研究主题页 · AX
AX 智能体体验AI 智能体用你的产品，
能把事情办完吗？
AX（Agent Experience，智能体体验）关注 AI 智能体使用产品时，能否理解操作、取得适当权限、完成任务，并把可验证的结果交回用户。
从产品入口到错误恢复，这里整理四个检查点与任务闭环，链接设计方法和平台案例。
01
AX 阅读指南
从一笔完整任务，延伸到交易准备、访问边界与网站规则。
- 营销成长
AX 是什么？从订房看智能体体验
用一笔订房，检查界面操作、授权、结果验证与出错后的处理。
- 营销成长
你的网站准备好让 AI 智能体下单了吗？
对照商品数据、交易条件与结账流程，整理代理购物的准备工作。
- 新闻快讯
摩根大通开始封锁 AI 智能体？
从平台限制登录与代操的案例，理解智能体访问的边界。
- 营销成长
robots.txt 该不该挡 AI？
分清训练、搜索与用户触发的访问，再判断网站规则。
延伸阅读：从可供性理解智能体能否操作产品。
02
UX、DX 与 AX 的差别
UX 设计给看画面操作的人，DX 设计给读文档接 API 的开发者，AX 设计给替人办事的 AI 智能体。智能体拿到一句目标就开始自己找路，产品原本藏在界面里的假设，会一个一个冒出来。
UXUser Experience
以用户为对象
人自己看画面、判断下一步
- 用户选日期、挑时段
- 操作界面看价格、确认条件
- 任务结果完成预订
画面要清楚。人卡住时，还能自己看懂、回头修正。
DXDeveloper Experience
以开发者为对象
工程师先读文档，再把能力接进系统
- 开发者读文档、取得密钥
- API／SDK查空位、建立预订
- 系统整合上线后维护
文档可以长。工程师会先理解规格，再写程序。
AXAgent Experience
以 AI 智能体为对象
智能体接下目标，自己决定怎么完成
- 用户目标今晚 19:00，两位
- 智能体找入口、选工具、填参数
- 人机合作必要时确认，拿到预订记录
入口、工具、参数与错误回复都要能直接操作。卡住时，还要有人能接手。
03
AX 的四个检查点
AX 分成访问、上下文、工具与编排四个领域，出自 Biilmann 2026 年 1 月的〈One Year of AX〉。本页把它们整理成访问、理解、执行、交接四个检查点。它们不必照顺序做，重点是找出智能体走到你的产品时，可能在哪里停下来。
- 01
访问 Access
它能不能开始，什么时候该停？
登录、权限、付款与送出前的确认，都可能把任务切回人手上。高风险动作本来就该停，但要停得清楚：让智能体知道缺什么，也让人知道自己正在同意什么。
- 02
理解 Context
它知不知道这是什么、下一步能做什么？
文档、工具描述、错误消息与返回格式都会影响判断。与其堆品牌形容词，不如把产品能力、限制与操作方式写成智能体可直接使用的句子。MCP、Skills 或返回 Markdown，都是交接上下文的方式。
- 03
执行 Tools
它有没有动作可以调用？
把查空位、保留座位与建立预订拆成不同工具，写清楚输入、输出与失败状态。工具准备好之后，模型会不会选它，才是 TSO 要处理的事。
- 04
交接 Orchestration
任务中断时，谁接手、怎么接？
产品要能把任务交给智能体，也要在需要人判断时把上下文交回来。例如在后台按下一个键让智能体接手，但遇到例外时，人能看到它做到哪里、为什么停。只丢一句“请洽客服”，等于让整段任务从头再来。
设计时看的是产品缺什么；实际跑任务时，看的是它卡在哪一步。下一节把同一笔预订拆成三种结局，会比较容易看出两者的差别。
04
智能体预订失败的三种情况
把“今晚 19:00，两位”交给智能体，不一定会预订成功。它可能在登录时停下，可能停在等人确认，也可能收到成功消息，却无法证明预订真的存在。
用户问“今晚 19:00，帮两位找一家餐厅并预订。”
智能体需要登录才能继续
- 理解需求19:00，两位
- 进入预订需要登录
- 继续执行等待用户
交接：请用户先完成登录
怎么检查先确认智能体能不能完成登录。需要验证码、短信或既有账号时，把步骤交回人；人完成后，流程要能从原本的地方接下去，而不是重新开始。
交给用户确认时没有带上预订条件
- 查询空位有合适座位
- 人类确认餐厅与条件
- 送出预订等待确认
决定交给人，上下文一起交接。
怎么检查把餐厅、时段、人数与取消条件一起交给人确认。只问“要不要订？”不够，人要知道自己正在同意哪一笔交易。
工具回复成功但没有可核对的预订记录
- 餐厅、日期、时间与人数
- 可核对的预订记录
- 后续修改或取消方式
怎么检查把工具回复整理成可核对的记录：餐厅、时间、人数、预订编号与修改方式。智能体回报完成之前，状态要先对得上。
产品端要准备什么？看四个环节 ↓
05
任务闭环
任务闭环指一笔任务从开始到确认完成的完整过程。以预订为例，会经过四个环节：可发现、可执行、可验证、可恢复。任何一环断掉，智能体都得停下来，或把问题丢回给人。选一个环节，看产品要准备什么、事后能观察什么。
Discoverable
让智能体知道工具能做什么
操作线索（Signifier）・语义明确性・选用倾向（Propensity）
如何设计
把查空位与建立预订拆成两个工具，例如 search_tables 与 reserve_table。名称说动作，描述说能力，参数说格式，还要写明什么情况下不能调用。
查今晚空位 → 选时段 → 建立预订
观察什么
- 功能识别率
- 正确工具选择率
- 无效探索步数
Executable
依步骤分开授权并由人确认送出
可操作性（Affordance）・最小权限・人机协同
观察什么
- 授权后操作成功率
- 权限阻碍率
- 单次任务成本
Verifiable
用可核对的状态确认成功
状态反馈（State Feedback）・结果导向验证
观察什么
- 结果验证准确率
- 误判成功率（False Positive）
- 误判失败率（False Negative）
Recoverable
中断后让任务可以接续
容错设计・幂等性（Idempotency）・安全停止
观察什么
- 错误恢复率
- 重复预订率
- 高风险异常安全停止率
挑一个最常发生的任务，让智能体从头跑到尾，只记录第一个中断点：它找不到入口、看不懂工具、没有权限，还是无法确认结果？先修那一点，通常比一次补完四份文档有效。
06
常见问题
AX 是谁提出的？
AX 由 Netlify 执行长暨共同创办人 Mathias Biilmann 在 2025 年 1 月提出，原文是〈Introducing AX: Why Agent Experience Matters〉。本页的四个检查点，对应他在 2026 年 1 月〈One Year of AX〉中的访问、上下文、工具与编排四个领域。
AX 和 UX、DX 有什么不同？
UX 设计给看画面操作的人，DX 设计给读文档接 API 的开发者，AX 设计给替人办事的 AI 智能体。智能体拿到一句目标就自己找路，所以入口、工具、参数与错误回复都要能直接操作。
AX 和 GEO、TSO 有什么不同？
GEO 处理 AI 回答里有没有提到、引用你；TSO 处理智能体有没有选到你的工具；AX 处理智能体真的把任务做完。三件事会互相影响，但发生的位置不同。
一般品牌网站要先从哪一块开始？
别急着把四个领域都补齐。先挑一个真实任务，让智能体从头操作一次，找出第一个中断点，再从那里修。通常会比先写完一套文档更快看到问题。
AX 只跟有 API 的产品有关吗？
不用。网站本身就是智能体会读、会点的界面。没有 API 时，先把产品信息、联系方式与人工接手流程整理清楚，还是能改善 AX。
智能体出错时，怎么把任务交回真人？
超时后先查预订状态，需要重试时沿用同一笔操作的幂等键，避免重复预订。遇到无法处理的状况就停止，把做到哪里、为什么停交还给人，而不是只丢一句“请洽客服”。
智能体回报“已完成”，就代表预订成功了吗？
不一定。工具回复成功之后，还要有可核对的记录：餐厅、时间、人数、预订编号与修改方式。智能体要分得清“已送出”与“已确认”，才不会把处理中当成完成。
智能体需要的权限，要全部开放吗？
不用。查空位、暂留座位与送出预订可以分开授权，让智能体只做范围内的事；真正送出前，把时段、人数与取消条件交给人确认。
07
四个研究主题的关系
GEO 看自然回答里的提及与引用，TSO 看智能体选用哪个工具，AX 看任务能不能完成，AI 广告看回答下方的付费版位如何匹配与转化。四者处理相邻的问题，可依内容交叉阅读。
