LLM 和 Agent 的核心術(shù)語(yǔ)和原理

原文鏈接：https://labuladong.online/zh/ai-coding/basics/llm-and-agent/
更新時(shí)間：2026/04/28 12:24

很多讀者剛開(kāi)始用 AI 編程工具，經(jīng)常會(huì)有一個(gè)疑問(wèn)：Cursor、Antigravity 這些編輯器里也能選 Claude 模型，為什么目前來(lái)看還是 Claude Code 配合 Claude 模型的編程效果最好？

為什么 Qwen、DeepSeek 等國(guó)產(chǎn)模型也能支持在 Claude Code 里使用？和使用官方的 Claude 模型有什么區(qū)別？

如果你有這些疑問(wèn)，說(shuō)明你還沒(méi)搞清楚 LLM 和 Agent 之間的關(guān)系。

簡(jiǎn)單說(shuō)，AI 寫(xiě)代碼的效果同時(shí)取決于兩件事：LLM 模型本身的能力，以及圍繞模型的 Agent 工程實(shí)現(xiàn)。 兩者都?jí)驈?qiáng)，才能有最好的效果，任何一方拉胯，最終效果都不盡如人意。

我們說(shuō)的 Qwen、Claude、DeepSeek 等模型屬于 LLM，Cursor、Antigravity、Claude Code 等 AI 編程工具屬于 Agent。

這篇文章就來(lái)講清楚 LLM 和 Agent 分別是什么，它們之間是什么關(guān)系，讓你有一個(gè)具象化的理解。不涉及具體的 API 調(diào)用，只講原理。

1. LLM 的本質(zhì)：概率預(yù)測(cè)

大語(yǔ)言模型（LLM）的核心原理其實(shí)就一句話：根據(jù)已有的文本，預(yù)測(cè)下一個(gè) token 出現(xiàn)的概率。

這里的 token 是模型處理文本的最小單位，一個(gè) token 大約相當(dāng)于一個(gè)漢字或半個(gè)英文單詞。后面我們會(huì)頻繁提到 token 這個(gè)概念，你可以先簡(jiǎn)單理解為「一小段文字」。

比如你輸入「今天天氣」，模型會(huì)計(jì)算所有可能的下一個(gè)字的概率分布：「真」的概率 30%，「不」的概率 20%，「很」的概率 15%……然后從中選一個(gè)輸出。選完之后，把這個(gè)字拼到輸入后面，繼續(xù)預(yù)測(cè)下一個(gè)字，如此反復(fù)，就生成了一段完整的文本。

所以 LLM 本質(zhì)上就是一個(gè)概率模型，一個(gè)字一個(gè)字地往外蹦。

你跟 ChatGPT 聊天時(shí)看到回答一個(gè)字一個(gè)字地出現(xiàn)，不是為了打字機(jī)效果。這就是它真實(shí)的工作方式。

你可能會(huì)問(wèn)：這也太簡(jiǎn)單了，就靠猜下一個(gè)字，怎么能寫(xiě)出那么流暢、那么「有道理」的回答？

關(guān)鍵在于規(guī)模效應(yīng)。 當(dāng)模型的參數(shù)量大到幾百億、上千億，訓(xùn)練數(shù)據(jù)覆蓋了海量文本，這個(gè)「概率預(yù)測(cè)」就變得驚人地準(zhǔn)確。準(zhǔn)確到讓人覺(jué)得它真的「理解」了你在說(shuō)什么。

但要注意，它并不真的理解，只是在做統(tǒng)計(jì)意義上的模式匹配。

這就好比一個(gè)人把所有棋譜都背下來(lái)了。他可能并不「理解」圍棋的哲學(xué)，但下出的棋比大多數(shù)人都強(qiáng)。

還有一個(gè)參數(shù)叫溫度（temperature），控制模型選字時(shí)的隨機(jī)程度。溫度為 0 時(shí)，模型每次都選概率最大的那個(gè)字，輸出最確定。溫度調(diào)高，模型就更愿意選那些概率較低的字，輸出更有創(chuàng)意但也更不可控。

另一個(gè)重要的概念是上下文（Context）。模型在預(yù)測(cè)下一個(gè) token 時(shí)，依據(jù)的就是當(dāng)前上下文里的所有文本。你輸入的問(wèn)題、之前的對(duì)話歷史、系統(tǒng)給的背景設(shè)定，這些全部拼在一起就構(gòu)成了上下文。

舉個(gè)例子，你跟 ChatGPT 聊天，第一句說(shuō)「我叫小明」，然后聊了很多別的話題，最后突然問(wèn)「我叫什么名字」，它能正確回答「你叫小明」。

這不是因?yàn)樗赣涀　沽四愕拿?，而是因?yàn)椤肝医行∶鳌惯@句話還在上下文窗口里。模型每次生成回答時(shí)，都是依據(jù)整個(gè)上下文的內(nèi)容來(lái)預(yù)測(cè)下一個(gè) token 的，所以看起來(lái)它好像是「記住」了你的名字。

