OpenAI 断供 Cursor：5% 流量就能锁住 Agent 生态

2026 年 8 月 28 日晚，OpenAI 发布公告，准备停止向 SpaceX 旗下的 Cursor 提供模型，拟议的停供日期是 11 月 12 日。只看表面，这件事似乎不值得大惊小怪：Cursor 还能接多家模型，OpenAI 称把取消压到合同允许的最晚日期，而且 OpenAI 模型只占 Cursor 用户流量约 5%。可就是这样一份通知，让"Cursor 换模型"从改一行配置的事，变成了伤筋动骨的项目。接口明明还开着，为什么生态已经被锁住了？这篇专题把答案拆成六步：断供靠什么生效，上游为什么有动机这么做，真正被争夺的是什么，为什么换模型不等于换行为，这件事的证明边界在哪里，以及迁移权能不能在工程上赢回来。

断供靠什么生效：合同取消窗口与信任判断

先说清楚这一章只解释什么问题：只占 Cursor 用户流量约 5% 的供应中断，为什么仍能让换模型从改一行配置变成伤筋动骨的项目。要回答它得走三步，每一步都往前顶一层：断供靠合同里的什么机制生效，生效后改变的到底是什么，以及 5% 这个数字为什么反而把问题引向了上游的动机。

先把事件坐标钉死。2026 年 8 月 14 日，SpaceX 以 60 亿美元完成对 Cursor 的收购（依据 SEC EDGAR 备案文件）；8 月 28 日晚 OpenAI 发布公告；8 月 29 日 CNBC 率先报道。要回答"断供靠什么生效"，先看公告里写的动作是什么。公告把这次动作的性质说得很清楚：不是 Cursor 违规，而是收购触发了合同条款。"Today, we notified SpaceX that we intend to wind down our contract providing OpenAI models to Cursor, with a proposed shutoff date of November 12, 2026." 停供拟议在 11 月 12 日生效，并称会把取消压到合同允许的最晚日期（原文 'the latest date we can'）；除此之外，无论停供日怎么谈，future models 都不会再提供给 Cursor。OpenAI 公告

往上退一步看第一步的机制：为什么这条合同条款能生效？关键在两个词：change of control（控制权变更）和信任判断。公告的推理链是：与 Cursor 的定制合同给 OpenAI 留了一个"在控制权变更后的限定窗口期内取消合同"的权利；在此基础上，OpenAI 说 "we cannot be confident that SpaceX will use our technology within our terms of service"，理由是它跟 Musk 旗下公司之间存在违约历史。注意这里的措辞：不安全感的对象是 SpaceX 这个新控制方，是对未来的前瞻性判断，不是对 Cursor 过去的指控。公告特意保留了一句 "We've worked with Cursor for nearly four years and have enormous respect for their team"。

机制看清楚了，第二步再看生效后改变了什么。调用代码一行没动，API 接口一个没关，改变的是合同里的供应关系。这就是第一层要被钉死的直觉：访问权首先是商业与治理关系，不是纯技术接口。一个 Cursor 开发者读到的"断供"，在法律文本里读起来是另一回事：上游换了个相对人，合同给对方留了个变更后的取消窗口，上游决定用掉它。

第三步，回到开头那个 5%。Cursor CEO Michael Truell 当晚在 X 上回应：OpenAI 模型约服务 Cursor 用户流量的 5%，双方正在沟通解决。这个 5% 来自推文自述，未经独立审计。同一晚，Anthropic 联合创始人 Tom Brown 表态会增加 Claude 算力支持 Cursor。于是拼图变成了：只占 5% 流量、对手反手加码、过渡期给足，却仍然被一纸通知搅动了整个开发者生态。反常之处恰好在这里：如果迁移代价真的只有"换一个模型标识"，5% 的流量占比根本翻不起浪花；它能翻起浪花，说明这次断供触动的不是流量，而是别的什么东西。那么，上游为什么有动机这样重划边界？这是下一章的问题。

把断供放回老问题：为什么上游有动机重划接入边界

