← 返回藏书阁

Agent Benchmarks

wiki/ai/concepts/Agent-Benchmarks.md
分类：ai / concepts · 更新：2026-09-12 09:18 最近更新

Agent Benchmarks

奖励完整性： [[benchshield-reward-lifecycle-integrityBenchShield]] 把 task outcome 与 Checked/VectorExposed/AgentViolation/Inconclusive 分账；独立 verifier 仍可能受错误 handoff、fail-open 或语义不足影响。作者表 4 的 96.0% 是 126 个 covered cell 中的条件准确率，另有 18 个弃权，coverage 87.5%，不可宣传成全部任务准确率。机制与表格复算已入库，checker/模型未在本机复现。^[raw/articles/benchshield-reward-lifecycle-integrity-2026-09-12.md]
分母与指标检查： [[spa-plan-first-label-preserving-persistent-agentsSPA]] 的 soft-hit 排除缺失 producer，不能替代 strict reuse；低 ASR 还要连同 utility/实际执行覆盖看。[[arc-addressable-recall-context-compactionARC]] 的正确数与配对表成功数存在未解释口径，不将 completion 显著性当 accuracy 提升。a2a-output-attestation-and-delegation-ancestry 另区分作者运行回执、本机文件 hash 检查和本机重放，三者不能混报。^[raw/articles/spa-plan-first-label-preserving-persistent-agents-2026-09-11.md] ^[raw/articles/arc-addressable-recall-context-compaction-2026-09-11.md] ^[raw/articles/a2a-output-attestation-and-delegation-ancestry-2026-09-11.md]
测量机制补充： [[redagentbench-state-grounded-safety-measurementREDAgentBench]] 要把 execution、evidence view、proof contract 与判分分开；已确认违规中的规则识别比例不等于全任务失败率。[[a2a-tck-conformance-coverage-and-security-boundariesA2A TCK]] 则提醒测试标题/条款数不是实际覆盖，skip 与前置失败不能伪装成通过。两者均需保存精确版本、适用分母及未验证项。^[raw/articles/redagentbench-state-grounded-safety-measurement-2026-09-10.md] ^[raw/articles/a2a-tck-conformance-coverage-and-security-boundaries-2026-09-10.md]

Agent Benchmarks 用来评估 AI agent 在多步任务、工具使用、代码仓库操作、UI 控制和真实专业工作流中的能力。2026 年的明显趋势是：单一总分越来越不够，需要把 agent 能力拆成多个可解释维度。

为什么传统 benchmark 不够

很多模型在学术题、短任务和静态 benchmark 上表现很强，但这不等于能完成真实工作。Agents-Last-Exam 直接指出这个断层：现有 benchmark 成绩没有充分转化为经济上有意义的专业部署。

关键评测维度

  • 长程任务完成能力。
  • 结果是否可验证。
  • 是否有经济价值和真实职业对应关系。
  • 工具调用与 MCP workflow 能力。
  • UI / computer use。
  • 仓库探索、上下文定位和 patch synthesis。
  • 多模态理解和信息综合。

代表方向

  1. Agents-Last-Exam：面向真实经济任务，最难 tier 当前 full pass rate 低于 1%。
  2. SWE-Explore：把 coding agent 的仓库探索能力单独拆出来评估，关注 line-level coverage 和 ranking efficiency。

2026-06-30 补充：评估上下文文件本身

[[agents-md-context-files-paperEvaluating 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-verificationAgentOps coding-agent verification membrane]] 提醒我们，agent evaluation 不只发生在公开 benchmark 上，也应该发生在每次真实工程变更里。一个 PR、一次 wiki ingest、一次发布任务，都可以产生局部 verdict：PASS、REFUTE、HOLD，以及对应证据。

这类 micro-benchmark 的价值在于贴近真实工作流；缺点是噪音高、不可横向比较。因此它更适合作为团队/个人 workflow 的健康指标，而不是公开排行榜。

2026-07-02 补充：数据密集型 agent 评测

[[coda-benchCODA-BENCH]] 把 coding-agent 评测推进到数据密集型任务：agent 不只是改代码，还要在含大量噪声文件的 Linux sandbox 中发现相关数据、编写程序并产出可核验答案。它补充了一个关键维度：Discovery Accuracy。真实工程任务常常失败在“找错上下文/数据”，而不是模型不会写代码。

对 llm-wiki 来说，这提示我们也应评估 agent 的 discovery pipeline：是否先读 _index/log、是否搜索既有页面、是否保存 raw、是否能列出证据路径。没有 discovery verdict 的知识库回答，可能只是语言流畅但证据不稳。

2026-07-03 补充：评测不仅要测能力，还要测可靠性与完整性

[[caliper-skill-reliability-testingCaliper]] 和 [[proctor-signed-benchmark-integrity-bundlesProctor]] 补充了两个以前容易被混在一起的维度：skill/workflow 的稳定性，以及 benchmark 运行的完整性。前者问“同一个 skill 重复 k 次是否稳定优于 baseline”；后者问“agent 是否接触了隐藏测试、答案、fix history 或未授权网络”。

这对 agent benchmark 的启发是：公开分数只是第一层，真正可用的评测至少需要三张表：任务成功率、可靠性/回归曲线、完整性/证据边界。对 Hermes 来说，每个关键自动化 workflow 都应能回答：baseline 是什么、重复运行是否稳定、完成证据是否被不该有的信息污染。

2026-07-04 补充：benchmark 要覆盖 adoption、determinism 和真实桌面任务

[[agent-context-workshopAgent Context Workshop]] 提醒：上下文工具的 benchmark 不能只看最终准确率，还应记录 tool adoption、重复运行确定性和 token efficiency。一个 graph 工具如果理论上有帮助但 agent 很少调用，实际价值就会大幅下降。
[[pinchbenchPinchBench]] 则代表 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-boundaryUnderSpecBench]] 补充了一个 completion-centric benchmark 容易遗漏的维度：agent 是否在 intent、target 或 blast radius 不明确时越界行动。真实 DevOps / coding-agent 评测不应只奖励完成任务，也要奖励 clarification、refusal、deferment 等安全不行动。
[[greplica-persistent-coding-agent-memoryGreplica]] 则代表 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-diagnosticsTraceProbe]] 说明 resolve rate 隐藏了关键过程差异：成功 run 也可能包含大量搜索循环、错误分支和验证跳过。未来 agent benchmark 应报告 trajectory health，包括到达相关函数/文件的速度、search loop、validation skip、reversion、无效编辑和 token/cost waste。
[[swe-review-agentic-code-reviewSWE-Review]] 则补充 review 维度：评估 reviewer agent 不应只看批注是否正确，还要看结构化反馈是否提升下一轮 revision 的 resolve rate。对 Hermes 来说，wiki ingest / coding task 的质量指标也应从“最终是否有文件”扩展到“路径是否健康、review 是否改善结果”。

