SKILL.state深入解析：把AI Agent长程执行变成可校验的状态迁移

写在前面

欢迎大家关注Rocky的公众号：WeThinkIn 欢迎大家关注Rocky的知乎：Rocky Ding 《三年面试五年模拟》AIGC/LLM/AI Agent算法工程师/开发工程师求职面试秘籍独家资源：【三年面试五年模拟】WeThinkIn/AIGC-Interview-Book，欢迎大家Star～

Rocky最新撰写的10万字AI Agent（AI智能体）深入浅出全维度解析文章： 深入浅出完整解析AI Agent（AI智能体）的核心基础知识

AIGC/LLM/AI Agent算法岗/开发岗求职面试内推学习社群（涵盖AIGC、LLM大模型、AI Agent、传统深度学习、自动驾驶、机器学习、计算机视觉、自然语言处理、强化学习、大数据挖掘、具身智能、元宇宙、AGI等AI行业最新面试干货经验与核心知识）欢迎大家加入：https://t.zsxq.com/33pJ0

大家好，我是Rocky。

核心导读：Agent运行得越久，为什么越容易被自己的历史拖累？

一个仓库 Agent 已经处理了上百条指令：物品入库、货架调整、订单出库，以及穿插其中的传感器日志。第 101 步，它需要回答的可能只是“item_12 现在在哪里”。如果系统每次都把此前的对话、工具输出和推理重新交给模型，这个简单问题就变成了另一项任务：从不断增长的文字中重建当前世界，并判断哪些信息已经失效。

长上下文可以容纳更多历史，却不会自动判断哪条旧事实已经被新事实覆盖。一次失败命令、一个过时位置、一段错误假设，都可能继续留在后续输入里。这里的问题已经进入运行时设计：系统究竟把什么视为执行的依据，又允许哪些信息跨步骤保留？

Sanket Badhe、Priyanka Tiwari 和 Jonghyun Chung 提出的 SKILL.state: Scalable Long-Horizon Agent Skills，给出一个明确方案：每一步只输入不可变技能规范、结构化执行状态和最新观察；模型完成本步推理后，运行时校验并应用状态补丁，后续步骤不再重放此前的推理轨迹。本文讨论 arXiv:2608.26263 的 v3 版本，作者机构为 Google LLC 与 Purdue University。

Rocky认为，这篇论文最有价值的判断，是把“当前执行事实的维护”从模型反复阅读历史的隐含能力，提升为运行时的显式责任。 模型仍负责推理，但跨步骤保留的信息需要进入有结构、有更新语义、可校验的状态。

作者报告，在 Gemini-3-Flash 的仓库 100 步实验中，SKILL.state 的动作准确率为 0.94，累计 Token 为 65,408；同时保留历史和状态的 Stateful 基线分别为 0.91 与 1,062,387。这个结果支持认真研究显式状态，但不能直接推广成“所有 Agent 都能节省 16 倍成本”。收益依赖领域是否适合状态化、状态是否充分、字段是否真正有界，以及模型能否稳定生成正确补丁。

本文先解释执行机制和复杂度条件，再保留完整实验表格，最后讨论证据边界与工程落地。论文结果、技术解释和 Rocky 的研究建议会明确区分。

一、问题背景：对话记录、摘要和执行状态，各自承担什么职责？

1.1 历史能够解释过程，却未必适合作为每一步的工作区

ReAct 式执行将推理、动作、观察串起来，优点是简单、信息保留充分，也便于追踪模型如何到达当前结果。在探索性任务里，某个早期细节可能到后面才显出价值，保存历史具有实际意义。

问题出现在长程、重复、状态明确的流程中。模型每一步都要重新消解“物品先在 A、后来移到 B、又尝试移到 C 但失败”这种时序关系。输入越长，重复读取越多；历史中的错误推理与旧事实也越容易同当前观察竞争。将全部过程视为当前决策上下文，会把状态管理成本转交给模型。

摘要尝试压缩过程，但一份自然语言摘要同样需要决定哪些关系不可删除。如果摘要遗漏了物品编号与货架编号的绑定，即使语言流畅，也可能无法支持下一条出库命令。状态表示要解决的关键问题是：哪些信息必须精确保留，哪些可以覆盖，哪些已经没有执行价值。

1.2 论文比较的是具体运行时配置

这里的 Stateful 是作者实现的 LangGraph-style 基线，其附录提示明确包含完整历史。它不能代表所有使用 LangGraph 的系统，也不能据此认定某个框架必然要求无限追加对话。本文将实验结论限定在这些具体配置上。

SKILL.state 关注技能已经选定之后如何执行。它没有在本文解决大规模技能检索、跨任务技能发现或模型参数学习。把这些问题区分开，才能判断这项运行时改造适合放在系统的哪一层。

二、方法展开：只让未来需要的信息穿过执行边界

图 1｜SKILL.state 的完整架构图。左侧将历史持续加入上下文，右侧将本步推理投影成状态更新，再以当前状态继续执行。下方

t

=

500

t=500

t=500 的条形图是增长趋势示意，不是本文报告了 500 步实测；仓库扩展实验最长为 200 步。图中的常数输入结论也需要状态与观察大小有界的条件。

2.1 输入三元组：规范、状态与最新观察

论文在引言中以公式（1）概括执行输入：

A

t

=

(

P

,

Σ

t

,

O

t

)

.

A_t=(P,\\Sigma_t,O_t).

At​=(P,Σt​,Ot​).

其中，

P

P

P 是不可变的过程规范，包含任务规则、可用动作和行为要求；

Σ

t

\\Sigma_t

