不要等 LLM 工作流上线后再补 eval：promptfoo 最该先定义的是失败边界

很多团队接入 LLM 应用时，会先把 prompt 调顺，再补一个“评测脚本”。这个顺序很容易出问题：等到线上开始失败时，大家才发现自己没有定义过什么叫通过、什么叫失败、哪些失败必须阻断发布。

这里的核心判断是：Doramagic 不是提示词库，也不是把 README 换一种说法。它要把一个开源项目整理成 AI Agent 能力资产：source map、host instructions、prompt preview、pitfall log、eval/smoke check、boundary card、human manual、test log 和 feedback path 都要能被宿主装载、复核和改进。

promptfoo 值得被认真看，不是因为它能把所有模型排个名，而是因为它把 LLM 工作流里最容易被忽略的一层抽出来了：在修改 prompt、切换模型、接入工具、开放 agent 权限之前，先把评测合同写清楚。

Doramagic 的 promptfoo manual 里，我会重点看四件事。

1. eval 不是一个分数，而是一组可复现的判断

promptfoo 的核心引擎会围绕配置、provider 调用、断言评分和结果聚合工作。它支持 YAML/JSON 配置，把 prompt、test cases、providers 和 assertions 放在同一个执行语境里。

这意味着一个 eval 不应该只问“模型回答得好不好”。更稳的写法是：

• 哪些输入必须稳定通过；
• 哪些输出必须被拒绝；
• 哪些 tool call 结构必须合法；
• 哪些结果需要 deterministic assertion，哪些才交给 LLM-as-judge；
• 切模型、切 provider、改 prompt 后，哪些 case 必须重新跑。

如果这些东西没有提前写进配置，后面的分数只是装饰。

2. agent 可以调用 eval，但不能无限制地调用

manual 里一个很关键的点是 promptfoo 暴露了 MCP tool surface。list_evaluations、get_evaluation_details、run_evaluation、share_evaluation 这些工具可以让 AI agent 程序化地驱动评测。

这很强，但也有边界。run_evaluation 不是“随便跑一下”的按钮。它有 configPath、testCaseIndices、promptFilter、providerFilter、maxConcurrency、timeoutMs、分页参数等限制。换句话说，agent 调用 eval 前，应该先说明：跑哪个配置、筛哪些 case、并发多少、超时多少、为什么这次要跑。

我会把这作为第一条边界：agent 可以建议 eval，但不能在没有范围说明的情况下消耗 API、触发大规模并发，或者把一次局部验证包装成“系统已经可靠”。

3. provider 多，不等于默认可迁移

promptfoo 支持的 provider surface 很大：OpenAI、Anthropic、Google Vertex、xAI、Bedrock、Cerebras、agent SDK、MCP tools、自定义网关等。这对团队很有价值，因为你可以用同一组 test cases 比较模型和运行方式。

但风险也在这里。不同 provider 的结构化输出、工具调用、超时、缓存、权限和计费方式都不一样。一个在 OpenAI 上通过的工具调用检查，不应该自动证明 Anthropic 或 Vertex 上也通过。

所以第一次用 promptfoo，我不会一上来做“大模型横评”。更合理的顺序是：先固定一个 provider 和一个真实业务场景，跑最小 smoke eval；然后再增加第二个 provider，观察断言是否仍然成立。

4. red teaming 不是营销词，而是发布前的负样本合同

promptfoo 的 redteam 层复用核心 evaluation engine，但加入攻击 provider、on-topic checking、target invocation、judging 和迭代反馈。manual 里提到的 preset 覆盖 prompt injection、harmful content、PII 等风险。

这里最容易误用的是：把 red teaming 当成“安全扫描一下”。真正有用的做法是把它变成发布前的负样本合同：哪些 prompt injection 必须挡住，哪些 PII 输出必须失败，哪些工具权限必须拒绝。

如果 redteam 只产生一份报告，但没有进入 CI、发布门禁或人工 review checklist，那它只是一次演示。

一个更稳的第一次运行路径

我会这样让 AI agent 使用 promptfoo：

1. 先读 Doramagic manual，确认项目用途、Node 版本要求和主要执行边界；
2. 在临时目录里准备一个最小 promptfooconfig，只覆盖一个业务场景；
3. 只接一个 provider，先跑 3 到 5 个高价值 test cases；
4. assertions 先用 deterministic checks，再谨慎加入 LLM rubric；
5. 让 agent 输出失败样本、通过样本、成本、耗时和下一步建议；
6. 在没有复核失败样本前，不把结果写成“可以上线”。

Doramagic promptfoo pack 的价值不在于替代官方文档，而在于给 AI coding host 一个可装载的操作合同：先看 manual，再看 pitfall，再跑 eval，最后才允许修改 prompt 或推荐发布。

这个 feedback loop 也很重要：如果第一次运行暴露了新失败样本，它不应该只停在一篇文章里，而应该回流到 pitfall log、eval case、boundary card 或 human manual。这样下一次 agent 装载这个能力资产时，拿到的是更新后的操作经验，而不是旧的宣传文案。

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

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

GitHub pack：https://github.com/tangweigang-jpg/doramagic-promptfoo-pack

上游项目：https://github.com/promptfoo/promptfoo

说明：这是 Doramagic 整理的非官方项目能力资产，不代表上游官方发布。