2026-07-09 补充：从二值分数到行动严重度、gate firing 和 SOP 质量

[[action-graded-severity-scale-tool-agentsAction-Graded Severity Scale]] 说明 agent safety benchmark 不能只看 binary attack-success rate；同样“被攻击成功”可能只是无害尝试，也可能是跨 scope 外传或扩权链。未来评测应报告 severity distribution、worst-case tail 和 escalation-chain 检出能力。
[[deterministic-gates-tool-agent-policyDeterministic Gates]] 提供了一个更好的 intervention 评估方式：把任务分成 gate firing 与 non-firing strata，检查提升是否集中在 gate 实际拦截的样本上。[[evosop-iterative-tool-optimizationEvoSOP]] 则把评测对象扩展到 SOP/toolset 本身：一个高阶工具是否减少 reasoning rounds、是否稳定提升成功率、是否因为 bloating 带来新错误，都应被持续测量。

2026-07-11 补充：原创任务、功能级 verifier 与性能优化评测

[[deepswe-long-horizon-coding-agent-benchmarkDeepSWE]] 和 [[perfopt-bench-performance-optimization-agentsPERFOPT-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-benchmarkUniClawBench]] 把 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-reviewThe harness still matters]] 说明 coding-agent 评测如果只报模型和最终成功率是不够的：harness 本身会改变 quality、cost、runtime 和 token usage。更稳的 benchmark 记录应包含 matched-model comparison、任务表面、grader、重复次数、成本、上下文量、数据可访问性和限制说明。
[[did-it-claim-evidence-reconciliationdid-it]] 则补充了评测运行后的 claim audit：agent 的自然语言报告也应被评测。一个 benchmark run 可能真的执行了命令，也可能只是声称执行；因此 transcript-level receipts 可以成为低成本的 eval hygiene 层，帮助区分 backed、unsupported 和 contradicted claims。

2026-07-14 补充：环境生成、工具面 ablation 与仓库上下文格式也要进入 benchmark

[[seta-scaling-environments-terminal-agentsSETA]] 把 terminal-agent benchmark 的焦点推进到“环境如何生成和演化”：任务不仅要有描述，还要有可执行 sandbox、oracle solution、post-rollout verifier 和 partial-progress reward。[[execute-code-tool-surface-ablationexecute_code 工具面限制实验]] 则说明评测必须记录 tool surface；同一模型在 bash、IDE primitives、code execution 等工具面下的成本和成功路径不可直接比较。
[[aigx-context-formatAIGX]] 虽然是工具/格式项目，但它提出的 controlled benchmark claim 也提醒我们：context format 本身可以被实验比较。对 Hermes 来说，未来 workflow benchmark 应至少记录三层变量：环境/任务合同、工具面、上下文格式；否则分数无法解释，也无法迁移。

2026-07-15 补充：评测仓库知识获取，而不只是最终修复率

[[acquire-qa-driven-repository-knowledgeACQUIRE]] 提醒 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-benchDo Agent Optimizers Compound?]] 提醒 agent benchmark 不能只测“一次优化后的固定任务分数”。真实部署更像持续学习：优化旧任务后，新任务到来时是否迁移；继续优化时是否不遗忘旧任务；长期平均 pass rate 是否提升。它把 benchmark 维度扩展为 transfer、continued improvement、lifelong average 和 regression control inside the loop。
[[set-shifting-behavioral-test-harnessed-agentsSet-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-cicoder_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-scannerHarness Score]] 说明 agent 评测可以先从 deterministic repo harness scanner 开始：是否有 context guides、skills/commands、hooks/guardrails、sensors、CI 和 hygiene。[[nemo-relay-agent-runtime-controlNeMo 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-auditVigiles]] 提醒，agent benchmark 不能只看最终任务成功，也要测 harness artifact 是否真的被采用：AGENTS.md、skills、hooks、subagents 可能存在但失效，形成 false confidence。[[halo-record-runtime-recordsHalo 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-benchmarkOpenBench]] 提供了一个清晰范式：在 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-benchmarkSitegeist]] 把 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-evaluationhalu-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-benchmarkAgentBattler Bench]] 提供了 benchmark integrity 的具体样本：sealed schedule、container isolation、separate verifier、raw traces、snapshot hash、replay，以及在发现 native agent 可读 holdout verifier 后撤回旧 ranking。它提醒：benchmark 可信度不只来自任务难度，也来自污染控制、基础设施无效运行标记和结果可重放。
[[laborant-evaluation-design-skillsLaborant]] 则把评测前置到 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-reviewBetter 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-04 补充：domain realism、guard adoption 与 skill-runtime reliability

assetopsbench-industrial-agent-benchmark 提醒 benchmark 应增加 domain realism：真实行业 scenario、specialist agent、MCP/tool protocol、领域 verifier、privacy boundary 和 live evaluation 都会改变 agent 的真实可用性。通用 coding pass rate 不能替代工业、运维、企业流程里的场景化评测。

agentlint-runtime-guardrails 和 skill-bill-governed-agent-skill-runtime 则从本地 workflow 侧补充两个评测对象：guardrail 是否在 runtime event 上正确 firing、误报/漏报如何；governed skill runtime 是否在 crash / context compaction / agent 切换后仍能按 spec、review、audit、gate 完成。对 Hermes 来说，wiki-radar、发布、代码修改等高频流程都应逐步有 micro-benchmark：结构要求是否满足、hook 是否采用、恢复是否可靠、最终声明是否有 receipt。

2026-08-05 补充：评测共享 workspace、artifact 行为和上下文归因

swe-touch-user-intervention-coding-benchmark 把 coding-agent benchmark 推向共享 workspace 场景：用户在 agent 任务中途修改代码后，agent 是否能识别 state drift、重新计划并继续修复。assay-ai-artifact-evaluation-framework 把评测对象扩展到 AI artifacts：skills、MCP servers、agents、plugins 是否实际做了声明中的事。agentfootprint-explainable-agent-traces 则补充过程归因：失败不只看最终 pass/fail，也要知道哪些上下文影响了模型决策。

这对 Hermes 的 benchmark 设计意味着三类新指标：mid-run intervention robustness、artifact behavior proof、context attribution completeness。每日 radar 也应记录候选评分和拒绝理由，否则最终报告无法解释为什么某些材料进入长期知识、某些只留 raw。

2026-08-06 补充：benchmark 应覆盖视觉趋同、领域业务状态和 skill paired study