但上下文的容量肯定是有限的，我們一般稱這個(gè)容量為「上下文窗口」。超出窗口的內(nèi)容就需要被處理掉，常見(jiàn)的做法是壓縮：讓模型把早期的對(duì)話總結(jié)成一段摘要，保留重要信息，丟掉細(xì)節(jié)，從而騰出空間。

所以如果你和 ChatGPT 聊了特別長(zhǎng)的對(duì)話，再問(wèn)最開(kāi)頭的問(wèn)題，它可能就答不上來(lái)了。因?yàn)樵缙诘膶?duì)話已經(jīng)被擠出了上下文窗口，這就是我們常說(shuō)的「失憶了」。

目前主流模型的上下文窗口在 128K 到 1M token 之間，大約相當(dāng)于幾萬(wàn)到幾十萬(wàn)字。聽(tīng)起來(lái)很大，但后面你會(huì)看到，在 Agent 場(chǎng)景下這個(gè)空間消耗得非常快。

所以，最佳實(shí)踐是一個(gè)上下文窗口只聚焦處理一個(gè)問(wèn)題相關(guān)的對(duì)話，對(duì)于新的問(wèn)題就重新開(kāi)始一個(gè)新的上下文窗口。

2. 從「補(bǔ)全」到「對(duì)話」：Instruct 模型

如果你關(guān)注過(guò)開(kāi)源模型（比如 Llama、Qwen），會(huì)發(fā)現(xiàn)它們通常有兩個(gè)版本：一個(gè)叫 Base，一個(gè)叫 Instruct。這兩個(gè)版本的區(qū)別，恰好能幫你理解 LLM 是怎么從「補(bǔ)全引擎」變成「對(duì)話助手」的。

Base 模型就是我們上面說(shuō)的純概率預(yù)測(cè)模型。你輸入「中國(guó)的首都是」，它會(huì)接著往下寫(xiě)「北京，位于華北平原……」。這是在做文本補(bǔ)全。你輸入半句話，它幫你把后半句續(xù)上。

但你想想，我們用 ChatGPT 的時(shí)候，輸入「中國(guó)的首都是」，它會(huì)怎么回答？它不會(huì)幫你續(xù)寫(xiě)，而是會(huì)回答「中國(guó)的首都是北京」。它把你的輸入當(dāng)作了一個(gè)問(wèn)題來(lái)回答，而不是一段需要續(xù)寫(xiě)的文本。

這就是 Instruct 模型做的事情。在 Base 模型的基礎(chǔ)上，用大量的「指令-回答」數(shù)據(jù)對(duì)進(jìn)行微調(diào)（Fine-tuning），再通過(guò) RLHF（人類(lèi)反饋強(qiáng)化學(xué)習(xí)） 進(jìn)一步優(yōu)化。

RLHF 就是讓模型對(duì)同一個(gè)問(wèn)題生成多個(gè)回答，由人類(lèi)評(píng)審員打分排序，模型根據(jù)打分調(diào)整自己。經(jīng)過(guò)這兩步，模型就明白了：用戶輸入的不是需要你續(xù)寫(xiě)的文本，而是需要你響應(yīng)的指令。

所以我們平時(shí)用的 ChatGPT、Claude 這些，全都是 Instruct 模型。Base 模型雖然也很強(qiáng)，但它只會(huì)「接話」，不會(huì)「回答問(wèn)題」，直接拿來(lái)對(duì)話會(huì)很奇怪。

Instruct 版本的訓(xùn)練成本相比預(yù)訓(xùn)練階段要小得多，但效果上是質(zhì)的飛躍。它直接讓 LLM 從一個(gè)文本補(bǔ)全工具變成了可以對(duì)話的助手。

3. 思維鏈：讓模型「想清楚再說(shuō)」

LLM 有一個(gè)有趣的特性：如果你讓它直接給出答案，它可能會(huì)犯錯(cuò)；但如果讓它先把推理過(guò)程寫(xiě)出來(lái)，再給答案，準(zhǔn)確率會(huì)高很多。

這就是所謂的思維鏈（Chain of Thought，CoT）。比如你問(wèn)一道數(shù)學(xué)題「小明有 3 個(gè)蘋(píng)果，又買(mǎi)了 5 個(gè)，吃了 2 個(gè)，還剩幾個(gè)？」，模型如果直接蹦出一個(gè)數(shù)字，可能會(huì)出錯(cuò)。但如果它先寫(xiě)「3 + 5 = 8，8 - 2 = 6」，再回答「6 個(gè)」，就準(zhǔn)確多了。

這其實(shí)和我們?nèi)祟?lèi)做題一樣，做一道復(fù)雜的數(shù)學(xué)題，直接根據(jù)題意猜答案和在草稿紙上一步一步推演，正確率完全不同。

模型把思考過(guò)程「寫(xiě)出來(lái)」，等價(jià)于給自己打草稿，每一步的中間結(jié)果都成了后續(xù)推理的輸入，自然就更靠譜。

