AI 迁移日历正成为产品风险

重要的不是模型厂商发布得更快，而是迁移日历正在成为生产风险，因为 agent 应用把工作流逻辑绑定在厂商拥有的编排表面上。

最近两个开发者通知说明了这一点。OpenAI 的 API deprecations 页面显示，Agent Builder 已在 2026 年 6 月 3 日被标记为 deprecated，并计划在 2026 年 11 月 30 日关闭；ChatKit 仍然可用，开发者被引导迁移到 Agents SDK 或 ChatGPT Workspace Agents。Google 的 Gemini API changelog 则显示，多个 Gemini 2.0 模型已在 2026 年 6 月 1 日关闭，开发者被要求改用新的 Gemini 3.x 变体。

单独看，这两条通知都不令人意外。平台会淘汰旧表面。模型会老化。Preview 产品会进入稳定路径，或者消失。但更尖锐的判断是，AI 应用风险已经不再只是 prompt 质量、延迟、幻觉或 token 成本。它还包括生命周期耦合：产品中有多少工作流逻辑，依赖于一个变化速度可能快过客户自身发布流程的厂商表面。

这和普通 SaaS 依赖风险不一样。数据库版本升级可能破坏集成，但应用通常仍拥有其上的业务逻辑。Agent 系统模糊了这条边界。平台可能同时提供模型、tool-calling 语义、memory 行为、文件检查、沙盒执行、聊天 UI 组件、eval hooks 和托管 workflow builder。团队采用的托管表面越多，deprecation 就越不像例行库升级，越像一次产品管理事件。

这个具名机制可以叫作便利性导致的编排锁定。团队通常从最快路径开始：托管 builder、默认 agent loop、厂商 UI kit，或模型专属的 tool schema。当目标是验证一个 workflow 是否有价值时，这很合理。但便利层会慢慢变成应用的操作层。它决定工具如何被调用、状态如何表示、错误如何重试、文件如何传给模型、用户如何看到 agent 行动，以及开发者如何调试失败。一旦厂商改变这一层，团队就不只是替换一个模型名称，而可能要重写 workflow 的形状。

最容易误读的是，把每一次 deprecation 都当成厂商不可靠的证据。这太粗糙。快速移动的 AI 平台必须修剪旧表面。如果每一个 preview 模型和 builder 都永远保留，反而会制造另一种可靠性问题：文档碎片化、安全假设陈旧、eval 行为不一致，以及拖慢稳定路径的支持负担。Deprecation 不一定是坏事。真正坏的是对即将被淘汰的表面保持无声依赖。

对构建者来说，实际影响是一种新的依赖审查。问题不只是“哪个模型表现最好？”而是“如果这个表面改变，我们产品的哪些部分仍然可迁移？”一个团队可能把请求路由包在模型抽象层后面，却把 workflow 状态嵌进托管 builder；这并不是真正的可迁移。一个团队也许能切换 model ID，但如果无法在厂商 harness 之外复现 agent 的工具计划、memory 边界或恢复行为，那它只解决了最容易的一层。

这对 coding assistants 和 operator tools 尤其重要。WisdomChain 的周度表现报告指出，top AI coding assistants 页面值得更新，而这个市场信号与今天的判断吻合：开发者工具越来越不只是看模型质量，也要看它们如何承受 IDE 集成、agent runtime、权限模型和 eval loop 的变化。一个 coding agent 在 demo 中表现漂亮，但不能保留 trace、重放失败，或跨平台变化迁移任务状态，恰好在企业最关心的位置上脆弱。

同样的逻辑也适用于重度依赖 memory 的产品。之前关于 AI memory systems and retrieval discipline 的文章里，核心问题不是 memory 是否让 agent 显得更聪明，而是 retrieval 边界是否明确到可以审计。迁移日历让这个问题更尖锐。如果平台改变 memory、文件或 tool context 的表示方式，产品就需要验证旧 workflow 是否仍然检索正确证据、排除正确的私有上下文，并保留用户意图。

这里还有一个经济学角度。Deprecations 会把隐藏的工程工作推到台前。一个团队为了快速探索而建立在 preview 表面上，也许节省了几个月，之后却要在厂商 deadline 下偿还这笔债。这不一定是错误。错误在于没有给这个选项定价。当 workflow 还不确定能否经受客户检验时，原型速度非常值钱。但一旦 workflow 开始产生收入，迁移日历就应该和 cloud commitments、eval coverage、incident response 和 security review 一样，进入运营计划。这也直接连接到更广义的 AI cost governance problem：单位经济性不只是 token 价格，还包括保持平台层兼容所需的工程成本。

产品设计启示很具体。生产级 AI 系统需要一份 versioned orchestration ledger。对每一个关键 workflow，团队都应该知道其中涉及的 model IDs、API surfaces、tool schemas、memory stores、file interfaces、UI components、eval suites 和 hosted builder dependencies。团队也应该知道哪些部分已经有关闭日期，哪些只是 preview，哪些可以在本地重放，哪些需要厂商专属状态。这不需要变成沉重官僚流程。它可以从一张简单的依赖表开始，并和 release gates 与 eval runs 关联起来。

二阶后果是，采购问题会变得更技术化。买家不只会问准确率和安全性，还会问迁移支持、deprecation window、export format、state portability 和 replayable traces。“我们使用最新模型”已经不够。更强的回答会更像运营说明：“workflow 是这样 versioned 的，迁移是这样测试的，rollback path 在这里，仍然厂商专属的部分在这里。”

一个合理反方观点是，抽象层可能变成过早工程化。很多团队确实应该使用厂商原生 builder，因为它们压缩了从想法到用户反馈的距离。如果产品仍在探索，过度投资可迁移性可能只是逃避学习的一种方式。正确答案不是在发布任何东西之前先建一个私有平台。正确答案是知道姿态何时改变。一旦 workflow 有真实用户、合规暴露、收入影响或运营责任，“以后再迁移”就不再是计划，而是未管理的负债。

可证伪的下一步指标，是厂商是否把生命周期管理变成一等产品表面。观察是否出现 migration dashboards、compatibility scanners、agent-workflow export tools、跨模型版本的 eval diffing，以及对编排产品比对原始模型更长的 deprecation windows。也要观察企业买家是否开始在 AI agent 合同里要求 platform-exit clauses，而不只是 data-processing terms。

市场判断很简单：AI 平台正在变成操作环境，而操作环境会被升级纪律检验。赢家不会是那些永远不淘汰任何东西的厂商。这不现实。赢家会是那些让严肃构建者看见变化、在变化到来前测试变化，并在不丢失 workflow evidence 的情况下完成迁移的厂商。

对构建者来说，今天的现实校验是，不要再把模型迁移当成改名练习。如果一个 AI workflow 依赖厂商的 agent builder、托管 memory 语义、UI component 或 tool-calling runtime，那么迁移风险存在于 workflow 里，而不是 import statement 里。本周最无聊也最有价值的动作是：画出产品依赖的 AI 表面，标出 preview 和 deprecation 日期，并在厂商日历让演练变成强制之前，先做一次迁移演练。

资料来源：OpenAI API deprecations, "2026-06-03: Agent Builder," https://developers.openai.com/api/docs/deprecations；Google Gemini API release notes, "June 1, 2026," https://ai.google.dev/gemini-api/docs/changelog；Google Gemini API deprecations, https://ai.google.dev/gemini-api/docs/deprecations；OpenAI, "The next evolution of the Agents SDK," https://openai.com/index/the-next-evolution-of-the-agents-sdk/。

Read in English →