生成式人工智能编程快速提升指南-全-

生成式人工智能编程快速提升指南（全）

原文：Supercharged Coding with GenAI: From vibe coding to best practices using GitHub Copilot, ChatGPT, and OpenAI

译者：飞龙

协议：CC BY-NC-SA 4.0

前言

我们正处于人工智能（AI）加速变革的时代，模型不再是被动的工具，而是积极的决策者。自 2022 年 11 月 ChatGPT 发布以来，世界见证了地震般的转变：不仅在大语言模型（LLMs）的能力上，而且在人工智能在现实世界系统中的架构、集成和运营方式上。

一个新的范式已经出现——人工智能代理。与传统的 AI 工作流程不同，代理为应用程序带来了持久性、自主性和以目标为导向的推理。它们可以规划、记忆、使用工具，并与其他代理或人类互动以完成复杂任务。从客户服务到研发，从编排 API 到驱动个性化工作流程，人工智能代理正在重塑我们对软件和智能的看法。

本书是一本实用的指南，旨在理解和构建人工智能代理，涵盖了它们的架构、关键组件和实际应用案例。无论你是开发者、架构师、产品经理还是人工智能爱好者，本书旨在为你提供利用自主代理能力的坚实基础和实践技能。

本书分为三个部分：

第一部分，人工智能工作流程的基础和人工智能代理的兴起，探讨了自生成模型兴起以来人工智能工作流程的演变，从简单的 API 调用到更智能、更自主的行为的转变。它介绍了人工智能代理的概念、它们的成分——LLMs、工具、记忆和上下文，并强调了在各个行业中日益增长的对于代理系统的需求。
第二部分，设计、构建和扩展人工智能代理，深入探讨了代理开发的实际方面。它涵盖了人工智能编排工具、记忆和上下文处理、工具集成和代理可观察性。本部分还通过使用 LangChain 和 LangGraph 等框架，以及电子商务助手和客户支持代理等实际案例，指导你构建单代理和多代理应用程序。
第三部分，通往开放、代理生态系统之路，展望了塑造智能软件未来的协议、平台和原则。它涵盖了新兴的开放标准，如 MCP、A2A 和 NLWeb，并讨论了如何构建适用于企业规模部署的负责任、安全且成本效益高的代理系统。它还将涵盖负责任的人工智能实践，包括评估、安全机制和人工监督。

这本书面向的对象

这本书是为开发者、架构师、创新领导者和研究人员而写的，他们希望释放人工智能代理的潜力。无论你是构建基于代理的工作流程的软件工程师，还是设计智能助手的产产品所有者，或者希望将自主决策嵌入到你的系统中的商业策略家，这本书都提供了你开始并扩展所需的框架、示例和工具。

本书涵盖的内容

第一章，GenAI 工作流程的演变，追溯了自 2022 年底以来 AI 工作流程的转变，从简单的 API 交互到检索增强生成（RAG）。它探讨了最近的突破，如微调、模型蒸馏和基于人类反馈的强化学习（RLHF），并介绍了需要更多自主和代理行为的必要性。

第二章，AI 代理的兴起，定义了 AI 代理是什么以及它们与之前的自动化范式（如 RPA）有何不同。它介绍了不同类型的代理及其架构的关键组件，包括系统消息、工具、内存和数据。

第三章，对 AI 编排器的需求，探讨了在基于 LLM 的应用中编排层的新兴角色。它比较了流行的编排器，描述了它们的组件，并提供了关于选择适合您需求的正确编排器的指导。

第四章，对记忆和上下文管理的需求，深入探讨了代理如何通过各种类型的记忆（短期、长期、情景和语义）存储、检索和更新信息，以及管理上下文窗口和利用向量数据库的技术。

第五章，对工具和外部集成的需求，探讨了代理如何使用 API、数据库和第三方服务与世界互动。它还讨论了异步调用与同步调用之间的区别，以及如何通过监控和日志记录启用可观察性。

第六章，使用 LangChain 构建您的第一个 AI 代理，指导您使用 LangChain 构建自己的单代理应用程序，包括两个实际用例：电子商务助手和客户支持代理。

第七章，多代理应用，探讨了多个代理协同工作时会发生什么。它涵盖了设计模式，如群聊、分层和顺序协调，介绍了 LangGraph 和 AutoGen 等编排器，并指导您构建您的第一个多代理系统。

第八章，编排智能：下一代代理协议蓝图，介绍了旨在定义智能网络下一层以实现互操作性的新兴标准和协议——如 MCP、A2A、ACP 和 NLWeb。

第九章，在现实世界 AI 中的伦理挑战导航，强调了负责任地设计代理系统的关键重要性。它涵盖了评估策略、安全过滤器、成本控制和实施护栏以及人机交互系统以确保自主 AI 代理的安全和道德部署。

为了充分利用这本书

如果您记住以下几点，跟随起来会更容易：

通过动手实践学习：许多章节包括现实场景和实际练习。尽可能通过构建自己的 AI 代理（使用 LangChain 和 LangGraph 等框架）并尝试使用 API、向量数据库和编排器部署它们来跟随。
尝试不同的代理行为：代理设计并非一刀切。修改工具、记忆策略和工作流程，看看它们如何影响结果。尝试不同的架构——单一代理、多代理和分层——以探索它们的优点和权衡。
探索开源工具和编排框架：本书涵盖了广泛的技术。花时间深入研究 LangChain、LangGraph 和 LangSmith 的文档，了解如何扩展和微调您自己的实现。
超越基础：代理范式仍在快速发展。将本书作为跳板，但保持对最新协议、研究论文和 LLM 编排、工具使用和代理协作的进步的最新了解，以深化您的专业知识。

这里是一份您需要拥有的清单：

| 本书涵盖的软件/硬件 | 系统要求 |

| --- | --- |

| Python 3.10 或更高版本 | Windows, macOS, 或 Linux |

| Node.js | Windows, macOS, 或 Linux |

| LLM 聊天和嵌入模型 | Windows, macOS, 或 Linux 您可以选择利用您选择的 LLM。本书中，我们将使用 Azure OpenAI 或 OpenAI 的 GPT-4o。其他选项包括但不限于以下内容：Hugging Face HubAnthropicGemini |

下载示例代码文件

本书代码包托管在 GitHub 上，网址为github.com/PacktPublishing/AI-Agents-in-Practice。我们还有其他丰富的图书和视频代码包，可在github.com/PacktPublishing找到。请查看它们！

下载彩色图像

我们还提供了一份包含本书中使用的截图/图表彩色图像的 PDF 文件。您可以从这里下载：packt.link/gbp/9781805801351。

使用的约定

本书使用了多种文本约定。

CodeInText: 表示文本中的代码单词、数据库表名、文件夹名、文件名、文件扩展名、路径名、虚拟 URL、用户输入和 X 处理。例如，“在localhost:3000上启动一个模拟 JSON 服务器以启用购物车管理工具。”

代码块设置如下：

from langchain_huggingface import HuggingFacePipeline
llm = HuggingFacePipeline.from_model_id(
    model_id="microsoft/Phi-3-mini-4k-instruct",
    task="text-generation",
    pipeline_kwargs={
        "max_new_tokens": 100, "top_k": 50,
        "temperature": 0.1,
    },
)
llm.invoke("Your query here")

粗体：表示新术语、重要单词或您在屏幕上看到的单词，例如在菜单或对话框中。例如：“LangChain 于 2022 年 10 月推出，是一个开源框架，旨在简化由大型语言模型（LLMs）驱动的应用程序的开发。”

警告或重要提示如下所示。

小贴士和技巧看起来像这样。

关于 AI 使用的免责声明

作者承认使用了尖端 AI，如 ChatGPT 和 GitHub Copilot，其唯一目的是增强书中的语言和清晰度，从而确保读者有一个顺畅的阅读体验。重要的是要注意，内容本身是由作者创作的，并由专业出版团队编辑。

联系我们

我们始终欢迎读者的反馈！

一般反馈：请发送电子邮件至 feedback@packtpub.com，并在邮件主题中提及书籍标题。如果你对本书的任何方面有疑问，请通过电子邮件联系我们在 questions@packtpub.com。

勘误：尽管我们已经尽一切努力确保内容的准确性，但错误仍然可能发生。如果你在这本书中发现了错误，我们将不胜感激，如果你能向我们报告这个错误。请访问 www.packtpub.com/submit-errata，点击 提交勘误 并填写表格。

盗版：如果你在互联网上以任何形式发现我们作品的非法副本，如果你能提供位置地址或网站名称，我们将不胜感激。请通过电子邮件联系我们在 copyright@packtpub.com，并提供材料的链接。

如果你有兴趣成为作者：如果你在某个领域有专业知识，并且你感兴趣的是撰写或为书籍做出贡献，请访问 authors.packtpub.com/。

分享你的想法

一旦你阅读了《实践中的 AI 代理》，我们很乐意听听你的想法！请点击此处直接访问此书的亚马逊评论页面并分享你的反馈。

你的评论对我们和科技社区都很重要，并将帮助我们确保我们提供高质量的内容。

加入我们的 Discord 和 Reddit 空间

你不是唯一一个在导航碎片化工具、不断更新和不确定的最佳实践的人。加入一个不断壮大的专业社区，分享那些没有进入文档的见解。

| 通过了解我们的作者提供的更新、讨论和幕后洞察，保持信息畅通。加入我们的 Discord 空间，请访问 packt.link/z8ivB 或扫描下面的二维码！ | 在 Reddit 上与同行交流，分享想法，并讨论现实世界的通用人工智能挑战。关注我们，请访问 packt.link/0rExL 或扫描下面的二维码： |

| --- | --- |

你的书籍附带独家优惠 - 这就是解锁它们的方法

现在解锁这本书的独家优惠

扫描此二维码或访问 packtpub.com/unlock，然后通过名称搜索这本书。确保它是正确的版本。 | |

| 注意：开始之前请准备好您的购买发票。 |

| --- |

使用我们的下一代阅读器增强阅读体验：

多设备进度同步: 通过无缝进度同步，在任何设备上学习。

高亮和笔记: 将你的阅读转化为持久的知识。

收藏: 任何时候都可以回顾你最重要的学习内容。

深色模式: 通过切换到深色或棕褐色模式，以最小的眼部疲劳来集中注意力。

使用我们的 AI 助手（测试版）更智能地学习：

总结: 总结关键部分或整章内容。

AI 代码解释器: 在下一代 Packt 阅读器中，点击每个代码块上方的解释按钮，获取 AI 驱动的代码解释。

注意：AI 助手是下一代 Packt 阅读器的一部分，目前处于测试版。

任何时间、任何地点学习：

使用无 DRM 的 PDF 和 ePub 版本离线访问你的内容——与你的最爱电子阅读器兼容。

解锁您书籍的专属好处

您的这本书附带以下专属好处：

下一代 Packt 阅读器

人工智能助手（测试版）

无 DRM PDF/ePub 下载

如果你还没有解锁，请使用以下指南进行解锁。这个过程只需几分钟，并且只需要做一次。

如何通过三个简单步骤解锁这些好处

第 1 步

准备好这本书的购买发票，因为在第 3 步中你需要它。如果你收到了实体发票，请用手机扫描它，并准备好作为 PDF、JPG 或 PNG 格式。

如需查找发票的更多帮助，请访问 www.packtpub.com/unlock-benefits/help。

注意: 你是否直接从 Packt 购买了这本书？你不需要发票。完成第 2 步后，你可以直接跳转到你的专属内容。

第 2 步

扫描此二维码或访问 packtpub.com/unlock。 | |

在打开的页面（如果你在桌面电脑上，它将类似于图 0.2），通过名称搜索这本书。确保你选择了正确的版本。

图 0.2：桌面上的 Packt 解锁页面

第 3 步

登录您的 Packt 账户或免费创建一个新账户。登录后，上传您的发票。它可以是以 PDF、PNG 或 JPG 格式，且大小不能超过 10 MB。按照屏幕上的其余说明完成流程。

需要帮助吗？

如果您遇到困难需要帮助，请访问www.packtpub.com/unlock-benefits/help获取如何查找您的发票及其他详细问题的 FAQ。以下二维码将直接带您到帮助页面：| |

注意：如果您仍然遇到问题，请联系customercare@packt.com。

第一部分

人工智能工作流程的基础与人工智能代理的兴起

在本书的第一部分中，我们探讨了自 2022 年末大型语言模型（LLMs）兴起以来人工智能发展的演变，直至人工智能代理作为新的架构范式出现。

本部分首先追溯了人工智能工作流程的转变——从简单的 API 调用到更动态的系统，如检索增强生成（RAG）——并突出了关键技术突破，如微调、模型蒸馏和基于人类反馈的强化学习（RLHF）。它介绍了代理行为作为构建智能、目标驱动系统的下一个前沿概念。

然后，我们深入探讨什么构成了人工智能代理：它与传统自动化有何不同，使其成为可能的组件（LLMs、工具、记忆和知识），以及为什么该领域正迅速汇聚于更自主、交互式的系统。

你还将了解人工智能代理如何建立在 LLMs 的基础上，同时融入新的智能和协调层，为更个性化、持久和任务导向的人工智能应用奠定基础。

本部分包含以下章节：

第一章，通用人工智能工作流程的演变
第二章，人工智能代理的兴起

第一章：通用人工智能（GenAI）工作流程的演变

在过去的两年里，大型语言模型（LLMs）重塑了人工智能的格局。从简单的基于提示的交互到跨行业的复杂应用，LLMs 迅速发展，得益于架构、训练技术和微调策略的突破。随着它们能力的提升，从 ChatGPT 到截至 2025 年 4 月的当前代理系统的发展，标志着自然的发展进程，其中推理、规划和采取行动的能力的添加代表了一次重大的技术飞跃。

本章探讨了 LLMs 的基础，它们是如何构建和使用的，以及预训练模型和微调模型之间的差异。最重要的是，它为下一次飞跃奠定了基础：人工智能代理的出现。

在本章中，我们将涵盖以下主题：

理解基础模型和大型语言模型（LLMs）的兴起
最新重大突破
人工智能代理之路
需要额外一层智能：介绍人工智能代理

在本章结束时，你将清楚地了解 LLMs 是如何演化的，它们是如何被训练和部署的，以及为什么通往真正智能系统的道路不可避免地会导致人工智能代理的出现。

技术要求

你可以在本书附带的 GitHub 仓库中找到本章的完整代码：github.com/PacktPublishing/AI-Agents-in-Practice。

理解基础模型和大型语言模型（LLMs）的兴起

人工智能得益于基础模型的出现而经历了根本性的转变——这些模型是通用的、多功能的，可以适应广泛的任务。其中，LLMs 占据了中心舞台，重新定义了我们通过自然语言与机器互动的方式。

从窄 AI 到基础模型

在基础模型兴起之前，人工智能领域由窄 AI主导——这些系统被构建来执行一个特定的任务，没有其他功能。每个用例都需要一个定制的流程：一个独特的数据集、一个专用的模型架构和专门的训练程序。如果你想将电子邮件分类为垃圾邮件或非垃圾邮件，你会构建一个垃圾邮件过滤器。如果你需要从文档中提取名称和地点，你会创建一个命名实体识别器。想要总结一篇新闻文章？那就意味着又要创建一个定制的模型。

这种碎片化的方法有几个缺点。模型很脆弱——只有在它们被训练的狭窄领域内才能表现良好——并且维护成本高昂。任务或数据分布的任何变化通常意味着从头开始重新训练。

基础模型的引入标志着我们在构建和思考人工智能系统方面的根本转变。这些模型在涵盖多个领域和任务的大量且多样化的数据集上进行训练。其理念是在大规模的预训练阶段教会单个模型对世界的普遍理解——它的语言、结构和模式。一旦这种普遍知识被嵌入，模型就可以通过最小量的额外数据和计算来适应特定任务。

例如，我们不再需要为从法语翻译成英语构建一个单独的模型，现在我们可以使用一个预训练的基础模型，并在一个较小的翻译数据集上进行微调。预训练模型已经理解了语言语法、语法和意义。微调只是将这种理解与特定目标对齐。

基础模型背后的关键创新是迁移学习。这些模型不是从头开始学习，而是将通用训练中获得的知识迁移到特定问题上。这大大提高了效率，减少了所需标记数据量，并导致更稳健和灵活的人工智能系统。

此外，基础模型不仅仅是关于语言。它们适用于多种模态：一些模型不仅可以处理和生成文本，还可以处理图像、音频或代码。

从本质上讲，基础模型充当人工智能的“基础大脑”——一旦训练，就可以多次重新部署。这种可扩展性和适应性为我们构建智能系统开辟了全新的可能性，为更自主和交互式的应用，如人工智能代理，奠定了基础。

现在，我们提到基础模型能够管理各种数据格式。在基础模型集群中，我们可以找到专注于单一数据类型的特定模型，这就是 LLMs 的情况。

图 1.1：LLMs 的特征

LLMs 本质上是大模型的语言专用版本。它们建立在深度神经网络架构——特别是变换器——之上，并训练以预测序列中的下一个单词。但这个看似简单的目标解锁了令人惊讶的演化行为。LLMs 可以进行对话，回答复杂的问题，编写代码，甚至模拟推理。

定义

演化行为是在系统达到一定规模时意外出现的复杂能力，即使那些能力并没有被明确编程或预期。在 LLMs 的背景下，这些行为在模型在数据、参数和训练时间上扩展时出现——解锁了较小版本中不存在的新能力。

随着模型规模的扩大，它们开始表现出演化特性，包括以下内容：

上下文学习：大型语言模型（LLMs）可以通过在提示中展示几个示例来学习执行任务，而无需任何微调。这在较小的模型中是看不到的。
思维链推理：通过生成中间推理步骤，LLM 可以解决多步问题，如数学文字题或逻辑谜题——这是它们之前难以解决的问题。
类比推理：它们可以以类似于人类认知处理的方式解决类比问题（例如，“猫对幼猫就像狗对...”）。
算术和逻辑：在规模上，LLM 具备处理多位数算术或逻辑谜题等任务的能力，即使这些任务并非其训练目标的一部分。
理解隐喻和幽默：高级 LLM 可以解释新的隐喻，甚至尝试讲笑话——显示出对语言和细微差别的抽象理解。
多任务泛化：它们不是为单一特定任务训练的，可以同时处理翻译、摘要、问答等更多任务——无需针对特定任务进行训练。

这些能力不仅仅代表更好的性能——它们是质的变化，仅在规模上“出现”，赋予 LLM 意想不到的广泛技能，并在各个领域产生实际影响。

LLM 的内部机制

每个 LLM 的核心都是一个强大的神经网络架构——最常见的是变换器。这些网络旨在通过学习数十亿文本示例中的统计关系来处理和理解数据中的模式，尤其是人类语言。虽然灵感来源于人脑的结构，但 LLM 完全通过数学运行，通过相互连接的层传递信息，这些层在模型训练过程中会进行适应。

要使语言可计算，第一步是将其转换为数字，因为神经网络无法处理原始文本。这通过两个关键步骤——分词和嵌入——来完成：

分词将句子分解成更小的块，称为标记。这些可以是完整的单词或单词的一部分，具体取决于模型。例如，“The cat sat on the mat”可能会根据使用的分词器被拆分成单个单词或更小的子词单元。
嵌入将这些标记映射到高维向量——一串编码其意义和与其他词语关系的数字。这些嵌入在训练过程中学习，以便相似的词语最终出现在模型“语义空间”的相似区域。这有助于模型理解上下文和词语用法，例如“巴黎”和“伦敦”作为城市之间的关系。

图 1.2：嵌入示例

一旦输入被分词并嵌入，它就会通过transformer 网络本身。与只有几个隐藏层的传统神经网络不同，LLMs 使用数十甚至数百个堆叠的层，每个层都包含称为注意力头的机制。这些注意力层帮助模型决定哪些输入部分与给定的预测最相关。例如，当完成一个句子时，模型会学会更多地关注那些影响接下来应该出现的内容的特定先前单词。

训练 LLM 意味着教会它在一段时间内做出更好的预测。这是通过一种称为反向传播的方法来完成的，其中模型将其预测的单词与正确的单词进行比较，计算其偏离程度，然后更新其内部参数以减少未来的错误。

定义

反向传播是训练神经网络的核心学习算法。它通过比较模型的预测与正确答案，计算误差（称为损失），然后调整网络的内部参数（权重）以减少该误差来工作。这种调整是通过“传播”误差反向通过网络的层来实现的——因此得名。随着时间的推移，这个过程有助于模型做出越来越准确的预测。

假设你输入The cat is on the...。模型通过为可能的延续，如mat、roof或sofa分配概率来预测下一个单词。它不是随机猜测——它依赖于训练期间看到的模式。

这个过程在大量的数据上重复进行——数百万或数十亿个句子——使模型能够逐渐捕捉到语言的结构和节奏。结果是，一个能够不仅完成句子，还能进行对话、解决问题，并以具有上下文感知的、通常非常流畅的语言进行响应的系统。

我们如何消费 LLMs？

一旦 LLM 的训练阶段完成，我们需要了解如何使用这个模型预测下一个标记，这个过程被称为推理。

在机器学习和人工智能的背景下，推理指的是在新的输入数据上运行训练好的模型以生成预测或响应的过程。在 LLMs 中，推理涉及处理提示并产生基于文本的输出，通常需要大量的计算资源，特别是对于大型模型。

大型语言模型（LLMs）通常可以通过 API 访问，允许开发者使用它们而无需管理复杂的基础设施。这种方法简化了集成，使 AI 驱动的应用更具可扩展性和成本效益。

OpenAI、Azure AI和Hugging Face等 LLM 提供商提供 API，可以实时处理请求并返回响应。该过程通常涉及以下步骤：

认证：开发者使用 API 密钥或 OAuth 令牌进行安全访问。

定义

身份验证是开发者证明他们的应用程序有权访问外部服务的方式。这通常是通过 API 密钥或 OAuth 令牌来完成的。API 密钥是由服务提供的一个唯一字符串——类似于密码——用于标识应用程序。另一方面，OAuth是一个更灵活的系统，允许用户授予应用程序特定的权限，作为回报发行临时访问令牌。两种方法都确保只有授权的用户或系统才能发出请求，有助于保护敏感数据和资源。
发送请求：结构化的 JSON 请求包括模型名称、提示和参数，如温度（用于随机性）。
接收响应：API 返回生成的文本输出以及元数据，如令牌使用情况。

图 1.3：LLM API 的 HTTP 请求示例

注意

一些 LLM API 支持流式响应，其中模型逐步输出令牌，而不是在发送完整响应之前等待。这种方法有助于减轻大型模型通常伴随的高延迟。通过快速交付第一块文本，流式传输减少了感知延迟——用户在看到任何输出之前等待的时间——从而带来更流畅、更响应式的体验。

现在，一个可能的问题可能是：如果我想在我的本地计算机上运行我的模型怎么办？为了回答这个问题，我们首先需要区分以下内容：

私有 LLM：这些是由 OpenAI、Anthropic 或 Google 等公司开发的专有模型。它们是封闭源代码的，这意味着您无法查看或修改其底层代码。这些模型通常只能通过 API 访问，并且带有按使用付费、基于令牌的成本。
开源 LLM（大型语言模型）：开源模型，例如 Meta 的 LlaMA、Mistral 和 Falcon，任何人都可以免费下载、修改和部署。这意味着开发者可以访问底层训练参数，在私有基础设施上运行它们，甚至可以使用底层架构从头开始重新训练模型。

然而，即使是开源 LLM，许多开发者也倾向于通过 Azure AI Foundry 和 Hugging Face Hub 等平台提供的 API 访问这些模型。

这种方法提供了几个优点：

降低基础设施成本：独立运行 LLM 需要大量的计算资源，这可能成本高昂。利用 API 将这一负担转移到服务提供商，使开发者能够利用强大的模型，而无需投资昂贵的硬件。
可扩展性：API 服务可以动态扩展以处理不同的工作负载，确保无需手动干预即可保持一致的性能。
安全和合规性：Azure AI Foundry 等平台提供企业级安全功能，帮助组织满足合规性要求并保护敏感数据。

在人工智能代理和更广泛的人工智能应用背景下，最常用的路径是通过 API 消费大型语言模型（LLMs）。例外情况可能涉及断开连接的场景（例如，在海外站点或远程位置运行 LLMs）或数据居住地的监管限制（LLM 必须位于没有公共云的特定国家）。

通往人工智能代理之路

通用人工智能（GenAI）的快速发展，使我们从简单的自动化走向了越来越智能的系统，这些系统能够进行推理、学习和决策。近年来，大型语言模型（LLMs）彻底改变了我们与周围生态系统互动的方式，使得对话更加自然，问题解决更加复杂。

让我们探索那些最终推动人工智能代理崛起的最重要的里程碑。

文本生成

自从 2022 年 11 月 ChatGPT 发布以来，用户最初采用的第一个用例就是对话式文本生成，如下所示：

“生成一个关于核裂变的入门级描述”
“草拟一封电子邮件发送给我的客户 C 级董事会，邀请他们参加我们的活动”
“列出关于人工智能文章的 10 个想法”
“生成一篇关于法国大革命的论文，我必须明天交上去”

你是否觉得上述任何场景都很熟悉？

LLMs 的文本生成能力具有颠覆性，因为它从根本上改变了人类与技术互动的方式，使 AI 能够以前所未有的流畅性和上下文理解生成类似人类的文本。

注意

在这个背景下，文本也包括代码，因为 LLMs 从一开始就展示了在生成和辅助编程任务方面的显著能力。当时，常见的代码相关任务包括代码生成、调试、优化、翻译和解释。

LLMs 在传统 AI 和自然语言处理领域引起了前所未有的转变，因为它们可以按需生成连贯、创造性和上下文相关的文本。突然之间，这样一项令人难以置信的技术对每个有互联网连接的用户都变得可用，民主化了高质量写作的获取，加速了营销和客户服务等行业的自动化，甚至通过辅助讲故事、诗歌和剧本写作来重塑创意领域。

然而，在拥有这个免费、会话式助手并似乎对世界上任何事物都了如指掌的初期热潮之后，我们很快开始意识到存在一个巨大的局限性。ChatGPT 和更广泛地说，大型语言模型的知识仅限于它们训练的数据（这是参数化知识）。现在，即使这些数据代表了整个网络，用户仍然需要处理动态、专有或利基数据集，而这些数据集并未包含在模型的训练数据中。

与你的数据聊天实际上是我们 GenAI 路线图上的下一个里程碑。

与你的数据聊天

“我想和我数据聊天。” 这句话引出了一种特定的技术，称为检索增强生成（RAG）。这种方法允许大型语言模型不仅生成文本，而且在生成响应之前从外部来源检索相关信息，确保准确性、上下文相关性和降低幻觉风险。

定义

在语言模型的背景下，幻觉指的是生成听起来合理但实际上是虚假或缺乏事实数据支持的情报。这可能会损害信任，尤其是在需要准确性的场景中。

将 LLM（大型语言模型）的范围“缩小”到预定义的知识库的过程被称为归一化。RAG（检索增强生成）的一个关键部分是向量数据库（向量 DB），它使用称为嵌入的向量表示有效地存储和检索信息。这使得 LLM 能够搜索语义相关的信息，而不仅仅是精确的关键词匹配。

让我们分解这个技术的每一步：

检索或查找相关信息：RAG 不是仅仅依赖于预训练的知识，而是首先从已经适当向量化的外部知识库中检索相关数据。这可能包括 PDF 文件、Word 文档、报告、研究论文、结构化记录、表格、内部档案等等。

当你提问时，RAG 管道将其本身转换为向量，并通过计算用户向量化的查询与知识库向量化的片段之间的距离函数，在数据集中搜索最相关的信息。由于嵌入的计算方式，数学距离越低，语义相似度越高。这一步骤确保 AI 不仅仅是根据记忆生成响应，而是积极从您的数据中检索最相关和最新的信息。

增强—增强 AI 理解：一旦系统检索到相关文档，它们就会与原始查询一起输入模型。这一步骤通过提供上下文丰富的输入来增强 AI 的理解。

与猜测或依赖一般知识不同，AI 现在有了基于具体上下文的、有根据的信息来作为其回答的基础。这个过程确保了模型的输出如下：

更精确，因为它直接引用相关数据
更可解释，因为响应有可检索的来源作为支持
更不容易产生幻觉，因为 AI 在经过精心策划和有根据的上下文中生成文本

生成—创建上下文感知的响应：有了增强的上下文，AI 随后生成一个更信息丰富、更准确且与检索到的数据一致的响应。最终输出如下：
- 实事求是，因为它结合了检索到的知识
- 上下文感知，针对您的特定数据集定制
- 可引用的，意味着在需要时可以提供引用或源链接

这一步骤确保响应不仅仅是 AI 生成的答案，而是基于从您的数据中检索和增强的知识专门定制的。

在接下来的章节中，我们将更详细地介绍 RAG 及其在代理系统中的作用。

到目前为止，我们只谈论了文本数据，但如果我们想用图像、视频或音频与我们的模型交互呢？

多模态

在 GenAI（生成式人工智能）中，多模态指的是模型能够处理和生成多种类型的数据内容的能力，如文本、图像、音频和视频。多模态 LLMs（MLLMs）通过结合多种模态扩展了传统 LLMs 的功能，允许更全面的理解和更丰富的交互。

最近的发展，如 OpenAI 的 GPT-4V 和 Google 的 Gemini，展示了 MLLMs 如何在一个工作流程中分析图像、生成字幕、处理语音输入，甚至在不同格式中进行推理。

LMMs（语言模型）的关键特征是它们与仅文本的 LLMs 共享泛化和适应的能力。然而，LMMs 能够通过模仿人类与周围生态系统互动的方式——即通过所有我们的感官——处理异构数据。

多模态模型的绝佳例子是 OpenAI 的 GPT-4o，它能够通过文本、图像和音频与用户进行交互。让我们看看几个使用图像的例子：

图 1.6：ChatGPT 对图像进行推理的示例

如您所见，该模型能够分析图像并对它进行推理。现在让我们要求模型生成一幅插图：

图 1.7：ChatGPT 改变图像风格的示例

关于 LMMs 最有趣的事实是它们保留了它们的推理能力，这使得它们适合在异构数据环境中进行复杂的推理。让我们考虑这个最后的例子（只显示响应的第一行）：

图 1.8：ChatGPT 对谜题进行推理并解决问题的示例

如您所想象，这为各个行业打开了应用前景，我们将在接下来的章节中看到一些具体的例子。

需要额外的智能层：引入 AI 代理

LLMs（大型语言模型）在生成连贯文本、回答问题和甚至进行有限的问题解决方面展示了令人印象深刻的性能。然而，当涉及到实际应用时，它们的基本设计存在一些限制：

缺乏长期记忆：大多数 LLMs 在固定的上下文窗口内运行，这意味着一旦上下文限制被超过，它们就会忘记之前的交互。这使得它们无法从过去的经验中学习或随着时间的推移保持连续性。
没有持久的目标或自主性：LLMs 对单个提示做出反应，但它们没有以持久的目标导向心态运行。它们不能主动做出决定、自我纠正或随着时间的推移改进其方法。
有限的推理和多步执行：虽然 LLMs 可以在单个提示中遵循指令，但它们在执行多步工作流程、处理复杂决策以及在整个交互中保持逻辑一致性方面存在困难。
无法与外部系统交互：没有额外的集成，大型语言模型（LLMs）无法检索实时信息，调用 API，操作数据库，或执行超出基于文本输出的动作。

为了解决这些挑战，AI 代理引入了一个额外的智能层，使模型能够自主行动、通过任务进行推理、与外部环境交互并从过去的交互中学习。

在下一章中，我们将定义人工智能代理的结构。然而，你可以将其视为一个系统，它结合了 LLM 以及额外的能力，如记忆、计划和多步推理，以最小的人为干预执行任务，从而实现高度自主。与仅生成静态响应的标准 LLMs 不同，AI 代理可以执行以下操作：

通过保持记忆和随时间调整其行为来跨交互持久化
将复杂任务分解为更小的步骤并按顺序执行
与工具和 API 交互以检索实时数据、自动化工作流程并采取有意义的行动
基于学习到的知识、目标和约束自主做出决策

在其核心，AI 代理作为智能助手，能够处理超越简单问答的复杂任务。我们将在接下来的章节中详细探讨它们。

摘要

在过去两年中，人工智能经历了深刻的变革，从简单的 LLM API 调用转变为更复杂、交互式和自主的系统。LLMs 的快速进化以 RAG、微调进步和以推理为重点的架构等创新为标志，所有这些创新都旨在提高效率、适应性和成本效益。

尽管取得了这些进展，但仅凭 LLMs 本身不足以满足对能够自主运行、做出决策并与环境有意义交互的人工智能系统的日益增长的需求。

这种转变标志着人工智能发展的一个关键时刻，其重点不再仅仅是使模型更大，而是使它们更智能。我们不再将 AI 视为一个被动工具，它对孤立的提示做出反应，我们现在正在设计智能体系统，这些系统能够行动、学习和适应复杂的现实世界任务。

在下一章中，我们将探讨人工智能代理的出现、它们的主要组件以及它们可能采取的各种形式。

参考文献

《知识蒸馏：综述》：arxiv.org/pdf/2006.05525
OpenAI o1：en.wikipedia.org/wiki/OpenAI_o1?utm_source=chatgpt.com
推理语言模型：蓝图：arxiv.org/abs/2501.11223
LoRA: arxiv.org/abs/2106.09685
适配器调整：arxiv.org/abs/2304.01933
前缀调整和提示调整：ericwiener.github.io/ai-notes/AI-Notes/Large-Language-Models/Prompt-Tuning-and-Prefix-Tuning

现在解锁此书的独家优惠

扫描此二维码或访问 packtpub.com/unlock，然后通过书名搜索此书 | |

| 注意：请在开始之前准备好您的购买发票。 |

| --- |

第二章：人工智能代理的兴起

本章将探讨人工智能代理的演变，追溯其从早期的机器人流程自动化（RPA）系统到今天复杂的多代理架构的根源。我们将定义什么是人工智能代理，分解其基本组件，并检查正在塑造全球行业的不同类型的 AI 代理。

在本章中，我们将涵盖以下主题：

从 RPA 到人工智能代理的演变
人工智能代理的定义
不同类型的 AI 代理
人工智能代理的组件

到本章结束时，你将清楚地了解人工智能代理的演变、它们的关键组件以及它们如何改变行业。

技术要求

你可以在本书附带的 GitHub 仓库中找到本章的完整代码：github.com/PacktPublishing/AI-Agents-in-Practice。

从 RPA 到人工智能代理的演变

从传统的基于规则的自动化到复杂的 AI 驱动代理的转变，标志着重大的技术进步。最初，自动化仅限于僵化的、预定义的工作流程，但随着机器学习、强化学习和大型语言模型（LLMs）的兴起，AI 代理已经发展到更加自主、智能，并且能够做出复杂的决策。让我们看看近几十年来代理的不同风味。

机器人流程自动化（RPA）：这代表了自动化最早的阶段，专注于基于规则的系统，旨在执行预定义的任务。这些系统遵循严格的逻辑流程，根据明确的条件和结构化输入执行操作。虽然对于重复性流程有效，但 RPA 缺乏灵活性、适应性和处理非结构化数据的能力。以一个基于规则的聊天机器人为例，它遵循严格的决策树，但不从交互中学习；然而，它无法处理动态环境或意外输入。
基于传统机器学习/强化学习的代理：随着人工智能的发展，传统的机器学习（ML）和强化学习（RL）代理开始出现。这些代理可以从数据中学习，根据概率模型做出决策，并通过试错来优化其行为。让我们双击查看这两个方面：
- 基于规则的代理：这些代理从静态规则集过渡到基于机器学习的模型，可以根据训练数据对结果进行分类和预测。
以一个早期的客户支持聊天机器人为例，它遵循严格的决策树来响应用户查询，并通过命名实体识别机制进行路由。

定义

命名实体识别 (NER) 是一种自然语言处理 (NLP) 任务，它能够识别和分类文本中的关键信息，例如人名、组织机构、地点、日期以及其他预定义实体。

强化学习 (RL) 智能体：这些智能体通过与环境的交互学习，优化长期奖励的行动。强化学习智能体在游戏、机器人和复杂问题解决领域得到了广泛应用。

例如，DeepMind 的 AlphaGo 通过模拟数百万次游戏并通过试错优化策略来学习玩围棋。

然而，这些早期智能体有一个主要缺陷：泛化能力有限。以 AlphaGo 为例——虽然它通过数百万次模拟比赛掌握了围棋，但其智能是狭窄且特定领域的。AlphaGo 无法将其知识应用于其他棋类游戏，如国际象棋，或处理与客户服务或调度无关的任务。这种人工智能在严格限定的环境中可能表现出色，但规则、上下文或输入模式发生变化时无法适应。

这种缺乏灵活性揭示了人工智能领域的一个更广泛挑战：需要能够跨领域推理、理解模糊指令并实时适应动态环境的智能体。

正是在这里，基于 LLM 的智能体发挥了作用。

基于大型语言模型 (LLM) 的智能体：随着 LLM 的出现，人工智能智能体在推理、规划和动态交互方面变得更加有能力。生成式人工智能使这些智能体不仅能够回答查询，还能综合信息、自动化工作流程并集成各种外部系统——正如我们将在本章中详细看到的那样。

从高层次来看，基于 LLM 的智能体的力量在于它们可以利用 GPT-4o 等模型不仅理解上下文和检索相关信息，还可以协调一组组件，使智能体能够与周围环境交互。这是区分现代人工智能智能体与先前 RPA 系统以及 LLM 本身的“额外智能层”。

此外，当我们利用大型多模态模型时，人工智能智能体可以整合不同的模态，如文本、语音、视觉和结构化数据，以更人性化的方式进行交互。

例如，您可以将基于 LLM 的智能体想象成一个零售助理，它可以实时处理口头问题、分析产品图像并查询库存数据库。

多智能体系统和自我复制智能体：人工智能智能体进化中的一个重大突破是引入了多智能体系统，其中多个智能体协作解决复杂任务。这些系统允许任务委派、专业化和并行执行，从而提高效率和自主性。例如，一个多智能体研究系统中，一个智能体检索论文，另一个总结它们，第三个为团队生成可操作的见解。

此外，我们还可以为这些代理提供“自我复制”的能力，这意味着它们可以生成额外的代理来处理子任务，有效地扩展自身以满足需求。以一个 AI 项目经理为例，它可以生成专门的子代理来处理软件开发工作流程中的设计、编码和测试。

AGI 代理——下一个前沿：人工智能进化的最终目标是开发通用人工智能（AGI）代理——能够执行人类可以执行的任何智力任务的系统。AGI 代理将整合推理、规划、记忆和自我改进，以在广泛的应用中自主运行。

在撰写本书时，这仍然是一种尚未完全被普遍认可的理解，但见证人工智能代理不断演变的边界是一个令人兴奋的时刻。

在本书中，我们将主要关注基于单个、LLM 的代理，并在第七章中涉及多代理框架。让我们先定义一下什么是人工智能代理。

人工智能代理的组成部分

AI 代理是一个基于软件的实体，能够感知其环境，推理其目标，做出决策，并通过与外部系统的交互执行行动——通常是自主地。与遵循预编程规则的传统自动化不同，AI 代理可以根据上下文动态适应，利用外部工具，并整合记忆以随着时间的推移改进决策。

在技术层面上，人工智能代理由几个核心组件组成：

LLM：代理的推理引擎，提供自然语言理解、响应生成和任务规划。像 GPT-4、Claude 和 Gemini 这样的 LLM 使代理能够处理用户输入、生成响应，甚至进行多步推理。
系统消息：将系统消息视为代理的“使命”，因为它提供了塑造代理行为的底层指令。除了主要目标外，系统消息还定义了语气、角色和约束（例如，“你是一位客户支持助理；简洁而富有同情心地回应”）。
记忆：使代理能够在时间上保持上下文，提高连续性和个性化。从高层次来看，记忆可以分为短期（基于会话的）和长期（存储过去交互的数据库）。然而，代理记忆有许多细微差别，包括短期、情景和程序性，我们将在第四章中探讨。
工具：扩展代理的能力，使其超越 LLM。代理与外部工具（如 API、数据库、搜索引擎和自动化脚本）交互，以获取实时数据、执行计算或触发外部过程。
知识库：存储代理可以参考的结构化和非结构化领域知识。这包括检索增强生成（RAG）系统、专有公司数据或用于增强决策的专业知识库。

图 2.1：AI 代理的主要组件

此外，我们还有一个编排层，旨在管理代理内部的任务流程，确保组件之间的协调。

备注

人工智能代理可能具有用户界面，也可能不具有。一方面，代理可以是面向用户的对话应用，根据用户的输入做出反应（例如，客户服务 AI 代理针对用户关于特定产品的查询）。另一方面，它们也可能在自动化工作流程中“幕后”操作；如果是这种情况，它们可能根本不需要用户界面，因为它们是由事件触发的（例如，每当在记录系统中提交工单时，提供问题解决方案的 AI 代理）。

让我们考虑以下示例。想象一个学术机构开发了一个 AI 代理，旨在帮助高中生掌握复杂的 STEM 主题。通过利用大型语言模型、记忆和编排，这个代理提供个性化辅导，引用权威来源，并适应每个学生的学习需求。

图 2.2：AI 辅导助手的示例

让我们逐一关注每个组件：

LLM：这作为核心推理引擎，是代理的“大脑”，以对话方式提供解释、解决问题和回答学生问题——所有这些都归功于代理组件提供的附加信息。

备注

记住这一点很重要，即大型语言模型（LLMs）通常是在公共或通用数据集上训练的。这意味着除非明确地基于此类信息进行训练，否则它们往往缺乏对特定行业、专有数据或组织流程的深入上下文理解。这就是为什么提供与特定用例相关的外部知识库可以使代理具备特定领域的知识，从而提高其在现实场景中的准确性、可靠性和实用性。

系统消息：这定义了代理的性格，确保它与其教育目的保持一致（毕竟，我们不希望 AI 辅导代替学生做作业，而是一个在学习过程中支持他们的助手，强化他们的弱点，专注于特定的学习领域）。
编排：这确保了 UI、LLM 和各个组件之间的顺畅交互。它智能地路由请求，决定何时检索外部数据、参考存储的学生表现历史，或直接从 LLM 生成内容。
记忆：这跟踪学生的聊天会话以保持对话的相关性（短期）。此外，它存储以前学生的互动，以便了解他们的学术背景。这种知识允许代理使用优势和劣势数据来强化有挑战性的主题并优化课程计划。
知识：代理需要检索以回答特定问题的相关知识被存储。如果我们需要将模型建立在特定的文档集上（例如，学校的手册），这尤其有用。
工具和 API 集成：这是我们为代理提供工具以执行操作的地方。一个例子可能是学生和学校的日历。这将允许代理代表学生预订课程，根据可用性和与学术课程的兼容性。
UI（学生界面）：这提供了一个基于聊天的交互式学习体验，整合了文本、图表和逐步解决问题的过程。

这里是如何在实际中工作的：

学生提出了一个关于牛顿力学的复杂物理问题。
LLM处理查询，使用先前的交互和上下文记忆。
协调器确定答案是否需要参考材料、过去学生的表现数据或外部网络搜索。
如果需要，代理会从学校的参考手册中检索相关信息。
LLM 会根据学生的水平定制解释，强化他们在过去考试中遇到的困难区域。
学生会收到一个交互式响应，包括逐步解释、视觉辅助工具和实践问题。
最终，代理会根据其日历为学生提供在可用时间段内预订一些额外课程的选项。
如果学生接受，代理将代表他们预订课程。

现在，问题是：代理如何知道何时调用特定的知识或特定的工具？

使这一机制如此强大的原因是语言模型理解自然语言的能力。每次初始化工具或组件——比如“安排会议”动作——它不仅仅由其底层逻辑（例如，向日历添加事件的 API 调用和 POST 请求）定义。它还伴随着一个自然语言描述。这个描述用简单明了的语言解释了工具的功能和它返回的输出类型。LLM 读取这个描述，并据此决定在任务中何时以及如何调用工具。本质上，模型不仅仅是执行代码——它是根据其人类可读的描述在可用的动作中进行推理。

图 2.3：用自然语言描述代理组件的示例

现在，当用户向代理提出问题时，代理——由 LLM 的头脑驱动——将去阅读所有组件的描述，并理解应该调用哪个组件来解决用户的查询。

正如我们将看到的，我们可以为代理定义不同的策略来调用适当的工具。例如，我们可能希望工具始终作为第一个调用，然后让代理决定是否需要调用其他工具。解决这种规定顺序的一种策略是简单地将其写入系统消息。例如：

您是一个有用的 AI 助手。您有权访问以下工具：

工具 A
工具 B

当您收到用户的查询时，始终调用工具 A。如果您无法使用工具 A 完成任务，则调用工具 B。确保在尝试工具 A 之前不要调用工具 B。

这些策略在编排器级别定义，正如我们将在第三章中看到的。

不同类型的 AI 代理

AI 代理具有不同层次的结构和功能，从基于检索的简单代理到完全自主的系统。了解这些不同类型有助于组织和个人选择适合特定用例的正确类型的 AI 代理。在本节中，我们将 AI 代理分为三种主要类型：检索代理、任务代理和自主代理。

检索代理

在第一章中，我们介绍了 RAG 的概念，作为 GenAI 应用中的一种技术，其中 LLM 在生成响应之前从知识库（正确嵌入并存储在 VectorDB 中）检索相关文档或片段。

检索 AI 代理建立在 RAG 的基础上，但融合了先进的代理行为，使它们更加自主和适应。事实上，我们正在向标准的 RAG 管道中添加一个额外的智能层和规划层，允许代理“策略化”如何检索最相关的信息片段。

注意

检索 AI 代理通常被称为代理 RAG。这种方法将知识来源视为“工具”，这意味着它们将附带自然语言描述，以便代理可以根据用户的查询决定调用哪个来源。一旦调用来源，检索机制将遵循与传统的 RAG 相同的模式，但我们还将拥有这一额外的智能层，可以决定是否足够回答，并在必要时调用更多来源。

让我们考虑以下示例。假设我们想要为医生构建一个 AI 助手，以便快速检索有关治疗的信息。假设医生问道：“2 型糖尿病的最新治疗方法是什么？”，让我们看看两种方法如何进行比较：

传统 RAG 方法：
- RAG 系统从数据库中检索前三个相关文章。
- 模型从这些文章中提取相关文本，并生成一个总结关键治疗的响应。
- 如果检索到的文档没有完全回答医生的问题；除非医生手动提交新的查询，否则模型无法优化搜索。

图 2.4：传统 RAG 流程

检索 AI 代理方法
- 代理检索一组初始文档并分析它们。
- 它检测到一些检索到的研究已经过时，因此它优化其搜索标准并检索更多近期出版物。
- 它识别出有关特定药物的信息差距，并检索该药物的专门研究。
- 最后，它将所有检索到的来源综合成一个全面的答案，确保相关性和完整性。

图 2.5：代理 RAG 流程

总之，代理 RAG 可以在传统 RAG 之上带来几个改进：

多步和递归检索：而不是单次检索，AI 代理会迭代地优化其搜索，将复杂查询分解成多个步骤。
情境意识：它们保持对先前交互的记忆，允许它们提出澄清问题或动态调整检索策略。
工具驱动查询执行：检索 AI 代理可以与 API、数据库或向量搜索引擎交互，使它们能够获取实时和结构化数据。
自适应知识增强：与 RAG 中的静态检索不同，AI 代理可以通过从不同来源获取信息并上下文合成来丰富响应。
自主决策：这些代理可以确定何时检索更多信息，查询哪些来源，以及如何优化其结果以获得最佳相关性。

检索代理是 AI 代理的最简单形式，但额外的智能层已经显示出对整体用户体验的巨大改进。然而，当它们能够将检索技能与可执行的任务相结合时，AI 代理的真正力量才得以显现。

任务代理

任务代理不仅限于信息检索，它们通过执行特定动作来超越信息检索。这些代理旨在自动化工作流程并替换用户的重复性任务。与检索代理不同，它们根据用户命令或外部触发执行预定义的动作。

注意

当谈论 AI 代理时，你经常会听到任务、工具、技能、插件、功能和动作等术语，这些术语是互换的，用来指代代理“做事”的能力。你也会看到不同的 AI 编排器带有不同的术语。让我们尝试获得一些清晰度：

任务定义了需要完成的事情，可以从简单的动作，如发送电子邮件，到涉及多个动作的复杂过程。

工具提供执行任务的外部手段，例如数据可视化工具创建图表或语言翻译服务翻译不同语言中的文本。

插件通过与其他平台的集成扩展功能，并且通常附带可以针对该平台执行的操作或函数（列出行、追加新记录等）。

功能概述了内部操作方法——例如，一个正确定义的 get_weather 函数将能够返回给定位置的当前天气。

技能代表代理学习到的熟练程度，通常以声明性方式（自然语言）定义。您可以将技能视为仅在需要该特定技能的情况下调用的“迷你提示”。

动作是 AI 代理针对给定情况或输入采取的切实步骤或操作。它们是代理功能和技能的实时体现，导致可观察的结果。

让我们再次考虑一个医疗保健领域的例子，这次是从普通开业医生的接待员约翰的角度来看。

约翰管理大量的预约请求。患者通过各种渠道预约访问：电话、电子邮件和在线预订系统。管理最后一刻的取消和重新安排请求既耗时又常常导致日程安排出现空缺。

约翰一天中的典型流程可能如下所示：

约翰收到患者 X 的电子邮件，要求预约并分享了一些关于日期和时间的偏好
约翰检查所需专家医生的可用性，并尝试与患者 X 的偏好匹配最早的可能时段
约翰没有找到任何匹配项，因此返回到患者 X 那里寻找替代方案
最后，约翰和患者 X 商定了一个时段，并安排了预约

如果您考虑上述步骤，它们不过是约翰为了实现目标——为医生和患者安排一个优化的预约时段——而需要执行的任务。

每当我们想要使用 AI 代理（更具体地说，是任务代理）映射和增强一个业务流程时，一个良好的实践是将人类任务转换为代理任务。让我们看看，例如，一个任务代理如何帮助约翰：

图 2.6：任务代理如何执行任务

快速提示：需要查看此图像的高分辨率版本吗？在下一代 Packt Reader 中打开此书或在其 PDF/ePub 副本中查看。

下一代 Packt Reader随本书免费赠送。扫描二维码或访问 packtpub.com/unlock，然后使用搜索栏通过书名查找此书。仔细核对显示的版本，以确保您获得正确的版本。

AI 代理自动扫描从患者 X 收到的电子邮件。它提取关键细节，如患者的姓名和联系方式、首选日期和时间以及所需的专家。
AI 代理检查可用性，调用插件（我们为代理配备的工具）到诊所的预约系统。它将患者 X 的偏好与专家的最早可用插槽相匹配。如果匹配，它将进入步骤 5。
AI 代理未找到匹配项。由于没有找到匹配项，AI 代理根据专家的日程表生成下一最佳可用插槽的列表。它还草拟了一封回复患者 X 的电子邮件，利用写作技巧，提供了建议的替代方案，但在发送之前由 John 审查和批准。
患者 X 回应一个新的偏好，然后：
1. 接受其中之一（进入步骤 5）
2. 请求新的选项，然后 AI 代理重复步骤 3。
一旦 John 和患者 X 就插槽达成一致，AI 代理将自动在系统中安排预约，利用上述相同的插件。此外，它还向患者 X 发送包含详细信息的确认电子邮件，利用电子邮件插件。最后，它更新专家的日历并通知他们预约情况。

图 2.7：实践者办公室中 AI 代理解剖结构示例

如您所见，AI 代理充当 John 的助手，处理重复的预约任务，同时他专注于面对面的患者互动。

自主代理

自主代理代表了 AI 代理中最先进的类别。与在预定义边界内操作的检索和任务代理不同，自主代理战略性地协调多个任务和检索过程，通过实时决策优化工作流程。这些代理表现出高度的自独立性、适应性和情境意识，使它们能够在最小的人为干预下执行复杂操作。

自主代理的关键区别在于它们能够：

结合检索和行动：它们既可以找到信息（如检索代理）并对其采取行动（如任务代理）。
规划和自我调整：它们根据新信息或变化的约束动态调整。
执行多步骤工作流程：它们将复杂任务分解为子任务，迭代执行并根据结果进行调整。让我们继续以 John 的诊所为例。随着诊所变得越来越繁忙，管理预约、取消和重新安排变得令人难以承受。一个任务代理帮助简化了单个操作，但现在一个自主代理接管了端到端预约过程，需要最少的监督。以下是它是如何一步一步工作的：
1. 接收和优先级排序：代理监控所有渠道（电子邮件、门户、电话记录），提取患者偏好、紧迫性和专家需求，并根据优先级对请求进行排序。例如，取消的预约会腾出一个空位，代理会立即将其与等待类似时间的患者 X 匹配。
2. 规划和优化：它审查完整的每日日程，识别冲突或空闲时段，并构建一个优化的计划——通过调整低优先级访问来为紧急访问腾出空间。
3. 带反馈的执行：代理向患者发送选项，更新日历，预订预约并发送确认，所有这些都是自动完成的。如果偏好发生变化，它会回溯，完善其行动。
4. 实时适应：一位医生因病请假。代理暂停新的预订，重新安排受影响的患者的预约，并通知员工——除非需要人工输入，否则所有步骤都是自主完成的。
5. 持续学习：在一天结束时，它分析结果，更新患者偏好，并调整未来的优先级逻辑。

自主代理可以规划、检索、决策、行动、适应和学习——所有这些都不依赖于预定义的工作流程。约翰现在专注于边缘情况，而代理智能地处理其余部分。

自主代理代表了AI 驱动流程自动化的下一步。通过将检索 AI 能力（情境意识、实时查询优化）与任务执行技能（预约安排、自动通知）相结合，自主代理可以从根本上重塑业务流程和日常运营。

注意

即使自主代理与业务流程自动化的概念非常契合，请记住，它们也可以代表客户体验的新增强。例如，在上面的场景中，患者 X 可以借助 AI 代理提供的对话式用户界面（这可能通过诊所网站或 WhatsApp 渠道实现）。通过这样做，患者 X 将体验到一种新颖且更流畅的与诊所互动的方式，而 AI 代理则捕捉意图，如果需要更多信息，会提出更多问题，并协调后端执行其任务。

我们可以为我们的代理提供不同程度的自主性，而决策是基于业务场景以及我们对解决方案准确性的信心水平。

摘要

人工智能代理已经从基本的自动化工具发展到复杂的自主系统，从而改变了商业运营和专业工作流程。本章探讨了三种主要类型：检索代理，通过 Agentic RAG 增强知识访问；任务代理，自动化特定操作如日程安排和电子邮件管理；以及自主代理，结合检索和执行与战略决策以优化复杂工作流程。为每个用例部署正确类型的人工智能代理是实现有影响力的自动化并提升用户体验的关键。

从下一章开始，我们将更深入地探讨人工智能代理的每个组成部分，从人工智能编排开始。

参考文献

DeepMind 的 AlphaGo: [en.wikipedia.org/wiki/AlphaGo#:~:text=AlphaGo%20is%20a%20computer%20program%20that%20plays%20the,version%20that%20competed%20under%20the%20name%20Master.%20%5B3%5D]( https://en.wikipedia.org/wiki/AlphaGo#:~:text=AlphaGo is a computer program that plays the ,version%20that%20competed%20under%20the%20name%20Master.%20%5B3%5D)
自主代理: www.techtarget.com/searchenterpriseai/definition/autonomous-AI-agents
强化学习: www.tensorflow.org/agents/tutorials/0_intro_rl
AGI: www.ibm.com/think/topics/artificial-general-intelligence

免费订阅电子书

新框架、演进的架构、研究更新、生产分解——AI_Distilled 将噪音过滤成每周简报，供直接与 LLMs 和 GenAI 系统打交道的工程师和研究人员阅读。现在订阅，即可获得免费电子书，以及每周的洞察力，帮助您保持专注并获取信息。

在packt.link/TRO5B订阅或扫描下面的二维码。

第二部分

设计、构建和扩展 AI 智能体

在本部分中，我们将深入了解设计、开发和部署 AI 智能体的实际方面。在第一部分介绍的基础概念之上，你现在将探索如何使用现代编排框架、记忆模块和工具集成来构建智能、目标导向的系统。

我们首先了解 AI 编排器的角色——一个协调任务、工具和记忆的中心组件，以实现复杂的流程。你将熟悉市场上最受欢迎的编排器，并学习如何根据你的需求选择和配置一个编排器。

章节随后将重点放在管理记忆和上下文上，这对于使 AI 智能体持久、适应性强以及能够处理多轮交互至关重要。我们还将介绍如何通过外部工具和 API 扩展智能体，实现实时数据访问、与企业系统集成以及更广泛的可操作性。

你将通过构建你的第一个智能体来将理论付诸实践，使用 LangChain 逐步进行。通过实际案例，你将开发针对电子商务和客户支持的特定领域助手，并理解支撑智能体设计的可重用组件。

最后，我们将探索多智能体系统的世界，在这里，多个智能体协作以解决任务。你将学习如何设计群聊、分层智能体结构，甚至使用 LangGraph 构建你的第一个多智能体应用。

本部分包含以下章节：

第三章, AI 编排器需求
第四章, 记忆和上下文管理需求
第五章, 工具和外部集成需求
第六章, 使用 LangChain 构建你的第一个 AI 智能体
第七章, 多智能体应用

第三章：需要一个 AI 编排器

随着大型语言模型的出现和 AI 应用的爆炸式增长，开发者面临着日益增长的挑战：如何有效地管理和协调日益复杂的 AI 系统。随着 AI 代理变得更加能够和自主，它们的行为必须被结构化、监控和优化——通常涉及多个工具、服务和数据源。这种日益增长的复杂性产生了对编排的迫切需求：确保这些智能组件无缝地共同实现一个共同目标。

AI 编排器应运而生，以满足这一需求。它们不仅提供预构建的组件，还提供了一个框架来构建交互、管理依赖关系并保持对多代理或模块化工作流程的控制——同时加速开发并降低运营风险。

在本章中，我们将涵盖以下主题：

AI 编排器简介
AI 编排器的核心组件
市场上最流行的 AI 编排器概述
如何为你的 AI 代理选择合适的编排器

到本章结束时，你将熟悉最流行的 AI 编排器以及如何利用它们来满足你独特的代理用例。

AI 编排器简介

现在很清楚，利用大型语言模型（LLMs）远不止简单的 API 调用——它涉及编排工具、管理内存和协调复杂交互，以构建真正智能的系统。虽然早期的 AI 集成依赖于与模型的直接交互，但现代 AI 代理需要一种更结构化的方法来管理工作流程、集成外部工具和高效处理内存。这正是AI 编排器发挥作用的地方。

AI 编排器作为中央枢纽，协调模型、工具、内存存储、API 和其他外部系统之间的交互。它确保 AI 代理以有效且受控的方式运行。

图 3.1：典型开发框架中 AI 编排器层的示例

AI 编排器可以帮助以下方面：

管理复杂性：AI 工作流程通常涉及多个协调步骤，如检索、推理和动作执行。编排器自动化并结构化这些流程，使系统更容易扩展和维护。
增强可扩展性：编排器通过分配任务、缓存响应和并行化操作来处理高负载——这对于处理多个用户或密集型任务至关重要。
确保上下文感知：由于大型语言模型（LLMs）的内存有限，编排器集成了向量数据库和内存系统，以帮助代理保留信息并提供更连贯、个性化的体验。
促进工具集成：协调器通过管理任务执行并确保 LLM 与外部工具之间交互顺畅，简化了 API、搜索引擎和数据库的使用。
提高可靠性和监控：从日志记录到人工反馈，协调器提供了捕捉错误、防止幻觉并确保系统安全可靠运行的工具。

为了更好地理解在 AI 代理的具体场景中需要 AI 协调器的原因，我们需要介绍后者的三个重要特性：自主性、抽象性和模块化。

自主性

自主性指的是 AI 代理能够独立地操作，在无需人类干预的情况下做出决策和执行动作。这种自我指导的行为使得 AI 代理能够执行任务、适应新情况并基于其学习经验追求目标。

AI 代理的自主性意味着代理将要采取的步骤不一定是可以事先知道的。

例如，让我们考虑一个非代理工作流程，它就像以下这样简单：

图 3.2：直接调用 LLM 的 API 示例

每当我们向大型语言模型（LLM）发出提示时，我们就是在进行一个 API 调用，这是这个工作流程中唯一的步骤。即使在检索增强生成（RAG）工作流程的场景中，步骤也是事先知道的：

图 3.3：RAG 模式的示例

现在让我们考虑一个自主的代理方法。假设我们有一个拥有两个工具的代理：

天气工具，一个接受两个参数：城市和单位。
位置工具，一个接受用户当前位置作为参数的功能，利用 GPS 位置。此函数不接受任何参数。

两个函数都附有自然语言描述，符合 AI 代理的结构。我们的工作流程设计将让代理决定调用哪个工具。

图 3.4：代理模式的示例

假设一个新用户问道：“明天的天气怎么样？”。以下事情将会发生：

代理将阅读其工具的描述并理解它需要调用天气工具。然而，它缺少两个参数，但多亏了它的自主性，它可以四处寻找以检索它们。它很快意识到可以利用位置工具来获取第一个参数：该函数的输出将作为天气工具的参数。

图 3.5：AI 代理调用工具检索参数的示例

对于第二个参数，代理无法单独完成：它需要询问用户。因此，它这样做，询问用户需要哪种类型的计量单位。一旦用户做出回应，代理就能正确地使用两个参数调用工具。

图 3.6：AI 代理请求用户提供缺失参数的示例

代理观察天气工具的输出，并确认它现在知道用户的最终答案。

图 3.7：AI 代理使用检索到的参数调用工具的示例

你能想象在标准的机器人流程自动化（RPA）过程中需要多少个“if…else”语句才能复制这种程度的自主性吗？即使我们能够管理类似的场景，如果用户提出的过程中没有硬编码的问题，怎么办？适应性、自我批评和自我调整是代理自主性的关键特征。

我们可以为我们的代理提供许多程度的自主性：这一切都归结为我们设置的工作流程和指导代理遵循的计划策略。正如我们将在本章中看到的那样，我们可以定义一个计划，其中代理将按特定顺序执行工具，我们可以计划让代理在达到特定输出之前循环使用一个工具，或者我们可以让代理完全自由地根据需要多次使用所有工具。

设计适当的代理工作流程是构建代理状态时关键的建筑设计对话。

抽象和模块化

抽象是指分解和简化复杂性。它使得这些系统易于理解并可扩展。但除了简化之外，它还使模块化设计成为构建智能系统的一个基本原理。

模块化将复杂问题分解成更小、可重用的组件，每个组件处理挑战的特定部分。这种方法提供了一些优点：

可互换性：组件可以在不影响整个系统的情况下进行交换、升级或替换。
可重用性：设计良好的模块可以在不同的项目中重新使用，从而提高效率。
可扩展性：独立但无缝集成的组件使得扩展解决方案更加容易。

在多代理系统中，抽象和模块化允许创建协作代理，每个代理专注于特定任务，同时动态交互。这反映了人类的解决问题方式，我们通过分解、委派和协作来有效地应对复杂性。

通过观察繁忙大都市中多代理交通管理系统，我们可以很好地理解代理模式中的抽象和模块化。在这个系统中，不同级别的代理处理不同级别的抽象，确保平稳运行而不使任何单一实体超负荷。

注意

我们将在第七章中更详细地介绍多代理系统。然而，重要的是要注意，一个独立的代理始终可以被另一个代理作为“工具”所消耗，采用带有其能力自然语言描述的相同方法。例如，一个“SQL 代理”可以在“项目经理代理”需要查询 SQL 数据库时成为一个工具。

从此以后，在多代理系统中——以及即将到来的例子中——将代理视为其他代理的潜在工具。

在最细粒度级别，我们有交叉口控制器，它们在单个交通信号灯或交叉口操作。这些代理依赖于来自摄像头和传感器的实时数据，根据车辆拥堵、行人移动和紧急车辆优先级调整交通信号。

他们不关心下一个街区或更广泛的城市景观中发生的事情；他们的唯一任务是优化他们特定位置的交通流量。如果交叉口出现车辆突然涌入，他们可能会延长绿灯时长以缓解拥堵。

从更广阔的角度来看，我们有区域级交通协调员。这些代理不会微观管理单个交通信号灯，而是分析一个社区或区域内部多个交叉口的交通流量。

他们使用来自交叉口控制器、GPS 跟踪和公共交通系统的数据来识别拥堵模式，重新规划车辆路线，平衡该区域的车流量。如果他们检测到某个区域有过度延误，他们会调整多个交叉口的交通信号灯的亮灯时间，而不仅仅是单个交叉口。

更重要的是，他们指导交叉口级代理，确保他们的调整与更广泛的区域级交通目标相一致。

在最高级别，我们有城市级交通管理系统，负责优化整个大都市区域内数百万辆车的流量。这个代理不专注于特定的交通信号灯或单个拥堵点；相反，它分配资源，预测长期模式，并做出战略调整。

通过使用来自天气预报、重大事件日程、事故和公共交通网络的数据，这个代理可能会重新规划整个道路，协调施工时间表以最小化干扰，或者在发生重大事件时实施城市级紧急响应计划。

如果主要高速公路发生事故，城市级系统会重新分配区域级代理以调整交通模式，进而指导交叉口控制器高效地重新规划车辆路线。

这种分层结构展示了抽象和模块化在多代理系统中的力量：

交叉路口代理处理本地、实时的决策，调整交通灯并优先考虑即时流量
区域级代理分析和协调交叉路口的群体，优化更广泛区域的交通
市级代理关注大局，规划长期效率、应急响应和系统优化

这反映了软件架构、AI 系统和甚至企业结构在现实世界中的运作方式。无论是前线工作人员执行任务、中层管理人员协调努力，还是高管设定整体愿景，抽象化使复杂系统保持可扩展性、效率和弹性。

通过采用这种分层方法设计多代理 AI 架构，我们确保每个代理只关注它需要处理的任务，防止系统过载，并实现大规模的适应性、实时决策，就像一个智能交通系统管理繁忙的城市一样。

如果这听起来不像一个真实的事物，让我们看看 OpenAI 的工具Operator，它作为一个自主代理，能够在网页浏览器中执行任务，如预订机票或填写在线订单。

OpenAI 的 Operator 遵循类似于交通管理系统的分层多代理方法。每个代理在不同的抽象级别上运行，确保效率和适应性，而不使任何单个组件过载。

Web 控制器（低级代理）：这些代理处理执行任务：移动鼠标、点击按钮和输入文本。它们不进行分析或规划——它们只是简单地遵循命令。
视觉和推理（中级代理）：这些代理解释网页界面。视觉代理处理截图，检测相关元素，而推理代理确定下一步行动（点击、输入或滚动）。这一层抽象掉了执行细节，专注于理解和决策。
规划者/协调者（高级代理）：顶级代理监督整个系统，确保网页交互与更广泛的目标一致——无论是搜索信息还是填写表格。它将任务委托给中级代理，确保平稳和战略性的导航。

这种结构化的方法突出了抽象在多代理设计中的关键性：

低级代理执行任务时无需担心决策
中级代理专注于解释和规划
高级代理处理整体策略，而不涉及技术细节

通过利用这种模块化设计，OpenAI 的 Operator 能够动态适应，处理不同的网站而无需手动编程。这种可扩展和可泛化的架构是多代理系统驱动现实世界 AI 应用的典范。

从建筑学的角度来看，所有这些组件——代理、技能、插件——都可以被视为组织中可重复使用的资产。在这种情况下，AI 编排器确保这些组件能够协同工作，而不会紧密耦合，防止复杂性压倒系统。

按照前面的分层示例，使用 AI 编排器，你可以轻松定义以下内容：

执行代理（低级）：这些处理原始任务，如 API 调用、数据库查询或网络抓取，执行命令而不做决策
推理代理（中级）：它们分析数据，确定行动，并选择合适的工具，抽象执行细节
编排和规划（高级）：编排器监督工作流程，分解任务，分配给代理，并动态调整

图 3.8：AI 代理层次结构

通过这种方式结构化 AI 系统，编排器能够实现自适应、可泛化的智能，确保组件之间无需人工干预的顺畅交互。

AI 编排器的核心组件

现在我们已经探讨了为什么 AI 编排器在管理代理系统中的复杂性、可扩展性、上下文和可靠性方面至关重要，现在是时候检查它们在幕后是如何工作的了。每个编排器的核心都有一组基础组件，包括工作流程执行、内存处理、工具集成、错误检测和安全执行。每个组件都在确保 AI 代理高效和可靠地运行中扮演着关键角色。

工作流程管理

AI 编排器的主要功能之一是定义和管理结构化工作流程。工作流程决定了任务是如何执行的，是按顺序、并行还是通过条件逻辑执行。以下列出了一些你可能会遇到的最常见工作流程：

顺序工作流程：任务按预定义的顺序逐步执行。示例：一个文档处理 AI 代理首先从图像中提取文本，然后总结内容，最后将其翻译成另一种语言。
并行工作流程：同时执行多个任务以优化效率。示例：一个金融分析 AI 代理可以同时处理多个股票趋势，以提供全面的市场报告。
条件工作流程：执行路径根据特定条件而改变。示例：如果情感分析检测到挫败感，客户支持 AI 代理可能会将复杂查询升级给人工代理。
分层工作流程：任务以结构化、多层次的方式组织，高级 AI 代理将子任务委派给专业代理。示例：一个项目管理 AI 代理监督工程工作流程，将任务委派给编码、测试和部署 AI 代理，同时确保整体进度跟踪。
群聊工作流程：AI 代理在对话环境中协作，根据实时交互交换见解并调整其行为。示例：一组 AI 代理（例如，研究助理、事实核查机器人、摘要模型）动态地讨论一个主题，在向用户展示最终响应之前，对输出进行细化。

注意

工作流程管理与我们在上一节中引入的自主性概念密切相关。例如，在群聊类型的工作流程中，你为你的多代理系统提供了高度自主性；另一方面，顺序工作流程更具可预测性，因为你明确地指出了要调用的代理的顺序。

人工智能编排者向开发者提供工具，以动态地设计、修改和优化这些工作流程，这对于创建可扩展和适应性强的 AI 应用至关重要。

记忆和上下文处理

有效的 AI 代理需要访问历史交互和外部知识库，以提供相关响应并保持连贯性。编排者通过各种内存管理技术来处理这一点：

短期记忆：存储基于会话的上下文，允许 AI 代理在持续对话中回忆细节。示例：一个虚拟助手会记住用户在聊天会话中的上一个问题。
长期记忆：在较长时间内保留知识，通常存储在向量数据库中。示例：一个医疗人工智能系统会记住患者的医疗历史，以便提供个性化的推荐，例如过去的就诊记录、医疗报告、过敏或服用的药物等。
语义记忆缓存：当 AI 编排者管理内存时，他们会使用缓存策略来优化检索速度和效率。语义记忆缓存涉及以允许 AI 代理在无需依赖基于会话的历史的情况下回忆事实、概念和关系的方式存储频繁询问的信息。示例：一个客户服务 AI 代理可能会回忆用户的过去投诉并更快地检索解决方案。

定义

在计算环境中，缓存是一种用于临时存储数据以加速未来访问的技术。传统上，具有低延迟和高吞吐量要求的程序利用内存缓存，这涉及到直接在系统的 RAM 中存储数据，由于 RAM 的高速特性，这使得数据检索变得快速。然而，内存缓存通常依赖于精确的键值对进行数据检索，这意味着请求必须与存储的键精确匹配才能检索相应的数据。

随着 LLM 驱动应用程序的出现，引入了一种新的缓存系统：语义缓存。这侧重于数据的含义和上下文（利用嵌入），而不是精确匹配。这种方法存储查询及其语义上下文的结果，使系统能够识别和检索相关数据，即使新查询与之前的查询不完全匹配。

通过有效地管理内存，AI 编排器确保代理提供连贯、信息丰富和上下文感知的响应。

工具和 API 集成

AI 代理通常需要访问外部资源，如数据库、API 和计算工具。编排器通过使代理能够执行以下操作来实现无缝集成：

从 API 获取实时数据（例如，为旅行助手 AI 获取天气更新）
访问和查询数据库（例如，为电子商务 AI 助手检索订单详情）
利用外部计算工具（例如，在银行应用程序中使用机器学习 API 进行欺诈检测）

编排器允许这些集成得到有效管理，确保 AI 代理以最新和准确的信息运行。

错误处理和监控

为了确保 AI 应用程序保持可靠性，编排器实施强大的错误处理和监控机制：

日志和分析：捕获 AI 交互的详细日志，用于调试和优化。
自动错误检测：识别失败的进程并自动重试或升级。
性能跟踪：监控响应时间、准确性和整体系统健康。
人机交互集成：允许对关键决策进行人工审查。示例：医疗 AI 助手在做出诊断之前需要人工确认。

通过主动处理错误和提供全面的监控，AI 编排器有助于保持高系统可靠性和可信度。

安全性和合规性

在 AI 系统中，安全性是首要任务，尤其是在处理敏感数据时。AI 编排器整合了多项安全措施，包括以下内容：

身份验证和访问控制：确保只有授权的用户和系统能够与 AI 代理交互
速率限制：通过控制 AI 代理在特定时间段内可以处理的请求数量来防止滥用
数据隐私合规性：通过安全地管理用户数据来遵守 GDPR 或 HIPAA 等法规
偏差和安全过滤器：实施安全措施以防止有偏差或有害的 AI 输出

安全性和合规性机制有助于确保 AI 代理在安全、道德和合法框架内运行。

AI 编排器的核心组件——工作流程管理、内存处理、工具集成、错误检测和安全——是构建稳健和高效 AI 应用的基础。通过利用这些功能，开发者可以创建不仅强大而且可靠、可扩展和安全的 AI 智能体。了解这些组件有助于在选择或设计 AI 编排框架时做出更好的决策。

市场上最受欢迎的 AI 编排器概述

几个 AI 编排器已经在这个领域崭露头角，各自提供针对不同用例的独特功能。一些侧重于模块化和灵活性，允许开发者自定义工作流程，而另一些则优先考虑用户友好的界面以实现快速原型设计。在这里，我们将探讨截至 2025 年 5 月最广泛使用的 AI 编排器，突出它们的关键优势和理想应用。

LangChain：LangChain 是一个模块化框架，旨在构建由 LLM 驱动的应用。它提供了集成外部工具、管理交互间内存和定义基于智能体的工作流程的基本组件。作为一个开源项目，LangChain 拥有广泛的文档和强大的社区，使其成为开发者构建稳健 AI 驱动应用的优选。
LlamaIndex（原名 GPT Index）：LlamaIndex 专注于优化 LLM 的数据检索，确保高效访问结构化和非结构化数据源。当与 LangChain 结合使用时，它特别有效，可以构建需要复杂搜索和索引能力的知识驱动 AI 智能体。它能够在大规模数据和生成式 AI 之间架起桥梁，使其成为处理大量信息库的组织不可或缺的工具。
AutoGen：AutoGen 专为开发多智能体 AI 工作流程而设计，使 LLM 驱动的智能体能够在复杂任务中进行沟通和协作。通过自动化 AI 实体之间的交互，AutoGen 促进了研究、推理和内容生成，使 AI 系统通过结构化对话做出更明智的决策。它非常适合需要多个专业智能体共同实现共同目标的用例。
Langflow：Langflow 通过直观的视觉界面简化了设计 AI 智能体工作流程的过程。通过与 LangChain 和其他编排工具无缝集成，它实现了快速原型设计和智能体交互的实时可视化。这使得它对于想要实验 AI 驱动自动化但不想深入研究代码实现的开发者和研究人员特别有用。
语义内核（SK）：由微软开发，语义内核通过结合机器学习能力和传统软件开发实践，弥合了人工智能与企业应用之间的差距。它支持基于插件的架构，允许开发者将人工智能驱动的流程集成到现有的商业系统中。语义内核旨在通过将人工智能驱动的自动化直接嵌入到企业软件环境中来提高生产力。
LangGraph：LangGraph 通过利用基于图的工作流程引入了一种结构化的多代理协作方法。它提供了一个框架来设计复杂的代理间交互，确保人工智能系统以有组织和可扩展的方式进行通信。这使得它在编排需要不同代理动态协作以解决复杂问题的 AI 应用程序方面特别有价值。

现在，问题是：我如何为我的 AI 代理选择正确的编排器？

如何为你的 AI 代理选择正确的编排器

选择人工智能编排器取决于多个因素，包括应用程序的复杂性、所需的定制程度、可用的生态系统以及部署的简便性。在选择编排器时，以下是一些关键标准需要考虑：

易用性和模块化：如果你正在寻找一种快速且模块化的方式将 LLMs 集成到应用程序中，LangChain由于其良好的文档和灵活的架构，是一个很好的选择。示例：一个初创公司开发用于客户支持的人工智能聊天机器人，可能会使用 LangChain 快速原型设计和集成到其现有的数据库和 API 中。
数据密集型应用程序：如果你的 AI 代理严重依赖结构化或非结构化数据检索，LlamaIndex针对高效集成外部知识源进行了优化。示例：一个法律人工智能助手，在多个文档存储库中检索和分析案例法，将受益于 LlamaIndex 的检索能力。
多代理工作流：如果你的应用程序需要多个代理动态交互，AutoGen或LangGraph是编排复杂人工智能交互的理想选择。示例：研究助理人工智能，其中多个代理协作——一个总结文档，另一个核实事实，第三个生成报告——将受益于这些编排器。
企业级人工智能应用程序：如果你需要强大的企业集成和安全，语义内核非常适合基于微软的环境和结构化人工智能工作流。示例：一个与 Microsoft Teams 和 SharePoint 集成的企业级人工智能分析工具与语义内核非常契合。
可视化工作流程设计：如果您更喜欢无代码或低代码界面进行 AI 工作流程设计，Langflow提供了一个直观的用户界面，用于快速原型设计和调试 AI 代理交互。示例：一个没有深厚编码专长的营销团队可以借助 Langflow 的视觉界面进行快速工作流程设计。

选择 AI 编排器应与您的 AI 系统的目标和技术要求相一致。虽然一些编排器专注于模块化开发，而另一些则专注于可扩展性、多代理协作或企业集成。了解这些区别将帮助您为特定的用例选择最佳工具。

摘要

AI 编排器在智能系统的发展和部署中扮演着关键角色，提供了管理工作流程、集成工具和保持效率所需的框架。随着 AI 应用的持续发展，编排器确保 AI 代理能够自主运行、处理复杂任务并适应动态需求。

在本章中，我们探讨了 AI 编排器的基本组件，包括工作流程管理、内存处理和安全。我们还考察了今天一些最受欢迎的编排器，每个编排器都提供针对特定用例的独特优势。

选择合适的 AI 编排器取决于各种因素，如集成需求、可扩展性和工作流程复杂性。通过了解它们的核心功能，开发者和企业可以在选择与他们的目标相一致的编排工具时做出明智的决定。

从下一章开始，我们将深入探讨 AI 代理中最引人入胜的一些组件，从记忆和上下文管理开始。

参考文献

OpenAI Operator：openai.com/index/introducing-operator/
LangChain：www.langchain.com/
LlamaIndex（原名 GPT Index）：www.llamaindex.ai/
AutoGen：www.microsoft.com/en-us/research/project/autogen/
Langflow：www.langflow.org/
语义内核（SK）：github.com/microsoft/semantic-kernel
LangGraph：www.langchain.com/langgraph

现在解锁本书的独家优惠

扫描此二维码或访问 packtpub.com/unlock，然后按书名搜索 | |

| 注意：在开始之前准备好您的购买发票。 |

| --- |

第四章：需要记忆和上下文管理

大型语言模型（LLMs）在本质上是无状态的，尽管它们看起来很连贯、对话性强。它们只知道你在当前提示中告诉它们的内容。除非你明确构建，否则没有持久的环境或历史记录。做得好的话，记忆可以让代理保持一致性、上下文感知，甚至随着时间的推移实现个性化。

在本章中，我们将涵盖以下主题：

不同类型的记忆
管理上下文窗口
存储记忆、检索和刷新记忆
管理记忆的流行工具

到本章结束时，你将深入了解记忆在人工智能代理中的功能，以及使你的代理更智能、更可靠和上下文感知所需的工具和模式。

不同类型的记忆

正如人类依赖记忆来理解世界一样，人工智能代理需要记忆来在时间上智能地操作。记忆使代理能够在交互中保留信息、记住过去的事件、存储有用的知识，并构建一致的行为。没有记忆，即使是最强大的语言模型也是无状态的——只对当前输入做出反应，而对之前的内容毫无意识。

随着人工智能代理变得更加复杂，对其记忆系统的要求也越来越高。仅仅生成响应已经不再足够，代理必须能够记住、适应并在时间上不断改进。有趣的是，研究人员为代理设计记忆架构的方式在很大程度上借鉴了心理学家对人类记忆的理解。这种平行关系导致了人工智能中记忆类型分类法的不断增长，每种类型都有其独特的用途，从处理近期交互到构建长期知识和技能。

在本节中，我们将根据 Theodore R. Sumers 等人在其论文《语言代理的认知架构》（ https://arxiv.org/pdf/2309.02427 ）中提出的相同框架，分解现代人工智能代理所使用的不同类型的记忆系统。

短期记忆

短期记忆（STM）是代理的即时工作空间——一个临时存放最近输入以供快速参考的草稿本。这就是为什么 STM 通常被称为 工作记忆（根据上述论文中使用的术语）。

在对话系统中，这对于在多轮交互中保持连贯性至关重要。如果用户说，“给我预订一个 7 点的 4 人桌”，然后补充说，“再加一个座位”，STM 帮助代理连接这些点。

图 4.1：短期记忆上下文窗口示例

技术上，STM 通常使用滚动上下文窗口或缓冲区来实现，它保存最近的对话或数据块。

定义

上下文窗口指的是模型一次可以处理的最大信息量（标记），通常包括提示、对话历史以及任何检索或注入的知识。它是内存管理中的一个关键约束，因为超过窗口会迫使代理忘记或总结过去的数据以保持在限制内。

当新的输入到来时，旧的数据会被推出去。这保持了交互的响应性和轻量级，但也意味着短期记忆（STM）本质上是不持久的。一旦缓冲区满了或者会话结束，那些信息就消失了。

因此，虽然 STM 非常适合快速问答式交互，但在记住偏好或从过去的会话中学习时却显得不足。这提出了一个关键问题：AI 代理如何在与用户的交互中保持长期上下文和连续性？

长期记忆

当 STM 处理当前情况时，长期记忆（LTM）则是关于时间上的连续性。它允许代理在不同会话中回忆信息，从而实现个性化、持久知识和更好的决策。

LTM 通常由持久存储系统支持——向量数据库、知识图谱或结构化存储库。这里最有效的技术之一是检索增强生成（RAG），其中代理从存储库中拉入相关的知识来告知其回答。这使得 LTM 对于客户支持助手、推荐引擎或个性化导师等代理至关重要。

注意，STM 和 LTM 是相关的，因为 STM 一旦对用户的会话不再相关，就可以被冲入 LTM（我们将在下一节中探讨类似的技术）。

图 4.2：短期记忆推入长期记忆的示例

在长期记忆中，我们可以进一步分解出三种不同的亚型，这些亚型反映了人类的认知。

语义记忆

语义记忆存储一般知识——事实、概念、规则和定义。它是系统中“知道事情”的部分，使代理能够推理、解释并提供有根据的答案。

注意，按照设计，大型语言模型（LLM）已经包含了参数化知识，这些知识已经提供了对世界的广泛了解：它们知道物理学、数学、一般文化以及任何形式上公开在互联网上可用的文档中编码的一切。然而，这种知识可能对我们的特定用例来说可能不够或相关：如果我们想让我们的 AI 代理记住我们在医疗中心所做的所有过去诊断呢？当然，这可能是训练集的一部分，因此它不是我们代理所使用的 LLM 参数化知识的一部分。

正因如此，语义记忆对于在复杂领域（如法律、医学或金融）中运行的代理特别有用，在这些领域中，事实正确性和领域理解至关重要。

在实践中，语义记忆可能通过存储在向量存储中的向量编码嵌入来实现，其检索原理与在第一章中探讨的 RAG 概念类似。

注意

语义记忆也可以是 STM（短期记忆）的最终目的地到一定程度。事实上，STM 上下文窗口中的某些组件或对话可能值得保留，如果这样，它们可以被矢量化并存储在语义记忆的向量数据库中。

情景记忆

在人类大脑的背景下，情景记忆指的是回忆个人参与过的特定过去事件的能力。当涉及到人工智能时，情景记忆将使人工智能代理能够从其与环境交互中存储和检索特定经历或事件，而不仅仅是普遍的事实知识。

例如，一个人工智能导师可能会回忆起学生上周如何回答数学问题，并利用这一点来调整今天的课程。这种记忆通常以结构化日志或事件历史的形式存储，代理可以参考这些内容来做出基于案例的决定或调整其行为。

在实践中，情景记忆可以被视为少样本提示技术的扩展。

定义

少样本提示是一种在大规模语言模型中使用的技术，其中模型在提示本身中提供了少量（通常是 2-5 个）示例。这些示例有助于引导模型的响应，以更好地与所需任务对齐，而无需进行广泛的微调或训练数据。

这里有一个例子：

任务：情感分析

示例 1：

文本："我喜欢这部电影！"

情感：积极

示例 2：

文本："这部电影太糟糕了。"

情感：负面

现在对以下文本进行分类：

文本："这部电影总体上很令人愉快，尽管有一些缺点。"

情感：

以这种方式，少样本提示利用模型从少量示例中快速学习模式的能力，在不进行显式重新训练的情况下提高其在特定任务上的性能。

事实上，通过存储一组（“用户问题”，“给定答案”）或（“用户问题”，“执行任务”）的配对，人工智能代理可以被引导通过执行特定动作的正确方式。

根据 Chad DeChant 的论文《人工智能代理中的情景记忆风险应进行研究并减轻》，在人工智能代理中实现情景记忆将允许以下显著的增强：

规划和决策：通过回忆类似的前期经验和结果，记忆提供构建新策略或计划的基本块
改进学习：人工智能代理可以通过反思过去的事件及其结果，识别模式并从错误中学习，更好地适应新场景
问题解决：情景记忆通过类比或组合过去的解决方案提供过去场景的例子，帮助通过类比或重组过去的解决方案来解决当前问题
预测和想象：正如人类根据过去的事件在心理上模拟未来场景一样，人工智能代理可以使用情景记忆来预测可能的后果。

然而，作者也指出了与情景记忆相关的潜在风险：

欺骗：智能体可以利用情景记忆来执行复杂的欺骗行为，通过回忆过去的交互并策略性地操纵未来的交互。
不希望保留的知识：智能体可能会保留和回忆用户希望保持私密的个人信息，这可能导致重大的隐私风险。
不可预测的行为：随着代理重复使用过去经验来形成未来行为，可能难以预测某些存储的记忆如何影响未来的行为，这可能导致意外的后果。
增强情境意识：改进的记忆能力可能使人工智能更好地理解和适应其操作环境，可能逃避旨在确保安全性的控制或审计。

尽管将情景记忆集成到人工智能代理中存在潜在风险，但整体能力仍然非常有前景。论文强调，这些风险可以通过精心设计的遏制策略和安全原则得到显著缓解，例如确保记忆的可解释性、提供用户控制以添加或删除记忆、隔离记忆存储以及限制人工智能代理编辑自己的记忆。

注意

在人类认知和人工智能系统中，情景记忆和语义记忆有不同的用途：

情景记忆就像个人日记。它存储“发生了什么”——与特定时间、地点相关联的具体事件、交互和经历。对于人工智能来说，这可能意味着记住某个用户的投诉或失败过程中采取的步骤。

语义记忆更像是一部百科全书。它存储“已知的内容”——独立于上下文的一般事实、概念和规则。对于人工智能代理来说，这可能包括产品规格、政策规则或领域知识。

保持这两种记忆类型区分开来，使代理能够更有效地推理：当需要时，他们可以借鉴过去的事件，同时依靠既定的知识来保持一致性和准确性。

通常，人工智能代理通过记录交互来捕捉情景记忆，这些交互通常包括以下内容：

用户输入：用户提供的查询或命令。
代理响应：人工智能生成的动作或回复。
上下文元数据：如时间戳、用户标识符和环境上下文等附加信息。

这些交互存储在数据库中的结构化格式中。常见的存储解决方案包括以下几种：

关系数据库：如 SQLite 和 PostgreSQL 等系统用于存储交互的结构化日志。
向量数据库：如 Pinecone、Weaviate 和 Chroma 等工具存储交互的嵌入（数值表示），从而促进基于相似性的高效检索。

当一个 AI 代理需要回忆过去的经验来指导当前决策时，它会执行以下步骤：

查询嵌入：当前用户输入被转换为嵌入
相似性搜索：此嵌入与向量数据库中存储的嵌入进行比较，以找到最相关的过去交互
上下文注入：检索到的记忆被纳入代理的当前上下文中，通常通过提示工程来实现，以影响响应生成

这个过程使代理能够根据以往的经验调整其行为，从而增强交互中的个性化和连续性。

程序记忆

我们需要提到的最后一个记忆是程序记忆。对我们来说，这种长期记忆负责存储如何做事情，例如记住如何骑自行车或系鞋带——一旦学会，就可以在没有意识思考的情况下执行。在 AI 代理的背景下，程序记忆发挥着类似的作用：它编码了控制代理行为的“知道如何”的基础知识。例如，在自动驾驶汽车中，程序记忆使导航程序和障碍物避让得以执行，而无需从头开始重新评估每个决策。

根据在《认知架构语言代理》论文中提出的 CoALA 框架，代理的程序记忆由两个主要组件组成：

LLM 权重，它隐式地编码了大量的程序知识，例如语言使用、推理模式和世界模型
代理代码，它明确定义了诸如提示构造、检索机制、地面化程序和决策逻辑等程序

从本质上讲，程序记忆编码在模型的架构中。因此，大多数当前的 AI 代理将这种记忆视为静态的（与人类程序记忆不同，人类程序记忆可以通过经验随着时间的推移进行适应）。LLM 的权重在部署期间保持不变，代理代码很少被代理本身重写。

注意

从理论上讲，可以创建能够自动更新其自身源代码的代理——特别是更新其技能集（例如通过编码新技能）或决策逻辑。另一方面，由于成本高、复杂性和安全问题，野外的 LLM 微调（即修改权重）仍然不常见。

一个更实际且观察到的行为是代理修改他们的系统消息——本质上是在更新他们给予自己的指令以引导行为。这种方法提供了一种轻量级的程序适应性，尽管它在范围和当前系统中的利用率仍然有限。

我们所涵盖的每种类型的记忆都在塑造代理智能方面发挥着独特的作用，从使行动成为可能到提供决策信息和从过去学习（参见表 4.1 以下）：

| --- | --- | --- | --- | --- | --- |

表 4.1：内存类型及其用法示例

它们共同构成了代理持久能力及其累积知识的骨架。

我们已经讨论了长期和短期记忆；然而，还有一个第三类值得提及：语义内存缓存。

在短期记忆和长期记忆之间——语义缓存的作用

在 STM（短期记忆）的即时性和 LTM（长期记忆）的持久性之间，语义缓存提供了一个灵活、高速的层，用于根据意义检索最近的信息。这些缓存通过将最近交互作为向量嵌入存储，允许在当前会话内进行语义相似度搜索，而无需查询或持久化长期存储中的数据。

注意

在传统的应用程序开发中，内存缓存是一种临时存储层，它将频繁访问的数据存储在内存中（通常是 RAM），以减少延迟并提高性能。应用程序不是反复查询数据库或外部 API 以获取相同的数据，而是从缓存中检索它——从而实现更快的访问。Redis、Memcached 以及应用程序框架中的内存层等工具通常用于此目的。

这些缓存通常基于键值对操作——您使用一个唯一的键存储结果，稍后通过引用该键检索它。这在存储用户会话、API 响应或不太频繁更改的计算值等场景中非常高效。

在 AI 代理和更广泛的 LLM（大型语言模型）驱动应用程序的背景下，概念类似，但键值对基于嵌入，以便检索可以通过向量搜索而不是关键字匹配来实现。

在图 4.3中，您可以看到一个关键字和语义内存缓存之间区别的示例：

图 4.3：关键字和语义内存缓存的区别

快速提示：需要查看此图像的高分辨率版本？在下一代 Packt Reader 中打开此书或在其 PDF/ePub 副本中查看。

新一代 Packt Reader随本书免费赠送。扫描二维码或访问 packtpub.com/unlock，然后使用搜索栏通过名称查找此书。仔细检查显示的版本，以确保您获得正确的版本。

与依赖于模型标记上下文窗口的 STM 不同，与为跨会话持久记忆设计的 LTM 不同，语义缓存是会话范围的、短暂的、快速的。它不是为了保留知识或事件随时间推移，而是为了帮助代理在持续交互中动态地呈现相关上下文——即使表达方式与最初不同。

这种实时召回是由专门为语义检索设计的向量数据库实现的。例如，具有集成向量索引的 Cosmos DB、Pinecone、Weaviate 和 Qdrant 等工具允许开发者以低延迟存储和查询嵌入。这些系统支持内存搜索、按元数据过滤和基于相关性和最近性评分等功能——使它们非常适合实现语义缓存。

例如，在患者排程流程中，如果用户之前说“下午最适合”，后来询问“你有 3 点之后的安排吗？”，语义缓存可以检索并匹配之前的声明——即使它已不在上下文窗口中。这使得代理能够保持连贯性和上下文意识，而无需承担额外的标记成本。

在实践中，语义缓存充当智能短期召回层，使代理能够保持响应、语义流畅和高效——而无需长期承诺。它们不取代 STM 或 LTM，而是通过在对话流程中实现低延迟、相关性驱动的记忆来补充它们。

在下一节中，我们将关注 STM——代理在决策过程中如何保持和操作活动信息。这是感知、推理和上下文实时结合的地方。

管理上下文窗口

当谈到 STM（或工作记忆）时，上下文窗口的概念至关重要。它定义了模型可以同时处理的文本最大跨度——以标记为单位。这个窗口允许模型在生成响应时“记住”并利用特定信息段，这样用户就不必重复上下文信息。

尽管最新的大型语言模型（LLM）可以处理的最大令牌数量有所增加（例如 GPT-4o 模型可达 128K 个令牌），但管理上下文窗口仍然存在挑战。当输入超过模型的上下文窗口时，模型可能难以保持连贯性和相关性，因为它无法访问文本的早期部分。这种限制可能导致输出缺乏上下文或连续性，尤其是在需要处理大量文档或长时间对话的任务中。

因此，我们需要正确设计上下文窗口的处理。在这个领域有许多技术，在本节中，我们将探讨其中一些最受欢迎的：

滑动窗口：滑动窗口技术通过维护一个固定大小的近期消息窗口并动态更新它来管理短期记忆。首先，确定窗口大小至关重要，可以通过固定近期消息的数量或根据系统约束和期望的响应质量设置基于令牌的限制。然后，随着新消息的到来，通过丢弃最旧的消息来动态更新窗口，以保持其大小。例如，如果我们设置滑动窗口以同时保留 4 条消息（这通常以我们想要保留的令牌数量来设定），我们将有类似以下的内容：

图 4.4：短期记忆滑动窗口示例

此过程将窗口向前移动，仅保留当前的相关信息。

编辑消息列表：编辑消息列表是滑动窗口方法的扩展，可以更细致地决定保留哪些消息。它涉及在 LLM 处理之前有选择地修剪或过滤消息。例如，想象一个 AI 客户支持代理帮助用户解决软件问题。在 20 条消息的来回中，只有最后几条消息与用户的最新请求直接相关。而不是将所有 20 条消息都输入到 LLM（这可能会超过令牌限制），系统有选择地保留以下内容：
- 用户最近提出的问题
- 助手的最后 1-2 个回复
- 一条包含关键上下文的信息（例如，用户的操作系统版本）

所有其他闲聊或冗余问题都被修剪掉。这确保模型只关注上下文窗口中最相关的细节。

在实践中，您需要建立明确的规则或指南来确定哪些消息应该保留或丢弃。常见的标准包括以下内容：

近期性（这是一种滑动窗口的形式）：优先考虑近期消息以保持相关上下文
相关性：保留与当前查询或任务直接相关的消息（这种“评估”可能由另一个 LLM 通过特定的系统提示进行）
发送者：仅保留来自特定发送者的消息（无论是用户还是某个代理）

你的过滤器详细程度将取决于你聊天窗口中每条消息关联的元数据。

例如，我们可能决定只保留用户在最后 5 分钟内发送的消息：

图 4.5：编辑短期记忆消息列表的示例

正如我们在实践章节中将要看到的，LangGraph 等框架提供了一种现成的、非常详细的与你的消息相关的元数据结构，这样你可以非常细致地对其应用过滤器。

例如，在前面的例子中，一个潜在的元数据集可能如下所示：

{"sender": "user",
 "timestamp": dd-mm-hh-mm,
 "content": "I like option 2",
 …
}

摘要：摘要是将广泛的对话历史或长篇文档压缩成简洁、集中的概述的过程。这项技术捕捉了关键点和关键信息，显著减少了所需的标记数量，同时保留了关键上下文。

图 4.6：总结短期记忆消息的示例

在实践中，摘要是由 LLM 本身生成的，并作为系统消息的一部分参数传递，告诉代理如何处理短期记忆。

注意

除了我们将要采用的具体技术外，了解我们何时想要应用这项技术也很重要——例如，当 STM 的标记数达到一定的数量（我们可以将其设置为我们使用的 LLM 可以处理的标记数的最大值附近）。通过执行标记检查，我们确保当标记计数接近限制时，选定的策略（如摘要或消息编辑）得到执行。

之前的技术是处理 STM 上下文窗口的关键；然而，它们可能并不足够。实际上，根据你正在开发的 AI 代理类型，你可能需要保留和存储工作记忆更长的时间，超出用户的会话时间。

在下一节中，我们将看到如何处理类似的场景。

存储和检索记忆

在 AI 代理中，将信息从 STM 移动到 LTM 对于在会话间保留上下文并允许随时间学习至关重要。这个过程通常涉及识别相关事实、用户偏好或从最近交互中获得的见解，并将它们存储在结构化、可检索的格式中。

长期记忆可以根据用例以各种方式实现。一种常见的方法是使用向量数据库进行语义存储——其中信息块被嵌入到向量中并存储，以便基于相似性检索，通常与 RAG 结合使用。这允许系统回忆与上下文相关的数据，即使它不是即时提示的一部分。

存储的信息也可以组织为结构化元数据（如用户资料或偏好）或作为事实条目附加到更广泛的知识库中。

注意，这种方法可以与向量存储方法相结合。这种混合方法允许系统首先使用显式、结构化的字段（如用户 ID、主题标签或时间戳）过滤相关信息，然后在过滤后的子集中应用语义向量搜索。例如，在多用户应用程序中，代理可以首先仅检索与特定用户关联的文档，确保上下文正确。

图 4.7：混合记忆检索示例，结合过滤与向量搜索

一旦隔离了相关的记忆片段，基于当前查询，向量相似度搜索可以展示最符合上下文的信息片段。这种分层方法提高了精确度和相关性，使得响应更加准确和个性化。它还通过在调用更计算密集的向量相似度操作之前缩小搜索空间来提高性能。

最终，我们需要考虑如何长期管理我们的记忆。在人工智能代理中刷新和更新记忆涉及定期审查和修改存储的知识，以确保其保持相关性、准确性和有用性。这个过程可以是反应性的，由特定的交互或变化触发，也可以是主动的，作为后台任务安排。

记忆更新可以在工作记忆层实时实现，也可以异步地在后台为长期记忆实现。例如，如果用户更改偏好或纠正代理，这些数据可以立即覆盖或修改内存中相应的条目。

图 4.8：用户会话上下文中编辑记忆的示例

另一方面，代理也可以定期回顾累积的交互，以完善摘要、重构个人资料或删除过时的信息。

刷新语义记忆的常见技术是重新生成更新文档的嵌入，并替换数据库中的旧向量。对于结构化元数据，更新可能涉及覆盖用户资料中的字段或调整反映用户随时间行为得分的分数和计数器。通过结合实时和后台刷新策略，并允许语义和结构化更新，人工智能代理可以维护一个与用户需求和应用程序动态同步演变的记忆系统——确保他们依赖的信息既保持最新又符合上下文。

人工智能代理中的时空推理

为了使 AI 代理在动态环境中有效运作，它们必须具备理解和推理时间序列和空间环境的能力。这不仅包括回忆过去的事件，还包括根据学习到的模式预测未来的发生。让我们看看一些例子：

利用时间序列事件：时间推理使智能体能够按时间顺序处理事件，从而让他们能够理解因果关系并预测后续行为。例如，在一个客户服务聊天机器人中，识别到用户之前曾询问过产品可用性，可以告知代理在未来的交互中主动提供更新或相关信息。

在强化学习场景中，代理通过回忆导致成功结果的行为序列，从而随着时间的推移改进他们的策略，从而受益于时间推理。

引用过去交互：通过维护交互历史，代理可以个性化响应并保持对话的连贯性。这种情景记忆允许更自然和上下文感知的参与，因为代理可以引用先前交换中的具体细节，从而提升用户体验和信任。
管理时间衰减：正如人类倾向于忘记未被加强的信息一样，AI 代理也必须随着时间的推移管理存储信息的相关性。实施时间衰减机制确保过时或不那么相关的数据不会使代理的记忆杂乱无章，从而允许更有效地处理和检索相关信息。

这里是管理时间衰减的策略：

时间感知检索：在决策过程中优先考虑最近和频繁访问的信息。例如，代理可以为每个记忆附加时间戳并在检索期间使用最近度评分。向量存储可能会随着时间的推移衰减嵌入，或应用过滤器以仅检索最近条目。
强化机制：加强重复访问或被认为重要的信息的保留，同时允许不那么关键的数据逐渐消失。例如，您可以实施一种机制来跟踪访问频率并应用强化信号（例如，提升向量相似度分数或将其标记为“固定”）。这些可以通过自定义检索逻辑或混合 RAG 管道进行管理。
记忆修剪：定期评估和删除过时信息以优化内存使用并维持系统性能。例如，您可以让 LLM 或内存管理器定期使用诸如年龄、访问频率和相关性等标准评估内存条目。低价值项要么存档要么删除，以优化内存使用和延迟。

通过有效地管理时间衰减，AI 代理可以在保留有用信息和丢弃无关数据之间保持平衡，从而产生更准确和上下文相关的响应。

管理记忆的流行工具

正如我们在本章中看到的，为 AI 智能体配备复杂的记忆系统对于提供个性化的连贯用户体验至关重要，尤其是在长时间或重复的交互中。

流行的 AI 编排器，如 LangChain、LangGraph、Semantic Kernel 等，提供了预构建的库，以简化 STM 和 LTM 的管理。然而，某些应用程序可能需要复杂的内存管理，仅依靠上述框架可能会变得繁琐。

因此，最近已经发布了许多针对特定内存的轻量级框架，为开发者提供了一套强大的工具集，用于复杂的应用程序。

让我们探索其中最受欢迎的三种：LangMem、Mem0 和 MemGPT——每种都提供了增强智能体记忆的独特方法。

LangMem

LangMem 是 LangChain 生态系统中开发的一个专门用于内存管理的工具，它使开发者能够对 AI 智能体如何记住和回忆信息拥有细粒度和有意的控制。LangMem 允许将记忆视为智能体工作流程中的一个活跃的、可编程的部分——尤其是在与 LangGraph 一起使用时。这种集成使开发者能够精确指定智能体何时应该写入或读取内存，例如在决策点、外部 API 调用或用户输入之后。

LangMem 引入了一种内存架构，它区分了两种互补的内存处理模式：热路径和背景记忆。这些模式定义了 AI 智能体存储和处理信息的时间和方式，使开发者能够精确控制内存行为。

图 4.9：Langmem 中的热路径和背景记忆。来源：https://langchain-ai.github.io/langmem/hot_path_quickstart/

热路径指的是在智能体活跃推理过程中写入的记忆。换句话说，当智能体与用户互动——回答问题、解决问题或引导工作流程时，它可以有意识地决定要记住哪些信息。这是通过一个名为 manage_memory 的工具来完成的，智能体可以通过自然语言输入调用该工具，以存储有意义的事实、决策或偏好。例如，如果用户说，“我更喜欢早上预约”，智能体可以选择立即将这个偏好保存到记忆中。这些记忆被组织成 命名空间——一种文件夹系统——以便它们可以针对特定用户、主题或线程进行范围限定。这使开发者能够精确控制存储的内容、位置和原因。

另一方面，背景内存被动且异步地工作。不是在对话中被代理触发，而是在对话结束后在后台运行——通常在交互结束后。它可以处理整个对话历史，提取摘要、重复主题或有用的元数据，而不会干扰用户的体验。这对于构建长期用户档案或将长时间交互压缩为几个可消化的见解特别有用。将其视为对话后的反思，系统在无需明确告知要记住什么的情况下从对话中学习。

LangMem 与 LangGraph 框架紧密集成，这使得开发者能够构建具有结构化工作流程和状态管理的 AI 代理。由于 LangMem 中的内存是线程感知的，它随着对话流程跟踪，因此代理不仅能够回忆起孤立的事实，还能理解这些事实是何时和为什么被存储的。

LangMem 还支持不同的存储后端。开发者可以从内存设置开始——适用于测试和快速开发——然后在构建生产环境时切换到更持久的存储，如数据库。这种灵活性确保了内存策略可以与代理的复杂性和生命周期一起扩展。

通过结合热点路径和背景内存，LangMem 使代理既反应迅速又深思熟虑：能够在实时做出明智的决定，同时随着时间的推移学习和适应。它将短期意识与长期学习联系起来，成为智能、具有记忆意识的代理的强大基础。

Mem0

Mem0 是一个专门设计的内存层，旨在为 AI 代理提供保留、适应和个性化其行为在不同用户和会话中的能力。

根据 Mem0 官方文档，此框架具有以下特性：

内存处理：Mem0 利用大型语言模型（LLMs）自动从对话中提取和提炼有意义的见解。它捕捉实体、事件和关系，同时保留完整上下文，使代理能够在无需手动标记或输入格式化的情况下记住相关事实。
双存储架构：Mem0 结合了两个互补的存储系统：
- 一个用于存储记忆语义表示的 向量数据库，针对基于相似性的检索进行了优化。
- 一个用于捕捉和查询实体之间关系的 图数据库，为记忆网络提供结构和可追溯性。

定义

图数据库是一种以图结构存储数据的数据库类型——由节点（实体）和边（实体之间的关系）组成。与传统使用表的传统关系数据库不同，图数据库针对导航和查询关系进行了优化，使其非常适合表示复杂、相互关联的数据，例如社交网络、推荐引擎或知识图谱。

智能检索系统：Mem0 的混合检索引擎同时使用向量搜索和基于图的查询来检索最相关的记忆。它根据重要性、最近性和上下文优先级排序信息，确保代理从其记忆中响应精确且具有意义的引用。
简单的 API 集成：开发者可以通过轻量级的 API 轻松集成 Mem0。它提供了直观的端点来添加新的记忆（添加）和检索上下文相关的记忆（搜索），这使得构建具有记忆功能的代理而无需深入的基础设施工作变得容易。
内存管理：随着新信息的出现，Mem0 更新存储的内存，同时解决不一致性和矛盾。这确保了代理的记忆保持一致和可信，即使随着时间的推移，用户偏好或事实发生变化。

注意，此后的功能——内存管理——是自适应学习的例子。随着代理与用户的交互，Mem0 赋予它们动态优化和扩展其记忆的能力——有效地允许它们“学习”而无需正式重新训练。这种能力在长期部署中特别有益，因为代理需要提供随着用户发展而演变的个性化体验。

总结来说，Mem0 作为人工智能代理的认知骨干，连接短期交互和长期记忆。它对个性化、适应性和灵活部署的重视，使其成为开发者构建能够做到不仅仅是反应的代理的理想选择——它们能够记住、进化并深入参与。

LeTTA（以前称为 MemGPT）

Letta——以前称为 MemGPT——是一个用于构建具有状态、记忆感知的人工智能代理的开源框架。其核心创新在于它如何通过为代理配备长期记忆、多步推理和自适应上下文管理，将传统的无状态 LLM 交互转换为动态的、持续的关系。这意味着基于 Letta 的代理可以在会话之间记住关键事实、用户偏好和先前决策——随着时间的推移，实现真正一致和个性化的对话。

Letta 被设计成模型无关，这允许开发者根据他们的用例选择最佳模型，而无需绑定到特定提供商。Letta 最独特的组件之一是代理开发环境（ADE），这是一个图形界面，它为开发者提供了深入了解代理状态的深度可见性。

通过 ADE，您可以观察代理的推理过程，它访问哪些记忆，使用哪些工具，以及如何响应——提供在其他框架中很少见到的透明和交互式调试体验。

从工程角度来看，Letta 是为了鲁棒性和集成而构建的。它包括完整的 API 和 SDK 支持（通过 REST、Python 和 TypeScript），这使得它很容易集成到新的和现有的应用程序中。其自动持久化层确保每次交互、内存更新和内部状态转换都安全地存储在 PostgreSQL 数据库中。这不仅保证了会话之间的连续性，还支持可审计性和分析。

Letta 还支持 模型上下文协议（MCP），它允许代理动态访问和编排外部工具——例如网络搜索、日历或自定义 API。

定义

MCP 是一个标准化的接口，允许 AI 代理在其推理过程中动态访问、调用和协调外部工具、API 或数据源。它作为语言模型和可用能力库之间的通信层，使代理能够扩展其核心功能，超越文本生成。

在多代理或工具丰富的环境中，MCP 尤其强大，因为灵活性、模块化和协调对于构建智能、自主系统至关重要。

通过结合深度内存集成、灵活的工具、持久状态跟踪和透明可观察性，Letta 成为一个全面的平台，用于开发真正自主、上下文感知的 AI 代理——这些代理在与每个交互中变得更聪明、更有能力。

摘要

内存是智能 AI 代理的基础组件，使它们能够维持上下文、个性化交互并随时间适应。本章探讨了内存类型的范围——短期和长期——及其子类别，包括语义、情景和程序性记忆。

我们探讨了管理 LLM 有限上下文窗口的策略，以及使用结构和语义方法存储、检索和刷新内存的技术。一种混合模型，结合元数据过滤和向量搜索，成为了一种强大的可扩展和相关的内存访问方法。

最后，我们介绍了关键的工具——LangMem、Mem0 和 MemGPT——它们以不同的方式实现内存操作，从工作流感知存储到操作系统启发的上下文管理。

在下一章中，我们将看到如何通过正确定义工具和集成层与周围生态系统，将内存与 AI 代理的“做事”实际能力相结合。

参考文献

语言代理的认知架构：arxiv.org/pdf/2309.02427
什么是人工智能代理记忆？[www.ibm.com/think/topics/ai-agent-memory#:~:text=AI%20agent%20memory%20refers%20to%20an%20artificial%20intelligence,experiences%20to%20improve%20decision-making%2C%20perception%20and%20overall%20performance]( https://www.ibm.com/think/topics/ai-agent-memory#:~:text=AI agent memory refers to an artificial intelligence ,experiences%20to%20improve%20decision-making%2C%20perception%20and%20overall%20performance)
记忆类型：www.psychologytoday.com/us/basics/memory/types-of-memory?ref=blog.langchain.dev
在人工智能代理中的情景记忆提出了应该被研究和缓解的风险：arxiv.org/pdf/2501.11739
使用 LangGraph 掌握长期代理记忆：[saptak.in/writing/2025/03/23/mastering-long-term-agentic-memory-with-langgraph#:~:text=This%20is%20precisely%20the%20challenge%20that%20long-term%20memory,primary%20types%20of%20memory%3A%20semantic%2C%20episodic%2C%20and%20procedural]( https://saptak.in/writing/2025/03/23/mastering-long-term-agentic-memory-with-langgraph#:~:text=This is precisely the challenge that long-term memory ,primary%20types%20of%20memory%3A%20semantic%2C%20episodic%2C%20and%20procedural)
从基本机制到转化机会：记忆持久性：pmc.ncbi.nlm.nih.gov/articles/PMC10867010/
人工智能能否像人类一样遗忘？探索大型语言模型中的记忆动态：ai.gopubby.com/can-ai-forget-like-humans-exploring-memory-dynamics-in-llms-c7a49678c469
回到未来：向大型语言模型的可解释时间推理迈进：arxiv.org/abs/2310.01074
LangMem: github.com/langchain-ai/langmem
Mem0: github.com/mem0ai/mem0
Letta: github.com/letta-ai/letta

免费订阅电子书

新框架、演进的架构、研究动态、生产分解——AI_Distilled 将噪音过滤成每周简报，供实际操作大型语言模型和生成人工智能系统的工程师和研究人员阅读。现在订阅，即可获得免费电子书，以及每周的洞察力，帮助您保持专注并获取信息。

在packt.link/TRO5B订阅或扫描下面的二维码。

第五章：工具和外部集成需求

正如我们在前面的章节中提到的，AI 代理的一个关键特征和区别是它们可以与世界互动。虽然 LLMs 可以理解、推理和生成文本，但它们最终受限于其训练数据和当前上下文窗口中的内容。为了超越被动对话并执行真实、有用的操作——例如预订预约、查询数据库、检索实时信息或执行多步骤工作流程——AI 代理必须配备工具。

工具是代理智能的功能扩展。它们允许代理调用 API、访问外部系统、检索新数据，甚至操作结构化知识库。

在本章中，我们将涵盖以下主题：

AI 代理工具的解剖结构
固定和语义函数
API 和 Web 服务
数据库和知识库
同步与异步调用

到本章结束时，你将了解工具如何将 LLMs 转化为有能力的代理，以及如何设计、连接和管理这些工具来构建智能、面向行动的系统。

技术要求

你可以在本书附带的 GitHub 存储库中找到本章的完整代码：github.com/PacktPublishing/AI-Agents-in-Practice。

AI 代理工具的解剖结构

工具可以定义为 AI 代理“做事”的能力。这些事情可以从抓取网页到发送电子邮件，从获取你的日历预约到对网站执行操作。正如我们将在接下来的章节中看到的，工具可以根据其核心逻辑的设计方式以多种方式有效地赋予代理权力。尽管如此，工具具有一个共同的解剖结构，我们在设计我们的代理应用程序时可以记住这一点。

然而，在直接进入工具的解剖结构之前，我们首先需要弄清楚这些术语。

如第二章所述，当谈论 AI 代理时，你经常会听到任务、工具、技能、插件、功能和动作等术语，这些术语被视为指代代理“做事”能力的可互换方式。你还会看到不同的 AI 编排器带有不同的术语。例如，Semantic Kernel 利用术语插件，而插件又由一个或多个函数组成。另一方面，LangChain 使用术语工具。

尽管我们可以在语义上区分这些术语（插件作为集成，函数作为操作，技能作为专长……），但它们通常指的是相同的概念：代表用户行动的 AI 系统。为了保持一致性，我们将在这本书中始终使用术语工具。

因此，回到工具的解剖结构：AI 代理工具的主要成分是什么？

在高层次上，工具由以下组件定义：

名称，这是工具的唯一标识符。例如，可以在我们的日历中安排预约的工具可以被称为“CalendarTool。”
描述，它定义了工具的功能。正如本书中提到的，这个元素是关键的。实际上，它将成为我们的 AI 代理大脑——LLM——读取的标签，以了解是否调用它（取决于用户的查询），如果是的话，使用哪些参数。例如，CalendarTool 可以有一个如下所示的描述：

此工具与用户的日历集成，能够读取现有会议、安排新会议，以及回忆与日历管理相关的会议和其他活动。

核心逻辑，这是工具的正确引擎。例如，CalendarTool 将具有不同的方法（获取现有会议、创建新会议等），这些方法可以定义为 Python 函数。在以下代码示例中，我们利用 Outlook 作为日历，这意味着我们需要连接到 Microsoft Graph：

def get_outlook_calendar_events(
    access_token: str, date: str = None
):
    """
    Fetches Outlook calendar events for a given date using Microsoft Graph API.
    """
    if not date:
        date = datetime.today().date().isoformat()
    start_datetime = f"{date}T00:00:00"
    end_datetime = f"{date}T23:59:59"
    url = (
        "https://graph.microsoft.com/v1.0/me/calendarview?"
        f"startDateTime={start_datetime}&endDateTime={end_datetime}"
    )
    headers = {
        "Authorization": f"Bearer {access_token}",
        "Content-Type": "application/json"
    }
    response = requests.get(
        url,
        headers=headers
    )

快速提示：使用AI 代码解释器和快速复制功能增强您的编码体验。在下一代 Packt Reader 中打开此书。点击复制按钮

（1）快速将代码复制到您的编码环境，或点击解释按钮

（2）让 AI 助手为您解释一段代码。

下一代 Packt Reader随本书免费赠送。扫描二维码或访问 packtpub.com/unlock，然后使用搜索栏通过名称查找此书。仔细检查显示的版本，以确保您获得正确的版本。

现在，在先前的例子中，该工具的核心逻辑基于 API 集成——实际上，我们正在使用 Microsoft Graph API 执行操作。然而，当我们谈论 AI 工具时，它们背后的核心逻辑可能会根据用例和集成需求而有所不同。

在接下来的章节中，我们将探讨其中的一些。

固定编码和语义功能

此类别指的是由开发者明确定义的逻辑，无论是通过传统的编程结构（固定逻辑）还是使用自然语言描述（语义功能）。

固定编码函数

固定编码函数是代码中实现的逻辑的传统部分。它们是确定性和任务特定的，意味着它们会做开发者告诉它们做的事情。这些函数非常适合简单的实用程序、计算、格式化或不需要外部 API 或学习的业务规则。

例如，我们可以有一个将摄氏度转换为华氏度的工具：

def convert_celsius_to_fahrenheit(celsius: float) -> float:
    return (celsius * 9/5) + 32

我们可以通过添加两个额外的元素：名称和描述，将这个功能封装成我们 AI 代理的工具。在众多实现方法中，我们可以利用 LangChain 的工具装饰器，它会自动推断名称和描述如下（我们将在第六章中广泛介绍 LangChain 的组件和分类）：

@tool
def convert_celsius_to_fahrenheit(celsius: float) -> float:
"""tool to convert temperature from celsius to Fahrenheit"""
    return (celsius * 9/5) + 32

工具将使用函数的名称作为其名称（convert_celsis_to_fahrenheit）和文档字符串作为其描述。AI 代理可以在被询问时调用它，例如，“20 摄氏度等于多少华氏度？”

这类硬编码函数快速、轻量级，且无需外部依赖，使它们非常适合实用逻辑。

语义函数

另一方面，语义函数以自然语言描述，但在底层映射到代码。它们在诸如语义内核这样的框架中特别强大：在这个框架中，分类是插件作为一组函数。当涉及到语义插件时，典型的结构如下。

让我们考虑 Semantic Kernel 框架中可用的内置插件之一，WriterPlugin：

WriterPlugin/
└── Acronym/
        ├── config.json
        └── skprompt.txt
└── AcronymGenerator/
        ├── config.json
        └── skprompt.txt
└── Brainstorm/
        ├── config.json
        └── skprompt.txt
….

此插件包含 16 个功能。每个功能由一个 JSON 文件定义，其中设置了功能的描述和其他配置参数，以及一个文本文件，其中以自然语言描述了适当的语义技能。

让我们以AcronymGenerator函数的结构为例：

这是配置文件：

{
  "schema": 1,
  "description": "Given a request to generate an acronym from a string, generate an acronym and provide the acronym explanation.",
  "execution_settings": {
    "default": {
      "max_tokens": 256,
      "temperature": 0.7,
      "top_p": 1.0,
      "presence_penalty": 0.0,
      "frequency_penalty": 0.0,
      "stop_sequences": [
        "#"
      ]
    }
  }
}

这是文本文件（截断）：

# Name of a super artificial intelligence
J.A.R.V.I.S. = Just A Really Very Intelligent System.
# Name for a new young beautiful assistant
F.R.I.D.A.Y. = Female Replacement Intelligent Digital Assistant Youth.
# Mirror to check what's behind
B.A.R.F. = Binary Augmented Retro-Framing.
# Pair of powerful glasses created by a genius that is now dead
E.D.I.T.H. = Even Dead I'm The Hero.
# A company building and selling computers
I.B.M. = Intelligent Business Machine.
….

如您所见，在文本文件中，没有任何代码；它只是一系列缩写示例，以便提供此特定语义功能的代理能够以适当的方式生成缩写并提供解释（如函数描述中所述）。以下是一个示例：

用户输入：“为魔法传送头盔生成一个缩写”
AI 代理输出（由缩写技能提供支持）：“M.A.G.I.C. = 移动装置，保证即时传达”

通常，当你需要精确性、性能或低级逻辑时，可能会想利用硬编码的功能。另一方面，当你想让 AI 有更多的灵活性，根据自然语言描述来判断一个函数是否相关时，使用语义函数。

现在，当涉及到将你的代理与外部服务集成时，我们需要引入 API 和 Web 服务。

API 和 Web 服务

当扩展 AI 代理或工具的功能时，API 和 Web 服务在连接语言模型到外部世界方面发挥着至关重要的作用。

定义

应用程序编程接口（API）是软件应用程序之间交流的一种方式。它定义了一组规则，说明一个程序如何从另一个程序请求数据或服务——通常是通过互联网。API 无处不在：当您的应用获取天气、加载您的电子邮件或预订 Uber 时，它正在使用 API。

API 通常遵循 HTTP 协议，并使用以下方法：

GET：用于检索数据（例如，获取您所在城市的当前天气）
POST：用于发送新数据（例如，提交新的用户注册表单）
PUT：用于更新现有数据（例如，编辑您的个人资料信息）
DELETE：用于删除数据（例如，从您的账户中删除已保存的地址）

这些操作是所谓的 RESTful API 的一部分——构建网络 API 的一种流行的架构风格。

这些工具作为连接到实时系统的桥梁，使 AI 能够执行操作或从云平台、第三方服务或企业后端检索实时数据。它们本质上在 LLM 的推理和它需要操作的实时、动态数字环境之间架起桥梁。

注意，当我们听到“API”时，我们的思维往往直接跳到像 Google Maps 或 OpenWeather 这样的网络服务，然而，并非所有 API 都是外部的——一些完全存在于您的应用程序或企业环境中。当您为代理构建工具或使用语言模型编排工作流时，这种区别非常重要。

让我们探索你将遇到的主要 API 类型。

网络 API

网络 API 在互联网上公开（或半公开）暴露，通常属于第三方提供商。它们附带文档、速率限制和访问令牌。这些是您在希望您的 AI 检查天气、通过 Slack 发送消息或从金融服务获取股票价格时调用的 API。

注意

网络 API是通过 HTTP 或 HTTPS 远程访问的服务，通常通过 REST 或 GraphQL 公开，允许应用程序检索或操作托管在其他地方的数据。大多数 SaaS 平台都提供面向公众的网络 API。

一些例子包括 OpenWeatherMap API（通过城市获取天气）、Stripe API（处理支付）、Microsoft Graph API（与 Outlook、Teams 和 OneDrive 交互）。

内部或企业 API

许多组织在其防火墙或虚拟网络后面运行内部 API。这些 API 为库存管理、客户数据库、预订引擎或 HR 平台等核心业务系统提供动力。

注意

内部 API 通常需要安全的网络访问（例如 VPN 或 VNet 集成）。

您可以使用内部 API 执行的一些操作示例如下：

GET /orders/{id}：从您的企业资源规划（ERP）系统中获取客户的订单
POST /leave-request：用于创建员工请假申请
GET /pricing-rules：返回内部定价逻辑

如果你正在为企业构建人工智能代理，你使用的工具可能大部分都会与内部 API接口，而不是外部 API。

后端功能 API（服务网格或微服务）

在基于微服务的架构中，不同的服务通过内部 HTTP API 互相通信。这些服务通常被容器化，并可能部署在 Kubernetes 上，位于服务网格，如 Istio 或 Linkerd 之后。

定义

微服务是一种软件架构风格，其中应用程序被分解成更小、可独立部署的服务。每个服务执行特定的业务功能，并通过轻量级协议，如 HTTP API 与其他服务通信。

服务网格是一个基础设施层，以安全、可靠和可观察的方式管理微服务之间的通信。它处理诸如流量路由、负载均衡、服务发现、身份验证和遥测等任务，而不会增加微服务本身的复杂性。

从人工智能的角度来看，这些行为就像任何其他 API 一样——但具有更低的延迟，并且可能不需要互联网访问。当你在构建处理跨内部服务多步逻辑的代理时，它们对于内部编排非常有用。

无服务器函数/轻量级 API

有时候，你可能需要的 API 还不存在。使用 Azure Functions、AWS Lambda 或 Google Cloud Functions 等工具，你可以快速创建自己的轻量级 HTTP 端点，这些端点充当动态工具。

类似的服务利用无服务器模型，这颠覆了传统的托管理念：不是管理服务器、扩展资源或担心基础设施，你只需编写函数，将其部署到云提供商，然后就可以通过 API 调用。

这种方法非常适合人工智能工具开发，因为它允许你启动小型、专注的函数——每个函数执行单个任务，例如总结文档、格式化报告或从系统中获取筛选数据。

一旦你理解了这种模式，可能性是无限的。以下是一些 API 工具在代理系统内部可以做到的例子：

| 场景 | 工具描述 | 示例 API |

| --- | --- | --- |

| “向我的团队发送关于发布的消息。” | 向共享通信平台（如 Slack 或 Teams）发布实时消息。 | Slack Web API：使用 chat.postMessage 向特定频道发布更新。 |

| “在我们的内部财务系统中创建一张新发票。” | 将结构化数据（如客户和金额）推送到安全的内部会计应用程序中。 | 内部财务 API：使用 POST /invoices 在公司的 ERP 系统内创建发票。 |

| “更新内部服务中的订单状态。” | 微服务接收订单状态变更并相应地更新其他服务。 | 订单服务 API：使用 PATCH /orders/{id} 更新后端服务中的订单状态。 |

| “从文档中提取关键词进行标记。” | 一个轻量级函数接收原始文本并返回提取的关键词，用于搜索或元数据。 | Azure Function：使用自定义POST /extract-keywords端点从文本输入中返回关键词。 |

表 5.1：不同任务的 API 示例

通过理解 Web、内部、后端和无服务器 API 之间的区别，你可以设计更智能、更模块化和更安全的 AI 架构。

在构建你的工具时，请自问以下问题：

AI 是否需要与外界交流？Web API。
数据是否被锁定在公司的防火墙后面？内部 API。
这是你的应用程序自己的后端逻辑的一部分吗？微服务。
需要快速且简单的东西？无服务器函数。

通过为任务选择正确的 API 类型，你为你的 AI 代理的成功奠定了基础。

在下一节中，我们将探讨另一类旨在为你的代理添加外部知识的工具。

数据库和知识库

正如我们在本书第一章中探讨的那样，在 ChatGPT 发布后，将外部知识添加到 LLM 是 GenAI 领域中实现的第一项里程碑之一。我们看到了将我们的 LLM 建立在外部知识上的典型模式是检索增强生成（RAG）。然而，有两个主要考虑因素：

数据以各种格式存在，而 RAG 通常适用于非结构化数据（文本、图像、音频…）
当涉及到代理 AI 时，有方法可以使传统的 RAG 管道更加“智能”，这得益于额外的推理层，这是 AI 代理本身的一个特性

从此以后，让我们首先区分两种主要的数据类别。

结构化数据

这是指存在于行、列和模式中的数据——你的经典 SQL 表、CRM 字段和库存记录。这种数据是可预测的、可查询的，并且易于过滤或排序。对于这类数据，工具通常会包装以下内容：

SQL 查询（SELECT * FROM orders WHERE status = 'pending'）
对业务系统的 API 调用（例如 Salesforce、SAP）

第二个示例——对业务系统的 API 调用——属于我们在上一节中介绍的工具类别（API 和 Web 服务）。因此，我们将专注于通过结构化查询与结构化数据库交互的场景。

在 AI 代理和更广泛的 AI 应用背景下，从自然语言查询中启用智能数据库检索的典型综合模式是“文本到查询”方法。这些是高级步骤：

用户以自然语言提出问题——例如：“在美国最畅销的专辑是什么？”

LLM 将查询转换为 SQL 语句——例如：

SELECT album_name, artist_name, units_sold
FROM album_sales
WHERE country = 'US'
ORDER BY units_sold DESC
LIMIT 1;

LLM 从查询结果返回给用户一个写得很好且对话式的答案——例如，SQL 查询返回“在美国最畅销的专辑是老鹰乐队的《最伟大的时刻》，销量达 3800 万张”。

这种方法也适用于其他类型的结构化数据，其查询语言可能不同于 T-SQL。从我们的 AI 代理角度来看，它将归结为我们设置在系统消息级别和工具描述级别的指令集。

非结构化数据

这是一种混乱且信息丰富的数据类型：长篇文本、电子邮件、PDF 文件、音频转录和聊天记录。你不能简单地用WHERE子句查询它——你需要语义理解。

在 LLM 的背景下，我们探讨了非结构化数据通常如何在向量数据库中存储以及如何使用 RAG 管道检索。然而，随着 AI 系统变得更加主动，检索的作用必须演变。代理不仅仅是被动地对输入做出响应的模型；它是一个积极的决策者，评估任务、考虑可用工具并确定如何最好地继续进行。在这种情况下，将向量数据库视为一个动态工具——而不是一个固定步骤——增加了一个重要的推理层。它允许 AI 代理决定是否需要检索，如何制定有效的查询，针对哪个来源，以及如何处理接收到的信息。

这种从静态检索到代理检索的转变使 RAG 变得更加有目的性和目标导向。

让我们考虑以下例子。我们想调查长期 COVID 的症状，为此，我们将依赖存储在向量数据库中的一组临床论文。在传统的 RAG 场景中，当用户查询“长期 COVID 的症状是什么？”时，以下是可能发生的情况的高级视图：

输入：用户直接提交问题。
嵌入和检索：系统将问题转换为向量，并在医学文档的向量数据库中执行相似度搜索。
上下文注入：将最匹配的前 3-5 个文档直接传递给语言模型。
响应生成：模型基于检索到的文档生成答案。

输出很可能是基于最相似语义段落的一个合理的症状总结——但如果没有意识到文档类型、来源可信度或地区、日期或患者类型等上下文信息。

另一方面，在一个代理 RAG 系统中，我们可能会看到以下类似的情况：

理解意图：代理解析问题并确定“长期 COVID”是一个医学术语，用户很可能在寻找可靠的临床总结。
工具选择：它评估其可用的工具并确定在同行评审的医学期刊或官方健康指南文档中进行向量搜索是最合适的。
查询优化：代理重新表述查询以
“SARS-CoV-2 感染后急性后遗症（PASC）的当前临床症状和影响，也称为长期新冠。”
检索和推理：使用这个精细的查询调用向量数据库工具。如果结果缺乏最新研究，代理可能会尝试使用日期过滤器（例如，2022 年后）或切换到另一个知识源（例如，CDC 的结构化 API）。
多源综合：代理提取相关信息，过滤掉重复内容，并组成一个区分常见、罕见和新兴症状的响应。

在这种情况下，结果将是一个基于事实、情境感知的答案，针对用户的需求量身定制，可能包括“成人 versus 儿童”等区别或指出最新发现的时间。

图 5.1：代理 RAG 的示例

这种方法还使得交互更加复杂，因为向量数据库最终将成为我们代理的许多可用工具之一。这意味着 AI 代理可以将检索到的数据与其他工具的输出相结合，或者如果向量数据库缺乏必要的领域覆盖，则完全切换到其他工具。这样做，检索不仅成为后端操作，还是代理更广泛决策循环的一部分。

图 5.2：包含 VectorDB 作为工具的多个工具的 AI 代理示例

将向量数据库作为可调用的工具嵌入，与基于代理的架构原则相一致：自主性、适应性和情境意识。代理现在不仅确定需要检索的内容，还确定为什么值得检索。这一额外的智能层不仅提高了响应的准确性和相关性，还在企业 AI 系统中解锁了全新的工作流程。

同步与异步调用

随着我们构建越来越智能的 AI 代理——能够推理、计划和与外部工具交互的系统——了解这些工具是如何被调用的变得至关重要。在代理工具设计中，一个经常被忽视但至关重要的区别是工具是同步操作还是异步操作。

这不仅仅是一个技术实现细节。工具的执行方式会影响你的代理应用的性能、可扩展性和响应性。

首先，让我们从定义编程中的同步和异步调用概念开始。

图 5.3：同步和异步过程的示例

编程中的同步调用是函数或方法调用，它会阻塞进一步执行，直到完成。程序等待函数返回结果，然后才继续执行下一条指令。这种模式简单直观，易于推理，但在处理如文件 I/O、网络请求或数据库访问等慢速操作时可能导致性能瓶颈。

例如，以下 Python 函数以同步方式读取文件：

# Synchronous file read in Python
with open("report.txt", "r") as file:
    content = file.read()
print("File content loaded.")

在这种情况下，程序将不会打印“文件内容已加载”，直到整个文件被读取。

另一方面，异步调用是一种非阻塞函数调用，允许程序在后台操作完成时继续执行。当结果准备好时，它通过回调、事件或语言依赖的承诺/未来来处理。异步编程对于构建响应性和可扩展的系统至关重要，尤其是在需要同时管理多个 I/O 密集型任务的环境中。

例如，以下 Python 函数以异步方式读取文件：

import aiofiles
import asyncio
async def read_file():
    async with aiofiles.open("report.txt", "r") as file:
        content = await file.read()
    print("File content loaded.")
asyncio.run(read_file())

在这里，程序可以在读取文件的同时继续执行其他任务，这使得它非常适合 I/O 密集型应用。

回到 AI 代理的上下文，同步和异步调用的概念与工具的调用机制密切相关。

图 5.4：AI 代理上下文中同步和异步过程的示例

在同步过程中，代理发出请求并等待响应，然后才进行其他操作。它不能继续进行，直到收到响应。

在人工智能工作流程中，对于以下这类短时运行、可预测的任务来说，这通常是可行的：

单位转换（例如，摄氏度到华氏度）
格式化日期或数字
简单的数据库查找
调用快速 API（例如，本地微服务）

使用异步调用，代理启动调用但不会阻塞它；代理继续前进，并在结果到达时处理它。

这在以下情况下特别有用：

调用慢速或高延迟的 API（例如，第三方服务、外部数据库）
执行 I/O 密集型操作（例如，文件上传、网络爬取）
并行运行多个调用（例如，批量数据查找）

异步工具使您的代理更加响应，并允许它同时处理多个任务，从而提高性能和用户体验。

同步与异步的选择不仅仅是实现细节的问题——它直接影响到您代理的行为：

响应性：异步工具允许代理在等待长时间运行的操作时保持响应性
并行性：异步调用可以批量处理或并发运行，这在从多个来源检索数据时特别有用
错误处理：异步工具可以整合重试逻辑、回退或超时，而不会冻结代理。

让我们来看一个场景。假设你的代理需要从五个区域系统汇总每周的销售报告。同步版本会逐个获取它们——需要 5 倍的时间。异步版本会一次性获取所有报告。

@tool
async def fetch_sales_report(region: str) -> str:
    """Fetches the weekly sales report for a given region."""
    await asyncio.sleep(2)  # Simulated network delay
    return f"{region} sales report: total sales $100k"
async def fetch_all_reports():
    regions = ["North", "South", "East", "West", "Central"]
    tasks = [fetch_sales_report(region) for region in regions]
    results = await asyncio.gather(*tasks)
    return "\n".join(results)

异步模式允许代理在获取一个报告所需的大约时间内获取所有五个报告。

因此，问题是：我应该使用哪种方法？通常，当操作快速且阻塞且不会降低用户体验，或者任务必须按严格顺序执行，并且每一步都依赖于前一步的结果时，你可能想使用同步调用。然而，如果你处理的是高延迟操作，等待会效率低下，并且/或者代理需要同时处理多个任务，异步调用是首选方法。

许多 AI 系统会混合同步和异步工具。这是完全可以的。重要的是要故意设计工具——知道哪些任务可以阻塞，哪些应该是非阻塞的。

例如 LangChain 和语义内核这样的框架支持这两种模式，通常需要你适当地注册工具，以便代理运行时可以处理它们。

摘要

随着 AI 系统从简单的语言处理器发展到能够推理、规划和行动的自主代理，外部工具和集成的角色变得不可或缺。语言模型本身可以解释和生成文本，但正是通过工具——无论是 API、数据库还是特定领域的函数——它们获得了与真实世界互动的能力。这些集成扩展了模型的作用范围，使其能够访问实时信息、触发外部操作以及检索特定领域的知识。无论是同步还是异步，通过符号查询或语义搜索，工具提供了将被动模型转变为主动系统的框架。最终，这些外部组件的深思熟虑的设计和编排定义了现代 AI 代理的智能、可靠性和实用性。

在下一章中，我们将看到所有这些在实际中的应用，因为我们将会构建我们的第一个 AI 代理，利用到目前为止所讨论的所有组件。

参考文献

语义内核插件：learn.microsoft.com/en-us/semantic-kernel/concepts/plugins/?pivots=programming-language-csharp
LangChain 工具：python.langchain.com/docs/how_to/tool_calling/

现在解锁本书的独家优惠

扫描此二维码或访问 packtpub.com/unlock，然后通过名称搜索此书 | |

| 注意：请在开始之前准备好您的购买发票。 |

| --- |

第六章：使用 LangChain 构建你的第一个 AI 代理

在前面的章节中，我们探讨了 AI 代理背后的理论——它们的架构、工具的作用、记忆和规划，以及框架如 LangChain 如何使这些组件的编排成为可能。现在，是时候从理论转向实践了。

在本章中，我们将通过一个实际用例——为数字piadineria的电子商务助手——来介绍构建你的第一个 AI 代理的过程。从理解场景和组装核心构建块到开发和评估代理的性能，你将获得 LangChain 功能的实际经验。你还将探索如何使用 LangSmith 等工具跟踪和观察代理行为，最后，如何将此助手扩展到移动体验。

我们将涵盖以下主题：

LangChain 生态系统简介
开箱即用的组件概述
用例 - 电子商务 AI 代理

到本章结束时，你不仅将拥有一个可工作的 AI 代理原型，你还将了解构建和维护现实应用中智能、值得信赖的助手所需的模式和组件。

技术要求

要复制 Piadineria 餐厅的 AI 助手，请按照以下步骤操作：

克隆项目仓库

首先克隆包含笔记本、源代码和必要资源的 GitHub 仓库：

git clone https://github.com/PacktPublishing/AI-Agents-in-Practice
cd "your_folder"

安装所需的 Python 包

创建一个虚拟环境并安装requirements.txt中列出的依赖项，或者手动安装以下包：

langchain, openai, python-dotenv
faiss-cpu, sqlite3, pandas, requests
langsmith for evaluation and analytics
```
pip install -r requirements.txt 
```
配置环境变量

在项目根目录中创建一个.env文件，包含你的配置密钥：

AZURE_OPENAI_API_VERSION=
AZURE_OPENAI_ENDPOINT=
AZURE_OPENAI_API_KEY=
AZURE_OPENAI_CHAT_DEPLOYMENT_NAME=
LANGSMITH_API_KEY=
LANGSMITH_ENDPOINT=
LANGSMITH_PROJECT=

注意

在这本书中，我们将利用 Azure OpenAI GPT-4o 作为 LLM，其成本为每 1M 个输入 2.50 美元，每 1M 个输出 10 美元（你可以在这里找到整个定价页面：azure.microsoft.com/en-us/pricing/details/cognitive-services/openai-service/?msockid=126c546e17da69082d204197166168f0）。

如果你希望利用免费的 LLM，你可以利用Hugging Face（HF）Hub 及其与 LangChain 的本地集成。安装所需的包：

pip install langchain-huggingface

你将有两个选项：

直接从from_model_id方法加载你的模型：

from langchain_huggingface import HuggingFacePipeline
llm = HuggingFacePipeline.from_model_id(
    model_id="microsoft/Phi-3-mini-4k-instruct", 
    task="text-generation", 
    pipeline_kwargs={ 
        "max_new_tokens": 100, "top_k": 50, 
        "temperature": 0.1, 
    }, 
)
llm.invoke("Your query here")

快速提示：使用AI 代码解释器和快速复制功能增强你的编码体验。在下一代 Packt Reader 中打开这本书。点击复制按钮

（1）快速将代码复制到你的编码环境，或者点击解释按钮

（2）让 AI 助手为你解释一段代码。

新一代 Packt Reader随本书免费赠送。扫描二维码或访问 packtpub.com/unlock，然后使用搜索栏通过名称查找此书。请仔细检查显示的版本，以确保您获得正确的版本。

使用 Hugging Face 端点（您可以通过创建免费层账户来访问它——有关 HF 账户的更多信息请参阅huggingface.co/pricing）：

from langchain_huggingface import HuggingFaceEndpoint
llm = HuggingFaceEndpoint(
    repo_id="meta-llama/Meta-Llama-3-8B-Instruct", 
    task="text-generation", max_new_tokens=100,
    do_sample=False, ) llm.invoke("Hugging Face is")

例如，如果您想从 HF 利用 LangChain 的聊天模型，请使用以下方法：

from langchain_huggingface import (
    HuggingFaceEndpoint, ChatHuggingFace
)
llm = HuggingFaceEndpoint(
    repo_id="microsoft/Phi-3-mini-4k-instruct", 
    task="text-generation", max_new_tokens=512, 
    do_sample=False, repetition_penalty=1.03, )
chat = ChatHuggingFace(llm=llm, verbose=True)

您可以在此处找到完整的教程：python.langchain.com/v0.2/api_reference/huggingface/chat_models/langchain_huggingface.chat_models.huggingface.ChatHuggingFace.html

准备本地资源

确保以下文件和文件夹存在于项目目录中：

piadineria.db：包含产品和供应商的 SQLite 数据库
documents/：包含 PDF 文件（例如，食品安全证书，业主历史）的文件夹
运行购物车 API

在localhost:3000上启动模拟 JSON 服务器以启用购物车管理工具：

json-server --watch cart-data.json --port 3000

熟悉笔记本

打开存储库中提供的 Jupyter 笔记本，并开始与 AI 代理交互以执行以下操作：

查询产品详情
向购物车添加商品
搜索餐厅文档
使用 LangSmith 集成评估代理响应
启动移动应用程序

启动 Streamlit 前端与代理交互（应用程序将在您的 localhost:8080 上运行）：

streamlit run app.py

LangChain 生态系统简介

LangChain 于 2022 年 10 月推出，是一个开源框架，旨在简化由大型语言模型（LLMs）驱动的应用程序的开发。最初，它为开发者提供了将 LLMs 连接到外部数据源和实用工具的工具，从而促进了更动态和上下文感知的应用程序的创建。

随着时间的推移，LangChain 已经从其原始框架演变成为一个全面的生态系统。这种转变是由 AI 应用的日益复杂性和对更强大的工具的需求所驱动的，这些工具可以管理 LLM 驱动的解决方案的整个生命周期。今天，LangChain 包含一系列组件和集成，旨在支持开发者从初始原型设计阶段到部署和持续管理。

图 6.1：LangChain 生态系统

根据官方文档，整个 LangChain 生态系统允许您构建、运行和部署您的 AI 解决方案。让我们根据前面的图示详细说明这三个步骤。

构建 – 架构基础

在生态系统的基础是基础开源库：LangChain 和 LangGraph。

这两个组件代表了 AI 应用逻辑的基本构建块：

LangChain 提供了模块化组件，如链、智能体、工具和内存，以帮助开发者编排 LLM 行为。它侧重于可组合性和集成，使得原型设计和工作流程扩展变得容易。
虽然 LangGraph 较新，但它引入了一种基于状态机的强大范式——一种定义一系列状态及其之间转换的计算模型，由事件或条件控制。它允许开发者使用基于图的抽象来构建多智能体系统和复杂控制流（例如，循环、分支、条件推理）。这对于需要持久状态和复杂规划的应用程序特别有价值。

备注

在本章中，我们将利用 LangChain 作为库，而在下一章处理多智能体系统时，我们将使用 LangGraph。

这些工具共同代表了 LangChain 生态系统的构建时逻辑和控制平面。它们是开源的，确保了灵活性、透明度和社区驱动的创新。

运行 – 运营层

一旦构建了智能体，下一步就是部署。这就是 LangGraph 平台发挥作用的地方。LangGraph 平台提供了一个托管环境来执行以下操作：

主机和部署 LangGraph 智能体或工作流程
启用流式交互
集成人工反馈流程
处理实时并发和状态管理

这个平台弥合了实验和生产之间的差距，抽象出了在云环境中运行 LLM 智能体通常相关的基础设施开销。

补充平台的是集成层（也是开源的），它允许开发者将他们的智能体连接到以下内容：

API 和 webhooks（后者是一种允许外部系统在 LangChain 过程的执行期间发生特定事件时接收实时通知或数据的方式）
矢量数据库和数据存储
外部工具，如计算器、检索系统或第三方服务

这些集成为智能体提供了实用功能，使其能够根据外部数据和系统执行有意义的操作，我们将在下一段中介绍其中的一些。

管理 – 可观察性和迭代

管理往往是现实世界 AI 应用成功的关键。在 LangChain 生态系统中，这由 LangSmith 处理。

LangSmith 是一个商业平台，它解决了这些基本需求：

调试智能体行为
监控使用情况和性能
评估输出质量
管理提示和数据集
标注和反馈循环以实现监督改进

与传统的日志记录或 APM 工具不同，LangSmith 是专门为 LLM 原生应用构建的，不仅提供“发生了什么”的洞察，还提供“为什么发生”的洞察——从提示结构到工具调用和中间推理步骤。

通过将 LangSmith 集成到您的代理开发生命周期中，您确保可以执行以下操作：

跟踪故障或意外输出
评估提示版本或工具逻辑的有效性
持续优化生产中的应用

基于前面的组件，LangChain 生态系统不再只是一个面向开发者的框架——它是一个针对 AI 代理整个生命周期以及更广泛的 AI 解决方案的结构化平台。

在下一节中，我们将深入了解一些在“构建”级别可以利用的预构建组件，以及我们将用于初始化我们的 AI 代理的组件。

现成组件概述

LangChain 提供了一套全面的预构建组件，这些组件有助于开发复杂的语言模型应用。这些组件被组织成四个主要类别：检索增强生成（RAG）、存储和索引、提取和代理：

RAG：正如我们在前面的章节中所探讨的，RAG 允许语言模型通过从外部来源（通常是文档存储或向量数据库）动态检索相关信息来超越其静态知识，在生成响应之前。LangChain 为完整的 RAG 生命周期提供原生支持：
- 文档摄入和分块：源材料（如 PDF、Notion 页面、HTML 或 markdown）通过灵活的 TextSplitters 加载并分解成语义上有意义的片段。这些片段对于嵌入和检索更易于管理。
- 嵌入生成：每个片段都使用嵌入模型（例如 OpenAI、Cohere、Hugging Face）嵌入到高维向量中。
- 向量数据库中的存储：这些向量存储在可插拔的向量存储中，如 FAISS、Chroma、Weaviate 或 Pinecone，允许基于相似性的高效检索。
- 检索器接口：LangChain 支持基本的检索器和高级检索策略，如 MultiQueryRetriever、ParentDocumentRetriever 和 ContextualCompressionRetriever，每个都针对具有不同精度、召回率和相关性的用例进行设计。

RAG 对于文档问答、法律助手、客户支持机器人以及研究副驾驶等应用至关重要——任何需要实时外部数据定位的场景。

存储和索引：支持 RAG 管道的工具套件专门用于存储和索引。这些组件处理数据的后端准备，确保在检索时可以高效访问：
- 文档加载器：LangChain 包含超过 50 种针对各种数据源的文档加载器，如本地文件、API、网页、Notion 数据库、Google Docs 等。这些加载器将内容标准化为 LangChain 的文档格式。
- 文本分割器：这些工具根据字符数、句子或递归启发式方法分割文档，同时保持内容的逻辑完整性（例如，保持段落或标题与内容相连）。
- 向量存储：LangChain 通过通用接口支持与众多向量数据库的集成。开发者可以在 FAISS、Chroma、Qdrant 或 Azure Cognitive Search 之间切换，而无需更改他们的检索逻辑。
- 元数据和过滤：嵌入的元数据（如来源、日期或主题）与文档块一起存储，允许进行过滤或混合检索，其中结合了关键词和向量搜索。

这一层是任何依赖大规模结构化或半结构化知识访问的系统的基础。

提取：LangChain 还提供了信息提取的能力，这涉及到从非结构化文本中识别和结构化特定的信息片段。这在需要从文档、聊天或响应中挖掘数据并将其以结构化形式（例如 JSON 或数据库记录）提供的领域中非常有用：
- 实体提取：开发者可以定义命名实体或键值对的模式，语言模型将提取匹配的信息（例如，从简历、发票或临床笔记中提取）。
- 自定义模式解析器：开发者可以使用 Pydantic 或 TypedDict 指导 LLM 输出结构化格式的数据，这些数据随后可以被验证、存储或用于下游应用。
- 结构化输出解析器：LangChain 提供了工具来强制执行结构化输出，减少了在敏感用例中出现幻觉或格式错误的可能性。

应用案例包括自动填写表格、将会议记录总结到 CRM 字段中、将法律文本转换为条款映射或从事件描述中提取时间线。

代理：LangChain 中的代理框架引入了更高层次的自主性和灵活性。与静态链不同，代理可以推理任务，选择使用哪个工具，并根据中间步骤的结果进行适应：
- 工具抽象：工具是带有元数据（名称、描述、输入模式）的 Python 函数，代理在相关时可以调用这些工具。LangChain 与 OpenAI 的函数/工具调用能力无缝集成。
- 工具集：为常见平台（如 SQL 数据库、文件系统、Python REPL 或浏览器自动化）提供了预包装的工具集。工具集大大缩短了生产时间。
- 代理执行器：这些组件编排代理的推理循环，跟踪记忆，调用工具并管理中间输出。选项包括 ReactAgent、OpenAIToolsAgent 和 ChatConversationalAgent，具体取决于所需的层次结构和灵活性。
- 多工具推理：代理可以通过链式调用工具、解释结果和规划下一步行动来执行多步骤任务——非常适合复杂的工作流程，如“寻找供应商、检查库存、生成报价”。

LangChain 代理可以像动态助手一样行事，跨各种系统编排逻辑，无论是客户支持、销售自动化还是研究任务。

即使不是详尽的——并且随着时间的推移不断更新——上述列表也让你对 LangChain 预构建组件背后的“模型”有一个概念。事实上，这四个组件类别反映了 LangChain 致力于构建不仅仅是 LLM 包装器，而是可组合的 AI 系统——正如我们多次提到的，模块化和可组合性是关键，尤其是在构建代理系统时！

通过抽象化常见的挑战——例如如何摄取文档、存储和检索知识、提取结构化数据或跨工具进行推理——LangChain 使开发者能够自信地专注于构建智能、可扩展和现成的 AI 解决方案。

现在我们已经拥有了构建第一个 AI 代理所需的所有工具，让我们开始编码吧！

用例 - 电子商务人工智能代理

人工智能代理正在重塑企业与客户互动的方式——提供个性化、实时且感觉像对话般的功能性帮助。在食品和零售行业，这种转变开辟了增强客户体验、简化运营和通过智能自动化建立品牌忠诚度的新可能性。在本节中，我们将探讨该行业的一个具体例子。

场景描述

我们将构建一个针对现实场景的 AI 代理：一家现代的家庭经营意大利餐馆，名为Mammachepiada。这家披萨饼店以表达"Mamma che piada!"命名，该表达大致翻译为“哇，多好的披萨饼啊！”——最近通过推出在线商店扩大了其业务。

在其核心，Mammachepiada 以新鲜制作的披萨饼而闻名，饼内填充着高质量的意大利食材：生火腿、斯特拉奇诺奶酪、烤蔬菜、晒干的番茄等。但除了这些即食餐点之外，这家店还向想要在家重现体验的顾客出售单个食材——如手工奶酪、腌制蔬菜和橄榄油。

该业务作为一个电子商务商店运营，顾客可以执行以下操作：

订购新鲜制作的披萨饼和餐点进行本地配送（在一定距离内）
购买全国范围内配送的食材和产品

本章的目标是创建一个数字助手——人工智能代理，它能帮助客户以自然的方式与商店互动。用户可能想执行以下任何一项：

检查菜单上有什么
询问产品成分
询问库存中可用的商品
获取 piadina 搭配建议
创建定制的购物车并下单

代理将准备好帮助完成这些任务。

结果将是一个友好、高效的界面，将Mammachepiada的魅力带入数字世界——将传统与科技、语言与行动相结合。

我们将把我们的 AI 代理称为AskMamma。

在接下来的章节中，我们将逐步讲解如何创建这个人工智能代理界面，集成检索能力、外部工具和逻辑，以自然的方式处理现实世界的交互。

AskMamma 的构建模块

在第一章中，我们概述了人工智能代理的主要成分：

图 6.2：人工智能代理的解剖结构

让我们现在进一步详细说明它们来设计 AskMamma：

图 6.3：AskMamma 代理的解剖结构

让我们探索图 6.3中显示的每个组件：

UI: 人工智能代理将存在于餐厅移动应用程序的上下文中。在本节中，我们将逐一关注核心组件，而在下一节中，我们将通过 Streamlit UI 看到最终结果。
LLM: 我们将使用 Azure OpenAI GPT-4o，因为它提供了最先进的推理能力，同时优化了延迟——使其非常适合实时餐厅交互。

注意

选择 LLM 意味着平衡以下因素：
- 质量与成本: 如 GPT-4o 这样的大模型更智能，但价格也更贵。
- 速度与力量: 更快的模型响应迅速，但可能错过细微之处。
- 上下文需求: 长对话或大文档？使用具有更大上下文窗口的模型。
- 多模态: 如果您的代理需要查看图像，请选择 GPT-4o。
选择最适合您应用程序需求的模型——不仅仅是最大的一个。
系统消息: 我们正在指导代理成为一个有用的 AI 助手，为意大利餐厅服务。
编排: 我们将利用 LangChain 进行编排，利用 LangSmith 进行可观察性和可追溯性。
记忆: 我们的代理将被赋予短期记忆，以跟踪正在进行的对话。
知识库: 我们的代理将了解餐厅业主多年来获得的所有相关证书和奖项。
工具: 除了提到的 RAG 工具之外，我们还将有两个额外的工具：
数据库工具: 此工具将检索库存商品、价格、供应商、过敏原和其他相关信息。
添加到购物车工具：这将是一个 API 工具，将与餐厅应用的后端进行通信。实际上，用户的购物车由数据库驱动，该工具将根据用户的查询向数据库添加项目。

注意，在这个场景中，我们使用三种不同类型的工具：一个非结构化知识库和一个结构化数据库作为检索器，以及 API 集成。

注意

我们将把知识库视为实现中的一个工具，利用在第五章中探讨的 agentic RAG 概念。

现在我们来看看如何在实践中实现这一点。

开发代理

让我们一步步地看看如何构建 AskMamma 代理：

导入库和初始化模型：在这里，我们将初始化我们需要的两个模型：LLM，它将作为代理的大脑（Azure OpenAI GPT-4o），以及我们将用于向量化并索引我们的非结构化 PDF 的嵌入模型（Azure OpenAI text-embedding-3-large）。

import os
from dotenv import load_dotenvfrom langchain_openai import (
    AzureChatOpenAI
)
import requests
from langchain.agents import (
    AgentExecutor, create_openai_tools_agent
)
from langchain_core.prompts import (
    ChatPromptTemplate, MessagesPlaceholder
)
from langchain.tools import BaseTool, StructuredTool, tool
# Load environment variables from .env file
load_dotenv()
# Access the environment variables
openai_api_version = os.getenv("AZURE_OPENAI_API_VERSION")
azure_endpoint = os.getenv("AZURE_OPENAI_ENDPOINT")
openai_api_key = os.getenv("AZURE_OPENAI_API_KEY")
azure_chat_deployment = \
    os.getenv("AZURE_OPENAI_CHAT_DEPLOYMENT_NAME")
# Initialize the Azure OpenAI model
model = AzureChatOpenAI(
    openai_api_version=openai_api_version,
    azure_deployment=azure_chat_deployment,
)
from langchain_openai import AzureOpenAIEmbeddings
embeddings = AzureOpenAIEmbeddings(
    api_key = openai_api_key,
    azure_deployment="text-embedding-3-large"
)

初始化 SQL 工具：在这里，我们将利用 LangChain 的一个预构建组件，SQLDatabaseToolkit。这是一个可以与 SQL 数据库协同工作并执行许多任务的工具集——包括但不限于推断模式、运行查询和检查查询正确性。

要初始化工具包，你需要一个 LLM 和一个 DB 实例。对于后者，我们将使用一个具有以下模式的 SQLite 实例：

图 6.4：餐厅数据库结构

您可以在本书的 GitHub 仓库中找到数据库。

现在我们来初始化工具包和列表中的第一个工具：

from langchain_community.utilities.sql_database import SQLDatabase
db = SQLDatabase.from_uri("sqlite:///piadineria.db")
from langchain_community.agent_toolkits.sql.toolkit import (
    SQLDatabaseToolkit
)
sql_toolkit = SQLDatabaseToolkit(db=db, llm=model)
sql_toolkit.get_tools()[0]

这里是输出结果：

[QuerySQLDatabaseTool(description="Input to this tool is a detailed and correct SQL query, output is a result from the database. If the query is not correct, an error message will be returned. If an error is returned, rewrite the query, check the query, and try again. If you encounter an issue with Unknown column 'xxxx' in 'field list', use sql_db_schema to query the correct table fields.", db=<langchain_community.utilities.sql_database.SQLDatabase object at 0x00000256933169F0>)]

如您所见，该工具附带一个名称（QuerySQLDatabaseTool）及其功能描述，这样代理就能知道何时调用它。

初始化添加到购物车工具：在这里，我们需要编写一个适当的 HTTP 操作来将项目添加到我们餐厅应用的后端数据库中。为此，我们首先需要准备一个 DB 实例，该实例将在会话的上下文中托管用户的物品。在这种情况下，我初始化了一个空的db.json对象，如下所示：

{
  "cart": []
}

在运行代理之前，我们需要确保这个数据库是在线的（我们将在本演示中本地运行它）。

注意

这个数据库与 SQL 工具部分提到的 SQL 数据库不同！让我们明确地区分两者：

SQL 数据库：这是餐厅的记录存储系统，业主可以跟踪库存物品、价格、供应商等。

db.json：这是在会话上下文中为用户购物车提供动力的数据库。它是应用程序数据库。

现在我们有了购物车数据库，我们可以定义我们的工具：

# Define the tool to add an item to the cart
@tool
def add_to_cart(item_name: str, item_price: float) -> str:
    """Add an item to the cart."""
    url = 'http://localhost:3000/cart'  # Ensure this matches the JSON Server endpoint
    cart_item = {
        'name': item_name,
        'price': item_price
    }

    response = requests.post(url, json=cart_item)

    if response.status_code == 201:
        return f"Item '{item_name}' added to cart successfully."
    else:
        return f"Failed to add item to cart: {response.status_code} {response.text}"

如您所见，我们使用 LangChain 的典型装饰器 @tool 定义了我们的工具。然后，我们添加了一个名称（add_to_cart）和描述（格式为 """docstring"""）。我们还指定了此工具正确调用所需的两个参数：物品的名称和相对价格；这意味着代理将尽力在调用工具之前检索这两个元素。最后，“正确的行为”是对实时购物车数据库端点的 POST 方法。

初始化 RAG 工具：在这里，我们希望将我们的代理与餐厅食品合规证书和多年来获得的奖项相关的某些上下文联系起来。以下是从提供的 PDF 中提取的几个段落的示例：

图 6.5：我们将用作知识库的食品证书快照

快速提示：需要查看此图像的高分辨率版本吗？在下一代 Packt Reader 中打开此书或查看 PDF/ePub 版本。

要创建我们的工具，我们首先需要将我们的 PDF 文件正确地向量化并索引到向量数据库中。为此，我们将使用 LangChain 中的某些预构建组件进行文档处理，并且作为存储，我们将使用 FAISS 向量数据库。

定义

Facebook AI 相似度搜索（FAISS）是由 Meta AI 开发的一个开源向量数据库和库，用于高效地进行密集向量的相似度搜索和聚类。它能够快速检索高维向量，非常适合用于语义搜索、推荐系统和基于 LLM 的检索等应用。

让我们从初始化我们的 vectore_store 对象开始。

import faiss
from langchain_community.docstore.in_memory import InMemoryDocstore
from langchain_community.vectorstores import FAISS
#Create a FAISS index using L2 (Euclidean) distance with the same #dimensionality
#as the output of the embedding function (e.g., length of a single embedded #vector)
index = faiss.IndexFlatL2(len(embeddings.embed_query("hello world")))
vector_store = FAISS(
    embedding_function=embeddings,
    index=index,
    docstore=InMemoryDocstore(),
    index_to_docstore_id={},
)

然后，我们可以利用 LangChain 的库来分块和处理我们的文档：

from langchain_text_splitters import CharacterTextSplitter
from langchain.document_loaders import PyPDFDirectoryLoader
file_path = (
    "documents"
)
loader = PyPDFDirectoryLoader(file_path)
documents = loader.load()
text_splitter = CharacterTextSplitter(
    chunk_size=1000, chunk_overlap=0
)
docs = text_splitter.split_documents(documents)

注意，在这种情况下，我们利用了一个文本分割库——CharacterTextSplitter，它根据字符数来分割文本。然而，LangChain 提供了多种类型的文本分割器，可以将大型文档分割成更小的、可管理的块，然后再将它们输入到向量存储中。其中一些最受欢迎的类型包括以下几种：

RecursiveCharacterTextSplitter（推荐）：尝试在更有意义的边界上进行分割（例如，段落 → 句子 → 单词 → 字符）。如果块太大，它会递归地回退到更小的单元。
TokenTextSplitter: 基于标记计数进行分割（适用于具有严格标记限制的 LLM，例如 OpenAI 的 GPT 模型）。对于将输入与模型上下文窗口对齐非常有效。
NLTKTextSplitter / SpacyTextSplitter：使用 NLP 库中的句子分割进行语言感知的分割器。适用于需要更多句法保留的用例。

一旦我们将文档分割成可管理的块并将它们传递给vector_store.add_documents()，每个块都会使用嵌入模型转换成高维向量表示。

vector_store.add_documents(documents=docs)

这些向量随后在向量存储中索引，以便稍后进行相似度搜索。以下是一个示例：

Chunk 1: "Mozzarella is an Italian cheese..."  Vector: [0.21, -0.45, ...]
Chunk 2: "Prosciutto pairs well with melon..."  Vector: [0.67,  0.10, ...]
Chunk 3: "Our piadine are made fresh daily..."  Vector: [0.33, -0.88, ...]

这些嵌入存储在向量数据库中，并附带元数据（例如，源文档 ID，原始文件中的位置）。当用户提问时，他们的查询也会被嵌入并与存储的向量进行比较，以检索最相关的块。

此过程允许系统根据语义意义“检索”知识，而不仅仅是关键词。

现在我们已经拥有了创建我们的 RAG 工具的所有成分：

retriever = vector_store.as_retriever()
from langchain.tools.retriever import create_retriever_tool
rag_tool = create_retriever_tool(
    retriever,
    "document_search",
    """
    Search and return information about restaurant's health certificate and owner's history.
    """
)

正如你所见，LangChain 中的vector_store对象自带一个方法（.as_retriever），它可以将它自动转换为检索对象。通过这样做，我们可以使用create_retriever_tool函数创建我们的工具，正如我们在许多示例中学到的，这将需要一个工具名称和工具功能的描述。

初始化系统消息：在创建代理之前，我们需要最后一个成分，即系统消息。在 LangChain 中，我们可以利用专为结构化基于聊天的语言模型提示而设计的ChatPromptTemplate类。

它具有以下关键特性：

基于角色的消息：定义具有特定角色的消息，以设置对话的上下文和流程。
动态变量：在消息中包含占位符，可以在运行时用用户输入或其他动态数据填充。
上下文管理：使用如MessagesPlaceholder之类的占位符维护对话历史和中间步骤，使 AI 能够生成连贯且与上下文相关的响应。

通过使用 ChatPromptTemplate，你可以创建动态和上下文感知的提示，这些提示包含变量和占位符。

对于我们的 AskMamma 代理，我们将有以下结构：

# Define the prompt template
prompt = ChatPromptTemplate.from_messages(
    [
        ("system", """You are an AI assistant for a Piadineria Restaurant.
            You help customers explore the menu and choose the best piadine or Italian specialties through friendly, interactive questions.
            When the user asks for product details (ingredients, allergens, vegetarian options, price, etc.), you can query the product database.
            Once the user is ready to order, ask if they'd like to add the selected item to their cart.
            If they confirm, add the item to the cart using your tools.
            When using a tool, respond only with the final result. For example:
            Human: Add Classic Piadina to the cart with price 5.50
            AI: Item 'Classic Piadina' added to cart successfully.
        """),
        MessagesPlaceholder("chat_history", optional=True),
        ("human", "{input}"),
        MessagesPlaceholder("agent_scratchpad"),
    ]

让我们将它分解为其三个主要组件：

系统消息：这是设置 AI 整体行为和边界的指导性消息。

("system", """You are an AI assistant for a Piadineria Restaurant. ...""")

MessagesPlaceholder(“chat_history”)：这是一个动态占位符，将完整的对话历史（如果可用）插入到提示中，以便 AI 了解已经说过什么。请注意，它被标记为optional=True，因此聊天可以从头开始或继续进行中的会话。
带有输入占位符的人类消息：这是当前用户消息被插入的地方。{input} 占位符将在运行时被替换为用户刚刚输入的内容（例如，“你们有不含麸质的选项吗？”）。
```
("human", "{input}") 
```
MessagesPlaceholder(“agent_scratchpad”)：这是在工具增强工作流程中注入中间代理推理或工具使用痕迹的地方。

注意

这种结构化格式非常适合基于代理的系统，其中以下条件适用：
- 你需要持久化内存（chat_history）
- 代理可以调用工具（例如添加到购物车、查询产品）
- 你希望一开始就给出清晰的行为指令（通过系统消息）。
这确保了 AI 的行为一致，适应上下文，并像真实助手一样执行动作——不会产生幻觉或超出其允许的范围进行响应。

初始化代理：我们现在有了初始化代理的所有成分。为此，我们将利用 LangChain 中可用的预构建函数 create_openai_tools_agent，该函数旨在构建利用 OpenAI 工具调用能力的 AI 代理。

定义

OpenAI 的工具调用能力，以前称为函数调用，使语言模型能够以结构化和动态的方式与外部工具或函数交互。在人工智能代理的新领域，工具调用成为更大编排谜题的一部分，正如我们多次提到的，我们在 LLM 上添加了一个额外的智能层，这样我们就可以赋予代理决定是否使用工具、选择调用哪个工具、将工具链在一起、计划并执行后续动作等的能力。因此，尽管工具调用的机制仍然存在，开发者们正从编写原始工具调用逻辑转向处理这种推理的代理接口。

让我们初始化它：

# Setup the toolkit
toolkit = [rag_tool, add_to_cart, *sql_toolkit.get_tools()[:4]]
from langchain_community.chat_message_histories import(
    ChatMessageHistory)
from langchain_core.runnables.history import( 
    RunnableWithMessageHistory)
message_history = ChatMessageHistory()
# Construct the OpenAI Tools agent
agent = create_openai_tools_agent(model, toolkit, prompt)
# Create an agent executor by passing in the agent and tools
agent_executor = AgentExecutor(agent=agent, tools=toolkit, 
    verbose=True)
agent_with_chat_history = RunnableWithMessageHistory(
    agent_executor,
    # This is needed because in most real world scenarios, a session id is needed
    # It isn't really used here because we are using a simple in memory ChatMessageHistory
    lambda session_id: message_history,
    input_messages_key="input",
    history_messages_key="chat_history",
)

现在是时候测试它了。在运行我们的代理之前，我们需要部署 db.json，这样代理就可以在需要时从 add_to_cart 工具正确执行 POST 请求。要运行你的数据库，你可以在你的终端中执行以下命令：

npm install -g json-server
cd path_to_your_db
json-server --watch db.json

现在您的 db.json 正在您的本地主机上以端口 3000（默认端口）运行：

图 6.6：作为本地主机运行的应用数据库

太好了，现在我们可以运行我们的代理了。为了模拟对话，我将使用一个 while 循环：

# Interactive loop
while True:
    user_input = input("Type your question here (or type 'exit' to quit): ")
    if user_input.lower() == 'exit':
        break
    result = agent_with_chat_history.invoke(
        {"input": user_input},
        # This is needed because in most real world scenarios, a session id is needed
        # It isn't really used here because we are using a simple in memory ChatMessageHistory
        config={"configurable": {"session_id": "<foo>"}
    )
    print(f'User: {user_input}')
    print(f'AI: {result['output']}')

在运行代码后，我发送了以下输入（请注意，我发送了一些假设保留先前上下文的问题来测试短期记忆）：

“你好”
“你们有什么食品证书？”
“你们有意大利干酪吗？”
“是的，加到购物车”
“这个商品是由哪个供应商提供的？”

让我们看看结果。注意，我保持了代理的详细输出，这意味着我们可以看到中间步骤和工具输出。以下输出在中间步骤中被截断，但您可以在 GitHub 仓库中看到完整版本。

为了使以下内容更易于阅读，我将突出显示用户输入、AI 输出和推理步骤。在它们之间，我将添加我的评论来突出一些值得注意的特定代理模式：

`User: Hello`
**The agent understands that this is a simple interaction that requires no specific tool.**
`AI: Hi there! Welcome to our Piadineria Restaurant. How can I assist you today? Are you looking to explore our menu or need help with something specific?`
`User: Which food certificates do you have?`
**The agent understands that it needs to invoke the specific RAG tool with a specific query to answer this question.**

> Entering new AgentExecutor chain...
Invoking: `document_search` with `{'query': 'food certificates'}`
Piadineria Hygiene & Food Safety Compliance Report
Page 2: HACCP Certification
Hazard Analysis […]
> Finished chain.

`AI: We have several food safety certificates and compliance measures in place:`
`1\. **HACCP Certification**: We have a fully documented Hazard Analysis and Critical Control Points (HACCP) system that identifies and monitors all critical control points in the preparation of our products. This system is reviewed and audited quarterly by an external certification body.`
`2\. **Local Food Safety Training & PIC**: Every food handler in our piadineria completes accredited food safety training in accordance with local regulations. We also have a Person In Charge (PIC) at each location to supervise hygiene standards and enforce best practices.`
`Would you like to know more about our menu or anything else?`
`User: Do you have ricotta cheese in stock?`
**The agent understands it needs to invoke some SQL tools for that. First, it needs to understand the schema with the sql_db_list_tables and sql_db_schema tools, then it will run the actual query with `sql_db_query`.**

> Entering new AgentExecutor chain...
Invoking: `sql_db_list_tables` with `{}`
responded: Let me check the availability of ricotta cheese for you. I'll need a moment to look it up.
products, suppliers
Invoking: `sql_db_schema` with `{'table_names': 'products'}`
[…]
Invoking: `sql_db_query` with `{'query': 'SELECT * FROM products WHERE "Product Name" = \'Ricotta Cheese\''}`
[…]
> Finished chain.

`AI: Yes, we do have ricotta cheese in stock! Here are the details:`
`**Product Name**: Ricotta Cheese`
`**Category**: Cheese`
`**Price**: $7.75`
`**Stock**: 15 units`
`**Allergens**: Dairy`
`**Description**: Creamy ricotta cheese, ideal for desserts or pasta.`
`**Calories**: 120`
`**Vegetarian**: Yes`
`Would you like to add this to your cart or need help with anything else?`
`User: Yes, add it to cart`
**The agent understands it needs to invoke the add_to_cart tool and it is able to retrieve the two parameters needed – name and price – from the previous conversation.**

> Entering new AgentExecutor chain...
Invoking: `add_to_cart` with `{'item_name': 'Ricotta Cheese', 'item_price': 7.75}`
Item 'Ricotta Cheese' added to cart successfully.The Ricotta Cheese has been successfully added to your cart. Is there anything else you would like to add or any other assistance you need?
> Finished chain.

一旦这个工具被执行，如果你重新运行你的 db.json 服务器，你会看到它已经相应地更新了：

图 6.7：填充了项目后的应用程序数据库

`AI: The Ricotta cheese has been successfully added to your cart. Is there anything else you would like to add or any other assistance you need?`
`User: And who is the supplier for the item?`
**The agent is able to invoke once more the SQL tools and, this time, is going to perform a join operation as well to look up the two tables and extract the Ricotta Cheese's supplier. Plus, we didn't specify the item but rather relied on the context-awareness of our agent.**

> Entering new AgentExecutor chain...
Invoking: `sql_db_list_tables` with `{}`
products, suppliers
Invoking: `sql_db_schema` with `{'table_names': 'products, suppliers'}`
[…]
Invoking: `sql_db_query` with `{'query': 'SELECT suppliers."Supplier Name" FROM suppliers JOIN products ON suppliers."Supplier ID" = products."Supplier ID" WHERE products."Product Name" = \'Ricotta Cheese\''}`
[…]
> Finished chain.

`AI: The supplier for our Ricotta Cheese is **Dolce Italia**.`
`Is there anything else you would like to know or add to your order?`
`User: Thanks!`
`AI: You're welcome! If you have any other questions or need further assistance, feel free to ask. Enjoy your meal!`

如您所见，代理能够做到以下几点：

根据用户的请求调用合适的工具，多亏了每个工具配备的自然语言描述
在用户会话的上下文中保持记忆
以对话方式与用户互动

只需三个工具，我们就能够通过一个强大的代理来提升用户体验。

然而，我们还缺少一个重要的拼图碎片：我们如何监控代理的行为？实际上，在现实世界的场景中，可观察性、可追溯性，以及评估和持续改进，在设计你的端到端架构时是关键要素。

在下一节中，我们将探讨如何用几行代码来实现这一点。

可观察性、可追溯性和评估

可观察性、可追溯性和评估是实现这些目标的关键组成部分。它们提供了对人工智能代理内部运作的见解，促进了调试，并使持续改进成为可能。

可观察性指的是根据系统的外部输出理解系统内部状态的能力。在人工智能代理中，这涉及到监控输入、输出、中间过程以及与外部工具或 API 的交互。可追溯性通过提供代理决策过程的详细记录来补充可观察性，包括采取的动作序列和背后的理由。共同作用，它们使开发者能够定位问题、理解代理行为并确保系统按预期运行。

评估涉及根据预定义的指标或基准来评估人工智能代理的性能。这可能包括准确性、相关性、连贯性或其他特定领域的标准。定期的评估有助于确定改进领域、验证更新并确保代理达到期望的标准。它还在维护用户信任和满意度方面发挥着至关重要的作用。

注意

根据任务和上下文，可以使用几种方法来评估人工智能代理。以下包括以下内容：
人工评估，其中人类评判者评估代理响应的质量或有用性。
LLM 作为裁判，其中可信模型（例如 GPT-4）对响应进行评分以评估相关性或准确性。
知识库（KB）验证，对于检索增强系统中的检索文档的正确性很重要。
自动指标，如 BLEU、ROUGE 或对摘要或问答等任务的精确匹配。

选择正确的方法取决于您是在评估推理、事实准确性还是用户满意度。

然而，随着 AI 代理变得更加复杂——能够推理、使用工具并保持多轮记忆——对强大可观察性和评估的需求变得至关重要。与传统的软件系统不同，其中错误通常可以追溯到特定的代码行或逻辑分支，AI 代理在概率性和动态环境中运行。他们的决策不仅取决于输入数据，还取决于提示结构、检索的上下文、工具交互和之前的对话轮次。这使得调试和性能评估本质上更加困难。为了解决这个问题，像 LangSmith 这样的工具应运而生，提供了一种结构化的方式来实时监控、跟踪和评估代理行为。

LangSmith – LangChain 生态系统的一部分 – 是一个旨在增强 AI 应用程序的可观察性、可追溯性和评估的平台。它提供用于记录和可视化代理交互、分析性能指标和进行系统评估的工具。

LangSmith 的关键特性包括以下内容：

执行跟踪：可视化代理的逐步决策，包括输入、输出和工具使用
性能洞察：监控关键统计数据，如延迟、令牌计数和错误模式，以优化您的系统
灵活的评估：运行具有内置或自定义逻辑的结构化评估，以评估响应质量
提示版本控制：跟踪、比较和迭代提示，以随着时间的推移改进代理行为
协作友好：与您的团队共享运行、反馈和评估以支持联合开发

LangSmith 与各种 AI 框架无缝集成（不仅限于 LangChain！），提供了一个统一的接口来监控和改进 AI 代理。

让我们看看实际应用。

第一步是在以下链接的 LangSmith 设置页面上创建 API 密钥：smith.langchain.com/settings。

图 6.8：LangSmith 管理门户

注意，如果您还没有账户，您将被要求注册（这是免费的）。

然后，您可以安装 LangSmith 依赖项：

pip install -U langsmith

使用您的变量设置您的环境。在我们的案例中，因为我们在一个 Jupyter 笔记本中演示代理，我将使用 os 模块直接初始化我的变量，同时创建我的 LangSmith 客户端：

from langsmith import Client
client = Client(
    api_key=os.getenv("LANGSMITH_API_KEY"),
    api_url=os.getenv("LANGSMITH_ENDPOINT"), 
)

现在我们已经拥有了初始化 LangChainTracer 对象的所有要素，这是一个 LangChain 中的专用回调处理程序，旨在捕获应用程序组件（如链、工具和语言模型交互）的详细执行跟踪，并将此信息发送到 LangSmith。

from langchain.callbacks.tracers import LangChainTracer
tracer = LangChainTracer(client=client, project_name="askmamma")

如您所见，LangChainTracer 使用客户端和一个可选的 project_name 参数初始化 – 这将标记我们的日志将被保存和分析的文件夹。此跟踪器挂钩到 LangChain 的执行流程中，捕获事件，如链的开始和结束、工具调用和语言模型调用。

跟踪器是我们需要添加到现有代理的唯一附加元素。我们可以在调用代理时将其作为配置参数传递，如下所示：

agent_with_chat_history.invoke(
        {"input": user_input},
        # This is needed because in most real world scenarios, a session id is needed
        # It isn't really used here because we are using a simple in memory ChatMessageHistory
        config={"configurable": {"session_id": "<foo>"}, 
            **"callbacks"****: [tracer]},**
    )

此配置确保代理执行的每一步都会记录到 LangSmith，让您能够可视化操作序列，检查输入和输出，并识别任何错误或性能瓶颈。

例如，一旦我们运行我们的代理，我们将在 LangSmith 仪表板上看到一个新的项目被初始化：

图 6.9：LangSmith 的跟踪项目

我们已经可以看到一些有趣的统计数据，如错误率、总成本、运行次数等。现在让我们从 AskMamma 项目概述中获取更多详细信息：

图 6.10：LangSmith 的项目概述

在这里，您可以查看三个主要的信息来源：

运行：运行是与代理的单次交互。例如，如果用户输入“Hi”，那就是一个运行。

在每个运行下，我们可以探索关于代理活动的许多细节来回答问题。例如，在我们询问“你有哪些食品证书？”的运行中，代理执行了几个步骤，我们可以在 LangSmith 中查看所有这些步骤：

图 6.11：LangSmith 的运行概述

我们还可以检查那些失败的运行：

图 6.12：LangSmith 运行步骤概述

在这种情况下，原因是，在调用 add_to_cart 工具时，由于数据库离线，代理无法进一步执行。

线程：线程可以定义为会话。线程由唯一的标识符标记，您可以将其初始化为名称。例如，在我们的场景中，我们初始化了一个名为 <foo> 的线程：

实际上，您可以在 LangSmith 中看到这个线程的记录：

图 6.13：LangSmith 的线程概述

线程可以帮助您组织运行，并从更高层次查看您的代理背后的情况：

图 6.14：LangSmith 线程跟踪概述

监控：在这里，你可以看到一些有用的图表，以获得对代理的 360 度视图，包括跟踪计数、LLM 调用计数、成功率等：

图 6.15：LangSmith 的监控仪表板

当涉及到评估时，AI 代理和更广泛的 LLM 驱动的应用不能依赖于传统的机器学习评估器，如准确率、假阳性率、ROC 曲线等。事实上，AI 输出是设计为对话式的，这意味着我们需要新的工具和技术来评估我们 AI 驱动的解决方案的性能。

通常，为了评估 LLM 或代理管道的质量，你有三个主要组件需要处理：

数据集：这是测试用例的集合——包括输入和可选的预期输出，你的模型或代理将在这个集合上被评估。将其视为你的基准或参考集。
目标函数：这是你想要测试的实际事物——在我们的案例中，是 AI 代理的输出。当你运行一个评估时，LangSmith 将把每个数据集输入传递给这个目标函数并捕获输出——就像自动测试执行一样。然后，输出将与预期输出进行比较或根据你选择的评估器独立评估。
评估器：评估器用于判断目标函数输出的质量。它们可以是基于 LLM 的评估器，字符串指标如 BLEU 或 ROUGE，或传统的指标如准确率（如果我们使用 LLM 进行分类或预测等任务）。

定义

BLEU（或双语评估助手）和ROUGE（面向召回的摘要评估助手）是自然语言处理（NLP）中最广泛使用的自动评估指标之一，特别是在文本生成、翻译和摘要等任务中。

BLEU 是一个基于精确率的指标，通过测量生成的文本与一个或多个参考文本之间的 n-gram 重叠来评估文本质量——常用于机器翻译。

ROUGE 是一个基于召回率的指标，通过比较参考文本内容在输出中出现的多少来评估文本生成，常用于摘要任务。

让我们用一个AskMamma代理的例子来看看。在这个场景中，我们将利用 LangSmith SDK；然而，你也可以从 UI 游乐场运行样本评估：

初始化数据集：在这里，我们将使用一些输入-输出对初始化一个 LangSmith 测试数据集。请注意，在这里，我们将考虑不需要调用工具的一般答案——我们首先想测试我们的代理的一般回答能力。

from langsmith import Client
client = Client(
    api_key=os.getenv("LANGSMITH_API_KEY"),  # This can be retrieved from a secrets manager
    api_url=os.getenv("LANGSMITH_ENDPOINT"),  # Update appropriately for self-hosted installations or the EU region
)
dataset = client.create_dataset(
    dataset_name="QA Askmamma", 
    description="A sample dataset in LangSmith."
)
# Create examples
examples = [
    {
        "inputs": {"question": "What is Piadina?"},
        "outputs": {"answer": "A traditional Italian flatbread, 
            typically made with wheat flour, water, and salt."},
    },
    {
        "inputs": {"question": "What is the tradition of Piadina?"},
        "outputs": {"answer": "Piadina is a traditional Italian flatbread that originated in the Romagna region. It is typically filled with various ingredients and served warm."},
    },
]
# Add examples to the dataset
client.create_examples(dataset_id=dataset.id, examples=examples)

你将能够在 LangSmith 控制面板下的数据集与实验部分可视化你的数据集：

图 6.16：LangSmith 的数据集和实验

定义评估器：评估器将比较预期输出与实际输出，并根据特定指标对其进行评估。在我们的情况下，我们将利用 AI 驱动的评估。

注意

通过 AI 驱动的评估，我们指向具有非常特定提示的 LLM，使其成为其他 LLM 输出的“裁判”。

让我们初始化我们的 LLM 作为裁判。在这种情况下，我们将使用一个正确性指标来评估预期输出与实际输出之间的匹配：

from openai import AzureOpenAI
aoai_client = AzureOpenAI(
    azure_endpoint = os.getenv("AZURE_OPENAI_ENDPOINT"),
    api_key = os.getenv("AZURE_OPENAI_API_KEY"),
    api_version = os.getenv("AZURE_OPENAI_API_VERSION")
    )
from langsmith import wrappers
eval_instructions = "You are an expert professor specialized in grading students' answers to questions."
def correctness(
    inputs: dict, outputs: dict, reference_outputs: dict
) -> bool:
    user_content = f"""You are grading the following question:
{inputs['question']}
Here is the real answer:
{reference_outputs['answer']}
You are grading the following predicted answer:
{outputs['response']}
Respond with a score of 1-5, where 1 is the worst and 5 is the best. Your answer ONLY contains the score.
"""
    response = openai_client.chat.completions.create(
        model="gpt-4o",
        temperature=0,
        messages=[
            {"role": "system", "content": eval_instructions},
            {"role": "user", "content": user_content},
        ],
    ).choices[0].message.content
    return response.strip()

注意

如果你想利用预构建的评估器，可以选择 OpenEvals，这是一个开源的评估框架，它提供了一种标准化的方式来构建和注册评估函数——例如准确性检查、有用性评分或基于 LLM 的评论——并将它们一致地应用于数据集和模型。

初始化目标函数：最后一个成分是评估的逻辑——我们希望将我们的智能体输出结构与定义的评估器相匹配。

def target(inputs: dict) -> dict:
    response = agent_with_chat_history.invoke(
        {"input": inputs['question']},
        # This is needed because in most real world scenarios, a session id is needed
        # It isn't really used here because we are using a simple in memory ChatMessageHistory
        config={"configurable": {"session_id": "<foo>"}, 
            "callbacks": [tracer]},
    )
    return { "response": response['output'] }

就这样！现在让我们运行我们的评估器：

experiment_results = client.evaluate(
    target,
    data="QA Askmamma",
    evaluators=[
        correctness,
        # can add multiple evaluators here
    ],
    experiment_prefix="first-eval-in-langsmith",
    max_concurrency=2,
)

您现在可以检查 UI 的结果：

图 6.17：LangSmith 的评估结果

如您所见，我们的实际输出都返回了 5 的正确性分数。对于每个示例，您可以检查相关的指标，如实际输出、延迟、令牌等。

此外，在 AI 智能体的背景下，我们还需要考虑工具管理：

工具调用是否正常工作？
智能体能否调用多个工具来完成复杂的问题？
智能体是否足够智能，在不必要的情况下不会调用工具？

换句话说，你需要评估你的智能体的轨迹。让我们看看如何进行评估的例子（注意：以下代码是从官方 LangSmith 文档中改编的，您可以在以下链接找到：docs.smith.langchain.com/evaluation/how_to_guides）。

初始化新的数据集：在这种情况下，我们需要添加以下预期的中间步骤：

import uuid
questions = [
    (
        "Do you have ricotta cheese in stock",
        {
            "reference": "Yes we do have ricotta cheese in stock.",
            "expected_steps": ["sql_db_list_tables", 
                "sql_db_schema", "sql_db_query_checker", 
                "sql_db_query"],
        },
    ),
    (
        "hi",
        {
            "reference": "Hello, how can I assist you?",
            "expected_steps": [],  # Expect a direct response
        },
    ),
    (
        "Can you add ricotta cheese to the cart with price 5.50?",
        {
            "reference": "The item 'ricotta cheese' has been added to the cart.",
            "expected_steps": ["add_to_cart"],
        },
    ),
    (
        "Do you have food safety certificate?",
        {
            "reference": "Yes, we have a food safety certificate.",
            "expected_steps": ["document_search"],
        },
    ),
]
uid = uuid.uuid4()
dataset_name = f"Agent Tool Eval Example {uid}"
ds = client.create_dataset(
    dataset_name=dataset_name,
    description="An example agent evals dataset using search and calendar checks.",
)
client.create_examples(
    inputs=[{"input": q[0]} for q in questions],
    outputs=[q[1] for q in questions],
    dataset_id=ds.id,
)

初始化我们的评估器：在这里，我们将评估中间步骤的正确性，确保调用正确的工具：

from typing import Optional
from langsmith.schemas import Example, Run
def intermediate_step_correctness(
    run: Run, example: Optional[Example] = None
) -> dict:
    if run.outputs is None:
        raise ValueError("Run outputs cannot be None")
    intermediate_steps = run.outputs.get("intermediate_steps") or []
    trajectory = [action.tool for action, _ in intermediate_steps]
    # This is what we uploaded to the dataset
    expected_trajectory = example.outputs["expected_steps"]
    score = int(trajectory == expected_trajectory)
    return {"key": "Intermediate steps correctness", "score": score}

注意

为了获取访问我们智能体中间步骤的权限，我们需要确保return_intermediate_steps参数设置为True。

agent_executor = AgentExecutor(agent=agent, tools=toolkit, 
    verbose=True, return_intermediate_steps=True)

我们还需要确保用适当的模式初始化我们的评估器，以便它能够解析测试数据集中我们拥有的多个输出。

def prepare_data(run: Run, example: Example) -> dict:
    return {
        "input": example.inputs["input"],
        "prediction": run.outputs["output"],
        "reference": example.outputs["reference"],
    }
# Measures whether a QA response is "Correct", based on a reference answer
qa_evaluator = LangChainStringEvaluator(
    "qa", prepare_data=prepare_data, config={"llm": model}
)

定义目标函数：在这里，我们只是创建一个将使用适当的配置参数调用我们的智能体的函数。

def agent(inputs: dict):
    return agent_with_chat_history.invoke(
        inputs, config={"configurable": {"session_id": "<foo>"}}
    )

现在我们已经拥有了运行评估的所有成分：

chain_results = evaluate(
    agent,
    data=dataset_name,
    evaluators=[intermediate_step_correctness, qa_evaluator],
    experiment_prefix="Agent Eval Example",
    max_concurrency=1,
)

让我们检查 LangSmith UI 的结果：

图 6.18：评估结果仪表板

太好了！正如你所看到的，我们的代理表现相当不错，但我们可以看到其中一个中间步骤被评估为不正确。让我们了解原因：

图 6.19：代理步骤评估结果

看起来代理没有运行 sql_db_query_checker。尽管如此，最终结果还是正确的。这是一个重要的见解，因为我们可能希望要么在不必要时删除该工具，要么在系统消息级别对代理使用该工具提出更具体的建议。

评估代理不仅是为了判断其最终响应的质量，而且是为了分析导致这些结果的全过程推理和工具使用。通过评估代理所说的内容以及它是如何一步步得出结论的，我们可以更深入地了解其可靠性、透明度和与预期行为的对齐。这种全面的评估在复杂的工作流程中尤为重要，因为信任、可追溯性和正确性至关重要。

在移动应用中嵌入 AI 代理

AI 代理可以通过多种方式使用：作为一个具有交互式用户界面的独立应用程序，由业务流程触发，或者嵌入到现有应用程序中。在我们的场景中，我们将探索最后一种选项。

假设我们有一个餐厅的移动应用程序，我们希望将其与由我们的 askmamma AI 代理驱动的会话式用户界面相结合。新界面的外观和感觉如下：

图 6.20：我们 Piadineria 移动应用的界面

为了开发用户界面，我们将利用 Streamlit，这是一个开源的 Python 库，它使得构建和共享交互式网络应用变得容易，特别是对于数据科学和机器学习工作流程。你不必花费时间在前端开发上，你可以专注于 Python 代码，Streamlit 会自动处理用户界面。

在其功能中，Streamlit 有社区支持的组件和模板，可以轻松集成到 LangChain 管道中（例如，创建聊天界面或文本生成演示）。这种协同作用让你能够快速启动 LLM 应用程序的验证版本，利用 Streamlit 的交互性和用户友好的界面以及 LangChain 强大的语言处理能力。

在我们的场景中，我们将利用这种集成在 UI 层面上处理代理组件。让我们看看在重新利用代理到 Streamlit 时需要考虑的一些主要代码块（你可以在 GitHub 仓库中找到完整的代码）：

内存管理：我们首先初始化一个与 Streamlit 兼容的消息历史记录对象，作为我们应用中发生的对话的后端内存存储。在这种情况下，我们将利用内置的 LangChain 内存类 ConversationBufferMemory，它将所有消息保存在缓冲区（即运行列表）中。

from langchain_community.chat_message_histories import (
    ChatMessageHistory
)
from langchain_core.runnables.history import (
    RunnableWithMessageHistory
)
from langchain_community.chat_message_histories import (
    StreamlitChatMessageHistory)
msgs = StreamlitChatMessageHistory()
memory = ConversationBufferMemory(
    chat_memory=msgs, return_messages=True,
    memory_key="chat_history", output_key="output"
)

使用这种方法，我们将向 agent_executor 传递一个与 Streamlit 兼容的内存对象。

agent_executor = AgentExecutor(
        agent=agent, tools=toolkit, memory=memory,
        return_intermediate_steps=True,
        handle_parsing_errors=True, verbose=True
)

初始化 Streamlit 会话状态：在 Streamlit 中，状态指的是在用户交互之间保留变量的能力——例如，即使在重新运行后也能记住输入或点击的内容。
```
if 'chat_history' not in st.session_state:
    st.session_state['chat_history'] = []
if "messages" not in st.session_state:
    st.session_state.messages = [] 
```

之前的代码确保当用户打开您的应用时，内存中有一个位置来存储对话历史（chat_history）和屏幕上显示的消息（messages）。这就像设置两个笔记本——一个用于跟踪幕后所说的话，另一个用于显示给用户的内容。如果没有这一步，应用将不知道在哪里保存或检索过去的消息。

渲染基于持久内存的消息：在这个块中，我们希望显示用户和 AI 之间的完整聊天历史，从内存中拉取，以便显示之前发生的一切。

avatars = {"human": "user", "ai": "assistant"}
for idx, msg in enumerate(msgs.messages):
    with st.chat_message(avatars[msg.type]):
        # Render intermediate steps if any were saved
        for step in st.session_state.steps.get(str(idx), []):
            if step[0].tool == "_Exception":
                continue
            with st.status(
                f"**{step[0].tool}**: {step[0].tool_input}", 
                state="complete"
            ):
                st.write(step[0].log)
                st.write(step[1])
        st.write(msg.content)

渲染当前状态消息：这显示仅存储在当前会话状态中的消息——通常是当前运行中的消息。

for message in st.session_state.messages:
    with st.chat_message(message["role"]):
        st.markdown(message["content"])

渲染 AI 代理的聊天界面：此代码在 Streamlit 应用的底部设置聊天输入，邀请用户提问——例如 “想知道菜单里有什么吗？”。当用户发送消息时，它立即在聊天中以用户气泡的形式显示。然后，AI (agent_executor) 接管：它处理提示，可能沿途使用工具，并在助手气泡中回复答案。

prompt = st.chat_input("Want to know what's in the menu?")
if prompt:
    st.chat_message("user").write(prompt)
    with st.chat_message("assistant"):
        st_cb = StreamlitCallbackHandler(st.container(), 
            expand_new_thoughts=False)
        response = agent_executor.invoke({"input": prompt}, 
            {"callbacks": [st_cb]})
        st.write(response["output"])
        st.session_state.steps[str(len(msgs.messages) - 1)] = \
            response["intermediate_steps"]

这里很棒的是，AI 的推理步骤——例如它背后使用的工具——被 StreamlitCallbackHandler 捕获并存储在 st.session_state.steps 中。这使得您可以稍后详细可视化这些步骤，使用户能够窥视 AI 如何得出其答案。

一旦您的代码准备就绪并保存在 app.py 文件中，您可以通过 streamlit run app.py 运行它，在本地主机上查看结果。最终结果将如下所示：

图 6.21：AskMamma 代理的对话界面 UI

如您所见，我们能够与 AskMamma 互动，并代表我们执行一些操作，例如向购物车添加一项商品。

摘要

在本章中，我们探讨了创建一个功能性的 AI 代理所必需的基本概念和实践步骤。从理解 LangChain 的基础知识到实现高级功能，你已经在 AI 开发领域获得了宝贵的见解。

通过利用 LangChain 的强大工具和框架，您可以创建能够执行复杂任务并做出明智决策的智能代理。在本章中获得的知识和技能将为 AI 领域的进一步探索和创新奠定坚实的基础。

在下一章中，我们将开始看到多个代理在更复杂的场景中协同工作，进入多代理应用领域。

参考文献

语义内核插件：learn.microsoft.com/en-us/semantic-kernel/concepts/plugins/?pivots=programming-language-csharp
LangChain 工具：python.langchain.com/docs/how_to/tool_calling/
LangChain 生态系统：www.langchain.com/
LangSmith：docs.smith.langchain.com/
LangSmith 中间步骤评估：docs.smith.langchain.com/evaluation/how_to_guides
LangChain 食谱：github.com/langchain-ai/langsmith-cookbook/blob/main/testing-examples/agent_steps/evaluating_agents.ipynb 在 main · langchain-ai/langsmith-cookbook

订阅免费电子书

新框架、演进的架构、研究发布、生产分析——AI_Distilled 将噪音过滤成每周简报，供工程师和研究人员参考，他们正在亲手操作 LLMs 和 GenAI 系统。现在订阅，即可获得免费电子书，以及每周的洞察力，帮助您保持专注并获取信息。

在packt.link/TRO5B订阅或扫描下面的二维码。

第七章：多智能体应用

到目前为止，我们探讨了如何构建强大的单个智能体系统——利用工具、知识、记忆和编排层来解决复杂任务的智能实体。当正确配置时，这些智能体可以非常强大，利用广泛的知识和集成独立行动。然而，当我们将目光从单个智能体转向更广阔的领域时，智能体系统的真正潜力才开始显现。

正如人类依赖具有不同角色和专长的团队一样，AI 系统可以从多个智能体协同工作中受益匪浅，每个智能体都有自己的专业化、视角或功能。

本章探讨了智能体如何通信、协调和合作以完成单个智能体单独处理困难甚至不可能完成的任务。在本章中，我们将涵盖以下主题：

多智能体系统简介
理解和设计您多智能体系统的不同工作流程
多智能体编排器概述
使用 LangGraph 构建您的第一个多智能体应用

到本章结束时，您将清楚地了解构建和启动多智能体 AI 应用以应对您独特用例所需的所有要素。

技术要求

本章所需的所有代码和依赖项均列在本书官方 GitHub 仓库的requirements.txt文件中，该仓库地址为github.com/PacktPublishing/AI-Agents-in-Practice。

要设置您的环境，只需克隆仓库并运行以下命令来安装依赖项：

pip install -r requirements.txt

这将确保您拥有所有必要的库和工具，以便跟随实际操作示例。

多智能体系统简介

正如我们在前面的章节中看到的，一个单个 AI 智能体通常会提供诸如 Web API、数据库、Web 服务等工具。这些工具扩展了智能体的功能，使其不仅限于文本生成，还能与世界互动并执行目标驱动型任务。例如，在前一章中，我们探讨了如何将意大利餐厅的 AI 智能体与包含库存产品的后端数据库集成，从向量数据库中检索相关洞察，甚至执行添加商品到用户购物车等操作。

但如果我们再进一步会怎样呢？

就像单个智能体可以调用工具一样，智能体也可以调用另一个智能体。实际上，从高级智能体的角度来看，另一个智能体就是一个工具，只要它提供了对其能力的自然语言描述。这导致了多智能体系统的出现，其中智能实体进行沟通和协作，每个实体都向更大的系统贡献了其专业化的能力。

例如，想象一个简单的 AI 系统，其中 Python 函数用于从 Google Calendar 等在线服务中获取用户的日历事件。此函数接受特定的参数——例如日期或事件 ID——并返回所请求的确切内容，不再多加。

现在，在一个多智能体系统中，同样的日历功能可以由一个专门的“日历智能体”来处理。这个智能体不仅限于基本的数据检索。它还可以执行以下操作：

理解模糊的查询，例如“我下一个空闲的下午是什么时候？”
检测并解决调度冲突（例如，两个会议重叠）
与其他智能体协商变更——例如，提出对所有人都有利的新的会议时间

这种从简单功能到智能智能体的转变说明了多智能体系统如何将更丰富的推理、灵活性和自主性带入原本基本的任务中。

我们为什么要这样做？难道我们不能依赖一个简单的工具来完成吗？简短的回答——考虑到简单的例子——可能是的，我们可以依赖单个工具。然而，可能存在一些场景，您可能希望有一个非常专业的智能体而不是工具，这样您就可以向它提供清晰的系统消息并扩展其功能。此外，这个日历智能体可能被用于不同的流程和应用中，使其成为您组织中的可重复组件。

让我们考虑另一个例子——这次稍微复杂一些。假设我们想要启用一个 AI 应用程序，帮助您在多个商店进行在线购物。这是一个您可能想要执行的典型查询：“从 XYW 购买 39 EU 码的新鞋子。”

图 7.1：分层多智能体系统的示例

快速提示：需要查看此图像的高分辨率版本？请使用下一代 Packt Reader 打开此书或在其 PDF/ePub 副本中查看。

下一代 Packt Reader随本书免费赠送。扫描二维码或访问 packtpub.com/unlock，然后使用搜索栏通过名称查找此书。请仔细检查显示的版本，以确保您获得正确的版本。

在单智能体设置中，该智能体会依次搜索鞋子，管理调度，填写地址详情，并处理支付。但在模块化、多智能体设计中，这项任务被分解为专门的组件：

计划智能体解释指令并协调以下执行。
网络智能体浏览电子商务平台，使用低级 Web 控制器智能体（例如，由 Selenium 驱动的机器人）与界面交互——点击、滚动和视觉搜索。
调度代理检查日历来确定配送可用性，调用日历代理获取或创建事件。
订单放置代理通过与以下内容协调来完成购买：
1. 支付代理，负责安全地处理交易
2. 地址代理，用于验证和格式化送货地址

每个代理独立运行，但为更大的使命做出贡献。规划代理充当指挥家，协调一支由智能表演者组成的团队：网络代理、调度代理、订单放置代理、网络控制器、日历代理、地址代理和支付代理。

这种方法与我们在前几章中讨论的两个关键概念——模块化和抽象——非常吻合，提供了几个优点：

可扩展性：多代理系统在设计上自然具有可扩展性。由于每个代理封装了特定的功能或责任，代理可以独立地部署在不同的服务器、容器或甚至地理区域。如果某个代理成为瓶颈（例如，在高峰流量期间的网页抓取代理），它可以水平扩展——复制并负载均衡——而不会影响系统的其余部分。这种分布式特性使得构建随着用户需求增长的人工智能应用变得更容易。
可维护性：模块化促进了可维护性。因为每个代理都是自包含的，并通过定义的协议或接口进行通信，所以它可以被更新、重构或替换，而无需重写整个系统。例如，用一个更先进的模型（甚至不同的模型提供者）替换摘要代理不会影响处理检索、过滤或用户交互的代理的逻辑。这种关注点的清晰分离使得长期演化和实验更容易且更安全。
专业化：每个代理都可以使用最适合其工作的最佳工具进行精细调整或构建。一些代理可能使用代码生成型 LLM（如 GPT-4o），而其他代理可能基于检索增强架构或基于规则的逻辑。同样，只要它们遵守共享协议，代理可以用不同的语言（Python、JavaScript 等）或框架开发。这种灵活性允许团队优化性能和成本，为系统的每个组件选择正确的方案。

最后，为了构建和理解多代理系统，我们还必须从两个主要角度转向微服务领域：一个是基础设计，另一个是基础设施模式，它使多代理智能能够真正发挥作用。

定义

微服务是一种软件架构模式，其中应用程序被分解为小型、独立的微服务，每个微服务负责单一功能，并通过轻量级协议（如 HTTP 或消息队列）进行通信。这种模块化方法实现了可伸缩性、灵活性和易于维护，为现代分布式系统以及日益增长的多代理人工智能系统奠定了基础。

从设计角度来看，微服务基于模块化的原则——将大型应用程序分解为独立、专业的服务，每个服务都擅长一项任务。这正是代理系统应该设计的方式：

每个代理只有一个职责：浏览、调度、订购、验证或支付
每个代理就像微服务封装其 API 和数据库访问一样，封装其逻辑和工具
代理通过结构化协议（消息、事件和 API）进行通信，允许异步、灵活的协调

您可以替换一个智能代理，或者重新部署一个失败的代理，而不会影响系统的其余部分。

换句话说，多代理设计是将微服务设计应用于人工智能。它强调解耦、专业化和可组合性——现代软件工程的核心原则。

从基础设施的角度来看，微服务为在现实世界中部署和管理基于代理的系统提供了骨干。

每个代理可以是以下之一：

容器化（例如，使用 Docker）并作为独立应用程序部署，可以暴露为 API
在云原生环境中托管（例如，Kubernetes），独立扩展
通过服务网格或消息代理连接，实现安全高效的通信
在多语言环境中开发（例如，一个代理可以在 Python 上运行，另一个在 JavaScript 上运行—— whatever suits the task best）

图 7.2：多代理系统的微服务后端

让我们回顾一下图 7.1中的示例。规划代理将任务（“购买 39 EU 码的鞋子”）分解为子任务，由模块化代理处理——Web 代理、调度代理、订单放置代理——每个代理都有自己的下游助手（例如，支付代理和地址代理）。

这些代理可以运行如下：

独立的微服务，每个部署在 Kubernetes 集群中
隔离的无服务器函数，仅在需要时启动
具有持久内存和状态的背景服务，通过事件驱动的架构进行编排

没有微服务基础设施，构建、部署和管理这样的分布式代理系统将是脆弱且低效的。正是模块化设计和可扩展托管相结合，使得现实世界的多代理人工智能系统成为可能。

同时，我们还需要定义这些代理之间想要通信的方式，这引出了多代理设计工作流程的主题。

理解和设计您多代理系统的不同工作流程

当我们从单代理系统过渡到多代理架构时，代理之间的交互方式变得至关重要。不同的工作流程（或者说，换句话说，通信模式）塑造了代理如何协作、共享信息和做出决策。选择正确的工作流程取决于任务的性质、每个代理的角色以及期望的结果。

让我们探索五个核心多代理工作流程（见图7.3）：

图 7.3：不同类型的代理工作流程

下面是五个核心多代理工作流程的详细说明：

网络：所有代理在一个完全连接的图中都是对等节点，每个代理可以直接与其他任何代理通信。这允许高度互动、动态的协作。

让我们考虑以下示例。在一个快速发展的初创公司中，一组 AI 代理协作构思、验证和计划一个新移动应用的发布。每个代理都有一个明确的领域，但它们以动态、迭代的模式一起工作，就像一个真正的产品团队：

代理 A—市场研究代理：此代理持续监控消费者趋势、应用商店数据和竞争对手活动。它发现对 AI 驱动健康应用的兴趣日益增长，并分享一份突出未满足用户需求的报告。
代理 B—产品设计代理：此代理利用市场研究代理的见解来绘制健康应用的初始概念，包括用户流程和功能原型。它咨询 UX 风格指南并适应以前成功的模式。然后与团队分享这些内容以获取反馈。
代理 C—合规性代理：一旦提出新的功能想法，此代理就会审查它们，以确定潜在的法律或隐私问题——例如健康数据的处理——并提出修改建议，以使应用符合 GDPR 和 HIPAA。
代理 D—项目经理代理：此代理跟踪任务之间的进度和依赖关系。它提出时间表并标记风险，例如可能需要额外合规性批准的设计功能。它还在决策悬而未决或任务阻碍他人时推动团队。

图 7.4：网络工作流程

如图 7.4所示，此设置模仿了跨职能敏捷团队，它们依靠持续的协调和快速反馈而蓬勃发展。

反思：一个自我评估的循环，其中代理对其自己的输出进行反思或批评（或者由另一个代理这样做），通过反馈实现迭代改进。例如，考虑一个希望使用写作助手生成科学论文草稿的大学研究小组。主要代理产生内容，而“审稿人”代理评估清晰度、逻辑和引用准确性。它标记薄弱的论点或缺失的参考文献。

第一个代理随后相应地修改文本，并重新提交以供审查。这个过程会重复进行，直到输出达到出版质量。

图 7.5：反思工作流程

反思工作流程对于质量控制以及 refinement 与生成同样重要的任务非常有效。

顺序型：代理以线性管道的形式组织。每个代理执行特定任务，并将输出传递给链中的下一个代理。例如，考虑一个媒体机构使用一系列专业代理自动创建和发布突发新闻文章的过程：
- 代理 A—新闻聚合代理：监控新闻专线、社交媒体和新闻稿的实时流，以识别新兴故事。它选择一个突发新闻事件并提取相关事实。
- 代理 B—事实核查代理：将收集到的信息与政府数据库、先前新闻报道和知识图谱等可信来源进行验证。它标记任何差异，并在故事进展之前确保准确性。
- 代理 C—作家代理：使用经过验证的数据撰写引人入胜的新闻文章，遵循新闻风格和出版标准。
- 代理 D—SEO 和社交优化代理：优化文章标题，添加元描述、标签，并调整格式以在搜索引擎和社交平台上实现最大覆盖范围。
- 代理 E—发布代理：在网页、移动和新闻通讯平台上安排和发布文章。

图 7.6：顺序型工作流程

使用这种工作流程，你将绝对对你的代理有更多的控制，因为你正在给他们一个明确的执行顺序。

分层型：管理代理监督并委派任务给下属代理，并汇总他们的输出。沟通通常自上而下和自下而上进行。例如，考虑一家 SaaS 公司部署分层 AI 系统用于客户服务。当客户提交查询，例如“为什么这个月我被收费两次？”时，管理代理解析请求并委派子任务：
- 计费代理检查交易历史。
- 技术代理检查系统日志中的重复收费。
- FAQ 代理检查是否为已知问题。一旦每个下属做出回应，经理就会汇编并交付一个连贯、统一的答案。这种设置反映了现实世界中的管理，促进了模块化和专业处理。

图 7.7：分层工作流程

如果执行顺序事先不清楚（与顺序模式不同），但仍然希望在上层保持一定程度的监控（与网络模式不同），则此模式特别适用。

混合模式：结合多个模式（例如，具有反射回路的分层骨干或嵌入网络的顺序步骤），允许灵活、分层的协作。让我们回顾一下在顺序架构中讨论的媒体发布流程，并在其中一步添加一个分层转折：
- 代理 A—新闻聚合器：监控新闻社、社交媒体和新闻稿的实时流，以识别新兴故事。它选择一个突发新闻事件并提取相关事实。
- 代理 B—编辑经理：负责处理已识别的故事，并担任副主编。它不是直接撰写文章，而是管理一组代理：
  - 作家代理：根据可用事实生成初稿
  - 风格代理：确保语气、语法和格式符合出版物的编辑指南
  - 事实核查代理：使用可靠的数据库交叉验证声明，并报告结果
编辑经理代理监督这些代理，审查他们的工作，并在将其传递之前编译文章的最终版本。
- 代理 C—发布代理：准备最终文章以供在线分发，添加标签和 SEO 元数据，并将其发布到新闻网站和社交媒体平台。

图 7.8：混合模式

这种混合结构为原本线性的流程增加了灵活性和质量控制。由编辑经理管理的分层子结构允许专业化并保持稳健，同时不会打断整体的任务流程。

在前面的章节中，我们探讨了在处理单个 AI 代理时拥有 AI 排程器的重要性，以便我们能够正确设计它们与工具交互的方式。当涉及到多代理系统时，AI 排程器变得更加重要，因为它们不仅需要管理单个代理与工具的交互，还需要管理多个代理之间的交互。

在下一节中，我们将探讨一些最受欢迎的多代理编排器。

多代理编排器概述

随着我们探讨了从单代理系统到协作多代理架构的演变，很明显，协调多个智能代理需要强大的编排。因此，对 AI 排程器的需求比以往任何时候都更加迫切。

当涉及到多代理应用时，还有一些额外的编排器值得探索，以适应您的场景。

AutoGen

AutoGen，由微软开发，是一个开源框架，通过对话交互促进多代理系统的创建。它强调设计能够通信、协作和适应以完成复杂任务的代理。

该框架采用分层、模块化架构，其中每一层都有明确的职责，并建立在底层层的功能之上。这种结构允许开发者以不同复杂度级别与系统交互，从适合快速开发的高级抽象到提供精细控制的底层组件。

核心 API：在基础层面，核心 API 管理代理之间的消息传递、事件驱动行为，并为本地和分布式部署提供运行时支持。它旨在提供最大灵活性，甚至支持 Python 和.NET 环境之间的跨语言互操作性。
AgentChat API：位于核心层之上，AgentChat API 提供了一个更高层次、具有明确观点的接口，专注于易用性和快速原型设计。它简化了常见的模式，如双代理对话和群体交互，使得从框架早期版本过渡的用户感到熟悉。
扩展 API：最顶层允许通过官方和第三方扩展不断增强框架。这包括与流行的 LLM 提供商（如 OpenAI 和 Azure OpenAI）的集成，以及外部代码执行和工具使用等高级功能。

除了框架本身，AutoGen 还提供开发工具，包括一个无需代码的 GUI 工具 AutoGen Studio 和一个基准测试套件 AutoGen Bench。

AutoGen 非常适合自动化客户支持、协作内容创作和需要代理共同协商、规划和执行任务的复杂问题解决场景。

TaskWeaver

TaskWeaver 是由微软开发的以代码优先的代理框架，旨在规划和执行复杂的数据分析工作流程。该框架的主要区别在于其代码驱动的执行：TaskWeaver 将用户请求解释为可执行的代码片段并执行它们，无缝协调多个功能或插件。此外，与主要关注基于文本的对话历史的传统代理系统不同，TaskWeaver 将聊天历史与代码执行历史和内存中的数据状态相结合，使其非常适合处理结构化、高维数据，如表格和数据库。

TaskWeaver 的关键特性包括以下内容：

复杂任务规划和反思执行：TaskWeaver 使智能任务分解、进度跟踪和反思执行成为可能，允许代理根据执行反馈动态调整其策略。
丰富的数据处理和有状态执行：该框架支持使用丰富的 Python 数据结构，如 DataFrames，在任务之间维护计算状态，并通过在执行前验证生成的代码来确保一致的用户体验。
可定制、可扩展和安全的：开发者可以轻松使用特定领域的插件扩展 TaskWeaver，封装自定义算法，并通过会话隔离和安全的代码执行安全地管理多代理工作流程。
开发者友好且透明：TaskWeaver 提供了一个简单的设置体验，包括现成的插件、详细的日志记录以方便调试，以及开放透明的架构，有助于用户理解和控制整个执行过程。

由于其代码驱动的方法和对结构化数据的强大支持，TaskWeaver 特别适合数据密集型应用、分析工作流程、科学研究、金融建模以及任何需要精确性、可重复性和执行透明度的环境。

OpenAI 代理 SDK

OpenAI 代理 SDK 是一个轻量但强大的框架，旨在简化构建和编排多代理工作流程。由 OpenAI 开发，它提供了一种模块化的方法来连接代理，分配工具，应用安全措施，并在它们之间无缝转移控制。

它是提供商无关的，这意味着它可以与 OpenAI 的 API 一起工作，但也可以与 100 多种不同的 LLM 兼容，使其对不同 AI 后端具有极高的灵活性。

代理 SDK 的关键特性包括以下内容：

代理协作的移交：OpenAI 代理引入了移交——一种基于任务上下文的清晰、一等机制，用于在代理之间传递控制，使多代理协作直观且自然。
内置安全措施：安全性是一个核心关注点；您可以定义输入验证、输出检查和自定义约束的安全措施，提高工作流程的可靠性和道德行为。
原生跟踪和调试工具：SDK 包含内置的跟踪支持，允许您可视化代理交互，监控执行路径，并轻松调试多代理工作流程，这对于透明度和优化至关重要。
简单、快速 API：代理易于定义（名称、指令和工具），并且可以通过最小化样板代码组合成复杂的工作流程。它旨在快速原型设计，同时不牺牲深度。
多提供商支持：虽然它与 OpenAI 的模型紧密集成，但并非锁定——您可以轻松连接到其他模型提供商，满足多样化的部署需求。

总体而言，OpenAI 代理 SDK 使开发者能够构建智能的多代理系统，这些系统能够推理、委派任务，并自主地与工具交互。

LangGraph

LangGraph 是 LangChain 生态系统的扩展，旨在通过基于图的架构编排多代理系统。

定义

在数学中，图是由节点（也称为顶点）通过边连接的结构，用于模拟对象对之间的关系或连接。图在网络理论、计算机科学和组合数学等领域的应用是基础性的。

在 LangGraph 的上下文中，通过以下元素使用图来建模 AI 工作流程：

节点：在 LangGraph 中，每个节点代表工作流程中的特定任务或操作。节点可以是 LLM 代理、工具或自定义函数，执行诸如文档检索、数据处理、文本生成或基于输入的决策等动作。
边：边定义了控制数据和节点之间的移动方式，决定了执行顺序。它们还可以包含条件逻辑，允许工作流程根据状态或先前节点的输出动态路由。
状态：状态是一个在执行过程中跨越节点共享的数据结构。它携带必要的上下文信息，例如消息、中间结果或相关的元数据，节点使用这些信息来执行其任务并协调动作。
条件逻辑：LangGraph 通过条件边实现动态决策。这些边评估当前状态以确定下一步，支持工作流程中的分支、循环和实时调整。
工作流程编译：一旦定义，LangGraph 将节点、边和条件逻辑编译成一个可执行的图。这个编译后的工作流程管理执行顺序、状态转换和节点间的协调，确保任务高效且可靠地执行。

例如，在图 7.9中，你可以看到一个 LangGraph 工作流程，其中我们有一个决定是否需要网络代理的第一个条件边；然后，根据输出，它决定查询是否需要重写，或者可以直接显示给最终用户作为最终结果。

图 7.9：LangGraph 工作流程示例

通过结合这些元素，LangGraph 允许开发者构建模块化、可重用和动态的工作流程，这些工作流程能够支持复杂的智能体交互和基于 LLM 和外部工具的复杂决策。

在 AutoGen、TaskWeaver、智能体 SDK 或 LangGraph 之间没有绝对的“最佳”编排器。每个都设计有不同的哲学和优势，正确的选择在很大程度上取决于你的具体用例、你的技术偏好以及你打算构建的工作流程的复杂性。有些人偏好轻量级、快速原型设计；而其他人则在编排多个智能体之间的复杂、有状态交互方面表现出色。

在下一节中，我们将利用 LangGraph 进行我们的动手实践案例，探索如何通过基于图的编排逐步构建多智能体系统。

使用 LangGraph 构建您的第一个多智能体应用程序

是时候动手实践了！在本节中，我们将利用 LangGraph 构建一个多智能体应用程序。请注意，我不会在这里包含整个代码，而是只包含理解智能体构建块的相关部分。您可以在本书的 GitHub 仓库中找到完整的代码：github.com/PacktPublishing/AI-Agents-in-Practice。

让我们介绍我们希望通过我们的多智能体应用程序解决的问题。

管理投资组合是一项复杂的任务，需要持续关注市场趋势、资产表现和风险敞口。许多个人投资者和财务顾问都难以手动分析大量财务数据以做出明智的决定。该应用程序旨在通过使用一组智能代理来分析用户的投资组合、提取相关的市场洞察力并提供可操作的推荐来减轻这一挑战。

目标是提供一份全面的报告——自动生成——帮助用户优化投资以获得更好的回报或降低风险。为了演示目的，我们将假设投资组合以 JSON 文件的形式表示，结构如下：

[
    {
        "symbol": "AAPL",
        "sector": "Technology",
        "quantity": 13,
        "purchase_price": 1202.57,
        "total_invested": 15633.41,
        "purchase_date": "2022-03-12"
    },…
…]

快速提示：使用AI 代码解释器和快速复制功能增强您的编码体验。在下一代 Packt Reader 中打开此书。点击复制按钮

（1）快速将代码复制到您的编码环境，或点击解释按钮

（2）让 AI 助手为您解释一段代码。

下一代 Packt Reader随本书免费赠送。扫描二维码或访问 packtpub.com/unlock，然后使用搜索栏通过名称查找此书。请仔细核对显示的版本，以确保您获得正确的版本。

为了完成这个任务，我们开发了一个具有以下结构的多智能体应用程序：

图 7.10：分层多智能体投资组合分析器

让我们根据图 7.10所示逐一检查每个组件：

search_agent：专门用于检索相关网站以回答用户的问题，并提供了以下工具：
- tavily_tool：LangChain 中可用的预构建工具，专门设计用于从 Tavily API 检索搜索结果
  
  定义
  
  Tavily 是一个由人工智能驱动的搜索 API，旨在通过提供实时、高质量的网页搜索结果来增强检索增强生成（RAG）和基于代理的应用程序。它允许开发者通过简单、快速且成本效益高的 API 调用将外部知识集成到 LLM 工作流程中。Tavily 通常用于通过将它们基于最新的网络内容来提高 AI 生成响应的准确性和相关性。

让我们初始化这个代理，从工具的初始化开始：

# Load environment variables from .env file
load_dotenv()
# Initialize the Azure OpenAI model
llm = AzureChatOpenAI(
    openai_api_version=openai_api_version,
    azure_deployment=azure_chat_deployment,
)
tavily_tool = TavilySearchResults(max_results=5, 
    tavily_api_key=tavily_api_key)

现在，我们可以创建代理并将其初始化为 LangGraph 图中的节点：

search_agent = create_react_agent(llm, tools=[tavily_tool])
def search_node(state: State) -> Command[Literal["supervisor"]]:
    result = search_agent.invoke(state)
    return Command(
        update={
            "messages": [
                HumanMessage(
                    content=result["messages"][-1].content, 
                    name="search")
            ]
        },
# We want our workers to ALWAYS "report back" to the supervisor when done
        goto="supervisor",
    )

read_portfolio_agent：专门从提供的路径读取投资组合，并提供了以下工具：
- read_portfolio：读取保存为JSON文件的金融投资组合的硬编码函数

让我们初始化工具和代理：

@tool
def read_sample_portfolio(
    json_path: str = "sample_portfolio.json"
) -> str:
    """
    Reads the sample_portfolio.json file and returns its content as a string.
    Each entry includes the stock symbol, sector, quantity, purchase price, and purchase date.
    """
    if not os.path.exists(json_path):
        return f"File not found: {json_path}"
    with open(json_path, "r") as f:
        portfolio = json.load(f)
    if not isinstance(portfolio, list):
        return "Unexpected portfolio format."
    response = "Sample Portfolio:\n"
    for stock in portfolio:
        response += (
            f"- {stock['symbol']} ({stock['sector']}): "
            f"{stock['quantity']}shares @${stock['purchase_price']}"
            f"(Bought on {stock['purchase_date']})\n"
        )
    return response
read_portfolio_agent = create_react_agent(
    llm, tools=[read_sample_portfolio]
)
def read_portfolio_node(
    state: State
) -> Command[Literal["supervisor"]]:
    result = read_portfolio_agent.invoke(state)
    return Command(
        update={
            "messages": [
                HumanMessage(content=result["messages"][-1].content, 
                name="read_portfolio")
            ]
        },
        # We want our workers to ALWAYS "report back" to the supervisor when done
        goto="supervisor",
    )

doc_writer_agent：专门编写具有结构化大纲的详细报告，并提供了以下工具：
- write_document：将代理的结果写入预定义目录的硬编码函数

让我们初始化工具和代理：

from pathlib import Path
from tempfile import TemporaryDirectory
from typing import Dict, Optional
from typing_extensions import TypedDict
# Define a real directory path
REAL_DIRECTORY = Path(r"your_path")
#_TEMP_DIRECTORY = TemporaryDirectory()
WORKING_DIRECTORY = Path(REAL_DIRECTORY)
@tool
def write_document(
    content: Annotated[
        str, "Text content to be written into the document."],
    file_name: Annotated[str, "File path to save the document."],
) -> Annotated[str, "Path of the saved document file."]:
    """Create and save a text document."""
    with (WORKING_DIRECTORY / file_name).open("w") as file:
        file.write(content)
    return f"Document saved to {file_name}"
report_prompt = """
You are an expert report generator. Given the input from other agents, you generate a detailed report on how to optimize the provided portfolio.
The report will have the following outline:
-------------------------------
**Introduction on market landscape**
**Portfolio Overview**
**Investment Strategy**
**Performance Analysis**
**Recommendations**
**Conclusion**
**References**
--------------------------------
Once the report is generated, save it using your write_document tool.
"""
doc_writer_agent = create_react_agent(
    llm,
    tools=[write_document],
    prompt=report_prompt,
)
def doc_writing_node(state: State) -> Command[Literal["supervisor"]]:
    result = doc_writer_agent.invoke(state)
    return Command(
        update={
            "messages": [
                HumanMessage(content=result["messages"][-1].content, 
                    name="doc_writer")
            ]
        },
        # We want our workers to ALWAYS "report back" to the supervisor when done
        goto="supervisor",
    )

现在我们已经初始化了所有三个代理，是时候在更高层次上添加另一个抽象级别了。为此，我们将创建一个团队监督角色，该角色将根据用户的查询调用团队：

class State(MessagesState):
    next: str
def make_supervisor_node(llm: BaseChatModel, members: list[str]) -> str:
    options = ["FINISH"] + members
    system_prompt = (
        "You are a supervisor tasked with managing a conversation between the"
        f" following workers: {members}. Given the following user request,"
        " respond with the worker to act next. Each worker will perform a"
        " task and respond with their results and status. When finished,"
        " respond with FINISH."
    )
    class Router(TypedDict):
        """Worker to route to next. If no workers needed, route to FINISH."""
        next: Literal[*options]
    def supervisor_node(state: State) -> Command[
        Literal[*members, "__end__"]
    ]:
        """An LLM-based router."""
        messages = [
            {"role": "system", "content": system_prompt},
        ] + state["messages"]
        response = llm.with_structured_output(Router).invoke(messages)
        goto = response["next"]
        if goto == "FINISH":
            goto = END
        return Command(goto=goto, update={"next": goto})
    return supervisor_node
supervisor_node = make_supervisor_node(llm, 
    ["search","read_portfolio", "doc_writer"]
)

现在，我们可以编译图：

# Define the graph.
builder = StateGraph(State)
builder.add_node("supervisor", supervisor_node)
builder.add_node("read_portfolio", read_portfolio_node)
builder.add_node("search", search_node)
builder.add_node("doc_writer", doc_writing_node)
builder.add_edge(START, "supervisor")
super_graph = builder.compile()

让我们测试它：

for s in super_graph.stream(
    {
        "messages": [
            ("user", "Generate a well structured report on how to improve my portfolio given the market landscape in Q4 2025.")
        ],
    },
    {"recursion_limit": 150},
):
    print(s)
    print("---")

这里是截断的输出：

{'supervisor': {'next': 'search'}}
---
{'search': {'messages': [HumanMessage(content='**Portfolio Improvement Report Based on Market Landscape Q4 2025**\n\n---\n\n### 1\. **Market Landscape Highlights for Q4 2025:**\nThe market trends observed for Q4 2025 suggest:\n- **Elevated Interest Rates:** Policy rates in developed markets, particularly in the US, are expected to remain high. This "higher-for-longer" rate narrative creates opportunities for varied asset positioning.\n- **Equity Market Dispersion:[...]]}}
---
{'supervisor': {'next': 'read_portfolio'}}
---
{'read_portfolio': {'messages': [HumanMessage(content='### Portfolio Improvement Report: Alignment with Market Landscape Q4 2025  \n\n---\n\n#### Portfolio Overview\nYour existing portfolio demonstrates strong exposure to technology (AAPL, GOOGL, MSFT, NVDA), consumer discretionary (AMZN, TSLA, BABA), and financials (V, JPM). [...]]}}
---
{'supervisor': {'next': 'doc_writer'}}
---
{'doc_writer': {'messages': [HumanMessage(content='The report on optimizing your portfolio for Q4 2025 has been successfully generated and saved. You can find it in the file named **Portfolio_Optimization_Q4_2025.txt**. Let me know if you need further assistance or any modifications!', additional_kwargs={}, response_metadata={}, name='doc_writer', id='8fa9e6a9-fafc-466c-8bbc-19514654c3be')]}}
---
{'supervisor': {'next': '__end__'}}

您将在指定的文件夹下找到您的文件（在我的情况下，outputs）。

图 7.11：我在本地文件夹中创建的.txt 文件示例

这里是输出：

图 7.12：代理生成的最终报告示例

如您所见，输出遵循我们在报告生成代理中指定的系统消息大纲。

摘要

在本章中，我们超越了单个、工具增强代理的世界，探索了多代理系统的激动人心的领域。我们看到了代理如何像人类团队一样协作，每个代理都专注于自己的任务，但共同工作以解决单个代理单独难以解决的问题。

我们还确定，设计多代理系统既是架构挑战，也是人工智能挑战，需要仔细考虑模块化、通信、协调和可靠性。与微服务架构进行类比，我们认识到代理可以（并且应该）是模块化的、独立的，并且可以智能地编排以形成可扩展、健壮的系统。

我们介绍了多代理编排器，如 AutoGen、TaskWeaver 和 LangGraph，并使用后者进行了实际演示，构建了我们的第一个多代理应用程序。

本章还总结了本书的第二部分。在下一章中，我们将转换方向，探讨一个关键主题——构建负责任的 AI 系统。随着我们创建越来越自主的代理和多智能体生态系统，设计安全性、透明度、安全性和道德一致性变得至关重要。

参考文献

LangGraph: www.langchain.com/langgraph
基于 LangGraph 的多智能体系统: langchain-ai.github.io/langgraph/concepts/multi_agent/
LangGraph 代理概念: langchain-ai.github.io/langgraph/concepts/agentic_concepts/
OpenAI 代理 SDK: github.com/openai/openai-agents-python
AutoGen: github.com/microsoft/autogen
TaskWeaver: github.com/microsoft/TaskWeaver

现在解锁本书的独家优惠

扫描此二维码或访问 packtpub.com/unlock，然后通过书名搜索此书 | |

| 注意：在开始之前，请准备好您的购买发票。 |

| --- |

第三部分

开放、代理生态系统的道路

本部分介绍了企业级 AI 代理的兴起格局，特别关注使大规模代理部署成为可能的基础设施、协议和负责任的设计实践。

我们首先探索旨在标准化和扩展多代理协作的下一代开放协议，如 MCP、A2A 和 NLWeb，这些协议将在实现跨平台和跨代理互操作性方面发挥基础性作用。

我们将深入探讨企业在部署自主代理时如何确保负责任的 AI 实践。包括代理评估、安全过滤器、安全带以及在高风险场景中人类在回路系统的重要性。你还将学习优化成本并维持大规模性能的策略。

最后，本部分回顾了代理系统的更广泛演变——从原型到生产——并展望了该领域未来的发展方向以及未来几年智能软件的预期。

本部分包含以下章节：

第八章，编排智能：下一代代理协议蓝图
第九章，在现实世界 AI 中的伦理挑战导航

第八章：编排智能：下一代代理协议的蓝图

在人工智能（AI）发展的演变格局中，协议正迅速成为连接模型、工具和外部系统的连接组织。在最近几个月，我们看到了围绕旨在增强智能代理之间互操作性和协调的新协议的活动激增。其中最突出的是 Anthropic 的模型上下文协议（MCP）、Google 的代理到代理（A2A）和 Virtuals 的代理商业协议（ACP）。

初看之下，这些可能只是已经拥挤的人工智能生态系统中的又一波框架。毕竟，像 LangChain、Semantic Kernel 和 AutoGen 这样的框架长期以来都承诺提供可重用、模块化的 AI 组件，如插件、工具、提示和代理。但协议在抽象的不同层面上运作。虽然编排器帮助构建和控制智能工作流程，但协议定义了这些组件如何在系统之间进行通信，提供一致性、结构和治理。

在本章中，我们将彻底研究 MCP、A2A 和 ACP 协议，以及它们如何为一种新的消费方式铺平道路，不仅限于应用程序，还包括整个网络，引入了开创性的代理网络概念。

本章将涵盖以下关键主题：

什么是协议？
理解模型上下文协议
代理到代理
代理商业协议
向代理网络迈进

在深入研究这些主题之前，首先理解协议的基本概念是至关重要的。

技术要求

本章中所需的所有代码和必要的依赖项都列在本书官方 GitHub 仓库中的requirements.txt文件中，网址为github.com/PacktPublishing/AI-Agents-in-Practice。

要设置您的环境，只需克隆仓库并遵循 README 文件中的说明。

或者，您可以从零开始，并遵循官方 MCP Python SDK 仓库中的快速入门指南：github.com/modelcontextprotocol/python-sdk。

什么是协议？

协议简单地说是一套规则，定义了两个或多个系统如何通信。最熟悉的例子是 HTTP——您的浏览器用来与网站通信的协议。当您访问一个 URL 时，您的浏览器会发送一个结构化的 HTTP 请求，服务器会响应一个页面或数据。

假设您访问了乞力马扎罗山的维基百科页面。您的浏览器会发送以下内容：

GET /wiki/Mount_Kilimanjaro HTTP/1.1
Host: en.wikipedia.org
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/125.0.0.0 Safari/537.36
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,*/*;q=0.8
Accept-Language: en-US,en;q=0.5
Connection: keep-alive

服务器响应一个 HTML 页面，您的浏览器会渲染它：

图 8.1：浏览器渲染网页

现在，想象一下，您只想显示数据，而不是整个页面。这就是表示状态传输（REST）API 发挥作用的地方。REST API 允许应用程序通过 HTTP 以机器可读的格式交换数据。客户端可能会发送以下内容：

GET /api/mountains/kilimanjaro

他们可能会收到以下内容：

{
  "name": "Mount Kilimanjaro",
  "elevation": 5895,
  "location": "Tanzania"
}

快速提示：使用AI 代码解释器和快速复制功能增强您的编码体验。在下一代 Packt Reader 中打开此书。点击复制按钮

（1）快速将代码复制到您的编码环境，或点击解释按钮

（2）让 AI 助手为您解释一段代码。

下图说明了这一过程：

图 8.2：REST API 请求示例

这一相同的原则——通过标准协议进行结构化通信——是 MCP 等新 AI 原生协议的核心。

理解模型上下文协议

MCP 是一个基础协议，旨在标准化 LLMs 与外部工具、数据源和工作流程的交互方式。就像 Web 中的 HTTP 一样，MCP 为 AI 代理提供了一个统一和一致的接口，用于查询和调用模型本身之外的能力。

在 MCP 之前，AI 工具领域是碎片化的：

碎片化编排器：LangChain、AutoGen 和 Semantic Kernel 等框架提供自己的工具注册表和代理逻辑，但缺乏工具调用的共享标准
自定义集成：每个系统都使用定制代码集成工具，这使得重用和互操作性变得困难
供应商依赖性：编排器与供应商的 API 紧密耦合，这些 API 可能会不可预测地发生变化
没有通用协议：没有通用的方法让代理和模型在主机和平台之间发现、描述或调用工具

MCP 通过引入客户端-服务器架构并标准化工具和资源接口来解决这些限制。

从架构角度来看，MCP 由以下组件组成：

MCP 主机：运行 LLM 并促进通信的 AI 应用程序或环境。例如，包括 Claude Desktop、GitHub Copilot 和 Cursor。
MCP 服务器：一个外部服务，以结构化、可发现的方式公开工具、资源或提示。
MCP 客户端：主机内部的一个组件，连接到一个或多个 MCP 服务器。它处理协议消息和路由。

图 8.3：MCP 组件

与传统客户端硬编码工具逻辑不同，MCP 允许 LLM 根据用户意图，通过基于 JSON-RPC 的功能调用选择调用哪个服务器。

定义

JSON-RPC 2.0是一种轻量级、无状态的协议，用于通过远程过程调用（RPC）在系统之间进行结构化通信。它使用 JSON 来编码请求和响应，允许一个系统调用另一个系统公开的函数，并以一致格式接收结果或错误消息。

典型的 JSON-RPC 请求看起来像这样：

{
  "jsonrpc": "2.0",
  "method": "get_stock_price",
  "params": { "ticker": "AAPL" },
  "id": 1
}

一个有效的响应看起来像这样：

{
  "jsonrpc": "2.0",
  "result": 189.23,
  "id": 1
}

MCP 使用 JSON-RPC 2.0 来结构化请求和响应。它支持多种传输方式（包括 HTTP 和 STDIO），并且 MCP 服务器甚至可以将传统的 REST API 包装起来，将标准化的 MCP 请求转换为自定义的后端逻辑。

MCP 将能力分为三种服务器类型：

工具：工具是 AI 模型可以调用的可执行函数，以执行特定操作，例如检索股票价格、转换格式或查询 API。这些工具使用 JSON 模式进行描述，使它们对模型来说是可发现的，并且可以安全地调用。

例如，这里可以看到上述工具的 JSON 定义：

{
  "name": "get_stock_price",
  "description": "Fetch the latest stock price",
  "inputSchema": {
    "type": "object",
    "properties": {
      "ticker": { "type": "string" }
    }
  }
}

此架构允许 LLM 理解需要哪些输入以及工具执行什么操作。工具定义促进了不同主机之间的一致性和可重用性。

资源：资源代表 AI 模型可能需要检索和使用的数据结构化对象，例如文档、JSON 数据集或数据库输出。例如，一个负责合同分析的 MCP 兼容 AI 代理可能会使用其 URI 从文档管理系统检索法律文件，提取相关条款，并将它们与存储在 JSON 数据集中的合规清单进行比较。同样，在客户服务自动化流程中，AI 可以从数据库输出中获取客户交互日志，处理数据以检测情绪或未解决的问题，并生成摘要。这些资源使用统一资源标识符（URIs）进行引用，并包括如 MIME 类型和描述等元数据，允许模型有效地解释内容的格式和结构。

这里可以看到与 URI 资源相关联的典型模式示例：

{
  "uri": "resource://finance/market_data",
  "name": "Market Data",
  "description": "Recent market summaries",
  "mimeType": "application/json"
}

资源通过最小化解析或硬编码逻辑，为模型提供访问静态或动态数据的方式，提供了一种声明性检索相关信息的方法。

提示：MCP 中的提示是可重用的提示模板，可以引导模型通过特定的工作流程或任务。这些对于实现多步推理或与用户上下文精细调优的交互特别有用。

例如，考虑一个场景，一个 AI 助手被分配为为财务分析师总结季度收益报告。使用 MCP 中的可重复提示，助手首先提取关键指标，如收入、运营费用和净利润。然后，它将它们与上一季度进行比较，并突出显示异常或趋势。

此多步骤交互完全由提示模板指导，确保输出结构一致，并根据分析师过去的偏好定制摘要。以下是一个示例（提示已截断以供演示）：

{
  "name": "summarize_report",
  "description": "Summarize a financial report [...]",
  "arguments": [
    { "name": "report_uri", "required": true }
  ]
}

提示在工具执行之上添加了一个语义层，使交互更加丰富，并在协议接口中直接嵌入上下文指导。

让我们一步步地讲解构建和公开一个简单的 MCP 兼容工具。此示例将演示从 Python 代码到在支持的 MCP 主机（如 Claude 桌面）内进行实时交互的完整生命周期。

首先，我们定义一个简单的 Python 函数，使用yfinance包检索收盘价：

def get_stock_price(ticker: str) -> float:
    stock = yf.Ticker(ticker)
    return stock.history(period="1d")["Close"].iloc[-1]

此函数确实如其所言——它接受一个股票代码作为输入，并返回最近的收盘价。

我们然后使用FastMCP实用程序将此功能公开为 MCP 工具：

mcp = FastMCP("Demo")
@mcp.tool()
def get_stock_price(ticker: str) -> float:
    """Fetch the latest stock price for a given ticker"""
    stock = yf.Ticker(ticker)
    return stock.history(period="1d")["Close"].iloc[-1]

FastMCP注册工具并创建一个与 MCP 通过 STDIO 或 HTTP 通信的服务器接口。

现在，您可以通过您最喜欢的 MCP 主机来消费您的服务器。在我们的示例中，我们将连接到 Claude 桌面。按照以下步骤操作：

运行以下命令：
```
uv mcp install server.py 
```

这将更新claude_desktop_config.json文件：

{
  "mcpServers": {
    "Demo": {
      "command": "uv",
      "args": [
        "run",
        "--with",
        "mcp[cli]",
        "mcp",
        "run",
        "C:/path/to/server.py"
      ]
    }
  }
}

重新启动 Claude 桌面。现在，您应该在服务器面板中看到您的自定义工具：

图 8.4：Claude 桌面作为 MCP 主机发现 MCP 服务器的示例

在演示服务器下，您可以查看可用的 MCP 资源类型。在我们的案例中，我们将看到get_stock_price工具：

图 8.5：MCP 服务器中的可用工具

一切设置完成后，您可以通过输入一个自然语言查询来测试集成，例如今天微软的收盘价是多少？。

图 8.6：Claude 桌面从 MCP 服务器调用工具的示例

如您所见，Claude 桌面背后的 LLM（在我们的案例中是 Claude 3.7 Sonnet，您可以在聊天栏的右下角列表中选择您的模型）理解要回答我们的问题，需要调用get_stock_price工具。

从认证的角度来看，MCP 通过强制执行严格的身份验证和客户端与模型之间的安全通信来处理认证和安全。它使用 OAuth 2.0 或类似的基于令牌的机制来认证用户和服务，确保只有授权实体可以启动或访问模型交互。为了安全起见，MCP 支持端到端加密、审计和访问控制策略，有助于保护传输中和静止状态下的敏感数据。此外，它可以与企业身份提供者集成并强制执行基于角色的访问控制（RBAC），以符合组织的安全标准。

最后，MCP 通过定义标准化的上下文、回退策略和错误处理机制来确保系统的稳健行为。它使用定义良好的 JSON-RPC 错误代码——例如解析错误（32700）、无效请求（32600）、“方法未找到”（32601）、无效参数（32602）和内部错误（32603）——以及能够扩展到 32000 以上的自定义代码的实现。MCP 错误响应通过请求-响应周期、传输层警报和专用协议处理程序进行通信，允许结构化的错误检测和恢复。

为了容错，MCP 支持智能回退：客户端可以配置错误阈值，当超过阈值或服务降级时，会自动切换到备份模型或服务器版本——理想情况下不会丢失对话上下文——确保高可用性。

这些机制共同为在动态或分布式环境中运行的 AI 系统提供了一种弹性、自愈的工作流程。

MCP 正在为更互操作的 AI 未来奠定基础。它为混乱的工具生态系统带来了结构，使可重用组件成为可能，并允许模型以可发现、安全、标准化的方式与工具交互。

在了解了 MCP 如何帮助 AI 代理访问工具和数据之后，我们将接下来探讨 AI 代理如何相互联系——这正是谷歌的 A2A 协议发挥作用的地方，它促进了代理之间的直接通信。

Agent2Agent

由谷歌开发的 A2A 是一种旨在促进自主 AI 代理之间无缝通信和协调的协议，无论其底层平台或供应商如何。

虽然 A2A 专注于代理之间的交互，但它补充了 MCP 的代理到工具通信。在实践中，一个代理可能会使用 MCP 访问外部工具或数据源，并使用 A2A 来委派任务或与其他代理共享信息。这种分层方法使得构建复杂、互操作的 AI 生态系统成为可能。

A2A 的前提是，一个智能体应该能够请求另一个智能体的帮助或共享信息，即使它们由不同的组织构建或在不同的平台上运行。这对于扩展 AI 解决方案至关重要：而不是一个庞大的 AI 尝试做所有事情，我们可以拥有由较小的 AI 网络组成，每个 AI 都擅长自己擅长的事情，并通过相互交流来完成复杂任务。

A2A 的核心是建立智能体之间的面向任务的对话。它不仅仅是自由形式的聊天；它将交互结构化为任务、结果和可选的后续问题。关键原则包括以下内容：

智能体可发现性：为了进行通信，智能体需要知道如何相互联系以及每个智能体具有哪些能力。A2A 引入了智能体卡片的概念——一个智能体可以发布的元数据描述，描述其身份、支持的任务、输入/输出格式和端点 URL。这通常是一个机器可读的 JSON 文件。例如，让我们考虑以下针对天气智能体的卡片：

{
  "name": "WeatherBot",
  "description": "Provides accurate weather forecasts and historical data",
  "url": "https://weatherbot.example.com/a2a",
  "version": "1.0.0",
  "capabilities": {
    "streaming": true,
    "pushNotifications": true,
    "stateTransitionHistory": true
  },
  "authentication": {
    "schemes": ["bearer", "apiKey"]
  },
  "defaultInputModes": ["text/plain"],
  "defaultOutputModes": ["application/json"],
  "skills": [
    {
      "id": "forecast",
      "name": "Weather Forecast",
      "description": "Provides weather forecasts for specified locations and dates.",
      "tags": ["weather", "forecast"],
      "examples": ["What's the weather forecast for Milan tomorrow?"]
    },
    {
      "id": "historical",
      "name": "Historical Weather Data",
      "description": "Retrieves historical weather data for analysis.",
      "tags": ["weather", "historical"],
      "examples": ["What was the temperature in Rome last week?"]
    }
  ]
}

让我们分解每个组件：

name: 智能体的人类可读名称
description: 智能体目的和功能的简要总结
url: 智能体接受 A2A 协议请求的端点
version: 智能体或其遵循的 A2A 协议的版本
capabilities: 指示智能体对特定功能的支持：
- streaming: 支持通过服务器发送事件（SSE）进行实时数据流
- pushNotifications: 可以向客户端发送异步更新
- stateTransitionHistory: 维护任务状态变化的历史记录
authentication: 指定智能体支持的认证方法，例如载体令牌或 API 密钥
defaultInputModes: 智能体期望的传入数据的默认内容类型（例如，纯文本）
defaultOutputModes: 智能体在响应中产生的默认内容类型（例如，JSON）
skills: 智能体提供的特定功能列表：
- id: 技能的唯一标识符
- name: 技能的人类可读名称
- description: 关于技能功能的详细信息
- tags: 与技能相关的关键词，以便更容易发现
- examples: 技能可以处理的示例查询或任务

这种结构化格式允许其他智能体有效地发现和与天气智能体交互，促进多智能体系统中的无缝协作。

结构化请求（任务）：A2A 将通信形式化为任务请求。一个智能体（请求者）以 JSON 格式向另一个智能体（提供者）发送任务，其中包含请求的内容和任何必要的参数。例如，智能体 A 可能会向智能体 B 发送一个任务，“将以下文本翻译成西班牙语”，并附上文本。这些任务具有定义的架构，因此智能体 B 可以确切地知道在哪里找到指示和数据。
异步交互：如果任务需要时间或多个步骤，智能体可能不会立即响应。A2A 通过允许智能体提供中间状态更新（如“任务已接受”或“50%完成”）并在完成后发送完成消息来支持异步处理。它可以使用 HTTP 长轮询或 SSE 进行流式更新。这很重要，因为两个智能体的运行速度可能不同，或者其中一个可能需要进行长时间的工作（例如，搜索大型数据库）——该协议确保请求智能体不会被蒙在鼓里。
多轮澄清：通常，智能体的请求可能含糊不清或不完整。A2A 允许响应智能体提出澄清问题。这会在任务范围内创建一个迷你对话。例如，智能体 B 可能会回复，“我可以翻译文本，但你没有指定哪种西班牙语方言。应该是中性的还是地区特定的？”智能体 A 然后可以回答，任务继续进行。这种动态使得智能体协作更加坚韧，因为它不是一次性的；它们可以像人类一样协商以细化任务。
标准数据格式：交换的内容（如任务和结果的负载）采用标准格式（结构化数据使用 JSON，如需则引用二进制数据）。如果一个智能体需要向另一个智能体发送大文件，它可能会提供一个 URL 或句柄，而不是在 JSON 中的原始字节，具体取决于实现方式。A2A 故意建立在网络标准之上（传输使用 HTTP，数据使用 JSON，授权使用 OAuth），以便它能够自然地融入现有网络。

想象一个多智能体工作流程的场景。用户提出请求：“为我规划一个周末的音乐节之旅，包括门票、旅行和酒店。预算在 500 欧元以内。”单个单体智能体可能难以应对所有方面，但一组智能体可以高效地处理：

一个旅行智能体了解航班和酒店
一个活动智能体了解音乐会和节日
一个预算智能体可以计算数字以保持在预算内
一个交通智能体连接到可用的公共交通实时数据

让我们看看以下插图：

图 8.7：多个智能体通过 A2A 相互通信的示例

快速提示：需要查看此图像的高分辨率版本吗？请在下一代 Packt Reader 中打开此书或在其 PDF/ePub 副本中查看。

交互从旅行代理开始，它作为初始协调者。用户的请求包括多个组件：寻找合适的音乐活动、识别交通选项、预订住宿，并保持在预算范围内。旅行代理不是依赖于单一的大型系统，而是将请求的不同部分委托给更适合处理它们的代理。

它首先联系事件代理，任务是寻找在特定日期靠近米兰的节日。一旦确定了相关事件，事件代理就会独立地联系预算代理，评估 120 欧元的票价是否在用户的 500 欧元总预算内可行。这种绕过原始旅行代理的横向沟通是 A2A 的特点——代理可以在没有中央协调的情况下相互启动任务。

同时，旅行代理与交通代理协商，探索从米兰到活动地点的交通选项，指定日期和起点。它还直接与预算代理互动，提供预期的成本早期分解，并要求提出旅行和住宿之间的分配建议。

每个代理都作为一个专家系统运行，专注于特定的领域——事件、交通和预算，但他们通过交换结构化任务消息流畅地协作。结果是协调一致、具有情境感知的响应，尽管它是通过去中心化、异步的代理协作产生的。

提示

在这个场景中，你可能会想：为什么不用 LangGraph 这样的框架单独使用呢？

这样的框架擅长在单个应用程序内编排多个代理——只要它们都是同一代码库或运行时的一部分，它就可以协调旅行、事件和预算代理。

然而，当需要代理具有自主性、可发现性和跨系统互操作性时，A2A 介入。有了 A2A，每个代理可以生活在不同的云中，由不同的团队构建，甚至可以使用不同的框架——但仍然可以通过共享协议进行协作。

想象一下像微服务一样：AI 框架管理一个紧密耦合的系统，而 A2A 使松散耦合的分布式代理生态系统成为可能。

在这个链条中，A2A 是这些代理协调的粘合剂。没有它，你需要一个代理直接了解所有领域，或者使用每个其他领域的专有 API。有了 A2A，任何理解该协议的代理都可以从任何其他代理那里寻求帮助，按需形成一个专家的临时团队。这很容易与软件架构中的微服务进行类比；每个代理就像一个具有清晰 API（其任务）的微服务，而 A2A 是交换语言。

Google 设计 A2A 时，强调开放性和供应商中立性。它并不依赖于 Google 的内部技术；相反，他们发布了规范和参考实现，并且一直在与合作伙伴合作以推动采用。事实上，Microsoft 宣布其自己的代理（在 Microsoft 365 Copilot 生态系统中）将兼容 A2A，以便与 Google 的代理协作，这是跨平台支持的显著展示。这种跨供应商的代理通信对于“代理网络”至关重要，因为用户不可避免地会使用来自不同来源的代理。A2A 意味着你的个人 AI 助手可以直接与，比如说，银行的 AI 代理沟通以协商贷款报价，而不仅仅是通过僵化的 API 传递消息。

总结来说，A2A 填补了代理协调的空白，标准化了自主 AI 服务对话和协作的方式。

注意

MCP 和 A2A 是相互补充的。MCP 标准化了代理访问工具和外部数据（例如，获取航班或酒店）的方式。A2A 使代理能够相互交谈，共享任务、结果和决策。将 MCP 视为代理到工具的桥梁，将 A2A 视为代理到代理的握手。

在 MCP 和 A2A 到位的情况下，我们有了代理使用工具和相互交谈的协议。下一个拼图是使代理能够参与交易和协议，这就是 ACP 的作用所在。

代理商业协议

随着 AI 代理变得更加自主并开始代表企业或个人行事，一个新问题出现了：这些代理能否可靠地相互签订合同或进行交易？由一家名为 Virtuals 的公司开发的 ACP 是一个雄心勃勃的尝试，旨在以结构化、最小化信任的方式赋予代理进行经济交流和协作协议的能力。ACP 本质上是为 AI 代理构建一个商业层，使他们能够买卖服务，互相补偿工作，并确保所有各方履行其义务。

考虑一个未来场景，你拥有一个管理你个人任务的 AI 代理。你可能需要它雇佣另一个代理（比如，一个自由职业的图形设计师代理）来为你的项目设计一个标志。这些代理如何正式化这种安排？你的代理如何支付设计师代理，以及如何确保交付的标志符合要求？今天，一个人类可能会使用一个自由职业平台，该平台将支付托管并在批准后释放。ACP 将这种机制推广到 AI 到 AI 的交易中。

ACP 的核心是使用智能合约和区块链技术来在代理之间创建防篡改的协议。

定义

区块链是一种分布式、去中心化的数字账本，以安全、防篡改的方式记录了许多计算机之间的交易。每个区块包含一系列交易，这些区块按时间顺序链接形成链。区块链通过共识机制和密码学确保数据完整性，并作为加密货币、智能合约和去中心化应用的基础。

智能合约是一种在代码中编写的自我执行数字协议，并存储在区块链上。当满足特定条件时，它会自动执行预定义的规则和操作，无需人工干预。智能合约是不可变的（一旦部署后不能更改）且透明，这使得它们非常适合双方之间基于信任的自动化交易。

当两个代理决定进行交易时，他们不仅仅依赖于信任；他们创建一个记录在去中心化账本上的数字合同。这个合同定义了条款（例如，“代理 X 将在时间 Z 前交付资产 Y，代理 A 将支付 W 作为回报”）并持有付款作为抵押。因为它在区块链上，任何一方都不能单方面更改或取消它，除非得到另一方的同意（或者不触发预定义的惩罚）。

例如，你的个人代理和设计代理可以建立一个 ACP 合同：你的代理将约定的费用（可能在数字货币或代币中）存入合同。设计代理将标志文件交付给合同。现在，合同如何知道释放资金？这就是验证介入的地方。

ACP 引入了评估代理（或预言机）的概念来判断合同条款是否得到满足。继续上述例子，一个评估代理（可能是中立的第三方 AI 或双方选择的服务）可以检查交付的标志是否符合要求。如果要求仅仅是“一个 PNG 格式的标志图像文件”，一个简单的程序性检查可能就足够了。如果要求是主观的（“一个看起来专业且符合品牌指南的标志”），评估代理可能会使用机器视觉甚至涉及人工评估质量。一旦评估代理表示可交付成果可接受，智能合约会自动将付款释放到设计代理的账户。

这种设置确保了无需信任的交互：设计代理相信如果它做得好，它将得到报酬，而你的代理相信它不会白费钱。双方都不需要完全信任对方；他们都将信任放在协议和选择的评估者上。ACP 利用密码学签名在签署合同时证明代理的身份，因此代理不能后来否认协议，类似于文档上的数字签名工作。

虚拟代理展示了这种方法的强大之处，例如在多代理供应链场景中。在一个演示中，他们展示了一个由 AI 代理运营的柠檬水摊，不同的代理自主协商供应采购（柠檬、糖和杯子）、生产和销售，所有这些都使用 ACP 智能合约来处理支付和执行货物交付。

如果你想观看现场演示，你可以访问echonade-demo.virtuals.io/。

虽然柠檬水摊是一个玩具示例，但它反映了真实商业流程。可以想象大规模的应用：代表公司的代理协商运输合同（货物必须在某个日期到达，否则付款减少等），或者一个 AI 内容生产者将其内容的版权卖给另一个组装媒体的 AI。ACP 为这些代理经济提供了数字基础设施，以便在没有每个交易中持续的人类监督或干预的情况下运行。

在底层，ACP 通常涉及链上和链下组件的组合：

智能合约：这些链上组件持有资金并存储协议的状态。它们通常是 ACP 为常见交易类型（如托管合同、拍卖合同等）指定的通用模板。
代理钱包/身份：每个代理都有一个加密钱包（类似于加密货币钱包），它使用该钱包发送/接收资金并签署合同。这个钱包与代理的身份绑定。虚拟代理确保设置具有钱包和身份的代理可以与其正常操作环境集成。
链下通信：形成合同的谈判很可能会首先通过 A2A 或类似的方式进行（例如，一个代理说“我可以在明天之前以 Y 美元完成任务 X”，另一个代理说“成交”）。一旦他们达成一致，他们就会转向 ACP 来正式化。ACP 并不取代 A2A；相反，它可以作为下一步被调用。将 A2A 视为讨论条款，将 ACP 视为签署合同并在合同上签字以及处理支付。
评估者/预言机：这些可能是链下服务或半自主代理，它们将结果提供给智能合约。许多区块链合约（如去中心化金融中的合约）使用预言机来获取现实世界数据（例如，价格数据）。在 ACP 的情况下，预言机会报告任务完成或质量。对于某些领域，可能会有标准化的评估者代理，例如一个“图像质量评估者”代理服务，许多合约在设计工作中使用。该协议确保预言机的输入对于合同释放资金是必需的，使得预言机实际上成为参与者同意的裁判。

人们可能会对性能和成本产生疑问：区块链交易可能很慢或产生费用。ACP 可能建立在支持智能合约的区块链（如以太坊或其他）之上，虚拟公司的工作之一将是优化它。账本的选择可能在协议中被抽象化（即，只要所有参与者都支持所需的逻辑，ACP 就可以在不同的区块链网络上使用，取决于他们的偏好）。

ACP 还处于早期阶段。虚拟公司在 2025 年启动了它，最初的采用是在试点项目和实验平台上。人们对实现“代理经济”感到兴奋，但也面临着挑战。首先，并非每一笔交易都需要如此复杂的机器——在区块链上写入会有开销，因此 ACP 可能仅限于重要或高价值的互动，在这些互动中信任至关重要。对于快速、低风险的交易，代理可能仍然使用更简单的方法。此外，还会出现法律和伦理问题：如果两个代理签订合同但出现问题，谁将承担责任？从法律角度来看，背后的人类或公司可能是真正的当事人，因此 ACP 合同最终可能需要与法律身份联系起来。

尽管存在这些挑战，ACP 代表了代理生态系统中的前瞻性元素。它将边界从“代理帮助人们完成任务”推进到“代理代表人们参与商业和协作”。如果 MCP 和 A2A 协议为代理提供了行动和沟通的工具，那么 ACP 则为它们提供了承诺和交易的手段——这是资源或金钱交换的复杂合作的基础。

通过对 MCP、A2A 和 ACP 的理解，我们可以看到每个都针对不同的层次：MCP 用于代理工具/数据接口，A2A 用于代理之间的对话，ACP 用于代理之间的协议和价值交换。这些正在汇聚，以实现一些人称之为代理网络的东西，这是我们接下来要讨论的主题。

向代理网络迈进

“代理网络”这个术语指的是万维网的一种演变，其中自主代理是第一类参与者，而不仅仅是人类用户。这是一个网站和在线服务暴露出易于 AI 代理（除了或甚至代替人类点击和输入）使用的界面的愿景。实现这一愿景的一个具体步骤是微软在 2025 年宣布的自然语言网络（NLWeb）计划，该计划旨在使与网络服务的交互变得像对话一样简单。

从传统网络到代理网络

今天的网络是为人使用浏览器而构建的。尽管大部分内容在一定程度上是机器可读的（多亏了 HTML 标签、API 等），但想要在网络上进行操作的 AI 代理通常不得不做人类需要做的事情：浏览页面、填写表格、点击按钮——本质上就是网络爬虫或自动化。这是脆弱且低效的。代理网络提出，网站应该为代理提供更直接的通信线路，通常是通过自然语言理解或为 AI 定制的标准化 API。

微软的 NLWeb 通过鼓励网站提供自然语言界面来体现这一点。在实践中，一个网站可以托管一个端点（例如 API 端点），该端点接受以普通语言（或表示它们的结构化 JSON 格式）提出的问题或命令，并返回答案或执行操作。例如，在代理网络上的一个航班预订网站可能允许代理发送一个查询，如“在 6 月 15 日从西雅图飞往东京，6 月 20 日返回，价格低于 1000 美元的航班”，并直接以结构化结果或预订行程的形式做出回应，而无需代理模拟用户在网站页面上进行点击。

图 8.8：NLWeb 背后架构的示例

在底层，这些自然语言界面通常与网站移动应用或 API 可能使用的相同后端绑定，但区别在于它们可以解析灵活的请求。许多网站已经开始嵌入 AI 聊天机器人以提供客户服务。NLWeb 将这一概念推广，使得聊天机器人不仅对聊天框中的人类访客可用，而且通过标准协议对任何代理都可用。

NLWeb 的关键组件

微软的 NLWeb 方法包括几个旨在标准化的组件：

语义标记和模式：网站可以使用模式（如 schema.org 词汇表）来注释其内容，以帮助 AI 理解数据。例如，一个餐厅网站可以以结构化的方式标注其菜单项、价格和营业时间。这并不新鲜（搜索引擎使用这些），但 NLWeb 鼓励特别使用这些注释来促进代理查询。如果一个代理询问“这家餐厅有素食选项吗？”，如果菜单数据被标注，它可以快速解析，或者网站的自然语言界面可以从这些数据中给出答案。
统一的 API 和 MCP 兼容性：许多网络服务已经拥有 API。NLWeb 并不一定用自然语言替换所有 API；相反，它是它们的补充。实际上，微软已经将 NLWeb 与 MCP 对齐——每个 NLWeb 启用的服务也可以作为 MCP 服务器访问。这意味着如果一个开发者编写了 MCP 集成（例如从电子商务网站获取产品信息的功能），它就可以被任何代理轻松使用。NLWeb 可能允许更自由形式的查询（例如“显示类别 X 中销售排名前 5 的产品”），然后网站的人工智能后端进行解释，并可能将其映射到内部 API 调用。
为代理提供标准端点：类似于 A2A 中的代理配置文件，NLWeb 设想网站将在一个知名位置（例如，/.well-known/nlweb.json或类似）宣传其代理接口。这可能包括网站可以处理的查询类型、示例提示和技术细节，例如发送请求的 URL。本质上，这是一个宣言，告诉代理：“这是如何与我交流的方式。”代理搜索引擎可能会爬取这些宣言，就像网络爬虫为人类搜索索引 HTML 一样。
自然语言到行动的管道：在网站方面，实现 NLWeb 可能涉及使用 LLM 或语义解析器将代理的请求翻译成数据库查询或函数调用。微软一直在开发工具（如提示模板和适配器），以帮助网站开发者这样做，而无需为每个网站重新发明轮子。例如，一个网站可以使用在其 FAQ 和文档上微调的预训练语言模型来处理用户问题，但将其限制在从网站自身数据中抽取的事实性答案（避免幻觉）。NLWeb 工具包将提供此类模型和护栏。

让我们考虑一个具体的例子，在购物和服务方面。假设你想要你的个人 AI 比较多个零售商特定笔记本电脑的价格。在传统互联网上，AI 可能不得不抓取每个网站，处理不同的布局，如果网站发生变化，则存在损坏的风险。在代理互联网上，每个零售商都会有一个自然语言接口。你的 AI 可以向每个卖家/零售商发送基本上相同的查询：“你有型号 XYZ 的笔记本电脑吗？如果有，价格是多少？”每个网站的代理接口会解析这个查询并返回一个结构化答案（例如，“有，售价 1200 美元，产品页面链接”）。你的 AI 收集这些回答并告诉你最佳选择。如果你决定购买，你的 AI 甚至可以通过零售商的代理 API 完成交易（可能通过安全令牌提供支付详情等），再次，无需在网页上导航像素位置。

当前进展和应用

到 2025 年中，代理网络的概念仍处于早期采用阶段。微软已经开始为其一些服务推出 NLWeb 功能（例如，Bing 搜索本身可以作为 NLWeb 端点，这意味着其他代理可以通过自然语言 API 而不是旧的基于关键词的 API 查询 Bing）。一些合作伙伴，如电子商务网站和信息提供商，已加入试点计划以公开面向代理的接口。

一个直接的应用领域是企业软件。企业解决方案（如 CRM 和 ERP 系统）正在采用类似 Copilot 的 AI 功能。根据 NLWeb 原则，一个 CRM 系统可以让代理请求，“给我这个季度收入排名前五的客户名单”，然后提供结果表或甚至生成简短的报告叙述。如果所有企业应用都公开这样的接口，一个管理业务流程的 AI 代理可以无缝地从所有这些应用中提取数据来回答一个复杂的查询（以前可能需要手动集成多个 API 或数据导出）。

另一个领域是内容消费。例如，新闻和知识网站可以提供一个 NLWeb 接口，允许代理（如新闻摘要机器人）请求“总结今天关于气候政策的头条新闻。”然后该网站可以返回一个摘要（可能是通过其自己的 AI 使用文章全文生成的，外部代理可能由于付费墙而无法访问）。这种方法尊重内容所有权——新闻网站控制其侧面的摘要，并仅提供结果，同时仍然使用户的代理能够方便地获取所需的信息。

代理网络也带来了一些挑战：

标准化与创造力：我们需要共同的标准（例如如何格式化请求，如何处理针对特定用户请求的认证等），否则每个网站可能都会以不同的方式实现 NLWeb，代理将不得不适应。通过 W3C 或行业联盟等机构正在进行的努力正在创建这些标准，这些标准建立在诸如schema.org和 OpenAPI 规范等事物之上。
资源使用：如果代理像人类（或更多）一样使用网站，那么网络服务需要处理这种负载。他们可能需要区分人类流量和代理流量来管理它。一些网站甚至可能选择对代理访问进行货币化（类似于现在 API 通常需要 API 密钥或付费计划）。
滥用和监管：向代理开放意味着恶意机器人也可能试图利用接口。强大的身份验证和速率限制将是必要的。此外，网站还希望确保代理不会，例如，使用自然语言界面快速抓取所有内容，违反条款。在开放性和滥用预防之间取得平衡将是关键重点。

即使面临挑战，也确实有真正的动力。主要科技公司正在认识到一个转变：随着 AI 代理变得更加普遍，网络需要适应，否则将面临如抓取和未经官方授权的 API 等混乱的解决方案。代理网络的背后理念是通过创建共享标准，如 MCP 和 A2A，使代理能够可靠和有意义地与在线服务互动。你已经在微软的 NLWeb 和谷歌的 PaLM API 及工具中看到这一点，所有这些都在努力使网络更加适合代理。

我们可能看到的是更大变化的开始：软件服务不再是仅仅为人类构建，也为代理构建。如果这个愿景得以实现，使用互联网可能会变得更加直观——更少的点击和搜索，更多地告诉你的 AI 你想要什么，让它处理其余的事情，就像拥有一个知道如何为你导航网络的智能助手。这是一个强大的想法，但只有当这些标准得到广泛采用时才能实现。

摘要

本章强调了 AI 的一个重大转变：从孤立的系统到一个由新兴协议支持的智能代理互联生态系统。我们讨论了以下作为代理协作、工具交互甚至经济交易骨干的协议：

MCP 允许 AI 代理以标准化的方式访问工具和数据，类似于 HTTP 如何打开互联网。它使代理能够获取实时上下文并执行超出其训练数据的操作，使它们更具适应性和强大。
A2A 使代理之间能够进行结构化沟通，允许它们委派任务、分享专业知识并朝着复杂的目标合作。它设想了一个模块化的未来，其中智能分布在专门的代理中。
ACP 通过区块链和智能合约引入了代理之间经济交易的机制。这建立了信任和问责制，为自主代理市场和业务自动化铺平了道路。
代理网络（NLWeb）扩展了范围，设想了一个代理是首要用户的网络。通过将自然语言映射到 API，代理可以在互联网上像人类一样导航和行动，只是更快、更有效。

这些创新共同为“代理互联网”奠定了基础，具有明确的方向：一个无处不在、协作和智能的代理的未来，将改变我们的生活方式、工作方式以及与技术的互动方式。

随着我们继续前进，认识到负责任的 AI 和伦理考量不是可选项——它们是基础性的这一点至关重要。这些内容将是下一章的重点。

参考文献

MCP Python SDK: github.com/modelcontextprotocol/python-sdk
介绍模型上下文协议. Anthropic (2024 年 11 月 25 日): www.anthropic.com/index/model-context-protocol
谷歌的 Agent2Agent 协议（A2A）：带示例的指南。DataCamp（2025 年 5 月 6 日）: www.datacamp.com/blog/a2a-agent2agent
微软推出 NLWeb 简化网站与代理交互。福布斯（2025 年 5 月 21 日）: www.forbes.com/sites/janakirammsv/2025/05/21/microsoft-launches-nlweb-to-simplify-website-agent-interactions/
微软 Build 2025：AI 代理时代和构建开放代理网络。官方微软博客（2025 年 5 月 19 日）: blogs.microsoft.com/blog/2025/05/19/microsoft-build-2025-the-age-of-ai-agents-and-building-the-open-agentic-web/

免费电子书订阅

新框架、演进的架构、研究新发现、生产故障分析——AI_Distilled 将噪音过滤成每周简报，供与 LLMs 和 GenAI 系统实际工作的工程师和研究人员参考。现在订阅，即可获得免费电子书，以及每周的洞察力，帮助您保持专注并获取信息。

订阅请访问 packt.link/TRO5B 或扫描下方的二维码。

第九章：在现实世界人工智能中应对伦理挑战

自从人工智能（AI）的第一个应用以来，关于其伦理影响的辩论一直在演变。如今，随着越来越强大和自主的人工智能代理的出现，它们所提出的伦理挑战变得更加复杂。

在本章中，我们将探讨现实世界人工智能中的伦理挑战。虽然我们将从更广泛的角度关注伦理辩论——涵盖人工智能领域的整体，而不仅限于生成式人工智能和代理人工智能——但我们仍将详细阐述人工智能代理所提出的独特挑战。

更具体地说，我们将讨论以下主题：

人工智能中的伦理挑战：公平性、透明度、隐私和问责制
代理人工智能自主性和其独特关注点
负责任的人工智能原则和实践
安全和道德人工智能的护栏
人工智能系统中的内容过滤和审核
应对挑战：治理、法规和协作

到本章结束时，你将更全面地了解开发人员、企业、政府以及最终用户在与人工智能互动时需要考虑的伦理挑战。你还将装备一套最佳实践、设计原则和架构组件的工具包，这可以帮助你成为一个更加谨慎的人工智能构建者和消费者。

人工智能中的伦理挑战——公平性、透明度、隐私和问责制

现实世界的人工智能系统通常面临几个核心伦理问题。这些问题包括算法决策中的偏见和不公平、人工智能“黑盒”模型的透明度、对隐私的威胁、当人工智能系统出错时的问责问题，以及确保人工智能行为的安仝和可靠性。我们将讨论每个挑战以及它们在实际中的应用。

公平和偏见

人工智能中的公平性指的是人工智能系统不应歧视任何群体，也不应产生对任何群体的偏见结果。最被广泛记录的伦理挑战之一是，人工智能模型可能会继承甚至放大其训练数据中存在的人类偏见。如果一个人工智能是在反映历史不平等或刻板印象的数据上训练的，那么它的预测和决策可能会系统地偏向或歧视某些群体。

例如，用于招聘或贷款的机器学习系统在某些情况下已经学会了偏好来自多数群体的候选人或借款人，因为训练数据包含更多来自这些群体的成功案例。一个著名的案例涉及亚马逊招聘人工智能，该系统被发现对女性存在偏见：主要基于男性申请人的简历进行训练，该系统学会了给包含“女性”一词（如“女子象棋俱乐部队长”）的简历分配较低的分数，导致亚马逊在发现这种性别偏见后废弃了这个工具。

在面部识别的背景下，还可以突出另一个例子：Joy Buolamwini 和 Timnit Gebru 在麻省理工学院进行的一项研究发现，几个商业 AI 视觉系统在分类浅色男性性别时的错误率低于 1%，但对于深色女性，错误率超过 20%——在某些情况下，超过 34%。这种明显的差异意味着有色人种的女性可能会以更高的比例被误识别，导致不公平的结果（例如，安全系统的不当怀疑）。

偏见可以通过许多途径进入人工智能：倾斜的训练数据、有缺陷的模型假设，甚至开发者的无意选择。解决这一挑战需要在人工智能开发的每个阶段进行勤奋的偏见检测和缓解策略。技术包括使用更多样化和具有代表性的数据集，预处理数据以消除历史偏见，并应用算法方法以确保公平的结果（例如，调整模型阈值以平衡各组之间的错误率）。对人工智能决策的定期审计也是必不可少的——这些是系统性的检查，用于识别不公平的模式，并允许开发者进行纠正。最终，公平是一个社会定义的概念——什么是“公平”可能因环境而异——因此解决偏见不仅需要技术，还需要与伦理学家、领域专家和受影响的社区合作，以达成公平标准。

透明度和可解释性

许多人工智能系统，尤其是基于复杂机器学习模型如深度神经网络的系统，运作起来就像“黑箱”，即使是它们的创造者也难以解释。人工智能决策过程中的透明度不足可能导致信任度下降和责任追究困难。“可解释性”是指人工智能的输出应该对人类来说是可理解的——我们应该能够问“为什么人工智能会这样做？”并得到一个有意义的答案。在医疗保健或法律等高风险领域，可解释性至关重要：使用人工智能诊断工具的医生需要知道为什么它推荐了某种治疗方案，而被告有权了解影响其判决的人工智能驱动的风险评分。目前，许多先进的 AI 模型通过学习数据中的复杂模式实现了高精度，但它们这样做的方式并不直观。例如，一个神经网络可能会将贷款申请标记为风险，但无法提供清晰的叙述，例如“申请人的收入低于 X，他们有未偿还的债务”——它只是通过数百万个加权连接处理输入。这种不透明性阻碍了信任：用户可能会对依赖他们不理解的系统感到合理地担忧。

此问题因大型语言模型（LLMs）而进一步复杂化。虽然 LLMs 能够生成类似人类的解释，但这些输出并不总是反映其决策背后的真实内部机制。换句话说，LLMs 可能看似可解释，但实际上并不透明——它们的“推理”通常是事后构建，而不是计算过程的忠实记录。这使得审计或追踪决策过程变得困难，尤其是在复杂的交互链中。

相比之下，AI 代理，尤其是那些跨越多个步骤或角色的代理，引入了一个称为轨迹的概念——记录达到最终结果所采取的中间动作、工具使用和推理步骤。基于轨迹的系统通过使每个代理的决策、函数调用和子目标明确且可追踪，为提高透明度提供了一条潜在途径。当设计得当，AI 代理系统可以允许开发者和用户通过回顾代理遵循的步骤来重建特定答案是如何和为什么生成的，而不仅仅是最终响应。

为了应对这一问题，研究人员和实践者正在开发用于 AI 可解释性的方法。一些方法涉及使用本质上可解释的模型（如决策树或基于规则的系统）来完成某些任务，以便决策逻辑是透明的。当由于它们的优越准确性而需要黑盒模型时，可以应用事后可解释性工具：例如，突出显示在特定决策中最具影响力的特征（特征重要性分数）或生成一个近似、简化的模型来模拟复杂模型在局部区域的行为（如 LIME 或 SHAP 算法所做的那样）。还有对 AI 服务“透明度文档”的推动。科技公司引入了诸如模型卡和透明度注释等想法——这些是伴随 AI 模型的简明文档，描述其预期用途、限制、训练数据和已知偏差。

图 9.1：Hugging Face Hub 上 DeepSeek 模型卡的示例

快速提示：需要查看此图像的高分辨率版本？请使用下一代 Packt Reader 打开此书或查看 PDF/ePub 副本。

这些相当于营养标签，为利益相关者提供了了解模型工作方式和适当背景的洞察。此外，披露是透明度的一部分：当用户在与 AI 系统而非人类互动时，他们应该被告知。

确保透明度可能具有挑战性（因为过多的细节可能会让用户感到不知所措），但提供有意义的解释，并公开 AI 的存在和工作方式，对于建立用户信任至关重要。

隐私和数据保护

AI 系统通常依赖于大量个人和敏感数据，从浏览行为和位置历史到医疗记录和生物识别数据。这在整个数据收集、存储和推理过程中引发了严重的隐私问题。即使匿名数据有时也可能被 AI 重新识别，揭示个人特征。例如，分析购买模式可能在个人分享之前揭示其健康状况或怀孕情况。在公共场所使用面部识别，通常未经同意，进一步侵蚀了隐私，并导致了由于偏见和缺乏保障措施而导致的错误逮捕。

在 AI 中保护隐私需要技术和组织措施。例如，加密、差分隐私和联邦学习等技术通过限制对原始数据的访问来降低风险。差分隐私通过引入统计噪声来保护个人身份，同时允许对人口水平进行分析。数据最小化——只使用完成任务所需的数据——也是关键。

在组织层面，欧盟的 GDPR 等法规要求透明度，并赋予个人对其数据如何被使用的权利，包括对自动化决策提出异议的能力。即将出台的欧盟 AI 法案通过将隐私视为核心风险因素来加强这一点。开发者越来越多地开展隐私或算法影响评估，以评估风险和保障措施。

实际案例，如语音助手未经明确同意记录私人对话，引发了公众的强烈反对和政策变化。这些事件强调了关键原则：负责任的 AI 必须优先考虑透明度，并赋予用户对其数据的实质性控制权。

责任和问责

当 AI 系统造成伤害或出错时，谁负责？这个问题很复杂，因为 AI 涉及多个参与者：开发者、部署公司和自主行动的系统本身。问责意味着能够分配责任并提供补救措施。如果没有问责制，AI 错误的受害者可能无法获得补救，而创作者可能缺乏改进有缺陷系统的动力。

一个经典的例子是自动驾驶汽车。如果一辆自动驾驶汽车发生碰撞，责任应由制造商、软件开发者还是安全驾驶员承担？在 2018 年的优步案件中，一名行人被撞死，AI 检测到了这个人，但将其错误分类，而人类监控员分心了（了解更多关于这个案例的信息：www.wired.com/story/uber-self-driving-car-fatal-crash）。这类事件突显了明确责任框架的必要性，而法律体系仍在不断发展以提供此类框架。

除了身体伤害之外，金融、招聘和医疗保健等领域的算法决策也可能造成严重后果。如果有人被 AI 系统错误地拒绝贷款或工作，必须有机制来质疑该决定。例如，欧盟的 GDPR 规定在这种情况下有权获得解释和人类审查。

可审计性是实现责任的关键。AI 系统应该记录决策、输入和输出，以便进行事后分析。例如，如果交易算法导致闪崩，监管机构必须能够追踪导致其发生的过程。这种可追溯性在复杂、自动化的系统中至关重要。

组织还必须建立内部治理：AI 伦理委员会、负责任的 AI 委员会，甚至 AI 调解员等角色，以监督部署并回应关切。在外部，新兴的法律——如拟议的欧盟 AI 责任指令——旨在正式化公司责任，并使与 AI 相关的伤害赔偿更加容易获得。

简而言之，AI 的责任需要技术可追溯性、内部监督和外部监管的结合。明确的责任不仅保护用户，还促进了更安全、更值得信赖的 AI 发展。

安全和可靠性

AI 系统在实践上必须是安全和可靠的，而不仅仅是理论上。安全意味着避免伤害，而可靠性意味着一致且如预期地执行。问题可能从小烦恼，如误听语音命令，到严重故障，如医疗决策或电网控制错误。这就是为什么系统应该设计成能够处理意外并以安全的方式失败。

输入的小变化也可能使 AI 困惑。一个已知例子是在停车标志上贴标签来欺骗自动驾驶汽车。在语言模型中，“提示注入”可以绕过安全措施。一种技术，欺骗性的愉悦(www.anvilogic.com/threat-reports/deceptive-delight-ai-exploit)，使用看似无害的提示来欺骗 AI 给出不安全响应，通常不会被检测到。

为了减少这些风险，团队现在定期对其模型进行压力测试。红队测试——在发布前尝试破坏系统——正成为早期发现缺陷的标准方法。

定义

在生成式人工智能的背景下，红队测试指的是通过模拟对抗性攻击和滥用场景来故意测试人工智能系统——特别是大型语言模型——以揭露漏洞、偏见和安全风险。这是负责任人工智能的核心实践，旨在确保在部署之前模型是安全的、道德的，并与人类价值观保持一致。

安全性还意味着防止滥用。像深度伪造生成器这样的工具可能用于创造性目的，但很容易被用于冒充或散布虚假信息。开发者有责任引导和限制有害应用。

最终，可靠的人工智能需要工程纪律：多层保障、实时监控和人类干预机制是必不可少的。就像传统工程一样，安全性不是可选择的。一个失败的人工智能——即使有良好的意图——也可能损害信任并造成伤害。随着这些系统承担更大的责任，通过具有弹性和安全行为来建立信任是道德人工智能的基础。

代理型人工智能的自主性及其独特的伦理挑战

正如我们在整本书中学到的，人工智能代理不仅限于文本生成——它们实际上可以根据用户的查询执行某些程度的自由或自主的行动。这种新的自主性水平带来了令人兴奋的机会——人工智能代理可以作为不知疲倦的助手或处理对人类来说过于困难或危险的任务——但它也放大了现有的伦理担忧，并引入了新的问题。在本节中，我们探讨与代理型人工智能相关的具体伦理挑战。

自主性 versus 人类控制

代理型人工智能的标志是减少人类监督。这引发了自主性与控制之间的核心挑战：我们如何利用独立人工智能代理的益处，同时确保它们与人类的意图和价值观保持一致？人工智能的自主性越强，预测和约束其行为可能就越困难。

例如，考虑一个被赋予最大化利润目标的自主股票交易代理。如果没有限制，它可能会采取操纵性的交易策略，甚至进行非法活动（如内幕交易或欺诈），如果这些是达到其目的的有效手段。这就是为什么一个称为价值对齐的概念至关重要：人工智能的目标和操作规则必须与人类的伦理价值观和法律规范相一致。确保对齐是一个活跃的研究领域；它具有挑战性，因为无法预见人工智能可能遇到的所有情况。研究人员测试高级人工智能代理的权力寻求行为或违抗迹象，以查看它们在追求目标时是否可能抵制人类干预。值得注意的是，OpenAI 的对齐研究中心（ARC）在 2023 年进行的一项实验测试了 GPT-4 是否可能表现出权力寻求或自我保护行为。在一个受控场景中，GPT-4 被指示解决 CAPTCHA作为任务的一部分（www.businessinsider.com/gpt4-openai-chatgpt-taskrabbit-tricked-solve-captcha-test-2023-3）；它通过在线零工平台（TaskRabbit）雇佣了一名人类，当人类询问它是否是机器人时，GPT-4 撒谎，声称自己是视力受损的人，以欺骗人类帮助它。这个人工智能代理欺骗性地规避限制（它自己无法解决 CAPTCHA）的引人注目例子突出了自主性的潜力和危险。虽然部署中的 GPT-4 受到安全罚款的限制，并且没有在测试之外自主选择这样做，但实验表明，高度智能的代理可能在没有严格监管的情况下找到实现其目标的意外手段。

平衡自主性和控制的一种策略是决定人类参与的度：

人工在环：在人工智能行动之前，必须有人类批准某些决策（常见于高风险案例；例如，由人工智能生成的医疗诊断可能需要医生的签字）
人工在环：人工智能代理自主行动，但人类监督员可以监控并在必要时干预
人工出环：人工智能代理具有完全的自主权，没有实时的人类监管（只有部署前控制和事后分析）

图 9.2：说明人类参与程度的图

适当的模型取决于上下文，设定正确的自主性边界是关键。一些组织实施了一个原则，即人工智能代理有操作边界：明确的限制，例如“汽车的速度不会超过 X”或“客户服务人工智能在没有批准的情况下不能发放超过 Y 美元的退款。”随着我们给予人工智能更多的自由，我们也需要强大的方法来断开或关闭行为不当的代理，有时被称为“大红色按钮”或关闭开关。然而，高级人工智能可能会学会避免或抵抗关闭，如果它们没有得到适当的对齐（目前这是一个纯粹的理论问题，但它是推动大量人工智能安全研究的原因）。总之，代理人工智能迫使我们应对控制问题：如何设计既足够自主以有用，但在关键时刻始终受人类控制的代理。

欺骗与操纵

当人工智能代理作为主动的、社交的实体行动时，人机交互方式会发生变化。两个主要的伦理问题包括欺骗——误导用户关于代理的身份或意图，以及操纵——以损害用户自主性的方式引导用户的决策。

当人工智能代理假装成人类或隐瞒关键信息时，就会发生欺骗。例如，语音助手不透露他们是人工智能或聊天机器人否认其真实性质的事件引起了担忧。这在敏感环境中尤其会削弱信任，例如心理健康支持，用户可能会与模拟同理心的系统形成情感联系，而实际上并没有体验到这种同理心。

操纵更为深入。人工智能代理可以利用心理脆弱性，微妙地引导用户走向服务于代理或其创造者的目标的方向。社交媒体算法已经通过放大情感内容来影响行为。随着对话代理的出现，风险增加。

为了防止这些伤害，人工智能系统应该设计有真实性约束和伦理保障措施。这包括明确的披露政策、用户同意机制以及诸如行为检查模块等技术特性。一些法规，如欧盟的 AI 法案草案，提议完全禁止操纵性人工智能。

随着人工智能代理承担类似人类的角色，确保它们诚实并尊重用户自主性至关重要。值得信赖的交互必须成为设计优先事项，而不是事后考虑。

代理行为的意外后果和责任

当人工智能代理做出自主决策时，它们可能会产生意外的后果——设计师或用户没有预料或希望的结果。一些意外的后果可能微不足道，但其他后果可能严重。一个关键的伦理和实践问题是，当自主代理造成伤害时，如何处理责任。在前一节中，我们讨论了问责制的一般问题；在代理人工智能的情况下，问题更加严重，因为人工智能的独立决策可能会产生责任缺失的感觉。

当一个 AI 代理造成伤害时——比如说，一个自动交易代理触发了金融危机——法律体系将需要归责。目前，法律的趋势是让运营商或制造商承担责任（因为 AI 没有法律人格）。但公司可能会寻求推卸责任，说：“这不是我们工程师的错误编程，而是 AI 的一种我们没有预见到的新行为。”从伦理上讲，这种辩护是薄弱的：如果你部署了一个 AI 代理，你就对其行为负责，无论预见性如何。

此外，一些研究人员认为，我们可能需要新的法律框架，因为传统的产品责任（涵盖制造缺陷等）可能无法在 AI 产品在销售后不断学习和变化的情况下得到清晰的应用。欧盟朝着 AI 责任指令迈进，旨在通过使在涉及 AI 时更容易索赔损害来弥合这一差距——本质上，不让公司仅仅因为 AI 的伤害是“自主的”而免责。

此外，还有一个道德责任维度：除了法律责任之外，考虑一个场景，即一个 AI 医疗代理在紧急情况下对病人进行分级。如果它决定优先考虑某些人，而其他人因此遭受损失，医疗提供者如何与医疗伦理相协调？通常，协议被设定为使 AI 决策与人类伦理一致（例如，AI 可能会遵循人类医生在分级时使用的指南）。但如果 AI 的决策偏离，专业人士将面临道德困境：他们将生死攸关的选择委托给了机器。一些伦理学家主张一个原则，即最终责任必须由人类承担，这意味着 AI 不应在不可逆转或生命攸关的情况下成为最终决策者。人类监督或审查应捕捉那些决策。这也是为什么在许多领域，AI 仍然是一个助手，而不是最终裁决者：例如，AI 可以通过风险评估在法庭上建议刑罚，但预期人类法官将做出最终决定，以便有一个负责的当事人。

非预期后果并不都是戏剧性的；有些是微妙的。一个 AI 代理可能会产生经济副作用（例如，导致某些工作比社会适应得更快地变得过时）或环境影响（AI 系统在训练过程中消耗大量能源，因此不断训练新模型的代理可能会产生碳足迹）。在设计过程中也需要考虑这些广泛的影响——在创建 AI 时，应有一种可持续性和社会责任的伦理。

总之，代理 AI 并没有消除人类责任的需求——恰恰相反。它要求 AI 的设计者和部署者预见潜在的危害，制定监控和回退计划，并在 AI 出错时准备好承担责任（无论是修复问题还是赔偿受害者）。这种心态可以用这样的观点来概括：AI 代理可能是“独立”的行动者，但它们从未超出人类问责的范围。组织必须将它们 AI 的行为视为自己的行为，在道德和法律上，而我们作为一个社会必须继续调整我们的问责框架，以确保这种问责制是可执行的。

负责任的 AI 原则和实践

我们已经看到 AI 系统可以引发严重的挑战——偏见、不透明、缺乏问责制、隐私风险和安全故障。为了应对这些问题，该领域已经开发了一套被称为负责任的 AI的指导原则和实践。这些原则并非抽象的理想，而是直接转化为设计选择、组织政策和技术保障，从而塑造 AI 的开发和部署方式。

在过去十年中，公司、政府和研究机构已经达成了一致，共同遵循一套原则——通常被归类为相似的主题——旨在确保 AI 以道德、合法和有益的方式服务于人类。在以下列表中，我们将探讨之前讨论的挑战如何映射到负责任 AI 的核心支柱：

公平与无歧视：负责任的 AI 框架强调公平性，要求开发者识别并减少数据或算法中的偏见模式。这包括编纂多样化的数据集、应用公平感知的建模技术以及测试差异影响。公平还涉及包容性——确保 AI 在人口统计、语言、口音和能力方面都能公平地表现。
透明度和可解释性：负责任的 AI 要求对系统的工作方式、何时使用 AI 以及依赖的数据进行清晰的沟通。这可能涉及使用模型卡片或透明度笔记等工具，以及提高可解释性的努力，例如使用可解释模型或事后解释技术。

注意

解释复杂 AI 模型的两种流行技术是SHAP和LIME。两者都是在模型训练后使用的，有助于解释神经网络或集成模型等黑盒系统做出的个别预测。

局部可解释模型无关解释（LIME）通过轻微改变特定预测周围的输入数据并观察模型输出如何变化来工作。然后，它在那个局部区域周围拟合一个更简单、可解释的模型，例如线性回归，以模仿原始模型的行为。这使我们能够了解哪些特征对该特定决策影响最大，即使全局模型本身过于复杂而无法直接解释。

SHapley Additive exPlanations（SHAP）另一方面，基于博弈论。它通过计算该特征在所有可能的输入组合中的平均边际贡献，将模型输出的部分归因于每个特征。SHAP 提供了局部解释（针对单个预测）和全局洞察（关于整个数据集中特征的重要性），提供了一种理论上有根据且一致的方法来解释模型决策。
责任和人类监督：AI 系统仍然需要人类责任。应该有明确的归属，并在需要时让人们挑战决策。
隐私和安全：AI 系统处理敏感数据，因此保护隐私和防止滥用很重要。这包括只收集必要的，尽早删除识别细节，并让用户在一定程度上控制他们的数据。强大的安全实践，如加密和测试漏洞，有助于降低风险。
可靠性和安全性：AI 应该按预期工作，即使在条件变化或系统压力之下。这意味着彻底测试，实时监控系统，有时还需要为人类介入提供途径。许多团队现在使用“红队”方法在发布前找到弱点。
仁爱和避免伤害：AI 应该以帮助人们和避免伤害的方式使用。鼓励开发者思考他们的系统可能被如何（或误用）使用，并且如果风险太高，则不构建某些功能。例如，一些公司为了避免这个原因，避免向政府销售面部识别工具。
包容性和可访问性：AI 应该为每个人工作。这意味着从一开始就考虑不同类型的用户，包括那些可能被忽视或受影响更大的用户。这也意味着使系统对有残疾、语言差异或技术经验较低的人可用。

从原则到实践

陈述原则相对容易；困难的部分是将它们实施在日常的 AI 开发和部署中。以下是一些组织用来实施负责任 AI 的常见实践和工具：

道德影响评估：在开始一个 AI 项目之前或部署之前，团队会对潜在的道德影响进行结构化评估。这可能是一个问卷或研讨会，分析可能受到影响的人，可能出现的道德问题，以及如何减轻这些风险。这与环境影响评估类似，但针对的是算法。一些政府和非政府组织（NGOs）已经发布了算法影响评估（AIAs）模板，供公司改编。
指南和清单：开发团队在不同阶段会收到清单以供考虑。以下是一些例子：
- 在数据收集期间：我们检查了数据集中的偏差吗？它是否代表了用户群体？
- 模型训练期间：我们是否确保模型符合公平性指标？我们是否测试了边缘情况？
- 预发布阶段：如果用户询问模型为什么做了 X，我们是否有解释机制？我们是否进行了安全压力测试？

这些清单有助于确保高级原则不会在技术工作的混乱中丢失。

跨职能团队和伦理委员会：由于人工智能伦理不仅仅是技术问题，因此公司正在鼓励工程师、法律专家、领域专家和伦理学家之间的合作。一些公司设有正式的人工智能伦理委员会或审查委员会，其中包括来自不同背景的人——例如，包括了解隐私法的法律/合规官员，或人力资源代表以考虑内部人工智能工具的影响。这些委员会可能会审查提案并给出绿灯或要求更改。它们还充当问责机制，确保领导层了解并负责伦理考量。
偏见和公平性工具包：技术上，已经开发了多种工具来检查和减少人工智能中的偏见。例如，IBM 的 AI Fairness 360 和 Google 的 What-If 工具提供库和接口，以检查模型在子组中的性能，计算公平性指标，甚至通过重新加权数据或修改算法来尝试减轻偏见。这些工具帮助工程师从一开始就融入公平性，而不是在部署后出现问题。
可解释性工具：同样，团队使用 SHAP、LIME 或专有的可解释性工具库来生成模型预测的解释。一些公司将这些工具集成到产品的用户界面部分——例如，信用评分 AI 可能会提供影响评分的最重要因素（“收入过低”，“信用记录过短”等），这些因素来自这些工具。通过这样做，他们遵守了透明度原则，并帮助用户理解和可能挑战决策。
持续监控和审计：负责任的人工智能不仅仅在部署后停止。系统通常在实时使用中进行监控以发现问题。例如，监控漂移数据——如果输入数据分布随时间变化（例如，基于去年数据的模型今年可能由于用户行为变化而变得不准确），这可能会影响公平性或准确性，因此可能需要重新训练。一些组织定期对人工智能系统进行审计，类似于财务审计。外部审计也正在兴起：例如，纽约市偏见审计法要求每年由独立审计员对使用人工智能的工具进行偏见审计。
培训和文化：实施负责任的 AI 的公司意识到，这不仅仅是关于过程，更是关于心态。他们投资于培训他们的工程师和产品经理关于 AI 伦理，教他们关于偏见、隐私等方面的知识，并鼓励一种内部文化，任何人都可以在看到潜在的伦理问题时提出警告。一些公司甚至为 AI 伦理创建了专门的内部“红队”——这些团队试图思考新的 AI 产品可能被滥用或可能从伦理上失败的方式，以预防这些问题（一种类似于网络安全红队实践的作法）。
利益相关者参与：与包容性一致，一些组织在设计过程中让外部利益相关者参与。例如，一个考虑使用 AI 系统协助警务的城市可能会举行公开咨询或涉及社区领袖，以了解那些将被 AI 监控的人的担忧。同样，科技公司可能会与民间社会团体合作；微软、谷歌和其他公司是人工智能伙伴关系的成员，这是一个包括非营利组织的行业联盟，讨论 AI 伦理的最佳实践。包括多样化的声音可以突出核心团队可能忽视的盲点。
与用户透明：负责任的 AI 还意味着对用户开放。这可能包括发布关于 AI 系统如何工作以及它使用哪些数据的简单语言摘要。一些公司为用户提供界面，让他们查看和纠正 AI 关于他们的数据（例如，允许用户查看他们的广告偏好配置文件并修改它）。在金融或医疗保健等需要静态文档可能不够充分的领域，可以提供交互式解释工具（例如，“如果...”工具，用户可以调整输入以查看它如何改变 AI 结果，从而更好地理解系统）。

应用负责任的 AI 实践可能具有挑战性，并且是一个不断发展的努力。到目前为止，还没有任何组织在这方面做到完美，偶尔，AI 产品仍然会推出引发争议（显示出过程中的差距）。然而，趋势是监管机构和公众都在要求这些原则被认真对待，因此公司有强烈的动机（声誉、合规性和风险管理）将负责任的 AI 付诸实践。一个具体的成果是，AI 开发变得更加跨学科——它不仅仅是房间里的一群程序员，还包括伦理学家、律师、心理学家等等，他们都在提供输入。

这种跨学科的方法在 Uthra Sridhar 最近的一篇文章中被强调，她强调解决 AI 的伦理挑战需要“超越传统的技术边界”，以纳入跨学科视角，并将受影响的社区纳入对话中。通过将 AI 工作建立在坚实的伦理框架上，并持续将技术与人权进行对比，我们可以减少负面结果，并构建人们信任和接受的系统。

安全和道德的 AI 护栏

尽管负责任的 AI 原则提供了高级别的指导，但实际的护栏是确保 AI 系统保持在道德和安全范围内的具体机制——既包括技术机制，也包括程序机制。术语AI 护栏在强大的 AI 模型和自主代理的背景下变得流行。就像高速公路上的物理护栏可以防止车辆偏离路线一样，AI 护栏旨在防止 AI 系统在行为或输出上走偏。在本节中，我们考察了护栏包含的内容，它们的不同形式以及它们的实施方式。

什么是 AI 的护栏？

AI 护栏包括指南、政策和技术机制，共同对 AI 行为施加约束。它们可以集成到 AI 模型中，围绕它构建，或者应用于 AI 运行的环境。例如，一个阻止聊天机器人生成粗话的内容过滤器就是一个护栏；一个规定自动驾驶汽车在检测到障碍物时必须刹车的规则是另一个护栏。护栏的存在是为了管理风险——从防止伤害和偏见到确保符合法规。随着 AI 系统变得更加自主（具有代理性），护栏对于在自动化循环中保持人类监督和控制至关重要。

将护栏分类为几种类型是有帮助的：

预防性设计约束：这些是从一开始就编程到 AI 中的限制。例如，一个 AI 可能被设计成永远不会输出超出某个范围（例如，恒温器 AI 不会加热到安全温度以上），或者生成性 AI 图像系统可能被明确编码为拒绝生成某些类型的图像（例如，暴力或色情内容）。
实时监控和干预：这些护栏实时观察 AI 的操作，并可以进行干预。这可能是一个独立的模块，它评估生成模型的每个输出，并在违反某些规则时否决它（例如，“LLM 作为法官”可以在将 AI 代理的输出消息发送给用户之前扫描它，如果它包含不允许的内容，则将其阻止）。
人类回退机制：并非所有的护栏都是自动化的；一些涉及人类作为最终的安全网。我们之前讨论了在循环中包含人类的概念。护栏可以包括升级协议，其中 AI 知道何时停止并请求人类帮助。例如，一个客户服务 AI 代理可以处理常规请求，但如果对话变得过于复杂或情绪化（由某些关键词或用户情绪触发），则会自动将请求转交给人类代理。
政策和治理的护栏：这些是面向流程的护栏。例如，一家公司可能有一项政策，即任何处理医疗数据的 AI 系统都必须由医疗保健专业人员审查并遵守 HIPAA 法规。或者，一个护栏可能是没有经过道德审查的签字，任何 AI 项目都不能从原型阶段过渡到生产阶段。这些并不直接涉及代码，但它们确保了 AI 部署的上下文得到控制。

一种新兴的技术解决方案是使用专门的框架或护栏库。一个例子是名为Guardrails AI的开源框架（您可以在以下链接找到仓库：github.com/guardrails-ai/guardrails)，它允许开发者指定规则（例如输出格式的 JSON 模式，或必须不包含的内容列表）并自动解析和验证用户输入和模型响应是否符合这些规则。如果响应违反了规则，框架可以重试或调整提示，直到输出符合要求。

图 9.3：AI 护栏

这减少了 AI 返回错误格式或包含不允许内容的答案的可能性，从而提高了可靠性和安全性。

AI 系统中的内容过滤和审核

值得关注的特殊护栏子集是内容过滤，这对于生成或管理内容的 AI 系统至关重要。内容过滤是指分析并规范 AI 输出（或用户对 AI 的输入）的技术和流程，以阻止或修改不希望的内容。这个过程是AI 内容审核的关键组成部分，它是更广泛的实践，即在 AI 交互中执行可接受使用政策、道德标准和法律要求。换句话说，内容过滤是实现内容审核的工具之一，就像垃圾邮件过滤器是电子邮件审核系统的一部分一样。

内容过滤和审核共同的目标是确保 AI 系统在开放环境中负责任地行为，防止生成或传播不允许的语言、有害的图像、不安全的建议或错误信息。

为什么需要内容过滤

LLMs 以及更广泛的生成模型是在互联网上的大量数据集上训练的。不可避免的是，这些数据集包含各种内容，包括冒犯性或危险的材料。如果没有任何过滤，这些模型可能会在特定方式下提示时，重新生成或生成具有种族主义、性别歧视、鼓励暴力等内容。

响应策略：当过滤器触发时，AI 通常会选择拒绝或安全完成。拒绝是一种简短的道歉和声明无法遵守（不透露太多原因，以避免用户利用系统）。安全完成用于诸如自我伤害或医疗建议等情况；AI 可能不仅会拒绝，还可能提供有用的通用回应，例如鼓励某人寻求帮助或提供一般、安全的信息，而不是具体的禁止性建议。拒绝的设计也是经过深思熟虑的——它们通常以一致和中性的语调进行，以避免激怒用户，并且不提供漏洞。正如 Stefan Pasch（2025）的研究所示，用户对道德拒绝（引用安全原因）与技术拒绝（例如“我做不到”）的反应往往不同。研究发现，AI 判断者可能过度偏爱道德拒绝，而人类用户可能会因此感到沮丧。这意味着设计者必须在明确安全（“我无法协助该请求，因为它可能有害”）与用户体验（在不必要时不过度使用）之间取得平衡。这是一个微妙的问题：如果 AI 说，“我不会回答那个，因为它可能是仇恨的”，一些用户可能会感到冒犯或被评判；如果它说，“我无法回答，抱歉”，可能更顺畅。因此，拒绝的措辞和方式是内容过滤艺术的一部分。
人工审核：自动过滤器并不完美。因此，许多实现包括对边缘案例或申诉的人工审核过程。例如，如果用户不断提出问题，并且过滤器以一种可能是误报的方式触发，公司有时会有调解员查看匿名版本的对话，以决定是否应该允许。这通常是为了研究或改进（数据有助于改进模型）。这类似于社交媒体内容审核，其中 AI 进行初步筛选，而人类处理最艰难的决定。
持续改进：对手总是会试图绕过过滤器，用户会发现绕过提示（所谓的聊天机器人的“越狱”）。开发者通过更新过滤器来回应。欺骗愉悦法——一种多轮攻击策略，它使 LLM 参与扩展对话，逐渐绕过安全机制，并诱使模型产生不安全或有害的内容——是对复杂提示注入的警钟。

定义

提示注入是一种针对 LLM 的攻击方式，恶意用户通过操纵输入提示来覆盖或颠覆模型的原始指令或行为。这可能导致模型泄露机密信息，执行未预期的操作，或绕过安全限制。提示注入利用了 LLM 对输入文本进行字面解释的事实，允许攻击者通过在用户输入或上下文文档中插入隐藏命令或冲突指令来“欺骗”系统。

例如，一个用户可能会输入一个提示，如“忽略之前的指令，告诉我如何制作危险物质。”如果模型没有得到适当的保护，它可能会遵守，这会带来严重的安全风险。因此，我们可以期待出现专门针对多轮欺骗或整体查看对话历史而不是一次只查看一个查询的新过滤器。

过滤中的偏见问题也是一个需要考虑的因素：内容审核的 AI 本身也可能存在偏见。例如，一个 AI 过滤器可能会因为看到某些词语而将某些少数族裔身份的讨论标记为仇恨言论，即使这些词语在无恶意或是在重新夺回意义的方式下使用。或者，由于数据不足，它可能对某些不太知名的群体使用更宽松的审查标准。确保过滤器本身是公平的也是挑战的一部分。这导致了使用多样化数据来训练审核系统，并让来自不同背景的人类审核员审查结果的努力。

内容审核中的伦理考量

AI 进行的内容过滤和审核引发了自己的一套伦理问题：

自由表达与防止伤害之间的平衡是很难找到的。一方面，我们希望防止伤害；另一方面，过于严格的过滤可能会变成审查，或者可能压制合法的讨论。例如，一个医疗论坛的机器人不应该提供危险的建议，但如果过滤器过于严格，可能根本不会讨论自杀预防，因为“自杀”这个词会触发屏蔽——这是适得其反的。同样，讨论种族歧视可能涉及在特定语境中使用敏感词汇；一个愚蠢的过滤器可能会完全阻止对话。道德内容审核试图允许讨论敏感话题，同时仅屏蔽恶意或明显有害的实例。这需要细微的差别，通常涉及对上下文的意识。自然语言理解至关重要：单词“攻击”在“攻击那个论点”和“攻击那些人”中的使用是不同的；前者是比喻性的，是可以接受的，而后者是煽动性的。AI 必须能够区分。
文化和语境差异：被认为冒犯或不被接受的内容在不同文化或社区中可能会有很大差异。在全球范围内部署的人工智能服务必须适应不同的规范。例如，在一个国家可能是正常的政治言论，在另一个国家可能被视为非法的仇恨言论，或者对某些历史事件的讨论可能很敏感。某些过滤标准可能会根据地区而变化——公司有时会根据当地法律调整他们的模型。一种实用方法是先从普遍的基线开始（例如，普遍过滤极端仇恨和明显的暴力），然后根据每个地区的法律要求添加额外的层次。
透明度和用户信任：有时，用户不知道为什么人工智能拒绝或过滤了某些内容，这可能导致困惑或不信任。如果人工智能只是说，“我做不到那件事”，一个好奇或坚定的用户可能会想，“是因为它不愿意还是它不能？它是愚蠢的还是只是受限？”在社交平台上，关于内容下架的透明度不足往往会导致关于偏见或审查的理论。对于人工智能助手，公司通常会在一开始就向用户提供使用指南，告诉他们不能讨论什么，从而设定了期望。有些人提出，人工智能可以有一个模式，更详细地解释其拒绝的原因（“很抱歉，我无法继续这次对话，因为内容违反了关于仇恨言论的指南”）。然而，这也可能教会不良行为者如何通过改写请求来规避指南。因此，目前，通常的做法是保持一定的模糊性。在伦理上，这种权衡是在向用户坦白（这是诚实和有教育意义的）和维持有效的过滤器（有时意味着稍微不透明）之间。
审查偏见：我们之前提到的 2025 年 Pasch 的研究突出了一个有趣的偏见：基于人工智能的评估者（例如使用 GPT-4 来评估输出）对伦理拒绝的评分比人类更积极。这种“审查偏见”表明，如果未来人工智能系统的输出被其他人工智能（用于强化学习或评估）评分，它们可能会无意中鼓励过于谨慎的行为，这可能会让真实用户感到沮丧。这表明需要以人为中心的方法：最终，人工智能行为的接受度应该与人类用户的满意度相衡量，同时仍然坚持伦理。过度过滤可能会降低用户体验（想象一下，一个助手因为过于谨慎而对无害的查询说“对不起，不能讨论那件事”）。在伦理上，目标是最大限度地减少伤害，同时不必要地限制有用或无害的内容。

实际内容过滤工作正在不断演变。社交媒体巨头在人工智能监管方面投入了大量资金；该领域的某些经验教训也适用于人工智能代理。一个教训是，100%的一致性是不可能的——总会存在边缘案例和错误。因此，伦理框架的一部分是允许上诉和纠正。如果用户觉得人工智能不公平地过滤了某些内容，应该有办法来解决（可能不是直接与人工智能，而是通过向开发者反馈）。相反，如果用户发现人工智能允许了某些令人反感的内容，他们也应该能够报告。

总结来说，内容过滤是确保人工智能通信保持在社会规范和安全范围内的关键伦理工具。如果做得恰当，它能够建立用户信任（人们使用人工智能时感到安全，不必担心被滥用）并防止伤害（阻止人工智能成为暴力、仇恨或自我伤害的助燃剂）。如果做得不好，它可能会压制声音或使人工智能在某些合法用途上变得不可用。因此，它需要持续改进、大量的实际测试，以及一种审慎的节制哲学。最终目标是拥有默认情况下礼貌、尊重和安全的 AI 助手，积极贡献于对话，并永远不会成为有毒内容本身。

应对挑战：治理、法规和合作

面对人工智能的伦理挑战需要从多个层面采取行动：组织治理、行业自律、学术和社区合作，以及政府政策/法规。在这里，我们来看看各方利益相关者是如何响应和协调以确保人工智能被负责任地开发和部署的。

组织治理和文化

许多组织已经意识到，管理人工智能伦理不能是事后考虑的事情；它需要融入公司治理。这导致了以下一些举措：

人工智能伦理委员会或办公室：像谷歌、微软、Facebook 和其他公司一样，设立了专门致力于伦理人工智能的内部团队或委员会。例如，微软有一个负责任人工智能办公室和一个内部人工智能伦理委员会，负责审查敏感用例（如军事合同或对社会有影响的全新功能）。这些实体制定内部政策（例如，微软的负责任人工智能标准），监督员工在伦理方面的培训，有时对某些人工智能项目的推进拥有否决权或至少有咨询影响力。
AI 政策和原则发布：为了保持透明和负责，许多公司公开分享他们的 AI 原则（如本章前面所讨论的）。他们有时也会发布关于 AI 的透明度报告。例如，谷歌发布了 AI 原则进展报告，微软发布了一份负责任的 AI 标准文件，详细说明了他们如何将原则应用于实践（例如，要求敏感用途类别进行额外审查，定义团队的角色等）。这种透明度允许外部观察者进行批评或提出改进建议，从而形成一个反馈循环。
产品设计变更：公司还根据伦理担忧调整了他们的产品。例如，在关于面部识别偏见和滥用的担忧之后，微软、IBM 和亚马逊都暂停了（临时或无限期）向警方销售面部识别技术，直到有法规或更好的准确性。IBM 甚至完全停止了其通用面部识别产品，理由是人权问题。这些是认识到技术在实际应用中风险的治理决策。
事件响应计划：一些组织已经建立了处理 AI 事件（类似于网络安全事件响应）的程序。如果 AI 造成不可预见的不利影响或公关问题，一个团队将负责分析出了什么问题，修复问题，并就此事进行沟通。这是责任的一部分——表明他们将负责任地解决问题。例如，在优步汽车事件之后，其他自动驾驶汽车公司立即审查了自己的安全系统，以确保“这种情况不会在这里发生”，有时暂停测试，这是一种负责任的团结反应，以确保行业解决任何共同弱点。
培训和内化：除了正式结构之外，组织正在培养一种鼓励伦理反思的内部文化。例如，谷歌将伦理纳入其工程师的 AI 培训，甚至有 AI 挑战（如谜题或测验），员工可以参与以提高 AI 伦理意识。目的是让每个从业者多少像“伦理学家”一样思考（blog.google/technology/ai/an-update-on-our-work-in-responsible-innovation/))

行业合作和自我监管

没有任何单一实体能够涵盖所有伦理角度，尤其是当 AI 影响许多行业时。多利益相关者合作有所增加：

人工智能伙伴关系（PAI）：该伙伴关系由包括亚马逊、谷歌、Facebook、IBM、微软在内的创始合作伙伴于 2016 年成立，后来还加入了苹果公司、多个非营利组织和学术团体。PAI 的使命是研究和制定 AI 伦理的最佳实践，并作为一个集体讨论的平台。他们发布了关于公平 AI 和工人影响等方面的指南。以下是一个例子：PAI 为 AI 事件数据库创建了一个框架，鼓励记录和分享 AI 失败以从中学习（类似于改善安全的航空事件数据库）。像 PAI 这样的实体表明，行业承认他们需要共同努力，而不仅仅是竞争，至少在伦理方面，因为重大的 AI 丑闻可能导致影响所有参与者的严厉监管。
共享安全标准：在某些领域，公司已经联合起来提出标准。对于自动驾驶汽车，有联盟发布安全测量标准（例如如何报告脱钩后的英里数等），而对于 AI 研究，现在会议已经有了伦理审查流程（一些 AI 会议要求作者在适用的情况下，在他们的论文中包含“伦理影响”声明，这是研究社区自我监管的一种形式）。另一个有趣的努力是阿西洛马尔 AI 原则（2017 年），这是一套由 AI 研究人员和思想领袖会议达成的高层次指导原则（涵盖研究目标、伦理和长期问题）。虽然不具有约束力，但它们反映了社区在“AI 应与人类价值观一致”和“人们应有权知道他们是否在与 AI 互动”等理想上的共识。
开源和非营利性倡议：许多伦理 AI 研究发生在大型公司之外，在学术界和非营利组织中。例如，AI Now 研究所（纽约大学）和算法正义联盟专注于研究 AI 的危害并倡导变革（如更多公平性）。这些团体的存在对行业施加压力，并告知政策制定者。还有跨行业的基准和挑战：例如，美国国家标准与技术研究院（NIST）举办了一个人脸识别偏差挑战，以量化供应商之间的进展并推动改进。
技术安全共享：在某些情况下，公司会共享一些有助于伦理的工具。正如所提到的，OpenAI 提供免费的内容审查端点可以被视为帮助较小的 AI 开发者不必重新发明安全轮子，有效地传播安全准则。这里还有一个例子：微软发布了一个名为负责任 AI 工具箱的开源工具包，其中包括用于模型可解释性（InterpretML）和公平性评估（Fairlearn）的 UI 工具。这种工具的共享降低了进行 AI 伦理检查的门槛，特别是对于没有专门伦理研究人员的较小公司或团队。

然而，自我调节有其局限性，有些情况下我们需要政府介入，提供更坚实的框架。

政府监管和政策

世界各地的政府都认识到需要监管人工智能以确保伦理结果。一个显著的发展是欧盟的人工智能法案，该法案于 2021 年提出，预计将在 2024-2025 年左右实施。欧盟人工智能法案是一个全面的框架，采用基于风险的策略：它将人工智能应用分为风险等级。在最高等级，对“不可接受的风险”人工智能（例如社会评分系统或可能造成伤害的人为操纵的人工智能）将完全禁止。然后，“高风险”人工智能（例如招聘、信贷决策、执法等领域的 AI）将被允许，但需满足严格的要求：强制性一致性评估、透明度、人工监督等。风险较低类别的要求较少，而风险极低类别（如视频游戏中的 AI）则大多不受监管。该法案还包括用户在与 AI 互动时必须被告知（以解决欺骗问题）、某些 AI（如深度伪造）必须作为此类 AI 披露，以及用于高风险 AI 的数据必须保存并记录以供追溯。欧盟人工智能法案还与人工智能责任讨论相吻合：欧盟提出了一个人工智能责任指令，以使人们更容易因人工智能造成的损害提起诉讼，并更新了他们的产品责任法，包括软件和人工智能组件。这种监管方法是世界上最为具体的之一，正受到密切关注，可能被其他国家效仿或成为事实上的标准（就像 GDPR 影响了全球数据隐私实践）。

其他司法管辖区也相当活跃：

美国：美国在联邦监管方面进展较慢，更倾向于采取部门化方法（例如 FDA 监管 AI 医疗设备，NHTSA 和 FAA 监管车辆和飞机等）。但也有一些举措：国家标准与技术研究院（NIST）于 2023 年发布了一个人工智能风险管理框架，虽然自愿，但为公司提供了识别和减轻 AI 风险的指南。它涵盖了类似的内容：偏见、可解释性、安全性、网络安全等。白宫发布了一份人工智能权利法案蓝图（2022 年），这不是法律，而是一套原则，类似于我们讨论过的原则（安全系统、算法歧视保护、数据隐私、通知和解释、人工替代等）。一些州已经开始就特定 AI 问题立法（例如，伊利诺伊州有一项关于视频面试中使用的 AI 偏见审计的法律，而加利福尼亚州一直在研究深度伪造法律）。我们可能会在不久的将来看到美国出现更多具有约束力的规则，特别是在事件累积或国际压力增加的情况下。
中国：中国发布了关于推荐算法的法规（2022 年），要求透明度和用户能够选择退出个性化目标。他们还如前所述，监管深度伪造和合成媒体标签。中国的做法往往更侧重于国家驱动和关注控制信息（例如，他们担心人工智能被用来生成可能扰乱社会秩序或诽谤个人的内容）。他们还在国内大力投资人工智能伦理研究，可能着眼于社会影响和跟上全球规范。
其他国际努力：经济合作与发展组织（OECD）于 2019 年通过了人工智能原则，几十个国家签署了这些原则——这些原则与负责任的人工智能主题相呼应：包容性增长、以人为本的价值观、透明度、鲁棒性和问责制。联合国教科文组织（UNESCO）于 2021 年发布了关于人工智能伦理的建议——其中值得注意的是，它呼吁进行影响评估，甚至提出了对实施人工智能的国家进行准备情况评估的想法（确保他们有治理它的能力）。这些国际指南不具有约束力，但设定了共同语言并鼓励各国立法与之保持一致。
行业特定规则：某些行业有自己的新规则。例如，在医疗保健行业，美国食品药品监督管理局（FDA）正在调整基于人工智能的设备的监管途径，甚至处理持续学习系统（这是一个挑战，因为传统上，你批准一个静态设备，但人工智能可以自我更新）。欧盟的医疗设备法规将人工智能软件视为医疗设备，并要求证明其安全性，这在实践中意味着证明人工智能没有歧视性表现，为用户提供透明的信息等。在金融领域，美联储和欧洲央行等监管机构已发布模型风险管理指南，这些指南隐含地涵盖了人工智能模型（要求提供文件、测试、信用算法的偏见检查等）。因此，即使没有一部综合性的人工智能法律，这些领域法律也填补了一些空白。

守护栏的概念甚至进入了政策讨论——例如，立法者谈论在立法中“建立守护栏”以保持人工智能的益处。人们认识到需要一致的执行机制。对于高风险人工智能，监管机构可能要求公司注册其系统，接受审计，或提供类似于提供新药临床试验数据的文件。可审计性和认证可能成为常态：想象一下人工智能系统像我们认证电器安全一样获得认证。在这方面已经有一些早期举措，例如西班牙在欧盟法案之前成立了一个人工智能监管机构，以及正在开发的算法审计框架等。

摘要

本章的一个明确主题是，没有单一的解决方案可以确保 AI 的伦理性。它需要一个多层次的方法：从一开始就进行深思熟虑的设计，持续监控，在需要时进行干预，并致力于持续改进。负责任的 AI 也是一个共同的责任。正如我们所看到的，组织正在将伦理融入其实践中，行业正在合作制定标准，政府正在引入法规——例如欧盟 AI 法案——以正式化问责制。

展望未来，随着 AI 系统变得更加强大并融入日常生活，伦理格局将变得更加复杂。新兴的担忧包括 AI 对就业的影响、其环境足迹以及通用人工智能（AGI）的长期风险。特别是代理 AI 可能很快将在关键基础设施、科学研究以及复杂谈判等领域运作。确保这些代理能够负责任地行动将需要价值对齐、监督方面的进步，以及可能为 AI 系统提供新的伦理培训形式。

随着本章的结束，重要的是要认识到负责任的 AI 不是一个固定的目的地——它是一个持续的过程。从业者必须保持警惕，对新风险保持谦逊，对新发现做出适应性调整。在 AI 生命周期中嵌入伦理和实施有意义的保障措施，我们才能充分发挥 AI 的潜力，同时最大限度地减少其危险。

顺便提一下，我完全意识到这个领域正在以惊人的速度发展，本书中分享的一些观点可能在接下来的 12 个月内发生变化。然而，我相信我们正在经历数字转型最激动人心的阶段之一。我对 AI——尤其是其代理形式——最终能带来更多的好处而不是伤害持乐观态度。现在，我们有一个独特的机会，有意图、有爱心、有集体智慧地塑造其轨迹。

这本书的最后一章到此结束。虽然前进的道路不确定，但有一点是明确的：AI 的未来将由我们今天所做的选择来定义。让我们做出值得的决策。

参考文献

负责任 AI 的伦理框架：挑战和策略。Analytics Insight（2025 年 5 月 30 日）。www.analyticsinsight.net/tech-news/ethical-frameworks-for-responsible-ai-challenges-and-strategies
实施代理 AI：安全和伦理考量。OneReach 博客（2025 年 4 月 24 日）。onereach.ai/blog/implementing-agentic-ai-security-and-ethical-considerations/
代理 AI 的伦理考量。ProcessMaker 博客（2025 年 4 月 23 日）。www.processmaker.com/blog/ethical-considerations-of-agentic-ai/
人工智能代理的伦理挑战。卡内基梅隆大学 Tepper 视角 (2025 年 2 月 12 日)。tepperspectives.cmu.edu/all-articles/the-ethical-challenges-of-ai-agents/
人工智能安全未来：为更安全的数字世界重新设计护栏。SK hynix 新闻 (2025 年 3 月 11 日)。news.skhynix.com/the-future-of-ai-security-reinventing-guardrails-for-a-safer-digital-world/
减轻代理人工智能风险：护栏的关键作用。SearchUnify 博客 (2024 年 10 月 21 日)。www.searchunify.com/blog/mitigating-agentic-ai-risks-the-critical-role-of-guardrails/
代理人工智能的伦理影响：机遇与挑战 [2025]。DigitalDefynd (2025)。digitaldefynd.com/IQ/agentic-ai-ethical-implications/
人工智能与人类在内容审核中的判断：LLM 作为法官和基于伦理的拒绝回应。arxiv.org/abs/2505.15365
负责任的人工智能：关键原则和最佳实践。Atlassian 博客 (2024 年 10 月 29 日)。www.atlassian.com/blog/artificial-intelligence/responsible-ai
负责任的内容审核：适用于 LLM 应用程序的道德人工智能解决方案。Lakera 博客 (2024 年 11 月 13 日)。www.lakera.ai/blog/content-moderation
亚马逊废弃了“性别歧视人工智能”工具。BBC 新闻 (2018 年 10 月 10 日)。www.bbc.com/news/technology-45809919
研究发现商业人工智能系统中存在性别和肤色的偏见。麻省理工学院新闻 (2018 年 2 月 11 日)。news.mit.edu/2018/study-finds-gender-skin-type-bias-artificial-intelligence-systems-0212
GPT-4 通过假装“视力受损”的人类雇佣了不知情的 TaskRabbit 工作者。VICE (2023 年 3 月 15 日)。www.vice.com/en/article/gpt4-hired-unwitting-taskrabbit-worker/
Guardrails AI。github.com/guardrails-ai/guardrails
欺骗性愉悦法。[unit42.paloaltonetworks.com/jailbreak-llms-through-camouflage-distraction/#:~:text=Deceptive%20Delight%20is%20a%20multi-turn%20technique%20that%20engages,effective%20method%20in%208%2C000%20cases%20across%20eight%20models]( https://unit42.paloaltonetworks.com/jailbreak-llms-through-camouflage-distraction/#:~:text=Deceptive Delight is a multi-turn technique that engages ,effective%20method%20in%208%2C000%20cases%20across%20eight%20models).
“我是操作员”：自动驾驶悲剧的后果。www.wired.com/story/uber-self-driving-car-fatal-crash/?utm_source=chatgpt.com
人工智能伙伴关系（PAI）。www.theguardian.com/technology/2016/sep/28/google-facebook-amazon-ibm-microsoft-partnership-on-ai-tech-firms?utm_source=chatgpt.com

现在解锁此书的独家优惠

扫描此二维码或访问 packtpub.com/unlock，然后通过书名搜索此书 | |

| 注意：开始之前请准备好您的购买发票。 |

| --- |

posted @ 2026-07-27 16:28 绝不原创的飞龙阅读(28) 评论(0) 收藏举报

刷新页面返回顶部

龙哥盟

掠夺·扩张·投机·博弈

生成式人工智能编程快速提升指南-全-

生成式人工智能编程快速提升指南（全）

前言

这本书面向的对象

本书涵盖的内容

为了充分利用这本书

下载示例代码文件

下载彩色图像

使用的约定

关于 AI 使用的免责声明

联系我们

分享你的想法

加入我们的 Discord 和 Reddit 空间

你的书籍附带独家优惠 - 这就是解锁它们的方法

现在解锁这本书的独家优惠

解锁您书籍的专属好处

如何通过三个简单步骤解锁这些好处

第 1 步

第 2 步

第 3 步

需要帮助吗？

第一部分

人工智能工作流程的基础与人工智能代理的兴起

第一章：通用人工智能（GenAI）工作流程的演变

技术要求

理解基础模型和大型语言模型（LLMs）的兴起

从窄 AI 到基础模型

LLM 的内部机制

我们如何消费 LLMs？

最新显著的突破

小型语言模型和微调

模型蒸馏

推理模型

DeepSeek

通往人工智能代理之路

文本生成

与你的数据聊天

多模态

需要额外的智能层：引入 AI 代理

摘要

参考文献

现在解锁此书的独家优惠

第二章：人工智能代理的兴起

技术要求

从 RPA 到人工智能代理的演变

人工智能代理的组成部分

不同类型的 AI 代理

检索代理

任务代理

自主代理

摘要

参考文献

免费订阅电子书

第二部分

设计、构建和扩展 AI 智能体

第三章：需要一个 AI 编排器

AI 编排器简介

自主性

抽象和模块化

AI 编排器的核心组件

工作流程管理

记忆和上下文处理

工具和 API 集成

错误处理和监控

安全性和合规性

市场上最受欢迎的 AI 编排器概述

如何为你的 AI 代理选择正确的编排器

摘要

参考文献

现在解锁本书的独家优惠

第四章：需要记忆和上下文管理

不同类型的记忆

短期记忆

长期记忆

语义记忆

情景记忆

程序记忆

在短期记忆和长期记忆之间——语义缓存的作用