Agent丨单 Agent 和多 Agent 分别适用于哪些场景，如何判断是否需要多 Agent？

type

Post

status

Published

date

Apr 29, 2026

slug

agent23

summary

1. 先给判断标准：什么时候单 Agent 足够？

单 Agent 适合满足下面几个条件的任务：

任务需要一个连续的推理链路。
任务的上下文高度共享，拆开反而会丢信息。
任务的状态修改集中在同一个工作区、同一批文件、同一个业务对象上。
用户需要频繁交互、反复纠偏、边做边改。
成本、延迟、可控性比并行更重要。

Claude Code 官方文档在“何时选择主会话而不是 subagent”里也强调：如果任务需要频繁来回沟通、多阶段共享大量上下文、快速做一个有针对性的修改，或者延迟敏感，那么主会话更合适；subagent 会启动 fresh context，需要重新收集上下文，因此不是免费的抽象。(Claude Code)

单 Agent 典型流程

这种结构的优势是简单、直接、低成本。对于大多数业务问答、普通 RAG、简单代码修改、单模块 Debug、单流程自动化，单 Agent 往往是最佳起点。

2. 什么情况下应该考虑多 Agent？

多 Agent 不是“多个 Prompt 文件”的堆叠，而是把一个任务拆成多个拥有独立上下文、独立职责、独立权限或独立执行生命周期的 Agent。Claude Code 文档把 subagent 的收益总结为上下文隔离、并行化、专门指令和工具限制；这些正是判断是否需要多 Agent 的四个核心维度。(Claude Code)

2.1 上下文隔离：避免主上下文被污染

当任务需要读取大量文件、日志、文档、测试输出，但最终主流程只需要一个摘要时，应该考虑 subagent。

例如：

主 Agent：负责用户交互和最终决策。
Research Agent：大量搜索代码、日志、外部文档。
Test Agent：运行测试并只返回失败摘要。
Review Agent：只读代码并返回风险点。

Claude Code 的 subagent 会在 fresh conversation 中运行，中间工具调用和结果保留在 subagent 内部，父 Agent 只接收最终消息；这可以避免大量搜索、测试、日志输出堆进主上下文。(Claude Code)

2.2 并行探索：子任务之间相互独立

如果一个问题可以被拆成多个互不依赖的方向，例如“前端、后端、数据库、测试”分别排查，或者“三种假设并行验证”，多 Agent 才有明显收益。

Claude Code 的 agent teams 文档也指出，Agent team 更适合并行探索、多个 teammate 研究不同方面、调试不同假设、跨前后端和测试的独立工作；但它也明确提醒：agent teams 有协调开销和更高 token 成本，不适合强顺序依赖、同文件编辑或高度耦合的任务。(Claude Code)

2.3 专业化角色：不同 Agent 拥有不同模型、Prompt、工具

OpenCode 的设计很典型：它有 primary agent，也有 subagent；内置 Build 是默认开发 Agent，Plan 是受限的分析规划 Agent，General、Explore、Scout 则分别服务于复杂多步任务、只读代码探索、外部依赖研究等场景。(OpenCode)

这说明一个成熟 Agent 系统不会让所有角色都拥有相同权限。比如：

Planner：只能读，不能写。
Explorer：只能搜索和读取代码。
Implementer：可以编辑文件。
Reviewer：只能审查，不允许修改。
Security Auditor：可以读取和 grep，但不能执行危险命令。
Dependency Scout：可以查外部依赖源码，但不能改本地工作区。

OpenCode 的 agent 配置支持 mode、model、prompt、permission 等字段；官方示例里 code-reviewer 可以配置为 mode: "subagent"，并通过 permission 禁止 edit。(OpenCode)

2.4 权限隔离：最小权限原则

多 Agent 的一个生产级价值是降低工具调用风险。Claude Code 支持给 subagent 限制可用工具，也支持 permission modes；OpenCode 支持 per-agent permission，并且可以对 edit、bash、webfetch、task 等权限设置 allow、ask、deny。(Claude Code)

这类场景特别适合多 Agent：

代码审查 Agent：只读，不写。
数据库 Agent：只允许读查询，不允许写库。
发布 Agent：必须人工审批。
文档 Agent：只能改 docs 目录。
安全 Agent：禁止访问外部网络，避免把敏感信息带出去。

2.5 多租户或多身份：不是 subagent，而是“多个完整 Agent”

OpenClaw 的多 Agent 更偏 Gateway 和运行时隔离。它的 multi-agent routing 文档定义了“一个 Agent”是完整 persona scope：workspace、auth profiles、model registry、session store 等；不同 channel account 或 peer 可以通过 binding 路由到不同 Agent。(OpenClaw)

