CooperBench — Cooperative Coding Agents Benchmark

CooperBench — Cooperative Coding Agents Benchmark

一句话结论

cooperbench/CooperBench 是一个评估 coding agents 多主体协作能力的 benchmark：它比较 solo、coop peer agents、lead/member team 三种设置，并引入 Redis 消息、共享任务列表、共享 scratchpad、可选共享 git remote 与协调指标。README 的核心发现是：给定同等总工作量，协调型 agents 可能显著弱于单 agent，这把 Agent-Benchmarks 的焦点从“单 agent 能否修复问题”推进到“多个 agent 能否在冲突任务中协作而不互相破坏”。

为什么对用户重要

Hermes / llm-wiki 已经频繁使用“主 agent + 工具 + 可能的子任务”模式。用户也关注 agent workflows、coding agents、子代理驱动开发和长期自动化。CooperBench 的价值在于给出一个冷提醒：多 agent 不是免费并行化。如果没有任务分解、冲突检测、共享状态、合并协议和协调指标，多 agent 可能比单 agent 更差。

这对未来 Hermes 子代理、并行 ingest、代码修改和自动化 loop 都很重要。尤其在无人 cron 里，多个 worker 同时写 wiki 或代码时，失败不一定来自模型能力，而可能来自协调层：重复页面、互相覆盖、合并冲突、共享 scratchpad 污染、任务无人认领或完成状态不一致。

机制 / 一阶原理

1. 从单体能力转向协作能力

传统 coding benchmark 多看一个 agent 对一个 issue 的 patch 是否通过测试。CooperBench 明确把同一任务拆到多 agent 设置中，观察它们在潜在冲突下的合作能力。这个转向很关键：真实组织中的 AI agent 很可能不是单体运行，而是多个模型/工具/角色并发处理同一代码库。

2. 三种设置暴露不同瓶颈

• solo：一个 agent 完成全部功能，是能力与上下文负担的 baseline。
• coop：多个 peer agent 各自处理一个 feature，通过 Redis 通信，可选共享 git remote。
• team：lead + members，使用 Redis-backed task list、共享 scratchpad、角色提示和协调指标。

这三种设置让 benchmark 能区分：失败是因为单 agent 负担过重，还是因为协作协议本身造成额外损耗。对 Harness-Engineering 来说，lead/member、task claim、scratchpad、git merge 都是 harness 变量，而不应被混进“模型好坏”的单一分数。

3. 协调指标是过程级 evidence

README 提到 team-mode result 中包含 tasks_total、tasks_done、unowned_at_end、time_to_first_claim_seconds、claims_per_agent、updates_per_agent 等 coordination indicators。这比只看最终测试通过率更可诊断：即使 patch 失败，也能判断是没有认领任务、认领太慢、更新不足、leader 未组织，还是 merge/implementation 出错。

与已有 wiki 概念的关系

• 对 Agent-Benchmarks：CooperBench 补上“multi-agent coordination deficit”维度，区别于 SWE-Explore、SWE-PolyBench 等更偏单 agent/repo-level patch 的评测。
• 对 子代理驱动开发：它提醒子代理不是越多越好；子代理需要任务认领、共享状态、冲突隔离和合并协议。
• 对 Harness-Engineering：多 agent harness 必须记录通信通道、共享资源、角色、任务表和 merge 策略，否则结果不可解释。
• 对 Loop-Engineering：长期 loop 中的并发 worker 需要 stop rule、ownership、claim lease 和 audit trail，避免 zombie work 或重复写入。

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

1. 并行 delegate 前先定义 coordination contract：任务拆分、文件所有权、写入顺序、冲突处理和最终合并者必须明确。
2. 给 wiki mass-ingest 增加任务认领表：如果未来并行创建 10+ 页面，应记录每个子任务 owner、状态、产物路径和验证结果，避免重复页/断链。
3. 评估子代理时不要只看速度：应同时记录最终质量、返工量、冲突次数、未认领任务、claim latency 和报告诚实度。
4. 优先单 agent + 工具，谨慎多 agent：对中小任务，单 agent 的全局上下文可能比多 agent 的协调成本更划算。

失败模式 / 边界条件

• 协作通道变成噪音源：Redis/scratchpad 可能堆积低质量状态，增加 context pollution。
• 共享 git remote 放大冲突：多个 agent 分支合并若没有策略，容易互相覆盖或通过局部测试但整体失败。
• leader bottleneck：team mode 中 lead 如果任务拆分差，members 可能空转或做错方向。
• benchmark 外推限制：本次只读取 README，未运行 CooperBench；README 中“协调 agents 更差”的结论需结合论文、任务集和实验条件再用于强决策。

深度判断

本次晋升 CooperBench，是因为它对用户长期关注的子代理、agentic coding、workflow harness 有直接耐久价值：它不是又一个通用 SWE-bench 变体，而是把“多 agent 协作是否真的有效”作为独立评测对象。置信度为 medium：已读取 README，arXiv API 当日 timeout/429，尚未读取完整论文或复现实验。

写入记录

• 2026-08-20 09:01 CST：新增 CooperBench 来源页，沉淀 multi-agent coordination benchmark、solo/coop/team 设置、过程级协调指标，以及对 Hermes 子代理和 llm-wiki mass-ingest 的启发。