不要让模型编写 YAML：LLM 建议的字段更改的确定性、最小差异 GitOps 修复

LLM 代理越来越多地诊断事件并提出补救措施。在 GitOps 工作流程中，应用修复意味着编辑版本控制的配置文件，而显而易见的实现是让模型编写编辑后的文件或差异，这是从业者首先要做的。在真实的 Kubernetes 清单上评估该选择后，我们发现没有任何文本生成策略对于无人值守的自动化来说是安全的。统一差异是不安全的：在严格的修补下几乎没有任何应用，但这是一个工件，因为宽容工具（GNU 补丁）应用了 96％，但默默地错误应用了大约七分之一（14-20％）而没有错误信号。全文件重写取决于功能：小模型会损坏文件，而前沿模型通常是正确的但不确定（它会默默地删除一个字段或在某些运行中编辑邻居）并且必须重新生成整个文件，每次编辑的成本为 O（文件大小）。我们提出了一种替代方案，将语义决策（哪个资源、字段和值）与编辑文件的语法行为分开。代理仅发出结构化的字段更改意图；确定性管道索引通过（种类，名称）体现，通过 YAML 解析器的节点位置标记定位目标标量的确切字符范围，并仅替换原始文本中的该范围。由于文件永远不会重新序列化，因此构造差异最小，保留格式和注释，并且编辑是正确的且独立于模型的确定性，生成成本为 O(1)。其贡献是将 LLM 提出的意图与 GitOps 的确定性、故障关闭应用程序合约配对。我们在 KubeAstra (Apache-2.0) 中实现它并发布基准测试。我们的主张仅限于忠实应用已知变更；更改是否正确由人工公关审查。