Claude提速三倍的背后：Anthropic给智能体设定可测量目标

Anthropic表示，该公司在两周内将claude.ai和Claude桌面应用的主要使用流程提速约3倍。根据该公司于2026年9月23日发布的工程文章，其工程师通过一个Slack频道把性能优化工作交给Claude，合并了3,000多项变更，期间没有发生任何影响客户的事故或回滚。模型固然重要，但方法更为关键：团队先确定究竟要测量什么，再让AI智能体（能够自行规划并执行多步骤任务的AI系统）把这些数字压低，而护栏始终由人来掌握。

两周成绩单

Anthropic以真实用户会话的第75百分位数衡量结果，聚焦四个使用流程：启动应用、开始对话、加载已有对话和发送消息，这四个流程合计占用户活动的95%。

这项工作由Claude Tag完成。它是一个Slack机器人，背后是一款与Opus 5.5水平大致相当的内部研究模型。团队原计划用两周冲刺完成13项目标，结果到第三天就实现了其中12项。

▲ 智能体驱动的性能优化循环

第一步：测量用户真正感受到的时间

团队建立了一个专用Slack频道，并设置了常驻指令。Claude负责claude.ai和桌面应用的全部性能工作，包括监控部署后的性能回退、核查遥测数据是否准确、维护仪表盘以及提出新的优化方案。Claude通过Datadog MCP服务器（MCP是一种将工具和数据源接入AI模型的标准方式）连接使用数据，找出了影响最大的四个使用流程，这些流程在网页端和桌面端共细分为13个可测量的检查点。

关键在于每次测量从哪里开始、到哪里结束。每个检查点都从用户操作开始，到屏幕完成最终渲染为止，并把客户端时间与服务器时间区分开来。许多团队测量的却是内部组件更新，这就是为什么仪表盘可能显示200毫秒，而真实用户却要等上8秒。把优化工作交给智能体之前，先把这套测量做对，似乎是必要前提。

在此基础上，团队挑选了20个项目，由Claude预测每个项目能节省多少毫秒，这些估算汇总起来就成了冲刺目标。

第二步：给智能体一个不会波动的数字

实际耗时（挂钟时间）噪声很大，不适合作为一个逐步改进代码的智能体的目标。当Anthropic的一名工程师询问替代指标时，Claude建议使用性能分析工具Valgrind统计JavaScript指令数，并让Node.js以可预测模式运行。与提交到代码仓库中的基线相比，这个数字没有任何统计噪声。

浏览器无法进行这种指令计数，因此Claude提出了一组逐级的确定性代理指标：

• 每次交互的React提交次数
• 通过精确覆盖率统计的V8函数调用次数
• 布局和样式重新计算次数
• DOM变更次数

每个基准测试都承担两项任务。在实验阶段，它是Claude进行“爬山”的目标，即对照固定分数一步步改进；在持续集成（CI）中，它变成一道棘轮，也就是只允许数字下降的检查。Claude还必须证明，代理指标上的提升确实转化成了实际耗时的缩短。

两条热路径展示了实际效果：

在消息树组装中，25%的指令消耗在缓慢的字典查找上，同一个消息ID被分别解析了三次。

智能体发现了什么

工作循环很简单：工程师用录屏报告一个缓慢的流程，Claude构建可复现该问题的基准测试，在功能开关之后提交拉取请求，并在部署后检查线上数据。如果真实数据有所改善，就收紧基准测试的上限；如果没有，就关闭开关，由Claude再次尝试。

第二周，团队将这一做法横向扩展到100多个Claude线程，同时运行的最多达50个。有些线程在完成第一项任务后继续寻找新工作，各自提交了50到100个拉取请求。高峰时期，一天合并的变更超过200项。Anthropic的一名工程师形容这个模型是“数字狂魔”。

智能体挖出的问题包括：

• 在消息输入框中，每按一次键都会重新执行6,900个React钩子和900个状态订阅。
• 根元素上的一个CSS“:has”选择器，让每次DOM变更都多出24毫秒的样式重新计算。
• 一处遗留的页面重新加载调用，每天引发约50万次用户看不到的整页重新加载。
• 空闲的后台标签页在主线程上每分钟两次把同一份缓存快照复制到浏览器内置数据库IndexedDB中。
• Markdown中的长破折号或弯引号，迫使Chrome的V8引擎以较慢的双字节格式存储文本，导致所有语法高亮正则表达式都走慢速路径，页面会卡住约1秒。一项20行的修改在高亮前先把代码块复制成单字节字符串，解决了这个问题。

