Kilo 基准测试（Benchmarking）指南：从 Harbor Smoke Eval 到评估体系路线图-平芜编程栈

Kilo 基准测试（Benchmarking）指南：从 Harbor Smoke Eval 到评估体系路线图

【免费下载链接】kilocodeKilo is the all-in-one agentic engineering platform. Build, ship, and iterate faster with the most popular open source coding agent.项目地址: https://gitcode.com/GitHub_Trending/ki/kilocode

导读：本文基于 benchmarking.md 展开，梳理 Kilo Code 当前已落地的基准测试证据（Harbor 烟测工作流、云端模型评估数据链路）与尚未验证的评估路线图（Harbor 适配器、ATIF 轨迹、Opik 集成）。你将掌握：基准测试要回答的两个核心问题、仓库中 smoke-test 工作流的具体执行细节（触发方式、依赖、两个烟测任务、产物上传），以及贡献者在把"评估命令"写入文档前必须满足的验证要求。

Benchmarking 要回答的两个核心问题

Kilo Code 的基准测试体系围绕两个独立问题设计：

模型对比（Model comparison）：在同一个 Kilo Code Agent 之上使用不同模型，结果如何差异？
Agent / 版本对比（Agent comparison）：在同一个模型与任务集之上使用不同 Agent 或不同 Kilo Code 版本，结果如何差异？

这两个问题分别隔离了"模型变量"与"代理变量"，是后续所有评估设计（任务集、对比维度、轨迹分析）的出发点。需要特别强调的是：基准测试与生产可观测性是两套体系。生产可观测性（见 agent-observability.md）监控的是真实会话的运行状态（指标、会话摄入、告警评估等）；而基准测试运行的是受控的评估任务，用于在发布前、模型切换前获得可复现的质量信号。

该文档的边界声明也很明确：页面内容只区分"已核实的仓库证据"与"路线图规划"，不保证私有基准工具、外部适配器或示例命令对贡献者立即可用。

当前已核实的评估证据

文档以证据表的形式给出了现状（Status 为Partial，即部分落地）：

能力	状态	证据与边界
Harbor 面向的烟测评估（Harbor-facing smoke eval）	当前工作流	`.github/workflows/smoke-test.yml`检出私有仓库`Kilo-Org/kilo-bench`，安装依赖后通过仓库脚本运行两个烟测任务
CLI 发布烟测覆盖（CLI release smoke coverage）	当前工作流	工作流可测试最新 npm CLI，也可测试指定版本的发布产物，随后校验结果
烟测结果产物（Smoke result artifacts）	当前工作流	工作流上传 result、trajectory 与 agent 安装日志供检查
云端模型评估数据摄入（Cloud model eval ingest）	当前服务	静态源码检查发现`services/model-eval-ingest/`的推广同步（promotion sync）表面
私有`kilo-bench`内部实现	此处未验证	私有仓库脚本、适配器行为与支持的本地命令不在已检查文档范围内
生产环境启用情况	此处未验证	静态源码无法证明部署、灰度、留存或供应商配置

可见"已核实"的证据集中在工作流文件层面，而私有基准仓库的内部脚本、适配器行为、生产环境启用情况均明确标注为"未验证"，这也是整篇文档刻意保持严谨的原因。

仓库中的 smoke-eval 工作流：源码级拆解

文档明确指出现有烟测工作流为.github/workflows/smoke-test.yml，该文件在仓库中真实存在。以下是结合源码的完整拆解。

工作流定位与触发方式

从 smoke-test.yml 的头部注释可见其定位：独立的烟测工作流——检出 kilo-bench 并对最新发布的 CLI（或指定版本）运行一小撮 Harbor 评估任务。它有两种触发方式：

workflow_dispatch：手动在 Actions 页面触发，可传可选输入cli_version（例如7.0.36），留空则测试最新 npm 发布版；
workflow_call：由发布工作流在草稿发布产物上传后调用。

