Prompt尚在探索，行業(yè)為何已熱議Context Engineering？

說到AI相關的技術或者職業(yè)，想必大家多會想到一個詞就是 Prompt Engineering。
很多人以為，大模型應用的核心競爭力，就是“會寫提示詞”。

這話不能說錯，但只對了一半。

這兩年，隨著 Agent、工具調(diào)用、長期記憶、企業(yè)知識庫、代碼代理這些能力快速落地，行業(yè)越來越清楚地發(fā)現(xiàn)：

Prompt 決定一次回答的起點，Context 決定一個智能體能走多遠。

換句話說，很多系統(tǒng)做不好，不是因為模型不夠強，也不是因為 prompt 寫得不夠花，而是因為：

• 給模型的信息太亂
• 歷史內(nèi)容太臟
• 工具結果太冗余
• 檢索內(nèi)容不準
• 狀態(tài)信息不連續(xù)
• 長期記憶和當前任務沖突

所以最近一個詞開始迅速升溫：

Context Engineering（上下文工程）

它正在從“小圈子討論”變成 AI 工程里的核心能力。Anthropic 在 2025 年 9 月專門發(fā)文討論 “為 AI agents 做有效的 context engineering”，強調(diào) agent 正從“預先把所有信息塞進 prompt”轉(zhuǎn)向“運行時按需、即時加載上下文”的設計方式。OpenAI 的 Agents SDK Cookbook 也把上下文管理、短期記憶修剪、長期記憶注入和狀態(tài)管理，直接放到了 agent 構建方法論的中心位置。

如果說過去兩年大家在研究“怎么問”，
那么現(xiàn)在行業(yè)開始真正研究的是：

怎么把模型需要知道的世界，組織成它能高效理解和推理的樣子。

這，就是 Context Engineering。

一、什么是 Context Engineering？

可以先給一個通俗定義：

Context Engineering，就是在模型每一次推理前，決定“該讓它看到什么、按什么順序看到、保留什么、丟掉什么、何時補充什么”的系統(tǒng)工程。

它不只是 prompt 的升級版，也不只是 RAG 的同義詞。

它更像是一個總控層，負責協(xié)調(diào)系統(tǒng)指令、用戶當前問題、歷史對話、檢索結果、工具返回、任務狀態(tài)、用戶偏好、長期記憶、權限與約束。

Anthropic 在 “Building Effective AI Agents” 里把現(xiàn)代 agent 的基礎模塊明確概括為：LLM + retrieval + tools + memory；而在后續(xù)關于 context engineering 的文章里，又進一步強調(diào)：隨著 agent 變得更自主，很多團隊開始從靜態(tài)檢索，轉(zhuǎn)向“just in time”的運行時上下文加載策略。

這其實已經(jīng)說明一件事：

今天的大模型應用，不再只是“問答系統(tǒng)”，而是在構造一個動態(tài)上下文操作系統(tǒng)。

因為 Prompt 本質(zhì)上只是一句話或一組指令。
但今天一個真實的 AI Agent，在一次任務里看到的內(nèi)容，往往早就不是一句話了，而是這樣的組合：

這意味著：
模型每次并不是在“回答一個問題”，而是在“理解一個臨時構造出來的微型世界”。

這個世界構造得好，模型就穩(wěn)定。
這個世界構造得差，模型就會混亂。

OpenAI 在關于 session memory 的 Cookbook 中明確指出，即便模型上下文窗口已經(jīng)很大，仍然會被未整理的歷史、多余的工具結果和噪聲檢索迅速淹沒，因此上下文管理不是優(yōu)化項，而是必需項。它特別提到修剪、壓縮能提升多輪一致性、工具調(diào)用準確率，并降低延遲和成本。

這也是為什么很多人做 Agent 時常遇到這些問題：

• 前后說法不一致
• 調(diào)錯工具
• 重復執(zhí)行同一步
• 忘記剛剛做過什么
• 被舊內(nèi)容“帶偏”
• 成本和延遲越來越高
• 越跑越不穩(wěn)定

問題看起來像“推理不行”，本質(zhì)上往往是：

上下文失控了。

我更愿意把它拆成 5 個核心動作。

1、選擇：不是所有信息都該進模型

Context Engineering 的第一步，不是“多給”，而是“少給但給對”。

很多初學者容易犯一個錯誤：

覺得模型越強，就應該把越多東西一股腦塞進去。

但現(xiàn)實恰恰相反。
大模型真正怕的，很多時候不是信息少，而是噪音太多。

比如用戶說：

繼續(xù)昨天那個協(xié)議符合度測試工具的設計。

這時系統(tǒng)真正該送進去的，應該是：

• 昨天的設計摘要
• 當前模塊狀態(tài)
• 用戶已確定的技術路線
• 跟“功能測試層”相關的歷史結論

而不是：

• 無關閑聊
• 舊的廢棄方案
• 全量原始日志
• 與當前任務沒關系的文檔片段

