Agent 成功率

3 秒看懂

Agent 成功率，即 AI Agent 在無人工干預條件下，端到端完成給定任務併產生符合預期結果的比例。它不再只關心單一問題的回答準確度，而是衡量智慧代理在多步推論、工具協調、環境互動、自我糾錯中“把事做成”的完整能力。在“聊天 AI”向“生產力 Agent”的躍遷中，成功率是定義產品能否脫離 demo 階段、真正進入業務流程的硬性門檻。

3 分鐘產業解釋

把 AI 想成一個遠端數字員工。你吩咐它：“幫我預訂下週三從上海飛北京的最便宜直飛機票，支付成功後把電子登機牌發給我。”任務包含理解模糊需求（“最便宜直飛”）、開啟航空網站或 API、識別動態網頁內容、選擇正確日期、過濾航班、填寫乘客和支付資訊、完成支付、截圖回傳——總共至少 8–10 個關鍵步驟。中間任何一環出錯，比如把“直飛”誤解為中轉、點錯日期、在支付頁面超時、或因頁面彈窗丟失上下文，整個任務即告失敗。

Agent 成功率就是把這一類端到端任務在不同的環境快照下重複數百次，統計“一切按預期完成”的比例。傳統大型模型評價——困惑度、BLEU、HumanEval 準確率——度量的是靜態文本或程式碼片段輸出的質量。而 Agent 成功率度量的是在不確定、長鏈路、跨工具、有狀態互動中的過程可靠性。產業界之所以如此重視，是因為成功率 80% 和 95% 看似只差 15 個百分點，但對企業長鏈自動化而言，意味著完全不同的人工兜底成本結構：80% 時，每 5 次任務就有 1 次失敗，運維團隊必須隨時待命搶救狀態，自動化非但不能降低開銷，反而新增運維複雜度；而 95% 以上時，多數任務可以“交鑰匙式”執行，人工僅作為極少數的例外流程介入。正是這種斷崖式影響，使得成功率成為 Agent 商業化的第一性指標。

技術原理

Agent 成功率的底層是一套 感知—規劃—行動—校驗 迴圈，其骨架如下：

任務指令 → [規劃器：拆解子目標序列]
              ↓
┌─────────────────────────────────────┐
│        動作迴圈（直到完成/失敗）      │
│                                     │
│  ┌──────────┐     ┌────────────┐   │
│  │ 環境感知  │←────│ 環境狀態    │   │
│  │  (DOM/截圖/API 響應)│ (網頁/OS/外部工具)│
│  └─────┬────┘     └────────────┘   │
│        │                            │
│  ┌─────▼───────────────────────┐   │
│  │ 推論決策 + 記憶檢索          │   │
│  │  - 當前子目標                │   │
│  │  - 歷史動作與觀察            │   │
│  │  - 工具描述 / 長期知識庫     │   │
│  └─────┬───────────────────────┘   │
│        │                            │
│  ┌─────▼───────────────────────┐   │
│  │ 動作生成（工具呼叫/UI操作）  │   │
│  └─────┬───────────────────────┘   │
│        │                            │
│  ┌─────▼───────────────────────┐   │
│  │ 校驗與反思（可選）           │   │
│  │  - 子目標成功? 輸出是否一致? │   │
│  │  - 若不一致，生成修正動作    │   │
│  └─────────────────────────────┘   │
└─────────────────────────────────────┘
              ↓
        成功/失敗判決

決定成功率高低的關鍵機制包括：

1. 規劃完整性與任務分解：LLM 規劃器在將模糊指令拆解為可執行的子目標時，是否遺漏隱式前置條件（如“登入帳戶”“確認優惠券未過期”）或忽略環境約束（如某些網站在無頭模式下不同渲染）。很多失敗源自“計劃本身就錯了”。

2. 工具定義與實際行為的對齊：Agent 依賴外部工具（搜尋、計算器、資料庫查詢、支付介面等），如果工具描述、引數格式或錯誤碼與實際返回不一致，會導致引數注入錯誤、解析失敗甚至幻覺式操作。

3. 上下文視窗的管理：長鏈任務在上下文中累積大量動作與觀察，模型必須記住最早的目標和約束，同時避免隨著視窗增長出現的注意力衰減和“遺忘早期指令”。結構化的記憶模組（如向量庫、摘要記憶、工作/長期記憶分離）成為對抗指數衰減的關鍵設計。

