为什么在使用 AI 编码代理进行多任务处理时会出现问题（以及我如何解决的）

Source: Dev.to

AI 编码代理正开始像团队成员一样。

你让其中一个重构一个模块。
另一个编写测试。
第三个原型化一个功能。

单独来看，它们很强大。
但一旦你尝试并行运行它们，情况就会变得混乱。

本文讨论了为什么会出现这种情况——以及我在尝试修复时学到的东西。

多任务问题

运行一次 AI 编码会话很简单。
同时运行三个会话通常是这样的：

• 三个终端窗口
• 多个功能分支
• 手动上下文切换
• 看不清每个代理在做什么

技术上可行。
认知上却难以扩展。

摩擦以小方式出现：

• 忘记哪个终端对应哪个分支。
• 不小心复用了上下文。
• 失去对长时间运行操作的跟踪。
• 因为开销增加而犹豫是否再启动“再来一个”代理。

CLI 给了你力量——但没有结构。

为什么单独使用 tmux 不够

你可以使用 tmux 等工具来改善布局。
这在视觉上有帮助，但并不能解决工作流结构：

• 仍然需要手动创建分支。
• 仍然需要管理隔离。
• 仍然需要记住哪个会话对应哪个任务。
• 仍然缺乏更高级别的组织。

布局不是工作流。
而在与 AI 代理协作时，工作流比布局更重要。

关键洞察

突破在于：

每个 AI 会话都应该像一个独立的特性分支一样自动运行——而不是仅仅另一个终端面板。

一个结构化的环境。

如果 AI 代理是“队友”，那么每个代理都应拥有：

• 它自己的工作空间
• 它自己的 git worktree
• 清晰的视觉边界
• 便捷的创建与销毁

这可以显著降低认知负荷。

为并行 AI 工作进行设计

我开始尝试一个简单的想法：

如果运行多个 AI 编码代理更像是在可视化工作区中管理多个特性分支，会怎样？

而不是：

Terminal A
Terminal B
Terminal C

你会得到：

• Agent Session 1 → Feature branch + isolated worktree
• Agent Session 2 → Separate branch + separate worktree
• Agent Session 3 → Experimental sandbox

一次性全部可见。
全部本地运行。
没有 API 包装器。
没有限制功能的抽象层。

我构建的内容

为了探索这个想法，我构建了 Parallel Code，一个桌面应用程序，它：

• 直接运行 Claude Code、Codex 和 Gemini CLI
• 为每个会话自动创建 git worktree
• 在结构化 UI 中平铺多个代理会话
• 完全保留 CLI 行为

它并不改变代理的工作方式；只是让多任务处理变得实用。

(在此插入 GIF 演示)

我的工作流程有什么变化

在切换到结构化并行会话后：

• 我在生成新代理前犹豫得更少。
• 实验性工作感觉更安全。
• 长时间运行的重构不再阻塞其他任务。
• 上下文切换显得更有意图，而不是混乱。

最大的不同不是速度。
而是清晰度。

更大的问题

现在，大多数 AI 辅助开发假设：

• 一个代理。
• 一个终端。
• 一个任务。

但这可能并不反映我们长期的工作方式。
如果 AI 代理成为真正的协作者，我们将需要更好的方法来：

• 并行运行它们
• 安全地隔离工作
• 在会话之间保持可见性
• 减少心理负担

我们可能正处于多代理未来的 “单代理 IDE” 阶段。

我很好奇

如果你大量使用 AI 编码代理：

• 你会并行运行多个会话吗？
• 你如何管理隔离？
• 终端 + tmux 足够吗？
• 你的工作流程在哪些环节会出现瓶颈？

我仍在迭代这个想法，期待你的深思熟虑的反馈。