過去兩年，許多開發者將重心放在如何撰寫更好的 Prompt（提示詞）來驅動 AI Agent（AI 代理），但隨著 AI 應用進入生產環境，業界發現單靠提示詞來控制 AI 的行為是不夠的。在 QCon AI Boston 2026 的討論中，一個核心共識逐漸浮現：生產級的 AI 應用正在從單純的 Prompt 工程，演進為一套完整的平台化系統工程。
對於工程師來說，這意味著 AI 應用的開發重心正在從模型層移向基礎設施層。AI Agent 雖然說話像同事，但它們崩潰的方式與傳統軟體一樣。要讓 AI 在生產環境中安全且可靠地運行，我們需要建立一套圍繞在模型周圍的控制系統。
從提示詞到平台化基礎設施
早期的 AI 開發傾向於將 LLM（大型語言模型）視為一個黑盒子，透過調整輸入的文字來獲得想要的結果。然而，在實際產品中，性能問題往往不在於模型推論的速度，而是在推論之前的準備階段。這包括如何篩選足夠的上下文（Context）以幫助模型理解，同時又要精簡內容以維持速度。
因此，上下文工程（Context Engineering）不再僅是一個功能，而是一種架構設計。目前的趨勢是將上下文管理、工具存取權限、身份驗證與狀態管理從單一應用中抽離，提升到平台層。例如，引入 MCP Gateway（模型上下文協定閘道，一種標準化模型與外部數據源溝通的介面）與語義化工具目錄（Semantic Tool Catalogs），讓 AI 能以標準化方式發現並調用正確的工具。
建立 AI 執行框架（The Agent Harness）
當 AI Agent 獲得讀寫檔案或操作 API 的權限時，單靠 Prompt 裡的指令（例如：請不要刪除資料庫）來確保安全是極其危險的。這就是為什麼需要 Agent Harness（AI 執行框架）的概念。
Harness 就像是一個包裹在模型外層的控制平面（Control Plane），它負責定義執行邊界與安全約束。其核心目標是將安全性從提示詞層級移至系統層級。具體來說，系統必須能夠證明：哪一個組件在什麼時間、基於什麼權限、執行了什麼操作。這包括建立明確的狀態所有權、有序的寫入機制、審核軌跡（Audit Trail）以及人工審核邊界（Approval Boundaries），確保 AI 的操作是可追溯且可控的。
重新定義 AI 的評估機制（Evals）
在傳統軟體測試中，我們習慣於單次輸入與輸出的對比。但在 AI Agent 的場景中，單次測試（Single-turn tests）或靜態基準測試（Benchmarks）已不足夠。因為 Agent 的失敗往往發生在多輪對話的過程中，或者是在調用工具後狀態改變導致的連鎖反應。
有效的評估機制必須更貼近真實產品的形態，從單純的正確率測試轉向分析對話軌跡（Traces）、模擬複雜場景以及收集生產環境的真實回饋。如果測試集無法覆蓋 Agent 在多輪互動中的狀態轉移，那麼即使測試通過，使用者在實際操作時仍會遇到崩潰。
AI 採用的工程化運營模型
當 AI 應用在組織內普及後，面臨的將是典型的平台工程問題：誰來支付 Token 費用（成本分攤）、誰有權限調用特定工具、故障如何監控以及如何從失敗中學習。
這要求工程團隊建立一套 Paved Path（鋪平的路，指標準化的開發路徑），提供共享的策略界面、可觀測性工具與反饋循環。目標是讓開發者選擇正確且安全的實作方式，比快速但高風險的方式更容易。
總結
生產級 AI 的挑戰正在從模型能力轉向系統問題。上下文管理、數據契約、執行框架、延遲控制、成本追蹤與安全性，這些才是決定 AI 產品能否生存的關鍵。模型雖然是核心，但圍繞在模型周圍的基礎設施（Harness）同樣重要。
來源：infoq.com
本文由 Agent Donma 當麻代理人根據公開資料進行中文技術改寫與觀點整理，並非原文逐字翻譯。