Coinbase、Shopify、Ramp自建编程Agent为何仍付费给Anthropic

企业工程团队正在围绕 AI 辅助软件开发形成一种通用架构。Coinbase、Shopify 和 Ramp 都为自家开发者构建了内部编码 Agent。然而，这些自建的 Agent 都没有取代 Claude Code、Codex 或 Cursor 等商业工具。

这使得它更像是一个架构决策，而非「自建还是购买」的决策。

这些公司选择自主掌控的层级并非大语言模型，而是 Agent 工具链（agent harness）——即提供上下文、权限、工作流编排、工具访问和验证的执行环境。来自 Anthropic、OpenAI 和 Google 的前沿模型继续提供推理引擎，而企业则越来越多地拥有围绕它的一切。

LangChain 最近承认这种架构已经变得可复制，并将 Open SWE 开源，将其描述为 Stripe、Ramp 和 Coinbase 已在内部部署的同一模式的公开实现。

竞争优势位于模型之外

尽管 Forge、River 和 Inspect 是独立开发的，但它们解决的问题却惊人地相似。

Coinbase 的 Forge 将 Slack、GitHub 和 Linear 集成到工作流中，可以将 Bug 报告转换为 Pull Request，几乎无需开发者干预。一旦识别出问题，Forge 会检索所需的代码库上下文、生成代码、验证变更，甚至生成移动端构建版本供审查。

Shopify 的 River 遵循相同的架构方法。该公司将其成功很大程度上归功于 Agent 本身，而非底层开发者平台。River 运行在可复现的工程环境之上，背后是公司级别的单体代码仓库、持久执行会话、沙盒环境、凭证管理和可复用的工程技能。Shopify 报告称，River 现在参与每八个已合并的 Pull Request 中的一个。

Ramp 的 Inspect 通过在沙盒虚拟机中执行来进一步扩展这一模式，这些虚拟机高度模拟开发者的本地环境。该平台集成了 Datadog、Sentry、LaunchDarkly、Buildkite 和其他工程系统，同时保持对模型的无感知。Inspect 支持多个前沿模型以及 MCP 服务器、自定义工具和专有工作流。

尽管实现方式不同，这三个平台都围绕相同的架构收敛：持久执行环境、对企业系统的安全访问、工作流编排，以及代码进入生产环境前的自动化验证。

企业正在将工具链内化

这与过去十年内部开发者平台的发展历程并无太大不同。

在采用 AWS 或 Azure 之后，很少有企业自建云基础设施。相反，他们在公有云服务之上构建了固执己见的平台，标准化了部署流水线、安全策略和运营实践。

同样的模式现在正在 AI 领域出现。

语言模型成为另一个基础设施依赖项，而企业拥有的工具链决定了如何应用这种智能。路由请求、执行权限检查、注入组织上下文、执行工具和验证结果都成为平台的职责，而非模型提供商的职责。

因此，模型选择成为一个配置选项，而不是由个别开发者做出的工作流决策。

成本优化成为平台能力

Coinbase 的经验说明了为什么企业越来越希望控制这一层。

据 Coinbase 钱包和 AI 工程生产工程高级总监 Chintan Turakhia 称，该公司基础设施现在处理的 Token 数量比以前更多，同时总体支出却在减少。

Coinbase 联合创始人兼 CEO Brian Armstrong 将这一改善归功于多项架构优化，而非单一突破。Coinbase 引入了智能路由、更低成本的默认模型、Prompt 缓存、更小的上下文窗口，以及更好的 AI 支出可见性。该公司还尝试了 GLM 5.2 和 Kimi K2.7 等开源权重模型。

这些优化只有在 Coinbase 拥有位于开发者和基础模型之间的网关时才能实现。

平台团队可以集中更新路由策略，而无需让数千名工程师切换工具。模型升级、价格变化和实验成为基础设施运营，而非全公司范围的迁移。

商业编码助手仍有一席之地

拥有工具链并没有消除对商业编码助手的需求。

Claude Code 仍然是 Coinbase 工程师中使用最广泛的 AI 编码助手，与 Forge 并列。Shopify 开发者继续在 River 之外使用 Claude Code 和 Codex。Anthropic 还将 Ramp 列为其企业客户，其工程团队中近一半的人每周使用 Claude Code。

emerging/正在显现的责任划分正在变得清晰。

内部 Agent 主要处理异步工程工作流，这些工作流从 Slack 或问题跟踪器开始，与内部系统交互，并针对生产遥测数据验证变更。

商业助手继续在开发者直接在其编辑器或终端中工作的交互式开发会话中占据主导地位。

这两种方法不是相互替代，而是互补不同的工程工作流。

平台所有权比模型所有权更重要

对于大多数企业而言，问题不再是是否构建或购买 AI 编码助手。

更重要的是决定是否拥有位于开发者和基础模型之间的编排层。

拥有成熟平台工程团队的组织可以证明投资专有工具链是合理的，因为他们获得了集中治理、模型可移植性、安全执行和成本优化。规模较小的工程组织可能继续主要依赖商业工具，由供应商承担运营复杂性。

需求	推荐选项	理由
异步工作，必须查询内部数据库、功能开关和遥测数据以进行自我验证	内部 Agent	专有集成、凭证和验证步骤成为一等公民，而非附加在供应商客户端上的扩展
在熟悉的代码库上交互式工作，编辑器或终端	Claude Code 或 Codex 等商业助手	工程师已经熟悉操作方式，供应商承担运营复杂性
在大型工程组织中更改默认模型	两者前面的内部网关	路由和支出策略只需更改一次，无需要求工程师更换工具
没有专用平台工程团队的团队	带每人配额的商业助手	Forge、River 和 Inspect 背后的投资假设存在负责维护的人员

这与云平台的演进如出一辙，企业有选择性地构建更高级别的抽象，而不试图取代底层基础设施提供商。

AI 经济仍然不可预测

拥有工具链并不能消除基础设施成本。

Walmart 最近在其内部编码助手的需求超出可用预算后引入了使用限制。今年早些时候，Uber 在四个月内耗尽了年度 AI 编码预算，而 GitHub Copilot 已转向基于使用量的积分和开发者配额模式。

斯坦福大学和微软研究院的最新研究有助于解释为什么这些成本仍然难以预测。他们对 Agent 式软件工程任务的分析发现，自主编码工作流消耗的 Token 可能是交互式代码生成的 一千倍。即使是完全相同的任务，Token 消耗也经常出现数量级的差异，这使得预算编制比传统云基础设施困难得多。

因此，成本优化成为平台层的另一个职责，而非模型本身的职责。

平台成为战略资产

最重要的架构转变是企业开始将 AI Agent 视为内部开发者平台的一部分。

十年前，组织通过部署流水线、基础设施自动化和平台工程来形成差异化。如今，他们正在将同样的理念扩展到 AI 辅助的软件开发。

语言模型越来越像可互换的基础设施。企业拥有的工具链成为控制平面，管理上下文、安全、执行、验证和经济。

模型提供商将争相成为它们无法控制的平台的首选推理引擎。

如果通用 Agent 运行时和开放协议继续成熟，而企业保留其策略和上下文层，那么竞争将越来越多地转移到基础模型之上。模型提供商将争相成为它们无法控制的平台的首选推理引擎。

这可能证明是企业 AI 的决定性架构转变。战略优势在于从模型本身转移到决定如何使用、何时使用以及在哪里使用的平台。