多智能体工作流：把重复流程拆开，交给 AI 协作

写在前面 "多智能体"这个词被用得很滥。我们的理解很务实：当一个任务需要不同的知识、不同的工具、不同的判断标准时，把它拆成几个职责清晰的环节，比让一个"全能助手"闷头做完，效果更稳定、也更容易排查。 本文讲这套拆解怎么做，以及它的边界在哪。

一、为什么不用一个"全能 Agent"

给一个模型写一份三千字的提示词，让它既懂业务规则、又会调十几个接口、还要遵守审核标准——这种做法在演示里可行，在生产上会持续出问题：

• 指令互相冲突。提示词越长，模型越容易顾此失彼。当"要详细"和"要简洁"同时出现时，模型的选择几乎是随机的。
• 工具选择混乱。可选工具一多，模型会调错、漏调，或者陷入重复调用。我们见过 Agent 对同一个工具连续调用 8 次的案例——它在尝试修正上一个调用的错误，但越调越偏。
• 出错难定位。整个过程是个黑盒，答案不对时你不知道是哪一步崩的。

我们在自有产品的第一版就走过这条路，后来整体重构了运行时：放弃让 Agent 自主规划一切，改成分层的、可预测的结构。每一类任务走各自的处理路径，各自有明确的检索策略、提示词模板和输出校验。可预测性带来的收益，远大于"自主规划"带来的想象空间。

"全能"和"可靠"是反比关系

一个系统中，单一组件承担的责任越多，它出故障时的影响范围越大，故障原因也越难定位。这就是软件工程里"关注点分离"这条原则被反复强调的原因。AI Agent 不例外——看起来"一个助手搞定一切"很简洁，实际上是把所有故障点塞进了一个黑盒。

拆开之后，排查变成了逐段检查：检索返回了什么？分析环节基于这些输入输出了什么？撰写环节有没有偏离分析的结论？每一步都有可检查的中间态，而不是只在最后看到最终结果。

二、怎么拆一个流程

以"生成一份市场调研简报"为例，拆解通常是这样：

输入：调研主题 + 资料范围
  ↓
① 检索环节   →  从指定资料源找出相关材料，输出带出处的证据清单
  ↓
② 分析环节   →  对证据做归纳、对比、提炼要点
  ↓
③ 撰写环节   →  按既定模板组织成文
  ↓
④ 校核环节   →  检查引用是否真实、数据是否与原文一致
  ↓
⑤ 人工确认   →  业务人员审阅、修改、定稿

每个环节的关键在于输入输出是结构化的。检索环节交给分析环节的不是一段散文，而是一份带出处编号的证据列表。这样下一环节出错时，你能立刻看出是证据不对还是分析不对。

拆的粒度怎么把握

拆太细，调用次数变多、延迟变高；拆太粗，又回到了"职责不清"的问题。我们的经验法则是：按"输入输出可以独立校验"来界定环节边界。

如果一个环节的输出可以在不依赖其他环节的前提下被判断正确与否，那这个边界就是合理的。反例：把"检索 + 分析 + 撰写"放在一起，最终的输出是一篇完整文章——你无法判断问题是出在检索阶段、分析阶段还是撰写阶段。

我们在自有平台上就是这么组织的：不同职责的子模块各管一段——找证据的只管找证据，做分析的只管分析，做翻译润色的只管语言。它们共享同一套可观测记录，每一步的输入、输出、耗时、报错都能回看。

三、人工确认节点放在哪

这是整套方案里最需要和业务方谈清楚的部分。我们的原则：

人工确认不是效率的敌人。 一个流程如果原本需要 4 小时，AI 做完初稿只花 10 分钟，人工审核 30 分钟——总耗时依然从 4 小时降到 40 分钟。试图把最后那 30 分钟也省掉，往往是风险的来源。

设计确认节点的三个原则

1. 确认的内容要具体，而不是"你看一下整体对不对"。给审核者展示的是"AI 改了哪几个段落""这几个数据从哪来的""这几个引用的原文是什么"。
2. 修改成本要低。如果审核发现某一段需要重写，应该能直接在界面上编辑，而不是退回重跑整个流程。
3. 确认要有记录。谁在什么时间通过了哪个版本——这对于对外发布的内容尤其重要。

四、工具调用：让 AI 少做无用功

流程中的很多环节其实不需要模型"思考"，只需要它正确地调用工具：搜索、文档解析、数据库查询、格式转换、调用内部 API。

工程上的几个实际经验：

• 工具的描述要写得像给新同事看的说明书，含糊的描述会导致模型乱调。好的工具描述应该包含：这是什么工具、什么时候该用、什么时候不该用、每个参数的含义和格式、返回值长什么样。
• 给工具设超时和重试上限，否则一个卡住的调用会拖垮整个流程。超时后应该有明确的降级行为——是跳过这一步、返回兜底值、还是标记为需要人工处理。
• 工具返回的错误要让模型看得懂，"500 Internal Error"对模型毫无帮助，"参数 date 格式应为 YYYY-MM-DD"才能让它自己纠正。
• 重依赖的工具要隔离运行。我们把 PDF 结构化解析、OCR、音视频处理、Office 转换这类带沉重系统依赖的能力放在独立的沙箱服务里，主流程只通过接口调用。这样主服务保持轻量，沙箱挂了也不会拖垮全局。

五、流程沉淀与复用

第一次把一个流程跑通，通常要花不少时间调试。真正的收益来自把它固化成模板：

• 同一类任务，下次直接换输入即可
• 新员工不需要学怎么写提示词，只需要填几个参数
• 流程改进一次，所有使用者都受益

从"调出来"到"改进去"

模板不是设计出来的，是跑出来的。我们建议的做法是：先让业务方用一个通用流程跑真实场景，跑了 20 次以后，回过头看哪些步骤每次都需要人工修改、哪些步骤调了很多次才满意。这些就是需要"改进去"的地方。

改进去的方法有两种：

• 优化提示词/策略：如果某个步骤的输出方向对但细节不准，调整这一步的提示词和参数
• 拆分/合并步骤：如果某一步的输出总是被下一步推翻重写，说明这两步的边界画错了，考虑合并或重划

我们建议企业从一个高频、规则清晰、结果可验证的流程开始，跑顺了再扩展。一上来就想把十个流程全自动化，通常一个都做不好。

六、什么流程不适合做

坦率说，以下情况我们会劝退：

• 规则本身没有共识。 如果三个业务专家对"什么是合格的输出"有三种标准，AI 也解决不了这个问题——先把标准定下来。
• 样本量太小。 一个月只跑两次的流程，自动化的投入产出比很差。调试流程本身需要素材，没有足够的实际数据，流程就只能靠想象来设计，上线以后全是意外。
• 每次输入形态都不一样。 自动化依赖一定的稳定性，完全随机的输入难以固化。
• 错了代价极高且难以发现。 这类流程适合让 AI 做辅助检查，而不是主执行。比如财务报表的编制——AI 可以帮你做交叉校验、发现异常，但让 AI 做主生成等于把风险交给了概率。

七、典型交付流程

流程梳理与选型  →  角色化拆解  →  工具接入与编排
     →  人工确认节点设计  →  试运行与效果校准
     →  模板固化  →  推广与迭代

想找出你们内部哪些流程值得先做，欢迎联系我们聊聊。我们通常会先看你现在这件事是怎么做的、花多少人时、结果怎么验收。