设计多智能体智能系统

作者: Maggie Liu, Thiago Rotta, Vinicius Souza, James Tooles & Microsoft AI Co-Innovation Labs

1. 引言

生成式AI正以前所未有的速度从概念验证试点转向企业关键任务工作负载。第一波项目通常部署单一的"全能"智能体，即一个包装了提示工程、向量存储和少量API连接器的大型语言模型。这种模式适用于狭窄的FAQ机器人，但在现实企业约束下会崩溃：

• 跨越数十条业务线的领域专业知识
• 严格的数据主权和模型访问策略
• 需要在不重新部署整个堆栈的情况下插入新功能或交换模型

因此，采用最新AI进展的企业正在转向多智能体系统——通过编排器协调的自主、任务专业化智能体集合，反映了跨职能人类团队处理复杂工作的方式。每个智能体耦合：

• LLM或SLM核心（大型或小型语言模型）
• 领域特定工具集（API、知识图谱、专有数据）
• 短期和长期记忆以随时间完善计划

突破不在于单个智能体的智能，而在于多个智能体共享上下文、分工协作并将结果合并为连贯答案时出现的涌现行为。

2. 问题陈述

尽管LLM驱动的助手在各行业迅速采用，大多数企业实现仍锚定在单智能体架构中，即单个通用智能体负责理解每个请求、调用每个工具并遵守每个策略。虽然这种"集中式智能"模型对于受限用例（如内部FAQ或聊天机器人前端）足够，但在现代企业工作流程需求下会根本性崩溃。

试图扩展此模型的组织遇到了几个结构性挑战：

• 过度泛化：单个智能体尝试服务多条业务线——每条都有其自己的监管、语言和决策细微差别——导致脆弱的提示、通用响应和跨板模型性能下降
• 性能瓶颈：当所有内容都通过单个智能体运行时，系统会变慢——特别是随着更多用户发送请求或任务变得更复杂并需要多个步骤或工具时
• 安全与合规风险：集中访问不同数据集（如金融、医疗、PII等）违反了数据最小化和最小特权访问等核心原则，难以满足监管框架
• 变更管理复杂性：由于所有逻辑、工具和内存都耦合在一个智能体中，添加新功能或领域用例需要对完整堆栈进行回归测试。这显著降低了实现价值的时间，并在平台团队中产生风险规避
• 专业化不灵活：随着用例发展，可以集成新工具、API和模型以纳入最新创新，但单体智能体抵制这种模块化，阻碍创新

继续沿着这条道路前进的企业发现，它们受到的限制不是AI本身的能力，而是围绕AI包装的系统刚性，单个智能体处理多个领域。这导致了创新放缓、运营风险增加，以及与竞争行业现在采用的一流架构日益分歧。

向模块化、多智能体系统的转变不再是研究抱负，对于寻求规模化运营AI的组织来说，这是一个战略要务，随着企业将其现有的单智能体重构为多智能体架构，这种转变正在被越来越多地采用。

3. 解决方案

解决方案不是将单个智能体拉伸到断裂点，而是将工作负载分配到专注于特定领域或功能的专业化智能体，同时中央保持系统协调和上下文感知。这种转变直接导致多智能体架构，其中领域专家智能体在其领域边界内独立处理任务，编排器确保不同组件之间的无缝集成。

在基础层面，此架构由以下组成：

• 专注于专业功能的多个领域智能体（例如，用于电汇的支付智能体，用于投资组合指导的投资顾问智能体）
• 负责意图路由、上下文保存和任务路由的编排器，确保每个查询落在正确的专家智能体上
• 允许智能体有效协作同时向用户呈现统一体验的上下文共享机制

为支持企业级AI系统所需的模块化、可扩展和专业化行为，企业正在采用结合集中编排与分布式智能的分层多智能体架构。如下所示，此架构设计为反映真实世界组织的结构：中央协调器（编排器）将任务委托给专业化智能体，每个智能体都配备了领域特定能力、工具和内存。系统分为清晰的功能层，包括编排、分类、智能体执行、知识检索、存储和集成，允许在规模上实现灵活性、治理和性能。

