在软件采购链条里，最近多出了一个新买主：coding agent。它直接写代码、调工具、改工程仓库，哪些开发工具能真正进入项目，全看它挑了谁。
2026 年 9 月，初创公司 Armature 拿出一批大规模实测数据，把这个新买主的行为摸了一遍：一共跑了 16.9K 次沙箱会话，让 Claude Code、Codex 和 Cursor 这三款主流 agent 在合成工程仓库里真正动手接入开发工具，而不是在聊天框里问它们推荐什么。
测出的结果打破了惯常认知。知名度很高的 PayPal 在首批发布集中被提及 139 次，但真正被选中写进代码库的次数是 0。同一个工具，在这个技术栈的仓库里还是大家公认的首选，换到另一个仓库里就直接出局。
如果你自己做开发工具，或者平时每天用 agent 写代码，这份数据都会逼着你重新审视软件分发的逻辑：到底什么样的工具才会被 agent 选中，过去靠品牌和营销堆出来的那套打法还剩多少用处。刚好在同一个月，Y Combinator 宣布举办主题为 Make Something Agents Want 的黑客松，整个生态的关注点与这份数据指向了同一个方向。
这份数据能回答的，是 agent 到底怎么挑工具，核心结论有三条：被提及不等于被采纳；选型跟着语言环境走；大市场高度集中。各结论的具体数字稍后逐条给出；在那之前先看两件事：数据是怎么来的、到底该不该信。它们直接决定了这些数字能证明多远。
先看数据是怎么来的。Armature 准备了几十个合成工程仓库，技术栈分布对齐 GitHub 公开仓库，里面是虚构的企业背景、真实的依赖锁文件。任务要求 agent 完成真实的工具集成：接入支付功能，或者配置交易类邮件发送。全程只记录两件事：agent 提到了哪些工具，哪些真正写进了代码。每个任务配四种开发者人设：注重交付速度的 vibe coder、初级、资深以及企业工程师。
跑接入的是三款主流 agent：Claude Code、Codex 与 Cursor，底层模型分别是 Claude Opus 5、GPT-5.6 Sol 与 Grok 4.6。每个会话里安排了一个模拟用户（由 Gemini 实例扮演，规则禁止它主动点名具体产品），替真实开发者与 agent 多轮交互；中途方案澄清和打回修改分别有 811 次和 734 次，全留在了交互记录里，会话收尾时模拟用户对补丁 100% 批准。最后由另一个独立的 Gemini 实例充当裁判，通读交互记录与最终代码补丁，统计哪些工具被提及、哪一家最终胜出。
测试范围先打个折。在全量 16.9K 个会话中，首批发布只收录截至 2026 年 9 月 2 日的 5.3K 条记录，其余约 69% 没入选，原因主要有三类：agent 版本更新导致旧数据整批隔离、没过审的评测集整体重跑，以及每轮测试固定截取预设顺序的前 N 条以避免事后挑选。具体处理规则见 Armature 的测试说明文档。
可信度同样需要留个心眼。Armature 的主业是提供每月 5,000 美元起的技术增长服务，帮开发工具争取 coding agent 的采纳，公司在报告开头披露了这笔利益冲突：“Disclaimer: Armature sells growth services to dev tools. This study is part of our broader work on how to influence coding agents choices and get products picked.” 既然涉及商业利益，这也是我们复核它的原因：我们下载了 Armature 基于 CC BY 4.0 协议公开的数据集 agent-leaderboards.csv 与接口全量数据，按 9 月 2 日截点筛选后逐位复现了 5.3K 次会话的统计口径，报告核心数字与底层原始记录一致。
第一条，被提及不等于被采纳。支付类一共做了 395 次集成测试，知名度极高的 PayPal 拿到 139 次自然提及，真正进入代码库的次数是 0；在这 139 次运行里 Stripe 赢下了 124 次。agent 在对话里提到的工具，和它写进代码的工具，完全是两回事。
第二条，选型跟着语言环境走。面对完全相同的交易邮件发送需求，四种不同编程语言的工程仓库选出了四个不同的赢家：TypeScript 仓库选了 Resend（55/89），Python 仓库选了 SendGrid（22/24），Go 仓库选了 Postmark（20/24），Java 仓库选了 Azure ACS（22/23）。四门语言对应四个赢家，而且在各自语言里的胜率都超过六成。这组测试样本规模有限，但方向清楚：语言环境主导选型。
第三条，大市场高度集中。样本中 Stripe 在支付场景的胜率高达 88%（349/395）；Neon 在数据库领域同样领先，236/356、胜率 66.3%，在三款受测 agent 的独立统计中采纳率全部位列第一。换开发者人设再看：初级工程师人设下 Neon 入选 104/106 次，在追求交付速度的 vibe coder 人设下更是拿下了 60/60 次。
反过来看，这份数据也有两件事证明不了。首先是胜率不等于市场份额：测试中的模拟用户剥离了人类既有的品牌偏好与历史采购合同，测试环境也是全新的绿地项目；Armature 在报告中自行声明，在现实世界只要有人类参与决策，既有品牌依然能分得一部分份额。其次是 agent 发起部署不等于自主采购：根据 Vercel 披露的数据，其平台由 agent 发起的部署占比虽然超过 50%，但那只是执行层面的动作，并不是选型决策，预算审批与账号绑定的最终权限仍在工程师手里。
所以样本里到底谁排第一，只是这份数据的副产品。它的真正价值，是第一次为行业提供了一个可复现的观察窗口，让我们看清 agent 究竟如何做工具选型。后文正好借由这个窗口解答三个核心问题：软件分发的竞争现在发生在哪里；以往基于传统搜索建立的类比哪些仍然成立、哪些已经断裂；开发工具厂商当下该做什么、不该做什么。
软件交付形态这两年一直在向 AI 靠拢。2025 年初，代码库附带的内容除了人类文档，还增加了直接面向模型的说明文件，就像给新来的实习生准备的上手指南。像 21st.dev 这类平台便展现了这种模式：开发者输入自然语言，平台直接交付界面组件代码。传统软件库交付建材，面向 AI 的组件库直接交付包工包料的施工团队。此前关于 Claude Code 的分析 记录过这种交付模式。
到了 2025 年底，厂商的做法又往前迈了一步：不再只打包功能代码，而是同时交付精简的核心套件、给机器看的组装说明书，以及降低出错率的配套工具。这整套形态被称为生成内核。就像宜家提供标准板材的同时会配齐内六角扳手，生成内核同样追求向自动化工具交付完备接口。它的设计原则是激进透明：面向机器的设计必须尽量暴露原始错误与底层参数，降低模型推理的猜测成本。API 调用失败时，原原本本返回原始错误字段与触发参数，不要吞掉它们换成一句友好的统一提示。此前关于 超越 DRY 的技术思考 曾深入讨论过这种机制。
哪怕厂商打造了适配机器的生成内核，前置问题依然摆在眼前：到底是什么决定了内核能进入 agent 的视线？在工具真正组装进项目之前，必定先存在一个决定谁能进入工程仓库的分发界面，这便是选择层。产品形态决定入选之后好不好用，而选择层决定的，是能否跨过第一道门槛进入工程环境。
谁能跨进这个门槛，底下早已展开了真金白银的较量。在商业服务侧，Armature 推出每月 5,000 美元起的优化咨询，协助开发工具提升在 agent 环境中的采纳概率。在开源生态侧，项目 preseason.ai 则通过定时运行固定提示词与模型快照矩阵，搭建起一套公开对抗的测试面板。
两边的测试数据摆在一起，反差非常明显。在数据库领域，preseason.ai 测试显示 PostgreSQL 占 53.8%，Supabase 占 24.9%，Neon 仅占 5.3%，与 Armature 测试中 Neon 66.3% 的领先优势大相径庭。preseason.ai 在其代码库说明 中写道，评测方法应当公开、可复现且允许质疑，不能仅保留在私有仪表盘中。
两套测试的设计差异给出了合理的解释方向：preseason 让模型直接作答，答案很大程度跟着训练时的品牌熟悉度走；Armature 则让 agent 在沙箱里实际跑接入，结果取决于文档质量与接入链路的顺畅程度。这个推论来自两种测试设计的对照，尚未经过受控对比验证。但这表明，开发工具的竞争重心从单纯的代码能力，扩散到了面向智能体的发现与采纳阶段。
coding agent
获取外部信息的方式，直接决定了工具的触达路径。在测试会话中，agent
主要依靠三类渠道。第一是网络搜索。在 Armature 的报告统计中，基于 GPT-5.6
的 Codex 网络搜索调用率高达 94%；我们在抽样的 57 次搜索里看到 56
次使用了限定域名的 site: 语法。第二是内置厂商知识技能。部分
agent
封装了专属文档查询工具，能够绕过公开搜索引擎直接读取接口。第三是工程仓库的本地记忆与预装文件。agent
会优先沿用项目既有的锁文件与配置结构。
与之对照，Claude Code 整体搜索调用率约 30%，在沙箱这类冷门技术测试中才会升至 80% 左右。业内对此有两种解释。一种观点认为，先进模型倾向于依靠预训练通用知识，因而减少了外部检索；另一种观点来自社区讨论，Hacker News 上活跃的工程师 42piratas 指出差异源于框架本身的权限摩擦：Claude Code 抓取网页需逐个域名向用户申请权限，搜索也有独立门禁，检索仓库既有文件阻力最小，Codex 则无此摩擦。多位工程师反映，除非明确要求调研，否则 Claude Code 很少主动搜索网络。这两类解释目前尚未定论。
至于机器到底怎么读技术文档，学术界和工程落地的动作已经把趋势展现得很清楚了。针对 AI agent 访问文档行为的实证研究 指出，多款 coding agent 访问文档端点呈现独特 HTTP 签名，把多页跳转直接压缩为一到两次请求，传统停留时长与跳出率统计因而失效。Snowflake 在版本公告中 上线分层 llms.txt 与 Markdown 文档，注明供 Cortex Code、Cursor 与 Claude Code 直接读取。GitBook 发布的指南 也支持通过参数直接返回结构化问答，并指明模型选型会综合比对概念与约束表格。
这些触达路径合在一块，构成了工程环境驱动的选择函数。agent 的选型决策高度依赖具体任务的具体条件。面对相同的邮件需求，四种语言仓库导向了不同的供应商；在语音交互测试里，人设仅仅切换为企业工程师，首选工具便转向了 LiveKit（23/76）。微调提示词同样改变结果：在提示词中增加成本考量后，Render 便取得 30/54 胜局，反超同条件下仅获 7/54 的 Vercel。在官方模型对比面板中，模型版本更迭同样重排了选型位次。
大市场格局相对稳定，长尾小市场则全在漂移。前面的实测数据体现了头部的稳固：Stripe 凭借 349/395、Neon 凭借 236/356，在三款 agent 之间稳稳保持住了领先，靠的是清晰的接口规范与较低的接入摩擦。
但在更为分散的长尾领域，不同 agent 的选择呈现明显离散。刚才的语音交互测试在三款 agent 之间选出了三个胜者：Claude Code 偏好 Twilio（23/94），Codex 偏好 OpenAI Realtime（32/110），Cursor 则偏好 Vapi（41/104）。在多项测试中频繁出现的 LangChain，官方记录提及 197 次，最终真正进入代码库被采纳的仅有 4 次。
Armature 报告里还有一个数：各测试间 42% 的选型一致率。这个指标的官方口径没有公开，合理的推测是：同一类任务（同领域、同仓库、同人设）下，三款 agent 选出同一款工具的比例。我们按多种合理口径在首批发布集上复算，得到 41.5% 到 48.2% 的区间，与 Armature 公布的 42% 在数值上相容。这一分布表明，厂商无法指望锁定某种静态的模型偏好，能够持续经营的只有在特定任务上下文中的可达性。
很多人习惯把面向 agent 的工具优化类比为传统搜索引擎优化 SEO。这种类比在宏观上确实有相通之处：软件采购引入了新中介与新渠道，催生出对应的优化服务与测量市场。在 Hacker News 的社区讨论 中，该研究获 300 分与 152 条评论，不少开发者都在担忧新型垃圾信息泛滥。联合创始人 Louis Scremin 回复表示，这有可能演变成比传统 SEO 严重千倍的混乱局面，行业须审慎应对。
真把具体工程机制拆开来看，这一类比在三个环节直接出现了断裂。第一，优化对象的数学形态不同。传统搜索的核心是全局相对稳定的排名函数，排序跨用户通用，厂商可针对固定排名长期优化。coding agent 的决策则依赖具体任务上下文，本质上是选择函数。同一款工具在 TypeScript 仓库胜出，换到 Python 仓库就可能落选；提示词加入成本限制，也会促使 agent 转向。厂商无法优化全局静态排名，目标转为在具体工程上下文中满足代码执行要求。这促成了 Armature 按仓库、语言与人设细分出售评测的商业模式。
第二，安全护栏设立了技术上限。传统搜索时代，网站可通过堆砌关键词操纵排名。在 agent 交互中，过度诱导会直接触发安全防御。Armature 联合创始人 Louis Scremin 披露过一项未发表实验：团队在自建搜索引擎中向特定产品施加过强偏置，立刻触发了防提示词注入机制。主流模型在安全审查时宁可承受误报也不漏过风险。客观平实的信息能提供决策依据，强行操纵则会触发防御直接拦截。
第三，采购决策的责任链路尚未移交。前文提到的超过 50% 部署占比只是执行层数字，账户与付款权仍由工程师牢牢掌握。测试中模拟用户最终批准全部方案，忽略了既有供应商协议、安全合规与历史技术栈约束。在实际生产中，人类构成了软件选型的最终过滤层。
还有一处容易混淆。许多人认为网站加上 llms.txt 就能得到大模型引用，两组独立数据都不支持这个说法：Google 官方指南 明确说明搜索不用此类格式，Search Engine Journal 针对约 30 万个域名的统计研究 也没发现它对搜索引用有正向影响。而且通用搜索引擎的文献引用与 coding agent 的代码集成是两条路径，别拿前者的成熟度赌后者的成熟度，也别拿前者不成熟当借口忽略后者。
面对选择层的出现，开发工具厂商需要建立新的度量视角。工具转化链路可拆为四个阶段：第一，agent 能否在检索中读到工具；第二，工具能否进入方案备选名单；第三，agent 能否在具体仓库中写代码完成接入；第四，集成代码能否跑通测试满足功能。Armature 测试把发现与接入摩擦混合在一起，厂商评估时须将四个环节拆开测量。
结合现有测试推论，厂商在文档建设中可推进四项动作。这些建议属于现状推演，并非现成药方：
第一，明确适用边界。在文档标注适用框架版本与不适用场景，避免 agent 盲目尝试。
第二，公布真实计费与额度限制。测试记录显示 agent 会抓取并理解定价，Mailgun 因免费额度注明一天保留期输给 Postmark，Supabase 因捆绑后端服务定价在纯数据库需求中落选。
第三，提供经过验证的极简运行示例。给出零配置代码片段，减少依赖冲突。
第四，降低接入摩擦。减少交互配置与权限门禁，让代码在沙箱中静默构建。
完善文档时，厂商须划清安全界限。页面信息以提供事实为限，不能触碰注入防御红线。分发入口也是潜在攻击面，页面可提供客观约束，但不能试图索取执行权限。
对待文案优化效果须保持审慎。测试中部署领域的 18 个测试用例全部随提问改变选择，统计的是用户提问措辞变化引发的响应。其实验原始定义是在同一仓库和同一 agent 条件下更换提问语句，并非厂商修改官网文案的受控 A/B 实验。页面文案调整能在多大程度上因果性地改变采纳率，目前缺乏严格对照的实证数据。
在走向真正自动化采购前，行业依然面临三个未决问题。第一，真实工程中，agent 在多大比例上拥有自主选型权，还是仅执行人类指定的安装。第二，厂商修改文档描述，究竟能为采纳率带来多大因果提升且具备统计显著性。第三，随着代理能力扩展，工程师是否会在低风险领域逐步放弃逐项审查，真正将采购权让渡给自动化流程。
此前讨论软件工程时提过一个观点：软件工程正在从构建具体软件，走向构建软件的生成潜力。今天摆在眼前的体会更深了一步：软件蕴含的生成潜力，必须先让 agent 在任务上下文中找到、读懂并顺利调通。这套连接潜能与工程实践的发现机制，构成了软件分发里全新的选择层。