Next-Level Agents：釋放動態(tài)上下文（Dynamic Context）的巨大潛力 原創(chuàng) 精華
編者按： 本文深入探討了如何通過優(yōu)化動態(tài)上下文信息（Dynamic Context）來提升 AI Agents 的工作效率和準(zhǔn)確性。文章首先概述了五種常見的技術(shù)策略，包括信息標(biāo)識(Message Labeling)、針對不同需求設(shè)定不同上下文、優(yōu)化系統(tǒng)提示詞(System Prompts)、精簡 RAG 系統(tǒng)中冗余信息，以及其他處理上下文的高級策略。
隨后，作者分享了一些技術(shù)實(shí)施細(xì)節(jié)和經(jīng)驗(yàn)教訓(xùn)，這些教訓(xùn)雖然源自與 Multi-agent 團(tuán)隊(duì)在實(shí)際生產(chǎn)環(huán)境中的長期合作實(shí)踐，但對于 single agent 系統(tǒng)也具有廣泛的適用性和指導(dǎo)意義。
文中強(qiáng)調(diào)，AI Agents 不應(yīng)僅局限于使用固定提示詞指令來定義，還應(yīng)包含自己的動態(tài)上下文配置。通過簡明的上下文類型劃分，為每個(gè) AI Agent 量身打造不同的上下文配置，將極大拓展其應(yīng)用潛能。本文所述的動態(tài)上下文配置（Dynamic Context）僅是 AI Agents 系統(tǒng)架構(gòu)的冰山一角，歡迎各位讀者就此主題深入交流探討。
作者 | Frank Wittkampf
編譯 | 岳揚(yáng)
AI Agents 之間往往存在很大差異（配圖源自 MidJ
01 內(nèi)容簡介 Introduction
AI Agents 的行為主要由兩點(diǎn)決定： (1) 它所運(yùn)行的基礎(chǔ)模型，以及 (2) 輸入給該模型的上下文信息。上下文信息輸入的方式直接影響著 Agents 任務(wù)執(zhí)行效果。甚至可以說，即使使用同一模型，不同的上下文內(nèi)容輸入也能造就各具特色的 Agents 行為模式。那么，何為 Agents 所需的“上下文信息”呢？可通過查閱下方的 “Types of Context” 圖示了解相關(guān)信息。
本文將深入探討一系列 Agents 進(jìn)階策略，依據(jù) AI Agents 的具體需求優(yōu)化上下文信息，從而提升其工作效率與準(zhǔn)確性。本文首先將概述五種常見技術(shù)策略，然后會分享一些實(shí)施細(xì)節(jié)。 文中總結(jié)的經(jīng)驗(yàn)教訓(xùn)，雖源自于和 multi-agent 團(tuán)隊(duì)在實(shí)際生產(chǎn)環(huán)境中合作的長期實(shí)踐經(jīng)驗(yàn)，但這些經(jīng)驗(yàn)對于 single agent 系統(tǒng)亦具有廣泛的適用性和指導(dǎo)意義。
AI Agents 所涉及的上下文類別（圖片由原文作者提供）
02 理解上下文信息需求
網(wǎng)絡(luò)上大多數(shù)在線示例及教程都傾向于采取簡化手段處理上下文信息（例如設(shè)定一個(gè)固定的上下文長度限制）。然而，在實(shí)際的 AI 應(yīng)用中需要更加細(xì)膩和成熟的方法。
依據(jù)手頭任務(wù)的不同，各種 Agents 對上下文信息的需求大相徑庭。 有的 Agents 或許只需當(dāng)前的信息，而有些 Agents 為了確?；卮鹁珳?zhǔn)，則可能需要依靠大量的歷史數(shù)據(jù)。因?yàn)榇嬖谶@種差異性，需要針對每一個(gè) Agent 制定個(gè)性化的上下文管理策略。
下面是一位用戶與兩個(gè) Agents（用于軟件開發(fā)的 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: “ … ”在上述案例中，上下文的組織方式顯然存在冗余且效率不高。多條對話內(nèi)容都存在不必要的信息重復(fù)（比如 system prompts），同時(shí)每個(gè) Agent 都接收到了超出其范圍的上下文內(nèi)容。為此，我們有必要了解改進(jìn)上下文管理的幾種策略。
03 策略 1：Message Labeling（信息標(biāo)識）
Message labeling 是調(diào)控并提升 AI Agents 任務(wù)執(zhí)行互動效能的重要手段。借由為每次交談的信息附加元數(shù)據(jù)標(biāo)識（metadata），可以智能地篩選出對 Agents 手頭任務(wù)最為關(guān)鍵的信息。此策略圍繞幾個(gè)關(guān)鍵方法展開：
- Relevance Labeling（相關(guān)性信息標(biāo)識）：每一條信息均應(yīng)被賦予能夠體現(xiàn)其與當(dāng)前互動乃至未來交流相關(guān)性的標(biāo)簽。這一操作包括深入剖析信息內(nèi)容，并評估其對 Agents 的決策路徑是否可能存在益處。譬如，那些含有疑問句、決策節(jié)點(diǎn)或獨(dú)到見解的信息，理應(yīng)都被標(biāo)識為極高度相關(guān)。
- Permanence Labeling：根據(jù)信息的時(shí)效性和實(shí)用性進(jìn)行分類這一步極為重要。有些信息，比如含有 foundational decisions （譯者注："foundational decisions" 指的是那些構(gòu)成行為規(guī)劃或討論交流基礎(chǔ)的核心決策，通常對后續(xù)步驟有深遠(yuǎn)影響，確立了基本原則、目標(biāo)或方向。）或 milestone communications （譯者注："milestone communications" 如同國道上的里程牌，指示項(xiàng)目已達(dá)成某個(gè)重要目標(biāo)或正進(jìn)入新階段。）的信息，因其存在長遠(yuǎn)價(jià)值，應(yīng)在不同對話環(huán)節(jié)中持續(xù)保存。相比之下，僅供一次性使用的系統(tǒng)通知類信息（system messages），僅在特定上下文下短暫需要。一旦它們的即刻相關(guān)性（immediate relevance）消逝，便應(yīng)從 AI Agents 的存儲記憶庫（memory）中予以剔除。
- Source and Association Labeling：此步驟會明確每條信息的發(fā)出源頭，不論是來自某個(gè)特定的 Agent 、用戶交互過程、功能執(zhí)行流程或其他程序過程。這種標(biāo)識有利于建立一個(gè)條理清晰、便于追蹤的歷史記錄體系，確保 Agents 能夠根據(jù)信息的源頭或與當(dāng)前任務(wù)的關(guān)聯(lián)度，迅速定位并參考所需資料。
在相關(guān)信息的元數(shù)據(jù)上應(yīng)用智能標(biāo)識（smart labels），就能啟用智能化選取功能（smart selection）。接下來，我們將進(jìn)一步列舉幾個(gè)實(shí)用示例。
04 策略 2：針對 AI Agents 的不同需求設(shè)定不同的上下文
各 Agent 因?yàn)槿蝿?wù)各異，其上下文需求自然也大不相同。有的 Agent 僅憑少量信息就能執(zhí)行，而有的則需大量的上下文信息才能確保操作無誤。這一策略是對之前所述的信息標(biāo)識策略的深化應(yīng)用。
關(guān)鍵上下文要素辨識（Critical Context Identification） ：識別哪些信息對 Agents 來說比較重要，并集中精力優(yōu)化這些要素的處理流程，提升模型響應(yīng)的精確度，這一點(diǎn)至關(guān)重要。以先前交流場景上下文中的第8行為例，用于代碼審查的 Agent 僅需少量的特定上下文即可準(zhǔn)確完成工作。事實(shí)上，若提供給它的上下文超出必要范圍，其處理結(jié)果反而可能不盡人意。
那么，它究竟需要什么樣的上下文呢？粗略一看便可知，用于代碼審查的 Agent 僅需關(guān)注其 system prompt 及緊鄰其前、含有最新版本代碼的最后一條 Agent 消息（第6行）。
換言之，每個(gè) AI Agent 都應(yīng)配置為只選擇自己需要的對話歷史（上下文）。比如，代碼審查 Agent 僅查看最近的兩條消息，而代碼編寫 Agent 則需要更長的上下文歷史作為支持。
05 策略 3：優(yōu)化 System Prompts
指令位置的相關(guān)策略（Placement） ：當(dāng)探討 Agents 及其 system prompts 時(shí)，不難發(fā)現(xiàn) Agents 的 system prompts 位置非常重要。它該置于對話序列的起始，還是末尾？對此，目前尚無定論，實(shí)際效果依具體應(yīng)用場景而異。試想，哪種位置設(shè)計(jì)能更好地促進(jìn)信息的處理與反饋？
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 …"若在更大規(guī)模且復(fù)雜多變的對話歷史中進(jìn)行嘗試，你會觀察到即便是相同的引導(dǎo)語，由于位置不同，最終效果也會有所區(qū)別。不過有一點(diǎn)顯而易見，system prompts 應(yīng)當(dāng)有意識地被放置在某一特定位置，而這一決策需依據(jù) Agents 特性和實(shí)際應(yīng)用場景來決定。
注意：從我的實(shí)踐經(jīng)驗(yàn)來看，system prompt 是否應(yīng)當(dāng)設(shè)置為對話序列的最后一條信息，很大程度上取決于所使用的大語言模型（LLM）。通常情況下，將其置于末位是個(gè)不錯的選擇（當(dāng)然也有例外，比如信息抽取（information extraction）任務(wù)中）。
持久性考量策略（Permanence） ：此外，除了 system prompts 的位置安排外，大多數(shù)情況下，還必須確保 system prompts 被標(biāo)記為 “fleeting” 。這里說的“fleeting message（瞬態(tài)消息）”，意味著一旦其作用發(fā)揮完畢，就不會在對話記錄（上下文）中繼續(xù)留存。
以 agent1 為例，它可能首先接收到一條指令（prompt），要求其暫時(shí)擱置問題進(jìn)行反思（step back and reflect on the problem）。緊接著的下一輪交互環(huán)節(jié)，agent1 又被要求依據(jù)之前的反思來解決問題。在這種情況下，第二次交互時(shí)初始的提示詞（反思）不僅多余，反而可能干擾 Agents ，導(dǎo)致解答質(zhì)量下滑。因此，如若那條初始的 system prompt 能夠設(shè)定為非持久性的，即在之后的交互中不再重復(fù)發(fā)送給 Agents ，處理效果將會更佳。具體到下述例子，這意味著當(dāng)?shù)诙蜗?Agents 發(fā)起 LLM 查詢請求時(shí)，應(yīng)將第 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 都會被安排在最合適的位置。這樣一來，對話記錄（上下文記錄）將會變得干凈而有序，為雙方提供了更精確與更可預(yù)測的互動環(huán)境。
06 策略 4：精簡 RAG 系統(tǒng)中的冗余信息
關(guān)于如何通過優(yōu)化 RAG 系統(tǒng)來增強(qiáng) Agents 效率的話題，我們足以撰寫一系列文章詳述，但在此僅簡明扼要地概述幾條。由于 RAG 操作可能導(dǎo)致大量的 tokens 消耗，掌握一些管理此問題的技巧顯得尤為重要。 若你對該技術(shù)方向尚不夠熟悉，強(qiáng)烈建議你投入足夠的時(shí)間深入研究。
初級的 RAG 教程往往假定用戶上傳的文檔簡潔、直白、明了，但在實(shí)際應(yīng)用中，大多數(shù)文檔結(jié)構(gòu)復(fù)雜且內(nèi)容多變。 根據(jù)我的經(jīng)驗(yàn)，許多文檔具有大量重復(fù)信息，比如同一份 PDF 文章的引言、正文和結(jié)論中經(jīng)常會復(fù)述同一內(nèi)容；一份醫(yī)療記錄中可能會頻繁出現(xiàn)幾乎雷同的醫(yī)療信息；或是系統(tǒng)日志記錄中不斷重復(fù)的日志記錄。尤其在生產(chǎn)環(huán)境下，面對海量文件檢索時(shí)，標(biāo)準(zhǔn) RAG 流程返回的內(nèi)容往往會異常冗余，重復(fù)度極高。
合理應(yīng)對重復(fù)內(nèi)容（Dealing with Duplicates） ：優(yōu)化 RAG 系統(tǒng)上下文的第一步是識別并剔除檢索文檔片段中的確切重復(fù)內(nèi)容及近似重復(fù)內(nèi)容，以防信息冗余。確切的重復(fù)內(nèi)容（Exact duplicates）易于辨認(rèn)，而近似重復(fù)內(nèi)容（Near duplicates）則可通過語義相似性分析（semantic similarity）、向量嵌入的多樣性（diversity of vector embeddings）度量（差異大的文檔片段其向量間距離較遠(yuǎn)）等多種技術(shù)來檢測。如何執(zhí)行這一操作極大程度上取決于具體應(yīng)用情景。這里[1]提供了一些按困惑度（perplexity）分類的實(shí)例。
模型響應(yīng)內(nèi)容多樣化（Diversity in Responses） ：確保 RAG 系統(tǒng)輸出多樣性的方式主要是巧妙地整合來自多個(gè)文件的內(nèi)容。其中一種簡便且高效的策略是，在檢索時(shí)不單純依據(jù)語義相似度（similarity）選取最高的 N 篇文檔，而是在檢索查詢（retrieval query）中使用 GROUP BY 語句。再次強(qiáng)調(diào)，是否采取這一策略，高度取決于具體需求場景。這里[2]也提供了一個(gè)按困惑度分類的實(shí)例。
動態(tài)檢索（Dynamic Retrieval） ：既然本文聚焦于動態(tài)上下文的構(gòu)建，那么如何將這一思想融入 RAG 流程中呢？傳統(tǒng)的 RAG 流程通常只提取排名前 N 的結(jié)果，比如最相關(guān)的 10 段文檔片段。但這并不符合人們檢索信息的方式。在搜索信息時(shí)，人們一般會使用搜索引擎持續(xù)探索，直至找到滿意答案，可能想要的內(nèi)容就在搜索結(jié)果的第一頁，也可能在第二頁甚至更后。當(dāng)然，這取決于個(gè)人的耐心與運(yùn)氣 ;-) 。我們也可以模仿這一過程來設(shè)計(jì) RAG 系統(tǒng)，使其能夠更加靈活地進(jìn)行信息提取。也可以讓 AI Agents 進(jìn)行更有選擇性的檢索，只給出前幾條結(jié)果，然后讓 Agents 決定是否需要更多信息。
這里有一種推薦做法：不要只單一設(shè)定一個(gè)相似度閾值（similarity cutoff），而是設(shè)定高中低三個(gè)閾值界限。 舉個(gè)例子，搜索結(jié)果可能包括 11 個(gè)高度相似、5 個(gè)中等相似以及 20 個(gè)輕微相似的文檔。若我們設(shè)定 Agents 每次只能查看 5 份文檔，接下來就由 Agents 自身決定是否需要更多資料。你可以告知 Agents ，它已瀏覽了 11 份高度相似文檔中的 5 份，還有超過 25 份文檔可供探索。通過巧妙設(shè)計(jì)提示詞指令（prompt engineering），Agents 在搜索數(shù)據(jù)時(shí)將會更快展現(xiàn)出更為理性的行為模式。
07 策略 5：處理上下文的高級策略
下面我將簡要介紹幾種策略，進(jìn)一步介紹動態(tài)上下文：
即時(shí)元數(shù)據(jù)標(biāo)識（Instant Metadata） ：如策略 1 所述，在消息中添加元數(shù)據(jù)標(biāo)識可以幫助我們預(yù)先選擇特定 Agent 所需的歷史記錄。在多數(shù)情況下，一個(gè)簡單的單詞文本標(biāo)簽（one word text label）就足夠了。知道信息來源于某一個(gè)特定功能、特定 Agent 或特定用戶，就可以為消息添加一個(gè)簡單的標(biāo)簽。但如果處理的是非常龐大的 AI 模型響應(yīng)，并且需要進(jìn)一步優(yōu)化，那么需要一種更高級的方法來為對話消息添加元數(shù)據(jù)標(biāo)識：即利用人工智能（with AI）。
這里有一些實(shí)例：
有一種為歷史對話消息（上下文信息）打標(biāo)簽的簡單方法 —— 單獨(dú)調(diào)用一個(gè)成本較低的 AI 模型，由該模型為對話消息生成消息標(biāo)識。然而，這樣每次就需要進(jìn)行兩次 AI 模型調(diào)用，就將整個(gè)流程復(fù)雜化了。
RAG 采用兩步處理方式（Dual processing for RAG） ：為了優(yōu)化 RAG 流程，我們可以考慮使用更便宜（更快）的 LLMs 來濃縮 RAG 系統(tǒng)的輸出結(jié)果，然后再將其提供給 LLMs。使用這種方法的訣竅在于使用非常簡單且不具破壞性的提示詞，將原始的 RAG 系統(tǒng)輸出結(jié)果濃縮或簡化為更易于消化的形式。
例如，可以使用更便宜的模型來剝離那些特定信息，減少重復(fù)，或者只選擇與當(dāng)前任務(wù)相關(guān)的文檔部分。這就要求我們了解這些較為廉價(jià)模型的優(yōu)缺點(diǎn)。如果與功能更強(qiáng)大的模型結(jié)合使用，這種方法可以替我們節(jié)省大量成本（和時(shí)間）。
08 Implementation
OK，上文所述內(nèi)容是否意味著每個(gè) AI Agent 都需要大量的個(gè)性化代碼來優(yōu)化其性能呢？怎樣才能提煉這些理念并廣泛運(yùn)用呢？
Agent 架構(gòu)設(shè)計(jì)（Agent Architecture） ： 針對這些疑問，實(shí)際上存在一些條理清晰的解決方案，只是需要一些長遠(yuǎn)的規(guī)劃與設(shè)計(jì)。要搭建一個(gè)能有效支持多種 Agent 運(yùn)行的平臺，就需要有一個(gè) Agents 框架。如果一開始就有一套明確的設(shè)計(jì)準(zhǔn)則，那么便能輕松利用動態(tài)上下文信息，從而使 Agents 速度更快、成本更低、效果更好。
動態(tài)上下文配置正是 Agents 系統(tǒng)架構(gòu)中的關(guān)鍵一環(huán)。
動態(tài)上下文配置（Dynamic Context Configuration） ：正如本文所述，每個(gè) Agent 都有獨(dú)特的上下文需求。要了解、管理這些需求，實(shí)質(zhì)上就是要處理 Agents 在所有上下文中的大量變化（variation）（參考本文頂部插圖）。令人欣慰的是，這些變化（variation）能夠簡化歸納為少數(shù)幾個(gè)基礎(chǔ)維度。下面通過一個(gè)實(shí)例，綜合展示本文提及的所有概念。
設(shè)想一位用于軟件開發(fā)的 Agent ，它會先規(guī)劃程序開發(fā)方案，隨后根據(jù)這一方案執(zhí)行。這位 Agent 的上下文配置可能為：
- 保存用戶提出的問題（Retain the initial user question）
- 記錄行動方案（Retain the plan）
- 清除過往對話記錄，僅保留最近一次代碼修改記錄（last code revision）及對話鏈中的最后一條信息
- 引入 RAG 機(jī)制處理上傳的代碼文件，但不執(zhí)行 RAG 系統(tǒng)的壓縮處理流程
- 將 system prompt 恒定設(shè)為對話鏈的最后一條信息
這種配置會被保存在該 Agent 的上下文配置中。因此，我們對 AI Agents 的定義超越了單純的一系列固定提示詞指令—— AI Agents 還配備有專門的動態(tài)上下文配置。
您會發(fā)現(xiàn)，對于不同的 AI Agent ，這些動態(tài)上下文配置既具備深刻意義，又展現(xiàn)出豐富的多樣性，它們使得原本高度個(gè)性化的代碼能夠得到有效且高度抽象的統(tǒng)一管理。
09 Rounding up 總結(jié)回顧
合理管理動態(tài)上下文不僅能讓 AI Agents 的表現(xiàn)更加出色，還能顯著提升其準(zhǔn)確性?、響應(yīng)速度??，甚至還能減少能源消耗??……
Agents 不應(yīng)局限于使用固定提示詞指令（prompt instructions）來定義，它還應(yīng)包含自己的動態(tài)上下文配置。借助簡明的上下文類型劃分，為每個(gè) Agents 量身打造不同的動態(tài)上下文配置，將極大拓展 Agents 的應(yīng)用潛能。
動態(tài)上下文配置（Dynamic Context）僅是 Agents 系統(tǒng)架構(gòu)的冰山一角。若各位讀者想要深入了解，歡迎隨時(shí)與原文作者深入交流（或者加入本公眾號建立的交流群聊與各位小伙伴一起交流探討）。也可以在評論區(qū)留下您的問題或獨(dú)到見解，若您覺得本文對你有所裨益，請轉(zhuǎn)發(fā)給您的朋友或關(guān)注我們，這都是對我們莫大的支持與鼓勵！
Thanks for reading!
Frank Wittkampf
Startup Nerd & Tech Exec
??https://medium.com/@frankw_usa??
END
參考資料
本文經(jīng)原作者授權(quán)，由 Baihai IDP 編譯。如需轉(zhuǎn)載譯文，請聯(lián)系獲取授權(quán)。
原文鏈接：
