当AI从“会说”走向“会做”，智能体开始成为产品和平台的新型使用者，也成为业务流程中的行动主体。体验评价因此不能再停留在界面是否好用、回答是否准确，而要进一步回答：智能体是否理解场景、能否被放心委托、是否真正完成任务，以及整个过程是否可靠、可控、可验证、可追溯。

过去二十多年里，我们谈数字产品、服务设计和客户体验，始终绕不开一个核心概念：用户体验。

这套逻辑塑造了今天的用户体验方法体系。我们做用户研究，理解人的需求；绘制用户旅程，分析人的触点；优化界面流程，降低人的认知负担；追踪满意度、可用性、转化率和留存率，判断人是否喜欢、是否顺畅、是否信任。

这套方法没有过时，但正在变得不够用。

当下，AI正在从“会说”走向“会做”。智能体不再只是回答问题的聊天机器人，也不再只是嵌入界面的辅助功能。越来越多智能体开始替人理解任务、规划步骤、调用工具、访问系统、比较方案、做出判断、写回状态，甚至与其他智能体协同完成复杂任务。

它们既是产品和平台的新型使用者，也是业务流程中的执行者；既可能服务人，也可能代表组织承担一项持续性的职责。

于是，一个新的问题出现了：

这就是为什么我们需要讨论一个新的概念：智能体体验——Agent Experience，简称AX。

用一句话概括：

一、AX不是“AI产品的用户体验”

“智能体体验”很容易被误解。

有人把它理解为AI产品的用户体验，有人把它理解为智能体好不好用，也有人把它等同于模型能力、任务成功率或智能体基准测试。这些理解都触及了一部分，但都不完整。

传统UX主要关注人使用系统时的感知与行为；AI模型评价主要关注模型能否回答、推理或生成；智能体基准测试通常关注某种能力在规定任务上的表现。AX关注的则是：

它既包括人和智能体之间的委托与交互，也包括智能体对场景、规则和权限的理解；既包括智能体与工具、系统及其他智能体的协同，也包括它在跨轮次、跨任务、跨场景过程中对上下文和经验的保持、更新与回写；最终还要看任务是否真正完成，以及整个过程能否被控制、复核和追溯。

因此，AX评价的不是智能体是否拥有类似人的主观感受，也不只是“人觉得怎么样”，而是智能体参与之后，整个任务系统是否真的变得更可靠、更高效、更可控。

传统UX的核心对象是人。AX的核心对象，是智能体参与后的完整任务系统。

二、AX这个概念从哪里来

严格地说，Agent Experience并不是一开始就指AI智能体体验。

在客服和呼叫中心领域，Agent长期用来代指话务员和人工坐席，因此早期的Agent Experience更多是“坐席体验”，也就是客服人员使用系统、处理工单和服务客户时的工作体验。

在AI Agent语境中，AX真正进入全行业讨论，一个重要节点来自Netlify联合创始人兼CEO Mathias Biilmann。

2025年1月28日，他发表《Introducing AX: Why Agent Experience Matters》，明确提出：随着AI智能体开始自主地与产品、平台和内容交互，企业需要关注智能体作为产品或平台用户时的整体体验。他把AX放在UX、DX之后：过去为人类用户设计UX，为开发者设计DX；现在，还需要为AI智能体设计AX。

Salesforce随后从体验设计角度进一步提出，AI智能体是一类新的终端用户，AX既包括“为智能体设计数字环境”，也包括“设计智能体本身”，目标是让智能体有效运行，并产生以人为中心的结果。

Speakeasy和Stainless等API与开发者基础设施公司，则把AX进一步落实到工程层面：清晰而范围适当的工具、机器可读文档、稳定的接口契约、明确的权限、可执行的错误信息、失败后的恢复路径，以及持续评价和改进机制。

由此可以看到，AX最早的一层含义，是让产品、平台、API和服务对智能体更加友好；但随着智能体进入真实业务流程，它正在从“智能体作为用户的体验”扩展为“智能体参与业务后的系统体验”。

三、为什么不是更宽泛的“AI体验”

“AI体验”可以覆盖搜索推荐、图像识别、智能客服、AIGC写作工具和企业大模型平台，范围非常广。智能体则是一种更具体的系统形态。

