第 1 章：认识 Claude Code

从聊天机器人到 Agent

Planning + Memory + Tool Use

一、从"被动应答"到"主动执行"：本质区别

1.1 聊天机器人的局限

在 Claude Code 出现之前，大多数人对 AI 的交互体验停留在聊天机器人（Chatbot）层面。你问一句，它答一句；你停止输入，它就原地待命。无论是早期的规则式客服机器人，还是后来基于大语言模型（LLM）的 ChatGPT、Claude Web 版，其核心模式都是被动响应（Reactive）——等待用户触发，然后生成一段文本作为回复。

这种模式的本质局限在于：

无状态性：每次对话都是独立的，机器人不会记住你三天前告诉它的项目结构。
无行动能力：它只能"说"，不能"做"。你无法让它去读取你的代码文件、运行测试、或者提交 Git。
无目标导向：它不会主动分解任务、制定计划、检查进度。你问"怎么修复这个 Bug"，它给你一段解释，但修复工作仍然需要你自己完成。

业界常用一个类比来区分两者：想象一位明星的助理（按指令做事）与经纪人（主动规划）的区别——IBM 在相关文章中也讨论了这一区分¹。

1.2 Agent 的定义

AI Agent（智能代理）是一个能够自主完成任务的系统。与聊天机器人不同，Agent 具备以下特征：

主动性（Proactive）：在获得初始目标后，能够自主规划并执行多步骤操作，无需人类在每一步进行干预。
工具使用（Tool Use）：能够调用外部 API、执行代码、读写文件、浏览网页，将自身的能力边界扩展到训练数据之外。
记忆能力（Memory）：能够在会话之间保持状态，记住用户的偏好、项目的上下文、过去的交互历史。
目标分解（Planning）：能够将复杂任务拆解为可执行的子任务，并根据执行反馈动态调整计划。

OpenAI 研究员、前 AI 安全研究负责人 Lilian Weng 在 2023 年 6 月的一篇博客中，将 Agent 的核心组件归纳为 LLM、Memory、Planning 和 Tool Use 四大部分²。业界常将 Agent 架构概括为：

Agent = LLM + Memory + Planning + Tool Use（基于 Lilian Weng 的组件分析²）

这一概括已成为业界理解 Agent 架构的基准框架。Claude Code 正是这一公式的工程化落地——它以 Claude LLM 为大脑，通过工具调用与文件系统和终端交互，借助 CLAUDE.md 和 Auto Memory 实现跨会话记忆，并在每次任务中自主进行规划与执行。

1.3 范式转移的意义

从聊天机器人到 Agent，不仅是功能增强，更是交互范式的根本转移：

维度	聊天机器人	Agent
交互模式	被动响应	主动执行
任务处理	单轮文本生成	多步骤工具调用循环
记忆能力	无（或仅限当前会话）	短期 + 长期记忆
能力边界	训练数据内的知识	训练数据 + 外部工具 + 实时信息
用户角色	操作者（每一步都需参与）	监督者（设定目标后旁观）
错误处理	无（一次性输出）	自我反思、重试、修正

当你对 Claude Code 说"帮我重构这个模块的代码"时，它不会只给你一段重构建议的文字说明。它会：读取相关文件、分析依赖关系、制定重构计划、执行修改、运行测试验证、在失败时调试并重试——整个过程你只需在关键节点确认即可。这就是 Agent 与聊天机器人的本质区别。

二、Planning（规划）：从 CoT 到 ReAct

2.1 Chain-of-Thought：让模型"一步一步想"

要让 LLM 从"回答问题"进化到"执行任务"，首先需要解决的是推理能力。2022 年，Google 研究团队在论文《Chain-of-Thought Prompting Elicits Reasoning in Large Language Models》中提出了**思维链（Chain-of-Thought, CoT）**技术。³

CoT 的核心思想极其简单：在提示词中要求模型"一步一步思考"（think step by step），模型就会在生成最终答案之前，先输出中间的推理步骤。这一简单的技巧显著提升了 LLM 在数学、逻辑推理和符号操作等复杂任务上的表现。

