多 Agent 协作系统怎么设计？8 个核心问题拆解
多 Agent 协作系统设计有 8 个核心问题，一次讲透。
- 角色拆分：决策 / 协调 / 执行三层，权限等级分开
- 上下文传递：选择性注入 + 笔记本模式，避开上下文膨胀
- 冲突仲裁：分类 + 证据链验证 + 置信度加权升级
- 死循环破解：状态机 + 令牌桶 + 仲裁 agent
- 共享记忆：共识 / 私有分层 + 命名空间隔离
- 可观测性：监控 + 追踪 + 日志 + 全链路 trace
- 效果评估：完成度 / 效率 / 经济性，必须 AB 对标
- 错误恢复：澄清 → 规划校验 → 反思 → 仲裁兜底
多 Agent 不是 1+1>2，先看值不值再上。
1. 角色怎么拆：别按工种拆，按层级拆
最常见的错误是按工种拆角色——数据采集 agent、数据分析 agent、报告生成 agent。看起来分工明确，实际跑起来全是扯皮。
正确的拆法是按 层级 拆：
每个 agent 只能管两三个相关工具，做到高内聚低耦合。一个 agent 什么都干，能力看起来强，实际上没法做权限控制——你也不知道它下一步会调什么工具、动什么数据。
加分项是 权限等级：核心能力（写库、调支付）、辅助能力（搜索、读库）、工具能力（计算、转换）分开。权限一样，所有 agent 都能改核心数据，出问题根本定位不到是谁干的。
2. 上下文怎么传：别全量传，选着传
最朴素也最贵的做法是"把上家所有上下文都塞给下家"。几个 agent 串下来，prompt 撑爆，token 成本线性上涨。
更好的姿势是 选择性注入：
- 关键结论放在最前面，让下家第一眼看到
- 用检索器动态筛选真正相关的信息
- 大量原始数据只在需要的时候才加载
跨窗口（多个 agent 跨多轮）场景，笔记本模式 几乎是必备：
- 遇到需要长期保留的关键信息，先写进外部存储（KV、向量库、文件）
- 后面的 agent 按需去查，不塞 prompt
- 既不丢信息，又把 token 省下来
说白了，把 agent 的"短期记忆"和"长期记忆"分开管理，别让短期记忆膨胀成长期负担。
3. agent 结论冲突了怎么办：先分类，再验证证据
两个 agent 给出相反的结论，第一反应不应该是投票。投票看起来民主，实际上是让多数人的意见碾压少数人的事实。
专业的做法是三步走：
- 分类冲突：是强分歧（结论互斥）、弱分歧（细节不一致）还是沉默冲突（一个 agent 没说话）
- 证据链验证：不看谁声音大，核对双方各自的证据来源——数据哪来的、推理路径对不对
- 置信度加权 + 升级：两边置信度差得大、又是关键决策，自动升级给人类判断
这一步听着麻烦，但是区分"会跑多 agent"和"会设计多 agent"的分水岭。只做投票的方案，碰上对抗样本立刻崩。
4. 死循环怎么防：状态机 + 令牌桶 + 仲裁 agent
多 agent 互相调用的死循环是经典坑。基础解法：
- 状态机检测调用图：A→B→A 直接环、A→B→C→A 间接环，发现即熔断
- 迭代 / 转交 / 重试次数硬上限：所有可能递归的计数器都设上限
- 令牌桶限流：每次调用消耗一个令牌，用完就停
进阶做法是 配一个独立的仲裁 agent，专门实时监控调用关系图：
仲裁 agent 不参与业务，只看"谁在调谁、调了多少次、是不是形成了环"。一旦发现异常，立刻熔断、改路由。这条思路我之前在 Agent 死循环怎么办？ 里讲过单 agent 场景，多 agent 只是把环从"工具调用"升级到"agent 调用"。
5. 共享记忆怎么管：分层 + 命名空间 + 过期
所有 agent 共享一份记忆，认知污染 几乎是必然——agent A 写一条临时笔记，agent B 把它当事实用，整个系统开始胡说八道。
记忆至少分两层：
| 层级 | 读权限 | 写权限 | 用途 |
|---|---|---|---|
| 共识层 | 所有 agent | 需仲裁通过 | 跨 agent 共享的事实 |
| 私有层 | 仅 owner | 仅 owner | agent 内部状态、临时笔记 |
更进一步：
- 命名空间隔离：用权限矩阵控制"谁能写、谁能读"，别让所有 agent 都能改共享区
- 版本控制：记忆有版本号，被覆盖可回滚
- 信息衰减：记忆有 TTL，过期自动失效，需要时重新验证再用
详细的多层记忆设计可以参考 AI Agent 的记忆系统，本文不展开。
6. 协作链路怎么可观测：监控 + 追踪 + 日志，缺一不可
很多人以为"加个监控就行"，其实可观测性要拆成三块：
- 监控（Metrics）：发生了什么——调用次数、成功率、token 消耗
- 追踪（Tracing）：请求走了哪条链路——A → 协调 → B → 协调 → C
- 日志（Logging）：为什么这么做——关键决策点的 reasoning 记录
真正体现水平的，是能拉出 全链路 trace：
- 调用深度有多深（嵌套几层）
- 冲突率是多少（哪些节点经常打架）
- token 成本花在哪儿（哪段 prompt 撑爆了）
- 根因定位一次到位，不用满头大汗去猜
生产环境没 trace，出问题只能靠日志拼接，定位一次根因半天起步。
7. 怎么评估效果：4 个维度 + AB 对标
单 agent 看完成度就够了，多 agent 必须看 4 个维度：
| 维度 | 关键指标 |
|---|---|
| 完成度 | 任务准确率、完整率、一致性 |
| 协作效率 | 链路长度、冲突率、平均完成步数 |
| 经济性 | 总 token 成本、单任务成本、ROI |
| 稳定性 | 异常恢复率、循环发生率、仲裁触发率 |
这里有个反直觉的认知必须拎出来：多 agent 不是简单的 1+1>2，很多场景下成功率反而会衰减——协调成本、冲突成本、token 成本叠加，可能比单 agent 更差。
所以 必须做 AB 对标测试：单 agent baseline vs 多 agent 方案，跑同一批任务、看同一组指标。只对比"谁效果更好"是片面的，要看"值不值"——多出来的 30% 准确率，能不能 cover 多出来的 200% token 成本？
8. agent 误读需求、连续调错工具：四层兜底
agent 拿到模糊需求就开始猜、猜错了还死磕，是生产环境最常见的翻车之一。解法是四层递进：
- 输入澄清层：遇到模糊请求先反问确认，别自己脑补
- 规划校验层：执行前先验证工具调用顺序合不合理
- 实时监测 + 自我反思层：发现输出异常触发反思，连续出错直接中断
- 仲裁 agent 兜底层：重新理解意图、重新规划；解决不了升级给人类
关键原则：不能一条路走到黑。任何一个 layer 失败，下一层立刻接上，而不是在错误方向上多花 10 步 token。
写在最后
8 个问题覆盖了多 agent 协作从设计到落地的全链路：角色拆解、上下文传递、冲突仲裁、死循环防护、记忆管理、可观测性、效果评估、错误恢复。
最后一条建议：不要为多 agent 而多 agent。多 agent 解决的是单 agent 解决不了的复杂问题（并行子任务、专业分工、跨领域协同），但代价是协调成本和调试成本。如果单 agent 加更多工具就能搞定，就别上多 agent。
References
- 阿里算法岗三面真题精讲：完整拆解多 Agent 协作通信架构、任务分配机制与分布式协同落地思路 —— AI大模型原理, Bilibili