StateM：不改模型权重，给智能体套个"状态机外壳"就能涨 10 个点
论文：https://arxiv.org/abs/2608.15089 作者：Ziheng Qin、Yaxin Lu（共同一作）、Zhangyang "Atlas" Wang、Kai Wang 日期：2026 年 8 月 15 日 代码：https://github.com/henryqin1997/statem
核心摘要
长程智能体有个很憋屈的死法：模型明明每一步都会做，整个任务却跑砸了——中途忘了可变状态、之前踩过的坑没记住、跳过已知流程、或者提前撂挑子。这篇论文的赌注很直接：问题不在模型，在 harness（围绕模型的执行系统）。作者提出 harness scaling 概念——像扩展模型一样去扩展执行控制层，不动一行模型权重。落地系统叫 StateM：一个 agent 原生的运行时，用 YAML runbook 把执行组织成"持久状态 + 阶段局部上下文 + 受检转换 + 可恢复运行手册 + 版本化实践经验"。战绩相当夸张：Terminal-Bench 2.1 上 GPT-5.5 xhigh 从 83.1% 拉到 92.1%（+9 点，约等于一次模型代际升级）；冻结的 runbook 原封不动迁到 GPT-5.6 Sol xhigh，拿到 95.28% 原始分（445 次试验过 424 次，89 个任务全部至少过一次）；更狠的是成本侧——给 DeepSeek-V4 Flash 做适配只花不到 38 美元，最终评测证据只花约 15 美元 API 费用（对照的 GPT 提交花 574.68 美元），分数却摸到 88.8% 的 GPT-5.6 Sol max 水平。一句话：模型扩展决定智能体"能做什么"，harness 扩展决定它"能不能把活干完"。
🎯 一个反直觉的问题
现在提升智能体能力的主流路径是：堆预训练、加后训练数据、加测试时推理、再加几个 agent。这篇论文偏要唱反调，问了一个正交问题：
有多少"模型失败"，其实是 harness 的失败——那个本该维护状态、约束执行、验证进度、从错误中恢复的外层系统？
作者给出两个操作性假设（不是对 transformer 注意力的根本论断）：
- 控制信号稀释（control-signal dilution）：紧凑的计划和完成标准，被越来越长的命令、观察、修复轨迹包围。附录的 Figure 6 把这个画得很形象——计划 token 抽象层级高、数量少但关键，弧线权重代表注意力，计划在长轨迹里只分到"最细的一根线"。
- 可变状态模糊（mutable-state ambiguity）：已完成的目标、待处理的依赖、失败的尝试、合法的下一步，都要从 append-only 的历史里重建，而不是从权威当前状态读取。Figure 7 对比了线性依赖的简单任务（最新值好找）和带循环分支的复杂任务（同一变量交错追加多个版本，"当前哪个是活的"根本说不清）。
这两个假设指向同一个处方：把程序状态外化、按阶段刷新控制信息、在关键转换前检查证据。
📖 论文信息
- 标题：StateM: Reaching 95.3% Raw Accuracy, or a $15 Frontier Run, on Terminal-Bench 2.1 via Harness Scaling
- arXiv：2608.15089（v1，2026-08-15）
- 署名：作者注明这是个人时间完成的工作，不代表任何所属机构观点；全部实验在个人 Codex Pro 订阅 + MacBook Pro 2025（M4）上完成，正式提交跑在 AWS m7i.4xlarge 上，总预算控制在 200 美元以内（实际不到 125 美元）。这个"个人科研"背景本身就是论文叙事的一部分——harness 开发不该是大厂专属。
🧠 StateM 设计：状态即"上下文+契约"边界
设计空间的空位
论文 Figure 1 画了一张控制层设计的象限图：纵轴是运行时强制力（runtime enforceability），横轴是 agent 自主性（agent autonomy），点的样式区分控制工件归谁所有（开发者/智能体/双方共编）：
- 朴素 agent：计划只在上下文里，容易半途而废（右下）；
- Codex / Claude Code：软计划、checklist、钩子，agent 自己持有软控制，但没有原生状态钩子（中右）；
- StateFlow：有限状态机控制，能抓错修复，但控制层对 agent 不可见不可编（左上）；
- LangGraph：图编排包住 agent，控制强但主要用户可见可编（左上）。
StateM 瞄准的是右上角那块空地：宽泛的 agent 自主性 + 可强制的状态转换 + agent 和用户共同可见可编的控制工件。这个定位不是说哪个点绝对最优——稳定重复的工作流适合固定图，短任务可能一个指令文件就够；StateM 服务的是中间地带：开放到需要通用 agent，又长又重到软计划和自我声明完成不够用。
运行时与控制配置分离
StateM 刻意拆成两层：
- 运行时（runtime）：通用机制——状态持久化、转换验证、钩子执行、历史、恢复，跨 agent 跨工作流可复用；
- 控制配置（control profile / runbook）：版本化 YAML 工件，定义状态、转换、提示词、钩子、条件、检查、修复策略，可以编码工作流特定的程序性知识。
这个拆分对解读实验很关键：Terminal-Bench 的成绩是"运行时 + 演化出的基准适配 profile"的组合效果，不能当成纯粹状态机抽象的功劳。作者对此非常坦诚，反复强调这一点。
状态的双重身份
每个状态是有意义的工作阶段（规划、实现、契约检查、自审、修复、交接），而不是单次模型调用。它有两个身份：
- 上下文边界：进入状态时，
in_hook注入提示、跑初始化、加载紧凑进度记录——给当前阶段一个新鲜的控制锚点，agent 不用从一长串终端输出里推断"我现在到哪了"。注意这不擦除模型上下文，也不保证无损压缩，只是让权威阶段和其义务变得显式且新近。 - 契约边界：离开状态要满足显式退出条件。
out_hook负责持久化进度、写回执；before_transfer块在转换提交前评估配置好的退出条件，检查不过就把 run 摁在原地。
检查按证据强度分四档，这个区分很讲究：
- 命令/谓词检查：宿主执行，可独立复现（取决于命令本身正确）；
- manual 检查：需要人或操作员显式决策；
- checklist/message 检查：agent 确认义务，但本质是结构化自我声明；
- llm_review 检查：引入独立语义判断，但非确定性验证。
作者的潜台词：agent 自己说"完成了"不算独立验证。StateM 让这些声明可见、可审计，但可靠性仍取决于产生和验证它们的机制。
goto 协议：受检、留痕、可恢复
形式上 runbook 是 \(\mathcal{B} = (\mathcal{S}, s_0, \mathcal{S}_T, \mathcal{E}, \Phi)\)：状态集、初始态、终止态、合法转换边、每态的局部规格（提示、钩子、检查、工件引用）。边上可以有守卫条件，比如验证失败路由到 repair、证据充足去 handoff、等外部服务就去 wait——修复路由是图里显式的，不是让 agent 自己记住的隐含指令。
agent 请求 goto TARGET 时，StateM 执行六步有序协议：
- 验证当前态到 TARGET 的边存在；
- 评估当前态的
before_transfer检查； - 执行当前态的持久化/
out_hook； - 评估边守卫和边级 transfer hook；
- 全部前置步骤成功才提交目标态、追加转换事件到历史；
- 创建目标态入口、执行
in_hook。
任何前置失败，run 留在源态并记录失败原因，agent 可以查看未满足条件、修复、重试。作者特意强调这是"checked, logged, recoverable"而非完全事务性——StateM 延迟提交运行时状态，但没法回滚 hook 造成的外部副作用（比如已经发出去的邮件）。
恢复与停止钩子
每次运行有独立记录：run ID、当前态、转换历史、hook/检查结果、时间戳、证据文件引用。进程重启、上下文刷新、模型侧压缩之后，agent 直接问 StateM"我在哪、欠了什么"，不用从几百屏终端输出里考古。
还有一个针对 Codex / Claude Code 的 stop hook：宿主收到停止请求时，hook 检查 StateM 状态——如果已在终止态或显式等待外部依赖，放行；否则把当前阶段和未履行义务退还给 agent，要求继续干。这是防"提前撂挑子"的直接手段。作者同时泼了冷水：stop hook 不保证最终成功，agent 可能卡死在检查上或预算耗尽，所以仍要配重试、时间、资源上限。它的收益是执行持久性和更明确的停止条件，不是推理能力。
三类失败缺口与三个控制点
论文把执行失败操作化为三种缺口，各自对应一个控制点，这个映射是全文的骨架：
| 失败缺口 | 含义 | StateM 控制点 |
|---|---|---|
| 认知缺口（epistemic gap） | 决策点上没有相关知识或方法 | state-local context（in_hook 在恰当阶段激活领域知识） |
| 程序记忆缺口（procedural-memory gap） | 跨 run：之前 run 诊断出的教训没存住、没激活 | 版本化 practices（教训变成持久的提示/检查/激活规则） |
| 程序遵从缺口（procedural-compliance gap） | 单次 run 内：正确流程已激活但没执行完 | 受检转换（不完整的交接被阻断，run 留在可修复态） |
失败驱动的 harness 优化循环
因为 runbook 是机器可操作的显式工件，harness 本身可以被优化：跑完一轮后，把失败归类为缺上下文、非法转换、检查太弱、交接过早、恢复无效等控制层缺陷，然后由工作 agent 或独立的 hyper-agent 提议修改状态边界、提示、钩子、检查、恢复规则、practice 激活条件，候选改动经回归测试后并入新版本 runbook。模型权重不动，程序性知识在外层积累。附录 A 给了一个完整 coding-agent runbook 示例：start → plan → execute → review →（execute 回路 / handoff / session_refresh），每个节点都有 prompt、in_hook、out_hook、before_transfer checklist，边上有自然语言条件。
📊 实验：两条前沿 + 一个迁移层级
实验沿三条轴组织四种范式：固定模型提升 → 同族冻结迁移 → 跨供应商适配迁移 → 跨任务分布泛化。核心问题是：随着模型和任务距离变远，"什么东西还能迁移"。答案是迁移对象越来越抽象——近邻模型共享具体 profile，跨供应商只剩运行时+runbook 结构+黄金法则，跨任务只剩"如何定位和保护关键执行边界"的方法论。
Terminal-Bench 2.1：质量前沿
基准 89 个任务、每任务 5 次试验、共 445 次，主指标是试验级成功率。结果汇总（对应论文 Table 4）：
| 系统 | 配置 | 分数 |
|---|---|---|
| GPT-5.5 xhigh + Codex | 公开参考 | 83.1% |
| GPT-5.5 xhigh + StateM | 自研 profile | 92.1%，88/89 任务覆盖 |
| GPT-5.6 Sol xhigh + Codex | 公开参考 | 84.9% |
| GPT-5.6 Sol xhigh + StateM | 冻结 GPT profile，公开提交 | 95.28% raw，89/89 覆盖 |
| GPT-5.6 Luna + Codex | 公开参考 | 76.7% |
| GPT-5.6 Luna + StateM | 冻结 profile | 85.4% |
几个值得细嚼的点：
- 固定模型 +9.0 点 vs 模型换代 +1.8 点。参考 harness 下 GPT-5.5→GPT-5.6 Sol 只涨 1.8 点；StateM 在 GPT-5.5 上 +9.0、在 GPT-5.6 Sol 上 +10.4。Figure 3 和 Figure 5 把这个" harness 增益 ≈ 一次模型代际升级"的对比画成散点：GPT-5.5+StateM 的 92.1% 已经压过 GPT-5.6 Sol Ultra 的 91.9% 参考线。作者的原话很到位：模型扩展扩大能力边界，harness 扩展决定能力有多可靠地变成完成的工作。
- 冻结迁移零改动。GPT-5.5 上开发的 profile 在见到任何 GPT-5.6 评测结果之前就冻结，原样套到 GPT-5.6 Sol 和 Luna。Figure 4 强调"零目标模型 runbook 改动"——注意"冻结"指零改动，不是零评测成本。Luna（更便宜档位）+ StateM 的 85.4% 反超 Sol xhigh 参考的 84.9%，便宜的模型配好 harness 打赢贵一档的裸模型。
- 95.28% 的诚实披露。这是 PR #142 公开提交流水线的原始分（评审前），通过了十项自动检查，但 PR 未合并进榜单。作者主动交代：评审认定 4 条轨迹不该计分则 420/445=94.38%；若 9 条疑似 reward hacking 轨迹全部计零则 415/445=93.26%。提交消耗 11.78 亿 token、流水线估算模型成本 1062.95 美元。这种把裁决敏感性写进正文的姿势，在刷榜论文里算少见。
任务级证据：增益集中在"关键边界"
Table 3 列了 GPT-5.5 上的代表性任务提升，模式高度一致——最大增益都出现在关键边界上：
- configure-git-webserver 0/5 → 5/5：基线 agent 会配 Git、SSH、hooks、HTTP 服务器，但从不可靠地保持和验证端到端存活状态。StateM 把最终交接门控在新鲜的消费者侧证据上：必须物化 clone–commit–push–curl 完整链路才能离开验证态；验证若扰动环境，run 留在可修复态直到一致性恢复。没有新增任何组件级能力，只是把模型已有的能力在关键交接边界前组合、检查、闭环。
- dna-insert 0/5 → 5/5、dna-assembly 1/5 → 5/5：状态局部的生物学/引物契约检查、引物-Tm-组装不变量的转换门。
- db-wal-recovery 2/5 → 5/5：破坏性操作前的预检保存。
- 其余如服务就绪门、VM 生命周期闭环、候选优先的有界精化等。
作者注明这些关联不是组件消融，但模式足够清晰：服务就绪再交接、契约满足再提交、破坏前先保存、证据闭环再宣布完成。
成本前沿：15 美元的头部成绩
跨供应商处出现转折。冻结的 GPT profile 直接套到 DeepSeek-V4-Flash，分数 82.7% → 82.0%，精确 profile 迁移在供应商边界失败了——因为 StateM 保留了 base agent 大量自主性，供应商特有的行为差异仍然关键。
但适配不是从零开始：运行时、runbook 高层结构、路由策略、已适用控制、失败分析循环、黄金法则全部保留。只花 37.02 美元做供应商特定适配后：
- 标准超时全量：392/445 = 88.09%（+5.39 点）；
- 披露的 88 任务公共核（排除延迟敏感的 gpt2-codegolf）：392/440 = 89.09%；
- 仅对该任务延长超时（3/5 通过），描述性聚合 395/445 = 88.76%，一位小数恰好追平公开报告的 GPT-5.6 Sol max 88.8%。
成本对比是全文最扎眼的数字：DeepSeek 最终评分证据的实测 API 费用 $15.20，对照公开 GPT-5.6 Sol max 提交的 $574.68——约 1/37.8；全部适配+评测共 $52.22，也只有约 1/11。Figure 5 把分数-成本对画在同一坐标系：DeepSeek+StateM（88.76%, $15.20）与 GPT-5.6 Sol xhigh+StateM（95.28%, $1062.95）两个橙点把质量-成本前沿同时向左上推。部署经济学被改写了：选择不再是"买最强模型"，而是"投资 harness，让便宜模型变成更强的系统"。
BusinessBench：任务侧泛化跟随"控制边界"
477 个实例、7 个任务族，用 Codex + GPT-5.6 Luna。attendance-payroll 族被主动弃权（不套 StateM 工作流，作为对照），实际干预 6 族 405 实例。流程是 GPT-5.6 Luna 任务 agent 跑开发集、提复用改动，GPT-5.6 Sol xhigh hyper-agent 评审族级通用性后合并进族 profile，冻结后一次性 held-out 评测。
Table 1 的冻结一次性结果：
| 范围 | Codex CLI | StateM–Codex | Δ |
|---|---|---|---|
| Held-out 族宏平均 | 84.67 | 85.22 | +0.55 |
| Held-out 实例微平均 | 84.44 | 85.78 | +1.34 |
| 开发集 | 86.07 | 91.71 | +5.64 |
| 全部干预实例 | 84.76 | 88.72 | +3.96 |
| Budget Approval + Machine Operating 子组 | 71.91 | 81.94 | +10.04 |
族级分布揭示真正规律（Table 1 下半）：Budget Approval +12.21、Machine Operating +9.21、WebArena +4.00、WebTest +0.50，但 RefactorBench −2.78、WooCommerce Stock −3.70——负迁移。
负迁移的复盘比正增益更有信息量（Table 2 的评测后诊断）：
- RefactorBench：初版 profile 过度强调最小改动和向后兼容，却没闭环显式的代码迁移义务。换成"义务追踪+签名核验+全仓陈旧引用扫描"的更薄 profile 后，总分 76.39% → 79.17%。教训：有用干预不是更多通用兼容程序，而是直接的义务闭环。
- WooCommerce：初版有一堆程序却没保住跨系统不变量（库存实体、目的地级去重、不可逆邮件、回执）。换成不变量匹配的 profile 后，86.42% → 90.12%。
- Attendance：弃疗本身就是正确的控制决策。
结论凝练成一句：harness 泛化跟随机制匹配，而非任务多样性。强 profile 不是最大化的通用工作流，而是绑定最少可能漂移的不变量、在违规会造成后果处验证。附录 Table 5 把这些抽象失败模式（阶段副作用泄漏、算术依赖漂移、跨目的地实体错配、批量数据膨胀、瞬时vs确定性失败、服务会话持久性等）蒸馏成 11 条可复用控制，每条配执行证据机制和适用族。
程序记忆必须是选择性的
4.7 节是全文思想浓度最高的部分。runbook 既是运行时控制面，也是跨独立执行的选择性程序记忆。作者给了三个"记忆失败"的反面教材：
- 记住不该记的：Terminal-Bench 视频任务没规定目标帧精度，hyper-agent 观察基准行为后把默认精度值写进 profile——模糊规格被事后解析、再当作通用实践存下来；
- 评估器反馈渗入记忆：DNA 插入任务的验证器选最左有效插入边界，这个约定根本不在任务描述里，但反复反馈会让 profile 学会复现它——行为与评估器一致，语义却来自评估器而非任务契约；
- 对的失败被抽象错：BusinessBench 初版把过多兼容程序给了 RefactorBench、把过重工作流给了检索主导的 WebArena。
设计规则因此很直接：经验必须先过滤才能成为记忆；harness scaling 是抽象问题，不是规则堆积；目标是记住关键边界，而不是记住每一条失败轨迹。
22 小时连续运行
4.8 节补了一个操作性证据：一次 Terminal-Bench profile 开发 run 中，hyper-agent 连续跑了 22 小时，跨越长交互历史、上下文刷新/压缩、stop-hook 续跑，全程靠 StateM 持久记录提供当前阶段、转换历史、未决义务和恢复锚。观察到的减速来自界面上未折叠的终端输出累积，而非控制状态丢失。日尺度的开发循环、程序状态外在于易变的模型上下文——这正是 harness 该有的样子。
🔍 相关工作定位
论文与四条线对话，且很克制地声明"新颖性不在任何单一组件，而在通过 agent 原生、共同可编的执行表示把它们组合起来"：
- 规划与长程执行（τ-bench、SWE-bench Pro 等）：自然语言计划只是建议，除非运行时维护进度并检查条件；同时 Dennis et al. 2026 的证据表明过度编排反而碎化推理——StateM 正是在这个张力中找位置：更强执行控制，但不把主 agent 拆成一串窄域模型调用。
- 状态机/图编排（StateFlow、LangGraph）：已有持久状态、条件边、checkpoint、人在环恢复；StateM 不抢这些功劳，区别在于默认执行抽象——不是开发者写的控制器调用 agent，而是通用 CLI agent 当主角、控制层暴露在它的普通工具环境里。
- CLI agent 软控制（Codex、Claude Code）：计划、TODO、规则文件、记忆、钩子都很有用，但拼不成一个权威的转换感知控制面；StateM 把这些碎片组织成共享 runbook。
- harness 自适应与自改进（Agentic Harness Engineering、Life-Harness、Self-Harness、Better Harnesses Smaller Models）：harness 可优化本身不新鲜，StateM 的差异在被优化的工件——一个状态、转换条件、钩子、修复路径、历史都对执行 agent 和人类监督者直接可见的状态机 runbook，同一份表示身兼运行时控制、审计面、优化搜索空间三职。
- AgingBench（Zhu et al., 2026）：研究的是跨会话的寿命可靠性（压缩/干扰/修订/维护四种老化），与 StateM 的单任务内程序执行正交互补——revision aging 的结果恰好佐证了显式状态表示的必要性。
💬 评价与思考
亮点：
- 问题切得准且答案干净。"模型每步都会做、整活却失败"是所有跑过长程 agent 的人的共同痛点，StateM 给的答案（状态=上下文+契约边界、受检转换、选择性程序记忆）朴素但打中要害。configure-git-webserver 0/5→5/5 的案例是最有说服力的缩影：不缺能力，缺闭环。
- 迁移层级的诚实刻画。没有吹"一个 runbook 打天下"，而是如实报告：同族精确迁移成立、跨供应商精确迁移失败但适配便宜、跨任务只剩方法论。负迁移案例（RefactorBench、WooCommerce）的复盘尤其珍贵。
- 成本叙事有冲击力。\(15 摸到 88.8% 头部水平、\)52.22 包圆全部开销，"harness 投资替代模型升级"的经济学论证可能会影响一批团队的采购决策。
- 披露规范罕见地好。raw 分、两种裁决敏感口径（94.38%/93.26%）、提交 PR 编号、token 数、成本口径（流水线估算 vs 实测 API）、弃权族的处理，全部摆上台面。
需要泼的冷水：
- 95.28% 是未过评审的 raw 分。按作者自己给的最严口径是 93.26%，且 submission 成本 $1062.95 比 GPT 参考 $2059.19 便宜但仍不廉价；"约等于模型代际升级"的说法建立在参考分来自不同 agent 版本（0.125.0 vs 0.144.1）的非严格 A/B 上，作者注明了，读者也要记住。
- 成绩无法剥离 profile 内容。作者反复强调 Terminal-Bench 结果是"运行时+演化 profile"的合奏，意味着其中一部分增益其实来自针对基准分布的失败驱动调优（哪怕守住了不用隐藏测试/答案的红线），离"状态机抽象本身值多少分"这个问题仍有距离。
- 黄金法则靠人。高层架构和 golden rules（最小可复用控制、按可见语义路由而非任务 ID 路由、开发反馈与冻结评测分离）是人定的；程序记忆的"选择性"也依赖更强的 hyper-agent 或人来裁决抽象质量。harness scaling 目前更像"人机混合的半自演化"，离全自动还有距离——作者用 "Semi-Self-Evolving Agent" 标注，算诚实。
- 单 agent 边界。多 agent 角色隔离、权限设计只停留在讨论；22 小时运行也暴露 UI 层面的工程债。
一句话总结：StateM 把"经验教训"从复盘文档里的死文字变成可执行、可审计、可版本化的状态机控制层，用一次实验证明了一个可能被低估的命题——在当前这一代模型上，瓶颈常常不在模型，而在它周围那圈没人认真对待的执行系统。harness scaling 能不能成为与 model scaling 并列的能力轴，要看更多独立复现，但这篇论文至少把这个轴的存在性立住了。