SKILL.state: Scalable Long-Horizon Agent Skills
Sanket Badhe, Priyanka Tiwari, Jonghyun Chung
EMNLP
cs.AI, cs.MA
2026-08-27
Google提出SKILL.state：每步只喂技能说明、当前结构化状态和最新观察，推理写完即丢。Gemini-3-Flash在仓库任务200步上准确率0.94，累计12.2万token，约为Memory基线的五十分之一。
现在主流 agent runtime 把技能执行当成一场不断加长的对话。每一步把推理、动作、观察、工具输出都追加进 transcript。步数一长，prompt 按步数线性涨，累计 token 按平方烧。过期推理和旧观察还一直占着位置，模型每步都要从历史文本里把当前世界再拼一遍。
MemGPT 一类记忆系统用摘要或检索压长度，LangGraph 一类会往窗口里塞一块结构化状态，执行语义没变：下一步决策仍然主要靠对话记录。长程程序性技能真正缺的是一份足够统计量，能让历史被丢掉而不丢正确性。压缩历史，治不了「历史不该是执行载体」这件事。
SKILL.state 把每一步改写成状态转移。模型只看到三样东西：不可变的技能说明 P、当前结构化执行状态 Σt、最新观察 Ot。输出是一段当步 Chain-of-Thought、一个 JSON 状态补丁、以及要执行的动作。运行时校验补丁合法后做字典合并，键设为 null 表示删除；推理轨迹立刻丢掉，永远不再进后续 prompt。
循环很短：
状态 schema 按域写一次，不按任务写。InterCode CTF 的 100 道题共用五个字段：discoveredflags、testedhypotheses、activefiles、workingdir、cmdsummary。校验失败就回滚重试，坏 JSON 写不进持久状态。
步内推理完整保留，用来做多步演绎；跨步只活结构化状态。累计 token 因此从对话 runtime 的平方级降到线性，单步 prompt 与已经走了多少步无关。
主实验用 Gemini-3-Flash，温度 0.0，合成任务 5 个种子。对照三条主基线：完整追加的 ReAct、保留最近 3 轮加摘要的 Memory、状态块加完整 transcript 的 LangGraph 式 Stateful。T≥50 时与基线的差异通过配对 t 检验，p<0.01。
仓库管理环境跟踪 500 个独立货架，缩放到 T=200:
| 方法 | T=200 准确率 | 均 prompt | 累计 token |
| ReAct | 0.74 | 48,007 | 261 万 |
| Memory | 0.84 | 84,364 | 618 万 |
| Stateful | 0.88 | 72,305 | 504 万 |
| SKILL.state | 0.94 | 1,811 | 12.2 万 |
T=100 时相对 Stateful 累计 token 少 16.2 倍，65,408 对 1,062,387。噪声实验固定 T=50，每步塞 50 条无关遥测时 ReAct 掉到 0.53，SKILL.state 仍 0.98，因为干扰在写补丁时被滤掉，进不了下一步 prompt。外部静默改世界时，历史基线要幻觉 5 到 8 步才能跟上，SKILL.state 收到纠正观察后 0 步恢复。
公开基准同样用 Gemini-3-Flash:
| 基准 | ReAct | Memory | Stateful | SKILL.state |
| InterCode CTF pass@1 | 43.2% | 46.4% | 41.8% | 54.2% |
| τ-Bench Retail | 48.2% | 29.9% | 51.7% | 58.3% |
| τ-Bench Airline | 21.8% | 23.6% | 28.1% | 32.4% |
CTF 上比最强基线高 7.8 个点，累计 token 比 ReAct 少 60.4%(387k 对 977k)。Airline 上基线单步 prompt 能顶破 11,000，SKILL.state 钉在约 2,800，累计 2.88M，比 Stateful 的 5.28M 少 45.4%。
预算对齐把压缩基线钉在约 1,800 token：滑窗截断准确率 0.18，摘要封顶 0.52，LLMLingua 0.22，SKILL.state 0.94。短 prompt 本身不够，结构化状态保住了统计压缩会扔掉的槽位标识。
开源模型上准确率优势变小。Gemma-4-31B 仓库 T=100，SKILL.state 和 Stateful 都是 0.42，ReAct 只有 0.21。失败日志里 68% 是合并时漏写已有键，等于把状态覆盖丢了；20% 是嵌套类型弄错，12% 是 JSON 格式。软件仓库环境 T=25 时 SKILL.state 准确率 0.88，低于 Stateful 的 0.94；拉到 T=50、T=100 才反过来，0.86 对 0.74、0.78 对 0.63。短程、状态图纠缠时，丢掉 transcript 会付一点代价。
这是 runtime 抽象，不改模型权重，现有 ReAct 循环上就能换。技能框架最近热衷把流程写成可复用 skill，真正跑起来时上下文却仍按对话涨。任务能事先写好 schema 的话，显式状态比摘要、滑窗、困惑度压缩都更接近正确的执行语义。
能直接用的场景：长工单、仓库式槽位、终端循环、客服工具调用这类「当前世界能写成 JSON」的流程。省的是二次方 token，顺带少被旧推理带偏。这不是新推理算法，是把对话状态跟踪里「状态是充分统计量」的假设搬到 agent 执行上，并且真的把历史扔掉。
论文自己列了三条假设破裂点。事先不知道 schema、当时没认出某条观察的日后用处、任务目标就是历史轨迹本身，比如审计、溯源、解释做过什么。实现只覆盖单 agent，多 agent 并发写需要合并算子上的冲突语义，文中没测。
合成仓库任务几乎就是在考「记不记得 500 个货架」，对显式状态极度友好。公开基准的提升更可信，但 CTF 五字段 schema 是作者手写的，换域就要重新设计。开源小模型的瓶颈在结构化输出服从，不在推理，论文也承认要靠语法约束解码。Stateful 基线仍然带着完整 transcript，「加了状态却没丢掉历史」的对照成立；缺的是 schema 能不能自动发现，文中没做。