它不仅生成内容，还可能具备目标理解、任务规划、工具调用、状态保持、结果反馈乃至一定程度的自主执行能力。

“会说”主要考验模型生成能力；“会做”则涉及场景理解、任务拆解、权限边界、工具调用、异常恢复、结果确认、多方协同和责任追溯。

这决定了智能体体验必须回答一组更复杂的问题：

• 智能体是否理解了真实场景，而不只是识别了提示词表面含义？
• 是否识别了用户的真实意图、目标和隐含约束？
• 是否知道哪些事能做、哪些事不能做，何时必须请求授权？
• 是否正确调用工具，而不是只在语言上“假装完成”？
• 是否能在失败时恢复，并向人清楚说明问题和下一步？
• 是否能与其他智能体共享必要状态、传递完整信息并履行任务契约？
• 是否能记住该记住的、更新已经过期的、删除不该保留的？
• 是否允许人类随时干预、接管、审计和追责？

这些问题已超出一般“AI体验”的范畴。提出AX，不是为了制造一个新名词，而是因为智能体带来了新的体验对象、新的交互关系和新的系统风险。

四、AX正在呈现五个演进趋势

从2025年以来的国际讨论和企业实践看，AX正在沿着五个方向快速演进。

趋势1. 从“人使用产品”扩展到“智能体也使用产品”

过去，产品主要被人点击，文档主要给人阅读，流程主要由人操作。现在，产品会被智能体读取，API会被智能体调用，知识会被智能体检索，流程会被智能体执行。

未来一个产品是否“体验好”，不仅取决于人打开界面后是否顺畅，也取决于智能体能否理解它、调用它、完成任务，并把结果可靠地带回给人。

趋势2. 从图形界面友好走向机器可读与可操作

人可以容忍一定程度的模糊、猜测和视觉引导，智能体则更依赖清晰的结构和稳定的契约。高质量AX越来越依赖机器可读文档、结构化语义、统一身份、稳定API、明确权限、可解释错误和可恢复路径。

这意味着，体验设计的对象不再只是页面和交互流程，还包括API、数据模型、本体语义、工具描述、上下文协议和系统反馈机制。对智能体来说，这些过去被视为“后台”的部分，正在成为新的体验界面。

趋势3. 从交互工具走向工作委托与人类编排

当人只向AI提问时，界面清晰、回答准确可能已经足够；当人把任务交给智能体时，体验的重点就转向能力边界、任务契约、过程反馈、授权确认、异常处理、人工接管和结果验收。

人的角色也在变化：从逐步操作系统的人，转变为提出目标、设置边界、调度智能体并验收结果的编排者。

趋势4. 从单智能体走向多智能体和跨系统协作

越来越多复杂任务不会由一个智能体独立完成，而是由多个专业智能体、工具和系统共同完成。任务如何分解，信息如何传递，状态如何同步，冲突如何处理，上游错误如何被下游拦截，最终责任如何追溯，都成为新的体验问题。

因此，AX正在从单点人机交互扩展为人、智能体、系统和组织共同参与的协同网络。

趋势5. 从能力展示走向生产级可信完成

早期智能体更多通过演示证明“它能做什么”。进入真实业务后，组织更关心“它能否稳定、合规地做成”。评价重点因此从单次成功、语言表现和能力上限，转向连续稳定成功、真实结果状态、证据链、成本与循环控制，以及版本变化后的持续回归。

AX也由一种设计理念，逐渐成为智能体工程化、规模化和可信化所需的质量基础设施。

五、当“用户”不再只是人类，体验关系如何扩展

“用户不再只是人类”，并不是说人不重要了。恰恰相反，是因为智能体开始参与行动链路，更多角色进入了体验结构。

直接与智能体交互的人，需要委托任务、查看结果、确认风险和接管异常；组织委托方关心智能体能否承担岗位职责并服务组织目标；系统管理者和运营者关心稳定性、成本、越权和回滚；审计与治理主体需要核验合规证据和责任链；在多智能体系统中，其他智能体也会成为信息和任务的接收者。

因此，AX中的“用户”已经扩展为委托者、监督者、执行者、接收者、复核者和协作者。

