第 0 篇：Agent 世界观——先搞懂 LLM、Context、Tool 与 Agent 到底是什么

名词解释

LLM（Large Language Model，大语言模型）：负责理解、推理、判断和生成内容的核心模型。本文把它比作一个"拥有天下武学与深厚内力的绝顶高手"。它真正长期保留下来的能力主要固化在模型参数中，而不是像数据库一样保存一篇篇文章。

Weights / 模型参数 ：模型训练后形成的大量参数。本文把它类比为高手经过长期修炼形成的"内功、武学体系和肌肉记忆"。问它 Java HashMap 是怎么实现的？ 时，它通常不是去内部查一篇叫 HashMap.txt 的文章，而是凭训练形成的参数模式理解问题并生成答案。

Prompt（提示词）：一次模型调用时交给 LLM 的指令和信息。Prompt 不只是用户最后输入的一句话；在真实系统中，还可能包含系统指令、历史消息、工具说明、检索结果等。

Context（上下文）：某一次 LLM 调用时，它当前能"看到"的全部有效信息。可以把它理解成高手此刻脑中摆着的材料。

Context Window（上下文窗口）：一次模型调用能够容纳的上下文容量上限。本文把它类比为高手有限的"当前工作记忆"。它和模型参数不是一回事。

Tool（工具）：LLM 可以请求外部系统执行的能力，例如搜索网页、读取文件、执行 Shell、修改代码、查询数据库、调用 API。Tool 本身通常没有负责整体任务的智能。

Tool Use / Function Calling（工具调用）：LLM 根据当前上下文判断需要使用某个工具，并输出结构化的调用请求；真正执行工具的一般是模型外部的运行环境，然后把结果重新交给 LLM。

Agent（智能体）：围绕 LLM 建立的一套可持续执行任务的系统。它通常至少包含 LLM、Tools 和执行循环，复杂实现还会加入状态管理、上下文管理、权限控制、失败恢复、任务规划等。本文把 Agent 类比为高手携带的一套"法宝系统"：法宝不替高手思考，而是让高手的内力拥有更多现实中的表现形式。

Agent Loop（智能体循环）：Agent 的核心运行方式。LLM 判断下一步 → 请求工具 → 工具执行 → 结果回填上下文 → 再次调用 LLM → 继续判断，反复进行，直到任务完成、失败、被中止或需要用户介入。

Memory（记忆）：模型之外保存的长期或跨任务信息，例如数据库、文件、向量库、用户偏好、任务历史。需要使用时，再把相关内容取出来放进 Context。Memory 不是 LLM 参数本身，也不等于 Context。

State（状态）：当前任务执行到哪一步、哪些子任务已完成、哪些文件被改过、测试是否通过等运行信息。State 更接近"任务进度"，Memory 更接近"需要长期保存的信息"，二者实际工程中可能由同一存储系统承载。

MCP（Model Context Protocol）：一种让模型应用以统一方式连接外部工具和上下文来源的协议。它解决的是"怎么把能力接进来"的问题，不等于 Agent 本身。

Claude Code：Anthropic 面向软件开发场景提供的 Coding Agent。它能围绕代码项目持续读取、分析、修改、执行和验证，而不是只进行一次代码问答。

Claude Agent SDK：用于构建 Agent 应用的开发工具。可以把 Claude 的推理能力与工具、权限、执行环境等组合起来，构建面向不同任务的 Agent。

本文的武侠比喻只是教学模型，不是官方术语，也不是对底层实现的逐字映射。

工程概念以真实系统行为和官方文档为准；比喻的目的只有一个：先建立一个不容易混乱的世界观。

