Agent Basic / 08
单 Agent 和多 Agent 的边界
多 Agent 是另一个很容易被过度包装的话题。
很多展示会把系统拆成：
- 研究员 Agent
- 分析师 Agent
- 执行 Agent
- 审核 Agent
- 管理者 Agent
看起来非常高级。
但在真实工程里，一个更关键的问题是：
这些角色拆分到底是系统需要，还是只是为了演示效果。
先说结论
大多数项目的第一版，应该优先从单 Agent 做起。
原因很简单：
- 成本更低
- 状态更集中
- 调试更容易
- 行为更容易解释
多 Agent 真正有价值的前提，不是“角色名能不能起得漂亮”，而是“任务是否真的存在明确的职责分离”。
单 Agent 什么时候更合适
如果一个任务满足下面这些条件，单 Agent 通常更合适：
- 目标比较单一
- 状态可以集中管理
- 工具集不算特别复杂
- 不需要多个独立视角长期博弈
- 系统首先追求稳定而不是花哨
例如：
- 风险初筛
- 文档问答
- 单任务研究分析
- 工单分类和处理
这类任务往往一个 Agent 加上合适的工具和状态管理就能做好。
多 Agent 真正有意义的场景
多 Agent 更适合下面几类问题：
1. 职责确实不同
例如一个角色负责信息收集，另一个角色负责审查和裁决。
它们的输入、输出、关注点真的不同。
2. 上下文压力太大
不同子任务需要不同上下文，硬塞到一个 Agent 里会变得又长又乱。
3. 任务可以并行
例如多个独立方向可以同时搜集信息，再汇总到一个中心节点。
4. 需要明确对抗或复核机制
例如一个 Agent 负责生成方案，另一个负责找漏洞，第三个负责最终裁决。
这时多 Agent 才有真正结构价值。
多 Agent 最容易被低估的成本
很多人只看到了“角色分工”，没看到系统复杂度会同步上升。
一旦进入多 Agent，你马上就要处理：
- Agent 之间怎么通信
- 谁维护全局状态
- 谁拥有最终决策权
- 冲突结论怎么解决
- 多轮协作何时停止
- 成本和延迟怎么控制
也就是说，多 Agent 不是“把单 Agent 复制几份”这么简单。
一个常见误区：把 Prompt 分角色，就以为自己做了多 Agent
例如：
- 同一个模型
- 同一个上下文
- 同一个执行循环
- 只是换了几个 system prompt 名字
这更像是“多角色提示词”，不一定真的构成有意义的多 Agent 系统。
真正值得拆成多 Agent 的系统，通常会有更清晰的：
- 角色边界
- 状态边界
- 输入输出边界
- 协作协议
一个务实判断标准
在决定是否上多 Agent 前，先问自己这几个问题：
- 单 Agent 真的做不好，还是我只是觉得多 Agent 更高级
- 各角色之间是否有明确且稳定的职责边界
- 把它们拆开后，系统复杂度增加是否值得
- 是否真的需要并行、复核或对抗式协作
如果这些问题答不清楚，就先别拆。
一个更推荐的演进路径
比起一开始就上多 Agent，更推荐这样做：
- 先做一个状态清晰的单 Agent
- 找出真正的瓶颈
- 只在必要处拆出子 Agent 或子模块
- 让多 Agent 服务问题，而不是服务演示效果
这样做通常更稳，也更容易长期维护。
小结
多 Agent 不是升级版皮肤，也不是默认更先进。
你可以先记住一句很实用的话：
如果单 Agent 还没做稳，多 Agent 大概率只会把问题复制并放大。
先把单 Agent 做扎实，再决定哪些地方值得拆分，通常是更成熟的工程路径。
接下来你可以进入：
因为当你真正开始关心状态、节点、分支和协作时，才会需要更强的系统编排能力。