本文腦圖如下：

方法：AI Agent 的有效上下文工程

1?? 何為上下文工程 Context Engineering ？

2025 年 6 月以來(lái)，原名為「Prompt Engineering」的提示詞工程，在 AI Agent 概念日趨火熱的應(yīng)用潮中，

經(jīng)由 Anthropic、LangChain、Manus 等 AI 公司，以及 Andrej Karpathy（前 OpenAI 聯(lián)創(chuàng)）、Tobi Lutke（Shopify CEO）等行業(yè)領(lǐng)袖的傳播下，共識(shí)成了更適應(yīng) Agent 的新概念：

——「Context Engineering」，即上下文工程。

在國(guó)內(nèi)，也對(duì)應(yīng)出現(xiàn)了“Prompt 工程已死，未來(lái)屬于 context 工程”、“別再卷 prompt 了”等論調(diào)。

但，事實(shí)盡是如此？

雖然傳播一個(gè)新概念的“好”方法，就是拿它與出了名的舊事物對(duì)比、營(yíng)造沖突。

但 prompt 仍是 context 工程不可或缺的子集，context 工程則是為適應(yīng) AI Agent 架構(gòu)日趨復(fù)雜健全的自然發(fā)展。（Anthropic 團(tuán)隊(duì)在《Effective Context Engineering for AI Agents》一文中，也提到了一致觀(guān)點(diǎn)）

要簡(jiǎn)單區(qū)分兩者差異的話(huà)，可以如此理解：

• Prompt 工程，專(zhuān)注單輪 AI 交互的生成質(zhì)量，是為獲得最佳結(jié)果而編寫(xiě)和組織 LLM 指令的方法。
• Context 工程，更關(guān)心在多輪 LLM 推理過(guò)程（可通俗理解為 Agent 運(yùn)行過(guò)程）中，找到并維護(hù)動(dòng)態(tài)優(yōu)化整個(gè) LLM 所接觸的上下文信息配置
• （包括系統(tǒng)指令 system instructions、工具 tools、MCP 協(xié)議、外部數(shù)據(jù)、消息歷史 message history）的策略。
• 目標(biāo)是以盡可能少且必要的 tokens，最大化 LLM 生成結(jié)果，引導(dǎo)模型輸出我們期望的行為。

比如，Context 工程涉及的 system instruction 依舊是 prompt 工程實(shí)現(xiàn)的。并非全方位替代，只是需要根據(jù) AI 開(kāi)發(fā)情景，靈活選擇實(shí)現(xiàn)深度而已

Anthropic 《Effective Context Engineering for AI Agents》：context engineering 與 prompt engineering 的差異

2?? 有限的大模型上下文空間 → Context Rot

大模型的上下文窗口有限。

從 GPT3.5 的 16K ，到 Claude 3.5 的 200K，再到現(xiàn)在 Gemini 2.5 Pro 的動(dòng)輒 1M，近年來(lái) LLM 上下文窗口大小，確實(shí)提升飛快。

這是否意味著我們可以高枕無(wú)憂(yōu)，把一切 Context 都無(wú)腦地塞進(jìn)去？

答案是否定的——時(shí)至今日，上下文依舊需要被視為有遞減收益邊際的有限資源。

不知道你在和 AI 聊天時(shí)，是否發(fā)現(xiàn)這么一個(gè)現(xiàn)象？

當(dāng)對(duì)話(huà)長(zhǎng)度不斷增加（即使還沒(méi)超過(guò)官方標(biāo)稱(chēng)的上下文窗口尺度），模型的回復(fù)質(zhì)量也會(huì)有明顯的下降：

• 回答深度降低： 越來(lái)越難深入結(jié)合前文你提供的細(xì)節(jié)，提供創(chuàng)造性和細(xì)節(jié)度俱佳的回應(yīng)。通常你不得不重新發(fā)送關(guān)鍵 Prompt，再次強(qiáng)調(diào)可能有用的細(xì)節(jié)。
• 混亂歸因：在做歸納或分析時(shí)，胡亂地把你上文中提到的不相關(guān)細(xì)節(jié)關(guān)聯(lián)起來(lái)，得出一些南轅北轍的奇怪結(jié)論。
• 忘記前序指令： 忘記了對(duì)話(huà)早期你對(duì)它的回答要求（比如不要濫用比喻句式），但隨著你自己使用了類(lèi)似比喻的文風(fēng)后，又開(kāi)始犯軸。

——1M 上下文的 Gemini 2.5 Pro，基本在 tokens 量來(lái)到 4w 左右時(shí)，會(huì)反映為推理緩慢，質(zhì)量開(kāi)始有所下降。

