你开的 Agent 越多，越需要一个“调度台”：从 Corgi 看多 Agent 时代的新瓶颈
Show HN 上的 Corgi 是一个认识 Agent 的终端多路复用器：显示每个 Agent 在干什么、按 F1 跳到下一个未读，统一启动 Claude Code、Codex、Pi。
10 月 24 日，Hacker News 上有一个 Show HN 帖子，叫 Corgi。
据 HN 页面，它拿到了约 135 分、46 条评论。
一个刚出来没几周的终端小工具，为什么会有这么多人停下来讨论？
因为它戳中了一个越来越多人正在经历、但很少有人说破的问题：
同时开好几个 coding agent 之后，难的不再是写代码，而是“谁在干活、谁在等我”。
01
我们先做一个假设。
假设你是一个开发者，同时开着 Claude Code、Codex，可能还有一个 OpenCode。
每个 Agent 都在一个终端窗口里跑自己的任务。
请你想一想再回答：
此刻，哪个 Agent 在认真干活？
哪个 Agent 卡住了，正在等你点头？
哪个 Agent 已经干完了，结果你还没看？
它们分别改过哪些文件？
如果你答不上来，不奇怪。
因为大多数人的工作方式，还停留在“一个人 + 一个 Agent”的时代。
02
为什么会这样？
要理解这个问题，我们得先问：多开 Agent，到底是在提高什么？
很多人的直觉是：Agent 越多，产出越多。
真的是这样吗？
不完全是。
我们可以用一个极简的公式来看：
有效产出 = Agent 数量 × 每个 Agent 拿到你回应的及时程度
前半部分，越来越便宜，开一个新会话就行。
后半部分，却越来越贵，因为你只有一个。
于是，一条传导链就出现了：
Agent 变多 → 等你回应的会话变多 → 你在窗口之间来回切换 → 有的 Agent 干等，有的结果没人看 → 有效产出反而上不去
这就像一家餐馆，厨师越请越多，但传菜口只有一个人在喊号。
厨师不是瓶颈。
喊号的人才是。
换个角度看，这其实是一个效率问题。
商业里有个老道理：一切竞争，最后都是效率之争。
过去，开发的成本主要在“写”。
现在，“写”的一部分交给了 Agent，成本就挪到了“切换”和“确认”上：你得知道去哪个窗口，得想起它刚才在干什么，得判断它的结果能不能用。
这些成本，看不见，不记账，但每一次都在消耗你。
所以，多 Agent 时代真正稀缺的，不是更多的 Agent，而是一个能告诉你“下一步该看谁”的调度台。
03
Corgi 想做的，就是这个调度台。
据官网介绍，它是一个终端多路复用器，像 tmux，但是认识 Agent。支持 Claude Code、Codex、Pi、OpenCode。平台方面，官网写的是支持 macOS、Linux 和 WSL；GitHub 仓库 README 的安装说明只写了 macOS（Apple Silicon）和 Linux（amd64），没提 WSL，也不支持原生 Windows。
你可能会问：tmux 不是早就能分屏、能后台常驻了吗？为什么还要一个新东西？
区别在于，tmux 只认识窗口，不认识窗口里的东西。
它知道你开了几个 pane，但不知道哪个 pane 里的 Agent 在等你。
Corgi 想补上的，正是这一层“认识”。
它做了哪些事？我把官网列出的功能，按“调度台”的逻辑归归类。
第一类，是告诉你“谁需要你”。
官网列了四种状态：working、needs you、unread、clear（README 的功能表里写的是 working、needs you、done 三种，两边说法不完全一样，以实际版本为准）。按 F1，直接跳到下一个未读的 Agent。
这一条，其实就是在解决上面公式的后半部分：把“你的回应”分配到最需要的地方。
它怎么知道 Agent 的状态？README 写得很直白：你在 pane 里跑 claude、codex 这些命令，Corgi 会往它们的设置里加上自己的 hooks（Pi 是装一个扩展，OpenCode 不用改，Codex 要你在 /hooks 里确认一次）。在意配置被改动的人，装之前心里要有数。
第二类，是告诉你“它干了什么”。
鼠标悬停，就能看到 Agent 做了啥，它碰过的所有文件可以在一屏里滚完。
第三类，是帮你管好“现场”。
Ctrl-T 新开或恢复会话，有统一的启动器，支持多账号，能内联显示 token 用量。还有 worktree 管理，按工作区显示 CPU、内存、GPU。它像 tmux 一样后台常驻。
另外还有些小细节：⌘V 可以直接贴图，SSH 下也行（需要 Ghostty Nightly）。corgi --skill 可以让 Agent 学会驱动它。
安装方式是一行 curl -fsSL https://corgi.computer/install.sh | bash，然后在项目目录里敲 corgi。
04
作者自己是怎么想的？
据作者在 HN 上的自述和回复，Corgi 受 Herdr 启发，有 herdr 风格的键位，能迁移 workspace、tab、pane 和正在运行的进程。用 TypeScript + Bun 写，基于 pi-tui，并致谢 Ghostty 和 Kitty。
还有一个值得注意的设计假设：他假设你有便宜的推理可用，比如 Haiku，用 Agent 来帮你整理链接、worktree，以及每个 Agent 在干什么。
这背后的逻辑是什么？
用一个便宜的 Agent，去管理一群贵的 Agent。
不是让人去盯每一个窗口，而是让机器先做一遍“汇总”，人只看结论。
这个思路对不对？我觉得方向是对的。
但它也有前提：那个负责汇总的 Agent，得足够可靠。如果汇总错了，你看到的“结论”就是错的，而你可能还以为自己什么都看见了。
所以，便宜的 Agent 可以帮你筛，但不能替你信。
05
说完它想做什么，必须说清楚它现在是什么。
Corgi 是一个只有几周大的项目。
它不是成熟产品，更像一个公开的实验。
HN 评论区里，有几条很实在的意见：
第一，缺少原生的多机远程。作者回复说，这是下一件大事。
第二，有人报告重绘闪烁。
第三，curl | bash 的安装方式引发了关于 Homebrew 沙盒的讨论，Homebrew 维护者 mikemcquaid 也在帖子里回复了。
第四，Windows 用户要走 WSL2。作者回复说是“间接支持”，原生 Windows 他上次试的时候，coding agent 本身就不太好用。
这些问题，对一个几周大的项目来说都很正常。
但正常，不代表你可以忽略。
06
那么，你现在该不该用？
我的建议是，先问自己三个问题：
第一，你是不是真的经常同时开多个 Agent？如果你一次只开一个，调度台对你的价值有限。
第二，你能不能接受一个早期工具的不稳定？闪烁、缺功能、键位变化，都可能发生。
第三，你对 curl | bash 这种安装方式放不放心？如果不放心，先读一遍安装脚本，再决定。
如果三个答案都是“是”，可以在不重要的项目上先试一试。
如果有一个是“否”，那就先收藏，过一段时间再看。
还有一点要提醒：别因为有了调度台，就把更多、更重要的事情一股脑交给更多的 Agent。
调度台解决的是“看得见”，不是“管得好”。
每个 Agent 改了什么、该不该合进去，最后拍板的还是你。
结语
工具在变，但商业的逻辑没变：哪里稀缺，哪里就有价值。
一个人用一个 Agent 的时候，稀缺的是 Agent 的能力。
一个人用一群 Agent 的时候，稀缺的是这个人的注意力。
Corgi 能不能长成那个调度台，现在还言之过早。
但它提出的问题，值得每一个多开 Agent 的人认真想一想：
你缺的不是更多的手，而是一双知道该先看哪里的眼睛。
来源：Corgi 官网；GitHub 仓库（MIT）；Show HN 帖子。HN 分数与评论数为发稿时（2026-10-26）的约数；官网写支持 macOS、Linux、WSL，README 安装说明只列 macOS（Apple Silicon）和 Linux（amd64）；会给 claude/codex 等加 hooks（据 README）；迁移 workspace 与活进程等功能据作者在 HN 的自述；提示音文件来自 herdr，Apache-2.0；“调度台”的瓶颈分析为作者看法。