C2A：场景到智能体（Context to Agent）

智能体能否理解主体、对象、当前状态、时间条件、业务规则、权限边界、用户意图、真实目标和隐含预期？

如果场景理解错了，后面的交互越自然、执行越流畅，可能只是“错误的流畅”。

H2A：人到智能体（Human to Agent）

人能否清楚委托任务？智能体能否澄清歧义、告知边界、反馈进展、请求授权、解释结果，并支持暂停、撤销、回滚和人工接管？

传统UX更多关注“人如何操作系统”，H2A关注的是“人如何把工作交给智能体，并始终保有必要的控制权”。

A2A：智能体到智能体（Agent to Agent）

多个智能体能否可靠分工、传递完整上下文、同步状态、解决冲突、隔离失败并形成连续的责任链？

这已经不是传统人机交互能够充分覆盖的问题。

M2A：记忆到智能体（Memory to Agent）

智能体能否在合适场景调用正确记忆，及时更新过期内容，纠正错误内容，隔离不同用户、项目和租户的数据，并将经过验证的任务经验安全回写？

没有记忆治理，就没有真正的持续体验；没有正确回写，也没有智能体基于场景反馈持续改进的飞轮。

因此，中国复杂业务语境下的AX，不应只被理解为“Agent作为用户的体验”，更应被理解为：

六、AX的本质：场景中的决策与执行质量

如果要用一句话解释智能体体验，可以这样说：

这句话包含四个关键词：

第一个是“场景”。智能体不是在真空中工作。它面对的是具体的人、任务、对象、状态、规则、时间、权限、历史和预期。没有场景，智能体只能做泛化回答；理解了场景，智能体才可能做出正确判断。

第二个是“决策”。智能体不断在做判断：用户真正想要什么？下一步该做什么？是否需要调用工具？是否需要人工确认？结果是否可信？是否触碰风险边界？这些判断构成了智能体体验的核心。

第三个是“执行”。智能体时代最大的变化，是AI开始从回答走向行动。行动必须产生结果，结果必须能够被确认。真正的AX不能只看智能体有没有说“已经完成”，而要看目标环境、业务对象、系统状态、文件状态或审批状态是否真的发生了正确变化。

第四个是“记忆”。智能体如果不能把经过验证的任务过程、场景反馈和用户偏好沉淀下来，就只能反复从零开始；如果记住了错误、过期或未经授权的内容，又会持续放大风险。因此，记忆既是能力，也是治理对象。

归根到底，AX不只是“聊得像不像人”，而是：

七、AX智能体体验应该如何评价

智能体最容易让人误判的地方，是它经常“看起来像完成了”。

它可能说“已经提交”，但系统状态没有变化；可能说“文件已生成”，但文档内容或版式完全不可用；可能说“已经查询”，但没有调用正确接口；可能给出一个看似合理的结论，但数据口径错误；也可能完成了表面任务，却越过权限边界。

因此，AX评价要从回答质量走向任务质量，从交互感受走向可信执行，从一次演示走向可复现、可验证、可追溯的评价过程。

整体架构可以概括为：

一道门：底线门槛

越权访问、敏感信息泄露、绕过审批执行高影响动作、伪造工具调用结果、把失败写回为完成、提示注入防御失效、危险动作无法中止、评价欺骗和后台循环失控，不是“扣几分”的问题，而应是不可补偿的底线问题。

底线门槛既包括正式评价前的静态准入检查，也包括任务运行过程中的动态审计。它的作用不是让智能体得高分，而是防止高风险智能体带病上线。

一次适配：先分类，再确定必测模块

不同智能体不能用同一把尺子评价。

对话助手重点看场景理解、意图识别、上下文保持、歧义澄清和边界告知；工具型智能体重点看任务完成、工具调用、输出质量、结果验证和错误恢复；工作流与自动化智能体重点看步骤规划、参数构造、状态写回和权限控制；数字员工与平台级智能体还要评价岗位边界、长程任务、多智能体协同、记忆治理和循环运行；具身智能体则要增加环境与设备状态反馈、紧急停止和物理结果验证。

分类适配的目的，是避免低估高自治智能体的执行风险，也避免对简单信息型助手施加不必要的测评负担。