是的，最大上下文窗口 ≠ 最佳注意力窗口。

有個(gè)專(zhuān)門(mén)術(shù)語(yǔ)來(lái)描述這個(gè)普遍的負(fù)面模型現(xiàn)象：Context Rot，上下文腐爛。

如同人類(lèi)在信息過(guò)載時(shí)會(huì)思維混亂，而過(guò)長(zhǎng)的、充滿(mǎn)干擾的上下文，同樣會(huì)顯著降低模型的推理能力。

而模型性能下降（上下文腐爛，context rot）的三大因素如下：

1. 1.Context 輸入越長(zhǎng) → 注意力被稀釋。
2. 2.問(wèn)題與關(guān)鍵信息的語(yǔ)義相似度越低 → 模型越難匹配到答案。
3. 3.關(guān)鍵信息與周?chē)蓴_內(nèi)容的語(yǔ)義相似度越高 → 干擾增強(qiáng)，模型難以分辨。

這三個(gè)因素會(huì)相互放大，導(dǎo)致性能顯著下降。

PS：反過(guò)來(lái)，控制 Context 長(zhǎng)度、減少 Context 中的干擾項(xiàng)數(shù)量、提升問(wèn)題與 Context 中有效信息的相似度，就能夠提升 Agent 的處理效果

這三大因素來(lái)自于 Chroma 團(tuán)隊(duì)（打造了目前全球最主流的開(kāi)源向量數(shù)據(jù)庫(kù)之一）名為《Context Rot》的同名實(shí)驗(yàn)研究。

實(shí)驗(yàn)研究古法人工濃縮如下，個(gè)人覺(jué)得會(huì)對(duì)測(cè)試 AI 產(chǎn)品有一些實(shí)用啟發(fā)。（比如測(cè)試較佳 context 長(zhǎng)度）

如果覺(jué)得太長(zhǎng)，也可以下滑到本段小結(jié)～

? Chroma：探究上下文對(duì)模型性能影響的關(guān)鍵要素

他們?cè)O(shè)計(jì)了一套實(shí)驗(yàn)，來(lái)測(cè)試影響 LLM 長(zhǎng)上下文性能表現(xiàn)的因素：

在傳統(tǒng) NIAH（Needle in a Haystack：即 LLM 大海撈針測(cè)試）基礎(chǔ)上，進(jìn)一步拓展任務(wù)難度，考察大模型的語(yǔ)義理解層面的撈針能力，而非直接詞匯匹配。

傳統(tǒng) NIAH 任務(wù)，是評(píng)估模型長(zhǎng)上下文能力最廣使用的基準(zhǔn)之一：

將一個(gè)隨機(jī)事實(shí)（針信息），放在較長(zhǎng)的上下文（干草堆）中，通過(guò)直接問(wèn)答，要求模型回答某個(gè)針的信息 ，比如：

干草堆：[大量無(wú)關(guān)文本]

藏在干草堆的針信息：“我從大學(xué)同學(xué)那里得到的最好的寫(xiě)作建議是每周都要寫(xiě)作。”

問(wèn)題 Prompt：“我從大學(xué)同學(xué)那里得到的最好的寫(xiě)作建議是什么？”

此時(shí)，模型被期望能從大量干草堆中，直接找到針信息，并回答“每周都寫(xiě)作”。全程無(wú)需間接推理信息，直接根據(jù)已有信息回答即可。

傳統(tǒng) NIAH 雖然很有效地考察了 LLM 的大海撈針能力，但實(shí)際問(wèn)答場(chǎng)景往往不會(huì)如此直接清晰：

• 一方面，需要 LLM 處理“針-問(wèn)題”之間的模糊語(yǔ)義：“我周末去了動(dòng)物園，并在那里喂了長(zhǎng)頸鹿?！?，那么問(wèn)題“動(dòng)物園里有什么動(dòng)物”
• 另一方面，真實(shí)的上下文中，往往充滿(mǎn)了容易誤解的干擾項(xiàng)。比如，“我從我大學(xué)教授那里得到的最好的寫(xiě)作建議是每天寫(xiě)作”，就會(huì)對(duì)上文“大學(xué)同學(xué)的寫(xiě)作建議”形成干擾（就如人類(lèi)讀一篇文章很快、很長(zhǎng)時(shí)，也容易記錯(cuò)細(xì)節(jié)）

  
  

Chroma 團(tuán)隊(duì)實(shí)際上，也注意到了這一點(diǎn)，并拓展了 4 種不同 NIAH 任務(wù)：

