《深入理解 AI Agent》精读教程：从上下文工程到持续进化

Yung原创2026/8/21大约 25 分钟

《深入理解 AI Agent》精读教程：从上下文工程到持续进化

本文依据李博杰《深入理解 AI Agent：设计原理与工程实践》v2.0（2026-08-20）整理。书中观点、本文的工程化解释和成书后的当前补充会明确区分。本文不是原书逐字摘录，而是一篇可独立学习、可用于项目设计的章节化教程。

先建立一张地图

Agent 不是“更会聊天的 LLM”，而是一个让模型在受约束的环境中观察、决策、执行、接收反馈并持续推进任务的系统：

用户目标
  -> 上下文装配
  -> LLM 决策
  -> 工具/代码/交互动作
  -> 环境观察结果
  -> 状态与记忆更新
  -> 继续循环或结束

这条主线贯穿全书：

第 1 章定义 Agent 的观察空间、动作空间和 Harness。
第 2 章解释上下文如何决定能力上限，以及缓存、提示、Skill、状态栏和压缩。
第 3 章处理跨回合记忆与知识检索。
第 4 章把能力设计成工具，并讨论 MCP、感知工具、执行工具和渐进式发现。
第 5 章把 Agent 放进代码仓库，讨论 Coding Agent 和通用 Agent。
第 6 章扩展交互边界，引入异步事件、用户沟通、语音和多模态。
第 7 章建立评估体系。
第 8 章讨论模型后训练如何改变 Agent 能力。
第 9 章讨论从反馈、轨迹到持续进化。
第 10 章讨论多 Agent 的分工、通信和协作代价。

章节总览

顺序	章节	要回答的问题	学习产出
引言	全书方法	为什么 Agent 应按系统而非 Prompt 学习	建立“模型—上下文—工具—环境”视角
1	AI Agent 入门	Agent 与普通调用的差异是什么	能画出观察/动作循环和 Harness
2	上下文工程	如何让模型在有限上下文中获得正确信息	能设计消息、缓存、提示、Skill、状态和压缩
3	用户记忆和知识库	什么该记住，什么应该检索	能设计记忆分层与混合 RAG
4	工具	如何把外部能力安全暴露给模型	能设计工具契约、权限和渐进发现
5	Coding Agent 与通用 Agent	为什么代码能力是通用 Agent 的基础	能设计搜索、编辑、执行和恢复闭环
6	交互	Agent 如何接收主动事件并与人协作	能设计异步、语音、多模态和隔离执行
7	Agent 的评估	如何判断 Agent 真的变好了	能评估任务、轨迹、工具和安全
8	模型后训练	训练如何塑造工具使用和执行能力	能区分预训练、SFT、偏好和 Agent 训练
9	Agent 的持续进化	如何让系统从失败中改进	能构建反馈、轨迹、记忆和版本闭环
10	多 Agent 协作	什么时候拆分 Agent，如何控制协作成本	能选择单 Agent、子 Agent 或多 Agent

引言：不要把 Agent 学成 Prompt 技巧

书中把 Agent 放在一个完整系统中理解：模型只是决策核心，真正决定可用性的还有上下文、工具、环境、状态、权限、评估和运行时 Harness。这个视角解释了为什么同一个模型在 Demo 中很聪明，进入生产后却会因为工具描述不清、上下文过长、权限缺失或没有恢复机制而失败。

Harness 是什么

Harness 可以理解为包裹在模型外面的运行时：

输入规范化
  -> 上下文构建
  -> 模型调用
  -> 工具路由与权限检查
  -> 结果校验
  -> 状态持久化
  -> 观测、限流、重试、停止

它的价值不在于让模型“更聪明”，而在于把不应该交给模型的确定性约束放回程序。用户权限、金额校验、文件路径、超时、幂等和审计都必须由 Harness 强制执行。

原书观点与本文补充

