前言

你盼世界，我盼望你無(wú) bug。Hello 大家好！我是霖呆呆。

目前各種 Agent 產(chǎn)品層出不窮。我自己也用了一段時(shí)間的 Claude Code，用著用著就產(chǎn)生了一個(gè)疑問(wèn)：

這些 Agent 到底是怎么"思考"的？它憑什么知道該調(diào)哪個(gè)工具？它怎么記住我之前說(shuō)的話？

帶著這些問(wèn)題，我系統(tǒng)地學(xué)習(xí)了 AI Agent 的 10 個(gè)核心概念，從最基礎(chǔ)的"Agent 核心循環(huán)"一直學(xué)到"編排框架選型"。

這篇文章就是我整個(gè)學(xué)習(xí)過(guò)程的總結(jié)，會(huì)用大量實(shí)際場(chǎng)景來(lái)幫你理解這些概念。如果你也在用 Agent 工具但對(duì)背后的原理一頭霧水，這篇文章應(yīng)該能幫到你

一、Agent 核心循環(huán)：Perceive → Think → Act → Observe

學(xué) Agent 的第一步，就是搞清楚它到底在干嘛。

大家可能也知道，Agent 發(fā)展至今，已經(jīng)不僅僅停留在"你問(wèn)它答"了。一個(gè)真正的 Agent 在工作時(shí)，一直在跑一個(gè)四步循環(huán)：

Perceive（感知）→ Think（思考）→ Act（行動(dòng)）→ Observe（觀察）
          ↑                                          |
          └──────────────────────────────────────────┘

來(lái)看個(gè)例子：

你讓 Agent 幫你翻譯一份 PDF 文檔：

看到?jīng)]，Agent 不是一條線走到底的，而是在不斷循環(huán)。每一次 Observe 之后都會(huì)回到 Think，重新審視當(dāng)前狀態(tài)。

最容易踩的坑：Think 缺失導(dǎo)致死循環(huán)

如果一個(gè) Agent 陷入了死循環(huán)，第一反應(yīng)不應(yīng)該是"加個(gè)重試上限"，而是要問(wèn)：它的 Think 步驟是不是出了問(wèn)題？

來(lái)看個(gè)反面案例：

Agent 在翻譯完 PDF 后，沒(méi)有經(jīng)過(guò) Think 步驟來(lái)判斷"翻譯結(jié)果是否可以返回給用戶了"，而是直接又回到 Perceive，把翻譯結(jié)果當(dāng)成新的輸入，開(kāi)始翻譯"翻譯后的內(nèi)容"... 然后無(wú)限循環(huán) 

翻譯 PDF → 拿到結(jié)果 → 沒(méi)有思考"是否完成" → 又去翻譯 → 又拿到結(jié)果 → ...

這不是"缺少重試上限"的問(wèn)題——那只是工程層面的補(bǔ)救。根本原因是 Think 步驟缺失，Agent 沒(méi)有在 Observe 之后停下來(lái)思考："我到底做完了沒(méi)有？"

這個(gè)區(qū)分很重要：Think 決定"做什么"，重試上限決定"做多久"。兩者缺一不可。

二、工具調(diào)用機(jī)制：Function Calling 與 MCP

搞清楚了核心循環(huán)，下一個(gè)問(wèn)題來(lái)了：循環(huán)中的 Act 步驟，Agent 是怎么"動(dòng)手"的？

這里涉及兩個(gè)容易混淆的概念：Function Calling（函數(shù)調(diào)用） 和 MCP（Model Context Protocol）。

Function Calling：LLM 的"表達(dá)方式"

LLM 自己是不能執(zhí)行代碼的，它本質(zhì)上只是在"生成文本"。那它怎么調(diào)工具呢？

答案是：LLM 輸出一段結(jié)構(gòu)化的 JSON，告訴宿主程序"我想調(diào)這個(gè)工具"：

{
  "tool": "get_weather",
  "parameters": {
    "city": "上海"
  }
}

這就是 Function Calling——LLM 用結(jié)構(gòu)化數(shù)據(jù)表達(dá)調(diào)用意圖，但它自己不執(zhí)行。

MCP：宿主側(cè)的"連接協(xié)議"

MCP 是宿主程序（比如 Claude Code）用來(lái)管理和連接外部工具服務(wù)器的協(xié)議。它解決的是"工具從哪來(lái)、怎么調(diào)"的問(wèn)題。

它們的關(guān)系

LLM 輸出 Function Call → Host 解析 → 通過(guò) MCP（或其他方式）路由到具體工具 → 執(zhí)行 → 結(jié)果返回給 LLM

