Agent 設計模式
從 Prompt 工程到上下文工程
當我們從單輪對話走向多步 Agent，僅僅優化 Prompt 已經遠遠不夠。真正的挑戰是：如何策展每一輪推理時送給模型的全部 Token。
概念演進
過去
Prompt Engineering
優化提示詞的寫法：措辭、結構、Few-shot 示例
現在
Context Engineering
策展每一輪推理時送給模型的全部 Token：System Prompt、工具定義、MCP 描述、對話歷史、外部檢索資料...
Prompt 工程關注的是怎麼寫指令，而上下文工程關注的是一個更大的問題：模型的輸入視窗裡放什麼、怎麼放、放多少。當你的系統有 System Prompt、工具描述、歷史訊息、RAG 檢索結果、使用者偏好…這些加起來可能佔滿大半個上下文視窗。如何管理這些 Token，就是上下文工程。
上下文視窗裡有什麼
System Prompt — 角色定義、規則、約束
Tool Definitions — 工具名稱、參數、描述
Conversation History — 多輪對話歷史
Retrieved Data — RAG 檢索結果、檔案內容
User State — 使用者偏好、會話狀態、環境資訊
所有這些加在一起 = 模型每次推理時看到的全部資訊
為什麼上下文工程重要
Context Rot
上下文越長，模型對資訊的檢索準確率越低。關鍵資訊被淹沒在海量 Token 中。
注意力預算有限
每個 Token 都在消耗模型的注意力預算。無關 Token 佔位 = 有用資訊被稀釋。
n-squared 複雜度
n 個 Token 產生 n x n 個注意力關係。上下文翻倍，計算量四倍增長。
動手試試：Context Rot 模擬器
1K Token -- 一段對話
注意力集中，檢索準確
檢索準確率
注意力密度
高注意力 低注意力
理解注意力的代價
Transformer 的自注意力機制中，每個 Token 都要和其他所有 Token 計算關聯度：
Attention Complexity = O(n^2)
這意味著：把上下文從 50K 擴展到 100K Token，注意力計算量會變為原來的 4 倍，遠超翻倍。上下文不是免費的：每多塞一個無關 Token，都在浪費其他 Token 能獲得的注意力。
高效上下文的三個原則
System Prompt 的合適高度
太模糊（「你是一個有用的助手」）= 模型缺乏方向感，輸出泛泛而談。
太具體（列舉 50 種邊界情況）= 模型被過度約束，無法靈活處理新情況。
最佳實踐：給出明確的角色定位和核心原則（5-10 條），然後信任模型在此框架下自主判斷。像好的管理者一樣，給方向，不給每一步的指令。
太具體（列舉 50 種邊界情況）= 模型被過度約束，無法靈活處理新情況。
最佳實踐：給出明確的角色定位和核心原則（5-10 條），然後信任模型在此框架下自主判斷。像好的管理者一樣，給方向，不給每一步的指令。
System Prompt 的高度要找到中間的甜蜜點
工具集要精簡
生產實踐驗證：如果人類都分不清該用哪個工具，AI 也分不清。
給 Agent 10 個功能相似但描述模糊的工具，不如給 5 個職責清晰、命名精準的工具。每個工具的 description 要像好的 API 文件一樣，讓呼叫者（模型）一看就知道什麼時候用、怎麼用。
給 Agent 10 個功能相似但描述模糊的工具，不如給 5 個職責清晰、命名精準的工具。每個工具的 description 要像好的 API 文件一樣，讓呼叫者（模型）一看就知道什麼時候用、怎麼用。
Few-shot 精選典型，不要堆砌
Few-shot 示例是上下文中 ROI 最高的部分，但前提是選對了。
正確做法：精選 2-3 個最能代表目標行為的典型例子，覆蓋最常見的輸入模式。
錯誤做法：堆砌 10+ 個邊界 case 的例子，不僅浪費 Token，還讓模型過度關注異常情況而忽略主線。
正確做法：精選 2-3 個最能代表目標行為的典型例子，覆蓋最常見的輸入模式。
錯誤做法：堆砌 10+ 個邊界 case 的例子，不僅浪費 Token，還讓模型過度關注異常情況而忽略主線。
上下文是稀缺資源。你的目標是找到最小的高訊號 Token 集合。每一個 Token 都必須為模型的推理做出貢獻，能放多少就放多少的思路行不通。像編輯精修文章一樣精修你的上下文：每個多餘的詞都是噪音。