AI 智能体的崛起

本章内容

• 定义Agent（智能体）与Agentic Thinking（智能体思维）
• 介绍Model Context Protocol（MCP，模型上下文协议）
• 理解AI Agent的基础架构层
• 迈向多智能体系统

单靠基于大语言模型的应用（例如简单的聊天机器人），只能生成回复并回答问题。而我们希望它们能够更进一步——不仅能够制定计划，还能够执行计划。我们希望它们不仅仅列出可选航班，而且能够直接完成机票预订；不仅仅告诉我们项目中有哪些内容需要修改，而且能够实际更新项目跟踪器。

为了赋予 AI 应用主动执行任务的能力，我们需要在系统中引入AI 智能体。

智能体并不是机器学习和人工智能领域的新概念，而且这一术语本身也存在一定的歧义。不过，当我们讨论智能体或AI 智能体时，通常指的是一种软件系统：它能够感知所处环境，利用大语言模型提供的能力和资源，自主决定下一步应采取的行动，并执行相应操作，以实现既定目标。

本书围绕AI 智能体的构建与应用展开，旨在帮助读者扩展基于大语言模型的系统能力。我们将深入探讨智能体的工作原理、其强大能力的来源，以及如何构建能够自动完成复杂任务的智能体。

本书将从一个简单的单智能体开始，逐步扩展到更复杂的智能体系统，包括 Agent Flow（智能体流程）、**Orchestration（编排）和Collaboration（协作）**等架构模式。这些模式极大地提升了智能体的推理能力和任务执行能力，使其能够处理单个智能体难以胜任的复杂问题。

你将学习如何利用 OpenAI Agents SDK、Model Context Protocol（MCP）等现代框架构建和连接智能体，并将它们与数据库、API、知识库以及完整的应用程序集成，构建具备真实业务能力的智能体系统。

本书的目标，是帮助你从一名只会编写提示词的探索者，成长为能够设计和构建智能体系统的智能体架构师。通过掌握书中的设计模式、实践代码和工程思维模型，你将能够构建真正能够在生产环境中创造价值的智能体系统。

本书重点关注智能体和智能体系统的架构设计与开发实践。我们采用简洁而富有启发性的示例，而非冗长的生产级代码，帮助读者在学习过程中始终能够清晰理解每一步的实现机制，而不会被大量工程细节所淹没。

在本书后半部分，我们还将介绍当前最先进 AI 系统所采用的生产级架构。不过，《AI Agents in Action》并不是一本关于生产环境运维的实践手册。虽然书中会涉及生产环境中的一些重要议题，例如安全、合规等，但并不会全面讲解部署智能体系统时涉及的每一项配置选项、可观测性体系或合规要求。

本书的目标，是帮助你充分理解智能体系统的架构思想和核心构建模块，使你在面对生产环境中的各种工程决策时，能够从容分析并做出合理选择。为此，书中的示例始终保持适度精简，以便将重点放在核心思想和设计理念上，而不是复杂的实现细节。

这段探索之旅不仅关乎技术本身，更关乎我们如何重新思考解决问题的方式。我希望本书能够启发你，将智能体视为创新过程中的合作伙伴，借助它们将创意转化为行动，并以过去难以想象的方式解决实际问题。

接下来，让我们首先明确本书所说的智能体究竟指什么，以及AI 智能体为人工智能带来了哪些新的能力。

1.1 定义 Agent 与 Agentic Thinking

智能体这一概念并非人工智能领域的新事物。在强化学习中，智能体是指能够做出决策，并通过与环境交互不断学习的实体。而在其他语境中，Agent一词的含义则更加宽泛，通常用于指代能够代表用户执行任务的软件。尽管不同领域对智能体的定义有所差异，但其核心思想始终保持一致：智能体能够感知所处环境，决定下一步应该采取什么行动，并通过执行这些行动来实现既定目标。这一定义虽然简洁，却具有足够的包容性，既能够涵盖传统的人工智能系统，也适用于本书将要介绍的基于大语言模型的智能体。

Agentic 一词是在Agent概念基础上的进一步延伸。它用于描述具有能动性的系统或行为，即能够为了实现某个目标，在一定程度上自主地感知环境、做出决策并采取行动。当我们称一个系统具有 Agentic 特性时，强调的是它在运行过程中遵循了这种自主感知、决策和行动的模式，而不仅仅是表面上看起来像一个智能体。从哲学角度来看，对能动性的定义往往更加严格，通常还要求具备意图、适应能力等特征。但对于智能体工程而言，本书采用的这种更加务实的定义已经足以满足工程实践的需要。

将 Agent 与传统 AI 助手进行对比，这一区别就会更加清晰。生成式 AI 助手在接收到用户提示后，会生成相应的回复，随后任务便告结束。而智能体则不同，它会围绕既定目标持续执行多个步骤，并根据执行过程中观察到的环境变化，不断决定下一步应采取的行动。自主性和持续性，正是将一个系统从被动响应的 AI 助手转变为主动执行任务的智能体的关键特征。随着现代 AI 系统越来越多地集成工具调用和多步骤工作流，例如 OpenAI、Google 和 Anthropic 等厂商推出的 Deep Research 等功能，AI 助手与智能体之间的界限也开始变得越来越模糊。因此，理解二者背后的核心设计模式显得尤为重要。

虽然本书重点讨论的是基于大语言模型的智能体，但智能体的设计理念其实有着悠久的发展历史。基于规则的系统、符号推理、信念—愿望—意图（Belief–Desire–Intention，BDI）架构、强化学习智能体以及神经符号方法等，都为智能体系统的设计提供了许多值得借鉴的模式，每种方法也都适用于不同类型的问题。真正发生变化的是智能体能力的边界。大语言模型的出现极大拓展了单个智能体能够进行推理和完成任务的范围，使其能够处理过去难以胜任的复杂问题。

长期以来，人们对于什么才算是智能体一直存在一定的混淆。为了更准确地理解这一概念，下面我们将回顾从与大语言模型的直接交互，到LLM Actions、Assistant Proxy、Assistant、Agent，再到Agentic System的发展演进过程。

1.1.1 理解 Agent、Assistant 与 LLM 的演进模式

当 ChatGPT、Claude 等系统刚刚发布时，用户实际上是在直接与底层的大语言模型交互：输入一条提示词，模型生成一段文本，整个交互过程到此结束。如果你曾在这些工具发布初期使用过它们，那么你印象中的大概就是这种最直接的对话模式。

在此基础上，更进一步的发展是让大语言模型调用工具来完成具体任务，例如生成图片、搜索网络信息，或执行其他操作。如今，这已经成为 ChatGPT、Claude 等产品的常规能力，但与最初仅能进行文本生成的交互方式相比，这代表着一次重要的能力跃升。

图 1.1 展示了两种典型的交互方式：一种是用户直接与大语言模型交互（上图）；另一种是用户与能够调用工具的大语言模型进行交互，这类系统通常称为智能助手（下图）。可以看到，当 ChatGPT 作为智能助手使用时，它能够先生成质量更高的图片生成提示词，从而获得更好的图像生成效果。

