怎样知道 Agent 真的完成了

2. 模拟任务：验收第三章写出的独角兽企业新闻稿

在第三章中，你让 Agent 根据企业介绍、招股书、CEO 专访和行业报告，为一家虚构的企业“云舟Z智能”起草了一篇新闻稿。为了把验收过程讲清楚，本章再给这批模拟资料补上三个明确事实：

• 招股书写的是：2025 年营业收入为 24 亿元，同比增长 18%；

• CEO 专访说的是：希望未来三年把海外收入占比提高到 30%；

• 行业报告写的是：相关市场规模约为 800 亿元，没有给云舟Z智能排过名。

Agent 交来的初稿却写成：

2026 年，云舟Z智能营收突破 35 亿元，同比增长 40%，海外收入占比达到 30%，稳居行业第一。

句子很顺，气势也很足，但四个关键信息没一个对的。你不能只回复一句“再严谨一点”，而要让 Agent 按照同一把尺子逐项验收，并把每个判断的依据交出来。

你可以向 Codex 这样发出验收任务：

请先验收这篇新闻稿，不要直接润色或重写。

1. 按完成标准逐项判断“通过、需要修改或缺少依据”；

2. 单独检查数字、时间、排名、目标与已完成事实、绝对化表述；

3. 对每个关键说法列出稿件原句、来源文件、页码或位置、资料原文和判断；

4. 找不到依据就写“未找到依据”，不要猜；

5. 先交验收报告，等我确认后再修改正文。

下面几个概念，正好对应这次验收里的不同部分：Hallucination 是需要识别的事实问题，Completion Criteria 是验收标准，Eval 是按标准实际检查，Trace 是继续追查问题怎样产生，Benchmark 则用于把不同配置放到同一套题目上比较。

3. Hallucination（幻觉）：把“事实”小小改头换面

Hallucination（幻觉）是模型把错误、推测或没有依据的内容当成事实写了出来。它不只表现为凭空编一个数字，还可能表现为在已有资料上胡改上两笔，失之毫厘，张冠李戴：

• 把“24 亿元”写成“30 亿元”；

• 把“未来希望达到 30%”写成“已经达到 30%”；

• 看到行业规模很大，顺手把企业写成“行业第一”；

• 把别的年份、别的公司或别的口径的数据安到当前企业头上。

验收时，凡是找不到可靠来源的说法，先标为“待核实”。

让 Agent 回到原文核对；现有资料仍不能支持，就删除这句话，或者改成符合原文的表达。如果这条信息确实不可缺，则需要重新补充资料。

4. Completion Criteria（完成标准）：把“完成”写成可以验收的条件

Completion Criteria（完成标准）是你用来判断任务能不能交付的一组明确条件。它最好在写稿前就确定；如果前面没有写，最晚也要在验收前补上。

“写一篇有传播力的新闻稿”只是期待，不足以验收。“全文 1200—1500 字；必须写清楚公司新发布的商品或服务、经营数据和行业背景；所有数字注明来源；未来目标不能写成已经完成；没有依据不得使用‘第一’‘领先’等判断”，才接近完成标准。

这次新闻稿可以使用下面这张验收表：

对于新闻稿来说，“每个关键数字都能查到出处”是很有用的验收方式。

5. Eval（评估）：拿着标准检查一次

有了 Completion Criteria 这把尺子后，下一步是 Eval（评估）：根据标准检查任务结果，并记录检查结论。

新人用户一般不需要搭一套专业评估系统，而是让 Agent 按验收表逐项输出“通过、需要修改、缺少依据”，再由你抽查关键事实，就是一次轻量 Eval。

以上面的错误段落为例，Eval 的结果应该接近这样：

除了对交付物初稿（新闻稿、报告、自媒体内容等）进行挑错验收外，Eval 还有更有价值的地方。比如当你准备长期、反复让 Agent 做同一类任务时，可以用 Eval 比较哪种执行方法更可靠。

以“云舟Z智能”这个新闻稿为例，以后你需要持续追踪几家业内企业，每周至少写两篇新闻稿。那么这时就有必要评估一下“以后写稿用什么执行方法”更好，比如使用什么 Prompt、用哪个模型、必备什么材料、用什么写作 Skill 等。