Σt​ 是当前结构化执行状态；

O

t

O_t

Ot​ 是最新环境观察。这里的大写

A

t

A_t

At​ 表示输入上下文，后文的小写

a

t

a_t

at​ 才表示执行动作，两者不能混用。

论文在方法部分以公式（2）再次给出同一定义：

A

t

=

(

P

,

Σ

t

,

O

t

)

.

A_t=(P,\\Sigma_t,O_t).

At​=(P,Σt​,Ot​).

这两个编号公式内容相同，分别承担引入思路和正式定义的作用。真正改变执行方式的约束是：后续 Prompt 不再包含先前观察、动作和推理的完整文本；此前有价值的信息必须已经进入状态。

还要区分 Agent 保存的执行状态 和 环境真实状态。前者由模型提出更新，后者存在于仓库、数据库或工具系统中。一个 JSON 对象结构正确，不代表其中记录的事实一定真实；显式化使差异更容易检查，并不会让差异自动消失。

2.2 Schema 按领域设计，而不是为每道题定制

作者使用领域级状态 Schema。例如 InterCode CTF 的 100 个任务复用五个字段：discovered_flags、tested_hypotheses、active_files、working_dir 和 cmd_summary。这些字段分别保存已发现的结果、已测试假设、活跃文件、工作目录以及命令相关摘要。

这种设计具有合理的工程直觉：下一步需要知道某个假设已经失败，未必需要重读提出假设时的全部文字。但 tested_hypotheses 是一个固定字段，并不意味着它的列表长度固定；cmd_summary 是一个固定字段，也不意味着其中的字符串永远不增长。字段数量有界与序列化后的状态大小有界，是两项不同约束。

一个可执行的 Schema 还需要约定身份、单位、生命周期和未知值。例如，“尚未检查货架”和“货架已经确认为空”能否用同一个 null 表示？某个假设是未测试、已否定，还是因为工具失败而无法判断？这些区分决定压缩后的状态是否仍能支持可靠动作。

2.3 输出三元组：临时推理、状态补丁与动作

论文公式（3）：

(

R

t

,

Δ

Σ

t

,

a

t

)

.

(R_t,\\Delta\\Sigma_t,a_t).

(Rt​,ΔΣt​,at​).

R

t

R_t

Rt​ 是本步中间推理，

Δ

Σ

t

\\Delta\\Sigma_t

ΔΣt​ 是描述键修改与删除的 JSON 字典，

a

t

a_t

at​ 是将要执行的命令。SKILL.state 并未取消单步多步推理；它改变的是推理生成之后的信息保留方式。状态更新通过验证后，本步推理不进入后续 Prompt。

论文公式（4）：

Σ

t

+

1

=

Σ

t

⊕

Δ

Σ

t

.

\\Sigma_{t+1}=\\Sigma_t\\oplus\\Delta\\Sigma_t.

Σt+1​=Σt​⊕ΔΣt​.

⊕

\\oplus

⊕ 表示带有 null 删除语义的字典合并操作。这个定义强调补丁作用于已有状态，而非每一步重写整个状态。图中出现的 “JSON Patch” 应按论文的字典补丁语义理解，不能直接当成已经声明符合某个 JSON Patch 标准协议。

附录的仓库示例中，最新请求是出库 item_12，状态记录该物品位于 shelf_42。模型输出：

{
"state_patch": {
"inventory": {
"shelf_42": null
}
},
"action": "Ship item_12 shelf_42"
}

读者应注意：删除的含义、嵌套字典如何合并、缺失键是否保留，需要由运行时明确定义。只知道顶层执行一次 dict.update，不足以推出深层键也会按预期合并或删除。论文提供了上述示例，但没有在正文给出足以覆盖所有嵌套情况的合并实现。

2.4 算法 1：运行时如何接管状态更新

以下中文伪代码保留论文 Algorithm 1 的执行顺序；无效补丁的回滚重试来自论文限制部分的补充说明。

输入：不可变技能规范 P，初始状态 Sigma_0
对执行步骤 t = 0, …, T：
接收最新观察 O_t
构建输入 (P, Sigma_t, O_t)
调用模型，生成 (本步推理 R_t, 状态补丁 DeltaSigma_t, 动作 a_t)
校验状态补丁
若补丁无效：不提交该补丁，进入回滚与重试处理
若补丁有效：Sigma_(t+1) = Merge(Sigma_t, DeltaSigma_t)
执行动作 a_t
本步推理不进入下一次输入

论文伪代码采用

t

=

0

,

…

,

T

t=0,\\ldots,T

t=0,…,T 的索引，实验中的

T

T

T 则表示执行长度。工程实现应统一轮数约定，避免把索引上界与实际调用次数混用。

更值得关注的是提交顺序：论文算法先更新内部状态，再执行动作。对于会失败或只部分成功的外部工具，这会出现状态与环境不一致的窗口。例如内部已删除库存记录，出库命令却失败了。论文说明了无效补丁的回滚重试，却没有在该算法中完整展开工具失败后的事务协议。

Rocky的工程建议是，将拟议状态与已确认事实分开，并使工具返回能够驱动确认、补偿或回滚。 具体选择先执行后提交，还是使用待确认状态和事务日志，要结合工具的幂等性与业务约束。这里是在补充生产系统设计，并非论文已经完成了分布式事务验证。

三、复杂度分析：从平方增长到线性增长，需要哪些前提？

3.1 历史重放为什么产生平方级累计输入

论文公式（5）：

∑

t

=

1

T

∣

C

t

∣

=

O

(

T

2

)

.

