L6

多 Agent 管理平台

Multi-Agent Management Platform — Agent 管理中心 · Skill 市场 · 工具注册中心 · 编排引擎 · 框架集成

层级编号 L6 核心模块数 5 (Agent 中心 / Skill 市场 / 工具注册 / 编排引擎 / 框架集成) 向下依赖 ↓ L5 (Agent API / MCP Tools / RAG API) 向上提供 ↑ L7 (Agent 编排 API / Skill 搜索及加载 API / Tool 发现及执行 API) 关键用户 AI 应用开发者 · 平台运维 · 业务系统集成商 设计理念 模块化 · 可编排 · 框架无关 · 可观测 · 安全治理

2. 层级定位

L6 多 Agent 管理平台是 AI 平台架构中的"指挥调度层",位于 L5 模型基础应用平台(提供单 Agent 能力、工具、技能)之上,L7 业务应用层(调用多 Agent 编排 API 构建业务应用)之下。L6 不直接产生模型推理请求,而是通过调用 L5 的各子平台能力来实现多 Agent 的协调与管控。

L6 的核心职责可概括为 "管、配、编、评" 四个维度:

层级定位 — L6 多 Agent 管理平台在架构中的位置 L7 · 业务应用层 (Business Applications) 智能客服 · 数据分析助手 · 自动化工作流 · 内容生成平台 · 决策支持系统 调用编排 API / Skill API / Tool API L6 · 多 Agent 管理平台 (Multi-Agent Management Platform) Agent 管理中心 | Skill 市场 | 工具注册中心 | 编排引擎 | 框架集成适配 管: 注册/发现/健康/生命周期  ·  配: Skill 市场/工具注册  ·  编: 六种编排模式  ·  评: 监控/评估/SLA 调用单 Agent API / MCP Tools / RAG API L5 · 模型基础应用平台 (Model Application Platform) Agent 平台 · Dify Workflow · RAG 平台 · MCP 平台 ↑ 上游 (L7 可见) 编排 API · Skill 搜索 · Tool 发现 不暴露 Agent 内部状态 ↓ 下游 (L5 依赖) Agent Runtime API · MCP Tool · RAG 不绕过 L5 直接调用 L4 ↔ 内部解耦 模块间通过编排上下文通信 独立部署,松散耦合

3. 边界规范

上游 → L7 提供 Agent 编排 API / Skill 搜索及加载 API / Tool 发现及执行 API —— L7 业务应用层通过标准 REST/gRPC API 调用 L6 的编排能力和服务发现能力。L6 不暴露单个 Agent 的内部状态(如 Prompt 内容、记忆片段、中间推理步骤),仅暴露编排结果和聚合指标。
下游 → L5 使用单 Agent Runtime API / MCP Tool API / RAG 检索 API —— L6 编排引擎通过 L5 提供的标准接口驱动单个 Agent 的执行、工具调用和知识检索。L6 不绕过 L5 直接调用 L4 模型网关,也不直接访问 L4 以下的任何层级。
内部 Agent 管理中心、Skill 市场、工具注册中心为独立模块,共享编排上下文 —— 三个模块独立部署和维护,通过统一的编排上下文(Orchestration Context)进行数据交换。Agent 在编排过程中可动态加载 Skill、发现并调用工具。
约束 所有多 Agent 编排产生的推理请求必须经过 L5 → L4 链路,确保可观测性和安全治理 —— L6 不直接产生模型推理,所有推理由 L5 层的 Agent Runtime 代为执行。L6 负责编排逻辑和结果汇聚,推理成本和安全由底层链路保障。

A

Agent 管理中心

Agent 管理中心是多 Agent 管理平台的核心模块,负责平台上所有 Agent 的全生命周期管理。它提供统一的注册与发现机制、能力矩阵管理、健康监控、环境隔离、发布审批和运行时可观测能力。

A1.1 Agent 注册与发现

每个 Agent 在接入平台时必须在 Agent 管理中心完成注册,注册信息包含元数据、能力声明和接口规范。其他 Agent 和编排引擎通过服务发现机制查找并使用已注册的 Agent。

📋 注册元数据

  • 基础信息:agent_id(全局唯一)、name、version、owner、team
  • 描述信息:description、tags、categories、use_cases
  • 接口规范:input_schema(JSON Schema)、output_schema(JSON Schema)、endpoint
  • 能力声明:capabilities(工具列表、技能列表、知识领域)、model_requirements
  • 部署信息:environment(dev/staging/prod)、region、replicas
  • SLA 承诺:max_response_time、max_concurrency、availability_target

🔍 服务发现

  • 基于能力查询:按能力标签检索 Agent,如 "查找具备 SQL 查询能力的 Agent"
  • 基于名称查询:精确匹配和模糊匹配 agent_id 或 name
  • 基于标签查询:按 tags 进行多标签组合查询
  • 健康感知:自动过滤不健康或已下线的 Agent
  • 就近路由:按部署区域返回最优 Agent 实例
  • 缓存策略:本地缓存注册信息,TTL 30s,降低发现延迟

A1.2 Agent 能力矩阵

平台维护一个全局的 Agent 能力矩阵(Capability Matrix),以二维表格形式展示每个 Agent 支持的任务类型、工具集合和知识领域,方便编排引擎在任务分配时快速匹配合适的 Agent。

Agent任务类型工具集合知识领域支持语言最大并发
数据分析助手数据查询, 报表生成, 趋势分析SQL Engine, Python Sandbox, Chart Tool销售数据, 用户行为, 财务指标zh-CN, en-US50
智能客服 Agent问答, 工单处理, 投诉升级Web Search, Knowledge Base, Ticket System产品手册, FAQ, 订单物流zh-CN, zh-TW, en-US200
代码审查 Agent代码 Review, Bug 检测, 重构建议GitHub, Static Analysis, Linter编码规范, 设计模式, 安全漏洞en-US30
文档生成 Agent文档撰写, 翻译, 格式转换Doc Generator, Translation, PDF ExportAPI 文档, 技术规范, 用户手册zh-CN, en-US, ja-JP20
内容审核 Agent内容检测, 敏感信息识别, 合规审查Content Moderation, PII Detection, Image Check合规政策, 敏感词库, 行业法规zh-CN, en-US100
报告汇总 Agent数据汇总, 报告撰写, 摘要生成Web Search, Code Sandbox, Doc Gen行业报告, 竞品分析, 市场数据zh-CN, en-US15

