夜雨聆风Replit 刚刚发布 Parallel Agents——一个应用最多可以同时交给 10 个 AI 代理去改，每个代理拿到应用的独立副本，在自己的环境里独立运行，完成后由系统自动合并代码。官方博客透露，合并冲突的自动解决率达到 90%。这套机制把软件工程里的「分支并行开发」直接产品化，面向所有 Replit 用户开放。
一个应用，十个代理同时下手
5 月 12 日，Replit 在 X 上官宣了 Parallel Agents，33 万人围观。
"Meet Replit Parallel Agents. Build faster by running up to 10 agents in parallel. Each agent gets its own copy of your app. They work on their own computer. Then merge their work agentically."
「最多 10 个代理并行运行。每个代理拿到你的应用的一份副本，在自己的机器上工作，然后自动合并各自的成果。」
▲ Replit 官方帖：最多 10 个代理并行工作，各自拿到应用副本，完成后自动合并（33.5 万次浏览）
这段话拆开来看，有三层意思：
第一层，每个代理拿到的是完整的应用副本。类似 Git 里的分支——你 fork 出去 10 份代码，10 个人各改各的，互不干扰。
第二层，每个代理跑在独立的计算环境里。一个代理改前端样式的时候，另一个可以同时调后端接口，第三个在写测试——它们在物理层面就是隔离的。
第三层，合并由系统来做。官方用了一个词叫 agentically merge，意思是 AI 来负责判断怎么把 10 份修改合回到一个代码库里。
合并冲突自动解决率 90%，怎么做到的？
并行跑 10 个代理，启动不难。难的是最后一步：怎么合并？
10 个代理各改各的，改同一个文件怎么办？改了互相矛盾的逻辑怎么办？一个加了字段，另一个删了同一个字段怎么办？
Replit 官方博客"Live from HQ"系列里给出了部分答案。工程师 Peter 主导了 Agent 4 的并行任务系统，核心就是合并冲突的自动解决。
▲ Replit 官方博客：五位团队成员拆解 Agent 4 背后的工程细节
博客里提到了几个关键设计：
依赖排序先行。多个任务并行启动前，代理会先推理出任务之间的依赖关系——比如登录系统要先于管理后台，代理会自己排好顺序，能并行的才并行。
模型分工协作。表面上看只有一个代理，底层其实是一组专用模型的流水线：一个负责探索，一个负责测试，一个负责管理并行子代理的协调。
90% 的冲突自动解决。Peter 给出的说法是，代码模型的能力已经跨过了一个临界点——它们能理解每个分支在「试图做什么」，然后像开发者一样去解决冲突。剩下 10% 的边缘情况，会浮出来交给用户处理。
Parallel Agents 在产品里长什么样？
打开 Replit 官网，Agent 4 的产品页已经把 Parallel Agents 放进了核心功能区。
▲ Agent 4 产品页强调「Design while Agent 4 builds」——你改设计，代理同步在改代码
▲ Replit 官网首页：Parallel Agents 与 Infinite Canvas、Ship Anything 并列为核心能力
官网描述的使用场景是：你在 Infinite Canvas 上调整设计，同时代理在后台并行处理多个开发任务。你可以实时看到每个代理在做什么，哪些任务已经合并到主线，哪些还在进行中。
Replit 把这套体验类比为「写代码版的 Google Docs」——多人（多代理）实时协作，你随时可以跳进某个代理的任务里看它在做什么，审查它改了什么，在它合并到主线之前就做出判断。
开发者怎么看？意见两极分化
推特上的反应很有意思。
一派觉得这是正确方向。有用户说：
"10 agents running in parallel is where building starts to feel like a lever instead of a grind. The bottleneck shifts from hours of work to quality of direction."
「10 个代理并行运行，构建应用开始像杠杆而不像苦力活。瓶颈从工作时长转向了方向判断的质量。」
"The future dev stack might just be humans supervising systems."
「未来的开发技术栈可能就是人类监督系统。」
另一派直接把矛头指向合并环节。
"Running 10 agents in parallel is the easy part. Getting them to not undo each other's edits at merge time is where this lives or dies."
「并行跑 10 个代理是容易的部分。让它们在合并的时候不互相撤销对方的修改，这才是生死线。」
"Parallel agents are cute until your merge strategy silently corrupts shared state."
「并行代理看起来很酷，直到你的合并策略悄悄破坏了共享状态。」
"10 parallel agents only compound output if the merge layer owns dependency graphs, tests, conflict resolution and rollback. Otherwise parallel coding turns into 10 branches of review debt instead of 10x delivery."
「10 个并行代理要真正叠加产出，合并层就必须管好依赖图、测试、冲突解决和回滚。否则并行编码只会变成 10 个分支的审查债务，根本换不来 10 倍交付。」
还有人更尖锐：
"Replit's betting 10 confused agents outperform 1 focused one. Bold."
「Replit 赌的是 10 个各自迷糊的代理能赢过 1 个专注的代理。够大胆。」
社区已经出现实际痛点
Replit 社区论坛里，一个标题为「Context and Intent Deficit in Agent 4」（Agent 4 的上下文与意图理解缺陷）的帖子记录了更具体的问题。
▲ Replit 社区搜索"parallel agents"，出现 Agent 4 上下文/意图缺陷的讨论
用户 mikeamancuso 写道：Agent 3 和 Agent 4 在向子代理传递上下文和意图时，表现差距巨大。他的项目在 Agent 4 上线后频繁出现破坏性改动（breaking changes）。以前 Agent 3 能在一两个小时内独立完成的复杂任务，Agent 4 需要四到六个小时并且需要全程人工辅助。
他的团队最终决定：回滚 Agent 4 上线后的所有改动，休息一周，等 Replit 修好问题再说。
这个反馈指向一个核心矛盾——并行代理提高了速度，但如果单个代理的上下文理解能力下降了，跑再多个也只是把错误并行化。
Vibe Coding 的下一个拐点
把 Replit Parallel Agents 放进 vibe coding 工具的演进线来看，节奏越来越清晰：
第一阶段：对话生成代码。你告诉 AI 你想要什么，它吐出一段代码。Cursor、GitHub Copilot、早期的 Replit AI 都在这个阶段。
第二阶段：代理直接改项目。AI 拥有了对整个项目的上下文理解，可以直接修改文件、运行测试、处理错误。Replit Agent、Cursor Agent、Devin 都在这个阶段发力。
第三阶段，就是现在——多代理并行。一个项目同时有多个代理在不同方向上探索，代理之间有任务分工、依赖排序、冲突解决和合并机制。
这个演进方向的逻辑很明确：软件开发的真正瓶颈在于「能不能同时推进多个方向并保持一致性」，单纯写代码早就不是卡点了。
Parallel Agents 本质上把软件团队里的工程实践——分支开发、并行任务、代码审查、合并冲突解决——打包成了一个产品功能，提供给可能只有一个人的开发者。
但问题也在这里。软件工程团队之所以需要代码审查和合并流程，就是因为并行开发天然会产生冲突。人类工程师处理合并冲突靠的是对业务逻辑的深度理解，靠的是跨模块的架构判断。AI 代理在 90% 的场景下能自动解决冲突，剩下 10% 恰恰是最关键、最容易出事的部分。
谁来审查代理的合并结果？谁来判断 10 个代理各自的改动放在一起有没有产生意料之外的交互？当用户连代码都不写的时候，他有能力做这个判断吗？
Replit 给出的答案是把工具做到足够透明——你能看到每个代理在做什么，你能在合并前审查，你能回滚。但透明度解决的是信息问题，解决不了能力问题。
vibe coding 的下一个瓶颈，大概率会卡在人类审查 AI 代码的速度上。10 个代理同时交活，谁来验收？
— END —
