很多智能体的评测在上线那天就停了。设计期跑过的那套数据集留在开发环境里，而生产环境跑的是另一回事：模型会换代，提示词会被改，输入会慢慢漂移，被调用的工具接口有时在没人通知的情况下就动了。只在发布前评一次，等于让用户替你发现故障。10 月 20 日，UiPath 在官方发行说明里给出了一项预览功能：运行时评测（runtime evaluations），给已经部署的智能体定期打分。
机制并不难懂。针对某个已部署的实例，用数据集（输入加期望输出）给它评分，可以手动触发，也可以按计划重复执行。文档里反复强调的一点很有价值：评测打的是「部署中的那个实例」，不是设计期的副本——因为设计期那一版里没有生产数据、没有真实工具、也没有被改过三遍的提示词。
评测器分成三类，各管一段。输出校验跑确定性检查：包含文本、精确匹配、JSON 相似度，便宜且每次结果一致。LLM 裁判用模型来打分，能接受措辞不同但语义正确的答案，分四类——输出、严格 JSON、轨迹、模拟执行，每一条判分都附理由；代价是成本与偏置。工具调用校验看的是过程：参数对不对、调用次数是否超标、顺序是否走岔、返回值是否匹配。最后一类是关键所在——一个智能体完全可能给出正确答案却走了错路：调了不该调的工具、跳过了该走的审批、多绕三圈才到终点。只看最终输出抓不到这些，而生产里恰恰是这类问题最贵。
数据集怎么攒也有新意。已完成的真实生产运行可以直接转成数据点，文档建议优先把失败案例和边角样本收进来；生成式样例与业务团队导入的用例是另外两个来源。副作用必须模拟：评测跑的是真实例，工具是活的就会真的发信、真的建单、真的把单子塞进某个人的待办里，所以凡是对外产生变化的工具与人工复核步骤，都该交给静态替身或生成式响应接管。运行节奏上，文档给出的建议是「每次变更跑一遍，外加定时查漂移」，频率按自己依赖变化的速度自定，官方没有给默认值。
增量读法：这项功能把评测对象从「答案对不对」扩到了「路走得对不对」，正好接上本站近期跟踪的评测盲区线索。2112 那批工作指出基准与规约之间存在缺口、自动检测器与人工判定在不少用例上不一致、harness 自身的变化能让跨系统准确率失去可比性；2009 记的 AWS 九阶段评估框架讲的是上线之前的门。UiPath 这一项把门挪到了上线之后，并且把工具调用序列纳入评分，等于把流程合规变成了可以按天打分的项目。
冷水三盆。它仍是预览功能，可用性边界与配额都还在调整；LLM 裁判本身有偏置也有成本，分数高不等于判定正确，判分理由需要人工抽检；最有用的一类——轨迹裁判（LLM Judge Trajectory）——暂时还不能放进定时计划，也就是说「路走得对不对」目前还得手动触发，恰好是最该自动化的那一步没自动化。目前官方及行业暂未披露更多细节，后续将持续跟进迭代动态。值得盯的观察哨：定时轨迹评测何时开放，以及评测分数会不会真和授权挂钩——低于阈值自动收窄智能体的动作范围。