图 1.1 与大语言模型交互的两种常见模式：一种是直接与 LLM 本身交互，另一种是与具备工具调用能力的 LLM 进行交互。如果你使用过早期版本的 ChatGPT，那么体验到的就是直接与 LLM 交互的模式，当时没有代理智能体或其他智能助手代表你执行任务。如今，ChatGPT 已集成了网络搜索、代码编写等多种工具，使其能够借助这些工具完成用户请求，因此当前版本的 ChatGPT 更接近于一个智能助手，而不仅仅是一个文本生成模型。

如果你曾通过 ChatGPT、Gemini 等平台使用过 Nano Banana、Image 2.0 或其他图像生成工具，那么你实际上已经体验过一种代理智能体（Proxy Agent）的交互方式。在这种模式下，大语言模型并不会直接将你的请求发送给图像生成模型，而是会先接收并理解你的请求，再将其重新组织、优化为更适合目标任务的输入格式，然后再交由相应的工具执行。

正是在上述两种直接交互模式的基础上，AI 系统逐渐演进出了能够调用工具的智能助手（Assistant）以及智能体（Agent）。目前，这一领域的术语尚未完全统一，因此在许多资料中， Assistant 和 Agent这两个词经常会被混用。在本书中，我们将以自主性作为二者的主要区分标准。本书所说的智能助手，是指能够代表用户调用工具，但在执行过程中的每一步都需要用户批准，且不具备自主规划和连续完成多个任务能力的大语言模型。与之相对，智能体则能够自主开展推理、制定计划并执行任务，例如发送电子邮件、制作演示文稿、预订机票以及开展研究等，而无需在每一步都依赖用户的确认。

在实际应用中，智能助手与智能体之间的区别并不是一道泾渭分明的界限，而更像是一条连续的能力谱系。在生产环境中，智能体几乎都会采用分级的人类参与（Human-in-the-Loop，HITL）控制机制：对于风险较低的操作，智能体可以自主执行；对于风险中等的操作，则可能需要用户确认；而对于发送电子邮件、进行支付、删除数据记录等高风险操作，无论智能体整体具备多高的自主性，通常都必须经过用户的明确批准才能执行。因此，当本书将智能体描述为具有自主性时，我们的意思是，它能够自主完成推理、制定计划，并执行由多个步骤组成的任务；这并不意味着它应该在任何情况下都完全脱离人工监督运行。设计合理的审批与监督机制，本身就是智能体系统设计的重要组成部分。本书后续也将多次回到这一主题，深入讨论如何在自主性与安全性之间取得平衡。

表 1.1 总结了本书将介绍的四种交互模式，从直接与大语言模型对话一直到自主智能体，展示了它们在能力和自主性方面的逐步演进。

表 1.1 本书涉及的四种 LLM 交互模式

图 1.2 对智能助手与智能体两种模式进行了对比。二者最关键的区别在于人在执行流程中的位置（Human in the Loop）：智能助手在执行每一个步骤时都需要获得用户的批准，而智能体则围绕一个更高层次的目标自主开展工作。

图 1.2 上图：智能助手代表用户执行一个或多个任务，但每项任务都需要用户逐步批准；下图：智能体能够围绕既定目标自主调用多个工具完成任务，无需在执行过程中逐步获得用户批准。

在图中，上方的智能助手通过调用单个工具访问天气服务来回答天气查询，但在执行该操作之前，它会先征求用户的批准。相比之下，下方的智能体（Agent）则由用户赋予自主决策、推理和规划的能力，可以自主选择并调用所需工具，以完成一个更高层次的目标。在这个示例中，用户授权智能体自行决定如何使用电子邮件和通知等工具，从而识别并展示最重要的五封邮件。

如果你曾使用过 ChatGPT 的网络搜索、Canvas 或 GPT Assistant 等功能，那么实际上你已经体验过智能助手。在这种模式下，大语言模型知道自己可以使用哪些工具或助手功能，并能够根据用户的请求判断是否需要调用它们。在调用新的外部工具之前，LLM 会暂停执行并请求用户批准。获得批准后，相应的工具会被调用，其执行结果再返回给 LLM。随后，LLM 会将这些结果整理并组织成自然语言回复，最终呈现给用户。

与智能助手不同，智能体会先理解用户提出的请求或目标，然后通过推理制定执行计划，并识别完成任务过程中需要进行的各项决策。随后，智能体会按照既定计划逐步执行任务，并自主完成执行过程中所需的各项决策。它可能会在完成某些关键里程碑后请求用户反馈，但总体而言，智能体具备自主制定计划并执行计划，以实现既定目标的能力。能动性赋予了智能体完成复杂目标的能力，但与此同时，也必须采取适当的控制措施，防止智能体执行未经授权或不可预期的操作。

1.1.2 像智能体一样思考：感知—规划—行动—学习（Sense–Plan–Act–Learn）

我们使用能动性这一术语来描述智能体自主做出决策并利用工具完成既定目标的能力。从内部工作机制来看，这意味着智能体必须能够对实现目标所需的任务进行推理。

表 1.2 给出了三个示例目标：创建一张图片、前往卡尔加里旅行，以及购买一台计算机。同时，表中还列出了实现每个目标所需执行的任务，以及完成这些任务需要使用的工具。

表 1.2 完成不同目标所需的任务与工具

目标既可以很简单，例如生成一张图片；也可以十分复杂，例如预订旅行或购买商品。为了完成一个目标，智能体会将其拆解为多个任务，并进一步细化到工具层面，即每个任务都对应一次或多次工具调用。这些工具既可以是面向特定任务的专用工具，例如图像生成工具；也可以是用途更加广泛的通用工具，例如网络搜索，它能够为多个不同的任务提供支持。在执行过程中，一个工具的输出结果还可以作为下一个工具的输入，这种将多个工具串联起来完成任务的过程称为工具链。

智能体会从用户或系统接收一个目标，并将其拆解为多个具体任务。随后，智能体依次执行完成目标所需的各项任务。图 1.3 展示了智能体从接收用户目标到调用工具完成任务的典型工作流程。整个过程可以概括为四个基本步骤：感知、规划、行动和学习。

图 1.3 智能体完成目标的四步流程：感知——接收输入（例如目标或反馈）；规划——确定完成目标所需的任务；行动——调用并执行任务对应的工具；学习——观察任务执行结果，判断目标是否已经完成，或是否需要继续执行后续流程。

感知—规划—行动—学习循环，是智能体完成需要多个任务步骤目标时所采用的内部运行机制。能动性——尤其是自主决策和规划的能力——正是驱动这一循环持续运行的核心。这一循环并非全新的概念。它借鉴了经典人工智能和机器人领域中许多成熟的思想，例如军事战略中的 OODA 循环（Observe–Orient–Decide–Act，观察—判断—决策—行动）、智能体研究中的 BDI（Belief–Desire–Intention，信念—愿望—意图）架构，以及更早提出的反应式规划（Reactive Planning）和感知—规划—行动（Sense–Plan–Act）机器人控制范式。本书将这一经典模式适配到了基于大语言模型的智能体中，其中：感知对应输入与上下文处理，规划对应 LLM 的推理过程，行动对应工具调用与执行，而学习则对应对执行结果的评估以及记忆的更新。

