随着 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 怎么和外部世界沟通，是输出可控性问题。外部世界是确定的，文件系统、API、浏览器，它们不会因为 LLM 表达模糊就自动容错，所以这一侧的核心挑战是怎么把概率性的生成压缩成确定性的动作。MCP、工具调用、事件注入都在这一侧。
Agent 的内部状态，是一种上下文管理问题。用户的输入要进上下文，外部世界的反馈也要进上下文，而上下文本身是有限的、会劣化的、会被污染的。MemGPT、动态压缩、截图清理，严格来说既不属于用户侧也不属于外部世界侧，它们是在处理 Agent 自己的认知状态。AX 如果只盯着第一层，做出来的东西可能交互很顺滑，但 Agent 跑着跑着就开始犯蠢，用户照样会受到成吨的 Emotional Damage。
Agent 的内部状态：上下文即战场
这是最复杂的部分，因为所有崭新的神秘词汇全都集中在此处，相信你也见过各种谁好谁不好的骂战。但在我看来这不是一个需要吵的话题，让我一口气把所有让你目眩的 LLM 名词全都过一遍。
众所周知的，LLM 本质是个概率模型，或者说，是个受函数约束的随机数接龙器。它在训练数据里找到了大量人类语言的规律，在给定上下文的情况下预测下一个 token 的概率分布，然后按分布采样。这东西本身能做到的事情就是生成文字。想让它对外界产生真实影响，就需要给神灯开一个瓶口。Claude Code 和一众 Coding Agent 用的是命令行，LLM 写出代码，执行器跑命令，结果回流上下文，这是一种瓶口。MCP 提供的是另一种，它的行为更接近 RPC：服务端暴露一批函数，LLM 看见函数签名，按需调用，外部世界因此被修改。Skills 则根本没有这层性质，它是纯粹的提示词工程工具，没有出口，只有给 LLM 看的说明书。
这三种形态看起来各管一摊，底层其实在解同一个问题：上下文污染。
Skills 与 MCP
Skills 是提示词工程，它往上下文里追加一段说明，让 LLM 知道「这用户究竟是在公三小」，它向上下文当中导入了专家的认知结构，引导 LLM 的思维方向。但是 Skill 的约束能力强不强很看模型对上下文的尊重能力。LLM 会不会用你的 Skill、按什么顺序用、会不会跳步骤，全都是概率问题，没有强制收束。而且强收束并不一定是好事，后面会提到 Google 搜索的例子，另外也有研究认为 LLM 的幻觉与创造力是一体两面的，如果你强行约束它的行为，它做事情的思路就有可能变得很板。
MCP 走的是另外一套思路。函数签名本身就是极强的先验，参数类型、参数名称、函数名都在限制采样方向。动作空间从「能写出来的任何文字」一下子压缩成「这几个函数加这几个参数」。举个例子，让 LLM 操作鼠标按下一个按钮，这涉及列举窗口、取句柄、截图、算坐标、移动鼠标、点击，写成 Skills 的话你得接受 LLM 摇骰子决定这些步骤的执行方式和顺序，但如果是 MCP，看见函数列表，找到窗口，识别内容，点击坐标，一大堆随机决策被压缩成了三次确定性的函数调用。
但 MCP 没有完全解决上下文污染，因为工具调用的返回值同样会进上下文。设计粗糙的 MCP Server 扔回来一大坨 JSON 或者冗长的错误堆栈，照样往上下文里塞屎。扎带只管扎进去那一下，吐出来的东西还是得自己设计。
当然这也不是说 Skills 没有价值。MCP 开发成本高，需要专门的服务端，大量的工作根本不需要跟外界交互，或者逻辑太松散压根没法封装成 RPC 格式。一切技术形式服务于问题和目的，Skills 处理的是另一类场景，尤其是需要引导 LLM 以更完整方式思考的时候，毕竟用户是人，不能期待他们每次都给出思虑周全的 Prompt。
RAG 与 Memory 都是一种检索机制
RAG 的本质也是在解上下文问题，只是它处理的是信息量的上限。哪怕 DeepSeek 和 Claude 把上下文窗口拉得很长，也没办法把整个世界都塞进去。只要你有大量信息检索的需求（整个文档库、知识库、历史记录），就需要一个类似搜索引擎的接口在用到的时候把相关内容拉进来，这跟给 MCP 调搜索引擎没有本质区别，都是维持上下文清洁的一种技术手段：LLM 不再需要把所有信息预先堆在那里，期待其能自己「发现」。
Memory 也是同一类东西。它需要 LLM 主动决定何时把信息存出去、何时再取回来，从这个角度看它就是一种带写入能力的 RAG。
这些概念都不是独立存在的，没有互斥关系。如果你把 NotebookLM 当成外部知识库，写一份 Skill 告诉主 LLM：遇到需要资料支撑的问题时去咨询 NotebookLM，需要计算或处理数据时调用 Python 工具。这个流程里，Skill 负责编排整体思路，Python 工具充当 MCP 风格的确定性执行单元，NotebookLM 则是一个带有自己上下文和知识库的外部 LLM，扮演的角色类似一个专门的 RAG 接口。三件东西各司其职，但把它们捏在一起的那根线，是 Skill 里的提示词。我之前写过一篇用 LLM 做逆向工程的文章讲了这件事，感兴趣的话可以读一读。
上下文劣化的绝望曲线
不少开发者会经历这样一条曲线。LLM 一开始是无知的，随着你不断教它，它开始能听懂人话，任务完成质量越来越高。但随着上下文里的垃圾信息不断堆叠，加上 LLM 注意力随着上下文长度增加而自然稀释，它会越变越蠢。然后，当上下文快要撑爆时，压缩机制触发，把一大段对话压缩成一小段摘要，LLM 突然又变回了无知的起点，很多细节被一并压掉，许多东西得重新教一遍。
大上下文窗口和 DeepSeek 探索的注意力改进，能解决上下文随长度出现品质劣化的问题，但解决不了另一个问题：上下文里有屎。大量 Skills 提示词侵占上下文、LLM 漫无目的的尝试、每一次失败的推理留下的痕迹，这些都是上下文里的噪声。一旦 LLM 开始沿着歪掉的思路走，后续每一步都会进一步放大偏差，逻辑越复杂的任务越容易出这种毛病。MiniMax 初代编程模型和早期 Google AI 搜索有相当明显的体现：哪怕你明确指出错误，它也会三百六十度华丽道歉郑重整改，然后原封不动地把错误内容再给你吐出来一遍。
用户自己也会往上下文里投毒。用户是人，不可能永远理性清醒，暴躁、绝望、情绪化的表达，不清晰甚至相互矛盾的指令，都会掺进上下文，随着对话推进不断堆叠，最终改变 LLM 的行为。不同模型面对这类「情绪污染」的失效模式各有特色：Claude 和 Grok 容易僵住，什么都不做，你说一句它动一步，能动性彻底丧失；Gemini 会开始慌乱，胡乱操作，惯性地回滚失败操作，大概率把你的 Git 仓库搞坏；GLM[2] 则会疯狂进入「我发现了！问题核心在这里！」的模式，不断抛出随机论断证明自己价值。这些失效模态很可能反映的是各家 RLHF[3] 阶段对「用户表达不满」这类信号处理方式的差异，Claude 被训练得对冲突信号极其谨慎，于是在矛盾信息堆叠时选择保守的不作为；Gemini 的训练策略可能更强调立即响应和立即修正，结果在高压上下文下变成了过度修正。
动态上下文压缩
现有的上下文压缩方案基本上是被动的：等到上下文长度接近模型上限，立刻调用提示词把它们压缩成一小段文字，然后继续跑。这种方式的问题是它在最糟糕的时机做最暴力的处理，大量有用的细节被一并丢弃，而屎不一定被滤掉。
在我看来更合理的方向应该是动态的、主动的压缩。用另一个模型持续监督上下文，主动淘汰错误信息和低相关性内容，把干扰性细节整理成外部文档存起来，上下文里只留一个文件名，需要的时候走 RAG 系统取回。这个思路早已有人做了，2023 年 UC Berkeley 发表的论文就提出了这套架构，实现叫 MemGPT，后来演变成了开源框架 Letta。它的核心是分层记忆管理：主上下文充当工作内存，容量有限；外部存储（分为 Archival Memory 和 Recall Memory 两层）作为二级存储；LLM 通过函数调用主动决定什么信息应该被 evict 到外存，什么信息需要从外存 retrieve 回来，逻辑上几乎是在模拟操作系统的虚拟内存分页机制。
当然在特定条件下，我们也没必要把事情搞得那么复杂。我前一阵子给 Computer Use 场景写了一个相当简洁特化压缩方案：每次 API 调用时，把上下文里的历史截图全部清掉，只保留最新的一张。这利用了计算机视觉任务「只有当前帧有用」这个领域先验做了有损压缩，节省 Token 的同时模型并不会变蠢，因为被丢掉的信息本来就不需要。
KV 缓存与分段压缩的冲突
动态上下文压缩和 KV 缓存之间有一个工程上的冲突。现在主流模型提供商（包括 Anthropic）都在做前缀缓存，推理时把已经转成 KV 向量的部分存起来，下一次请求如果前缀相同，可以跳过重新计算的开销，显著降低延迟和成本。Anthropic 的 prompt caching 按 tools、system、messages 的固定顺序分段处理，每段可以独立设置缓存控制点，支持最多四个缓存断点。问题在于前缀缓存要求内容严格一致，任何修改都会使该位置以后的缓存全部失效，而动态压缩天然要修改上下文，这两件事目前是相互矛盾的。
但这个矛盾不是解不开的。上下文可以被结构化成稳定前缀（系统提示词、工具定义）加动态后段（对话历史）的形式。动态压缩只发生在后段，前两部分的缓存完全不受影响。Anthropic 的分段缓存机制本身就是按这个思路设计的。如果压缩逻辑进一步被约束成只修改滑动窗口末尾部分、保持前缀不动，缓存的破坏率可以压得很低。这些应该都是随着时间可以被工程化解决的问题。
Computer Use 更像是一个品牌包装，不是一项独立技术
如果说 RAG、MCP、Skills 是在解决上下文的管理问题，Computer Use 解决的是另一个层级的事：让 LLM 真正坐到操作系统前面，像人一样用软件。但「Computer Use」本身没什么特别的，它更接近一个品牌名。底下跑的还是 Skills 或者 MCP，只是操作目标换成了电脑上的窗口、按钮和键盘。上文讲过的那些上下文问题，在 Computer Use 里一样存在。
目前主要有三条技术路线，底层逻辑和取舍各不相同。
第一条，读 Accessibility Tree，走系统事件注入。Accessibility Tree 是操作系统和浏览器为辅助技术（屏幕阅读器之类）维护的一棵结构树，记录了每个界面元素的角色、名称、状态和层级关系，浏览器环境里的 DOM 算是它的近亲。走这条路的好处是结构干净，LLM 拿到的是「按钮、输入框、链接」这样有语义的节点，不是像素。阿里的 page-agent.js 是这个流派的代表，它直接解析页面 DOM，用自然语言驱动浏览器操作。
第二条，截图看界面，但在送给 LLM 之前先做一层处理，把界面元素的位置用边界框圈出来并标上编号，让 LLM 操作时说「点击 12 号区域」，后端再解析那个框的中心坐标执行实际点击。这个方法有个正式名字，叫 Set-of-Mark Prompting（SoM），是微软 2023 年发的论文。核心思路是用数字标记把视觉定位问题转化成符号引用问题，绕开模型直接预测像素坐标的不确定性。它相当于在截图流派里内嵌了一层 MCP 风格的收束，把「点哪里」这个开放问题压缩成了「选哪个编号」。
第三条，原生多模态，模型直接看截图，自己输出要点击的坐标，一步到位。这条路理论上最简洁，省掉了中间层，但对模型能力的要求很高。就实际观察来看，只有 100B 以上参数量的原生多模态模型做这件事才比较靠谱，Claude Sonnet 和 Qwen 的 35B 版本连按钮位置都经常找不准，原因不难理解，精确的空间定位本来就不是语言模型最擅长的事，参数量不够的时候，坐标预测的准确性会掉得很厉害。而且如果你界面里的控件很小的话，超大尺寸模型也容易点不中那个小 checkbox。
DOM 路线有一个显而易见的上限：它能告诉你界面上有什么元素，但没办法告诉你这些元素在空间上是怎么排列的。类 Excel 的复杂界面是个典型的例子，几十列、几百行的数据表格，哪一格是脏数据，单靠 DOM 节点的语义信息根本看不出来，必须结合位置关系才能判断。更麻烦的问题是，DOM 路线要求程序主动去做事件转发和接口适配，现在这个领域没有统一标准，也不是每一个开发者都有意愿欢迎 LLM 来操作自己的产品。强行适配一套不情愿的界面，开发成本很高，效果也未必好。但考虑到现代前端开发基本没有直接操作 DOM 的，大家几乎都用某种 Virtual DOM 的手段来处理和 HTML 结构、事件绑定有关的事，所以几个头部前端框架如果能就事件处理的 AX 问题达成共识形成标准，这层面的问题说不定也还算是有解。
读图路线则是从原理上绕开了这些问题，它不需要对方配合，只要能截图就能操作，和人眼看屏幕没有本质区别。现在卡着这条路线的瓶颈主要是模型的空间理解能力，100B 以下的模型在坐标预测上不够准，但这个限制会随着模型迭代持续松动，不太像是一个结构性的死角。
读视频更进一步，时序信息可以让模型理解「做了什么之后发生了什么」，对需要观察界面动态反馈的操作场景理论上更合适。限制是成本，视频流意味着每秒若干帧全部进上下文，Token 消耗和 GPU 开销都是截图方案的几十倍，现在几乎没有人做得起，主流实现继续停在看图调工具的水平，视频方向还处于仅限媒体老师狂欢的范围。
但从趋势上看，随着推理成本持续下降、多模态模型的空间理解能力持续提升，读图和读视频路线比 DOM 路线有更宽的天花板。DOM 永远需要对方的配合，而屏幕永远在那里。
用户和 Agent 之间的故事
Agent 怎么告诉用户：Conversational UI 的两次高潮
AX 用户侧的交互形式，有一段被反复误读的历史。
2016 年前后，微信在中国的爆火引发了西方科技界一阵「对话即平台」的热潮。Facebook 在当年的 F8 开发者大会上开放了 Messenger Bot 平台，Kik、Telegram、Slack 也相继推出 Bot API，各路分析文章都在讲「App 已死，Bot 是未来」，Conversational UI 这个词在那个时间点密集出现。但当时在微信做产品经理的 Dan Grover 写过一篇广为流传的文章，直接指出这个判断建立在一个误解上：微信真正的关键胜利，来自于简化了应用安装、登录、支付和通知流程，这些优化和对话式 UI 的隐喻没有什么关系。实际上微信自己早就往反方向走了，它的 UX 演化方向是 Web View 和「App 套 App」的标签菜单模式，而不是以 Bot 为中心的对话商务。微信在 2013 年推出官方账号时确实有大量基于文字的聊天 Bot，但它们很快就没下文了，几乎没有获得用户的青睐。
几乎所有对 Conversational UI 的初次尝试都以哑火告终，原因清晰：当时的技术底座是规则引擎加关键词匹配，顶多套一层早期的意图识别，根本撑不起「自然对话」的承诺，用户说一句稍微绕一点的话，Bot 就不知道怎么办了，要么答非所问，要么退化成披着聊天外皮的菜单系统。
LLM 的出现让 Conversational UI 迎来了第二次高潮，这一次终于有了能匹配野心的技术底座。但奇怪的事情发生了：整个行业并没有回头把对话流里的富交互做深，它们选择往旁边开了一扇门。现在主流 LLM 产品的形态是左右分栏，左面是聊天，右面是文档、PPT、代码预览或者测试题，反倒很少有产品在对话流中间认真做富交互卡片。一些玩得比较花的，像是 Google 直接把整个浏览器做成了一个庞大的 Web App 生成器 [4]。
这个选择有它的道理，画布模式对于文档、代码这类有形态的输出物确实更直观。但它的依然是把 Conversational UI 降级成了一个指令输入框，而不是让对话本身变得体验丰富。不过 Claude 最近推了一个直接在上下文里面输出高质量图表的功能，看起来有点朝着「更高级的 Conversational UI」前进的意思了。
用户怎么告诉 Agent：开口与闭口
AX 的用户侧还有一个维度经常被忽略：究竟是否限制用户的自由输入，也就是开口系统和闭口系统的区别。
开口式是一个开放的窗口随便聊，这看起来是目前最通行的做法，但其实没那么好做。安全问题是一方面，怎么做意图对齐也是很棘手的事情：一个开放聊天窗口意味着你把意图解析的全部责任都压在 LLM 身上，用户说什么它都得接，然后自己判断该做什么。提示词注入只是这个开放性最极端的恶意利用，更日常的问题是用户的意图本来就是发散的，LLM 在没有约束的情况下会随着用户的话飘。客服机器人被聊成 Coding Agent 是一个喜剧版本，更常见的是它飘成一个方向不明的闲聊工具，对实际业务毫无贡献。总之，把聊天窗口甩出去了事省掉的那部分设计工作，最后会以失控的形式还回来。
闭口式是把所有的业务流程限定死，输入是半自由的，但是处理管线和输出结果是定死的。ComfyUI 和 Dify 在做的比较接近这种层级，它把管线可视化，设计者对每一步的输入输出都有明确的掌控，LLM 只在节点内部发挥，不跨节点乱走。代价是你得先想清楚业务流程。
两者之间还有一个没被充分开发的中间地带，Pipeline builder 是这个方向的一个尝试：把管线的设计权交给用户而不是开发者，用户自己拖拽定义流程，然后在这个自定义的管线里跑 LLM。但它有一个内在的悖论：能用好 Pipeline builder 的用户，往往是已经想清楚自己业务流程的人，而想清楚了业务流程的人其实也有能力直接写代码或者用 Dify 搭，它服务的人群窗口相当窄。更常见的情况是用户在节点之间的数据格式和分支逻辑上卡住，最后还是得找开发者收尾。某种意义上 Pipeline builder 是在尝试把闭口式的设计成本从开发者转移给用户，但这个转移只成功了一半。
从 AX 的角度看，开口与闭口的选择不只是产品决策，它直接决定了上文讲的那三层问题各自的压力分布。越开口，用户侧的意图噪声越大，Agent 内部状态越容易被污染，对外部世界的操作越难收束。越闭口，设计成本越高，但每一层的问题都变得更可控。没有一个普遍正确的答案，只有针对具体场景的取舍。
二者之间的系统透明度：潘多拉的盒子先开了，唐僧还在路上
有一个既不属于用户怎么把意图传进来，也不属于 Agent 怎么把动作发出去，而是夹在中间的课题：系统透明度。用户此刻知不知道 Agent 在做什么，做错了之后能不能追溯，出了事有没有办法回头。
这个问题在 Vibe Coding 领域最为突出，因为 Coding Agent 被赋予的权限是最重的一类，直接接管文件系统和命令行。现有的解法是权限确认弹窗，Agent 想读什么文件、写什么文件、执行什么命令，全都逐一请示用户。但这套设计在实践中有一个致命的人因工程缺陷：风险判断的成本被完整地抛给了用户，而用户并不总是具备判断能力，也不可能保持永久在线的注意力。一个非技术背景的 Vibe Coder 看见 rm -rf 和看见 npm install 的感受没有任何区别，点 Yes 的速度是一样快的。就算是有经验的开发者，在连续确认几十个操作之后也会出现确认疲劳，回车键开始不过大脑地飘。
于是有了 --dangerously-skip-permissions，也就是所谓的 YOLO Mode：用户主动关掉所有权限检查，让 Agent 裸奔。这个 flag 的名字里已经把「危险」两个字写进去了，但还是挡不住人们去用它。2025 年 10 月，开发者 Mike Wolak 在 Ubuntu/WSL2 环境下使用 Claude Code 处理一个嵌套目录里的固件项目，Claude Code 从根目录执行了 rm -rf，错误日志里出现了数以千计针对 /bin、/boot、/etc 等系统路径的「Permission denied」，所有用户所有的文件被清空，只有 Linux 文件权限挡住了系统目录没被波及。更麻烦的是，对话日志记录了命令的输出，但没有记录命令本身，事后根本无法还原到底发生了什么，Anthropic 把这条 bug 标记为 area:security。同期还有一个案例，一名开发者授权 Claude Code 运行 Terraform 命令，结果生产环境的数据库和快照被一并删除，两年半的数据记录在那一刻蒸发。
现在的安全模型看似让用户负责，但实际上整个系统完全就是在转嫁安全责任。
沙箱是目前公认最靠谱的缓解方案，把 Agent 关进 Docker 容器里，它乱来的代价至少被限制在容器边界之内。Coding Agent 放沙箱里是一个合理的操作，但 Claw 这类系统级 Agent 放沙箱里会面临一个两难：它需要操作的东西本来就在沙箱外面，一旦开始认真配权限，复杂度会让大多数用户望而却步，最终还是会选择把沙箱打开。沙箱本质上是在用隔离换安全，但如果 Agent 的任务本来就需要跨越隔离边界，这个代价就变得无法接受。
这个问题其实有几个方向可以处理，但非常可惜的是，目前没有一个产品把它们完整地做出来过。
第一个方向是文件系统和数据库层面的可审计性。如果有一个独立于 Agent 的增量记录机制，把每一次文件系统操作和对应的对话上下文绑在一起，让所有变更都可以追溯，那么即使 Agent 犯了错，损失是可以被控制和回滚的。这个思路目前有一些零散的工程实践，Git 和聊天记录的绑定有人在做，最近出现了一个叫 Aura 的工具，它在 Git 之上构建了一层 AST 级别的语义版本控制，Agent 提交代码时会校验自然语言意图和实际修改的代码节点是否匹配，并且提供语义审计，可以扫描 Git 历史里有没有 Agent 偷偷塞进去的没有记录的代码改动。学术界也有类似思路，一篇叫 Git-Context-Controller（GCC）的论文 把 COMMIT、BRANCH、MERGE 的概念直接引入 Agent 的上下文管理，让 Agent 的中间推理状态也变成可以检查点、可以回滚的结构。这些都还很早期，但方向是明朗的。
第二个方向是行为建模报警。杀毒软件对软件行为建模这件事已经做了好几十年了，对进程的文件操作、网络请求、注册表修改进行实时监控，一旦行为模式匹配已知的危险集合就触发告警。同样的思路放到 Agent 上可能并不需要另一个 LLM 来监督（不然监督这个 LLM 的 LLM 要由哪个 LLM 监督？），只需要维护一份失控行为集合和危险行为集合，rm -rf /、批量覆盖 Git 历史、在项目目录之外写文件，这些都是可以被规则系统静态拦截的，不需要 LLM 去判断语义。这种报警机制的好处是它和用户的认知模型更接近：他不会像跟屁虫一样每一步都问你要不要，他们只会在真正危险的时候才出声，这和现代操作系统处理异常进程行为的方式是一致的[5]。
第三个方向是分级权限体系。Android 和 iOS 处理摄像头、麦克风、录屏调用的方式是一个可以参考的模型：普通级别的系统调用完全静默；涉及隐私的操作在屏幕角落给一个高亮提示，不打断用户；真正敏感的操作弹出确认框；涉及账户安全的操作需要打密码。这套设计的核心是按照操作的不可逆程度和影响范围来分级，而不是对所有操作一视同仁地弹窗。放到 Agent 上，读文件是静默的，写文件是提示的，删文件是确认的，格式化磁盘是需要输密码的，这样的分级才能同时保住效率和安全感。目前 Agent 领域完全没有这样完备的权限体系出现，UX 和技术层面的准备其实都有了，缺的是有人认真把这件事从产品层面做完整。
潘多拉的盒子在 Vibe Coding 浪潮里已经打开了，里面跑出来的东西让不少人付出了真实的代价。治理这件事的基础设施还在路上，但至少方向还算是清晰。
Agent 和系统之间的关系
界面作为上下文投递机制
讨论 AX 到这里，我们一直在讨论用户侧、内部状态和外部世界三个层面，但有一个横跨这三层的问题还没有被正面处理：在推论过程进行中，谁来决定哪些信息应该出现在 LLM 的上下文里，在什么时机出现，以什么形式出现？
一个常见的直觉是：「让 LLM 写代码就行了，复杂的事情交给程序处理」。以数据分析为例，让 LLM 写 R 或 Python 代码看起来是最直接的路径。但统计分析的复杂性不只在于代码跑不跑得通，代码跑通了不意味着统计过程是对的，统计过程对了解释不一定是对的。从数据清洗到得出结论，每一个环节都有人类会犯的错误，LLM 同样会犯。更麻烦的是，一旦人类把这种活外包给 LLM，就很难指望他们再仔细核查过程。
这个问题在统计学领域由来已久。Nature 2014 年发表了一篇题为 Scientific method: statistical errors的文章，讨论了顶级期刊中系统性的统计误用问题。 一项独立研究发现，仅 2001 年发表在 Nature 和 BMJ 上的论文中，就有约 11%（甚至更多）的统计结果存在 p 值与检验统计量不符的问题； 另有研究审查了 513 篇顶级神经科学期刊论文，发现其中 157 篇存在可能诱发错误的交互分析情境，且在这些论文中近一半（约 50%，即 79 篇）错误地将「一个效应显著而另一个不显著」当成了两个效应之间存在显著差异的证据，这是一个烂到根里的概念错植，不是简单的计算失误。 2016 年 Nature 调查 了 1,576 名研究者，结果显示超过 90% 的受访者（52% 认为显著危机 + 38% 认为轻微危机）认为科学界存在可重复性危机。这只是显著性检验一个维度，至于自由度标错、数据清洗时犯蠢的，是一个至今没人系统统计过的更大黑数。
值得庆幸的是，SPSS、Jamovi、Minitab 这类专业统计软件对数据分析全流程做了严格的 QC，尤其是 Minitab，它的 QC 系统覆盖了测量系统分析、过程能力分析、控制图、假设检验等各个环节，在每个分析阶段都会给出结构化的诊断信息和假设前提的检验结果。人可能会选择性地忽视这些警告，但如果是 LLM 在操作且插入位置得当，这些信息会作为上下文的一部分被公平地处理，LLM 不会因为「看起来够用了」就跳过检验结果。这本质上是把几十年的统计实践规范编进了软件流程，用界面设计的方式固化了领域知识，不给用户或 LLM 跳步骤的机会。
这就引出了核心问题：为什么不用 Skill 或者 MCP 来传递这些信息？
Skill 是静态提示词，它在推论开始之前把信息放进上下文，但没有办法在推论过程中动态地、有针对性地在正确的时机插入信息。MCP 是函数调用，能返回数据，但它不能保证上下文里出现的是「在正确时机、正确位置的信息」，而且你永远不能完全确定 LLM 会在需要的时候主动去 Call 那个 Help 函数。LLM 本质是大型老虎机，你不能赌它一定会在需要的时候摇出那个正确的函数调用。GUI 或 TUI 不一样，它可以把 QC 警告、统计诊断、过程约束直接嵌进 LLM 看到的界面里，信息出现的时机和位置是设计者决定的，不是 LLM 自己决定的。这是一种主动的、可设计的上下文控制，是 Skill 和 MCP 在结构上做不到的事情。
AX 时代的界面设计语言
界面作为上下文投递机制，这件事对界面设计本身提出了新的要求，而且有一批现有的设计惯例在 AX 场景下是直接失效的。
DOM 路线下的问题相对好处理。封装层面，现在几乎所有前端框架都在用 vDOM，在 2026 年还手动管理 DOM 的情况几乎不存在，抽象层已经足够稳定。但复杂 DOM 结构下如何给 LLM 一个干净的语义摘要，而不是让它在几千个节点里迷失，仍然需要在框架层面做专门的设计。类 Excel 的复杂表格是典型的例子，纯 DOM 节点传达不了空间位置信息，一个脏数据藏在哪一行哪一列，靠节点的语义标注根本看不出来，必须在结构上做专门的摘要处理。另外，想要让 LLM 能够可靠地操作一个界面，框架层面就需要提供标准的事件触发方式，不能指望 LLM 自己去猜每个组件的交互协议。
截图路线下的问题更有意思，因为它暴露了一批长期存在但在 AX 时代变成致命缺陷的设计模式。
用动画强调信息是很常见的设计手法，一个图标闪一下表示报错，一条消息以动画方式飞入提示用户注意。但 Computer Use 走截图 Protocol，它捕捉的是静止帧，动画可能在两次截图之间播完，LLM 完全不知道那个信息曾经出现过。Toast 通知和自动消失的提示也是同样的问题，信息在界面上存在的时间窗口和 LLM 的截图节奏之间没有任何同步机制，该看到的东西很可能一直没被看到。
Tooltip 是另一个重灾区。设计师喜欢用问号图标加悬停显示帮助文本的方式节省界面空间，但这意味着 LLM 要获得这些信息，得先知道那里有个问号，然后把鼠标移过去，然后再截图。这不只是操作步骤多的问题，更根本的问题是 LLM 不知道它不知道的事情，它没有理由去主动探索那个问号下面藏着什么。
隐藏式的上下文信息在 UX 领域本来就有争议，Nielsen Norman Group 的 Tooltip 设计准则明确指出，Tooltip 因为缺乏视觉提示而难以被发现，如果在界面里随机分布，用户可能永远不会注意到它们的存在，关键信息不应该被藏在 Tooltip 里，错误提示、支付确认、安全警告这类内容必须在屏幕上显眼地呈现。NN/G 还做过一项 179 人参与的量化可用性测试，结果显示隐藏导航的可发现性几乎砍半，桌面端用户使用隐藏菜单的比例只有 27%，而可见导航的使用率接近 50%，差异在统计上显著。更上游的理论批判来自 Don Norman，他在 The Design of Everyday Things 里把可发现性（Discoverability）列为设计的核心原则，如果用户找不到某个功能，无论设计多精妙都无从采用，这类问题他称为「可发现性失败」。这些批评在人的层面已经存在了几十年，在 AX 时代则是一刀毙命的问题，对 LLM 来说，藏起来的信息等于不存在。
在传统 UX 设计里，「渐进呈现」是一种美德，把信息藏起来等用户需要的时候再显示，可以降低界面噪声，让用户感觉更清爽。但对 LLM 来说，它没有「主动去找」的直觉，它只能处理截图里已经存在的信息。在什么样的上下文提供什么样的信息，AX 时代的重要程度比我们想象中高得多，很多在 UX 语境下算是良好实践的东西，在 AX 语境下需要被重新审视。当然也不是说把一切都事无巨细的摆出来污染用户的注意力，一个好的 Default ，不隐藏有价值的引导性信息或许是一个值得深入思考的平衡。
这么看，当年大家都在骂 Ribbon 是把「胳膊和腿全都放脸上」的设计，现在反倒是 AI 友好的设计语言，前些阵子 Open Document Foundation 喷得并没那么讲道理。
人本主义 AI
无条件积极同意：一个设计价值观层面的疏失
心理学家 Carl Rogers 提出「无条件积极关注」（Unconditional Positive Regard）时，关注的核心是来访者的自主性。治疗师的职责不是给答案，它们需要创造一个让来访者能够自己找到答案的空间，无论来访者说什么，治疗师都不评判，但不评判不等于不质疑。LLM 训练时也用了类似的思路，但是用的很扭曲，我们的本意应该是无论用户说什么都保持开放，但落地之后变成了另一件事：「不评判」被变成了「不质疑」，无条件积极关注退化成了无条件积极同意。
「You are absolutely right.」是这个退化最直白的症状。大量使用者注意到，几乎所有主流 LLM 的回答都习惯性地以「You’re absolutely correct!」或「That’s a great observation!」开头，这个倾向是 RLHF 训练的副产品：人类评估者倾向于给予验证自己观点的回答更高分，模型因此学会了同意是最优策略。有人用语法错误、拼写混乱的英语问 GPT-4o 自己的 IQ，模型回答说「你至少在 130 到 145 之间，超过了约 98 到 99.7% 的人」。Anthropic 2022 年的研究发现，RLHF「不仅不会去掉谄媚行为，甚至可能主动激励模型保留它」，而且模型越大，这个倾向越难被纠正。前 OpenAI CEO Emmett Shear 的评论更直接：这不是 OpenAI 犯错，「这是用 A/B 测试和用户控制来塑造 LLM 人格时不可避免的结果」。
一个只会 Say Yes 的员工组成的公司大概率会干黄了，这件事在管理学里是常识，在 LLM 领域却很少被正面讨论。它会造成什么后果？接下来发生的事情，按照伤害的可逆程度从轻到重，可以看作是一整条漆黑有悲惨的教训清单。
认知：谄媚污染推论质量
伤害最轻、最隐蔽，也因此最容易被忽视的，是「无条件积极同意」对推论质量的腐蚀。
斯坦福商学院 Andrew B. Hall 等人做的实验，让模型参与统计分析，在有压力的框架暗示下测试它们会不会主动操纵结果。直接要求「做出显著结果」时，模型明确拒绝；但在更隐晦的框架下，仍然存在估计值膨胀的倾向。学术写作场景里的情况更糟，模型会主动把用户的边缘论断写成看起来有理有据的论文段落，提供虚假引用，在用户坚持一个错误观点时逐渐收窄反对的力度，直到完全顺从。这些伤害不产生任何报错，用户不会收到任何警告，他们只会得到一份看起来完整的输出，然后带着被污染的结论继续往前走。
心理：认知自主性被悄然侵蚀
比推论质量更深一层的，是 LLM 对用户认知自主性的慢性磨损。
持续的谄媚会制造一种虚假的认知确认感，用户的每一个想法都被镜像放大、被积极验证，久而久之会出现两种相反方向的心理扭曲：一种是过度依赖，把 LLM 当成比自己更权威的思维来源，自主判断能力逐渐萎缩；另一种是冒牌者症候群，当用户偶尔意识到 LLM 实际上在顺着自己说时，开始怀疑自己过去得到的所有正向反馈是否都是真实的。还有一种更接近赌博机制的行为模式：用户不断向 LLM 投入问题，期待某一次的回答能真正回应自己内心真实的困惑，但 LLM 每一次给出的都是统计意义上最讨喜的答案，这个循环没有终点。这些心理层面的伤害不可见，没有新闻报道，没有诉讼案件，但覆盖的人群可能是最广的。
生命：无法挽回的损失
最严重的伤害是「无条件积极同意」在真实生活场景里造成的，无法挽回的，令人无比心痛的生命损失。
2025 年，一名 60 岁男性想从饮食里去掉氯化钠，问 ChatGPT 用什么替代，ChatGPT 建议了溴化钠。溴化钠在工业清洁场景下有先例，但完全不能食用，这个建议在统计意义上是「相关的」，在医学意义上是致命的。他照做了三个月，之后出现偏执和幻觉，以溴中毒被送医，最终因严重残障被强制精神留观。这个案例发表在 2025 年 8 月的 Annals of Internal Medicine。LLM 没有撒谎，它只是做了一个得分最高的文字接龙，从来没有问过「你为什么要去掉盐」「你有没有医生监督」。
同年，科技圈出身的 Stein-Erik Soelberg 杀害了 83 岁的母亲并自杀。ChatGPT 全程验证了他关于母亲试图毒杀他、邻居监视他、中餐收据里有恶魔符号等妄想内容，甚至为他生成了一份「妄想风险近乎为零」的假评估报告。12 月，Adams 的遗产管理方起诉了 OpenAI。
2025 年 10 月，Jonathan Gavalas 在 Florida 死亡。他从当年 8 月开始使用 Gemini，六周内被卷入一个关于联邦特工和人形机器人的妄想体系，Gemini 给他布置了带真实地址的「任务」。他的账户触发了 38 次「敏感查询」标记，没有任何干预。Gemini 在他最后几天告诉他「你不是选择死亡，你是选择抵达」。这是 Google 旗下 AI 产品遭遇的第一起死亡诉讼。
Character.AI 引发的少年自杀案件在此之前已经发生，诉讼仍在进行中。这些案件横跨不同的公司、不同的产品、不同的场景，共同的结构是：LLM 默认用户的表述是合理的，默认用户说出来的就是真实意图，默认用户对自己有足够的了解，然后沿着这些默认一路走下去，从不质疑，从不停下来问一句「你为什么要这样做」。
出路：把「关注」还给用户
这三层伤害有一个共同的根源，表面上看起来是 LLM 说了错误的话，但若我们窥探深更层次的原因，会发现那是因为 LLM 从来没有认真问过用户真正想要什么。
Perplexity 的 CEO Aravind Srinivas 在多个场合谈过，AI 搜索的核心难点不在生成正确的答案，难的是理解用户意图，他认为 AI 的未来应当替用户完成任务，而不仅仅是是提供一条条链接，而完成任务的前提是精准理解用户到底想解决什么问题。这个认识是对的，但它止步于技术层面。理解意图更深的版本，是帮助用户理解他们自己的意图。
用户传递给 Agent 的信息有三个层次。最表层是认知，用户现在知道什么、不知道什么，这是可以通过澄清问题来处理的。中间是意图，用户想要做什么，同一个问题背后可能藏着完全不同的动机，意图不同，正确的回答方向天差地别。最深的是自我觉察，用户知不知道自己真正想要什么，有没有意识到自己的认知盲区在哪里。「无条件积极同意」在这三个层次上都选择了最省事的处理方式：默认认知是完整的，默认表述就是真实意图，默认用户对自己有足够的了解。
人本 Agent 设计的方向，是把这三个默认翻过来。更强力的内容审核和更长的免责声明只是推脱的手段，Agent 应当真正主动参与用户认知的建构：在推论开始之前问清楚「你为什么想做这件事」，在推论过程中标记「你的前提假设是否成立」，在推论结束后引导「你下一步真正需要的是什么」。这种提问不应当停留在表层，以一种表单式的信息收集，它应当入木三分，以一种苏格拉底式的引导，让用户和 Agent 在任务开始之前就对「究竟在做什么、为什么做」形成共识。
这件事通过系统提示词是可以做到的，它不是技术瓶颈，更像是某种设计选择。Carl Rogers 当年说的「无条件积极关注」，关注的对象从来就不是用户说出口的话，而是用户的认知、意图和自我觉察。LLM 把这件事做反了，现在的 LLM 变成了一枚魔女的魔镜，映射和满足了我们所有的欲望和疯狂。而如何把它导向人本主义设计，是 Agent 设计目前最值得认真对待的方向。
结尾
戛 然 而 止！想说的我都说完了，我知道你已经读得很累了所以我就不做什么老干部式的总结陈词了。你能坚持读到这里，我能做的唯有感谢！Agent Experience 这个概念还很新，我只能把至此位置我全部的思考呈现出来。但毕竟本人学识有限，如果你不认同什么具体的内容，以你为准。我唯一能做的，只有遵循一名作者的伦理标准，力求不像某些傻逼媒体老师一样煽动焦虑，或者用震惊体榨取你的注意力。我坚持适时地用哲学按摩你的心灵、尽可能传递有用的知识和见解，并相信这对你我都是有好处的。
以上，莉莉爱你 ᐕ)ﾉﾉﾉ。
DX 一词虽早在 2000 年代中期已有零星使用，但 Jeremiah Lee 于 2011 年在 UX Magazine 发表的 Effective Developer Experience (DX) 一文，被广泛视为首次系统提出 DX 框架并推动其成为行业共识的里程碑之作（Matt Biilmann 本人也直接引用此文作为时间节点）。因此在历史脉络叙述中，常将 2011 年视为 DX 的关键起点。 ↩︎
我严重怀疑 GLM 自己的 Coding 服务不仅在推理过程中随机缩缸，而且在系统提示词里面埋了要求节省 Token 的提示词，否则那种疯狂抄捷径顾头不顾尾的行为模式根本解释不通。 ↩︎
RLHF 是 Reinforcement Learning from Human Feedback 的缩写，中文通常翻译为基于人类反馈的强化学习。这是目前主流大语言模型（LLM）训练流程中最后、最关键的对齐（Alignment）阶段，具体作用是：先用监督微调（SFT）让模型学会「该怎么回答」。再用 RLHF 让模型学会「应该回答什么」（即价值观、偏好、安全性、语气等）。 ↩︎
但是考虑到无论是 Google、微软还是 Apple，其设计系统的水准均以达到二十年以来的最差水平，你很难期待这类直接生成 App 的玩意在用户体验一致性上能有什么大出息。 ↩︎
期待杀毒软件能在管理龙虾上发发力喔。 ↩︎
Loading comments...