给 AI Agent 建立可重复的评估回路

以本站的草稿发布冲突为例，把一次看似成功的操作拆成可检查的规则、失败样本和回归测试。

更新于 2026/09/26生长中

文章目录

一个 Agent 完成任务后，告诉你“发布成功”，还不足以说明它做对了。更具体的问题是：发布到了哪里？公开的是哪个版本？有没有把仍在编辑的草稿带出去？

本站工作台的一次评审暴露了这种差距：作者确认的是版本 2，另一个窗口随后保存版本 3，发布接口却公开了版本 3。接口返回成功，操作本身仍然违反了作者的意图。

这篇笔记用这个实际问题说明怎样设计评估。它讨论的是 Agent 调用工具时必须守住的边界；这里的冲突来自工具实现，并不能证明模型本身的好坏。

先把成功写成可观察的条件

“正确发布文章”太宽泛。这个场景至少包含以下条件：

这样，判断依据就不再只是界面上的“成功”提示。评估必须读取操作之后的状态。

原问题可以按下面的顺序复现，不需要长提示词，也不需要真实文章：

修复前，本地检查得到 200，公开正文是 B；预期应该是 409，让作者重新核对。修复需要同时约束读取和写入：仅在代码开头比较版本仍不够，实际更新时也必须带上版本条件。

UPDATE ideas
SET published_content = draft_content,
    is_published = 1,
    version = version + 1
WHERE id = ? AND version = ?;

上面只展示关键字段。若没有行被更新，应报告冲突，不能继续把操作当成成功。

完整实现可以对照仓库中的灵感发布接口。

接口状态码、版本、文件路径和公开快照可以直接由代码检查。文章是否解释清楚、摘要是否准确、引用是否支持结论，则需要另一套阅读量表。

例如，检查“有引用”只能证明输出包含一个引用位置，不能证明来源存在，更不能证明来源支持那句话。可以把这类样本拆成三项：链接是否可访问、引文能否在来源中找到、来源是否支持当前表述。每项单独记录证据，不用一个布尔值代替全部判断。

对于需要人或模型判断的内容，可使用这样的记录：

任务：压缩一篇笔记的摘要
硬约束：不增加原文没有的事实；保留结论的适用条件
原始材料：原文与旧摘要
输出：候选摘要
判定：通过 / 需修改
证据：指出候选中新增、遗漏或改变含义的具体句子

这是一个量表示例，尚未作为本站自动评分系统部署。先用真实样本校准判断，再决定哪些部分适合自动化。

一次失败至少留下输入、预期、实际结果和复现步骤。修复之后，再用同一个样本确认差异，并补一个正常路径：最新版本仍然能够发布。

发布版本冲突只是其中一个样本。后续值得覆盖的还有：工具超时后的重试、AI 候选返回时原稿已变化、草稿切换后旧请求完成。它们共同依赖上下文交接中保留可执行状态。