这类场景不是“一个主 Agent 叫几个 subagent”，而是需要多个完整 Agent：

一个家庭网关里，工作助手和生活助手隔离。
一个企业 Gateway 里，不同 Slack workspace、Discord server、WhatsApp 号码路由到不同 Agent。
不同用户、不同团队、不同客户不能共享记忆、会话、认证配置。
每个 Agent 有自己的 workspace、SOUL.md / AGENTS.md / USER.md、session history。

OpenClaw 默认是单 Agent，agentId 为 main；只有当你显式添加 Agent、配置 bindings，才进入多 Agent 路由模式。(OpenClaw)

3. 单 Agent vs 多 Agent 场景对照

判断维度	单 Agent 更适合	多 Agent 更适合
上下文	所有步骤共享同一上下文	子任务上下文很大，应该隔离
执行方式	强顺序、一步依赖一步	可并行探索、互不阻塞
用户交互	用户频繁纠偏	子任务可独立完成后汇报
工具权限	权限统一、风险较低	不同角色需要不同权限
成本延迟	成本敏感、低延迟优先	愿意用更多 token 换并行和质量
任务边界	修改同一文件、同一对象	前端/后端/测试/安全等边界清晰
记忆隔离	共享同一记忆即可	多用户、多身份、多 workspace 隔离
失败恢复	单流程可回滚	每个 Agent 需要独立日志和状态

一句话判断：

如果只是“复杂”，先用单 Agent。如果复杂性来自“可隔离、可并行、可授权、可审查、可路由”，再用多 Agent。

4. 从 Claude Code 看：Subagent 是“隔离上下文 + 专门工具”的轻量多 Agent

Claude Code 的 Agent SDK 支持用 agents 参数定义 subagent，每个 AgentDefinition 可以有 description、prompt、tools、model、skills、memory、mcpServers、maxTurns、background、permissionMode 等字段；Claude 会根据 description 自动决定是否调用，也可以显式指定某个 subagent。(Claude Code)

下面是一个改写后的代码级抽象：

这段代码体现了多 Agent 的几个关键原则：

description 决定“什么时候用”。
prompt 决定“怎么做”。
tools 决定“能做什么”。
model 决定“用多强的模型做”。
主 Agent 只负责分派、汇总和最终决策。

不过，Claude Code 文档也明确指出，subagent 默认 fresh context，不会看到父会话完整历史；父到子的唯一通道是 Agent 工具传入的 prompt，所以文件路径、错误信息、决策背景必须显式传进去。(Claude Code)

5. 从 OpenCode 看：Primary Agent 与 Subagent 是两种不同入口

OpenCode 的设计特别适合作为“如何拆 Agent”的参考。它把 Agent 分成两类：

Primary agents：用户直接交互的主 Agent，可以通过 Tab 或快捷键切换。
Subagents：由 primary agent 调用，或者由用户通过 @ mention 手动调用。(OpenCode)

OpenCode 还内置了 Build、Plan、General、Explore、Scout 等 Agent。Build 用于完整开发工作，Plan 默认对编辑和 Bash 设置 ask，Explore 是只读代码探索，Scout 用于外部依赖研究。(OpenCode)

一个工程化配置可以这样写：

这个配置体现出一个重要经验：多 Agent 不只是多几个角色名，而是每个角色都要有不同的权限、模型、上下文和交付物。 OpenCode 文档也建议使用 permission 字段做更细粒度控制，并说明 mode 可设置为 primary、subagent 或 all。(OpenCode)

6. 从 OpenClaw 看：多 Agent 不只是协作，也是路由和隔离

OpenClaw 的多 Agent 模式更接近“多租户 Agent 网关”。它支持多个隔离 Agent，每个 Agent 拥有自己的 workspace、agentDir、session history，入站消息通过 bindings 路由到正确 Agent。(OpenClaw)

一个简化版 OpenClaw 多 Agent 路由配置可以这样理解：

OpenClaw 文档还强调，多 Agent 可以对应不同账号、不同人格、独立认证和独立会话，避免 cross-talk；但 workspace 并不是天然强沙箱，绝对路径仍可能访问主机其他位置，强隔离需要启用 sandbox 或使用不同 OS 用户 / 主机。(OpenClaw)

7. 多 Agent 的三种模式

7.1 主 Agent + 专家 Subagent

这是最常见、最推荐的起点。

适用于：

代码审查。
RAG 多源检索。
测试失败分析。
安全扫描。
文档生成前的资料收集。
主 Agent 不想被大量中间信息污染的场景。