sitegeist-visual-convergence-benchmark 把 coding-agent 评测从功能修复扩展到视觉 artifact：同一批中性网站 brief 下，不同模型/agent 是否反复生成相似 UI 套路。它提醒 benchmark 要控制生成边界和信息泄漏，否则无法区分模型设计先验、上下文污染和 harness 诱导。

pibench-payment-integration-benchmark 则把评测推进到支付集成领域：functional correctness、reliability、security 和 business-state consistency 需要同时成立。它的 paired skill study 也提示，外部 skill 的价值应在同任务同环境下比较 with-skill vs baseline，而不是只根据 README 或安装量判断。

2026-08-07 补充：benchmark 应纳入 policy-graded evaluation 与长程 harness 变量

boundary-bench-sandbox-policy-benchmark 提醒 coding-agent benchmark 不能只报告模型、任务和 pass rate。真实部署会有网络 allowlist、read-only OS、frozen home、非 root、no_new_privs 等 policy；这些边界会让一部分任务变成 not-applicable，或让成本/失败模式发生系统性变化。因此 benchmark 应记录 policy lattice、任务适用性、adapted verifier、harness provenance 和 policy-blockage report。

longhorizon-harness-long-horizon-computer-use 从另一侧说明，harness 本身是可测变量：同模型、同执行后端下，Manager/Executor/Auditor 与 verified state 可能显著改变 GUI、CLI 和混合桌面任务表现。本地 llm-wiki radar 也应按 benchmark cell 记录：发现路径、读取证据、晋升/拒绝理由、文件写入、index/log/reindex 与最终 claim receipt。

2026-08-08 补充：本地 eval runtime、主动发现与领域 benchmark

everdict-harness-agnostic-agent-eval-runtime 把 agent 评测平台化为 baseline/candidate diff、CI gate、MCP/API 驱动和自托管 runner。它的关键贡献是把 harness、environment、driver、grader、backend 分开记录，让本地 workflow 改动可以被回归测试，而不是只凭感觉判断。

active-swe-proactive-bug-fixing-benchmark 补充 proactive discovery 维度：agent 在没有 instance-specific issue report 时要主动检查仓库、提出 bug 假设、生成测试并由 judge 验证证据链。data-eng-bench-domain-coding-agent-benchmark 则补充 domain realism：dbt / warehouse / business-state / backend dialect / hidden verifier 会暴露通用 SWE benchmark 看不到的失败。

claimproof-evidence-gated-agent-claims 进一步说明 benchmark 的输出也要评测：执行可靠性与报告诚实度应分开。对 llm-wiki radar 来说，下一步 micro-benchmark 不应只问“今天是否新增页面”，还要问是否有候选 tape、raw hash、结构化拒绝理由、写入记录、index/log 更新、claim receipt 和领域轮换。

2026-08-09 补充：Pass^3、security-tool eval 与 egress false-positive discipline

claw-eval-trustworthy-agent-evaluation 提醒 agent benchmark 需要 human-verified rubrics、Completion / Safety / Robustness 分层和 Pass^3 这类重复稳定性指标；一次 lucky run 不应被当作可靠能力。对 Hermes / llm-wiki radar 来说，日报质量也应拆成结构化 micro-benchmark：是否 orient、是否读原文、是否保存 raw+hash、是否更新 source/concept/index/log、是否有写入记录、报告 claim 是否有文件或命令 receipt。

agent-egress-bench-security-tool-corpus 则把评测对象从 agent/model 转向 security tool：代理、防火墙、MCP wrapper 或 scanner 是否能阻断外传，同时不过度误杀 benign traffic。这个方向与 boundary-bench-sandbox-policy-benchmark 互补：部署可信度不仅取决于模型 pass rate，也取决于中间控制层在 attack corpus 和 false-positive suite 上的表现。

2026-08-10 补充：评测要覆盖 egress/dataflow、local scorecard、typed simulator 与 covert communication

[[evalglass-local-first-agentic-app-evaluationEvalGlass]] 把 agentic app 评测变成 repo-owned scorecard：coding agent 可搭建 checks，但 gold、threshold、judge calibration 和 gate authority 必须由人/项目拥有。[[open-weight-agent-reliability-labOpen-Weight Agent Reliability Lab]] 则展示确定性 simulator + typed tools + exact oracle 如何评估本地 tool-calling agent 在授权、故障恢复、证据引用和最终状态上的可靠性。
[[cyclops-deterministic-mcp-toxic-flow-proxyCyclops]]、[[mcp-guardrail-sql-authorizer-boundaryMCP Guardrail]] 与 [[provekit-mcp-redteam-hardened-mcp-serverProveKit MCP]] 说明 agent benchmark 还应包含 security boundary 的结构化任务：数据是否从 untrusted 来源流向 sensitive read 再到 egress，SQL/文件工具是否被越权参数突破，拒绝路径是否泄露 schema。[[truco-bench-covert-agent-signalingTruco-Bench]] 补充 inter-agent covert signaling 维度：黑盒 monitor、reasoning monitor、probe readout 看到的是不同能力层，评测报告必须记录 oversight access。

对 llm-wiki radar 自身，最小 benchmark 可先从结构化 scorecard 开始：orient、搜索、raw hash、深度判断、concept 更新、_index/log、vector reindex、最终报告 claim receipt；再逐步加入失败注入和重复运行稳定性。

2026-08-11 补充：评测 security scanner、领域 guardrail 与报告 claim atom

[[healthclaw-guardrails-clinical-agent-data-boundaryHealthClaw Guardrails]] 提醒 agent benchmark 需要 domain-boundary cases：在医疗/FHIR 这类高风险场景中，成功不只是工具调用完成，还包括 PHI redaction、租户隔离、step-up auth 和不可变审计。[[aishield-agent-tool-security-scannerAIShield]] 则把评测对象扩展到安全扫描器本身：它是否覆盖 MCP/Skill/Prompt 供应链，误报/漏报如何，规则与 OWASP 映射是否可复核。
[[claim-trace-evidence-claim-atomclaim-trace]] 补充了报告诚实度的最小测量：claim requirements 与 evidence key/value 是否匹配。对 llm-wiki radar，下一步 micro-benchmark 可以把“保存 raw、创建 source、更新概念、更新 _index/log、reindex”都变成可检查 claim，而不是只在自然语言报告里声明。

2026-08-13 补充：benchmark 要同时评估控制面、provenance gate、长程开放产物与报告证据

