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

你即将面临的问题一个投入生产的 5G 核心网每小时产生的安全遥测数据，比大多数企业安全运营中心（SOC）一周内接收到的数据还要多。成熟 SOC 的瓶颈很少在于分析师的初步筛查；真正的问题在于，检测工程团队能否让规则库与威胁形势保持同步——威胁形势的演变速度往往快于规则的编写速度。下文所述的架构模式基于某一级电信运营商 5G 核心网中的生产级安全运维实践，并在过去一年中通过不断的运维反馈和内部部署进行了持续优化和改进。该架构采用多代理层设计，通过 A2A 协议进行协调，并通过 MCP 与环境集成，同时配备一个特权审核代理来执行安全检查代码。对照已完成基线标定的事件分类体系测算，该平台将平均检测时间和响应时间分别缩短了约 40%，自主生成了 80 多条此前无法编写出来的检测规则，并将制定新规则所需的人工时间从大约 3 小时压缩至 15 分钟。该平台可以同时监控 10 至 20 个 5G 网络功能。两种无效模式以及为什么在当前关于安全运维 AI 的行业文献中，有两种主流的模式，而在我看来，在电信核心网络这种规模下，这两种模式都行不通。单个 LLM将管道安全遥测数据、资产上下文和操作员查询整合到一个大模型中，并要求其生成检测结果和响应。该模型在生产环境中失败了，原因有三个，而且这些原因是相互叠加的。首先，对于实际的安全运营中心（SOC）所要处理的远程监测数据而言，上下文窗口过小。此外，模型具有不确定性，而这种特性对于触发生产基础设施自动隔离这样的输出结果而言是不可接受的。最后，单个提示词的修改会改变整个 SOC 的行为，这使得变更管理几乎无法进行。将生成式人工智能（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）在运行时即时推导安全决策。这是一个糟糕的主意。审核代理应调用一个独立的策略层（在本例中为 OPA），并根据确定性的裁决采取行动；审核代理自身的提示词很简短，而策略本身则是受版本控制的代码。特性 5：人在环中作为一等输出每一项具有重大影响的决策都有三种最终状态：自动执行、自动拒绝，以及连同完整的推理链一并上报给 SOC 分析师。当审核代理的信心低于阈值、资产类别在“始终上报”列表中，或者拟采取的行动将超出配置的影响范围时，系统将进入第三种状态。这种方法所贯彻的纪律虽然不合时宜，却至关重要：有些决策绝不应该自动化。该协议机制会在采取任何行动之前，将决策连同代理的所有推理过程一并转至人工处理队列。审核代理的策略具体是什么样子特性 4 将审核代理描述为一个策略层，而非一个提示词。实际上，该层由 OPA 和 Kyverno 两个协同工作的层组成，它们分别承担着不同的职责。由 OPA 支持的审核代理会从运营风险的角度（包括影响范围、可信度、可逆性以及人工升级）决定某项操作是否被允许。操作请求到达集群后，Kyverno 会独立验证该操作在 Kubernetes 底层的实现方式：可信镜像来源、工作负载身份、资源约束以及准入控制。OPA 负责强制执行业务安全不变量，Kyverno 负责强制执行平台安全不变量。二者协同工作，在代理推理与生产环境执行之间为系统提供多层次的深度防御。关于下文将要介绍的 OPA 策略所依赖的字段，这里简要说明一下。提议代理会在提出建议时估算影响范围和置信度。影响范围是指若提议的操作出现问题时，可能受其影响的客户流量占比；而置信度则表示提议代理对其自身提议正确性的信心程度。可逆性取决于操作类型本身：阻断路由具有明确的回滚机制，而删除或重新配置核心组件通常不具备回滚机制。Config_validated 与其他三个字段不同，它必须由审核代理设置，绝不会由提议代理设置，因为代理不应该能够将自身的配置更改标记为安全。下面的输入内容并非提议代理原样发送过来的。审核代理会根据提议构建这样一个输入，并添加诸如 config_validated 之类的字段。这些字段仅允许审核代理进行设置。package reviewer.policy# Input shape, illustrative only. Built by the reviewer agent from the proposing agent's output, not sent as-is by that agent.# {# "action": {# "type": "deploy_rule", # deploy_rule, execute_containment, or modify_config# "blast_radius_pct": 0.8, # estimated by the proposing agent at proposal time# "confidence": 0.94, # the proposing agent's own estimate that its proposal is correct# "reversible": true, # set from the action type, not estimated# "config_validated": true # set by the reviewer, never by the proposing agent# },# "asset": {# "NF_role": "upf",# "element_id": "upf-fr-paris-04"# }# }## Thresholds referenced below, data.limits, come from a separate data document, not from this file.default decision := {"result": "escalate", "reason": "no matching rule"}decision := {"result": "auto_reject", "reason": "configuration change is not clearly validated"} if { input.action.type == "modify_config" input.action.con