原书内容：Agent 的核心是模型与世界之间的观察空间和动作空间，Harness 是模型之外的重要工程竞争力。
本文补充：在当前 API 产品中，工具调用、结构化输出、模型路由和 tracing 通常由 SDK 处理一部分，但不能替代业务侧的授权、状态机和审计。

第 1 章：AI Agent 入门

1.1 现代 Agent = LLM + 上下文 + 工具

一个最小 Agent 至少包含：

LLM：根据当前上下文选择下一步。
上下文：系统指令、用户目标、历史消息、工具定义和观察结果。
工具：查询、检索、写文件、执行代码、发送消息等动作。
环境：数据库、文件系统、浏览器、业务 API 或真实世界设备。
循环控制：决定继续、重试、暂停、请求确认或结束。

没有工具时，模型只能产生动作建议；没有上下文时，模型无法知道目标和约束；没有循环控制时，工具调用就无法形成任务执行。

1.2 观察空间与动作空间

观察空间是 Agent 能看到的信息，例如用户消息、工具结果、文件内容、日志和截图。动作空间是 Agent 可以提出的行为，例如调用工具、写文件、执行命令、发送回复。

观察：订单 1001 已付款，库存为 0
决策：查询补货时间
动作：调用 get_restock_eta(sku)
观察：预计明天到货
决策：向用户解释并询问是否创建工单

动作空间越大，能力上限越高，风险面也越大。设计时应遵循最小权限：只暴露完成任务所需的动作，不要把数据库 root、任意 Shell 或无限制网络访问直接交给模型。

1.3 ReAct 循环

ReAct（Reasoning and Acting）把推理与行动交替起来：

目标 -> 选择动作 -> 观察结果 -> 更新判断 -> 选择下一动作

工程实现不需要把内部思维过程原样暴露给用户。应用应记录结构化轨迹（决策摘要、工具名、参数、结果、耗时和错误），而不是依赖模型输出一段不可验证的“思考文字”。

1.4 Harness 的五类能力

可以把 Harness 拆成五组：

上下文装配：消息、工具、记忆、检索结果和状态栏。
循环控制：最大步数、超时、重试、停止条件和人工确认。
能力执行：工具路由、参数校验、权限、沙箱和幂等。
状态与观测：任务状态、轨迹、指标、日志和回放。
安全护栏：输入输出过滤、提示注入防护、数据隔离和降级。

1.5 什么时候不用 Agent

流程固定、输入结构稳定、结果需要严格确定时，优先使用普通服务或 Workflow。比如“上传文件→抽取文本→生成向量→入库”不需要让模型动态规划每一步。开放任务、步骤依赖中间结果、需要多工具组合时，才有 Agent 的价值。

第 2 章：上下文工程

上下文工程是全书的核心。Prompt 只是上下文的一部分；真正要优化的是“在正确位置、以正确格式、以合理成本，把模型下一步所需的信息送进去”。

2.1 API 消息结构

典型对话由四类角色构成：

[
  {"role": "system", "content": "你是订单助手，不能绕过权限。"},
  {"role": "user", "content": "查询订单 1001。"},
  {"role": "assistant", "tool_calls": [{"name": "get_order", "arguments": {"id": "1001"}}]},
  {"role": "tool", "tool_call_id": "call_1", "content": "订单已付款，库存为 0"}
]

角色表达的是消息来源和信任层级。工具结果不能被当成新的系统指令；外部网页、用户上传文档和检索片段都属于不可信数据，必须在上下文中明确标记为资料，而不是命令。

2.2 带工具调用的核心循环

伪代码如下：

messages = [system_message, user_message]

for step in range(MAX_STEPS):
    response = model.chat(messages=messages, tools=tool_schemas)
    messages.append(response.message)

    if not response.tool_calls:
        return response.text

    for call in response.tool_calls:
        tool = registry.require(call.name)
        args = tool.schema.validate(call.arguments)
        authorization.require(user, tool, args)
        result = tool.execute(args, context=execution_context)
        messages.append(tool_result(call.id, sanitize(result)))

