第1章　定义、边界与产业演进¶

状态：初学者展开试稿，待人工审阅（基于Release Candidate 1修订）

本章定位：从一个熟悉的任务出发，理解Agent是什么、怎样做事，以及为什么还需要模型之外的程序。

本章回答的三个问题¶

一个很会回答问题的AI，为什么还不一定是Agent？
模型、上下文和工具，怎样配合起来完成一件事？
模型越来越聪明，为什么仍然需要检查、权限和停止规则？

你不需要会编程，也不需要先学机器学习。只要用过“输入一句话，AI给出回答”的聊天工具，就可以从这里开始。遇到英文名称时，先理解旁边的中文解释；本章的代码可以跳过，不影响主线。

5分钟速读¶

模型擅长生成回答，Agent系统还要把决定变成行动，并根据结果调整下一步。 区别不在于回答有多长，而在于有没有真正使用环境反馈推进任务。
Agent = LLM + 上下文 + 工具是一张组成示意图，不是“装好三个零件就一定成功”的公式。 大语言模型选择下一步；上下文提供当前能看到的资料；工具提供查询和操作的接口。
环境是被查询、被操作的对象。 图书馆目录、文件、网页和业务系统属于环境；能读取目录的工具接口，不等于目录本身。
Harness是模型周围的运行与管理程序。 它负责准备资料、检查工具请求、记录进度、控制权限，以及核对任务是否真的完成。
“不知道”有时不是不够聪明，而是没有看到必要信息；“做不到”有时是没有合适工具或权限。 这些情况要分开检查，不能一律归结为模型能力不足。
一次成功不等于永远可靠。 教学故事帮助理解机制，实验记录用来检验具体表现；二者不能混为一谈。

一、统一定义：从“告诉我怎么做”到“帮我做，并核对结果”¶

1.1 先看一个找书的任务¶

假设你刚上初中，要为科学课准备一次关于月球的分享。你向一个AI提出请求：

“帮我找一本适合我读的月球科普书，确认本校图书馆现在能借，告诉我怎么借。先不要替我预约。”

一个只生成文字、不能查询图书馆的模型，可以解释怎样挑选科普书，也可能推荐它知道的书名。但它没有拿到你所在学校的实时馆藏记录，就不能确认某本书是否在馆。即使它写出“这本书现在可以借”，这句话本身也不是借阅状态的证据。

如果给这个系统接入经过授权的图书馆查询工具，它就有可能走得更远：先搜索月球主题，读取候选书的简介，再查询馆藏。如果第一本已经借出，就检查另一本；如果简介不足以判断阅读难度，就查找补充介绍，或者询问你是否接受文字较多的书。

这里最关键的变化不是“回答变长了”，而是查到的结果改变了下一步的做法。系统不是一口气写出一套看起来合理的步骤，而是在做过一步、收到反馈之后，再决定接下来做什么。

教学示例说明

本章的找书、预约和退款场景都是为解释机制而设置的假想例子，不代表某个学校已经部署了这样的系统，也不是实验结果。真实实验将在第九节单独介绍。

1.2 本书怎样定义Agent¶

AI Agent通常译为“人工智能智能体”。“智能体”这个词在不同研究领域中的用法并不完全相同；本书主要讨论以大语言模型为决策核心的软件系统，采用下面这个工作定义：¹

AI Agent是能够依据当前上下文选择行动，通过受控工具与环境交互，并在预算和终止条件内持续推进目标的系统。

这句话可以拆开理解。目标是“找到适合且可借的书”，而不是单纯输出一段介绍。选择行动是决定先查哪本书、信息不足时查什么。环境反馈是工具带回的馆藏状态或错误信息。预算和终止条件则告诉系统：不能无休止地查下去，找到了符合要求的结果、遇到无法解决的问题，或者用完允许的时间，都需要结束或转交给人。

“受控”也很重要。用户只要求查询，系统就不能自行预约，更不能修改借阅记录。自主性指的是在允许范围内选择步骤，不是自己给自己增加权限。

这一定义强调的是运行方式，不保证每一次运行都成功。Agent可能选错书、误读简介，也可能因为图书馆系统不可用而无法完成。我们需要知道它怎样失败，而不是因为它叫Agent，就相信它已经可靠。

1.3 会调用工具，就一定是Agent吗¶

还不能只凭这一点判断。想象一个程序规定：“收到城市名以后，查询天气，再把温度填进句子。”它使用了工具，但所有步骤都事先安排好了。这里的模型即使参与，也可能只是把结果改写得更容易读。

