【2026 最新】AutoSaddler 是什麼？從失敗 Trace 修 Harness 的最小實驗

AutoSaddler 是什麼？簡單說，它是一套離線 mini-batch Harness 優化框架：先收集 Agent 的成功與失敗執行證據，診斷哪一層最值得改，產生受限的候選 Patch；matched train cases 先決定是否接受，accepted candidates 再由獨立 dev cases 排序。它不是讓 Agent 在正式環境裡想到什麼就改什麼。

這篇會先跑 Microsoft 官方 V2 免憑證範本，帶你讀 events.jsonl、候選版本與 result.json；再把這個玩具流程升級成有回歸案例、成本上限與人工核准的最小實驗。先說清楚：官方 fake template 的 observation 沒有真實 trace，能驗證的是管線與 artifact，不是完整重現論文的根因推理。

先說結論：自我改進的重點是驗收，不是自動改 Prompt

🧭 記憶把手：AutoSaddler ＝ 執行證據 ＋ 受限 Patch ＋ Train 接受 ＋ Dev 排序 ＋ 可回溯候選。

• 先診斷：錯誤答案只是症狀；要比較成功與失敗案例，找出 Prompt、Tool 或 Middleware 哪一層可修。
• 再產生候選：修改先落在新的 candidate，不直接覆蓋正式 Harness。
• Train 決定接受：同一批 matched-valid observations 的平均 score 必須嚴格上升，候選才進 accepted set。
• Dev 負責排序：accepted candidates 才跑獨立 dev cases，最後按 development mean score 選結果；dev 不是第二次 acceptance verdict。
• 最後才核准：正式導入前另跑安全、權限與產品回歸，人工看過 diff；研究流程的 selected 不等於 production 安全。

如果你還不熟悉 Harness，可先讀 AI Agent Harness 是什麼與 30 行 Harness 實作框架。AutoSaddler 處理的是下一個問題：Harness 已經會跑，但如何把一批失敗轉成可驗證、可回滾的改版。

AutoSaddler 是什麼？先把 Model 與 Harness 分開

本文依 AutoSaddler 論文的範圍，把可優化 Harness 限定為 system prompt、工具，以及 middleware／Agent loop；scenario 的資料分割與 evaluator 是外部驗收機制，不是 optimizer 可修改的元件。AutoSaddler 改的是前述 Harness 元件，不更新模型權重。這也是它和 Harnessed Agentic RL最容易混淆、也最重要的界線。

AutoSaddler 論文把問題設成離線、具監督訊號、任務彼此獨立的 mini-batch 優化。白話講，就是先拿一疊已完成且可評分的作業來改教學流程，而不是一邊服務真實使用者、一邊偷偷改規則。論文實驗使用早期 V1 路徑；截至 2026 年 8 月 27 日，官方 repository 的 quickstart 已以 V2 為主，因此本文只把論文用來解釋方法，不把 V2 smoke run 當成論文 benchmark 重現。

AutoSaddler 是什麼流程？五個階段看懂閉環

1. Evidence：成功與失敗都要留

只看失敗 trace，很容易把偶發工具錯誤誤判成 Prompt 問題。AutoSaddler 先把同一候選在一批 cases 的 observation 集合起來，包含 case、disposition、score、attempt 與成本等欄位；真實 adapter 還可把輸入、輸出與工具事件綁成 artifact。成功案例提供「哪些行為不要破壞」的對照。

2. Diagnosis–Patch：診斷和修改綁在結構化輸出

診斷結果受 schema 約束；本文 fake template 回傳 diagnosis 與 updates，Git-backed adapter 則可回傳 changed_paths，並以實際 workspace diff 表示修改。Patch 可落在三類：Prompt 負責行為指引；Tool 可調整描述、參數或實作能力；Middleware 可在工具呼叫前加入策略，或調整基礎設施與 Agent loop。結構化格式讓候選可以重放與比較，但不會自動保證修改正確。

3. Matched acceptance：先檢查同批平均分

新的 candidate 會先重跑參與診斷的 train cases。官方 V2 本機範本使用 matched_valid_strict_improvement：parent／child 在同一組 case 與 repetition 上配對，只取兩邊都有效的 observations，child 平均 score 嚴格高於 parent 才接受。這只能證明同批平均分上升，不能證明根因判斷正確，也不保證每一題都沒有退步。

4. Dev ranking：用沒參與修補的案例選結果

獨立 dev split 就像考完練習題後換一張小考卷。它不參與 diagnosis；候選先通過 train acceptance，才會執行完整 dev evaluation。V2 最後以 mean_development_score在 seed 與所有 train-accepted candidates 中選出結果。要特別注意：dev 變差不會撤銷候選的 accepted status，只可能讓 development ranking 選到分數更高的其他候選。更嚴謹的實驗還會把 test split 封住，直到策略與閾值都凍結才做一次最終估計。

5. Reflection 與 EvoDAG：留下教訓，也留下血緣

