评测请求发出后，关闭进程、等结果、再接着打分，比一直占着脚本窗口更适合大规模回归测试。但恢复时如果重新点击“开始”，同一批问题也可能重新计费。Braintrust在10月15日介绍workflow evaluations，将异步提交、结果回收和评分组织到同一实验中。真正值得企业团队关注的，不只是批量接口的价格，而是任务跨进程以后，如何认出原来的那次运行。

快速看点：任务生成和模型裁判都可接异步接口；多个测试项能够合并提交，再按编号归回各自结果；跨进程恢复需要持久化存储。Python能力仍处于公开预览，不能把可恢复直接理解为外部请求只会发生一次。

便宜的批次，不一定是更快的评测

一次Agent回归可能包含回答生成、工具轨迹检查和模型裁判。若每个测试项都实时调用大模型，成本会随样本与试验次数增长；不要求马上出结果的任务，才适合交给供应商批处理。Braintrust这次介绍的是对接这类异步服务，而不是发布一个新的推理模型。

其博客所说的50%折扣，指供应商批处理请求相对标准接口的定价，不是整个评测项目的总成本减半。数据准备、存储、评分、失败处理和工程维护并不会随之消失。若先生成答案、再把答案送去批量评分，两段等待还存在依赖关系，不能同时计作即时完成。

这也意味着，批处理更适合夜间回归、模型横向比较和允许延后完成的大型评分任务。面对必须及时反馈的线上故障或发布拦截，应先设定等待预算与超时处置，再决定哪些环节可以异步，不能只按单次调用价格选择链路。

从一条一批，变成多条共享一批

workflow evaluations把发送与收集分开：submit把请求交给供应商，collect在结果准备好后取回输出；轮询或webhook负责推进完成状态。各阶段的输出和评分最终仍归入一个Braintrust实验，团队不必把一夜之间陆续返回的结果手动拼成多份报告。

版本边界需要分清。Python基础工作流能力要求SDK 0.39.0及以上；将多个用例合成供应商批次的WorkflowBatchTask与WorkflowBatchScorer要求0.45.0及以上。该版本标签发布于10月7日，批量支持合并于10月5日，不能把15日的介绍文章写成所有代码当天首次开放。

合并记录显示，批量收集按custom_id对应到单个测试项，而不是假设返回顺序等于提交顺序。缺少结果或某项报错时，需要保留该项失败状态；任务失败也不能当成得到了可评分答案。合批降低提交数量，但不会让数据缺口自动变成通过。

批量评分还支持最大条数和等待窗口，未凑满的批次可在窗口达到或不再有任务结果到达时推进。这里的等待检查发生在评测被推进时，并非自动启动一个后台计时器。平台仍要安排轮询或事件处理，否则配置了等待时间，也不代表无人值守就能结束。

恢复要带原编号，不能重新开始

跨进程运行的关键资产是run_id。start会创建新运行并再次提交请求；继续原任务应带上已有编号执行poll或结果处理。交付人员需要把这个编号与数据集、评估定义和供应商批次关联保存，而不是只在临时终端里看一眼输出。

内存存储适合整段运行都留在同一进程的示例。若希望进程退出后由另一进程接续，可使用Redis等持久化存储，并保持相同存储与评测定义。文档中的Redis记录默认七天过期，因此恢复窗口还要与任务周期匹配，不能把持久化误解为永久保存。

事件回调也有自己的边界：结果处理接口不会代替应用验证通知来自谁，接入端要核验供应商签名；事件可能重复到达，收集函数必须允许安全重复执行。只处理完成通知而忽略失败、过期或取消事件，会留下无法结束的等待任务。

出错后的恢复更不能一概重跑。文档说明，供应商重试和取消仍需集成层负责；某些永久失败会使后续轮询继续报错，需要修复原因并按明确范围另开运行。公开预览接口可能变化，接入时还应固定SDK版本，验证部分结果、超时和进程退出场景。

小编判断：先算清等待，再证明没有重付

这次更新的实用价值，是把评测从一个持续等待的函数，变成有身份、有状态、可分阶段推进的交付流程。它与此前把应用日志接入轨迹的功能不同：前者组织离线评测执行，后者帮助追查运行问题，不能因同属可观测工具就混成一件事。

企业试点不妨先选一组固定回归样本，记录提交次数、完整回收率、总耗时和全链路费用，再测试重启及重复事件。只有输出与评分完整、恢复没有意外重复计费，批处理折扣才真正转化为可持续的运营收益。更低的单价是起点，可解释的完成状态才是验收依据。