四类能力：C2A、H2A、A2A、M2A

四类能力分别评价场景理解、人机委托、智能体协同和记忆治理。它们回答的是：智能体是否理解任务所在的真实环境，人是否能够放心委托，多个智能体是否能够可靠协同，系统是否能够正确积累和使用经验。

一条证据链：从轨迹到结果状态

智能体执行过程中，应记录关键输入、任务规划、工具调用、参数与返回、记忆读写、授权确认、状态变化、异常处理和验证结果。最终结论不能只依赖智能体自述，而要通过外部环境、数据库、日志、文件、接口或人工复核进行独立验证。

这条证据链，是复核、归因、追责和持续改进的基础。

八、六类关键指标：分数不是目的，而是为了发现问题

指标体系的作用，是把复杂体验问题拆成可观察、可记录、可比较、可复测的质量项。AX评价可围绕以下六类关键指标展开。

这六类指标共同回答一个问题：

指标不能脱离场景孤立使用。同一个“任务完成率”，在问答助手、工单智能体、代码智能体、财务数字员工和多智能体系统中的含义并不相同；同一个“满意度”，也不能替代对真实结果状态的验证。

九、AX智能体体验评价的六种关键方法

方法一：从场景卡开始，而不是从提示词开始

普通提示词测试的链路通常是“输入提示词—查看回答”；AX评价需要建立更完整的链路：

更具体地说，应先建立场景卡，再设计测试任务，最后才写测试提示词。

场景卡需要说明业务背景、角色与权限、任务目标、显性意图与隐含预期、业务对象、规则约束、可用工具、禁止行为、风险等级、人工接管条件和结果验证对象。

测试任务需要进一步明确前置条件、输入材料、任务契约、允许工具、禁止动作、期望输出、完成标准、失败策略和验证方式。

测试提示词只是触发智能体行为的输入。它应尽量接近真实用户表达，并覆盖正常、模糊、隐含意图、规则冲突、权限边界、工具异常、高风险、对抗、多智能体协同和长程运行等不同类型。

这样才能避免三个常见误区：把提示词当成场景，把回答当成结果，把“看起来完成”当成“真的完成”。

方法二：分层评分，而不是只靠模型裁判

智能体体验评价不能只靠一个大模型裁判，也不能只靠用户主观感受。合理的分工是：

接口是否调用、参数是否正确、状态是否写回、权限是否越界、文件是否生成等硬事实，应优先采用规则、日志和系统状态判断。

表达是否清楚、解释是否充分、策略是否合理、结果是否满足语义预期，可以由模型依据明确的评分准则和评分锚点辅助判断。

金融、医疗、政务、法律、资金交易、数据删除和生产环境变更等高风险场景，需要专家复核，尤其是规则与模型评分冲突、样本接近通过边界或业务口径尚未固化时。

用户评分则用于评价委托是否容易、过程反馈是否清晰、结果是否易懂、控制感和信任感是否充分。用户满意不能证明任务真实完成，也不能抵消越权、泄露和虚假完成等底线问题。

方法三：验证结果状态，防止“虚假完成”

可信完成不是智能体说完成了，而是同时满足几个条件：任务目标达成，结果符合任务契约，通过独立验证，未触发底线事件，并且过程证据能够支撑结论。

对执行型智能体，不能把自然语言声明或完成状态码直接当作完成依据，而要核验目标对象是否发生了预期变化。

文档智能体要看目标文件是否真实生成、内容与版式是否符合要求；代码智能体要看代码是否提交、是否通过测试、是否引入缺陷；数据分析智能体要看数据来源、统计口径、图表和结论能否复核；工单与审批智能体要看业务状态是否正确变化；配置智能体要看目标系统配置是否真正生效。

这是AX评价区别于普通问答测试的关键。

方法四：多次运行，评价稳定性而不是偶然性

智能体运行具有不确定性。一次成功只能说明“有可能做到”，不能证明“可以放心委托”。

对客服、政务、金融、审批、生产配置、设备控制和数字员工等确定性较强的任务，应重点评价连续稳定成功率：同一任务多次运行，均在规则与边界内成功，才具备生产级可靠性。

