AI Agent 学习总结

AI Agent 学习总结：第 1---5 章与第 10 章

一、整体认识：从能回答到能可靠完成任务

六章构成一条完整的学习主线：先理解 Agent 怎样运行，再学习如何组织上下文、保存知识、开放工具、执行代码，最后理解多个 Agent 如何协作。

章节	核心问题	重点概念
第 1 章：AI Agent 入门	Agent 是什么，如何持续做事？	LLM、上下文、工具、ReAct、Harness
第 2 章：上下文工程	每一步应该让模型看到什么？	消息结构、缓存、提示词、Skills、状态、压缩
第 3 章：用户记忆和知识库	如何跨会话保存并找到有用知识？	记忆表示、RAG、知识组织与更新
第 4 章：工具	怎样准确地感知和操作外部世界？	工具接口、能力表达、发现机制、安全边界
第 5 章：Coding Agent 与通用 Agent	如何把判断转化为可验证的工作？	编码流程、故障恢复、代码的六类用途
第 10 章：多 Agent 协作	什么时候值得分工，怎样防止失控？	上下文共享、协作拓扑、通信、独立验证

贯穿六章的认识是：Agent 的效果取决于模型能力，也取决于信息是否充分、工具是否可用、结果是否经过验证，以及失败后能否恢复。

二、第 1 章：建立 Agent 的基本框架

1. 三个基本组成

书中用工程公式描述最小实现：Agent = LLM + 上下文 + 工具。

• LLM 是决策核心：理解目标、规划步骤、选择行动。
• 上下文是当前可见的信息：包含任务、规则、历史、观察、相关记忆与知识。
• 工具是交互接口：读取资料、修改文件、执行代码、调用服务或委派任务。

需要区分 Agent 与 Environment（环境）。外部网页、数据库、文件内容及其变化属于环境；负责读取内容、校验调用、管理运行过程的部分属于 Agent 的工程系统。即使环境部署在同一台机器上，也不因此成为模型或 Harness 的组成部分。

模型无法利用没有进入上下文的信息，也无法完成没有操作接口支持的行动。因此，排查失败时应先检查"看到了什么"和"能做什么"，再判断是否需要更换模型。

2. ReAct：思考---行动---观察

接收目标 → 构造上下文 → 判断下一步 → 调用工具
                         ↑              ↓
                    更新上下文 ← 观察执行结果
                         ↓
                  验证完成条件 → 交付

工具调用请求由模型生成，实际执行由运行时完成。执行结果必须回到上下文，否则 Agent 无法知道操作是否成功，也容易重复相同动作。

用户消息、模型回复、工具调用及结果构成运行轨迹（trajectory）。轨迹既支持后续决策，也为调试、审计和经验整理提供依据。

3. Harness：围绕模型建立可靠性

Harness 是 Agent 边界内、模型之外的运行与治理层。

要素	职责	示例
上下文管理	提供相关信息、维护状态	检索资料、压缩历史、保留目标
工具接口	将决策连接到实际操作	文件读取、搜索、代码执行
约束	限定允许执行的行为	权限检查、参数校验、资源限制
验证	判断结果是否满足目标	测试、状态查询、渲染检查
纠正	失败后恢复或调整	修改方案、有限重试、回滚、人工接管

模型说完成了，不等于任务完成了。 完成条件应由可检查的产物和外部反馈支持。

4. 从简单方案开始

一次文本处理可使用单次模型调用；步骤稳定、边界清楚时可使用工作流；执行路径依赖中间发现时，再引入自主 Agent。固定流程与自主决策也可以组合。

本章还区分三种改进途径：任务中的上下文适应、跨任务的外部产物更新、训练中的模型参数更新。把知识加入上下文或写进文件，并不等于更新了模型参数。

**学习收获：**Agent 开发首先要建立"决策---行动---反馈"闭环，再围绕闭环设计约束、验证与恢复机制。

三、第 2 章：上下文工程决定信息供给质量

1. 上下文比提示词更广