4. 校驗與自我糾偏的深度：每個子步驟結束後是否主動對照預期結果進行校驗，以及是否在失敗時基於結構化回溯進行修正，而非簡單重試上一次動作，對複雜任務的影響可達數十個百分點。

從機率角度看，若每個不可並行的原子步驟正確率為 p，任務的步驟數（主要指串聯依賴、中間狀態不可丟棄的環節）為 n，理想化的端到端成功率上限趨近 p^n。當 p=0.95、n=20 時，端到端成功率僅約 36%；即便單步正確率提高到 0.99，20 步後也會跌至 82%。這就是為什麼真實企業場景下，步驟超過 10 個的完全自動化至今仍然罕見——需要工程手段在多個層面上打破串聯剛性，如引入可回滾狀態、並行執行與獨立校驗、分級中斷與人工握手等，才能將有效成功率提升至可商用區間。

關鍵引數

Agent 成功率並非一個單一數值，而應作為一組分層指標體系來理解。核心引數與評估粒度包含：

• 任務完全成功率（End-to-End SR）：最頂層、最硬核的指標，指“一次都不人工干預、最終結果完全符合驗收標準”的比例。它常出現在企業服務級別協議（SLA）中。

• 首次成功率（First-Attempt SR）：不含任何重試或自我修正的原始成功率，反映模型在最乾淨條件下的規劃與行動能力。可以用於快速評估模型初始策略的質量，而非藉助反思彌補短板的程度。

• 子目標/步驟成功率：將長任務按里程碑切分（如“搜尋頁面開啟成功”“表單填寫正確”“支付介面呼叫正常”），逐環節計算成功率。這是定位失敗來源的基本單位，能清晰反映出 Agent 的弱點集中在工具呼叫引數錯誤、視覺識別偏差還是規劃遺漏。

• 魯棒成功率：在同類任務上引入環境擾動（網頁版面配置微調、同義指令改寫、部分工具降級或不可用）後仍能成功的比例。它是泛化能力和真實世界適用性的直接證明，比實驗室條件下的成功率更能反映產品潛力。

• 漸進成功率：首次嘗試失敗後，經最多 N 輪自我修正（反思—重規劃—重執行）最終成功的任務比例。該指標能量化反思機制的投資回報率，同時也暗示 Agent 到底是在“聰明地糾錯”還是“隨機重試撞運氣”。

• 嚴重失敗率（Critical Failure Rate）：導致不可逆負面後果的失敗比例，例如錯誤刪除資料、錯誤提交訂單、洩露敏感資訊或執行不可撤銷的危險操作。這一指標直接與安全合規和業務損失掛鉤，可比成功率本身更重要。

• 成功率方差與尾部表現：同一任務多次執行的波動性以及在最差 X% 場景下的失敗特徵。低方差、輕薄尾部意味著 Agent 行為可預測，有利於風險定價和運維排班。

在公共基準測試中，這些指標通常通過環境模擬和自動判決指令碼獲取；而在真實部署中，還需加裝執行時保護層（guardrails）和人工確認節點，相當於在成功率指標之外引入了“受控失敗”的緩衝機制。

技術路線

衡量 Agent 成功率的方法可歸納為三條主要技術路線，它們在成本、可信度、泛化性和可復現性上各有取捨：

評估路線	核心方式	成功率表徵	成本	可復現性	泛化性	主要侷限
環境模擬 + 自動判決	在可重置的模擬環境（WebArena, OSWorld, SWE-bench 等）中執行 Agent，通過預設的斷言指令碼判定成功/失敗	直接度量端到端、子目標等各類成功率	高（需建置維護模擬環境）	中高（環境版本鎖定後可復現）	高（可注入各類擾動）	環境多樣性有限，始終存在 sim-to-real gap；任務指令碼覆蓋範圍決定評估天花板
LLM-as-Judge	由一個強裁判模型（或經過校準的多模型陪審團）對 Agent 的完整行動軌跡和終態進行語義判斷，輸出成功機率或分級結果	通過裁判推斷成功率，可用於缺乏自動化驗證指令碼的場景	中（僅需裁判模型呼叫）	中（裁判模型版本鎖定後一致性較好，但裁判本身可能漂移）	中（語義理解強，但對細微邏輯錯誤的區分力不足）	裁判幻覺、對部分失敗模式誤判（如看似正確但邏輯錯誤的操作）；缺乏客觀剛性標準
人機協同評估	聘請領域專家或眾包評估員對任務執行結果、甚至中間步驟進行人工評判，常用於校準自動化指標	作為最高訊號校準其他方法的 baseline，也適用於高風險領域的最終驗收	極高（人力成本）	低（人的主觀性和疲勞）	高（人類判斷最貼近實際需求）	難以大規模、高頻執行；一致性需嚴格控制

