从 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 一个角色，就自动形成团队 |
价值规模化 | 产物能否验收、部署、带来收入或竞争优势 | 代码和内容生成得快，商业价值就会同步增长 |
前两层，已经出现明确的技术突破。
最后一层，仍然远没有答案。
一个团队可以让 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 系统看起来很热闹，但它们并不在争同一个答案。
更准确地说，大家正在尝试四种不同的组织哲学。
路线 | 核心做法 | 适合什么 | 最大问题 |
|---|---|---|---|
中心化协调 | 一个强主 Agent 负责拆解、分配、汇总 | 目标清楚、需要全局判断的任务 | 主 Agent 的上下文和决策会成为瓶颈 |
层级化委派 | Planner、Worker、Judge 分工，形成任务层级 | 大型项目、长时执行、持续迭代 | 信息会在逐层转述中损耗 |
独立并行 | 多个 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 这些词开始频繁出现的原因。
它们听上去像工程术语，背后处理的却是非常具体的问题：
层次 | 它要解决什么 |
|---|---|
Harness | Agent 看见什么、能调用什么工具、如何循环、何时停止 |
Runtime | 会话、沙箱、资源、状态快照、失败恢复 |
Orchestrator | 任务如何拆分、依赖如何安排、结果如何汇总 |
Control Plane | 权限、预算、模型路由、策略、审计和全局约束 |
Verification | 哪些操作可自动放行，哪些结果需要独立检查或人工升级 |
今天很多“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~
