SKILL.state 深度解析：倉儲測試少 93.8% Token，代價是什麼？（2026）

2026 年 8 月 26 日，Sanket Badhe、Jonghyun Chung（Google LLC）與 Priyanka Tiwari（Purdue University）在 arXiv 發表〈SKILL.state: Scalable Long-Horizon Agent Skills〉。這篇 SKILL.state 研究提出一個直覺很強的改寫：長時間運作的 Agent，不必每一步都把完整對話重讀一次；它可以只帶著一份可更新的結構化狀態，以及最新觀察繼續工作。

真正值得注意的，不只是作者在自建倉儲測試裡報告「少用 93.84% token」。更重要的是，它把 Agent 的記憶問題重新切成兩件事：下一步需要知道什麼，以及事後需要保留什麼證據。前者可以很短，後者卻不該跟著消失。

全文精華：94% 的表內算術成立，但邊界很窄

• 核心機制：每一步只輸入固定 skill 規格、目前 execution state、最新 observation；模型輸出動作與 JSON dictionary patch，作者設計會拒絕格式或 schema 不合規的 patch，再更新狀態。
• 最亮眼數字：作者自建的 SkillExecBench 倉儲任務在 horizon T=100 時，SKILL.state 報告 65,408 token、score 0.94；作者的 stateful、LangGraph-style 全歷史 baseline 為 1,062,387 token、score 0.91。
• 公開 benchmark：InterCode CTF 與 τ-Bench Airline 的 token 降幅很大，但 τ-Bench Retail 對 stateful baseline 只少 11.48%，不能概括成「公開測試都省 40–66%」。
• 最關鍵風險：schema 驗證能攔住欄位或 JSON 錯誤，不能證明模型沒有忘記一條語意上重要的限制。
• 實務結論：把精簡 state 放進 prompt，把 append-only event log 與 checkpoints 留在 prompt 外；state 是工作記憶，不是稽核紀錄的替代品。

為什麼這篇論文突然引爆討論？

採 full-history runtime 時，Agent 一旦跑到數十、數百步，完整 transcript 會反覆被送進模型：第 1 步的內容出現在第 2 步、第 3 步，直到最後一步。這不只增加 token，也讓舊觀察、已完成推理與現在真正需要的限制混在一起。論文把問題描述為 context degradation 與 context poisoning，正好命中長任務常見的成本與可靠性焦慮。

話題也受到社群放大。提供的 r/artificial 討論串在 2026 年 8 月 31 日查得 855 分、89 則留言；留言很快把問題推向兩個要害：prompt caching 會不會改變成本結論，以及 state 若沒有寫進某項資訊，是否會造成無聲遺失。兩個疑問都合理，但要先看清作者實際改了什麼。

SKILL.state 到底怎麼運作？

“At each execution step, the model receives only the immutable skill specification, the current structured execution state, and the latest observation.”

意思是：每次執行時，模型只看到不變的技能規格、當前結構化狀態與最新觀察。模型做完短暫推理後，產生下一個 action，並提出一個 state update；按論文設計，runtime 會拒絕 malformed 或 schema-invalid state patch，再把合規的新狀態帶到下一步。先前的 observation 與 reasoning 不再逐步堆進 prompt。

這很像倉庫交班。新班次不需要聽完上一班每一句對話，只需要目前庫位、未完成訂單、已鎖定貨架與待處理異常。然而，交班表能否取代監視器、掃碼紀錄與責任軌跡？不能。交班表是足以繼續操作的摘要；事件紀錄則回答「先前到底發生了什麼」。

93.84% token 降幅，精確來自哪裡？

最常被轉貼的數字來自作者建立的 SkillExecBench warehouse management 任務。環境包含 500 個貨架、收貨、訂單與維護事件，以及 Store、Ship、Move、Wait actions；無效 action 會回傳錯誤。作者稱使用 Gemini-3-Flash，並以 5 個程序生成器 seed 報告平均值與 sample standard deviation。

以表中平均值重算，SKILL.state 使用 baseline 的 6.16% token，降幅是 93.84%，baseline 用量則是它的 16.24 倍。這個算術沒有問題；問題在於如何描述它。

• 它是作者自建的合成環境，不是所有長任務的平均節省率。
• T=100 是環境 horizon，不宜直接寫成「100 次模型呼叫」；表中的總 token 與平均 prompt 也無法直接和 T=100 對齊，v1 沒有完整交代事件、模型呼叫、output、retry 與 token accounting 的對應。
• score 是可行動事件中有效正確 action 的比率，不是「整個任務成功率」。
• 作者報告 5 個 seed，但 v1 沒附原始 run、逐步 trace、完整 seed 清單、model snapshot 或 tokenizer accounting；因此只能說「作者報告」，不能寫成 AlphaLab 已重現。

公開 benchmark 有進步，但不是一律省 40–66%

論文也測了 100 題 InterCode CTF，以及 Sierra τ-Bench 的 Retail、Airline。SKILL.state 在作者表 4 的三組 pass rate 都最高：54.2%、58.3%、32.4%。但 token 降幅因任務與比較對象差異很大。

任務	對 ReAct 的 token 降幅	對 stateful baseline 的降幅
InterCode CTF	60.39%	65.75%
τ-Bench Retail	22.54%	11.48%
τ-Bench Airline	40.62%	45.45%

Retail 還有一個容易被總 token 掩蓋的反例：SKILL.state 的平均 prompt 是 3,325 token，反而高於 ReAct 的 2,819、Memory 的 2,737 與 stateful baseline 的 3,065。也就是說，它在這組任務降低了累計 token，卻沒有降低單步平均 prompt；「所有公開 benchmark 都縮小 prompt」與作者自己的表格不相容。

