如何将运维意图与执行器分离
内容提要
文章主张将运维意图与执行机制分离：以稳定的运维规范描述目标、约束和所需证据，执行器仅负责实现并返回证据，再由独立评估器判定是否符合规范。这样更换工具或AI代理时运维含义不变，并可比较不同执行器的合规性。
延伸解读
执行器独立性的实际含义
执行器独立性并非要求不同执行器内部步骤一致，而是指运维规范在更换执行机制后依然有效。例如，同一部署规范可由滚动部署、蓝绿部署或AI代理实现，只要它们都能满足规范中的约束（如副本数、错误率、延迟）并返回所需证据。这种独立性让团队在迁移工具时，无需重新定义成功标准，从而避免工具锁定和语义迁移。
证据标准化与合规评估的分离
不同执行器返回的证据格式可能各异，如字段名不同。文章强调通过适配器将执行器特定证据转换为规范层定义的规范证据模型，确保比较基于统一概念。同时，执行器应只返回事实证据，而非成功标志；合规性由独立评估器根据规范判定。这种分离使证据可复用，并支持审计和重新评估。
执行器独立性常见的断裂点
文章指出，独立性常在以下情况失效：规范中包含工具特定字段（如kubernetesNamespace）、执行器自定义成功规则、缺乏证据标准化、隐藏前置条件或恢复行为、以及概念语义不匹配（如healthy与ready）。这些断裂点暴露了隐藏耦合，需通过明确规范定义和证据映射来解决。
对AI代理的意义与测试方法
AI代理每次可能生成不同执行计划，使得逐步等价不现实，但规范可保持稳定，代理只能在约束内自主优化。文章建议通过测试矩阵验证执行器可移植性：用一组规范运行多个执行器，比较合规结果。这能揭示执行器是否正确、规范是否完整或证据是否缺失，从而指导改进。
Q&A
什么是运维意图与执行器分离？
运维意图与执行器分离是指将运维规范（描述目标、约束和所需证据）与执行机制（负责实现并返回证据）分开，再由独立评估器判定是否符合规范。这样更换工具或AI代理时运维含义不变，并可比较不同执行器的合规性。
为什么需要将运维意图与执行器分离？
因为现代软件系统经常更换执行机制（如CI/CD平台、云提供商、部署系统等），如果更换执行器也改变了操作的含义，系统就不是真正由规范驱动的。分离可以避免工具锁定、隐藏行为变化、重实现漂移和审计缺口，使迁移时只需保留规范、替换机制。
如何定义执行器契约？
执行器契约是一个最小接口，规定执行器接收运维规范并返回执行证据。例如 DeploymentExecutor 接口包含 execute(spec: DeploymentSpec): Promise<ExecutionEvidence> 方法。接口不应包含工具特定概念（如 kubectl 命令），否则会破坏可移植性。
如何比较不同执行器的执行结果？
应比较证据而非内部步骤。不同执行器可能产生不同的证据值（如副本数、错误率、延迟），但只要满足同一规范即可。需要将执行器特定的证据格式通过适配器归一化为规范证据模型，然后由独立评估器根据规范检查每个约束，返回合规结果和失败原因。
执行器独立性通常在哪些地方失效？
常见失效点包括：规范中包含工具特定字段（如 kubernetesNamespace）、执行器拥有成功规则、缺少证据归一化、隐藏前置条件（如审批）、隐藏恢复行为（如自动回滚）、以及语义不匹配（如 healthy、ready 等概念定义不一致）。
如何测试执行器的可移植性？
可以准备一组运维规范，对每个执行器运行每个规范，收集证据并评估合规性，生成一个矩阵（如 Rolling 和 BlueGreen 对 Orders v42 和 Payments v18 的 PASS/FAIL 结果）。这能提供执行器可移植性的证据，而不是假设工具等价。
执行器独立性对AI代理有什么意义？
AI代理可能每次生成不同的执行计划，步骤级等价不现实。但规范可以保持稳定，代理在运维约束内自主选择计划，其结果仍用同一契约评估。这创造了代理自主性与运维约束之间的边界：代理可以优化执行，但不能悄悄重新定义成功。
执行器独立性是否意味着所有工具可以互换？
不是。不同执行器可能有不同的能力、成本、延迟、故障模式、安全模型和运维复杂度。规范可能要求某个执行器无法提供的能力（如零停机部署）。执行器独立性不意味着忽略实现细节，而是运维含义不应依赖于特定执行机制。