工作流还配置了concurrency组（group: smoke-test，不取消进行中的运行）与timeout-minutes: 30的上限。

前置条件与所需 Secrets

工作流运行需要三个 Secrets（缺少时会在 "Validate API key" 步骤直接报错退出）：

Secret	用途
`KILO_API_KEY`	Kilo Gateway 密钥，用于驱动评估中的模型请求
`KILO_ORG_ID`	Kilo 组织 ID
`BENCH_GITHUB_TOKEN`	具有`Kilo-Org/kilo-bench`（私有仓库）`contents:read`权限的 PAT，用于检出基准仓库

执行步骤流水线

工作流运行在blacksmith-2vcpu-ubuntu-2404运行器上，完整步骤为：

检出 kilo-bench：actions/checkout@v6检出Kilo-Org/kilo-bench，使用BENCH_GITHUB_TOKEN；
安装 uv：astral-sh/setup-uv@v6，开启缓存；
设置 Python：uv python install 3.13；
安装依赖：uv sync --no-dev；
校验 API key：KILO_API_KEY为空则输出 error 并退出；
下载 CLI 产物：cli_version为空则测试最新 npm 版；否则用gh release download v$VERSION --pattern kilo-linux-x64.tar.gz从发布草稿下载对应归档，并以环境变量KILO_CLI_PATH传给后续步骤；
运行两个烟测任务（见下文）；
校验结果：python3 scripts/validate_smoke_test.py jobs/smoke-test-*/（脚本位于私有 kilo-bench 仓库中）；
上传产物：if: always()保证即使失败也上传，供排查。

两个烟测任务

工作流通过私有仓库脚本./scripts/run_eval.sh运行两个任务，使用模型kilo/anthropic/claude-sonnet-4.6：

任务	数据集选择	工作流中记录的预期范围
`hello-world`	`-d hello-world`	小规模烟测任务
`log-summary-date-ranges`	`-d terminal-bench-sample --include-task-name "log-summary-date-ranges"`	小型终端基准（Terminal-Bench）样例

两个任务都附加了--job-name（smoke-test-hello-world/smoke-test-log-summary）与--timeout-multiplier 2。关于超时倍增器的设计，工作流注释中有详细说明：Harbor 默认的 agent-setup 超时为 360 秒，而hello-world容器（FROM ubuntu:24.04）在 CLI 真正下载前需要执行apt-get update、apt-get install、NodeSource 的curl|bash以及apt install nodejs，在 Blacksmith 运行器上若 apt 镜像或 NodeSource CDN 变慢，可能超过 6 分钟并触发AgentSetupTimeoutError。将 multiplier 设为 2 可为瞬时镜像/CDN 波动留出余量（该参数会统一缩放 setup、agent、verifier、env build 的超时，但它们都是上限值，因此无害）。

成本与产物

工作流注释给出了成本预期：hello-world约$0.01，log-summary-date-ranges约$0.13，总成本预期低于$0.50，墙钟时间低于 15 分钟。这组数据来自仓库内注释，可作为该烟测在发布门禁场景下开销的参考。

上传产物名为smoke-test-results，路径包括：

