一个人带一群智能体：角色、并发与验收

一年里我长期同时开着多个智能体干活。写这篇是想把"怎么分工、怎么并发、怎么验收"讲清楚——因为这三个问题的答案，几乎决定了这套协作是省时间还是浪费时间。

先说结论

• 拆分的价值不在并行，而在让提出方案的人不负责验证；
• 并发上限应该从服务端限额倒推，并先缓存再并发；
• 验收标准必须是机器可判的，否则等于没提。

一、一次典型任务的规模

以一次消融实验为例，实际发生的分工是这样的：

角色	数量	只做什么	明确不做什么
主流程	1	拆任务、汇总、向人汇报	不亲自写实现
探索	2–4	只读检查、给出结论与依据	不改任何文件
实现	1–3	在约定范围内改动	不做自己的验收
审查	1–2	按检查清单找问题	不许改代码

在同一套记录里，近一半的执行单元是子任务而不是对话轮次——也就是说绝大多数"会话"其实是主流程派发出去的分工，不是一问一答。

二、三条硬规则

一、审查者不许改代码。 一旦允许，它就会把问题就地修掉，"发现问题"这个环节就消失了，最后只是多了一个实现者。

二、先缓存再并发。 结果先落盘，重跑几乎零成本；并发数按接口限额设上限，而不是按"想多快"：

并发上限 = min(接口限额 × 0.7, 本地资源允许的并发)
失败重试 = 仅对"重试有效"的类别开启（如限流），其余记录原因后跳过

三、验收标准要能自动判断。 "检查一下有没有问题"等于没提。可用的标准长这样：

• 全部测试通过，并给出通过条数；
• 界面每个可点击元素都被真实点击过，给出点击与失败计数；
• 导出的图片必须实际渲染出来看过，而不是只确认文件存在。

性价比最高的一步

把"验收标准"写成可执行的检查项，再交给主流程自动跑。这一步做完之后，人在整个流程里只需要在关键节点看结论。

三、三个坑

一、并发拉满是负优化。 我试过一次派出十几个子任务：接口限流、相互等待、重试把额度烧光，总耗时反而更长。固定并发上限之后，同样的工作量更快完成。

二、子任务没有"完成定义"就没法收敛。 每个子任务必须自带"什么算做完"，否则主流程无法判断该收还是该等。我的标准是：进度落盘 + 明确产出物 + 超时与重试策略，三样齐了才发出去。

稍加注意

长任务一定要让进度写进文件，而不是留在对话里。会话一断，对话里的进度就不存在了；文件里的进度可以被任何进程接手。

三、子任务的上下文要干净。 把无关的历史带进子任务会显著降低它的判断质量。派发时只给它需要的输入，而不是"把它可能用到的全部材料塞过去"。

四、现在的默认做法

• 探索与审查只读，实现与审查分离；
• 并发有上限，失败分类重试；
• 验收标准先写出来，能让脚本跑的绝不用人看；
• 长任务进度落盘，随时可以中断、换人、续跑。

这四条固定下来之后，"一个人带一群智能体"才从演示变成了可用的工作方式。