把这次断供放回产业组织的老框架里，它一点也不新鲜。模型市场的供应链是两层：上游是模型供应商（OpenAI、Anthropic、Google），下游是接入 API 做产品的应用（Cursor、Windsurf），而上游同时自己也用自家模型做应用（ChatGPT、Claude Code）。这种结构有一个专门的词：纵向封锁（vertical foreclosure），大白话就是，上游供应商一边卖零件、一边自己组装整机，零件渠道在自己手里，它不需要断供，只要让对手跑得慢一点，就能把市场往自己这边挪。

这就像电商平台一边让第三方卖家入驻、一边做自营：通道在手里，改排序、改推荐位、改结算规则就能偏向自己，全程不用涨价。模型市场里的"改排序"，对应 Besanson（2026）形式模型里定义的三种非价格封锁机制：一是 QoS 歧视（QoS 即服务质量），即给自己的应用更好的延迟、吞吐和上下文限额，给下游应用更差的，价格一分不动，体验悄悄拉开；二是路由偏置，即在助手类界面里把流量优先导给自己家的工具和服务；三是分层访问歧视，即把最强模型能力放进限定访问的分层，只对特定伙伴开放，让排他发生在能力前沿而不是公共模型层。Besanson 2026

为什么是"非价格"？因为这三种机制都绕开了涨价这个显性动作。模型给出的均衡直觉是：上游自营业务利润越厚（m_U 越大）、推理质量在用户感知质量里占的比重越高（α 越大）、API 价格越低（p 越小）、下游越跑不掉（替代弹性 η 越小），封锁的冲动就越强。用人话讲：自家下场越赚、对手越难跑，就越有动机把接入体验往自己这边拉。论文对 Google、OpenAI 等四家 provider 做了 stylized calibration（比较风险映射，不是结构估计），把 OpenAI 和 Google 列为"封锁条件最有利"的一组。需要保留的限定是：这篇论文 2026 年 4 月提交，早于 8 月的断供公告，它对事件的解释是条件性的，不是说论文预测了这次断供。

上游与下游的关系，以及三条非价格杠杆挂在哪条边上，可以看下面这张结构图：

图注：Besanson（2026）形式模型的市场结构：上游 U 既向下游应用收 API 费用，又用自己的应用与它们争夺终端消费者。QoS 歧视、路由偏置、分层访问这三条非价格杠杆，都挂在 U 到下游这条供应边上；均衡里 U 抬高自营质量、压低下游质量，就是纵向封锁的日常形态。Besanson 2026

下游为什么跑不掉？这就轮到转换成本（switching costs），也就是换掉供应商时损失的沉没投入。Klemperer（1987）把转换成本分成三类：学习成本（学会了怎么用你的产品）、交易成本（迁移本身的手续）、以及合同制造的成本（靠条款设计出来的忠诚计划）。无论哪一类，机制都一样：你为当前供应商投入得越专用，换走时损失越大，供应商在签约之后就拥有了事后议价力，也就是你的投入沉下去之后它才有的讨价还价能力。Klemperer 1987

Farrell 与 Klemperer（2007）在综述里补了关键的一句：兼容性（compatibility）会削弱在位者基于安装基础的竞争优势，而不兼容会放大在位优势。所以协议统一确实是削弱锁定的方向，但兼容只解决"接口"，解决不了你为旧供应商做的那些专用投入。Farrell-Klemperer

到这里问题就升级了：这不是 OpenAI 与 Cursor 的产品八卦，而是产业组织的老游戏，上游利用下游沉淀的专用投入，把竞争排他写进供应关系。OpenAI 只是动用了一个现成的合同工具，change-of-control 取消窗口。那么关键的下一问是：下游的专用投入到底沉淀在哪里？ 不是 API 密钥，不是账单，而是 harness。

模型只是可替换的引擎，harness 才是被争夺的运行时

