构建生产级 AI Agent 评测工具链的实战指南

你的 AI Agent 在演示环境里运行良好。它回答问题、调用工具、完成工作流。所有人都在点头。但上线一周内，它就给客户给出了错误答案。

演示与生产环境之间的差距，就是评估。Eval harness 是一种基础设施，在代码发布前用它对 Agent 进行已知正确结果的测试。你发布的是通过评估的版本，而不是模型第一次写出来的那个。

如果你正在与一家 AI Agent 开发公司合作，他们的评估设置比任何 PPT 都能说明生产就绪状态。

Eval Harness 到底是什么

Eval harness 是针对 LLM 驱动系统的测试基础设施。它在开发期间离线运行。三个组件让它正常工作。

数据集：你自定义的"黄金用例"

忘掉学术基准测试。你的 eval harness 跑的是"黄金用例"，即从你实际用例中抽取的基线示例。客服 Agent？用已知正确解决方案的真实工单。销售线索筛选 Agent？用已知正确决策的真实潜在客户。

前 50 个黄金用例是最难的部分。定义"正确"迫使团队进行大多数团队从未进行过的对话。从 50 个扩展到 200 个是递增进行的。

指标：不只是通过/失败

现代评估框架提供 50+ 种 LLM-as-a-judge 指标：忠实度、任务完成度、幻觉检测、相关性。选择与你失败模式相匹配的指标。你的 AI Agent 开发服务提供商应该将指标映射到你的用例，而不是套用通用模板。

执行流程

Harness 遍历黄金用例，调用 Agent，收集执行轨迹，然后应用指标。输出是一份评分报告，显示 Agent 在哪里通过、失败、以及失败多少。每次 prompt 变更、模型更新或工具行为变化时都会运行。

Eval 与 Guardrail：了解区别

Eval 是离线的。它们在开发期间或 CI/CD 中运行，针对真实情况测量行为，并报告分数。它们告诉你 Agent 是否足够好可以发布。

Guardrail 是在线的。它们在生产环境中运行，实时拦截有问题的输出。它们会阻止、重试或升级。一旦你用评估分数来 gate 部署（除非忠实度保持在 0.92 以上，否则这个版本不能发布），你的 eval harness 就变成了安全基础设施。它是用户和糟糕的模型更新之间的那道门。

为什么 Agent Eval 比 LLM Eval 更难

LLM 评估检查单个输入-输出对。Agent 生成轨迹：推理链、工具调用、中间结果和最终输出。两个 Agent 可能通过不同路径达到相同的正确答案，而一条路径可能是脆弱的。

轨迹质量。Agent 是走了合理路径，还是在找到答案前漫无目的地调用了六个不必要的工具？

工具调用正确性。Agent 是否用正确的参数调用了正确的工具？用错误过滤条件查询 CRM 会返回错误数据，而 Agent 会把它当作真理。

连锁失败检测。第二步的错误会传播到第三步、第四步和第五步。你的评估必须捕获链条在哪里首先断裂。

非确定性处理。相同的输入可能产生不同的运行结果。你的 harness 必须处理可接受的变异性。如果你在评估一家 AI Agent 开发公司的提案，问问他们如何处理轨迹验证。如果答案是"我们检查最终输出"，那他们测试的是 LLM，而不是 Agent。

2026 框架格局

agentevals (LangChain-AI)。MIT 许可。专注于轨迹和工具调用匹配。轻量级，最小依赖。

Strands Evals (AWS)。Apache 2.0。通过 OpenTelemetry 追踪进行自动化根因分析。精确定位失败发生的位置，而不只是知道失败了。

DeepEval。Apache 2.0。电池内置：50+ 指标，通过 pytest 进行 CI/CD 集成，评分追踪仪表板。作为标准 pytest 测试接入现有工作流。

promptfoo。MIT 许可。安全优先，提供 50+ 漏洞扫描（prompt 注入、PII 泄露、越狱）。OpenAI 于 2026 年 3 月收购了 promptfoo，表明安全正在与正确性评估融合。

Arize phoenix-evals。可组合的构建块，用于幻觉、相关性和毒性评分。适合组装自定义流水线。

选择正确的框架

CI/CD gating（阻止坏部署）。DeepEval 或 promptfoo。两者在分数低于阈值时都会让构建失败。

生产监控（捕捉漂移）。Strands Evals 或 DeepEval。两者都支持针对实时行为进行持续评估。