这种主要由程序预先规定步骤和分支的系统，叫工作流（Workflow）。它可以有很多步骤，也可以根据查询结果走不同分支；区别在于，下一步的选择范围和转移规则主要由开发者提前写好。

找书任务也可以做成工作流，例如“按主题查询，再筛选在馆的书，最后展示”。如果需求足够固定，这样完全可以满足需要。只有在需要根据新发现灵活选择查询方式、补充资料或澄清问题时，才值得考虑让模型参与决定执行路径。

因此，判断重点不是“有没有工具”“有没有循环”，也不是界面看起来像不像聊天，而是：关键步骤由谁决定，执行结果又怎样影响后续决定。 工作流与Agent还可以混合使用，第2章会继续讨论如何选择。²

二、三种理解层次：把同一套系统看清楚¶

2.1 直觉层：大脑、眼睛和手脚¶

原始书稿用“大脑 + 眼睛 + 手脚”帮助读者建立直觉：模型负责判断，上下文让模型获得信息，工具把决定转为查询或操作。¹

放回找书的故事：“先查月球主题，再确认能否借到”是决策；“这本书适合入门，但已经借出”是当前掌握的信息；查询目录则是一次工具行动。只靠其中一项，都不能完成整个任务。

不过，这只是帮助记忆的比喻，并不是说模型像人一样拥有意识。“眼睛”也不够准确：上下文不仅有刚看到的结果，还包括用户要求、规则、以前查过什么，以及可用工具的说明。把它想成当前摊在桌面上的任务资料，往往更贴切。

2.2 工程层：LLM、上下文和工具¶

大语言模型（Large Language Model，LLM）是处理语言并生成输出的模型。在本章的系统里，它除了生成回答，还可以提出“查询某本书的馆藏”这样的行动请求。模型负责提出什么请求，不等于它亲自运行了图书馆的查询程序。

上下文（Context）是某一次模型调用时提供给它的信息。找书时，这份资料可以包括你的年级、主题要求、已查书目和最新结果。模型不能自动看到电脑里的全部文件，更不会天然知道学校的实时借阅情况。信息必须经由输入或工具结果进入上下文，才可能被用于这次判断。

工具（Tools）是系统允许使用的查询或操作接口。你可以把接口理解成一张格式明确的申请单：填入书名，请求查询；填写格式正确且身份有权限，程序才执行。程序返回的结果，再被整理给模型看。

所以，Agent = LLM + 上下文 + 工具里的加号表示组件配合，不是数学加法。模型需要知道有什么工具、怎样提出请求；程序需要真正执行请求；执行结果还必须回到下一轮上下文。 只把工具名字写进提示词，并不会让系统凭空获得对应能力。

2.3 控制层：根据观察选择行动¶

再换一个角度，不看零件，只看信息怎样流动。系统收到一条观察（Observation），据此选择一个行动（Action），行动得到新反馈，然后继续。这就是反馈闭环。

决定“在当前信息下选择什么行动”的逻辑，称为策略（Policy）。这里的“策略”不是一份永远不变的完整计划，而是做下一步选择的方法。查到第一本书已借出后，策略可能转向查询替代书，而不是机械地继续介绍第一本。

看待系统的角度	决策	当前资料	与外部交互
直觉层	大脑	桌面上的资料，或粗略比作眼睛	手脚
工程层	LLM	上下文	工具接口
控制层	策略	观察与相关历史	行动与反馈

这不是三套不同的Agent。它们分别帮助我们理解“像什么”“由什么构成”和“怎样运转”。不必背表格；能把找书过程放进这三个角度，就抓住了主线。

三、Agent与Environment：查询入口不等于整个世界¶

图1：Agent边界与反馈闭环

3.1 哪些东西属于环境¶

环境（Environment）是Agent与之交互的外部对象及其状态。找书时，图书馆目录、借阅数据库、提供简介的网页，以及回答澄清问题的你，都属于环境。写代码时，文件、运行中的程序和测试环境也属于环境。³

为什么要画这条边界？因为模型说了什么，与环境发生了什么，是两件事。模型可以写“预约完成”，但只有预约系统接受请求、产生相应记录，才能支持这个说法。把二者分开，就不会把一句流畅的回复误当作现实中的结果。

同样，“我准备查询”不等于“已经查过”，“请求已发出”也不等于“请求已成功”。这些区别听起来琐碎，却决定一个系统是在描述行动，还是确实做了行动。

3.2 上下文是窗口，不是世界本身¶

假设查询工具返回“某书在馆”。模型看到的是这条查询结果，而不是整个图书馆。它可能不知道书架正在调整，也不知道查询后是否有另一位同学刚借走这本书。