harness（执行外壳）指的是模型之外的全部代码、配置与执行逻辑。Guo 等人（2026）的综述给了一个精确的工程定义：agent = 模型 + 执行 harness，模型负责推理，harness 负责其余一切。这个"其余一切"被拆成六个运行时组件：观察接口（把终端输出、文件 diff、DOM 状态变成模型能读的观测）、上下文管理器（决定什么进 context、以什么形式进）、控制循环（编排 observe-reason-act 的步调、重试与路由）、动作接口（把模型输出映射成函数调用与工具执行）、状态与产物存储（持久化对话、计划、轨迹、产物）、验证与治理层（测试、断言、权限、回滚、审计）。HarnessSurvey

图注：中心是 Model，六个周边盒子是 harness 的运行时组件，箭头构成模型与外部环境之间的闭环。模型只承担推理这一件事，工具调用、上下文、状态、验证全在 harness 里。HarnessSurvey

这六个组件说明了一个重要事实：模型在其中只是可替换的推理引擎。工具怎么调、上下文怎么压、记忆怎么存、重试与权限怎么做，都是 harness 的职责；而这些职责决定了一个 agent 产品的默认路由、能力暴露和用户工作流的沉淀位置。谁的 harness 被用，谁就握住了这些沉淀物。Guo 等人的综述把工程主战场的迁移画成了四段：从 prompt 工程，到上下文工程，到 harness 工程，再到 agent-native 训练与共演化。注意范式之间是共存的，不是后者取代前者，只是瓶颈在移动。HarnessSurvey

图注：工程努力的重心从调动模型行为、到组织上下文、到稳定执行系统、再到训练与共演化 agent 行为。比重装模型本身，更多能力被搬进了运行时。HarnessSurvey

为什么 harness 值得被"争夺"？Zhou 等人（2026）用"外部化"的框架给了统一的说法：能力正在从权重里迁移出来。记忆（memory）把状态外部化，技能（skills）把程序性专长外部化，协议（protocols）把交互结构外部化，而 harness 工程是统摄这三者的运行时环境。这些外部化的东西有一个共同点：它们不随 model ID 迁移。你把模型从 A 换成 B，权重换了，但记忆库、技能清单、协议契约都不跟着走。Externalization

图注：外部化作为 LLM agent 设计的主线。中栏：能力从权重出发，经 Memory（状态）、Skills（技能）、Protocols（协议）三个维度外部化，汇入中间的 Harness；下栏：研究工作的分布从 Weights 层逐步向外迁移。Externalization

图注：Harness 居中，Memory、Skills、Protocols 三个轨道环绕，沙箱、可观测、压缩、评测、审批环等操作元素在中间衔接。外围这些外部化模块都不随模型 ID 迁移。Externalization

工程层面，LangChain 2026 年 3 月的博客把 harness 落到了一串具体原语：filesystem 与 Git 作为协作面、bash 加沙箱作为通用工具、AGENTS.md 这类记忆文件、Skills 的渐进披露、Ralph Loop 的长任务续跑。这是厂商视角的部件清单，不是标准答案，但足以说明 harness 不是抽象概念，而是这些可指名的工程对象。LangChain

那么 harness 里有没有可以中立化、可以随迁移带走的部分？有，工具协议层就是最典型的一个。MCP（Model Context Protocol）2026 年 7 月 28 日的规范版本做了一个关键的无状态化重构：协议层从"带 session 的长连接"改为"每个请求自带能力协商"的 stateless 模式，去掉 session store，任何请求可以打到任意 server 实例。MCP 早已不是 Anthropic 的独家协议，Arcade、AWS、Cloudflare、Figma、Google Cloud、Microsoft、Netlify、OpenAI、Posthog、Prefect、Runlayer、Stacklok、Supabase、Xero 等十余家厂商都进了 adoption 名单（以 MCP 官方 adoption 名单为准）。协议层因此可以脱离任何单一模型方存在，这是"中立层"的第一个实证锚点。MCP Spec

图注：MCP 规范版本变更的部署层对比。BEFORE（2025-11-25）：client 经 sticky route 固定到单个 server 实例，多个实例共享 session store。AFTER（2026-07-28）：任意请求可路由到任意实例，session store 消失，协议层与具体 server 实例解耦。MCP Spec

