当架构范式迁移时

什么会变，什么不会

本文延续方法论视角--《AI 技术栈的收敛与分化》看同一时刻各层的收敛与分化（横切），本文看范式迁移时什么变、什么不变（纵切）。两篇一横一纵，同一套判断方法：找结构性位置，看它属于哪一层。

本文判断截至 2026 年 7 月；分层框架为方法论推导。

零、起点

架构经验在 AI 时代作不作数，取决于它属于哪一层。AI 应用的技术栈可以分成三层，其中两层没变，一层变了：

• 底座层--云计算基础设施。容器、队列、N 层、微服务、负载均衡。没变，仍然是 AI 系统的物理承载。
• 心法层--架构师做决策时依据的根本判断。价值定义、取舍方法、验证回路。没变，跨越范式。
• 设计对象层--架构师在顶层设计的东西。从"数据流 + 业务逻辑 + 交互协议"变成"能力注入 + 行为循环 + 评估飞轮 + 记忆沉淀"。变了。

底座没变，心法没变，变了的是设计对象。所以旧经验不是全盘作废，也不是全盘照搬--底座层直接复用，心法层抽象后迁移，设计对象层重新学。本文把这三层逐一打开。

一、底座没有变

先说最没争议的一层。

云计算基础设施没有因为 AI 过时。一个 AI 应用在生产环境跑起来，拆开看，绝大部分组件仍然是传统云架构的那一套：

• 推理服务跑在容器里，由 Kubernetes 调度和扩缩容
• 异步任务（批量 embedding、离线 eval、bad case 处理）走消息队列
• Agent 调用的工具挂在 API 网关后，带认证、限流、超时
• RAG 的向量数据存在向量库或带向量扩展的关系库
• 监控、告警、日志、链路追踪，和十年前一样

这不是"AI 应用碰巧也用到了云原生组件"，而是"AI 应用架构是坐在云基础设施上面的新层"。变化不是替代，是分层。

要诚实补充两点。第一，底座的软件基建--容器、队列、微服务、监控--没变，直接复用；但底座多了一档工作负载：模型推理，跑在 GPU 上，架构师除了会调度 CPU 资源，还要会调度 GPU 和显存。第二，底座上长出了一层 agent 运行时组件：代码执行沙箱（给 agent 的工具调用隔离环境）、持久执行（长时 agent 崩溃后的状态恢复）、agent 身份（非人身份的认证授权）、AI 网关（token 级限流、语义缓存、prompt injection 防护）。组件清单明显变长了。但注意这些组件长在哪：沙箱是 K8s 的扩展，AI 网关是 Gateway API 的扩展，agent 身份是 IAM 的扩展--全部长在现有底座上。所以"分层不替代"的判断不是被削弱，是被强化：新组件一层层在长，底座一层层在承接。这是底座为适应 AI 做的扩展，不是底座被谁替代。

这层的结论：底座的结构经验直接复用，不需要重学；要补的是组件清单上的新面孔--GPU 调度、沙箱、agent 身份这些"长在旧底座上的新组件"，学的是用法，不是新范式。真正要重学的是上面两层。

二、心法没有变

心法层是这篇文章最有价值的一层，也是范式迁移期最容易被忽视的一层。

注意力天然被"新东西"吸走--新模型、新框架、新范式。但架构师真正稀缺的能力不是追新，是判断。而判断所依据的心法，跨越范式不变。三件事。

价值定义

架构的第一步不是选技术，是定义"这个系统要交付什么价值"。这是老生常谈，但在 AI 时代特别容易丢--因为 AI 的可能性太多，诱惑太多。

一个 AI 客服应用，价值定义是"把 60% 的工单自动解决，剩余 40% 转人工且带好上下文"，还是"把每个工单的回答质量做到人工水平"，这两条路线后面的技术选型完全不同。前者是"省钱"，要的是任务完成率和成本；后者是"提质"，要的是回答质量和可控性。价值定义不清就动手选模型、写 prompt、搭 agent，后面全是空转。

这条心法在传统架构里就叫"先定义要解决什么问题"，AI 时代没有变，只是更难--因为 AI 的价值边界更模糊（"智能"本身难量化），更需要架构师主动把它钉死。

取舍方法

架构是取舍。运营卓越、安全、可靠、性能、成本、可持续，六个支柱不可能同时最大化。选哪两个优先、哪两个妥协，就是架构指纹。这个方法跨越范式不变。