这说明，观察通常是不完整的，也有时间范围。诚实的回答应该是“刚才的馆藏查询显示可以借”，而不是保证“你明天过去一定能借到”。后者超出了这次观察能够支持的范围。

拿到工具结果也不等于拿到绝对真理。工具可能连接了过期目录，网页简介也可能写错。应当进一步问：信息来自哪里、什么时候获取、是否回答了当前问题？“使用工具”与“获得可靠证据”之间，还隔着这些检查。

3.3 部署在同一台电脑，也仍然有边界¶

工具接口像查询窗口，数据库像窗口背后的登记册。负责接收请求、检查权限、整理结果的程序属于Agent的运行支持部分；登记册里的书目和借阅记录属于环境。

即使两者部署在同一台电脑上，这个区别仍然成立。我们按职责划分，而不是按机器位置划分。否则，一旦系统从本地搬到服务器，概念就会全部混乱。

图1表达的正是这两层关系：外层是Agent与环境互相传递行动和观察；内层是模型与支持它运行的程序互相配合。下面就来看内层。

四、Model与Harness：谁决定下一步，谁让决定正确落地¶

4.1 Model负责理解和提出候选行动¶

Model就是模型，在本章主要指作为决策核心的LLM。它适合处理语言和语义问题，例如理解“不要太难”意味着什么、从简介判断一本书是否偏入门，以及在资料不足时提出澄清问题。

这些判断很难全部写成简单的“如果……就……”规则。同样是“适合初中生”，有人更喜欢插图，有人愿意读较长的文字；模型可以结合上下文提出候选方案。

但候选方案仍然需要核对。模型可能把“介绍月球观测”误读成“介绍月球探测器”，也可能选出不存在的书目编号。能理解语言，不等于掌握了当前系统里的所有事实。

4.2 Harness负责把候选行动变成受控执行¶

Harness在本书中指模型周围的运行与治理层。先不用纠结怎样翻译这个词，可以把它理解为“帮助模型做事，并看住执行边界的程序”。它不是另一个必须更聪明的AI，而是一组代码、配置和服务。⁴

模型提出“查这本书”以后，Harness要确认这个工具是否存在、参数是否符合要求、当前用户是否允许查。检查通过，才把请求交给环境中的系统执行。返回结果以后，它还要记录下来，放入适合下一轮使用的上下文。

Harness也负责系统不应依靠临场发挥的事情。例如用户已经取消任务，程序就应阻止新的操作；查询次数已经达到上限，就不能因为模型说“再试一次”而自行放宽限制。

这也解释了另一种常见写法：Agent = Model + Harness。它不是与前面的三组件公式竞争的新定义，而是把“上下文怎样准备、工具怎样调用、运行怎样管理”合在Harness这一层里看。同一套系统，只是换了一种划分方式；环境仍然在Agent边界之外。

4.3 用一次预约请求看清职责¶

把原来的任务稍作扩展。假设你已经看完推荐，明确要求预约选中的书。下面各方的职责就容易区分了：

环节	模型可以做什么	程序和环境需要确认什么
理解请求	判断你要预约哪本书；有歧义时追问	书目编号是否确实存在
准备请求	提出预约工具及其参数	当前登录身份是否有预约权限
执行之前	向你说明准备做什么	按业务规则取得所需确认，不能只凭模型声称“用户同意”
执行之后	根据返回结果组织说明	预约记录是否已生成，或系统是否明确拒绝

原任务只允许查询，因此不能自动走进这个预约流程。只有用户的新请求和系统授权都满足要求，才可以进入相应操作。

在退款场景里也是同样的道理：模型可以提出“为这笔订单退款128元”，但订单是否存在、可退金额是多少、谁有权操作，以及款项是否退回，都需要业务规则和相关系统核对。这里的128元只是说明分工的假设金额，不是业务阈值。

4.4 为什么提示词不能代替程序检查¶

提示词（Prompt）是给模型的指令或任务说明。告诉模型“不要越权”“先确认再操作”可以帮助模型提出更合适的行动。但如果模型遗漏了要求，单靠这句话并不会阻止工具继续执行。

本书的工程建议是：让模型知道规则，同时让执行程序真正检查规则。提示词负责说明“应该怎样做”，权限检查负责决定“这次操作是否允许发生”。二者不是相互替代的关系。⁴

还要避免另一个误解：Harness并不是写出来就天然正确。程序也会有漏洞，数据库也可能配置错误。因此它同样需要测试。把权限放进程序，是为了让边界能够明确检查，而不是宣布风险已经消失。

五、观察空间与动作空间：不是所有问题都靠换模型解决¶

