千个Agent协同：一人公司的门槛在哪？

从 Multi-Agent Scaling 到下一代智能系统的组织、验证与控制

—

最近 X 上有一类画面最容易让人看得热血上头：

有人坐在电脑前，打开几十个终端窗口，Claude Code 负责拆任务，Google Antigravity 拉起一组 worker，另一个 Agent 做 review，几个模型并行写代码、跑测试、查资料、生成页面。/swarm

整个屏幕看起来就像一家公司。

于是“一人公司”又被抬到了新高度：过去一个人配 AI，相当于多了个助手；眼下一个人似乎能拥有几十、几百乃至上千个数字员工。

Anthropic 11 月9日发布 Fable 5.2 时透露，有位工程师让模型协调了超过 1,000 个子 Agent，连续八天，从一个空文件夹起步，搭出一个能在笔记本上启动的操作系统原型，驱动、文件系统、窗口、登录界面都在里面。这个实验

Google 也没绕弯子。Antigravity 新推出的 [[保留3]] 把协调者、隔离的 worker、对抗式 verifier、共享消息板和执行图谱塞进同一条工作流。它主打的不是“更会聊天的模型”，而是一个能调度一群模型的工作现场。/swarm

可问题也跟着换了。以前大家盯的是：模型能不能写出一段代码、做完一次研究、调起一个工具。

如今更麻烦的是：一百个、上千个 Agent 一起动起来，谁能保证它们不重复干活、不互相覆盖、不把错误一层层传下去，最终交出一个人愿意接受的结果？

一人公司真正的门槛，也许从来不在“能不能调动更多 Agent”，而在能不能把越来越多的智能执行能力，组织成一个可信、可审计、可验收的系统。

一、先别急着把一千个 Agent，想成一千名员工

一千个 Agent 不等于一千个员工。员工会攒下对组织的理解，会扛长期责任，会掂量一个决定对客户、品牌、团队和自己的职业意味着什么。Agent 能被迅速复制、快速启动、同时运行，也能迅速犯下同一种错误，几分钟内就把它复制一千遍。

所以，Agent 的规模化至少分三层，不能搅成一件事。

前两层，技术突破已经摆在那里。最后一层，答案还远没有。

一个团队能让 Agent 一天生成十万行代码，也能让它们一夜之间做完市场研究、搭出产品页面、写好营销文案和客服流程。可这些结果离一门真正的生意，中间还隔着用户需求、产品判断、获客、销售、交付、品牌、合规、售后，以及那个始终绕不过去的问题：谁为结果负责？

这也是为什么，今天看到的“一人公司”故事该拆成两句话。第一句站得住：以前要一个 5—10 人执行团队完成的那部分工作，现在确实可能由 1—2 个人加一套成熟的 Agent 系统完成。

第二句则远没成立：所以，一个人已经等于一家完整公司。

前者是

后半句则远未站住脚：执行能力上的变化，被过早当成了商业上的现实。

二、Agent数量堆上去，并不是一条铁律

多Agent最容易让人看走眼的地方，就在于它太像传统意义上的招人了。一个不够就上十个，十个不够就上一百个。

可软件系统毕竟不是工厂流水线。任务之间能不能并行，常常比你开了多少个实例更要紧。

Google Research 今年 1 月做过一项很有参考价值的实验：研究人员对比了 180 种 Agent 配置，得出的结论是“架构是否匹配任务结构”决定结果，并非“多 Agent 更强”。

在可并行的金融分析任务上，采用集中式协调的多 Agent 系统比单 Agent 提升约 80.9%；可在严格顺序的规划任务里，多 Agent 配置反倒下降了 39%—70%。道理不难懂：前一类任务能让不同 Agent 分头去分析收入、成本、市场和竞争对手；后一类任务得保住连续的推理链，频繁沟通反而会把上下文打碎、把认知预算耗掉。Google Research 的完整实验

于是，一个系统能不能从 1 个 Agent 扩到 100 个，看的不是“Agent 总数”，而是三样东西：

• 这个任务能拆出多少相对独立的子任务；子任务之间的依赖有多密；每多一个 Agent，协调、验证和返工的成本要涨多少。

可以把它想成一条很朴素的规律：真正有效的并行度，取决于任务里到底有多少活儿能在不互相等待的情况下干完，而非你开了多少个 Agent。

