promptfoo 评测：用声明式配置把 LLM 评估和红队测试搬进 CI
测试您的提示、代理和 RAG。 AI 红队/渗透测试/漏洞扫描。比较 GPT、Claude、Gemini、DeepSeek 等的性能。具有命令行和 CI/CD 集成的简单声明性配置。由 OpenAI 和 Anthropic 使用。
秒懂
- 它是什么？
- promptfoo 是一个面向 LLM 应用评估与红队测试的开源 CLI 与库，支持多模型对比、漏洞扫描和 CI/CD 集成。本文基于其 README 与文档信息，分析它的工作机制、上手方式、局限与适用场景。
- 适合谁用？
- promptfoo 适合需要把 LLM 评估和红队测试纳入日常开发流程的团队，尤其是已经使用 Node.js 24 或愿意升级的工程环境。它用声明式 YAML 配置和命令行接口降低了评估门槛，但本地运行意味着每次评估都要消耗 API 调用，且对非 Node 技术栈的团队需要额外引入运行时。
- 能商用吗？
- 可以。MIT 是宽松许可证：你可以使用、修改并销售基于它的软件，只需保留版权和许可证声明。
- 还在维护吗？
- 在维护。仓库在最近一天内有新的提交。
- 用什么语言写的？
- 主要是 TypeScript（依据 GitHub 的语言统计）。
以上回答依据项目的 GitHub 数据（最近同步于 2026年9月15日）和我们的分析，不构成法律意见。
开源项目深度解析
它解决什么问题：把 LLM 评估从拍脑袋变成可重复的检查
开发 LLM 应用时，最常见的做法是手动试几个提示词，凭感觉选一个看起来不错的。promptfoo 想改变这种状态。它提供一个 CLI 和库，让你用声明式配置定义评估用例，然后自动运行并对比不同模型或提示词的表现。目标用户是那些需要持续验证提示词质量、模型选择或安全性的工程师。它不只是做一次性的对比，而是把评估变成像单元测试一样可以反复执行、可以放进 CI 的流程。README 里明确说，它的用途包括测试提示词、智能体和 RAG，以及红队测试和漏洞扫描。这意味着它同时覆盖了功能评估和安全评估两个方向，但两者共享同一套配置和运行机制。
工作机制：声明式配置、本地运行、多提供商适配
promptfoo 的核心是一个命令行工具，它读取配置文件，向指定的 LLM 提供商发送请求，收集响应，然后根据预设的评判标准给出结果。配置是声明式的，意味着你描述要测什么，而不是写代码去编排测试流程。它支持 OpenAI、Claude、Gemini、DeepSeek 等多家提供商，也支持 Ollama 这类本地模型。运行过程完全在本地执行，README 强调“你的提示词永远不会离开你的机器”，这指的是评估逻辑和配置本身不经过第三方服务器，但实际请求还是会发给对应的 LLM API。红队测试是另一个独立功能，它自动生成攻击性提示词来探测漏洞，并生成安全漏洞报告。代码扫描则是针对代码库的，用于在 pull request 中检查 LLM 相关的安全和合规问题。
快速上手：三条命令跑通第一个评估
安装 promptfoo 需要 Node.js 22.22.0 或更高版本，README 推荐使用 Node.js 24 LTS。全局安装后，用 init 命令生成一个示例项目，然后运行 eval 和 view 就能看到结果。具体命令是：npm install -g promptfoo，然后 promptfoo init --example getting-started，进入目录后执行 promptfoo eval 和 promptfoo view。view 命令会启动一个本地界面来展示结果。除了 npm，还支持 brew install promptfoo 和 pip install promptfoo，也可以用 npx promptfoo@latest 免安装运行。大多数提供商需要 API key，通过环境变量设置，比如 export OPENAI_API_KEY=sk-abc123。这个上手流程很直接，但注意它依赖 Node.js 版本，如果环境里有多个 Node 版本，需要先确认当前版本。
CI/CD 集成：把评估变成质量门禁
promptfoo 的一个关键卖点是能集成到 CI/CD 流程中。README 提到可以“自动化检查”和“审查 pull request”。这意味着你可以在每次代码提交时自动运行评估，如果结果不达标就让构建失败。这种集成方式对团队有实际价值，因为它把提示词回归测试变成了常规工程实践。代码扫描功能更进一步，它针对 LLM 相关的安全和合规问题，能在 pull request 阶段就发现风险。不过，CI 集成的具体配置方式在 README 里没有展开，需要查阅文档。从项目结构看，它提供了 GitHub Action，但具体用法需要看 docs/code-scanning 和 docs/integrations/ci-cd。如果你已经用 GitHub Actions，这可能是一个低成本的接入点。
局限与失败模式：本地运行的成本和 Node.js 依赖
promptfoo 的本地运行特性是一把双刃剑。好处是隐私和可控，坏处是每次评估都要消耗真实的 API 调用，产生费用和延迟。如果你有大量测试用例，评估时间会很长，而且结果受 API 可用性影响。另一个限制是它对 Node.js 版本的严格要求，README 明确要求 Node.js >=22.22.0，推荐 24 LTS。如果你的项目还在用 Node 18 或更早版本，需要先升级，这可能会引入兼容性问题。此外，promptfoo 的配置是声明式的，但这意味着调试复杂场景时，你可能需要学习它的配置语法和评判逻辑，而不是直接写代码。最后，红队测试和代码扫描是相对较新的功能，README 没有提供详细的失败案例或边界说明，实际效果需要自己验证。
替代方案：与自建脚本和托管评估平台的对比
promptfoo 的替代方案可以分两类。一类是自己写脚本调用 LLM API，然后手动比较输出。这种方法灵活，但需要自己处理并发、缓存、结果汇总和报告生成，维护成本高。promptfoo 的价值在于把这些重复工作封装成声明式配置和标准命令。另一类是托管的评估平台，比如某些商业服务提供图形界面和托管运行。这类平台省去本地环境配置，但你的提示词和测试数据会发送到第三方服务器，而且通常需要按量付费。promptfoo 的本地运行和开源许可证是它的差异化优势。还有一个间接替代是直接使用各提供商自己的评估工具，比如 OpenAI 的 evals，但那些通常只针对单一提供商，而 promptfoo 支持多提供商对比。
维护与升级成本：活跃开发与许可证考量
从仓库信息看，promptfoo 的开发很活跃，最近一次提交是 2026 年 8 月，版本号到了 0.122.2，说明迭代频繁。频繁的版本更新意味着你需要定期升级来获得新功能和修复，但也可能带来配置兼容性变化。项目采用 MIT 许可证，允许自由使用、修改和分发，这对商业项目友好。不过，README 中有一个重要声明：promptfoo 现在是 OpenAI 的一部分，但项目保持开源和 MIT 许可证。这意味着项目的长期方向可能受 OpenAI 影响，虽然目前声明不变，但你应该关注后续的治理变化。升级成本方面，由于是 CLI 工具，升级通常只是重新安装 npm 包，但如果你在 CI 中固定了版本，需要手动更新。
编辑结论
promptfoo 适合需要把 LLM 评估和红队测试纳入日常开发流程的团队，尤其是已经使用 Node.js 24 或愿意升级的工程环境。它用声明式 YAML 配置和命令行接口降低了评估门槛，但本地运行意味着每次评估都要消耗 API 调用，且对非 Node 技术栈的团队需要额外引入运行时。不适合那些只想要托管式评估平台、不想自己管理配置和报告生成流程的团队。在采用前，先确认你的 Node.js 版本是否满足要求，并检查目标提供商（如 OpenAI、Anthropic、Ollama）的 API key 和环境变量设置是否就绪。对于已有 CI 管线的团队，建议从 promptfoo init --example getting-started 开始，先跑通一个最小示例，再逐步加入红队测试和代码扫描。promptfoo 的 MIT 许可证允许自由使用和修改，但需要注意它已被 OpenAI 收购，尽管 README 声明保持开源，后续方向仍需观察。
社区笔记