3.1 组件分解

编排器（语义内核）

中央协调组件，管理整个系统中请求和响应的流。它提供统一管理，确保适当路由、维护上下文和处理请求的生命周期。

工作原理：编排器从用户应用程序接收请求，确定如何处理它们，与适当组件协调，维护状态，并最终返回响应。

分类器（NLU、SLM、LLM）

负责理解用户输入并确定系统内适当路由的组件。它确保用户请求被正确理解并定向到最合适的智能体，提高响应质量和系统效率。

工作原理：分析用户输入的内容、上下文和意图，对其进行分类并确定适当的处理。该方法涉及使用从较便宜到较昂贵选项的范围，NLU → SLM → LLM | SML基于确定性来确定意图或连续性的使用。如果在过程结束时未检测到意图，返回"IDK"（我不知道）。

智能体注册表

维护所有可用智能体、其能力和操作状态信息的目录服务。它支持动态发现和利用智能体，支持可扩展性和系统演进，无需硬编码依赖。

工作原理：维护智能体元数据的数据库，包括能力、端点和操作参数。提供查找和选择功能以识别特定任务的适当智能体。

子组件

• 发现模块
  • 主动识别和注册新智能体
  • 实现发现协议
  • 处理管理员发起的智能体注册
  • 执行网络扫描以定位潜在智能体
  • 管理智能体上线工作流
  • 维护发现历史和重试逻辑
• 验证模块
  • 验证智能体能力和接口
  • 执行安全验证和身份验证
  • 通过探测请求测试智能体功能
  • 确保与系统要求的兼容性
  • 生成用于分类的智能体元数据
• 注册表存储
  • 智能体信息的持久存储
  • 维护版本历史和能力演进
  • 存储安全凭据和访问策略
  • 记录智能体交互指标和性能数据

主管智能体（考虑可扩展性要求可选）

负责协调其他智能体活动以解决复杂任务的专门智能体。它能够将复杂任务分解为可由专门智能体处理的子任务，然后将其输出合成为连贯响应。

工作原理：接收高级任务，将其分解，委托给适当的专门智能体，监控进度，聚合结果，并确保整体任务完成。

最佳实践：

• 监控智能体在知识领域和行动范围方面的重叠，以防止冗余和混淆
• 避免保持高度相似的智能体分开，因为这可能降低编排器或意图分类器的性能
• 重构或将类似智能体分组在共享接口或能力下，以简化分类和路由
• 随着架构跨领域扩展，引入智能体主管——这些组件帮助管理和抽象相关智能体组
• 使用分层组织（例如，主管 → 智能体组）以保持清晰性、可扩展性和意图解析的便利性

智能体 #1、#2、#3、#4（带MCP客户端）

设计用于处理特定领域、任务或能力的专门AI智能体。领域专业化允许在特定领域比通用智能体具有更深入的专业知识和更好的性能。

工作原理：每个智能体专注于特定领域（例如，金融、医疗、编码）或功能（例如，摘要、研究、创意写作），应用专门知识、模型或技术到用户请求。

本地和远程智能体之间的差异：

• 本地智能体在与编排器相同的环境中运行
• 远程智能体跨网络边界操作
• 智能体到智能体通信应通过使用特定标准化协议（如A2A）实现
• 远程智能体需要额外的安全性和可靠性考虑
• 通信模式不同（内存中与网络协议）
• 部署和扩展策略显著不同
• 资源管理方法有实质性差异

对话历史

用户-智能体交互和对话流的持久存储。它支持上下文感知响应，支持从过去交互中学习，并提供系统行为的审计跟踪。

工作原理：记录对话中的每个回合，在结构化、可查询格式中维护用户输入、智能体响应和相关元数据。

智能体状态

智能体操作状态、配置和运行时状态的持久存储。它支持跨会话的连续性、从故障中恢复以及基于过去经验的适应。

