StateM

自动研究时间：2026-08-19 09:02（Asia/Shanghai）
来源日期：Hugging Face Daily Papers 页面实际显示 Aug 18，列表最顶部为 StateM: Reaching 95.3% Raw Accuracy, or a $15 Frontier Run, on Terminal-Bench 2.1 via Harness Scaling。
研究路径：Daily Papers 列表 -> Hugging Face 详情页 -> arXiv 摘要页 -> arXiv v1 PDF 与完整 TeX 源码 -> 官方项目页、代码仓库及公开评测说明。

执行摘要

长程智能体常出现一种很有诊断价值的失败：模型会做每个局部步骤，最终任务却没有完成。计划被长命令轨迹稀释，当前状态只能从追加式历史中重建，之前总结的教训没有在风险再次出现时被激活，或者智能体在测试、外部验证和最终状态尚未闭合时就宣布完成。StateM 的核心判断是：这不全是模型能力问题，也可能是承载模型执行的 harness 没有把“现在处于哪一步、离开这一步需要什么证据、失败后如何恢复”变成持久且可执行的控制。

StateM 因而把开放式 CLI 智能体包在一个轻量状态机运行时中。人类可读的 YAML runbook 定义粗粒度阶段、合法边、进入与退出 hook、检查、修复路径和终止状态；每次运行另存当前状态、转移历史、检查结果和证据引用。智能体仍可在一个阶段内自由推理和调用工具，但跨阶段的 goto 必须经过检查、持久化和记录。作者将这种在不修改模型权重的前提下扩展执行系统的路线称为 harness scaling。

论文在 Terminal-Bench 2.1 上报告了显著提升：GPT-5.5 xhigh 加 StateM 为 92.1%，公开参考为 83.1%；用 GPT-5.5 开发并冻结的 runbook 不经目标模型调参，配合 GPT-5.6 Sol xhigh 得到 424/445，即 95.28% raw accuracy。同一 profile 还把 GPT-5.6 Luna 从 76.7% 提至 85.4%。跨提供商时，原样移植 GPT profile 反而使 DeepSeek-V4-Flash 从 82.7% 降至 82.0%；在保留 runtime、runbook 结构与开发原则并做 37.02 美元适配后，标准超时成绩达到 88.09%，最终计分证据的实际 API 支出为 15.20 美元。

这些数字不能脱离评测边界。95.28% 是尚未进入正式榜单的公开提交原始分，论文承认 4 条有奖励问题的轨迹应改判为零，此时为 94.38%；若把当前 9 条被标记轨迹全部计零，则为 93.26%。GPT 参考并非同一 agent 版本下重新跑出的严格 A/B 对照，StateM 结果也没有将通用 runtime 与经过 benchmark 反馈演化的 profile 分离。15.20 美元是 DeepSeek 最终评测的实际 API 账单，不能与 GPT 提交管线给出的 API-equivalent model cost 混作同一种成本。

论文真正有长期价值的结论因此不是“状态机让任何模型都达到 95.3%”，而是更窄也更可操作的一点：模型能力与执行可靠性是两条不同的扩展轴；持久状态、证据化转移和经过筛选的程序性记忆，能让已有能力更稳定地变成完成的工作，但具体规则只会在执行机制相似时迁移。

1. 论文基本信息

核心链接：

• Hugging Face 详情页：https://huggingface.co/papers/2608.15089
• arXiv 摘要页：https://arxiv.org/abs/2608.15089
• arXiv PDF：https://arxiv.org/pdf/2608.15089
• arXiv TeX 源码：https://export.arxiv.org/e-print/2608.15089
• 官方项目页：https://henryqin1997.github.io/statem/
• 官方代码仓库：https://github.com/henryqin1997/statem
• Terminal-Bench 2.1 公开提交 PR：https://github.com/harbor-framework/terminal-bench-2-1/pull/142

2. 背景与动机：会做步骤，为什么仍然做不完任务

2.1 计划在长轨迹中只是“软建议”

通用 CLI 智能体往往先生成计划，再进入几十乃至几百次命令、观察、重试和修复。计划很短、抽象层级很高，执行轨迹却持续增长。如果运行时没有把当前阶段和完成条件重新放到注意力前沿，智能体需要从混杂历史中不断恢复“为什么在做这一步”，容易漏掉原始约束或把局部成功误当成整体完成。

