2026 年 5 款 AI Agent 评估框架推荐：Inspect AI、DeepEval、Promptfoo 怎么选？

评估 Agent 时，只看最后回答往往不够：模型可能查询了错误订单、重复调用写接口，或者工具失败后仍给出肯定结论。本篇比较五款可用于 Agent 评估的框架，重点是工具轨迹、任务完成与可重复回归。若主要想比较共享实验、生产追踪和团队协作，可看已有的 LLM 应用评估平台推荐。

快速选择

框架	优先验证的任务	主要接入方式	要特别检查
Inspect AI	自定义多步任务、执行环境与 scorer	Python Task、solver / agent、日志	工具结果与参数、限额、样本状态
DeepEval	Python 应用的组件、轨迹和回归测试	测试用例、指标、pytest / tracing	评分输入是否完整，judge 成本与校准
Promptfoo	配置驱动的模型及 Agent 对照	配置、provider、assertions	provider 适配、轨迹断言、运行隔离
Ragas	工具调用与任务目标指标	对话 / 工具轨迹及对应 reference	顺序、额外调用、目标与指标定义
TruLens	从轨迹定位 Agent 失败原因	tracing、反馈与评估指标	span 覆盖、判断依据、数据留存

顺序是场景入口，不是准确率或性能排名。能力核对于 2026-10-17；没有用统一付费测试集对五家作生产基准。

1. Inspect AI：自己定义任务、工具和通过条件

Inspect 用 Task 组合数据集、执行逻辑和 scorer，适合需要精确安排任务环境、模型工具循环和评分的团队。自定义 Python 工具与日志，让开发者可以检查一次任务中的调用对象、参数、结果以及最终回答。编码或长流程评估还可配置 sandbox 和限额。Inspect 官方文档、工具、评分

适合：研究工程、自定义 Agent 任务、需要保留完整轨迹的回归套件。代价是需要自己维护数据集、执行适配和判分规则；框架不会自动定义业务上的正确行为。主仓库 MIT 许可不代表模型和计算费用为零。

2. DeepEval：把 Agent 回归放进 Python 测试流程

DeepEval 当前区分端到端、组件和轨迹评估，能够对工具、检索器、规划器等部分分别分析，也能把测试接入 CI。适合已有 Python 应用、希望从现成指标和测试流程起步的团队。不能沿用“DeepEval 只能比较最终答案”的旧概括。DeepEval 介绍、Agent 入门

使用前先判断指标需要哪些输入：参考调用、trace、目标答案还是 grader。确定性指标和 LLM judge 不应混为一谈；评分模型换版本后也应重跑人工校准样本。Apache-2.0 框架与 Confident AI 托管服务是不同成本层。官方仓库

3. Promptfoo：配置与 assertions 组织多方案对照

Promptfoo 通过 provider 和测试配置连接目标，适合希望集中管理样本、模型或 Agent 变体及断言的团队。官方有 Agent、编码 Agent 和 CI 等接入示例；先确认目标执行方式与依赖版本，再扩大测试矩阵。Promptfoo 入门、编码 Agent 评估

不能假设所有 provider 都自动暴露相同轨迹。应检查断言能否拿到实际工具参数、执行结果和最终工作区状态。涉及代码或工具写入的 provider，需要单独验证工作目录、隔离、凭据和清理方式。不要把一次评分通过解释成整个 Agent 已完成安全验收。

4. Ragas：把工具准确性和目标完成分开测

Ragas 当前 Agent 指标包括 Tool Call Accuracy、Tool Call F1 和 Agent Goal Accuracy 等。准确调用、接近参考调用与完成目标是不同问题：F1 可帮助观察多调用或漏调用，但关键业务动作不应因为一个较高综合分而自动放行。Ragas 工具与 Agent 指标

适合：已经有结构化对话轨迹和 reference，希望对工具路径、目标完成作针对性分析。工具顺序是否必须固定，应根据业务依赖定义；互不依赖的只读调用可以允许多条有效路径，扣费或写操作则需要更严格的动作约束。

5. TruLens：利用轨迹与反馈解释失败

TruLens 的当前入口强调 Agent tracing 与评估，可以把步骤、输入输出和反馈关联起来。适合先从已有应用轨迹定位检索、计划、工具选择和回答的失败，再形成回归样本的团队。TruLens 官方介绍

应先确认集成能捕获所需 span、工具参数和错误，而不是只有外层请求。反馈模型需要说明评分依据，轨迹缺失不能靠更复杂 judge 自动弥补。官网基准属于特定实验条件下的供应商材料，本文没有把它转述成五款工具统一胜负。

费用应按一次完整回归计算

这五个入口覆盖执行框架、指标和 tracing，不适合用一个“每月最低价”排名。对每个方案分别列：软件及托管服务、被测模型、judge 模型、工具 API、sandbox、日志存储和维护。

例如 200 个样本 × 3 次重复 = 600 条运行轨迹；如果每条轨迹还用两项模型评分，可能形成 1,200 次 judge 调用，实际数量由所选指标实现决定。缓存、重试和多轮执行也会改变预算。先用小批样本记录 usage，再决定全量频率；不要把所有指标都默认配置成模型评分。

先做一份共同验收集

准备四类样本：正确调用后回答、对象或参数错误、工具失败、无关或额外动作。每例写清允许路径、必须发生的动作、禁止动作与最终可接受结果。先使用只读 fixture 验证评估器能区分这些情况，再在测试账户运行真实 Agent。

记录任务完成率、关键动作违规数、工具错误数、超时与限额终止数，以及每条可用样本的成本。失败或未完成样本不能默默从分母消失。用人工标注子集验证 judge，保留评分规则和模型版本，避免版本升级后拿不可比的数字宣布“质量提升”。

配套 Inspect AI 教程 给出工具轨迹与确定性评分示例；平台协作取舍见 Inspect AI vs Braintrust。