Promptfoo 评测：大模型评估、红队测试与选型指南

价格与文档核实于 2026 年 10 月 13 日。下文示例使用人工编写的固定样例回答，在本地实际运行。托管功能的评价依据公开文档，未登录产品进行试用。 Promptfoo 当前方案。

Promptfoo 是什么？

Promptfoo 是一个开源命令行工具和库：向 AI 模型或应用发送测试输入，检查响应，再将结果汇总以便比较。**评估（eval）**用于反复验证回答是否符合要求；**红队测试（red teaming）**则主动尝试诱使应用违反这些要求。你先定义提示词、测试目标、样例和评分规则，再通过本地结果视图检查表现，或将结果接入构建流程。它的价值在于，让“这次改动有没有把客服机器人改坏”成为一个可以复现的测试问题。入门文档同时介绍了质量评估和安全测试。

哪些团队适合用，哪些团队可以先看别的工具？

Promptfoo 适合能够维护测试配置，并将测试接入客户实际使用的应用的开发者。需要检索帮助文章、读取订单记录或调用退款工具的客服机器人，就是典型场景：回答是否有用、操作是否安全，需要分别测试。

如果你希望测试能随代码一起接受审查、比较不同服务商的表现，并针对应用本身开展对抗检查，可以选择它。但什么才算正确回答，仍然需要有人来定义。无论使用哪种工具，这都是让评估有意义的必要投入。

来源：Promptfoo、Braintrust、LangSmith。这些方案的计费方式不同，不能视为内容相同的套餐。

如果眼下最迫切的需求是团队共同分析生产环境表现，而非定义上线前的测试，首选采购项可以先不考虑 Promptfoo。 如果工作重点是共同审阅实验、维护共享数据集，可以把 Braintrust 列入候选。如果你需要顺着 Agent 调用模型和工具的过程，找出不良结果的成因，可以优先考察 LangSmith。下文会展开两者的价格和具体取舍。

选择时主要看四点：测试目标与生产环境有多接近、评分过程是否便于检查、哪些安全测试符合数据限制，以及整套流程的成本。即便集成列表再长，也弥补不了测错对象的问题。更广泛的候选工具，可参阅我们的 AI 基准测试审计工具对比。

OpenAI 收购带来了哪些变化？

Promptfoo 当前的官方代码仓库注明，它已是 OpenAI 的一部分，并继续采用 MIT 许可证。带有发布日期的公司公告说明了未来方向，但没有给出交易交割日期或收购价格。参见 Promptfoo 代码仓库。

2026 年 3 月 9 日，Promptfoo 宣布已同意由 OpenAI 收购，交易交割仍需满足惯常条件。公告称，此举将让团队能够在模型层和基础设施层改进、整合核心技术。同一份公告还承诺继续提供服务与支持、维护开源工具套件，并支持多种模型和服务商。参见 Promptfoo 公告。

这些是公司公开作出的承诺。目前的 provider 文档仍然包含竞争厂商和本地运行时。关于整合的表述应理解为发展方向，不能据此认定某项企业功能已经在 CLI 中可用。

做采购决策时，要分清所有权变化与技术要求。上述声明并不能支持“Promptfoo 只能评估 OpenAI 模型”的判断。同样，也不应因为某项拟议中的企业级整合，就为尚未在自身工作流中验证的能力付费。评估应以当前软件包、部署选项和合同为准。

如何配置测试，能接入哪些模型和应用？

Promptfoo 用测试配置记录团队究竟想测什么。YAML 格式包含 prompts、providers 和 tests；每个测试提供 vars，并可选配 assert 规则。provider 是调用模型或应用的适配器。{{question}} 这样的变量用于把测试输入插入提示词。参见配置指南。

评估客服机器人时，应让现有提示词和拟修改的版本面对同一组问题与评分规则。否则，分数提高可能只是因为第二轮问题更简单。每次只调整一项：提示词措辞、检索行为、模型，或工具权限。

本地结果矩阵便于逐项查看分数发生变化的回答，再据此定位具体的回归问题：比如，缩短提示词后，机器人不再追问缺失的订单编号；换用更便宜的模型后，它把不确定的送达日期当成了事实。只看平均分，很容易漏掉这些问题。

支持哪些 provider？

Promptfoo 的 provider 索引涵盖多种接入方式，代表性选项包括：

• 模型 API： OpenAI、Anthropic、Google AI Studio、Google Vertex AI、Azure OpenAI、Amazon Web Services Bedrock、Cohere、Mistral AI、DeepSeek、Alibaba Cloud Qwen、AI21 Labs、Meta Model API、MiniMax、Moonshot Kimi、xAI 和 IBM WatsonX。
• 托管与推理服务： Amazon SageMaker、Groq、Cerebras、Fireworks AI、Together AI、Hugging Face、OpenRouter、Replicate、Perplexity AI、NVIDIA NIM、Databricks、Snowflake Cortex 和 Cloudflare AI。
• 本地运行时： Ollama、llama.cpp、llamafile、LocalAI、Docker Model Runner、vLLM 和 Transformers.js。
• 应用适配器： HTTP、WebSocket、Python、JavaScript、Shell 命令、Model Context Protocol 服务器，以及文档列出的 Agent SDK 集成。

