北京
你用Claude Code同时开着几个会话窗口写代码，有的改测试，有的写文档，有的找bug。表面看效率拉满，但几个分支同时往主线上提交修改的那一刻，冲突、排队、权限混乱全来了。
这事最近被 OpenAI 负责强化学习与 Agent 基础设施的工程师阿比谢克·巴德瓦杰拎上台面聊透了。他在一场题为《从 fork() 到舰队》的演讲中，把问题直接拉到基础设施层面：多个 AI Agent 同时产代码时，怎么才能不把生成速度变成审核排队、分支冲突和环不隔离的灾难？
他给出的判断很直接。该扩的不是同时聊天的窗口数量，而是一个可控的工作流。并行有价值的前提是：每个任务有明确归属、结果可被独立验证、运行在隔离的沙箱里。一旦把一个大任务拆得稀碎，协调开销、启动成本、同步消耗和 review 压力会瞬间吞掉所有提速红利。
巴德瓦杰画出的 Agent 编队是这样的：由一个 Planner 把目标拆成真正独立的子任务，设定好每条任务的完成标准；两到三个 Worker 各自拿到独立的 worktree 或沙箱去干活；Verifier 按预设的测试条件和约束检查产出；人最终拍板 merge、授权和下一步走向。在这套模型里，共享的对象不是全部上下文，而是任务定义、文件边界、验收标准和决策日志。
他在七月的演讲中重点拆解了 fork/exec、容器、gVisor 和 microVM 几条路线的取舍，还讨论了持久存储、快照和沙箱环境调度的问题。核心工程判断是：长任务和实验分支需要可保存的状态，而沙箱该放在哪里，很大程度上取决于已有的快照层分布。这不是一份“按这个搭就稳了”的操作手册，但它点出一个极易被忽视的拐点：并行问题变成基础设施问题的时间，比你坐在聊天窗口前感受到的要早得多。
已经冒头的一批小工具开始围绕并行 git worktree、运行时治理和 Agent 的“飞行记录器”做文章了。它们的出现并不意味着市场有了赢家，但足以说明问题已经跨过单次模型响应质量这个讨论阶段，进入了协作架构的深水区。真正有效的并行，不是让更多 Agent 同时开工，而是从一开始就为它们划好地盘、定好规矩、备好验证手段。做不到这一点，提速只是账面上的幻觉。
特别声明：以上内容(如有图片或视频亦包括在内)为自媒体平台“网易号”用户上传并发布，本平台仅提供信息存储服务。
Notice: The content above (including the pictures and videos if any) is uploaded and posted by a user of NetEase Hao, which is a social media platform and only provides information storage services.
