该用一个 AI Agent，还是多个？

“帮我把这段会议记录整理成行动项表格。”这个任务，该用几个 Agent？

通常一个就够了。它依次读取文本、提取行动项并输出表格，清楚的任务说明和输出格式已经能约束整个过程。硬拆以后可能变成：

Agent A 负责读会议记录
Agent B 负责提取行动项
Agent C 负责检查格式
Agent D 负责总结风险

这套分工看起来挺完整，但对一个简单任务来说可能太复杂：每加一个 Agent，就多一次交接；交接内容说不清，信息就在半路丢了。

多 Agent，也就是 multi-agent，确实有用。拆分会增加沟通、交接和状态同步成本，效果需要实际验证：简单任务通常一个 Agent 就够；当职责、工具或风险边界差异明显，一个 Agent 难以兼顾时，再考虑拆分。先检查一个 Agent 能否稳定完成任务，出现问题后，再判断分工能否解决这个问题。

01 先从单个 Agent 开始

第一条原则：

一个 Agent 能稳定完成，就先用一个 Agent。

Anthropic 在《Building effective agents》里也建议先找最简单的方案，只在需要时才增加复杂度，这甚至可能意味着根本不用 Agentic 系统。

单个 Agent 出了错，先看过程记录，定位问题出在哪：

资料过期     -> 更新资料（拆了也还是读旧文件）
规则不清     -> 修正规则
职责互相干扰 -> 这才轮到分工

比如退款判断出错是因为政策文件过期，加一个售后 Agent 也可能继续读到同一份旧文件。

02 五种适合拆分的情况

出现下面几种情况时，可以考虑拆分。

第一，职责差异太大。客服系统里，一个任务是帮用户选商品，另一个任务是处理退款，两个任务的目标、语气、工具和风险完全不同。放在一个 Agent 里，它可能在推荐商品时误用退款工具，或者在退款场景里说营销话术。

第二，工具太多。一个 Agent 同时拥有商品搜索、订单查询、退款申请、库存更新、优惠券发放、客服升级等工具，选择工具的难度会变高。工具越多，它越难稳定选对工具和权限。

第三，指令太长。一个 Agent 同时承担销售、售后、技术支持、合规和财务规则时，指令会变长，关键边界也更难稳定执行。

第四，风险等级不同。普通咨询可以快速回答，退款、付款、合同承诺则需要严格确认。分开处理能让权限和检查强度匹配真实后果。

第五，模型能力和成本不同。任务有轻有重：

全部任务塞给同一个重型 Agent，速度和成本都不划算；复杂任务交给太轻的 Agent，质量又不够。分工有时就是为了把任务交给合适的处理者。拆开以后，每个角色的权限和越界风险也要重新设计，这是Agent 防护栏要解决的事。

03 多个 Agent 怎么协作

多 Agent 最常见的入口是路由 Agent：先判断用户意图，再把任务和必要上下文交给合适的专门 Agent。客服场景可以这样组织：

用户输入
  |
  v
路由 Agent：判断用户要买东西、查订单、退款，还是找技术支持
  |
  +-> 购物 Agent：推荐商品、比较选项
  |
  +-> 售后 Agent：查订单、判断退款条件
  |
  +-> 技术支持 Agent：排查使用问题

路由 Agent 像前台接待，负责把请求交给合适的处理者；具体业务由相应的专门角色处理。

任务分给不同角色以后，能不能同时开始？要看它们是否互相等待。两份资料各自独立，就可以并行检查，再交给明确的责任者汇总；退款判断要用订单查询结果，就得等查询完成再交接。并行检查也要针对同一任务对象，使用相同的判断标准：一方按旧政策、另一方按新政策检查，两份报告就不能直接合并，最终责任者要先列出冲突，请求核实。

还有一种停下来的原因：权限不足、风险超出授权，或问题无法判断。这时需要转人工，由有权限的人补齐这些条件。

04 每个角色说清五件事

角色名字只是个标签，真正决定它们能不能顺利协作的，是职责、输入和输出。每个 Agent 都要说清五件事：

它负责什么？
它不负责什么？
它可以使用哪些工具？
它什么时候接手？
它什么时候交回或交给别人？

例如售后 Agent：

边界清楚后，路由和交接更容易保持稳定，也能减少任务冲突和遗漏。

05 交接最容易丢信息

第一个常见错误是把“拆得多”当成“更高级”。一个简单写作任务，拆成选题、资料、写作、审校、润色五个 Agent，只会增加等待和计算成本。我更看重每个角色是否解决了实际问题。第二个错误是“每个 Agent 都能做所有事”：如果每个 Agent 都有全部工具、全部权限和类似指令，它们就会争抢任务，分工的价值也随之消失。

第三个错误是交接丢信息。接手者看到“交给售后”，还不知道用户问了什么、是哪笔订单、什么已经查过，只能重新询问，或冒着信息不全的风险判断。那把全部历史传过去呢？购物预算通常与这次退款无关，只有任务还包括换购时才可能用上。交接要围绕接手后的工作选信息，至少包含：

用户原始问题
已经确认的事实和当前状态
尚未解决的问题
需要下一个 Agent 做什么
不能越过的边界

例如：“用户申请订单 A 的退款；订单已收货；尚未核实适用政策；请售后查询政策并生成建议；未获人工确认前不得提交退款。”交接里的每句话还要保留来源。原记录是“用户说已收货”，交接里就照实写这一句，等系统确认后再改成“订单系统已确认收货”：

用户说已收货    -> 依据弱，可能要补查
系统确认已收货  -> 保留查询来源和时间，核对仍有效后使用

第四个错误是缺少最终责任者。多个 Agent 都参与了任务，还要有人检查最终结果是否一致、是否守住边界、能否交付，防止交接错误传到交付结果。