编程 Agent 正在替你选择供应商，但推荐结果不是市场份额
据 Armature 公布的实验，面对支付、邮件、数据库等需求，不同编程 Agent 往往不会选同一个外部服务。研究项目共进行了 16,893 次运行，但首批公开分析使用的是 51 个代码库中的 5,292 个会话，不能把总运行量直接写成有效样本，更不能当成真实开发者采购次数。
作者：林岚｜OC 开发者生态编辑
据 Armature 公布的实验，面对支付、邮件、数据库等需求，不同编程 Agent 往往不会选同一个外部服务。研究项目共进行了 16,893 次运行，但首批公开分析使用的是 51 个代码库中的 5,292 个会话，不能把总运行量直接写成有效样本，更不能当成真实开发者采购次数。
一句话结论：Agent 已经可能影响软件选型的第一步，但实验中的“被选中”既不是市场份额，也不是团队已经授权购买。
模型拿到的不是一张空白采购单
这项实验使用带有依赖锁定文件等上下文的合成代码库，模拟不同语言、行业和开发者类型。交互中的“人类”由模型扮演，结果再由另一套模型流程判断与归类。它适合观察受控条件下的工具选择，却没有覆盖真实组织里的采购审核、历史合同和同事争论。
实验里，三种 Agent 在相同测试单元中全部选中同一工具的比例只有 42%。语言环境也明显影响结果：例如，邮件服务在 TypeScript 与 Python 代码库中的选择分布并不相同。研究还记录了不同 Agent 使用网页搜索的差异。这些都是特定版本、提示和运行环境下的观察，不是产品永远不变的性格。
一个项目已经使用某套 SDK，迁移成本可能比“哪个服务最强”更重要。锁定文件、框架默认示例、现有环境变量，都会成为 Agent 的线索。因此，所谓模型偏好，可能混合了训练材料、当前搜索结果和仓库约束。仅凭最终选择，很难把三者拆开。
文档开始接近采购入口
过去，开发者常常先决定服务，再查接入文档。Agent 工作流可能反过来：先找到一份能完成任务的文档，再把对应服务写进代码。服务商竞争的对象于是多了一层——不是搜索结果里能否出现，而是说明能否被可靠地执行。
这不意味着厂商应该堆满“适合 AI”的宣传句。对实际集成有帮助的是清楚的鉴权方式、可运行但不泄露秘密的示例、费用边界、失败语义和清理资源的方法。Agent 能复制一段成功示例，却不理解重试会重复扣费，文档的转化率越高，事故面可能反而越大。
对团队来说，仓库内的约束应当比口头偏好更具体。“尽量便宜”不足以指导数据库选择；“必须部署在某区域、已有供应商优先、不得开通收费套餐、生产数据不能外传”才是可以检查的条件。约束还需要落到工具权限，不能只期待模型每次都记住文字。
生成了集成代码，不等于完成了选型
设想 Agent 给项目加上邮件发送功能，顺手选了一个服务。代码能运行，只能说明接入路径大致成立。团队还需要判断发送区域、投递要求、域名配置、日志保留、退订处理，以及将来迁移的代价。这里有些是工程问题，有些是业务责任，不应该被一个安装命令一起带过。
同样，“被频繁提及”与“最后被选中”也不一样。实验中的品牌可能出现在比较或排除过程中。营销部门若把提及量直接解释成需求增长，会把候选名单误当成订单。
更可靠的内部评价，是保存选型理由和被排除的替代方案，要求 Agent 标出哪些依据来自当前文档、哪些只是推断。最终验收也要检查服务是否符合约束，而不是只检查测试有没有变绿。
关键事实
- 总实验运行数为 16,893；首批分析为 5,292 个会话、51 个代码库。
- 使用合成项目与模型模拟交互，并非真实采购调查。
- Agent 选择会随语言、上下文和运行方式变化。
- 研究衡量推荐与选择行为，不衡量供应商实际收入或市场占有率。
OC 判断
这项实验最有价值的提醒，是选型权正在从一段明确的人类讨论，移动到一次看似普通的任务执行中。企业不必阻止 Agent 提出供应商，但应把“提出方案”“接入测试”“创建账户”“产生费用”拆成不同权限。代码可以自动生成，采购责任不能靠默认值悄悄转移。
为什么重要
- 对开发者：依赖增加之前，应能解释它为什么符合项目约束。
- 对服务商：文档的准确性、可执行性和失败说明，正在直接影响分发。
- 对企业：Agent 采用率上升时，软件资产管理需要覆盖自动引入的外部服务。
评论
围绕这篇文章补充信息、提出问题或分享观察。