Microsoft 设计多智能体系统

1. 引言

生成式人工智能正以企业技术领域罕见的速度，从概念验证试点转向关键业务负载。第一波项目通常只搭建单一的 “全能型” 智能体 —— 一个封装了提示工程、向量库与少量 API 连接器的大语言模型。这种模式适用于窄场景的 FAQ 机器人，但在真实企业约束下会迅速失效：

• 覆盖数十条业务线的领域专业知识
• 严格的数据主权与模型访问策略
• 无需夜间重新部署全栈即可接入新能力或替换模型的需求

因此，采用最新 AI 技术的企业正转向多智能体系统：一组自主化、特定任务的智能体，通过调度器协同工作，模拟跨职能人类团队处理复杂任务的方式。每个智能体包含：

• 大语言模型（LLM）或小语言模型（SLM）核心
• 领域专用工具集（API、知识图谱、私有数据）
• 长短时记忆，用于持续优化规划

其突破点并非单个智能体的智能，而是多个智能体共享上下文、分工协作、合并结果形成统一回答时涌现出的整体行为。

2. 问题阐述

尽管基于大语言模型的助手在各行业快速落地，大多数企业实现仍停留在单一智能体架构：由一个通用智能体负责理解所有请求、调用所有工具、遵守所有策略。这种 “集中式智能” 模型适用于受限场景（如内部 FAQ、入门级聊天机器人），但在现代企业工作流需求下会彻底失效。

试图规模化该模式的组织面临以下结构性挑战：

• 过度泛化：单一智能体试图服务多条业务线（各有监管、语言、决策差异），导致提示脆弱、回答通用、整体模型性能下降。
• 性能瓶颈：所有流量流经单一智能体，系统随用户增多、任务复杂化而变慢。
• 安全与合规暴露：集中访问金融、医疗、个人身份信息（PII）等多样数据集，违背数据最小化、最小权限原则，难以满足监管框架。
• 变更管理复杂：所有逻辑、工具、内存耦合在一个智能体中，新增功能需全栈回归测试，大幅拖慢价值交付并引发平台团队风险规避。
• 专业化灵活性不足：单体智能体难以模块化集成新工具、API 与模型（如本地推理轻量 SLM、垂直领域微调模型），阻碍创新。

继续沿用单一智能体路线的企业，其限制并非来自 AI 本身，而是系统架构的僵化。这导致创新放缓、运营风险升高，并与领先架构逐渐脱节。

向模块化、多智能体系统转型已不再是研究愿景，而是企业规模化落地 AI 的战略必需。越来越多企业正在将现有单一智能体架构重构为多智能体架构。

3. 解决方案

解决方案不是将单一智能体压榨到极限，而是将工作负载分发到专用智能体，每个智能体专注特定领域或功能，由中央组件保持系统协同与上下文感知。这直接形成多智能体架构：领域专家智能体在各自领域内独立处理任务，调度器确保各组件无缝集成。

该架构基础组成：

• 多个专注特定功能的领域智能体（如汇款支付智能体、投资顾问智能体）
• 负责意图路由、上下文保留、任务分发的调度器
• 支持智能体高效协作并向用户呈现统一体验的上下文共享机制

为支撑企业级人工智能系统所需的模块化、可扩展、专业化能力，企业正采用分层式多智能体架构，将集中式编排与分布式智能相结合。

如下所示，该架构旨在模拟现实世界的组织架构：由中央协调器（编排器）将任务委派给各类专业化智能体，每个智能体均具备领域专属能力、工具与记忆。系统划分为清晰的功能层，包括编排调度、任务分类、智能体执行、知识检索、数据存储与系统集成，在大规模部署下实现灵活性、可管控性与高性能。

3.1 组件拆解

调度器（Orchestrator ,语义内核）

• 系统核心协调组件，管理系统的请求与响应流，提供统一管理、合理路由、上下文维护与请求生命周期管理。

• 工作方式：接收用户应用请求，确定处理方式，协调对应组件，维护状态，最终返回响应。

分类器（自然语言理解 NLU、小语言模型 SLM、大语言模型 LLM）

• 负责理解用户输入并确定系统内合理路由，确保请求被正确理解并导向最合适智能体，提升回答质量与系统效率。

