2026 年脈絡工程實戰：如何在有限的上下文視窗裡餵給模型真正的答案

隨便挑一個 2025 年中穩穩跑在生產環境裡的代理，今天重跑一次，你會撞上同一種沉默的失敗：跑到第 30 步，模型開始憑空捏造工具名稱、自打嘴巴把第 4 步的計畫推翻，並且自信地回傳一份檢索系統根本沒吐出的資料。Prompt 沒變、模型沒變、檢索沒變。變的是代理一路累積下來的脈絡已經多到把注意力預算壓垮了。這就是脈絡工程（context engineering）要解決的問題，而在 2026 年，它已經不再是選配。

Prompt 工程——把對的句子寫在最前面——解決了上一代的難題，但解決不了下一代。現代代理會跑上數小時、呼叫數十個工具、抓回上千份文件，最後產出的答案依賴它整個 session 看過的所有東西。真正有意思的工程工作，已經從「怎麼寫 prompt」搬到「怎麼替模型篩選它看見的東西」。這個紀律是 Anthropic 在 2025 年底定名的脈絡工程，而 LangChain、Cognition、Manus，以及多數前沿團隊到現在都已經把它當作代理可靠性的主要操作桿。

先把觀點寫在前面：如果你的代理擁有超過三個工具、會跑超過十個輪次、或每次任務抓超過二十份文件，那它每次執行都在繳一種隱形稅。稅的形式是 hallucination、漏掉的約束、失控的成本，以及「這個代理跑越久看起來越笨」的詭異感受。解法不是換更大的模型，也不是換更聰明的 prompt，是一套刻意設計的系統——在每一個步驟，把「最小集合的高訊號 token」放進脈絡視窗。

舊規則為什麼失靈了

兩件事同時發生。模型的脈絡視窗變長——20 萬、40 萬、甚至 100 萬 token——而工程團隊像所有人碰到更粗的水管一樣，把更多東西塞了進去。Chroma Research 把這個失敗模式命名為 context rot：token 越多，模型從中精準召回資訊的能力就越差。它不是斷崖式的崩壞，而是慢慢下滑、再加速下滑；等到你的脈絡裡大半是工具呼叫紀錄與檢索噪音時，模型的表現就像被迫讀一本千頁操作手冊、而它只記得其中一半的語言。

理由出在 Transformer 架構本身：每個 token 都對其他所有 token 投以注意力，這會產生 n² 的成對關係。脈絡越長，模型越要把注意力攤到更多關係上，於是每一條關係的精準度就跟著掉。模型在比較短的序列上訓練，對長距離依賴的專門電路本來就少。脈絡越長，模型越是在它的訓練分佈之外工作。

這不是前沿模型的專利。每個模型、每種規模、每家供應商的基準測試都重現這個現象。實務上的結論是：脈絡是會遞減邊際報酬的有限資源。Anthropic 的說法已經變成這個領域的工作定義：好的脈絡工程，就是在每一輪找出「最小集合的高訊號 token」，最大化達成目標結果的機率。

第二個轉變是代理變成了主流介面。聊天機器人只有一次出手的機會，代理則要出手上百次。每一次工具結果、每一次檢索、每一段推理、每一次重試，都把更多內容推進視窗。Drew Breunig 在 2025 年中整理了這些失敗模式——context poisoning（幻覺污染脈絡後繼續擴散）、context distraction（內容量大到壓過訓練）、context confusion（多餘脈絡影響輸出）、context clash（脈絡裡各段互相矛盾）。這些不是極端案例，而是任何跑得夠久的代理每天都會經歷的常態。

脈絡工程 vs Prompt 工程——真正的差別

兩個紀律站在技術堆疊的不同層。Prompt 工程是寫好一條指令字串的工藝；脈絡工程則是設計「模型看見什麼」這個系統，涵蓋 prompt 之外的所有東西。下表是最乾淨的對照。