\\sum_{t=1}^{T}|C_t|=\\mathcal O(T^2).

t=1∑T​∣Ct​∣=O(T2).

C

t

C_t

Ct​ 表示历史累积型运行时第

t

t

t 步的上下文。若每步追加的信息量近似固定，且没有截断或硬上限，单步输入长度随

t

t

t 线性增长。累计读取的历史相当于

1

+

2

+

⋯

+

T

1+2+\\cdots+T

1+2+⋯+T，于是得到平方级输入规模。

这个结论描述的是上述追加模式。具有固定窗口、严格摘要上限或其他有界上下文策略的运行时，不必满足同样的增长形式。论文后来加入预算匹配实验，正是为了区分“输入变短”和“保留了正确状态”两种作用。

3.2 状态输入为什么可能保持有界

论文公式（6）：

∣

P

t

∣

=

O

(

∣

P

∣

+

∣

Σ

∣

+

∣

O

∣

)

.

|P_t|=\\mathcal O(|P|+|\\Sigma|+|O|).

∣Pt​∣=O(∣P∣+∣Σ∣+∣O∣).

这里的

P

t

P_t

Pt​ 表示第

t

t

t 步完整 Prompt，需与不可变规范

P

P

P 区分。论文公式（7）进一步给出：

∑

t

=

1

T

∣

P

t

∣

=

O

(

T

)

.

\\sum_{t=1}^{T}|P_t|=\\mathcal O(T).

t=1∑T​∣Pt​∣=O(T).

推导的关键在于：规范大小、执行状态大小和最新观察大小，必须受到不随执行长度增长的上界约束。为了把条件写清楚，可以将论文分析展开为下面这个解释式：

∑

t

=

1

T

∣

P

t

∣

=

O
 ⁣

(

T

∣

P

∣

+

∑

t

=

1

T

∣

Σ

t

∣

+

∑

t

=

1

T

∣

O

t

∣

)

.

\\sum_{t=1}^{T}|P_t|=\\mathcal O\\!\\left(T|P|+\\sum_{t=1}^{T}|\\Sigma_t|+\\sum_{t=1}^{T}|O_t|\\right).

t=1∑T​∣Pt​∣=O(T∣P∣+t=1∑T​∣Σt​∣+t=1∑T​∣Ot​∣).

如果状态不断追加新实体、已测试假设和命令摘要，或者每步工具返回越来越长，那么仅仅删除对话历史不足以保证

O

(

T

)

\\mathcal O(T)

O(T)。领域 Schema 给出了结构约束，还需要容量、归档、选择性读取或观测压缩来约束实际大小。

3.3 输入长度、累计 Token、推理延迟与费用不能画等号

公式（5）—（7）直接分析累计 Prompt 规模。将它推广到全部 Token 消耗，还需要约束每步输出、推理长度以及回滚重试次数。一个字段错误导致模型反复重试，即使每次 Prompt 固定，实际执行成本仍可能升高。

计费还受到输入与输出单价、缓存命中和供应商计费方式影响；延迟受到模型计算、工具等待、并发和重试影响。本文引用的“16.2 倍”是特定表格的累计 Token 比值，不是延迟加速比，也不是实测费用收益。论文没有给出足以替代这些独立测量的端到端成本报告。

Rocky认为，显式状态降低的是每一步重建历史的负担。它的长期价值，需要同时通过正确率、执行成本和状态维护成本来检验。

四、评测设置：先弄清任务、指标与基线的边界

4.1 两类合成环境与两类公开基准

SkillExecBench 包含仓库管理与软件仓库两个受控环境。仓库环境维护 500 个货架，通过 Store、Ship、Move 和 Wait 处理物品与订单；软件环境模拟分支、提交、PR 与 CI 状态，以依赖关系变化考察执行能力。这些任务有确定性的环境转移，适合诊断状态追踪，却不是完整工业仓储或真实软件开发系统。

InterCode CTF 包含 100 个终端挑战，Agent 在容器中通过命令试探假设并寻找 flag；论文按精确结果匹配衡量 pass@1。Sierra

τ

\\tau

τ-Bench 包含 Retail 与 Airline 客服流程，由模拟用户、工具调用和数据库状态变化组成。其成绩依赖程序化评估器，不能直接等同于真实用户满意度或对所有业务规则的完整形式化证明。

软件仓库动作定义存在一处需要复现者处理的差异：正文列举 CherryPick、Merge、RunTests、CreateRelease 和 Rollback，附录列举 Commit、CreatePR、Merge、FixCI 和 Wait。两者不完全一致。本文保留“模拟软件状态执行”这个共同定义，不将其写成已确定的统一 API 规范。

4.2 分数、字符与 Token 的不同含义

仓库任务的评分可写成：

S

c

o

r

e

=

S

u

c

c

e

s

s

f

u

l

A

c

t

i

o

n

s

T

o

t

a

l

A

c

t

i

o

n

a

b

l

e

E

v

e

n

t

s

.

\\mathrm{Score}=\\frac{\\mathrm{Successful\\ Actions}}{\\mathrm{Total\\ Actionable\\ Events}}.

Score=Total Actionable EventsSuccessful Actions​.

所以 0.94 是动作层面的准确率，不是“94% 的完整 100 步任务全部成功”。软件仓库附录更具体地以正确解决并合入主分支且不破坏 CI 的请求比例定义成功。公开交互基准则使用任务成功率。不同指标不能直接混合成一个总平均。

