评测平台是平台层,项目规则是适配层

**Langfuse 这类观测/实验平台能承担 prompt 评测,但永远不知道你的业务规则;业务规则必须由项目自己以适配层的形式喂进去。** 因此结论是:不要自己造 Prompt Lab / Skill Lab / Tool Lab,改为「平台承担 Lab 功能,项目只写适配代码」。

分工

Langfuse  = 平台层:prompt 版本、数据集、实验、trace、评分、历史对比
项目适配层 = fixtures(假数据/输入/上下文)
           + cases(项目用例定义)
           + runners(调用本项目 prompt/skill/tool)
           + evaluators(项目自定义 scorer)

平台能回答「用了哪个 prompt 版本、哪个 case 失败、原始输出是什么、分数比上次差没有、trace 断在哪」。平台不能回答「哪些 fieldPath 合法、结构化 JSON 怎样才算保留列表、这个 skill 应返回哪些风险项、能不能编造指标、确认卡需要哪些字段」——这些项目知识必须由项目提供。

Langfuse 与 Promptfoo 的区别

两者默认重心不同,Langfuse 确实能在一部分场景替代 Promptfoo:

Langfuse  = 团队级调试/观测/实验平台(有 hosted state)
Promptfoo = 本地优先的 prompt/agent 测试运行器(配置 + assertions,不依赖平台账号)

Promptfoo 的优势是本地启动快、配置简单、assertions 直接(JSON 校验、包含/不包含、自定义 JS/Python)、适合在 CI 当测试跑。

常见误判:上传固定输出 ≠ 链路回归

把固定的 modelOutput case 上传到平台跑 experiment,只验证了解析与契约(输出是否合法 JSON、tool call 契约、字段路径、禁用 token)。它不覆盖:不同版本 prompt 对比、真实模型输出、单个业务 skill、工具安全测试、端到端链路回归。评估覆盖面要按「测的是解析还是链路」区分,别把前者当成后者。

相关

  • 分层要落到运行时才有效 —— 本条是该骨架的一处实例:适配层写了,还要真的跑真链路才算落地
  • Agent harness 要隔离复现可收尾 —— 项目侧的调试房间与平台侧评测的分工
  • 多源更新按维度取真源 —— 同为「平台层 vs 项目层」的真源划分