别再沉迷协议，专注代理体验

2025 年，如果你没有使用 MCP（模型上下文协议）进行开发，那你可能没有认真对待 AI 代理。MCP 主导了一整年的代理话题讨论：会议演讲、路线图、招聘计划，几乎一切都围绕 MCP 展开。

然而，到了 2025 年底至 2026 年，AI Skills 出现并立即引发了反弹。工程师们宣称 MCP 已死，取而代之的是 Skills，随后又转向 CLI。Perplexity 的 CTO 公开表示公司正在降低对 MCP 的优先级。这个循环快、响且可预测：新工具、新热潮、新重写。

我在 2025 年初便开始推广代理体验（Agent Experience，简称 AX），当时 MCP 仍是核心焦点。回应大多是质疑：AX 想得太复杂了，MCP 才是唯一重要的层面。这种观点如今看来有失偏颇。那些否定 AX 的人并非认为 MCP 无用，而是错将协议当成了战略。

他们忽略的是，而且我认为整个行业仍然在忽略的是：协议本身不值得精通，真正值得精通的是这门学科。

我们不断掉入工具陷阱

我们的行业有一个众所周知的习惯：混淆工具与战略。微服务、Kubernetes、GraphQL 时代如此，现在对代理协议也是如此。

MCP、AI Skills、A2A、ACP 都是实现方式。它们很重要，解决了实际问题。但没有任何一个值得你在此基础上构建战略。因为它们本质上就是会变化的东西。

当你围绕一个特定协议组织代理战略时，你是在一个由他人控制的、市场随时可能抛弃的基础上建造。更糟糕的是，你跳过了本该先做的步骤——判断该协议是否真正适合你的用例。

这就是工具陷阱。你优化了一个特定集成机制的使用，却没有首先理解你究竟在优化什么。

那么，什么是代理体验？

代理体验（AX）是研究 AI 代理如何发现、理解你的系统并与之交互，然后系统性地改进这些交互的学科。

可以将其视为面向代理的用户体验（UX）。UX 的出现并非因为某个 UI 框架胜出，而是因为团队意识到人类与软件交互的质量是一个设计问题，它超越了任何特定技术。在 React 中构建糟糕的体验和在原生 JavaScript 中一样容易。框架不是决定性变量，设计思维才是。

AX 同理。代理如何发现你的服务能做什么？它如何理解 API 的边界？当它失败时，能否获得足够的上下文进行恢复？交互是否高效，还是代理在无谓的往返中浪费 token？

这些问题与协议无关。无论你是通过 MCP、Skills、A2A 还是尚未发明的方式来暴露能力，它们都适用。能够回答这些问题的团队将适应任何未来变化，因为他们理解问题空间，而不仅仅是当前的工具链。

AX 是你已关心之事物的延伸

AX 并非用户体验、开发者体验或客户体验的竞争对手。它是这三者的延伸。

你的首要目标仍是提供卓越的客户体验。但变化在于客户与你互动的方式。越来越多客户将任务委托给代理。当客户要求代理与你的 API 集成、部署到你的平台或从你的服务中拉取数据时，该代理正代表客户行事。代理的体验决定了它实现客户目标的可能性。

如果客户的代理在身份验证上挣扎，为了解析你的错误消息而消耗大量 token，或者因为你的 API 缺乏上下文而静默失败，那就不仅仅是投诉那么简单了。代理会悄无声息地转向能提供更好体验的替代服务。你的客户可能甚至不会注意到这一转变。你就在没有任何支持工单的情况下失去了客户。

UX 优化的是人类点击界面的体验，DX 优化的是开发者在你平台上构建的体验，CX 审视整个客户旅程。AX 则将这种思考延伸到了客户如今派出的代理身上。

协议跑步机不可持续

回顾一下 MCP 的实际历程。团队投入大量精力编写 MCP 服务器实现。但很多实现并不理想。不是 MCP 本身有缺陷，而是这些团队没有仔细思考代理真正需要从他们的系统获得什么。2026 年女王大学的一项研究分析了 103 个 MCP 服务器中的 856 个工具，发现 97.1% 的工具描述至少包含一个质量问题，56% 未能清晰说明其目的。协议运行正常，但体验设计才是问题所在。

当 Skills 出现时，同样的团队面临换汤不换药的熟悉问题。他们仍然没有回答根本性问题：代理需要利用我们的服务完成什么？最小的可行交互界面是什么？代理需要哪些上下文才能做出良好决策？