举个例子，面对问题"一个农场有 35 只鸡和 28 只兔子，一共有多少条腿？"，不使用 CoT 时模型可能直接给出一个错误答案；而使用 CoT 后，模型会这样推理：

鸡有 2 条腿，35 只鸡共有 35 × 2 = 70 条腿。
兔子有 4 条腿，28 只兔子共有 28 × 4 = 112 条腿。
总腿数 = 70 + 112 = 182 条腿。

CoT 的革命性意义在于：它将一个"端到端的黑盒预测"转化为"可解释的多步推理过程"。这为后续 Agent 的规划能力奠定了基础。

2.2 Tree of Thoughts：探索多条推理路径

然而，CoT 有一个致命缺陷：它只能沿着一条线性路径推理。一旦某一步出错，后续所有步骤都会建立在错误之上，模型没有"回头"的能力。这就像在迷宫中只能往前走，不能分叉探索。

2023 年，Yao 等人提出了**思维树（Tree of Thoughts, ToT）**框架。⁴ ToT 将推理过程建模为一棵搜索树：

每个节点代表一个"思维"（中间推理步骤）
从每个节点可以分叉出多个子节点（不同的下一步推理方向）
模型通过评估函数判断哪些分支更有希望，然后使用 BFS（广度优先）或 DFS（深度优先）进行搜索

ToT 让 LLM 具备了类似人类"深思熟虑"的能力——不急于给出第一个想到的回答，而是先探索多种可能性，评估后再做选择。这在需要创造性思维或复杂决策的任务中尤为重要。

2.3 ReAct：推理与行动的交响乐

CoT 和 ToT 解决了"如何思考"的问题，但 Agent 还需要"如何行动"。2023 年，Yao 等人在 ICLR 会议上发表了里程碑式的论文《ReAct: Synergizing Reasoning and Acting in Language Models》。⁵

ReAct 的核心洞察是：推理（Reasoning）和行动（Acting）应该交替进行、相互促进。推理帮助模型制定和跟踪行动计划、处理异常情况；行动让模型能够与外部环境（如知识库、API、文件系统）交互，获取推理所需的信息。

ReAct 定义了一个标准的交互循环格式：

Thought: [模型对当前状态的思考]
Action: [模型决定执行的动作]
Observation: [动作执行后从环境获得的结果]
...（循环重复）

这个循环在 Claude Code 中每天都在上演。以下是 ReAct 循环在 Claude Code 中的示意性运作方式：

Thought: 用户报告测试失败，我需要先查看测试输出，找到失败原因。
Action: 运行测试套件（Bash: npm test）
Observation: 测试输出显示 3 个测试失败，错误信息指向 src/utils/auth.ts 的第 42 行。

Thought: 错误与认证模块有关，我需要读取该文件了解上下文。
Action: 读取文件（Read: src/utils/auth.ts）
Observation: 文件内容显示一个 JWT 验证函数，第 42 行使用了已废弃的 API。

Thought: 问题找到了——使用了过时的 JWT 验证方法。我需要修改代码使用新的 API。
Action: 编辑文件（Edit: src/utils/auth.ts）
Observation: 文件修改成功。

Thought: 修改完成，我需要重新运行测试验证修复是否有效。
Action: 运行测试（Bash: npm test）
Observation: 所有测试通过。

这就是 ReAct 循环在真实世界中的运作方式。每一次 Thought 都是规划，每一次 Action 都是工具调用，每一次 Observation 都是环境反馈。通过这个循环，Agent 能够自主地、一步一步地逼近目标。

ReAct 论文的实验结果令人印象深刻：在问答任务 HotpotQA 和事实核查任务 FEVER 上，ReAct 克服了纯 CoT 推理中常见的幻觉和错误传播问题；在交互式决策任务 ALFWorld 和 WebShop 上，ReAct 的绝对成功率分别比模仿学习和强化学习方法高出 34 和 10 个百分点。⁵

2.4 自我反思：从错误中学习

规划不是一次性的。真正强大的 Agent 还需要具备**自我反思（Self-Reflection）**能力——在执行过程中评估自己的表现，从错误中学习，并动态调整计划。

