本文腦圖如下:
方法:AI Agent 的有效上下文工程
![]()
1?? 何為上下文工程 Context Engineering ?
2025 年 6 月以來,原名為「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」,即上下文工程。
![]()
在國內(nèi),也對(duì)應(yīng)出現(xiàn)了“Prompt 工程已死,未來屬于 context 工程”、“別再卷 prompt 了”等論調(diào)。
但,事實(shí)盡是如此?
雖然傳播一個(gè)新概念的“好”方法,就是拿它與出了名的舊事物對(duì)比、營造沖突。
但 prompt 仍是 context 工程不可或缺的子集,context 工程則是為適應(yīng) AI Agent 架構(gòu)日趨復(fù)雜健全的自然發(fā)展。(Anthropic 團(tuán)隊(duì)在《Effective Context Engineering for AI Agents》一文中,也提到了一致觀點(diǎn))
要簡單區(qū)分兩者差異的話,可以如此理解:
- Prompt 工程,專注單輪 AI 交互的生成質(zhì)量,是為獲得最佳結(jié)果而編寫和組織 LLM 指令的方法。
- Context 工程,更關(guān)心在多輪 LLM 推理過程(可通俗理解為 Agent 運(yùn)行過程)中,找到并維護(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 開發(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,近年來 LLM 上下文窗口大小,確實(shí)提升飛快。
這是否意味著我們可以高枕無憂,把一切 Context 都無腦地塞進(jìn)去?
答案是否定的——時(shí)至今日,上下文依舊需要被視為有遞減收益邊際的有限資源。
不知道你在和 AI 聊天時(shí),是否發(fā)現(xiàn)這么一個(gè)現(xiàn)象?
當(dāng)對(duì)話長度不斷增加(即使還沒超過官方標(biāo)稱的上下文窗口尺度),模型的回復(fù)質(zhì)量也會(huì)有明顯的下降:
- 回答深度降低: 越來越難深入結(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)起來,得出一些南轅北轍的奇怪結(jié)論。
- 忘記前序指令: 忘記了對(duì)話早期你對(duì)它的回答要求(比如不要濫用比喻句式),但隨著你自己使用了類似比喻的文風(fēng)后,又開始犯軸。
——1M 上下文的 Gemini 2.5 Pro,基本在 tokens 量來到 4w 左右時(shí),會(huì)反映為推理緩慢,質(zhì)量開始有所下降。
是的,最大上下文窗口 ≠ 最佳注意力窗口。
有個(gè)專門術(shù)語來描述這個(gè)普遍的負(fù)面模型現(xiàn)象:Context Rot,上下文腐爛。
如同人類在信息過載時(shí)會(huì)思維混亂,而過長的、充滿干擾的上下文,同樣會(huì)顯著降低模型的推理能力。
而模型性能下降(上下文腐爛,context rot)的三大因素如下:
- 1.Context 輸入越長 → 注意力被稀釋。
- 2.問題與關(guān)鍵信息的語義相似度越低 → 模型越難匹配到答案。
- 3.關(guān)鍵信息與周圍干擾內(nèi)容的語義相似度越高 → 干擾增強(qiáng),模型難以分辨。
這三個(gè)因素會(huì)相互放大,導(dǎo)致性能顯著下降。
PS:反過來,控制 Context 長度、減少 Context 中的干擾項(xiàng)數(shù)量、提升問題與 Context 中有效信息的相似度,就能夠提升 Agent 的處理效果
這三大因素來自于 Chroma 團(tuán)隊(duì)(打造了目前全球最主流的開源向量數(shù)據(jù)庫之一)名為《Context Rot》的同名實(shí)驗(yàn)研究。
實(shí)驗(yàn)研究古法人工濃縮如下,個(gè)人覺得會(huì)對(duì)測(cè)試 AI 產(chǎn)品有一些實(shí)用啟發(fā)。(比如測(cè)試較佳 context 長度)
如果覺得太長,也可以下滑到本段小結(jié)~
? Chroma:探究上下文對(duì)模型性能影響的關(guān)鍵要素
他們?cè)O(shè)計(jì)了一套實(shí)驗(yàn),來測(cè)試影響 LLM 長上下文性能表現(xiàn)的因素:
在傳統(tǒng) NIAH(Needle in a Haystack:即 LLM 大海撈針測(cè)試)基礎(chǔ)上,進(jìn)一步拓展任務(wù)難度,考察大模型的語義理解層面的撈針能力,而非直接詞匯匹配。
傳統(tǒng) NIAH 任務(wù),是評(píng)估模型長上下文能力最廣使用的基準(zhǔn)之一:
將一個(gè)隨機(jī)事實(shí)(針信息),放在較長的上下文(干草堆)中,通過直接問答,要求模型回答某個(gè)針的信息 ,比如:
干草堆:[大量無關(guān)文本]
藏在干草堆的針信息:“我從大學(xué)同學(xué)那里得到的最好的寫作建議是每周都要寫作。”
問題 Prompt:“我從大學(xué)同學(xué)那里得到的最好的寫作建議是什么?”
![]()
此時(shí),模型被期望能從大量干草堆中,直接找到針信息,并回答“每周都寫作”。全程無需間接推理信息,直接根據(jù)已有信息回答即可。
傳統(tǒng) NIAH 雖然很有效地考察了 LLM 的大海撈針能力,但實(shí)際問答場景往往不會(huì)如此直接清晰:
- 一方面,需要 LLM 處理“針-問題”之間的模糊語義:“我周末去了動(dòng)物園,并在那里喂了長頸鹿。”,那么問題“動(dòng)物園里有什么動(dòng)物”
- 另一方面,真實(shí)的上下文中,往往充滿了容易誤解的干擾項(xiàng)。比如,“我從我大學(xué)教授那里得到的最好的寫作建議是每天寫作”,就會(huì)對(duì)上文“大學(xué)同學(xué)的寫作建議”形成干擾(就如人類讀一篇文章很快、很長時(shí),也容易記錯(cuò)細(xì)節(jié))

Chroma 團(tuán)隊(duì)實(shí)際上,也注意到了這一點(diǎn),并拓展了 4 種不同 NIAH 任務(wù):
- 1.“針-問題對(duì)”相似度測(cè)試:構(gòu)造不同語義理解難度的問題,測(cè)試不同 context 長度對(duì)回答的影響
- 2.干擾項(xiàng)測(cè)試:設(shè)置“不同的數(shù)量 + 不同的放置位置”的干擾項(xiàng),測(cè)試不同 context 長度對(duì)回答的影響
![]()
- 3.“針-干草堆”相似度測(cè)試:當(dāng)針信息與上下文的向量語義逐漸接近時(shí),測(cè)試不同 context 長度對(duì)回答的影響
- 4.上下文文本、段落結(jié)構(gòu)測(cè)試:測(cè)試相同內(nèi)容含義時(shí),邏輯連貫的結(jié)構(gòu)與雜亂顛倒的結(jié)構(gòu),是否對(duì)模型推理性能有所影響
看完整體測(cè)試過程,我也總結(jié)了一些有助于理解 context 工程價(jià)值的現(xiàn)象:
- 1.無論如何,context 長度增加時(shí),模型完成同樣任務(wù)(即使很簡單)的能力都會(huì)下降
- 2.針與問題之間的語義關(guān)系越難理解(相似度低),受 context 長度影響越大;且這種下降在長輸入時(shí)會(huì)被顯著放大。
而 Context 長度較短時(shí),模型對(duì)低相似度的問題,有更高的處理成功率
- 3.context 越長,干擾項(xiàng)對(duì)模型的影響也會(huì)加劇
- 4.針與干草堆的內(nèi)容,在語義上越接近(主題越相關(guān)),模型識(shí)別針的能力越差。 如果針在語義上與周圍內(nèi)容格格不入(邏輯不連續(xù)、主題突兀),模型反而更容易識(shí)別。就像人玩找茬游戲,對(duì)突兀的信息更敏感。
難:在 10 篇“寫作建議”文章中找“最佳寫作建議是每周寫作”
易:在“量子物理、烹飪、園藝”文章中找“最佳寫作建議是每周寫作”
小結(jié):當(dāng) AI Agent 在多輪推理和更長的時(shí)間線上運(yùn)行時(shí),模型必然會(huì)面臨越來越多的 context rot 因素。
冗余的上下文將大量占用模型的思考空間,顯著降低其完成復(fù)雜任務(wù)的思考能力。
而上下文工程(Context Engineering)誕生的實(shí)質(zhì),正是在探究哪種上下文配置,最有可能引導(dǎo)模型輸出我們期望的結(jié)果,獲取更好的任務(wù)效果。
3?? 有效開展 Context 工程的方法
AI Agent 發(fā)展至今,已經(jīng)越來越能夠在多輪推理和更長的時(shí)間內(nèi)運(yùn)行。
這些不斷在“思考-行動(dòng)-觀察”中循環(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ì)話歷史 message history 等)
為了避免模型性能的下降,這些數(shù)據(jù)必須被 context 工程動(dòng)態(tài)優(yōu)化:
唯有效的 context 才配占據(jù)有限的上下文窗口資源。
![]()
Anthropic《Effective Context Engineering for AI Agents》:圖解 Agent 開發(fā)中,context engineering 的起效形式
想要實(shí)現(xiàn)有效的 context 工程,大體上分為三類策略:
策略之一,從寫好 System Prompt 開始
我們依舊可以從更熟悉的模塊開始學(xué)習(xí)——通過 Prompt 工程,設(shè)計(jì)清晰、簡單直接的系統(tǒng)提示。
有效的上下文,始于清晰的指令。
如果 Prompt 過于具體,使用大量示例、if-else 類的要求,則會(huì)使得模型更加僵化,缺乏處理意外情況的能力;
而 Prompt 如果要求過于模糊,或缺少足夠的背景信息,則會(huì)無法對(duì)模型輸出進(jìn)行可控管理。
![]()
在 Agent 運(yùn)行過程中,每一輪推理所產(chǎn)生的部分 context(工具調(diào)用返回結(jié)果、Chat 回應(yīng)等) ,也需經(jīng)由 Prompt 引導(dǎo)其如何輸出和被精煉(Kimi 那類 Model as Agent 的路線不在此列),方可具備一定的可預(yù)測(cè)性與管理意義。
以下是一些經(jīng)過實(shí)踐檢驗(yàn)、能顯著提升模型表現(xiàn)的提示詞編寫原則:
- 啟發(fā)式引導(dǎo):系統(tǒng)提示 System Prompt 應(yīng)當(dāng)足夠靈活地為模型提供啟發(fā)式引導(dǎo),使其既能具體地輸出所需的結(jié)果,又能泛化應(yīng)對(duì)各類邊界情況。
比如「利用 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 語法,分割不同指導(dǎo)作用的提示詞。
雖然隨著模型能力提升,LLM 對(duì)復(fù)雜糅合的 Prompt 理解能力有所提升,但結(jié)構(gòu)化提示詞,依然有助于提升模型些許性能。更重要的是,大幅簡化人類工程師理解、維護(hù) Prompt 的難度。
- 先用聰明模型寫一版最小化提示:
寫第一版提示詞時(shí),記得先用你能用到的最聰明模型,寫出能大致滿足要求的最小化 Prompt。
(只有這樣,你才能知道當(dāng)下 AI 的能力邊界,區(qū)分哪些是 Prompt 的問題,哪些是模型智力問題)
最小化 Prompt 意味著用最少的提示信息量,優(yōu)先定義“有什么、做什么”,而不是“怎么做”——把我們的提示詞設(shè)計(jì)“最小化”。(詳見:)


