Agent说“处理完成”。值班同事打开后台：工单状态没变，客户资料反而多改了一列。演示里的对话很顺，业务结果却错了。微软Copilot Studio团队与Hugging Face发布的ThinkingBox，正是为了让这种差别进入评测表：把Agent放进带有初始后台状态、策略约束和工具的沙箱，执行完毕后对照数据库的黄金状态检查，而不以最后一句回答作为通过条件。公开资料介绍了507个合成企业工作流，以及重复运行20次的评测方法。企业可以据此设计自己的验收，但不能把公开基准成绩当作真实生产环境承诺。
一句话“已完成”，到底证明了什么
设想一个数字银行的用户要求变更一项服务设置。Agent调用了查询工具，甚至写入工具也返回成功，随后给用户一个流畅答复。评审若只看聊天记录，很容易给高分。然而任务可能还要求验证账户归属、遵守某项策略限制、更新指定字段且不得触碰其他记录。工具调用成功只证明接口处理了请求，不证明业务目标达成；界面中的一条成功提示，也不能说明所有必要副作用均已发生。
ThinkingBox公开介绍的工作流涉及零售、汽车保险、旅行、数字银行和咨询，合计507个合成任务。每个任务包含初始后台状态、用户目标、策略约束、MCP工具和可执行的最终状态检查。这里的“合成”很重要：样本是为受控比较构造的，不是这些行业里所有流程的真实分布。它让模型或Agent配置在同样起点重复跑，排除上一次试验残留状态造成的干扰；却不能自动覆盖本公司的异常数据、权限矩阵与接口故障。
如果采购方听到“507”，最好先问覆盖的是哪类动作。查询型任务与写入型任务的风险不同；写入订单、处理赔付、修改旅行行程、更新账户权限，错误的恢复成本也不同。可以借用ThinkingBox的结构搭建本地任务集，却不应把“跑过公开任务”翻译成“已经可以接管我司流程”。公开基准解决的是可复现实验起点和可检查终点，公司的真实边界还得自己写出来。
最终状态：把要求变成能执行的断言
状态评测通常可分成四层。第一层是目标记录：目标对象的字段、金额或状态是否变为预期值。第二层是前提约束：Agent是否在有效授权、合法业务条件之内执行。第三层是副作用：通知、审批、关联单据、外部工具调用是否按规则发生。第四层是未受影响的对象：本不该修改的行是否保持原样。ThinkingBox强调数据库与预设黄金状态的比较，以及副作用检查；四层拆法是企业实施时可采用的检查设计，不是对其公开实现细节的逐项复述。
假设“为合规的零售退货创建退款申请”是一条企业自建测试任务。验收不能只有refund.status = created。还需要核对退货资格、退款目标账户、原订单金额上限、审批节点及该订单之外的余额是否未变。反过来，若用户要求一个被策略禁止的动作，正确终态可能恰恰是“没有写入”，并保留明确的拒绝依据。负面任务要在样本中出现，否则一个不加判断地执行所有请求的Agent也能拿到漂亮分数。此例是方法示意，不是ThinkingBox原始任务内容。
检查器最好读取权威数据源，而非再问同一个Agent“你做成了吗”。对数据库可做事务后的快照比较；对外部系统可用事件回执、幂等键、审计日志和补偿记录互相印证。如果通知可能异步送达，检查窗口要写清楚，例如等待任务队列终态后再评分，而不是因为消息晚了几秒就误判。数据库一致并不天然涵盖所有外部副作用；网络出口、邮件、支付和工单流转都应单独列断言。
为什么要重置沙箱
同一条任务第二次跑，起点若已经发生了第一次的写入，就不是同一道题。把初始状态冻结、在每次试验前还原、按固定配置保存轨迹，才能比较不同Agent策略或同一策略的波动。ThinkingBox的可重置沙箱因此比一份问答题库更接近企业的验收现场。还原不是只清数据库：缓存、队列、外部模拟服务、授权令牌、时钟与速率限制，也可能影响结果。后面这些是落地时需额外考虑的系统因素，不应误写为项目公开承诺。
企业可以把测试分为两组。一组是可重复、无真实对外影响的模拟环境，专门定位策略与工具调用问题；另一组是经过隔离的预生产环境，用接近真实的接口和权限验证集成风险。不要为了测试方便，给Agent一把比生产还大的通用密钥，否则测到的是一个现实里不应存在的Agent。测试数据也不必复制真实客户隐私；用去标识化或合成数据重建业务约束更稳妥。
每次运行都应留一份可以复盘的证据包：任务版本、初始状态哈希、模型和Agent配置、工具版本、允许调用的范围、执行轨迹、最终状态差异、检查器版本，以及时间与成本。否则版本迭代后，团队只能对着“上周能过、今天过不了”猜原因。轨迹供定位问题，终态断言才负责业务通过与否；别反过来用“调用看起来合理”盖过错误的记录。
20次重复运行，不是把单次成功率乘一下
官方建议同一任务重复运行。公开分析指出，一些模型单次成功率不低，但连续20次全部成功的任务比例明显下降。这里有两个不同指标：按所有运行计算的单次通过率，以及按任务计算的“20次无一失败”比例。后者更贴近高频业务的稳定性要求。没有给出同一任务、相同环境与相同判分口径的原始序列，就不应凭一句概述替它填上具体百分比。
重复试验要尽量保持提示、温度、工具版本、初始状态、超时与预算一致，然后记录每次差异。若任务失败集中在第一个授权检查，可能是策略表达不清；若失败发生在工具写入之后，可能是返回值误读、幂等处理或异步状态检查有问题。把20次结果折成一个平均分，会丢掉定位线索。可以把失败分成“目标字段未变”“错改其他对象”“多余外部动作”“策略违规”“超时未定”等互斥或可并列的类别，复测修复是否真正命中原因。
连续全过也不是绝对可靠的证明。20次里没有失败，只能说明在这20次固定条件下没有观察到失败；上线后人员资料、权限、数据质量和外部接口都会变。业务风险高的场景还需要扩大样本、增加扰动和灰度监控。最危险的误读是把“20次都成功”当成一张不必再盯的许可证。相反，如果几次运行出现同一种破坏性副作用，即使总体通过率可观，也应先暂停自动写入。
把一次失败留在测试环境，而不是留给客服
真正有用的失败注入，不是随手断开一个接口看Agent会不会道歉。要先写出业务预期：读取超时后是否允许重试，写入返回超时但后台已经提交时是否会发生第二次写入，审批人在任务运行中撤销权限时是否应该停止。对每种情况，测试人员分别记录“观察到的终态”和“允许的终态集合”。如果业务允许一个订单保持待确认状态，这也应明写；不要把所有未完成都算作同一类错误。
幂等键尤其适合写入类任务。Agent收到工具超时，可能不知道上一笔请求是否成功；若简单重试，就可能生成重复通知或两笔申请。实现端可用唯一业务操作标识拦截重复提交，检查端则核对最终只有一笔有效副作用。这里不能只看Agent说了“我不会重复”，必须让重复的工具调用实际跑一次。对于不可补偿的资金动作，测试和生产都应加入人类确认，不能靠优秀的平均分放宽。
有些任务不存在唯一的黄金数据库快照。例如两种等价的审批路径都符合法规和内部制度，却会生成不同流水号。这时可以用状态不变量代替逐字段全量相等：金额守恒、只有指定账户被修改、审批顺序满足限制、消息不发给未授权对象。ThinkingBox强调黄金状态核验，但企业照搬方法时应先确认自己的流程到底是唯一终态还是一组合法终态。把合法差异误判成失败，会逼团队去优化错误的指标。
给采购和实施团队的一份验收单
先选一条有权威终态、失败后果可说明、当前人工处理方式可对照的流程。比如IT工单分类后的状态更新，或已获批准的服务目录维护。把用户请求拆成目标、禁止动作和有条件动作；找业务负责人签认“什么算完成”，再让工程师把它们写成断言。没有业务签字的黄金状态，往往只是在复现开发者对业务的猜测。
然后做数据隔离和权限收缩。每项工具调用的可写范围、单次额度、审批阈值与出错后的补偿路径都写进方案；对不可逆动作保留人工确认。测试集要有正常任务、缺字段任务、越权请求、重复请求和工具异常。不必为了追求题量在最初就攒出507条，先让十来条真正高风险的任务拥有可靠断言，通常更能发现问题。数量是覆盖广度的一部分，不能替代断言质量。
最后按运行维度交报告，而非只交一段Agent演示视频。报告至少给出任务级通过、连续重复通过、错误副作用、授权违规、平均与尾部耗时，以及失败轨迹可追溯性。门槛须由公司自行按风险设定：可撤销的内部目录变更，和会影响资金或客户权益的操作，不应使用同一通过线。验收后继续监控线上状态偏差，版本一变就回归测试；工具适配器、策略文案和数据模式更新都可能改变原来合格的结果。
先和现有流程比，再考虑扩大授权
验收还要有对照组。人工处理同一类工单平均需要多久、会犯什么错，现有规则引擎能否更便宜地解决问题？Agent若只是替代一条可确定执行的SQL更新，增加模型调用未必划算。对确需理解自然语言和处理例外的流程，也应记录每次任务的工具调用次数、人工复核工时和错误恢复成本。只统计模型单次推理价格，容易漏掉失败回滚、客服解释与重新审批的费用。
上线顺序可以从“只读建议”转到“人工确认后写入”，再进入小范围自动写入。阶段推进的依据应是本地任务的终态通过情况与错误副作用，而不是供应商通用榜单上的名次。灰度期间，自动把Agent计划的变更和实际后台差异放在同一张审计视图里；只要出现越权写入，就把相关动作退回人工。这样的闸门不神奇，却比上线后追问一句“Agent为什么这么做”有用。
检查器也要接受检查
把最终状态设为验收标准之后，检查器本身便成了质量瓶颈。若测试脚本只断言订单“已关闭”，没检查关闭原因和关联通知，Agent可能在错误条件下关单仍被判通过。每条断言应能追溯到业务规则，失败时输出最小、明确的差异；业务负责人抽检通过样本时，也应看有没有漏掉的副作用。检查器版本改变后，旧成绩不能直接与新成绩比较。
推荐保留几条人工构造的反例：正确写入目标但多改一行，收到工具成功却没提交事务，策略禁止时依然发出通知。让检查器逐一拦下，再用随机任务做抽查。审计人员若能在几分钟内从失败报告定位是哪一行、哪一次调用出了问题，测试集才有长期维护价值。否则“最终状态评测”很可能退化成另一种无法解释的总分。
真正该带走的判断
ThinkingBox把“回答得好”与“任务做对”拆开。507条合成工作流、重置沙箱、黄金状态和20次重复试验，可以借来设计验收；本地业务规则仍要企业自己定义。采购评审应要求供应商演示后台差异与失败案例，技术团队应把最终状态和副作用写入自动验收。一个Agent如果无法解释它修改了什么、为什么能改、还有什么未完成，就不要让那句“完成了”成为放行依据。
参考资料
- Microsoft × Hugging Face，《The Agent Said It Was Done. The Database Disagreed.》，2026-10-03：ThinkingBox的507个工作流、状态评测和重复运行方法。
- Microsoft / Hugging Face，《ThinkingBox-Bench v1.0》数据集：黄金数据库状态、执行检查及基准许可说明。
- AccessAllGPT Research，《Microsoft and Hugging Face Bring ThinkingBox’s 507 Stateful Agent Workflows to OpenEnv》，2026-10-04：OpenEnv集成及20次重复运行的交叉材料。