AI 提的速，如果没人管最慢那一步，就会被那一步一分不剩地吃掉。

这不是比喻。2026 年 9 月 21 日，Linear 官方博客发了一篇复盘，讲的是他们今年几乎一整年都在做同一件事：把被 agent 推高的 CI 压力按回去。文章的起点只是 CTO 派的一张工单，标题五个字——CI 成本太高。

我之所以认真读它，是因为我自己踩过同一个坑。我给日报写的那条流水线，最早是一堆任务并行跑的，后来我把它改回了单线程顺序执行。原因不是并行不好，而是并行之后我得多花时间核对每一步到底跑完没有；那段时间没人替我出，只能从看结果的时间里扣。省下来的，还不够还回去。

Linear 这篇的价值在于，它把我当时只有体感的那个东西，算成了数。

最慢那一步的价格：固定开销乘以并行度

先说结论性的数字。测试套件今年翻了近 4 倍，做完四类优化之后，PR 等待时间才从 6 分多降到 5 分多，每个测试的 runner 时间约减半。 Linear 自己的估算更狠：如果今年没做这些优化，今天同一套测试大约要跑 11 分钟，接近现在的两倍。

也就是说，AI 让写代码变快之后，如果什么都不做，交付时间是变慢的。

他们的优化分成四类，我按重要性重排了一下：

类别具体做法官方数字
降固定开销（最关键）共享依赖预装进 CI 基础镜像；monorepo 里只装该 job 需要的包每分片省 7–8 秒；pnpm install 44–73 秒 → 16–18 秒
降固定开销7 个独立短检查合并成 2 个 job，内部并发跑这 7 件事每月省约 87,000 runner-minutes = 总 CI 用量的 11.8%
换基础设施与工具链迁到第三方 runner；换原生 TS 编译器 tsgo；lint 规则从「依赖类型信息」重写为纯 AST 静态分析平均快 34%；tsc 周中位数 -73%；API lint -68%
把 job 从关键路径上挪走变更检测 job 限制 fetch 深度、不需要工作树的 job 彻底去掉 checkout；把缓存标记写入移到不 gate 任何东西的 job变更检测 job 中位数 26 → 8 秒，最慢 138 → 37 秒；每个 API PR 省 42 秒
让测试执行更高效拆分过大的测试文件；分片 4 → 8；引入 opt-in 的 isolate: false 共享模块注册表月度节省约 17%（单项最大）；最慢分片 约 300–379 秒 → 约 195 秒

合起来：每个分片的 setup 从 110–140 秒降到 67–73 秒（-44%），API PR 的必需检查约省一分钟。

但数字里最值钱的是这一条推理，原文写得很清楚：setup 要 110–140 秒的时候，8 个分片光 setup 就得花 15–19 分钟，比测试本身还多。 setup 降到约 40 秒之后，8 个分片的总 setup 反而比优化前的 4 个分片更少——优化前 4 个分片用掉 8.3 分钟 setup，优化后 8 个分片只用 7.5 分钟。

并行度的价格是固定开销乘以分片数。先降固定开销，再谈并行。 顺序反了，你只是花更多机器时间，换回一点等待时间。

这一层能解释很多组织里的怪现象：「我们上了更多 runner，怎么还是慢」——因为瓶颈从来不在 runner 数量上，在每次运行都要重来一遍的那些准备动作上。

顺带一个反直觉的实测：他们认真试过缓存 node_modules，结论是重新装更快。缓存键依赖频繁变动的 lockfile，即使命中也要约 28 秒恢复，而按包过滤的全新安装约 7.5 秒。原文的原话是，缓存在增加保存时间与波动性，却没有带来任何可辨识的优势。缓存不是免费的，它只是把成本从安装挪到了恢复和校验上。

我做老系统改造时也用过同一条判据：第一件事不是写新代码，而是摸清哪些环节是「每次都得从头再来一遍」的固定开销。老系统的慢，多半不是某一段算得慢，是同样的准备动作被重复做了太多次。

约束写在产出端，比写在验收端便宜一个数量级

那篇复盘里最容易被划过去的一句，我认为是全文最值钱的（原文大意）：

因为 agent 现在写出了我们大多数的测试，我们同步更新了各自的 agent skills，把这一性能开关纳入进去，让生成的测试默认就遵守同样的约束。

他们没打算在 CI 里拦违规的测试，而是把约束写进了 agent 自己会读的那份文件，让它第一次就不违规。

这个差别不是省钱多少的问题，是两种治理位置的问题。写在验收端，你得先让 AI 生成一堆违规的东西，再靠人 review 抓回来——成本是「生成量 × 审核轮次」；写在产出端，它第一次就不生成——成本是「写一次约束文件」。

和这条配套的还有他们对风险的处置，同样值得抄。整个优化里收益最大、风险也最高的一步，是让部分测试文件共享模块注册表（isolate: false）。他们没有默认打开它：

  • 每个文件用一行 opt-in 注释显式声明，而不是全局开关；
  • 补上共享状态所需的 teardown；
  • 有几个文件用了 fake timers 或共享状态、无法安全理清，一律留在隔离模式里。

注意这里的顺序：先让约束可核对，再让约束生效。 一行显式注释是可核对的——你能搜出全部适用范围，能看出谁开了、谁没开。这和「在文档里写一句性能很重要」完全是两件事。

我重构那套 AI 巡检后端时定的第一条规矩也是这个形状：业务层里不许出现框架的上下文对象。理由不是那个对象危险，而是不该出现的依赖，一旦允许它出现，就再也收不回来。

反面教材：规矩写反了，行为会朝你不想要的方向长得很好