根據(jù) Prompt 測(cè)試過程中發(fā)現(xiàn)的問題,迭代必要的指令細(xì)節(jié)、few-shot,優(yōu)化生成效果。
最終再遷移到最終的生產(chǎn)模型,完成細(xì)化。
- 精選最小可行的 Agent 工具集:為 Agent 準(zhǔn)備的工具,應(yīng)當(dāng)是自包含、能被 LLM 充分理解,且工具之間功能重疊少的。
- 自包含:工具自身包含了特定任務(wù)所需的所有邏輯和功能,不需要頻繁訪問外界或配合調(diào)用其他工具,即可完成任務(wù)。
- 能被 LLM 理解、使用:如果人類都不能準(zhǔn)確描述何時(shí)使用什么工具、如何用調(diào)用,就不要指望同樣依賴文本生成的 LLM 能夠調(diào)用好工具。
- 謹(jǐn)慎在 Prompt 中添加示例!
是的,我不喜歡濫用 few-shot。過度 few-shot 提示,往往會(huì)使得 AI 生成風(fēng)格容易陷入僵化。
一般來說,個(gè)人會(huì)盡量避免在推理模型中使用 few-shot。
Anthropic 團(tuán)隊(duì)也同樣分享了他們的觀點(diǎn):
Few-shot 是非常有效的 AI 提示實(shí)踐,但要著重避免在 prompt 中塞滿過多邊緣例子,應(yīng)該設(shè)計(jì)一組足夠多樣化、規(guī)范的核心例子,有效展現(xiàn) Agent 的預(yù)期行為。
(一些不好的 system prompt ,甚至?xí)唤o出準(zhǔn)確、完備的背景信息、目的描述,就在那通過塞一堆“示例”,強(qiáng)行矯正表現(xiàn)不佳的測(cè)試結(jié)果。
答應(yīng)我,千萬別學(xué)這個(gè)!
不然,越是開放的復(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í)際沒用”的內(nèi)容。
所以,現(xiàn)在越來越多的 AI 應(yīng)用,開始采用 AI 自主探索的即時(shí)上下文方案:
- 與人類「整體回憶-深入回顧某段記憶細(xì)節(jié)-最終推理得到結(jié)論」的多步思考一樣,其實(shí)沒必要要求 Agent 在推理時(shí),一次性回憶所需的全部上下文
- 像 Cursor 等 AI Coding 工具,就會(huì)按照用戶需求,先翻閱項(xiàng)目文件夾中的 readme.md,了解項(xiàng)目文件結(jié)構(gòu) → 在 /resource/pic 目錄找圖片、到 /component 目錄找組件代碼等。
在這個(gè)過程中,Agent 自主導(dǎo)航與檢索信息,動(dòng)態(tài)獲取所需信息到上下文窗口中。
(對(duì)應(yīng)的,人類會(huì)先回憶自己的待辦記在哪個(gè)備忘錄、日歷中,在到對(duì)應(yīng)軟件中翻閱記錄,為大腦的上下文窗口實(shí)現(xiàn)動(dòng)態(tài)掛載與減負(fù)。)
- 此外,即時(shí)上下文方案,也有助于漸進(jìn)式披露上下文,為后續(xù)工作提供參考記憶。
即使是每一次 Agent 檢索所獲取的文件名稱、大小、文件創(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 等簡單方案的耗時(shí)與效果。
策略之三,為超長程任務(wù),實(shí)現(xiàn)無限上下文
雖然模型發(fā)展必然會(huì)帶來更大的上下文窗口…
但如 Chroma 的 Context Rot 研究,無論如何,無關(guān)的 Context 占用上下文窗口時(shí),必然會(huì)影響模型性能。
在當(dāng)下的時(shí)間節(jié)點(diǎn),Agent 的智能幾乎與一次性自主運(yùn)行時(shí)長掛鉤。
AI Coding 中的代碼重構(gòu)任務(wù)、Deep Research 任務(wù)等,往往會(huì)運(yùn)行數(shù)十分鐘及以上,其產(chǎn)生的 context 必然會(huì)遠(yuǎn)超出模型的上下文窗口限制。
為了保障此類長程任務(wù)的連貫性與目標(biāo)達(dá)成,Anthropic 團(tuán)隊(duì)引入了專門的上下文工程設(shè)計(jì),在框架層面解決上下文污染與限制問題:
1)壓縮(Compaction)
最直接的思路,是在上下文接近窗口限制時(shí),把對(duì)話內(nèi)容“有損壓縮”,拋棄冗余無用的歷史信息,并重新開啟一個(gè)新的上下文窗口。
僅保留核心決策與細(xì)節(jié)(比如整體計(jì)劃決策、執(zhí)行過程錯(cuò)誤和實(shí)現(xiàn)細(xì)節(jié)),以實(shí)現(xiàn)在新對(duì)話窗口的連貫性。
- 方法: 讓模型觸發(fā)一個(gè)“總結(jié)”動(dòng)作,提煉歷史對(duì)話。
以 Claude Code 為例,模型會(huì)保留開發(fā)架構(gòu)決策、未解決的錯(cuò)誤和關(guān)鍵實(shí)現(xiàn)細(xì)節(jié),同時(shí)丟棄冗余的工具輸出或過于細(xì)枝末節(jié)的消息。
- 工程調(diào)優(yōu)思路: 用于壓縮的 prompt,可以先以「最大召回率」 為目標(biāo)進(jìn)行編寫,確保能從歷史中提取所有相關(guān)信息;然后再迭代提示詞,逐步消除總結(jié)中的冗余內(nèi)容,提升壓縮精度。
2)結(jié)構(gòu)化筆記(Structured Note-taking)
當(dāng)下,越來越多的 Agent 應(yīng)用采用了這種外部 memory 策略,例如 Manus 等通用 Agent 的 todo.md,MemU 等記憶框架的 memory 策略,均屬于此列:
- 1.Agents 定期把重要記憶(如中間結(jié)論、待辦事項(xiàng)、用戶畫像、用戶活動(dòng))寫入到可供 Agent 讀寫的外部筆記文件
- 2.在后續(xù)推理執(zhí)行過程中,按需將記憶拉回上下文窗口。
能夠以極小的上下文開銷,進(jìn)行持久化記憶。
我之前在測(cè)試 Browser-use Agents 的 2048 游戲最高分時(shí),也將「在每一步游戲操作后,自行反思并記錄心得與教訓(xùn)」作為 Agents 的 system prompt。
AI 在游戲過程中,就會(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è)子智能體,讓專門的 Agent 專注于自己的任務(wù)與所需記憶空間,最后由一個(gè)主 Agent 在更高維度協(xié)調(diào)整體的任務(wù)計(jì)劃。
每個(gè)子 Agent 的上下文壓力都會(huì)小很多,模型性能能夠發(fā)揮的更徹底,不易 context rot。
例如,Manus 所推出的 Wide-Research 功能,就采用了類似方案,有興趣可以去試試看。因?yàn)槭遣⑿屑軜?gòu),所以能夠在單位時(shí)間內(nèi)開展更加廣泛、深入的 Deep Research 研究或其他復(fù)雜任務(wù)。
至此,
- 壓縮適合多輪對(duì)話交互任務(wù);
- 結(jié)構(gòu)化筆記記錄適用于持久化保存工作記憶;
- 多智能體架構(gòu)則方便分解復(fù)雜任務(wù),緩和單 Agent 的上下文壓力。
可以根據(jù) Agent 應(yīng)用的類型和復(fù)雜度靈活組合,共同為超長程任務(wù)實(shí)現(xiàn)無限上下文,提供切實(shí)的可能。
4?? 總結(jié): 精心設(shè)計(jì)你的 Context 工程
回顧上文,system prompt 編寫、即時(shí)上下文檢索、上下文架構(gòu)管理,一切討論的錨點(diǎn),最終都回歸到了 context 工程的核心:
找到以最小 tokens 集合,最大化引出期望 AI 結(jié)果的策略。
Context 工程本身并不神秘,只是隨著 AI Agent 架構(gòu)日趨復(fù)雜、健全的自然工程發(fā)展。
理解了超長上下文如何影響 LLM 的性能表現(xiàn),和 Agent 內(nèi)的上下文記憶運(yùn)作機(jī)制,我們才能更好地開展有效 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 類型
Anthropic 分享了他們過去一年里,與數(shù)十個(gè)團(tuán)隊(duì)、客戶合作構(gòu)建智能體時(shí),總結(jié)下來的實(shí)用建議。
關(guān)于智能體的定義劃分,往往在 workflows 和 agents 中有所混淆。Anthropic 將其統(tǒng)稱為 agentic systems,智能系統(tǒng):
- 工作流 Workflow:把 LLMs 和工具通過代碼,預(yù)編排好執(zhí)行路徑的規(guī)則流程。
- AI 代理 Agent:由 LLMs 自主指導(dǎo)其執(zhí)行過程和工具使用的自主系統(tǒng)。
如何選用、設(shè)計(jì) agentic systems ?
- 無硬性規(guī)定與優(yōu)劣,應(yīng)當(dāng)以解決問題為目標(biāo)出發(fā),可以用多種類型進(jìn)行組合。
- 最小化設(shè)計(jì)原則,如無必要,無增實(shí)體。從簡單提示與優(yōu)秀模型開始,實(shí)驗(yàn)并構(gòu)筑第一個(gè)版本的「Agent」。只有智能不足時(shí),才考慮調(diào)優(yōu)工程,添加更多步驟與 Context 指引。
- 請(qǐng)注意 Agent 的可解釋性與維護(hù)性,不可解釋的 Agent 無法維護(hù),無法維護(hù)則無法針對(duì)生產(chǎn)環(huán)境的各類問題進(jìn)行工程調(diào)優(yōu)。所以請(qǐng)保持 Agent 的規(guī)劃步驟的透明度
以下是 Anthropic 總結(jié)的 workflow 與 Agents 類型,可能為你帶來一些參考啟發(fā):
Workflow
增強(qiáng)型 LLM(the augmented LLM)
- 給 LLM 配上檢索、工具、記憶等增強(qiáng)功能,LLM 可以主動(dòng)使用,生成自己的搜搜查詢、選擇合適的工具。
- 和 Agent 的區(qū)別是,增強(qiáng)型 LLM 不會(huì)規(guī)劃任務(wù)流程,也無法自行決定下一步做什么,不能自主進(jìn)行多輪交互。
![]()
- 提示鏈工作流(Workflow: Prompt Chaining)
- 通過將任務(wù)分解為多個(gè)子環(huán)節(jié),由多個(gè) LLM 分別處理前一個(gè)環(huán)節(jié)的輸出,就像 coze、dify 一樣。
- 示例應(yīng)用:營銷文案生成 → 翻譯為其他語言;文章大綱生成 → 檢查 → 分段完成正文編寫
![]()
- 路由式工作流(Workflow:Routing)
- 允許 LLM 分類 input,并在更合適的子任務(wù)中解決。可以對(duì)不同類型的任務(wù)進(jìn)行分別的提示優(yōu)化,不會(huì)干擾其他任務(wù)的表現(xiàn)
- 比如:AI 客服、Chatbot 自主切換回答模型(簡單問題就切換到小模型,類似 ChatGPT 5 網(wǎng)頁服務(wù),優(yōu)化成本和響應(yīng)速度)
![]()
- 并行式工作流(Workflow:Parallelization)
- Sectioning:在與用戶對(duì)話時(shí),一個(gè)模型負(fù)責(zé)處理用戶意圖,一個(gè)模型篩查問答中不適當(dāng)、不合規(guī)的內(nèi)容。
- Voting:代碼 or 內(nèi)容審計(jì),通過不同模型/不同提示,從不同方面對(duì)內(nèi)容進(jìn)行評(pí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è)來源收集信息的 search 任務(wù)等。
![]()
- 評(píng)估-優(yōu)化式工作流(Workflow:Evaluator-Optimizer)
- 何時(shí)使用?——當(dāng)人類清晰地表達(dá)其反饋時(shí),LLM 的響應(yīng)可以明顯改進(jìn);其次,LLM 能夠提供這種反饋
- 比如:Search 場景、多輪文學(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í)終止)
- 常見的 Computer Use、Coding Agent 均在此列
- 隨著底層模型能力的提升,Agent 獨(dú)立解決復(fù)雜問題、處理錯(cuò)誤反饋的能力也會(huì)隨之提升
![]()
Ref:
- Building effective agents|BY Anthropic:https://www.anthropic.com/engineering/building-effective-agents
反思:止損線,亦是起跑線
“在抵達(dá)下一個(gè)階段之前,這就是我探索愿意投入的、輸?shù)闷鸬拇鷥r(jià)。”
發(fā)現(xiàn)自己在涉及到需要長期投入的重大決策時(shí)(如職業(yè)選擇、親密關(guān)系等),容易過度“憂慮未來的最終結(jié)果”。
導(dǎo)致因?yàn)槲窇诌h(yuǎn)期回撤心理,不自覺地壓抑當(dāng)下的機(jī)會(huì)、幸福感,最終決定放棄對(duì)自己現(xiàn)階段更有價(jià)值的行動(dòng)。
比如:
- 憂慮某個(gè)商業(yè)模式、變現(xiàn)機(jī)會(huì)能走多遠(yuǎn),導(dǎo)致面對(duì)送到手上的機(jī)會(huì)時(shí),遲遲不敢下注。
- 因過度追求構(gòu)建“長期可靠”的關(guān)系,而忽視在當(dāng)下接觸到的人,就無法通過一段段交織的關(guān)系,成長為更好的自己。
被評(píng)價(jià)“這個(gè)人想得清楚”,看起來是件好事。但有時(shí)也會(huì)因?yàn)楠q豫,錯(cuò)過一些機(jī)會(huì)。
很難區(qū)分保守與激進(jìn)、深思熟慮與開放靈活,孰對(duì)孰錯(cuò)。
但重點(diǎn)在于,決策的第一步不僅僅是靠直覺、喜好,而是先明確自己當(dāng)下最需要解決的問題是什么,盤算清自己愿意押注的籌碼底線。
比如現(xiàn)在有多少儲(chǔ)蓄,現(xiàn)在來看,最多愿意設(shè)置 xx 時(shí)間、金錢的止損線。再次之前要盡情探索自己創(chuàng)業(yè)可能性,到了止損階段后,即使回去上班,自己也能接受。
過度憂慮未來、不預(yù)分配當(dāng)前階段的籌碼,混亂地做出“明智、保護(hù)自己”的投資,是對(duì)流向自己的機(jī)會(huì)的不尊重。
——未來是很重要,投注成本是很珍貴,但也請(qǐng)多多珍惜當(dāng)下。
特別聲明:以上內(nèi)容(如有圖片或視頻亦包括在內(nèi))為自媒體平臺(tái)“網(wǎng)易號(hào)”用戶上傳并發(fā)布,本平臺(tái)僅提供信息存儲(chǔ)服務(wù)。
Notice: The content above (including the pictures and videos if any) is uploaded and posted by a user of NetEase Hao, which is a social media platform and only provides information storage services.