Abstract / 摘要

大语言模型正越来越多地被用于支持网络运维（NetOps）和智能运维（AIOps），涵盖事件调查、根因分析、配置合成及有限的自我修复。在这一转变中，基于代理的运维工作以工作流的形式展开：从收集证据到采取行动，遵循权限、策略与检查机制，并在必要时提供回滚选项。这一点至关重要，因为操作决策可能产生即时影响。文章围绕自主性层次、工具范围、证据轨迹和保证合同来组织相关文献。这些合同定义了代理可以观察、提议和执行的内容，也定义了任何行动被许可前必须通过的检查。操作可靠性主要来自模型周围的机制——类型化工具接口、来源与新鲜度感知的检索、显式预算与停止规则、最小权限访问以及代理无法绕过的写边界验证门——而非模型本身。文章同时论证，评估应超越静态问答，需要以工作流为中心的评估，涵盖轨迹质量、有限工具使用、安全提议生成、沙盒重放、金丝雀试验及回滚感知评分。最后，文章审查了代理靠近操作控制面时变得尤为突出的安全、隐私和治理风险。综述的结论是，智能NetOps与AIOps的进步将取决于将自主性视为一个受约束的操作控制问题，其输出必须可靠、可审计且可安全部署。

I. Introduction / 引言

现代网络和云服务通过密集的遥测流、工单、运行手册、仪表盘和配置工件层来运行。过去十年中，这一层的增长速度超过了维护团队的增长速度，这主要是因为服务图、部署管道和网络策略在不断变化。与此同时，运营商已积累了用于推理配置和可达性的强大工具。真正的新颖之处并非我们在自动化运维，而在于大语言模型能够横跨整个操作表面，将零散的运维工作转变为一个“读取、推理、行动”的统一循环。 这种运维负担正被三个相关趋势加剧：操作工具表面的广度、变更的速度以及告警与事故交接的体量。在SRE领域，组织目标是在变更频率增加的情况下最小化检测和恢复时间，这使得证据收集和变更安全性成为关键约束。LLM的主要优势在于处理程序性和语言性任务的能力，两者均可借助工具得到辅助。这一视角将自主化NetOps和AIOps置于自主计算的语境中。Kephart和Chess将自主系统描述为关注配置、修复和保护的自我管理系统。基于LLM的运维代理借助自然语言界面、规划和代码生成等现代工具重新审视了这一目标。然而，这些工具也引入了新的故障类型：错误诊断、过时证据、不安全的工具使用、提示词操纵以及不受约束的执行。 LLM通过将自然语言作为状态查询和工具调用的控制层，彻底改变了用户界面。在早期部署中，这些模型主要用于事件聚合、事后分析或查询构建。随着系统演变为能够规划多步、调用API或命令行工具、直接修改配置的智能代理，这一转变变得更为重要。然而，LLM不应被视为实现智能运维的唯一途径。在多种NetOps和AIOps场景中，因果推理和依赖图方法已提供了可解释且计算开销更低的故障定位和假设生成机制。因此，一个核心设计问题是：LLM代理应如何补充而非掩盖或替代这些因果机制？

考虑一个值班事件：一次例行部署后，某项微服务的延迟SLO被违反。代理必须 (i) 检索最近的变更和所有权上下文； (ii) 发起少量具有区分度的日志/指标/追踪查询； (iii) 提出缓解措施，如功能标志回滚或流量切换； (iv) 将任何写操作路由至策略检查、不变式验证、金丝雀发布及带回滚触发器的流程中。这个例子将在后文用于说明工具循环、验证墙、评估阶梯和威胁模型。

与自主化运维相关的文献分散在网络、系统、软件工程和安全等领域。网络领域的文献强调策略和拓扑动态下的正确性与不变式。系统和SRE实践侧重于事故响应延迟、运维负载以及复杂依赖带来的脆弱性。软件工程领域则越来越多地研究LLM如何帮助运维人员表达意图和检索正确的运维证据。与此同时，基础模型研究已产生与运维直接相关的工具使用和迭代推理模式，但很少从运维风险的角度进行讨论。尽管研究者正在探索自主化工作流，但该领域仍缺乏共享的自主性术语、稳定的评估任务集以及与真实操作工具表面相匹配的清晰威胁模型。

