Cline E2E 基准测试实战用 Harbor 与 cline-bench 在真实故障代码库中验证 Agent 能力【免费下载链接】clineAutonomous coding agent as an SDK, IDE extension, or CLI assistant.项目地址: https://gitcode.com/GitHub_Trending/cl/cline本篇指南围绕 Cline 仓库中 E2E Agent 测试 展开讲解如何基于 cline-bench 生产级编码任务、Harbor 执行框架与 Docker/Daytona 环境对 Cline 运行完整的端到端 Agent 评测读完你可以掌握前置环境搭建、全部 CLI 参数、结果判定机制reward 文件与失败排查方法并能对照 run-cline-bench.ts 源码理解 Runner 的完整调用链。一、E2E 测试的定位评测金字塔的第三层在 Cline 的分层评测体系中参见 evals/ARCHITECTURE.md测试被划分为三层Layer 1 契约测试纯单元测试验证 API 格式转换、工具调用解析无 LLM 调用Layer 2 冒烟测试evals/smoke-tests/下的 5 个精选场景分钟级完成调用真实模型Layer 3 E2E 测试即本文主题位于 evals/e2e/基于 cline-bench 的生产级任务耗时以小时计。E2E 测试的核心设计是让 Cline 在真实的、损坏的代码库中完成生产级问题修复。每个任务遵循统一的三段式流程来自 evals/e2e/README.md在 Docker 中启动一个带有缺陷的代码库把任务描述交给 Cline以cline-cliagent 身份运行用pytest验证修复是否成功verifier 产出 reward。这相当于 SWE-bench 风格的问题集任务源自真实用户会话衍生的生产级编码问题而不是玩具示例。二、前置环境搭建按 evals/e2e/README.md 的要求本地运行需要四项前置条件。下面给出原文档的安装命令并补充 Runner 源码中的实际校验逻辑。1. Python 3.13 uv# macOS brew install python3.13 pip install uvRunner 的checkPrerequisites()run-cline-bench.ts会执行python3 --version找不到 Python 3 直接报错退出版本不是 3.13 只打印警告Warning: Python 3.13 recommended, found: ...不阻断运行。2. Harbor基准执行框架uv tool install harbor这是硬性检查源码中执行which harbor失败则返回Harbor not found. Install with: uv tool install harbor并终止。3. Docker本地执行时# 验证 Docker 正在运行 docker info注意源码中 Docker 检查失败只告警不终止Warning: Docker not available. Use --env daytona for cloud execution.——即没有 Docker 时仍可切换到 Daytona 云端执行。4. API Keyexport ANTHROPIC_API_KEYsk-ant-... # 或 export API_KEYsk-ant-... # 通用回退变量从源码可以看到每个 provider 有专属环境变量run-cline-bench.tsProvider专属环境变量anthropicANTHROPIC_API_KEYopenrouterOPENROUTER_API_KEYopenaiOPENAI_API_KEYgeminiGEMINI_API_KEY取值逻辑是process.env[专属变量] || process.env.API_KEY即专属变量优先、API_KEY兜底两者都缺失时该任务直接记为失败Missing API key: ...而不是整体退出。5. 初始化 cline-bench 子模块文档隐含的前置步骤任务集存放在 git 子模块 evals/cline-bench 中。.gitmodules 定义了该子模块Runner 在找不到目录时会提示Ensure the submodule is initialized: git submodule update --init因此在首次运行前需要执行git submodule update --init若跳过这一步Runner 会以cline-bench not found at: ...报错退出run-cline-bench.ts。三、本地运行方式以下为原文档给出的完整命令集相对于仓库根目录执行# 以默认设置运行全部任务Anthropic Docker npx tsx evals/e2e/run-cline-bench.ts # 只运行特定任务子串过滤 npx tsx evals/e2e/run-cline-bench.ts --tasks discord # 使用其他 provider/模型 npx tsx evals/e2e/run-cline-bench.ts --provider openai --model gpt-4o # 在 Daytona 云端运行更快、可并行 export DAYTONA_API_KEYdtn_... npx tsx evals/e2e/run-cline-bench.ts --env daytona # 输出 JSON 结果 npx tsx evals/e2e/run-cline-bench.ts --output results.json对应源码各参数在main()中手工解析默认值为envdocker、provideranthropic、modelclaude-sonnet-4-20250514、tasksall、trials1run-cline-bench.ts与文档中的 CLI Options 表完全一致。需要说明的是当前仓库根目录的 package.json 中并未定义eval:e2e脚本只有test:unit、test:e2e等因此按本文档直接使用npx tsx调用 Runner 是当前可用方式。四、CLI 参数详解参数默认值说明--envdocker执行环境docker或daytona--provideranthropic模型提供商anthropic、openai、openrouter、gemini--modelclaude-sonnet-4-20250514模型 ID--tasksall任务过滤模式子串匹配--trials1每个任务重复试验次数--output-将 JSON 结果写入指定文件三个值得注意的源码级细节Provider 到 Harbor 模型串前缀的映射并非原样透传而是经过PROVIDER_MODEL_PREFIX转换run-cline-bench.tsopenai会被映射为openai-nativeanthropic/openrouter/gemini保持同名前缀。最终拼成的 Harbor 模型串形如anthropic:claude-sonnet-4-20250514。若传入未收录的 provider则直接以其自身名称作为前缀。任务过滤是子串匹配getTaskList()读取evals/cline-bench/tasks/下的子目录名--tasks discord会筛选出所有名称中包含discord的任务run-cline-bench.ts并非精确匹配。--trials的实现方式Runner 在循环里对同一任务重复调用 Harbor每次都是一个完整 trial而不是把试验数传给 Harbor 单进程run-cline-bench.ts。五、Runner 内部执行链一次任务的完整生命周期结合 run-cline-bench.ts 源码每个任务的执行链路如下定位任务目录Runner 以自身位置为基准定位evals/cline-bench/读取tasks/子目录得到任务清单拼装 Harbor 命令核心命令为run-cline-bench.tsharbor run -p tasks/taskId -a cline-cli -m prefix:model --env docker|daytona其中-a cline-cli表明被评测的 agent 是 Cline CLI命令在cline-bench目录下以spawnSync同步执行并继承父进程环境变量附带统一的API_KEY。30 分钟硬超时每次 Harbor 调用设置了timeout: 30 * 60 * 1000与文档中“部分任务需要 20–30 分钟”的说法互相印证结果判定靠 reward 文件Harbor 成功退出后Runner 扫描evals/cline-bench/jobs/下最新的时间戳 job 目录查找该任务对应的 trial 目录中的verifier/reward.txt内容为1记 PASS0记 FAIL找不到 reward 文件则记为Could not determine task resultrun-cline-bench.ts汇总与退出码所有任务跑完后生成BenchmarkReport并在终端打印 SUMMARYTotal / Passed / Failed / Pass Rate。只要有失败任务进程即以退出码 1 结束run-cline-bench.ts这一点为将来接入 CI 的失败判定做了准备。--output results.json写出的 JSON 结构由BenchmarkReport接口定义run-cline-bench.ts{ timestamp, provider, model, environment, trialsPerTask, results: [{ taskId, passed, duration_sec, error? }], summary: { total, passed, failed, passRate } }六、任务集12 个生产级编码任务当前 cline-bench 提供 12 个任务来自 evals/e2e/README.md覆盖多种语言与技术栈的修复/重构/迁移场景every-plugin-api-migration— 迁移插件中的 API 调用police-sync-segfault— 修复段错误intercept-axios-error-handling— 修复 Axios 错误处理telegram-plugin-refactor— 重构 Telegram 插件discord-trivia-approval-keyerror— 修复 Discord 机器人的 KeyErrorterraform-azurerm-deployment-stacks— Terraform 提供方修复orpc-client-migration— 客户端迁移任务v-edit-workspace-tests— 修复 workspace 测试healthchain-prefetch-removal— 移除 prefetch 逻辑aenet-pytorch-pbc-neighborlist— PyTorch 周期性边界条件PBC修复suave-http-data-bleeding— 修复 HTTP 数据泄漏filmarchiver— 影片归档器缺陷修复由于--tasks采用子串过滤例如--tasks discord只会命中第 5 个任务用--tasks pytorch可单独跑第 10 个任务。七、结果目录结构Harbor 会将结果写入evals/cline-bench/jobs/目录结构如下来自 evals/e2e/README.mdjobs/ └── 2025-01-25__10-00-00/ ├── result.json # 聚合结果 └── task-id__hash/ ├── result.json # 单次 trial 结果 ├── agent/cline.txt # 完整会话日志 └── verifier/reward.txt # 1通过或 0失败排查问题时agent/cline.txt记录了 Cline 与环境的完整交互过程verifier/reward.txt是 Runner 判定 PASS/FAIL 的唯一依据——两者结合可以精确定位是 Agent 行为问题还是验证器问题。八、CI 集成为什么只在夜间跑文档明确说明 E2E 测试只在夜间调度而非每个 PR 都跑原因有三耗时长每个任务 20–30 分钟API 成本每次运行约 $1–5取决于所选模型基础设施要求依赖 Docker 或 Daytona 环境。文档同时指向.github/workflows/nightly-evals.yml作为 CI 配置。这里需要基于当前仓库状态做一个审慎说明目前.github/workflows/目录下尚未看到该工作流文件且 evals/README.md 的 TODO 一节明确写着 “Nightly E2E CI: Add scheduled workflow for cline-bench tests”要求 Docker runner、Harbor 就绪、约 1–2 小时超时、独立 secrets。从源码结构看Runner 以失败即退出码 1 的行为设计已经为接入该夜间工作流预留了条件。九、故障排查原文档的 Troubleshooting 章节覆盖了三个高频问题1. “Harbor not found”source .venv/bin/activate # 如使用 venv uv tool install harbor对应源码中which harbor检查失败的路径。2. “Docker not available”# 启动 Docker daemon docker info # 应能正常显示 Docker 信息3. 任务超时部分任务如 Qt WASM、Android 相关可能需要 20–30 分钟。本地运行时请确保 Docker 拥有足够资源建议 8GB 内存。从源码看30 分钟正是spawnSync的timeout值超过即被判定为失败。十、现状说明与延伸阅读当前检出的 evals/cline-bench 目录为空说明子模块尚未初始化首次使用必须先执行git submodule update --init否则 Runner 直接报错退出。根据 evals/README.md整个评测框架在切换到新的 SDK CLI 期间处于部分调整状态冒烟测试Layer 2的 CI 临时停用E2E 夜间 CI 尚在 TODO 列表中。因此本文档描述的运行方式npx tsx直接驱动是当前最可靠的本地评测入口。想理解 passk / pass^k 等指标以及完整的三层测试金字塔可继续阅读 evals/ARCHITECTURE.md 与 evals/README.md任务贡献入口是外部的 cline-bench 子模块仓库见 .gitmodules。小结Cline 的 E2E 评测通过npx tsx evals/e2e/run-cline-bench.ts一条命令把 12 个真实故障代码库交给 Cline CLI在 Harbor 驱动的 Docker/Daytona 沙箱中逐个验证并以reward.txt作为客观判分依据。理解 Runner 的 provider 前缀映射、30 分钟超时与 reward 判定逻辑后你就可以在本地或 CI 中稳定复现整套评测流程并基于--output产出的 JSON 报告做跨模型、跨版本的回归对比。【免费下载链接】clineAutonomous coding agent as an SDK, IDE extension, or CLI assistant.项目地址: https://gitcode.com/GitHub_Trending/cl/cline创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考