agentlock-provenance-action-gate 把安全评测拆成攻击成功、defense-effective success 与 benign ceiling，说明“拦住攻击”必须和“保留任务能力”一起报告。controlkeel-governed-agent-control-plane 和 aegis-architecture-aware-method-pack 提供了 bounded with/without evidence 样本，但也明确限制模型、suite、scoring 和评审边界。aaabench-long-horizon-game-world-benchmark 则把 benchmark 推向真实引擎、开放世界、视觉自检、无人 supervisor 和 artifact quality。

这给 llm-wiki radar 的 micro-benchmark 新增三项：一是候选晋升必须说明来源/深度/拒绝理由；二是报告 claim 要能映射到 raw/page/index/log/reindex receipt；三是开放式 artifact 不能只看 pass/fail，还要记录运行边界、operator 是否提示、重复性和主观质量评审入口。

2026-08-15 补充：重复运行、私有仓库评测与配置 lint

[[agentrelbench-stochastic-agent-damage-benchmarkAgentRelBench]] 提醒行动型 agent 的安全问题具有随机性：单次 clean run 可能只是没碰到 damage event，而不是证明 agent 安全。因此 agent benchmark 应记录重复次数、damage probability、severity、统计功效和报告诚实度，避免“跑一次没出事”变成上线依据。
[[repotrials-private-repository-coding-agent-evalRepoTrials]] 则把评测从公开 leaderboard 拉回到团队自己的代码库：从 Git history 挖掘真实修复，隐藏 verifier material，用 BASE/RED/GOLD 和本地 vault 形成私有 coding-agent 回归集。它说明选择 agent / harness / skill 时，最有决策价值的往往是“在我的仓库、我的测试、我的流程上是否稳定”。
[[agnix-agent-config-linterAgnix]] 补上 benchmark 前的 preflight：如果 CLAUDE.md、AGENTS.md、SKILL.md、hooks 或 MCP config 结构错误，后续行为 eval 可能测到的是“配置不可见/未触发”，而不是模型能力。对 llm-wiki radar 来说，日报质量也应先通过结构检查，再谈深度与发现质量。

2026-08-16 补充：stateful replicas、记忆冲突与安全 shortcut 都应进入 agent benchmark

realreplicabench-stateful-business-agent-benchmark 把长程 agent 评测推进到本地复刻的真实业务系统：CLI、browser、file、API/MCP 任务都要求改变可验证状态，并保留 trajectory、artifacts、logs 和 container metadata。这补充了单纯 coding benchmark 的盲区：真实 agent 能力不仅是 patch synthesis，也包括跨工具工作流、业务状态一致性和 artifact integrity。

hermes-memconflict-memory-provider-benchmark 则把 context provider / memory provider 也纳入 benchmark：同一 MemConflict 数据集、同一 answer model、judge、top-K、scorer 和 provider contract 下，比较 temporally valid / factually correct / contextually applicable memory 是否被检索并用于回答。对 llm-wiki 来说，这提示向量检索也应区分“证据命中”和“最终回答正确”。

breachforge-agentic-exploit-containment-harness 从安全侧提醒：benchmark 不能把 shortcut 当能力。攻防 agent 如果通过 egress、proxy 或 answer-key leakage 完成任务，应被评为 containment failure，而不是高 pass rate。未来 Hermes workflow eval 应同时记录 task success、boundary violation、claim honesty 和 infrastructure validity。

2026-08-20 补充：多 agent 协作本身需要独立评测

[[cooperbench-cooperative-coding-agentsCooperBench]] 把 coding-agent benchmark 从“一个 agent 能否完成 repo-level issue”推进到“多个 agent 是否能在潜在冲突任务中合作”。它的 solo / coop / team 设置说明，多 agent 并不天然优于单 agent；如果任务认领、共享 scratchpad、通信、git merge 和 leader/member 协议设计不好，协调成本会吞掉并行收益。

对 Hermes 来说，未来使用子代理或并行 wiki ingest 时，benchmark 不能只看速度或最终文件数量，还应记录 coordination receipts：每个子任务 owner、claim 时间、产物路径、冲突/返工次数、未认领任务、最终合并验证。否则“多 agent 看起来更忙”可能只是制造更多不可审计状态。

2026-08-21 补充：本地 benchmark instance 与 action-level prediction receipts

[[tenx-bench-kit-internal-agent-benchmark10x-bench-kit]] 把 coding-agent 评测拉回团队自己的仓库：私有 tasks/evaluation-pool、throwaway container、hidden evaluation materials、metrics/patch/result artifacts、template/task/judge/rubric version stamps，以及只在同一 era 内比较结果。这补充了公开 leaderboard 缺少的“本地任务、私有约束、版本可比性”。
[[arc-skill-prediction-gated-skillarc-skill]] 则说明 benchmark 可以记录更细粒度的 action-level receipts：每个动作前的预测、预测是否被下一帧反驳、失败点和 replay。对 Hermes 来说，未来 workflow eval 应同时覆盖 trial-level artifacts 和 claim/action-level receipts：最终页面是否存在只是最低层，还应检查写入前预期、写入后对账、未入库理由和验证输出。

写入记录

  • 2026-08-21 09:06 CST：补充 10x-bench-kit 的内部 coding-agent benchmark instance 与 arc-skill 的 action-level prediction receipts。
  • 2026-08-20 09:01 CST：补充 CooperBench 对多 agent 协作评测、coordination receipts、子代理/mass-ingest 指标的启发。
  • 2026-08-15 09:01 CST：补充 AgentRelBench、RepoTrials、Agnix 对 stochastic damage、私有仓库评测和 agent config preflight 的 benchmark 启发。
  • 2026-08-13 09:00 CST：补充 Prismor、AgentLock、ControlKeel、Smithers、Aegis、AAABench 对运行时控制、来源授权、持久 workflow、架构基线和长程 benchmark 的启发。
  • 2026-08-11 09:00 CST：补充 AIShield、Suede Creator Skills、HealthClaw Guardrails、claim-trace 对 skill/MCP 安全准入、领域 guardrail、报告 claim evidence 的启发。
  • 2026-08-09 09:00 CST：补充 HOL Guard、agent-egress-bench、RepoPrompt CE、Claw-Eval、Open Science Skills、Designer Skills 对运行时安全、上下文工作台、agent benchmark 和 domain skill routing 的启发。
  • 2026-08-08 09:00 CST：补充 Everdict、Active-SWE、Data Eng Bench、Claimproof 对本地 eval runtime、主动发现、领域现实性和报告诚实度的 benchmark 启发。
  • 2026-08-07 09:00 CST：补充 Boundary-Bench、LongHorizon-Harness、SkillForge 对权限政策、已验证状态、skill runtime / manifest 和 radar 证据化的启发。
  • 2026-08-06 09:00 CST：补充 Sitegeist 与 PIBench 对视觉 artifact 趋同、领域业务状态一致性和 paired skill study 的 benchmark 启发。
  • 2026-08-05 09:00 CST：补充 SWE-Touch、Assay、AgentFootprint 对共享 workspace benchmark、AI artifact behavior proof 和 context attribution 的启发。
  • 2026-08-04 09:00 CST：补充 AssetOpsBench、AgentLint、Skill Bill 对 domain realism、runtime guard adoption 和 skill-runtime reliability 评测的启发。
  • 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 和工具换挡能力。
  • 2026-08-10 09:00 CST：补充 2026-08-10 AI 雷达关于 MCP 工具边界、local-first eval、typed simulator 与 covert signaling 的综合更新。

