AI 代理简介

围绕 ChatGPT 的讨论现已演变为 AutoGPT。虽然 ChatGPT 主要是一个可以生成文本响应的聊天机器人，但 AutoGPT 是一个功能更强大、自主性更强的 AI 代理，可以执行复杂的任务，例如进行销售、计划旅行、预订航班、预订承包商做家务、订购披萨。

比尔·盖茨最近设想了一个未来，我们将拥有一个能够处理和响应自然语言并完成许多不同任务的人工智能代理。盖茨以计划旅行为例。

通常，这需要您自己预订酒店、航班、餐厅等。但人工智能代理可以利用其对您的偏好的了解来代表您预订和购买这些东西。

AI 代理 [1] 的研究历史悠久，主要集中在多代理系统 (MAS) [2]，尤其是面向目标的代理 [3]。然而，在实践中，设计和部署 AI 代理仍然具有挑战性。在本文中，我们主要关注 AI 代理平台的两个方面：

鉴于人工智能代理的复杂性和长期运行性，我们讨论了确保可靠且有状态的人工智能代理执行的方法。
为 AI 代理添加负责任的 AI 维度。我们重点介绍了 AI 代理特有的问题，并提出了建立由负责任的 AI 实践管理的集成 AI 代理平台的方法。

Agent AI 平台参考架构

在本节中，我们重点识别参考 AI 代理平台的关键组件：

代理市场
编排层
集成层
共享内存层
治理层，包括可解释性、隐私、安全性等。

有状态且负责任的 AI 代理 — 图 1：AI 代理平台参考架构（作者提供图片）

给定一个用户任务，AI 代理平台的目标是识别（组成）能够执行给定任务的代理（代理组）。因此，我们需要的第一个组件是能够将任务分解为子任务的编排层，由编排引擎编排各个代理的执行。

解决此类复杂任务的高级方法包括：(a) 将给定的复杂任务分解为简单任务（层次结构或工作流），然后 (b) 组合能够执行简单任务的代理。这可以以动态或静态方式实现。在动态方法中，给定一个复杂的用户任务，系统会根据运行时可用代理的功能制定满足请求的计划。在静态方法中，给定一组代理，在设计时手动定义复合代理，结合它们的功能。

这意味着存在一个代理市场/代理注册中心——对代理能力和约束有明确的描述。例如， 让我们考虑一个房屋粉刷代理C，其服务可以在线预订（通过信用卡）。鉴于此，用户需要有效的信用卡这一事实是一个约束，而用户的房子将在一定时间范围内粉刷这一事实是其能力。此外，我们还需要考虑C在实际执行阶段的任何约束，例如，C只能在工作日（而不是周末）提供服务。一般来说，约束是指启动执行需要满足的条件，而能力则反映执行终止后的预期结果。有关 AI 代理发现方面的详细讨论，请参阅 [4]。

考虑到需要协调多个代理，我们还需要一个支持不同代理交互模式的集成层，例如代理到代理 API、代理 API 提供供人类使用的输出、人类触发 AI 代理、AI 代理到代理（人类参与循环）。集成模式需要由底层 AgentOps 平台支持。

Andrew Ng 最近从性能角度谈到了这方面：

如今，许多 LLM 输出都是供人类使用的。但在代理工作流中，LLM 可能会被反复提示反思和改进其输出、使用工具、计划和执行多个步骤，或实现多个协作的代理。因此，在向用户显示任何输出之前，我们可能会生成数十万个或更多的 token。这使得快速 token 生成非常可取，而较慢的生成速度则成为充分利用现有模型的瓶颈。

为了容纳多个长期运行的代理，我们还需要一个共享内存层，实现代理之间的数据传输，存储交互数据，以便可以用于个性化未来的交互。

最后是治理层。我们需要确保用户共享的与特定任务相关的数据或跨任务的用户配置文件数据仅与相关代理共享（身份验证和访问控制）。我们进一步考虑了数据质量、隐私、可重复性和可解释性等不同的负责任的 AI 维度，以实现管理良好的 AI 代理平台。

状态代理监控

有状态执行 [5] 是任何分布式系统平台的固有特性，并且可以被视为实现人工智能代理平台编排层的关键要求。

鉴于此，我们预计，随着 AI 代理平台为企业做好准备并开始支持 AI 代理的生产部署，代理监控和故障恢复将变得越来越重要。

