什么是AI代理

AI代理通过赋予大型语言模型(LLMs) 访问工具和知识的能力来扩展它们的功能，从而使其能够执行操作。AI智能体通常包括：

  • 角色设定（Persona）：定义智能体与用户交互的个性和特征。
  • 工具：智能体能够执行的功能和能力。
  • 技能：智能体拥有的知识和专长。

AI代理的组成部分包括：

  • 环境：AI代理运行的定义空间。例如，旅行预订 AI代理，环境是 AI代理用于完成任务的旅行预订系统。
  • 传感器：环境包含信息并提供反馈。AI代理使用传感器收集并解释关于环境当前状态的信息。在旅行预订代理示例中，旅行预订系统可以提供诸如酒店可用性或航班价格等信息。
  • 执行器：一旦 AI代理接收到环境的当前状态，就会为当前任务确定要执行的操作以改变环境。对于旅行预订代理，可能的操作是为用户预订一个可用的房间。

png

  • 大型语言模型：代理的概念在 LLMs 出现之前就存在（基于规则的邮件过滤系统等）。使用 LLMs 构建 AI代理的优势在于它们解释人类语言和数据的能力。该能力使 LLMs 能够解释环境信息并制定改变环境的计划。
  • 执行操作：LLMs 通过解释用户请求并使用其环境中可用的工具来完成任务。
  • 访问工具：LLM 可访问的工具由 它运行的环境和AI代理的开发者定义。以旅行代理示例为例，代理的工具受限于预订系统中可用的操作，或者开发者可以将代理的工具访问限制为航班。
  • 记忆+知识：在用户与代理的对话上下文中，记忆可以是短期的。从长期来看，除环境提供的信息外，AI代理还可以从其他系统、服务、工具，甚至其他代理中检索知识。在旅行代理示例中，这些知识可能是位于客户数据库中的用户旅行偏好信息。

不同类型的代理

代理类型 描述 示例
简单反射代理 根据预定义规则执行即时操作。 旅行代理解释电子邮件的上下文并将旅行投诉转发给客户服务。
基于模型的反射代理 根据世界模型及对该模型的更改执行操作。 旅行代理基于对历史定价数据的访问，优先考虑价格发生显著变化的路线。
基于目标的代理 通过解释目标并确定实现目标的操作来创建计划。 旅行代理通过确定从当前位置到目的地所需的旅行安排（汽车、公共交通、航班）来预订行程。
基于效用的代理 考虑偏好并以数值方式权衡权衡以确定如何实现目标。 旅行代理在预订旅行时通过权衡便利性与成本来最大化效用。
学习型代理 通过对反馈做出响应并相应调整操作，随时间改进。 旅行代理通过使用行程结束后的客户反馈调查来改进，以便在未来的预订中做出调整。
分层代理 在分层系统中包含多个代理，更高层代理将任务拆分为子任务，由低层代理完成。 旅行代理通过将任务划分为子任务（例如，取消特定预订）并让低层代理完成这些子任务，然后向高层代理报告，从而取消行程。
多代理系统(MAS) 代理独立完成任务，可以是合作的或竞争的。 合作：多个代理分别预订酒店、航班和娱乐等具体旅行服务。竞争：多个代理管理并竞争共享的酒店预订日历，以将客户预订到酒店。

什么时候，怎样使用代理

适用于使用代理的场景：

  • 开放性问题：允许 LLM 确定完成任务所需的步骤，因为这些步骤无法总是硬编码到工作流中。
  • 多步骤流程：需要一定复杂性的任务，AI代理需要在多轮中使用工具或信息，而不是一次性检索。
  • 随时间改进：代理可以通过从其环境或用户处接收反馈随时间改进以提供更好的效用的任务。

代理解决方案

  1. 代理开发：定义工具、操作和行为，如可选择的模型、数据检索工具、API等
  2. 代理模式：使用允许在多个步骤中以更可扩展方式提示 LLM 的代理模式
  3. 代理框架：是为简化 AI代理的创建、部署和管理而设计的软件平台。这些框架为开发人员提供预构建的组件、抽象和工具，从而简化复杂 AI 系统的开发。

代理框架

AI代理框架的一些关键能力：

  • 代理协作与协调：支持创建多个可以协同工作、沟通并协调以解决复杂任务的 AI代理。
  • 任务自动化与管理：提供用于自动化多步骤工作流、任务委派和代理间动态任务管理的机制。
  • 上下文理解与适应：赋予代理理解上下文、适应变化环境并基于实时信息做决策的能力。

如何快速原型、迭代并改进代理的能力？

使用模块化组件

可以快速组合LangChain等SDK提供的组件来创建功能原型，而无需从头开始，从而实现快速试验和迭代。可以使用预构建的解析器从用户输入中提取信息，使用记忆模块存储和检索数据，并使用提示生成器与用户交互，所有这些都不需要你从零构建这些组件。

使用协作工具

可以使用CrewAI、AutoGen、Semantic Kernel等创建可以协同工作的多个代理，形成一个代理团队，每个代理具有专门功能，例如数据检索、分析或决策。这些代理可以相互沟通并共享信息以实现共同目标，例如回答用户查询或完成任务。

实时学习

先进的框架提供实时上下文理解和自适应的能力。

可以实现反馈回路，让代理从交互中学习并动态调整其行为，从而持续改进和完善能力。

代理可以分析用户反馈、环境数据和任务结果来更新其知识库、调整决策算法，并随着时间提升性能。这种迭代学习过程使代理能够适应变化的条件和用户偏好，增强整体系统效果。

设计模式

空间、时间、核心

Agent (Space)

代理运行的环境。这些原则为我们在物理和数字世界中设计代理的方式提供指导。

  • 连接，而不是替代 – 帮助将人们与其他人、事件和可操作的知识连接起来，以促进协作与联系。
  • 代理帮助连接事件、知识和人。
  • 代理将人们拉得更近。它们不旨在取代或贬低人。
  • 易于访问但有时隐形 – 代理在后台运行，仅在相关且合适时提醒我们。
    • 经过授权的用户可以在任何设备或平台上轻松发现并访问代理。
    • 代理支持多模态输入与输出（声音、语音、文本等）。
    • 代理可以根据对用户需求的感知，在前台和后台之间、在主动与被动之间无缝切换。
    • 代理可能以隐形形式运行，但其后台处理路径及与其他代理的协作对用户是透明且可控的。

