Prompts 確立意圖。Context 選擇事實、歷史和工具輸出，讓 AI 在長任務中保持連貫。

在這個領域的第一幕里，我們沉迷于字詞斟酌。微調一個動詞，挪一條約束，看看模型會不會聽話。它常常奏效，足以讓人以為這是一門手藝。直到問題變得更長、更亂、更多步驟，一條安靜的真相浮出水面。措辭重要，但模型看到什么更重要。

Prompt engineering 關注“如何把話問好”。Context engineering 關注此刻該把哪些信息擺上臺面。這包括指令、檢索到的事實、工具輸出、計劃，以及仍然會影響下一步的那部分歷史。工作重心從討巧變為策展，從機靈話術轉向精挑細選的輸入。

別把它當精靈，更像是舞臺監督。你的職責是決定誰上場，說哪句臺詞，什么時候退場。

為什么這很關鍵？因為模型有注意力預算。每多一個 token，就多一分競爭：注意力、成本、延遲。把窗口灌滿，質量下滑；把它餓著，模型就會憑空編造來補缺。手藝就活在中間：相關、及時、最小。

想象一個在做研究任務的 agent。它瀏覽、做筆記、調用工具，持續一小時。如果每輪都重播全部歷史，你要為速度和連貫性付費；壓縮得太早，又會丟掉真正需要的細節。系統的表現取決于你喂它的 context，而不是你囤下的 context。

Context engineering 是一門選擇、塑形、編排模型下一步應當關注內容的學科。

這不是在否定 prompts，而是更大的框架。好的 prompts 仍然錨定意圖與語氣，但它們坐落在一個活的 context 里，必須在工作展開時被修剪、總結、刷新。每個強系統背后的問題都變得既簡單又苛刻：為什么是這些信息、在這一步、以這個代價、為了這個結果。

Context vs. Prompt Engineering

有什么區別？

Prompt engineering 調教的是指令。你打磨措辭、約束、語氣，讓模型理解意圖。它是“局部的”、迭代迅速，適合短小且獨立的任務。

Context engineering 塑造的是信息集合。你決定哪些事實、歷史、計劃、工具輸出應該進入窗口，且是針對這一步。它是“系統性的”，難以作假，當工作跨越多輪與多工具時回報更大。

指令再利落，輸入錯了也會失敗；反之亦然。提示很亂，但當有對的文檔、數字和狀態在場，它也能跑通。區別不在“文案” versus “數據”，而在句子 versus 供應鏈。

按職責思考：Prompt engineering 錨定聲音、目標、護欄；Context engineering 策展來源、壓縮歷史、編排工具結果。一個在約束語言，另一個在約束流程。

權衡隨之而來。更重的 context 增加成本、延遲，也擴大出錯面；更輕的 context 則冒著遺漏、重復、脆弱的風險。按任務校準：短問答偏向 prompt 手藝，長流程 agent 偏向 context 控制。

Prompt focuses the ask. Context builds the brief that makes the ask land.

為什么把 prompt 歸入 context 的子集？因為指令會在你組裝的窗口里“同行”。窗口若嘈雜或單薄，再完美的措辭也救不了；窗口若相關且精簡，普通的措辭往往就夠了。

實踐中的判據很簡單：如果你的改進計劃改變了句子，你在做 prompt 工作；如果它改變了模型讀什么，你在做 context 工作。最好的系統兩者兼顧，且按這個順序來。

為何隨著 AI 成熟，Context 更重要

短任務會原諒糟糕的輸入，長任務不會。一旦 agent 開始瀏覽、調工具、擬計劃、反復改稿，prompt 不再是瓶頸。真正移動的靶子是“狀態”：模型該記什么、忘什么、重讀什么。

模型在這點上很像我們。工作記憶稀缺，長記憶嘈雜。把一切塞進窗口，注意力渙散；剔得太狠，又丟掉主線。手藝不在于“量”，而在“壓力下的取舍”。