2026-08-12 补充：证据型 cyber missions 与进化式 agent 实验都要求 benchmark 锁定

xorcise-cyber-agent-evidence-benchmark 把 agent 评测从最终成功扩展为 action trace：命令、工具调用、dead ends、deterministic checks 和 judge 共同构成 evidence report。kadath-evolutionary-agent-runtime 则提醒自我改进评测必须锁定 objective、rubric、tool manifest、runtime config 和 lineage，否则多代优化很容易变成 proxy hacking 或自改成绩单。

这给 llm-wiki radar 的 micro-benchmark 一个更硬的标准：报告 claim 要能追溯到 raw/page/命令 receipt；如果 workflow 自我优化，评分标准和候选 tape 不能被同一轮随意改写。评测对象越接近真实行动，越要区分 task success、side-effect severity、claim honesty 和 infrastructure validity。

  • 2026-08-12 09:00 CST：补充 ProdAgent、XORCISE、gpu-server-setup、KADATH 对生产控制面、证据评测、runbook skill 和上下文边界的启发。
  • 2026-08-16 09:00 CST：补充 2026-08-16 雷达关于 RealReplicaBench、Hermes MemConflict、pi-rlm、book-to-skill、NeuroArxiv、BreachForge 的综合启发。

2026-08-22 补充：verifier、版本化环境与私有任务生成正在成为 benchmark 的核心

[[llm-as-a-verifier-fine-grained-agent-verifierLLM-as-a-Verifier]] 把 agent benchmark 的反馈从最终 pass/fail 拆成 criterion-level、pairwise、progress-tracking 的 verifier 层；这说明未来 benchmark 需要同时记录执行者轨迹和评估者轨迹，并把 token/cost 作为 verifier 质量的一部分。
[[osworld-v2-release-versioned-computer-use-benchmarkOSWorld-V2]] 的 release contract 说明 computer-use benchmark 不能混用 main/latest：代码、task files、assets、mocked website 和 provider image 必须同版本，否则“同一分数”没有可复现含义。[[weavebench-hybrid-gui-cli-agent-benchmarkWeaveBench]] 进一步强调 GUI 与 CLI/code 的状态不可互相替代，评分应读取完整轨迹并惩罚 fabricated evidence。
[[issuebenchkit-private-repo-coding-agent-benchmarkIssueBenchKit]] 与 [[openbenchmark-trajectory-to-benchmarkOpenBenchmark]] 则把评测从公开榜单拉回团队自己的工作流：真实 issue、base commit、复现命令、before/after verdict、轨迹导入、rubric/pairwise judge、成本与速度，构成更适合企业内部 coding-agent 的 benchmark 单元。

对 Hermes 来说，最低可信 benchmark 单元应包含：任务版本戳、隐藏/独立 verifier、完整轨迹、成本、重复次数、claim receipts、以及污染边界说明。没有这些字段的“agent 做得不错”只能算观察，不能算可复用评测。

写入记录

  • 2026-08-22 09:30 CST：补充 verifier、版本化 computer-use、混合 GUI+CLI 和私有 coding-agent benchmark 的设计要求。

2026-08-23 补充：私有 PR benchmark、可审计 agent 与 computer-use runtime 进入本地评测闭环

[[repoagentbench-private-pr-coding-agent-benchmarkRepoAgentBench]] 把真实 merged PR 转成团队私有 coding-agent benchmark：PR description 是任务，真实 tests 是验收，agent 输出 diff.patch / agent.log / events.jsonl。它进一步证实 benchmark 不应只比较模型，还要把 harness/native CLI/adapter 作为被测变量记录。
[[dm-code-agent-auditable-local-code-agentDM-Code-Agent]] 从 agent runtime 侧补充了可审计性：append-only trace、fork/replay、隐藏测试 benchmark 和逐题 pass/fail 翻转，让“agent 为什么失败”比总分更可诊断。[[cua-computer-use-drivers-sandboxes-benchmarksCua]] 则提醒 computer-use benchmark 需要 OS/VM、driver、sandbox、trajectory export 和 registry 这类运行时字段，否则 GUI/CLI 长程任务不可复现。

对 Hermes 来说，未来本地 workflow eval 的最低可信单元应包含：任务来源/版本、harness/adapter、真实 verifier、隐藏材料边界、完整 trajectory、成本、重复次数、最终 claim receipts，以及环境/runtime manifest。

写入记录

  • 2026-08-23 09:00 CST：补充 RepoAgentBench、DM-Code-Agent、Cua 对私有 PR benchmark、可审计 trace 和 computer-use runtime manifest 的启发。

2026-08-24 补充：黑盒 CLI、动态观察与规则租金都应被 benchmark

[[agent-belt-black-box-cli-agent-benchmarkAgent Belt]] 把被测对象明确为用户真实安装和认证过的 CLI agent，而不是模型或内部 solver。这补充了 agent benchmark 的一个关键变量：同一模型在不同 CLI/harness、skills、MCP 和用户级配置下可能表现完全不同，因此评测记录必须包含 binary/harness、工作区配置、重复次数、paraphrase family、独立 judge 和 artifact receipts。
[[aoi-dynacu-bench-dynamic-computer-useAOI / DynaCU-Bench]] 则说明 computer-use benchmark 不能只测离散截图后的动作结果。动态屏幕、语音和 transient UI 事件会发生在 agent step 之间；如果 observation interface 没捕捉到它们，后续 planner/verifier 都在陈旧状态上工作。DynaCU-Bench 的 Static-50 no-degradation control 也提醒：增强观察不能只追求动态任务提分，还要证明静态任务不退化。
[[token-warden-benchmark-gated-agent-memoryToken Warden]] 把 benchmark 对象推进到 agent memory / behavioral rules：规则是否应进入长期上下文，不应靠感觉，而应在 frozen suite 上证明净收益。对 llm-wiki radar 来说，关注主题、skills、cron prompt 和自我优化规则都应逐步有“是否付租”的证据；否则 benchmark 之外的长期上下文会成为隐性成本。

