• 核心功能：把你重复用到的提示词整理成可复用的 Patterns（模式），通过命令行直接调用各种大模型完成任务（总结、提取、改写、分析等）。
• 许可证 / 语言：MIT / Go。
• 仓库数据：星标 4.4 万+ ｜ 最新版本 v1.4.507 ｜ 最近提交 2026-10-03（维护活跃）。
• 部署方式：官方提供一键安装脚本；Windows 也可用包管理器安装（官方给出的命令包括 winget install danielmiessler.Fabric），另有 Docker 方式。
• 使用场景：习惯命令行、希望把一套固定提问方式沉淀下来反复用的人；也适合做批量文本处理（例如把一批文章统一改写、统一提取要点）。
• 优势：几乎不需要写代码；模式可复用、可分享；支持多种模型供应商。
• 局限：需要自己配 API Key；它本身不做评测和安全测试；模式库的质量依赖社区贡献。
• 一句话：如果你只想“把好用的提示词存起来随时调用”，这是最容易上手的起点。

• 核心功能：用声明式配置（YAML）定义提示词与测试用例，自动跑评测、对比不同模型 / 不同提示词的效果，支持多种评判方式（字符串相似度、正则、LLM 当裁判等）；同时提供红队测试能力，用于扫描提示词与 AI 应用的安全漏洞。
• 许可证 / 语言：MIT / TypeScript（Node.js）。
• 仓库数据：星标 2.6 万+ ｜ 最新版本 0.123.1 ｜ 最近提交 2026-10-03（维护活跃）。
• 部署方式：命令行工具，官方给出的安装方式包括 npm install -g promptfoo、npx promptfoo@latest、brew、pip 等；典型流程是初始化示例 → 跑评测 → 打开本地报告页面查看结果。
• 使用场景：想验证“B 版提示词是不是真的比 A 版好”；想把提示词评测接入 CI，每次改完自动跑一遍，防止效果回退。
• 优势：配置驱动，基本不用写代码；默认本地运行，数据不外传；支持的模型供应商很多。
• 局限：评测本身要调用模型 API（有成本）；复杂场景仍可能需写少量代码；它聚焦“上线前”，没有生产环境的持续监控能力。
• 需要知道的变化：2026 年 3 月 9 日，promptfoo 官方宣布被 OpenAI 收购（OpenAI 官方公告与 promptfoo 官方博客均有说明），官方同时明确项目仍然开源、仍为 MIT 许可证。这里把它写出来不是要劝退，而是想说明一个选型常识：开源项目的治理归属会变，评估工具时要顺带看一眼它属于谁、路线图会不会偏向某一家的生态。

• 核心功能：LLM 应用的可观测性（追踪每次调用）、提示词管理（集中管理、版本控制、协作迭代、一键回滚）、评估（LLM 当裁判 / 人工标注 / 自定义评估），还有用于试提示词的 Playground。
• 许可证 / 语言：Open Core——核心部分是 MIT 许可，但 ee/ 目录下的内容由商业许可（Langfuse Enterprise License）管理。语言以 TypeScript 为主，提供 Python / JS-TS SDK。
• 仓库数据：星标 3.5 万+ ｜ 最新版本 v4.50.0 ｜ 最近提交 2026-10-02（维护活跃）。
• 部署方式：可以用官方云服务；也支持完全自托管，官方提供本地 Docker Compose（docker compose up）、单机、Kubernetes（Helm）以及云厂商 Terraform 等多种方案。
• 使用场景：团队协作开发 AI 应用；把提示词从代码里抽出来单独管理；上线后定位“哪一步调用出的问题”。
• 优势：能完全自托管、数据自己拿着；生态集成多（OpenTelemetry 体系、主流应用框架）；提示词版本管理这块体验成熟。
• 局限：自托管是多组件的，有运维成本；接入需要在代码里加 SDK / 埋点；企业功能在商业许可里，不是全都能白嫖。
• 一句话：从“个人调提示词”升级到“团队管提示词”时，这是最常见的落点。

• 核心功能：把提示词工程、评估（人工评估 + 自动评估）、可观测性（原生 OpenTelemetry 追踪）整合在一个平台里。
• 许可证 / 语言：同样是 Open Core——核心 MIT，ee/ 目录单独许可。前端 TypeScript，后端 Python。
• 仓库数据：星标 4.8k ｜ 最新版本 v0.121.7 ｜ 最近提交 2026-10-03（维护活跃）。
• 部署方式：有官方云服务；自托管用官方提供的 Docker Compose 方案。
• 使用场景：团队里既有工程师也有产品 / 领域专家时，让不写代码的人也能在界面上对比提示词、跑评估。
• 优势：UI 上手门槛低；追踪基于 OpenTelemetry，和现有可观测体系兼容；支持较多模型。
• 局限：自托管要起多个服务，部署难度中偏高；深度集成仍需写代码。
• 一句话：和 Langfuse 定位接近，选哪个主要看团队里“不写代码的人”占多少——那部分人越多，UI 友好度越重要。

