HashiCorp 创始人给终端写了个新协议：别再猜 agent 在干嘛了

同时开 8 个 agent 的人，都有一个共同的痛

如果你现在的工作流是"开 5 个终端窗口，每个窗口跑一个 coding agent"，那你一定经历过这个画面：切回某个窗口，发现 agent 20 分钟前就停下来了——在等你批准一个权限；另一个窗口显示"done"，但你不知道它什么时候做完的；还有一个看起来在疯狂输出日志，其实只是在循环重试同一个失败的命令。你花在"确认每个 agent 在干嘛"上的时间，快赶上写代码本身了。

10 月 6 日，HashiCorp 联合创始人、Ghostty 终端模拟器作者 Mitchell Hashimoto 在个人博客上发布了一个新规范，专门解决这个问题：OSC 7501，程序状态协议（Program Status Protocol）。一句话概括：让任何程序通过终端转义序列，主动告诉终端"我现在是什么状态、为什么"——而不是让终端（或你）去猜。

OSC 7501 是什么：五行代码讲清

技术上它是一个新的终端转义序列。程序想报告状态时，向自己的 pty 发送这样一串字符：

ESC ] 7501 ; state=blocked:kind=permission:app=terraform:msg=... ESC \

body 是用冒号分隔的 key=value 列表，唯一必填的是 state，取五个值之一：idle（空闲，等你下指令）、working（干活中，可带 progress 百分比）、done（做完了，结果还没被你看过）、blocked（卡住了，动不了）、error（失败了）。blocked 还要带 kind 说明卡在哪类事情上（permission 权限 / question 提问 / auth 认证），以及 base64 编码的 msg 讲清原因——比如 Terraform 可以报告"Apply 前被拦下：3 个新增、1 个修改、0 个销毁，等你确认"。

多任务的程序可以用层级 id 上报多条记录：一个部署工具可以同时报告"根任务 working，美东区正在推镜像（40%），欧洲区 blocked 等你批准上线生产"。终端决定怎么展示这些信息：通知、收件箱、状态图标，随它。clear 状态可以清除记录。

Mitchell 还给出了一个 shell 脚本的完整接入示例——给 rsync 包一层状态上报，纯 POSIX sh，不到十行，不需要 SDK、不需要 socket、不需要环境变量、不需要 JSON。这是整个设计哲学的缩影：对程序侧来说，发出状态应该像 echo 一样便宜。

为什么需要新协议：因为现在全靠"猜"

Mitchell 花了整整一节讲"为什么现有方案都不行"，而这节恰恰是 vibe coder 最有共鸣的部分。

背景是：同时跑多个长任务 agent 的人越来越多——后台做调研的、盯 issue 的、修 bug 的、大功能开发的——每个 agent 干一会儿就停下来：要权限、要提问、或报告做完了。于是催生了一个新的工具品类，Mitchell 称之为 "agentic inbox"（智能体收件箱）：一个视图纵览所有运行中的 agent，谁在干活、谁做完了、谁在等你。他点名的例子有 Herdr、cmux、Agent Deck，"以及另外几百个"。

这些工具今天解决"agent 状态"问题只有两招。第一招：启发式猜测。读屏幕内容或窗口标题，用正则匹配已知模式。Herdr 是这方面的优等生，而且文档写得很诚实：它的检测规则是 TOML 文件，一套规则专门识别 Claude Code——比如"窗口标题以盲文 spinner 字符开头就判定为 working"。Mitchell 指出一个残酷的事实：光是 Claude Code 的检测文件，三个月内就改了 10 次——因为 Claude Code 2.1.228 把 spinner 从盲文字符换成了半圆字符，规则就失效了。"这不是批评 Herdr，他们已经在现有工具下做到了最好。但它恰恰证明了统一协议的价值。"

第二招：各家私有 API。让程序通过收件箱专属的带外 API 上报状态，比如 Herdr 的 socket API 或 cmux notify 命令。这比猜要好——毕竟"真正知道状态的是程序自己"。但问题是：每个程序要单独对接每个收件箱（N×M 的集成地狱），而且本地 socket 过不了 SSH、进不了容器还得额外桥接。而 pty 天生跨越这一切——你的 agent 跑在远程服务器、容器、tmux 里，pty 都在。

所以 OSC 7501 的设计约束非常清晰：终端原生、无 SDK、无偏向任何 GUI 呈现、无偏向任何工作负载（包括 AI）。"行为良好的终端会忽略不认识的 OSC"，所以老终端不会被新序列搞坏，降级是安全的。

已经落地的部分：不只是纸面规范

这个规范不是 Mitchell 的空想。他已经亲手实现了两次：一次在 libghostty（Ghostty 的核心库），一次在 Rex（他的新终端项目）。更狠的是，他还给 Terraform、Claude Code、Codex、Homebrew 做了概念验证——每种都是插件或 fork 的形式，实现都不超过十几行代码。

