开源 Agent 评测工具怎么选：12 个工具、5 套组合与许可证红线

文章来源：微信公众号「银翼AI评测室」于 2026 年 11 月 10 日发布《开源 Agent 评测工具横向对比：附 5 套可直接抄的组合选型方案》。原文标注价格与许可证核对时间为 2026 年 11 月。

本文处理方式：保留原文的分层模型、工具短板与五套组合，另外对 12 个工具的仓库与许可证做了独立核验（2026-11-11），凡与原文不一致处单独标注。原文中的价格、企业版能力与 probe 额度属于会变动的商业条款，本文只写“以官方当期为准”，不当作固定事实。

一句话结论

选开源 Agent 评测工具，先分清它在链路里负责哪一段，再谈品牌：引擎负责跑和判，指标库负责判得准，平台负责存和看，基准负责对外比较，标注负责人工复核。 把引擎当平台用，会在多租户、权限和报告上撞墙；把平台当引擎用，会在判分粒度和 CI 门禁上返工。

原文有一句话概括得很准：同时满足自托管、可对外交付、有 Agent 轨迹的工具不到一半。所以真实选型不是挑一个最强工具，而是拼一条各段职责清晰、许可证没有断点的栈。

核验说明：许可证先看这一张表

原文把“越靠上层，许可证越容易有断点”作为核心判断。这个判断成立，但具体条目要按仓库实际核对。我用 GitHub API 逐个查了 SPDX 标识（2026-11-11）：

两条需要记住的许可证红线：

• ELv2 不是“随便用”。Phoenix 的 ELv2 明确限制：不得把软件作为托管或管理服务提供给第三方。对客户交付评测报告通常没问题，但如果你要把评测能力包装成 SaaS 卖，这就是断点。
• open core 要看目录边界。Langfuse 的 MIT 只覆盖 ee/ 之外的代码；RBAC、SSO、审计日志等能力在云端要 Pro + Teams 附加包或 Enterprise 才有。自托管免费不等于功能齐全。

另外原文有一处口径不一致：正文说“分成四层”，表格实际列出五类——引擎、指标库、平台、基准、标注。本文按五类组织。

一、五类工具的分工与硬短板

引擎：跑用例、算通过、给退出码

promptfoo 的定位要特别注意：它的自托管文档写得很直白——自托管服务器用本地 SQLite 和内存作业队列，Helm 部署必须保持 replicaCount: 1。这不等于“不能自托管”，而是不能把它当高可用评测平台。

指标库：把“好不好”变成可计算的分数

指标库的共同局限：它们回答的是“这段输出相对给定上下文是否可靠”，不回答“Agent 在多轮里有没有按顺序调对工具”。工具型 Agent 必须补轨迹断言。

平台：存 trace、管数据集、看趋势

基准与标注：一个负责对外比较，一个负责人工兜底

一个常见误配：用 Label Studio 当评测平台。它没有跑批调度、没有模型调用、没有自动判分，只能承担“人来打分”这一环。

二、五套组合：按画像对号入座

原文强调五套是并列关系，不是升级路线。这一点很重要——不要五套都上，那是五个维护负担。

方案 1：个人验证型（3 天判断值不值得做）

适用：1–2 人，手上有个刚成型的 Agent，要回答“继续投入还是砍掉”。

最小栈：Inspect AI（引擎）+ DeepEval（指标）+ 本地 JSON + 手写两页结论。不装平台、不建库、不做看板。

关键配置：

• 30–50 条用例，覆盖主流程、边界，再加至少 5 条故意刁难的
• 每条采样 3 次，用通过率下结论，不看单次结果
• 判分分两层：能程序断言的先写死（字段、工具名、调用顺序），剩下的再用 rubric 让模型判
• 失败样例逐条人工过一遍——这一小时比多跑 200 条值钱

成本：软件 0 元；人力约 2–3 人日；算力按模型单价另算。

失败模式：用例只写顺利路径、判分只看最终答案。分数虚高，上线才发现问题。

方案 2：团队门禁型（PR 阶段挡回归）

适用：3–10 人，Agent 已上线或即将上线，每次改 prompt、换模型、加工具都怕弄坏老功能。

