如何衡量操作规范与其实际执行情况之间的符合程度

在我之前的文章中，我探讨了“执行器独立性”这一概念：即不同的执行机制应当能够满足相同的操作规范要求。

所谓“执行器独立性”，指的是即使负责执行的机制发生了变化，操作规范本身仍然应该保持稳定不变。

这种理念为我们提供了一种有用的架构模型：

规范
      ↓
执行器
      ↓
证据

然而，这仍然留下了一个重要的问题：我们该如何判断某次执行所产生的结果是否真正符合这些规范要求呢？

这就是所谓的“合规性评估问题”。

从执行器的角度来看，某个部署过程可能已经成功完成，但实际上却可能违反了操作规范的要求；

某个修复机制也可能完成了所有计划中的操作，但最终仍会使系统状态超出可接受的范围内；

甚至一个恢复操作也可能在没有任何错误的情况下结束，但却无法恢复所需的数据。

正因如此，像success = true这样的简单判断标准是远远不够的。

我们需要一种方法，来对比“理论上应该发生的情况”与“实际观察到的结果”，从而得出明确、可解释且有用的评估结论。

在本文中，我将向您展示如何对操作合规性进行建模分析，如何逐一评估各种约束条件，如何区分“通过”“失败”或“未知”的结果，如何处理容差问题，如何应对缺失的证据，如何为不同问题的严重性进行分级，如何生成有用的合规性总结报告，以及如何避免将合规性评估简单地转化为一个误导性的分数。

这些示例虽然使用了TypeScript和特定的部署场景，但同样的方法同样适用于基础设施变更、事件响应、数据备份与恢复、数据管道系统以及由人工智能驱动的系统。

核心理念就是：合规性的判断标准并不取决于执行器是否声称自己已经完成了任务，而在于实际观察到的结果是否符合操作规范的要求。

先决条件

您需要具备以下基础知识：

• 关键的软件架构概念

• TypeScript或类似的语言

• 基本的测试方法

• 可观测性相关技术

• CI/CD开发流程

• 操作规范的定义与编写方法

• 执行器独立性的概念

您不需要使用特定的部署平台，而且这些示例的设计也相对简单，因此评估模型的结构非常清晰、易于理解。

目录

• 先决条件

• 在此背景下，合规性意味着什么

• 从规范和证据入手开始分析

• 逐一评估各项约束条件

• 不要将所有情况简单地归为“通过”或“失败”

• 将缺失的证据视为未知状态

• 在无法进行精确比较时，使用容差值

• 为各项约束条件分配严重性等级

区分强制性约束条件和建议性约束条件

• 构建可重复使用的合规性评估工具

• 谨慎地生成合规性总结报告

• 为什么单一分数可能会产生误导

• 保留评估结果背后的所有证据

• 合规性评估结果应该是可复现的

• 这种方法如何应用于多个执行器场景

• 这种方法如何适用于人工智能代理

• 一个简单的端到端示例

• 实用的合规性评估工作流程

• 合规性评估无法证明什么

• 从执行成功到操作结果的可验证性

• 结论

在此背景下，“符合规范”意味着什么

用通俗的话来说，符合规范就是遵守某种规则、标准或要求。

不过在这里，我会对这个术语进行更具体的定义：

“运行符合规范”是指评估观察到的系统运行结果是否满足某份操作规范的各项要求。

在这个背景下，“证据”指的是从系统中收集到的一系列可被观察到的数据，这些数据可以用来与规范进行对比。它本身并不代表最终的结果判断，而是用于产生这一判断的数据。

这个定义包含三个部分。

1. 规范

规范明确了哪些内容是必须满足的。

例如：

version = v42
available replicas >= 3
error rate <= 1%
p95 latency <= 400 ms

2. 证据

证据描述了实际观察到的情况。

例如：

version = v42
available replicas = 3
error rate = 0.4%
p95 latency = 280 ms

3. 评估

评估就是将证据与规范进行对比。

例如：

version             PASS
available replicas  PASS
error rate           PASS
p95 latency          PASS

因此，“符合规范”并不是系统本身的属性，而是通过将证据与规范进行对比后得出的结果。