raise AgentStopped("超过最大步骤数")

关键点是：模型只能提出调用意图，真正的工具查找、参数校验、授权和执行由后端完成。工具失败时返回结构化错误，让模型决定重试、换工具或向用户说明，不要吞掉错误后继续生成。

2.3 KV Cache、Prompt Cache 与上下文布局

KV Cache 是模型推理过程中对历史 token 中间结果的缓存；Prompt Cache 通常指服务商对重复前缀的缓存。两者都鼓励稳定前缀：系统提示、工具定义、长期规则放前面，变化频繁的用户输入和观察结果放后面。

稳定：系统规则 -> 工具 schema -> 长期 Skill
变化：任务状态 -> 最近观察 -> 用户本轮输入

缓存不是简单的性能开关，而是上下文布局约束。频繁把时间戳、随机 ID 或动态工具列表插入系统提示，会破坏前缀命中。当前补充：具体缓存行为、计费和可缓存 token 范围取决于模型供应商，接入前应以官方文档和真实指标验证。

2.4 系统提示词的组织方式

相比无序规则堆砌，推荐用流程组织：

角色与目标
  -> 可用资料及可信边界
  -> 工具选择规则
  -> 参数和权限约束
  -> 失败与澄清策略
  -> 输出格式

Prompt 应说明“何时调用工具、何时停止、资料不足时怎么办”，而不是只写“你是一个专业助手”。Few-shot 适合表达难以用规则描述的格式和边界案例；示例过多会占用上下文并固化错误模式。

2.5 Skills：可组合的领域能力

Skill 是一组可按需加载的领域说明、流程、模板和约束。它和工具的关系是：Skill 描述“如何完成一类任务”，工具负责“执行具体动作”。

一份可用 Skill 至少包含：触发条件、输入输出、步骤、禁用条件、错误处理、示例和依赖工具。Skill 不应拥有绕过权限的能力；它只是上下文材料，最终执行仍由 Harness 控制。

2.6 Agent 状态栏

长任务需要一个结构化状态栏，让模型和人都知道当前进度：

{
  "task_id": "task-001",
  "goal": "分析最近 7 天订单下降原因",
  "phase": "data_analysis",
  "completed": ["query_orders", "query_traffic"],
  "next": "compare_conversion_rate",
  "blocked_by": null,
  "budget": {"steps_left": 8, "seconds_left": 120}
}

状态栏应是机器可读、短小、稳定的元信息。它不是把完整历史重新总结一遍；更新频率越高，缓存和 token 成本越高，所以应只在阶段切换、关键失败或需要恢复时更新。

2.7 上下文压缩与隔离

压缩的目标不是单纯减少字符，而是保留下一步决策所需的信息。可以采用分层策略：

保留系统规则、未完成目标和最近错误。
将已完成工具结果压缩为结论、来源和可追溯 ID。
将大文件、长日志放外部存储，只在上下文中保留摘要和引用。
对独立子任务使用子 Agent，隔离上下文比把所有内容压成一段更可靠。

压缩后必须可回溯：摘要应带原始观察的 ID、时间和来源，避免模型把摘要误当成事实原文。

第 3 章：用户记忆和知识库

3.1 记忆的三层评估

不要问“系统有没有记忆”，而要分别评估：

记住：系统是否保存了事实。
找回：任务需要时是否能检索到事实。
用对：模型是否在正确场景、以正确权限使用事实。

记忆可分为当前对话、任务工作记忆、用户长期偏好和外部知识。不同层次的生命周期、隐私和删除策略都不同。

3.2 结构化记忆优于整段聊天

{
  "user_id": "u-001",
  "preferences": {"language": "zh-CN", "timezone": "Asia/Shanghai"},
  "facts": [{"value": "负责华东区域设备", "source": "user", "updated_at": "..."}],
  "consent": {"long_term_memory": true}
}