1. 1.“針-問(wèn)題對(duì)”相似度測(cè)試：構(gòu)造不同語(yǔ)義理解難度的問(wèn)題，測(cè)試不同 context 長(zhǎng)度對(duì)回答的影響
2. 2.干擾項(xiàng)測(cè)試：設(shè)置“不同的數(shù)量 + 不同的放置位置”的干擾項(xiàng)，測(cè)試不同 context 長(zhǎng)度對(duì)回答的影響

1. 3.“針-干草堆”相似度測(cè)試：當(dāng)針信息與上下文的向量語(yǔ)義逐漸接近時(shí)，測(cè)試不同 context 長(zhǎng)度對(duì)回答的影響
2. 4.上下文文本、段落結(jié)構(gòu)測(cè)試：測(cè)試相同內(nèi)容含義時(shí)，邏輯連貫的結(jié)構(gòu)與雜亂顛倒的結(jié)構(gòu)，是否對(duì)模型推理性能有所影響

看完整體測(cè)試過(guò)程，我也總結(jié)了一些有助于理解 context 工程價(jià)值的現(xiàn)象：

1. 1.無(wú)論如何，context 長(zhǎng)度增加時(shí)，模型完成同樣任務(wù)（即使很簡(jiǎn)單）的能力都會(huì)下降
2. 2.針與問(wèn)題之間的語(yǔ)義關(guān)系越難理解（相似度低），受 context 長(zhǎng)度影響越大；且這種下降在長(zhǎng)輸入時(shí)會(huì)被顯著放大。

   而 Context 長(zhǎng)度較短時(shí)，模型對(duì)低相似度的問(wèn)題，有更高的處理成功率

3. 3.context 越長(zhǎng)，干擾項(xiàng)對(duì)模型的影響也會(huì)加劇
4. 4.針與干草堆的內(nèi)容，在語(yǔ)義上越接近（主題越相關(guān)），模型識(shí)別針的能力越差。 如果針在語(yǔ)義上與周?chē)鷥?nèi)容格格不入（邏輯不連續(xù)、主題突兀），模型反而更容易識(shí)別。就像人玩找茬游戲，對(duì)突兀的信息更敏感。

   難：在 10 篇“寫(xiě)作建議”文章中找“最佳寫(xiě)作建議是每周寫(xiě)作”

   易：在“量子物理、烹飪、園藝”文章中找“最佳寫(xiě)作建議是每周寫(xiě)作”

小結(jié)：當(dāng) AI Agent 在多輪推理和更長(zhǎng)的時(shí)間線(xiàn)上運(yùn)行時(shí)，模型必然會(huì)面臨越來(lái)越多的 context rot 因素。

冗余的上下文將大量占用模型的思考空間，顯著降低其完成復(fù)雜任務(wù)的思考能力。

而上下文工程（Context Engineering）誕生的實(shí)質(zhì)，正是在探究哪種上下文配置，最有可能引導(dǎo)模型輸出我們期望的結(jié)果，獲取更好的任務(wù)效果。

3?? 有效開(kāi)展 Context 工程的方法

AI Agent 發(fā)展至今，已經(jīng)越來(lái)越能夠在多輪推理和更長(zhǎng)的時(shí)間內(nèi)運(yùn)行。

這些不斷在“思考-行動(dòng)-觀(guān)察”中循環(huán)運(yùn)行的 Agent，會(huì)在運(yùn)行中不斷產(chǎn)生、積累更多對(duì)下一次循環(huán)有影響的上下文數(shù)據(jù)

（包括系統(tǒng)指令 system prompt, 工具調(diào)用 tools, MCP, 外部數(shù)據(jù), 對(duì)話(huà)歷史 message history 等）

為了避免模型性能的下降，這些數(shù)據(jù)必須被 context 工程動(dòng)態(tài)優(yōu)化：

唯有效的 context 才配占據(jù)有限的上下文窗口資源。

Anthropic《Effective Context Engineering for AI Agents》：圖解 Agent 開(kāi)發(fā)中，context engineering 的起效形式

想要實(shí)現(xiàn)有效的 context 工程，大體上分為三類(lèi)策略：

策略之一，從寫(xiě)好 System Prompt 開(kāi)始

我們依舊可以從更熟悉的模塊開(kāi)始學(xué)習(xí)——通過(guò) Prompt 工程，設(shè)計(jì)清晰、簡(jiǎn)單直接的系統(tǒng)提示。

有效的上下文，始于清晰的指令。

如果 Prompt 過(guò)于具體，使用大量示例、if-else 類(lèi)的要求，則會(huì)使得模型更加僵化，缺乏處理意外情況的能力；

而 Prompt 如果要求過(guò)于模糊，或缺少足夠的背景信息，則會(huì)無(wú)法對(duì)模型輸出進(jìn)行可控管理。