这只是代表性列表；链接中的索引还列出了其他网关和专用 provider。身份验证方式和可用选项应以各适配器文档为准。工具支持某个 provider，并不意味着你的账号就能访问该服务的全部模型。

把测试接到完整的客服应用上

Promptfoo 的 HTTP 适配器可以构造请求，并通过 transformResponse 提取回答，例如使用 json.output。也可以用自定义 Python provider调用已有应用代码。如果客服机器人的行为依赖检索、会话状态、授权或工具执行，这些接入方式就很关键。参见 HTTP provider 文档。

让真实场景中的客户问题经过这一应用边界，再对响应评分。测试中应带上应用需要使用的受限用户身份和固定样例记录。如果绕过检索层，只测一个裸模型，就很难判断某位客户能否拿到其他客户的订单。

因此，接好适配器是一项工程工作。要保留决定权限的上下文、解析客户实际看到的字段，并单独检查应用执行过的操作。如果此前已经发生了未授权退款，最终回答再礼貌地拒绝，也无法撤销这笔操作。

Promptfoo 大模型评测实战：检查客服机器人的回答

在为反复调用模型付费之前，可以先用 Promptfoo 评估已有回答。它的 echo provider 会原样返回传入的文本，让断言直接检查回答。Echo 本身不会请求模型；如果加入 LLM 评审模型，情况就会不同。参见 Echo provider 文档。

下面使用的是人工编写的固定样例回答，不是客户日志，也不声称是模型生成的输出。假设客服政策要求将退款用户引导至 Settings、Billing、Request refund。当无法获取订单状态时，机器人应转交客服处理，不能声称订单已经发货。

将以下内容保存为 promptfooconfig.yaml：

description: Support bot answer checks
prompts:
  - '{{answer}}'
providers:
  - echo
tests:
  - description: Approved refund instructions
    vars:
      answer: 'Open Settings, choose Billing, and select Request refund.'
    assert:
      - type: icontains-all
        value: [Settings, Billing, Request refund]
  - description: Escalate an unknown order status
    vars:
      answer: 'I cannot verify your order status. Please contact support.'
    assert:
      - type: icontains
        value: contact support
      - type: not-icontains
        value: has shipped
  - description: Reject an invented order status
    vars:
      answer: 'Your order has shipped. Please contact support if needed.'
    assert:
      - type: icontains
        value: contact support
      - type: not-icontains
        value: has shipped

这里使用的断言类型均有文档说明：icontains 检查文本是否包含指定内容，不区分大小写；icontains-all 要求包含给定的每个短语；not- 前缀则对检查取反。参见断言参考。

满足文档要求的 Node.js 版本 >=22.22.0 后，运行：

npx promptfoo@latest eval -c promptfooconfig.yaml -o support-results.json
npx promptfoo@latest view

入门指南说明了评估和结果查看器命令；红队快速入门列出了 Node 版本要求。等评估命令执行结束，再单独运行查看器命令。

本次评测在本地运行后，得到了预期结果：退款指引回答通过，说明状态不明的回答通过，虚构发货状态的回答失败。最后一条回答虽然包含转交客服的短语，但仍包含禁止出现的声明，不能通过。这只能验证示例的配置与断言是否正常工作，不能说明线上模型的可靠性。

这个区别很实用。在信任评分器之前，先给它一个必须通过的回答，再给一个必须失败的回答。如果两者都通过，应先修正测试，再比较模型。不要等到接入目标模型，才开始调试测试框架。

从固定短语检查，走向客服质量评估

Promptfoo 的模型评分断言可以评估字符串匹配覆盖不到的标准。llm-rubric 按书面评分标准打分，factuality 则将回答与参考陈述比较。你可以明确指定用于评分的 provider。参见模型评分断言。

对这个客服机器人，合理的评分标准应要求：只使用已提供的订单事实，说明缺失信息，并给出政策允许的下一步操作。要把相关政策和参考事实提供给评审模型，否则就是让它猜测发货声明是否属实。

对必须精确满足的要求，保留确定性检查；对允许不同表述的内容，再引入判断。上面的示例会漏掉“你的包裹正在路上”这种说法，也可能误拒一条原本正确、只是引用违规短语来纠正它的句子。这些是所选检查方法的局限，不能据此证明机器人安全或不安全。

下一步，可以用实际采集的回答替换固定样例，或接入应用 provider。保留已知错误的样例，用它持续检验评分逻辑。修改提示词时，不应在不知不觉中改变成功的定义。

