AgentTerm 登陆 Show HN：为 AI CLI 而生的「超级终端」，一个会话一个窗口

10 月 2 日，Hacker News 的 Show HN 区出现了一个标题很狂的帖子：「Show HN: A substantially expanded terminal for AI CLIs – I can't work without it」（为 AI CLI 大幅扩展的终端——离了它我没法工作）。主角叫 AgentTerm（albertwujj/agent-term），一个开源终端， slogan 是「Tell them apart, drive to the finish, beyond the IDE」（分清它们、推向终点、超越 IDE）。在 Warp、Ghostty、各种 AI IDE 打得不可开交的 2026 年，又来一个终端？但 AgentTerm 的切入点很刁钻：它不跟 IDE 抢「写代码」，它抢的是「管 agent」。

先说它的世界观。README 开篇就讲了一个观察：人们在 IDE、终端、厂商桌面 app 里运行 coding agent，而终端一直在把人吸回去——Claude Code 和 Codex 生来就是终端程序，Cursor 和 Copilot 出生在 IDE，却都反过来给自己加了 CLI。几十年前的老形态，恰好长着 agent 需要的样子：文本进、文本出，shell、git 和所有工具都只隔一条命令。但标准终端的 TUI 界面给不了 agent 和用户「更丰富的协作」：你没法在滚动的输出里精确批注，没法把 plan 渲染成文档，没法一眼分清五个并行会话谁是谁。

于是 AgentTerm 走了「第二条路」：不把 agent 搬进为它定制的 app，而是以终端为核心、去扩展终端。Electron 做窗口、xterm.js 做终端模拟、node-pty 接 shell——你的 CLI agent（Claude Code、Codex、Cursor CLI 等等）原样跑在里面，只是终端本身变聪明了。用作者的话说：「厂商的桌面 app 只支持自家的 agent，还把你从 shell 里拽走；在这个终端里，agent 可以是任何一种，还留在你的 shell 里。」

它到底加了什么

AgentTerm 的功能表，读起来像一份「vibe coder 痛点清单」：

• Sessions：分清谁是谁。每个会话独占一个操作系统窗口，任务栏按钮 / Dock 磁贴各不相同，五个并行 agent 一眼就能分清。作者特意解释了为什么不用 tmux 或统一管理器：反其道而行之，让「你用了几十年的操作系统」来当管理器——任务栏、Dock、Mission Control、Alt-Tab 都是久经考验的窗口管理。
• Comment：对输出精确批注。选中 agent 打印的任何内容，直接写评论，引用原文，agent 照着改。这是终端时代没有的交互：以前你想纠正 agent，只能在下一轮 prompt 里「用文字描述」你想改哪段；现在可以直接「指着」改。
• Docs / Code：把 plan 和 review 渲染出来。让 agent 把 plan 写成 markdown 文件，点文件名，文档就在终端窗口里渲染出来——你可以直接在渲染页上批注、改写，agent 把你的编辑当作意图、用自己的话写回源码。代码审查也一样：agent 交的是一份「策展过」的 review，有叙事、有重点标注，你 inline 评论，它原地修复并回复。
• Phone：手机接管。出门也能看到哪台机器上的哪个 agent 需要你，版式和桌面一致，可以直接语音回复。Agent 的长会话最怕「卡在某个确认提示上等人」，这个功能就是冲着这个痛点去的。
• Long jobs / Checkout lock / IDE 联动。agent 起的 CI 长任务，跑完后会「自己回来汇报」，闲置的 agent 会被提醒去接；多人协作时一个 @ mention 就能让 agent 拿 checkout 锁、切分支再开工，避免并行 agent 互相踩；点 agent 引用的 file:line，你的 IDE 会跳到精确行数（只读模式，手滑也改不了代码）。

最妙的是安装方式。Quick start 只有一句话：ask your agent（去问你的 agent）。你把这句 prompt 复制给正在用的 coding agent：「把 https://github.com/albertwujj/agent-term 克隆到 ~/agent-term，按 docs/setup.md 搭好并在这个项目里启动。」然后 agent 自己读文档、自己装、自己启动——一个为 agent 设计的终端，让 agent 自己把它装起来。这种「元叙事」在 2026 年已经不算噱头，而是新工具的标准动作：你的目标用户天天跟 agent 打交道，最好的 onboarding 就是让 agent 来 onboarding。

为什么是「扩展终端」，而不是「再造 IDE」

AgentTerm 的 README 里有一段「路线之争」的论述，值得全文摘出来品：厂商的路线是「把 agent 搬出终端，做一个围着 agent 转的 app」；AgentTerm 的路线是「把终端当核心去扩展」。前者的代价是：面板还没打字就先摆好了，容易分心；只支持自家 agent；把你从 shell 里拽走。后者的哲学是：「按需扩展」——需要时才出现，用完窗口立刻变回纯终端。

这个判断背后是对「注意力」的理解。IDE 和 agent 桌面 app 是「常驻面板」思维：文件树、面板、侧边栏永远在那儿。而 agent 时代的工作流是「脉冲式」的：大部分时间你在等 agent 跑，偶尔需要介入——看一眼 plan、批注一段输出、回一个确认。AgentTerm 的交互全是「召唤式」的：选中才评论、点开才渲染、需要才看手机。窗口在 95% 的时间里就是一个干净的终端，把「重」的部分藏起来，把「轻」的部分留下来。