用預算思維。每個 token 都在購買注意力、延遲、金錢。花到能復利的地方。

多輪工作會留下軌跡。工具輸出、部分計算、用戶糾正、細小決策的積累速度超出預期。逐輪逐字重播這條軌跡，系統會變慢，答案質量會漂移；不加思索地做總結，又可能壓掉恰恰支撐下一步的那個關鍵數據。

這些失敗模式與真實團隊的通病如出一轍：舊錯誤殘留，污染后續步驟；過時事實與新鮮事實并列，模型把它們混在一起；無關歷史干擾下一次選擇。另一邊，修剪過猛會造成既視感：agent 反復學它本來就知道的事。

有用的 context 位于相關性、時效性、可靠性的交集之外的，都是負擔。更大的窗口有幫助，但也容易養懶：人們不再策展，因為系統“吃得下”。賬單爬升、延遲拉長、質量仍然下降。

設計問題轉向務實：跨輪次要 cache 什么？要重算什么？現在總結什么、以后再總結什么？這些是“策略選擇”，不是事后想起，它們決定你的 agent 是保持在場還是走神。

A long task needs a loop that retrieves, filters, and writes back state, not a one-shot prompt.

Context Engineering 的構件

Context 不靠一個絕招，而是一套小而嚴的紀律，彼此配合。Retrieval 拉來候選，Processing 提煉，Memory 管時間維，Orchestration 讓整條環路保持清醒。把這些做好，模型讀到的是 brief，而不是逐字稿。

Bring in candidates, pick the few that matter, compress, then assemble the window with memory.

1.Context Retrieval 與 Generation

從“可能有用的候選”開始，而不是迷信模型“本來就知道”。從文檔、代碼、日志、工單或 vector store 拉取——帶著預算做。Retrieval 是工具，不是拐杖。

Generation 也屬于這里。計劃、假設、工作筆記不會憑空出現。讓模型起草一個短計劃，然后把這個計劃當作下一步的輸入。scratchpads 讓思考可見、可驗證。

對“新鮮度”要挑剔。過期一周的 FAQ 若與新政策矛盾，比沒有更糟。來源不可信，就別檢索。你能維護的最簡單檢索策略，勝過你維護不動的花哨策略。

2.Context Processing、Summarization 與 Compression

原始輸入很少值得坐頭排。為長段落做總結，去掉套話，對敏感字段做脫敏。保留能錨定決策的數字與名字；丟掉只增添情緒、沒有信息量的形容詞。

Compression 往往是團隊容易抄近道的地方。克制“全都塞上去以求保險”的沖動。每多一個 token 就是延遲與成本。如果確實需要更長的記錄，把它寫進 memory，按需再取關鍵片段。

順序很重要。先給清晰的指令，再放高信號事實，然后是更短的歷史。別把請求埋在 context 堆里指望模型自己挖出來。

3.Context Management 與 Memory

短期 context 是窗口，長期 memory 是存儲，要分開用。窗口留給會改變下一步的東西；存儲留給你希望跨輪次保留的事實與決策。

寫得比你以為的更少。存用戶偏好、已解析的 ID、重新發現代價高的決策、和緊湊的過去工作摘要。回避八卦與瑣碎。按任務與語義雙重索引，方便后續選擇性檢索。

隱私是設計，不是復選框。寫入時脫敏、靜態加密，明確可被召回的范圍。沒有什么比模型突然翻出用戶沒想到會再出現的舊細節更傷信任。

4.Context Integration 與 Orchestration

真實系統要用工具。工具輸出也是 context，所以同樣需要紀律。別整頁地粘貼搜索結果或日志。提取相關行，并保留源鏈接以便審計。

子任務應有獨立的 contexts。Researcher agent 可廣泛閱讀，然后給 Writer agent 一份兩段式 brief。Coder agent 需要的是函數簽名與失敗的測試，而不是整倉庫。分離能降噪，讓錯誤局部化。

