Context Engineering：AI Agent 開發的新核心能力

本文整理自 Dex Horthy 在 AI Engineer 大會的演講。

「LLM 是純函數，token 進、token 出。」Dex Horthy 在 AI Engineer 大會上說出這句話時，台下安靜了一秒。這聽起來太簡單了，簡單到像是廢話。但 Dex 認為，正是這個被忽略的基本事實，解釋了為什麼有些 Agent 可靠、有些不可靠。

如果 LLM 是純函數，那決定輸出品質的唯一因素就是輸入。你的 Prompt、你的 Memory、你的 RAG、你的對話歷史——這些全都是同一個問題的不同面向：怎麼把對的 token 送進模型，讓它給你好的回應？Dex 把這個問題叫做 Context Engineering。

為什麼框架讓你失去控制

很多 Agent 框架會幫你處理 Context 的累積。它們有內建的對話管理、工具調用格式、錯誤重試機制。這在初期很方便，但 Dex 觀察到一個問題：當你需要提升品質時，你會發現自己被框架綁住了。

他舉了一個常見的場景。Agent 呼叫 API 失敗了，框架自動把錯誤訊息加到 Context，讓 Agent 重試。聽起來合理。但如果連續失敗幾次，Context 裡就堆滿了錯誤訊息。Agent 看到這些，很容易失去方向，開始亂猜、重複同樣的錯誤、或者乾脆放棄。Dex 問台下：「有人經歷過這種情況嗎？看著 Agent 就這樣 spin out，失控了？」不少人舉手。

問題在於，你沒有主動管理 Context。你讓框架自動把東西堆進去，但那不一定是模型需要看到的。正確的做法是：當連續失敗後終於成功，就清掉那些錯誤訊息；不要把整個 stack trace 丟進去，摘要成有用的資訊就好；甚至可以在某些節點做 Context 的總結，把冗長的歷史壓縮成重點。這些都需要你擁有 Context Window 的控制權。

擁有你的 Prompt 和 Context Window

Dex 說，有些框架可以幫你產生很棒的 Prompt——那種你可能要上三個月 Prompt 學校才寫得出來的品質。這在初期很有用。但如果你想突破某個品質門檻，你最終會需要自己手寫每一個 token。

因為 LLM 是純函數，除非你要自己重新訓練模型，不然你能控制的就是輸入。你放進去什麼詞彙、什麼順序、什麼格式，都會影響輸出。有些團隊會花大量時間優化 Prompt 裡的每一個字，因為他們發現微小的改動可能帶來顯著的品質提升。這不是玄學，這是 Context Engineering。

同樣的邏輯適用於 Context Window 的建構。標準做法是用 OpenAI 的 messages 格式，但 Dex 指出：在你要求 LLM 選擇下一步的那個時刻，你的工作只是告訴它目前發生了什麼事。你可以把所有資訊用任何你想要的方式，塞進一個 user message 裡，問它「接下來該做什麼」。你可以自己定義事件狀態的資料結構，用自己的方式序列化，不需要遵循任何框架的格式。

Dex 分享了他們內部 Agent 的 trace 長什麼樣子。不是標準的 messages 格式，而是經過壓縮、優化密度的自定義格式。他說：「如果你沒有在看每一個 token，沒有在優化你傳給 LLM 的資訊密度和清晰度，你可能在錯失品質的上升空間。」

從錯誤處理看 Context 管理

Dex 特別談到錯誤處理這個場景，因為它最能說明 Context 管理的重要性。當 Agent 呼叫 API 失敗後重試，很多人會直接把錯誤訊息堆進 Context。這看似合理——讓模型知道發生了什麼事，才能調整策略。但如果連續失敗幾次，Context 裡就堆滿了錯誤訊息，模型反而會迷失方向。

正確的做法是主動管理這些資訊。如果最終成功了，考慮清除之前的錯誤記錄——它們已經沒有用了。如果要保留錯誤資訊，摘要它，不要貼整個 stack trace。你要問自己的問題是：模型需要知道什麼，才能做出更好的決策？答案通常不是「所有曾經發生的事」，而是「現在最相關的資訊」。

Context 長度也是一個常被忽略的因素。Dex 提到，就算 Gemini 能吃兩百萬個 token，沒有人會說這樣比精心控制的 Context 更可靠。Context 越長，模型越容易迷失。在長流程中，可以考慮在某些節點做摘要，把冗長的歷史壓縮成重點，然後繼續往下走。這樣每一次 LLM 調用都能專注在當前最重要的事情上。

還有一個微妙的設計問題：很多系統在輸出的第一個決策點就要區分「呼叫工具」還是「回覆人類」，這個區分本身就增加了複雜度。Dex 建議把人類介入當作一種工具——「我完成了」「我需要澄清」「我需要找主管」都可以是工具的選項。這樣模型的第一個輸出就是自然語言的意圖表達，比直接區分工具調用更可靠。這也是 Context Engineering 的一部分：怎麼設計輸出格式，讓模型更容易給出正確的回應。

Context Engineering 作為核心競爭力

Dex 引用了 NotebookLM 團隊的說法：找到模型能力的邊界——那個它不是每次都能做對的事——然後用工程手段讓它變得可靠。如果你能做到這點，你就創造了比別人更好的東西。

這裡的「工程手段」，很大程度上就是 Context Engineering。不是換一個更強的模型，不是加更多工具，而是更精確地控制模型看到什麼。這需要你理解你的任務、理解模型的行為、不斷實驗和迭代。

Dex 在結尾說，他不知道什麼 Prompt 格式更好、什麼 Context 結構更有效——他只知道你能嘗試的東西越多、能調整的旋鈕越多、能評估的維度越多，你就越可能找到真正好的解法。這就是為什麼你要擁有你的 Prompt 和 Context Window，而不是把它們交給框架。

LLM 是純函數。Context Engineering 就是在這個函數的輸入端做最佳化。這不是什麼神秘的 AI 技術，這是軟體工程的基本功：理解你的系統、掌控你的輸入、測量你的輸出、不斷迭代。只是現在，你的系統裡多了一個會輸出 JSON 的函數，而你的工作是確保它看到對的東西。