对代码生成、研究检索、方案生成和创意任务等探索型场景，可以评价有限重试次数内的成功率，用于观察能力上限。

至少一次成功，证明智能体“可能做到”；连续稳定成功，才说明它“可以被放心委托”。

方法五：对问题样本进行模块归因

一个智能体输出错误结论，原因可能不在模型本身，而在数据接口、统计口径、知识召回、记忆调用、任务规划、工具选择、参数构造、多智能体通信、状态写回或最终表达。

因此，问题样本分析应形成“证据收集—范围收敛—逐模块诊断—责任判定—结构化沉淀”的归因链路。

评价报告不能只告诉团队“这条没通过”，还要说明问题现象、判定依据、主责模块、次责模块、用户影响和修复建议，并将样本纳入问题库、回归任务集和版本发布门槛。

评价的目的不是出分，而是把问题稳定追到可修复的原因。

方法六：把评价嵌入研发、上线和运营闭环

AX评价不应是上线前的一次性项目，而应嵌入智能体全生命周期。

• 研发阶段，用核心场景集快速发现模型、提示词、工具、记忆、权限、流程和交互短板。
• 上线验收阶段，用正式必测场景集验证底线门槛、核心能力、结果状态、证据链和用户可接受性。
• 运营阶段，持续抽取真实任务、失败样本、低满意样本、投诉工单、异常日志和监控告警，回流测试集。
• 版本变更阶段，模型、提示词、工具、知识库、权限策略、记忆机制或工作流节点发生变化，都应触发回归评价。
• 事故复盘阶段，把线上问题转化为新的场景卡、任务卡、边界样本和对抗样本，防止同类问题重复发生。

最终，应形成这样一个闭环：

场景资产库 → 评价任务库 → 测试提示词库 → 自动执行 → 轨迹采集 → 结果状态验证 → 分层评分 → 用户反馈 → 问题归因 → 修复复测 → 持续监测。

此时，评价不再只是“出一份报告”，而成为智能体持续进化的质量基础设施。

十、从UX到AX，不是替代，而是升级

提出AX，并不意味着UX不重要了。只要人还在使用产品、委托任务、监督过程和接受结果，用户体验就不会消失。

但体验学科需要从人机界面走向人机协同，从交互感受走向任务结果，从单点产品走向场景系统。

过去，我们主要设计人如何使用系统；现在，还要设计智能体如何理解和调用系统，人如何委托和监督智能体，智能体如何与其他智能体协同，组织如何治理智能体，以及系统如何利用记忆持续优化。

UX关注人，DX关注开发者，AX关注智能体，CX关注客户关系和业务结果。智能体时代真正需要的，是把这些体验统一到具体场景中，让人、智能体、组织、系统、工具、数据和记忆共同构成一个可运行、可追溯、可改进的任务系统。

一个高质量的智能体产品，不只是模型强、界面好、功能多。它还应当：

• 让人能够放心委托，并随时保有必要的控制权；
• 理解真实场景，而不只是理解提示词；
• 调用工具、改变状态并完成真实任务，而不只是生成建议；
• 承认不确定性，遇到边界和风险时主动请求确认；
• 与其他智能体可靠协作，而不是各自为战；
• 留下完整证据，让结果能够被验证、复核和追溯；
• 正确记忆、及时更新、必要时遗忘，并防止记忆污染；
• 持续从场景反馈和失败样本中改进，而不是一次性完成任务。

结语：从“看起来能用”到“可以放心委托”

为什么现在必须关注AX？

因为智能体正在成为新的行动主体。因为人类用户不再是唯一的体验参与者。因为未来的产品不仅要被人使用，也要被智能体读取、调用、执行和确认。因为智能体产品的质量不能只靠模型能力或用户满意度证明，而必须在真实场景中证明它可靠、可控、可信、可协同、可持续。

从“看起来能用”到“可信完成”，是智能体从演示走向生产的分水岭。

AX不是一个概念包装，也不只是体验设计领域的一次术语扩展。它将逐渐成为智能体时代产品设计、服务设计、工程实现、质量评价和组织治理共同需要的新基础。

从UX到AX，变化的不只是体验对象，而是整个数字世界的使用方式。