AI-Agents-实战-一-

AI Agents 实战（一）

原文：AI Agents in Practice

译者：飞龙

协议：CC BY-NC-SA 4.0

AI Agents 实战

献给我的家人和朋友——感谢你们在这旅途中给予的支持、耐心和鼓励。

—— Valentina

贡献者

关于作者

Valentina Alto 是一位技术架构，在迪拜微软创新中心（Microsoft Innovation Hub）专注于 AI 和智能应用开发。在微软工作期间，她担任过解决方案专家等不同角色，专注于制造业、制药和零售行业的数据、AI 和应用负载，并在 AI 时代推动客户的数字化转型。Valentina 是一位活跃的技术书籍作者和演讲者，为 AI 和机器学习的书籍、文章和活动做出贡献。在过去的两年里，Valentina 已出版了关于生成式 AI 和大语言模型的两本书，进一步巩固了她在该领域的专业知识。

我要感谢我的家人和朋友，在这个过程中给予了我无私的支持、耐心和理解。你们的鼓励无价。

我非常感谢 AI 和技术社区的同事和同行，他们富有见解的讨论、反馈和灵感塑造了我对生成式 AI 的理解。你们的贡献不断推向创新的边界。

特别感谢 Ali Abidi 让我在 AI Agent 时代这样一个激动人心的时刻有机会撰写这本书。特别感谢 Prajakta Naik、Aditi Chatterjee 和 Alish Falcon 为审阅本书提供的宝贵意见和时间，感谢整个 Packt 团队在本书编写期间的支持。

关于审稿人

Amey Ramakant Mhadgut 是一位拥有五年以上行业经验的软件工程师，拥有计算机科学硕士学位。他专注于大数据、生成式 AI、Python、AWS 和可扩展软件架构。Amey 在他的评审中兼具学术深度和实践洞察，对技术内容提供了深熟虑的分析。

Prudhvi Raj Dachapally 拥有 7 年以上的行业经验，是 eBay 的高级应用科学家，在那里构建创新的 AI 解决方案以增强推荐体验。在此之前，他在 Cyndx 领导 AI 团队，开发了由微调大语言模型驱动的金融 B2B 产品语义搜索引擎和 AI 助手。他在 EMNLP 和 CogSci 等顶级会议上有 180 多篇引用和论文。他拥有印第安纳大学明尼阿波林的硕士学位，并通过导师指导和校友活动保持活跃。

我想感谢我的妻子 Sri Vyshnavi 在评审过程中的持续支持，以及我的父母 Subramramanyam 和 Sri Neela，他们的牺牲和信念是我今天所拥有每一个机会的基础。

订阅获取免费电子书

新框架、演进中的架构、研究发布、生产分解——AI_Distilled 将噪音过滤为为实际操作 LLM 和生成式 AI 系统的工程师和研究人员提供的每周简报。现在订阅即可获得一本免费电子书，以及帮助您保持专注和掌握信息的每周见解。

访问 https://packt.link/TRO5B 订阅，或扫描下方二维码。

LLM 的内部原理：6
短期记忆：66
在短期记忆和长期记忆中——语义缓存的作用：77
记忆存储、检索与刷新：81
管理记忆的流行工具：84
Mem0：86

第 9 章：应对现实 AI 中的伦理挑战 221

AI 中的伦理挑战——公平性、透明性、隐私与问责制 222

公平性与偏见：222
透明性与可解释性：223
隐私与数据保护：225
问责制与法律责任：225
安全性与可靠性：226

代理 AI 的自主性及其独特的伦理挑战 227

自主性对比人类控制：227
欺骗对比操纵：229
代理行为的意外后果与责任：229
负责任的 AI 原则与实践：231
从原则到实践：233

安全且伦理 AI 的护栏 235

什么是 AI 护栏？：235

AI 系统中的内容过滤与审核 237

为什么需要内容过滤：237
内容过滤如何工作：238
内容审核中的伦理考量：240

应对挑战：治理、监管与协作 241

组织治理与文化：242
行业协作与自律：243
政府监管与政策：244

总结 246

参考文献 247

你可能喜欢的其他书籍 250

索引 253

前言

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

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

本书是理解和构建 AI Agent 的指南，涵盖了它们的架构、关键组件和现实用例。无论你是开发者、架构师、产品经理还是 AI 爱好者，本书都为你提供了利用自主代理力量的基础知识和实践技能。

本书分为三个部分：

第一部分：AI 工作流基础与 AI Agent 的兴起，探索了生成式模型崛起以来 AI 工作流的演变，追踪了从简单 API 到更智能、自主行为的变化。介绍了 AI Agent 的概念及其要素——LLM、工具、记忆和上下文，并强调了各行业对代理系统日益增长的需求。
第二部分：设计、构建与扩展 AI Agent，深入探讨代理开发的实践。涵盖了 AI 编排工具、记忆与上下文处理、工具集成以及代理的可观测性。这部分还将指导你如何使用 LangChain 和 LangGraph 等框架构建单代理和多代理应用，并提供电子商务助手和客户支持代理等实战案例。
第3部分：通往开放、代理化的生态系统，展望了塑造智能软件未来的协议、平台和原则。它涵盖了如 MCP、A2A 和 NL-Web 等新兴开放标准，并讨论了如何构建适用于企业级部署的负责任、安全且高效益的智能体。它还将涵盖了负责任的 AI 实践，包括评估、安全机制和人类监督。

本书适用读者

本书面向想要充分释放 AI 智能体全部潜力的开发者、架构师、创新领导者和研究人员。无论你是正在构建基于智能体工作流的软件工程师，还是设计智能助手的产品经理，亦或是希望将自主决策嵌入到系统中的业务战略家，本书都提供了你所需的框架、示例和工具，帮助你开始并扩展。

本书涵盖内容

第1章“生成式 AI 工作流的演进”追溯了自 2022 年底以来 AI 工作流的转型，从简单的 API 交互到检索增强生成（RAG）。它探索了诸如微调、模型蒸馏和人类反馈强化学习（RLHF）等最新突破，并引入了对更具自主性和代理性行为的需求。

第2章“AI 智能体的崛起”定义了什么是 AI 智能体，以及它们与之前的自动化范式（如 RPA）的区别。它介绍了不同类型的智能体以及构成其架构的关键组件，包括系统消息、工具、内存和数据。

第3章“对 AI 编排器的需求”探讨了编排层在基于 LLM 的应用中新兴的角色。它比较了流行的编排器，描述了它们的组件，并为根据你的需求选择合适的编排器提供了指导。

第4章“内存与上下文管理的需求”深入探讨了智能体如何通过各种类型的内存（短期、长期、情节性、语义性）存储、检索和更新信息，还介绍了管理上下文窗口和利用向量数据库的技术。

第5章“工具与外部集成的需求”探索了智能体如何使用 API、数据库和第三方服务与世界交互。它还讨论了异步与同步调用，以及如何通过监控和日志实现可观测性。

第6章“使用 LangChain 构建你的第一个 AI 智能体”将引导你使用 LangChain 构建自己的单智能体应用，包括两个实用案例：电子商务助手和客户支持智能体。

第7章“多智能体应用”探索了多个智能体协同工作时的情况。它设计了如群聊、分层和顺序协调等模式，引入了 LangGraph 和 AutoGen 等编排器，并指导你构建第一个多智能体系统。

第8章“编排智能：下一代智能体协议蓝图”介绍了新兴的标准和协议——如 MCP、A2A、ACP 和 NL-Web——这些标准旨在为互操作智能体定义智能 Web 的下一层。

第9章“应对现实世界 AI 中的伦理挑战”强调了负责任设计智能体系统的至关重要。它涵盖了评估策略、安全过滤器、成本控制以及护栏和人类回路系统的实现，以确保自主智能体安全且符合伦理部署。

如何充分利用本书

如果你能记住以下几点，跟随学习将更加容易：

通过实践学习：许多章节包含了真实场景和实际练习。尽可能通过使用 LangChain 和 LangGraph 等框架构建自己的 AI 智能体来跟随学习，并尝试使用 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-4。

其他选项包括（但不限于）以下：

Hugging Face Hub
Anthropic
Gemini

下载示例代码文件

本书的代码包托管在 GitHub 上： https://github.com/PacktPublishing/AI-Agents-in-Practice 。我们还在丰富的图书和视频目录中提供了其他代码包，可以在 https://github.com/PacktPublishing 获取。快去看看吧！

下载彩色图片

我们提供了一个 PDF 文件，其中包含书中使用的截图/图表的彩色版本。你可以在此处下载： https://packt.link/gbp/9781805801351 。

使用规范

code：表示文本中的代码、数据库表名、文件夹名、文件名、扩展名、路径名、虚拟 URL、用户输入和 X handle。例如，“在 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_tokens": 100, "top_k": 50,
  "temperature": 0.1,
}

llm.invoke("Your query here")

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

警告或重要注释显示所示。
提示和技巧显示所示。

关于 AI 使用的免责声明

作者承认使用了尖端 AI（如 ChatGPT 和 GitHub Copilot），其唯一目的是为了提高书中的语言表达和清晰度，从而为读者提供流畅的体验。需要注意的是，内容本身由作者编写并由专业出版团队编辑。

与我们联系

我们欢迎读者的反馈！

普通反馈： 请发送邮件至 feedback@packt.com 反馈，并在邮件主题中注明书名。如果你对本书的任何方面有疑问，请发送邮件至 questions@packtpub.com。

勘误： 尽管我们已尽力确保内容的准确性，但错误在所难免。如果你在书中发现错误，我们将不胜感激你的告知。请访问 http://www.packtpub.com/submit-errata ，点击 Submit Errata 并填写表单。

盗版： 如果你在互联网上发现我们作品任何形式的非法复制版，我们将不胜感激你提供所在地地址或网站名称。请联系 copyright@packt.com 并附上材料链接。

如果你有兴趣成为作者： 如果你在某个领域有专长，并对编写或为书籍做贡献感兴趣，请访问 http://authors.packt.com/ 。

分享你的想法

在你读完《AI Agents in Practice》后，我们非常想听听你的想法！请点击此处直接进入该书的亚马逊评论页面并分享你的反馈。

你的评价对我们和技术社区至关重要，并将帮助我们确保交付高质量的内容。

接入我们的 Discord 和 Reddit 社区

你并不是唯一在应对碎片化工具、不断更新和不明确最佳实践的人。加入我们不断增长的专业人士社区，交流未记录在文档中的见解。

| 获取我们作者提供的更新、讨论和幕后见解。加入我们的 Discord 空间：https://packt.link/z8ivB 或扫描下方二维码： | 与同仁交流，分享想法并讨论现实中的生成式 AI 挑战。在 Reddit 上关注我们：https://packt.link/0rExL 或扫描下方二维码： |

| --- | --- |

您的书籍附带专属福利 —— 如何解锁它们

使用下一代阅读器获得增强阅读体验：

多设备进度同步：在任何设备上学习，进度无缝同步。
高亮显示与记笔记：将您的阅读转化为持久的知识。
书签：随时回顾您最重要的学习内容。
深色模式：通过切换到深色或深褐色模式，以最小程度的眼睛疲劳来专注于阅读。

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

总结内容：总结关键章节或整个章节。
AI 代码解释：在下一代 Packt 阅读器中，点击每个代码块上方的“解释”按钮即可获取 AI 驱动的解释。

AI 助手是下一代 Packt 阅读器的一部分，目前仍处于测试阶段。

随时随地学习：

使用无 DRM（数字版权管理）的 PDF 和 ePub 版本离线访问内容——与您喜爱的电子阅读器兼容。

解锁您的书籍专属福利

您购买的书附带以下专属福利：

下一代 Packt 阅读器
AI 助手（测试版）
无 DRM 的 PDF/ePub 下载

如果您尚未解锁，请参考以下指南进行解锁。此过程仅需几分钟，只需操作一次。

如何通过三个简单步骤解锁这些福利

第 1 步

准备好此书的发票，因为您在第 3 步中需要它。如果您收到纸质发票，请用手机扫描并准备好 PDF、JPG 或 PNG 格式。

有关查找发票的更多帮助，请访问 https://www.packtpub.com/unlock-benefits/help 。

注意：您是直接从 Packt 购买的书吗？您不需要发票。完成第 2 步后，您可以直接进入专属内容。

第 2 步

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

在打开的页面上（如果您在桌面端，界面将类似于图 0.2），按名称搜索此书。确保您选择了正确的版本。

第 3 步

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

需要帮助？

如果遇到问题并需要帮助，请访问 https://www.packtpub.com/unlock-benefits/help 了解如何查找发票及更多信息。以下二维码将直接带您进入帮助页面：

注意：如果仍面临问题，请联系 customercare@packt.com。

第 1 部分

AI 工作流的基础与 AI 智能体的崛起

在本书的第一部分中，我们探索了自 2022 年底大语言模型（LLMs）兴起以来 AI 开发的演变，导致了 AI 智能体（AI agents）作为一种新架构范式的出现。

这一部分首先追溯了 AI 工作流是如何转变的——从简单的 API 调用到更动态的系统（如检索增强生成 RAG），并突出了技术突破，如微调、模型蒸馏和基于人类反馈的强化学习（RLHF）。它引入了“智能体行为”（agentic behavior）的概念，将其作为构建智能、目标驱动系统的下一个前沿。

