多 Agent 并行工程：从审查瓶颈到可扩展工作流架构

7 月 20 日，AI LABS 的作者展示了如何通过多个并行的 Claude Code 会话和 git worktrees 进行开发。如今，不再是单个 AI Agent 等待下一条指令，而是由人把彼此独立的工作拆分到多条并行分支中。就在一周前，OpenAI RL and Agent Infrastructure 团队工程师 Abhishek Bhardwaj 也在题为《From fork() to Fleet》的演讲中，把同一个问题提升到了基础设施层面。

这并不能证明“舰队”已经成为行业标准。但它体现了一个重要的实践转向：如果多个 Agent 可以同时提交代码，怎样才能避免让生成速度最终变成 review 队列、分支冲突，以及环境中过度开放的权限？

简短的答案是：应该扩展的不是聊天会话数量，而是可管理的 workflow。只有当任务能够拆分为多个部分，并且每个部分都有明确的负责人、可验证的结果和隔离的工作环境时，并行才有价值。如果任务拆解不当，并行反而可能加速协调噪声，而启动、同步和 review 的成本也会吞噬并行带来的收益。

“舰队”的起点不是 Agent 数量

用简单的话说，什么是 AI Agent？它是一种模型，你要求它做的不只是回复聊天消息，而是在规定的边界内执行一系列操作：研究代码、提出修改、运行可用工具，并留下可供检查的产物。

单个助手可以在共享分支中工作。而一支 AI Agent 团队则需要不同的组织方式：

• planner 把目标拆解为彼此独立的子任务，并定义完成标准；

• 两到三个 worker Agent 分别获得独立的 worktree 或 sandbox；

• verifier 根据预先定义的测试和约束检查结果；

• 人类负责决定是否 merge、授予哪些权限，以及下一步做什么。

这就是 Agent 编排在实践中的含义：不是让多个模型彼此对话，而是把具体产物的责任分配出去。需要共享的并不是所有上下文，而是任务描述、文件边界、验收标准和决策日志。

在 7 月的演讲中，Bhardwaj 分析了 fork/exec、容器、gVisor 和 microVM 之间的权衡，以及 persistent storage、snapshots 和 sandbox 环境调度。他提出的是一个工程观点：长时间运行的任务和实验分支需要可持久化的状态，而 sandbox 的部署位置也取决于已经可以使用的 snapshot 层。这并不是唯一正确架构的标准答案，却是一个很有价值的判断依据：并行化成为基础设施问题的时间，比你从聊天窗口中观察到的要早。

围绕 git worktree 并行运行、runtime governance，以及 Agent “flight recorder” 出现的一些小型工具，也印证了这一模式。这些工具仍处于早期阶段，并不意味着市场胜负已定，但至少说明，问题已经不再只是单次模型回答的质量。

收益出现在哪里

只有同时满足以下三个条件，并行工作才是合理的。

子任务之间的关联较弱。例如，一个分支负责编写测试，另一个更新文档，第三个调查独立模块中的错误原因。如果两个分支修改的是同一个契约或同一组文件，coordination tax 很快就会吞噬收益。

子任务之间的关联较弱。例如，一个分支负责编写测试，另一个更新文档，第三个调查独立模块中的错误原因。如果两个分支修改的是同一个契约或同一组文件，coordination tax 很快就会吞噬收益。

结果能够被验证。每项任务都有输入、预期产物，以及帮助人类确认具体完成内容的测试或判断标准。对于 Agent 舰队来说，“改进这个模块”远不如“在不修改 public API 的前提下，为场景 X 添加测试”有效。

结果能够被验证。每项任务都有输入、预期产物，以及帮助人类确认具体完成内容的测试或判断标准。对于 Agent 舰队来说，“改进这个模块”远不如“在不修改 public API 的前提下，为场景 X 添加测试”有效。

环境和权限相互隔离。负责编写测试的 Agent 不一定需要 production credentials。负责研究代码仓库的 Agent，也不一定需要执行网络操作或访问本地 daemon 进程的权限。

环境和权限相互隔离。负责编写测试的 Agent 不一定需要 production credentials。负责研究代码仓库的 Agent，也不一定需要执行网络操作或访问本地 daemon 进程的权限。

在这种模式下，多 Agent 系统可以减少独立步骤之间的等待时间。但不能承诺线性加速：每增加一个执行者，都会带来任务描述、启动成本、检查、同步和冲突风险。这里最有价值的变化不是“更多 Agent”，而是更严格地定义工作。

转折：sandbox 不能取代信任边界

人们很容易认为，只要为每个 Agent 分配一个 sandbox，问题就解决了。Pillar Research 最近的一项分析改变了这种直觉：研究人员描述了他们在 Cursor、Codex、Gemini CLI 和 Antigravity 中复现的 sandbox 边界绕过方式。

作者把这些机制归纳为几类：基于 denylist 的方案、workspace 中可执行的配置、对所谓安全命令名称的信任，以及拥有特权的本地 daemon 进程。有些问题已经得到修复，另一些则被厂商认为难以利用。我们不能据此断定，这些产品的所有版本都仍然存在漏洞，或者所有 sandbox 都毫无用处。

