AI工作流验收：用强制检查守住关键环节

AI智能体可以把一个工作流的大部分配置都做对，却仍然留下一个损坏的必要审批环节。如果你的评估报告只给出一个平均分，这种失败很容易被一个漂亮的数字悄悄掩盖。

OpenAI 10月6日发布的研究《Advancing computer use with Ironclad》把这个问题变成了一个具体的工程挑战。研究人员与实际从业者合作，在法律、商务和采购场景中定义了11项任务，每项任务配备8到50条评估标准。

报告显示，GPT-6 Astra在Max推理模式下的平均评分标准得分为55.0%，GPT-5.6 Sol在High推理模式下为41.6%。需要注意的是，这些平均分描述的是"满足了多少条标准"，而非"完美完成了多少个工作流"。报告中19.2分钟对比37.0分钟的单次尝试耗时是模拟估算值，不是实测的客户节省时间。而这些结果只覆盖那11项研究任务，并不代表所有Ironclad工作流。

从这项研究中可以提炼出一个关键的实现思路：把衡量进展的"分数"与允许工作流投入使用的"条件"分离开来。下面介绍的设计模式是一种建议方案，并非对Ironclad实际实现的描述。

从带版本号的需求开始

假设有一条虚构的采购政策：金额严格超过1万美元（不含税）时需要财务审批。真正的流程负责人需要确认这些细节，它们不应该由智能体凭空编造。

为了便于处理，用"分"来表示金额，于是边界值就是1,000,000。接着定义可观测的测试案例：

• 999,999分走普通流程。
• 1,000,000分同样走普通流程，因为规则说的是"严格超过"。
• 1,000,001分需要财务审批。
• 金额缺失时应保持"未完成"状态，而不是悄悄走普通流程。
• 编辑已有请求使其跨越边界时，应触发负责人指定的审查行为。

后两种情况属于补充提出的需求，在实现前需要达成一致。它们存在的意义是暴露模糊地带，而不是把一个假设直接变成政策。

把这些确认过的案例绑定到某个配置版本上。昨天那套配置下的通过记录，不应该为今天已改动的配置背书。

让强制检查保持独立

评分标准可以衡量有用的标签、文档质量和配置细节。保留这个分数用于横向对比和调试。但要单独维护一组由流程负责人选定的强制检查ID。

下面是一个针对可信测试运行器所收集观测结果的Python校验函数。它只接受带有证据引用、且针对指定版本的明确通过。缺失、过期或结果不明确的观测，一律视为"未验证"。

def acceptance(required, observations, version):
    if not required:
        raise ValueError("Define mandatory checks before evaluation")

    failed = []
    unverified = []
    for check_id in sorted(required):
        row = observations.get(check_id)
        if (not row or row.get("version") != version
                or not row.get("evidence")):
            unverified.append(check_id)
        elif row.get("status") == "fail":
            failed.append(check_id)
        elif row.get("status") != "pass":
            unverified.append(check_id)

    return {
        "ready": not failed and not unverified,
        "failed": failed,
        "unverified": unverified,
    }

这个决策中刻意没有引入任何聚合分数。可选检查项得分再高，也无法抵消一个失败的强制检查。失败和未验证两种状态都会阻止ready变为真，同时在报告中保持彼此区分。

下面是一组展示该校验行为的合成测试数据——它们是用于演示的fixture，并非来自真实工作流的证据：

required = {"above_threshold", "missing_amount"}
observations = {
    "above_threshold": {
        "status": "pass",
        "version": "config-7",
        "evidence": "fixture:above-threshold",
    }
}

result = acceptance(required, observations, "config-7")
assert result["ready"] is False
assert result["unverified"] == ["missing_amount"]

空的强制检查集合会直接抛出错误，因为一个不小心变空的清单绝不应该产生"通过"的结果。遇到预期之外的状态同样标记为未验证。这个函数假设输入映射遵循既定结构，对于不可信的输入，应在调用前的边界处完成校验。

这种"强制检查与评分分离"的思路，在软件质量保证领域有对应的先例：持续集成（CI）流水线通常区分"阻断性测试"（blocking tests）和"信息性指标"（informational metrics）。前者一旦失败即阻止代码合并，后者仅供趋势分析。将同样的模式引入AI智能体验收，本质上是把"质量门控"（quality gate）的概念从代码部署迁移到工作流配置部署。质量门控的核心原则是：通过标准必须在运行前明确定义，且不能被运行结果的整体表现所覆盖——这正是 acceptance() 函数中 required 为空时直接抛出异常、而非返回通过的设计原因。

在智能体的"叙述"之外收集观测

上面的校验函数检查的是引用和状态，它并不能证明被引用的产物真实存在，也不能证明结果为真。如果同一个智能体既能编造观测结果，又能改写强制检查集合，那么这道关卡几乎提供不了任何保障。

正确做法是让一个独立的测试控制器在安全环境中提交已知请求，然后读取由此产生的路由或审批状态。保存请求ID、被测配置版本、输入、预期结果、实际结果以及支撑证据。在把结果交给校验函数之前，先确认证据引用能够解析到该精确案例与版本对应的观测记录。

当视觉上下文重要时可以使用截图，但也要同时捕获实际的结果状态。编辑器里一条规则的截图，确立的是"配置长什么样"；而一个被实际路由的测试请求，确立的是另一件事——"这套配置针对某个输入的实际行为"。

把失败保存为可复现的案例。"智能体漏了一些步骤"很难调试，而"把已保存请求从900,000分改到1,100,000分后未触发财务审查"则清晰描述了一次输入变化和一个可观测的缺陷。

这里指出的风险在安全领域被称为"自证问题"（self-attestation problem）：当一个系统既能产生被评估的行为，又能影响评估记录本身时，评估结果的可信度就会崩塌。独立测试控制器的作用类似于审计中的"职责分离"原则（separation of duties）——提交测试输入、读取系统输出和记录证据的角色，必须在逻辑上独立于被测智能体。对于计算机使用（computer use）场景，这一点尤为重要：智能体可以直接操作界面，因此理论上有能力在屏幕截图中制造符合预期的视觉状态，而底层路由逻辑实际上并未按预期执行。依赖实际的路由或审批状态字段，而非仅依赖截图，是绕开这一风险的关键措施。

变更之后要重新检查

每次配置变更后，都要为强制案例重新收集新的观测结果。不要仅仅因为可见的表单看起来没变，就复用旧的通过记录。审批路由可能依赖于截图无法揭示的字段、条件或后续编辑。

对于首个试点，一个精简的强制检查套件比一大堆含糊的检查项更有用。当负责人识别出新需求、或某次失败暴露出遗漏的边界时，再逐步添加案例。同时持续追踪更宽泛的评分标准，这样你就能看到那些尚不足以构成"验收通过"、但确有改善的进展。

还要记录达成可验收结果所需的人力投入：准备、审查、修复和反复测试的时间。把这些测量值与模型执行时间、以及研究中的模拟耗时严格区分开来。

OpenAI的报告明确保留了人工监督在复杂合同场景中的角色。这里提出的校验机制并不打算取代这份责任，它只是让负责人更清楚地看到：什么通过了、什么失败了、还有什么尚未被任何人验证。

从一个工作流、一个各方认可的规则版本和几个有意义的案例开始。可靠的验收决策，始于对"系统完成后必须做到什么"的精确定义。