在 Agent 運(yùn)行過(guò)程中，每一輪推理所產(chǎn)生的部分 context（工具調(diào)用返回結(jié)果、Chat 回應(yīng)等） ，也需經(jīng)由 Prompt 引導(dǎo)其如何輸出和被精煉（Kimi 那類(lèi) Model as Agent 的路線(xiàn)不在此列），方可具備一定的可預(yù)測(cè)性與管理意義。

以下是一些經(jīng)過(guò)實(shí)踐檢驗(yàn)、能顯著提升模型表現(xiàn)的提示詞編寫(xiě)原則：

• 啟發(fā)式引導(dǎo)：系統(tǒng)提示 System Prompt 應(yīng)當(dāng)足夠靈活地為模型提供啟發(fā)式引導(dǎo)，使其既能具體地輸出所需的結(jié)果，又能泛化應(yīng)對(duì)各類(lèi)邊界情況。

  比如「利用 LLM，評(píng)估事情的重要性」：

  評(píng)估事情的重要性。比如，在 1 到 10 的刻度上，其中 1 是完全世俗的（例如，刷牙，整理床鋪）和 10 是極其深刻的（例如，大學(xué)錄取、結(jié)婚）

• 結(jié)構(gòu)化提示：AI 更容易讀懂未經(jīng)精排的提示詞了，但結(jié)構(gòu)化提示方法依然值得被適度應(yīng)用。

  使用 或#式的 XML 標(biāo)簽 / Markdown 語(yǔ)法，分割不同指導(dǎo)作用的提示詞。
  雖然隨著模型能力提升，LLM 對(duì)復(fù)雜糅合的 Prompt 理解能力有所提升，但結(jié)構(gòu)化提示詞，依然有助于提升模型些許性能。

  更重要的是，大幅簡(jiǎn)化人類(lèi)工程師理解、維護(hù) Prompt 的難度。

• 先用聰明模型寫(xiě)一版最小化提示：

  寫(xiě)第一版提示詞時(shí)，記得先用你能用到的最聰明模型，寫(xiě)出能大致滿(mǎn)足要求的最小化 Prompt。

  （只有這樣，你才能知道當(dāng)下 AI 的能力邊界，區(qū)分哪些是 Prompt 的問(wèn)題，哪些是模型智力問(wèn)題）

  最小化 Prompt 意味著用最少的提示信息量，優(yōu)先定義“有什么、做什么”，而不是“怎么做”——把我們的提示詞設(shè)計(jì)“最小化”。（詳見(jiàn)：）

  
  

  
  

  根據(jù) Prompt 測(cè)試過(guò)程中發(fā)現(xiàn)的問(wèn)題，迭代必要的指令細(xì)節(jié)、few-shot，優(yōu)化生成效果。

  最終再遷移到最終的生產(chǎn)模型，完成細(xì)化。

• 精選最小可行的 Agent 工具集：為 Agent 準(zhǔn)備的工具，應(yīng)當(dāng)是自包含、能被 LLM 充分理解，且工具之間功能重疊少的。
• • 自包含：工具自身包含了特定任務(wù)所需的所有邏輯和功能，不需要頻繁訪(fǎng)問(wèn)外界或配合調(diào)用其他工具，即可完成任務(wù)。
  • 能被 LLM 理解、使用：如果人類(lèi)都不能準(zhǔn)確描述何時(shí)使用什么工具、如何用調(diào)用，就不要指望同樣依賴(lài)文本生成的 LLM 能夠調(diào)用好工具。

• 謹(jǐn)慎在 Prompt 中添加示例！

  是的，我不喜歡濫用 few-shot。過(guò)度 few-shot 提示，往往會(huì)使得 AI 生成風(fēng)格容易陷入僵化。

• 一般來(lái)說(shuō)，個(gè)人會(huì)盡量避免在推理模型中使用 few-shot。

  Anthropic 團(tuán)隊(duì)也同樣分享了他們的觀(guān)點(diǎn)：

  Few-shot 是非常有效的 AI 提示實(shí)踐，但要著重避免在 prompt 中塞滿(mǎn)過(guò)多邊緣例子，應(yīng)該設(shè)計(jì)一組足夠多樣化、規(guī)范的核心例子，有效展現(xiàn) Agent 的預(yù)期行為。

  （一些不好的 system prompt ，甚至?xí)唤o出準(zhǔn)確、完備的背景信息、目的描述，就在那通過(guò)塞一堆“示例”，強(qiáng)行矯正表現(xiàn)不佳的測(cè)試結(jié)果。

  答應(yīng)我，千萬(wàn)別學(xué)這個(gè)！

