AI · 2026-07-01

提示工程(Prompt Engineering)作為一個獨立職位,在 2026 年幾乎消失了。取而代之的是「上下文工程」(Context Engineering)。Gartner 把它定義為提示工程的繼任者,Anthropic 在 2025 年 9 月發表的工程文章直接點出核心問題:重點不再是「找對措辭」,而是「什麼樣的上下文組態,最可能讓模型產生我們要的行為」。

換句話說,當代理(Agent)變成多步驟、多回合的系統,真正決定成敗的不是你怎麼問,而是你在每一步往模型的上下文視窗(context window)裡塞了什麼。業界一句話總結:現在大多數代理失敗,已經不是模型失敗,而是上下文失敗。

📖 學(核心)

為什麼提示工程不夠了

單次問答時代,你只要把問題寫清楚就好。但代理會跑很多回合:呼叫工具、讀回傳、再決策。光是工具回傳的結果,在代理真正處理使用者請求前,就可能吃掉超過 50,000 個 token。這時「怎麼措辭」已經不是瓶頸,「上下文裡有什麼、沒有什麼」才是。

Anthropic 對上下文工程的定義是:在 LLM 推論過程中,策劃並維護一組最佳 token 的整套策略——包含所有會進到上下文裡、但不屬於提示本身的資訊。目標說穿了很簡單:用最小、訊號最高的 token 集合,最大化拿到理想結果的機率。

上下文不是越多越好:Context Rot

很多人以為把資料全塞進百萬 token 視窗就萬事大吉。事實相反。Chroma 在 2025 年的研究系統性測試了 18 個前沿模型(GPT-4.1、Claude 4 系列、Gemini 2.5、Qwen3),發現一個現象叫「上下文腐化」(Context Rot):輸入越長,準確率非線性下滑,常常在標稱上限前就掉了 30% 到 50%。

具體一點:一個號稱 200K token 的視窗,可能在 5 萬 token 的輸入量就開始出現嚴重準確率損失;標稱 1M 的視窗,並不能可靠地對 1M token 進行推理。模型通常在達到宣稱上限前的 30%–40% 就先垮了。

更要命的是位置效應:多文件問答與鍵值檢索的準確率呈「U 形」——資訊放在開頭或結尾時最準,放在中間時準確率下滑超過 30%,這個現象在六個模型家族都重現。中間的資訊,模型基本上「看不太到」。

四個動作:Write / Select / Compress / Isolate

LangChain 把上下文工程歸納成四個操作,這是目前最實用的心智框架:

Write(寫出):把重要資訊持久化到上下文視窗之外,確保跨回合、跨 session 都能留存。例如把任務筆記、決策記錄寫進外部檔案或記憶體,而不是讓它在對話裡飄走。
Select(選取):每一步動態地把最相關的資訊拉進視窗,而不是全部硬塞。昨天談的 RAG 就是 Select 的一種手段,但 Select 的範圍更廣——選工具、選範例、選記憶,都算。
Compress(壓縮):把視窗裡的雜訊砍掉,常見做法是摘要與壓縮歷史對話,只保留高訊號的部分。
Isolate(隔離):給問題的不同部分各自乾淨的視窗。例如開一個子代理,只餵它完成某個子任務需要的上下文,跑完只回傳結果。隔離能避免一個環節污染另一個環節,是可靠多代理系統的基礎。

四種失敗模式

知道怎麼做,也要知道怎麼壞。LangChain 把代理上下文的問題歸成四種失敗模式,debug 時很好用:

上下文中毒(Context Poisoning):錯誤或無關的細節混了進來,後面一路被帶歪。
上下文分心(Context Distraction):關鍵資訊被雜訊埋掉。
上下文混淆(Context Confusion):太多不相關資料,代理失焦。
上下文衝突(Context Clash):矛盾的輸入,導致行為前後不一致。

據統計,2025 年將近 65% 的企業 AI 失敗,可歸因於多步驟推理過程中的上下文漂移或記憶遺失。

🧠 記

上下文工程 = 提示工程的繼任者;成敗在於「上下文裡放了什麼」,不是「怎麼措辭」。
Context Rot:上下文不是越多越好,模型常在標稱上限前 30%–40% 就準確率崩盤;中間位置的資訊最容易被忽略(U 形效應)。
四個動作:Write(寫出持久化)、Select(動態選相關)、Compress(壓縮去雜訊)、Isolate(隔離給子任務)。
四種失敗:中毒、分心、混淆、衝突——這是 debug 代理的檢查清單。
目標:用最小、訊號最高的 token 集合,最大化理想結果的機率。

✍️ 實踐

今天就能做的事:

量一下你的提示有多長:把你最常用的那個 AI 工作流程的完整輸入丟去算 token。如果動輒上萬,先問自己:這裡面有多少是模型真正需要的?把無關的歷史、重複的指令砍掉。
把長文件放在開頭或結尾:要 AI 根據一份長文件回答時,別把關鍵段落埋在中間。把最重要的內容放在輸入的最前或最後,避開 U 形低谷。
用 Compress 開新局:長對話拖久了,主動請 AI 先「摘要目前進度與關鍵決策」,然後開新對話貼上摘要繼續。這就是手動版的 Compress,能立刻擺脫累積的雜訊。
用 Isolate 拆任務:遇到複雜任務,別在同一個對話裡又查資料、又寫程式、又改文案。拆成幾個獨立對話各自處理,只把結果帶回主線。

🔗 延伸學習

💬 問 AI

我想把上下文工程套用在我自己的 AI 工作流程上。
請先問我目前最常用的一個流程是什麼、輸入大概多長,
然後用 Write / Select / Compress / Isolate 四個動作,
逐一指出我哪裡可以改善,並給出具體的調整建議。

請解釋「Context Rot」與「U 形位置效應」對我整理長文件提問的影響。
如果我有一份很長的資料要請你分析,
我應該怎麼安排內容順序與切分方式,才能讓你的回答最準確?

請扮演我的 AI 代理 debug 教練。
我描述一個 AI 代理表現異常的情況,
你用「中毒 / 分心 / 混淆 / 衝突」這四種上下文失敗模式,
幫我判斷最可能是哪一種,並給出排查步驟。

我的知識庫

探索