演进响应四动作：保持 / 简化 / 升级 / 替换

演进不是「要不要升级模型」

模型每个季度都在变强、变便宜。已经上线的系统面对的问题不是「要不要用新模型」，而是当外部能力变化时，系统应该发生什么变化。

错误的默认反应有两种：一种是永远不动（错过删复杂度的窗口），另一种是每个新版本都追（把系统变成永远在搬家的工地）。第三种态度是把演进当成一个有触发器、有评测、有固定动作集的运行流程。

触发器

出现下列任一情形，启动演进评估（不是启动改造）：

• 模型升级或降价；
• 新能力出现（长上下文、多模态、工具可靠性提升）；
• 接口标准变化；
• 依赖弃用 / 供应商变化；
• 新安全威胁；
• 成本结构变化。

铁律：先跑本地评测集

无评测基线不动手。 T5「评测与验收包」是回归安全网：动任何东西之前先在本地评测集上跑一遍现状分数，动手后再跑一遍对比。没有这一步，你的「升级」不可证伪。

模型迁移还要额外注意：换了模型不等于行为不变。有团队实测过——换代之后「先查工具再回答」这类隐含习惯不再稳定，需要在指令层加显式原则，并为每个模型维护独立的评测基线。换评分模型同样要重新校准，不同模型之间的一致性可能低到没有参考价值。

四动作

简化的典型形状：微调 → 提示词；多步 pipeline → 一步；多 Agent → 单 Agent；复杂解析 → 模型直读。每一次简化都要重新验证两件事：可靠性没有下降、正确拒绝（该不做时不做）没有变差。

升级的典型形状：原来必须人审的环节可以自动化；原来做不了的任务现在能做。注意——自主动作扩大意味着错误代价暴露面扩大，审批点不得随手放宽。要放宽，先重做错误代价评估。

演进是双向的

能力增强既可能让系统变简单（删护栏），也可能放大风险（自主范围扩大、副作用增多）。所以演进不是单向简化，而是重新匹配「自主程度 × 错误代价」：模型变强了，你可以把系统做简单；同时你要确认新的自主范围仍然错得起。

重构纪律五条

1. 无评测基线不动手（T5 先行）；
2. 一轮只改一个变量，灰度对比；
3. 方向是删复杂度，不是加功能；
4. 契约/边界/审批点是安全带——放松前必须重做错误代价评估；
5. 变更记录进 T6，包括「我们这次选择了保持」。

可演进性是设计出来的

想让四动作便宜，系统设计期就要预留：模型可替换边界、规则与模型分离、工具契约稳定、评测集是资产、版本关联、降级路径预置、知识与事实分离。这七项不是架构装饰，它们决定了下一次模型发布时你花的是两周还是两个季度。

小结

技术演进是做减法的机会窗口。收到「模型又升级了」的消息时，默认动作是：跑评测 → 问「可以删掉什么」 → 四动作选一 → 删完重测 → 记录进 T6。