Shinn, Cassano, Berman 等人在 2023 年提出的 Reflexion 框架，为 Agent 增加了动态记忆和自我反思能力。⁶ 在 Reflexion 中，每次行动后，Agent 会计算一个启发式评估：轨迹是否低效？是否出现了幻觉？如果发现问题，Agent 会生成反思文本，将其存入工作记忆，并在后续决策中加以利用。

Claude Code 虽然没有显式实现 Reflexion，但其**自动记忆（Auto Memory）**机制起到了类似的作用。当 Claude 在多次会话中反复犯同一个错误时，用户纠正的信息会被自动记录到 ~/.claude/projects/<project>/memory/ 中，在后续会话中作为上下文加载，从而避免重复犯错。

三、Memory（记忆）：从上下文窗口到向量存储

3.1 人类记忆的启发

在讨论 Agent 的记忆之前，让我们先看看人类记忆的运作方式。心理学将人类记忆分为三个层次：⁷

感觉记忆（Sensory Memory）：保留感官信息的短暂印象，仅持续数秒。
短期记忆 / 工作记忆（Short-Term / Working Memory）：存储当前意识中的信息，容量约为 7 个组块，持续 20-30 秒。
长期记忆（Long-Term Memory）：可存储数天到数十年的信息，容量几乎无限。分为显性记忆（事实和事件）和隐性记忆（技能和程序）。

Lilian Weng 在她的博客中指出，LLM Agent 的记忆系统可以与人脑记忆建立大致的映射：²

人类记忆	Agent 记忆	对应机制
感觉记忆	嵌入表示	文本/图像的 Embedding
短期记忆	上下文学习	Transformer 的有限上下文窗口
长期记忆	外部向量存储	Vector Store + 快速检索

3.2 短期记忆：上下文窗口

LLM 的上下文窗口（Context Window）就是它的短期记忆。所有输入的提示词、历史对话、读取的文件内容，都占据这个有限的空间。当前主流模型的上下文窗口从 128K 到 2M 不等（2M 为 Gemini 系列，Claude 3.5 为 200K，GPT-4 为 128K），但无论如何，它都是有限的。

上下文窗口的限制带来了几个实际问题：

历史信息丢失：长会话中，早期的对话内容可能被挤出窗口。
注意力稀释：窗口中信息过多时，模型对每条信息的关注度会下降。
成本增加：上下文越长，推理成本越高。

Claude Code 通过**压缩（Compaction）**机制应对这一限制。当会话上下文接近上限时，系统会自动将旧的工具输出清除，必要时对对话历史进行摘要。用户也可以手动执行 /compact 命令来压缩会话。Anthropic 的官方文档建议：如果你想让某些指令在长会话中持久生效，不要只依赖对话历史，而应该将它们写入 CLAUDE.md 文件。⁸

3.3 长期记忆：向量存储与 Embedding

为了突破上下文窗口的限制，Agent 需要长期记忆——一种能够在会话之间持久保存、并在需要时快速检索的信息存储机制。

标准的做法是使用向量存储（Vector Store）：

嵌入（Embedding）：将文本、代码或其他信息通过 Embedding 模型转换为高维向量。语义相近的内容在向量空间中距离更近。
存储：将这些向量存入专门的数据库（如 FAISS、Pinecone、Weaviate、Chroma 等）。
检索：当需要回忆时，将查询转换为向量，通过**最大内积搜索（Maximum Inner Product Search, MIPS）**找到最相关的记忆片段。

为了提高检索速度，通常使用**近似最近邻（ANN）**算法。常见的选择包括：²

HNSW（Hierarchical Navigable Small World）：构建多层小世界图，上层创建快捷路径，下层精细化搜索。
FAISS（Facebook AI Similarity Search）：通过向量量化和聚类加速搜索。
ANNOY（Approximate Nearest Neighbors Oh Yeah）：使用随机投影树进行高效搜索。

3.4 Claude Code 的记忆系统

Claude Code 的记忆系统分为两个互补的层次：⁸

CLAUDE.md——用户定义的规则记忆

这是由用户编写的持久化指令文件，存储在项目根目录（./CLAUDE.md 或 ./.claude/CLAUDE.md）或用户主目录（~/.claude/CLAUDE.md）。每个新会话开始时，这些文件会被完整加载到上下文中。它们包含：

