我在 AWS 帳戶上看到一筆 200 美元的帳單在一夜之間出現。
不是因為系統當機。
一個 Agent 連續跑了六個小時，沒有停止條件，每次迭代都呼叫 OpenAI API。
所有監控儀表板都顯示系統正常運作。
沒人注意到，直到早上帳單寄來。
這就是當你建立 AI 系統卻不了解它們實際運作方式時會發生的事。
大多數人學 AI 工程都是倒著學的。
裝個套件。跟個教學。呼叫 API。弄出點東西。感覺有進展。
然後某個東西以無法理解的方式壞掉了。
他們隨機改數字，直到問題消失。
那不是工程。那是帶著希望的鍵盤操作。
以下 6 個概念能解決這個問題。
一句話解釋一切
每個 AI 系統，無論多複雜，都只是：
記憶（RAG）+ 思考（LLM + Token）+ 動作（Agent）+ 衡量（Eval）
……透過脈絡工程組合起來。
這就是整個領域。
以下只是拆解每個部分的實際意義。
1. Token 與脈絡視窗
LLM 不閱讀單字。它們閱讀稱為 token 的區塊。
"engineering" → 1 個 token
"unbelievable" → 2 個 token 空格和標點符號也算在內。
每個模型都有一個脈絡視窗 — 一次能容納的 token 數量上限。
→ Claude：200,000 個 token
→ GPT-5：400,000 個 token
把它想像成會議室裡的白板。
模型只能處理目前寫在板子上的內容。
當板子寫滿時，舊的筆記會被擦掉以騰出空間。
模型不會失去思考能力。
它會失去對較早資訊的存取權。
為什麼這會搞壞正式環境系統：
→ Token 要花錢 — 每次 API 呼叫都按輸入和輸出 token 計費
→ 冗長的聊天記錄會快速填滿視窗
→ 當脈絡填滿時，較早的指令會默默被丟棄
→ 什麼東西進到脈絡是一個工程決策，不是預設值
證明這點的失敗案例：
一個團隊建立了一個客戶支援 Agent，每次請求都帶著整整 12 個月的對話記錄作為脈絡。
在測試中只有 5 次互動時運作完美。
在正式環境中，經過 50 次互動後，Agent 開始忽略自己的系統提示。
指令還在。
但它們被埋在大約 80,000 個 token 的對話記錄之下。
模型已經有效地停止關注它們了。
修復方法不是換更好的模型。
而是摘要較舊的記錄，以保持脈絡集中。
令人不安的真相：
大多數「提示工程失敗」其實是 token 和脈絡視窗失敗的偽裝。
工程師責怪提示，但真正的問題是關鍵指令在 500 行脈絡的第 3 行，而模型已經不再權重它了。
2. 嵌入與向量搜尋
嵌入把意義轉換成數字，讓「相似度」可以用數學計算。
它們解決的問題：
你有 50,000 份文件。使用者問了一個問題。你需要最相關的 3 份 — 而且不必每次都讀全部 50,000 份。
關鍵字搜尋在這裡會失敗。
如果文件中寫了「automobile」，使用者問的是「cars」，關鍵字搜尋會錯過它。
不是因為答案不在那裡。而是因為詞彙不符。
嵌入用不同的方式解決這個問題。
一個嵌入模型把文字轉換成向量 — 一串代表數學空間中意義的數字。
語意上相似的文字 → 數值上相近的向量。
「car」和「automobile」 → 距離很近
「car」和「photosynthesis」 → 距離很遠
向量搜尋實際如何運作：
- 每份文件都被轉換成向量並儲存
- 使用者的問題也變成向量
- 系統找到與問題向量最接近的已儲存向量
- 那些就是你最相關的文件
這不是近似值的魔法。這是幾何學。
相似度是一個你可以計算的真實數學性質。
這在正式環境中會出現在哪裡：
→ 任何文件系統中的語意搜尋
→ 尋找相似產品、文章、使用者個人資料
→ RAG 中的檢索步驟（下一個概念）
→ AI Agent 中的記憶
3. RAG（檢索增強生成）
與其在你的資料上訓練模型，不如在查詢時檢索相關資料，然後餵給模型作為脈絡。
RAG 解決的問題：
LLM 知道很多東西。但它們不知道你的資料。
你公司的內部文件。你的產品資料庫。你的客戶支援紀錄。
這些都不在訓練集中。
兩個選項：在你的資料上訓練模型（昂貴、緩慢、馬上過期），或者在模型需要的時候立即提供你的資料。
RAG 是第二個選項，以系統化的方式進行。
三步驟流程：
→ 檢索：
問題變成向量 → 向量資料庫找到最相似的已儲存文件 → 取出前 3-5 個區塊
→ 增強：
檢索到的文件被加入模型的脈絡 → 提示變成「使用這個脈絡，回答這個問題」
→ 生成：
模型根據你的實際資料回答 — 而不是幻覺
RAG 在哪裡會出問題：
→ 檢索品質差 = 答案差。模型只能根據收到的東西運作
→ 不當的分塊方法會把答案和它的脈絡分開
→ 如果檢索找不到有用的東西，模型仍然可能產生幻覺
一個真實的 RAG 失敗案例：
一個團隊為一本 500 頁的技術手冊建立了一個內部知識助手。
示範時完美運作。在正式環境中，答案含糊不清，有時還錯誤。
問題在於：分塊大小。
他們根據原始字元數把手冊切成 1,000 token 的區塊。
表格在中間被切斷。逐步說明在中間被切斷。
檢索找到了正確的大致區域 — 但錯過了實際答案。
把分塊大小減半並加上重疊，一夜之間解決了 80% 的問題。
硬派觀點：
當你的檢索很差時，RAG 被高估了。
LLM 無法修復糟糕的檢索。它只能圍繞著它產生幻覺。
如果你看到錯誤的答案，別再調整提示了。
開始衡量你的檢索精確度。
答案就在那裡。
4. Agent 循環
Agent 透過反覆選擇一個動作、執行它、觀察結果、然後決定下一步做什麼來運作 — 直到任務完成。
一般的 LLM 呼叫是無狀態的。你問，它回答，結束。
Agent 是有狀態的。它行動、觀察、決定、重複。
用白話來說的循環：
- 接收一個目標
- 決定下一個動作
- 執行它 — 搜尋、寫程式、讀取檔案
- 觀察結果
- 根據學到的東西決定下一個動作
- 重複直到目標完成
- 回傳最終答案
工具是賦予 Agent 力量的東西。
沒有工具，LLM 只能用文字回應。
有了工具，它可以搜尋網路、讀取檔案、寫程式、呼叫 API、觸發你定義的任何動作。
初學者總是搞錯的三件事：
→ 沒有停止條件的 Agent 會永遠執行。你必須定義何時停止 — 步驟上限、時間上限或目標條件
→ 更多工具 ≠ 更好效能。太多工具會讓模型混淆該用哪一個
→ 工具錯誤需要明確處理。一個靜默失敗會讓 Agent 自信滿滿地產出垃圾
那個 200 美元的隔夜失敗，詳細說明：
Agent 沒有最大步驟數。它的目標：研究一個主題並產出摘要。
它的一個網路搜尋工具回傳了空結果。
Agent 不知道怎麼停止。
它持續搜尋、重試、產生中間摘要 — 每個都觸發另一次搜尋。
六小時後：847 次 LLM 呼叫。210 萬個 token 被消耗。一份看起來合理但完全循環的摘要。一張 200 美元的帳單。
修復方法是三行程式碼：一個最大步驟計數器、一個空結果的明確處理器、一個當信心低落時的升級路徑。
同一個 Agent 現在平均在 12 次呼叫內完成。
你需要聽到的意見：
大多數 Agent 失敗不是因為模型不好 — 而是因為工程師把循環當成自我管理。
它不是。
護欄、停止條件、錯誤處理器 — 一開始就建立，而不是在第一次事故後才加上。
5. Eval（評估）
Eval 是你用來知道你的 AI 系統是否真的有效 — 以及一個改變是讓它變好還是變壞的方法。
這個概念大多數教學都會跳過，因為它不吸引人。
但這正是區分建示範的工程師和建正式環境系統的工程師的關鍵。
沒有 eval 的問題：
你改了提示。更新了檢索邏輯。切換到更新版的模型。
它變好了嗎？
你不知道。你可以人工檢查幾個例子 — 但那是一種感覺，不是證據。
Eval 實際上看起來像什麼：
→ 一個黃金資料集：25-50 個真實輸入，附有已知的正確輸出，涵蓋主要使用案例加上 5 個已知的棘手邊緣案例
→ 盡可能使用二元指標：
— RAG 系統是否檢索到正確文件？是/否
— Agent 是否無錯誤完成？是/否
— 回應是否包含所需資訊？是/否
→ 隨時間追蹤的總分：
— 檢索準確率：89% → 做了改變 → 84%。發現回歸。
— 任務完成率：76% → 新 Agent 版本 → 81%。確認改善。
Eval 循環：
部署 → 用 eval 衡量 → 找出失敗 → 把失敗加入黃金資料集 → 修正 → 再次執行 eval → 比較分數 → 只有數字進步了才上線
老實說：
「幫助性：3.7/5」不能告訴你任何可執行的事情。
「正確檢索到文件：84% 的時間」清楚告訴你問題在哪裡，以及修正改善了幅度有多少。
一個沒有 eval 的 AI 系統不是產品。
它是一個你無法放心改變的示範。
6. 脈絡工程
這門學科專門決定哪些資訊該放進模型的脈絡視窗、如何組織、以及什麼該被排除。
以下是讓人不舒服的觀點：
脈絡工程比提示工程更重要。
一個平庸的提示，放在精心策劃的脈絡中，表現會勝過一個在雜訊中埋沒的出色提示 — 每次都會。
大多數團隊把 80% 的最佳化努力花在提示上，卻幾乎不花在脈絡上。
結果也反映了這一點。
天真的方法會失敗：
包含所有東西。全部歷史。所有檢索到的文件。每一個工具描述。系統提示。使用者訊息。全部。
這會因為一個一致的原因而失敗：模型對於什麼最重要感到困惑。
有一個有記錄的效果叫做「迷失在中間」 — 埋藏在大段脈絡深處的資訊較不容易被使用。
脈絡工程實際包含什麼：
→ 選擇：這個特定決策需要哪些文件、事實或歷史？
→ 壓縮：對話中較舊的部分能否被摘要以節省 token？
→ 排序：關鍵指令應該在開頭和結尾 — 而不是中間
→ 修剪：哪些東西可以移除而不影響輸出品質？
→ 結構：標題、分隔線、標籤區段會影響模型使用資訊的可靠度
一個實務範例：
一個 Agent 已經運行了 45 分鐘。它累積了 80,000 個 token 的對話歷史。它的視窗是 128,000。
你不希望失去最初的目標和限制，即使歷史填滿了視窗。
脈絡工程：壓縮較舊的工具輸出，摘要較早的推理，在整個工作階段中讓任務定義保持顯眼。
提示工程是寫出好的指令。
脈絡工程是建立這些指令能被實際遵守的環境。
這 6 個概念如何形成一個系統
記憶 → RAG + 嵌入（系統知道的東西）
思考 → LLM + Token + 脈絡視窗（它如何用它知道的東西推理）
動作 → Agent 循環 + 工具（它能在世界上做什麼）
衡量 → Eval（你怎麼知道它在運作）
黏合劑 → 脈絡工程（決定上述所有部分之間流通什麼）
一個簡單的聊天機器人只是思考。
一個客戶支援 Agent 是記憶 + 思考 + 動作。
一個可靠的正式環境系統會加上衡量。
精巧之處在於這些部分如何連接。
任何單一請求的流程：
使用者問題
→ 脈絡工程決定要包含什麼
→ 嵌入檢索相關記憶（RAG）
→ Token 決定視窗能容納多少
→ LLM 對組合好的脈絡進行推理
→ Agent 循環決定是否需要更多資訊
→ Eval 衡量輸出是否正確
從哪裡開始
你不需要一次精通全部六個。
→ 從 token 和脈絡視窗開始 — 它們影響你建的一切 → 當你需要語意搜尋或記憶時，加入嵌入
→ 當你需要讓模型奠基在自己的資料上時，學習 RAG
→ 當你需要自動化時，學習 Agent 循環
→ 在把任何東西上線到正式環境之前，加入 eval
→ 當其他東西都變得直覺時，應用脈絡工程
這個順序不是隨便的。
每個概念都讓下一個概念變得可學習。
老實說的最後總結
大多數在正式環境中跟 AI 奮鬥的團隊，不是因為用錯模型或用錯套件。
他們奮鬥是因為跳過了這六個概念中的一個。
Agent 永遠循環，因為沒有人想過停止條件。
RAG 的答案是錯的，因為沒有人衡量檢索。
提示在長時間工作階段後失效，因為沒有人理解脈絡視窗是如何填滿的。
這些不是複雜的問題。
它們是基本的問題，只是用技術詞彙包裝起來。
工具每六個月就變一次。
這六個概念是工具如何運作的核心。
學會這些概念，你永遠不會再被新的工具搞糊塗。
更重要的是 — 你永遠不會再花 200 美元看著一個 Agent 整夜循環，納悶哪裡出了錯。
如果這對你有幫助：
→ 轉發給每一位你認識的 AI 工程師
→ 追蹤 @sairahul1 獲得更多像這樣的系統和拆解
→ 把這篇加入書籤 — 下次正式環境出問題時你會回來參考
我寫關於 AI、建立產品，以及在你睡覺時運作的系統。
