《深入理解 AI Agent》92 个实验怎么学：从跑通到改造的实践指南

先搭一个不会误导自己的实验台

《深入理解 AI Agent：设计原理与工程实践》最适合用实验方式学，而不是只翻目录。最稳妥的起点，是先搭一套干净的复现实验台：单独 clone 仓库、固定 commit、创建虚拟环境、记录模型 provider、保存 API key 使用范围、标注操作系统和 Python 版本。你越早把这些基础信息写下来，后面越不容易在“当时到底用的是哪个版本”这种问题上浪费时间。

做 92 个实验时，真正要保存的不是截图，而是可重跑记录。命令行、配置文件、输出摘要、失败信息、依赖来源、外部仓库版本，这些都应该进入实验笔记。只要你把每次运行当成一次可审计的实验，而不是一次性演示，后面的复现速度会比想象中快得多。

把 92 个实验分成三层来学

这 92 个实验不适合一口气硬跑。更合理的办法，是按依赖和风险拆成三层：第一层是单机可跑、依赖少、用于建立直觉的实验；第二层需要 API key、外部数据集、MCP 服务或浏览器环境；第三层则可能需要 GPU、机器人、语音链路、额外仓库或外部 benchmark。这样的分层不是偷懒，而是控制变量。

先把第一层跑稳，再把第二层纳入章节主线，最后根据自己的方向挑第三层。这样学到的不是“我跑过很多实验”，而是“我知道每个实验为什么失败、成功时依赖了什么、可以怎样改造”。

第一章实验要看懂循环而不是只看输出

第一章最重要的实验，是让你亲眼看见 ReAct 循环如何工作：模型读取上下文，决定动作，调用工具，再把结果写回上下文。这个闭环跑通之后，很多看似复杂的 Agent 系统都会被你重新理解成“循环 + 状态 + 工具”的组合。

建议在这一章故意制造几个失败：工具返回空结果、工具返回错误格式、模型过早说完成、上下文里故意放入误导信息。你会很快看清楚，为什么没有 Harness、没有边界、没有回退的系统，只是一个会调用函数的聊天模型。

第二章实验要比较上下文组织方式

上下文工程的实验，不应该只比较哪段 prompt 更顺口，而应该比较上下文结构如何影响稳定性。把稳定规则、临时任务、工具结果、摘要和角色信息混放，和分层存放，是两种完全不同的系统。前者容易被最近输入拖偏，后者更容易让模型知道该看什么、该忽略什么。

做实验时，最好同时记录 token 分布、消息顺序、压缩方式和输出偏差。这样你才会明白，真正决定效果的不是“提示词写得漂亮”，而是信息组织是否尊重了模型的注意力机制。

第三章实验要把记忆和召回分开测

记忆实验和 RAG 实验常被混在一起，但它们的评估目标并不一样。记忆更关注什么该长期保存、什么应该过期、什么应该只在项目范围内生效；RAG 更关注检索是否准确、证据是否足够、召回内容是否带来源。把两者分开测，你才能真正知道问题出在存储、检索还是引用。

如果实验允许，最好专门测试过期信息、冲突信息和来源缺失信息。这样你会发现，真正好的记忆系统并不是“什么都能记住”，而是“不会把不该继续影响决策的内容带进下一轮”。

第四章实验要看工具能否安全组合

工具实验不能停留在“能调用”这三个字上。你需要观察 schema 是否清楚、参数是否安全、错误码是否易读、操作是否幂等、是否允许撤销、是否支持确认。一个查询工具出错，多半只是误导；一个写入工具边界不清，则可能直接改坏外部系统。

建议在这一章里同时跑同步工具和异步工具，再对比状态回写方式。你会很快发现，工具设计不是函数签名那么简单，而是整个动作空间是否适合模型参与。

第五章实验要把代码改动做成闭环

Coding Agent 的实验价值，来自它把读仓库、改文件、跑测试、看报错、修补丁这几步串成一个闭环。你不要只看它“写出了一段代码”，而要看它是否知道在哪里定位、如何最小化修改、怎么确认修改没有破坏别处。

最有用的实验，是故意给它一个会失败的小任务，比如路径写错、测试名变更、依赖缺失、补丁冲突。然后观察它是否能读懂仓库结构、承认错误并回滚。能完成这一步，才算理解了编码 Agent 的工程意义。

第六章实验的重点是评估纪律

到了评估章节，前面所有实验都应该被重新检查：有没有 baseline，是否可以重跑，失败样本是否覆盖，结果是否只是在少数样本上好看。评估不是附录，而是决定实验有没有研究价值的主线。

