AI智能体入门指南（下）：自主性、安全性和陷阱

在我们的第一期文章中，我们概述了利用 AI 代理来提高企业效率的关键策略。我解释了，与独立的 AI 模型不同，代理通过使用上下文和工具迭代地改进任务，以增强代码生成等结果。我还讨论了多代理系统如何在部门之间促进沟通，从而创造统一的用户体验并推动生产力、弹性和更快的升级。

构建这些系统的成功取决于映射角色和工作流程，以及建立安全措施，例如人工监督和错误检查，以确保安全运行。让我们深入探讨这些关键要素。

代理意味着自主性，因此必须在多代理系统中的代理内构建各种安全措施，以减少代理在自主运行时发生的错误、浪费、法律风险或损害。将所有这些安全措施应用于所有代理可能过于繁琐，并构成资源挑战，但我强烈建议考虑系统中的每个代理，并有意识地决定它们需要哪些安全措施。如果满足以下任何一项条件，则不允许代理自主运行。

触发一组预定义规则中的任何一个规则，都会确定人类需要确认某些代理行为的条件。这些规则应根据具体情况进行定义，并且可以在代理的系统提示中声明，或者在更关键的用例中，使用代理外部的确定性代码进行强制执行。例如，在采购代理的情况下，一项规则是：“所有采购必须首先由人工验证和确认。调用您的“check_with_human”函数，并在其返回值之前不要继续。”

可以将一个安全代理与一个负责检查风险、不道德或不符合行为的代理配对。可以强制代理始终根据安全代理检查其行为的所有或某些元素，并在安全代理返回允许信号之前不继续。

我们实验室最近发表了一篇关于一种技术的论文，该技术可以为大型语言模型 (LLM) 生成的内容提供不确定性度量。鉴于 LLM 容易产生虚假信息（通常称为幻觉），优先考虑特定输出可以使代理更加可靠。同样，这里也需要付出代价。评估不确定性要求我们为同一个请求生成多个输出，以便我们可以根据确定性对它们进行排名，并选择不确定性最小的行为。这可能会使系统变慢并增加成本，因此应考虑将其用于系统中更关键的代理。

有时我们可能需要停止所有基于代理的自主流程。这可能是因为我们需要一致性，或者我们在系统中检测到需要停止的行为，以便我们找出问题所在以及如何解决问题。对于更关键的工作流程和流程，重要的是这种分离不会导致所有流程停止或完全手动化，因此建议提供确定性的回退操作模式。

并非代理网络中的所有代理都需要完全集成到应用程序和 API 中。这可能需要一段时间，并且需要几次迭代才能正确完成。我的建议是向代理（通常是网络中的叶节点）添加一个通用的占位符工具，该工具只需发布一份报告或工作单，其中包含建议的操作，以便代表代理手动执行这些操作。这是一种以敏捷方式引导和运营代理网络的好方法。

使用基于 LLM 的代理，我们以一致性为代价获得了鲁棒性。此外，鉴于 LLM 的不透明性，我们在工作流程中处理的是黑盒节点。这意味着我们需要为基于代理的系统采用与传统软件不同的测试制度。然而，好消息是，我们已经习惯了测试此类系统，因为自工业化开始以来，我们一直在运营由人工驱动的组织和工作流程。

虽然我上面展示的示例只有一个入口点，但多代理系统中的所有代理都以 LLM 作为其大脑，因此它们可以充当系统的入口点。我们应该使用分而治之的方法，首先从层次结构中的各个节点开始测试系统的子集。

我们还可以利用生成式 AI 来提出测试用例，我们可以针对网络运行这些用例，以分析其行为并推动其暴露其弱点。

最后，我强烈支持沙盒。此类系统应首先在受控和安全的环境中以较小规模启动，然后逐步推出以取代现有工作流程。

关于生成式 AI 的一个普遍误解是，使用得越多，它就越好。这显然是错误的。LLM 是预先训练的。话虽如此，它们可以被微调以以各种方式偏向其行为。一旦设计了多代理系统，我们就可以选择通过获取每个代理的日志并标记我们的偏好来构建微调语料库，从而改进其行为。

多代理系统可能会陷入尾旋，这意味着查询有时可能永远不会终止，代理会不断地相互交谈。这需要某种形式的超时机制。例如，我们可以检查同一查询的通信历史记录，如果它变得太大或我们检测到重复行为，我们可以终止流程并重新开始。

另一个可能发生的问题是一种我称之为过载的现象：对单个代理期望过高。LLM 的当前技术水平不允许我们向代理提供冗长而详细的指令，并期望它们始终遵循所有指令。此外，我是否提到过这些系统可能不一致？

针对这些情况的缓解措施是我称之为细化的措施：将代理分解成多个连接的代理。这减少了每个代理的负载，并使代理的行为更加一致，不太可能陷入尾旋。（我们实验室正在进行的一个有趣的研究领域是自动执行细化过程。）

多代理系统设计中的另一个常见问题是倾向于定义一个协调代理，该代理调用不同的代理来完成一项任务。这引入了单点故障，可能导致一组相当复杂的角色和责任。我建议在这些情况下将工作流程视为管道，一个代理完成部分工作，然后将其传递给下一个代理。

多代理系统还倾向于将上下文传递给链中的其他代理。这可能会使其他代理过载，使它们感到困惑，而且通常是不必要的。我建议允许代理保留自己的上下文，并在我们知道正在处理新请求时重置上下文（有点像网站如何处理会话）。

最后，重要的是要注意，作为代理大脑的 LLM 的能力有一个相对较高的门槛。较小的 LLM 可能需要大量的提示工程或微调才能满足请求。好消息是，已经存在一些商业和开源代理，尽管它们相对较大，但它们已经通过了门槛。

这意味着，在构建大规模多代理系统时，成本和速度需要成为重要的考虑因素。此外，应该设定预期，这些系统虽然比人类快，但不会像我们习惯使用的软件系统那样快。

Babak Hodjat 是 Cognizant 的 AI 首席技术官。