1.7 万次实测：Codex 到底是怎么挑选第三方工具的？
你有没有想过一个问题：当你说「帮我给这个应用加一个数据库」，最终装上 Neon 而不是 Supabase 的那只手，到底是怎么做出判断的？
过去这个判断是人的事。开发者会逛论坛、翻文档、比价格、问同事，最后拍板。但现在，越来越多的人把这件事直接外包给了 AI 编程 Agent。你只描述一个症状，或者提一句需求，Agent 在几分钟内就替你调研、比较、选型，然后动手写代码把它装好。
这件事的权重比很多人意识到的要大得多。去年四月，Vercel 公开过一个数据：平台上超过 30% 的部署是由编程 Agent 发起的，六个月里涨了十倍。换句话说，决定一个第三方服务生死的，正在从「人」悄悄变成「Agent 的口味」。
于是有人做了一件很大胆的事：直接做了一场可能是史上最大规模的实验，去观察 Agent 到底是怎么挑工具的。
一场 1.7 万次会话的观察实验#
做这件事的是 Armature Research，一家专门做开发者工具增长服务的团队。他们想看的是：当 Claude Code、Codex 和 Cursor 面对同一个需求时，它们各自会选谁、为什么选、选得对不对。
实验的规模相当可观：接近 1.7 万次会话，确切地说是 16893 次，覆盖 75 个代码仓库、10 种编程语言、18 个领域，还有 1163 种提示词变体。他们设计了四类提问者，从什么都不懂的氛围程序员，到对合规和采购有一堆要求的大企业工程师。
为了模拟真实场景，他们甚至安排了一个「假人」在对话里打配合。这个假人由 Gemini 3.7 Flash 扮演，负责在 Agent 给出建议后说「就用你推荐的第一名吧」，让 Agent 真的去实现，而不是只停留在口头推荐。因为实验团队发现，如果一上来就让 Agent 直接动手、不许提问，它反而会倾向把所有东西都自己写一遍，而不是引入第三方方案。
最后，从这 1.7 万次会话里，他们筛出了 5292 次有效会话用于分析，还把所有原始痕迹（提示词、思考过程、实际改动的代码）全部公开了。下面是我觉得最有意思的几个发现。
发现一：三个 Agent 的信息来源，几乎不是一个物种#
这是最颠覆我认知的一点。同样是选型，三个 Agent 的「情报渠道」完全不同。
Codex 是重度依赖联网搜索的那个。94% 的会话里它都会去搜网页。更有意思的是，十次搜索里有九次它都用了 site: 这样的搜索运算符，去锁定特定域名，比如 site:auth0.com password reset MFA。也就是说，Codex 不是漫无目的地搜，而是精准地钻进某个服务商的官方文档里挖答案。
Cursor 也有三分之二的会话会联网。而 Claude Code 是个另类，它主要靠自己的「先验知识」直接回答，只有大约 30% 的情况会去搜。但一旦搜起来，它浏览的页面数量是 Codex 的三倍，属于「不搜则已，一搜就把网页翻个底朝天」。
还有一个有意思的细节：在某些比较新、它先验知识比较弱的领域，比如沙箱环境，Claude Code 的搜索比例会飙到 80% 左右。这说明「搜不搜」不是一个固定策略，而是看它对自己答案的自信程度。
发现二：它们只有 42% 的概率达成一致#
如果你以为让三个顶级 Agent 选同一个工具，答案应该八九不离十，那你可能要失望了。实验结果是：三个 Agent 全都选同一个工具的格子，只占 42%。
语音 Agent 这个领域是个绝佳的例子。同样要接一个语音能力，Claude Code 选了 Twilio，Codex 选了 OpenAI 的 Realtime API，Cursor 选了 Vapi。三个答案，各奔东西。
这背后其实挺值得玩味。Codex 选 OpenAI Realtime API，很难说没有「自家人」的倾向在里面。这提醒我们，Agent 的「推荐」从来不是中立的，它带着训练数据、生态绑定、甚至商业关系的烙印。
另外，Claude Code 有个明显的习惯：它倾向于「自己动手造」，把东西写进代码里而不是引入第三方。数据显示它这么做的比例是 19%，几乎是 Codex 和 Cursor 的两倍，后者只有 10%。
发现三：同一个问题，换一个语言答案就变了#
第三个发现是关于「语境」的。同样是「给我的应用加一个发邮件的能力」，放在四种不同语言写的代码库里，居然出现了四个不同的赢家。
TypeScript 项目里赢的是 Resend，在 89 次里拿下了 55 次；Python 项目里赢的是 Sendgrid，22 次里赢了 22 次；Go 项目里是 Postmark，20 次里赢了 20 次；Java 项目里是 Azure ACS，22 次里赢了 22 次。
部署平台也一样。Vercel 在 TypeScript 项目里几乎无敌，尤其当你用了 Next.js 的时候，胜率直接到 100%；但到了 Python 项目里，Vercel 一次都没被推荐过，反而是 Render 主导了局面。
这揭示了一个很关键的事实：Agent 的选型高度依赖代码库的既有技术栈。它不是一个「普世最优解计算器」，而是一个「在特定语境下找最顺手的答案」的引擎。
发现四：被提及，不等于被选中#
这个发现对做开发者工具的人尤其扎心。很多知名产品在对话里被反复提到，却几乎从来不被选中。
支付领域，PayPal 被提到了 139 次，被选了 0 次。而 Stripe 拿下了这 139 次里的 124 次。Adyen 更惨，被提到 175 次，只被选了 3 次。
框架领域，LangChain 是被提及最多的框架，194 次，但只被选中 4 次。部署平台里，Netlify 被提到 152 次，只被选 6 次。
数据库是最典型的。Supabase 是被提及最多的数据库，242 次，但最终被 Neon 大幅碾压。
这个现象说明：Agent 在做选择时，会先把一批「候选者」列出来，然后逐个比较、淘汰。「被提及」只是进入了候选名单，「被选中」才是真正的胜利。而很多产品的落败，不是因为它不好，而是因为在 Agent 逐条比较时，某个细节让它出局了。
发现五：页面上的一个细节，就能翻转胜负#
第五个发现解释了「为什么好产品也会输」。答案是：有时候只是一个页面措辞的问题。
Mailgun 经常输给 Postmark，原因听起来很荒谬：Agent 读到了它的免费计划有「1 天保留」这个限制，于是判定它不适合。
Supabase 的失利也是类似的逻辑。它几乎总是因为「捆绑了太多用不上的功能」而输掉，比如把 auth、存储、realtime 一起打包卖，但 Agent 明明只要一个数据库。多出来的东西非但没加分，反而成了扣分项。
在 5292 次有效会话里，有 388 次提到了「平台管理开销」，195 次提到了「成本」。而在相当一部分案例里，这些负面的判断，更多来自信息的呈现方式，而不是产品本身真的不行。这对服务商是个巨大的提醒：你写在定价页和文档里的每一个字，可能正在被某个 Agent 逐字阅读并打分。
发现六：有些市场，一家独大到可怕#
最后看看结果的整体格局，你会发现很多领域已经出现了极端集中。
支付：Stripe 十次里赢九次，只有在一些受欧盟监管的特定场景里，才会输给 Paddle、Mollie 这种更垂直的玩家。数据库：Neon 拿下了 66%，剩下的被云厂商原生方案分走。文件存储：亚马逊 S3 以 45% 领先，Azure 和 GCP 各占 20% 左右。邮件服务：Resend 和 Postmark 咬得很紧，分别是 35.6% 和 27.4%。
这种集中度意味着，一旦某个产品在 Agent 的心智里占了上风，马太效应会非常明显，后来者想翻身会越来越难。
我的几点思考#
看完这组数据，我有三个感想想分享。
第一，Agent 正在成为软件分发的新入口，而且这个入口有极强的「记忆」和「偏好」。过去你争夺的是开发者的心智，现在你争夺的是 Agent 训练数据和网页文档里那几行字。谁能被 Agent 更准确地「读懂」，谁就更可能被选中。
第二，对开发者来说，「让 Agent 替我选」是一把双刃剑。它能省时间，但选择结果带有明显的生态偏见和语境依赖。Codex 会倾向 OpenAI 自家产品，换一种语言栈可能就换一个答案。所以在关键的基础设施选型上，Agent 的建议值得参考，但不该被无条件信任。
第三，对服务商来说，这场游戏的规则变了。你不再只是写给人看的文档，还要写给 Agent 看的文档。清晰的定价、明确的边界、干净的对比，比华丽的营销词更值钱。因为你的对手不再是竞争对手的销售，而是一个会逐字阅读并打分的模型。
Armature 表示这只是第一波结论，后面还会继续挖。但仅凭这一波，有一点已经很清楚了：软件世界的权力，正在从「写代码的人」向「替人做决定的 Agent」转移。而这场转移，才刚开始。