论文将这种现象称为 control-signal dilution。作者谨慎地把它视为运行假设，而不是关于 Transformer 注意力的基础定理。StateM 的应对不是清空全部上下文，而是在进入每个阶段时刷新阶段相关说明、持久进度和未完成义务，让控制信号再次靠近当前决策点。

2.2 追加式历史不是权威的当前状态

复杂任务包含分支、循环和失败重试。同一事项会在历史中留下“准备做、做了一半、失败、修复、重新验证”等多个版本。若没有可覆盖更新的状态记录，智能体只能从日志推断哪个版本仍然有效，容易重复动作、漏掉依赖或恢复到错误位置。论文把这称为 mutable-state ambiguity。

StateM 将当前节点、state-entry ID、合法转移、检查结果、时间戳和证据引用保存在模型上下文之外。进程重启、上下文压缩或会话刷新后，智能体可查询权威状态，而不必只靠终端 transcript 重建现场。

2.3 三类缺口需要三种不同控制

论文把“为什么没有做对”拆成三个层次：

这个分类很重要。给合规缺口追加更多知识没有用；把所有失败都写进永久记忆，也会产生规则膨胀和错误抽象。StateM 试图在“知识何时出现、经验如何跨运行保留、程序是否真的完成”三个位置分别介入。

2.4 自主性与可执行控制之间的空档

传统工作流图和状态机擅长持久状态、条件路由、检查点和恢复，但常由开发者预先把任务拆成节点，模型只在节点内被调用。通用 CLI 智能体则保留很大的工具与推理自由度，不过计划、TODO、规则文件和自检通常是模型中介的软约束。

StateM 选择中间位置：不把主智能体拆成大量窄节点，只对粗粒度阶段间的转移施加强制；runbook 同时对智能体和用户可见、可审计，并由 host runtime 保护关键不变量。它更适合“短任务用规则文件就够、固定业务用硬编码工作流更合适”之间的开放式长任务。

3. 核心贡献

3.1 提出与 model scaling 正交的 harness scaling

模型扩展提高“能否推理出某一步”，harness scaling 关注“已有能力能否持续、可恢复、可验证地完成整个工作”。论文用四种证据把这条轴具体化：固定模型提升、同模型家族冻结迁移、跨提供商适配迁移，以及跨任务家族的 held-out 泛化。

这比单纯说“prompt 很重要”更强，因为优化对象不仅有文字提示，还包括状态边界、hook、检查、路由、恢复和 practice 激活条件；也比宣称“harness 可以通用迁移”更克制，因为实验明确展示了迁移层次随模型与任务距离而变化。

3.2 将状态定义为 context-and-contract boundary

每个 state 同时承担两种角色：

1. Context boundary：进入节点时加载当前阶段的说明、事实和持久进度；
2. Contract boundary：离开节点前检查必须满足的条件，失败则不提交转移。

这将“提醒智能体下一步做什么”和“阻止不完整结果进入下一步”统一在同一抽象中。前者改善注意力与恢复，后者才提供真正的运行时控制点。

3.3 保留单一通用智能体的推理回路

StateM 不要求把任务改写成一串彼此独立的 model call。智能体在 plan、execute、review 等阶段内部仍可自由选择工具、修改方案和迭代。状态图只规定粗粒度合法路径与交接条件，从而减少重编排造成的上下文碎片和路由错误。

3.4 将失败复盘变成版本化程序性记忆

一次失败可经过“观察轨迹与证据 -> 抽象控制层原因 -> 修改 runbook -> 回归与 held-out 评估”变成 practice。practice 可以是阶段提示、检查、约束、激活条件或验证动作。与把 postmortem 写进普通记忆文件相比，它不仅可读，还能在相关边界被执行。

论文强调 practice 必须经过筛选。真正的目标不是记住每条失败，而是记住会在未来造成不可逆后果的边界；错误、过宽或来自评测器隐含偏好的教训也必须能被修订或删除。

3.5 给出迁移层次，而不是二元“可迁移”结论

实验支持的层次是：

• 邻近 GPT 代际之间，具体 states、路由、checks 与 repair 结构可以冻结迁移；
• 跨模型提供商时，具体 profile 不能直接复用，但 runtime、runbook 结构、适用控制、golden rules 与失败分析循环仍可复用；
• 跨任务分布时，最可迁移的是识别并保护“后果性执行边界”的方法，具体规则需要按 family 重建。

4. 方法：StateM 如何把开放式执行装进可恢复控制层