后來(lái)的推理模型（比如 OpenAI 的 o1/o3 系列、DeepSeek R1、Claude 的 extended thinking）把這個(gè)思路進(jìn)一步系統(tǒng)化了。模型不光會(huì)寫(xiě)推理過(guò)程，還會(huì)自我反思：先給出一個(gè)答案，再回頭檢查有沒(méi)有問(wèn)題，發(fā)現(xiàn)不對(duì)就修正。

這個(gè)就和我們做判斷的邏輯是類(lèi)似的，很多時(shí)候直覺(jué)不準(zhǔn)確，需要仔細(xì)思考一下才能得出正確的結(jié)論。

所以你在用 Claude 或 ChatGPT 時(shí)，有時(shí)候會(huì)看到模型在「思考」很久才回復(fù)。它就是在做這種多步推理和自我驗(yàn)證，本質(zhì)上是用更多的計(jì)算量來(lái)?yè)Q取更高的準(zhǔn)確率。

早期的推理模型是以「獨(dú)立模型」的形態(tài)出現(xiàn)的。各家廠商往往同時(shí)發(fā)布兩個(gè)版本，一個(gè)是普通對(duì)話模型（如 gpt-4o、DeepSeek V3），一個(gè)是推理模型（如 gpt-o1、DeepSeek R1）。開(kāi)發(fā)者要根據(jù)任務(wù)類(lèi)型選模型：簡(jiǎn)單問(wèn)題用對(duì)話模型省錢(qián)，復(fù)雜問(wèn)題用推理模型求解。

但這種二分法用起來(lái)很別扭，一個(gè) Agent 任務(wù)里可能既有簡(jiǎn)單的文件讀寫(xiě)，也有復(fù)雜的代碼調(diào)試推理，你總不能中途換模型吧？

所以從 2025 年下半年開(kāi)始，行業(yè)逐漸統(tǒng)一到了單一模型 + 思考強(qiáng)度參數(shù)的新范式。同一個(gè)模型既能快速回答，也能深度思考，開(kāi)發(fā)者通過(guò)一個(gè)參數(shù)控制它「想多久」。

各家的參數(shù)名略有不同（reasoning_effort、effort、thinkingLevel 等等），但思路一致：都是通過(guò)一個(gè)參數(shù)控制模型的思考強(qiáng)度。

強(qiáng)度調(diào)高，模型多花點(diǎn)時(shí)間反復(fù)推演；強(qiáng)度調(diào)低，直接給答案省 token。開(kāi)發(fā)者不用再糾結(jié)選哪個(gè)模型，一個(gè) API 調(diào)用按需調(diào)檔就行。

這個(gè)變化對(duì) AI 應(yīng)用的開(kāi)發(fā)也比較友好，以前在代碼里要維護(hù)兩套模型的調(diào)用邏輯（對(duì)話模型 vs 推理模型），現(xiàn)在一套代碼就夠了，復(fù)雜度低了很多。

4. System Prompt：設(shè)置「人設(shè)」

到目前為止，我們講的都是模型本身的能力：它怎么預(yù)測(cè) token、怎么理解指令、怎么做推理。但還有一個(gè)問(wèn)題：你怎么控制它的行為？

比如你希望模型用簡(jiǎn)潔的風(fēng)格回答，或者讓它扮演一個(gè)特定的角色，這些要求要寫(xiě)在哪里？

答案是 System Prompt。它是對(duì)話開(kāi)始前給模型的一段指令，會(huì)被拼到上下文的最前面。用戶在聊天界面里看不到這段文字，但模型每次生成回答時(shí)都能讀到它。

你可以把 System Prompt 理解為模型的「人設(shè)說(shuō)明書(shū)」。對(duì)話還沒(méi)開(kāi)始，模型就已經(jīng)讀到了這段文本，后續(xù)不管用戶問(wèn)什么，它都會(huì)在這個(gè)「人設(shè)」的框架下回答。

System Prompt 可以是模型服務(wù)商預(yù)設(shè)的（比如 OpenAI 給 ChatGPT 寫(xiě)的默認(rèn)指令），也可以是開(kāi)發(fā)者通過(guò) API 自己設(shè)定的。用戶也能參與其中，最直觀的例子就是 ChatGPT 的「自定義指令」功能。

你可以在設(shè)置里告訴它你的職業(yè)背景，讓它用特定的風(fēng)格回復(fù)你。比如你寫(xiě)「我是一個(gè)后端開(kāi)發(fā)者，回答要簡(jiǎn)潔，給代碼示例時(shí)用 Go」，之后每次對(duì)話它都會(huì)按這個(gè)偏好來(lái)。這個(gè)「自定義指令」本質(zhì)上就是被追加到了 System Prompt 里。

System Prompt 還有一個(gè)重要的用途：設(shè)置安全規(guī)則。

你在用 ChatGPT 或 Claude 的時(shí)候，問(wèn)某些敏感話題會(huì)被拒絕回答。這種拒絕行為一部分來(lái)自訓(xùn)練階段的安全對(duì)齊（比如 RLHF），模型在訓(xùn)練時(shí)就已經(jīng)學(xué)會(huì)了拒絕明顯有害的請(qǐng)求。