系统提示词只是上下文的一部分。书中的基础调用模式还包括工具定义、用户消息、历史模型回复和工具结果。

示例用 system、user、assistant、tool 四种角色说明消息来源；工具定义通过独立的 tools 字段提供。工具结果需要关联对应调用，不能随意伪装成普通用户消息。具体协议因模型与服务而异，工程实现应保持其要求的消息结构。

基础布局可以概括为：上下文 = 相对稳定的前缀 + 随任务增长的轨迹。

上下文工程要解决哪些信息进入、何时进入、怎样组织，以及什么时候压缩或移出。

2. 缓存影响上下文布局

• KV Cache：缓存模型已计算的键值状态，减少生成中的重复计算。
• Prompt Cache：在服务支持的条件下，跨请求复用相同前缀的计算结果。

通常的前缀复用要求对应 token 前缀保持一致。从某个位置发生变化，会使该位置及其后的缓存无法直接复用，之前的相同前缀仍可能复用。

因此，稳定规则和核心工具定义尽量保持稳定；时间、任务进展等动态状态尽量追加在后部。压缩历史时，还要权衡压缩收益与缓存重建代价，不宜每轮都重写完整历史。

3. 提示词与 Skills 各有职责

系统提示词应明确身份、目标、边界、流程和输出要求。比起不断叠加零散规则，清楚的步骤、条件和验收方式更有助于执行。

Skill 是按需加载的领域操作知识包。 先暴露名称和描述，需要时读取正文，再按需读取脚本和参考资料，这就是渐进式披露。

工具提供操作能力，Skill 提供完成一类任务的方法。例如，文件读写工具提供基础操作，报告写作 Skill 说明怎样收集证据、组织章节和检查引用。Skill 本身不会赋予额外权限。

4. 显式状态减少遗忘和重复

长任务中的关键状态容易散落在历史里。状态栏将信息整理为当前可直接使用的摘要，包括：目标与约束、完成标准、已完成事项、剩余工作、近期错误、调用次数及预算。

这能减少模型反复从原始记录中推导状态的负担。但状态提醒不等于强制执行，次数上限和权限仍应由代码约束。

5. 压缩要保留决策依据

书中提出分层处理：控制工具输出预算，将大结果外置；删除低价值噪声；在适用条件下使用 API 层压缩；保留结构化归档摘要；最后才进行全量压缩，并为失败设置停止机制。

压缩应保留目标、约束、关键事实、来源、时间条件、决策理由、失败路径和待办事项。不能把"某条件下成立"压缩成"始终成立"。

独立子任务还可以使用隔离的上下文完成探索，只回传结论、证据位置和未解决问题，减少主上下文负担。代价是任务移交必须自包含、边界明确。

6. 区分资料与指令

网页、文档、邮件和工具结果可能携带提示注入。来源标记、指令与数据分离有助于减少混淆，执行层还需要独立检查权限和高风险操作。单靠提示词无法构成完整的安全边界。

**学习收获：**上下文工程追求相关、准确、结构清楚和可维护，而不是一次性塞入尽可能多的信息。

四、第 3 章：从保存信息到管理可用知识

1. 轨迹、长期记忆与共享知识库

对象	主要内容	用途
轨迹	一次运行的事件与工具反馈	当前执行、追溯和调试
用户长期记忆	跨会话的个人事实、偏好和关系	连续性和个性化服务
共享知识库	业务文档、规则、领域资料	公共或组织范围的知识供给

用于审计的原始轨迹可以只追加；实际送入模型的上下文可以压缩。长期记忆是提炼后的知识，会更新、合并和淘汰，不能只当作不断增长的聊天记录。

2. 四种记忆存储格式

格式	表示方式	优点	局限
Simple Notes	单条原子事实	简洁、维护成本低	容易丢失关联
Enhanced Notes	带背景的完整段落	语义和叙事较完整	冗余多、更新可能牵涉多处
JSON Cards	分类嵌套的结构化属性	便于局部更新和明确查询	固定分类不适合所有多维事实
Advanced JSON Cards	属性加背景、主体、关系、时间	有利于消歧和情境判断	提取和维护成本较高

