context engineering 是什麼？決定模型看到什麼

2025 年 6 月 18 日，Shopify 執行長 Tobi Lütke 在 X 發了一則短貼文：「比起 prompt engineering，我更喜歡『context engineering』這個詞。它更準確地描述了核心技能：為任務提供所有必要的上下文，讓問題對 LLM 來說變得可解。」

一週後的 6 月 25 日，Andrej Karpathy 跟進背書：「+1。人們一聽到 prompt，想到的是日常丟給聊天機器人的短指令。但在每一個工業級 LLM 應用裡，context engineering 才是那門精巧的藝術與科學——在 context window 裡填進剛剛好的資訊，供下一步使用。」

兩則推文，一週之內，一個新職能有了名字。Hacker News 吵上首頁，LangChain 一週後端出方法論，三個月後 Anthropic 發了官方工程指南。

上下文工程（context engineering）是一套策劃與維護「模型在推論當下看到哪些資訊」的方法：把任務需要的指令、資料、工具結果與對話歷史，以剛好夠用的形式放進上下文視窗（context window）。prompt engineering 關注怎麼把問題問好；context engineering 關注模型做決定的那一刻，手上到底有什麼。這個詞在 2025 年 6 月由 Shopify 執行長 Tobi Lütke 定調、Andrej Karpathy 背書後流行，如今是 AI agent 開發的核心技能。

詞是 2025 年 6 月才有的。痛，做 agent 的人早就在痛了。

詞怎麼紅的：一週從推文變成方法論

其實比 Lütke 更早幾天，2025 年 6 月 12 日，Cognition（Devin 的開發商）的 Walden Yan 在〈Don’t Build Multi-Agents〉一文就把 context engineering 列為 agent 可靠性的第一原則。他的講法：prompt engineering 是為聊天機器人把任務寫成理想格式的功夫，context engineering 是它的下一級——而且「這實際上是打造 AI agent 的工程師的頭號工作」。

接下來的半年，這個詞以罕見的速度完成制度化：

時間	事件
2025 年 6 月 12 日	Cognition 的 Walden Yan 在〈Don’t Build Multi-Agents〉把 context engineering 列為 agent 可靠性核心原則
2025 年 6 月 18 日	Tobi Lütke 推文定調這個詞
2025 年 6 月 25 日	Karpathy「+1」，詞徹底出圈
2025 年 7 月 2 日	LangChain 發表〈Context Engineering for Agents〉，把手法歸納成 write、select、compress、isolate 四類
2025 年 7 月 14 日	Chroma Research 發表 Context Rot 報告，補上實驗證據
2025 年 9 月 29 日	Anthropic 發表官方工程文〈Effective context engineering for AI agents〉

為什麼是 2025 年年中？因為 agent 在那半年起飛。Claude Code、Devin、各家 Deep Research 類產品，把 AI 的工作型態從「一問一答」拉長成幾十分鐘、上百次工具呼叫的長程任務。單次把 prompt 寫漂亮，管不了這種規模——每一步餵進模型的東西，才決定它第 50 步還清不清醒。

跟 prompt engineering 的邊界

把 context window 想成一張固定大小的工作桌。prompt engineering 是把便利貼上的要求寫清楚；context engineering 是管理整張桌面：攤開哪幾份文件、收走哪些看完的、把上週的結論濃縮成一頁摘要，還是請同事在自己桌上整理完、只交回一張結果。桌面就這麼大，擺錯東西比寫錯便利貼更常害你做錯事。

兩者的分工可以並排看：

	prompt engineering	context engineering
管什麼	指令怎麼寫	模型看到的全部資訊
工作單位	一段 prompt	整個 context window 的組成
典型場景	聊天一問一答	agent 長程多步任務
失敗樣態	問題問不清楚	資訊太多、太雜、太舊
代表動作	措辭、給範例、定格式	檢索、壓縮、隔離、記憶

Anthropic 那篇工程文的定義畫得更細：context engineering 涵蓋推論時模型看到的所有 token——系統提示（system prompt）、工具定義、few-shot 範例、對話歷史、檢索回來的資料，prompt 只是其中一塊。照這個框架，檢索增強生成（RAG）也算 context engineering 的手段之一：RAG 解「去哪拿對的資料」，context engineering 還要管「拿來之後放多少、放哪裡、什麼時候丟掉」。

Context rot（上下文腐蝕）：塞越多，答越差

如果 context engineering 只是「把有用的東西都塞進去」，那它不值得一個新名字。它成立的前提是一個反直覺的實驗事實。