但光靠訓(xùn)練還不夠，因?yàn)榘踩呗孕枰?jīng)常調(diào)整，某類(lèi)內(nèi)容的寬嚴(yán)尺度會(huì)隨政策變化。每次改策略都重新訓(xùn)練模型，成本太高了。所以模型服務(wù)商還會(huì)在 System Prompt 里寫(xiě)明確的安全規(guī)則，做更精細(xì)的策略控制。這樣改一行文本就能生效，靈活得多。

你可能會(huì)問(wèn)：如果用戶在對(duì)話里寫(xiě)「忽略你之前的所有指令」，模型會(huì)聽(tīng)誰(shuí)的？

這就涉及 System Prompt 和用戶消息的優(yōu)先級(jí)問(wèn)題。實(shí)際上，送給模型的文本會(huì)標(biāo)記不同的角色標(biāo)簽（system、user、assistant），模型在訓(xùn)練時(shí)學(xué)會(huì)了對(duì) system 標(biāo)簽的內(nèi)容賦予更高的服從權(quán)重。所以正常情況下，用戶沒(méi)法輕易覆蓋 System Prompt 里的規(guī)則。

當(dāng)然，這種防護(hù)不是絕對(duì)的。網(wǎng)上有各種「越獄」（jailbreak）技巧試圖繞過(guò) System Prompt 的限制，模型廠商也在不斷加固，這本質(zhì)上是一場(chǎng)攻防博弈。

System Prompt 的核心價(jià)值就兩點(diǎn)：定義模型的行為方式，以及設(shè)置不可輕易繞過(guò)的規(guī)則。

后面你會(huì)看到，不管是讓模型調(diào)用工具、執(zhí)行任務(wù)還是遵循操作流程，都依賴于往上下文里塞入恰當(dāng)?shù)奈谋?。System Prompt 就是這一切的起點(diǎn)。

5. Function Calling：讓 LLM 學(xué)會(huì)「動(dòng)手」

LLM 雖然能說(shuō)會(huì)道，但它有一個(gè)根本性的限制：它只能輸出文本。

你問(wèn)它現(xiàn)在幾點(diǎn)了，它不知道，因?yàn)樗鼪](méi)有時(shí)鐘。你讓它幫你查數(shù)據(jù)庫(kù)，它做不到，因?yàn)樗B不上數(shù)據(jù)庫(kù)。它就像一個(gè)被關(guān)在房間里的超級(jí)大腦，知識(shí)淵博，能說(shuō)會(huì)道，但沒(méi)有手腳，做不了任何事情。

2023 年 6 月，OpenAI 發(fā)布了 Function Calling 功能，給這個(gè)「超級(jí)大腦」裝上了手腳。

比方說(shuō)你開(kāi)發(fā)了一個(gè)聊天機(jī)器人，你想讓模型在需要的時(shí)候自動(dòng)調(diào)用天氣查詢 API 來(lái)回答用戶的問(wèn)題。

第一步：你要把這個(gè)查詢天氣的 API 的描述塞進(jìn) System Prompt 里（上一節(jié)講過(guò)，它就是對(duì)話開(kāi)始前給模型的隱藏指令）。

比如你可以這樣寫(xiě)：

你是一個(gè)有用的助手。你有以下工具可以使用：

工具名稱：get_weather
功能描述：查詢指定城市的當(dāng)前天氣
參數(shù)：

• city（字符串，必填）：城市名稱，如"北京"
• unit（字符串，可選）：溫度單位，"celsius"或"fahrenheit"，默認(rèn)"celsius"

當(dāng)用戶的問(wèn)題需要查詢天氣時(shí)，請(qǐng)輸出 JSON 格式的工具調(diào)用。

然后用戶問(wèn)了一個(gè)問(wèn)題：「北京今天冷不冷？要不要穿外套？」

第二步：模型讀到這個(gè)問(wèn)題，發(fā)現(xiàn)上下文里有一個(gè)查天氣的工具可以用。它自己并不知道北京今天多少度，但它知道可以調(diào)用工具來(lái)獲取。于是模型不直接回答，而是輸出：

{
  "tool": "get_weather",
  "arguments": { "city": "北京" }
}

意思是：「我需要調(diào)用工具 get_weather，參數(shù)是 city: 北京」。

注意，模型本身并沒(méi)有調(diào)用任何 API，它只是輸出了這么一段 JSON 文本，表達(dá)一個(gè)「調(diào)用意圖」。

第三步：你的程序看到這段 JSON 后，不要直接返回給用戶，而是去調(diào)用天氣查詢 API，再把結(jié)果塞回模型的上下文：

text

工具 get_weather 的返回結(jié)果：
{"city": "北京", "temperature": 8, "unit": "celsius", "condition": "多云"}

第四步：模型看到這個(gè)結(jié)果后，就能給用戶一個(gè)有用的回答了：「北京今天 8°C，多云，還是挺涼的，建議穿個(gè)外套」。