论文指标定义将 Average Prompt Size 规定为每次调用的平均字符串字符数；Total Tokens 是累计 Token 消耗。后文有个别段落和表注把 Prompt 预算写成 Token，存在口径不一致。本文保留原数值，并在涉及这些口径的地方明确指出，避免自行选择一个单位后当成已核实事实。

底层模型为 Gemini-3-Flash、Gemma-4-31B-it 和 Qwen-3-8B-it。作者设置 temperature=0、top-p=1，并对合成实验采用 5 个生成种子，报告均值与样本标准差。零温度有助于减少采样差异，但不单独保证模型服务、工具环境与全部运行过程完全确定。

作者报告长程条件下的配对 t 检验

p

<

0.01

p<0.01

p<0.01。没有逐种子结果与完整比较明细，就无法独立复算每个检验，也不能把这句总体陈述套到所有模型、任务和运行时组合上；后文存在分数相同和短程表现不占优的组合。

4.3 附录算法：同一随机过程生成可比事件

论文附录的第二个算法给出了仓库任务生成过程，核心是固定随机种子，让不同运行时面对相同外部事件序列：

seed = 42 # 附录示例种子
rng = Random(seed)
gt_shelves = 500 个初始为空的货架
events = []
重复 Horizon 次：
available = 查询空货架
occupied = 查询占用货架
possible_events = [Receive]
若 occupied 非空：加入 Order 和 Maintenance
event_type = rng 从 possible_events 中采样
events 追加由 event_type 构造的观察
按 event_type 更新生成器的真实状态
返回 events

这里的 42 是生成伪代码示例，不代表全部实验仅使用这一种子。需要复现时，还应获得五个实验种子的具体取值、事件构造规则，以及 Agent 动作偏离预期后环境如何继续反馈。固定外部事件流能够增强可比性，但真实交互仍可能受各运行时自身动作影响。

五、仓库长程执行：最清楚的收益来自输入规模控制

论文表 1｜Gemini-3-Flash 的仓库长度扩展，均值 ± 标准差，5 个种子。Avg Prompt 的单位在该表明确为字符；Score 是动作准确率。

从 10 步到 200 步，SKILL.state 的平均 Prompt 在约 1,736—1,905 字符之间变化，整体接近稳定。相对地，Memory 在 200 步时平均 Prompt 达到 84,364 字符，累计 Token 达到 6,175,509。摘要机制的存在，并没有在这一实现中自动形成严格容量上限。

100 步时，Stateful 与 SKILL.state 的累计 Token 比为

1,062,387

/

65,408

≈

16.24

1{,}062{,}387/65{,}408\\approx16.24

1,062,387/65,408≈16.24；后者相对减少约 93.84%。分数从 0.91 提高到 0.94，是 3 个百分点的动作准确率差。相对 Prompt 基线，Token 比约为 19.04，准确率差为 10 个百分点。选择不同基线会得到不同倍率，引用时必须同时给出分母。

200 步时，SKILL.state 仍为

0.94

±

0.02

0.94\\pm0.02

0.94±0.02，累计 122,384 Token。这支持“在给定仓库环境中，显式状态有效抑制历史输入增长”的结论。但它没有证明任意实体规模、任意领域或无限长度下仍能维持同等正确率。500 个货架是环境容量，200 步是实测执行长度，两者也不能互换。

六、噪声鲁棒性：实验验证的是无关干扰过滤

论文表 2｜仓库噪声实验，50 步，Gemini-3-Flash。

在每步 50 条噪声下，Prompt 的分数为 0.53，SKILL.state 为 0.98。把无关信息过滤在状态补丁生成环节之外，可以减少它们在未来步骤重复出现，这是结果支持的一种机制解释。

但 SKILL.state 并未在所有噪声条件下独占最优。20 条噪声时，Memory 为 1.00、Stateful 为 0.98，而 SKILL.state 为 0.97；50 条噪声时，SKILL.state 与 Stateful 同为 0.98。结果更适合表述为相对直接累积历史具有明显鲁棒性，而非对全部记忆策略的全面胜出。

附录将实际评测限定为 Condition 1：随机生成、与主任务严格无关、且不会改变真实环境状态的背景遥测。尽管正文使用了较宽泛的“context corruption”措辞，这组实验不能证明对抗提示注入、伪造业务指令、恶意工具输出或真正状态突变下的安全性。新观察依然直接进入本步 Prompt，恶意内容仍可能影响模型提出的补丁。

七、状态恢复：零额外滞后需要纠正信息到达

论文表 3｜仓库状态恢复，Gemini-3-Flash。

Secret Audit、Secret Barcode 和 Secret Move 三种场景中，SKILL.state 报告 0 个恢复步骤，历史基线出现约 5—8 或 6—8 步滞后。论文解释是：环境提供纠正告警后，状态立即更新，过时事实不再通过长历史反复影响判断。

“0”应理解为该恢复指标下没有额外滞后，不能理解为系统无需观察就能发现外部变化。显式状态有利于覆盖旧事实，状态更新仍然需要可信的新证据。 如果现实中有人移动物品但工具系统没有提供任何变化信号，三元组中同样缺少恢复依据。

此外，Canceled Order 场景下所有运行时都失败。论文没有在该表提供足以定位共同失败根因的完整轨迹，因此应保留这个反例，而不是将恢复机制概括为所有漂移都能自动处理。

八、公开交互基准：成功率与累计 Token 的改善并不要求每步更短

论文表 4｜Gemini-3-Flash 在三个公开交互任务设置中的结果。k 与 M 分别表示千与百万；Prompt 列沿用论文名称，其单位问题见下文。

8.1 InterCode CTF：显式保存假设，减少无效重复

