從試點到生產：五階段代理部署手冊

差距，已量化

試點到生產的差距不再是定性判斷。它是一個可測量的比率。

First Page Sage 分析了 2026 年 2 月至 6 月的 30+ 份研究報告中的 16,000+ 家企業。在已採用代理 AI 的企業中，64% 仍處於試驗階段。只有 12% 已完全部署。每有一家企業在生產中執行代理，就有超過五家仍在執行永遠無法跨越界線的試點。

放棄資料解釋了原因。First Page Sage 發現 43% 的失敗代理 AI 專案因不明確的商業價值或 ROI 而被放棄。另有 38% 因資料品質不足而失敗。另有 35% 因成本攀升而被終止。模式是一致的：試點證明模型能執行任務，但當任務需要變成有可測量結果的生產整合時就會停滯。

在採購領域，差距更大。Art of Procurement 報告稱 94% 的採購高階主管每週至少使用生成式 AI，49% 在 2024 年試點了 GenAI——但只有 4% 實現了大規模部署。94% 採用 / 4% 規模化部署的比率是所有功能領域中試點到生產差距最極端的版本。

linesncircles 直接量化了失敗機制：60% 的代理 AI 試點無法規模化。根本原因不是模型能力——而是架構性的。

失敗模式	根本原因	頻率
流程鏡像	將人類工作流程自動化而不為自主執行器重新設計	38%
無可觀測性	代理作為黑盒運作，無稽核追蹤	27%
上下文崩潰	代理在多步驟管線中遺失任務上下文	22%
工具過載	單一代理被賦予 30+ 工具且無優先路由	13%

最主要的根本原因——38% 的流程鏡像——正是本文直接解決的問題。

自動化幻覺

Deloitte State of AI in the Enterprise 2026 發現只有 34% 的企業真正在圍繞 AI 重新構想營運，這為失敗模式命名：自動化幻覺。一個組織拿現有的工作流程——比如說，一個應付帳款職員在遺留 ERP 中點擊審核發票——把 AI 代理包裹在上面。代理模仿人類的點擊。工作流程沒有改變。結果是代理的表現不如它本應取代的人類，因為工作流程是為人類的優勢（視覺辨識、上下文判斷、例外處理）設計的，而不是為代理的優勢（API 呼叫、結構化資料處理、平行執行）設計的。

同樣的工作流程用 API 優先觸發器和結構化資料交接重新設計後，以 10× 速度執行，錯誤率降至 5%。區別不在於模型。區別在於架構。

代理不是一個快速的人類。它是一個非同步的、上下文敏感的、機率性的系統，需要結構化輸入、確定性決策門和明確的失敗處理。把代理釘在一個為人類設計的工作流程上，恰好產生了 linesncircles 識別的失敗模式：代理在人工交接點遺失上下文（上下文崩潰，22%），淹沒在人類螢幕提供但代理無法優先排序的工具中（工具過載，13%），在沒有人類工作流程透過郵件執行緒和審核鏈隱含承載的稽核追蹤下運作（無可觀測性，27%）。

代理相容架構的五個屬性

在代理可以部署之前，它將要操作的工作流程必須重新設計為代理相容的。linesncircles 確定了五個屬性來區分準備好為自主執行器服務的工作流程和未準備好的：

1. 結構化資料交接。 每個任務邊界傳遞一個型別化 schema——一個帶命名字段的 JSON 物件，而非自由文字。以結構化格式接收請求的代理可以驗證它、提取所需欄位並傳遞給下一步。接收自由文字的代理必須解析它、猜測結構，並冒著在解析中遺失資訊的風險。步驟之間的邊界是上下文崩潰發生的地方。結構化 schema 防止了它。

2. 明確的成功標準。 代理必須能夠評估任務是否完成。「處理 RFQ」不是成功標準。「報價已建立，所有行項目已對照目錄解析，定價按客戶層級套用，可用性鎖定已取得並設過期時間，報價狀態設為進行中」才是。沒有明確的成功標準，代理要麼過早停止（工作不完整）要麼永不停止（無限迴圈）。成功標準是代理的終止條件。

3. 冪等工具呼叫。 相同工具呼叫用相同參數必須在重試時產生相同結果且無副作用。如果代理為 50 個單位的批次呼叫 acquire_availability_hold 且呼叫超時，重試不能取得 100 個單位。冪等性使代理管線可以安全重試——而重試使它們在生產中可靠，因為網路超時和暫態故障是常態。

4. 持久記憶層。 代理的狀態——它做了什麼、正在做什麼、接下來需要做什麼——必須在對話上下文視窗之外持久化。上下文視窗是易失的：受 token 限制約束，在工作階段間清除，且不可查詢。持久記憶層——資料庫、鍵值存儲、狀態機——在工作階段間、故障間以及人工交接間持有代理的狀態。

