什么时候该用多 Agent？什么时候老老实实用一个强单体 Agent + 好的工具/工作流就够了？​

也就是：多 Agent 选型与落地决策篇。

前面几篇已经把 Agent 的铺开了：

• 讲清楚了什么才算真正的 Agent，而不是“会聊天的 LLM + RAG”；
• 拆了 5 大核心组件：意图解析、规划、工具、状态与记忆、评估与控制；
• 写了怎么给 Agent 安装技能（Tool 抽象、自动选工具、安全边界）；
• 也把状态持久化、回放、质量评估、多 Agent 协作模式（Parallel / Sequential / Router / Hierarchical 等）都过了一遍。

但实际落地时，你会发现另一个更现实的问题：

我这需求到底要不要搞多 Agent？
是不是一个「功能清晰的单体 Agent + 一些工具 + 一个工作流」就够了？

这篇文章就专门帮你解决这件事：

• 什么时候应该坚持用「单 Agent + 工具」；
• 什么时候值得为复杂场景引入「多 Agent 协作」；
• 引入多 Agent 后，工程上要多付出哪些成本，以及如何控制。

---

一、先统一一个判断框架：从这三个维度看选型

我自己在项目里做选型，会从三个维度来判断：

1. 任务复杂度：任务是否天然可分解成多个步骤/角色？
2. 领域/职责数量：需要多少种“专业能力”同时在线？
3. 非功能约束：延迟、成本、可观测性、团队维护成本能不能接受？

可以用一个简单的“选型矩阵”来给自己先打个分：

维度	典型特征	建议
任务复杂度	单轮问答、小型工具调用、无明显上下游依赖	单体 Agent + 工具
	长流程、多步骤、有规划-执行-评估闭环	考虑多 Agent / 工作流
领域/职责数量	1–2 种能力（比如 FAQ + 简单查询）	单体 Agent + 工具
	3 种以上明显不同专业（法律/财务/运维/代码）	多 Agent + 路由/层次结构
非功能约束	对延迟/资源极其敏感，人手有限，不易维护多套逻辑	优先单体方案
	追求可扩展性/可观测/可插拔，能接受多一点工程复杂度	可以引入多 Agent 架构

一句话心法：

能用“单体 Agent + 好的工具层 + 清晰工作流”搞定的，就不要一上来堆多 Agent。
多 Agent 是为「复杂任务 + 多专长 + 高可观测/高扩展性」服务的，而不是为了“看起来高级”。

---

二、哪些场景「单体 Agent + 工具」就够了？

先讲“克制”的一面，很多需求其实完全没必要上多 Agent。

2.1 FAQ / 知识问答 + 轻度查询

特征：

• 用户问的问题大多是 FAQ、操作指引、简单状态查询；
• 调用 1–2 个内部接口就能拿到答案；
• 没有很重的“多步骤推理”。

架构建议：

• 一个对外的「助手 Agent」入口；
• 底下挂一组工具：知识检索（RAG）、订单查询、工单查询等；
• 用一个简单的“轻量工作流”（if/else + 少量状态）衔接。

这种情况下，如果你上来就搞：

• Planner Agent；
• N 个 Worker Agent；
• Reviewer Agent；

基本就是过拟合架构，后续维护成本陡增。

2.2 单一领域的业务助手

比如：

• 只做“代码重构建议”的 Agent；
• 只做“日志解析 & 根因初判”的 Agent；
• 只做“产品配置生成”的 Agent。

特征：

• 任务类型比较单一；
• 工具相对集中（主要对接一个域的系统）；
• 不需要复杂的任务路由和跨领域协作。

这类需求最适合用你前面几篇里讲的模式：

• 单体 Agent；
• 工具抽象清晰（Tool + ToolRegistry）；
• 状态/回放/质量评估做扎实。

2.3 对延迟和成本极其敏感的路径

有些路径对延迟/成本要求极高，比如：

