很长时间以来，终端一直是开发者工作流中最简单的一部分。你打开一个 shell，运行命令，查看输出，切换目录，也许再分个窗格，然后继续。它是一个薄的、快速的执行接口，不是一个完整的工作空间。

但 AI coding agents 改变了这个逻辑。它们写代码——更准确地说，它们现在在开发者最常做有状态工作的同一个环境中运行：运行测试、阅读日志、切换分支、启动服务器、检查文件、调试失败。这让终端成为了它们的天然归宿。OpenAI 的 Codex CLI 从本地终端运行，读取、修改和运行目录中的代码。Anthropic 的 Claude Agent SDK 构建的 agents 可以读取文件、运行命令和编辑代码。GitHub 的 Copilot coding agent 研究仓库、规划实现、在分支上修改代码，并打开 Pull Request。

所以终端不再只是你输入命令的地方。它正在成为一个多个半自主进程行动、暂停、请求批准、变更文件、等待你重新进入循环的地方。而我们的大多数 UI 模式是为人类驱动的命令执行而构建的，而不是为监督长期运行的 agents。

旧模型：一条命令，一个结果

传统的终端 UX 是线性的。你输入一条命令，机器响应，你阅读输出，决定下一条命令。标签、窗格和多路复用器给了我们更多运行命令的地方，而不是理解正在进行的工作的新方式。

一个 agent session 打破了这个模式。它不仅仅是输出；它是一个带有意图、上下文、状态、权限和副作用的任务。它更像一个实时的工作对象，而不是一个终端缓冲区。但我们仍然像对待标签中的文本一样对待它。

新模型：多个任务，多个上下文

一旦一个 agent 有用，你就会想要更多：一个修复测试，一个探索重构，一个审查 PR，一个在另一个分支上运行实验。

这就是 Git worktrees 变得重要的原因。它们让一个仓库保持多个工作树，允许同时检出多个分支。Agents 在一个文件系统内行动，所以如果它们共享一个检出、一个服务器、一个端口或一个数据库，结果就会变得模糊不清，人类必须重建发生了什么。实际工作流变成了空间性的，即使 UI 不是。你开始在区域中思考：一个分支、一个服务器、一个失败的测试；一个 agent 在保守修复，另一个在激进修复；一个预览、一个日志流、一个 diff。

标签不保留意图

一个标签告诉你一个终端存在。它很少告诉你为什么：它属于哪个任务，它在哪个分支上，它是否变更了文件，它是否可以安全地终止，或者里面的 agent 是否在等待你。这对于 shell 来说没问题。但当终端持有一个 agent——这个 agent 已经推理了十分钟、编辑了六个文件，现在要求应用一个冒险的迁移——这就不好了。

一个有用的 agent 工作空间应该一目了然地回答：这个 agent 在做什么，在什么状态上？什么被改变了，它已经尝试了什么？它是阻塞了、等待中、失败了，还是仍在工作？我可以比较两个尝试，明天继续吗？

Agent 输出不是日志。有些是决策、假设、计划和权限边界。构建日志可以略读；agent 记录需要解释。像 Codex CLI 和 Claude Code 这样的终端原生 agents 靠近真实环境，这使它们强大，但意味着 UI 必须传达比文本更多的东西。

监督是困难的部分

启动一个 agent 是容易的。监督一个是更难的。监督几个是更加困难的。

一个聊天框加一个文件树适用于小任务。一旦工作需要运维、需要终端、diff、预览、测试结果、日志和分支，就会捉襟见肘。每个模式都有权衡：一个 IDE agent 靠近代码，但不总是靠近运行时。一个终端 agent 靠近运行时，但不总是有组织。一个云端 PR agent 如 Copilot 适合 review，不适合实时导航。

真正的瓶颈是注意力

多年来，开发者工具针对的是打字速度和自动补全。有了 agents，瓶颈从按键移动到注意力：我能理解发生了什么，信任这个改变，比较两个尝试，明天继续，杀死正确的进程，判断一个 agent 是卡住了还是实际在工作？

下一个有用的层可能不是更智能的聊天框，而是一个理解任务优于消息、工作树优于文件夹、agent 状态优于输出、审批优于提示、以及历史优于回滚的工作空间模型。终端仍然会在那里，比以往更重要。但一旦工作的单位大于一条命令，它可能就不够了。

参考来源：https://cate.cero-ai.com/blog/ui-problem-ai-coding-agents