Agent丨多 Agent 协作有哪些常见模式、适用场景和主要挑战？

type

Post

status

Published

date

Apr 16, 2026

slug

agent10

summary

1. 为什么需要多 Agent？

单 Agent 最大的问题不是“不够聪明”，而是上下文、工具和目标过载。一个 Agent 同时负责需求分析、代码搜索、实现、测试、评审、文档、部署时，很容易出现以下问题：

上下文窗口被无关信息污染。工具过多导致选择错误。既负责写代码又负责审代码，容易自我确认。长任务阻塞主会话，用户无法及时干预。权限边界不清，分析型任务也可能误写文件或误执行命令。

LangChain 团队在多 Agent 架构基准测试中也指出，单 Agent 在工具数量和上下文规模增长时性能会明显下降；多 Agent 的动机之一就是把不同工具集、上下文和职责模块化，便于维护、评估、并行化和跨团队开发。(LangChain)

2. 从成熟项目看多 Agent 的工程化方向

2.1 Claude Code：Subagent + Hook 生命周期

Claude Code 的多 Agent 设计重点是 Subagent。官方文档显示，用户可以通过 /agents 创建子代理，子代理以 Markdown 文件加 YAML frontmatter 的方式定义，并可配置自定义 prompt、工具限制、权限模式、hooks、skills 等。(Claude Code)

一个典型 Claude Code 风格的 subagent 配置可以抽象成：

Claude Code 的 Hook 机制也值得参考。官方文档说明，Hooks 可以在 session、turn、tool call 等生命周期点触发，事件包括 SessionStart、UserPromptSubmit、PreToolUse、PostToolUse、SubagentStart/Stop、TaskCreated/TaskCompleted 等。(Claude Code)

这说明 Claude Code 的多 Agent 不是孤立的“角色扮演”，而是嵌入到了完整的 Agentic loop 生命周期里：

Claude Code 的启发：
多 Agent 应该被设计进生命周期，而不是临时 prompt 拼接。

2.2 OpenCode：Primary Agent + Subagent + 权限模型

OpenCode 的文档把 Agent 分为两类：Primary agents 和 Subagents。Primary agent 是用户直接交互的主代理，Subagent 是主代理可调用的专门助手，也可以通过 @agent 手动调用。(OpenCode)

OpenCode 内置两个 primary agent：

build：默认开发 Agent，具备完整工具权限。
plan：受限 Agent，默认对文件编辑和 bash 命令要求确认，适合代码分析、规划和建议，不直接修改代码。(OpenCode)

OpenCode 还内置三个 subagent：

general：复杂搜索和多步骤任务。
explore：快速、只读地探索代码库。
scout：外部文档和依赖源码研究。(OpenCode)

其配置方式非常适合学习。OpenCode 支持在 opencode.json 中为不同 Agent 设置模式、模型、prompt 和权限。官方文档示例中，权限可以用 ask、allow、deny 控制，并且支持 read、edit、bash、websearch、webfetch、lsp、skill 等权限项。(OpenCode)

可以抽象成如下源码风格：

OpenCode 的启发：
多 Agent 的核心不是“多个名字”，而是不同 agent 拥有不同工具、权限、模型和上下文。

2.3 OpenClaw：Gateway + agentId + 多人格隔离

OpenClaw 的设计更偏向“长期运行的个人/团队 AI 操作系统”。它通过 Gateway 作为统一控制平面，连接 CLI、Web UI、移动端节点、headless node 等客户端。OpenClaw 文档明确说明 Gateway WebSocket 协议是单一控制平面和节点传输层，所有客户端连接时声明自己的 role 和 scope。(OpenClaw)

在多 Agent 路由上，OpenClaw 把一个 Agent 定义为完整的 persona scope：包括 workspace 文件、auth profile、model registry、session store；每个 agentId 都有独立的 workspace、状态目录和 session 存储。(OpenClaw)

OpenClaw 的 Sub-agents 是从已有 Agent run 中派生的后台 Agent run，它们运行在自己的 session 中，完成后把结果通知回发起者。文档还强调子代理默认隔离、可选 sandbox、不默认获得 session tools，并支持可配置嵌套深度。(OpenClaw)

OpenClaw 的多 Agent 配置也体现了“按渠道路由到独立 Agent”的思想：

OpenClaw 文档也提醒，workspace 默认 cwd 并不等于硬 sandbox，绝对路径仍可能访问宿主机其他位置，除非启用 sandbox；其配置里也支持为 Agent session 启用隔离 sandbox runtime。(OpenClaw)

OpenClaw 的启发：
多 Agent 协作如果要进生产，一定要把身份、会话、权限、工作目录、工具和通信渠道一起设计。

3. 多 Agent 协作的常见模式

