用于生产安全运维的多智能体AI：5G核心网中的A2A和MCP架构

InfoQ 中文 2026-07-30T11:31:03.742751

摘要：面对5G核心网海量安全遥测数据，传统SOC（安全运营中心）的规则编写速度远跟不上威胁演变。本文介绍了一种基于多智能体AI的生产级安全运维架构，通过A2A（代理到代理）协议协调智能体、MCP（模型上下文协议）集成环境，并设置特权审核代理确保安全可控。该架构已在某电信运营商5G核心网中部署一年，将检测与响应时间缩短约40%，并自动生成了80多条此前无法编写的新规则。

问题背景

一个投入生产的5G核心网，每小时产生的安全遥测数据量，甚至超过大多数企业SOC一周的接收量。成熟SOC的瓶颈往往不在于分析师能否完成初步筛查，而在于：检测工程团队能否让规则库跟上威胁演变的速度——而威胁演变的速度，通常比规则编写快得多。

下文介绍的架构模式，基于某一级电信运营商5G核心网中的生产级安全运维实践，过去一年通过持续运维反馈和内部部署不断优化。该架构采用多代理层设计，通过A2A协议进行智能体间的协调，通过MCP与环境集成，并配备一个特权审核代理来执行安全检查代码。

对比已完成基线标定的事件分类体系，该平台将平均检测时间和响应时间分别缩短了约40%，自主生成了80多条此前无法编写的检测规则，并将制定新规则所需的人工时间从约3小时压缩到15分钟。该平台可同时监控10至20个5G网络功能。

两种无效的模式

当前安全运维AI领域主要有两种主流模式，但在电信核心网络这种规模下，两者都行不通。

1. 单个大语言模型（LLM）

将管道安全遥测数据、资产上下文和操作员查询直接喂给一个大模型，期望它直接输出检测结果和响应。这种模式在生产环境中失败了，原因有三且相互叠加：

上下文窗口过小：无法容纳实际SOC所需的远程监测数据量。
模型不确定性：对于需要自动触发生产基础设施隔离这样的输出，模型的不确定性是不可接受的。
变更管理困难：一个提示词的修改会改变整个SOC的行为，让变更管理几乎无法进行。

2. 将生成式AI（GenAI）集成到传统SIEM/SOAR系统中

大多数供应商的做法是在现有技术栈上附加一个LLM助手，帮助汇总告警、起草应对方案。这确实能提升分析师效率，但不会改变SOC的结构形态——规则仍然需要手动编写，覆盖新威胁所需的时间仍然受限于检测工程团队的编写速度。如果你在高风险SOC中评估过这两种模式后感到“哪里不对”，那本文就是为你准备的另一种选择。

架构设计

将SOC视为一个多智能体系统：专业化的窄领域智能体通过开放协调协议协作，通过开放上下文协议与环境交互，将耗费资源的LLM推理置于经典异常检测机制之后，并通过设计确保人类始终参与其中。以下是该架构不可妥协的四大特性。

特性1：采用单页契约的窄智能体

每个智能体承担多项职责：检测规则合成、告警分级、响应措施建议、环境上下文检索以及跨智能体审查。每个智能体的系统提示、工具列表、输出模式和升级协议，都必须能容纳在一页之内。如果一页内读不懂某个智能体的协议，就把它拆分。

使用大语言模型时，人们常常忍不住给智能体设计丰富的个性和复杂的提示——请抵制这种诱惑。根据我们的评估，表现最好的智能体都使用简洁、类似职位描述的系统提示；提示中的花哨设计只会带来技术债务。

特性2：通过开放协议（A2A）协调

智能体之间采用Agent-to-Agent（A2A）协议进行交互。A2A协议由谷歌于2025年4月开源，并于2025年6月移交至Linux基金会。实际应用中的替代方案是框架特定的总线。但选择由开放机制治理的协议至关重要——在生产环境中，多智能体系统的使用寿命以年为单位，协调层的持久性远比任何特定框架的便利性更为关键。

我们将A2A与MCP（同样由Anthropic于2025年12月捐赠给Linux基金会下的Agentic AI基金会）以及CNCF底层组件（如Cilium、cert-manager、OPA、Kyverno、Argo CD、Prometheus）相结合。整个技术栈处于同一开放治理框架下，在受监管行业中，这本身就是采购与合规层面的有力证据。

特性3：通过MCP进行环境集成

智能体与底层环境之间的每次交互都通过模型上下文协议（MCP）服务器进行。这些交互包括：资产清单查询、当前网络拓扑、近期事件历史、配置状态等。MCP为智能体提供了一个稳定且经过模式验证的接口，使其能访问5G环境；而环境内部的工具则按自己的节奏演进。当新增资产类别或更换资产清单系统时，MCP服务器的适配器会自动处理变更，无需重写智能体的任何提示词。

特性4：一个有特权的审核智能体

在未获得审核智能体明确批准之前，任何智能体都不得发起任何对外可见的操作。审核智能体的安全约束必须已编码、纳入版本控制，并可以独立测试。所谓“对外可见操作”包括：部署检测规则、执行隔离措施、修改防火墙策略等。审核智能体是系统的安全底线。在关键基础设施部署中，自主行动之所以能被接受，完全是因为审核智能体允许如此。

关键要点

传统单LLM和GenAI集成模式均无法应对5G核心网的生产规模，主要原因在于上下文限制、模型不确定性以及规则编写速度瓶颈。
多智能体架构通过窄智能体单页契约、A2A协议协调、MCP环境集成和特权审核代理，实现了安全运维的规模化自动化。
实际部署效果：检测与响应时间缩短40%，自动生成80+原创检测规则，新规则编写从3小时降至15分钟。
关键设计原则：开放协议（A2A/MCP）保证长期兼容性；特权审核代理确保安全可控；拒绝花哨提示，坚持简洁工程化。