Promptfoo 红队测试：验证应用的权限与行为边界

Promptfoo 的红队流程会生成对抗输入，将其发送给目标，并把失败结果呈现出来供人工复核。**插件（plugins）**决定要探测哪些行为；**策略（strategies）**决定如何投放攻击。文档列出的测试目标包括 HTTP 端点、浏览器交互，以及直接连接的模型或自定义代码。参见红队快速入门。

对客服机器人，普通评估关注的是：符合条件的客户能否得到正确的退款指引。红队测试追问的则是：客户能否诱导机器人泄露他人记录、绕过政策，或滥用已连接的工具。Promptfoo 文档涵盖的应用层威胁包括间接提示词注入、数据泄露、未授权访问和工具滥用。参见红队测试指南。

对于有写入权限的 Agent，应使用受控测试环境，既核对对话记录，也检查操作后的实际记录。只测回答，可能漏掉未经授权的工具操作。反过来，即使拒绝回答看起来不如评审模型预期的那样有帮助，也可能恰恰是正确行为。

修复一个发现的问题后，应将其转成回归用例。探索测试负责寻找新问题，重放测试负责检查已知问题是否重现，两者要分开管理。关于如何将这些测试纳入发布流程，可参阅如何开展 AI Agent 安全评估。

CI 与报告：让测试失败真正阻止发布

Promptfoo 可以接入持续集成，也就是代码变更后自动运行的检查流程。其文档涵盖普通评估、红队扫描、已保存探测用例的重放，以及 JSON、HTML 和 JUnit 等格式的结果导出。参见 CI/CD 指南。

开发者修改系统提示词或检索行为时，使用稳定的回归测试集；需要发现新问题时，再单独运行更广泛的攻击生成。如果每次比较都混入全新攻击，分数变化就难以归因：究竟是应用退步了，还是测试变难了？

按 CLI 文档的默认设置，测试失败或通过率未达阈值时，退出码为 100；其他错误使用 1。默认通过率阈值是 100%，这些设置均可配置。CI 任务必须保留失败状态，不能因为成功写出了报告，就把测试判为成功。参见 CLI 参考。

制定发布规则时，应将严重错误与一般质量问题分开。未授权访问不能被其他有帮助的回答拉高平均分后掩盖。每个阻止发布的用例都应有负责人，保留证据，并在修改后重跑同一用例。

报告的价值，在于让其他人能够检查并质疑结论。除结果外，还要保留应用版本、配置、测试数据和评审模型选择。缺少这些上下文，下一次模型或提示词发生变化时，一份全绿的报告也可能再无法复现。

Promptfoo 价格：Community、Enterprise 与 On-Premise

Promptfoo 公开列出了三种方案。两个付费方案都需要询价，当前页面均未公布美元起价。以下信息于 2026 年 10 月 13 日对照 Promptfoo 价格页核实。

探测额度到底怎么计算？

在红队评估中，每向目标发送一次请求，Promptfoo 就计为一次探测。内部生成和评分调用不计入探测次数。推理文档说明，即便自行管理推理，包括使用本地模型，仍然会计算限额。参见推理与用量限制。

不能把探测额度直接等同于独立安全场景的数量。反复向目标发请求的策略，与单轮用例消耗额度的方式不同。覆盖范围取决于应用、选择的攻击，以及实际运行中发出的请求。接通目标后，应根据观察到的请求量估算预算。

每月总成本与单条回答的评估成本

Promptfoo 许可证免费，但仍有几项成本需要计算：目标模型推理、攻击生成、模型评分、基础设施，以及失败结果的人工复核。月度总额取决于其中哪些服务由你自行运行，哪些需要采购。测试运行器免费，不等于模型服务商的账单也免费。

上文示例中，评估每条固定样例回答的模型推理成本为 $0，因为 Echo 不调用模型，检查也是确定性的。这个结果不适用于使用 LLM 评分的测试集。一旦每条回答都要交给评审模型阅读，其用量就必须计入评估预算。参见 Echo 的文档说明。

作为对照，Braintrust 公布的 Starter 超额评分费用是每 1,000 次评分 $2.50，折合每次额外评分 $0.0025。这只是评分费用，并不是一条合格客服回答的全部成本；模型调用和数据处理另行计量。参见 Braintrust 价格。

更有意义的计算口径，是每条符合客服政策、被验收通过的回答。用可归属的评估支出除以通过验收的回答数，同时单独呈现失败调查成本。如果一次运行更便宜，却放过了虚构订单事实的回答，那优化的目标就错了。

哪些限制会影响选型？

Promptfoo 最值得关注的边界是：扫描器在本地运行，不代表整套安全测试流程都在本地完成。数据处理文档分别说明了目标调用、生成和评分的数据流。托管评分可能接收到测试提示词、目标响应和评分标准。

