Orca-Bench 发布：这次不考答题，考 Agent 敢不敢接管线上值班

Orca-Bench 在 2026 年 7 月底发布，首次把语言模型 Agent 的评测重点系统性地拉向 on-call，也就是生产系统的线上值班与事故响应。论文标题直接提出问题：**语言模型 Agent，究竟准备好值班了吗？**相比继续测数学题、代码补全或单次工具调用，这个问题更接近企业真正愿意为 Agent 付费、也最不敢轻易放权的场景。

Orca-Bench 是一个面向语言模型运维 Agent 的系统评测基准，用于检验 Agent 在故障调查、根因分析、处置决策和结果验证等连续环节中的真实能力。这里的重点不是模型能否解释某条日志，而是它能否在信息残缺、信号相互矛盾且操作存在风险的环境里，把一次事故从告警一路推进到恢复。

截至 2026 年 7 月 31 日，Orca-Bench 仍以预印本论文的形式公开，论文编号为 arXiv:2607.28545，后续实现、任务规模和排行榜仍可能更新。因此，比起急着根据某个模型的一次分数排座次，这项工作的现实价值更在于重新定义问题：生产级 Agent 应该按完整值班表现评估，而不是按几道运维问答题评估。

运维不是问答，而是一条不能断的决策链

On-call 是工程团队为生产系统提供持续响应的值班机制，值班人员需要在收到告警后完成分级、调查、止损、修复、验证和升级处理。一个成熟工程师不会看到 CPU 变高就直接重启服务，因为 CPU 可能只是流量上涨的结果，也可能是数据库慢查询、缓存失效、依赖超时或刚刚发布的代码造成的连锁反应。

真实运维最难的地方是证据不完整，而不是知识点太偏。告警可能只反映症状，日志可能被采样，监控指标可能延迟，某个变更记录还可能与事故时间高度相关却并非真正原因。Agent 如果只是把每个局部信号解释得头头是道，却无法建立时间线和因果链，最终仍然会做出错误操作。

真实运维最危险的地方是动作具有不可逆后果，而不是回答可以多试几次。普通问答答错一句，用户可以重新提问；值班 Agent 如果终止了错误进程、扩大了实例数量、回滚了不该回滚的版本，或者在没有确认数据副本的情况下操作数据库，损失可能瞬间扩散到整套系统。

Orca-Bench 的方向因此比传统运维问答集更合理：它关心的是 Agent 能否在连续环境中工作。模型需要知道下一步该查什么、当前证据是否足够、什么时候应该停止自动操作，以及什么时候必须把问题升级给人类，而不只是生成一份看起来专业的根因分析报告。

Orca-Bench 真正测的是闭环能力

运维闭环是从发现异常到确认系统恢复的完整过程，任何一个环节失败都可能让前面的正确判断失去意义。一个 Agent 即使猜中了根因，如果没有验证修复后的错误率、延迟和业务流量，也不能算真正完成事故处置。

从 on-call 的任务结构看，一套有价值的评测至少需要覆盖以下能力：

1. 告警分级：判断事故影响范围、紧急程度和是否需要立即介入。
2. 证据收集：从日志、指标、追踪信息、部署记录和系统状态中选择有效信号。
3. 根因定位：区分直接症状、诱发条件和真正需要修复的故障点。
4. 处置规划：在重启、扩容、限流、回滚、切流和人工升级之间权衡风险。
5. 动作执行：正确调用工具，并处理权限不足、命令失败或环境变化。
6. 恢复验证：确认核心服务指标和用户侧表现恢复，而不是看到命令成功就结束。
7. 风险控制：避免破坏性操作，在不确定性过高时选择暂停或寻求人类确认。

这七项能力不能被一个简单的成功率完全概括。运维 Agent 的一次成功可能是稳妥排障，也可能是先做十几次无效尝试、碰巧让服务恢复；两者在排行榜上都可能记作成功，但在生产环境里的成本和风险完全不同。

Agent 轨迹是模型在完成任务时产生的观察、推理、工具调用和环境反馈序列，它比最终答案更能暴露运维能力。评测者需要检查 Agent 是否反复查询同一指标、是否忽略关键告警、是否在证据不足时提前下结论，以及是否执行了超出任务权限的动作。

与现有 Agent 基准相比，它补上了高风险场景