工作原理：维护每个智能体的静态配置和动态运行时状态，允许它们恢复操作并维护学习行为。

注册表存储

智能体注册表的专门存储，维护智能体元数据、能力和操作历史。它为智能体注册表提供持久数据层，确保跨系统重启和更新的一致智能体信息。

工作原理：存储关于每个智能体的全面信息，包括能力、端点、安全凭据、性能指标和版本历史。

集成层和MCP服务器

连接智能体到外部工具、服务和数据源的标准化接口层。它提供一致的方式让智能体访问外部能力，无需为每个工具实现自定义集成。

工作原理：实现模型上下文协议（MCP）以将工具作为标准化服务公开，智能体可以发现和调用这些服务。

3.2 关键优势

• 模块化和可扩展性：架构的模块化性质使组织能够逐步演进其AI系统，而不会中断整个堆栈。新的智能体，无论是专注于新领域还是任务，都可以通过智能体注册和编排无缝引入，无需重新训练或重新部署现有组件。
• 领域专业化：不是依赖通用模型或单智能体处理所有用户请求，每个智能体都是为其领域特定主题、规则和数据量身定制的。这确保了更深的准确性、更好的需求对齐和减轻更细微的输出。
• 可扩展性：角色和职责在编排、智能体、知识和存储层等基础层之间的分离，允许系统在领域和用例间水平扩展。智能体可以在本地运行，或者系统可以与远程智能体集成，并且主管可以管理智能体集群，因为系统内专门知识的数量增长。这使企业能够随时间支持数百个任务特定智能体。
• 弹性：一个智能体中的故障不会在整个系统中级联，编排器或智能体主管可以重新路由、重试或回退到其他智能体，使系统具有弹性。

4. 多智能体系统的实现

在设计多智能体系统时，必须从内部评估开始。这包括评估现有资产、团队能力，最重要的是，将从此类系统中受益的业务场景。虽然新技术的诱惑很强，特别是在这个快速发展的空间中，但成功取决于将系统与有意义的业务用例对齐。没有明确的投资回报（ROI），项目有失败的风险。

许多组织选择在现有对话系统之上构建智能体平台，因为基于聊天的界面通常是生成式AI的第一个应用。其他组织选择与更广泛的公司战略对齐，如Microsoft Copilot或Azure Foundry，通过围绕这些平台构建或完全采用其能力。这个战略决策很重要，但超出了本文的范围。

无论选择哪条路径，本文档分享了我们在实现多智能体系统过程中的经验和遇到的挑战。无论您的架构方向如何，我们的见解都适用。

4.1 架构模型

多智能体系统可以设计为单体或分布式系统。每种方法都涉及性能、可扩展性、可维护性、团队协调和操作复杂性之间的权衡。

模块化单体

一个自包含的应用程序，其中编排器和专门智能体被结构化为明确定义的模块。这种方法有利于简单性、共享内存和低延迟通信。

微服务

一种分布式架构，其中每个智能体（或智能体组）被封装为独立服务。此模型支持独立部署、粒度可扩展性以及使用不同工具、框架或编程语言的灵活性。

系统评估与治理

定义系统将如何评估并识别直接影响其行为的组件也至关重要。应用于单个智能体的相同结构化实践——如LLMOps、数据管道、持续评估和CI/CD——应扩展到系统级别，以确保健壮性和与业务目标的对齐。

作为说明系统不同方面如何连接及其可能产生的影响的示例，让我们考虑一个使用RAG（检索增强生成）的知识库智能体。通常，这些智能体使用向量数据库。数据库或索引通常由不同的团队填充，其上的更改可能影响我们知识库智能体的行为。当发生不同更改时，我们失去了对更改及其影响的跟踪。将其放大到所有可能的更改，最终用户可能遇到中断的体验。为避免这种情况，我们建议从一开始就制定版本控制策略，并确保生产环境是密封的。

这是智能体版本控制状态机的建议。注意：不要使用状态字段跟踪版本，版本是不同类型的数据。