随后，我们深入探讨了什么是 AI 智能体：它与传统自动化有什么不同、实现它的组件（LLMs、工具、内存和知识），以及为什么该领域正迅速向更自主、交互的系统收敛。

您将理解 AI 智能体如何在 LLM 的基础上构建，同时引入新的智能和编排层，为更个性化、持久且面向任务的 AI 应用奠定基础。

此部分包含以下章节：

第 1 章：生成式 AI 工作流的演变
第 2 章：AI 智能体的崛起

1 生成式 AI 工作流的演变

在过去的两年里，大语言模型（LLMs）重塑了 AI 的格局。从简单的基于提示的交互到跨越多个行业的复杂应用，LLMs 在架构、训练技术和微调策略突破的推动下演进得非常快。随着其能力的演进，截至 2025 年 4 月，从 ChatGPT 到如今智能体系统的转变标志着一种自然的演进，其中推理、规划和执行能力的加入代表了重大的技术飞跃。

本章将探讨 LLM 的基础、它们如何被构建和使用，以及预训练模型与微调模型之间的区别。重要的是，它为下一次飞跃——AI 智能体的出现铺平了道路。

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

理解基础模型和 LLMs 的崛起
最新的重大突破
通往 AI 智能体的之路
额外智能层的必要性：引入 AI 智能体

通过本章的学习，您将清晰地理解 LLM 是如何演变的、如何被训练和部署，以及为什么通往真正智能系统的道路不可避免地指向 AI 智能体的。

技术要求

您可以在书籍配套的 GitHub 仓库中访问本章的完整代码，地址为 https://github.com/PacktPublishing/AI-Agents-in-Practice。

理解基础模型和 LLMs 的崛起

由于基础模型的出现，AI 经历了根本性的转变——基础模型是多功能、通用的模型，可以适应广泛的任务。其中，LLMs 占据了中心位置，通过自然语言重新定义了我们与机器的交互作用方式。

从狭义 AI 到基础模型

在基础模型兴起之前，AI 领域由狭义 AI 主导——即为了执行某一个特定任务而不做其他任何事情的系统。每个用例都需要自定义的流水线：专门的模型架构和专门的训练程序。如果你想将电子邮件分类为垃圾邮件或非垃圾邮件，你需要构建一个过滤器。如果你需要从文档中提取名称和地点，你需要创建一个实体识别器。总结新闻文章？那意味着另一个定制化模型。

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

基础模型的引入标志着我们构建和思考 AI 系统方式的根本性转变。这些模型在跨越多个领域和任务的海量且多样化的数据集上进行训练。其核心思想在大规模预训练阶段教导一个模型对世界产生通用的理解——其语言、结构和模式。一旦嵌入了这些通用知识，模型就可以以极少的额外数据和计算来适应特定任务。

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

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

此外，基础模型不仅限于语言。它们跨越模态：某些模型不仅可以处理和生成文本，还可以处理图像、音频或代码。

本质上，基础模型充当了 AI 的“基础大脑”——训练一次，多次复用。这种可扩展性和适应性开启了我们构建智能系统的全新可能性，为更自主和交互的应用程序（如 AI 智能体）奠定了基础。

现在，我们提到基础模型能够处理各种数据格式。在基础模型的集群中，我们可以找到只关注一种数据类型的特定数据模型，LLM 就是如此。

https://github.com/OpenDocCN/freelearn-dl-zh/tree/master/docs/ai-agents-in-practice/img/7c0fff452a128c12d9cc1b782f267ef2_27_0.png

图 1.1：LLM 的特征

LLM 本质上是基础模型的语言专门化版本。它们构建在深度神经网络架构（特别是 Transformer）之上，并经过训练以预测序列中的下一个词。但这个看似简单的目标解锁了令人惊叹的涌现行为。LLM 可以进行对话、回答复杂问题、编写代码，甚至模拟推理。

定义

涌现行为（Emergent behaviors）是指系统在达到特定规模时意外展现的复杂能力，尽管这些能力并非通过显式编程或预设。在大型语言模型（LLMs）的语境下，当模型在数据、参数和训练时间上进行扩展时，这些行为就会出现——从而解锁了较小版本中不具备的新能力。

随着模型规模的扩大，它们开始表现出涌现属性，包括以下：

上下文学习 (In-context learning)：LLM 仅通过在提示中提供几个示例即可学习执行任务，而无需任何微调。这在较小的模型中是不可见的。
思维链推理 (Chain-of-thought reasoning)：通过生成中间推理步骤，LLM 可以解决数学应用题或逻辑谜题等多步问题——这些是它们以前所苦恼的。
类比推理 (Analogical reasoning)：它们能够以人类认知处理的方式解决类比问题（例如，“猫之于小猫，狗之于……”）。
算术与逻辑：在大规模下，LLM 发展出了处理多位数算术或逻辑谜题等任务的能力，即使这些任务并非它们训练目标的一部分。
理解比喻和幽默：先进的 LLM 可以解释比喻甚至尝试开笑话——展现出对语言细微差别的抽象理解。
多任务泛化 (Multi-task generalization)：它们不是针对某个特定任务进行训练的，而是同时处理翻译、摘要、问答等——而无需特定任务的训练。

这些能力代表的不仅仅是性能的提升——它们是质上的新行为，只有在大规模下才会“涌现”，赋予了 LLM 令人惊讶的广泛技能，并对各个领域产生现实世界的影响。

每个 LLM 的底层机制

每个 LLM 的核心都是强大的神经网络架构——最常见的是 transformer。这些网络通过学习数十亿个示例的统计关系，来处理和理解数据中的模式，特别是人类语言。尽管在结构上受到人类大脑的启发，但 LLM 纯通过数学运行，通过相互连接的层传递信息，这些层会随着模型进行调整。

为了让语言变得可计算，第一步将其转换为数字，因为神经网络无法处理原始文本。这通过两个关键步骤实现——分词（tokenization）和嵌入（embedding）：

分词 (Tokenization) 将句子分解为称为 tokens（标记）的较小单元。根据模型，可以是完整的单词或单词的一部分。例如，“The cat sat on the mat”可能会根据所使用的分词器被拆分为单个单词或更小的子词。
嵌入 (Embedding) 获取这些标记并将每个标记映射到高维向量——一组编码了其含义与其他单词之间关系的数字字符串。这些嵌入是在训练过程中学习的，使得相似的词最终位于模型“语义空间”中的相似区域。这有助于模型理解上下文和词汇用法，例如“巴黎”和“伦敦”作为城市之间的关系。

一旦输入被分词和嵌入，它就会在 transformer 网络 本身中移动。与只有几个隐藏层的传统神经网络不同，LLM 使用了数十层甚至数百层堆叠的层，每层都包含称为 注意力头（attention heads） 的机制。这些注意力层帮助模型决定输入中的哪些部分对预测最相关。例如，在完成句子时，模型学习更多关注影响后续内容的特定前词。

训练 LLM 是教导它随时间推移做出更好的预测。这是通过名为 反向传播（backpropagation） 的方法实现的，模型将其预测的词与正确的词进行比较，计算偏差程度，然后更新其内部参数以减少未来的错误。

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

假设你输入了“The cat is on the...”。模型通过对可能的延续（如 mat, roof 或 sofa）分配概率来预测下一个词。它并不是随机猜测——而是依赖于在训练期间见过的模式。

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

我们如何使用 LLM？

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

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

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

OpenAI、Azure AI 和 Hugging Face 等 LLM 提供了处理请求并实时返回响应的 API。该过程通常涉及：

身份验证 (Authentication)：开发者使用 API密钥或 OAuth令牌进行安全访问。

| 定义 |

| :--- |

| 身份验证是开发者证明其应用程序权限访问外部服务的方法。通常通过API密钥或OAuth令牌来实现。API密钥是由服务提供的唯一字符串（类似于密码），用于标识应用程序。另一方面，OAuth 是一种更灵活的系统，允许用户授予应用程序特定的权限，并返回临时令牌。这两种方法确保了只有授权的用户或系统可以发出请求，从而保护敏感数据和资源。 |

发送请求：结构化的 JSON 请求包含模型名称、提示和参数（如用于随机性的温度/temperature）。
接收响应：API 返回生成的文本输出以及作为 token 使用用量的元数据。

curl -X POST "https://api.openai.com/v1/chat/completions" \
-H "Authorization: Bearer YOUR_API_KEY" \
-H "Content-Type: application/json" \
-d '{
  "model": "gpt-4",
  "messages": [{"role": "user", "content": "What is the capital of France?"}],
  "temperature": 0.7,
  "max_tokens": 50
}'

{
  "message": {
    "role": "assistant",
    "content": "The capital of France is Paris."
  }
}

注意：某些 LLM API 支持流式响应（streaming responses），模型增量地输出标记，而不是等待生成完整响应后再发送。这种方法有助于缓解通常与大模型相关的高延迟。通过快速交付第一块文本，流式传输减少了感知延迟（用户在看到任何输出之前的等待时间），从而带来了更流畅、更敏捷的体验。

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

私有 LLM (Private LLMs)：这些是由 OpenAI、Anthropic 或 Google 等公司开发的专有模型。它们是闭源的意味着意味着无法查看或修改其底层代码。这些模型通常仅通过 API 访问，并按使用 token 计费。
开源 LLM：开源模型（如 Meta 的 Llama、Mistral 和 Falcon）可以免费下载、修改和部署。这意味着开发者可以访问底层的已训练参数，在私有基础设施上运行它们，并利用底层架构从零开始提取模型。

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

这种方法具有多个优势：

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

在 AI Agent（以及更广泛的 AI 驱动应用）背景下，最被采用的方法是通过 API 消费 LLM。例外可能与离线场景（例如在离岸站点或远程位置运行 LLM）或数据驻留方面的法规限制有关（LLM 必须位于没有公共云服务的特定国家内）。

教师模型

学生模型

https://github.com/OpenDocCN/freelearn-dl-zh/tree/master/docs/ai-agents-in-practice/img/7c0fff452a128c12d9cc1b782f267ef2_36_0.png

随着语言模型（LLMs）规模和计算需求的不断增长，蒸馏技术在保持高质量输出的同时，实现了更具实用性的部署。

推理模型

2024 年，一种被称为推理语言模型（RLMs）的新型 AI 模型问世，旨在增强超越传统 LLM 的复杂问题解决能力。这些模型代表了生成式 AI（GenAI）发展的重大转变，侧重于内部审议和逐步推理来处理复杂的任务。

RLM 的示例包括：

OpenAI 的 o1：于 2024 年 9 月发布，o1模型引入了“私有思维链”机制，允许模型在回答之前在内部对问题进行处理和推理。这种方法在数学和科学领域取得了显著进展，o1解决了美国数学数学邀请赛（ https://en.wikipedia.org/wiki/OpenAI-o1?utm_source=chat.com ）中 83% 的问题，标志着性能与之前的模型相比有了大幅提升。
OpenAI 的 o3模型：在 o1进展的基础上，o3模型于 2024 年 12 月发布，通过分配更多时间进行内部审议进一步增强了推理能力。这使其在包括编码和高级科学查询在复杂任务中获得了更高的准确率。注意的是，o3在 ARC-AGI 基准测试（ https://arxiv.org/blog/oai-o3-pub-breakthrough ）中获得了 75.7% 的得分，反映了其卓越的问题解决能力。

定义

https://github.com/OpenDocCN/freelearn-dl-zh/tree/master/docs/ai-agents-in-practice/img/7c0fff452a128c12d9cc1b782f267ef2_37_0.png

通用人工智能抽象与推理语料库（ARC-AGI）是一个用于评估 AI 系统对新任务的泛化和适应能力的基准，它紧密模拟了人类的智能。由 François Chollet 于 2019 年引入，ARC 强调在不依赖大量先验数据或特定领域训练的情况下抽象推理问题解决能力。

DeepSeek 的 R1模型：2025 年 1 月，中国初创公司 DeepSeek 引入了 R1，这是一种开源推理模型，其性能与 o1等领先模型相当，而开发成本仅为后者的部分。R1的开源特性促进了广泛的研究和应用，贡献了它的快速被采用和影响。

推理模型巨大的区别在于，它们在回答之前会“花时间思考”；与单次通过生成响应的传统 LLM 不同，RLM 会参与内部审议，在得出结论之前处理多个推理步骤。这种方法增强了它们处理复杂多步问题的能力，而这也是我们开始讨论 AI 智能体（AI agents）的关键，正如我们在整本书中看到的那样。

此外，RLM 经过专门训练，擅长需要高级推理的任务，例如复杂的数学、科学研究和错综复杂的编码挑战。这种专业化使其能够在这些领域优于传统的 LLM。

上述特征的自然结果是，与传统 LLM 相比，RLM 的内部处理和扩展的推理路径使得每次查询需要更多的计算力和时间。这种权衡导致了在需要深度推理的任务上以增加资源消耗为代价换得了更优越性能。

DeepSeek

2025 年，所有人的注意力都转向了一个名为 DeepSeek R1 的突破性模型。

DeepSeek 是一家成立于 2023 年的中国 AI 公司，开发了一系列先进的 LLM——以其 R1系列为巅峰——这些模型通过证明高性能模型可以高效且具有成本效益地进行开发，颠覆了 AI 行业。作为锦上添花，DeepSeek 还开源了这种训练方法以及模型本身，以便每个人都可以下载并在本地使用它们。