你的程序?qū)⑦@個(gè)回復(fù)返回給用戶，用戶就能看到一個(gè)準(zhǔn)確的天氣回答了。

整個(gè)過(guò)程中，模型的上下文里依次出現(xiàn)了這些內(nèi)容：工具描述 → 用戶提問(wèn) → 模型輸出工具調(diào)用 → 工具返回結(jié)果 → 模型最終回答。

全部都是文本，全部在上下文窗口里，沒(méi)有任何魔法。模型之所以知道該調(diào)用 get_weather，純粹是因?yàn)樗谏舷挛睦镒x到了這個(gè)工具的描述。

這里面考驗(yàn)的是模型的指令遵從能力。你讓它輸出 JSON，它能不能老老實(shí)實(shí)只輸出合法的 JSON，不夾帶其他亂七八糟的文字？你告訴他函數(shù)的參數(shù)和類(lèi)型，它是否輸出正確的函數(shù)參數(shù)？

如果你嘗試過(guò) GPT-3.5 這種早期模型，會(huì)發(fā)現(xiàn)它們的指令遵從能力很差，輸出 JSON 的同時(shí)還可能帶一句「好的，下面是結(jié)果」之類(lèi)的廢話，這就會(huì)導(dǎo)致程序解析 json 失敗。

到 2023 年底，OpenAI 把 functions 參數(shù)改名為 tools，Anthropic、Google 也跟進(jìn)推出了自己的 Tool Use 方案。名字雖然變了，本質(zhì)沒(méi)變：模型輸出結(jié)構(gòu)化的工具調(diào)用請(qǐng)求，外圍程序解析結(jié)構(gòu)化的數(shù)據(jù)，執(zhí)行后把結(jié)果喂回上下文。

隨著模型的指令遵從能力越來(lái)越強(qiáng)，Tool Use 從勉強(qiáng)能用變成了非?？煽浚@也為后面 Agent 的出現(xiàn)奠定了基礎(chǔ)。

6. MCP：給工具定個(gè)標(biāo)準(zhǔn)

Tool Use 的原理搞清楚了，但還有一個(gè)實(shí)際問(wèn)題。

前面說(shuō)了，工具的描述需要塞進(jìn)模型的上下文，而這件事是需要配合模型服務(wù)提供方的。你要按照它要求的格式來(lái)定義工具，它才能正確地把工具信息傳給 LLM。

問(wèn)題是，各家的格式不太一樣，同樣是定義我們前面那個(gè)查天氣的工具，在 OpenAI 和 Anthropic 的 API 里，寫(xiě)法是不同的：

json
// OpenAI 的格式：嵌套在 function 里，參數(shù)字段叫 parameters
{
  "type": "function",
  "function": {
    "name": "get_weather",
    "description": "查詢指定城市的當(dāng)前天氣",
    "parameters": {
      "type": "object",
      "properties": {
        "city": { "type": "string", "description": "城市名稱" }
      },
      "required": ["city"]
    }
  }
}

// Anthropic 的格式：扁平結(jié)構(gòu)，參數(shù)字段叫 input_schema
{
  "name": "get_weather",
  "description": "查詢指定城市的當(dāng)前天氣",
  "input_schema": {
    "type": "object",
    "properties": {
      "city": { "type": "string", "description": "城市名稱" }
    },
    "required": ["city"]
  }
}

描述的是同一個(gè)工具，但字段名和嵌套層級(jí)都不一樣。你為 OpenAI 寫(xiě)好的工具定義，拿到 Anthropic 上就得改一遍格式，Google Gemini 又是另一套寫(xiě)法。

工具開(kāi)發(fā)者要為每個(gè)平臺(tái)適配一遍，這和當(dāng)年手機(jī)充電線的混亂局面一模一樣。

2024 年 11 月，Anthropic 推出了 MCP（Model Context Protocol，模型上下文協(xié)議）。你可以把它理解為 AI 工具領(lǐng)域的「USB-C 標(biāo)準(zhǔn)」：按照 MCP 的規(guī)范寫(xiě)一個(gè)工具，所有支持 MCP 的 Agent 都能直接接入，不用關(guān)心底層是哪家的模型。

用 MCP 寫(xiě)一個(gè)查天氣的工具，用 Python 的 FastMCP 庫(kù)十幾行代碼就搞定了：

python
from mcp.server.fastmcp import FastMCP

# 創(chuàng)建一個(gè) MCP Server
mcp = FastMCP("weather-server")

# 用裝飾器定義一個(gè)工具，函數(shù)簽名就是工具的參數(shù)定義
@mcp.tool()
def get_weather(city: str) -> str:
    """查詢指定城市的當(dāng)前天氣"""
    # 這里調(diào)用真正的天氣 API
    return f"{city}：8°C，多云"

# 啟動(dòng)服務(wù)
mcp.run()

就這么點(diǎn)代碼，F(xiàn)astMCP 會(huì)自動(dòng)根據(jù)函數(shù)簽名和文檔字符串生成標(biāo)準(zhǔn)的工具描述。