轨迹验证（验证路径，而不只是答案）。agentevals 或 Strands Evals。两者都原生支持多步骤追踪。

安全与红队测试。promptfoo。市场最深的漏洞扫描。大多数生产团队使用两个框架：一个用于正确性，一个用于安全。当你雇佣 AI Agent 开发者时，问问他们使用哪些框架以及为什么。

CI/CD 集成：让 Eval 自动化

手动评估在第二个 sprint 后就会消亡。DeepEval 的 pytest 集成展示了它应该如何工作：eval 用例作为测试函数，每个用黄金输入调用 Agent 并断言指标达到阈值。套件在每个 Pull Request 上运行。如果忠实度下降或幻觉上升，PR 就失败。

这就是定制 AI Agent 开发的实际运作方式。每个 prompt 编辑和工具更新在到达用户之前都要通过评估门控。一个没有这套流程就交付的 AI Agent 开发合作伙伴，交付的是未经测试的代码。

你应该问 AI Agent 开发公司的四个问题

四个问题区分出真正做评估的供应商和只会做演示的供应商。

有多少测试用例？ 低于 50 个是原型。生产环境需要 100 到 200+ 个黄金用例。

每种任务类型有哪些指标？ 只追踪"准确率"会漏掉忠实度、幻觉率、工具调用正确性和轨迹效率。

能展示评估结果吗，而不只是演示？ 评估结果有分数、通过率、失败细分。没有数字意味着没有评估。

评估是在 CI/CD 中运行还是手动运行？ 没有自动化评估的 AI Agent 软件开发，靠的是信念而不是验证。

2026 年塑造 Agent 评估的趋势

安全融入正确性评估。promptfoo 的收购证实了这一点。正确答案和对操控的抵抗能力现在是同一条流水线。

轨迹优先设计。框架正在从"检查输出"转向"检查每一步"。通过糟糕推理达到正确答案的 Agent，是定时炸弹。

在线/离线融合。开发时评估和生产 guardrail 正在合并。Strands Evals 已经可以读取生产轨迹。

自动化根因分析。当评估失败时，追踪数据精确定位行为偏离的确切步骤。

结论

Eval harness 区分的是你信任的 Agent 和你希望它能工作的 Agent。框架存在。集成模式已验证。问题是你的团队或你的供应商是将它构建到流程中，还是在第一次生产故障后才事后补救。

如果你在评估 AI Agent 开发解决方案，从评估对话开始。一个供应商的测试方法论比他们的功能列表更能说明生产结果。

正在构建 AI Agent，想从一开始就把评估做好？与我们的团队讨论构建一个在用户发现前就能捕捉失败的 eval harness。

常见问题

1. AI Agent 开发中的 eval harness 是什么？ 在已知正确示例上运行 Agent、跨指标测量性能并报告分数的测试基础设施。它离线运行。你发布的是通过的那个版本。

2. Agent 评估与 LLM 评估有何不同？ LLM 评估检查输入-输出对。Agent 评估检查完整轨迹：推理、工具调用、中间结果。路径质量影响可靠性。

3. 生产评估套件需要多少测试用例？ 从 50 个黄金用例开始。扩展到 100 到 200 个以覆盖边缘情况和对抗性输入。低于 50 个是原型级别。

4. Eval 和 Guardrail 有什么区别？ Eval 离线运行，针对真实情况测量。Guardrail 在生产中运行，拦截坏输出。Eval gate 发布。Guardrail 捕捉 Eval 遗漏的东西。

5. 哪个评估框架适合 CI/CD gating？ DeepEval 或 promptfoo。DeepEval 作为 pytest 测试运行。promptfoo 在正确性之外增加安全扫描。

6. AI Agent 开发公司应该追踪哪些指标？ 至少追踪忠实度、任务完成度、幻觉率和工具调用正确性。组合取决于用例。

7. Eval 如何融入 CI/CD 流水线？ 写成自动化测试，在每个 Pull Request 上运行。指标低于阈值自动阻止部署。

8. 为什么 OpenAI 收购了 promptfoo？ 这表明安全评估（prompt 注入、PII 泄露）正在与正确性评估融合成一条流水线。

9. 我可以同时使用多个评估框架吗？ 可以。常见配置：DeepEval 用于正确性和 CI/CD gating，promptfoo 用于安全和红队测试。

10. 我应该问供应商关于他们评估流程的什么问题？ 多少测试用例、每种任务类型有哪些指标、能否展示评估结果（不是演示）、以及评估是在 CI/CD 中运行还是手动运行。