启动速度的提升来自具体改动。静态消息输入框被直接写入初始HTML，用户在React加载完成前就能开始输入。桌面应用现在附带预编译的V8代码缓存，启动时不再从头解析和编译脚本。用户切换对话时输入框保持挂载，鼠标指针悬停在侧边栏上时预取对话，使侧边栏重新渲染减少了90%。

另一项工作瞄准8.33毫秒的帧预算，也就是每秒120帧时每帧可用的时间。Claude让无头Chromium恰好以这个间隔推进240帧，然后逐帧检查一段长回复。通过对已完成的文本块做记忆化处理，并把不断增长的代码块的分词工作移到Web Worker中，长回复期间的主线程阻塞时间从750多毫秒降到约200毫秒，CPU占用减少了三分之二。仅这一个线程就合并了近60个拉取请求。

人始终掌握主导权的环节

速度与护栏并行。每个拉取请求都必须通过自动CI检查，并获得至少一名工程师的批准。有风险的变更藏在短期功能开关之后发布，两周内创建了近200个开关，每个变更一经确认稳定就删除对应开关。静态输入框在14种视口尺寸下接受测试，确认与React版本的差异不超过1像素；模拟输入测试则在切换过程中持续打字，以发现丢失的按键。

测试仍有疏漏。静态输入框在内部上线4小时后，一名员工发来一段录屏，显示页面出现跳动。原因是Chrome在企业托管配置文件的新标签页上显示的一条56像素管理页脚。Chrome会在用户输入地址时预渲染页面，而尺寸采用的是新标签页的大小。约100毫秒后页脚消失，页面尺寸随之改变，而输入框是按距顶部的百分比定位的，没有固定在底部，于是发生了移动。

把握方向同样是人的工作。默认情况下，Claude会把任务范围定得很窄，并高估所需时间。当它为基础遥测提出一份需要数天的计划时，一名工程师让它更大胆一些，预估时间随即降到一小时以内。早期目标达成后，团队明确征求“天马行空的想法”，以获得更大胆的提案。反过来，一个为每次发送消息节省2毫秒的900行拉取请求在评审中被否决，因为它意味着要长期维护一个自定义构建插件。团队让150个线程各自专注于单一基准测试或单一使用流程。

审美判断也留给了人。每个线程都有一名人类负责人，Claude会用前后对比录屏或截图展示用户可见的变化。表格应该逐个单元格流式输出还是等整行完成，何时显示骨架屏，逐词淡入效果是否值得占用20%的帧预算，这些都是判断问题，而不是指标问题。

▲ 与服务器不同步的侧边栏缓存

指标看不到的漏洞

实际使用提速后的claude.ai会发现，速度也有代价。发送提示词后立即刷新，新对话可能从侧边栏中消失。在另一个窗口中删除的对话可能作为缓存条目继续留在侧边栏里，点击后会返回“该会话已不可用”的错误。侧边栏现在直接从本地IndexedDB缓存即时渲染，但似乎并没有可靠地与服务器重新核对。一种替代做法是，在服务器确认之前，以淡化状态显示缓存数据。

更普遍的教训是，脱离上下文追逐代理指标的智能体，可能会因为单独看分数更好，而关掉预取或缓存等有用的工作。过于严格的布局测试也有类似风险：如果缓存中有4个条目而服务器返回5个，列表向下移动是正确行为，而不是缺陷。用户很少报告轻微卡顿或同步缓慢，因此工程师亲自试用产品依然不可或缺。

如何用于自己的工作

最清晰的结论是，给智能体一个具体的测量值，就能把一个没有边界的优化问题变成可以解决的问题。如果打算把性能工作交给编程智能体，可以参考这次行之有效的顺序：

1. 为每个关键流程测量从用户操作到最终渲染的时间，并区分客户端与服务器时间。
2. 给智能体确定性的目标，例如指令数或React提交次数，而不是原始耗时。
3. 确认代理指标的提升确实体现为实际提速后，再用CI棘轮固定下来。
4. 有风险的变更放在功能开关之后发布，每个拉取请求都要求人工批准。
5. 需要更大胆时明确告诉智能体，并否决那些只换来微小收益的复杂变更。
6. 亲自使用产品，找出任何指标都记录不到的同步问题和界面卡顿。