所以第三层的答案很清楚：谁控制 harness，谁就控制默认路由、能力暴露与用户工作流的沉淀位置，模型本身只是可替换的引擎。这正是模型实验室要争夺的东西。但还有一个更隐蔽的问题悬着：就算协议统一了，行为保证能跟着模型走吗？

模型换得走，行为保证换不走：工具语义、轨迹与 eval 基线

把模型从 A 供应商换成 B 供应商，很像把业务从 MySQL 迁到 PostgreSQL：SQL 语法差不太多，对应 API 的兼容；但 schema、索引、迁移脚本、踩过的坑，一样都不会自动跟着走。你换掉的不是连接字符串，而是十年积累的系统行为。换模型也一样，真正绑死在旧模型行为上的，是三类专用资产。

先看实证。Leins 等人（2026）做了一次严格受控的评测：5 个开源 backbone、3 个 benchmark、5 种方法（3 种编排方法加 CoT 和 task-only 两个基线），用 GEPA 把每种方法的 prompt 优化预算统一锁死，排除"方法更复杂只是因为它被调教得更多"这个混淆变量。结果分两层：平均来看，编排方法最多带来 4.6 个百分点的提升，这似乎支持"加编排总没错"；但按 backbone 拆开看，同一个编排方法在不同模型上的配对差从约 −10 到 +18 个百分点，正负号都翻过来了。一个方法对 GLM 是好东西，换到 DeepSeek 上反而减分。平均值的平静掩盖了交互的激烈。OrchestratePay

图注：编排方法减去 CoT 基线的配对准确率差，按 backbone 与 benchmark 拆分。同一方法在不同模型上从负到正大幅摆动，说明编排收益是模型特定的，不能外推。OrchestratePay

成本维度同样要重测。同一次实验里，编排方法的 token 成本是 task-only 的 2 到 4 倍。把准确率和成本同时画出来，所谓"平均提升 4-5 个百分点"，代价是成本的成倍增长，而这个成本曲线同样是模型特定的。OrchestratePay

图注：横轴为平均加权 token 数（成本代理），纵轴为准确率，误差条为 95% 置信区间。提升数个百分点的编排方法，成本往往翻 2-4 倍，迁移后必须重新测这条曲线。OrchestratePay

第二份实证更锋利，它直接打掉了"更强模型总是更好"这个直觉。Wang 与 Cui（2026）在 multi-call workflow 里做模型替换实验：同一个"把 medium 升级到 strong"的动作，在 Mixed Qwen/GPT 阶梯上把 RMSE（均方根误差，越小越好）从 4.818 降到 1.538，强模型大胜；换到 Qwen-only 阶梯上，同样的动作把 RMSE 从 4.843 劣化到 5.091，强模型反而更差。也就是说，tier label 描述的是实现选择，不承诺替换价值：同一档"强模型"在哪个角色、哪个规模、哪个任务合同下值多少，必须按部署实测。论文自己的话是：tier labels describe an implementation choice, whereas measured substitutions reveal which actions a deployment can use。更极端的是，把任务合同整体换成另一类任务后，Mixed 阶梯上的强弱顺序再次反转。TierLabels

图注：四条模型阶梯在 8-64 次 solve call 下的 workflow 级 RMSE，每条阶梯画 all-small / all-medium / all-strong 三条线。Mixed 阶梯上 all-strong 显著更低；Qwen-only 阶梯上顺序反转，all-strong 反而更差。TierLabels

这两份实证指向同一个结论：接口能搬家，行为保证搬不走。所谓工具语义，就是模型"如何调用你的工具"的行为约定，换一个模型，同样的 JSON schema，调用风格、失败恢复、上下文预算全都要重新验证；而长期运行沉淀的轨迹（traces）与 eval 基线（评测基准），是绑在特定模型行为上的专用资产。Guo 等人的综述把这层关系概括为 agent quality 来自 model × harness × task × evaluation 的乘积，Zhou 等人的外部化框架则指出记忆与技能正是这类资产的载体。换 model ID 不等于迁移，它等于重新验证整条系统行为，这才是比 API 兼容更隐蔽的锁定。