Agent (Time)

代理随时间运行的方式。这些原则为我们设计在过去、现在和未来交互的代理提供指导。

  • 过去：反思包括状态和上下文的历史。
    • 代理基于对更丰富历史数据的分析（不仅仅是事件、人物或状态）提供更相关的结果。
    • 代理从过去事件创建连接，并主动反思记忆以应对当前情境。
  • 现在：更多的是引导而不是单纯通知。
    • 代理体现了与人互动的全面方法。当事件发生时，代理不仅仅是静态通知或其他形式的形式化。代理可以简化流程或动态生成提示，以在恰当的时刻引导用户的注意力。
    • 代理根据上下文环境、社会和文化变化以及用户意图来提供信息。
    • 代理交互可以是渐进的，随着时间推移逐步演变/变得更复杂，以在长期内赋能用户。
  • 未来：适应与演进。
    • 代理适应各种设备、平台和模态。
    • 代理适应用户行为、无障碍需求，并且可以自由自定义。
    • 代理通过持续的用户交互得到塑造并不断演进。

Agent (Core)

这些是代理设计核心中的关键要素。

  • 接受不确定性但建立信任。
    • 预计代理会存在一定程度的不确定性。不确定性是代理设计的关键要素。
    • 信任与透明是代理设计的基础层。
    • 人类可以控制代理何时开启/关闭，且代理状态在任何时候都应清晰可见。

实施这些原则的指南

  1. 透明性：告知用户 AI 的参与方式、其如何运作（包括过去的行为），以及如何提供反馈和修改系统。
  2. 控制权：使用户能够自定义、指定偏好和个性化，并对系统及其属性（包括“忘记”能力）拥有控制权。
  3. 一致性：在设备和端点之间追求一致的多模态体验。在可能的情况下使用熟悉的 UI/UX 元素（例如用于语音交互的麦克风图标），并尽量降低客户的认知负担（例如，追求简洁响应、视觉辅助和“了解更多”内容）。

如何使用这些原则和指南设计一个旅行代理

以设计一个旅行代理为例，下面是如何考虑使用这些设计原则和指南的方式：

  1. 透明性 – 让用户知道旅行代理是一个启用 AI 的代理。提供一些基本的入门说明（例如，“你好”消息、示例提示）。在产品页面上清楚记录这些内容。显示用户过去询问的提示列表。明确说明如何提供反馈（点赞和点踩、发送反馈按钮等）。明确说明代理是否有使用或主题限制。
  2. 控制权 – 确保清楚说明用户在创建代理后如何通过诸如系统提示之类的方式对代理进行修改。使用户能够选择代理的详细程度、写作风格，以及代理不应讨论的任何注意事项。允许用户查看并删除任何相关文件或数据、提示和过往对话。
  3. 一致性 – 确保“共享提示”、“添加文件或照片”和“标注某人或某物”的图标是标准且易识别的。使用回形针图标表示与代理的文件上传/共享，使用图片图标表示图像上传。

工具使用

工具是代理可以执行的代码，用以完成动作。工具既可以是诸如计算器这样简单的函数，也可以是调用第三方服务的 API，如股票价格查询或天气预报。在 AI代理的上下文中，工具被设计成由代理响应模型生成的函数调用来执行。

工具使用设计模式 专注于赋予大语言模型（LLM）与外部工具交互以实现特定目标的能力。工具是代理可以执行的代码，用以完成动作。工具既可以是诸如计算器这样简单的函数，也可以是调用第三方服务的 API，如股票价格查询或天气预报。在 AI代理的上下文中，工具被设计成由代理响应模型生成的函数调用来执行。

AI代理可以利用工具完成复杂任务、检索信息或做出决策。工具使用设计模式常用于需要动态与外部系统交互的场景，比如数据库、网络服务或代码解释器。该能力适用于多种使用场景，包括：

  • 动态信息检索：代理可以查询外部 API 或数据库以获取最新数据（例如，查询 SQLite 数据库进行数据分析，获取股票价格或天气信息）。
  • 代码执行与解释：代理可以执行代码或脚本以解决数学问题、生成报告或进行模拟。
  • 工作流自动化：通过集成任务调度器、邮箱服务或数据管道等工具，自动化重复或多步骤的工作流程。
  • 客户支持：代理可以与客户关系管理系统（CRM）、工单平台或知识库交互以解决用户问题。
  • 内容生成与编辑：代理可以利用语法检查、文本摘要或内容安全评估等工具辅助内容创作任务。

实现工具使用设计模式需要哪些元素/构建块？

  • 函数/工具模式定义：对可用工具的详细定义，包括函数名、目的、必需参数和预期输出。这些模式使 LLM 能理解可用工具及如何构建有效请求。
  • 函数执行逻辑：根据用户意图和对话上下文决定何时以及如何调用工具。这可能包括规划模块、路由机制或动态决定工具使用的条件流程。
  • 消息处理系统：管理用户输入、LLM 响应、工具调用及工具输出之间的对话流。
  • 工具集成框架：连接代理与各类工具的基础设施，无论是简单函数还是复杂外部服务。
  • 错误处理与验证：处理工具执行失败、验证参数和应对意外响应的机制。
  • 状态管理：跟踪对话上下文、之前的工具交互及持久数据，确保多轮交互中的一致性。

代理检索增加生成

代理式检索增强生成（Agentic RAG）是一种新兴的AI范式，在此范式中，大型语言模型（LLMs）能够自主规划下一步操作，同时从外部来源获取信息。与静态的先检索后阅读模式不同，代理式RAG中，LLM通过迭代调用，穿插工具或函数调用及结构化输出。系统对结果进行评估，优化查询，必要时调用额外工具，并不断循环直到达到满意的解决方案。这种迭代的“制作者-检查者”模式提升了准确性，处理了格式错误的查询，确保高质量结果。

Agentic RAG核心循环：

png

Agentic RAG工具集成：

png

Agentic RAG自我纠正：

png

代理的边界