拿研究任务来说，它常常适合多 Agent。一个问题能拆成好几个相对独立的方向：找资料、读论文、核对公司数据、梳理技术路线、找反例。Anthropic 的多 Agent Research 系统走的就是这个路子：主 Agent 负责策略和汇总，子 Agent 在各自的上下文里并行搜索、压缩信息。Anthropic 披露，在其内部评测中，多 Agent 研究系统在某些广度优先任务上明显好过单 Agent；但它同时提醒，多 Agent 的 token 消耗大约是普通聊天的 15 倍，而且不少需要共享上下文、强依赖协作的编程任务，并不适合简单靠加人来解决。

复杂的软件重构就是另一码事了。它表面上涉及几百个文件，看着很适合分给几百个 Agent；可实际上，接口、架构、测试、数据库迁移和用户行为之间往往彼此牵连。一个局部改动，可能在另一个模块里埋下隐患。

到了这一步，多 Agent 的难题就变成了“如何避免每个人都在局部正确地做错事”，“如何分配工作”已经不再是重点。

三、Agent系统正分出四种组织路线

今天多 Agent 系统看着很热闹，可它们争的并不是同一个答案。更准确地说，各家正在试的是四种不同的组织哲学。

这四条路线谈不上谁取代谁，它们各自应对的是不同的失败模式。

1. 中心化协调：设一个总指挥，责任链更清楚

中心化协调，最贴合人对“团队”的直觉。

由一名主 Agent 读取需求、拟定计划、下发任务，若干 worker 各自分头执行，收尾阶段再由主 Agent 或 verifier 汇总结果、提出质疑、决定要不要继续推进。

这种做法胜在清楚。

全局目标归谁盯、局部执行归谁管、哪些结果必须上报，每个人都心里有数。任务边界比较明确、又需要有人做整体取舍时，这种结构往往更稳。

Google/swarm也没有把 coordinator 拿掉，只是不再让它独自扛下所有上下文的转述。worker 在彼此隔离的 worktree 里干活，verifier 专门对 diff 和测试运行结果提出质疑，协作过程则保存进一块共享的、只做追加的消息板。Google 对它的定位说得很直白：这是对单 Agent 和脆弱层级链的一种修正——不是让一个总指挥把所有事都记在脑子里，而是让团队成员围着同一块可追溯的工作面配合。

中心化的问题同样摆在明面上：主 Agent 容易变成认知上的瓶颈。

凡是关键任务，都得它过目、它拍板、它汇总。一旦 coordinator 的上下文越拖越长、优先级开始乱、计划越来越过时，整个系统就像一家过度依赖 CEO 的公司，只能干等。

2. 层级化委派：给 Agent 也配上“中层管理者”

Cursor 的实践值得细看，因为最早走相反路线的正是它。

一开始，Cursor 让 Agent 之间平等协作：共享状态大家都能看，任务自己认领，进度自己更新，再用锁防止彼此踩到同一个文件。

跑出来的效果，很像一个没有管理架构的临时工作群。

锁要么被长期占着，要么忘了释放；20 个 Agent 的有效吞吐一度只有 2—3 个；Agent 还偏爱挑简单、安全的小任务，最难、最需要端到端负责的那部分没人愿意接。

再往后，Cursor 换成了 Planner、Worker、Judge 三方分工：

• Planner 不断探索代码库，提出下一批任务；
• Worker 只负责执行分到手的活；
• Judge 在每轮结束时判断是继续、停止，还是重新规划。

这个转折相当关键。

它说明多 Agent 系统并不会天然形成协作。目标分解不明确、阶段性判断缺失，Agent 就很容易滑进一种“假繁忙”——提交一大堆、改动一小步、局部反复优化，真正关键的目标却迟迟推不动。

当然，层级并非越多越好。

Cursor 后来的经验是：整合角色搞得过于复杂、组织结构管得过于严密，反倒会制造新的瓶颈。最好的结构常常在中间地带：结构太少，系统会冲突、重复、漂移；结构太多，系统会僵化、脆弱，时间全耗在彼此同步上。

这一点跟人类组织其实差不太多。

3. 独立并行：把“多做几次”当成可靠性策略

第三条路线更朴素：别让 Agent 之间协作得太深。

让多个 Agent，甚至不同模型，各自独立完成同一个任务，再由系统去做比较、投票、交叉验证或者挑选。

对于答案能够被明确检验的任务，这套做法相当合用。

