AI Agent 只是「聰明原型」？五條殘酷鐵律，決定你的智慧體是玩具還是現金流
你是否曾有過這種感覺：花了一個週末，用最新的 AI 模型打造了一個驚為天人的 Agent，它能自動規劃行程、撰寫郵件、甚至幫你分析財報。你興奮地將它部署到伺服器上，以為從此可以躺著等它幫你賺錢。結果呢？第一個禮拜它表現神勇，第二個禮拜開始胡言亂語，第三個禮拜直接罷工，留下滿地錯誤的 API 呼叫和一張令人心碎的雲端帳單。
這不是你的錯，而是你犯了「原型思維」的忌諱。
你做出來的是一個「聰明的原型」，不是一個「可靠的產品」。這兩者之間的鴻溝，正是當前 AI 產業最昂貴的學費。根據 2026 年最新的產業調查，超過 70% 的企業級 AI 專案仍停留在概念驗證（PoC）階段，無法跨過生產環境的死亡之谷。大家不缺模型，不缺算力，缺的是把 AI 當成嚴肅工程來對待的「紀律」。
在 Peter Yang 的頻道中，來自 LlamaIndex 的兩位核心專家 Nan Yu 與 Jacob Shumway，在一場題為 「5 Rules for Building AI Agents That Work in Production」 的對談中，沒有給你雞湯，而是毫不留情地拆解了那些能真正在殘酷商業環境中存活下來的 Agent，究竟具備什麼特質。這不是一場學術研討，而是一堂關於生存的實戰課。
如果你正準備將手上的 Side Project 變成一個真正扛得住流量的服務，或者你正在公司內部推動 AI 轉型，這篇文章將為你提煉出決定生死的五條鐵律。準備好撕毀你的架構圖了嗎？
規則一：從「夢幻組合」到「無聊架構」——別讓你的 Agent 成為即興脫口秀演員
當我們談論 AI Agent 時，腦海中浮現的往往是宛如科幻電影般的場景：一個全知全能的核心，自主調用各種工具，像人類一樣思考與決策。Nan Yu 與 Jacob Shumway 卻直言，這正是導致專案失敗的最大禍根。
在生產環境中，你需要的不是一個會即興發揮的天才，而是一個嚴格遵守腳本的職業演員。
許多開發者陷入的誤區，是將所有邏輯都塞進一個巨大的 LLM 提示詞中，期望它能像人類一樣隨機應變。這種「夢幻組合」在 Demo 時看起來很酷，因為模型確實會根據當下的輸入即時推理出下一步動作。但問題在於，LLM 的本質是概率預測，而非確定性計算。 這意味著，同一句話，它今天可能給你 A 答案，明天可能給你 A+ 答案，後天手滑了給你 B 答案。當這個「不確定性」被放入一個複雜的商業流程中時，就是一場災難。
想像一下，你的 Agent 負責處理客戶退款。今天它的工具呼叫邏輯完美，明天它突然心血來潮，決定先發一封充滿同情心的郵件給客戶再執行退貨——這在測試時看起來是「擬人化」的加分項，但在生產環境中，這叫 不可控的 Bug。
Nan Yu 在對談中強調了一個關鍵詞：「Workflow」。她認為，真正能在生產環境中成功的 Agent，必須是「工作流」與「Agent」的混合體。
這聽起來有點違反直覺，因為我們總覺得 Agent 就該比 Workflow 高級。但事實是，Workflow 提供了確定性的骨架，而 Agent 則在骨架的縫隙中提供靈活的決策。
「我們不應將 Agent 視為一個完全自主的個體，而應將其視為一個精心設計的工作流程中，負責處理例外與複雜判斷的組件。」 —— Nan Yu
這裡的核心要點是：將複雜任務拆分為多個小型、明確的「步驟」（Step）。 每個步驟執行特定的任務，並透過定義好的介面進行溝通。例如，一個「研究分析 Agent」不應該直接面對「寫一份報告」的模糊指令。它應該是一個清晰的流程：
- 使用網路搜尋工具（Workflow 固定行為）。
- 過濾並提取網頁內容（Workflow 固定行為）。
- 將內容交由 Agent 進行總結歸納（Agent 動態調用）。
- 透過格式模板輸出（Workflow 固定行為）。
這看起來很「無聊」，甚至有點死板，但正是這種「無聊」，保證了系統的可預測性、可測試性和可觀測性。生產環境的老闆們最怕的不是 AI 不夠聰明，而是 AI 今天聰明了、明天卻笨了。穩定性，是生產環境唯一的信仰。
規則二：Greedy 不是王道——面對岔路，懂「審查」比懂「思考」更重要
這是整場對談中，最令我感到「後背發涼」的一點。當我們面對 AI 給出的答案時，往往會陷入一種「科技崇拜」——因為它看起來太合理了，以至於我們放棄了最基本的常識審查。
Jacob Shumway 在影片中提出了一個尖銳的觀點：目前的 RAG（檢索增強生成）系統，在 「Greedy 搜尋」（貪婪搜尋）上已經做得非常出色。什麼是 Greedy 搜尋？就是根據當下的上下文，機械地選出下一個最有可能的 Token。這是 LLM 的本能反應。
但這種本能反應，在需要有條件的邏輯推理時（Conditional Reasoning），往往是錯的。
他舉了一個非常好的例子：想像你的 Agent 需要回答一個數學應用題，「如果小明有 5 顆蘋果，他吃了 2 顆，又買了 3 打，請問他現在有多少顆？」LLM 透過 Greedy 搜尋，可能因為「蘋果」與「加法」的高關聯性，直接算出 5 - 2 = 3，然後 3 + 36 = 39，它給出了答案。這個過程看似合理，但如果你沒有在系統設計上設定一個「檢查機制」，它永遠不會發現問題所在。
這裡的「檢查機制」，就是規則二的核心：建立一個關於「思維過程」的評估系統，而非僅評估「思維結果」。
我們通常會對最終的輸出（Final Output）進行評估，評測它的語法、含金量、相關性。但 Shumway 強調，生產級的 Agent 必須對「中間步驟」進行強制性的自我反思與評估。
這種評估不是說讓 LLM 問自己「我這樣做對不對」——因為那只是另一種形式的 Greedy 輸出。而是要做 「輸出審查（Validate）」 與 「回饋閉環（Feedback Loop）」。
怎麼做？你得將任務結構化。當 Agent 產出一個中間結果時，你必須設計一個獨立的 Prompt 來審查這個結果。例如，你可以設計一個「Rule-based Filter」：寫死了法規要求，用戶的年齡必須大於 18 歲。Agent 從客服紀錄中提取出一個用戶的年齡為 17 歲，但它依然嘗試完成下單流程——此時，你必須有預先定義的邏輯去攔截它。不要讓 LLM 去判斷 17 歲是否能買菸，你要用傳統的程式碼去強制阻擋。
這背後的啟示是：在生產環境中，AI 的「純理性」是不可靠的，你需要用傳統的「規則理性」去輔助它。
很多開發者害怕寫死規則，因為那會讓 Agent 看起來「不夠聰明」。但這是嚴重的誤解——真正的智慧型系統，是懂得在何處運用規則、何處運用模型的系統。當你給 Agent 劃定了不可逾越的紅線，它在紅線內反而能獲得更大的自由。
規則三：別讓辛苦的「檢索」變成 AI 的「耳邊風」——打造高頻寬的語境傳輸管線
這條規則直接點破了所有 RAG 應用的死穴：你的資料庫搜尋做得再好，如果 LLM 沒有「讀懂」你的資料，一切都是徒勞。
Nan Yu 在對談中把 RAG 的流程拆解的非常透徹。她指出，現在很多開發者僅僅是將檢索到的文本塊（Chunk）粗暴地塞進 Prompt 中，然後祈禱 LLM 能從中挖掘出真相。這就像是給一名記者一份 1000 頁的 PDF 檔案，然後對他說：「寫一篇關於其中第 35 頁提到的某個細節的深度報導。」他當然會看，但他的注意力會被分散，而關於那個細節的記憶，很可能只佔他整個閱讀量中的 1%。
這不是 AI 的理解能力有問題，而是你的「資料傳輸頻寬」太低。
我們必須區分兩個概念：「資訊檢索」 與 「語境建立（Context Building）」。前者是找到正確的文件，後者是讓 LLM 真正消化並關聯文件中的內容。
為了實現後者，LlamaIndex 提出了 「句子視窗檢索（Sentence Window Retrieval）」 或 「結構化資料檢索」 的概念，這在業界已被廣泛驗證。這個概念的核心是：不要將一個龐大的區塊丟給 LLM，而是去檢索出「最關鍵的單一預測」，並在檢索後，動態地擴大該預測周圍的上下文範圍。
舉例來說，當用戶問：「我們公司在 2024 年第三季度的毛利率是多少？」傳統作法是從資料庫中抽取一段描述財務數據的文字。但更好的做法是：先鎖定「2024 Q3」與「毛利率」這兩個精準的實體，然後像洋蔥一樣，逐層向外剝開，將包含這兩個關鍵字的段落、以及與這句話有主語或時間關聯的上下文，一同建構成新的 Prompt。
這樣做的好處是顯而易見的：它降低了資訊雜訊，提高了 Token 的利用效率（單位成本內的資訊密度）。
更進一步，Nan Yu 特別強調了 「自我修正的檢索」。當 Agent 第一次檢索到的資訊不足以回答問題時，它不應該直接對用戶說「我不知道」。它應該有能力將問題「降維打擊」，設計一個更精準的子查詢（Sub-Query），去搜尋缺失的部分。
這聽起來很美妙，但在工程實現上，需要你在後端建立一個極度清晰的資料索引（Index）。如果你對資料的標籤、屬性、時間戳沒有進行嚴格的結構化管理，Agent 這種「動態擴充」的能力將徹底失效。簡單來說，想要 AI 聽懂人話，你得先讓資料庫說人話。
規則四：拋棄「記憶金魚」——生產級 Agent 的記憶必須是分層級的
在對話式 AI 的早期，我們最常聽見的抱怨是：「為什麼它老是忘記我五分鐘前說的話？」這是「短期記憶」的缺失。如今，Context Window 變得超大，動輒百萬 Token，很多人覺得記憶問題解決了。但 Jacob Shumway 潑了一盆冷水：如果將所有歷史都塞進上下文（Context），你的 Agent 的「注意力」會被稀釋，而且你的成本會呈指數級上升。
這就是所謂的「Lost in the Middle」現象——LLM 往往會對長上下文的中間部分「視而不見」。
因此，規則四要求我們為 Agent 建立一個 「分層記憶架構」。
它類似於人類的大腦運作機制：
- 工作記憶（Working Memory）： 這是你給 Agent 的 System Prompt，明確交代任務、語氣、與當前對話的執行狀態。這是整個 Agent 的「作業系統」。
- 脈絡記憶（Episodic Memory）： 這是當前「任務執行中」的關鍵資料。例如，用戶在第 1 步上傳的 PDF 內容。這些內容只保留在當前執行緒中，任務結束即銷毀或歸檔。
- 長期記憶（Semantic Memory）： 這通常是儲存在向量資料庫中的使用者偏好、歷史事實。你不可能每次都將所有歷史事實塞給 LLM，你必須透過檢索，提取出與當前任務相關的長期記憶片段。
Shumway 在對談中提出了一個非常務實的策略：狀態管理（State Management）。
在傳統程式碼中，狀態管理是天經地義的事。但在 LLM 應用中，很多開發者卻忘了「永久記憶」賦予給 Agent 的「權重」。他建議，在設計 Agent 時，必須明確區分「當前任務的上下文」與「全域的知識庫」。當 Agent 確定需要全域知識時，才觸發檢索動作；而當 Agent 只是在執行當下任務時，就閉鎖在當前的工作記憶中。
這不僅僅是為了省錢，更重要的為了「專注」。
如果一個 Agent 在幫你分析 Excel 表格時，腦子裡還同時在想著「用戶半年前曾問過他喜歡喝美式咖啡」，那麼它的輸出風格與邏輯一定會受到干擾。這種記憶的分層管理，讓 Agent 具備了「專業人士」的素養：面對不同的任務，展示不同的專業側面，而非將所有特性都混合在一起。
永遠記住，給 Agent 太多的記憶，就像是給一個粗心的人一台 100GB 的隨身碟，他往往會因為找不到資料而放棄，倒不如給他那張只記著關鍵緊急聯絡人的名片夾。
規則五：拋棄「一次性玩具」的概念——從設計第一天就植入「可觀測性」與「可評估性」
這是最殘酷的一條規則，也是將「開發者」與「工程師」區分開來的分水嶺。
當我們寫傳統 API 時，我們有 Postman、有 Kibana、有 Sentry，我們知道每個 request 的延遲、錯誤率與完整 trace。但當我們面對 Agent 時，我們似乎瞬間退化成了洞穴人，只能盯著終端機裡噴出的字串，祈禱它不要出錯。
Nan Yu 明確指出：「如果不為 Agent 建立追蹤（Tracing）與評估（Evaluation）系統，你就沒有資格將它部署到生產環境。」
這是一句非常嚴厲的警告。為什麼大家總覺得 AI Agent 很難 Debug？因為你無法用傳統的斷點去中斷模型的內部推理過程。 你只能看到輸入與輸出。當輸出錯誤時，你根本不知道是「檢索到了錯誤的資料」還是「模型做出了錯誤的推理」。
因此，規則五要求我們，從開發的第一天就必須構建三大支柱：
支柱一：完整的 Logging（日誌）系統。 你不能只記錄最終的答案。你必須記錄每一次的 Tool Call、每一次的 Prompt 拼接結果、每一次檢索回來的 Chunk 內容、每一次 LLM 的 Raw Output。只有當你將這些過程全部結構化地記錄下來，你才能在出錯時判斷問題是出在「搜尋」、「理解」還是「生成」。
支柱二：LLM 作為評審員（Judge）。 這是一個較前沿但已被驗證有效的做法。你使用一個更強勁的 LLM 來評判你的 Agent 的輸出。但這裡有許多的注意事項，例如你不能直接問「這個回答好不好」，而是要設計一套嚴謹的評分 Rubric（例如：是否忠於原文？是否涵蓋所有要點？是否有毒？）。這種 「LLM-as-a-Judge」 的方式，能快速找出那些傳統程式審查發現不了的「幻覺」，但請記住，這只是快速檢測，最終仍需要人與規則介入。
支柱三：組建黃金評估集（Golden Evaluation Set）。 這可以說是整個對談中最「無聊」但最有用的建議。你需要收集一批包含「問題-標準答案」的測試集。當你每次修改 Agent 的 Prompt 或架構時，跑一遍這個測試集，並記錄分數。如果這個分數下降了，代表你的「升級」是失敗的，但至少在自動化測試中失敗，總比在客戶面前失敗來得好。
「你不能在生產環境中『測試』你的 Agent。你必須在測試環境中『生產』你的 Agent。」 —— Jacob Shumway
這條規則的本質是：軟體工程的 3 個底層邏輯——版本控制、自動化測試、持續整合——同樣適用於 Agent 的開發中。不要把 Agent 當作一個魔法服務，應該把它當作一間精密的手術室。
生產級 Agent 的可觀測性架構（示意圖）
總結與行動藍圖：告別「人工智慧」，擁抱「增強智慧」
為了讓你能快速掌握這五條鐵律的精髓，我將它們總結如下，方便你在設計下一次衝刺時，隨時回來對照：
| 鐵律 | 核心重點 | 常見的失敗模式 | 正確的設計思維 |
|---|---|---|---|
| 規則一 | 架構為主 | 將所有邏輯交給 LLM 隨機應變，混亂且不可控。 | 定義清晰的「工作流」骨架，將 Agent 的行為限制在框架內，並要求其輸出規範化資料。 |
| 規則二 | 條件推理 | 「貪婪搜尋」導致錯誤的聯想，直接產出錯誤結論。 | 強制對中間步驟進行審查；用傳統程式邏輯建置「規則防火牆」，提前攔截低級錯誤。 |
| 規則三 | 檢索策略 | 將檢索到的 Chunk 直接塞入 Prompt，Token 利用率低。 | 建構多層級檢索，動態擴充「句子窗口」；設計「失效回饋」機制，讓 Agent 能自我修正。 |
| 規則四 | 記憶分層 | 上下文過長導致注意力渙散，且造成不必要的算力浪費。 | 嚴格區分工作記憶（系統提示）、任務記憶（執行緒）與長期記憶（向量庫）。 |
| 規則五 | 評估重於開發 | 迷失在調 Prompt 的過程中，沒有數據支撐，只能靠運氣。 | 從第一天導入 Tracing、LLM-as-a-Judge 以及黃金評估集（Regression Test）。 |
結論：這是一場殘酷的最終檢驗
AI Agent 的浪潮已經從「Can we build it」（我們能建造嗎）進入了 「Should we run it in production」（我們該讓它上線嗎） 的時代。
正如 Nan Yu 與 Jacob Shumway 所揭示的，真正能為企業帶來價值的 AI Agent，不是那個「無所不能」的天才，而是那個 「在精密的拘束下，依然靈活的執行者」。它不需要像人一樣擁有天馬行空的想像力，它需要的是像一位頂級特工那樣，在規則的邊界內，達成最不可能完成的任務。
所以，在你看完這篇文章之後，不妨問問自己手邊的那個 AI 專案：它現在是依靠「模型的能力」在走鋼索，還是依靠「工程系統」在建造橋樑？
因為在生產環境中，走鋼索的人終將墜落，而建造橋樑的人，才能引領產業過河。你，準備好當工程師，而不是觀眾了嗎？