终端正在长出一层管理 agent 的壳

最近我注意到一个变化：终端这个用了几十年都没怎么变样的老东西，因为 AI agent 太多，开始往外长出一层新壳。

起因是 Bret Fisher 的一期视频。他是 Docker、Kubernetes 圈子里很多人都认识的老教育者，自称 “a very CLI guy”，终端用了 40 年，从 80 年代中期的 Sinclair 绿屏机起步，一路 HP Unix、Solaris、各种 BSD，到 2009 年第一台 Mac 上了 iTerm，一用就是 17 年。这种人说”我换工具了”，分量跟一个刚入行两年的人不一样。而且他动的地方挺有意思：不在终端模拟器本身，在它上面新冒出来的那层壳。

他换的这个东西叫 Supacode，一个 Mac 上的终端 UI，已经当主力用了一两个月。原视频在这里：My new terminal daily driver: Supacode for macOS。

一个还没起好名字的新品类

Bret 给 Supacode 的定位是 “agent harness session manager”，硬翻过来是”agent 驾驭层的会话管理器”。他自己都嫌这名字太长，说”得有个更好的叫法”。但这串拗口的词，反而把这层壳的位置讲清楚了。

得先说清楚 harness 是什么。Bret 在视频里给了一个挺干净的定义：像 Claude Code、Codex、Copilot 这些，技术上不是”agent”，是 harness（驾驭层）。一个 harness 里面装着多个 agent，而一个 agent 由四样东西组成：能干什么（权限）、用哪个模型、一段系统提示词、能调哪些工具。你可以用开箱自带的 agent，也可以自己往里塞。

这个定义我读着眼熟，因为它跟我自己沉淀下来的判断几乎一字不差：模型本身之外、所有让模型能干活的脚手架，都是 harness。Bret 是从工具用户的视角讲的，落点完全一样。所以当他说”我要管理的不是某一个 agent，是我同时在跑的一大堆 harness”，痛点就出来了。

痛点有个很形象的名字，叫 tab hell。你在 Claude Code 里开一个会话，在另一个项目里又开一个，跨机器可能开了一千个 tab。每个 tab 都存着那个会话的状态，你舍不得关，又记不住哪个在等你、哪个跑完了、哪个还在干活。Bret 说他经常同时开着 50 个以上的窗口。一个普通开发者平时也就开几个终端，50 个是什么概念？人脑已经盯不过来了。Supacode 要解决的，就是这个”盯不过来”。

为什么突然冒出几十个终端

要理解 Supacode 从哪来，得先认识一个库：libGhostty。

Ghostty 是 Mitchell Hashimoto（HashiCorp 创始人）这两年的新作品，一个跨平台终端模拟器。Bret 去年底从用了 17 年的 iTerm 切到了它，理由很朴素：iTerm 功能多到现代开发根本用不完，Ghostty 更轻、更好配、可能还快那么几毫秒。

真正聪明的设计不在 Ghostty 这个壳，而在 Mitchell 把终端最复杂、最难啃的核心逻辑抽成了一个底层库，叫 libGhostty。终端在不同系统上 UI 完全不同（Mac 用 Swift，Linux 多半 GTK，Windows 又一套），但底层那堆脏活累活是共通的。把脏活沉到库里，UI 只是库上面薄薄一层壳，谁都能拿去做自己的终端。

结果就是这一两年，基于 libGhostty 的项目冒出来几十个，多到有人专门建了个 awesome-libGhostty 清单来收。以前你选终端，来回也就 iTerm、系统自带那几个；现在 Bret 的原话是，你可以”每周挑一个新终端来玩，玩一年都玩不完”。选择从匮乏变成了过载，于是又有了新需求：得有人帮你从这几十个里挑出靠谱的。Supacode 就是这批新终端里专门面向 agent 的那一类。

terminal-first，不是再造一个 IDE

打开 Supacode，第一眼几乎跟 Ghostty 一样，因为它底层就是 libGhostty，会自动读你的 Ghostty 配置、主题、字体、快捷键。Command+T 开新 tab，Command+D 切分窗格，这些 iTerm 时代的肌肉记忆全都还在。

真正多出来的是左边那条侧边栏，列着你所有的项目和目录。这是终端之上的新抽象层。其中一个我觉得最关键的设计：项目不必是 git 仓库。市面上不少同类工具死盯着 git，没有 git 仓库就不工作；Bret 要的是一个”还是终端、只是多几个功能”的东西，所以普通文件夹也能放进侧边栏，能 pin 到顶、能排序、能上色。

往上是几个”懂一点 GitHub”的小功能。如果某个项目是开着 PR 的分支，标题栏会冒出一个小窗口（Bret 管它叫 notch），告诉你这个 PR 的 CI 检查挂了，鼠标悬上去能看到完整的失败列表，点一下跳到 PR 页。你不用一直守在 GitHub 页面上。它拿权限的方式也务实：OAuth 授权一次，再借 gh 命令行工具的能力捞 token，不用自己单独再搭一套 GitHub 认证。

然后是跟 agent 直接相关的 hooks。Supacode 能往四种主流 harness 里插钩子（视频里 Bret 开了 Claude Code 和 Pi，Codex 还没装）。钩子干的事是：识别出你在跑哪个 harness、它现在在干嘛、是不是在等你回话，再把这些状态捞到界面上和 Mac 右上角的通知里。值得提一句，市面上的 harness 远不止四种，Bret 自己张口就报了七八个（Claude Code、Codex、Copilot、Pi、OpenCode、Hermes、OpenClaw……），所以”只支持四种”也说明这层整合还很早期。