项目的构建命令和测试流程
代码风格和架构约定
"总是做 X" 或 "绝不做 Y" 的硬性规则
项目结构和关键文件路径

CLAUDE.md 的加载遵循目录层级规则：从当前工作目录向上遍历，加载沿途发现的所有 CLAUDE.md 文件。对于大型项目，还可以使用 .claude/rules/ 目录将规则按主题拆分，并通过 paths 字段限定规则适用的文件范围。

Auto Memory——自动积累的经验记忆

这是 Claude 自动维护的学习笔记，存储在 ~/.claude/projects/<project>/memory/ 目录下。每次会话中，Claude 会根据用户的纠正和反馈，自动决定哪些信息值得记住：

构建命令和调试技巧
代码风格偏好
架构决策和约定
反复出现的问题和解决方案

MEMORY.md 作为索引文件，在每个会话开始时加载前 200 行或 25KB。详细笔记存放在独立的主题文件中（如 debugging.md、api-conventions.md），Claude 在需要时按需读取。

这两种记忆系统的对比如下：

特性	CLAUDE.md	Auto Memory
作者	用户	Claude 自动
内容	规则和指令	学习和经验
范围	项目/用户/组织级	每个工作树独立
加载方式	每会话完整加载	每会话加载索引
用途	指导行为	避免重复犯错

四、Tool Use（工具使用）：从 Function Calling 到 MCP

4.1 工具使用的必要性

LLM 的知识受限于训练数据，存在三个根本缺陷：²

知识截止：模型不知道训练数据截止日期之后发生的事件。
无法行动：模型不能直接执行代码、查询数据库或调用 API。
专业领域薄弱：对于高度专业化的领域（如特定公司的内部系统），训练数据覆盖不足。

**工具使用（Tool Use）**正是为了解决这些问题。通过让 LLM 学会调用外部工具，Agent 的能力边界被大大扩展。

4.2 Function Calling：工具使用的基石

Function Calling（函数调用）是 OpenAI 在 2023 年推出的 API 功能，现已成为业界标准。其核心机制是：⁹

开发者在 API 请求中提供一组工具定义（JSON Schema 格式），描述每个工具的名称、用途和参数。
LLM 在生成回复时，如果发现需要使用工具，会输出一个工具调用请求（包含工具名称和参数）。
应用程序接收到请求后，执行实际的工具函数，并将结果返回给 LLM。
LLM 根据工具返回的结果，生成最终的回复。

以天气查询为例：

// 工具定义
{
  "name": "get_weather",
  "description": "获取指定城市的当前天气",
  "parameters": {
    "type": "object",
    "properties": {
      "city": {"type": "string", "description": "城市名称"}
    },
    "required": ["city"]
  }
}

// 模型输出的工具调用
{"city": "北京"}

// 工具执行结果
{"temperature": 22, "condition": "晴朗", "humidity": "45%"}

// 模型生成的最终回复
"北京今天天气晴朗，气温 22°C，湿度 45%，非常适合外出。"

Claude Code 内置了丰富的工具集，按功能分类包括：¹⁰

文件操作：Read（读取）、Edit（编辑）、Write（写入）
搜索：Grep（文本搜索）、Glob（文件匹配）
执行：Bash（终端命令）
网络：WebFetch（网页获取）
代码智能：LSP（语言服务器协议，支持跳转定义、查找引用等）

4.3 MCP：工具使用的标准化

2024 年 11 月，Anthropic 推出了模型上下文协议（Model Context Protocol, MCP）——一个开放标准，旨在统一 AI 系统与外部工具、数据源的集成方式。¹¹

MCP 的设计灵感来自软件开发中的语言服务器协议（LSP）。就像 LSP 让编辑器能够统一对接各种编程语言的智能提示一样，MCP 让 AI Agent 能够统一对接各种外部工具和数据源。

MCP 的核心架构采用客户端-服务器模式：

MCP 客户端：AI 应用（如 Claude Code）内置的 MCP 客户端。
MCP 服务器：为特定数据源或工具提供标准化接口的适配器。

通过 MCP，Claude Code 可以连接到：¹⁰

