《深入理解 AI Agent》笔记 - 1 AI Agent 入门

前言

解释和个人阅读感受

本书《深入理解 AI Agent：设计原理与工程实践》为李博杰所著并开源，地址为：https://github.com/bojieli/ai-agent-book， 截止 2026-09-07 已有 79 位贡献者， star 45k 。

本书的核心观点是：Agent = LLM + 上下文 + 工具。作者开源了图书，并配套了 109 个实验，具体实验这里不做解释，需要的朋友可以在前面的链接自行查看并下载。

我是一位大三的计科学生，主要的方向是 Java web ，但结合我平时的所见所闻，我认为开发岗位与 Agent 的结合是势不可挡的，这也是我慕名学习本书的主要原因之一。

我在阅读时主要看重开发人员应该怎么去认识和使用Agent，实验部分我只会看得出的结论，没有实机测试。因此，这篇笔记可能更适合有同样情况的网友。如果您更希望深入理解其中的原理，我更推荐阅读原书。

而我阅读下来的体验是：虽然我之前没有系统了解 LLM 或 Agent 的原理，但这不影响我的阅读体验，我依然能从零开始理解各家 Agent 的设计结构和思路，并尝试怎么更好使用大模型来进行开发。作者的行文也平实易懂，我推荐大家有时间的话都可以阅读原著。

另外难得的一点是，他是少数成体系且时间上接近当前的书籍，不会出现书中的结论已经过时或被证伪的情况。我第一次在一本书中看到 GPT-5.6 的身影。

要求的前置知识-书中要求

必需：阅读全书的基础

Python 编程：书中几乎所有实验都基于 Python。你需要熟悉 Python 的基本语法、常用的数据结构、包管 理（pip）等基本概念。不要求精通，但应能读懂和修改中等复杂度的 Python 代码。

LLM 的基本使用经验：你应该用过 ChatGPT、Claude 或类似的产品，理解“提示词（Prompt）→ 模型回 复”的基本交互模式。

一款 AI 辅助编程工具：强烈建议安装并熟悉至少一款 AI 辅助编程工具，如 Claude Code、Codex、Cursor、 TRAE 等。一方面，这些工具能显著提高书中实验的开发效率，因为实验涉及大量代码编写和调试。另一方 面，这些编程工具本身就是成熟的 Coding Agent，你在使用它们的过程中会直观地体验到 ReAct 循环、工 具调用、上下文管理等书中反复讨论的核心机制。这种第一手体验对理解 Agent 的设计原则极有价值。

软件工程常识：熟悉命令行操作、Git 版本控制、JSON 数据格式、REST API 等基本概念。这些是运行实 验和理解 Agent 工具调用机制的基础。

推荐：提升特定章节的阅读体验

机器学习基础（第八章）：了解训练与推理、损失函数、梯度下降、过拟合等基本概念，有助于理解模型后训 练。

基础数学（第 2-3、8 章）：对线性代数有直观的理解（比如知道向量可以表示方向和大小、矩阵可以做批量运 算）有助于理解嵌入和注意力机制；基本的概率统计知识有助于理解评估指标和强化学习中的期望奖励。书 中的数学不涉及复杂的推导，侧重直观解释。

Web 开发基础（第 6 章）：了解 HTTP、WebSocket、前后端分离架构等概念，有助于理解事件驱动的异步 Agent 架构和语音 Agent 的实时通信实验。

对 Transformer 架构的基本了解（第 2、8 章）：Transformer 是当前几乎所有大语言模型的底层架构。对于 希望系统地补充大模型基础知识的读者，推荐阅读《图解大模型》（图灵出版）。该书以直观的图解方式讲解 了 Transformer 架构、预训练与微调等核心概念，与本书的 Agent 工程视角形成良好的互补。

第一章总观

从多个真实 Agent 产品出发，建立对 Agent 的直观理解。深入解析 Agent 的核心公式：从实现层的 LLM + 上下文 + 工具，到直觉层的大脑 + 眼睛 + 手脚，再到学术层的策略（Policy）、观察空间（Observation Space）与动作空间（Action Space）。同时通过实验剖析 ReAct 循环的运作机制，也就是“思考 → 行动 → 观察”的迭代过程，并区分任务内的上下文适应、跨任务的外部产物（artifact）更新和 训练周期中的参数更新。最后讨论从工作流到自主 Agent 的编排设计模式，为后续章节建立统一的概念框架。

