给 API 公司用的中立 SDK 与 MCP 迁移控制平面——一套可信的 agent 接口，同时覆盖 Claude、OpenAI 和 Google。

1. Anthropic 的收购说明，SDK 与 MCP 这层已经重要到足以让前沿模型公司直接下场持有。
2. 托管式 Stainless 产品计划下线，对依赖中立生成器基础设施的团队来说，立刻就形成了强制性迁移动作。
3. Stainless 的客户名单覆盖 OpenAI、Google 和 Cloudflare，证明 API 工具买方早就需要跨生态可移植性，而不是单平台锁定。
4. 当 Anthropic 把这笔收购直接绑定到 Claude 如何连接外部数据与工具上时，API 团队必须先把新的 agent 分发表面握在自己手里，不能等平台替他们定义。

催化因素。 Anthropic 的收购，加上外界报道中 Stainless 托管产品将被关停，让中立的 SDK 与 MCP 基础设施一下子变成刚需；而此时模型平台又都在争夺 agent 如何连接第三方工具。

产品导入 OpenAPI 或类似合同，把它当成唯一受治理的事实源，直接生成生产级 SDK、MCP server 和 agent 工具描述。它再补上一层迁移工具：对比生成结果、标出 breaking changes，让团队替换掉厂商自有流水线时，不必把每一次 SDK 发布流程都重写一遍。兼容性实验室会在主流模型生态上跑合同、鉴权和 tool-call 测试，让 API 团队能证明哪些端点能稳定跑在 Claude、OpenAI、Google 和后续 agent runtime 上。系统还会提供 rate limit、OAuth scope、人工审批要求，以及 agent 流量和人类开发者流量的可观测性策略。时间一长，公司就会变成 API 卖向 agent 经济时那层中立分发与质量控制基础设施。

差异化。 这不是又一个 SDK 生成器，而是 agents 真正会调用的 API 接口面的中立变更管理与兼容性层。现有 codegen 工具能帮团队产出 client，但帮不了他们从平台自有工具迁出来、在多模型生态里做行为认证，也管不了 MCP 与 tool runtime 边界上的策略。真正能守住的切口，是迁移自动化、跨模型兼容性数据，以及跨多个 API 厂商沉淀出来的 agent 接口遥测。

待完成任务

flowchart LR
  Buyer[API platform leader] --> Pain[Vendor lock-in and broken agent surfaces]
  Pain --> Product[SDK and MCP migration plane]
  Product --> Outcome[Portable trusted API access for agents]

高管要点

• Anthropic 收购 Stainless，以及外界报道中 Stainless 托管产品将被下线，给那些不愿把 SDK 与 MCP 路线图交给单一模型平台的 API 公司，立刻撕开了一道中立性缺口 [8][31]。
• 需求可信，但还在早期：Postman 说 82% 的组织至少部分采用 API-first，但真正为 AI agents 设计 API 的只有 24%，经常使用 MCP 的只有 10%，所以短期更适合先卖迁移工具，而不是大而全的平台预算 [23]。
• 平台支持并没有收敛，反而在分裂：Anthropic 的 MCP connector 只支持 remote、也不支持 ZDR；OpenAI 明确提醒 remote MCP server 可能外流敏感数据；Bedrock agents 则依赖 OpenAPI 3.0 的子集加确认控制 [9][21][6]。
• 竞争对手已经证明 SDK 与 MCP 生成有预算，但大多数厂商优化的是 artefact 产出，而不是中立迁移、跨模型认证或运行时策略控制 [28][27][11][32][1]。
• 这仍是一个有风投兴趣、但明显偏窄的滩头市场：公开目录代理说明 API 项目和 OpenAPI 规范数量不少，但短期真正可触达的，只是其中具备多 SDK 复杂度、又被 agent mandate 压着走的少数 [3][5][23]。

市场定义

这里定义的市场，是一类中立的开发者基础设施软件：它把一份 API 合同变成受治理的 SDK、MCP server 和模型特定工具接口面，同时负责跨 Anthropic、OpenAI、Google 与 AWS 生态的迁移、兼容性与策略控制。这个品类夹在传统 SDK 生成、文档工具和 agent runtime 治理之间；除非某产品真的接管了 SDK 到 MCP 的迁移工作流和认证闭环，否则不把通用 API 管理和模型托管算进来 [28][27][11][9][21]。