A. Why agentic operations now / 为何现在需要自主化运维

运行任务的结构与底层模型的功能同样重要。在大多数情况下，任务涉及一系列查询和行动，且经常存在信息缺失。运维人员可能需要检查影响范围，在日志或计数器中寻找证据，提出修复建议，实施变更，然后监控是否有问题复发。这些步骤遵循明确的流程。LLM在这里很适合，因为它们能处理流程和记录中的语言。 (1) 运行任务需要大量检索：许多工作归结为搜索证据和关联来自多个工具的信息。检索增强设计通过将模型推理与对文档和系统数据的可靠访问结合起来解决这一需求。 (2) 工具调用将语言转化为可执行计划：现代LLM代理能选择工具、跨步保留状态并在新证据出现时修改计划。这类似于经验丰富的运维人员的工作流程，但代理能在不同接口上更快地重复这一过程。 (3) 网络和云已有正确性传统：NetOps拥有成熟的方法来检查变更是否违反不变式、破坏可达性或与策略意图冲突。这一传统为基于代理的系统引入了有益的约束。代理可提议行动计划，但整个系统必须在任何行动执行前检查关键属性，并将变更保持在安全范围内。 主要问题：可衡量的操作目标：本文探讨的核心问题是——我们应如何设计、评估和管理NetOps与AIOps代理，以维持甚至最大化可靠性和安全性，同时减少运维负担？从操作角度看，目标是在满足明确安全约束的前提下改善诊断和缓解时间。因此，后文关于评估的讨论将以工作流性能为主要主题，而非静态问答。

B. Scope and definitions / 范围与定义

论文使用NetOps指代通信网络特有的运维工作流，包括意图、配置、故障排查、流量工程和安全发布。使用AIOps指代AI支持的IT运维，包括日志和指标异常检测、事故分类、诊断和修复。使用“自主化”描述在步间保持状态、选择工具或行动、执行多步规划的系统，其中可能包含特定阶段的人为审批。 自主性阶梯作为一个操作对象：作者将自主性建模为一个阶梯。每一级由代理可使用哪些工具以及哪些门控是强制性的来刻画：A_k = (T_read_k, T_write_k, G_k) 。其中T_read_k是只读工具（查询和检索），T_write_k是写能力工具，G_k是不可绕过的门控（策略检查、不变式、审批、金丝雀和回滚规则）。写进一步分为提议和执行：T_write_k = T_propose_k ∪ T_execute_k。 证据轨迹用于审计和评分：代理与工具的交互被视为一等输出：E = {(τ1, y1), ... , (τn, yn)}。其中τ_i是类型化工具调用（工具名加参数），y_i是其输出。这使得“工具接地”概念更加具体：评估能判断追踪结果是否具有区分性、成本是否有限、是否足以证明提议的操作合理。 论文将研究范围限制在运维工具接口，包括监控后端、日志存储、追踪系统、配置仓库、CI/CD管道、网络控制器和工单系统。这是因为安全与治理与代理可调用的工具、它们拥有的权限以及强制执行的检查和控制紧密相连。

C. Contributions of this survey / 本文贡献

本文做出四项贡献：

• 工作流基础分类法：基于操作阶段和自主性等级构建分类系统，而非模型内部结构，并将这些角色与具体工具界面和故障模式关联。
• 架构模式与护栏：从近期系统中提取重复出现的设计模式，包括检索和证据管理、工具使用循环、以及运维助手。将这些模式映射至验证、权限最小化、分阶段部署和人工审批等护栏。
• 评估实践与基准指南：将评估方法合成为反映实际运维工作的任务定义，并讨论如何设计衡量端到端效用而非孤立语言质量的基准。
• 安全、治理与合规分析：分析自主化运维特有的问题，包括不安全的工具调用、权限和审计边界、自主性与问责制之间的张力，并强调现有网络验证和更新抽象可被重用为可执行的安全约束。

D. Organisation of the paper / 论文组织

