SKILL.state：省 Token 的
Agent 执行架构（复现实测）

这套东西没有需要"安装"的部分。它不是框架也不是库，就是一条 prompt 构造规则加一个字典合并函数。只需要一个能跑 chat completion 的模型。

export BIGMODEL_API_KEY=你的key

这次用智谱 BigModel 的 GLM 系列（glm-4.5-flash），因为 OpenRouter 上调 Gemini 被 provider ToS 403 拦了。

GLM 系列默认开推理，content 字段会是空字符串——全部内容跑到 reasoning_content 里去了。请求体里必须显式关掉，否则动作解析全部拿到空值：

{"thinking": {"type": "disabled"}}

免费档并发一高就 429，而失败调用如果返回空串，会被打分函数判成"答错"——最后拿到的是一张漂亮但完全错误的准确率表。第一次跑的时候我就吃了这个亏。处理方式：

_throttle = threading.Semaphore(2)      # 全局限并发
_last = [0.0]
def _pace(min_gap=1.2):                 # 全局最小请求间隔
    with _lock:
        wait = _last[0] + min_gap - time.time()
        if wait > 0: time.sleep(wait)
        _last[0] = time.time()
# retries=12，指数退避；硬失败次数单独统计打印

wrote results.jsonl (354 LLM calls, 0 hard failures)

对比的公平性全靠这一点：四个 runtime 拿到的 skill.instructions 完全一样，事件序列由同一个 seed 生成，唯一的自变量就是上下文管理方式。以下模板逐字来自论文 Appendix A（论文明确说 "exactly as they were dynamically constructed"）。

A.1 Prompt（ReAct 式）—— 追加全部历史

Instructions:
{skill.instructions}

History:
Observation: {history[0].observation}
Reasoning & Action: {history[0].response}
[... 追加所有历史 observation 和 action ...]

Latest Observation: {observation}

Generate your next reasoning and action (format 'Action: <cmd>'):

A.2 Memory（摘要式）—— 滚动 3 步窗口 + 周期性摘要

把上面的 History: 换成 Summarized History: + Recent History:（只保留最近 3 轮）。

A.3 Stateful（LangGraph 式）—— 结构化 state + 完整历史

注意它同时有结构化 state 和完整历史，这是它和 SKILL.state 唯一的区别，也是论文要证的点：

Instructions:
{skill.instructions}

Current State:
{json.dumps(state, indent=2)}

History:
[... 依然追加所有历史 ...]

Latest Observation: {observation}

Update the state if necessary, provide reasoning, and output 'Action: <cmd>'.
To update state, use the format: StateUpdate: {"key": "value"}

A.4 SKILL.state —— 没有 History 这一节

Instructions:
{skill.instructions}

Skill Execution State:
```json
{json.dumps(state, separators=(',', ':'))}
```

Latest Observation: {observation}

Provide your response with:
1. Step-by-step reasoning (will be discarded after execution)
2. A JSON block fenced with ```json ... ``` containing both your State Patch and your Action.
   The JSON block MUST have exactly these two keys:
   { "state_patch": { <dict: your state updates, set keys to null to delete> },
     "action": "<string: the exact command you want to execute>" }

三个细节值得注意：

• state 用 separators=(',', ':') 序列化，不缩进——省的就是这点空格。
• prompt 里明写 "will be discarded after execution"。模型知道自己的推理不会被保留，才会主动把该留的东西写进 state_patch。
• schema 归 runtime 管，不归模型管。模型只是"提议"一个补丁，合法性由确定性代码校验；非法补丁不落库，触发回滚重试。

def merge_patch(state, patch):
    for k, v in (patch or {}).items():
        if v is None:
            state.pop(k, None)
        elif isinstance(v, dict) and isinstance(state.get(k), dict):
            merge_patch(state[k], v)
        else:
            state[k] = v
    return state

Warehouse Management（论文 Appendix B.1 Environment 1）：500 个货架，每架最多一件货。动作空间 Store / Ship / Move / Wait。事件有三类：