用户与买方

主要用户，是 API-first 软件公司的平台工程与开发者基础设施团队：他们维护多套官方 SDK，也在被企业客户追问 API 能不能顺畅跑在 Claude、ChatGPT、Gemini 和 Bedrock agents 上。经济买方通常是 VP Platform、开发者体验负责人或 API 业务 GM，因为痛点同时跨越发布工程、安全评审和外部采用指标 [23][25][12]。

购买触发点

• Anthropic-Stainless 交易会触发路线图复盘，因为原本中立的供应商正在变成平台自有资产，托管产品连续性也不再有保证。 [8][31]
• 企业客户开始追问 AI-ready 或 MCP-ready 集成，但大多数 API 原本并不是按 agents 来设计，平台团队因此必须尽快补洞。 [23][16]
• 安全与合规评审的焦点，已经从“给人类开发者上手”转到“最小权限、提示词注入防护，以及 agent 访问边界”。 [15][9][19][17]

支付意愿

从公开定价页看，预算并不是凭空新建，而是已经藏在相邻工具栈里：Stainless 把 SDK、文档和 MCP 生成打成一包并提供免费层；Speakeasy 有免费层和 business trial；liblab 公布的 MCP 用量价格是每 100 次调用 $5；APIMatic 的 business 与 enterprise 价格则保持定制。这个格局说明，只要创业公司能消掉迁移风险、并成为可信控制平面，就有机会卖出企业平台订阅，而不只是另一个生成器 [29][26][34][2]。 [29][26][34][2]

品类动态

增长信号 完全 API-first 组织同比增长 12%

验证信号

• Anthropic 表示已有数百家公司依赖 Stainless 生成 SDK、CLI 和 MCP server，这说明生成式机器接口确实存在成熟 incumbent 需求。
• TechCrunch 报道 Stainless 服务过 OpenAI、Google、Cloudflare、Replicate 和 Runway，证明跨平台 API 厂商早就愿意为中立工具付费。
• Fern 与 OpenRouter 的案例说明，面向 AI 的 API 公司已经在为 agent 消费优化文档和机器可读 artefact。
• 公开 API 目录上的徽章显示，就算暂时不算企业内部 API，市场上也已经有数千个对外 API 和 OpenAPI 文档可供切入。

监管与技术约束

• MCP 协议里的鉴权是可选项，所以客户不能默认拿到一致的最小权限行为，除非额外补上控制层。
• Anthropic 的 MCP connector 只支持工具、要求公开暴露的 remote server，而且不支持 Zero Data Retention。
• Amazon Bedrock agents 只支持 OpenAPI 3.0 的一个子集，并鼓励显式用户确认，以降低提示词注入风险。
• 如果开发者盲目信任未经验证的 remote MCP server，敏感上下文就可能被外流，因此信任与策略管理不是加分项，而是核心问题。

竞争不是平面的，而是战略性的。Stainless 曾经是最贴近的 benchmark，因为它同时覆盖官方 SDK 与 MCP 生成，但被 Anthropic 收购后，它从中立供应商变成了平台资产 [8][28]。Speakeasy 和 APIMatic 在可靠 SDK 自动化与 CI/CD 集成上最强，但它们并没有把跨模型认证和运行时策略控制做成核心 [27][26][1]。Fern 擅长把文档、SDK、CLI 和 agent 可读内容放进同一发布面，尤其适合 AI 导向的开发者体验 [11][12]。liblab 说明 MCP 生成正在独立长出预算，但它本质上仍主要按输出生成收费，而不是按中立迁移治理收费 [32][33][34]。开源工具则始终是愿意自己维护的团队的真实替代项 [22][30]。

为什么现有厂商不会默认胜出