此外，還有一些混合路線正在興起：利用 Agent 執行軌跡資料訓練專門的成功率打分模型（learned verifier），使其具備接近人類判斷精度而成本接近自動指令碼，同時引入對抗性測試來探測評估模型的盲區。這類思路逐漸將“成功率衡量能力”本身變成研發 Agent 過程中的一個獨立技術棧。

在工業界實踐中，同一 Agent 產品往往會同時部署多條評估管線：自動化迴歸跑分（每次釋出前在模擬基準上刷分）、關鍵場景的人工抽查、以及基於使用者反饋的“執行時感知成功率”（例如通過任務後用戶是否立即人工修正來判斷Agent是否成功）。只有將多條路線的訊號交叉驗證，才能避免“實驗室成功率”與“生產成功率”之間的巨大落差。

上游

Agent 成功率的上游直接決定其天花板，主要包括以下要素：

• 基礎模型能力：LLM/VLM 的指令跟隨準確率、工具呼叫準確率（function calling）、長上下文記憶保持力、多模態理解（截圖、PDF、表格）等幾項子能力，構成 Agent 原子操作的“原材料”。例如，在某一權威基準測試中，GPT-4 級別的工具呼叫單步準確率約為 85%–92%（來源：OpenAI 2023 技術報告中的 Function Calling 評測），而此前的模型可能不足 70%，這直接轉化成了多步任務成功率的階躍。

• 工具生態系統與介面規範化：下游工具（搜尋引擎、電商 API、SaaS 軟體介面、作業系統操作）的文件質量、錯誤碼標準化程度、冪等性支援等，強烈影響 Agent 呼叫時的引數填充錯誤率和異常處理成功率。OpenAPI 規範、雲端廠商對 Agent 友好的工具閘道器設計正成為上游基礎設施競爭焦點。

• 模擬與基準平台：WebArena (Zhou et al., 2024)、OSWorld (Xie et al., 2024)、SWE-bench (Jimenez et al., 2024)、GAIA (Mialon et al., 2023)、τ-bench (Yao et al., 2024) 等評測環境，定義了當前行業公認的成功率“座標”。這些平台的任務分佈、難度曲線和擾動策略，直接影響 Agent 團隊最佳化成功率的方向和是否存在基準過擬合風險。

• 記憶與狀態管理元件：向量資料庫、持久化工作記憶、圖記憶等中介軟體的效能與可靠性，決定了 Agent 能否在多步、多會話任務中維持上下文完整性。

• 安全與權限管控層：細粒度的動作權限控制（如只允許讀取、禁止刪除）、危險操作攔截、使用者確認斷點等機制，雖然不直接提升成功率，但可有效降低嚴重失敗率，從而改善成功率指標的業務含義。

供給端目前的狀態是：基礎模型能力近兩年進步顯著，但工具標準化和長鏈記憶元件仍比較碎片化；高覆蓋度的模擬基準增長迅速，但模擬任務的生產級覆蓋率依然不足真實用例的 10%，導致上游對成功率的支撐尚存在明顯瓶頸。

下游

Agent 成功率的下游影響幾乎滲透到所有引入自主 Agent 的垂直領域：

• 企業自動化交付與採購決策：在 RPA 和智慧化流程領域，諮詢服務商和軟體供應商已在合同中明確約定 Agent 成功率 SLO。例如，某跨國金融集團的智慧文件處理 Agent 招標中，要求“發票自動錄入端到端成功率不低於 95%，嚴重錯誤率低於 0.1%”（來源：公開招標公告，2024 年）。成功率每提升 1 個百分點，直接關係數百萬至千萬元級合同能否續約。

• 使用者體驗與信任建立：面向 C 端或中小企業使用者的 Agent 產品（如旅行助手、購物助手、程式設計助手），成功率低於使用者心理閾值的後果是使用者快速放棄。多項產品體驗研究表明，使用者對自主 Agent 的容錯率遠低於對人類客服：一次致命失敗可能導致永久流失，與成功率高度相關的“任務放棄率”是此類產品的北極星指標。