第2章回顾NetOps和AIOps背景及运维工具栈。第3章介绍运维的LLM和代理基础，包括检索和工具使用循环。第4至6章审查架构模式和代表性系统。第7章聚焦评估与基准。第8章涵盖安全、治理与合规。第9章概述开放研究问题，随后是结论。

II. Operational background: NetOps and AIOps / NetOps与AIOps操作背景

运维最好被理解为一个在不确定性和组织约束下执行的控制问题。大多数事故并非由一次巧妙的查询解决，而是通过反复将部分信号转化为安全的、可逆的操作，同时保持较小的影响范围。这就是“有帮助的文本”只是故事一小部分的原因。关键挑战包括证据收集、变更的提议与审查，以及为后续审计和组织学习所做的决策记录。 （此处插入图1）图1：面向智能网络运维和智能运维的自主性阶梯分类法。随着系统从只读辅助转向可写执行，工程重心从答案质量转向安全操作：类型化工具接口、独立验证、审批以及支持回滚的部署流程。 图 1：面向智能网络运维和智能运维的自主性阶梯分类法。随着系统从只读辅助转向可写执行，工程重心从答案质量转向安全操作：类型化工具接口、独立验证、审批以及支持回滚的部署流程。来源：原论文 PDF 第 5 页。 图 2：跨智能网络运维和智能运维的统一证据到行动控制循环。系统被部分观测（通过工具获得 ot），行动 at 受自主性层级 Ak 约束，写侧执行通过强制门控 Gk（策略、不变式、审批、部署约束）进行中介。来源：原论文 PDF 第 6 页。

A. A unified evidence-to-action control loop / 统一的证据到行动控制循环

NetOps和AIOps均可建模为一个部分观测的控制循环。存在潜在的系统状态x_t，运维人员和自动化系统仅能通过工具中介的观测o_t来观察它，并应用行动a_t来改变未来状态。关键操作点是右侧项：代理并非在无约束的行动空间中行动，而是在自主性级别内行动，该级别由工具权限和在执行任何写操作前必须满足的强制门控定义。 （此处插入图2）图2：跨智能网络运维和智能运维的统一证据到行动控制循环。系统被部分观测，行动受自主性层级约束，写侧执行通过强制门控进行中介。

B. NetOps workflows and artefacts / NetOps工作流与工件

NetOps包含通信网络的操作生命周期，其工作流通常包括：捕获意图、集成设备或控制器变更、针对不变式和操作策略进行验证、执行分阶段部署、以及执行变更后监控并在必要时回滚。在可编程网络中，控制器在此过程中扮演核心角色。 配置之所以操作困难，是因为它不是一个单纯的参数设置过程，而是跨异构设备、存在异步收敛和涌现行为的分布式过程。配置错误源自局部错误、策略冲突、漂移或脆弱的变更序列。此外，即使最终状态正确，如果更新顺序不当，也可能通过不安全的中间状态达到。 因果诊断作为NetOps的一个原语：并非所有NetOps诊断都适合语言推理或模式识别。一种互补的研究方法采用因果推理、依赖模型和事件相关结构来解释观测症状的原因。这在网络运维中很有吸引力，因为故障沿着已知关系传播。当已知底层的因果或依赖结构时，因果方法有助于减少基于原始遥测数据和操作手册上下文的重复计算密集型推理。 验证和确认作为日常NetOps：在网络运维中，变更在提交前通常会被检查。一个简单的配置编辑就可能改变可达性、隔离性、必经点或策略合规性。这催生了将配置转化为模型并在部署前检查这些属性的工具。在控制器管理或快速变化的网络中，同样的关注出现在运行时。更新不应仅仅因为控制平面移动得快就破坏不变式。 NetOps工具和变更治理：NetOps也依赖于普通的治理机制：配置管理数据库、拓扑存储、配置平台、CI检查、控制器API和工单系统。这些工具决定谁能查看、批准和更改网络。这些对于自主化系统至关重要，因为NetOps已被工具、策略和人工审批塑造。它们并非辅助控制，而是定义了代理可用的行动表面。

C. AIOps workflows and artefacts / AIOps工作流与工件

