模型变强了，你的系统该变简单

模型发布日，工程团队的标准动作是：评估要不要升级。我的建议是反过来先问一句——这次可以删掉什么？

每一层复杂度都是对模型缺陷的补偿

回头看那些为了弥补模型短板而存在的东西：

• 微调，是为了让模型懂你的领域——现在提示词里放几段领域说明就够了；
• 多步 pipeline，是因为模型一次做不完长任务——长上下文与更强的指令跟随让一步成为可能；
• 多 Agent 协作，是因为单 Agent 能力不够——它同时带来了通信开销与不可预测性；
• 复杂的解析与格式修复层，是因为模型输出不稳定——结构化输出在变可靠。

这些不是架构，是伤疤。模型变强时，伤疤应该被重新评估：还要贴着吗？

但「变简单」不是免费的

反方向的力同样真实：模型变强 → 你敢给它更多自主权 → 自主动作范围扩大 → 错误代价的暴露面也在扩大。

一个只能读资料的助手，出错是「答案不好」；一个能写生产系统、能下单、能发消息的 Agent，出错是「事故」。所以每次演进要做的是重新匹配：

自主程度 × 错误代价

模型能力上升一档，你可以选择：删掉一层护栏（简化），或者扩大一格自主范围（升级）。不能两个都做——那是把安全带拆了再踩油门。要扩大自主范围，先重做错误代价评估，审批点不许随手放宽。

演进的四个动作

收到「模型升级了」的消息，按流程走：

1. 先跑本地评测集（无基线不动手）；
2. 保持：评测达标就不动——最常见的正确答案；
3. 简化：能删护栏/删步骤/删 Agent 的，删完重测可靠性与「正确拒绝」；
4. 升级：新能力打开新价值的，回最小闭环重走一遍，审批点逐个重估；
5. 替换：依赖弃用或成本结构变化的，换实现但保持工具契约，换完全量回归。

一轮只改一个变量，灰度对比，记录进运行台账。「我们这次选择了保持」也是一条值得记录的决策。

结论

模型变强是做减法的机会窗口，不是加功能的发令枪。每一轮演进先问「可以删掉什么」，删完必须用评测证明可靠性没有下降；同时盯住自主范围——扩一格，错得起吗？

系统该变得简单，但方向盘（评测集）和安全带（边界与审批）不能一起扔。