面向	Prompt 工程	脈絡工程
範圍	一條指令字串	推論時模型看見的所有東西
表面	系統 prompt + 使用者訊息	指令、檢索文件、記憶、工具定義、歷史、輸出綱要
狀態	無狀態或單輪	有狀態、多輪、跑數小時
優化目標	更好的措辭、更少的歧義	脈絡視窗裡更高的訊號雜訊比
失敗模式	模型誤讀任務	模型拿到太多、太少、或錯的資訊
負責人	任何寫 prompt 的人	負責打造代理管線的平台團隊

判斷你已經從一個紀律跨到另一個的方法很簡單：改善是來自改字句，還是來自改接線？如果你在換名詞和形容詞，你還在寫 prompt；如果你在改「代理抓什麼資料、用什麼順序、如何重排、視窗滿了要淘汰哪些」，你就在做脈絡工程。Prompt 工程依然必要，脈絡工程則讓其他所有代理工作撐得起來。

2026 年真正有效的四個模式

不同作者切割這塊領域的方式略有不同。Anthropic 走過系統 prompt、工具、範例、訊息歷史四塊；LangChain 把操作形式化為四個動詞：write、select、compress、isolate。實務上比較好用的整理方式，是按四個模式來切——每一個模式回答代理每一步都要回答的不同問題。

1. 漸進式揭露與技能

一個同時處理客服、帳務、退款、新手引導的代理，並不需要在每一輪都載入四套完整指示。全部載入，多數視窗空間會浪費在「這輪用不到」的指引上。傳統替代方案——為每個領域開一支專門子代理——會疊上編排負擔、重複共用邏輯，還會被代理間通訊的延遲拖累。兩條路都撐不起規模。

漸進式揭露分層載入資訊。先做探索（只讀名稱與描述）、需要時啟用（完整指示）、執行任務時才載入（腳本與參考資料）。Anthropic 的 Agent Skills 是這種模式的標準實作：一個 markdown 檔配 YAML frontmatter，平台啟動時只讀名稱與描述——每個技能大約 80 token——等到模型判斷技能相關時，才把完整的指示本體載入。Anthropic 預設 17 個技能在探索階段合計約 1,700 token，比一次全部載入省下一個量級。

最有趣的應用是身分管理。Claude Code 不是一支「PDF 代理」加一支「試算表代理」——它是一支代理，啟用對應技能後改變行為來配合任務。這個模式可以推廣到任何「需要廣泛能力、但執行要聚焦」的系統，而且 skills 是純英文 markdown，領域專家不必懂工程就能設定代理行為。

2. 脈絡壓縮

每一次工具呼叫、每一筆觀察、每一段推理都會累積進脈絡。如果不處理，歷史會塞爆視窗，把系統指示、工具定義、任務前段真正需要用來推理的內容推出去。這個領域已經收斂到一個主流解法：滑動視窗加上摘要混合——最近的輪次完整保留、較舊的脈絡透過 LLM 摘要壓縮。

Manus 四次重寫代理框架後留下兩個值得帶走的細節。第一，最近的幾輪工具呼叫要保留原始格式——失去那種節奏會造成難以察覺的退化。第二，不要把錯誤堆疊摘要掉。工具呼叫失敗時，把錯誤訊息和堆疊留在脈絡裡，能幫模型避免重複同一個錯誤。Anthropic 的 compaction beta——compact-2026-01-12 原語——會在 token 觸發點（常見設定約 18 萬）自動啟動，把對話摘要後繼續執行。軌跡大致保持平穩，視窗則循環更新。

壓縮本質上是有損的。重點在於選擇丟什麼。原始保留：最近幾輪工具呼叫、錯誤堆疊、當前計畫。壓縮或淘汰：代理不會回頭看的舊工具輸出、模型已經引用過的檢索文件、已被取代的中間推理。

3. 即時檢索

預檢索式——對整個知識庫做向量搜尋、把 top-K 倒進 prompt、然後生成——是經典的 RAG 模式，對小型任務仍是對的預設。對長時程代理，這個形狀是錯的。代理應該握著輕量識別碼（檔案路徑、查詢字串、文件 ID），透過工具在需要時才把資料載入。

