1. 从一个诡异的故障说起协作越紧密系统越脆弱先说一件我实际遇到过的事。去年我在调一个多 Agent 的客服系统结构很简单一个售前 Agent 负责推荐商品和解答购买问题一个售后 Agent 负责退换货、退款、物流异常。当时我犯了一个非常直觉化的错误——为了让两个 Agent协作得更好我给它们配了一个完全共享的长期记忆库。我的想法很朴素既然是一个团队信息当然要互通有无售前聊完的用户诉求售后接手时就能直接看到历史不用再重新问一遍。上线头两周一切正常。然后某天下午售前 Agent 开始在一个商品推荐回复里一本正经地引用一条该商品支持 90 天无理由退款的政策。问题是这条政策从头到尾都不存在。我查了知识库没有任何一条文档写过这句话。可以追溯到源头是售后 Agent 在处理一个用户投诉时为了安抚情绪自己推断出了这个政策并写进了共享记忆。售前 Agent 在第二天读到这段记忆后果断把它当成了权威依据继续在对话里扩散它。用户越问越细售前 Agent 为了自圆其说甚至编出了更详细的退款流程。一个根本不存在的政策就这样在协作中被反复强化最后变成了系统里最稳定的错误事实。这次故障让我意识到一个核心问题我们通常理解的协作——信息越透明、共享越彻底、每个成员越了解彼此——在多 Agent 系统里恰恰是灾难的起点。真正工程意义上的多 Agent 协作不是靠信息无限流动来达成的。它靠的是另一件事把边界定义清楚。谁负责什么、谁能读什么、谁能写什么、谁在什么情况下把问题交给谁。边界不是协作的反义词边界恰恰是协作能够稳定发生的前提条件。就像结构工程里墙体不是用来隔绝空间的它是用来定义荷载路径、控制裂缝传播方向的。这篇文章我就想把关于边界的思考完整地梳理一遍多 Agent 系统里到底有哪些边界它们失效时是什么样的我们如何在工程上把它们设计得足够坚固以及在运行时如何监控和维护它们。适合正在用 LangGraph、CrewAI、AutoGen 或自研框架搭多 Agent 应用的人也适合那些已经在生产环境里被协作得很好的 Agent 团队坑过、却说不清楚问题出在哪的人。2. 多 Agent 系统里到底有哪些边界——四种边界及它们的职责很多人想到多 Agent 边界第一反应是隔离 Agent 之间的信息。这个理解没错但太粗糙了。边界不是一道墙而是许多道性质完全不同的墙。我习惯把多 Agent 系统中的边界分成四类知识边界、状态边界、权限边界、职责边界。它们的失效方式不同修复手段也不同混在一起讨论就容易抓瞎。先举个生活化的比喻。一个运转良好的项目组不是所有人都知道所有事。销售知道合同报价工程师知道技术瓶颈法务知道风险条款。PM 不会要求销售去审核代码规范工程师也不会去拍板客户赔付方案。每个人守着自己的边界只在特定的接口点交换信息——比如每日站会、PRD 评审、变更通知。真正的团队协作发生在这些交接点上不是发生在所有人的大脑里。多 Agent 系统也是一样的道理。只不过 Agent 没有职业素养和社会常识它不会自动判断这条信息是不是我该看的这个操作是不是我该做的。如果你不给它边界它什么都敢读、什么都敢写。下面我把四类边界分别拆开说清楚。知识边界Knowledge BoundaryAgent 在回答问题时允许引用哪些知识域。售前 Agent 只能查商品库、价格表、库存数据售后 Agent 只能查订单状态、退换货规则、物流接口。知识边界的核心问题不是模型知道什么而是模型在运行时能检索和引用什么。大模型的训练知识是公用的、打开的但一次具体的推理其知识来源完全可以并且应该被约束在某个范围内。状态边界State BoundaryAgent 能读写哪些记忆。这里说的记忆包括短期记忆当前会话中的几轮上下文和长期记忆跨会话的向量库、结构化存储、文件缓存。状态边界失效是四类边界里最隐蔽的因为记忆篡改不像知识污染那样直接反映在回答内容上它会在几十轮对话之后才暴露出来——一个 Agent 基于另一条 Agent 留下的错误推断做出了关键决策。权限边界Permission BoundaryAgent 允许调用哪些工具和外部接口。这个最接近传统后端系统的权限模型。查询订单接口、写数据库、发送邮件、操作文件系统每一项都应该有明确的谁可以碰的清单。权限边界往往被多 Agent 开发者忽略的原因在于开发期只有一个 Agent 在跑或者所有 Agent 都共用同一个 API Key权限问题根本不显形。一旦 Agent 数量上来、分工细化权限边界就成了系统安全的第一道闸门。职责边界Responsibility Boundary在特定任务流中到底由哪个 Agent 主导处理这件事。职责边界不是静态的你负责售前、我负责售后而是动态的——当一个会话从售前流转到售后时谁接管主导权谁退居只读辅助。职责边界失效的典型表现是抢答多个 Agent 同时对同一个用户诉求给出回复而且回复口径不一致系统整体表现就像人格分裂。为了看起来更直观我把这四类边界整理成这样边界类型一句话定义最典型的失效信号知识边界允许引用哪些知识域Agent 引用了职责域之外的文档或事实状态边界允许读写哪些记忆一个 Agent 的写操作污染了另一个 Agent 的决策依据权限边界允许调用哪些工具Agent 执行了超出自己角色范围的操作职责边界在任务流中由谁主导多个 Agent 对同一输入各自回复口径互相矛盾这里有一个非常重要的认知误区要澄清边界不是要切断 Agent 之间的协作它是在管理协作发生的时空范围。你完全可以让两个 Agent 共享一部分记忆、交叉引用一部分知识——但前提是这种交叉是设计出来的、走明确通道的而不是因为代码偷懒把所有东西堆在一起然后祈祷模型分行。边界管理的本质是把隐性的、全量的混合改成显性的、按需的连通。3. 边界模糊与边界泄漏故障模式的工程学分类边界在真实系统里从来不是二进制——不是有或没有而是多清楚和多糊。你可以把所有 Agent 塞进一个共享上下文的 prompt 里它们之间的边界几乎为零协作成本也几乎为零但系统行为完全失控你也可以让每个 Agent 完全隔离、老死不相往来协作彻底消失。绝大多数已上线的多 Agent 应用都坐落在两者之间的某个模糊位置。一旦边界模糊就会出现几种高频故障模式。能识别出这些模式排错的速度会快很多。我把它们分成四类信息串扰、职责重叠、正反馈回路、资源竞态。**信息串扰Cross-talk**是最常见的边界模糊病。我们把会话历史、检索结果、全局上下文一股脑塞给所有 Agent每个 Agent 都不具备这消息是发给我的吗的判断力。单独的 Agent 很聪明组合起来却会把不该作为决策依据的信息当成依据。我调试过一个多 Agent 项目团队用一个统一的 RAG 索引做知识检索查询词同时命中市场部文档和技术 FAQ。结果负责产品推荐的 Agent 在介绍功能时突然冒出一句已知性能瓶颈包括……。这就是知识边界失效检索引擎把不属于当前职责的内容返回了而 Agent 没有能力拒绝这些内容。给上下文窗口喂什么它就会用什么——这是语言模型的底层行为改 prompt 的作用非常有限。**职责重叠Responsibility Ambiguity**则是多个 Agent 抢一个活。最常见的设计错误是用意图分类 动态路由来决定哪个 Agent 响应但路由的判定边界本身模糊。比如一个通用助手Agent 和一个订单查询Agent 同时覆盖了我的订单到哪了这类诉求意图分类器稍微有波动请求就会路由到不同 Agent 手里用户得到的回复口径自然不一致。更麻烦的是当路由逻辑不够稳定时系统会在不同运行版本之间随机切换人格这种故障极难复现因为日志里每个请求看起来都合理。**正反馈回路Positive Feedback Loop**是我在文章开头那个案例里遇到的故障模式A 的输出变成 B 的输入B 的输出再反过来成为 A 的输入循环中每次迭代都会让偏差放大。语言模型的输出天生带有非确定性这种微小的偏差原本不会造成大问题但反馈回路会把它变成一次次复读——每次复读不仅不修正还会在一个错误的方向上添砖加瓦。我见过最夸张的案例里两个 Agent 在 7 轮互相对话之后就把一个最初的可能有优惠的猜测发展成了一份包含具体折扣额度、适用范围和截止日期的完整政策文档。没有任何人编造过它它就是这么一环一环长出来的。**资源竞态Resource Contention**看起来与前三种不同它更像是并发系统里的普通问题但在多 Agent 语境下有特殊危害。多个 Agent 同时请求同一个外部 API、同时写同一个数据库表、同时竞争同一个模型服务的配额。你不拦着它们就会互相踩踏轻则性能劣化重则数据互相覆盖。这类问题在单 Agent 的系统里几乎不存在因为只有一个执行者但到了多 Agent 并行执行时就成了常态而非偶发。把这四种故障模式放在一起看能得出一个工程学层面的结论边界是控制故障传播半径的手段。结构工程里防火墙的作用不是阻止火灾发生而是让火灾在一个房间内烧完不蔓延到整栋楼。多 Agent 系统的道理一模一样。信息串扰、职责重叠、反馈回路、资源竞态本质都是故障越过了边界从局部向全局扩散。边界设计的水平不体现在系统不出错的时侯恰恰体现在它出错的时侯影响面有多大。4. 把边界焊死一套可落地的边界设计方法讲了这么多理论下面来点能直接抄作业的东西。这部分是我在实际项目里逐步摸索出来的边界设计框架分为五个层面编排层、状态层、知识层、协议层、运行前预检。它们不是可选组合而是一个完整链路——任何一个层面缺失边界都会有漏风的地方。4.1 编排层每个 Agent 都要有一张角色卡片在编排层也就是定义执行流程的层面最容易被跳过的就是角色建模。大多数框架CrewAI 的 Agent 定义、LangGraph 的节点、AutoGen 的 ConversableAgent都允许你填 role 和 description但很少有人真正把角色描述写成一份严格的、可审计的职责说明书。我的做法是给每个 Agent 维护一张结构化的角色卡片不只是一个笼统的名字加一句话描述。它长这样role_card { id: sales_assistant, display_name: 售前助手, responsibilities: [ 根据用户需求推荐商品, 解答价格、库存、物流时效问题, 在用户表达售后诉求时将会话转交给 after_sales_assistant ], forbidden_actions: [ 承诺退款政策, 修改用户的订单状态, 访问售后申诉渠道 ], knowledge_domains: [ product_catalog, pricing, inventory ], memory_namespaces: [memory:sales:*], allowed_tools: [search_products, get_price, check_stock, create_handoff_ticket] }这张卡片不是给人看的是给两处代码看的一是编排引擎它根据角色卡片决定任务路由二是一个我后面会讲到的运行前预检模块它负责在 Agent 执行动作前做边界校验。角色卡片的关键是forbidden_actions。大多数团队只定义了Agent 能做什么没定义Agent 不能做什么。对于一个自带非确定性的模型来说只声明正面清单是不够的——模型在读到一个场景时没被禁止会被理解成可以做。你必须把所有高危动作显式写出来。4.2 状态层记忆分区与命名空间隔离记忆边界是所有边界里最值钱也最容易被滥用的一种。我见过太多团队把多 Agent 协作实现成了几个 Agent 共享同一个向量数据库集合这等于让每个 Agent 都能读写所有人的日记。我的建议是长期记忆按命名空间严格分区命名规则就用角色 ID 作为前缀配合完整路径# 不推荐所有 Agent 共享同一个 collection collection vector_db.get_collection(shared_memory) # 推荐每个 Agent 有独立的命名空间只有显式声明的跨域通道才可访问 sales_memory vector_db.get_collection(memory:sales) after_sales_memory vector_db.get_collection(memory:after_sales) # 跨域通道需在角色卡片里显式授权 handoff_notes vector_db.get_collection(memory:handoff)这里有个工程细节值得说清楚短期记忆会话上下文和长期记忆持久化存储要分开处理。短期记忆通常只存在于单个任务执行链中Agent 之间共享短期记忆在某些场景下是合理的比如让多个子 Agent 共同阅读同一份用户输入。但长期记忆一旦共享污染就是永久性的——今天一个 Agent 写错的事实三个月后还会被另一个 Agent 引用。如果你用的是 LangGraph你的 State 结构本身就承担了一部分记忆边界功能。不要把整个会话历史塞进一个全局 State 里让所有节点都读而应该在 State 里显式区分shared_context和private_context。每个节点声明它只能写自己的private_context公共区域的写入要走专门的handoff函数。4.3 知识层检索必须收口到职责域RAG 是目前多 Agent 系统最常用的知识增强手段但绝大多数实现都有同一个问题知识被摊开给所有 Agent。一个检索接口一个向量库谁的查询都能在这一个池子里捞。这么做表面上是最大化信息复用实际上是在给信息串扰开大门。正确的做法是给知识检索加上和权限系统一样的细粒度控制。RAG 架构不变但在索引和查询之间插一层权限过滤def retrieve_knowledge(agent_role: str, query: str, top_k: int 5): # 第一步先从角色卡片中取出该 Agent 的知识域白名单 allowed_domains role_card_registry.get(agent_role)[knowledge_domains] # 第二步在检索结果上做域过滤也可以用向量检索前过滤更省算力 candidates vector_db.search(query, top_ktop_k*3) filtered [doc for doc in candidates if doc.domain in allowed_domains] # 第三步如果过滤后结果不足宁可少给不要乱给 return filtered[:top_k]这里想强调一个反直觉的工程选择过滤后结果不足时不要用放宽领域来补足。宁可让 Agent 明确说该信息不在我的查询范围内也不要给它越界的上下文。很多工程师担心信息不够 → 回答质量差但实际上多 Agent 系统里因为信息越界而回答错误远比信息不足严重得多——前者是系统性错误后者只是不完整。4.4 协议层把协作设计成交接不是设计成讨论在多 Agent 系统里Agent 之间的协作方式可以分成两类一类是大家一起讨论同一个问题另一类是按契约交接任务。前者适合头脑风暴、方案评审但它在生产系统里极其危险因为它没有任何边界保障——A 的话会自然流入 B 的上下文B 的话又会回流到 A。后者才是生产级应用的常态。我的经验是将信息交换重构为契约交接。两个 Agent 之间不直接传递开放式对话内容而是传一个结构化的交接消息里面规定了字段、语义和有效范围handoff_message { type: handoff.sales_to_after_sales, source_agent: sales_assistant, target_agent: after_sales_assistant, user_intent_snapshot: 用户要求退货商品ID可查, critical_facts: [ {field: order_id, value: 20250115-77889}, {field: issued_complaint, value: 物流延迟导致拒收} ], explicitly_excluded: [ 销售承诺过的优惠信息可能不存在 ], expires_at: 2025-01-18T00:00:00Z }这个交接消息就是两个系统之间的接口——它把所有 Agent 间传递的信息收拢到明确定义的字段里减少了开放式内容随意漂移。工程上你应该给交接消息加 schema 校验字段名写错、类型不对直接拒绝交接。这听起来死板但它能拦下大量因为模型随手写了个字段而导致的隐性故障。提示交接消息不是文档它是运行时数据结构。不要让它携带大段自然语言总结尽量只带结构化字段。自然语言总结会把原 Agent 的偏见打包传递到下一个 Agent 手里。4.5 运行前预检给每个动作装一个限位器最后一步是运行时校验也是我后面称它为限位器的东西在多 Agent 框架里Agent 要调工具、写记忆、发消息之前都会经过一个拦截层。拦截层检查这次动作是否在角色卡片的允许范围内。越权动作直接拒绝并记录一条审计日志。用伪代码表示就是def guard_action(agent_role: str, action: dict) - dict: card role_card_registry.get(agent_role) if action[type] tool_call: if action[tool_name] not in card[allowed_tools]: return {allowed: False, reason: tool_not_in_whitelist} target action.get(target, ) # 一些工具需要路径级权限例如只读与写 if action[method] write and not card[allowed_write_targets].match(target): return {allowed: False, reason: write_target_out_of_scope} if action[type] memory_write: ns action[memory_namespace] if not any(ns.startswith(prefix) for prefix in card[memory_namespaces]): return {allowed: False, reason: memory_namespace_forbidden} if action[type] message_send: # 允许谁发给谁也要在编排层显式定义 if action[target_agent] not in card[allowed_participants]: return {allowed: False, reason: communication_not_configured} return {allowed: True}这个限位器是所有边界设计里投资回报率最高的一块。它把边界问题从信任模型变成了执行纪律——你再也不依赖模型自觉不越界而是从机制上保证它越不了界。很多框架比如 LangGraph 的interrupt机制、自研 Agent 的tool_executor都可以挂这种拦截层改造量并不大。5. 边界不是死的运行时监控与动态治理边界设计得再完美也只是预配置。运行中的多 Agent 系统是活的知识库在变、需求在变、Agent 的角色职责也在演进。边界不能设计完就一劳永逸你需要一套观测手段来看边界在哪断了、在哪堵了、在哪又太宽了。5.1 如何观测边界泄漏多 Agent 系统排错的最大困难是不知道谁在什么时侯读到了什么。单体 Agent 出了错你可以直接复现它的 prompt多 Agent 系统出错你得先搞清楚错误信息是从哪个 Agent 的哪段输入里串进来的。我的做法是给所有 Agent 加统一的审计埋点每条推理记录至少包含三件事这个 Agent 读了哪些知识条目知识边界观测、写了哪些记忆状态边界观测、调了哪些工具权限边界观测。不是可选的调试日志而是强制全量记录。你可以用现成的链路追踪工具LangSmith、Langfuse也可以自己在工具执行层里包一层记录函数。重点不是工具而是你要保证每一个读写动作都能对得上一个Agent 身份。有了全量审计日志边界泄漏就变成可查询的了。我最常跑的几个排查 SQL 思路供参考找跨域引用查某一天的日志看看售后 Agent 的回复里引用了多少条知识来源属于product_catalog域。如果比例超过个位数说明知识过滤有漏洞。找重复应答在同一个会话 ID 下如果两个不同 Agent 都产生了面向用户的最终回复说明职责边界在路由层失效了。找记忆互写查memory_write记录看哪个 Agent 写进了不属于自己命名空间的消息。这个要在预检层拦截但如果拦截层部署晚了历史记录里也能翻出来。5.2 一组值得跟踪的边界健康指标除了日志排查我建议日常盯三个指标。域外引用率Agent 在回复文本中引用了多少知识库域之外的条目。实现方式是给每条知识条目附加域标签并通过 LLM 或规则事后抽取回复内容来比对。这个指标最直接地反映知识边界的破坏程度。职责重叠指数在一段统计周期内多个 Agent 回复同一类用户请求的占比。计算方法是把用户请求做意图聚类然后看每个聚类下有多个 Agent 产出过最终答复的比例。这个值高说明路由边界不清晰需要马上调整。上下文污染比在 Agent 的实际上下文窗口中与本角色无关 message 的 token 占比。这个指标需要你在把信息塞进上下文时就打标。如果某天这个值突然升高往往意味着某个跨 Agent 通路没有按预期工作。这三个指标不需要像 Prometheus 监控那样搞得很重可以放在每日离线任务里算。多 Agent 应用初期的边界问题不会按小时爆发按天观察完全来得及。5.3 边界的动态调整治理循环与熔断边界在运行期是可以且应该被调整的。我的做法是每个迭代周期做一次边界评审流程简化下来是三步找越界事件从审计日志里找出所有被guard_action拦截的动作、所有域外引用率超标的会话。判断越界原因是一个 Agent 的任务定义确实需要扩大知识域还是路由写得不合理把一个不该发给它的请求分给它了这步务必区分边界设窄了和模型行为失控前者需要放宽后者需要收紧。执行调整修改角色卡片或路由逻辑把新的边界配置部署上去。角色卡片应该是可热更新的配置而不是写死在代码里的定义。除了日常调整还必须有熔断机制。当一个 Agent 的越界行为事件频发、而且每次都产生用户可见的错误时不要让它继续在旁边半越界运行——直接把它的权限降级为只读切断它的工具调用链路等人工 review 完再恢复。这个降级动作跟后端系统把一个异常节点从负载均衡池里摘掉是一个道理。系统可以损失一部分智能能力但不能承担持续扩散的错误。5.4 反馈回路的抑制边界里的止损通道前文提到的正反馈回路在运行时治理中值得单独讲一下。回路一旦形成靠调整角色卡片是不够的因为它是两个 Agent 之间动态涌现的相互增强不体现在任何单一 Agent 的越界行为上。我自己项目里最管用的办法有两条。第一在交接消息上附加事实来源链每个 Critical Fact 都标注来源 Agent 和产生时间接收 Agent 在引用这个事实时如果发现来源 Agent已经和自己处于同一协作路径上就禁止将其作为新依据继续传递——切断自我循环。第二对 Agent 间连续的对话轮次设置阈值同一任务链内部Agent 之间的消息往复超过 N 轮我常用 3 到 5 轮就直接中断要求一个角色卡片之外的人工节点或者更上级的编排器做一次汇总和裁决再决定是否继续。这个限制看起来粗暴但正是防火墙截断火灾蔓延的多 Agent 版本。6. 边界治理的分寸感冗余、安全裕度与演进节奏讲到这里你可能会产生一个印象边界越多越森严越好。这其实是对工程学方法的误解。结构工程里的边界墙体、伸缩缝、柱距从来不是越多越好而是恰到好处。边界设计的关键不是砍断所有连接而是给每个必要的连接匹配足够的安全裕度。在多 Agent 系统里这个分寸感体现在三个地方。第一个地方是容许有节制的冗余。两个 Agent 偶尔都能回答同类问题本身不是问题问题是这种冗余是否在预期之内、是否有一致性保障。如果你的边界设计成绝对不重叠你会损失系统天然的容错能力——一个 Agent 挂了另一个可以顶上。我通常允许职责边界存在 10% 左右的灰区但这部分灰区必须经过同一套知识源、同一个回复口径的校验而不是放任两个 Agent 各自发挥。第二个地方是显式设计跨边界通道而不是等泄漏发生后再补救。比如一个编辑 Agent 和审核 Agent 之间它们确实需要共享一份草稿内容。你不能因为它们属于不同角色就把存储完全隔离而是应该在角色卡片里显式声明一个共享命名空间memory:drafts:*两个角色都有读写权限其他角色一律禁止。这样跨边界的协作是被批准的、被记录的而不是漏过去的。边界管理做久了你会发现真正让你省心的工作就是把所有隐式泄漏变成显式授权。第三个地方是边界治理的演进节奏。在一套多 Agent 系统刚上线时边界设得紧一些、宁可误伤不可放任上线跑通几个业务场景、积累了一批审计日志后再按照真实数据把边界调松或调细。很多人一上来就追求完美平衡搞出一套极其复杂的动态路由和共享协议结果系统复杂到根本跑不动。我更推荐的做法是先拿角色卡片 命名空间隔离 运行前预检这三板斧把骨架立起来用两个星期观察真实流量再动手加动态调整和熔断这类高级机制。边界治理是一个循环往复打磨的过程不是一次交付的文物。最后分享一个我反复踩过坑之后总结出的经验多 Agent 系统的稳定性不取决于你用的框架有多先进、模型有多聪明而取决于你能不能回答清楚三个朴素的问题——在这条任务链上每一步应该是谁在做它被允许依赖哪些信息它做完之后把结果交给谁、以什么格式交这三个问题的答案越明确你的边界就越清晰边界越清晰一个 Agent 的失控就越难演化成整个系统的崩溃。至于协作得更好这件事等边界立住了再谈也不迟。