想检查客服智能体有没有按规定返回字段，不一定要再问一个大模型。团队可以写一段Python规则，但让评测服务器直接执行别人注册的代码，又会把服务器本身暴露给这段规则。MLflow 3.18.0把代码型评分器带入在线评测，并提供实验性的作业容器：服务器负责挑选轨迹和保存结果，评分函数可以放进一个短时运行、没有网络的容器。关键在于正确启用这条执行路径。

快速看点：代码可评新轨迹或整段会话；无网络容器不是默认配置；升级时要同时确认部署形态、作业镜像和旧数据迁移。

在线评分是事后检查，不是请求前的门禁

这里的“在线”不是模型回答之前插入一道审批。应用先记录轨迹或会话，MLflow再用配置好的规则抽样评分，记录评估结果。规则可以检查结构、字段或工具调用组合。例如退款申请助手必须返回订单号和固定状态码，评分函数可以检查字段是否齐全，却不能仅凭字段通过就断定退款符合业务条件。

这类代码通过装饰器定义，注册时平台保存函数源码。对单条轨迹运行的评分器，结果记在相应轨迹；会话评分的结果则记在该会话的首条轨迹。这样可覆盖多轮行为，但同名会话评分重新运行后，可替换早先同名代码评分结果，因此若要做版本对照，团队应事先规划名称和结果保留方式。

功能也没有把历史数据自动补评分。对已经记录的轨迹，指南建议在编写规则的环境使用本地评估接口；容器化在线评分面向随后记录的数据。没有标准答案输入的自动评测也不适合直接替代带人工标签的离线回归集。

隔离的是评分代码，采样与写回仍归服务器

配置好Docker后端时，服务器先挑选和准备轨迹，再把该作业需要的内容交给容器；评分器代码在容器执行，输出由服务器校验后写回。容器只能看到自己的输入，输入挂载为只读，也不继承服务器凭据。容器不能调用外部API或模型；需要模型裁判时，仍应使用另一路服务器侧的评分机制。

这项隔离不能只靠“启用自定义评分”得到。文档要求分别允许代码型评分器、选择支持作业容器的执行引擎，并指定Docker执行后端。仅允许自定义评分却没有指定容器后端，代码可以直接在宿主执行。反过来，正确配置后，容器不支持的作业会失败，不会为了继续评分而回退到宿主。

容器并不替企业完成数据治理。评测输入仍可能带着提示词、客户字段或工具返回，应由团队控制采样及脱敏。规则所依赖的库要随镜像准备好，不应在运行中临时下载安装；还要为超时、输出过大或依赖缺失安排可辨认的错误处理，不能把未评分的轨迹当成合格。

先核对自托管条件，再谈扩大生产覆盖

上游给出的条件包括Linux或macOS自托管服务器、数据库后端、同宿主的Docker或兼容套接字，以及单个服务副本。服务端和作业镜像应保持版本一致。说明没有把这种执行方式承诺为多副本生产方案，也没有把普通类形式的评分器、依赖联网的校验或所有混合评分组合列入支持。

时间也要分开看：变更日志的版本标题标11月2日，PyPI显示包于11月3日上传，GitHub正式发布条目显示11月4日。SQL后端升级还应单独安排维护窗口，按版本说明先备份并停止写入再做迁移；是否升级和是否启用实验评分能力，不必成为同一个上线决定。

试点可用一组非敏感轨迹，分别覆盖规则通过、明确失败和规则执行超时，再检查服务器是否正确区分评估结论与执行错误。还应验证未配置网络时任务不会悄悄依赖外部服务。这里没有运行容器、评分器或升级数据库，不能把文档中的隔离描述当成对实际部署的安全审计。

另一个容易漏掉的检查是容器失败后的告警归属。评分规则报错、输入未采到和业务回复不合格，是三件不同的事；值班人员应能从记录里区分它们，再决定是修评分代码、调整采样，还是回到业务系统排查。

小编判断

这次变化适合那些已经能写出明确规则、却不想把评分脚本与服务进程混在一起的团队。先挑一个可重现的结构检查，保留离线样本和人工复核，再小比例采样在线轨迹。验收应分别问：哪些代码获准运行、它能看到什么、失败如何显现。回答清楚这三件事，比单纯扩大评分覆盖更重要。