尽管任务中具有自主性，代理式RAG并不等同于通用人工智能。其“代理”能力受限于开发者提供的工具、数据源和策略。它不能自行发明工具或突破设定的领域边界，而是擅长动态编排现有资源。

  1. 领域特定自主性： 代理式RAG系统聚焦于在已知领域内实现用户定义目标，使用如查询重写或工具选择等策略提升结果。
  2. 基础设施依赖： 系统能力依赖开发者整合的工具和数据，无法无人工干预跨越这些界限。
  3. 遵守防护措施： 道德规范、合规规则和业务政策极为重要。代理的自由始终受限于安全措施和监管机制（希望如此？）

实际使用案例与价值

代理式RAG在需要迭代优化和精准性的场景中表现出色：

  1. 优先正确性环境： 如合规检查、监管分析或法律研究，代理模型可反复验证事实，咨询多方来源，重写查询直至给出充分审查答案。
  2. 复杂数据库交互： 处理结构化数据时，查询常常失败或需调整，系统能自主细化查询，确保最终检索符合用户意图。
  3. 延伸工作流程： 长时会话可能随着新信息出现不断演变。代理式RAG可持续融合新数据，随着对问题域理解深入调整策略。

治理、透明度与信任

随着系统推理自主性增强，治理与透明度尤为关键：

  • 可解释推理： 模型可提供查询轨迹、咨询的来源及推理步骤的审计日志。GenAIOps等工具有助于保持透明并降低风险。
  • 偏差控制与均衡检索： 开发者可调优检索策略，确保考虑到均衡、具有代表性的数据源，定期审计输出，检测偏差或失衡模式。
  • 人工监管与合规： 对于敏感任务，人工复核仍不可或缺。代理式RAG不是取代人工判断，而是通过提供更详实审核的选项增强其能力。

可信代理

了解威胁

为了构建可信赖的 AI代理，重要的是了解和减轻 AI代理面临的风险和威胁。

一些针对 AI代理的不同威胁：

  • 任务与指令

描述: 攻击者试图通过提示或操控输入更改 AI代理的指令或目标。

缓解措施: 执行验证检查和输入过滤，以检测潜在危险提示，防止其被 AI代理处理。由于此类攻击通常需要频繁与代理交互，限制对话轮数是预防这类攻击的另一种方式。

  • 访问关键系统

描述: 如果 AI代理可访问存储敏感数据的系统和服务，攻击者可通过代理与这些服务之间的通信进行攻击。这些攻击可能是直接的，也可能是通过代理尝试间接获取这些系统信息。

缓解措施: AI代理应仅在必要时访问系统，以防止此类攻击。代理与系统之间的通信也应保证安全。实施身份验证和访问控制是保护此类信息的另一个方法。

  • 资源和服务过载

描述: AI代理访问不同工具和服务以完成任务。攻击者可能利用此能力通过 AI代理发送大量请求攻击这些服务，可能导致系统故障或高昂费用。

缓解措施: 实施策略限制 AI代理对服务的请求次数。限制与 AI代理的对话轮数和请求次数是防止此类攻击的另一方式。

  • 知识库投毒

描述: 此类攻击不是直接针对 AI代理，而是针对 AI代理将使用的知识库和其他服务。攻击可能通过破坏 AI代理用于完成任务的数据或信息，导致向用户提供带偏见或非预期的响应。

缓解措施: 定期核查 AI代理在工作流程中使用的数据。确保对此数据的访问安全，仅由可信人员更改，以避免此类攻击。

  • 级联错误

描述: AI代理访问各种工具和服务以完成任务。攻击者造成的错误可能导致 AI代理连接的其他系统失败，使攻击范围扩大且更难排查。

缓解措施: 避免此类情况的一种方法是让 AI代理在有限环境中运行，例如在 Docker 容器中执行任务，防止对系统的直接攻击。创建回退机制和在某些系统返回错误时的重试逻辑是防止更大系统故障的另一方式。

  • 人类参与环节

构建可信赖的 AI代理系统的另一有效方法是使用人类参与环节。这种方法创建了一个流程，用户可以在运行过程中向代理反馈。用户本质上作为多代理系统中的代理，提供对运行过程的批准或终止。

png

规划设计

多数现实任务复杂，无法一步完成。如何构建一个规划者动态选择可用代理。规划者输出分解任务并分配代理以执行？

AI代理需要一个简明目标来指导其规划和行动。大型或复杂任务在分解为较小的、面向目标的子任务后更易管理。每个子任务可以由专门的代理或流程处理。大型语言模型（LLMs）可生成结构化输出（如 JSON），使下游代理或服务更易解析和处理。这在多代理环境中特别有用，我们可以在收到规划输出后执行相应任务。

png

迭代规划

部分任务需反复沟通或重新规划，一个子任务的结果会影响下一个。例如，若代理在预订机票时发现意外的数据格式，则可能需要调整策略后再进行酒店预订。此外，用户反馈（如用户偏好提前航班）可触发局部重新规划。这种动态迭代的方法保证最终方案符合真实限制和不断变化的用户偏好。

多代理

多智能体适用场景

  • 大工作负载：将大任务拆分成小任务，分配给不同智能体，实现并行处理，加快完成速度。例如大型数据处理任务。
  • 复杂任务：复杂任务也可以拆分成多个子任务，由不同智能体负责各个具体方面。例如自动驾驶汽车中，不同智能体负责导航、障碍检测及与其它车辆通信。
  • 多样专长：不同智能体具备多样专长，更有效地处理任务不同方面。比如医疗领域，智能体分别管理诊断、治疗方案和患者监护。

使用多智能体优于单一智能体的优势

  • 专门化：每个智能体专攻特定任务。单一智能体因缺乏专门化，面对复杂任务时可能混淆、执行不擅长的任务。
  • 可扩展性：通过增加更多智能体扩展系统更加容易，而不是让单个智能体超负荷。
  • 容错性：某智能体失败时，其他智能体仍能继续工作，确保系统可靠。

实现多智能体设计模式的构建模块

