在大模型能力日益強大的今天，AI“會不會寫代碼”已不再是問題，真正決定其能否成為開發者得力助手的關鍵，在于它“能不能理解上下文”。

技術術語的更迭，不僅是語言表達的更替，更代表著思維范式的轉變。上下文工程這一新術語，之所以能引起業內共鳴，折射的是智能體復雜性的演化和應對策略的轉變，是對現實中算法和工程挑戰的一種集體回應，尤其是在垂直/領域的智能體。

現有的大模型已經非常智能。但即便是最聰明的人，如果不清楚自己要做的事情的上下文，也很難給出令人滿意的交付。兩款產品可能在做完全相同的事情，一款給人感覺充滿魔力，但另一款卻像個廉價的演示品。差別在哪里？就在于上下文工程的構建上。

一、從一個場景開始，感受上下文工程的魔力

場景設定：你是某款智能體的產品經理，正在釘釘上收到研發發來的私信：“有個問題想確認一下，新版的導入功能是不是只支持 CSV？我們這邊需要開始寫接口了。”

一個普通的智能助手可能會直接幫你草擬一句回復：“是的，目前只支持 CSV，后續可能會擴展。”表面上看沒錯，但沒有考慮到項目當前階段、上下游依賴、語氣風格、團隊共識等細節，容易引起誤解或返工。

而一個具備“上下文感知”的智能體，會先主動檢索：

項目狀態：按照項目規劃，導入功能這周進入開發階段。

需求文檔：設計稿明確列出 V1 支持 CSV 和 JSON，但后者會延后一周上線。

團隊氛圍：研發那邊人手吃緊，擔心 scope 變化影響進度。

任務歷史：曾有一次因需求細節未澄清導致返工，剛復盤過。

個性化語氣設定：直接、細節清楚、減少異步往返。

最終生成的消息可能是：“目前計劃 V1 支持 CSV 和 JSON，但 JSON 要到下周才能接接口。你這邊這兩天先按 CSV 做沒問題，接口格式我一會兒就在需求列表上進行補充。”

魔力在哪？

它不是因為模型算法更好，而是因為它理解了：

當前的任務規劃

團隊過往的溝通隱患

對方的工作狀態與擔憂

文檔/知識庫的實時狀態

這正是“上下文工程”的魔力所在，用足夠有結構的信息輸入，換來更自然、更可控、更滿意的輸出行為。這種上下文工程的設計才會讓智能體更像一個人去思考任務。

二、提示詞->提示詞工程->上下文工程的演進

提示詞，是擅于利用大模型的用戶手上的魔力筆。

通過具象的提示詞可以獲得盡可能滿意的輸出。我們在教大模型理解我們的同時，也在學習如何被理解。每個提示詞都是一面鏡子，映照出我們對“理解”本身的理解。比如提示詞大師李繼剛提供過大量、高質量的提示詞。來看個例子：

這種用結構化的提示詞挖掘大模型能力的體驗，早期造就了大量圍繞提示詞調優的 Prompt Hacker 群體，也使得寫提示詞在一段時間里，成為優化大模型輸出的核心技巧。然而，這種做法的核心問題也很快暴露出來：過度依賴個體經驗，缺乏系統性、穩定性和可復用性，同一個提示詞在不同模型或不同時間段下的表現千差萬別，一套提示詞很難橫跨多個任務、多個上下文等等。

由此延伸出了提示詞工程，Agent Builder 們試圖將對大模型的調試經驗固化為規則，將試錯過程轉化為一套可維護、可迭代的編排流程，打造相比通用大模型在某個場景下更具競爭力的行業智能體。例如，在實際項目中，你會看到團隊構建了一組系統提示詞模板，輸入變量、角色說明、指令目標都被結構化封裝。在電商文案生成、法律文書生成、客服問答等典型場景中，提示詞工程的方式確實顯著提高了輸出的一致性與產品化效率。來看個例子。

下方是通義千問提供的諸多領域的垂直/領域智能體，已經把提示詞內化成智能體的系統能力。用戶不再需要輸入“你是一個善于起爆炸標題黨的作者”之類的提示詞，降低了用戶獲得定向輸出效果的使用門檻。

但是，隨著用戶的需求進一步升級，比如多輪對話、多角色協作、深度研究、用戶狀態追蹤等復雜任務的不斷涌現，模型應用從短指令走向長流程、從靜態調用走向動態交互之后，大家會發現：真正影響輸出質量的，是整個輸入結構的系統設計能力，而不止是用戶或系統提示詞本身。于是，上下文工程應運而生。它不只是對提示詞工程的簡單補充，而是關注整個上下文的組織方式、信息來源、結構設計和動態調度。這預示著圍繞“如何獲取更好輸出”這一核心目標的方法論，正在發生根本性的變化。