还有一个技术细节很见功力：host 和 agent 之间用「文本模式」做稳定接口。终端 host 解析输出里的文件引用和既定格式，guide files 则教 agent「按 host 懂的格式输出」。两边互相迁就，形成协议。作者的原话是：「成熟的文本模式就是稳定的接口，有用的输出风格会留下来。」——不依赖任何厂商 SDK 和 API，agent 换代了，只要输出风格还在，终端就还能懂。在模型和 CLI 三个月一换代的 2026 年，这种「反脆弱」的设计比追新功能重要得多。

「让 agent 装终端」：onboarding 的范式转移

AgentTerm 的 quick start 只有一句话——ask your agent，这件事比功能本身更值得写一章。传统软件的 onboarding 是「人读文档、人点下一步」；agent 时代的 onboarding 正在变成「人给 agent 一句话，agent 读文档、装软件、配环境」。AgentTerm 的作者显然想明白了：我的目标用户是每天跟 agent 打交道的人，最好的安装方式就是让 agent 来安装。

这个范式的连锁反应才刚刚开始。当「让 agent 装好」成为标准动作，工具的竞争维度就变了：文档不再是写给人看的，而是写给 agent 看的——结构清晰、步骤原子、有明确的验收标准；安装过程不再追求「一键」，而是追求「agent 可执行」；甚至连错误处理都要考虑「agent 读不懂时怎么办」。以后评价一个开发者工具好不好用，第一个问题可能是：「你家 agent 能不能自己把它装起来？」AgentTerm 的 README 里专门有一份 SECURITY.md 讲「它会碰你系统的哪些地方」，正是为了回答 agent 和用户共同的疑问：让 agent 装东西，边界在哪里。

更深一层，这预示了软件分发的权力转移。过去，应用商店和官网下载页是入口；未来，agent 的「推荐 + 安装」可能是更大的入口——你的 agent 说「这个终端不错，我帮你装上」，比任何广告都管用。独立开发者做工具，得开始思考「agent 分发」：你的 README 有没有 agent-readable 的 quick start？你的安装步骤 agent 能不能无监督跑完？AgentTerm 的 Show HN 帖子，本质上是一次「agent 分发」的现场演示。

我的判断：2026 是「终端文艺复兴」之年

AgentTerm 不是孤例。Warp 把终端做成了 agent 开发环境并开源，Ghostty 1.3 的 Zig 核心被拿去嵌进各种工具，herminal 这样的个人项目在给 macOS 终端加 agent 仪表盘，Haibin 的 AgentTerm 在做多窗格 agent 管理+手机遥控——终端，这个被宣判过好几次「死亡」的东西，正在被 agent 倒逼着重造。2026 年的终端之争，争的已经不是「渲染快不快、主题好不好看」，而是「谁更懂 agent 的工作流」。

为什么是终端复活，而不是 IDE 通吃？三个原因。第一，agent 是「文本生物」：它的输入输出都是文本，终端是离它最近的栖息地；IDE 的图形界面反而是翻译层。第二，shell 是最大公约数：git、docker、ssh、脚本，agent 要干活就绕不开 shell，而终端就是 shell 的家。第三，厂商中立：Claude Code、Codex、Gemini CLI、Cursor CLI 可以同时跑在同一个终端里，没有任何一个厂商的 app 会允许这种「脚踏多条船」。终端的中立性，在 agent 战国时代成了稀缺品。

当然，IDE 路线也不会坐以待毙。Cursor 的 CLI、Copilot 的终端集成、Zed 的 agent 面板，都在试图「把终端的优点吸进 IDE」。但这里有个结构性矛盾：IDE 的护城河是「编辑器体验」，终端的护城河是「shell 中立性」——前者越做越重，后者越做越像「水电煤」。AgentTerm 赌的是后者：当 agent 成为主要劳动力，开发者待得最久的地方不是编辑器，而是「看 agent 干活、偶尔介入」的地方。那个地方长什么样，2026 年还没有定论，但「终端 + 按需扩展」显然是候选答案之一。

对 vibe coder 的实操建议：如果你已经同时跑 2 个以上的 agent 会话，是时候认真考虑「会话管理」了——不管是 AgentTerm 这种扩展终端，还是 tmux + 命名规范，核心是解决三个问题：分清（哪个会话在干什么）、找回（关掉的会话怎么 resume）、不丢（长任务跑完别静默失败）。AgentTerm 的 phone 和 long-job 设计，本质上就是在回答后两个问题。工具可以换，但这三个问题，每个重度 agent 用户迟早都要面对。

泼一盆冷水：AgentTerm 是 MIT 开源、零遥测、无账号，作者看起来是个人开发者——这类项目的风险从来不是「想法不行」，而是「维护能不能跟上 agent 的迭代速度」。Claude Code、Codex 的 CLI 输出格式一变，host 的解析器就可能失效；Electron 的体积和内存占用，对「终端应该轻」的原教旨主义者也是个坎。但话说回来，2026 年最好的工具，几乎都是从这种「个人开发者解决自己的痛点」开始的。先让 agent 帮你把它装上，用一周，再决定它值不值得留在你的 Dock 里——毕竟，能自己安装自己的终端，本身就已经通过了第一轮面试。