這里有個(gè)關(guān)鍵理解：從 LLM 的角度看，所有工具長(zhǎng)得都一樣。無(wú)論這個(gè)工具是內(nèi)置的還是通過(guò) MCP 配置的，LLM 都是輸出同樣格式的 Function Call。至于工具到底是內(nèi)置的還是 MCP 的，那是 Host 層面的事。

好吧，用人話說(shuō)就是 ：

• Function Calling = LLM 的"嘴"（表達(dá)意圖）
• MCP = Host 的"手"（連接和執(zhí)行工具）

工具描述的質(zhì)量決定一切 

LLM 怎么知道該調(diào)哪個(gè)工具？答案是靠工具描述。對(duì)比一下：

// ? 模糊的描述
name: "data_processor"
description: "處理數(shù)據(jù)"

// ? 精準(zhǔn)的描述
name: "csv_to_json_converter"
description: "將 CSV 格式的文本轉(zhuǎn)換為 JSON 數(shù)組，
每一行成為數(shù)組中的一個(gè)對(duì)象，首行作為字段名"

第一個(gè)描述太泛了——"處理數(shù)據(jù)"？處理什么數(shù)據(jù)？怎么處理？LLM 看到這種描述基本是蒙圈的。第二個(gè)描述就很明確，LLM 知道遇到 CSV 轉(zhuǎn) JSON 的需求時(shí)該調(diào)它。

記?。汗ぞ呙枋霾皇菍?xiě)給人看的注釋?zhuān)菍?xiě)給 LLM 看的"使用說(shuō)明書(shū)"。

三層安全設(shè)計(jì)

工具調(diào)用涉及到安全問(wèn)題，比如"發(fā)郵件"這種不可逆操作。完整的安全設(shè)計(jì)有三層：

1. 工具描述約束：在工具描述中寫(xiě)明"調(diào)用前必須和用戶確認(rèn)內(nèi)容"
2. LLM Think 評(píng)估：LLM 在 Think 步驟判斷"這個(gè)操作是否需要確認(rèn)"
3. Host 攔截：宿主程序?qū)Ω唢L(fēng)險(xiǎn)操作彈出確認(rèn)提示

三層防線，缺一不可

三、規(guī)劃與任務(wù)分解：Agent 怎么把大任務(wù)拆小

如果你用 Claude Code 幫你做一個(gè)博客項(xiàng)目，你會(huì)發(fā)現(xiàn)它不會(huì)上來(lái)就開(kāi)始寫(xiě)代碼。它會(huì)先做一件事：規(guī)劃。

列出需求點(diǎn)、確定技術(shù)棧、規(guī)劃頁(yè)面結(jié)構(gòu)、拆出任務(wù)清單——每一項(xiàng)都是具體要執(zhí)行的步驟。

帶依賴(lài)關(guān)系的拆解

關(guān)鍵不是簡(jiǎn)單列個(gè) TODO list，而是要搞清楚任務(wù)之間的依賴(lài)：

任務(wù) 1: 初始化項(xiàng)目        → 無(wú)依賴(lài)
任務(wù) 2: 搭建頁(yè)面布局      → 依賴(lài)任務(wù) 1
任務(wù) 3: 實(shí)現(xiàn)暗黑模式      → 依賴(lài)任務(wù) 2
任務(wù) 4: 寫(xiě)單元測(cè)試         → 依賴(lài)任務(wù) 2、3

為什么依賴(lài)關(guān)系這么重要？三個(gè)原因：

1. Agent 知道執(zhí)行順序
2. 保證依賴(lài)任務(wù)完成后才執(zhí)行下游任務(wù)
3. 在多 Agent 模式下，能知道哪些任務(wù)可以并行分配

兩種執(zhí)行策略

實(shí)際的 Agent 更偏向交替式。因?yàn)榫退阋?guī)劃得再好，執(zhí)行過(guò)程中也可能遇到突發(fā)情況——比如執(zhí)行到第 3 步發(fā)現(xiàn) Next.js 版本不支持某個(gè)暗黑模式方案，這時(shí)候 Agent 需要重新審視整個(gè)計(jì)劃，調(diào)整方案再繼續(xù)執(zhí)行。

還有一個(gè)容易忽略的點(diǎn)：探索先于規(guī)劃！

比如要重構(gòu)一個(gè)認(rèn)證模塊，Agent 不應(yīng)該上來(lái)就寫(xiě)計(jì)劃。而是先審視一下項(xiàng)目現(xiàn)有的認(rèn)證模塊——看能不能改、改了影響多大——然后再做規(guī)劃。

