你即将面临的问题
一个投入生产的 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.config_validated == false} else := {"result": "escalate", "reason": msg} if { sensitive_elements[input.asset.element_id] msg := sprintf("%s is a sensitive network element and always escalates", [input.asset.element_id])} else := {"result": "auto_reject", "reason": msg} if { input.action.blast_radius_pct > data.limits[input.action.type].max_blast_radius_pct msg := sprintf("blast radius %.2f exceeds limit for %s", [input.action.blast_radius_pct, input.action.type])} else := {"result": "auto_execute"} if { config_ok not sensitive_elements[input.asset.element_id] input.action.blast_radius_pct <= data.limits[input.action.type].max_blast_radius_pct input.action.confidence >= data.limits[input.action.type].min_confidence input.action.reversible == true}config_ok if { input.action.type != "modify_config"}config_ok if { input.action.type == "modify_config" input.action.config_validated == true}sensitive_elements := {"upf-fr-paris-04", "sepp-fr-edge-01"}阈值本身存储在单独的数据文档中，而非硬编码在策略中。这种方法使决策逻辑与实际的风险容忍度能够单独进行版本控制。SOC 团队可以在不触及规则结构的情况下收紧阈值。
{ "limits": { "deploy_rule": { "max_blast_radius_pct": 0.5, "min_confidence": 0.7 }, "execute_containment": { "max_blast_radius_pct": 0.2, "min_confidence": 0.9 }, "modify_config": { "max_blast_radius_pct": 0.3, "min_confidence": 0.8 } }}假设检测工程代理为一个新的检测传感器生成了一个 Kubernetes 部署，审核代理根据影响范围和可信度批准了该部署。但批准并不意味着一切就此结束。在该对象到达 Kubernetes API 服务器之前，Kyverno 会单独对其进检查，即使审核代理已经批准，Kyverno 仍然可能拒绝该部署。
以下代码片段是一条规则，用于拒绝任何从已批准内部注册表外拉取镜像的部署。这一点至关重要，因为生成清单的代理可能会误引用错误的镜像源，而且受损的依赖项可能会指向不应指向的位置。
apiVersion: kyverno.io/v1kind: ClusterPolicymetadata: name: trusted-registryspec: validationFailureAction: Enforce rules: - name: verify-registry match: any: - resources: kinds: ["Deployment"] validate: message: "Images must come from the internal trusted registry" pattern: spec: template: spec: containers: - image: "registry.internal/*"第二个代码片段是一条规则，用于捕获另一种错误：代理提出了一个有效的修复方案，但会打开远超预期数量的源。
当要求代理解决连接或访问问题时，一种常见的失误是不断放宽 NetworkPolicy 或 ConfigMap 的限制，直到症状消失，但却没有注意到该修复方案批准了本不应放行的流量或访问。
apiVersion: kyverno.io/v1kind: ClusterPolicymetadata: name: block-permissive-network-policyspec: validationFailureAction: Enforce rules: - name: reject-allow-all-ingress match: any: - resources: kinds: ["NetworkPolicy"] namespaces: ["soc-agents"] validate: message: "NetworkPolicy must not allow ingress from all sources" deny: conditions: any: - key: "{{ request.object.spec.ingress[].from[] | length(@) }}" operator: Equals value: 0入站规则中 from 字段留空即表示“允许一切”，而这正是这种变更，看似能解决眼前的问题，却悄无声息地消除了架构所依赖的网络边界。无论提出该变更的代理认为其多么合理，或触发该变更的事件多么紧急，Kyverno 都会在请求到达集群之前将其拒绝。
这并不能取代审核代理的判断。OPA 负责从风险的角度判断某项操作是否合理。Kyverno 则确保以 Kubernetes 对象形式表达的任何内容都符合集群自身的基线要求，而不管生成该对象的代理在风险评估方面推断得有多好或多差。仅靠其中任何一层都不够，将其中任何一层视为最终决定都是错误的。
组件分解
需要指出的是，Kyverno 并未被列为上述任何一个代理所使用的工具。它位于审核代理之后，在 Kubernetes 准入阶段发挥作用，独立于任何代理的决策。
审核代理的安全约束涵盖四个类别。影响范围限制可以防止提议响应的影响范围超过预配置的客户流量比例。可逆性要求规定，每个提议的响应都必须具有明确的回滚方案。置信度阈值可以防止置信度低于校准阈值的提议执行，从而避免所有请求自动执行。最后，人在环中触发机制会始终将特定资产类别的处理上报至更高层级。此外，还有一条范围更窄的第五规则：任何配置变更，如果评审代理无法验证为明确无误，都将被直接拒绝，而不管其他四类规则的评分如何。这些约束独立于任何大语言模型（LLM）提示词之外，位于评审代理在评估时直接调用的策略层中。
系统为何能保持迅速响应
针对投入生产应用的多代理大语言模型（LLM）系统，延迟是一个合理的质疑点。如果每个安全事件都触发完整的扇出流程——从上下文分析到检测工程、响应再到审核，每个环节都调用一个 LLM——那么在电信核心网那样的业务量下，每起事件所需的时间和令牌成本将难以承受。
该架构通过异常门控推理解决了这一问题。在分诊代理调用任何 LLM 之前，原始遥测特征向量会先由隔离森林（Isolation Forest）模型进行评分。这是一种基于滚动历史流量训练的无监督异常检测算法。选择隔离森林模型是经过深思熟虑的：它推理速度快、无需标注、能很好地处理高维输入，并且在分布漂移的情况下仍然能保持性能的平稳下降。只有异常评分超过校准阈值的样本才会被转发给由 LLM 驱动的代理。其余样本则在指标层面进行汇总后丢弃。
实际效果是，由大语言模型（LLM）驱动的处理流程承担了此前由人工检测工程师负责的工作（即调查新型模式），而且无需处理常规流量。LLM 路径上的单事件延迟受扇出过程中最慢节点的限制（在我们的部署中，包括审核代理策略评估在内的端到端延迟上限不足 10 秒），而且 LLM 路径本身仅对极少数事件进行处理。
有两个设计要点值得特别指出。隔离森林每周重新训练一次，而且两次重新训练之间的特征漂移会被作为首要指标进行追踪；过时的异常模型会悄无声息地增加 LLM 的工作负载。阈值本身是审核代理参考的策略参数。因此，在面对运营压力时，它可以不重新部署任何代理即可收紧阈值以减轻 LLM 的负载。
协调层是什么样子的
为了使该模式具像化，以下代码片段演示了分诊代理与检测工程代理之间 A2A 任务消息的结构。具体的模式属于内部实现细节，但该信封结构体现了 A2A 所规定的结构：
{ "task_id": "tsk_2026-03-24_8c1b9f", "from_agent": "triage.v3", "to_agent": "detection_engineering.v2", "intent": "synthesize_detection", "trace_id": "01HSMJ8...", "context_refs": [ "mcp://asset-inventory/upf/upf-fr-paris-04", "mcp://detection-index/recent?window=14d" ], "payload": { "observation": { "...telemetry fingerprint..." }, "novelty_score": 0.92, "deadline_ms": 90000 }, "constraints": { "rule_language": "sigma", "must_include_test_corpus": true, "max_false_positive_rate": 0.005 }}有两点值得专门提一下。首先，代理间信封携带一个随任务传播的 trace_id。每个下游链路跨度都属于同一个分布式追踪：检测工程代理对 MCP 的调用、审核代理的策略评估，以及最终的部署。这正是该系统可调试的关键所在。
其次，context_refs 字段携带的是 MCP URI，而非嵌入式上下文。检测工程代理将在评估时通过 MCP 解析这些 URI。这种解析方式既能保持有效载荷小巧，又能使上下文代理在 MCP 边界实施访问控制，并确保资产清单的任何变更都能立即被所有代理感知。
MCP 调用资产清单的结构如下例所示：
GET mcp://asset-inventory/upf/upf-fr-paris-04 Headers: { agent-identity: spiffe://company.com/sa/detection_engineering } Returns: { hostname, customer_segments, NF_role, last_seen, ...}代理的身份是在网格层绑定的工作负载身份；MCP 服务器会根据该身份对清单执行授权。身份即流量策略才是恰当的做法。
一个典型的请求流
假设分诊代理在 5G 核心网中的 User Plane Function（UPF）上检测到一个此前未见过的控制平面信号异常：
分诊代理对该异常进行分类，通过 MCP 向上下文代理查询该 UPF 的元数据、对客户的影响以及近期历史记录，并判定该模式为新型异常。
分诊代理向检测工程代理分发一个 A2A 任务，例如，“利用一个小型测试语料库，合成一条本应更早捕获此模式的检测规则”。
与此同时，分诊代理向响应代理分发一个 A2A 任务，例如，“假设此信号模式有恶意，提出一项遏制措施”。
两项建议均通过 A2A 提交给审核代理。
审核代理根据策略包（OPA 风格规则）来评估每项建议。若两项均通过审核，则部署该规则并执行响应措施；若任意一项未通过，则将该情况连同代理的完整推理链一并上报给人工 SOC 分析师。
面对每天数百个这类流程，该方法实现了规则创建效率的提升，而且我们在运营商层面观测到了自主策略实施覆盖范围的增长。
可量化的成果
与基准架构相比，在内部评估中使用相同的事件类别，我们测得：
MTTD（平均检测时间）和 MTTR（平均修复时间）均缩短了约 40%。
在 5G 核心网中自主生成了 80 多条检测规则，这些规则都已通过审核代理进行验证，并经过人工抽样审核。
生成一条新检测规则所需的人工时间压缩了约 12 倍（从 3 小时缩短到了约 15 分钟）。
可以同时监控 15 至 20 个 5G 网络功能。
理解上述数据需要结合两方面的背景信息：这些数据源自该平台的内部基准测试以及运营商的事件响应指标，而非第三方研究。这些数据是以同一运营商此前采用的架构为基准进行对比；你的基准可能会有所不同。
权衡与适用范围的局限性
当你的安全运营中心（SOC）事件量大，而且规则库规模庞大到使维护成为结构性瓶颈时；当漏检成本很高（例如关键基础设施、金融服务和电信核心网）时；以及当你的工程能力已经足够成熟，能够将审核员的安全策略视为一等配置项时，这种模式非常适用。
如果规则数量比较少，以至于人工检测工程不是瓶颈；如果法规要求检测逻辑必须完全确定且可静态审计；或者如果运营商的工程职能没有涵盖审核员安全策略，那么该模式就不适用。最后一种情况最为关键：如果没有这种所有权，无论其余部分设计得多么完善，平台都是不安全的。
有几个注意事项值得明确说明一下。该架构将检测工程师的工作重心从规则编写转移到了审查员策略的维护和代理输出审核上，但并没有彻底消除这些工作。A2A 和 MCP 仍然在不断演进，因此，任何未经红队测试的审查员安全约束都应被视为不完善。
如果重来一次，我会怎么做
事后看来，有两件事本可以有更好的做法。我低估了编写有用的 OPA 策略所需的工作量；虽然代码量不大，但设计正确的不变量（尤其是合适的影响范围约束）需要与 SOC 团队进行多轮沟通，而我此前并未为此预留时间。此外，我将审核代理设计成了单个代理。吸取了这次经验教训，现在我会将审核代理拆分为执行前审核代理（即：该操作是否符合策略？）和执行后审核代理（即：该操作是否产生了预期效果？），并将审核代理的结果反馈用于审核代理策略的调整中。
在该架构的实现和评估过程中，我总结出了一些经验教训。
首先构建审核代理
安全底线由审核代理设定。如果在扩展代理层的其余部分之前就在约束条件上投入精力，就可以避免事后给约束打补丁的麻烦。
从第一天起就将“异常”作为预过滤条件添加进来
最初，我们过早地将事件分发给基于大语言模型（LLM）的代理，直到面临生产环境负载时才发现成本和延迟问题。如果从一开始就在 LLM 层前部署一个隔离森林，本可以节省四分之一的运维应急处理工作；同样，将异常阈值视为需经审核代理确认的策略参数，而非配置常量，也能达到相同的效果。
抵制“巧妙”的提示
在实际开发中，仅有一页的简洁系统提示总能胜过繁琐的个性化设计。过度的巧思会累积成技术债务，并掩盖变更管理背后的故事。
尽早发布模式
A2A 和 MCP 已经公开发布，但基于它们构建的 SOC 领域代理模式仍然仅限内部使用。发布 SOC 领域代理的参考模式，并公开审核代理使用的策略语言，具有行业价值。该领域将在 2026-2027 年逐步采用共享模式；越早实现越好。
小结
通过 A2A 进行协调、通过 MCP 实现集成的安全运维多代理 AI，对我们而言不再是未来的选择；它已经是一种已取得可量化成果的现行生产模式。这种模式并不意味着它是万能的解决方案；其中的权衡取舍是真实存在的。但就规模庞大到规则维护已成为结构性瓶颈的云原生 SOC 而言，根据我的经验，这是当今最稳健的架构选择。
自从在 KubeCon 上展示这一架构以来，我不断地听到两个问题：如何保持其响应性，以及人类在其中扮演什么角色。这两个问题的根本答案是一致的：在放置大语言模型（LLM）的位置上要严格把控，将成本更低、更可预测的机制置于价格高昂的机制之前。采用开放协议而非定制总线，在“策略即代码”（policy-as-code）中优先考虑安全性，而非依赖系统提示。要始终把“人在环中”的路径作为系统的常规输出，而非作为额外追加进来的例外情况。
在未来的十八个月内，真正有意义的工作不在于模型的扩展，而在于强化审核代理，标准化安全运营中心（SOC）领域的代理架构，以及编写安全策略——正是这些策略能将一个精妙的架构转变为一个在运营上值得信赖的架构。
原文链接：https://www.infoq.com/articles/multi-agent-security-operations/