最有意思的设计：壳做薄，能力交给 agent

Supacode 有一个我认为最值得说的设计，它有自己的 CLI。但这个 CLI 不是给人用的。

Bret 的原话是，这个 CLI “是给 agent 用来管理这个 app 的”。听起来有点绕：跑在 app 里的 agent，反过来管理装着它的 app。实际用起来是这样：他在某个 agent 会话里直接说一句”帮我把这个目录在 Supacode 里开成一个新项目”，agent 就调 CLI 把活干了。他当然也能自己点界面上的加号，但他更愿意让 agent 来。

worktree 也是同一个套路。git worktree（同一个仓库同时把多个分支检出到不同目录，让你并行干活又不互相打架）这东西，Bret 坦白过去一年试了好几次都没学会，”命令有点复杂，我没真正搞懂”。Supacode 是第一个把 worktree 做简单的 app，他用了才算开窍：设好存放位置，进项目点加号，新建分支、建 worktree 一步到位。更妙的是，agent 自带一个 skill，知道怎么调 Supacode 的 CLI 管 worktree。所以他常常是”拿 agent 驱动这个 GUI”，而不是自己动手点。

这个设计我越想越觉得是对的。它没有把每个功能都做成一个按钮塞给人，而是把功能做成 CLI 和 skill 交给 agent，界面本身保持薄。这正好是我一直认同的那条准则：壳要薄，能力要厚，而且能力应该沉淀成 agent 能复用的技能，不是堆在一次性的 UI 上。

（顺带一提，它还接了 ZMX，类似 tmux 的会话持久化：你 kill 掉 Supacode 再开，每个 tab 的历史都还在，后台在跑的 Claude Code 也还活着。对 terminal-first 的人是个实在的便利。）

这其实是一场关于”要不要 GUI”的赌注

视频后半段 Bret 对比了几个竞品，对比本身比结论有意思。

• Cmux：同样 terminal-first，性能好，但左侧菜单一堆没用的小字，他不喜欢那个 UI。
• Superset（注意别跟 Supacode 搞混）：体验类似，右侧能直接看 git diff、做 review，但他觉得”界面上东西太多了”。
• OpenChamber：长得最漂亮，但只支持 OpenCode，而且是 client-server 模型，能挂一堆 GUI、TUI、Web UI 客户端，”上千个按钮”。Bret 承认它好看，但”我会被界面上那些花哨东西分心”，而且终端在里面像 VS Code 那样只是个底部的附属品，不是主角。

这些工具铺开来，是一条从”纯终端”到”纯 GUI”的光谱。而每个人站在光谱哪一端，本质是在赌一件事：agent 到底能自动化到什么程度。

Bret 自己站得很靠终端那头。他连 diff 都不在 GUI 里看，而是从 shell 跑 Lazy Git，拖成一个小窗摆在边上，agent 改文件时实时扫一眼——用了几十年，习惯了。他给薄壳派的理由很直白：你可能会说，我们要的就是 agent，agent 能替我们干完所有这些事，连按钮都不需要，因为 agent 会去点。

他甚至把话说到了头：也许有一天我会习惯没有 shell，等 agent 真能包办一切，我整天跟它们说话就行。他说自己其实已经在这么干了。

我会怎么看这件事

把视频里这堆工具退后一步看，Supacode 这类”agent 会话管理器”，其实就是 harness 之上又叠的一层壳，专门解决”人还得同时盯着好几个 agent”这个当下的过渡期难题。

而这层壳，恰恰是会贬值的那部分。我的判断一直是：harness 里很多东西是在补模型当下的短板，模型一代代变强，这些补丁会慢慢变多余；真正不贬值的是验证——你能不能快速判断 agent 干得对不对。tab hell 这个痛点也一样，它存在的前提是”人还要盯 agent”。哪天 agent 真能自己拉起验证、自己收尾、出问题自己重试，要人来回切的会话也就少了，这层会话管理壳的价值自然跟着缩水。Bret 那句”也许有一天我会习惯没有 shell”，其实就是在替这层壳预告它的退场。

所以一个工具聪明不聪明，要看它怎么对待这件事。Supacode 的聪明，正在于它没把宝压在”壳越厚越值钱”上：界面做薄，CLI 留给 agent，worktree 包成 skill 让 agent 调。换句话说，它做的不是一个会随模型变强而过时的厚 GUI，而是一个能力可以下沉、可以被 agent 接管的薄层。哪怕将来人不怎么盯界面了，这些 CLI 和 skill 照样能用。OpenChamber 那种”上千个按钮”的方向，赌的是相反的一面：赌人会长期需要一个丰富的图形界面来盯 agent。两种赌法都有人买单，但我更看好薄的那一端。

最后留个我自己验证过的提醒：如果你也一直没把 git worktree 用起来，先别急着怪自己。Bret 这种 40 年终端老兵都坦白命令太绕、试了几年没学会。worktree 的真实门槛，一直被各种”它很简单很强大”的说法低估了。能把它包成一键操作、再交给 agent 去调的工具，比又一篇 worktree 命令教程有用得多。这一点上，Supacode 的思路值得借鉴：与其教人记命令，不如把命令藏进 skill 让 agent 去记。