• 不然，越是開(kāi)放的復(fù)雜任務(wù)下，模型泛化越是不堪直視，回答形式也極其僵化……比如虛擬陪伴）

別忘了，system prompt，本身就是最小化的初始 context。

一個(gè)清晰、高效的 prompt，能夠用最有必要的 tokens，為后續(xù)推理交互提供重要的方向指引。

策略之二，即時(shí)上下文，讓 Agent 像人一樣地獲取上下文

考慮到在真實(shí)使用 AI 時(shí)，一方面上下文窗口有限，不可能把所有的相關(guān) context 都塞進(jìn)去。

另一方面，以往在推理前的階段采用 embedding-based 檢索的方案，常常會(huì)檢索到很多“可能相關(guān)但實(shí)際沒(méi)用”的內(nèi)容。

所以，現(xiàn)在越來(lái)越多的 AI 應(yīng)用，開(kāi)始采用 AI 自主探索的即時(shí)上下文方案：

• 與人類(lèi)「整體回憶-深入回顧某段記憶細(xì)節(jié)-最終推理得到結(jié)論」的多步思考一樣，其實(shí)沒(méi)必要要求 Agent 在推理時(shí)，一次性回憶所需的全部上下文

• 像 Cursor 等 AI Coding 工具，就會(huì)按照用戶(hù)需求，先翻閱項(xiàng)目文件夾中的 readme.md，了解項(xiàng)目文件結(jié)構(gòu) → 在 /resource/pic 目錄找圖片、到 /component 目錄找組件代碼等。

  在這個(gè)過(guò)程中，Agent 自主導(dǎo)航與檢索信息，動(dòng)態(tài)獲取所需信息到上下文窗口中。
  （對(duì)應(yīng)的，人類(lèi)會(huì)先回憶自己的待辦記在哪個(gè)備忘錄、日歷中，在到對(duì)應(yīng)軟件中翻閱記錄，為大腦的上下文窗口實(shí)現(xiàn)動(dòng)態(tài)掛載與減負(fù)。）

• 此外，即時(shí)上下文方案，也有助于漸進(jìn)式披露上下文，為后續(xù)工作提供參考記憶。

  即使是每一次 Agent 檢索所獲取的文件名稱(chēng)、大小、文件創(chuàng)建時(shí)間，這些信息也都有助于 Agent 在后續(xù)推理中，判斷信息的相關(guān)性與價(jià)值（命名規(guī)范暗示用途；文件大小暗示復(fù)雜性；創(chuàng)建時(shí)間可以作為相關(guān)性參考）（可以讓 Agent 自行記錄 memory 筆記，將這些工作記憶摘要與持久化。）

當(dāng)然，請(qǐng)記得權(quán)衡即時(shí)上下文探索，與向量檢索/直接拼入context 等簡(jiǎn)單方案的耗時(shí)與效果。

策略之三，為超長(zhǎng)程任務(wù)，實(shí)現(xiàn)無(wú)限上下文

雖然模型發(fā)展必然會(huì)帶來(lái)更大的上下文窗口…

但如 Chroma 的 Context Rot 研究，無(wú)論如何，無(wú)關(guān)的 Context 占用上下文窗口時(shí)，必然會(huì)影響模型性能。

在當(dāng)下的時(shí)間節(jié)點(diǎn)，Agent 的智能幾乎與一次性自主運(yùn)行時(shí)長(zhǎng)掛鉤。

AI Coding 中的代碼重構(gòu)任務(wù)、Deep Research 任務(wù)等，往往會(huì)運(yùn)行數(shù)十分鐘及以上，其產(chǎn)生的 context 必然會(huì)遠(yuǎn)超出模型的上下文窗口限制。

為了保障此類(lèi)長(zhǎng)程任務(wù)的連貫性與目標(biāo)達(dá)成，Anthropic 團(tuán)隊(duì)引入了專(zhuān)門(mén)的上下文工程設(shè)計(jì)，在框架層面解決上下文污染與限制問(wèn)題：

1）壓縮（Compaction）

最直接的思路，是在上下文接近窗口限制時(shí)，把對(duì)話(huà)內(nèi)容“有損壓縮”，拋棄冗余無(wú)用的歷史信息，并重新開(kāi)啟一個(gè)新的上下文窗口。

僅保留核心決策與細(xì)節(jié)（比如整體計(jì)劃決策、執(zhí)行過(guò)程錯(cuò)誤和實(shí)現(xiàn)細(xì)節(jié)），以實(shí)現(xiàn)在新對(duì)話(huà)窗口的連貫性。