从概念上来说：

规范
      +
证据
      ↓
评估结果
      ↓
最终结论

从规范和证据入手

假设我们有这样一份部署规范：

type DeploymentSpec = {
  version: string;
  minReplicas: number;
  maxErrorRate: number;
  maxP95LatencyMs: number;
};

const spec: DeploymentSpec = {
  version: "v42",
  minReplicas: 3,
  maxErrorRate: 0.01,
  maxP95LatencyMs: 400,
};

现在我们来定义相应的证据：

type DeploymentEvidence = {
  version: string;
  replicas: number;
  errorRate: number;
  p95LatencyMs: number;
};

const evidence: DeploymentEvidence = {
  version: "v42",
  replicas: 3,
  errorRate: 0.004,
  p95LatencyMs: 280,
};

最简单的评估方式可能是返回一个布尔值：

function conforms(
  spec: DeploymentSpec,
  evidence: DeploymentEvidence
): boolean {
  return (
    evidence.version === spec-version &&
    evidence.replicas >= spec.minReplicas &&
    evidence.errorRate <= spec.maxErrorRate &&
    evidence.p95LatencyMs <= spec.maxP95LatencyMs
  );
}

这种做法虽然可行，但存在一个问题。

<如果结果是：

false

你并不明白为什么会出现这样的结果。对于实际操作来说，这种信息是远远不够的。

单独评估各项约束条件

不要用一个布尔值来表示所有检查结果，而应该分别评估每一项约束条件。

type ConstraintResult = {
  name: string;
  passed: boolean;
};

function evaluateDeployment(
  spec: DeploymentSpec,
  evidence: DeploymentEvidence
): ConstraintResult[] {
  return [
    {
      name: "version",
      passed:
        evidence.version === spec.version,
    },
    {
      name: "replicas",
      passed:
        evidence.replicas >= spec.minReplicas,
    },
    {
      name: "error-rate",
      passed:
        evidence.errorRate <= spec.maxErrorRate,
    },
    {
      name: "latency",
      passed:
        evidence.p95LatencyMs <= spec.maxP95LatencyMs,
    },
  ];
}

ConstraintResult为每一项检查结果提供了一个名称以及一个布尔值。函数evaluateDeployment()会逐一将观测到的数值与规范中对应的规则进行比较，判断部署后的版本是否与规范要求完全一致、副本数量是否足够、错误率及延迟是否在允许的范围内。

该函数并不会将所有这些检查结果合并为一个true或false，而是会为每一项约束条件返回一个单独的结果。这样，调用者就能清楚地知道是哪些要求通过了测试，哪些没有通过。

因此，输出结果可以是这样的：

version       PASS
replicas      PASS
error-rate    PASS
latency       PASS

或者：

version       PASS
replicas      FAIL
error-rate    PASS
latency       FAIL

这种表示方式要实用得多。因为这样就能清楚地了解哪些操作失败了，原因也便于解释。

不要将所有结果简单地归为“通过”或“失败”

有时候，二进制的评估方式确实过于简单了。

假设规范要求：

错误率 <= 1%

但你的监控系统目前无法提供相关数据。

在这种情况下，应该给出什么结果呢？

显然，PASS是不正确的。

而FAIL也可能产生误导，因为这实际上混合了两种不同的情况：

系统确实违反了规范要求

以及：

PASS FAIL UNKNOWN

例如：

type ConstraintStatus = | "PASS" | "FAIL" | "UNKNOWN";

对于那些缺乏数据的检查项，结果绝对不应该被默认为“通过”。

将缺失的证据视为未知状态

^{假设某些证据变得不完整了。换句话说，该系统可能会返回部分观测数据，而不是全部数据。部署记录可以告诉我们当前正在运行的是哪个版本，以及系统中有多少个副本可用，但错误率这一指标目前还无法获取。}

我们可以通过将每个证据字段设置为可选来体现这一点：

type DeploymentEvidence = {
  version?: string;
  replicas?: number;
  errorRate?: number;
  p95LatencyMs?: number;
};

随后，评估器需要区分真正的违规情况与数据缺失的情况：