模式一：Router / Handoff，路由转交模式

这是最常见、也最容易落地的模式。

用户请求先进入 Router Agent，由 Router 判断任务类型，然后转交给最合适的专家 Agent。例如：

“帮我分析这个 repo 的性能问题” → code-explorer
“帮我写测试” → test-writer
“帮我查依赖库源码” → dependency-scout
“帮我审查安全风险” → security-reviewer

LangGraph Swarm 对这种模式有比较清晰的定义：swarm-style 多 Agent 允许 Agent 根据专长动态 handoff 给其他 Agent，并记住最后活跃的 Agent，后续交互可以从该 Agent 继续。(GitHub)

一个简化版路由器可以这样写：

适用场景：

企业知识库问答：财务、人事、法务、研发文档分别由不同 Agent 处理。Coding Agent：探索、实现、测试、审查、文档分工。RAG 系统：查询路由到不同 collection、retriever 或工具。ChatOps：不同 Slack channel 或不同机器人账号绑定不同 Agent。

主要挑战：

Router 一旦判断错，后续 Agent 会沿着错误方向深入。解决方式是：
给 Router 明确的 agent description、加置信度、允许二次转交、保留人工 override。

模式二：Supervisor / Worker，主管-工人模式

Supervisor 负责理解任务、拆解计划、分配任务、整合结果；Worker 只负责局部任务。

LangChain 的多 Agent 基准文章把 Supervisor 定义为：单个 supervisor 接收用户输入并委派给 sub-agent，sub-agent 返回后控制权回到 supervisor，且只有 supervisor 能回复用户。(LangChain)

Microsoft Agent Framework 的迁移文档中也展示了类似的 manager/orchestrator 思路：用 manager agent 协调整个 workflow，并配置参与者、最大轮数、stall 处理、人类审查等。(Microsoft Learn)

一个工程化 Supervisor 不应该只是“让 LLM 自由分配”，而应该显式维护任务状态：

适用场景：

长链路研发任务：需求 → 设计 → 编码 → 测试 → Review。自动化研究报告：检索 → 归纳 → 交叉验证 → 写作。数据分析：数据理解 → SQL/Python → 图表 → 业务解释。企业流程自动化：申请、审批、执行、归档。

主要挑战：

Supervisor 容易成为瓶颈。所有信息都经过它，会导致 token 成本增加、信息转述失真、上下文膨胀。LangChain 的实验也提到，Supervisor 架构里的“转述层”会带来类似电话游戏的错误，后来通过减少 handoff 消息、直接 forward 子 Agent 输出等方式改善。(LangChain)

模式三：Parallel Subagents，并行探索模式

当任务可以拆成互不依赖的子问题时，最适合并行化。

例如用户问：

“帮我评估这个 RAG 系统的召回质量、chunk 策略、rerank 效果和线上延迟瓶颈。”

可以同时启动四个 Agent：

retrieval-evaluator
chunking-analyst
rerank-specialist
latency-profiler

OpenClaw 的 Sub-agents 文档明确说，子代理目标之一是并行化 research、long task、slow tool 工作，避免阻塞主 run，同时默认保持 session 隔离。(OpenClaw)

Microsoft Agent Framework 文档也展示了 concurrent execution：多个 Agent 并行处理输入，最后返回合并结果。(Microsoft Learn)

伪代码：

适用场景：

多文件代码搜索。多数据源 RAG 检索。多方案架构评估。多模型交叉验证。长耗时工具任务，如浏览器操作、依赖源码分析、benchmark。

主要挑战：

并行不等于更准确。并行 Agent 可能重复搜索、结论冲突、成本翻倍。必须有 aggregator 负责去重、排序、冲突解释和最终决策。

模式四：Planner / Executor / Reviewer，计划-执行-评审模式

这是 Coding Agent 中最实用的模式之一。

OpenCode 的 plan 与 build 分离非常适合这个模式：plan 负责分析和规划，默认限制文件编辑和 bash；build 负责实际开发，具备更高权限。(OpenCode)

可以把权限设计成：

适用场景：

生产代码修改。数据库 migration。DevOps 脚本生成。自动修复测试失败。大型 refactor。

主要挑战：

Executor 容易偏离 Planner 的边界，Reviewer 又可能只做形式审查。解决方式是：
计划必须结构化，执行必须产出 diff，评审必须基于 diff、测试和需求逐项核对。

模式五：Critic / Judge，批判者与裁判模式

这个模式不是让多个 Agent 合作完成不同部分，而是让它们对同一问题给出独立判断，再由 Judge 选择或合并。

适用场景：

架构方案评审。安全审计。RAG 生成答案的事实性校验。多模型结果投票。PR Review。

