智能体体验 (AX) 简明教程

微信 ezpoda免费咨询：AI编程 | AI模型微调| AI私有化部署
AI工具导航 | Tripo 3D | Meshy AI | ElevenLabs | KlingAI | ArtSpace | Phot.AI | InVideo

在塑造产品时，开发者体验（DX）和用户体验（UX）是两个关键考量因素。如今，软件产品不再仅由人类使用，AI 智能体也成为其用户。这种转变需要一个全新的视角来设计你的产品：智能体体验（Agent Experience，简称 AX）。

"智能体体验（AX）"这一术语最早由 Netlify 的 CEO Mathias Biilmann 在 2025 年 1 月提出，定义为"AI 智能体作为产品或平台用户所获得的整体体验"。

我在 AI 领域从事开发者增长和开发者关系工作已有三年，亲眼见证了这一领域的规则正在被重写。我看到了从关注 SEO 到思考内容如何出现在 LLM 回复中的转变，从让文档仅对开发者友好到同时对 AI 智能体友好，以及我们开始围绕智能体易用性制定工程最佳实践。

在这篇博客中，我将目前遇到的所有技术整理成一个实用框架。需要注意的是，智能体体验这一概念仅有一年历史，业界目前正在迭代各种想法和技术，这些内容可能在几个月后就已经过时。

1、智能体体验 vs. 开发者体验 vs. 用户体验

智能体已经进入对话。到目前为止，软件产品在提升可用性时主要考虑两类目标受众：终端用户和开发者。现在，智能体也开始与软件产品进行交互。编码智能体可以使用不同的软件产品（包括数据库或框架）来构建软件；计算机使用智能体可以代表你与不同的软件产品（包括电子邮件或日历应用）进行交互。

用户体验（UX）关注终端用户如何成功使用你的产品完成任务。

开发者体验（DX）关注开发者如何成功使用你的产品进行构建。

智能体体验（AX）则不同：用户是 AI 智能体，它发现、评估并操作你的平台，通常无需人工介入。核心问题变成了：AI 智能体如何成功地使用或基于你的产品进行构建？ 这也意味着智能体可以同时被视为终端用户和开发者角色。

在设计 DX 或 UX 时，将目标受众的情感纳入考量是一个关键方面：他们是沮丧、困惑还是愉悦？对于 AI 智能体来说，这种情感曲线并不存在。相反，我们需要用失败模式（例如，模糊的错误响应、认证失败等）来替代情感，用可靠性曲线（"智能体在每个阶段成功的可能性有多大"）来替代情感曲线。

2、智能体旅程地图的阶段

智能体体验有许多不同的方面。其中包括回答诸如"如何让智能体选择你的软件产品？"或"如何让你的软件产品对智能体更易访问？"等问题。

这让我想起了 UX 和 DX 中的一个类似概念：在 UX 和 DX 中，目标受众的目标、问题和答案通常被映射到所谓的"用户旅程地图"或"开发者旅程地图"，代表用户或开发者在与你软件产品交互时所走的端到端路径。在智能体体验中，智能体的路径与终端用户或开发者的路径类似，只是人类角色变成了 AI 智能体。

在本节中，我将智能体从发现到成功所经历的路径映射到一个类似的"智能体旅程地图"上。你可以把它看作是智能体的采用漏斗。我总结的地图遵循五个阶段：发现（Discover）、评估（Evaluate）、入门（Onboard）、集成（Integrate）、推广（Advocate），如下图所示。

（注：在 DX 中，你通常在"集成"和"推广"之间有一个"扩展"阶段，我还没想好如何在 AX 情况下妥善处理这个阶段。如果你有改进建议，请联系我。）

3、发现（Discover）

"发现"阶段试图回答这个问题：智能体能否知道并找到你的平台？ 这个阶段关乎你的平台在 LLM 训练数据中的可见性，以及智能体调用网络搜索工具进行研究时在搜索结果中的可见性。

这是一个价值十亿美元的问题。我看到许多机构承诺为 LLM 提供可发现性和可见性解决方案，但我还没有看到任何证明它们有效的证据。

我看到的一个常见假设是增加你的产品在基础模型训练数据中的提及量。也有大量机构涌现，承诺通过为 Medium 或 dev.to 等流行平台生成用户生成内容（UCG）来增加 LLM 引用。

另一个方面是在 LLM 回复中被提及的 SEO 等价物，它有许多不同的名称，如 GEO（生成式引擎优化）、LLMO（LLM 优化）或 AEO（答案引擎优化）。许多 SEO 工具将 GEO/LLMO/AEO 纳入其产品，并承诺通过调整博客结构以提高可扫描性和分块、改进引用以证明权威性和相关性、以及提高可读性来获得更好的排名。然而，我还没有看到任何确认这些方法是否真的会影响 LLM 中的提及。

最后，考虑到 LLM 在使用网络搜索工具时如何制定搜索查询，网络上现在充斥着低质量的 SEO 文章，标题诸如"十大"、"2026年"、"X vs Y"等等，针对不同的工具。

4、评估（Evaluate）

"评估"阶段试图回答这个问题：智能体能否评估你的平台是否适合任务并满足其需求？ 我认为这与用户或开发者通过浏览你的网站或文档来评估你的产品类似。与 UX 和 DX 类似，你的网站应该有清晰的能力描述。AX 中新增的是考虑让网站对智能体更易访问。