举个例子：让多个Agent分头去修同一个bug，或者让多个模型各自做同一份市场研究，再或者几个候选方案统统跑一遍相同的单元测试、静态检查、人工抽检。在这里，多Agent的意义并非凑出什么“集体智慧”，它带来的是更宽的探索面，让单一路径翻车的风险降下来。

不过，代价摆在那儿：烧钱。

说白了，这是拿算力开销去顶协作开销。碰上质量没法自动判定的问题，它还可能把麻烦往后挪——十个方案摆在你面前，可谁来定哪个最优？

这么看，独立并行算不上什么通用组织架构，它更像一种策略，在“验证便宜、探索昂贵”的场合格外好使。

4. 共享状态协作：下一代系统的关键，也许不在聊天，而在共同面对同一份现实

有一条路线最该盯住：把目光从“Agent之间要讲多少话”挪开，转到“它们到底共享了什么”上面。

以往的多Agent系统，运行方式往往是这样：

主Agent先汇总一遍，交给子Agent；子Agent干完活，再写段总结递回去；另一个Agent读完总结，接着往下执行。

每转述一回，信息就丢一层。

错误还会被“洗白”。某个没验证过的推断，被第一个Agent写进总结；第二个Agent拿它当背景事实；第三个Agent又照着它排计划。到头来，系统记住的不是原始证据，而是一个被来回转述多遍的结论。

共享状态、共享消息板、可检索工作记忆、可追溯引用关系之所以近来受重视，原因也在这里。

它们要解决的，其实不是“让Agent聊得更顺”，而是让每个Agent都能答上几个更基础的问题：

• 眼下这项任务处在什么状态？
• 这个结论是从哪来的？
• 哪个Agent干了哪些事？
• 这个依赖满足了没有？
• 哪些信息已经过期？
• 这条证据经过独立验证了吗？

将来的Agent协作系统，大概率更像一层带版本、权限、引用、依赖关系和审计日志的“共享现实层”，而不是一群互相发消息的聊天机器人。

但共享状态也不是什么万能药。

共享得越多，污染可能来得越快。一个错误结论进了共享状态，比起困在某个Agent的上下文里，危险程度可能更高。所以关键不在“共享”本身，而在于共享内容的来源、置信度、版本、过期时间和验证状态。

四、代码生成开始变便宜，验证正在变得昂贵

这是多Agent时代最容易被漏算的一笔账。

一个Agent一小时才写出一小段代码，这时候人类做review算不上什么大问题。

可要是一百个Agent同时往外吐代码、文档、测试、配置、研究报告和产品方案，系统的瓶颈很快就会从“生成得不够快”变成“这些东西到底能不能用，由谁来拍板”。

这中间至少横着四层各不相同的标准：

不少AI demo只走到第一层就停了。

页面能跑，代码能过测试，Agent也能说一句“任务完成”。可离可合并、可部署还差得远，更别提持续创造价值了。

今年3月，METR请真实维护者审查了296份AI生成的SWE-bench PR。校正之后，维护者愿意合并的比例，平均比自动评测的通过率低约24个百分点。METR给出的结论并非“Agent不行”，说法要克制得多：把benchmark分数直接当成真实世界里的可用性，很容易高估Agent的价值，那些没机会根据反馈反复迭代的Agent尤其如此。

生产率该怎么看，也会跟着变。

以前大家盯的是token单价：输入多少钱、输出多少钱、模型又便宜了多少。

往后真正该算的，或许是“单位验收交付成本”：

模型成本 + 运行成本 + 协调成本 + 验证成本 + 人工成本 + 返工成本 ÷ 被正式接受的有效产出

这个指标不够性感。但它比“今天跑了多少Agent”“生成了多少行代码”要诚实得多。

OpenAI的Harness Engineering复盘里有个细节很能说明问题：他们用Codex搭一个内部产品，五个月下来形成约百万行代码、约1,500个已合并PR；代码吞吐一上来，团队的瓶颈就变成了人类QA能力。结果他们只能让应用本身、日志、指标、浏览器状态都对Agent可见，让Agent自己去复现、验证和迭代，而不是把所有检查都堆给人。

这并不等于“人终于可以不review了”。恰恰相反，它说明人类review没法靠蛮力扩张，只能重新设计。

五、真正的竞争，正在从模型能力转向控制平面