在实现多智能体设计模式前，需了解构成该模式的模块。以为用户订旅行为例，构建模块包括：

  • 智能体通信：负责查航班、订酒店和租车的智能体需沟通用户偏好和限制。需要决定通信协议和方法。具体来说，查航班智能体需与订酒店智能体交流，保证酒店预订与航班日期一致。即需决定哪些智能体共享信息以及如何共享。
  • 协调机制：智能体须协调行动，满足用户偏好和限制。比如用户偏好酒店靠近机场，而限制是租车只能在机场拿车。订酒店智能体与租车智能体相互协调，满足这些需求。即需决定智能体如何协调行动。
  • 智能体架构：智能体内部须具备决策功能，能从与用户互动中学习。查航班智能体需根据用户历史偏好决策推荐航班。即需决定智能体如何决策和学习。例如，查航班智能体可用机器学习模型基于用户过往偏好进行推荐。
  • 多智能体交互可见性：需要有工具和技术监控多个智能体的活动和交互，如日志监控、可视化工具和性能指标。
  • 多智能体模式：有集中式、分布式和混合架构等不同实现模式，需选择最合适的模式。
  • 人工介入：通常系统中有人类介入环节，需要指示智能体何时请求人工干预。例如，用户要求指定未推荐的酒店或航班，或预订前要求确认。

多智能体交互的可见性

了解多个智能体之间如何交互非常重要，有助于调试、优化和保障系统效果。为此需有跟踪智能体活动和交互的工具，如日志监控、可视化工具和性能指标。

  • 日志和监控工具：每个智能体的操作都应记录日志，日志包含操作智能体、执行动作、动作发生时间及结果，便于调试与优化。
  • 可视化工具：用图形化方式展示智能体间信息流，直观揭示瓶颈、低效等问题。
  • 性能指标：追踪多智能体系统绩效，如完成任务所需时间、单位时间完成任务数量及推荐准确性，指导改进和优化。

多智能体模式

以下是一些可用于构建多智能体应用的具体模式，值得考虑：

群聊模式

当需要创建多智能体相互通信的群聊应用时适用。典型场景包括团队协作、客户支持和社交网络。该模式中，每个智能体代表群聊中的一个用户，采用消息协议交换消息。智能体可以发送、接收并响应群聊消息。可采用集中式架构（所有消息通过中央服务器传递）或分布式架构（消息直接交换）。

png

任务交接模式

适合创建多个智能体之间能够相互交接任务的应用。典型应用包括客户支持、任务管理和工作流自动化。每个智能体表现为任务或工作流中的一步，按照预定义规则向其他智能体交接任务。

png

协同过滤模式

用于多个智能体合作向用户推荐内容的应用。使用多个智能体参与推荐因各智能体具备不同专长，能从不同角度贡献。举例：用户需要买股票推荐。

  • 行业专家：一智能体专研某行业。
  • 技术分析：另一智能体擅长技术分析。
  • 基本面分析：再一智能体负责基本面分析。通过协作，提供更全面推荐。

png

场景：退款流程

假设客户申请产品退款，过程中可能涉及多个智能体，分为退款特定智能体和业务通用智能体。

退款特定智能体：

  • 客户智能体：代表客户，负责发起退款流程。
  • 卖家智能体：代表卖家，负责处理退款。
  • 支付智能体：管理支付过程，负责退款执行。
  • 解决智能体：负责处理退款过程中产生的问题。
  • 合规智能体：确保退款流程符合规章政策。

元认知

元认知指的是涉及思考自身思维的高级认知过程。对于AI智能体来说，这意味着它们能够基于自我意识和过去经验评估和调整其行动。元认知，或称“对思考的思考”，是构建具备智能行为的AI系统的重要概念。它涉及AI系统意识到自身内部过程，并能够监控、调节及适应其行为。就像我们在判断环境氛围或面对问题时所做的那样。这种自我意识可以帮助AI系统做出更好的决策，识别错误，并随着时间推移提升性能——这再次关联到图灵测试以及围绕AI是否会取代人类的争论。

在具有智能体特性的AI系统中，元认知有助于解决若干挑战，例如：

  • 透明性：确保AI系统能够解释其推理和决策过程。
  • 推理能力：增强AI系统整合信息和做出合理决策的能力。
  • 适应性：使AI系统能够适应新环境和变化的条件。
  • 认知感知：提高AI系统识别和解释环境数据的准确性。

元认知的作用：

  • 自我反思：智能体可以评估自身表现并识别改进空间。
  • 适应能力：智能体基于过往经验和环境变化调整策略。
  • 错误校正：智能体能够自主检测并修正错误，提升准确性。
  • 资源管理：智能体通过规划和评估行动，优化时间与计算资源的使用。

智能体中的规划

规划是AI智能体行为的核心部分。它涉及规划实现目标所需步骤，同时考虑当前状态、资源及可能障碍。规划要素：

  1. 当前任务：明确任务定义。
  2. 完成任务的步骤：将任务拆解为易管理的步骤。
  3. 所需资源：识别必要资源。
  4. 经验：运用过往经验指导规划。

纠正型RAG系统

纠正型RAG方法侧重于利用RAG技术纠正错误并提升AI智能体的准确性。主要涉及：

  1. 提示技巧：使用特定提示引导智能体检索相关信息。
  2. 工具：实现算法和机制，使智能体评估检索信息的相关性并生成准确回答。
  3. 评估：持续评估智能体表现，进行调整以提升准确度和效率。

示例：考虑一个从网络检索信息以回答用户查询的搜索智能体。纠正型RAG方法可能包括：

  1. 提示技巧：基于用户输入制定搜索查询。
  2. 工具：使用自然语言处理及机器学习算法排序和筛选搜索结果。
  3. 评估：分析用户反馈，识别并纠正检索信息中的不准确部分。

评估相关性

评估相关性是 AI代理性能的关键环节。它确保代理检索和生成的信息适当、准确且对用户有用。

评估相关性的关键概念

  1. 上下文感知：
    • 代理必须理解用户查询的上下文，以检索和生成相关信息。
    • 示例：当用户查询“巴黎最佳餐厅”时，代理应考虑用户偏好，比如料理类型和预算。
  2. 准确性：
    • 代理提供的信息应事实准确且最新。
    • 示例：推荐当前营业且评价良好的餐厅，而非过时或已关闭的选项。
  3. 用户意图：
    • 代理需推断用户查询背后的意图，提供最相关信息。
    • 示例：用户问“经济实惠的酒店”，代理应优先推荐价格合理的选项。
  4. 反馈循环：
    • 持续收集并分析用户反馈，有助于代理优化其相关性评估过程。
    • 示例：结合用户对以往推荐的评分与反馈，改进未来响应。

目标导向搜索

