编者按：目前 AI Agents 在各行各业的应用前景广阔，越来越多的企业开始尝试部署 AI Agents ，然而如何在企业生产环境中有效部署和管理 AI Agents，是工程师们面临的一大挑战。你是否曾面临这样的困惑：如何确保 AI Agents 在生产环境中稳定可靠地运行？如何应对突发的高并发请求？当 AI Agents 出现"幻觉"或系统崩溃时，又该如何快速恢复？
本文提出了 "Multi-Agent-as-a-Service(MAaaS)" 这一概念，认为可以借鉴云应用的最佳实践（best-practices）来设计、部署和管理 AI Agents 系统。MAaaS 框架涵盖了从系统架构到监控管理的各个方面，包括明确的职责划分、RESTful 接口设计、独立的数据存储、容器化部署、自动化测试等关键策略。
我们相信，随着对 MAaaS 概念的不断探索和完善，Multi-Agent 系统有望在各个行业中引发变革，为 AI 应用开辟新的道路。
作者 ? | Sam Rajaei & Guanyi Li
编译 ? | 岳扬
Appendix: Debate Output
?文中链接?
关于 AI Agents（能够基于特定指令和对上下文的理解独立完成任务的自主系统[1]）的讨论[2]一直不绝于耳。其讨论热度几乎可与大语言模型（LLMs）相媲美。本文将从一线工程师、系统架构师以及平台可靠性工程师（SREs）的视角出发，探讨 AI Agents，介绍 Multi-Agents-as-a-Service 这一概念，以及他们如何在未来的生产环境中与 AI Agents “打交道”。
Context：AI Agents 能解决什么问题？
在探讨 AI Agents 能解决的问题时，我们发现它们在以下任务场景表现出色 —— 模仿人类交流方式可以更有效执行的任务，比如需要理解自然语言、情感识别、个性化服务或者需要与人类用户进行互动的任务。
在电子商务领域，借助 LLM-based RAG 或 Text-to-SQL 等技术， AI Agents 能够根据公司规定准确回答用户的问题，从而为客户提供更加个性化的购物体验，有望颠覆传统的电商模式。
客户服务领域也是 AI Agents 的理想应用场景。很多人都有过为了一些简单的问题（比如订单状态没有更新）长时间排队等待客服的经历。一些初创公司（例如 Decagon[3]）正通过 AI Agents 来解决这些效率低下的问题。
也十分适合根据个人需求提供产品或内容的定制化领域，Wix[4] 就是一个典型案例。面向无需编写代码或只需编写少量代码的网站搭建需求，Wix 开发了一个聊天机器人，它能够通过问答与用户互动，根据用户的描述和需求来搭建网站。
“人类只需设定目标（goals），而 AI Agents 会独立决策，选择达到目标所需的最优行为规划。”[5]
基于 LLMs 的 AI Agents 在模拟人类的自然对话和执行简单的商业流程操作等方面表现较好，往往能够提供既高效又令人满意的服务。
工程师们关于 AI Agents & Enterprise Production Environments 的观点
在思考了 AI Agents 的诸多优势后，你是否曾好奇过它们如何在企业生产环境中运行？什么样的架构模式和基础设施组件能够最好地支持它们的正常运行？当遇到不可避免的错误，如 Agents 出现幻觉[6]、系统崩溃，或（可能更加糟糕）在执行重要任务时进行了错误的推理和规划，我们该怎么办？
如果我们是一名工程师，必须审慎思考这些问题。更重要的是，我们还需探讨一个根本性的问题：我们该如何界定 Multi-Agent 平台首次部署成功的标准？
为了寻找答案，我们可以借鉴软件工程领域的另一个分支——可靠性工程（Reliability Engineering）中的一个概念：服务质量目标（Service Level Objectives, SLOs）。SLOs 是衡量服务性能与可靠性的关键指标，简单来说，SLOs 规定了“成功”操作与总操作的 acceptable ratio（译者注：可以接受的或合理的比例，如果这个比例高于某个预先设定的阈值，那么服务的性能就被认为是可接受的。反之，如果低于这个阈值，则可能需要采取优化措施。），以及这些操作对用户体验的影响。这些目标将帮助我们设定 AI Agents 及其支持的工作流所需达到的服务要求和预期水平。
那么，SLO 与我们讨论的 AI Agents 有什么关系呢？
我们在讨论 AI Agents 的性能时，可以将其简化为两个核心目标 —— “可用性（Availability）”和“准确性（Accuracy）”，并且识别出一些更具体的、有助于实现这些目标的 SLOs ：
可用性：描述的是 Agents 或平台对请求（requests）给出成功响应（例如 HTTP 200 状态码）的比例。从以往来看，底层服务器的正常运行时间和 ping 命令的成功率是衡量可用性的重要指标。然而，在微服务架构盛行的今天，这种传统的衡量方式可能变得不那么重要了。现在的平台系统更倾向于通过响应用户请求成功的次数与响应用户请求失败的次数来准确反映系统的可用性。此外，延迟（Latency）[7]和吞吐量（Throughput）也是与之相关的指标。
准确性：这一点与 AI Agents 快速且稳定地响应用户的请求不同，它更侧重于 Agents 在无人验证其工作准确性的情况下，能否从业务角度正确执行任务并返回准确数据。传统系统也会监测数据准确性和质量的 SLOs。
衡量上述 AI Agents 的性能目标是否达到时，通常需要实时地收集和提交应用程序内部的各种性能指标数据，可以按照固定的时间间隔（比如每10分钟一次）收集、提交，或者是对特定事件（如用户请求、上游调用等）做出响应时收集、提交。例如，可以用 Synthetic[8] probing（译者注：通过模拟或合成的方式来探测系统，通常是为了测试系统在处理现实情况时的性能。例如，在测试一个网站或服务器的响应时间时，可以用它来模拟用户发起的请求，然后测量服务器对这些请求的响应时间和成功率。） 来模拟用户请求，触发相关事件，并监控相关数据。此处我们要探讨的关键问题是：那些设计相对简单、行为可预测的传统系统，其输出总是确定的、可预测的，因此，对其进行监控、探测和评估通常比较直接。但对于复杂多变的 GenAI Agents，情况却未必如此。
请注意，本文主要关注两个目标中的第一个——可用性。包括确定验收标准，这些验收标准确保系统在运行时能够保持稳定，不受外部因素的影响，以便帮助 Agents 顺利处理用户的 query 。如果想要更深入了解准确性（例如为 AI Agents 设定合理的任务范围、优化 few-shot 方法和评估框架的性能）的相关内容，这篇文章[9]可作为入门学习资料。
现在，回到工程师在部署 AI Agents 时为确保基础架构的可靠性而需要做好的事情。为了达成服务质量目标（SLOs）并打造一个可靠而安全的平台，工程师应当重点关注以下几个因素：
Scalability：当请求量突然增加时，系统能否有效应对？
Cost-Effectiveness：大语言模型（LLM）的使用成本高昂，如何监控和控制成本？
High Availability：如何确保系统始终可用且响应迅速？AI Agents 是否具备自我修复功能，并能够从错误（errors）或系统崩溃（crashes）中恢复正常？
Security：如何确保数据在静态存储过程中和传输过程中的安全?，如何完成安全审计、漏洞挖掘等工作？
Compliance & Regulatory：这是人工智能领域的一个重大议题，我们必须遵守哪些相关的数据隐私法规和其他特定行业标准？
Observability：如何实时监控 AI Agents 的业务流程、运行状态和资源利用率，以便在问题影响用户体验之前识别并解决？
是不是听起来很耳熟？似乎 AI Agents 与 Web 应用、微服务架构和云基础设施所面临的挑战非常相似。
那么，现在该怎么办？我们提出了一个用于 AI Agents 开发和维护的框架，该框架遵循了多年来在一系列工程和软件学科中形成的最佳实践（best-practices）。
Multi-Agent-as-a-Service (MAaaS)
这次，让我们借鉴云应用领域（cloud-based applications）的最佳实践，重新思考如何在生产系统中设计 AI Agents：
明确的职责范围：每个 Agents 都应该有一个定义明确且职责范围较小的工作领域，并明确其功能界限。通过这种模块化方法，AI Agents 能够更准确的执行任务，且更易于管理和不依赖其他组件独立扩展。
RESTful 接口风格和服务间使用异步通信方式：使用 RESTful API 进行用户与 AI Agents 之间的通信，并利用消息代理（message brokers）进行异步通信。这种方法让 AI Agents 之间的交互更加松散，从而提高了系统的可扩展性（scalability）和容错能力（fault tolerance）。
每个 AI Agent 的数据独立存储：每个 Agent 都应该有自己的数据存储空间，每个 Agent 的数据应该是封闭的，不会与其他 Agent 的数据混淆或混合。必要时使用分布式数据存储解决方案，使每个 Agent 更加独立和易于管理。
使用容器化技术和容器编排来管理和部署应用程序：使用容器（如 Docker ）来打包和部署 AI Agents，确保它们在不同的环境中保持一致性，简化了 Agents 的部署（deployment）和扩展（scaling）（译者注：即增加或减少 Agents 实例的数量）过程。借助容器编排平台（如 Kubernetes ）来管理 Agents 服务的整个生命周期，包括部署、扩展和日常运维。
自动化测试和 CI/CD 流程：实施自动化测试（包括单元测试（unit）、集成测试（integration）、契约测试（contract）和端到端测试（end-to-end）），以确保对 AI Agents 进行可靠的代码变更管理。使用 CI 工具在代码提交时自动构建和测试 AI Aegnts 。建立 CD pipelines，无缝地将更新后的代码（changes）部署到生产环境，减少停机时间并确保快速迭代。
可观测性（Observability）：为 AI Agents 及其支持的基础设施实施强大的可观测工具，如 metrics（译者注：可量化的指标，用于衡量系统性能、资源使用情况、响应时间等。）、tracing（译者注：跟踪和记录系统内部操作的详细信息，包括请求如何从一个服务流向另一个服务等信息。）和 logging（译者注：通常记录错误、警告和信息性消息，以便在出现问题时进行回溯和分析），以建立一个能够实时显示平台可靠性的工具或界面。计算每个 Agent 及其处理的所有请求流的 SLOs 和 error budgets（译者注：在 SLOs 中允许的错误次数或错误率）。通过模拟用户请求和高效地处理系统警告和故障，可以在 Agents 产生的问题对大量终端用户造成影响之前及时发现并解决。
通过应用前文提到的这些原则，我们就可以构建一个强大的、可靠的 AI Agents 框架，并提出 “Multi-Agent as a Service”（MAaaS） 这一概念。这种方法利用了云应用的最佳实践，重新定义了 AI Agents 的设计、部署和管理方式。
Image by the author
AI Agents 能够在业务运营中扮演着比较关键的角色。然而，Agents 需要一个强大的基础设施支撑着它的运行，不能独立于这些环境之外，确保它能够满足生产环境中的预期需求，基础设施中的关键组件包括：
SOA 架构（Service-Oriented Architecture）：在设计 AI Agents 时，将其设计成可以轻松集成到现有系统中的 services（译者注：可以独立运行，也可以作为更大的系统或应用程序的一部分，可以选择使用云服务商的云服务，按需使用。）。
API 网关：使用 API 网关来管理和保护客户端与 Agents 之间的流量。
弹性基础设施：利用可以根据需求弹性扩展或缩减资源的云基础设施。
云服务提供商托管的云服务：使用云服务提供商托管的服务（如数据库服务、向量存储服务、消息传递服务和机器学习服务）来减少运维成本。
集中监测（Centralized Monitoring）：使用集中监测解决方案（如CloudWatch、Prometheus、Grafana）来追踪 AI Agents 的运行状况和性能情况。
为了突出前文所提 Multi-Agent 系统的优点，我们将展示一个简单的 Multi-Agent 系统示例：一个辩论平台。
Example: Multi-Agent 辩论模拟系统
为了生动演示 MAaaS 的运作方式，我们打造了一个 Multi-Agent 辩论模拟系统。辩论的主题是“AI 对就业市场的影响（AI’s impact on the job market）”。这个辩论系统包含三个 Agent：
支持 AI 对就业有益的 A 队
持有相反观点的 B 队
负责管理辩论过程的主持人，辩论将在八轮之后或两队之间的讨论开始变得没有太多意义时结束。
我们使用 PhiData[10] 来构建 AI Agents ，并通过 AWS Elastic Kubernetes Service（EKS） 进行部署，以实现高可用性。Agent 的活动通过 AWS CloudWatch 进行监控，EKS 的 service discovery 功能（译者注：分布式系统中自动发现服务的机制，用于简化服务的发现和交互过程。）可确保 Agents 之间的通信顺畅。Agents 之间的对话历史记录被存储在数据库中，以便在出现故障时，任何备用的 Agents 都能无缝地继续讨论。这种遇到故障及时恢复的弹性通过一个消息队列得到了增强，只有当消息被消费者完全处理并确认后，消息队列才会将这个消息标记为已处理，从而确保消息不会丢失或重复处理。为了保持对话的流畅性，每个 AI Agents 目前被限制为只有一个实例运行，尽管 Kubernetes 能够确保在 Pod 下线时系统仍然运行正常。
Image by the author
为了方便用户在本地环境中试用该系统，我们编写了一个在 MiniKube 环境中部署该系统的 YAML 文件。在这个简化版本的系统中，我们省略了 postgres 数据库，每个 Agents 都暂时将其对话历史记录存储在内存中。这一调整使得该系统更加轻便，更适合本地部署，同时还保留了其核心功能。你需要首先在操作系统上安装 MiniKube[11]、Ollama[12] 和 kubectl[13]。
将上述内容保存到名为 deploy.ymland 的文件中，然后运行：
开始辩论（minikube 在 Linux 系统和 Windows 系统上的使用方式略有不同）：
获取辩论记录：
删除系统资源：
这些 Agents 接着进行了一场精彩的辩论（见文末附录中的辩论记录）。
对 Multi-Agent 系统的兴趣为创新和提高效率带来了无限可能。通过应用云原生的一些原则和最佳实践，我们可以构建可扩展、成本效益高、安全且高可用性的 Multi-Agent 系统。MAaaS模式不仅与现代软件工程原则相契合，还为更复杂且适合生产环境的人工智能应用开辟了道路。随着我们对这些概念的不断探索和完善，Multi-Agent 系统在各个行业中引发变革的可能性变得越来越大