• 模型平台. Anthropic、OpenAI、Google 和 AWS 都提供了工具调用或 MCP 原语，但每一层接口都明显带着各家平台形状。正因如此，市场才给中立翻译与认证层留出了空间。
• SDK 生成器. Speakeasy、APIMatic 和 Stainless 已经把 artefact 生成做得很好；但如果买方更在意从平台自有基础设施里迁出来、跨模型测试，以及运行时策略执行，它们就不会自动胜出。
• 文档与 DX 平台. Fern 证明 API 现在越来越需要从同一事实源同时产出文档、SDK、CLI 和 agent 可读 artefact；但“谁来管理旧流水线迁移、谁来做跨模型行为认证”这两个问题，它并没有真正回答。
• 开源与自建. OpenAPI Generator 和 Swagger Codegen 把 build-versus-buy 的门槛压得很低，所以创业公司要赢，必须在迁移速度、质量保障和互操作性上明显超过内部平台团队，而不是只会生成代码。

这家公司卖的是一层中立控制平面，服务对象是既要发布官方 SDK、又要交付 MCP server 和 agent-ready 工具接口面的 API 厂商；他们不想把这一层直接交给 Anthropic、OpenAI、Google 或 AWS。催化剂非常具体：Anthropic 收购了 Stainless，而外界报道中的托管产品关停计划，会立刻触发那些依赖中立 SDK 基础设施团队的路线图复盘。最好的首批客户，是偏后期的 API-first SaaS 或基础设施公司：至少 3 套官方 SDK、一份 OpenAPI 合同，而且本季度就有企业共创客户要求接入兼容 Claude 或 ChatGPT 的 agent。产品应该以迁移优先的平台形态落地：导入现有合同，重新生成 SDK 和 MCP 接口面，把输出和旧流水线逐项 diff，并在买方真正关心的模型生态里做行为认证。研究支持这是一个“窄但真实”的市场：公开 API 目录说明外部 API 项目很多，但同时具备多 SDK 复杂度、又承受 agent 压力的只是其中一部分，所以公司该优化高 ACV 的共创客户，而不是一开始就追广谱 self-serve。公司真正赢法，是成为可信的发布治理与兼容性层，而不是跟现有 code generator 正面打“谁更便宜”。运营上的关键取舍，是在外部 API 迁移切口跑通之前，先别碰企业内部 API、通用 API 管理工作流和泛化 observability。当前输入里最大的空白，是 2026 年到底有多少活跃 Stainless 客户必须迁移，所以前 90 天必须把三件事问清：紧迫度、预算 owner，以及首个付费模块到底是迁移还是认证。

问题

• 现在的 API 公司得同时交付给开发者的 SDK 和面向 agent 的接口，但大多数发布流水线原本只为 SDK 生成而建。
• Anthropic 接手 Stainless，把原本中立的供应商变成平台基础设施；对不想把 API 分发边缘绑死在单一模型厂商上的买方来说，连续性风险一下子浮上台面。
• 开源生成器和现有 SDK 工具能产出 artefact，但给不了平台团队迁移安全、跨模型兼容性证明，也管不了 agent 流量的策略控制。

解决方案

• 导入一份 API 合同，把它变成受治理的事实源，生成带版本管理的 SDK、MCP server 和工具描述符；切换前还能和旧流水线并排做 diff。
• 在 Claude、OpenAI、Google 和 AWS 的 agent 接口面上跑兼容性、鉴权和回归测试，让买方在对企业客户承诺支持前，先把能跑的范围说清楚。
• 补上一层运行时策略与遥测，覆盖 OAuth scope、确认门槛、rate limit，以及 agent 与人类流量的拆分观测，让产品从一次性迁移工具升级成控制平面。

为什么我们会赢

• Stainless 被 Anthropic 收购后，中立性的重要性只会更高：买方现在有了一个非常直观的理由，不愿再让单一模型平台掌握自己的 SDK 与 MCP 路线图。
• 真正能守住的切口是“迁移 + 认证”：现有厂商早已会生成代码，但很少有人能一边安全替换线上发布流水线，一边证明它在多个模型生态里都能正常工作。
• 每一次生产发布，都会沉淀规范 diff、回归、鉴权失败和 agent 流量模式数据；跑过的 API 产品越多，这套数据越值钱。

里程碑

flowchart LR
  Wedge[Migration-first beachhead] --> MVP[MVP for one API product]
  MVP --> Proof[Paid pilots and cross-model proof]
  Proof --> Expansion[Multi-product expansion]