A1.3 Agent 健康检查与心跳机制

平台通过多层健康检查机制确保所有注册 Agent 的可用性:

❤️ 心跳检测

每个 Agent 每隔 10s 向管理中心上报心跳(liveness probe)。连续 3 次心跳丢失标记为"可疑"状态,连续 5 次丢失标记为"离线"。离线 Agent 自动从服务发现列表中移除。

🔬 就绪检测

Agent 启动后通过 readiness probe 报告是否已加载完模型、工具和记忆。未就绪的 Agent 不会被编排引擎分配任务。就绪检测超时 60s。

📊 深度健康检查

每分钟对 Agent 进行一次深度检查:发送测试推理请求,验证响应时间、正确率和功能完整性。深度检查失败触发告警和自动恢复流程。

⚠️ 降级与熔断

当 Agent 的错误率超过 10% 或平均响应时间超过 2×SLA 时,自动触发熔断。熔断后的 Agent 不再接收新请求,等待冷却期后自动恢复或人工介入。

A1.4 Agent 生命周期

Agent 从创建到退役的完整生命周期包含以下 7 个阶段:

💡
创建
🚀
发布
🔄
更新
↩️
回滚
🚫
下线
🗑️
删除
创建 在管理控制台定义 Agent 元数据(名称、描述、标签、所属团队),声明能力集合(输入输出 Schema、工具需求、模型要求、知识领域),系统自动生成 agent_id 和初始版本 v0.1.0。创建后的 Agent 默认进入 draft(草稿) 状态,仅创建者可见。
发布 Agent 经过测试和审批后发布到目标环境(dev/staging/prod)。发布时生成版本快照,自动触发 CI/CD 部署流水线。灰度发布:10% → 30% → 100% 逐步放量,每个阶段观察 15 分钟无异常后继续。
更新 更新 Agent 配置或能力声明,生成新版本号(遵循语义化版本)。变更内容记录到 changelog。非兼容性更新(如修改输入 Schema)必须创建新 major 版本,旧版本保持可用。
回滚 生产环境出现异常时,支持一键回滚到任一历史版本。回滚自动触发全量流量切换,同时记录回滚原因和时间。回滚后生成 incident 报告。
下线 将 Agent 置为 offline 状态。下线后的 Agent 不再参与服务发现和编排调度,但元数据和历史数据保留 30 天。下线前自动通知所有使用者,提供数据迁移窗口。
删除 从平台彻底移除 Agent 的所有信息。删除操作需二次确认,删除后数据不可恢复。关联的编排工作流受影响,需提前处理。

A1.5 环境隔离

平台支持三种标准环境,Agent 在发布时指定目标环境,不同环境之间完全隔离:

维度开发环境 (dev)预发布环境 (staging)生产环境 (prod)
目的Agent 开发与单元测试集成测试与预发布验证正式业务运行
数据隔离模拟数据 / 测试数据集脱敏生产数据子集真实生产数据
模型配置低成本模型(如 GPT-4o-mini)生产级模型(如 GPT-4o)生产级模型 + 备用 Fallback
监控级别基础日志完整监控 + 告警预配置全链路监控 + 自动告警 + 值班
SLA 要求接近生产 SLA严格 SLA 保障
部署方式共享集群 Namespace独立 Namespace独立集群 / 多可用区
访问控制开发者 + CI/CD开发者 + QA + 管理员严格的 RBAC + 审批

A1.6 发布审批工作流

Agent 从开发环境到生产环境必须经过审批工作流,确保变更的可控性和安全性:

自测通过 开发者完成 Agent 开发后,在 dev 环境运行自动化测试套件(单元测试 + 集成测试 + 回归测试),测试通过率 100% 后方可提交审批。
代码审查 至少一名同团队资深开发者对 Agent 配置(Prompt、工具定义、安全策略)进行代码审查。审查通过后进入 QA 阶段。
QA 验证 QA 团队在 staging 环境执行功能验证、性能测试和安全测试。测试报告自动关联到发布申请单。
管理员审批 平台管理员审批发布申请,确认资源配额、SLA 承诺和安全合规。高风险 Agent(如可执行代码、可修改数据)需要安全团队额外审批。
灰度发布 审批通过后进入灰度发布流程:10% 流量观察 15 分钟 → 50% 流量观察 30 分钟 → 100% 全量。每个灰度阶段自动评估错误率和延迟,超出阈值自动回滚。

A1.7 运行时监控

平台对所有运行中的 Agent 采集以下维度的监控指标,支持实时监控和历史趋势分析:

📊 调用量

每秒请求数(QPS)、累计调用次数、并发实例数。按 Agent 版本、环境、调用来源等维度聚合分析。支持按分钟/小时/天粒度查看趋势。

⏱️ 延迟

平均执行时间、P50/P95/P99 延迟、最大执行时间。延迟按阶段细分(推理耗时、工具调用耗时、编排调度耗时)。

✅ 成功率

请求成功率、错误率、重试率。按错误类型分类(推理错误、工具调用失败、超时、Rate Limit)。成功率和错误率按调用来源和环境展示。

💰 成本

Token 消耗量(输入/输出)、模型调用成本(按模型和 Provider 分组)、工具调用成本。支持预算告警和成本分摊到团队/项目。

A1.8 Agent 评估与优化

平台提供多维度的 Agent 评估体系,帮助开发者持续优化 Agent 表现:

⭐ 任务成功率

Agent 完成任务的百分比,基于预定义的成功标准自动评估。按任务类型、输入复杂度、数据源等维度分解统计,低于阈值自动告警。

👍 用户满意度

收集终端用户对 Agent 输出的反馈(赞/踩、评分 1-5 星、文本评价)。支持按时间、Agent 版本、场景维度分析满意度趋势。

⚖️ A/B 比较

在同一流量中运行两个 Agent 版本,对比效果指标。支持等量分流和比例分流(如 10% 新版本 vs 90% 旧版本),自动统计显著性差异。

🧠 自动优化建议

基于历史数据和行为分析,自动生成优化建议:Prompt 调整、工具选择优化、参数调优、记忆策略改进。优化建议附带预期影响评估。

A2. Agent Registry YAML 规范示例

以下为一个完整的 Agent 注册 YAML 定义,展示了注册到平台所需的所有字段:

# Agent 注册规范示例
apiVersion: agent-registry.ai-platform.io/v1
kind: AgentRegistration
metadata:
  agent_id: "agent-customer-service-v2"
  name: "智能客服助手"
  version: "2.3.1"
  owner: "team-customer-platform"
  team: "客户平台部"
  labels:
    environment: production
    language: zh-CN
    priority: P0
  tags: ["customer-service", "ticketing", "multilingual"]
spec:
  description: "面向企业客户的智能客服 Agent,支持多渠道接入、工单管理和知识库问答"
  use_cases:
    - "客户咨询自动回复"
    - "工单自动创建与分发"
    - "常见问题解答"
    - "订单物流状态查询"

  # 接口声明
  interface:
    transport: grpc
    endpoint: "dns:///agent-customer-service.platform.svc.cluster.local:50051"
    timeout_ms: 30000
    input_schema:
      type: object
      properties:
        session_id:
          type: string
          description: "会话 ID"
        user_id:
          type: string
          description: "用户 ID"
        message:
          type: string
          description: "用户消息内容"
        context:
          type: object
          description: "附加上下文信息"
      required: ["session_id", "message"]
    output_schema:
      type: object
      properties:
        reply:
          type: string
          description: "Agent 回复"
        actions:
          type: array
          items:
            type: object
            properties:
              type:
                type: string
                enum: ["create_ticket", "escalate", "close"]
              payload:
                type: object
      required: ["reply"]

  # 能力声明
  capabilities:
    tasks:
      - name: "question_answering"
        description: "基于知识库的问答能力"
        level: "expert"
      - name: "ticket_management"
        description: "创建、查询、更新工单"
        level: "advanced"
      - name: "sentiment_analysis"
        description: "客户情绪分析"
        level: "basic"
    tools:
      required:
        - tool_id: "knowledge-base-search"
          version: ">=2.0.0"
        - tool_id: "ticket-system"
          version: ">=1.5.0"
      optional:
        - tool_id: "order-query"
          version: ">=3.0.0"
    knowledge_domains:
      - "企业产品知识"
      - "客户服务流程"
      - "订单与物流"
    languages:
      - "zh-CN"
      - "en-US"
    models:
      primary:
        provider: "openai"
        model: "gpt-4o"
        parameters:
          temperature: 0.3
          max_tokens: 4096
      fallback:
        - provider: "anthropic"
          model: "claude-3-5-sonnet"

  # 部署与资源
  deployment:
    environment: production
    region: "cn-beijing"
    replicas: 5
    resources:
      cpu: "4"
      memory: "8Gi"
    scaling:
      min_replicas: 3
      max_replicas: 20
      target_cpu_utilization: 70
      target_memory_utilization: 80

  # SLA 承诺
  sla:
    max_response_time_ms: 3000
    max_concurrency: 200
    availability_target: 99.95
    max_error_rate: 1.0

  # 安全控制
  security:
    authentication:
      type: mTLS
      cert_ttl_days: 365
    authorization:
      type: RBAC
      roles: ["admin", "editor", "viewer"]
    data_classification: "internal"
    audit_enabled: true

  # 可观测性
  observability:
    tracing:
      enabled: true
      sampling_rate: 1.0
    metrics:
      - "request_count"
      - "response_time_ms"
      - "error_rate"
      - "token_usage"
      - "tool_call_count"
    logging:
      level: "info"
      retention_days: 30

B

Skill 市场

Skill 市场是 L6 层的"能力超市",Agent 和编排引擎可以从市场中搜索、加载和使用各种预构建的技能。Skill 是可复用的能力单元,封装了特定任务的 Prompt 模板、工具调用序列和推理策略。

B1.1 Skill 定义结构

每个 Skill 包含完整的元数据、能力声明和运行时信息:

字段类型说明
skill_idstring全局唯一 Skill 标识符,如 "skill-web-research-v2"
namestring人类可读的 Skill 名称,如 "网络深度研究"
versionstring语义化版本号 MAJOR.MINOR.PATCH
descriptionstringSkill 功能描述,支持 Markdown 格式
capabilities[]array能力标签列表,用于搜索匹配,如 ["web_search", "data_extraction", "summarization"]
input_schemaobject输入参数的 JSON Schema 定义
output_schemaobject输出结果的 JSON Schema 定义
model_requirementsobject模型要求:推理能力等级、上下文窗口、是否支持函数调用等
tools_requiredarraySkill 运行所需的工具列表,含版本约束
examples[]array使用示例,包含输入和期望输出
ratingnumber综合评分(1-5 星)
usage_countinteger总使用次数
authorstring创建者信息
created_at / updated_atdatetime创建和最后修改时间
compatibilityobjectAPI 兼容性声明和 breaking change 记录
dependenciesarray对其他 Skill 的依赖关系
cost_estimateobject预估每次调用的 Token 消耗和成本

B1.2 Skill 生命周期

每个 Skill 从开发到迭代经过以下六个阶段:

💻
开发
🧪
测试
🧩
审查
🚀
发布
💬
反馈
🔄
迭代
开发 开发者定义 Skill 的 Prompt 模板、工具调用逻辑和输入输出 Schema。使用平台提供的 Skill SDK 进行本地开发和调试。开发完成后推送到 Git 仓库。
测试 在沙箱环境运行自动化测试:输入输出格式校验、工具调用正确性、边界场景测试、性能基准测试。测试通过后生成测试报告。
审查 由平台 Skill 评审组(至少 2 人)进行代码审查和效果审查。审查内容包括 Prompt 质量、工具安全性、输出合规性、文档完整性。
发布 审查通过后发布到 Skill 市场。发布时生成版本标签,自动注册到 Skill 索引。可选择公开发布或团队内部分发。
反馈 收集使用者评分、评价和使用数据。低评分 Skill 自动触发审查流程,长期低分(评分 < 3.0 持续 30 天)的 Skill 标记为"不推荐"。
迭代 根据反馈和数据持续优化 Skill。每次迭代需重新走完整的测试→审查→发布流程。major 版本更新需通知所有使用者。

B1.3 Skill 评分系统

Skill 评分系统采用多维度综合评分模型,避免单一指标偏差:

⭐ 用户评分

使用者在使用后对 Skill 进行 1-5 星评分。评分可附带文字评价。系统自动过滤异常评分(如短时间内大量低分或高分)。评分权重:50%。

📈 使用次数

Skill 被调用的总次数和最近 30 天活跃使用次数。使用量反映 Skill 的受欢迎程度和稳定性。评分权重:15%。