在配置智能体时，我们通常会为其提供完成任务所需的各种工具。随后，当智能体接收到一个目标时，它会加载自身的指令，并在内部生成一份执行计划。这份计划会明确需要调用哪些工具、如何调用这些工具，以及哪些工具的输出需要作为后续工具的输入进行串联。接下来，智能体会根据任务执行结果和工具返回的输出进行观察与评估，判断目标是否已经完成，还是需要继续执行后续步骤。如果目标已经达成，智能体便会将最终结果返回给用户。以上只是对整个流程的高层概述。在实际应用中，上述部分或全部步骤都可能比这里描述的更加复杂。

对于早期的基础大语言模型（如GPT-4），我们通常需要借助提示工程等技术，引导模型按照步骤进行推理、制定执行计划，并依照计划完成各项任务。如今，大多数用于构建智能体的前沿模型都已经具备了一定的推理和规划能力，并且通常会以 Thinking 或 Reasoning 模式的形式显式提供给用户使用。不过，这种内置推理能力的质量差异仍然较大。对于规模较小的模型、较早期的模型，或是在超出其训练分布范围的任务上运行的模型，即使名义上支持推理模式，也可能只能进行较浅层的推理，或者在处理复杂的多步骤任务时跳过某些关键步骤。

模型内置的推理能力在一定程度上降低了通过智能体指令显式引导模型进行推理的需求，但并没有完全取代这种做法。正如第 4 章将要介绍的，在许多场景下，我们仍然需要采用各种推理模式来提升、规范和控制智能体的推理过程，尤其是在处理长程任务，或底层模型本身并非具备顶尖推理能力的情况下，这些推理模式仍然发挥着重要作用。

1.1.3 Agent 通过工具执行行动

OpenAI 和 ChatGPT 率先建立了大语言模型调用工具的基本模式，而这一模式后来也被广泛应用于智能体的设计之中。为了让 LLM 或智能体能够正确使用工具，需要事先告诉它们如何调用工具，包括工具的输入参数应如何定义，以及工具返回结果后应如何处理。工具本质上是对程序函数（Function）的封装，因此我们通常将其称为工具函数。

图 1.4 要使用工具，智能体首先需要将该工具注册为一个JSON格式的描述（定义）。完成注册后，智能体便可以像在Python中调用函数一样调用该工具函数。

工具通常是对API调用、数据库、外部应用程序或其他资源的封装，使智能体能够突破自身代码的限制，与外部系统进行交互并执行实际操作。不同的智能体框架通常都提供了工具注册机制，使开发者能够将普通函数注册为智能体可调用的工具。例如，可以通过 Python 装饰器、TypeScript 装饰器，或框架提供的配置项完成注册。注册完成后，智能体便能够了解该工具的功能、输入输出以及适用场景，并在需要时自主调用它。

工具调用并非总能成功，而智能体如何处理工具调用失败，往往正是演示级系统与生产级系统之间的重要区别。在实际应用中，工具可能因各种原因调用失败，例如API 请求超时、数据库返回了不符合预期的数据结构、触发接口调用频率限制、外部服务不可用，或传入参数格式错误等。一个设计良好的智能体不会将这些失败视为程序崩溃，而是把它们当作正常控制流程的一部分来处理。它会将错误信息反馈给模型，由智能体自主判断下一步应采取的策略，例如重试、切换到备用方案、向用户请求进一步确认，或者放弃当前任务。同时，系统还会限制重试次数，以避免陷入无限重试的循环。在后续章节构建生产级智能体时，我们还将深入讨论错误处理、重试机制以及回退策略等关键工程实践。

传统上，智能体和大语言模型只能使用其代码库中已经集成的工具。这一限制很快就暴露出了问题，因为开发者往往花费更多时间构建和维护工具，而不是开发智能体本身。例如，一个智能体可能需要读取你的日历、发送一条 Slack 消息、查询PostgreSQL数据库，并创建一张Jira工单。如果没有统一的协议，开发者就必须分别为这四种服务编写并维护四套工具封装，持续跟进四套 API 的更新变化，并且反复实现相同的认证、重试以及数据结构处理逻辑。如果一个团队同时开发多个智能体，这些重复性的工作还会成倍增加，最终，大部分工程投入都会耗费在工具集成与连接上，而不是智能体行为和能力本身的开发。

这一状况后来发生了改变。模型上下文协议（MCP）等标准协议，使智能体能够调用代码库之外的工具，而不再局限于本地集成的功能。借助 MCP，开发者无需再为每一种外部服务重新编写集成代码，智能体可以直接连接并调用由服务提供商或开源社区维护的工具服务器。MCP 的出现标志着智能体开发方式的一次重要转变：从过去每个智能体都内嵌一套专有工具库的模式，逐步演进为依托标准化、可发现的外部工具服务器生态来构建智能体系统。这种模式不仅减少了重复开发工作，也使工具的共享、复用和扩展变得更加容易。

1.2 认识 Model Context Protocol（MCP）

**MCP（Model Context Protocol，模型上下文协议）**由 Anthropic 开发，并于 2024 年 11 月发布。它是一种基于JSON-RPC 2.0的开放标准，旨在让 AI 系统能够以一致、安全且高效的方式连接外部服务。JSON-RPC 2.0是一种轻量级的远程过程调用协议，它定义了一套标准化的请求与响应消息格式。因此，无论 MCP 服务器是使用Python、TypeScript、Go或其他编程语言实现，MCP 工具调用都遵循统一、可预测且与编程语言无关的结构。

最初，MCP 被定位为LLM 与工具之间的集成接口，延续了上一节中提到的 OpenAI 在 ChatGPT 中已经建立的工具调用模式。MCP 与早期相关方案的区别在于，它提供了一种简单且易于适配的协议，能够将几乎任何代码库封装成一个轻量级的服务器。这种设计使 MCP 成为了适用于大语言模型工具连接的一种通用模式。从根本上来说，MCP 改变了我们构建 AI 系统的方式。

因此，LLM 和智能体开发者可以利用现成的 MCP 服务器，轻松集成代码库之外的各种工具。当目标服务已经存在对应的预构建 MCP 服务器时，开发者无需再自行编写用于工具调用的独立函数，也不需要处理底层接口、数据库连接或其他集成细节。相反，他们只需要连接到 MCP 服务器，发现其中提供的可用工具，然后即可无缝使用这些工具。如果目前还不存在对应的预构建服务器，那么仍然需要有人开发并维护一个 MCP 服务器，用于封装底层能力。但这种工作只需要针对每种服务集成完成一次，而不必为每个智能体重复实现。最终生成的 MCP 服务器还可以被复用，或共享给更广泛的开发者社区。

图 1.5 展示了智能体与 MCP 之间在实际场景中的交互方式，它将工具开发从每个智能体独立承担的重复工作，转变为一个共享且可复用的基础层。

图 1.5 智能体连接到 MCP 服务器，以发现其提供的工具，并了解如何使用这些工具。当一个 MCP 服务器被注册到智能体后，智能体会在内部调用 list_tools，获取该服务器支持的所有工具及其描述。随后，与常规的工具调用流程类似，智能体会根据工具描述来判断如何最合理地使用这些工具。

