先区分验收要求与运行证据
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 永不失败,而是让失败、暂停、越权和完成保持不同语义。技术页解释这些结果怎样由命令、事件和工作流产生。
来源与范围
本次未重跑上述上游测试,未执行安装、真实宿主或交付动作;这里的可核验材料是固定修订测试源码。进一步验证应记录环境、依赖版本、命令、实际结果及未执行项,不能把测试名当作运行报告。