为什么 AI Agent 把工程师又带回了命令行

AI 摘要
- 终端重新变得重要,不是因为工程师怀旧,而是因为 AI agent 需要一个可执行、可观察、可回放的工作界面。
- 图形界面适合人类感知,但很多时候不适合 agent 理解。文本、命令、日志、退出码、diff 和测试结果,反而更容易被机器接住。
- Jane Street 的
strace-ui和 Bonsai_term 说明,TUI 不只是简陋版 GUI。它可以把复杂系统状态变成快速、键盘友好、可测试的工作台。 - Claude Code 和 Codex CLI 这类工具让 terminal 从"人操作机器"的入口,变成"人和 agent 一起操作工程系统"的共享空间。
- 下一代开发工具的关键,不一定是谁的界面更漂亮,而是谁能把任务、动作、证据和修正压成更短的反馈闭环。
有一段时间,我以为 AI 编程工具的未来会长得更像一个巨大的 IDE。
更大的侧边栏,更聪明的补全,更会解释代码的面板,更像产品经理精心设计过的工作区。你把需求拖进去,把截图贴进去,模型在某个圆角卡片里思考,最后吐出一段可以接受的结果。
结果最先让我真正觉得"这东西开始能干活了"的,不是某个漂亮界面。
是终端。
黑底,白字,偶尔一点绿色和红色。一个 agent 在里面跑 rg,读文件,改一小段代码,跑测试,失败,再读日志,再改。它不需要你教它按钮在哪里,也不需要把屏幕理解成一张图片。它看到的是命令、输出、退出码、diff、路径、行号、错误栈。
这些东西不漂亮,但它们诚实。
它们把一次工程动作压成了最基本的形态:我做了什么,系统怎么回答,哪里坏了,下一步该看哪里。

终端不是回忆滤镜
命令行当然有怀旧的一面。
很多工程师对它有感情:第一次 ssh 到一台机器,第一次在日志里抓到线上问题,第一次用一条管道把半天的手工活变成十秒。终端像一个旧工作台,边角磨得发亮,抽屉里塞满了你自己才知道的工具。
但如果只把这次 TUI 回潮理解成情怀,就看浅了。
Jane Street 最近写了一篇文章,叫 strace-ui, Bonsai_term, and the TUI renaissance。文章的起点很朴素:他们一直觉得 strace 有用,但输出难读,子进程和线程不好跟,想过滤 syscall 还得重新跑。于是他们做了一个 terminal UI,把 strace 变成可以探索的界面。
这事听上去不大,却很能说明问题。
strace 原本像一卷没有整理过的案卷。系统调用一行接一行地涌出来,openat、recvmsg、rt_sigprocmask,夹着 pid、fd、地址、buffer。你知道线索在里面,但你要一边翻,一边在脑子里维持状态。
strace-ui 做的事,不是把它"美化"一下。
它把 pid 变短,把结构体格式化,把 buffer 画成 hexdump,允许你交互式过滤 syscall,沿着同一个文件描述符往前往后跳,还能把某些文件描述符上的网络地址解析得更清楚。
这不是装饰。是把一坨输出变成一个可以追问的现场。
程序刚刚跟内核说了什么?这个 socket 是什么时候打开的?这个子进程从哪里冒出来的?这一行日志之前到底发生了什么?
终端在这里不是 GUI 的穷亲戚。它是一个刚好够用、刚好贴近问题、刚好把注意力收住的工作台。
Agent 喜欢的界面,和人喜欢的不一样
人类喜欢界面的很多原因,和 agent 喜欢界面的原因不一样。
人喜欢图标,因为图标一眼能懂。人喜欢拖拽,因为动作有空间感。人喜欢按钮、卡片、动画、层级、颜色,因为这些东西帮我们把复杂性分块。
Agent 不一定需要这些。
对一个 coding agent 来说,最重要的常常不是"看起来清楚",而是"能不能被准确读取"。它更关心这些问题:
这个动作能不能用文本表达?
这个结果能不能被复制?
失败有没有明确的错误信息?
状态变化能不能变成 diff?
下一步能不能直接执行?
这就是为什么终端突然变得顺手。命令是动作。日志是观察。退出码是判断。测试结果是验证。diff 是记忆。
图形界面当然也可以做这些,但它必须有意识地设计出来。终端则天生就带着这些性质。它没有那么多空间幻觉,也没有那么多视觉礼仪。它把工程系统最关键的反馈直接摊在桌上。
Claude Code 的官方文档把自己描述成一个能读代码库、编辑文件、运行命令、接入开发工具的 agentic coding tool,而且明确说它可以在 terminal、IDE、桌面应用和浏览器里使用。OpenAI 的 Codex CLI 页面也很直白:在终端里和 Codex 结对。
这两句话放在一起看,意味很清楚。
AI 编程工具不是只在聊天框里回答问题。它正在进入工程师原本就工作的地方:仓库、shell、测试、CI、日志、版本控制。
而这些地方的共同语言,长期以来就是文本。
可测试的界面,才适合 agent
Jane Street 那篇文章里,真正打动我的不是 TUI 很快,也不是键盘很爽,而是他们讲到 Bonsai_term 的 expect tests。
大意是:如果一个 terminal app 能把当前 UI 状态打印成类似截图的文本,那么测试失败时,人和 agent 都能看到清楚的 diff。哪里多了一行,哪里少了一列,哪个状态从 pending 变成了 done,反馈很快,也很准。
这件事有点反常识。
我们习惯把 UI 测试看成一种麻烦事:截图脆弱,像素差异吵闹,浏览器状态复杂,测试失败时你要猜到底是样式坏了、数据晚到了,还是按钮真的没响应。
但一个文本界面如果设计得好,它的状态可以直接变成证据。

