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

当AI Agent开始替代人类执行大量软件操作时，一个新的问题浮出水面：Agent会如何“审判”你的产品？Google Cloud AI工程总监Addy Osmani提出了AEO（Agentic Engine Optimization，Agent引擎优化）的概念，类比搜索引擎时代的SEO，为这个命题提供了系统性的框架。在Agent深度嵌入开发工作流的当下，理解Agent选择软件的底层逻辑，正在成为产品设计者不可回避的新课题。

人类使用文档的方式是渐进式探索：打开首页、导航到特定板块、扫读标题、试运行代码示例，整个过程耗时4到8分钟。而Agent完全不同——它发送一个HTTP请求获取完整内容，在400毫秒内决定用还是不用。这意味着人类精心设计的渐进式引导、侧边栏导航、交互式教程，在Agent眼中全部变成了需要过滤的噪音。更关键的是，Agent的上下文窗口容量是有限的，当文档超过一定规模，它不会报错，而是默默放弃，转而用训练数据中的记忆“编造”一个答案。你的Analytics后台只会记录一个跳出率100%的匿名访问，而不知道这其实是一次致命的“审判”。

Agent读文档的本质是“审判”而非“浏览”

Osmani给出了AEO的核心判断标准：页面前500个Token必须回答三个问题——这是什么、能干什么、怎么开始。如果答案被埋在页面深处，Agent很可能在找到之前就已经放弃。这个容错空间极其有限，与人类用户可以忍受冗长前言、多次翻页形成鲜明对比。以思科安全防火墙管理中心的REST API快速入门指南为例，其Token数高达193,217，远超大多数Agent的上下文窗口承载能力。Osmani建议的合理量级是：快速入门指南低于15,000 Token，单个API参考页低于25,000 Token，概念性指南低于20,000 Token。超出这个范围，就需要明确的分块策略。

500 Token：第一道生死线的判定逻辑

Osmani提出的AEO六层框架提供了系统性的优化路径。第一层，检查robots.txt——许多企业在2024至2025年间出于对AI爬虫的戒备，误封了Anthropic、OpenAI、Google等公司的User-Agent，导致文档在Agent世界彻底消失，而这只需要十分钟审计即可修复。第二层，发布llms.txt——这是Agent版的Sitemap，放在域名根目录的Markdown文件，列出文档页面清单、每个页面的描述和Token数，让Agent能够精准定位而不必盲目爬取整个站点。第三层，写skill.md——这是产品的“自荐信”，在几百字内声明核心能力、必要输入、限制条件和关键文档链接，让Agent在几秒内判断工具是否适合当前任务。第四层，确保Markdown版本可被直接访问——HTML格式包含大量div标签、CSS类名、ARIA属性等噪音，而Markdown是去掉了所有包装的纯内容。第五层，将Token数作为元数据暴露——在meta tag或HTTP响应头中标注页面Token数，让Agent能够提前判断是否需要只取相关段落。第六层，添加Copy for AI按钮——开发者从渲染后的网页复制内容时，会带入大量导航、页脚噪音，一个干净的Markdown一键复制功能能大幅提升上下文质量，Anthropic和Cloudflare的文档站已率先实现。

六层框架：从检查robots.txt到Copy for AI按钮

AEO最容易产生的误解是它以牺牲人类体验为代价换取机器友好。但事实上，AEO与优秀的人类文档设计高度重合：把答案放在页面最前面而非埋在三段背景介绍之后、控制单页篇幅让每个页面聚焦一件事、用清晰层级结构组织内容而非长篇堆砌。唯一的区别在于容错度：人类可以忍受不完美的文档，Agent不会。Osmani在检查服务器日志后发现，大量Agent流量正以“低质量访客”的形式存在——滚动深度为零、页面停留时间极短、没有任何点击。这些沉默的访客正在决定产品在整个Agent生态中的位置，而大多数公司对此毫无感知。投资人在使用多个Agent开发一个包含448个任务的应用时发现，Agent会自动倾向于API设计优秀、文档结构清晰的工具，这个选择过程完全绕过了传统的品牌认知和销售关系。对于真正优秀的产品，这是利好；对于靠惯性、靠品牌光环活着的产品，是一场无声的清算。

过去十年，产品团队大量投入在UI/UX设计上。而接下来，同等甚至更大的投入可能要转向API设计、文档结构和Agent可达性。Agent时代的产品评价标准更加客观——它不会因为品牌知名度高就多给你几秒钟耐心，不会因为销售关系就优先选择你。它只看一件事：能不能在最短时间内让它理解你是谁、你能干什么。这大概是近十年来，对“什么是好产品”最安静、也最深刻的一次重新定义。