请把成功率、延迟、token 成本、失败类型和人工复查证据分开记录。这样你会发现，很多“看起来更强”的方法，其实只是换了呈现方式；而真正的改进，必须在证据上站得住。

第七章实验要测试训练是否真的必要

后训练实验最容易让人上头，但真正应该先问的是：这个问题值得训练吗。SFT、RL、奖励设计、环境质量，这些都不是独立快捷键；如果上下文、工具和评估还不稳，训练只会把偏差放大。

所以做这一章的实验时，不要急着看指标上升，而要先问样本是否干净、反馈是否可信、任务是否定义清楚。很多问题先靠工程治理就能解决，训练只是最后的手段，不该成为默认选项。

第八章实验要留复盘字段

经验学习这一章很适合变成实验日志模板。每次运行后，记录任务目标、上下文摘要、工具调用、失败原因、修复动作、可复用模式和是否值得沉淀成工具。只要你坚持这么记，Agent 的“自我进化”就不再是口号，而是可以验证的知识积累。

这一章的关键不是自动化得多炫，而是是否真的学会把经验变成结构化资产。没有复盘字段的任务，只会留下结果；有复盘字段的任务，才会留下方法。

第九章实验要正视多模态成本

语音、GUI、机器人和视觉任务会把 Agent 直接拉进复杂环境，所以实验时不能只盯效果。你要看输入噪声、动作延迟、回滚难度、设备限制和评估难度。多模态系统的成本，往往不是模型本身，而是周边环境。

这一章值得做的实验，是把多模态输入重新转回文本世界，检查系统是否仍然能解释自己的动作。如果不能解释，说明多模态只是在展示层更丰富，并没有真正形成可控能力。

第十章实验要验证协作边界

多 Agent 实验如果只看分工，很容易被表面热闹迷住。你真正要观察的是责任是否清楚、状态是否同步、冲突如何解决、失败是否隔离。协作系统一旦设计不清，就会把一个错误放大成多个互相掩盖的错误。

做这一章实验时，建议画出每个角色的输入、输出、确认权和回退路径。只要你能说清楚什么时候该用单 Agent，什么时候才适合上协作网络，你就已经学到了比“让多个模型一起干活”更重要的东西。

API key、硬件和外部依赖要提前列清楚

实验失败里最常见的一类，不是模型不会做，而是环境条件没准备好。API key、计费额度、浏览器权限、GPU、音频设备、外部 benchmark、额外 clone 的仓库，这些都应该在开跑前列成清单。把依赖写在前面，远比跑到报错再查要高效。

如果要长期复现，最好把每个实验的环境说明、依赖锁定、版本号和外部服务边界都写成小卡片。这样哪怕翻译版滞后、README 改动、目录重排，你也不会因为一个小变化就彻底失去复现能力。

最有价值的不是跑完，而是知道为什么能跑通

学习 92 个实验的真正收益，并不来自“数量感”，而来自你能不能解释自己为什么成功。你用的是哪个模型，为什么要这么排上下文，哪个工具最关键，哪个验证步骤最有意义，哪些条件一变就会失败，这些比结果本身更值得留下。

当你能把一个实验讲成一条可复现的工程链，说明你已经从“看过 Agent”走到了“会搭 Agent”。这正是这套实验最值得学的地方。

每个实验都要先写预期. 运行前先写预期，是复现实验里最便宜也最有效的动作。你认为输出应该是什么，工具应该调用几次，失败时应该停在哪里，哪些日志能证明结果有效。没有预期的实验，只是在看系统表演。 写完预期再运行，你会更容易发现异常。有时模型给出了看似合理的答案，却少调用了关键工具；有时结果正确，但依赖了错误证据。预期让这些问题变得可见。

把实验改坏一次再修好. 只跑通一次很容易产生错觉。更好的学习方式，是故意把实验改坏：删掉一个环境变量，换一个模型，缩短上下文，改变工具返回格式，加入过期记忆。然后记录系统如何失败。 修复失败的过程往往比成功运行更有价值。它会逼你区分模型问题、上下文问题、工具问题和依赖问题，也会让你知道哪些防护应该写进自己的 Agent 模板。

为每章保留一个代表性实验. 如果时间有限，不必追求一次跑完全部 92 个实验。每章至少保留一个代表性实验，能覆盖本章核心思想就够了。第一章要有循环，第二章要有上下文结构，第三章要有记忆或 RAG，第四章要有工具契约，第六章要有评估。 代表性实验跑稳后，再按兴趣扩展。这样你不会被实验数量压垮，也不会失去章节之间的连接。学习路径应当先形成骨架，再逐步补肉。

