摘要

  • LACNIC 9 月 9 日刊登的客座文章，把“能够执行”和“能够决策”区分开来，并建议从一个自治域、一个运营流程开始。这意味着等级首先属于被测场景，不能直接变成整家企业的属性。
  • 一项可复核的自治声明需要场景账本：被测对象与时段、五个环节的人机分工、按最低项得出的等级、证据、基线与结果、人工干预权，以及系统变化后的重新评估条件。

设想两家运营商都把自己写成 L3。第一家已经让系统自动收集告警、关联症状并提出修复方案，但每一次配置变更仍由工程师批准。第二家可以自动完成业务开通与配置下发，却要靠人工核实部分资源清单。两张幻灯片上的数字相同，真正的依赖却落在不同位置。采购者、值班人员和风险负责人需要知道的，恰恰是那个位置。

2026 年 9 月 9 日，LACNIC 博客刊登了 Hernán Arcidiacono 的文章。页面介绍他是 Iplan Argentina 的 CTO，也是 IANA Review Committee 成员，同时明确注明观点属于作者本人，并不必然代表 LACNIC。文章开头给出一个很有用的切分：自动化讲的是执行能力，自治讲的是决策能力。前者按照预设规则应对已知事件；后者还要感知自身状态、目标或意图以及外部环境。

文章随后把讨论从设备层推向企业运营。它援引的 TM Forum 框架包含资源、服务和业务三层，因此“自治网络”并不只是让路由器少等一次人工命令，而是改变企业安排、交付和监督工作的方式。不过，作者给出的起步方法很克制：先选择一个自治域，例如接入或 IP；再选择一个具体流程，例如故障管理；逐步让人从闭环的部分环节退出，并在早期保留人的决策位置。

这种“小步开始”不是临时性的工程注脚，而是评估范围。项目从一个域和一个流程开始，证据就只覆盖这个域和流程。它不能自动证明计费、客服、核心网、安全响应、能耗优化也处于同一水平。企业可以有一个宏大的自治目标，却同时拥有许多不同的局部成熟度。

先写清测什么，再讨论到几级

TM Forum 对 IG1252 的公开说明，把评估对象写成“一张网络或其中一部分”，并将方法落到运营流程、子流程、任务和任务标准。数字并不是悬在企业名称上方的声誉，而是从具体工作中推导出来的结果。

ITU-T Y.3173 把这条边界说得更细。它同时观察网络生命周期中的工作流和网络子系统。整网等级只是各个相关工作流与子系统等级的综合反映；只有当相关对象都达到或超过某个门槛，整网才可以被视为达到该等级。工作流与子系统又会随用例变化，因此同一套基础设施在不同用例中可以得到不同答案。

这份建议书使用五个维度：

  1. 需求映射：把运维需求变成网络组件能够理解和执行的指令；
  2. 数据采集：取得分析所需的状态信息；
  3. 分析：解释当前状态，并在需要时预测变化；
  4. 决策：选择配置或业务动作；
  5. 动作执行：把决定真正作用于网络。

每个维度都要说明由人、人与系统共同，还是系统完成。一个用例的汇总等级随后取各维度中的最低适用等级，而不是取最高值或平均值。最先进的演示不能替整条闭环背书。

这条“取最低项”的规则能挡住展厅式会计。一个准确的告警分类器，并没有让变更批准自动变得自治；一个能够写出漂亮方案的智能体，并不能证明输入数据充分；一次无人值守的快速执行，也不能修复含糊的意图。薄弱的连接必须继续出现在结论里。

Y.3173 还保留了一条常被宣传语忽略的限制：无论处于哪一级，人的决策与执行指令都应具有最高权威。等级不会自动分配法律责任、合同责任和中止权。谁能叫停、谁能接受例外、谁承担损失，仍需要单独设计和记录。

能力提高，不等于效果变好

第二种常见错位，是把更高的自治等级直接当成更好的业务结果。2025 年 12 月通过的 ITU-T Y.3063 把两件事分开。它的四层框架包括：业务价值目标、端到端业务场景结果、特定域的网络能力指标，以及计算指标所依赖的网络系统数据。

