不要只靠模型排行榜切换 Agent：用 World Model Optimizer 从 OTel 轨迹做可回放的路由决策
给 Agent 换模型时，团队常见的流程是：看到一个更便宜或在某项榜单上更高的模型，然后把默认模型替换掉。这个流程的问题不只是评测与生产任务不一样，更在于它把“模型能力”“工具调用方式”“提示词与技能”“任务分布”混成了一个不可回放的结果。某个模型在通用基准上表现好，并不能证明它在你的 API、权限边界、检索质量和失败重试策略下同样合适。
World Model Optimizer（WMO） 是 Experiential Labs 发布的 Python 工具。仓库根目录当前没有可供确认的项目许可证文件，因此本文不将其表述为开源或 MIT 许可；采用前应由团队自行完成许可证与依赖项审查。它的思路不是为每个问题猜一个“最强模型”，而是读取已经采集的 Agent 轨迹，建立一个可交互的环境模型；随后在留出的轨迹任务上测量已登记的候选模型，为端点生成路由策略。项目同时提供 harness 优化和模型蒸馏能力，但第一次落地时，把它当成“基于自家轨迹的路由实验台”更容易控制变量。
这篇文章聚焦一个很具体的场景：团队已经能导出 OpenTelemetry（OTel）轨迹，想评估不同模型在现有 Agent 工作流中的取舍，但不希望直接在线上把所有请求分流给实验模型。
先明确：轨迹不是聊天记录，也不是万能测试集
一条可用于此类实验的轨迹，应至少能让系统重建任务、动作与观察结果之间的顺序关系。例如，Agent 调了什么工具、带了哪些参数、工具返回了哪一类结果、下一步又做了什么。这样得到的不是通用世界知识，而是一个围绕团队既有工作流的局部环境近似。
它有两个重要边界。第一，模型只能从已有轨迹所覆盖的分布中得到评价；从未出现的新业务流程、突发权限错误或第三方接口大改，仍要靠集成测试和灰度监控。第二，轨迹里若包含错误的成功判定，优化器只会更有效率地放大这个问题。因此，在导入前应先确认采样是否覆盖成功、失败、重试和人工接管路径，而不是只挑“顺利完成”的会话。
WMO 的仓库文档把数据边界写得很明确：训练、验证与测试应是确定性切分；用于提示优化和知识提取的内容来自训练集，而最终评估保留未触及的测试数据。这个约束的价值在于，别让同一段轨迹既参与构造环境又参与宣布候选模型胜出，否则报告中的提升可能只是对已见样本的记忆。
从 OTel 文件建立端点模型
安装后，先登记你实际可以调用的模型提供商。官方 README 给出的起点是：
pip install world-model-optimizer wmo providers set
wmo providers set 会将可选模型记录到项目内的 .wmo/pool.toml。这里建议只登记已完成成本、数据处理和区域合规审查的提供商；路由实验并不会替你完成密钥管理或供应商风险评估。
接着，把导出的轨迹文件构造成一个命名端点，并在留出的任务上测量候选模型：
wmo build --file traces.jsonl --name support-agent wmo optimize route sweep support-agent --traces traces.otel.jsonl wmo optimize route fit matrix.json --kind knn \ --out .wmo/models/support-agent/policy.json
这三步有不同职责。build 将轨迹变成可供后续运行与评估使用的模型目录；route sweep 产出候选模型在轨迹任务上的测量矩阵；route fit 再从矩阵拟合一个 KNN 路由策略。不要把第三步理解成“神奇地发现最佳模型”：它只是把已经获得的比较结果编码成策略文件。测量输入不完整、任务标签错误或成本字段缺失时，策略同样会继承这些缺陷。
用报告把“更便宜”拆成可审阅的结论
策略生成后，可以启动命名端点，并与既有基线做报告对照：
wmo serve --name support-agent wmo optimize route report matrix.json \ .wmo/models/support-agent/policy.json --baseline gpt-5.5
WMO README 的示例使用 gpt-5.5 作为基线参数；实际使用时应替换成团队当前真正的默认模型。报告应回答三件事，而不应只有一个平均成本数字：路由把哪些任务交给了哪些模型；相对于基线，留出任务的完成或断言表现是否回退；成本降低是否集中在低风险、低复杂度请求上。
一个实用的审阅方式是按工具链路分桶。例如把“只读检索”“单次结构化写入”“跨系统变更”分开看。若策略只在只读检索上节省成本，却在写入路径增加失败重试，就不该用一个总平均值掩盖风险。对于具有副作用的工具调用，离线模拟报告只能作为准入证据之一；仍应保留审批、幂等设计、速率限制和生产告警。
给策略增加一条“不要路由”的失败门
离线矩阵中最容易被忽略的结果，往往不是哪个模型胜出，而是哪一类任务没有足够证据支持自动选择。比如轨迹数量很少、工具返回高度依赖实时库存，或者成功条件只由人工在工单系统中确认；这类样本即使算出了成本，也不应被强行归入某个低价模型。实际策略评审时，可以为每个任务簇同时记录样本量、失败原因分布、人工接管比例与最近一次数据更新时间。样本不够或失败类型变化明显的簇，应该回到基线模型、进入人工审批，或仅做观察性分流。
还应把“路由失误”定义成可观测事件，而不是等用户投诉后再回看平均指标。对有副作用的工作流，至少把下列信号与路由版本关联：工具调用被拒绝、重试次数超过阈值、任务超时、补偿动作发生、人工撤销，以及最终业务状态不符合预期。这样下一轮导出的轨迹不会只记录模型输出，还会带上策略在真实边界处失败的证据。版本化保存 policy.json、输入轨迹快照的标识和报告命令，也能让团队在异常出现后回答：当时为什么会把这次请求分给这个候选，而不是仅凭记忆追溯一段配置变更。
何时该进一步优化 harness，何时不该
模型路由解决的是“给这类请求分配哪个已登记模型”。如果同一个模型在某些任务上失败，根因也可能是 Agent 的工具策略、技能提示或执行循环不合适。WMO 还提供 wmo optimize harness：项目说明称候选 harness 可以改变提示词、工具、策略、技能和运行时代码，并通过闭环评估门槛后才成为新的版本化 champion。
这并不意味着每次效果不佳都要自动优化。harness 变更比路由更容易扩大行为面：工具权限、最大轮次、提示词和运行时代码都可能影响真实执行。更稳妥的顺序是先固定 prompt、工具集合和测试任务，完成一次仅比较模型路由的实验；如果失败样本稳定地指向同一类规划或工具使用问题，再单独建立 harness 实验，并把候选版本、评测集版本和回滚条件写入变更记录。
WMO 还支持将本地优化放进 E2B 沙箱执行。官方示例使用 pip install "world-model-optimizer[e2b]"、E2B_API_KEY 与 --backend e2b。这适合需要隔离真实 worker 进程的评估，但要注意它隔离的是执行环境，并不自动证明模拟环境与生产完全一致；网络、身份、数据快照和外部服务副作用仍需单独定义。
把实验结果接到发布流程，而不是直接接到全量流量
一个可落地的最小流程可以是：每周从已脱敏的 OTel 轨迹生成固定版本的数据集；对当前基线与两三个候选运行 sweep；审阅完成率、失败类型和成本报告；将通过门槛的策略先用于低风险流量；最后把线上异常、人工接管和新增任务重新纳入下一轮轨迹。
这样做的核心不是追逐某个“省 40%”的宣传数字。WMO 的 README 将其定位为把既有轨迹用于持续改进，并提出成本下降的目标；对任何特定团队而言，实际收益必须由自己的留出任务与线上观测确认。真正有价值的是让路由选择从一次不可复盘的配置修改，变成带数据版本、基线、策略文件和失败边界的工程决策。