最小栈：promptfoo（引擎 + 门禁）+ Opik 或 Langfuse（平台）+ 自渲染报告。三件事分开，谁坏了修谁。

关键配置：

# 示意：promptfoo 断言的两层写法
tests:
  - vars:
      question: "查一下订单 12345 的状态"
    assert:
      - type: contains
        value: "已发货"          # 硬断言：字段/关键值
      - type: javascript
        value: "output.includes('order_query')"  # 工具名/调用顺序类断言
      - type: llm-rubric
        value: "回答没有编造物流时间，且说明了数据来源"

• PR 档：20–30 条冒烟用例，5 分钟内出结果，失败直接挡合并
• 夜间档：100 条以上，每条 5 次采样，结果进平台看趋势
• 双阈值：总体通过率 + 10 条关键用例必须全过。只设总体通过率，最容易掩盖关键路径崩坏

成本：软件 0 元；人力 5–10 人日，主要花在接 CI 和调判分；平台自托管需一台常驻机器（原文建议 4C8G 以上），存储随 trace 增长，提前留盘。

失败模式：

1. 把 promptfoo 自托管当生产平台——SQLite + 内存队列，多副本会找不到 Job，也没有多租户与 SSO
2. 阈值拍脑袋定，第一天门禁全红，两周后没人看，门禁形同虚设

方案 3：对外服务型（按项目交付报告）

适用：要接客户、按项目交付评测报告，客户可能要求数据不出机房。

最小栈：Inspect AI + DeepEval + Opik + Label Studio + 自研报告层。

为什么这么选：许可证干净——MIT 与 Apache-2.0，没有“自托管仅企业版”的断点。

明确排除：Braintrust、LangSmith、Confident AI、Phoenix。前三个的平台能力绑定商业版；Phoenix 是 ELv2，对外托管有硬限制。

能力边界：Opik 的项目维度可给每个客户独立空间，trace 与数据集不混；Label Studio 承担客户侧或内部人工抽样复核；报告层必须自研（元信息、总览、分维度、失败归因、修复建议、附录）。

成本：软件 0 元；人力是最大变量，瓶颈在报告层而不是跑批；周期按 4 周起估算。

失败模式：签合同前没确认“客户要私有化”和“客户要审计与权限隔离”这两件事，交付时才发现用错了许可证。

方案 4：中文基准型（评国产模型或建行业基准）

适用：要评国产模型、在中文业务场景里比模型，或要建自己的行业基准集。

最小栈：EvalScope（中文基准 + 压测）+ OpenCompass（组织基准与评测范式）+ 自建题集 + Label Studio（人工复核）。

关键配置：

• 固定解码参数：temperature、max_tokens、stop 全部写死。同一批题在多个模型上跑，参数不一致结论就不可比
• 中文题必须本地化：术语、口径、输出格式、拒答行为四项都得改；机翻题测不出真实差距
• 抽 10% 题人工复核，确认判分逻辑没跑偏

成本：软件 0 元；人力 2–3 周，其中建 100–200 条题约 5–8 人日；标注成本按本地人力单价核算。

失败模式：拿公开榜分数当产品结论；中文题直接机翻；不同模型解码参数不一致；题目与训练集重叠导致分数虚高。

方案 5：安全红队型（上线前过一轮）

适用：上线前要过安全评审、客户要求提示注入测试，或 Agent 能调工具、能碰真实数据。

最小栈：promptfoo redteam（攻击面覆盖）+ Inspect 沙箱（受限执行）+ 人工复核兜底。

关键配置：

• 攻击面按 OWASP LLM Top 10 组织
• 工具型 Agent 必测三条：越权调用工具、被注入后改目标、把数据带出去
• 每条记录版本、时间、模型、结论，方便复现
• 插件报告不能直接交付，高危项必须人工确认

成本：软件 0 元（在 probe 额度内）；人力 3–5 人日；1–2 周。promptfoo 社区版当前标称每月 1 万 probe，单轮 500–1000 probe 远低于额度。

失败模式：只跑插件不写业务攻击画像；把红队报告当合规证明——这两件事不是一回事。

三、三个问题定路线

原文用“三问定路线”收尾但没展开具体问句。下面这张判定表是我根据五套方案反推的，不是原文逐字内容，供快速对号：