AIOps通过将遥测转化为事故证据和响应选项来支持现代网络和云系统的日常运维。事故工作通常经历检测、分类、诊断、缓解和学习阶段。AIOps因此位于原始系统信号和运维判断之间。 在信号到决策的过程中，证据质量占主导地位。AIOps系统通常从处理告警开始，这些告警常包含噪声或模糊的症状。分类的目的是将事故导向正确的响应者并尽快消除常见原因。诊断涉及将观测症状连接到可能的故障模式。 与NetOps相比，AIOps产生更广泛、更细致的叙事性工件：事故生成时间线、聊天记录、仪表盘、值班笔记、运行手册和事后分析。这些工件捕捉了策略和实践，反映了组织认为什么是安全的、哪些行动是允许的、以及在尝试缓解之前必须收集哪些证据。 从异常检测到可操作的RCA：早期AIOps研究主要关注事故检测，但真正的操作效益在于实际缓解事故。近期研究主张在微服务环境中结合指标与其他信号，以更精细的粒度定位原因。

D. Operational artefacts as data types: trust and freshness / 操作工件作为数据类型：信任与新鲜度

自主化运维系统不可避免地消费和产生工件。将这些工件视为数据类型（而非“只是文本”）使得信任边界可见，并减少事故中在压力下的过度信任。 两个轴很有用：信任级别和新鲜度与过时风险。信任级别上，部分工件是权威性的（策略即代码、签名配置基线），部分是建议性的（运行手册、事后分析），部分被视为不可信的（自由格式的聊天记录、外部提供文档）。操作规则简单：不可信工件可为假设提供信息，但未经G_k中的独立检查，不得用于驱动写操作。运维知识会老化，新鲜度应通过时间戳、版本和来源在工件级别进行跟踪。 （此处插入图3）图3：按信任级别和过时风险划分的运维制品。同一制品可能随时间推移而变化。例如，日志变更后，运行手册可能变得过时。因此，当行动接近写边界时，检索需要来源和时效性信号。

E. Observability modalities and tool surface / 可观测性模态与工具表面

自主化运维必须连接各种证据类型与其暴露工具。每种模态都是分布式系统的一个不完美传感器。每个工具要么是产生观测o_t的读侧接口，要么是提议或执行行动a_t的写侧执行器，因此会触发门控G_k。 日志携带丰富的语义上下文，但常是非结构化的、嘈杂的且跨组件不一致。指标便宜易聚合，但主要弱点是模糊性：不同故障模式可能产生相同的指标症状。分布式追踪有价值，因为它暴露了请求路径和影响延迟的因素。工单和变更记录编码了意图、审批和问责制。操作工具决定了代理能安全观察和执行的操作：查询工具暴露证据，变更工具可修改系统。这种不对称性是运维与许多通用代理基准不同的主要原因。

III. LLM foundations for operations / 运维的LLM基础

LLM在运维中重要的原因与许多通用代理展示不同。运维工作已通过各种工具进行协调，并受到明确约束。因此，基础既包括模型本身，也包括模型所处的系统。该系统限制了模型的感知范围，使工具使用成为默认的认知模式，并将每次操作视为必须被证明合理、经过检查且可逆的变更。图4勾勒了一个实用栈，反映了成熟NetOps和AIOps组织的运作方式。LLM作为证据、假设和建议的协调者最有价值，而可靠性来自模型外部的接口和检查。 （此处插入图4）图4：实用的“大语言模型在运维中”架构。可靠性主要来自类型化工具接口、显式验证墙和门控操作行动，并围绕审批建立持久证据日志和治理机制。 图 3：按信任级别和过时风险划分的运维制品。同一制品可能随时间推移而变化。例如，日志变更后，运行手册可能变得过时。因此，当行动接近写边界时，检索需要来源和时效性信号。来源：原论文 PDF 第 10 页。 图 4：实用的“大语言模型在运维中”架构。可靠性主要来自类型化工具接口、显式验证墙和门控操作行动，并围绕审批建立持久证据日志和治理机制。来源：原论文 PDF 第 11 页。

A. A workflow contract for safe autonomy / 安全自主性的工作流合同

