CliDeck - 把多个 AI 编码代理收进一个本地仪表盘
AI 编码代理开始变得像后台任务系统。一个终端里跑 Claude Code，另一个终端里跑 Codex，旁边还有 Gemini CLI 或 OpenCode 做 review。真正麻烦的不是启动它们，而是几个小时后还能不能看清：谁已经结束、谁在等输入、哪段输出值得接着处理、哪个会话还能继续恢复。
今天推荐的 rustykuntz/clideck 就是为这个场景做的本地仪表盘。它用一个浏览器界面承载多个 CLI coding agent，会话仍然跑在真实终端里，但状态、预览、通知、项目分组、角色和多代理路由被集中到同一个界面。GitHub 页面当前显示项目约有 91 stars、14 forks，主要语言为 JavaScript，许可为 MIT，latest release 为 v1.31.9。
项目概览
| 属性 | 详情 |
|---|---|
| 仓库 | rustykuntz/clideck |
| 文档 | docs.clideck.dev |
| Stars | 约 91 |
| Forks | 14 |
| 主要语言 | JavaScript |
| 许可 | MIT |
| 最新 release | v1.31.9 |
它不是替代代理，而是管理代理
CliDeck 的定位很克制：它不是新的 coding agent，也不是把你的 prompt 重写后再交给模型。文档里说得很清楚，它是一个 coordination layer，覆盖在现有 CLI 工具之上。你仍然使用 Claude Code、Codex、Gemini CLI、OpenCode 或普通 shell，只是把它们放进一个本地 Node.js server 和浏览器 UI 里管理。
这个边界很重要。很多“多代理平台”容易变成新的执行层，用户需要把项目、权限、provider、日志都交给它。CliDeck 的思路更像给终端加一个工作台：代理在真实 PTY 里运行，浏览器通过 xterm.js 渲染终端，状态检测主要依赖 localhost 上的 telemetry。代理本身不需要知道 CliDeck 的存在。
一屏看清多个会话
CliDeck 最直接的价值，是减少终端切换成本。README 和文档提到的核心能力包括：
- 实时状态：看出哪个 agent 正在工作，哪个已经 idle；
- 消息预览：在侧边栏看到每个会话的最新输出；
- 浏览器和声音通知：代理完成时提醒你回来处理；
- session resume：关闭后重新打开，可以继续之前的 agent session；
- projects：把多个会话按项目组织；
- roles：创建 Programmer、Reviewer、PM 这类可复用身份；
- prompt library：保存常用 prompt，用
//快速插入； - search：检索会话和 transcript。
这些功能单独看都不复杂，但组合起来正好打中 AI 编码的日常痛点。过去你可能用 tmux 或多个终端窗口管理并发任务；它们擅长分屏，却不擅长表达“这个代理正在等 review”“这个项目下有三个相关会话”“这个输出应该交给另一个角色继续看”。
Autopilot 适合低风险串联
CliDeck 比普通终端仪表盘更进一步的地方，是 Autopilot。它可以在项目层面观察带角色的 agent，等一个 agent 变成 idle 后，把输出转交给下一个 specialist。README 强调这个过程会原样路由内容，不重写、不总结，并用 fingerprint 和 handoff history 减少重复循环。
这类功能适合非常明确的流水线，例如：
- Programmer 做实现；
- Reviewer 做代码审查；
- Tester 根据结果补测试或复现；
- PM 只收最终状态。
我不会把它理解成“完全无人值守的软件开发”。更务实的用法，是把低风险、可中断、可审计的串联动作交给它。例如让一个 agent 完成初稿后自动请另一个 agent 做 review，或者让文档 agent 根据实现会话的输出补说明。真正涉及提交、部署、生产变更的步骤，仍然应该保留人工确认或仓库里的明确门禁。
本地优先是关键设计
CliDeck 对隐私边界的描述值得注意。文档写到所有数据留在本机，telemetry 从 agent 流向 CliDeck 的 localhost，Autopilot 的 LLM 调用则直接走你配置的 provider，CliDeck 自己没有服务器。
这和它的使用场景很匹配。AI coding agent 往往会处理私有仓库、终端输出、错误日志和未提交改动。如果一个管理面板默认要上传 transcript 或代理状态，就会很难进入真实工作流。CliDeck 把核心控制面放在本地，至少让用户可以把风险边界看清楚。
当然，本地优先不等于没有风险。你仍然需要理解每个底层 agent 会把哪些上下文发送给模型 provider，Autopilot 使用的 provider 配置也需要单独审查。CliDeck 管的是终端和路由层，不会替你解决所有数据治理问题。
适合什么人
我觉得 CliDeck 适合几类开发者先试：
- 已经同时使用 Claude Code、Codex、Gemini CLI 或 OpenCode；
- 经常开多个终端跑 agent，事后找不到哪个会话完成了；
- 希望把实现、review、测试、文档分给不同 agent，但不想搭一整套平台；
- 想从手机上看本机 agent 状态，并在必要时回复输入；
- 想保留真实终端，不希望代理输出被中间层加工；
- 需要一个比 tmux 更面向“会话和项目”的 agent 工作台。
如果你一次只跑一个代理，或者工作流主要是短 prompt、短响应，CliDeck 可能显得太重。它的价值会在多个长任务并发、多个项目切换、多个角色协作时更明显。
使用前要确认的边界
CliDeck 的 README 写到 macOS 和 Windows 可用，Node 18+，Linux 目前是 untested。安装方式很简单：
npm install -g clideck
clideck默认打开 localhost:4000，端口冲突时可以指定其他端口：
clideck --port 4001真正接入前，我建议先用一个非关键项目试三件事：状态检测是否稳定、session resume 是否符合你的预期、Autopilot 的 handoff 是否容易审计。尤其是多代理路由，不要一开始就接到会改生产配置或直接推送的流程里。
总结
rustykuntz/clideck 抓住了 AI 编码工作流正在出现的一个新问题：当 agent 从“偶尔问一下”变成“并行跑几个长任务”，普通终端窗口开始不够用了。
它的做法不是重新发明 agent，而是把现有 CLI agent 收进一个本地仪表盘，补上状态、预览、通知、恢复、项目分组和轻量路由。对已经把多个 coding agent 放进日常开发的人来说，CliDeck 很值得试一轮。它不会自动让多代理协作变可靠，但能让这些会话变得更可见、更容易接手，也更适合被纳入可审计的开发流程。