✅ 任务成功率

Skill 在推理测试集上的成功率,以及在生产环境中的实际成功率。成功率低于 80% 的 Skill 自动降权。评分权重:20%。

⏱️ 响应时间

Skill 的平均执行时间和 P95 延迟。响应时间直接影响用户体验,快速响应获得更高评分。评分权重:15%。

B1.4 Skill 推荐引擎

平台内置 Skill 推荐引擎,基于以下策略为 Agent 和开发者推荐最合适的 Skill:

🏠 基于场景

根据当前任务场景推荐相关 Skill。例如,数据分析场景推荐 "SQL 查询"、"数据可视化"、"统计报告"等 Skill。场景标签由 Skill 作者声明,系统自动扩充关联场景。

👥 基于用户行为

基于组织内其他使用者(同团队、同项目、同角色)的 Skill 使用历史进行协同过滤推荐。"使用此 Skill 的用户也使用了..."模式推荐。

🎯 基于效果

优先推荐综合评分高、成功率高、延迟低的 Skill。新发布的 Skill 获得"新秀"标签和短期流量扶持(7 天),帮助积累初始数据。

🧠 基于语义

基于 Skill 描述和用户需求描述的语义相似度匹配。使用 Embedding 模型将 Skill 描述和用户查询编码后计算余弦相似度,返回 Top-K 最相关 Skill。

B1.5 Skill 依赖管理

Skill 之间可能存在依赖关系(如"深度研究"Skill 依赖"网页搜索"和"内容摘要"两个基础 Skill)。平台提供自动依赖解析机制:

依赖类型说明示例
必需依赖Skill 正常运行必须加载的其他 Skill"网络研究"依赖 "网页内容提取"
可选依赖加载后可以增强 Skill 能力,缺少时功能降级运行"翻译"可选依赖 "术语词典"
版本约束指定依赖 Skill 的版本范围(^1.0.0、>=2.0.0)依赖 "data-analysis" ^2.1.0
冲突检测自动检测依赖树中的版本冲突,无法自动解决时拒绝加载两个依赖同时要求不同 major 版本
循环依赖检测检测并阻止 A→B→C→A 的循环依赖构建依赖有向无环图(DAG),检测环路
延迟加载按需加载依赖,仅在执行到特定分支时加载仅在用户选择"高级模式"时才加载分析 Skill

B1.6 版本兼容性声明

Skill 使用语义化版本控制,版本变化对兼容性的影响如下:

版本变更兼容性允许的变更使用者影响
MAJOR 升级不兼容输入 Schema 破坏性修改、输出结构改变、删除已废弃功能、底层模型或工具架构变更需修改 Agent 调用代码,强制通知所有使用者
MINOR 升级向后兼容新增可选参数、扩展输出字段(仅追加)、新增功能、增强已有能力无需修改代码,新功能可选使用,建议使用者关注 release notes
PATCH 升级完全兼容Bug 修复、性能优化、文档改进、Prompt 微调(不影响输出风格和格式)无需任何操作,自动更新
预发布版本不保证alpha/beta/rc 后缀,功能未稳定,随时可能变更仅用于测试和验证,不建议用于生产环境

B2. Skill JSON 规范示例

以下为一个完整的 Skill 定义 JSON 示例:

{
  "skill_id": "skill-deep-research-v2",
  "name": "深度网络研究",
  "version": "2.1.0",
  "description": "对给定主题进行多源网络搜索、信息交叉验证和结构化报告生成。支持中英文,自动引用来源。",
  "author": {
    "name": "AI Platform Team",
    "contact": "ai-platform@company.com"
  },
  "capabilities": [
    "web_search",
    "multi_source_verification",
    "data_extraction",
    "summarization",
    "report_generation",
    "citation_management"
  ],
  "input_schema": {
    "type": "object",
    "properties": {
      "topic": {
        "type": "string",
        "description": "研究主题,越具体越好",
        "examples": ["2025 年全球 AI 芯片市场分析"]
      },
      "depth": {
        "type": "string",
        "enum": ["basic", "moderate", "deep"],
        "default": "moderate",
        "description": "研究深度:basic=5 个搜索源,moderate=15 个,deep=30 个"
      },
      "language": {
        "type": "string",
        "enum": ["zh-CN", "en-US"],
        "default": "zh-CN"
      },
      "include_graphs": {
        "type": "boolean",
        "default": false,
        "description": "是否在报告中包含趋势图和数据可视化"
      }
    },
    "required": ["topic"]
  },
  "output_schema": {
    "type": "object",
    "properties": {
      "title": { "type": "string" },
      "executive_summary": { "type": "string" },
      "sections": {
        "type": "array",
        "items": {
          "type": "object",
          "properties": {
            "heading": { "type": "string" },
            "content": { "type": "string" },
            "citations": {
              "type": "array",
              "items": { "type": "string" }
            }
          }
        }
      },
      "conclusion": { "type": "string" },
      "citations": {
        "type": "array",
        "items": {
          "type": "object",
          "properties": {
            "index": { "type": "integer" },
            "url": { "type": "string" },
            "title": { "type": "string" },
            "reliability_score": { "type": "number" }
          }
        }
      },
      "metadata": {
        "type": "object",
        "properties": {
          "sources_consulted": { "type": "integer" },
          "execution_time_ms": { "type": "integer" },
          "total_tokens_used": { "type": "integer" }
        }
      }
    },
    "required": ["title", "executive_summary", "sections", "citations"]
  },
  "model_requirements": {
    "min_reasoning_level": "advanced",
    "min_context_window": 128000,
    "requires_function_calling": true,
    "recommended_models": [
      "gpt-4o",
      "claude-3-5-sonnet",
      "qwen3-235b-a22b"
    ],
    "estimated_tokens_per_call": {
      "basic": 4000,
      "moderate": 12000,
      "deep": 35000
    }
  },
  "tools_required": [
    {
      "tool_id": "web-search-engine",
      "version": ">=3.0.0",
      "purpose": "多源搜索引擎搜索"
    },
    {
      "tool_id": "web-content-extractor",
      "version": ">=1.2.0",
      "purpose": "网页内容抓取和提取"
    },
    {
      "tool_id": "code-sandbox",
      "version": ">=2.0.0",
      "purpose": "数据分析和图表生成",
      "optional": true
    }
  ],
  "dependencies": [
    {
      "skill_id": "skill-content-summarization",
      "version": "^1.5.0",
      "type": "required"
    },
    {
      "skill_id": "skill-data-visualization",
      "version": "^2.0.0",
      "type": "optional"
    }
  ],
  "compatibility": {
    "api_version": "2.0",
    "breaking_changes": [
      {
        "version": "2.0.0",
        "description": "输出 schema 结构调整,sections 改为数组格式",
        "migration_guide": "https://docs.internal/skill-migration-v2"
      }
    ],
    "deprecated_since": null
  },
  "examples": [
    {
      "name": "市场研究报告",
      "input": {
        "topic": "2025 年全球 AI 芯片市场分析",
        "depth": "moderate",
        "language": "zh-CN"
      },
      "output_preview": "生成包含市场概况、主要厂商分析、技术趋势、区域分布等章节的完整报告"
    }
  ],
  "rating": 4.7,
  "usage_count": 15230,
  "cost_estimate": {
    "average_tokens": 8500,
    "average_cost_usd": 0.12,
    "currency": "USD"
  },
  "created_at": "2025-08-15T10:00:00Z",
  "updated_at": "2026-05-20T14:30:00Z"
}

