# 策展 · X (Twitter) 🔥🔥🔥

> 📖 本站完整內容索引（documentation index）：[llms.txt](/llms.txt)

> 作者：Composio (@composio) · 平台：X (Twitter) · 日期：2026-07-09

> 原始來源：https://x.com/composio/status/2074908761970393265

## 中文摘要

Fable 5 執行真實 Agentic 任務勝過 GLM-5.2。

Composio 針對 Fable 5 與 GLM-5.2 做了實測，將兩者連接至 17 種 SaaS 工具（包含 GitHub、Slack、Salesforce、Notion 等），並指派 47 項具體任務。測試結果顯示，Fable 5 完成了所有任務，而 GLM-5.2 則有 2 項失敗。這項測試揭露了開源權重模型在追求 SOTA（State-of-the-art）效能時，仍面臨關鍵的技術落差。

**效能與效率差異**
在整體執行表現上，Fable 5 展現了更高的運作效率：
- 成功率：Fable 5 為 100%，GLM-5.2 為 95.7%（45/47）。
- 執行時間：Fable 5 平均每項任務耗時 84 秒，總計 66 分鐘；GLM-5.2 平均耗時 148 秒，總計 116 分鐘。
- 資源消耗：Fable 5 的 token 使用量減少約 20%，且所需的 tool calls 次數（239 次 vs 294 次）與對話輪次（6.1 次 vs 7.3 次）均較少。

**關鍵技術落差分析**
透過分析 stack traces，Composio 指出了兩者在處理複雜任務時的三大差距：

- **無法判斷任務是否完成**：在 GitHub 安全稽核任務中，要求找出 130 個包含硬編碼 `secret_key` 的 Python 檔案。Fable 5 精確找出所有檔案；GLM-5.2 僅找到 120 個便認定任務完成，且在過程中因遺失已儲存的結果檔案，導致重複搜尋並觸發錯誤，最終耗費 3.5 倍的 token 卻僅達成 92% 的目標。
- **模糊條件下的判斷力不足**：在 Zendesk SLA 稽核任務中，GLM-5.2 雖然正確執行了結構化輸出與時間戳記計算，卻在判斷「是否有代理人回覆」的邏輯上出錯。此類錯誤極具危險性，因為其輸出的格式與結構看起來完全正確，若無人工深入檢查 stack traces，極易被誤認為執行無誤。
- **執行路徑的精準度**：在 LaunchDarkly 設定變更等需要高度精確的任務中，Fable 5 傾向於在第一次嘗試時就使用正確的參數呼叫正確的工具；而 GLM-5.2 則採取探索式路徑，包含額外的搜尋、重試與修正錯誤的繞路。這種效率差異在單次對話中不明顯，但在需要多步驟串接的 Agent 工作流中，時間成本會顯著累積。

**核心結論**
Composio 指出，目前的差距並非單純在於「工具使用能力」，因為兩者皆能處理 API 互動、身份驗證與解析回應。真正的技術門檻在於：
- 具備自我驗證能力，在提交答案前確認工作是否確實完成。
- 能區分「輸出看起來合理」與「工作已完整執行」的差異。
- 在條件模糊時，具備正確的判斷決策能力。

Fable 5 的勝出之處，正是在於這些「小錯誤最難被發現且代價最高」的關鍵環節。

## 標籤

Agent, Benchmark, 開源專案, Fable, Composio, GLM