科普 · AI Agent 落地与风险

多智能体协作：
一个 Agent 指挥一群 Agent

一个 Agent 能干很多事，但有些活天生适合一群 Agent 一起干：写一份上万字的报告、同时查几十个资料源、又写代码又做验证。办法是搭一个小编队——一个统筹拆任务、几个执行者并行干活、一个独立的验证者检查成果。这篇文章讲清楚：什么时候一个就够，什么时候需要一群，三层结构怎么配合，以及小团队怎么从最小的试点起步。顺带说清楚一件事：网上流传的“一个人指挥 50 个 AI”，数字是被放大过的。

资料基准日：2026 年 11 月 10 日 · 约 12 分钟读完 · 文中产品功能与价格变动很快，购买前请以官方购买页为准

先说结论

多智能体不是“Agent 越多越好”，而是“任务需要分工时才上”。判断标准有三个：任务够不够长、能不能拆成互不依赖的几块、出错代价大不大。三条都不占，就一个 Agent。

经典结构是三层：统筹 + 执行 + 验证者。统筹拆任务、派活、汇总；执行者并行干活；验证者独立检查成果，而且要用和执行者不同的模型。验证者不是“再看一遍总结”，而是对照真实产物逐项检查。

pstack 是一个免费的开源编排工具（MIT 协议），它把这套分工办法写成了可以直接用的 skill 和 playbook。别把它和 xAI 的 Grok Bot 混为一谈——Grok Bot 是闭源的收费产品，pstack 是免费的开源插件。

“一个人指挥 50 个 AI”是二创放大的标题。原分享者 Lauren Tan 自己说的是同时跑 10 到 20 个 Agent，单月约 1,000 个 PR——而且 PR 的数量不等于产出的质量。

01一个 Agent 够不够用？先看任务长什么样

上多 Agent 之前，先问三个问题。三个都答“是”，再考虑一群；否则一个就够。

图 1 · 三个问题决定用一个还是一群：任务够长、能拆、出错代价大，才值得上一群。

举个例子就明白了。让 Agent 写一封邮件、整理一份会议纪要，一个 Agent 绰绰有余；让它写一份上万字的行业报告，同时查几十个资料源、做表格、画图、再写代码验证数据——一个 Agent 要跑很久，中间还容易跑偏，这时候拆成“检索组、写作组、验证组”并行做，才划算。

反过来也有不适合拆的活：如果第二步必须等第一步的结果（比如先定方案、再按方案写代码），拆了也没用，只能串行干。一个 Agent 串行干完，反而更省事、更省钱。

判断口诀：长、能拆、怕错，才上一群。

任务短、拆不开、错了也没事——一个 Agent 是最好的选择。多 Agent 是手段，不是目标。

02三层结构：统筹、执行、验证者

多 Agent 协作的经典结构只有三层，再多就乱了。每一层只做一件事。

图 2 · 三层结构：你定目标，统筹派活，执行者并行干活，验证者独立检查，通过了才能交付。

这张图里最容易被忽略的角色，是验证者。它和执行者有三个不同：

看的东西不同：执行者看的是任务，验证者看的是产物——写出来的代码能不能跑、表格里的数字对不对、报告里引用的来源存不存在。只读执行者的总结不算验证，要读 diff、读文件本身。
用的模型不同：验证者要用和执行者不同的模型家族。自己检查自己的活，容易“既当运动员又当裁判”。
权力不同：验证者有一票否决权。没通过就打回重做，不能“差不多就交了”。自动合并是最后一步，不是起点。

还有几条结构上的硬规矩，都是从实践里总结出来的：

最多三层。你 → 统筹 → 执行者，不要再加第四层。层数一多，信息每传一层就丢一点，最后没人知道最初的目标是什么。
一个任务一个负责人。每个执行者只对自己那一块负责到底，从动手到交付，出了问题找得到人。
可逆的工作直接做，不可逆的永远等人。改草稿、查资料可以直接做；发给客户、删数据、部署上线，必须人点头。
一个统筹手头约 10 个执行者是上限。再多，统筹自己就成了瓶颈。

03pstack 是什么：一个免费的开源编排工具

上面这套三层分工的办法，有人把它写成了可以直接用的工具，名字叫 pstack。

pstack 是 SpaceX AI / xAI 的工程师 Lauren Tan（网名 poteto）开源的一套工作方法，仓库在 GitHub 上，MIT 协议，本身免费。它不是一款 Agent 产品，而是一套装在编程工具里的“技能包”：34 个功能 skill、24 条原则 skill、23 个 playbook（操作手册），再加 2 个子 Agent。主入口是一个命令 /poteto-mode——你给它一个任务，它先匹配到对应的 playbook，再按步骤触发其他的 skill。