5. 硬停止條件。 代理必須知道何時升級給人類。「當置信度降到閾值以下」是硬停止。「當定價工具傳回超出預期範圍的結果」是硬停止。「當同一工具連續失敗三次」是硬停止。沒有硬停止條件，代理要麼執行到產生錯誤結果，要麼在任意點停止。硬停止是讓代理保持在其能力範圍內的機制。

將這些聯繫在一起的架構原則：每個代理管線應該能在三分鐘內被非技術利害關係人審查。如果你無法用通俗語言解釋代理在每一步做什麼，可觀測性層就不足以支撐生產部署。

五階段部署模型

五個屬性定義了工作流程應該是什麼樣。五階段部署模型定義了如何從現有的人類工作流程到達那裡。它是自動化幻覺的操作性答案。

第一階段：流程考古（2–3 週）

在編寫任何代理程式碼之前，目標工作流程被端到端映射。每個決策點、每個觸及的系統、每條例外路徑都被記錄。目標不是複製工作流程——而是質疑它。

一個典型發現：人類工作流程表面上需要的 40% 的工具表面區域在編寫任何代理程式碼之前就被消除了。人類工作流程累積了人類執行必需的步驟（視覺確認、手動資料重錄、跨系統複製貼上），但這些對代理來說不必要。流程考古將其剝離。剩下的是最小可行工作流程——真正產生業務結果的步驟。

這一階段是自動化幻覺被打破的地方。團隊映射人類做什麼，識別哪些步驟是人類權宜之計的開銷，並用結構化資料交接和明確成功標準重新設計剩餘步驟。輸出不是現有流程的流程圖——而是代理可以執行的重新設計的工作流程。

IdeaBosque 的一週 Discovery 階段直接映射到流程考古。Discovery 產出的系統清單、工作流程映射和固定範圍是這一階段的工件——最小可行工作流程、它觸及的系統以及代理建構的範圍。

第二階段：工具和權限範圍界定

手握重新設計的工作流程，團隊定義最小可行工具集——恰恰是代理需要的工具，不多一個。每個工具在安全團隊註冊。資料存取和速率限制按工具定義。服務帳戶按代理類別以最小權限存取建立。

這一階段防止工具過載——13% 的失敗模式。一個被賦予 30 個工具且無優先路由的代理會用錯工具、亂序使用工具，或把上下文視窗花在推理該呼叫哪個工具上。一個被賦予 5 個工具、每個都有明確目的和型別化輸入 schema 的代理，會在正確時間使用正確工具。工具範圍界定不是安全練習——是精度練習。

在 SilvaEngine 的 ai_mcp_daemon_engine 中，工具範圍界定在兩個層面執行。儲存在 DynamoDB 中的模組配置決定了執行時載入哪些模組——因此哪些工具。_apply_partition_defaults 方法從傳入請求的 endpoint_id 和 part_id 構建分割區鍵，此鍵在所有資料模型上作為 DynamoDB 哈希鍵執行。範圍限定為租戶 A 的代理無法查詢租戶 B 的資料，因為分割區鍵不同且沒有跨分割區查詢路徑。最小權限在資料層執行，而非應用層。

第三階段：可觀測性基礎設施

日誌堆疊在代理部署之前建構，而非之後。每次工具呼叫都記錄時間戳、輸入參數、輸出內容、狀態和持續時間。每次 LLM 推理都記錄 prompt、回應和所用模型。每個決策分支——代理選擇一條路徑而非另一條——都記錄推理過程。

這一階段防止無可觀測性失敗模式（27%）。作為黑盒運作的代理無法除錯、無法稽核、無法改進。當生產代理產生錯誤報價時，問題不是「哪裡出了錯」——而是「哪個工具呼叫，在哪一步，用什麼輸入，產生了錯誤輸出。」沒有逐工具稽核記錄，這個問題無法回答。

在 ai_mcp_daemon_engine 中，mcp_utility.py 中的 execute_decorator 包裹每次工具呼叫。在工具函式執行前，裝飾器在 DynamoDB 中建立一條狀態為 initial 的 MCPFunctionCallModel 記錄，捕獲分割區鍵、工具名稱、參數和時間戳。執行後，更新記錄的內容、狀態為 completed、time_spent（毫秒）。如果工具拋出例外，裝飾器捕獲它，將記錄更新為狀態 failed 並附完整 traceback，然後重新拋出。三個本地二級索引支援按 MCP 類型、按工具名稱、按更新時間戳查詢——維運人員可以問「顯示過去一小時定價工具的每次失敗呼叫」並從單次索引查詢獲得答案。

這是使代理可在三分鐘內審查的稽核追蹤。它也是後續金絲雀階段的資料來源。

第四階段：影子模式金絲雀部署（2–4 週）

代理與人類工作流程並行執行。代理不採取真實操作——它處理相同的輸入並產生與人類輸出進行比較的輸出。偏離每日追蹤。