Reflection 把評估結果整理成 lesson；V2 的 evolution_dag.json保存候選父子關係、change、狀態與 dev 分數，元件來源／選擇理由留在事件與 history，lesson 另投影到 strategy/lessons.json。DAG 是有向無環圖，可以把它想成不允許時光倒流的家譜。這些 artifact 提供追查與重跑所需的版本證據；部署回滾仍要由外部流程實作。

最小實驗第 0 步：跑官方免憑證 V2 template

截至 2026 年 8 月 27 日，官方 README 列出的本機條件是 Git、uv 與 Python 3.12～3.14。以下固定到本文實際檢查的 repository commit；這能避免日後 quickstart 更新時，讀者以為跑的是同一份程式。

git clone https://github.com/microsoft/AutoSaddler.git
cd AutoSaddler
git checkout 30e20ce004486c58e7ee97c66182a8d0d41ec90e

uv sync --extra dev
uv run python -m autosaddler.v2.cli \
  --config configs/v2/local_template.yaml \
  --run-id local-template

這個 template 的 scenario 與 provider 都是 deterministic fake，不讀模型 API key，也不下載 benchmark dataset。它預先放入兩個 train case 與兩個 dev case，baseline 的 instruction 是 baseline，fake diagnosis 產生的新值是 improved。評分器只檢查字串是否等於 improved_text；所以 case 名稱即使改成「缺引用」或「未檢查指令」，也只是方便閱讀 artifact，並沒有真的讓 Agent 犯這兩種錯。

AlphaLab 實際跑到什麼？

我們在 2026 年 8 月 27 日以這個 commit 跑完一輪：baseline candidate 的 train observations 是 task failure，structured patch 只改 instruction，matched train 與 dev fake cases 隨後通過，result.json選出 child candidate。再次執行同一個 run-id後，事件檔與結果檔的 SHA-256 都維持不變，符合這個範本的 resume／deterministic 目的；另跑官方 fake plugin 與 resume fault 兩個窄測試也通過。

但這不是「AI 從真實失敗 trace 找到根因」的證據：fake observation 裡的 trace 是 null，修補答案也是 provider 預先決定。這份 smoke run 能支持的結論很窄：V2 的候選、驗證、事件與續跑管線可在本機走通。要評估診斷品質，必須接上真實 scenario、評分器與 provider。

最小實驗第 1 步：按順序讀四種 artifact

執行後先把輸出路徑存進變數；以下命令只讀取 artifact：

RUN='outputs/v2-template/local-template'
test -f "$RUN/result.json"

uv run python -m json.tool "$RUN/manifest.json"
uv run python -m json.tool "$RUN/result.json"
find "$RUN/candidates" -name candidate.json -print
wc -l "$RUN/events.jsonl"

1. manifest.json 與 resolved_config.yaml：先確認真正執行的 scenario、provider、budget、acceptance policy 與路徑；不要只相信你以為載入的原始 YAML。
2. evidence/ 與 evaluations/：從 case ID 回到 observation，確認哪些失敗被拿去診斷、matched rerun 是否真的用同一批案例。
3. candidates/ 與 evolution_dag.json：比較 parent／child 的元件值，再查 lineage。看到分數改善前，先問 diff 到底改了哪一層。
4. events.jsonl 與 result.json：前者是 append-only 事件軌跡，適合查 phase、attempt 與 resume；後者只是最後摘要，不能單獨解釋為什麼候選被接受。

你也可以把最後幾筆 event 展開，但範例程式只做讀取，省略了超大檔案的串流上限與錯誤回復；production 工具要加檔案大小、schema 與敏感資料檢查：

uv run python - <<'PY'
import json
from pathlib import Path

path = Path("outputs/v2-template/local-template/events.jsonl")
events = [json.loads(line) for line in path.read_text().splitlines()]
for event in events[-5:]:
    print(event.get("event_type"), event.get("operation_id"))
PY

如果你想把失敗變成可重跑案例，可沿用 AI Evals 的測資與評分設計：每個 case 固定輸入、允許工具、期望結果與硬性 invariants；不要只存一句「這次不好」。要追查 Agent 長流程，再配合 Agent 可觀測性把每次工具呼叫、延遲與錯誤串回同一條 trace。

最小實驗第 2 步：接真實 Harness 前先設五道 acceptance gate

真正的難點不是把 provider 換成能呼叫模型，而是先決定「什麼改動有資格進正式環境」。以下五道 gate 是本文建議加在 optimizer 外面的 production acceptance；它們不是目前 V2 的內建 dev ranking。規則盡量寫成機器可判斷，任何一道不過就停止，不自動合併。

