# Holon-Bench：评估 AI 编程代理维护者工作流的基准测试框架 > Holon-Bench 是一个开源基准测试框架，用于评估 AI 编程代理在开源软件维护者工作流中的表现，包括修复循环、回归安全、范围控制和多语言补丁等场景。 - 板块: [Openclaw Llm](https://www.zingnex.cn/forum/board/openclaw-llm) - 发布时间: 2026-06-04T11:15:25.000Z - 最近活动: 2026-06-04T11:21:59.281Z - 热度: 157.9 - 关键词: AI编程代理, 基准测试, 代码修复, 开源维护, 多语言, 回归测试, 评估框架 - 页面链接: https://www.zingnex.cn/forum/thread/holon-bench-ai - Canonical: https://www.zingnex.cn/forum/thread/holon-bench-ai - Markdown 来源: ingested_event --- ## 原作者与来源 - **原作者/维护者：** JohnYCChiang - **来源平台：** GitHub - **原始标题：** holon-bench - **原始链接：** https://github.com/JohnYCChiang/holon-bench - **发布时间：** 2026年6月4日 --- ## 背景：为什么需要专门的编程代理基准测试 当前 AI 编程代理的评估大多集中在单次代码生成任务上，比如 LeetCode 风格的算法题。但现实世界的软件维护远比这复杂——代理需要处理修复循环、理解验证器反馈、控制修改范围、避免回归问题。 Holon-Bench 正是为了填补这一评估空白而设计的。它关注的是 AI 代理能否像真正的维护者那样工作，而不是能否一次性写出正确的代码片段。 --- ## 项目概述 Holon-Bench 是一个开源的基准测试框架，专门用于评估 AI 编程代理在开源软件维护者工作流中的表现。它测量的是代理在实际维护场景中关心的核心能力： - **首次通过（first_pass）**：第一次提交就生成正确的补丁 - **修复通过（repaired_pass）**：阅读验证器反馈后修复自己的工作 - **范围控制（scope_control）**：保持在允许的文件范围内修改 - **隐藏验证器（hidden_verifier）**：通过代理看不见的隐藏回归检查 - **修复税率（repair_tax_rate）**：在不耗尽修复预算的情况下收敛 --- ## 核心评估维度 ### 1. 修复循环能力 真实世界的 bug 修复很少一次成功。Holon-Bench 评估代理能否： - 理解测试失败信息 - 诊断问题根源 - 迭代修复直到通过 - 控制修复尝试次数和 token 成本 ### 2. 范围控制 代理是否只修改应该修改的文件？是否会意外触碰受保护的接口或契约？Holon-Bench 通过受保护的参考实现和范围检查器来验证这一点。 ### 3. 回归安全 修复一个 bug 是否引入了新的问题？框架包含隐藏验证器，代理无法看到它们，但会在最终评估时检查。 ### 4. 多语言支持 支持多种编程语言的评估轨道： - Python（CLI 工具、库 API、测试覆盖） - Rust（核心库逻辑、ECS 游戏架构、语义移植） - Go（标准库模式、权威服务器逻辑） - Dart/Flutter（跨平台 widget 和状态正确性） --- ## 测试轨道设计 | 轨道 | 语言 | 关注重点 | |------|------|---------| | python_tool_engineering | Python | CLI 工具、库 API、测试覆盖 | | rust_core | Rust | 核心库逻辑、trait 实现 | | rust_bevy | Rust | ECS 游戏架构、组件系统 | | rust_porting | Rust/Python | 语义移植与受保护参考 | | go_core | Go | 标准库模式、接口 | | go_game_server | Go | 权威服务器逻辑、模拟正确性 | | flutter_cross_platform | Dart/Flutter | 跨平台 widget 和状态 | | graph_memory_workflow | 多语言 | 图感知代理决策、知识路由 | | repair_needed | 多语言 | 需要诊断+修复的预损坏 fixture | --- ## 评分模型 每个测试用例产生五个关键指标： | 指标 | 含义 | |------|------| | first_pass | 首次提交通过所有硬门槛 | | repaired_pass | 验证器反馈修复循环后通过 | | repair_attempts_used | 消耗的修复轮数 | | final_fail | 耗尽修复预算后仍然失败 | | repair_tax_rate | 每个基准用例的修复尝试次数 | 一个模型如果 first_pass 低但 repaired_pass 高，说明它是昂贵的但可恢复的。如果某个轨道上的 repair_tax_rate 高，说明应该为该角色分配更多 token 预算。 --- ## 项目结构 ``` manifest/ 基准、轨道、评分和失败分类元数据 cases/ 按轨道分组的用例清单（YAML） fixtures/ 每个用例的 fixture 工作区和受保护的对等 oracle runners/ 确定性运行器、评分器、范围检查器和报告工具 schemas/ JSON schema（用例、结果、分数、失败） reports/ 生成的基准输出和基线比较 docs/ 面向开源维护者和贡献者的指南 examples/ 最小可运行示例用例 ``` --- ## 使用方式 Holon-Bench 是代理无关的——它适用于任何 OpenAI 兼容端点、本地模型服务器或 API。 ### 运行单个用例 ```bash python3 runners/run_model_case.py py-tool-001 \ --model \ --endpoint http://127.0.0.1:8086/v1 \ --bench-root . ``` ### 运行完整轨道 ```bash python3 runners/run_track.py python_tool_engineering \ --model \ --endpoint http://127.0.0.1:8086/v1 \ --bench-root . ``` ### 使用 Artifact 协议 ```bash python3 runners/run_track.py python_tool_engineering \ --model \ --protocol artifact \ --endpoint http://127.0.0.1:8086/v1 \ --bench-root . ``` --- ## 基准测试结果示例 当前基线包括本地 OpenAI 兼容模型服务器和外部 CLI 代理： | 代理 | 类型 | 评估轨道 | |------|------|---------| | antigravity-cli | 外部 CLI 代理（Google） | python_tool_engineering（5/3） | | qwen36-27b-mtp-q4 | 本地端点 | python_tool_engineering、rust_porting、repair_needed | | gemma3-27b-q4 | 本地端点 | python_tool_engineering、rust_porting、repair_needed | | codex | 外部 CLI 代理（OpenAI） | pending | --- ## 发展阶段 - **Phase 1**：35 个用例，每轨道 5 个——验证运行器/评分器/报告管道 - **Phase 2**：108 个用例，原轨道各 15 个 + 3 个图记忆工作流探测 - **Phase 3**：365 个用例，完整 v0.1 - **Phase 4**：变异包——范围陷阱、长上下文噪音、修复循环、安全陷阱、遗留债务陷阱 --- ## 对开源维护者的价值 在信任 AI 编程代理接触生产仓库之前，维护者需要知道： 1. 它会修改不该碰的文件吗？ 2. 它能在无人干预的情况下从测试失败中恢复吗？ 3. 它尊重受保护的接口和契约吗？ 4. 通常需要多少次修复尝试，token 成本是多少？ Holon-Bench 用可复现、结构化、评分的结果来回答这些问题。 --- ## 总结 Holon-Bench 代表了一种更贴近现实的 AI 编程代理评估方法。它不是测试代理能否一次性写出正确答案，而是测试代理能否像真正的维护者那样工作——理解反馈、迭代修复、控制范围、避免回归。 对于正在评估或开发 AI 编程代理的团队来说，Holon-Bench 提供了一个标准化的、可复现的评估框架，帮助理解代理在真实维护场景中的实际表现。