什么时候需要多个 Agent：分工也有成本

先画出依赖，再决定并行#

单篇检查可以拆成：读取正文与项目规则、检查元数据和链接、摘出事实性说法、查询材料、阅读逻辑与表达、汇总报告。

其中一些步骤能独立处理，一些不能。事实查询依赖先找出需要核实的说法；汇总依赖各项结果。还没确定输入版本就同时开工，各方可能读到不同的稿件。

可以先按工作关系判断：

一篇短文往往不值得分成多个 Agent。启动、传递规则和汇总都要时间。若固定校验本来只需运行一个脚本，也没必要额外找一个 Agent 专门“负责”那条命令。

需要查询多项相互独立的事实、等待不同服务返回，或者检查多篇互不依赖的文章时，并行更可能有价值。判断依据是实际工作量和等待，而不是任务里出现了几个名词。

第一种分工：检查独立，正文集中修改#

对一篇文章，我会先采用只检查的分工，暂时不让多个 Agent 改正文。

协调者先确定文章版本和适用规则，再把固定检查与内容阅读分给两个执行者。事实核实可以由其中一方先摘出清单，再交给独立的查询任务；没有必要默认每类都启动一个 Agent。

各执行者都读取同一份输入，各自写独立报告。协调者负责去重、检查范围和统一结论。需要修改时，再由指定的一方按确认后的建议改正文。

这样，事实检查发现某个数字缺少依据，表达检查提出删除整段时，就能先处理意见冲突。否则两边可能各自写出一个看似合理的版本，留下更难评估的合并结果。

同一模型承担不同角色，也不意味着获得了独立的专家意见。角色名称能帮助分配工作，不能替结果提供质量证明。

每个执行者知道自己读什么、写什么#

任务分配不能只写“你负责技术检查”。它还需要输入版本、检查范围、输出位置，以及遇到问题时怎么报告。

例如，固定检查任务可以这样写：

1
输入：协调者确认的 sample.mdx 版本，以及指定项目规则。
2
责任：检查元数据和站内链接；实际运行已有适用校验。
3
输出：review/run-01/format-report.md。
4
只写自己的报告，不修改正文或其他执行者的文件。
5
每项记录状态、位置、规则或工具证据。
6
路由映射不明时标记未完成，不自行假定链接失效。
7
发现任务外问题时简短记录，不扩大扫描。
8
报告中列出本次未覆盖项。

内容阅读任务则写到 content-report.md，负责推理、重复与完成态。两者可能都看到一处问题，但文件归属清楚，写入不会互相覆盖。

如果确实需要并行修改，优先按互不依赖的文件划分所有权。共享配置、导航或同一篇正文，应该指定单一负责人。隔离的工作目录能减少写入冲突，但结果回到一起时，仍然需要检查兼容性和冲突。

任务说明里的文件归属是协作约定。如果所有执行者仍拥有相同的写入工具，它不是强制权限限制；重要边界需要在实际环境里实现。

交接格式应让下一个人可以继续#

长篇聊天摘要很容易漏掉检查范围。我会让各方至少交付这些信息：

1
任务：format-check
2
输入版本：填写协调者确认的版本
3
已覆盖：元数据、站内链接
4
结果：各项通过、发现问题或未完成
5
问题：原文位置、适用规则、实际证据、建议
6
未覆盖：外链内容核实、正文表达
7
障碍：无，或写明具体原因
8
写入文件：review/run-01/format-report.md

查询任务还应注明实际读到的材料范围。只获得一个摘要，就交接“摘要”，不能写“已读完全文”。后一位执行者应据此判断是否需要补读。

交接只带必要内容。重复转发整篇正文、完整工具返回和全部日志，既增加上下文，也可能把不相关的私人信息带给更多执行者。需要全文的任务可以读取授权输入，不需要全文的任务只拿对应片段与条件。

同时，不要把“已经交给另一位 Agent”当成结果。协调者应拿到实际报告，确认对应版本和检查状态，才能进入汇总。

汇总要处理冲突，也要找漏项#

拼接两份报告不是验收。同一问题可能出现两次，也可能有两种相反判断。

例如，固定检查认为某个站内链接无效，内容检查认为它对应动态路由。协调者需要核对项目路由与实际生成地址，不能按多数意见决定。如果材料不足，就保留未完成状态。

去重时也不能只看标题是否相同。“收益数字无依据”和“作者未完成该测试”可能指向同一句话，却是两个相关问题。合并后应保留各自依据，避免只剩一个模糊的“表达不严谨”。

还要对照最初检查清单，确认有没有无人负责的项目。两个执行者都写了“未覆盖事实核实”，说明这项检查仍未完成；不能因为双方任务都结束就把整个报告标为通过。

一份完整汇总应能说明：输入一致，约定检查有人覆盖，冲突已解决或保留，未完成项没有被删掉。正文若在汇总期间更新，相关结论需要重新检查。

上下文分开，不等于安全隔离#

不同 Agent 有独立对话，能够减少彼此聊天内容的干扰。但它们仍可能共享文件系统、工具、账户权限和运行日志。

一方写入了不合适的文件，另一方可能照样读取；一方看到材料中的恶意指令，也可能在汇总时把它传给协调者。上下文分开，并不会阻止这些动作。

因此，各方都要把文章和查询内容作为数据处理，维持原有任务范围。涉及重要数据时，使用实际的只读权限或受限环境，并限制传递范围。不能把“分给一个新 Agent”当成已经隔离风险。

最终验收者也要核对依据。把同一条错误判断经过多次转述，不会让它变成事实。

比较总耗时和人工返工#

并行能缩短一些等待，但也增加启动、重复读取、交接和汇总。要判断它是否值得保留，应从任务开始量到可用报告交付，而不只比较某个执行者的运行时间。

可以拿两份工作量相近的输入，分别记录单 Agent 与分工方案的总耗时、调用费用、漏项和人工修正。输入难度不同的结果不能直接当作速度证明；模型和工具变化也要记下来。

如果并行后报告更快，但你必须花更久解决冲突，它可能没有减少工作。如果任务很短，回到单个 Agent 顺序处理也很合理。

对文章检查，我会先保留一种容易核对的分工，再按实际瓶颈调整。确定输入、约定所有权和验收，比增加角色更重要。

下一篇会把这个流程放到定时或事件触发下，处理重复运行、预算和通知，并说明发布决定如何保留给人。