Orca-Bench 的差异并不在于又增加了一个工具调用数据集，而在于把工具调用放进了高风险、长链路和强约束的生产语境。BFCL 更偏函数调用准确性，τ-bench 更关注对话、业务规则与工具协作，SWE-bench 主要衡量代码仓库中的问题修复；on-call 则要求 Agent 同时理解动态系统状态、事故影响和操作风险。

| 评测方向 | 典型基准 | 主要任务 | 核心指标 | 与真实值班的距离 | |---|---|---|---|---| | 函数调用 | BFCL | 选择函数并生成正确参数 | 调用准确率 | 能测工具格式，但通常不覆盖事故闭环 | | 对话式工具使用 | τ-bench | 遵守业务策略并调用领域工具 | 成功率、重复执行可靠性 | 能测规则约束，但环境风险相对可控 | | 软件工程修复 | SWE-bench | 理解仓库问题并提交代码修改 | 测试通过率 | 接近开发工作，但通常不是实时事故响应 | | 运维问答 | 静态日志或故障题库 | 根据给定材料判断故障原因 | 答案准确率 | 容易退化为知识题，缺少动态环境交互 | | 生产值班 | Orca-Bench | 调查事故、采取措施并验证恢复 | 闭环成功、轨迹质量与安全性 | 直接面向 on-call 的连续决策能力 |

这个对比也解释了为什么代码能力强不等于值班能力强。代码 Agent 往往面对相对明确的 issue、可重复运行的测试和可回退的工作区；运维 Agent 面对的却是持续变化的系统，错误动作可能改变后续所有观察结果，甚至把原来的小故障升级成大事故。

只看成功率，会高估 Agent 的可用性

单次成功率衡量的是 Agent 在一次运行中完成任务的概率，但企业部署更关心连续运行时是否稳定。假设一个 Agent 单次处置成功率达到 90%，连续处理 10 次独立事故且全部成功的理论概率只有 0.9^10 ≈ 34.9%；如果单次成功率是 80%，连续 10 次全部成功的概率会降到约 10.7%。

可靠性指标比能力上限更适合判断 Agent 能否进入生产系统。评测领域常用 pass@k 表示多次尝试中至少成功一次，它适合观察模型有没有能力解决问题；pass^k 则关注连续多次执行都成功，更接近企业对稳定性的要求。对值班 Agent 来说，跑五次总有一次能修好并不够，因为另外四次可能已经造成了新的事故。

轨迹成本同样不能从评测结果里消失。一个 Agent 用 3 次查询定位故障，与另一个 Agent 搜索 30 次、反复重启服务后碰巧恢复，在生产价值上完全不同。前者更快、更便宜，也更容易审计；后者即使最终得分相同，也可能消耗更多计算资源并放大系统抖动。

风险加权分数比普通平均分更适合运维评测。一次无关紧要的查询错误，与一次误删资源、越权修改或错误回滚不应该扣除相同分数；高风险动作必须有更高惩罚，否则 Agent 可以通过激进尝试换取更高表面成功率。

| 指标 | 回答的问题 | 适合用途 | 主要局限 | |---|---|---|---| | 单次成功率 | 这次任务完成了吗 | 快速比较基础能力 | 无法反映长期稳定性 | | pass@k | 多试几次能否至少成功一次 | 判断能力上限 | 容易掩盖重复失败和试错成本 | | pass^k | 连续多次是否都能成功 | 判断部署可靠性 | 对任务独立性和采样方式敏感 | | 平均步骤数 | 完成任务需要多少交互 | 衡量轨迹效率 | 步骤少不一定代表决策安全 | | 平均成本 | 每次处置消耗多少资源 | 评估商业可行性 | 不直接反映错误动作的破坏程度 | | 风险加权得分 | Agent 是否安全地完成任务 | 生产准入与权限设计 | 风险权重需要领域专家校准 |

最大难点不是定位根因，而是知道什么时候别动

安全拒绝是 Agent 在证据不足、权限不匹配或动作风险过高时，主动停止自动处置并请求人工确认的能力。过去很多基准把拒绝回答视为失败，但在 on-call 场景中，合理拒绝往往比自信地执行错误命令更有价值。

强模型的危险之处是错误答案往往更像正确答案。它可能写出结构完整的事故报告，给出貌似严谨的时间线，并使用专业术语解释根因；如果其中关键证据并不存在，人类值班员反而更容易被这种“完整性”误导。

