← 返回藏书阁Agent Benchmarks
Agent Benchmarks
Agent Benchmarks 用来评估 AI agent 在多步任务、工具使用、代码仓库操作、UI 控制和真实专业工作流中的能力。2026 年的明显趋势是：单一总分越来越不够，需要把 agent 能力拆成多个可解释维度。
为什么传统 benchmark 不够
很多模型在学术题、短任务和静态 benchmark 上表现很强，但这不等于能完成真实工作。Agents-Last-Exam 直接指出这个断层：现有 benchmark 成绩没有充分转化为经济上有意义的专业部署。
关键评测维度
- 长程任务完成能力。
- 结果是否可验证。
- 是否有经济价值和真实职业对应关系。
- 工具调用与 MCP workflow 能力。
- UI / computer use。
- 仓库探索、上下文定位和 patch synthesis。
- 多模态理解和信息综合。
代表方向
- Agents-Last-Exam：面向真实经济任务，最难 tier 当前 full pass rate 低于 1%。
- SWE-Explore：把 coding agent 的仓库探索能力单独拆出来评估，关注 line-level coverage 和 ranking efficiency。
2026-06-30 补充：评估上下文文件本身
| [[agents-md-context-files-paper | Evaluating AGENTS.md: Are Repository-Level Context Files Helpful for Coding Agents?]] 把 benchmark 对象从模型/agent 扩展到“上下文资产”：仓库级 instructions 是否真的提升任务完成率？这对 Context-Engineering 很关键，因为它说明 context 也应该被测试和维护，而不是只凭感觉堆叠。 |
2026-07-01 补充：从 benchmark 到每次变更的局部 verdict
| [[agentops-coding-agent-verification | AgentOps coding-agent verification membrane]] 提醒我们，agent evaluation 不只发生在公开 benchmark 上，也应该发生在每次真实工程变更里。一个 PR、一次 wiki ingest、一次发布任务，都可以产生局部 verdict：PASS、REFUTE、HOLD，以及对应证据。 |
这类 micro-benchmark 的价值在于贴近真实工作流；缺点是噪音高、不可横向比较。因此它更适合作为团队/个人 workflow 的健康指标，而不是公开排行榜。
2026-07-02 补充：数据密集型 agent 评测
| [[coda-bench | CODA-BENCH]] 把 coding-agent 评测推进到数据密集型任务：agent 不只是改代码，还要在含大量噪声文件的 Linux sandbox 中发现相关数据、编写程序并产出可核验答案。它补充了一个关键维度：Discovery Accuracy。真实工程任务常常失败在“找错上下文/数据”，而不是模型不会写代码。 |
对 llm-wiki 来说，这提示我们也应评估 agent 的 discovery pipeline：是否先读 _index/log、是否搜索既有页面、是否保存 raw、是否能列出证据路径。没有 discovery verdict 的知识库回答，可能只是语言流畅但证据不稳。
2026-07-03 补充：评测不仅要测能力，还要测可靠性与完整性
| [[caliper-skill-reliability-testing | Caliper]] 和 [[proctor-signed-benchmark-integrity-bundles | Proctor]] 补充了两个以前容易被混在一起的维度：skill/workflow 的稳定性，以及 benchmark 运行的完整性。前者问“同一个 skill 重复 k 次是否稳定优于 baseline”；后者问“agent 是否接触了隐藏测试、答案、fix history 或未授权网络”。 |
这对 agent benchmark 的启发是：公开分数只是第一层，真正可用的评测至少需要三张表：任务成功率、可靠性/回归曲线、完整性/证据边界。对 Hermes 来说，每个关键自动化 workflow 都应能回答：baseline 是什么、重复运行是否稳定、完成证据是否被不该有的信息污染。
2026-07-04 补充：benchmark 要覆盖 adoption、determinism 和真实桌面任务
| [[agent-context-workshop | Agent Context Workshop]] 提醒：上下文工具的 benchmark 不能只看最终准确率，还应记录 tool adoption、重复运行确定性和 token efficiency。一个 graph 工具如果理论上有帮助但 agent 很少调用，实际价值就会大幅下降。 |
| [[pinchbench | PinchBench]] 则代表 benchmark-as-skill：用 OpenClaw 运行日历、邮件、研究、写作、代码、文件、memory、skills 等真实任务，并结合自动评分与 LLM judge。它补充了公开 agent benchmark 常缺的个人生产力/桌面 agent 维度。 |
对 Hermes 来说，下一步应把 llm-wiki 雷达自身也当成 benchmark：是否 orient、是否读原文、是否保存 raw、是否避免重复页面、是否更新 _index/log、是否能给出深度判断。没有这些 workflow 级 verdict，日报很容易退化成“看起来完整”的文字生成。
2026-07-07 补充：行动边界与 context-provider 评测
| [[underspecbench-action-boundary | UnderSpecBench]] 补充了一个 completion-centric benchmark 容易遗漏的维度：agent 是否在 intent、target 或 blast radius 不明确时越界行动。真实 DevOps / coding-agent 评测不应只奖励完成任务，也要奖励 clarification、refusal、deferment 等安全不行动。 |
| [[greplica-persistent-coding-agent-memory | Greplica]] 则代表 context-provider 评测：不是只测模型能不能写代码，而是测“持久仓库记忆”是否减少 tokens、tool calls、成本和规划时间，并提升 plan quality。对 llm-wiki 来说，wiki-vquery、_index/log、ConversationSpec 都应被看作可评测的 context provider：如果它们不能减少 rediscovery 或改善答案/计划质量，就只是上下文负担。 |
2026-07-08 补充：轨迹诊断与 review usefulness
| [[traceprobe-trajectory-structure-diagnostics | TraceProbe]] 说明 resolve rate 隐藏了关键过程差异：成功 run 也可能包含大量搜索循环、错误分支和验证跳过。未来 agent benchmark 应报告 trajectory health，包括到达相关函数/文件的速度、search loop、validation skip、reversion、无效编辑和 token/cost waste。 |
| [[swe-review-agentic-code-review | SWE-Review]] 则补充 review 维度：评估 reviewer agent 不应只看批注是否正确，还要看结构化反馈是否提升下一轮 revision 的 resolve rate。对 Hermes 来说，wiki ingest / coding task 的质量指标也应从“最终是否有文件”扩展到“路径是否健康、review 是否改善结果”。 |
2026-07-09 补充：从二值分数到行动严重度、gate firing 和 SOP 质量
| [[action-graded-severity-scale-tool-agents | Action-Graded Severity Scale]] 说明 agent safety benchmark 不能只看 binary attack-success rate；同样“被攻击成功”可能只是无害尝试，也可能是跨 scope 外传或扩权链。未来评测应报告 severity distribution、worst-case tail 和 escalation-chain 检出能力。 |
| [[deterministic-gates-tool-agent-policy | Deterministic Gates]] 提供了一个更好的 intervention 评估方式：把任务分成 gate firing 与 non-firing strata，检查提升是否集中在 gate 实际拦截的样本上。[[evosop-iterative-tool-optimization | EvoSOP]] 则把评测对象扩展到 SOP/toolset 本身：一个高阶工具是否减少 reasoning rounds、是否稳定提升成功率、是否因为 bloating 带来新错误，都应被持续测量。 |
2026-07-11 补充：原创任务、功能级 verifier 与性能优化评测
| [[deepswe-long-horizon-coding-agent-benchmark | DeepSWE]] 和 [[perfopt-bench-performance-optimization-agents | PERFOPT-Bench]] 把 coding-agent benchmark 的重点从“公开历史 patch 的通过率”推进到更接近真实工程的评测控制层。DeepSWE 强调原创长程任务、污染控制、功能级 verifier 与轨迹公开；PERFOPT-Bench 强调性能优化闭环、hidden correctness、verified speedup 和 shortcut detection。 |
对 Hermes 来说，agent benchmark 的最低可信单元应包含：任务新鲜度说明、独立 verifier、执行轨迹、污染/shortcut 风险，以及对 workflow/harness 的归因。只看 leaderboard 或单次 pass rate 容易把记忆、投机或测量噪音误判为真实工程能力。
2026-07-12 补充：proactive agent 的能力驱动闭环评测
| [[uniclawbench-proactive-agent-benchmark | UniClawBench]] 把 agent benchmark 从静态单轮答案推进到真实环境、轨迹/产物和多轮反馈：它按 Skill Usage、Exploration、Long-Context Reasoning、Multimodal Understanding、Cross-Platform Coordination 五类能力组织任务，并用 executor、hidden supervisor、user simulator 三角色闭环评估。 |
对 Hermes 来说，这给每日雷达和复杂自动化任务提供了更好的复盘 schema：失败不是笼统的“模型不行”，而应归因到工具选择、探索、长上下文一致性、多模态证据或跨平台状态协调。未来报告若出现未入库/无法验证，也应标明主要瓶颈能力。
2026-07-13 补充：benchmark 应把 harness 与 claim receipts 作为一等对象
| [[harness-benchmarks-meta-review | The harness still matters]] 说明 coding-agent 评测如果只报模型和最终成功率是不够的：harness 本身会改变 quality、cost、runtime 和 token usage。更稳的 benchmark 记录应包含 matched-model comparison、任务表面、grader、重复次数、成本、上下文量、数据可访问性和限制说明。 |
| [[did-it-claim-evidence-reconciliation | did-it]] 则补充了评测运行后的 claim audit：agent 的自然语言报告也应被评测。一个 benchmark run 可能真的执行了命令，也可能只是声称执行；因此 transcript-level receipts 可以成为低成本的 eval hygiene 层，帮助区分 backed、unsupported 和 contradicted claims。 |
2026-07-14 补充：环境生成、工具面 ablation 与仓库上下文格式也要进入 benchmark
| [[seta-scaling-environments-terminal-agents | SETA]] 把 terminal-agent benchmark 的焦点推进到“环境如何生成和演化”：任务不仅要有描述，还要有可执行 sandbox、oracle solution、post-rollout verifier 和 partial-progress reward。[[execute-code-tool-surface-ablation | execute_code 工具面限制实验]] 则说明评测必须记录 tool surface；同一模型在 bash、IDE primitives、code execution 等工具面下的成本和成功路径不可直接比较。 |
| [[aigx-context-format | AIGX]] 虽然是工具/格式项目，但它提出的 controlled benchmark claim 也提醒我们：context format 本身可以被实验比较。对 Hermes 来说，未来 workflow benchmark 应至少记录三层变量：环境/任务合同、工具面、上下文格式；否则分数无法解释，也无法迁移。 |
2026-07-15 补充：评测仓库知识获取，而不只是最终修复率
| [[acquire-qa-driven-repository-knowledge | ACQUIRE]] 提醒 coding-agent benchmark 应把 pre-repair knowledge acquisition 也作为一等评测对象。它在 SWE-bench Verified 上报告相对 Mini-SWE-Agent 提升 3.8–4.4 个 Pass@1 百分点，但更重要的是提供了可诊断中间层：Questioner 是否问到关键知识缺口，Answerer 的答案是否有证据，Resolver 是否真的使用 QA。 |
这对 Agent-Benchmarks 的启发是：最终 pass rate 之外，应增加 question quality、answer grounding、knowledge-gap coverage、QA usage rate、以及动态补问成本等指标。否则，一个 agent 可能只是偶然找到正确 patch，却没有可复用、可审计的仓库理解过程。
2026-07-16 补充：从静态分数到持续学习与工具换挡能力
| [[agent-optimizers-compound-terminal-bench | Do Agent Optimizers Compound?]] 提醒 agent benchmark 不能只测“一次优化后的固定任务分数”。真实部署更像持续学习：优化旧任务后，新任务到来时是否迁移；继续优化时是否不遗忘旧任务；长期平均 pass rate 是否提升。它把 benchmark 维度扩展为 transfer、continued improvement、lifelong average 和 regression control inside the loop。 |
| [[set-shifting-behavioral-test-harnessed-agents | Set-shifting Behavioral Test]] 则提供了工具使用的过程级指标：当 reliable tool group 在隐藏边界后变化，agent 是否能从旧 routine 切换到新目标工具。对 Hermes 来说，这类指标可以迁移为“来源/工具可靠性变化时是否换路”：PDF 404 后是否转 HTML、RSS 失败后是否转 API、shell 可替代时是否转窄工具、旧 query 低信号时是否轮换主题。 |
这说明未来 agent benchmark 至少应分三层报告：最终任务结果、能力/轨迹健康、以及跨阶段适应性。单次高分但无法迁移、无法换路或牺牲旧能力的优化，不应被视为可靠进步。
2026-07-19 补充：skill / workflow 本身也要进 CI 回归评测
| [[coder-eval-skill-evaluation-ci | coder_eval]] 把 benchmark 从“公开任务上比较模型”拉回到本地工程资产：一个 Claude Code/Codex/Gemini 配置、一个 skill、一组 prompt 或一个 llm-wiki radar workflow，都可以用声明式任务、sandbox、weighted criteria、telemetry 和 task.json verdict 进行 A/B 与回归测试。 |
这对 Agent-Benchmarks 的启发是：真实可用性评测不应只看 leaderboard；还要看团队自己的 skill 是否持续触发、上下文/工具面改变后是否退化、成本是否上升、最终报告里的 claim 是否有 artifact receipt。对 Hermes 来说，下一步可以先把“每日 radar 是否 orient/raw/index/log/write-record”做成本地结构检查，再逐步升级为完整 agent eval。
2026-07-21 补充：benchmark 应同时评分 harness 结构与运行时轨迹
| [[harness-score-maturity-scanner | Harness Score]] 说明 agent 评测可以先从 deterministic repo harness scanner 开始：是否有 context guides、skills/commands、hooks/guardrails、sensors、CI 和 hygiene。[[nemo-relay-agent-runtime-control | NeMo Relay]] 则说明运行时轨迹本身应成为评测输入：scope、tool calls、lifecycle events、raw events 和 normalized trajectories 可以解释最终成功/失败背后的路径质量。 |
这对 Agent-Benchmarks 的启发是：公开 pass rate 之外，应增加两类本地指标：pre-run harness maturity 与 in-run trajectory health。对 llm-wiki radar 来说，对一次 ingest 的 benchmark 不只是“今天是否创建了页面”，还包括是否 orient、是否保存 raw+hash、是否记录未入库原因、是否更新 _index/log、是否在工具失败后换路。
2026-07-22 补充：评测应覆盖规则采用与记录完整性
| [[vigiles-agent-harness-audit | Vigiles]] 提醒，agent benchmark 不能只看最终任务成功，也要测 harness artifact 是否真的被采用：AGENTS.md、skills、hooks、subagents 可能存在但失效，形成 false confidence。[[halo-record-runtime-records | Halo Record]] 则补充 benchmark integrity：运行轨迹如果可被删除或改写，后续评分和报告 claim 都会失去可信基础。 |
这把 agent benchmark 的 hygiene 层再推进一步：先用 lint/audit 检查规则、hook、skill 的结构和触发；再用 behavior test/eval 检查它们是否改变行为；最后用 runtime record 证明 tool trajectory 没被篡改。对 Hermes 来说，wiki-radar 的最小 benchmark 应新增两项：cron prompt 的关键要求是否被机械满足，以及最终报告中“已写入/已验证/未入库”的 claim 是否有文件或命令 receipt。
2026-07-25 补充：harness 本身需要 matched-model benchmark
| [[openbench-harness-benchmark | OpenBench]] 提供了一个清晰范式：在 Track A 中固定模型与任务，把差异归因到 coding-agent harness 的 scaffolding、tools、prompting、permission policy、token tax 和 wall-clock。它还把 Harness Bench 与 Gateway Bench 分开，避免把 harness、API gateway、router、模型选择混成一个总分。 |
对 Agent-Benchmarks 的启发是：未来评测应至少记录 model、harness、gateway、tool surface、permission policy、checker、transcripts、cost 与重复次数。对 llm-wiki radar 来说，每次 deep ingest 也可以被视为一个 micro-benchmark cell：是否 orient、是否读 source、是否保存 raw+hash、是否更新概念、是否有未入库理由、是否完成 reindex。这样才能把“日报质量”从主观感觉变成可复盘 workflow 指标。
2026-07-27 补充：视觉生成 benchmark 要测重复与 artifact integrity
| [[sitegeist-visual-diversity-benchmark | Sitegeist]] 把 agent benchmark 推到视觉/前端生成场景：100 个 neutral briefs、隔离 one-site filesystem、artifact contract、移动端/console/runtime dependency reject、exact/cross-model duplicate audits 和 gallery corpus。它提醒 benchmark 不应只问“能不能 build / 是否通过测试”，还要问开放式生成是否陷入模板化收敛、是否依赖远程资产、是否违反产物边界、是否保留可复查源代码和构建输出。 |
对 Agent-Benchmarks 的启发是增加 artifact diversity / integrity 维度：特别是 UI、文档、产品设计、营销页、图表等主观质量任务，应同时记录 generation boundary、model/harness metadata、duplicate audit、mobile/runtime verifier 和人工审阅入口。对 llm-wiki radar 来说，也可借鉴 duplicate audit：如果连续多天入库相似 harness/source note，应主动合并、写 comparison 或降级为 raw，而不是制造页面膨胀。
2026-07-28 补充：执行可靠性与报告诚实度应分开评测
| [[halu-core-claim-grounded-agent-evaluation | halu-core]] 把 agent eval 拆成 Execution Reliability 与 Reporting Honesty：一个 agent 可能完成任务但报告夸大，也可能报告声称完成但 action log 不支持。它用 scoped run token、Agent API、event-sourced audit log 和 deterministic scoring，把 final claims 与实际 action 绑定起来。 |
这对 Agent-Benchmarks 的启发是：未来 benchmark / 本地 workflow eval 不应只给最终 PASS/FAIL，还应输出 claim-level verdict：BACKED、UNSUPPORTED、CONTRADICTED、NOT-CHECKABLE。对 llm-wiki radar 来说，最终报告中的“已保存 raw / 已创建页面 / 已更新 index / 已 reindex”都应能被文件路径或命令输出支撑；无法访问或 API 失败的来源必须明确写成 HOLD/未入库，而不是被自然语言掩盖。
2026-07-29 补充：sealed harness benchmark 与评测设计边界
| [[agentbattler-bench-sealed-harness-benchmark | AgentBattler Bench]] 提供了 benchmark integrity 的具体样本：sealed schedule、container isolation、separate verifier、raw traces、snapshot hash、replay，以及在发现 native agent 可读 holdout verifier 后撤回旧 ranking。它提醒：benchmark 可信度不只来自任务难度，也来自污染控制、基础设施无效运行标记和结果可重放。 |
| [[laborant-evaluation-design-skills | Laborant]] 则把评测前置到 live system 边界设计：runner、cases、scorers、observations、metrics、supported claims 和 limitations 都要先被写明。对 Hermes / llm-wiki 来说，未来评测应同时覆盖两层：先用 Laborant 式 design 明确要证明什么，再用 AgentBattler 式 integrity 证明结果没有被泄漏、污染或基础设施失败掩盖。 |
2026-07-30 补充：workflow review 可作为个人级 micro-benchmark
| [[better-harness-evidence-bounded-workflow-review | Better Harness]] 提醒，agent benchmark 不一定都要是公开排行榜；对个人/团队更有价值的常常是 workflow-level micro-benchmark：每次任务是否有足够上下文、是否在受控路径执行、是否有真实验证、是否留下交付/学习证据。 |
这对 llm-wiki radar 的评测很直接：日报质量不应只看发现数量或页面数量，而应看深度判断、原文证据、未入库说明、index/log/vector 维护和自我优化是否形成闭环。未来可以把每次 radar 报告按 PASS / PARTIAL / HOLD 标注，而不是只输出自然语言总结。
2026-07-31 补充：工具/server 接入也需要 agentic eval
mcp-gauntlet-agentic-mcp-server-evaluator 把 benchmark 对象从模型和 coding harness 扩展到 MCP server 本身：一个 server 静态 schema 合法，不代表 agent 能正确选工具、完成任务，也不代表 live outputs 不会携带 prompt injection。它的 report card 同时覆盖 schema、description、security、task success、tool reliability、response safety、robustness 和 definition drift。
这对 Agent-Benchmarks 的启发是：未来本地评测应包含 adoption target。评估一个 MCP server、skill、context layer 或 loop supervisor 时，不能只测“组件存在/命令能跑”，还要测 agent 是否在代表性任务中正确采用它、是否减少错误/成本、是否引入新的安全或漂移风险。
2026-08-02 补充：trajectory collection 与 controlled-language eval
axisagentic-runtime-trajectory-framework 说明 agent benchmark 的输入不应只包含最终答案，还应包含模型可见上下文、工具事件、token/timing、evaluation artifacts 和 provenance。这样的 trajectory 才能支持 recovery、replay、失败归因和高质量 SFT export。simpleenglish-controlled-language-agent-skill 则提醒输出质量也能被规则化评测：减少歧义、短句、明确动作和违反受控语言规则的数量，都是比“看起来专业”更可复查的指标。
对 llm-wiki radar 来说，日报评测可以继续收紧为 claim-level receipts：哪些来源已读取、哪些 raw 已保存、哪些页面已更新、哪些只是候选未入库。语言上则应偏向受控、明确、少营销的工程报告。
写入记录
- 2026-08-02 09:01 CST：补充 OptMem、AxisAgentic、Agent Graph、SimpleEnglish 对长期记忆、轨迹证据、事实路由 skill 和受控语言评测的启发。
- 2026-07-31 09:01 CST：补充 mcp-gauntlet 对 MCP server / skill / context layer adoption eval 的启发。
- 2026-07-30 09:00 CST：补充 Better Harness 对 workflow-level micro-benchmark、证据化日报和 radar PASS/PARTIAL/HOLD verdict 的启发。
- 2026-07-29 09:00 CST：补充 AgentBattler Bench 与 Laborant 对 sealed benchmark integrity、撤榜纪律、eval design boundary 和 llm-wiki workflow 评测的启发。
- 2026-07-28 09:00 CST：补充 halu-core 对 Execution Reliability、Reporting Honesty、claim-level receipt 与 wiki-radar 报告诚实度评测的启发。
- 2026-07-27 09:07 CST：补充 Sitegeist 对视觉生成 benchmark、artifact diversity / integrity、重复审计和 llm-wiki 页面膨胀检测的启发。
- 2026-07-22 09:00 CST：补充 Vigiles 与 Halo Record 对规则采用评测、false confidence、runtime record integrity 和 wiki-radar claim receipt benchmark 的启发。
- 2026-07-21 09:01 CST：补充 Flow-Next、Harness Score、NeMo Relay、FastContext 对 agent workflow、harness scoring、runtime trajectory 或只读上下文探索的启发。
- 2026-07-19 09:04 CST：补充 coder_eval 对 skill/workflow CI 回归评测、A/B 配置、artifact receipt 的启发。
- 2026-07-01 09:00 CST：补充 AgentOps 将 benchmark 思路下沉到日常工程 verdict 的观察。
- 2026-07-02 09:00 CST：补充 CoDA-Bench 的数据密集型 agent 评测与 discovery accuracy 维度。
- 2026-07-03 09:00 CST：补充 Caliper / Proctor 对 skill 可靠性和 benchmark 完整性的启发。
- 2026-07-04 09:00 CST：补充 Agent Context Workshop 与 PinchBench 对 adoption、determinism、真实桌面任务和 wiki-radar benchmark 的启发。
- 2026-07-07 09:00 CST：补充 UnderSpecBench 的行动边界评测与 Greplica 的 context-provider planning benchmark。
- 2026-07-08 09:00 CST：补充 TraceProbe 的 trajectory health 维度与 SWE-Review 的 review usefulness 维度。
- 2026-07-09 09:00 CST：补充 deterministic gates、action-graded severity 与 EvoSOP 对 harness / benchmark / skill 生命周期的启发。
- 2026-07-11 09:00 CST：补充 DeepSWE 与 PERFOPT-Bench 对原创长程任务、功能级 verifier、性能优化评测和 shortcut detection 的启发。
- 2026-07-12 09:00 CST：补充 UniClawBench 对 proactive agent 能力驱动闭环评测和 Hermes 复盘维度的启发。
- 2026-07-13 09:00 CST：补充 harness-benchmarks 与 did-it 对 harness-level evaluation、成本/质量/token 记录和 claim receipts 的启发。
- 2026-07-14 09:00 CST：补充 SETA、execute_code 工具面实验与 AIGX 对环境生成、工具面、仓库上下文格式的启发。
- 2026-07-15 09:02 CST：补充 ACQUIRE 对 pre-repair QA、知识缺口覆盖、answer grounding 和 QA usage 评测维度的启发。
- 2026-07-16 09:00 CST：补充持续学习 agent optimizer 与 set-shifting 评测，把 benchmark 维度扩展到 transfer、continued improvement、lifelong average、regression control 和工具换挡能力。