1. 功能 Gate：原失敗案例必須改善，原成功案例不可退步；計分規則先凍結再看候選。
2. 獨立 Gate：dev cases 不參與 diagnosis，並包含同類但不同表面形式的問題；另設每題 hard floor 或非劣閾值，補上 mean ranking 可能掩蓋個別退步的缺口。這和 Specification-first convergence的精神相同：先寫驗收，再讓系統收斂。
3. 硬限制 Gate：禁止新增未核准網路目的地、擴權、讀 secrets、關閉驗證或改動評分器。即使總分上升，踩線仍直接淘汰。
4. 成本 Gate：在 config 固定 max_rollouts、max_iterations 與 diagnosis timeout；provider 還要另設金額、token、併發與 wall-time 上限。
5. 人工 Gate：reviewer 看 component diff、被修改的程式碼、工具權限、train／dev 明細與回滾點；核准後先進隔離環境或小流量 canary，不直接改 production。

最小安全單位不是「平均分增加」，而是一個可解釋的 candidate bundle：父版本、Patch、理由、受影響元件、每題 before／after、未通過案例、成本與雜湊都在。若團隊無法在幾分鐘內回答「為什麼留下它、怎麼退回去」，就還不該自動化合併。

六個容易踩的坑：看到分數變好先別興奮

1. 把 offline 誤解成不用網路：offline 指優化不在即時 production path。fake template 不需 key；真實 provider 仍可能呼叫外部 API。
2. 只餵失敗案例：沒有成功對照，系統可能修掉一個錯、破壞三個原本正常的行為。
3. 讓 dev 洩漏進 diagnosis：一旦看過答案，dev 就不再獨立；換一組封存案例。
4. 把 train 改善當 production 保證：研究 benchmark 的任務、評分器與權限邊界都可能不同，不能直接外推。
5. 忽略 artifact 的秘密：session、evaluation、工具參數、檔案路徑與 repository metadata 都可能含敏感資料。run directory 要最小權限、加密、設定保存期限，分享前先清查。
6. 允許修改評分器或安全閘門：這等於讓考生改考卷。優化 workspace、evaluator、dev/test 與 deploy credential 必須隔離。

想看另一種「先限制自主權，再逐步解鎖」的實作思路，可延伸閱讀 Prime Agent 的 Harness-first 方法。兩者角度不同，但共同點都是把成功條件與權限放在 Agent 外面。

AutoSaddler FAQ：新手先釐清的 8 題

1. AutoSaddler 會訓練或微調模型嗎？

不會更新模型權重。它優化的是 Harness 元件，例如 Prompt、Tool 與 Middleware；模型可作為提出診斷與 Patch 的 provider。

2. 它會在 production 自己越跑越強嗎？

不應這樣理解。官方論文設定是離線 mini-batch 優化；正式服務是否採用候選，應由額外回歸、人工核准與部署流程決定。

3. 免憑證 template 能測診斷品質嗎？

不能。它的 fake provider 預先回傳答案、observation 沒有真實 trace；它適合驗證安裝、artifact、acceptance 與 resume 管線。

4. Structured Patch 就代表安全嗎？

不代表。Schema 讓修改可驗證、可重放，卻不會替你判斷權限擴張、資料外洩或錯誤工具實作；仍要靠 allowlist、sandbox 與人工 review。

5. 為什麼要同時看成功與失敗 trace？

因為成功案例讓評估看見回歸。它幫你分辨「失敗特有的根因」和「所有案例都共有的正常行為」；若要任何一題退步就阻擋，還要另寫 per-case no-regression 規則，不能只看目前的平均分 policy。

6. Dev cases 要準備多少才夠？

樣本數要由風險、覆蓋與結果變異決定。先覆蓋高風險行為、常見變形與不可退步的成功路徑，再依錯誤成本與結果變異增加樣本；重點是獨立、可評分且不被 diagnosis 看見。

7. EvoDAG 會把多個 Patch 全部合併嗎？

不是無條件全併。V2 把候選血緣放在 DAG，把元件來源與選擇理由放在事件／history；演化仍受結構化輸出、評估與接受策略約束，每個新候選都要重新評估。

8. 第一個真實實驗該選什麼任務？

選低風險、可重跑、答案可機器驗的任務。例如隔離 repository 裡的格式修復或固定 API fixture；避開真實客戶資料、金流、部署權限與不可逆外部操作。

給新手的 7 個重點

1. AutoSaddler 改 Harness，不改模型權重。
2. Evidence 要包含成功與失敗，不能只看錯題。
3. Patch 先成為候選，不直接覆蓋正式版本。
4. Matched train 的配對有效 observation 平均分決定接受；獨立 dev mean score 負責最終排序，不是第二次 acceptance verdict。
5. 官方 fake template 是管線 smoke test，不是論文重現或真實診斷證據。
6. 成本、權限、資料與評分器都要放在 optimizer 控制範圍外。
7. 最終交付不是一個高分，而是一份可解釋、可重跑、可回滾的 candidate bundle。

完成這個最小實驗後，下一步不是立刻接昂貴 benchmark，而是先把自己的一個低風險失敗變成固定 fixture。若你需要從 Agent、工具與評估的基礎開始，AlphaLab 的 AI 實作課程可作為完整學習入口。