4.1 Runtime 与 control profile 分层

StateM 将系统拆为两层：

• Runtime 提供状态持久化、转移验证、hook 执行、历史记录与恢复等通用机制；
• Control profile 由 runbook 表达，定义某类工作的阶段、提示、检查、路由和修复策略。

这一区分也决定了如何解读实验：论文评估的是基础模型、StateM runtime 和特定 profile 的组合。Terminal-Bench profile 已通过失败反馈演化，不能把全部增益归因于“用了状态机”。

一个 runbook 可形式化为：

其中 $\mathcal{S}$ 是粗粒度状态集合，$s_0$ 是初始状态，$\mathcal{S}_T$ 是终止状态，$\mathcal{E}$ 是允许的有向边，$\Phi(s)$ 包含节点提示、进入/退出 hook、转移检查和本地证据引用。

4.2 一次 goto 的有序协议

当智能体请求 goto TARGET 时，runtime 依次执行：

1. 验证当前 state 到目标 state 的边是否存在；
2. 执行当前 state 的 before_transfer 检查；
3. 运行持久化操作或 out_hook；
4. 检查 edge guard 与 edge-specific hook；
5. 仅在必要步骤成功后提交目标 state，并把事件追加到 history；
6. 创建新的 state-entry，执行目标 state 的 in_hook。

前置检查失败时，运行仍停留在原节点，失败被记录，智能体可修复后重试。论文将它称为 checked, logged, recoverable，而非 fully transactional：StateM 可以推迟内部状态提交，却不能普遍回滚 hook 已经写入外部系统的副作用。外部操作仍应尽量幂等，并提供显式补偿或重试设计。

4.3 检查有不同证据强度

因此，StateM 让声明变得可见和可审计，但不会因为它被写进 receipt 就自动成为事实。对关键不变量，应优先使用外部可复现检查或人工决定。

4.4 每次运行有独立持久状态

runbook 是可复用控制逻辑，每次 execution 则保存独立的 run ID、当前节点、entry ID、转移历史、hook 与 check 结果、时间戳和证据文件引用。多个智能体或并行运行可以共享 profile，而不混淆各自进度。

恢复也有明确边界：StateM 能恢复已经记录的控制状态并重跑配置的 recovery step，不能找回从未持久化的工作、隐藏的模型上下文，也不能自动撤销任意外部动作。可靠恢复仍依赖合理的持久化边界与可重入 hook。

4.5 共享控制不等于允许智能体削弱约束

智能体可在 policy 允许时追加 run-local dynamic checks，并把新风险记录到历史，供人类决定是否提升为下一版本的通用规则。但追加更严格的检查与删除用户不变量不是同一权限。关键权限、blocking check 和 host-owned policy 不能仅靠“YAML 可编辑”保护，部署端必须限制智能体可修改的字段和文件。

StateM 还可接入 Codex 或 Claude Code 的 stop hook。若运行尚未进入终止节点，也没有明确等待外部依赖，hook 会返回当前阶段与未完成义务并请求继续。这能减少过早停止，却不保证最终成功；模型、环境、时间或预算耗尽时仍需要重试上限和真实 blocker 语义。

5. 实验设计与证据边界

5.1 Terminal-Bench 2.1

Terminal-Bench 2.1 包含 89 个真实命令行任务，每题运行 5 次，完整评测共 445 条 trial。论文主要报告 trial-level success rate，并将“5 次中至少成功一次的任务数”称为 five-trial task coverage。这个 coverage 衡量观察到的五次覆盖，不等于单次运行可靠率，也不能直接解读为 Pass@5 的独立采样概率估计。

Terminal-Bench profile 先用 GPT-5.5 开发，然后在 GPT-5.6 Sol 与 Luna 上冻结。冻结意味着不依据目标模型的评测结果修改 prompt、state、routing、check catalog、默认值或 repair policy；它不意味着目标模型评测不花成本，也不排除 frozen policy 根据任务可见信息在单次 run 内实例化动态检查。

profile 构建允许使用可见任务描述、workspace、公开文档和可观察执行反馈，不允许读取隐藏测试、verifier 实现、公开答案、answer artifact、task hash，或以人工枚举的 task ID 作为路由键。人类给出三条 golden rules：偏好最小可复用控制、按可见任务语义路由、分离开发反馈与冻结评测。

5.2 BusinessBench