智能体注册表与编排

多智能体系统的核心部分是智能体注册表。此服务将负责生成描述智能体的元数据，验证智能体是否实现支持的协议。注册过程可以通过两种方式发生：

• 注册表发起的智能体注册：在智能体可用且有办法获取智能体信息的情况下，注册机制可以向目标智能体URL发出请求以获取智能体信息。要实现此机制，注册机制需要知道在哪里以及如何请求不同的智能体信息端点
• 智能体发起的自注册：或者，注册机制可以是API端点，智能体可以在此"自行"注册到注册表。要实现此机制，注册机制需要提供一个端点，智能体可以访问以提供其智能体信息

在高度监管的市场中，很难考虑有自注册路径，特别是当还有上线外部智能体的路由时，有办法处理它，如使用批准工作流，每个用例将确定最合适的选项或两者（如果是这种情况）。

一旦智能体注册，就是定义智能体编排配置的时候，编排器智能体服务将使用另一个描述组成编排器的智能体及其版本的元数据。它基本上定义了智能体及其版本，就像Docker compose配置。

只是强调，强烈建议对编排器和智能体的元数据进行版本控制，避免任何更改影响用户体验。

操作弹性

多智能体系统中的操作弹性始于可观察性。虽然本文不深入探讨可观察性，因为其他地方有广泛覆盖，但重要的是要承认，没有它，就无法实现弹性。

假设可观察性到位，下一步是定义应测量什么以及系统应如何响应以确保弹性。这包括监控智能体健康、检测故障和实现恢复机制。

健康检查是基础性的。必须连续监控智能体，无论它们是本地部署还是远程部署。在中断或故障事件中，应自动触发重试策略。这些在弹性架构中很常见，有助于保持服务连续性。

对于生成式AI应用，需要额外考虑：

• 令牌消耗监控对于避免意外成本激增或性能下降至关重要。系统应跟踪使用模式并强制执行阈值或警报
• 必须有回退机制来处理令牌限制被超过或模型响应失败的场景。这可能包括切换到较小模型、使用缓存响应或优雅地降级功能

弹性还应考虑整个智能体生命周期。这包括：

• 智能体及其依赖项的版本控制
• 生产环境的隔离以防止意外副作用
• 上游和下游更改的影响跟踪（例如，RAG基础智能体使用的向量数据库的更新）

通过主动设计故障和恢复，并确保系统行为是可观察、可测量和可操作的，团队可以构建健壮、可靠且与业务连续性目标对齐的多智能体系统。

参考：

• 监控和警报：Azure AI Foundry包括内置仪表板并与Azure Monitor集成，用于跟踪指标（例如，令牌使用、智能体性能）和设置主动警报。监控Azure AI Foundry智能体服务 – Azure AI服务 | Microsoft Learn
• 多智能体参考架构

安全

生成式AI应用引入了一套超越传统软件系统的新安全风险。这些包括威胁，如模型幻觉、提示注入攻击、数据泄漏和旨在操纵模型行为的对抗性输入。

一个特别令人担忧的向量是提示注入，恶意用户制作输入以改变智能体的预期行为或绕过保护措施。这些攻击可能很微妙且难以检测，特别是在严重依赖自然语言输入的系统中。

在Microsoft，我们的团队通过AETHER（工程与研究中的AI与伦理）委员会的工作积极应对这些挑战。作为此倡议的一部分，我们开发了一个专门为AI系统量身定制的威胁建模框架，我们在整个开发生命周期中应用此框架。此框架有助于早期识别和减轻风险，确保安全嵌入多智能体系统的设计中。

我们还发布了关于安全部署实践和负责任AI使用的指南，其中包括：

• 输入验证和清理
• 智能体和编排层的基于角色的访问控制
• 智能体交互的日志记录和审计跟踪
• 敏感数据和模型输出的隔离
• 速率限制和滥用检测机制