• 成本結構與 ROI：成功率的微小變化通過影響人工複核工作量而產生放大效應。對於日處理 10 萬次任務的客服 Agent 系統，若成功率從 90% 提升至 95%，意味著每日失敗任務從 1 萬次降低到 5000 次。以單次人工介入平均成本 5 元計，每年節省的人力成本約 900 萬元（計算口徑：250 個工作日 × 5000 單 × 5 元）。這直接決定了企業自動化投入的回收期。

• 監管與合規：在醫療、法律、金融交易等強監管領域，成功率與嚴重失敗率直接影響是否需要向監管方報備、是否觸發行內事件響應機制。低成功率 Agent 在這些領域幾乎沒有進入機會。

• 生態連鎖反應：當 Agent 成為另一個 Agent 的工具時（多 Agent 協作），單個 Agent 的成功率會作為“工具可靠性”輸入到上游排程 Agent 中。這意味著成功率缺陷會以級聯形式汙染更復雜的自動化鏈條，進一步放大其重要性。

受益公司

Agent 成功率的提升與度量，正在重塑 AI 產業鏈中的價值分配，多方因此深度受益（以下僅描述產業邏輯，不做任何投資建議）：

• 基礎模型提供商（OpenAI、Anthropic、Google DeepMind 等）：成功率的每一次公開躍進都是其 API 生態的核心營銷資產。OpenAI 通過 GPT-4 Turbo 的 Function Calling 改進和 2025 年初推出的 Operator，將網頁自動化成功率推高到新基線；Anthropic 則將 Computer Use 與 Claude 的安全層結合，強調高成功率下的可控性；Google 憑藉 Gemini 的多模態優勢，嘗試將成功率競爭從文本工具呼叫擴充套件到視覺介面操作。這些公司通過按用量收費，成功率的提升直接帶動 API 消耗量和客戶粘性。

• 企業軟體與雲端平台巨頭（微軟、Salesforce、ServiceNow、SAP 等）：在 Copilot、Agentforce 等產品中，成功率是區分“演示驚豔”和“生產可用”的核心。微軟將 Copilot Studio 的 Agent 成功率作為企業客戶部署前的關鍵 POC 指標；Salesforce 則強調其 Agentforce 在 CRM 工作流中的成功率超過獨立通用模型，以此作為對抗純模型公司競爭的護城河。此類公司的訂閱續費和高價產品升級包，與成功率表現高度繫結。

• Agent 架構與工具鏈公司（LangChain、LlamaIndex、AutoGen、CrewAI 等）：通過提供規劃器、記憶管理、工具編排和評測工具，直接提升 Agent 建置者的開發效率和成功表現。隨著成功率成為產品經理和工程師關心的首要指標，對除錯、追溯、A/B 測試和失敗回放的需求催生了獨立評測賽道。

• 垂直領域 Agent 初創（Cognition（Devin）、Adept、Imbue 等）：其估值錨點之一便是其 Agent 程式碼或作業系統完成任務的成功率，較通用方案高出多少個百分點。例如 Devin 在 SWE-bench Verified 上的解決率從 2024 年的約 13% 提升到後續版本的 20% 以上（來源：Cognition 官方部落格，2024 年），每一次提升都直接對應商業敘事和融資熱度。

• 獨立評測與安全公司（Galileo、Braintrust、Patronus 等）：隨著企業對“自評自”不再信任，第三方成功率評測、紅隊測試、執行時安全防護成為必選項。這些公司的服務價值直接與市場上 Agent 部署數量以及成功率差異化的需求有關。

需要指出的是，上述公司受益的前提是其在真實業務中證明成功率的泛化能力，而非僅在公關基準上“刷分”。

市場規模

公開資料中尚未出現完全聚焦於“Agent 成功率”這一單一指標的市場規模測算，但與之緊密相關的 AI Agent 市場及其評估服務市場正在快速膨脹，成功率作為其核心效能變數，深刻影響版圖擴張速度。

• 全球 AI Agent 市場：據 MarketsandMarkets 2024 年釋出的報告，全球 AI Agent 市場規模 2024 年約為 51 億美元，預計 2030 年將達到 471 億美元，年複合增長率約 44.8%。報告指出，企業對自動化解決方案的強勁需求是該市場增長的主要驅動力，其中任務成功率和可靠程度是採用的首要考量因素。Grand View Research 的同期研究也給出了相近的基年估算與爆發式增長預測。