对总观点的解释

Agent = LLM + 上下文 + 工具

• LLM 是 Agent 的大脑：它不只是一组模型参数，而是 Agent 的整个决策内核——理解意图、思考规划、做出 判断。就像人类大脑不只是神经元的集合，还包括通过经验塑造的思维方式，LLM 的能力也来自两部分：预 训练所积累的世界知识与语言能力，以及后训练所固化的决策策略——后者的具体技术（如监督微调与强化 学习）将在第八章展开。
• 上下文是 Agent 的眼睛：它不只是输入给模型的那段文本，而是 Agent 在每个决策点收到并保留的信息表示 ——来自环境的观察、用户记忆、领域知识、自身状态和任务进展。
• 工具是 Agent 的手脚：这里的“工具”指 Agent 用来感知或改变外部世界的接口，包括工具定义、调用协议和 适配器——从预定义的工具调用到动态生成代码，从委托子 Agent 协作到主动与用户沟通。

Agent = Model + Harness

Harness

Harness 把环境返回的观察转换为模型能够处 理的上下文，再把模型选择的行动转换为对环境的工具调用。没有通过观察通道进入上下文的信息，对模型来说就 像不存在；没有被动作接口允许的操作，模型即使知道该怎么做，也只能停留在文字建议上。

Manus

合并原本分离的空间。在 Manus 出现之前，生产级 Agent 大多沿着 Deep Research（深度调研）、 Coding（代码生成）和 Computer Use（电脑操控）三条相对独立的路线发展。Manus 的突破在于率先把三者放进 同一个有广泛影响力的生产级 Agent：虚拟浏览器扩大了观察空间，文件系统、代码执行与命令行执行扩大了动作 空间。它没有仅靠替换一个更强的模型来成为通用 Agent，而是取三类 Agent 观察空间与动作空间的并集，使同一 个 Agent 能跨越原有产品边界完成任务。

OpenClaw

把接口延伸到用户的数字生活。 OpenClaw 又把这两个空间向外推进了一层。它通过用户已经在使用的 WhatsApp、Telegram、Slack、Discord、iMessage 等消息渠道接收任务和返回结果，让 Agent 可以随时随地被触达；同时采用本地 Gateway，连接 Google Drive、Notion 等云应用以及本地文件系统。这样一来，分散在不同账号与设备中的数字文件都可以在用户明确授权后进入同一个 Agent 的观察空间，并被其工具处理。相较于早期 Manus 以隔离云端沙盒为中心、往往需要上传文件或另行配置连接器的形态，本地优先的 OpenClaw 跨越了更大的数据边界。值得注意的是，Manus 后来也加入了 Google Drive 连接器和桌面端本地访问，这恰好再次说明，产品能力的演进往往就是观察空间和动作空间的演进。

这里顺便纠正一个观念：小龙虾本身不是模型、小龙虾本身不是模型、小龙虾本身不是模型！它更像是一层外置框架，去对模型塑形。你可以在小龙虾中使用各类支持的模型，但不存在 小龙虾 > gpt 之类的比较关系。

工具

只有调用了工具，Agent 才能真正读取并进行操作。这也是我认为 Agent 突飞猛进的一点：在之前，你让 AI 写文案，AI只能输出一段 markdown ，需要你自己调整为合适的格式。但现在， AI 可以直接调用工具生成pdf、pptx或你需要的格式，只要工具中有申明。许多MCP、Skill也是为了让 Agent 更好调用工具。

工具调用（Tool Calling / Function Calling）

是现代 LLM Agent 的一项核心能力，它让模型能够通过结 构化的方式调用外部工具。这种能力将 LLM 从一个纯粹的文本生成器转变为能够执行实际操作的智能系统。本书 后续统一使用“工具调用”这一术语。

工具调用的流程分为四步：首先，在上下文里告诉模型有哪些工具可用（包括名称、用途和参数）；然后，模型 自主判断要不要调用工具、调用哪个、传什么参数；接着，工具执行完毕后，结果被追加到上下文中；最后，模型 据此决定下一步行动。这个循环就是后文要介绍的 ReAct 的基础。

