AI Agent 上生產的最後一公里:可觀測性、執行時審計與評估怎麼做(2026)
Demo 能跑通,不等於能上生產。真正的卡點是"怎麼證明 agent 可信"。本文拆解 demo 到生產之間的三道護欄——可觀測性、執行時審計、評估契約——用雜湊鏈審計與 270 次契約全通過的實證,講清怎麼向客戶安全團隊舉證、以及可觀測性與評估平臺怎麼選型。
把一個 AI agent 送進生產,難點已經不在"能不能跑通 demo",而在"能不能證明它可信"。要跨過這道坎,需要三道護欄:可觀測性(執行時看得見發生了什麼)、執行時審計(能向第三方證明發生了什麼、且記錄改不了)、評估(上線前後驗證它做得對不對)。三者缺一,agent 就停在"演示能過、生產不敢上"的最後一公里。本文用雜湊鏈審計、270 次工程契約全通過等實證,拆開這三道護欄各自解決什麼、怎麼落地,以及可觀測性和評估平臺該怎麼選型。
這也是我們上一篇《為什麼 AI agent 在生產環境會失敗》的續篇——那篇講"為什麼會失敗"(診斷),本篇講"怎麼觀測、審計、評估讓它在生產裡活下來"(解法)。
AI agent 上生產前,到底要做哪些可觀測性和評估?
一句話答案:至少要做三件事——給執行時裝上可觀測性(traces / logs / metrics)、給關鍵行為加上執行時審計(可驗證、不可篡改的證據鏈)、給上線質量建立評估契約(用程式碼而非提示詞兜住確定性)。
這三件套對應三個不同的問題。可觀測性回答"它現在在幹什麼、慢在哪、錯在哪";執行時審計回答"事後我能不能向客戶、合規、安全團隊證明它當時到底做了什麼";評估回答"它這次改動之後,行為是變好了還是回退了"。
值得強調的是,評估並不等於"再測一遍模型輸出"。arXiv 上一篇 2026 年 7 月的論文《From Prompts to Contracts: Harness Engineering for Auditable Enterprise LLM Agents》提出的思路是:把需要確定性的行為從提示詞裡"下沉"到程式碼、manifest、schema 和校驗件中,圍繞一個可替換的"組合邊界(composition boundary)"來組織——也就是說,評估的物件是工程化的契約,而不只是一段自然語言指令的運氣。而執行時審計這一層,已經有像 Halo 這樣的開源執行時在做:把每一次工具呼叫、模型呼叫、資料訪問都記成日誌。下面幾節逐一展開。企業為什麼連"跑通"之後仍然上不了線,可以參照《為什麼企業 AI 落地這麼難》裡的系統性阻力。
可觀測性和評估到底有什麼區別?
一句話答案:可觀測性關注執行時"發生了什麼"(traces / logs / metrics),評估關注上線前後"做得對不對"(質量 / 迴歸 / 紅隊),執行時審計則關注"能不能向第三方證明發生過什麼"(不可篡改)——三者目標不同,不能相互替代。
很多團隊把這三件事混為一談,結果是:裝了 tracing 卻沒有評估門禁,模型一改版就在生產裡悄悄回退;或者做了離線評估卻沒有執行時證據,出事時拿不出可信記錄。用三類主流工具的定位來對照,區別會更清楚:mlflow 提供 tracking 加 evaluation,promptfoo 側重 evaluation 加紅隊對抗測試,comet-ml/opik 覆蓋 debug / evaluate / monitor 的全鏈路。下表把四個維度拆開:
| 維度 | 可觀測性(Observability) | 評估(Evaluation) | 執行時審計(Runtime Audit) |
|---|---|---|---|
| 回答的問題 | 它現在在幹什麼、慢在哪、錯在哪 | 它這次改動做得對不對、有沒有回退 | 事後能不能證明它當時做了什麼 |
| 觸發時機 | 執行時持續 | 上線前 + 迴歸 + 定期紅隊 | 每次關鍵呼叫即時留痕 |
| 典型產出 | 每一步 tool call 的 trace、延遲與 token 指標 | 跑一批對抗 prompt 看通過率 / 洩漏率 | 每次工具/模型/資料訪問的雜湊鏈日誌 |
| 物件導向 | 工程與 SRE | 質量與產品 | 客戶安全團隊、合規、審計方 |
| 代表工具 | opik、mlflow tracing | promptfoo、mlflow evaluation | Halo(雜湊鏈、不可篡改) |
一個實操判據:如果你只能向工程團隊解釋系統狀態,卻沒法向客戶的安全團隊出示不可抵賴的證據,那你有可觀測性,但沒有執行時審計——而在企業場景裡,後者往往才是簽約的前提。
怎麼向客戶的安全團隊證明 agent 沒亂動他們的資料?
一句話答案:靠執行時審計留下一條"供應商在執行、但供應商自己也改不了"的證據鏈——把每次工具呼叫、模型呼叫、資料訪問都寫成雜湊鏈式(hash-chained)的追加日誌,任何持有 checkpoint 的一方都能驗證記錄未被篡改。
這正是開源專案 Halo(2026 年 7 月 7 日釋出於 Show HN,37 分、23 條討論)給出的答案,它把自己定義為"the audit trail the vendor runs but cannot edit"(供應商執行、卻無法編輯的審計追蹤)。它的幾個設計點對企業交付很關鍵:
- 雜湊鏈追加日誌:每一次工具呼叫、模型呼叫、資料訪問都追加成一條鏈式記錄,任何一方只要持有某個 checkpoint,就能校驗這條鏈是否被事後改動過——即"可驗證不可篡改(tamper-evident)"。
- 隱私友好:原始入參不落庫,只存雜湊加脫敏摘要,因此審計證據本身不會成為新的資料洩漏面。
- 易嵌入:零執行時依賴、約 4,300 行 Python,已提供 OpenTelemetry、LangChain、MCP、OpenAI Agents SDK、Claude Code 等介面卡,能直接掛進現有 agent 棧。
對 FDE(Forward Deployed Engineer,前向部署工程師——把 agent 真正落進客戶生產環境的那個角色)來說,這類證據鏈的意義是把"相信我們沒亂動資料"換成"這裡是可驗證的記錄,你自己核"。這也是我們在企業 AI 作業系統裡堅持"每個專屬智慧體各自可審計"的原因。
為什麼只寫 prompt 或規則不夠,一定要工程化護欄?
一句話答案:因為提示詞復現不了確定性保證——同一條規則,靠 prompt 寫會時靈時不靈,靠程式碼/harness 兜才是承重的。
前面提到的那篇 arXiv 2607.08028給出了到目前為止最硬的一組對照資料。研究者在 5 家韓國企業集團、共 25 家上市公司的公開資料上做實驗,跨 3 個託管模型,讓確定性行為走"組合邊界"的工程化契約:270 次 composition-boundary 執行契約全部通過。
更說明問題的是失敗一側的對照:僅靠 prompt 指令時,"推薦措辭"越界和"內部 trace 洩漏"這兩類違規會直接抵達終端使用者;而換成 harness(把校驗下沉到程式碼與 schema)後,這些違規被完全攔截。 結論很直接——程式碼保證是承重牆,提示詞只是裝飾層,你沒法讓一句自然語言指令去承擔"絕不洩漏內部 trace"這種硬約束。這一節的取捨,和《為什麼 AI agent 在生產環境會失敗》裡反覆出現的"demo 靠提示詞、生產靠工程"是同一件事。
Agent 可觀測性 / 評估平臺有哪些,怎麼選型?
一句話答案:主流的三個開源平臺各有側重——mlflow 偏工程平臺與 tracking,promptfoo 偏評估與紅隊,opik 偏執行時監控;若還要向第三方證明"發生過什麼",再補一層像 Halo 這樣的不可篡改審計。
選型不必糾結"誰最好",而要看你當下缺的是哪道護欄。下表是 2026 年 7 月中旬的一個快照(Star 數與定位均取自各專案本週仍在更新的倉庫):
| 工具 | 定位 | 強項 | 適合場景 | Star(2026-07) |
|---|---|---|---|---|
| mlflow | agents/LLMs 的 AI engineering 平臺 | tracking + evaluation,實驗與版本管理成熟 | 已有 ML 平臺、想把 agent 納入統一治理 | 26,970★ |
| promptfoo | prompt / agent / RAG 測試 | evaluation + red teaming,對抗與洩漏測試 | 上線前門禁、安全紅隊 | 23,133★ |
| comet-ml/opik | agentic workflow 的可觀測層 | debug / evaluate / monitor 全鏈路 | 生產執行時監控與排障 | 20,528★ |
| Halo(halo-record) | 不可篡改執行時審計 | 雜湊鏈、tamper-evident、只存雜湊+脫敏摘要 | 需向客戶/合規出示可驗證證據 | 開源 · Show HN 37p |
一個務實的組合:用 opik 或 mlflow 兜執行時可觀測,用 promptfoo 做上線前評估與紅隊,用 Halo 補上向第三方舉證的審計層——三者分別對應前面三道護欄。如果你想把這套護欄整合進一套統一的企業 AI 作業系統(其賣點正含"各自可審計的專屬智慧體"),而不是自己拼裝,可以從這裡切入。
主動式 agent 上線後,除了它自己還要監控什麼?
一句話答案:還要監控它所觀測的"企業狀態"——主動式(proactive)agent 的價值在於持續盯著業務變化並及時浮現問題,所以可觀測的物件不只是 agent 內部,還包括它對外部世界的感知質量。
arXiv 另一篇 2026 年 7 月的論文《Context Graphs for Proactive Enterprise Agents》給出了這一層的量化標尺:主動式 agent 在持續監控企業狀態時,Precision@5 達到 0.83、誤報率 0.11,而平均"浮現時間"從反應式基線的 47 分鐘壓縮到 30 秒以內(47min → 30s)。 這組數字說明,當 agent 從"等你問"變成"主動報",你要監控的指標就多了一層:它的判斷準不準(precision)、吵不吵(誤報率)、快不快(浮現時間)。缺了這層監控,主動式 agent 很容易變成"要麼漏報、要麼天天誤報"的噪聲源。
這些護欄值得投入嗎?落地會不會導致裁員?
一句話答案:值得,而且資料不支援"AI 落地=裁員"這一焦慮——重投入 AI 的公司,採用後反而在擴招。
給 agent 上生產裝三道護欄確實要花工程成本,但它換來的是能簽約、能通過安全審查、能規模化複製的生產系統,而不是永遠停在 demo。商業側的實證也偏向樂觀:Ramp Economics Lab 2026 年 6 月 30 日的研究《Companies hire more after AI adoption》基於超過 21,000 家美國公司的樣本發現,重投入 AI 的公司在採用後兩年內,總員工數增長約 10%、入門級崗位增長約 12%。換句話說,把 AI agent 真正落進生產、並用護欄讓它可信,更像是在為團隊創造槓桿,而不是替換團隊。
如果你正卡在"demo 能跑、生產不敢上"的最後一公里,6AM TECH(晨啟科技)的 FDE 諮詢可以幫你把可觀測性、執行時審計與評估這三道護欄落進客戶的真實環境。更多常見問題見我們的 FAQ。
