当 coding agent 替你选技术栈:17k 次真实跑动里的厂商博弈

2026 年 9 月初,YC P26 批次的 Armature 团队公开了一份关于 coding agent 工具选择行为的最大规模实测研究——16,893 次跨 agent、跨代码库、跨人设的会话,涉及 Claude Code、Codex、Cursor 三款主流编程助手,75 个仓库、10 种编程语言、18 个行业,1,163 种 prompt 变体。这份研究的结论不只是"agent 选了什么",而是更上游的命题:在 vibe-coder、初级工程师、高级工程师、大厂合规工程师四种人设下,同一个需求会得到不同的技术栈推荐;同一段 prompt 在 4 种语言仓库里会指向 4 个不同的赢家。这件事正在重新定义 SaaS 厂商的生存逻辑——"被 agent 选中"正在变成和"被 Google 搜到"同等重要的事。

几乎同一时间,一个独立项目 Preseason.ai(由 HN 评论者 thedreammachine 推荐)从另一个角度印证了同一趋势:它把高级 vibe-coding prompt 冻结成面板,持续追踪每次主流 LLM 在不同任务下推荐什么工具。Armature 的研究给出的是"现场跑动",Preseason 给出的是"回归面板"。两者合在一起,标志着一个新产业正在成形——不是 LLM 之间的竞争,而是 LLM 与 LLM 之间、由第三方工具库构成的"被 agent 选中"的市场争夺。

17k 次跑动里学到的 5 件事

Armature 的实验设计非常克制。75 个仓库全部用假公司名、假 git 历史、假 API key,但用真实的 lockfile 在 npm 等包管理器上验证——确保 agent 推荐的工具确实"装得上、跑得起来"。每个实验运行在 E2B、Blaxel、Daytona 三家 sandbox provider 之一,通过 Gemini 3.7 Flash 扮演的"模拟人类"在中间做对话推进,Gemini 3.7 Flash 的第二个实例充当 judge,评估会话是否有效、谁被提到、谁最终被选。规则上特意要求:agent 必须实际把方案装到代码里、跑通,而不只是"口头推荐"——这避免了大量"纸上谈兵"的结果。

从 16,893 次跑动里筛出 5,292 次有效会话后,Armature 团队分享了 5 个值得所有人记住的核心观察。

第一,三个 agent 用不同的信息源,经常得出不同结论。Cursor 在 2/3 的会话里会主动搜网;Codex 在 94% 的会话里搜网,其中 90% 用 site: 限定符精确到可信域名;Claude Code 主要靠训练先验,只在 30% 的会话里搜网,但一旦搜就会读 3 倍于 Codex 的页面。在更新更快的细分赛道(sandbox 等)里,Claude Code 的先验更弱,搜网率会升到 80%。三个 agent 在全部赛道的胜率一致性只有 42%——比如语音 agent 这一格,Claude Code 选 Twilio,Codex 选 OpenAI Realtime API,Cursor 选 Vapi。

第二,Claude Code 几乎两倍于其他 agent 倾向于自建。19% vs 10% 的自建比例差异意味着,在 Claude Code 用户的工作流里,将近五分之一的需求会被 agent 评估为"自己实现比引入第三方更合适",而 Codex / Cursor 用户这个比例只有十分之一。这对工具厂商来说是一个直接的信号——Claude Code 的"先验自信"会让第三方工具被评估的机会更少。

第三,代码库语境决定了胜者。同样是"给发票发邮件"的 prompt,TypeScript 仓库里 Resend 以 55/89 次胜出,Python 仓库里 Sendgrid 以 22/24 次胜出,Go 仓库里 Postmark 以 20/24 次胜出,Java 仓库里 Azure ACS 以 22/23 次胜出。Vercel 在 TypeScript 仓库(尤其 Next.js 项目)里 100% 胜出,但在 Python 仓库里从未被推荐——Render 在那里几乎垄断。结论很清楚:不是 agent 在选择,本质上是"代码库里已经有什么"在选择。

第四,被提到不等于被选中。这是对所有 SaaS 厂商最冷的一个数字:PayPal 在支付赛道被提及 139 次、0 次被选;Adyen 被提及 175 次、只被选 3 次;LangChain 被提及 194 次、只被选 4 次;Netlify 被提及 152 次、只被选 6 次;Supabase 被提及 242 次、依然被 Neon 在大多数情况下压倒。这是一份非常直白的"提及 vs 转化"漏斗——"你知道我"和"你选我"之间的距离,远比传统 SEO 时代更远。

第五,定价页和功能描述本身就是变量。Mailgun 在 free plan 上有"1-day retention"这一条,经常因此输给 Postmark;Supabase 在打包定价里塞进了 auth、storage、realtime 等一堆 BaaS 功能,经常因此输给"只做数据库"的 Neon。Armature 团队直接说:"在 195 条提到成本的会话里,大部分不是因为成本真的不可接受,而是因为呈现方式让 agent 误判了它"。这意味着 SaaS 厂商对 agent 的产品描述方式,会直接影响推荐率。

为什么这件事不只是"AI 时代的新 SEO"

把 Armature 和 Preseason 放在一起看,会发现一件更结构性的事情:在被 agent 选中的市场里,"排名第一的胜者"和"被提及的次数"几乎不相关。在传统 SEO 里,被引用、被列入列表、被多家媒体报道,会通过 PageRank 间接推高排名;但在 agent 选择场景里,agent 读完几页文档后给出的"最终结论"是另一个独立的决策过程。这件事 Armature 团队用一句话总结得很到位:"被提到是基本盘,被选中是另一个游戏"。