然而，监控人工智能代理（类似于监控大型分布式系统）具有挑战性，原因如下：

没有全局观察者：由于其分布式特性，我们不能假设存在一个对整个执行具有可见性的实体。事实上，由于其隐私和自主性要求，即使是复合代理也可能无法看到其组件代理的内部处理。
非确定性：AI 代理允许并行组合流程。此外，AI 代理的执行通常依赖于外部因素。因此，在实际执行之前可能无法预测其行为。例如，航班预订是否成功取决于可用座位数量（预订时），无法提前预测。
通信延迟：通信延迟使得无法立即记录所有相关代理的状态。例如，假设代理A发起记录组合状态的尝试。然后，当请求（记录其状态）到达代理 B 并且 B 记录其状态时，代理 A 的状态可能已经发生变化。
动态配置：随着执行的进行，代理逐渐被选择（动态绑定）。因此，分布式系统的“组件”可能事先无法得知。

总而言之，鉴于 AI 代理的复杂性和长期运行特性，AgentOps 监控至关重要。我们将代理监控定义为找出执行过程的位置以及是否出现任何意外故障的能力。我们讨论了获取代理执行快照以回答以下类型的查询的能力和局限性：

本地查询：可根据代理的本地状态信息回答的查询。例如，“代理A的执行当前状态是什么？”或“ A是否已达到特定状态？”等查询。本地查询可通过直接查询相关代理提供商来回答。
复合查询：针对多个代理的状态表达的查询。我们假设与组合状态相关的任何查询都表示为各个代理执行状态的结合。状态查询示例：“代理A、B和C是否分别达到状态x、y和z？”此类查询在文献中被称为稳定谓词。稳定谓词被定义为一旦变为真就不会变为假的谓词。
历史查询：与组合的执行历史相关的查询。例如，“代理A和B被暂停了多少次？”。如果使用执行快照算法回答查询，则需要提到结果是相对于过去某个时间的。
关系查询：基于状态之间关系的查询。例如，“当代理B处于 y 状态时，代理A的状态是什么？”不幸的是，基于执行快照的算法不能保证此类查询的答案。例如，除非我们有一个快照可以捕获代理B处于y状态时的状态，否则我们将无法回答查询。此类谓词在文献中被称为不稳定谓词。不稳定谓词的值不断在真和假之间交替变化 – 因此很难基于快照算法进行回答。

我们将在下一节概述 AI 代理监控方法和解决方案架构。

AI代理监控架构与快照算法

我们假设每个代理都对应一个协调器和日志管理器，如下图所示。我们还假设每个代理负责执行单个任务/操作。

协调器负责与代理执行相关的所有非功能方面，例如监控、事务等。日志管理器记录有关任何状态转换以及代理发送/接收的任何消息的信息。所考虑的状态转换和消息如下图所示：

未执行 (NE)：代理正在等待调用。
执行（E）：在收到调用消息（IM）时，代理将其状态从 NE 更改为 E。
已暂停 (S) 和由调用者暂停 (IS)：处于状态 E 的代理可能由于内部事件 (暂停) 而将其状态更改为 S，或者在收到暂停消息 (SM) 时将其状态更改为 IS。相反，由于内部事件 (恢复) 而从 S 转换到 E，在收到恢复消息 (RM) 时从 IS 转换到 E。
取消 (CI)、由于调用者而取消 (ICI) 和已取消 (C)：处于 E/S/IS 状态的代理可能会由于内部事件 (取消) 或收到取消消息 (CM) 时发生的 ICI 而将其状态更改为 CI。一旦完成取消，它将状态更改为 C 并向其父级发送 acCanceled 消息 (CedM)。请注意，取消可能需要取消其某些组件代理的效果。
终止 (T) 和补偿 (CP)：代理在完成操作后将其状态更改为 T。终止时，代理会向其父代理发送终止消息 (TM)。代理可能需要在完成操作后取消操作（补偿）。处于状态 T 的代理在收到 CM 后将其状态更改为 CP。完成补偿后，它将移动到 C 并向其父代理发送 CedM。

我们假设组合模式（静态组合）为代理操作指定了部分顺序。我们定义代理操作之间的发生前关系如下：

操作 a 发生在操作 b (a → b) 之前，当且仅当下列之一成立

