开九个终端跑 AI 写代码，第十个用来检查前九个

有人开了九个终端跑 AI 编码代理，最后发现唯一在并行的是焦虑。这条回复出现在 Emdash 的推文下面，点赞不多，但说清了很多人现在的桌面状态。

Emdash 是一个开源桌面应用，Apache-2.0 许可，目标很具体：让开发者同时跑多个 AI 编码代理，不用在终端窗口之间来回切。每个任务有自己的 Git worktree 和分支，本地项目可以，通过 SSH/SFTP 连远程机器也可以。它不绑定某一家代理，直接调用你已经装好的 CLI，比如 Claude Code、Codex、OpenCode、Amp。

功能可以压成几条：隔离 worktree，代理改的东西留在各自分支；GitHub、Linear、Jira 里的 issue 和 ticket 可以直接送进代理；应用内看 diff、CI 检查、创建 PR、合并；远程项目通过 SSH/SFTP 接。有网友补充，README 里的流程是 review diff、开 PR、查 CI、在应用内合并，每个代理的改动走正常 PR 回主分支。

评论区里，worktree per task 基本是共识。Rohan Bhanot 说这是唯一清醒的跑法，但合并回去仍然疼。Nash 说得更具体，四个分支都动了同一个配置文件，最后合并才是真工作。还有网友提到，多个代理挤在同一个 checkout 里，会为了 package-lock.json 打架。worktree 把编辑隔开，但隔不开合并顺序。有人建议标记任务依赖，依赖分支先落地就让整批失败；真正独立的任务可以任意顺序合并。这个建议很工程，也很现实。

Dan Kornas 回复另一位网友时说，他希望阻塞任务的精确决策能直接露出来，这样不用重开整个 session 就能回答。这个点比终端管理更接近日常痛点。四个代理同时跑，真正花时间的往往不是看它们写代码，而是判断哪一个停下来等你拍板。

Emdash 把 diff review、CI、PR 和 merge 收进一个地方，等于把合并放回正常 PR 流程。它不会自动理解四个分支改同一个配置文件的语义冲突，也不承诺替你决定任务依赖。它解决的是窗口和上下文分散，不是收尾本身。

另一个被忽略的成本是状态可见性。有网友说，终端埋在别的窗口下面，经常错过已经跑完的任务。还有人问 SSH 断线后代理是否继续跑，推文里没展开。Emdash 至少把任务集中到一个桌面应用里，让谁在跑、谁跑完、谁卡住更有机会被看见。

适合用的人很明确：已经付费订阅了编码代理，手里同时有几个修复或功能，不想再管终端标签。单任务新手不用急着上。开源地址在 GitHub 的 generalaction/emdash。先别开第十个终端，它可能只是用来检查前九个。