与人工智能代理入门 [第1/9部分]¶

人工智能代理入门¶

如果你使用过Cursor编写代码，并且看到它搜索你的代码库、编辑多个文件并重新运行测试直到通过，那么你已经使用过人工智能代理了。如果你使用过Deep Research通过反复搜索和阅读来研究某个主题、让Manus控制浏览器完成在线任务、让豆包手机助手订票或发送消息，或者让Pine AI协商更低的电信账单，也是如此。

这些产品有多种形式，但它们有一个共同特征：它们不再是被动的“你问，它回答”的对话。它们会规划自己的执行步骤，调用每个任务所需的工具，并根据结果调整策略。人工智能代理正在成为与计算机交互的一种新方式。

本章从实际示例开始，逐步深入到人工智能代理的核心组件：读者将亲身体验现代代理能做什么，了解其背后的架构，并学习构建代理系统的设计模式和最佳实践。

阅读提示：本章是整本书的概念图：对核心公式、操作循环、工程框架和代理设计模式进行简洁概述。它建立了贯穿后续章节的共享词汇和参考点。第一次阅读时不要试图记住每个概念；要把握大局。后面的每个章节都会扩展这里介绍的一个方面，你可以在需要重新定位时回到本章。

现代代理 = 大语言模型 + 上下文 + 工具¶

现代代理系统的本质可以用一个简洁的公式概括：代理 = 大语言模型（LLM） + 上下文 + 工具。这个公式简单实用——只要对每个术语进行宽泛理解：

大语言模型是代理的推理引擎：它不仅仅是一组模型参数；它是代理的决策核心，负责理解意图、推理、规划和判断。大语言模型的能力来自于预训练期间获取的世界知识和语言能力，以及通过后训练编码的决策策略（第7章将介绍监督微调、强化学习等技术）。
上下文是代理的工作信息集：不仅仅是输入模型的文本，而是代理在每个决策点可用的工作信息集——环境、用户记忆、领域知识、自身状态和任务进展。就像一个人做决策时需要评估情况、回忆相关经验并参考资料一样，代理的上下文窗口包含了它在那一刻可以使用的信息。
工具是代理的行动接口：不仅仅是少数可调用的API函数，而是代理可以采取行动的全套方式——从预定义的工具调用到来按需加载的技能，从生成代码即时创建新能力到将工作委托给子代理，从与用户互动到响应外部事件。

更直观地说：代理 = 推理引擎 + 工作上下文 + 行动接口。模型进行推理和决策，上下文提供这些决策所依赖的工作信息集，工具提供决策影响外部世界的接口。

这三个组件正好对应强化学习（RL）中的三个核心概念（第7章有介绍）。以下表格是可选阅读——如果你没有强化学习背景，可以随意跳过；后面的内容不依赖它。它仅帮助熟悉强化学习的读者将相关知识映射到本书的术语中：

直觉	代理组件	RL概念（可选）	角色
推理引擎	大语言模型	策略	决定“下一步做什么”的决策逻辑——根据当前信息，从所有可用选项中选择最合适的行动
工作上下文	上下文	观测空间	代理可用的所有信息——它能观察、读取、记住的内容以及能访问的系统
行动接口	工具	行动空间	代理能做的全套事情——从发送消息到执行代码再到控制接口的“手段”

观测空间和行动空间：模型与世界的接口¶

在他们的经典教科书《计算机体系结构：一种定量方法》中，亨尼西和帕特森在第1章以“什么是计算机体系结构？”开篇，并将指令集体系结构（ISA）确定为软件和硬件之间的接口¹。这种视角为我们理解代理提供了一种有用的方式：观测空间和行动空间共同构成了大语言模型与其外部环境之间的接口。观测空间将环境中的信息转化为模型可以处理的上下文；行动空间将模型决策转化为对外部世界的操作。观测空间之外的信息对模型来说实际上不存在。行动空间之外的操作仍然是模型只能用语言推荐的事情，即使它完全知道应该做什么。

因此，一旦底层模型保持不变，提高代理性能的主要系统工程手段通常是重新定义或扩展其观测空间和行动空间。用本书的术语来说，这意味着扩展上下文和工具。许多看似需要“更智能模型”的问题实际上是接口问题：将与任务相关的数据带入上下文，或者将所需操作暴露为工具，那么之前无法解决的任务可能在不重新训练模型的情况下变得可解决。

Manus：合并原本独立的空间。在Manus出现之前，生产型代理主要遵循三条不同的路线：深度研究、编码和计算机使用。Manus是第一个在一个系统中广泛有影响力地将这三者整合在一起的生产型代理。网络扩大了它的观测空间；文件系统和代码执行扩大了它的行动空间；屏幕感知以及点击和输入将图形界面带入了两者。Manus不仅仅通过替换更强的模型成为通用代理。它整合了三种代理的观测空间和行动空间，使一个代理能够跨越之前的产品边界。

OpenClaw：将接口扩展到用户的数字生活。OpenClaw再次将两个空间向外扩展。它通过用户已经身处的消息通道——WhatsApp、Telegram、Slack、Discord、iMessage等——接收任务并返回结果，因此几乎可以从任何地方接触到代理。它的本地优先网关，加上授权的工具、插件和技能，可以连接谷歌云端硬盘和Notion等云应用以及本地文件系统。因此，在用户明确授权的情况下，分散在各个账户和设备上的文件可以进入一个代理的观测空间，并由其工具进行操作。与最初以云沙盒为中心的Manus形式相比，本地优先的OpenClaw跨越了更广泛的数据边界。Manus后来添加了自己的谷歌云端硬盘连接器和对本地文件的桌面访问——这进一步强化了这一点：产品演进通常正是通过扩展观测空间和行动空间来实现的²。

扩展并不意味着立即将所有可用的词元和工具都注入模型。不相关的上下文会增加噪声，而工具太多会增加选择成本和安全风险。有用的扩展必须是按需、相关且受控的：检索应该将正确的信息放入上下文，工具发现应该只暴露当前需要的行动，权限和结果验证应该约束这些行动。后面的章节将详细介绍这些技术。

理解每个组件的作用以及它们如何协同工作，是构建有效代理系统的基础。我们将从三个组件中最具体的一个——工具，即行动接口——开始，向内深入到大语言模型和上下文。首先，以下是不同类型的代理在这三个维度上的比较：

人工智能代理入门 [第2/9部分]¶

代理产品	工作上下文	动作接口	策略
编码代理（例如Cursor）	需求文档、代码库、终端环境	开放式（内部推理、代码搜索、文件读写、命令执行等）	增量式开发：理解需求→搜索相关代码→编辑代码→测试验证→调试修复
搜索代理（例如Deep Research）	网络资源、学术数据库、本地文件	开放式（内部推理、搜索查询、网页阅读、摘要生成）	迭代深化：根据现有信息调整搜索方向，逐步合成完整报告
计算机控制代理（例如浏览器使用）	计算机屏幕、浏览器页面、文件系统	开放式（内部推理、点击、打字、滚动、截图、代码执行等）	视觉感知+操作：观察屏幕→识别目标元素→执行操作→验证结果
手机助手代理（例如豆包）	手机屏幕、已安装应用	开放式（内部推理、点击、滑动、打字、打开应用等）	意图理解+应用控制：理解用户需求→定位目标应用→执行操作→确认完成
个人任务代理（例如Pine AI）	用户账户信息、历史账单、服务提供商知识库	开放式（内部推理、打电话、发邮件、填表、与用户确认）	多步骤任务执行：收集信息→制定谈判策略→联系服务提供商→谈判→报告结果

这些系统具有三个共同特征：开放式动作空间——不是从固定的按钮集合中选择，而是生成任意自然语言和代码；内部推理——在行动前进行规划；以及连续交互——根据环境反馈调整策略。这些能力正是源于推理引擎、工作上下文和动作接口的相互作用——也就是大语言模型（LLM）、上下文和工具的相互作用。