AI 应用多了一个新变量，让取舍更尖锐：智能性。智能性、延迟、成本构成新的三角--模型越大越智能但越慢越贵，模型越小越快越便宜但能力打折；RAG 加得越多召回越好但延迟越高；agent 循环越多解决能力越强但 token 成本和延迟都涨。

但变量变多不等于方法变了。取舍的方法还是那个：先定哪个维度是底线（必须满足），哪个是优化目标（越好越行），哪个可以妥协。只是 AI 应用的取舍表上多了一行"智能性"。但要补一句：心法没变，心法依赖的成本结构变了。AI 应用的成本多了推理 token、模型调用、数据标注这些项，随用量非线性增长。用传统架构的静态成本账做 AI 应用的取舍，是这层最容易犯的错。心法没变，变量多了，成本结构也变了。

验证回路

架构决策必须被验证，不能停在"我觉得这样设计对"。这是心法。

传统架构的验证回路是：监控 -> 告警 -> 压测 -> 故障演练。AI 应用多了一个验证维度--评估（eval）。但"验证回路"这个心法没变，变化的是验证的对象和手段（下一部分展开）。

这里要强调的是：AI 应用因为行为是概率性的，验证回路比传统架构更重要，不是更不重要。传统架构功能测过就是对，AI 应用没有"测过就对"，只有"在 eval 集上持续达标"。这倒逼架构师把验证从"上线前的一道工序"提升为"贯穿始终的核心活动"。

三件事为什么不变？因为它们是"做工程"的心法，不是"做某种工程"的心法。范式变的是被设计的东西（设计对象层），不是设计本身的逻辑。价值要定义、取舍要做、决策要验证--不管设计的是电商系统还是 AI 应用，这三件事都跑不掉。

三、设计对象变了

这是唯一变了的一层，也是架构师要重新学的部分。

传统架构师在顶层设计的是三样东西：数据流（数据怎么存怎么转）、业务逻辑（规则写在代码里）、交互协议（服务间怎么通信）。AI 应用架构师在顶层设计的是另外四样：能力注入、行为循环、评估飞轮、记忆沉淀。逐一讲。

侵入性光谱：能力注入的方式

传统架构里，业务逻辑写在代码里，是确定性的--写死一条规则，系统就按这条规则跑。AI 应用里，能力不是写死在代码里的，而是通过多种方式注入。这些方式对模型的侵入程度从低到高，不是几个离散选项，是两个极端之间的连续带--能力全在模型外（Prompt）是一端，全进模型权重（Finetuning）是另一端，中间可以落在任意位置。把这条带叫做侵入性光谱：

先校准一个术语：prompt 和 RAG 在 2026 年的业界话语里已被收编进"上下文工程"--它们不再是两个独立位置，而是上下文窗口装配中的两个 slot，与系统提示、工具定义、记忆并列。这个收编不改变光谱的结构：上下文工程管的是"注入什么内容"，光谱管的是"能力边界放在模型内还是外"，两个问题正交。

这种连续带结构在架构里不是第一次出现。服务的粒度就是同样的一条带：从整个单体到细粒度微服务，选的是"一致性边界放多大"--边界越大（粗粒度），一致性容易保证但独立性弱；边界越小（细粒度），独立性强但分布式一致性成本高。侵入性光谱选的是"能力边界放在模型内还是外"：越往外（Prompt），改造越便宜但能力上限低；越往内（Finetuning），控制力越强但改造成本高。

两者的权衡是同构的：边界内放得越多，控制力和一致性越强，但改造成本和耦合越高；边界外放得越多，灵活便宜，但能力上限和一致性都打折。

关键 insight 有两个。

第一，这不是非此即彼，是在光谱上选点。同一个 AI 应用，不同能力可以落在光谱不同位置：基础领域能力 finetune 进模型，长尾事实用 RAG 外挂，临时指令用 prompt，复杂多步任务用 agent 编排。架构师的工作不是选一个，是给每个能力选对位置。

第二，选点不是一次定的。能力一开始用 prompt 验证可行性，验证后值得固化就沿光谱向内升级--外挂成 RAG、固化成 skill、内化成权重。这条光谱是"能力从外部挂载到内部内化"的连续路径，架构师要管的是能力沿光谱的迁移，不只是某一刻的选点。还要补一笔：迁移的主体多了一个--系统自己。离线复盘机制可以把反复出现的错误提炼成 playbook、把有效模式固化成 skill，不需要人逐案决定升级。系统开始自己沿光谱向内移动，这是光谱在 2026 年最大的变化，也是本文"记忆沉淀"一节的伏笔。

评估：从验收变成核心工程活动

