【2026 最新】AgentGrad 是什麼？5 步介入實驗找出該改哪個 Agent Prompt

你把 planner、worker、reviewer 串成一條多 Agent 流程，最後答案卻錯了。最直覺的做法，是把三份 Prompt 一起重寫；結果可能變好，卻沒人知道是哪一刀有效，也不知道下一批任務會不會一起壞掉。AgentGrad 要解的就是這個歸因難題。

2026 年 9 月公開的 AgentGrad v1 預印本，把 Prompt 優化拆成兩件事：先逐一介入 Agent，找出哪個單點修正足以讓整條流程過關；再把相似的自然語言修正意見聚在一起，每個候選一次只改一個 Agent 的 Prompt。這篇專為第一次除錯多 Agent 系統的讀者寫，會用一個可直接執行、但刻意簡化的三 Agent 玩具程式，帶你做完 train、held-out 與候選驗收。

先畫清界線：下文程式是 AlphaLab 的教學重建，使用手寫規則與精確比對，不是作者官方實作，也不是論文 benchmark 重現。你會學到可移植的實驗骨架，而不是拿到一個宣稱能直接複製論文分數的套件。

名稱也要分清楚：本文專指 Chu 等人在 arXiv:2609.08572 描述的方法；搜尋結果若出現其他同名產品，不能視為這篇論文的官方實作。

先說結論：AgentGrad 先找可修復點，再決定怎麼改

AgentGrad 的錨點公式是：可修復點 ＝ 一次只介入一個 Agent ＋ 觀察整體 reward 是否由失敗轉成功。

如果介入 worker 後整條流程過關，這筆失敗就先歸到 worker；接著比較同一輸入下 worker 的原輸出與介入後輸出，寫成一條 textual gradient（用自然語言描述 Prompt 應往哪裡改）。累積多筆後，將同義問題聚成一群，產生候選 Prompt；候選先過該群案例，再過 held-out 驗證，兩關都嚴格變好才接受。

這裡的「歸因」不是法醫式地證明最早肇因。它回答的是：目前哪個單一 Agent 的受引導行為，足以修復結果？如果 reviewer 也能補救上游錯誤，論文採用的倒序檢查可能先把案例歸給 reviewer。理解這個限制，才不會把可修復點誤寫成唯一根因。

為什麼一次改三份 Prompt，測完仍然不知道答案？

假設 planner 漏了截止日、worker 改壞票號大小寫、reviewer 又用了錯誤狀態字。你同時加上「保留所有欄位」「不要改 ID」「輸出必須合規」，train 成績上升了，但證據只告訴你這包變更有效。它沒有告訴你哪一條必要，也沒有隔離過度寬鬆的新規則。

這和改程式時一次提交三個模組很像：測試綠燈不等於你知道修正機制。多 Agent 更麻煩，因為上游輸出會改變下游輸入；只看最終答案，很容易把後果當成來源。想先補齊 trace、reward 與驗收觀念，可搭配 AI Evals 新手指南與 Agent Harness 是什麼。

AgentGrad 實作第 0 步：先凍結資料、reward 與 trace

痛點：如果每輪案例、模型或評分標準都在變，你無法判斷 Prompt 是否真的進步。解法是先凍結實驗契約。至少留下 sample_id、每個 Agent 的輸入與輸出、Prompt 版本、模型版本、token／延遲／費用，以及最終 reward。

1. train：用來發現失敗、生成修正方向。
2. held-out validation：其中案例從未送進 gradient extractor 或候選生成，只用來評估候選並決定接受或丟棄。
3. test：所有設計完成後才開封，用來報告最終結果，不能反過來調 Prompt。

reward 不一定要是模型評審。JSON schema、正確答案、工具呼叫成功、隱私遮罩是否完整，都可以先用 deterministic check。重點是成功條件要在改 Prompt 前寫好。若你還沒有可重播的 controller／worker 架構，可先照 30 行 Agent Harness 實作把每一步輸出保存下來。

AgentGrad 實作第 1 步：只收集真的失敗案例

解法是先建立 failure set。論文只讓 reward < max_reward 的失敗案例進入介入與 gradient extraction；對固定 train 跑目前 Prompt 組合，每個優化回合都重新建立一次。

failures = [x for x in train if reward(run(x, prompts)) < max_reward]
unresolved = failures.copy()

論文裡當輪介入仍無法修好的 hard case 會先排除，但不是永久刪掉；下一輪 Prompt 已更新後，它會再次進入 failure set。你的實作也要保留這個重試語意，否則最難的問題會悄悄從報表消失。