以一个查天气的场景为例，四步流程在 API 层面的简化表示如下：

第一步：声明工具 
tools: [{
  name: "get_weather",
  parameters: {
    city: "string"
  }
}]
第二步：模型决定调用
assistant: {
  tool_calls: [{
    function: "get_weather",
    arguments: {city: " 北京"}
  }]
}
第三步：结果追加到上下文 
tool: {
  tool_call_id: "call_1",
  content: '{"temp":28,"sky":" 晴"}'
}
第四步：模型基于结果回复
assistant: {
  content: " 北京今天 28°C、晴。"
}

LLM

大语言模型（Large Language Model, LLM）是 Agent 的决策核心。收到用户的请求后，它需要先解析真实 意图（用户说的往往不是他真正想要的），再将模糊或复杂的任务拆解成可执行的步骤。执行过程中它还要持续做出 判断：下一步该做什么、要不要调用工具、调哪个工具、传什么参数。这种“理解-规划-执行”的能力来自预训练所积 累的知识，是工作流和自主 Agent 都依赖的基础。

模型即 Agent：能力内化，但 Harness 仍然重要

一些先进模型通过后训练，尤其是强化学习，将工具调用策略内化为原生能力：何时调用工具、调用哪个工具、传什么参数，都可以由模型自行决定。这里需要区分“决策”和“执行”：强化学习写入模型参数的是决策策略，工具本身的实现、权限、调用循环和结果回传仍由 Agent 框架或 API 服务端完成。

模型越能自主决策，出错时的影响面也越大，因此围绕模型的 Harness 并不会消失。它负责上下文管理、工具接口、安全约束、验证和纠正，把模型能力引导成可靠的任务执行。

Agent 的学习机制：三种更新路径

Agent 的行为改变不只发生在训练阶段，可以按更新位置和持续时间分成三条路径：上下文适应是在当前任务中加入示例、状态或检索结果，立即生效但不会跨会话保留；外部产物更新是把事实写入知识文档，把策略写入 Prompt 或 Skill，把确定性约束写进程序和 Harness，能够跨任务积累且便于审计；参数更新则通过后训练改变模型本身，适合内化难以用规则表达的通用能力，但成本和部署风险更高。

上下文

从 API 的视角看，每次调用 LLM 时的上下文由以下五个部分构成：

• 系统提示词（System Prompt）：与用户每次输入的提示词不同，系统提示词由开发者编写，在整个对话过 程中保持不变，相当于 Agent 的“岗位说明书”——定义它的身份、权限和行为准则。通过提示工程（Prompt Engineering）精心设计系统提示词，我们可以塑造 Agent 的工作方式。系统提示词中还会包含跨会话保存的 用户记忆（用户偏好、历史行为、背景设定等个性化信息，详见第三章）和动态注入的环境状态。
• 工具定义（Tool Definitions）：声明 Agent 可用工具的名称、功能描述和参数格式。没有工具定义，Agent 就 无法识别和调用任何工具——消融实验（实验 1-1）将验证这一点。工具定义与系统提示词一起构成对话中保 持不变的静态前缀（这是基础模式；2026 年以来，生产框架中工具的完整 schema 也可以按需动态加载到上 下文末尾而不破坏前缀，详见第二章工具定义一节和第四章）。
• 用户消息（User Messages）：来自用户的输入。用户消息中还可能包含通过 RAG（检索增强生成，Retrieval- Augmented Generation，详见第三章）动态检索引入的外部知识——覆盖训练数据截止后的信息或私有领域 知识。
• 模型回复（Assistant Messages）：模型之前生成的回复，最多包含三个部分——思考过程（reasoning，即内 部思考链，用于保持思维的连贯性和决策的可解释性）、文本内容（content，即对用户的回复）和工具调用 请求（tool_calls，即 Agent 采取行动的方式）。在一次具体的回复中，三者不一定同时出现：例如 Agent 决定调用工具时通常只有 reasoning + tool_calls，给出最终回答时通常只有 reasoning + content。
• 工具执行结果（Tool Results）：Agent 框架执行工具后返回的结果。这些结果是 Agent 下一步思考的直接依 据，也让它能够从执行结果中学习、避免重复犯错。