例如，"张医生是父亲的医生"不能只存成"医生：张医生"。主体和关系丢失后，后续任务就可能使用错误对象的信息。

对于条件判断和状态演化较复杂的知识，章节还讨论了可执行代码表示；它能明确规则，也需要受控执行和验证。

3. 三层记忆能力评估

1. 基础回忆：准确取回用户直接提供的事实。
2. 多会话检索：跨时间和话题找到相关信息，区分对象与有效状态。
3. 主动服务：发现分散信息之间的联系，提醒用户可能遗漏的问题。

保存数量不能证明记忆好用。系统既要有全局概览发现查询方向，也要能按需取回精确细节。

4. RAG 的完整管道

文档整理与分块 → 建立索引 → 稠密/稀疏检索
                              ↓
                       结果融合 → 重排序
                                    ↓
                          证据进入上下文 → 生成答案

稠密检索 擅长语义相似匹配；稀疏检索 擅长关键词、编号和错误码等精确匹配；混合检索结合两路候选，降低各自盲区。

融合负责建立统一候选池，例如使用基于排名的 RRF；重排序负责对候选做更精细的相关性判断。两者不是同一步，重排序也不能找回完全没被召回的资料。

章节通过 recall@k、MRR、nDCG 等指标检查正确资料能否被找到、是否足够靠前、整体排序质量如何。评估需要有标注的查询集。

5. 三个容易混淆的概念

概念	阶段	解决的问题
上下文感知检索	建立索引时	给孤立分块补充来源背景，减少语境丢失
上下文感知压缩	任务运行时	根据目标去除冗余，控制上下文规模
Agentic RAG	查询与执行时	由 Agent 决定何时检索、怎样追问、是否继续查证

知识组织不限于扁平分块。树形摘要、实体关系图、带目录与交叉链接的文件系统，都能支持从概览到细节的导航。文件系统知识库也需要索引和横向链接，不能只把文件堆在目录里。

6. 知识更新要能核验和回滚

新信息可能与旧信息冲突，也可能只是对应不同人物、时间或适用条件，不能用最新一句话直接覆盖所有旧记录。

书中区分事件触发的增量更新与周期性的全量整理。两者都需要回到原始证据，处理重复、过期内容和冲突，维护链接和索引。

可以区分三层：原始证据 → 经审核的知识 → 可重建的检索索引。更新以最小变更提出，独立审核后发布，保留来源、时间、版本和访问边界。日志与记忆还需避免不必要地暴露敏感信息。

**学习收获：**记忆的价值在于能否在正确场景下被准确使用，知识库可靠性来自检索质量与持续治理。

五、第 4 章：工具是 Agent 的行动接口

1. 五类工具

类型	用途	示例
感知工具	获取信息	搜索、读文件、查询数据库
执行工具	改变外部状态	写文件、执行程序、调用业务接口
协作工具	驱动其他 Agent 或人类参与	委派任务、请求确认、交换进度
事件触发工具	外部事件启动执行	定时器、Webhook、新消息事件
用户沟通工具	向用户传递信息	进度通知、消息、语音沟通

第四章重点展开前三类，事件触发和用户沟通的实时运行机制在其他章节继续讨论。

2. 从 Agent 的目标出发设计接口

ACI（Agent-Computer Interface）强调让接口易于被 Agent 理解和正确使用。工具说明不仅要写功能，还要写适用时机、边界、参数示例、返回内容和错误含义。

文件名搜索与文件内容搜索是不同能力。描述不清时，模型即使参数格式正确，也可能选错工具。

还要保持参数保真。精确替换中的引号、空格或路径若被中间层静默改写，模型意图与实际执行就会不一致，导致难以排查的反复失败。

3. 表达形式与披露数量是两个问题