这对 agent 太重要了。
Agent 不怕干活。它怕的是干完以后不知道自己是不是干对了。
你让它改一段代码,它可以改。你让它解释一个错误,它可以解释。你让它猜一个 UI 是否正确,它也能猜。但真正能让它稳定起来的,是反馈:
测试红了。
类型报错了。
快照 diff 变了。
构建失败在某个文件某一行。
这时 agent 才不是在表演聪明,而是在一个有摩擦、有证据、有纠错能力的系统里工作。
所以,终端的价值不是"黑底白字很酷"。它的价值是把反馈闭环缩短。
从任务到动作,从动作到输出,从输出到验证,从验证到修正,几乎都在同一个介质里发生。
这就是好工作台的味道。
GUI 不是输了,只是没有默认赢
我不想把这篇写成命令行原教旨主义。
GUI 没有输。很多工作天然需要图形界面:设计稿、数据可视化、复杂业务流程、地图、视频、表格、运维拓扑、权限配置。人类不是日志解析器,我们需要形状、层级、空间和颜色。
问题是,AI agent 的出现改变了评判界面的标准。
过去,一个开发工具的界面主要服务人。它要降低人的认知负担,让人少记命令,少犯错,少在文档里翻来翻去。于是图形界面有巨大优势。
现在,界面开始同时服务人和 agent。
如果一个按钮点完以后,没有清楚的状态输出;如果一个流程失败以后,只弹一个含糊的 toast;如果一个操作背后的数据变化不能被复制、记录、回放;如果一个系统只能靠截图让 agent 猜发生了什么,那么它对人也许舒服,对 agent 却不友好。
反过来,一个看起来朴素的 TUI,如果每一步都有动作、结果、状态和可测试表示,就会突然变得很现代。
这也是那篇 Terminal Is All You Need 论文想说明的地方。它说,terminal-based agent tools 之所以在实践里被广泛采用,不是巧合,而是因为终端满足几种关键设计性质:agent 和界面的表示兼容,agent 的动作在交互介质里透明,人类参与的门槛也低。
我不觉得这意味着所有界面都该回到终端。
它真正提醒我们的是:未来任何面向 agent 的界面,都要重新获得终端已经拥有的那几种品质。
可读。
可执行。
可追踪。
可回放。
可验证。
终端是共享空间
以前我使用终端,感觉它是"我操作机器"的入口。
现在有了 coding agent,感觉变了。
终端更像一个共享空间。
我把任务说出来。Agent 去读仓库。它跑命令,我看输出。它改文件,我看 diff。它跑测试,我看失败。它说自己想下一步怎么做,我可以打断、修正、收窄范围。我们的对话不只发生在聊天框里,也发生在命令历史、文件变更、错误日志和测试结果里。
这让我重新理解了"界面"这个词。
界面不是屏幕上摆了哪些控件。界面是人、机器和工作对象之间的接触面。
对 AI 编程来说,真正的工作对象不是漂亮的提示词,而是代码库、依赖、运行环境、测试、日志、提交历史、部署约束。终端刚好把这些东西连接得很紧。它让 agent 能够进入同一个现场,而不是隔着一层截图或一层产品包装猜测。
这也是为什么我越来越不相信那种"一个通用聊天框接管所有工作"的想象。
聊天框适合意图。
终端适合行动。
IDE 适合阅读和局部编辑。
浏览器适合看真实用户界面。
未来的开发工具不会只剩一种界面。更可能是这些界面被重新编排:聊天负责澄清意图,终端负责执行和验证,IDE 负责代码上下文,浏览器负责视觉结果,版本控制负责留下记忆。
其中,终端会重新站到中间,不是因为它最大,而是因为它最像一条能跑通的管道。
漂亮不是不重要,漂亮只是第二重要
一个好的工程工具,当然也应该漂亮。
但这里的漂亮,不是大片渐变、悬浮卡片和会动的光效。它更像一把好用的钳子,线条干净,重量合适,放回工具箱时你知道它下次还会在那里。
终端的美感在于克制。
它告诉你:先把事情说清楚。先让动作能执行。先让失败能复现。先让结果能比较。先让下一个人,或者下一个 agent,看得懂刚才发生了什么。
当 AI 加入工作以后,这些品质变得更珍贵了。
因为模型会让产出变多,让尝试变快,也让表面完整的东西变得便宜。一个看起来很会工作的 agent,如果没有反馈闭环,很容易只是更快地产生幻觉、更快地绕开问题、更快地把错误包装成解释。
终端把它拉回地面。
跑一下。
看输出。
读 diff。
测一遍。
失败了,重来。
这套老派流程,突然成了 AI 时代最现代的工作方式。
回到黑底白字
所以我越来越觉得,终端回来了,不是因为工程师突然想念过去。
它回来,是因为我们正在给一个新同事找桌子。
这个同事不会累,读得快,写得也快,但它需要清楚的输入、明确的边界、可靠的反馈、可验证的结果。它需要一个地方,让它的每个动作都能被看见,让错误能被指出,让修正有路可走。
终端不是唯一答案。
但它是一个很好的提醒:界面的最高级形态,不一定是让一切看起来更像人类世界,而是让工作本身更容易被理解、执行和修正。
在这个意义上,黑底白字一点也不旧。
它只是提前很多年,长成了 AI agent 需要的样子。
Local graph
这篇文章在知识网络里的位置
Why these nodes?
- 为什么 AI Agent 把工程师又带回了命令行 → Prompt Injection 之后:AI Agent 真正危险的是工具链
links to this post - 为什么 AI Agent 把工程师又带回了命令行 → AI 不该替 QA 点按钮:它该先学会找茬
links to this post - AI 不该替 QA 点按钮:它该先学会找茬 → 为什么 AI Agent 把工程师又带回了命令行
links back to this post - 人人都有 AI,公司为什么还是没学会 → 为什么 AI Agent 把工程师又带回了命令行
links back to this post - Prompt Injection 之后:AI Agent 真正危险的是工具链 → 为什么 AI Agent 把工程师又带回了命令行
links back to this post - 为什么 AI Agent 把工程师又带回了命令行 → 从一键偷 Token 到 npm 投毒:AI 安全别只等扁鹊拔针
same series - 为什么 AI Agent 把工程师又带回了命令行 → Prompt Injection 之后:AI Agent 真正危险的是工具链
same series - 为什么 AI Agent 把工程师又带回了命令行 → AI 不该替 QA 点按钮:它该先学会找茬
shares concept: execution-evidence
Read next because
关联阅读,不是猜你喜欢。
Prompt Injection 之后:AI Agent 真正危险的是工具链
Agent 安全不是把 system prompt 写得更凶,而是重新设计工作授权:外部内容只能提供证据,不能授予行动权限;读和做必须分开。
AI 不该替 QA 点按钮:它该先学会找茬
把 AI 放进软件测试流程,最务实的做法不是让它凭空判断对错,而是让它从需求、用例、脚本、执行证据、缺陷归因和回归选择里接住重复劳动。
从一键偷 Token 到 npm 投毒:AI 安全别只等扁鹊拔针
GitHub token stealing 和 Red Hat npm 包投毒这两个事件,真正提醒我们的不是 AI 能不能发现漏洞,而是个人和企业能不能把披露、验证、修补和预防做成一条可执行的证据链。
人人都有 AI,公司为什么还是没学会
AI 让一次性产出变便宜。真正难的是,公司能不能把这些产出变成可复用的判断、工作流和组织记忆。