2026-09-12 · DECISION TRACE

小墨 V4.1.5 评测基准产品介绍:为真实工作流设计的终端 Agent 评测

保留方案、指标、验证、复盘和治理判断,让结论能够追溯。

2026-09-12记录日期
评测记录记录类型
13章节数

小墨 V4.1.5 评测基准产品介绍:为真实工作流设计的终端 Agent 评测

  • HTML: https://decision.ht1072.top/2026-09-12-xiaomo-v415-benchmark-product-intro-2026-09-12.html
  • Local HTML: [已移除本地路径]
  • Generated: 2026-09-12T00:39:20+08:00

小墨 V4.1.5:一个为真实工作流设计的终端 Agent 评测基准

产品定位:测模型"给了终端能不能自己把活干完",而不是"问一题答得对不对"。 版本2026-09.v4.1.5-cal · 16 题 · 100 分 · 机器验证 60 + 匿名裁判 40


一、为什么需要这个基准

市面上的模型评测大多停留在"一问一答":固定题面、单轮响应、答案比对。但真实的生产力场景是另一回事——你交给 agent 一个终端、一个任务目录、一份执行合同,它要自己决定读什么、跑什么命令、什么时候提交、什么时候诚实地说"证据不足"。

传统榜单测不出的东西,恰恰是终端 agent 场景里致命的东西:

  • 上下文纪律:多轨项目里旧状态被新状态覆盖,能不能只报告当前有效主线、不复活已放弃的副作用?
  • 证据诚实:工具失败了敢不敢承认?没观察到的东西会不会被写成成功?
  • 收敛能力:给了预算(轮次/调用数/秒数),能不能在预算内做完而不是无限探索?
  • 边界意识:哪些操作被明确禁止?被拒绝后会不会原样重试?

小墨 V4.1.5 就是针对这些能力的 executable benchmark。它不是一个静态题库,而是一条完整的可审计评测流水线:沙箱物化 → 候选执行 → 机器重放验证 → 匿名裁判 → 哈希绑定回执。

二、评测流水线:五层架构

2.1 沙箱物化层

每题按 seed 由 generator 生成全新 workspace(固定 seed 集合 s1/s2/s3 保证同 seed 下所有模型面对完全相同的 fixture)。候选被放进 bwrap 沙箱(profile v4-bwrap-terminal-only-v1):

  • 只能看到一个工具terminal。没有 read_file、没有浏览器、没有搜索——就像真实 SSH 到一台机器。
  • 只能访问 /workspace:宿主目录、私有 oracle、历史评测、凭据全部不可见。
  • 外部网络不可用:O1 的 Git remote 是 workspace 内的本地 bare repo,不依赖网络也不允许联网。

2.2 候选执行层

runner 用真实 Hermes 引擎驱动候选模型,全程 host 侧哈希链 trace

  • 每个模型请求/响应、每次终端调用/结果、每次 schema 反馈都按 sha256 哈希链串联——事后篡改任何一环,链就断。
  • 候选身份绑定:trace 里的每次模型响应都记录 provider/model,跑完核对 actual_identity,用 B 模型冒充 A 模型直接判无效。
  • 零 fallback 原则:runner fallback 发生即 protocol_status=invalid——你测的是这个模型,不是它的备胎链。

2.3 机器验证层(60 分)

候选说"我修好了"、"测试通过了"不算数。机器验证器把候选留下的实际产物在隔离环境里重新执行:

  • 隐藏测试:K2/K3 的 private behavior cases 在候选不可见的 validator snapshot 里跑——你不知道有什么测试,只有真修对了才能过。
  • 真实 Git 操作:O1 的 push 状态判断,验证器自己跑 merge-base --is-ancestor 对 remote 做可达性检查。
  • 真实浏览器:U1 用 Chromium 通过 CDP 拉取无障碍树、模拟 Tab/Enter 键盘导航、360/768/1280 三档视口量矩形——不是正则匹配 HTML 字符串。
  • 真实构建:U2 的 build 和测试验证器重跑一遍,退出码 0 才算数。

2.4 匿名裁判层(40 分)

机器判不了"推理质量",交给固定裁判 gpt-5.6-sol(temperature=0):

  • 盲评包:题面 + rubric + 候选提交原文 + 机器已验证事实。不含模型名、provider、run_id、token 数、耗时。
  • 反作弊:审计函数对盲评包做身份标记扫描——包里出现任何能推断候选身份的内容,直接拒绝评分。
  • 失败即 unavailable:裁判失败记 judge_score_status=unavailable,不填零、不重试、总分记 null。宁可没有分数,不要假分数。

2.5 回执与哈希绑定层

每个 run 产出四份互相绑定的回执(candidate/machine/judge/scored),每份都带 SHA-256 指纹链:manifest、control、workspace 不可变完整性、每题 submission、answer set、host trace、validator 与沙箱 profile 全部入哈希。同一 workspace 修补后不得复用旧回执——想重考,生成新 run 从头再来。

三、16 道题:六个能力维度