例如在文章開頭，我們舉的產品經理和工程師之間的那一段對話，一個高質量智能體，不再只是讓大模型回答用戶的問題，而是通過上下文工程，幫助大模型在回答前獲得更加結構化的輸入，包括項目狀態、需求文檔、任務歷史、甚至團隊氛圍，實現大模型更好的理解當前的任務規劃、團隊過往的溝通隱患、對方的工作狀態與擔憂、文檔/知識庫的實時狀態等等。上下文工程就成了一個結構化信息池，一個模型輸出前的思維工作臺。我們想想，兩個人執行同一個任務時，除了各自的專業知識和技能儲備以外，比得不就是各自對任務上下文的理解能力嗎？

我們正在進入一個更具結構化的時代。

三、上下文工程不等同于上下文

構建上下文聽起來像是把信息填進 prompt 這么簡單的事情，為什么還需要專門搞一套工程？（注意，這里的工程還包括了模型的 RL，本文第五章的常見策略會提到具體案例。）其實任何有過多輪交互、系統協作、信息調度經驗的人都知道：信息失敗除了是因為缺失，還會是因為亂、沖突、不連貫。

我們曾經通過 RAG、Function Calling、MCP 等外部信息接口，讓大模型變得更加聰明。但事實證明，工具太多也是有后果的，更多的補充信息、更長的上下文并不一定會產生更好的響應。上下文過載可能會導致智能體以意想不到的方式失敗。上下文可能會變得有害、分散注意力、令人困惑或產生沖突。這對于依賴上下文來收集信息、綜合發現并協調行動的智能體來說尤其成問題。這也一定程度上抑制了 RAG、Function Calling、MCP 的熱情。例如當你設計的智能體對接幾十個 MCP 時，對 Tool 信息的管理就會成為新的工程課題（Nacos Router 和 Higress AI 網關的 Toolset 是解決這一工程課題的不同技術手段）。

Drew Breunig對常見上下文失敗歸類為以下4種，這對我們進一步理解“上下文工程不等同于上下文”，很有幫助。

上下文中毒

過往訓練和評估大模型時，研究者長期聚焦于單輪、任務全量給定的情況。但現實使用中，用戶往往采用多輪對話逐步補充、不完全描述需求的交互方式，這會引發錯誤信息出現的概率。當錯誤的信息，比如用戶誤輸、工具輸出異常等被寫入上下文時，模型會將其當成事實反復引用，并執著于實現不可能或無關的目標，甚至后續每一步決策都在錯誤基礎上前行，越走越偏。

就像互聯網提升了我們獲取信息的效率和信息面積，但也更容易被虛假信息誤導。當我們誤把一個虛假信息當真，講給更多人聽，結果就形成了自己的潛意識，還會在后續其他的討論和推理中引用該虛假信息。

情境干擾

指的是上下文過長或冗余信息過多，導致模型注意力資源被稀釋，過度關注上下文，忽略了原本通過訓練獲得的內容，輸出質量下降。雖然現在的大模型都已經支持百萬級別的 token 上下文輸入，但是 Gemini 2.5 的一份技術報告中指出，隨著上下文超過 10 萬個 token，大模型傾向于多步驟生成推理的長上下文，而非用于檢索的長上下文。對此我們都有真實的體驗，例如考前復習，突然布置了一大包模擬題，太雜太多，混淆了原本積累的知識和理解，反而考砸了。

根據 Databrick 的一項報告，大多數模型的性能在達到一定上下文規模后就會下降。Llama-3.1-405b 的性能在 32k 個 token 后開始下降，GPT-4-0125-preview 的性能在 64k 個 token 后開始下降，并且只有少數模型能夠在所有數據集上保持一致的長上下文 RAG 性能。

語境混淆

是指模型使用上下文中多余的內容來生成低質量的響應。例如 Agent 配置了16個 MCP，當用戶發起請求，即便該請求只和其中2個 MCP 有關，大模型也會把16個 MCP 全部檢索一遍，導致模型有可能將這些無關片段也納入推理，生成了偏題或低質量的響應。

下方截圖是伯克利今年6月發布的函數調用排行榜，是對外部工具調用的基準，用于評估模型使用工具進行響應的能力。該排行榜顯示大模型在引入函數調用或使用工具的時候，幾乎所有大語言模型的性能都會比原始文本生成任務中有所下降，在多函數調用場景中，準確率顯著低于單函數調用。

語境沖突