5.1 观察不足：模型缺的是哪一条信息¶

观察空间（Observation Space）指系统通过既定通道可能获得的观察范围；某次实际拿到的查询结果只是其中一条观察。可以用“这套系统有机会看到什么”来理解它，不要与“这次上下文里已经放了什么”混为一谈。

找书时，如果上下文只有书名，没有简介，模型就缺少判断阅读难度的材料；如果只有简介，没有馆藏状态，它又无法确认是否能借。重复要求它“认真一点”，并不能补出缺失的数据。

遇到错误时，可以依次检查：信息源里有没有所需内容？查询工具有没有取到？结果有没有进入模型上下文？模型是否读懂了它？前面几步出问题，与最后一步出问题，需要的修复方式不同。

当然，补足信息也不保证回答正确。模型仍可能误读。因此，更合理的做法是同时检查有没有证据和有没有正确使用证据，而不是先认定一切都是“模型不够强”。

5.2 动作不足：知道办法，不等于有能力执行¶

动作空间（Action Space）是系统允许选择的行动范围。一个只有搜索工具的Agent，可以找书、读简介，却不能自动预约。这不一定是缺陷：如果用户只要求查资料，保持只读能力反而符合任务边界。

当任务确实需要预约时，系统必须接入相应接口，并取得授权。模型即使写出了完整的预约步骤，也不能绕过“没有接口”或“没有权限”这个事实。

增加工具时还要区分两类后果。读取简介通常不会修改借阅记录；预约、发信、付款则会改变外部状态。这种对外部状态的改变，在软件工程中叫副作用（Side Effect），并不是说它一定有害。只是它一旦发生，就可能需要取消、补偿，甚至无法完全撤回。

因此，本书建议从完成任务所需的最小能力起步。需要查馆藏，就先给查询能力；不要为了让Agent“万能”，顺便开放删除记录或管理其他用户账号的权限。

5.3 从接口变化理解产品形态¶

原始书稿列举了搜索、编程、电脑操控和个人助手等产品。本章不比较品牌强弱，而是借用它们的任务类型，看看接口变化意味着什么。⁵

搜索类Agent在收到一个主题后，不只写已有知识，还可以检索网页、阅读结果、寻找缺失证据。如果搜到的资料互相矛盾，下一步可以是寻找更直接的来源。这增加的是获取外部信息的能力，但搜索结果本身仍要核查。

编程类Agent（Coding Agent）可以读取代码、修改文件，再运行测试。测试失败信息又成为下一轮修正的输入。它与“聊天框里生成一段代码”的重要区别，是能够接触实际项目及其运行反馈，而不只是描述一段可能可用的代码。

电脑操控（Computer Use）把屏幕、页面结构、点击和输入作为交互通道。系统可以尝试在界面中办事，但点击按钮不等于业务已经成功：页面可能还在加载，也可能弹出了错误，需要继续观察。

语音输入、定时事件和用户授权的本地文件访问，则分别改变了信息的形式、任务的触发时机与可访问的数据范围。它们说明，设计Agent不只是在挑选模型，还包括决定模型怎样接触世界。

这是一种理解产品演进的角度，不是所有产品依次经历的固定历史阶段，也不是工具越多越先进。对于找书任务，接入正确的馆藏查询，比赋予整台电脑的控制权限更贴合这里的任务边界。

六、ReAct：把“想、做、看”接成一个闭环¶

6.1 为什么不能只在开头计划一次¶

你可能会问：既然模型会规划，为什么不一次性写好所有步骤，再照着执行？原因在于，有些信息只有执行之后才知道。

在找书之前，系统不知道哪本书已借出；在查询之后，它可能发现某本书只适合更有基础的读者。原先的计划需要随反馈调整。否则，即使每一步都“按计划完成”，也可能没有解决用户的问题。

ReAct这个名称结合了推理（Reasoning）与行动（Acting）。Yao等人的论文研究了交替生成推理轨迹与任务行动的方法：推理帮助调整行动计划，行动帮助接触外部信息。⁶ 本章用“想—做—看”记住这一机制，再加入工程上必要的检查与停止规则。

需要区分：ReAct是一种具体研究方法，不是所有工具调用系统的严格同义词。下面是受其启发的简化教学闭环，也不要求产品向用户展示模型的完整内部推理。

6.2 一次找书任务怎样推进¶

下面的“选择依据”是便于学习的教学说明，不是某个真实模型的隐藏思考记录。每一步的动作都限定在查询范围内。