传统架构里，测试和验收是工程活动的最后一环--功能开发完，写测试、跑测试、过了就上线。验收是"出口检查"。

AI 应用里，评估不再是出口检查，而是核心工程活动。原因是模型行为是概率性的：同一个输入，模型这次答对不代表下次答对，在这个 case 上好不代表在那类 case 上好。没有"测过就对"，只有"在 eval 集上持续达标"。

这个变化是本质的。传统架构的"正确性"是二值的--功能对就是对的。AI 应用的"正确性"是分布的--在多少比例的 case 上达标，达标的标准是什么，本身是一个需要设计的东西。于是 eval 集合从"上线前跑一次的测试集"变成"随业务持续演化的核心资产"，评估从"最后一道工序"变成"贯穿每次变更的回路"--改了 prompt、换了模型、加了 RAG，都要在 eval 集上回归。agent 时代评估的对象也从输出扩展到轨迹--不只测答案对不对，还测全程：工具选对没有、参数给对没有、失败后恢复没有。生产 trace 回流 eval 集的闭环（线上失败聚类后 promote 成回归用例）已成参考实现，这一点下一节飞轮展开。

这里还有个更深的难点：eval 集能不能逼近真实分布的尾部。在干净测试集上跑 99%，部署到真实长尾上可能立刻塌--可靠性不看平均情况，看尾部那 5%。这不是修辞：2026 年一项对 14 个前沿模型持续 18 个月的追踪测出，模型准确率年增 21%，可靠性年增仅 3%--能力在涨，尾部几乎不动。eval 集不是越大越好，是越逼近真实部署的长尾越好。顺带区分一个常见误读：近年"eval 失效"的批评声量很大，但矛头指向的是静态公共 benchmark（饱和加污染，失去区分度）；恰恰是私有的、持续的、贴近生产分布的 eval 工程在升值。批评的方向和这里的论点一致。

这意味着设计对象变了：传统架构师设计"功能 + 测试"，AI 应用架构师设计"功能 + eval 集 + 评估回路"。

进化机制：数据飞轮，第二条进化回路

传统架构的进化机制是 DevOps：线上出问题 -> 监控告警 -> 人定位 -> 人改代码 -> 部署。这是代码驱动的进化回路，节奏以天或周计。这条回路在 AI 应用里没有消失--CI/CD、监控、回滚都还在。

AI 应用多了第二条回路：数据飞轮。线上 bad case -> 归因 -> 修复 -> 回归验证 -> 反哺 eval 集。这条回路里，数据本身驱动系统进化--bad case 变成 eval case，eval 集随业务持续演化，系统的能力随数据积累而提升，不只是随代码改动而提升。

这里要诚实区分 bad case 的三条去路。第一条，bad case -> eval case，是通用的：任何 AI 应用都能把线上 bad case 沉淀进 eval 集，作为回归基线。第二条，eval case -> 权重信号，只对走 finetuning 或 RL 环境后训练的应用成立--只有这条路飞轮的结果能沉淀成训练数据，它要求模型所有权，纯调闭源 API 的应用走不了。第三条是 2026 年新开的：bad case -> 上下文层沉淀。不改权重，把归因结果、反复出现的模式、用户的纠正写进 memory、skill、playbook，跨会话持久改变行为。这条路已经被平台产品化（托管记忆、离线复盘机制），闭源 API 应用的飞轮不再到 eval 集就停。三条路不互斥：eval 集是底线，权重层和上下文层看条件选。注意"eval case 变训练信号只对改权重的路成立"这个判断仍然成立--上下文层沉淀改变的是行为，不是权重；变化的是行为的载体多了一个。

飞轮转不转得起来，瓶颈常常不在设计图，在物理供给--但两类供给的稀缺性不一样。算力买得到，干净的真实分布数据买不到。互联网本身大多是噪声，真实部署里回来的 bad case 才是干净信号。飞轮的价值不在数据变多，在数据变干净、变逼近真实分布。算力不够，回路是死的；但算力够了、数据是脏的，转出来的只是更快的退化。真正卡飞轮的是数据质量。还要警惕一点：飞轮不是转起来就永远转--边际数据价值递减、标注质量退化，飞轮会熄火，它本身需要工程化维护。

bad case 归因的人力含量也在变。一个 case 答错，是检索没召回、还是模型推理偏了、还是 prompt 没约束住--发现、聚类、根因假设、草稿修复这几环已可自动（已有平台把"归因->修复->回归->反哺 eval"整条链做成产品），但裁决和验收仍是人：AI 给出排序的根因假设和修复草稿，人选一个并确认。"很难全自动"依然成立，但人的位置从"做归因的人"变成"审归因的人"。人的角色因此变了：传统架构里人是"改代码的人"，AI 应用里人是"设计飞轮回路、维护 eval 集质量、审核 bad case 归因、决定哪些 case 值得回流的人"。代码不再是系统进化的唯一载体，数据飞轮是增加的第二个载体。