以下是 DeepSeek LLM 在生成式 AI 领域具备的主要特征：

训练方法： 让 DeepSeek 脱颖而出的是其独特的训练方法。它并不深度依赖人工标注的数据集，DeepSeek 的 R1-Zero模型是仅使用强化学习（RL）训练的。在强化学习中，模型通过尝试错误来学习——通过产生理想的结果获得奖励。在这种情况下，LLM 因其连贯且准确的回答而获得奖励，鼓励它独立发展出推理能力。

这种纯 RL 方法允许 DeepSeek 突破边界，但最初也伴随着权衡——模型有时产生可读性较差或不一致的语言。为了解决这个问题，团队对后续的 R1模型采用了多阶段训练过程，结合不同的技术来逐步提高模型性能。

该过程从在小规模、高质量的数据集上进行监督微调（通常被称为“冷启动”）开始，以建立语言基础。然后重新引入强化学习以提高推理和决策能力。模型还生成了合成数据，并通过拒绝采样（rejection sampling）进行过滤以剔除糟糕的输出。这些过滤后的数据被用于进一步的监督训练。最后的 RL 阶段有助于提高模型在多样化任务中的一致性和适应性。

结果是什么？一个质量上可以与 OpenAI 的 o1等顶级替代方案竞争的模型——尽管训练时使用的资源更少，且没有大规模的人工标注数据集。

硬件利用： 在尖端硬件往往是限制因素的行业中，DeepSeek 证明了创新可以抵消硬件限制。得益于前述的训练策略，该公司在 55 天内使用约 2,000 张 NVIDIA H800 GPU 成功训练了其旗舰模型 DeepSeek-R1，成本约为 560 万美元。考虑到美国对先进 AI 芯片的出口限制，这一成就尤为值得关注。
开源： DeepSeek 对开源原则的承诺营造了一个加速创新的协作环境。通过公开其模型和训练方法，DeepSeek 邀请全球研究人员和开发者对其工作做出贡献并在此基础上进行开发。

DeepSeek 的进展在全球 AI 界产生了波动，挑战了既有者，并引发了对现有实践的重新评估。

通 AI 智能体之路

生成式 AI 的快速演进使我们从简单的自动化变成了能够推理、学习和决策的日益智能的系统。近年来，LLM 改变了我们与周围生态交互的方式，实现了更自然的对话和复杂的问题解决。

让我们探索推动 AI 智能体出现的重大里程碑。

文本生成

自 2022 年 11 月 ChatGPT 发布以来，用户接受的首个用例是对话式生成，例如：

“对核裂变生成一个初级的描述”
“草拟一封给客户高层的邮件，邀请他们参加我们的活动”
“为关于 AI 的文章列出 10 个创意”
“为我生成一篇明天要交的法国大革命论文”

上述场景你看起来眼熟吗？

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

注意

在此语境下，文本也包括代码，因为从一开始开始，LLM 在生成和协助编程任务方面就展现了强大的能力。

生成式 AI 工作流的演变

大语言模型（LLMs）标志着传统人工智能和自然语言处理领域前未有的转变，因为它们能够根据生成连贯、创意且与上下文相关的文本。突然之间，这种不可思议的技术对每个连接互联网的用户都可用，实现了高质量写作的民主化，加速了营销和客户服务等行业的自动化进程，甚至通过故事讲述、诗歌和剧本创作重塑了创意领域。

然而，在最初对这种似乎了解我们所处世界的免费对话助手进行热热后，我们很快开始意识到存在一个巨大的局限性。ChatGPT 以及更广泛地说，LLMs 所携带的知识限于它们接受训练的数据（这称为参数化知识）。现在，即使这些数据代表了整个网络，用户仍然需要处理动态的、私有的或未包含在模型训练数据中的数据集。

事实上，“与你的数据聊天”是我们生成式 AI 路线图中的下一个里程碑。

与你的数据聊天

“我想和我的数据聊天。”这一陈述引出了名为检索增强生成（RAG）的特定技术。这种方法允许 LLM 不仅能生成文本，还能在生成响应之前从外部源检索相关信息，从而确保准确性、上下文相关性并降低幻觉风险。

https://github.com/OpenDocCN/freelearn-dl-zh/tree/master/docs/ai-agents-in-practice/img/7c0fff452a128c12d9cc1b782f267ef2_40_0.png

在语言模型的语境下，幻觉是指生成听起来合理但事实错误或缺乏事实数据支持的信息。这会损害信任，特别是在要求准确性的场景中。

将 LLM “限定”到预定义的知识库的过程被称为“落地”（grounding）。RAG 的关键部分是向量数据库（vector DB），它使用称为嵌入（embeddings）的向量表示来高效地存储和检索信息。这允许 LLM 搜索语义相关的信息，而不仅仅是精确的关键词匹配。

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

1. 检索或寻找相关信息：RAG 不仅仅依赖预训练知识，而是首先从已正确向量化的外部知识库中检索相关数据。这些可以是 PDF、Word 文件、报告、研究论文、结构化记录、表格、内部档案等。
1. 增强——提升 AI 的理解：一旦系统检索到相关文档，它们将与原始查询一起被输入模型。这一部分通过提供丰富的上下文输入来增强了 AI 的理解。

AI 现在不再是猜测或依赖通用知识，而是有了基于落地的、特定上下文的信息来构建其响应。这种增强过程确保了模型的输出具有：

更精确，因为它直接引用了相关数据
更具可解释性的响应，因为它们有可追溯的来源支持
更不容易产生幻觉，因为 AI 在经过策划且落地的上下文中生成内容
1. 生成——创建感知上下文的响应：有了增强的上下文，AI 随后会生成一个更具信息量、更准确且与检索到的数据一致的响应。最终输出是：
事实有据，因为它整合了检索到的知识
上下文感知，针对你的特定数据集进行定制
可引用的，意味着它在需要时可以提供引用或来源链接

这一步确保了响应不仅仅是 AI 生成的答案，而且是根据你数据的检索和增强知识专门定制的答案。

在接下来的章节中，我们将涵盖更多关于 RAG 及其在代理系统（agentic systems）中作用的内容。

到为止，我们一直在谈论文本数据，但如果我们想用图像、视频或音频与模型交互该怎么办？

多模态

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

最近的进展，例如 OpenAI 的 GPT-4V 和 Google 的 Gemini，展示了 MLLMs 如何在单一工作流中分析图像、说明、处理语音输入，甚至跨不同格式进行推理。

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

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

https://github.com/OpenDocCN/freelearn-dl-zh/tree/master/docs/ai-agents-in-practice/img/7c0fff452a128c12d9cc1b782f267ef2_42_0.png

这是罗马斗兽场，也称为弗拉未露剧场，位于意大利的罗马。它是古罗马最具标志性的地标之一，曾用于角斗士比赛和动物狩猎、模拟战斗等公共表演。

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

如你所见，模型能够分析图像并进行推理。现在让我们让模型生成一张插图：

https://github.com/OpenDocCN/freelearn-dl-zh/tree/master/docs/ai-agents-in-practice/img/7c0fff452a128c12d9cc1b782f267ef2_43_0.png

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

关于 LMM（大模态模型）最有趣的事实是，它们保留了推理能力，使其适用于异构上下文中的复杂推理。让我们考虑最后最后一个例子（仅显示响应的前几行）：

十字游戏

https://github.com/OpenDocCN/freelearn-dl-zh/tree/master/docs/ai-agents-in-practice/img/7c0fff452a128c12d9cc1b782f267ef2_44_0.png

横向：

一种属于猫头鹰且眼睛非常圆的鸟。
一种以长胡须闻名的猫。
一种有八条腿且在水中的动物。
风的英文怎么说。

纵向：

以飞行闻名的鸟叫什么名字？
一种以鳞片闻名的鱼。
一种以皮毛闻名的哺乳动物。
有翅膀的鸟叫什么名字？
使用哪个身体部位？

你能帮我解决吗？

当然，让我们来解这个字游戏。以下是根据给定线索的答案：

1. Cephalothorax（螯肢节肢动物中头部和胸部的的融合）
1. Arachnids（蝎子所属的纲：蛛目）
1. Metamorphosis（变态：从幼态到成态的转变）

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

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

LLMs 在生成连贯文本、回答问题甚至进行有限的问题解决方面展示了惊人的能力。然而，它们的基本设计在现实世界应用中存在几个局限性：

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

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

我们将在下一章中定义 AI 代理的构造。不过，你可以开始将其视为一个结合了 LLM 和额外能力（如记忆、规划和多步推理）的系统，以便以最小的干预执行任务，实现极大程度的自主性。与生成静态响应的标准 LLM 不同，AI 代理可以执行以下操作：

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

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

总结

在过去的两年里，AI 经历了深刻的变革，从简单的 LLM API 调用转向了更复杂、交互式且自主的系统。LLM 的快速演进以 RAG、微调进展和以推理为核心的架构等创新为标志，所有这些都旨在提高效率、适应性和成本效益。

尽管有了这些进展，但仅靠 LLM 还不足以满足市场对能够自主运行、做出决策并与环境进行有意义交互的 AI 系统的日益增长的需求。

这种转变标志着 AI 开发的一个关键时刻。关注点不再仅仅是让模型变得更大，而是让它们变得更智能。我们不再将 AI 视为一个响应孤立提示词的被动工具，而是现在设计能够行动、学习并适应复杂现实世界任务的代理系统（agentic systems）。

在下一章中，我们将研究 AI 代理的出现、其主要组件以及它们可能形成的各种形式。

参考文献

Knowledge Distillation: A Survey: https://arxiv.org/pdf/2006.05525
OpenAI o1: https://en.wikipedia.org/wiki/OpenAI_o1?utm_source=chatgpt
Reasoning Language Models: A Blueprint: https://arxiv.org/abs/2501.11223
LoRA: https://arxiv.org/abs/2106.09685
Adapter Tuning: https://arxiv.org/abs/2304.01933
Prefix Tuning and Prompt Tuning: https://ericwiener.github.io/ai-notes/AI-Notes/Large-Language-Models/Prompt-Tuning-and-Prefix-Tuning

立即解锁此书的专属福利

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

https://github.com/OpenDocCN/freelearn-dl-zh/tree/master/docs/ai-agents-in-practice/img/7c0fff452a128c12d9cc1b782f267ef2_46_0.png

2

AI 代理的崛起

本章将探索 AI 代理的演进，追溯其从早期的机器人流程自动化（RPA）到如今复杂的多代理架构的根源。我们将定义什么是真正的 AI 代理，分解其核心组件，并检查塑造全球行业的不同类型的 AI 代理。

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

从 RPA 到 AI 代理的代理演进
AI 代理的定义
不同类型的 AI 代理
AI 代理的组件

在本章结束时，你将对 AI 代理的演进、其关键组件以及它们如何转型行业清晰的的。

技术要求

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

从 RPA 到 AI 代理的代理演进

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

机器人流程自动化 (RPA)： 这代表了自动化的早期阶段，专注于设计用于执行预定义任务的基于规则的系统。这些系统遵循严格的逻辑流，根据显式条件和结构化输入执行操作。对于重复性流程，RPA 缺乏灵活性、适应性和处理非结构化数据的能力。例如，一个遵循严格决策树而不从交互中学习的基于规则的机器人；它无法处理动态环境或意外输入。
传统的基于 ML/RL 的代理： 随着人工智能的进步，传统的机器学习（ML）和强化学习（RL）代理开始出现。这些代理可以从数据中学习，基于概率模型做出决策，并通过试错来优化行动。让我们深入了解其中之一：
基于规则的代理：这些代理从静态规则集转变为基于机器学习的模型，可以根据训练数据对结果进行分类和预测。

以早期的客户支持机器人为例，它遵循严格的决策树来响应用户查询，并利用命名实体识别机制进行路由。

| 定义 |

| :--- |

| 命名实体识别 (NER) 是一项自然语言处理（NLP）任务，用于识别和分类给定文本中的关键信息，如人名、组织、地点、日期和其他定义的实体 |

AI 智能体（AI Agent）的演进

强化学习（RL）代理与非 LLM 智能体

强化学习（RL）代理通过与环境交互进行学习，优化行动以获得长期奖励。RL 代理被广泛应用于游戏、机器人和复杂问题解决领域。

例如，DeepMind 的 AlphaGo 通过模拟数百万局游戏并通过试错优化策略，学会了下围棋。

然而，这些早期的代理有一个巨大的缺点：泛化能力有限。以 AlphaGo 为例——尽管它通过数百万次模拟比赛精通了围棋，但它的智能是狭窄且特定领域的。AlphaGo 无法将其知识应用于象棋等其他棋类游戏，也无法处理客户服务或调度等不相关的任务。这种 AI 在严格限制的环境中可能表现出色，但在规则、上下文或输入模式发生变化时无法适应。

这种灵活性的缺乏揭示了 AI 面临的一个更广泛的挑战：需要能够跨领域进行推理、理解模糊指令并实时适应动态环境的代理。这就是基于 LLM 的代理大显身手的地方。

基于 LLM 的代理

随着 LLM 的出现，AI 代理变得更具推理、规划和动态交互的能力。生成式 AI 使这些代理不仅能够响应查询，还能合成信息、自动化工作流并与各种外部系统集成——正如我们在整个章节中详细看到的那样。