[1. 为什么所有 Agent 教程之前，都应该先讲世界观](#1. 为什么所有 Agent 教程之前，都应该先讲世界观 "#1-%E4%B8%BA%E4%BB%80%E4%B9%88%E6%89%80%E6%9C%89-agent-%E6%95%99%E7%A8%8B%E4%B9%8B%E5%89%8D%E9%83%BD%E5%BA%94%E8%AF%A5%E5%85%88%E8%AE%B2%E4%B8%96%E7%95%8C%E8%A7%82")
[2. 第一件事：先把 LLM 想明白](#2. 第一件事：先把 LLM 想明白 "#2-%E7%AC%AC%E4%B8%80%E4%BB%B6%E4%BA%8B%E5%85%88%E6%8A%8A-llm-%E6%83%B3%E6%98%8E%E7%99%BD")
- [2.1 LLM 不是数据库](#2.1 LLM 不是数据库 "#21-llm-%E4%B8%8D%E6%98%AF%E6%95%B0%E6%8D%AE%E5%BA%93")
- [2.2 模型参数更像"肌肉记忆"](#2.2 模型参数更像“肌肉记忆” "#22-%E6%A8%A1%E5%9E%8B%E5%8F%82%E6%95%B0%E6%9B%B4%E5%83%8F%E8%82%8C%E8%82%89%E8%AE%B0%E5%BF%86")
- [2.3 LLM 是一个完整的"高手"](#2.3 LLM 是一个完整的“高手” "#23-llm-%E6%98%AF%E4%B8%80%E4%B8%AA%E5%AE%8C%E6%95%B4%E7%9A%84%E9%AB%98%E6%89%8B")
[3. 第二件事：模型参数和 Context 完全不是一回事](#3. 第二件事：模型参数和 Context 完全不是一回事 "#3-%E7%AC%AC%E4%BA%8C%E4%BB%B6%E4%BA%8B%E6%A8%A1%E5%9E%8B%E5%8F%82%E6%95%B0%E5%92%8C-context-%E5%AE%8C%E5%85%A8%E4%B8%8D%E6%98%AF%E4%B8%80%E5%9B%9E%E4%BA%8B")
- [3.1 Context 是当前工作记忆](#3.1 Context 是当前工作记忆 "#31-context-%E6%98%AF%E5%BD%93%E5%89%8D%E5%B7%A5%E4%BD%9C%E8%AE%B0%E5%BF%86")
- [3.2 为什么新开一次对话，它就像"失忆"了](#3.2 为什么新开一次对话，它就像“失忆”了 "#32-%E4%B8%BA%E4%BB%80%E4%B9%88%E6%96%B0%E5%BC%80%E4%B8%80%E6%AC%A1%E5%AF%B9%E8%AF%9D%E5%AE%83%E5%B0%B1%E5%83%8F%E5%A4%B1%E5%BF%86%E4%BA%86")
- [3.3 Context、Memory、Weights 的关系](#3.3 Context、Memory、Weights 的关系 "#33-contextmemoryweights-%E7%9A%84%E5%85%B3%E7%B3%BB")
[4. 第三件事：Tool 到底是什么](#4. 第三件事：Tool 到底是什么 "#4-%E7%AC%AC%E4%B8%89%E4%BB%B6%E4%BA%8Btool-%E5%88%B0%E5%BA%95%E6%98%AF%E4%BB%80%E4%B9%88")
- [4.1 Tool 不是智能](#4.1 Tool 不是智能 "#41-tool-%E4%B8%8D%E6%98%AF%E6%99%BA%E8%83%BD")
- [4.2 Tool 是"能力外放方式"](#4.2 Tool 是“能力外放方式” "#42-tool-%E6%98%AF%E8%83%BD%E5%8A%9B%E5%A4%96%E6%94%BE%E6%96%B9%E5%BC%8F")
- [4.3 LLM 并不是亲自执行 Tool](#4.3 LLM 并不是亲自执行 Tool "#43-llm-%E5%B9%B6%E4%B8%8D%E6%98%AF%E4%BA%B2%E8%87%AA%E6%89%A7%E8%A1%8C-tool")
[5. 第四件事：Agent 到底是什么](#5. 第四件事：Agent 到底是什么 "#5-%E7%AC%AC%E5%9B%9B%E4%BB%B6%E4%BA%8Bagent-%E5%88%B0%E5%BA%95%E6%98%AF%E4%BB%80%E4%B9%88")
- [5.1 Agent 不是另一种比 LLM 更高级的 AI](#5.1 Agent 不是另一种比 LLM 更高级的 AI "#51-agent-%E4%B8%8D%E6%98%AF%E5%8F%A6%E4%B8%80%E7%A7%8D%E6%AF%94-llm-%E6%9B%B4%E9%AB%98%E7%BA%A7%E7%9A%84-ai")
- [5.2 最小 Agent 与完整 Agent](#5.2 最小 Agent 与完整 Agent "#52-%E6%9C%80%E5%B0%8F-agent-%E4%B8%8E%E5%AE%8C%E6%95%B4-agent")
- [5.3 为什么"Agent = 一个死的工具集合"只对了一半](#5.3 为什么“Agent = 一个死的工具集合”只对了一半 "#53-%E4%B8%BA%E4%BB%80%E4%B9%88agent--%E4%B8%80%E4%B8%AA%E6%AD%BB%E7%9A%84%E5%B7%A5%E5%85%B7%E9%9B%86%E5%90%88%E5%8F%AA%E5%AF%B9%E4%BA%86%E4%B8%80%E5%8D%8A")
[6. Agent 真正的灵魂：Agent Loop](#6. Agent 真正的灵魂：Agent Loop "#6-agent-%E7%9C%9F%E6%AD%A3%E7%9A%84%E7%81%B5%E9%AD%82agent-loop")
- [6.1 本质上就是自动化的高频多轮调用](#6.1 本质上就是自动化的高频多轮调用 "#61-%E6%9C%AC%E8%B4%A8%E4%B8%8A%E5%B0%B1%E6%98%AF%E8%87%AA%E5%8A%A8%E5%8C%96%E7%9A%84%E9%AB%98%E9%A2%91%E5%A4%9A%E8%BD%AE%E8%B0%83%E7%94%A8")
- [6.2 每一轮究竟发生了什么](#6.2 每一轮究竟发生了什么 "#62-%E6%AF%8F%E4%B8%80%E8%BD%AE%E7%A9%B6%E7%AB%9F%E5%8F%91%E7%94%9F%E4%BA%86%E4%BB%80%E4%B9%88")
- [6.3 为什么历史记录可能被裁剪、总结或外置](#6.3 为什么历史记录可能被裁剪、总结或外置 "#63-%E4%B8%BA%E4%BB%80%E4%B9%88%E5%8E%86%E5%8F%B2%E8%AE%B0%E5%BD%95%E5%8F%AF%E8%83%BD%E8%A2%AB%E8%A3%81%E5%89%AA%E6%80%BB%E7%BB%93%E6%88%96%E5%A4%96%E7%BD%AE")
[7. 用 Claude Code 修 Bug，把整个过程串起来](#7. 用 Claude Code 修 Bug，把整个过程串起来 "#7-%E7%94%A8-claude-code-%E4%BF%AE-bug%E6%8A%8A%E6%95%B4%E4%B8%AA%E8%BF%87%E7%A8%8B%E4%B8%B2%E8%B5%B7%E6%9D%A5")
[8. 为什么套上 Agent 后，LLM 看起来突然强了很多](#8. 为什么套上 Agent 后，LLM 看起来突然强了很多 "#8-%E4%B8%BA%E4%BB%80%E4%B9%88%E5%A5%97%E4%B8%8A-agent-%E5%90%8Ellm-%E7%9C%8B%E8%B5%B7%E6%9D%A5%E7%AA%81%E7%84%B6%E5%BC%BA%E4%BA%86%E5%BE%88%E5%A4%9A")
[9. Memory、State、Planning、Retry：复杂 Agent 多出来的东西](#9. Memory、State、Planning、Retry：复杂 Agent 多出来的东西 "#9-memorystateplanningretry%E5%A4%8D%E6%9D%82-agent-%E5%A4%9A%E5%87%BA%E6%9D%A5%E7%9A%84%E4%B8%9C%E8%A5%BF")
[10. MCP 在这个世界观里处于什么位置](#10. MCP 在这个世界观里处于什么位置 "#10-mcp-%E5%9C%A8%E8%BF%99%E4%B8%AA%E4%B8%96%E7%95%8C%E8%A7%82%E9%87%8C%E5%A4%84%E4%BA%8E%E4%BB%80%E4%B9%88%E4%BD%8D%E7%BD%AE")
[11. Workflow、Agent、Multi-Agent 不要混为一谈](#11. Workflow、Agent、Multi-Agent 不要混为一谈 "#11-workflowagentmulti-agent-%E4%B8%8D%E8%A6%81%E6%B7%B7%E4%B8%BA%E4%B8%80%E8%B0%88")
[12. 几个最常见的错误理解](#12. 几个最常见的错误理解 "#12-%E5%87%A0%E4%B8%AA%E6%9C%80%E5%B8%B8%E8%A7%81%E7%9A%84%E9%94%99%E8%AF%AF%E7%90%86%E8%A7%A3")
[13. 用一句武侠世界观把整套系统串起来](#13. 用一句武侠世界观把整套系统串起来 "#13-%E7%94%A8%E4%B8%80%E5%8F%A5%E6%AD%A6%E4%BE%A0%E4%B8%96%E7%95%8C%E8%A7%82%E6%8A%8A%E6%95%B4%E5%A5%97%E7%B3%BB%E7%BB%9F%E4%B8%B2%E8%B5%B7%E6%9D%A5")
[14. 后续学习 Claude Agent 时应该带着哪些问题](#14. 后续学习 Claude Agent 时应该带着哪些问题 "#14-%E5%90%8E%E7%BB%AD%E5%AD%A6%E4%B9%A0-claude-agent-%E6%97%B6%E5%BA%94%E8%AF%A5%E5%B8%A6%E7%9D%80%E5%93%AA%E4%BA%9B%E9%97%AE%E9%A2%98")
[15. 最终总结](#15. 最终总结 "#15-%E6%9C%80%E7%BB%88%E6%80%BB%E7%BB%93")

1. 为什么所有 Agent 教程之前，都应该先讲世界观

学习 Agent 最容易出现的一种情况是：

会用，但不懂。

会配置 Tool，会复制 MCP 配置，会运行 Claude Code，会调用 Agent SDK，但是一遇到下面的问题就开始混乱：

LLM 和 Agent 到底是什么关系？
Agent 自己会不会思考？
Tool 到底是 LLM 的一部分，还是外面的东西？
为什么一次任务会消耗很多次模型调用？
为什么 Tool 的结果还要再发回给模型？
为什么 Context 太长会成为问题？
Memory 和 Context 有什么区别？
MCP 是不是 Agent？
Claude Code 为什么比普通聊天更像一个"程序员"？

这些问题如果没有先想清楚，后面学到的每个概念都会像孤岛。

所以这套教程不准备从 API 开始。

先建立世界观，再进入具体技术。

本文最重要的目标不是让你记住某个定义，而是建立一套可以长期复用的认知模型。

2. 第一件事：先把 LLM 想明白

2.1 LLM 不是数据库

假设你问 Claude：

Java HashMap 是怎么实现的？

一个很容易产生的错误想象是：

"Claude 内部是不是保存了一篇关于 HashMap 的文章，现在把它搜出来了？"

这个理解不准确。

LLM 的核心不是传统意义上的资料库查询。

它经过训练后，大量语言模式、知识关联、推理方式、代码结构等能力被压进了模型参数。

于是当 HashMap 这个问题进入模型后，模型根据当前输入和自身参数生成回答。

可以先粗略理解为：

这不是说模型"完全没有知识"。

恰恰相反，它有非常庞大的知识和能力。

关键区别在于：

这些知识通常不是以一篇篇可直接检索的原文形式存在于模型内部。

2.2 模型参数更像"肌肉记忆"

本文采用一个武侠比喻。

把 LLM 想成：

一个学会了天下万般武学的绝顶高手。

高手为什么会武功？

不是因为每打一拳，都先翻书：

"让我查一下《拳法大全》第 37 页。"

而是几十年、几百年的训练已经把能力练进去了。

看到攻击，他自然知道怎么拆。

看到招式，他自然知道怎么接。

对应到 LLM：

模型参数就像训练后形成的内功、武学体系和肌肉记忆。

训练阶段不断调整参数；训练完成后，这些参数成为模型生成答案时的基础。

所以当你问：

Java HashMap 是怎么实现的？

它更多是在"凭已经练进身体里的东西作答"，而不是在"大脑里翻找一篇记忆"。

这就是本文后面一直会使用的核心比喻：

Weights ≈ 内功 + 武学体系 + 肌肉记忆。

需要注意：这是帮助理解的教学类比，不代表神经网络参数真的等同于人类肌肉记忆。

2.3 LLM 是一个完整的"高手"

在本文的武侠世界观里：

LLM 就是一个完整的高手。

他有自己的理解能力、判断能力、推理能力和表达能力。

他的问题不是"身体缺器官"。

真正的问题是：

仅靠自身，他对现实计算机世界能够直接产生的作用非常有限。

他可以知道 Linux 命令怎么写。

他可以分析某段 Java 代码应该怎么改。

他可以告诉你数据库应该怎么设计。

但"知道怎么做"和"真的进入你的机器执行"是两件事情。

这就引出了 Tool 和 Agent。

3. 第二件事：模型参数和 Context 完全不是一回事

理解 Agent 之前，必须把下面两个东西彻底分开：

模型参数
Context

它们都可能被日常语言叫成"记忆"，但工程上完全不是一回事。

3.1 Context 是当前工作记忆

假设第一轮：

用户：帮我设计一个登录系统。

模型回答了一套 JWT 方案。

第二轮：

用户：在刚才方案上加 RBAC。

为什么模型知道"刚才方案"是什么？

一个关键原因是：前面的对话仍然被放在当前上下文中。

因此可以把 Context 类比为：

高手当前脑海中能摆下的有限工作材料。

这里可能包含：

系统给模型的规则
用户当前的问题
前面的对话历史
模型之前的回答
Tool 返回的结果
从 Memory 检索出的资料
当前任务状态的摘要
某些项目文件内容

所以：

Context 不是只有"用户最后一句话"。

它是这一次模型调用时真正送进模型的有效输入集合。

3.2 为什么新开一次对话，它就像"失忆"了

假设之前你和模型聊了半小时登录系统。

然后清空 Context，重新开一个完全独立的会话，只说：

继续优化。

如果没有额外的 Memory 或历史恢复机制，模型自然不知道你让它继续优化什么。

不是因为它的模型参数突然变了。

也不是因为刚才聊天时模型参数里写入了一段"用户项目记忆"，然后又被删除。

而是因为：

刚才那段经历没有出现在这一次调用的 Context 里。

在本文的比喻中：

模型参数：高手已经练成的武功
Context：高手眼下正在想着的事情

前者长期存在。

后者是当前任务中的有限工作记忆。

3.3 Context、Memory、Weights 的关系

这三个词非常容易混淆。

最关键的一句话：

LLM 直接推理时依赖模型参数和当前 Context；外部 Memory 若想影响这一轮判断，通常需要先被读取，再进入 Context。

因此，"模型记得"和"系统帮模型找回来再塞给它"是完全不同的事情。

4. 第三件事：Tool 到底是什么

4.1 Tool 不是智能

Tool 可以极其强大，但它本身通常只是一个能力接口。

例如：

read_file(path)
write_file(path, content)
bash(command)
search_web(query)
query_database(sql)
deploy(service)
send_email(...)

这些能力本身未必知道：

为什么现在要调用自己
当前整个任务目标是什么
下一步应该做什么
到底什么时候算完成

真正负责结合上下文做判断的，通常还是 LLM 或外围确定性的工作流逻辑。

4.2 Tool 是"能力外放方式"

继续使用武侠比喻。

LLM 是一个拥有强大内力的完整高手。

Agent 法宝可以让这股内力出现不同的"表现形式"。

例如：

武侠比喻	工程里的 Tool
勘测前方十里地形	搜索网页、读取目录、读取文件
神识探查	查询数据库、查看日志、读取系统状态
飞剑攻击	修改文件、调用 API、执行命令
炼器	生成代码、创建配置、修改工程
传讯符	发送消息、调用外部服务
储物法宝	保存任务状态、持久化 Memory

这里最重要的不是比喻本身。

而是理解：

Tool 没有把 LLM 变成另一个更聪明的模型，它只是给 LLM 的判断增加了可执行出口。

4.3 LLM 并不是亲自执行 Tool

真实工程里，一个非常容易被忽略的细节是：

LLM 一般不会自己伸手进入你的操作系统执行命令。

更典型的过程是：

也就是说：

LLM 判断"我需要读文件"。
LLM 输出一个结构化的工具调用意图。
Agent Runtime 收到这个请求。
Runtime 真正执行工具。
工具返回结果。
Runtime 把结果重新送给 LLM。
LLM 再根据新信息继续判断。

所以从工程角度说：

LLM 负责决策，Runtime 负责调度，Tool 负责执行。

不同系统的实现细节会不同，但这个抽象非常重要。

5. 第四件事：Agent 到底是什么

5.1 Agent 不是另一种比 LLM 更高级的 AI

这是本文最想纠正的误区之一。

很多入门材料会让人形成一种印象：

LLM 是普通 AI
Agent 是更高级 AI
Multi-Agent 又是更高级 AI

这种层级想象很容易误导。

更准确的理解是：

Agent 是围绕 LLM 建起来的任务执行系统。

智能的主要来源仍然是 LLM。

Agent 负责把：

模型
工具
上下文
状态
执行循环
权限
外部环境

组织成一个可以持续做事的整体。

5.2 最小 Agent 与完整 Agent

最小化理解时，可以先把 Agent 看成：

LLM + Tools + Loop

这已经足够形成一个基本 Agent。

但是生产级 Agent 往往还会有更多部分：

所以如果只说：

Agent 就是一堆工具。

不够完整。

Tool 是 Agent 的重要组成部分，但不是整个 Agent 系统。

5.3 为什么"Agent = 一个死的工具集合"只对了一半

这个说法的优点是，它抓住了一个非常关键的事实：

工具本身不会因为被叫做 Agent 就突然产生智能。

但是工程上还需要再补半句话：

Agent 不只是工具集合，还包含让 LLM 和工具能够持续交互的运行机制。

如果没有这个运行机制：

谁保存当前任务状态？
谁真正执行工具？
谁把 Tool Result 塞回下一轮？
谁判断是否继续？
谁处理失败？
谁控制权限？
谁处理 Context 太长？
谁决定任务什么时候结束？

因此可以把它修正为：

Agent 的"法宝能力"本身大多是死的；Agent Runtime 把这些法宝组织起来，让 LLM 可以在一个持续循环中使用它们。

6. Agent 真正的灵魂：Agent Loop

6.1 本质上就是自动化的高频多轮调用

这是理解 Agent 最关键的一层。

一个 Agent 任务看起来可能很神奇：

"帮我检查整个项目，修复登录 Bug，跑完测试后告诉我结果。"

但从底层视角看，它往往不是"一次模型调用完成全部事情"。

而是很多轮模型调用串起来。

这一张图就是整个 Agent 世界观的核心。

可以把 Agent 的运行理解成：

不断把"当前已知的一切"交给 LLM，让它判断下一步；外部世界执行之后，再把新结果交回来。

反反复复，直到任务完成。

所以说，同一个问题+同一个 llm，在网页和 agent 这俩不同的环境中，所消耗的 token 是不同的（对话的轮次不同），网页是一问一答的对话式，agent 中一个问题可能经历数十次问答（loop 操纵的）

6.2 每一轮究竟发生了什么

假设用户说：

修复这个项目的登录 Bug。

第一轮模型可能看到：

用户目标
系统规则
当前项目环境说明
可用工具列表

然后它判断：

先看目录结构。

于是请求 Tool。

目录结果回来后，第二轮模型看到的 Context 会增加：

刚才自己为什么要读目录
Tool 返回的目录
原始任务目标

然后继续判断：

应该读取登录相关文件。

再调用 Tool。

新的结果继续回填。

于是整个 Agent 是一个不断积累"观察结果 → 决策 → 新观察结果"的闭环。

6.3 为什么历史记录可能被裁剪、总结或外置

一个任务可能执行几十轮、几百轮。

如果每一轮都把从第一条消息开始的所有内容原封不动重新传入模型，Context 会越来越大。

因此真实 Agent 系统可能采用：

删除不重要的历史
对早期内容做摘要
只保留当前任务关键状态
把大文件放在外部，不长期塞在 Context
需要时重新读取
把长期信息保存进 Memory
把执行进度压缩成结构化 State

所以更准确的表述不是：

每一次都一定把所有历史完整重新发给 LLM。

而是：

每一轮都会构造一个足以支持当前判断的新 Context；其中可能包含原始历史，也可能包含裁剪、摘要、检索结果或结构化状态。

这也是后面学习 Context Engineering 时必须重点理解的地方。

7. 用 Claude Code 修 Bug，把整个过程串起来

假设用户对 Claude Code 说：

修复项目里的登录 Bug，完成后运行测试。

从概念上，可以把过程理解成下面这样：

这张图揭示了一个表面上容易被忽略的事实：

Claude Code 看起来像在"持续工作"，本质上是模型判断和外部执行之间反复闭环。

真正让它像一个"会干活的程序员"的，不只是模型会写代码，而是：

它可以继续观察
可以继续行动
可以看到行动结果
可以根据失败调整
可以验证最终结果

8. 为什么套上 Agent 后，LLM 看起来突然强了很多

普通聊天模式通常是：

这时模型再聪明，很多时候也只能告诉你：

"你应该这样做。"

而 Agent 模式是：

关键变化不是：

模型智商突然提高了。

而是：

模型获得了"行动 → 观察结果 → 再判断"的闭环。

这和人类解决现实问题非常像。

人类程序员也不会坐着凭空一次性想完所有细节。

真实过程是：

看项目
猜原因
改代码
跑测试
看报错
再改
再测试

Agent 让 LLM 也拥有类似的反馈闭环。

9. Memory、State、Planning、Retry：复杂 Agent 多出来的东西

一个非常小的 Demo Agent，可能真的只有：

LLM
两三个 Tool
一个 while loop

但是到了真实产品里，通常还会加入很多工程能力。

Memory

保存跨轮次、跨任务甚至跨会话的信息。

例如：

用户偏好
项目背景
历史决策
长期知识
已处理过的问题

Memory 自己不能自动改变模型判断。

需要先被检索或读取，再放入 Context。

State

保存当前任务正在发生什么。

例如：

子任务 A 已完成
子任务 B 失败两次
当前修改了 3 个文件
测试还剩 2 项
当前工作目录是什么

Planning

复杂任务可能需要先拆解：

先定位问题
再读取代码
再修改
再测试
再检查回归

有些规划由 LLM 自己动态产生，有些由工作流预先规定，有些是混合方式。

Retry / Failure Recovery

真实环境一定会失败。

例如：

API 超时
Shell 命令报错
测试失败
文件不存在
权限不足

Agent 系统需要决定：

是否重试
是否换方案
是否让 LLM 重新判断
是否向用户请求授权
是否终止任务

Context Management

任务越来越长，Context 越来越大。

系统需要决定：

什么保留
什么删除
什么总结
什么写入 Memory
什么重新读取

Permission / Safety

一个"会行动"的 Agent 比只会聊天的模型风险更高。

所以真实系统还需要：

工具权限
文件访问范围
命令执行限制
用户确认
敏感操作审批
沙箱环境

这也是为什么 Agent 工程绝不只是"给模型几个函数"这么简单。

10. MCP 在这个世界观里处于什么位置

MCP 很重要，但不要把 MCP 和 Agent 混成一个东西。

可以先这么理解：

Agent 解决的是"高手如何持续完成任务"。

MCP 更偏向解决"法宝能力如何用统一方式接进系统"。

例如你的 Agent 想拥有：

GitHub 能力
数据库能力
文件系统能力
浏览器能力

如果每种能力都有完全不同的接入方式，整个生态会很乱。

MCP 的价值之一，就是让模型应用与外部工具、资源之间形成更统一的连接方式。

但是：

接入了 MCP，不代表自动拥有了完整 Agent。

还需要有人负责：

任务循环
上下文
状态
工具调用
完成条件

11. Workflow、Agent、Multi-Agent 不要混为一谈

Agent 系统并不意味着"所有事情都交给 LLM 自由决定"。

真实生产环境往往会混合：

确定性代码
Workflow
规则引擎
LLM 判断
Agent Loop

例如一个退款流程可能是：

这里不是"纯 Agent"。

而是确定性流程和 LLM 能力混合。

这往往比把所有控制权都交给 LLM 更可靠。

至于 Multi-Agent，可以先理解为：

一个系统里存在多个承担不同角色的 Agent，它们之间继续通过消息、任务或共享状态协作。

但不要因为"Agent 数量更多"就自动认为系统一定更高级、更智能。

很多问题一个 Agent 就能解决，多 Agent 反而可能增加：

成本
延迟
上下文同步难度
错误传播
调试难度

12. 几个最常见的错误理解

误区一：Agent 是一种新的模型

不对。

Agent 通常是围绕模型建立的执行系统。

LLM 是核心智能来源之一，Agent 是让这份智能能够持续作用于任务的运行方式。

误区二：Agent 一定比普通 LLM 更聪明

不准确。

同一个 LLM 套上 Agent 后，看起来可能厉害很多，因为它：

能搜索
能读文件
能执行
能验证
能失败后再来

提升的是整个系统解决任务的能力，不代表底层模型参数本身突然升级。

误区三：LLM 知道 Linux，所以它就能操作你的 Linux

不对。

"知道怎么操作"和"拥有执行权限"是两回事。

Tool / Runtime 才负责把判断变成真正的系统动作。

误区四：模型参数就是模型的大脑数据库

不准确。

模型参数包含训练形成的能力与统计结构，但不能简单理解成一个按文章、文件、记录组织的数据库。

"HashMap 怎么实现"这个例子尤其适合帮助区分这两种东西。

误区五：Context 就是长期记忆

不对。

Context 更像当前工作记忆。

Memory 是模型外部的长期存储。

Memory 中的信息通常需要再次进入 Context，才能影响当前推理。

误区六：Agent 每一步都必须完全由 LLM 决定

不对。

生产系统可以把很多部分交给确定性代码、规则和 Workflow。

LLM 只负责那些真正需要语言理解、模糊判断和推理的部分。

误区七：MCP 就是 Agent

不对。

MCP 更像能力接入层或协议层。

一个 MCP Server 可以给 Agent 提供 Tool，但它本身不等于完整 Agent 系统。

13. 用一句武侠世界观把整套系统串起来

现在可以把本文全部压缩成一个统一模型。

LLM 是一个拥有天下武学的完整高手，为了容纳更多武学彻底放弃了大脑记忆（只保留超短记忆即上下文）。

模型参数是他多年修炼形成的内功、武学体系和肌肉记忆。

Context 是他此刻有限的工作记忆------当前任务、刚刚看到的信息、工具返回结果，都需要进入这里才能参与这一轮判断。

Memory 是外部保存的信息，需要时再取出来放回 Context。

Agent 是高手携带的法宝系统和运行框架。法宝本身不负责成为"另一个高手"，而是让高手的内力可以表现成搜索、读文件、查数据库、执行命令、修改代码、调用 API、保存状态等现实能力。

Agent Loop 则是高手不断判断、使用法宝、得到反馈、再次判断的循环。

因此，一个复杂 Agent 任务从底层看，往往就是一次又一次 LLM 调用与 Tool 执行组成的闭环，直到最终验收通过。

这套比喻有意避免说：

LLM 没有手、没有眼睛，所以 Agent 给它安装手和眼睛。

因为这种说法很容易把 LLM 想成一个"残缺的大脑"。

本文更推荐：

LLM 是完整高手，Agent 是让其能力产生更多现实表现形式的法宝系统。

14. 后续学习 Claude Agent 时应该带着哪些问题

当这个世界观建立以后，再进入 Claude Code、Tool Use、MCP、Agent SDK 时，建议始终带着下面这些问题：

这一部分是谁在做决定？
- LLM？
- Runtime？
- 固定 Workflow？
这一部分信息现在存在哪里？
- Weights？
- Context？
- Memory？
- State？
这个 Tool 到底提供了什么外部能力？
LLM 请求 Tool 后，真正是谁执行？
Tool Result 如何回到下一轮 Context？
这一轮为什么还要再次调用模型？
任务什么时候算完成？谁负责验收？
如果工具失败，会怎样恢复？
Context 太长之后，系统如何裁剪或压缩？
哪些东西适合交给 LLM，哪些应该使用确定性代码？
MCP 在这里只负责接入能力，还是还承担了其他职责？
Claude Code 的"自主工作感"，究竟来自模型、工具，还是整个闭环设计？

只要这些问题一直保持清楚，后面再看复杂 Agent 架构就很难真正迷路。

15. 最终总结

学习 Agent 时，最不应该做的事情，就是把各种新名词一个一个孤立背下来。

真正需要建立的是关系：

最后只记住五句话：

LLM 是智能核心，不是数据库。
Weights 更像训练形成的内功和肌肉记忆；Context 是当前有限的工作记忆。
Tool 是能力外放方式，真正执行 Tool 的通常是模型外部 Runtime。
Agent 不是另一个神秘 AI，而是把 LLM、Tool、Context、State、Memory 和执行机制组织起来的任务系统。
Agent 最核心的运行方式，是"判断 → 行动 → 获得反馈 → 再判断"的循环。

理解完这些，再开始学习 Claude Code、MCP、Claude Agent SDK，后面看到的绝大多数机制都会开始有位置，而不是一堆零散的新名词。

本篇定位

这是整套 Claude Agent 教程的"第 0 篇"，负责建立世界观，而不是代替后续的官方文档学习。

后续涉及 Claude Code、Claude Agent SDK、Tool Use、MCP、权限系统、Hooks、Subagents、Context Engineering 等具体机制时，应继续以 Anthropic 官方文档为事实来源；本文中的"绝顶高手、内功、法宝"等说法只作为教学辅助模型。