当前情况	下一步行动与选择依据	环境反馈怎样改变后续步骤
只有主题和阅读要求	搜索月球主题的馆藏，先找到候选书	得到候选书目，才能继续比较
某候选书简介适合入门	查询这本书是否可借	如果已经借出，就不能把它当作“现在可借”的结果
第一候选已借出	查询另一候选的简介和馆藏	若内容适合且在馆，就有了符合要求的候选
已找到候选，但还不知道借阅办法	查询本馆借阅说明	补齐地点、手续等用户要求的信息
已有对应证据	整理书名、推荐理由、查询时点和借阅方法	程序核对是否覆盖任务要求，再返回结果

这里没有必须用完的固定轮数。如果第一次查询已经返回足够信息，就不必额外查询。如果始终找不到合适的书，应说明“没有查到符合条件的结果”，而不是为了交差编出一本。

6.3 轨迹：系统怎样知道自己已经做过什么¶

执行过程中累积的请求、行动、结果和状态记录，称为轨迹（Trajectory）。在找书任务里，它相当于工作记录：“查过第一本，已借出；查过第二本，简介符合要求；还差借阅办法。”

没有相关记录，模型下一轮可能又从第一本书查起。不是系统真的“忘性大”，而是新一轮调用没有收到先前的有效进展。相反，如果把大量无关日志全部塞进去，也可能让关键事实难以找到。

因此，Harness要做的不是永远保留所有文字，而是为当前决定提供必要、准确的状态与证据。长期记录可以保存在模型之外；每一轮需要哪些内容，再组织进上下文。第4章会展开这种上下文管理。

6.4 怎样结束，才不是“模型说了算”¶

一个闭环需要区分“模型准备回答”和“任务已被验证完成”。找书任务的完成条件可以是：候选符合主题，难度判断有简介支持，可借状态有查询记录，借阅办法有对应来源。模型准备结束时，系统要核对这些要求，而不是仅看回复里有没有“已完成”三个字。

其中，有无查询记录、书目编号是否匹配，可以交给程序检查；“读起来是否适合你”则包含主观判断，应展示推荐依据，必要时让你确认。独立核验不意味着所有问题都有一个能自动算出的标准答案。

无法继续时，也要有合适的终点。信息不足可以等待用户补充；查询服务不可用可以返回失败说明；达到允许的时间或调用次数，就应停止。停止不一定代表成功，却比无休止地尝试更可控。

技术深潜：可跳过的伪代码。 下列代码像一份简写的流程说明，不能直接运行。这里的预算包括每一轮尝试，不只计算工具调用；限时执行还需要能响应取消，不能仅在循环开头检查一次。

建立任务记录，设定总时间与尝试次数上限

只要没有取消、也没有达到上限，就重复：
    为本轮预留预算
    根据任务记录准备上下文
    在时间限制内，让模型提出下一步建议

    如果建议结束：
        核对完成条件与证据
        通过就返回结果；不通过就记录还缺什么
    否则，如果需要用户补充：
        暂停并向用户提问
    否则：
        检查工具、参数和当前权限
        允许才在时间限制内执行；不允许就记录拒绝原因
        把行动和结果写入任务记录

若因为取消或达到上限退出，返回未完成状态和原因

这段流程的重点不是语法，而是顺序：先提出请求，再检查执行；先获取结果，再决定下一步；结束时说明是完成、受阻还是取消。 真实系统还需要处理并行操作、保存恢复位置等问题，第3章和第9章会继续展开。

七、Agent如何学习和变化：这次答对了，不等于模型被重新训练了¶

7.1 当前任务里的变化：获得新资料¶

找书时，你补充了一句“我更喜欢有插图的”。下一次模型调用看到了这个偏好，于是改变推荐。这叫任务内的上下文适应：输入变了，行为随之变化，但不意味着模型内部参数被改写。⁷

可以把它类比为做开卷题：桌上新放了一张资料，答题时就能参考。这是帮助理解的比喻，不是在说明人脑与模型具有相同机制。

下一次新会话是否还记得偏好，要看应用有没有保存，并在需要时重新提供给模型。在本次聊天里说过，不等于今后每次调用都自动知道。

7.2 跨任务的变化：更新外部资料和程序¶

假设学校改变了借阅规则。可以更新图书馆的规则文档，让系统下次查询新版本；也可以修改执行程序，在预约前检查新的条件。这些变化保存在模型之外，所以称为外部产物更新。

这里的产物不仅是最终报告，还可以是提示词、知识文档、可复用的任务说明或程序。若遇到Skill这个词，本章先把它理解为可按需读取的任务知识与操作指导；它不是给系统授予权限的凭证。

