问题不是 Agent 太少，而是边界太乱
很多团队刚开始做 Multi-Agent 时，会把注意力放在“要不要多几个角色”上：规划 Agent、执行 Agent、审查 Agent、总结 Agent。角色一多，看起来很智能，但实际落地时经常出现责任不清、链路过长、失败无法定位的问题。
我的判断是：Multi-Agent 产品首先要解决的不是角色数量，而是任务边界。一个 Agent 必须知道自己能做什么、不能做什么、输出给谁、失败时怎么处理。
Agent 编排的本质，是把不稳定的推理过程拆成可观察、可评估、可替换的工作单元。
三层产品结构
我会把 Multi-Agent 平台拆成三层：编排器、执行器和评估器。这样产品、工程和运营都能理解系统是怎么跑的。
一次任务如何流转
一个典型请求进入平台后，不应该直接交给“万能 Agent”。更稳的流程是：先分类，再规划，再执行，再评估，最后交付。
- 识别目标：判断用户是在咨询、排障、查询、投诉，还是要求生成内容。
- 拆分任务：把大目标拆成几个可以独立执行的小任务。
- 分配 Agent：根据任务类型选择检索、工具、写作、校验等不同 Agent。
- 聚合结果：把多个执行结果合并成一个对用户有价值的输出。
- 质量评估：检查事实、完整性、合规边界和可执行性。
状态管理比 Prompt 更重要
Multi-Agent 失败的常见原因，是状态在多个角色之间传丢了。规划 Agent 认为任务 A 已完成，执行 Agent 实际失败了；总结 Agent 拿到的是过期上下文；评估 Agent 不知道工具调用返回了什么。
所以平台必须有统一的任务状态，而不是让每个 Agent 在自己的 Prompt 里“记住”。状态里至少要记录任务目标、当前步骤、输入输出、工具调用、错误原因、重试次数和最终结论。
产品侧的护栏
Multi-Agent 平台一定要有护栏，否则很容易把错误放大。一个 Agent 的误判会影响下一个 Agent，最后形成一条看似合理但完全错误的执行链。
| 护栏 | 作用 | 产品表现 |
|---|---|---|
| 最大步骤数 | 防止无限规划和循环执行 | 超过阈值后降级或转人工 |
| 工具白名单 | 限制 Agent 能调用的外部能力 | 不同场景配置不同权限 |
| 输出评估 | 避免错误结果直接交付 | 低分结果自动重试或标记 |
| 人工接管 | 处理高风险和低置信度任务 | 保留完整上下文供人工继续 |
第一版应该做多小
我不建议第一版就做通用 Agent 平台。更务实的做法，是先选一个高频、边界清楚、可衡量的场景，例如“客服问题分诊 + 知识检索 + 答案评估”。
总结
Multi-Agent 的价值不是“多几个智能角色”，而是让复杂任务可以被拆分、被协作、被评估。产品经理需要关注的不是技术名词本身，而是用户目标如何被稳定完成。
当平台能回答“现在执行到哪一步、为什么失败、哪一步需要重试、什么情况下交给人工”时，Multi-Agent 才真正从 Demo 走向产品。
欢迎通过邮件和我交流：shaoyanyan91@163.com
本文首发于邵炎炎个人博客。转载请注明出处。