目标导向搜索涉及理解和解析用户查询背后的目的或目标，以检索和生成最相关且有用的信息。这一方法超越了简单关键词匹配，更注重把握用户的实际需求和上下文。

目标导向搜索的关键概念

  1. 理解用户意图：
    • 用户意图通常分为三类：信息型、导航型和事务型。
      • 信息型意图：用户寻求某个主题的信息（如“巴黎最佳博物馆有哪些？”）。
      • 导航型意图：用户想访问特定网站或页面（如“卢浮宫官方网站”）。
      • 事务型意图：用户希望完成某种事务，如订机票或购物（如“预订去巴黎的机票”）。
  2. 上下文感知：
    • 分析用户查询的上下文，有助于准确识别意图，包括考虑之前交互、用户偏好和当前查询的具体细节。
  3. 自然语言处理（NLP）：
    • 利用 NLP 技术理解和解析用户的自然语言查询，包括实体识别、情感分析和查询解析等任务。
  4. 个性化：
    • 基于用户历史、偏好和反馈个性化搜索结果，提高信息相关性。

代码生成代理

代码生成代理使用生成式 AI 模型编写和执行代码。这些代理可以通过生成并运行各种编程语言的代码来解决复杂问题、自动化任务并提供有价值的见解。

实际应用

  1. 自动代码生成：为特定任务生成代码片段，如数据分析、网络爬取或机器学习。
  2. SQL 作为 RAG：使用 SQL 查询从数据库中检索和操作数据。
  3. 问题解决：创建并执行代码解决特定问题，如优化算法或分析数据。

示例：用于数据分析的代码生成代理

假设正在设计一个代码生成代理。它的工作流程可能是：

  1. 任务：分析数据集以识别趋势和模式。
  2. 步骤：
    • 将数据集加载到数据分析工具中。
    • 生成 SQL 查询以过滤和聚合数据。
    • 执行查询并获取结果。
    • 使用结果生成可视化和见解。
  3. 所需资源：数据集访问权限、数据分析工具和 SQL 能力。
  4. 经验：利用过去的分析结果提升未来分析的准确性和相关性。

利用环境感知和推理

基于表的架构确实可以通过利用环境感知和推理增强查询生成过程。

以下是如何实现的示例：

  1. 理解架构：系统将理解表的架构并利用这些信息来指导查询生成。
  2. 基于反馈调整：系统会基于反馈调整用户偏好，并推理哪些架构字段需要更新。
  3. 生成并执行查询：系统基于新的偏好生成并执行查询以获取更新的航班和酒店数据。

使用 SQL 作为检索增强生成 (RAG) 技术

SQL（结构化查询语言）是与数据库交互的强大工具。作为检索增强生成 (RAG) 方法的一部分，SQL 可以从数据库中检索相关数据，为 AI代理生成响应或行为提供信息。

关键概念

  1. 数据库交互：
    • 使用 SQL 查询数据库，检索相关信息并操作数据。
    • 示例：从旅行数据库中获取航班详情、酒店信息和景点。
  2. 与 RAG 的集成：
    • 根据用户输入和偏好生成 SQL 查询。
    • 检索的数据用来生成个性化推荐或行为。
  3. 动态查询生成：
    • AI代理基于上下文和用户需求生成动态 SQL 查询。
    • 示例：根据预算、日期和兴趣定制 SQL 查询筛选结果。

应用

  • 自动代码生成：生成针对特定任务的代码片段。
  • SQL 作为 RAG：使用 SQL 查询操作数据。
  • 问题解决：创建并执行代码解决问题。

部署代理到生产环境

跟踪（Trace）:表示从开始到结束的完整代理任务（例如处理一个用户查询）。

与跨度（Span）:是跟踪中的单个步骤（例如调用语言模型或检索数据）。

为什么在生产环境中可观测性很重要

将 AI代理迁移到生产环境会引入一系列新的挑战和要求。可观测性不再是“可有可无”的，而是一项关键能力：

  • 调试与根因分析：当代理失败或产生意外输出时，可观测性工具提供的跟踪可帮助定位错误根源。这在可能涉及多个 LLM 调用、工具交互和条件逻辑的复杂代理中尤其重要。
  • 延迟与成本管理：AI代理通常依赖按 token 或按调用计费的 LLM 和其他外部 API。可观测性可以精确跟踪这些调用，帮助识别过慢或过于昂贵的操作。这使团队能够优化提示、选择更高效的模型或重新设计工作流，以管理运营成本并保证良好用户体验。
  • 信任、安全与合规：在许多应用中，确保代理的行为安全且符合伦理非常重要。可观测性提供了代理行为和决策的审计轨迹。这可用于检测和缓解提示注入、有害内容生成或个人身份信息（PII）处理不当等问题。例如，你可以审查跟踪以了解代理为何给出某个响应或使用特定工具。
  • 持续改进循环：可观测性数据是迭代开发流程的基础。通过监控代理在真实世界的表现，团队可以识别改进点、收集用于微调模型的数据，并验证变更的影响。这创建了一个反馈循环：来自在线评估的生产洞察用于指导离线实验和改进，从而逐步提升代理性能。

需要跟踪的关键指标

为了监控和理解代理行为，应跟踪一系列指标和信号。具体指标可能会根据代理的用途而有所不同，但有些是普遍重要的。下面是可观测性工具通常监控的一些常见指标：

延迟： 代理响应的速度有多快？长时间等待会对用户体验产生负面影响。你应通过跟踪代理运行来衡量任务和各个步骤的延迟。例如，一个所有模型调用总共需要 20 秒的代理，可以通过使用更快的模型或并行运行模型调用来加速。

成本： 每次代理运行的费用是多少？AI代理依赖按 token 或外部 API 调用计费的 LLM。频繁使用工具或多次提示会迅速增加成本。例如，如果代理调用 LLM 五次只换来边际质量提升，那么你必须评估成本是否合理，或是否可以减少调用次数或使用更便宜的模型。实时监控还可以帮助识别意外激增（例如导致过度 API 循环的 bug）。

请求错误： 代理失败的请求有多少？这可以包括 API 错误或工具调用失败。为了让代理在生产环境中更健壮，你可以设置回退或重试。例如，如果 LLM 提供商 A 出现故障，你可以切换到 LLM 提供商 B 作为备用。