四、記憶系統(tǒng)：短期、長(zhǎng)期、工作記憶

Agent 怎么"記住"東西？這里有三種截然不同的記憶類(lèi)型

三種記憶

這三者最容易搞混的是長(zhǎng)期記憶和工作記憶。

來(lái)個(gè)場(chǎng)景幫你區(qū)分：

一個(gè)客服 Agent，用戶打來(lái)電話說(shuō)"耳機(jī)壞了要退貨"。Agent 承諾 3 天內(nèi)處理。

三天后用戶又打來(lái)問(wèn)進(jìn)度。

這時(shí)候 Agent 需要知道"之前承諾了 3 天內(nèi)處理"這個(gè)信息——它應(yīng)該存在哪種記憶里？

答案是長(zhǎng)期記憶。因?yàn)檫@個(gè)信息需要跨對(duì)話保留。工作記憶不行，因?yàn)樗谏弦淮螌?duì)話結(jié)束時(shí)就被丟棄了。

區(qū)分標(biāo)準(zhǔn)很簡(jiǎn)單：需要跨對(duì)話保留的 → 長(zhǎng)期記憶。只在當(dāng)前任務(wù)中有用的 → 工作記憶。

五、上下文窗口管理：Agent 的"內(nèi)存管理"

LLM 的上下文窗口是有限的（就像你電腦的內(nèi)存）。一個(gè)處理大型項(xiàng)目的 Agent，不可能把所有文件都塞進(jìn)上下文里。

那怎么辦？這里有幾個(gè)核心策略：

策略一：按需加載

不一次性讀所有文件，而是先搜索定位，再精確讀取。

比如 Claude Code 修一個(gè) bug，它的做法是：

1. 先用 grep 搜索關(guān)鍵詞，找到 3 個(gè)相關(guān)文件
2. 只讀取這 3 個(gè)文件的內(nèi)容
3. 修改完成

而不是把整個(gè)項(xiàng)目的 50 個(gè)文件全部讀一遍。

策略二：摘要壓縮

對(duì)話太長(zhǎng)時(shí)，把早期的對(duì)話內(nèi)容壓縮成摘要，保留關(guān)鍵信息，釋放上下文空間。

策略三：子 Agent 分擔(dān)

把任務(wù)拆給子 Agent 處理，每個(gè)子 Agent 有自己獨(dú)立的上下文窗口。這樣就把一個(gè)大的上下文需求分散到了多個(gè)小窗口里。

策略四：避免冗余

已經(jīng)知道的信息不要重復(fù)加載。比如 Claude Code 編輯完一個(gè)文件后，不會(huì)重新讀取這個(gè)文件——因?yàn)榫庉嫷膬?nèi)容已經(jīng)在上下文里了，再讀一次就是加載重復(fù)信息。

"避免冗余"和"摘要壓縮"不是一回事！

• 避免冗余：不加載重復(fù)信息
• 摘要壓縮：把已有信息壓縮變短

前者是"不加"，后者是"縮短"。我之前就搞混過(guò) 

六、ReAct 范式：邊想邊做的藝術(shù)

ReAct = Reason + Act。它和核心循環(huán)是什么關(guān)系？

核心循環(huán)是通用的設(shè)計(jì)模式，ReAct 是具體的實(shí)現(xiàn)方法。

就像"組件化"是通用的前端思想，React 是實(shí)現(xiàn)組件化的具體框架。你不會(huì)說(shuō)"組件化是 React 的改良版"對(duì)吧 

ReAct 之前的兩種做法

ReAct 的創(chuàng)新就是把兩者結(jié)合——Thought 和 Action 交替進(jìn)行：

Thought: 我需要先確認(rèn)《三體》的作者，不能憑記憶猜
Action: search("三體 作者")
Observation: 劉慈欣
Thought: 確認(rèn)是劉慈欣，接下來(lái)搜他的其他作品
Action: search("劉慈欣 其他作品")
Observation: 《球狀閃電》《流浪地球》

ReAct 的兩大核心價(jià)值

1. 自我糾錯(cuò)

當(dāng)搜索失敗時(shí)，Thought 步驟讓 Agent 能反思原因并調(diào)整策略：

Thought: 我需要先確認(rèn)作者
Action: search("三體 作者")
Observation: 沒(méi)有找到相關(guān)結(jié)果
Thought: 搜索失敗了，可能是關(guān)鍵詞不對(duì)，換個(gè)方式試試
Action: search("《三體》 科幻小說(shuō) 作者是誰(shuí)")
Observation: 劉慈欣