论文将操作代理建模为在显式工作流合同下运行。该合同使“安全自主性”变得可操作、可测试和可审计。合同利用第1节中的自主性级别对象：A_k = (T_read_k, T_write_k, G_k)，以及证据轨迹对象E = {(τ1, y1), ..., (τn, yn)}。 定义（代理工作流合同）：合同是一个元组 C = (A_k, Π, I, R, B, S)，其中Π是组织策略，I是一组操作不变式，R是一组必需的证据义务，B是预算向量，S是一组停止规则。这是表达“工具优先+门控”含义的最简单方式。

B. Budgets and stopping rules as first-class constraints / 预算与停止规则作为一等约束

操作代理受预算约束，不仅是为了成本控制，更因为有界循环是安全姿态的一部分。预算被视为向量B = (B_tool, B_tok, B_time, B_risk)。其中B_tool限制工具调用次数，B_tok限制模型上下文和生成，B_time限制延迟，B_risk限制执行违规写操作的概率。 停止规则S应是明确的、机械可执行的，例如：预算耗尽、缺少必需证据R、G_k中门控失败、重复矛盾观测、需要人工决策的不可诊断歧义。在运维中，“知道何时停止”与“知道尝试什么”同样重要。

C. Why operations need tool-first design / 为何运维需要工具优先设计

两个操作事实解释了为何流畅的文本是一个糟糕的成功标准。第一，证据由工具产生。在事故响应中，了解系统状态的可靠方式是查询它。这就是为何近期系统在LLM推理前就收集和构建诊断工件，而非要求模型从简短提示中推断状态。第二，行动必须可审查和可逆。一个答案通常暗示一个变更。因此，实用系统将行动表达为结构化提议，在模型外部检查它们，并以有限权限应用它们。

D. Prompting, schemas, and domain adaptation / 提示、模式与领域适应

对于总结、工单起草和初步分类等任务，提示通常就足够了。一旦系统提议工具调用或修复计划，目标就变了。系统必须在噪声下稳定运行，正确选择工具，遵循模式，并避免不安全的猜测。结构化输出充当可测试的执行合同。模式应像API一样进行版本管理，模式漂移是实时事故中的常见故障模式。

E. Retrieval-augmented generation for operational knowledge / 运维知识的检索增强生成

运维知识持续变化。检索因此成为一种可靠性机制，因为它限制了模型可能假设的内容。运维增加了两个更严格的要求：新鲜度和来源。 许多操作问题是时间索引的。一个运行手册步骤可能在迁移后变得错误。这就是检索和评估应具有时间意识的原因，并对依赖过时工件的行为进行惩罚。检索内容可塑造特权行动，因此检索层也是安全边界的一部分。实用设计应区分权威来源、建议性来源和不可信来源。这种分离影响着代理可以安全相信什么。

F. Tool use and controlled action interfaces / 工具使用与受控行动接口

使用工具的代理能选择工具、跨步保留状态并在新证据出现时修改计划。然而在操作环境中，工具使用必须结构化、权限化并在故障条件下进行测试。 操作工具应是类型化、版本化且权限化的。代理不应默认拥有自由形式的shell访问权。对于特权或敏感任务，应调用窄API。一个稳健的模式是要求带有前置条件和回滚步骤的差异（diff）。执行器仅在验证后应用这些差异。

G. A minimal verification wall proposition / 最小验证墙命题

论文将“验证墙”精确定义为提议与提交之间的不可绕过门控。 命题（验证墙）：假设每个写操作a（即T_write_k中的每个τ）仅当通过一个不可绕过的门g: (a, E, Π, I) → {allow, deny}（其中g ∈ G_k）时才被执行，且g在建模域内是合理的。那么所有已执行的写操作序列在建模域内满足Π和I。该证明通过假设和归纳得出，但未在建模域外提供保证。

H. Planning patterns with explicit budgets and gates / 带显式预算和门控的规划模式

自主化运维聚焦于少数规划模式，因为事故倾向于遵循一个递归循环：假设、测试、缓解、验证。与通用代理的区别在于计划受到Π、I、预算B和门控G_k的约束。

I. Safety foundations that interact with tool use / 与工具使用交互的安全基础