更多任务自动完成，可能减少重复劳动，却不一定提高可用性；处理时间缩短，可能把成本挪到罕见例外上；节能动作可能牺牲覆盖；人工工单下降，也可能与投诉上升同时发生。成熟度回答“谁在做”，效果评估回答“做完以后发生了什么”。

Y.3063 把目标分为客户体验、运营效率和资源效率。可选指标包括业务交付与激活时间、可用性、中断时间、平均恢复时间、资源部署时间、运营自动化比例、能耗与资源满足率。它明确指出，不是每个指标都适合每个场景。评估必须先声明基线、观察期和聚合方式。

该建议书的实践附录先要求列出各运维域中的端到端业务场景，再为每个场景推导指标、衡量贡献、排列优先级，最后采用“先试点、后扩展”。这与企业徽章的逻辑正好相反：不是先挑一个好看的数字，再寻找能够支撑它的片段；而是先把工作清单摊开，说明希望改变什么价值，再扩大已经证实有效的部分。

这对拉美和加勒比地区的中小 ISP 尤其重要。Arcidiacono 认为，中小运营商不应把自治视为大型运营商的专利，也要考虑落后的竞争风险。场景方法让这种建议更可执行：一家区域 ISP 不必复制跨国转型计划，可以挑出一个反复发生、成本高或容易出错的流程，记录现有人机分工，自动化有限部分，比较前后结果，再决定是否扩大。

场景账本该留下哪些连接

这里提出的账本是 Theo March 的分析，并不是 LACNIC、TM Forum、ITU 或 ETSI 的正式要求。它的目的，是保存宽泛等级会抹掉的连接。

第一组字段确认身份与范围：运营商、责任人、被测域或网络部分、用例、工作流、触发条件、评估时段和方法版本。“故障管理”仍然太宽，基站小区故障、光传输故障和配置漂移应当是不同记录。

第二组字段保存五维向量。需求、数据、分析、决策和执行分别由谁完成，要用意图版本、数据引用、模型或规则版本、决策记录、变更编号和事后状态检查来佐证。摘要等级取适用最低项，同时必须保留生成它的完整向量。

第三组字段记录效果：基线、与场景匹配的指标、观察窗口和结果。平均恢复时间、可用性和自动化比例互不等价。若把它们揉在一起，项目总能挑出一项改善，遮住另一项恶化。

第四组字段记录控制：人工干预权、动作半径、例外路径、回滚负责人和终态证据。文档里写有“支持回滚”并不够。对于一次真实动作，需要把触发、建议、决定、变更、异常效果和恢复串成同一条记录。

最后一组字段规定失效。模型、意图、拓扑、数据源、供应商、软件版本、动作权限或流程发生实质变化，都可能让旧评估失去意义。账本应给出到期日与重新评估触发器，否则旧系统挣来的等级会长期寄生在新系统上。

智能体越多，范围越不能省略

ETSI GS ZSM 002 区分域内管理和跨域端到端管理。多个闭环可以在不同粒度上并行运行，并以横向或层级方式协作。2026 年 1 月发布的 ETSI GR ZSM 020 又区分由人决策的助手、受监督的自治智能体和完全自治智能体，同时按功能与动作类型进行分类。

在跨域故障示例中，本地智能体发现问题、查找其他能力、把上下文上报给端到端协调者、组成调查团队，并在处理后收集反馈。这套协作可以高度复杂，而关键批准仍由人完成；反过来，一个狭窄的域内流程也可以高度可靠，却不足以描述整家运营商。

参与者越多，“我们是 L4”透露的信息反而越少。必须继续追问：哪个智能体、哪个场景、哪项能力、谁给出的决策权、执行了什么、最终状态如何验证。

等级必须会过期

自治声明常经历五次越界：最自动化的任务代表整条闭环，闭环代表整个域，域代表企业，能力代表效果，旧评估代表已经变化的系统。每一步都让表达更好卖，也让问题更难定位。

LACNIC 所刊文章最有价值的地方，是从一个对象、一个流程和渐进改变出发。拉美和加勒比地区不需要把这种克制重新包装成空泛的成熟度口号。不同规模的运营商可以保留同一套等级语言，但每个数字都必须指回它所描述的工作。

自治等级不是永久头衔。它是一项带范围、证据和期限的技术声明。

来源