开头刷到 SpaceX 工程师演示 AI Coding 的视频时我第一反应和大多数人一样屏幕上那 200 多个 Agent 同时跑任务、同时改代码、同时提 PR视觉效果确实拉满。但盯着看了一会儿我意识到真正值得研究的东西不是模型的代码能力又强了多少而是他背后那套让 200 多个 Agent 不互相打架、不重复劳动、不把仓库搞崩的工程框架。这篇文章不会去复述那个视频而是把它拆开看并行 AI Coding 到底在并行什么200 这个数字是怎么来的以及一个普通团队能不能把这套玩法移植到自己的项目里。我给的结论是能但瓶颈不在于模型也不在于会不会写 Prompt而在于任务切分、调度、验证这套工程配套。如果你已经在用 Codex、Claude Code 这类工具做单 Agent 编码觉得“一个一个改太慢了”这篇文章应该能帮你打开思路。1. 200 个 Agent 并行真正牛的其实是“装配线”先把这个概念说透那个视频里看起来是 200 多个 Agent 在同时干活但底层大概率不是在同一个时刻有 200 个请求打向大模型 API。更合理的理解是这是一条软件工厂装配线Agent 是产线上的工人每个工人只负责一小段工序系统负责把任务排队、分发、验收、合并。视觉上看到的是 200 个并行本质上是调度系统把几千个任务管理得井井有条。1.1 为什么不能用“多开终端”的办法平替很多人尝试过并行 AI Coding第一反应往往是“我开 5 个终端每个终端跑一个 Claude Code 不就行了” 这个想法不算错但做到 5 个已经是极限了。超过这个数你会遇到三个绕不过去的问题第一个是任务分配靠人肉。你得自己判断哪个 Agent 该做哪个模块谁先谁后这等于把调度系统长在自己的脑子里项目一大人就废了。第二个是上下文混乱。Agent 之间互相不知道对方改了什么A 改了接口签名B 还在按旧接口写调用Git 合并时全是语义冲突——不是 Git 解决不了那种冲突而是代码逻辑上直接对不上。第三个是缺少验证关。单个 Agent 写完代码、跑一遍自己写的测试就觉得自己完成了但没人从系统层面确认它有没有破坏别人的功能。真正的 200 Agent 并行是把“人肉调度”变成了“系统调度”把“靠感觉验收”变成了“网关自动验收”把“共享同一个工作目录”变成了“各自沙箱 分支隔离”。这四件事才是这种玩法牛的原因。1.2 “并行”在系统层面是怎么实现的我在自己的项目里复现这套思路时对“并行”有了新的理解。任务队列里的状态不是简单的“执行中 / 完成”而是一套生命周期pending、ready、running、blocked、passed、failed、retrying。调度器每秒钟扫描一次把依赖已经满足的 ready 任务分配给空闲 WorkerWorker 拉起一个容器去执行执行完把结果交给评估网关评估通过才允许合入。所以 200 个并行 Agent 的真实含义是任务队列里处于 running 状态的任务数量是 200 左右但实际在调用模型 API 的 Worker 可能只有 20 个甚至更少。其他任务都在排队、在等待依赖、在跑测试、在等待重试。这是一个“伪高并发”的经典实现方式——把 CPU 密集的模型调用拆成异步任务用队列削峰填谷而不是真的同时发起 200 个并发请求。这也解释了为什么那个视频里的 Dashboard 看起来那么壮观你看到的是 200 个任务同步推进不是 200 个 API 请求同时飞出去。理解这一点很重要因为它直接决定了工程架构该怎么设计。2. 任务切分并行 Agent 的数量上限取决于你的拆分能力很多人在复现这套玩法时第一个卡住的地方不是技术而是“没有那么多任务可分”。200 个 Agent 并行意味着你手里至少有几千个规模合理的任务而且任务之间要尽可能解耦。任务切分是整个体系的起点也是并行度真正的天花板。2.1 一个仓库到底能拆出多少个独立任务拿一个典型的后端项目来算账。假设这是一个电商后台有商品、订单、用户、支付、优惠券五个域。拆任务的时候我会按这几个层次去切API 层每个资源一组端点按域拆出 50 个任务每个任务负责一个子域下的 controller、DTO、校验逻辑、对应接口测试。Service 层按业务用例拆比如“创建订单”“取消订单”“订单超时关单”大概 40 个任务每个任务包含 service 实现和单元测试。Infrastructure 层按存储介质拆MySQL、Redis、消息队列各自独立30 个任务包括 repository 实现、缓存策略、消息消费者。基础工程项目骨架、CI 配置、统一错误码、日志规范、数据库迁移脚本10 到 15 个任务。前端与文档如果仓库是前后端一体前端页面按页面拆文档按模块拆又能多出三五十个。这么一拆一个中等规模仓库轻轻松松就是 150 到 300 个任务。你不需要每个任务都从零写代码很多任务是“改既有代码”“补测试”“修类型错误”“更新文档”这些任务同样能被 Agent 消化。2.2 Task Spec并行时代最重要的文档给单 Agent 发需求你可以一句话说个大概它不懂会问你。但到了 200 个 Agent 并行的场景没人有空回答你的问题Agent 之间也没有群聊可以商量。每个任务必须有一份完整的 Task Spec把所有约束写清楚让 Agent 只需要照着做。我的 Task Spec 通常长这样## 任务实现订单取消接口 ### 目标 在 orders 模块新增一个取消订单接口支持用户对未发货订单执行取消操作。 ### 接口定义 - 路径: POST /api/v1/orders/{order_id}/cancel - 请求体: {} (空对象仅需用户认证) - 响应: 200 OrderCancelResponse - 错误码: 4001 订单不存在 / 4002 订单状态不允许取消 ### 涉及文件仅允许修改这些文件 - src/modules/orders/controller.ts - src/modules/orders/service.ts - src/modules/orders/types.ts - tests/orders/cancel.test.ts ### 禁止修改 - src/shared/ 下的任何文件 - 数据库迁移脚本 ### 验收标准 1. 所有新增文件通过 ESLint 2. pytest / jest 全量覆盖新增代码且测试通过 3. 不影响 创建订单 和 订单查询 两个既有用例你会发现这份 Task Spec 和平时写需求文档最大的区别是它明确划定了“可动范围”。因为并行执行时Agent 没有全局视野如果不限制文件范围它很容易觉得“顺手把这个公共组件的接口也改了更优雅”然后引发连锁雪崩。Spec 里的“禁止修改”和“仅允许修改”就是用来锚定 Agent 活动边界的。2.3 依赖关系怎么办波次调度任务不可能全部独立总有一些天然依赖。比如数据库 schema 没定repository 层的任务就无从下手repository 没写service 层就算写出来也是空转。我的做法是把所有任务建一张 DAG有向无环图依赖方向为“前置任务 → 后置任务”然后按拓扑排序分成若干波次。第 0 波放最底层的任务数据库迁移、基础 schema、项目配置、公共类型定义这些任务全部独立可以满并行跑。第 1 波放依赖第 0 波结果的任务repository 实现、缓存层。第 2 波再放 service 层和 API 层。以此类推每一波内部完全并行波与波之间靠“任务完成回调”自动触发不需要人工介入。这种分波次跑的方式还有一个好处每一波结束都会产生一个“集成点”。我能在这个时间点拉一次全量回归确认这一波合入后仓库依然是绿的再放下一波进场。这比 200 个 Agent 一起乱跑最后集中爆炸要可控得多。3. 并行执行的工程骨架队列、工作池、沙箱、评估网关任务切分是图纸工程骨架是厂房。想让 200 个 Agent 稳跑你需要四件套任务队列、Worker 工作池、沙箱隔离、评估网关。这四样东西缺一个并行的规模都上不去。3.1 用队列而不是“开线程”调度系统的核心是一个持久化的任务队列。每个任务进来时记录 ID、Spec 路径、依赖列表、状态、重试次数、运行日志。Worker 启动时向队列拉取任务而不是由调度器直接 push——这是生产者消费者模式好处是 Worker 可以随时水平扩展宕机了也不会丢任务重启后继续拉。任务状态流转我建议至少要有这几个pending刚入库、ready依赖全部满足、runningWorker 认领、passed评估通过、failed评估失败或运行异常、retrying失败后进入重试。调度器就像一个耐心的前台只做两件事扫描 ready 任务、回收超时任务。队列落在哪种基础设施上取决于你的规模。我列个表给你参考方案适合规模优点缺点SQLite / PostgreSQL 轮询任务量低于几千零额外组件、状态好查轮询频率上去后有数据库压力Redis Queue / BullMQ中等规模、高频调度延迟低、有重试机制任务状态不好审计复杂查询要外挂数据库Temporal / 持久化工作流大规模、长流程重试、超时、状态机都内置引入额外基础设施学习曲线陡我个人的推荐是从 PostgreSQL 轮询开始任务表 一个 worker 定期 SELECT FOR UPDATE SKIP LOCKED 拉任务就够了。等到任务量和并发真的上去了再平滑迁到 Temporal而不是一开始就上重型调度框架。3.2 沙箱让 Agent 随便折腾但别弄脏主仓库200 个 Agent 不可能共享同一个磁盘目录否则互相覆盖文件是迟早的事。每个任务执行时应该拉一个独立的容器或至少一个独立分支来干活。标准做法是每次任务启动用仓库当前分支打一个快照在容器里恢复整个仓库然后切一个任务专属分支让 Agent 在这个分支上改代码、跑测试。容器要限制 CPU、内存、磁盘和超时时间比如单任务最多跑 15 分钟超出直接杀掉。沙箱的核心价值有两个。第一是隔离副作用Agent 里面跑的命令可能是危险的比如“给我安装一个全局工具”“把 node_modules 删了重装”这些副作用被限制在容器里不会污染宿主机。第二是失败隔离一个任务把容器搞崩、把磁盘写满、甚至把内核参数改了其他 199 个任务毫发无伤。打个不太严谨但好懂的比方这就像游乐场的每个项目都有独立围栏一个设施停了别的设施照常排队。3.3 评估网关每份产出都先过测试再谈合并这一环是并行不翻车的命门。我见过太多“多 Agent 协作”项目死在同一个问题上Agent 说“我做完了”然后人就信了。单个 Agent 这么做问题不大顶多代码写得烂但 200 个 Agent 都说“我做完了”没人逐个检查整个仓库会以肉眼可见的速度腐化。评估网关要做的事很简单每个 Agent 完成任务后不直接合入而是先跑一套标准检查。最少要包含这几项cd $WORK_DIR make lint # 静态检查 make typecheck # 类型检查 make test # 单元测试 回归测试 make build # 确保产物能构建只有四条全绿任务才允许 commit、push、创建 Merge Request。只要有一条挂了任务标记 failed把失败日志回传给 Agent让它自己修最多重试三次三次还不过就标记 blocked 转人工。这个设计有一个很微妙的地方Agent 自己写的测试不能作为唯一验收标准。因为 Agent 的“自洽”能力很强——它写一个函数再写一个测试去测这个函数实现和测试共享同一套错误假设结果是绿的但功能在真实场景下根本跑不通。我后面会细讲这个坑。4. 调度系统的真实面目失败、重试、合并与上下文隔离四件套搭好只是万里长征第一步。真正跑起来之后你会发现调度系统不是“把任务丢给 Agent 就完事”而是每天二十四小时在处理异常。这一节把最容易出事、也最容易被忽略的几个环节拎出来讲。4.1 Agent 执行失败的四种典型原因我跑过几百个任务之后把失败原因基本归成了四类第一类是 Task Spec 含糊。比如“优化一下这个函数的性能”这个描述根本没有验收标准Agent 自由发挥的空间太大跑出来的结果五花八门。解决方法是把验收标准量化改成“在 X 数据集上P95 延迟降低 30%且所有测试通过”。第二类是环境问题最常见的是缺依赖。Agent 在沙箱里跑测试发现缺一个包它有两种选择自己装或者改代码绕过。自己安装没问题但有些 Agent 会“顺手”改代码让它在缺依赖的情况下也能跑通这就很危险。解决方法是沙箱镜像里预装项目全部依赖并禁止 Agent 修改依赖清单除非 Spec 里显式授权。第三类是测试写错。Agent 为了让测试通过把断言写得过于宽松比如只检查返回值类型不检查值。这是最讨厌的失败因为网关是绿的代码是烂的。后面我会专门讲怎么防。第四类是依赖任务没真正完成。上游任务是“实现 createOrder”Agent 只写了 interface 没写实现但自测时用了 mock结果下游任务一接真实实现就炸。解决方法是把“上游任务必须提供真实可运行的实现”写进 Spec 的禁止项并在评估网关上额外跑集成测试而不是只跑单测。4.2 上下文隔离与“选择性失忆”200 个 Agent 并行时上下文的管理策略跟单 Agent 完全不同。单 Agent 对话可以越长越好能记住之前聊过什么并行场景下系统反而要主动给每个 Agent “清空记忆”让它只专注当前任务。具体做法是Agent 拿到的上下文由三部分组成Task Spec 全文、被授权文件的内容、相关接口签名。其他东西一概不给。仓库的其他部分如果有关联应该在 Task Spec 里用“参考接口”的章节列出来Agent 通过读文件而不是靠猜来获取。这么做有两个原因。第一是省钱省 token一个仓库几十万行代码不可能全塞进每个 Agent 的上下文200 个 Agent 重复读一次就是十倍百倍的开销。第二是减少幻觉上下文越宽Agent 越容易“过度联想”干出超出任务范围的活。给得越少它越老实。全局记忆由调度器保存而不是由 Agent 保存。比如“哪个文件正在被哪个任务改”“哪些任务已经完成了”这些信息存在任务表里由调度器统一管理。Agent 不需要知道自己之外的世界发生了什么系统替它记着就行。4.3 合并冲突写不进 Git 的语义冲突更麻烦文件层面的冲突Git 的三路合并能解决大部分。两个 Agent 各改各的文件最后合入主分支时基本不会冲突。真正头疼的是语义冲突任务 A 改了下单接口的返回结构任务 B 在新写的支付回调里用了旧返回结构。两个任务单独跑测试都是绿的合并之后集成测试一跑就炸。我的兜底方案是三道防线在 Task Spec 里声明“接口契约”把公共接口定义放在共享文件里并标记为禁止单任务修改。谁要改接口必须走一个单独的“接口变更任务”变更完成后再放行下游任务。每一波任务合并完成后强制跑一次全量构建和全量测试任何失败都回到“上一波绿点”而不是勉强修复。合入主分支的权限归调度器不归 Agent。Agent 永远只 push 到自己的任务分支合入动作由系统在评估网关绿灯后执行。5. 工具选型与落地路径从几个 Agent 到上百个 Agent这套体系听起来很重但落地时你可以从很轻的配置开始。关键是选对工具组合并且知道每一步投入进来的成本值不值。5.1 单 Agent 引擎怎么选Worker 里真正干活的“手”通常是一个 CLI 版的编码 Agent。我试过几种主流的简单说下感受引擎特点适合场景Codex CLI命令行原生、能自己读仓库、能执行命令自动化流程里的 Worker适合并行接入Claude Code对话体验好、上下文理解强、工具调用稳需要仔细推理的复杂任务Aider轻量、Git 原生、便宜小任务批量执行和已有命令行的集成方便ClineVS Code 插件也能命令行调用希望在图形界面下观察单任务执行细节我的习惯是“装配线两头用贵模型中间用便宜模型”任务切分和最后的代码评审用 Claude 这类逻辑推理强的中间几十个执行 Worker 用 Codex 这类适合自动化的。贵模型不值得铺满 200 个任务便宜模型跑批量任务边际成本低效果也不算差。5.2 编排层Temporal、LangGraph 还是自研编排层是很多人的纠结点。LangGraph 是现在 Agent 圈最火的框架适合编排“少数几个有记忆、有状态、需要互相协作”的 Agent但它是为“Agent 对话”设计的不是为“200 个工人的工厂流水线”设计的。真要做大规模任务队列LangGraph 里那些会话记忆、图状态同步会成为负担。我自己更倾向用 Temporal 这类持久化工作流引擎来当调度底座。它有内置的重试、超时、心跳机制任务跑了一百分钟突然 Worker 挂了Temporal 会自动把任务重新丢到队列里。200 个 Agent 并行时这种可靠性比“内存里维护一个状态机”要踏实得多。如果项目只是练手也可以用最简单的方案PostgreSQL Python 脚本 系统 crontab。调度器每分钟扫一次任务表把 ready 任务塞到队列中间件Worker 起来跑容器。代码量不大但逻辑完整。等你真的需要了再把调度层替换成 Temporal任务表结构可以基本不动。5.3 成本与速率的一个粗算关于 200 个 Agent 并行很多人最关心的是“烧钱吗”。我按一个中等仓库粗略算一下假设总共 300 个任务每个任务输入约 30k token包含 Task Spec、相关代码输出约 5k token单个任务耗 35k token一个全程下来就是 10M token 量级。如果全用顶级模型按输入输出混合价算一次大改造可能花几百到上千美元如果换成偏便宜的模型跑执行层成本能压到三分之一。速率方面真正的瓶颈是模型 API 的限流。假设你不走批量接口单 key 每分钟上限 500 次请求那么工作池开 20 个并发就已经很激进再高没意义因为都在排队等限流恢复。所以 200 个并行 Agent 里的数字应该理解为“系统管理着 200 个在途任务”而不是“同时发起 200 个模型请求”。6. 这套玩法的边界与我的个人复盘搭建并跑了这套并行体系之后我对“AI Coding 大规模并行”有了更清醒的认识。它确实能带来数量级的交付速度提升但它不是银弹。任何一个环节做得不到位并行带来的问题可能比单 Agent 还多。6.1 为什么大多数人不需要真的上 200 个并行先泼一盆冷水如果你的项目在 10 个任务以下或者任务之间强耦合强行上并行只会增加调度开销。我见过有人为了“并行”硬把一个大功能拆成 20 个小任务结果每个任务都在改同一个模块合入时冲突解决花掉的时间比单 Agent 做完整件事还长。判断该不该上并行看三个条件任务量够不够多、任务之间够不够独立、有没有可靠的自动评估手段。三个条件缺两个老老实实单 Agent 串行跑完更划算。并行不是炫技是一种匹配特定负载的架构。以我实际项目为例改造一个维护了三年的老服务代码结构乱、测试覆盖低。我不敢让 200 个 Agent 自由发挥而是先跑了一个“基础设施 Agent”把类型检查补上、把旧测试框架迁到新版本等仓库绿了再放 50 个并行任务去按模块重构。这个渐进过程明显更顺因为它先制造了一个安全的并行前提。6.2 我踩过的三个坑模糊约束、自洽测试、并发写公共文件第一个坑是模糊约束。我最初给 Agent 的任务描述里有“优化”“重构”“改进”这类日常词结果一个 Agent 把公共错误码枚举从 string 改成了 int理由是“int 更规范”。单独看没问题但它牵一发动全身下游十几个任务全部爆红。后来我把所有任务描述改成了“目标 可动文件 验收标准 禁止项”四段式类似“只允许修改指定的 4 个文件禁止修改公共类型定义”再没出过这种问题。第二个坑是 Agent 自己写测试自己过。有一次审查一个 Agent 的产出发现它提交了一个缓存模块测试文件只有两个用例一个测“能拿到缓存”一个测“缓存为空时返回 null”都是空壳断言。真正的缓存击穿、过期、并发写根本没人验证。解决办法是对关键技术任务测试用例由我预先写好Agent 只写实现一般任务至少要求测试覆盖率达到某个指标而不是“只要有测试就行”。第三个坑是并发写同一个公共配置文件。两个任务同时往 package.json 里加依赖后提交的覆盖了先提交的。后来我把这类公共文件的写入全部串行化统一由一个“依赖更新 Agent”处理其他 Agent 在 Spec 里就只能读不能写。6.3 如果你要从零开始尝试我的操作建议先别急着复刻 200 个 Agent 的全套架构。我自己就是一步一个台阶踩过来的给一条平滑路径先跑通“3 个 Agent 并行 人工 review 人工合并”把 Task Spec 的写法、评估网关的检查项磨顺再上“10 个 Agent 队列 沙箱”体验一下自动化调度带来的效率提升最后才是多 Worker 并行、自动合入、失败自动重试。每个阶段都要有一个明确的硬指标比如从 3 到 10 的过程以“零手工修复代码”为目标——所有代码产出都被 Agent 自己修到通过你再出手就算失败。指标达到了再推到下一个规模。这样你的整套基础设施是被真实压力锻炼出来的而不是一次性搭个看起来很美、一跑全崩的纸壳子。最后再说一个让我印象深刻的细节那套 200 个 Agent 并行的演示里最出彩的其实不是 Agent 写代码的速度而是它把“每个任务从开始到合入平均只要几分钟”这件事稳定地跑了下来。做到这一步技术含量不在模型层而在调度、隔离、验证这些“不性感”的工程活上。这也是我写这篇文章最想传达的东西——AI Coding 的上限很大程度取决于你的工程下限。