作为代理大脑的LLM的能力门槛相对较高。规模较小的LLM可能需要大量及时的工程或微调才能满足要求。

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

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

01 保障和自主权件

代理意味着自主性，因此必须在多代理系统中为代理内置各种保护措施，以减少代理自主运行时的错误、浪费、法律风险或危害。将所有这些保护措施应用于所有代理可能会过度并带来资源挑战，但我强烈建议考虑系统中的每个代理，并有意识地决定它们需要哪些保护措施。如果满足其中任何一个条件，代理就不应该被允许自主运行。

02 明确定义人为干预条件

触发一组预定义规则中的任何一个都会决定人类需要确认某些代理行为的条件。

这些规则应根据具体情况进行定义，并可在代理的系统提示中声明或者在更关键的用例中，使用代理外部的确定性代码来执行。对于采购代理来说，一条这样的规则是：“所有采购都应首先由人类验证和确认。调用您的‘check_with_human’函数，直到它返回值后再继续。”

03 保障代理

保障代理可以与负责检查风险、不道德或不合规行为的代理配对。可以强制代理始终根据保障代理检查其行为的全部或某些元素，除非保障代理返回批准，否则不会继续。

04 不确定性

我们实验室最近发表了一篇论文，介绍了一种可以衡量大型语言模型 (LLM) 生成内容的不确定性的技术。

鉴于LLM倾向于虚构（通常称为幻觉），优先考虑某个输出可以使代理更加可靠。这里也需要付出代价。评估不确定性需要我们为同一请求生成多个输出，以便我们可以根据确定性对它们进行排序，并选择不确定性最小的行为。这可能会使系统变慢并增加成本，因此应该考虑系统中更关键的代理。

05 解除按钮

有时我们需要停止所有基于代理的自主流程。这可能是因为我们需要一致性，或者我们检测到系统中的行为需要停止，以便我们找出问题所在并修复它。对于更关键的工作流程和流程，重要的是这种脱离不会导致所有流程停止或完全变成手动，因此建议配置确定性的后备操作模式。

06 代理生成的工作订单

并非代理网络中的所有代理都需要完全集成到应用程序和API中。这可能需要一段时间，并且需要几次迭代才能正确完成。

我的建议是向代理（通常是网络中的叶节点）添加一个通用占位符工具，该工具只会发布报告或工作订单，其中包含代表代理手动采取的建议操作。这是一种以敏捷方式引导和运营代理网络的好方法。

07 测试

借助基于LLM的代理，我们以牺牲一致性为代价获得了稳健性。此外，鉴于 LLM的不透明性，我们正在处理工作流中的黑盒节点。这意味着我们需要一种不同于传统软件的基于代理系统的测试机制。然而，好消息是，我们已经习惯了测试这样的系统，因为自工业化开始以来，我们就一直在运营以人为本的组织和工作流程。

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

我们还可以利用生成式人工智能来提出针对网络的测试用例，以分析其行为并推动它揭示其弱点。

最后，我非常提倡沙盒。此类系统应首先在受控且安全的环境中小规模推出，然后逐步推广以取代现有的工作流程。

08 微调

关于通用人工智能的一个常见误解是，你用得越多，它就越好。这显然是错误的。LLM是经过预先训练的。话虽如此，它们可以通过各种方式进行微调以偏向其行为。一旦设计出多智能体系统，我们就可以选择通过从每个智能体获取日志并标记我们的偏好来构建微调语料库，从而改善其行为。

09 陷阱

多代理系统可能会陷入混乱，这意味着有时查询可能永远不会终止，代理之间会不断进行通信。这需要某种形式的超时机制。例如，我们可以检查同一查询的通信历史记录，如果查询量增长过大或检测到重复行为，我们可以终止流程并重新开始。

另一个可能出现的问题是一种我称之为超负荷的现象：对单个代理期望过高。目前最先进的法学硕士课程不允许我们向代理提供冗长而详细的说明，并期望他们始终遵循这些说明。另外，我是否提到过这些系统可能不一致？

缓解这些情况的方法就是我所说的粒度化：将代理分解为多个相连的代理。这可以减少每个代理的负载，并使代理的行为更加一致，不太可能陷入混乱。（我们实验室正在进行的一个有趣的研究领域是自动化粒度化过程。）

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

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

最后，需要注意的是，作为代理大脑的LLM的能力门槛相对较高。规模较小的LLM可能需要大量及时的工程或微调才能满足要求。好消息是，已经有几个商业和开源代理通过了这一门槛，尽管规模相对较大。

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