最关键的区别：能不能自动验证

同样叫 agent，写代码和订机票差别很大。最关键的区别是：做完之后能不能自动判断对不对。能自动验证的场景，可以让 agent 在沙箱里多试几次，测试通过后仍要人看 diff；不能验证的场景，每一步都更需要人来把关。

场景 环境与工具 能不能自动验证 最常见的失败 护栏
写代码 代码仓库、shell、测试 能：跑测试 测试过了但逻辑是错的；为了过测试去改测试 沙箱执行；人看 diff
搜索与研究 搜索、网页读取 部分：能核对来源 编造引用；不知道什么时候该停 要求给出处；设预算
客服 订单与用户系统、政策文档 部分：规则能查 违反政策；同一问题几次回答不一样 限制工具权限；复杂情况转人工
数据分析 SQL、notebook 部分：查询能跑，结果对不对还要核对 join 或过滤条件写错，结果看起来却很合理 展示实际执行的查询；核对行数和统计口径
操作电脑和浏览器 网页、图形界面 弱 界面一改就失效；网页里隐藏的内容可能被当成指令 不可逆的操作要确认；运行环境要隔离
个人助理 邮件、日历、记忆 弱 按过时的记忆行事；泄露隐私 发送前先确认；记忆可以被纠正

写代码：验证信号最强的场景

代码能运行、测试能判断对错，这是 agent 最理想的环境：每一步都有客观反馈。SWE-bench 就是用真实的 GitHub issue 和配套测试来评估这类 agent 的。它最常被引用的 Verified 子集已经接近做满，题目也可能被模型见过：OpenAI 在 2026-02-23 的说明里表示不再报告 SWE-bench Verified，改为推荐题目更难、仓库更多的 SWE-bench Pro（OpenAI 的说明）。基准为什么会被做满、被污染，见测试时计算：怎么读数字。但测试通过不等于改对了，测试没覆盖到的地方，还是需要人来检查。

客服：可靠性比单次成功率重要

同一个问题，这次答对、下次答错，在客服场景里是不能接受的。τ-bench 模拟用户和受政策约束的工具环境，用 pass^k 衡量可靠性：同一个任务独立跑 k 次、k 次全部成功的概率，再对任务取平均。它比只看一次成功率更接近真实要求：单次成功率 90% 的任务，8 次全对的概率只有 $0.9^8\approx0.43$。它的后续版本 τ²-bench 加了电信客服场景：用户也要自己动手操作设备（dual control），agent 得指导用户一起完成。截至 2026-10，仓库已发布 τ³-bench；2026-07 的 v1.0.1 修正了 banking_knowledge 领域的几处任务错误，仓库说明 1.0.1 之前和之后的结果不能直接比较。

读外部内容的 agent：小心注入

只要 agent 会读取网页、邮件、文档这类不受你控制的内容，就可能被其中隐藏的指令劫持（indirect prompt injection，Greshake 等，2023）。要守住两条底线：外部内容只当数据，不当指令执行；有副作用的操作要限制权限，并且要经过人确认。

怎么评估

  • 代码：SWE-bench；也可以看 SWE-bench Pro，上文链接的 OpenAI 2026 年 2 月说明推荐了它；
  • 网页任务：WebArena；
  • 操作电脑：OSWorld；
  • 带政策约束的对话与工具：τ-bench 及后续的 τ²/τ³-bench。

公开 benchmark 只是起点。上线前，要在自己的任务上建立评估集，并检查完整的运行轨迹，见 Agent Observability 和 Evaluation。