【导语：长期以来，终端是开发者工作流中简单的执行接口。但 AI coding agents 的出现改变了这一逻辑，让终端成为其天然归宿，也给终端 UI 模式带来了新的挑战。】
很长时间里，终端只是一个薄的、快速的执行接口。然而，AI coding agents 改变了这一状况，它们在开发者常做有状态工作的环境中运行，如运行测试、阅读日志等，使得终端不再只是输入命令的地方，而是成为多个半自主进程行动的场所。像 OpenAI 的 Codex CLI、Anthropic 的 Claude Agent SDK 构建的 agents 以及 GitHub 的 Copilot coding agent 都在终端发挥着作用。
传统的终端 UX 是线性的，输入一条命令，机器响应，然后决定下一条命令。而 agent session 打破了这个模式，它是一个带有意图、上下文、状态、权限和副作用的任务，更像一个实时的工作对象，而非传统的终端缓冲区，但我们仍按传统方式对待它。
一旦一个 agent 发挥作用，就会有更多需求，如修复测试、探索重构等。Git worktrees 变得重要，因为它能让一个仓库保持多个工作树，允许同时检出多个分支。实际工作流变成空间性的，但 UI 并未跟上。
标签只能告知终端存在，却很少能说明其所属任务、分支、文件变更等情况。对于 shell 来说尚可，但对于持有 agent 的终端，这远远不够。一个有用的 agent 工作空间应能清晰展示 agent 的状态、改变的内容等信息。
Agent 输出不是简单的日志，还包含决策、假设等，终端原生 agents 靠近真实环境，这要求 UI 传达更多信息。
启动一个 agent 相对容易，但监督一个或多个 agent 则困难得多。不同模式都有其权衡，如 IDE agent 靠近代码但不靠近运行时，终端 agent 靠近运行时但缺乏组织，云端 PR agent 适合 review 但不适合实时导航。
多年来，开发者工具关注打字速度和自动补全，有了 agents 后，瓶颈从按键转移到注意力。未来可能需要一个更理解任务、工作树、agent 状态等的工作空间模型，终端虽仍重要，但可能不足以应对大于一条命令的工作。
编辑观点：AI coding agents 的发展给终端带来变革，当前 UI 模式已难以适应。开发者需探索新的工作空间模型，以应对注意力瓶颈，提升开发效率。
)