SKILL.state 的 pass@1 为 54.2%，比最强基线 Memory 的 46.4% 高 7.8 个百分点，比 Stateful 的 41.8% 高 12.4 个百分点。累计 Token 从 ReAct 的 977k 降为 387k，按表中舍入数计算，减少约 60.4%。

CTF 状态保存已测试假设与当前工作目录，因而具有减少重复探索的合理机制。它仍需要模型选择值得测试的下一条假设；状态维护不能替代解题推理。本实验提供的是作者报告的任务级结果，没有通过更细消融单独识别每个字段的贡献。

还有一个统计口径需要澄清：表头写 100 个任务，且指标被定义为二元 pass@1，但 54.2%、43.2% 这样的比例不能直接对应“100 个任务各运行一次”的整数成功数。它可能涉及重复评估或其他聚合方式，本文核对的描述不足以确定。因此保留报告值，不把它改写为“54.2 道题成功”，也不擅自补充重复次数。

8.2 Retail：平均 Prompt 更长，但累计 Token 更少

Retail 上，SKILL.state 成功率为 58.3%，高于 Stateful 的 51.7%，累计 Token 为 3.47M，也是表中最低。然而其 Prompt 值为 3,325，反而高于 ReAct 的 2,819、Memory 的 2,737 与 Stateful 的 3,065。

这个反例很重要：高效执行不等于每一次模型调用都使用最短输入。 更充分的状态可能增加单步输入，却帮助减少无效交互。论文没有在这里给出调用次数、输出 Token 和失败重试的完整分解，所以“步骤减少”属于合理解释，不能写成已经逐项测量的确定归因。

8.3 Airline：更低累计消耗，成功率仍只有三成左右

Airline 上，SKILL.state 的成功率为 32.4%，比 Stateful 的 28.1% 高 4.3 个百分点；累计 Token 为 2.88M，低于 ReAct 的 4.85M 和 Stateful 的 5.28M。按表中已经舍入的数值重新计算，降幅分别约为 40.6% 与 45.5%；论文正文给出 40.5% 与 45.4%，可能涉及未展示精度，本文不将二者强行视为完全一致。

32.4% 同时说明任务仍然困难，不能只引用相对提升而略去绝对成功率。论文正文将约 2,800 的 Prompt 描述成 tokens/step，而指标定义使用字符数。缺少日志与统一计数说明时，无法据此精确重建单步 Token 预算。

九、预算匹配：短输入本身不足以解释全部收益

论文表 5｜仓库 100 步，Gemini-3-Flash，预算匹配控制。表注称约 1,800 tokens，正文同一实验又称约 1,800 characters；下面保留 Avg Prompt 名称和原数值，不自行统一单位。

滑动窗口、受限摘要和 LLMLingua 的累计 Token 都在约 6.2 万—6.3 万，接近 SKILL.state 的 65,408。但分数分别为 0.18、0.52 和 0.22，显著低于 SKILL.state 的 0.94。这个比较支持一个实用判断：执行依赖精确实体关系时，保留的信息类型比单纯减少输入长度更关键。

例如，货架编号看起来重复，实际上承担“哪个物品在哪里”的映射关系。统计压缩如果破坏这种关联，即使留下了任务大意，也不能正确生成下一条动作。作者将 LLMLingua 的退化归因为关键槽位信息丢失；本文将其限定为该配置与该任务的解释，不推广成所有压缩器都会失效。

这组实验不是严格意义上的完全等预算。SKILL.state 的 Avg Prompt 为 1,905，滑动窗口为 1,800，相差约 5.8%；累计 Token 也略有不同，再加上单位不一致、压缩器具体配置未充分展开，不能宣称已排除所有资源与实现差异。更稳妥的结论是：在作者报告的近似预算对照中，显式状态保留了对仓库任务更有用的结构。

十、软件仓库扩展：关系状态比独立库存更难维护

论文表 6｜Gemini-3-Flash 的模拟软件仓库长度扩展。按论文指标定义，Avg Prompt Size 为平均字符长度。

100 步时，SKILL.state 为

0.78

±

0.08

0.78\\pm0.08

0.78±0.08，Stateful 为

0.63

±

0.10

0.63\\pm0.10

0.63±0.10，累计 Token 分别为 90,200 和 2,308,000。显式状态的相对优势仍在，但 SKILL.state 自身从 10 步的 1.00 降到了 100 步的 0.78，说明控制上下文增长并不能完全消除长程错误。

25 步时，SKILL.state 为

0.88

±

0.08

0.88\\pm0.08

0.88±0.08，低于 Stateful 的

0.94

±

0.03

0.94\\pm0.03

0.94±0.03，也略低于 Memory 的

0.89

±

0.07

0.89\\pm0.07

0.89±0.07。这进一步限制了“任何长度都最好”的表述。对分支、PR 与 CI 构成的关系网络，修改一个实体可能使多个依赖状态失效；维护局部字段与维护关系一致性之间，仍有明显距离。

Rocky认为，复杂流程的状态设计，应明确哪些字段由工具事实直接更新，哪些字段是模型推断，以及哪些关联必须一起迁移。 这会影响补丁校验能否识别“字段类型正确，但依赖关系已经矛盾”的情况。

十一、开放权重模型：节省上下文，不代表自动获得可靠执行能力

论文表 7｜Gemma-4-31B-it 的仓库扩展。该表将分数写成小数，将分数标准差写成百分数；例如 0.42 ± 4.1% 对应约 0.42 ± 0.041，这里保留论文记法。