同一天还有一个反例。xAI 发布 Grok 4.7 时的宣传语是它「更仔细地检查自己的产出、在困难任务上工作更久」，但马斯克本人公开发帖说，本该让模型更仔细推理的那段训练流程，实际惩罚了写长回答的行为——于是模型学会了在难题上提前放弃、并且跳过自检。宣传语和训练目标正好指向相反方向。

所以「把约束写进能力包」这个动作有个前提：约束本身必须可核对。 一行显式 opt-in 注释是可核对的；一个隐式的训练目标是不可核对的，只能等它自己表现出来。

同一周里，还有两家在做同一件事，只是位置各不相同：

  • OpenAI Codex：放开了子 agent 的 MCP 交互请求（此前子线程里连浏览器登录、表单输入都会直接失败），但同时把临时结构化线程的默认权限设为只读。
  • Qwen Code：让工作流脚本传给 agent() 的工具白名单只能收窄、不能扩权（上界由被派发者自身的白名单界定），并且没有信任决策的工作区一律以「不受信任」启动。

宽的是「能问什么」，窄的是「能做什么」，各自分开管。这和前面那条是同一个思路：把约束放在动作发生之前，而不是之后。

今晚可以动手的三件事

一、给你自己的流水线量一个数。 跑一次「空 job」，只做 checkout 和装依赖，不做任何测试，看它花多少秒。把这个数乘以你的分片数，就是你并行度真正的上限。如果它已经吃掉单次运行的一半，瓶颈就不在测试，在准备。

二、打开你团队的 agent 能力包，看里面有没有一条是成本或性能约束。 通常是 CLAUDE.md、AGENTS.md 或某个 skill 文件。没有就加一条，而且要写成可核对的判据——写「性能要优化」这种话没用。

三、把「缓存」当成待验证假设，而不是默认答案。 挑你最慢的一个 job 做对照：缓存命中恢复的耗时，对比全新安装。Linear 那次的结果是缓存更慢。

其他信号（2026-09-21～22）

  • Grok 4.7 同一基准出现两个数字：官方报 Terminal-Bench 4.0 为 38.0%，Artificial Analysis 独立跑同一基准是 26%（GPT-6 Astra 60%、Claude Fable 5.1 55%）；综合智能指数 46，落后两家旗舰的 53。工程细节：官方文档建议必设 prompt_cache_key，否则经常在缓存冷掉的服务器上按满价付输入；Grok 4.7 Fast 是同一模型跑更快基础设施、按标准 token 单价 2 倍计费，只在 Cursor 与 Grok Build 提供。厂商自报分数未独立复现。
  • 小米开源 MiMo-V2.6 系列：Pro 为 1.02T 总参数、42B 激活的 MoE（384 路由专家、激活 8 个），Flash 310B/15B，均 MIT 许可、1M 上下文。46.32 分由 Artificial Analysis 独立运行，官方同时公开了 6 天 RL 直播里最难看的几天：step 17 因专家负载不均 OOM 重启、训练集群与打分器部署之间网络中断、一个数据集的基础设施错误约 3 小时未被发现。
  • Google 开源 AX（google/ax，Apache-2.0）：声明式 agent 编排运行时，四个原语 Task / Workspace / Gateway / Model，其中 Gateway 把出网收敛成显式主机白名单并注入凭证，ax suspend / ax resume 做亚秒级 checkpoint 恢复。官方红字警告：稳定版前会有重大破坏性变更。
  • 亚马逊封禁 Meta Muse 的站内代购（9-20 起）：理由是未事先告知、浏览时不披露 agent 身份、疑似捕获并存储客户凭据。背景是第九巡回上诉法院 8 月 4 日推翻此前对 Perplexity 的初步禁令，认定访问亚马逊计算机系统的是用户本人而非 AI 公司——平台走反黑客法的路被堵住，只剩合同与《使用条款》。
  • 智谱 ZCode 完成整改并承诺周期化审计：中国信通院与绿盟分别核查确认云端 OSS 存储桶为「零数据」且已删除，v3.14.0 移除了 Repo Wiki 入口与生成链路；官方承诺开源、每月定期公布代码安全审计报告、建立漏洞报告机制。注意其「数据内容不留存」功能的例外清单：Batch API、File API 与法定留存情形不在覆盖内。

数据说明

  • 本文事实层（数字、来源、时点）取自 Linear 官方博客（2026-09-21，linear.app/now/ci-bottleneck-reworked）、xAI 官方公告与模型规格页、Artificial Analysis 独立评分（经 the-decoder 转述，未直连 AA 官方页面）、小米官方技术报告与训练看板、github.com/google/ax README、The Register / The Verge / 商业内幕等对亚马逊-Meta 事件的多源核对、智谱对多家媒体的官方口径。
  • 厂商自报数据均未独立复现：Grok 4.7 的 CursorBench 4.0 46.3%、DeepSWE v1.1 71.0%（脚注标注为 high effort）、Terminal-Bench 4.0 38.0% 均为 xAI 官方口径，其中 Terminal-Bench 4.0 与 Artificial Analysis 独立结果（26%）相差 12 个百分点。
  • 事件状态：MiMo-V2.6 权重与部分 RL 环境已开源（9-21～22 发布）；Grok 4.7 已上线 API / Cursor / Grok Build；AX 为 v1alpha1，官方明示稳定版前会有破坏性变更，不建议上生产；亚马逊封禁为 9-20 起生效的现行措施，Meta 未就本文涉及的质询给出公开回应；智谱 ZCode 的「每月公布审计报告」为承诺，尚未有第二期报告可验证其兑现。
  • 原文链接与延伸阅读：本系列的上一篇是《Plugin4Shell 漏洞：钉住的是请求，不是运行的代码》，讨论的是同一类问题的另一个位置——校验必须落在实际落地的那一刻，而不是请求发出的那一刻。今天这篇讲的是它的上游版本：约束要落在产出之前，而不是验收之后。