当你同时开着十个 Claude Code 的时候，问题才真正开始

我最近的工作流变成了这样：一个 Claude Code 跑前端重构，一个跑后端接口对接，一个 Gemini 在旁边做 code review，还有一个 Codex 在尝试某个不确定的实验方向。再加两个终端窗口跑测试和部署。

这还没算上那些我忘了关的。

问题不是"能不能开这么多窗口"——tmux 当然能。问题是你根本不知道哪个 agent 正在等你回复、哪个已经卡死了、哪个其实三分钟前就做完了在空转。你切到窗口 A，发现 Claude 在问你一个权限确认；切回窗口 B，Gemini 报了个错你还没看到。然后你在二十个 pane 之间疯狂跳跃，像是在玩一个设计得很差的弹球游戏。

这就是 agent-deck 要解决的问题。但它做的事情比"好看的终端管理器"多得多。

为什么 tmux 不够用

先把这个说清楚：agent-deck 跑在 tmux 上面，不是要替代 tmux。它替代的是你脑子里的那个"全局状态表"——哪个 session 在干什么、谁在等我、我该先处理谁。

tmux 给你窗口管理。agent-deck 给你AI agent 的语义理解。

具体来说，它知道一个 Claude Code session 当前是"正在思考"（running）、“等你确认”（waiting）、“闲着等你下指令”（idle）、还是"出错了"（error）。这不是简单的"进程还在不在"的判断，而是真正解析 agent 的输出状态。这件事你自己手动扫窗口也能做，但你不会每隔 5 秒扫一次——而 agent-deck 会。

这种状态检测带来的第一个实际收益是：你不用再主动去查了。等待中的 session 会直接出现在 tmux 状态栏上，你按 Ctrl+b 然后按数字键就能跳过去。出错的 session 是红色标记。这个信息密度比你自己扫二十个 pane 高出一个数量级。

Fork：不是为了"分支"，而是为了"不必从头来"

agent-deck 的 session fork 是我最常用的功能，原因可能跟你想的不一样。

不是因为我喜欢 Git 风格的分支模型，而是因为跟 AI agent 对话的沉没成本太高了。你跟 Claude 聊了半个小时，上下文已经包含了项目结构、你的偏好、之前踩过的坑。这时候你想试另一个方案——你不想丢掉当前对话，但也不想在这个对话里把方向搅混。

按 f，一秒钟 fork 出一个新 session，完整继承当前对话上下文。两个方向可以并行跑。做完之后哪个好留哪个，另一个直接删掉。

这个功能单独看没什么了不起。但当你真的在用 AI agent 做探索性工作的时候——比如"我不确定该重构数据库层还是先加缓存层"——你试过一次就知道差距。没有 fork，你要么在一个对话里来回切换方案（上下文污染），要么新开一个从头喂背景（时间浪费）。

Git Worktree：让多个 agent 安全地改同一个 repo

这个功能解决的是一个更硬的工程问题。

如果你的前端 agent 和后端 agent 在同一个代码库里工作——这在 monorepo 里很常见——它们会在同一个分支上互相覆盖对方的文件变更。git stash 来回切换？你自己手动做可以，让 AI agent 做就别想了。

agent-deck 的方案是 git worktree。创建 session 的时候加一个 --worktree 参数，agent 就会在一个独立的工作目录里工作，有自己的分支，不会跟别人冲突。做完了用 agent-deck worktree finish 合并回去、清理 worktree、删掉 session，一条龙。

它甚至支持 bare repo 布局——把 .bare/ 放在项目根目录，所有 worktree 都是平级的，没有"主 checkout"的概念。这对 CI 环境和多人协作的 agent 部署很实用。

还有一个容易忽略的细节：worktree 不会复制 .env、.mcp.json 这些 gitignore 的文件。agent-deck 提供了一个 .agent-deck/worktree-setup.sh 钩子，在创建 worktree 之后自动把主仓库的配置文件复制过去。这个小东西如果不做，每个新 worktree 里 agent 都会因为缺少环境变量而报错，你得手动一个个修。

Conductor：让一个 AI agent 盯着其他 AI agent

这是 agent-deck 里设计最重的功能，也是我读文档时觉得"这帮人是真的在自己用这个工具"的地方。

Conductor 是一个持久的 AI agent session，它的任务不是写代码，而是监控和调度其他 session。它能：

• 发现某个 session 出错了，尝试自动修复
• 发现某个 session 在等你确认，如果它有信心就替你回答
• 没信心的时候通过 Telegram 或 Slack 通知你
• 你从手机上回复一条消息，它帮你执行

这听起来像是"用一个 AI 管一堆 AI"的套娃设计，但逻辑是自洽的：如果你有 10 个 session 在跑，你不可能一直盯着。你需要一个值班的人。这个人不需要特别聪明，它需要的是：一直醒着、能判断"这事儿我能不能处理"、知道什么时候该叫老板。

实际用起来更像是一个自动化的运维值班系统，只不过值班的不是人也不是脚本，而是一个 AI agent。你可以给每个 conductor 写 CLAUDE.md 定义它的行为边界——什么情况自动处理、什么情况必须通知你。

配合 Watcher 功能，conductor 还能接收外部事件：GitHub webhook（有人提了个 issue，conductor 自动分配给对应的 session）、ntfy 推送（从手机发一条消息触发 conductor 动作）、Slack 消息。这些外部事件不是直接启动新 session，而是先通知 conductor，让 conductor 决定怎么处理。作者把这个叫做"doorbell rule"——门铃只负责通知有人来了，开门不开门是屋里人决定的。这个设计是对的，如果 watcher 直接 agent-deck launch，新 session 就变成了没有父节点的孤儿，状态事件无法路由回去。

