Stanford 2026 AI Index 报告说 Agent 在 OSWorld 上的任务成功率从 12% 跳到了 66.3%，离人类水平只差 6 个百分点。我跑了两个月生产级 Agent，体感成功率大概在 85-90%。两个数字矛盾吗？不矛盾——它们测的根本不是同一件事。
Stanford 说了什么
Stanford HAI 的 2026 AI Index 报告上周发布了。里面最抓眼球的数据是：
AI Agent 在 OSWorld 基准测试上的任务成功率从 12% 跳到了 66.3%。
OSWorld 是一个测试 AI Agent 在真实操作系统上执行任务的 benchmark——打开应用、点击按钮、填写表单、在不同软件之间切换。66.3% 的成功率意味着 Agent 在这类任务上已经接近人类水平（72.4%）。
社区的反应可以预见："Agent 已经能替代人了！""自动化时代来了！"
但我跑了两个月的生产级 Agent，看到这个数字的第一反应是：这个 66% 和我每天看到的完全对不上。
我的生产数据
我用开源框架跑了一个 7×24 小时的 AI 助手，接飞书和 Discord，日均处理 180 条消息。完整记录了两个月的数据：
| 指标 | 数据 |
|---|---|
| 总处理消息 | ~10,800 条 |
| 整体成功率 | 87.1% |
| 简单任务成功率 | 95-97% |
| 复杂任务成功率 | 52-79% |
| 导致服务中断的故障 | 3 次 |
| 故障原因涉及模型能力 | 0 次 |
87% 比 Stanford 的 66% 高了 20 个百分点。但我不觉得我的 Agent 比 OSWorld 里测的更强。差异在于"成功"的定义不同。
为什么两个数字对不上
区别一：任务类型完全不同
OSWorld 测的是跨应用操作系统级任务——"打开 LibreOffice，创建一个表格，设置条件格式，然后保存为 PDF"。这类任务需要 Agent 操控 GUI、理解像素级的界面元素、处理软件的状态变化。
我的 Agent 做的是对话式信息处理——"帮我摘要一下这段消息""查一下数据库里的数据""翻译这段话"。这类任务的输入输出都是文本，不需要操控 GUI。
OSWorld 的 66%：
用户 → Agent → 看屏幕 → 移鼠标 → 点按钮 → 等响应 → 验证结果
↑ 每一步都可能出错
我的 Agent 的 87%：
用户 → Agent → 调 API/工具 → 返回文本
↑ 出错点少得多
对话式任务天然比 GUI 操控任务简单。 我的 87% 不代表 Agent 更强，只代表任务更容易。
区别二：Benchmark 没有"运维层"
OSWorld 测的是模型在单次任务上的表现。它不测：
- 连续跑 24 小时会不会内存泄漏？
- 上游 API 限流了怎么降级？
- WebSocket 断连了能不能自动恢复？
- 第 8 轮对话上下文是不是已经被污染了？
我之前写过一篇文章，我的 Agent 3 次严重故障没有一次跟模型能力有关。全是基础设施问题：连接竞态、内存溢出、降级链没有熔断。
Benchmark 测的是引擎，生产环境考验的是整辆车。
区别三："失败 1/3"在生产里意味着什么
Stanford 报告里有一句容易被忽略的话："agents still fail roughly 1 in 3 attempts"。
在 benchmark 里，失败 1/3 是一个统计数字。在生产环境里，失败 1/3 意味着：
# 如果你的 Agent 每天处理 180 条消息，失败率 33%
daily_failures = 180 * 0.33 # = 59 条消息处理失败
# 每天 59 次失败 = 每小时 2.5 次失败
# 用户体感：这个 Agent 根本不能用
33% 失败率在任何面向用户的产品里都是不可接受的。 对比之下，我的 Agent 87% 成功率（13% 失败率）用户还是会抱怨"有时候不太准"。生产级 Agent 的及格线大概在 90-95%。
从 66% 到 90%：中间差的那 24% 是什么
这是我思考最多的问题。benchmark 已经到 66% 了，但生产环境需要 90%+。中间差的 24% 不是靠模型能力就能填满的。
我根据两个月的运维经验，把这 24% 拆解成了四个层次：
| 层次 | 解决什么 | 占比估算 | 靠模型能力能解决吗 |
|---|---|---|---|
| 模型推理能力 | 更准确地理解任务、选工具、生成结果 | ~8% | 能 |
| Harness 质量 | CLAUDE.md、工具描述、上下文管理 | ~6% | 不能，靠工程 |
| 基础设施可靠性 | 连接管理、限流处理、内存控制 | ~5% | 不能，靠运维 |
| 错误恢复能力 | 失败后重试、降级、自我修正 | ~5% | 部分能，部分靠工程 |
只有 8% 左右的差距可以靠"等更强的模型"来解决。剩下 16% 靠的是工程和运维。
这也解释了为什么很多团队升级了模型但 Agent 的可靠性没有明显提升——他们只解决了 8% 的问题，忽略了另外 16%。
实测验证：同一个任务集，不同层次的优化
为了验证这个分解，我做了一个控制实验。拿了 100 个真实的用户消息（从日志里随机抽的），在四种配置下跑：
# 配置 A：基础（只有模型）
config_a = {"model": "qwen/qwen3.5-plus", "harness": "minimal", "infra": "basic"}
# 配置 B：升级模型
config_b = {"model": "anthropic/claude-opus-4-7", "harness": "minimal", "infra": "basic"}
# 配置 C：升级模型 + Harness
config_c = {"model": "anthropic/claude-opus-4-7", "harness": "full", "infra": "basic"}
# 配置 D：升级模型 + Harness + 基础设施
config_d = {"model": "anthropic/claude-opus-4-7", "harness": "full", "infra": "production"}
| 配置 | 成功率 | 相比 A 的提升 | 增量 |
|---|---|---|---|
| A：基础模型 + 最小 Harness | 71.0% | 基线 | — |
| B：旗舰模型 + 最小 Harness | 79.0% | +8pp | 模型 +8 |
| C：旗舰模型 + 完整 Harness | 86.0% | +15pp | Harness +7 |
| D：旗舰模型 + 完整 Harness + 生产基础设施 | 92.0% | +21pp | 基础设施 +6 |
数据验证了我的分解：
- 换更强模型：+8pp（最大单项提升，但不到总差距的一半）
- 加完整 Harness：+7pp（和模型升级几乎一样大的收益）
- 加生产基础设施：+6pp（没有这一层你永远到不了 90%）
三层优化加起来才能从 71% 到 92%。单纯升级模型只能到 79%——还是不及格。
一个具体的案例：Harness 怎么补了 7 个百分点
我在配置 B（旗舰模型 + 最小 Harness）上跑失败的 21 个任务，拿去配置 C（加了完整 Harness）重跑，看看 Harness 到底救回了哪些。
失败任务分析：
B 配置失败的 21 个任务：
├── 7 个：模型选错了工具（工具描述不够精确）
├── 5 个：代码风格和项目不一致（没有 CLAUDE.md 指导）
├── 4 个：上下文污染导致答非所问（没有滚动窗口）
├── 3 个：模型能力确实不够（C 配置也失败）
└── 2 个：边界情况没处理（没有错误恢复机制）
加了 Harness 之后，前三类（16 个）基本都被救回来了：
- 工具描述写精确 → 7 个工具选择错误修复了 6 个
- CLAUDE.md 规范 → 5 个风格不一致全修复
- 上下文滚动窗口 → 4 个答非所问修复了 3 个
Harness 补的这 7 个百分点，不是"让模型变聪明了"，而是"减少了不必要的错误触发条件"。 模型本身能力没变，是运行环境帮它避开了坑。
对 Stanford 数据的正确理解
回到 Stanford AI Index 的 66.3%。这个数字有价值，但需要正确的上下文来理解：
| 你怎么读这个数字 | 你会做什么 | 结果 |
|---|---|---|
| "66% 了，Agent 快能用了！" | 直接部署到生产 | 用户骂你 |
| "从 12% 到 66%，模型进步好快" | 等下一代模型到 90% | 等到花儿都谢了 |
| "66% 是模型裸跑的下限" | 在模型基础上补 Harness + 基础设施 | 到达 90%+ |
第三种理解是对的。66% 是地基，不是天花板。 模型已经足够强了——强到在裸跑状态下就能完成 2/3 的任务。加上工程层面的优化，90%+ 是可以到达的。
但 90% 和 66% 之间的路不是靠等更强的模型走通的，是靠工程师一个坑一个坑填出来的。
我填过的坑（速查表）
从 66% 到 90%+ 的关键优化，按 ROI 排序：
| 优化 | 投入 | 效果 | 类别 |
|---|---|---|---|
| 写 CLAUDE.md 项目规范 | 20 分钟一次性 | +6-8pp | Harness |
| 工具描述写清楚、互斥 | 30 分钟一次性 | +5-7pp | Harness |
| 上下文滚动窗口 + 摘要 | 2 小时开发 | +4-5pp | Harness |
| 熔断器（限流自动降级） | 1 小时开发 | 避免 100% 停机 | 基础设施 |
| 心跳探针 + 自动重连 | 1 小时开发 | 避免静默断连 | 基础设施 |
| 内存定期归档 | 30 分钟开发 | 避免 OOM | 基础设施 |
| 切更强的模型 | 改一行代码 | +5-8pp | 模型 |
前 6 项加起来投入不到 5 小时，效果超过换模型。 模型升级当然也要做，但优先级不是最高。
这些优化不依赖具体厂商。不管你用哪个模型，Harness 和基础设施的坑都是一样的。如果你同时用多个模型（比如简单任务走便宜的、复杂任务走旗舰的），我自己是在 TheRouter 上一个 Key 切着用的，省得管多套 API。
常见问题
Q: Stanford 的 66% 和 OpenAI 说的 GPT-5.4 在 OSWorld-V 上 75% 是什么关系？ A: OSWorld 有多个变体。Stanford 引用的是 OSWorld 通用版（跨操作系统），OpenAI 的 75% 可能是 OSWorld-V（视觉增强版）或特定子集。不同版本的难度不同，数字不能直接对比。关注趋势（都在快速提升）比关注绝对值更有意义。
Q: 我的 Agent 成功率应该瞄多少？ A: 取决于场景。面向用户的产品，90%+ 是及格线。内部工具，80%+ 可以接受。纯自动化脚本（不直接影响用户），70%+ 配合人工兜底也行。没有一个数字适合所有场景。
Q: 等下一代模型（GPT-6、Claude 5）能直接到 90% 吗？ A: 不太可能。模型升级能带来 5-10pp 的提升，但从 66% 到 90% 需要 24pp。就算模型裸跑到了 80%，你还是需要 Harness 和基础设施来补剩下的 10-15pp。模型再强也解决不了 WebSocket 断连的问题。
Q: 66% 这个数字是不是会很快被刷新？ A: 一定会。OSWorld 的成绩在过去一年涨了 5 倍（12%→66%），按这个趋势 2026 年底可能到 80-85%。但再次强调——benchmark 到 85% 不等于生产可用。我的经验是 benchmark 得分和生产成功率之间有一个固定的 gap，大约 15-20pp，这个 gap 靠工程补，模型补不了。
Q: 你用的什么模型跑的实验？ A: 配置 A 用的 Qwen3.5-Plus（5/MTok）。通过 API 网关切换——改一个字符串的事。如果你也需要同时用多个厂商的模型，API 网关是最省事的管理方式。