100 步时，Gemma 的 SKILL.state 与 Stateful 分数同为 0.42，累计 Token 分别为 65,480 与 557,968。这个组合最直接支持效率改善，不能写成准确率也得到提升。SKILL.state 从 10 步的 0.98 降为 100 步的 0.42，表明长程可靠性问题并未解决。

论文表 8｜Qwen-3-8B-it 的仓库扩展，分数标准差单位同表 7。

Qwen 在 100 步时，SKILL.state 分数为 0.34，高于 Stateful 的 0.31，累计 Token 则从 569,400 降至 66,850；但 0.34 的绝对动作准确率仍然很低。一个便宜但经常错误的执行器，可能将成本转移到人工纠错、回滚和业务损失上。

作者对 Gemma 的失败日志给出三类错误占比：过早覆盖或删除状态 68%，Schema 理解或类型转换问题 20%，JSON 语法格式问题 12%。这提示补丁生成和合并约定值得优先改进。不过论文没有在该段提供错误样本数、分类一致性评估或消除这些错误后的对照，因此不能仅凭分类就证明“模型推理能力完全不是瓶颈”。

受约束解码可以减少语法错误，也可帮助满足结构约束；它无法单独保证物品位置正确、删除时机正确或某个业务动作合法。对于占比最大的覆盖/删除错误，还需要核实模型生成的是补丁还是完整替换，以及嵌套字典的合并语义。

十二、软件环境中的噪声与恢复：保留具体成功，也保留失败

论文表 9｜模拟软件仓库噪声鲁棒性，50 步，Gemini-3-Flash；噪声为不改变环境状态的无关 syslog。

从无噪声到每步 50 条噪声，SKILL.state 从 0.90 降到 0.80，Prompt 从 0.76 降到 0.11。两者差距在高噪声下扩大，但 SKILL.state 仍有下降。正确表述应是更稳健，而非对噪声不敏感。

论文表 10｜模拟软件仓库的状态恢复，比较收到非结构化告警后的恢复滞后。

Force Push 和 Flaky CI Test 下，SKILL.state 报告零额外恢复步骤，其他运行时需要 8—14 步。PR Closed 场景则全部失败。这与仓库 Canceled Order 的共同失败形成呼应：一部分异常可以通过覆盖旧事实处理，另一些异常涉及任务是否仍然可执行、目标是否需要重新解释，单纯更新状态未必足够。

从这些结果得到的工程启发，是为异常设置明确的处理分支：继续执行、重新观察、修复前置条件、转入人工处理或终止任务。这个扩展需要单独评测，不能把论文没有提供的异常策略算作既有能力。

十三、预算随长度扩展：错误保留策略会在长任务里放大

论文表 11｜Gemini-3-Flash 仓库预算匹配的多长度结果，均值 ± 标准差，5 个种子。约 1,800 预算的单位问题与表 5 相同。

10 步时，各压缩策略分数处于 0.88—0.92，SKILL.state 为 1.00；100 步时，滑动窗口与 LLMLingua 分别降至 0.18 和 0.22，SKILL.state 仍为 0.94。随着距离拉长，早期实体映射被丢弃的后果更容易显现。

自然语言摘要在 100 步达到 0.52，明显好于另外两种压缩控制，也说明压缩方法不能一概而论。值得继续研究的是，怎样把结构化约束、摘要和按需证据读取结合起来，并在同一计数口径下比较正确率、调用数、输入输出 Token 与维护开销。

十四、边界与可复现性：充分状态是一项假设，需要持续检验

14.1 三种情况下，丢弃历史可能丢掉未来必需的信息

论文明确承认，状态作为未来执行的充分统计量是方法的前提。第一，任务开始时无法预先确定 Schema，状态结构需要在执行中发现。第二，某条旧观察当时看似无关，后续才暴露重要性，但此前没有被保存。第三，任务目标本身就是审计历史、追踪来源或解释过去动作，历史不能被当作执行负担直接丢弃。

充分性并非“JSON 里有几个合适字段”就能得到的数学保证。它涉及信息选择是否正确、任务是否变化、状态是否保存不确定性，以及新目标是否需要重新访问过去证据。论文没有证明任意领域都存在足够小的充分状态。

14.2 校验可以保护格式边界，语义正确性需要额外机制

运行时负责 Schema 与补丁校验，使无效输出不会直接写入持久状态，这是清楚的责任划分。但类型合法的错误事实仍可能通过结构检查。订单标识是字符串，并不能证明模型选中了正确订单。

生产环境需要将模型提议与可核验事实连接起来：重要字段附带工具证据或版本号；涉及外部副作用时检查前置条件；失败后重新同步权威数据库。审计日志可以独立保存工具动作、状态差异和结果，且无需在每一步全量注入 Prompt。这个设计可借鉴论文的信息隔离思想，但属于扩展方案。

多 Agent 场景进一步引入并发写。论文当前实现聚焦单 Agent，没有验证冲突检测、版本比较、写入顺序或多节点一致性。共享一个 JSON 文件并不自动成为可靠协调协议。

14.3 复现应优先澄清的证据缺口

论文公开了运行时公式、算法、四类主要 Prompt 模板、环境说明与实验表格，足以理解设计方向。arXiv 源包提供论文 LaTeX 和图形资产；在本文核对的论文与元数据中，未找到作者给出的官方实现仓库链接。不能把论文源包当成可直接运行的 Agent 实现，也不能据此断言其他渠道绝对不存在代码。

复现者首先需要确认：预算按字符还是 Token 计算；InterCode 的小数成功率采用什么重复与聚合口径；公开基准的具体版本、任务子集与停止条件；每种运行时的调用、输出、重试与压缩开销如何统计；嵌套补丁和 null 删除的精确定义；以及软件仓库实际采用哪套动作接口。

