SKILL.state：把 Agent 从“聊天记录驱动”改造成“显式状态机驱动”

最重要的三层理解

1. 不是 Memory 技巧：它不是把历史压缩得更聪明，而是改变“下一步决策依赖什么”的执行语义。
2. 不是取消推理：单步内部仍允许复杂推理；只是推理不作为跨步持久记忆，持久化的是结构化状态。
3. 真正难点从 Context 搬到 State：系统能力取决于 Schema 是否覆盖未来决策所需信息、Patch 是否正确、状态与真实环境是否一致。

“Context poisoning” 在这篇论文里的具体含义

问题不是只有上下文太长。更危险的是：旧事实、失败假设、已经失效的观察和过时推理长期驻留在 Prompt 中。模型必须在每一步区分“历史事实”和“当前事实”，因此执行正确性越来越依赖自然语言历史的再解释。

来源：论文第 1–3 页的 Introduction 与 SKILL.state 定义。

从“推理问题”切换到“系统执行问题”

SKILL.state 与 Memory / DST / Context Compression 的边界

真正的算法核心：Reasoning → Projection → State Patch

把 Figure 1 看成“上下文数据流图”

实验的自变量不是“模型”，而是 Context Management Paradigm

最有说服力的一页：规模、噪声、恢复同时测

证明“短 Prompt”不是充分条件

整篇论文最值得反复读的一页：充分统计量假设

把论文放回研究谱系：ReAct → Memory → Long Context → Explicit State

本页主要是参考文献。学习时不要逐篇阅读，而要按四条线索建立关联：Agent loop / Tool use、Long-term memory、Long-context degradation、Context compression。SKILL.state 的位置是：不继续优化“怎么保存历史”，而是质疑“执行是否必须依赖历史”。

最适合直接复现的一页：四种 Runtime Prompt 的最小差异

Benchmark 的关键不是“难”，而是可控地暴露状态错误

把 state patch 当成“事务增量”理解

Warehouse 例子中，观察到客户订购 item_12，模型从 state 找到 shelf_42，输出 Patch 将该位置置空，同时生成 Ship item_12 shelf_42。这个例子清晰展示“观察 → 查状态 → 决策 → patch + action”的闭环。

Noise 实验测的是 Attention Drag，不是恶意 Prompt Injection

噪声被严格限定为随机、与任务无关、不会改变 ground-truth state 的背景 telemetry，例如机器人电量、温湿度、Camera OCR、远端服务器 CPU/RAM。作者明确说这部分专注 Condition 1：Irrelevant Context。

因此不能把表 2 / 表 9 的结果外推成“对 prompt injection、恶意 rule override 或可信输入冲突也同样鲁棒”。

关系图状态比独立槽位更难，但趋势仍成立

T=100：Prompt 0.53 / 1.8485M tokens；Memory 0.57 / 2.7527M；Stateful 0.63 / 2.308M；SKILL.state 0.78 / 90.2k。说明当状态存在 PR、branch、CI 的结构依赖时，显式 state 仍明显减少 token，并保持更高分数。

结构化状态把新瓶颈暴露为“结构化输出遵循”

Gemma-4-31B 与 Qwen-3-8B 在长 horizon 下整体分数下降，但 SKILL.state 的 Prompt 仍约 2.1k。Gemma T=100 时 SKILL.state 与 Stateful 都是 0.42，但 token 约为 65k vs 558k；Qwen T=100 为 0.34 vs 0.31，token 约 66.9k vs 569k。

三个结尾证据：高噪声、外部漂移、固定预算

Software Repository 在 50 noise events 下：Prompt 0.11，SKILL.state 0.80；Force Push / Flaky CI 的恢复步数分别对 baseline 为 8–14 步，对 SKILL.state 报告为 0；固定约 1,800 tokens 时，T=100 的 SKILL.state 0.94，而 Summary-capped 0.52、Window 0.18、LLMLingua 0.22。

