记忆中的代码示例会让客户更新显得很容易。在这个示例中，代理凭记忆写出一次调用。方法名看着合理，字段也熟悉，测试材料接受请求。然而真实供应商的契约在示例写成后已经改变。
失败发生在调用之前：本该查阅当前来源时，代理用了记忆。
关于代理与变化的 API 的讨论主张检索能回答任务的精确片段。对集成尤其有用，因为 API 定义是变化的契约，而不是背景读物。
看似合理的调用不是契约
大模型从不同时期的代码、文档和讨论中学习。那些示例在形式与惯用写法上有用，却不能证明供应商今天、在应用使用的版本和连接的账户中接受什么。
Shopify 的API 版本指南说明每季度发布以及版本对应的变更记录。开发者可以选用受支持的版本，再阅读升级相关的变化。请求里指定的版本，比模型对“Shopify API”的记忆重要得多。
Brevo 的创建联系人参考文档还有另一层：自定义属性必须存在于账户中，类型不匹配的值可能被忽略。通用 API 模式无法告诉代理这个账户创建了哪些属性，需要限定账户范围的查询或验证。
当前契约至少包含两部分：供应商发布的操作，以及账户配置的对象。任务依赖两者时，代理就需要两者。
检索出的答案要带上版本和账户范围。某个 API 版本正确的操作描述，在另一个版本可能错误；一个 Brevo 账户中的属性名，在另一个账户可能不存在。测试材料应包含选定版本和账户标识符，其中任一未知就失败。助手不应从附近的示例猜测来消除歧义。
只检索使用中的小部分
糟糕的修法是把一万项操作定义贴进代理的每一轮。文本更多、容易混淆的旧片段更多，留给实际任务的空间更少。应该询问移动这条记录的操作，以及决定它能否成功的限制。
对联系人更新，答案材料可能是操作路径、允许的字段、必需的标识符、属性类型规则和当前 API 版本。把这些片段及来源 URL 给代理，其余内容留待别的问题。
Tajo 的Brevo API 指南可以帮助读者了解供应商。本地生产代码使用精确调用前，应以官方参考文档为准。读者需要在供应商变更时可以重新打开的来源。
仓库可以让过程可重复。记录锁定的版本、保存的规格文件哈希和核对日期。哈希改变并不证明有破坏性变化，但会告诉维护者该比较什么。模型可以总结相关差异；测试仍要运行可工作同步所依赖的操作。
把生成请求当作待验证的假设，做三项检查。第一，它是否符合官方操作和锁定版本？第二，连接账户是否有请求所假定的对象？第三，范围有限的执行是否留下预期状态？模式检查、账户查询、写后读回分别回答。任一项都不能代替另外两项。
- 供应商操作 版本 · 字段
公开 API 接受什么
- 连接账户 属性 · 类型
这个账户里有什么
- 有限执行 写入 · 读回
实际改变了什么
不要把检索当作执行证明
合理的质疑是：“官方文档可能落后于真实服务。”确实可能。阅读是必要的，但不充分。契约测试应通过相同的客户端代码发送范围有限的请求，检查响应和目标系统状态。如果服务行为不同，记录差异并限定受影响操作。
契约含糊时，代理也应停止。把猜测的字段映射应用到许多联系人，比审核一次字段定义更昂贵。多业务工具集成指南从明确各数据对象的权威来源入手；保持 API 信息新鲜，就是把同样原则用于传输对象的操作。
代价是维护当前参考资料和测试。否则就要在同步触及的每条记录上，为同一个过时前提付费。
模型可以记住想法，但必须阅读契约，并检查即将改变的账户。
这并不要求每次交互都慢下来。把范围小且有版本的片段和账户模式缓存到已知失效事件或选定刷新时间。把来源与检索日期跟决策一起保存。这样只有契约可能改变时才为重新读取付费，而不是对已经获批的同步逐行付费。
常见问题
AI 助手为什么会答错 API？
训练资料和缓存示例可能早于供应商当前模式、版本或账户专属配置。具体操作必须查阅当前官方契约。
锁定 API 版本能解决问题吗？
它能让契约稳定一段时间，但版本会老化，账户配置也重要。跟踪受支持版本，升级时阅读变更记录。
代理应该检索什么？
范围很窄的操作定义、必需字段和相关版本说明，并带上来源链接与日期。不要为了一个调用加载供应商的完整目录。