本文保留论文报告的全部实验表格，并核对数值与计算关系，没有重跑模型基准，也没有把作者的统计显著性声明当作独立复现结果。公开数据里的改善值得进一步研究，口径不完整的部分则需要补充运行证据。

十五、Rocky的研究判断：从状态表示继续走向状态治理

15.1 首先落地在状态边界清晰的流程

库存处理、工单流转、受约束客服和部署流程，通常具有可识别实体、相对稳定的动作空间与可校验工具返回，适合先做状态化试验。开放研究、需求探索和长文创作中，未来相关信息更难提前判断，过早丢弃历史可能损失价值。

对 Agent 团队，起点可以是一个较小但完整的业务流程：定义最小执行状态，明确每个字段的证据来源和更新规则，再同现有运行时做等任务、等工具、统一计数口径的对照。不要从“所有历史都应删除”这个口号开始。

15.2 将状态容量、充分性与更新正确性一起评估

未来研究可以围绕三个相互牵制的目标展开：状态越短，成本越容易控制；状态越完整，未来信息缺失风险越低；更新越复杂，模型越容易出错。只报告平均 Prompt 长度，无法反映这些关系。

值得增加的指标包括：关键字段遗漏率、事实过期率、补丁拒绝率、语义错误率、工具失败后的状态偏离时间，以及恢复到权威状态所需的调用数。再逐步扩大实体数量、任务长度和目标变化程度，才能判断“有界状态”是在真实扩展下成立，还是只在固定实验容量里成立。

15.3 区分工作状态、证据存储与待验证推断

一个更完整的系统可以让紧凑状态服务当前执行，让外部证据存储服务按需追溯，并为模型假设设置单独的可信度与失效条件。这样既不会把所有过程无差别加入每步输入，也不会把暂时的猜测永久固化成事实。

这种组合不是论文已经验证的架构。它是从论文充分性边界出发的一条研究方向：当状态发现缺口时，是否能有控制地检索证据并修正，而不是让摘要或日志再次无限膨胀。

15.4 商业价值最终要落到每个成功任务的总成本

对产品团队，应关注长任务能否稳定完成、异常是否可恢复、人工接管是否减少。对算法工程师，应关注模型能否正确维护关系与补丁，而非只输出合法 JSON。对创业者与投资人，一套显式状态格式本身并不足以形成壁垒；领域状态建模、工具一致性、可靠交付和持续评测才决定其积累价值。

Rocky认为，SKILL.state展示了一条值得验证的Agent工程方向：把运行过程中的短期推理，转化为下一步可使用、可检查、可修正的执行状态。 当状态的充分性、容量和事实一致性都有清晰边界时，上下文管理才开始成为可度量的系统能力。

术语与概念速查

推荐阅读

Rocky一直在运营技术交流群（WeThinkIn-技术交流群），这个群的初心主要聚焦于技术话题的讨论与学习，包括但不限于算法、开发、竞赛、科研以及工作求职等。群里有很多人工智能行业的大牛，欢迎大家入群一起学习交流～（请添加小助手微信Jarvis8866，拉你进群～）

1. 深入浅出完整解析AI Agent（AI智能体）的核心基础知识

2025年可以说是AI Agent全面落地应用的元年，因此Rocky在持续撰写对AI Agent的全维度解析文章：

深入浅出完整解析AI Agent（AI智能体）的核心基础知识

2. 深入浅出完整解析扩散模型DDPM、DDIM、Score-Based、SDE、LDM、Classifier/Classifier-Free Guidance、Rectified Flow核心基础知识

Rocky对扩散模型的本质原理与和核心基础知识进行了全面系统的深入浅出分析讲解，同时不断跟进补充扩散模型的最新技术发展，希望能给大家带来帮助：

深入浅出完整解析扩散模型DDPM、DDIM、Score-Based、SDE、LDM、Classifier/Classifier-Free Guidance、Rectified Flow核心基础知识

3. 入浅出完整解析FLUX.2、Seedream（即梦）、Z-image、GLM-Image核心基础知识

Rocky对AIGC时代“中场时刻”之后的主流AIGC创作大模型的核心基础知识进行了全面系统的深入浅出分析讲解，力求让大家通俗易懂理解AIGC时代的技术浪潮的本质价值：

入浅出完整解析FLUX.2、Seedream（即梦）、Z-image、GLM-Image核心基础知识

4. 深入浅出完整解析FLUX.1 Kontext和FLUX.1 Krea核心基础知识

Rocky对FLUX.1 Kontext和FLUX.1 Krea的核心基础知识作了全面系统的梳理与解析：

深入浅出完整解析FLUX.1 Kontext和FLUX.1 Krea核心基础知识

5. 深入浅出完整解析DeepSeek系列核心基础知识

Rocky对DeepSeek系列模型的核心基础知识作了全面系统的梳理与解析：

深入浅出完整解析DeepSeek系列核心基础知识

6. 深入浅出完整解析Stable Diffusion 3（SD 3）和FLUX.1系列核心基础知识

Rocky对Stable Diffusion 3和FLUX.1的核心基础知识作了全面系统的梳理与解析：

深入浅出完整解析Stable Diffusion 3（SD 3）和FLUX.1系列核心基础知识

7. 深入浅出完整解析Stable Diffusion XL（SDXL）核心基础知识

Rocky对Stable Diffusion XL的核心基础知识作了全面系统的梳理与解析：

深入浅出完整解析Stable Diffusion XL（SDXL）核心基础知识