外部 benchmark 要单独建目录. 涉及 benchmark 的实验，最好和普通章节实验分开管理。benchmark 往往有自己的下载方式、版本、指标解释和许可证边界，混在章节目录里很容易让记录失真。 单独建目录还能方便重跑。模型或工具变更后，只要 benchmark 环境保持稳定，你就能比较新旧结果，而不是每次都重新猜测差异来自哪里。

成本记录也是实验结果. 调用云模型、长上下文、多轮工具和外部服务时，成本本身就是结果的一部分。一个方法如果成功率略高但成本翻倍，是否值得采用，需要写进评估结论，而不是留到上线前才发现。 记录成本不只是记录金额，还包括延迟、token、失败重试次数、人工介入次数和环境准备时间。Agent 实验的真实价值，往往要把这些隐性成本一起算进去。

用复现实验训练自己的判断力. 跑实验不是为了证明书里每句话都对，而是训练判断力。你要知道哪些结论依赖特定模型，哪些结论依赖特定工具，哪些结论在上下文变短后仍然成立，哪些结论只适合演示。 当你能把这些边界说清楚，就已经超过“会运行代码”的层次。你开始拥有自己的 Agent 工程判断，而这正是 92 个实验最值得提供的东西。

实验结束要整理成下一次可用的脚手架. 每章结束后，把稳定命令、依赖说明、常见错误、评估脚本和样例输入整理成小脚手架。下次再学相近主题时，不必从零开始找命令。 这种整理也能帮助别人复现。一个好的实验笔记，应该让另一个人能在相同边界下得到相近结果；如果只有自己看得懂，就还不是合格的复现记录。

不要把 README 当装饰. 很多实验失败，是因为读者只看正文，不看章节 README。README 往往包含运行入口、依赖提示、外部仓库说明、环境变量名称和实验限制。即使正文解释得很清楚，缺少这些执行信息，复现也会变得非常脆弱。 建议每次运行前先把 README 里的关键条件摘成三行：需要什么、怎么启动、如何确认成功。这个动作很简单，却能防止你在错误目录里安装依赖、在错误 provider 上调试模型，或把翻译版的旧说明当作当前事实。

把模型差异写进实验结论. Agent 实验对模型差异非常敏感。同一个工具描述，在一个模型上可能会稳定调用，在另一个模型上可能会过早总结；同一个上下文压缩策略，在长上下文模型和短上下文模型上的失败方式也不同。实验结论如果不写模型名称，就很难复用。 因此每条结论都要带上模型条件：provider、模型版本、温度、上下文窗口、是否启用流式输出、是否有工具调用限制。这样你不会把某个模型的偶然表现误认为系统规律，也更容易在未来替换模型时重新评估。

把实验改造成自己的业务样例. 跑通原实验只是第一步。更有价值的是把输入换成自己的业务样例：内部文档、真实代码片段、常见客服问题、固定数据表、标准运维任务。只要任务足够小，就能检验书里的方法是否适合自己的场景。 改造时不要一次替换所有变量。先保留原模型和工具，只换输入；再保留输入，只换上下文结构；最后再换工具或评估方法。逐步替换能让你知道差异来自哪里，而不是把所有变化混成一团。

把每个实验结果写成可复用卡片. 每次实验跑完后，最好立刻写一张小卡片：任务目标、环境条件、模型名称、上下文结构、工具边界、输出结果、失败原因、修复动作、是否可复用。卡片越短越好，但信息必须完整。这样做的意义在于，你不会把实验记忆留在脑子里，而是留下可以搜索、比较和复验的材料。 很多人忽略了这个步骤，于是三天后就忘了为什么某个实验成功。结果不是代码没跑通，而是经验没沉淀。实验课最怕这种“跑过但没学会”的状态。

把同一实验在两种条件下重跑. 如果时间允许，最好把同一实验在两种条件下重跑一次：一次按原始配置，一次改一个变量。变量可以是模型、上下文长度、工具返回格式、依赖版本、温度或外部数据。比较两次结果时，你会非常清楚地看到哪一层最敏感。 这种对照比单次成功更能训练直觉。Agent 学习真正需要的不是一次性成功记录，而是对“什么会改变结果”的判断能力。