C

工具注册中心

工具注册中心(Tool Registry)是 L6 层所有工具的集中管理和发现平台。Agent、Skill 和编排引擎通过工具注册中心发现和调用各类工具。工具注册中心与 L5 MCP 平台协同工作——MCP 平台负责工具的运行时执行和安全代理,工具注册中心负责工具的元数据管理、分类、搜索和生命周期。

C1.1 工具分类体系

工具按照功能领域分为五大类,每类包含多个子分类:

📊 数据查询工具

  • SQL 查询:MySQL、PostgreSQL、ClickHouse、Trino 等 SQL 数据库查询
  • NoSQL 查询:MongoDB、Redis、Elasticsearch 等非关系型数据查询
  • API 调用:REST/gRPC/GraphQL API 的通用调用封装
  • 搜索引擎:Google/Bing 搜索、内部知识库搜索、Elasticsearch 搜索
  • 知识库检索:RAG 平台 API 封装,支持向量检索和关键词检索

💻 计算工具

  • 数学计算:高精度数学运算、公式求解、统计计算
  • 代码执行沙箱:安全的 Python/JavaScript/SQL 代码执行环境
  • 数据转换:JSON/CSV/XML/YAML 格式转换、数据清洗
  • 统计分析:描述统计、假设检验、回归分析、时间序列分析
  • 数据可视化:图表生成(柱状图、折线图、饼图、散点图、热力图)

📡 通讯工具

  • 邮件:SMTP/IMAP 协议,发送和读取邮件
  • 即时通讯:飞书、钉钉、企业微信的消息发送和接收
  • 日程管理:创建、查询、更新日历事件和会议安排
  • 审批工作流:发起和查询 OA 审批流程
  • 通知推送:多渠道统一通知推送(短信、App Push、Webhook)

🎨 内容工具

  • 文档生成:PDF/DOCX/PPTX 格式文档的自动生成
  • 图像生成:基于 Stable Diffusion / DALL-E 的图像生成和编辑
  • 音视频处理:语音合成(TTS)、语音识别(ASR)、视频剪辑
  • 翻译:多语言翻译服务,支持术语表定制
  • 格式转换:文档格式互转、图像格式转换、音视频转码

⚙️ 系统工具

  • Shell 执行:在受控环境中执行系统命令
  • 文件操作:文件读写、目录遍历、文件上传下载
  • Cron 任务:定时任务管理、周期任务调度
  • 监控告警:系统指标查询、告警规则管理、事件通知
  • 配置管理:读取和更新系统配置、Feature Flag 管理

C1.2 工具注册规范

每个工具在注册中心注册时需提供完整的元数据规范:

字段类型说明示例
tool_idstring全局唯一工具标识符tool-sql-query-v3
namestring人类可读的工具名称SQL 数据库查询
versionstring语义化版本号3.2.1
descriptionstring工具功能详细描述对 MySQL/PostgreSQL 数据库执行只读 SQL 查询
sourcestring工具来源(builtin/community/custom)builtin
categorystring所属分类data_query
parametersobject参数 JSON Schema 定义{ type: "object", properties: {...} }
security_levelstring安全等级(readonly/readwrite/admin)readonly
rate_limitobject速率限制配置{ rpm: 100, tpm: 50000 }
audit_logboolean是否记录审计日志true
data_classificationstring数据处理等级(public/internal/confidential/restricted)internal
pricingobject工具调用定价{ per_call: 0.001, per_token: 0.0001 }
auth_requiredboolean是否需要认证true
approval_requiredboolean调用是否需要审批false
timeout_msinteger超时时间(毫秒)30000
retry_policyobject重试策略配置{ max_retries: 3, backoff: "exponential" }
health_checkstring健康检查端点/health/live
docs_urlstring文档链接https://docs.internal/tools/sql-query
ownerstring维护团队team-data-platform

C1.3 工具安全机制

工具注册中心内置多层安全机制,确保工具调用的安全性和合规性:

🔑 安全级别

工具按操作权限分为三个安全等级:只读(readonly):仅允许数据查询和读取操作;读写(readwrite):允许创建和修改数据;管理(admin):允许系统级操作,如删除数据和执行命令。高级别工具可调用的 Agent 必须经过额外授权。

🚧 参数校验与清洗

所有工具调用的输入参数经过 JSON Schema 严格校验,拒绝未定义字段和类型不匹配的输入。字符串参数自动进行 SQL 注入、命令注入和 XSS 攻击检测与清洗。参数长度和数值范围受约束。

🕵️ 敏感数据脱敏

工具输出中检测到的敏感信息(身份证号、手机号、银行卡号、密码、密钥等)自动脱敏。脱敏规则可配置:保留前缀/后缀、部分掩码、完全隐藏等。数据分类为 confidential 和 restricted 的工具输出强制脱敏。

🔐 RBAC 访问控制

基于角色的访问控制,每个工具可配置允许的角色列表。Agent 调用工具时使用其关联的服务账号进行鉴权。支持精细化权限:按用户、团队、应用维度配置黑白名单。高风险操作需要额外审批。

安全设计原则:工具调用始终遵循"最小权限原则"——Agent 只能调用其被明确授权的工具。所有工具调用行为完整记录审计日志,日志不可篡改,保留至少 180 天。安全管理委员会定期审查工具权限配置。