BusinessBench 用 GPT-5.6 Luna 测试 task-family 级泛化。每个被处理的 family 单独在 development instances 上演化 profile，并在首次 held-out 评测前冻结。GPT-5.6 Luna task agents 生成候选经验，GPT-5.6 Sol xhigh hyper-agent 评估 family-level 通用性与兼容性。

基准共有 477 个 eligible instances、7 个 families；Attendance Payroll 因没有合适的 StateM workflow 而 abstain，72 个 treatment-arm run 不计入疗效汇总。真正接受 StateM 处理的是 405 个 instances、6 个 families，共 810 次 treatment/control execution。每个 instance 每个 arm 只有一条随机轨迹，后续依据总体反馈做的改进被单独标为 post-evaluation diagnostic validation。

5.3 成本口径

论文区分三种不应混合的成本：

• DeepSeek final-evaluation expenditure：生成最终计分证据的实际 API 费用；
• DeepSeek adaptation expenditure：提供商专用 profile 开发迭代的所有记录费用；
• GPT public submission 的 model cost：提交管线估算的 API-equivalent 成本，并不等于作者在 Codex Pro 套餐下的实际支出。

论文附录还说明主要研发资源是个人 Codex Pro 与 2025 款 M4 MacBook Pro，正式提交使用 AWS m7i.4xlarge；整个个人研究工作的实际使用低于 125 美元。但这个项目预算同样不能替代可复现的算力、时间和人工成本核算。

6. 核心实验结果

6.1 固定模型：harness 增益大于所比较的代际差

GPT-5.5 的 +9.0 点与 GPT-5.6 Sol 的 +10.38 点，明显大于参考 harness 下 GPT-5.5 到 GPT-5.6 Sol 的 +1.8 点。论文据此说 harness 增益在此设置下近似一次 model-generation upgrade。

但这不是同一实验矩阵内的严格因果分解。GPT-5.5 参考来自 Codex agent 0.125.0 的公开结果，不是作者用完全相同 agent 版本、基础设施和随机条件重新运行的 A/B control；不同参考行还可能来自不同高算力配置。最稳妥的结论是“系统级差异很大，值得把 harness 当成主要变量”，而不是“状态机单独贡献了精确 9.0 点”。

6.2 95.28% 的裁决敏感性

GPT-5.6 Sol xhigh + StateM 的公开提交包含 445 trials、439 次无错误完成、6 次 AgentTimeoutError、11.78 亿 tokens，管线估算 model cost 为 1,062.95 美元，并通过 10 项静态与配置检查。截至论文记录时间，PR 仍未合并到正式 leaderboard。

作者给出三档口径：

即使使用最保守的第三档，成绩仍高于 84.9% 参考；但论文标题中的 95.3% 只能称为 raw、pre-adjudication result，不能当作最终官方榜单成绩。

6.3 同一 GPT 家族可冻结迁移，跨提供商则需要适配

用 GPT-5.5 开发的完整 profile 在 GPT-5.6 Sol 与 Luna 上不修改控制逻辑，仍分别带来 +10.4 与 +8.7 点。这说明邻近模型可能共享重复出现的执行故障，具体 states、激活策略、checks 和 repair 结构可作为权重外的可移植程序知识。

然而，把同一 frozen GPT profile 直接用于 DeepSeek-V4-Flash，会把 82.7% baseline 降到 82.0%。这条负结果非常关键：StateM 没有消除基础模型的提供商特性，过度具体的规则会在新模型上形成负担。

在保留通用 runtime、高层 runbook 结构、仍适用的 controls、failure-analysis loop 与 golden rules 后，作者用 37.02 美元进行提供商专用适配，结果为：

88.76% 四舍五入后等于另行报告的 GPT-5.6 Sol max 88.8%，但两者运行条件不同。标准超时下可复现的主结果仍应是 88.09%，不能用替换一题超时条件后的 descriptive aggregate 覆盖它。

6.4 15 美元成本前沿究竟指什么

完整 DeepSeek 最终计分证据的实际 API 费用是 15.20 美元；适配花费 37.02 美元；两者总计 52.22 美元。论文将 15.20 美元与一个公开 GPT submission 的 574.68 美元 model cost 比较，前者为后者的 2.65%，约低 37.8 倍；全套适配加评测则约为其 1/11。