• 方法： 讓模型觸發(fā)一個(gè)“總結(jié)”動(dòng)作，提煉歷史對(duì)話(huà)。

  以 Claude Code 為例，模型會(huì)保留開(kāi)發(fā)架構(gòu)決策、未解決的錯(cuò)誤和關(guān)鍵實(shí)現(xiàn)細(xì)節(jié)，同時(shí)丟棄冗余的工具輸出或過(guò)于細(xì)枝末節(jié)的消息。

• 工程調(diào)優(yōu)思路： 用于壓縮的 prompt，可以先以「最大召回率」 為目標(biāo)進(jìn)行編寫(xiě)，確保能從歷史中提取所有相關(guān)信息；然后再迭代提示詞，逐步消除總結(jié)中的冗余內(nèi)容，提升壓縮精度。

2）結(jié)構(gòu)化筆記（Structured Note-taking）

當(dāng)下，越來(lái)越多的 Agent 應(yīng)用采用了這種外部 memory 策略，例如 Manus 等通用 Agent 的 todo.md，MemU 等記憶框架的 memory 策略，均屬于此列：

1. 1.Agents 定期把重要記憶（如中間結(jié)論、待辦事項(xiàng)、用戶(hù)畫(huà)像、用戶(hù)活動(dòng)）寫(xiě)入到可供 Agent 讀寫(xiě)的外部筆記文件
2. 2.在后續(xù)推理執(zhí)行過(guò)程中，按需將記憶拉回上下文窗口。

能夠以極小的上下文開(kāi)銷(xiāo)，進(jìn)行持久化記憶。

我之前在測(cè)試 Browser-use Agents 的 2048 游戲最高分時(shí)，也將「在每一步游戲操作后，自行反思并記錄心得與教訓(xùn)」作為 Agents 的 system prompt。

AI 在游戲過(guò)程中，就會(huì)額外記錄結(jié)構(gòu)化筆記，指導(dǎo) AI 在新一輪游戲的操作決策，改進(jìn)游戲得分。如：

- 心得 1：固定一個(gè)角落放最大塊（常用底部左/右角），盡量不要把它移出該角” - 心得 2：盡可能往同一個(gè)方向合并數(shù)字方塊

3）多智能體架構(gòu)（Multi-Agents Architectures）

這是一種更積極的“分而治之”的架構(gòu)思想。

將一個(gè)復(fù)雜任務(wù)分解到多個(gè)子智能體，讓專(zhuān)門(mén)的 Agent 專(zhuān)注于自己的任務(wù)與所需記憶空間，最后由一個(gè)主 Agent 在更高維度協(xié)調(diào)整體的任務(wù)計(jì)劃。

每個(gè)子 Agent 的上下文壓力都會(huì)小很多，模型性能能夠發(fā)揮的更徹底，不易 context rot。

例如，Manus 所推出的 Wide-Research 功能，就采用了類(lèi)似方案，有興趣可以去試試看。因?yàn)槭遣⑿屑軜?gòu)，所以能夠在單位時(shí)間內(nèi)開(kāi)展更加廣泛、深入的 Deep Research 研究或其他復(fù)雜任務(wù)。

至此，

• 壓縮適合多輪對(duì)話(huà)交互任務(wù)；
• 結(jié)構(gòu)化筆記記錄適用于持久化保存工作記憶；
• 多智能體架構(gòu)則方便分解復(fù)雜任務(wù)，緩和單 Agent 的上下文壓力。

可以根據(jù) Agent 應(yīng)用的類(lèi)型和復(fù)雜度靈活組合，共同為超長(zhǎng)程任務(wù)實(shí)現(xiàn)無(wú)限上下文，提供切實(shí)的可能。

4?? 總結(jié)： 精心設(shè)計(jì)你的 Context 工程

回顧上文，system prompt 編寫(xiě)、即時(shí)上下文檢索、上下文架構(gòu)管理，一切討論的錨點(diǎn)，最終都回歸到了 context 工程的核心：

找到以最小 tokens 集合，最大化引出期望 AI 結(jié)果的策略。

Context 工程本身并不神秘，只是隨著 AI Agent 架構(gòu)日趨復(fù)雜、健全的自然工程發(fā)展。

理解了超長(zhǎng)上下文如何影響 LLM 的性能表現(xiàn)，和 Agent 內(nèi)的上下文記憶運(yùn)作機(jī)制，我們才能更好地開(kāi)展有效 context 工程。

最后的最后，請(qǐng)務(wù)必、務(wù)必，把上下文窗口視為有限的資源。

Ref：