閾值是具體的。偏離率超過 15% 表明存在 prompt 工程或流程重設計問題——代理未準備好進入生產。偏離率低於 5% 且連續五個工作日維持是晉升標準。代理只有在證明了對人類基線的一致準確後才晉升到生產。

這一階段是重新設計的工作流程與現實世界相遇的地方。流程考古識別了最小可行工作流程。工具範圍界定給了代理正確的工具。可觀測性基礎設施記錄了每次呼叫。影子模式測試代理在重新設計的工作流程上使用範圍限定的工具是否能產生匹配或超越人類基線的結果。如果不能，診斷在稽核追蹤中——團隊可以將偏離追溯到特定工具呼叫、特定輸入和特定輸出。

第五階段：人工交接協議

每條升級路徑在代理上線前定義並測試。代理必須知道：升級給誰、以什麼格式、在什麼 SLA 內。為非技術利害關係人發布內部代理到人工交接 runbook。

這一階段是五個屬性中的硬停止條件變為可操作的地方。代理的硬停止——置信度閾值、工具失敗計數、輸出範圍檢查——映射到特定的人類接收者和特定的升級格式。定價異常升級給銷售營運主管。可用性檢查失敗升級給庫存經理。重複工具失敗升級給工程值班。交接不是後備——它是工作流程的設計部分，使用與代理間轉換相同的結構化資料交接。

Databricks 2026 State of AI Agents 報告 發現擁有治理工具的組織——第三至五階段描述的可觀測性、斷路器和交接協議——比沒有的組織多推動 12× 的專案進入生產。擁有評估工具的組織多推動 6×。治理基礎設施不是開銷。它是決定試點能否變成生產的乘數。

反面證據：部署紀律，而非技術

NVIDIA State of AI Report 2026（3,200+ 受訪者，2025 年 8–12 月）提供了試點失敗資料的反面證據。88% 的組織報告 AI 增加了年收入。87% 報告 AI 降低了年成本。44% 正在部署或評估 AI 代理。86% 預計 2026 年預算會增加。

看不到 ROI 的 56%（PwC）與看到收入增加的 88%（NVIDIA）之間的差距不在於技術。相同的模型、相同的 MCP 協定、相同的編排框架對兩組都可用。差距在於部署紀律——執行試點的組織和執行五階段部署模型的組織之間的區別。

五階段模型不是評估 AI 的框架。它是部署產生可測量結果的代理的操作手冊。已完全部署代理 AI 的 12%（First Page Sage）不是擁有最佳模型的組織。而是那些在代理上線前做了流程考古、界定工具範圍、建構可觀測性、執行金絲雀並定義交接協議的組織。

採購標準

五階段模型轉化為買家可以向代理供應商提出的四個問題：

1. 你們的部署流程是什麼樣的？ 如果答案是「我們設定模型然後你就走了」，就沒有流程考古。代理將被釘在人類工作流程上，自動化幻覺將產生 38% 的失敗模式。

2. 你們如何界定工具集範圍？ 如果答案是「代理可以存取一切」，就沒有工具範圍界定。工具過載（13%）是預期結果。

3. 我能看到最近 100 次工具呼叫的稽核追蹤嗎？ 如果答案是「我們有 CloudWatch 日誌」，就沒有結構化的逐工具稽核記錄。可觀測性層是可以除錯的代理和只能重啟的代理之間的區別。

4. 你們的金絲雀流程是什麼？ 如果答案是「我們在 staging 測試」，就沒有影子模式。Staging 測試程式碼，不測試代理對真實輸入的行為。影子模式測試代理。

這四個問題映射到第一至四階段。一個無法回答它們的供應商在執行試點模式——那個產生 60% 失敗率的模式。

---

一家執行 NetSuite、BigCommerce 和三個供應商目錄的經銷商透過五階段模型部署代理。流程考古端到端映射了 RFQ 工作流程並消除了 40% 的人類權宜之計的手動查找步驟。工具範圍界定給了代理五個 MCP 模組：NetSuite 連接器、BigCommerce 目錄、供應商目錄圖、定價引擎和可用性鎖定管理器——每個都有最小權限憑證和速率限制。可觀測性基礎設施將每次工具呼叫記錄到可按工具名稱、狀態和時間範圍查詢的 DynamoDB 稽核追蹤中。影子模式針對真實 RFQ 執行三週，偏離低於 5%。人工交接協議將定價異常路由給銷售營運主管，將可用性失敗路由給庫存經理。代理在第 8 週上線，處理真實 RFQ，每一步都有記錄，每個模組都可透過設定停用。報價周轉從三天降到不到一小時。這個建構就是五階段模型應用於真實工作流程。

申請一次範圍界定的建構。 一週 Discovery。你獲得系統清單、工作流程映射和固定範圍——無論你是否與我們合作建構。