工具：代理的动作接口¶

工具是代理与外部世界的桥梁。它们将代理从被动观察者转变为能够搜索、写入文件、运行代码、调用API、发送消息或操作界面的主动系统。没有工具，代理仅限于文本生成；有了工具，它就能对外部系统采取行动。

为了系统地讨论工具，我们可以根据代理与世界交互的方向将其分为五类。在这个阶段，简要概述每种类型的代表性场景就足以建立整体图景；后续章节将深入探讨每种类型。

感知工具使代理能够获取信息：搜索引擎提供实时网络数据，文件系统读取本地文档，API和数据库连接外部服务和企业核心数据。

执行工具使代理能够对外部系统采取行动：代码执行、文件操作、系统命令和外部API调用将决策转化为具体行动。

协作工具使代理能够与其他代理分工合作：将专门任务委派给子代理，在关键决策点请求人类确认，或在多代理系统中协调行动。

事件触发工具的调用方式与前三种类别根本不同：代理不会调用它们；它们作为外部输入到达，触发代理开始工作。新邮件到来、预定时间到达或另一个系统触发Webhook回调；事件激活代理并启动推理和行动。代理本身不会调用这些工具，但它们仍然是代理与外部世界交互的渠道，因此我们将其计入广义的工具系统中。

用户通信工具是代理与用户通信的渠道。执行工具改变外部世界，而通信工具传递信息——通过短信、语音通话、电子邮件等传递代理的进展或主动签到。

第4章将涵盖这五类工具的完整分类法和设计原则。工具设计的质量直接决定了代理能够可靠完成的任务：接口定义模糊，模型会误用它们；错误处理不佳，单个工具失败可能会让代理陷入困境；权限范围过广，一个代理错误可能会不可逆转。随着MCP（模型上下文协议）标准的推广，集成工具变得像安装插件一样简单——生态系统正在迅速扩展，但设计原则不会过时。

工具调用（也称为函数调用）是现代大语言模型代理的核心能力：它让模型以结构化方式调用外部工具，将大语言模型从纯文本生成器转变为能够通过外部接口行动的智能系统。本书通篇使用“工具调用”这一术语。

工具调用分为四个步骤：首先，上下文告知模型可用的工具（名称、用途、参数）；然后，模型自行决定是否调用工具、调用哪个工具以及使用什么参数；接下来，工具运行后，其结果附加到上下文中；最后，模型根据该结果决定下一步行动。这个循环是后续章节介绍的ReAct循环的基础。

以天气查询为例，API级别四步过程的简化表示如下：

步骤1：声明工具                  步骤2：模型决定调用
tools: [{                             assistant: {
  name: "get_weather",                  tool_calls: [{
    parameters: {                           function: "get_weather",
      city: "string"                        arguments: {city: "Beijing"}
    }                                      }]
}]                                    }

步骤3：结果附加到上下文          步骤4：模型根据结果回应
tool: {                               assistant: {
  tool_call_id: "call_1",               content: "Today in Beijing: 28°C, sunny."
  content: '{"temp":28,"sky":"clear"}' }
}                                     }

开发者只需定义工具并执行调用；模型本身决定是否调用、调用哪个工具以及传递什么参数。第2章将详细检查这种API结构。

为代理设计工具时，从任务所需的最窄能力开始，然后随着任务变得更复杂逐步扩展。如果任务只需要基本算术，具有明确定义参数的计算器就足够了；当任务扩展到读取电子表格、清理缺失值、计算统计数据和绘制图表时，受限制的Python代码解释器比不断增长的专门工具集合更容易组合和探索。但通用性也会增加错误风险并扩大攻击面：代码必须在隔离沙箱中运行，默认禁用网络访问，无法访问授权工作目录外的文件，并且对执行时间、CPU、内存和输出大小有限制。

同样，单个日志工具适合记录一次执行；对于耗时数小时甚至数天的长期任务，受控虚拟工作目录可以保存计划、中间结果、执行日志和最终工件，以便代理在多次运行中恢复。该目录还应限制可读和可写路径、存储容量和文件类型，并防止路径遍历，而不是将整个主机文件系统暴露给代理。

通用工具并不总是比专门工具更好。高风险操作或受严格业务约束的操作——例如支付、数据删除、发送电子邮件和生产部署——仍应作为具有明确参数、受限权限和端到端可审计性的专用工具公开，并在必要时添加预览和人类确认。因此，工具设计的核心原则是：使用通用基础能力进行组合和探索；使用专用工具约束高风险操作并强制执行严格业务规则。

大语言模型：代理的推理引擎¶

大语言模型（LLM）是代理的决策核心。给定用户请求，它首先必须推断真实意图（用户所说的往往不是他们实际想要的），然后将模糊或复杂的任务分解为可执行步骤。在整个执行过程中，它不断做出决策：下一步做什么、是否调用工具、调用哪个工具以及使用什么参数。这种理解-规划-执行能力来自预训练期间积累的知识，是工作流和自主代理都依赖的基础。

大语言模型代理的一个显著能力是内部推理——在行动前，代理可以规划和推理任务。这不会改变外部环境，但会显著改善后续行动。这种能力来自预训练（在大量互联网文本上的初始训练，通过该训练模型学习语言模式和世界知识）：模型利用人类知识中编码的推理模式，包括数学定律、因果关系和分解问题的策略。因此，代理的推理不是盲目试错，而是基于结构化知识体系。

面向AI智能体的入门指南[第3/9部分]¶

这种结构化推理使大语言模型（LLM）智能体能够在没有先前示例的情况下处理全新任务——零样本和少样本这两个概念说明了这一点。直接体现是零样本泛化：面对从未见过的任务，智能体通过重组已有的知识来处理它，不需要示例。模型可能从未被明确教导过写关于量子物理的诗歌，但它可以根据现有的语言和物理知识创作出合理的诗歌。

通过几个示例，大语言模型智能体还可以进行少样本适配：提示词中的两三个演示就足以让它学习新任务模式。如果展示一些“用户评论→情感标签”的示例，它就能对新评论进行情感分类。简而言之：零样本意味着不用示例解决任务；少样本意味着从少量示例中学习模式。

模型作为智能体：当模型本身成为产品¶

“模型作为智能体”范式是AI智能体开发的最新方向。先进模型通过训练后（尤其是强化学习）将工具调用内化为原生能力：何时调用工具、调用哪个工具、使用什么参数——模型自行决定，无需手动编排。这并不意味着框架层不重要。相反：模型越强，周围的框架就越重要。在智能体语境中，框架是将模型能力转化为可靠任务执行的工程基础设施。它包括上下文管理、工具接口、安全约束以及验证和纠正机制（见本章最后一节）。

模型拥有的决策权限越大，错误决策的影响就越大——这需要更精细的约束、验证和纠正来保持其可靠性。模型提供商的真正优势不是“让框架更薄”，而是能够共同优化模型及其周围的框架，持续迭代。

但随之而来的是一个更深层次的问题：如果模型不断变强，今天的框架最终会被模型吸收吗？在《苦涩的教训》中，里奇·萨顿回顾了AI研究七十年中反复出现的模式³：研究人员反复将他们对某个领域的理解编码到系统中，实现短期收益，但最终输给了随计算和数据扩展的通用方法——搜索和学习。从这个角度看，框架中的多少约束、验证和纠正属于“人类先验”，是模型注定要内化的？本书的立场可以用八个汉字总结：认可方向，务实节奏。从方向上看，我们毫不怀疑模型将继续吸收框架的部分内容——工具调用和长视野规划曾经依赖外部编排，现在已成为原生模型能力。然而在实践中，这种吸收比直觉慢得多：训练以月为时间尺度进行，没有模型能在一次训练中内化真实业务的所有约束和偏好。模型当前的能力边界正是框架创造价值的地方。因此，框架工程不是对《苦涩的教训》的抵抗，而是在工程时间尺度上的实践：模型还不能可靠完成的事情，框架先覆盖；每当模型内化另一层，框架就舍弃该层，转向支持下一个能力前沿。这条主线贯穿全书——第2章从上下文工程角度提供务实答案，第8章进一步讨论智能体如何从操作经验中选择和验证下一次系统更新，后记回归模型是否会吸收框架的完整答案。