8. 深入浅出完整解析Stable Diffusion（SD）核心基础知识

Rocky对Stable Diffusion 1.x-2.x系列模型的核心基础知识做了全面系统的梳理与解析：

深入浅出完整解析Stable Diffusion（SD）核心基础知识

9. 深入浅出完整解析Stable Diffusion中U-Net的前世今生与核心知识

Rocky对Stable Diffusion中最为关键的U-Net结构进行了深入浅出的全面解析，包括其在传统深度学习中的价值和在AIGC中的价值：

深入浅出完整解析Stable Diffusion中U-Net的前世今生与核心知识

10. 深入浅出完整解析LoRA（Low-Rank Adaptation）模型核心基础知识

对于AIGC时代中的“ResNet”——LoRA模型，Rocky进行了深入浅出的全面讲解：

深入浅出完整解析LoRA（Low-Rank Adaptation）模型核心基础知识

11. 深入浅出完整解析ControlNet核心基础知识

AIGC图像创作开源社区已经形成以Stable Difffusion/FLUX为核心，ConrtolNet和LoRA作为首要AI辅助工具的变化万千的AIGC图像创作工作流。

ControlNet正是让AI图像创作社区无比繁荣的关键一环，它让AIGC图像创作过程更加的可控，更有助于广泛地将AIGC算法解决方案应用到各行各业中：

深入浅出完整解析ControlNet核心基础知识

12. 深入浅出完整解析Sora、Seedance、keling等AI视频大模型核心基础知识

AI绘画和AI视频是两个互相促进、相互交融的领域，2024年无疑是AI视频领域的爆发之年，Rocky对AI视频领域核心的Sora、Seedance、Keling等大模型进行了全面系统的梳理与解析：

深入浅出完整解析Sora、Seedance、keling等AI视频大模型核心基础知识

13. 深入浅出完整解析AIGC时代Transformer核心基础知识

在AIGC时代中，Transformer为AI行业带来了深刻的变革。Transformer架构正在一步一步重构所有的AI技术方向，成为AI技术架构大一统与多模态整合的关键核心基座，大有一统“AI江湖”之势。Rocky也对Transformer模型进行持续的深入浅出梳理与解析：

深入浅出完整解析AIGC时代Transformer核心基础知识

14. 深入浅出完整解析ComfyUI、Diffusers、Stable Diffusion WebUI等主流AIGC创作框架核心基础知识

AIGC创作框架正是AIGC算法工作流的运行载体，目前主流的AIGC创作框架有ComfyUI、Diffusers、Stable Diffusion WebUI等。在传统深度学习时代，PyTorch、TensorFlow以及Caffe是传统深度学习模型的基础运行框架，到了AIGC时代，Rocky相信ComfyUI就是AIGC时代的“PyTorch”、Stable Diffusion WebUI就是AIGC时代的“TensorFlow”、Diffusers就是AIGC时代的“Caffe”：

深入浅出完整解析ComfyUI、Diffusers、Stable Diffusion WebUI等主流AIGC创作框架核心基础知识

15. 深入浅出完整解析ComfyUI、Diffusers、Stable Diffusion WebUI等主流AIGC创作框架核心基础知识

在AIGC时代中，如何快速转身，入局AIGC产业？如何成为AIGC/LLM/AI Agent算法/开发工程师？如何在学校中系统性学习AIGC/LLM/AI Agent知识，斩获心仪的AIGC/LLM/AI Agent算法/开发offer？

Don‘t worry，Rocky为大家总结整理了全面的AIGC/LLM/AI Agent算法/开发工程师成长秘籍，为大家答疑解惑，希望能给大家带来帮助：

手把手教你成为AIGC/LLM/AI Agent算法/开发工程师，斩获AIGC/LLM/AI Agent算法/开发offer！

16. AIGC产业的深度思考与分析

2023年3月21日，微软创始人比尔·盖茨在其博客文章《The Age of AI has begun》中表示，自从1980年首次看到图形用户界面（graphical user interface）以来，以OpenAI为代表的科技公司发布的AIGC模型是他所见过的最具革命性的技术进步。

Rocky也认为，AIGC及其生态，会成为AI行业重大变革的主导力量。AIGC会带来一个全新的红利期，未来随着AIGC的全面落地和深度商用，会深刻改变我们的工作、生活、学习以及交流方式，各行各业都将被重新定义，过程会非常有趣。

那么，在此基础上，我们该如何更好的审视AIGC的未来？我们该如何更好地拥抱AIGC引领的革新？Rocky准备从技术、产品、商业模式、长期主义等维度持续分享一些个人的核心思考与观点，希望能帮助各位读者对AIGC有一个全面的了解：

深入浅出全面解析AIGC时代核心价值与发展趋势（2025年版）

17. AI算法工程师的独孤九剑秘籍

为了方便大家实习、校招以及社招的面试准备，同时帮助大家提升扩展技术基本面，Rocky将符合大厂和AI独角兽价值的算法高频面试知识点撰写总结成《三年面试五年模拟》之独孤九剑秘籍:

【三年面试五年模拟】AIGC时代的算法工程师的求职面试秘籍（持续更新中）

18. 深入浅出完整解析AIGC时代中GAN（Generative Adversarial Network）系列模型核心基础知识

GAN系列模型作为传统深度学习时代的最热门生成式Al模型，在AIGC时代继续繁荣，作为Stable Diffusion/FLUX系列大模型的“得力助手”，广泛活跃于AlGC图像创作的产品与工作流中：

深入浅出完整解析AIGC时代中GAN（Generative Adversarial Network）系列模型核心基础知识