別再迷信 Prompt Engineering：打造可維運的 AI Agent，關鍵在於「可觀測性」

當我們將大型語言模型（LLM）驅動的 Agent 從本地開發環境推向真實世界的生產環境時，真正的挑戰才剛開始。許多團隊過度專注於優化提示詞（Prompt Engineering），期望透過更精巧的指令讓 Agent 表現得更聰明。然而，我認為這是一個普遍的迷思。一個真正能進入正式環境、處理關鍵任務的 Agent，其核心價值並非最會回答問題，而是最可觀測、可追蹤、可恢復、可驗證。監控、狀態持久化、證據留存與失敗回報等軟體工程原則，遠比模型表面的流暢對答更為重要，這才是區分玩具與工具的關鍵。

為什麼在本地端運作流暢的 Agent，一到正式環境就靜默失靈？

在開發階段，我們通常在受控的環境中與 Agent 互動，一切看起來都很完美。Agent 能夠理解指令、執行任務、回報結果。但一旦部署到生產環境，面對非預期的輸入、網路延遲、API 限制與長時間運行的挑戰，許多潛在問題便會浮現。這些問題往往不是模型理解力的問題，而是系統韌性（resilience）的匱乏。

我們經常看到以下幾種典型的「靜默失敗」模式：

• 吞噬例外：Agent 在執行多步驟任務的途中遭遇 API 錯誤或內部異常，但它並未回報失敗，而是直接跳過，最後給出一個看似成功卻內容不完整的結果。
• 缺乏證據：Agent 回報「任務已完成」，例如「已將分析報告儲存至指定路徑」，但實際上因為權限問題或路徑錯誤，檔案從未被寫入。由於缺乏執行紀錄（log），我們無從追查失敗的根本原因。
• 狀態遺失：需要長時間運行的 Agent（例如持續監控市場動態），在系統重啟或程序崩潰後，無法從中斷點恢復，所有記憶與上下文都消失了，只能從頭來過。根據 Google 的 SRE 手冊，這種缺乏狀態持久化的系統，其可用性註定極低。
• 違規而不自知：Agent 在與外部系統互動時，可能無意中超出了 API 的速率限制（rate limit），例如每分鐘超過 60 次請求。它不會主動回報這個違規行為，只會導致後續任務不斷失敗，讓問題排查變得極為困難。

這些問題都無法透過「把指令寫得更清楚」來解決。它們是系統性的工程缺陷，需要我們將視角從「與模型對話」提升到「建構可靠的軟體系統」。

從「提示詞」到「工程化」：Agent 可靠性的四大支柱

要打造一個生產級別的 Agent，我們必須借鏡傳統軟體開發中的可靠性工程（Reliability Engineering）原則。與其將 Agent 視為一個黑盒子，不如將其視為一個由多個可監控元件組成的系統。我認為，Agent 的可靠性建立在四大支柱之上：

一個無法被觀測的系統，就是一個無法被管理的系統。對於自主運行的 AI Agent 而言，這句話尤其真確。

首先是可觀測性（Observability）。我們需要詳細記錄 Agent 的每一步決策，包括它接收到的輸入、內部的思考鏈（Chain-of-Thought）、呼叫了哪個工具、工具的回傳值，以及最終的輸出。像 LangSmith 這類的工具，正是為了解決這個問題而生，它提供了完整的執行追蹤（trace），讓開發者能輕易地診斷問題。

其次是狀態持久化（State Persistence）。對於需要跨越多個會話或長時間運行的 Agent，必須將其記憶和當前任務狀態儲存在外部資料庫（如 Redis 或 PostgreSQL）中。這確保了即使系統中斷，Agent 也能在恢復後讀取先前的狀態，從上次離開的地方繼續執行，而不是每次都從零開始。這在處理需要數小時甚至數天的複雜任務時至關重要。

第三是可驗證性（Verifiability）。Agent 的任何產出，特別是那些會對外部世界產生影響的操作（如發送郵件、修改資料庫），都必須留下可供驗證的「證據」。這不僅僅是日誌，更可能是操作的快照、資料庫交易 ID，或是 API 回傳的成功訊息。這讓我們能夠在事後審計 Agent 的行為是否符合預期，也是建立信任的基礎。一些研究如 AgentBench 框架，也強調了對 Agent 行為進行基準測試和可驗證評估的重要性。

最後是可恢復性（Recoverability）。當 Agent 遇到可預期的錯誤時（例如暫時性的網路問題導致 API 回傳 503 錯誤），它應該具備自動重試機制，例如最多重試 3 次，每次間隔指數級增加。對於無法恢復的嚴重錯誤，系統應立即停止並發出警報，而不是讓 Agent 繼續在錯誤的狀態下運行，造成更大的損失。

Agent 的可靠性工程，我們該如何具體實踐？

將上述原則付諸實踐，需要開發流程和架構上的轉變。首先，放棄在 Jupyter Notebook 中進行端對端的 Agent 開發。Notebook 適合快速實驗，但不適合建構穩定的系統。我們應該從一開始就採用模組化的程式碼結構，並導入結構化日誌（structured logging）。

在架構上，可以考慮引入一個「協調器（Orchestrator）」的角色。這個協調器負責管理 Agent 的生命週期、持久化其狀態，並監控其執行的每一步。Agent 本身則專注於思考和工具調用。這種關注點分離的設計，讓系統更容易測試和維護。例如，在 LangChain 框架中，自從 v0.1.0 版本開始，就愈來愈強調生產環境的部署與可觀測性，提供了更多與外部監控工具整合的介面。

此外，建立一個模擬生產環境的「演練場（staging environment）」也至關重要。在這個環境中，我們可以模擬各種異常情況，例如 API 突然失效、輸入資料格式錯誤等，以測試 Agent 的容錯與恢復能力。學術界也在探索更複雜的評估環境，例如 SWE-bench，它利用真實的 GitHub issue 來評估 AI Agent 解決實際軟體工程問題的能力，這也為我們提供了驗證 Agent 可靠性的新思路。

總結來說，打造一個真正有用的 AI Agent，是一項嚴肅的軟體工程挑戰。當我們將目光從華麗的展示轉向枯燥但關鍵的可靠性指標時，我們才算真正走在通往通用人工智慧助手的正確道路上。未來的競爭優勢，將屬於那些能夠建構並維運大規模、高可靠 Agent 系統的團隊。

延伸閱讀

• Site Reliability Engineering: How Google Runs Production Systems
• LangSmith Documentation
• AgentBench: Evaluating LLMs as Agents

我是江中喬，專注於 AI Agent Architecture、Memory Governance 與 Cognitive Diversity，持續研究如何打造能夠長期協作、可信任且可治理的 AI 系統。