• 用户实时互动的前台接口（APP 首页推荐、搜索提示）；
• 高 QPS 的公共服务。

多 Agent 典型问题是：

• 多轮 LLM 调用 ⇒ 延迟叠加；
• 多个 Agent 并行/串行 ⇒ token+工具调用成本增加；
• 管理和监控更复杂。

在这些路径上，可以优先用：

• 单体 Agent + 固定工作流；
• 或者甚至只是“ReAct + 工具”。

---

三、什么时候多 Agent 是「物有所值」？

再看另一面：如果你满足下面这些条件，多 Agent 通常就很划算。

3.1 天然「多角色」的任务

例如：

• 运维排障流程
  • 观测/拉数：抓指标/日志；
  • 诊断：分析原因；
  • 决策：决定是否要执行修复动作；
  • 执行：具体扩容/重启/回滚；
  • 复盘：记录报告。

这里每一步的输入输出形态完全不同，逻辑关注点也不一样。把所有逻辑塞进一个 Agent，会变成一个巨大无比的 Prompt + 一堆 if/else 分支，既难维护，又难观测。

更合理的做法：

• 观测 Agent（Metrics/Logs Inspector）
• 诊断 Agent（Root Cause Analyzer）
• 决策 Agent（Change Approver / Risk Evaluator）
• 执行 Agent（Executor / Runbook Runner）
• 复盘 Agent（Reporter）

再用一个调度/编排层把他们串起来（LangGraph / 自研工作流）。

3.2 明显的「多领域专家」需求

比如一个“企业超级助手”：

• 能回答 HR 政策（假期、报销规则）；
• 能回答法务问题（合同条款解释、风险提示）；
• 能回答财务相关（预算、成本结构）；
• 还能处理技术/运维问题（接口错误、告警分析）。

尽管理论上你可以训练一个“无所不能”的大模型，但从工程与安全角度，更实际的做法是：

• 专门一个 HR Agent（接 HR 系统 + 内部规则库）；
• 一个 Legal Agent（接法务规则、风险库）；
• 一个 Finance Agent（接报表/预算系统）；
• 一个 Ops Agent（接监控/日志/自愈系统）；
• 外面再包一层 Router / Orchestrator Agent 做路由与编排。

这样做的好处：

• 安全边界清晰：不同 Agent 掌握不同权限；
• 数据隔离清晰：HR 看不到法务私密数据，反之亦然；
• 优化更容易：某个域表现不好，就只调那个域的 Agent 和工具。

3.3 要求「可插拔扩展」的中台类系统

如果你的系统未来有这样的需求：

• 频繁接入新能力（比如新业务线、新系统）；
• 不同业务线希望自定义自己的「Agent 套餐」；
• 平台方不希望每次改动都动到一个巨大的单体 Agent。

那从一开始就用「多 Agent + 清晰边界 + 注册/调度机制」去设计，会比后来从单体 Agent 硬拆省很多痛苦。

也就是说：

如果你的系统定位本身就是「Agent 平台 / Agent 中台」而不是“一个具体场景的智能助手”，
早一点上多 Agent 架构，长期更划算。

---

四、从单体到多 Agent：一条可控的演进路径

不建议一上来就把业务拆成七八个 Agent。更稳妥的做法是：

4.1 第一步：单体 Agent + 工具 + 明确状态

• 把所有逻辑集中在一个 Agent 里；
• 但要保证：
  • 工具抽象清晰（ToolRegistry）；
  • AgentState Schema 定义清楚；
  • 每一步决策/工具调用都能被 Trace & 回放。

此时你已经为“将来拆分多个 Agent”做好了数据和代码基础。

4.2 第二步：把「规划 / 执行 / 评估」逻辑松耦合

• 在单体 Agent 内部先人为地分成三个模块：
  • Planner：负责任务分解/步骤规划；
  • Worker：负责具体工具调用/操作；
  • Evaluator：负责评估结果是否满足目标。

代码层面可以先拆成三个类/三个函数，仍然在同一进程内调用。

