当账本从流水账换成科目余额：Google SKILL.state 拆解
一个跑了 200 步的 agent，在第 200 步收到的 prompt 里，躺着第 3 步的货架记录、第 47 步的报错、第 112 步的一次犹豫。这些信息大多早就用不上了，但它们还在上下文里占着位置。Google 的新论文 SKILL.state（arXiv 2608.26263）给这个病起了名字：上下文的麻烦不…
当账本从流水账换成科目余额：Google SKILL.state 拆解
一个跑了 200 步的 agent，在第 200 步收到的 prompt 里，躺着第 3 步的货架记录、第 47 步的报错、第 112 步的一次犹豫。这些信息大多早就用不上了，但它们还在上下文里占着位置。Google 的新论文 SKILL.state（arXiv 2608.26263）给这个病起了名字：上下文的麻烦不是不够用，是会中毒——在 200 步的仓库管理任务上，标准 ReAct 的准确率从 100 步时的 0.84 掉到 0.74，同期 prompt 累计吃掉 260 万 token。
论文的解法一句话能说完：别记流水账，记科目余额。
会计几百年前就解决了这个问题。你不需要重读所有凭证才知道现金余额——每笔交易发生时更新余额，凭证归档备查。SKILL.state 把这个结构搬进了 agent 运行时。
状态、补丁、和被丢掉的草稿
传统 runtime 是 append-only：每一步的观察、思考、动作都追加进对话历史，prompt 随步数线性变长，累计成本按平方涨。SKILL.state 用一个显式的、可变的执行状态取代它。
每步 prompt 只有三样东西：技能说明书（整个任务期间不变的那份程序性规范）、当前状态（一份结构化的字段表——比如 CTF 场景就五个字段：已发现的 flag、已测试的假设、活跃文件、工作目录、命令摘要）、最新观察。
模型照常推理。论文特意强调：步内的思维链完整保留，不受任何限制， deductive planning 该多长多长。但推理的产出被规定成两样东西——一份 JSON 补丁（改哪些键、置 null 删哪些键）和下一个动作。补丁通过验证、合并进状态之后，推理痕迹永久丢弃，永不再进后续 prompt。
论文的灵魂句值得原样记下：把瞬态推理投影成持久结构化状态，只让未来执行所需的信息活过这次交互。
复杂度的账这样算：append-only 每步 prompt 长度 O(t)，累计 O(T²)；SKILL.state 每步常数，累计 O(T)。落到数字上：同一个 200 步任务，ReAct 总共 2,608,755 token，SKILL.state 122,384——十九分之一。准确率反过来：0.74 对 0.94。更说明问题的是曲线形状：SKILL.state 每步成本 1,811 token，从 100 步跑到 200 步纹丝不动（100 步时是 1,905，甚至略降）。它是平的，不是一条斜率很小的斜线。
三个对照组，比主实验更有意思
主表格之外，论文的三个对照实验把「为什么」讲得更清楚。
第一个：摘要记忆不是解药，是慢一拍的病。Memory 基线（滚动 3 步窗口+周期性自然语言摘要）在 200 步时吃了 617 万 token——比 ReAct 的 261 万还贵一倍多。每一步都往摘要里写新内容，摘要自己也在膨胀，它只是把 append-only 的速度调慢了一档。
第二个：光「有状态」不够，得「只有状态」。LangGraph 式基线把结构化状态块和完整滚动历史一起塞进上下文，得 0.88——比 ReAct 好，但离 0.94 差一截。状态块是对的，历史把它淹了。
第三个最锋利：等预算对照。所有基线被砍到和 SKILL.state 一样的约 1,800 字符预算再跑一遍——滑窗 0.18（关键的早期库存分配被挤出窗口），LLMLingua 压缩 0.22（统计熵过滤把「看似冗余的槽位标识符」删了，而那些标识符语义上生死攸关）。SKILL.state 在同样预算下 0.94。结论就一句：收益不来自 prompt 短，来自「什么被留下了」。统计压缩毁掉的是精确的关系依赖，结构化状态保住的正是它。
「丢了历史会怎样」——论文自己回答了
「如果历史真的被丢掉，会发生什么？什么该留下？」——论文用一正一反两个答案接住了这个问题。
反着说：丢掉历史不但不可怕，还能救命。实验 3 让环境在 agent 看不见的地方悄悄变化——外部人员挪动了货架上的货，然后发一条纠错警报。历史基线连续 5 到 8 轮幻觉：prompt 里堆积的过时事实压过了矛盾的新观察，旧记录有权威，新观察说不过它。SKILL.state 零恢复步——纠错警报一到，状态立即更新。历史不只是贵，它会跟现实打架。
正着说，Limitations 老老实实列了三条丢历史的代价。一是 schema 得事先写好：领域结构未知时，状态该长什么样没法边跑边发现。二是延迟相关性：正确的状态更新可能依赖一个「当时没看出有用」的早期观察——它没进状态，50 步后要用时已经没了。三是任务目标定义在历史本身：审计、调试溯源、解释过去的行为——这时历史是产出，不是开销。
这三条合起来，恰好是「什么该留下」的精确形状。而 SKILL.state 真正的立场藏在架构里：这个判断不该由模型在每一步推理时用注意力隐式地做，该在工程师写 schema 的那一刻显式地做。判断没有消失，只是换了地方、提前了时刻。
验证在运行时，不在模型
小模型的表现暴露了这套架构的真实瓶颈。Gemma-4-31B 在 100 步任务上得分 0.42，误差分类后：68% 是过早覆盖或删除状态键（更新时漏掉了已有字段），20% 是 schema 类型理解，12% 是 JSON 语法——全是结构化输出遵从性问题，不是推理能力问题。
论文的架构回应恰好是个教科书设计：schema 的所有权和验证在确定性运行时，不在模型。格式坏的补丁进不了持久状态，触发回滚重试。模型可以猜错，账本不会脏。
公开基准上这套东西也站得住。InterCode CTF 上 pass@1 54.2% 对 ReAct 的 43.2%——状态里显式记着「已测试的假设」，模型不再重复踩同一个坑。τ-Bench Airline 上 32.4% 对 21.8%，基线 prompt 峰值超过每步 1.1 万 token，SKILL.state 恒定约 2,800。噪声实验再补一刀：每步注入 5 到 50 条干扰事件（遥测、无关的 git 分支活动、规则改写），ReAct 从 0.68 掉到 0.53，SKILL.state 全程不低于 0.97——干扰在生成补丁的环节就被滤掉了，根本没机会进后续 prompt。
收尾
从「它能记住多少」到「什么该留下」，中间其实还隔着一问：谁来决定什么该留下。SKILL.state 的答案是三次分工——工程师写 schema，定下领域里什么是字段；运行时验证补丁，守住账本不被写坏；模型只负责提出补丁，做它擅长的猜测与推理。
两百步以后还站得住的信息，不是记住的，是设计出来的。