Agent 搭完之后，怎么知道它真的变好了？

Agent 看起来已经把事情做完了，但是结果却不尽如人意。

回复写得很完整，语气也比上一版自然，甚至还主动补了几个细节。可真到交付的时候，问题就冒出来了：表格少了一列，事实没有核实，文件没存到指定位置，或者该调用的工具根本没有调用。

只看聊天窗口，它好像更聪明了。放回实际工作里，这件事却没有稳稳当当地做完。

Agent 搭起来以后，很多人都会卡在这里。换模型、改提示词、加知识库、调工作流，每次似乎都有一点变化。可这次改动到底有没有用，不能只看某一次回答是不是更顺眼。

真正需要解决的，是怎么验收。

01 做出来了，不代表能交付

平时做内容或处理业务，我们不会把“有一份结果”直接当成完成。文章要核对事实，海报要检查尺寸和错字，数据表要看字段齐不齐，邮件发出前也要确认收件人和附件。

Agent 的结果也要这样看。先让它把东西做出来，再检查这份东西到底能不能用。如果把这两步混在一起，很容易被流畅的语言和整齐的格式带偏。

而且，生成式 AI 的输出本来就会波动。同一个任务今天做对了，不代表下次还会做对。新版本修好了一个问题，也可能把原本稳定的地方弄坏。软件开发里通常把这种情况叫作“回归”。

所以，评测 Agent 不是为了算出一个漂亮的总分，而是要留下可以反复核对的证据。下次再改模型或工作流时，能清楚地看到它哪里变好了，哪里反而退步了。

02 先把要测的任务固定下来

可以先留一小组经常会遇到的真实任务。不用一下覆盖所有情况，先选最常用、也最怕出错的那些。

做内容运营，可以放进这些任务：根据给定信息写摘要、从长文中提取标题、按格式生成发布文案、核对事实、把结果存到指定文件。企业内部的 Agent，则可以测试查制度、整理会议纪要、生成固定字段的周报，或者调用某个业务工具。

以后每次换模型、改提示词或调整工作流，都把这组任务重新跑一遍。测试对象固定了，前后两版才有得比。

跑完以后，先看字段、文件、关键词、工具调用这些明确要求有没有做到；再让模型按照事先写好的质量标准帮忙评审；最后结合人工抽检，给出能不能交付的判断。

不过，这套测试只能说明 Agent 在这批任务和当前环境里的表现。它不能证明 Agent 已经不会犯错，也不能保证换个任务、模型或环境以后依然稳定。

03 验收可以分三步

刚开始做评测，不用急着搭一整套自动化系统。先把检查分成三步，就已经能发现不少问题。

第一步，查硬规则。

比如要求的字段有没有出现，禁止内容有没有混进来，指定工具是否真的调用，文件能不能打开，尺寸和格式对不对。这些问题通常有明确答案，也比较适合交给程序检查。

链接检查要多看一层：格式是否正确、页面能否访问、打开后是不是目标页面。如果碰到登录和权限，就单独留给人工确认。还要注意，网页这次能打开，不等于内容一定真实，事实仍然要另外核验。

硬规则判断不了文章好不好看，但很擅长拦住那些低级又致命的错误。能明确检查的要求，尽量别让模型凭感觉判断。

第二步，让模型按照质量评分标准帮忙评审。

所谓质量评分标准，就是把“这篇写得不错”拆得更具体一些。比如有没有回答核心问题，有没有漏掉必要背景，事实是否充分，表达是不是适合目标读者。

这些要求很难只靠关键词判断，可以交给另一个模型先评一遍。但模型评审也会有偏差。两份答案谁先谁后，可能影响比较结果；内容写得更长，有时也会平白占便宜；评审模型还可能更喜欢与自己相近的表达。

所以，让模型帮忙评审，适合用来扩大检查范围，不能直接替代最终验收。它说“通过”，只能算一条辅助意见。

第三步，人工抽检。

人工要重点看一类结果：规则通过了，模型也觉得不错，但真正的用户未必满意。比如文章事实没错，却没抓住读者最关心的点；报告字段齐全，给出的建议却没法执行；图片没有越界，视觉重点却很乱。

不一定每一份结果都要人工检查。抽多少，要看任务风险和工作量。涉及对外发布、政策、客户信息或重要业务决策时，检查自然要更严一些。

04 失败记录比总分更值得留下

发现问题以后，别只改一句提示词，然后马上重新生成。最好顺手记下四样东西：当时给了什么输入，Agent 实际输出了什么，问题出在哪里，这次又做了什么修改。

还要把这个失败案例放回固定任务里。下一次更新后，它要和其他旧任务一起重跑，这就是回归测试。

这样积累一段时间，留下来的就不再是零散的“调参经验”，而是一份越来越贴近实际工作的检查清单。Agent 以前在哪里出过错，新改动有没有让同类问题再次出现，都能查到。

如果一次生成的成本比较高，还可以把检查往前放。先做便宜而明确的预检，再生成一小部分样片。方向确认没问题，再完整生成；成品出来后，还要把整体和细节都复核一遍。

做 PPT、海报、短视频或批量文档时，这个顺序尤其有用。很多问题在预检或样片阶段就能发现，不必等整批做完再返工。

05 今天就可以先建一张表

还没有评测系统也没关系，可以先从一张简单表格开始。列名写成：任务、硬规则、质量评分标准、硬规则结果、模型意见、人工结论、失败原因、修改记录。

“模型意见”和“人工结论”要分开记。模型给出的“是”或“否”只是参考，最后能不能交付，还是要看人的判断。

然后从最常做的事情里挑一小组固定任务。个人刚开始时，可以先准备 5～10 个，但这只是方便起步，不是统一标准。数量少一点没关系，重要的是每次改动后，都用同一批任务重跑。

每个任务写两类验收条件。一类是必须做到的硬规则，另一类是需要结合上下文判断的质量标准。跑完以后，把规则结果、模型意见、人工抽检结论和具体失败原因都记下来。

刚开始不用忙着算总分，先看三件事：以前的错误有没有再出现，原本稳定的任务有没有变差，这次想解决的问题是不是真的解决了。

表格持续更新以后，就会慢慢形成一套适合自己工作流的验收基线。它可能不复杂，也不一定完全自动化，但会比反复打开聊天窗口、凭印象比较两段回答靠谱得多。

判断 Agent 有没有真的变好，不能只看它说得像不像一个聪明人。更重要的是，同一批真实任务交给它时，它能不能更稳定地把该做的事做对。就算出了问题，也能知道错在哪里，下次还可以专门检查这个问题有没有再回来。

如果你觉得今天这篇有收获的话，欢迎点赞、关注、转发，我们下篇见。