用户反馈： 实施直接的用户评估能提供有价值的洞察。这可以包括明确的评分（👍/👎、⭐1-5 星）或文本评论。持续的负面反馈应引起你的注意，因为这表明代理没有按预期工作。

隐式用户反馈： 即使没有明确评分，用户行为也能提供间接反馈。这可以包括立即重新措辞问题、重复查询或点击重试按钮。例如，如果你发现用户反复提出相同的问题，这表明代理没有按预期工作。

准确性： 代理生成正确或期望输出的频率如何？准确性的定义各不相同（例如问题求解正确性、信息检索准确性、用户满意度）。第一步是定义你的代理的成功标准。你可以通过自动化检查、评估分数或任务完成标签来跟踪准确性。例如，将跟踪标记为“成功”或“失败”。

自动化评估指标： 你也可以设置自动评估。例如，你可以使用 LLM 为代理的输出打分，如判断其是否有帮助、是否准确等。也有若干开源库可以帮助评估代理的不同方面，例如用于 RAG 代理的 RAGAS 或用于检测有害语言或提示注入的 LLM Guard。

要收集跟踪数据，需要对代码进行埋点/监控。目标是为代理代码添加埋点，使其发出可被可观测性平台捕获、处理和可视化的跟踪和指标。OpenTelemetry (OTel)已成为 LLM 可观测性的行业标准。它提供了一套用于生成、收集和导出遥测数据的 API、SDK 和工具。

代理评估

可观测性为我们提供了指标，但评估是分析这些数据（并执行测试）以判断 AI代理表现如何及如何改进的过程。换句话说，一旦你有了这些跟踪和指标，如何利用它们来评判代理并做出决策？

定期评估很重要，因为 AI代理通常是非确定性的并且会随时间演变（通过更新或模型行为漂移）——如果没有评估，你无法知道你的“智能代理”是否真正完成了它的工作，或是否出现了回归。

AI代理的评估可分为两类：在线评估和离线评估。两者都很有价值，且互为补充。我们通常先从离线评估开始，因为这是部署任何代理前的最低必要步骤。

成本管理

以下是一些管理将 AI代理部署到生产环境成本的策略：

Using Smaller Models: 小型语言模型 (SLMs) 在某些代理化用例中可以表现良好，并能显著降低成本。如前所述，构建一个评估系统以确定并比较与更大型模型的性能，是了解 SLM 在特定用例中表现的最佳方式。考虑在更简单的任务（如意图分类或参数提取）中使用 SLMs，同时将更大型模型保留用于复杂推理。

Using a Router Model: 类似的策略是使用不同种类和规模的模型。您可以使用 LLM/SLM 或无服务器函数，根据请求的复杂性将请求路由到最合适的模型。这同样有助于降低成本，同时确保在适当的任务上获得良好性能。例如，将简单查询路由到更小、更快速的模型，只有在复杂推理任务时才使用昂贵的大模型。

Caching Responses: 识别常见请求和任务，并在它们通过您的代理化系统之前提供响应，是减少类似请求数量的好方法。您甚至可以实现一个流程，使用更基础的 AI 模型来识别一个请求与缓存请求的相似程度。对于常见问题或常见工作流，这一策略可以显著降低成本。

代理协议（MCP、A2A 和 NLWeb）

模型上下文协议（MCP）

png

  • 动态工具发现：代理可以动态接收来自服务器的可用工具列表以及它们的功能说明。这与传统 API 不同，传统 API 往往需要静态编码集成，任何 API 更改都会需要代码更新。MCP 提供“一次集成”的方法，从而具有更高的适应性。
  • 跨 LLM 的互操作性：MCP 可在不同的 LLM 之间工作，提供灵活性以切换核心模型以评估更好的性能。
  • 标准化安全：MCP 包含标准的身份验证方法，在添加对额外 MCP 服务器的访问时提高了可扩展性。这比管理不同的密钥和各种传统 API 的身份验证类型更简单。

代理到代理（A2A)

代理到代理（A2A）协议 更进一步，使不同 AI代理之间能够通信与协作。A2A 将来自不同组织、环境和技术栈的 AI代理连接起来，以完成共享任务。

png

  • 增强的协作：它使来自不同供应商和平台的代理能够交互、共享上下文并协同工作，促进跨传统上不连通的系统的无缝自动化。
  • 模型选择灵活性：每个 A2A 代理可以决定用于服务其请求的 LLM，允许为每个代理使用优化或微调的模型，这不同于某些 MCP 场景中的单一 LLM 连接。
  • 内置身份验证：身份验证直接集成到 A2A 协议中，为代理交互提供了强健的安全框架。

自然语言网页（NLWeb）

png

上下文工程

对于 AI代理来说，上下文是驱动代理规划采取特定动作的要素。上下文工程是确保 AI代理拥有完成下一个任务步骤所需正确信息的实践。上下文窗口是有大小限制的，因此作为代理构建者，我们需要构建系统和流程来管理在上下文窗口中添加、移除和压缩信息。

Prompt Engineering vs Context Engineering

提示工程侧重于一组静态指令，以一套规则有效地引导 AI代理。上下文工程则是如何管理一组动态信息（包括初始提示），以确保 AI代理随着时间推移拥有所需的信息。围绕上下文工程的主要思想是使这一过程可重复且可靠。

AI代理可能需要管理的上下文类型包括：

指令： 像代理的“规则”——提示、系统消息、少样本示例（向 AI 展示如何执行某事）以及可使用工具的描述。这里是提示工程与上下文工程结合的重点。

知识： 涵盖事实、从数据库检索的信息或代理积累的长期记忆。如果代理需要访问不同的知识库和数据库，这包括整合检索增强生成 (RAG) 系统。

工具： 代理可以调用的外部函数、API 和 MCP 服务器的定义，以及使用它们所得到的反馈（结果）。

对话历史： 与用户的持续对话。随着时间推移，这些对话会变得更长更复杂，从而占据上下文窗口的空间。

用户偏好： 随时间收集到的关于用户喜好或不喜好的信息。这些可以被存储并在做出关键决策时调用以帮助用户。