2026-08-26 补充：统计可靠性与冻结 evaluator 让 benchmark claim 更可信

[[reliable-cua-statistical-computer-use-evalreliable-cua]] 把 computer-use agent benchmark 的可信度从 verifier/环境层推进到统计层：CUA 结果应按 app、scenario、configuration、rollout 的层级结构聚合，并报告 Wilson interval、hierarchical bootstrap CI 和环境轴造成的退化，而不是把所有 run 展平成一个成功率。它补充了 [[weavebench-hybrid-gui-cli-agent-benchmarkWeaveBench]]、[[osworld-v2-release-versioned-computer-use-benchmarkOSWorld-V2]] 与 [[cua-computer-use-drivers-sandboxes-benchmarksCua]] 的运行时/轨迹视角：即使 verifier 正确，统计汇总错误也会制造虚假的确定性。
[[rsihub-frozen-evaluator-agent-self-improvementRSIHub]] 则把 agent 自我改进评测收敛成 frozen evaluator、candidate lineage、archive records 与机制盖章的状态更新。对 Agent-Benchmarks 来说，这说明 benchmark 不只是一次测模型，也可以成为 workflow/prompt/skill/harness 迭代的边界：候选可以变，但评分器和报告来源不能被同一候选随意改写。

对 Hermes 来说，未来本地 workflow eval 的可信 claim 应至少包括：任务层级/配置轴、重复次数、置信区间或稳定性说明、冻结 evaluator、候选 lineage、artifact receipts 和报告重算路径。否则“今天 radar 更好”“某 agent 更强”都只能算观察，不能算可复用结论。

写入记录

  • 2026-08-26 09:01 CST：补充 reliable-cua 与 RSIHub 对层级统计、置信区间、frozen evaluator 和 agent/workflow 自我改进 benchmark 的启发。
  • 2026-08-24 09:00 CST：补充 Agent Belt、AOI/DynaCU-Bench、Token Warden 对黑盒 CLI 评测、动态观察 benchmark 和 benchmark-gated memory 的启发。

2026-08-27 补充：harness release 本身必须进入 benchmark cell

[[agent-harness-evolution-shapes-coding-agent-qualityAgent Harness Evolution Shapes Coding Agent Quality]] 提供了一个直接证据：固定底层 LLM、只改变 coding-agent harness 的连续版本，也会造成 effectiveness / efficiency 波动。它把评测归因从“模型分数”推进到“model × harness release × tool surface × context policy × loop control”的组合单元。

对 Agent-Benchmarks 的启发是：公开或内部 coding-agent benchmark 应记录 harness version、release diff、任务抽样、重复次数、token/cost、tool trajectory 和具体质量回归归因。对 llm-wiki radar 来说，每日 ingest 也应记录本轮搜索源、晋升门槛、写入合同和验证输出；否则日报质量变化会被错误归因到模型，而不是 workflow/harness 改动。

写入记录

  • 2026-08-27 09:00 CST：补充 agent harness longitudinal study 对 benchmark 归因、harness version 和 llm-wiki radar 自评的启发。

2026-08-28 补充：benchmark 必须显式建模监督通道、长程 GUI 状态和 harness 盲评

[[baseerat-oversight-gap-computer-useBaseerat]] 提醒 computer-use benchmark 不能默认监督者总能看见真实屏幕：agent narration、accessibility tree、视觉屏幕和真实提交状态可能不一致，因此 benchmark 应报告 oversight parity gap，并用 trusted action receipts 而不是自然语言自述作为完成证据。[[longpuzzlebench-long-horizon-gui-agent-benchmarkLongPuzzleBench]] 则把长程 GUI 能力放入 deterministic browser puzzle environment，通过 evaluator-only state 避免把答案暴露给 agent。
[[harness-arena-blind-agent-harness-benchmarkHarness Arena]] 从 coding-agent 侧补充 harness attribution：同一模型、同一任务、隔离 workspace 下比较不同 harness，并在身份揭示前进行 blind judging。对 Hermes 来说，未来 benchmark cell 应至少记录 observation channel、verified state path、evaluator-only material boundary、harness version、workspace isolation、cost/duration、deliverables hash 和 claim receipts。

2026-08-29 补充：统计语义、三阶段 verifier 与 GUI trustworthiness 要进入 benchmark 合同

[[beyond-pass-k-agentic-code-reliability-securityBeyond Pass@k]] 提醒 coding-agent 评测不能把单次提交里的测试数量当成独立 rollout；可靠性 claim 应记录独立尝试次数、strict task resolution 和 security-adjusted success。[[swe-refactor-bench-whole-repository-migrationSWE Refactor Bench]] 进一步说明长程迁移任务需要先做 migration audit，再做 behavioural tests，最后用独立 agentic verification 找 hidden behavioral differences；否则 agent 可能通过保留旧实现绕过真实迁移目标。
[[adepts-bench-trustworthy-computer-use-agentsADeptS-Bench]] 则把 computer-use benchmark 从 task success 扩展到 attack success、clarification behavior 和 safety-tool ablation。对 Hermes / llm-wiki 来说，未来 benchmark cell 应至少包含：attempt independence、strict resolution、anti-shortcut audit、security/attack outcome、clarification/HOLD 行为、harness/interface 版本和 claim receipts。没有这些字段的 agent 分数只能算观察，不能算可迁移评测结论。

写入记录

  • 2026-08-29 09:01 CST：补充 Beyond Pass@k、SWE Refactor Bench 与 ADeptS-Bench 对可靠性统计、迁移 anti-shortcut verifier、GUI trustworthiness 和内部 coding-agent benchmark 合同的启发。

2026-08-30 补充：评测应覆盖 skill-library poisoning 与多代理协作变量

[[evomal-self-poisoning-agent-skill-librariesEVOMAL]] 把 benchmark integrity 推进到自演化 skill library：评测 self-improving coding agent 时，不能只看任务完成率，也要测 agent-authored artifacts 是否把恶意或低质量模板复制进长期库。它的 ASPR 指标提醒：成功完成任务和污染 skill library 可以同时发生，安全 verdict 必须成为成功条件的一部分。
[[agentroom-crdt-shared-workspace-coding-agentsAgentRoom]] 则提醒多代理 coding benchmark 不能只比较“一个 agent vs 多个 agent”。真正的变量包括 solo、parallel-merge、coordinated shared workspace、claim/status/broadcast 协议、CRDT merge、matched compute、abandon rate 和 run-to-run variation。对 Hermes 来说，子代理工作流的评测单元应记录 coordination protocol，而不是只记录子代理数量。

