ice 许多开发者用 Cursor、Claude Code 等 AI Agent 调 API 时，会发现有的服务接入很顺利，有的却反复报错，甚至 Agent 会凭空造出不存在的接口。常见解释是模型不够聪明，但另一种可能是：有些产品天然对 Agent 友好，有些则让 Agent 难以理解。Google Cloud AI 工程总监 Addy Osmani 今年 4 月把这种现象称作 AEO（Agentic Engine Optimization），即“Agent 引擎优化”。如果说 SEO 是为搜索引擎爬虫优化，AEO 就是为 AI Agent 优化。
一篇关于九大主流 Coding Agent HTTP 行为的研究显示，Agent 读文档和人类完全不同。人类会逐页浏览、点击链接、停留几分钟，但 Agent 通常只发一次 GET 请求，然后在 400 毫秒内决定是否采用这份文档。比如一个工程师让 Cursor 接入支付 API，文档有近 20 万个 Token，超出上下文窗口。Agent 没有提示错误，而是默默放弃文档，根据自身训练记忆生成了一段连接已废弃 endpoint 的代码，用户花两个小时调试才发现问题。从网站分析后台看，这次访问只是 100% 跳出的匿名 IP，没人意识到那是一个给产品“判死刑”的 Agent。
500 个 Token 内必须回答三个问题
Osmani 指出，Agent 的耐心可以精确量化：页面最前面的 500 个 Token 里，必须说清楚产品是什么、能做什么、怎么开始。如果答案藏在页面中间或末尾，Agent 很可能在读到之前就放弃。另外，Agent 的上下文窗口有上限。思科安全防火墙管理中心的一份 REST API 快速入门指南有 193,217 个 Token，将近 72 万字符，足以撑爆多数 Agent。面对这样的文档，Agent 要么截断丢掉关键信息，要么跳过文档，要么回退到自身记忆中的过时信息。软件产品需要为 Agent 重写文档，让关键内容出现在开头，并且足够精简。