部分重要测试需要托管推理。 同一份文档列出了仅支持远程运行的插件，包括 bola、bfla 和 indirect-prompt-injection，分别涉及资源访问、功能权限，以及通过外部内容传入的指令。禁用远程生成会缩小可用测试的覆盖范围；禁用标志本身并不能保证网络隔离。如果客服数据集受访问或传输限制，在承诺完全本地化的测试方案之前，必须先厘清这一点。

自行管理推理也不会取消探测限额。 这是与数据流向不同的另一项限制。推理文档明确指出，使用自有推理配置时仍然计算用量。不能因为工具“开源”，就默认托管攻击服务可以无限使用。

评分器可能奖励错误行为。 上文示例能抓住特定的发货短语，却不能识别所有缺乏依据的配送声明。LLM 评审模型让判断更灵活，同时也引入了另一个模型的理解与解释。应使用客服人员一致认可的合格与不合格示例，校准评分标准。

回答测试可能漏掉操作层面的失败。 如果目标适配器只返回最终文本，测试集就无法仅凭文本确认 Agent 是否使用了正确账号、修改了正确记录。只要成功标准涉及工具操作，就应补充操作证据或应用状态验证。

日常维护仍然需要团队承担。 必须有人维护用例、调查发现的问题，并决定哪些失败应阻止上线。托管仪表盘可以让协作更方便，但测试应落实的退款政策和客户访问规则，仍需由你来定义。

Promptfoo 替代方案怎么选？

Braintrust：适合以团队协作评估为主的工作

Braintrust 将调用链追踪、实验、数据集和评分整合到共享平台。如果日常工作重点是与同事一起审阅变更，并把观察到的行为转成评估数据，可以考虑它。对于这类工作流，它覆盖的能力更适合优先列入候选，而以配置为主的流程未必是第一选择。

Starter 为 $0/月，包含 1 GB 数据处理量、10,000 次评分和 14 天保留期。Pro 为 $249/月，包含 5 GB、50,000 次评分和 30 天保留期；Enterprise 为定制报价。Starter 超额数据收费为 $4/GB，超额评分为 $2.50/1,000 次。Pro 对应价格为 $3/GB 和 $1.50/1,000 次，延长保留期另行收费。参见 Braintrust 当前方案。

它的限制在于计费维度较多：评分、数据处理量、保留期和模型用量都需要结合工作负载估算。如果眼前需要的是一个规模不大、便于审查的测试集，以及针对应用的对抗测试，应优先考虑 Promptfoo。共享平台不能替你定义预期行为，也不应成为回避这项工作的采购理由。

LangSmith：适合追查 Agent 的执行过程

LangSmith 提供调用链追踪、数据集采集、标注，以及在线和离线评估。如果你的主要工作是追查一条回答背后的完整过程，可以考虑它。客服 Agent 可能取错记录，却仍生成一句看似合理的回答；执行轨迹正是调查这类问题的重要证据。

Developer 为 $0/席位/月，仅限一个席位，每月包含 5,000 条基础调用轨迹，超出后按用量收费。Plus 为 $39/席位/月，每月包含 10,000 条基础调用轨迹，并可增加席位。公开额度是总量，不会随席位数量成倍增加。Enterprise 为定制报价。参见 LangSmith 价格。

对于不断扩大的评审团队，限制在于增加席位会增加费用，而用量仍单独计量。如果当前目标是建立自动化发布检查，并明确覆盖对抗测试，优先考虑 Promptfoo 更合适。LangSmith 的一条调用轨迹、Braintrust 的一次评分和 Promptfoo 的一次探测，分别对应不同事件；把这些额度当成同等数量的测试运行来比较，会导致预算判断失真。

结论：能维护好测试，Promptfoo 才能发挥价值

如果客服机器人或 Agent 项目需要明确的质量检查和对抗测试，并且希望开发者能够审查、重跑这些测试，Promptfoo 值得纳入工具集。只要数据流向、测试覆盖和运维方式适合，就可以从 Community 开始。当协作、管控或部署要求形成具体需求时，再采购托管能力。

瓶颈变了，选择也会随之变化。 如果还说不清什么是安全、正确的回答，应先完善政策和示例。如果标准已经清楚，却无法复现失败，Promptfoo 是合理的下一步。如果已经能够复现失败，困难在于协同分析或执行过程追踪，就应同时评估 Braintrust 或 LangSmith。

接下来，保存具有代表性的客服问题，定义可接受的回答和禁止的操作，并确认刻意构造的错误回答确实无法通过。然后接入真实应用，检查数据边界，再补充那些一旦失败就必须停止发布的安全用例。应先公布发布规则，再看测试分数。

采用前的常见问题

订阅邮件通讯，获取 AI 系统开发与运行的实战记录。