这两年我越来越笃定一件事：单打独斗的 Agent 已经过时了。不是说单个智能体没用，而是当你真正把一个任务丢给它，让它从"帮你写一段代码"变成"替你扛一个完整的业务流"时，单 Agent 很快就会暴露出一堆问题：上下文塞爆、角色混乱、出错后没人纠偏。于是我开始把目光转向"智能体军团"——让多个各司其职的 Agent 组成一张协同作战图，像排兵布阵一样去拆解任务。这篇文章就是我搭过几个多智能体系统之后，对"协同作战图到底该怎么设计"的完整复盘。适合那些已经跑通过单 Agent Demo、正准备往真实业务场景落地的开发者，也适合想搞清楚多 Agent 协作到底比单 Agent 强在哪里的产品和技术负责人。

1. 为什么单枪匹马的 Agent 总在关键时刻掉链子

先聊点真实的。我最早做 AI 应用的时候，思路特别简单：把所有需求都塞进一个 Agent 里，指望它"能者多劳"。比如让它既要做信息检索，又要做数据分析，还要负责最后的文案输出。做个 Demo 给朋友演示，效果确实惊艳。可一旦把场景换成每天生产真实内容、处理真实数据，问题就一个接一个冒出来。这些坑不是模型不够聪明，而是单 Agent 的架构上限就在那里。

1.1 单 Agent 的三大死穴：上下文、工具边界、错误放大

第一个死穴是上下文窗口有限。大模型的上下文是稀缺资源，当任务链条很长，中间过程会产生大量中间结果，这些结果全堆在同一个上下文里，很快就把窗口撑爆。更麻烦的是，前面的信息会污染后面的推理。比如检索回来 20 篇文档，Agent 在处理到第 15 篇的时候，可能已经忘了第 1 篇在讲什么，于是产生幻觉。这不是提示词工程能救回来的，这是信息过载的物理限制。

第二个死穴是工具边界模糊。真实业务流往往需要多种能力：检索、计算、调用外部 API、生成结构化数据、做质量校验。你把所有工具都挂在同一个 Agent 上，它会频繁地在不同工具之间切换。而每切换一次，都意味着一次上下文重写、一次注意力分散。我见过某个 Agent 在"检索——分析——写入数据库"这个链条上反复横跳，最后把一段应该写入金额字段的内容，写进了日期字段。它并不是不懂，只是角色的连续一致性在长链路里维持不住。

第三个死穴是错误会被放大而不是收敛。单 Agent 链条里，如果一个环节出了问题，后续所有环节都会基于错误继续执行。更棘手的是，单 Agent 没有"自我纠偏"的天然机制——它一边干活一边检查自己的产出，等于让运动员兼任裁判，效果可想而知。你只能靠外部再加一层校验逻辑，可这样你自己就变成了那个"第二 Agent"。

1.2 多智能体协同的本质：分工、交接、校验

搞明白单 Agent 的瓶颈，再看多智能体就顺了。所谓"智能体军团协同作战图"，本质上做三件事：分工，把一个大任务拆成若干小任务，每个小任务对应一个专职 Agent；交接，定义清楚 Agent 之间的输入输出接口，让信息像流水线一样有序流转；校验，让独立的 Agent 或规则去检查关键产出，质量不达标就退回重做。

打一个最朴素的比方：单 Agent 像一个小工作室，一个人包揽策划、写稿、排版、设计，听着全能，实际产能被严重限制；多智能体像一个正规内容团队，策划、写手、编辑、设计各管一摊，每道工序之间有明确交接物和验收标准。一个人改稿改十遍，不如让写手和编辑互相盯一眼，这就是校验的价值。

有一点必须强调：多智能体绝不是"让几个 Agent 多轮聊天"。很多人一上来就让两个 Agent 你一言我一语地对话，以为这就是协作了。但自由对话没有结构，没有接口规范，没有终止条件，最后通常会陷入两个结果：要么无限循环，要么跑题。真正的协同作战图，第一步就是把"聊天"变成"结构化协作"。

1.3 什么场景才值得搞"军团"

在动手设计协同图之前，建议先对号入座。以下三类场景是最典型的"适合搞军团"：

一是研究分析类，比如"搜集 20 个来源的信息→交叉验证→输出一份带引用的分析报告"。这类任务天然有检索、筛选、整合、生成的阶段划分，拆成多个 Agent 后，每个环节都可以用最合适的模型策略来处理。

