Next-Level Agents：釋放動態上下文（Dynamic Context）的巨大潛力 原創 精華
編者按： 本文深入探討了如何通過優化動態上下文信息（Dynamic Context）來提升 AI Agents 的工作效率和準確性。文章首先概述了五種常見的技術策略，包括信息標識(Message Labeling)、針對不同需求設定不同上下文、優化系統提示詞(System Prompts)、精簡 RAG 系統中冗余信息，以及其他處理上下文的高級策略。
隨后，作者分享了一些技術實施細節和經驗教訓，這些教訓雖然源自與 Multi-agent 團隊在實際生產環境中的長期合作實踐，但對于 single agent 系統也具有廣泛的適用性和指導意義。
文中強調，AI Agents 不應僅局限于使用固定提示詞指令來定義，還應包含自己的動態上下文配置。通過簡明的上下文類型劃分，為每個 AI Agent 量身打造不同的上下文配置，將極大拓展其應用潛能。本文所述的動態上下文配置（Dynamic Context）僅是 AI Agents 系統架構的冰山一角，歡迎各位讀者就此主題深入交流探討。
作者 | Frank Wittkampf
編譯 | 岳揚
AI Agents 之間往往存在很大差異（配圖源自 MidJ
01 內容簡介 Introduction
AI Agents 的行為主要由兩點決定： (1) 它所運行的基礎模型，以及 (2) 輸入給該模型的上下文信息。上下文信息輸入的方式直接影響著 Agents 任務執行效果。甚至可以說，即使使用同一模型，不同的上下文內容輸入也能造就各具特色的 Agents 行為模式。那么，何為 Agents 所需的“上下文信息”呢？可通過查閱下方的 “Types of Context” 圖示了解相關信息。
本文將深入探討一系列 Agents 進階策略，依據 AI Agents 的具體需求優化上下文信息，從而提升其工作效率與準確性。本文首先將概述五種常見技術策略，然后會分享一些實施細節。 文中總結的經驗教訓，雖源自于和 multi-agent 團隊在實際生產環境中合作的長期實踐經驗，但這些經驗對于 single agent 系統亦具有廣泛的適用性和指導意義。
AI Agents 所涉及的上下文類別（圖片由原文作者提供）
02 理解上下文信息需求
網絡上大多數在線示例及教程都傾向于采取簡化手段處理上下文信息（例如設定一個固定的上下文長度限制）。然而，在實際的 AI 應用中需要更加細膩和成熟的方法。
依據手頭任務的不同，各種 Agents 對上下文信息的需求大相徑庭。 有的 Agents 或許只需當前的信息，而有些 Agents 為了確保回答精準，則可能需要依靠大量的歷史數據。因為存在這種差異性，需要針對每一個 Agent 制定個性化的上下文管理策略。
下面是一位用戶與兩個 Agents（用于軟件開發的 Agent 和用于軟件測試的 Agent）間的交流場景：
1 User: “Please improve the sorting function I wrote from the uploaded file”
2 System_prompt_for_coder: “You are a SW developer, you help the user to
develop …”
3 Coding_agent: “read_file_function”
4 Function_response: “coding snippet: ```some returned code```”
5 System_prompt_for_coder: “You are a SW developer, you help the user to
develop …”
6 Coding_agent: “I’ve improved your code by adding … and … to your code,
here is the new function …”
7 System_prompt_for_reviewer: “you are a SW code reviewer, you …”
8 Code_reviewer_agent: “After reviewing the improved code, there
are a few more things that I would add to the code …"
9 System_prompt_for_coder: “you are a SW developer, you help the user to
develop …”
10 Coding_agent: “ … ”在上述案例中，上下文的組織方式顯然存在冗余且效率不高。多條對話內容都存在不必要的信息重復（比如 system prompts），同時每個 Agent 都接收到了超出其范圍的上下文內容。為此，我們有必要了解改進上下文管理的幾種策略。
03 策略 1：Message Labeling（信息標識）
Message labeling 是調控并提升 AI Agents 任務執行互動效能的重要手段。借由為每次交談的信息附加元數據標識（metadata），可以智能地篩選出對 Agents 手頭任務最為關鍵的信息。此策略圍繞幾個關鍵方法展開：
- Relevance Labeling（相關性信息標識）：每一條信息均應被賦予能夠體現其與當前互動乃至未來交流相關性的標簽。這一操作包括深入剖析信息內容，并評估其對 Agents 的決策路徑是否可能存在益處。譬如，那些含有疑問句、決策節點或獨到見解的信息，理應都被標識為極高度相關。
- Permanence Labeling：根據信息的時效性和實用性進行分類這一步極為重要。有些信息，比如含有 foundational decisions （譯者注："foundational decisions" 指的是那些構成行為規劃或討論交流基礎的核心決策，通常對后續步驟有深遠影響，確立了基本原則、目標或方向。）或 milestone communications （譯者注："milestone communications" 如同國道上的里程牌，指示項目已達成某個重要目標或正進入新階段。）的信息，因其存在長遠價值，應在不同對話環節中持續保存。相比之下，僅供一次性使用的系統通知類信息（system messages），僅在特定上下文下短暫需要。一旦它們的即刻相關性（immediate relevance）消逝，便應從 AI Agents 的存儲記憶庫（memory）中予以剔除。
- Source and Association Labeling：此步驟會明確每條信息的發出源頭，不論是來自某個特定的 Agent 、用戶交互過程、功能執行流程或其他程序過程。這種標識有利于建立一個條理清晰、便于追蹤的歷史記錄體系，確保 Agents 能夠根據信息的源頭或與當前任務的關聯度，迅速定位并參考所需資料。
在相關信息的元數據上應用智能標識（smart labels），就能啟用智能化選取功能（smart selection）。接下來，我們將進一步列舉幾個實用示例。
04 策略 2：針對 AI Agents 的不同需求設定不同的上下文
各 Agent 因為任務各異，其上下文需求自然也大不相同。有的 Agent 僅憑少量信息就能執行，而有的則需大量的上下文信息才能確保操作無誤。這一策略是對之前所述的信息標識策略的深化應用。
關鍵上下文要素辨識（Critical Context Identification） ：識別哪些信息對 Agents 來說比較重要，并集中精力優化這些要素的處理流程，提升模型響應的精確度，這一點至關重要。以先前交流場景上下文中的第8行為例，用于代碼審查的 Agent 僅需少量的特定上下文即可準確完成工作。事實上，若提供給它的上下文超出必要范圍，其處理結果反而可能不盡人意。
那么，它究竟需要什么樣的上下文呢？粗略一看便可知，用于代碼審查的 Agent 僅需關注其 system prompt 及緊鄰其前、含有最新版本代碼的最后一條 Agent 消息（第6行）。
換言之，每個 AI Agent 都應配置為只選擇自己需要的對話歷史（上下文）。比如，代碼審查 Agent 僅查看最近的兩條消息，而代碼編寫 Agent 則需要更長的上下文歷史作為支持。
05 策略 3：優化 System Prompts
指令位置的相關策略（Placement） ：當探討 Agents 及其 system prompts 時，不難發現 Agents 的 system prompts 位置非常重要。它該置于對話序列的起始，還是末尾？對此，目前尚無定論，實際效果依具體應用場景而異。試想，哪種位置設計能更好地促進信息的處理與反饋？
1) user: "I visited dr. Fauci on Thursday, and got diagnosed with …"
2) system: "Extract all medically relevant info from the user prompt"或者
1) system: "Extract all medically relevant info from the user prompt"
2) user: "I visited dr. Fauci on Thursday, and got diagnosed with …"若在更大規模且復雜多變的對話歷史中進行嘗試，你會觀察到即便是相同的引導語，由于位置不同，最終效果也會有所區別。不過有一點顯而易見，system prompts 應當有意識地被放置在某一特定位置，而這一決策需依據 Agents 特性和實際應用場景來決定。
注意：從我的實踐經驗來看，system prompt 是否應當設置為對話序列的最后一條信息，很大程度上取決于所使用的大語言模型（LLM）。通常情況下，將其置于末位是個不錯的選擇（當然也有例外，比如信息抽取（information extraction）任務中）。
持久性考量策略（Permanence） ：此外，除了 system prompts 的位置安排外，大多數情況下，還必須確保 system prompts 被標記為 “fleeting” 。這里說的“fleeting message（瞬態消息）”，意味著一旦其作用發揮完畢，就不會在對話記錄（上下文）中繼續留存。
以 agent1 為例，它可能首先接收到一條指令（prompt），要求其暫時擱置問題進行反思（step back and reflect on the problem）。緊接著的下一輪交互環節，agent1 又被要求依據之前的反思來解決問題。在這種情況下，第二次交互時初始的提示詞（反思）不僅多余，反而可能干擾 Agents ，導致解答質量下滑。因此，如若那條初始的 system prompt 能夠設定為非持久性的，即在之后的交互中不再重復發送給 Agents ，處理效果將會更佳。具體到下述例子，這意味著當第二次向 Agents 發起 LLM 查詢請求時，應將第 2 行信息剔除在外。
#1 User:
"What is the meaning of the universe?"
#2 System:
"You're a philosopher; before you answer, step back and
reflect on what the user's question implies."
#3 Agent_philo:
"Reflecting on this question, one can consider the universe
through various philosophical lenses - existentialism views
it as a canvas for creating personal meaning, while cosmology
sees it as a playground for understanding physical laws. This
interplay between human perception and scientific exploration
is central to understanding our query."
#4 System:
"You're a philosopher, and you just reflected deeply on the
question posed by the user. Use that insightful reflection to
craft a comprehensive answer."
#5 Agent_philo:
"From an existentialist perspective, the meaning of the universe
is a personal journey, where each individual constructs their own
meaning through choices and life experiences. In contrast, from a
cosmological viewpoint, it is about exploring and understanding
the vast, intricate laws that govern the cosmos. These perspectives
help us grasp the multifaceted nature of our universe, blending our
existential quests with scientific inquiry."通過這種方法，所有陳舊的 system prompt 都將從對話序列中清理出去，每條 system prompt 都會被安排在最合適的位置。這樣一來，對話記錄（上下文記錄）將會變得干凈而有序，為雙方提供了更精確與更可預測的互動環境。
06 策略 4：精簡 RAG 系統中的冗余信息
關于如何通過優化 RAG 系統來增強 Agents 效率的話題，我們足以撰寫一系列文章詳述，但在此僅簡明扼要地概述幾條。由于 RAG 操作可能導致大量的 tokens 消耗，掌握一些管理此問題的技巧顯得尤為重要。 若你對該技術方向尚不夠熟悉，強烈建議你投入足夠的時間深入研究。
初級的 RAG 教程往往假定用戶上傳的文檔簡潔、直白、明了，但在實際應用中，大多數文檔結構復雜且內容多變。 根據我的經驗，許多文檔具有大量重復信息，比如同一份 PDF 文章的引言、正文和結論中經常會復述同一內容；一份醫療記錄中可能會頻繁出現幾乎雷同的醫療信息；或是系統日志記錄中不斷重復的日志記錄。尤其在生產環境下，面對海量文件檢索時，標準 RAG 流程返回的內容往往會異常冗余，重復度極高。
合理應對重復內容（Dealing with Duplicates） ：優化 RAG 系統上下文的第一步是識別并剔除檢索文檔片段中的確切重復內容及近似重復內容，以防信息冗余。確切的重復內容（Exact duplicates）易于辨認，而近似重復內容（Near duplicates）則可通過語義相似性分析（semantic similarity）、向量嵌入的多樣性（diversity of vector embeddings）度量（差異大的文檔片段其向量間距離較遠）等多種技術來檢測。如何執行這一操作極大程度上取決于具體應用情景。這里[1]提供了一些按困惑度（perplexity）分類的實例。
模型響應內容多樣化（Diversity in Responses） ：確保 RAG 系統輸出多樣性的方式主要是巧妙地整合來自多個文件的內容。其中一種簡便且高效的策略是，在檢索時不單純依據語義相似度（similarity）選取最高的 N 篇文檔，而是在檢索查詢（retrieval query）中使用 GROUP BY 語句。再次強調，是否采取這一策略，高度取決于具體需求場景。這里[2]也提供了一個按困惑度分類的實例。
動態檢索（Dynamic Retrieval） ：既然本文聚焦于動態上下文的構建，那么如何將這一思想融入 RAG 流程中呢？傳統的 RAG 流程通常只提取排名前 N 的結果，比如最相關的 10 段文檔片段。但這并不符合人們檢索信息的方式。在搜索信息時，人們一般會使用搜索引擎持續探索，直至找到滿意答案，可能想要的內容就在搜索結果的第一頁，也可能在第二頁甚至更后。當然，這取決于個人的耐心與運氣 ;-) 。我們也可以模仿這一過程來設計 RAG 系統，使其能夠更加靈活地進行信息提取。也可以讓 AI Agents 進行更有選擇性的檢索，只給出前幾條結果，然后讓 Agents 決定是否需要更多信息。
這里有一種推薦做法：不要只單一設定一個相似度閾值（similarity cutoff），而是設定高中低三個閾值界限。 舉個例子，搜索結果可能包括 11 個高度相似、5 個中等相似以及 20 個輕微相似的文檔。若我們設定 Agents 每次只能查看 5 份文檔，接下來就由 Agents 自身決定是否需要更多資料。你可以告知 Agents ，它已瀏覽了 11 份高度相似文檔中的 5 份，還有超過 25 份文檔可供探索。通過巧妙設計提示詞指令（prompt engineering），Agents 在搜索數據時將會更快展現出更為理性的行為模式。
07 策略 5：處理上下文的高級策略
下面我將簡要介紹幾種策略，進一步介紹動態上下文：
即時元數據標識（Instant Metadata） ：如策略 1 所述，在消息中添加元數據標識可以幫助我們預先選擇特定 Agent 所需的歷史記錄。在多數情況下，一個簡單的單詞文本標簽（one word text label）就足夠了。知道信息來源于某一個特定功能、特定 Agent 或特定用戶，就可以為消息添加一個簡單的標簽。但如果處理的是非常龐大的 AI 模型響應，并且需要進一步優化，那么需要一種更高級的方法來為對話消息添加元數據標識：即利用人工智能（with AI）。
這里有一些實例：
有一種為歷史對話消息（上下文信息）打標簽的簡單方法 —— 單獨調用一個成本較低的 AI 模型，由該模型為對話消息生成消息標識。然而，這樣每次就需要進行兩次 AI 模型調用，就將整個流程復雜化了。
RAG 采用兩步處理方式（Dual processing for RAG） ：為了優化 RAG 流程，我們可以考慮使用更便宜（更快）的 LLMs 來濃縮 RAG 系統的輸出結果，然后再將其提供給 LLMs。使用這種方法的訣竅在于使用非常簡單且不具破壞性的提示詞，將原始的 RAG 系統輸出結果濃縮或簡化為更易于消化的形式。
例如，可以使用更便宜的模型來剝離那些特定信息，減少重復，或者只選擇與當前任務相關的文檔部分。這就要求我們了解這些較為廉價模型的優缺點。如果與功能更強大的模型結合使用，這種方法可以替我們節省大量成本（和時間）。
08 Implementation
OK，上文所述內容是否意味著每個 AI Agent 都需要大量的個性化代碼來優化其性能呢？怎樣才能提煉這些理念并廣泛運用呢？
Agent 架構設計（Agent Architecture） ： 針對這些疑問，實際上存在一些條理清晰的解決方案，只是需要一些長遠的規劃與設計。要搭建一個能有效支持多種 Agent 運行的平臺，就需要有一個 Agents 框架。如果一開始就有一套明確的設計準則，那么便能輕松利用動態上下文信息，從而使 Agents 速度更快、成本更低、效果更好。
動態上下文配置正是 Agents 系統架構中的關鍵一環。
動態上下文配置（Dynamic Context Configuration） ：正如本文所述，每個 Agent 都有獨特的上下文需求。要了解、管理這些需求，實質上就是要處理 Agents 在所有上下文中的大量變化（variation）（參考本文頂部插圖）。令人欣慰的是，這些變化（variation）能夠簡化歸納為少數幾個基礎維度。下面通過一個實例，綜合展示本文提及的所有概念。
設想一位用于軟件開發的 Agent ，它會先規劃程序開發方案，隨后根據這一方案執行。這位 Agent 的上下文配置可能為：
- 保存用戶提出的問題（Retain the initial user question）
- 記錄行動方案（Retain the plan）
- 清除過往對話記錄，僅保留最近一次代碼修改記錄（last code revision）及對話鏈中的最后一條信息
- 引入 RAG 機制處理上傳的代碼文件，但不執行 RAG 系統的壓縮處理流程
- 將 system prompt 恒定設為對話鏈的最后一條信息
這種配置會被保存在該 Agent 的上下文配置中。因此，我們對 AI Agents 的定義超越了單純的一系列固定提示詞指令—— AI Agents 還配備有專門的動態上下文配置。
您會發現，對于不同的 AI Agent ，這些動態上下文配置既具備深刻意義，又展現出豐富的多樣性，它們使得原本高度個性化的代碼能夠得到有效且高度抽象的統一管理。
09 Rounding up 總結回顧
合理管理動態上下文不僅能讓 AI Agents 的表現更加出色，還能顯著提升其準確性?、響應速度??，甚至還能減少能源消耗??……
Agents 不應局限于使用固定提示詞指令（prompt instructions）來定義，它還應包含自己的動態上下文配置。借助簡明的上下文類型劃分，為每個 Agents 量身打造不同的動態上下文配置，將極大拓展 Agents 的應用潛能。
動態上下文配置（Dynamic Context）僅是 Agents 系統架構的冰山一角。若各位讀者想要深入了解，歡迎隨時與原文作者深入交流（或者加入本公眾號建立的交流群聊與各位小伙伴一起交流探討）。也可以在評論區留下您的問題或獨到見解，若您覺得本文對你有所裨益，請轉發給您的朋友或關注我們，這都是對我們莫大的支持與鼓勵！
Thanks for reading!
Frank Wittkampf
Startup Nerd & Tech Exec
??https://medium.com/@frankw_usa??
END
參考資料
本文經原作者授權，由 Baihai IDP 編譯。如需轉載譯文，請聯系獲取授權。
原文鏈接：
寫的太好了 帶來了很多靈感
