很长时间以来,终端一直是开发者工作流中最简单的一部分。你打开一个 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