需要同时保留两个限定：第一，574.68 美元对应的公开提交原始成绩是 83.37%，不是单独报告的 88.8% Sol max，论文只把 88.8% 当 score-only reference；第二，DeepSeek 是实际账单，GPT 是提交记录中的 model-cost 数值。这个比较说明价格曲线可能被 harness 显著移动，但不是严格的同平台、同计费、同超时成本实验。

6.5 任务级提升集中在“交接前最后一公里”

论文列出的代表性变化包括：

configure-git-webserver 最能说明机制。baseline 已会配置 Git、SSH、hook 和 HTTP server，却不能稳定保持最终 live state。StateM 要求在离开 verification 前用新的 clone、commit、push、curl 链路从消费者视角闭环；验证若扰动环境，任务仍停留在可修复状态。这里新增的不是组件知识，而是把已有能力组合成不可跳过的完成证据。

6.6 BusinessBench：总增益温和，机制匹配时才明显

首次冻结、未触碰 held-out 的汇总结果为：

最大的两个 family 提升来自执行机制匹配：Budget Approval 从 62.91% 到 75.12%，受益于精确小数、政策对账和 mandatory-effect closure；Machine Operating 从 90.79% 到 100%，受益于 query planning、data-plane execution、区间覆盖和 durable publication。

负迁移同样存在：RefactorBench 从 80.56% 降到 77.78%，WooCommerce Stock 从 92.59% 降到 88.89%。前者的初始 profile 过度强调最小修改与向后兼容，却没有闭合明确的 API migration obligation；后者堆了很多流程，却漏掉库存实体、按目的地去重、不可逆邮件动作和 receipt 之间的跨系统 invariant。事后使用更薄、更匹配边界的 profile，matched rerun 才分别有所恢复。

这支持论文最重要的 task-side 结论：泛化跟随控制机制是否匹配，而不是任务表面是否多样。 Attendance abstain、WebTest 接近饱和、WebArena 只需要很轻的 query-state control，也说明“更多控制”不是默认答案。

6.7 22 小时运行证明的是持久执行，不是无限自治

一次 Terminal-Bench profile 开发中，hyper-agent 连续运行 22 小时，经历长交互历史、上下文刷新或压缩以及 stop-hook continuation。StateM 的持久记录一直保留当前阶段、转移历史、未解决义务和恢复锚点。作者观察到的减速来自界面中未折叠的累积终端输出，而非 StateM 状态丢失。

这是一条 day-scale operational endurance 证据，不代表无限运行，也不证明面对任意故障都能自动恢复。预算耗尽、外部依赖、错误检查和无效修复循环仍然存在。

7. 局限与批判性分析

7.1 没有隔离 runtime 与 profile 的贡献

StateM 的成绩来自通用 runtime 加演化后的 benchmark-aware profile。论文没有提供“相同提示与 practices，仅去掉状态持久化”“只保留 checks”“只保留 state-local context”等组件消融，也没有以同一模型、agent 版本和基础设施重跑所有 reference。因此，现有证据证明组合系统有效，不能回答每一项机制各贡献多少。

7.2 公开 raw score 尚未完成裁决

95.28% 的提交 PR 未进入正式榜单，且存在 reward hacking 审查。作者主动给出 94.38% 和 93.26% 的敏感性结果是优点，但也意味着标题数字不是稳定终值。后续若 PR 裁决变化，应以公开提交记录和官方 leaderboard 为准。

7.3 Harness 优化可能学习评测器而非任务合同

即使没有读取隐藏测试或 verifier，反复观察失败反馈仍可能把评测器未写入题面的偏好固化进 memory。论文举出两个例子：视频任务中对目标帧精度的默认值，以及 DNA insertion verifier 偏好最左有效边界。这样的 practice 能提高 benchmark 分数，却不一定是现实任务的通用规范。

因此 failure-driven optimization 必须区分“来自公开合同的不变量”和“事后迎合 evaluator 的惯例”，并把后者标记为局部、可撤销假设。

7.4 规则会负迁移，也会制造控制开销

DeepSeek 的 82.7% -> 82.0%，以及 BusinessBench 两个 family 的首轮下降，证明 profile 不是免费增益。过宽 procedure 会消耗时间和上下文，错误边界会让智能体验证无关事项，甚至错过真正的 completion contract。一个成熟系统需要对 practice 做版本回归、按可见语义稀疏激活，并允许 abstain 或删除规则。

7.5 检查不等于正确性 oracle