从高层次来说，基于 LLM 的代理的威力在于，它们可以利用像 GPT-4o 这样的模型理解上下文并检索相关信息，还可以协调一组组件，使代理与周围环境交互。这就是区分现代 AI 代理与之前的 RL 代理以及 LLM 本身的“额外智能层”。

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

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

多智能体系统与自我复制代理

AI 代理演进的一项重大突破是多智能体系统的引入，即多个代理协作解决复杂任务。这些系统允许任务委托、专门化和并行执行，从而实现更高的效率和自主性。例如，在一个多智能体研究系统中，一个代理负责检索论文，另一个负责总结，而第三个则为团队生成可操作的见解。

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

AGI 代理——下一个前沿

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

在编写本书时，这仍然尚未完全成为共识，但见证 AI 代理不断演变的边界确实是一个令人兴奋的时刻。

在本书中，我们将主要关注基于 LLM 的单一代理，并在第 7 章涉及多智能体框架。让我们从定义什么是 AI 代理开始。

AI 代理的组件

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

在技术层面，AI 代理由几个核心组件组成：

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

此外，我们还有一个编排层（Orchestration layer），用于管理代理内部的任务流，确保组件之间的协调。

注意

AI 代理可能具有也可能不具有用户界面。一方面是面向输入的对话式应用程序，它们会根据用户的输入做出反应（例如，处理用户对特定产品查询的客户服务 AI 代理）。另一方面，它们也可以在自动化工作流中“幕后”运行；如果是这样，它们可能完全不需要 UI，因为它们是由事件触发的（例如，每当记录系统中创建工单时，AI 代理就会提供解决方案）。

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

让我们详细查看每个组件：

LLM：它充当核心推理引擎，即代理的“大脑”，以对话的方式提供解释、解决问题并回答学生的问题——这一切都归功于代理组件提供的额外信息。

注意

重要的是，LLM 通常在公共或通用数据集上进行训练。这意味着，除非显式地基于此类信息进行对齐，否则它们通常对特定行业、专有数据或组织流程缺乏深层的上下文理解。这就是为什么提供与特定用例相关的外部知识库可以为代理配备特定领域的知识，从而提高在现实世界场景中的准确性、可信度和实用性。

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

以下是它们在实践中的工作方式：

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

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

这种机制之所以强大，是因为语言模型理解自然语言的能力。每当一个工具或组件（例如“预约会议”操作）初始化时，不仅是通过其底层逻辑（例如 API 调用和向日历添加事件的 POST），还附带了自然语言描述。该描述用通俗易懂的话解释了工具的功能及其返回的输出类型。LLM 读取此描述并利用它在执行任务期间决定何时以及如何调用工具。本质上，模型不仅是在执行代码，而是在根据人类可读的描述对可用操作进行推理。

如何在自然语言中描述代理人的组件示例

现在，当用户提问的瞬间，由 LLM 大脑驱动的 Agent 会浏览所有组件描述并理解该查询应调用哪个组件来解决问题。

我们可以为 Agent 定义策略以调用合适工具。例如：始终先启动一个工具；随后让它决定是否还需要额外工具（使用系统消息中的指导顺序）。请注意这些策略必须在编排层面上定义：

You are a helpful AI assistant with access to following tools:
- Tool A
- Tool B

When processing requests, always try using only Tool A; if insufficient action cannot completed with only model capabilities activate Step B afterward making sure we don't activate Button C before trying upon button T while already tested Item more than necessary.

这些生产开发计划最初被指定为章节条目，随后显示在文章页面中，其中实际操作流程需要根据正在进行的部门特定项目进度报告进行验证更新，这些报告是在证明实质性修改后创建的，包括关于功能需求调整的审计变更，而不影响核心功能状态的保持，除了文档目的之外，仍然继续实际操作的执行，最终的预期成果仍然得以实现。

第 2 章

39

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

购买此书时将免费赠送下一代 Packt Reader。扫描二维码码或访问 packtpub.com/unlock，使用搜索栏通过名称查找此书。请双倍检查显示的版本，以确保获取的是正确的版本。

https://github.com/OpenDocCN/freelearn-dl-zh/tree/master/docs/ai-agents-in-practice/img/7c0fff452a128c12d9cc1b782f267ef2_61_0.png

AI 智能体自动扫描来自患者 X 的电子邮件。它提取关键细节，如患者 X 的姓名和联系方式、偏好的日期和时间以及所需的专科医生。
AI 智能体检查可用性，通过与诊所调度系统调用插件（我们为智能体配备的工具）来完成操作。它将患者 X 的偏好与专科医生最早的空档进行匹配。如果匹配成功，则进入第 5 步。
AI 未找到匹配项。由于未找到匹配项，AI 智能体根据专科医生的日程生成后续最佳可用空档列表。它利用写作技能为患者 X 起草回复邮件，提供建议的替代方案，但在发送之前由 John 审核并批准。
患者 X 回复新的偏好，并：
- a. 接受其中之一（进入第 5 步）
- b. 请求新选项，然后 AI 智能体重复第 3 步。
一旦 John 和患者 X 同意某个时间，AI 智能体将利用上述相同的插件在系统中安排预约。此外，它利用电子邮件插件向患者 X 发送包含详情的确认邮件。最后，它更新专科医生的日历并通知他们预约。

AI 智能体的崛起

https://github.com/OpenDocCN/freelearn-dl-zh/tree/master/docs/ai-agents-in-practice/img/7c0fff452a128c12d9cc1b782f267ef2_62_0.png

图 2.7：医生办公室 AI 智能体结构示例

如你所示，AI 智能体充当 John 的助手，处理重复性的调度任务，而他专注于面对面的患者互动。

自主智能体

自主智能体代表了 AI 智能体的最高级类别。与在预定义边界内运行的检索智能体和任务智能体不同，自主智能体策略地协调多个任务和检索过程，做出实时决策以优化工作流。这些智能体表现出高度的独立性、适应性和感知能力，允许它们极少的人工干预执行复杂操作。

自主智能体的关键区别在于它们能够：

结合检索与行动：它们既可以寻找信息（类似于检索智能体），也可以对其执行操作（类似于任务智能体）。
计划与自我调整：它们根据新信息或不断变化的约束进行动态调整。
执行多步工作流：它们将复杂任务分解为子任务，迭代执行并根据结果进行调整。

让我们继续以 John 诊所的例子。随着诊所变得繁忙，管理预约、取消和重新安排变得不可重负。任务智能体帮助简化了单个动作，但现在由自主智能体接管了端到端的调度过程，只需极少的监督。以下是其工作步骤：

a. 接收与优先级排序：智能体监控所有渠道（电子邮件、门户网站、电话转录），提取患者偏好、紧急程度、专科需求，并根据优先级对请求进行排序。例如，一个取消的预约释放了一个空档，智能体立即将其匹配给等待相似时间的患者 X。
b. 计划与优化：它审查全天日程，识别冲突或空闲间隙，并构建优化计划——调整低优先级访问以为紧急访问留出空间。
c. 带有反馈的执行：智能体向患者发送选项信息、更新日历、预订并发送确认——全部自动完成。如果偏好发生变化，它会返回循环并完善其操作。
d. 实时适应：医生请假了。智能体停止新的预约，重新安排受影响患者的行程并通知员工——在无需人工输入的情况下自主处理所有步骤。
e. 持续学习：在结束时，它分析结果，更新患者偏好并调整未来的优先级逻辑。

自主智能体可以进行计划、检索、决策、行动、适应和学习——这一切都不依赖于预定义的工作流。现在 John 专注于边缘情况，而由智能体智能地处理其余部分。

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

备注

即使自主智能体与业务流程自动化的概念非常契合，但请记住，它们也可以代表客户体验的新增强。例如，在上述场景中，患者 X 无需打电话或发送电子邮件，而是利用 AI 智能体提供的对话式 UI（这可以通过诊所网站或 WhatsApp 通道实现）。通过这种方式，患者 X 将以全新的、更顺畅的方式与诊所互动，而 AI 智能体正在捕捉意图、在需要更多信息时提问问题，并协调后端执行任务。

https://github.com/OpenDocCN/freelearn-dl-zh/tree/master/docs/ai-agents-in-practice/img/7c0fff452a128c12d9cc1b782f267ef2_64_0.png

我们可以为智能体提供不同程度的自主性，决策取决于业务场景以及我们对解决方案准确性的信心程度。

总结

AI 智能体已经从基础自动化工具演变为复杂的自主系统，改变了业务运营和专业工作流。本章探讨了三种主要类型：通过 Agent RAG 增强知识访问的检索智能体；自动执行调度和电子邮件管理等特定操作的任务智能体；以及将检索、执行与战略性决策相结合以优化复杂工作流的自主智能体。为每种用例部署正确的 AI 类型是实现有影响的自动化和增强用户体验的关键。

从下一章开始，我们将深入探讨 AI 智能体的每个组件，从 AI 编排开始。

参考文献

DeepMind 的 AlphaGo: https://en.wikipedia.org/wiki/AlphaGo#:~:text-AlphaGo is a computer program that plays the ,%20version%20that%20competed%20the%20name%20Master
自主智能体: https://www.techtarget.com/searchenpriseai/definition/autonomous-agents
强化学习: https://www.tensorflow.org/agents/tutorials/intro_rl
AGI: https://www.ibm.com/think/topics/artificial-general-intelligence

此部分包含以下章节：

第 3 章：AI 编排器的必要性
第 4 章：内存与上下文管理的必要性
第 5 章：工具与外部集成的必要性
第 6 章：使用 LangChain 构建第一个 AI Agent
第 7 章：多智能体应用

第 3 章：AI 编排器的必要性

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

AI 编排器的出现是为了应对这一需求。它们不仅仅是提供预构建的组件，而是提供了一个用于结构化交互、管理依赖关系以及维护多智能体或模块化工作流控制的框架——同时加速开发并降低操作风险。

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

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

在本章结束时，你将熟悉最流行的 AI 编排器，以及如何利用它们来实现你独特的智能体用例。

AI 编排器简介

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

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

https://github.com/OpenDocCN/freelearn-dl-zh/tree/master/docs/ai-agents-in-practice/img/7c0fff452a128c12d9cc1b782f267ef2_70_0.png

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

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

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

为了更好地理解在 AI Agent 特有背景下对 AI 编排器的需求，我们需要介绍后者的三个重要特性：自主性、抽象化和模块化。

自主性

自主性是指 AI Agent 独立运行的能力，在没有人类干预的情况下做出决策并执行操作。这种自导行为使 AI Agent 能够执行任务、适应新情况并根据其学习的经验追求目标。

AI Agent 的自主性意味着 Agent 将采取的步骤并不总是预先知道的。

例如，让我们考虑一个简单的非智能体工作流：

https://github.com/OpenDocCN/freelearn-dl-zh/tree/master/docs/ai-agents-in-practice/img/7c0fff452a128c12d9cc1b782f267ef2_71_0.png

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

每当我们提示 LLM 时，我们都在进行 API 调用，这是构成该工作流的唯一步骤。即使在检索增强生成（RAG）工作流场景中，步骤也是预先知道的：

带有嵌入的向量数据库

https://github.com/OpenDocCN/freelearn-dl-zh/tree/master/docs/ai-agents-in-practice/img/7c0fff452a128c12d9cc1b782f267ef2_72_0.png

现在让我们考虑一种自主的智能体方法。假设我们有一个有两个工具的 Agent：

天气工具：一个接收两个参数的函数：城市和测量单位。
位置工具：一个接收用户当前位置（利用 GPS 位置）的函数。该函数没有参数。

根据 AI Agent 的解剖结构，这两个函数都带有自然语言描述。我们的工作流设计将让 Agent 决定调用哪个工具。

https://github.com/OpenDocCN/freelearn-dl-zh/tree/master/docs/ai-agents-in-practice/img/7c0fff452a128c12d9cc1b782f267ef2_72_1.png

假设一个新用户问：“明天天气如何？”将发生以下情况：

Agent 将读取其工具的描述并理解它需要调用天气工具。然而，它缺少两个参数，但得益于它的自主性，它可以查看周围来检索这些参数。因此它理解可以利用位置工具来获取第一个参数：该函数的输出将作为天气工具的参数。

https://github.com/OpenDocCN/freelearn-dl-zh/tree/master/docs/ai-agents-in-practice/img/7c0fff452a128c12d9cc1b782f267ef2_73_0.png

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

对于第二个参数，Agent 无法独自完成：它需要询问用户。于是它这样做了，询问用户需要哪种测量单位。一旦用户回答，Agent 就能使用两个参数正确地调用工具。

AI 编排器的必要性

https://github.com/OpenDocCN/freelearn-dl-zh/tree/master/docs/ai-agents-in-practice/img/7c0fff452a128c12d9cc1b782f267ef2_74_0.png

图 3.6：AI Agent 向用户询问缺失工具的示例

Agent 观察天气工具的输出，并确定它现在知道了给用户的最终答案。

https://github.com/OpenDocCN/freelearn-dl-zh/tree/master/docs/ai-agents-in-practice/img/7c0fff452a128c12d9cc1b782f267ef2_74_1.png

图 3.7：AI Agent 向用户询问缺失工具的示例

