StateM：以持久化状态为中心的 Agent 原生 Runtime

  • 关联论文：2608.15089
  • 作者：Tom
  • 更新：2026-08-26

一句话结论

StateM 提出了一个以 durable states、phase-local 上下文、受检跃迁、可恢复 runbook 和版本化流程实践为核心的 agent-native runtime，使 Agent 与用户能共同检视执行过程、在不改模型权重的前提下通过 harness scaling 改善执行系统——在 Terminal-Bench 2.1 上用 GPT-5.6 Sol xhigh 达到 95.3% raw accuracy，最终 API 成本约 \$15 vs GPT 参考方案的 \$574.68。

解决什么真问题

长程 Agent 经常在底层模型能解决各子步骤的情况下仍然失败，根源在于执行系统层面的系统性缺陷：

  1. 状态丢失：无法追踪可变更状态（mutable state），导致跨步骤上下文断裂
  2. 经验遗忘：无法从早期执行中复用学到的方法论（lessons from earlier executions）
  3. 步骤跳过：跳过已知必要程序，直接跳到"结论"
  4. 过早终止：任务未完成就停止执行

StateM 的核心洞察是：这些问题不需要改模型权重来解决——可以通过 harness scaling 改善执行系统本身。这是对主流"模型能力决定一切"范式的直接挑战。

核心方法

StateM 的运行时设计围绕以下核心抽象组织：

Durable States（持久化状态）

与传统的 ephemeral 上下文不同，StateM 的状态是 durable 的——可以跨执行会话保留，并在事后被检查和回放。这解决了"状态丢失"问题。

StateM State Model:
    durable_state: 跨会话保持的全局状态
    phase_local_context: 每个阶段的局部上下文
    checked_transitions: 必须通过前置条件检查才能跃迁
    recoverable_runbooks: 可回放的执行手册
    versioned_procedures: 版本化的流程（agent 和用户可共同检视）

Phase-Local Context（阶段局部上下文）

每个执行阶段维护自己的局部上下文，阶段之间通过显式的 checked transitions 连接。这防止了跳过已知程序的问题。

Recoverable Runbooks（可恢复执行手册）

将 postmortem 发现（任务失败后的复盘）转化为可执行的前置条件（preconditions）和实践（practices），通过 stateful controls 强制执行。

关键公式/机制

Harness Scaling 原则：不更新模型权重，而是通过以下方式 scaling the execution system： - 丰富 runbook 库（更多执行模式被编码为可复用手册） - 扩展 golden rules（全局必须遵守的执行约束） - 深化 state 检查点（更细粒度的状态追踪）

Terminal-Bench 2.1 结果（GPT-5.6 Sol xhigh）：
    raw accuracy: 95.3% (across 445 trials)
    tasks solved at least once: 89/89 (100%)

API 成本对比：
    StateM final-score: ~$15
    GPT reference: $574.68
    DeepSeek-V4 total: $52.22 (DeepSeek-V4 Flash $38 adaptation + $14.22 runs)

迁移性：同一 runbook 结构和 golden rules 迁移到 GPT-5.6 Luna，将 76.7% → 85.4%（高于 84.9% Sol xhigh 参考）。

关键实验与数据

Terminal-Bench 2.1 主要结果

模型 + 配置 Raw Accuracy
GPT-5.5 xhigh + StateM 92.1%（参考 83.1%）
GPT-5.6 Sol Ultra + StateM 91.9%
GPT-5.6 Sol xhigh + StateM 95.3%（445 trials）
GPT-5.6 Luna + StateM（frozen profile） 85.4%（参考 76.7%，高于 Sol xhigh 84.9%）

DeepSeek-V4 适应成本

配置 分数 成本
DeepSeek-V4 Flash 基线 82.7% —
+ $38 adaptation 88.1% $38
+ $14.22 延迟敏感任务扩展 89.1%（88-task common core） +$14.22
达到 GPT-5.6 Sol max 88.8% 水平 — 总 $52.22
GPT-5.6 Sol max 参考 88.8% $574.68

⚠️ 成本数字均基于原文自报，未独立核验 API 价格数据。

BusinessBench 结果

  • Family-specific runbooks 在 held-out 测试集上：macro +0.55，micro +1.34
  • Mechanism-matched families：+10.04 points（说明当任务共享执行结构时，具体规则有强泛化性）

亮点与局限

亮点： - 挑战"模型即一切"范式：证明执行系统层面的改进（harness scaling）可以在不换模型的前提下大幅提升性能 - 成本数据极具冲击力：$15 vs $574.68 的对比，对生产部署决策有直接参考价值 - 跨模型迁移性：runbook 从 GPT-5.5 → GPT-5.6 迁移时无需重新设计，说明框架具有模型无关性 - 经验固化机制：将 postmortem 发现转化为可执行的前置条件，这是一个从"失败中学习"到"系统化预防"的完整闭环

