Cline 评测框架面向自主编码 Agent 的三层测试体系与 passk 度量实战【免费下载链接】clineAutonomous coding agent as an SDK, IDE extension, or CLI assistant.项目地址: https://gitcode.com/GitHub_Trending/cl/cline本篇指南基于仓库中的 evals/README.md 及配套源码完整拆解 Cline 的分层评测系统契约测试无 LLM 调用、Smoke 测试真实 LLM 调用的分钟级验证与 E2E 基准测试cline-bench 生产级任务并结合 evals/smoke-tests/run-smoke-tests.ts 与 evals/analysis/src/metrics.ts 的源码实现讲清楚每一层的运行原理、参数含义与结果度量方式。读完后你可以独立运行各层评测、自定义测试场景并能用 passk / pass^k / Flakiness 指标正确解读一次评测运行的结果。一、整体架构测试金字塔与目录结构Cline 评测框架的定位是分层度量系统在任意级别上的表现A layered testing system for measuring Clines performance at different levels。它把一个非确定性的 AI 编码 Agent 的质量问题拆成三个成本递增、保真度递增的层次层级名称位置成本是否调用 LLMLayer 1契约测试Contract Tests / Unitsrc/core/api/transform/__tests__/秒级否Layer 2Smoke 测试evals/smoke-tests/分钟级是Layer 3E2E 测试cline-benchevals/e2e/ evals/cline-bench/小时级是evals/ARCHITECTURE.md 中用一张 ASCII 测试金字塔图直观描述了这三层底层是宽而快的契约测试中间是 Smoke 测试顶部是完整的 Agent E2E 任务。顶层目录结构如下继承自 evals/README.mdevals/ ├── smoke-tests/ # Quick provider validation (minutes) │ ├── run-smoke-tests.ts │ └── scenarios/ # 5 curated test scenarios │ ├── e2e/ # Full E2E with cline-bench (hours) │ └── run-cline-bench.ts │ ├── cline-bench/ # Real-world tasks (git submodule) │ └── tasks/ # 12 production bug fixes │ ├── analysis/ # Metrics and reporting framework │ ├── src/ │ │ ├── metrics.ts # passk, pass^k calculations │ │ ├── classifier.ts # Failure pattern matching │ │ └── reporters/ # Markdown, JSON output │ └── patterns/ │ └── cline-failures.yaml │ └── baselines/ # Performance baselines for regression detection其中 evals/analysis/ 是贯穿各层的共享度量与报告框架metrics.ts 负责 passk 等指标计算classifier.ts 基于 cline-failures.yaml 做失败模式匹配reporters/ 提供 Markdown 与 JSON 两种输出格式cli.ts 则是对外的分析命令行入口。重要现状说明README 原文提示Smoke 测试Layer 2当前处于部分禁用状态——评测框架正在切换到新的 SDK CLI。evals/smoke-tests/ 下的场景被完整保留npm run eval:smoke:run依然会对$PATH中现有的任意cline可执行文件生效可通过npm i -g cline安装。旧的 build-and-link 辅助脚本以及自动运行的cline-evals-regression.ymlCI 工作流已停用直到有人把构建步骤接到新的 SDK CLI 上。二、Layer 1契约测试无 LLM 调用契约测试位于src/core/api/transform/__tests__/直接测试 API 转换逻辑不产生任何 LLM 调用因此快且确定性高。它覆盖三类能力思维链Thinking trace保留跨 provider 消息转换时 reasoning/thinking 块不丢失工具调用解析XML 与原生两种 tool call 格式的解析Provider 格式转换如 Anthropictool_use→ OpenAItool_calls的互转。运行方式npm run test:unit -- --grep Thinking\|Tool Callevals/ARCHITECTURE.md 进一步说明了契约测试的来源旧的evals/benchmarks/tool-precision/目录已被移除其功能被src/core/**/__tests__/中的契约测试与 52 个 system prompt 快照测试覆盖并随npm run test:unit一起运行。ARCHITECTURE.md 还列出了代表性用例树例如thinking-traces.test.ts中的convertToOpenAiMessages preserves reasoning_details、convertToAnthropicMessage preserves thinking blocks以及tool-parsing.test.ts中的 Tool call ID truncation (40 chars) 等断言。CI 定位README 明确指出当前 PR 门禁gate只跑契约测试因为它零成本、零外部依赖适合作为每次合并的硬性检查。三、Layer 2Smoke 测试——用真实 LLM 调用验证 Provider 链路3.1 目标与场景清单Smoke 测试位于 evals/smoke-tests/目的是用真实 LLM 调用做跨 provider 的快速验证分钟级覆盖 3 次/场景的试验以产出 passk 指标实际执行clineCLI 并带上--config、-y、-t、-m参数。evals/smoke-tests/README.md 说明这些测试专门用于捕获以下类型的回归工具执行read、write、edit 文件Provider 响应解析工具链式调用一次任务中多次工具操作基础代码生成。其场景表如下ID名称测试内容01-create-file创建简单文件write_to_file02-edit-file编辑已有文件replace_in_file03-read-summarize读取并总结read_file04-multi-file创建多个文件多次工具调用05-typescript-function生成 TypeScript代码生成06-apply-patch编辑文件GPT-5apply_patch工具、原生工具调用07-edit-gemini编辑文件GeminiGemini 模型变体从当前仓库的 evals/smoke-tests/scenarios/ 目录看除上述场景外还存在08-openai-compat-gpt-oss-edit场景目录——README 中5 curated scenarios的描述对应的是基础 5 个通用场景而 06 之后的编号场景用于覆盖特定模型/Provider 的差异化代码路径如apply_patch仅 GPT-5 系模型走 Responses API 原生工具。3.2 前置条件与认证Smoke 测试要求cline可执行文件在$PATH中可用——Runner 启动时会先执行which cline检查见下文源码分析找不到会直接提示从 npm 安装 cline或链接apps/cli中的 SDK CLI并退出。认证有两种方式继承自 evals/smoke-tests/README.md# 交互式本地开发推荐 cline auth # 带 API key自动化场景 cline auth -p cline -k $CLINE_API_KEY -m anthropic/claude-sonnet-4.5README 中的最小运行示例# Set API key (Cline provider) export CLINE_API_KEYsk-... # Run smoke tests npm run eval:smoke:run # Run specific scenario npm run eval:smoke:run -- --scenario 01-create-file # Run with specific model (overrides per-scenario models) npm run eval:smoke:run -- --model anthropic/claude-sonnet-4.5eval:smoke:run脚本的定义可以在 apps/vscode/package.json 中找到eval:smoke:run: bun evals/smoke-tests/run-smoke-tests.ts即直接用 Bun 运行 run-smoke-tests.ts。3.3 完整参数表Runner 头部注释声明了支持的全部选项参数说明默认值--trials n每个测试的试验次数3--scenario name只运行指定场景全部--model id覆盖所有场景的模型场景自身models字段或默认模型--output file将 JSON 结果额外写入指定文件不写--parallel [limit]并发运行场景×模型任务可指定并发上限关闭上限 4--model会强制覆盖场景的models列表见--model的注释overrides any per-scenario models典型用法# 用场景默认模型GPT-5跑 apply_patch 场景 npm run eval:smoke:run -- --scenario 06-apply-patch # 强制该场景换用指定模型 npm run eval:smoke:run -- --scenario 06-apply-patch --model openai/gpt-4o此外 Runner 支持从仓库根目录的.env/.env.local加载环境变量loadEnvFiles()读取且override: false已存在的环境变量优先。3.4 场景定义config.json 的完整字段每个场景是evals/smoke-tests/scenarios/name/下的一个目录必须包含config.json可选包含template/起始文件目录。Runner 中的SmokeScenario接口run-smoke-tests.ts定义了对应 schema字段必填说明name是人类可读名称description是该场景测什么prompt是传给 Cline 的任务提示词timeout是超时秒数同时作为 CLI-t参数与进程看门狗expectedFiles否任务完成后必须存在的文件列表expectedContent否内容断言数组{ file: file1.txt, contains: expected text }models否场景专属模型列表如apply_patch场景绑定 GPT-5provider否Provider 覆盖默认clinerequiredEnv否该场景运行所需的环境变量名列表缺失时场景被跳过auth否Provider 专属认证配置apiKeyEnv、baseUrlEnv、modelIdsmoke-tests README 给出的最简config.json示例{ name: Human-readable name, description: What this tests, prompt: The task prompt for Cline, expectedFiles: [file1.txt], expectedContent: [ { file: file1.txt, contains: expected text } ], timeout: 60 }3.5 源码剖析一次 Trial 的完整执行流程从 run-smoke-tests.ts 的实现看整个运行流程是场景 × 模型 × 试验三层循环加载与过滤loadScenarios()扫描scenarios/下每个目录的config.json若未指定--scenario则按requiredEnv过滤缺失环境变量的场景被记入skippedByEnv并在输出中列出原因。认证保障ensureScenarioAuth()对每个provider, 模型, baseUrl, keyEnv组合做幂等认证——调用cline auth --config ~/.cline -p provider -k key -m modelId成功的组合写入configuredAuthCache避免重复执行。使用默认clineprovider 且未显式传 key 时直接依赖开发者本机~/.cline已有的认证configuredAuthCache之外的快速路径。执行 TrialrunTrial()每个 Trial 有独立工作目录workspace-trial-N先清空再重建保证相互隔离若场景带template/用fs.cpSync复制起始文件进工作目录组装 CLI 命令cline --config ~/.cline -y -t timeout -m model prompt。其中-y是 YOLO 模式自动批准所有操作、完成后退出-t是 CLI 侧超时-m显式指定模型以保证可复现源码注释明确写道 explicit model setting for determinismrunClineWithTimeout()用spawn拉起子进程并设置看门狗超时后直接SIGKILL并记录 Timeout exceeded非零退出码会被展开为Exit code: N加上 stderr 最后 3 行方便定位失败原因进程退出码为 0 后先按expectedFiles逐一fs.existsSync断言文件存在再按expectedContent用content.includes(check.contains)断言文件包含期望文本任一失败即记为 FAIL 并携带具体错误信息。日志落盘每个 Trial 的 stdout/stderr 与状态写入trial-N.log格式固定为头部Trial 编号、Status、Duration、Error加## STDOUT/## STDERR两段。3.6 结果输出每次运行会在 evals/smoke-tests/results/ 下创建带时间戳的目录形如2026-01-27T19-50-54-391Z其中包含results/ ├── latest - 2026-01-27T.../ # 指向最近一次运行的符号链接 └── 2026-01-27T19-50-54-391Z/ ├── report.json # 完整结构化结果 ├── summary.md # CI 友好的 Markdown 摘要 └── scenario-id/model-id/ ├── trial-1.log # 各 Trial 的 CLI stdout/stderr └── workspace-trial-N/ # 各 Trial 的工作目录summary.md由generateSummaryMarkdown()生成包含总览表Total / Passed / Failed / Flaky / Overall passk、按场景×模型的结果表以及仅列出的失败/不稳定 Trial 的错误详情——专为贴进 CI Job Summary 设计。查看结果的常用命令来自 ARCHITECTURE.md# View latest results cat evals/smoke-tests/results/latest/summary.md # Debug a failure cat evals/smoke-tests/results/latest/scenario/model/trial-1.log ls evals/smoke-tests/results/latest/scenario/model/workspace-trial-1/退出码语义只要report.summary.failed 0Runner 就process.exit(1)使该命令可以直接用作 CI 的通过/失败判据。四、Layer 3E2E 测试——cline-bench Harbor 的完整 Agent 评测E2E 层位于 evals/e2e/任务集来自 evals/cline-bench/git 子模块包含 12 个真实生产级 bug 修复任务通过 Harbor 框架在 Docker/Daytona 沙箱中执行定位为 Nightly CI 运行。运行前提README 与 run-cline-bench.ts 头部注释一致Python 3.13含 uv、Harboruv tool install harbor安装、Docker本地执行或DAYTONA_API_KEY云执行。基本用法# Prerequisites: Python 3.13, Harbor, Docker npm run eval:e2e # Specific task npm run eval:e2e -- --tasks discord # Different provider npm run eval:e2e -- --provider openai --model gpt-4o4.1 Runner 参数与 Provider 映射从 run-cline-bench.ts 的参数解析看支持的完整选项比 README 示例更细参数说明默认值--env docker\|daytona执行环境docker--provider name模型 Provideranthropic--model id模型 IDclaude-sonnet-4-20250514--tasks pattern任务过滤子串匹配任务目录名all--trials n每个任务试验次数1--output file结果写 JSON 文件不写Provider 到 Harbor 模型前缀的映射在源码中显式定义PROVIDER_MODEL_PREFIXanthropic → anthropic、openrouter → openrouter、openai → openai-native、gemini → gemini注释标明需特殊处理API key 环境变量映射PROVIDER_API_KEY_ENV分别为ANTHROPIC_API_KEY、OPENROUTER_API_KEY、OPENAI_API_KEY、GEMINI_API_KEY也接受兜底的API_KEY变量。4.2 任务判定Harbor 的 reward.txtRunner 实际执行的 Harbor 命令为harbor run -p tasks/taskId -a cline-cli -m provider-prefix:model --env env其中-a cline-cli指定被评测的 agent 适配器。每个任务有 30 分钟硬超时timeout: 30 * 60 * 1000。任务是否通过不依赖 Harbor 的退出码而是读取结果文件Runner 扫描cline-bench/jobs/下最新的 job 目录在 trial 子目录中查找verifier/reward.txt当且仅当其内容等于1时判定为 PASS——这是典型的 SWE-bench 风格 verifier 判定。若 harbor 进程退出码非 0 或找不到 reward 文件则记为 FAIL 并附 stderr。运行前置检查checkPrerequisites()会依次验证python3 --version是否 3.13不匹配仅警告、which harbor是否存在缺失则报错并提示uv tool install harbor、docker info是否可用不可用则警告建议--env daytona。若evals/cline-bench子模块未初始化会明确提示git submodule update --init。五、指标体系passk、pass^k 与 Flakiness 的精确公式README 的指标表指标公式含义passkP(≥1 of k passes)解题能力solution finding capabilitypass^kP(all k pass)可靠性reliabilityFlakinessEntropy of pass rate一致性consistency基于 3 次试验的状态判定全过 →pass可靠全挂 →fail坏了混合 →flaky需要调查。metrics.ts 给出了这些指标的无偏估计实现文件头注释注明方法论参考 HumanEval 论文的 passk 估计// passk 1 - C(n-c, k) / C(n, k) // 其中 n 总试验数c 通过数k 抽样数 passAtK(trials: boolean[], k: number): number { const n trials.length const c trials.filter(Boolean).length if (n k) throw new Error(Cannot calculate pass${k} with only ${n} trials) if (c k) return 1.0 return 1 - this.binomial(n - c, k) / this.binomial(n, k) } // pass^k C(c, k) / C(n, k) passCaretK(trials: boolean[], k: number): number { // ... if (c k) return 0.0 return this.binomial(c, k) / this.binomial(n, k) } // Flakiness 二值熵 -p*log2(p) - (1-p)*log2(1-p)p 为通过率 // 全过/全挂 → 0.0通过率 50% → 1.0最大方差 flakinessScore(trials: boolean[]): number { /* ... */ }几个值得注意的实现细节无偏组合估计而非简单频率3 次试验中 2 次通过直接说 pass3 ≈ 2/3 会低估真实能力组合公式1 - C(1,3)/C(3,3)在 nck 的边界情形会给出更保守或更真实的估计metrics.ts 的注释例子即2/3 通过 → pass3 ≈ 96%。binomial()用迭代乘法避免阶乘溢出并对k n-k时取小优化calculateTaskMetrics()对不足 3 次试验自动降级只有trials.length 3才计算 pass3 / pass^3否则置 0——这解释了为什么 Runner 的终端输出在trials 3时只打印pass1标签pass3 is meaningless with fewer trialsgetTaskStatus()的状态机极简passCount totalCount → passpassCount 0 → fail其余 →flaky与 README 的三态描述完全对应。六、失败分类把 flaky 和 broken 区分开来evals/analysis/patterns/cline-failures.yaml 定义了一套 Cline 专属的正则失败模式库version 1.0供 classifier.ts 对失败日志做模式匹配归因。分类覆盖了 Agent 评测中最常见的几类根因类别示例模式特征provider_bugProvider 集成缺陷gemini_signaturemissing.?signature\|thoughtSignatureGemini 原生工具调用需要 thoughtSignatureclaude_tool_formatwrite_to_file.*missing.*contentClaude 工具参数抽取失败指向具体的 provider 集成 bugtransient瞬时、可重试rate_limit429\|rate.?limit\|quota.?exceedednetwork_timeoutECONNREFUSED\|ETIMEDOUT\|ENOTFOUNDmodel_overloaded503\|service.?unavailable重试即可恢复不应计入能力回归harness评测框架自身故障verifier.*failed\|missing.*test.*file是评测器坏了不是 Agent 坏了environment沙箱故障docker.*failed\|container.*exit\|OCI.*runtimeDocker/Daytona 环境拉起失败policy安全策略拒绝content.*policy\|safety.*filter模型因内容策略拒绝执行auth认证错误不可重试401\|unauthorized\|invalid.?api.?key凭证问题这套分类的价值在于当 Nightly E2E 出现失败时可以先把transient/harness/environment类失败与真实的模型能力回归分开避免因为 Docker 没起来而误判模型退化。配套的分析产物还有 schemas/harbor-output.ts、analysis-output.ts两个输出结构定义、parsers/harbor.ts解析 Harbor 输出以及 reporters/markdown.ts / reporters/json.ts。指标与分类器的单元测试位于 evals/analysis/src/tests/metrics.test.ts、classifier.test.ts。七、CI 集成现状README 对 CI 集成给出了三条现状说明这也是理解当前仓库状态的关键事实当前 PR 门禁只跑契约测试Layer 1Smoke 测试 CI临时禁用——原cline-evals-regression.yml工作流在把构建步骤指向新 SDK CLI 之前不会自动运行Nightly E2E尚未实现见下节 TODO。evals/ARCHITECTURE.md 补充了 CI 结果的查看方式Job Summary 贴进 Actions、完整结果以smoke-test-results-run_idartifact 下载以及重新启用 CI 的条件旧工作流构建的是cli/下的遗留 CLI只有将其构建步骤替换为apps/cli下的 SDK CLI 后才可以重新启用。八、快速上手与扩展评测8.1 Quick Start继承自 README# Run all fast tests npm run test:unit npm run eval:smoke:run # Run E2E (requires setup) cd evals/cline-bench # Follow README.md for Harbor setup npm run eval:e2e8.2 添加新的测试新增 Smoke 场景三步创建evals/smoke-tests/scenarios/name/config.json字段见 3.4 节可选添加template/目录放起始文件运行验证npm run eval:smoke:run -- --scenario name。新增契约测试在src/core/api/transform/__tests__/下添加用例运行npm run test:unit -- --grep YourTest。新增 E2E 任务按 README 指引E2E 任务集由 cline-bench 子模块承载新任务需贡献给该子模块仓库evals/cline-bench任务采用 SWE-bench 风格组织。8.3 已知 TODOREADME 原文Nightly E2E CI为 cline-bench 测试添加定时工作流。要求Docker runner、Harbor 配置、约 1–2 小时超时应按 schedule如 nightly而非 per-PR 运行E2E 环境使用独立 secrets。原生工具调用 Smoke 测试为 CLI 增加native_tool_call_enabled设置的支持以便用原生工具调用测试 Claude 4当前只有 GPT-5 系列模型经 Responses API 自动使用原生工具。九、小结如何把这套框架用起来结合源码可以提炼出这套分层体系的工程决策逻辑契约测试守 PR零 LLM 成本、确定性断言验证provider 消息格式转换不会丢 thinking 块、不会解析错 tool call这类最底层的不变量Smoke 测试守 provider 链路用 8 个场景基础 5 个 模型专属 3 个× 默认 3 次试验在分钟级内回答这个 provider/模型今天能不能正常驱动 Cline 的工具执行并用 pass3 / pass^3 / flakiness 区分偶尔失手与链路坏了E2E 守真实能力把 12 个生产级 bug 修复任务放进 Docker/Daytona 沙箱以 verifier 的reward.txt 1为唯一判据定位在小时级成本下回答Cline 作为自主编码 Agent 到底能不能修真实问题指标与分类兜底metrics.ts 的组合数无偏估计 cline-failures.yaml 的六类失败归因让任何一层的失败结果都能被量化解读、且能区分模型退步与环境抖动。需要提醒的适用前提Layer 2 与 Layer 3 均要求真实 API 凭证与外部可执行环境clineCLI 在$PATH、Python 3.13 Harbor Docker并且由于评测框架正在向新 SDK CLI 迁移自动化的 Smoke CI 目前处于停用状态——本地手动运行各层测试不受影响但不要把PR 门禁理解为三层全跑。相关资源索引evals/README.md、evals/ARCHITECTURE.md、evals/smoke-tests/README.md、evals/e2e/README.md、evals/package.json。【免费下载链接】clineAutonomous coding agent as an SDK, IDE extension, or CLI assistant.项目地址: https://gitcode.com/GitHub_Trending/cl/cline创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考