同一能力可以做成专用工具，也可以通过通用执行器配合 Skill 完成。专用工具便于参数约束、测试和稳定封装；通用执行器更灵活，但需要更严格的执行边界；Skill 承载方法，借助现有工具执行。

不论采用哪种形态，都不必把全部能力同时放进上下文。可以先给目录或搜索入口，再加载详细定义。

MCP 解决工具和数据接入的互操作问题，Skill 承载使用方法和流程知识。是否采用 MCP，与是否全量暴露工具定义，同样是两个独立决策。

4. 感知结果应支持继续探索

搜索宜返回标题、位置和摘要；读取宜支持分页或指定范围。若内容被截断，应说明尚有多少内容以及如何继续读取，避免把"没看到"误判为"没有"。

多模态处理有三条路径：原生多模态模型直接处理、提取文本后处理、通过专门的多模态工具回答问题。选择时应考虑信息损失、上下文成本和任务是否依赖布局、图表或空间关系。

5. 执行工具要有独立边界

参数合法不等于操作被授权，接口成功返回也不一定代表业务目标达成。执行层需要输入检查、权限约束、隔离环境、资源限制和结果验证。

对可能已生效的写操作，超时后应先确认状态，再决定是否重试，避免重复产生副作用。

**学习收获：**清晰、保真、反馈充分且边界明确的接口，比盲目增加工具数量更有价值。

六、第 5 章：代码是通用 Agent 的基础能力

1. Coding Agent 是工程闭环

流程可概括为：理解项目与约束 → 明确需求 → 必要的设计 → 实现 → 测试与修复 → 审查与交付。简单任务可以缩短流程，复杂任务则需要设计和审查节点。

项目文档应记录结构、架构约定、运行方式与验证命令，让关键知识不只存在于人的记忆中。

测试、类型检查、静态检查、版本控制和持续集成，为 Coding Agent 提供了成熟的外部反馈与恢复手段。完成标准应是行为满足需求并通过相关验证，而不是"代码已经生成"。

2. 按故障类型选择恢复策略

层次	典型故障	处理思路
API 层	限流、超时、连接中断、输出截断	判断是否可重试，限制次数，必要时降级
工具层	工具不存在、参数错误、执行异常	修正输入或策略，避免原样重试
上下文层	窗口溢出、压缩失败、消息配对损坏	压缩或恢复结构，避免持续失败
控制流层	无进展循环、恢复过程再次出错	检测重复模式，设置预算、熔断与接管

可靠性不仅在于少犯错，也在于错误能否被发现、定位、恢复或安全终止。

3. 搜索、编辑与并发

知道函数名或错误文本时，可用精确内容搜索；知道路径模式时，可用文件名搜索；只知道概念时，再考虑语义搜索等方法。

编辑应基于实际读取的内容，采用范围明确的修改，并检查差异与结果。多个操作之间要留意文件是否已变化。

独立且支持并发的操作可以并行；后一步依赖前一步结果时，需要按依赖顺序执行。取消范围同样应遵循依赖关系，不能随意中止无关工作。

4. 代码的六类用途

用途	价值	示例
思考工具	精确计算和逻辑验证	数学计算、符号推导、约束求解
业务规则约束	将明确规则变成可执行检查	时间范围、条件组合、额度限制
多媒体生成	控制结构、布局和可修改性	图表、演示文稿、视频编排
系统适配器	连接接口与数据格式	日志解析、字段转换、服务适配
生成式 UI	更有效地展示和收集信息	表单、交互图表、结构化选择
Agent 自举	创建或修复 Agent 的组成部分	配置修复、工具生成、流程搭建

代码执行具有确定性，不代表代码本身正确。模型仍可能误解需求或写错规则，需要验证输入、逻辑和实际输出。

视觉产物还应检查实际渲染，运行成功无法证明布局正确。自然语言规则与代码校验也应互补：前者支持理解和解释，后者约束关键决策。

**学习收获：**代码让 Agent 能精确计算、构造产物和连接系统；测试与真实反馈让这些能力可验证、可修正。