局限： - Terminal-Bench 2.1 和 BusinessBench 的公开可用性未明确（GitHub: henryqin1997/statem） - $15 vs $574.68 成本数字为单次运行估算，实际生产环境因并发、重试等可能有差异（⚠️ 原文未明确计算口径） - Runbook 设计需要人工 postmortem 参与，scaling 成本未讨论 - 原文未报告 frozen profile 的具体构建过程 - Terminal-Bench 2.1 的任务难度分布未分析

对工程落地的启发

  1. Harness scaling > 模型更换：当 agent 性能遇到瓶颈时，先评估执行系统（状态管理、上下文组织、跃迁检查）再考虑换模型——成本收益比往往更优。
  2. Deducible runbook 是核心资产：每次任务复盘的发现应被编码为可复用 runbook，这是组织知识积累的机制，而非随任务结束丢失。
  3. 成本可量化才能优化：StateM 将 API 成本作为一等指标（$15 vs $574.68），这应该成为所有 production agent 系统的标准实践。
  4. Frozen profile 的迁移价值：当需要在多个模型间切换时，frozen profile 是保持性能连续性的机制。
  5. Checked transitions 防止步骤跳过：phase boundary 的显式检查点可以有效防止 agent"跳步"的冲动。

与同方向工作的关系

  • 与 HarnessRisk（2608.17597）：同为同年8月的 harness 研究，但 StateM 关注执行可靠性，HarnessRisk 关注安全——StateM 的 State Persistence 阶段恰好是 HarnessRisk 的覆盖范围
  • 与 Agent Lightning v1.0（2608.17528）：两者都研究 harness scaling，但 Agent Lightning 聚焦 RL 训练框架，StateM 聚焦运行时状态管理；可构成"RL 优化 + 状态管理"的双支柱
  • 与 Compaction Cliff（2607.22752）：两者都研究长程 Agent 的状态管理挑战；Compaction Cliff 揭示了上下文压缩时安全规则丢失问题，StateM 通过 durable states + recoverable runbooks 提供了正向解决方案
  • 与 Terminal-Bench 系列：Terminal-Bench 2.1 是评估对象，StateM 证明了 benchmark 成绩可以通过 harness engineering 提升，而非只能靠模型能力

适合谁读

  • Agent 系统工程师：需要设计 production-ready agent runtime，希望理解状态管理、runbook 复用等核心抽象
  • AI Engineering 团队负责人：关注 cost-per-task 优化，StateM 的 $15 vs $574.68 对比极具参考价值
  • ML Platform 工程师：Frozen profile 迁移机制对 multi-model deployment 有直接借鉴意义
  • Agent 评估研究者：Terminal-Bench 2.1 作为 benchmark 的使用方法，以及 harness scaling 对 benchmark 成绩的影响分析

工程落地与核查（Jay）

实际系统怎么用

StateM 的核心价值在于 不改模型、不改 harness 接口的前提下提升 agent 执行可靠性。工程团队落地时有两层路径：

路径 A（推荐）：直接复用 StateM 框架 - 仓库：henryqin1997/statem（⚠️ 需 fetch 验证可用性，原文未明确说明是否已开源） - 适合场景：Terminal 类 CLI agent 任务（如 SWE-bench 类开发任务、运维自动化） - 接入成本：不需要改现有 harness，只需要在 harness 外层包裹 StateM 的 durable state + runbook 层

路径 B：参考设计、自行实现 - durable states → 可用 Redis 或 PostgreSQL JSON 列实现跨会话状态持久化 - phase-local context → 每个 phase 对应一个 context manager，退出时做显式 checkpoint - checked transitions → 每个 phase boundary 变成一个 precondition 函数，通过后才允许跃迁 - runbook → 任务失败后生成 postmortem → 转化为可执行的前置条件规则，入规则库

坑位清单

坑 描述 应对
坑 1：runbook 人工成本 StateM 的 runbook 需要人工 postmortem 参与，scaling 时人工成为瓶颈 初期先用规则引擎自动生成候选 runbook，人工做 final review
坑 2：$15 vs $574.68 计算口径 ⚠️ 原文未明确 $15 的计算方式（是否含重试、并发？） 生产部署前必须复现计算脚本；建议用 LangSmith / Arize 追踪实际 API 成本
坑 3：frozen profile 构建黑盒 原文未说明 frozen profile 如何构建，GPT-5.6 Luna 迁移时实际可用性存疑 建议从 AgentScope 或 OpenHands 的 profile 机制入手逆向
坑 4：Terminal-Bench 2.1 非公开风险 原文未明确 Terminal-Bench 2.1 和 BusinessBench 是否公开可用 写工程方案前先用 gh repo ls henryqin1997 或 web search 确认开源状态
坑 5：phase 划分依赖人工设计 哪些边界算 phase boundary 需要领域知识，无通用自动方法 从"已知失败模式"最多的环节优先画 phase（如代码执行前、测试运行后）

核查结论

  • GitHub 可用性：⚠️ 存疑，原文未明确，henryqin1997/statem 需独立 fetch 验证
  • 成本数字：$15 vs $574.68 未附计算脚本，生产环境直接引用有风险
  • BusinessBench 公开性：未明确
  • frozen profile 方法论：原文未公开，属于黑盒迁移