从能跑到可交付：单 Agent 与多 Agent 的架构取舍

开发 AI Agent，到底用单 Agent 还是多 Agent？拆分依据是什么

★先证明边界存在，再证明拆分有收益。

读者定位：本文面向正在设计或评审 Agent 系统的开发者、架构师，以及准备相关技术面试的同学。

下面这个场景，是我把多个 Agent 项目里常见的评审争论、工具误选和上下文丢失，压缩成的一次合成现场——它不是某一次真实事故，但折射出的问题非常真实：

投影上的 Trace 停在第七次模型调用。

用户原话只有一句：

★查下订单，没发货就取消，优惠券能退的话一起退。

负责售后 Agent 的开发同学把链路继续往下拉：调度 Agent 先调用订单 Agent，订单 Agent 把任务转给退款 Agent，退款 Agent 又回来确认订单状态；优惠券 Agent 没拿到前面的用户身份，只能重新索要参数；最后回复 Agent 收到五段互相重复的结果，还得自己猜哪个才是最终状态。

会议室里没人说话。

第一版明明只有一个 Agent。它挂载了十几个工具，其中订单、退款、优惠券、风控、回复这五类职责语义重叠，偶尔会选错接口。为了「职责清晰」，第二版被拆成了意图识别、订单、退款、优惠券、风控、回复六个 Agent，外面再套一个调度 Agent。

架构图确实更漂亮了。

但同一个请求，原来是一个 Agent 偶尔选错工具，现在变成六个 Agent 稳定地互相解释。

评审里有人试探着问：「是不是还缺一个专门管理上下文的 Agent？」

屏幕前的开发同学把两版链路并排放好，只问了一句：

★我们究竟是在拆能力，还是在拆一张好看的架构图？

这个问题非常真实：开发 AI Agent，到底该用单 Agent，还是多 Agent？

先说结论：Agent 数量不是复杂度勋章

我的判断很直接：

默认先做单 Agent。只有同时满足两个条件，才考虑拆成多 Agent——存在稳定、可描述的任务边界；拆分带来的收益，经过评估能覆盖协调成本。这两个条件缺一个都不行。

业务复杂，不等于需要多个 Agent。

流程很长，不等于需要多个 Agent。

系统里有多个「角色」，更不等于每个角色都要变成 Agent。

OpenAI 在其官方指南《A Practical Guide to Building Agents》的「When to use multiple agents」一节给出的建议也是：先尽量扩展单 Agent 的能力。真正需要拆分的信号，主要是两类：复杂条件越来越难让一个 Prompt 稳定遵守；工具相似或重叠，导致模型持续选错工具，而且通过工具命名、参数和描述优化仍然解决不了。

注意，这个判断里没有「我的业务有六个部门，所以要做六个 Agent」。

因为 Agent 的边界，不该从组织架构图里抄。

别急着拆：很多所谓的多 Agent，其实只是多步骤工作流

先分清三个东西：工具、工作流和 Agent。

工具：执行一个边界明确的动作，例如查询订单、发起退款
工作流：按规则连接多个步骤，例如查询成功后再判断是否退款
Agent：面对不确定输入，自主选择下一步动作，并根据结果调整计划

如果订单状态是 SHIPPED 就拒绝取消，这是业务规则，不需要一个「订单状态判断 Agent」。

如果金额超过 5000 元必须人工审批，这是控制规则，也不该交给一个「审批 Agent」自由发挥。

下面这种流程虽然有很多节点，本质上仍然是确定性工作流：

def cancel_order(request):
    order = get_order(request.order_id)

    if order.user_id != request.user_id:
        raise PermissionError("order does not belong to current user")

    if order.status == "SHIPPED":
        return reject("order has already shipped")

    if order.amount >= 5000:
        return create_human_approval(order)

    return execute_cancel(order)

这里需要模型做的，通常只需完成意图与参数抽取。权限、状态、金额、审批这些边界，代码比 Agent 更可靠，也更容易测试。

能用规则画清楚的路径，先写成工作流；只有规则无法提前穷举、执行过程需要根据新信息动态调整时，才把决策交给 Agent。

所以第一道选择题不是「单 Agent 还是多 Agent」，而是：

★这一步到底需不需要 Agent？

很多团队跳过了这道题，后面的架构自然越做越重。

真正的拆分依据，不是角色，而是四种独立性

一个「研究员」、一个「分析师」、一个「审核员」，这叫角色命名，不叫架构边界。

我更建议从四种独立性判断：上下文能否独立、能力与权限能否独立、任务能否独立执行、结果能否独立验收。