• Effective context engineering for AI agents｜By Anthropic：https://www.anthropic.com/engineering/effective-context-engineering-for-ai-agents
• Managing context on the Claude Developer Platform｜By Anthropic：https://www.anthropic.com/news/context-management
• Context Rot: How Increasing Input Tokens Impacts LLM Performance｜By Chroma：https://research.trychroma.com/context-rot

? 梳理：Anthropic 界定的 Agent 類(lèi)型

Anthropic 分享了他們過(guò)去一年里，與數(shù)十個(gè)團(tuán)隊(duì)、客戶(hù)合作構(gòu)建智能體時(shí)，總結(jié)下來(lái)的實(shí)用建議。

關(guān)于智能體的定義劃分，往往在 workflows 和 agents 中有所混淆。Anthropic 將其統(tǒng)稱(chēng)為 agentic systems，智能系統(tǒng)：

• 工作流 Workflow：把 LLMs 和工具通過(guò)代碼，預(yù)編排好執(zhí)行路徑的規(guī)則流程。
• AI 代理 Agent：由 LLMs 自主指導(dǎo)其執(zhí)行過(guò)程和工具使用的自主系統(tǒng)。

• 無(wú)硬性規(guī)定與優(yōu)劣，應(yīng)當(dāng)以解決問(wèn)題為目標(biāo)出發(fā)，可以用多種類(lèi)型進(jìn)行組合。
• 最小化設(shè)計(jì)原則，如無(wú)必要，無(wú)增實(shí)體。從簡(jiǎn)單提示與優(yōu)秀模型開(kāi)始，實(shí)驗(yàn)并構(gòu)筑第一個(gè)版本的「Agent」。只有智能不足時(shí)，才考慮調(diào)優(yōu)工程，添加更多步驟與 Context 指引。
• 請(qǐng)注意 Agent 的可解釋性與維護(hù)性，不可解釋的 Agent 無(wú)法維護(hù)，無(wú)法維護(hù)則無(wú)法針對(duì)生產(chǎn)環(huán)境的各類(lèi)問(wèn)題進(jìn)行工程調(diào)優(yōu)。所以請(qǐng)保持 Agent 的規(guī)劃步驟的透明度

以下是 Anthropic 總結(jié)的 workflow 與 Agents 類(lèi)型，可能為你帶來(lái)一些參考啟發(fā)：

Workflow

增強(qiáng)型 LLM（the augmented LLM）

• 給 LLM 配上檢索、工具、記憶等增強(qiáng)功能，LLM 可以主動(dòng)使用，生成自己的搜搜查詢(xún)、選擇合適的工具。
• 和 Agent 的區(qū)別是，增強(qiáng)型 LLM 不會(huì)規(guī)劃任務(wù)流程，也無(wú)法自行決定下一步做什么，不能自主進(jìn)行多輪交互。

• 提示鏈工作流（Workflow： Prompt Chaining）
• • 通過(guò)將任務(wù)分解為多個(gè)子環(huán)節(jié)，由多個(gè) LLM 分別處理前一個(gè)環(huán)節(jié)的輸出，就像 coze、dify 一樣。
  • 示例應(yīng)用：營(yíng)銷(xiāo)文案生成 → 翻譯為其他語(yǔ)言；文章大綱生成 → 檢查 → 分段完成正文編寫(xiě)

• 路由式工作流（Workflow：Routing）
• • 允許 LLM 分類(lèi) input，并在更合適的子任務(wù)中解決。可以對(duì)不同類(lèi)型的任務(wù)進(jìn)行分別的提示優(yōu)化，不會(huì)干擾其他任務(wù)的表現(xiàn)
  • 比如：AI 客服、Chatbot 自主切換回答模型（簡(jiǎn)單問(wèn)題就切換到小模型，類(lèi)似 ChatGPT 5 網(wǎng)頁(yè)服務(wù)，優(yōu)化成本和響應(yīng)速度）

• 并行式工作流（Workflow：Parallelization）
• • Sectioning：在與用戶(hù)對(duì)話(huà)時(shí)，一個(gè)模型負(fù)責(zé)處理用戶(hù)意圖，一個(gè)模型篩查問(wèn)答中不適當(dāng)、不合規(guī)的內(nèi)容。
  • Voting：代碼 or 內(nèi)容審計(jì)，通過(guò)不同模型/不同提示，從不同方面對(duì)內(nèi)容進(jìn)行評(píng)估，甚至通過(guò)投票閾值來(lái)過(guò)濾假陽(yáng)性。
  • 并行式有兩種應(yīng)用角度，一是分治可并行的獨(dú)立子任務(wù)；二是多次運(yùn)行同一任務(wù)獲取多樣化結(jié)果 or 進(jìn)行投票
  • 什么時(shí)候使用效果更好？1）提升任務(wù)執(zhí)行性能；2）LLM 同時(shí)處理多因素任務(wù)是困難的，分解為單因素單個(gè)模型處理，會(huì)更好
  • 比如：