七、第 10 章：多 Agent 协作的价值与代价

1. 先证明协作有收益

多个 Agent 不会自动优于单个 Agent。本章强调检查协作是否引入新的证据、能力或独立观察，如测试结果、渲染截图、不同资料来源和独立调查。

多个角色围绕同一段内容反复表态，可能增加成本却无法突破共同盲区。是否使用多 Agent，应同时衡量效果、延迟与总资源开销。

2. 两个独立的架构维度

**上下文是否共享：**共享保留更多细节，但容易膨胀并延续角色惯性；隔离有利于专注、并发和权限管理，但必须明确传递任务信息。

协作拓扑：

拓扑	组织方式	主要代价
对等协作	少量角色按约定迭代反馈	需要清晰的反馈规则与终止条件
管理者模式	中心 Agent 拆解、分派和整合	管理者可能成为能力与可用性的瓶颈
去中心化模式	各角色按协议自主沟通和移交	一致性、责任划分和冲突处理更复杂

不能只看角色名称，要看实际控制权和信息怎样流动。

3. 移交信息与管理生命周期

隔离上下文的 Agent 可以通过工具参数、共享文件和消息总线通信。实践中，移交包应包含目标、输入与来源、约束、产物格式、验收标准、已知问题和证据位置。

文件交换承担产物传递，创建、查询状态、消息、取消和等待承担运行控制。系统不只要能启动子任务，还要知道它是完成、阻塞还是需要终止。

MCP 面向 Agent 与工具的互操作；A2A 面向 Agent 之间的互操作，尤其关注跨系统发现、任务与产物交换。协议不能替代任务边界和验收规则。

4. 提议者---审核者需要独立证据

提议者生成产物，审核者根据原始需求、实际产物与外部证据检查。审核应给出可定位、可执行的修改条件。

代码审核应结合测试，视觉审核应查看渲染，知识审核应追溯原始资料。若审核者只接收提议者筛选过的解释，就可能继承相同错误。

循环需要验收门槛、迭代次数和预算，既防止未验证就停止，也防止无限修改而无法交付。

5. 六类失败模式

失败模式	风险	应对思路
共享文件并发冲突	覆盖修改、跨文件语义不一致	版本检查、工作副本隔离、集成验证
错误级联放大	上游误解被下游反复引用	传递证据来源、独立交叉核验
同质趋同	多个角色重复同类错误	不同信息来源与审查视角、共享资源治理
互相扯皮	责任不清、目标冲突	明确所有权、优先级和争议处理方式
循环失控	无界派生、重复调用、成本膨胀	总预算、并发上限、取消与停止机制
理解债与认知投降	人无法理解或审查交付物	保持架构理解，检查关键依据与实际结果

乐观锁主要解决同一文件版本冲突，不能自动解决"一个角色改了接口，另一个仍按旧接口使用"的语义问题。

6. 从任务协作到 Agent 社会

章节通过社会模拟、经济竞争和信息不对称游戏说明：多个 Agent 长期交互可能形成超出单次任务设计的群体行为。

群体运行还受到激励、资源、信息权限和争议裁决机制影响。单体更强，并不自动意味着群体更协调。

**学习收获：**多 Agent 的关键是有效分工、明确接口和可验证反馈，而不是单纯增加角色数量。

八、跨章节串联：五个反复出现的设计模式

模式	六章中的体现	需要注意的边界
提议者---审核者	知识更新、工具审查、代码与视觉验证	审核需要独立证据
渐进式披露	Skills、分层知识、工具发现	先给入口，再按需读取细节
只增不改	稳定轨迹前缀、原始事件归档	不等于禁止压缩上下文或修订派生知识
边界集 + 保留集	验证目标变化并检查原有行为	解决新问题的同时防止回归
最小 diff + 可回滚	代码、知识和配置的修改	控制范围，保留审查与恢复依据

信息供给、行动执行与反馈治理需要一起设计。缺少任何一环，都可能出现"看起来会做，实际做不稳"的系统。