jobs/smoke-test-*/**/result.json（评估结果）
jobs/smoke-test-*/**/trajectory.json（轨迹）
jobs/smoke-test-*/**/agent/setup/*.txt（CLI 安装脚本的标准输出/错误/返回码，用于定位卡住的步骤）

产物保留 30 天（retention-days: 30），if-no-files-found: warn避免空目录导致硬失败。注释特别说明：kilo-bench 的安装脚本使用set -euo pipefail（无set -x）且从不回显认证令牌或 API 密钥，因此上传安装日志是安全的。

与发布流程的衔接

在 publish.yml 中，烟测被编排为预发布门禁：smoke-test任务依赖version与build-cli，仅在github.repository == 'Kilo-Org/kilocode'时执行，通过uses: ./.github/workflows/smoke-test.yml复用工作流，并传入cli_version: ${{ needs.version.outputs.version }}与secrets: inherit。最终的publish任务在依赖列表中包含smoke-test，意味着烟测未通过则不会进入发布步骤。这从调用链上印证了文档中"CLI 发布烟测覆盖"与"发布前跑稳定子集"的规划方向。

文档对上述证据的定性是：这证明了 smoke 覆盖存在，但不能据此推断出公开的 Harbor 适配器契约或贡献者可直接使用的本地 CLI。

Cloud model-eval-ingest 的证据边界

文档指出，静态源码检查在云端发现了services/model-eval-ingest/服务，用于推广同步（promotion sync）。需要严格对待的边界是：这仅代表"当前仓库定义的服务表面"（repository-defined surface），部署环境、滚动节奏、数据留存与供应商配置必须另行验证，不能在验证之前作出生产级声明。

路线图：待验证的评估能力

文档给出了清晰的路线图，其中除烟测外均标注为"未验证/规划中"：

能力	状态	预期用途
面向贡献者的 Harbor 适配器	未验证路线图	在受控评估环境中自主运行 Kilo CLI
ATIF 轨迹适配器	未验证路线图	输出结构化 step 级轨迹用于对比
Opik 集成	未验证路线图	摄入轨迹并对比评估运行
标准模型对比工作流	规划中	跨模型对比质量、成本与墙钟时间
标准 Agent 对比工作流	规划中	在同一任务上对比不同 Agent 或 Kilo 版本
自定义任务集模板	规划中	构建聚焦的回归或能力套件
烟测之外的 CI 回归套件	规划中	在发布前运行稳定子集

拟议评估设计：Harbor + ATIF + Opik 的组合

文档提出的更完整评估设计可复用开源评估组件，但前提是在实现过程中逐一验证适配器可用性：

组件	路线图角色	需要验证的内容
Harbor	评估框架与数据集	确认支持的 Kilo 适配器及调用契约
ATIF	结构化轨迹	确认输出的字段与推理数据策略
Opik	轨迹摄入与分析	确认 Harbor 集成配置与 Kilo 适配器支持
Terminal-Bench 或其他数据集	受控任务	确认版本、许可证与任务选择

潜在架构（文档原文）：

Evaluation task set -> controlled trial environment -> verified Kilo adapter -> model request -> result and optional trajectory artifacts -> smoke validation, aggregate analysis, or trace analysis

这条链路与现有 smoke 工作流完全吻合：任务集即hello-world/terminal-bench-sample，受控环境即 Harbor 容器（如ubuntu:24.04），模型请求即kilo/anthropic/claude-sonnet-4.6，产物即result.json/trajectory.json，最后一步即validate_smoke_test.py或未来的聚合/轨迹分析。

拟议对比维度

对比类型	固定输入	变量	衡量指标
模型对比	Kilo Code Agent + 任务集	模型	完成度（Completion）、成本（Cost）、墙钟时间
Agent 对比	模型 + 任务集	Agent 或 Kilo Code 版本	完成度、成本、墙钟时间
轨迹分析	评估任务	运行轨迹	工具选择、错误、重复步骤

模型对比与 Agent 对比共享"完成度 / 成本 / 墙钟时间"三个指标，从质量与资源消耗两个维度给出可量化的决策依据；轨迹分析则深入到单次运行内部，回答"工具选得对不对、哪里出错、是否原地打转"这类行为层面的问题。

命令验证要求：什么不能直接写进文档

文档提出了明确的命令纪律：不要将opik harbor run -a kilo、kilo --auto、kilo run --auto当作开箱即用的接口写进文档，除非在相关仓库中验证了适配器与自主 CLI 调用确实可行。私有kilo-bench工作流命令只是实现证据，不是面向公众的使用保证。这一点直接约束了贡献者在写评估类文档时的措辞边界。