自主化运维扩展了攻击面，因为它将不可信文本和遥测路由到特权行动中。安全因此属于架构基础。 提示注入和不可信文档是重要威胁。操作规则简单：将检索到的文档视为不可信输入，隔离工具权限，在执行任何操作前执行独立检查。遥测操纵构成完整性攻击，即使表现良好的模型也可能被虚假输入操纵。三个护栏可强制执行：最小权限工具访问、独立验证门控、以及通过审批、金丝雀发布和回滚就绪性控制的自主性。

IV. Agentic architecture patterns for operations / 运维的自主化架构模式

自主化NetOps和AIOps系统主要差异在于它们被允许做什么。描述这一点的一个有用方式是自主性阶梯，其中每一级都是一个能力合同，而非产品标签。

A. Autonomy rungs as capability contracts / 自主性阶梯作为能力合同

论文将阶梯定义与工具范围和不可绕过门控绑定。对于代理产生的任何候选动作a，门控建模为一个全函数g_k(a, E, Π, I) ∈ {0,1}，仅当动作在策略Π下被允许、传递相关不变式I并满足G_k中的门控条件时才返回1。这一框架使自主性表述精确：一个系统并非因为听起来谨慎就“安全”，只有当其写操作受T_execute_k约束且无法绕过g_k(·)时才安全。

B. Ladder of autonomy with explicit tools, gates, artefacts, and success / 带有显式工具、门控、工件和成功的自主性阶梯

表II总结了四个常见级别：Copilot（只读）、Analyst（只读诊断）、Planner-executor（写有限）、Closed-loop（自愈）。每个级别列出工具范围、强制门控、生成工件和成功标准。 Copilot级别：改善运维人员吞吐量，成功标准是更快找到证据和更少遗漏信号。Analyst级别：运行读查询、维护竞争假设、生成结构化RCA报告，主要故障模式是故事模式。Planner-executor级别：安全自主性成为整个系统的属性，成功不仅是变更被应用，更是应用时不违反检查属性且系统能快速返回已知良好状态。Closed-loop级别：集成检测、诊断、缓解和恢复验证，行动范围必须极窄，回滚需自动发生。

C. Reference architecture and evaluation observables / 参考架构与评估可观测项

图4给出了本文使用的参考架构。其实际价值在于使后文评估具体化，暴露了可跨任务、轨迹和部署阶段测量的可观测项，包括：证据质量、门控行为、提议质量和操作结果。

D. Human review as a concrete object / 人工审批作为具体对象

在受门控的规划-执行系统中，人类审查的不是聊天记录，而是可评分、存档和重放的数据包R = (∆, Pre, Checks, Canary, Rollback, Ptrs(E))。这是问责制的实际接口。

E. Failure modes by rung / 各级别的故障模式

自主性改变了哪些故障占主导地位。在低级别，主要损害是浪费时间和对误导性解释。在高级别，主要损害是不安全的变更和难以审计的行动。论文用热图总结这一转变，跨常见风险：幻觉、工具滥用、通过工件的提示注入、已验证状态与已实现状态之间的漂移、以及回滚失败。定性结论是，在较高级别，门控和验证不是可选项，而是一旦T_execute_k非空时的绑定约束。

V. Agentic NetOps / 自主化NetOps

NetOps是自主化系统的自然目标，因为许多操作任务已遵循可重复循环。同时，NetOps比许多AIOps场景有更高的安全门槛，因为一个错误变更可能迅速传播，引发大范围中断或创建难以调试的瞬态行为。这种结构化工作流与高后果的结合使NetOps成为LLM自主化设计的有用压力测试。LLM很少是“决定网络状态真相”的正确位置。相反，作为工作流控制器最有价值：将意图转化为查询、通过验证器路由证据、提议最小侵入性差异并记录前置条件和回滚。 （此处插入图9）

A. NetOps property definitions (targets for the verification wall) / NetOps属性定义（验证墙的目标）

为将“验证”具体化，论文固定了一个紧凑模型和一组在NetOps文献中反复出现的属性。将网络建模为有向图G=(V,E)。使用谓词定义可达性、隔离性、必经点和无循环等不变式。这些涵盖了最常见的操作问题，并与配置分析器和不变式检查器通常被要求证明或反驳的内容一致。

B. Intent, ambiguity, and when clarification is mandatory / 意图、歧义与何时必须澄清