1. 每一步模型只看三个输入

Aₜ = (P, Σₜ, Oₜ)

P   = immutable procedural specification
Σₜ  = structured execution state at step t
Oₜ  = latest environment observation

最关键的是“没有 C₁…Cₜ 的完整 conversation”。以前的 actions、observations、reasoning 不直接进入下一轮。

2. 模型输出三类东西，但只有一类跨步持久化

(Rₜ, ΔΣₜ, aₜ)

Rₜ   = within-step reasoning       → ephemeral
ΔΣₜ  = structured state patch      → persistent after validation
aₜ   = action                      → sent to environment

3. 状态更新

Σₜ₊₁ = Σₜ ⊕ ΔΣₜ

⊕ = dictionary merge
null = deletion semantics

学习视角：可以把它理解成“把本轮推理压缩为一个具有业务语义、可验证、可覆盖的状态增量”，而不是把自然语言推理摘要当作事实。

论文给出的 CTF 5 字段 Schema

{
  "discovered_flags": [],
  "tested_hypotheses": [],
  "active_files": [],
  "working_dir": "...",
  "cmd_summary": "..."
}

这五个字段不是“记住所有发生过的事”，而是保存未来搜索仍然有用的信息：发现了什么、哪些假设已失败、哪些文件活跃、当前目录、命令摘要。

设计 State Schema 的四条规则

1. Future-use only：字段存在的理由必须是“未来某一步会用它做决策”。
2. Canonical：同一事实尽量只有一个权威位置，避免多个字段表达冲突事实。
3. Patchable：状态应能局部更新，而不是每轮要求模型重写整份对象。
4. Validatable：类型、枚举、ID、引用关系最好能被程序校验。

必须补上的复杂度条件

论文把 |Σ| 和 |O| 视为与 t 无关，因此得到“strictly bounded O(1) prompt footprint”。对固定 500 shelves 的 Warehouse，这个假设很自然；但对开放式文件系统、网页探索、代码搜索、长期任务，如果 state 中集合/日志/摘要持续扩大，就不能只因为 Schema 字段数固定而自动得到 O(1)。

生产策略：对每个字段设计 cardinality bound、TTL、top-K、聚合器或 domain-specific compaction；否则只是把“conversation growth”换成“state growth”。

实验设计最漂亮的地方

作者不仅比较“完整历史 vs state”，还把 Sliding Window、硬上限 Summary、LLMLingua 压缩到与 SKILL.state 近似相同 token budget。这样可以回答一个关键反事实：性能提升到底来自“Prompt 变短”，还是来自“保留了正确的结构化语义”？

不要过度外推

Appendix C 明确把噪声限定为 strictly irrelevant + non-state-altering。这证明了对 Attention Drag 的鲁棒性，但没有直接证明对恶意 prompt injection、伪造状态事件、多个可信源冲突、部分可观测世界等问题同样有效。

1. “State 是充分统计量”不是自动成立

如果某条早期观察当时没被识别为重要事实，就不会进入 Σ；历史一旦丢弃，未来无法回看。这是论文自己明确列出的限制。

2. 固定 Schema 不保证 O(1)

Schema 字段固定，但字段值仍可能无限增长。对开放式 Agent 必须额外设计 state budget。

3. Patch 与 Action 的原子性

Algorithm 1 的顺序是 Validate Patch → Apply Σₜ₊₁ → Execute aₜ。如果动作执行失败，论文没有给出完整的 commit/rollback 事务协议。生产实现应避免“状态声称已发生，但外部世界没发生”。

4. Stateful (LangGraph-style) 是一种基线配置，不等于整个框架能力边界

论文中的 Stateful baseline 是“结构化 state + 完整 rolling transcript”。因此它证明的是这种配置相对 SKILL.state 的差异；不能直接理解成所有 LangGraph 应用都必须保留完整 conversation。

为什么三层都要保留