2025 年 7 月 14 日，向量資料庫公司 Chroma 的研究團隊（Kelly Hong、Anton Troynikov、Jeff Huber）發表技術報告，把這個現象命名為 context rot（上下文腐蝕）：他們實測 18 個前沿模型——包括 GPT-4.1、Claude 4 家族、Gemini 2.5、Qwen3——發現模型的表現會隨輸入長度上升而變得不穩定，而且遠在規格標示的上限之前就開始退化。

三個實驗設計都刻意簡單：

1. 加強版大海撈針——在經典的 needle-in-a-haystack 檢索任務上，加入語意相近的干擾項、調整問題與答案的相似度。結果：干擾項的殺傷力會隨輸入變長而放大。
2. LongMemEval 對話問答——讓模型在約 11 萬 token 的聊天紀錄裡回答問題。只餵相關片段的版本，明顯贏過餵整份歷史的版本。
3. 重複字串複製——連「照抄一串重複的字、其中藏一個不同的字」這種零推理任務，準確率都會隨長度下滑。

這份報告戳破了一個行銷敘事：規格表上的 100 萬 token 上限是「裝得下」，裝得下與用得好是兩件事，模型對 context 的使用並不均勻。Anthropic 後來在自家工程文裡把這件事講成了設計原則——模型有 attention budget（注意力預算），「context 必須被當成報酬遞減的有限資源來對待」。

2026 年的實務手法：從塞好塞滿到動態管理

知道 context 是有限資源之後，工程手法就跟著長出來了。Anthropic 那篇工程文列了四招，LangChain 的 Harrison Chase 則把同類手法歸納成 write、select、compress、isolate 四類，講的是同一件事：

1. Compaction（壓縮重整）——對話快撐滿時，把歷史摘要成一段、開新視窗重來。Claude Code 的 /compact 就是這招的產品化。代價：摘要一定丟細節，摘錯了錯誤會一路複利。
2. 結構化筆記（structured note-taking）——把關鍵狀態寫到 context 之外的檔案（例如 NOTES.md、待辦清單），需要時再讀回來。模型的「工作記憶」有限，那就給它一本筆記本。
3. Subagent 隔離——讓子代理在自己的 context 裡翻幾萬 token 的資料，只把幾百字的結論帶回主線。Cognition 曾警告多 agent 平行決策容易彼此打架；Anthropic 的用法是把「搜集類」工作丟給 subagent、決策留在主 agent，兩種立場在這點上其實相容。
4. Just-in-time retrieval（即時檢索）——先只放檔案路徑、連結這類輕量引用，模型真的要用再去撈全文。人也這樣工作：你不會為了寫一封信先背下整個資料夾。

對照 2025 年年中那波「把 RAG 結果全部倒進 prompt」的做法，2026 年的主流已經走向動態管理：memory（跨 session 記憶）、compaction、context 隔離，從加分項變成 agent 框架的標配。在概念階梯上，context engineering 接在 prompt engineering（2023 年前後流行）之後；後來社群又往上疊出 harness engineering、loop engineering 這類新詞，關注點從「單步餵什麼」擴到「整個工作迴圈怎麼架」。這一級先站穩，上面幾級才有地基。

限制、代價，以及你可以先做的一件事

誠實講邊界。

每一招都有工程成本。 compaction 的摘要 prompt 要調、筆記格式要設計、subagent 要防呆——這些都是要長期維護的程式碼，比「直接塞」貴得多。小量、單輪的應用，prompt 寫好就夠，不需要為了名詞上這一整套。

詞有膨脹風險。 2026 年什麼都能叫 context engineering。聽到這四個字，先問對方具體做了哪一件事：檢索？壓縮？隔離？記憶？答不出來的，通常只是把 RAG 換了個新包裝。

手法會過時，前提不會。 長 context 能力每一代模型都在進步，2025 年的某些補償技巧會被淘汰。但「注意力是有限資源」這個底層事實，短期內不會變——Chroma 測的 18 個模型沒有一個免疫。

可以直接試的一件事：下次你的 AI 答錯，先把它實際看到的 context 挖出來——RAG 應用就把檢索回來的片段印出來，Claude Code 就看看是不是該 /compact 了。十次有八次，問題出在餵料。模型答錯時，先驗它看到了什麼，再怪它不夠聰明。

帶走一條判斷準則就好：把 context window 當成有限預算在管，每個 token 都要賺回自己的位置。至於 memory 跨 session 累積時，怎麼避免把舊錯誤一路帶著走——這是 2026 年年中還沒有共識答案的未解題。

資料來源：Tobi Lütke（X）、Andrej Karpathy（X）、Anthropic Engineering、Chroma Research、Cognition、LangChain

矽基前沿 · 大百科線（編輯：廖玄同），《context engineering 是什麼？決定模型看到什麼》，矽基前沿 [Si]gnals，2026-07-05。https://signals.tw/articles/what-is-context-engineering/