自然语言意图通常是欠指定的，即使由经验丰富的运维人员表达也是如此。意图常遗漏对安全重要的操作约束。对于自主化NetOps，这建议了一种安全分工：LLM处理歧义解决并产生结构化候选，而合成和检查后端提供关于正确性的权威。一个实用且可检查的强制澄清条件是存在多个不同的差异，它们通过当前检查但为某些流量类诱导不同的转发语义。

VI. Agentic AIOps / 自主化AIOps

在AIOps中，观察结果不完整且常常过时，能够真正变更系统状态的能力比在NetOps中更受限制。这并不降低AIOps的难度；这仅仅改变了设计重点。AIOps代理必须处理叙事性工件、噪声遥测和随时间漂移的运行手册。AIOps中的根因分析通常被表述为在部分可观测性下的因果分配问题。给定一段观测序列o_t，代理必须定位一组最小的组件或上游服务，其故障或变更能最经济地解释观测到的症状。 LLM为日志理解和异常检测提供了新能力。智能运维代理将LLM的推理能力与结构化运维工件联系起来。在受约束的行动包絡下规划缓解措施是AIOps的另一个关键设计点。工作流工件本身可能成为对抗性输入。AIOps的基准和数据集方面，近期工作正在向工作流为中心的评估发展，但仍缺乏统一的标准化基准。

VII. Evaluation and benchmarking / 评估与基准测试

评估需要从静态问答转向工作流为中心的评估。论文提出了一套评估模式和要求。指标词汇表包括：轨迹完整性、证据区分度、工具预算利用率、门控通过率、提议有效性和操作结果度量。论文建议每篇论文应报告一个标准评估成绩单，包含任务类型、自主性级别、预算设置、轨迹评分和操作结果。离线评估使用数据集、指标和协议来测量代理在固定条件下的表现。在线评估则在沙盒和真实环境的金丝雀测试中进行。基准仍处于早期阶段，需要更现实、可复现且包含操作约束的评估任务。

VIII. Security, privacy, safety, and governance / 安全、隐私、安全性与治理

当代理靠近操作控制面时，安全、隐私、安全性和治理风险变得尤为突出。论文定义了攻击者模型、资产和信任边界。与通用LLM代理不同，操作代理对真实基础设施拥有特权写访问，因此威胁更加严重。威胁包括：提示注入、检索投毒、遥测完整性攻击、过度授权和弱可审计性。论文将威胁映射到控制措施和可测量测试，讨论了遥测完整性检查、不可绕过策略门控、隐私与合规要求、以及治理工件。安全评估协议需确保控制措施的有效性以及审计轨迹的完整性。

IX. Open problems and research agenda / 开放问题与研究路线图

*问题框架化：*将自主性级别和操作保证合同作为核心概念。*验证、保证与跨层和时间的组合安全：*如何跨抽象层和时间推移提供保证。*基准现实性与可再现性：*需要更真实、可复现且基于合同的评估。*混合因果-LLM操作：*如何将因果推理与LLM结合。*安全与完整性作为合同条款而非附加项：*安全应从架构基础中考虑。*人为因素与问责制：*人机协作和审计责任。*标准化与最小互操作模式：*需要共享的模式和接口。*持续操作：漂移、学习、治理与成本：*系统需应对知识漂移并持续更新。

X. Conclusion / 结论

智能NetOps和AIOps的进步将取决于将自主性视为一个受约束的操作控制问题，其输出必须可靠、可审计且可安全部署。操作可靠性主要来自模型周围的机制，而非模型本身。评估需要以工作流为中心。NetOps是验证自治的尖锐测试床。安全性应在架构基础中考虑。

原文信息

英文题目： Large Language Models for Agentic NetOps and AIOps: Architectures, Evaluation, and Safety 作者： Muhammad Bilal, Jon Crowcroft, Ruizhi Wang, Xiaolong Xu, Schahram Dustdar arXiv ID： 2605.12729 类别： cs.NI, cs.AI, cs.CR Comments/项目信息： 50 pages, 15 figures, 6 tables; survey article 原文链接： http://arxiv.org/abs/2605.12729v1