将智能体连接到 MCP 服务器通常包括两个步骤：首先配置并运行 MCP 服务器，然后将该服务器注册到智能体中。完成连接后，当智能体接收到一个任务时，它首先会调用服务器上的 list_tools，获取当前可用工具列表及其描述。随后，智能体会在内部判断应该使用哪个工具，执行相应调用，并根据返回结果进行学习和调整，必要时修改后续计划，最终汇总并返回任务结果。

MCP 常被称为LLM 和智能体领域的 USB-C，它旨在解决开发者在构建 LLM 应用和智能体应用时经常遇到的许多问题：

• 工具访问不一致 —— 虽然 OpenAI 为工具调用建立了一套标准，但并非所有 LLM 提供商都遵循这一标准。开发者通常需要根据底层模型的要求调整 JSON 工具描述。MCP 则将这些差异进行了抽象和隐藏。

• 数据响应不可靠 —— 使用统一标准协议可以减少在实现和访问多个工具时可能出现的错误。借助 MCP，工具返回结果的格式被标准化，更容易被系统消费，从而降低数据处理错误。

• 集成碎片化 —— 将工具函数代码与智能体/LLM 放在同一个代码库中，通常意味着需要直接在智能体代码旁编写工具逻辑，或者创建后续可复用的独立模块或软件包。这往往会导致代码中混杂大量支持不同工具的实现，而在运行智能体时，又必须将这些工具全部连接起来。

• 代码可扩展性 —— MCP 为使用任意编程语言开发工具提供了统一协议。这意味着开发者不再受限于 Python，也不再受限于智能体所使用的代码库。

• 实现抽象 —— 开发者无需再关注工具实现过程中的复杂细节。随着 MCP 的发展，目前已经有大量开源服务器可用，可以为几乎所有常见使用场景提供工具能力。

• 易于构建 —— MCP 以及其他提供方提供了大量工具和软件包（SDK），帮助开发者快速使用不同语言构建服务器。如果开发者需要创建自己的工具，也可以简单地将其封装为 MCP 服务，使这些工具能够被大多数智能体框架和 LLM 框架访问。

• 安全与信任 —— 将智能体连接到 MCP 服务器意味着暴露了智能体可以自主调用的工具执行接口，因此 MCP 服务器会成为智能体运行环境中的高权限访问面。MCP 在传输层支持身份认证和授权，同时该协议也支持通过沙箱隔离、限定范围的凭证以及针对高风险操作的人机协同审批来进行安全部署。在构建智能体系统时，应将 MCP 服务器视为受信任的依赖组件：验证其来源，固定版本，并遵循最小权限原则运行它们，以确保智能体系统能够安全、负责任地运行。

MCP 已经成为推动 AI Agent 发展和普及的重要因素之一，因为它能够让 Agent 与各种工具和资源实现无缝集成。在第 3 章中，我们将深入探讨 MCP，从构建 MCP 服务器，到让 Agent 调用和使用这些服务器，都会进行详细介绍。工具和 MCP 服务器只是构建 Agent 的一个方面。下一节，我们将进一步探讨构成 Agent 的基础层次结构。

1.3 理解 Agent 的五大功能层

Agent 的复杂程度可以有很大的差异：从用于完成简单任务和目标的基础实体，到能够执行复杂、多步骤目标的高级实体。为 Agent 增加功能并提升其能力，可以理解为不断叠加功能层（functional layers）的过程。

一个完整的 Agent 通常由以下五个核心功能层组成：

1. Persona（角色设定）
2. Tools and Actions（工具与行动）
3. Reasoning and Planning（推理与规划）
4. Knowledge and Memory（知识与记忆）
5. Evaluation and Feedback（评估与反馈）

如图 1.6 所示，这五个功能层构成了现代 AI Agent 的基础架构，也是本书前半部分构建 Agent 时所采用的整体框架。

图 1.6 Agent 的五大功能层：Persona（角色设定）、Tools and Actions（工具与行动）、Reasoning and Planning（推理与规划）、Knowledge and Memory（知识与记忆），以及 Evaluation and Feedback（评估与反馈）。

每一层都代表着 Agent 能力的一种演进。并非所有 Agent 都必须具备全部五层能力。在某些情况下，也可以省略特定层。不过，在大多数情况下，核心层（角色设定、工具与行动、推理与规划）对于所有 Agent 都是必不可少的。还需要注意的是，这些层并不是按照固定的从上到下顺序被调用的。在 Agent 循环过程中，核心组件会持续交互：推理会参考角色设定来做出决策，规划会调用工具，工具返回的结果会反馈给推理过程，而角色设定则会约束 Agent 如何表达最终结果。因此，图中的五层结构只是为了方便理解 Agent 的能力组成，而并不代表 Agent 在运行时的实际调用顺序。

我们将在接下来的章节中对这些层进行更详细的探讨。随着本书的深入推进，我们会在后续章节中进一步深入研究每一层的具体内容。

1.3.1 Agent 的 Persona（角色设定）

Agent 角色层代表了 Agent 的基础描述和定位。角色设定通常也被称为系统提示词，它指导 Agent 完成任务、学习如何响应，以及理解其他相关细节。角色设定包含诸如背景或角色（例如程序员、作家）等元素，除此之外，它还可以进一步描述 Agent 的各种属性，例如专业水平、沟通风格、领域方向以及运行约束等。

角色设定可以通过多种方式生成，包括开发者手动编写；借助 LLM 辅助生成，即由一个模型为另一个模型编写或优化角色设定；以及基于数据驱动的方法，例如进化算法。在研究场景中，进化算法已被用于根据性能指标对 Agent 角色设定进行迭代变异和筛选，通过自动化的试错过程有效优化 Agent 的角色设定。图 1.7 将角色层展示为 Agent 的第一层。

图 1.7 角色层是 Agent 的核心层。它由定义 Agent 角色以及 Agent 应如何完成目标和任务的系统指令组成。其中可能包含关于推理、规划以及访问知识和记忆的相关指令。

在后续章节中，我们将通过提示工程、推理与规划、评估标准以及事实约束等技术，探索如何创建有效且具体的 Agent 角色设定。我们还将学习由人类制定的角色设定与由 AI 生成的角色设定之间的区别。

1.3.2 Agent 的工具与行动

几乎所有 Agent 的下一层核心能力都是工具与行动。工具帮助 Agent 朝着最终目标完成任务，并支持更高层的推理与规划、知识与记忆、评估与反馈等层面的活动。图 1.8 展示了工具与行动层，以及它在增强 Agent 能力方面所发挥的作用。

图 1.8 展示了工具与行动层在 Agent 中的作用。工具不仅负责执行具体任务，也是支撑推理、知识、记忆以及评估等上层能力的基础设施，是 Agent 不可或缺的核心组成部分。

根据用途不同，工具与行动大致可以分为以下几类：

• 任务执行工具
• 上下文获取工具
• 推理与规划工具
• 知识与记忆工具
• 反馈与评估工具