Claude Code 就是這個做法。CLAUDE.md 開頭先以小量、always-on 的規則集形式落入脈絡；glob、grep 這類基本工具讓代理可以邊走邊查、必要時才讀檔。模型可以寫精準的查詢、把結果存下來、用 head 和 tail 檢查大檔，永遠不需要把整份內容倒進視窗。這正好對應人類的認知：我們不會把整個語料庫背起來，而是靠檔案系統、書籤、搜尋把需要的東西即時拉出來。

取捨是真的：執行期探索比預檢索慢。對的答案還是混合——一開始先載入小型規則集（CLAUDE.md、系統 prompt、關鍵 schema），其餘靠工具即時載入。對法律、財務這類底層語料較靜態的工作，前置載入更多脈絡划算；對編寫程式、搜尋、多步研究這類「相關資料要邊走邊發現」的任務，即時載入才是對的預設。

4. 工具表面精簡

Anthropic 在生產環境看到最常見的失敗模式，是工具集合過於臃腫。如果連人類工程師都沒辦法斬釘截鐵地說「這個情境該用哪個工具」，那就不能期待 AI 代理做得更好。「對的工具數量」幾乎永遠比團隊第一版上架的數量還要少。

2026 年真正重要的工具設計選擇：

• 工具要自足。每個工具都該有單一明確的目的、健全的錯誤處理、和毫不模糊的契約。如果兩個工具都能「查客戶」，把它們合併。
• 回傳值要節省 token。一個工具回 4,000 token JSON、但代理只要三個欄位，等於每次呼叫都在浪費脈絡。用分頁、投影、選擇性檢索。
• 參數名要敘述清楚。customer_id 比 id 清楚。看起來像拼錯字的名稱會產生可預期的誤用。
• 不要在迭代中途動態新增或刪除工具。工具定義落在脈絡前段，任何變動都會讓後續所有輪次的 KV-cache 失效。重置 cache 的成本通常超過「工具變少」省下的成本。

脈絡管線——它實際上怎麼跑

脈絡不是人工組裝的。它是每輪都會跑一次的管線輸出。一條典型的 2026 管線長這樣：

1. 使用者輸入送達。系統對查詢分類、辨識啟用中的技能或路由目標、決定要查哪些檢索來源。
2. 檢索平行展開。向量搜尋、關鍵字搜尋、結構化查詢、程式碼圖查詢——同時跑，結果合併成候選集合。
3. 記憶層拉出短期脈絡（對話歷史的相關切片、最近的工具結果）與長期脈絡（持久筆記、使用者偏好、過往摘要）。
4. 系統指示與工具定義疊上去。在多代理系統裡，每支子代理會以更窄的範圍跑同一條管線，再回報結果。
5. 完整脈絡送進模型。輸出串流回來；工具呼叫則帶著新查詢回到第 2 步。

token 預算在每一步都會被強制執行。一個常見模式是分段預算：系統 prompt 1,500 token、工具定義 2,000 token、檢索文件 5,000 token、訊息歷史 8,000 token、當前步驟 scratchpad 3,000 token。某一段超出預算時，壓縮或淘汰會在呼叫模型之前先啟動。

2026 年真正在改變的事情

今年有三個趨勢把這門學科往前推。它們都不是新框架，都是操作實務的改變。

Skills 成為一級抽象。Anthropic 在 2025 年 12 月推出後，OpenAI、Google、GitHub、Cursor 在幾週內相繼採用，Agent Skills 已經是模組化代理行為的標準做法。最有意思的發展是「代理自己寫技能」。Claude Code 的 skill-creator 觀察自己成功的行為、把它歸納成新的技能檔、加進技能庫。品質不一定穩定，但方向是把迴路關起來——人類先寫初始技能，代理再從經驗延伸技能庫。