长期记忆必须有来源、时间、置信度、作用域和删除机制。涉及隐私、身份、健康、财务的信息不能因为模型“觉得有用”就自动永久保存；应提供用户可见的查看、修改和删除入口。

3.3 RAG：从文档到可检索知识

RAG 的完整链路是：

文档采集 -> 清洗 -> 按语义切分 -> Embedding -> 索引
问题 -> 查询改写 -> 稠密/稀疏召回 -> 重排序 -> 上下文组装 -> 生成与引用

稠密检索擅长语义相似，稀疏检索擅长精确术语、编号和代码。生产知识库常用混合检索，再用 Cross Encoder 或其他 reranker 对候选集重排。

3.4 超越扁平文本

书中强调结构化索引、文件系统范式、知识更新和 Agent 化 RAG：

用标题、章节、实体、时间、权限和来源保存文档结构。
让 Agent 通过搜索、读取目录、打开文件等工具渐进获取资料。
更新索引时使用版本、删除标记和增量同步，避免旧文档继续被召回。
检索结果必须带引用，回答不能把没有证据的推测写成事实。

3.5 多模态记忆

截图、表格、音频和视频不能一律转成纯文本。应根据任务保存原始资源、结构化抽取结果和可检索摘要，并记录权限与保留期限。当前补充：视觉模型和多模态 Embedding 的输入限制差异较大，必须以所用模型的官方文档和评估集为准。

第 4 章：工具设计

4.1 工具分类

类型	示例	主要风险
感知工具	搜索、读文件、查数据库、截图	越权读取、提示注入、数据泄露
执行工具	写文件、改订单、发邮件、执行命令	破坏性操作、重复执行、权限越界
协作工具	请求用户确认、转人工、调用子 Agent	状态丢失、等待超时、责任边界模糊

4.2 工具契约

{
  "name": "create_support_ticket",
  "description": "为指定订单创建人工处理工单；仅在用户确认后调用。",
  "input_schema": {
    "type": "object",
    "required": ["order_id", "reason", "confirmation_id"],
    "properties": {
      "order_id": {"type": "string", "pattern": "^\\d+$"},
      "reason": {"type": "string", "maxLength": 500},
      "confirmation_id": {"type": "string"}
    }
  },
  "risk": "write",
  "idempotency": "required"
}

工具描述应说清楚“何时使用、何时不要使用、参数含义、返回结构和失败方式”。参数 schema 不是装饰：后端仍需重新校验，因为模型可能缺字段、编造 ID 或传入边界值。

4.3 工具粒度与通用执行器

工具太细会增加调用次数和规划难度，太粗则隐藏业务约束、返回噪声并扩大权限。可先提供面向任务的专用工具，稳定后再抽象通用执行器；通用执行器必须限制可执行动作、参数类型和资源范围。

4.4 MCP 与渐进式工具发现

当工具数量很大时，不应把全部 schema 一次性塞入上下文。可以先暴露工具目录或 Skill，模型按需发现，再加载少量相关工具。这样降低 token 成本、减少选择混淆，也缩小提示注入面。MCP 解决的是工具/资源连接协议，不等于自动获得权限；服务端仍须做身份、授权、审计和隔离。

4.5 安全执行原则

写入、删除、付款、发信、生产命令等动作需要：

身份认证 -> 资源授权 -> 参数校验 -> 风险分级
  -> 用户确认（必要时） -> 幂等键 -> 执行 -> 审计

工具结果要面向模型决策，避免直接返回整行数据库或超长日志。错误应带稳定错误码、是否可重试和用户可理解的摘要。

第 5 章：Coding Agent 与通用 Agent

5.1 Coding Agent 的闭环

Coding Agent 的环境是代码仓库、测试工具、构建系统和版本控制。最小闭环是：

理解需求 -> 浏览仓库 -> 制定计划 -> 编辑文件 -> 运行验证
  -> 读取错误 -> 修复 -> 再验证 -> 汇报差异