Anthropic 在 context engineering 文章里提到，很多 agent 開始采用“輕量標識符 + 運行時按需取數(shù)”的思路：先保留文件路徑、查詢引用、鏈接等索引，而不是把所有內(nèi)容提前塞滿上下文；需要時再動態(tài)取回。Claude Code 在處理大體量數(shù)據(jù)分析時，也會用 Bash 的 head、tail 等方式只讀取必要片段，而不是把整個對象都灌進上下文。

這說明，Context Engineering 的第一原則不是“大而全”，而是：

相關、及時、可控。

如果說選擇解決的是“給什么”，
那壓縮解決的就是“怎么給”。

OpenAI 在 session memory 的官方示例中，把trimming（修剪）和compression（壓縮）作為兩種核心上下文管理技術，并指出這樣做可以維持長線程的一致性、減少工具調(diào)用失敗、降低 token 成本，并抑制上下文污染。

這一點在工程里極其重要。

例如一次工具調(diào)用返回 5000 行日志。
你不能原樣塞給模型，而要把它壓成可推理的信息塊：

失敗原因摘要：1. 參數(shù)名不一致2. 返回結構為空3. timeout 超過閾值4. 上一輪緩存未清理

這里的關鍵，不是把字數(shù)變短，
而是把噪聲信息壓成因果結構。

真正好的上下文壓縮，應該保留：

• 決策依據(jù)
• 關鍵異常
• 已完成步驟
• 尚未解決的問題
• 影響下一步行動的約束

壓縮失敗的系統(tǒng)，常常會出現(xiàn)兩種極端：

• 壓得太狠，關鍵信息丟了
• 壓得太松，token 爆了，模型也亂了

所以從工程視角看，壓縮并不是“摘要一下”那么簡單，它本質(zhì)上是：

把原始軌跡整理成模型可持續(xù)利用的工作記憶。

很多人提到 Context Engineering，第一個想到的是 RAG。
但我更想說一句：

RAG 只是把東西找回來，Context Engineering 決定這些東西能不能被模型用好。

Anthropic 在 “Contextual Retrieval” 文章中指出，傳統(tǒng) RAG 的一個核心問題，是在編碼文檔時會把原始語境剝離掉，導致檢索失敗。為此他們提出了 Contextual Retrieval，并給出數(shù)據(jù)：該方法可將檢索失敗降低 49%，與 reranking 結合時可降低 67%。

這組數(shù)據(jù)很有啟發(fā)意義，因為它告訴我們：

• 不是“檢到就行”
• 不是“相似度高就行”
• 不是“片段多就行”

真正決定質(zhì)量的，是：

• 片段本身有沒有保留語境
• 排序是否合理
• 是否和當前任務綁定
• 是否與歷史狀態(tài)一致
• 是否會和系統(tǒng)規(guī)則沖突

也就是說，未來企業(yè)做知識庫，真正的難點越來越不在“有沒有向量庫”，而在：

能不能把檢索結果組織成高質(zhì)量上下文。

普通聊天系統(tǒng)的失敗，最多是答偏。
Agent 的失敗，往往是任務中斷、重復執(zhí)行、狀態(tài)錯亂。

這就要求系統(tǒng)始終知道：

• 當前目標是什么
• 已完成到哪一步
• 下一步該做什么
• 哪些結論已經(jīng)確認
• 哪些結果只是臨時推斷

OpenAI 在關于 context personalization 的 Cookbook 中強調(diào)，現(xiàn)代 AI agent 正在從“響應型助手”變成“會記住你的協(xié)作者”，而實現(xiàn)這一點的關鍵，就是通過結構化 state 對象、hooks 和上下文注入邏輯來管理跨輪狀態(tài)和長期記憶。

這句話其實很重要。
因為它說明，今天的 agent 架構已經(jīng)不再只是“消息列表 + 大模型”，而是在向下面這個方向演化：

LLM + 狀態(tài)機 + 記憶層 + 檢索層 + 工具層

這也是為什么很多優(yōu)秀的 coding agent、data agent 用起來會讓人感覺“它不像在聊天，而像在干活”。

它不是因為突然“更聰明”了，
而是因為它始終知道自己處在任務鏈的哪個位置。

5、記憶：未來真正拉開差距的是“連續(xù)協(xié)作”

短上下文解決的是當下，長期記憶解決的是持續(xù)協(xié)作。

OpenAI 關于 context personalization 的文檔明確把“shaping what the model knows at any given moment” 作為 context engineering 的核心，并強調(diào)通過長期記憶注入，agent 可以記住偏好、過往行動和個性化信息，變得更一致、更有延續(xù)性。

OpenAI 2026 年披露的內(nèi)部數(shù)據(jù) agent 也把“memory”列為多層上下文的一部分，并介紹其數(shù)據(jù)代理會結合表使用歷史、人工注釋、Codex enrichment、institutional knowledge、memory 和 runtime context 共同工作。

這說明一個趨勢已經(jīng)很清楚：

未來好用的 AI，不只是“會回答”，而是“會延續(xù)”。

比如它知道：