Compaction 變成基礎設施。Anthropic 2026 年 6 月釋出的《2026 Agentic Coding Trends Report》，把脈絡工程框為今年的承重技能。脈絡檔維護得好的團隊，錯誤少 40%、任務完成速度快 55%。Compaction 原語——compact-2026-01-12 與同類——現在以 beta 形式直接出貨在 frontier model API，而不是各家各自包裝的第三方工具。壓縮觸發點、摘要策略、cache 保留邏輯，都正在變成一級設定，而不是每個團隊各自重新發明的工程工作。

ContextOps 進入組織層。個人層級的脈絡工程——一位開發者寫一份仔細的 CLAUDE.md——確實有價值，但它終究是團體賽中的個人練習。真正拉開差距的組織，是把脈絡操作化到整個組織層：單一可信來源的編碼慣例，自動配送到每個 repository 的每支 AI 助理。Packmind、Thoughtworks 的 Birgitta Böckeler、R Systems 的 Neeraj Abhyankar 都把這個方向框為企業 AI 基礎建設的未來 12 到 18 個月。現在就把這一層蓋起來的團隊，正在累積複利優勢。

常見錯誤——一直反覆咬人的那些

2026 年脈絡工程專案的失敗模式看起來驚人地一致。六個要特別注意的：

• 預設全部載入。最常見的錯誤。每段脈絡都全量載入每輪，因為載入比思考省事。代理頭幾輪還行，接著就退化。解法：從第一天起就為每段設 token 預算。
• 脈絡檔只剩 prompt 性質。一份寫著「遵循 clean architecture 原則」的 CLAUDE.md 是給人看的寫作提示，不是代理能執行的脈絡規則。把每個模糊的形容詞換成模型能偵測違規的具體規則。「資料存取層用 repository pattern」可被執行；「寫出乾淨的程式碼」不行。
• 忽略工具定義。團隊花數小時調系統 prompt，卻讓工具定義與之矛盾。如果系統 prompt 寫「永遠驗證輸入」，但工具定義沒有驗證 hook，代理會傾向採用工具的行為而不是 prompt 的指令。工具也是脈絡的一部分。
• 壓縮過於激進。壓縮門檻設太低——5 萬 token——為了「省錢」。關鍵的早期細節被摘要掉，模型在第 20 步就失去主線。解法：分層壓縮、保留錯誤堆疊、保留當前計畫。
• 沒有衡量脈絡品質。團隊分不清新的壓縮策略是在幫忙還是扯後腿，因為沒有評估在量差異。解法是做一套小型 held-out 評估集（50 到 100 個具代表性的任務），每晚以同一個生產指標對新舊策略各跑一次。
• 以為脈絡越多越安全。事實恰恰相反。最強的脈絡工程實作是「先減再加」。如果一塊資訊不是下一步必要的，就別放進去。你每少加一個 token，模型就多一個 token 可以花在真正要做的工作上。

什麼時候值得投入脈絡工程——什麼時候殺雞用牛刀

不是每個應用都需要一條完整的脈絡管線。一次性摘要、單輪分類、靜態 FAQ 機器人——這些都不需要漸進式揭露、壓縮、技能路由。值得投入的情境是：

• 你的代理會跑超過十輪、呼叫超過三個工具、或每次任務抓超過二十份文件。
• 你觀察到品質隨脈絡增長而退化——過某輪之後 hallucination 增加、工具呼叫送錯目標、代理忘記原本任務的約束。
• 你的 token 帳單不是小數目。壓縮、路由、技能揭露帶來的成本節省，一旦代理上線就會複利放大。
• 你需要可稽核性——能解釋代理用哪些資訊做出決定。脈絡工程是達成可稽核性的唯一路徑。

下列情境可以跳過：

• 任務是單輪、單次模型呼叫就解決。Prompt 工程就是全部答案。
• 你無法控制脈絡。如果你只是包別人的 API、影響不了視窗裡放什麼，那工作在你上游。
• 你在做原型。先寫死一份最簡單、能用的脈絡、上線、觀察真實流量長相，再決定要不要投資管線。

一份實戰起手檢查表

