生活类比：餐厅后厨
厨师连续做菜 8 小时，只能证明厨房没有停。是否能出餐，还要看订单、温度、过敏原和最终品控。
哪里不像：软件任务可以自动回滚与重放，真实餐食通常不能。
Agent Acceptance · 零基础速通讲义
让 Agent 跑得久，更要交得对。
你将用 30 分钟搭起一个能让 Codex 等 Agent 持续工作、用外部证据证明结果、在停滞或越权前自动停下的最小系统。
CHAPTER 01 · 5 MIN
先改掉一个错误目标
很多人问：“怎样让 Agent 无人值守地跑 8 小时？”这个问题少了后半句：8 小时后，谁来证明它交付的是正确结果？
运行得久≠交付可靠
工程对应
Agent 是执行者；验收契约是订单；测试与真实操作是温度计；独立评价器是品控；预算和停止条件是总控台。
读完你能做什么
- 把模糊任务改写成第三方可判定的验收契约。
- 区分“自动测试全绿”和“真实结果已被证明”。
- 设计可恢复的长时循环、独立评价与机械停止。
- 为功能、缺陷、重构和调研选择不同 oracle。
常见误解
误解：模型更强，就可以删掉 harness。
实际：模型能力会改变需要多少控制，但生产任务仍需要权限、证据、预算和退出条件。
CHAPTER 02 · ROUTE
30 分钟只走这五站
时间有限时，不必先读完 34 个来源。按下面顺序建立最小闭环，再去完整研究版查证。
最短结论：Ralph/循环负责“继续做”，不能负责“宣布成功”。终止权属于冻结的 criterion、指定 grader 和预算控制器。
CHAPTER 03 · CONTRACT
一份好验收标准，必须回答八个问题
验收标准不是“代码看起来不错”，也不是把实现步骤写死。它描述可观察结果，并额外固定安全、证据和运行边界。
1 结果用户最终能做什么？
2 边界允许与禁止修改什么？
3 不变量哪些旧行为必须保持？
4 判定器谁用什么 oracle 判断？
5 证据命令、日志、截图放哪里？
6 独立性怎样避免自己给自己打分？
7 运行预算、重试、停止、恢复？
8 回执最终交接包含哪些事实？
坏标准 → 可验收标准
坏：“实现头像上传，代码优雅，测试完善。”
好：“已登录用户可上传 JPG/PNG，刷新后仍显示；超大文件和伪装扩展名被拒绝且不持久化；既有设置页、鉴权和路径安全测试继续通过；评价器在运行中的应用完成正反两条路径。”
快速自检
“使用 React 实现”是不是验收标准？
通常不是。它是实现约束。除非框架本身是兼容性或组织边界，否则验收应优先写用户可观察结果。
CHAPTER 04 · SEPARATION
三角色加一个控制器
不一定需要四个不同模型，但必须让职责和权限能被区分。最关键的一条：Builder 不能仅凭自己的总结把任务改成 PASS。
Planner冻结结果、边界、criterion、预算。
Builder每轮只完成一个可验证切片。
Evaluator新上下文、只读、亲自运行 oracle。
Controller依据机器状态继续、停止或升级。
为什么需要新上下文
像让另一位验收员只看订单和成品，而不是听厨师复述自己多努力。它不能消除偏差，但能减少沿着同一实现假设自证。
独立评价器也会错
LLM grader 可能宽松、过度挑错或被漂亮解释带偏。确定性判定优先；主观评价要用人工样本校准，并允许返回 INCONCLUSIVE。
CHAPTER 05 · EVIDENCE
先过便宜的门，再做昂贵的验证
每个切片都跑全量 E2E 会很慢，只跑单测又容易“绿而不真”。分层门禁让反馈速度和证据强度同时可控。
G0
契约就绪任务可解，每条 criterion 有 oracle、证据、grader。
开工前G1
基线可归因修改前先复现或冒烟，保存历史失败。
新工作区G2
切片完整一轮一项，不混入无关重构。
每轮G3
确定性检查编译、类型、lint、定向测试、结构与安全规则。
每轮G4
真实路径 + 负向控制运行应用，并证明错误输入真的失败。
行为变化G5
独立评价只读 evaluator 亲自执行判定器。
每条标准G6
批次集成全量回归、跨切片不变量、脏工作区与孤儿文件。
合并前G7
最终回执范围、证据、风险、回滚点、未完成与人工待决。
退出前证据不是二元的
E0自述/解释，只证明意图
E1diff、类型、lint、结构
E2定向测试与可复现实验
E3真实路径与负向控制
E4独立评价、全量回归、人工风险批准
“几百个测试全绿”为什么仍可能是假的？
Agent 可能弱化断言、改 fixture、增加只返回预期值的 mock，或测试根本没有经过新增代码。防线是：测试变更单独审查、路径覆盖证据和一个应当失败的 negative control。
CHAPTER 06 · LONG RUN
上下文会消失，任务状态不能消失
长时自主不是把一个对话无限拉长，而是让新会话能从外部状态可靠接班。
repo/ ├─ AGENTS.md # 地图，不是百科全书 ├─ docs/ACCEPTANCE.md # 冻结的人类可读验收契约 ├─ .agent/acceptance.json # 机器状态，初始全部 FAIL ├─ .agent/PROGRESS.md # 已做 / 下一步 / 失败签名 ├─ .agent/DECISIONS.md # 为什么这样做 ├─ .agent/evidence/ # 日志、截图、命令与轨迹 ├─ .agent/STEER.md # 人类引导 ├─ .agent/STOP # 优雅停止开关 └─ RUN_RECEIPT.md # 最终交接
四种机械停止
成功
mandatory 全部 PASS，集成门与回执完整。
预算
达到时间、轮次、成本、磁盘或 API 限额。
停滞
连续 2 轮无有效 diff，或同一失败签名连续 3 次。
边界
需要未授权权限、破坏性动作、外部协调或证据不足。
while budget.remaining and not STOP.exists:
criterion = first_mandatory_false()
builder.run_one_slice(criterion)
deterministic_gates.run()
fresh_readonly_evaluator.verify(criterion)
controller.check_progress_signature()
checkpoint_state_and_evidence()
这是控制协议伪代码，不是无限执行脚本。实际 runner 还要处理进程树、锁、心跳、磁盘上限和秘密隔离。
CHAPTER 07 · WORKED EXAMPLE
完整演练：让头像上传任务安全跑一晚
贯穿例子从模糊需求开始，逐步变成 Agent 可执行、Evaluator 可证伪、Controller 可停止的任务。
| 阶段 | 具体做法 | 产生的证据 |
|---|---|---|
| 冻结结果 | 合法图片上传并持久化；超大和伪装扩展名拒绝。 | C01–C04 = FAIL |
| 基线 | 登录、设置页、上传 API 冒烟；保存既有失败。 | baseline 日志、commit |
| 最小切片 | 先实现服务端格式/大小校验，不同时重构认证。 | 紧凑 diff、定向测试 |
| 真实路径 | 在运行中的页面上传合法图并刷新，再上传伪装文件。 | 操作轨迹、请求、存储前后状态 |
| 负向控制 | 把校验临时指向错误阈值，确认测试会失败后恢复。 | grader 有识别失败的能力 |
| 独立评价 | 新上下文只读检查目标 commit，逐条更新状态。 | 状态、理由、证据 URI |
| 集成与退出 | 全量回归、路径安全检查、最终回执。 | 全部通过才 PASS |
判断题：如果 UI 上传成功，但刷新后恢复旧头像，任务完成了吗？
没有。核心用户结果明确要求持久化；表面成功不能替代刷新后的真实状态。
没有。核心用户结果明确要求持久化；表面成功不能替代刷新后的真实状态。
CHAPTER 08 · SELF-CHECK
你已经能启动第一个受控任务了吗？
问题 1：谁可以把 criterion 从 FAIL 改成 PASS？
指定的 grader。确定性条件由程序判定；主观条件由经过标定的独立评价器或人判定。Builder 的总结不是证据。
问题 2：什么时候应该让 Agent 继续重试？
只有失败产生了新诊断或新证据路径、仍在预算内、且没有触及权限边界时。原样重复同一失败不是进展。
问题 3：高风险部署可以完全无人值守吗？
准备、验证和回滚演练可以高度自治；真正改变生产、权限、数据或对外发送的动作需要明确批准。
启动前 10 项
- 用户结果可被第三方观察。
- 范围、禁区、写区与非目标清楚。
- mandatory criterion 初始为 FAIL。
- 每条标准有 oracle、证据、grader 和阈值。
- 修改前保存基线或原故障复现。
- 至少有一个负向控制。
- Builder 与 Evaluator 的上下文或权限隔离。
- 预算、停滞阈值和人工 STOP 已固定。
- 高风险动作有批准与回滚点。
- 最终回执不会只写“已完成”。
CHAPTER 09 · FULL RESEARCH
没有删掉原内容：完整研究版在这里
这份速通讲义重排了学习顺序，但没有替代原研究。下面四页按原始文件完整保留，可用于查来源、生成契约和落地运行。
CHAPTER 10 · SOURCE & BOUNDARY
来源、事实与这份讲义的边界
直接材料：《Agent 长时自主交付验收研究》四页 HTML，研究快照为 2026-08-01，包含 34 个公开来源与 6 个视频入口。
教学重建：本页按“错误目标 → 验收契约 → 角色分离 → 证据门禁 → 运行控制 → 完整演练”重排，并增加餐厅类比、头像上传贯穿案例和自检题。类比只帮助理解，不是技术机制本身。
事实边界：OpenAI、Anthropic、METR 和社区案例的数字均有各自任务与时间边界。社区自报不能证明普遍成功率；产品能力在 2026-08-01 之后可能变化。
版权与署名：本专题以“知萃研究整理”署名发布，原创整理与交互页面来自用户提供的研究包；外部资料版权归各来源所有，页面只做摘要、转述与链接。内容所有者已于 2026-08-02 确认授权公开发布。