衡量 API Agent 在生產環境長程任務中的可靠度

TL;DR

• 單一任務的高分是假象:APIFlow-Bench 上,即使是輕量模型在單一 API 任務也有 88–97% 通過率;一旦串成依賴鏈,同樣的子任務組合起來只剩 44–73%。難度沒變,變的是錯誤會不會被繼承。
• 把 API 工作拆成七種失敗模式分別評分:authentication、discovery、schema repair、multi-step execution、error recovery、pagination、statefulness。分開評分才知道模型為什麼失敗——step 3 沒存狀態害 step 15 失敗,和 pagination 處理不好,是完全不同的病。
• 合成任務必須設「硬性關卡」才可信:三道 gate——self-testing(空白提交與被破壞的證據都必須失敗)、solvability(frontier 模型試 10 次至少過 3 次才收)、golden replay(把各子任務的參考答案串起來重放,整條鏈必須全過)。
• 確定性 validator 與 LLM validator 兩者都要:兩個確定性驗證器(環境最終狀態 + 最終答案)決定 leaderboard 分數;LLM validator 不計分,專門標記可疑的通過案例交給人審。驗證器錯了,模型的真實能力就永遠測不出來。

重點整理

問題:企業把商業邏輯包在 API 裡,現在把 agent 接了上去(約 02:24–02:26)

Zelin Wan 是 Postman 的工程師,這場介紹他們的 benchmark APIFlow-Bench。

企業用 AI agent 執行長程任務時,已經在面對一個具體問題:agent 在早期犯的一個小錯,會讓整件事整個失敗。而工程師實際在做的事情長這樣——把一個 build job 接到 monitoring API、建立一筆紀錄、或從 rate limit 中復原。這些任務類型就是 benchmark 的取材來源。

他們的核心發現非常乾脆:

他強調關鍵:任務本身沒有變難。是當後面的任務依賴前面任務的結果時,模型才開始失敗。

在企業裡,大量商業邏輯被包在 API 中,而現在我們正把 AI agent 接進這些 API。AI 造成的一個小錯,會在後期變成一個大問題。

所以真正的問題不是「模型能不能回答問題」——那件事大家都知道可以了。真正的問題是:AI agent 能不能在一條長程依賴鏈上一路保持正確?這就是「回答」與「執行」的差別。

七種失敗模式,分開評分(約 02:27)

一兩種 failure mode 不夠,他們要的是能涵蓋真實 API 工作的最小集合。因此把 API 工作拆成七種失敗模式,各自獨立評分:

1. authentication(認證)
2. discovery(探索)
3. schema repair(schema 修復)
4. multi-step execution(多步驟執行)
5. error recovery(錯誤復原)
6. pagination(分頁)
7. statefulness(狀態保持)

為什麼要分開?他舉 statefulness 的例子:agent 在第 3 步更新了某個東西,而第 15 步只有在 agent 當初確實存下那個更新時才會成功。 一個在 statefulness 上失敗的模型,和一個在 pagination 上失敗的模型,失敗原因完全不同。分開評分,才能告訴你模型為什麼失敗,而不只是失敗了。

任務生成 pipeline 與 fixer agent(約 02:27–02:29)

他們用內部資料近似真實使用者的 workflow,建出一套模擬的企業 API 生態系(模仿真實公司的 API),再在上面生成任務。

pipeline 從 step 0 的「企業 API 生態系生成」開始,接著九個步驟逐一生成任務。每個生成的任務都要通過驗證:

• 用 frontier 模型對每個任務嘗試 10 次,至少通過 3 次才保留。
• 理由很實際:用語言模型生成的任務,有些根本無解。你不會想拿一堆無解任務去評估 frontier 模型,然後宣稱那就是模型的極限。
• 任務沒通過驗證怎麼辦?把嘗試的 transcript 與程式碼餵給一個 fixer agent,由它修正任務,再跑一次那 10 次嘗試。若持續失敗,就整個丟掉重新生成。

Harness 與三個 validator(約 02:29–02:30)

benchmark 由四塊組成:一套 API 生態系、蓋在上面的任務、一個共用 harness、以及為每次 trial 評分的 grader。

• Harness:設計了 7 個工具,作用在 5 種不同的 entity。每個任務、每次 trial 都跑在同一個 harness 上,差別只在生態系與 grader 不同。
• 三個 validator:
• 兩個確定性 validator——一個檢查環境的最終狀態,一個檢查 agent 給出的最終答案。這兩個決定 leaderboard 上看到的 pass rate。
• 一個 LLM validator——不計入分數,用途是標記「可疑的通過」,交給人類複核。

三道 gate:讓生成的任務值得信任(約 02:30–02:31)

每道 gate 擋掉任務生成過程中不同類型的失敗:

1. Self-testing:空白提交必須永遠失敗;而拿參考答案但把證據破壞掉,也必須失敗。否則就代表任務本身或 validator 有問題。
2. Solvability:就是前面提到的——frontier 模型試 10 次、至少 3 次通過才收。
3. Golden replay:建構鏈式任務時,把各子任務的參考答案全部串起來、接進這條鏈式任務,結果必須全部通過。這樣才能確認組出來的最終鏈是正確的、如預期運作的。

實驗規模與結果(約 02:31–02:32)

• 467 個任務,最終產出 20 步的長鏈任務
• 19 個模型,每個模型每個任務跑 5 次 trial
• 合計約 44,000 次 trial,所有 transcript 都公開在 leaderboard 上
• 下一版計畫擴增任務數量與鏈的長度

Leaderboard 結果(20 步鏈式任務):GPT-5.5 居首;橘色長條是開源模型,紫色是閉源模型。他提到 leaderboard 在演講當週剛更新,已納入 Kimi K3 與 Fable 5。

一個有意思的發現:此時此刻,開源模型已經逼近閉源模型的頂端集團——在他們的 bench 上,GLM 與 Qwen 3.7 拿下第二與第三名。

三個 takeaway(約 02:32–02:33)

1. 單一任務已經無法區分模型。所有模型(包括輕量模型)在 solo 任務上都拿高分,看不出差距——這正是他們建構鏈式測試去逼出極限的原因。他們反覆看到:模型在早期犯一個極小的錯,那個小錯到後面就變成一份壞掉的報告。
2. 生成合成任務時,一定要用硬性 gate 確保任務可信。例如「10 次嘗試至少 3 次通過」;再加上 golden replay 確認你的參考答案真的能跑。他也鼓勵大家自己發展更多方法。
3. 確定性 validator 與 LLM validator 兩者都需要。而且建立 validator / grader 時務必 human-in-the-loop 持續打磨——因為一個錯的 validator,永遠測不出模型的真實能力。

blog 與 leaderboard 都在 blog.postman.com。

金句

"So the task itself didn't get harder. But if the later task is depend on the results of the previous task … then that's where the model start to fail."(約 02:26)

整場的核心診斷:崩潰的來源是依賴,不是難度。

"The real problem is: can the AI agent stay correct across a long horizon of dependent chain tasks? That's the difference between answering and executing."(約 02:26)

"We don't want to generate a bunch of unsolvable tasks and then use those to evaluate frontier models and claim that's the limit of the models."(約 02:28)

合成 benchmark 的誠實原則:先證明題目有解,再用它下結論。

"A wrong validator cannot reveal the true performance of the models."(約 02:33)

驗證器本身也需要被驗證。