EvalCore

我们在撞上每个团队在交付 LLM 功能时都会碰到的同一面墙之后，做出了 EvalCore：你改了 prompt 或者换了个更便宜的模型，没有任何"货检测试"时刻能告诉你你的 AI 是不是变差了。你只能从用户那里发现。

现有的方案都有一票否决的硬伤：

CI 里的 eval 套件既不稳定又贵。每次重跑都会打到真实的 LLM API，所以你每个 commit 都要为同样的调用付费——而且一个不稳定的 LLM judge 会以非确定性的方式让你的构建失败。团队会悄悄停止运行 eval。

大多数工具只给最终答案打分。对于 agent 来说，路径才是关键：调用了哪些工具，顺序是什么，成本是多少。

所有东西都假设你在用 Python 或 Node。如果你的应用是 Rust、Go、Java，或者混合栈，那就没你什么事了。

EvalCore 是一个小二进制 + 一个 YAML 文件。把它指向你的应用（HTTP 端点、shell 命令，或者导出的 trace），写好你的检查，运行 evalcore run。退出码 0 或 1——直接接进 CI。

我觉得真正不同的三件事：

🎬 Record/replay 是核心原语。每次 LLM 调用——包括 judge 调用——都会被录制到本地的 SQLite "cassette"里。提交它，CI 就能逐字节回放：零费用、离线、零不稳定。把 AI 行为当成 Cargo.lock——--cache live 就是你显式的 cargo update。漂移检测应该放到夜间任务里，而不是让一个无关的 PR 失败。

🤖 Agent 按"做了什么"打分，不只是"说了什么"。EvalCore 会读取你的应用已经在发出的 OTel/OpenInference trace，并对轨迹做断言：must_not_call: issue_refund before: verify_identity，max_steps: 8。策略即 CI 断言，无需 SDK，任何语言都能用。

🔒 真正做到 Local-first。结果、历史和 cassette 都存在你仓库旁边的 SQLite 文件里。无需注册、没有服务器、没有遥测——什么都不离开你的机器。如果你在受监管的、不能把 trace 发到 SaaS 的环境里，这就是为你准备的。

附带的能力还有：回归基线（--baseline main 把关的是"不要变差"，而不是"完美"）、套件级门槛（pass-rate 下限、分类任务的 accuracy/macro-F1）、用于随机输出的 trials: N、模型并排对比（--matrix gpt,claude 打印逐用例胜者和成本）、成本预算、可分享的 HTML 报告，以及本地运行历史查看器。你现有的 Ragas/DeepEval 指标通过 5 行 subprocess 包装就能原样跑起来。

先打个预防针：这还很早期。EvalCore 还在 pre-1.0——核心引擎、缓存、轨迹规则和门槛已经发布并经过测试，但配置面和 API 在小版本之间可能还会变动，provider 适配器目前还很薄（现在只支持 OpenAI 兼容 + 通用 HTTP），仓库里也有我公开追踪的已知缺口（judge 调用还没计入预算、没有多轮对话模拟、不支持 Windows shell target）。我宁愿在这里先说清楚，也不想让你在落地到一半才发现。如果你现在就上手试用，你对接下来要做什么会有不成比例的影响力。

它不是什么：不是可观测性平台，不是 prompt 管理器，也不主打速度——eval 是 I/O 密集的，所以我们并不宣称快很重要。我们主张的是：你的 eval 套件应该是一个二进制、在 CI 里确定性的、并且可以免费反复跑。

Apache-2.0 协议，底层是 Rust，使用时完全不需要懂 Rust。

cargo install evalcore 或者直接下载二进制——快速入门完全离线、零 API key、5 分钟内就能跑起来。我真心希望听到它在你那套技术栈上哪里坏掉：缺哪些 target 类型、scorer 或 trace 格式？🙏