开源 Benchmark 框架综合评估报告
结合你们的实际建设目标，我把前面讨论的 5 个项目放在同一套评估框架下比较：
- 题库管理：是否能维护、分类、版本化和审核 Benchmark Case。
- 考试执行：是否能组织批次、运行测试、自动判分、回归复测。
- 安全攻防：是否适合提示词注入、敏感数据泄露、越权工具调用和完整 Agent 攻击链。
- 多产品扩展：是否能接入人脸活体、移动应用加固等非 LLM 产品。
- 企业运营：是否能支持团队协作、权限隔离、隐藏题管理、审计和长期运营。
- 落地成本：直接复用多少、需要二次开发多少，以及是否会被特定平台绑定。
先明确一个评估口径：这里说的“支持”，分为三种——开源项目原生具备、通过代码或配置可实现、需要自建或依赖商业版。这三种不能混为一谈。
一、项目定位与基础能力
| 评估维度 | Promptfoo | Langfuse | DeepEval | Inspect AI | PyRIT |
|---|---|---|---|---|---|
| 官方定位 | LLM 测试、红队安全测试 | LLM 应用可观测性与评测 | LLM 应用评测框架 | AI 系统评测框架 | AI 红队攻击框架 |
| 核心形态 | CLI、配置文件、Web UI | Web 平台、SDK、API | Python SDK、CLI、配套平台 | Python SDK、CLI、评测日志 | Python SDK、CLI、攻击编排 |
| 主要使用方式 | 配置测试目标、用例和断言后执行 | 管理数据集，绑定任务并运行实验 | 定义 Golden、Test Case、Metric 后执行 | 定义 Dataset、Task、Solver、Scorer 后执行 | 定义攻击场景、Target、Technique、Scorer |
| 是否面向安全测试 | 是，内置红队测试能力 | 不是其核心定位 | 支持安全相关评测和红队能力 | 可构建安全评测任务 | 是，核心定位之一 |
| 是否有 Web 管理界面 | 有评测结果查看界面；自托管版本有明确限制 | 有，题库管理体验较完整 | 主要通过配套的 Confident AI 平台提供 | 主要是 CLI、日志与程序化工作流 | 提供 Scanner、Shell 等交互入口，偏技术操作 |
| 是否适合非 LLM 产品 | 需自定义 Provider、测试和断言 | 需自定义任务与结果接入 | 需自行实现被测系统适配和指标 | 可编写自定义任务与评分器 | 可自定义 Target，但并非通用非 LLM 测试平台 |
| 推荐扮演的角色 | Agent 安全考试执行器 | 题库管理与评测运营候选 | LLM 专项评分引擎 | 复杂任务评测引擎 | 红队攻击执行与研究工具 |
官方能力依据：Promptfoo 的测试配置和红队工作流、Langfuse 的数据集与实验机制、DeepEval 的 Golden 和 Test Case 模型、Inspect AI 的任务与评分体系、PyRIT 的攻击组件架构。
GitHub
+6
二、Benchmark 库管理能力对比
这一部分最贴近你刚才的问题，也是我认为最需要重点评估的部分。
| 题库管理维度 | Promptfoo | Langfuse | DeepEval | Inspect AI | PyRIT |
|---|---|---|---|---|---|
| 创建与维护题目 | 支持配置文件管理测试用例 | 支持 UI、SDK 创建和维护数据集条目 | 支持代码创建 Golden、Test Case | 通过代码或数据文件定义 Dataset | 通过 Seed、Scenario 等数据结构组织攻击 |
| UI 直接编辑题目 | 有配置和结果 UI，但不是完整的集中式题库编辑器 | 支持 | 依赖配套平台能力 | 不以此为核心 | 不以此为核心 |
| 多专业/多产品分类 | 可通过目录、标签、配置约定组织 | 可通过项目、数据集命名与元数据组织 | 可通过数据集和自定义元数据组织 | 可通过任务、数据集、标签及自定义约定组织 | 可通过场景、标签及自定义数据结构组织 |
| 自定义字段 | 支持变量、元数据及断言配置 | 支持输入、预期输出和元数据扩展 | 支持 additional_metadata 等扩展字段 | 通过自定义数据结构和元数据实现 | 通过场景、Seed、标签等结构扩展 |
| 数据集版本管理 | 以配置文件和版本控制为主；需要自行约束题库版本 | 原生支持 Dataset Item 版本历史 | 本地文件可版本控制；平台提供集中管理能力 | 适合代码与文件版本管理 | 适合代码、配置和数据版本管理 |
| 历史版本复测 | 可用 Git、固定配置及结果记录实现 | 支持按历史 Dataset 版本运行实验 | 可通过固定数据集与代码版本实现 | 可通过固定数据、任务和代码版本实现 | 可通过固定攻击配置、数据与环境实现 |
| 题目审核、审批流 | 需自行建设 | 不等于完整的专业题目审批流，需验证或补建 | 配套平台可支持团队数据集工作流；正式审批流程需核实 | 需自行建设 | 需自行建设 |
| 题目状态管理 | 可通过文件、标签和版本约定实现 | 可通过数据集条目状态、归档等能力管理 | 可通过数据集管理与自定义元数据实现 | 需自行定义状态模型 | 需自行定义状态模型 |
| Smoke / Regression / Gold 分层 | 可通过独立配置、标签和 CI 流程实现 | 可通过独立数据集、命名和元数据实现 | 可通过独立 EvaluationDataset 或元数据实现 | 可通过独立 Dataset / Task 组合实现 | 可通过独立场景与数据集合实现 |
| Hidden Set 隔离 | 配置和执行流程可分离，但不能默认视为强权限隔离 | 可通过项目权限设计部分实现；严格隔离要关注版本、部署和授权能力 | 代码层可分离；平台权限与原始载荷保护需核实 | 可通过独立数据与执行权限设计实现 | 可通过独立数据与访问权限设计实现 |
| 题目来源与溯源 | 需约定 metadata、Git 提交或外部系统记录 | 可在元数据和数据集管理中记录，复杂审批链需补建 | 可使用 metadata、comments 和自定义字段 | 可使用数据文件、代码和元数据 | 可使用 Seed、Scenario、标签及外部数据管理 |
| 跨产品共享题目 | 可通过公共配置、数据文件和标签实现 | 可通过共享数据集或跨项目的数据导入导出设计 | 可通过共享数据文件或平台数据集实现 | 可通过公共 Dataset 和任务代码实现 | 可通过共享攻击 Seed、Scenario 等实现 |
| 题库统计与质量治理 | 评测结果统计较强，题目治理需补建 | 数据集与实验管理较强，专业化题库质量治理需补建 | 评测指标强，完整题库治理依赖代码和平台 | 评测执行与结果记录强，题库治理需补建 | 攻击结果与数据记录强，题库治理需补建 |
Langfuse 的版本能力尤其值得关注：官方文档说明，数据集条目新增、修改、删除或归档会产生新的数据集版本，并可按历史版本运行实验。
GitHub
+1
DeepEval 的 EvaluationDataset、Golden、多轮 Golden 和本地 JSON/JSONL/CSV 导入导出也比较成熟，但需要区分开源 SDK 的数据模型和配套平台的协作管理功能。
DeepEval - The LLM Evaluation Framework
+2
关键判断：这五个项目都不能直接等同于你们要建设的完整 Benchmark 库。 Langfuse 更接近可直接使用的题库管理工作台；其他项目主要以配置文件、代码、攻击场景或评测数据集来组织测试。
三、考试执行、评分与结果分析
| 评估维度 | Promptfoo | Langfuse | DeepEval | Inspect AI | PyRIT |
|---|---|---|---|---|---|
| 批量执行测试 | 强 | 支持实验批量执行 | 强 | 强 | 强，适合攻击批次 |
| 多被测版本对比 | 支持多目标、配置及评测结果对比 | 强，适合数据集实验对比 | 支持模型和应用版本评估 | 强，适合可复现评测 | 支持不同目标与攻击配置对比 |
| 自定义判分逻辑 | 支持断言、脚本及自定义评分 | 支持代码评估、API/SDK 分数和 LLM Judge | 强，自定义 Metrics 灵活 | 强，自定义 Scorer 灵活 | 强，自定义 Scorer 灵活 |
| 精确匹配、规则判分 | 支持 | 支持代码评估 | 支持自定义指标 | 支持自定义评分器 | 支持自定义评分器 |
| LLM Judge | 支持 | 支持 | 强 | 支持 | 支持 |
| 多轮对话评测 | 支持相关测试流程 | 主要通过任务与应用接入实现 | 支持 Conversational Golden / Test Case | 可构建多轮 Solver 工作流 | 支持多轮攻击编排 |
| Agent 工具调用与轨迹分析 | 可通过目标适配、测试和断言实现 | 适合记录与分析运行轨迹，执行本身需要接入 | 支持 trajectory-based evaluation | 可用 Solver 和 Scorer 评估任务过程 | 强，适合攻击链和执行轨迹 |
| 真实攻击编排 | 强，内置红队测试工作流 | 不是主要能力 | 有相关评测和红队能力 | 需要自行构建攻击流程 | 强，核心优势之一 |
| 测试结果报告 | 强，带 Web 结果查看 | 强，数据集实验与评测结果管理 | 代码输出与配套平台报告 | 有评测日志、评分和结果查看 | 有攻击记录、评分和数据导出 |
| 失败用例复测 | 支持回归运行 | 支持历史数据集实验复跑 | 支持重复运行同一数据集 | 支持复跑固定任务与数据 | 支持重复运行攻击场景 |
| 正常任务效用对照 | 可设计正向测试和断言 | 可用独立数据集、任务和分数实现 | 可构建正常任务 Golden 与指标 | 可构建正常任务及效用 Scorer | 可设计正常目标测试，但不是主要优势 |
| 高危用例独立统计 | 可按标签、断言及结果统计 | 可按数据集、元数据和分数设计 | 可通过元数据与指标汇总 | 可通过标签和评分汇总 | 可按攻击类型、场景和评分汇总 |
| 端到端真实状态验证 | 需连接真实执行环境和结果 Oracle | 需连接被测系统与评估任务 | 需自定义轨迹/状态 Oracle | 适合构建复杂任务与状态判分 | 适合构建攻击执行和结果判定流程 |
官方文档分别明确了 Promptfoo 的测试断言和红队流程、DeepEval 的端到端/轨迹/组件级评测、Langfuse 的实验与评分机制，以及 PyRIT 的攻击场景、执行器和评分器模型。
Promptfoo
+4
对你们最重要的一个区别
对于前三个专项——敏感数据检测、意图识别、提示词注入检测——大多数框架都能通过自定义数据和判分器实现离线评测。
但整体 Agent 攻击 Benchmark 不能只判断模型有没有说出正确答案。它需要验证：
- 工具是否真的执行了；
- 是否访问或外传了不允许的数据；
- 权限边界是否被突破；
- 攻击链在哪一步被拦截；
- 正常任务是否仍能完成。
这时，执行环境、轨迹采集和结果 Oracle 比题库本身更关键。Inspect AI 和 PyRIT 值得重点验证这部分能力；Promptfoo 则适合更快建立可重复的安全测试与回归流程。
四、企业化部署、权限与长期运营
| 评估维度 | Promptfoo | Langfuse | DeepEval | Inspect AI | PyRIT |
|---|---|---|---|---|---|
| 开源自托管 | 有自托管 Web 方案 | 支持自托管 OSS | SDK 可本地运行；平台能力需区分 | 支持本地部署和运行 | 支持本地运行 |
| 离线运行能力 | CLI/本地执行可用；具体 Provider 取决于网络与配置 | 可自托管，但依赖其服务组件 | SDK 可本地运行 | 可本地运行 | 可本地运行 |
| 团队协作管理 | 开源自托管版本有明显限制 | 基础协作能力较完整 | 配套平台支持集中数据集与结果管理 | 更偏研发团队协作与代码工作流 | 更偏红队研究和执行团队 |
| 细粒度 RBAC | 开源自托管版不具备完整 RBAC | 项目级细粒度角色控制属于 Enterprise 能力 | 配套平台权限细节需确认 | 主要依赖部署环境、代码仓库和外部系统 | 主要依赖部署环境和外部系统 |
| 操作审计 | 需结合执行记录和部署设计 | 完整审计日志属于 Enterprise 能力 | 需核实配套平台及套餐 | 可用执行日志与外部系统补充 | 有攻击记录，但不能直接等同于企业级审计 |
| Hidden Set 访问审计 | 需要补充 | 可结合权限体系和审计能力，但需核实版本与授权 | 需补充或依赖平台能力 | 需自建访问控制与审计 | 需自建访问控制与审计 |
| 高可用、水平扩展 | 开源自托管 Web 方案官方明确有扩展限制 | 支持自托管，部署规模取决于基础设施与版本 | 主要是评测 SDK 的运行扩展，集中平台另行评估 | 可通过任务执行基础设施扩展 | 可通过执行器、数据库及任务调度体系扩展 |
| 结果 API 与集成 | 支持程序化执行、结果和 CI 流程 | SDK/API 较完整 | SDK、CLI 和配套平台集成 | Python API、CLI、评测日志 | Python API、目标接口和数据导出 |
| 数据本地化 | 本地运行可控制测试数据去向；远程 Provider 另论 | 自托管可控制部署位置 | 本地 SDK 可控制数据流；平台使用时需审查 | 本地执行可控制数据流 | 本地执行可控制数据流 |
| 商业化依赖风险 | 需关注开源自托管版与 Enterprise 功能差异 | 需重点关注 Enterprise 权限、审计等功能边界 | 需区分开源 SDK 与 Confident AI 平台 | 相对适合代码自主控制的评测流水线 | 相对适合代码自主控制的红队流水线 |
这一表中有三项需要特别注意：
Promptfoo 官方明确指出，其基础自托管版本不支持多团队 RBAC 和水平扩展，且不建议将该版本直接用于生产级场景。
Promptfoo
Langfuse 的 OSS 核心功能采用 MIT 许可证，但项目级 RBAC、审计日志、数据保留策略等部分企业功能需要 Enterprise 许可。
GitHub
+1
DeepEval 的核心 SDK 为 Apache 2.0 开源项目；其配套 Confident AI 平台承担更集中的数据集管理、失败轨迹沉淀和团队协作功能，不能把平台能力全部视为纯开源、自托管能力。
GitHub
+1
对你们来说，这意味着：如果 Benchmark 需要保存客户 POC 数据、攻击载荷、漏洞细节和 Hidden Set，数据驻留、角色权限、审计能力与许可证边界应该进入选型的硬性评估项，而不是上线后再补。
五、优劣势与二次开发工作量
下面的工作量是针对你们的目标进行的工程估算，不是项目官方承诺。假设已有基本的测试环境、API 和产品技术负责人，且先建设 MVP。
| 项目 | 核心优势 | 主要短板 | 二次开发重点 | 初步工作量估算 |
|---|---|---|---|---|
| Promptfoo | 上手快；红队测试、用例执行、断言和回归流程成熟；适合快速形成测试闭环 | 不适合作为完整的多产品题库运营中心；开源自托管版本的协作和扩展能力有限 | 统一 Case Schema、题库生命周期、Hidden Set 隔离、多产品适配器、企业级任务调度 | 接入现有 Agent 安全测试：约 1–3 人周；扩展成多产品运营平台：约 6–12 人周 |
| Langfuse | UI 和数据集管理体验较好；支持数据集版本与实验；适合集中维护评测数据和结果 | 本质上不是红队攻击执行引擎；复杂攻击链、专业审批和严格 Hidden Set 需要额外设计；部分企业权限功能收费 | 安全 Case 扩展字段、攻击执行器、专业审批、Hidden Set 安全边界、成绩单 | 基础题库 MVP：约 2–5 人周；多产品安全 Benchmark 平台：约 6–12 人周 |
| DeepEval | Python 评测开发体验好；自定义指标灵活；适合 Golden 数据集、单题判分及 Agent 轨迹评测 | 集中化题库管理体验主要依赖配套平台；非 LLM 产品接入需要自定义 | 统一数据模型、题库 UI、非 LLM 适配器、考试批次和权限管理 | LLM 专项评测：约 1–3 人周；多产品管理平台：约 8–16 人周 |
| Inspect AI | 适合复杂任务、Solver/Scorer、自定义评测环境和可复现考试；代码自主性较高 | 不是开箱即用的题库管理系统；业务人员直接编辑题库的体验不足 | 题库管理 UI、Case 生命周期、跨产品任务调度、结果运营和权限体系 | 复杂 Agent 评测：约 2–5 人周；多产品管理平台：约 8–16 人周 |
| PyRIT | 攻击研究和红队编排能力突出；适合多轮攻击、攻击技术组合、攻击结果采集 | 不是通用 Benchmark 题库；正常任务评测、产品专业管理和企业题库治理不是其重点 | 通用 Case 层、非 LLM 执行器、考试批次、题库审核、综合成绩统计 | 红队攻击测试接入：约 1–3 人周；多产品管理平台：约 8–16 人周 |
工作量仅用于立项初估。若要做到生产级权限、审计、高可用和完整审批流程，实际投入可能明显增加；多个框架并行集成也会带来额外维护成本。
六、按你们的目标进行综合评分
以下是我基于本次需求给出的主观适配评分，满分 5 分。它不是开源项目的官方排名，重点衡量的是对易盾多产品 Benchmark 建设的适用程度。
| 评估项 | 权重 | Promptfoo | Langfuse | DeepEval | Inspect AI | PyRIT |
|---|---|---|---|---|---|---|
| 题库管理与维护 | 20% | 3.0 | 4.5 | 3.0 | 2.5 | 2.0 |
| 安全测试执行 | 20% | 4.5 | 2.5 | 3.5 | 3.5 | 4.5 |
| 自定义判分与结果分析 | 15% | 4.0 | 4.0 | 4.5 | 4.5 | 4.0 |
| 多产品扩展能力 | 15% | 3.0 | 3.0 | 3.0 | 4.5 | 3.0 |
| 企业运营与权限 | 15% | 2.5 | 3.5* | 3.0* | 2.0 | 2.0 |
| 开源自主可控程度 | 10% | 4.0* | 4.0* | 4.5 | 5.0 | 5.0 |
| 上手与落地速度 | 5% | 4.5 | 4.0 | 4.0 | 3.0 | 3.0 |
| 加权参考分 | 100% | 3.6 | 3.5 | 3.5 | 3.5 | 3.3 |
*Langfuse 的企业权限、DeepEval 的集中化协作，以及 Promptfoo 的自托管能力均需结合具体版本和许可证验证。评分主要用于确定 PoC 顺序，不能替代实际测试。
分数接近并不是因为这五个项目能力相同，而是因为它们解决的问题不同：Langfuse 偏题库和实验运营，Promptfoo 偏测试与安全评估，Inspect AI 偏可编程任务评测，PyRIT 偏攻击研究，DeepEval 偏指标和判分。
七、最终建议：先验证两条路线，不要一开始就全都集成
路线 A：Langfuse + 自建轻量运营层
优先验证题库管理
适合希望尽快得到可视化题库、版本管理、数据集实验和统一结果工作台的团队。重点验证 Hidden Set 隔离、Case 自定义字段，以及人脸活体和 App 加固结果能否接入。
路线 B：Promptfoo + 自建统一题库管理层
优先验证安全测试执行
适合先快速落地 Agent 安全攻防、提示词注入测试和回归考试。统一题库、审批、专业管理和 Hidden Set 权限由你们掌控，其他产品通过适配器接入。
我的建议是，用同一批 30–50 个 Agent 安全 Case，分别验证这两条路线，并加一个复杂攻击链场景和一个非 LLM 产品模拟接入任务。对比实际开发量、判分准确性、题库维护体验和权限边界，再决定架构。
最后提醒一点：不要让题库管理工具决定你们的 Benchmark 数据模型。 先确定统一 Case Schema、版本、分层、来源和判分规范，再让框架适配你们的标准。这样未来替换执行引擎或新增产品专业时，题库和历史成绩不会被某个开源项目锁死。
文档信息
- 本文作者：zhupite
- 本文链接：https://zhupite.com/ai/red-team-platform.html
- 版权声明：自由转载-非商用-非衍生-保持署名（创意共享3.0许可证）