HyperAgent：用工具 Schema 超圖取代隱式推理 — 讓 LLM Agent 的工具調用既準又省
一句話核心結論
現有 LLM agent 的工具調用依賴隱式推理：從文字描述推斷哪些工具能串接、參數如何傳遞。當工具數量增加時，這種推斷變得不可靠——模型可能選到語義相關但參數不相容的工具，或漏掉「看似無關但實際是前置必要」的生產者工具。HyperAgent 把工具關係顯式建模為有向 Tool-Schema 超圖（TSH）：每個工具是一個超邊，從輸入 schema 節點指向輸出 schema 節點。任務執行前先萃取工具上下文圖→建構 Schema-aware Task DAG；執行時以缺損導向擴張（DOE）動態建構工具支援子圖——只補足當前狀態真正缺少的輸入。在 AppWorld 上，GPT-4o + HyperAgent 以 Test-N TGC 67.1、SGC 55.9 超越所有非微調方法，同時減少 API 呼叫、LLM 互動次數與 token 消耗。消融實驗確認：移除工具上下文圖或工具支援子圖都會顯著降低效能。
核心指標（GPT-4o）
Test-Normal TGC: ReAct 48.8 → PlanExec 63.1 → Traj 65.8 → HyperAgent 67.1。Test-N SGC: 32.1 → 52.6 → 55.9
跨模型泛化
GPT-4-Turbo Test-N TGC 45.3（vs ReAct 26.8）；Llama-3-70B 30.1（vs ReAct 20.8）。三個 backbone 全部超越 baseline
效率增益
API 呼叫數、LLM 互動輪次、token 總消耗三者同步降低。圖 2 顯示 HyperAgent 在兩類任務（Test-N / Test-C）都優於 ReAct
問題背景：為什麼隱式工具推理會壞掉
LLM agent 的工具使用面臨兩個核心困境：
- 依賴推斷不可靠：要完成一個目標操作，agent 必須不只知道哪些工具語義相關，還要知道哪些上游工具能產出該工具所需的輸入參數。當工具數量龐大時，LLM 隱式推斷工具依賴鏈的可靠性急遽下降。
- 前置工具遺漏：語義檢索會保留與任務直接相關的工具，但可能排除「語義上不相關、操作上不可或缺」的前置生產者工具。等到執行時才發現工具無法使用，已經浪費了時間和 token。
現有圖方法（ToolNet、Graph RAG-Tool Fusion）補了部分缺口——它們把工具依賴顯式化。但仍有兩個限制：(a) 只捕捉粗粒度工具依賴，不指定哪個上游輸出滿足哪個下游輸入；(b) 工具組合是狀態相關的——靜態規劃的路徑可能因執行時已取得的數值而變成冗餘或不完整。
核心架構：Tool-Schema 超圖 + 兩階段規劃執行
階段零：超圖建構
基於 In-N-Out 資料集（專家標註的參數級 API 圖），將每個工具表示為一條從輸入 schema 節點 → 輸出/效果節點的有向超邊。超圖中的 port-level dependency links 精確指定「哪個工具的第幾個輸出能餵給哪個工具的第幾個輸入」。額外從 API 文檔中萃取效果節點（如 login 建立 session）和條件節點（如某 API 要求先驗證），由 GPT-4o 初篩後經專家驗證。
階段一：任務級規劃（Task-Level Planning）
- 任務解釋：LLM 從使用者請求中產出結構化解釋——操作意圖 + 涉及的 schema、值、約束、期望效果
- 種子節點錨定：用 embedding 相似度將操作意圖錨定到工具超邊、將 schema 解釋錨定到輸入/輸出節點
- 上下文圖萃取：從種子節點向後展開（bounded backward search），只保留「能產出種子所需輸入」的工具——語義不相關但操作必要的前置工具被自動補回
- Task DAG 分解：基於序列化的工具上下文圖，LLM 規劃器將任務分解為 Schema-aware Task DAG——每個子任務指定目標輸出 schema、候選終端工具、依賴邊
階段二：缺損導向擴張（Deficit-Oriented Expansion, DOE）
Task DAG 告訴 agent「要做什麼」，但不預先決定「用哪些工具」。執行時，DOE 為每個就緒子任務動態建構工具支援子圖：
- 從候選終端工具出發，識別當前 agent 狀態中未滿足的輸入需求（缺損集 Deficit Set）
- 用 beam search 在超圖中向後展開，尋找能補足缺損的生產者工具
- 優先選擇輸出與缺損集重疊最大的工具（公式：Ω(e,M) = Σρ(e,r)）
- 找到完整支援子圖後，執行工具鏈→驗證子任務完成→更新 agent state→refine 剩餘 Task DAG
關鍵設計：DOE 是狀態條件式的——已由先前執行取得的 schema 值不會再被當作缺損。這避免了靜態規劃常犯的「重複呼叫已有資料的工具」錯誤。
實驗結果摘要
主結果：跨 scaffold 比較（GPT-4o）
| 方法 | Test-N TGC | Test-N SGC | Test-C TGC | Test-C SGC |
|---|---|---|---|---|
| ReAct | 48.8 | 32.1 | 30.2 | 13.0 |
| PlanExec | 63.1 | 52.6 | 35.7 | 18.9 |
| Traj(SetBSR+Snippet) | 65.8 | 53.6 | 38.7 | 24.8 |
| HyperAgent | 67.1 | 55.9 | 40.2 | 26.1 |
消融實驗：兩個關鍵組件
- Variant 1（移除工具上下文圖）：只保留簡化工具描述做 DAG 規劃——效能顯著下降，token 和 API 呼叫增加。證明結構化依賴資訊本身對規劃品質至關重要。
- Variant 2（移除工具支援子圖）：直接用語義相似度 top-K 工具執行子任務——效能同樣下降。證明 DOE 的缺損感知擴張比單純語義匹配更精確。
工具上下文圖品質
在相同 20 工具預算下，HyperAgent 萃取的工具上下文圖對金標工具集的覆蓋率顯著優於 In-N-Out 圖檢索和純語義 top-K 檢索。Schema 節點錨定 + 依賴引導展開能補回語義上不相關的前置工具。
與微調方法的對比
HyperAgent 作為無需訓練（NFT, Non-Fine-Tuning）方法，在多個指標上與需要大量軌跡訓練的 RL/DPO 方法競爭甚至超越：
- Test-N TGC 67.1：超越 Iterative Expert Iteration（58.3）、DPO-MCTS（57.0）、DMPO（59.0）、PPO（50.8）、RLOO（57.2）、GRPO（58.0）
- 僅次於 LOOP(turn) 的 71.3 和 LOOP(token) 的 71.3——但 LOOP 需要大量訓練樣本，HyperAgent 是零訓練部署
- Test-C SGC 26.1 與 LOOP(token) 26.6、LOOP(turn) 26.5 幾乎持平
這說明結構化的工具關係建模可以部分取代大量軌跡訓練——對資源有限的部署場景意義重大。
對 Hermes / DKY 的啟發
- Hermes 的工具描述應從純文字升級為 schema-aware：目前 Hermes 的工具清單是純文字描述（名稱 + description + parameters JSON Schema）。HyperAgent 的教訓是：單純語義匹配會漏掉前置必要工具。應在工具註冊時顯式記錄「哪些工具的輸出可以餵給哪些工具的哪個參數」。
- 工具支援子圖可以作為 Hermes 的內建模組：DOE 的核心邏輯（缺損集→生產者工具展開）可以用 ~100 行 Python 實現，不需要 LLM 參與。將它作為 Hermes 工具選擇的前處理層，能避免「選了語義相關但參數不相容的工具」的低級錯誤。
- 狀態感知的工具組合比靜態規劃更可靠：Hermes 目前的工具調用是 step-by-step 的 ReAct 模式。HyperAgent 的 Task DAG + DOE 兩層架構可作為進化方向：規劃層給出高層子任務圖，執行層根據當前已取得的資料動態選擇工具鏈。
- 消融實驗的啟發：結構化依賴資訊（工具上下文圖）比工具清單本身更重要。Hermes skill 的描述中如果加入「前置條件：需要 X 的輸出」的結構化欄位，就能讓工具選擇從語義匹配升級為依賴匹配。
- 成本控制的正向循環：HyperAgent 的 token 節省來自「更少的試錯」而非「更短的 prompt」——結構化規劃減少了 ReAct 中反覆查文檔和重試的浪費。Hermes 當前面臨的 token 成本問題，可以透過引入 schema-level 規劃來系統性改善。
限制
- 僅在 AppWorld（模擬消費應用 API）上評估，未測試程式開發、系統管理、網頁操作等其他 agent 領域
- 超圖建構依賴 In-N-Out 資料集的專家標註——在沒有標註的新工具集上，需要 LLM 輔助建構，品質可能下降
- DOE beam search 的計算成本隨工具集大小增長——超大工具集（>10K tools）的擴展性未驗證
- 論文使用 GPT-4o 作為規劃器——在更弱的 LLM backbone 上，任務解釋和 DAG 分解的品質可能不足以驅動 DOE
- 僅測試單一 agent 場景，多 agent 協作下的跨 agent 工具依賴未處理