写入记录

  • 2026-08-31 09:00 CST：补充 SandboxEscapeBench、dispatch-level instrumentation、ContextPilot 与 NOOA 对 sandbox safety、工具轨迹、上下文行动归因和 harness-as-variable 的评测启发。
  • 2026-08-30 09:00 CST：补充 EVOMAL 与 AgentRoom 对 skill-library poisoning、安全 verdict、多代理 coordination benchmark 的启发。

2026-08-31 补充：benchmark 要评测 sandbox、工具轨迹和上下文行动

[[aisi-sandboxescape-bench-container-breakoutSandboxEscapeBench]] 把 agent benchmark 的完整性边界推进到执行环境：如果 sandbox 可被 frontier model 通过常见 misconfiguration 或已知 CVE 逃逸，那么任何“安全评测”都可能失去隔离假设。因此 future benchmark cell 应记录 outer isolation、container privilege、Docker socket、runtime/kernel version、network/mount policy 和 token/cost budget。
[[dispatch-level-instrumentation-agentic-datasheet-extractionDispatch-Level Instrumentation]] 说明 fidelity score 本身不足以证明 agentic extraction 可靠；模型可能没调用必要工具却答对或编造 source text。Agent benchmark 应同时评分 value correctness、tool-path compliance、silent-failure detector、oracle coverage 和 report honesty。[[contextpilot-proactive-context-managementContextPilot]] 则提醒上下文编辑也是被测行动：planning、memory、offloading、compression、search/delete/summarize 的采用率和 action-level advantage 都应进入长程任务评测。
[[nvidia-nooa-object-oriented-agent-harnessNOOA]] 的 reported SWE-bench / ARC-AGI-3 / CyberGym 成绩进一步强化 harness-as-variable：同一模型的 pass rate、token、LLM calls 和 cost 会被 object state、pass-by-reference、typed contracts、deterministic gates 改变。对 Hermes 的内部 benchmark 来说，最低字段应扩展为：model、harness/interface、sandbox policy、context action log、dispatch trace、verifier/oracle boundary、成本、重复次数和 claim receipts。

2026-09-01 补充：benchmark 应把 runtime / gateway / federation control plane 作为变量

MCP-Gateway-Runtime 和 [[ibm-contextforge-mcp-federation-control-planeIBM ContextForge]] 说明，agent benchmark 不能只记录模型名称。工具面如果经过 MCP gateway、A2A/REST federation、tool filtering、auth、rate limiting、sandbox 或 observability layer，结果就同时受到 Context-Engineering、Harness-Engineering 和 Loop-Engineering 的影响。

因此 future benchmark cell 应至少记录：runtime/gateway 名称与版本、tool registry snapshot、context manifest、sandbox/security policy、credential boundary、trace/oracle availability、cost/token budget、重复次数和 claim receipts。否则“某 agent 更强”的结论可能只是 gateway 暴露了更好工具、harness 帮它过滤了危险动作，或 verifier 更宽松。

写入记录

  • 2026-09-01 21:16 CST：补齐 MCP / Agent Runtime / Gateway 主题簇互链，明确本页在 runtime、context、harness、loop、benchmark 之间的分工。

2026-09-02 补充：benchmark 的核心从结果分数转向 verifier 与环境合同

[[da-verify-programmatic-verification-harnessda-verify]] 和 [[cuarena-instrumented-computer-use-environmentsCUArena]] 分别补强了 agent benchmark 的两个基础层。da-verify 显示，LLM 自检不是可靠 verifier；在可程序检查的数据分析任务中，采样多样性 + 程序化 agreement gate 才是主要收益来源。CUArena 则说明 computer-use benchmark 不能只有 UI 和任务描述，必须能 reset、observe、grade，并保留 raw / semantic / outcome 三流日志。

这把 Agent-Benchmarks 的最低可信单元收紧为：任务可重置、状态可观察、评分可程序化或至少独立、重复次数/温度/成本可报告、失败能归因到 verifier、环境、工具面或模型，而不是只给一个 pass rate。对 llm-wiki radar 来说，入库流程也应按同样标准自检：raw hash、页面写入、index/log、reindex 和最终报告 claim 都应有 receipt。

写入记录

  • 2026-09-02 09:00 CST：补充 da-verify 的程序化 agreement gate 与 CUArena 的 reset/observe/grade 环境合同对 agent benchmark 的启发。

2026-09-02 补充：A2A 实践案例应进入 benchmark 变量

A2A-Agent2Agent-Protocol 让 agent benchmark 需要区分单 agent tool-use 与 multi-agent delegation。若被测系统通过 A2A 调用了远程 specialist agent，benchmark cell 应记录 Agent Card、discovery/registry、task lifecycle、streaming/push、auth、artifact receipt、远程 agent opaque 程度和成本分摊。

后续雷达应优先关注有真实 A2A 实践证据的案例，而不是只介绍协议概念的文章。

写入记录

  • 2026-09-02 21:23 CST：补充 A2A-Agent2Agent-Protocol 与本主题簇的关系，明确 A2A 在 agent-to-agent delegation、Agent Card、Discovery、task lifecycle 和实践案例雷达中的位置。

2026-09-03 补充：A2A benchmark 要记录 delegation topology 与不可信 card

[[a2a-samples-agent-card-discovery-interoperabilityA2A Samples]] 说明 A2A 评测不能只记录“是否支持协议”。最低 benchmark cell 应记录 host/client 类型、remote agent 列表、AgentCard URL/hash、card 是否经过 sanitize、是否动态 discovery、task lifecycle、streaming/push、artifact 类型、远端 agent 内部是否调用 MCP/custom tools、以及 trace/cost 如何在 host 与 remote agents 之间归因。

尤其要把 AgentCard 当作供应链输入而不是可信说明文档：如果 benchmark harness 把 card description、skills.description 或 artifact 文本直接拼进模型上下文，可能把远端 agent 的 prompt injection 计为“协作能力”。因此 multi-agent interoperability benchmark 应同时报告 untrusted-input handling 和 delegation success。

写入记录

  • 2026-09-03 09:00 CST：补充 A2A Samples 对 delegation topology、AgentCard receipt、untrusted card sanitization 和 A2A+MCP 组合评测字段的启发。

2026-09-03 补充：知识点雷达与自我优化入口

AI-Knowledge-Point-Radar 将 benchmark / evaluation 与 sandbox / security evaluation 设为核心雷达轴；后续 benchmark 页面应标明是否涉及 MCP gateway、A2A delegation、harness/runtime 变量。

写入记录

2026-09-04 补充：benchmark 应记录 policy decision 与 evidence chain