function evaluateErrorRate(
  spec: DeploymentSpec,
  evidence: DeploymentEvidence
): ConstraintStatus {
  if (
    evidence.errorRate === undefined
  ) {
    return "UNKNOWN";
  }

  return (
    evidence.errorRate <= spec.maxErrorRate
  )
    ? "PASS"
    : "FAIL";
}

首先，该函数会检查是否确实检测到了错误率数值。如果没有检测到，则返回UNKNOWN，而不会进行猜测；如果检测到了该数值，就会将其与规定的最大允许错误率进行比较，并据此返回PASS或FAIL。

这样得到的结果如下：

errorRate = 0.004 → PASS
errorRate = 0.03  → FAIL
errorRate missing → UNKNOWN

这种区分非常重要。数据缺失意味着我们原本期望能够获取到的指标或运行状态信息实际上并不存在。例如，因为监控系统在某个时间窗口内没有报告错误率数值。如果将这种数据缺失的情况也视为“通过”，那么合规性的评估结果就会变得过于乐观。

在无法进行精确比较的情况下使用容差

有些约束条件确实应该要求完全相等。

例如：

部署的版本必须等于v42

而另一些约束条件则不必如此严格。

在数字系统中，有时需要设置容差，因为即使两个数值在功能上是等价的，它们的测量结果也可能存在细微的差异。浮点运算、采样、四舍五入以及测量误差等因素都可能导致数值虽然并不完全相等，但仍然符合要求。

function withinTolerance(
  observed: number,
  expected: number,
  tolerance: number
): boolean {
  return (
    Math.abs(observed - expected)
    <= tolerance
  );
}

例如：

withinTolerance(
  1.9999999,
  2,
  0.0001
);

这个函数会计算观测值与期望值之间的绝对差值，然后判断这个差值是否在允许的容差范围内。当预期会出现微小的数值差异时，使用这种判断方法可以避免出现误判。

不过，容差的设定必须基于实际的操作需求，而不能仅仅为了让所有的检测结果都显示为“通过”而随意设置。

为约束条件添加严重性等级

并不是所有的约束条件都具有相同的操作重要性。

假设有两个约束条件同时出现了问题：

延迟时间为405毫秒，副本数量为0。

这两种情况都属于故障，但它们并不相同。

如果延迟时间只是略微超出正常范围，或许只需要采取相应的措施，而不必立即进行回滚操作；而当副本数量为零时，则意味着服务已经无法正常使用，此时必须立即启动恢复流程。通过区分故障的严重程度，我们可以更合理地评估这些情况，而不是将所有故障都视为同等重要。

type Severity =
  | "INFO"
  | "WARNING"
  | "CRITICAL";

type ConstraintResult = {
  name: string;
  status: ConstraintStatus;
  severity: Severity;
};

在这里，status用于说明某个约束条件是通过了测试、失败了，还是根本无法被评估。而severity则反映了这一结果在实际运行中的重要性。

这两个维度是相互独立的：一个约束条件可能会以WARNING的严重程度失败，也有可能以CRITICAL的严重程度失败。

延迟时间
失败
警告

副本数量
失败
严重故障

在决定是继续执行操作、暂停、回滚还是升级处理时，这些信息非常重要。

区分强制性约束条件与建议性约束条件

有些要求决定了某个操作是否可以被接受；而另一些要求虽然能提供有用的提示信息，但并不会阻止操作的执行。

这与“严重程度”这个概念是不同的。“严重程度”用于描述故障带来的影响，而“约束模式”则用来说明某条规则是否会影响最终的合规性判断。对于REQUIRED类型的约束条件来说，如果它们没有通过测试，操作就无法被视为符合规范；而对于ADVISORY类型的约束条件，即使它们没有通过测试，操作仍然可能被认为是符合规范的，不过这种情况下还是应该报告故障情况。

type ConstraintMode =
  | "REQUIRED"
  | "ADVISORY";

现在，一个结果可以包含以下这些信息：

type ConstraintResult = {
  name: string;
  status: ConstraintStatus;
  severity: Severity;
  mode: ConstraintMode;
  expected?: unknown;
  observed?: unknown;
};

