先区分验收要求与运行证据

V1 验收文档要求六类场景全部通过同一命令与事件接口,不能用内部函数测试替代。但文档中的“必须通过”是要求,不是某次运行已经通过的证明。1

本页阅读的是 1f2270eaa31ba099837375bfcdfd162c8f31f1b9 的测试断言。以下“预期”均指测试中的预期,不代表本次启动了真实 Agent。

回放与并发:状态必须来自同一段历史

Task Repository 契约同时用于内存与文件系统适配器。一个测试追加阶段事件后重新 load,要求重建结果与追加结果相同;另一个测试让两个调用使用相同 expectedVersion,要求恰好一个成功、另一个报版本过期。2

version 1
  + append A(expectedVersion=1) -> accepted -> version 2
  + append B(expectedVersion=1) -> stale version

load(events) -> same snapshot as accepted append

示意不指定谁赢得竞争。这个实验检验不会静默覆盖,不证明任意磁盘故障、文件系统或远程共享存储都具有同等可靠性。

权限:让模型尝试越过自己的边界

MCP 测试不是只检查 schema 有哪些工具,还实际请求未开放的用户动作。外部写意图使任务进入 awaiting_approval 后,模型调用 approve 失败;请求 pause、steer、cancel 也不能代替用户控制。宿主身份由服务器配置注入,不能由工具参数伪造。3

输入测试要求观察到的结果不证明什么
外部写入意图记录策略判断并等待审批外部系统已执行操作
MCP 调用 approve返回错误,仍等待审批CLI 用户一定作出了正确决定
伪造 actor / caller工具 schema 不接受自报身份操作系统本身不存在被攻破风险
未授权用户控制命令不改变运行任务任意第三方 MCP 服务同样安全

这种测试保留了确认成本,而不是为了“全流程自动通过”删掉停点。

预算:暂停不能产生新的额度

预算测试固定时钟,先取得 deadline,暂停再恢复,要求 deadline 原样保留。Generator 达到轮次上限时,记录 budget.exhausted,任务状态为 partial,风险中说明耗尽项。4

观察重点不是抛出了哪个异常,而是剩余工作仍可读,且没有被标成 completed。代价是任务可能交付部分结果;这比无界返工或伪造完成更符合预算契约。

交付:已经就绪,也必须再次授权

交付包测试要求 requires_confirmation: true 与 allowed_automatically: false。更具体的交付动作测试覆盖提交过程中的取消,以及两个动作竞争同一工作区锁。5

取消测试检查 HEAD 没有变化、暂存区为空、没有 delivery.action_applied,并留下动作被替代的记录。并发测试要求第二个动作在第一个持锁时被拒绝。它们针对所构造的本地执行窗口,不是对任意远程 push 或外部服务回滚的保证。

真实宿主仍需独立运行

在匹配的上游环境中,README 给出下面的仓库检查入口:

npm test
npm run typecheck
npm run build

真实 Codex / Claude Code smoke 另外依赖本机 CLI、认证与受支持环境。缺少认证应报告 dependency_unavailable 或明确 skip,不能算成功。本文不提供已运行数量,也不把网站构建通过算到 Harness 的验收成绩中。6

从这些实验回看设计页,控制层的价值不是保证 Agent 永不失败,而是让失败、暂停、越权和完成保持不同语义。技术页解释这些结果怎样由命令、事件和工作流产生。

来源与范围

本次未重跑上述上游测试,未执行安装、真实宿主或交付动作;这里的可核验材料是固定修订测试源码。进一步验证应记录环境、依赖版本、命令、实际结果及未执行项,不能把测试名当作运行报告。

参考资料

  1. 端到端验收要求。 ↩

  2. 仓储契约测试。 ↩

  3. MCP 身份、审批与控制测试。 ↩

  4. 预算测试。 ↩

  5. 交付包测试;交付动作取消与串行化。 ↩

  6. 验证入口与 smoke 边界。 ↩