打分 = 成功动作数 / 可动作事件数。往占用的货架上 Store、从错误的货架 Ship、Move 不存在的货，都算失败。

这个环境的巧妙之处在于：它逼着 agent 维护 500 个互不重叠的状态变量，而早期的 observation 会随着 horizon 增长滑出上下文窗口。不记住 item_12 放在 shelf_42，后面接到订单就必然出错。

1 · 它把成本从输入侧挪到了输出侧

SKILL.state 的输出 token 是 ReAct 的近两倍——因为它每一步都要额外生成一份 state_patch JSON。而多数模型的 output 定价是 input 的 3–5 倍。按 4× 折算成"输入等价 token"：ReAct ≈ 303k，SKILL.state ≈ 94k，仍然领先 3.2×，但不是表面上的 7.1×。报价的时候别只看 total tokens。

2 · 准确率：持平，没有超越

三个 horizon 上 SKILL.state 的得分都等于当轮最好的 baseline（0.70 / 0.72 / 0.60），一次都没超过。论文声称的是 "improves task accuracy"，这一轮只复现出"不降低"。倾向于认为这是模型能力的差异：论文用 Gemini-3-Flash 在 T=100 拿到 0.94，而 glm-4.5-flash 在 T=50 已经掉到 0.60。基础能力不足以稳定执行时，上下文管理方式带来的边际收益会被噪声淹没。

3 · O(1) 的隐藏前提：状态本身要有界

记录了每一步 Σ_t 里 inventory 的条目数，整个 T=50 过程中它在 1 到 5 之间波动——因为 Ship 事件会把货从架上拿走，库存不是单调增长的。SKILL.state 的 O(1) 成立的前提是 state 本身有界。如果任务里状态只增不减（比如爬虫累积 URL、调查类 agent 累积证据），|Σ_t| 会随 t 增长，prompt 也就跟着涨，只是常数比全历史小而已。

4 · 结构化输出的可靠性比预期好

论文 §5.7 给了开源模型的错误分布：Gemma-4-31B 在 T=100 上，68% 的错误是"更新 state 时误删了已有 key"。这轮 glm-4.5-flash 在 T=10/25/50 三个 horizon 上的非法 patch 数都是 0——85 步、每步一个 JSON 块，全部解析成功且结构合法。说明论文这条结论对模型代际比较敏感，但确定性校验层还是要写，代价接近零。

论文 §7 Limitations 给了三个明确的失效场景，这是全文最该先读的一节：

1. schema 无法预先确定，状态结构必须在执行中动态发现——这时不知道该往 Σ 里投影什么。
2. 正确的状态更新依赖某条早期 observation，而它当时的相关性没被识别出来——没投影进去，就永久丢了。这是 SKILL.state 最本质的风险：它是有损的，损失点在"当时没意识到重要"。
3. 任务目标本身就定义在历史轨迹上——审计、调试溯源、解释过去的动作。这类任务里交互历史是产出物，不是开销。

加上实测得到的两条：

4. 步数不到几十步，收益抵不上改造成本（T=10 只省 3%）。
5. 状态单调增长的任务，O(1) 不成立。

反过来，最适合的场景是：长流程、状态可 schema 化、动作有明确成败反馈的执行类任务——论文选的仓库管理、Git 仓库操作、CTF、客服工单都是这个模子。

不需要换框架，四步：

不要按任务写。问自己："下一步决策需要知道什么？"只留这些字段。论文的 CTF schema 只有 5 个字段。

删掉 History:，换成 Skill Execution State: + Latest Observation:。这是唯一必须改的地方。

每步输出 {"state_patch": ..., "action": ...}，并在 prompt 里明说推理会被丢弃。这句话是有效的——模型知道推理不留存，才会主动往 state 里写。

校验不通过就丢弃补丁、重试当前步，绝不把畸形输出写进持久状态。schema 的所有权在代码这一侧，不在模型那一侧——这是整个架构安全性的来源。