前两项（系统提示词 + 工具定义）是静态前缀，后三项（用户消息 + 模型回复 + 工具执行结果）是随交互不 断增长的动态消息历史。这五个部分共同构成了 LLM 每次推理时的上下文。

消融实验

此处为了体现各模块的重要性，进行了消融实验：

工具定义（Tool Definitions，静态前缀的一部分）是 Agent 行动能力的基础，没有它，Agent 就无法识别和调用任何工具。工具执行结果（Tool Results）是闭环控制的关 键，缺失它会导致 Agent “盲目”执行，陷入无限循环。思考过程（模型回复中的 reasoning 部分）保留了 Agent 此前做出决策的原因，使思维流程更加连贯，避免做出前后矛盾的决策。历史消息（之前轮次的用户消息、模型 回复和工具执行结果）则防止了冗余操作，保持任务执行的连贯性，避免重复犯同样的错误。

ReAct 循环

Agent 执行任务的核心模式叫做 ReAct（Reasoning + Acting）。虽然名字只体现了思考（Reasoning）和行动 （Acting）两个词，但实际循环包含三个环节：模型先思考当前应该做什么，然后调用工具行动，再观察工具返回的 结果并继续思考下一步。这个“想 → 做 → 看 → 想 → 做 → 看”的循环不断重复，直到任务完成。

Harness 工程：从“能做事”到“可靠地做事”

如果把 LLM 看作 Model，那么 Agent 边界内围绕模型运行的代码、配置和服务可以统称为 Harness。生产形态可以写成：Agent = Model + Harness，其中 Harness = 上下文管理 + 工具接口 + 约束 + 验证 + 纠正。前两项让 Agent 能理解任务并采取行动，后三项负责限制危险行为、检查结果并在失败时重试、回退或交给人处理。

Harness 不包括它所操作的环境本身：工具适配器、权限和沙箱属于 Harness，沙箱中的文件、进程、数据库和网页属于 Environment。生产系统的主要工程量往往不在调用模型，而在这些运行与治理机制上。

发展历程

提示工程（Prompt Engineering）是第一波创新——通过优化输入给模型的自然语言指令来提升输出质量。 上下文工程（Context Engineering）是第二波——人们认识到单纯优化提示词还不够，需要系统性地管理模型 能看到的所有信息（系统指令、工具定义、对话历史、外部知识）。

Harness 工程是第三波——它将视野从“模型能看到什么”进一步扩展到“Agent 如何组织模型运行并与环境交 互”，涵盖上下文与工具接口、约束机制、验证手段、反馈循环和错误恢复等 Agent 边界内、模型之外的运行与治理 机制。

随后出现的 Loop 工程（Loop Engineering）又把视野从单次运行扩展到跨轮次的持续自主运转：谁来发现下 一件该做的事、何时验证、何时才算真正完成（第十章将结合多 Agent 协作系统展开）。

2026 年 7 月，业界又开始用 Graph 工程（Graph Engineering）描述一种更高层的编排视角：把 Agent 循环、 确定性程序和人工审批组织成显式的执行图，其中节点承担具体能力，边规定路由与依赖，结构化状态沿边传递并 在关键边界处持久化。

工作流与自主 Agent

工作流把 LLM 和工具放进开发者预先定义的固定路径，适合步骤明确、合规要求严格的任务；自主 Agent 则根据环境反馈动态决定下一步，适合开放式、步骤数量难以预估的任务，但会付出更多延迟、成本和复合错误风险。实践中常把两者混合：关键边界使用确定性流程，灵活部分交给自主循环。选择顺序通常应是：先尝试单次模型调用，再考虑工作流，只有确实需要动态决策时才引入自主 Agent，并为其设置最大迭代次数、错误处理和人工检查点。

成功的 Agent 系统遵循三个核心原则

保持简单。从最简单的方案开始，只在确实必要时才增加复杂度。直接的 API 调用优于复杂的框架，清晰的代 码优于聪明的抽象。因为每多一层抽象都会成为以后调试时新的盲区。