1. 量測目前的脈絡成本。連續一週，記錄每輪平均 token、各段分佈、觀察到的失敗模式。沒有這個基準就是盲飛。
2. 找出目前脈絡裡雜訊最高的三個區塊。通常是：工具定義、檢索文件、舊工具結果。把它們各砍一半，量對品質的影響。
3. 把任何模組化行為改寫為 skill。如果代理要負責兩個以上領域，把每個領域模型化成一個 skill：探索中繼資料、完整指示、執行腳本。
4. 加上 compaction 觸發。大多數生產代理會從「滑動視窗 + 摘要」混合策略獲益，門檻設在模型視窗的 60–70%。用 held-out 評估集測，不要直接對線上使用者測。
5. 稽核工具表面。如果你的工具超過十五個，合併或刪除，直到剩下的集合是人類也能自信選用為止。
6. 加上每輪 token 預算。為脈絡每段設固定上限；任何一段溢出時若無明確覆寫，就拒絕組裝 prompt。
7. 每晚跑脈絡品質評估。挑一份小型、有代表性的任務集，用與生產同一個指標評分，分別跑「有套用新脈絡工程」與「沒套用」，給你迭代的訊號。
8. 若有多個領域就建一條脈絡路由層。在管線頂端放一個小型分類器，決定要載入哪些知識庫、哪些工具、哪些技能——這個動作省下的脈絡比任何單一優化都多。

常見問題

什麼是脈絡工程？

脈絡工程是一門紀律：在每一次推論呼叫中，挑選並維護模型看見的最佳 token 集合。它涵蓋所有會落入脈絡視窗的東西——系統 prompt、工具定義、檢索文件、記憶、訊息歷史、累積的動作軌跡。Prompt 工程聚焦在指令字串，脈絡工程聚焦在整個資訊環境。

脈絡工程跟 Prompt 工程有什麼不同？

Prompt 工程是子集。每條寫得好的 prompt 都是脈絡的一部分，但脈絡還包含模型在推論時看見的其他所有東西。兩者互補，不是競爭。實務上，2026 年的代理團隊大概花 10% 力氣在 prompt 措辭、90% 在圍繞它的脈絡管線。

什麼是 context rot？

context rot 是指脈絡視窗 token 變多時，模型表現出現可觀察的退化。模型的注意力預算有限，每加一個新 token 就在爭奪預算。token 越多，從脈絡任何特定位置精準召回的能力就越低。Chroma Research 提出了這個詞；背後的現象在所有主要模型家族都能重現。

什麼是脈絡壓縮原語？

壓縮原語是模型或 API 內建的功能，會在 token 觸發點自動把對話較舊的部分做摘要。Anthropic 的 compact-2026-01-12 是目前作為 beta 釋出的實作——它在可設定的觸發點（常見 18 萬 token）啟動，把先前脈絡摘要後繼續執行，軌跡不會中斷。其他前沿供應商也在出貨類似功能。

小型語言模型也需要脈絡工程嗎？

需要——有時比大模型更需要。小模型的有效脈絡視窗更小、可分配的注意力預算更少、訓練資料裡長序列也更少。對小模型來說，雜訊脈絡的代價比 frontier 模型更高。紀律一樣，只是預算更緊。

脈絡工程只是 RAG 的進階版嗎？

不是。RAG 是脈絡工程的一個元件——檢索是外部知識進入視窗的方式。脈絡工程還包括這些知識進來之後會怎樣（壓縮、隔離、技能啟用）、它如何與對話歷史和工具結果互動、以及視窗滿了會淘汰什麼。

最後一句話

Prompt 工程教會這個領域怎麼寫指令；脈絡工程正在教它怎麼工程化整個資訊環境。已經吸收這個差別的團隊，是能在生產環境裡跑上好幾小時還穩穩的團隊。還沒吸收的團隊，會看著自己的代理在第 30 輪之後悄悄退化、然後把責任推給模型。解法幾乎從來不是模型。幾乎都是視窗裡裝了什麼。