试了 Otty 才确认：终端在 2026 年变成了另一件事

今天试了 Otty。

快。但让我停下来的是另一件事。

每个标签页上直接标着 agent 的状态：Processing、Idle、Awaiting Input。不用切过去看，扫一眼就知道哪个 agent 还在跑、哪个在等你、哪个已经停了。

这个东西，传统终端给不了。

我花了很长时间才想明白自己为什么对这件事这么在意。不是 Otty 做了什么惊艳的事。它只是让你看到了你本来不该错过的东西。但在传统终端里，这些东西你就是看不到。三个标签页打开，每个都在跑 agent，你只能一个一个切过去看有没有输出。像在没有仪表盘的车里开车。

2026 年，终端出了什么问题

过去两年，开发者工作流里最大的变量是 code agent。不是编辑器，也不是框架。

Claude Code 来了，Codex 来了，OpenCode 也来了。开发模式从"一个人开一个终端跑命令"，变成了"一个人同时开三个 agent 会话——一个改前端、一个修后端、一个做 Code Review"。去年还在争论"AI 能不能写代码"，今年已经默认能写，问题变成了"我怎么同时管好几个写代码的 agent"。

你的工作流变成了这样：开一个标签页跑 Claude Code 改排序逻辑，再开一个跑 Codex 写测试，第三个跑 OpenCode 做全量重构。你在这三个标签页之间来回切换，每个都停在同一个提示符前——你不知道它们干完了没有，不知道哪个在等你输入，更不知道哪个已经卡住了半小时。

我在这个状态里卡了两个月。一开始觉得 agent 嘛，自己跑就是了，跑完自然会告诉我。但实际不是这样。Claude Code 改完代码之后停在"结果已应用，请确认"的提示上等你回复。你不切过去看，它不会继续。有一次它的对话框在那里等了二十分钟。我把它切到后台去做别的事，完全忘了它在等我。

这不是 agent 的问题。是我的终端没有告诉我它在等我。

终端从"跑命令的窗口"变成了"agent 的驾驶舱"。

但 iTerm2 不知道这件事。Ghostty 不知道。Alacritty 更不知道。

它们都在做同一件事：把命令行渲染得够快、够漂亮、够原生。字体平滑、GPU 加速、True Color 支持——这些东西在 2025 年以前是选终端的核心指标。但如果你已经走入了"一天开五个 agent"的工作流里，瓶颈早就不在渲染性能上了。你需要知道谁在做什么。

2026 年的问题已经不是"终端快不快"。是"我的 agent 在终端里对我有多透明"。

这个差异，就是 Otty 和 Kaku 进场的位置。它们从不同方向回答同一个问题：当终端的主要任务不再是渲染命令输出，而是管理多个 agent 的交互时，终端应该做成什么样？

Otty：闭源，但 agent 体验是亲儿子

Otty 的定位很清楚：不是又一款 GPU 加速终端。是为 code agent 打造的终端。

Metal 渲染、GPU 加速、标签页和分屏这些都是入场券。但真正值得细看的，是它对 agent 的深度整合，分四个层面。

第一层，agent 可观测性。 在 Claude Code、Codex 或 OpenCode 的配置里装一个小 hook——一行配置。之后 agent 的每个状态变化——开始工作、完成、等待输入——会实时反映到标签页徽标上。你的工作流从"挨个切标签页看"变成"扫一眼就知道哪个 agent 需要你"。

第二层，会话管理。 agent 的每一次对话都被自动捕获，可搜索，可回溯。几小时前 agent 的推理过程，直接回看。想继续一个旧会话，点 Resume。agent 做完事或者等你输入时，系统弹窗通知。它能保持 Mac 不进入休眠，长任务不会因为合盖被中断。甚至合盖再开盖，所有 pane 都能恢复——Session Recovery 是标配。

还有一个有意思的功能叫 Fork & Branch。你在一个 agent 会话里遇到了一条岔路——是重构方案 A 还是方案 B？传统做法是复制粘贴整个上下文开新窗口。Otty 直接在当前标签页上 fork 出一个新 pane，两个 agent 会话平行推进，互不干扰。选错了也不丢上下文，切回来继续。

第三层，输入工具。 Composer（多行输入框）、Prompt Queue（排队等当前 agent 跑完再发下一条）、Send to Chat（把终端输出直接喂给 agent）。Prompt Queue 我试用了一下感觉特别好：你正在等 agent A 跑完，突然想起另一条指令想发出去。传统做法是新建一个标签页开另一个 agent，或者打断现在的。Prompt Queue 把所有待发指令排队，agent 处理完当前任务就自动取下一个。不打断做事的节奏。

第四层，协议层。 Otty 提出了 OSC 26 Terminal Agent Protocol——一个让 agent 主动向终端报告身份、状态、进度的通信协议。传统上 agent 跑在终端里，终端对它一无所知。OSC 26 让 agent 可以告诉终端"我是谁、我在做什么、我进到哪一步了"。目前只有 Otty 支持这个协议，但如果被广泛采用，它可能成为 AI 终端的标准通信层。

如果你每天在多个 agent 会话之间来回跑，Otty 省的不是启动速度那几百毫秒。省的是你在"猜哪个 agent 跑完了"这件事上浪费的所有注意力。

Otty 闭源，由 Typora 的开发商 appmakes 出品。macOS only，下载直接用，不需要账号。离线体验完全免费——这也是个明确承诺。

Kaku：从 WezTerm 里 fork 出的另一条路

Kaku 走了完全不同的方向。

它是 WezTerm 的一个深度 fork，MIT 开源，由作者 tw93 维护。5,500+ 个 star，40 多位贡献者，刚发 v0.13.0。没有另起炉灶，直接在 WezTerm 的 Rust 内核上做减法加调料。