Orchestration 是寫進代碼的策略。決定何時檢索、何時總結、何時寫入 memory、何時丟棄。為 pipeline 做 instrumentation，在生產環境觀察 token 計數與延遲。目標是穩定的環路，而不是炫技的 demo。

Orchestration 的檢驗很簡單：拿掉某一步，質量可測地下降，那它就值得保留；否則就刪。

穩定環路的共性

• 先把目標與 token 預算說清的團隊，選擇會更干凈。這聽起來形式化，但當延遲與成本開始漂移時，它會省大事。
• Retrieval 更像“假設”而非“真相源”。在操作性任務上，新鮮度勝過廣度；在開放式研究上，廣度有益。不要猜，值得測試。
• Summaries 只有在保住數字、名字、決策時才有用。這些一丟，錯誤率上升，哪怕 prompts 看起來更干凈。掩蓋關鍵數字的整潔總結，是個 bug。
• 順序比大多數人以為的更重要。耐用的系統常把指令放前、硬事實其次、歷史只留薄薄一層：清楚的請求，其次是證據，再有恰到好處的過去以自洽。
• 把耐久事實寫入 memory，且控制范圍。一個越長卻從不提升結果的存儲，只是新雜物。決定留棄時，instrumentation 勝過直覺。

從打磨 Prompts 到工程化 Context

一種新范式

Prompt 小技巧給了我們開門紅，它們仍然重要。但如今的工作更像“系統設計”而不是“文字游戲”。我們在選擇來源、決定什么要持久化、把工具輸出當作信號進行路由。

心智轉變說起來簡單、做起來難。與其問“怎么表述”，不如問“模型必須讀什么，按什么順序，為什么是現在”。這個問題引出的是“策略”，不是一次性的招數；也引出“度量”。

團隊習慣也會隨之改變。Writers 與 PMs 共同定義目標與語氣；工程師接好 retrieval、memory 與過濾；數據同學看 drift 與成本。只有這些角色坐在同一張桌子上，對“什么是好”達成一致，環路才能運轉。

失敗模式也變了。過去 prompt 不好，答案就不好，你改句子就行。現在 context 不好，答案看起來像樣卻走偏。錯誤藏在缺失的事實、陳舊的片段、或未經修剪就粘貼的工具結果里。

你不需要宣言來實踐它。先把某類任務每一輪都應該“存活”的少量事實點名道姓。決定它們住在哪里、何時回來。設個硬性的 token 預算并遵守。其他都是打磨。

關于語氣與文化的最后一筆：Context 工作在“輕意見、重證據”的團隊里更茁壯。某一步不改變結果，就刪；更小的窗口表現更好，就保持更小。以“最小化”為傲，勝過以“復雜度”為傲。

結論

The Future is Engineered Context

Prompts 開啟對話；Context 讓對話誠實。耐久的系統把信息當可塑的材料，而不是用來膜拜的垃圾場。它們選擇誰該在場、誰該候場、誰永不入場。

收益是現實可感的。更小的模型在干凈的 brief 下也能顯得更鋒利；評審更短，因為決策住在該住的地方；團隊少爭文案，多爭來源、順序與成本——這樣的爭論更健康。

責任同樣在這兒。Memory 是力量，力量需要邊界。寫你能辯護的，取你能驗證的，有意地遺忘。你守住的信任，是你交付的產品的一部分。

如果我們把 context 當成產品表層來對待，配上預算、測試與意圖，會發生什么變化？答案很少是“更多數據”，更常是“更好的時機、更清晰的次序、更少的意外”。

Prompts 是接口。Context 是讓這個接口可靠的環境。請慎選你的環境。

難的不是造更大的窗口；難的是決定該留什么在外，并在“再多粘一點更容易”時仍然守住這條線。這就是手藝，這就是工作的所在。

本文轉載自??PyTorch研習社??，作者：AI研究生