4.3 第三步：抽成显式节点 / 状态机

• 把 Planner / Worker / Evaluator 变成工作流里的节点；
• 用 LangGraph / 自研 StateMachine 明确每个节点的输入输出；
• 仍然只跑在一个服务里，但边界已经被「显式化」。

4.4 第四步：按职责/领域拆成多个 Agent

当你发现：

• 某个节点逻辑特别复杂；
• 某个领域的逻辑需要独立演进；
• 或者某个领域的安全/合规要求更高；

就可以把这个节点抽成一个独立 Agent 服务，走 HTTP/RPC 调用即可。

演进路线大致是：

单体 Agent
  ↓
单体 Agent 内部模块化（planner/worker/evaluator）
  ↓
显式工作流 + 独立节点
  ↓
节点按领域/职责逐步拆成多个 Agent 服务

---

五、多 Agent 带来的工程成本和如何控制

多 Agent 架构不是“白嫖”，它会带来额外的工程复杂度，主要在：

1. 部署与运维成本

   • 多个服务/进程需要部署、扩缩容、监控；
   • Agent 之间的网络调用引入新的失败点。

2. 调试复杂性

   • Bug 可能出现在任意一个 Agent，或者它们之间的交互；
   • 必须有好的 Trace + 回放系统。

3. 版本管理与灰度

   • 不同 Agent 的版本组合非常多；
   • 需要考虑：
     • A 老版本 + B 新版本；
     • 部分场景只灰度某一个 Agent。

4. 统一质量评估更难

   • 质量问题可能出在 Planner 选错了路径；
   • 也可能出在 Worker 工具调用不当；
   • 还可能是 Evaluator 放水/误判。

如何控制这些成本？​

• 严格定义 Agent 接口（输入输出 Schema）；
• 所有 Agent 共用一套：
  • Trace ID / 日志规范；
  • 质量事件格式；
  • 指标采集与告警体系；
• 把「Agent 级评测框架」接进 CI/CD：
  • 每次改任意一个 Agent，都要在一套统一样本集上重跑；
  • 不允许整体表现退步超过阈值。

---

六、给你一份「落地决策清单」

你可以在每个项目启动时，拿这份清单走一遍：

1. 这个需求是否天然包含多个清晰子角色？

   • 没有 → 倾向单体 Agent；
   • 有（比如「观测/诊断/决策/执行」）→ 可以考虑多 Agent。

2. 是否涉及3 个以上明确不同的专业领域？

   • 没有 → 倾向单体 Agent（配合工具）；
   • 有 → Router + 多 Specialist Agent 会更稳。

3. 是否对延迟/成本极其敏感？

   • 是 → 优先单体 + 简化流程；
   • 否 → 可以适当增加多 Agent 带来的额外 LLM 调用。

4. 团队中是否有足够人力/经验来维护多服务架构？

   • 暂时没有 → 先单体，架构上预留拆分空间；
   • 有 → 可以从 Planner/Worker/Evaluator 分离开始。

5. 这个系统的定位是**“单一应用 Agent”还是“Agent 中台/平台”**？

   • 单一应用 → 以单体为主，必要时少量拆分；
   • 平台 → 早一点引入多 Agent 设计更合适。

---

七、总结：别为「多 Agent」而多 Agent，让架构为需求服务

回到一开始的问题：「继续」写 Agent 相关的东西，怎么写才有工程价值？

这一篇给你补上的，是整个 Agent 系列中非常关键的一块：

多 Agent 不是目的，而是手段。
单体 Agent vs 多 Agent，是一个典型的工程选型问题。​

可以用下面这句话作为全文的收尾，也可以直接当 CSDN 文章的“总结”：

对简单问题，用简单方案；
对复杂问题，再用复杂架构。
先把单体 Agent + 工具 + 状态 + 评测打牢，
再用多 Agent 架构按需拆分，而不是一上来就堆“Agent 团队”。​