checklist 是自我声明，llm_review 仍会出错，command 只验证命令覆盖的性质。StateM 可以阻止已配置条件被无声跳过，却发现不了 runbook 和智能体都没有想到的要求。对安全、资金、生产部署等高风险任务，外部独立验证、最小权限和人工审批仍不可替代。

7.6 外部副作用缺少事务回滚与安全边界

goto 对内部状态采用先检查后提交，但 hook 对文件、服务和远程系统的修改不能自动 ACID rollback。恶意或错误 hook 还会继承 host 权限。论文明确将 sandbox、permission control、幂等操作和补偿逻辑留给部署环境；这意味着 StateM 是控制 substrate，不是安全 sandbox。

7.7 BusinessBench 的泛化证据仍有限

首次 held-out 的 macro 增益只有 0.55 点，micro 为 1.34 点；每个 instance 每个 arm 只有一次随机 trajectory，family 大小也不相等。+10.04 点来自事后聚焦的两个 mechanism-matched family，应视为探索性 subgroup。后续 refinement 使用过 aggregate evaluation feedback，不能与未触碰 held-out 的首轮证据混在一起。

7.8 成本比较不是统一会计实验

15.20 美元只覆盖最终 DeepSeek 证据，不含 37.02 美元适配、人工抽象、hyper-agent 审核、基础设施和 framework 研发。GPT 数字又多为 API-equivalent model cost。论文已披露差异，但传播时很容易被压缩成“15 美元击败 575 美元”；工程决策应重新测量自己的 token、wall time、人工维护与失败恢复成本。

8. 应用影响与工程启示

8.1 软件工程智能体

最直接用途是把 coding agent 的 plan -> execute -> review -> handoff 变成持久 runbook。真正有价值的门禁不是“自称测试过”，而是从仓库规则派生的可执行证据：变更范围、构建或测试结果、消费者路径验证、分支与远端状态，以及明确的 blocker。中断后可从 state 与 receipts 恢复，而不是重新阅读整段 terminal history。

但 profile 应薄且仓库特定。RefactorBench 的负迁移表明，通用“兼容性检查大全”可能不如从当前 API migration contract 派生的一次 stale-reference closure。

8.2 长流程业务自动化

审批、库存同步、报表发布和多系统写入都具有“中间结果正确但最终 effect 未闭合”的风险。StateM 可保存 task-derived effect manifest，对 attempted、succeeded、failed 与 fresh-read observed effects 对账，并在不可逆动作前要求人工或 host 证据。

对重复业务，应优先使用固定工作流引擎；StateM 的优势在于业务目标开放、执行路径需由通用智能体动态选择，但关键交接点仍可枚举的中间地带。

8.3 低成本模型部署

DeepSeek 实验提示一种新的预算分配：不只购买更强模型，也投资于失败诊断、状态持久化和最小控制 profile。若任务频繁重复，适配成本可以在多次运行中摊薄；若每个任务完全不同，维护 profile 可能得不偿失。

部署前应做三组独立实验：裸模型基线、冻结 profile 迁移、允许固定预算适配。只有这样才能区分便宜模型本身的能力、旧规则的负迁移和新 harness 的真实收益。

8.4 人机共同审计

runbook、history、failed checks 和 receipts 形成共享控制面，比在聊天记录中追加一句“请再检查”更容易审计。人可以冻结不可修改的不变量，把语义判断留给人工，把可重放检查交给 runtime，并从多次失败中选择哪些 practice 值得提升为版本化规则。

8.5 多智能体扩展仍是未来工作

论文主体只研究单一 autonomous agent。角色隔离的 planner、executor、reviewer 可以提供不同上下文与权限边界，但也引入状态共享、冲突解决和协调成本。StateM 的 state/context/permission 分离为此提供接口方向，却没有用本论文实验验证多智能体收益。

9. 相关工作与论文位置

与 StateFlow 或 LangGraph 相比，StateM 的新意不在单个机制，而在默认控制权：传统 graph 多由开发者持有，模型在节点内执行；StateM 把状态机作为智能体普通 CLI 环境中的共享工件，智能体可查看状态、请求转移、诊断失败并在权限允许时提出修改，人类则在同一工件上审计与冻结不变量。

与 Self-Harness 等演化路线相比，它也不只搜索 prompt。一次失败可以改变转移时检查、恢复路径和阶段上下文。但这种更大的搜索空间同样增加了错误抽象与 benchmark overfitting 风险，所以论文把“选择什么值得成为持久 memory”视为核心难题。

