系统设计的权衡

架构上的每一个决定都在买东西，而代价是另一样东西。没有代价的决定不是权衡，是常识——真正的问题从来不是「哪个更好」，而是「你愿意为什么付钱」。这个判断在 AI 系统里没有变，只是付钱的位置换了。

先分「可逆的」和「锁死的」

这是最有用的一次分类，因为它决定了你该花多少时间在这个决定上。可以晚点再定的，就晚点再定；一旦定了就会锁死后续所有选项的，值得当场吵清楚。

MCP 2.0 是这一类里最干净的例子。把协议核心从有状态改成无状态，表面上是删掉了握手和会话 id，实质是把「同一个会话必须落在同一个实例」这条约束从架构里拿掉——于是负载均衡、扩容、故障恢复三件事同时变简单。它改变的不是一个功能，是后面每一个部署决定的可选项。

状态几乎总是最贵的那一项

有状态换来的是「少传一点数据、少算一遍」，付出的是「请求必须回到同一个地方」。这笔账在单机上看着划算，一旦要横向扩，代价会一次性全部到账。所以看到「为了性能把它缓存在实例里」这类说法时，先问一句：这是省了多少，锁死了什么。

每一层抽象，都是拿控制换省事

「Copilot 与裸 API」那条信号里，模型层的价差被抹平之后，剩下的决定就是你要拥有哪一层——外壳、工具层、还是只有权重。往上走一层，你少建一些东西，也少了一些能改的地方。

这里还有一个容易被忽略的形态：默认值本身就是一次权衡，只是别人替你做了。vLLM 把 Model Runner V2 定为默认执行引擎，等于把这个取舍一次性推给了所有用户；受影响的人如果没读发布说明，会以为自己什么都没选。

写下来的那一句，决定六个月后还能不能改

一条能用的决策记录有三段：我们选了 X；因为在我们的场景里 A 比 B 重要；如果 A 不再重要，就应该重新考虑。 大部分记录只写了前两段，于是六个月后没人知道当初的前提还成不成立，也就没人敢动它——权衡退化成了惯例。

具体到某一项怎么量，交给别的条目：延迟那一项去看《交互系统中的延迟权衡》，「哪个约束先咬人」去看《模型选型与约束匹配》，本地与云那条线去看《本地与云混合推理架构》，而「自建还是采购」是《AI 工具链选型与自建边界评估》要回答的。这条只负责一件事：先认出你正在做的是一次权衡，而不是在选一个更好的东西。