Queen-Bee 智能体：以 BeeSpec 为中心的企业 MCP 编排管控架构

# Queen-Bee 智能体：一种以 BeeSpec 为中心的企业受控 MCP 编排架构
来源：https://arxiv.org/html/2606.06545  
（技术报告 / arXiv 预印本）

###### 摘要

企业智能体系统越来越需要将大语言模型连接到私有工具、内部知识和模型上下文协议（MCP）接口。在这种场景下，原始任务能力是不够的：组织还需要策略执行、租户级隔离，以及保持在明确操作边界内的执行。我们提出 **Queen-Bee**，一种受控的多智能体架构，其中 Queen 控制平面检索能力、规划任务范围内的执行，并编译出结构化的 **BeeSpec**，由专门的 Bee 智能体在受限工具访问下执行。我们实现了一个工作原型，包含租户范围的 MCP 连接器、审计支持的运行时治理、检索驱动的弱孵化功能，以及多种配置后端。我们在 59 个企业风格任务上评估了系统，涵盖治理敏感请求、检索驱动配置、作用域内本地执行和化学工作流集成。检索驱动的 Queen-Bee 变体在任务成功率达到 0.964，零治理失败，并且作用域内执行质量显著优于静态 Queen-Bee 基线和宽松的单智能体基线。我们进一步展示了一个多 Bee 化学工作流，包含明确的审批门控，以及基于真实上游证据和筛选工件的具体前三名候选名单。与混合检索和 LLM 引导配置的额外比较表明，更丰富的配置后端是可行的，但在当前小型、高度结构化的能力注册表上并未超越轻量级结构化检索器。这些结果提供了原型层面的系统证据，而非生产部署研究，并表明企业智能体平台不仅应根据能力来评估，还应考虑受控配置、隔离行为、作用域内执行质量以及工件感知的工作流协调。

关键词：LLM 智能体；模型上下文协议；多智能体系统；工具治理；租户隔离；检索增强配置；企业软件架构

## 1 引言

近年来基于 LLM 的智能体系统能够调用工具、访问结构化资源，并在外部系统上执行工作流。然而，企业部署带来的问题与开放领域的智能体评估截然不同。在企业私有 MCP 环境中，智能体不仅需要完成任务，还必须尊重部门边界、租户隔离、工具治理和审计要求。一个通过调用错误工具或跨越租户边界完成任务的系统，即使最终结果看似有用，在操作上也是不可接受的。

这一观察促使我们从单体、广泛权限的智能体转向受控、角色约束的编排。我们认为，企业主要需要的不是一个拥有无限制工具访问权限的通用智能体，而是一个能够配置专门执行单元、分配受限能力、并强制执行运行时策略约束的系统。

为支持这一观点，我们提出 **Queen-Bee**，一种用于企业 MCP 集成的受控多智能体架构。核心设计决策是通过结构化中间表示 **BeeSpec** 分离规划与执行。Queen 不是直接将请求发送给执行智能体，而是首先检索相关能力，规划执行边界，并编译一个 BeeSpec，其中包含 Bee 的角色、附加技能、允许的 MCP 工具、租户范围、记忆范围以及策略配置文件。然后，执行在这些约束下进行。

本文做出四项贡献：

1.  我们提出了一种以 BeeSpec 为中心的架构，将企业智能体控制平面与执行平面分离。
2.  我们实现了一个受控原型，包含租户范围的 MCP 连接器、真实的 stdio MCP 适配器、检索驱动弱孵化以及审计支持的运行时策略检查。
3.  我们设计了一个包含三部分的评估，涵盖隔离与治理、检索驱动配置、以及在 59 个企业风格任务上的作用域内 Bee 执行。
4.  我们比较了多种配置后端，包括轻量级结构化检索、噪声注册表压力检索、混合稀疏+密集检索以及 LLM 引导配置，并表明在当前注册表规模下，轻量级结构化后端仍然最强。

## 2 背景与动机

企业请求很少是单步骤或单边界的任务。招聘工作流可能需要候选人查找、日程安排以及围绕薪酬数据的策略敏感限制。IT 工作流可能需要知识查找、工单创建，并与 HR 系统明确分离。跨租户请求必须被拒绝，即使表面操作看似无害。这些约束暴露了单智能体设计中的一个结构性弱点：广泛能力通常与广泛权限耦合。