创始团队

实验路线图

风险评估

必须成立的条件

• 至少 30% 的合格偏后期 API 厂商，在未来 12 个月内确实有向外部客户上线 MCP 或 agent 工具接口面的 mandate。
• 从厂商绑定工具迁出来这件事足够急，至少一半共创客户会在完整替代平台出现前，先为试点付费。
• 仅做 Claude 和 OpenAI 认证，就足以覆盖第一批企业需求，让买方接受分阶段的平台 rollout。
• 一次迁移试点能在不漏掉发布周期的前提下，把单个 API 产品推到生产，并把关键 cutover 缺陷压到 1% 以下。
• 超过 50% 的生产客户会在 12 个月内从 1 个 API 产品扩到至少 2 个，证明这是个平台业务，而不是纯服务项目。

待尽调问题

• 到 2026 年，真正需要替换托管工作流的 Stainless 或同类工具客户，到底有多少？又有多少只会把当前输出冻结不动？
• 第一笔预算在现实里究竟由谁拍板：VP Platform、开发者体验、安全团队，还是 API 业务 GM？
• 买方排第一的购买理由到底是迁移自动化、跨模型认证，还是运行时策略控制？
• 内部平台团队把开源生成器和零散 MCP 原型拉起来之后，外部厂商还有多大赢面？
• 什么 proof point 才能把共创试点转成多产品年度订阅，而不是一次性迁移项目？

模型合理性

• 收入引擎. 基准情形的收入增长，靠的是把 3-5 个付费共创客户转成 Q4Y2 的 15 个生产客户，再在 Q4Y3 扩到 40 个受管 API 产品，blended ACV 约 $105K。
• 必须成立的前提. 试点转生产的转化必须足够强，才能让经常性平台收入在第二位 AE 和后续工程招聘把成本打满之前先长起来。
• 模型失效条件. 如果销售周期拉长到 9 个月，或成熟 ACV 更接近 $95K，downside 情形会在公司讲出清晰下一轮融资故事之前先把现金打穿。
• 下一轮融资证明点. 下一轮融资叙事要建立在 15 个生产客户、可见的第二产品扩张，以及到 Q4Y2 退出时约 $1.4M ARR、且手里仍有 6 个月现金之上。

情景

敏感性

flowchart LR
  Targets[Target API vendors] --> Pilots[Paid migration pilots]
  Pilots --> Customers[Production API products under management]
  Customers --> Expansion[More SDKs, MCP surfaces, and policy modules]
  Customers --> Revenue[Recurring + migration revenue]
  Expansion --> Revenue
  Revenue --> GrossProfit[Gross profit]
  GrossProfit --> Cash[Cash / runway]

警示项: 模型仍假设前 18 个月服务成分较重，所以毛利率要到 Y3 才摸到 75% 目标。 · 基准情形下，Q4Y3 的期末现金已经很薄，融资稍有延迟或试点转化稍慢，runway 就会迅速收紧。 · 从 Q4Y2 的 15 个客户跳到 Q4Y3 的 40 个，意味着 outbound、转介绍和实施能力都必须比第一年显著更可复制。 · Y3 的 EBITDA 依旧为负，因此下一轮融资更依赖 ARR 质量和扩张证据，而不是短期盈利。

• 平台捆绑竞争. Anthropic、OpenAI、云厂商或 API 管理 incumbent 可能把 SDK 与 MCP 工具打包到足够好，从而压窄独立厂商的切口。 缓解措施: 靠中立性、迁移支持和跨模型认证取胜——这些都是单平台打包工具很难有公信力做好的。
• 标准快速变化. MCP、工具 schema 和 agent runtime 预期都可能高速演进，导致生成出来的接口面很难长期稳定。 缓解措施: 把产品当成“编译器 + 兼容性实验室”来做，持续更新 adapter，卖的是托管式变化管理，而不是一套静态标准。
• 早期市场偏窄. 未来 12 个月里，真正急着补齐 agent-ready 接口面的 API 公司可能只占一小部分，首轮销售会慢。 缓解措施: 先盯住那些已经承受企业压力、必须上线 MCP 支持的偏后期 API 厂商，并用迁移服务先把近期预算撬出来。