这些工具对 Agent 内部状态以及外部环境的影响各不相同。

其中，上下文获取工具主要负责获取 Agent 做出下一步决策所需的信息，例如执行网络搜索、查询向量数据库、读取本地文件、调用只读 API等。这类工具的特点是只负责获取信息，而不会改变任何外部系统的状态。它们与另外两类工具存在明显区别。

知识与记忆工具负责读取或更新 Agent 自身的持久化知识库和记忆存储，例如写入长期记忆或读取历史经验。

而任务执行工具则是真正作用于外部世界的工具，它们能够执行实际操作，例如发送邮件、创建工单、修改数据库记录或调用第三方服务。

在 Agent 的运行过程中，工具的调用通常并不是随机发生的，而是受到多个模块共同驱动，包括：

• 规划：决定下一步需要调用哪些工具；
• 记忆检索：根据历史经验选择合适的工具或执行策略；
• 评估与反馈：根据工具执行结果调整后续行为，并持续优化 Agent 的决策过程。

这些机制共同决定了 Agent 如何选择和使用工具，并帮助 Agent 在执行过程中不断调整行为、积累经验，从而逐步提升完成复杂任务的能力。

1.3.3 Agent 的推理与规划

能够调用工具或执行实际操作的 Agent，必须具备推理和规划能力。如今的大多数前沿基础模型已经具备较强的原生推理能力，并能够输出一定程度的推理过程。对于大多数通用应用场景而言，这种内置推理能力已经足够使用。然而，对于能力要求更高的 Agent，我们通常希望能够更精细地控制其推理过程，例如：

• 应该考虑哪些因素；
• 按照什么顺序进行推理；
• 推理过程中应遵循哪些约束。

因此，在很多场景下，我们仍然需要在模型原生推理能力之上，进一步引入结构化的推理策略。

通常可以根据以下原则判断：什么时候仅依赖模型原生推理即可，什么时候需要增加结构化推理。

• 模型原生推理通常已经足够，当任务具有以下特点时：

  • 任务流程较短，只包含一到三个步骤；
  • Agent 可调用的工具数量较少；
  • 即使执行错误，其代价也较低且容易恢复；
  • 使用的是推理能力较强的前沿模型，并且任务属于模型擅长的领域。

• 当出现以下任意情况时，引入结构化推理会带来明显收益：

  • 任务流程较长，或者需要拆分为多个子目标；
  • Agent 拥有大量工具，需要在其中做出合理选择；
  • 操作错误代价较高，甚至不可逆，例如发送邮件、资金转账或修改生产环境数据；
  • 任务超出了模型训练时的优势领域；
  • 希望整个推理过程能够审计或复现；
  • 使用的是参数较小或较旧的模型，其原生推理能力相对有限。

• 对于安全关键或受监管的场景，应始终在模型原生推理之外增加结构化推理。

原生推理通常属于模型内部行为，不仅难以观察，而且不同运行之间还可能存在差异；而结构化推理能够让开发者清楚地检查、测试并约束 Agent 的推理过程，从而提升系统的可靠性和可控性。

图 1.9 展示了推理与规划层在 Agent 中的作用，以及如何通过不同方法增强 Agent 的思考能力。本书将在第 5 章详细介绍多种经典推理模式，包括 Chain of Thought（CoT，思维链）、ReAct（Reason + Act）、**Reflexion（反思机制）**以及其他常见的 Agent 推理框架。

图 1.9 Agent 的推理与规划层，以及增强 Agent 思维能力的不同方式。Agent 的推理既可以来自底层大语言模型本身，也可以结合提示工程和工具调用等方法进一步增强。

在规划过程中，Agent 通常会采用两种不同的推理方式：单路径推理和多路径推理。

在单路径推理中，Agent 一旦确定了执行计划，就会按照既定顺序逐步完成各项任务。即使某一步失败，或者得到意料之外的结果，它通常也不会回到之前重新规划，而是继续沿着当前路径执行。这种方式速度快、成本低，但当任务存在较大不确定性时，整体鲁棒性较差。

相比之下，多路径推理会同时（或依次）探索多个可能的解决方案。Agent 会针对不同方案分别进行分析，并根据最终目标评估哪一条路径最有希望成功，然后选择最佳方案继续执行。它还可能将表现优秀的执行路径保存下来，以便未来遇到类似任务时直接复用。其中，**Tree of Thoughts（ToT，思维树）**就是多路径推理最具代表性的实现方式之一。相比单路径推理，多路径推理通常能够在复杂任务中制定出更优的执行方案。不过，由于 Agent 需要同时规划多条路径，因此会消耗更多 Token，也会增加整体推理时间。

除了由 Agent 自身完成规划之外，实际系统中还经常采用外部规划器。所谓外部规划器，是指独立于 Agent 之外、专门负责制定执行流程的系统，例如编排程序、工作流引擎、专门负责规划的 Planning Agent。在这种架构下，执行 Agent 本身并不负责制定整体计划，而是由外部规划器决定下一步应该执行什么任务，再将对应指令交给 Agent 去完成。本书后续章节还将介绍什么情况下应该让 Agent 自己规划，什么情况下应将规划能力交给外部系统完成。

除了学习如何让 Agent 更高效地执行任务、完成目标之外，我们还将系统介绍各种经典规划方法，并深入探讨不同的推理策略，包括单路径推理和多路径推理，帮助 Agent 在复杂任务中制定更合理、更高效的执行方案。

1.3.4 Agent 的知识与记忆

Agent 利用知识和记忆，在尽可能减少 Token 消耗的前提下，为当前上下文补充最相关的信息。这不仅有助于提升回答质量，也能够提高推理效率。知识与记忆的组织方式可以有多种形式。它们既可以采用统一结构，即知识和记忆共享同一种存储与检索机制；也可以采用混合结构，结合多种不同的存储和检索方式。实际应用中，知识与记忆的数据来源十分丰富，例如PDF 等文档资料、关系型数据库、对象数据库、文档数据库、图数据库、关键词搜索索引、基于向量嵌入的语义检索系统,甚至简单的列表也可以作为 Agent 的记忆存储。

目前，在实际生产环境中，最常见的记忆形式是对话记忆。它记录了用户与 Agent 的整个对话过程，包括双方交流的内容，以及 Agent 在执行任务过程中调用过的各种工具。通常，对话记忆可以分为两类：短期记忆和长期记忆。短期记忆保存的是当前会话最近发生的对话内容，它直接存放在模型的上下文窗口中，并随着会话不断更新。长期记忆则能够跨越多个会话长期保存，并仅在需要时被检索出来。在大多数生产级 Agent 中，这两类记忆通常会结合使用。系统会在当前会话历史的基础上，再叠加用户的长期偏好、历史决策以及持续进行中的项目等长期信息，从而使 Agent 能够提供更加个性化、更具连续性的服务。

所有这些设计都受到一个重要限制——上下文窗口。上下文窗口决定了模型一次最多能够关注的 Token 数量，因此，它也是 Agent 架构设计中最关键的因素之一。上下文窗口的大小直接影响许多设计决策，例如：