这是不是意味着所有模型方都会封锁竞品？未必。回到事件本身校准一下论断的强度。

这场断供的证明边界：不指控、只占 5%、对手反手加算力

回到 8 月 28 日那晚。三件事决定了这次断供的证明边界。第一，公告没有指控 Cursor 违规，理由挂在前瞻性信任判断上，还特地保留了 "enormous respect for their team" 的措辞，控诉的对象从始至终都不是 Cursor，而是 SpaceX 这个新控制方。OpenAI 公告

第二，OpenAI 模型只占 Cursor 用户流量约 5%，这个数字出自 Truell 的 X 推文，未经独立审计，但量级是对的：这不是一次把 Cursor 彻底卡死的全面封锁，而是对一条占比很小的供应线做合同性收口。CNBC

第三，Anthropic 同晚表态增加 Claude 算力支持 Cursor，说明下游并非没有替代选项，一周之内就有竞对供应商反手接盘。多接入可以稀释单一依赖，但消除不了转换成本：换一家模型，工具语义、轨迹、eval 基线照样要重验，多接几家只是让单点依赖变小，不改变 harness 沉淀本身。

所以这次断供的证明力到哪为止？它证明的是：上游在控制权变化时，有能力也有动机重划接入边界。它不能证明的是：所有模型方都会封锁竞品。第 2 章那个形式模型里的 QoS 歧视，本来就不是在某个单一阈值上消失，而是在下游利润率、API 价格、下游替代弹性等多个参数的联合边界上才消失。有条件、有动机，不等于已经全面封锁；而安全理由与竞争激励，也确实无法只靠外部观察分离。回到第 2 章那张上下游结构图：这次断供用的不是 QoS 歧视，是合同取消窗口，工具不同，但"上游握着重划边界的权力"这个结构事实是一致的。Besanson 2026

读成"对模型方的控诉"就错过了真正的教训。把论断收窄成"压力测试而非普遍定理"之后，问题只剩一个：那下游该怎么办？ 迁移权能不能在工程上赢回来？

把迁移权做成可演练的工程能力：中立层、影子运行、持续回归

能。关键是把"可迁移性"从口号拆成三件可以演练的事。

第一件，把状态放在可导出的中立层。业务逻辑、工具协议、记忆数据、任务级 eval，这些应该从具体模型的行为里解耦出来。工具协议层是最好切入的部分：MCP 的无状态化重构已经证明协议层可以脱离任何单一模型方存在，上一章的 BEFORE/AFTER 对比就是证据。所谓"无状态协议里状态搬不走"是错觉，显式 handle 模式恰恰给出了状态搬家的一条现成路径：server 铸造一个标识，模型把它当普通参数在调用间传递。看下面的序列图，create_basket 返回的 basket_id 被原样带回 add_item，跨调用的状态显式地由调用方携带，协议的每个实例只负责一次请求。MCP Spec

图注：无状态协议下跨调用状态的传递方式。Model 调用 create_basket，server 返回 basket_id，Model 再把同一个 basket_id 作为普通参数传给 add_item。状态由 server 铸造、由模型携带，任何 server 实例都能处理请求。MCP Spec

中立层里有哪些可导出的部件？LangChain 那张"想要的行为 → harness 加的部件"映射图给了一份清单：filesystem 与 Git、bash 与沙箱、记忆文件与搜索、压缩与技能渐进披露、Ralph Loop 与规划验证，再加上 MCP 工具层。这些部件都写在 harness 里，不写在任何一家模型的权重里。LangChain

图注：左列是模型单独做不到、团队想要的行为，右列是 harness 为此添加的部件，一一对应。这些外部化的部件是迁移时可以带走的对象，前提是你把它们留在中立层而不是埋在模型专属代码里。LangChain

第二件，定期做跨模型影子运行（shadow run）。影子运行的意思是：让候选模型并行处理同一批任务流，比较故障、成本与效果，把"替换后能否维持"从猜测变成实测。实验模板可以直接借用 Wang 与 Cui 的两阶段设计：第一阶段用固定的工作流图加风险谓词（risk predicate）提出"哪里值得用强模型"的分配，第二阶段把 outcome traces 转成可复用的约束，在部署条件变化后重测同一个替换动作是否仍然有益。这两步把"往哪里路由"和"替换本身值多少"两件事分开，因为前者可以跨部署保留结构知识，后者必须按目标部署重做校准。TierLabels