我们可以想象需要多少个 if...else 语句才能复制这种自主性吗？即使我们能管理类似的场景，如果用户问了某些未在流程中硬编码的内容怎么办？自适应性、自我批判、自我调整是智能体自主性的关键特征。

我们可以为 Agent 提供许多不同程度的自主性：这取决于我们设置的工作流以及指示 Agent 遵循的规划策略。正如我们在本章中看到的，我们可以定义一个计划，让 Agent 按特定顺序执行工具；我们可以计划让 Agent 在达到特定输出之前不断循环，然后再进入下一步；或者我们可以让 Agent 自由地在需要时尽可能多次使用所有工具。

设计合适的智能体工作流是一场架构设计对话，这是构建你的智能体状态时的关键。

抽象化与模块化

抽象化是指拆解并简化复杂性。它是让这些系统变得可理解且可扩展的原因。但除了简化之外，它还实现了模块化设计，这是构建智能系统的基本原则。

模块化将复杂问题分解为更小的、可重用的组件，每个组件处理挑战的特定部分。这种方法具有多个优势：

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

在多智能体系统中，抽象化和模块化允许创建协作智能体，每个智能体负责特定任务并进行动态交互。这反映了人类解决问题的方式，我们通过分工、委托和协作来有效应对复杂性。

理解智能体模式中抽象化和模块化的极佳方法是观察繁忙大都市的多智能体交通管理系统，其中不同层级的智能体处理不同级别的抽象，确保运行顺畅而不会让任何单一实体过载。

注意

我们将在第 7 章中详细介绍多智能体系统。然而，重要的是，一个独立的智能体始终可以被另一个智能体作为“工具”来调用，其方法是提供关于其能力的自然语言描述。例如，当“项目经理智能体”需要查询 SQL 数据库时，“SQL 智能体”就可以成为它的工具。

从现在起，在多智能体系统以及接下来的示例中，请将智能体视为其他智能体的潜在工具。

在最细粒度的层面上，我们有路口控制器，它们运行于单个交通灯或交叉路口。这些智能体依赖摄像头和传感器的实时数据，根据交通拥堵情况、行人移动和紧急车辆优先级来调整交通信号。

它们并不担心下一个街区或更广泛区域发生了什么；它们唯一的工作就是优化其特定位置的交通流。如果路口突然出现大量车辆，它们可能会延长绿灯时长以缓解拥堵。

放远视角，我们有区域级交通协调员。这些智能体并不微观管理单个交通灯，而是分析社区或区域内多个交叉路口的交通流。

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

更重要的是，它们指导路口级智能体，确保它们的调整与更广泛的区域交通目标保持一致。

在最高层，我们有市级交通管理系统，负责优化整个大区的车辆流量。该智能体不关注特定的交通灯或单个拥堵点；而是分配资源、预测长期模式并做出战略性调整。

利用来自天气预报、重大活动日程、事故和公共交通网络的数据，该智能体可能会重新规划整条道路，协调施工进度以减少干扰，或在发生重大事件时实施全市应急响应计划。

第 3 章

如果主高速路上发生事故，市级系统会重定向区域级智能体来调整交通模式，进而指示路口控制器高效地重新规划路线。

这种分层结构展示了多智能体系统中抽象和模块化的力量：

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

这反映了软件架构、AI 系统甚至公司结构在现实世界中的运作方式。无论是执行任务的一线员工、协调工作的中层经理，还是看到整体愿景的高管，抽象都能让系统保持可扩展性、效率和韧性。

通过这种分层方法设计多智能体 AI 架构，我们确保每个智能体都专注于它需要处理的内容，防止系统过载，并实现大规模的自适应、实时决策，就像管理繁华城市的智能交通系统一样。

如果你觉得这听起来不像现实中的存在，让我们来看看 OpenAI 的一个名为 Operator 的工具，它作为一个自主智能体运行，能够在网页浏览器中执行任务，例如预订或填写在线订单。

OpenAI 的 Operator 遵循类似于交通管理系统的分层多智能体方法。每个智能体在不同的抽象级别运行，确保了效率和适应性，而不会让任何单一组件负担过重。

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

这种结构化方法强调了抽象在多智能体设计中的关键性：

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

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

从架构角度来看，所有这些组件——智能体、技能、插件——都可以被视为组织中可重复的资产。在这种背景下，AI 编排器确保这些组件协同工作而不产生紧耦合，防止复杂性使系统过载。

遵循上述的分层示例，通过 AI 编排器，你可以轻松定义以下内容：

执行智能体（低级）：这些处理原始任务，如 API 调用、数据库查询或网页爬取，执行命令而不进行决策
推理智能体（中级）：它们分析数据、确定操作并选择正确的工具，抽象执行细节
编排与规划（高级）：编排器监督工作流，分解任务，将其分配给各个智能体并进行动态调整

https://github.com/OpenDocCN/freelearn-dl-zh/tree/master/docs/ai-agents-in-practice/img/7c0fff452a128c12d9cc1b782f267ef2_79_0.png

图 3.8：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 交互的详细日志，用于调试和优化。
自动错误检测：识别失败的进程并重试，同时自动进行升级处理。
性能跟踪：监控响应时间、准确性和整体系统健康状况。
人机交互（Human-in-the-loop）：允许对关键决策进行人工审核。示例：医疗 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 驱动自动化但不想深入研究代码密集型实现的开发者和研究人员特别有用。
Semantic Kernel (SK)：由微软开发，将机器学习能力与传统软件开发实践相结合，弥合了 AI 与企业应用之间的差距。它支持基于插件的方法，允许开发者将 AI 驱动的工作流集成到现有的业务系统中。Semantic Kernel 的设计是将 AI 驱动的自动化直接嵌入到企业软件环境中以提高生产力。
LangGraph：LangGraph 通过基于图的工作流为多智能体协作引入了结构化方法。它提供了一个设计复杂的智能体间交互的框架，确保 AI 系统以组织且可扩展的方式进行通信。这对于编排不同智能体必须动态协作解决复杂问题的 AI 应用特别有价值。

现在问题是：我如何为我的 AI 智能体选择合适的编排器？

如何为你的 AI 智能体选择正确的编排器

选择 AI 编排器取决于多个因素，包括应用的复杂度、所需的自定义程度、可用的生态系统以及部署的简易性。选择编排器时的关键标准：

易用性和模块化：如果你寻找一种快速且模块化的方法将 LLM 集成到应用中，LangChain 是一个很好的选择，因为它文档齐全且架构灵活。示例：开发客户支持 AI 聊天机器人的初创公司可以使用 LangChain 快速构建原型并与现有的数据库和 API 集成。
数据密集型应用：如果你的智能体高度依赖结构化或非结构化数据检索，LlamaIndex 为高效集成外部知识源进行了优化。示例：一个跨多个存储库检索和分析法例的法律助手将从 LlamaIndex 的检索能力中受益。

AI 编排器与智能体内存管理

多智能体工作流

如果你的应用需要多个智能体动态交互，AutoGen 或 LangGraph 是编排复杂 AI 交互的理想选择。示例：研究助手需要多个智能体协作——一个总结文档，另一个检查事实，第三个生成报告——这会从这些编排器中受益。

企业级 AI

如果你需要强大的企业级集成和安全性，Semantic Kernel 非常适合基于 Microsoft 的环境和结构化的 AI 工作流。例如：一个与 Microsoft Teams 和 SharePoint 集成的企业级 AI 驱动工具将与 Semantic Kernel 非常匹配。

视觉化工作流设计

如果你倾向于使用无代码或低代码界面进行 AI 工作流设计，Langflow 提供了一个直观的 UI，用于 AI 智能体交互的快速原型和调试。例如：一个没有深厚编程知识的营销团队创建一个 AI 驱动的内容生成器，利用 Langflow 的可视化界面进行快速工作流设计。

选择合适的 AI 编排器

选择 AI 编排器应符合你 AI 系统的目标和技术需求。有些编排器专注于模块化开发，而另一些则侧重于扩展性、多智能体协作或企业集成。理解这些区别将帮助你为特定的用例选择最佳工具。

总结

AI 编排器在智能系统的开发和部署中起着关键作用，它们提供了管理工作流、集成工具和维持效率的必要框架。随着 AI 应用的不断演进，编排器确保了 AI 智能体能够自主运行、处理复杂任务并适应动态需求。

在本章中，我们探索了 AI 编排器的基本组件，包括工作流管理、内存处理和安全性。我们还研究了目前最流行的一些编排器，每种都针对特定用例提供了定制的优势。

选择正确的 AI 编排器取决于多种因素，例如集成需求、扩展性和工作流复杂性。通过理解它们的核心功能，开发者和企业在选择符合其目标的编排工具时可以做出明智的决策。

从下一章开始，我们将深入探讨 AI 智能体引人注目的组件，从内存和上下文管理开始。

参考文献

OpenAI Operator: https://openai.com/index/introducing-operator
LangChain: https://www.langchain.com/
LlamaIndex (原 GPT Index): https://www.llamaindex.ai/
AutoGen: https://www.microsoft.com/en-us/research/project/autogen/
Langflow: https://www.langflow.org/
Semantic Kernel (SK): https://github.com/microsoft/semantic-kernel
LangGraph: https://www.langchain.com/langgraph

解锁专属福利

立即解锁此书的专属福利。扫描此二维码或访问 packtpub.com/unlock，然后通过书名搜索此书。

https://github.com/OpenDocCN/freelearn-dl-zh/tree/master/docs/ai-agents-in-practice/img/7c0fff452a128c12d9cc1b782f267ef2_86_0.png

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

第 4 章：内存和上下文管理的必要

大型语言模型（LLMs）从根本上是无状态的，尽管它们看起来是连贯且富有对话性的。它们只知道你在当前提示（prompt）中告诉它们的内容。除非你显式地构建，否则没有持久的上下文或历史。如果处理得当，内存允许智能体在时间的推移中保持一致性、感知上下文，甚至实现个性化。

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

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

在本章结束时，你将对内存如何在 AI 智能体中发挥作用，以及让你的智能体更智能、更可靠且感知上下文所需的工具和模式有深入理解。

不同类型的内存

就像人类依赖记忆来理解世界一样，AI 智能体也需要内存来随时间长时间智能地运行。内存允许智能体在跨交互中保留信息、记住过去的事件、存储有用知识并建立一致的行为。没有内存，即使是最强大的语言模型也是无状态的——只对当前输入做出反应，而不知道之前发生了什么。

随着 AI 智能体变得越来越复杂，对其内存系统的要求也随之增加。智能体仅仅生成响应已经不够了——它必须随着时间的推移进行记忆、适应和改进。有趣的是，研究人员设计智能体内存架构的方法很大程度上借鉴了心理学家对人类记忆的理解。这种并行关系导致 AI 内存类型的分类日益增多，每种内存都有独特的用途，从处理近期交互到构建长期知识和技能。

在本节中，我们将遵循 Theodore R. Sumers 等人在他们的论文 Cognitive Architectures for Language Agents 中提出的框架，拆解驱动现代 AI 智能体的不同类型的内存系统。

短记忆

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

在对话系统中，这对于维持跨多轮交互的连贯性至关重要。如果用户说“帮我订一个晚上 7 点 4 个人的桌子”，然后接着说“再加一个座位”，STM 帮助智能体连接这些点。

https://github.com/OpenDocCN/freelearn-dl-zh/tree/master/docs/ai-agents-in-practice/img/7c0fff452a128c12d9cc1b782f267ef2_89_0.png

从技术上讲，STM 通常使用滚动上下文窗口或缓冲区实现，持有最近的对话或数据块。

| 定义 |

| :--- |

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

随着新输入的到来，旧数据会被推出去。这保持了交互的响应性和轻量化，但也意味着 STM 本质上是瞬时的。一旦缓冲区充满或会话结束，信息就消失了。

内存和上下文管理的必要

因此，虽然 STM 是快速问答式交互的理想选择，但在记住偏好或从过去的会话中学习方面不足。这提出了一个关键问题：AI 智能体如何在跨交互中保留长期上下文和连续性？

长期记忆

虽然 STM 处理现在，但长期记忆（LTM）关乎时间的连续性。它允许智能体在不同的会话之间回忆信息，实现个性化、持久知识和更好的决策。

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

注意 STM 和 LTM 是关联的，STM 最终可以刷新到 LTM（我们将在接下来的章节中探索类似的技术）。

https://github.com/OpenDocCN/freelearn-dl-zh/tree/master/docs/ai-agents-in-practice/img/7c0fff452a128c12d9cc1b782f267ef2_90_0.png

在长期记忆中，我们可以进一步细分为三个镜像人类认知的不同子类型。

语义内存

语义内存存储通用知识——事实、概念、规则和定义。它是系统中“知道某事”的部分，允许智能体进行推理、解释并提供知情的答案。

注意，根据设计，LLM 带有参数化知识，这些知识提供了关于世界的广泛知识：它们了解物理、数学、通用常识以及以任何形式编码在互联网上公开的任何文档中的一切。然而，这些知识对于我们特定的用例可能不够或不相关：例如，如果我们想让 AI 智能体对我们在医疗保健中心进行过的所有过去的诊断有记忆呢？当然，这是无法成为训练集的一部分，因此它不是 LLM 参数化知识的一部分。这就是为什么语义内存对于运行在法律、医学或金融等领域的智能体特别有用，在这些领域，事实准确性和领域理解至关重要。

