一份 1.7 万次跑测的工程师视角报告

近期,Agent 工具评测机构 Armature 团队发布了一项堪称迄今为止规模最大的实证研究——他们在 75 个代码库、10 种语言、1,163 条 prompt 变体、3 个沙箱供应商之间,让 Claude Code、Codex、Cursor 三款主流编程智能体总共跑了 16,893 个真实任务会话,从中筛选出 5,292 个有效样本,逐一回看每一条对话流和最终的代码 diff。这份研究的特别之处在于:它不是为了测模型会不会写代码,而是为了测「智能体在没有任何人意见时,会自己挑哪一款第三方服务」。

这个问题的提出动机是具体的。Armature 在文章开头举了一个数据库选型的例子:一个 vibe coder 写了个人旅行 app,发现每次重连数据就丢,他对 Claude Code 说「我需要把我输入的内容存在某个地方,下次打开还能看到」;5 分钟后 Claude Code 回:「你需要数据库,Neon 很合适,因为它有免费档、装起来快,而且不像 Supabase 那样不用就暂停」。用户接受了,智能体把 Neon 装上,事情结束。

Armature 紧接着模拟了一个对偶实验:一个资深工程师在生产级应用里问 Cursor「这个 app 最佳数据库方案是什么,要成本可控、完全托管」;5 分钟后结论一样,推荐 Neon,理由不同——「它对成本预期和企业级需求更匹配」。两个沙箱、两套智能体、两套代码库、两组人设、两套 prompt,同一个结论。Armature 由此追问:如果把这种实验推广到更多工具品类、更多上下文、更多画像,结论会改变吗?

这个问题对开发者重要——他们需要判断「能否信任智能体的选型判断」;但对供应商更重要,因为他们的生死很快就取决于能否被编程智能体选中。Armature 引用了 近期一家头部平台披露的数据:「超过 30% 的部署由编程智能体发起,半年内增长了 1000%」。当智能体成为采购决策的实际执行者,选型研究就从「用户调研」变成了「机器可读的排名」。

五条让厂商和工程师都该警觉的发现

Armature 在 5,292 个有效会话里提炼出 5 条第一手观察,每一条对供应商的产品决策和工程师的信任边界都构成直接冲击。

  • **第一条,三款智能体使用不同的信息源,结果也相互冲突。** Cursor 在三分之二的会话里依赖网页搜索;Codex 几乎每个会话都用 web 搜索(94%),但 10 次查询里有 9 次会带上 site: 限定符去聚焦可信域或某个具体方案(例如 site:auth0.com password reset MFA social connections);Claude Code 主要依赖模型先验,只在约 30% 的会话里搜网页,但一旦搜,浏览页数是 Codex 的 3 倍。在更新的领域(比如沙箱),Claude Code 没有先验可依赖,搜索比例会升到 80%。三者只在 42% 的细分品类里挑同一款工具,多数品类各有偏好——例如语音智能体,Claude Code 选 Twilio,Codex 选 OpenAI Realtime API,Cursor 选 Vapi,完全是三个不同的世界。
  • **第二条,Claude Code 比另外两家更倾向自建。** Claude Code 自行构建的比例是 19%,Codex 和 Cursor 都是 10%,几乎相差一倍。这意味着在 Claude Code 主导的工作流里,开源 SDK 和自研组件被选中的概率显著高于其他两款智能体生态——这是供应商做集成适配时必须考虑的非对称性。
  • **第三条,代码库上下文是决定性的。** 同一个邮件发送需求,在 4 个不同语言的代码库里得到 4 个不同的胜者:TypeScript 选 Resend(89 跑 55 胜),Python 选 Sendgrid(24 跑 22 胜),Go 选 Postmark(24 跑 20 胜),Java 选 Azure ACS(23 跑 22 胜)。某头部平台 在 TypeScript 仓库里全胜(NextJS 项目里 100% 被推荐),但在 Python 仓库里从未被推荐,后者由 Render 主导。**对供应商来说,「在主流仓库生态里的语言适配深度」是隐形准入门槛,不是 SEO 关键词密度。**
  • **第四条,被频繁提及不等于被选中。** 这是 Armature 最反直觉的一条。Armature 统计了品类内提及次数与最终胜出次数的偏离度:PayPal 在支付服务商品类里被引用 139 次,一次都没被选中;Stripe 在这些会话里赢下了 124 次。Adyen 被引用 175 次,只赢 3 次。LangChain 是被提及最多的框架,194 次,只赢 4 次。Netlify 被引用 152 次,作为部署平台只赢 6 次。Supabase 是被引用最多的数据库,242 次,仍然被 Neon 大幅压制。结论非常直接:**SEO、PR、行业露出,在智能体的选型逻辑里不是决定性变量,被「读到」和被「选中」是两件事。**
  • **第五条,产品页面的小细节会翻盘选型。** Mailgun 在很多会话里输给 Postmark,原因不是产品本身弱,而是智能体读到了它免费档「1 天留存」的限定后放弃;Supabase 几乎总是输在「过多不必要的 BaaS 功能(鉴权、存储、实时)被打包定价」,而智能体其实只在找数据库。Armature 在 5,292 个会话里看到 388 次提到平台管理开销,195 次提到成本,其中很多不是因为数据真的不可接受,而是信息呈现方式让智能体做出了负面判断。**对一个工具供应商来说,产品页面的「意图清晰度」直接决定胜率,不是表面流量问题。**

为什么「被提到」不等于「被选中」——TDQS 给出的解释

与 Armature 几乎同一天(也是 近期),MCP 生态的核心维护者 Glama 团队发布了 TDQS(Tool Definition Quality Score,工具定义质量评分)开放规范,这是给 15,036 个 MCP 服务器、228,369 个工具打分的事实标准。TDQS 的研究恰好补上了 Armature 没有回答的那个缺口——**智能体在挑工具时,究竟读了什么、依据什么做决定**。