• 中國企業級自動化與 Agent 市場：根據億歐智庫等機構 2024 年的報告，中國 AI Agent 及智慧自動化市場處於早期爆發階段，金融、政務、製造、電商為主要需求方。招標檔案中頻繁出現對於“自動化執行準確率”、“任務成功率”的定量要求，顯示出下游支付意願與成功率的直接關聯。公開資訊顯示，部分地方政府和央企的智慧流程自動化採購標的中，要求驗收時端到端成功率不低於 90%（2024 年公開招標公告）。

• 評測與可觀察性衍生市場：隨著 Agent 落地數量指數增長，對成功率評測架構、執行時監控、失敗溯源和合規審計的需求有望催生一個年規模數十億美元的獨立賽道。雖然目前尚無統一口徑統計，但此類工具在 2024 年獲得的風險投資總額已超過 5 億美元（據 PitchBook 不完全統計），側面反映市場對“如何證明和保持高成功率”的巨大重視。

整體而言，成功率雖不直接交易，但其“及格線”每向上移動一個等級，都可能釋放下一個百億美元級別的自動化市場空間，因為它意味著 Agent 可以滲透到更復雜、更不容忍錯誤的業務流中。

玩家對比

當前圍繞 Agent 成功率的主要參與者在產品形態、主流基準以及公開成功率資料上存在明顯差異。以下基於公開測試結果與官方揭露的資訊進行比較（資料日期截至 2025 年 2 月）：

玩家/模型	代表能力	代表性評測基準	公開成功率	重要說明與來源
OpenAI — Operator（基於 GPT-4 系列）	瀏覽器 Agent，視覺+文本操作	WebVoyager	87%（2025 年 1 月）	OpenAI 官方部落格揭露；此前 GPT-4 + 瀏覽器工具在 WebVoyager 上約為 70% 左右
Anthropic — Claude 3.5 Sonnet + Computer Use	作業系統級 Agent，理解螢幕並操作	OSWorld	14.9%（僅截圖，2024 年 10 月）	人類基準為 72.4%；Anthropic 同時給出結合更多輔助資訊的配置下成功率為 22.0%
Google DeepMind — Project Mariner（Gemini）	基於 Chrome 擴充套件的網頁 Agent，多模態	WebVoyager (推測)	公開資料未見明確端到端數值；2024 年底演示顯示在若干網站任務上達到與人類相近效率	Google 尚未釋出系統性的基準成功率報告，資料待補充
Adept / Amazon（部分技術授權）	ACT-1 模型，專注 UI 操作	自建內部基準	公開資料未見最新官方公佈	2024 年部分團隊成員被亞馬遜吸收，公司獨立運營，產品聚焦 Workflow Automation
Cognition — Devin	軟體開發 Agent，生成並修改程式碼	SWE-bench Verified	13.86%（2024 年 3 月）→ 21.0% 以上（2024 年 8 月更新）	Cognition 官方部落格；人類外包開發者解決率約為 90%+（受任務難度影響）
開源 Agent 架構 + GPT-4（如 AutoGPT, LangChain）	通用任務 Agent，可組合工具	GAIA（通才 Agent 基準）	約 15% 水平（2023 年），人類 >90%	來源：GAIA 論文 (Mialon et al., 2023)
微軟 Copilot Studio	企業低程式碼 Agent，嵌入 Microsoft 365	內部客戶 POC 指標，未公開標準化基準	公開資料未見終端成功率橫評資料	微軟強調在客戶環境通過整合 Graph API 和自定義聯結器可將成功率提升至“可部署”水平

關鍵差異維度：

• 模態覆蓋：Operator 和 Mariner 深度整合視覺理解，Claude Computer Use 直接從螢幕座標操作，對動態 UI 泛化更直接，但也更難。
• 安全與容錯：Anthropic 將嚴重失敗率控制放在首位，導致其探索性配置下的原始成功率偏低，但部署時可能通過權限限制與確認步驟換取更低風險。
• 垂直聚焦 vs 通用：Devin 專攻軟體開發，成功率基準明確（解決 GitHub issue），而通用 Agent 評測基準任務離散，更容易測出高方差。
• 開閉源生態：開源架構成功率高度依賴底層模型能力和社群工具開發成熟度，尚未出現對閉源巨頭形成替代的突破性資料。

