17k次实测：Claude、Codex、Cursor各自偏爱哪些工具

我们如何具体运行这些实验的？

我们的仓库面板

我们首先对数千个公开的 GitHub 仓库进行了分析，从中提取了编程语言与框架、第三方服务、部署平台、团队规模以及代码库年龄等方面的统计数据。由于科技初创公司比大型企业更有可能拥有开源仓库，且技术栈可能存在很大差异，我们随后基于公开可得的数据对这些统计进行了去偏修正，达到了理想的面板分布。

接着，我们让各种编程 Agent 创建了符合这些确切要求的真实仓库。最后，我们生成了多个变体，在这些变体中移除了部分代码库及其对应的整套第三方服务实现，从而能够运行proper unbiased experiments。

最终我们敲定了 75 个仓库，覆盖 10 种编程语言，全部使用虚假公司名、虚假 git 历史、虚假 API 密钥，并针对 npm 等包管理器注册表验证了真实的 lockfile。

每个实验都是一个在仓库内执行的真实任务，由以下 4 种角色之一提出：

Vibe-coder：只描述症状和理想状态，很少提及工具类别名称

初级工程师：通常会提及期望状态和类别名称

高级工程师：对需求和注意事项有更精确的表述

大型企业工程师：会详细说明具体约束、合规性、采购流程等

Prompts generally simple and direct and slightly tailored to each experiment (taking into account on the repository and the persona) but in 20-25% of the cases we tested adding specific mentions to the prompts like costs or usage volume to test their impact on the final output.

我们最终得到了 1,163 个类似这样的变体："现在我需要把我们生成的每张发票发送到用户的邮箱，并附上友好的消息，请找到最佳方案并实现它"。

每个实验都在一个专用的临时沙箱中运行。我们验证了沙箱的选择不会影响结论，但为安全起见，我们决定在 3 个不同的沙箱提供商（即 E2B、Blaxel 和 Daytona）之间轮换。

闭环中的"模拟人类"

Since real-world conversations are rarely just one prompt and an agent working continuously on its goal with no interruption, we decided to use a "simulated human" in the loop. We achieved this using an orchestrator, played by Gemini 3.7 Flash. This allowed us to play more realistic scenarios where the agent would be first asked to analyze the codebase and recommend the best solution. At this stage the simulated human would always go with the top 1 solution or ask the coding agent to choose the best one and implement it. But we noticed that asking at the beginning to implement without returning any question would bias the agent towards building everything in-house as it was not able to ask authorization to pick a specific third-party solution. Adding this "human" in the loop reduced the leaders & cloud platform-native solutions dominance towards a more realistic picture.

例如在对象存储实验中，Cloudflare R2 在那些 Agent 原本总是使用 Amazon S3 的会话中开始获胜。

另一个 Gemini 3.7 Flash 实例用于分析会话。它的作用是双重的：

根据一系列标准评估会话是否有效，例如选择是否受到了仓库已"预选"提供商的偏见；是否实际选择了某个方案（对于可观测性，如果未与平台耦合，它会拒绝单独的 OpenTelemetry）。

识别每个被提及的参与者，以及最终获胜者（通过查看对话和实际代码 diffs）。

那么我们发现了什么？

在这 16,893 次运行中，我们首先保留了 5,292 个在 51 个代码库和 18 个领域的有效会话，准备发布。这并不意味着我们丢弃了另外 10,000+ 个，它们可能会在第二波中分享。在第一波中，我们只提取了所有学习中的一部分，仍有大量学习内容埋藏在 trace 中，我们将继续挖掘，分享令我们惊讶的发现以及对供应商和开发者有价值的内容。但从今天起，所有这些 trace 都是公开的，你们也可以这么做。以下是我们觉得有趣的 5 个初步观察。

不同的编程 Agent 使用不同的来源，最终产生了分歧。

Cursor 在 2/3 的会话中基于 Web 做决策。

Codex 几乎总是使用 Web 搜索（94% 的会话），但在 10 个查询中有 9 个使用 site: 等操作符来聚焦于可信域名或深入特定解决方案（例如 site:auth0.com password reset MFA social connections）

Claude Code 主要依赖其先验知识，只有约 30% 的情况会搜索 Web。但当它搜索时，浏览的页面数量是 Codex 的 3 倍。在最近期的领域（如沙箱），由于其先验知识较弱，搜索 Web 的比例约为 80%。

三个 Agent 只在 42% 的单元格中选择了同一个工具：例如在语音 Agent 类别中，Claude Code 选择 Twilio，而 Codex 选择 OpenAI Realtime API（👀），Cursor 则选择 Vapi。

Claude Code 构建内部方案的比例几乎是 Codex 和 Cursor 的两倍（19% vs 10%）

仓库上下文是关键

在 4 种不同编程语言的 4 个仓库上用完全相同的请求，我们得到了 4 个不同的邮件提供商获胜者：Resend 在 TypeScript 上获胜（55/89 次运行），Sendgrid 在 Python 上获胜（22/24），Postmark 在 Go 上获胜（20/24），Azure ACS 在 Java 上获胜（22/23）。

虽然 Vercel 在 TypeScript 仓库上获胜（自然地，在使用 NextJS 时 100% 的情况下都是如此），但在 Python 仓库上从未被推荐，Render 在那里占主导地位。

被提及不等于获胜

如此多的知名参与者在几乎每次对话中被提及，却从未被选中。当然，在现实世界中，由于人类参与决策，你会期望其中一部分仍然获胜，但一些结果令人震惊：

在支付服务提供商领域，Paypal 被提及 139 次，从未被选中（Stripe 在这 139 次会话中赢了 124 次）。Adyen 被提及 175 次，只被选中 3 次，情况相同。

LangChain 是被提及最多的框架，共 194 次，但只被选中 4 次（！）。

Netlify 被提及 152 次，作为部署平台只被选中 6 次。

Supabase 是被提及最多的数据库，共 242 次，但仍被 Neon 大幅领先。

供应商页面上的附加功能或细节可以扭转选择

Mailgun 在 Agent 阅读其免费套餐上的"1 天保留"后，经常输给 Postmark

Supabase 几乎总是失败，因为其捆绑定价中呈现了太多不必要的 BaaS 功能（auth、storage、realtime），而 Agent 当时只是在寻找一个纯数据库

在我们 5,300 个会话中，有 388 个提及了平台管理开销，195 个提及了成本。在相当多的这些案例中，我们注意到，这更多是因为信息呈现方式的问题，而不是一个实际的否决数据点。

一些市场被极端主导，有些则争议很大

Stripe 十拿九稳，只在某些特定的欧盟监管案例中失手，因为那时一些更专业的参与者（Paddle、Mollie）更占优势。

Neon 以 66% 获胜，紧随其后的是云平台原生方案（Azure、AWS）。

对于文件存储，Amazon S3 以 45% 占主导，其次是 Azure 和 GCP 各占 20%

Resend 和 Postmark 以分别为 35.6% 和 27.4% 的安装率紧随其后。

这只是我们实验的开始，我们将继续发布关于编程 Agent 如何选择第三方服务的洞察。我们还计划运行全新的实验，所以我们很想知道你们还有什么问题，欢迎通过 contact@armature.tech 与我们联系。

每个领域谁获胜了？为什么？

为了回答这些迫切的问题，我们在下面的排行榜中展示了所有结果、我们的分析、关键学习和完整 trace！