为什么运行多个 AI 编码代理会导致混乱（以及我们如何解决）

Source: Dev.to

梦想：并行 AI 编码

你有一个复杂任务——重构涉及 API、前端、测试和文档的 12 个文件的 auth 模块。

单个 AI 代理（Claude、Copilot、Cursor）需要 20‑30 分钟。它可能会触及上下文限制，并且会顺序处理文件。

于是你想：“我只要打开 5 个终端把工作拆开就行。”

现实：5 分钟的混乱

• 终端 1： 开始重构 auth.rs

• 终端 3： 也开始编辑 auth.rs → ❌ 文件冲突。一个覆盖了另一个。

• 终端 4： 编写引用 api.rs 中函数的测试

• 终端 2： 还没有写那个函数 → ❌ 依赖失败。

• 终端 5： 为 /auth/login 接口编写文档

• 终端 3： 刚把它改名为 /auth/signin → ❌ 引用已过时。

没有协调的并行 AI 编码比顺序执行更糟。你在执行上省了时间，却在冲突解决上失去更多。

为什么现有方案不适用

• 多代理框架（AutoGen、CrewAI、LangGraph）：
  它们协调代理之间的对话，适用于通用工作流，但不管理文件锁、依赖顺序或代码库层面的冲突防止。

• 手动协调：
  你成为调度者，决定哪个终端处理哪个文件，检查冲突并管理依赖。结果自己成了瓶颈。

• 单一代理：
  安全但慢。没有并行性，且在大任务上会触及上下文限制。

实际需要的东西

• 任务拆解： 将模糊请求分解为具体、可并行的子任务。
• 依赖管理： 知道哪些任务必须先完成，其他任务才能开始。
• 文件锁定： 防止两个工作者同时编辑同一文件。
• 监控： 实时查看每个工作者的操作。
• 恢复机制： 在不需要人工干预的情况下处理失败。

这些需求不需要智能，只需要确定性的编排。

我们的方案：Jupiter

我们正在构建 Jupiter —— 一个基于 Rust 的并行 AI 编码代理编排引擎。一次指令，N 个工作者，零冲突。

关键洞见：编排不需要 AI。 调度、锁定、监控和路由都是确定性操作，我们用 Rust 实现（零 token 消耗）。Claude 仅用于规划和编写代码。

更多架构细节将在本周发布。

网站：
Discord: