当一千个Agent 开始工作，真正稀缺的是什么？

本文来自微信公众号： AIGC从0到1 ，作者：王零壹，原文标题：《当一千个 Agent 开始工作，真正稀缺的是什么？》

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

—

最近X上最容易让人热血沸腾的画面，是这样的：

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

屏幕像一家公司。

于是，“一人公司”又被推到了一个新高度：过去一个人加AI，像多了一个助手；现在，一个人似乎可以拥有几十、几百，甚至上千个数字员工。

Anthropic 11月9日发布Fable 5.2时披露，一位工程师曾让模型协调超过1,000个子Agent，持续八天，从空文件夹开始构建了一个可在笔记本上启动的操作系统原型，包含驱动、文件系统、窗口、登录界面等。这个实验当证明了一件事：Agent的执行规模，已经开始越过过去单一对话框的边界。

Google的动作也很直接。Antigravity刚推出的/swarm，把协调者、隔离的worker、对抗式verifier、共享消息板和执行图谱放进同一个工作流里。它卖的不是“更会聊天的模型”，而是一个可以调度一群模型的工作现场。

但问题也随之变了。

过去我们关心的是：模型能不能写出一段代码、完成一次研究、调用一个工具。

现在更棘手的问题是：当一百个、上千个Agent同时开始行动，谁来保证它们没有重复劳动、没有互相覆盖、没有把错误层层传递，最后真的交付了一个人类愿意接受的结果？

一人公司的真正门槛，可能从来不是“能不能调动更多Agent”。

而是：能不能把越来越多的智能执行能力，组织成一个可信、可审计、可验收的系统。

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

一千个Agent不是一千个员工。

员工会积累对组织的理解，会承担长期责任，会知道一个决定对客户、品牌、团队和自己的职业意味着什么。Agent可以被迅速复制、快速启动、同时运行，也可以迅速犯下同一种错误，并在几分钟内把它复制一千遍。

因此，Agent的规模化至少有三层，不能混成一件事。

前两层，已经出现明确的技术突破。

最后一层，仍然远没有答案。

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

这也是为什么，今天看到的“一人公司”故事，应该被拆成两句话。

第一句是成立的：以前需要一个5—10人执行团队完成的一部分工作，现在确实可能由1—2个人加一套成熟的Agent系统完成。

第二句则远未成立：因此，一个人已经等于一家完整公司。

前者是生产函数正在变化。

后者是把执行能力的变化，过早地翻译成了商业现实。

二、更多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，但它不再让coordinator独自承担所有上下文转述：worker在隔离worktree中工作，verifier专门质疑diff和运行测试，系统用共享、追加式消息板保存协作过程。Google明确把它定位为一种对单Agent和脆弱层级链的修正：不是让一个总指挥记住一切，而是让团队成员围绕同一块可追溯的工作面协作。

中心化的代价也很明显：主Agent会变成认知瓶颈。

所有关键任务都要它看、它判、它汇总。只要coordinator的上下文开始变长、优先级开始混乱、计划开始陈旧，整个系统就会像一个过度依赖CEO的公司一样，陷入等待。

2.层级化委派：让Agent也拥有“中层管理者”

Cursor的实践很值得看，因为它最早尝试过相反的路线。

最初，Cursor让Agent平等协作：每个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可以说“任务完成”。但这距离可合并、可部署、更不用说可持续创造价值，往往还有很长的路。

METR在今年3月请真实维护者审查了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，不是一千名员工。

它们是一千个需要被组织、被约束、被验证、也最终需要有人为其结果负责的执行单元。

所以，下一代软件真正争夺的，或许不只是更强的模型，而是谁能先把“组织智能劳动”这件事，做成一种可靠的基础设施。