2024 年 9 月，Answer.AI 提出了 llms.txt 文件格式作为帮助 LLM 使用网站信息的标准化方式。虽然业界一直在推广这一标准作为最佳实践，但根据我的经验，llms.txt 接收到的流量很少。Drupal 创始人 Dries Buytaert 最近的一篇博客文章也报告了同样的情况，指出"它为之设计的机器人并不寻找它。"

Dries 的同一篇博客还观察到，Markdown 文件比 llms.txt 被请求得更多。许多公司，如 Gemini API 文档 或 Elastic 文档，现在都有"查看 Markdown"选项。然而，Dries 的博客也显示，Markdown 文件确实被机器人查看，但不如常规 HTML 文件那么多。

5、入门（Onboard）

"入门"阶段试图回答这个问题：智能体能否轻松设置（无需人工干预）？ 这个阶段考虑的是关于智能体首次访问的一切，包括：

"智能体能多快开始？"：在开发者体验中，你会用"Hello World 时间"（或"首个令牌/首次 API 调用时间"等）这样的指标来衡量。在智能体体验中，除了常规文档外，拥有一个指导智能体如何成功使用 API 的智能体技能可能会有所帮助。

"智能体能否在没有人类的情况下开始？"：智能体是否拥有正确的权限，还是必须有人工介入？例如，当在你的平台上注册以获取 API 密钥时，也许认证步骤是智能体最容易失败的地方，因为 OAuth 流程是为人类（在环）设计的。另一个考虑因素是你的产品是否可以受益于沙盒环境。

6、集成（Integrate）

"集成"阶段试图回答这个问题：智能体能否可靠地操作你的平台？ 目前，我看到 AI 智能体使用软件产品的四种主要方式：

CLI 可以说是智能体使用的最简单接口，因为 LLM 在 CLI 使用方面接受了大量训练。

API 是智能体与软件产品交互的最成熟方式。AX 的关键是确保你的 API 有清晰、机器可读的规范（如 OpenAPI），以及错误响应给智能体足够的上下文来自我纠正，无需人工干预。当你的工具是新的且尚未出现在任何 LLM 的训练数据中时，这一点尤为重要。

HORNET.dev 采用的一种有趣方法是使用可验证的 API（包括配置、查询和部署），让智能体通过引导式反馈循环学习如何使用他们的检索引擎，类似于可以测试和自我纠正的代码。

模型上下文协议（MCP） 是连接 LLM 与外部工具和数据源的开放标准，由 Anthropic 在 2024 年提出，并于2025 年底捐赠给 Linux 基金会。许多公司现在管理着 MCP 服务器，通过 MCP 客户端向智能体直接暴露工具、最新文档和代码示例。尽管 MCP 承诺提供更清晰的接口，但最近的一篇博客文章认为 LLM 不需要专门的协议，因为它们可以自己通过 CLI 和一些文档搞清楚事情。

智能体技能 是可重用、自包含的指令，指导智能体如何成功完成你产品的特定任务。这在入门期间特别有价值，但设计良好的技能可以在整个使用过程中降低失败率。

此外，当我在 Elastic 与同事讨论为搜索智能体编写工具的最佳实践时，他们谈到"低门槛、高上限"：这是用户体验（UX）设计中的一个概念，描述那些易于上手（低门槛）同时又能支持高级、复杂用例（高上限）的产品。在搜索智能体的上下文中，这意味着：

低门槛：通过将任务抽象为专门工具，使智能体能够轻松、便捷地以较少的推理开销解决重复性任务。虽然这降低了常见任务的复杂性，但仅能使用专门工具将阻止智能体解决模糊的任务。

高上限：使智能体能够使用通用工具（如通用搜索工具或普通执行工具）解决复杂、模糊的任务，即使没有专门工具可用。然而，由于智能体必须自己想办法解决任务，可能需要更多迭代来解决问题。

7、推广（Advocate）

"推广"阶段试图回答这个问题：智能体会推广你的平台吗？ 例如，智能体如何决定为某个编码任务推荐哪些软件产品和开发者工具？智能体如何选择他们的首选技术栈？

最近的一份报告分析了 Claude Code 实际选择什么。报告显示，Claude Code 似乎偏向于特定的软件产品。该报告突出了了解 AI 智能体实际选择什么软件工具以及如何选择的竞争情报价值。

遗憾的是，我不知道 AI 智能体如何选择软件工具。我只能假设这可能与"发现"阶段中提到的技术有关：你的产品在训练数据中被提及的数量和情感，以及智能体在研究时组成的特定网络搜索查询中排名靠前的内容。此外，我可以想象你的产品在 GitHub 仓库的公共项目中的使用量也可能起到作用。

这个问题本质上回到了"发现"阶段，这使得智能体旅程成为一个循环而非漏斗。

8、总结

随着 AI 智能体在编码智能体等用例中确立自己的地位，在设计软件产品时考虑智能体体验变得更加重要。

正如我们所见，业界提出并试验了不同的标准，如 llms.txt 或 MCP，并已经开始抛弃它们。本博客中提到的所有方面都是从业者目前正在试验的技术的快照，可能仅仅几个月后就会过时。

无论你是否认为"智能体体验"只是另一个流行词，现实是智能体现在已经成为你产品的真实用户。如果你是一个开发 LLM 的大型 AI 实验室（LLM 是智能体的核心部分），智能体体验对你来说可能目前不是优先事项。然而，如果你有一个开发者工具或软件产品希望智能体使用，智能体体验应该成为优先事项。人们已经在讨论产品驱动增长（PLG）方法是否很快会被"智能体驱动增长"方法所取代。

原文链接: Agent Journey Map: Designing Software for AI Agents

汇智网翻译整理，转载请标明出处