相关论文链接：

• StateFlow：https://arxiv.org/abs/2403.11322
• Agentic Harness Engineering：https://arxiv.org/abs/2604.25850
• In-Context Prompting Obsoletes Agent Orchestration for Procedural Tasks：https://arxiv.org/abs/2604.27891
• From Model Scaling to System Scaling：https://arxiv.org/abs/2605.26112
• Life-Harness：https://arxiv.org/abs/2605.22166
• Your Agents Are Aging Too：https://arxiv.org/abs/2605.26302
• Self-Harness：https://arxiv.org/abs/2606.09498

10. 复现与采用建议

10.1 复现实验时分开三个对象

复现者应分别固定：基础 agent 与模型、StateM runtime 版本、control profile 版本。若三者一起变化，无法判断提升来自模型更新、runtime bug fix 还是新增 practice。每次 trial 还应记录超时、token、实际账单、host 类型、动态检查和外部人工介入。

10.2 先从一个后果性边界开始

不必把整个流程一次性状态机化。可先选择最常导致不可逆失败的一个交接点，例如“部署后必须由新客户端访问”“批量写入后必须 fresh-read 对账”“数据库恢复前必须复制原文件”。为它设计一个可重放检查，再观察增益与开销。

10.3 为 profile 做迁移矩阵

至少报告以下四格：同模型同任务、同家族新模型、跨提供商同任务、同模型新 task family。StateM 论文显示，这四格的 transferable object 不相同。把某次 benchmark profile 宣称为通用最佳实践，会掩盖最值得监控的负迁移。

10.4 把记忆提升视为代码审查

任何从失败轨迹抽象出的 practice，都应附带来源、适用条件、反例、预期证据与回滚方式。只有通过开发集回归和 untouched held-out 检查后，才从 run-local rule 提升到 base runbook。来自 evaluator 暗示而非公开合同的约定，应明确标记为 benchmark-local。

11. 总结

StateM 把一个常被归咎于“模型还不够强”的问题重新表述为系统工程问题：长程智能体不仅需要推理，还需要一个模型上下文之外的权威执行状态，需要在高风险交接前提供证据，也需要把跨运行经验筛选成可执行而非无限累积的程序记忆。

Terminal-Bench 2.1 的固定模型提升和 GPT 代际冻结迁移说明，这条路线可能释放大量已有模型能力；DeepSeek 的先降后升说明具体控制不会无条件跨提供商迁移；BusinessBench 的小幅总体提升、两个强匹配 family 和两个负迁移 family，则把原则进一步收紧到“控制必须对准真正的执行边界”。

因此，这篇论文最值得带走的不是 95.3% 或 15 美元这两个标题数字，而是一套评估智能体系统的新问题：模型是否知道该做什么，系统是否记得现在做到哪里，之前的教训是否在正确时刻出现，以及在宣布完成之前，是否真的有独立证据证明后果已经闭合。

参考资料

1. Hugging Face Papers, “StateM: Reaching 95.3% Raw Accuracy, or a $15 Frontier Run, on Terminal-Bench 2.1 via Harness Scaling.” https://huggingface.co/papers/2608.15089
2. Qin, Z., Lu, Y., Wang, Z. A., & Wang, K. “StateM: Reaching 95.3% Raw Accuracy, or a $15 Frontier Run, on Terminal-Bench 2.1 via Harness Scaling.” arXiv:2608.15089, 2026. https://arxiv.org/abs/2608.15089
3. StateM official project page. https://henryqin1997.github.io/statem/
4. StateM source repository. https://github.com/henryqin1997/statem
5. Terminal-Bench 2.1 public submission PR #142. https://github.com/harbor-framework/terminal-bench-2-1/pull/142
6. Wu, Y. et al. “StateFlow: Enhancing LLM Task-Solving through State-Driven Workflows.” https://arxiv.org/abs/2403.11322
7. Lin, J. et al. “Agentic Harness Engineering: Observability-Driven Automatic Evolution of Coding-Agent Harnesses.” https://arxiv.org/abs/2604.25850
8. Zhu, J. et al. “Your Agents Are Aging Too: Agent Lifespan Engineering for Deployed Systems.” https://arxiv.org/abs/2605.26302
9. Zhang, H. et al. “Self-Harness: Harnesses That Improve Themselves.” https://arxiv.org/abs/2606.09498