良好的上下文工程始于良好的规划。以下方法将帮助你开始思考如何应用上下文工程概念：

  1. 定义清晰的结果 - 分配给 AI代理的任务结果应明确定义。回答问题——“当 AI代理完成任务时，世界会是什么样子？” 换句话说，用户在与 AI代理交互后应该获得什么改变、信息或回应。
  2. 绘制上下文地图 - 一旦定义了 AI代理的结果，就需要回答“AI代理为了完成此任务需要哪些信息？”。这样你就可以开始映射这些信息可能存放的位置。
  3. 创建上下文管道 - 既然你知道了信息在哪里，就需要回答“代理将如何获取这些信息？”。这可以通过多种方式完成，包括 RAG、使用 MCP 服务器和其他工具。

规划很重要，但一旦信息开始流入我们代理的上下文窗口，我们需要有实际策略来管理它：

Managing Context

虽然一些信息会自动添加到上下文窗口，但上下文工程更强调主动管理这些信息，可以通过以下几种策略来实现：

Agent Scratchpad:允许 AI代理在单次会话期间记录与当前任务和用户交互相关的重要信息。它应存在于上下文窗口之外的文件或运行时对象中，代理在需要时可以在此会话内检索。

Memories：草稿本适合管理单次会话上下文窗口之外的信息。记忆使代理能够在多次会话间存储和检索相关信息。这可能包括摘要、用户偏好和用于未来改进的反馈。

Compressing Context：一旦上下文窗口增长并接近其限制，可以使用摘要和修剪等技术。这包括只保留最相关的信息或删除较旧的消息。

Multi-Agent Systems：开发多代理系统是一种上下文工程形式，因为每个代理都有自己的上下文窗口。构建这些系统时，需要规划如何共享和传递这些上下文。

Sandbox Environments：如果代理需要运行一些代码或处理文档中的大量信息，这可能需要大量 token 来处理结果。代理可以使用沙箱环境来运行这些代码，仅读取结果和其他相关信息，而不是将所有这些内容存储在上下文窗口中。

Runtime State Objects：通过创建信息容器来管理当代理需要访问特定信息的情况。对于复杂任务，这将使代理能够逐步存储每个子任务的结果，从而让上下文仅与该特定子任务保持关联。

Common Context Failures

Context Poisoning

是什么： 当幻觉（LLM 生成的错误信息）或错误进入上下文并被反复引用，导致代理追求不可能的目标或制定荒谬策略时，就会发生上下文中毒。

如何处理： 实施 上下文验证 和 隔离。在将信息添加到长期记忆之前进行验证。如果检测到潜在的中毒，启动新的上下文线程以防止错误信息传播。

旅行订票示例： 你的代理幻想出一趟 从某个小型本地机场直飞到远方国际城市，而该机场实际上并不提供国际航班。这个不存在的航班细节被保存到上下文中。后来，当你要求代理预订时，它不停地试图为这条不可能的路线找票，导致反复出错。

解决方案： 在将航班细节添加到代理的工作上下文之前，实施一步 使用实时 API 验证航班存在性和航线。如果验证失败，则将错误信息“隔离”并不再使用。

Context Distraction

是什么： 当上下文变得非常庞大时，模型可能过于关注累积的历史，而不是利用训练中学到的内容，导致重复或无用的行为。模型甚至可能在上下文窗口未满之前就开始犯错。

如何处理： 使用 上下文摘要。定期将累积的信息压缩为更短的摘要，保留重要细节并删除冗余历史。这有助于“重置”关注点。

旅行订票示例： 你长时间讨论过多种梦想旅行目的地，包括两年前一次背包旅行的详细叙述。当你最终要求 “帮我找下个月的廉价机票” 时，代理被旧的无关细节拖住，不断询问你的背包装备或过去的行程，而忽视了你当前的请求。

解决方案： 在达到一定轮次或上下文变得过大时，代理应 总结最近且相关的对话部分——聚焦于你当前的旅行日期和目的地——并在下一次 LLM 调用时使用该压缩后的摘要，丢弃不太相关的历史聊天。

Context Confusion

是什么： 当不必要的上下文（通常表现为过多可用工具）导致模型生成糟糕的响应或调用无关工具时发生。较小的模型尤其容易出现这种情况。

如何处理： 使用 RAG 技术实施 工具载入管理。将工具描述存储在向量数据库中，并仅为每个具体任务选择最相关的工具。研究表明将工具选择限制在 30 个以下是有效的。

旅行订票示例： 你的代理可以访问数十个工具：book_flight、book_hotel、rent_car、find_tours、currency_converter、weather_forecast、restaurant_reservations 等。你问，“在巴黎出行最好的方式是什么？” 由于工具数量庞大，代理感到困惑，尝试在巴黎内部调用 book_flight，或者即便你偏好公共交通也调用 rent_car，因为工具描述可能重叠或它根本无法辨别最佳选项。

解决方案： 对工具描述使用 RAG。当你询问如何在巴黎出行时，系统基于你的查询动态检索 仅 最相关的工具，如 rent_car 或 public_transport_info，向 LLM 提供一个聚焦的“工具载入”。

Context Clash

是什么： 当上下文中存在冲突信息时，会导致不一致的推理或糟糕的最终响应。这通常发生在信息分阶段到达，而早期的错误假设仍保留在上下文中。

如何处理： 使用 上下文修剪 和 外卸。修剪意味着在新细节到来时移除过时或冲突的信息。外卸则为模型提供一个单独的“草稿区”以处理信息，而不会弄乱主上下文。

旅行订票示例： 你最初告诉代理，“我想坐经济舱。” 后来在对话中你改变了主意，说，“实际上，这次我们坐商务舱吧。” 如果两条指示都保留在上下文中，代理可能会收到冲突的搜索结果或对优先考虑哪条偏好感到困惑。

解决方案： 实施 上下文修剪。当新指令与旧指令矛盾时，旧指令应从上下文中移除或被明确覆盖。或者，代理可以使用 草稿区 来调和冲突偏好，然后再决定，确保只有最终一致的指令指导其行动。

代理记忆

AI代理的记忆指允许它们保留和回忆信息的机制。这些信息可以是关于对话的具体细节、用户偏好、过去的行动，甚至是学到的模式。

为什么记忆重要？

代理的智能与其回忆和利用过去信息的能力密切相关。记忆使代理能够：

反思：从过去的行动和结果中学习。

交互性：在正在进行的对话中保持上下文。

前瞻性和反应性：基于历史数据预测需求或做出适当回应。

