前篇回顧Agent 基礎(chǔ)篇 #01 從LLM到Agent →Agent 基礎(chǔ)篇 #02 四大核心機制上一篇建立了 Agent 的整體框架Agent LLM Planning Tool Use MemoryLilian Weng 的經(jīng)典分解加上 Reflection 作為第四大機制。這個公式看起來很簡潔但每個模塊展開之后都是一個獨立的工程領(lǐng)域。這篇把四個機制拆開逐個看它們在工程中到底在做什么、解決什么問題、有哪些經(jīng)典方案。不追求窮盡每個細節(jié)——后續(xù) RAG、MCP、Memory 系列會各自深入——而是要建立一張全景圖知道每個模塊的邊界在哪以及它們怎么協(xié)作。1. PlanningAgent 怎么拆解任務(wù)LLM 的一次推理只能生成一段文本。當(dāng)任務(wù)需要 10 步才能完成時Agent 不能一次性把 10 步全想出來然后一口氣執(zhí)行——它需要在執(zhí)行過程中不斷調(diào)整計劃。這就是 Planning 模塊要解決的問題。1.1 三種規(guī)劃策略的演進Planning 的發(fā)展經(jīng)歷了三個階段每個階段都在解決前一個階段的短板策略核心思路優(yōu)勢局限代表作Chain-of-ThoughtCoT單路徑逐步推理一步一步想簡單有效零額外開銷不能與外部工具交互走錯了無法回頭Wei et al., 2022Tree of ThoughtsToT多路徑搜索每一步探索多個分支并擇優(yōu)推理能力更強適合高價值決策計算成本高每步多次 LLM 調(diào)用Yao et al., 2023Plan-and-Execute先生成完整計劃再逐步執(zhí)行執(zhí)行中可以修正計劃全局視角支持步驟間依賴和并行規(guī)劃階段開銷大計劃可能因環(huán)境變化而失效LangGraph / HuggingGPT這三者的關(guān)系是遞進的CoT 解決能推理的問題ToT 解決推理質(zhì)量的問題Plan-and-Execute 解決推理與執(zhí)行結(jié)合的問題。工程選擇原則多數(shù)生產(chǎn)場景用 ReAct單步推理行動循環(huán)就夠了。ToT 適合錯誤代價極高的場景如金融決策Plan-and-Execute 適合步驟多且有依賴關(guān)系的任務(wù)如查數(shù)據(jù)庫 → 分析 → 寫報告 → 發(fā)郵件。不要在簡單任務(wù)上用重型規(guī)劃——規(guī)劃本身也有延遲和出錯的風(fēng)險。1.2 ReAct最廣泛使用的規(guī)劃模式上一篇已經(jīng)介紹過 ReAct 的 Thought → Action → Observation 循環(huán)。這里補充一個工程細節(jié)ReAct 的本質(zhì)是規(guī)劃與執(zhí)行交替進行——每一步 Thought 就是一次微型規(guī)劃決定下一步做什么Observation 則是從環(huán)境中獲取反饋用來修正后續(xù)計劃。這種模式的好處是靈活——不需要提前制定完整計劃可以邊走邊看。壞處是缺乏全局視角如果任務(wù)有 20 步Agent 可能走到第 10 步才發(fā)現(xiàn)一開始的方向就是錯的。1.3 Dream-SaaS 中的規(guī)劃Dream-SaaS 的 Supervisor 采用的是 Plan-and-Execute 的變體。Supervisor 在收到用戶請求后先做一次意圖分析和任務(wù)拆解決定需要調(diào)用哪些子 Agent、以什么順序執(zhí)行。執(zhí)行過程中如果某個子 Agent 返回的結(jié)果不符合預(yù)期比如代碼審查 Agent 發(fā)現(xiàn)了嚴重問題Supervisor 可以修改后續(xù)計劃——比如增加一輪修復(fù)驗證步驟。這比純 ReAct 更高效因為避免了每做一步都重新規(guī)劃全局的開銷也比靜態(tài) DAG 更靈活因為可以在運行時調(diào)整執(zhí)行路徑。2. Tool UseAgent 怎么擴展能力LLM 本身只能處理文本。要讓 Agent 查數(shù)據(jù)庫、調(diào) API、操作瀏覽器就需要 Tool Use 機制——讓模型能夠輸出結(jié)構(gòu)化的工具調(diào)用請求由外部系統(tǒng)執(zhí)行后把結(jié)果返回。2.1 從 Function Calling 到 MCP 的演進Tool Use 的發(fā)展可以分三個階段第一階段Function Calling2023OpenAI 在 GPT-3.5/4 中引入 Function Calling定義了工具調(diào)用的基本范式開發(fā)者用 JSON Schema 描述工具的輸入輸出格式模型在推理時輸出結(jié)構(gòu)化的調(diào)用請求應(yīng)用層執(zhí)行后把結(jié)果喂回模型。這個階段的問題每個平臺定義自己的工具格式——OpenAI 一套、Anthropic 一套、Google 一套。工具開發(fā)者需要為每個平臺寫不同的適配代碼N 個工具 × M 個平臺 N×M 個集成。第二階段Computer Use2024-2025Anthropic 的 Computer Use 讓 Agent 直接看屏幕截圖、計算鼠標(biāo)坐標(biāo)、點擊按鈕。范式轉(zhuǎn)變是不再需要為每個軟件寫專門 APIAgent 可以操作任何有圖形界面的軟件。但代價是速度慢、精度有限、風(fēng)險高——能點擊任何按鈕的 Agent也可能點錯按鈕。第三階段MCP 統(tǒng)一協(xié)議2024 至今Anthropic 在 2024 年 11 月發(fā)布 MCPModel Context Protocol定義了工具發(fā)布和發(fā)現(xiàn)的標(biāo)準(zhǔn)協(xié)議。工具開發(fā)者只需實現(xiàn)一次 MCP Server任何支持 MCP 的 ClientClaude、GPT、開源框架都能直接調(diào)用。N×M 的集成問題變成了 NM。階段時間范式核心問題Function Calling2023每個平臺自定義工具格式N×M 集成成本工具不可復(fù)用Computer Use2024-2025Agent 直接操作 GUI速度慢、精度低、安全風(fēng)險MCP2024 至今統(tǒng)一協(xié)議標(biāo)準(zhǔn)化NM 集成工具可復(fù)用可發(fā)現(xiàn)2.2 Tool Use 的工程挑戰(zhàn)即使有了 MCP 這樣的標(biāo)準(zhǔn)協(xié)議Tool Use 在工程中仍有幾個硬問題工具選擇準(zhǔn)確率當(dāng)可用工具超過 10 個時模型選錯工具的概率顯著上升。Anthropic 的解決方案是 Tool Search Tool——先讓模型搜索相關(guān)工具再調(diào)用而不是一次性把所有工具描述塞進 prompt。上下文污染工具返回的大量數(shù)據(jù)如一個 10MB 的日志文件會擠占上下文窗口把重要信息擠出去。Anthropic 在 2025 年底推出的 Programmatic Tool Calling 讓模型寫代碼來處理工具返回的數(shù)據(jù)只把摘要放回上下文。錯誤處理工具調(diào)用可能超時、返回錯誤、返回格式異常。Agent 需要有能力判斷工具調(diào)用失敗了并決定下一步——重試、換工具、還是放棄。Tool Use 的核心矛盾工具越多Agent 能力越強但工具選擇越容易出錯。這就是為什么給 Agent 加 50 個工具并不比加 5 個精準(zhǔn)的工具更好——工程上的關(guān)鍵是工具描述的質(zhì)量和選擇策略而不是數(shù)量。2.3 Spring AI 中的 Tool 定義示例Tool(description 搜索知識庫中的相關(guān)文檔) public ListDocument searchKnowledgeBase( Param(query) String query, Param(topK) int topK ) { return knowledgeBaseService.search(query, topK); }Spring AI 的Tool注解讓工具定義變得聲明式——只需描述工具做什么、接受什么參數(shù)框架負責(zé)生成 JSON Schema 并注冊到 Agent。MCP 協(xié)議則進一步把這個注冊過程標(biāo)準(zhǔn)化讓工具可以跨框架復(fù)用。3. MemoryAgent 怎么記住經(jīng)驗LLM 本身沒有記憶——每次 API 調(diào)用都是獨立的模型不記得上一輪對話。但一個有用的 Agent 需要記住用戶偏好、歷史操作、過去的錯誤。這就是 Memory 模塊的職責(zé)。3.1 三層記憶架構(gòu)參照認知科學(xué)的記憶分層Agent 的記憶系統(tǒng)通常分為三層層級對應(yīng)認知科學(xué)存儲位置內(nèi)容生命周期工作記憶工作記憶Working Memory上下文窗口當(dāng)前對話歷史 當(dāng)前任務(wù)狀態(tài) 檢索到的相關(guān)記憶單次會話短期記憶短期記憶Short-term Memory外部存儲Redis / DB最近幾輪對話的摘要、用戶最近的操作跨會話定期清理長期記憶長期記憶Long-term Memory向量數(shù)據(jù)庫 結(jié)構(gòu)化存儲用戶偏好、歷史經(jīng)驗、學(xué)到的知識永久工作記憶就是上下文窗口本身容量有限4K-200K tokens會話結(jié)束就消失。短期記憶是對近期信息的壓縮和摘要存儲在外部系統(tǒng)中。長期記憶是持久化的經(jīng)驗和知識需要通過檢索才能加載到工作記憶中。3.2 記憶的工程實現(xiàn)三層記憶聽起來簡單工程實現(xiàn)中有幾個關(guān)鍵決策什么該記、什么不該記如果什么都記存儲會迅速膨脹檢索也會變慢。Agent 需要判斷哪些信息值得長期保存。通常的做法是讓 LLM 在每輪對話結(jié)束后做一次記憶提取——從對話中抽取關(guān)鍵事實、用戶偏好、重要決策存入長期記憶。怎么檢索長期記憶存儲在向量數(shù)據(jù)庫中通過語義相似度檢索。但純語義檢索不夠——用戶問上次那個項目怎么樣了需要的是時間最近的相關(guān)記憶而不是語義最相似的記憶。生產(chǎn)級系統(tǒng)通常采用混合檢索語義相似度 時間衰減 重要性權(quán)重的加權(quán)組合。怎么遺忘記憶不是越多越好。過時的信息會干擾檢索質(zhì)量。成熟的記憶系統(tǒng)需要定期清理、合并和壓縮——把多條相關(guān)記憶合并為一條摘要淘汰長期未訪問的記憶。Dream-SaaS 的記憶分層工作記憶 當(dāng)前對話上下文 從向量庫檢索的相關(guān)記憶片段短期記憶 近 7 天的對話摘要Redis 存儲自動過期長期記憶 用戶偏好 ProfilePostgreSQL 知識向量庫Qdrant。記憶提取通過專門的 Memory Agent 執(zhí)行在每輪對話結(jié)束后異步運行。具體實現(xiàn)在本系列的 Memory 篇中詳細展開。3.3 記憶的 Java 工程實現(xiàn)思路// 短期記憶Redis 存儲自動過期 Component public class ShortTermMemory { private final RedisTemplateString, String redis; public void saveSummary(String sessionId, String summary) { redis.opsForList().rightPush(session: sessionId, summary); redis.expire(session: sessionId, 7, TimeUnit.DAYS); } public ListString getRecentContext(String sessionId, int limit) { return redis.opsForList().range(session: sessionId, -limit, -1); } } // 長期記憶向量數(shù)據(jù)庫 結(jié)構(gòu)化存儲 Component public class LongTermMemory { private final QdrantClient qdrant; // 語義檢索 private final UserProfileRepository repo; // 結(jié)構(gòu)化查詢 public void storeMemory(MemoryEntry entry) { // 向量化存儲語義檢索用 qdrant.upsert( entry.getId(), embeddingService.embed(entry.getContent()), entry.getMetadata() ); // 結(jié)構(gòu)化存儲精確查詢用 repo.save(entry); } public ListMemoryEntry retrieve(String query, int topK) { float[] queryVec embeddingService.embed(query); return qdrant.search(queryVec, topK); } }4. ReflectionAgent 怎么從錯誤中學(xué)習(xí)前三個機制解決的是怎么做的問題Reflection 解決的是怎么做得更好。一個沒有反思能力的 Agent每次犯同樣的錯誤有反思能力的 Agent能從失敗中提取經(jīng)驗避免重蹈覆轍。4.1 Reflexion把失敗變成語言化的經(jīng)驗Reflection 的經(jīng)典實現(xiàn)是 Shinn et al.NeurIPS 2023提出的Reflexion框架。它的核心思路很直白Agent 執(zhí)行任務(wù)失敗后不是簡單地重試而是先讓 LLM 分析失敗原因生成一段自然語言的自我反思如上次失敗是因為沒有檢查變量是否在使用前初始化然后把這段反思存入記憶在下次嘗試時注入到 prompt 中。執(zhí)行任務(wù) → 評估結(jié)果 → 失敗 ├─ 是 → 生成反思文本 → 存入記憶 → 帶著反思重試 └─ 否 → 返回結(jié)果Reflexion 的實驗數(shù)據(jù)很說明問題在 HumanEval 編程基準(zhǔn)上Reflexion 的 pass1 達到 91%而 GPT-4 直接生成只有 80%。在 HotPotQA 多跳問答上準(zhǔn)確率提升了約 20 個百分點。4.2 反思的工程挑戰(zhàn)Reflexion 的思路清晰但工程實現(xiàn)中有幾個陷阱反思幻覺2025 年的研究發(fā)現(xiàn)LLM 的自我反思有時會生成看起來合理但實際錯誤的分析——模型編造了一個失敗原因然后基于這個錯誤原因去調(diào)整行為結(jié)果越改越差。這就是反思幻覺Reflection Hallucination。解決方案基于事實的反思。不能只讓模型憑空反思必須提供客觀的反饋信號——代碼的執(zhí)行錯誤日志、工具調(diào)用的返回值、環(huán)境的實際狀態(tài)。反思必須錨定在這些事實之上而不是模型的想象。反思的代價每次反思都需要額外的 LLM 調(diào)用。在延遲敏感的場景中如實時對話反思的開銷可能不可接受。實際工程中通常只在關(guān)鍵節(jié)點做反思如任務(wù)失敗、結(jié)果異常而不是每步都反思。常見誤區(qū)不是所有場景都需要 Reflection 模塊。如果任務(wù)的成功率已經(jīng)很高如 95%反思帶來的收益微乎其微反而增加了延遲和成本。Reflection 最有價值的場景是任務(wù)復(fù)雜、錯誤率高、且錯誤模式可歸納如代碼生成、多步推理、工具調(diào)用鏈。4.3 Dream-SaaS 中的反思Dream-SaaS 的代碼審查 Agent 實現(xiàn)了輕量級反思當(dāng)審查結(jié)果被用戶標(biāo)記為誤報時系統(tǒng)會將這次誤報的上下文代碼片段 審查意見 用戶反饋存入記憶。下次審查類似代碼時檢索這段記憶提醒 Agent 上次類似的代碼被判定為誤報注意避免。這不是完整的 Reflexion 框架但核心思路一致把失敗經(jīng)驗轉(zhuǎn)化為可檢索的記憶指導(dǎo)后續(xù)行為。// 輕量級反思誤報記憶存儲 public void onUserFeedback(ReviewResult result, String feedback) { if (false_positive.equals(feedback)) { // 存入誤報記憶下次遇到類似代碼時檢索 reflectionMemory.store( new ReflectionEntry( result.getCodeSnippet(), // 觸發(fā)誤報的代碼 result.getComment(), // Agent 給出的審查意見 此模式曾被誤判為問題代碼, // 反思結(jié)論 LocalDateTime.now() ) ); } }5. 四個機制怎么協(xié)作一張全景圖四個機制不是獨立運行的它們在一個完整的 Agent 執(zhí)行流程中緊密配合。用 Dream-SaaS 的 Supervisor 來舉例用戶請求 │ ▼ ┌─────────────────────────────────────────────┐ │ PlanningSupervisor 分析意圖拆解任務(wù) │ │ → 需要查知識庫 審查代碼 生成報告 │ └─────────────────────────────────────────────┘ │ ▼ ┌─────────────────────────────────────────────┐ │ Memory檢索用戶偏好 歷史上下文 │ │ → 該用戶偏好簡潔風(fēng)格上次類似的報告... │ └─────────────────────────────────────────────┘ │ ▼ ┌─────────────────────────────────────────────┐ │ Tool Use并行調(diào)用子 Agent 和工具 │ │ → KnowledgeBaseAgent CodeReviewAgent │ │ → 各 Agent 通過 MCP 調(diào)用底層工具 │ └─────────────────────────────────────────────┘ │ ▼ ┌─────────────────────────────────────────────┐ │ Reflection匯總結(jié)果檢查質(zhì)量 │ │ → 審查結(jié)果是否完整是否需要補充 │ │ → 如有問題回到 Planning 修正計劃 │ └─────────────────────────────────────────────┘ │ ▼ 返回最終結(jié)果機制角色對應(yīng)本系列Planning決定做什么、怎么做、什么順序編排篇本文 下篇Tool Use執(zhí)行具體操作與外部世界交互MCP 系列已發(fā)布Memory提供上下文和經(jīng)驗指導(dǎo)決策Memory 系列已發(fā)布Reflection檢查結(jié)果質(zhì)量從錯誤中學(xué)習(xí)后續(xù)專題6. 總結(jié)四個核心機制——Planning、Tool Use、Memory、Reflection——構(gòu)成了 Agent 的完整能力棧。Planning 決定做什么Tool Use 提供執(zhí)行能力Memory 提供經(jīng)驗和上下文Reflection 確保質(zhì)量并持續(xù)改進。機制核心問題經(jīng)典方案工程要點Planning怎么拆解復(fù)雜任務(wù)CoT → ToT → Plan-and-Execute簡單任務(wù)用 ReAct復(fù)雜任務(wù)用 Plan-and-ExecuteTool Use怎么擴展 Agent 能力Function Calling → MCP工具質(zhì)量 數(shù)量注意上下文污染Memory怎么跨會話記住經(jīng)驗工作/短期/長期三層記憶混合檢索 定期遺忘Reflection怎么從錯誤中學(xué)習(xí)Reflexion 框架必須錨定事實避免反思幻覺理解這四個機制的關(guān)鍵不在于記住每個算法的細節(jié)而在于理解它們各自解決什么問題、邊界在哪里、怎么協(xié)作。有了這張全景圖再去看后續(xù)每個系列的深入展開就知道它在整個架構(gòu)中扮演什么角色。下篇預(yù)告《深入理解 AI Agent七從單 Agent 到多 Agent——為什么一個不夠》深入理解 AI Agent · AGENT 基礎(chǔ)篇 #02作者宋哥 | Java 后端 → AI Agent 工程師項目Dream-SaaS · 多 Agent 協(xié)作平臺有問題評論區(qū)見歡迎交流~參考資料[1] Lilian Weng, LLM Powered Autonomous Agents https://lilianweng.github.io/posts/2023-06-23-agent[2] Wei et al., Chain-of-Thought Prompting Elicits Reasoning in Large Language Models, NeurIPS 2022 [2201.11903] Chain-of-Thought Prompting Elicits Reasoning in Large Language Models[3] Yao et al., Tree of Thoughts: Deliberate Problem Solving with Large Language Models, NeurIPS 2023 https://arxiv.org/abs/2305.10601[4] Yao et al., ReAct: Synergizing Reasoning and Acting in Language Models, ICLR 2023 [2210.03629] ReAct: Synergizing Reasoning and Acting in Language Models[5] Shinn et al., Reflexion: Language Agents with Verbal Reinforcement Learning, NeurIPS 2023 https://arxiv.org/abs/2303.11366[6] Anthropic, The Model Context Protocol Introducing the Model Context Protocol \ Anthropic[7] Anthropic, Introducing advanced tool use on the Claude Developer Platform Introducing advanced tool use on the Claude Developer Platform \ Anthropic[8] Lei Wang et al., A survey on large language model based autonomous agents, Frontiers of Computer Science 2024[9] Zylos AI, Agent Self-Correction: From Reflexion to Process Reward Models Agent Self-Correction: From Reflexion to Process Reward Models | Zylos Research[10] Taskade, How LLMs Got Hands: The History of Tool Use and Function Calling How LLMs Got Hands: A History of Tool Use (2026)