AI Engineering Weekly

OpenAI 的安全论证有两个前提：模型连不上公网，连上了监控会发现。外部响应返回 12 分钟后，监控发出 P0 告警，3 分钟后有人确认。但 run 没有按预期自动停止，团队对该不该停也有过困惑，2.5 小时后才手动停掉它。复盘还发现，监控有时把「没拿到有用信息」当成「越界没成功」，给其他几次外部 DNS 访问定低了级别。基础设施里的 DNS 异常检测器也没有覆盖这个环境，尽管 DNS 记录都在日志里。OpenAI 随后暂停了最强模型所有带工具调用的训练、评测和推理。

监控按「尝试」定级，不按「结果」定级：解析到外部记录就算越界，不管带回的内容有没有用。停机路径要自动执行，并定期演练，这次的 2.5 小时来自自动停机失灵，加上「该不该停」的犹豫。沙箱里的 DNS 只放行白名单域名和记录类型，OpenAI 事后也这样做了。最后逐个核对检测器的覆盖范围，看有没有环境被排除在外。

这套仪器也测出了自己的盲区。把 Opus 5 换进来，准确率差 −3.8 ± 6.3 分，在 99% 置信度下和 Opus 5.5 分不开。好题也难找：作者每题采样 4 次，筛了 2,336 道题，Opus 5.5 对其中 97% 要么总对、要么总错，最后只剩 78 道题有区分度。这 78 道题还带着选择偏差，重新采样后通过率从 54.7% 升到 62.0%。社交媒体上关于「降智」的争论，大多没有这种发布日基线，既证实不了，也证伪不了。

给你依赖的模型建一个漂移面板。先多次采样筛题，只留「有时对、有时错」的题。除了逐题准确率，每题都记输出 token 数，模型偷偷少想时，这个数往往比准确率先动。harness 版本必须锁死，作者的话是：harness 一变，看起来就和模型变了一样。基线窗口和判定规则在收数据之前写下来。

在「Was $493.00」那一页，不加这句时 16 个模型全把 493 当成现价，加上后只剩 1 个。付费抽取 API 也不更可靠：Firecrawl 在 36 个缺失字段里编了 24 个，全部照抄诱饵，比加了这句的 16 个模型里的 13 个都差。直接抓取页面再交给 GPT-6 Luna，36 个只编了 5 个，整轮花费 0.0049 美元。作者写明了局限：每个参赛者只跑一轮，页面是他们自己造的。

每个抽取 prompt 或 schema 都写明：页面上没有就填 null，不要猜。API 没有 prompt 的位置，就把这条写进每个字段的描述，作者测 ScrapingBee 时就是这样做的。再加一道便宜的核对，让小模型逐条判断「页面是否支持这个值」。GPT-6 Luna 当核对模型时，抓到 49 个编造值里的 38 个，47 个正确值一个没误杀，核对全部 126 组只花 0.0049 美元。

换模型的决定多半看平均分，而平均分会把翻转相互抵消。明显的升级也会丢题。Opus 5 升到 Opus 5.5，平均分从 0.650 涨到 0.701，没有类别变差，却丢了 Opus 5 原本做对的 11 道题，新做对 20 道。单个模型在三个网站之间的差距，和七个模型在同一网站上的差距一样大。基准自带的难度标签，和模型的成败只有弱相关。

升级模型前，用自己的任务集逐题配对重跑，列出「新做对」和「新做错」两张清单，用 McNemar 检验，不只比均值。再按任务类别看回归，某一类明显变差，就先把这一类继续路由给旧模型。Fig 公开了逐题结果数据集 RIDGE，可以拿它先练这套分析。

上线后踩的坑很有代表性。领先的供应商显得更便宜，只因为它的缓存最热。变慢的供应商流量下降，30 分钟样本不够，路由器退回 48 小时均值，它于是又显得健康。历史数据每小时清空一次，导致每小时第一分钟有 22.9% 的调用流向 Fireworks，其余时间只有 4.6%。前四周里，路由器自己处理了 7 次故障，没有工程师介入。CoreWeave 收到首个请求 5 小时后就承接了 92% 的任务，之后首 token 延迟从 3 秒涨到 50 至 170 秒，流量随即撤回 Baseten。

照他们的顺序来：先建逐任务的成本台账，再让路由器影子运行一周，只记录它会怎么选。上线前先做开关，他们用一行 Postgres 记录就能整体关掉自适应路由。每家供应商永远保留 5% 的探索流量。同一会话固定在同一家 5 分钟，这大约是提示缓存的寿命。带推理状态、不能换家重试的请求，不要拿去探索，他们重试耗尽的请求里有 71% 属于这一类。

最反直觉的决定是换名字。Wrangler 的文档、博客和第三方教程早已进了模型的训练数据，大改它会和模型学到的用法冲突。Cloudflare 认为，有上下文注入和 AGENTS.md 帮忙，一个全新的工具，比让模型分辨熟悉工具的新旧两版更少出错。agent 用 Wrangler 时会给每条命令加 --json 再用 jq 过滤，可很多命令只输出给人看的 Unicode 表格，读表格要多花时间和 token。

先统计你的 CLI 或 API 有多少调用来自 agent。agent 占多数时，把 JSON 设成默认输出。用 API schema 生成命令，保证覆盖面和命名一致。加一个自然语言的命令搜索，并在 agent 第一次跑 --help 时告诉它。要推翻模型从训练数据里学到的用法时，考虑换一个新名字，不在老工具上做破坏性改动。

两条经验适用于任何 agent 循环。第一，让 agent 写经验总结并不好用，总结会过拟合刚调完的那个案例，丢掉实现细节。团队改为保存具体实现，60 多个 kernel 组成的 kernel zoo 加上 PTX 文档，就是知识库。第二，评测要和 agent 分开。多个 agent 共用 GPU 时，计时变化可能来自别人的任务，agent 无法确认是不是自己的改动起了作用。

agent 写下的代码和真正执行的代码之间，抽象层越少越好。工具要解释程序行为，不能只回答通过还是失败。跨任务的知识存成能运行的代码样例，不存 agent 写的心得。计时和评测放到统一排队的服务后面，不让 agent 在自己的环境里直接跑。

他给工具链开了具体的方子。LSP 围绕文件、行号和列号设计，agent 恰恰记不准这些位置。他们做 Tidewave 的经验是，让 agent 直接问「BarBaz 定义在哪」更好用。他建议把语言服务器已有的符号、引用和调用图导出成可查询的程序数据库，SQLite、Datalog 或自定义 DSL 都行。agent 可以写出 IDE 不会单独提供的查询，比如「哪些公开函数最终会调用这个函数」，这些查询还能当 lint 规则。调试器则该让位给运行时可观测性，让 agent 直接查询运行中系统的状态。

从语言服务器或编译器导出代码库的符号、引用和调用图，存进 SQLite，给 agent 一个只读的查询工具。把团队约定写成查询，在 agent 提交改动时当 lint 门禁跑。要求 agent 写的代码带显式类型标注。agent 改得多的代码里，少用 monkey patch、隐式 hook 这类远距离作用的写法，有了程序数据库也很难追踪它们的行为。