微软业务智能体评测接入 HF，直接检查数据库结果

发生了什么

ThinkingBox 将业务智能体的验收落到数据库终态与副作用。HF 博文介绍了 507 项有状态流程，并对每项任务独立运行二十次，分别观察平均成功、至少成功一次和所有尝试都成功的情况。1

这对小团队接入客服、订单或工单自动化很重要：模型说已经完成，和系统记录真正正确，是两件需要分别核实的事。

具体是什么

文章展示一个工单案例：智能体完成了多次看似合理的查询与写入，却把仍有问题的工单标成已解决。只检查工具是否成功调用，可能错过这种错误；核对最终字段才能发现结果与要求不一致。1

基准因此不只看最终回复，也检查遗漏操作、不该发生的修改和错误字段。重复执行则进一步区分“偶尔能做对”与“可持续交给它处理”的任务。

怎么用

从博文进入 ThinkingBox 的 OpenEnv 示例，先运行一项参考任务和终态核验器，确认自己理解预期状态。1 接入模型时，从相同初始数据库状态重复执行，不要在上一轮已经修改过的环境上接着测试。

对自己的业务，可以先选三类高频工作：查询后更新状态、根据规则创建记录，以及修改后需要保持其他字段不变的流程。每类任务写清最终应该变什么、什么绝不能变，以及完成后怎样检查。

同时保存工具轨迹和数据库差异。遇到失败，区分是模型误读规则、选错记录、漏掉步骤，还是核验器本身写错。只有找到失败类型，后续换模型、改工具或调整流程才有明确方向。

还应测试重复提交同一请求的情况，检查系统是否重复创建订单、工单或其他记录。把这种边界条件加入验收，能让评测更贴近日常业务中网络重试与用户再次询问的实际情况。

意味着什么

业务智能体的采购和上线标准需要从演示转向验收。平均分可以帮助比较候选，但真正的使用范围应按重复成功的具体任务划分。一个整体得分较低的模型，也可能在某个固定流程中更稳定。

小团队可以先把稳定流程交给自动化，把仍不可靠的步骤保留人工处理。这样更容易明确收益，也便于随着模型或工具更新逐步扩展范围。

局限与风险

二十次全部通过只代表这二十次观察结果，不能证明以后永远不会失败。文章也区分了至少一次成功与全部成功，没有把它们当作同一可靠性指标。1

数据库检查必须与业务要求一致。写得过窄会误判正确路径，写得过松又会放过副作用。正式采用前，应让懂业务的人检查核验规则，并用真实但隔离的测试数据覆盖边界情况，尤其是重复提交和信息冲突。