只有边界足够独立，拆分才会减少复杂度。否则，你只是把一个大 Prompt，变成了多个 Agent 之间的大段转述。

第一层：上下文能不能独立

单 Agent 最常见的问题，不是模型不够聪明，而是上下文越来越脏。

一个企业助手同时挂着财务制度、运维手册、销售话术、合同模板和二十多个工具。每次请求都把这些内容塞进同一个上下文，模型就要不断判断：当前应该相信哪套规则，哪些工具与任务有关，哪些历史信息已经失效。

这时候，先别急着上多 Agent。可以先做动态上下文和动态工具集：

def build_runtime(intent, user):
    return AgentRuntime(
        instructions=prompt_registry.for_intent(intent),
        tools=tool_registry.allowed_for(intent, user.roles),
        knowledge=knowledge_registry.for_domain(intent.domain),
    )

它还是一个 Agent，只是每次只加载当前任务需要的 Prompt、知识和工具。

LangChain 官方文档的 Multi-agent 章节把这类做法称为 Skills 模式：单 Agent 保持控制权，需要时再加载专业上下文。它解决的是上下文选择问题，不一定需要引入多个自治实体。

什么时候才值得拆？

当两个领域需要长期携带大量、相互无关甚至互相冲突的上下文，而且无法通过按需加载稳定隔离时，可以拆成不同 Agent。

例如：

• 合同审查需要完整法务条款、风险规则和引用证据
• 生产排障需要拓扑、日志、指标和只读运维工具
• 两者几乎不共享推理过程，只交换结构化结论

这时拆分能把无关信息挡在上下文之外。

反过来，如果子 Agent 仍然需要完整聊天记录、全部业务文档和所有工具才能工作，它就没有真正的上下文边界。如果拆完以后每个 Agent 还得背着同一只大书包，拆分基本没有价值。

第二层：工具和权限能不能独立

工具多，不是拆分的充分条件。

OpenAI 的指南特别强调，真正容易让模型出错的，不只是工具数量，而是工具之间是否相似、重叠。十几个命名清楚、参数差异明显的工具，一个 Agent 也可能管理得很好；几个语义接近的工具，反而会让模型反复误选。

比如：

cancel_order
close_order
terminate_order
apply_refund
refund_order

如果这些工具的适用状态、权限和副作用没有写清楚，拆成五个 Agent 也只是把歧义搬了家。

先做低成本治理：

• 合并语义重复的工具
• 给工具写清适用条件、禁止条件和副作用
• 使用结构化参数，减少自由文本
• 根据用户权限和任务阶段动态暴露工具
• 把业务校验放在工具内部，不相信模型自觉遵守

判据是：只有当两个工具集有明确不同的权限域、失败策略和负责人，且上述低成本治理仍无法消除误判时，才值得拆成不同 Agent。否则，拆开只是把歧义从一个大 Prompt，搬进多个 Agent 之间的转述。

例如生产运维 Agent 只能读日志和触发预案，财务 Agent 可以查账但不能操作基础设施。拆开后，每个 Agent 拿到的凭证、工具和安全策略都不同。

这不是为了模拟两个职业，而是为了形成两个可审计的权限边界。

第三层：任务能不能独立执行，尤其是并行执行

多 Agent 最容易兑现的收益，不是「集体智慧」，而是并行。

Anthropic 在其工程博客《How We Built Our Multi-Agent Research System》中复盘：这种架构特别适合广度优先、可以沿多个独立方向同时探索的研究任务。多个子 Agent 使用各自的上下文并行检索，主 Agent 最后汇总结果。

例如用户问：

比较三家云厂商在模型托管、向量检索、权限治理和成本方面的方案。

四个维度可以相对独立地调查，适合并行扇出：

                 -> 模型托管 Agent  --\
用户 -> 主 Agent -> 向量检索 Agent  ----> 证据合并 -> 最终报告
                 -> 权限治理 Agent  ----/
                 -> 成本分析 Agent  --/

但「先查订单，再根据订单状态决定能否退款，成功后返还优惠券」不是并行任务。后一步依赖前一步的真实结果，强行拆成多个并行 Agent，只会增加状态同步和冲突处理。

一个很实用的判断是：

★子任务能否在拿到一份有限输入后独立完成，并返回一份结构化结果？

如果能，而且多个子任务之间没有写冲突，就适合并行。

如果不能，每个 Agent 都在等待别人的半成品，或者多个 Agent 可能同时修改同一订单、同一文件、同一数据库记录（即发生写冲突 / write contention），就要谨慎。此时确定性的串行工作流，通常比多 Agent 群聊更稳。