虽然本文不涵盖AI安全的全部范围，但我们强烈建议从一开始就集成威胁建模和安全开发实践。安全不应是事后考虑；它必须是任何GenAI系统架构的基础支柱。

• 令牌配额增加：客户应请求增加Azure OpenAI模型的令牌配额（例如，GPT-4o、GPT-4o-mini、O系列），以避免随着使用扩展而出现速率限制。
• 区域资源部署：跨不同区域部署多个Azure OpenAI资源以处理API请求、减少延迟并减轻速率限制。
• 专用网络和安全：Azure AI Foundry智能体服务支持专用网络隔离，使客户能够安全地托管智能体、与用户管理的身份集成并强制执行严格的"默认拒绝"网络规则。如何将虚拟网络与Azure AI Foundry智能体服务一起使用 – Azure AI Foundry | Microsoft Learn。

客户用例

ContraForce

以下三个案例研究来自与Microsoft AI Co-Innovation Labs的客户合作伙伴关系，这是一个全球AI专家团队，共同构建加速客户部署的gen AI解决方案。ContraForce、Stemtology和SolidCommerce在旧金山的AI Co-Innovation Lab中构建了他们的多智能体原型，实验室团队工程师使用为Azure Cloud优化的多模态、多智能体工作流定制gen AI解决方案。

ContraForce为MSSP提供在Azure上运行的多租户、多智能体系统。 ContraForce是一家网络安全软件公司，提供智能体安全交付平台（ASDP），使托管安全服务提供商（MSSP）能够通过自动化跨数十甚至数百个客户环境的Microsoft Security应用程序的托管服务交付来规模化运营。通过将Microsoft Sentinel和Microsoft Defender XDR等工具集中到统一的多租户平台中，ContraForce为MSSP提供了必要的基础设施、工作流和编排层，以驱动高效、高利润的托管安全服务。

与软件供应商托管和运营单个智能体的传统模型不同，ContraForce采用了多租户、多智能体系统。此设计允许MSSP为每个托管租户和客户实例化专用的、上下文感知的智能体，每个智能体都基于租户特定上下文和工作流。这些智能体充当虚拟安全服务交付分析师，MSSP团队的自主扩展，专门为每个客户的上下文、工作流和服务级别要求量身定制。ContraForce抽象了智能体编排、协调和托管的复杂性。MSSP不需要自己管理AI基础设施；他们只需定义每个客户的服务意图和要求。ContraForce处理其余部分。

ContraForce ASDP：多租户、多智能体系统 当ContraForce在其预览阶段评估Microsoft的AI智能体服务时，高度可扩展且多租户友好的架构与此模型完美对齐。它使ContraForce能够在每个客户环境中部署独立、智能的智能体，同时仍然是协调、共享框架的一部分。此能力使得可以在不同的客户环境中提供一致、高质量的安全自动化，而不会引入操作瓶颈或冒服务降级的风险。由中央编排层协调，多租户、多智能体系统为专门智能体生态系统提供了基础，其中一些专注于检测，其他专注于响应，还有一些专注于保存机构知识。

在不到一个月的时间内，ContraForce推出了第一个为MSSP量身定制的多租户服务交付智能体的原型。此Microsoft Security的服务交付智能体使用专有的ContraForce Gamebooks自动化警报分类、事件调查、恶意意图确定和引导响应执行。

服务交付智能体使MSSP能够管理每个分析师3倍的客户，双倍事件调查能力，并在不需要专门的安全和AI工程团队的情况下解锁新的业务模型。对于ContraForce，它还验证了通过领域特定工作流、用户界面和服务逻辑应用多智能体AI系统是将AI从实验室过渡到现实世界专业服务的关键；并为我们提供了清晰的视线以实现我们预计的300%年同比顶线增长。

Stemtology使用AI治疗骨关节炎

此案例研究是来自Microsoft AI Co-Innovation Labs的原始故事的转载。 与Microsoft AI Co-Innovation Labs合作的最大好处是能够快速达到POC并开始测试。我们能够与实验室团队的工程师快速设计，为高效数据清理创建基础设施，并无缝协调构建出一些本来需要我们的团队约3个月时间的东西，在几周内完成。" – Annalina Che, CEO, Stemtology

