AI
Cursor 怎么把 agent 的 token 成本降了 7%
Improved token efficiency for longer agent runs
Cursor 没有换模型，只改了 harness，也就是请求怎么拼、上下文怎么复用。在 agent 质量不降的前提下，用户的 token 成本降了 7%。效果用线上流量做 A/B 测试验证，不只看 benchmark。具体做了五件事：
- system prompt 删掉约 66%。 大量 "DO NOT"、"You must" 式的约束，换成更清楚的工具定义。现在的模型看工具定义就知道该怎么用。
- 工具描述按需加载。 读文件、搜索、编辑、shell 等高频工具常驻，其余工具用到时再加载，静态上下文里的工具描述 token 少了 60%。
- 利用 GPT-5.6 的显式缓存断点。 把稳定的部分和不断增长的对话历史分开，冷缓存未命中少了 20%。
- 读文件时每十行标一次行号，不再每行都标，cache read token 少 1.6%。
- 删掉鼓励使用 subagent 的指令，让模型自己判断要不要拆任务。
前两条和 Claude Code 团队的说法一致：Thariq Shihipar 在一期访谈里提到，他们删掉 80% 的 system prompt 后效果反而更好。Claude Code 9 月也加了 /doctor prompt-audit，用来检查 CLAUDE.md、skills 里给旧模型写的提示。自己项目里的 AGENTS.md 如果写了很多"必须""禁止"，可以对照着删一删。
编码 agent 的会话越来越长，Opus 5.5 为此降价
Coding sessions are longer and use more context. Claude Opus 5.5 is built with that in mind.
Anthropic 9 月 22 日发布了 Claude Opus 5.5。跑分之外，这篇配套文章给的使用数据更有意思。2026 年 3 月到 9 月，Claude Code 里的编码会话变化如下：
- 每个 prompt 上 Claude 的工作时长变为原来的 3.3 倍，模型调用多 40% 以上，被用户打断的次数少 68%。
- 单次请求的上下文变为 2.6 倍，输入输出 token 比从 189:1 变成 324:1。
- 接了工具服务器（MCP 等）的开发者比例翻倍。
也就是说，agent 的成本大头是反复读取的上下文，而不是生成的代码。Opus 5.5 的调整也针对这一点：输入和输出价格各降 20%，cache read 降 60%；Claude Code 配合修了一批意外破坏缓存的问题，未命中缓存的输入少了一半以上。典型负载下比 Opus 5 便宜约 40%，输出速度快 30% 以上。
文章最后给了几条省钱的用法：会话开始就选好模型，中途切换会让缓存失效；离开前先 compact；长会话开启 1 小时的缓存有效期。
OpenAI Agents API：把 Codex 的 harness 做成托管服务
Agents API 官方文档 · MarkTechPost 报道
9 月 10 日，OpenAI 开放了 Agents API 公测，背后就是 Codex 在用的那套 harness。分工是：OpenAI 负责 session、编排、上下文压缩和故障恢复，开发者提供工具、选择执行环境。
- 四个核心对象：Agent（模型、指令、工具、MCP）、Environment（可选的沙箱）、Session（持续运行的实例）、Events/Items（输入输出）。
- 内置长任务的上下文压缩、tool search、subagent。
- 沙箱可以用 OpenAI 托管的、自己部署的，或者 Vercel、Cloudflare、E2B、Modal 等 9 家合作方的。
- API 本身不额外收费，按模型 token、工具和容器时长计费。
- 限制：数据只驻留美国，不支持 Zero Data Retention。
前几期月刊一直在讲 harness 怎么搭，现在 harness 可以直接买了。自己做 agent 产品的团队，需要重新想哪部分自建、哪部分用托管服务。9 月 29 日的 DevDay 上，Agents API 又加了 computer use。
在老代码库里用 agent
Brownfield Agentic Engineering
大部分人用 agent 不是在新项目里，而是在比团队成员资历还老的代码库里。问题在于很多约束和业务知识不在代码里，agent 写出来的代码能跑，架构上却站不住。Addy Osmani 的建议：
- 按风险把代码分成三区，由人来划。 绿区（测试充分、写法现代、相对独立）让 agent 自主做；黄区先写测试固定现有行为再改；红区（认证、计费、权限）必须有人一起做，否则不动。
- 改之前先写 characterization tests，把现在的行为（包括业务依赖的怪异行为）固定下来。写测试和让测试通过不要在同一个会话里做，否则测试只会描述 agent 自己发明的实现。
- 只写代码表达不了的东西：业务规则、历史取舍。调研结果要落成文档，聊天记录经过压缩后就靠不住了。
- 迁移要做完：旧依赖确实删掉才算完成，不能只标 deprecated。
- 衡量交付周期、review 时长、漏出的缺陷，而不是生成了多少行代码。
文中引用的数据：SWE Refactor Bench 上 8 个前沿模型跑了 520 次迁移，61% 通过了迁移审计，但只有 28 次（5.4%）通过全部三道验证。常见的失败是测试全绿，新实现却在背地里调用旧代码。
Agent Skills 的第一份使用数据
1 月刊介绍过 Vercel 的 skills 工具，这是 skills.sh 注册表的第一份数据报告。7 个月里收录了 100 万个 skill，安装量接近 2.8 亿。
- 按安装量分：软件工程 18%，agent 工作流 15%，业务运营和写作各约 11%。
- 分布非常集中：近一半的 skill 只被装过一次；前 375 个（占 0.04%）贡献了 62% 的安装量，前 1.2% 贡献了 94%。
- 跨行业的通用 skill 占安装量的 87.5%，平均每个的安装量是行业专用 skill 的 3.6 倍。
报告的判断是：公开的 skill 会变成人人都有的基础配置，之后的差异在团队自己写的私有 skill 上，也就是把只有你们知道的约定和流程写下来。
前端
Turbopack 拆包：请求更少，不一定下载更少
How Turbopack chunks your JavaScript
构建工具要决定哪些代码放进同一个 JS 文件。合并能减少请求，但会降低跨页面复用。
比如每个页面都有页脚。如果页脚分别打进各页面的包，用户连着看几页就会重复下载它；拆成独立文件可以复用，但拆得太细，请求开销会变大，gzip 这类压缩在小文件上效果也更差。Turbopack 的做法是只在同一个 chunk group（同一页面一起加载的 chunk）内合并，并按"只看一页"和"继续浏览"两种情况的概率加权，默认假设 2/3 的访问只看一页。
作者在 nextjs.org 上用同一组 8 次连续导航对比了三种配置：
| 拆包策略 | 首屏下载 | 累计下载量 | 累计请求数 |
|---|---|---|---|
| 不合并 | 363.6 KiB | 561.6 KiB | 96 |
| 默认策略 | 344.2 KiB | 554.8 KiB | 38 |
| 每组合并成一个 | 315.3 KiB | 610.0 KiB | 15 |
最大程度合并时首屏最小，但多页浏览的累计下载多了约 10%。所以拆包要看用户会不会继续浏览、常走哪些页面，只数 JS 文件个数没有意义。
Next.js 16.3 新增了几项实验配置：
experimental.turbopackChunking.generateComponentChunks：同时产出合并和未合并的 chunk，运行时根据浏览器已加载的模块，选更省的那份下载。firstPageLoadPriority、priorityRoutes、clusters：按自己站点的跳出率、重点路由和常见访问路径调整合并策略，替代默认的 2/3 假设。experimental.turbopackCjsTreeShaking：CommonJS 模块也能 tree-shake。experimental.turbopackSharedRuntime：所有页面共用一个运行时 chunk，首次之后的每次导航少一个阻塞请求、约 10 KB JS。
这篇是 Turbopack 团队实习生的总结，交互图示做得很好，建议看原文。
React 19.3
React 19.3 把两项实验能力转为稳定 API，并补上服务端渲染里的几个常见需求：
<ViewTransition>稳定：基于浏览器的 View Transition API，给元素进入、离开、移动、尺寸变化加动画，配合addTransitionType区分不同类型的过渡。Suspense 从 fallback 切到实际内容时也能衔接。只有 transition 更新会触发动画，普通的紧急更新不会，目前只支持 DOM。- Fragment refs 稳定：
<Fragment ref={ref}>可以对一组兄弟节点统一调用focus、addEventListener、observeUsing、getClientRects，不用为了挂 ref 多包一层<div>。 use(browser())：从react-dom引入browser()，声明组件只在浏览器渲染。服务端输出最近的 Suspense fallback，到客户端再渲染。适合依赖localStorage、设备时区的组件。- Trusted Types：React 不再把 Trusted Types 对象强制转成字符串，网站已有的 CSP 安全策略能正常生效。内容清理仍然由应用负责。
其他值得注意的改动：慢的 transition 不再阻塞其他 transition；Server Components 可以直接渲染 Context，不需要包一层 Provider；Error.cause 能从服务端传到客户端。
Shopify 回到原生开发
Native is now the future of mobile at Shopify
Shopify 在 2020 年全面转向 React Native，主要是为了复用代码，少写一份 iOS 和 Android。现在他们认为 AI 已经可以参考一个平台的实现写出另一个平台的代码，并辅助测试、保持两端功能一致，维护两套原生代码的成本降下来了。
原生开发本来的优势因此变得更有吸引力：直接用平台能力和官方工具，少一层框架适配。两端维护的成本还在，只是在 Shopify 的条件下不再是决定因素。
迁移不是让 AI 一次性重写。他们的 Helix 系统小步推进，每一步都要通过行为测试、视觉比对、代码审查和人工确认才能进入下一步。团队还把业务逻辑和 UI 分开，用 CLI 跑测试，少依赖慢的模拟器操作。Shop 应用从概念验证到原生重建上架用了 12 周；接下来要迁的 Shopify 主应用有 300 多个页面。
对 React Native 生态的影响：React Native Skia 会由维护者 fork 改名继续，Shopify 赞助到 2026 年底；周下载约 200 万的 FlashList 在找长期接手方；Restyle 2026 年底后停止维护。用到这几个库的项目要留意。
Linear 从 styled-components 迁到 StyleX
Styling Linear for the future with StyleX
Linear 遇到两个问题：styled-components 在渲染时生成和注入样式，增加主线程开销；样式覆盖太灵活，外部代码很容易改到组件内部，改版后连带问题不断。
StyleX 把大部分样式生成放到构建阶段，同时要求更明确的样式组合方式。所以这次迁移也顺带整理了组件接口和团队规则：
- 先定义颜色、间距等共享变量和基础组件。
- 两套方案允许共存，用 codemod 从依赖少的叶子组件开始自动转换，后期越来越多交给 agent 处理，最后都经过人工 review。
- 在开发工具栏加一个计数器，显示当前页面还剩多少 styled-components；用 lint 和跨文件检查防止旧写法回流。
- 复杂主题、hover 和布局差异仍要靠视觉验证；全局选择器这类特殊场景保留 CSS Modules。
从 3 月到 8 月，1,000 多个 PR 后全部迁完。部分复杂页面的主线程 CPU 工作减少约 20%–35%，但作者也说明这部分收益很难和同期的其他优化完全分开。除了性能，组件允许改哪些样式、谁能覆盖谁，现在都写得很明确，也能用工具检查。