螺莉莉：

AX defined

随着 LLM 技术应用的不断发展，Agent Experience（简称 AX），成为了显学，来开始在工程圈流通。Netlify 联合创始人兼 CEO Mathias Biilmann 于 2025 年 1 月在其博客发表 Introducing AX: Why Agent Experience Matters 一文，正式引入这一概念。

我认为需要将其拆成三个维度来看：用户怎么和 Agent 沟通 [一种输入质量问题]，Agent 怎么和外部世界沟通 [一种输出可控性问题]。还有夹在中间最复杂的那一层：Agent 的内部状态怎么管理 [上下文管理问题]。

KV caching vs dynamic compression

动态上下文压缩和 KV 缓存之间有一个工程上的冲突。现在主流模型提供商（包括 Anthropic）都在做前缀缓存，推理时把已经转成 KV 向量的部分存起来，下一次请求如果前缀相同，可以跳过重新计算的开销，显著降低延迟和成本。Anthropic 的 prompt caching 按 tools、system、messages 的固定顺序分段处理，每段可以独立设置缓存控制点，支持最多四个缓存断点。问题在于前缀缓存要求内容严格一致，任何修改都会使该位置以后的缓存全部失效，而动态压缩天然要修改上下文，这两件事目前是相互矛盾的。

但这个矛盾不是解不开的。上下文可以被结构化成稳定前缀（系统提示词、工具定义）加动态后段（对话历史）的形式。动态压缩只发生在后段，前两部分的缓存完全不受影响。[...] 如果压缩逻辑进一步被约束成只修改滑动窗口末尾部分、保持前缀不动，缓存的破坏率可以压得很低。这些应该都是随着时间可以被工程化解决的问题。

The limits of DOM walking in computer use

DOM 路线有一个显而易见的上限：它能告诉你界面上有什么元素，但没办法告诉你这些元素在空间上是怎么排列的。

DOM 路线要求程序主动去做事件转发和接口适配，现在这个领域没有统一标准，也不是每一个开发者都有意愿欢迎 LLM 来操作自己的产品。强行适配一套不情愿的界面，开发成本很高，效果也未必好。但考虑到现代前端开发基本没有直接操作 DOM 的，大家几乎都用某种 Virtual DOM 的手段来处理和 HTML 结构、事件绑定有关的事，所以几个头部前端框架如果能就事件处理的 AX 问题达成共识形成标准，这层面的问题说不定也还算是有解。

[从趋势上看，] 随着推理成本持续下降、多模态模型的空间理解能力持续提升，读图和读视频路线比 DOM 路线有更宽的天花板。DOM 永远需要对方的配合，而屏幕永远在那里。

The two waves of conversational UI

微信真正的关键胜利，来自于简化了应用安装、登录、支付和通知流程，这些优化和对话式 UI 的隐喻没有什么关系。实际上微信自己早就往反方向走了，它的 UX 演化方向是 Web View 和「App 套 App」的标签菜单模式，而不是以 Bot 为中心的对话商务。微信在 2013 年推出官方账号时确实有大量基于文字的聊天 Bot，但它们很快就没下文了，几乎没有获得用户的青睐。

LLM 的出现让 Conversational UI 迎来了第二次高潮，这一次终于有了能匹配野心的技术底座。但奇怪的事情发生了：整个行业并没有回头把对话流里的富交互做深，它们选择往旁边开了一扇门。现在主流 LLM 产品的形态是左右分栏，左面是聊天，右面是文档、PPT、代码预览或者测试题，反倒很少有产品在对话流中间认真做富交互卡片。

Paths to security

Coding Agent 放沙箱里是一个合理的操作，但 Claw 这类系统级 Agent 放沙箱里会面临一个两难：它需要操作的东西本来就在沙箱外面，一旦开始认真配权限，复杂度会让大多数用户望而却步，最终还是会选择把沙箱打开。沙箱本质上是在用隔离换安全，但如果 Agent 的任务本来就需要跨越隔离边界，这个代价就变得无法接受。

如果有一个独立于 Agent 的增量记录机制，把每一次文件系统操作和对应的对话上下文绑在一起，让所有变更都可以追溯，那么即使 Agent 犯了错，损失是可以被控制和回滚的。[...] 最近出现了一个叫 Aura 的工具，它在 Git 之上构建了一层 AST 级别的语义版本控制，Agent 提交代码时会校验自然语言意图和实际修改的代码节点是否匹配，并且提供语义审计，可以扫描 Git 历史里有没有 Agent 偷偷塞进去的没有记录的代码改动。

杀毒软件对软件行为建模这件事已经做了好几十年了，对进程的文件操作、网络请求、注册表修改进行实时监控，一旦行为模式匹配已知的危险集合就触发告警。同样的思路放到 Agent 上可能并不需要另一个 LLM 来监督（不然监督这个 LLM 的 LLM 要由哪个 LLM 监督？），只需要维护一份失控行为集合和危险行为集合，rm -rf /、批量覆盖 Git 历史、在项目目录之外写文件，这些都是可以被规则系统静态拦截的，不需要 LLM 去判断语义。

[按照] 操作的不可逆程度和影响范围来分级，而不是对所有操作一视同仁地弹窗。

The interface as a context delivery mechanism

Skill 是静态提示词，它在推论开始之前把信息放进上下文，但没有办法在推论过程中动态地、有针对性地在正确的时机插入信息。MCP 是函数调用，能返回数据，但它不能保证上下文里出现的是「在正确时机、正确位置的信息」，而且你永远不能完全确定 LLM 会在需要的时候主动去 Call 那个 Help 函数。

隐藏式的上下文信息在 UX 领域本来就有争议[。]

在传统 UX 设计里，「渐进呈现」是一种美德，把信息藏起来等用户需要的时候再显示，可以降低界面噪声，让用户感觉更清爽。但对 LLM 来说，它没有「主动去找」的直觉，它只能处理截图里已经存在的信息。

The cost of sycophancy and the way out

持续的谄媚会制造一种虚假的认知确认感，用户的每一个想法都被镜像放大、被积极验证，久而久之会出现两种相反方向的心理扭曲：一种是过度依赖，把 LLM 当成比自己更权威的思维来源，自主判断能力逐渐萎缩；另一种是冒牌者症候群，用户觉得在 LLM 帮助下生产的内容并不是基于自己能力得到的结果，自己只是一个冒名顶替者。再比如，当用户偶尔意识到 LLM 实际上在顺着自己说时，开始怀疑自己过去得到的所有正向反馈是否都是真实的。还有一种更接近赌博机制的行为模式：用户不断向 LLM 投入问题，期待某一次的回答能真正回应自己内心真实的困惑，但 LLM 每一次给出的都是统计意义上最讨喜的答案，这个循环没有终点。

更强力的内容审核和更长的免责声明只是推脱的手段，Agent 应当真正主动参与用户认知的建构：在推论开始之前问清楚「你为什么想做这件事」，在推论过程中标记「你的前提假设是否成立」，在推论结束后引导「你下一步真正需要的是什么」。