智能体学习机制：从上下文适配到持续更新¶

前面的讨论指出，模型可以通过强化学习将工具使用策略内化为原生能力。但智能体行为的变化不仅发生在训练期间。根据更新发生的位置和持续时间，这些变化可以理解为三条互补路径（图1-1）：任务内上下文适配、跨任务外部工件更新和训练周期内的参数更新。

图1-1：智能体能力更新的三个层次

上下文适配发生在当前任务内。一旦示例、状态和检索结果进入上下文，模型就能立即调整行为，但这不会改变下一会话的持久状态。其优势是速度快、成本低；局限性源于上下文窗口和信息组织方式。第2章将详细解释这种适配形式的工作原理。

为了让变化在任务间持续，系统可以更新外部工件：事实和经验可以组织成知识文档，可用语言表达的策略可以写入提示词或技能，确定性程序和约束可以编码到程序和框架中。这些工件可审计且可修订，但智能体仍必须在执行时通过上下文或工具接口访问它们。第3章到第5章建立知识和程序的基础，第8章讨论如何从评估后的操作轨迹生成此类更新。

当目标是高维能力——如医学图像理解、自然语言风格或隐式决策策略——而外部规则无法完全表达时，必须通过训练后更新模型参数。参数更新带来更高的部署成本，但能产生自然且广泛的泛化；第7章系统介绍其方法。因此，这三条路径不是互斥的类别，而是在不同时间尺度上运作的协调机制：上下文支持即时适配，外部工件支持可控积累，参数内化难以明确表达的能力。

上下文：智能体的工作集¶

上下文是智能体在每个决策点可获取的信息工作集。就像人做决策时需要桌上有正确的材料——任务说明、参考手册、之前的通信、最新数据——智能体的上下文窗口是它可以使用的信息。从API的角度（第2章详细介绍），每次大语言模型调用的上下文包括五部分：

系统提示词：不同于用户在对话中输入的提示词，系统提示词由开发者编写，在整个对话中保持固定。它是智能体的“工作描述”——定义其身份、权限和行为规则。精心进行系统提示词的提示工程是塑造智能体操作行为的方式。系统提示词还包含跨会话持久化的用户记忆（偏好、过去行为、背景设置等个性化信息；见第3章），以及动态注入的环境状态。
工具定义：声明智能体可用工具的名称、功能描述和参数格式。没有工具定义，智能体无法识别或调用任何工具——消融研究（实验1-1）将验证这一点。工具定义与系统提示词一起构成整个对话中保持不变的静态前缀。（这是基础模式；自2026年起，生产框架还可以在上下文末尾按需加载完整工具架构而不破坏前缀——见第2章和第4章的工具定义部分）
用户消息：用户的输入。用户消息可能还包含通过RAG（检索增强生成，详情见第3章）动态检索的外部知识——涵盖训练数据截止日期之外的信息或私有领域知识。
助手消息：模型之前生成的响应，可包含最多三部分——推理（内部思维链，保持连贯性和决策可解释性）、内容（对用户的响应）和工具调用（智能体采取行动的方式）。在特定响应中，这三部分可能不会同时出现：例如，当智能体决定调用工具时，通常只有推理+工具调用；当给出最终答案时，通常只有推理+内容。
工具结果：智能体框架执行工具后返回的输出。这些结果是智能体下一步推理步骤的直接依据——使其能够从结果中学习而非重复错误。

前两项（系统提示词+工具定义）构成静态前缀；后三项（用户消息+助手消息+工具结果）构成随每次交互增长的动态消息历史。这五部分共同构成每次大语言模型推理的上下文。

人工智能代理入门 [第4/9部分]¶

每个组件真的都是不可或缺的吗？最直接的方法是进行消融研究——一种一次排除一个原因的诊断方法：移除组件A，看看系统是否仍然有效，然后是组件B，依此类推，直到每个组件的贡献清晰明了。实验1-1正是将这种方法应用于上述五个组件。结果一目了然：没有工具定义，代理完全无法行动；没有工具结果，它不会收到上一步的反馈，因此会反复调用同一个工具，陷入无限循环；没有助理消息中的推理，连续的决策开始相互矛盾；没有消息历史，代理会失去任务连续性，从头开始重新执行整个任务，重复已经完成的步骤。每个组件的作用都有实验证据支持，而非仅仅是理论推断。

实验1-1 ★★：上下文的关键作用¶

我们通过系统的消融研究探究了每个上下文组件如何塑造代理行为。在上述五个组件中，四个进行了测试——系统提示作为代理的基本身份定义被豁免：没有它，代理完全没有角色意识，测试将毫无意义。如图1-2所示，实验设置了五组对照：一组保留所有组件的完整基线，另外四组每组缺少一个组件，以观察每个组件对代理性能的影响。

图1-2：实验1-1——上下文消融研究设计

实验结果揭示了每个上下文组件不可替代的作用。工具定义（静态前缀的一部分）是代理行动能力的基础；没有它们，代理无法识别或调用任何工具。工具结果是闭环控制的关键；缺少它们会剥夺代理的执行反馈，导致其陷入无限循环。推理过程（助理消息中的推理部分）保留了代理先前决策的原因，使整体推理更连贯，防止矛盾决策。消息历史（用户消息、助理消息和之前轮次的工具结果）防止冗余操作，保持任务执行的连贯性，避免重复同样的错误。

实验的核心见解是：上下文决定了代理在决策时拥有的信息，代理只能基于该信息进行决策。正如一个人缺少关键文件无法做出合理判断一样，缺少任何上下文组件的代理都会严重丧失决策能力——没有工具定义，它不知道存在哪些工具；没有之前的执行结果，它不知道已经做了什么。

ReAct循环¶

掌握了三个组件后，自然会产生一个问题：它们如何协同工作？ReAct循环是将大语言模型（LLM）、上下文和工具连接成一个系统的核心机制。我们可以逐步审视它。

代理执行任务的核心模式称为ReAct（推理+行动）。名称只提到了推理和行动，但实际循环有三个阶段：模型首先推理下一步该做什么，然后调用工具来行动，接着观察工具的结果并推理后续步骤。这个“推理→行动→观察→推理→行动→观察”的循环会重复，直到任务完成。

以跨多种货币汇总收入的具体示例来理解代理的轨迹：代理工作时积累的消息历史，包括用户消息、助理消息（含推理和工具调用）和工具结果。每次LLM调用时，模型接收的完整上下文是静态前缀（系统提示+工具定义）加上轨迹（动态消息历史）（图1-3）。这表明一个关键事实：代理上下文=静态前缀+轨迹。具体来说，静态前缀是上述五个组件中的前两个（系统提示+工具定义）；轨迹是后三个（用户消息+助理消息+工具结果，随每次交互增长）。LLM从这个完整上下文中生成下一个响应，然后附加到轨迹中供后续调用。

图1-3：代理轨迹——多货币汇总任务的ReAct循环

以下是轨迹的伪代码结构：