数据库（PostgreSQL、SQLite 等）
版本控制系统（Git）
文件系统
第三方 API（Slack、Notion、Jira 等）
浏览器自动化工具（Playwright）

MCP 的一个重要设计是按需加载：工具定义默认延迟加载，只有工具名称占用上下文空间，直到实际使用时才加载完整定义。这有效避免了扩展能力带来的上下文膨胀问题。¹⁰

4.4 工具使用的层次

Li 等人在 2023 年提出的 API-Bank 基准，将 Agent 的工具使用能力分为三个层次：¹²

Level-1：调用 API。给定 API 描述，模型需要判断是否需要调用、如何正确调用、如何响应返回结果。
Level-2：检索 API。模型需要搜索可能解决用户需求的 API，并通过阅读文档学习如何使用。
Level-3：规划 API 调用。面对模糊的用户需求，模型需要进行多次 API 调用的规划，按正确顺序执行。

Claude Code 在日常使用中展现了 Level-3 的能力。例如，当用户说"帮我部署这个应用到生产环境"时，Claude Code 可能需要：读取部署配置文件、检查环境变量、运行构建命令、调用部署 API、验证部署结果——这一系列操作涉及多个工具的协调使用。

五、三要素协同：以 Claude Code 为例

5.1 一个完整任务的解剖

让我们以一个真实的开发任务为例，观察 Claude Code 中 Planning、Memory 和 Tool Use 如何协同工作：

用户请求："给这个项目添加用户认证功能，使用 JWT，包括登录和注册接口。"

Planning（规划）：

Claude Code 首先进行任务分解：

了解项目技术栈（通过读取 package.json、框架配置文件）
检查现有代码结构（路由、模型、中间件的目录组织）
设计认证模块的架构（路由、控制器、服务层、数据库模型）
实现注册接口（输入验证、密码哈希、数据库写入）
实现登录接口（凭证验证、JWT 签发）
添加认证中间件（保护需要登录的路由）
编写测试
运行测试验证

这个规划不是一次性完成的，而是在执行过程中动态调整的。如果 Claude 发现项目使用了 Prisma 而非 Mongoose，它会调整数据库模型的实现方式；如果测试失败，它会重新规划调试步骤。

Memory（记忆）：

在整个过程中，记忆系统持续发挥作用：

CLAUDE.md 告诉 Claude："本项目使用 TypeScript + Express + Prisma + PostgreSQL"、"API 路由放在 src/api/routes/ 目录"、"所有接口需要 Swagger 文档"。
Auto Memory 提醒 Claude："上次添加类似功能时，测试数据库需要手动迁移"、"用户偏好使用 bcrypt 而非 argon2 进行密码哈希"。
上下文窗口 维护当前会话的对话历史和已读取的文件内容。

Tool Use（工具使用）：

每一步规划都通过具体的工具调用实现：

Read(package.json)        → 了解依赖和脚本
Read(src/app.ts)          → 了解应用入口和中间件注册方式
Read(prisma/schema.prisma) → 了解数据模型
Edit(prisma/schema.prisma) → 添加 User 模型
Bash(npx prisma migrate dev) → 执行数据库迁移
Write(src/api/routes/auth.ts) → 创建认证路由
Edit(src/app.ts)          → 注册认证路由
Bash(npm test)            → 运行测试

每个工具调用的结果（Observation）都会反馈给模型，影响下一步的 Thought 和 Action。这就是 ReAct 循环的真实运作。

5.2 子代理：分层规划与上下文隔离

对于特别复杂的任务，Claude Code 还会使用子代理（Subagent）。子代理是在独立上下文窗口中运行的专门化 AI，拥有自己的工具权限和记忆。¹⁰

例如，在上述认证功能开发中，Claude Code 可能委派一个专门的安全审查子代理。以下示意性配置展示了子代理的典型定义方式：

name: security-reviewer
description: 审查代码安全漏洞
tools: Read, Grep, Glob
model: opus
permissionMode: plan  # 示意字段，请以官方文档为准

这个子代理在只读模式下审查认证代码，检查 SQL 注入、密码存储安全、JWT 配置等问题，然后返回审查报告。主代理根据报告决定是否需要修改。