• 核心功能：一个开源的大模型评估框架，写法类似 Pytest——你把评测写成测试用例，覆盖相关性、忠实度、幻觉、任务完成度、RAG 指标、多轮对话指标等等。
• 许可证 / 语言：Apache-2.0 / Python。
• 仓库数据：星标 1.9 万+ ｜ 最新版本 python-v4.2.4 ｜ 最近提交 2026-10-02（维护活跃）。
• 部署方式：pip install -U deepeval，然后按官方方式跑测试命令。
• 使用场景：给 RAG、Agent、客服机器人写回归测试；在 CI 里给质量把关；对比不同提示词 / 模型 / 架构的效果。
• 优势：和 Python 测试生态无缝衔接；指标覆盖广；部分指标可以本地跑，不依赖外部 API。
• 局限：必须写 Python；多数指标依赖“用模型当裁判”，需要 API Key。
• 一句话：如果你是开发者，且有“每次改完提示词都要自动验一遍”的需求，它是最顺手的。

• 核心功能：用编程方式把控制流（条件、循环、工具调用）和生成过程交织起来，并且可以强制模型的输出符合正则、上下文无关文法（CFG）或 JSON Schema。
• 许可证 / 语言：MIT / Python。
• 仓库数据：星标 2.2 万+ ｜ 最新版本 0.3.2 ｜ 最近提交 2026-05-21。注意：它的更新频率明显低于本表其他项目，选型前建议先看仓库近况。
• 部署方式：pip install guidance，配合你选用的后端模型一起用。
• 使用场景：输出的东西必须“能被程序正确解析”时——比如固定结构的 JSON、特定格式的文本、需要严格遵循语法的生成任务。
• 优势：约束能力强，能显著减少“就差一个括号 / 一个字段”的返工；也能降低无效 token 的消耗。
• 局限：必须写 Python；部分高级约束需要后端模型支持；适合工程场景，不适合纯聊天用户。
• 一句话：“让模型不可能输出错误格式”，比“在提示词里反复强调要输出 JSON”可靠得多。

• 核心功能：用写代码的方式构建 LLM 程序（把任务拆成可组合的模块），再由框架的优化算法自动寻找更好的提示词 / 示例组合。
• 许可证 / 语言：MIT / Python，由斯坦福团队维护。
• 仓库数据：星标 3.8 万+ ｜ 最新版本 3.4.0 ｜ 最近提交 2026-10-02（维护活跃）。
• 部署方式：pip install dspy，纯 Python 库。
• 使用场景：要做多阶段的复杂流水线（分类、检索问答、Agent 循环），并且希望效果可复现、可自动化调优，而不是靠手感改提示词。
• 优势：把“提示词调优”从手艺变成流程；有配套论文与持续演进的优化器；社区大。
• 局限：必须写 Python，学习曲线明显；要有一定的评测数据才能发挥价值；依赖模型 API。
• 一句话：它代表的是另一种思路——不是把提示词写好，而是把提示词交给程序去优化。对纯使用者来说门槛偏高，但值得知道这条路存在。

• 核心功能：基于 OpenTelemetry 的 AI 工程平台，用很少的代码给 LLM 应用接上可观测性（追踪、成本、延迟），同时提供评估、提示词版本管理、Playground 等能力。
• 许可证 / 语言：Apache-2.0 / Python SDK（另有 TypeScript、Go SDK；平台前端为 TypeScript）。
• 仓库数据：星标 2.8k ｜ 最新版本 openlit-2.1.0 ｜ 最近提交 2026-10-01（维护活跃）。
• 部署方式：SDK 侧 pip install openlit 并初始化；平台侧官方提供 Docker Compose 自托管方案。
• 使用场景：已经有一套 OpenTelemetry 可观测体系、希望把 AI 调用也纳进去的团队。
• 优势：不绑定厂商；接入成本低；自托管、数据本地。
• 局限：自托管平台多组件、部署难度中等；社区规模明显小于 Langfuse。
• 一句话：如果你公司已经有可观测体系，选它比选一个独立平台更省事。

LLM-as-judge：让一个（通常更强的）模型按照给定的评分标准，去给另一个模型的输出打分。它是目前规模化评估主观质量（是否有帮助、语气是否合适、是否忠于原文）最现实的手段。

但它有两个坑：一是裁判本身有偏见（例如偏好更长的回答、偏好和自己风格接近的回答）；二是裁判会漂移（换了模型版本，分数就不可比了）。所以专业做法是：固定裁判模型版本 + 抽样人工作为校准基准。

红队测试：用对抗性的输入，主动攻击自己的 AI 应用，在真实攻击者之前把漏洞找出来。常见手法包括提示词注入、越狱（jailbreak）、诱导泄露隐私数据、诱导调用不该调用的工具等。

它和评测的区别在于：评测回答的是“它做得好不好”，红队回答的是“它会不会被人搞坏”。对要上线的 Agent 类应用来说，这两件事都得做——尤其是接入了文件、数据库或支付能力的 Agent。