在 Agent 系统里，最危险的状态不一定是报错，而是"看起来完成了"。
模型说"已整理资料、生成文档并通知相关人员"，但文档在哪里？数据来自哪一次查询？通知是草稿还是已经发送？有没有跳过无法登录的系统？如果这些问题还要靠人继续追问，任务就没有真正进入可验收状态。
一个更稳妥的做法，是在任务开始前定义验收契约，在任务结束时强制生成完成回执。它不替代日志，而是把分散在日志、文件和工具返回值里的关键信息压缩成一个稳定接口。
"完成"需要五个字段
json
{
"task_id": "content-20260911-1830",
"status": "needs_review",
"deliverables": [],
"evidence": [],
"risks": [],
"next_actions": []
}1. deliverables：交付物
这里记录最终产物，而不是执行动作。比如"生成文章"不是交付物，"article.md，SHA-256 为......，共 1872 字"才是。
每个交付物至少要有类型、位置、版本和摘要。文件被覆盖、页面仍是草稿、数据库只写入了一部分，都应在这里显式体现。
2. evidence：证据
证据回答"为什么相信它完成了"。它可以是测试报告、工具返回的对象 ID、截图、校验和、查询时间或审批记录。
日志不能直接等同于证据。日志通常描述"尝试过什么"，而验收证据需要证明"结果现在是什么"。例如上传动作返回 200，只能证明请求成功；若要证明目标文件可用，还需要读取元数据或校验文件哈希。
3. status：状态
建议至少区分三态：
completed：所有自动验收条件通过，不再需要人工动作。needs_review：产物已准备好，但发布、付款、发送等外部影响操作等待人工确认。blocked：关键依赖缺失，继续运行不会自动解除。
这三个状态不能混用。尤其不要把"草稿已预填"写成"文章已发布"，也不要把"等待验证码"写成"任务失败"。
4. risks：风险与缺口
风险字段要短、具体、可行动。比如"标签未匹配，候选集为空"，优于"平台可能有问题"；"数据采样时间为 18:30，阅读量缺失"，优于"数据不完整"。
风险不应藏在长篇总结的最后一段。它必须是结构化字段，才能被监控系统、任务看板或下一位 Agent 消费。
5. next_actions：下一步
下一步用于说明谁在什么条件下做什么。一个合格动作通常包含 owner、action 和 condition：
json
{
"owner": "human",
"action": "核对标签与分类后手动发布",
"condition": "编辑页字段完整且预览无误"
}这样，Agent 的结束就不是把责任抛回聊天框，而是完成一次明确交接。
把验收契约放进状态机
任务状态机可以简化为：
running -> validating -> completed | needs_review | blocked
关键在 validating。Agent 在这一阶段不继续扩张任务，而是逐项检查：交付物是否存在、证据是否能定位、外部动作是否越过确认边界、风险是否会影响结论、下一步是否有明确责任人。
对于可重复执行的任务，还应加入幂等键。相同 task_id 已存在有效交付物时，系统应继续补齐或校验，而不是重新创建一份难以区分的新草稿。
四个常见反模式
第一，把过程当结果。"调用了写作工具"不代表文章已生成，"打开编辑器"不代表字段已预填。
第二，把一句自然语言总结当状态。长文本对人友好，却很难被调度器可靠判断。
第三，只报告成功，不报告缺失。越是自动化程度高，越需要把未验证项列出来。
第四，验收规则在任务结束后才临时决定。更好的顺序是先写验收条件，再执行，再用同一条件收尾。
最小落地清单
如果只做第一版，可以从六件事开始：固定任务号；保存交付物位置；为每个关键结论绑定证据；使用三态状态；列出风险与缺失；把外部影响动作统一放入人工确认门。
AI 员工真正进入团队工作流，不是因为它能连续输出更多文字，而是因为它能把工作交到一个可检查、可继续、可追责的位置。Tipkay 在部分内容岗位中也采用"预填后由用户确认"的边界；无论使用哪种 Agent，验收契约都应由任务本身定义，而不是依赖一句"相信我，已经完成"。