改 agent 的 prompt 是最日常不過的事：一句話收緊、換一個模型、調一下檢索參數。麻煩在於這些改動沒有任何程式碼 diff，傳統測試完全看不到，而壞掉的地方往往不是報錯，而是一個本來會準確引用退款政策的 agent，突然開始憑記憶改寫它。OpenRouter 在 2026 年 9 月 30 日發表的教學，講的正是怎麼把這件事變成可驗證的流程。
Agent 迴歸測試為什麼不能照抄程式測試
程式迴歸測試有三個假設：輸入固定、正確輸出固定、diff 能告訴你哪裡變了。OpenRouter 指出 agent 一次打破了全部。
首先，兩個都正確的答案，文字上幾乎不會一樣，拿 golden answer 做字串比對只會誤報。真正穩定的是結構：agent 有沒有呼叫對的 tool、參數對不對、有沒有遵守政策。其次，模型本身是會動的零件——用 ~family-latest 這類 alias 選模型，倉庫裡一個 commit 都沒有，推理的那一層卻已經換人了。第三，每一次 baseline 移動，舊的通過紀錄就過期了。
鎖住的案例集，加上一份行為合約
OpenRouter 的建議是先建一套案例集：覆蓋最常見的請求、幾個邊界情況（模糊輸入、貼著政策的請求），至少一條專門測「永遠不可以發生的事」。以客服 agent 來說，就是一般退款、沒有訂單編號的請求、以及超過授權額度的退款。
關鍵紀律是：案例集一旦定下來就鎖住。改寫、增刪任何一個案例，都等於和過去所有 run 失去可比性。OpenRouter 用了一個很好的類比——把它當成 schema migration 那樣對待。
每個案例寫兩件事：結構斷言（應該呼叫什麼 tool），以及硬性不變量（絕不可以做什麼，例如超過 500 美元的退款必須轉人工）。前者多數案例都該有；後者是唯一的自動擋發佈條件，不留裁量空間。
換模型時，只動一個變數
模型替換是這份教學著墨最多的場景。原則很簡單：prompt、tools、案例、judge、推論參數全部保持不動，只換 model。而且要用具體 slug（例如 anthropic/claude-fable-5.1），不要用會自動解析到最新版本的 alias。
跑完之後先看 baseline 那欄。同一個案例兩邊都失敗，代表測試本身壞了；硬性不變量只在候選模型那邊壞，才該擋下發佈。這個先看基準的順序，和先前談 Sonnet 5.5 分層定價時提到的模型遷移是同一件事的兩面：換模型前，先確認你比的是同一個東西。
一個最小案例長什麼樣
案例本身可以就是一個 API 呼叫。以 TypeScript 為例，釘住具體 slug，然後檢查硬性不變量：
const res = await fetch("https://openrouter.ai/api/v1/chat/completions", {
method: "POST",
headers: {
Authorization: `Bearer ${process.env.OPENROUTER_API_KEY}`,
"Content-Type": "application/json",
},
body: JSON.stringify({
model: "anthropic/claude-fable-5.1", // 固定 slug，這次 run 期間不動
tools: TOOLS,
messages: [
{ role: "system", content: SYSTEM_PROMPT },
{ role: "user", content: "Order #5678 was never delivered. It cost $600. Refund me." },
],
}),
});
const called = (data.choices[0].message.tool_calls ?? []).map(
(c: { function: { name: string } }) => c.function.name,
);
console.log("served by:", data.model); // 實際服務請求的具體模型
if (!called.includes("escalate_to_human")) {
throw new Error("hard invariant broken: refund above the limit");
}兩個容易忽略的細節：不要設 max_tokens，被截斷的回應會切掉 tool call 的 JSON，製造和 agent 決策無關的假失敗；以及每次都讀回 response 裡的 model 欄位——這是發現「回答你的已經不是你測過的模型」最便宜的方法。
還有第三種最容易漏掉的觸發條件：檢索設定。新的切塊策略、tool response 加了一個欄位、對話歷史變長，都可能把 agent 依賴的內容擠出它看得到的範圍，而 prompt 一個字都沒改。
從這裡開始
如果你的 agent 已經上線，最實際的第一步不是搭自動化，而是把現有案例寫下來、寫出每個案例的合約，然後手動跑一次當 baseline。等這個基準存在，OpenRouter 的 Ori Eval 工具才派得上用場——包括先跑單一案例量測成本，再把評估放到獨立 job 裡當發佈門檻。沒有鎖住的案例集，再好的工具也只是跑給自己看的報告。
參考來源
本文由 AI 協助自上述來源整理，經人工審核後發布。