寫(xiě)完之后，Claude Code、Cursor 這些支持 MCP 的編程工具，只需要在配置文件里注冊(cè)這個(gè) Server，就能直接使用 get_weather 了。你不用操心每家平臺(tái)的 API 差異。

目前 MCP 已經(jīng)成了行業(yè)事實(shí)標(biāo)準(zhǔn)，但要注意，MCP 并沒(méi)有引入什么新的 AI 能力，它解決的是工程層面的互通問(wèn)題，底層還是 Tool Use 那一套：工具描述塞進(jìn)上下文，模型決定是否需要調(diào)用，外圍程序?qū)嶋H執(zhí)行工具并把結(jié)果喂回上下文。

MCP 只是把「怎么描述工具」「怎么調(diào)用工具」這些接口給標(biāo)準(zhǔn)化了。

7. Agent：給 LLM 套上循環(huán)

有了 Tool Use，LLM 就能做事了。但如果只是「用戶問(wèn)一句 → 模型調(diào)一次工具 → 返回結(jié)果」這種一問(wèn)一答的模式，能做的事情還是非常有限。

真實(shí)世界的任務(wù)往往需要多個(gè)步驟：先讀一下文件看看代碼結(jié)構(gòu)，再定位到有 bug 的函數(shù)，然后修改代碼，最后跑一下測(cè)試確認(rèn)修復(fù)了。這不是一次工具調(diào)用能搞定的。

Agent 的核心思路很簡(jiǎn)單：把 LLM + Tool Use 放進(jìn)一個(gè)循環(huán)里。

用偽代碼表示：

python
while 任務(wù)未完成:
    模型根據(jù)當(dāng)前上下文思考下一步該做什么
    if 模型認(rèn)為需要使用某個(gè)工具:
        執(zhí)行工具，把結(jié)果追加到上下文
    elif 模型認(rèn)為任務(wù)完成了:
        輸出最終結(jié)果，退出循環(huán)

就這么簡(jiǎn)單。Claude Code、Cursor、Codex 這些編程 Agent，本質(zhì)上都是這個(gè)循環(huán)，配上一堆編程相關(guān)的工具：讀文件、寫(xiě)文件、執(zhí)行命令、搜索代碼、運(yùn)行測(cè)試。

下面用一個(gè)修 bug 的例子來(lái)直觀理解這個(gè)過(guò)程：

用戶：src/main.py 里的 calculate_total 函數(shù)計(jì)算出來(lái)的數(shù)字總是不對(duì)，幫我修一下。

模型思考：我需要先看看這個(gè)函數(shù)現(xiàn)在的代碼是什么樣的。

模型行動(dòng)：調(diào)用 read_file 工具，參數(shù) path="src/main.py"

觀察結(jié)果：工具返回了文件內(nèi)容，模型看到 calculate_total 函數(shù)里把價(jià)格和數(shù)量乘反了。

模型思考：找到問(wèn)題了，把 price * quantity 改成 quantity * price 就行。

模型行動(dòng)：調(diào)用 edit_file 工具，修改那行代碼。

觀察結(jié)果：工具返回修改成功。

模型思考：改完了，還應(yīng)該跑一下單元測(cè)試確認(rèn)修復(fù)。

模型行動(dòng)：調(diào)用 run_command 工具，參數(shù) command="python -m pytest tests/"

觀察結(jié)果：工具返回測(cè)試通過(guò)。

模型思考：任務(wù)完成了。

模型輸出：已修復(fù) calculate_total 函數(shù)中的乘法順序錯(cuò)誤，所有測(cè)試通過(guò)。

模型在循環(huán)中不斷地「思考 → 行動(dòng) → 觀察結(jié)果 → 再思考」，這個(gè)模式在學(xué)術(shù)上叫 ReAct（Reasoning + Acting）。

它和人類(lèi)解決問(wèn)題的方式其實(shí)很像：你不會(huì)一上來(lái)就知道怎么做，而是先看看情況，試一下，看看結(jié)果，再?zèng)Q定下一步。

注意這個(gè)循環(huán)有一個(gè)副作用：每一輪的工具調(diào)用和返回結(jié)果都會(huì)追加到上下文里，所以上下文在不斷增長(zhǎng)。

所以上下文窗口的大小很重要，窗口太小的話 Agent 跑幾輪就把上下文撐滿了，前面的信息被截?cái)?，模型就「失憶」了。現(xiàn)在主流模型的上下文窗口在 128K 到 1M token 之間，就是為了讓 Agent 能跑更久。

同時(shí)，工具調(diào)用的準(zhǔn)確性也是很重要的，你看目前新模型發(fā)布的時(shí)候都有工具調(diào)用相關(guān)的評(píng)估指標(biāo)。如果工具調(diào)用的能力差，就可能把大量和目標(biāo)無(wú)關(guān)的工具調(diào)用結(jié)果追加到上下文里，導(dǎo)致上下文被撐爆。