一个 Judge Agent 的输入最好是结构化的：

主要挑战：

多个 Agent 可能互相强化错误，尤其是它们共享同一段错误上下文时。要让 Critic 模式有效，需要：
独立上下文、不同评审维度、引用证据、低温度、明确 verdict schema。

模式六：Blackboard / Shared Memory，共享黑板模式

多个 Agent 不直接点对点聊天，而是围绕一个共享状态区协作。每个 Agent 往黑板写入观察、证据、假设、待办、结论，其他 Agent 读取后继续推进。

OpenClaw 的多 Agent 路由文档提到，每个 Agent 有独立 workspace、session store，同时也支持在配置中让一个 Agent 搜索另一个 Agent 的 QMD session transcript collection。(OpenClaw)

这类模式在 RAG 里尤其常见：

retriever-agent 写入候选文档。
reranker-agent 写入重排结果。
answer-agent 写入答案草稿。
verifier-agent 写入事实核查结果。
synthesizer-agent 最终输出。

伪代码：

主要挑战：

共享记忆很容易变成“垃圾堆”。必须给黑板数据加类型、来源、时间、置信度、可追溯引用和过期机制。否则多 Agent 会读取过时结论，形成错误循环。

模式七：Event-driven Agents，事件驱动模式

这种模式适合长期运行的 Agent 系统。Agent 不只响应用户 prompt，也响应事件：

文件变更。
GitHub PR 创建。
测试失败。
Slack 提及。
定时任务。
Webhook。
工具调用前后。

Claude Code 的 Hooks 支持 session、turn、tool call 级别事件，OpenClaw 也支持 hook/webhook 配置，并提醒 webhook payload 应被视为不可信输入。(Claude Code)

伪代码：

主要挑战：

事件驱动系统最大风险是权限扩大和触发风暴。要限制事件来源、去重、限流、加审批、记录审计日志，并对不可信 payload 做 prompt injection 防护。

4. 多 Agent 模式选型表

模式	核心思想	适用场景	优点	主要风险
Router / Handoff	根据任务类型转交专家 Agent	客服、RAG、多工具系统、Coding Agent	简单、扩展性好	路由错误
Supervisor / Worker	主管拆解任务，工人执行	长任务、复杂研发、报告生成	可控、结构清晰	Supervisor 成本高、转述失真
Parallel Subagents	多个 Agent 并行探索	搜索、评估、代码扫描	快、覆盖广	成本高、结果冲突
Planner / Executor / Reviewer	计划、执行、评审分离	代码修改、DevOps、数据库变更	安全、可审计	流程变慢
Critic / Judge	多视角评审后裁决	架构、安全、事实核查	降低单点偏差	多 Agent 共同幻觉
Blackboard	通过共享记忆协作	RAG、研究、长期项目	可追溯、可持续	记忆污染
Event-driven	由事件触发 Agent	ChatOps、PR、测试、告警	自动化程度高	触发风暴、权限风险

5. 放到 RAG 系统里，多 Agent 怎么设计？

一个生产级 RAG 系统可以拆成以下 Agent：

推荐职责拆分：

query-router-agent：判断是普通问答、复杂推理、工具调用还是拒答。
retriever-agent：负责 BM25、向量检索、metadata filter。
reranker-agent：负责 cross-encoder、LLM rerank 或规则过滤。
answer-agent：只基于证据生成答案。
verifier-agent：检查引用是否支持结论。
fallback-agent：当证据不足时给出澄清问题或拒答。

RAG 多 Agent 的关键不是“多几个角色”，而是把检索、生成、验证解耦。否则 answer agent 一旦直接接触所有工具和所有文档，很容易出现证据污染和幻觉。

6. 一个可落地的多 Agent Runtime 设计

可以把 Agent Runtime 抽象成四层：

一个最小 Agent 定义可以这样设计：

Runtime 调用时要做权限拦截：

这个设计对应 OpenCode 的权限思想：不同 Agent 可以对编辑、bash、外部目录、web search、LSP、skill 等能力设置不同的 allow/ask/deny 策略。(OpenCode)

7. 多 Agent 的主要挑战与解决方案

7.1 上下文隔离：不要把所有东西广播给所有 Agent

多 Agent 最大的反模式是：

“把用户问题、所有工具结果、所有 Agent 对话、所有中间推理都塞给每个 Agent。”

这样做会导致上下文污染、成本膨胀和错误传播。

更好的做法：

每个 Agent 只拿到完成任务所需的最小上下文。Agent 输出结构化结果，而不是长篇自由文本。Supervisor 只转发结论、证据和必要上下文。子 Agent 默认独立 session，需要时再 fork 当前上下文。