十几行是什么概念？意味着任何 agent 工具的作者，一个下午就能让自家工具"会说话"。也意味着终端模拟器侧（Ghostty、WezTerm、Kitty、Alacritty……）一旦跟进，用户侧不需要装任何东西就能用上。他还表示已经联系了多个流行终端程序和模拟器的维护者参与评审规范，正在收集反馈，并邀请已经实现的工具发邮件给他，他会维护一份实现清单。

这个规范脱胎于他的两份工作：Ghostty（终端模拟器）和 Superlogical（他的新公司，做服务端终端 multiplexer，号称要解决 tmux 太慢、状态同步太重的问题）。两条线汇到一起，指向同一个判断：终端是开发者、agent、工具、基础设施的最大公约数——缺的不是更快的终端，而是一个"任务状态"的原语。

它站在哪些前人的肩膀上

OSC 7501 不是第一个想解决"程序状态"的转义序列，这个谱系值得了解一下，因为它能说明 Mitchell 到底解决了什么别人没解决的。

最老的是 OSC 9 / OSC 99：Windows Terminal 支持的任务栏进度通知，程序可以报告进度条。但它只能表达"进度"，表达不了"卡住了、为什么卡住"。

用得最广的是 shell integration（OSC 633 / 133 家族）：VS Code、WezTerm 都在用，shell 通过转义序列告诉终端"这里是 prompt 开始、这里是命令开始、这里是命令结束、退出码是多少"。它解决的是"命令行在哪"，但粒度是 shell 级别的——agent 在一次命令里跑 40 分钟、中间停三次要权限，OSC 133 看不到这些细节。

还有一堆各家终端私有的：iTerm2 有自己的转义序列做徽章、通知、进度，每家终端各搞一套，程序要适配 N 家。Mitchell 的野心是：做一个"终端原生、厂商中立"的版本，让程序只发一种序列，所有终端都懂。这个定位和当年 Unicode 统一各家编码有点像——不求功能最多，但求"通用"。

OSC 7501 和它们的关系是互补而非替代：OSC 133 告诉你"命令在哪"，OSC 7501 告诉你"任务怎么样了"。一个管位置，一个管状态。终端模拟器大概率会两个都实现——位置是给人看的，状态是给机器和人一起看的，缺了谁都不完整。

多说一句：协议的成败从来不取决于设计多优雅，而取决于"第一个吃螃蟹的大厂是谁"。OSC 7501 的运气不错——出生的第一天就带着 Ghostty 的实现和 Claude Code、Codex 的 PoC。如果接下来 WezTerm 或 VS Code 终端跟进，这个序列就有可能从"Mitchell 的个人项目"变成"终端的默认方言"。值得每隔几个月回来看看它的实现清单。

我们的判断：agent 基础设施在终端层补课

把 OSC 7501 放进 2026 年的 agent 基础设施版图里看，它补的是一块长期缺失的拼图。上层我们已经有了：MCP 让 agent 能调用工具，agent 协议让 agent 之间能协作，各种 inbox 工具让人类能纵览 agent。但最底层——程序如何向"我运行的地方"报告"我怎么样了"——一直靠的是 1970 年代的退出码和日志流。退出码只在结束时说一次，日志是给人看的不是给机器读的。OSC 7501 是第一次有人认真地为"运行中状态"设计一个机器可读的、终端原生的通道。

对 vibe coder 的直接影响分三层。短期（现在）：如果你用 Herdr/cmux 这类多 agent 管理工具，继续用——它们是这个协议的第一批受益者，协议普及后它们的检测会从"正则猜"变成"精确知道"，误报会大幅下降。中期（几个月）：关注你常用的 agent 工具（Claude Code、Codex、OpenCode……）会不会跟进上报状态——跟进了，你的多 agent 驾驶舱体验会好一个量级。长期："程序会报告状态"可能变成和"程序会写日志"一样的基础素养，就像当年所有 CLI 都学会了 --help 一样。

还有一个值得玩味的视角：Mitchell 在文章里特意写了一节"不关心 AI 的可以跳过"。这个协议是完全通用的——构建、部署、数据处理，任何长任务都用得上。他没有把它包装成"AI 协议"去蹭热度，而是坚持"终端原生、通用规范"的定位。最好的基础设施都是这样：解决一个具体而痛的问题（agent 状态），但设计成所有人都能用。这种克制，恰恰是它可能活得久的原因。

最后给动手派一个建议：Mitchell 公开征集实现者。如果你维护着一个 CLI 工具或 agent 相关的开源项目，花一个下午按规范加上状态上报，然后给他发封邮件——你的名字会出现在协议的实现清单里。这种早期参与标准制定的机会，在基础设施领域可不常有。