Anthropic 的同一篇文章也给出了很现实的边界：他们的多 Agent research 系统在内部评估中对特定研究任务效果显著，但消耗的 Token 约为普通对话的 15 倍。这个数字不是所有业务的通用倍率，却说明一件事：并行能力不是免费的。

第四层：结果能不能独立验收

这是最容易被忽略的一层。

你准备把一个任务交给子 Agent 时，能不能说清楚下面这些内容？

from dataclasses import dataclass

@dataclass
class AgentTask:
    objective: str
    context_refs: list[str]
    allowed_tools: list[str]
    output_schema: dict
    acceptance_criteria: list[str]
    max_steps: int
    token_budget: int

一个合格的子任务，至少要有：

• 明确目标，而不是「你自己看着办」
• 最小必要上下文，而不是整段历史全部转发
• 可用工具和禁止动作
• 结构化输出协议
• 可检查的完成条件
• 步数、时间和 Token 预算

代码不重要，契约才重要。

如果任务完成与否只能靠主 Agent 看完一大段自然语言再凭感觉判断，那么这个边界还不成熟。拆分后很容易出现重复劳动、遗漏和无限转交。Anthropic 在多 Agent 系统的实践中也强调，主 Agent 给子 Agent 的任务必须包含目标、输出格式、工具与来源指引，以及明确边界。指令太模糊，子 Agent 就会做重复搜索，或者各自理解成完全不同的问题。

不能独立验收的任务，通常也不适合独立成 Agent。

什么时候单 Agent 更合适

把上面的判断压缩一下，下面这些场景优先选单 Agent：

典型例子包括订单客服、内部知识问答、单仓库代码助手、表单处理、标准审批辅助。

这里的「单 Agent」不等于一个巨型 Prompt 加所有工具。

成熟的单 Agent 仍然可以有工作流、状态机、动态工具、记忆分层、人工审批和多个普通服务。只是最终的自主决策中心只有一个。

什么时候多 Agent 才开始划算

下面这些信号同时出现三项及以上，多 Agent 才可能值得：

典型例子包括跨领域深度研究、多个代码仓库的并行分析、跨法务与财务的材料审查、复杂事件中多个只读调查面的并行取证。

但即使决定用多 Agent，也不要默认让所有 Agent 在群里自由讨论。

拆完以后，选哪种多 Agent 结构

多 Agent 不是一种架构，而是一组不同的协调模式。

| 模式 | 适合场景 | 最大风险 | |---|---| | Manager + Subagents | 一个入口，主 Agent 分派并汇总多个独立子任务 | 主 Agent 成为瓶颈，汇总时丢信息 | | Router | 一开始就能判断请求属于哪个专业域 | 路由错误会把整条链路送错地方 | | Handoff | 处理过程中才发现需要哪个专家，用户与接手者继续对话 | 来回转交、状态丢失、无限循环 | | Concurrent | 多个独立视角可以同时处理同一输入 | 结果冲突，需要明确合并规则 | | Sequential | 每一阶段有不同专业上下文和明确输入输出 | 前序错误逐级放大，没有并行收益 | | Maker-Checker | 产出物有客观验收标准，需要生成与审查分离 | 没有停止条件时会反复修改 |

OpenAI 把常见多 Agent 结构概括为两类（见其指南「Common patterns」一节）：Manager 通过工具调用多个专业 Agent；或者 Agent 之间通过 handoff 转移执行权。Microsoft Azure Architecture Center 的「AI Agent Orchestration Patterns」则进一步区分了顺序、并发、群聊、handoff 和动态规划等模式，并明确列出了各自不适用的场景。

选择模式时，先问谁拥有最终状态和最终决定权。

• 需要统一用户体验和集中控制，用 Manager
• 一开始就能分类，优先用 Router，甚至直接用代码路由
• 只有执行中才知道该找谁，用 Handoff
• 子任务彼此独立，用 Concurrent
• 依赖关系固定，用确定性 Sequential Workflow
• 有明确质量标准，用带次数上限的 Maker-Checker

大多数业务系统真正需要的是「一个主 Agent + 少量受控子 Agent + 大量确定性代码」，而不是一群 Agent 自由聊天。

工程上怎么落地：先做失败归因，再做架构拆分

不要在白板上凭感觉决定 Agent 数量。

我更建议按下面六步做。

第一步，先做一个可评估的单 Agent 基线

至少准备一组来自真实业务分布的测试任务，记录：