代码能力既是执行工具，也是思考工具：搜索可以发现事实，脚本可以计算和转换，测试可以验证假设，生成临时代码可以探索数据结构。

5.2 文件编辑和命令执行

生产 Coding Agent 不应给模型一个无限制 Shell。建议：

工作目录显式绑定，禁止越过项目边界访问文件。
读、写、删除、移动和执行命令分别授权。
删除、覆盖、网络、凭据和生产环境操作默认需要确认。
命令设置超时、输出上限和进程清理。
每次修改记录 diff，验证失败时保留可回滚状态。

5.3 故障恢复

常见失败包括依赖缺失、编译错误、测试失败、路径错误、工具超时和上下文丢失。恢复策略应把错误归类：

可重试：网络抖动、临时服务错误
可修复：语法、类型、测试断言、参数错误
需澄清：需求矛盾、权限不足、目标不明确
应停止：破坏性风险、重复失败、超出预算

模型不应在同一错误上无限循环。Harness 需要记录尝试次数、错误摘要和最近变更，并在达到阈值时请求人工介入。

5.4 通用 Agent 的 Coding 内核

通用 Agent 也需要类似的搜索、代码/数据变换、外部系统适配和验证能力。区别在于环境和工具不同，而不是“Coding Agent 只会写代码”。代码执行为数据分析、图表生成、文件处理和业务规则验证提供了通用能力，但必须在沙箱中运行。

第 6 章：交互——观察与动作空间的扩展

6.1 从同步请求到异步事件

同步 Agent 假设用户在线等待；真实任务可能需要长时间运行、定时触发或等待外部事件：

任务创建 -> 持久化状态 -> 后台执行
  -> 事件到达/工具完成 -> 恢复上下文
  -> 通知用户或继续执行

异步系统必须有任务 ID、状态机、重试策略、幂等键、超时和取消机制。不要把内存中的对话对象当成可靠任务状态。

6.2 事件触发工具

事件可以来自定时器、Webhook、消息队列、监控告警或用户操作。触发事件时要重新做身份和作用域检查；不能因为“系统自动触发”就绕过原有权限。

6.3 语音、多模态与虚拟身份

语音把交互从串行文本扩展为更自然的流式输入输出，但带来打断、延迟、转写错误和隐私问题。多模态输入要明确每种资料的可信级别和可执行边界：截图中的文字是观察，不是系统命令。虚拟身份是表现层设计，不能伪装成真实授权主体。

6.4 隔离执行环境

文件、代码、浏览器和网络工具建议运行在短生命周期沙箱中：限制 CPU、内存、磁盘、网络和凭据；任务结束清理环境；需要持久化的结果写入受控存储。隔离优于仅靠 Prompt 告诉模型“不要做危险操作”。

第 7 章：Agent 的评估

Agent 评估不能只看最终答案。至少要同时看任务结果和过程轨迹。

7.1 评估维度

维度	核心问题	示例指标
任务成功	是否达到用户目标	成功率、完成率
决策	是否选择了正确路径	工具选择准确率、无效调用率
参数	参数是否忠实于输入	参数错误率、编造 ID 率
效率	是否浪费调用	步数、延迟、token、成本
安全	是否越权或跳过确认	越权率、高风险确认率
恢复	失败后能否停止或修复	重试成功率、循环率
体验	输出是否清楚可用	引用完整性、人工评分

7.2 轨迹数据

{
  "run_id": "run-001",
  "goal": "解释订单未发货原因",
  "steps": [
    {"tool": "get_order", "args": {"order_id": "1001"}, "status": "success"},
    {"tool": "get_inventory", "args": {"sku": "SKU-8"}, "status": "success"}
  ],
  "final": {"grounded": true, "needs_confirmation": false},
  "usage": {"input_tokens": 3200, "output_tokens": 410, "latency_ms": 2800}
}

轨迹应脱敏，并保留工具版本、模型版本、提示版本和数据集版本，才能比较两次发布的变化。

7.3 评估集与回归