例如：

版本要求
必需
通过

延迟时间目标
建议性
未通过

尽管如此，整个操作可能仍然符合规范，只是会收到一个警告提示。这种表达方式比使用一个全局的布尔值要更加准确和清晰。

构建可重用的合规性评估工具

到目前为止，所有的示例都局限于特定的部署环境以及一些硬编码的检查规则。下一步的目标是将评估机制与具体的规则分离出来，这样同一个评估工具就可以用来评估不同的操作规范。

为了实现这一目标，我们可以将每一条规则表示为一个Constraint对象。每个约束条件都会包含自己的名称、严重程度、模式以及评估函数。而OperationalSpec则相当于这些约束条件的集合。

type Constraint = {
  name: string;
  severity: Severity;
  mode: ConstraintMode;
  evaluate(evidence: T): ConstraintStatus;
};

type OperationalSpec = {
  name: string;
  constraints: Constraint[];
};

然后：

function evaluateConformance(spec: OperationalSpec, evidence: T): ConstraintResult[] {
  return specconstraints.map((constraint) => ({
    name: constraint.name,
    status: constraint.evaluate(evidence),
    severity: constraint.severity,
    mode: constraint.mode,
  }));
}

规范定义了哪些内容需要被评估。

评估工具负责收集这些评估结果。它不需要了解每条约束条件的具体含义，只需执行每条约束条件的评估函数，并记录相应的状态、严重程度和模式即可。这样一来，评估引擎就可以保持通用性，而具体的操作规则仍然由规范来规定。

expected和observed这两个字段在这个简单的示例中是可选的，但在实际的生产系统中，我建议填写这些字段，或者存储与评估结果相关的证据信息，这样最终的评估结论才会具有可解释性，并且便于进行审计。

谨慎地计算合规性总结

单独查看每项评估结果固然有用，但有时也需要一个整体的总结。

type ConformanceSummary = {
  total: number;
  passed: number;
  failed: number;
  unknown: number;
  conformant: boolean;
};

然后：

function summarize(results: ConstraintResult[]): ConformanceSummary {
  const required = results.filter((result) => result.mode === "REQUIRED");

  const passed = results.filter((result) => result.status === "PASS").length;

  const failed = results.filter((result) => result.status === "FAIL").length;

  const unknown = results.filter((result) => result.status === "UNKNOWN").length;

  const conformant = required.every((result) => result.status === "PASS");

  return {
    total: results.length,
    passed,
    failed,
    unknown,
    conformant,
  };
}

现在，要判断整体是否符合要求，就必须确保所有必要的约束条件都通过评估。

需要注意：every()方法会检查所有的必要约束条件是否都处于“PASS”状态；因此，如果某个必要的约束条件缺乏相应的评估证据，那么整个系统的评估结果就会被视为不合格，而不会被悄悄地视为合格。

建议性的约束条件也会出现在报告中，但它们并不会影响最终的评估结论。

为什么单一的评分标准可能带来风险

人们很容易想要创建一个统一的评分标准：

合规性 = 92%

但这样的做法可能会产生误导。

假设如下：

9项低风险约束要求得到满足，
1项关键安全约束要求未通过

如果使用简单的评分方法，结果会显示为：

合规性为90%

但在实际操作中，这种结果可能是完全不可接受的。

在计算评分时，应该保留以下信息：