你就可以拿同一批资料和同一套验收标准，分别测试：

• Prompt A 和 Prompt B，哪一个更少漏掉数字来源。

• 模型 A 和模型 B，哪一个更少把目标写成已完成事实；

• 只提供招股书，和同时提供招股书、专访、行业报告，哪种资料组合写出的稿子更完整。

• 同样是写作 Skill，Skill A 和 Skill B，哪一个的生成结果更符合发布要求。

根据 Eval（评估）结果，最终敲定自己的写作方案。对于新人用户而言，用什么工具组合也是个人价值壁垒的体现，值得长期积累。

6. Trace（过程追踪）：这句话到底是怎么来的

Trace（过程追踪）是系统在 Agent 执行任务时留下的过程记录。一次任务可以记录收到的指令、读取的资料、进行的调用、各步结果和报错。它通常由系统自动产生，不需要用户自己写。

这个概念离新人用户有一些距离，所以你基本不需要打开完整 Trace。但是基于 Trace 的能力，新人用户可以在交付物验收时进行准确“溯源”。

比如，验收新闻稿时，让 Agent 在验收表中增加一列关键说法的来源，已经足够实用。你可以对 Codex 说：

请在验收报告中增加“关键说法的来源”一列，标出来源文件和具体位置；找不到依据的内容写“无”。

于是 Codex 就会在验收报告中新增一列：

完整 Trace 对开发人员的用处更多。

例如客服 Agent 错把旧折扣发给客户，开发人员可以打开这次任务的 Trace，依次查看“查询资料—取回折扣规则—生成邮件—发送结果”。如果取回的就是旧规则，问题可能出在知识库；如果取回的是新规则，邮件却写错了，问题可能出在生成环节。开发人员据此决定修资料、改程序，还是换模型。

开发人员还会用 Trace 排查事故、比较不同版本，并观察一批 Agent 是否稳定运行。这里还会遇到 Log（日志）和 Observability（可观测性）。

Log 记录单个事件，例如“10:32 查询折扣规则”“10:33 返回 2024 年旧规则”。Trace 把同一次任务里的这些记录按先后关系串起来。Observability 则把许多任务的 Trace、Log，以及成功率、耗时等指标放在一起，帮助开发人员了解整个系统的运行情况。这一套新人用户知道即可。

7. Benchmark（基准测试）：给不同配置准备同一套考题

Benchmark（基准测试）是一套固定、可以反复使用的测试材料和评分规则。Prompt、Skill、大模型和 Agent 配置都可以成为它的测试对象。网上常见的模型榜单就是 Benchmark：它们固定数学、代码或问答等测试题，用来比较不同模型的成绩。

Eval 小节中提到，你可以用同一份新闻稿材料测试两版 Prompt、两种 Skill、两个模型或两套 Agent 配置，再比较哪一种写得更准、更好。这是在对这些对象进行一次 Eval。如果把材料、正确事实、任务要求和评分规则保存下来，以后每次都让不同的测试对象完成同一项任务，并按同一标准评分，这套固定测试就是一套小型的 Benchmark。

再比如，你的部门负责 AI、存储芯片、数据中心、云服务、制造业和医疗健康等多个赛道的新闻稿，就可以为每个赛道准备多组有代表性的历史任务。每组固定已经核准的材料、正确事实、任务要求和验收标准，再针对不同的 Prompt、Skill、大模型或 Agent 配置完成同一批任务，并把参加测试的名称和版本记录在结果中，然后比较：

• 哪种配置漏掉的关键信息更少；

• 哪种配置错写数字、年份和事实状态的次数更少；

• 哪种配置给出的来源更完整；

• 哪种配置更符合公司的新闻稿文风；

• 哪种配置在稿件质量达标的情况下，消耗的 Token 更少、性价比更高。

这就是一套小型的内部 Benchmark。

8. 一句话释义

• Hallucination 是模型把错误、推测或没有依据的内容当成事实写出来

• Completion Criteria 是判断任务能不能交付的一组明确条件

• Eval 是根据标准检查任务结果并记录结论

• Trace 是系统在 Agent 执行任务时留下的过程记录

• Benchmark 是一套固定、可以反复使用的测试材料和评分规则