子代理的价值不仅在于专业化，更在于上下文管理——子代理的详细工作（如遍历大量文件）不会占用主代理的上下文窗口，只有最终摘要返回给主代理。¹⁰

5.3 安全边界：规划与执行的约束

Claude Code 的架构中，Planning、Memory 和 Tool Use 并非无约束地运行。Anthropic 设计了一套分层治理机制来确保安全：¹⁰

权限模式（Permission Mode）：官方提供四种主要模式，用户可以根据任务敏感度选择：default（需逐条确认）、acceptEdits（自动接受编辑）、plan（计划模式，只读分析后生成计划）、bypassPermissions（跳过权限提示，适用于 CI/容器环境）。CLI 另有 --dangerously-skip-permissions 选项。
沙箱（Sandbox）：Bash 命令在 OS 级沙箱中运行（macOS 使用 Seatbelt，Linux 使用 bubblewrap），限制文件系统和网络访问。
Hooks：在工具执行前触发的用户自定义检查，可以拦截、修改或拒绝工具调用。
Checkpoints：每次文件修改前自动快照，支持代码和对话状态的回溯。

这些安全机制与三要素协同工作：Planning 生成的计划可能包含危险操作，但 Permission Mode 和 Sandbox 会在执行层拦截；Memory 中的 CLAUDE.md 可以包含安全规则（如"绝不修改 .env 文件"），在规划阶段就影响 Agent 的决策。

六、从 LLM 到 Agent：范式转移的深层意义

6.1 从"知识压缩"到"行动系统"

传统 LLM 的本质是知识压缩——将人类语言中的统计规律压缩进模型参数中。当你向 ChatGPT 提问时，它本质上是在做"基于概率的文本续写"。

Agent 则代表了一个根本不同的范式：行动系统（Action System）。LLM 不再是孤立的文本生成器，而是嵌入在一个能够感知环境、制定计划、执行动作、学习反馈的闭环系统中。这个转变的意义堪比从"百科全书"到"机器人"的跨越。

6.2 从"人机交互"到"人机协作"

聊天机器人时代，人机交互的模式是指令-响应：人发出指令，机器给出响应，循环往复。Agent 时代，人机关系进化为协作：人设定目标，Agent 自主执行，人在关键节点监督和纠正。

Anthropic 在《Building Effective Agents》一文中，将 Agentic 系统分为两类：¹³

Workflows（工作流）：LLM 和工具通过预定义的代码路径编排，适合任务明确的场景。Workflows 提供可预测性和一致性。
Agents（代理）：LLM 动态指导自己的流程和工具使用，自主决定如何完成任务，适合开放式问题。Agents 在需要灵活性时更具优势。

两者是互补而非对立的关系——Workflows 适合明确任务，Agents 适合开放问题。Claude Code 同时具备这两种能力：对于简单的文件编辑，它可以遵循预定义的工作流；对于复杂的重构任务，它会进入自主 Agent 模式，动态规划每一步操作。

6.3 从"软件工具"到"软件伙伴"

最深刻的范式转移或许是心理层面的。当开发者使用 Claude Code 时，他们逐渐从"使用一个工具"转变为"与一个伙伴协作"。这个伙伴：

记得项目的每一个细节（Memory）
能够自主规划和执行复杂任务（Planning）
能够调用各种工具与外部世界交互（Tool Use）
会从错误中学习并改进（Self-Reflection）

这不是拟人化的修辞，而是对系统能力的准确描述。正如 Lilian Weng 所说："这可能只是一个新时代的开端。"²

6.4 当前局限与未来方向

尽管 Agent 技术已经取得显著进展，但仍面临挑战：²

有限的上下文长度：上下文窗口仍然是瓶颈，尽管向量存储可以缓解，但其表示能力仍不如完整的注意力机制。
长期规划的困难：面对漫长历史和复杂解空间，LLM 在规划上仍不如人类 robust，遇到意外错误时调整计划的能力有限。
自然语言接口的可靠性：Agent 依赖自然语言作为 LLM 与外部组件（记忆、工具）之间的接口，但 LLM 可能产生格式错误，甚至表现出"叛逆"行为（如拒绝遵循指令）。