这也是设计对象的本质变化：传统架构的核心资产是代码，AI 应用架构师设计的核心资产里多了数据飞轮（eval 集 + bad case 库 + 反哺通路）。架构师设计的不只是"系统现在怎么跑"，更是"系统怎么自我进化"。

记忆沉淀：不改权重的行为进化

设计对象层在 2026 年最大的增量，是记忆沉淀成为新的设计对象。

传统架构里，系统行为由两样东西决定：代码和数据。行为要改变，要么改代码，要么（对 AI 应用而言）改模型权重。记忆沉淀给出了第三条路：系统运行中产生的经验--bad case 的归因结果、反复出现的模式、用户的纠正--被写进一个持久层，不改代码、不改权重，后续行为却真实地变了。这个层里有三样东西：memory（事实和情节记忆）、skills（程序性知识，文件化、可版本管理）、playbook（系统离线复盘自我提炼的模式）。在侵入性光谱上，它介于 RAG（只读外挂）和 finetuning（权重内化）之间：比 RAG 深--有写路径，系统自己积累；比 finetuning 浅--不动权重，可逆可审计。

这是本质变化：系统运行本身开始产生行为资产。以前"系统在跑"和"系统在学"是两种状态，跑产生的数据要被人捞起来、整理、通过改代码或训练回流，才变成能力；现在从跑到学的通路被设计成系统的一部分，经验沉淀是连续的、自动的、跨会话的。

架构师要设计的是四个问题。写什么：什么经验值得沉淀--不是所有交互都该被记住，沉淀策略的策展和 eval 集的策展是同构问题，都是"从噪声里挑信号"。怎么组织：工作记忆、短期、长期怎么分层，各自的生命周期是什么。怎么注入：记忆在什么时候、以多少上下文预算被检索回上下文--注入太多稀释注意力，太少等于没记。怎么治理：记忆会过时、会冲突、会被错误经验污染，衰减、遗忘、纠错机制是记忆层能不能长期可信的关键。记忆的质量治理和 eval 集的质量治理同构--都是核心资产的策展，也都是飞轮能不能持续转动的前提。

至此，设计对象层的新对象有四样：能力注入回答"能力从哪来"，评估回答"怎么知道行不行"，数据飞轮回答"系统怎么进化"，记忆沉淀回答"经验存到哪"。这四样在传统架构的版图里找不到对应物，是这层要重新学的东西。

结语

范式迁移期最容易犯两个错。一个是全盘否定--"AI 来了，旧架构经验都作废了"，于是底座和心法也一起丢掉，从零重学本来已经会的东西。另一个是全盘照搬--"架构就是架构，换个壳而已"，于是用过时的选型去套新的设计对象，套不上。

两个错都是因为没分层。把技术栈分成底座、心法、设计对象三层来看，问题就清楚了：底座没变，直接复用；心法没变，抽象后迁移；设计对象变了，重新学。判断一个旧经验作不作数，看它属于哪一层。

底座没变，心法没变，变了的是设计对象。

分层判断有一个伴生原则：反面定义比正面清单更可靠。正面清单（要用微服务、要拆）会随范式过时--"要用微服务"在低流量场景就是错的；反面定义（不要泥球、不要烟囱、不要过度工程、不要镀金）跨范式有效，任何架构都不要泥球和镀金。判断旧经验时，抽象的心法和反面定义可迁移，具体的选型和正面清单会过时。

底座层告诉架构师"系统能跑起来"，心法层告诉架构师"决策怎么做"，设计对象层告诉架构师"顶层设计什么"。前两层是迁移过来的资产，第三层是范式迁移期的学习任务。架构师的竞争力，在这三层各自的综合--既不丢掉底座和心法的存量，又跟上设计对象的增量。

变化的是被设计的东西，不变的是设计的逻辑。

附录：不变与变速查表

判断逻辑：一个经验作不作数，看它属于哪一层--底座（不变）/ 心法（不变）/ 设计对象（变）。两不变一变，构成范式迁移期的分层判据。

本文基于 2026 年 7 月的架构实践整理（v3：记忆沉淀提为第四设计对象，底座组件清单、飞轮三路分岔同步修订）。范式迁移进行中，部分判断为基于框架的推导。