10 月 7 日，Google 给编码 Agent 补上了一条更正式的文档管道：开发者可以在 gcloud 里查文档，把官方 Skill 装进编码助手，用 API Explorer 试请求，或从七种语言的客户端调用同一套服务。它试图解决的不是“模型会不会写代码”，而是模型动手前读到的 Google Cloud、Firebase、Android 文档是否仍然有效。
真正需要分清的是时间线。Developer Knowledge API 和配套 MCP 服务器并非 10 月才发布，它们在 2 月 4 日已经进入公开预览。10 月的变化是接入面扩大，让这套文档索引从一项单独 API 更容易进入终端、IDE 与后端程序。与此同时，生成式问答 AnswerQuery 的默认额度仍是每个项目每天 50 次。Google 把官方文档送到了 Agent 面前，却还没有给高频生产调用一条可以无条件依赖的生成问答通道。
10 月扩张的是接入面，不是 API 本身
2 月的首发已经提供两层能力：Developer Knowledge API 把公开开发文档转成可搜索、可完整读取的 Markdown，MCP 服务器再把搜索和读取工具暴露给 AI 助手。10 月 7 日的生态更新增加了 gcloud 命令、API Explorer、官方 Agent Skill，以及 C#、Go、Java、Node.js/TypeScript、PHP、Python、Ruby 七种客户端。
代码时间线进一步说明，这不是一夜之间完成的发布。Google 在 8 月 27 日已把 retrieving-developer-knowledge Skill 加入官方 google/skills 仓库；9 月 30 日又把版本升到 1.0.1，专门加入 AnswerQuery 触发 429 时改走文档搜索的规则。也就是说，10 月公告更像一次产品化收口：API、MCP、Skill、命令行和语言客户端开始共用同一套访问路径。
这改变了编码 Agent 获取资料的方式。过去常见做法是搜索网页、截取 HTML，再把结果塞进上下文；现在 Agent 可以按资源名取得 Markdown，并在请求中限定数据源、文档更新时间、URI 和内容长度。平台得到更稳定的输入格式，Google 也获得了定义收录范围、更新时间和调用额度的控制权。
搜索、取全文、生成答案是三笔不同的调用
这套 API 没有把所有需求塞进一个问答接口，而是拆成三步。
SearchDocumentChunks 先按关键词和语义返回相关片段。查询最长 500 个字符，默认最多返回 5 条结果，调用方可把上限调到 100；每个片段带有父文档资源名。Agent 随后用 GetDocument 取回整页 Markdown，或用 BatchGetDocuments 一次读取最多 20 篇文档。只有在需要把多处材料综合成直接回答时，才调用 AnswerQuery。
这个拆分决定了可核查性。搜索和取全文把“找到了什么”交给 Agent 自己处理；AnswerQuery 则由 Google 生成答案，并返回引用区间和文档片段引用。它能少占上下文、减少 Agent 自己拼接材料的工作，但回答质量仍取决于 Google 的语料、检索与生成过程。官方目前没有公布一套生产正确率评测，因此“来自官方文档”可以证明来源身份，不能直接证明回答完整或没有误解。
每天 50 次生成问答，迫使高频 Agent 保留检索路径
当前默认配额把两条路径的差异写得很清楚：AnswerQuery 每个项目每天 50 次；SearchDocumentChunks 与 AnswerQuery 合计每分钟 100 次；GetDocument 与批量读取合计每分钟 100 次。一次 AnswerQuery 会同时消耗一笔每日生成额度和一笔每分钟搜索额度。
这意味着 50 次不是整个知识 API 的日调用上限，而是平台代为生成答案的日上限。持续运行的编码 Agent 若把每个报错、每个 API 选择都交给 AnswerQuery，很快就会撞上日配额；搜索片段和读取全文则没有在该表中列出每日上限。Google 自己的 Skill 已把这种约束写进工作流：生成问答遇到 429 后，不回退到模型记忆，而是用 2—5 个关键词改走 search_documents。
对团队而言，更稳妥的架构因此不是“所有问题都问 Google”，而是把搜索与全文读取作为默认数据层，把生成问答留给真正需要综合解释的步骤。这样既保留原文，也把最稀缺的 50 次额度用在跨文档判断上。
官方语料仍有边界，更新目标也不是实时
Google 当前列出的语料覆盖 21 个域名，包括 Google Cloud、Firebase、Android、Chrome、Flutter、Go、TensorFlow、Gemini CLI 和 ADK 等。但覆盖并不等于全部收录：语料说明明确排除了多种语言的 Cloud 客户端参考页前缀，例如 Python、Go、Java 和 Node.js 的参考目录。
更新时间口径也发生了变化。2 月发布文称，公开预览期间文档会在更新后 24 小时内重新索引；10 月 20 日更新的语料说明把目标写成 48 小时内、也就是两个工作日内完成索引。这只能说明官方承诺口径变宽，不能据此断言实际延迟已经恶化；但对追踪刚发布 API、弃用项和安全修复的 Agent 来说，两天窗口足以要求它在高风险操作前再核对原始页面或发布说明。
Google 这次真正交付的，是一层面向 Agent 的官方文档基础设施，而不是消除错误的答案机器。它让开发团队可以用统一接口拿到结构化原文、更新时间和引用，也把语料选择、索引延迟与生成额度集中到一个平台。接下来最值得观察的不是又支持了多少 IDE，而是 Google 是否提高 AnswerQuery 配额、公布可复现的正确率评测，并让调用方看见每次答案背后的检索版本。