指的是當上下文中積累的新信息和外部工具或訓練知識庫中的信息相沖突，導致模型輸出不穩定。這在我們生活中也常遇見，例如網約車司機安裝了兩臺導航軟件，同一個目的地若在兩個導航軟件中出現不同的導航路線，司機就會犯難，然后隨機選擇一個。

總的來看，上下文既是提升輸出的魔力筆，又會因為信息太多帶來上下文中毒、情景干擾、語境混淆、語境沖突的挑戰，因此通過上下文工程的構建來保障上下文的交付質量，是構建高質量智能體的關鍵。

上下文工程包括上下文從哪來？保留哪些？丟棄哪些？是否要壓縮？如何壓縮？是否需要隔離？誰來寫？誰來拼接？所有這些問題構成了上下文工程的工作邊界。

四、構建上下文工程，從編排設計開始

目前業內還未出現構建比通用大模型更加智能的 Agent 的標準方法論。但從業內領先實踐者的分享中，我們或許能得到一些啟發，至少能了解到如何開始。例如近期 Cognition 發布的一篇技術博客，就是不錯的參考。文中列舉了 Agent 處理復雜長任務時的4種編排流程，并對輸出可靠性進行了比對。

1. 并行執行，無上下文共享

主任務拆分為多個子任務，分別由不同的 SubAgent 獨立執行，彼此之間沒有共享上下文信息，也沒有交互。優勢是實現簡單、便于并行計算、token 消耗更經濟，充分利用不同 Agent 的專業能力。但是任何子任務一旦失敗，整合階段將難以進行，且沒有補救機制。像拼圖游戲，每塊都找不同人拼，但沒人知道最終圖長啥樣，最后發現拼不上。

2. 并行執行，有上下文共享

子任務執行前都能訪問一個共享上下文，但執行仍是獨立完成，子任務間沒有交互。優勢是比方式一更可靠，任務理解更統一。但仍可能遇到輸出沖突、不協調的情況。就像菜品采購、切配工、廚師協同做一道菜，大家看了同一份菜單，固然各自有崗位分工，但是三者間沒有交流，按照自己的理解去執行，做出來的菜品就不如嫻熟搭配的后廚團隊。

3. 串行執行，逐步構建上下文

任務由多個 SubAgent 串行完成，前一個 Agent 的輸出成為后一個 Agent 的輸入，構建一種“任務接力”模式。優勢是子任務之間能被相互看到，任務理解更統一。但是任務過長時，串行產生的上下文會迅速膨脹，最終可能超過模型上下文窗口的容量限制，導致上下文溢出。工程中，如果我們設計的流水線很長，最終導致緩存溢出的可能性就會變大，其實是同樣的原理。

4. 串行執行，引入壓縮模型

在原有流程中加入一個專門的“上下文壓縮模型”，用于將過往的對話、行動歷史壓縮為少量關鍵細節與事件，供下一個模型繼續使用，保持決策連貫。優勢是突破上下文窗口限制，實現更長任務的處理；提高 Agent 的長期記憶能力。但這很難做好，需要投入精力去弄清楚哪些是關鍵信息，并創建一個擅長此的系統，一旦壓縮模型壓縮質量不高，壓縮過程中就會因為丟失細節，影響輸出穩定性。從事技術服務的，既要懂產品和技術，還要深入客戶的業務理解場景，不然很難給出令人滿意的交付。

五、上下文工程的一些常見策略

在 Cognition 提出的4類 Agent 編排流程中，所有失敗的根源都可以追溯到“上下文策略的不合理”：共享不足、信息斷裂、冗余失控。這就構成了上下文工程在處理復雜長任務時的真實使命，幫系統“看得更加清晰”。

1. 智能檢索

大模型的輸出會因為過多的外部工具，降低輸出性能。例如由 MCP 定義的工具。這篇論文中，團隊在對 DeepSeek-v3 進行提示時，發現當工具數量超過 30 種，工具描述開始重疊，極易造成混淆。超過100 種工具后，該模型幾乎肯定會失敗。因此通過智能檢索，選擇正確的工具至關重要使用。

該團隊引入了 RAG-MCP，通過一個檢索增強生成框架，減輕工具發現的負擔。RAG-MCP 使用語義檢索，在調用 LLM 之前從外部索引中識別與給定查詢最相關的 MCP。只有選定的工具描述才會傳遞給模型，從而大幅減少提示大小并簡化決策。論文中的實驗表明，RAG-MCP 顯著減少了提示標記（例如，減少了 50% 以上），并在基準任務上將工具選擇準確率提高了兩倍以上（43.13% 對比基準的 13.62%）。RAG-MCP 為 LLM 實現了可擴展且準確的工具集成。