• 任务成功率
• 工具选择准确率
• 最终答案正确率
• 人工接管率
• 总模型调用次数与 Token
• P50、P95 延迟
• 高风险动作拦截率

没有基线，多 Agent 做完以后「感觉更聪明」，没有任何意义。

第二步，从 Trace 里给失败分类

不要把所有失败都归因于模型能力。

只有失败稳定集中在某个边界上，拆分才有目标。

第三步，先试比多 Agent 更便宜的方案

顺序通常是：

优化工具定义
  -> 动态工具集
  -> 动态 Prompt / Skills
  -> 结构化状态与确定性工作流
  -> 单个专业子 Agent
  -> 多 Agent 编排

这不是说多 Agent 不高级，而是每向后走一步，评估、观测、重试、权限和成本治理都会更复杂。

第四步，一次只拆一个边界

不要从一个 Agent 一口气拆成七个。

先挑证据最强的边界。例如 Trace 显示，合同检索长期污染订单工具选择，那就只把合同审查拆成一个受限子 Agent，其他能力先不动。

这样你才能判断收益到底来自哪里。

第五步，把 Agent 间通信变成协议

子 Agent 不要返回一篇小作文。返回结构化结果：

{
  "taskId": "contract-risk-1024",
"status": "completed",
"findings": [
    {
      "clause": "8.2",
      "riskLevel": "high",
      "reason": "缺少责任上限",
      "evidenceRef": "doc://contract/8.2"
    }
  ],
"uncertainties": [],
"needsHumanReview": true
}

主 Agent 拿到的是可验证的状态，不是另一个模型的情绪稳定版散文。

第六步，用同一套任务做 A/B 评估

多 Agent 至少要证明一项核心收益，同时不能让其他指标失控。

可以用一个很朴素的式子做评审：

拆分净收益
= 质量提升 + 并行节省时间 + 上下文隔离收益 + 权限隔离收益
- 路由错误 - 信息损失 - 额外 Token - 额外运维复杂度

不需要真的把每一项换算成人民币，但必须拿数据讨论，而不是拿 Agent 数量讨论。

面试官追问：你的项目为什么用单 Agent，或者为什么拆成多 Agent

这道题最差的回答是：

★多 Agent 更专业，每个 Agent 各司其职，所以效果更好。

这句话没有边界，没有指标，也没有取舍。

更像工程师的回答可以这样说：

★我默认从单 Agent 开始，因为它的上下文、状态、评估和故障定位都更简单。先通过动态工具、Skills 和确定性工作流控制复杂度。 只有当 Trace 证明单 Agent 在稳定边界上失败，我才拆分。主要看四点：专业上下文是否需要隔离，工具和权限是否独立，子任务是否能并行或动态转交，输出能否单独验收。 拆分后我会用同一套评估集比较端到端成功率、工具与路由准确率、P95 延迟、Token 成本和人工接管率。如果质量收益覆盖不了协调成本，我会退回单 Agent。

面试官如果继续追问「多 Agent 怎么拆」，可以再补一句：

★我不会按岗位名称拆，而是按上下文、能力权限、执行依赖和验收协议拆。无法用一份短契约描述的子任务，不会独立成 Agent。

这就够了。

因为这说明你设计的不是一场模型角色扮演，而是一套可运行、可评估、可回滚的工程系统。

回到开头那条 Trace

评审最后，团队没有再加「上下文 Agent」。

他们先把五类语义重叠的售后工具（订单、退款、优惠券、风控、回复）合并成两个，把权限和订单状态校验放回业务服务；再按任务阶段动态暴露工具，只保留一个面向用户的主 Agent。

唯一被单独拆出去的，是可以并行执行、拥有独立知识库和输出协议的风险审查任务。

架构图从七个 Agent（六个专业 Agent 加一个调度）变成一个主 Agent、一个受控子 Agent，再加一条确定性订单工作流。

图没那么热闹了，Trace 反而终于能看懂。

所以，开发 AI Agent 用单 Agent 还是多 Agent，没有放之四海皆准的答案——它得回到你自己的 Trace 里找。

先证明边界存在，再证明拆分有收益。

否则所谓多 Agent，只是让多个模型一起承担一个本来就没想清楚的问题。

写在最后

如果这篇对你做 Agent 架构选型有帮助，欢迎点赞 / 收藏，也欢迎关注我，我会持续聊 Agent 工程里的真实取舍，而不是追热点名词。

你的项目现在用的是单 Agent 还是多 Agent？拆分时踩过哪些坑？评论区聊聊，我们一起把架构想清楚。