OpenAI 拟停止向 Cursor供模：如何设计不绑供应商的AIAgent架构

摘要：OpenAI 8 月 28 日宣布拟于 11 月 12 日停止向 Cursor 提供模型。本文不讨论合同是非，而是从工程角度给出岗位契约、能力路由、状态外置、工具适配、降级与验收六层架构，降低 Agent 对单一模型供应商的耦合。

OpenAI 8 月 28 日宣布，已经通知 SpaceX，拟逐步结束向 Cursor 提供 OpenAI 模型的合同，提议停止日期为 2026 年 11 月 12 日。

需要先限定事实：这是 OpenAI 一方公布的决定和理由，不代表合同争议已经有第三方结论，也不等于 Cursor 将停止服务。Cursor 8 月 14 日确认被 SpaceX 收购时，强调的正是自研模型、算力与更低运行成本。

对 Agent 工程更重要的问题是：当模型供给因为合同、并购、地区、价格或能力策略发生变化，业务工作流能否继续？

1. 先识别"模型锁定"到底锁住了什么

模型锁定通常不是 API 名称本身，而是五类隐式依赖：

依赖	常见表现	切换后的问题
提示词	岗位流程塞进超长 Prompt	新模型行为漂移
上下文	资料只在私有会话记忆中	换模型后业务失忆
工具协议	直接绑定专有调用结构	适配器整体重写
任务状态	中间结果只在模型上下文里	只能从头重跑
验收方式	依赖自然语言自报成功	无法统一回读

所以，model = "xxx" 并不是主要风险。真正的风险是模型同时承担岗位定义、记忆、编排、执行与验收。

2. Cursor Router 说明：先分类任务，再选择模型

Cursor 在 8 月 6 日公布 Router 的设计时写得很直接：没有一个模型在所有工作类别上都占优。

它先用任务类别、复杂度、近期工具调用和上下文判断工作，再在价格合适的模型与不同前沿模型之间路由。Cursor 公布的满意度和成本数字来自自家生产流量，不能外推成行业基准；但这个抽象顺序是合理的：

text 复制代码

Task → Capability Profile → Model Candidate → Budget Filter → Execution

而不是：

text 复制代码

Model → Prompt → All Tasks

3. 六层模型无关架构

3.1 Role Contract：岗位契约

岗位契约只描述目标、交付物和权限，不写模型名：

yaml 复制代码

role: blog_operator
goal: 形成经查证的三平台差异稿并完成发布准备
deliverables:
  - research_facts
  - csdn_article
  - juejin_article
  - toutiao_article
approval_required:
  - public_publish

3.2 Context Store：业务上下文

产品事实、用户画像、品牌风格、素材索引和历史正反例要独立版本化。模型只能读取它们，不能成为唯一存储位置。

ts 复制代码

interface BusinessContext {
  productFactsVersion: string;
  audience: AudienceProfile;
  brandVoice: BrandVoice;
  assetRefs: AssetRef[];
  forbiddenClaims: string[];
}

3.3 Capability Router：能力路由

路由的输入应该是能力需求：

ts 复制代码

type CapabilityRequest = {
  kind: 'research' | 'structured_write' | 'visual' | 'browser_action';
  complexity: 'routine' | 'complex';
  maxCost: number;
  requiredOutputs: string[];
  tools: string[];
};

模型只是候选执行器。选择依据可以包含质量、延迟、成本、可用区、上下文长度和工具能力。

3.4 Tool Adapter：工具适配层

上层调用岗位动作，而不是直接暴露整个浏览器或供应商协议：

ts 复制代码

interface PublishingPort {
  createDraft(input: DraftInput): Promise<DraftRef>;
  prefill(input: PlatformArticle): Promise<PrefillReceipt>;
  readBack(ref: DraftRef): Promise<EditorState>;
}

底层再分别实现 CSDN、掘金、头条适配器。模型变化不会迫使平台工具一起重写。

3.5 External State：状态外置

每一步都要留下可恢复状态：

json 复制代码

{
  "run_id": "20260829-am",
  "completed": ["research", "csdn_draft"],
  "artifacts": ["research.md", "cover.png"],
  "pending": ["juejin_prefill", "toutiao_prefill"],
  "last_verified": "csdn.editor.readback"
}

切换模型以后从 pending 继续，而不是再次执行已经产生外部副作用的步骤。

3.6 Verification：统一验收

不同模型可以有不同表达，但业务完成条件必须稳定。例如发布任务统一要求：标题、正文长度、两张图、封面、标签、账号、平台回执。

tool_call_success 只能说明调用完成，不能替代业务状态 verified。

4. 设计降级，不承诺无损切换

模型替换一定有成本。合理目标不是"零感知"，而是将差异限制在执行层。

可以预先定义三种降级：

能力降级：复杂模型不可用时，先完成资料整理和草稿，不执行高风险判断。
产物降级：图像生成失败时保留文案、尺寸和素材位，后续补图。
执行降级：平台登录或浏览器工具异常时停在本地包，不扩大权限、不重复发布。

5. Tipkay 的产品取舍与边界

这也是我们在 Tipkay 里把模型放进"员工工具箱"的原因。官网当前写明，GPT、Claude、豆包、DeepSeek 是员工使用的工具，不同工作选择合适模型；用户面对的是博客发布、视频制作、小红书运营等岗位，以及岗位自带的业务资料、流程、MCP 与 Skill。

这种结构可以降低"一个模型同时定义所有工作"的耦合，但不能消灭供应商风险。模型接口变化仍需要适配，特定能力也未必存在完全等价的替代品。

真正能保住的是上层岗位契约、业务上下文、任务状态、工具边界和验收规则。

6. 一份今天就能使用的检查清单

去掉具体模型名后，岗位目标是否仍然清楚？
业务资料是否独立于会话保存并有版本？
工具输入输出是否有稳定结构？
是否记录每一步外部副作用和恢复点？
切换模型后能否从上一步继续？
最终结果是否通过目标系统回读？

AI 模型会持续升级，合作关系也会变化。让模型成为可替换执行器，不是为了否定任何供应商，而是为了让业务资产真正属于自己。

参考资料

标签：人工智能、软件架构、AI Agent