轨迹 = [
  {角色: "用户", 内容: "根据公司季度收入：第一季度250万美元（美元）、第二季度210万欧元、第三季度180万英镑、第四季度3.8亿日元，计算公司年度总收入和平均季度收入"},

  # 第一次迭代 - LLM接收上述轨迹并生成响应
  {角色: "助理",
   推理: "需要将所有货币转换为美元...",
   内容: "",  # 没有直接回复用户
   工具调用: [
     {名称: "convert_currency", 参数: {金额: 2100000, 来自: "EUR", 到: "USD"}},
     {名称: "convert_currency", 参数: {金额: 1800000, 来自: "GBP", 到: "USD"}},
     {名称: "convert_currency", 参数: {金额: 380000000, 来自: "JPY", 到: "USD"}}
   ]},

  # 代理框架执行工具，将结果添加到轨迹中
  {角色: "工具", 内容: "欧元→美元：2282608.7"},
  {角色: "工具", 内容: "英镑→美元：2278481.01"},
  {角色: "工具", 内容: "日元→美元：2541806.02"},

  # 第二次迭代 - LLM接收包含工具结果的完整轨迹
  {角色: "助理",
   推理: "已获得转换结果，现在需要汇总并计算...",
   内容: "",
   工具调用: [
     {名称: "code_interpreter", 参数: {代码: "total = 2500000 + 2282608.7 + ..."}}
   ]},

  {角色: "工具", 内容: "总计：9,602,895.73美元，平均：2,400,723.93美元..."},

  # 第三次迭代 - LLM接收完整轨迹并生成最终答案
  {角色: "助理",
   推理: "所有计算完成，总结结果...",
   内容: "最终答案：总收入9,602,895.73美元..."},
]

请注意，系统提示和工具定义未在轨迹中显示——它们作为静态前缀，在每次LLM调用前自动添加到轨迹前面。

在我们的实验中，这个循环清晰可见。第一轮，代理分析任务并并行调用三个货币转换工具；第二轮，它将转换结果提供给代码解释器进行计算量较大的计算；第三轮，确认所有计算完成后，它生成最终答案。一个复杂的多步骤任务在3次迭代和4次工具调用中完成。

这种设计的精妙之处在于上下文的累积性。每次LLM调用都接收完整的轨迹，所以模型知道任务处于哪个阶段、之前尝试过什么以及结果如何。正如人们在解决问题时不断回顾和总结一样，代理通过其轨迹保持对任务的全局视图。而且由于轨迹结构清晰——用户消息、助理消息（推理+工具调用）和工具结果都明确分开，系统具有高度的可解释性和可调试性。

轨迹不仅是执行记录，更是代理能力的证明。大规模分析轨迹可以揭示行为模式、更好的决策路径和更好的工具设计。轨迹数据甚至可以提炼成知识库，或通过强化学习用于训练更强的代理模型——形成从经验中学习的闭环。

现在我们了解了代理的操作循环，接下来通过两个实验看看不同模型如何驱动它。

实验1-2 ★：Kimi K3原生代理能力¶

这个实验展示了Kimi K3的原生代理能力，这是“模型即代理”范式的一个示例。Kimi K3由月之暗面公司于2026年发布，是一个约有2.8万亿参数的专家混合（MoE）模型。MoE可视为一个专家团队：对于每种问题，系统仅激活最适合它的少数专家，而不是整个模型，在保持能力的同时避免了全部效率成本。Kimi K3具有100万个词元的上下文窗口、原生视觉理解能力和始终开启的“思考模式”。通过强化学习，它将工具调用的决策策略内化为原生能力：何时调用工具、调用哪个工具、传递什么参数都由模型决定，使其能够自主执行网络搜索等任务。准确地说，内化的是何时以及如何调用的决策；工具本身，如web_search和code_runner，仍然作为API级内置工具在服务器端执行。Kimi通过一个名为Formula的服务器端脚本引擎运行这些官方工具。

这里有三个观察要点。首先，强化学习训练让模型学会何时以及如何使用工具，这样客户端就不再需要手动编写工具调用的编排逻辑。其次，模型自行决定何时进行搜索以及搜索什么内容，展现出真正的自主性。第三，它会根据搜索结果调整策略，并判断是否已掌握足够信息。有一个常见的误解值得澄清：强化学习赋予模型的是决策策略，而非工具本身。它教会模型何时调用工具、选择哪个工具、传递什么参数、在收到结果后是否继续以及如何将数十次或数百次调用串联成连贯的推理；这些“何时以及如何使用”的判断被写入模型的权重中。工具及其执行由Agent框架或API内置功能提供：`web_search`和`code_runner`的实现、代码沙箱以及发出调用并返回结果的基础设施都存在于模型之外。强化学习优化的是决策策略；它不会将搜索引擎或代码沙箱嵌入模型的权重中。因此，编排循环并没有消失；它从客户端转移到了服务器端，而决策制定则进入了模型⁴。¶

Kimi K3在Agent任务中的显著优势是长链式工具调用的稳定性——它可以持续进行200 - 300次连续的工具调用，且始终保持连贯的推理，远远超过大多数模型开始出现性能下降时的几十次调用。K3针对长视野编程和Agent工作负载进行了优化，发布了两种变体：K3 Max（用于对话和Agent任务）和K3 Swarm Max（用于大规模并行处理）。作为开源模型，它在软件工程和Agent基准测试中与顶级闭源系统相当——这证明了强化学习可以赋予模型原生的Agent能力。

实验1 - 3★：GPT - 5.6原生深度研究能力¶

第二个实验使用OpenAI GPT - 5.6来展示，在API级内置工具的支持下，先进模型如何在服务器端闭合“搜索 - 阅读 - 分析”的编排循环以进行深度研究。GPT - 5.6有三种变体——Sol（旗舰前沿模型）、Terra（日常工作的平衡模型）和Luna（快速、经济的轻量模型），所有变体都将工具调用决策原生地留给模型，因此客户端不需要自己的编排框架。一个便利的功能是自由格式工具调用。传统上，模型调用工具时必须将每个参数序列化为严格的JSON（一种结构化数据格式），很像用严格格式规则填写表格。自由格式工具调用（通过type: "custom"的工具在API中声明）允许模型直接将原始文本发送给工具（一段Python代码、一个SQL查询），完全避免JSON转义。值得强调的是，这是API参数格式的演进，而非模型架构的创新——客户端的工具调用循环（检测tool_calls→执行→返回结果）保持不变；只是参数从JSON字符串变为原始文本。GPT - 5.6还引入了一个详细程度参数（控制输出细节）和一个推理努力参数（调整推理深度；Sol增加了一个最大级别以实现最彻底的推理时间），让开发者可以根据任务的复杂性调整模型行为。

GPT - 5.6与Responses API的网络搜索和代码解释器内置工具配合，提供了深度研究的核心机制：模型可以自主搜索网络获取实时信息并编写代码进行深入分析，实现“搜索→阅读→分析→再次搜索”的迭代研究过程。例如，面对“东盟10国首都之间的最短距离是多少？”这样的问题时，GPT - 5.6会自动搜索每个首都的地理坐标，然后编写Python代码计算所有首都对之间的大圆距离，最终确定最近的一对。同样，在“搜索比特币过去一个月的趋势并进行技术分析”这样的任务中，它可以从多个金融数据源获取实时价格数据，使用专业的技术分析库计算移动平均线、相对强弱指数（RSI）、指数平滑异同移动平均线（MACD）等技术指标，生成可视化图表并提供交易建议。

更重要的是，GPT - 5.6在模型层面内化了OpenAI深度研究产品的设计理念，引入了意图澄清过程。给定一个研究请求，GPT - 5.6不会立即开始执行；它首先通过一系列问题澄清用户的真实意图。对于“搜索比特币过去一个月的趋势并进行技术分析”，它会首先问：“您偏好哪个数据源？您希望分析哪些技术指标？”这种交互式澄清让GPT - 5.6能够生成更精确且更符合用户实际需求的研究报告。

GPT - 5.6是“模型即Agent”的成熟示例——Responses API的网络搜索、代码解释器等内置工具在服务器端闭环执行；编排循环从客户端转移到了API服务器，简化了客户端实现。模型仍然发出标准的工具调用；客户端只是不再需要自己构建“搜索 - 阅读 - 分析”的编排框架。它最值得注意的方面是意图澄清机制：模型不是立即执行任务，而是首先确认用户真正需要什么，然后制定研究策略。在执行开始之前就解决了“用户所说的”和“用户实际想要的”之间的差距。