如果是 Action-only 模式，搜索失敗后 Agent 可能直接跳到下一步，或者傻乎乎地告訴你"找不到" 

2. 可追溯性（Traceability）

每一步推理都顯式輸出，開(kāi)發(fā)者能看到 Agent "在想什么"。出了問(wèn)題可以精確定位到哪一步的推理出了錯(cuò)。

其實(shí)你在 Claude Code 里已經(jīng)見(jiàn)過(guò)了——Agent 在每次調(diào)用工具前輸出的那些分析和推理文字（比如"讓我先搜索一下相關(guān)文件"），就是 ReAct 中 Thought 的體現(xiàn)

什么時(shí)候不需要 ReAct？

流程固定、沒(méi)有不確定性的任務(wù)不需要。

比如"每天早上查天氣 → 格式化 → 發(fā)通知"，這種固定流水線甚至不需要 LLM 來(lái)編排，一個(gè)定時(shí)腳本就夠了。ReAct 的價(jià)值在于應(yīng)對(duì)不確定性，固定流程用它反而是浪費(fèi) token

七、多 Agent 協(xié)作：一個(gè)人干不完就叫幫手

到目前為止我們聊的都是單個(gè) Agent 的能力。但當(dāng)任務(wù)變復(fù)雜了，一個(gè) Agent 就不太夠用了。

為什么需要多 Agent？

兩種協(xié)作架構(gòu)

中心編排（Orchestrator）：

        [主 Agent]
       /    |     \
  后端Agent  前端Agent  測(cè)試Agent

主 Agent 負(fù)責(zé)分配任務(wù)、收集結(jié)果、協(xié)調(diào)信息。子 Agent 之間不直接通信。

去中心化（Peer-to-peer）：

  后端Agent ←→ 前端Agent
      ?            ?
     測(cè)試Agent ←→ ...

Agent 之間直接通信，通過(guò)共享狀態(tài)來(lái)同步。

Claude Code 用的是哪種？

中心編排。 Claude Code 有一個(gè)主 Agent 做全局把控，spawn 出子 Agent 來(lái)并行處理任務(wù)。子 Agent 之間不直接通信，所有信息流經(jīng)主 Agent。

為什么選這種？因?yàn)橹?Agent 能統(tǒng)一調(diào)度——當(dāng)后端 Agent 改了 API 字段名，主 Agent 可以通知前端 Agent 和測(cè)試 Agent 同步修改。如果是去中心化的，這個(gè)信息同步就會(huì)很混亂。

中心編排的代價(jià)

主 Agent 會(huì)成為瓶頸——所有信息都要經(jīng)過(guò)它，帶來(lái)額外的 token 消耗和延遲。所以實(shí)際使用中，主 Agent 不會(huì)讓子 Agent 匯報(bào)每一個(gè)細(xì)節(jié)，而是只收集關(guān)鍵結(jié)果和變更 ??

八、錯(cuò)誤處理與自我糾正：Agent 犯錯(cuò)了怎么辦

Agent 不是萬(wàn)能的，它會(huì)犯錯(cuò)。關(guān)鍵是怎么發(fā)現(xiàn)錯(cuò)誤和怎么處理錯(cuò)誤。

三類(lèi)錯(cuò)誤信號(hào)來(lái)源

需要注意的是，這里的可靠性指的是信號(hào)的確定性——環(huán)境反饋是程序化的確定結(jié)果， 而人類(lèi)反饋可能存在表述模糊的情況。但在意圖判斷層面，人類(lèi)反饋的權(quán)威性是最高的。

四種應(yīng)對(duì)策略（從輕到重）

還記得核心循環(huán)里的 Think 嗎？這里又用上了：

Think 決定"做什么"，重試上限決定"做多久"。 沒(méi)有 Think，Agent 會(huì)盲目重試同樣的操作；沒(méi)有重試上限，即使有 Think 也可能無(wú)限嘗試。兩者缺一不可！

實(shí)際中，一個(gè)錯(cuò)誤可能需要組合使用多種策略。比如執(zhí)行 npm install 報(bào)磁盤(pán)空間不足，Agent 可能需要先清理緩存（換方式重試），但清理磁盤(pán)屬于有風(fēng)險(xiǎn)的操作，又需要先問(wèn)用戶（升級(jí)求助）。

九、安全與對(duì)齊：給 Agent 裝上"剎車(chē)"

Agent 能力越強(qiáng)，越需要安全約束。這不是可選的，是必須的

