AI Agent 开始审判产品文档
Google Cloud AI 工程总监 Addy Osmani 于 2024 年 4 月正式提出 Agent 引擎优化（AEO），一套为 AI Agent 设计的文档优化实践标准。这并非未来概念，而是当前开发者工作流中正在发生的现实：当工程师使用 Cursor、Claude Code、Windsurf、Gemini CLI 等 Coding Agent 时，产品能否被 Agent 快速识别与调用，直接决定其能否进入开发者的工具链。
AEO 的核心观察来自一个隐蔽却关键的数据现象：大量 AI Agent 访问在传统 Analytics 后台中被归类为“跳出率 100% 的低质量访客”，零点击、零停留，实际却是 Agent 对产品文档做出了无声的“判死刑”决定——仅因前 500 Token 未能回答“这是什么、能干什么、怎么开始”三个问题，Agent 即放弃并转向其他工具。
Agent 读文档的三大反直觉差异
与人类开发者不同，AI Agent 的文档消费模式存在系统性差异：
- 耐心量化：Agent 在 400 毫秒内完成判断，需在前 500 Token 内获取核心答案，无法容忍冗长铺垫
- Token 预算严格：快速入门指南应低于 15,000 Token，单个 API 参考页低于 25,000 Token，概念性指南低于 20,000 Token；Cisco 防火墙文档达 193,217 Token，已逼近甚至超出 Agent 上下文窗口上限
- 无视 UI 噪音：侧边栏、面包屑、页脚、交互沙箱等渲染后元素对 Agent 无意义，HTML 格式因附带大量标签而显著增加 Token 消耗
值得注意的是，多数产品甚至不知道自己已被 Agent 流量访问。研究显示，人类读文档平均耗时 4-8 分钟，涉及导航、跳转、试代码等互动；而 Agent 仅通过一次 GET 请求完成评估，整个“用户旅程”被压缩到一次 HTTP 响应周期内。
六层 AEO 实践框架
Osmani 提出可落地的六层优化路径，优先级与工程成本递增：
| 层级 | 优化动作 | 工时估算 | 关键作用 |
|---|---|---|---|
| 第一层 | 审计 robots.txt | 10 分钟 | 防止误封Anthropic/OpenAI/Google等AI爬虫，避免Agent直接跳过 |
| 第二层 | 发布 llms.txt 索引文件 | 数小时 | Markdown 格式文档目录，标注各页功能与 Token 数，控制在 5,000 Token 以内 |
| 第三层 | 编写 skill.md 能力声明 | 适中 | 列出产品能力、必要参数、速率限制等，供 Agent 快速判断适用性 |
| 第四层 | 提供可访问的 .md 原文 | 简单 | HTML 包含大量非内容标签，Markdown 为 Agent 提供“去包装”纯文本 |
| 第五层 | 暴露页面 Token 元数据 | 简单 | 通过 meta tag 或响应头声明 Token 估算值，助 Agent 提前决策 |
| 第六层 | 添加 Copy for AI 按钮 | 低 | 一键复制干净 Markdown，减少开发者手动清理导航噪音的成本 |
完成前几项（robots.txt 审计、llms.txt、Token 标注）通常一个周末即可完成，但能显著提升 Agent 呼叫成功率。
适合谁用？
- 适用对象：SaaS 服务商、API 提供方、SDK 开发者——任何依赖开发者生态的产品；技术文档团队希望提升 Agent 可发现性；中等规模团队具备基本工程能力即可落地前三层
- 建议再等等：纯本地化、无网络调用场景的工具；文档已使用静态 Markdown 构建且无需 JS 渲染的项目可暂缓；小型个人项目若暂无 Agent 集成需求可延后关注
写在最后
AEO 与传统 SEO 在结构上高度同构，若 SEO 是为 Google 爬虫服务，AEO 则是为 AI Agent 的冷酷判决机制服务。有意思的是，Osmani 指出：AEO 的优化方向与人类优质文档设计高度重合——答案前置、单页聚焦、结构清晰、去除非必要噪音。不同仅在于容错：人类可跳跃阅读反复回溯，Agent 则一次判断定生死。这轮悄然发生的变更，正以最诚实的方式筛选真正以开发者为中心的产品。