图1 - 4展示了“模型即Agent”范式下原生工具调用的完整架构，以及Kimi K3和GPT - 5.6在实际任务中的ReAct执行过程。

Figure 1 - 4: "Model as Agent" Architecture—Native Tool Calling

框架工程：超越模型的竞争力¶

到目前为止，你已经了解了Agent的核心工作原理：大语言模型在上下文的引导下运行ReAct循环，使用工具完成任务。上面的实验表明基本机制是有效的——但也暴露了它的脆弱性。模型可能会幻觉（发明不存在的工具或参数）、选错工具或无法从错误中恢复。从一个可行的演示到可靠的产品存在相当大的差距，而这些脆弱性正是框架工程要解决的问题。本章前半部分回答了Agent是什么；后半部分回答了Agent如何在生产环境中可靠运行。

前面的部分确立了核心公式：Agent = 大语言模型 + 上下文 + 工具。它描述了Agent的内部组成：推理引擎、工作上下文和行动接口。框架工程为同一系统添加了第二个实现层面的视角：将大语言模型视为一个核心组件（模型），将围绕它构建的所有支持代码称为框架。这两个视角不是竞争关系；它们在不同的抽象层次上描述同一个系统。我们切换到更通用的词“模型”，因为框架工程的原理适用于任何能够推理和调用工具的模型，而不仅仅是特定种类的模型。框架的核心是原始公式中的“上下文 + 工具”，再加上三层防护：约束（Agent可以做和不可以做的事情）、验证（是否正确完成了事情）和纠正（出错时如何恢复）。

展开为一个等式，完整的生产级组成是：

Agent = 大语言模型 + [上下文 + 工具 + 约束 + 验证 + 纠正] = 模型 + 框架

一个最小的可用Agent仅依靠大语言模型、上下文和工具运行。要在长时间的生产工作负载中可靠运行，它还需要三层外部工程层——约束以防止过度扩展，验证以捕获错误，纠正以从失败中恢复。这些层不是事后添加的独立模块；它们是围绕“上下文 + 工具”的防护措施。换句话说：最小公式是演示视角，扩展公式是生产视角——后者完全包含前者并在其周围添加了安全网。

一个例子可以明确边界：将退款政策嵌入上下文中属于上下文，而检查退款金额不超过订单总额属于约束。执行API调用属于工具，而在API超时后自动重试属于纠正。模型提供底层的理解和推理；框架引导、约束并放大这些能力以实现可靠的任务执行。在模型之外设计和优化这种基础设施的工程实践就是框架工程。

人工智能代理入门 [第6/9部分]¶

一个具体的例子展示了框架的价值。假设你让一个代理退还用户3天前下的订单。没有框架：模型没有收到退款政策（没有上下文），不知道调用哪个API（没有工具），为用户编造退款结果（没有验证），用户发现退款从未发生（没有纠正）。有框架：系统提示指定了7天退款政策（上下文），代理调用query_order和process_refund工具执行操作（工具），框架检查退款不超过订单总额（约束），根据数据库确认退款已完成（验证），如果API调用超时自动重试（纠正）。同样的模型，结果大不相同。

简而言之，没有框架的模型可能功能强大，但缺乏可靠完成任务所需的周围控制。

更准确地说，模型之外的所有基础设施都属于框架。框架的核心是上下文和工具，围绕它们构建了三种工程保障：

功能	一句话职责	与上下文/工具的关系
上下文	为模型提供相关信息	核心能力
工具	为模型提供行动接口	核心能力
约束	设置行为边界——能做和不能做的事	围绕上下文和工具构建的安全边界
验证	自动判断工具执行结果的正确性	围绕工具执行结果构建的检查机制
纠正	发现问题时自动恢复或回滚	围绕工具调用失败构建的恢复机制

上下文和工具让代理完成任务——理解任务并采取行动。约束、验证和纠正确保其可靠且安全地完成任务——不是与上下文和工具分离的东西，而是确保它们在生产中可靠运行的工程。随着代理产品的成熟曲线，这两组之间的重点发生转移。

早期的代理框架侧重于上下文和工具：给模型工具，给它上下文，让它完成任务。生产级系统已将重心转移到约束、验证和纠正上：确保工具调用安全、上下文得到管理、错误可恢复。

以Claude Code为例。它的框架代码绝大多数都在进行约束、验证和纠正，而不是上下文和工具——工具本身（文件读写、命令执行、搜索）只是很小的一部分；围绕它们构建的保障措施才是真正的核心。这些机制包括：

进程状态管理：跟踪代理当前执行的步骤
多层上下文压缩：信息过多时自动修剪
权限分类：控制哪些操作需要用户确认
断路器：重复错误后自动停止重试，防止一个失败操作波及整个系统
错误恢复机制：捕获异常，回滚到最后稳定状态，重试或移交人工处理

行业正在从完成任务转向可靠完成任务，这使得框架工程成为代理系统的核心竞争优势。

从提示工程到循环工程：工程范式的演变¶

回顾人工智能应用工程的发展，出现了一条清晰的演进弧线：

软件工程是基础——传统的系统设计、架构、测试和部署。提示工程是第一波创新——通过完善喂给模型的自然语言指令来提高输出质量。上下文工程是第二波——意识到仅优化提示词是不够的：必须系统地管理模型的工作上下文（系统指令、工具定义、对话历史、外部知识）。框架工程是第三波——将视角从“模型接收什么信息”拓宽到“模型运行在什么样的系统中”，纳入模型之外的所有基础设施：约束机制、验证方法、反馈循环、错误恢复。接下来是循环工程，将视角从单次运行拓宽到跨运行的持续自主操作：谁发现下一个工作，何时验证，何时任务才算真正完成（第10章与多代理协作系统一起展开）。

2026年7月，行业开始使用图工程从更高层次的编排视角：将代理循环、确定性程序和人工审批组织成显式的执行图，其中节点提供能力，边定义路由和依赖关系，结构化状态沿边传递并在关键边界持久化。⁵ 图工程不是循环工程的替代品，也不应简单地视为上述演进中的“第六层”。循环本身就是带有回边的图，图中的节点仍可以内部运行ReAct或其他代理循环。名称尚未稳定，所以本书将其视为现有编排和框架实践的新兴术语；第10章展开多代理部分。这里的“图”指控制流或执行图，不是GraphRAG使用的知识图。

这五个阶段不是替代品而是嵌套的层次：提示工程是上下文工程的子集，上下文工程是框架工程的子集，框架工程是循环工程的子集。每一层都扩大了工程师的关注范围和影响力。随着模型在能力上趋于一致，不再是决定性的差异化因素，竞争优势转移到模型之外的工程上。 最近的工程实践支持这一观点。LangChain在Terminal Bench 2.0（评估代理在终端环境中完成复杂任务能力的基准）上的工作就是一个显著的例子：他们的编码代理从52.8%提高到66.5%（从排行榜前30名之外跃升至前5名）。改变的不是模型，而是框架——让代理检查自己的执行结果，检测何时陷入重复循环，并完善其推理策略。OpenAI的工程团队也分享了类似的经验：3名工程师在5个月内完成了大约100万行代码和近1500个拉取请求，约为传统开发速度的10倍。主要驱动力不是更强的模型；而是正确构建了框架。

框架五个功能的核心原则¶

前面的表格列出了框架的五个功能。下面的表格添加了每个功能的核心设计原则以及本书对其的处理方式，将概念映射到实践：

