In 2025, if you weren’t building with MCP, you weren’t serious about agents. The Model Context Protocol dominated the agent conversation for the better part of the year. Conference talks, roadmaps, hiring plans, all of it revolved around MCP.在 2025 年，如果你没有使用 MCP 构建，就说明你对代理并不认真。模型上下文协议（Model Context Protocol）在全年大部分时间里主导了代理对话。会议演讲、路线图、招聘计划，所有内容都围绕 MCP 进行。
Then late 2025 into 2026, AI Skills arrived and the backlash was immediate. Engineers declared MCP dead in favor of Skills, then dead in favor of CLI. Perplexity’s CTO said publicly that the company was deprioritizing it. The cycle was fast, loud, and predictable. New tool, new hype, new rewrite.随后在 2025 年底到 2026 年，AI Skills 出现，反响立刻出现。工程师们宣称 MCP 已死，转而支持 Skills，随后又说 Skills 已死，转向 CLI。Perplexity 的 CTO 公开表示公司正在降低对它的优先级。这个循环快速、喧闹且可预测。新工具、新热潮、新重写。
I started pushing Agent Experience early in 2025, while MCP was still the center of gravity. The response was mostly skepticism. AX was overthinking it. MCP was the only layer that mattered. That perspective aged poorly. The people who dismissed AX weren’t wrong about MCP being useful. They were wrong about a protocol being a strategy.我在 2025 年初就开始推动代理体验（Agent Experience），当时 MCP 仍是重心。大多数回应是怀疑。AX 被认为是过度思考。MCP 是唯一重要的层。这个观点后来证明不合时宜。那些否定 AX 的人并不是说 MCP 没用，而是误以为协议本身就是策略。
The thing they missed, and what I think most of the industry is still missing, is that the protocol is not the thing to get good at. The discipline is.他们错过的，以及我认为整个行业仍在错过的，是协议本身并不是需要精通的东西。需要精通的是这门学科。
We keep falling into the tool trap我们不断陷入工具陷阱
Our industry has a well-documented habit of confusing tools with strategy. We did it with microservices, Kubernetes, and GraphQL. Now we’re doing it with agent protocols.我们的行业有一个记录在案的习惯——把工具当作策略。我们在微服务、Kubernetes 和 GraphQL 上都犯过这个错误。现在我们又在代理协议上犯了同样的错误。
MCP, AI Skills, A2A, and ACP are all implementations. They matter and they solve real problems. But none of them are the right thing to build your strategy on top of. They are, by nature, the thing that changes.MCP、AI Skills、A2A 和 ACP 都是实现方式。它们重要，能解决真实问题。但它们都不应该成为你构建策略的基石。它们本质上是会变化的东西。
When you organize your agent strategy around a specific protocol, you’re building on a foundation someone else controls and the market can shift away from at any moment. Worse, you’re skipping the step that would tell you whether that protocol is even the right fit for your use case.当你围绕特定协议组织代理策略时，你实际上是在建立在别人控制的基础之上，而市场随时可能转向。更糟的是，你跳过了判断该协议是否真正适合你的用例的步骤。
This is the tool trap. You optimize your usage of a specific integration mechanism without first understanding what you’re actually optimizing for.这就是工具陷阱。你在优化特定集成机制的使用，却没有先弄清楚真正要优化的是什么。
So what is Agent Experience?那么，什么是代理体验？
Agent Experience (AX) is the discipline of studying how AI agents discover, understand, and interact with your systems, and then systematically improving those interactions.代理体验（AX）是一门研究 AI 代理如何发现、理解并与您的系统交互的学科，并系统性地改进这些交互。
Think of it as the agent-facing counterpart to User Experience. UX didn’t emerge because one UI framework won. It emerged because teams realized that the quality of human interaction with software was a design problem that transcended any particular technology. You could build a terrible experience in React just as easily as in vanilla JavaScript. The framework was not the variable. The design thinking was.把它看作是面向代理的用户体验（UX）对应物。UX 的出现不是因为某个 UI 框架胜出，而是因为团队意识到人与软件交互的质量是一个超越任何特定技术的设计问题。你可以用 React 也可以用原生 JavaScript 构建糟糕的体验。框架不是变量，设计思维才是。
AX works the same way. How does an agent discover what your service can do? How does it understand the boundaries of your API? When it fails, does it get enough context to recover? Is the interaction efficient, or is the agent burning tokens on unnecessary round trips?AX 的工作方式相同。代理如何发现你的服务能做什么？它如何理解你的 API 边界？当它失败时，是否得到足够的上下文来恢复？交互是否高效，还是代理在不必要的往返中消耗了大量 token？
These questions are protocol-agnostic. They apply whether you expose capabilities through MCP, Skills, A2A, or something that hasn’t been invented yet. The teams that can answer them will adapt to whatever comes next because they understand the problem space, not just the current toolchain.这些问题与协议无关。无论你是通过 MCP、Skills、A2A 还是尚未发明的东西来暴露能力，这些问题都适用。能够回答这些问题的团队将能够适应任何后续变化，因为他们理解的是问题空间，而不仅仅是当前的工具链。
AX is an extension of what you already care aboutAX 是你已经关心的事物的延伸
AX is not competing with User Experience, Developer Experience, or Customer Experience. It’s an extension of all three.AX 并不与用户体验（UX）、开发者体验（DX）或客户体验（CX）竞争。它是这三者的延伸。
Your primary focus is still providing a great experience to your customers. What has changed is how those customers interact with you. More and more, they delegate tasks to agents. When a customer asks an agent to integrate with your API, deploy to your platform, or pull data from your service, that agent is acting on their behalf. The agent’s experience determines how likely it is to achieve your customer’s goal.你的主要关注点仍然是为客户提供出色的体验。变化在于这些客户与您交互的方式。越来越多地，他们将任务委托给代理。当客户让代理集成你的 API、在你的平台部署或从你的服务拉取数据时，代理就在代表他们行动。代理的体验决定了实现客户目标的可能性。
If a customer’s agent struggles to authenticate, burns through tokens parsing your error messages, or fails silently because your API lacks context, something worse than a complaint happens. The agent will quietly start using an alternative service that provides a better experience. Your customer might not even notice the switch. You just lost them without a single support ticket.如果客户的代理在认证时遇到困难、在解析你的错误信息时耗尽 token，或因为你的 API 缺乏上下文而静默失败，会出现比投诉更糟的情况。代理会悄悄转向提供更好体验的替代服务。你的客户甚至可能没有注意到切换。你就在没有收到任何支持工单的情况下失去了他们。
UX optimized for humans clicking through interfaces. DX optimized for developers building on your platform. CX looked at the entire customer journey. AX extends that thinking to the agents those customers now send on their behalf.UX 为人类点击界面进行优化。DX 为在你的平台上开发的开发者进行优化。CX 关注整个客户旅程。AX 将这种思考延伸到客户现在代表他们发送的代理上。
The protocol treadmill doesn’t work协议跑步机行不通
Think about what actually happened with MCP. Teams invested heavily in writing MCP server implementations. A lot of those implementations were mediocre. Not because MCP was flawed but because the teams hadn’t thought carefully about what an agent actually needed from their system. A 2026 study out of Queen’s University examined 856 tools across 103 MCP servers and found that 97.1% of tool descriptions contained at least one quality issue, with 56% failing to state their purpose clearly. The protocol worked fine. The experience design was the problem.想想 MCP 实际上发生了什么。团队在编写 MCP 服务器实现上投入巨大。很多实现质量平平。并不是因为 MCP 本身有缺陷，而是因为团队没有仔细思考代理真正需要从系统中得到什么。2026 年皇后大学的一项研究审查了 856 种工具，涉及 103 个 MCP 服务器，发现 97.1% 的工具描述至少存在一个质量问题，56% 未能清晰说明其目的。协议本身运作良好，问题出在体验设计上。
When Skills emerged, those same teams faced a familiar problem wearing new clothes. They still hadn’t answered the foundational questions: What does an agent need to accomplish with our service? What is the minimum viable interaction surface? What context does an agent need to make good decisions?当 Skills 出现时，那些团队穿上新衣服仍面临熟悉的问题。他们仍未回答基础性问题：代理需要通过我们的服务完成什么？最小可行交互面是什么？代理需要什么上下文才能做出正确决策？
The teams that had worked through those questions adapted fast. Migrating from one protocol to another is mechanical when you already know what your agent-facing interface should look like. The protocol is the serialization format. The experience design is the hard part.已经解决这些问题的团队适应得很快。当你已经知道代理面向的接口应该是什么样子时，从一种协议迁移到另一种协议只是机械操作。协议是序列化格式，体验设计才是难点。
This pattern will keep repeating. Whether it is the Universal Commerce Protocol, A2A, or whatever lands next, something new will always be gaining traction. If your strategy is to become an expert in each successive protocol, you’re signing up for a treadmill that only speeds up.这种模式会不断重复。无论是通用商务协议、A2A 还是下一个出现的东西，总会有新事物获得关注。如果你的策略是成为每个后续协议的专家，你就签下了一条只会加速的跑步机。
What an AX practice looks likeAX 实践的样子
So what does it actually look like to take Agent Experience seriously? If you have ever built a UX research practice or a DX program, this will feel familiar. The steps aren’t new. The persona is.那么，真正认真对待代理体验到底是什么样子？如果你曾经建立过 UX 研究实践或 DX 项目，这会让你感到熟悉。步骤并不新，角色才是。
In talks, I break it down to five steps.在演讲中，我把它拆解为五个步骤。
Audit the agents your customers use. Know what’s walking through your front door. Look at your traffic data and logs and figure out what portion of your footprint is agents versus humans, and which agents specifically. Are your customers sending Claude Code? Cursor? Custom agents built on your API? You can’t design for something you haven’t observed. Same reason UX teams run user research. Different method, same motivation.审计客户使用的代理。了解哪些东西正走进你的前门。查看流量数据和日志，弄清你的足迹中有多少是代理而不是人类，以及具体是哪类代理。你的客户在发送 Claude Code？Cursor？基于你的 API 构建的自定义代理？如果你没有观察到，就无法为其设计。UX 团队进行用户研究的原因相同，只是方法不同，动机相同。
Identify the use cases customers want to delegate. Not every interaction needs to be agent-optimized. Take that same log data, look at the requests agents are making to your platform, and extrapolate what they were trying to achieve. You can also use AEO data to understand what areas your customers are asking about in agent-facing search. Focus on the highest-value surfaces first. If you have ever prioritized a DX roadmap by looking at what developers actually do with your API, you already know this muscle.识别客户想要委托的使用场景。并非每一次交互都需要针对代理进行优化。使用相同的日志数据，查看代理向你的平台发出的请求，并推断它们想要实现的目标。你也可以使用 AEO 数据了解客户在代理搜索中询问的领域。先关注价值最高的交互面。如果你曾经通过观察开发者实际使用你的 API 来优先排序 DX 路线图，你已经掌握了这套思维。
Verify and audit the experience of those interactions. Watch what happens when an agent tries to complete those tasks on your system. Where does it get stuck? Where does it misunderstand what your service offers? This is usability testing. The user is an LLM; the struggle is about context not button placement, but you’re answering the same question: Can they get the job done?验证并审计这些交互的体验。观察代理在你的系统上尝试完成任务时会发生什么。它卡在哪儿？它误解了你的服务提供了什么？这就是可用性测试。用户是 LLM；困难在于上下文而非按钮位置，但你在回答同一个问题：它们能完成任务吗？
Improve and repeat. Agent capabilities evolve. Models get smarter. New interaction patterns emerge. At Netlify, we’ve found cases where our product works one way but agents universally assume it works another way and never ask. Instead of fighting that assumption, we improved the product to work the way agents expect. The result was more adoption of those agent flows and fewer errors. The teams that treat this as a living practice will outperform those running from one protocol migration to the next.改进并重复。代理能力在演进，模型在变得更聪明，新的交互模式不断出现。在 Netlify，我们发现产品本来的工作方式与代理普遍假设的方式不一致，且代理从不提问。我们没有去对抗这种假设，而是改进产品，使其符合代理的预期。结果是这些代理流程的采纳率提升，错误率下降。把这当作活的实践的团队，将胜过那些只在协议迁移之间奔波的团队。
Automate validation and prevent regressions. Once you have a baseline for what “good” looks like, lock it in. Tools like AXIS, an open source scoring framework, let you run real agents against real scenarios and get a comparable score back. Wire it into CI and catch AX regressions the same way you catch broken tests. This is how you go from anecdotal improvement to measurable, repeatable AX quality.自动化验证并防止回归。一旦你有了“好”是什么样子的基准，就把它锁定。像 AXIS 这样的开源评分框架可以让你对真实代理在真实场景下进行测试并返回可比分数。把它接入 CI，像捕获破损测试一样捕获 AX 回归。这就是从零散改进走向可衡量、可重复的 AX 质量的方式。
When you have this practice in place, protocol choices become obvious. You can evaluate new tools on their merits. Does it solve a real friction point you have observed? Does it unlock capabilities you couldn’t achieve before? Or is it just different packaging for something you’re already doing well?当你拥有这种实践时，协议选择就变得显而易见。你可以根据工具的实际价值来评估它们。它是否解决了你观察到的真实摩擦点？它是否解锁了你之前无法实现的能力？还是仅仅是对你已经做得好的事情的不同包装？
The hard part is familiar难点是熟悉的
AX is harder to pick up than a new protocol. That is just the reality. Learning MCP or Skills is a bounded technical problem. Read the docs, write some code, and ship an integration. Clear finish line, easy to show progress. That’s genuinely appealing, especially when you or your teams are moving fast.AX 比新协议更难上手。这就是现实。学习 MCP 或 Skills 是一个有界的技术问题。阅读文档，写点代码，交付一个集成。目标明确，进度易于展示。这种方式确实很有吸引力，尤其是当你或你的团队动作快的时候。
Building an AX discipline means sitting with ambiguity for a while. Studying agent behavior before you have clean answers. Accepting that the right integration strategy depends on context you have to discover, not a tutorial you can follow. But if you’ve ever built a UX or DX practice from scratch, you’ve been here before. The why is the same: understand your users, reduce friction, and make it easy for them to succeed. How you do it is different because the user is different. The discipline isn’t new. It’s an extension of work our industry has been doing for decades.建立 AX 学科意味着要在模糊中坐一会儿。研究代理行为而没有现成答案。接受正确的集成策略取决于你必须发现的上下文，而不是可以直接照搬的教程。但如果你曾经从零构建过 UX 或 DX 实践，你已经走过这条路。原因相同：了解用户，降低摩擦，让他们更容易成功。做法不同是因为用户不同。学科本身并不新，它是我们行业数十年来工作的延伸。
The good news is that this thinking is gaining momentum. John Maeda’s 2026 Design in Tech Report is explicitly about the shift from UX to AX. Researchers are studying agent interaction quality as a first-class engineering concern. BCG and MIT Sloan found that 35% of organizations are already using agentic AI, with another 44% planning to. The question is no longer whether AX matters. It’s whether your team is building the practice before your competitors do.好消息是，这种思考正在获得动力。John Maeda 的 2026 年《Design in Tech Report》明确讨论了从 UX 向 AX 的转变。研究人员正把代理交互质量视为一等工程关注点。BCG 与 MIT Sloan 的研究发现，35% 的组织已经在使用代理 AI，另有 44% 正在计划使用。问题不再是 AX 是否重要，而是你的团队是否在竞争对手之前建立起这套实践。
The agents of 2028 won’t interact with your systems the way the agents of 2025 did. The protocols will be different. The capabilities will be different. The expectations will be different. What won’t change is the fundamental need for your systems to provide a great experience to the people who use them, and now, the agents those people send on their behalf.2028 年的代理不会像 2025 年的代理那样与你的系统交互。协议会不同，能力会不同，期望会不同。唯一不变的是你的系统必须为使用它们的人以及他们发送的代理提供出色的体验的根本需求。
Get good at that. The rest is implementation detail.在这方面变得擅长。其余的都是实现细节。