Anthropic 的建议是：从最简单的方案开始，只在必要时增加复杂度。对于许多应用，优化单轮 LLM 调用（配合检索和上下文示例）已经足够。当确实需要 Agent 时，应遵循三个核心原则：¹³

保持简单：Agent 的设计应尽可能简洁。
追求透明：明确展示 Agent 的规划步骤。
精心打磨工具接口：通过完善的文档和测试，确保工具易于理解和正确使用。

七、总结

从聊天机器人到 Agent，AI 正在经历一场从"会说"到"会做"的质变。这场质变由三个核心能力驱动：

Planning（规划）：通过 CoT、ToT、ReAct 等技术，Agent 能够将复杂任务分解为可执行的步骤，并在推理与行动的交替循环中逐步逼近目标。
Memory（记忆）：通过短期记忆（上下文窗口）和长期记忆（向量存储 + Embedding），Agent 能够在会话之间保持状态，从经验中学习。
Tool Use（工具使用）：通过 Function Calling 和 MCP 等机制，Agent 能够调用外部 API、执行代码、读写文件，将能力边界扩展到训练数据之外。

Claude Code 是这一范式转移的工程化典范。它以 Claude LLM 为大脑，通过 ReAct 循环自主规划与执行，借助 CLAUDE.md 和 Auto Memory 实现跨会话记忆，通过内置工具和 MCP 扩展与外部世界的交互能力。当你下一次在终端中输入 claude 时，你启动的不只是一个聊天程序，而是一个具备规划、记忆和工具使用能力的智能代理——一个正在与你协作完成软件开发任务的数字伙伴。

参考来源

IBM. "AI Agents vs. AI Assistants." IBM Think, 2025. https://www.ibm.com/think/topics/ai-agents-vs-ai-assistants ↩
Weng, Lilian. "LLM Powered Autonomous Agents." Lil'Log, Jun 2023. https://lilianweng.github.io/posts/2023-06-23-agent/ ↩ ↩² ↩³ ↩⁴ ↩⁵ ↩⁶ ↩⁷
Wei, Jason, et al. "Chain-of-Thought Prompting Elicits Reasoning in Large Language Models." NeurIPS 2022. https://arxiv.org/abs/2201.11903 ↩
Yao, Shunyu, et al. "Tree of Thoughts: Deliberate Problem Solving with Large Language Models." arXiv:2305.10601, 2023. ↩
Yao, Shunyu, et al. "ReAct: Synergizing Reasoning and Acting in Language Models." ICLR 2023. https://arxiv.org/abs/2210.03629 ↩ ↩²
Shinn, Noah, Federico Cassano, Edward Berman, Ashwin Gopinath, Karthik Narasimhan, and Shunyu Yao. "Reflexion: Language Agents with Verbal Reinforcement Learning." arXiv:2303.11366v4, 2023. https://arxiv.org/abs/2303.11366 ↩
Miller, George A. "The magical number seven, plus or minus two: Some limits on our capacity for processing information." Psychological Review, 1956. ↩
Anthropic. "How Claude remembers your project - Memory." Claude Code Docs. https://code.claude.com/docs/en/memory ↩ ↩²
OpenAI. "Function calling." OpenAI API Docs. https://developers.openai.com/api/docs/guides/function-calling ↩
Anthropic. "Claude Code sandboxing." Anthropic Engineering Blog, 2025. https://www.anthropic.com/engineering/claude-code-sandboxing; Anthropic. "Create custom subagents." Claude Code Docs. https://code.claude.com/docs/en/sub-agents ↩ ↩² ↩³ ↩⁴ ↩⁵ ↩⁶
Anthropic. "Model Context Protocol." 2024. https://modelcontextprotocol.io ↩
Li, Minghao, et al. "APIBench: A Benchmark for Tool-Augmented LLMs." arXiv:2304.08244, 2023. https://arxiv.org/abs/2304.08244 ↩
Schluntz, Erik, and Zhang, Barry. "Building Effective Agents." Anthropic Research, 2024. https://www.anthropic.com/research/building-effective-agents ↩ ↩²

LLM 的概率本质

为什么 AI 会"胡说"

Claude Code 的 Agentic Loop 全拆解