减什么？初始二进制比 WezTerm 小 40%，启动更快。默认配置开箱即用——JetBrains Mono 字体、macOS 原生字体渲染、暗色/亮色自动切换。装好就能干活，不用先读半小时文档写 config。

加什么？一个内置的 AI Assistant。传统 terminal 的 AI 做法是塞一个 chat 面板，Kaku 换了个路子，在终端里加一层智能补位：

• 命令失败时自动建议修复。npm run buidl 打错字？直接给出 npm run build，Cmd+Shift+E 粘贴到提示符上。什么都不自动执行——它设计上就假设你不想让 AI 替你运行命令，它只替你想。
• 输入 # 加一句自然语言，比如"# 找一下今天改了哪些 Go 文件"，它尝试转成对应的 shell 命令。不是把终端变成 chat，是在命令行基础上加一层自然语言翻译。
• 还集成了 Lazygit、Yazi 文件管理器、远程文件浏览——一套完整的 shell 工具链，不用另装。

这就是 Kaku 的定位：不假定你重度依赖 code agent。它假定你经常打错命令、想少背一点 shell 命令的语法、想在终端里直接问点什么事。它的 AI 不是另一个 agent，是终端自身的一个智能助手。

tw93 还做了一个"三件套"体系：Kaku（書く）写代码，Waza（技）练技能，Kami（紙）发文档。一个中国开发者用这套工具链定义了自己理解的 AI 编程工作流。和 Otty 那种"为 agent 设计一切"的哲学不同，Kaku 更像是"让经典终端自然进化"——在已有的 shell 工作流里嵌入 AI，而不是推翻重来。

Kaku 也是 macOS only，MIT 开源，不需要注册。brew install tw93/tap/kakuku 就能装。

两个方向

没有哪个方向更正确。取决于你目前在 code agent 这条路上走了多远。

但共通的趋势很明显：终端不再只是一个渲染器。

过去二十年，终端模拟器的竞争围绕速度、协议兼容性、功能丰富程度。xterm 到 iTerm2 到 Alacritty 到 Ghostty，本质上都在优化"把键盘输入传给 shell，把 shell 输出渲染到屏幕"这条管道。谁更快、谁支持更多 escape sequence、谁的配置更可编程，谁就赢了。竞争是线性的，标准是明确的。

2026 年的变化在于，终端里跑的不再只有你的命令。还有 agent 的命令。你的 shell 不只有你一个对话者，还有 Claude Code、Codex、OpenCode——它们在不断读取你的代码、写文件、执行命令。这些进程有自己的生命周期：开始、等待、报错、完成。而且通常不止一个。

一个什么都不知道的终端，只是把这些内容逐行打出来。Agent 完成了一个任务，输出停在那里，和编译报错混在一起，和 git log 的输出混在一起。你需要自己盯着屏幕分辨"它跑完了没有"。

但终端可以做得更多。它可以通过 hook 知道 agent 的状态，可以在标签页上标出来，可以在 agent 等你的时候弹通知，可以让你 fork 一个会话去试另一个方案而不丢失上下文。它有能力变成 agent 交互的管理层，而不只是一个被动的输出显示器。

这个转变，比谁快不快重要得多。

跨出那一步的，不止它们

Warp 其实比谁都早意识到这件事。2022 年它就把 AI 直接做进了终端，但选了闭源加账号制，社区反应一直复杂——开发者对"用终端还要先登录"这件事天然抗拒。Ghostty 选了另一条路——不做 AI 内建，把终端做到极致快，agent 支持交给外部工具。也是清晰的取舍。

Otty 和 Kaku 的特殊之处在于，它们都从"shell 输出渲染器"这个范畴里跨出去了一步——只是跨向了不同方向。

Otty 跨向 agent 交互层。把终端从"看 agent 日志的地方"变成"管 agent 的地方"。这个方向走得更深：它不只是让你看到状态，还让你 fork 会话、排队指令、把输出喂给另一个 agent。它在构建的不是终端，是 agent 的操作系统界面。

Kaku 跨向命令行辅助层。把终端从"出错只能自己查的地方"变成"出错有人帮你补的地方"。这个方向更轻：它不接管 agent 的管理，只是让终端本身更聪明一点——替你纠错、替你翻译自然语言、替你准备一套好用的 shell 工具。它更像一个 smarter shell。

这两个方向底层用着不同的技术栈、不同的开源策略、不同的 agent 深度，但指向同一个判断：终端和 agent 之间需要一个新的交互层。这个判断是 2026 年独有的——三年前你买一个终端，只需要它快；现在你需要它知道你的 agent 在干什么。

如果你接受这个判断，那 2026 年选终端的标准就变了。不是"它有多快"，也不是"它字体好不好看"。是"它知不知道你的 agent 在干什么"。

先问问自己：我每天开多少个 agent 会话？我需要知道每个 agent 在干什么吗？我是想管理它们，还是只想在打错命令的时候有人提醒一下？

答案不同，选择的终端就不同。

有一点是确定的：如果你只看了 Ghostty 的渲染性能、iTerm2 的特性列表、Kitty 的 GPU 加速，就决定 2026 年用什么终端，那你用的还是上一代的选择标准。今年的终端选型多了一个维度——这个维度以前不存在。

不是总结

2026 年的终端，正在从一个窗口变成驾驶舱。

但没人能替你决定你需要多少仪表盘。

技术永远是这样——不是某个产品赢了，而是一类需求第一次被好好回答了。Agent 需要自己的终端。这个判断本身，比 Otty 和 Kaku 谁做得更好，更值得被记住。