在实践中，语义内存可以通过存储在向量存储中的向量编码器嵌入来实现，其检索原理与第 1 章解释的 RAG 概念相似。

注意：语义内存也可以是 STM 部分内容的最终终点。事实上，STM 上下文窗口中的某些组件或对话可能值得保留，如果是这样，它们可以向量化并存储在语义内存中。

情景记忆

在人类大脑的语境下，情节记忆是指回忆个人参与过的特定事件的能力。对于 AI 来说，情节记忆允许 AI 存储和检索与其环境交互的特定经验或片段的记忆，而不仅仅是通用事实知识。

例如，一个 AI 导师可能会记住学生上周是如何回答一个数学题的，并将其用于今天的课程。这种内存通常存储为结构化日志或事件历史，智能体可以引用它们做出案例决策或调整其行为。

在实践中，情节记忆可以被视为少样本提示（few-shot prompting）技术的扩展。

定义

少样本提示（Few-shot prompting）是一种用于大语言模型的技术，通过在提示词本身中为模型提供少量（通常为 2-5 个）说明性示例。这些示例有助于引导模型的响应，使其更好地对齐目标任务，而不需要大量的微调或训练数据。

以下是一个示例：

任务：情感分析

示例 1：

文本：“我太喜欢这部电影了！”

情感：正向

示例 2：

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

情感：负面

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

文本：“尽管存在一些缺陷，但电影整体来说是趣味。”

情感：

通过这种方式，少样本提示利用了模型仅从少数示例中快速学习模式的能力，在无需显式重新训练的情况下提高其在特定任务上的性能。

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

根据 Chad Dechant 的论文《AI 智能体中的情景记忆带来了需要研究和缓解的风险》，在 AI 智能体中实施情景记忆将带来显著增强，如下：

规划与决策： 记忆提供了形成新策略的基石，或者通过回顾类似的以往经验和结果。
改进学习： AI 智能体可以通过反思过去的事件及其结果，识别模式并从错误中学习，从而更好地适应新场景。
问题解决： 情景记忆提供了过去场景的示例，通过类比或对过去解决方案的重新组合来帮助解决当前问题。
预测与想象： 就像人类根据过去的事件在脑海中模拟未来场景一样，AI 智能体可以使用情景记忆来预测可能的结果。

然而，作者还强调了与情景记忆相关的潜在风险：

欺骗： 智能体可以利用情景记忆，通过回顾过去的交互并策略性地操纵未来的交互来执行复杂的欺骗。
非愿知识保留： 智能体可能会保留并回忆用户希望私密的信息，构成重大的隐私风险。
不可预测的行为： 随着智能体重用过去的经验来形成未来的行动，很难预测某些记忆将如何影响未来的行为，可能导致意外之外的后果。
增强的情境感知： 改进记忆能力可以使 AI 更好地理解并适应其运行环境，可能在不被察觉的情况下逃避控制或审计以确保安全。

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

注意事项

在人类认知和 AI 系统中，情景记忆和语义记忆起着不同的作用：

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

语义记忆更像一本百科全书。它存储“已知内容”——独立于语境的通用事实、概念和规则。对于 AI 智能体来说，这可能意味着产品规格、策略规则或领域知识。

保留这两种类型的记忆允许智能体更有效地进行推理：它们可以在需要时利用过去的事件，同时依靠既有知识来保持一致性和准确性。

通常，AI 智能体通过记录交互来捕获情景记忆，这些交互通常包含：

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

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

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

当 AI 智能体需要回忆过去的经验以为当前决策提供信息时，它执行以下步骤：

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

这一过程使智能体能够根据先前的经验调整其行为，增强交互的个性化和连续性。

程序记忆

我们需要提到的最后一种记忆是程序记忆。对于我们来说，这种类型的长期记忆负责存储“如何做某事”，例如记住如何骑自行车或系鞋带——这些技能一旦学会，就可以在没有有意识思考的情况下执行。在 AI 语境下，程序记忆具有类似的功能：它编码了治理智能体行为的基础性“门道”。例如，在自动驾驶汽车中，程序记忆能够执行导航路线和避障操作，而无需从头重新评估每个决策。

根据《语言智能体认知架构》（Cognitive Architectures for Language Agents）论文中提出的 CoALA 框架，智能体的程序记忆由两个主要部分组成：

LLM 权重，它隐式地编码了大量的程序知识——如语言使用、推理模式和世界模型
智能体代码，它显式定义了程序，如提示构建、检索机制、落地例程（grounding routines）和决策逻辑

本质上，程序记忆被编码在模型的架构中。因此，大多数当前的 AI 智能体将其视为静态的（与人类的程序记忆不同，后者可以通过经验随时间进行适应）。LLM 的权重在部署期间保持不变，而智能体代码很大程度上由智能体自己重写。

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

一种更具实用且观察到的行为是智能体修改系统消息——本质上是更新它们用于引导的指令。这种方法提供了一种轻量级的程序化适应，尽管其范围有限且未被充分利用。

我们涵盖的每种记忆在塑造智能体智能方面都发挥着独特的作用，从实现行动到辅助决策以及从过去学习（参见下表 4.1）：

| 类型 | 目的 | 内容 | 存储机制 | 使用示例 | 更新机制 |

| :--- | :--- | :--- | :--- | :--- | :--- |

表 4.1：记忆类型及其使用示例

它们共同构成了智能体持久能力和累积知识的骨干。

我们涵盖了长期和短期记忆；但还有第三类值得提的：语义内存缓存。

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

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

注意

在传统的应用程序开发中，内存缓存是一个临时存储层，它在内存（通常是 RAM）中保留被频繁访问的数据，以降低延迟并提高性能。应用程序不再重复从数据库或外部 API 查询相同的数据，而是从缓存中检索——从而实现更快的访问。Redis、Memcached 以及应用框架中的内存级层通常用于此类目的。

缓存通常基于键值对工作——你使用唯一键存储结果，并在稍后检索它。这对于存储用户会话、API 响应或不经常更改的计算值等场景非常高效。在 AI 智能体以及更广泛的 LLM 驱动应用背景下，这一概念是类似的，但键值对是基于嵌入的，因此检索可以通过向量搜索而非关键词匹配来实现。

在图 4.3 中，你可以看到关键词内存缓存与语义内存缓存的区别：

关键词内存缓存

| 内存缓存 |

| :--- |

| 'question': 'what is the capital of Italy?' | 'answer': 'what is the capital of Italy?' |

| 'The capital of Italy is Rome.' | 'answer': 'The capital of Italy is Rome.' |

语义内存缓存

| 语义内存缓存 | | |

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

| 'what is the capital of Italy?' | Embedding | Question: what is the capital of Italy? |

| 'Italy main city?' | [0.5, 0.9, ... ] | Answer: The capital of Italy is Rome |

| 'Can you tell me what is the boot-shaped country's capital?' | | The capital of Italy is Rome. |

图 4.3：关键词内存缓存与语义内存缓存之间的区别

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

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

与依赖模型 token 上下文窗口的 STM 以及设计用于跨会话持久记忆的 LTM 不同，语义缓存是会话范围内的、瞬时的且快速的。它的设计不是为了随时间保留知识或事件，而是为了帮助智能体在持续交互期间动态检索相关上下文——即使其表述方式与原始表达不同。

第 4 章

这种实时回溯通过专为语义检索设计的向量支持数据库实现的。诸如集成了向量索引的 Cosmos DB、Pinecone、Weaviate 和 Qdrant 等工具允许开发者以低延迟存储和查询嵌入。这些系统支持内存搜索、元数据过滤以及基于相关性和新颖性的评分等功能——使其成为实现语义缓存的理想选择。

例如，在患者预约流程中，如果用户之前说“下午最合适”，随后询问“你们下午 3 点以后有空档吗？”，语义缓存可以检索并匹配之前的陈述——即使它已不在上下文窗口中。这使得智能体能够在不产生额外成本的情况下保持连贯性和上下文感知。

在实践中，语义缓存充当智能的短期回溯层，赋予智能体保持响应能力、语义流利高效性的能力——而无需长期的投入。它们并没有取代 STM 或 LSTM；它们通过在对话过程中实现低延迟、相关性驱动的内存来弥补它们。

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

管理上下文窗口

当涉及 STM（或工作记忆）时，上下文窗口（context window）的概念至关重要。它定义了模型可以同时处理的、以 token 为单位的最大文本跨度。该窗口允许模型在生成响应时“记住”并利用特定段的信息，从而使用户无需重复上下文信息。

尽管最新的 LLM 能够处理的最大 token 数量有所增加（例如 GPT-4o 等模型可多达 128K token），但管理上下文窗口仍面临挑战。当输入超过模型的上下文窗口时，模型可能难以维持连贯性和相关性，因为它无法访问文本的前部部分。这种局限性可能导致输出缺乏上下文或连续性，特别是在需要处理扩展文档或长时间对话的任务中。

因此，我们需要妥善设计上下文窗口的处理方式。该领域有许多技术，在本节中，我们将检查一些最流行的技术：

滑动窗口（Sliding window）： 滑动窗口技术通过维护一个固定大小近期消息窗口并动态更新它来管理短期记忆。确定窗口大小至关重要，可以通过固定消息数量或设置 token 限制来实现。例如，如果我们设置滑动窗口以保留 4 条消息（通常是这样设置的），我们将得到如下结果：
编辑消息列表（Editing message lists）： 编辑消息列表是滑动窗口的扩展，在保留哪些消息方面可能更加细粒度。它涉及在 LLM 处理消息之前选择性地裁剪或过滤消息。例如，想象一个 AI 客户支持助手正在帮助用户排除软件故障。在 20 次往返对话中，只有少数消息与用户的最新请求直接相关。系统不会将 20 条消息全部输入 LLM（这可能会超过 token 限制），而是选择性地保留：
- 用户最近的问题
- 助手最后的 1–2 次回复
- 一条包含关键上下文的早期消息（例如用户的操作系统版本）

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

新颖性（Recency）（滑动窗口的一种）：优先考虑近期消息以保持相关内容
相关性（Relevance）： 保留与当前查询或任务直接相关的消息（可以通过另一个 LLM 结合特定提示词进行相关性评估）
发送者（Sender）： 仅保留来自特定发送者（用户或其中一个智能体）的消息

过滤器的详细程度取决于聊天窗口中每条消息关联的元数据。例如，我们可以决定只保留用户在过去 5 分钟内发送的消息。所有其他闲聊或冗余问题都被裁剪掉。这确保了模型只关注上下文中最相关的细节。

例如，在在上一个示例中，一组可能的元数据可能如下：

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

摘要： 摘要是将大量的历史记录或冗长的文档浓缩为简洁、集中的观点的过程。这种技术捕捉了要点和关键信息，在保留关键上下文的同时显著减少了所需的 token 数量。

https://github.com/OpenDocCN/freelearn-dl-zh/tree/master/docs/ai-agents-in-practice/img/7c0fff452a128c12d9cc1b782f267ef2_102_0.png

图 4.6：短期记忆消息摘要示例

在实践中，摘要由 LLM 直接生成，并作为参数传递给系统消息的特定，该部分告知代理（agent）如何处理短期记忆。

注意事项

除了我们将要使用的特定技术外，了解何时想要应用该技术也关重要——例如，当短期记忆（STM）的 token 数量达到给定的数量时（我们可以将其设置为接近我们所使用的 LLM 能处理的最大 token 数量）。通过执行 token 检查，我们确保当 token 计数接近限制时，选定的策略（如摘要或消息编辑）会被强制执行。

上述技术是处理 STM 上下窗口的关键；然而，它们可能还不够。事实上，取决于你正在开发的 AI 代理的类型，你可能需要在比用户会话更长的时间内保留和存储工作记忆。

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

存储、检索和刷新记忆

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

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

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

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

长期语义记忆

记忆与上下文管理的性

{
  "user": "Pippo",
  "topic": "bank account",
  "embeddings": [
    [0.2, 0.4, ...],
    ... 
  ]
}

{
  "user": "Pluto",
  "topic": "bank account",
  "embeddings": [
    [0.3, 0.1, ...],
    ... 
  ]
}

{
  "user": "Pippo",
  "topic": "card inquiry",
  "embeddings": [
    [0.9, 0.1, ...],
    ... 
  ]
}

https://github.com/OpenDocCN/freelearn-dl-zh/tree/master/docs/ai-agents-in-practice/img/7c0fff452a128c12d9cc1b782f267ef2_104_0.png

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

一旦隔离了相关的记忆片段，向量相似性搜索就可以根据当前查询呈现出最符合上下文的信息片段。这种分层方法提高了精确性和相关性，能够提供更准确、更个性化的响应。它还通过在调用计算密集密集型向量相似性操作之前缩小搜索空间，来提高性能。

最终，我们需要考虑长期如何管理我们的记忆。在 AI 代理中刷新和更新记忆涉及定期审查和修改存储的知识，以确保其保持相关性、准确性和实用性。这一过程可以是响应性的（由特定的交互或更改触发），也可以是主动的（作为后台任务进行调度）。

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

第 4 章

83

https://github.com/OpenDocCN/freelearn-dl-zh/tree/master/docs/ai-agents-in-practice/img/7c0fff452a128c12d9cc1b782f267ef2_105_0.png