自主性：通过调用存储的知识更独立地运行。

实现记忆的目标是使代理更加可靠和有能力。

记忆类型

  1. 工作记忆

将其视为代理在单个正在进行的任务或思考过程中使用的一张草稿纸。它保存计算下一步所需的即时信息。

对于 AI代理，工作记忆通常捕获对话中最相关的信息，即使完整的聊天记录很长或被截断。它侧重于提取关键要素，如需求、建议、决策和操作。

工作记忆示例

在旅行预订代理中，工作记忆可能会捕获用户当前的请求，例如“我想预订去巴黎的行程”。这一具体需求被保存在代理的即时上下文中，以指导当前交互。

  1. 短期记忆

这种记忆在单次对话或会话期间保留信息。它是当前聊天的上下文，允许代理回溯对话中的先前轮次。

短期记忆示例

如果用户问：“去巴黎的机票大概多少钱？”然后跟进问：“那里的住宿呢？”，短期记忆确保代理知道“那里”在同一对话中指的是“巴黎”。

  1. 长期记忆

这是跨多个对话或会话持续存在的信息。它允许代理记住用户偏好、历史交互或长期的常识知识。这对个性化很重要。

长期记忆示例

长期记忆可能会存储“Ben 喜欢滑雪和户外活动，喜欢在有山景的咖啡馆喝咖啡，并且因过去受伤而想避免高级滑雪道”等信息。这些从先前交互中学到的信息会影响未来旅行计划会话中的推荐，使其高度个性化。

  1. 角色记忆

这种专门的记忆类型帮助代理形成一致的“个性”或“角色”。它允许代理记住关于自身或其预定角色的细节，使交互更流畅和有针对性。

角色记忆示例

如果旅行代理被设计为“滑雪专家”，角色记忆可能会强化这一角色，影响其以专家的语气和知识来回答问题。

  1. 工作流/情节记忆

这种记忆存储代理在复杂任务中采取的步骤序列，包括成功和失败。它像是在记住特定“情节”或过去经历，以便从中学习。

情节记忆示例

如果代理尝试预订某趟特定航班但因不可用而失败，情节记忆可以记录这一失败，允许代理在随后尝试时尝试替代航班或以更知情的方式向用户说明问题。

  1. 实体记忆

这涉及从对话中提取并记住特定实体（如人、地点或事物）和事件。它允许代理构建一个关于讨论的关键元素的结构化理解。

实体记忆示例

从一次关于过去旅行的对话中，代理可能会提取“巴黎”、“埃菲尔铁塔”和“在 Le Chat Noir 餐厅的晚餐”等实体。在未来的交互中，代理可以回忆起“Le Chat Noir”并主动提出在那里重新预订。

  1. 结构化 RAG (Retrieval Augmented Generation)

虽然 RAG 是一种更广泛的技术，但“结构化 RAG”被强调为一种强大的记忆技术。它从各种来源（对话、电子邮件、图像）提取密集、结构化的信息，并用它来提高回答的精确性、召回率和速度。与仅依赖语义相似性的经典 RAG 不同，结构化 RAG 利用信息的固有结构。

结构化 RAG 示例

结构化 RAG 可以不仅仅匹配关键字，而是从电子邮件中解析出航班详情（目的地、日期、时间、航空公司）并以结构化方式存储。这允许像“我周二预订了去巴黎的哪趟航班？”这样的精确查询。

实现与存储记忆

为 AI代理实现记忆涉及一个系统化的“记忆管理”过程，包括生成、存储、检索、整合、更新，甚至“遗忘”（或删除）信息。检索是一个特别关键的方面。

专用记忆工具

  1. Mem0

存储和管理代理记忆的一种方式是使用像 Mem0 这样的专用工具。Mem0 作为持久记忆层工作，允许代理回忆相关交互、存储用户偏好和事实性上下文，并随着时间从成功和失败中学习。其核心思想是无状态的代理转变为有状态的代理。

它通过一个两阶段记忆管道：提取和更新来工作。首先，添加到代理线程的消息会发送到 Mem0 服务，Mem0 使用大型语言模型（LLM）来总结对话历史并提取新记忆。随后，LLM 驱动的更新阶段会决定是否添加、修改或删除这些记忆，并将它们存储在可能包含向量、图和键值数据库的混合数据存储中。该系统还支持各种记忆类型，并且可以整合图记忆以管理实体之间的关系。

  1. Cognee

另一种强大方法是使用 Cognee，一个开源的语义记忆系统，它将结构化和非结构化数据转换为由嵌入支持的可查询知识图。Cognee 提供了双存储架构，结合了向量相似性搜索和图关系，使代理不仅能理解信息之间的相似性，还能理解概念之间的关系。

它擅长于将向量相似性、图结构和 LLM 推理融合的混合检索——从原始块查找到具备图感知的问题回答。系统维持着不断演进和增长的活记忆，并作为一个连接的图保持可查询，支持短期会话上下文和长期持久记忆。

  1. 使用 RAG 存储记忆

除了像 mem0 这样的专用记忆工具之外，您还可以利用强大的搜索服务作为存储和检索记忆的后端，尤其适用于结构化 RAG。这使您能够以自己的数据为基础来支撑代理的回答，确保更相关和准确的答案。

使 AI代理自我改进

实现自我改进代理的一个常见模式是引入一个“知识代理”。这个独立的代理观察用户与主代理之间的主要对话。它的角色是：

  1. 识别有价值的信息：确定对话中的哪部分值得作为通用知识或特定用户偏好保存。

  2. 提取并总结：从对话中提炼出关键的学习或偏好。

  3. 存储到知识库：将提取的信息持久化，通常存储在向量数据库中，以便日后检索。

  4. 增强未来查询：当用户发起新查询时，知识代理检索相关的已存信息并将其附加到用户的提示中，为主代理提供关键上下文（类似于 RAG）。

记忆的优化

延迟管理：为了避免降低用户交互速度，可以最初使用更便宜、更快速的模型快速检查信息是否有价值需要存储或检索，只有在必要时才调用更复杂的提取/检索流程。

知识库维护：对于不断增长的知识库，不常用的信息可以移动到“冷存储”以控制成本。

参考

microsoft/ai-agents-for-beginners

版权声明：本文为博主原创文章，转载请注明出处。 旭日酒馆