7.2 Agent Team：多个 Agent 平等协作

Claude Code 的 agent teams 允许多个 Claude Code 实例组成团队，一个 lead 负责任务分配和综合，teammates 各有独立上下文，并且可以相互通信；官方也说明它比 subagent 更适合需要讨论、挑战和自协调的复杂任务，但 token 成本更高，且是 experimental。(Claude Code)

适用于：

新模块设计。
多方案辩论。
多假设 Debug。
大型重构前的并行调研。
前端、后端、测试、安全可以相对独立推进的任务。

不适用于：

强顺序任务。
所有 Agent 都要改同一个文件。
每一步都依赖上一步细节。
预算紧张或延迟敏感。
责任边界不清，最后没人知道该听谁的。

7.3 多 Agent 网关：多个独立人格 / 用户 / 工作区

这是 OpenClaw 代表的模式。它不是为了“一个任务多人干”，而是为了“一个系统服务多个上下文、多个入口、多个身份”。OpenClaw 的 Gateway 可以拥有多个 channel 和多个 Agent，通过 binding 做确定性路由，并支持多账号或多 peer 路由。(OpenClaw)

适用于：

多用户个人助手。
企业内部多个团队共用一个 Gateway。
每个客户一个独立 Agent。
每个频道、账号、手机号对应不同 Agent。
工作记忆和生活记忆必须隔离。
不同 Agent 使用不同模型、不同工具、不同认证配置。

8. 如何判断是否需要多 Agent：五步决策法

第一步：任务能否自然拆分？

如果子任务之间强依赖，就不要拆。比如“读取一个函数 → 修改一行 → 运行一次测试”更适合单 Agent。

如果可以拆成独立方向，例如“认证模块安全审查、数据库性能审查、前端表单校验审查”，可以考虑多 Agent。

第二步：拆分后是否减少主上下文压力？

如果 subagent 只是把同样的信息复制一份，那没有价值。

如果 subagent 可以消化大量日志、搜索结果、文档、测试输出，只返回压缩摘要，就有价值。

Claude Code 文档明确把“隔离高输出量操作”作为 subagent 的常见模式，例如运行测试、获取文档、处理日志，并只把相关摘要返回主会话。(Claude Code)

第三步：不同角色是否需要不同工具权限？

如果所有角色都需要完整读写权限，多 Agent 的安全价值会下降。

如果可以做到：

Explorer 只读。
Reviewer 禁止编辑。
Test Runner 允许 Bash。
Implementer 允许 Edit。
Release Agent 必须 ask。

那么多 Agent 很值得做。

第四步：是否真的能并行？

并行的前提是子任务之间没有强共享状态。Claude Code agent teams 文档也强调：团队适合 parallel exploration，且 teammate 最好能独立工作；对于顺序任务、同文件编辑或大量依赖关系，单会话或 subagent 更有效。(Claude Code)

第五步：协调成本是否低于收益？

多 Agent 的成本包括：

更多 token。
更多上下文初始化。
更多工具调用。
更多失败模式。
更多权限配置。
更多结果综合。
更多冲突处理。

OpenClaw 的 subagent 文档也提醒，每个 sub-agent 默认有自己的 context 和 token usage；重任务或重复任务可以给 subagent 配更便宜的模型。(OpenClaw)

9. 一个实用评分模型

可以用下面的方式快速判断：

维度	问题	分数
上下文隔离	子任务会产生大量中间信息吗？	0 / 1 / 2
并行性	子任务能独立推进吗？	0 / 1 / 2
权限差异	不同角色需要不同工具权限吗？	0 / 1 / 2
专业差异	不同角色需要不同 Prompt / 模型吗？	0 / 1 / 2
状态隔离	是否涉及多用户、多 workspace、多账号？	0 / 1 / 2
评审需求	是否需要独立 reviewer / critic / verifier？	0 / 1 / 2
协调成本	拆分后是否容易冲突？	-2 / -1 / 0

总分 0～2：优先单 Agent。
总分 3～5：单 Agent + 少量 subagent。
总分 6～8：主 Agent + 多个专家 subagent。
总分 9 以上：考虑 Agent team 或多 Agent Gateway。
如果“协调成本”为 -2，除非有强隔离需求，否则不要上复杂多 Agent。

10. 多 Agent 的常见反模式

反模式一：按岗位名机械拆分

很多系统会拆出 PM Agent、Architect Agent、Developer Agent、Tester Agent、Reviewer Agent，但它们都读同一批上下文、调用同样工具、输出同样建议。这样只会增加 token 和冲突。

