The 4 Layers That Decide Which SDK a Coding Agent Uses
The 4 Layers That Decide Which SDK a Coding Agent Uses
决定编程智能体选择 SDK 的四个层级
When a developer asks a coding agent to “add payments to my app,” the agent does not simply choose the first SDK it remembers. It may draw on its training data, search the web, inspect machine-readable context, generate integration code, and run that code. At any one of those stages, an SDK can move to the top of the list—or get replaced by a competitor. 当开发者要求编程智能体“为我的应用添加支付功能”时，智能体并不会简单地选择它记忆中的第一个 SDK。它可能会调用训练数据、搜索网络、检查机器可读的上下文、生成集成代码并运行该代码。在这些阶段中的任何一个，某个 SDK 都可能跃升至列表首位，或者被竞争对手取代。
For developer-tool teams, this changes what “discoverability” means. Good documentation still matters, but documentation is only one part of the decision. Here is a practical model for understanding how coding agents such as Claude Code and Codex choose an SDK. 对于开发者工具团队来说，这改变了“可发现性”的定义。优秀的文档固然重要，但文档只是决策的一部分。以下是一个实用的模型，用于理解 Claude Code 和 Codex 等编程智能体如何选择 SDK。
The four-layer decision stack
四层决策堆栈
| Layer | What the agent does | What influences the choice |
|---|---|---|
| 1. Training data | Recalls tools and usage patterns from the base model | Historical docs, repositories, tutorials, package metadata |
| 2. Web search | Retrieves current information when memory is insufficient | Search visibility, crawlability, freshness, clear titles |
| 3. Context retrieval | Reads structured, task-specific context | llms.txt, MCP servers, installed skills, API descriptions |
| 4. Tool execution | Installs the package, writes code, and may run it | Installation reliability, API design, errors, response quality |
| 层级 | 智能体执行的操作 | 影响选择的因素 |
|---|---|---|
| 1. 训练数据 | 从基础模型中回忆工具和使用模式 | 历史文档、代码库、教程、包元数据 |
| 2. 网络搜索 | 在内存不足时检索最新信息 | 搜索可见性、可爬取性、时效性、清晰的标题 |
| 3. 上下文检索 | 读取结构化、特定任务的上下文 | llms.txt、MCP 服务器、已安装技能、API 描述 |
| 4. 工具执行 | 安装包、编写代码并可能运行它 | 安装可靠性、API 设计、错误信息、响应质量 |
Most teams have invested heavily in the first layer. The more controllable opportunities are often in layers two through four. 大多数团队在第一层投入了大量精力。而更具可控性的机会往往存在于第二到第四层。
Layer 1: Training data creates the shortlist
第一层：训练数据创建候选名单
Every coding agent starts with a base model. That model may have learned about an SDK from: Documentation pages, Public GitHub repositories, Stack Overflow answers, Tutorials and blog posts, or npm, PyPI, and other package metadata. 每个编程智能体都始于一个基础模型。该模型可能通过以下渠道了解 SDK：文档页面、公开的 GitHub 代码库、Stack Overflow 回答、教程和博客文章，或 npm、PyPI 等包元数据。
This creates a strong advantage for mature libraries. The agent has probably seen their package names, imports, initialization code, and common examples many times. But model knowledge has limits. It can be out of date, overrepresent popular libraries, miss a recently launched SDK, or reproduce a deprecated integration pattern. 这为成熟的库创造了巨大优势。智能体可能已经多次见过它们的包名、导入方式、初始化代码和常见示例。但模型知识是有局限的。它可能过时、过度偏向流行库、错过新发布的 SDK，或复现已弃用的集成模式。
For an SDK team, a useful test is to ask several models about the product without enabling web search. Check whether they know the correct package, initialization flow, and current API surface. That gives you a rough baseline for the first layer. Training data gets an SDK onto the shortlist. It does not guarantee the final choice. 对于 SDK 团队来说，一个有用的测试是在不开启网络搜索的情况下，向多个模型询问产品相关信息。检查它们是否知道正确的包名、初始化流程和当前的 API 接口。这能为你提供第一层的大致基准。训练数据能让 SDK 进入候选名单，但不能保证最终的选择。
Layer 2: Web search updates the shortlist
第二层：网络搜索更新候选名单
Coding agents search when the user explicitly asks them to find a tool, when the model is uncertain, or when the task depends on recent versions and comparisons. Vercel’s research into AEO (AI Engine Optimization) tracking for coding agents found that roughly 20% of the prompts it studied triggered web search. 当用户明确要求寻找工具、模型不确定，或任务依赖于最新版本和对比时，编程智能体会进行搜索。Vercel 对编程智能体 AEO（人工智能引擎优化）追踪的研究发现，其研究的提示词中约有 20% 触发了网络搜索。
This layer can fail for surprisingly mechanical reasons. Your docs may block relevant crawlers, rely entirely on client-side rendering, use vague page titles, or bury the working example beneath marketing copy. A page called “Node.js quickstart for Acme Payments” is easier to retrieve and interpret than one called “Getting started.” 这一层可能会因为一些令人惊讶的机械性原因而失效。你的文档可能屏蔽了相关爬虫、完全依赖客户端渲染、使用模糊的页面标题，或将可运行的示例埋没在营销文案之下。标题为“Acme Payments 的 Node.js 快速入门”的页面比标题为“入门指南”的页面更容易被检索和解读。
The practical checks are straightforward: Confirm that public docs are available without authentication; Inspect robots.txt for accidental crawler blocks; Make important pages readable without client-side JavaScript; Give quickstarts and comparisons specific, descriptive titles; Keep version-sensitive examples current. 实用的检查方法很简单：确认公开文档无需身份验证即可访问；检查 robots.txt 是否意外屏蔽了爬虫；确保重要页面在没有客户端 JavaScript 的情况下也能被读取；为快速入门和对比页面提供具体、描述性的标题；保持版本敏感的示例处于最新状态。
Layer 3: Structured context narrows the choice
第三层：结构化上下文缩小选择范围
Search gives the agent pages. Structured context gives it a compact explanation of what the SDK does and how to use it. 搜索为智能体提供页面，而结构化上下文则为它提供关于 SDK 功能及使用方法的简洁说明。
llms.txt
An llms.txt file can point an agent toward the most useful documentation and explain when the product is a good fit. A small, focused file is more helpful than a copy of the entire documentation site. The goal is not to manipulate the agent. It is to remove ambiguity: what the SDK is for, which package is official, and where the authoritative instructions live.
llms.txt 文件可以将智能体引导至最有用的文档，并解释产品适用的场景。一个精简、聚焦的文件比复制整个文档网站更有帮助。其目的不是操纵智能体，而是消除歧义：明确 SDK 的用途、哪个包是官方的，以及权威指南的位置。
MCP servers and agent skills An MCP (Model Context Protocol) server can expose tools and context directly to a compatible agent. An installed skill can provide preferred workflows, configuration patterns, and error-handling guidance. These mechanisms are especially valuable for newer products. A young SDK cannot retroactively appear in years of training data, but it can provide accurate context to an agent today. MCP（模型上下文协议）服务器可以直接向兼容的智能体公开工具和上下文。已安装的技能可以提供首选的工作流、配置模式和错误处理指南。这些机制对于较新的产品尤为重要。一个年轻的 SDK 无法追溯出现在多年的训练数据中，但它可以在今天为智能体提供准确的上下文。
Layer 4: Execution proves whether the recommendation works
第四层：执行验证推荐是否有效
Coding-agent recommendations are different from ordinary chatbot mentions. The recommendation is often embedded in an implementation. The agent may run the install, type-check the project, execute a request, and inspect the result. If the package name is wrong or the example fails, it has immediate evidence against the choice. 编程智能体的推荐与普通聊天机器人的提及不同。这种推荐通常嵌入在实现代码中。智能体可能会运行安装命令、对项目进行类型检查、执行请求并检查结果。如果包名错误或示例运行失败，它会立即获得否定该选择的证据。
Common failure modes include: 常见的失败模式包括：
- The package cannot be installed: Look for an alternative package. 包无法安装： 寻找替代包。
- The documented import does not exist: Search for another example or switch tools. 文档中的导入方式不存在： 搜索其他示例或更换工具。
- Authentication fails without a useful message: (The agent may struggle to debug the integration). 身份验证失败且没有有用的错误信息：（智能体可能难以调试该集成）。