判断用不用你的软件 Agent只需500个Token

现在几乎每个开发者都在用 AI Agent 干活。Cursor、Claude Code、Windsurf、Gemini CLI，各种 Coding Agent 已经深度嵌入了日常工作流。一个普遍的体验是，让 Agent 去调某些 API 或者集成某个服务，有些丝滑得像开了挂，有些则反复报错，甚至直接编造出一个根本不存在的接口。 大多数人把这归结为：「 模型还不够聪明 」。 但如果反过来想， 不是 Agent 不够聪明，而是有些产品天然对 Agent 友好，有些则天然对 Agent 充满敌意 。 这像极了十几年前的 SEO。你觉得自己的网站内容很好，但 Google 就是不收录，问题不在 Google 的算法，而在于你的网站没有做搜索引擎优化。 今天同样的事情正在 Agent 身上重演，只不过这一次，大多数产品甚至不知道自己正在被「审判」。 Google Cloud AI 工程总监 Addy Osmani 今年 4 月给这件事起了一个名字，叫 AEO（Agentic Engine Optimization），翻译过来就是： 「 Agent 引擎优化 」。 如果说 SEO 是为 Google 爬虫优化，AEO 就是为 AI Agent 优化。 这不是一个遥远的概念，而是一套已经可以落地的具体实践。在 Agent 正在成为软件产品最重要的「用户」的今天，到底什么样的设计，能让 Agent 更方便使用，可能决定了未来软件行业的真正走向。 01 Agent 怎么读文档？ 下面是一个用户非常日常的场景。 一个工程师打开 Cursor，让 Agent 帮他接入一个支付 API。Agent 发出了一个 HTTP 请求，拿到了文档页面，400 毫秒后做出了判断。但这份文档有将近 20 万个 Token，远远超出了 Agent 的上下文窗口容量。Agent 没有报错，没有提示，而是默默放弃了这份文档，转而根据自己训练数据里的记忆，编造了一个接入方案。 结果呢？用户拿到了一段看起来很合理的代码，跑起来却怎么都不通，花了两个小时 debug 才发现 Agent 给的是一个早就废弃的 endpoint。 而在这家支付公司的 Google Analytics 后台，这次访问只留下了一条记录。滚动深度为零，页面停留时间 400 毫秒，没有任何点击。在传统分析框架里，这就是一个「低质量访客」，一个跳出率 100% 的匿名 IP。没人知道这其实是一个 AI Agent，更没人知道这个 Agent 刚刚「审判」了他们的产品，然后判了死刑。 这就是 Agent 和人类读文档的根本差异。人类是「浏览」，Agent 是「审判」。 Osmani 在文章中引用了一篇针对九大主流 Coding Agent 的 HTTP 行为研究论文。数据很直观。人类读文档的方式是，打开首页，导航到某个板块，扫几个标题，读几段话，试一下代码示例，点两三个链接，花 4 到 8 分钟。整个过程中，你精心设计的渐进式引导、侧边栏导航、交互式教程都在发挥作用。 Agent 完全不是这样。它发出一个 GET 请求，拿到全文，在 400 毫秒内决定用还是不用。 人类的「用户旅程」对 Agent 来说，被压缩成了一次 HTTP 请求。 你花了几个月打磨的文档导航系统、面包屑路径、渐进式展示，在 Agent 眼里全是噪音，不但没用，还在浪费 Token。 这里有三个关键差异，理解了它们就理解了 AEO 的底层逻辑。 Agent 的「耐心」是可以精确量化的。 Osmani 给出了一个具体数字，你的页面前 500 个 Token 必须回答三个问题，这是什么、能干什么、怎么开始。如果答案埋在页面中间或者尾部，Agent 很可能在读到之前就已经放弃了。人类可以忍受冗长的前言，Agent 不会。 Agent 有严格的「胃口」上限。 Osmani 举了一个真实案例，思科安全防火墙管理中心的 REST API 快速入门指南，Token 数是 193,217，将近 72 万字符。这一份文档，就能吃掉甚至撑爆大多数 Agent 的整个上下文窗口。遇到这种文档，Agent 的反应要么是截断（丢掉关键信息），要么是跳过（当这份文档不存在），要么是回退到自身记忆（也就是自己编一个答案）。无论哪种，用户拿到的结果都是错的。 合理的 Token 预算大概是什么量级？Osmani 建议，快速入门指南低于 15,000 Token，单个 API 参考页低于 25,000 Token，概念性指南低于 20,000 Token。超过这个范围，就需要有明确的分块策略。 Agent 完全无视你的 UI 设计。 侧边栏、面包屑导航、页脚链接、交互式代码沙箱，这些出现在渲染后的 HTML 中的元素对 Agent 来说全是纯噪音。更要命的是，同样的内容，HTML 格式比 Markdown 格式要多消耗大量 Token，因为 div 标签、CSS 类名、ARIA 属性、内联样式全都被计入了。 Agent 读的是文本，不是界面。 理解了这三点，一个令人不安的结论就浮出水面了。 你的产品文档，很可能正在被 Agent 无声地「判死刑」，而你的 Analytics 后台只会告诉你，今天又多了几个跳出率 100% 的低质量访客。 不同 AI Agent 在服务器中留下的独特特征｜图片来源：addyosmani.com 02 如何「讨好」Agent？ 既然 Agent 选择工具的方式跟人完全不同，那怎么才能让产品被 Agent 优先选中？ Osmani 提出了一个六层框架。如果你有 SEO 经验，会发现这套东西在结构上惊人地相似，只不过优化对象从 Google 爬虫变成了 AI Agent。 第一层，检查 robots.txt。 这是 Agent 到访你网站时的第一站。很多公司在 2024 年和 2025 年出于对 AI 爬虫的恐惧，修改了 robots.txt，屏蔽了 Anthropic、OpenAI、Google 等 AI 公司的爬虫 User-Agent。当时的逻辑是防止内容被用于训练。 但这样做的副作用是， 你的文档从 Agent 的世界里彻底消失了。 Agent 在抓取页面之前会检查 robots.txt，如果发现自己被封锁，就直接跳过，不会报错，不会通知，不会在任何日志里留下痕迹。你的团队甚至不知道这件事发生过。 好消息是，这只需要十分钟的审计就能修复。检查一下你的 robots.txt 有没有误封 AI Agent 的 User-Agent，这大概是 ROI 最高的一项 AEO 工作。 一个结构完整的 llms.txt 文件是这样的｜图片来源：addyosmani.com 第二层，发布一份 llms.txt，Agent 版的 Sitemap。 SEO 时代你需要一个 sitemap.xml 告诉 Google 爬虫你的网站结构。AEO 时代，对应的东西叫 llms.txt。 这是一个放在域名根目录下的 Markdown 格式文件，里面列出你的文档有哪些页面、每页讲什么、大概多少 Token。Agent 读了这个文件就能精准定位到它需要的那一页，而不用盲目爬取你的整个网站。 一份好的 llms.txt 应该满足几