風(fēng)險(xiǎn)分級(jí)權(quán)限模型

如果你用過(guò) Claude Code，應(yīng)該對(duì)此很熟悉——讀文件不問(wèn)你，執(zhí)行 Bash 命令會(huì)彈確認(rèn)。

四層防御（Defense in Depth）

這是整個(gè)安全設(shè)計(jì)中最重要的概念

核心原則是：每一層都不能完全信任上一層。

即使模型層沒(méi)攔?。ū?prompt injection 繞過(guò)了），工具層可以攔；工具層也沒(méi)攔住，系統(tǒng)層可以攔；系統(tǒng)層也漏了，還有人類(lèi)做最后把關(guān)。

如果你做過(guò)前端，這個(gè)思路你一定不陌生——輸入校驗(yàn)就是一樣的：

用戶輸入 → 前端表單校驗(yàn) → API 參數(shù)校驗(yàn) → 數(shù)據(jù)庫(kù)約束（NOT NULL、UNIQUE）

每一層都不信任上一層已經(jīng)校驗(yàn)過(guò)了。這就是多層防御的精髓

十、編排框架與實(shí)戰(zhàn)選型：用什么工具來(lái)造 Agent

學(xué)完了 9 個(gè)核心概念，理論上你完全可以從零寫(xiě)一個(gè) Agent 了。但正如你不會(huì)用原生 JS 從頭擼一個(gè)大型應(yīng)用一樣——有框架幫你封裝好了通用的能力，何必自己造輪子

三個(gè)層級(jí)

選型指南

選底層 SDK： 需要極致控制力，團(tuán)隊(duì)技術(shù)能力強(qiáng)。比如 Anthropic 的 Claude Code，它的核心循環(huán)、上下文管理、權(quán)限系統(tǒng)、hook 機(jī)制都是從底層直接構(gòu)建的——這種高度定制的場(chǎng)景，就適合在 SDK 層級(jí)或更底層去實(shí)現(xiàn)。

選編排框架： 有開(kāi)發(fā)能力的團(tuán)隊(duì)，想利用框架的核心抽象（Agent、Tool、Memory）快速搭建，同時(shí)保留一定的靈活性和可擴(kuò)展性。

選低代碼平臺(tái)： 不懂開(kāi)發(fā)的人員也能用可視化方式搭工作流，或者需要快速驗(yàn)證想法。比如一個(gè)運(yùn)營(yíng)同學(xué)想搭個(gè)"每天自動(dòng)總結(jié)新聞發(fā)到飛書(shū)群"的工作流，用 Dify 拖拖拽拽就行了。

一個(gè)有趣的趨勢(shì)：

當(dāng)前 Agent 領(lǐng)域還在快速演化，底層 SDK 的使用率在上升。因?yàn)楹芏嗑幣趴蚣艿某橄髮臃炊闪讼拗?mdash;—Agent 的行為很難被預(yù)定義的流程圖完全覆蓋。Anthropic 官方推薦的做法就是用輕量 SDK + 簡(jiǎn)單代碼編排，而不是引入重型框架。

這就像前端早期——很多人覺(jué)得必須用框架，后來(lái)發(fā)現(xiàn)對(duì)于很多場(chǎng)景，原生 JS + 輕量庫(kù)反而更合適

后語(yǔ)

知識(shí)無(wú)價(jià)，支持原創(chuàng)！這篇文章就介紹到這里。

整篇文章下來(lái)，我們從 Agent 最基礎(chǔ)的核心循環(huán)一路學(xué)到編排框架選型，10 個(gè)概念環(huán)環(huán)相扣：

• 核心循環(huán)是 Agent 的"心跳"
• 工具調(diào)用讓它能"動(dòng)手"
• 規(guī)劃讓它能"拆解問(wèn)題"
• 記憶讓它能"記住你"
• 上下文管理讓它能"高效工作"
• ReAct讓它能"邊想邊做"
• 多 Agent讓它能"叫幫手"
• 錯(cuò)誤處理讓它能"從失敗中恢復(fù)"
• 安全與對(duì)齊給它裝上"剎車(chē)"
• 編排框架提供"開(kāi)箱即用的工具箱"

到此這篇關(guān)于一文盤(pán)點(diǎn)Agent開(kāi)發(fā)入門(mén)必懂的10個(gè)核心概念的文章就介紹到這了,更多相關(guān)Agent核心概念內(nèi)容請(qǐng)搜索腳本之家以前的文章或繼續(xù)瀏覽下面的相關(guān)文章，希望大家以后多多支持腳本之家！

最新評(píng)論