评估集应覆盖正常任务、边界输入、缺少参数、工具失败、权限拒绝、提示注入和高风险动作。离线回归不能替代线上监控；线上要采样真实失败轨迹并经过隐私处理后回流评估集。

第 8 章：模型后训练

8.1 从预训练到 Agent 能力

预训练提供语言和世界知识，监督微调让模型学会任务格式，偏好优化改善回答选择，面向工具使用和环境反馈的训练则进一步塑造“观察—行动—修正”能力。

8.2 为什么不能只堆 Prompt

Prompt 可以改变当前任务的行为，但无法可靠补齐模型缺失的工具格式能力、长程执行习惯或领域术语。训练也不是万能的：错误数据会固化错误策略，过拟合会降低泛化，安全和权限仍必须由运行时执行。

8.3 工具调用训练数据

高质量样本应包含用户目标、可用工具、正确调用、工具结果、失败分支和最终答复；参数必须来自真实 schema，不能用看似合理但不可执行的 JSON。评估时要区分“会生成调用格式”和“能在环境中完成任务”。

8.4 当前补充

具体训练框架、模型许可证、推理服务和后训练方法变化很快。本文不把某个模型或平台写成永久最佳实践；上线前应根据官方模型卡、许可证、硬件成本和内部评估集决定是否训练，以及选择 SFT、偏好优化或直接改进 Harness。

第 9 章：Agent 的持续进化

持续进化不是让模型自动修改自己，而是建立可审计的反馈闭环：

线上运行 -> 收集轨迹和反馈 -> 定位失败模式
  -> 修改提示/工具/检索/策略/模型
  -> 离线评估 -> 灰度发布 -> 继续观测

9.1 反馈来源

用户显式评价和纠正。
工具成功/失败、权限拒绝、超时和重试。
任务是否达成、业务指标是否改善。
人工审核发现的幻觉、越权和不必要操作。

反馈必须和运行版本绑定，否则无法知道问题来自模型、提示、工具还是数据。

9.2 记忆、策略和版本

把“某次失败”直接写进长期记忆通常会污染后续任务。应先归纳为可验证的规则、测试样例或工具改进，再经过评估后发布。提示、Skill、工具 schema、模型和评估集都应有版本号。

9.3 持续进化的安全边界

自动生成补丁、自动修改提示或自动创建工具必须经过沙箱、静态检查、回归测试和人工审批。一个能自我修正的系统，首先必须能说明自己改了什么、为什么改、影响哪些任务以及如何回滚。

第 10 章：多 Agent 协作

10.1 什么时候拆分

适合拆分的条件：任务领域差异明显、上下文相互污染、需要并行执行、权限边界不同或单 Agent 已难以维护。不适合拆分的情况：任务很短、共享状态很多、通信成本高、调试和审计比收益更重要。

10.2 常见协作模式

主 Agent
  -> 规划 Agent：拆解任务
  -> 检索 Agent：寻找资料
  -> 执行 Agent：操作工具
  -> 审核 Agent：检查结果
  -> 主 Agent：汇总并回复

也可以采用流水线、并行 fan-out/fan-in、层级委派或辩论/审核模式。每个子 Agent 都应有明确输入输出、工具范围、预算和停止条件。

10.3 协作通信

子 Agent 不应共享全部原始上下文，而应接收任务包：目标、已知事实、约束、输出 schema、截止时间和权限。返回结果要带来源、置信度、失败状态和可追溯 ID。

10.4 协作成本与治理

多 Agent 会增加模型调用、延迟、token、状态同步和故障面。先用单 Agent + 清晰工具验证任务，再根据指标决定是否拆分。拆分后要记录父子关系、每个 Agent 的版本和资源消耗，并设置全局预算。

一条可落地的学习与实现路线

阶段 1：只读问答与结构化输出

先实现单轮模型调用、系统提示、JSON schema、错误处理和 token/延迟日志。不要急着加入自主循环。

