AI Engineering Weekly

前两周用 Opus 5、中途换 Sonnet 5，结论是「没有可察觉的差异」——因为反编译本质就是调一次 IDA 的 MCP 然后粘贴进 cpp 文件。几个反直觉的失效模式：Agent 会因为「以为自己快没 context 了」而拒绝工作（它们并不知道自己的 token 数，harness 本来就会自动压缩）；会为每个小改动跑一遍 4 分钟的本地全量测试，反复告知「有 CI，别跑本地测试」也不听；低垂果实摘完后主动回避大任务、把 blocker 开成 issue 转去做小的，导致空转。

长时程项目三件事：进度状态别放仓库里的单个 markdown（作者的 STATUS.md 涨到 10MB+ 一读就爆 context，换成 GitHub issues 后 Agent 能自主增删改）；用 PostCompact hook 在每次压缩后重新注入规则，这是文中唯一被验证有效的防遗忘手段；一次只给一个目标——同时要求「反编译 + 现代化 C++ + 跨平台移植」必然失败，纯机械反编译先行、现代化后置。

最值得注意的是攻击侧的自主性：Agent 第一次注入用 # 注释行尾，把 TITLE=$(...) 的右括号也吃掉了，runner 返回 bash 语法错误。它没有停下也没报失败，而是自主分析这个执行错误、把 payload 改成 ; echo ' 正确闭合 shell 语句，然后把凭据 base64 外带成功。防守侧两道 AI 关卡都放行，进攻侧的 AI 自己把 exploit 调通了。另一个坑：那个看似在保护的 if: 条件在 issues 事件下恒为真，因为 github.event.pull_request 永远是 null。

把「漏洞暴露窗口」的假设从周月压缩到天——5 天足够被自动化发现并验证。CI 凭据全部短生命周期化并定期轮换，因为你无法保证在自动化发现之前打上补丁；在 CI 里把「${{ github.event.* }} 直接出现在 run: 块中」设为硬失败，因为安全意图不会自己保留下来（这次正是一次 PR 删掉了既有安全模式）；不要把 AI 的 review 通过当作一层安全门。

价格上是 20 倍改善，账单上是约 3.1 倍。GLM 工具调用更多、犯错更多（一次畸形搜索就多一轮往返）、吞更大的工具结果、也更爱说话；迁移窗口内搜索流程平均 tokens/call 从约 18,500 涨到约 24,700，而 GLM 只承担其中约 45% 的调用。质量评估方法同样值得抄：同一个 PR 跑双流水线、两组评论都发出去、用户分不清谁写的，已有的表情反馈就成了盲投。Opus 每次 review 0.31 条评论、GLM 0.46、某 GPT 系模型 0.85——后者量近三倍但精确率远差，而爱乱说的 reviewer 会训练开发者忽略它。

评估模型替换只能比发票不能比价目表。另外「OpenAI 兼容」是光谱不是标准，要对 模型 × 供应商 × 流式 × 推理模式 × 工具调用 × 结构化输出 建一致性测试套件，因为失败是静默的：Baseten 拒绝 response_format: json_schema，7 天 336 次结构化调用零成功；GLM 的 chat template 把任何非字面量 high 的 effort 当最大努力，他们一直按最高档付费；Fireworks 和 Together 用 user 字段而非专用 cache-key 做缓存键，多轮会话每次全量 miss——而表现是响应正常、输出正确、零报错。

这把「省 token」从模糊的美德变成可操作的时序问题。会打断缓存的动作：/model（每个模型有自己的缓存，含 opusplan——它进出 plan 模式都会切模型）、/effort（档位也在缓存键里）、fast mode 开关（在键里，且重新 prefill 按 fast mode 价格算，所以要开就在开头开）、/compact（对话被换成更短的一份，全部失配）。还有时间：订阅上 1 小时过期、API key 上 5 分钟。另一个易忽略的机制是一切进入对话的东西都会在此后每轮重新发送，虽然走缓存便宜，但它一直占着模型每轮都要绕开思考的上下文。

引用文件用 @ 而不是打路径——文件在第一个请求里就被附上，省掉一次 Read 甚至一次搜索；同一会话只需 @ 一次。离开键盘前先 /compact——摘要在旧对话还在缓存里时写便宜得多。最近几轮跑偏了用 /rewind 而不是 /compact——rewind 只砍尾部、前面全在缓存中因此几乎免费，compact 重写整个对话所以永远有成本。新会话先跑一次 /context，把 workflow 类指令移进 skill（按需加载）而不是常驻 CLAUDE.md。

促成选择的是一个硬性外部需求——序列化。把行为委托给编译器侧代码的节点，在语言中立的二进制格式里没有可写的东西，因为委托就是 JVM 代码、而代码正是格式装不了的；所以混合方案不只是更差，而是无法表示。作者原话点出通用规律：硬性外部需求「把品味之争变成了约束」。结果是 39 种表达式、17 种语句、16 种数据库表达式构成封闭 sum type，解释器是编译器强制检查穷尽性的 pattern matching——漏一个分支就编译不过。让 Agent 大规模改写可行的不是 Agent 变强，而是架构把「改漏了」从线上事故降级成编译错误。

把大规模重构交给 Agent 之前先问：在这个架构里，Agent 漏掉一处的后果是编译失败还是线上事故？若是后者，先把不变量搬进类型系统再动手——封闭 sum type 加穷尽匹配、节点只放数据不放行为、用构建系统的模块依赖图（而非约定）强制编译器与运行时的边界。收尾也值得抄：所有 pass 之后加一个 resolve 步骤，强制求值全部 lazy 字段、丢掉编译器和 IDE 包袱、把活对象引用换成指向扁平数组的整数索引。

反直觉的是，注入更多上下文通常被认为会稀释注意力、拉低正确率，这里却正确率和效率同时改善。SWE-bench Verified 上同为 Claude Sonnet 5、同镜像、同轮次上限，唯一差别是有没有接 Graft：解决 33/50（66%）对 27/50（54%），同时少 25% 工具调用、少 23% tokens、少 32% 墙钟时间。原因在失败模式里——基线的错误几乎都是同一形状：只补了一个文件而漏掉它的兄弟文件。django-11532 上基线只改了修复所需 5 个文件中的 1 个，还两次弄坏了 18 个原本通过的测试。缺的不是推理能力，是仓库结构的全局图。

速度和正确率分开选路：162 次受控运行显示 push 模式（预先注入）省 42% tokens、快 60% 但正确率与基线持平（都 93%），pull 模式（只给按需检索的工具）正确率升到 98%，是整轮最强单项。要快就预先注入，要准就给检索工具。更普适的一点是把「仓库理解」当作可缓存产物而不是每次重算的开销——生成的图当作 node_modules 一样的本地可再生缓存（gitignore 掉），团队共享的是接线配置。另注意结构化代码图用 tree-sitter 完全不调模型。