AgentGrad 實作第 2 步：從下游往上游，單次只介入一個 Agent

痛點：只讀 trace 仍可能把責任猜錯。解法是做 sequential intervention。依執行順序的反方向，先 reviewer、再 worker、最後 planner；每次只在一個 Agent 的現有 Prompt 後加入 training-only hint，其餘 Prompt 不動，再重跑尚未解決的案例。

for agent in reversed(agents):
    corrected = replay(unresolved, intervene_only=agent, hint=ground_truth_constraints)
    targets[agent] = cases_whose_reward_reaches_max(corrected)
    unresolved -= targets[agent]

hint 可以由 ground truth 或最終輸出限制，加上資料集、流程與角色描述組成；在原論文中只供訓練介入，正式推論使用的是更新後 Prompt，不攜帶 hint。實務上還要把 hint、模型隨機性與重跑次數寫進紀錄；一次採樣從失敗變成功，只能說它是候選可修復點。

AgentGrad 實作第 3 步：把前後差異寫成 textual gradient

痛點：「答案錯了，請改善」太粗，無法告訴 planner 或 worker 應改哪種行為。解法是比較同一個 Agent、同一份輸入下的兩個中間輸出。原輸出是 y_bad，介入後讓全流程過關的輸出是 y_hint；請 gradient extractor 只描述兩者之間可泛化的行為差。

gradient = critique(
  prompt=current_prompt,
  same_input=agent_input,
  original_output=y_bad,
  intervention_output=y_hint
)

例如不要寫「SEC-7 要改回大寫」，而要寫「所有識別碼必須逐字保留，禁止大小寫正規化」。前者記住一題，後者才可能成為 Prompt 規則。這種自然語言回饋與 TextGrad 使用的 textual gradient 同屬一個大方向；AgentGrad 的差異，是先用介入替這條回饋找到 Agent 級 pseudo-label。

AgentGrad 實作第 4 步：先按語意聚類，不要把所有抱怨黏成一條規則

痛點：「保留票號」「不要洩露姓名」「數學要驗算」放在同一個 batch，optimizer 很容易產生又長又互相干擾的 Prompt。解法是 semantic textual gradient abstraction。先把共享修正模式的 gradient 分成 semantic minibatch，再為每群抽象成一條 generalized gradient。

入門版可以用 embedding＋分群，也可以先讓一個 LLM 同時完成分群與摘要，但輸出必須保留 cluster_id、成員 sample、共同規則與例外。論文讓 aggregator LLM 對每個 Agent 的 Ωⁿ 分別在一次呼叫中完成分群與摘要；群數 Mₙ 由 LLM 決定，另以循環的 cluster-size 軟性下限（例如 5→3→1→5）調整抽象粒度。

AgentGrad 實作第 5 步：候選 Prompt 要連過兩關，否則丟棄

痛點：某群案例變好，可能只是 Prompt 記住那幾題。解法是 cluster gate 加 validation gate。依群大小由大到小測候選，每次只替換目標 Agent 的 Prompt；先要求該 semantic minibatch 的 reward 嚴格提高，再要求完整 validation 也嚴格提高，才寫入新版本。

if cluster_score(candidate) > cluster_score(current):
    if validation_score(candidate) > validation_score(current):
        accept(candidate)
    else:
        discard(candidate)  # retain current prompt

這裡要忠於論文：原演算法用的是嚴格提高，不是「持平也收」。生產環境可再加成本、p95 延遲、schema 合規、資安與重複採樣信賴區間，但這些是工程擴充，不能倒寫成論文原本就有。想看更完整的 Prompt A/B 驗收，可延伸到 Agent Skill Routing A/B 測試。

可執行簡化版：三個錯誤，三輪角色介入

AlphaLab 的 agentgrad_toy.py 完全不呼叫 LLM。三個 train case 分別植入 reviewer 狀態字、worker 票號大小寫、planner owner 遺失；四個 held-out case 包含三個同模式新樣本，以及缺截止日必須阻擋的回歸樣本。執行：

python3 agentgrad_toy.py

"""Teaching reconstruction, not official AgentGrad code."""

ROLES = ("reviewer", "worker", "planner")
TRAIN = (("overdue-status", "reviewer"),
         ("billing-id", "worker"),
         ("security-owner", "planner"))
VALIDATION = (("overdue-status-2", "reviewer"),
              ("billing-id-2", "worker"),
              ("security-owner-2", "planner"),
              ("missing-deadline", "regression"))

