Agent Belt — black-box CLI agent benchmark

Agent Belt — black-box CLI agent benchmark

一句话结论

Agent-Benchmarks 需要从“模型/框架跑公开题”继续下沉到“用户真实安装的 agent CLI，在真实工作区、真实 skills/MCP/auth 配置下是否稳定完成任务”。Agent Belt 的核心价值在于把 Claude Code、Cursor、Codex、Gemini、Copilot、opencode、Goose 或自定义 CLI 当作黑盒 subprocess 来评测，而不是重新实现一个内部 agent loop。

为什么这对用户重要

用户的 Hermes / llm-wiki 工作流实际依赖的是运行时组合：模型、CLI/harness、技能、工具、MCP、认证状态、工作区文件、cron prompt 和验证脚本。公开 benchmark 只能说明某个模型或某个 solver 在标准环境的能力，不能说明“我机器上这个 agent 配置”是否可靠。Agent Belt 的方向适合迁移为本地 llm-wiki radar eval：用小型场景测试是否 orient、是否保存 raw、是否更新 _index.md/log.md、是否留下未入库理由与写入记录。

机制 / 一阶原理

Agent Belt 把 被测单元 定义为黑盒 CLI binary：它不接管 agent loop，只在场景工作区里启动用户实际运行的工具，并收集规则检查、workspace diff、独立 LLM judge 与最终 verdict。这避免了“评测的是 wrapper，不是用户真正使用的 agent”的错位。

它还显式处理 stochastic agent 的方差：同一 scenario 可以用 --trials N 重复运行，paraphrase family 可以测语义等价任务的稳定性，多 judge consensus 可以降低单个 judge 的漂移风险。对长期 workflow 来说，这比单次绿勾更有意义：一次 pass 可能是幸运，pass^3 或 family-level pass 才更接近可靠性。

与已有 wiki 概念的关系

• 与 Harness-Engineering：它把 harness 当作可测对象，而不是只写规则和提示词。
• 与 Agent-Benchmarks：它补充了黑盒 CLI、重复次数、paraphrase family、multi-judge consensus 这些 benchmark integrity 维度。
• 与 Loop-Engineering：它适合成为无人 loop 的回归测试层，用于防止 cron prompt、skills 或工具面改变后悄悄退化。

对 Hermes / llm-wiki 的可执行启发

1. 先做一个最小场景集：radar-orient-only、raw-archive-and-hash、promote-one-source、reject-low-value-candidate、index-log-write-record。
2. 每个场景只使用临时 fixture vault，避免破坏真实 wiki；判分用 deterministic file checks 为主，LLM judge 只评估深度判断质量。
3. 报告不要只写“任务成功”，还要输出 pass rate、重复次数、耗时、工具错误、产生/未产生的文件 receipt。

失败模式 / 边界条件

• 它会驱动真实 CLI 作为当前用户执行，恶意 scenario 可能修改 dotfiles、SSH config、git hooks 或外传数据；因此只能在隔离工作区/低权限账户里跑。
• 如果用户级配置不随 fixture 一起进入工作区，评测结果会受本机登录态和全局配置影响，复现性下降。
• LLM judge 仍然可能漂移；核心 verdict 应尽量绑定 rules、workspace diff、测试命令和 artifact receipts。

写入记录

• 2026-08-24 09:00 CST：新增 Agent Belt source 页，提炼黑盒 CLI agent benchmark、重复试验与 llm-wiki radar eval 的启发。