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