模型像大脑，Agent loop像手脚，多Agent系统真正缺的，往往是神经系统和交通规则。

Harness、Runtime、Orchestrator、Control Plane这些词开始频繁出现，原因也在这里。

它们听着像工程术语，处理的其实都是很具体的问题：

眼下不少“master prompt”，看上去像一键就能把Claude Code变成一家完整的公司。

可真正成熟的系统，不会把关键约束全押在一段prompt上。

它会按类型把确定性放到不同的地方：

• 权限交给策略和沙箱管；
• 不可逆操作交给审批和回滚机制管；
• 代码质量交给测试、静态分析和独立review管；
• 长时任务则靠持久执行、断点恢复和预算控制来管理；
• 高风险决策不能靠一方拍板，得让不同来源的证据、独立的 verifier 和人来共同担责。

有个误区得先说清楚。

不少系统都声称自己留了 human-in-the-loop。

但人在最后一步按下“批准”，不等于他还保有独立判断。

要是摆在他面前的是 Agent 摘要过的证据、Agent 推荐的选项、Agent 拟好的理由，那这个人多半只是个责任签名器。人类真正握住的控制权，不在于把人放在流程末尾，而在于人还能看到关键证据、看懂分歧在哪、对前提提出质疑，并且在风险高的节点上确实能一票否决。

所以说，将来最强的 Agent 系统，未必是“最自主”的那个。

它更可能是这样一个系统：清楚哪些事可以放手，哪些事必须停下来等人，哪些事得交给另一套独立机制再验一遍。放到垂直领域，这一点尤其要紧。

六、一人公司只是表层，真正出现的是“人类团队 + Agent Fleet”

“一人公司”会冒出来，而且数量会持续增加。

边界清晰、价值又能快速验证的领域最容易出现这种形态：企业流程自动化、垂直工具、小型 SaaS、研究服务、内容生产、营销运营、客户支持。

一个对某行业摸得足够透的人，确实有机会靠 Agent 把原先要分给好几个人干的执行活，压进一套系统里。

不过团队不会就此消失。

更可能出现的局面是，组织朝两种形态分开走。

头一种是 Solo + Agents。

它胜在快、轻、成本低。创始人直接把自己的判断转成任务图、规则和 Agent 工作流。决策链短、客户需求明确、产品边界比较稳的场景，最适合这种打法。

另一种是 Team + Agent Fleets。

它的长处不在人多，而在于不同的人类角色能跟不同的 Agent 群体共用任务、证据、状态和责任。产品、工程、销售、运营、合规不再各自对着一个聊天机器人，而是一起进入一套可追溯的智能劳动系统。

前一种形态里，稀缺的是创始人的领域判断、获客本事、风险承受力和时间。

后一种形态里，稀缺的是组织设计：怎么让不同的人、模型、工具、权限和数据待在同一个系统里，还不会彼此拖后腿。

多 Agent 真正改变公司的地方，就在这里。

它不光让一个人看起来像一家公司，还开始逼着每家公司重新定夺：哪些事该人来做，哪些事交给 Agent，哪些协作可以自动跑，哪些必须留着人来负责。

七、真正稀缺的，是让智能劳动有序发生的能力

一千个 Agent 开工之后，最不缺的恐怕正是“执行”。执行会更快、更便宜，也更容易被复制。

真正稀缺的，是四件事：

• 能不能把复杂目标拆解成一项项正确的任务，能不能让不同的 Agent 围着同一份可信状态一起干活。
• 产出规模暴涨时，验证、审计和质量还能不能稳得住。
• 至于关键决定，还是得有人真的看懂了，并且愿意担这个责。

一千个 Agent 并不等于一千名员工。它们是一千个执行单元，需要被组织、被约束、被验证，到头来也得有人为它们的结果负责。

说到底，下一代软件争的恐怕不只是谁的模型更强，而是谁能先把“组织智能劳动”做成一种靠得住的基础设施。

920.org.cn（AI Research Institute）创始人，港大 AIBT 研究生，前上市公司 CMO，长期研究 AI 产品、Agent 架构与商业增长，也一直在看技术变迁怎么重塑人的工作、判断和生活。

写过《AIGC从0到1》系列丛书，以及东方寓言小说《飞将军》。

擅长提前看出苗头，是中文互联网第1个意识到 OpenClaw 范式价值的人（1月26日）。

关注我，一起 AIGC 从0到1~