• 在达到窗口限制之前，可以保留多少历史对话；
• 什么时候需要对历史内容进行摘要或丢弃；
• 工具返回的数据应该全部放入上下文，还是先过滤或分块；
• 知识检索得到的内容应如何排序、裁剪，再插入上下文；
• 多个 Agent 协同工作时，应如何共享彼此的状态信息。

虽然拥有更大上下文窗口的模型能够缓解这些问题，但并不能彻底解决。更长的上下文不仅意味着更高的推理成本、更慢的推理速度，还可能在超过一定长度后降低模型的推理质量。因此，在设计 Agent 的记忆系统时，决定哪些信息不应该放入上下文窗口，与决定哪些信息应该被检索出来同样重要。关于上下文管理和记忆架构，我们将在后续章节进行更加深入的讨论。

虽然知识与记忆都为 Agent 提供信息支持，但二者承担着不同的职责。知识指的是 Agent 在完成任务时需要使用的静态外部信息。例如产品文档、用户手册、知识库文章、数据库 Schema、代码仓库、各类参考资料等。这些信息独立于任何一次具体对话而存在，并随着原始数据源的更新而变化，例如新的公司制度发布、产品手册更新等。通常，同一个 Agent 的所有用户都会共享同一套知识库。

相比之下，记忆属于 Agent 在交互过程中逐渐积累的动态经验信息。它可能来自当前对话内容、用户明确表达的偏好、历史会话中的重要决策、Agent 对自身行为记录下来的观察结果。记忆会随着使用过程持续更新，并且通常只属于某一个特定用户、租户或会话。

知识与记忆在存储方式上也有所不同。知识通常存放于向量数据库、搜索索引、图数据库等。这些系统更加关注检索范围和召回率。而记忆则更多存放于Session Store、Key-Value Cache、用户专属数据库等。这些存储方式更加关注信息的新鲜度以及与当前用户的相关性。

无论是知识还是记忆，目前最主流的接入方式都是一种被广泛采用的技术——检索增强生成（RAG）。RAG 的核心思想是：先检索，再生成。当 Agent 需要做出决策时，它首先从知识库或记忆系统中检索最相关的信息，然后将这些信息加入当前上下文，再交由 LLM 进行推理和生成。RAG 最初主要用于静态知识检索，但如今，这一模式已经广泛应用于Agent 的长期记忆系统、知识与记忆混合架构、基于工具的动态信息查询。图 1.10 展示了知识与记忆层在 Agent 中所承担的作用。

图 1.10 Agent 的知识与记忆层通常采用多种存储方式。知识表示模型预训练时并未掌握、但后续提供给 Agent 的外部信息；记忆则表示用户、Agent 或其他系统在交互过程中积累的历史经验和状态信息。

在后续章节中，我们将学习如何设计更加高效的 Agent 信息管理体系。我们将介绍语义嵌入及其在 Agent 中的应用，探讨统一架构与混合架构如何适应不同场景下的需求。此外，我们还将学习如何利用多种知识来源，包括自然语言文档、不同类型的数据库，以及基于向量嵌入（Embeddings）的语义相似度检索。最后，我们将进一步分析混合架构如何同时提升 Agent 在知识检索和记忆管理方面的能力。

1.3.5 Agent 的评估与反馈

评估与反馈是 Agent 的最后一层功能模块，它通过各种外部机制帮助 Agent 提供更加准确、更加可靠的结果。目前，一种非常常见的实现方式是 LLM-as-Judge（LLM 作为评审）。在这种模式下，一个独立的大语言模型负责对 Agent 生成的结果进行评估，并根据预先设定的评价标准进行评分、审查或提出修改建议，之后再将最终结果返回给用户。

对于 Agent 自身而言，评估与反馈主要发生在 Sense–Plan–Act–Learn（SPAL） 循环中的 Learn 阶段。在这一阶段，Agent 会对工具执行结果或任务完成情况进行分析，根据反馈决定是继续当前的目标执行计划，还是对计划进行调整和修改。图 1.11 展示了评估与反馈层在 Agent 架构中的位置，以及它如何作为整个 Agent 的最后一道质量保障机制。

图 1.11 Agent 的评估与反馈层，以及实现这一能力的各种机制，包括评估工具调用结果、验证知识检索（Grounding）、向其他 Agent 提供反馈，以及支持具有类似能力的工作流等。

在实际系统中，Agent 所采用的评估与反馈机制会根据具体应用场景和需求有所不同。这些机制可能表现为多种形式，例如：

• 可调用的评估工具：Agent 可以主动调用这些工具，对执行结果进行检查和评分。
• 其他 Agent：一个 Agent 可以作为另一个 Agent 的工具，或在任务交接过程中负责评估和反馈。
• 输入与输出护栏：对 Agent 的输入和输出进行约束，确保内容符合预期、安全可靠。
• 独立的评审器：作为独立组件，与执行任务的 Agent 并行运行。

其中，最后一种方式通常采用经典的 Actor–Critic（执行者—评审者） 架构。在这种架构下，Actor 负责生成候选方案或回答， Critic 对结果进行评分、审查或修改，只有经过 Critic 审核之后，Agent 才会正式采用该结果并继续执行后续任务。这种机制能够有效提升 Agent 输出的质量与稳定性。除此之外，还有一些专门面向 Agent 的工作流设计，本身就鼓励在执行过程中不断进行评估与反馈。下一节中，我们将介绍这些典型的 Agent 工作流模式，并进一步了解评估与反馈在多智能体系统中的作用。

1.4 迈向多智能体系统

单个 Agent 已经能够完成许多任务，并实现多个目标。然而，随着问题规模和复杂度不断增加，单智能体系统很快就会遇到能力瓶颈。因此，多智能体系统的出现并不仅仅是为了增加 Agent 的数量，而是出于以下几个核心原因。

• 专业化：如果一个 Agent 同时拥有所有工具、领域知识以及各种指令，它的表现往往不如多个各司其职的 Agent。例如，将客服系统拆分为：

  • 分诊 Agent（Triage Agent）：负责识别用户问题并进行任务分发；
  • 计费 Agent（Billing Agent）：专门处理计费和支付相关问题；
  • 技术支持 Agent（Technical Support Agent）：专门解决技术故障和产品使用问题； 通常会比让一个 Agent 同时负责这三项工作取得更好的效果。

• 并行处理：有些任务天然适合并发执行，例如调研 10 家公司、审查 20 个 Pull Request、批量处理大量文档等。 多智能体系统可以将这些任务分发给多个 Agent 同时执行，从而大幅缩短整体完成时间，而无需像单个 Agent 那样逐个处理。

• 上下文管理：每个 Agent 都受到上下文窗口的限制。将一个大型任务拆分给多个 Agent 后，每个 Agent 只需要关注自己负责的那部分内容。这样，整个系统便能够处理那些单个 Agent 因上下文限制而无法完成的大规模任务。

• 天然属于多智能体的问题：有些应用场景本身就必须依赖多个智能体。例如社会模拟、市场与谈判模型、红队 / 蓝队对抗、多角色协同决策等。在这些场景中，每个参与者都拥有不同的目标和行为，因此无法通过单个 Agent 来模拟。

