导语:为什么"模型能不能查问题"必须被测出来 2026 年,大模型进入 SOC(安全运营中心)和 SRE(站点可靠性工程)的真实事件流,几乎所有团队都撞上了同一堵墙:模型在 Demo 里漂亮地定位了故障,但放进生产里要么找不到根因,要么花掉的钱多到无法负担,要么在良性事件里硬生生"诊断"出一个不存在的问题。问题不是模型不够聪明,而是没有一个能让人看清楚"它到底能不能查问题、查一次花多少钱、不同 h
导语:为什么"模型能不能查问题"必须被测出来
2026 年,大模型进入 SOC(安全运营中心)和 SRE(站点可靠性工程)的真实事件流,几乎所有团队都撞上了同一堵墙:模型在 Demo 里漂亮地定位了故障,但放进生产里要么找不到根因,要么花掉的钱多到无法负担,要么在良性事件里硬生生"诊断"出一个不存在的问题。问题不是模型不够聪明,而是没有一个能让人看清楚"它到底能不能查问题、查一次花多少钱、不同 harness 下表现差多少"的公开标尺。
围绕这个缺口,硅谷可观测性公司 Cribl 在 2026 年 8 月推出 SecIT Bench(SecIT Bench:A frontier benchmark for AI agents in IT and security workflows),把 AI Agent 在 IT 与安全调查工作流里的表现第一次系统地摆到台面上。本文基于 Cribl 官方排行(secitbench.cribl.io,最近一次运行 2026-09-06,版本 1.0)和官方介绍博客(cribl.io/blog),拆解这个基准的设计、首批结果,以及它对 Agent 落地意味着什么。
一、SecIT Bench 是什么:30 个真实事件,三维度打分
SecIT Bench 不是一个"考模型知识"的考试。它的设计目标被官方明确写了出来——"evaluating AI agents for telemetry workflows"。也就是说,考点不是"模型知不知道",而是"模型在混乱、缺失、互相矛盾的遥测数据里,能不能像人一样收集证据、排除可能、推理出根因,并在证据不足时克制住自己不下结论"。
具体设计有四个关键点:
1. 30 个事件场景,横跨四大类。官方把场景划成四类:① 入侵与突破(intrusion and breach)② 隐蔽数据外泄(covert data egress)③ 服务错误(service errors)④ 性能下降(performance degradation)。每个事件都不是凭空编的——大多用本地和远程基础设施模拟真实故障,有的是"故意制造流量和失败后捕获遥测数据",有的则是"故意良性、根本没有事件可查",专门用来测试模型会不会"无中生有"。
2. 同一个证据池 + 一个小时调查窗口。每个 Agent 拿到的是同一份证据、相同的 60 分钟调查时间、没有 token / 成本上限。这样"它比对手强"就一定是因为决策更聪明,而不是因为拿到了更多线索或允许烧更多钱。
3. 每个组合跑三次独立 rollout。Agent 系统本身具有非确定性,跑三次是为了消除"运气成分",让结果统计上站得住。
4. 三维度打分:准确率 / 成本 / 耗时。不像代码基准(SWE-Bench 等)只看对错,SecIT Bench 强制把"花多少钱、花多少时间"作为并列指标——官方原话:"Accuracy without cost is half a number"(只看准确率只是半个数字)。
计分机制也值得一提:每个事件的"根因分析报告"由三位独立 LLM 裁判组成"裁判委员会",按预定义的"二元诊断条件"逐项打分,最终按多数票决定一项是否满足。这套机制避免了对答案文本做关键词匹配的粗糙做法,转而评估"是否识别了正确的组件、是否串起了证据、是否解释了机理"。
二、为什么不能直接用 Coding Agent 的分数
一个很容易掉进去的坑:看到"模型 X 在 SWE-Bench 上拿了 80% 分",就推断它也能处理生产事件调查。Cribl 的官方回答很直接——"Debugging a software repository and diagnosing a production incident are fundamentally different tasks"。
代码调试有"可以编译、可以测试"的明确答案;事件调查没有——它要在噪声、缺失信号、冲突证据和不完整上下文中,从症状反推原因。两者的推理模式完全不同。所以 SecIT Bench 单独做了一套场景,而不是去借 coding benchmark 的旧账。
更进一步,SecIT Bench 把"工具和脚手架"(行业里常叫 harness)和"底层模型"分开打分。同一个模型在 Pydantic AI(轻量、general-purpose)里跑一遍,再在 Claude Code 或 Codex(完整 coding agent 环境)里跑一遍,直接对比。这样买方关心的"模型 + 环境"组合的真实表现,而不是模型在裸调用下的理想分数。
三、最新排行(2026-09-06,1.0 版)前五名
secitbench.cribl.io 上线了一个交互式排行榜,数据每周一更新。本轮跑下来,前五名分别是:
| # | 模型 | 环境 | 准确率 | 单次成本 | 耗时 | Score / $ |
|---|---|---|---|---|---|---|
| 1 | GLM-5.3 | Pydantic AI | 81.4% ±2.9 | $2.70 | 14.0m | 30.1 |
| 2 | gpt-6-astra | Pydantic AI | 81.0% ±3.4 | $8.21 | 8.3m | 9.9 |
| 3 | Grok-4.6 | Pydantic AI | 80.7% ±3.5 | $3.27 | 7.1m | 24.6 |
| 4 | Claude-Opus-5 | Pydantic AI | 79.2% ±3.3 | $6.11 | 5.3m | 13.0 |
| 5 | Qwen3.8-Max | Pydantic AI | 78.5% ±3.1 | $3.39 | 11.1m | 23.2 |
注意几个反直觉的现象:
第一名不是任何一家美国头部。榜首是 GLM-5.3(智谱),准确率 81.4%,单次调查 2.70 美元,Score/$ 30.1——这是"高分 + 低成本"的理想组合。第二名是 OpenAI 的 gpt-6-astra,准确率 81.0% 跟第一名几乎并列,但成本 $8.21,Score/$ 只有 9.9——贵了三倍但准确率没拉开差距。
开源模型挤进第一梯队。GLM-5.3-Flash(0.28 美元 / 次,Score/$ 269.7)和 DeepSeek-V4-Flash-0731(0.284 美元 / 次,Score/$ 243.2)分列性价比榜的冠亚军,准确率都在 70% 上下。开源 + 高性价比的组合让"自托管 Agent"的成本曲线发生质变。
最贵的不一定最准。Gemini-3.8-Flash 单次 $19.24,准确率只有 69.0%,性价比榜倒数第三;Claude-Sonnet-5 准确率 63.3%,单次 $1.66。贵 ≠ 准在这个基准里被反复印证。
四、场景维度的拆分:不同模型擅长的事件类型不同
排行榜只给了一个总分,但事件调查的难点不是均匀分布的。Cribl 把 30 个场景按"事件类型"展开成了一张二维表,可以从场景维度看清每个模型的真正擅长区:
- "间歇性购物车错误" / "银行账户突破" / "登录失败"这类高频、可定位的事件——几乎所有模型都能拿到 95% 以上,前三名甚至 100%。这是 baseline 类场景,无法区分模型能力。
- "结账宕机" / "支付失败" / "热点 task-api 主机" / "图服务异常"——这类事件平均分掉到 85%-90%,GLM-5.3、gpt-6-astra、Grok-4.6 在这里拉开差距,Qwen3.8-Max、GLM-5.3-Flash 紧随其后。
- "植物传感器洪流" / "新闻邮件摘要延迟" / "广告加载缓慢" / "间歇性购物错误"——平均分掉到 50% 以下,这里 GPT-5.6-Luna、Gemini-3.8-Flash、Claude-Sonnet-5 表现尤其弱,而 Grok-4.6、Claude-Opus-5 保持 70% 以上。
- "AI 助手回答不准确" / "邮件确认慢"——所有模型都掉到 40% 上下,这类"以 AI 为根因"的场景对 Agent 的反身性挑战最大。
这个切分对采购决策的指导意义在于:如果你的真实业务是"结账 / 支付"类,前三名任何一个都够用;如果是"AI 服务自身异常 + 跨域数据外泄"这种长尾,真正拉开差距的是 Grok-4.6 和 Claude-Opus-5——而榜单总分恰恰看不出来这件事。
五、Harness 维度:环境错了,模型再强也打折
官方博客里最有实战价值的结论是这个:Harness 对成本的影响远大于对准确率的影响。
具体数据是:把同一个模型从轻量级 harness(Pydantic AI,只暴露一个 Bash 工具)切换到完整的 Coding Agent harness(Claude Code 或 Codex),中位成本效率下降 23%。也就是说,用 coding 环境去查事件调查问题,平均每个事件要花多 23% 的钱——而准确率并没有等比例提升。
官方对这件事的解读是:Software development agents are optimized for a different set of tasks, tools, and success criteria(软件开发 Agent 优化的是另一组任务、工具和成功标准)。把 coding harness 硬塞到 IT/安全场景里,模型会走很多不必要的路径——打开文件树、读项目结构、试图 git diff——这些动作对调查一个线上支付失败毫无帮助,但 token 钱照花不误。
Cribl 给出的实用建议是:评估 Agent 时不要只看"模型本体分数",要看"模型 × harness × 你的真实遥测环境"组合的 Score/$。一个不暴露完整 Coding 工具、专门为 IT/安全调查做了轻量化设计的 harness,可能比"最强模型 + 最强 Coding Agent"的组合还要经济。
六、"Cost doesn't always buy precision":基准给出的最关键警告
这是官方博客里专门起小标题强调的一个现象:
- 首批数据中,准确率最高与最低模型之间的差距只有 17 个百分点。
- 但单次调查成本从 $0.28 到 $7.34,差了 20 多倍。
- 最贵的几个组合(OpenAI 顶级模型 + coding harness)准确率并不是最高的。
官方把这个反差称为"the critical insight for any procurement strategy"(任何采购策略都要看清的真相)。翻译成业务语言就是:不要因为"贵所以准"而迷信高价模型,因为"贵"本身不保证"准";同样,不要因为开源便宜就一刀切排除,SecIT Bench 的数据明确说明——开源模型在事件调查上是有竞争力的,只是要选对型号。
七、对企业实际部署的四个建议
Cribl 在博客结尾给出了四个"评估 Agentic 解决方案时要看清的结构性问题",可以直接拿来当采购清单:
- 看它在"从未见过的事件"上的准确率。不要拿 demo 的案例给自己壮胆,要一个数字,在你能检查的场景集上跑出来。
- 看每次调查的成本。"准确率高但成本高"和"准确率略低但成本极低",长期下来差异巨大;只有准确率是半个数字。
- 看不同 harness 下的表现一致性。同一个事件换 harness 跑一次,看方差落在哪里;如果方差大,意味着你的部署稳定性高度依赖 harness 选型,风险高。
- 看它对良性场景的处理。一个"证据不足硬下结论"的 Agent,在生产里会编造事故,引入的是另一种风险——而且这种风险很难被传统的告警系统捕捉到。
官方把这件事总结成一句话:"It's not just about choosing the right model. It's about choosing the right model, tools, and environment for the job."——选模型只是 1/3,选 harness 和工具链才是另外 2/3。
八、几点需要冷静看的注意事项
Cribl 在文末的"Practitioner notes"里坦率标注了几条方法论限制,值得在引用数据时一并带上:
- 所有模型都开启最大推理配置。这意味着跑出来的是"模型理论上限",不是"默认配置日常跑"的表现。
- 准确率定义是"满足诊断条件的百分比",不是"事件通过率"。一个 79% 的分数,意思是"在 30 个事件上,平均每个事件满足 79% 的诊断条件",而不是"解决了 30 个事件中的 79%"。
- 开源模型的耗时可能受外部限流影响。排名里那些"耗时偏长"的开源条目,部分时间花在了等外部 API 限流上,不是模型自身慢。
- 成本用各家标准、非缓存 token 定价。如果你的合同拿到了缓存折扣或企业价,真实成本会显著低于表上数字。
九、SecIT Bench 给整个 Agent 行业的三个信号
第一,事件调查类 Agent 的"模型天花板"已经很高,但工程化空间更大。官方判断:"Frontier models are genuinely strong reasoners and investigators. What they lack isn't intelligence — it's an environment built for getting the job done efficiently." 这是个鼓舞人心的结论——能力问题难解,工程问题可解。
第二,性价比维度正式进入了 LLM 评估清单。SWE-Bench、HumanEval 这类只看对错的基准,在企业实际采购中越来越被"Score/$"这类复合指标挤压。SecIT Bench 直接把成本作为并列维度,等于公开承认了"便宜够用"在工程上是合理选择。
第三,"Tooling & Environment"作为一个独立的产品层被正式提出来。harness 不是免费的,选错了不仅贵 23%,还可能让它的全部 coding 经验变成误导源。这为"专用 IT/安全 Agent harness"这类新产品留出了空间——Cribl 自己就在做这件事。
十、结语:从"能不能查"到"花多少钱查"
SecIT Bench 真正改变了 Agent 评估的语境:它不再只是"模型答得对不对",而是"在 30 个真实事件里答对多少、花多少钱、花多久、在哪种 harness 下表现稳定"。这四个维度加起来,才能支撑起企业级 Agent 的采购和部署决策。
在最新一轮 1.0 版排行里,GLM-5.3、gpt-6-astra、Grok-4.6、Claude-Opus-5、Qwen3.8-Max 在准确率上几乎并列第一梯队,但 Score/$ 拉开了从 9.9 到 30.1 的巨大差距;开源阵营在性价比榜上表现尤其亮眼;Harness 维度则提示了"专业 Agent 环境"作为新产品的可能性。这些结论不是终点——Cribl 明确写了"SecIT Bench will evolve as the technology does",排行榜会持续更新——但它给出了一个起点:让 AI Agent 在 IT/安全场景下的真实表现,从 PPT 上的口号变成可以拿来对比的数字。
