首先需要明确一个观点：在许多团队中，LLM 评测的优先级往往被排在上线之后。一旦确定了这个顺序，后续补做的成本将极为高昂。因为系统一旦接入真实用户、真实工具、甚至投入真金白银的预算，再回头讨论“什么算失败”，代价会非常巨大。

因此，我认为像 promptfoo 这样的工具应该被前置使用——在 prompt、RAG、agent 或多模型方案正式进入生产环境之前，就需要将可重复的测试集、断言、模型对比以及红队检查等内容，嵌入到一个可直接执行的配置中。

Doramagic 在 promptfoo 的项目说明书中将其定义为 LLM 评估与测试工具包（LLM eval and testing toolkit）。它并非简单地运行几个 prompt 并查看输出，而是围绕配置、provider 调用、断言评分（assertion grading）、结果聚合和 CI 集成，构建了一个完整的评测闭环。

项目说明书：
https://doramagic.ai/en/projects/promptfoo/manual/

项目页：
https://doramagic.ai/en/projects/promptfoo/

promptfoo 的核心价值并非“打分”，而是定义“发布边界”

许多 AI 应用的最大风险，并非模型完全无法工作，而是在某些边界场景下表现极不稳定。例如：同一个问题换一种问法，答案格式就出现偏差；RAG 检索到了相关内容，但回答却遗漏了关键事实；agent 成功调用了工具，却使用了未经授权的工具；更换模型后成本降低，但错误类型也随之改变；红队测试的提示轻松绕过了原本看似稳固的防护栏（guardrail）。

如果仅依赖人工体验，这些问题很容易被“这次看起来还行”的错觉掩盖。promptfoo 的精髓在于将这些主观“体验”转化为可重复执行的测试。

在 Doramagic 的 manual 中，promptfoo 的核心评测引擎分为三个子系统：

• 配置与 provider 解析： 使用 YAML/JSON 声明待测试内容、使用的模型以及调用的 provider。
• 测试执行与并发： 对 prompt、测试用例、provider 的组合进行 fan-out 执行，并处理重试、缓存和超时等问题。
• 断言评分与结果报告： 支持字符串匹配、schema 检查、LLM 作为评判（LLM-as-judge）、多模态评分等多种深度的判断。

换言之，它更像 AI 发布前的“测试闸门”，而非临时编写的 benchmark 脚本。

对 Agent 项目尤为关键：工具调用必须可验收

在 Agent 系统中，最危险的失败往往不是“未完成任务”，而是“完成任务的方式本身不可接受”。例如：工具调用顺序混乱；使用了未授权的工具；关键步骤未留下任何追踪记录；应发生的交接（handoff）未发生；出错后缺乏恢复路径（recovery path）；模型甚至直接凭臆想回答，未查询应有的工具或知识库。

promptfoo 的 manual 提到，它具备 MCP 工具接口（MCP tool surface），允许 Agent 通过 MCP 工具直接触发评测，例如 list_evaluations、get_evaluation_details、run_evaluation、share_evaluation。更重要的是，工具的元数据包含 readOnlyHint、idempotentHint、longRunningHint 等提示，这能帮助 AI 宿主提前理解每个工具的行为边界。

这对于“让 AI 自我测试”至关重要，因为评测工具本身也需要边界：哪些操作是只读的，哪些会产生副作用，哪些可能长时间运行，都必须在调用前明确说明。

红队测试并非最后一步，而应融入测试集

promptfoo 还内置了红队（red-teaming）能力。Doramagic 的 manual 指出，redteam 层复用了核心评测引擎，但额外增加了一套迭代攻击 provider，包括主题检查（on-topic checking）、目标调用（target invocation）、基于视觉的判断（vision-based judging）、分数比较（score comparison），以及在目标模型追问时自动生成回应的解除阻塞（unblocking）机制。

这表明 promptfoo 的红队并非一次性的“攻击演示”，而是可以融入测试集，成为持续集成的一部分。

一种务实的做法是：首先收集真实的失败案例；然后将这些案例分类（如 prompt 注入、PII 泄露、越权工具调用、幻觉引用）；接着将每类失败转化为固定的测试用例；之后每次修改 prompt、更换模型、调整检索策略或工具权限时，都运行这套测试。如果通过率下降，就先不要发布，而不是等到上线后观察用户反馈。

这，正是“发布边界”的真正含义。

首次落地的建议方案

有经验的人都知道，不要一开始就试图覆盖所有风险。首次引入 promptfoo，可以先构建一个最小的闭环：

• 选择一个高频任务；
• 编写 10 到 20 个真实输入；
• 为每个输入定义最小的可验收标准；
• 同时运行当前模型和候选模型；
• 记录准确率、格式稳定性、延迟、成本和失败类型；
• 将最严重的失败案例转化为回归测试。

对于 RAG 项目，优先关注事实依据（factual grounding）和引用的稳定性。对于 Agent 项目，优先关注工具调用、权限边界、追踪记录和交接（handoff）。对于客服或内容生成项目，则优先关注格式一致性、禁答边界和敏感内容处理。

一个关键的判断标准

当你准备上线一个 LLM 功能时，不要只问：“模型这次回答得好不好？”

更应该问的是：哪些输入是它必须失败的？哪些工具是它绝对不能调用的？哪些回答必须引用来源？哪些指标一旦下降就必须回滚？本次改动与上一次相比，失败类型是否有变化？

promptfoo 的价值正在于此：它将这些灵魂拷问转化为配置、测试、报告和 CI 信号。

当然，这类工具并不能保证你的 AI 系统绝对可靠，但它能让“不可靠”暴露得更早、更易复现，也更容易让团队进行讨论。对于一个真正要将 AI 功能投入生产环境的团队来说，这比任何一次漂亮的演示都重要得多。