MCP Socket Pool：一个省内存的工程细节，但很重要

MCP（Model Context Protocol）服务器是 Claude Code 生态里常用的扩展方式——web 搜索、浏览器自动化、数据库访问等等。问题是：每个 session 如果都各自启动一份 MCP 进程，10 个 session 就有 10 份。内存炸得很快。

agent-deck 的解法是 MCP Socket Pool：一份 MCP 进程通过 Unix socket 共享给所有 session。内存用量降 85-90%。MCP 进程崩了的话，reconnecting proxy 大约 3 秒自动重连。

这个功能本身不性感，但它是"从 demo 走向生产"的那种优化。你开两三个 session 的时候无所谓，开十个的时候没有这个根本跑不动。

配置就一行：在 ~/.agent-deck/config.toml 里设 pool_all = true。

Cost Tracking：AI 开发的隐性焦虑

用 AI agent 写代码有个不太被讨论的心理负担：你不知道你花了多少钱。

不是不知道单价——单价都写在官网上的。而是你不知道今天、这个项目、这个 session 具体烧了多少 token。这种感觉就像你把信用卡给了别人，你知道每样东西的标价，但看不到购物车总额。

agent-deck 的 cost tracking 解决的就是这个问题。它通过 Claude Code 的 hook 机制在每个 turn 之后读取 transcript 文件，自动收集 token 用量。支持 14 个模型的定价，TUI 里按 $ 就能看到今天/本周/本月的费用、各 session 的消耗排名、模型分布。还有 web dashboard，Chart.js 画图。

更能缓解焦虑的是预算限制：可以设每日/每周/每月的花费上限，80% 的时候警告，100% 的时候硬停。虽然这个功能目前标记为 untested，但方向是对的。

跨工具支持：不只是 Claude Code 的专属

agent-deck 对不同 AI 工具的支持深度不一样：

• Claude Code：最深。状态检测、MCP 管理、fork、resume 全支持
• Gemini CLI：同样深。状态、MCP、resume
• OpenCode：状态检测和组织
• Codex：状态检测、组织、conductor
• Cursor（终端模式）：状态检测和组织
• 自定义工具：通过 config.toml 里的 [tools.*] 配置

这个分层是合理的。Claude Code 和 Gemini CLI 有结构化的输出可以被解析，所以能做深层集成。其他工具至少能做进程级别的状态检测和分组管理。agent-deck 没有强求所有工具都走同一条集成路径，而是根据每个工具能提供的信息做适配。

Socket Isolation：不污染你自己的 tmux

一个经常被忽略的问题是：agent-deck 默认在你的 tmux server 上创建 session，这意味着它可能会修改你的 tmux 全局配置（状态栏、快捷键绑定等）。如果你自己的 tmux 配置很精心，这很烦。

v1.7.50 之后，你可以让 agent-deck 跑在自己的 tmux server 上：

[tmux]
socket_name = "agent-deck"

一行配置，agent-deck 的所有 session 就跑在 tmux -L agent-deck 上，跟你自己的 tmux 完全隔离。你在 shell 里误敲 tmux kill-server 也不会把 agent-deck 的 session 杀掉。

Docker Sandbox：让 agent 在笼子里工作

如果你不想让 AI agent 直接访问你的整个文件系统（这是合理的顾虑），可以开启 Docker sandbox。session 跑在隔离的容器里，项目目录以读写模式 bind-mount 进去，agent 能改代码但碰不到其他东西。

主机上的 Claude/Gemini 认证信息会自动共享到容器里，不需要重新登录。macOS 上连 Keychain 的凭证也会提取出来。

一次性试用可以用 agent-deck try "task description"——跑完自动清理。

安装和上手

一行装完：

curl -fsSL https://raw.githubusercontent.com/asheshgoplani/agent-deck/main/install.sh | bash

然后：

agent-deck                    # 启动 TUI
agent-deck add . -c claude    # 在当前目录加一个 Claude session

macOS、Linux、Windows (WSL) 都支持。也可以用 Homebrew：brew install asheshgoplani/tap/agent-deck，或者从源码编译。

这个工具真正解决的问题

回到开头。agent-deck 的价值不在"它是一个好看的终端 UI"——虽然它确实是，用 Bubble Tea 写的 TUI 交互很流畅。

它的价值在于：它理解 AI agent 的工作方式。

tmux 理解进程。操作系统理解进程调度。但 AI agent 不是普通进程——它有"在思考"、“在等人”、"做完了闲着"这些语义状态，这些状态对人的决策至关重要。你处理 waiting session 的优先级应该高于 running session，处理 error session 的优先级应该更高。这个优先级排序，tmux 不做，操作系统不做，只有一个专门为 AI agent 设计的管理工具才做。

更进一步，conductor 把这个逻辑从"人手动做"变成了"AI 自动做"。fork 把探索性工作的成本降到了接近零。worktree 把并发改代码的冲突问题工程化解决了。cost tracking 把"不知道花了多少钱"的焦虑消除了。

每一个功能都对应一个真实的痛点，而不是"有了这个功能好像很酷"。这是我觉得 agent-deck 值得用的原因。

项目地址：github.com/asheshgoplani/agent-deck，MIT 许可，目前 2.3k star，Go 写的，活跃开发中。