OpenClaw 的 Sub-agents 默认运行在独立 session 中，只有在需要当前 transcript 时才 fork 上下文，这个设计很适合作为参考。(OpenClaw)

7.2 权限隔离：分析 Agent 不应该有写权限

一个常见事故是：用户只是想“分析一下”，Agent 却直接改了文件、执行了命令或触发了外部 API。

解决方案：

规划 Agent：只读。检索 Agent：只读 + web/search。执行 Agent：可写，但 bash 默认 ask。Review Agent：只读，禁止 edit。Webhook Agent：强限制工具，默认不允许危险操作。

OpenCode 的 plan agent 默认对文件编辑和 bash 命令要求确认，正是这种权限隔离的体现。(OpenCode)

7.3 通信协议：自然语言聊天不是可靠协议

Agent 之间如果只靠自然语言聊天，很容易出现：

“我以为你已经做了。”
“你说的完成是指计划完成还是代码完成？”
“这个风险是 blocker 还是 warning？”

建议使用结构化 schema：

Supervisor 只接收这种结构，不直接接收大段散文。

7.4 成本与延迟：并行 Agent 会吞 token

多 Agent 不是免费午餐。OpenClaw 文档也提醒，每个 sub-agent 默认有自己的 context 和 token usage，重任务可以给子代理设置更便宜的模型，把主 Agent 保持在高质量模型上。(OpenClaw)

建议：

Router 用小模型。Explore / Scout 用快模型。Build / Review 用强模型。Judge 用低温强推理模型。并行任务设置 max steps 和 timeout。对重复检索结果做 cache。

7.5 结果冲突：多个 Agent 结论不一致怎么办？

不要让最后一个 Agent “凭感觉综合”。应该显式保留冲突：

当冲突涉及高风险操作，比如删除数据、修改权限、执行部署，应回退到 human-in-the-loop。Microsoft Agent Framework 文档中也展示了 plan review、tool approval、stall intervention 等人类介入机制。(Microsoft Learn)

7.6 安全：多 Agent 会放大攻击面

多 Agent 系统的攻击面比单 Agent 大：

一个 Agent 读到恶意文档。另一个 Agent 把恶意内容当指令执行。Webhook payload 注入 prompt。子 Agent 获得了不该有的工具。共享记忆被污染。Gateway 或 node 被暴露到公网。

OpenClaw 安全文档明确提醒，Gateway 能对已配对节点执行系统命令时，本质上是远程代码执行，需要节点配对、命令策略、执行审批等控制；同时也提醒不要把 Gateway 未认证暴露在 0.0.0.0，webhook payload 要视为不可信输入。(OpenClaw)

安全建议：

默认 deny，高危工具 ask。子 Agent 不继承主 Agent 全部工具。工具调用前后记录审计日志。对外部文档和网页内容加“不可信内容”标签。Agent memory 写入前做过滤。sandbox 执行文件系统和命令。不同 trust boundary 用不同 Gateway 或不同运行环境。

8. 多 Agent 架构落地 checklist

设计多 Agent 系统前，可以先问这些问题：

任务是否真的需要多 Agent？
如果只是一个短任务，单 Agent + 工具可能更简单。

每个 Agent 的职责是否互斥？
如果两个 Agent 做同一件事，应该明确一个是执行者，一个是审查者，或一个是候选方案生成者，一个是裁判。

每个 Agent 的工具权限是否最小化？
只读 Agent 不应该拥有 edit/bash 权限。

Agent 之间传递什么？
传结论、证据、结构化状态，而不是完整聊天记录。

失败如何处理？
timeout、重试、降级、转人工、回滚都要设计。

如何观测？
每个 Agent 的输入、输出、工具调用、token、耗时、错误都要可追踪。

如何评测？
不只评估最终答案，还要评估路由准确率、检索召回率、工具调用正确率、review 命中率、成本和延迟。

9. 最佳实践总结

多 Agent 协作的成熟设计可以归纳为一句话：

用 Router 降低任务选择难度，用 Supervisor 控制长流程，用 Subagent 隔离上下文，用 Permission 限制工具风险，用 Reviewer 降低错误率，用 Memory 保留可追溯证据。

如果你要为 Agent、RAG 或 LLM 应用设计多 Agent 系统，建议从最小可控版本开始：

第一阶段只保留三个 Agent：

planner/explorer：只读，负责理解和检索。
builder：可写，负责执行。
reviewer：只读，负责审查和验证。

等这个闭环稳定后，再引入：

scout：查外部文档和依赖源码。
test-agent：运行测试和定位失败。
security-agent：安全审计。
doc-agent：更新文档。
ops-agent：处理部署、告警和 ChatOps。

最终你会得到一个不是“聊天机器人集合”，而是一个有边界、有权限、有观测、有评测的 Agent 协作系统。