把代码改造实验当作最接近生产的一步. 书里的很多实验并不只是展示原理，它们还在教你如何把原理嵌进代码流程里。尤其是 Coding Agent、工具调用和评估相关实验，最值得做的不是照抄，而是替换成自己的仓库、自己的文件结构、自己的测试入口。这样你会开始感受到真实工程中的摩擦：路径不一致、权限不足、依赖老旧、工具返回形状不稳定。 这些摩擦并不是麻烦，它们本身就是学习内容。因为真正的 Agent 系统，永远要在摩擦中工作。

实验数量多时，顺序比速度更重要. 92 个实验看上去很多，但如果顺序错了，数量再少也会变得难学。先跑最小闭环，再跑上下文和记忆，再跑工具和代码，再跑评估，最后再碰训练、多模态和多 Agent，这个顺序不能省。顺序一旦乱了，你就会把后面的复杂问题误以为是前面的基础没学会。 所以学习这本书最好的心态，是稳定推进而不是冲刺清单。实验课不是竞速，真正的收获来自你知道每一步为什么这样走。

把实验拆成可重复的最小单元. 当实验数量很多时，最怕的是每个实验都写得很大，结果一旦失败就不知道该从哪层修。更好的方式，是把每个实验拆成最小单元：一个输入、一个上下文结构、一个工具调用、一个评估方式。单元越小，变量越少，排错越快。 这种拆法也会让你更容易复用。很多实验看似不同，实际只是在同一个最小单元上换了任务目标。你一旦看见这种共性，后面的复现速度会明显变快。

实验说明和实验结果要分开写. 实验说明是给未来自己看的，实验结果是给当前判断看的。说明要写清楚怎么跑，结果要写清楚为什么算成功。两者如果混在一起，后面回头看时就很难区分“我当时想做什么”和“我当时做成了什么”。 分开写之后，资料的可维护性会强很多。哪怕实验已经过时，你仍然能通过说明知道原始意图，通过结果知道系统曾经在哪里表现不错。

对照实验比单次高分更有价值. Agent 学习最容易出现的误区，就是迷信一次好结果。其实更值得做的是对照：同一个任务，换一个工具边界、换一个上下文组织、换一个模型配置，看结果如何变化。对照实验会把系统真正敏感的地方暴露出来。 一旦你开始习惯对照，就会发现很多“我觉得这个方案不错”的直觉并不可靠。对照实验会迫使你把感觉变成证据，这正是工程学习最重要的变化。

把实验和笔记变成后续项目的素材. 92 个实验不是终点，而是一批素材。未来做自己的 Agent 项目时，可以从这些实验里挑出最稳定的结构，改造成自己的输入、自己的工具、自己的评估。这样，你不是从零开始造一个系统，而是在一个成熟骨架上做迁移。 这也是这本书对实践学习最有帮助的地方。它给你的不是孤立 demo，而是一整套可以被重组的工程片段。

实验要给未来的自己留线索. 很多实验是今天跑通，明天就忘。为了避免这种情况，每次实验都应该给未来的自己留线索：为什么选这个模型，为什么这个上下文长度更合适，为什么这个工具边界更安全，为什么这个失败值得记住。线索比总结更重要，因为它能帮助你以后重建当时的判断。 如果线索足够完整，实验笔记会变成一份个人知识库，而不是散乱的运行记录。那时你再回头看 92 个实验，就会发现它们真正教你的不是“做了什么”，而是“如何判断下一步”。

复现实验也要管理情绪. 实验失败时，很容易把挫败感归因到模型或者书本。其实更好的做法，是把情绪和事实分开。事实是依赖缺失、环境不对、上下文结构有问题，还是工具契约不清。情绪则只是提示你需要暂停一下。 这听起来很软，但对长期学习很重要。Agent 实验往往需要大量重试，如果每次失败都被情绪拖走，学习节奏就会断。把失败当作信息，而不是当作否定，本身就是很重要的训练。

每个实验都应该留下未来可复用的线索：为什么选这个模型，为什么这样组织上下文，为什么这个工具边界更安全，为什么这个失败值得记住。线索比总结更有用，因为它能帮助你重建当时的判断，而不是只记得结果。

实验失败时，也要把情绪和事实分开。事实是依赖缺失、环境不对、上下文结构有问题，还是工具契约不清；情绪只是提醒你需要暂停一下。这样处理失败，学习节奏才不会被一次报错打断。

把实验和自己的业务样例连接起来，也会让复现更有意义。你可以把输入换成文档、代码片段、客服问题或固定表格，只要任务足够小，就能检验书里的方法是否真的适合自己的场景。

最终，92 个实验的价值不是“做过很多”，而是“知道下一次该怎么判断”。如果你能把一个实验讲成一条可复用的工程链，说明你已经从跑通者变成了可以迁移方法的人。