长任务模型的分水岭，不是能跑多久，而是会不会主动验证
模型能连续工作几小时，听起来像 Agent 成熟的标志。但运行时间本身不是价值。一个错误方向坚持得更久，只会制造更大的修改面、更难审查的提交和更昂贵的回滚。
真正的分水岭是模型是否会主动建立证据：打开页面检查布局、运行测试复现 bug、构造缺失的验证环境、对照需求检查边界，并在证据不足时承认没有完成。
计划能力和验证能力必须分开看
长任务至少有四个循环：
理解目标 → 制定计划 → 执行修改 → 验证结果
↑ ↓
└── 根据证据修订 ──┘
很多 Agent 在前三步表现很好：能拆任务、能改多个文件、能调用工具。失败通常发生在第四步：
- 测试只跑了最容易通过的部分；
- 页面生成后没有真实渲染；
- 修复了报错文本，没有修复根因；
- 只检查返回码，没有检查业务结果；
- 看到一次成功就停止；
- 把自己写的计划当成验收标准。
“主动验证”包含哪些行为
构造可观测证据
如果没有现成测试，模型会不会写最小复现、添加日志、生成对照输入，或使用浏览器和设备查看真实结果？
区分表面症状与根因
修复一个 null pointer 很容易；解释为什么状态本来不应该为空、还有哪些入口会产生同样状态，才是根因分析。
使用独立路径交叉检查
同一段代码生成结果后，再让同一个提示问“你做对了吗”并不独立。更强的验证包括：
- 编译器、类型系统和测试；
- 浏览器像素/DOM/控制台；
- 数据库约束与查询结果；
- 第二实现或基线程序；
- 静态分析与运行时观测；
- 人工批准。
管理不确定性
模型应能区分已验证、合理推断和未验证。无法访问生产环境时，正确做法是留下明确待验证项，而不是用本地结果宣称线上完成。
验证也需要预算
无限测试会让任务无法结束。运行时应为不同风险设置验证预算：
| 风险 | 最低验证 |
|---|---|
| 文档与注释 | 格式、链接、事实抽查 |
| 小型代码修改 | 目标测试 + 静态检查 |
| 跨模块改造 | 单测、集成、关键路径回归 |
| 数据迁移 | 预演、行数/约束、备份、回滚 |
| 发布与权限 | 影子验证、审批、灰度、线上观测 |
预算不是只限制 token，也限制外部副作用、运行时间、工具次数和允许修改的范围。
检查点让长任务可恢复
长任务不应依赖一条不断增长的对话。每完成一个可验证阶段，就保存：
- 当前目标与已完成条件；
- 修改文件和关键差异；
- 已运行的验证及结果；
- 未解决问题；
- 环境与依赖状态；
- 下一步和回滚点。
发生网络、工具或模型中断时，从最近检查点恢复，而不是重新阅读全部历史并猜测状态。
检查点也便于人工审查：审查者可以在风险上升前介入，而不是等 Agent 提交一个巨大结果。
如何评测长任务模型
不要只用“最终测试是否通过”。建议同时记录：
最终任务成功率
一次通过率
根因修复率
新增回归数
验证工具调用占比
错误宣布完成率
人工接管点
修改规模与有效修改比例
运行间方差
同一任务至少重复多次。平均水平高但方差巨大，不适合直接进入生产。
还要设计诱导项：缺失测试、误导性错误信息、过期文档、局部修复能通过但会破坏另一入口。它们能区分“会写代码”和“会完成工程任务”。
生产 harness 的五条约束
- 完成条件外置：由任务规范和验证器定义，不由模型自行决定。
- 高风险动作审批：发布、删除、转账、权限变更必须独立授权。
- 工具结果结构化：测试、部署和查询返回机器可判定状态。
- 失败可恢复：幂等、检查点、重试上限和回滚路径齐全。
- 证据可审计：保留命令、产物、测试和外部状态，而不是只保留总结。
模型更强后，人要做什么
人工不需要逐行盯住所有操作，而应把精力放在：
- 定义目标和不可越过的边界；
- 设计验证器；
- 审批不可逆动作；
- 处理需求冲突和业务判断；
- 复盘模型反复失败的模式。
Agent 自治不是把人从系统里删除，而是把人从重复执行者变成目标、边界与证据的负责人。
长任务真正值得信任的信号，不是模型说“我已经仔细检查”，而是系统里留下了别人可以重复的证据。