• State 解决“下一步要知道现在是什么”。
• Memory 解决“有些信息当前不在 state，但可能被未来查询重新激活”。
• Event Log 解决“人类需要知道到底发生过什么”，同时避免把审计历史当作每步推理上下文。

建议把论文的单阶段写状态改成事务式提交

observe Oₜ
   ↓
LLM proposes {patch, action}
   ↓
validate schema + invariants
   ↓
execute action against environment
   ↓
if success:
    commit/reconcile patch → Σₜ₊₁
else:
    keep/rollback Σₜ and write failure observation
   ↓
append immutable event log

对“动作本身会改变世界”的系统，这种顺序更容易维护 state/world consistency。若需要 optimistic update，也应保存版本和 rollback 信息。

State Schema

State = {
  "goal": str,
  "facts": dict,
  "tested_hypotheses": list[str],
  "active_resources": list[str],
  "progress": dict,
  "done": bool
}

LLM Structured Output Contract

{
  "state_patch": {
    "facts": {"key": "new_value"},
    "tested_hypotheses": ["..."],
    "done": false
  },
  "action": {
    "tool": "...",
    "args": {...}
  }
}

Runtime Loop

state = initial_state()
observation = env.reset()

while not state["done"]:
    prompt = build_prompt(skill_spec, state, observation)
    proposal = llm.generate_structured(prompt)

    validate_patch(proposal.state_patch)
    validate_action(proposal.action)
    validate_invariants(state, proposal.state_patch)

    result = env.execute(proposal.action)

    if result.success:
        state = merge(state, proposal.state_patch)
    observation = normalize(result)

    event_log.append({
        "state_version": version(state),
        "action": proposal.action,
        "result": result
    })

必须加的 6 个 Runtime Guard

1. JSON Schema / grammar constrained output
2. 字段级 patch allowlist
3. 状态 invariant 校验
4. state version / optimistic concurrency
5. action idempotency key
6. event-sourced audit log + replay

推荐你在复现时额外测两个论文没完全覆盖的问题

• State growth：让 tested_hypotheses 每步增长，测 O(1) 何时失效。
• Action failure：让 10% 工具调用返回失败，验证“先 patch 后 action”是否造成 state/world divergence。

1. SKILL.state 与“对 conversation 做 summary”最根本的语义差别是什么？
2. 为什么 Rₜ 可以丢弃，而 ΔΣₜ 必须保留？什么情况下这个假设失败？
3. 固定 5-field Schema 为什么不自动等于 O(1) Prompt？
4. 为什么 Sliding Window 与 LLMLingua 在相同 token budget 下仍大幅掉分？
5. 论文的 State Recovery 0 steps 依赖了哪些实验条件？
6. 如果最新 observation 本身错误，canonical state 会发生什么？如何加 provenance/confidence？
7. 为什么 production 系统仍应该保存 append-only event log，但不必把它喂给模型？
8. 多 Agent 共享 Σ 时，⊕ 需要解决哪些并发语义？
9. Action 执行失败时，怎样保证 state 与 world 原子一致？
10. 什么类型的任务本质上不适合彻底抛弃历史轨迹？

论文

• SKILL.state: Scalable Long-Horizon Agent Skills — arXiv:2608.26263
• arXiv PDF

本文逐页分析基于用户提供的 2608.26263v2.pdf（16 页），正文数字、公式、Benchmark、Prompt 模板与限制均按该版本整理。

内容边界

论文直接支持：SKILL.state 的输入/输出形式化、Algorithm 1、Schema 设计示例、复杂度主张、SkillExecBench、InterCode CTF、τ-Bench、各表实验数字、错误分类、Limitations 与 Appendix prompts。

本文工程推导：Markov 化解释、固定 Schema 不等于固定 state size 的复杂度条件、Patch/Action 原子性分析、State/Memory/Event Log 三层架构、事务式 commit、state version / idempotency / invariants 等生产化建议。这些是基于论文机制的系统工程延伸，不是作者在论文中完整给出的实现。