任务完成合同

用可观察后置条件判定业务工作是否完成。

完成合同把“看起来做完”变成可观察、可核验的业务条件。研究任务可能要求每个指标有原件定位和计算过程；教学任务可能要求学生在无提示下解出迁移题；外部执行任务可能要求目标系统出现正确状态。不同任务的完成证据不同，不能用一个语言评分覆盖全部场景。

模型输出完成声明只能触发verification。工具返回HTTP 200可能只说明受理请求；文件存在可能仍为空、损坏或使用了错误资料。Task应保存验收版本和逐项结果，把产物生成、验证通过与真正交付分开。若报告已经生成但客户投递失败，应展示两个状态，不能因为文本写得好就把整个任务标成功。

设计验收时，把确定性条件交给程序：公式复算、文件格式、目标记录、数量和权限；把解释质量交给校准过的judge或专家；把学习保持、投资结果等长期效果交给独立观察。验证器可以共享工具，但不应只是复述主Agent的自评。对于不可自动验证的关键结论，应保留未知和人工复核点。

成功、失败、取消、受阻与部分完成应有不同含义。预算耗尽时输出已完成项和证据缺口，是可解释结束，不能改写成成功。测试故意制造“API受理未落地”“引用存在但语境不支持”“文件生成但内容错版”等反例，并确认系统拒绝提前通过。完成合同越具体，Agent选择工具和停止的行为才越容易评测。

验收不应只验证正例。一个财报值可能存在于真实页面，却属于错误公司或期间；一个法律引用可能真实存在，却已经被后续权威限制；一道题的答案可能正确，却是提示后照抄。将这些“形式通过、业务不成立”的反例加入测试，才能避免完成条件被模型以表面方式满足。

实践重点：验收条件由业务定义，模型仅生成完成候选；独立验证通过后提交成功。

验证抓手：故意让工具返回受理但未生效，检查Task是否拒绝提前成功。

常见误区：用流畅答案、HTTP 200或模型自评替代外部结果。

Anthropic：长期任务Harness；Temporal：执行状态与外部副作用。