Nacos 近期發布 MCP Router 就是 RAG-MCP 的開源實踐。Nacos MCP Router 會根據任務描述和關鍵詞檢索出合適的 MCP 服務器后，再由大模型進行調用。

2. 上下文隔離

上下文隔離是將不同任務/子目標拆成獨立線程或 Agent，讓它們在各自的“泳道”里運行，任務分解成更小、更獨立的工作，每個工作單元都有各自的上下文，防止上下文共享導致的信息干擾或語義沖突。

工程上的技術手段是相通的。

做過微服務的同學一定對“泳道”一詞不陌生。想象你有一個多租戶的微服務平臺，每個租戶都能訪問訂單服務。如果沒有泳道機制，某個大客戶突然請求暴漲，可能拖垮整個系統；而有了泳道，每個客戶有獨立資源，不互相干擾。同理，在大模型應用中，如果多個用戶/任務共享一份上下文空間，模型可能混淆角色指令、任務狀態，導致幻覺頻發。用隔離結構就能較好地解決這種問題。不同的是，微服務治理中的“泳道”是用來控制訪問流量，大模型應用中的“泳道”是用來控制語義信息流。

Nacos 近期發布的 MCP Router 就是 RAG-MCP 的開源實踐。Nacos MCP Router 基于 RL，會根據任務描述和關鍵詞檢索出合適的 MCP 服務器后，再由大模型進行調用。

3. 上下文修剪

上下文修剪是指剔除無關、過時或冗余的上下文片段，降低上下文混淆的風險。因為隨著對話或任務的持續推進，原始上下文越積越多。但是模型的上下文窗口是有限的，堆疊會帶來兩個問題：模型注意力稀釋和 token 成本失控。

這和我們維護我們手機上內存很像，一開始所有應用和歷史信息都保留，但當手機出現運行緩慢的時候，就會開始清理手機內存，例如把下載到本地的大文件刪除，刪除微信聊天中的不重要的歷史信息。不同的是，在大模型應用中，上下文的修剪并非執行單一指令這么簡單，還需要基于重要性得分刪減對話歷史、基于意圖匹配清理無關檢索結果，甚至使用小模型做冗余句子識別。這些策略的質量將決定上下文的修剪質量。

這篇論文提到的 Provence 方法，使用了用于上下文剪枝的大模型和預訓練的重排序器（用于重排序分數）創建合成訓練目標，并基于合成數據調整預訓練的重排序器，以便最終的統一模型能夠高效地執行上下文剪枝和重排序。Provence 從上下文的段落中刪除了和用戶問題不相關的句子，減少上下文噪聲，加快大模型內容生成，并且對于任何大模型或檢索器來說，都能以即插即用的方式實現。

4. 上下文壓縮&總結

不同于上下文的修剪，壓縮是更進一步的工程策略。當我們對上下文修剪完后，再對剩下的上下文進行壓縮，把長文本壓縮成語義密度更高的表達，進一步釋放上下文空間，讓模型能聚焦真正關鍵的信息。

業內主流的壓縮方式有：

提取式壓縮：直接從原始上下文中篩選出關鍵句子或段落，將它們拼接成新 prompt，不進行改寫。實驗室效果可實現高達 10× 的壓縮比，同時幾乎不損失模型準確性，在多類任務（單文檔、多文檔 QA、摘要）中表現比較好。優劣勢包括保留原文措辭、信息可靠、輸出質量高；操作低改動、執行路徑簡單。不足之處是壓縮比受限于原段落長度，需要有效的關鍵內容識別機制。

抽象式壓縮：通過生成模型（比如摘要模型）將上下文概括成新文本，替代原內容，不保留原句。在高壓縮比條件下，性能比提取式略差（尤其是長期任務），多文檔 QA 場景中，若使用“query-aware summary”，即依據問題生成摘要，可提升性能達 10 個百分點。方案優勢是壓縮比高，能實現更短 prompt，但容易出現信息遺漏或歪曲，且依賴摘要模型質量。

令牌修剪：逐 token 剔除冗余或低價值內容，只保留關鍵 token，不重排句子結構。對于摘要任務，僅展現出邊緣性能提升，總體落后于提取式壓縮。實現簡單，無需生成額外文本，但是穩定性較差，對于需要語義完整性的任務支持不足，且難以識別復雜語義依賴。

這四種策略并非孤立存在，而是從入口（檢索）到單元化（隔離）、到清理（修剪）、再到提煉（壓縮），組成了一整套上下文的工程能力，是構建大模型應用的基礎。理解并創造性的應用這些策略，像打造產品一樣，去構建這些上下文工程，將成為 Agent Builder 們的核心競爭力。