TDQS 把每个 MCP 工具的描述拆成 6 个加权维度打分:目的清晰度 25%、使用指引 20%、行为透明度 20%、参数语义 15%、简洁与结构 10%、上下文完整性 10%。服务器层面还有 4 个平权维度:消歧能力、命名一致性、工具数量恰当性、覆盖完整性。每个维度都有公开锚点,模型按锚点评 1-5 分,每个分数都带书面理由。最终聚合成分数(1.0-5.0)和等级(A/B/C/D/F),B 是发布门槛。

Glama 在 856 个工具、103 个服务器的研究里给出了一个残酷数字:**97% 的工具描述都至少带一项缺陷,89% 的描述从来没说过「什么时候该用这个工具」**。他们做了一个对照实验:重写工具描述,不动一行代码,任务成功率提升了约 6 个百分点;而描述质量越高的工具,被智能体实际调用的频率大约是低质量工具的 2.6 倍。

这个数字跟 Armature 的发现咬合得极紧——Supabase「过多 BaaS 功能被打包定价」是描述层没讲清楚「什么场景用 Supabase」、Mailgun「1 天留存」是描述层没讲清楚「免费档约束」,LangChain 被频繁引用却极少被选中,大概率也是描述层没锚定「什么任务用 LangChain 而不是别的框架」。**Armature 测的是行为,TDQS 测的是原因,两者合并起来给出了一个完整的因果链:智能体选型的胜负不取决于你被多少人讨论,取决于你的工具描述能否在 0.5 秒阅读窗口内讲清楚「我是谁、什么时候用、什么时候不要用」。**

对厂商和工程师的双向启示

这两份报告叠加起来,把 2026 年下半年的 agent 工具生态切成几个明确的赛道,每个赛道都有不同的应对策略。

**对供应商而言,SEO 和 PR 的边际效用正在快速衰减。** Armature 的数据里,LangChain、Supabase、Netlify 这些被引用次数前三的工具,胜出率分别只有 2%、被 Neon 压制、6%。原因是智能体的推理逻辑更接近「先验 + 网页信号 + 文档细节」三层权重,而不是「链接流行度」。一个在 Python 仓库生态里写出比 Sendgrid 更清晰 API 文档的邮件服务商,有可能在 24 个月内把胜率从 0% 翻到 60%,即便它在主流社区上从未露过面。

  • **对工具供应商来说,代码库语境的适配从可选项变成必选项。** Armature 用 Resend/Sendgrid/Postmark/Azure ACS 在四种语言里的胜率差异证明了一件事:智能体不会泛化你的产品定位,它会按当前代码库的具体语言、框架、依赖管理工具做局部最优选择。一个 NextJS 项目里的邮件选型和一个 Django 项目里的邮件选型,推荐结果可以完全不同。**把自己的 SDK 深度嵌入每种主流语言的「启动模板」,比任何营销预算都更直接地提升胜率**——这是 Armature 的实测结论。

**对独立开发者和小团队来说,这是一个空窗机会。** 当 LangChain、Supabase、PayPal 这种「行业默认答案」在智能体选型里被边缘化,反而意味着它们并不是真正的护城河。一个描述清晰、目标场景明确的小工具,在 agent 工作流里有相当大的概率被选中——但前提是它的工具描述能通过 TDQS 的 B 级门槛,并且它的产品页面能让智能体在 1-2 次抓取里读懂核心定位。**这意味着 2026 年下半年,工具供应商竞争的主战场从「被多少人搜到」迁移到「被智能体读懂多少」**。

  • **对企业 IT 决策者来说,这两份数据点出了一个潜在风险:智能体的选型并非「客观最优解」。** Claude Code 自建倾向显著高于其他两家(19% vs 10%),意味着企业里部署 Claude Code 的工程团队会走「自己造轮子」的路径更多,而部署 Codex 或 Cursor 的团队会更倾向直接装第三方服务——同样的业务需求,选型不同会带来截然不同的技术债曲线。**给团队选哪款编程智能体,本身就是一个会被写入未来 5 年技术债账单的产品决策**,而这件事在过去两年被严重低估。

一个尚未解决的核心问题

Armature 在文末说了一句非常坦诚的话:**「这是我们实验的开始,我们会持续发布智能体如何选择第三方服务的洞察……我们也计划跑全新的实验,所以想知道你们还有什么问题没解决。」**

这句话背后是一个公开的挑战:智能体选型的可解释性。这 1.7 万次跑测告诉了我们「智能体做了什么选择」,但还没告诉「为什么」。而 TDQS 把工具描述分维度量化,部分补上了「智能体读了什么」的缺口,但也带来了新问题——**当一个工具描述优化到极致,它在智能体选型里就一定能胜出吗?有没有「描述完美但产品不行」或者「描述朴素但产品极强」的反例?** 这正是 OpenBenchmarks、Glama、Armature 这些独立第三方测评机构在 2026 年集体努力填补的方向——**构建一个能让智能体独立完成「发现 → 评估 → 复现」全链路的 benchmark 生态**。

对企业决策者来说,这两份数据最直接的含义是:**未来 12-24 个月里,你看到的大部分「AI 工具选型榜单」都可能是过时的,因为它们还在用人对人的评测口径;真正决定工具生死的,将是这些独立第三方用 TDQS、Armature 这类机器可读的评测口径给出的数字**。

而对开发者来说,这两份数据点的意义更朴素——**写好工具描述、说好使用场景、把产品页面讲到智能体能读懂,这件事的边际收益,可能在 2026 年下半年超过任何一种传统的工程优化手段**。