而那些已经解决了这些问题的团队适应得很快。当你已经知道代理面向的接口应该是什么样子时，从一个协议迁移到另一个协议只是机械性工作。协议是序列化格式，体验设计才是难点。

这种模式会不断重复。无论是通用商务协议、A2A 还是下一个热门事物，总会有新东西流行。如果你的策略是成为每种连续协议方面的专家，你就踏上了一条只会加速的跑步机。

AX 实践的模样

那么，认真对待代理体验究竟意味着什么？如果你曾经建立过 UX 研究实践或 DX 项目，你会觉得这一切很熟悉。步骤并不新鲜，只是角色变了。

我在演讲中将其分解为五个步骤：

1. 审计你的客户使用的代理。 了解什么在进入你的系统。查看流量数据和日志，区分哪些是代理流量哪些是人类流量，以及具体是哪些代理。你的客户是否在使用 Claude Code、Cursor 或基于你的 API 构建的定制代理？你不能为未曾观察过的东西进行设计。这与 UX 团队进行用户研究是同样的动机，只是方法不同。

1. 识别客户希望委托的用例。 并非每次交互都需要针对代理进行优化。利用相同的日志数据，查看代理向你的平台发出的请求，并推断它们试图完成什么。你也可以使用 AEO 数据来了解客户在面向代理的搜索中询问哪些领域。首先关注最高价值的部分。如果你曾经通过查看开发者实际如何使用你的 API 来排定 DX 路线图的优先级，那你就已经具备这种能力了。

1. 验证和审计这些交互的体验。 观察代理在尝试完成这些任务时会发生什么。它在哪一步卡住了？它在哪一点误解了你的服务能做什么？这就是可用性测试。用户是语言模型，困难在于上下文而不是按钮位置，但你要回答同样的问题：它们能完成工作吗？

1. 改进和重复。 代理能力不断进化，模型变得更聪明，新的交互模式出现。在 Netlify，我们发现有些情况我们的产品以一种方式工作，但代理普遍假设它以另一种方式工作且从不询问。我们没有与这种假设抗争，而是改进产品使其按代理期望的方式工作。结果是代理流程的采用率更高，错误更少。把 AX 作为活实践来对待的团队，将胜过那些从一个协议迁移忙到下一个的团队。

1. 自动化验证并防止退化。 一旦你有了“良好”的基线，就把它锁定下来。像 AXIS 这样的开源评分框架，允许你对真实场景运行真实代理并得到可比较的分数。将其集成到 CI 中，就像捕捉测试失败一样捕捉 AX 退化。这样你就能从轶事式的改进转向可衡量、可重复的 AX 质量。

当你的实践到位后，协议选择就变得显而易见。你可以根据新工具的实际优点来评估它们：它是否解决了你观察到的真实摩擦点？它是否解锁了你以前无法实现的能力？还是仅仅是对你已经做得很好的事情进行了不同的包装？

困难之处是熟悉的

AX 比学习新协议更难掌握，这是事实。学习 MCP 或 Skills 是一个有边界的工程问题：阅读文档、编写代码、交付集成。明确的终点，容易展示进展。这相当有吸引力，特别是当你或你的团队快速前进时。

而建立 AX 学科意味着在短期内要忍受模糊性。在你有清晰答案之前研究代理行为。承认正确的集成策略取决于你需要发现的上下文，而不是可以跟随的教程。但如果你曾从零开始建立 UX 或 DX 实践，那么你以前就经历过这些。原因相同：理解你的用户、减少摩擦、让他们容易成功。方法不同是因为用户不同。学科本身并不新鲜，而是我们行业几十年来工作的延伸。

好消息是，这种思维正在获得动力。John Maeda 的 2026 年设计科技报告明确讨论从 UX 到 AX 的转变。研究人员正在将代理交互质量作为一流的工程问题进行研究。BCG 和 MIT Sloan 发现 35% 的组织已经在使用代理型 AI，另有 44% 在计划中。问题不再是 AX 是否重要，而是你的团队是否在竞争对手之前建立实践。

2028 年的代理与 2025 年的代理与你的系统交互方式将不同。协议不同，能力不同，期望不同。但不会改变的是，你的系统需要为使用它们的人，以及现在那些人派出的代理，提供卓越体验这一根本需求。

精通于此，其他都只是实现细节。