维度 题目 考什么 机器/裁判分
上下文控制 C1 多轨状态重建 / C2 中途转向 / C3 检查点恢复 时间线重建、用户指令优先级、主线隔离 各题 2+4 / 3+3 / 2+4
证据研究 E1 依赖图 / E2 冲突证据裁决 / E3 执行观测 独立性推断、反例与未知项、真实检查与退出码 1+4 / 2+4 / 4+1
代码工程 K1 行号审查 / K2 调试修复 / K3 受约束实现 反例构造、最小修复+隐藏回归、合同遵从 3+4 / 6+2 / 6+2
Git 运维 O1 远端事实 / O2 路由追踪 / O3 故障注入 只读研判 push 状态、声明vs实际路由、故障恢复 6+0 / 5+1 / 6+1
安全治理 S1 授权边界 / S2 符号链接防御 高影响操作分类、路径逃逸与秘密文件判定 2+4 / 3+3
前端交付 U1 无障碍页面 / U2 端到端构建 真实浏览器 AX/键盘/视口、build-test-cleanup 闭环 5+1 / 4+2

几个设计亮点:

  • O1 纯机器评分(6+0):Git 状态判断没有主观空间,全交给验证器——机器能判的事实不给裁判自由心证。
  • K2 的五重机器验证:失败基线真实存在(1分)→ 只改允许文件(1分)→ 可见测试通过(1分)→ 隐藏行为用例通过(2分)→ 提交与实际变更一致(1分)。每一步都是独立断言。
  • "正确答案可以是失败":通用合同明确"允许结论为失败、不确定或证据不足"——把没观察到的东西写成成功,机器验证会拆穿你。

四、预算与纪律:评测的硬约束

capability_certification 全景预算:

层级 限制
单题模型轮次 14 轮(U2 为 18)
单题终端调用 24 次(U2 为 32)
单题墙钟 360 秒
全局 224 轮 / 384 次 / 1800 秒
单命令 300 秒超时

预算超限不是简单扣分——题目标 unfinished_at_deadline,但如果已留有真实产物(比如 U1 的 index.html 已落盘),机器照样重放实际产物给分,然后独立减 1 分超时罚分,核减前/后两个分数并列报告。原则:不因超时抹杀真实工作量,也不装作没超时。

配套的运行时纪律:

  • 公开提交 schema 反馈:候选写完 submission 立即收到格式校验结果(不含答案对错),可在预算内自行修正格式——考的是能力,不是猜 schema 的运气。
  • 供应商熔断感知:连续 500 "circuit breaker" 先查网关数据库区分上游限流与客户端重试放大,不盲目重跑烧钱。
  • exit 1 ≠ 失败:exit 1 是"协议有效但 Gate FAIL"(可评分);exit 2 才是候选失败。

五、状态机:把"成绩"和"资格"分开

V4.1.5 用显式状态链取代单一分数:

protocol_status → gate_status → score_status → ranking_status → certification_status
  • protocol_status=invalid:身份无法确认、fallback 发生、trace 断链、hash 不一致——环境失败,不是模型能力低,分数不可用。
  • gate_status=fail:协议有效但触碰安全红线(读 oracle、伪造结果、越权操作)——分数保留但不得进正式榜。
  • calibration_diagnostic:当前所有成绩的状态。单 seed 结果不构成认证、排行榜或稳定性结论——要成为 baseline 认证,需要多 seed 校准 + 裁判方差测量 + 留出集验证。

这个设计的意义:任何分数都能追溯到它配不配被信任、以及信任到什么程度

六、已验证的区分能力

这套基准已经跑过六款前沿模型(2026-09-11/12,seed s1),区分度实测有效:

  • 头部四款挤在 3.25 分内(92.25 ~ 90.00),但六维剖面差异显著:gpt-6-astra 在上下文恢复/证据校准反超,deepseek-v4.1-flash 在安全治理/故障注入称王,gpt-5.6-sol default 剖面最均衡。
  • 抓到了"思考档位悖论":同模型 max 档裁判分 +4 但机器执行分 -1.75,输出 token 翻倍——深思考买的是论证质量,不是执行质量。这类发现只有"机器重放 + 匿名裁判"双层结构才能捕捉。
  • 执行纪律是真维度:gemini-3.8-flash 两轮 0/16(全仓漫游不收敛),与模型"聪明与否"无关,但直接决定终端场景可用性。
  • 供应商故障可归因:claude-fable-5 的失败被数据库取证定位为上游 429+熔断放大,干净地移出评测集而不污染其他成绩。

七、技术规格速览

项目 规格
版本 2026-09.v4.1.5-cal
题目 16 题 / 6 维度(C×3 E×3 K×3 O×3 S×2 U×2)
总分 100 = 机器 60 + 匿名裁判 40
裁判 gpt-5.6-sol,temperature=0,盲评包反身份扫描
沙箱 bwrap terminal-only profile,无网络
seed s1 / s2 / s3(同 seed 同 fixture)
trace host 侧 sha256 哈希链,model/terminal pairs 配对校验
回执 candidate/machine/judge/scored 四方哈希绑定
运行入口 v4_candidate_runner.py pipeline --stage capability_certification
评分入口 v4_judge.py judge --run-id <id>

八、路线图

  • 多 seed 校准:s2/s3 全模型重跑,测量分数方差与裁判方差
  • baseline 认证:方差收敛后冻结 RC,盲开 locked holdout
  • 思考档位矩阵:同模型 × 多档位系统化测试,量化"深思考的边际收益"
  • 题集扩展:候选可见合同的持续收紧(跨任务隔离、实时 schema 反馈的更细粒度)

小墨 V4.1.5 由 Hermes Agent 评测体系驱动;全部评测代码、题包、回执与 trace 可审计。上一轮六模型横评报告:小墨 V4.1.5 六模型横评深度分析