更准确、也更有限的结论是：AI Agent 的安全性不会随着隔离机制自动出现。Workspace、hooks、编辑器、Docker socket、网络、credentials 和本地服务构成了不同的信任桥梁。同时工作的 Agent 越多，就越需要了解每种角色能够接触哪些桥梁。

因此，反对 Agent 舰队的一项有力意见确实成立：Agent 往往需要访问文件、网络和凭据，否则它的作用会非常有限。但让它变得有用的权限，也会扩大潜在损害的范围。理性的应对方式既不是宣布自主 AI Agent 已经安全，也不是禁止所有实验，而是把真正的 security boundary 下沉到运行环境中，并根据具体任务授予最小权限。

Review 正在成为新的瓶颈

加快修改代码的速度，并不等于加快交付速度。在 ClassIsland 项目的一个 pull request 中，7 月 19 日的讨论具体展示了问题的另一面：参与者批评了完全由 AI 生成、却未经人工检查的修改。这不能代表所有 AI 代码的质量，但已经足以清楚地反映 review 所承受的压力。

当只有一个 Agent 时，reviewer 只需要检查一条思路和一个 diff。当 Agent 数量增加时，reviewer 还必须回答更多问题：

• 两个分支是否用不同方式重复完成了同一件事；

• 一个局部正确的 patch 是否破坏了相邻契约；

• 测试是否真的验证了需求，而不是为了适配实现而调整；

• 新增的依赖、命令和权限从何而来；

• 结果能否在干净环境中复现。

因此，比起把 AI Agent 的记忆保存成无穷无尽的对话，更有用的方式是把它保存为一组可验证的产物：任务描述、计划、diff、命令、测试结果、假设，以及 reviewer 的决定。这样不仅能了解 Agent 提出了什么，还能知道它是在什么条件下完成这些工作的。

为期一个工作日的 Canary

不要一开始就搭建 AI Agent 创建平台，也不要立即设计十几个角色。先在一个真实但可逆的任务上，进行范围有限的实验。

选择一项能在一天内完成的工作，例如，在不修改 public interface 的前提下添加测试并修复一个隔离的缺陷。

指定一名人员担任任务负责人和 final reviewer。

把工作拆分到两个并行分支中，确保它们涉及的文件互不重叠，或者拥有清晰的契约边界。

为每个分支设置独立的 worktree 或 sandbox、最小访问权限，以及严格的时间和预算上限。

要求 Agent 不仅留下 diff，还要附上简短的命令列表、测试结果、假设和未解决的问题。

只有在完成 human review，并在干净上下文中运行检查后，才能合并结果。

记录四项指标：获得可验证结果所需的时间、成本、人工修正次数，以及 merge 前发现的缺陷数量。

Canary 结束后的决定，只需要对下一步给出二元结论，而不是一次性决定整个战略。如果两个分支都产出了高质量、可验证的结果，并且没有让 review 不堪重负，就在类似任务上重复这一 workflow。如果负责人花在协调上的时间，比在实现阶段节省的时间还多，就减少角色数量，或者退回到单 Agent 模式。

provod.ai——连接持续发展的 AI 市场的统一入口

新的热门模型会以最快速度接入：当新供应商出现时，团队不需要重新构建集成，API、余额和熟悉的工具都能保持不变。具体模型是否可用，可以在实时目录中查询。

一个目录即可覆盖当前用于文本和媒体处理的主流模型：OpenAI 的 GPT、Anthropic 的 Claude、Google 的 Gemini、xAI 的 Grok，以及 DeepSeek、Qwen、GLM、Kimi 和 MiniMax；图像模型包括 Nano Banana 2 Pro 和 GPT Image；视频模型包括最新版本的 Seedance、Kling、Veo 和 Google Omni。此外，还有用于 reasoning、搜索、文档、embeddings、音乐和音频的模型。

新模型上线时，provod.ai 不会额外收取“尝鲜税”：价格与供应商官方费率保持 1:1。

查看 provod.ai 的最新能力：注册表单 · 模型价格 · 符合 152-ФЗ 的数据保护 · provod.ai 首页

当 workflow 已经确定后，可以根据角色选择不同模型：用一种模型负责规划，另一种负责实现，第三种负责 review。通过 provod.ai，可以使用统一 API 访问这些模型，并以卢布支付使用费用。

但这只是模型访问和 billing 层。provod.ai 不会替团队创建 agent fleet、sandbox、worktrees、scheduler、policy engine 或 review 系统。首先要建立一个能够复现、结果可以衡量的 workflow，然后才有必要增加同时运行的 Agent 数量。

对于你的团队来说，哪种成本更高：让一个可验证的 Agent 以较慢速度推进，还是投入资源建设隔离和 review 机制，从而安全地运行多条并行分支？

如果需要采取进一步行动，你可以考虑屏蔽此人和／或举报滥用行为。