二是内容生产类，比如"每天基于一批新闻素材，产出公众号长文 + 微博短文案 + 内部摘要"。同一个素材要适应三种不同风格和长度要求，用三个专职 Agent 分别处理，比一个 Agent 来回变换人设要稳定得多。

三是批量化处理类，比如"批量读取客户工单→分类→标记优先级→起草回复→质检后发送"。这类任务串行阶段多，每个阶段的需求都很明确，非常适合流水线式协同。

反过来，如果只是简单的知识问答、单轮翻译、摘要生成，单 Agent 完全够用，强行拆成军团只是自找麻烦。这一点后面我会专门展开，先记住：多智能体是手段，不是目的。

2. 先分清阵型再谈协作：五种常见的智能体协同拓扑

"协同作战图"这四个字，设计的核心其实是"图"——也就是节点和边的关系。节点是 Agent，边是消息流转。在我画过和复盘过的项目里，多智能体的协作关系基本跑不出五种基础拓扑。每种拓扑解决一类问题，也各有代价。搞清楚这五种拓扑，你画图的时候才不会拍脑袋。

2.1 主管-下属模式：一个掌控者拆解全局任务

这是最经典、也是新手最容易上手的拓扑。整体结构是一个主管 Agent（Supervisor）对着一群专职下属 Agent。主管负责理解用户的总目标，把目标拆成子任务，然后一个个派发给合适的下属，下属完成后把结果交回，主管再汇总、决策下一步。

这其实就是一个"项目经理 + 团队"的结构。主管并不直接干活，它负责的是调度和整合。我见过很多成功的案例，比如某个研究报告生成系统：主管先派出"资料员"去搜资料，然后派"分析师"去出框架，再派"写手"去扩写，最后派"校对员"去查重。主管在每个环节都看结果、拍板是否进入下一步。

这个拓扑的优点是职责清晰、可控性强，主管可以在任何环节截停，防止任务跑偏；缺点是主管会成为瓶颈，所有信息都要过它这一手，复杂度上升后主管的上下文也会紧张。适合任务边界清晰、子任务划分明确的场景。

2.2 流水线模式：上一站的产出就是下一站的原料

流水线拓扑很好理解：Agent 按顺序排成一条线，前一个 Agent 的输出经过程序化处理，变成后一个 Agent 的输入。每一步只做一件事，做深做透，然后传给下一棒。整个过程不回流、不向上汇报，像工厂生产线。

我经常用流水线处理内容生产场景：第一个 Agent 做素材采集，把原始信息清洗成结构化条目；第二个 Agent 做数据分析，找出关键数字和趋势；第三个 Agent 做内容生成，把数据改写成可读的文案；最后交给质检 Agent做格式和事实校验。每个 Agent 的职责被压缩到很小，因此指令精度可以提得很高。

流水线的优点是效率高、逻辑简单；缺点是灵活性差，如果有一步需要回溯或者旁路处理，流水线的表达能力就不够了。所以流水线适合那些"输入稳定、流程固定"的批处理任务。

2.3 辩论与对抗模式：让不同立场互相找茬

这个拓扑最近很火。思路是让两个或多个 Agent 站在不同立场，对同一个问题分别给出答案或判断，再由一个评审 Agent或规则模块做最终裁决。典型的用法有：一个 Agent 写方案，一个 Agent 找方案的漏洞；或者两个 Agent 分别基于不同数据源做分析，再把结果对比验证。

我折腾过最实用的一种，是在内容审校场景里：一个 Agent 担任"流量派"，负责从选题吸引力的角度挑毛病；另一个 Agent 担任"严谨派"，负责从事实准确性的角度挑毛病。两个 Agent 各自输出一批问题清单，最后由一个评审 Agent 汇总去重，决定哪些修改必须做、哪些可以忽略。

对抗模式的优点是显著提高产出质量，尤其适合容错率低的场景；缺点是成本翻倍，而且如果缺少有力的裁决机制，容易陷入"互怼循环"。切记：对抗不是目的，让第三方做决策才是目的。

2.4 网状协商模式：Agent 之间自由协作

网状拓扑是最"多智能体"的多智能体，所有 Agent 互相可见，可以自由发送消息、请求帮助、交换信息，没有中心化的主管。这种结构像一张合作网，理论上最灵活，Agent 之间可以形成动态的临时协作关系。

