模型与Harness升级矩阵

通过交叉比较区分模型、harness及二者交互带来的变化。

模型升级可能改变工具选择、规划、schema行为、上下文利用和停止方式。新模型整体更强，不保证原Agent在所有任务上更强；旧harness中的强制短计划、频繁reset或冗余自评，可能限制新模型发挥。升级应比较模型与harness的交互，而非只跑一个新模型分数。

最小矩阵包含旧模型配旧harness、新模型配旧harness、旧模型配新harness、新模型配新harness。这样可以分辨质量变化来自模型、外围工程还是组合。Prompt、工具、检索、memory政策和verifier都应记录版本；同时变太多因素会使根因不清。

先通过协议契约测试，再做代表业务任务。前者检查工具call ID、stream、schema、拒绝和取消，后者检查证据、计算、权限与真实后置条件。对旧workaround进行消融：保留原规则、删除补丁和使用新默认设置分别比较，避免“更复杂”被当成“更可靠”。

评测要保留未见样例和严重错误分类，单次最佳表现不能替代稳定性。上下文压缩、冷缓存和工具故障也应进入升级场景。主模型与judge同时升级时，评分变化可能来自评估器，因此需保持一条稳定校准路径。

通过离线门槛后再shadow和canary。Shadow若有真实外部工具，必须禁用副作用或采用隔离后端；否则影子流量也可能重复发信或写入。回滚应恢复完整版本组合，而非只改model ID。

公开模型目录和框架文档给出能力入口，具体企业任务必须自行验证。供应商未提供固定snapshot时，记录复现限制并持续跑哨兵样例。模型发布当天可以进入候选，不必自动成为生产默认。

对于会执行外部动作的用例，升级实验需要测试后端或明确只读模式。重复跑同一评测，不应向真实客户重复发信或修改正式记录。评测隔离本身也是发布合同的一部分。

实践重点：比较旧旧、新旧、旧新、新新；删除旧workaround做消融。

验证抓手：先兼容性和离线任务，再shadow、canary与完整回滚。

常见误区：更强模型上线后原Agent反而退化却无法归因。

Pydantic AI：Harness能力边界；OpenAI Agents SDK：模型与provider。