D

多 Agent 编排引擎

多 Agent 编排引擎是 L6 层的核心组件,负责定义、调度和监控多个 Agent 之间的协作流程。编排引擎支持六种编排模式,可灵活组合应对不同的业务场景。

D1.1 六种编排模式

🔁 Sequential 顺序模式

Agent 按照预定义的顺序依次执行,前一个 Agent 的输出作为后一个 Agent 的输入,形成数据处理流水线。这是最基本的编排模式,适用于有明确步骤依赖的 ETL 式数据处理任务。
适用场景:数据处理流水线(数据提取 → 清洗 → 转换 → 分析 → 报告生成)、文档处理流程(OCR 识别 → 翻译 → 摘要生成 → 格式转换)、合规审查流水线(内容检测 → 分类 → 风险评分 → 处置建议)。
优点:执行路径清晰,易于理解和调试;每一步的结果可独立验证;错误定位精确,回滚成本低。
缺点:总执行时间 = 各步执行时间之和,不适用于延迟敏感场景;前序步骤失败导致整个流程中断。

🔀 Parallel 并行模式

多个 Agent 同时执行不同的子任务,所有 Agent 完成后汇总结果。并行模式可以显著降低总执行时间,适用于可分解为独立子任务的场景。
适用场景:多维度数据分析(各维度独立计算后汇总)、多渠道信息收集(同时搜索多个数据源)、批量内容生产(同时生成多篇文章/图片/报告)、并行竞品分析(多个竞品同时分析)。
优点:显著缩短总体执行时间(理论上可接近单步执行时间);子任务间完全隔离,故障隔离性好;易于扩展到更多 Agent。
缺点:资源消耗随并行数量线性增长;需要有效的汇总策略;汇总阶段可能成为瓶颈。

💬 Conversational 对话模式

多个 Agent 在一个共享的对话环境中自由交流、讨论和协作,通过多轮对话逐步逼近目标。不预设固定的执行路径,Agent 之间通过自然语言沟通。
适用场景:头脑风暴与创意生成(多个角色从不同角度提出想法)、复杂问题诊断(多个专家 Agent 讨论分析问题原因)、开放式研究(不同领域 Agent 从各自视角分析问题)、方案设计(产品经理 + 设计师 + 工程师 + 市场共同讨论方案)。
优点:高度灵活,能处理未预定义的复杂场景;充分利用各 Agent 的领域专长;可能产生突破性创意。
缺点:执行时间不可预测(可能陷入循环或偏离主题);对话质量受限于最弱 Agent;需要额外的对话管理和终止策略。

🤖 Hierarchical 层级模式

一个 Supervisor(管理者)Agent 负责将复杂任务分解为多个子任务,分配给多个 Worker(工作者)Agent 去执行,然后收集 Worker 的结果并汇总。Supervisor 可以递归地组织多层次的工作分解结构(WBS)。
适用场景:复杂任务分解(Supervisor 拆解任务 → Worker 各自执行 → Supervisor 结果整合)、软件开发(项目经理分配模块 → 开发 Agent 编码 → 测试 Agent 测试 → 整合报告)、大型项目报告(总编分配章节 → 各作者撰写 → 总编统稿审查)。
优点:自然的任务分解结构,易于管理和控制;可灵活调整 Worker 数量和类型;Supervisor 可监控子任务进度和质量。
缺点:Supervisor 成为单点决策瓶颈;层级深度增加时延迟增大;Supervisor 的分解能力直接影响整体效果。

⚖️ Debate 辩论模式

多个 Agent 针对同一问题独立形成回答,然后进入多轮辩论环节。每个 Agent 可以看到其他 Agent 的回答和论据,对自己的回答进行修正和优化。经过多轮辩论后,系统选择最终答案。
适用场景:事实核查与验证(多个 Agent 交叉验证信息真伪)、观点分析(多个 Agent 从不同立场分析问题)、决策支持(多个 Agent 各自分析后辩论产生最优决策)、风险评估(不同风险视角的 Agent 辩论识别全面风险)。
优点:通过"多角度审视"大幅提高答案准确性和全面性;辩论过程本身产生可追溯的推理链路;减少单一 Agent 的偏见和盲区。
缺点:Token 消耗大(多轮辩论产生大量对话);耗时较长;需要有效的辩论终止策略和最终裁决机制。

🗳️ Voting 投票模式

多个 Agent 独立回答同一个问题,然后通过投票机制(多数投票、加权投票、轮次投票等)选择最终的输出结果。投票模式与辩论模式的区别在于:Agent 在投票模式中不交换信息,独立完成回答。
适用场景:高精度要求的答案生成(如医疗诊断建议、法律条款解读)、关键业务决策(如交易审批、风控判断)、内容审核投票(多个审核 Agent 独立判断后投票决定)、预测与估计(多个 Agent 独立预测后取中位数或众数)。
优点:实现简单,Agent 间无通信开销;错误隔离性最好(一个 Agent 的错误不影响其他);理论上可以通过增加 Agent 数量持续提升准确率(类似集成学习)。
缺点:成本与 Agent 数量线性增长;无法获得"1+1>2"的协作增益;同质化 Agent 投票效果有限,需要多样性。

D1.2 编排工作流 YAML 定义示例

以下为一个混合编排模式的工作流定义示例,展示了顺序 + 并行 + 层级三种模式的组合应用——市场研究报告生成流程:

# 多 Agent 编排工作流定义示例:市场研究报告生成
apiVersion: orchestration.ai-platform.io/v1
kind: OrchestrationWorkflow
metadata:
  name: market-research-report
  version: "2.0.0"
  description: "生成多维度市场研究报告,包含竞品分析、趋势预测和战略建议"
  tags: ["market-research", "report-generation", "parallel-processing"]
