入门大模型工程师第八课----让Agent加一道自检闭环
前言
你已经看到 Agent 能拆任务、分头查资料、汇总成一份报告。可只要任务稍微长一点，另一个问题就会冒出来：报告写得很顺，但里面有没有把没完成的事写成完成？有没有遗漏阻塞事项？有没有把不能对外发送的信息写进去？
这类问题不一定靠一句“认真核对一下”就能解决。你需要让 Agent 写完以后，还能拿着依据回头检查一遍。
本课继续用 QoderWork 这类桌面 Agent 演示文件夹读取和任务执行。换成其他支持读取文件夹或上传多个文件的 Agent 时，入口名字可能不同，但判断逻辑相同。
先从一份需要核实的日报初稿开始。
课程目标
学完这节课后，你将能够：
写出执行规则，让 Agent 在执行任务时区分已完成、待确认、阻塞和不能对外发送的信息
在生成草稿时同步留下过程记录，写清事项来源、原始记录状态和处理方式
把复核中发现的问题补进执行规则或自检清单，减少下次同类错误
1 日报初稿容易出什么问题
假设你每天结束工作前都会发一份日报。你把今天的任务记录、客户名单修改记录、会议纪要、报销进度交给 Agent，让它整理成日报。
它给出的初稿可能长这样：
## 2026-05-15 日报 ### 已完成 1. 完成客户续费名单整理，已按客户等级标注优先级。 2. 补充“客户回访话术”说明，已更新到团队共享文档。 3. 完成下周客户拜访排期，已和销售同事确认时间。 4. 费用报销材料已提交，后续等待财务打款。 ### 明日计划 - 跟进重点客户续费确认。 - 整理本周客户反馈。 ### 备注 - 已确认客户采购预算约某预算金额。这份日报看起来顺畅，但发布前需要核实。对照原始记录，会发现几类问题：
日报里的说法 | 原始记录里的情况 | 问题 |
已和销售同事确认下周客户拜访时间 | 会议纪要写的是“还有两位客户待回复” | 把待确认写成已完成 |
费用报销材料已提交 | 报销记录写的是“缺少发票，暂未提交” | 把阻塞写成已完成 |
没有风险/阻塞栏目 | 任务记录里明确有阻塞项 | 遗漏阻塞事项 |
这不是格式问题。它真正错在状态和证据：待回复的事被写成确认，缺材料的事被写成提交。还有一类问题是发送范围：备注里的客户预算不该进入日报正文。
2 告诉 Agent 什么算合格
上面这些问题——状态写错、证据缺失、不该发的信息混进正文——可以通过一段执行规则来减少。把“什么算合格”写清楚，让 Agent 整理日报时全程遵守：
执行规则： - 已完成事项必须有证据。 - 进行中、阻塞、待确认不能写成已完成。 - 不能遗漏阻塞事项。 - 私密备注不能进入日报正文、问题清单、过程记录、自检结果等任何输出。执行规则能减少错误，但不能保证输出已经合格。它不是只在开始前生效，而是 Agent 整理材料和生成日报时都要遵守的边界。
规则尽量写成能检查的句子。“内容准确”太宽，“已完成事项必须有证据”就更容易核对。
3 生成草稿时同步留下过程记录
为了让后面能检查，不要只让 Agent 给出日报正文，还要让它在旁边列一份过程记录。过程记录不用给别人看，只供你或检查 Agent 判断每个关键内容从哪里来、处于什么状态、能不能写进正文。即使过程记录只给自己看，也不要复述私密备注的具体内容。
这不是固定模板。你也可以换成别的表格列，关键是说清楚：写了什么、依据在哪里、原始记录里显示的状态是什么、这条内容应该怎么处理。比如保留、改写、移到待确认或风险/阻塞栏目，或者删除敏感内容。为了检查方便，先用下面这个表格：
事项｜原始记录状态｜来源文件｜原文线索｜处理方式例如：
事项 | 原始记录状态 | 来源文件 | 原文线索 | 处理方式 |
客户续费名单整理 | 已完成 | customer_list_update.md + tasks.md | 已按客户等级标注优先级 | 保留在“已完成”栏目 |
下周客户拜访排期 | 待确认 | meeting_notes.md + tasks.md | 还有两位客户待回复 | 改到“待确认”栏目，不能写成已完成 |
费用报销材料 | 阻塞 | reimbursement_notes.md + tasks.md | 缺少发票，暂未提交 | 改到“风险/阻塞”栏目，并说明当前卡在哪里 |
执行规则用来说明 Agent 必须遵守什么，过程记录用来留下来源、状态和处理方式。没有过程记录，后面检查时就只能凭感觉判断“像不像对”。
4 换个对话，专门检查初稿
可以新开一个对话，把初稿、过程记录和必要的原始文件交给它，让它只做检查，不负责写稿。这样职责更单一。
很多检查项可以从执行规则改写而来。执行规则写“已完成事项必须有证据”，检查时就问“每条已完成是否都有证据？”自检清单可以按材料类型调整，这里先用下面这组问题：
自检清单： 1. 每条“已完成”是否有证据？ 2. 是否有未完成事项被写成已完成？ 3. 是否遗漏阻塞事项？ 4. 是否把计划、讨论或承诺误写成结果？ 5. 是否泄露或复述不能对外发送的信息？通常你会看到它把问题列出来：
抓到的问题 | 初稿里的内容 | 依据 |
待确认写成已完成 | 已和销售同事确认下周客户拜访时间 | 会议纪要写“还有两位客户待回复” |
阻塞写成已完成 | 费用报销材料已提交 | 报销记录写“缺少发票，暂未提交” |
遗漏阻塞事项 | 初稿没有风险/阻塞栏目 | 任务记录里有阻塞项 |
敏感信息进入输出 | 备注里出现客户采购预算 | 私密备注写明不得进入日报 |
自检清单的作用不是“再读一遍”。只说“请认真检查一下”，通常容易得到泛泛的确认；说“按过程记录逐条检查”，更容易让它指出哪个关键内容没有证据、哪条状态写错了。
5把检查前后要做的事串起来
前面每一步单独看都很小，连起来才是一套固定流程：写之前有规则，写的时候留依据，写完后按清单检查，发现问题后修订输出，再整理下次能用的检查项。
这套流程可以这样展开：
什么时候 | 要做什么 | 日报里的例子 |
写之前 | 写执行规则 | 已完成事项必须有证据 |
生成草稿时 | 留过程记录 | 下周客户拜访排期来自会议纪要，仍有客户待回复 |
写完后 | 按自检清单检查 | 有没有把待确认写成已完成 |
发现问题后 | 修订输出 | 把排期移到“待确认”，把报销移到“风险/阻塞” |
修订后 | 补规则或检查项 | 增加“待审批不能写成已完成或已确认” |
这类套在模型外面的约束与引导机制，业界通常叫Harness Engineering（驾驭工程）。Harness 原意是马具，用来约束和引导马的力量；放到 Agent 里，Harness 就是约束规则、检查反馈和纠偏机制的组合，套在模型外面，让它跑得快但不跑偏。
执行规则在行动前就告诉 Agent 哪些状态不能写错、哪些内容不能对外发送；自检清单在行动后检查输出有没有偏离这些规则。业界有时把行动前的引导叫 Guides，把行动后的检查叫 Sensors。
每次发现问题后补规则或检查项，不是为了保证以后一定不出错，而是让下次更容易提前发现同类问题。
6 反复验证后，保存成下次能用的模板
刚才这套流程还是你手动触发的：你把材料交给 Agent，先生成日报，再换个对话检查，最后修订并补检查项。重复做几次之后，如果同一类事每天、每周都会发生，就可以把固定路线写下来：
读取指定资料 → 生成草稿并留过程记录 → 按自检清单检查 → 修订并调整检查项 → 等人确认先不要急着自动发送或定时运行。下一步仍然建议手动触发：确认它能按固定路线读取材料、生成草稿、留下过程记录、按自检清单检查并修订。反复用几次确认这几步能稳定跑完后，再决定哪些低风险步骤可以自动，哪些动作必须等人确认。
可以自动化的通常是整理、摘要、草稿和待确认清单；发送、删除、移动真实业务文件、付款、外发含敏感信息的内容，都要停下来等人确认。
这套流程可以先保存成一份提示词模板，下次直接复制使用。模板不是固定格式，关键是把每次都要重复交代的内容放在一起；下次使用时，只需要改资料位置、日期和具体任务。模板里可以包含这些内容：
执行规则：哪些状态不能写错，哪些信息不能对外发送；
过程记录：每条内容要写清来源、原始状态和处理方式；
自检清单：每次写完后要检查哪些问题；
常见问题：以前出过哪些错，下次怎么查；
需要你确认的动作：哪些内容不能自动发送或自动处理。
如果这份模板反复使用、内容也比较稳定，再考虑做成 Skill 或定时任务。同一类问题反复出现时，不要只改这一次输出，先把对应检查项补进提示词模板；如果已经做成 Skill，也同步补进 Skill。