这条路径的一个特点是改动位置较清楚。规则出了问题，可以对照版本查明改了什么、恢复上一版。不过，新文件只是存在那里还不够，系统执行时必须实际读取或调用它，才能影响行为。

7.3 更深层的变化：更新模型参数¶

模型内部有训练得到的大量数值，称为参数。修改这些参数，才是模型训练意义上的更新。它与往上下文里添加一句要求，不是同一件事。

监督微调（Supervised Fine-Tuning，SFT）通过训练样例调整模型；强化学习（Reinforcement Learning，RL）利用奖励反馈调整行为；蒸馏（Distillation）则让一个模型从另一个模型提供的输出或其他训练信号中学习。这些方法的细节放在第13章，此处只需记住：它们需要专门的训练过程，而不是Agent每调用一次工具就自动发生。

应该选哪条更新路径？本书建议先看要改什么。今天哪本书在馆，应查询当前记录；借阅制度变了，应更新规则及执行检查；如果目标是改善广泛的语言理解或决策能力，才进一步评估模型训练是否合适。

临场获得信息、长期更新外部资料、修改模型参数，是三种不同的变化。 把它们区分开，才能知道所谓“Agent学会了”究竟指什么，以及应该怎样验证。

八、为什么Harness不会立即消失：能力和责任是两回事¶

8.1 有些辅助步骤可能变得不再必要¶

假设某个模型原来经常把查询请求写成错误格式，开发者便增加了格式修正程序。以后更换模型或接口，测试发现这类问题已经得到稳定处理，就可以重新评估是否还需要原先的修正步骤。

这是一个条件性的工程例子，不是说某次模型升级已经消除了所有格式错误。它说明：专门补偿某种能力缺口的代码，应该随实际能力变化而重新检查。 保留失去作用的复杂流程，也会增加维护负担。

原始书稿将这一立场概括为“方向认同，节奏务实”。本章将其作为设计判断，而不是预测Harness会在某个时间点被完全取代。⁴

8.2 有些边界不取决于模型聪明与否¶

图书馆的借阅权限不是一道智力题。模型理解规则，并不意味着它获得了管理员身份；它记住某本书上次可借，也不意味着这本书现在仍在馆。

同样，即使模型每次都能正确选择预约工具，系统仍需认证身份、记录操作，并确认预约是否成功。这些职责对应的是实时状态、外部授权和责任记录，不只是模型当前的理解能力。

因此，讨论Harness会不会消失时，应分开问：哪些代码在补模型的短板，哪些代码在执行业务本身的边界？ 前者可能简化；后者仍需要由合适的运行系统承担，具体实现位置可以变化。

8.3 不要把“需要管理”理解成“越复杂越好”¶

一个只读找书助手，不必一开始就拥有付款、群体协作和跨天恢复等全部能力。Harness应围绕实际任务构建，而不是因为某个术语流行，就多加一层系统。

本书建议先明确完成条件，给出最小必要工具，记录关键反馈，再针对实际发现的错误增加检查。既不要把所有判断都写死，也不要把所有责任都丢给模型。

这一取舍可以用一句话记住：让模型在边界内灵活选择，让程序检查边界是否被遵守。 第9章会把这些职责展开为可实现的生产系统设计。

九、常见失败模式与实验：用证据检查我们的直觉¶

9.1 三种“看起来做完了”¶

第一种：回答完整，但缺少事实依据。 找书助手写出了书名、位置和“可借”状态，却没有查询记录。表面上每个问题都有回答，实际上关键状态可能只是猜测。此时要查的是证据来源，而不是回答是否自信。

第二种：工具调用成功，但用户目标没完成。 查询接口正常返回，只说明查询执行了。如果返回的是“无匹配书目”，任务仍未得到想要的结果。预约接口返回“已接收申请”，也未必等于预约已经成立，要按该系统的状态含义继续核对。

第三种：正在反复尝试，却没有新进展。 系统一直查同一本已借出的书，可能是历史没有传给模型，也可能是工具反复返回含糊错误。需要先找出原因，再决定补上下文、换查询方式或停止，而不是无条件重试。

重复查询通常只是浪费时间，重复写入则可能造成重复预约或重复扣款。因此，对会改变外部状态的请求，遇到超时不能直接假定“没有发生”。本书建议先检查权威系统里的实际状态，再决定是否重试，并由程序防止同一请求重复生效。⁴

还有两条应由执行程序守住的底线：不允许的操作应在执行前拒绝；无法继续的循环应按预算停止。第六节的闭环之所以需要检查与终止，就是为了避免把这类问题交给模型临场判断。

9.2 实验1-1：拿掉一部分上下文，会发生什么¶

