多智能体编排进 Beta：把重复劳动拆成一条流水线的完整做法

一条流水线，而不是一个更聪明的对话框

最近多智能体方向有个值得注意的变化：主流平台开始把「动态编排」做成正式能力，进入公开测试阶段。意思是主智能体可以在运行过程中判断任务大小，自己决定开几个子智能体、怎么分工、什么时候收结果汇总，而不是人提前把流程写死。

这件事的意义不在于多了几个机器人，而在于重复劳动的处理方式变了。以前你把一份大任务丢给模型，它从第一行做到最后一行，中途跑偏了你只能在结尾发现。现在它可以把任务切成几段，每段单独跑，跑完交叉检查再汇总。

对每天要处理大量重复工作的人来说，这是实打实的生产力变化。写周报、整理客户反馈、批量生成商品文案、核对几十页表格——这些事情的共同点是步骤固定、量大、出错点集中。它们天生适合流水线。

判断一件事要不要上多智能体，看的是它的步骤能不能拆开，不是它有多难。 一篇需要灵感的文章不适合，一份需要核对八十条数据的报表非常适合。

先分清三种拆分方式

多智能体不是只有一种跑法，选错方式会让效率更低。

第一种是并行。把一个大任务切成若干互不相干的子任务，同时跑。比如给五十个商品各写一段卖点，每个子任务拿到的上下文只有那一个商品，互不干扰。并行的收益是线性提速，缺点是结果风格容易不统一。

第二种是串行。后一步必须依赖前一步的结果。比如先抽取客户反馈里的抱怨点，再按抱怨点归类，再针对每一类写回复模板。串行的收益是每步都能检查，缺点是总耗时不能压缩。

第三种是分角色。同一份输入交给不同角色各看一遍，最后交叉验证。比如一个负责找事实错误，一个负责找逻辑漏洞，一个负责看表达是否通顺。分角色的收益是质量明显提升，缺点是成本翻倍。

真实任务通常是三种混着用。一份月报可能先并行收集四个渠道的数据，再串行做归类和结论，最后分角色做一轮交叉检查。

动手之前：把任务写成一张步骤表

这一步最费时间，也最不能省。

拿一张纸，把你现在手工做这件事的完整过程写下来，写到能交给一个完全不懂的人照着做的程度。包括每一步的输入是什么、输出是什么、判断标准是什么。

举个例子，整理客户反馈这件事，很多人脑子里是「看看反馈然后总结一下」。写下来会变成这样五步：从后台导出近七天反馈；过滤掉纯好评和无意义内容；把剩下的按主题分组；统计每组出现次数；挑出次数最多的三组各写一句结论。

只有拆到这个颗粒度，你才知道哪一步能交给智能体、哪一步必须留给人。经验是：抽取和归类交给模型，判断和定调留给人。 前者量大且标准明确，后者需要你对业务的理解。

给每个子任务配一份最小上下文

这是新手最容易踩的坑。很多人把全部资料塞进一个超长提示词，然后抱怨模型抓不住重点。

正确做法是每个子任务只拿到它需要的那部分。给商品写卖点的子智能体，只需要那一个商品的标题、参数、目标人群、已有素材。它不需要知道你在做什么大项目，不需要看到另外四十九个商品。

上下文变小的收益有三个。结果更准，因为干扰信息少了。速度更快，因为要处理的 token 少了。成本更低，这一点跑批量任务时非常明显。

具体操作时，把主任务里不变的部分（公司背景、品牌调性、禁用词）单独存成一份固定说明，每个子任务都引用它；把变的部分（这一条的具体数据）单独注入。两份分开维护，改起来也清爽。

让子任务之间能互相挑错

多智能体最有价值的用法不是分工，是交叉验证。

一个很实用的结构是「生成—审查」双段。第一段让一个子智能体产出内容，第二段让另一个子智能体拿着明确清单去挑错，挑出来的问题再回到第一段改一轮。

审查清单要具体，不要写「检查有没有问题」。要写成四条：数字是否能在原文里找到对应；有没有出现原文没有的因果推断；专有名词拼写是否一致；有没有超出给定范围自行补充的内容。

最后一条特别重要。模型很擅长把没见过的东西写得像真的一样，尤其是数字和案例。你让它核对，它就必须只使用你给过的材料，任何补充都算错误。

跑两轮生成—审查，质量通常比单次生成高一大截，成本大约翻倍。对要对外发布的内容，这个代价划算；对内部草稿，可以只跑一轮。

汇总环节不要偷懒

多个子任务跑完，最后一步是汇总。很多人让主智能体直接把结果拼起来就完事，这一步恰恰是最该花心思的。

汇总要做三件事。统一口径，把不同子智能体写出来的同义词、不同格式、不同说法拉齐。补全局视角，单个子任务看不到整体趋势，汇总时才看得出来。做取舍，结果太多了要挑重点，不是全塞进去。

一个有效的做法是在汇总前先让主智能体看一遍全部子任务的关键字段，而不是完整内容。比如只看每条的「结论一句 + 置信度 + 异常标记」。这样它能在有限上下文里建立全局印象，再决定详细展开哪几条。

汇总完再跑一次整体审查，重点看有没有前后矛盾。分段跑的内容很容易出现前面说增长、后面说下滑这类冲突，只有通读全文才能发现。

控制成本：三条硬经验

多智能体最大的问题不是效果，是账单。任务拆得越细，调用次数越多，成本涨得越快。

第一条经验，不是所有步骤都要用最强模型。抽取、分类、格式整理这类机械工作，用轻量模型就够了；只有生成最终文案和做判断这两步值得用好模型。混合搭配通常能把成本压到三分之一，效果几乎不掉。

第二条经验，给每个子任务设明确的 token 上限和输出格式。不限长度的话，模型倾向于写长，写长的部分大多是废话。规定「输出不超过 150 字，三句话，用列表」，结果反而更精炼。

第三条经验，加缓存。同一批数据被多个子任务用到的部分，处理一次就存起来，不要每个子任务都重新读一遍原文。对跑几十个子任务的批量场景，这一条能省下可观的费用。

什么时候不该用多智能体

说了这么多好处，也要说清楚边界。

任务本身步骤就一两步的时候不要拆。拆开的开销大于收益，还容易在传递过程中丢信息。

需要强一致风格的内容不要拆。比如一整篇有个人色彩的文章，拆给五个子智能体写，拼起来会像五个人写的。这类任务适合单次生成再人工改。

对延迟敏感的场景不要拆。并行的收益要靠等待所有子任务完成才能兑现，串行更是把耗时累加。实时对话里上多智能体，用户只会觉得变慢了。

判断标准很简单：拆开以后，每个子任务能不能独立验收。 能，就适合；不能，说明它本来就是一件事。

一个可以直接照抄的起步方案

如果你从来没用过，从这件小事开始。

选一件你每周都要做、每次要花一小时的重复工作。按上面的方法写成五到八步的步骤表。第一步用轻量模型做抽取，第二步用轻量模型做归类，第三步用强模型写结论，第四步用强模型按四条审查清单挑错，最后你自己花十分钟定稿。

跑第一遍的时候别追求自动化，把每一步的输出都手动看一遍。看完你就知道哪一步的模型经常犯错、哪一步的提示词写得不够清楚。改两轮以后，再把人工检查点逐步撤掉。

一周以后，你会发现这件事从一小时变成十五分钟。这十五分钟里，大部分时间花在你做最终判断上——这恰恰是最该由你花时间的部分。

多智能体的价值不是替你思考，是替你把不需要思考的部分跑完。 想清楚这句话，你就知道该把什么交出去、该把什么留下来。