现有关于工具使用和多智能体协调的工作表明，语言模型可以在外部环境上行动，并在角色间分解任务[4 (https://arxiv.org/html/2606.06545#bib.bib4),7 (https://arxiv.org/html/2606.06545#bib.bib5),6 (https://arxiv.org/html/2606.06545#bib.bib7),1 (https://arxiv.org/html/2606.06545#bib.bib8)]。然而，企业部署更加强调有界执行、可审计性和租户感知连接。因此，我们的立场并非多智能体系统普遍更好，而是企业 MCP 环境需要一种架构，其中编排、能力分配和运行时治理是显式的一等组件。

## 3 相关工作

最近的 LLM 智能体工作在工具使用、推理-动作耦合以及多智能体角色分解方面取得了显著进展。Toolformer 和 ReAct 展示了两个互补方向：学习或提示模型使用工具，同时交织推理和行动[4 (https://arxiv.org/html/2606.06545#bib.bib4),7 (https://arxiv.org/html/2606.06545#bib.bib5)]。ToolLLM 将此趋势扩展至大型 API 生态系统，强调广泛的工具覆盖而非有界的企业执行[2 (https://arxiv.org/html/2606.06545#bib.bib6)]。多智能体框架如 AutoGen 和 CAMEL 表明，角色专业化的智能体可以在复杂任务上进行协调[6 (https://arxiv.org/html/2606.06545#bib.bib7),1 (https://arxiv.org/html/2606.06545#bib.bib8)]，但它们并未直接解决租户隔离、工具治理或显式执行边界编译。

我们的工作更接近于软件架构和访问控制传统，而非开放式的智能体社会。治理层借鉴了基于角色的访问控制和可执行策略思想[3 (https://arxiv.org/html/2606.06545#bib.bib1),5 (https://arxiv.org/html/2606.06545#bib.bib2)]，而 BeeSpec 抽象则明确分离了控制平面的规划与执行平面的动作。目标不是最大化智能体能够到达的工具数量，而是使能力分配、审计和阶段级工作流协调变得显式且可检查。

## 4 Queen-Bee 架构

### 4.1 概述

Queen-Bee 将执行分为四个层次：

1.  Queen 控制平面，负责能力检索、蓝图规划、BeeSpec 生成和治理决策。
2.  BeeSpec 中间层，明确定义每个 Bee 的执行边界。
3.  Bee 执行平面，其中专门的 Bee 仅在 BeeSpec 分配的能力范围内执行。
4.  租户范围 MCP 连接器层，在活跃租户范围内解析工具调用。

### 4.2 BeeSpec 作为核心中间层

BeeSpec 是规划与执行之间的核心架构接口。它包含 Bee 标识、角色、领域、附加技能、允许的工具、策略配置文件、记忆范围和租户范围。这一层很重要，因为它将配置与执行解耦。Queen 决定 Bee 被允许做什么；Bee 运行时在该约束下执行任务。与单体智能体相比，这种分离使得路由、审计和策略执行更容易推理。

具体来说，原型将每个 BeeSpec 表示为一个结构化记录，包含以下字段：

表 1：BeeSpec 模式，作为 Queen 规划与 Bee 执行之间的中间表示。
### 4.3 Queen 职责

Queen 不是一个通用的执行智能体。它在控制平面运行，执行四个功能：

1.  在 MCP 和技能注册表上的能力检索，
2.  任务范围执行的蓝图规划，
3.  BeeSpec 生成和租户范围 Bee 配置，
4.  通过策略检查和审计日志记录的运行时治理。

### 4.4 Bee 职责

每个 Bee 是一个专门的执行单元，在 BeeSpec 约束下运行。在当前原型中，Bee 被限定在 HR 和 IT 领域。Bee 使用附加技能推导本地工具计划，并在策略层授权后调用租户范围的 MCP 工具。

## 5 原型

我们实现了一个 Python 原型，包含领域范围的企业 Bee、租户范围的 MCP 连接器，以及一个中介每次工具调用的策略引擎。连接器层使用真实的 stdio MCP 适配器，由本地 FastMCP 服务器支持，并带有持久性租户范围会话重用。这使得原型更接近真实的工具调用，而不是模拟的进程内工具注册表，同时仍然允许受控的评估。

该实现的意图是作为原型和评估工具，而非声称达到生产级企业安全。其目的是使控制平面、BeeSpec、连接器和策略边界足够可执行，以衡量路由、配置、隔离和工作流行为。

系统包括两个能力注册表：

- •**MCP 注册表**，包含工具描述、领域、风险级别和租户范围元数据；
- •**技能注册表**，包含可重用的执行技能及其所需的工具依赖。

Queen 可以通过四种后端样式配置 Bee：

1.  轻量级结构化检索，
2.  在更嘈杂注册表下的**压力检索**，
3.  混合稀疏+密集检索，
4.  对检索候选进行 **LLM 引导配置**。

该原型现在还包含一个化学工作流切片。重要的是，这个化学层不再是仅由 MCP 塑造的模拟工具。两个化学 MCP 工具由真实软件或外部数据源支持：`chem.library_property_filter` 使用 RDKit 计算基于描述符的属性过滤器，`chem.literature_evidence_search` 查询 ChEMBL 并用 PubChem 标识符和同义词丰富重定位候选。这使得化学工作流成为一个有意义的系统集成示例，而不仅仅是占位领域。

## 6 实验设计

我们从三个角度评估系统。

### 6.1 实验 1：隔离与治理

此实验衡量系统是否阻止不安全的金融请求、拒绝跨租户请求，并在保持正常任务执行的同时避免不必要的工具使用。关键指标包括金融护栏阻止率、跨租户请求阻止率、租户范围准确率以及错误工具调用。

### 6.2 实验 2：检索驱动配置

此实验衡量 Queen 能否检索相关能力并编译有用的 BeeSpec。关键指标包括检索预期工具覆盖率、检索选定工具精度、技能激活率以及已配置案例数。

### 6.3 实验 3：作用域内 Bee 执行

此实验衡量 Bee 能否在 BeeSpec 约束下独立完成本地任务。关键指标包括 Bee 执行任务成功率、Bee 执行完成率以及 Bee 工具调用正确率。

## 7 评估设置

评估现在包含 59 个企业风格任务，跨越两个租户：

- • 24 个常规 HR 和 IT 任务，
- • 16 个治理敏感任务（金融敏感和跨租户），
- • 16 个仅需部分本地工作流的作用域内执行任务，
- • 3 个用于筛选和重定位的化学工作流任务。

我们比较七个系统：

1.  Queen-Bee（静态）
2.  Queen-Bee（检索）
3.  Queen-Bee（压力检索）
4.  Queen-Bee（混合检索）
5.  Queen-Bee（LLM 配置）
6.  Queen-Bee 无策略
7.  单智能体基线

## 8 结果

### 8.1 主要对比

主要结果表总结了系统级的核心结果。

表 2：59 个企业风格任务的主要评估结果。核心模式是稳定的。检索驱动的 Queen-Bee 在任务成功率和作用域内执行质量上均优于静态系统，同时保持完美的治理行为。无策略和单智能体基线在治理敏感任务上严重失败，完全未实现金融和跨租户阻止。

### 8.2 实验 1：隔离与治理

表 3 (https://arxiv.org/html/2606.06545#S8.T3) 报告了治理敏感子集。所有受控的 Queen-Bee 变体在该子集上均实现了完美阻止和租户范围保持，而无策略和单智能体基线的两个阻止指标完全失败。

表 3：隔离与治理结果。隔离结果是本文最强的部分。所有受控的 Queen-Bee 变体均实现了：
- • 金融护栏阻止率 = 1.0，
- • 跨租户请求阻止率 = 1.0，
- • 租户范围准确率 = 1.0。

相比之下，无策略 Queen-Bee 以及单智能体基线在治理敏感阻止指标上均降至 0.0。这证实了治理贡献不仅仅归结为专业化。

### 8.3 实验 2：检索驱动配置

表 4 (https://arxiv.org/html/2606.06545#S8.T4) 报告了配置导向的子集。轻量级检索驱动的 Queen 仍然是最强的默认后端，而结构化压力变体在当前任务集上略强。

表 4：检索驱动配置结果。在当前能力注册表上，轻量级检索驱动的 Queen 仍然是最强的配置后端：
- • 检索选定工具精度 = 0.979，
- • 已配置案例数 = 8，
- • 任务成功率 = 0.964。

有趣的是，结构化压力检索配置至少同样强大，在当前任务集上略好：
- • 任务成功率 = 0.964，
- • 错误工具调用 = 1，
- • 检索精度 = 0.979。

混合检索是可行的，但未超过轻量级基线。它保持了治理并产生了相同数量的已配置 Bee，但并未提高有效性。LLM 引导配置也保持可行，但性能低于轻量级启发式方法，表明仅靠候选约束的提示还不足以在该注册表规模上超越更强的结构化配置规则。

### 8.4 实验 3：作用域内 Bee 执行

表 5 (https://arxiv.org/html/2606.06545#S8.T5) 报告了作用域内执行子集。关键模式是：更好的配置导致在部分工作流下更完整的本地执行。

表 5：作用域内 Bee 执行结果。作用域内 Bee 执行质量现在可直接测量。静态 Queen-Bee 的 Bee 执行完成率仅为 0.80，而检索驱动的 Queen-Bee 达到了 0.95。这支持了配置质量不仅对治理重要，而且对执行效率也重要的主张。