图 4.8：用户会话背景下编辑记忆的示例

另一方面，代理也可以定期审查积累的交互，以精炼摘要、重构配置文件或删除过时的事实。

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

AI 代理中的时间和空间推理

为了让 AI 代理在动态环境中有效运行，它们必须具备理解和推理时间序列和空间上下文的能力。这不仅涉及过去的事件，还涉及根据模式预测未来的发生。让我们来看一些示例：

使用时间序列事件： 时间推理允许代理按时间顺序处理事件，从而理解因果关系并预测后续行动。例如，在客服机器人中，识别用户之前询问过产品的可用性，可以引导代理在未来的交互中主动提供更新或相关信息。

在强化学习场景中，代理从回溯导致成功结果的动作序列中受益，随时间优化其策略。

引用过去的交互： 通过维护交互历史，代理可以个性化响应并保持对话的连续性。这种情景记忆允许更自然、更感知上下文的交互，因为代理可以回忆之前的细节，增强用户体验和信任。
管理时间衰减： 人类倾向于忘记未加强的信息，AI 代理也必须管理存储信息的相关性。实施时间衰减机制可以确保过时或不相关的数据不会占用记忆，从而更高效地处理和检索信息。

以下是管理时间衰减的策略：

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

通过有效管理时间衰减，AI 代理可以在保留有用信息和丢弃无关数据之间取得平衡，提供更准确且符合上下文的响应。

管理记忆的流行工具

第 4 章

流行的 AI 编排器如 LangChain、LangGraph、Semantic Kernel 等提供了预构建库，以便更容易于管理短期内存（STM）和长期内存（LTM）。然而，某些应用程序可能需要复杂的内存管理，仅依赖上述框架可能会变得非常繁琐。

因此，近期发布了许多针对内存的轻量级框架，为开发者为复杂应用提供了稳健的工具包。

让我们来探索三个最流行的框架：LangMem、Mem0 和 MemGPT——它们为增强智能体（Agent）内存提供了不同的方法。

LangMem

LangMem 是在 LangChain 生态系统中开发的一个专用内存管理工具，旨在让开发者对 AI 智能体记忆和检索信息的方式进行细粒度、有目的控制。LangMem 允许将内存视为智能体工作流中活跃的、可编程的部分——特别是在与 LangGraph 使用时。这种集成允许开发者精确指定智能体何时应该向内存写入或从内存读取，例如在决策点、外部 API 调用或用户输入之后。

LangMem 引入了一种内存架构，区分了两种互补的处理模式：热路径（hot path）和后台内存（background memory）。这些模式定义了 AI 智能体何时以及如何存储和处理信息，让开发者能够精确控制内存行为。

图 4.9：Langmem 中的热路径和后台内存。来源：https://langchain.io/langmem/hot_path_quickstart/

热路径指的是在智能体活跃推理过程中写入的内存。换句话说，当智能体与用户交互（回答问题、解决任务、引导工作流）时，它可以意识地决定记住哪些信息。这是通过一个名为 manage_memory 的工具实现的，智能体可以使用自然语言输入来存储有意义的事实、决策或偏好。例如，如果用户说“我更喜欢预约预约”，智能体可以选择立即将该偏好保存到内存中。这些内存被组织在命名空间中——类似于文件夹系统——这样它们就可以被限制到特定的用户、主题或线程。这让开发者对存储什么、存储在哪里以及如何存储有了精确控制。

另一方面，后台内存是被动且异步运行的。这种模式不是由智能体在对话期间触发，而是在后台运行——通常在交互结束后运行。它可以处理整个对话历史以提取摘要、反复出现的主题或有用的元数据，而不会干扰用户的体验。这对于构建长期用户画像或将长交互浓缩为几个易于理解的见解特别有用。可以将其想象为对话后的反思，系统从对话中学习，而不需要被显式告知记住什么。

LangMem 与 LangGraph 框架深度集成，允许开发者构建具有结构化工作流和状态管理的智能体。由于 LangMem 中的内存感知线程的，它会随着对话流进行跟踪，因此智能体不仅能回孤立的事实，还能理解这些事实是在何时以及为何存储的。

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

通过结合热路径和后台内存，LangMem 使智能体能够既有反应性又有反思：能够实时做出智能决策，同时随着时间的推移进行学习和适应。它桥接了短期感知与长期学习，使其成为智能、内存感知智能体的强大基础。

Mem0

Mem0 是一种特殊的内存层，旨在为 AI 智能体提供跨用户和会话保留、适应和个性化行为的能力。

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

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

定义：

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

智能检索系统：Mem0 的混合检索引擎同时使用搜索和基于图的查询来检索最相关的内存。它根据重要性、近期和上下文对信息进行排序，确保智能体根据其内存提供精确且有意义的引用进行回答。
简单的 API 集成：开发者可以通过轻量级 API 轻松集成 Mem0。它提供了用于添加新内存（add）和检索上下文相关内存（search）的直观端点，使得无需深层的基础设施工作即可轻松构建支持内存的智能体。
内存管理：当新信息可用时，Mem0 会更新存储的内存，同时解决冲突和矛盾。这确保了即使用户偏好或事实随时间演变，智能体的内存也能保持一致和可靠。

注意，后一个功能——内存管理——是自适应学习的一个示例。随着智能体与用户的交互，Mem0 赋予了它们动态完善和扩展内存的能力——有效地允许它们在不需要正式重新训练的情况下“学习”。这种能力在智能体需要提供个性化体验的长期部署中特别有利。

总之，Mem0 了 AI 智能体的认知骨干，桥接了短期交互与长期记忆。它对个性化、适应性和灵活部署的强调，使其成为开发者构建不仅仅是做出反应的智能体的理想选择——它们会记忆、进化并深度参与。

LeTTA (原 MemGPT)

Letta——以前名为 MemGPT——是一个用于构建有状态、内存感知智能体的开源框架。它的创新在于如何通过赋予智能体长期记忆、多步推理和自适应上下文管理，将传统的 LLM 交互转换为动态、持续的关系。这意味着基于 Letta 的智能体跨会话记住关键因素、用户偏好和之前的决策——从而随着时间实现真正连贯且个性化的对话。

Letta 设计为与模型无关，允许开发者根据其用例选择最佳模型，而不受限于特定的提供商。Letta 最独特的组件之一是智能体开发环境（ADE），这是一个让开发者能够深度观察智能体状态的图形界面。

通过 ADE，你可以观察智能体是如何推理的、它正在访问什么、以及它是如何响应的——提供了一种在其他框架中很少看到的透明且交互式的调试体验。

从工程角度来看，Letta 是为了稳健性和集成而构建的。它包含了完整的 API 和 SDK 支持（REST、Python 和 TypeScript），使其能够轻松插入新应用程序和现有应用程序中。它的持久层确保了每次交互、内存更新和内部状态转换都安全地存储在 PostgreSQL 数据库中。这不仅保证了会话之间的连续性，还支持审计和分析。

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

第 4 章

89

定义

MCP（模型上下文协议）是一种标准化接口，允许 AI 代理在推理过程中动态地访问、调用和协调外部工具、API 或数据源。它充当了语言模型与可用能力库之间的通信层，使代理能够将其核心功能扩展到文本生成之外。

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

https://github.com/OpenDocCN/freelearn-dl-zh/tree/master/docs/ai-agents-in-practice/img/7c0fff452a128c12d9cc1b782f267ef2_111_0.png

通过结合深度内存集成、灵活的工具化、持久的状态跟踪和透明的可观测性，Letta 成为一个开发真正的自主、感知上下文 AI 代理的综合平台——这些代理会随着每一次交互而变得更聪明、功能更强大。

总结

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

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

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

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

参考文献

语言智能体的认知架构：https://arxiv.org/pdf/2309.02427
什么是AI代理内存？ 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
记忆的类型：https://www.psychologytoday.com/us/basics/memory/types-of-memory?ref=blog.langchain
AI代理中的情节记忆带来了应该被研究和缓解的风险：https://arxiv.org/pdf/2501.11739
使用LangGraph精通长期代理内存： https://saptak.in/writing/2025/03/23/mastering-long-term-agentic-memory-with-langgraph#~:This is precisely the challenge that long-term memory ,primary%20types%20of%20memory%3Asemantic%22episodic%22and%20procedural
从功能机制到转换机会的内存记忆：https://pm.ncbi.nlm.nih.gov/articles/PMC1086701/
AI会忘记人类吗？探索LLM中的内存动态：https://ai.gobubby.com/can-ai-forget-like-humans-exploring-memory-dynamics-in-llms-c7a49678c469
回到未来：迈向大语言模型的可解释时间推理：https://arxiv.org/abs/2310.01074
LangMem：https://github.com/langchain-ai/langmem
MemO：https://github.com/memoai/memo
Letta：https://github.com/letta-ai/letta

订阅免费电子书

新框架、演进中的架构、研究发布、生产拆解——AI_Distilled将噪音过滤掉，为实际操作LLM和生成式AI系统的工程师和研究人员提供每周简报。现在订阅即可获得免费电子书，以及帮助你保持专注并掌握资讯的每周见解。

在https://packt.link/T05B订阅或扫描下方的二维码。

https://github.com/OpenDocCN/freelearn-dl-zh/tree/master/docs/ai-agents-in-practice/img/7c0fff452a128c12d9cc1b782f267ef2_112_0.png

5

工具与外部集成的需求

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

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

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

AI代理工具的解剖结构
硬编码函数和语义函数
API和网络服务
数据库和知识库
同步与异步调用

在本章结束时，你将理解工具如何将LLM转换为能力强大的代理——以及如何为智能系统设计工具。

技术要求

你可以在随附存储库 https://github.com/PacktPublishing/AI-Agents-in-Practice 中访问本章的完整代码。

AI代理工具的解剖结构

正如第2章提到的，在谈论AI代理时，你经常会听到工具（tools）、技能（skills）、函数（functions）和动作（actions）这些术语，指的是同一个概念：即代表用户执行操作的AI系统。为了一致，我们在书中统一使用“工具（tool）”一词。

工具可以通过许多“做事情”的方式有效地赋予代理，正如我们在接下来的章节中看到的。

那么，回到工具的解剖结构：主要成分有哪些？

从高层次来说，工具由以下组件定义：

名称 (Name)：工具的唯一标识符。例如，一个可以在我们的日历中安排预约的工具可以是"CalendarTool"。
描述 (Description)：定义工具的能力。正如本书反复提到的，这个元素是关键。事实上，它将是AI代理大脑——LLM——读取以判断是否调用它（取决于用户的查询），以及如果调用，使用哪些参数。例如，CalendarTool可以具有如下描述：此工具与用户的日历集成，能够读取现有会议、安排新会议，并回顾会议以及任何与日历管理相关的其他活动。
核心逻辑，即工具的正确引擎。例如，CalendarTool将具有不同的方法（获取现有会议、创建新会议等），这些方法可以定义为Python函数。在下面的代码示例中，我们利用Outlook作为日历，这意味着我们需要连接到Microsoft Graph：

def get_outlook_calendar_events(
    access_token: str, date: str = None
):
    """
    使用 Microsoft Graph API 获取指定日的 Outlook 日历事件。
    """
    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/calendareview?"
        f"startTime={start_datetime}&endTime={end_datetime}"
    )

    headers = {
        "Authorization": f"Bearer {access_token}",
        "Content-Type": "application/json"
    }

    response = requests.get(
        url,
        headers=headers
    )

快速贴士： 使用AI代码解释器和快速复制功能来增强您的编码体验。在下一代Packt Reader中打开此书。点击复制按钮 (1) 可以快速地将代码复制到您的编码环境中，或点击解释按钮 (2) 让AI助手向您解释一段代码。

function calculate(a, b) {
  return {sum: a + b};
}

购买本书将免费赠送下一代Packt Reader。扫描二维码并访问packpub.com/unlock，然后使用搜索栏通过名称查找此书。请双击显示的版本，以确保您获取的是正确的版本。

现在，在上述的示例中，工具的核心逻辑是基于API集成——事实上，我们正在使用Microsoft Graph APIs执行操作。然而，当我们谈论AI工具时，它们背后的核心逻辑可能会根据用例和集成需求而异。

在接下来的章节中，我们将检查其中一些工具。

硬编码函数与语义函数

这一类指的是由开发者显式定义的逻辑，可以通过传统的编程结构（硬编码逻辑）或使用自然语言描述（语义函数）来实现。

硬编码函数

硬编码函数是实现在代码中的传统逻辑单元。它们是确定性的且特定于任务，这意味着它们完全按照开发者的指示执行操作。这些函数对于简单的工具、计算、格式化或不需要外部API或学习的业务规则非常理想。

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

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

我们可以通过添加额外的元素（名称和描述）将此函数封装为AI智能体的工具。在可选的各种方法中，我们可以利用LangChain的工具装饰器，它将自动推断出名称和描述（我们将在第6章中详细考虑LangChain的组件和分类）：

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

该工具将使用函数名作为其名称（convert_celsius_to_fahrenheit），并使用文档字符串（docstring）作为其描述。AI智能体在被询问时可以调用它，例如，“20摄氏度是多少华氏度？”

这类硬编码函数速度快、轻量级且不需要外部依赖，是工具逻辑的理想选择。

语义函数

