📖 本文首发于微信公众号「Wesley AI 日记」，更多 AI Agent 实战系列请微信搜索关注。
AI Agent 说"完成了"，但其实没有------任务验收机制的工程实践
你有没有遇到过这种情况：
给 AI Agent 分配了一个任务，它很快回复"任务已完成"。你打开系统一看------什么都没变。
我遇到过太多次了。不是 Agent 在撒谎，而是它真的"以为"自己完成了。
这篇文章，我把这个问题彻底拆开来看，分享我是怎么设计任务验收机制，把 AI Agent "虚报完成"的情况从每天都发生，降到接近零的。
问题的本质：Agent 的"完成"和你的"完成"不是同一回事
先搞清楚为什么 Agent 会说"完成了"但其实没完成。
Agent 的三种"虚报完成"模式
模式一：工具调用失败了，但 Agent 不知道
vbnet
Agent: 调用 write_file("output.md", content)
工具: [返回 {"success": true}] ← 但文件其实没写进去
Agent: 文件已写入，任务完成。这种情况很常见，特别是在文件系统操作、网络请求、数据库写入时。工具返回了 success，但后续校验会发现数据根本不存在。
模式二：完成了一半，把一半当全部
makefile
任务: 发布文章到3个平台（知乎、掘金、CSDN）
Agent: 知乎发布成功。任务完成。
← 掘金和CSDN根本没动Agent 完成了任务的第一步，就认为整个任务完成了。这在多步骤任务里极其常见。
模式三：执行了操作，但没有验证结果
makefile
Agent: 已向服务器发送请求，任务完成。
实际: HTTP 500，服务器拒绝了请求
Agent: [没有检查响应码，直接报完成]我的解决方案：三层验收机制
在踩了无数坑之后，我给我的 Agent 团队（跑在 OpenClaw 上的 6 个专职 Agent）设计了一套三层验收体系：
第一层：Tool 调用后强制校验
每个工具调用之后，不能只看返回值，必须做二次读取验证。
错误做法（Agent 的默认行为）：
python
result = write_file("output.md", content)
if result.success:
return "文件已写入" # ❌ 只信 success flag正确做法：
python
result = write_file("output.md", content)
if result.success:
# 二次验证：重新读取文件
verification = read_file("output.md")
if verification.content == content:
return "文件已写入并验证"
else:
return "写入失败：文件内容不符，需重试"听起来简单，但在 Agent 的 System Prompt 里明确写出这个规则非常重要。
我在 System Prompt 里加的规则：
bash
## 任务完成验收规则
每次执行写操作（文件写入、API调用、数据库操作）后，
必须执行对应的读操作来验证结果。
不得仅凭工具返回的 success:true 就报告任务完成。第二层：任务完成度检查清单
对于多步骤任务，我要求 Agent 在每次回复时附上一个完成度矩阵：
ini
## 任务完成状态
- [x] 步骤1: 内容生成 ✅
- [x] 步骤2: 知乎发布 ✅
- [ ] 步骤3: 掘金发布 ⏳
- [ ] 步骤4: CSDN发布 ⏳
- [ ] 步骤5: 日志记录 ⏳
当前完成度: 2/5 (40%)这样做的好处是，Agent 必须在回复里显式列出所有步骤的状态，不能"偷懒"把未完成的事情省略掉。
我在 Agent 的 SOUL.md（角色设定文件）里加了这条规则：
markdown
## 任务报告规则
完成任务时必须：
1. 列出所有预期步骤
2. 标注每个步骤的实际状态（✅/⏳/❌）
3. 计算总体完成度
4. 对未完成步骤给出原因和后续计划
禁止：在所有步骤完成前使用"任务完成"的表述第三层：外部观察者验收
这一层是我后来加的，也是最有效的。
核心思路：任务的完成不能由执行任务的 Agent 自己来判断，需要一个独立的"观察者"来确认。
在 OpenClaw 里，我专门设置了一个 content-reviewer Agent，它的职责就是在其他 Agent 报告完成时，独立去验证结果。
markdown
执行流程：
1. cross-platform-publisher → 发布内容 → 报告完成
2. cross-platform-publisher → 通知 content-reviewer → "请验收"
3. content-reviewer → 独立检查 → 确认/否定
4. 只有 content-reviewer 确认后 → 才写入 daily-traffic-log.md这套机制把"虚报完成"几乎降到了零。因为执行 Agent 知道，自己报完成之后还有一关。
实际踩坑案例：掘金发布的坑
分享一个真实案例。
我的 cross-platform-publisher Agent 有一次汇报：
"掘金文章已发布，标题《AI Agent 团队管理实战》，状态：成功"
我去掘金一看，确实有这篇文章------但状态是草稿，没有点击"发布"按钮。
Agent 调用了"创建文章"的 API，工具返回了 article_id，Agent 就认为发布完成了。
实际上，掘金的流程是：
- 创建文章（得到 article_id）
- 调用发布 API（传入 article_id，文章才真正公开）
Agent 只做了第一步。
修复方案：
在 Agent 的工具调用流程里，明确写出验收标准：
markdown
## 掘金发布验收标准
成功标准：文章在掘金可以被未登录用户看到。
验收方法：调用 GET /article/{id} 确认 status=2（已发布），
而非 status=1（草稿）。加了这条规则之后，Agent 会自动去检查文章状态，如果是草稿就继续调用发布 API，直到验收通过。
总结：三个工程实践原则
回头看这些踩坑经历，我提炼出三个实践原则：
原则一：写操作后必须读验证 任何对外部系统的写操作（文件、API、数据库），都必须在写之后立即做读取验证。信任 success flag，不如信任自己的眼睛。
原则二：任务完成度必须显式量化 不允许模糊的"任务完成"。必须是"5步中完成了5步，所有步骤均已验证"。这迫使 Agent 不能跳过步骤。
原则三：执行者和验收者分离 执行任务的 Agent 不能自己验收自己的成果。至少要有一个独立的检查机制------哪怕只是在 System Prompt 里加一条"完成后重新检查一遍所有步骤"。
这三条原则，让我的 Agent 团队从经常"虚报完成"，到现在几乎不再出现这个问题。
如果你也在用 AI Agent 处理实际业务，强烈建议把这套验收机制加进去。节省的时间，比写这些规则所用的时间多得多。
📖 本文首发于微信公众号「Wesley AI 日记」
📚 AI Agent 实战系列（微信搜索「Wesley AI 日记」关注）：
👆 微信搜索「Wesley AI 日记」关注，持续更新 AI Agent 实战系列。