• 工作方式：分析用户输入内容、上下文、意图，进行分类并确定处理方式。采用从低成本到高成本的递进方案：NLU → SLM → LLM/SLM，依据置信度判断意图或继续推理。若最终未识别意图，返回 “IDK（我不知道）”。

Agent Registry 智能体注册中心

维护所有可用智能体信息、能力与运行状态的目录服务，支持动态发现与使用，无需硬编码依赖即可实现扩展性与系统演进。

工作方式：维护智能体元数据数据库（能力、端点、运行参数），提供查询与选择功能，为特定任务匹配合适智能体。

子组件：

• 发现模块：主动识别并注册新智能体；实现发现协议；处理管理员发起的注册；网络扫描定位潜在智能体；管理上线流程；保留发现历史与重试逻辑。
• 验证模块：验证智能体能力与接口；安全验证与身份认证；探针请求测试功能；确保系统兼容；生成分类用元数据。
• 注册中心存储：持久化智能体信息；保留版本历史与能力演进；存储安全凭证与访问策略；记录交互指标与性能数据。

监督智能体（Supervisor Agent ,可选，视扩展性需求）

专用智能体，负责协调其他智能体完成复杂任务，将复杂任务拆解为子任务由专用智能体处理，再合成输出连贯回答。

工作方式：接收高层任务 → 拆解 → 委派 → 监控进度 → 聚合结果 → 确保完成。

一种专用智能体，负责协调其他智能体以完成复杂任务。将复杂任务拆解为子任务由专用智能体处理，并将它们的输出合成为连贯一致的结果。

工作机制：接收高层任务 → 任务分解 → 委派给对应专业智能体 → 监控执行进度 → 汇总结果 → 确保整体任务完成。

最佳实践：

• 监控各智能体在知识领域与行动范围上的重叠情况，避免冗余与混乱。
• 避免将高度相似的智能体分开独立部署，这会降低编排器或意图分类器的性能。
• 对相似智能体进行重构或分组，通过统一接口或能力封装，简化分类与路由逻辑。
• 当架构跨领域扩展时，引入智能体监管器，用于管理和抽象相关智能体群组。
• 采用分层组织架构（如：监管器 → 智能体组），保证结构清晰、可扩展，并简化意图解析。

智能体 #1, #2, #3, #4（带模型上下文协议 MCP 客户端）

专为处理特定领域、任务或能力而设计的专业化 AI 智能体。相较于通用型智能体，领域专业化能在特定场景中提供更深度的专业能力与更优表现。

工作机制：每个智能体专注于某一特定领域（如金融、医疗、代码开发）或功能（如摘要生成、信息调研、创意写作），针对用户请求应用专业知识、模型或技术。

本地智能体与远程智能体的区别：

• 本地智能体与编排器运行在同一环境中
• 远程智能体跨网络边界运行
• 智能体间通信应通过标准化协议实现，例如 A2A
• 远程智能体需要额外考虑安全性与可靠性
• 通信模式不同（内存内通信 vs 网络协议）
• 部署与扩缩容策略差异显著
• 资源管理方式存在本质区别

对话历史

• 用户 - 智能体交互与对话流的持久化存储，支持上下文感知回答、从历史交互学习，并提供系统行为审计轨迹。
• 工作方式：结构化、可查询格式记录对话每一轮：用户输入、智能体响应与相关元数据。

智能体状态

• 对智能体的运行状态、配置信息与运行时状态进行持久化存储。支持跨会话保持连续性、故障恢复，以及基于历史经验的自适应调整。
• 工作机制：为每个智能体同时维护静态配置与动态运行时状态，使其能够恢复执行并保留已学习到的行为模式。

注册中心存储

• 用于智能体注册中心的专用存储，负责维护智能体元数据、能力信息与运行历史。它为智能体注册中心提供持久化数据层，确保在系统重启与更新过程中，智能体信息保持一致。
• 工作机制：存储每个智能体的完整信息，包括能力、服务端点、安全凭证、性能指标与版本历史。

集成层与 MCP 服务器

• **标准化接口层：**用于连接智能体与外部工具、服务和数据源。它为智能体提供统一的外部能力调用方式，无需为每个工具单独开发定制化集成。
• 工作机制：通过实现模型上下文协议（MCP），将各类工具封装为标准化服务，供智能体自动发现与调用。

3.2 核心优势