所以 Agent 并不神秘。 它的「智能」來(lái)自兩部分：模型本身的推理能力決定了它能不能想出正確的下一步，工具賦予了它把想法變成行動(dòng)的能力。

LLM 是大腦，工具是手腳，循環(huán)是驅(qū)動(dòng)力。

8. Skills：可復(fù)用的工作流程

有了 LLM 和工具，Agent 知道自己「能做什么」。但在面對(duì)一個(gè)復(fù)雜任務(wù)時(shí)，它還需要知道「該怎么做」，也就是工作流程。

這就是 Skills 要解決的問(wèn)題。

你可能會(huì)問(wèn)：Agent 不是能自主循環(huán)解決問(wèn)題嗎，為什么還需要人來(lái)告訴它怎么做？

模型當(dāng)然能自己摸索，但對(duì)于復(fù)雜任務(wù)，自由發(fā)揮的效果不如按預(yù)設(shè)流程來(lái)得穩(wěn)。這就像公司招了一個(gè)聰明的新員工，他什么都能想辦法搞定，但給他一份 SOP 文檔，他能做得更快更穩(wěn)。

Skills 就是把一套完整的操作流程寫(xiě)成文檔，Agent 按文檔一步一步執(zhí)行。 本質(zhì)上，Skills 就是 SOP（標(biāo)準(zhǔn)操作流程）的文檔化。

拿 Anthropic 官方開(kāi)源的 PDF Skill 舉個(gè)例子。它的文件結(jié)構(gòu)是這樣的：

text
skills/pdf/
├── SKILL.md        # 核心文件：何時(shí)觸發(fā) + 操作指南
├── reference.md    # 詳細(xì)參考文檔
├── forms.md        # 表單填寫(xiě)專(zhuān)項(xiàng)指南
└── scripts/        # 預(yù)寫(xiě)好的 Python 腳本

其中 SKILL.md 是核心，開(kāi)頭的 YAML 部分告訴 Agent「什么時(shí)候該用這個(gè) Skill」：

yaml
---
name: pdf
description: Use this skill whenever the user wants to do
  anything with PDF files. This includes reading or extracting
  text/tables from PDFs, combining or merging multiple PDFs,
  splitting PDFs apart, rotating pages, adding watermarks,
  creating new PDFs, filling PDF forms...
---

后面的 Markdown 正文就是具體的操作指南：用哪個(gè) Python 庫(kù)、怎么讀取 PDF、怎么合并、怎么提取表格，甚至連代碼示例都寫(xiě)好了。而 scripts/ 目錄里則放了一批預(yù)寫(xiě)好的 Python 腳本：

text
scripts/
├── extract_form_field_info.py    # 提取表單字段信息
├── extract_form_structure.py     # 提取表單整體結(jié)構(gòu)
├── fill_fillable_fields.py       # 填寫(xiě)表單字段
├── check_fillable_fields.py      # 檢查哪些字段可填寫(xiě)
├── check_bounding_boxes.py       # 校驗(yàn)字段邊界框
├── convert_pdf_to_images.py      # PDF 轉(zhuǎn)圖片
├── create_validation_image.py    # 生成校驗(yàn)用的截圖
└── fill_pdf_form_with_annotations.py  # 通過(guò)注解填寫(xiě)表單

Agent 讀到 SKILL.md 之后就知道：要提取表單信息，跑 extract_form_field_info.py；要填寫(xiě)表單，跑 fill_fillable_fields.py；填完之后想確認(rèn)效果，跑 convert_pdf_to_images.py 轉(zhuǎn)成圖片看一眼。

它不需要自己去寫(xiě)這些腳本，也不需要把腳本代碼加載到上下文里去「理解」。它只需要知道每個(gè)腳本的用途，然后直接執(zhí)行就行了。

這樣做的好處很明顯：Agent 只需要讀一份文檔（占用少量上下文），就能借助預(yù)寫(xiě)好的工具完成復(fù)雜任務(wù)。而且這些腳本是我們事先調(diào)試驗(yàn)證過(guò)的，比讓 Agent 臨時(shí)寫(xiě)一個(gè)可靠得多。

你看，這就是一個(gè)完整的 SOP：什么時(shí)候觸發(fā)、具體怎么做、用什么工具，全部文檔化了。Agent 不需要「聰明地發(fā)明」解決方案，只需要「認(rèn)真地執(zhí)行」文檔里的流程。

Anthropic 在 Skills 的加載上有一個(gè)巧妙的設(shè)計(jì)叫漸進(jìn)式披露（Progressive Disclosure）。上面那個(gè) PDF Skill 的完整內(nèi)容可能有幾千個(gè) token，如果把所有 Skills 的完整內(nèi)容一股腦塞進(jìn)上下文，瞬間就滿了。

所以實(shí)際做法是：?jiǎn)?dòng)時(shí)只給模型每個(gè) Skill 的名字和一句話簡(jiǎn)介，大約 80 個(gè) token。幾十個(gè) Skill 加起來(lái)也才不到 2000 個(gè) token。等模型發(fā)現(xiàn)當(dāng)前任務(wù)和某個(gè) Skill 相關(guān)了，再把完整內(nèi)容加載進(jìn)來(lái)。