多智能体系统极大扩展了 Agent 的能力边界，使其能够自动完成许多单个 Agent 难以胜任的复杂任务。接下来，我们将介绍第一种、也是最常见的多智能体协作模式。

1.4.1 Agent Flow：流水线模式

多个 Agent 可以采用多种方式协同工作。具体采用哪种协作模式，取决于应用场景和业务需求。图 1.12 展示了最经典的一种模式——Agent Flow（流水线模式）。

图 1.12 多智能体的流水线协作模式。整个流程从规划 Agent开始，它首先将目标拆解为一个高层计划，然后将计划交给研究 Agent。研究 Agent 完成资料收集后，再把结果交给内容 Agent，由后者完成后续工作，例如根据研究结果撰写论文。

在 Agent Flow 中，多个 Agent 像生产流水线一样依次协作。每个 Agent 都扮演一个专业工种，只负责自己最擅长的一部分任务，并拥有各自专属的工具和资源。这些 Agent 通常通过以下三种方式共享信息。

• Threaded（共享会话线程）：所有 Agent 共享同一条对话历史。每个 Agent 都可以读取之前所有 Agent 的输入与输出，并继续向其中写入新的内容。这种方式能够完整保留上下文，但随着任务不断推进，对话历史会越来越长，也容易让后续 Agent 被大量无关信息干扰。

• Blackboard（黑板模式）：多个 Agent 共享一个结构化的工作空间（Blackboard）。每个 Agent 将自己的中间结果按照预先定义好的键写入其中，其他 Agent 可以按需读取对应的数据。相比共享完整上下文，这种方式更加清晰、结构化，也更容易控制每个 Agent 能看到哪些信息。不过，整个团队需要事先约定好统一的数据结构。

• Chained（链式传递）：每个 Agent 仅把自己的输出交给下一个 Agent。就像真正的流水线一样，上一个工位完成工作后，将结果直接交给下一道工序。这是实现最简单、最容易理解的一种方式。不过，它也意味着前面的大量上下文不会继续传递，后续 Agent 只能看到前一个 Agent 输出的内容，而无法访问整个执行过程。

选择哪一种协作方式，主要取决于下游 Agent 实际需要多少共享上下文。共享的信息越多，并不一定意味着效果越好。事实上，在很多情况下，链式传递都是默认且最合适的选择。只有当实践证明后续 Agent 确实需要访问更早阶段的信息时，才有必要采用共享上下文或黑板模式。

Agent Flow 是目前最容易实现、最容易控制的一种多智能体架构。它特别适用于那些流程固定、角色明确、需要多个步骤依次完成的任务。如果一个单智能体系统已经无法顺利完成整条任务链，那么通常就意味着，它已经非常适合升级为 Agent Flow 多智能体架构。

1.4.2 Agent Orchestration（编排模式，Hub-and-Spoke）

Agent Orchestration（Agent 编排），通常也称为 Hub-and-Spoke（中心—辐射）模式，是一种适用于单个 Agent 已经负载过重、或者需要同时处理多个目标时的多智能体架构。这种模式下，系统通常仍然以一个主要 Agent 与用户进行交互，因此整体体验往往类似于一个功能更强大的 AI 助手。图 1.13 展示了典型的 Agent 编排模式。

图 1.13 Agent 编排模式。中央 Agent 作为中心或编排者，负责将任务分配给多个 Worker Agent。各个 Worker Agent 完成自己的任务后，将结果返回给中心 Agent，由中心 Agent 判断目标是否已经完成，并最终向用户输出结果。

在这种架构中，主 Agent通常承担整个系统的规划与协调工作。它负责：

• 理解用户目标；
• 制定整体执行计划；
• 将任务拆分成多个子任务；
• 分配给对应的专业 Worker Agent；
• 汇总各个 Agent 返回的结果；
• 判断整体目标是否已经完成。

整个过程类似于调用工具。不同的是，这里的“工具”不再是普通函数，而是拥有独立推理能力的 Worker Agent。每个 Worker Agent 都拥有自己擅长的工具集合，并能够自主完成一个或多个子任务。在内部，它们同样可以进行规划、推理和工具调用，只不过这一切都围绕各自负责的子目标展开。

这种模式最大的优势在于：所有输入和输出都由一个中心 Agent 统一管理。因此，整个系统的行为更加可控，也更容易维护。此外，对于已经具备工具调用能力的单 Agent 系统来说，也很容易升级为这种架构。开发者只需要将原来的工具替换成多个 Worker Agent 即可，而每个 Worker Agent 则负责管理自己对应的一组工具。

不过，这种模式也存在一定局限性。由于 Worker Agent 主要负责执行被分配的任务，因此它们通常拥有较少的自主权。它们之间一般不会主动交换意见，也不会彼此进行反馈、评审或协作。虽然某些变体会引入观察者或评审者Agent，但它们仍然只能通过中心 Agent 进行通信，而不能直接与其他 Worker Agent 协同工作。正因如此，下一节将介绍一种更加强大的多智能体架构——Agent Collaboration（Agent 协作），它能够突破这一限制。

1.4.3 Agent Collaboration（协作模式，多智能体团队）

早期的多智能体系统通常采用Agent 团队的形式。团队中的每个 Agent 都承担着特定角色，并共同协作解决复杂问题。图 1.14 展示了一个典型的多智能体协作团队。

图 1.14 一个由多个 Agent 组成的协作团队。在 Agent Collaboration 模式中，各个 Agent 之间能够像团队成员一样相互交流、反复讨论。在某些情况下，还会设置一个 Manager Agent充当用户代理，负责协调团队工作并确保整个团队始终围绕目标推进。

在 Agent Collaboration 模式下，各个 Agent 可以直接相互通信，也可以只与某几个指定的 Agent 保持联系。与前面介绍的模式一样，每个 Agent 都拥有自己负责的角色，以及对应的一组工具。不同的是，在协作模式中，Agent 不仅负责调用工具完成任务，同时还承担着团队中的某项职责。

例如，在图中的示例团队里，QA Agent不仅负责验证代码是否满足产品需求，还可以进一步分析代码质量，对代码结构、设计合理性等方面提出改进建议。同样，Product Agent不仅负责制定产品需求，还可以检查开发结果是否真正符合最初定义的需求规格。也就是说，每个 Agent 不再只是任务执行者，而是真正拥有明确职责的团队成员。

这种协作模式最大的优势在于，它能够解决极其复杂、持续时间较长的问题。由于多个 Agent 可以不断讨论、相互补充，因此整体解决问题的能力通常远远超过单个 Agent。此外，这种架构也比较符合人们对于团队合作的直觉，因此设计思路相对容易理解。

不过，它也存在明显缺点。由于 Agent 之间需要频繁交流，因此整个系统往往会产生大量重复对话。这种“高频沟通”不仅增加了 Token 消耗，也会导致推理时间更长，从而显著提高运行成本。因此，在设计多智能体系统时，成本始终是一个必须重点考虑的问题。

事实上，本节介绍的每一种多智能体架构，本质上都是在以下几个方面进行权衡：