再生医学是一个快速发展的领域，承诺为以前无法治愈的疾病提供疗法，并帮助推进医学研究。Stemtology是这个关键空间的创新者，用AI驱动技术加速有效的疾病治疗。他们的AI平台集成大型语言模型（LLM）和图神经网络（GNN）以假设、模拟和优化炎症、免疫和退行性疾病的治疗计划。

Stemtology的工作解决了其行业中的已知限制，如缓慢的实验时间、孤立的研究发布和压倒性的数据复杂性。即使他们在应对这些挑战，Stemtology团队也需要与"最好的中的最好"合作，在Azure中构建可扩展的原型并获得解决方案的后端支持。

他们与Microsoft AI Co-Innovation Labs合作，构建一个生成式AI解决方案，可以找到和分析医学研究数据，并为骨关节炎生成治疗计划，计划以后将此解决方案应用于其他疾病。

在实验室中

我们在旧金山的AI Co-Innovation Lab团队带来了我们在使用Microsoft Azure和AI技术构建gen AI原型方面的丰富经验，以合作多智能体研究和开发解决方案。

实验室团队利用Azure OpenAI GPT和Azure Cognitive Search进行数据处理、假设生成和验证。他们还利用他们对尖端Microsoft技术的广泛知识，使用全新的Azure AI智能体服务，赋予Stemtology更强大和可扩展的智能体AI。

Stemtology智能体工作流 第一组智能体充当研究助理，从PubMed数据库搜索医学研究并提取该数据以获取见解和报告。下一个智能体获取该研究并根据疾病特定研究生成骨关节炎治疗计划，然后科学团队可以分析和测试这些研究。

此解决方案直接集成到Stemtology的业务模型中，充当研究和开发引擎，并与实验室团队的科学家协同工作，以加速合成细胞疗法的设计、测试和优化。

解决方案影响

Stemtology已经看到他们的解决方案与其科学团队的好处，包括显著的操作成本节约和减少在劳动密集型任务（如阅读和分析研究论文）上花费的时间。因此，科学家可以将重点转移到更高级的设计任务并探索其他疾病治疗。

在部署解决方案时，Stemtology期望实现更大的成果：

• 将实验时间线缩短高达50%
• 实现≥90%的治疗结果预测准确性，确保可行和有效的治疗解决方案
• 扩展解决方案以管理超过100种疾病
• 改善每种治疗疾病的再生结果

这种gen AI的高级应用将Stemtology定位为再生医学的领导者，通过加速药物发现和改善个性化治疗的可及性，为医疗提供者、研究人员和患者提供变革性好处。

通过与我们在AI Co-Innovation Labs的专家团队合作，Stemtology可以利用Azure中智能体AI的力量实现和扩展此解决方案。 引自Annalina Che, CEO, Stemtology。

用例3：SolidCommerce

SolidCommerce：零售行业的AI解决方案

SolidCommerce专门为零售行业提供量身定制的人工智能解决方案。公司专注于利用AI和机器学习技术帮助零售商优化操作、增强客户体验并驱动销售增长。通过利用数据驱动的见解，SolidCommerce授权零售商做出明智决策并在市场中保持竞争优势。

使命：

SolidCommerce的使命是使零售商能够解锁AI和机器学习的力量，以简化操作、改善客户参与并实现可持续增长。通过创新解决方案，他们旨在改变零售格局并帮助企业在快速变化的环境中蓬勃发展。

SolidCommerce产品的关键特性：

• 库存管理的预测分析：SolidCommerce提供使零售商能够预测需求、优化库存水平和降低成本的工具。通过分析大型数据集，他们的预测分析平台帮助零售商做出关于库存、供应链和定价策略的明智决策。
• 客户行为分析：SolidCommerce的解决方案分析客户互动和行为以发现可操作的见解。这使零售商能够更好地了解他们的受众并调整策略以改善满意度和忠诚度。
• 个性化营销策略：通过基于偏好、行为和购买历史对客户进行细分，SolidCommerce帮助零售商提供量身定制的促销和产品推荐。这些个性化互动增强了购物体验并有助于增加销售。