图注：两阶段实验模板。Stage 1 用固定图加风险谓词提出节点级 tier 分配，Stage 2 把运行轨迹转成可复用约束（at-least / at-most 规则），再测试部署条件变化后替换是否仍有益。TierLabels

影子运行的报告规范也有现成模板。Leins 等人的受控评测锁死了 backbone、解码参数、benchmark 与评分规则，只让方法这一个变量动，并用统一优化预算掐掉"调教更多"这个混淆变量；报告时只报 accuracy 是不够的，必须同时报 accuracy-cost 曲线，就像第 4 章那张散点图：迁移一次，成本曲线重测一次。OrchestratePay

第三件，把 evaluation 与 observability 合并成持续回归。Guo 等人给出的 harness eval 管线是四元素闭环：benchmark 定义任务，执行基础设施标准化运行，judgment 方法给结果打分和诊断，continuous evaluation 把这些信号反馈回系统改进。评测不再是上线前的单次动作，而是常驻的仪表盘；每一次模型替换、每一次任务合同调整，都在这个闭环里留下基线。HarnessSurvey

最后收个口。实验室自带的 harness（Claude Code、Codex 这类）往往能更快拿到原生能力、托管安全和模型协同，不能机械拒绝。正确的姿势是分层采纳：协议、记忆、eval 留在可导出的中立层，厂商特有的体验层随它去，同时定期演练跨模型影子运行。演练测试的不是接口能否调用，而是故障、成本、效果在替换后能否维持。

所以把六章的答案串起来：模型 API 的"开放"是模型方的治理决定，它今天可以把合同取消窗口用在你身上；而你能够决定的，是自己沉淀的状态放在哪一层。harness 控制权可以被争夺，但迁移权可以在工程上赢回来。5% 的流量占比之所以能撬动整个事件的讨论，不是因为 5% 本身重要，而是因为它精确地暴露了：这一行代码背后，你的资产到底沉淀在哪里。

参考文献

本专题引用的核心资料如下，建议深入学习时阅读原文：

1. Our decision on Cursor following its acquisition by SpaceX（OpenAI，2026-08-28）— openai.com
2. OpenAI to end model access to Cursor after acquisition by Elon Musk's SpaceX（CNBC / Lora Kolodny，2026-08-29）— cnbc.com
3. Markets with Consumer Switching Costs（Klemperer，QJE 102(2)，1987）— doi.org/10.2307/1885068
4. Coordination and Lock-In: Competition with Switching Costs and Network Effects（Farrell & Klemperer，HIO Vol.3 Ch.31，2007）— doi.org/10.1016/s1573-448x(06)03031-7
5. The Inference Bottleneck: A Formal Model of Vertical Foreclosure in AI Markets（Besanson，arXiv:2604.17431）— arxiv.org/abs/2604.17431
6. When Does LLM Orchestration Pay Off? A Controlled Evaluation of Accuracy, Cost, and Task Difficulty（Leins et al.，arXiv:2608.00685）— arxiv.org/abs/2608.00685
7. Beyond Tier Labels: Role- and Deployment-Dependent Model Substitution in Multi-Call LLM Workflows（Wang & Cui，arXiv:2608.09155）— arxiv.org/abs/2608.09155
8. From Question Answering to Task Completion: A Survey on Agent System and Harness Design（Guo et al.，arXiv:2606.20683）— arxiv.org/abs/2606.20683
9. The Anatomy of an Agent Harness（LangChain engineering blog，2026-03-10）— langchain.com
10. Model Context Protocol 2026-07-28 Specification — modelcontextprotocol.io
11. Externalization in LLM Agents: A Unified Review of Memory, Skills, Protocols and Harness Engineering（Zhou et al.，arXiv:2604.08224）— arxiv.org/abs/2604.08224