操作 a 和 b 之间存在控制/数据依赖关系，因此 a 需要先终止，b 才能开始执行。
存在一个运算 c 使得 a → c 且 c → b。

如果操作失败，则使用相同或不同的代理重试，直到成功完成（终止）。请注意，每次（重试）尝试都被视为一次新调用，并将相应地记录。最后，为了适应异步通信，我们假设存在输入/输出 (I/O) 队列。基本上，每个代理都有一个相对于其父代理和组件代理的 I/O 队列 — 如图 2 所示。

给定同步时钟和日志记录（如上所述），时间 t 时的层次结构组成的快照将包含截至时间 t 的所有“相关”代理的日志。

可以通过考虑父代理日志中记录的调用操作的代理（直到时间 t）以递归方式（从根代理开始）确定相关代理。如果使用消息时间戳，则我们需要在记录日志时考虑偏差，即，如果父代理的日志记录到时间t，则其组件代理的日志需要记录到（t + 偏差）。可以从状态转换模型中确定 I/O 队列的状态。

负责任的 AgentOps

生成式人工智能的日益普及，尤其是大型语言模型 (LLM) 的采用，重新引发了有关负责任人工智能的讨论，以确保人工智能/机器学习系统得到负责任的训练和部署。

下表总结了为人工智能代理实施负责任的人工智能所面临的主要挑战和解决方案。

ChatGPT 风格大型语言模型 (LLM) API
LLM 微调：LLM 本质上是通用的。要充分发挥 LLM 在企业中的潜力，需要将其与以文档、wiki、业务流程等形式捕获的企业知识相结合。这是通过使用企业知识/嵌入对 LLM 进行微调来开发特定于上下文的 LLM/小语言模型 (SLM) 来实现的
检索增强生成 (RAG)：微调是一个计算密集型过程。RAG 通过在提示中提供额外的上下文，将检索/响应与给定的上下文联系起来，从而提供了一种可行的替代方案。提示可能相对较长，因此可以在提示中嵌入企业上下文。

我们将在本文的其余部分扩展上述观点，以实现具有负责任的 AI 治理的集成 AgentOps 管道。

数据一致性：用于训练（尤其是微调）LLM 的数据应准确无误，这意味着应使用与特定用例相关的数据来训练 LLM，例如，如果用例是生成医疗处方摘要 — 用户不应使用其他数据（如诊断问答），用户只能使用医疗处方和相应的处方摘要。很多时候，需要创建数据管道来提取数据并将其提供给 LLM。在这种情况下，需要格外小心地使用正在运行的文本字段，因为这些字段包含的数据大多不一致且不正确。

偏见/公平性：就模型性能和可靠性而言，很难控制黑盒 LLM 中的不良偏见，尽管可以通过使用统一且无偏见的数据来微调 LLM 和/或在 RAG 架构中将 LLM 情境化，从而在一定程度上控制它。

可追溯性：为了使 LLM 更加可靠，建议对 LLM 的输出进行人工验证。人工参与可确保如果 LLM 出现幻觉或提供错误响应，人工可以进行评估并做出必要的更正。

幻觉：在使用 LLM API 或编排多个 AI 代理的情况下，幻觉出现的可能性会随着涉及的代理数量的增加而增加。正确的提示可以提供帮助，但只能起到有限的帮助作用。为了进一步限制幻觉，需要使用精选数据对 LLM 进行微调和/或将响应的搜索空间限制为相关和最新的企业数据。

可解释性：可解释性是一系列工具、算法和方法的总称，它们伴随着 AI 模型推理和解释。思路链 (CoT)是一个框架，用于解决 LLM 如何解决问题。CoT 主要可以通过两种方法实现：

用户提示：在这里，在提示期间，用户提供有关如何解决某个问题的逻辑，LLM 将使用相同的逻辑解决类似的问题并连同逻辑一起返回输出。
自动化 CoT 提示：手动制作 CoT 可能非常耗时，并且只能提供次优解决方案，自动 CoT（Auto-CoT）可用于自动生成推理链，从而消除人工干预。Auto-CoT 基本上基于两个过程：1. 问题聚类：对给定数据集的问题进行聚类。2. 演示抽样：从每个集群中选择代表性问题，并使用零样本 CoT 生成推理链。Auto-CoT 适用于具有大约 100B 个参数的 LLM，但对于 SLM 则不那么准确。