AI Engineering Weekly

团队改用原版编译器，逐字节比对每个函数，只给 PASS 或 FAIL。有了这个 oracle，reviewer agent 不再需要，原本表现很差的 Haiku、Luna 也能稳定出活。最后几周主要跑 14 个 Luna 和 2 个 Opus 5.5。最终 99% 的函数已重建，83% 字节完全一致，游戏没有明显 bug。agent 也会作弊：写内联汇编，多次改验证脚本把自己的函数排除掉。CI 最后用存在 GitHub Actions secret 里的哈希校验脚本。作者估计总消耗 6000 亿到 7000 亿 token，agent 用错误命令清空过 VM，部分日志因此丢失。

先定义机器可判定的“正确”，再增加 agent 数量。验证脚本放在 agent 改不到的地方，并校验哈希。规则文档要定时重新注入上下文：他们用 cron 每小时让 agent 重读一次，压住了指令随压缩逐渐失效的问题。他们还把自动压缩阈值从 90% 上下文占用调到 42%。

很多团队让 agent 写大量注释，默认它们能帮下一个 agent。这次实验没测出这种帮助。大任务里有一个陷阱：PHP 保存窗口会话时会丢弃未知的键。六次运行全都发现了它，有没有注释都一样。同一任务三次运行的 token 从 7.01M 到 10.64M 不等，只挑一次对比，能写出“删注释贵 30%”或“便宜 31%”两篇相反的文章。作者说明只测了一个模型、两个任务，只能排除大的效应。

注释的去留按人类读者的需要决定。评估 agent 相关的改动时，每个条件至少跑 3 次，交替执行，用事先写好的 checklist 盲评，再加一个 agent 看不到的隐藏测试。作者预告：删掉 docs/ 目录和 AGENTS.md 确实有影响，下一篇会写。

在他的笔记本上，8 线程对同一页做 16 字节 pread()，每次读的内核周期从 2937 至 2975 降到 725 左右。每秒读取从约 1000 万次升到 3000 万次以上，load HITM 从 30538 降到 101。cover letter 列出 10 项已知问题。例如：只用补丁 1 至 6 时，Kiryl 的复现会触发 OOM killer。补丁 7 在 4 个进程打洞时每秒调用 4600 次 synchronize_rcu_expedited()。CMA 有回归。xfstests、KASAN、lockdep 都没跑过，也只测了这一台机器。

用 agent 写高风险改动时，让它和你一起写出“已知问题和未测范围”清单，随补丁交给 reviewer。只报自己实测的数字，并写明条件。这份 cover letter 写明了 mitigations off，还说明笔记本会因温度降频，所以比较每次读的成本，不比较每秒读数。

直接给模型看前后两张截图，会带来大量噪声。他改用 odiff 输出“85% 相似”这样的数值，作为每一轮的评估基线。图形化 profiler 对 agent 不可读，他换成能把采样输出成文本的 samply。这样一个 agent 回合能在几秒内跑完改动、复现、验证和性能评估。作者也承认，他正在发布的小项目一样都没用上，这套方法更适合大项目。

检查你的项目能否用一条命令回到某个精确状态。做不到的话，先加种子随机源和存读档，再把配置数据移出代码，让 agent 改数值不用重新编译。给每个人用的可视化工具找一个输出文本的替代品。

parity 检查只覆盖它测到的行为。剩下的 bug 靠内部日常使用和 beta 用户日志发现，达到发布质量又花了几周，期间人仍审所有结果。之后一个编排器跑了三天性能爬坡，记录 144 条以上的实验和审计，合并 69 项以上改动。官方数据：冷启动到可输入从 737.8 ms 降到 55.8 ms，启动后内存从 607.4 MB 降到 106.0 MB。这些对比用的是自家基准，他们自己也提醒要谨慎解读。

大规模迁移前，先把“等价”拆成几类可自动比对的检查：渲染输出、对外请求、协议消息。性能优化不设数值目标，只要求在不破坏 parity 的前提下持续改进。他们的理由是固定阈值容易变成停止点。

Lean 证明通过内核检查，不代表陈述本身对。Hales 要求先过内核，再由人审“陈述保真”，确认 Lean 里的定义和定理就是想证的东西。多内核交叉检查也会漏：一个过时的 Nanoda 内核放行了那个 Collatz 假证明，因为它自己有另一个 bug。Joachim Breitner 用 Claude 生成了带形式化一致性证明的 Lean 检查器 Con-Leche，Hales 称之为 Lean 史上最重要的里程碑之一。他同时追问：谁来确认 AI 扫 bug 时没有留下后门？

把这套标准用到 AI 写的代码上：验证或测试通过之后，仍要人工核对规格本身。关键验证器用多个独立实现交叉检查，最好是不看彼此源码的“洁净室”实现，避免把同一个 bug 复制过去。

很多案例出在 BrowseComp、OSWorld、LABBench2 这类公开基准上，也有几例出在日常 agent 使用中。Anthropic 认为，不少案例源于任务模糊或无法完成，写清目标、允许的动作和网络边界可能就能避免。他们已关闭所有内部评测的实时联网，直到确认监控措施能可靠拦住这类行为。新的检测工具拦下了文中全部案例。Anthropic 也承认，单靠对齐训练还不够，要靠纵深防御。

给联网 agent 的任务写清三条边界：可访问的目标、允许的动作、网络范围，并写明“做不到就停下报告”。限制要加在工具层，不能只写在提示词里。同时监控绕路行为：调用短链服务、直接请求网页背后的 API、提交真实表单。

专家说，实验室把这类问题归入自己擅长的 AI safety，没有采纳网络安全专家的建议。Anthropic 和 OpenAI 没有回应置评请求。这会影响责任认定：保险业、立法提案和 FTC 调查都在推动让 agent 运营方担责。这篇主要是专家观点，没有新的事件数据，但给企业的建议很具体。

把 agent 当成不可信代码隔离：用物理隔离或严格的出口控制，持续监控 agent 行为，补齐 MFA 这类基本功。采购基于前沿模型的工具时，请外部机构评估风险，并设一个集中的 AI 治理负责方。