RealReplicaBench — stateful business agent benchmark

RealReplicaBench — stateful business agent benchmark

为什么重要

RealReplicaBench 值得进入 wiki，因为它把 agent benchmark 从“解题/改 patch”推进到真实业务状态改变：107 个任务覆盖 CLI、browser、file、API/MCP，运行在可复现的本地 replica 服务里，并保存 trajectory、verifier result、artifacts、logs 和 container metadata。对用户的 Hermes / llm-wiki 来说，它提示每日雷达和 agentic workflow 的评测也应看“是否改变了正确状态、是否留下可复查产物”，而不是只看自然语言完成声明。

机制 / 一阶原理

它的核心机制是用本地 mock 的 SaaS、commerce、messaging、document、operational systems 复刻真实任务表面；每个任务在 fresh container 中执行，并由 deterministic 或 LLM-assisted verifier 评分。这样既避免生产账号依赖，又让 agent 必须通过浏览器、CLI、文件和 API/MCP 完成 stateful workflow。README 还区分 OpenClaw 与 Accio 两种 harness 结果，提醒模型分数会受到 harness、工具粒度、运行时调度和 provider usage accounting 影响。

与已有概念的关系

• 补强 Agent-Benchmarks：长程能力应拆成 task surface、statefulness、verifier、trajectory、artifact integrity，而不是单一 pass rate。
• 连接 Harness-Engineering：benchmark 本身是 harness 变量；同一模型在不同 harness 下的步骤、时间、token 与 pass rate 不可直接混为模型能力。
• 连接 Context-Engineering：任务 state 和 verified artifacts 应作为 fresh context 传递给后续 executor，而不是把全轨迹塞回上下文窗口。

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

1. 给每日 radar 增加“stateful receipt”思路：raw 是否存在、source page 是否存在、concept 是否更新、_index/log 是否更新、reindex 是否跑完。
2. 对复杂自动化任务，报告应分开写 model/source 证据、harness/tool surface、verifier 和 artifact，而不是只给一个成功总结。
3. 如果未来评测 Hermes workflow，任务集应包含浏览器、文件、CLI、API/MCP 混合任务，并记录任务表面差异。

失败模式 / 边界

当前入库基于 GitHub README；leaderboard 数字和模型名需要以 live leaderboard / 论文或 release artifact 复核后再用于强结论。LLM-assisted verifier 的一致性、mock service 与真实业务系统的差距、以及 harness 间可比性仍是主要边界。

写入记录

• 2026-08-16 09:00 CST：新增 RealReplicaBench 来源页，沉淀 stateful business workflow benchmark、harness-as-variable 与 Hermes radar receipt 启发。