保留形成评分结果的证据
合规性评估的结果不应仅仅显示“未通过”，而应保留导致该结果的所有相关证据。
{
  "constraint": "最小副本数量",
  "expected": ">= 3",
  "observed": 2,
  "status": "FAIL",
  "severity": "CRITICAL"
}
这样人们就可以追问：
合规性评估结果应当具有可重现性
假设某项操作在10:00执行完毕。
10:01时，该操作的错误率为：
0.6%
而到了14:00，仪表盘显示的错误率却变成了：
2.1%
如果使用当前的监控数据重新评估这项操作，结果可能会不同。
因此，合规性评估应当基于与操作执行期间相关的证据来进行。所谓“操作执行期间”，指的是该操作运行的整个过程以及其直接产生的效果被检测到的那段时间。例如，对于在10:00完成的某项部署任务，应该使用10:00到10:05这段时间内收集的监控数据来评估其合规性，而不是几小时后仪表盘上显示的数据。
关键在于将评估结果与当时可获取的证据紧密关联起来。否则，系统中后续发生的变更就可能会改变已经完成的操作的评估结果。
一个具有可重现性的评估记录应该包含以下信息：
{
  "executionId": "deploy-812",
  "specVersion": "3",
  "evaluatedAt": "2026-10-06T10:01:00Z",
  "evidence": {
    "version": "v42",
    "replicas": 3,
    "errorRate": 0.006,
    "p95LatencyMs": 290
  }
}
这样，之后就可以根据这些记录重新进行评估了。
这一原则如何适用于多个执行器
假设有两个执行器运行相同的规范。
执行器A：
版本      合格
副本数量     合格
错误率       合格
延迟时间      合格
执行器B：
版本      合格
副本数量     不合格
错误率       合格
延迟时间      合格
现在的问题不再是：

哪个执行器更好？

当前需要回答的是：

哪次执行符合规范要求？

我们可以通过对每个执行器产生的结果使用相同的合规性评估工具来进行判断。规范和评估规则保持不变，只有生成的结果会发生变化。
在上面的例子中，执行器A符合规范要求，因为所有的约束条件都评估为“合格”；而执行器B则不符合，因为其副本数量的约束条件被评估为“不合格”。这样一来，我们就有了一个统一的比较标准，而不需要这两个执行器使用相同的内部处理流程。
随着时间的推移，我们还可以通过合规性比率、失败类型、延迟时间、成本、恢复频率以及未知结果的出现率等指标来对比不同执行器的性能。但合规性评估始终是处于契约层面的评价标准。
这一原则在AI智能体中的应用
对于AI智能体而言，合规性的要求尤为重要。
同一个目标可能有多种实现方案可供选择。
智能体执行方案1：
扩展规模
进行部署
进行观察
规划路径

智能体执行方案2：
先部署测试版本
然后进行观察
再进一步扩展
由于智能体每次都可以选择不同的执行方案，因此逐步骤地对比这些执行过程并没有太大意义。一次执行可能采用测试版本来进行部署，而另一次则创建并行环境来完成任务，但这两种方法都可能是实现同一目标的合法途径。
唯一不变的是规范本身：目标、约束条件以及结果评估标准不会因为智能体选择了不同的实施路径而发生变化。
每次执行完成后，系统都会收集关于最终状态的数据。随后，合规性评估工具会将这些数据与之前所有执行中使用的相同规范进行对比。这样一来，智能体就可以灵活地调整执行方案，同时成功的定义仍然独立于智能体本身。
规范              ↓
AI智能体            ↓
动态执行计划        ↓
实际执行过程       ↓
生成的结果数据     ↓
合规性评估结果    ↓
智能体可以提出各种行动方案，但是否这些行动能够达到预期目标，不应该仅由智能体自己来决定。
一个简单的端到端示例
首先定义结果数据的结构：
type DeploymentEvidence = {
  version?: string;
  replicas?: number;
  errorRate?: number;
  p95LatencyMs?: number;
};

接下来定义各种约束条件：
const constraints:
  Constraint[] = [
    {
      name: "version",
      severity: "CRITICAL",
      mode: "REQUIRED",
      evaluate: (evidence) => {
        if (!evidence.version) {
          return "UNKNOWN";
        }

        return (
          evidence.version === "v42"
        )
          ? "PASS"
          : "FAIL";
      },
    },
    {
      name: "replicas",
      severity: "CRITICAL",
      mode: "REQUIRED",
      evaluate: (evidence) => {
        if (
          evidence.replicas === undefined
        ) {
          return "UNKNOWN";
        }

        return (
          evidence.replicas >= 3
        )
          ? "PASS"
          : "FAIL";
      },
    },
    {
      name: "error-rate",
      severity: "CRITICAL",
      mode: "REQUIRED",
      evaluate: (evidence) => {
        if (
          evidence.errorRate === undefined
        ) {
          return "UNKNOWN";
        }

        return (
          evidence.errorRate <= 0.01
        )
          ? "PASS"
          : "FAIL";
      },
    },
    {
      name: "latency-target",
      severity: "WARNING",
      mode: "ADVISORY",
      evaluate: (evidence) => {
        if (
          evidence.p95LatencyMs === undefined
        ) {
          return "UNKNOWN";
        }

        return (
          evidence.p95LatencyMs <= 350
        )
          ? "PASS"
          : "FAIL";
      },
    },
  ];