但这种拓扑也是最危险的。没有中心调度，意味着没有全局视角，Agent 之间的协作路径不可预期，很容易出现"A 请求 B，B 又请求 A"的循环，或者某个 Agent 被大量消息淹没。我现在的建议是：除非团队里有非常强的可观测性基础设施建设，否则不要轻易上全局网状结构。即便要上，也建议先加一个消息中央路由，限制 Agent 之间的直连，让所有协作都经过可控的通道。

2.5 市场与路由模式：让任务动态找到专家

最后一种拓扑，本质上是一种"动态路由"。系统里挂着一堆专家 Agent，每个 Agent 注册自己的"技能标签"和能力描述。当任务进来时，由一个路由器 Agent或规则匹配器判断：这个任务应该交给哪个专家？如果任务比较复杂，则可能拆解后在多个专家之间流转。

这个模式有点像打车平台：乘客（任务）发出需求，平台（路由器）匹配最合适的司机（专家 Agent）。它的优势是扩展性好，新增一个专家只需要注册，不需要改动全局逻辑；缺点是路由器本身需要做得足够聪明，且对专家 Agent 的能力描述要非常准确，否则会频繁派错单。

2.6 五种拓扑怎么选：一个很朴素的判断逻辑

画协同图之前先问自己三个问题：任务的前后顺序重不重要？如果重要，考虑流水线；任务的子任务之间需不需要相互校验？如果需要，加对抗；任务是不是需要一个总负责人持续拍板？那就上主管-下属。网状拓扑不是不能用，它更适合做内部探索型应用，但真到了生产环境，我建议先从其余四种里选。

下表是我自己在选型时常用的快速对照：

配合使用也很常见：我自己最常用的是"主管-下属 + 流水线"混搭，主管负责拆任务，每个子任务内部再走一段流水线。图不一定要纯粹，关键是每一条边你都说得清楚"为什么要这样连"。

3. 把协同图画清楚的三个核心设计要素：角色、消息、裁决

拓扑是骨架，真正让协同图跑起来的是三个设计要素：角色定义、消息通信、裁决机制。很多人的协同图画出来花里胡哨，一跑就崩，问题基本都出在这三件事没做好。

3.1 角色卡片：每个 Agent 的职责边界要写到什么程度

画协同图的第一步不是连线，而是先把每个 Agent 的"角色卡片"写出来。我写角色卡片一般包含五个字段：岗位名称、核心目标、输入内容、输出内容、可用工具。限制越明确，Agent 越不容易越界。

举个例子，在一个内容生产协同图里，我会这样定义角色：

写完角色卡片，你会发现自己对每个 Agent 的提示词都变得特别精准，因为你不需要再告诉它"你是一个无所不能的助手"，你只需要告诉它"你负责接收结构化素材列表，只做一件事：找出其中最突出的三个数据亮点，输出一份分析结论"。

职责边界还有一个隐性作用：它能帮你控制成本。每个 Agent 只携带与它职责相关的少量上下文，模型推理时注意力更聚焦，token 消耗也更可控。

3.2 消息协议：别让 Agent 之间说"人话"

多智能体系统最容易犯的一个错误，是让 Agent 之间用自然语言互相"聊天"。问题是自然语言高度冗余、信息密度低、不可枚举，导致下游 Agent 需要花大量上下文去解析对方的模糊表达。正确的做法是：在 Agent 之间传递结构化消息。

我设计消息结构时，常用的最小字段集是这样：

{ "message_id": "c7f33a1e-9b21-4a12-8d42-1d8a5f00f3a1", "sender": "collector_agent", "receiver": "analyst_agent", "task_type": "analyze_trends", "payload": { "materials": [ {"title": "...", "source": "...", "content": "...", "collected_at": "..."} ] }, "status": "success", "trace_id": "task_0821_01" }

这里必须保留的字段是trace_id和status。trace_id解决可观测性，一次完整任务的链路追踪全靠它；status解决失败传递，下游 Agent 收到status: failed的任务时，可以直接跳过或启动补偿逻辑，而不是傻乎乎地继续处理一堆空数据。

在具体实现上，消息可以走两类通道：一是中心化状态，所有 Agent 读写同一个 State 对象，适合用图编排框架直接管理；二是消息队列，Agent 之间通过队列收发消息，适合更松耦合的系统。前者更简单、更容易追踪；后者更灵活，但需要额外处理消息消费和重试。我的经验是：在项目早期选中心化状态就够了，别一上来就上消息队列，那是在给自己加复杂度。

3.3 裁决机制：质量闸门和返工回路