正确做法是：

先定义产物边界。
再定义权限边界。
最后才定义角色名字。

反模式二：让所有 Agent 都能写文件

如果所有 Agent 都有写权限，就很容易出现覆盖、重复修改、风格不一致、状态竞争。OpenCode 的 Plan / Build 分离很有借鉴意义：Plan 可以分析和建议，但默认不修改代码；Build 才是开发执行入口。(OpenCode)

反模式三：嵌套过深

OpenClaw 支持 nested sub-agents，但默认 sub-agent 不能再 spawn 子 Agent；文档建议一般 depth 2 就足够，并且有 maxChildren、maxConcurrent 等限制。(OpenClaw)

过深嵌套会导致：

任务失控。
错误难追踪。
token 成本暴涨。
父子 Agent 指令冲突。
最终结果难归因。

反模式四：把“可复用提示词”误做成 Agent

如果只是想复用某种写作规范、代码风格、测试规则，不一定需要 subagent。Claude Code 文档也提醒：如果你想要的是在主会话上下文中复用 prompt 或 workflow，可以考虑 Skills，而不是隔离 subagent。(Claude Code)

11. 生产级多 Agent 推荐架构

一个相对稳妥的生产级架构如下：

关键点：

Orchestrator 不直接做所有事，而是负责拆解、路由、汇总和最终责任。
Explorer / Reviewer 默认只读。
Test Runner 允许有限 Bash。
Implementer 是少数有写权限的 Agent。
Quality Gate 应该尽量确定性，例如 lint、test、typecheck、policy check。
所有 Agent 输出都必须带证据，而不是只给结论。
主 Agent 对用户负责，subagent 输出只是证据，不是最终指令。

OpenClaw subagent 文档也有类似的安全边界：child output 是给 requester agent 综合的 report/evidence，不是用户指令，不能覆盖系统、开发者或用户策略。(OpenClaw)

12. 一个可落地的多 Agent 任务拆分模板

假设用户需求是：

“帮我重构支付模块，提升可维护性，并保证不破坏现有测试。”

可以拆成：

Agent	职责	权限	输出
Orchestrator	拆任务、调度、综合	Agent 调用、读	最终方案
Explorer	读取支付模块结构	Read / Grep / Glob	模块地图
Test Runner	跑现有测试	Bash / Read	失败摘要
Refactor Planner	设计重构方案	Read	分阶段计划
Implementer	执行小步修改	Edit / Read / Bash ask	Patch
Reviewer	审查回归风险	Read / Grep	风险清单

流程如下：

13. RAG 场景下：什么时候需要多 Agent？

RAG 默认不一定需要多 Agent。大部分问答场景，一个 Agent 加检索、重排、引用、答案生成已经足够。

需要多 Agent 的 RAG 场景通常是：

多源检索：代码库、文档库、工单、网页、数据库需要不同检索策略。
高风险答案：需要 Answer Agent + Critic Agent + Citation Verifier。
长文档分析：每个 Agent 负责一个章节或一个知识库分片。
时效性判断：一个 Agent 负责检索，一个 Agent 负责判断资料新旧和可用性。
权限隔离：不同数据源有不同访问权限，不能让同一个 Agent 混用所有数据。

一个 RAG 多 Agent 架构可以这样设计：

判断原则仍然一样：如果多 Agent 只是“多个检索器重复搜同一个库”，没有必要；如果它们对应不同数据源、不同权限、不同验证责任，就有价值。

14. 最终建议：从单 Agent 演进到多 Agent，而不是一开始就多 Agent

生产落地时推荐这个演进路径：

第一阶段：单 Agent + 工具调用。
第二阶段：单 Agent + 明确权限控制。
第三阶段：把高噪声任务拆成 read-only subagent。
第四阶段：加入 Test Runner / Reviewer 等验证型 subagent。
第五阶段：只有当并行收益明显时，再引入 Agent team。
第六阶段：当涉及多用户、多账号、多工作区时，再引入 OpenClaw 式多 Agent Gateway。

这也符合 Claude Code、OpenCode、OpenClaw 的共同经验：多 Agent 真正解决的是隔离、并行、权限、路由和验证，不是“让系统看起来更智能”。单 Agent 是默认，subagent 是局部优化，agent team 是复杂协作，多 Agent Gateway 是多租户和多通道路由。(Claude Code)

15. 一句话收尾

单 Agent 解决连续推理，多 Agent 解决工程边界。
当问题只是难，先增强单 Agent；当问题出现上下文污染、权限差异、可并行子任务、独立评审、多用户隔离时，再引入多 Agent。