阶段 2：RAG 与引用

完成文档清洗、切分、Embedding、混合召回、重排序、权限过滤和引用。建立一组带标准答案和来源的评估集。

阶段 3：只读工具

增加数据库、搜索、文件读取等工具。实现工具注册表、schema 校验、授权、超时、重试和轨迹记录。

阶段 4：受控 Agent

加入最大步数、任务状态栏、上下文压缩、失败恢复和人工确认。高风险写入工具默认关闭，只在测试租户灰度。

阶段 5：Coding/异步/多模态

在沙箱中加入代码、文件和浏览器能力；再引入后台任务、Webhook、语音或视觉输入。每扩展一种动作空间，都同步扩展安全和评估。

阶段 6：持续进化与多 Agent

等单 Agent 指标稳定后，再使用失败轨迹改进工具、提示、检索和模型；只有在上下文隔离或并行收益明确时才拆分多 Agent。

最小项目：受控订单调查 Agent

用户：为什么订单 1001 还没有发货？
  -> get_order_status（只读）
  -> get_inventory（只读）
  -> get_shipping_policy（RAG，只读）
  -> 汇总原因并引用来源
用户：那就创建人工工单
  -> 展示订单、原因和影响
  -> 请求明确确认
  -> create_support_ticket（写入、幂等、审计）

这个项目覆盖了本书的主要工程点：上下文、工具、记忆/RAG、状态栏、ReAct 循环、权限、人工确认、轨迹评估和错误恢复。实现完成后，再考虑异步通知、子 Agent 或自动化运营。

常见误区清单

把 Agent 等同于 Prompt；忽略 Harness、权限和状态。
把所有历史聊天、工具 schema 和原始文档一次性塞进上下文。
让模型直接访问数据库、Shell 或生产 API。
用“请不要越权”代替后端授权和沙箱。
只评估最终答案，不评估工具选择、参数和循环。
让失败的 Agent 无限重试。
把所有任务都做成 Agent，忽略确定性 Workflow。
没有版本化提示、工具、模型、知识库和评估集。
在没有单 Agent 指标的情况下盲目拆分多 Agent。

与站内其他教程的关系

AI 原生应用开发入门路线：适合先建立 LLM、Embedding、RAG、Agent 全局地图。
Agent 工程实践：从 RAG、工具调用到可控自动化：聚焦工具、权限、确认、记忆和生产安全。
RAG 从入门到实践：深入文档切分、召回、重排序、引用和评估。
Prompt Engineering 入门：补充提示词结构、约束和示例设计。
LangChain Agent 开发：把本文抽象落到框架组件和代码编排。
Embedding 与向量检索：解释稠密向量和相似度检索基础。

来源与版本说明

原书

李博杰：《深入理解 AI Agent：设计原理与工程实践》
版本：v2.0
PDF 生成/版本日期：2026-08-20
本文依据用户提供的本地 PDF，覆盖引言及第 1 章至第 10 章，章节顺序与原书目录一致。

当前补充

本文关于 API 缓存、MCP、模型后训练框架、模型许可证、沙箱和多模态能力的具体行为，属于面向当前工程实践的补充，不应视为原书逐句结论。实际项目应在选定模型、SDK、工具协议和部署平台后，核对对应官方文档、版本和许可证。

总结

Agent 的核心不是“让模型自由发挥”，而是设计一个能在观察和动作之间可靠运行的系统。模型负责概率性的理解与决策，Harness 负责确定性的权限、状态、执行、预算和审计；上下文工程负责把正确信息放在正确位置；记忆和 RAG 负责长期知识；工具和 Coding 能力负责改变外部世界；评估、后训练和持续进化负责让系统变得更可靠；多 Agent 只有在隔离或并行收益明确时才值得引入。

如果只记住一条工程原则：先做可验证、可停止、可回滚的单 Agent，再逐步扩大动作空间。每次增加新能力，都要同时增加权限边界、轨迹记录、评估样例和失败恢复。