更进一步,Armature 的数据还暴露了一个反直觉的现象:Claude Code 的"先验自信"反而让它成为工具厂商最难撬动的对手。Codex 和 Cursor 大量依赖实时网页搜索,意味着厂商只要被几家媒体引用、被几篇博客点名,就有机会在 Codex / Cursor 的检索结果里出现;但 Claude Code 只在 30% 的会话里搜网,剩下 70% 直接靠训练先验决策——这意味着 Claude Code 用户的工作流里,工具厂商的曝光位更少、更难争取。

对厂商的实操启示是分层运营:在 Codex / Cursor 生态,持续生产深度对比文章、技术评测、用户案例,目标是被搜网时进入候选名单;在 Claude Code 生态,直接走"训练先验"路线——出现在 GitHub 高 star 项目的 README、出现在权威 benchmark(SWE-bench Verified 等)、出现在 v0.dev 之类的官方 demo 里。后者比前者更难,但回报也更稳定,因为先验决策不会被某条负面评论一次性颠覆。

Vercel 的 30% 数字:为什么厂商现在必须在意 agent

Armature 在文章开头引用了 Vercel 2026 年 4 月披露的一个数字:"超过 30% 的部署是由 coding agent 发起的,较六个月前增长 1000%"。换算一下:在六个月内,agent 触发的部署占比涨了 10 倍。这个曲线如果继续走 6-12 个月,到 2027 年,大量 B2B SaaS 的"新用户来源"会变成"由 coding agent 替企业员工安装"。

对一个中型 SaaS 厂商而言,这个趋势的战略含义非常直接:传统的"PLG + SEO + 内容营销"飞轮正在被加上一条新链路——"Agent readability"。这条新链路的核心不是把网页做漂亮,而是让文档结构化、让功能描述精准、让定价页不被误解、让 lockfile 能直接装上。Armature 的数据已经显示,Mailgun 因为"1-day retention"这条短说明输掉了大量 agent 评估——这不是 SEO 能修的,这是文档工程问题。

HN 评论里 drivingmenuts 一句"a money-making opportunity"很精准地点中了这件事的商业本质。已经有公司(像 Armature 自己)在卖"帮工具厂商被 agent 选中"的增长服务——这是 agent 时代的新型 SEO 公司。但更长期看,任何有 PMF 的工具厂商都需要把"agent readability"作为产品功能的一部分,而不是外包给第三方增长公司。

从实测到落地:开发者与企业该怎么理解这件事

对一线开发者,Armature 的数据其实提供了一个反向有用的工具:如果你不信任 agent 的工具推荐,你可以用 prompt 工程让它重新评估。比如,显式说"不要 Stripe,我在找一个 EU 合规友好的支付商",或者"不要 Neon,我要全自托管 PostgreSQL",agent 就会重新跑检索逻辑。这意味着 agent 的"默认选择"不是终点,而是一个可以被人为引导的起点。

对企业技术决策者,Armature 的数据暗示了三个值得立刻审视的问题。第一,你的工程师在让 agent 选型时,有没有能力在 review 阶段识破 agent 的"先验偏好"——尤其是 Claude Code 的高自建倾向是否会让你的某些工具被悄悄跳过。第二,你的现有工具栈是否已经在 agent 推荐榜上——如果你用的是某个"被提及 100 次但被选 0 次"的工具,意味着未来 6-12 个月里它被 agent 引入的概率很低,工程师上手成本会变高。第三,你的代码库语境(语言、框架、已有依赖)是否在反向锁死你的 agent 推荐范围——同一个需求在不同语言下会推荐不同的数据库,这是工程团队必须显式管理的"上下文变量"。

对企业级 SaaS 厂商,这件事的优先级已经不是"做不做"而是"怎么做"。具体来说,产品文档页需要重写为"agent readable"结构:功能描述独立成节、可量化指标优先(延迟、限额、价格)、错误处理路径显式说明、定价页剥离交叉销售、SDK 安装路径直接走 lockfile。这些工作不是营销,而是产品工程,优先级应该和 API 文档的版本化、SDK 的 npm 发布对齐。

新范式的雏形:Agent 选中型 SaaS 的工程基线

Armature 的研究只是这个领域的第一波公开实测。Preseason 的面板、其它第三方评测、独立分析机构都可能陆续进场。但无论谁做,方法论上未来 12 个月会形成一些可被广泛接受的"agent readability 工程基线"——文档结构化是其中一项、定价页拆解是一项、benchmark 覆盖是一项、README 兼容性是一项。这些工程基线一旦稳定,会和今天的 API 设计规范、安全开发规范一样,成为 B2B SaaS 的硬门槛。

对企业级 coding agent 用户,最值得现在就做的一件事是建立"agent 推荐审计"流程:每季度抽样若干 agent 在你的核心需求上的推荐结果,对比你当前的技术栈,记录差异。如果一个工具反复被 agent 选中而你没用,这可能是一个被错过的机会;如果一个工具反复被 agent 跳过而你在用,这可能是一个未来 12 个月需要认真评估的风险。前者是被低估的潜力,后者是被高估的惯性。

这件事的长期意义,远超"被 AI 选中"的市场份额。它本质上是企业技术决策权的一次再分配——从人手里,部分转移到 agent 里。理解并主动管理这次转移,而不是被动接受,是接下来 12 个月所有认真做技术决策的人都必须面对的命题。