公開數字的 denominator 也沒有完整披露。InterCode 被寫成 100 tasks，單次二元結果原本只會產生整數百分比，但表中出現一位小數；τ-Bench 也沒有列 trial 數、失敗重試與 aggregation 方式。這些小數可能來自多次 run，卻需要作者的 task-level results 才能核對。

還有一個版本問題。論文 v1 沒列出 τ-Bench 的 commit 或 task 版本；目前 τ-Bench 官方 repository已提醒原始任務過時，並指向後續修正版。這不會自動推翻作者結果，卻代表讀者無法從論文判斷所用任務是否包含後續修正。公開 benchmark 應視為有方向性的作者證據，而不是封案。

這項研究最有力的部分：同 token 預算仍保住狀態

若只是把歷史截短，token 當然會下降；真正的問題是任務會不會一起壞掉。作者因此把倉儲 T=100 的 prompt budget 控制在約 1,800 token，比較 sliding window、summary-capped、LLMLingua 與 SKILL.state。

這組對照支持一個比「壓縮更厲害」更精確的說法：對程序化、schema 可預先定義的任務，把關鍵事實放進有型別的 state，可能比按字數截斷或生成自由文字摘要更穩。它把要保留的欄位先變成設計問題，而不是每一步讓模型臨場猜哪些句子重要。

四個不能被 94% 蓋掉的限制

1. 「驗證過的 state」不等於語意正確

按論文設計，runtime 會拒絕 malformed 或 schema-invalid state patch，並可 rollback/retry。這能抓到不存在的欄位或型別錯誤，卻無法證明模型沒有漏寫「不要移動這批貨」之類的重要限制。在 Gemma-4-31B、T=100、score 0.42 的 failure logs 中，作者把 68% 分為過早覆寫或刪除，顯示 state loss 至少在這組失敗樣本裡是核心問題。

2. LangGraph-style baseline 不是 LangGraph 的必然用法

作者的 comparator 把結構化 state 與完整 history 一起塞回 prompt，稱為「Stateful (LangGraph-style)」。但 LangGraph 官方文件讓開發者自行定義 State 與 reducers，也支援 checkpoint 與歷史查詢，並沒有要求每次模型呼叫都帶上完整 transcript。論文沒有提供 package version、graph configuration 或 runtime code，因此這組數字不能被改寫成「SKILL.state 比 LangGraph 省 94%」。

3. O(1) 是有條件的

論文把單步 prompt 寫成 O(|P|+|Σ|+|O|)。只有當 skill 規格 P、state Σ 與最新 observation O 的序列化長度都不隨 horizon 成長時，才可相對於 T 稱為 O(1)。如果 state 裡放入不斷增長的清單、自由文字摘要或證據全文，二次方累積仍可能回來。真正需要限制的是值的大小，不只是 schema 的欄位數。

4. Token 不等於帳單，也不等於延遲

Gemini context caching 可能降低重複 prefix 的實際費用與延遲；論文則報告 token totals，沒有列 cache 設定、cache hit、美元成本或端到端 latency，也未給出可核對的 Gemini-3-Flash API snapshot。因此 93.84% raw-token reduction 不能直接翻譯成 93.84% 成本或速度改善。

AlphaLab 判斷：正確方向是「短 state、長 log」

SKILL.state 最有價值的地方，不是宣告 transcript 已經過時，而是把工作記憶從聊天紀錄中獨立出來。Agent 的下一步決策，確實應優先讀一份最小、明確、可驗證的 canonical state；否則它每次都像把整個專案 Slack 從第一天重讀一遍。

但生產系統還需要另一條不進 active prompt 的 append-only log。它保留 observation、tool call、state patch、驗證結果、模型與 prompt 版本，供稽核、除錯、回放與復原。當 state 遺漏資訊時，系統應能沿 provenance pointer 找回原事件，而不是只剩模型改寫後的一份「現在看起來如此」。

層	放什麼	主要用途
Active state	目標、未完成步驟、硬限制、資源、版本號、證據指標	每一步最小決策上下文
Append-only event log	觀察、工具呼叫、patch、驗證結果、action receipt	稽核、除錯、重播
Checkpoint	特定版本的完整 state snapshot	故障復原、分支測試
Invariant gate	跨欄位規則、權限、數量守恆、樂觀鎖	補上 schema 驗證抓不到的語意約束

如果你要實作，先做這六件事

1. 先選對任務：從流程清楚、狀態欄位可預先枚舉、工具輸出可界定的程序化工作開始；研究探索或需求持續變動的任務，不適合一開始就丟掉歷史。
2. 把不可遺失的限制做成一等欄位：例如 goals、invariants、unresolved constraints、permissions、action receipts，不要全塞進一個 summary 字串。
3. 每個 state 帶版本與 provenance pointer：採 optimistic concurrency；patch 必須聲明讀到哪一版，重要值能追回原始 event。
4. 把 log 留在 prompt 外：正常步驟只讀 state；出現矛盾、低信心、人工抽查或復原時，再按需檢索歷史證據。
5. 做失敗注入：刻意刪掉限制、送入過期 patch、重複工具回覆、讓 summary 膨脹，確認 invariant gate 會阻擋而不是安靜前進。
6. 用 cache-aware all-in 成本比較：同時記 input/output/cached token、retry 次數、延遲、錯誤恢復與人工介入；不要只比 raw prompt token。