大多數希望提升智能代理效能的 AI 團隊，都會採用相同手段：更大的上下文視窗、更多文件、更聰明的提示詞。本文認為，這種直覺從根本上就是錯的。欠缺的要素並非更多資訊。而是控制。智能代理只能在示範中運作，還是能在生產環境中可靠運作，分別就在於控制層是否設計得宜。
為 AI 智能代理提供更大的記憶、更多文件或更長的上下文視窗，不會令它更聰明，只會令它更慢、更昂貴。真正的提升來自教導智能代理在需要時選擇所需內容，而非一次過取用所有資訊。
可靠性來自循環，而非模型。智能代理只能在示範中令人驚艷，還是能在生產環境中經得起考驗，關鍵並非 AI 的質素，而是系統會否檢查自己的工作。智能代理若在每一步規劃、行動、觀察和驗證，便能自行發現錯誤，而不是信心十足地犯錯。
目前大多數 AI 智能代理本質上只是步驟較多的聊天機械人，沒有任何機制判斷方向是否正確、何時應停止，或何時應改用另一種方法。加入完善的控制層，包括明確的成功準則、結構化狀態和驗證檢查，才能把徒具智能代理外形的物件轉化為真正可信的系統。
你昨天午餐吃了甚麼？
你大概不會重播一生所有記憶，直至找到「昨天＋午餐」，而會直接跳到這些概念所在的經歷片段。這是建構智能代理時很實用的心智模型：
龐大的上下文視窗不等於記憶。
一堆檢索所得的文件不等於理解。
冗長的思路鏈不等於可靠性。
這些都只是材料。但令智能代理真正具有智能代理特質的要素，也正是讓大腦無須以蠻力搜尋你一生經歷的要素：控制。
近期一項調查——大型語言模型的智能代理式推理——出色地概括（並命名）了許多人在建構系統時感受到的轉變：由模型內部推理，轉向透過互動推理。本文並非該論文的摘要。本文嘗試把這項轉變落實為實用的系統設計：
如果你以配備工具的聊天機械人方式建構智能代理，聊天機械人的失敗模式便會繼續出現，只是犯錯的代價更高。
有一段時間，我們「令模型更聰明」的預設方法基本上是：改良提示詞、思路鏈、自洽性／取樣式改進，再加上一些搜尋功能。
ReAct 是一個轉捩點，因為它令「思考 → 行動 → 觀察」變得自然。但請留意其中的隱含限制：許多做法最終仍只是「使用更多 token 的單範例推斷」。調查提出了更精準的框架：智能代理式推理着重擴展測試時互動，把推斷轉化為反覆迭代的過程，讓模型、記憶及環境一直參與循環。
如果你曾建構（或使用）在示範中令人驚艷、在實際工作流程中卻很脆弱的智能代理，本文正是為你而寫。
以下是我經常見到的模式（而我自己也確實建構過類似版本）：
採用一個優良的對話模型
加入幾項工具（搜尋、資料庫查詢，也許還有程式碼執行）
加入 RAG
加入「你是一個自主智能代理」的系統提示詞
全部包在 while 循環中，直至停止或逾時
恭喜，你已得到一個徒具智能代理外形的物件。但它往往會以可預見的方式失敗：
上下文膨脹：每項觀察都不斷附加，提示詞最終堆疊成考古地層。
胡亂使用工具：「信心十足地用錯工具」成為預設的失敗模式。
沒有停止條件：它繼續運作，只因為做得到，而非因為應該這樣做。
缺乏實證依據規範：除非你強制它檢查，否則它不會發現自己錯了。
記憶＝對話記錄：實際上只是寫日誌，卻稱之為學習。
因此，「智能代理」往往在示範中看似神奇，在生產環境中卻一片混亂。我們把智能代理式系統投入生產環境的經驗亦印證這一點：當評估對象不再是模型而是系統，失敗模式便包括流程導引、工具使用規範、上下文刪減及評估設計，而不只是「模型有否正確回答」。
那麼，問題便是：理想的智能代理應該是怎樣的？
為免過於抽象，以下是一個大多數人都能想像的簡單工作流程：「替我預訂下星期二從倫敦前往紐約的航班。下午 6 時前抵達。費用不超過 £900。要靠走道座位。」
常見的「智能代理式」實作方式如下：
立即檢索大量航空公司／旅遊政策文件（即使當下尚未需要）。
調用搜尋工具，把冗長的結果清單貼入提示詞，然後「選一個」。
未驗證限制條件（抵達時間／行李／座位／政策）便草率預訂。
如果失敗，便稍微改變方式重試，卻不清楚究竟改了甚麼或從中學到甚麼。
失敗的原因並非模型無法推理，而是系統沒有控制工作流程。
更具智能代理特性的版本會把任務視為互動過程，並採用明確的狀態和檢查：
規劃：重述限制條件並列出所欠資料（例如「偏好哪個機場？」／「可以轉機一次嗎？」）。
行動：以結構化查詢調用航班搜尋（日期範圍、抵達時間限制、預算）。
觀察：把結果儲存於精簡的狀態物件（價格／抵達時間／轉機次數最佳的 5 個選項），而非貼入一大段內容。
更新：若未能符合限制條件，便調整查詢（例如「下午 6 時前抵達的要求過嚴，要擴大時間範圍還是提高預算？」）。
驗證：執行驗證器（「抵達時間 < 18:00」、「價格 ≤ £900」、「符合政策」、「可選座位」）。
停止：只有在預訂 API 傳回確認且通過所有驗證器後才停止。
當中的改變細微，卻具有決定性。檢索按條件執行（而非反射動作）、上下文受到管理（狀態經過結構化，而非不斷累積），而驗證則納入循環（而非留給用戶）。把「預訂機票」換成「建立採購單」、「發出退款」、「更改生產環境設定」或「提交 PR」，道理也一樣：智能代理一旦能夠行動，循環便比提示詞更重要。
上述調查把智能代理推理分為三層：基礎層（規劃／工具使用／搜尋）、自我演進層（回饋＋記憶），以及集體層（多智能代理協調）。
但更深層的理念是：推理會成為規劃、決策及驗證的組織原則，而不只是生成看似合理的思路鏈。這聽來抽象，但只要對照架構中的實際變化，便會清晰起來。有三個核心重點需要記住：
優良的智能代理不應把檢索視為「每次必做」。檢索是一項決策，而非反射動作。
以下是一項實用的經驗法則：
如果系統每一輪都執行檢索，你建立的並非檢索機制，而是上下文稅。
這種情況在實際工作中屢見不鮮。為生產事故偵錯時，你不會把所有日誌都塞入上下文，而會根據當前假設，決定下一步擷取哪些指標／日誌。這就是「智能代理式檢索」。以下是更具體的模式：
判斷是否需要檢索
如需要：擬定查詢、擷取、略讀、提取
如證據互相矛盾：再次擷取
完成後才綜合分析
「智能代理式 RAG」亦由此開始有別於傳統 RAG：檢索成為經過深思熟慮的推理步驟，而非預設的流程階段。
當你不再評估「模型」，而是開始評估「系統」，狀態追蹤和流程追蹤便變得重要。
至今，業界已更明確重視智能代理工作流程的可觀測性。例如，OpenAI 的 Agents SDK 內置追蹤功能及 Traces 儀表板，記錄智能代理的運行過程（生成、工具調用、交接、護欄及自訂事件），讓你逐步偵錯和審核實際發生的情況。
這並非「有就更好」，而是系統可以偵錯與只能憑感覺檢查之間的分別。
在我看來，這項調查最具可操作性的部分，是它對回饋的論述十分直接。它把回饋分為三種機制：反思式回饋（生成 → 評析 → 修訂）、參數適應（透過微調／強化學習來學習），以及驗證器驅動的回饋（重試至通過驗證器為止）。
大多數團隊都應先採用驗證器驅動的回饋，因為這種方法平實而有效。只要你能編寫任何驗證器，用於單元測試、檢查結構定義、設定業務規則／限制（「金額超過 X 的退款必須上報」），或核實真確性（「必須提供引文」），就能把非確定性的模型輸出轉化為真正可信的結果。
這裏其中一項原本難以預見的轉變很簡單：在智能代理領域，可靠性往往更多來自循環，而非模型。
以下是我所見無須訓練、但能可靠改善行為的最精簡循環規範：
分步執行：規劃 → 行動 → 觀察 → 更新；
每次行動後，以 1 至 3 個要點概述觀察結果；
達成成功準則或用盡預算後便停止；傳回目前最佳結果及仍未釐清之處。
目的不是令模型變得冗長。而是令系統清晰可讀，並強制每一步都與現實核對。一個工程師很容易理解的例子，是類似 CI 的閉環實證依據流程：
規劃：提出變更清單
行動：執行測試／程式碼檢查
觀察：解析失敗結果
更新：修補並重試
以下幾個問題通常能揭示無意間形成的智能代理設計：
「我的智能代理會自行選擇要檢索的內容，還是每次都由我執行檢索？」
如果無條件檢索，你將付出以下代價：延遲、成本、上下文稀釋，以及「垃圾進、垃圾出」的風險上升。
「我的智能代理能否發現自己錯了？」
如果智能代理唯一的回饋訊號是「用戶感到惱怒」，你其實是在以人類的痛苦進行強化學習。由驗證器驅動的重試循環，是讓它核對現實最簡潔的方法。
「記憶是否可寫入，並會隨時間改善？」
如果你的「記憶」只是持續附加對話記錄，實際上只是在寫日誌。調查對記憶的界定十分重要：記憶會成為智能代理隨時間改進、持續增長的動態上下文，而不只是一份逐字記錄。
日誌告訴你發生過甚麼，記憶則告訴你下次該怎樣做。對話記錄是一份逐字記錄。記憶是一套持續演變的方針，決定哪些資訊值得保留供日後使用。
實用的起步方法，是建立一個小型「經驗教訓」表格，以任務類型、工具及失敗模式為鍵，並以有效做法和應避免事項為值。重點不是建立完美的知識圖譜。重點是產生複利式改善：記憶加上回饋，能把智能代理從「無狀態助手」轉化為隨時間持續進步的系統。
人們容易以增加智能代理來解決問題，但這往往只會令協調成本成倍上升。一個良好的「最小可行團隊」模式如下：
協調者：拆解＋分配
執行者：調用工具／作出變更
評析者／評估者：檢查正確性／風險
記憶管理者：記錄／整理經驗教訓
如果你無法說明每個智能代理各自負責甚麼，現階段大概還不需要多個智能代理。
如果我們真正接受這種範式轉移，便可能不再把所有內容塞進提示詞、不再把失敗視為最終輸出，也不再像評估聊天機械人般評估智能代理。我們會開始把智能代理視為其本質：以語言作為控制平面的軟件系統，而可靠性則來自循環。
加入另一個模型之前，先加入另一個評估循環。檢索所有內容之前，先把檢索設為按條件執行。先推出一個驗證器，而非一次推出十個。把記憶視為方針決策，而非資料庫。採用多智能代理時，先由兩個開始，而非二十個。這些並非規則，而是經過生產環境考驗後留存下來的模式。