协同图里不能只有"干活"的 Agent，必须要有"验收"的机制。我把这个机制叫做质量闸门（Quality Gate）。每个闸门有两个选项：通过，则任务流向下一节点；不通过，则回到上游某节点返工，或直接转人工。

裁决的实现方式有几种，按成本从低到高排列：规则闸门（比如检查输出 JSON 是否合法、字段是否完整、字数是否达标），模型闸门（用一个评分 Agent 对产出打分），人工闸门（关键节点直接插入人工审批）。生产环境通常吃混合方案：低风险环节用规则，高风险环节上模型，关键决策点上人。

这里有个很关键的参数：返工最大轮次。如果不设上限，一个写手 Agent 和质检 Agent 可以无限循环下去，成本直接爆掉。我常用的策略是：返工最多两轮，两轮之后无论质量如何，直接提交给人处理。因为从实际经验看，第三轮及以后的返工边际收益极低，Agent 往往只是在同一个圈子里打转，与其让它继续改，不如把球踢给人类。

4. 实战：把一张"内容生产战情室"协同图跑到能上线

前面讲的都是方法论，这一节上一个完整案例。我称它为"某内容生产战情室"，是我做过的一个模拟项目，目标很简单：每天自动基于最新资讯，产出三样东西——一份行业日报、一份周度趋势分析、若干条社交平台短文案。听起来不大，但你要是试图用单 Agent 搞定，会发现它要同时扮演编辑、分析师、写手、标题党，早早就精神分裂了。我们用多智能体协同图来解决。

4.1 场景设定与基础选型

先看战情室要处理的原始输入：一批资讯源链接、若干行业关键词，以及用户指定的当日关注主题。输出端是三类产品：日报（严肃、结构化）、周报（偏深度分析）、短文案（活泼、碎片化）。这个场景天然适合"主管-下属 + 流水线"的混搭拓扑。

技术选型上，我没有重度依赖某个特定框架，用的是当前主流的图编排框架思路：状态共享 + 节点函数。简单说，整个系统维护一个全局状态 dict，每个 Agent 节点是一个函数，读取上游写入状态的字段，处理后写回新字段，然后根据状态中的标记决定下一步走到哪个节点。这么做的好处是逻辑透明，挂了可以直接看状态在哪一步断的。

4.2 战情室里的 Agent 角色编排

战情室里设了五个角色：

1. 采集官：从资讯源抓取内容，清洗 HTML，抽取出标题、正文、时间、来源，输出结构化素材列表。
2. 分析师：接收素材列表，围绕用户关注主题做数据统计和趋势归纳，输出观点结论。
3. 写手（日报线）：基于分析结论，生成正式日报，要求语言克制、提供数据引用。
4. 写手（社媒线）：基于同一份分析结论，生成 5 条不同风格的短文案，要求口语化、有传播性。
5. 质检官：检查日报和短文案是否存在事实错误（对照素材原文）、是否缺失关键数据、格式是否符合发布规范。

画成协同图，大概是这样的执行顺序：采集官先跑 → 分析师再跑 → 两条写手线并行执行 → 质检官统一验收 → 不合格返工，合格输出。这里有一个典型的"扇出再扇入"结构：分析师产出同一份结论，喂给两个不同的写手，最后汇总到同一个质检官。这类结构在图编排框架里实现起来特别顺手。

4.3 核心代码逻辑：状态、节点、边

我简化一下核心逻辑。首先是状态定义：

class BattleRoomState: materials: list # 采集官的产出 analysis: dict # 分析师的观点结论 daily_report: str # 日报线写手的产出 social_posts: list # 社媒线写手的产出 quality_report: dict # 质检官的验收结果 current_step: str # 当前走到哪个环节

然后是把每个 Agent 封装成"节点函数"。这里我只贴关键的调度部分，让协同关系的逻辑更清楚：

def run_pipeline(state): # 第一站：采集 state.materials = collector_agent.run(source_urls=config.SOURCES) state.current_step = "collector_done" # 第二站：分析 state.analysis = analyst_agent.run( materials=state.materials, focus=config.FOCUS_TOPIC ) state.current_step = "analyst_done" # 第三站：两条写手线并行，可以同时执行 from concurrent.futures import ThreadPoolExecutor with ThreadPoolExecutor(max_workers=2) as pool: f_daily = pool.submit(daily_writer.run, state.analysis) f_social = pool.submit(social_writer.run, state.analysis) state.daily_report = f_daily.result() state.social_posts = f_social.result() state.current_step = "writers_done" # 第四站：质检闸门 state.quality_report = qa_agent.run( daily_report=state.daily_report, social_posts=state.social_posts, original_materials=state.materials ) if state.quality_report["passed"]: state.current_step = "done" else: state.current_step = "needs_fix" return state