SolidCommerce专注于将AI驱动技术与零售流程集成，确保企业能够高效适应不断发展的市场趋势、优化其操作并创造有意义的客户体验。通过帮助零售商利用数据的力量，SolidCommerce正在塑造行业的未来并驱动各种规模企业的增长。

AI用例

SolidCommerce：AI驱动的商家协助平台 SolidCommerce正在开发一个AI智能体驱动的平台，旨在帮助商家高效响应客户查询。该平台利用Azure Blob Storage、Azure AI Search和Function Apps从多个源检索和处理数据，确保准确和上下文特定的响应。通过自动化数据检索、响应生成和商家批准工作流，此系统提高了生产力，同时保持高响应相关性和准确性。

我们的第一个AI创新 第一个AI创新是一个用于托管数据检索和响应生成的多模态商家协助平台。

该平台集成多个Azure AI服务以：

• 从各种源检索数据，包括产品列表、发货跟踪和商家政策
• 使用AI Search和向量嵌入为上下文接地生成对客户查询的响应
• 启用商家批准工作流，以确保响应在发送前与业务策略对齐

开发方法 商家协助平台正在使用Azure云技术开发，利用尖端AI能力和服务以实现无缝数据集成、智能处理和可扩展工作流。该平台包含：

• Azure Blob Storage：包含产品和订单数据的文件被上传和索引。
• Azure AI Search：索引器处理数据以创建嵌入，启用高效的向量和关键字搜索能力。
• Function Apps：API提供实时数据检索，如发货跟踪、订单详细信息和商家政策。
• Azure AI智能体服务：AI智能体编排这些服务以，查询索引数据以进行精确信息检索。处理客户查询并生成基于可靠数据源的草稿响应。通过销售渠道（例如，eBay、Amazon）过滤搜索结果并定制响应。

价值和影响 SolidCommerce AI平台旨在通过以下方式授权商家：

• 提高效率：自动化数据检索和响应生成，减少客户服务任务所需的时间
• 增强准确性：结合向量搜索和关键字搜索以进行精确、上下文相关的响应
• 可扩展性：支持具有单独索引和销售渠道特定过滤的多个公司
• 简化工作流：启用商家审查和批准AI生成的响应，以确保合规性和质量

架构图

结论

对于跨企业扩展生成式AI的技术架构师和开发人员来说，单智能体系统的限制已经变得越来越明显。虽然对于快速原型设计有用，但这些早期架构很快变得刚性、难以治理，并且无法满足企业需求，如跨领域智能、不断发展的工具链以及严格的合规和安全标准。

多智能体架构为构建企业级AI系统提供了一个可扩展、有弹性且面向未来的基础。通过将职责分配到专门智能体，每个智能体都有自己的模型、工具和内存，并通过中央编排器协调它们的行动，组织获得了模块化、改进的故障容忍度和更清晰的关注点分离。这种方法不仅与既定的软件工程实践对齐，而且支持与现有企业系统和API更好的互操作性。

关键的是，多智能体系统增强了可观察性、可审计性和合规性，使企业能够强制执行策略、监控性能并在规模上维护治理。它们还支持人在环协作，其中智能体可以增强而不是取代人类专业知识，特别是在高风险领域。

从战略角度来看，这种架构转变授权企业在智能体中保留领域特定知识，通过动态分配工作负载优化计算成本，并通过可重用、可组合的智能体模式加速实现价值的时间。随着时间的推移，智能体演变为编码机构记忆的智能组件，提供持续的业务差异化。

最终，采用多智能体平台不仅仅是技术演进——这是对构建自适应、合规和智能系统的长期投资，这些系统可以随着业务需求扩展，交付有形价值，并随着企业优先事项演进。