仅靠故事，我们还不能知道真实模型在信息缺失时会怎样。仓库中的实验1-1选择了一个具体任务：把不同币种的季度收入统一换算，再求年度总额与季度平均。它要求使用给定工具的观察，而不是自行猜汇率。工具数值用于实验，不代表实时金融数据。⁸

为什么选这种任务？因为可以预先算出应得结果，再检查系统是否使用了对应工具证据。不只是看它“有没有回答”，还可以看答案是否正确、数字是否有依据。

实验采用消融（Ablation）方法：先保留完整配置作为基线，再分别去掉某一部分，例如可用工具定义、工具结果、先前历史或保留的推理历史。这样能观察，在指定任务与配置下，缺少某部分会怎样影响行为。

设计消融时还要小心：如果把工具结果换成“结果被隐藏了”，其实又给模型增加了一条提示——它知道发生了信息隐藏。仓库的修正版本采用空的工具消息内容，尽量不额外宣布这件事。但消息壳本身仍然存在，这也是实验边界的一部分。⁹

9.3 记录告诉了我们什么，又没有告诉我们什么¶

完整输入并不自动意味着理论正确，但它可以提供比较起点。 本次核对的记录中，完整基线得到了预期答案。缺少工具结果的运行则出现了重复调用、达到迭代上限仍无最终答案的情况；补充探测也记录过无依据数字。这支持我们关注反馈缺失风险，却不能证明所有模型在缺少结果时都会采取相同动作。⁸⁹

移除保留的推理历史，结果并不一致。 较早的Kimi运行记录在这一条件下仍得到正确答案；较新的DeepSeek运行记录则未通过精确数值检查，最终回答用了较粗的数值。注意，移除的是先前轮次保留下来的推理内容，不是禁止模型在当前轮次推理。不能据此说“推理没有用”，也不能反过来说“少了推理历史一定失败”。¹⁰

没有工具可用，不等于模型一定会坦白不知道。 某些运行会说明限制，另一些会用没有工具依据的数字作答。即使答案恰好接近目标数值，也不满足“必须依据工具结果计算”的任务要求。检查答案来源，与检查答案数值，都是必要的。⁹

这里尤其要区分两句话：“这组实验执行完了”是运行状态；“我们原先的猜想成立”是研究结论。前者不能代替后者。不同模型、不同日期的少量运行，也不能当成严格控制条件下的模型排名。

证据核对说明

本节依据仓库已保存的运行记录撰写，本次没有重新调用模型复现实验。现有实验卡中“移除Reasoning历史仍可正确完成”的概述，不能概括所有已保存运行；本章保留差异，不把其中一次结果写成普遍规律。来源与具体文件见章末。

十、检查清单：你是否真正理解了这个系统¶

不必把下面的清单当作术语测验。可以拿找书助手，或者你用过的一个AI工具，逐条回答。如果回答不出来，通常说明某个边界还没有讲清楚。

[ ] 目标是什么？ 是推荐书名，还是确认当前可借？两种目标需要的证据不同。
[ ] 是否需要动态选择步骤？ 固定查询流程已经够用时，不必为了名称而增加自主Agent。
[ ] 模型这次实际看到了什么？ 不要把“数据在系统里”当成“数据已经进入上下文”。
[ ] 有哪些工具，允许做哪些动作？ 能查记录，不代表能修改记录。
[ ] 行动之后会返回什么反馈？ 返回空结果、错误和成功，下一步应有区别。
[ ] 怎样证明任务完成？ 文本承诺不是预约记录，查询成功不是一定找到合适的书。
[ ] 谁控制权限和停止？ 用户取消、预算耗尽或操作不被允许时，应由程序处理。
[ ] 哪些是事实，哪些是建议或猜测？ 每条关键结论的依据和适用范围应能说清楚。

知识检查¶

先试着用自己的话回答，再看参考解释。能把机制讲给另一位初学者听，比记住英文缩写更重要。

AI说“这本书在馆，可以借”，但没有查询学校目录。这句话缺少什么？
一个程序按固定顺序查询馆藏、筛选结果、生成说明，它一定是本章定义下的自主Agent吗？
为什么查询工具属于Agent的接口，而图书馆记录属于Environment？
给模型补充一本书的简介，与重新训练模型，有什么不同？
系统收到了预约申请的“已接收”回执，为什么还不能直接说“预约成功”？
看到一条“去掉推理历史后仍然答对”的记录，可以推出推理历史永远不重要吗？

参考解释¶

第1题：缺少与当前学校、当前时点对应的馆藏证据。 模型可能知道这本书，却不知道它此刻在不在馆。应该查询；没有查询能力时，应说明无法确认。