另一方面，语义函数是用自然语言描述，但在底层被映射为代码。它们在Semantic Kernel等框架中特别强大：在该框架中，其分类法是将插件视为一组函数。当涉及到语义插件时，其典型结构如下。

让我们考虑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
Youth.
# F.R.I.D.A.Y. = Female Replacement Intelligent Digital Assistant
# 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.
...

如你所见，在文本文件中没有任何代码；它仅仅是一组缩写词，提供了此特定语义函数的智能体能够以正确的方式生成缩写并对其提供解释（如函数描述中所述）。这里有一个例子：

用户输入：“为一个魔法传送头盔生成一个缩写”
智能体输出（由缩写技能驱动）：“M.A.G.I.C. = Mobile Apparatus for Instantaneous Conveyance”

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

现在，当涉及到将智能体与外部服务集成时，我们需要引入API和Web服务。

API和Web服务

在扩展AI智能体或工具的能力时，API和Web服务在连接语言模型与外部世界方面起着至关重要的作用。

定义

应用程序编程接口（API）是软件应用程序之间通信的一种。它定义了一组规则，规定一个程序如何向另一个程序请求数据或服务——通常通过互联网进行。API随处可见：当你的应用获取天气、加载电子邮件或预订Uber时，它正在使用API。

API通常遵循HTTP协议并使用如下等的方法：

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

这些操作是RESTful API的一部分——这是一种在Web上构建API的流行架构风格。

这些工具充当与实时系统的连接器，允许AI执行操作或从云平台、第三方服务或企业后端检索实时数据。它们本质上弥合了大语言模型（LLM）推理与其运行所需的实时、动态数字环境之间的鸿沟。

请注意，当我们听到“API”时，脑海往往会跳到Google Maps或OpenWeather等Web服务，但并非所有的API都是外部的——某些完全运行在你的应用程序或企业环境中。当你为智能体构建工具或使用语言模型编排工作流时，这种区别非常重要。

Web API

Web API通过互联网上公开（或半公开）的，并且通常属于第三方提供者。它们附带文档、速率限制和访问令牌。

注意

Web API是一种通过HTTP或HTTPS远程可访问的服务，通常通过REST或GraphQL暴露，允许应用程序检索或操作托管在其他处的数据。大多数SaaS平台都提供面向的Web API。

示例包括OpenWeather 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：返回内部定价逻辑

如果你正在为企业构建AI智能体（Agent），你的大多数工具可能都会与内部API接口，而不是外部API。

后端函数API（服务网格或微服务）

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

定义

微服务是一种软件架构风格，它将应用程序拆分为较小的、可独立部署的服务。每个服务执行特定的业务功能，并通过HTTP API等轻量级协议与其他服务进行通信。

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

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

无服务器函数/轻量级API

有时，你需要的API还没有存在。通过Azure Functions、AWS Lambda或Google Cloud Functions等工具，你可以快速创建自己的轻量级HTTP端点，作为动态工具使用。

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

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

一旦你理解了这种模式，可能性就是无限的。以下是API在智能体系统内部可以执行的几个示例：

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

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

| 查询天气 | 获取特定位置的实时天气数据 | OpenWeather API |

| 处理支付 | 接受并处理客户付款 | Stripe API |

| 日历管理 | 读取和更新用户日历 | Microsoft Graph API |

| 内部订单查询 | 从ERP系统检索订单信息 | 内部REST 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 架构。

第 5 章

101

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

AI 是否需要与外部世界通信？Web API。
数据是否被锁在公司防火墙之后？内部 API。
这部分是你应用程序自身的后端逻辑吗？微服务。
需要快速简单的功能吗？无服务器函数。

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

在下一节中，我们将探索另一类工具，它们旨在为你的智能体添加外部知识。

数据库和知识库

正如本书第 1 章所探讨的，在 ChatGPT 发布后，为大语言模型（LLM）添加外部知识是生成式 AI 领域取得的首批里程碑之一。我们看到管理 LLM 外部知识的典型模式是检索增强生成 (RAG)。然而，有两个主要的考虑因素：

数据格式多种多样，而 RAG 通常适用于非结构化数据（文本、图像、音频……）
当涉及到 AI 时，得益于额外的推理层（这是 AI 智能体自身的特性），有方法可以让传统的 RAG 流水变得更加“智能”。

因此，让我们从区分这两类主要数据开始。

结构化数据

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

SQL 查询（SELECT * FROM orders WHERE status = 'pending'）
连接到现有系统的 API 调用（例如 Salesforce、SAP）

第二个示例——连接到现有系统的 API 调用——归结为上一节涵盖的工具类别（API 和 Web 服务）。因此，此后我们将关注通过结构化查询与结构化数据库交互的场景。

在 AI 智能体以及更广泛的 AI 应用背景下，通过自然语言查询实现智能数据库检索的典型模式是“文本转查询”（text-to-query）。

102

工具与外部集成的需求

这些是高级步骤：

用户提问
智能体将问题翻译为 SQL 语句：

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

LLM 返回答案

非结构化数据

这是信息丰富的数据：电子邮件、PDF、转录、聊天日志。在 LLM 的背景下，非结构化数据通常存储在向量数据库中。然而，随着 AI 系统变得智能化，检索的角色必须演进。这种从静态检索到智能检索的转变将 RAG 变为更有目的的行为。

让我们考虑以下示例。我们想要查询：“长新冠的症状有哪些？”在传统的 RAG 场景下，会发生：

输入：用户提交问题。
嵌入和检索：系统将问题转换为向量并在向量数据库中进行相似性搜索。
上下注入：将 3–5 个匹配文档直接传递给模型。
生成：模型根据检索到的文档生成答案。

输出可能是症状的合理总结——但感知文档类型、来源可靠性或地区、日期和患者类型等上下文。

而在智能 RAG 系统中，可能会看到类似的情况：

理解意图：智能体识别出“长新冠”是一个医学术语，且用户正在寻找可靠的临床总结。
工具选择：它评估可用工具，并确定对同行评审医学期刊或官方健康指南进行向量搜索最为合适。
查询优化：智能体将查询重构为“SARS-CoV-2 感染后后遗症（PASC），即长新冠的当前临床症状和影响。”
检索与推理：使用优化后的查询调用向量数据库。如果结果缺少近期研究，智能体可能会带有日期过滤器（例如 2022 年之后）重试，或切换到另一个知识源。
多源合成：智能体汇总相关信息，过滤重复内容，并编写区分常见、罕见和新兴症状的回复。

在这种情况下，结果将是根据用户需求定制的、感知上下文的答案，可能包括“成人与儿童”的区别，或注明最新发现的日期。

104

工具与外部集成的需求

https://github.com/OpenDocCN/freelearn-dl-zh/tree/master/docs/ai-agents-in-practice/img/7c0fff452a128c12d9cc1b782f267ef2_126_0.png

“这是我们可以利用来回答用户查询的临床手册集。”

图 5.1：代理式 RAG 示例

这种方法使得更复杂的交互成为可能，因为向量数据库将成为我们智能体许多可用工具之一。这意味着 AI 智能体可以将检索到的数据与其他工具的输出相结合，或者在向量数据库缺乏必要的领域知识时完全切换工具。通过这样做，检索不再仅仅是一个后端操作，而是智能体更广泛决策循环的一部分。

https://github.com/OpenDocCN/freelearn-dl-zh/tree/master/docs/ai-agents-in-practice/img/7c0fff452a128c12d9cc1b782f267ef2_126_1.png

“这是我们可以利用来回答用户查询的临床手册集。”

图 5.2：包含多个工具（包括作为工具的 VectorDB）的 AI 智能体示例

第 5 章

将向量数据库作为可调用工具，使检索与基于智能体的架构原则保持一致：自主性、适应性和上下文感知。智能体现在不再取决于询问了什么，而是决定什么值得检索——以及为什么要检索。这种增加的智能层不仅提高了响应的准确性和相关性，还为企业级 AI 系统开启了完全新的工作流。

同步调用与异步调用

随着我们构建日益智能的 AI 智能体——即能够推理、计划并与外部工具交互的系统——理解这些工具是如何被调用的变得至关重要。在智能体工具设计中，经常被忽视但至关重要的区别是工具是以同步运行还是异步运行的。

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

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

https://github.com/OpenDocCN/freelearn-dl-zh/tree/master/docs/ai-agents-in-practice/img/7c0fff452a128c12d9cc1b782f267ef2_127_0.png

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

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

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

## Python 中的同步文件读取
with open("report.txt", "r") as file:
    content = file.read()
print("File content loaded.")

在这种情况下，在读取完整个文件之前，程序不会打印“File content loaded”。

另一方面，异步调用是非阻塞的函数调用，它允许程序在操作于后台完成的同时继续执行。当结果就绪时，将根据语言的不同通过回调、事件或承诺/未来器（promises/futures）进行处理。异步编程对于构建响应迅速且可扩展的系统至关重要，特别是必须同时管理多个 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 智能体的语境，同步和异步调用的概念与工具的调用机制紧密相连。

https://github.com/OpenDocCN/freelearn-dl-zh/tree/master/docs/ai-agents-in-practice/img/7c0fff452a128c12d9cc1b782f267ef2_129_0.png

图 5.4：AI 智能体背景下的同步和异步过程示例

在同步过程中，智能体发出请求并在执行任何其他操作之前等待响应。在响应到达之前，它无法继续进行。

在 AI 工作流中，这对于短运行的、可预测的任务通常是必要的，例如以下任务：

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

使用异步调用，智能体发起调用但不会阻塞它；智能体会继续进行，并在结果到达时随时处理结果。

这在执行以下操作时特别有用：

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

异步工具让你的智能体响应更快，并允许它同时处理多件事，提高性能和用户体验。

同步与异步之间的选择不仅仅是一个实现细节——它直接影响你智能体的行为：

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

让我们来看一个场景。假设你的智能体需要总结来自五个区域系统的每周销售报告。同步版本将逐一个获取——耗时是 5 倍。异步版本将一次性获取它们。

@tool
async def fetch_sales_report(region: str) -> str:
    """获取给定区域的销售报告"""
    await asyncio.sleep(2) # 模拟网络延迟
    return f"{region} sales report: $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 和 Semantic Kernel 等框架支持两种模式，通常需要你正确注册工具以便智能体运行时处理它们。

6

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

在之前的章节中，我们探索了 AI 代理（Agents）背后的理论——它们的架构、工具的作用、内存与规划，以及 LangChain 等框架如何实现这些组件的编排。现在，是时候从理论转向实践了。

在本章中，我们将介绍如何使用 LangChain 构建你的第一个 AI 代理。我们将通过一个实际的用例来实现这一点：为一家数字化的披萨店（digital Pineria）创建一个电子商务助手。从理解场景和组装核心构建块，到开发和评估代理的性能，你将获得 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

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-4 作为大语言模型（LLM），其费用为每 100 万 token 输入 2.50 美元，每 100 万 token 输出 10 美元（你可以在此处查看完整页面： https://azure.microsoft.com/en-us/pricing/details/cognitive-services/openai-service/?msockid=12c6546e7da69082d28419716658f0 ）。

如果你想使用免费的 LLM，可以利用 Hugging Face (HF) Hub 及其与 LangChain 的原生集成。安装所需的包：

pip install langchain-huggingface

posted @ 2026-09-25 20:40 绝不原创的飞龙阅读(6) 评论(0) 收藏举报

刷新页面返回顶部

龙哥盟

掠夺·扩张·投机·博弈

AI-Agents-实战-一-

AI Agents 实战（一）

AI Agents 实战

贡献者

关于作者

关于审稿人

订阅获取免费电子书

第 9 章：应对现实 AI 中的伦理挑战 221

安全且伦理 AI 的护栏 235

AI 系统中的内容过滤与审核 237

应对挑战：治理、监管与协作 241

总结 246

你可能喜欢的其他书籍 250

索引 253

前言

本书适用读者

本书涵盖内容

如何充分利用本书

下载示例代码文件

下载彩色图片

使用规范

关于 AI 使用的免责声明

与我们联系

分享你的想法

接入我们的 Discord 和 Reddit 社区

您的书籍附带专属福利 —— 如何解锁它们

解锁您的书籍专属福利

如何通过三个简单步骤解锁这些福利

第 1 步

第 2 步

第 3 步

第 1 部分

AI 工作流的基础与 AI 智能体的崛起

1 生成式 AI 工作流的演变

技术要求

理解基础模型和 LLMs 的崛起

从狭义 AI 到基础模型

定义

每个 LLM 的底层机制

我们如何使用 LLM？

最新重大突破

小语言模型与微调

模型蒸馏

教师模型

学生模型

推理模型

定义

DeepSeek

通 AI 智能体之路

文本生成

生成式 AI 工作流的演变

与你的数据聊天

多模态

十字游戏

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

总结

参考文献

2

AI 代理的崛起

技术要求

从 RPA 到 AI 代理的代理演进

AI 智能体（AI Agent）的演进

强化学习（RL）代理与非 LLM 智能体

基于 LLM 的代理

多智能体系统与自我复制代理

AGI 代理——下一个前沿

AI 代理的组件

注意

如何在自然语言中描述代理人的组件示例

第 2 章

39

自主智能体

备注

总结

参考文献

第 3 章：AI 编排器的必要性

AI 编排器简介

自主性