保持透明。明确显示 Agent 的规划步骤、执行日志和决策轨迹——这不只是为了调试方便，也是让用户建立信 任的前提。因为黑箱里的错误一旦发生，外部观察者既无法定位也无法纠正。

设计好工具接口（ACI，Agent-Computer Interface）。ACI 强调的是从 Agent 视角设计接口（让 Agent 容易 理解和使用），而非传统 API 从程序员视角设计接口。工具的命名和参数要直观，容易误用的地方要从设计上让错 误无法发生——比如 SIM 卡的缺角让卡片只能从一个方向插进卡槽，避免了用户插反的错误；微波炉门没关好就 绝不加热，避免了用户开门加热的危险行为。这种“用设计消除错误”的思路，在制造业里有一个专门的术语，叫防 呆（Poka-yoke），源自丰田生产体系。设计不好的工具会让再强的模型也频繁出错——因为模型与工具之间唯一的 沟通通道就是接口本身，模糊的接口会被模型放大成系统性的错误。

护栏与安全性

护栏（Guardrails）构成了保障 Agent 行为安全可控的分层防线，可用于管理数据隐私风险（例如防止系统提 示泄露）或声誉风险（例如确保模型行为与品牌形象一致）。实践中可以先针对已识别的风险设置护栏，再在发现新 漏洞时逐步添加。本节只做高层次的概览，确立全书统一的分层骨架；具体的实现细节将在第二章（上下文层：提 示注入防护）、第四章（执行层：工具权限控制）和第五章（执行层与数据层：代码执行安全、信任边界下移）分别 展开，初次阅读无需深究。

单个护栏不太可能提供足够的保护，多个专门的护栏组合使用，才能构建出更有韧性的 Agent 系统。 护栏也存在另一类失败：误拒绝。为了降低危险请求被放行的概率，模型可能同时拒绝一部分合法但形式敏感 的任务，例如经过授权的安全测试、模型蒸馏研究。因此，护栏评估不能只测试“应当拒绝的请求是否被拦截”，还要 测试“明确允许的请求是否能够正常完成”。

设计模式

提议者—审核者（Proposer-Reviewer）：产出与评判由两个不共享上下文的角色分别承担，评判方看到的是产 物本身——渲染结果、测试输出、结构化的调用参数——而不是产出方的推理过程。它成立的前提是自审不可靠：同 一个上下文中的模型难以发现自己的认知盲区，也很难判断自己是否已被注入。第三章用它更新知识，第四章用它 做工具调用的事前审批与事后验证（Sidecar 是它的一个只读变体），第五章的 PPT、视频与日志三个实验都以它 为骨架，第七章用它评估 UI，第九章用它审核更新提案，第十章讨论了它在对等协作中的形态，以及为什么不能让 同一个 Agent 自审。

渐进式披露（Progressive Disclosure）：不把全部信息一次性放进上下文，而是先给一份可检索的目录，再按 需加载细节。它同时优化两件事——上下文预算与选择精度。第二章的 Agent Skills 是最典型的形态（元数据常驻、 正文按需加载），第三章的分层检索、第四章的主动工具发现与分页截断、第十章的 Agent 发现都是它的变体。 只增不改（Append-only）：状态以追加的方式演进，已经写下的内容不再回头修改。换来的是可缓存、可重放、 可审计。第二章的 KV Cache 前缀稳定性是它的性能形态——改动越靠前，作废的缓存越多；第三章的事件式记忆、 第四章把新工具的 schema 追加到轨迹末尾而不是插回前缀，都是同一条纪律。

边界集 + 保留集（Boundary Set + Retention Set）：任何一次修改都要同时在”它应当改变的那批样本”和”它 不应当影响的那批样本”上验证。只测前者会把过拟合当成进步，只测后者会把无效修改当成安全。第七章的回归任 务、第八章的训练与评估隔离、第九章的更新提案验证都建立在这对集合上。

最小 diff + 可回滚：每次修改尽量小、带来源、可单独回滚，而不是整体重写。它让归因成为可能——出了问 题能定位到具体哪一次改动。第三章的知识更新、第五章的代码补丁、第九章的 Prompt 与程序更新都遵循这条； 本章开头给出的三条更新路径（上下文内适应、外部产物更新、参数更新），也正是按可回滚程度从高到低排列的。