def passed(case, prompts):
    _, fault = case
    if fault == "regression":
        return prompts["reviewer"] != "all-at-once"
    return prompts[fault] == "v1" or (
        fault == "reviewer" and prompts[fault] == "all-at-once")

def score(cases, prompts):
    return sum(passed(case, prompts) for case in cases)

def sequential():
    prompts = {role: "v0" for role in ROLES}
    unresolved, trace = list(TRAIN), []
    for role in ROLES:
        candidate = {**prompts, role: "v1"}
        fixed = [case for case in unresolved
                 if not passed(case, prompts)
                 and passed(case, candidate)]
        if (score(TRAIN, candidate) > score(TRAIN, prompts)
                and score(VALIDATION, candidate)
                    > score(VALIDATION, prompts)):
            trace += [f"{name}: target={role}" for name, _ in fixed]
            prompts = candidate
            unresolved = [case for case in unresolved if case not in fixed]
    return prompts, trace

baseline = {role: "v0" for role in ROLES}
all_at_once = {"reviewer": "all-at-once",
               "worker": "v1", "planner": "v1"}
optimized, trace = sequential()

for label, prompts in (("baseline", baseline),
                       ("all-at-once", all_at_once),
                       ("sequential", optimized)):
    print(label, f"train={score(TRAIN, prompts)}/3",
          f"held-out={score(VALIDATION, prompts)}/4")
print(*trace, sep="\n")

控制組一次重寫三個角色，恰好修完 train，卻因一條過度寬鬆的 reviewer 規則，讓缺截止日的 held-out 案例錯誤通過。逐一介入版依 reviewer → worker → planner 找到三個可修復點。三個預寫的安全候選都同時提高 train 與 held-out，因此全部接受，這次執行沒有實際觸發候選丟棄；一次全改是獨立控制組，不是被 sequential gate 拒絕的候選。上圖摘要呈現三組分數與介入順序；它證明的是程式控制流符合我們的教學設計，不是證明任何真實 LLM 一定有同樣表現。

這個 toy 把 training-only hint、gradient／aggregation 與 optimizer 折成預寫的 v1，用完整 TRAIN 代替 semantic minibatch gate，且每輪角色後立即驗收；Algorithm 1 則先在固定 Prompt 上完成所有倒序介入與 gradient extraction，再逐 Agent 聚類和更新。

要換成真實模型，還需實作 training-only hint／replay、gradient extractor、逐 Agent aggregator、prompt optimizer、rollout budget、雙階段評估與版本化 log；不能只替換三個函式。若工作流有分支、重試或工具呼叫，可參考 Controller／Worker 評估方法，先定義同一案例如何重播，否則「只改一個 Agent」在實際執行中不成立。

論文成績怎麼讀：有潛力，但不是跨設定保證

AgentGrad 論文比較 no optimization、MIPROv2、TextGrad 與 GEPA，涵蓋多跳問答、事實驗證、隱私代理、指令遵循與數學推理五類多 Agent benchmark，並分別使用 GPT-5-mini 與 Qwen3-8B。作者報告的結果與 wall-clock 明細整理在下圖。

最保守的讀法是：這套「先定位、再聚類」的設計在作者設定下值得進一步驗證；它不是對任何 Agent 拓樸、模型或 reward 都成立的性能保證。預印本仍可能修訂，且推論 API 的隨機性、價格與延遲會改變實務結果。你的決策依據仍應是自己的 held-out 任務與成本帳，而不是只搬論文平均值。

重現邊界也很實際：v1 公開 source bundle 未附完整 optimizer hyperparameters、rollout-budget 設定或 implementation appendix，因此目前無法獨立重現論文各方法的公平比較條件。

AgentGrad 最常踩的 6 個坑

1. 把可修復點叫成唯一肇因：多個 Agent 可能都能補救；保留測試順序與首個命中。若要找其他可修復點，需改變順序或在首個成功後繼續測，不要過度解讀第一個命中者。
2. 介入時順便換模型：Prompt、temperature、工具與模型版本必須固定，否則變因不只一個。
3. 讓 validation 洩漏進 gradient：validation 可反覆回傳整體分數做接受／拒絕；若把案例內容或錯誤回饋送回 optimizer 才構成方向洩漏，最終報告另留一次性 test。
4. 聚類後丟掉成員：每條 generalized gradient 都要能追回原 sample，才能發現不相干錯誤被誤併。
5. 只看平均 reward：同步記錄分群成功率、最差案例、token、延遲與 schema／安全 gate；平均提升可能遮住高風險回歸。
6. 沒有版本化回滾：把 agent_name、舊／新 Prompt、cluster、兩關分數與 commit 寫進同一筆變更紀錄。