對比結果說明，成功率的高低不僅取決於模型智慧，還與任務域選擇、安全性取捨和工程最佳化深度高度相關。不同玩家在“成功率”這一相同詞彙下的實際含義可能差異巨大。

風險

過度依賴單一成功率數字或片面追求高成功率，會帶來多種技術和商業風險：

• 基準過擬合與泛化塌陷：許多團隊針對少數公開基準（WebArena、SWE-bench）反覆最佳化策略與提示詞，導致在實驗室成功率接近 90% 的 Agent，部署到企業獨有環境時成功率驟降至 20%–30%。這種 “benchmark leakage” 是當前產業最突出的錯配風險。

• 嚴重失敗率被平均數掩蓋：平均成功率 95% 但嚴重失敗率高達 2% 的 Agent，在金融交易、醫療醫囑等場景不可接受。企業若僅盯端到端成功率，將低估災難性錯誤所致的合規與賠償成本。

• 追求成功率的成本爆炸：為了提高最後幾個百分點的成功率，工程團隊可能需要引入昂貴的多 Agent 投票、超大規模上下文、海量工具呼叫重試，導致單任務推論成本和時間上升數倍甚至數十倍，破壞商業模型。例如將成功率從 90% 推至 95% 所增加的邊際成本，可能超過人工處理成本，形成經濟學上的“過度自動化”陷阱。

• 不可預測的級聯效應：在多 Agent 或 Agent 作為工具呼叫的場景中，一個低頻率的失敗會汙染上游排程決策，導致整條自動化鏈紊亂。這種級聯風險尚未被充分的壓力測試所覆蓋。

• 責任歸屬與監管模糊：當 Agent 自主執行且失敗造成損失時，責任在模型提供商、架構開發者還是終端使用者？當前法律架構（尤其在除歐盟 AI Act 以外的地區）仍屬缺位。如果監管未來規定 Agent 執行需要明確的成功率揭露與失敗備份機制，現有大量系統將面臨合規風險。

• 供應商鎖定與資料隱私：要獲得高成功率，企業常需要將內部資料、API 與工作流深度整合至特定模型提供商的 Agent 棧，一旦更換底層模型，成功率可能劇跌，形成鎖定效應。同時，將敏感資料暴露給 Agent 的校驗和日誌系統也加大了隱私風險。

誤讀糾偏

誤讀一：“Agent 成功率 90% 已經很好了，剩下 10% 人工兜底就行。”
糾偏：長鏈任務失敗的恢復成本通常遠超 10% 的時間佔比。一次失敗往往汙染中間狀態，需要重置環境、重新認證、對賬沖銷等。如果失敗恰好發生在安全關鍵步驟，“10%”的容許錯誤率可能直接引發業務事故。必須結合嚴重失敗率、失敗恢復時間（MTTR）等一併衡量，不能僅看粗糙成功率。

誤讀二：“更強的基礎模型自然帶來更高成功率，所以做 Agent 只需等模型升級。”
糾偏：即便單步正確率達到 99%，30 步無並行保護的端到端理論成功率也只約 74%。需要系統架構上的狀態檢驗點、事務回滾、並行備選、多路徑投票等工程手段，才能打破指數衰減的魔咒。Agent 成功率是系統工程能力的總和，而不是單純模型能力的投射。

誤讀三：“只要引入自我反思機制，成功率就會大幅躍升。”
糾偏：反思和重試可以提升漸進成功率，但其有效性依賴模型能否準確識別錯誤和生成有效的修正策略。如果模型最初的動作已經導致不可逆環境改變，或者反思過程同樣產生幻覺，反思可能只是浪費更多令牌和步驟，並未轉化為實際成功。另外，過度反思會顯著增加延遲與成本。

誤讀四：“成功率只要在標準基準上高，生產環境就沒問題。”
糾偏：標準基準的任務分佈、網站快照和工具集合是靜態的，真實世界的分佈漂移（網頁改版、API 版本更新、指令自然多樣性）可能讓成功率的降幅遠超預期。持續整合中的“成功率迴歸測試”和混沌工程（故障注入）是必要補充，不能將實驗室數字等同於部署承諾。

誤讀五：“成功率是唯一重要指標。”
糾偏：除成功率外，任務完成速度（延遲）、成本（需考量 token 消耗與工具呼叫費用）、使用者體驗滿意度以及可解釋性同樣決定