夜雨聆风在塑造产品的过程中，开发者体验和用户体验是两个关键考量因素。如今，软件产品的使用者不再仅仅是人类，还有 AI 智能体。这种转变要求我们用全新的视角来设计产品：智能体体验。
"智能体体验（AX）"这一概念最早由 Netlify 首席执行官 Mathias Biilmann 于 2025 年 1 月提出，被定义为"AI 智能体作为产品或平台用户时所获得的整体体验"。
过去三年，我一直在 AI 领域从事开发者增长和开发者关系方面的工作，亲眼见证了游戏规则被重写。我看到了从 SEO 思维到 LLM 响应提及优化的转变，从只考虑开发者阅读体验的文档到同时兼顾 AI 智能体可读性的转变，以及围绕智能体易用性的工程最佳实践的逐步形成。
在这篇博客中，我把自己目前收集到的所有方法整合成了一套实用的框架。需要注意的是，智能体体验的概念诞生才一年，整个行业目前仍在不断迭代各种理念和技术，有些内容可能在几个月后就会过时。
智能体体验（AX）vs 开发者体验（DX）vs 用户体验（UX）
智能体已经加入了对话。在此之前，软件产品在提升可用性时通常只考虑两类目标用户：最终用户和开发者。现在，智能体也开始与软件产品进行交互了。编码智能体可以使用不同的软件产品（如数据库或框架）来构建软件；计算机操作智能体可以代表用户与各种软件产品（如邮件或日历应用）进行交互。
用户体验（UX） 关注最终用户如何成功完成产品上的任务。开发者体验（DX） 则聚焦于开发者如何成功使用产品进行开发。
智能体体验（AX） 则有所不同：这里的"用户"是一个 AI 智能体，它能够自主发现、评估和操作系统，通常不需要人类参与其中。核心问题变成了：智能体如何成功地使用或基于你的产品进行开发？ 这也意味着智能体可以同时被视为最终用户和开发者角色。
在设计 DX 或 UX 时，时刻关注目标用户的情绪是关键：他们是否感到沮丧、困惑，还是愉悦？对于 AI 智能体，这种"情感曲线"并不存在。我们需要用故障模式（如模糊的错误响应、认证失败等）来替代情绪，用可靠性曲线（"智能体在每个阶段成功的可能性"）来替代情感曲线。
智能体旅程图的各个阶段
智能体体验涉及很多不同的方面。有些问题需要回答，比如"如何让智能体选择你的软件产品？"或"如何让你的软件产品便于智能体访问？"
这让我想起了 UX 和 DX 中的一个类似概念：在用户体验和开发者体验中，通常会用"用户旅程图"或"开发者旅程图"来映射目标用户的目标、问题和答案，这些图表示用户或开发者在使用软件产品时从起点到终点的完整路径。在智能体体验中，智能体的路径与最终用户或开发者的路径类似，只是现在的人类角色变成了 AI 智能体。
在这一部分，我绘制了智能体从发现到成功使用产品这条路径的"智能体旅程图"。你可以把它想象成智能体的采用漏斗图。我最终确定的旅程图包含五个阶段：发现（Discover）、评估（Evaluate）、入门（Onboard）、集成（Integrate）、推广（Advocate），如下图所示。
（注：在开发者体验中，"扩展（Scale）"阶段通常位于"集成"和"推广"之间，但在智能体体验的情况下，我还没想清楚如何妥善处理这个阶段。如果你有改进建议，欢迎联系我。）
发现（Discover）
"发现"阶段要回答的问题是："智能体能发现并找到你的平台吗？" 这个阶段关注的是你的平台在 LLM 训练数据和搜索结果中的可见性。
这是一个价值十亿美元的问题。我见过很多代理商声称能提供 LLM 可发现性和可见性的解决方案，但到目前为止，我还没看到任何实际效果的证明。
一个常见的假设是增加产品在基础模型训练数据中被提及的频率。还有很多代理商承诺通过在 Medium 或 dev.to 等热门平台上生成用户生成内容（UGC）来提高 LLM 引用率。
另一个方面是对标 LLM 响应提及的 SEO 优化，这个领域有多种名称，比如 GEO（生成式引擎优化）、LLMO（LLM 优化）或 AEO（答案引擎优化）。许多 SEO 工具已经把 GEO/LLMO/AEO 功能整合到产品中，承诺通过调整博客结构以提高可扫读性和分块、优化引用以增强权威性和相关性、以及提升易读性来获得更好的排名。不过，我还没有看到任何确认这些方法是否真的能影响 LLM 中的提及。
最后，考虑到 LLM 在使用网络搜索工具时如何构建查询语句，现在网上充斥着大量低质量的 SEO 文章，标题诸如"十大XX"、"2026 年如何XX"、"X vs Y 对比"等等。
评估（Evaluate）
"评估"阶段要回答的问题是："智能体能判断你的平台是否适合任务并满足需求吗？" 我认为这类似于用户或开发者通过浏览网站或文档来评估产品的方式。与用户体验和开发者体验一样，你的网站应该有清晰的功能描述。智能体体验的新挑战在于：如何让网站更易于智能体访问。
2024 年 9 月，Answer.AI 提出了 llms.txt 文件格式，作为向 LLM 提供网站使用信息的标准化方式。虽然业界一直在推广这个标准作为最佳实践，但根据我的经验，llms.txt 的访问量很低。Drupal 创始人 Dries Buytaest 最近的博文也报告了同样的情况，他说"设计它时所针对的爬虫根本不会去找它。"
同一篇博文中，Dries 还观察到 Markdown 文件的请求量比 llms.txt 更高。很多公司现在都提供"查看 Markdown"选项，比如 Gemini API 文档和 Elastic 文档。不过，Dries 的博文也指出，Markdown 文件虽然被爬虫访问，但频率不如常规 HTML 文件高。
入门（Onboard）
"入门"阶段要回答的问题是："智能体能轻松完成初始设置吗（无需人工干预）？" 这个阶段涉及智能体首次访问的各个方面，包括：
• "智能体能多快开始使用？"：在开发者体验中，通常用"首次运行时间"（或"首次获取 token/首次 API 调用等所需时间"）来衡量。在智能体体验中，除了常规文档外，拥有一个能指导智能体成功使用 API 的智能体技能（Agent Skill） 会非常有帮助。 • "智能体能自主开始使用吗？"：智能体是否拥有正确的权限，还是必须有人参与？例如，在平台上注册以获取 API 密钥时，认证步骤可能是智能体最容易失败的地方，因为 OAuth 流程是为人类（在环）设计的。另一个需要考虑的是，你的服务是否适合提供沙盒环境。
集成（Integrate）
"集成"阶段要回答的问题是："智能体能可靠地操作系统吗？" 目前，我观察到 AI 智能体使用软件产品主要有四种方式：
命令行工具（CLI） 可以说是智能体最容易使用的接口，因为 LLM 在 CLI 使用方面接受过大量训练。
API 是智能体与软件产品交互最成熟的方式。智能体体验的关键在于确保 API 具有清晰的、机器可读的规范（如 OpenAPI），以及能够为智能体提供足够上下文进行自我修正的错误响应。这一点在工具较新、尚未进入任何 LLM 训练数据时尤为重要。
HORNET.dev 采用了一种有趣的方法：使用可验证的 API（包括配置、查询和部署），让智能体通过引导式反馈循环来学习如何使用他们的检索引擎，类似于可以测试和自我修正的代码。
模型上下文协议（MCP） 是 Anthropic 于 2024 年提出的一个开放标准，用于将 LLM 与外部工具和数据源连接起来，2025 年底已捐赠给 Linux 基金会。许多公司现在都运营着 MCP 服务器，通过 MCP 客户端直接向智能体暴露工具、最新文档和代码示例。尽管 MCP 承诺了更简洁的接口，但最近的一篇博文认为 LLM 不需要专门的协议，因为它们可以凭借 CLI 和一些文档自行解决问题。
智能体技能（Agent Skills） 是可复用的、自包含的指令，用于指导智能体如何成功完成产品的特定任务。这在入门阶段特别有价值，设计良好的技能可以降低整个使用过程中的失败率。
此外，当我在 Elastic 与同事讨论搜索智能体的工具编写最佳实践时，他们提到了"低门槛、高天花板"的概念：这是用户体验设计中一个由来已久的理念，描述的是易于上手（低门槛）同时又能支持高级复杂用例（高天花板）的产品。在搜索智能体的语境下，这意味着：
• 低门槛： 通过将任务抽象为专用工具，让智能体以较低的推理开销轻松解决重复性任务。虽然这降低常见任务的复杂度，但仅使用专用工具也会阻碍智能体处理模糊任务。 • 高天花板： 使智能体能够使用通用工具（如通用搜索工具或原始执行工具）来解决复杂、模糊的任务，即使没有专用工具可用。然而，由于智能体需要自己摸索解决方案，可能需要更多迭代才能解决问题。
推广（Advocate）
"推广"阶段要回答的问题是："智能体会为你的平台代言吗？" 例如，智能体如何决定为某个编码任务推荐哪些软件产品和开发者工具？智能体如何选择自己的首选技术栈？
最近的一份报告分析了 Claude Code 实际选择了什么。报告显示，Claude Code 似乎会偏好某些特定的软件产品。这份报告凸显了理解 AI 智能体实际如何选择软件工具的竞争情报价值。
遗憾的是，我并不清楚 AI 智能体是如何选择软件工具的。我只能推测，这可能与"发现"阶段的一些技术有关：产品在训练数据中被提及的数量和情感倾向，以及在智能体进行研究时发出的特定网络搜索查询中排名靠前的内容。另外，我猜测你的产品在 GitHub 仓库中的公开项目里的使用量可能也起到一定作用。
这个问题本质上会回到"发现"阶段，这使得智能体旅程成为一个循环而非漏斗。
总结
随着 AI 智能体在编码智能体等用例中站稳脚跟，在设计软件产品时考虑智能体体验变得越来越重要。
正如我们所见，业界提出并试验了不同的标准，如 llms.txt 或 MCP，但已经开始逐步淘汰。本文中提到的所有方面都是从业者目前正在实践的技术快照，可能在几个月内就会过时。
无论你认为"智能体体验"是否只是另一个 buzzword，事实是智能体现在已经成为你产品的真实用户。如果你是一家开发 LLM（这是智能体的核心部分）的大型 AI 实验室，智能体体验可能暂时不是你的优先事项。但是，如果你有希望智能体使用的开发者工具或软件产品，智能体体验应该成为你的优先事项。人们已经在讨论产品导向增长（PLG）方法是否很快会被"智能体导向增长"方法所取代。
原文发布于 https://leoniemonigatti.com。
