最近在做一个偏综合信息处理的项目，需求大致是：拿到一堆半结构化资料，拆出关键信息、做风险判断、再给出一套可执行建议。最开始我直接押到单个 LLM 接口上，任务一多、上下文一长，问题就出来了：前面几个要点在后半程被忘干净，同一份材料甚至能生成两种互相矛盾的结论。后来我把方案彻底改了，核心思路一句话——做成"协作型多智能体 AI Agent"，让不同的 LLM 实例各管一块，通过任务协调与分工来抵消单模型的局限。这篇文章想把这段周期里关于任务拆解、角色定义、通信协议、踩坑记录这些实操层面的东西整理出来，给正在做多 Agent 方案的朋友做一份参考。
1. 为什么单个 LLM 会"忙不过来"：多智能体协作的三类典型场景
1.1 多角色任务：上下文被不同目标搅成一锅粥
我最早踩到的坑是"一个 Agent 同时要扮演两个角色"。
举个例子，当时接到一个客服场景：既要给客户回一封有同理心的安抚邮件，又要同步生成一份内部工单，把客诉等级、影响范围、责任部门标清楚。同一个 LLM 实例拿到这段提示词，前半段表现很好，情绪拿捏得不错，但切到后半段写工单时，它就容易把"安抚客户"的语气带到结构化输出里，字段变得冗长、不够硬核。反过来也有，让它先写工单再回邮件，邮件又经常变成干巴巴的"事件编号+处理结果"。
问题不在模型能力，而在上下文里同时揉进了两套目标。一个 Agent 的注意力池就那么大，多目标共存时必然互相污染。协作型多智能体天然把这两类目标拆给两个独立 LLM 实例，各自上下文里只有自己的目标。
1.2 复合调研任务：上下文过长后的"顺序性失忆"
第二个典型场景是长周期复合任务。拿市场调研来说，可能需要读 30 多份文件，提炼竞品动向、客户诉求、行业趋势等。
单个 Agent 处理这种任务，最常见的失效模式是"顺序性失忆"：先喂它 A 文件，它记了；再喂 B、C、D，等喂到第 20 份时，第 5 份文件的关键结论已经模糊了。你说"把这些都综合一下"，它往往会基于最近几份文件给出偏颇的综合结论。
这个场景适合用多 Agent 做数据分片：每个子 Agent 只看自己负责的 5 份文件，分别产出小结，再由一个汇总 Agent 去融合这些小结。一句话：让每个 LLM 都工作在它最舒适的信息量范围内，而不是强行拉大单上下文。
1.3 单 Agent 的"集权"瓶颈：自己写、自己审，必然自圆其说
我越来越觉得，单 Agent 做复杂任务最大的问题不是"不够聪明"，而是"缺少外部校验"。
一个 Agent 要自己写方案、自己挑毛病。你让它"写完后自查三遍"，它大概率只是换个说法把原来的内容再输出一遍。人类写文档至少还有个同事帮忙 review，单 Agent 世界里只有自己，天然缺少"对立视角"。
多智能体协作可以在结构上解决这个问题：生成 Agent 负责产出，评审 Agent 负责挑刺。两者的上下文隔离、目标对立、互相看不到对方的完整思考链。这个结构听起来简单，实操中很有效果。
2. 协作骨架：从流水线到编排者的三种架构取舍
2.1 三种拓扑：串行流水线、星型编排、环型讨论
确定要上多 Agent 之后，先别急着写提示词，得先把 Agent 之间的"组织架构"定下来。我接触过的协作拓扑大体分三种：
| 架构 | 协作方式 | 适合场景 | 典型风险 |
|---|---|---|---|
| 串行流水线 | A 处理完交给 B，B 处理完交给 C | 步骤固定、节点依赖明确的任务 | 单点失败即全链失败；前序错误被后序放大 |
| 星型编排 | 一个 Orchestrator 负责拆任务，分给 Worker，回收结果再决策 | 任务可并行、需要动态调度 | Orchestrator 成为瓶颈，对它的上下文要求高 |
| 环型讨论 | Agent 之间互相看输出、轮流提意见 | 评审、头脑风暴、方案博弈 | 极易死循环，Token 消耗大，收敛难 |
我自己的项目最终选了"星型编排 + 串行子流水线"的混合结构：整体上协调者（Orchestrator）做任务分配和汇总，具体某个子任务内部再走小流水线。这种结构比较贴合现实世界的团队协作方式：有牵头人，也有各条线的专业执行者。
2.2 任务分解：静态模板还是动态路由
任何协作系统最核心的机制都是"任务怎么切"。前期为了快速跑通，可以用静态拆分：把任务预定义为几个固定节点，比如"信息提取→风险识别→建议生成→交叉评审"。但实际运营一段时间后，你会发现静态拆分的效率上限很低——因为真实任务的复杂度和各环节耗时是动态的。
动态路由的逻辑是：协调者在每一步根据当前信息和目标，自己决定下一步该调哪个子 Agent。比如某个文件质量很差，提取都没有产出，那么"风险识别"这个节点是否继续跑就有意义了。动态路由在代码上就是一个循环加决策，依赖协调者的判断能力。
我的建议是：第一版本别急着上动态路由。先把任务的节点拆得足够细，每个节点跑通，再去考虑如何让协调者动态选择节点。新手一上来就动态路由，很容易出现调度混乱，连问题出在"路由决策"还是"子任务执行"都分不清。
2.3 通信内容设计：Agent 之间说"结构化数据"，不说闲聊
Agent 之间的消息本质上是数据结构，不是自然语言聊天。这一点是很多人容易忽略的。
一开始我也图省事，让 Agent 之间直接传自然语言段落。结果就是信息密度低、容易跑题、后续解析麻烦。后来统一改成结构化的消息体，大致如下：
{ "from": "extractor", "to": "risker", "task_id": "project_x_task_001", "payload": { "extracted_facts": [...], "confidence": 0.82, "source_slices": [...] }, "metadata": { "round": 1, "timestamp": "2024-06-20T10:30:00Z" } }关键是payload里的字段要尽量对子 Agent 友好，比如confidence（置信度）这个字段，能让下游判断"这份提取结果是否值得信任"，而不是盲目拿去做分析。通信语义越明确，下游 Agent 的行为就越可控。
3. 让 LLM 真正"分得了工"：角色定义、调度协议与通信结构落地
3.1 角色卡：比提示词多一点结构
多智能体里的提示词和单 Agent 很不一样。单 Agent 提示词只需要告诉它"做什么、怎么做"，多 Agent 提示词还必须在开头定义边界：你是什么角色、你负责什么、你不需要管什么、你的输入是什么、你的输出给谁。
我习惯把角色卡定义为五个部分：目标、输入、输出、约束、协作规则。举个例子，信息提取角色卡：
- 目标：从指定文档块中抽取与任务问题相关的事实，输出去重后的结构化事实列表。
- 输入：文档块文本，可能包含噪声。
- 输出：JSON 数组，每项含 fact、confidence、source_paragraph。
- 约束：不编造原文不存在的信息；不重复输出相同事实；如果原文互相矛盾，保留冲突记录并标注。
- 协作规则：只与 Orchestrator 通信，不直接与其他 Agent 对话；收到不确定指令时请求澄清，最多一次。
这套角色卡让我印象深刻的地方在哪？它把"不做什么"和"做什么"放在同等地位。因为多 Agent 场景里，Agent 擅自接手别的角色的活，常常是混乱的根源。
3.2 协调者的调度协议：决策节流是关键
Orchestrator 角色的质量，基本决定了整个系统的上限。它的问题是：协调者本身也是一个 LLM 调用，每轮都要消耗大量上下文，如果每一轮都让它重新阅读所有子任务的输出，成本会迅速失控。
我用了"决策节流"来缓解：协调者不直接接收 Worker 的原始输出，各 Worker 先把自己的输出压缩成摘要层再上报。控制协调者读取的消息量在 2000 到 4000 token 以内。这看起来像是信息损耗，但实际效果反而更好——协调者的注意力集中在"该决策什么"而不是"该读什么"上。
调度协议我用的是一个简单的状态循环，伪代码大概长这样：
state = {"status": "init", "artifacts": {}} while state["status"] not in ["done", "failed"]: next_actions = orchestrator_llm( system=orchestrator_role, global_state=state["summary"], available_workers=["extractor", "risker", "advicer", "critic"], ) # next_actions 是结构化指令，例如： # {"call": "extractor", "input": "chapter2.md", "round": 2} for action in next_actions: result = run_worker(action) state["artifacts"][action["round"]] = result["summary"] state["summary"] = summarize_all(state["artifacts"])注意我限制了一轮最多调 2 个 Worker，目的是控制节奏，避免一次调度太多导致上下文杂乱。实际跑下来，这个调度速度比一次全调慢，但每个环节的质量稳定许多。
3.3 停止条件：没有收敛机制的协作就是烧钱
多 Agent 协作里最隐蔽的成本黑洞是"没有收敛机制"。Agent 之间聊着聊着就互相补充、互相更正，每轮都增加新内容，但整体没有朝终点推进。
我在停止条件上设置了双重保险：
- 硬阈值：轮次不超过 N（比如 8 轮），达到即强制收敛，由协调者给出当前最佳输出。
- 软收敛：每一轮之间的"新增有效信息量"低于阈值（比如新增事实数少于 3 个，或所有 Agent 的置信度都高于 0.9），视为已经收敛。
- 评审终止：评审 Agent 连续两轮输出"通过"，或给出的修改建议没有新增项，则强制结束。
这样设计之后，一个常见的调研类协作任务通常在 3 到 5 轮内完成，不会拖到 10 轮以后。
3.4 框架选型的几个现实考量
现在市面上有不少现成的多 Agent 编排框架，但我的经验是：框架能省的是你跟底层 LLM 交互的重复工作，省不了的是你对你业务任务本身的理解。无论选哪个框架，核心要看三件事：
- 是否支持结构化消息的自定义 schema，还是只能传自由文本。
- 是否有可见的链路日志、消息可追溯，这决定你线上出问题能不能排查。
- 状态管理是框架拉起还是自己管理。我踩过不少坑，很多框架表面上做了状态管理，一旦涉及"协调者需要看到所有历史摘要"这类需求，它提供的默认存储就显得捉襟见肘了。
综合来看，目前比较成熟的方案自己搭一套轻量调度层，把 Agent 调用逻辑控制在几百行代码里，比被迫适配某个框架的抽象概念要省心得多。框架可以选"轻量、可扩展、至少支持自定义状态存储"的，而不是什么都内置好的"全家桶"。
4. 踩坑实录：串不起来的 Agent、死循环对话与幻觉放大链路
4.1 "分而不协"：每个 Agent 干得很好，合起来一团糟
一种很让人沮丧的情况：每个子 Agent 单独拿出来测试，输出都可圈可点，但整个协作链路一跑，最终结果反而比单 Agent 还差。
我在模拟项目 X 里遇到过：信息提取 Agent 给出的摘要准确率很高，风险识别 Agent 的分析也到位，但汇总阶段的协调者把两者简单拼接，分析建议显得特别割裂，前后逻辑对不上。原因在于协调者"融合"的手段太粗暴——它不知道提取 Agent 给的是事实层信息，风险识别给的是判断层信息，两者不是并列关系，是有先后依赖的。
修复办法：给协调者下发任务图模板，明确告诉它信息节点之间的依赖关系。例如"先看风险识别的结论，再决定用哪些事实作为论据"，而不是把两个输出混在一起重新生成。多 Agent 系统里，真正流走的不只是数据，还有数据之间的"逻辑顺序"。
4.2 死循环对话：两个 Agent 互相客气，Token 烧掉一半
环型讨论结构的最大坑，就是无终止的"客套式循环"。
前一阵我让两个 Agent 相互做方案 review，A 提了个意见，B 说"感谢指出，我会改进"，然后 A 又说"基于你的改进，我建议再考虑另一个角度"，B 又说"非常好的建议"…… 第 7 轮以后，它们输出的内容已经和原始任务需求没什么关系了。
这个问题光靠调系统提示词解决不了，提示词里写"请避免无意义客套话"完全不可靠。实际有效的手段是：给每轮的消息加"增量约束"——在角色卡里明确要求："如果本轮你没有发现新的实质性差异点，请明确输出 PASS，不要生成任何客套回应。"再加一个硬轮次上限，任何一轮达到上限就强制由协调者做最终裁定。
4.3 幻觉放大链路：A 的一个小错误，被 B、C、D 轮番"确认"
这是多 Agent 结构里最危险的坑，处理不好整个系统没法上线。
有一次我们做内部知识库问答，信息提取 Agent 在某个文件里提取出一条看似可靠但实际上是幻觉的信息，它自己标了置信度 0.85。接下来风险分析 Agent 基于这条"事实"做了三段分析，评审 Agent 看到分析逻辑完整就批了"通过"。最终链路输出：一个建立在幻觉之上的完整报告，权威感十足。
我后来设置了双保险：一是要求每个下游 Agent 对自己的输入做"事实核对"，如果输出中引用了上游事实且置信度高于阈值，必须直接从原文中引用原文片段作为论据，而不是转述；二是在汇合层加了一个校验 Agent，只负责核对"上游事实"和"原文"的一致性，不参与任何生成。这个校验 Agent 的上下文很小、但专门治这种扩散问题。
4.4 身份混淆：Agent 用着用着，忘了自己的角色
多 Agent 协作时间长、上下文一长，Agent 容易出现"身份漂移"。最典型的表现是：本该做数据提取的 Agent，最后一轮给出了建议，还在文末写了"以上是完善的方案，可以用 X 模型加速"；或者本该做评审的 Agent 忍不住自己动手改起了方案细节。
我定位到根因：某个 Agent 的上下文里，历史对话里混入了其他角色的指令和输出，它误认为这些内容也属于自己职责的一部分。
解决办法分两层。代码层：每次调用强制刷新 system prompt，不把它放入历史，完整保留角色卡的约束。数据层：在消息结构里加上scope字段，限定该 Agent 的输入只包含结构化输入流，而不是所有全局广播的内容。做到这两点，身份漂移出现的频率大幅下降。
4.5 一个完整的排查案例：资料审核小组的 12 轮无意义循环
最后放一个完整排查过程，给大家参考思路。
背景：模拟项目 X 做一份对外调查报告，配置了一个资料审核小组：抓取 Agent 负责收集原始链接，审核 Agent 负责确认链接内容真实性，协调者负责汇总。第一天跑出来一份报告，耗时 23 分钟、Token 消耗是单 Agent 的 8 倍，结果是失败——大部分链接标注"待确认"。
排查链路：
第一步，翻日志。发现协调者在第 3 轮对抓取 Agent 发出了一个模糊指令"继续补充缺失的信息"，抓取 Agent 不知道缺什么，就抓了一轮相同来源的链接算是"补充"。审核 Agent 收到一堆重复链接，一条条打标记。
第二步，看消息结构。我发现协调者广播的是"任务当前状态"的完整摘要，里面包含每个子 Agent 的名称和输出，但没有"哪些字段已完成、哪些还缺"的结构化状态表。子 Agent 只能靠读全文猜测进度。
第三步，修方案。我在状态定义里增加了一个"字段完成度"的表格，明确三列：字段名、状态、缺失原因。协调者只广播这张表，不再广播完整会话。同时给子 Agent 的协作规则加了一条："除非收到明确的行动指令，否则不要主动补充材料。"
改完之后，同样任务的 Token 消耗降到原来的 30%，成功率从 60% 提到了 92%。这个案例给了我很深印象：多 Agent 系统的很多问题不在"智能"层面，而在"组织信息流"层面。
5. 生产可用：动态任务路由、共享记忆与成本控制
5.1 从固定流程到动态任务路由
跑通了固定流程之后，可以开始考虑动态路由了。我发现它真正的好处是：能让任务分配跟"各 Agent 的实际执行质量"挂钩。
实现方法是在协调者的状态摘要里加入各 Worker 的历史表现指标，比如置信度均值、平均轮次、最近一次是否出现超时。协调者在决定把新任务传给谁时，可以倾向于选择"置信度更高、历史表现更稳"的 Worker。这个逻辑和路由表差不多，只是决策者由协调者 LLM 来代劳。
不过要注意：动态路由意味着输出不再有固定路径，调试复杂度显著上升。我的建议是给每个请求分配一个 trace_id，贯穿所有 Agent 的输入输出日志，线上排查时凭 trace_id 拉出整条调用链。没有这个，动态路由出现问题时你根本不知道从哪里查起。
5.2 全局记忆与私聊上下文的区隔
多 Agent 协作久了会面临一个矛盾：一方面希望 Agent 之间共享足够信息，避免重复劳动；另一方面，上一节讲到，全局广播会让每个 Agent 的上下文膨胀，甚至出现身份混淆。
我的经验是明确区分"全局状态"和"Agent 私聊上下文"。全局状态只有结构化摘要，比如任务进度、关键结论、冲突项；而 Agent 之间的详细讨论，只放在它们各自的上下文里，不上报到全局层。需要时，协调者再主动拉取某个 Agent 的详细输出。这个模式和团队协作很像：全组开会只同步关键信息，具体工作细节还在各小组里解决。
5.3 交叉校验机制：让 Agent A 复核 Agent B 的结果
除了用专门校验 Agent，我后来还试过一种"互审机制"：两个职责不重叠的 Agent 互相复核对方的输出。比如信息提取 Agent 完成提取后，让风险识别 Agent（同一文档的另一个视角）简单检查"提取结果是否遗漏了明显风险相关内容"。
这个方法的效果有两面性。好处是确实抓到了不少此前遗漏的信息；坏处是 Token 成本几乎翻倍，而且 Agent 之间如果共享了某些偏见，互相复核反而强化了这种偏见。所以我的建议是：互审只用在任务的关键路径上，其他节点不启用。能省就省。
5.4 成本与延迟的可控设计
聊到生产化，必须正面谈成本和延迟。一套多 Agent 协作系统的单位任务成本，通常是一个单 Agent 方案的 5 到 20 倍。控制成本的方法，我在项目里实践下来有这么几个比较有效：
| 手段 | 思路 | 效果 |
|---|---|---|
| 小模型负责粗过滤 | 用轻量分类模型判断文档是否需要进入深度提取 | 可过滤 30% 以上无用文档 |
| 摘要前置 | 子 Agent 只返回摘要，不返回全文 | 协调者上下文降 70% |
| 早停机制 | 软收敛出现时立即结束，不做满轮次 | 平均轮次减少约 40% |
| 分级模型 | 简单任务用小模型，复杂任务才上大模型 | 成本显著下降，质量无明显衰减 |
延迟方面，对用户可感知的任务，尽量只跑必要的链路。例如用户问一个事实性问题，就不必走"提取→分析→建议→评审"全链路，可以直接命中一条短路径，减少了一次请求里的调用次数，响应时间能明显改善。
5.5 给不同业务场景的配置建议
最后整理一下我目前对不同任务类型的默认配置思路，不一定最优，但参考价值比较高。
- 内容总结类：串行小流水线，2 个 Agent（提取 + 总结），不需要评审。
- 风险分析类：星型编排，信息提取 + 风险识别 + 交叉校验，评审 Agent 用轻量模型。
- 创意方案类：环型讨论 + 硬轮次上限，3 个 Agent，评审 Agent 的存在感要强。
- 长文档问答类：多提取 Agent 并行，汇总 Agent 融合，加一个校验 Agent 做事实核对。
每类任务的共同底线，是每一轮调用的输出必须可结构化、可追溯、可复用。输出的混乱是任何多 Agent 系统走向不可维护的起点。
收尾经验：别急着把系统搞得复杂
做了这么多协作型多智能体方案，我最大的体会是：这个领域真正难的地方，不在让每个 LLM 变聪明，而在让一堆 LLM 之间不互相添乱。角色定义、状态设计、消息结构、收敛条件，任何一块偷懒，最后都会以线上奇怪的错误还回来。
如果让我给正准备入手的读者一个具体建议：第一版宁可用相对朴素的结构，比如一个编排者加两个 Worker，把消息、状态、日志梳理仔细，先跑通再往上加复杂度。协作粒度也是宁粗勿细，一开始把 Agent 切得太细，你会发现维护成本急剧上升，而且很多"问题"其实是 Agent 之间协作的噪声，不是真正的任务难点。
最后分享一个小技巧：给每个 Agent 的输出加一个"置信度"字段，让任何下游都能判断"这条结果到底能不能直接用"。这个字段不需要多复杂，但要真实反映模型对输出的把握程度，会有意外收获——你会发现，很多协作冲突其实在拿到各自置信度之后就可以提前化解。
