编码代理工具选择实测：Claude、Codex与Cursor的偏好分析

样本代码库选择

我们首先对数千个GitHub公开代码库展开分析，提取编程语言与框架、第三方服务、部署平台、团队规模及代码库年限等维度的统计数据。考虑到科技初创企业比大型企业更倾向于开放代码库，且两者技术栈差异显著，我们基于公开数据对统计结果进行校正，最终确定了理想的样本分布。

随后，我们部署多组代码生成智能体，严格按照上述要求创建贴合真实场景的代码库。为开展无偏差对照实验，我们还生成了变体样本——移除部分代码及完整的第三方服务实现模块。

最终形成的样本库包含75个代码库，覆盖10种编程语言，所有样本均使用虚构公司名、虚构Git提交历史、虚构API密钥，同时搭配经npm等包管理器注册表校验的真实锁文件。

真实场景任务设定

每项实验对应代码库中的一项真实任务，任务需求由以下四类角色提出：

• 直觉型开发者：仅描述问题现象与理想结果，极少提及工具类别
• 初级工程师：通常说明预期目标与工具类别
• 高级工程师：对需求及禁忌事项描述精准
• 大型企业工程师：详细列出约束条件、合规要求、采购规范等

任务指令简洁直接，会根据代码库特性与角色身份稍作调整。此外，我们在20%-25%的实验中，特意在指令中加入成本、使用量等细节，测试其对最终输出结果的影响。

最终共生成1163种任务变体，例如：“请实现功能，将生成的每一张发票附友好说明发送至用户邮箱，需选用最优方案”。

实验运行环境

每项实验均在独立的临时沙箱中运行。我们已验证沙箱选择不会影响结论，但为确保严谨性，仍在E2B、Blaxel、Daytona三家沙箱服务商间轮换使用。

引入“模拟人类”交互环节

现实场景中，开发者与智能体的对话很少是“单次指令+持续执行”的模式。因此我们引入“模拟人类”交互机制，由Gemini 3.7 Flash扮演协调者角色，构建更贴近真实的实验场景：智能体先分析代码库并推荐最优方案，模拟人类会选择排名第一的方案，或要求智能体自行选定方案并实现。

我们发现，若一开始直接要求智能体实现功能而不预留提问空间，会导致智能体倾向于全部自研——因为它无法请求授权选用特定第三方服务。引入“模拟人类”环节后，头部厂商及云平台原生方案的主导地位有所下降，结果更符合真实情况。

例如在对象存储实验中，此前智能体几乎全部选用Amazon S3，引入交互后，Cloudflare R2开始在部分会话中胜出。

实验结果评审

我们使用另一实例的Gemini 3.7 Flash对实验会话进行评审，其职责分为两部分：

• 有效性校验：对照预设标准判断会话是否有效，例如代码库是否已预先选定服务商导致结果偏差；是否真正选定了完整解决方案（如可观测性场景中，若仅选用OpenTelemetry而未搭配平台则判定无效）
• 结果判定：识别会话中提及的所有服务商，并根据对话内容与实际代码差异确定最终选用方案

核心发现

本次实验共运行16893次，我们筛选出5292次有效会话，对应51个代码库、18个行业领域，相关结果将率先发布。其余1万余次会话并未废弃，后续可能作为第二波研究内容分享。目前我们仅从会话痕迹中提取了部分发现，后续将持续挖掘更多值得厂商与开发者关注的结论。所有会话痕迹现已公开，欢迎自行探索。以下是首批5项有趣发现：

不同代码生成智能体的决策逻辑存在分歧

• Cursor：2/3的决策基于网络搜索
• Codex：几乎全程依赖网络搜索（占94%的会话），且每10次查询中有9次使用site:等搜索运算符，聚焦可信域名或特定方案（例如site:auth0.com password reset MFA social connections）
• Claude Code：主要依赖内置知识库，仅约30%的场景会进行网络搜索；但搜索时浏览的页面数量是Codex的3倍。在沙箱等新兴领域，因其内置知识库覆盖不足，搜索占比升至约80%
• 三者选择同一工具的情况仅占42%：例如在语音智能体类别中，Claude Code选Twilio，Codex选OpenAI Realtime API（👀），Cursor选Vapi
• Claude Code的自研比例几乎是Codex和Cursor的两倍（19% vs 10%）

代码库上下文是关键决策因素

• 针对4个不同编程语言的代码库提出完全相同的邮件发送需求，最终胜出的服务商各不相同：Typescript环境下Resend胜出（89次运行中55次选择），Python环境下Sendgrid胜出（24次中22次），Go环境下Postmark胜出（24次中20次），Java环境下Azure ACS胜出（23次中22次）
• Vercel在Typescript代码库中胜出（使用NextJS时更是100%被推荐），但在Python代码库中从未被推荐，该场景下Render占据主导

被提及不等于被选用

许多知名厂商几乎在每段对话中都会被提及，但从未被选中。现实中人类介入可能会改变这一局面，但部分结果仍令人惊讶：

• 支付服务商领域：Paypal被提及139次，但从未被选用（这些会话中Stripe胜出124次）；Adyen被提及175次，仅被选用3次
• LangChain是被提及最多的框架（194次），但仅被选用4次（！）
• Netlify作为部署平台被提及152次，仅被选用6次
• Supabase是被提及最多的数据库（242次），但市场份额远不及Neon

厂商页面的细节会影响决策

• Mailgun的免费计划标注“数据保留1天”，导致其多次输给Postmark
• Supabase几乎次次落选，原因是其捆绑定价中包含认证、存储、实时同步等过多非必要BaaS功能，而智能体仅需纯数据库服务
• 在5300余次有效会话中，有388次提及平台管理成本，195次提及费用。我们发现，多数情况下影响决策的并非成本本身，而是信息呈现的方式

各领域竞争态势差异显著

• Stripe在10次实验中赢下9次，仅在受欧盟严格监管的场景中输给Paddle、Mollie等垂直服务商
• Neon以66%的占比领先，紧随其后的是Azure、AWS等云平台原生方案
• 文件存储领域：Amazon S3以45%的占比主导，Azure和GCP各占20%
• 邮件服务领域：Resend与Postmark占比接近，安装率分别为35.6%和27.4%

这只是我们实验的开端，后续将持续发布代码生成智能体选择第三方服务的相关洞察。我们还计划开展全新实验，欢迎通过contact@armature.tech提出你的疑问。

各领域胜出者是谁？原因何在？

为解答这些关键问题，我们在下方排行榜中公开了所有实验结果、分析过程、核心结论及完整会话痕迹！