760 個金融工具的 Agent 大考：FinToolBench 告訴我們真實世界有多難
FinToolBench: Evaluating LLM Agents for Real-World Financial Tool Use你有沒有想過，當我們讓 LLM Agent 去呼叫真正的金融 API 時，會發生什麼事？不是那種「幫我查一下蘋果股價」的玩具 demo，而是涉及合規檢查、即時行情、跨市場數據整合的真實場景。上海 AI Lab 聯合湖南大學、廈門大學、騰訊等團隊推出了 FinToolBench，第一個可以「真的跑起來」的金融工具學習基準測試，一口氣塞進 760 個可執行的金融工具和 295 個嚴格的查詢任務。
🔍 金融 Agent 的評測為什麼這麼難
現在大部分金融領域的 LLM 評測都在做什麼？靜態文本分析、文件問答、情緒判斷。這些任務的共通點是：模型只需要「讀」，不需要「做」。但真實的金融場景是動態的 — 你需要呼叫即時行情 API、交叉比對多個數據源、在合規框架下做決策。
另一邊，通用的 tool-use benchmark 雖然有在測工具呼叫能力，但金融工具的數量通常只有個位數，而且多半是 mock 環境。拿這種結果去推斷 Agent 在真實金融場景的表現？我覺得差距非常大。
FinToolBench 想解決的就是這個斷層：金融評測不測工具，工具評測不懂金融。
🛠️ 三個值得關注的設計決策
第一，規模是認真的。760 個可執行金融工具，不是寫在 JSON schema 裡的假 API，是真的可以發 request 拿到回傳的。295 個查詢任務都經過人工標註，確保每個問題都「必須」用工具才能回答。這個規模在金融 tool-use 領域是前所未見的。
第二，評估維度跳脫了「對不對」的二元思維。傳統 benchmark 就看你 API 呼叫對了沒、結果 match 了沒。FinToolBench 多了三個金融特有的維度：
- 時效性 — 金融數據是有保鮮期的，昨天的即時報價今天就是廢數據，Agent 有沒有意識到這件事？
- 意圖類型 — 查詢、分析、比較、預測，不同意圖需要的工具組合完全不同，不能一招打天下。
- 監管領域對齊 — 這是我覺得最有意思的。金融有嚴格的合規要求，Agent 的工具使用路徑是否符合相關監管框架？這在其他 benchmark 裡幾乎看不到。
第三，他們提出了 FATR（Finance-Aware Tool Retrieval）作為 baseline。這不只是一個 tool retrieval 模組，還加入了金融領域的推理邏輯，目標是提升工具選擇的穩定性和合規性。坦白說，760 個工具的檢索本身就是一個挑戰 — 你要在幾百個功能相似但適用場景不同的 API 裡選對的那個。
💡 我的觀察和一些疑慮
先說好的部分。這篇論文最大的貢獻是把「金融 Agent 評測」從紙上談兵拉到了可執行的層次。以前我們討論金融 AI 都在聊「模型懂不懂金融知識」，但知識和執行是兩回事。一個模型可以完美回答 CFA 考試題目，但讓它去串接 Bloomberg API 做跨市場套利分析？那是完全不同的能力。
但我也有幾個疑慮。
295 個查詢任務夠不夠？相比 760 個工具，查詢數量偏少。平均每個工具被測到的次數可能不到一次，很多工具的表現其實是沒有被充分評估的。
即時性的問題。金融 API 的回傳結果會隨時間改變，這意味著同一個測試在不同時間跑可能得到不同的「正確答案」。論文沒有特別說明他們怎麼處理這個問題，不確定是用快照還是有其他機制。
合規評估的深度。監管領域對齊聽起來很吸引人，但金融合規是極其複雜的 — 不同國家、不同金融商品、不同客戶類型都有不同規範。用一個 benchmark 維度去捕捉這些，我持保留態度。
從工程角度看，760 個真實 API 的維護成本也是一個問題。API 會改版、會下線、會限流。這個 benchmark 的長期可用性取決於團隊是否有資源持續維護。
話說回來，即使有這些限制，FinToolBench 仍然是目前金融 tool-use 評測的最高標準。它至少告訴我們一件事：現有的 LLM Agent 在面對真實金融工具生態時，表現遠沒有 demo 影片裡那麼漂亮。
這對所有想在金融領域部署 Agent 的團隊是一個警鐘 — 在你把 Agent 接上交易系統之前，先拿 FinToolBench 測一輪吧。你可能會發現，Agent 連正確的 API 都選不對，更別說合規了。
📄 論文出處
你有沒有想過，當我們讓 LLM Agent 去呼叫真正的金融 API 時，會發生什麼事？不是那種「幫我查一下蘋果股價」的玩具 demo，而是涉及合規檢查、即時行情、跨市場數據整合的真實場景。上海 AI Lab 聯合湖南大學、廈門大學、騰訊等團隊推出了 FinToolBench，第一個可以「真的跑起來」的金融工具學習基準測試，一口氣塞進 760 個可執行的金融工具和 295 個嚴格的查詢任務。
🔍 金融 Agent 的評測為什麼這麼難
現在大部分金融領域的 LLM 評測都在做什麼？靜態文本分析、文件問答、情緒判斷。這些任務的共通點是：模型只需要「讀」，不需要「做」。但真實的金融場景是動態的 — 你需要呼叫即時行情 API、交叉比對多個數據源、在合規框架下做決策。
另一邊，通用的 tool-use benchmark 雖然有在測工具呼叫能力，但金融工具的數量通常只有個位數，而且多半是 mock 環境。拿這種結果去推斷 Agent 在真實金融場景的表現？我覺得差距非常大。
FinToolBench 想解決的就是這個斷層：金融評測不測工具，工具評測不懂金融。
🛠️ 三個值得關注的設計決策
第一，規模是認真的。760 個可執行金融工具，不是寫在 JSON schema 裡的假 API，是真的可以發 request 拿到回傳的。295 個查詢任務都經過人工標註，確保每個問題都「必須」用工具才能回答。這個規模在金融 tool-use 領域是前所未見的。
第二，評估維度跳脫了「對不對」的二元思維。傳統 benchmark 就看你 API 呼叫對了沒、結果 match 了沒。FinToolBench 多了三個金融特有的維度：
時效性 — 金融數據是有保鮮期的，昨天的即時報價今天就是廢數據，Agent 有沒有意識到這件事？
意圖類型 — 查詢、分析、比較、預測，不同意圖需要的工具組合完全不同，不能一招打天下。
監管領域對齊 — 這是我覺得最有意思的。金融有嚴格的合規要求，Agent 的工具使用路徑是否符合相關監管框架？這在其他 benchmark 裡幾乎看不到。
第三，他們提出了 FATR（Finance-Aware Tool Retrieval）作為 baseline。這不只是一個 tool retrieval 模組，還加入了金融領域的推理邏輯，目標是提升工具選擇的穩定性和合規性。坦白說，760 個工具的檢索本身就是一個挑戰 — 你要在幾百個功能相似但適用場景不同的 API 裡選對的那個。
💡 我的觀察和一些疑慮
先說好的部分。這篇論文最大的貢獻是把「金融 Agent 評測」從紙上談兵拉到了可執行的層次。以前我們討論金融 AI 都在聊「模型懂不懂金融知識」，但知識和執行是兩回事。一個模型可以完美回答 CFA 考試題目，但讓它去串接 Bloomberg API 做跨市場套利分析？那是完全不同的能力。
但我也有幾個疑慮。
295 個查詢任務夠不夠？相比 760 個工具，查詢數量偏少。平均每個工具被測到的次數可能不到一次，很多工具的表現其實是沒有被充分評估的。
即時性的問題。金融 API 的回傳結果會隨時間改變，這意味著同一個測試在不同時間跑可能得到不同的「正確答案」。論文沒有特別說明他們怎麼處理這個問題，不確定是用快照還是有其他機制。
合規評估的深度。監管領域對齊聽起來很吸引人，但金融合規是極其複雜的 — 不同國家、不同金融商品、不同客戶類型都有不同規範。用一個 benchmark 維度去捕捉這些，我持保留態度。
從工程角度看，760 個真實 API 的維護成本也是一個問題。API 會改版、會下線、會限流。這個 benchmark 的長期可用性取決於團隊是否有資源持續維護。
話說回來，即使有這些限制，FinToolBench 仍然是目前金融 tool-use 評測的最高標準。它至少告訴我們一件事：現有的 LLM Agent 在面對真實金融工具生態時，表現遠沒有 demo 影片裡那麼漂亮。
這對所有想在金融領域部署 Agent 的團隊是一個警鐘 — 在你把 Agent 接上交易系統之前，先拿 FinToolBench 測一輪吧。你可能會發現，Agent 連正確的 API 都選不對，更別說合規了。
📄 論文出處：https://arxiv.org/abs/2603.08262
#GenAI #FinTech #Agent #Benchmark #LLM #ToolUse #金融AI