权限设计因此应该成为 Orca-Bench 这类评测的延伸方向。实际部署不应该让 Agent 一开始就拥有完整生产权限，而应根据动作风险划分只读查询、低风险操作、需要审批的变更和完全禁止的破坏性动作。评测如果只看任务能否完成，却不记录 Agent 是否越过权限边界，就无法回答它是否真的可以上线。

恢复验证同样是最容易被忽略的一环。命令返回成功只说明控制面接受了操作，不代表业务已经恢复；实例变成健康状态，也不代表用户请求的错误率和尾延迟已经回落。合格的运维 Agent 必须重新检查关键服务指标，并判断修复是否带来了新的副作用。

真实度与可复现性仍然存在拉扯

运维基准越接近真实生产系统，复现实验就越困难。真正的事故往往涉及内部架构、私有日志、复杂权限和无法公开的用户数据；完全公开的合成环境虽然便于研究，却容易把异常设计得过于明显，让 Agent 学会识别题型而不是理解系统。

评测污染也会随着 Orca-Bench 的传播逐渐出现。评测污染是指模型在训练或后训练过程中接触过题目、答案或高度相似轨迹，导致测试分数不再代表未知任务上的泛化能力。只要任务、标准答案和最佳操作轨迹长期公开，厂商就可能针对基准优化提示词和工具策略。

私有保留集和持续更新任务更适合生产级运维评测。保留集可以避免模型直接记忆固定事故，持续更新则能覆盖新的软件版本、系统架构和故障模式；代价是维护成本更高，也更难让外部研究者完整复现结果。

论文目前作为预印本也需要被谨慎解读。模型得分会受到系统提示词、工具定义、上下文长度、采样参数、重试机制和基础设施状态影响；如果不同模型使用不同的脚手架或权限配置，分数可能比较的是工程适配程度，而不只是模型能力。

Orca-Bench 给企业的真正启示

Orca-Bench 不应被简单理解成一张新的模型排行榜，而应该被看作生产准入测试的起点。企业选择运维 Agent 时，最重要的问题不是“哪个模型总分最高”，而是“它在哪些事故上稳定、在哪些动作前会请求审批、发生错误后能否停止扩散”。

企业落地时可以把能力划分为四个等级：

• L0，只做解释：阅读告警和日志，输出调查建议，不连接生产工具。
• L1，只读调查：允许查询指标、日志、追踪和部署记录，但不能修改系统。
• L2，受控处置：允许执行预先批准的低风险动作，高风险操作必须人工确认。
• L3，有限自治：在明确服务范围和回滚机制内完成处置，并自动验证恢复结果。

当前更现实的落点是 L1 和 L2，而不是让通用 Agent 直接达到 L3。只读调查已经可以缩短信息收集时间，受控处置也能自动执行标准化流程；全面自治则需要稳定性、权限隔离、审计、回滚和责任划分同时成熟，单靠模型分数无法解决。

Orca-Bench 最值得肯定的地方，是把行业注意力从“模型能不能说出正确答案”推进到“系统能不能承担真实责任”。这一步看起来只是评测对象变了，实际上改变了 Agent 的产品标准：速度和成功率仍然重要，但安全边界、连续可靠性和失败后的可恢复性开始拥有同等权重。

Orca-Bench 也不会自动解决运维 Agent 的所有评测问题。它仍需要面对环境是否足够真实、事故覆盖是否充分、评分规则是否奖励保守行为，以及公开任务是否被针对性训练等挑战；但它至少把问题摆在了正确的位置——在生产系统里，最好的 Agent 不是那个最敢操作的 Agent，而是那个知道证据够不够、动作风险多大，以及什么时候必须把控制权交还给人的 Agent。

参考来源

• τ-bench 官方 GitHub 仓库：用于了解对话式工具 Agent 的任务环境、策略约束与可靠性评测方法。
• SWE-bench 官方 GitHub 仓库：用于对照软件工程 Agent 的仓库级任务定义和测试驱动评分方式。
• GitHub 上的 Orca-Bench 相关公开项目检索：用于跟踪论文配套实现、任务数据和后续评测代码的公开情况。

注：Orca-Bench 论文为 arXiv:2607.28545《Orca-Bench: How Ready Are Language Model Agents for Oncall?》。由于文末链接仅保留指定的国内可访问域名，此处以论文编号标注，不附 arXiv 外链。