Spec 驅動的 agent:階層式規格、工具設計與基於軌跡的評估

TL;DR

• 軌跡比最終答案重要:他們看到的多數失敗模式(重複讀取、回頭、死路搜尋、不一致)在最終結果上完全看不出來,只有檢查 trajectory 才能發現;而且低效軌跡不只浪費 token,還因為 context 耗盡而反過來拉低正確率。
• 工具不是越多越好:把工具拆成 setup tools(啟動時一定呼叫) 與 discretionary tools(模型視問題自行決定);把一部分工具移到啟動階段,等於強制一次「新人 onboarding」,讓模型在解題時面對的選擇集變小,軌跡一致性顯著提升。
• tool overload 是真的:他們的 full 工具集是 minimal 的超集(多了現成的便利工具),結果更慢、品質還略差。真正重要的是 tool orthogonality / separability——只要 agent 分不清該叫 B 還是 C,就是問題。
• 知識重組成 diagnostic playbook(router + handbooks,router 把 symptom 映到 problem type 再路由到 handbook):相較直接讀原始文件,全面改善,token 總量降 43%、總錯誤率降 48%,連指令遵循都變好。
• 一句金句:「唯一比一個不能用的系統更糟的,是一個偶爾能用的系統。」正確性重要,一致性同樣重要。

重點整理

問題背景:Redis Query Engine 的診斷與修復 agent(約 00:40–00:41)

他們替 Redis Query Engine 建了一個 AI 診斷與修復 agent,主要服務對象是客戶支援團隊。Redis 本身有相當完整的工具與文件,但實際情況是很多複雜查詢最後一路升級到開發團隊,顯然不是可持續的做法;這個 agent 的目標就是攔下其中一大部分,縮短客戶的 time-to-solution。

技術上的困難在於:不像 SQL,LLM 對 Redis 查詢的參數化知識(parametric knowledge)相當有限,而且經常出錯;加上許多查詢本身高度依賴上下文——agent 必須判斷「這個查詢缺了什麼」。因此他們建的是一個帶 skills 與 tools、跑 clarify → diagnose → confirm 迴圈的 agent,以換取可靠性。

學到的第一課:最終結果不夠看(約 00:41–00:43)

三個觀察:

1. 只評最終結果往往不足——「怎麼走到那裡」的軌跡影響很大。
2. 正確性重要,一致性同樣重要。他的說法是:「唯一比一個不能用的系統更糟的,是一個只是偶爾能用的系統。」
3. 低效的 Redis 查詢本身很貴,而他們吃了一次苦頭才發現:這些低效軌跡在下游也更容易出錯,原因是長度/context 耗盡。

換更前沿、更強的模型當然能解掉一部分問題,但真正推動指標的是重組知識、以及重組 agent 取用資訊的方式——確保 agent 有足夠資訊知道如何辨識、如何取用、以及何時該用。

四類失敗模式(約 00:42–00:44)

前三類關於最終結果,第四類關於軌跡:

• Correctness:結果錯誤。可能是路徑錯、讀錯指標等,本質是 hallucination。
• Completeness:只診斷出問題的一部分,其他未解——這是他們最常遇到的問題之一。
• Usefulness,又分兩種:
• 給了太多或太籠統的資訊,使用者被資訊淹沒,實際上不可行動。
• 給的建議違反語意意圖——他舉的例子很精準:使用者問「我的查詢為什麼慢」,agent 回「減少搜尋詞的數量」。技術上正確,但完全沒有服務到使用者的目的。
• Efficiency:重複讀取、回頭、死路搜尋,浪費 token;而且如前所述,這也會負面影響正確率。

他強調:這些多半只有看軌跡才會浮現,在最終結果裡看不到。

介入一:工具架構——setup tools vs discretionary tools(約 00:44)

第一個維度是重新檢視 tool architecture。他們把工具分成兩類:

• Setup tools:啟動時一律呼叫。
• Discretionary tools:由模型依當下問題自行決定呼叫。

他用的比喻很好懂:就像你到一個新職位會先經歷 onboarding——有人告訴你這裡發生什麼事、誰負責什麼、該找誰。setup tools 就是這段 onboarding,提供足夠 context 讓 agent 知道如何正確前進、正確使用 discretionary tools、以及何時該用。

介入二:把知識組織成 diagnostic playbook(約 00:44–00:45)

第二個維度是知識庫的組織方式。可以直接餵原始文件,但他們發現重組成 diagnostic playbook 效果更好。playbook 就是 一個 router + 一組 handbooks:router 的結構是「symptom → problem type → 路由到某個或某組 handbook」。

他點出一個關鍵的使用者行為事實:使用者不會拿著「症狀」來找你,他們拿的是「困擾」。把困擾映射到症狀是 agent 的工作,而讓 agent 容易做到這件事是我們的工作。 playbook 就是為此存在。

實驗結果(約 00:45–00:48)

兩個介入分開評估,量測 end-to-end latency、tool call 次數、與結果品質。

工具架構:

他從 full 的結果導出兩個結論:tool overload 確實存在,而且更重要的是 tool orthogonality(或說 separability)很關鍵——只要 agent 在某個時點無法判斷該呼叫 B 還是 C,就是問題。

setup tools 與 minimal 在總指標上相近,直到他們鑽進軌跡本身:沒有 setup tools 的 minimal,軌跡遠遠更不一致,出現多得多的獨特序列。當然不是每個獨特序列都有問題,但其中一些會是。結論:減少 LLM 在任一時點需要做的決策,就能降低變異、提升一致性;setup tools 透過強制一段 onboarding context 達成這件事。

知識組織(playbook vs 原始文件),分兩組指標: - 答案品質:answer grounding、specificity - 軌跡品質:first-pass success、dead-end rate

結果全面改善,並且 token 總量下降 43%、總錯誤率下降 48%;最後一列顯示連指令遵循也變好了。他的總結是:讓 agent 更容易取用資訊,不只降低成本,也降低「遺忘」,因而提升可靠性。

未竟與收尾(約 00:48–00:50)

還有沒做好的地方。他點名 recursive self-improvement(本次峰會的共同主題之一)是很適合套用在這裡的方向,可望再往上推;但目前已經看到多數常見失敗模式減少。

三個帶走的重點:

1. 量測軌跡,不只量測最終答案——他們看到的許多問題根本不會出現在最終結果裡。
2. 盡可能把知識結構化,讓 agent 容易辨識與取用。
3. 檢視你的工具,分清楚哪些是必備的 baseline context、哪些是可自行斟酌的探索性 context。

最後一句:如果你能同時做到結果的 correctness、completeness、usefulness,加上有效率的軌跡,你的 agent 就更有機會達到 production 級的可靠度。

金句

"The only thing worse than a system that doesn't work is something that just works occasionally."(約 00:41)

一致性不是正確性的附屬品,在生產環境裡它本身就是一級指標。

"Telling a user who asked why my query is slow to reduce the number of search terms is technically correct, but it doesn't actually serve the purpose at all."(約 00:43)

「技術上正確但違反語意意圖」——一個最終答案評分幾乎抓不到的失敗模式。

"Most of these things can only be resolved by looking at the trajectory. They don't show up in the final result."(約 00:44)

整場的核心論點。