spec:
  # ── 全局设置 ──
  global:
    max_execution_time_ms: 600000  # 总超时 10 分钟
    error_strategy: rollback_on_failure
    trace_level: full
    notify_on_completion: true

  # ── 变量定义 ──
  variables:
    report_topic:
      type: string
      description: "报告主题"
    depth:
      type: string
      enum: ["basic", "standard", "deep"]
      default: "standard"
    output_format:
      type: string
      enum: ["pdf", "docx", "markdown"]
      default: "markdown"

  # ── 编排步骤 ──
  steps:
    # Step 1: 并行信息收集(并行模式)
    - id: information-gathering
      name: "并行信息收集"
      mode: parallel
      timeout_ms: 180000
      agents:
        - id: web-research-agent
          skill: skill-deep-research-v2
          params:
            topic: "${report_topic}"
            depth: "${depth}"
            perspective: market_overview
        - id: competitor-agent
          skill: skill-competitor-analysis
          params:
            industry: "${report_topic}"
            competitors: ["company_a", "company_b", "company_c"]
        - id: data-agent
          skill: skill-data-analysis
          params:
            metrics: ["market_size", "growth_rate", "market_share"]
            sources: ["internal_db", "public_reports"]
      aggregation:
        strategy: merge
        output_var: raw_research_data

    # Step 2: 信息交叉验证(辩论模式)
    - id: fact-verification
      name: "信息交叉验证"
      mode: debate
      depends_on: ["information-gathering"]
      timeout_ms: 120000
      agents:
        - id: verifier-agent
          skill: skill-fact-check
          params:
            input: "${raw_research_data}"
            rigor: high
        - id: quality-agent
          skill: skill-quality-review
          params:
            input: "${raw_research_data}"
      rounds: 3
      consensus_threshold: 0.8
      output_var: verified_data

    # Step 3: 多章节并行撰写(层级模式)
    - id: report-writing
      name: "多章节并行撰写"
      mode: hierarchical
      depends_on: ["fact-verification"]
      timeout_ms: 240000
      supervisor:
        agent: editor-agent
        skill: skill-report-editing
        params:
          input: "${verified_data}"
          structure:
            - executive_summary
            - market_overview
            - competitor_analysis
            - trend_forecast
            - strategic_recommendations
      workers:
        - agent: writer-agent-1
          assignment: executive_summary, market_overview
        - agent: writer-agent-2
          assignment: competitor_analysis
        - agent: writer-agent-3
          assignment: trend_forecast, strategic_recommendations

    # Step 4: 最终投票评估(投票模式)
    - id: final-evaluation
      name: "最终评估投票"
      mode: voting
      depends_on: ["report-writing"]
      timeout_ms: 60000
      agents:
        - agent: qa-agent
          skill: skill-report-quality
        - agent: compliance-agent
          skill: skill-compliance-check
        - agent: business-agent
          skill: skill-business-review
      voting:
        method: majority
        min_pass_votes: 2
      output_var: evaluation_result

  # ── 输出定义 ──
  output:
    report:
      from: report-writing
    quality_score:
      from: final-evaluation.result
    execution_metadata:
      from: system.execution_metadata

D1.3 容错机制

编排引擎内置多层容错机制,确保多 Agent 协作文档的可靠性和稳定性:

🔁 重试逻辑

Agent 调用失败时自动重试。支持三种重试策略:固定间隔(每 5s 重试一次)、指数退避(1s → 2s → 4s → 8s)、即时重试(仅对幂等操作)。可配置最大重试次数(默认 3 次)。重试次数超限后触发降级策略。

⏰ 超时处理

每个编排步骤和全局工作流都可配置独立的超时时间。超时发生后,根据策略执行:跳过(使用默认值继续)、降级(使用后备 Agent 执行)、终止(整个工作流标记为失败并回滚)。超时阈值基于历史 P99 延迟 + 50% 缓冲计算。

🔌 死锁检测

在对话模式和辩论模式中,引擎实时检测死锁或循环:消息循环检测:同一消息模式重复 > 3 次触发中断;无进展检测:连续 5 轮对话内容无明显变化触发干预;超时自毁:模式级别最大轮数限制(默认 20 轮)。

↩️ 回滚策略

工作流失败时支持自动回滚:回滚范围:降级模式(仅回滚失败步骤)、完整模式(回滚所有已执行步骤);回滚动作:清除临时数据、恢复 Agent 状态、发出告警通知。部分成功:允许已完成部分的输出保留,用于诊断。


E

多 Agent 框架集成

L6 平台设计为框架无关(Framework-Agnostic),通过统一的编排抽象层集成主流多 Agent 框架。这使得平台可以灵活切换底层框架,同时也支持同一工作流中混用不同框架的 Agent。

E1.1 主流多 Agent 框架对比

以下为 L6 平台集成的五大主流多 Agent 框架的详细对比:

维度Multica (任务管理平台)AutoGenLangGraphCrewAIMetaGPT
设计理念Kanban 任务管理平台,将任务分配给 AI 编码 Agent 执行多 Agent 对话与协作框架有状态图编排框架角色化 Agent 团队协作SOP 驱动的软件开发流程
核心模型看板 + 任务分配 + Agent 工作台 + 进度追踪Agent 对话 + 群聊 + 管理器状态图 (StateGraph) + 节点角色 + 任务 + 流程 + 工具角色 + 文档 + 流程 + 动作
Sequential
Parallel部分部分
Conversational部分部分
Hierarchical
Debate
Voting
Agent 注册表
Skill 市场
工具注册中心内置内置内置
监控与治理
SLA 保障
企业级安全基础基础
框架语言PythonPythonPython / TypeScriptPythonPython
许可证Apache 2.0CC-BY-4.0 (MIT)MITMITMIT
社区活跃度中 (开源)Microsoft (高)LangChain (高)

注意: Multica 属于不同类型的工具 — 它是一个 任务管理平台(基于看板将任务分配给 AI 编码 Agent),而非传统意义上用于 Agent 间通信的编排 SDK。Multica 更类似于 Anthropic 的 Managed Agents 或 ChatGPT Workspace,位于技术栈中不同的抽象层。上表中 Multica 列出的编排模式(Sequential、Parallel 等)指的是该平台所能协调的工作流类型,而非其自身的 API 能力。

E1.2 集成架构

L6 平台通过编排抽象层(Orchestration Abstraction Layer)实现框架无关的集成架构。所有主流框架通过适配器(Adapter)模式接入,上层编排引擎无需关心底层框架的具体实现:

L6 多 Agent 框架集成架构 ⚙️ L6 编排引擎 (Orchestration Engine) 顺序 / 并行 / 对话 / 层级 / 辩论 / 投票 编排抽象层 (Orchestration Abstraction Layer) — 框架无关 API 框架适配器层 AutoGen 适配器 · LangGraph 适配器 CrewAI 适配器 · MetaGPT 适配器 统一能力层 Agent 注册 · Skill 市场 · Tool 注册 监控 & 治理(框架无关) AutoGen Microsoft 对话框架 LangGraph LangChain 图编排 CrewAI 角色协作框架 MetaGPT SOP 驱动框架 ↓ L5 模型基础应用平台 (Model Application Platform) Agent Runtime · MCP Tools · RAG API · Dify Workflow 集成策略说明 多框架共存:同一工作流可调用不同框架的 Agent,由适配层统一处理协议转换 渐进式迁移:已有系统使用 CrewAI 可直接无缝迁移到平台,通过适配器接入 能力共享:无论底层框架,Agent 均通过统一能力层获取注册、Skill 和工具服务

E1.3 统一能力层

无论底层使用何种多 Agent 框架,L6 都提供以下框架无关的统一能力层:

📋 Agent 注册表

所有 Agent(无论来自哪个框架)统一注册到 Agent 管理中心。注册表提供框架无关的 Agent 元数据查询和发现接口。适配器负责将各框架的 Agent 描述转换为统一格式。

🏷️ Skill 市场

Skill 的定义和使用与底层框架解耦。同一 Skill 可通过不同框架的适配器运行。Skill 的输入输出 Schema 保持框架无关,适配器负责参数转换。

📦 工具注册中心

工具注册与管理独立于任何框架。各框架通过适配器调用工具注册中心 API 获取工具定义。工具调用的鉴权、审计、限流等治理能力由注册中心统一提供。

📊 监控与治理

所有编排运行时的监控数据统一收集和展示,不区分底层框架。告警策略、SLA 监控、成本管理等治理能力对所有框架 Agent 一视同仁。


9. SLA/SLO 目标

L6 多 Agent 管理平台定义以下 SLA/SLO 目标,确保平台的服务质量和用户体验:

🤖 编排服务

编排请求成功率> 99.9%
简单编排(Sequential, Parallel)P95< 5s
复杂编排(Debate, Hierarchical)P95< 30s
编排计划生成延迟< 2s
并发编排工作流数500+

🔍 Agent 发现

Agent 发现 P95 延迟< 200ms
Agent 注册生效时间< 5s
健康检查准确率> 99.99%
注册表变更推送延迟< 1s
最大注册 Agent 数1000+

📦 Skill 加载

Skill 搜索 P95 延迟< 500ms
Skill 加载 P95 延迟< 2s
Skill 发布生效时间< 30s
推荐引擎响应延迟< 1s
最大注册 Skill 数5000+

🔧 工具执行

工具执行 P95 延迟< 2s
工具发现 P95 延迟< 100ms
工具注册生效时间< 10s
工具执行成功率> 99.5%
最大注册工具数2000+
SLA 违规处理:连续 5 分钟 SLA 指标超出阈值触发 P1 级告警,值班工程师需在 15 分钟内响应。连续 30 分钟超标触发"服务降级"——平台自动从 L6 编排模式降级为 L5 单 Agent 直连模式,确保业务连续性。SLA 违规事件需在 24 小时内完成根因分析并生成改进报告。

10. 技术选型

以下为 L6 多 Agent 管理平台的核心技术选型及选型理由:

组件技术选型版本选型理由
运行时语言Python 3.12+3.12+AI/ML 生态最丰富,主流多 Agent 框架均为 Python 实现,团队技术栈一致
API 框架FastAPI0.110+高性能异步框架,原生支持 async/await,自动生成 OpenAPI 文档,Pydantic 集成实现参数自动校验
编排引擎核心自研 + Tempora/Temporal1.22+Temporal 提供可靠的工作流引擎(重试、超时、持久化),自研层实现 6 种编排模式和编排抽象层
消息队列Apache Kafka3.6+高吞吐、持久化、支持事件溯源,适合跨 Agent 的消息传递和编排事件流。分区机制支持并行消息处理
服务发现Consul / Kubernetes API1.18+Consul 提供健康检查和 DNS 服务发现,K8s API 提供原生 Pod 级服务发现。两层配合确保 Agent 发现的高可用
配置中心etcd + Apollo3.5+ / 2.0+etcd 存储 Agent/Skill/Tool 注册元数据(强一致性),Apollo 管理平台配置和环境配置(热更新)
数据库PostgreSQL 1616+存储 Agent 注册信息、Skill 元数据、编排工作流定义、运行时日志。JSONB 支持灵活 Schema,分区表支持海量数据
缓存Redis 7.x7.2+Agent 注册信息本地缓存、Skill 索引缓存、编排上下文缓存。Redis Stream 支持轻量级消息通信
向量数据库Milvus2.4+Skill 语义搜索和推荐引擎的向量存储。支持十亿级向量规模,混合搜索(向量+标量过滤)
搜索引擎Elasticsearch8.12+Agent/Skill/Tool 的全文搜索,支持模糊匹配、近似搜索、多字段组合查询
可观测OpenTelemetry + Prometheus + Grafana + ELKOTel 标准化 Trace 采集,Prometheus 存储指标,Grafana 可视化仪表盘,ELK 日志管理
容器化Docker + Kubernetes1.28+微服务容器化部署,K8s 编排管理。HPA 自动扩缩容,亲和性调度优化 Agent 部署
CI/CDGitLab CI + ArgoCDGitLab CI 构建和测试,ArgoCD GitOps 部署。Agent/Skill/Tool 注册配置存储在 Git 仓库中
Proto 序列化Protocol Buffers + gRPC3 / 1.60+跨 Agent 通信的高效序列化,gRPC 双向流支持编排引擎和 Agent 间的实时通信
API 网关Kong / APISIX3.5+L6 层统一 API 入口,认证鉴权、Rate Limit、请求转发。配合 L4 模型网关形成双层网关架构
架构设计原则:L6 多 Agent 管理平台坚持"框架无关、能力共享、统一治理"三大原则。框架无关确保不锁定任何多 Agent 生态;能力共享避免各框架 Agent 重复建设基础功能;统一治理保证所有 Agent 行为可监控、可审计、可管理。L6 不产生模型推理请求,所有推理由 L5 层代为执行,L6 专注编排逻辑和管理能力。
重要提醒:L6 平台严禁绕过 L5 直接调用 L4 模型网关或更低层级。所有 Agent 编排产生的推理请求必须经过 L5 Agent Runtime。违反此规范可能导致安全策略绕过、可观测性断裂和治理缺失。L6 编排引擎不直接管理模型推理的并发、计费和限流——这些由 L4 模型网关统一管控。