大多数早期多代理部署因将安全规则硬编码到提示词中而失败。本文介绍如何通过独立的策略层（OPA 与 Kyverno）实现确定性裁决，并阐述“人在环中”机制如何将关键决策向上汇报给分析师。此外，还通过具体策略代码示例，展示如何防止代理实施危险操作。

人在环中：将人工判断作为一等输出

每一项有重大影响的决策，最终都会进入三种状态之一：自动执行、自动拒绝，或者——连同完整的推理链一起——上报给 SOC 分析师。当审核代理对结果的信心低于阈值、资产类别被列入“始终上报”列表，或者拟采取的行动超出了配置的影响范围时，系统就会进入第三种状态。

这种纪律虽然听起来有点“老派”，但至关重要：有些决策绝不应该交给自动化。协议机制会在采取任何行动之前，把决策连同代理的所有推理过程一并转至人工处理队列，让分析师在最终动作执行前有机会复核。

审核代理的策略究竟长什么样

上一节提到，审核代理依靠的不是提示词，而是一个独立的策略层。实际上，这个层由 OPA（开放策略代理） 和 Kyverno 两个组件协同工作，它们各自承担不同的职责。

OPA 从运营风险角度评估操作是否允许：影响范围、可信度、可逆性以及是否需要人工升级。
Kyverno 则独立验证该操作在 Kubernetes 底层的实现是否符合基线要求：镜像来源是否可信、工作负载身份是否正确、资源约束是否合规、准入控制是否通过。

简单说：OPA 负责业务安全不变量，Kyverno 负责平台安全不变量。两者配合，在代理推理与生产环境执行之间形成多层纵深防御。

下面介绍的 OPA 策略用到几个关键字段，先说明一下：
- 影响范围：若操作出错，可能影响的客户流量比例。
- 置信度：提议代理对自己提议正确性的信心程度。
- 可逆性：取决于操作类型（例如阻断路由有回滚机制，删除核心组件通常不可逆）。
- config_validated：该字段只允许由审核代理设置，不允许提议代理自行设置——因为代理不应能将自己的配置更改标记为安全。

阈值本身存储在单独的数据文档中，而不是硬编码在策略里。这样决策逻辑与实际的风险容忍度就可以分开版本控制，SOC 团队无需改动规则结构就能调整阈值。

策略实战：防止镜像拉取越界

假设检测工程代理为一个新的检测传感器生成了 Kubernetes 部署。审核代理根据影响范围和置信度批准了它。但批准并不意味着万事大吉——在对象到达 Kubernetes API 服务器之前，Kyverno 会单独进行检查。即使审核代理已经点头，Kyverno 仍然可能拒绝。

以下是一条 Kyverno 规则，用于拒绝任何从已批准内部注册表之外拉取镜像的部署：

# 伪代码：拒绝非内部镜像源的部署
apiVersion: kyverno.io/v1
kind: ClusterPolicy
metadata:
  name: deny-external-images
spec:
  rules:
  - name: require-allowed-registry
    match:
      resources:
        kinds:
        - Deployment
    validate:
      message: "Only images from internal registry are allowed."
      pattern:
        spec:
          template:
            spec:
              containers:
              - image: "registry.internal.com/*"

这条规则之所以重要，是因为生成清单的代理可能误引用错误的镜像源，而受损的依赖也可能指向不该指向的位置。

另一条规则：防止 NetworkPolicy 过度放宽

当代理被要求解决连接或访问问题时，一种常见的错误是：不断放宽 NetworkPolicy 或 ConfigMap 的限制，直到症状消失，却忽略了这样的修复方案反而批准了本不该放行的流量。

入站规则中 from 字段留空意味着“允许一切”。这种变更看似能解决问题，却悄悄消除了架构依赖的网络边界。无论提出该变更的代理认为它多合理，或触发变更的事件多紧急，Kyverno 都会在请求到达集群前将其拒绝。

# 伪代码：拒绝 NetworkPolicy 中 from 字段为空的规则
- name: deny-open-networkpolicy
  match:
    resources:
      kinds:
      - NetworkPolicy
  validate:
    message: "NetworkPolicy ingress rules must specify a from selector."
    pattern:
      spec:
        ingress:
        - from:
          - ipBlock:
              cidr: "!0.0.0.0/0"

需要强调的是：这绝不取代审核代理的判断。OPA 负责从风险角度判断操作是否合理；Kyverno 则确保以 Kubernetes 对象形式表达的任何内容都符合集群自身的基线要求—不管生成该对象的代理在风险评估上推断得多好或多差。仅靠其中任何一层都不够，将任何一层视为最终决定都是错误的。

组件分解：Kyverno 位于何处

Kyverno 并未被列为上文任何一个代理所使用的工具。它工作在 Kubernetes 的准入阶段，位于审核代理之后，独立于任何代理的决策链。

审核代理的安全约束涵盖四个主要类别：

影响范围限制：防止提议响应的影响范围超过预配置的客户流量比例。
可逆性要求：每个提议的响应都必须有明确的回滚方案。
置信度阈值：置信度低于校准阈值的提议不会自动执行。
人在环中触发：特定资产类别的处理始终上报至更高层级。

此外，还有一条更窄的第五规则：任何配置变更，如果评审代理无法验证为明确无误，将被直接拒绝——不论前四类规则的评分如何。

所有这些约束都独立于任何大语言模型（LLM）提示词之外，位于评审代理在评估时直接调用的策略层中。

查看原文