放進真實流程前，再加一層安全與成本閘門

AgentGrad 的論文 gate 只比較任務 reward；真實系統不能就此自動部署。先把 trace、ground truth 與 hint 當成不可信資料：移除姓名、帳號與祕密；用結構化欄位和明確 delimiter 包住；optimizer 不給外部工具與寫入權；也不要要求或保存隱藏 chain-of-thought，只留可觀察的輸入、輸出與評分。

• 安全：候選不得抄入單一答案、私人資料、繞過詞或擴大 Agent 權限。
• 成本：分開記錄 intervention、gradient、aggregation、validation 的 model call、token、延遲與當日價格。
• 穩健：隨機模型用配對重跑或信賴區間，避免把一次幸運採樣當修正。
• 發布：先存成待審 Prompt 版本；paper gate、固定 regression set 與預算線都過，再由人核准。

這些是 AlphaLab 建議的 production extension，不是 AgentGrad Algorithm 1 已經提供的功能。介入最壞情況還要讓每筆失敗逐 Agent 重跑；團隊應先訂 rollout budget，否則精準歸因本身可能比手動檢查更貴。

FAQ：AgentGrad 新手最常問的 8 題

1. AgentGrad 是模型、Agent framework，還是 optimizer？

它是多 Agent Prompt optimizer 的方法。它不取代 planner、worker 或 reviewer，而是在訓練／開發階段決定先改哪個角色的 Prompt，以及用哪些失敗模式產生候選更新。

2. AgentGrad 真的能找到「肇事 Agent」嗎？

它找到的是單點介入可修復的位置，不保證唯一結構根因。下游 Agent 可能補救上游錯誤；倒序先命中誰，也會影響案例歸屬。若要做更強的因果結論，需另加多順序、重複採樣與交互介入。

3. 為什麼要從最後一個 Agent 往前測？

這是論文為了降低預期介入次數採用的順序。作者表示其觀察中失敗較集中在後段；這是研究設定的經驗選擇，不是所有系統的定律。你的 trace 若顯示上游更常錯，可以把測試順序列為實驗變因。

4. textual gradient 是真的數值梯度嗎？

不是。它是自然語言形式的修正方向，例如「識別碼必須逐字保留」。名字借用梯度的更新直覺，但 Prompt 本身不需要可微分。

5. 沒有 ground truth 還能用嗎？

可以從可驗證限制開始。例如 JSON schema、工具執行結果、引用存在、敏感資料不得出現。若 reward 只是另一個 LLM 的主觀偏好，應保存 rubric、評審模型版本並抽樣人工複核。

6. 一定要用 LLM 做語意聚類嗎？

照論文演算法需要 aggregator LLM。人工標籤或 embedding clustering 是工程替代版，不是原法重現；不論採哪種替代，都要檢查群內是否共享同一修正模式，並保存成員與抽象規則的對應。

7. AgentGrad 和 DSPy、TextGrad、GEPA 是互斥選項嗎？

概念上不必互斥。DSPy optimizers、TextGrad 與 GEPA提供不同的候選生成與搜尋抽象；AgentGrad 的核心價值在多 Agent 的目標定位與語意梯度整理。真正整合仍要自己定義 adapter、budget 與驗收。

8. 哪裡可以拿到本文的可執行程式？

先複製上方完整玩具程式。它只是 deterministic gate skeleton；把 passed() 接上 harness replay 後，仍需另補 hint、gradient、逐 Agent aggregation 與 candidate generation。截至 2026 年 9 月 14 日，本文核對的 arXiv v1 摘要／TeX source、Hugging Face paper page、第一作者網站與 GitHub profile，均未顯示作者指定的 AgentGrad implementation／project link；這是有界快照，不代表日後不會發布。若出現作者 repo，應以作者頁或論文修訂連結交叉確認。

給新手的 5 個重點

• 不要先改 Prompt；先凍結案例、reward、模型設定與 trace。
• 一次只介入一個 Agent，問它能否讓最終 reward 達標。
• 比較同一輸入的原／介入後中間輸出，才有局部修正訊號。
• 相似 textual gradients 才放同一群，每群只產生一個可追溯候選。
• cluster 與 held-out 兩關都嚴格改善才接受，否則丟棄候選、保留目前 Prompt。