功能	核心原则	实践示例	参见章节
上下文	信息充分性：确保代理在每个决策点都基于充分的信息做出决策	系统提示、知识库、代理状态栏、辅助程序绕过查询	第2章和第3章
工具	清晰接口：工具名称直观，参数有示例，边界有说明	MCP工具、代码解释器、搜索工具	第4章
约束	故障安全默认值：所有能力默认关闭，必须明确启用（类似于移动应用权限管理）	在Claude Code中，每个工具默认在执行前需要用户授权	第4章
验证	输入隔离：安全检查只看结构化数据（例如工具返回的JSON字段），不看模型生成的自由文本（因为攻击者可能通过提示注入操纵模型输出）	代码检查器、类型系统、工具调用结果验证	第5章和第6章
纠正	在确认故障不可恢复之前不暴露中间状态（例如静默重试失败的工具调用，而不是向用户显示半完成的结果）	静默重试、续生生成、连续失败时移交人工判断（断路器机制）	第2章和第5章

五个功能形成一个闭环：上下文和工具支持决策，约束防止错误，验证检测偏差，纠正闭合循环。如果任何环节缺失，系统就会出现可靠性缺口。在研究具体的编排模式和护栏设计之前，我们首先列出构建有效代理和选择模型的核心原则——这是后续所有设计决策的基础。

构建有效代理的核心原则¶

基于Anthropic的经验，成功的代理系统遵循三个核心原则。

入门指南：AI 代理（第 7/9 部分）¶

保持简单。从最简单的解决方案开始，仅在真正必要时增加复杂性。直接的 API 调用比复杂的框架更可取；清晰的代码比巧妙的抽象更可取——每一层额外的抽象在调试时都是新的盲点。

保持透明。清晰展示代理的规划步骤、执行日志和决策轨迹。这不仅是调试的便利；也是用户信任的前提——黑盒内的错误很难从外部定位或修复。

设计结构良好的工具接口（ACI，代理-计算机接口）。ACI 是从代理的角度设计接口——让代理易于理解和使用——而不是像传统 API 那样从程序员的角度设计。工具名称和参数应直观，并且在可能出现误用的地方，设计应从一开始就避免错误：SIM 卡的缺口角使其只能以一种方向滑入托盘中，微波炉门打开时无法加热。制造业将此称为“消除错误”理念 防错法（Poka-yoke），这是丰田生产系统中的一个术语。设计不佳的工具甚至会导致最强的模型反复失败：接口是模型和工具之间的唯一通道，模糊的接口会被放大为系统性错误。

接下来的三个部分讨论了框架工程中三个独立但重要的主题：模型选择、编排模式以及防护措施和安全性。这些都不属于框架的五个适当元素，但在工程实践中都是不可避免的。

如何选择模型¶

在讨论编排模式之前，我们首先需要回答一个实际问题：什么样的模型应该驱动你的代理？

模型是代理智能的基础，选择合适的模型往往比任何数量的提示调整都重要。模型发布更新太快，特定版本的推荐很难保持有用，所以本节提供方向而非具体推荐。

了解“三大巨头”。当前代理开发中最常用的三个闭源模型提供商是 OpenAI（GPT/o 系列）、Anthropic（Claude 系列）和 Google（Gemini 系列）。每个都有其优势：Claude 在复杂推理、编码和工具调用方面表现出色，是代理开发的热门选择；Gemini 提供超长上下文窗口和强大的多模态能力，适合长文本和图像、视频等多媒体场景；GPT/o 系列能力均衡且用户基数最大。选择模型时，不要仅依赖排行榜；在自己的任务上进行评估（见第 6 章）。

中文模型。如果你的应用部署在中国或预算有限，中国供应商的模型是务实之选。字节跳动的豆包系列在中国内延迟极低，适合实时交互；摩斯智算的 Kimi 在代理能力方面是较强的中文模型之一；通义千问、深度求索等开源模型在成本和可定制性方面有优势。请注意，模型在工具调用能力上差异很大，所以在投入使用前一定要在具体场景中测试。中文模型通常通过火山引擎（豆包）、硅基智能（开源模型）等平台的 API 访问，而非中文模型可以通过 OpenRouter 等聚合服务访问。

开源与闭源。闭源模型通常能力领先，但成本更高且受供应商 API 政策限制。开源模型成本低，支持私有部署，允许微调定制，适合成本敏感场景或有数据合规要求的场景。

大多数代理需要支持推理的模型。代理要做出复杂决策——多步推理、工具选择等，没有推理能力的模型在这些方面往往表现不佳。例外情况很少：单一简单步骤，或相当于点击固定位置的计算机使用 GUI 操作，此时非推理模型可能够用。一旦涉及多步推理或动态决策，推理模型就至关重要。

考虑输出速度和多模态能力。除了成本，还有两个容易忽视的维度。一是输出词元速度：代理通常要运行多轮推理，每一轮必须在前一轮完成后才能开始，所以输出速度直接决定端到端时延——一个 20 轮的代理任务，每轮慢 2 秒，就会多等 40 秒。二是多模态支持：如果你的代理需要理解图像、音频或视频，多模态能力是硬性要求，而模型在这方面差异很大。

编排模式：工作流与自主式¶

编排模式是框架组织其“上下文和工具”层的方式——它们决定上下文在大语言模型调用之间如何流动，工具如何调度，以及代理的执行路径是预先固定还是动态生成。代理编排从简单到复杂不断演变，每种模式都有合适的用例和权衡。根据 Anthropic 与数十个构建大语言模型代理的团队合作经验，最成功的实现很少使用复杂框架；它们使用简单、可组合的模式。

构建大语言模型应用时，要从简单到复杂推进。从单个大语言模型调用开始——如果更好的提示和上下文示例能解决问题，就不要构建代理系统。当需要多个步骤且任务能清晰分解为固定子任务时，使用工作流。只有当需要动态决策和灵活执行路径时，才使用自主式代理。并且记住：代理系统通常以时延和成本换取更好的任务性能——要仔细评估这种交换是否值得。

工作流模式：确定性编排¶

工作流是通过预定义代码路径编排大语言模型和工具的系统。其执行路径是确定性的，由开发者预先设计——每个步骤和转换的行为都在代码中定义；大语言模型仅处理每个节点内的理解和生成。

例如，一个航班预订代理可以使用包含四个固定节点的工作流：

验证用户身份——调用身份验证 API 确认用户身份。
搜索可用航班——根据用户需求查询航班数据库。
完成支付——调用支付接口扣款。
确认预订——调用预订 API 锁定座位并向用户发送确认。

每个节点内都可以使用大语言模型（例如用自然语言理解用户的出行需求），但节点之间的流程顺序由代码固定——系统不会在支付完成前预订座位，也不会在身份验证前开始搜索航班。

工作流模式有两个核心优势。首先，严格的流程控制：开发者可以保证关键步骤绝不会被跳过或顺序错误——“支付前不预订”等业务规则由代码强制执行，而不是交由大语言模型判断。其次，安全性：因为执行路径是确定性的，提示注入或模型错误最多影响当前节点内的处理；不会让代理跳转到不应到达的分支。攻击面局限在单个节点内。

工作流的主要局限是缺乏灵活性。当出现意外事件时——例如用户在支付时更改预订，或航班取消系统需要推荐替代方案——固定路径无法自行适应；只能遵循预设的异常分支或将控制权交回给人类。

自主式代理：运行时决策¶

当工作流的固定路径不足时，我们需要自主式代理。自主式代理与工作流的核心区别在于，执行路径不是预先定义的，而是由代理在运行时根据环境反馈确定的。

回到航班示例，自主式代理不需要四个预定义节点。用户说“给我订下周三去上海的航班”，代理动态确定顺序：搜索航班，发现需要登录，验证身份，然后继续搜索。如果最便宜的航班有经停，它可以询问是否可以接受；如果用户说不行，它就调整搜索标准。

因此，自主式代理必须自己规划——选择自己的执行步骤——并识别失败并改变策略，而不是简单地在错误时停止。但自主性不是无边界的：必须设计明确的停止条件（任务完成、达到最大迭代次数、遇到不可恢复错误），否则代理可能进入无限循环或在任务已完成后继续执行。