• 推理延迟
• Token 消耗
• 系统复杂度
• Agent 能力

对于绝大多数实际项目来说，**最好的架构并不是能力最强的那个，而是能够以最低成本满足业务需求的那个。**本书后续在讨论生产环境中的 Agent 架构时，也会重点分析这些成本与性能之间的权衡。

通常情况下，我们只有在面对单个 Agent 无法解决的复杂问题时，才会采用协作模式。研究表明，多智能体之间的持续协作不仅能够提升问题解决能力，还有助于产生新的思路和创新想法。一些更加先进的协作系统甚至结合了进化算法，进一步增强 Agent 团队发现新知识、创造新概念的能力。

当然，这几种多智能体模式并不是互相排斥的。开发者完全可以根据实际需求，将不同模式组合使用，从而构建更加复杂、更加强大的多智能体系统。本书主要围绕 OpenAI Agents SDK 展开介绍。这一框架对 Agent Flow 和 Agent Orchestration 都提供了良好的支持，因此后续章节也将重点介绍这两种多智能体架构的设计与实现。

1.5 下一步

接下来的内容将围绕 Agent 的五大功能层展开：

• 角色设定
• 工具与行动
• 推理与规划
• 知识与记忆
• 评估与反馈

本书将以这五个功能层作为核心框架，帮助读者理解、设计并构建各种类型的 Agent。其中，每一个功能层都会对应一个独立章节，并配有可运行、可修改的示例代码，方便读者边学边实践。

不过，在正式深入介绍这五个功能层之前，本书首先会讲解现代 Agent 开发中两个至关重要的主题：MCP 和多智能体系统。MCP 改变了 Agent 与工具、数据之间的连接方式，而多智能体协作也已经成为构建真实 Agent 系统不可或缺的一部分。如果忽略这些内容，仅介绍一个简化版的单 Agent 示例，那么后续很多设计都会脱离真实的工程实践。因此，本书将这两个主题提前介绍，为后续所有章节打下更加贴近实际开发的基础。

掌握了五大功能层之后，我们将进一步从单 Agent 扩展到多智能体系统，以及真实世界中的分布式 Agent 系统。在这一阶段，重点已经不再是单个 Agent，而是多个 Agent 如何组成一个协同工作的整体，包括：

• Agent 之间如何交换消息；
• 如何在多个进程之间管理状态；
• 系统出现异常时如何处理故障。

随后，本书还将进入更高级的话题。我们将深入研究 Agentic Loop——这是 Deep Research Agent 等高级 Agent 能够持续规划、执行、观察和修正自身行为的核心机制。

接下来，我们还将探索下一代 Agent 系统。这些系统不仅能够完成任务，还拥有一定程度的元认知能力。也就是说，它们能够主动监控自己的推理过程，发现问题并进行修正，而不是完全依赖底层模型自身的推理能力。

最后一章将把全书内容融会贯通。作者将通过几个真实的生产级 Agent 系统案例，包括：

• 客服 Agent（Customer Support / Help Desk Agent）
• Deep Research Agent
• RAG Agent

展示如何将前面介绍的各种能力组合起来，构建真正可投入生产环境的 Agent 系统。届时，你将能够从整体架构角度理解这些系统，把它们看作是不同功能层、Agent 循环以及多智能体协作模式的不同组合，而这些内容都已经在本书中逐步构建完成。

正如前面所强调的，本书并不是一本生产运维指南。因此，对于企业级系统中的一些问题，例如：

• 安全
• 治理
• 合规
• 大规模部署

本书仅会进行简要介绍。当读者掌握 Agent 的构建方法之后，如果希望进一步学习生产级系统的最佳实践，可以结合最新的技术博客、视频教程以及各种 AI 搜索工具获取更加前沿的资料。

本章小结

• AI Agent 的核心特征是拥有“自主性”，能够自主做出决策、执行任务，并代表用户或系统采取行动。现代 AI Agent 通常由大语言模型结合工具、记忆以及规划能力共同构成。

• Agent 的自主性来源于一个自动运行的闭环——感知→ 规划→ 执行→ 学习，它使 Agent 能够持续完成复杂目标。

• Assistant需要用户逐步确认才能调用工具完成单个任务，而 Agent则能够自主推理、规划，并连续执行多个任务，从而实现更高层次的目标。

• 本书将 LLM 的使用模式划分为四种： 用户直接与 LLM 对话、Assistant Proxy（代理助手，对请求进行重写或转换）、 Assistant（带工具调用，需要用户确认）、Autonomous Agent（自主规划并执行任务的智能体）。

• Agent 接收目标之后，会加载系统指令，生成执行计划，识别需要调用的工具，按步骤完成各项任务，并在整个过程中自主做出决策，最终返回结果。

• Agent 通过工具与外部世界交互。工具通常封装了 API、数据库以及各种外部资源，使 Agent 能够突破自身代码范围执行实际操作。

• MCP由 Anthropic 于 2024 年 11 月提出，被誉为“LLM 的 USB-C 接口”。它提供统一协议，使 Agent 可以连接 MCP Server、自动发现可用工具，并无需编写大量定制化集成代码。

• MCP 解决了工具接口不统一、数据格式不一致、集成方式碎片化、扩展能力不足以及工具开发复杂等问题，同时也提供了标准化且易于开发的 MCP Server。

• Agent 可以通过五个核心功能层进行设计和构建：角色设定、工具与行动、推理与规划、知识与记忆、评估与反馈

• Persona 层定义 Agent 的身份、职责、行为方式以及完成任务时应遵循的系统指令。

• Tools and Actions 层赋予 Agent 与外部世界交互的能力，使其能够真正执行各种操作。

• Reasoning and Planning 层帮助 Agent 针对复杂目标进行推理、制定计划，并通过不断尝试和调整完成任务。

• Knowledge and Memory 层利用外部知识库和历史记忆，为 Agent 提供模型训练之外的信息，并结合过往经验辅助决策。

• Evaluation and Feedback 层通过各种评估机制持续优化 Agent 输出，提高回答质量，促进学习，并增强最终结果的可靠性。

• 多智能体系统主要包括三种典型模式：Agent Flow（流水线模式，多个专业 Agent 按顺序依次完成任务）、Agent Orchestration（编排模式、中心 Agent 统一协调多个 Worker Agent）、Agent Collaboration（协作模式，多个 Agent 作为团队相互沟通、共同完成复杂任务）。

• Agent Flow是最简单、最容易实现的多智能体架构，特别适合流程固定、角色明确、由多个步骤组成的任务。

• Agent Orchestration 采用 Hub-and-Spoke结构，由一个主 Agent 负责规划与协调多个专业 Worker Agent，将原本的工具调用升级为多智能体协作。

• Agent Collaboration 则将多个 Agent 组织成真正的团队，它们能够彼此交流、相互反馈、共同推理，从而解决更加复杂的问题，但同时也会带来更高的计算成本和响应延迟。

• AI Agent 标志着软件开发范式正在发生变化——系统逐渐从传统编程转向以自然语言驱动的智能交互，使开发者能够从 Prompt Engineering 一路扩展到真正可投入生产环境的 Agent 架构设计。