StateM：靠执行脚手架扩展在 Terminal-Bench 2.1 上拿下 95.3% 原始准确率或 15 美元的极限成绩 StateM: Reaching 95.3% Raw Accuracy, or a \$15 Frontier Run, on Terminal-Bench 2.1 via Harness Scaling
不改权重，用状态机运行时让智能体达 95.3%，或仅花 15 美元匹敌前沿
前置知识
智能体脚手架（Agent Harness）与脚手架扩展
脚手架是包裹在模型外部的执行系统，负责维护状态、约束执行、验证进度和从错误中恢复，包括提示词组织、工具调用循环、检查点和重试逻辑等。脚手架扩展（harness scaling）是本文提出的概念：与模型扩展（扩大预训练、增加后训练数据、延长推理）互补，通过系统性改进运行时控制层，把模型已有但未兑现的能力转化为可靠完成的任务。
全文的核心论点就是量化『有多少模型失败其实是脚手架失败』，不理解这个框架就无法理解为什么作者不改权重也能拿到大幅提升。
Terminal-Bench 2.1 与试验级准确率
一个包含 89 个真实终端任务的基准，覆盖服务配置、生物信息、数据恢复等场景。完整评测对每个任务跑 5 次试验共 445 次，主指标是试验级成功率（成功试验数/总试验数）；另报告五次试验任务覆盖率（至少成功一次的任务比例），它是经验覆盖率而非单次运行可靠性。
论文所有头条数字（95.28%、$15 成本）都以这套协议为分母，且作者特意区分了 raw 原始分、裁定后分数和任务覆盖率三种口径。
有限状态机与受检转移
状态机把流程建模为状态集合 $\mathcal{S}$、允许的边 $\mathcal{E} \subseteq \mathcal{S}\times\mathcal{S}$ 和转移条件；只有在条件满足时才能从当前状态跳到下一状态。本文的 runbook 定义为 $\mathcal{B} = (\mathcal{S}, s_0, \mathcal{S}_T, \mathcal{E}, \Phi)$，每次 goto 转移要经过六步有序协议：验证边存在、评估 before_transfer 检查、执行 out_hook 持久化、评估边守卫、提交并记录历史、执行目标状态 in_hook。
StateM 的全部控制能力（阻止未完成交接、失败留在可修复状态、恢复锚点）都建立在『转移前必须通过检查』这个状态机语义上。
CLI 智能体（Codex / Claude Code）
以命令行为主要动作空间的通用智能体：模型在统一循环里自由地读写文件、执行命令、迭代调试，保持完整推理能力。它们自带计划提示、TODO 列表、规则文件和钩子等控制碎片，但这些大多是软性自然语言约束或挂在工具事件上的钩子，并不构成一个权威的、可强制执行的执行状态。
StateM 明确保留这类通用智能体作为主执行者，把控制层暴露在它原本的 CLI 动作空间里，这是『agent-native』的含义，也是与 LangGraph 类编排系统的分界。
三类执行缺口：认知、合规与过程记忆
本文把『模型会做但系统仍失败』拆成三种：认知缺口（决策点上相关知识不可用，如不知道某统计工具的用法）；过程合规缺口（正确流程已激活但执行不完整，如没跑消费者验证就宣布完成）；过程记忆缺口（上次运行学到的教训在下次同类风险出现时未被保留或激活）。StateM 分别用状态局部上下文、受检转移和版本化实践对应解决。
这是论文的方法论骨架：每一个 StateM 机制都能映射到一种失败模式，理解它才能明白为什么某些任务提升巨大而某些出现负迁移。
研究动机
长时程智能体有一种典型的失败方式：底层模型明明能解决每个局部步骤，完整运行却失败了——智能体偏离计划、丢失可变任务状态、跳过必要检查、重复无效动作，或在交付物可验证完成之前就停下。真实工作流和基准评测的是『完成任务』而不是『知道怎么做大部分步骤』，因此这些失败是致命的。论文用数据说明问题的量级：在 Terminal-Bench 2.1 上，参考脚手架下 GPT-5.5 xhigh 只有 83.1%，换到新一代 GPT-5.6 Sol xhigh 也只有 84.9%，一次模型代际更替仅带来 1.8 个百分点的提升；而典型任务如 configure-git-webserver，基线智能体明明会配置 Git、SSH、钩子和 HTTP 服务器，却因不能可靠保持并验证端到端可用状态而得到 0/5。作者把执行压力归结为两个操作层面的问题：一是控制信号稀释——紧凑的计划和完成标准被越来越长的命令、观察、修复轨迹淹没；二是可变状态歧义——已完成目标、待决依赖、失败尝试和合法下一步必须从只追加的交互历史里重建，而不是从权威当前状态里读取。
本文的目标是本文要回答一个正交于模型扩展的问题：有多少表面的模型失败，实际上是维护状态、约束执行、验证进度和恢复错误的脚手架的失败？为此作者提出『脚手架扩展』这一能力轴，并设计一组递进的实证检验：第一，不动模型权重，更好的脚手架能否提升固定模型？第二，用一个模型开发的脚手架能否零改动迁移到更新的模型？第三，这些控制原则能否提升到开发基准之外的任务分布？同时还要回答成本问题：能否用远低于旗舰模型的 API 开销，把便宜模型推到前沿水平？具体目标落为一个名为 StateM 的智能体原生运行时：以人可读的 YAML runbook 组织执行，包含状态、合法转移、状态局部指令、钩子、检查和恢复规则，智能体和人类用户可以共同检查、修改和审计这层控制，而模型权重完全冻结。
与已有工作不同的是，现有系统在『运行时可强制执行性』和『智能体自主性』之间存在一个未被占据的组合点。状态机/图式编排系统（StateFlow、LangGraph 等持久工作流）提供显式状态、条件路由、检查点恢复，但通常由开发者编写控制器，把模型当作节点里的被调用者，控制工件外在于执行智能体；通用 CLI 智能体（Codex、Claude Code）保留广阔的推理和动作空间，但其计划、指令文件、记忆和钩子只是软性碎片，不构成统一的、转移感知的控制面。与 AgingBench 等跨会话可靠性诊断、与自动化脚手架适配研究也不同——后者证明『脚手架可优化』本身不新。StateM 的独特切入在于：控制层是一台状态机，但操作它的是智能体自己——通过完成任务所用的同一套 CLI 命令来查询状态、请求转移、检查失败条件、提出 runbook 修改；而 runbook 是智能体和用户共同可见、可编辑、可版本化的共享工件。也就是说，区别不在于系统有没有状态，而在于执行期间谁能检查、修改和操作这层有状态控制。
核心方法
直觉上，StateM 把一个长任务的执行过程从『一条越滚越长、真相越来越模糊的终端记录』改造成『一台外部权威状态机上的明确旅程』：智能体始终知道自己在哪个阶段、本阶段该做什么、离开前必须证明什么，而且这些信息由运行时持久化在模型上下文之外。技术上，StateM 分为两层：通用运行时提供状态持久化、转移验证、钩子执行、历史与恢复机制；控制档案（control profile）以 YAML runbook 表达，规定某个工作类别的阶段、指令、检查与修复策略。runbook 形式化为 $\mathcal{B} = (\mathcal{S}, s_0, \mathcal{S}_T, \mathcal{E}, \Phi)$，其中 $\Phi(s)$ 是状态规范，包含阶段局部提示、进出钩子、转移检查和状态局部工件引用。典型编码 runbook 包括 Plan、Execute、Verify、Repair、Handoff 等粗粒度阶段，每个状态展开后是 in_hook（加载上下文、初始化文件）→ 状态体（模型自由工作）→ out_hook（持久化、写回执）→ before_transfer（阻塞式检查）四段结构。所有阶段变更通过 goto 操作走六步有序协议，任何前置检查失败都让运行留在原状态并记录原因，智能体可以修复后重试。运行结束后，失败被归类为缺失上下文、非法转移、弱检查、过早交接或无效恢复等控制层缺陷，由工作智能体或超智能体提出 runbook 修改，经回归测试后并入新版本——模型权重不变，过程性知识在控制层累积。
核心创新是把『状态』同时当作上下文边界和契约边界。作为上下文边界，进入状态时 in_hook 刷新该阶段的指令与持久进度，制造一个新鲜的控制锚点，使权威阶段和当前义务变得显眼而近期，智能体不必从冗长轨迹里反推自己的位置；作为契约边界，离开状态必须满足显式退出条件，而且不同检查的证据强度被严格区分：命令/谓词检查由宿主执行、可独立复现；manual 检查需要真人决策；checklist/message 检查只是结构化自我承诺；llm_review 提供语义判断但绝非确定性验证——这防止了『智能体的完成声明被当作独立验证』。第二个关键点是与 StateFlow/LangGraph 的本质区别：主执行者仍是保留统一推理循环的通用 CLI 智能体，不被分解成一串节点级模型调用，控制层就在智能体原本的工具环境里，用 goto 等普通命令操作。第三个关键是共享可操作性：runbook 是工作区里的普通工件，智能体可以在运行中注册新的动态检查（只能加严不能削弱），用户可以审查、编辑、版本化同一份文件。三类执行缺口各有一个对应控制点：认知缺口由状态局部 in_hook 激活知识解决，合规缺口由转移守卫阻塞未完成交接解决，记忆缺口由把教训固化为版本化实践（practice）解决。
方法步骤详情
开发流程分四个阶段落地。第一步，用 GPT-5.5 xhigh 开发 Terminal-Bench 控制档案：人类提供高层架构和『黄金规则』（偏好最小可复用控制、从可见任务语义而非任务身份路由、开发反馈与冻结评测严格分离），GPT-5.5 Codex 完成大部分脚手架实现和轨迹分析，超智能体在累积轨迹超出单上下文容量时做抽象审查；过程中不用隐藏测试、验证器实现、公开解法或任务哈希作路由键。第二步，冻结档案并迁移：对 GPT-5.6 Sol xhigh 和 Luna，提示词、状态、路由、检查目录、默认值和修复策略全部冻结，运行中允许的动态检查只从任务可见信息实例化、只记录不提升。第三步，跨供应商适配：冻结的 GPT 档案直接用于 DeepSeek-V4-Flash 反而降分，于是允许一个新的适配阶段，在相同运行时、runbook 骨架、适用控制和黄金规则上花费不到 38 美元调整具体实践，再冻结做最终评测。第四步，任务侧泛化：BusinessBench 上为每个任务族单独建档案，GPT-5.6 Luna 任务智能体跑开发实例并从失败轨迹提出可复用修改，GPT-5.6 Sol xhigh 超智能体评估族级通用性与兼容性后合并，冻结后做首次 held-out 一次性评测。运行期间，每次 goto 依次执行：验证边存在→评估 before_transfer 检查→执行 out_hook→评估边守卫→仅当全部成功才提交并追加历史→执行目标状态 in_hook；进程重启后智能体从持久运行记录（运行 ID、当前状态、转移历史、未决检查、证据文件）恢复，而不是重读整条终端记录。
技术新颖性
单独看每个组件都不新：状态机编排早已存在，钩子和检查点是工程常识，脚手架自动适配近年也有多项工作（Life-Harness、Self-Harness、Better Harnesses, Smaller Models 等）。论文明确承认这一点，其新颖性在于三者的组合方式和被优化的工件本身。第一，runbook 这个表示同时扮演三个角色：运行时控制面、审计面、以及失败驱动改进的搜索空间——prompt-only 的脚手架优化无法改动转移时检查、恢复行为和状态局部上下文，而完全外置的工作流图又把控制留在执行智能体之外，StateM 让被优化的东西恰好是智能体自己操作的那份 YAML。第二，『状态=上下文与契约双重边界』的抽象把两类失败（不知道该做什么/知道但没做完）分别对准，且对检查的证据强度做了显式分级，这在同类系统中少见。第三，论文把『脚手架本身必须便宜到可快速修改』提炼为脚手架扩展的先决条件：传统图运行时的节点/边/处理器修改是重工程，StateM 的 YAML 修改是数据操作，这使 22 小时量级的一天尺度开发循环成为可能。第四，迁移实验设计本身有方法论价值：把『精确档案跨代迁移、开发原则跨供应商迁移、控制边界抽象跨任务迁移』作为一个层级来测量，而不是问一句『能不能迁移』。
实验结果
实验覆盖四层证据。固定模型提升：GPT-5.5 xhigh 加 StateM 在 Terminal-Bench 2.1 达 92.1%（参考 83.1%，+9.0），五试验覆盖 88/89 任务，且超过 91.9% 的 GPT-5.6 Sol ultra 参考——脚手架增益复现了一次模型代际升级。冻结跨代迁移：档案冻结后用于 GPT-5.6，Sol xhigh 在 445 次试验中成功 424 次即 95.28% 原始准确率（参考 84.9%，+10.4），89 个任务全部至少成功一次；但这是裁定前公开提交分，疑似奖励破解轨迹记零后为 93.26%，PR 尚未合入排行榜；同一冻结档案还把 Luna 从 76.7% 提到 85.4%（+8.7），反超 Sol xhigh 参考。成本前沿：GPT 档案原样用于 DeepSeek-V4-Flash 从 82.7% 降到 82.0%（精确迁移失败），花 37.02 美元适配后达 392/445=88.09%（标准超时），88 任务公共核 89.09%，唯一超时敏感的 gpt2-codegolf 单独延长超时后描述性全量 88.76%，一位小数追平 88.8% 的 GPT-5.6 Sol max；最终证据仅花 15.20 美元，约为公开 GPT 提交 574.68 美元的 1/37.8。任务泛化：BusinessBench 冻结一次性 held-out 宏平均仅 +0.55（84.67→85.22）、微平均 +1.34，但机制匹配的 Budget Approval + Machine Operating 子组从 71.91% 升至 81.94%（+10.04，machine-operating 达 100%），RefactorBench −2.78、WooCommerce −3.70 暴露负迁移；事后诊断证明修正控制边界后两者可救（WooCommerce 86.42→90.12、RefactorBench 76.39→79.17）。任务级增益集中在关键边界：configure-git-webserver 0/5→5/5、dna-insert 0/5→5/5、dna-assembly 1/5→5/5；另有一次档案开发运行连续 22 小时跨越上下文刷新仍保持控制状态。
查看结构化数据
| 任务 | 指标 | 本文 | 基线 | 提升 |
|---|---|---|---|---|
| Terminal-Bench 2.1（GPT-5.6 Sol xhigh，冻结档案） | 试验级原始准确率（445 试验） | 95.28%（424/445，裁定前公开提交分；严格裁定后 93.26%–94.38%） | 84.9%（GPT-5.6 Sol xhigh 参考脚手架） | +10.4 个百分点，89 任务全部至少一次成功 |
| Terminal-Bench 2.1（GPT-5.5 xhigh） | 试验级准确率 | 92.1% | 83.1%（GPT-5.5 Codex 公开参考；另超 91.9% GPT-5.6 Sol ultra 参考） | +9.0 个百分点，任务覆盖 88/89 |
| Terminal-Bench 2.1（GPT-5.6 Luna，冻结档案） | 试验级准确率 | 85.4% | 76.7%（Luna 参考） | +8.7 个百分点，低成本档反超 84.9% 的 Sol xhigh 参考 |
| Terminal-Bench 2.1（DeepSeek-V4-Flash，适配档案，标准超时） | 试验级准确率 | 88.09%（392/445；88 任务公共核 89.09%；延长超时描述性全量 88.76%） | 82.7%（基线）；冻结直迁移仅 82.0% | +5.39 个百分点，一位小数追平 88.8% GPT-5.6 Sol max |
| Terminal-Bench 2.1 最终证据成本（DeepSeek 路线） | 实际 API 花费（美元） | $15.20（适配+全部评测合计 $52.22） | $574.68（GPT-5.6 Sol max 公开提交报告的模型成本） | 约 1/37.8，总投入约 1/11 |
| BusinessBench（6 处理族，Codex+GPT-5.6 Luna，冻结一次性） | held-out 家族宏平均 / 实例微平均 | 85.22% / 85.78% | 84.67% / 84.44%（Codex CLI） | +0.55 / +1.34 个百分点；开发集 +5.64、全部处理实例 +3.96 |
| BusinessBench 机制匹配子组（Budget Approval + Machine Operating） | held-out 家族宏平均 | 81.94%（budget-approval 62.91→75.12，machine-operating 90.79→100.00） | 71.91% | +10.04 个百分点 |
局限与改进
作者承认的局限相当坦率：95.28% 是裁定前的公开提交分，PR 未合入排行榜，疑似奖励破解轨迹记零后降为 93.26%；GPT-5.5 参考是模型匹配的公开结果而非同智能体版本的 A/B 重跑；结果测的是『运行时+演化后的控制档案』组合，不能归因于状态机抽象本身；五试验任务覆盖率不等于单次运行可靠性；BusinessBench 冻结聚合提升微弱（宏 +0.55），且各族规模不等、每臂每实例只有一条随机轨迹，没有方差估计；gpt2-codegolf 的描述性 88.76% 改变了运行条件（延长超时）才能与 88.8% 对齐；成本对比混合了不同计费结构（$1062.95 是流水线按 API 等价折算的成本，作者实际走 Codex Pro 订阅并未自掏这么多）。我自己的观察补充几点：档案开发深度依赖人类黄金规则和超智能体审查，自动化程度存疑；DNA 插入任务里档案通过验证器反馈学到了任务描述中不存在的『最左插入』约定，这种对评测器惯例的隐式拟合与 Terminal-Bench 上未声明的视频帧精度默认值一样，属于危险的基准特异性记忆；所有对比基准的分数都在快速变动中，跨模型参考的可比性会随时间衰减。
独立分析的弱点
第一，黄金规则和高层架构仍由人类手工指定，失败归因、实践抽象和『哪些教训值得持久化』的判断大量依赖超智能体与人的审查，这在任务分布变化时是最脆弱的一环——改进方向是把边界质量（control-boundary quality）本身变成可优化的目标，例如用消融式自动验证候选实践的边际贡献。第二，过程记忆可能记错东西：RefactorBench 首版档案把有效失败错误地抽象成过度的兼容性流程导致 −2.78，WooCommerce 档案装了流程却丢了跨系统不变量导致 −3.70，说明目前没有预测『控制应绑在哪个执行边界』的事前方法——可以探索从任务规格自动抽取不变量与完成条件、以机制匹配度打分决定是否部署档案，甚至像 attendance-payroll 那样把『弃权』也变成可学习的决策。第三，对验证器惯例的隐式拟合（最左插入、帧精度默认值）表明失败驱动优化会把评测偏差当知识存储——改进方向是为每条实践记录证据来源与适用条件，并显式区分『任务契约』与『评测器行为』。第四，统计功效不足：BusinessBench 每臂单轨迹、WebArena 25 实例中仅 3 个非平局结果，很多结论在噪声边缘；应引入多种子重复与配对检验。第五，stop hook 防早停可能演变成无限烧钱循环，论文也承认它不保证终止——需要与预算、退避和收益检测联合调度。第六，安全边界不完整：YAML 可编辑性本身不提供权限分离，沙箱与权限控制被推给宿主；应设计 runbook 的分级写权限与签名机制。第七，全部结论限于单智能体流，多智能体角色隔离只有展望。
未来方向
作者明确提出的方向包括：把 StateM 与 AgingBench 式的生命周期诊断结合——用跨会话的压缩/干扰/修订/维护老化定位退化机制，再由 runbook 适配闭环修复，形成『诊断+执行』的完整可靠性栈；扩展到角色隔离的多智能体运行时，利用状态、上下文与权限的分离防止单一上下文里自我强化的错误决策，但这会带来状态共享与权限设计的新问题。基于本文成果还可自然延伸：一是把『迁移层级』做成预测工具——给定模型对与任务族，先小成本估计精确档案能否迁移、需要多少适配预算，把 38 美元式的适配变成可规划的支出；二是过程记忆的遗忘与修剪机制，论文已证明『记更多不是更好记忆』，需要主动删除与重写实践的策略；三是把检查的证据强度分级形式化，让 llm_review 类软检查与命令类硬检查在风险成本框架下自动组合；四是把成本-质量前沿（Figure 5）扩展成多模型路由：运行时按任务特征在 GPT 与 DeepSeek 之间分配调用；五是在真实生产工作流（而非基准）中验证 22 小时级运行与恢复锚点的价值；六是探索 runbook 作为人类-智能体契约的治理问题——审计、版本签名与变更审批流程。
复现评估
复现条件中等偏上但门槛在快速降低。有利因素：核心代码和若干运行时案例已开源（论文摘要给出 GitHub 链接）；DeepSeek-V4-Flash 是公开 API 模型，论文完整披露了成本结构——适配 37.02 美元、最终评测 15.20 美元、合计 52.22 美元，意味着一个个人开发者用几十美元就能复现成本前沿的主结果；三套 Terminal-Bench 数字（88.09%/89.09%/88.76%）的运行条件被逐一披露，BusinessBench 的处理族选择、冻结协议和事后验证流程也写得足够细。不利因素：GPT-5.5/GPT-5.6 系列依赖 OpenAI 特定订阅与提交渠道，95.28% 的复现需通过 harbor 框架的 445 试验公开提交，公开渠道报告的模型成本即达约 1063 美元；论文只说『档案经 GPT-5.5 演化、冻结后使用』，runbook 的最终版本是否完整随代码发布未明确承诺，而 Terminal-Bench 分数高度依赖那份演化后的具体档案，只复用运行时框架会得到远低的分数；22 小时开发运行的轨迹分析流程半自动化，需要相当的人工判断。总体判断：复现 DeepSeek 88% 级别结果对有经验的工程师是可行的小额项目；复现 GPT 质量前沿则需要提交渠道、耐心和数百至千美元级预算。
论文图表
一张二维象限图：纵轴是运行时可强制执行性（运行时是否维护权威执行状态、约束合法转移、能否阻止不完整交接），横轴是智能体自主性（主智能体选择工具、修订流程、在大动作空间内运作的自由度）。标记样式区分控制工件的归属：开发者拥有（StateFlow、LangGraph 等图式编排位于强控制-弱自主区）、智能体自有软控制（软计划/清单、Codex/Claude Code 的 DIY 控制层碎片位于弱控制-强自主区）、以及智能体与用户共同可见可编辑。StateM 被标注在右上角——既保持广阔智能体自主性又有可强制执行的状态转移。
这张图是全文定位声明：StateM 的贡献不是发明状态机或钩子，而是占据『强执行+强自主+共同所有权』这个此前空白的组合点。理解它才能准确说出 StateM 与 LangGraph、与裸 Codex 的本质差别，也才能理解作者反复强调的『区别不在有没有状态，而在谁能操作状态』。