四、无论选哪套，这五件事先做对

1. 判分分两层

能确定性断言的（字段、枚举值、工具名、调用顺序、JSON schema）先写成代码断言；只有主观质量项才交给 rubric 或 LLM 裁判。反过来做，等于把可复现的部分也交给了概率。

2. 用通过率而不是单次结果

LLM 输出有随机性。同一用例采样 3–5 次，看通过率与置信区间，比挑一次最好结果有意义得多。

3. 门禁要有双阈值

只看总体通过率，10 条关键路径挂了 2 条，整体分数可能仍达标。关键用例必须单独设“全过”门槛。

4. 平台与引擎解耦

引擎升级频繁，平台承载历史数据。把“跑”和“存”分开，换引擎时历史数据还在，迁移成本可控。

5. 报告层不要外包给工具

工具能出图表，但出不了“为什么这个版本变差、该改哪一段”的归因。对外交付的报告层必须自己掌握叙事结构。

五、必须说清的边界

原文自己列了三条，我认为都成立，再补两条：

• 价格与许可证有时效。 本文表格是 2026-11-11 的仓库快照；企业版能力与额度以官方当期为准。
• 能力判断有主观成分。 “生态较新”“报告能力弱”是使用体感，不是 benchmark。
• 公开基准不等于产品结论。 榜单测的是通用能力，你的业务结论只能由你的题集给出。
• 五套组合不是标准答案。 它们是起点，不是终点；团队变大、客户要求变化后要重新选。
• 许可证要看目录，不看 README 一句话。 open core 项目的 MIT/Apache 往往只覆盖部分目录，ee/、enterprise/ 下另有一套条款。核许可证的正确方式是看 LICENSE 全文加仓库目录结构，而不是看徽章。

结语

这份横评最值得抄走的不是某一张工具表，而是两层判断：

1. 分层判断：先确认缺的是引擎、指标、平台、基准还是标注，再选工具。多数“工具不好用”的问题，其实是层选错了。
2. 许可证判断：在私有化、对外托管、审计这三类需求上，许可证比功能更早决定可行性。

如果你现在只有一件事能做，就做这件：把最近三个月的线上问题整理成 30 条冒烟用例，接进 CI，只做“不比现在差”的判断。先有能跑的门禁，再谈平台化和多租户。

参考资料

• 微信公众号「银翼AI评测室」：《开源 Agent 评测工具横向对比：附 5 套可直接抄的组合选型方案》，2026-11-10，https://mp.weixin.qq.com/s/J-g6z6FjUPYx1FpQ9fcwRQ
• promptfoo 自托管文档（SQLite + 内存队列、单副本限制），https://www.promptfoo.dev/docs/usage/self-hosting/
• promptfoo 定价（社区版含每月 1 万 probe），https://www.promptfoo.dev/pricing/
• Langfuse 定价（RBAC/SSO 在 Teams 附加包，审计日志在 Enterprise），https://langfuse.com/pricing
• Braintrust 定价（Pro 249 美元/月），https://www.braintrust.dev/pricing
• Langfuse 许可证（MIT Expat 核心 + ee/ 另许），https://github.com/langfuse/langfuse/blob/main/LICENSE
• Phoenix 许可证（Elastic License 2.0），https://github.com/Arize-ai/phoenix/blob/main/LICENSE
• 各工具仓库：https://github.com/promptfoo/promptfoo、https://github.com/UKGovernmentBEIS/inspect_ai、https://github.com/confident-ai/deepeval、https://github.com/vibrantlabsai/ragas、https://github.com/comet-ml/opik、https://github.com/mlflow/mlflow、https://github.com/modelscope/evalscope、https://github.com/HumanSignal/label-studio、https://github.com/argilla-io/argilla、https://github.com/open-compass/opencompass

来源字段：2026-11-10｜微信公众号「银翼AI评测室」｜https://mp.weixin.qq.com/s/J-g6z6FjUPYx1FpQ9fcwRQ ｜按引擎、指标库、平台、基准、标注五类拆解 12 个开源 Agent 评测工具，核验许可证断点并给出五套组合选型｜适合正在搭 Agent 评测体系、需要私有化交付或建立 CI 门禁的团队，可作为选型起点与许可证风险清单。