创建规范：
const deploymentSpec:
  OperationalSpec = {
    name: "deploy-orders-v42",
    constraints,
  };

进行评估：
const evidence:
  DeploymentEvidence = {
    version: "v42",
    replicas: 3,
    errorRate: 0.004,
    p95LatencyMs: 370,
  };

const results =
  evaluateConformance(
    deploymentSpec,
    evidence
  );

const summary =
  summarize(results);

评估结果可能如下：
version          PASS     REQUIRED
replicas         PASS     REQUIRED
error-rate       PASS     REQUIRED
latency-target   FAIL     ADVISORY

同时，
conformant = true

所有强制性的约束条件都得到了满足。不过，建议性的延迟目标未通过评估，因此系统仍应显示警告信息。
实用的合规性评估流程
如果想要在现有系统中引入合规性评估机制，可以按照以下步骤操作：

  
选择一项需要评估的操作。
  
定义相应的规范要求。
  
将各项约束条件分为“强制性”或“建议性”两类。
  
为这些约束条件设定相应的严重性等级。
  
明确证据收集的具体方式。
  
规定如何处理缺失的证据，使其被标记为“UNKNOWN”。
  
逐一评估各项约束条件的满足情况。
  
生成最终的评估结果摘要。
  
保存所有的评估证据数据。
  
对规范文件进行版本管理。
  
重新审查那些会导致异常失败或结果为“UNKNOWN”的规则。
不要仅仅为了让测试结果通过而削弱规范的要求。
合规性无法证明什么
合规性能够告诉你：

观察到的证据符合规范要求。

但它无法自动证明：

该规范本身是否正确。

规范可能是错误的，收集到的证据也可能存在问题。
因此，合规性的判断取决于以下因素：
规范的质量
证据的质量
评估的准确性

合规性只是一种验证机制，并非绝对真理。
从执行成功到可验证的操作
传统的自动化流程通常到这里就结束了：
执行
↓
成功 / 失败

而基于合规性的模型则增加了更多的结构层次：
规范
↓
执行器
↓
执行过程
↓>收集证据
↓>进行约束条件评估
↓>判断是否符合规范要求

现在你可以提出以下问题：

哪些要求得到了满足？


哪些要求没有达到标准？


有哪些要求无法被评估或验证？


哪些证据支持了最终的判断结果？

如果系统在执行后立即符合规范要求，那么你就获得了一个基准点。
从这个基准点出发，你可以持续观察系统的运行情况。
接下来再问：

当操作已经成功完成，但实际情况开始与规范要求偏离时，会发生什么？

这就是所谓的“运行偏差”现象。
结论
仅仅拥有一个能够正常执行的系统是不够的，一个状态良好的开发流程或一份完善的计划也同样不够。
真正重要的是：最终形成的系统是否满足各项操作规范的要求。
这需要三个要素：
规范
证据
评估结果

一个实用的合规性评估模型应该能够记录以下信息：
约束条件的遵守情况
通过 / 失败 / 未知结果
问题的严重程度
强制性的规则与建议性的规则
实际观测到的数值
预期的数值
证据的具体内容
规范的版本信息

执行器负责完成具体的操作，证据用于描述实际发生的情况，而规范则定义了应该发生的结果。
随后，合规性评估工具会对比这两者之间的差异。
这样的机制为传统的自动化流程以及日益自主化的系统提供了更坚实的基础。
然而，某一个时间点上的合规性并不能说明一切——一个系统现在可能符合规范要求，但日后却可能出现偏差。
下一个问题就是：

我们该如何检测到实际情况何时开始与预期目标产生偏离？

这正是我接下来想要探讨的内容。