这个结构里有一个值得注意的设计：采集官的输出是"结构化素材列表"，分析师接收的是结构列表而不是原始正文。这样分析师就不需要反复读全文，只需要基于已经抽好的要点做归纳。省 token 还在其次，关键是避免了"分析师被素材细节带跑"的风险。

4.4 跑出来的效果和必须做的两个改进

我拿这个模拟系统跑过大概一百个任务，印象最深的是质检官节点对整体质量的兜底作用。前面几版没有质检官时，偶尔会产出"看起来通顺但数据对不上原文"的报告，混在正常产出里特别难发现。加上质检官并配置事实比对逻辑后，这类硬伤基本能在输出前被拦截住。

另外一个必须做的是人工审批闸门。尤其是日报这类对外可见度高的产出，我最后在质检官之后加了一个"人工确认"节点，属于批次发布前的最后一道关卡。所谓"自动化"，不一定是全无人化，在关键节点保留人工权限，才是对自动化能力的尊重。战情室运行中，真实的人工介入率最终压到了两成左右，且大都发生在重大数据发布的当天。这个比例完全可以接受。

5. 协同图落地时绕不开的五个坑

方法再好，落地时该踩的坑一个都不会少。我挑五个最有共性的问题展开讲，每一个都是我一度被搞到头皮发麻的实战经历。

5.1 坑一：循环依赖与死锁，编出来的图走不通

多智能体系统里最隐蔽的问题不是某一步报错，而是整个图卡住不动。典型情况是：Agent A 要等 Agent B 的结果，Agent B 又要等 Agent A 的结果，两个节点互相等待，谁也没法先开工。还有一种更隐蔽的，是"间接循环"：A 依赖 B，B 依赖 C，C 又依赖 A，三四个节点串成一个环，画图时根本察觉不到。

解法分两层。第一层靠设计：画完图后强制检查一遍有向边，确保整体是一个有向无环图（DAG），至少主干链路不能有环。如果确实需要"反复修改"这样的回路，不能把它画成原路返回的闭环，而是用一个单独的"返工计数"状态来标记，返工节点重新触发时走的是一个新的执行分支。第二层靠兜底：在调度器层面设置每轮执行的最大节点数和超时时间，一旦超过，宁可任务失败，也不能让它悄悄跑一晚上消耗 token。

5.2 坑二：上下文污染，A 的记忆串到了 B 的大脑里

在图编排框架中，多个 Agent 共享同一个全局状态。这本来是方便，但也容易变成灾难。比如采集官把原始素材写进了状态，写手生成文案时不光读了分析结论，还把采集官的原始素材捞出来直接当成自己的输出素材，于是写出来的段落黏着大量原文碎片。这就是上下文污染，下游 Agent 收到了过量、与它当前职责无关的信息，被带偏了。

我的对策是：每一个 Agent 节点在接收输入前，先做一次字段级的"过滤"，只把它该看到的字段放进它的上下文。采集官看不到质检报告，写手看不到其他写手的初稿，分析师只需要结构化的素材列表。核心原则就一句：各 Agent 之间只传递完成当前任务所必需的最小信息集。宁可多定义几个中间字段，也别把所有半成品都堆在一个共享大状态里。

5.3 坑三：成本失控，智能体军团变成了烧钱黑洞

多 Agent 系统的推理成本不是简单的加法，而是乘数。因为每多一个 Agent，就多一份独立的上下文和多轮推理，再加上总控节点的调用、质检节点的评分、返工循环的迭代，一笔任务跑下来账单很吓人。我见过某个任务链条，光主链路就调用了十几次大模型，还是不同规模的模型各调各的。

控制成本要从三个角度同时使劲。第一，能用小模型的地方不上大模型：路由判断、字段提取、格式检查这类轻量任务，用便宜的小模型完全够；第二，限制返工和重试次数，这是最有效的止损手段；第三，凡是程序能做的校验，不要用模型去做，比如 JSON 格式检查、字段存在性校验，写几行正则就完了，完全不需要再问一次大模型。

5.4 坑四："责任推诿"，质检官说改，写手改完还是不行