第2题：不一定。 按预定步骤和分支执行，可以是工作流。判断依据不是用了几次工具，而是后续关键行动主要由预定义程序决定，还是由模型根据反馈动态选择。

第3题：接口与被访问对象的职责不同。 工具负责表达和传递查询；环境保存实际书目与借阅状态。模型生成的请求不能自己决定这些状态。

第4题：补简介改变的是本次输入，训练改变的是模型参数。 如果下一次调用没有收到这份简介，也没有从外部保存位置重新取回，就不能假设它自然拥有该信息。

第5题：“已接收”只说明申请到达了系统。 它可能还需排队、审核或分配。应依据预约系统的最终状态解释结果；无法确认时，就报告仍在处理中。

第6题：不能。 它只能说明那次任务、模型和配置下仍然答对。其他记录已经出现不同结果，而且移除历史不等于关闭当前推理。

本章小结¶

回到最开始的找书请求，你现在可以把整个过程串起来：用户提出目标；Harness准备当前资料；模型提出下一步；程序检查并调用工具；环境返回结果；相关反馈进入下一轮。找到有依据的结果就结束，受阻就说明原因，需要补充就询问用户，而不是靠一句“已完成”越过检查。

所以，理解Agent最重要的不是记住几个缩写，而是始终追问：它看到了什么，决定做什么，实际发生了什么，凭什么说完成了？

下一章将接着问一个实用问题：既然Agent增加了这些环节，什么时候值得使用它，什么时候一个简单程序或固定工作流就够了？

来源与证据¶

本章保留原有Agent、Model、Harness、Environment的概念边界；新增的找书故事仅用于教学。工程建议以“本书建议”等措辞表达，不作为实验已经证明的普遍规律。以下仓库链接固定到本次修订前的版本，便于核对，不依赖会变化的主分支内容。

原始中文书稿《AI Agent入门》的“现代Agent = LLM + 上下文 + 工具”及“ReAct循环”，见原始第1章。本章沿用蓝皮书的工作定义，不声称它是覆盖所有AI研究领域的唯一术语定义。 ↩↩
原始第1章“编排模式：工作流与自主”及“两种模式的选择与混合”。原稿进一步引用Anthropic的Building effective agents；本次扩写以已核对的仓库书稿为依据，保留预定义工作流与动态行动选择的区别，不引入新的产品效果结论。 ↩
原始第1章图1-1及“Harness工程：模型之外的竞争力”。核心边界是：工具定义、适配与权限控制属于运行支持，文件、数据库及其变化状态属于环境；物理部署位置不决定概念归属。 ↩
原始第1章“Harness工程”“模型即Agent”及“护栏与安全性”；副作用与重试的进一步约束见蓝皮书第9章。本章将职责分工作为工程建议展开，不沿用原稿中未经本次独立核验的产品代码占比、排行榜提升或行业强判断。 ↩↩↩↩
原始第1章“观察空间与动作空间：模型与世界的接口”及工具分类。本章只抽取搜索、代码执行、界面操作等交互机制，不保留产品首创、市场领先和具体版本能力的判断。 ↩
Shunyu Yao等，ReAct: Synergizing Reasoning and Acting in Language Models。本次核对论文摘要中的“交替生成推理轨迹与任务行动、利用外部信息调整计划”机制，不引用其基准分数，也不将本章工程伪代码称为论文的完整实现。 ↩
原始第1章“Agent的学习机制：从上下文适应到持久更新”。三条路径是任务内上下文适应、跨任务外部产物更新和模型参数更新；本章的借阅规则例子是教学展开，不是训练效果证据。 ↩
实验1-1的2026-09-01运行记录。本次核对记录中的任务约束、分组结果、最终回答及分析限定，没有重新执行真实API实验。记录中的模型标识为deepseek-v4-flash；该标识用于定位仓库记录，不构成对模型市场发布信息的独立核验。 ↩↩
第一章实验台账，实验1-1行。台账记录了空结果与可见隐藏标记的区别、小样本及非确定性限制，并指出提示约束不能被当作阻止捏造的可靠开关。台账中的历史运行叙述不应自动当成最新运行的汇总。 ↩↩↩
对照2026-08-25保存的运行与2026-09-01保存的运行中的no_reasoning分组：前者记录的模型标识为kimi-k3，结果为correct；后者为deepseek-v4-flash，结果为incorrect。后者最终回答使用了较粗数值，未满足精确答案检查。两次运行不能用来隔离模型差异或证明某种失败原因；它们足以提醒我们，不应把单次结果写成必然规律。 ↩

第1章 定义、边界与产业演进¶