• 模块化与可扩展性：架构的模块化特性支持企业渐进式迭代升级 AI 系统，无需中断整个技术栈。通过智能体注册与编排，可无缝接入专注于新领域或新任务的新增智能体，无需对现有组件重新训练或重新部署。
• 领域专业化：不再依赖单一通用模型或单个智能体处理所有用户请求，每个智能体均针对特定领域的主题、规则与数据专门构建并精调优化。这能确保更高的准确率、更贴合业务需求，并减少不合规或模糊的输出。
• 可扩展性：通过对编排层、智能体层、知识层、存储层等基础层进行职责分离，系统可跨领域、跨场景横向扩展。智能体既可本地运行，也可集成远程智能体；随着系统内专业知识类型增多，监管器可统一管理智能体集群，支持企业逐步承载数百个专用任务智能体。
• 容错与稳定性：单个智能体发生故障时不会引发系统级联失效，编排器或智能体监管器可对任务进行重新路由、重试或降级切换至其他智能体，保障系统高可用与强韧性。

4. 多智能体系统实施

设计多智能体系统必须先开展内部评估：评估现有资产、团队能力，以及最关键的 —— 可从该系统受益的业务场景。新技术吸引力强，但成功关键在于系统与有意义业务场景对齐。无明确投资回报（ROI），项目易失败。

许多组织在现有对话系统上构建智能体平台，也有组织与微软 Copilot、Azure Foundry 等公司战略对齐，围绕或直接采用其能力。该战略决策意义重大，但不在本文讨论范围内。

无论选择何种路径，本文分享我们实施多智能体系统的经验与遇到的挑战，见解适用于任何架构方向。

4.1 架构模式

多智能体系统可设计为单体式或分布式系统，两种方案在性能、扩展性、可维护性、团队协作与运营复杂度上各有取舍。

模块化单体

独立应用，调度器与专用智能体为定义清晰的内部模块，优势：简单、共享内存、低延迟通信。

微服务

分布式架构，每个 / 每组智能体封装为独立服务，支持独立部署、细粒度扩展，可灵活使用多样工具、框架与编程语言。

系统评估与治理

同样至关重要的是，定义系统的评估方式，并识别直接影响其行为的组件。适用于单个智能体的规范化实践（如大模型运营 LLMOps、数据流水线、持续评估、CI/CD 等），也应延伸至系统级，以确保系统具备健壮性并与业务目标保持一致。

为说明系统各模块如何关联及其可能产生的影响，我们以一个采用检索增强生成（RAG） 技术的知识库智能体为例。这类智能体通常会使用向量数据库，而数据库或索引一般由其他团队负责维护，其变更会直接影响知识库智能体的行为。一旦发生各类变更，我们若无法追踪变更内容与影响范围，当此类变更不断增多，最终用户就可能遭遇功能异常、体验受损的情况。为避免这一问题，我们建议从项目初期就制定版本管理策略，并确保生产环境处于受控、封闭的稳定状态。

这是一份针对智能体版本管理所设计的状态机建议。注意：请勿使用state 字段来追踪版本，版本属于另一类独立的数据。

智能体注册中心与调度

多智能体系统的核心是智能体注册中心（Agent Registry）。该服务负责生成描述智能体的元数据，并验证智能体是否实现了系统支持的协议。注册流程可通过两种方式实现：

• 注册中心发起的智能体注册：当智能体已部署且可获取其信息时，注册机制可向目标智能体 URL 发起请求，以获取智能体信息。实现该机制需要注册中心知晓不同智能体信息接口的访问地址与方式。
• 智能体发起的自主注册：另一种方式是，注册机制提供一个 API 接口，供智能体将自身信息 “主动” 注册到注册中心。实现该机制需要注册中心提供一个可被智能体访问的接口，用于接收并录入智能体信息。

在监管严格的行业中，开放自主注册路径难度较大，尤其是在需要接入外部智能体的场景下。可通过引入审批工作流等方式进行处理，具体场景将决定采用哪种最合适的方案，或两种方案并行。

智能体完成注册后，即可定义智能体编排配置。编排器智能体服务将使用另一组元数据，来描述组成编排体系的智能体及其版本。该配置本质上是指定智能体与对应版本，类似于 Docker Compose 配置。

在此再次强调：强烈建议对编排器与智能体的元数据进行版本管理，避免任何变更影响最终用户体验。

运营韧性

