AI Agent 开始交工程化的学费

如果你最近还在判断 Agent 是不是一个会退潮的概念，今天这组数字值得认真看一眼。

GitHub 一年内的 Git 活动翻了一倍多，Asana 把浏览器 Agent 的单次成本压低了 76 倍，Sophos 把一次安全调查从 38 分钟缩短到 89 秒。与此同时，公开代码中大约每两秒就会出现一个新泄露密钥。

这些消息放在一起，指向的不是“模型又强了”，而是更现实的变化。AI Agent 已经开始进入生产系统，而生产系统最关心的四件事是吞吐量、成本、安全和评测。

GitHub 的数据告诉我们，Agent 时代首先是基础设施问题

GitHub 公布的数据很有冲击力。2025 年 9 月到 2026 年 8 月，平台每月 Git 活动从 2182 亿次上升到 4733 亿次。仅 2026 年 9 月，开发者与 Agent 就提交了 73.8 亿次 commit，是一年前的五倍以上。push 数量同比增长 4.9 倍，GitHub Actions 当月运行 32.6 亿次，超过一年前的四倍。

中文翻译一下就是，Agent 不只是替人写更多代码，它还会更频繁地保存、推送、触发测试、读取分支和发起合并。人类觉得可以忽略的几百毫秒延迟，会在成千上万个 Agent 的循环里变成真正的瓶颈。

GitHub 因此正在重建面向 Agent 规模的 Git 基础设施。过去的架构把耐久性和读取扩容绑定在一起，增加副本可以提高读取能力，却会让每次写入等待更多副本确认。Agent 带来的持续高并发写入，让这套折中碰到了天花板。

我的判断是，下一轮 AI 开发工具的护城河不会只在模型体验上。任务队列、并发隔离、增量状态、缓存、失败恢复和可观测性，这些过去看起来不够性感的工程能力，会决定产品能不能从十个用户走到一万个用户。

对 opcpay.org 的读者来说，这个变化尤其重要。如果你的产品准备加入 Agent，别只算一次模型调用多少钱。还要算一次完整任务会产生多少次读写、多少次外部 API 调用、多少次重试，以及失败后是否能够从中间状态恢复。Agent 的账单往往藏在循环里。

Asana 的 76 倍降本，关键并不是找到更便宜的模型

Asana 对浏览器 Agent 做了 144 次实验。优化前的生产方案，单次任务模型成本至少为 36.21 美元，有些运行甚至在达到步骤上限后仍未完成。优化后使用 GPT-6.1 Sol，单次成本降到 0.47 美元，速度从至少 22.5 分钟缩短到约 4 分钟，并且所有运行都完成任务并返回正确答案。

表面看，这是一次 76 倍降本和 5 倍提速。真正值得抄作业的是它的实现路径。

团队发现，Agent 虽然缓存了固定指令和工具定义，却没有缓存不断增长的网页文本与截图历史。每次请求都在重新支付整段历史的费用。更麻烦的是，系统几乎每一步都会删除旧截图、裁剪文字，历史内容一旦变化，缓存也很难命中。

他们最终扩大了历史预算，把浏览历史纳入缓存，并让截图累计到 20 张后再批量缩减到最新一张。优化后，89% 的输入来自缓存，缓存价格只有未缓存输入的 5%。完整案例可见OpenAI 与 Asana 公布的实验记录。

我的判断是，Agent 产品的毛利率越来越像一个系统设计问题。模型单价固然重要，但上下文是否稳定、工具返回是否冗长、截图是否反复变化、失败是否导致整段重跑，常常比模型价目表更能决定最终成本。

如果你正在做 SaaS Agent，可以从一个很朴素的表格开始。记录每次任务的输入 token、缓存命中率、工具调用次数、重试次数、任务完成率和人工接管时间。没有这些数据，“换一个更便宜的模型”通常只是把问题挪了个地方。

AI 代码审查终于有了更接近生产环境的公开标尺

AI 代码审查工具很多，但过去很难回答一个基本问题，它到底是真的发现了问题，还是只写出一堆看起来专业的评论。

GitHub 发布的 ReviewBench 尝试补上这个空白。团队先分析了 1.039 亿个真实 PR 的语言、仓库规模和改动形态，再构建包含 219 个 PR、覆盖 19 种语言的评测集。标准答案同时来自人类审查、前沿模型与静态分析，独立高级工程师对真实问题的标注一致率达到 96.6%。

中文翻译一下，评测不再只问“模型找到了多少预先写好的错误”，还要区分严重程度、问题类别，以及工具在召回率与误报率之间作出的选择。一个什么都评论的 Agent 可能召回率很高，却会把开发者淹没在噪音里。

我的判断是，AI 功能采购会越来越依赖贴近业务的评测集。通用榜单只能说明模型大概有多聪明，真正决定价值的是，它能否在你的代码、你的风险等级和你的工作流中减少事故，同时不制造过量干扰。

对小团队而言，不必复制 GitHub 的完整方法，但可以借鉴它的结构。抽取过去半年最典型的 PR，整理已知缺陷和人工评论，把“严重问题漏报率”和“每个 PR 的无效评论数”同时列为指标。你需要的不是最会说话的审查工具，而是最适合你风险偏好的工具。

代码生成越快，安全越不能依赖人肉补救

GitHub 披露，目前每三个 PR 中就有一个涉及 AI Agent，一年前这一比例还不到十分之一。与此同时，公开代码中大约每两秒出现一个新泄露密钥，而且这一数量已经连续三年每年翻倍。

容易得出的结论是，AI 让开发者变得更粗心。但 GitHub 的九个季度数据并不支持这个判断。2024 年第二季度到 2026 年第二季度，被检查的 push 增长 2.84 倍，携带凭据的 push 增长 2.59 倍，单次 push 的泄露比例没有可统计识别的上升趋势。开发者主动绕过拦截的比例反而从 6.63% 降到 3.93%。

真正的问题是规模。人工吊销一个泄露密钥平均需要约 40 天，大约五分之一超过 90 天。当前 push protection 能在密钥进入仓库历史前拦住约 30%，其余 70% 仍然需要事后处理。更多数据见 GitHub 的密钥防护分析。

我的判断是，AI 时代的安全设计要从“发现后通知人”转向“危险动作发生前自动阻断”。这不只适用于代码密钥，也适用于 SaaS 里的退款、删除、权限变更和批量外发。凡是补救成本远高于拦截成本的动作，都应该尽可能设置前置检查与分级授权。

对 opcpay.org 的读者而言，这意味着自动化不能只追求完成率。一个支付或运营 Agent 即使 99% 的时候都正确，只要剩下 1% 能够直接执行不可逆操作，产品就很难获得真正的信任。权限边界、审批门槛和审计记录，本身就是产品体验的一部分。

Sophos 展示了垂直 Agent 更现实的落地方式

Sophos 每天接收数万亿条安全事件，再把它们压缩成约 1000 至 2000 个案件，交由九个安全运营中心调查。引入 Agent 后，使用 Agent 的案件平均响应时间从约 38 分钟降到 89 秒，下降约 96%，其中 52% 的 MDR 案件可以在分析师设定的边界内端到端自动处理。

这套系统并没有假装人类不再重要。它把服务分为通知、协作和授权三种模式。涉及不确定或潜在破坏性的操作，仍然交给人类判断。原始案例见OpenAI 与 Sophos 的公开说明。

我的判断是，垂直 Agent 最可行的路径不是把专家拿掉，而是把专家经验拆成调查、规划、执行和复核几个环节，再明确每个环节的权限。这样既能把大量标准案件交给计算资源，也能把人的注意力留给例外、威胁与责任判断。