[[aegisflow-local-first-policy-gatewayAegisFlow]] 的 PR writer proof 给 Agent-Benchmarks 补了一个 security-adjusted evaluation 维度：评测不应只问 agent 是否完成 PR，而要记录它在 allow、review、block 三类边界下的行为，以及是否产生可验证 evidence chain。一个安全 coding agent 遇到 github.delete_repo block 后应停止或澄清，而不是改用 shell/API 绕过边界。

因此内部 coding-agent benchmark 可新增字段：policy_pack_version、allowed_actions、reviewed_actions、blocked_actions、approval_receipts、bypass_attempts、evidence_chain_valid、upstream_receipt_present。这样“成功率”才能和权限/安全成本一起比较。

写入记录

  • 2026-09-04 09:00 CST：补充 AegisFlow 对 policy-aware benchmark、blocked-action 行为和 signed evidence chain 的启发。

2026-09-05 补充：Agent registry / gateway 本身也需要合规与信任评测

[[permit-mcp-gateway-enterprise-trust-layerPermit MCP Gateway]] 与 [[a2apex-agent-card-certification-directoryA2Apex]] 提醒：agent benchmark 不能只测最终任务完成率，也要测 agent-facing control plane 是否产生可信 receipt。MCP 侧应评测 identity binding、authorization decision、consent、credential scope、audit log；A2A 侧应评测 Agent Card schema、live JSON-RPC endpoint、auth failure、task lifecycle、streaming/push、artifact integrity 和 trust-score 可解释性。

这类评测更像 control-plane conformance test：它不证明 agent “聪明”，但证明 agent 的工具/委托边界可治理、可复查、可撤销。对 Hermes 的无人 cron 来说，这比单次任务成功更基础，因为缺少身份/策略/审计 receipt 的成功可能只是隐性越权。

写入记录

  • 2026-09-05 09:00 CST：补充 MCP/A2A trust registry 对 benchmark-evaluation 的影响，将 identity/policy/audit 与 Agent Card/live endpoint/auth 纳入评测维度。

2026-09-07 补充：A2A/MCP runtime benchmark 要测 registry snapshot 与 task lifecycle

[[dsh-nacos-bridge-registry-to-harness-runtimedsh-nacos-bridge]] 提醒 runtime/gateway benchmark 不应只测最终任务成功，还要测 registry diff、mount/unmount、health check、schema/card 漂移、capability snapshot 与 stale rejection。否则 agent 可能在不同运行中看到不同工具面，分数无法解释。
[[a2a-query-task-handle-approval-brokera2a-query]] 则提示 A2A benchmark 应把 task lifecycle 作为一等对象：TaskHandle 状态转换是否正确，INPUT_REQUIRED / AUTH_REQUIRED 是否进入 approval broker，streaming 断线后是否 resubscribe/poll fallback 并用 getTask reconcile，artifact accessor 是否可验证，devtools wire receipt 是否足以支持 claim audit。

写入记录

  • 2026-09-07 09:00 CST：补充 A2A/MCP runtime benchmark 对 registry snapshot、mount/unmount、TaskHandle、approval broker、stream reconcile 与 artifact receipt 的评测维度。

2026-09-08 补充：SWE-Marathon 把 benchmark 推到 multi-hour / reward-hacking / context-telemetry 层

[[swe-marathon-ultra-long-horizon-agent-benchmarkSWE-Marathon]] 补充了 agent benchmark 的 marathon-scale 维度：20 个 2–10 小时软件工程任务、13 个 agent/model 配置、1,300 条轨迹、平均 27.2M tokens，最强配置 pass@1 仍低于 30%。它的关键不在排行榜，而在 benchmark harness：visible feedback 与 hidden scoring 分离，hidden verifier 覆盖 dense tests、behavioral parity、performance gates、deterministic replay、integrity/audit checks 和 computer-use UX verifier。

对本页的新增规则是：长程 benchmark 必须同时报告 reward-hacking audit、context/token/cost、重复工具调用、failure taxonomy 与 residual risk。SWE-Marathon 发现 13.8% rollouts 有 exploit-shaped action、10.2% ship verifier bypass，但 132 个 shipped bypass 均被防御层抓住；同时 99.6% agent-attributable failures 带 validation-failure signal。Hermes 的内部 coding-agent benchmark 也应从二值 PASS/FAIL 升级为：horizon、hidden verifier、trace/cost、shortcut probes、失败类型和报告 claim receipt。

写入记录

  • 2026-09-08 09:01 CST：补充 SWE-Marathon 对超长程 agent benchmark、multi-channel verifier、reward-hacking audit、context/token telemetry 与 failure taxonomy 的启发。

2026-09-09 补充：benchmark 要测 tool-route、action safety 与 protocol conformance

[[osworld-mcp-tool-invocation-computer-use-benchmarkOSWorld-MCP]] 给 agent benchmark 增加了 tool-route 维度：任务是否 tool-beneficial、工具库存是否经验证、agent 何时选 GUI/工具、Tool Invocation Rate、distractor 下是否稳、step/cost 是否下降。它提醒评测不能只说“有 MCP 工具”，而要测 agent 是否知道什么时候该用、什么时候不该用。
[[agenttrust-runtime-safety-interceptionAgentTrust]] 给 benchmark 增加 action-time safety 维度：每次工具动作前能否归一化、识别混淆、检测多步链、给出 allow/warn/block/review、提供 safe fix，并在拦截器异常或 LLM judge 不可达时 fail-safe 到 review。[[a2a-v1-protocol-binding-governanceA2A v1]] 则把跨 agent benchmark 的变量扩展为 protocol conformance：supportedInterfaces、protocolVersion、binding、auth、signature、stream/push/task lifecycle 是否按规范工作。

后续 Hermes 内部 benchmark 的最小 receipt 应从 pass/fail 扩展为：task_applicability、tool_route、action_verdict、protocol_binding、hidden_verifier、trajectory/cost、security_adjusted_success 与 failure_taxonomy。

写入记录

  • 2026-09-09 09:01 CST：补充 OSWorld-MCP 的 tool-route eval、AgentTrust 的 action-time safety eval 与 A2A v1 的 protocol conformance eval。
  • 2026-09-10 09:11 CST：以简短入口补充 REDAgentBench 证据视图/REG 分母与 A2A TCK 实际断言覆盖；深度分析保留在 source，避免继续膨胀概念页。
  • 2026-09-11 09:09 CST：补充条件复用/全量复用、正确率/完成率、作者回执/本机核查分账，标记新 source 的 contested 定量问题而非覆盖原文。
  • 2026-09-12 09:17 CST：补充奖励生命周期完整性与 covered accuracy/弃权分母入口；保留本机表格复算与作者运行的证据分层。
藏书阁 · Published from llm-wiki · 2026-09-12 12:06:22