它里面最值得借鉴的几条原则，用大白话讲就是：

验证先行：宣称“做完了”之前，要对照真实产物验证一遍，而不是看“能运行”或者听 Agent 自己说“搞定了”。
拆成可验证的小单元：多步工作拆成每个都能单独验证的小块，逐个验证再往下走，不要整层一起上。
教训要写进结构里：每次失败，不要只修当次的输出，要把它变成一条 lint 规则、一段检查脚本或者一个字段——让下次自动防住。
数字先问“它测的是什么”：引用任何实测数字之前，先找到它的限制条件。分数高，不等于活干得好。

要分清两件事：pstack 本身免费，但用它要花钱。花的是编程工具的订阅费和模型 token 费——一次运行“花的是真 token”，官方指南明确提醒先设预算。pstack 是 Cursor 的插件，安装是在 Cursor 里运行 /add-plugin pstack。如果你现在主要用的是 Codex 而不是 Cursor，安装路径是否适用要重新确认——这一点我们核实过，写在这里是提醒你先确认再动手。

别把 pstack 和 Grok Bot 混为一谈：

pstack 是免费的开源插件，帮你编排 Agent 干活；Grok Bot 是 xAI 的收费产品（Premium 30 美元/月起），本身就是一个 Agent 队友。一个是“指挥方法”，一个是“队员本身”。

除了 pstack，各家产品里也有“多 Agent 协作”的影子，只是形态不同：OpenAI 的 Dots 自己不埋头干重活，而是把写代码派给 Codex、把长任务派给 ChatGPT Work，自己负责盯进度；Grok Bot 是多个 Bot 在同一台云电脑上并行分工、互相交接；Kimi 的 Agent 集群能把复杂目标拆给多个子 Agent 并行做研究、编程和验证；豆包工作的“工作伙伴”可以组建多 Agent 小队协同。这些都是“多智能体协作”的不同版本，背后的分工逻辑是相通的。

04数字要说清楚：“50 个 Agent”是怎么来的

2026 年 11 月，网上流传一个视频，标题是“1 个人指挥 50 多个 AI”。这篇文章里要把这个数字说清楚，因为它正好说明了多 Agent 协作最容易被误解的地方。

事实是这样的：Lauren Tan 本人分享的方法是同时跑 10 到 20 个 Agent，三层结构，单月约 1,000 个 PR（代码合并请求）。“50 多个 Agent”“20 个工程师”这些说法，是二创标题放大的，原分享里没有。PR 的数量也不等于产出的质量——1,000 个 PR 里有多少是小修小补、有多少真正解决了问题，数字本身不回答这个问题。

类似的数字游戏，在 Agent 产品里很常见：

“300 个子 Agent”（Kimi Agent 集群）：这是官方技术博客描述的集群能力上限，不是日常使用的典型值。不要写成“每次任务都调用 300 个 Agent”。
“4,000 次工具调用”：同样是能力上限的描述，不是“每个任务都调 4,000 次”。
“90 亿次任务请求”（腾讯 WorkBuddy，2026 年 10 月 29 日）：这是腾讯自己的说法，计的是“请求次数”，不是“完成的工作件数”，更不是“付费用户数”，且未经独立核实。引用时必须写“腾讯称”。

看多 Agent 的宣传，记住三句话：

问“同时跑几个”之前，先问“同时跑几个还能管得过来”；看“一个月多少 PR”之前，先问“多少 PR 是真正有用的”；听到“几百个子 Agent”时，记得那是上限，不是日常。

05小团队怎么起步：四步试点

不要一上来就搭一个 10 人的 Agent 编队。正确的起步方式是：先跑通一个最小的单元，再扩。

第一步：一个 Agent，先跑通。挑一件重复、耗时、出错代价低的活（比如每周整理一份数据报表），让一个 Agent 从头到尾跑通。你只审结果，不插手过程。跑通两周，记下它哪里会出错。
第二步：把验证写成脚本。针对第一步里出错的地方，写一个能自动检查的小脚本——比如“报表里的数字加起来对不对”“引用的链接能不能打开”。这一步最关键：没有脚本化的验证，多 Agent 就是多份“看起来完成了”的输出，没人知道真假。
第三步：再加第二个 Agent。一个做、一个查。做的用一个模型，查的用另一个模型家族。跑通一次完整流程：派活 → 执行 → 验证 → 合并，全程你只审 diff（实际改动），不只看总结。
第四步：连续两次全绿，才扩。只有连续两个任务全程跑通、验证者拦截的问题稳定下来，才考虑加第三个执行者，或者开过夜跑。自动合并不要开。每次只扩一个单元，不要一次铺 5 个 Agent。