从实现角度看，自主式代理本质上是在循环中使用工具的大语言模型，不断获取环境反馈以推进任务——这就是前面介绍的 ReAct 循环。常见的退出条件包括：调用最终输出工具、模型返回没有任何工具调用的响应，或遇到错误或达到最大轮次。

图 1-5：自主式代理的执行循环

与人工智能代理入门 [第8/9部分]¶

自主代理非常适合解决开放式问题——那些难以或不可能预测所需步骤数量的问题。典型用例包括：解决SWE-bench（软件工程基准，用于评估代理自动修复真实GitHub问题能力的基准）任务的编码代理、像人类一样操作计算机界面的“计算机使用”代理，以及需要迭代搜索和分析的研究任务。

自主性成本也更高，且会让错误累积。因此，部署自主代理需要在沙盒中进行彻底测试、设置适当的防护措施和监控，并在关键决策点设置人工参与的检查点。

选择和混合两种模式¶

实际上，工作流和自主代理并非相互排斥——许多系统混合了两者：具有严格合规要求的关键流程作为工作流运行以确保可靠性，而需要灵活决策的部分则切换到自主模式。例如，n8n是一个成熟的开源工作流自动化框架，开发人员通过在可视化画布上排列功能组件来构建代理——工作流节点和自主代理节点可以在同一系统中共存。

图1-6：n8n工作流编辑器界面

主流代理框架简要比较¶

下表总结了广泛使用的代理框架和平台，以帮助读者为自己的场景找到合适的框架：

框架聚焦点	对应章节	核心内容	安全关注点
上下文设计	第2章（上下文工程）	提示工程、代理状态栏、上下文压缩、代理技能	提示注入和信息泄露
上下文扩展（知识持久化）	第3章（知识库）	用户内存、RAG、结构化索引、代理式RAG	敏感信息暴露、隐私保护
工具设计和安全约束	第4章（工具设计）	工具分类、权限控制、MCP标准、异步架构	误操作、未经授权访问、不可逆转操作
工具验证和纠正	第5章（代码生成）	编码代理框架、测试驱动开发、编码编码的规则	身份冒充、责任归属
系统级验证	第6章（评估）	评估环境、数据集、自动化评估、可观测性	—
模型级纠正	第7章（训练后）	SFT（监督微调）、强化学习——将框架中积累的反馈信号写入模型参数，可视为框架工程的扩展	目标偏离、对齐和鲁棒性
经验驱动的持续纠正	第8章（持续演进）	轨迹学习信号；知识/指令/程序/参数更新；自我修改；验证和回滚	内存中毒、不安全的自我修改、能力漂移
多模态上下文和工具	第9章（多模态和实时交互）	语音代理、计算机使用、机器人操作	多模态输入的安全过滤、实时交互中的权限控制
多个代理之间的约束和纠正	第10章（多代理协作）	协作架构、失败模式、代理社会	代理之间的信任边界违规、共享资源冲突

随着“模型即代理”趋势的深化，框架的核心价值不再在于“编排大语言模型调用”——模型越来越多地自行决策。变得更重要的是围绕模型的框架工程：上下文管理、工具生态系统、安全约束、错误恢复。选择框架时，问题不在于框架有多复杂，而在于它是否能让你通过尽可能薄的抽象层专注于业务逻辑。

编排模式解决框架内上下文和工具的组织问题——大语言模型调用、工具和数据流如何连接。但仅完成任务是不够的；任务还必须正确且安全地完成。因此，我们转向实践中实施约束、验证和纠正的主要方式：防护措施。

防护措施和安全性¶

本节从高层级概述防护措施以建立整体图景。实现细节和实践将在第2章（提示注入防护）、第4章（工具权限控制）和第5章（代码执行安全）中介绍；首次阅读的读者无需关注每个细节。

防护措施是框架中“约束、验证和纠正”层的主要实现方式——一种分层防御，使代理行为安全可控。设计良好的防护措施有助于管理数据隐私风险（例如，防止系统提示泄露）和声誉风险（例如，保持模型行为与品牌一致）。从已识别的风险的防护措施开始，然后在新漏洞出现时添加新的防护措施。

将防护措施视为深度防御。单个防护措施本身不太可能足够，但几个专门的防护措施结合起来会形成更具弹性的代理系统。

防护措施的类型¶

根据防护措施在执行流程中的位置，可分为输入侧、执行侧和输出侧三种类型。

输入侧防护措施在请求到达代理之前拦截请求，通常通过四种机制。相关性分类器标记离题查询——例如，编码助手被问到“帝国大厦有多高？”。安全分类器检测越狱（诱导模型绕过其安全限制）和提示注入（在输入中嵌入恶意指令）。关键区别在于：在越狱中，用户试图直接绕过模型的限制；在提示注入中，攻击者通过外部数据（网络内容、文档）间接操纵模型行为。内容审核标记有害或不适当的输入，例如暴力或歧视性内容。基于规则的防护针对已知威胁（如SQL注入）应用确定性措施——黑名单、输入长度限制、正则表达式过滤。

执行侧防护措施验证工具调用。核心是工具风险评级：根据操作是否可逆、其权限级别和财务影响，为每个工具分配风险级别（低/中/高）。高风险操作需要额外审查或人工确认。

输出侧防护措施在响应返回给用户之前检查响应。PII过滤器检查输出中的个人身份信息（例如，身份证号码、电话号码）以防止不必要的暴露；输出验证通过内容检查确保回复符合品牌价值。

请注意，一些机制（例如，基于规则的正则表达式过滤）可以在输入侧和输出侧使用；上述分类遵循最常见的部署位置。

基于分类器的防护措施的一个代表性行业实践是Anthropic的宪法分类器⁶。其设计有三个关键要素。首先，规则驱动训练：用自然语言编写的“宪法”——明确规定允许和不允许的内容——用于为输入和输出分类器生成合成训练数据。其次，联合上下文判断：新一代同时检查用户的问题和模型的答案，因为有些答案本身看起来完全没问题（例如，“如何使用食品香料”），只有结合问题才能清楚“食品香料”是化学试剂的暗语。第三，两阶段筛选：一个极其轻量级的探测器——几乎不花费成本读取模型的内部激活——首先检查每个对话，任何可疑的内容都会升级到更强大的分类器进行审查，而不是直接拒绝。这样第一阶段可以容忍更多的假阳性而不影响用户体验，整体成本大大降低。

人工干预¶

人工参与干预是关键的保护措施：它让代理在不降低用户体验的情况下提高实际性能。在早期部署中最为重要，此时它有助于识别失败模式、暴露边缘情况并建立稳健的评估周期。

通过人工参与机制，无法完成任务的代理可以优雅地移交控制权。在客户服务中，这意味着升级到人类代表；对于编码代理，这意味着将控制权交还给开发人员。

通常有两种主要情况会触发人工干预：

超过失败阈值 设置代理重试和操作的上限。如果代理超过这些上限（例如，经过几次尝试仍无法推断客户意图），则升级到人类。

高风险操作 敏感、不可逆转或高风险的操作应触发人工监督——至少在团队对代理的可靠性建立足够信心之前。典型示例：取消用户订单、批准大额退款、处理付款。

牢记框架的五个要素，本书其余部分遵循此结构。

本书作为框架工程的实用指南¶

从Harness工程视角看[第9/9部分]AI代理入门¶

从Harness工程的角度来看，本书的每一章都系统地构建了Harness的一个组成部分。与此同时，安全问题并不属于单一章节；它是贯穿整本书的跨领域关注点（跨领域关注点会同时涉及系统的多个部分，就像软件工程中的日志必须贯穿每个模块一样）。下表以单一视图呈现了Harness功能、安全方面及相应章节：