• 協(xié)調(diào)-執(zhí)行式工作流（Workflow：Orchestrator-Workers）
• • 中央 LLM 分解任務(wù)（相較并行式更靈活，子任務(wù)不是預(yù)先定義的），工作者 LLM 分別執(zhí)行，返回結(jié)果，綜合輸出。
  • 示例應(yīng)用：對(duì)多個(gè)文件進(jìn)行復(fù)雜更改的 coding 產(chǎn)品， 分解需要從多個(gè)來(lái)源收集信息的 search 任務(wù)等。

• 評(píng)估-優(yōu)化式工作流（Workflow：Evaluator-Optimizer）
• • 何時(shí)使用？——當(dāng)人類(lèi)清晰地表達(dá)其反饋時(shí)，LLM 的響應(yīng)可以明顯改進(jìn)；其次，LLM 能夠提供這種反饋
  • 比如：Search 場(chǎng)景、多輪文學(xué)創(chuàng)作與編輯（Evaluator 對(duì)多輪生成內(nèi)容，進(jìn)行綜合反饋與建議）

Agent

Anthropic 把 Agent 定義為：LLMs autonomously using tools in a loop.

• 通常指自主智能體，不斷基于環(huán)境反饋的循環(huán)使用工具。能夠理解復(fù)雜輸入，推理與規(guī)劃，以及從錯(cuò)誤中恢復(fù)。（通常會(huì)包含最大迭代次數(shù)，控制 Agent 行動(dòng)何時(shí)終止）
• 常見(jiàn)的 Computer Use、Coding Agent 均在此列
• 隨著底層模型能力的提升，Agent 獨(dú)立解決復(fù)雜問(wèn)題、處理錯(cuò)誤反饋的能力也會(huì)隨之提升

Ref：

• Building effective agents｜BY Anthropic：https://www.anthropic.com/engineering/building-effective-agents

反思：止損線(xiàn)，亦是起跑線(xiàn)

“在抵達(dá)下一個(gè)階段之前，這就是我探索愿意投入的、輸?shù)闷鸬拇鷥r(jià)?！?/p>

發(fā)現(xiàn)自己在涉及到需要長(zhǎng)期投入的重大決策時(shí)（如職業(yè)選擇、親密關(guān)系等），容易過(guò)度“憂(yōu)慮未來(lái)的最終結(jié)果”。

導(dǎo)致因?yàn)槲窇诌h(yuǎn)期回撤心理，不自覺(jué)地壓抑當(dāng)下的機(jī)會(huì)、幸福感，最終決定放棄對(duì)自己現(xiàn)階段更有價(jià)值的行動(dòng)。

比如：

• 憂(yōu)慮某個(gè)商業(yè)模式、變現(xiàn)機(jī)會(huì)能走多遠(yuǎn)，導(dǎo)致面對(duì)送到手上的機(jī)會(huì)時(shí)，遲遲不敢下注。
• 因過(guò)度追求構(gòu)建“長(zhǎng)期可靠”的關(guān)系，而忽視在當(dāng)下接觸到的人，就無(wú)法通過(guò)一段段交織的關(guān)系，成長(zhǎng)為更好的自己。

被評(píng)價(jià)“這個(gè)人想得清楚”，看起來(lái)是件好事。但有時(shí)也會(huì)因?yàn)楠q豫，錯(cuò)過(guò)一些機(jī)會(huì)。

很難區(qū)分保守與激進(jìn)、深思熟慮與開(kāi)放靈活，孰對(duì)孰錯(cuò)。

但重點(diǎn)在于，決策的第一步不僅僅是靠直覺(jué)、喜好，而是先明確自己當(dāng)下最需要解決的問(wèn)題是什么，盤(pán)算清自己愿意押注的籌碼底線(xiàn)。

比如現(xiàn)在有多少儲(chǔ)蓄，現(xiàn)在來(lái)看，最多愿意設(shè)置 xx 時(shí)間、金錢(qián)的止損線(xiàn)。再次之前要盡情探索自己創(chuàng)業(yè)可能性，到了止損階段后，即使回去上班，自己也能接受。

過(guò)度憂(yōu)慮未來(lái)、不預(yù)分配當(dāng)前階段的籌碼，混亂地做出“明智、保護(hù)自己”的投資，是對(duì)流向自己的機(jī)會(huì)的不尊重。

——未來(lái)是很重要，投注成本是很珍貴，但也請(qǐng)多多珍惜當(dāng)下。