终端AI编码代理如何量化评估?kimchi的terminal-bench-2基准与会话审计工具完全手册 终端AI编码代理如何量化评估kimchi的terminal-bench-2基准与会话审计工具完全手册【免费下载链接】kimchiTerminal coding agent powered by Kimchis multi-model orchestration项目地址: https://gitcode.com/gh_mirrors/kimc/kimchikimchi 是一款运行在终端里的 AI 编码代理coding agent CLI由 Kimchi 的多模型编排系统驱动。想回答我的编码代理到底强不强、花了多少钱、哪个环节拖后腿这类问题靠感觉是不行的——kimchi 仓库内置了一套完整的量化评估体系benchmark/ 目录下的 terminal-bench-2 基准测试、manual 手动基准以及 audit-session 会话审计工具让你用数据而非直觉来衡量 AI 编码代理的表现与成本。为什么终端AI编码代理需要量化评估终端 AI 编码代理如 kimchi、Claude Code、OpenCode的实际能力差异很大同样一句修复这个 git 问题有的代理 3 分钟搞定有的反复试错半小时。要对比模型、对比编排策略、控制成本你需要三把尺子通过率在标准任务集上能解决多少问题terminal-bench-2Token 与成本每个阶段、每个模型花了多少会话审计过程质量阶段切换是否合理、架构与测试是否达标会话审计kimchi 把这三把尺子都做成了开箱即用的脚本这就是本文要讲的内容。kimchi 的三层基准测试体系kimchi 的评估工具集中在 benchmark/ 目录分三层各管一件事层级目录作用标准化大考benchmark/terminal-bench-2/在 Docker 容器中跑 terminal-bench 官方 89 个任务输出 reward 分数手动冒烟基准benchmark/manual/预定义 6 类编码任务对比不同模型的 token、耗时、子代理数量会话质量审计benchmark/audit-session/对已完成会话做 6 维度评分产出带等级的审计报告三层工具互为补充terminal-bench-2 回答能不能做对manual 回答哪种模型/编排更省audit-session 回答过程好在哪里、烂在哪里。terminal-bench-289 个真实终端任务的大考terminal-bench-2 是面向终端环境的 AI 代理标准基准包含 89 个任务。kimchi 提供了一个 Harbor 适配器kimchi_agent:Kimchi它会在每个任务容器内安装 kimchi 二进制以非交互模式运行kimchi --print --session /logs/agent/sessions/main.jsonl从会话 JSONL 解析 token 与成本计数器回填到基准的试次trial上下文详细说明见 benchmark/terminal-bench-2/README.md。快速开始一条命令跑通基准前置要求Docker、uv、导出的KIMCHI_API_KEYkimchi 的所有请求都走 Kimchi 网关不需要各家模型厂商的独立 key。export KIMCHI_API_KEY... ./scripts/run-local.sh -i terminal-bench/fix-git去掉-i参数即可跑完整 89 个任务数据集-n 8表示 8 个试次并行./scripts/run-local.sh -n 8其他常用参数-i terminal-bench/build-*只跑匹配 glob 的任务-l 5只跑前 5 个任务-k 3每个任务尝试 3 次--timeout-multiplier 0.5把所有任务的超时减半缩短最坏等待时间聚合结果落在jobs/timestamp/result.json每个试次目录下还有trial.log、result.json含 reward 分数和完整的会话 JSONL可以用kimchi --session path直接回放。单模型 vs 多模型编排模式对比的关键这是 kimchi 基准最有价值的用法——同一个任务单模型和多模型编排到底差多少# 单模型模式指定一个模型全程跑 MODELkimchi-dev/kimi-k2.5 ./scripts/run-local.sh -i terminal-bench/fix-git # 多模型编排模式orchestrator 按阶段分配模型 MODELmulti-model ./scripts/run-local.sh -n 8 -k 3注意MODEL必须写成provider/id格式。除了跑 kimchi 本身仓库还提供run-opencode-kimchi.sh、run-claude-code-kimchi.sh、run-gsd-kimchi.sh三个脚本把其他终端编码代理接进 Kimchi 网关跑同一套任务方便做跨代理横评。此外还可以叠加 A/B 变量--agent-kwarg ferment-oneshottrue让每个试次进入一次性 Ferment 渐进式项目模式--agent-kwarg disable-compactiontrue关闭上下文压缩控制变量后就能量化每个特性对 reward、token、成本的影响。结果在哪里看jobs 目录结构每次运行的产物结构非常规整benchmark/terminal-bench-2/jobs/run/ config.json / result.json / job.log task__trial/ result.json # reward 与异常类型 trial.log # Harbor 完整命令流水 verifier/reward.txt # 验证器写回的分数 agent/sessions/main.jsonl # 主会话完整记录 agent/ferments/ # Ferment 模式下的计划快照与事件日志仓库自带分析脚本 benchmark/terminal-bench-2/scripts/analyze-ferment-bench.py支持run汇总一次运行、trial生成单个试次的证据报告、compare对比同任务多次尝试或跨运行结果三种命令分析地图见 benchmark/terminal-bench-2/docs/ferment-terminal-bench-analysis.md。Apple Silicon 用户必读本地分数不可信 ⚠️terminal-bench 的任务镜像只有 amd64 版本。在 M 系列 Mac 上Docker 的 Rosetta 或 QEMU 模拟都无法覆盖完整 x86 指令集会出现两种假象Rosetta 下代理直接崩溃Illegal instructionQEMU 下验证器段错误、reward 被强制写 0——即使代理其实做对了任务。结论很明确M 系列 Mac 可以用来调试 harness、读工具调用日志但可信的 reward 数字必须在真 x86_64 Linux 上跑如 CI 运行器。这一点写死在 benchmark/terminal-bench-2/README.md 的前置要求里。会话审计工具给 AI 会话打分的 audit-session基准测试告诉你结果audit-session 告诉你过程。它把一段已完成的 kimchi 会话 JSONL 交给一个审计员代理逐条证据核查后产出分级报告入口脚本是 benchmark/audit-session/audit-session.sh# 交互式选择要审计的会话 ./benchmark/audit-session/audit-session.sh # 直接指定会话文件 ./benchmark/audit-session/audit-session.sh path/to/session.jsonl # 换审计员用 claude 跑审计 ./benchmark/audit-session/audit-session.sh -r claude -m opus path/to/session.jsonl六维度评分体系阶段纪律、代码质量与成本效率审计员按 6 个维度给出 A–F 字母等级每个维度都要求附上时间戳、轮次编号、成本数字等具体证据不许和稀泥维度权重检查内容阶段纪律15%阶段顺序是否合理、切换是否及时、plan 是否真在 build 之前架构设计20%设计决策时机、模块边界、是否遵循项目惯例代码质量20%Lint 结果、命名、重复代码、过度设计测试策略20%覆盖率、负路径、测试组织模式阶段-模型匹配10%贵模型是否用在复杂阶段、便宜模型是否用在常规工作成本效率15%分阶段成本拆解 反事实分析如全程只用 Opus 会花多少钱除了这 6 个评分维度审计还会采集 7 组结构性指标逐轮模型归属、每次模型切换的触发原因与延迟、子代理生命周期是否循环、预算消耗、各任务类型的 token 消耗、每个完成任务的单任务成本以及开源模型的使用占比。审计报告的两种产物Markdown 报告 JSON 侧车每次审计在项目目录生成两个文件.kimchi/audits/{sessionId}-{task}-{runner}-{model}-AUDIT.md人读的分级报告含摘要评分表、阶段时间线每阶段时长/模型/轮次/成本、分维度详评、工具使用矩阵以及Top 3 可执行改进项同名-AUDIT.json机器可读侧车文件schema 1.0.0记录各模型 token/成本、切换事件、子代理状态、任务类型聚合等JSON 侧车让批量对比成为可能——用jq就能算出两次运行的成本差、开源模型占比、子代理循环率把感觉这次跑得更稳变成可复现的数字。典型工作流先跑复杂任务再审计复盘完整链路在 benchmark/audit-session/README.md 里有示例cd benchmark/manual ./new-session.sh创建基准会话跑一个复杂任务如./sessions/session-02/run-complex.sh等运行结束把产出的 JSONL 传给审计脚本打开.kimchi/audits/下的报告根据Top 3 改进项调整未来的模型分配、阶段切换或任务拆分手动基准与自我改进闭环benchmark/manual/ 定义了 6 个固定任务简单限流器、复杂 REST API、调研、代码探索等每个任务都带预期基准token 预算、时长上限、子代理数量区间。analyze-session.py按预算逐项给出 PASS / WARN / FAILcompare-sessions.py并排对比两个会话的 token 变化百分比。更妙的是自我改进循环benchmark/manual/start-self-improvement.sh 让 kimchi 以 yolo 模式自动执行构建 → 跑基准 → 分析 → 改代码的迭代闭环协议定义见 benchmark/manual/self-improvement.md。你可以放一个improvement-goals.md文件来定向指挥比如把复杂任务的 token 消耗降低 30%——量化评估工具就这样闭环成了自动优化的燃料。快速上手清单目标命令单任务基准MODELkimchi-dev/kimi-k2.5 ./scripts/run-local.sh -i terminal-bench/fix-git全量 89 任务并行./scripts/run-local.sh -n 8多模型编排对比MODELmulti-model ./scripts/run-local.sh -n 8 -k 3汇总一次基准运行python3 benchmark/terminal-bench-2/scripts/analyze-ferment-bench.py run审计一个会话./benchmark/audit-session/audit-session.sh session.jsonl手动基准对比python3 benchmark/manual/compare-sessions.py一句话总结terminal-bench-2 管做对没有audit-session 管做得好不好、花了多少钱manual 基准管改哪版代码更省。三者都用同一套会话 JSONL 说话——这正是 kimchi 把终端 AI 编码代理的量化评估做得可复现、可对比、可自动化的关键。【免费下载链接】kimchiTerminal coding agent powered by Kimchis multi-model orchestration项目地址: https://gitcode.com/gh_mirrors/kimc/kimchi创作声明:本文部分内容由AI辅助生成(AIGC),仅供参考