先把话说在前面：这不是一份行业共识
下面要讲的结构，是本编辑部把 11 月 2 日到 6 日五份公开材料摆在一起之后的归纳，没有任何一家厂商宣布过它，也不代表行业共同转向。五件事彼此独立：Anthropic 给 Messages API 加了消息线程、Redis 把上下文能力拆成六块、Five9 与 Sierra 各买了一家做外围能力的公司、四家后台软件把智能体嵌进系统记录。硬要找共同点，只有一条不太起眼——没有一份材料要求客户先换掉既有底座。
这条共同点之所以值得单拎出来，是因为过去两年智能体落地的默认剧本，往往从「选一个平台、迁一批数据」开始。而这一周的做法反着来：能力从外围接上去，核心系统留在原位。这不一定更好，但它确实把成本与风险挪到了别的地方。
三层叠加，各自动了什么
接口层动的是请求怎么发。2200 号那篇里，消息线程让长会话每轮只传增量，业务代码基本不用改，代价是客户端要重新承担重放与状态管理；省下的是等待，账单没变。这一层最轻，也最容易被当成纯性能优化忽略掉——它其实已经把一部分会话状态从客户端搬到了服务端。
能力层补的是模型之外的缺口。2201 号的 Redis Iris 把路由、复用、记忆、工具入口、可观测与智能体间通信拆成六件，贴在团队已有的 Redis 运行时上；2203 号的 Anon 补的是没有 API 的门户登录与表单填写。两件都不是模型能力，却都决定了长任务能不能走完。渠道层则改了卖法：2202 号里 Five9 与 Salesforce 都把智能体做成可跑在竞品系统之上的叠加层，2204 号的四家后台软件干脆把智能体塞进合同、数据库与可观测系统，没另开入口。
于是这一周的主语变了。不是「模型又能做什么」，而是「模型之外还差什么，以及怎么把它接上去而不动底座」。这句话听着朴素，落到合同上却是另一种采购：从替换式变成叠加式。
叠加式采购，把三道题推到台前
其一，谁能停。能力链每多一段外部依赖，急停与降级的责任就多一次交接。站内 2190 号记过安全厂商把急停做成产品的那条线，本篇不重复它的细节，只补一句采购视角的话：买叠加层时，得同时买下「停它」的权限和流程，否则出事时手里只有一个客服工单号。
其二，记录在哪。一次请求现在可能穿过接口层、上下文层、叠加层与核心系统，日志分散在不同供应商手里。2204 号那批产品之所以强调动作留痕，恰恰因为责任分段之后，证据链最容易断在两段之间的缝隙里。没有统一追踪编号，事后复盘基本靠猜。
其三，换掉要多久。叠加层可以独立停服、改价、改接口，迁移成本常被低估。本批 2202 号那笔交易里，「独立售卖给竞品平台客户」的路线能否长期维持，公告就没有回答。这里有个更一般的判断：替换式采购的痛在迁移，一次性、看得见、有预算；叠加式采购的痛在退出，分散在合同、鉴权与运维手册里，往往等到某一天能力下线才浮出来。这个对照是编辑归纳，不是任何一家的结论。
三盆冷水，与三个观察哨
冷水得自己泼。五份材料几乎全是厂商自述、厂商委托调查或公司口径，缺第三方复现；把一周内恰好出现的五个样本归纳成结构，有过度拟合的风险，换个星期可能就是另一幅图；更要紧的是，「不换底座」不等于没有迁移成本，它只是把成本从项目初期挪到了日常运维和退出那一刻。别把省下的前置工作当成省下的总工作量。
值得盯的信号有三个：叠加层厂商会不会开始单独公布服务等级与退出条款；跨层统一审计会不会变成招标里的硬指标；企业采购评分表里会不会出现「可替换性」这一项。今天就能做的工程动作也不复杂：给每段外部能力登记负责人与停用流程，把跨层请求串成同一条追踪编号，对每个叠加层做一次「拔掉会怎样」的演练。这些判断目前尚无行业统一口径，后面几周的实际合同与停用公告会比任何路线图都更能说明问题，后续将持续跟进迭代动态。