随着 LLM 技术应用的不断发展，Agent Experience（简称 AX），成为了显学，来开始在工程圈流通。Netlify 联合创始人兼 CEO Mathias Biilmann 于 2025 年 1 月在其博客发表 Introducing AX: Why Agent Experience Matters 一文，正式引入这一概念。他将 AX 定位为继 UX（1993 年 Don Norman 在 Apple 任职时提出）与 DX（2011 年 Jeremiah Lee 在 UX Magazine 文章中系统阐述并普及的框架）之后的下一个核心设计维度。AX 专门探讨如何设计产品形态，使 AI Agent 能够可靠地「理解」、自主操作并高效集成到现有的界面和操作系统中。
事实上，Agent Experience 这个词要比 UX 和 DX[1] 复杂得多，因为它不仅包含了人这个高度不确定性的，又引入了一层人工智能，它们需要协同对外部世界产生影响，因此也会产生大量的彼此交互，让整个问题空间变得更难以分析。因此，为了把整个概念阐释清楚，我认为需要将其拆成三个维度来看：用户怎么和 Agent 沟通，Agent 怎么和外部世界沟通。还有夹在中间最复杂的那一层：Agent 的内部状态怎么管理。
用户怎么和 Agent 沟通，是一种输入质量问题。用户是人，表达天然是模糊的、情绪化的、跳跃的，你不可能期待每次他打开聊天窗口之前都在 Word 里面写一篇完整的议论文把自己的想法解释清楚。所以这一侧的核心挑战是怎么在不强迫用户写规范 Prompt 的前提下，把意图尽量准确地传进去。Skills 在这一侧发挥作用，交互设计也在这一侧。
Agent 怎么和外部世界沟通，是输出可控性问题。狭义层面上的 AX 通常被限定在这个范围。外部世界是确定的，文件系统、API、浏览器，它们不会因为 LLM 表达模糊就自动容错，所以这一侧的核心挑战是怎么把概率性的生成压缩成确定性的动作。MCP、工具调用、事件注入都在这一侧。
Agent 的内部状态，是一种上下文管理问题。用户的输入要进上下文，外部世界的反馈也要进上下文，而上下文本身是有限的、会劣化的、会被污染的。MemGPT、动态压缩、截图清理，严格来说既不属于用户侧也不属于外部世界侧，它们是在处理 Agent 自己的认知状态。AX 如果只盯着第一层，做出来的东西可能交互很顺滑，但 Agent 跑着跑着就开始犯蠢，用户照样会受到成吨的 Emotional Damage。
这是最复杂的部分，因为所有崭新的神秘词汇全都集中在此处，相信你也见过各种谁好谁不好的骂战。但在我看来这不是一个需要吵的话题，让我一口气把所有让你目眩的 LLM 名词全都过一遍。
众所周知的，LLM 本质是个概率模型，或者说，是个受函数约束的随机数接龙器。它在训练数据里找到了大量人类语言的规律，在给定上下文的情况下预测下一个 token 的概率分布，然后按分布采样。这东西本身能做到的事情就是生成文字。想让它对外界产生真实影响，就需要给神灯开一个瓶口。Claude Code 和一众 Coding Agent 用的是命令行，LLM 写出代码，执行器跑命令，结果回流上下文，这是一种瓶口。MCP 提供的是另一种，它的行为更接近 RPC：服务端暴露一批函数，LLM 看见函数签名，按需调用，外部世界因此被修改。Skills 则根本没有这层性质，它是纯粹的提示词工程工具，没有出口，只有给 LLM 看的说明书。
这三种形态看起来各管一摊，底层其实在解同一个问题：上下文污染。
这两个东西走的是两个思路，一个是在上下文加入正确的东西，一个是阻止垃圾信息填满上下文。
Skills 是提示词工程，它往上下文里追加一段说明，让 LLM 知道「这用户究竟是在公三小」，它向上下文当中导入了专家的认知结构，引导 LLM 的思维方向。但是 Skill 的约束能力强不强很看模型对上下文的尊重能力。LLM 会不会用你的 Skill、按什么顺序用、会不会跳步骤，全都是概率问题，没有强制收束。而且强收束并不一定是好事，后面会提到 Google 搜索的例子，另外也有研究认为 LLM 的幻觉与创造力是一体两面的，如果你强行约束它的行为，它做事情的思路就有可能变得很板。
MCP 走的是另外一套思路。函数签名本身就是极强的先验，参数类型、参数名称、函数名都在限制采样方向。动作空间从「能写出来的任何文字」一下子压缩成「这几个函数加这几个参数」。举个例子，让 LLM 操作鼠标按下一个按钮，这涉及列举窗口、取句柄、截图、算坐标、移动鼠标、点击，写成 Skills 的话你得接受 LLM 摇骰子决定这些步骤的执行方式和顺序，但如果是 MCP，看见函数列表，找到窗口，识别内容，点击坐标，一大堆随机决策被压缩成了三次确定性的函数调用。
但 MCP 没有完全解决上下文污染，因为工具调用的返回值同样会进上下文。设计粗糙的 MCP Server 扔回来一大坨 JSON 或者冗长的错误堆栈，照样往上下文里塞屎。扎带只管扎进去那一下，吐出来的东西还是得自己设计。
当然这也不是说 Skills 没有价值。MCP 开发成本高，需要专门的服务端，大量的工作根本不需要跟外界交互，或者逻辑太松散压根没法封装成 RPC 格式。一切技术形式服务于问题和目的，Skills 处理的是另一类场景，尤其是需要引导 LLM 以更完整方式思考的时候，毕竟用户是人，不能期待他们每次都给出思虑周全的 Prompt。
RAG 的本质也是在解上下文问题，只是它处理的是信息量的上限。哪怕 DeepSeek 和 Claude 把上下文窗口拉得很长，也没办法把整个世界都塞进去。只要你有大量信息检索的需求（整个文档库、知识库、历史记录），就需要一个类似搜索引擎的接口在用到的时候把相关内容拉进来，这跟给 MCP 调搜索引擎没有本质区别，都是维持上下文清洁的一种技术手段：LLM 不再需要把所有信息预先堆在那里，期待其能自己「发现」。
Memory 也是同一类东西。它需要 LLM 主动决定何时把信息存出去、何时再取回来，从这个角度看它就是一种带写入能力的 RAG。
这些概念都不是独立存在的，没有互斥关系。如果你把 NotebookLM 当成外部知识库，写一份 Skill 告诉主 LLM：遇到需要资料支撑的问题时去咨询 NotebookLM，需要计算或处理数据时调用 Python 工具。这个流程里，Skill 负责编排整体思路，Python 工具充当 MCP 风格的确定性执行单元，NotebookLM 则是一个带有自己上下文和知识库的外部 LLM，扮演的角色类似一个专门的 RAG 接口。三件东西各司其职，但把它们捏在一起的那根线，是 Skill 里的提示词。我之前写过一篇用 LLM 做逆向工程的文章讲了这件事，感兴趣的话可以读一读。