https://blog.cpdd.fyi/tags/otty/Recent content in Otty on Zampo BlogHugozh-cnTue, 07 Jul 2026 14:00:00 +0800https://blog.cpdd.fyi/posts/ai-native-terminal-otty-kaku-2026/Tue, 07 Jul 2026 14:00:00 +0800https://blog.cpdd.fyi/posts/ai-native-terminal-otty-kaku-2026/<p>今天试了 Otty。</p> <p>快。但让我停下来的是另一件事。</p> <p>每个标签页上直接标着 agent 的状态：Processing、Idle、Awaiting Input。不用切过去看，扫一眼就知道哪个 agent 还在跑、哪个在等你、哪个已经停了。</p> <p>这个东西，传统终端给不了。</p> <p>我花了很长时间才想明白自己为什么对这件事这么在意。不是 Otty 做了什么惊艳的事。它只是让你看到了你本来不该错过的东西。但在传统终端里，这些东西你就是看不到。三个标签页打开，每个都在跑 agent，你只能一个一个切过去看有没有输出。像在没有仪表盘的车里开车。</p> <h2 id="2026-年终端出了什么问题">2026 年，终端出了什么问题</h2> <p>过去两年，开发者工作流里最大的变量是 code agent。不是编辑器，也不是框架。</p> <p>Claude Code 来了，Codex 来了，OpenCode 也来了。开发模式从&quot;一个人开一个终端跑命令&quot;，变成了&quot;一个人同时开三个 agent 会话——一个改前端、一个修后端、一个做 Code Review&quot;。去年还在争论&quot;AI 能不能写代码&quot;，今年已经默认能写，问题变成了&quot;我怎么同时管好几个写代码的 agent&quot;。</p> <p>你的工作流变成了这样：开一个标签页跑 Claude Code 改排序逻辑，再开一个跑 Codex 写测试，第三个跑 OpenCode 做全量重构。你在这三个标签页之间来回切换，每个都停在同一个提示符前——你不知道它们干完了没有，不知道哪个在等你输入，更不知道哪个已经卡住了半小时。</p> <p>我在这个状态里卡了两个月。一开始觉得 agent 嘛，自己跑就是了，跑完自然会告诉我。但实际不是这样。Claude Code 改完代码之后停在&quot;结果已应用，请确认&quot;的提示上等你回复。你不切过去看，它不会继续。有一次它的对话框在那里等了二十分钟。我把它切到后台去做别的事，完全忘了它在等我。</p> <p>这不是 agent 的问题。是我的终端没有告诉我它在等我。</p> <p>终端从&quot;跑命令的窗口&quot;变成了&quot;agent 的驾驶舱&quot;。</p> <p>但 iTerm2 不知道这件事。Ghostty 不知道。Alacritty 更不知道。</p> <p>它们都在做同一件事：把命令行渲染得够快、够漂亮、够原生。字体平滑、GPU 加速、True Color 支持——这些东西在 2025 年以前是选终端的核心指标。但如果你已经走入了&quot;一天开五个 agent&quot;的工作流里，瓶颈早就不在渲染性能上了。你需要知道谁在做什么。</p> <p>2026 年的问题已经不是&quot;终端快不快&quot;。是&quot;我的 agent 在终端里对我有多透明&quot;。</p> <p>这个差异，就是 Otty 和 Kaku 进场的位置。它们从不同方向回答同一个问题：当终端的主要任务不再是渲染命令输出，而是管理多个 agent 的交互时，终端应该做成什么样？</p>