Harness关注点	对应章节	核心内容	安全关注点
上下文设计	第2章（上下文工程）	提示工程、Agent状态栏、上下文压缩、Agent技能	提示注入和信息泄露
上下文扩展（知识持久化）	第3章（知识库）	用户记忆、RAG、结构化索引、代理式RAG	敏感信息暴露、隐私保护
工具设计与安全约束	第4章（工具设计）	工具分类、权限控制、MCP标准、异步架构	误操作、未授权访问、不可逆操作
工具验证与纠正	第5章（代码生成）	编码Agent的Harness、测试驱动开发、编码规则	身份冒充、责任归属
系统级验证	第6章（评估）	评估环境、数据集、自动化评估、可观测性	—
模型级纠正	第7章（训练后）	SFT（监督微调）、强化学习——将Harness积累的反馈信号编码到模型参数中，作为Harness工程的扩展	目标不一致、对齐性和鲁棒性
系统级纠正	第8章（自我进化）	外部化学习、工具创建、经验积累	—
多模态上下文与工具	第9章（多模态与实时交互）	语音Agent、计算机使用、机器人操作	多模态输入的安全过滤、实时交互中的权限控制
多Agent之间的约束与纠正	第10章（多Agent协作）	协作架构、失败模式、Agent社会	Agent之间的信任边界违规、共享资源冲突

Anthropic在构建长期运行的Agent时的实践展示了Harness设计如何解决模型自身无法解决的问题。他们在“初始化Agent”（设置环境、分解任务列表）和“执行Agent”（每次会话逐步推进并留下清晰的交接工件）之间分配复杂任务，使用结构化的Harness来应对长任务的两种失败模式：上下文耗尽和过早宣告任务完成。接下来的章节将逐个介绍Harness组件——第2章从最核心的部分开始，即上下文工程，第5章阐述了编码Agent中Harness工程的完整实践。

章节总结¶

本章构建了一个以实践为导向的框架，用于理解和构建AI代理。

Agent = 推理引擎 + 工作上下文 + 行动接口：大语言模型提供推理和决策，上下文提供决策时可用的工作信息集，工具提供行动接口。三者缺一不可。

扩展上下文和工具是主要的能力杠杆：一旦模型固定，重新定义或扩大观察和行动空间——即扩展上下文和工具——通常可以直接将无法解决的任务转化为可解决的任务。从Manus到OpenClaw的演变表明，很多通用性来自于扩展接口边界；这种扩展必须按需进行，并与权限和验证相结合。

上下文是决定性因素：上下文由静态前缀（系统提示 + 工具定义）和动态轨迹（消息历史）组成。消融实验表明，移除任何组件都会显著降低系统性能。ReAct循环的本质是不断向轨迹中追加内容，从而使模型不断推进任务。

Harness是竞争优势：模型能力正在商品化；真正的差异化因素是Harness——围绕上下文和工具构建的约束、验证和纠正机制，能够实现可靠的任务完成。在生产级Agent系统中，绝大多数Harness代码都用于这些保障措施，而不仅仅是上下文和工具。

从工作流到自主Agent：先有提示词，然后是工作流，最后是自主Agent——这种顺序是减少意外行为的最实用方式。每种编排模式都有其适用的情况；没有一种模式在所有地方都是最好的。

安全是架构问题：护栏、人工参与、对齐（使模型行为与人类意图保持一致）——安全必须从代码的第一行开始设计，而不是在发布前修补。它涵盖五个层面：模型、上下文、工具、协作和社会。

下一章将深入探讨Harness最核心的组件：上下文工程。第7章将介绍Agent概念在强化学习中的学术根源，并比较传统RL与现代LLM Agent。

以下是针对本章核心概念进一步深入的思考问题。

思考问题¶

★★ 如果只能给Agent系统添加一种能力——更强的模型、更丰富的上下文或更多工具，你会选择哪一种？在什么条件下你的选择会改变？
★★★ 在ReAct循环中，Agent的每次大语言模型调用都会接收完整的历史轨迹，因此随着轨迹增长，这种设计的成本呈二次方增长。能否在不丢失关键信息的情况下打破这种二次方增长？
★★ “模型即Agent”范式意味着模型在工具调用决策上变得更加自主。然而，本章认为Harness工程的重要性实际上在增加。这两种趋势如何共存？Agent框架的未来核心价值在哪里？
★★ 在消融实验中，缺少“工具结果反馈”导致Agent陷入无限循环。在生产环境中，除了缺少工具结果，还有哪些情况可能导致Agent循环？你会设计哪些检测和终止机制？
★ 本章从工作上下文、行动接口和策略三个维度分析了五种Agent产品。选择一个你日常使用的AI产品，从相同的三个维度进行分析，并判断其架构是否合适。如果由你设计，你会如何改进？
★★ 如果你要专门设计一个用于预订航班的客户服务系统，你会选择工作流模式还是自主Agent模式？是否可能在同一系统中混合使用这两种模式？
★★★ 护栏部分提到了工具风险评级。如果一个工具通常风险较低，但在特定参数组合下变得风险较高（例如delete_file删除普通文件与删除系统文件），你会如何设计动态风险评估？
★★ 在本章的Agent产品表中，所有Agent都有“开放式”行动空间。在什么场景下，受限行动空间（例如只能从预定义选项中选择）比开放式行动空间更优？
★★ 人工参与干预机制要求Agent“优雅地移交控制权”。然而，在实践中，用户可能离线、响应缓慢或给出模糊指示。这种情况下Agent应该怎么做？
★★★ 引言中提到“好的设计原则应该超越模型迭代周期”。给出一个你认为随着模型改进可能过时的当前Agent设计原则，并解释原因。

约翰·L·亨尼西和大卫·A·帕特森，《计算机体系结构：一种定量方法》，第6版，摩根·考夫曼出版社，2019年，第1章“什么是计算机体系结构？”。该书区分了指令集体系结构、计算机组织和硬件；指令集体系结构专门是软件和硬件之间的接口。见https://shop.elsevier.com/books/computer-architecture/hennessy/978-0-12-811905-1 ↩
Manus的官方资料描述其原始沙盒是一个孤立的云虚拟机。在介绍其谷歌云端硬盘连接器时，Manus明确回忆了早期在云端硬盘、桌面和Manus之间手动下载和上传文件的分散工作流程。当它在2026年3月推出“我的电脑”时，它将重要工作主要存在本地而不是云端称为云沙盒的一个基本限制。OpenClaw的官方README描述了一个在用户自己设备上运行的本地优先、始终在线的个人助手，并列出了二十多个消息通道；其工具和插件系统可以添加云集成和本地功能。见https://manus.im/blog/manus-sandbox，https://manus.im/blog/manus-google-drive-connector，https://manus.im/blog/manus-my-computer-desktop，https://github.com/openclaw/openclaw，以及https://docs.openclaw.ai/tools ↩
Sutton, Rich. “The Bitter Lesson”, 2019. http://www.incompleteideas.net/IncIdeas/BitterLesson.html ↩
感谢读者asdlem通过GitHub Issue #30指出并澄清了这一点，即强化学习内化的是工具调用的决策策略，而非工具执行机制。详见https://github.com/bojieli/ai-agent-book/issues/30 ↩
Josh C. Simmons在2026年7月4日的文章《我们正在进入图工程阶段》中明确使用了这个名称，从节点、类型化边和检查点状态的角度进行了总结。7月18日，Peter Steinberger关于讨论是否从循环转向图的问题进一步推动了该名称的传播。这些实践早于该标签：LangGraph、微软代理框架和谷歌ADK的官方文档将它们描述为图编排或基于图的工作流。参见https://www.drjoshcsimmons.com/writing/we-are-entering-the-graph-engineering-phase，https://x.com/steipete/status/2078277297791189132，https://docs.langchain.com/oss/python/langgraph/overview，https://learn.microsoft.com/en-us/agent-framework/workflows/，以及https://adk.dev/workflows/。 ↩
Anthropic. “下一代宪法分类器：更高效地抵御通用越狱”, 2026. https://www.anthropic.com/research/next-generation-constitutional-classifiers; 论文：Cunningham等人，“宪法分类器++：高效的生产级抵御通用越狱的防御”, arXiv:2601.04603 ↩