多 Agent 系统里有一种特别让人抓狂的现象：质检官提出修改意见，写手改完交回来，质检官又说不行，再改再说不行的循环就这样反复出现。从我的观察看，原因通常不是两个 Agent 在互相找茬，而是质检标准没有被形式化。质检官靠"感觉"判断，写手靠"感觉"修改，标准一直漂移，永远对不上。

解法是把质量闸门从"主观评分"改成"清单校验"。我在质检节点里维护一份显式的检查清单，每一项是布尔判断：是否包含至少三个数据来源？是否有引用来源字段？所有数字是否与素材原文一致？每条短文案是否超过 50 字？质检官每次输出这份清单的勾选结果，写手拿到清单后照着补就行。返工轮次的收敛效果立竿见影。

5.5 坑五：故障定位难，任务挂了你不知道去找谁

单 Agent 出问题，报错信息就在那一个调用里，好查。多 Agent 系统出问题，可能是采集环节源头数据格式变了，可能是分析师模型抽风，可能是质检规则误判，也可能只是某个中间字段没传对。没有可观测性的话，排查一次故障能把人耗到崩溃。

所以我有两条硬规矩。第一，每个 Agent 节点入口和出口都打日志，记录入参摘要、出参摘要、耗时、token 消耗，以及最重要的trace_id。第二，所有节点共享同一个trace_id，这样任何一次失败的任务，都可以按 trace_id 把整个链路的日志捞出来，快速定位卡在哪一个环节。很多智能体框架自带 tracing 能力，一定要在项目初期就把它开起来，别等到出了问题再补。

6. 什么时候该收手：不要为了"多智能体"而多智能体

聊了这么多怎么把军团建起来，最后我得泼一盆冷水。多智能体是手段，不是目的。在我身边已经能看到一种现象：有开发者为了让项目听起来"高级"，不管什么场景都强行拆出四五个 Agent，结果系统变慢、变贵、变难维护，产出质量还没有单 Agent 直接跑得好。这种"为了多智能体而多智能体"的倾向，才是这个领域最大的坑。

6.1 单 Agent 依然够用的几个信号

你自己判断一下，如果下面几条里命中三条以上，我建议你老老实实先把单 Agent 用透，不要动拆分的念头。

第一，任务链条短，整个流程不超过三四个操作步骤，上下文不会膨胀。比如"把这段录音转成文字并润色"，两步搞定，拆成两个 Agent 纯属脱裤子放屁。

第二，角色不需要多次切换，整个任务始终是同一个视角。比如"根据这篇论文写一份摘要"，从头到尾都是读者视角，不需要变成批评者、再变成改写者。

第三，你目前最痛的是单次生成质量不够，而不是流程复杂。这种情况应该先去调提示词、补示例、做检索增强，而不是拆 Agent。质量问题很多时候不是"人不够"，而是"工具不够或数据不够"。

第四，成本敏感。多 Agent 系统对个人开发者和中小团队来说，是一个持续性的成本负担。如果你的付费能力有限，那先单 Agent + 工具链，是你性价比最高的方案。

6.2 渐进式改造：从"单 Agent + 工具"开始长出征兆

如果你判断下来确实需要多智能体，也建议不要一把梭，走渐进式路径。第一步，先把"工具"做好，让单 Agent 有能力去调用检索、计算、写库；第二步，加一个质检 Agent，只负责对主 Agent 的产出做检查，这是最简单、收益最明显的多 Agent 改造；第三步，把主流程拆成两个阶段，比如"先分析再生成"，让每个 Agent 专注一个阶段；最后，在上面的基础上再按需要加入主管、路由、人工闸门。

我用这个顺序迭代过好几个项目，每一次都踩在"刚好需要"的节点上，没有一次是因为面子工程硬上架构。做技术最忌讳的，是拿架构复杂度来证明自己很专业。真正的专业，是让系统在自己该有的复杂度上运行，多一分浪费，少一分不稳定。

说到底，"智能体军团协同作战图"不是一张挂在墙上的气势恢宏的蓝图，它就是一份工程图纸。节点定得越清晰、边画得越克制、闸门设得越明确，你的军团就越能打。画图之前用笔在纸上把角色、消息、裁决列出来，能帮你躲掉九成的返工。以后你回头看自己设计的那些协同图，最成功的，大概率不是编排得最花哨的那张，而是每个 Agent 都知道自己该干什么、不该干什么的那张。