每一步都要记一笔账：这次花了多少 token、用了多长时间、验证者拦截了几个问题。这笔账就是“扩还是不扩”的依据——如果验证者一直在拦截同一类错误，停下来修 skill 或检查脚本，不要继续出活。

还有一条信任曲线可以对照：本地单个 Agent 全程盯着 → 装上编排工具 → 为应用建验证脚本 → 每次失败沉淀成规则 → 对规则做盲测 → 只有这时才扩到云端、扩到更多 Agent。自动合并是最后一步，不是起点。

06多 Agent 的坑：人越多，越要小心什么

多 Agent 不是免费的午餐。每多一个 Agent，就多一份成本和一份混乱的可能。

沟通成本：Agent 之间也要“开会”——传任务、同步进度、汇总结果。任务拆得越碎，协调的开销越大。有时候三个 Agent 互相等，比一个 Agent 自己干还慢。
责任不清：活是三个 Agent 一起干的，错了找谁？所以“一个任务一个负责人”这条规矩不能破，每个执行者只对自己那一块负责到底。
账单翻倍：每个 Agent 都在烧 token，验证者也要烧。三个 Agent 并行，费用不是一个 Agent 的三倍——因为还要加上统筹和验证者的消耗，以及反复打回重做的部分。预算上限要先设好。
验证者疲劳：验证者也是模型，也会犯错、也会“看累了”放水。定期换验证者用的模型、定期抽查验证者的结论，验证本身也需要验证。
信任错觉：CI 绿了、验证者通过了，不等于事情就对了。pstack 里有一句话：“Green is not safe”——绿灯只是裁决的输入，不是裁决本身。最后拍板的人，永远是你。

所以，回到这篇文章开头那个问题：什么时候需要一群 Agent？答案是——当你已经有一个 Agent 跑得很顺、验证脚本已经立起来、而且任务确实长到一个人干不完的时候。不是之前。

本系列下一篇预告：《Agent 选型指南：七款产品，哪一款适合你》——按场景给选择框架，不替你做决定。

附来源清单

以下来源为本文写作时实际查阅或核对过的资料，核对日期均为 2026 年 11 月 10 日。产品功能与价格变动很快，引用时请以官方最新页面为准。

pstack 仓库（独立镜像）：https://github.com/backnotprop/pstack —— MIT 协议；版本 0.15.36；34 个功能 skill + 24 条原则 skill + 23 个 playbook + 2 个子 Agent；主入口 /poteto-mode；orchestrate playbook 最多三层、每 coordinator 约 10 个 worker、一个 PR 一个 owner、独立 verifier 用不同模型家族、不可逆写入永远等人；/goal 在仓库里不存在。
Cursor 官方插件库 pstack：https://github.com/cursor/plugins/tree/main/pstack —— 与独立镜像同款。
本站 pstack 试点清单（2026-11-10，内部工作文件）：~/workspace/goals/sirna-sequence-design-platform-optimization/files/pstack-pilot-checklist-20261110.md —— pstack 机制对照、试点步骤 1–2 已跑通、步骤 3 已暂停；“50 个 Agent / 20 个工程师”为二创放大标题，原分享无此说法；Lauren Tan 本人同时跑 10–20 个 Agent、单月约 1,000 个 PR；Grok Bot 闭源且不免费，与 pstack 不是一回事；用户现主要用 Codex，pstack 的 Cursor 安装路径在 Codex 下是否适用待重新确认。
本站《常驻 AI 智能体科普：Grok Bot 与它的同类们》（2026-11-10）：Grok Bot 闭源、Premium 30 美元/月起；Dots 把代码派给 Codex、长任务派给 ChatGPT Work；Kimi Agent 集群 300 子 Agent / 4,000 工具调用为厂商口径；豆包工作“工作伙伴”可组建多 Agent 小队；WorkBuddy 可并行执行多个任务；腾讯“90 亿次任务请求”为厂商自述、未经独立核实。
Kimi Agent 官方帮助中心：https://www.kimi.com/help/agent/agent-overview —— Agent 集群、Kimi Claw、20+ 工具。
Grok Bot 官方文档：https://docs.x.ai/grok-bot/overview —— 多个 Bot 协作、共享云电脑（2026-11-10 核实）。