這就是一個(gè)典型的工程優(yōu)化：核心原理沒(méi)變（都是往上下文里塞文本），但通過(guò)按需加載，大幅降低了 token 消耗。

9. 一切都是上下文

回頭看我們講的所有內(nèi)容，你會(huì)發(fā)現(xiàn)一個(gè)貫穿始終的事實(shí)：不管是思維鏈、Tool Use、Agent 循環(huán)、MCP 工具描述還是 Skills 文檔，最終都要塞進(jìn)上下文窗口里，交給同一個(gè)概率模型去一個(gè)字一個(gè)字地往外蹦。

思維鏈?zhǔn)鞘裁?？是模型在上下文里?xiě)給自己看的草稿。

MCP 和 Tool Use是什么？是在上下文里塞了工具描述，模型讀到后輸出調(diào)用請(qǐng)求，結(jié)果再追加回上下文。

Agent 循環(huán)是什么？是不斷地往上下文里追加思考和工具結(jié)果。

Skills是什么？是把操作手冊(cè)的文本加載到上下文里。

沒(méi)有任何魔法，全部都是文本，全部都靠那個(gè)「預(yù)測(cè)下一個(gè) token」的概率模型在驅(qū)動(dòng)。

這就是為什么漸進(jìn)式披露這些工程細(xì)節(jié)如此重要。因?yàn)槟Ｐ捅旧淼哪芰κ枪潭ǖ?，上下文里塞什么、怎么塞、塞多少，直接決定了 Agent 的表現(xiàn)。

同樣一個(gè)模型，給它一份寫(xiě)得好的 Skill 文檔和一批預(yù)置腳本，它能高效完成復(fù)雜任務(wù)。給它一個(gè)塞滿了無(wú)關(guān)信息的上下文，它可能連簡(jiǎn)單的問(wèn)題都答不好。

所以整條演進(jìn)路線的本質(zhì)是：LLM 是基座，Agent 是圍繞 LLM 的一套工程體系。

從 Function Calling 到 MCP 到 Skills 到漸進(jìn)式披露，都是在解決同一個(gè)問(wèn)題：如何在有限的上下文窗口里高效地組織信息，讓概率模型發(fā)揮出最大的能力。

理解了這一點(diǎn)，你會(huì)發(fā)現(xiàn) AI 時(shí)代的機(jī)會(huì)并不只屬于搞大模型訓(xùn)練的人。模型能力的提升當(dāng)然重要，但圍繞模型的工程優(yōu)化同樣大有可為。

怎么設(shè)計(jì)工具讓 Agent 用起來(lái)更順暢？怎么寫(xiě) Skill 文檔讓流程更可靠？怎么管理上下文讓 token 花在刀刃上？這些都是實(shí)實(shí)在在的工程問(wèn)題，也是你理解了這些原理之后可以著手的方向。

說(shuō)到底，你不需要懂模型是怎么訓(xùn)練的，但你知道「一切都是上下文」，就能更聰明地使用這些 Agent 工具更好地完成任務(wù)。

而且，隨著模型本身的能力的提升，你圍繞模型構(gòu)建的工程優(yōu)化的價(jià)值也會(huì)水漲船高，這正是 AI 時(shí)代的機(jī)會(huì)所在。

10. 回到開(kāi)頭的問(wèn)題

你現(xiàn)在應(yīng)該明白 Claude Code、Cursor 等工具是什么了吧？它們是 Agent 工程層面的工具。

即便底層都使用相同的 Claude 模型，它們的編程效果也會(huì)有差別，就是因?yàn)?Agent 的工程實(shí)現(xiàn)不一樣。

就我的體驗(yàn)來(lái)說(shuō)，同樣都是用 Claude 模型，Claude Code 用起來(lái)最舒服，給人感覺(jué)最聰明，就是因?yàn)樗?Agent 工程做得最好，Cursor 等其他工具都略遜一籌。

說(shuō)白了，Claude 模型和 Claude Code 都是 Anthropic 的，所以 Claude Code 舍得給模型塞更多的上下文，獲取充分的信息后再開(kāi)始寫(xiě)代碼。

Cursor 等其他工具，依靠模型廠商的 API 調(diào)用，多少有些成本的限制在里面，所以它們希望塞更少的上下文，盡快給出答案。但這樣做的代價(jià)就是，有些復(fù)雜問(wèn)題可能得不到足夠的信息，模型再?gòu)?qiáng)也沒(méi)用，寫(xiě)出來(lái)的代碼還是可能欠考慮。

反過(guò)來(lái)，同一個(gè) Agent 實(shí)現(xiàn)，使用不同的模型，效果也會(huì)有差別，這就是模型能力的差距。

比如你用 Claude Code 接入其他的模型，效果也不如使用 Claude 模型好，因?yàn)槟壳皝?lái)看 Claude 模型的編程能力是最強(qiáng)的，其他模型還有一定的差距。