Chapter1 zh

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

人工智能代理入门¶

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

工具：代理的行动接口¶

工具是代理与外部世界的桥梁。它们将代理从被动的观察者转变为能够搜索、写入文件、运行代码、调用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）是代理的决策核心。给定用户请求，它首先必须推断真实意图（用户所说的往往不是他们真正想要的），然后将模糊或复杂的任务分解为可执行步骤。在整个执行过程中，它不断做出决策：下一步做什么、是否调用工具、调用哪个工具以及使用什么参数。这种理解-规划-执行能力来自预训练期间积累的知识，是工作流和自主代理都依赖的基础。

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

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

这种结构化推理让大语言模型代理能够处理完全新的任务而无需先前示例——零样本和少样本这两个概念说明了这一点。直接体现是零样本泛化：面对从未见过的任务，代理通过重组已有的知识来处理它，不需要示例。模型可能从未被明确教过写关于量子物理的诗，但它可以根据已有的语言和物理知识生成合理的诗。

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

模型即代理：当模型本身成为产品¶

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

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

但随之而来的是一个更深入的问题：如果模型不断变强，今天的框架最终会被模型吸收吗？在《苦涩的教训》中，里奇·萨顿回顾了人工智能研究七十年中反复出现的模式³：研究者反复将对领域的理解编码到系统中，实现短期收益，但最终输给了随计算和数据扩展的通用方法——搜索和学习。从这个角度看，框架中的多少约束、验证和纠正属于“人类先验”，是模型注定要内化的？本书的立场可以用八个汉字总结：认可方向，务实节奏。从方向上看，我们不怀疑模型会继续吸收框架的部分内容——工具调用和长视距规划曾经依赖外部编排，但现在是模型的本地能力。然而在实践中，这种吸收比直觉慢得多：训练需要数月时间尺度，没有模型能在一次训练中内化所有真实业务的约束和偏好。模型当前的能力边界正是框架创造价值的地方。因此，框架工程不是对抗苦涩的教训，而是在工程时间尺度上的实践：模型还不能可靠完成的事情，框架先覆盖；每当模型内化另一层，框架就舍弃该层，转向支持下一个能力前沿。这条主线贯穿全书——第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循环是将大语言模型、上下文和工具连接成一个系统的核心机制。我们可以逐步审视它。

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

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

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

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

trajectory = [
  {role: "user", content: "Based on the company's quarterly revenue: Q1 2.5M USD, Q2 2.1M EUR, Q3 1.8M GBP, Q4 380M JPY, calculate the company's total annual revenue and average quarterly revenue"},

  # 第一次迭代 - LLM接收上述轨迹并生成响应
  {role: "assistant",
   reasoning: "Need to convert all currencies to USD...",
   content: "",  # 没有直接回复用户
   tool_calls: [
     {name: "convert_currency", args: {amount: 2100000, from: "EUR", to: "USD"}},
     {name: "convert_currency", args: {amount: 1800000, from: "GBP", to: "USD"}},
     {name: "convert_currency", args: {amount: 380000000, from: "JPY", to: "USD"}}
   ]},

  # 代理框架执行工具，将结果添加到轨迹中
  {role: "tool", content: "EUR->USD: 2282608.7"},
  {role: "tool", content: "GBP->USD: 2278481.01"},
  {role: "tool", content: "JPY->USD: 2541806.02"},

  # 第二次迭代 - LLM接收包含工具结果的完整轨迹
  {role: "assistant",
   reasoning: "Conversion results obtained, now need to aggregate and calculate...",
   content: "",
   tool_calls: [
     {name: "code_interpreter", args: {code: "total = 2500000 + 2282608.7 + ..."}}
   ]},

  {role: "tool", content: "Total: $9,602,895.73, Average: $2,400,723.93..."},

  # 第三次迭代 - LLM接收完整轨迹并生成最终答案
  {role: "assistant",
   reasoning: "All calculations complete, summarizing results...",
   content: "FINAL ANSWER: Total revenue $9,602,895.73..."}
]

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

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

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

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

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

实验1-2 ★：Kimi K3的本地代理能力¶

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

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

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

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

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

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

图1-4：“模型即代理”架构——本地工具调用

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

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

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

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

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

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

一个例子可以阐明边界：将退款政策嵌入上下文中属于上下文，而检查退款金额不超过订单总额属于约束。执行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个PR，约是传统开发速度的10倍。主要驱动力不是更强的模型；而是把框架搞对了。

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

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

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

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

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

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

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

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

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

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

接下来的三个部分讨论框架工程中三个独立但重要的主题：模型选择、编排模式以及护栏和安全。它们不属于五个框架要素本身，但在工程实践中都不可避免。

如何选择模型¶

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

自主代理：运行时决策¶

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

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

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

从实现角度看，自主代理本质上是在循环中使用工具的LLM，不断获取环境反馈以推进任务——这就是前面介绍的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章（多代理协作）	协作架构、失败模式、代理社会	代理之间的信任边界违反、共享资源冲突

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

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

护栏和安全¶

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

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

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

护栏的类型¶

根据它们在执行流程中的位置，护栏分为三种类型：输入侧、执行侧和输出侧。

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

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

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

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

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

人工干预¶

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

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

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

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

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

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

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

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

从框架工程的角度看，本书的每一章系统地构建了框架的一个组件。与此同时，安全不属于任何单一章节；它是贯穿全书的横切关注点（横切关注点同时触及系统的多个部分——在软件工程中，日志记录必须贯穿每个模块的方式）。下表以单一视图呈现了框架功能、安全方面及对应的章节：

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

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

章节总结¶

本章构建了一个以实践为导向的理解和构建人工智能代理的框架。

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

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

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

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

从工作流到自主代理：先提示，然后工作流，最后自主代理——这个顺序是减少意外行为的最实用方式。每种编排模式都有适用场景；没有一种模式在所有地方都最佳。

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

下一章将深入探讨框架中最核心的组件：上下文工程。第7章涵盖代理概念在强化学习中的学术根源，并比较传统强化学习与现代大语言模型代理。

以下思考问题旨在将本章核心概念进一步深化。

思考问题¶

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

约翰·L·亨尼西和大卫·A·帕特森，《计算机体系结构：一种定量方法》，第6版，摩根·考夫曼出版社，2019年，第1章“什么是计算机体系结构？”。该书区分了指令集体系结构、计算机组织和硬件；指令集体系结构专门是软件和硬件之间的接口。见https://shop.elsevier.com/books/computer-architecture/hennessy/978-0-12-811905-1 ↩
Manus的官方材料描述其原始沙盒是一个孤立的云虚拟机。在介绍其谷歌云端硬盘连接器时，Manus明确回忆了早期在云端硬盘、桌面和Manus之间手动下载和上传文件的分散工作流程。当它在2026年3月推出My Computer时，它称重要工作本地存在而不是在云端是云沙盒的一个基本限制。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问题#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. "Next-generation Constitutional Classifiers: More efficient protection against universal jailbreaks", 2026. https://www.anthropic.com/research/next-generation-constitutional-classifiers; paper: Cunningham et al., "Constitutional Classifiers++: Efficient Production-Grade Defenses against Universal Jailbreaks", arXiv:2601.04603 ↩