多智能体系统的运行韧性，首先建立在可观测性之上。尽管本文不对可观测性展开深入探讨（相关内容已有大量资料覆盖），但必须明确：没有可观测性，就无法实现韧性。

在具备可观测性的前提下，下一步是定义需要度量的指标以及系统应如何响应，以保障韧性。这包括监控智能体健康状态、检测故障，并实现恢复机制。

健康检查是基础。无论智能体是本地部署还是远程部署，都必须对其进行持续监控。当出现中断或故障时，应自动触发重试策略。这是韧性架构中的通用做法，有助于维持服务连续性。

对于生成式 AI 应用，还需要额外关注：

• Token 用量监控至关重要，可避免成本突增或性能下降。系统应追踪使用模式，并设置阈值与告警。
• 必须具备降级 / 备用机制，以应对 Token 超限、模型响应失败等场景。例如：切换到更小模型、使用缓存结果，或优雅降级功能。

韧性设计还应贯穿智能体的整个生命周期，包括：

• 智能体及其依赖项的版本控制
• 生产环境隔离，避免意外副作用
• 对上下游变更进行影响追踪（例如基于 RAG 的智能体所使用的向量数据库更新）

通过主动设计故障与恢复流程，并确保系统行为可观测、可度量、可处置，团队能够构建出健壮、可靠且符合业务连续性目标的多智能体系统。

安全

生成式人工智能应用带来了一系列有别于传统软件系统的全新安全风险，其中包括模型幻觉、提示词注入攻击、数据泄露，以及为操纵模型行为而设计的对抗性输入等威胁。

提示词注入是一类尤为值得警惕的攻击途径：恶意用户会精心构造输入内容，篡改智能体的预期行为，或绕过系统的安全防护机制。这类攻击手段往往较为隐蔽，难以被检测，在高度依赖自然语言输入的系统中更是如此。

在微软，我们的团队正通过AETHER（工程与研究领域的人工智能与伦理）委员会的工作，积极应对这些挑战。作为该计划的一部分，我们研发了一套专为人工智能系统打造的威胁建模框架，并将其应用于整个开发生命周期。这一框架有助于尽早识别并缓解安全风险，确保安全设计被深度融入多智能体系统的架构中。

我们还发布了关于安全部署实践与负责任的人工智能使用规范指南，核心内容包括：

• 输入验证与清洗
• 针对智能体和编排层的基于角色的访问控制
• 智能体交互行为的日志记录与审计追踪
• 敏感数据与模型输出的隔离保护
• 限流机制与滥用行为检测

尽管本文并未全面覆盖人工智能安全的所有范畴，但我们强烈建议从项目初期就整合威胁建模与安全开发实践。安全绝非事后补救的措施，而必须成为所有生成式人工智能系统架构的核心基石。

结论

对于在企业内部规模化落地生成式 AI 的技术架构师与开发者而言，单智能体系统的局限性已日益凸显。这类架构虽然适用于快速原型验证，但会迅速变得僵化、难以治理，且无法满足企业级诉求 —— 如跨领域智能能力、持续演进的工具链、严格的合规与安全标准等。

多智能体架构为构建企业级 AI 系统提供了可扩展、高韧性、面向未来的基础。通过将职责分配给多个专业化智能体（每个智能体拥有独立模型、工具与记忆），并通过中央编排器统一协调行为，企业可以获得模块化、更强的容错能力与更清晰的职责分离。这种思路不仅与成熟的软件工程实践一致，还能更好地与现有企业系统及 API 实现互操作。

至关重要的是，多智能体系统提升了可观测性、可审计性与合规能力，支持企业在规模化场景下有效执行策略、监控性能、保持治理可控。它还支持人在回路的协作模式：智能体作为人类专业能力的增强，而非替代，尤其适用于高风险领域。

从战略视角看，这一架构转型使企业能够：

• 在智能体中沉淀领域专属知识
• 通过动态分配任务优化计算成本
• 通过可复用、可组合的智能体模式加速价值落地周期

长期来看，智能体将逐步演化为承载企业内部知识的智能组件，为业务带来持续的差异化竞争力。

总而言之，采用多智能体平台不只是一次技术升级，更是一项长期投资：用于打造自适应、合规、智能化的系统，使其能够随业务需求规模化扩展、交付实际价值，并与企业战略目标同步演进。

来源：https://developer.microsoft.com/blog/designing-multi-agent-intelligence