软件定义网络把人从设备命令行里解放出来，却没有把人从"翻译"这件事里解放出来。
当基础设施的反馈周期从"季度"压缩到"毫秒"，翻译这件事就必须交给机器------但要交给一个被约束、可验证的机器。
而让 AI 的"理解"不至于变成天马行空的，不是更长的提示词，而是三件事：它读到了什么、它的输出被什么结构约束、以及谁在最后独立验证它。
〇、引言：两句话，隔着十三年
2013 年的一个网络变更窗口。 一位网络工程师要在两台核心交换机之间新增一条业务链路。他的动作序列是这样的：登录跳板机，show run 导出配置，在本地文本编辑器里对齐 ACL 编号和 VLAN 段，确认 STP 拓扑不会因为新链路的 cost 变化而收敛到错误的方向，然后用 SecureCRT 的批量发送功能把配置刷进六台设备。刷完后 ping、traceroute、看 show interface counters，最后在变更单上写"已完成，业务验证正常"。
2026 年的同一个机房。 同一个人的工作开场白可能变成一段话：
为训练任务 train-llm-70b-phase2 开通跨 8 个 rail 的无损网络。每张 GPU 只允许与同 rail 的 leaf 互通，禁止任何跨 rail 绕行。变更不得影响现有三个租户的可达性。任一 spine 的 PFC pause 帧速率超过 1000pps 立即回滚。变更后 72 小时 all-reduce 有效带宽不低于基线的 95%。
这两段话之间隔着的，不只是 SDN 控制器、Telemetry 和自动化平台。隔着的是控制权的三次迁移：从"设备自己算"，到"控制器统一算"，再到"系统按业务结果自己算"。
推动这一能力扩展的重要背景之一，是 AI Infra 对网络性能、跨域协同与变更可验证性的更高要求。
不过，一旦把"理解意图"这件事交给大模型，立刻会撞上一个现实问题：模型的脑子里装的是"一般意义上的网络"，而你要改的是这一台设备、这一个 fabric、按这一套内部规范。 它的方案往往看起来极其专业，却建立在它自己想象出来的事实上------MTU 早就改过了、PFC 早就开了、那个固件版本不在批准清单里。
所以第三次迁移能否成立，取决于一个看起来是技术、实则是治理的问题：如何降低 AI"用想象填补事实"的风险，以及如何约束它输出的东西。
这里必须先划清一条界线，它是本文与许多"AI + 网络"论述最大的分歧点：检索（RAG）能降低信息缺失的风险，但它本身不是安全边界。 模型仍可能忽略检索到的内容、误读证据、错误拼接多个来源，甚至生成检索结果里根本不存在的字段------即使每个字段都带了引用，也不代表那条引用真正支持该字段的值。
真正限制它的是检索之外的六道闸门：结构化输出约束、实体与策略白名单、字段级证据校验、确定性编译、独立验证器、最小权限的执行控制（6.7 详述）。我们不追求让 AI 更自由，我们追求让它的自由有边界------而边界不在提示词里，在它下游的那几道闸门上。
〇·五、阅读须知：本文的三类陈述
这篇文章混合了三种性质不同的陈述，混读会导致误判，先做区分：
| 类型 | 包括什么 | 应如何对待 |
|---|---|---|
| 有技术依据的事实 | RFC 9315 对意图及意图生命周期的定义；NCCL 对集合通信的语义（All-Reduce 与 All-to-All 是两种不同的操作）；Batfish 等工具的分析范围与限制 | 可查证，文中尽量标注来源与限制 |
| 合理但需限定条件的工程判断 | 大规模同步训练对网络性能高度敏感；RAG 能降低生成方案时的信息缺失风险；自治等级应由风险与验证能力共同决定 | 成立，但依赖前提条件 |
| 作者提出的设计假设 | 七层架构、语料三级权威、覆盖率阈值、自治等级表、"控制权的三次迁移" | 可作为架构建议，不是行业标准，也未被行业验证 |
另外两点需要预先说明：
- 文中的量化数字（MFU 52%→38%、goodput +7%、PFC 1000pps、覆盖率 0.9/0.6、静态分析"秒级"等）都是演示用的示例参数，不是实测数据，也不是可直接复用的阈值。真实取值必须由读者依据自己的硬件、拓扑、作业特征与风险成本校准。
- "SDN → IBN → AI 增强的意图管理"是本文的分析模型，用来组织论述，不是行业已经完成或必然经历的三个历史阶段（详见第十章）。三者可以共存，实际架构也可能是混合形态。
一、先把坐标钉住：AI Infra 是什么，与传统 IT Infra 是什么关系
在谈网络之前，必须先回答这两个问题。因为"意图定义网络"不是一个独立的技术潮流，它是 AI Infra 这套新约束条件推导出的必然结果。
1.1 AI Infra 是什么
AI Infra（AI Infrastructure）不是"能跑 AI 的服务器"，也不是"买了 GPU 的数据中心"。更准确的定义是：
为大规模模型训练与推理而整体设计的、算力---互联---存储---调度四者强耦合的基础设施系统。
它的四层结构大致如下：
┌──────────────────────────────────────────────────────┐
│ 调度与运行时层 │
│ 作业调度 · 拓扑感知放置 · 弹性容错 · 推理网关 · 配额 │
├──────────────────────────────────────────────────────┤
│ 数据与存储层 │
│ 并行文件系统 · 对象存储 · 数据集缓存 · Checkpoint 高频写 │
├──────────────────────────────────────────────────────┤
│ 互联层（本文主角） │
│ 计算网络（IB / RoCEv2）· 存储网络 · 前端业务网络 │
├──────────────────────────────────────────────────────┤
│ 算力层 │
│ GPU/NPU · 高速显存 · 液冷 · 高密机柜 · 供电与散热 │
└──────────────────────────────────────────────────────┘四层缺一不可，而且层与层之间的耦合强度远超传统 IT 。举一个用于说明耦合强度的量级示例（数值为假设，非实测 ）：一个 1024 卡的训练作业，如果某台机器的网卡因为光模块衰减导致 0.1% 的丢包，这不会让作业失败------但它会让集合通信的同步等待被最慢的那条链路拖住，MFU（模型算力利用率）可能从 52% 掉到 38%。算力没有坏，网络没有断，但钱在烧。 这种故障形态在传统 IT Infra 的评价体系里几乎不可见。
1.2 AI Infra 与传统 IT Infra 的关系
最常见的误读是把它当成"新一代替代品"。真实关系更接近同一套工程体系在不同约束下的重新配平 ：虚拟化、编排、可观测性、权限模型这些骨架被继承下来了，但优化的目标函数换了。
下面的对比描述的是两种典型场景 ：大规模同步训练集群，与传统企业级 IT 系统。现实中两者都有大量例外------高成熟度的互联网业务同样具备高频自动变更能力，AI 集群的管理网与存储网也仍以传统形态为主。对比的目的是说明约束条件的整体偏移方向，不是给出非此即彼的分类。
| 维度 | 传统 IT Infra | AI Infra | 后果 |
|---|---|---|---|
| 服务对象 | 人发起的请求（Web、数据库、办公） | 机器之间的同步（梯度、参数、KV Cache） | 流量方向从南北向变为东西向 |
| 流量特征 | 突发、可缓存、可重试 | 持续、带宽饱和、对尾延迟极敏感 | 拥塞控制策略完全不同 |
| 核心指标 | 可用性（99.9%）、P99 延迟 | 有效算力利用率、作业完成时间（JCT）、goodput | "没坏"不等于"合格" |
| 故障影响 | 一台机器宕 → 流量切走 | 一台机器慢 → 整个作业等它（straggler） | 单点性能退化成全局问题 |
| 变更节奏 | 季度级、窗口化（典型） | 任务级、天级（目标场景中的运营假设） | 人工审批流程难以维持控制力 |
| 扩容单位 | 单台服务器 | 一个 Pod / 一个 rail / 一整列机柜 | 容量规划粒度变粗，爆炸半径变大 |
| 主要成本 | 硬件折旧 + 人力 | 硬件折旧 + 闲置算力（最贵的浪费） | 优化目标从"省人"变成"省卡时" |
| 失败代价 | 服务降级、可回滚 | 训练中断、回滚到上一个 checkpoint、数天算力沉没 | 不可逆性显著上升 |
一句话概括这层关系：
AI Infra 不是传统 IT Infra 的升级版，而是把它的约束条件整体更换了一遍。 同样的一套工程方法，面对的是完全不同的时间常数、故障形态和成本结构。
1.3 一个被低估的推论：网络从"配套设施"变成了"算力的一部分"
在许多传统企业 IT 场景里，网络常被当作共享基础设施，业务团队更关注应用可用性；但大型互联网、金融和电信网络早已将网络性能作为一等指标。在 AI Infra 里，网络直接出现在性能公式里：
有效算力 ≈ 峰值算力 × 并行效率
并行效率 ≈ f(计算/通信比, 网络带宽, 尾延迟, 拥塞程度, 拓扑匹配度)这意味着网络配置的一次次优选择，可能以额外卡时、延长作业完成时间（JCT）或降低 MFU 的形式反映到成本上。具体损失必须通过同一作业、同一并行策略和可比负载下的基准测试量化，不能脱离环境给出统一百分比。网络不再只是"支撑系统"，而是影响有效算力利用率的重要组成部分。
这就是为什么本文要谈网络。在所有基础设施门类里，AI Infra 对网络的压迫最直接，也最先暴露出"人工控制"的物理极限。
二、SDN：把控制权从设备里拿出来
2.1 前史：分布式控制的成就与天花板
在 SDN 之前，网络是一个分布式自治系统 。每台设备运行自己的控制平面：交换机跑 STP 破环，路由器跑 OSPF/IS-IS 算最短路径，边界跑 BGP 交换可达性。全局的最优行为不是被"设计"出来的，而是从一堆局部规则和邻居协商中涌现出来的。
这套设计极其成功------分布式路由与控制协议支撑了互联网长期的规模扩张；它的重要优势包括没有单一全局控制器作为唯一决策点，并允许在一定范围内局部部署与演进。具体协议仍可能存在选举、收敛与故障域等限制。但它有三个结构性天花板：
- 业务意图视图缺失。 传统分布式控制协议负责交换可达性与计算路径，通常并不提供统一的、面向业务意图的全网视图：一台设备掌握的是自己的链路状态数据库，而不是"从 A 到 B 在当前策略下是否被允许"。你问这个问题，答案要靠人手工拼。（需要说明的是，现代网络已经可以通过遥测与分析系统在协议之外建立全局视图，但那是后来叠加的能力，不是分布式协议本身提供的。）
- 策略表达力贫乏。 协议能表达"最短路径""本地优先级""MED"，但表达不了"财务系统的流量不得经过任何境外节点"这种业务级约束。
- 变更靠经验。 加一条链路、改一个 metric，影响面要靠在脑袋里推演，或者等出事了再回滚。
2.2 SDN 的三个命题
2008 年前后，Stanford 的 OpenFlow 工作把这三个天花板一次性摆到了台面上。SDN 的原始命题可以拆成三条：
| 命题 | 内容 | 本质 |
|---|---|---|
| 分离 | 控制平面与数据平面解耦，设备退化为可编程的转发件 | 让"决策"和"执行"可以独立演进 |
| 集中 | 控制器持有全局拓扑与状态视图 | 把"涌现"换成"计算" |
| 开放 | 提供标准化的南向接口（OpenFlow、P4、NETCONF/gNMI） | 让网络可被软件工程化 |
需要说明：这三条是本文对 SDN 的概念归纳，不是某个标准给出的统一定义。现实中的实现形态远比它丰富------分布式控制器、混合控制架构（控制逻辑部分集中、部分保留在设备上）、以及完全不采用集中控制器的自动化方案都广泛存在。
在这三条里，传播得最彻底的是第一条。后面的历史证明了这一点：OpenFlow 作为协议并未成为所有场景的主流南向接口（流表容量、匹配字段僵化、芯片支持滞后都是原因），但"控制与转发分离"这个思想渗透进了几乎所有现代网络------云厂商的 VPC、运营商的 SRv6 骨干、数据中心里的 EVPN 控制平面，底层都是这个思想。
2.3 历史的分岔：OpenFlow 未成主流南向接口，Overlay 广泛应用
这里不做"技术路线已经定型"的判断------今天仍有 P4、可编程交换芯片、SD-WAN 控制器等大量不同形态并存。更准确的说法是：在数据中心网络这个具体战场上，大面积落地的不是 OpenFlow，而是两条更务实的路线：
- Overlay 路线 ：VXLAN + BGP EVPN。物理网络保持简单（IP 可达即可），把租户隔离、多播、策略全部塞进隧道封装里。控制平面用 BGP 而不是自定义协议------用已有的、经过三十年考验的协议承载新的抽象。
- 广域网路线 ：Google B4（2013 年 SIGCOMM 论文）与 Microsoft SWAN（2015）。它们把跨数据中心的流量工程交给集中式或逻辑集中式控制系统，结合应用需求与链路状态分配带宽。B4 论文报告，其流量工程系统能将链路利用率推向接近满载，同时在应用优先级与需求之间进行权衡。这是特定受控广域网场景的论文结论，不能泛化为所有网络采用 SDN 后都能达到相同利用率；其效果依赖流量可调度性、边缘流量测量、优先级策略与故障处理机制。
这两条路线的共同点值得注意：它们都没有追求"用一个控制器接管整个网络"，而是选择了"在受控范围内做集中优化"。 这是工程理性的胜利，也是后来 IBN 反复踩坑时应该回看的教训。
2.4 SDN 到底解决了什么
以下是常见形态的对照，不代表所有网络都严格经历了从左到右的演进：
| 问题 | 传统设备管理形态 | 典型 SDN / 自动化形态 |
|---|---|---|
| 配置方式 | 传统设备环境常见逐台 CLI 与脚本 | 典型控制器/自动化平台可统一编排、模板化下发 |
| 全局视图 | 依赖协议状态、设备命令与外部工具拼接 | 可通过控制器、遥测与分析系统建立较统一的视图 |
| 变更速度 | 取决于规模、流程与自动化成熟度 | 可脚本化或流水线化，但不保证固定速度 |
| 多租户隔离 | 可能依赖 VLAN 与人工规划 | 可结合 Overlay、策略与自动化分配 |
| 排障 | 常通过设备命令逐跳排查 | 可集中采集流表、配置与遥测 |
| 可测试性 | 常以人工 review 为主 | 可做配置 diff、仿真、回放或自动化测试 |
2.5 SDN 的未完成：它换掉了 CLI，没换掉"人脑做翻译"
这是全文最重要的一个判断，值得单独强调：
SDN 把"手工敲命令"变成了"手工写策略"，抽象层级只上升了一级，翻译工作仍然在人脑里完成。
具体来说，SDN 之后依然存在的四个断层：
- 意图仍是配置级的。 工程师写的是"deny tcp any any eq 445"，而不是"这个业务不允许被办公网访问"。前者是手段，后者才是目的。当业务变化时，前者需要人重新翻译一遍。
- 策略可能停留在静态配置层。 在缺少持续保障能力的实现中，控制器下发后，网络是否仍符合目标取决于是否另有遥测、策略检查与告警机制。现代 SDN 平台也可以集成持续监控与闭环能力，因此这不是 SDN 的固有限制。
- 验证依赖人。 "这条 ACL 会不会误伤另一个业务"这个问题，答案通常是"我看着应该不会"。近年出现的 Batfish、NetKAT、Minesweeper 等工具试图用形式化方法回答它，但普及度远低于其价值。
- 跨域协同缺失。 计算、存储、网络各自有控制器，谁也不理解对方的意图。一个训练作业要"拓扑感知放置"，需要调度器和网络控制器互相解释自己------而它们说的是两种语言。
SDN 给了网络一副可编程的肌肉，但没有给它一套会自我校正的神经。 这正是 IBN 要补的那一块。
三、IBN：第二次抽象，从"配置"到"结果"
3.1 定义与那个闭环
意图定义网络（Intent-Based Networking, IBN）在 IETF/IRTF 有一份被广泛引用的概念文档（RFC 9315，2022 年，IRTF NMRG）。需要说明它的性质：这是一份 Informational 文档 ，提供的是概念框架与术语定义 ------它对意图、意图履行（fulfillment）与保障（assurance）给出了定义与生命周期描述，但并不对本文这套 AI + RAG 架构做任何标准化背书。
RFC 9315 将意图描述为对期望网络行为的声明，并讨论意图履行、保障及生命周期相关功能。下图是本文对这些功能的四段式归纳，用于工程设计，不是 RFC 原文规定的固定四阶段流程：
① 意图表达（Compose）
业务目标 + 约束，用什么手段实现不关心
↓
② 翻译与验证（Translate & Validate）
转成策略/配置候选 → 在模型或孪生环境里预演 → 检查是否违反硬约束
↓
③ 下发与编排（Activate / Deploy）
分批、灰度、按依赖顺序下发；失败即停
↓
④ 保障与优化（Assure / Observe-Analyze-Act）
持续遥测 → 与意图比对 → 偏离则纠正或上报
↺ 回到 ①（意图可能因业务变化而更新）这个闭环里，真正区别于 SDN 的是 ②的"验证"和④的"保障"。SDN 控制器也可能具备验证、监控与回滚能力；这里要比较的不是 SDN 技术本身，而是仅有配置下发、没有意图级验收与持续保障的实现形态。
3.2 与 SDN 的关系：肌肉与神经
| SDN | IBN | |
|---|---|---|
| 抽象对象 | 转发行为 | 业务结果 |
| 输入 | 拓扑、流表、策略规则 | 目标、约束、SLA |
| 正确性判据 | 配置是否下发成功 | 业务是否达到预期，且没有附带伤害 |
| 时间尺度 | 变更时 | 全生命周期 |
| 失败处理 | 回滚配置 | 检测偏离、重新规划、必要时上报 |
| 实现基础 | 可编程的数据面与自动化接口（常见路径，但非唯一） | 不要求特定的控制器架构；关键条件是状态可见性、策略表达能力、可控执行接口与可验证的反馈闭环 |
一句话：SDN 解决"能不能改"，IBN 解决"该不该改、改完对不对"。
需要澄清一个常见误解：IBN 并不严格要求先部署一个集中式 SDN 控制器。 RFC 9315 本身也讨论了意图系统、控制器、网络管理系统等多种实现形态，并未规定唯一的底层架构。传统网络同样可以通过配置管理系统、策略引擎、设备 API、遥测与配置分析工具，获得一部分意图管理能力------只是能力边界会受可见性与执行接口完备程度的限制。
因此二者更接近"常配合"而非"上下级"的关系：IBN 通常借助 SDN 提供的抽象、编程与统一执行能力，但也可以通过多种现有网络管理与自动化系统实现。
3.3 第一代 IBN 的实践与三个失败模式
2017 年前后，主流厂商集体推出过 IBN 产品：Cisco 的 DNA Center（后演化为 Catalyst Center）、Juniper 的 Mist（用 AI 做无线保障）、Arista 的 CloudVision、Apstra 的 AOS（后来被 Juniper 收购）。它们确实做成了一些事：基于遥测的故障定位、配置合规检查、有线无线的自动排障。
不能仅凭产品形态就断言第一代 IBN 整体"没有兑现承诺"；不同产品的目标、能力与成熟度差异很大。以下三条是作者基于公开资料与产品形态提出的风险归纳，不是行业公认的失败分类，也缺少可引用的第三方量化评估；把它们当作"值得警惕的设计倾向"来读，比当作行业定论更合适：
失败模式一：意图目录靠人穷举。
系统要求你从下拉菜单里选一个"意图模板"。这等于把"翻译"这一步从工程师的脑子里，搬到了一个预先枚举的清单里。如果缺少扩展和澄清机制，清单之外的意图就可能无法被表达或只能转人工处理。 这可能退化为"带 UI 的模板库"；不过，模板本身并非缺陷，关键在于系统是否允许受控扩展、持续保障与清晰的未覆盖状态。
失败模式二：保障环路依赖阈值，不依赖推理。
"CPU 超过 80% 告警""丢包率超过 1% 告警"------这是监控，不是保障。意图保障不仅需要阈值告警，还要把观测指标映射到明确的目标和约束，并说明哪些偏离可以自动纠正、哪些只能告警或升级处理。阈值仍然是保障机制的一部分；它的局限在于单独使用阈值不能解释业务意图是否整体满足。
失败模式三：只能管自家域。
一个厂商的控制器只管自己的设备。可真实网络是异构的：IB 交换机、RoCE 以太网、传统核心、云上 VPC、SD-WAN 分支。意图一旦跨域，就退化成一堆工单。
3.4 三级抽象：命令行、配置、意图
把这段历史压缩成一张表，会看得更清楚：
| 层级 | 工程师说什么 | 系统做什么 | 典型形态 | 遗留问题 |
|---|---|---|---|---|
| L1 命令 | interface Gi0/1 / switchport trunk allowed vlan 20 |
忠实执行 | CLI、脚本 | 换环境就失效 |
| L2 配置 | "这条链路 trunk 放行 VLAN 20--30，MTU 9000" | 下发并保持 | SDN 控制器、Terraform、Ansible | 状态漂移无人知，语义仍是手段 |
| L3 意图 | "这个训练作业的 8 个 rail 各自独立，禁止绕行，吞吐不低于基线 95%" | 翻译、验证、下发、持续保障 | IBN + Agent + 遥测闭环 | 意图如何形式化、如何证明 |
注意 L2 到 L3 的跳跃不是"写得更抽象"，而是"判据换了"：L2 的成功判据是"配置生效了"，L3 的成功判据是"业务结果达标了，且没有副作用"。
（此处的 L1--L3 是本章对抽象层级的编号，与第五章架构图的 L1--L8 是两套独立编号，不要混淆。）
四、为什么 AI Infra 把网络自动化推到了能力边界
如果只是传统企业网络，意图化可以慢慢来------毕竟人还能盯得住。但 AI Infra 把四个变量同时改掉了，导致人在一部分反馈回路里已经跟不上事件的节奏。
4.1 流量模型：从南北向到全互联
传统数据中心以南北向为主（客户端 → 负载均衡 → 应用 → 数据库），东西向虽有但通常是有限扇出。在数据并行等大规模同步训练场景中，常见通信操作包括 All-Reduce、All-Gather、Reduce-Scatter 等；模型并行、专家并行和推理场景的通信模式可能不同，不能将所有 AI 网络流量都归结为集合通信。
这里要纠正一个流传很广的误解：
All-Reduce 要求所有参与者获得全局归约结果，这并不等于每张 GPU 都要与其他每张 GPU 建立直接通信。
NCCL 集合通信文档明确区分 All-Reduce 与 All-to-All 两种不同的集合操作；All-Reduce 会把归约结果提供给所有参与 rank，而 All-to-All 才是每个 rank 向各目标 rank 发送不同数据块的语义。All-Reduce 的物理通信由具体实现选择 Ring、Tree 等算法完成。实际的流量模式取决于 NCCL 的算法选择、GPU 与 NIC 的拓扑关系、并行策略（DP/TP/PP/EP 的组合）以及通信库实现，不能从"用了 All-Reduce"直接推出"网络必须是全互联直连"。
不过结论的方向不变：大规模训练仍会产生高强度、同步化、周期性、带宽饱和的东西向流量，并对网络带宽、尾延迟与拥塞控制提出极高要求。由此带来两个后果：
- ECMP 哈希极化（hash polarization）：传统 ECMP 按五元组哈希选路，在少量大象流的场景下极易把多条大流压到同一条链路上，导致"链路总带宽够，但某几条被打爆"。为此才有了 adaptive routing、per-packet spraying、flowlet switching 等机制。
- 对丢包与延迟的高度敏感 ：TCP 靠丢包感知拥塞，而 RoCEv2 部署通常依赖 PFC 与 ECN 的协同来降低丢包（机制见下文）。作为一个可能的故障场景示例 （不是普遍的持续时间或影响程度）：一次 PFC 风暴可以在很短时间内让一个 Pod 的有效吞吐大幅下降，而监控面板上的链路状态一切正常------因为链路没有 down。
关于 PFC 与 ECN，必须先分清流量控制与拥塞控制：
- PFC 是对特定优先级流量的逐跳暂停控制（流量控制）；
- ECN 是拥塞标记，配合端侧拥塞控制算法调节发送速率（拥塞控制）。NVIDIA 的 Cumulus 文档同时记录了 lossless（PFC + ECN）与 lossy（ECN）配置路径；具体支持能力取决于交换机、NIC、驱动与软件版本，不能把某一厂商的配置能力泛化到所有设备。
二者组合是常见的 RoCE 无损以太网部署方式，但并非所有 RoCE 部署都必须启用 PFC------业界也存在主要依赖 ECN 与端侧拥塞控制的 lossy RoCE 配置。更重要的是，PFC 可以缓解特定条件下的丢包风险，同时也会引入队头阻塞、拥塞传播和持续暂停等新风险（厂商通常提供 PFC watchdog 等缓解机制）。
所以："PFC 已开启"不等于"网络无损"，"ECN 已配置"也不等于"拥塞已被正确处理"。 网络是否可靠，取决于端到端 QoS 映射、缓冲区配置、ECN 阈值、拥塞控制算法、故障检测与恢复机制的协同设计。这一点适用于本文后续所有涉及 PFC 的表述------包括 5.4 契约里那条"PFC pause 超过阈值即回滚"，它是一条需要结合本地计数器口径与误报处理来定义的约束，不是通用常数。
4.2 指标：从"可用性"到"有效算力"
传统网络考核的是 uptime 和 P99 延迟；AI Infra 更多考核 MFU、JCT、goodput。以下对比面向典型的大规模同步训练场景：
| 传统指标 | AI Infra 指标 | |
|---|---|---|
| 观测对象 | 链路、设备、请求 | 作业、通信模式、同步等待 |
| 灵敏度 | 断链才报警 | 尾延迟的小幅恶化就可能需要介入（3% 是示例量级，非通用阈值） |
| 归因难度 | 高（但故障明确） | 极高（"慢"可能来自网络、NCCL 参数、拓扑错配、GPU 降频） |
| 可接受误差 | 有余量 | 几乎没有（卡时按秒计费） |
"网络没坏，只是慢了 3%"------这句话在传统运维里可以挂一周没人管；在万卡集群里，它对应的是被闲置的算力。 至于这值多少钱，取决于集群规模、卡时单价与作业时长，这里不给通用数字------任何脱离具体规模与价格的"几百万浪费"都是修辞，不是结论。
4.3 变更节奏：从季度到任务级
传统网络的变更窗口通常是季度级、需要 CAB 审批（这是常见做法，不是唯一形态）。在本文讨论的目标场景中，AI Infra 的变更节奏被假设为：
- 新训练任务进来，需要按拓扑感知重新规划 rail 分配（天级）；
- 某个租户扩容，需要调整 QoS 与 PFC 水位（小时级）；
- 出现 straggler，需要临时隔离某条链路并重路由（分钟级）；
- 推理业务波峰，需要动态调整前端与存储网络带宽配比（分钟级）。
当变更频率超过人工审批的频率，审批就从"控制"退化为"橡皮章"。 这是所有基础设施团队都经历过的异化过程，只是 AI Infra 把它压缩到了几个月内完成。
需要说明的是，上面这组节奏是运营场景假设 ：并非 AI 集群的所有网络配置都需要高频变更------管理网、带外网、安全域边界通常仍然是低频变更；反过来，成熟度很高的传统业务网络也可能具备持续的自动变更能力。这组对比说明的是变更压力的分布发生了偏移，而不是"AI 集群的一切都在分钟级变化"。
4.4 故障形态：从"断"到"慢"到"静默错"
这是最容易被低估的一点。AI Infra 的典型故障谱系是：
- 显性故障：链路 down、端口 err-disable、BGP 邻居翻。传统监控能抓到，反而最好处理。
- 性能故障：光模块衰减、FEC 纠错率上升、MTU 不一致导致分片、PFC 死锁、ECN 阈值错配。表现为"吞吐下降但不告警"。
- 静默数据错误：在极少数配置下（例如校验被卸载、端到端校验覆盖不完整），链路层的少量数据损坏可能未被传输层校验捕获。
需要提醒的是，这是一条可能的故障链，不是常见的直接因果关系 ：链路数据损坏、传输层校验、NIC/驱动行为、训练框架的数值异常之间存在多层环节，把训练侧观察到的 loss 异常或收敛异常直接归因于"网络静默错误"，是一种过早的归因。真正可怕的是它的结构------症状出现在算法层，根因可能在网络层，中间隔着整个软件栈，因此逐层排除的成本极高。
面对这类难以直接观测的故障，"人去看一眼"基本无效。可行的做法是让系统自己持有"这个作业应该跑多快"的意图，并持续比对实测值与该意图的偏离------注意，比对的是可观测指标（goodput、通信耗时、重传与 FEC 计数），而不是直接断言"一定是网络坏了"。
4.5 结论：时间尺度要分层，意图层只负责它该负责的那一层
到这里可以给出一个更谨慎的结论。
部分网络控制事件的时间尺度可达毫秒到秒，而人工分析与审批通常更慢；因此快速控制回路必须由协议、硬件或确定性自动化在机器侧闭合。
这一点没有争议。但由此不能直接推出"所以必须采用 IBN、必须引入 LLM"。这个推论存在一个跳跃，必须补上：
| 时间尺度 | 由谁承担 | 例子 |
|---|---|---|
| 毫秒级 | 确定性协议、硬件与控制算法 | ECN 标记、端侧速率调节、PFC |
| 秒级 | 协议与硬件 | 链路倒换、路由收敛、BFD 触发 |
| 分钟级 | 规则化自动化（不需要 LLM） | 限速、切换、按预设策略回滚 |
| 小时及以上 | 意图管理层 | 目标表达、跨域协调、策略生成与验证、受控变更编排、持续保障 |
也就是说，AI Infra 要求的是不同时间尺度的控制机制分层协同，而不是把所有控制都提升到意图层。毫秒级拥塞控制不应该、也不需要等待 LLM 推理；把每一次快速控制动作都上升为一次"意图变更"，既慢又危险。
那么意图层不可替代的位置到底在哪里？在既有自动化机制无法满足跨域目标与治理要求的地方：
- 一次变更需要同时协调调度器、网络控制器与存储策略；
- "是否成功"不能由命令退出码判定，而必须由业务指标判定；
- 变更需要留下可审计的证据链，回答"谁提的、谁批的、改了什么、怎么证明"。
所以更准确的表述不是"AI Infra 让 IBN 变得生死攸关"，而是：AI Infra 让跨域、可验证、可审计的意图编排变得不可回避。 前者是把一个工程判断说成了历史必然，后者才是能从前提推出的结论。
五、意图定义网络的参考架构
5.1 八层结构
┌─────────────────────────────────────────────────────────────┐
│ L8 意图层 │
│ 自然语言 / 领域 DSL：业务目标、约束、验收标准、自治等级 │
├─────────────────────────────────────────────────────────────┤
│ L7 检索与知识层（RAG） │
│ 事实源（独立采集）· 规范库 · 先例库 · 术语映射 │
│ 定位：证据供给机制 ------ 不是安全边界 │
├─────────────────────────────────────────────────────────────┤
│ L6 意图编译与结构化校验层 │
│ LLM 生成候选 → 结构化输出约束 → 实体/策略白名单 │
│ → 字段级证据校验；未通过者拒绝、降级或转人工 │
├─────────────────────────────────────────────────────────────┤
│ L5 独立验证层（不依赖模型输出） │
│ 语法与模型校验 · 网络行为分析 · 仿真孪生 · 灰度实测 │
│ 必须记录：覆盖范围、未建模行为、数据新鲜度、模型假设 │
├─────────────────────────────────────────────────────────────┤
│ L4 策略与编排层 │
│ 策略引擎 · 工作流 · 多域协调（调度器 / 网络 / 存储） │
├─────────────────────────────────────────────────────────────┤
│ L3 执行安全控制层 ◆ 独立成层 │
│ 最小权限 · 范围与速率限制 · 分批 · 幂等 · 熔断 │
│ · 回滚演练 · 审计记录 │
├─────────────────────────────────────────────────────────────┤
│ L2 执行层（SDN 的遗产） │
│ 控制器 · NETCONF/gNMI · P4 · Terraform/Ansible · 设备 API │
├─────────────────────────────────────────────────────────────┤
│ L1 数据面与遥测层 │
│ 转发芯片 · INT（带内遥测）· gNMI streaming · eBPF · sFlow │
│ 这一层决定"你能验证什么"，是整套体系的地基 │
└─────────────────────────────────────────────────────────────┘相比常见的分层，这里做了两处调整：
- 在意图层与执行层之间插入 L7 检索与知识层，位置在生成之前------先检索、再生成，AI 的假设空间从一开始就被限制在企业真实拥有的实体、策略和先例之内。
- 把原来合在一起的"编译与验证"拆成 L6 与 L5，并把 L3 执行安全控制独立成层。 原因是：编译属于"生成侧"，验证必须站在模型输出之外，执行安全则是与二者都不同的第三类职责------它关心的是"万一前面都错了，后果能不能被限制住"。第六章会给出这两处调整的完整理由。
5.2 每一层的职责与典型失败模式
| 层 | 职责 | 典型失败模式 | 症状 |
|---|---|---|---|
| L8 意图 | 表达业务目标与边界 | 意图不可测量（"网络要稳定"） | 系统无法判断是否达成 |
| L7 检索知识 | 提供事实线索、规范与先例，缩小模型的假设空间 | 召回漏检、语料过期、错误先例被复用 | 错误方案"看起来有出处" |
| L6 编译与结构化校验 | 把意图变成候选契约，并强制 schema、白名单与证据校验 | 校验规则覆盖不全，模型输出绕过结构约束 | 契约格式合规但语义错误 |
| L5 独立验证 | 在明确建模的范围内给出验证证据 | 把"模型内验证"当成"真实环境验证" | 分析通过、现网翻车 |
| L4 策略编排 | 权限、顺序、依赖、跨域 | 策略冲突、环路依赖 | 变更卡住或部分生效 |
| L3 执行安全控制 | 最小权限、范围与速率限制、幂等、熔断、回滚演练、审计 | 只做了权限，没做速率限制与回滚演练 | 一次误操作扩散到整个 fabric |
| L2 执行 | 实际下发配置 | 部分失败、幂等性缺失 | 配置漂移、半成品状态 |
| L1 数据面与遥测 | 提供事实 | 采样率不足、时钟不同步 | 验证结论不可信 |
这张表最值得看的是首尾两行，以及新增的 L3。
- 整个体系的可靠性上限由 L1 决定：如果遥测只能看到 1% 的采样、时间戳偏差 200ms，上面七层再精巧，验证的也只是一个近似世界。
- L7 决定的是"AI 的假设空间有多大"，但它只提供线索。 语料再完整，也不能替代 L6 的输出约束与 L3 的执行控制------只有当 L6 的 schema、白名单和证据检查由运行时强制执行时，它们才能限制输出；真正限制后果的是 L3 的执行安全控制。
5.3 一条铁律：检索在前面，LLM 在两端，约束与验证在中间
这是本文对"AI + 网络"最核心的工程主张：
自然语言意图
──► [L7 检索：事实 / 规范 / 先例] 提供线索，不提供保证
▼
──► [LLM：在检索结果之内理解、澄清、补全] ──► 候选契约（逐字段带 source_id）
│
[L6 结构化校验：schema + 白名单 + 证据校验]
│ 未通过 → 拒绝 / 降级 / 转人工
▼
[确定性编译器] ──► [L5 独立验证器]
│ 并记录覆盖范围与假设
▼
[L3 执行安全控制：最小权限·限速·分批·熔断·回滚]
│
▼
[L2 分批执行器]
异常解释 / 归因假设 / 变更摘要 ◄──[LLM：在遥测事实之内做解释]── 遥测事实
❌ 反模式
LLM ──凭参数记忆直接生成 CLI──► 生产设备
把"检索到了规范"当成"已经遵守了规范"，是同一类错误的另一种形态理由很朴素：LLM 可以辅助把模糊表达整理成候选的明确表述，但不能单独保证一个全局约束在所有设备和运行状态下都成立。 前者是语言问题，后者是组合爆炸问题。
但必须补上一个关键限定，否则这条主张会被误读成"只要先检索就安全了"：
RAG 是证据供给机制，不是安全执行机制；引用是证据线索，不是正确性证明。
模型仍可能忽略检索到的内容、误读证据、错误拼接多个来源，甚至生成检索结果里根本不存在的字段。所以完整的链条是三段，缺一不可：
- 检索缩小假设空间（L7）；
- 结构化校验与白名单限制输出（L6）；
- 独立验证与执行安全控制限制后果（L5、L3）。
少了第一段，模型在黑暗里想象；少了后两段，模型带着引用犯错------后者更危险，因为它看起来经过了验证。
所以正确的姿势是：先检索、后生成；LLM 负责"翻译意图"与"解释事实"；中间的编译、验证、执行全部交给确定性程序；执行之前再过一道独立的执行安全控制。 检索这一手，是让 LLM 的创造力从"任意发挥"变成"在给定的零件库里组装"------但需要强调，这个比喻描述的是概率上的收敛，不是机制上的保证：模型依然有能力造出库里没有的零件，拦住它的是 L6 的白名单，不是检索本身。
这也解释了为什么"AI 网络"这个词经常被误用------真正的 AI 不是在转发面上跑模型，而是在意图层做人机接口、在检索层做知识对齐、在保障层做归因推理。
5.4 网络意图契约样例
把 5.3 的结构落成一份可 review 的文件，大概长这样。这是说明设计思路的伪契约，不是可直接执行的标准 API，也不是已经通过某个 YAML schema 校验的规范文件；落地时需要定义正式 schema、字段语义、数据源适配器和策略执行器。结构与其他意图契约可以保持相似，但不能只靠字段命名保证行为。
apiVersion: intent.network/v1
kind: NetworkIntent
metadata:
id: "net-intent-2026-1019-train-tenant-b"
owner: "ai-platform-team"
risk_level: high
autonomy: A2 # 受控执行，关键步骤人工审批
created: 2026-10-19T09:00:00+08:00
# ── L7 检索与知识层：先划定 AI 能看什么、必须引什么，再谈目标 ──
knowledge:
# 事实源独立于知识库：CMDB、实时遥测、设备配置、拓扑发现各自保留
# 数据来源、时间戳与权威性；RAG 只做检索与关联，不替代实时采集与一致性检查
fact_sources_separate: true
corpora:
- id: "topology-facts"
source: "cmdb://fabric/dc-gpu-01 + gnmi://*/lldp"
freshness_sla: "<= 5 min" # 活的事实源：拓扑、端口、光功率
authority: authoritative # 权威数据源候选；仍须校验时间戳、采集状态与冲突
- id: "net-policy"
source: "docs://net/policy/*.md"
freshness_sla: "<= 30 day" # 规范库：慢变，但必须有效
authority: normative # 规范，必须遵守
- id: "change-history"
source: "itsm://changes/fabric?window=24m"
freshness_sla: "<= 24 h"
authority: precedent # 先例：可参考，不可照抄
- id: "incident-library"
source: "itsm://incidents/sev>=2?fabric=dc-gpu-01"
freshness_sla: "<= 24 h"
authority: precedent
denied_corpora: # 声明检索范围；必须由数据访问层强制执行
- "docs://security/zones/*" # 安全域拓扑不对本意图开放
- "itsm://incidents/*/pii"
generation_rules:
retrieve_before_generate: true # 期望流程；必须由编排/工具层强制，而非只靠提示词
citation_required: true # 关键事实/约束字段须带来源或明确标注为推导值
min_coverage: 0.9 # 示例阈值；不能替代逐项硬约束门禁
on_low_coverage: "apply_per_constraint_gate_and_autonomy_policy" # 由逐项门禁与风险策略决定降级
unknown_entity_policy: "ask_human" # 检索不到就问，不许猜
forbid_invention:
- "不得生成语料中不存在的 VLAN / rail / 队列 / ACL 名称"
- "不得引用未收录的厂商命令、参数或版本号"
- "不得把历史先例当作组织规范使用"
goal:
statement: >
为训练作业 train-llm-70b-phase2 开通跨 8 个 rail 的无损网络，
保证 all-reduce 有效带宽不低于基准的 95%，
且不得改变现有租户 tenant-a 与 tenant-c 的可达性关系；tenant-b 是本次目标租户，需按批准的变更计划新增或调整其网络策略。
business_objective: "评估网络优化对 1024 卡作业 MFU 的影响；38%→52% 仅为待验证的示例目标，不构成网络单独可保证的收益"
success_definition: "72 小时 goodput ≥ 基线 95%，且不存在违反已批准 rail 隔离策略的跨域路径"
context:
fabric: "dc-gpu-01"
topology: "two-tier rail-optimized, 8 rail, 400G RoCEv2"
current_state:
tenants: 3
peak_utilization: "62%"
pfc_baseline_pps: 120
data_sources:
- "gnmi://*/interfaces/state" # 端口与队列计数
- "telemetry://int/fabric" # 带内遥测
- "scheduler://jobs/train-llm-70b-phase2"
scope: # 适用对象：契约必须明确"改谁的、不改谁的"
applies_to:
- "fabric=dc-gpu-01, tenant=tenant-b, rail=0..7"
explicitly_out_of_scope:
- "tenant-a 与 tenant-c 的任何对象；tenant-b 中未列入 applies_to 的对象"
- "spine 的 BGP 与全局 QoS 参数"
allowed_exceptions: # 允许的例外必须预先登记，不得由 AI 现场发明
- id: "E1"
condition: "某 leaf 端口光功率超限时，可申请更换光模块后继续"
requires: "infra-lead 书面批准 + 证据留档"
timeouts: # 超时策略：不做无期限的等待
precondition_wait: "30m"
per_batch_execution: "15m"
verification_window: "72h"
on_timeout: "stop_and_report"
output_contract: # 真正的约束在这里，不在提示词里
schema: "intent.network/v1#NetworkIntent"
strict: true # 由运行时校验器强制拒绝 schema 之外的字段；声明本身不产生强制效果
entity_whitelist: # 实体白名单：只能引用检索到的对象
- "topology-facts://leaf-*"
- "topology-facts://rail-*"
policy_whitelist:
- "net-policy://L22,L31,L42,L57,L64,L88,L103"
evidence_check: "每个事实/约束字段的 source_id 必须可解析；推导字段须记录输入来源与确定性推导规则"
on_violation:
unknown_entity: "reject_field_and_ask"
unverified_field: "block_from_execution"
missing_citation: "downgrade_to_A0"
target_state:
connectivity:
rule: "GPU 的 rail-j 仅进入 rail-j 对应的转发域；不得经由其他 rail 的 leaf 或策略域绕行。若架构路径需要 spine，必须满足批准的 rail 隔离策略。"
qos:
lossless_queue: 3
pfc_threshold: "依据端口速率、线缆长度、端侧反应时间、缓冲区与设备实现按批准公式计算"
ecn_mark: "由规范与基准测试确定；40% 仅为示例值，不得直接作为生产配置"
performance:
per_node_goodput: "按约定的 NCCL benchmark、并行策略与节点网卡配置定义；380 Gbps 仅为示例值"
job_goodput: ">= 基线 95%"
constraints:
hard: # 每条硬约束都必须能溯源到语料
- id: "C1"
rule: "不得修改任何 spine 的 BGP 配置"
src: "net-policy#L42"
- id: "C2"
rule: "不得修改 tenant-a 与 tenant-c 的 ACL 与 QoS 映射；tenant-b 仅允许修改 applies_to 明确列出的对象"
src: "net-policy#L57"
- id: "C3"
rule: "指定监测点的 PFC pause 计数按批准的口径连续 30 秒超过阈值时，停止后续批次并按预案评估回滚"
src: "net-policy#L88 + incident-library#INC-2025-0712"
- id: "C4"
rule: "变更窗口内同时下线的 leaf 不超过 1 台"
src: "net-policy#L31"
soft:
- "变更窗口 ≤ 90 分钟"
- "配置 diff 行数 ≤ 200（超出需二次评审）"
# 由历史先例提出的建议，不属于硬约束；审批后才可转入正式约束集
proposed_recommendations:
- id: "R1"
rule: "建议变更前后采集目标范围内的 FEC/CRC 基线用于对比"
src: "change-history#CHG-2026-0431（同类变更的既有做法）"
origin: precedent_suggested
status: pending_human_review
capabilities:
allowed:
- "netconf://leaf-*/interfaces/*"
- "controller://fabric/tenant/tenant-b/*"
- "gnmi://*/telemetry (read)"
denied:
- "cli://*/reload"
- "netconf://spine-*/bgp/*"
- "controller://fabric/global/*"
preconditions:
- id: P1
check: "目标 leaf 端口收光功率在 -3 dBm ~ -9 dBm 区间"
on_fail: abort
- id: P2
check: "数字孪生预演通过，diff 仅落在 tenant-b 命名空间内"
evidence: "twin_diff_report.json"
on_fail: abort
- id: P3
check: "当前无进行中的 fabric 级变更"
on_fail: wait
verification:
independent_of_executor: true
checks:
- id: V1 # 负向测试：不该通的必须不通
method: "reachability_matrix"
expect: "tenant-a 与 tenant-c 的可达性矩阵逐项不变；tenant-b 中未列入 applies_to 的对象保持不变"
- id: V2
method: "next_hop_trace"
expect: "路径不经过其他 rail 的 leaf 或策略域；若设计路径经过 spine，必须满足已批准的 rail 隔离策略"
- id: V3
method: "nccl_benchmark"
expect: "在事先固定的 NCCL 版本、并行策略、GPU/NIC 映射与测试参数下，busbw 达到批准的基线目标；380 Gbps/node 仅为示例值"
- id: V4
method: "72h_goodput_window"
expect: "job_goodput ≥ baseline × 0.95"
evidence:
- "配置前后完整快照与 diff"
- "孪生预演报告（含被拒绝的候选方案）"
- "PFC/ECN 计数基线对比曲线"
- "NCCL 基准测试原始日志"
measurement: # 验收必须能承受测量误差，否则阈值只是装饰
pfc_rollback_rule:
counter: "interface.pfc_pause_rx_rate"
sampling_interval: "1s"
duration: "连续 30s 超过阈值" # 避免单采样点误报触发回滚
threshold: "1000 pps（示例值，需按本地计数器口径校准）"
on_false_positive: "记录并复核，不自动扩大回滚范围"
goodput_baseline:
window: "变更前后各 24h，且处于同一负载区间"
load_condition: "作业规模与并行策略一致"
statistic: "P50，剔除已知维护窗口与异常样本"
confidence: "样本量 ≥ 30；不足时不判定达标/不达标，只报告"
gates: # 逐项门禁：关键约束未确认即阻断，不看平均分
mode: "per_constraint" # 而不是 average_coverage
blocking:
- "C1（spine BGP 保护）已确认"
- "C2（租户隔离不被影响）已确认"
- "回滚路径已演练且当前可用"
- "负向测试已定义且可执行"
note: >
即使整体检索覆盖率达到 99%，只要有一条 blocking 项未确认，
仍不得执行任何高风险操作。覆盖率是参考指标，门禁才是放行条件。
failure_policy:
on_precondition_fail: "stop_and_report"
on_verification_fail: "rollback_to: commit-20261019-0930"
escalation: "page network-oncall + ai-platform-lead"
never: # 负向清单优先从事故库检索生成
- rule: "在 PFC 计数持续增长时继续扩容"
src: "incident-library#INC-2025-0712"
- rule: "跳过负向测试直接进入验收"
src: "net-policy#L64"
- rule: "用'我先试一下，不行再改回来'处理核心设备"
src: "incident-library#INC-2024-1180"这份契约里有几处值得停下来看：
knowledge.generation_rules是整份契约的收敛器。retrieve_before_generate堵住了"先想后查"，min_coverage+on_low_coverage让"查不到"变成一个明确的降级动作而不是一次蒙，unknown_entity_policy: ask_human规定检索不到时必须问人而不是猜------这三条只有在由编排器、检索服务和执行门禁实际强制时，才能构成有效控制；把它们写在配置或提示词里本身并不会自动阻止模型违规。knowledge.denied_corpora声明了检索范围，但声明本身不是访问控制。 多数人只管 AI 能执行什么（capabilities），忘了管它能知道什么。一个能读到全量安全域拓扑的 Agent，即使没有写权限，也可能泄露敏感信息。检索服务和底层数据源必须强制执行身份、租户、用途与字段级权限；提示词里的排除清单不能替代访问控制。R1展示了从历史先例中提出补充检查建议的价值；但先例不能自动升级为硬约束。该建议必须经工程师确认、补充适用范围和验证方法后，才能进入正式约束集。src字段让每一条约束都可溯源、可 review。评审者看到的不是"AI 觉得应该这样"，而是"这条来自 net-policy 第 88 行，以及 2025 年那次 PFC 事故报告"。verification的第一项是负向测试：证明"该通的通了"只完成一半，证明"不该通的不通"才是另一半------而后者往往是事故的来源。
新增的 output_contract、gates、measurement 三段分别回应三个常见问题：模型绕过结构输出（strict + 白名单）、"平均覆盖率达标就放行"（gates.mode: per_constraint）、以及阈值无法落地（计数器口径、持续时间与误报处理）。没有这三段，契约就只是一份格式整齐的自然语言。
还有两点与检索有关：
capabilities.denied显式禁止碰 spine 的 BGP。在网络里，最重要的不是你能改什么，而是你被结构性禁止改什么。 因为网络的故障域是全局的。constraints里的每一条都必须是可机器判定 的------不能判定的约束不是约束，是祝福。RAG 在这里有个副作用值得一提：它让"不可判定"变得可见。如果一条约束在语料里找不到对应的检查方法，它就不该写进契约，而应退回给工程师重写。
六、用 RAG 限定意图的解空间：让 AI 在天马行空之前先落地
第五章留下了最关键的一个问题没有回答：凭什么相信 LLM 翻译出来的意图契约？
答案不在提示词技巧里，而在它读到了什么。一个模型无论多聪明，它脑子里装的都是"一般意义上的网络"；而你要改的是这一台 leaf、这一个 fabric、按这一套内部规范 。模型缺的不是推理能力，是本地事实。 检索增强生成（RAG）在意图工程里的价值，因此也就不是"让 AI 知道得更多"，而是------
显著缩小 AI 的生成空间，把它收敛到"这个组织真实拥有、真实允许、真实做过"的范围附近。
注意这里用的是"收敛"而不是"限定"：检索能大幅降低信息缺失带来的风险，但它无法从机制上禁止模型生成检索结果之外的内容。 这一点会在 6.7 展开------它是本章最重要的限定。
6.1 先看清敌人：AI 在哪些地方"天马行空"
把意图翻译阶段的失败归个类，会发现它们高度集中在四种漂移上：
| 漂移类型 | 表现 | 网络里的具体后果 |
|---|---|---|
| 实体漂移 | 把业务名词映射到错误或不存在的资产 | 改了同名的另一台 leaf；引用了 fabric 里根本不存在的 rail 3 |
| 策略漂移 | 用"业界最佳实践"顶替本组织规范 | 套用通用 PFC headroom，与本 fabric 的光纤长度和 buffer 不匹配 |
| 约束漂移 | 漏掉工程师没说、但组织明文规定的约束 | 忘了变更前后采基线、忘了通知相邻租户、忘了避开变更窗口 |
| 度量漂移 | 给出看起来合理但无法测量的验收标准 | "性能有明显改善""延迟处于可接受水平" |
这四类漂移的共同根因只有一句话：模型的训练分布不等于这个环境的事实分布。 模型不知道你机房里那台设备叫什么、组织的阈值定的是多少、上次那次 PFC 事故是怎么收场的。它只能用"一般情况"填补这些空白------而网络恰恰是最不容许"一般情况"的领域，因为一般情况在别处是近似，在网络里是配置错误。
6.2 三类语料，三种权威等级
给 AI 接上检索之前，必须先给语料分级。不加区分地把所有文档塞进同一个向量库，是 RAG 落地最常见的败因。
| 语料 | 内容 | 回答的问题 | 鲜度要求 | 权威等级 |
|---|---|---|---|---|
| 事实语料 Fact | CMDB、拓扑、LLDP 邻居、端口状态、光功率、ACL 现状、遥测基线 | "现在实际是什么样？" | 分钟级 | 权威：可直接作为依据 |
| 规范语料 Norm | 组织网络策略、变更规范、命名约定、安全基线、批准的软件版本清单 | "允许什么、禁止什么？" | 天/版本级 | 规范：必须遵守 |
| 经验语料 Precedent | 历史变更单、事故报告、复盘结论、评审意见 | "以前怎么做的、踩过什么坑？" | 天级 | 参考：可参考，不可照抄 |
三个等级里，最容易被搞混的是后两个。
把先例当规范用，是 RAG 系统最常见、也最危险的错误。
因为先例里通常既有成功经验也有权宜之计。AI 检索到"上次张三这么做没出事"，就会把它当成通行做法写进契约------而那次可能只是运气好，或者那次的环境与这次不同。规范语料必须支持逐条引用（精确到条款号），先例语料只能以"候选 + 出处 + 差异说明"的形式出现。
涉及当前运行状态的事实，应优先从经过校验的配置快照、设备 API、控制器状态与遥测等权威数据源获取，而不能仅凭文档推断。实时数据也可能存在采样延迟、采集故障或语义差异，因此仍需记录来源、时间戳、采集状态，并在关键变更前交叉核验。写进 Wiki 的"MTU=9000"与 gNMI 读出的 1500 冲突时，系统应报告冲突并按预先定义的数据权威规则处理，而不是不加条件地信任任一来源。
6.3 四个限定动作
RAG 到底在哪几个环节收窄 AI 的自由度？可以拆成四个动作：
| 动作 | 输入 | 做什么 | 产出 | 失败时的行为 |
|---|---|---|---|---|
| 消歧 Disambiguate | 意图中的名词 + 事实语料 | 把"训练网络""rail 3"映射到唯一实体 ID | 实体绑定表 | 多命中或无命中 → 反问工程师，不允许默认选择 |
| 补全 Complete | 规范语料 + 同类先例 | 补上工程师没说但组织规定的约束 | 新增约束（标 origin: auto_completed） |
补出的约束必须逐条 review |
| 溯源 Cite | 生成结果 + 检索片段 | 每个事实与约束字段挂 source_id，用户输入、遥测值与推导字段分别标记来源类型 |
可 review 的出处链 | 无出处字段 → 标 unverified，不得进入执行 |
| 收敛 Constrain | 策略模板 + 命名实体 + 历史做法 | 把候选方案的可用零件限制在检索到的实体与策略范围内 | 有限候选集（通常 1--3 个） | 组合空间为空 → 上报"无可行方案" |
其中补全 可能有价值，但不能把工程师未写出的内容一律当作"已知约束"。工程师可能遗漏某些规则，也可能有意不采用某项历史做法；系统应区分正式规范、已记录先例与模型推断，并让新增约束经过 review。如果组织已将经验记录在可检索的复盘或变更文档中，RAG 可以把这些已记录的经验重新呈现出来："你没说，但 net-policy 第 31 条有规定，而且上一次同类变更也做了这件事。"
这也回答了 5.4 里 R1 建议的来源：它来自历史先例，因此只能作为待审核建议，而不是未经批准的硬约束。
但要提醒一句："收敛"这一行是最容易被高估的。 检索提供了零件的清单，真正强制"只能用清单里的零件"的是 L6 的实体白名单与 schema 校验------清单本身不会自动变成约束。
6.4 一个对照案例
同一句模糊意图，两种系统。（本案例为演示性构造：其中的 ECN 阈值、+7% 收益、租户数量都是示例参数，不是实测数据，也不是可复用的调参结论。）
工程师说："优化一下训练网络的网络性能。"
无 RAG（自由生成）：
- 检查并调大 MTU 到 9000
- 开启 PFC 无损队列
- 调整 ECMP 哈希种子以均衡流量
- 为关键队列配置加权调度
- 建议升级交换机固件到最新版本
五条建议，每一条单看都很专业。问题在于：MTU 本来就是 9000；PFC 早就开了，真正的瓶颈是 ECN 阈值设在了 85%；改哈希种子会让正在跑的三个租户的流量重新分布；那个固件版本不在本组织的批准清单里。五条里四条是错的或有害的，但它们读起来毫无破绽。
有 RAG（检索先行）：
| 检索到的东西 | 内容 | 对方案的改变 |
|---|---|---|
| 事实语料 | MTU=9000、PFC 已启用、ECN 阈值 85%、租户 a/b/c 在线、ECMP 为默认五元组 | 否掉建议 1、2；定位到 ECN |
| 规范语料 | net-policy#L103（ECN 建议 40%）、#L31（同时下线 leaf ≤1）、#L22（固件白名单） | 给出目标值，否掉建议 5 |
| 经验语料 | CHG-2026-0431 同类优化，仅调 ECN 后 goodput +7%；INC-2025-0712 曾因同时调 PFC 和 ECN 引发震荡 | 收敛为单变量；加入"不得同时改 PFC"约束 |
在这个纯演示案例中，系统提出一个待验证候选：评估是否将 ECN 标记阈值从 85% 调整到规范允许的目标值，并先在一个可隔离范围灰度；不预先承诺 +7% 收益，也不在缺少本地验证时直接把 40% 当作生产参数。任何实际阈值都必须由设备队列、buffer、端侧拥塞控制与流量基准共同确定。
方案从五条变成一条，这不是能力下降，是质量上升。 而那被砍掉的四条，恰恰是"天马行空"的具体形态。
最后提醒一次：这个案例说明的是机制 （检索如何改变生成），不是结论（ECN 该调到多少）。真实环境里的 ECN 阈值取决于队列深度、buffer 配置、流量模型与端侧拥塞控制算法，没有任何理由照抄这里的 40%。
6.5 三项覆盖率、逐项门禁，与"我不知道"的合法化
先说清楚性质：0.9 / 0.6 这类阈值是作者提出的启发式起点，不是有公认依据的安全阈值，必须依据误检成本、漏检成本与风险敞口自行校准。
而且单一的"覆盖率"这个指标本身就不够用。一个意图包含 100 个字段，系统命中了 95 个------这不代表它已经具备 95% 的安全性，因为缺失的那 5 个可能恰好是跨租户隔离、路由安全或回滚条件。所以至少应该拆成三项：
| 指标 | 含义 | 缺失时的后果 |
|---|---|---|
| 实体覆盖率 | 设备、端口、租户、拓扑等对象是否得到可靠绑定 | 改错对象 |
| 约束覆盖率 | 每项硬约束是否有明确、有效且可执行的表达 | 漏掉禁止项 |
| 验证覆盖率 | 每项关键约束是否有对应的验证手段及明确边界 | 声称成功但无法证明 |
更重要的是：对安全硬约束必须采用逐项门禁（per-constraint gate），而不是凭平均覆盖率放行。 任何关键约束未确认，都应阻止相应的高风险操作------即使整体覆盖率已经达到 99%。 这正是 5.4 契约中 gates.mode: per_constraint 的由来。
在此之上，覆盖率可以作为降级信号驱动自治等级（下表的数值是启发式示例）：
| 覆盖率 | 系统行为 | 自治等级 |
|---|---|---|
| ≥ 0.9（示例） | 正常生成，全字段带引用 | 按原定等级执行 |
| 0.6 -- 0.9（示例） | 生成，但未覆盖项全部标 unverified，需人工逐项确认 |
降一级 |
| < 0.6（示例） | 不生成方案，只输出"我还缺这些信息"的澄清清单 | A0（仅建议） |
这条设计的意义超过它的技术含量：它让"我不知道"成为系统的合法输出。 一个永远给得出答案、却从不说"我没查到"的 AI，在意图工程里是最危险的组件------因为它的自信与它的无知不成比例。
6.6 RAG 自己的四个陷阱
引入 RAG 不等于解决问题，它只是把问题换了一批。四个必须提前设防的陷阱：
陷阱一：检索即背书（cherry-picking）。
模型先有了一个倾向，再从检索结果里挑一句支持它的，给错误方案穿上"有出处"的外衣。带引用的错误比不带引用的错误更难发现，因为它看起来经过了验证。对策：要求输出必须覆盖正反两类证据，并强制列出"被拒绝的候选方案及原因"。
陷阱二：检索不到 ≠ 不存在。
语料缺失时，AI 会默认"没有这条约束"。这是最难防的一条，因为系统的表现完全正常，只是它的世界比真实世界小。对策：严格区分"已检索且确认无"与"未检索到"两种状态，后者必须触发 ask_human，而不是静默通过。
陷阱三：语料漂移与鲜度。
文档写着 MTU 9000，实际是 1500。过期的权威文档比没有文档更危险 ------它是错的，还带着权威的光环。对策：事实类一律走活数据源，不走文档；文档类标注 freshness_sla，超期自动降级为"仅供参考"。
陷阱四：上下文挤压导致的关键信息丢失。
检索到 50 段，进模型时被截断成 10 段，而最关键的那条约束恰好被挤掉了。对策：把规范语料结构化------策略即代码、条款即字段，以字段形式进入提示词，而不是和叙述性文档一起争抢上下文窗口。约束应该用"机器可读的策略对象"表达，而不是"一段可能被截断的自然语言"。
6.7 RAG 不是安全边界：真正拦住 AI 的是六道闸门
这是本章、也是全文最需要说清楚的一条。
前面所有设计------语料分级、鲜度、引用链、覆盖率------解决的是"信息缺失"这一个问题 。但生产变更的安全性至少还取决于另外几件事：业务意图是否有歧义、策略是否冲突、编译器是否正确实现了策略语义、验证器是否覆盖真实风险、执行器是否具备最小权限与可靠回滚、变更后是否有独立验收与审计。RAG 只解决其中的第一项。
所以必须明确：
RAG 是证据供给机制，不是安全执行机制；引用是证据线索，不是正确性证明。
真正拦住模型的是检索之外的六道闸门。它们与检索的关系是并列且互补，不是由检索派生：
| 闸门 | 做什么 | 拦住什么 | 所在层 |
|---|---|---|---|
| 1. 结构化输出约束 | 强制输出符合契约 schema，禁止自由字段 | 模型"顺手"加上去的字段 | L6 |
| 2. 实体与策略白名单 | 只允许引用检索到的实体 ID 与策略条款号 | 凭空发明的 VLAN / rail / ACL 名称 | L6 |
| 3. 字段级证据校验 | source_id 必须能解析回原文，并核对语义一致 |
引用存在但不支持该值的"假引用" | L6 |
| 4. 确定性编译 | 由程序生成配置，不由模型输出命令 | 模型直接产出设备 CLI | L6 → L2 |
| 5. 独立验证器 | 在建模范围内检查可达性、策略冲突与负向用例 | 把"生成时的自洽"当成"真实正确" | L5 |
| 6. 执行安全控制 | 最小权限、范围与速率限制、幂等、熔断、回滚演练、审计 | 前面全错时把后果放大到整个 fabric | L3 |
其中第 3 条值得单独说明，因为它最容易被漏掉：模型的引用可能真实存在，却并不支持它给出的那个值。 例如引用了 net-policy 第 88 行（PFC 阈值规范），却把阈值写成了另一个数字。只检查"有没有引用"是不够的，必须检查"引用是否支持这个值"。
把这六道闸门与检索放在一起看，才能得到一个诚实的结论：
检索降低的是"因为不知道而犯错"的概率；六道闸门限制的是"即使不知道也不会造成灾难性后果"的边界。 前者提升质量，后者控制风险，二者不能互相替代。
6.8 小结
如果把这一章压缩成一句话：
RAG 在意图工程里的角色不是知识插件，而是收敛器------它减少的不是 AI 的无知，而是 AI 的自由发挥空间；但它只收敛，不设限。
知识是副产品，收敛才是目的 ，而边界要另设。这也解释了为什么"先检索、再生成"这个顺序不可协商：先生成后校验，你校验的是一个已经被想象力污染过的候选；而先检索再生成，AI 从第一步起就大概率只在这个组织真实拥有的零件库里组装。
最后把那个比喻的限定说完整："零件库"描述的是概率上的收敛，不是机制上的保证。 模型依然有能力造出库里没有的零件------拦住它的是白名单、证据校验和独立验证，不是检索本身。
七、意图如何被编译、验证、保障
7.1 编译：三段式，不能一步到位
从一句话到一台设备的配置，中间必须经过三个中间产物。跳过任何一段，都会把错误推迟到更难发现的地方。
而这三段的输入，全部来自第六章的检索结果：① 依赖事实语料做实体绑定，② 依赖规范语料展开策略，③ 依赖事实语料核对设备型号、版本与命名。 没有检索供给的编译，本质上是让模型凭记忆写代码------它能写出语法正确的代码，但不知道你仓库里有哪些函数。
自然语言
│ ① 语义解析：抽取目标、域、对象、约束、度量
▼
Intent IR（结构化意图）
│ ② 策略合成：展开为可达性规则、QoS 映射、路径约束
▼
Policy Set（与厂商无关的策略集）
│ ③ 设备编译：映射为具体厂商的配置/OpenConfig 模型
▼
Config Candidate（配置候选，未下发）三段式的价值在于每一段都可以单独验证，且可以单独替换。换一个交换机厂商，只需替换③；业务意图变化，只需改①；策略优化，只动②。
7.2 验证的四个层级，以及验证器的边界
验证不是一个动作，而是四个层级。它们回答的是不同性质的问题，前一层级的通过不能证明后一层级成立。
| 层级 | 手段 | 能回答什么 | 成本 | 局限 |
|---|---|---|---|---|
| ① 语法与模型校验 | schema 检查、数据模型校验、约束检查 | 配置是否合法、是否符合数据模型 | 低 | 不保证语义正确 |
| ② 网络行为分析 | Batfish、等价类分析、头空间分析（NetKAT 等） | 在给定模型下，流量是否可达、策略是否冲突 | 中（随网络规模、配置复杂度与协议模型而变化；大型网络的数据平面计算可能需要数分钟） | 只覆盖被建模的属性，不建模性能与真实硬件行为 |
| ③ 性能与拥塞评估 | 仿真、数字孪生 | 特定流量模式下的吞吐、队列水位与延迟 | 较高 | 结论精度取决于孪生环境与真实环境的一致程度 |
| ④ 真实环境验证 | 灰度执行、负向测试、实测 | 设备、固件、遥测与真实流量是否符合预期 | 高 | 需要变更窗口与回滚准备，本身有风险暴露 |
工程上的合理顺序是 ① → ② → ③ → ④，逐级放大成本与置信度。跳过前几步直接上现网，是在用生产环境做测试环境。
最关键的一句必须写在前面：
①②不能自动证明③④。 一个通过了可达性分析的配置，仍可能在真实设备上因为队列配置、芯片行为或固件差异而表现完全不同。
因此，所有验证输出都必须附带三样东西：覆盖范围（验证了哪些属性）、未建模行为（哪些没验证）、数据与模型假设（基于哪个配置快照与拓扑）。验证器只能对它明确建模的属性、输入和假设给出结论。
以 Batfish 数据平面分析说明为例：它依据设备配置与网络模型分析路由、转发与可达性，是非常有价值的控制平面分析工具；但它不是能够自动证明所有网络性能与安全属性的通用证明器 ，其数据平面计算在大规模网络上也可能耗时数分钟。把它当成"证明配置正确"的工具，是把一个分析器当成证明器用。
即便如此，它的价值依然被长期低估。它能枚举出"这条 ACL 会不会让某个子网在某种失败场景下不可达"，而这个问题的正确答案，人类工程师通常只能给出"应该不会"。网络事故复盘里反复出现的那句"我以为不会影响那个业务"，本质上是同一个问题的两种说法。
7.3 执行：分批、灰度、可回滚
以下是高风险变更执行器应具备的基本控制原则；具体分批粒度与验证项需依据拓扑和变更类型确定：
- 按爆炸半径排序：先改最边缘、影响面最小的设备；核心设备最后。
- 每批之后必须验证，验证不过立即停，不允许"先把剩下的刷完再一起看"。
- 回滚路径必须预先存在且被测试过。"我们有备份配置"不算回滚能力------没演练过的回滚等于没有回滚。
7.4 保障：把 SLA 变成持续运行的检查
变更完成不等于意图达成。保障环路要做的是：
每 N 秒：
采集事实（遥测）→ 与意图的 target_state 比对 → 计算偏离度
偏离 < 容忍阈值：记录，不动作
偏离 ≥ 阈值但可自愈：触发纠正（重路由 / 调整 ECN / 隔离链路）
偏离 ≥ 阈值且不可自愈：告警 + 冻结变更 + 生成归因假设这里最容易做错的是纠正动作本身 。一个自动重路由如果与 BGP 收敛叠加，可能制造出比原问题更大的震荡。所以保障环路也必须受 capabilities 约束：它能做的纠正动作，必须是白名单里的、有限振幅的、可撤销的。
7.5 一个完整案例：万卡集群新增租户
把上面所有机制串起来看一遍：
| 阶段 | 输入 | 动作 | 产出 |
|---|---|---|---|
| 意图表达 | 平台团队的诉求 | LLM 澄清"rail 独立""禁止绕行""不影响邻居"的具体含义 | 意图契约草案 |
| 检索与补全（L7） | 契约草案 + 事实/规范/先例语料 | 实体消歧（rail 3 → 具体 leaf 组）；提出 R1 基线采集建议并标记待审批；关键约束逐项绑定 source_id；覆盖率 0.94（示例值，需定义分母、字段权重与缺失处理规则） |
带出处的契约 v0.1 + 未覆盖项清单 |
| 前置检查 | 契约 + 光模块/K8s 状态 | 检查收光功率、FEC 计数、端口可用性 | 前置条件报告（P1/P3 通过） |
| 编译 | 意图 IR | 展开为 8 个 rail 的 ACL + QoS + PFC headroom | 与厂商无关的策略集 |
| 静态分析 | 策略集 + 现有配置 | 可达性矩阵计算，比对 tenant-a/b/c | 差异报告：仅 tenant-b 命名空间变化 |
| 孪生预演 | 拓扑 + 策略集 | 模拟流量，观察队列水位与 PFC 触发 | 预演报告：峰值 PFC 320pps，低于 1000pps 阈值 |
| 审批 | 上述全部证据 | 网络负责人 review diff 与预演结论 | 批准 |
| 分批执行 | 批准的计划 | 先 leaf-1 后 leaf-2...，每台后跑 V2 检查 | 执行日志 |
| 验收 | 目标状态 | 负向测试 + NCCL 基准 + 72h goodput | 验收报告 + 证据包 |
| 回流 | 全部 artifact | 契约入库，作为下一个租户的模板 | 可复用的网络意图资产 |
注意第 2 步和第 5 步：一个是"环境是否具备条件"，一个是"方案是否真的安全"。 这两个问题在传统流程里通常由同一个人在同一个会议上有同一个直觉回答；在意图体系里，它们被拆成两个可独立验证的检查点。这就是"把判断力从直觉变成证据"的具体形态。
八、人的位置：从网络工程师到网络意图工程师
8.1 能力迁移
| 能力 | 过去的重要性 | 未来的重要性 | 变化性质 |
|---|---|---|---|
| CLI 熟练度、厂商命令记忆 | 高 | 中（仍需，但不再是核心） | 从"生产力"退化为"识字率" |
| 协议原理（BGP/EVPN/PFC/ECN） | 高 | 更高 | 因为要判断 AI 的方案是否合理 |
| 拓扑与故障模式建模 | 中 | 极高 | 意图的约束条件来自这里 |
| 验证设计（含负向测试） | 低 | 极高 | 决定自治等级的上限 |
| 意图表达与契约撰写 | 无 | 高 | 新的核心产出物 |
| 语料治理（事实/规范/先例分级、鲜度与权威） | 无 | 高 | AI 的假设空间大小由它决定 |
| 验证边界意识（知道验证器覆盖了什么、没覆盖什么） | 低 | 高 | 决定"通过验证"这句话能信几分 |
| 跨域协同（算/网/存/调度） | 低 | 高 | AI Infra 的天然要求 |
| 权限与爆炸半径治理 | 中 | 高 | 一次误配等于全站 |
一句话：从"会配"转向"会判"，再转向"会喂"。 "会判"的前提是"懂"------一个不理解 PFC 死锁机理的人，写不出"PFC 计数持续增长时禁止扩容"这条约束，他不会想到有这回事。而"会喂"的意思是：你给 AI 的语料，就是你能给它的自由度。 语料里没有的规范，它不会遵守；语料里过期的拓扑，它会照着配。
8.2 四个反模式
反模式一：意图不可测量。
"网络要稳定""延迟要低""保证高可用"------这些不是意图，是愿望。合格的意图必须能回答："系统怎么知道它被违反了？" 如果答不出来，就还没有完成意图设计。
反模式二：把 LLM 放进数据面的决策链。
让模型在毫秒级拥塞决策里"判断一下"，等于把确定性系统换成一个带随机性的系统，而且是在最不能容忍随机性的位置。转发面要的是可穷举的行为，不是合理的猜测。
反模式三：自动化雪崩。
保障环路检测到偏离 → 自动重路由 → 引发次生拥塞 → 再次检测到偏离 → 再次重路由。自动化的最大风险不是它做错一次，而是它把一个错误重复一千次。 所以纠正动作必须有振幅限制、频率限制和熔断机制------这三样比纠正逻辑本身更重要。
反模式四：把 RAG 当成"知识库堆料"。
把 Wiki、工单、聊天记录、三年前的架构文档一股脑灌进向量库，然后指望模型自己分辨哪份是当前规范、哪份是临时方案。检索质量不取决于语料的数量，取决于语料的分级与鲜度。 一个未分级的语料库，本质上是"用向量相似度伪装的随机源"------它会让错误方案更容易找到一句支持它的引文，而不是更难。
九、边界：今天做不到的事
一篇诚实的文章必须写清楚这一点。意图定义网络目前仍处于方法论形成期，以下七个边界在可见的未来都不会消失。
9.1 意图的形式化极限
自然语言天然模糊，而网络策略要求完备。"不允许办公网访问生产数据库"------是禁止所有端口，还是只禁 3306？是禁 IP 段，还是禁身份？IPv6 呢？带内管理口呢？每一个歧义点在网络里都会变成一个真实的开放面。
LLM 能帮你澄清这些歧义（这正是它最有价值的地方），但它不能替你决定业务上到底想要什么。歧义的最终消解责任在人。
RAG 在这里能做的是把一部分"AI 不知道"转化为"系统找到了可核验的资料"，但它查不出"业务上到底想要什么"。语料里没有的意图，系统只能反问；而反问的质量，取决于它是否知道自己不知道什么------这正是 6.5 那条覆盖率机制存在的意义：它把"没查到"从一种隐性失败，变成了一个显式的降级动作。
9.2 可观测性的物理上限
你只能验证你测量到的东西。INT 需要芯片支持，采样遥测会丢细节，eBPF 有内核版本限制，时钟不同步会让关联分析失真。
这意味着：意图体系的可靠性上限，等于遥测体系的保真度上限。 想做高层意图，先老老实实投资底层可见性------这个顺序反了，得到的就是"看起来很智能，实际上在猜"的系统。
9.3 爆炸半径与授权
网络是全局共享故障域。计算挂一台，影响一个作业；网络配错一条 ACL，可能影响全站。因此网络的自治等级通常应比计算更保守。下表是一组初始建议，不是固定映射：自治等级必须依据影响范围、可逆性、验证覆盖率、审批权限与故障恢复能力动态评估------同一个操作在不同的 fabric、不同的业务时段、不同的验证能力之下，完全可以是不同等级：
| 操作类型 | 建议自治等级 |
|---|---|
| 只读诊断、根因假设生成 | A3（可自主） |
| 单端口/单 VLAN 级调整 | A2（受控执行 + 审批） |
| 路由策略、QoS 全局参数 | A1（生成方案，人工执行） |
| 核心 ACL、BGP 策略、安全边界 | A0--A1（仅建议） |
| 任何可能造成跨租户影响的操作 | A0 |
9.4 异构与多域
真实的 AI 集群往往是 InfiniBand 计算网 + RoCE 存储网 + 以太前端网三网并存，再叠上云上 VPC 和分支 SD-WAN。在异构环境中，通常不能假设单一控制器原生、完整地理解 InfiniBand Subnet Manager、以太网 EVPN 与云安全组的全部语义。通过多控制器编排、标准化模型和适配器可以整合部分能力，但跨域语义、可见性与责任边界仍是主要难点。 意图在这种环境下必然被切成多段，"端到端意图"目前只是一个方向，不是一个可交付物。
9.5 责任归属
"这条 ACL 是谁批准的？" 这个问题在任何事故复盘里都会出现。意图体系必须能回答：意图谁提的、谁批的、AI 调了什么接口、系统实际改了什么、验证是谁做的。如果审计链断了，自治等级就必须降回 A0------不是技术原因，是治理原因。
9.6 成本
写契约、建孪生、做形式化验证、维护遥测精度、维护 RAG 语料的分级与鲜度------这些都有可观的固定成本，而且最后一项最容易被低估：语料不是一次性建的，它需要像代码一样被 review、版本化和定期清理。 对"给测试环境加个 VLAN"这种任务，意图工程的开销远大于收益（这里不给出"十倍"这类测算，因为没有通用的计算模型；合理的做法是估算两侧：一侧是"写契约 + 评审契约 + 维护语料"的人力成本，另一侧是"事故概率 × 事故损失 + 重复执行节省的时间"）。判断标准很简单：任务是否复杂、是否高风险、是否重复出现。 三者至少占两项，才值得上意图体系。
9.7 检索的概率性 vs 策略的完备性
这是 RAG 无法靠工程优化消除的结构性局限。
网络策略要求完备 ："所有不该通的路径都不通"------注意是"所有"。而向量检索是概率性 的：它返回"最相似的 k 条"，从不承诺"相关的都在这里"。这两者之间存在根本张力：你可以不断提高召回率，但无法证明某一次检索是完备的。
所以即使 RAG 做得再好，意图体系也必须保留不依赖检索的兜底：
- 网络行为分析（7.2 的第②级）不依赖检索，它直接对完整配置做可达性枚举；
- 负向测试不依赖检索，它直接实测"不该通的是否通了"；
- A0 等级不依赖检索，它在证据不足时把决策权交回人。
换句话说：RAG 有助于收敛生成，但不能单独保证策略完备性。策略完备性需要在完整、可信的配置与资产模型上，结合可达性分析、策略检查、负向测试及明确的未建模边界来评估；即使如此，也不能据此宣称对所有真实硬件行为都已证明完备。 这正是本文始终坚持"检索与 LLM 在两端、确定性留在中间"的根本原因------中间那一段，不能有概率。
十、结语：控制权的三次迁移
回到标题。
第一次迁移 ，是把控制权从"每台设备各自的协议收敛"里拿出来，交给集中式控制器。这是 SDN。它解决的是可见性与可编程性------网络第一次成为可以被软件工程化的对象。
第二次迁移 ，是把控制权从"人的配置动作"里拿出来，交给"策略 + 闭环保障"。这是 IBN。它解决的是正确性与持续性------网络不再假定"下发了就等于实现了"。
第三次迁移 ，是把控制权从"预先枚举的策略目录"里拿出来，交给"能理解业务语言、能提出候选方案、能在约束下规划"的系统。这是AI 增强的意图管理 。它要增强的是表达力与规划能力------自然语言接口有机会降低表达业务目标的门槛，但它仍须把目标转换为可检查的策略和约束，而不是直接把自然语言当作可执行配置。
需要说明：这三次迁移是本文的分析模型，不是行业已经完成、或必然经历的三个历史阶段。 现实里三者是共存关系：SDN 并不必然意味着控制权全部集中到单一控制器；意图管理的目标导向与持续保障思想在 LLM 出现之前就已存在；AI 可以增强已有的意图管理系统，但不意味着传统 IBN 会被 AI-IBN 取代。更准确的描述是：网络管理在可编程性、目标表达与自动化推理三个方向上的能力扩展，实际架构往往是三者的某种混合。
三次迁移共享同一个方向：
人类少 specify 一点，机器多 infer 一点；但人类要承担的判断责任，一点都没有减少。
而贯穿三次迁移的那条红线可以表述得更严谨一些：
机器每获得一项更高风险的操作权限，就必须同时满足相应的证据充分性、策略约束、验证覆盖、执行权限、可逆性与审计要求。证据不足时必须降级；证据充分也不意味着可以绕过独立验证。
SDN 时代的证据是配置 diff，IBN 时代的证据是遥测与 SLA，意图时代的证据是检索得到的出处链 + 独立验证结论 + 执行审计 。所以 RAG 在这个体系里的定位从来不是"给 AI 补知识"，而是为自主权提供证据材料------但它只是材料之一。
这里的关键差异在于：安全自治不是由证据的数量决定的，而是由证据质量、验证能力与操作风险共同决定的。 一条带引用的约束，如果它的值不被引用真正支持、它的验证手段不存在、它对应的操作不可逆，那么它依然不应该被自动执行。自主权与证据必须同比例增长，但比例的分母还包括验证能力与可逆性------这是整套体系里唯一不能妥协的配比。
AI Infra 强化了在机器内部闭合快速控制回路的必要性，但这里的"机器内部"应指协议、硬件、确定性算法与经过验证的自动化，而不是让 LLM 直接参与毫秒级控制。对于需要跨域目标协调、策略治理和审计的慢速回路，意图管理可以提供更高层的规划与保障。
所以这篇文章真正的结论，和上一篇是同一条：
意图定义网络的价值，不是让机器更聪明地猜工程师想要什么，而是让工程师能把"想要什么"表达得足够精确，精确到可以被验证。
而 RAG 在这句话里的位置，是让"猜"这件事本身大幅减少：它把 AI 从"在无限空间里想象一个合理方案"，变成"在这个组织真实拥有的零件库里组装一个方案"。 前者需要你事后判断它对不对，后者允许你事前判断它可能是什么。
在这一点上，网络是检验意图工程的一类高价值试验场：协议复杂、故障传播快、配置变更风险高，而且部分属性（可达性、策略冲突）可以通过形式化方法分析。它适合用来验证"目标形式化、证据约束、独立验证、受控执行、持续保障"这些通用方法是否真的有效。
但这不等于同一套方法可以直接推广到其他基础设施领域。 数据库要处理事务一致性、锁与隔离级别；存储要处理持久性、写入顺序与故障切换；身份管理要处理权限继承、身份生命周期与授权边界；工业控制要处理物理安全、实时性与设备失效模式。这些领域的业务约束、风险模型、验证对象与安全边界都必须重新定义。
网络验证成功证明的是"这些工程原则具有迁移价值"，不是"其他领域必然跑得通"。把前者说成后者，是本文原稿里最该被删掉的一句话。