• 你長期偏愛哪種輸出風格
• 你正在做哪個項目
• 你已經(jīng)否決過哪些方案
• 你更習慣哪類技術棧
• 某個任務推進到第幾階段

這不是簡單的“聊天記憶”，
而是在做一種持續(xù)協(xié)作型上下文系統(tǒng)。

四、真正厲害的 Agent，拼的不是工具數(shù)量，而是上下文質(zhì)量

現(xiàn)在很多人做 agent，容易掉進一個誤區(qū)：
以為接更多工具、支持更多 MCP server、能搜更多數(shù)據(jù)，就一定更強。

其實不一定。

Anthropic 在 “Building Effective AI Agents” 中提到，augmented LLM 的關鍵并不只是擁有 retrieval、tools、memory，而是要把這些能力針對具體場景做適配，并提供清晰、易于模型使用的接口。文中還提到 MCP 是一種整合第三方工具生態(tài)的方式，但接口質(zhì)量仍然是關鍵。

這句話翻譯成大白話就是：

工具再多，如果進模型的上下文是亂的，Agent 一樣會翻車。

所以真正成熟的 agent 系統(tǒng)，不是“給模型一堆按鈕”，而是：

• 先決定何時該調(diào)用什么
• 再決定調(diào)用結果怎么壓縮
• 然后決定哪些結果應留下，哪些該丟棄
• 最后再決定下一輪推理該基于什么上下文繼續(xù)

也就是說，工具只是能力接口，Context 才是能力調(diào)度系統(tǒng)。

五、為什么 Context Engineering 會比 Prompt Engineering 更值錢？

因為 Prompt 更像技巧，
而 Context Engineering 更像基礎設施。

Prompt 容易被復制。
一句提示詞，別人看完就能照抄。

但 Context Engineering 涉及的是整條鏈路：

• 信息接入
• 檢索與召回
• 歷史修剪
• 運行時加載
• 狀態(tài)存儲
• 長短期記憶
• 工具結果整形
• 權限和邊界控制
• 成本、延遲與可觀測性平衡

這不是“會不會寫幾句 prompt”的問題，
而是“能不能把模型放進一個足夠清晰、穩(wěn)定、真實、可推理的環(huán)境里”。

我甚至覺得，未來幾年真正拉開 AI 工程師差距的，不一定是誰更會調(diào)模型，而是誰更會做這件事：

為模型構造一個低噪聲、高相關、可持續(xù)的工作世界。

你不用一上來就追求復雜架構，
但至少要建立這幾個意識：

第一，別把聊天記錄無限堆下去。
要學會摘要、修剪和狀態(tài)提取。

第二，別迷信“全量上下文”。
很多時候按需加載比一次性全塞更穩(wěn)定。

第三，做 RAG 時別只關注召回率。
更要關心片段有沒有語境、排序是否合理、是否和任務綁定。

第四，做 Agent 時一定要顯式記錄任務狀態(tài)。
不要把“它應該記得”當成默認前提。

2、對企業(yè)團隊

Context Engineering 的價值更大。

因為企業(yè)環(huán)境的問題從來不是“模型不會回答”，而是：

• 文檔多而雜
• 數(shù)據(jù)權限復雜
• 業(yè)務概念不統(tǒng)一
• 歷史知識沉淀分散
• 多系統(tǒng)接口返回風格不一致
• 員工希望結果可靠、可追蹤、可復用

OpenAI 在介紹內(nèi)部數(shù)據(jù) agent 時就明確指出，他們之所以做這個系統(tǒng)，是因為內(nèi)部有 600PB 級數(shù)據(jù)和 7 萬個數(shù)據(jù)集，在這種規(guī)模下，“找到正確表”本身就是難題。為避免 many-to-many join、過濾錯誤、null 處理等分析失真，他們圍繞多層 context 來構建 agent。

這給企業(yè)一個很現(xiàn)實的啟示：

未來企業(yè) AI 項目的競爭，不只是模型選型，而是上下文基礎設施建設。

如果說：

• 2023 年是“大模型能力展示年”
• 2024 年是“Prompt 工程和 RAG 普及年”
• 那么 2025～2026 年，越來越像是“Agent 工程化與 Context Engineering 抬頭之年”

這不是一句口號，而是能從官方工程文章中看到越來越清楚的路線：
Anthropic 在講 just-in-time context、Contextual Retrieval、augmented LLM；OpenAI 在講 session memory、state management、long-term memory、內(nèi)部 data agent 的多層 context 設計。

所以我更愿意把它總結成一句話：

Prompt 是讓模型開口，Context Engineering 是讓模型真正進入工作狀態(tài)。

未來的 AI 工程，除了會寫提示詞，還需要掌握如何組織知識、管理記憶、裁剪歷史、編排工具、維護狀態(tài)，給模型提供一個干凈、準確、連續(xù)的現(xiàn)實世界（想想是不是牛馬感又來了）。

但這，才是 Context Engineering 真正值錢的地方。

歡迎大家+關注、多多討論。