夜雨聆风回望AI发展路径，2023年尚属“原型验证”阶段，2024年则掀起了“百模大战”的浪潮。行至2026年，行业主线已清晰转向“工程化落地”。
这一转变的信号颇为明确：业界的关注重点，正从模型能力的边界探索，转向AI应用在实际生产环境中的稳定性、安全性与可控性。测试，恰恰是其中绕不开的关键环节。
过去沿用的“人工抽查式”验证，即通过若干提问来评估回答质量，在面对Agent与RAG等复杂架构时，已明显力不从心。
当前市面上的测试工具数量众多，品类繁杂，命名亦有相近之处，容易造成混淆。为避免陷入盲目的“工具竞赛”，我从单点评估、横向对比、安全红队与可观测性四大功能维度进行筛选，最终整理出以下7款工具，并尝试用它们构建一套覆盖完整质量保障链条的解决方案。
DeepEval适合刚接触LLM测试的团队作为起点。
这是一款开源Python项目，用法与Pytest高度相似：定义测试用例、设定阈值、执行断言，区别在于测试对象从普通函数变为了大模型输出。它内置50余种评估指标，覆盖RAG、Agent、多轮对话和多模态等场景，无需从零编写评估提示词。
针对RAG场景，提供
FaithfulnessMetric（检测回答是否忠实于检索内容）与AnswerRelevancyMetric（评估回答与问题的相关程度）。针对Agent场景，设有
ToolCorrectnessMetric（校验工具选择与参数准确性）及TaskCompletionMetric（判断任务最终完成情况）等六项专用指标。
若内置指标不足，还可通过G-Eval依据自然语言标准自定义评分；需要更确定性结果时，则可采用DAG决策树指标。它既支持端到端的整体链路评估，也支持对检索、生成、工具调用等环节的独立测试。与LangChain、CrewAI、Pydantic AI等框架无缝集成，CI流水线中一条命令即可完成回归测试。配套Confident AI云端看板可供团队协作，本地开发时亦可在终端查看链路追踪。不少团队的自动化回归测试，正是从这里开始搭建。
Promptfoo当面临模型选型困惑时——例如同一问题在不同模型（GPT、Claude、Gemini、Llama）上的表现差异——Promptfoo是进行横向对比的理想工具。
其核心用法为编写YAML配置文件，定义提示词模板、测试输入、预期输出或评分规则，随后通过一条promptfoo eval命令同时评测多个模型。结果以矩阵形式并排展示，便于快速定位特定提示词在不同模型上的表现差异。它兼容OpenAI、Anthropic、Google、Azure、Bedrock及Ollama等主流模型源，基本不受厂商锁定。
2026年3月，Promptfoo被OpenAI收购，但其MIT开源协议不变，CLI与库仍可正常使用。收购前已被超过25%的《财富》500强企业采用。除模型比较与提示词A/B测试外，其内置的红队探测功能也颇具价值——可在开发阶段自动检测提示词注入、越狱、数据泄露及工具滥用等风险。此外，它支持版本回归对比，便于追踪模型或提示词变更带来的行为偏移，避免问题延迟至上线后才暴露。
RAGAS若业务涉及知识库问答或文档检索等RAG应用，则需要专门评估“检索+生成”全链路的工具，RAGAS正是为此而生。
它将RAG流程拆解为检索器与生成器，并为各自设立对应指标。检索侧关注context_precision（返回片段中有用的比例）和context_recall（应召回内容的完整度）；生成侧评估faithfulness（回答是否基于检索内容，即幻觉检测）与answer_relevancy（回答与提问的匹配程度）。所有指标评分范围0至1，行业内常见的生产基准约为precision 0.7、recall与faithfulness 0.85，具体阈值仍需依业务容错率调整。
多数指标通过LLM-as-a-Judge自动打分，无需大量人工标注；faithfulness指标还可选用Vectara的HHEM小型模型进行NLI校验，以节省API调用成本。每当模型版本升级、向量库分块大小或top-k参数调整后，运行RAGAS即可量化检索与生成质量的变化，比人工抽检更为系统，也便于纳入版本迭代流程。
GiskardGiskard侧重于业务层面的红队与安全评估，是我常用的扫描工具。
它可检测提示词注入、有害内容、刻板偏见、虚假信息及数据泄露等风险，并将发现的问题自动转化为可复现的测试用例，纳入Golden Dataset，确保后续发布版本中持续回归验证。内置OWASP LLM Top 10（LLM01～LLM10）检测模块，报告可映射至NIST、MITRE ATLAS等合规框架，对需过审计的RAG应用尤其实用。
新版v3进一步强化了对Agent场景的支持：可用自然语言描述Agent的能力边界，系统自动生成多轮对抗性探测场景，而非仅发送单次攻击指令。它会根据Agent的回复动态调整策略，专门挖掘那些需多轮交互才能暴露的深层漏洞。Scenario API支持按步骤编排复杂交互流程，某一步失败即终止，便于快速定位问题。开源版负责本地扫描与用例生成；企业版Hub提供持续红队与协作看板。与garak相比，Giskard更擅长将漏洞沉淀为可长期维护的业务测试资产，而非仅提供一次性攻破报告。
garakgarak同样值得关注，由NVIDIA AI Red Team维护，同样开源。
其架构分为四个模块：Generator（连接目标模型）、Probe（发送攻击提示词）、Detector（判断响应是否违规）、Buff（对提示词进行编码变换等增强处理）。可将其理解为LLM领域的“nmap”：指定模型端点，选择一组探针扫描，即可获知模型在哪些攻击方式下防御失效。
它内置50余种Probe模块，涵盖提示词注入、DAN越狱、编码绕过、数据泄露、包名幻觉、恶意代码生成、毒性输出、XSS等攻击类型；28种Detector负责判定响应是否违规。支持OpenAI、HuggingFace、Bedrock、Ollama等20多种后端；通过pip install garak安装后，一行CLI命令即可运行，输出JSONL与HTML格式报告，可直接接入CI流水线。Probe与Detector均采用插件化设计，继承基类编写Python代码即可扩展自定义探针。
简言之，Giskard偏向业务层Agent扫描与用例沉淀，garak则侧重标准化、底层探测，覆盖面广且上手迅速。二者互补而非替代关系——我的通常做法是用garak进行广度扫描，再以Giskard开展深度检测与业务回归。
Midscene.js对于带有图形界面的产品，Midscene.js（字节跳动Web Infra开源）提供了视觉驱动的测试方案。
它摒弃了对DOM选择器的依赖，转而基于截图进行交互：多模态模型“观看”界面后，你只需用自然语言描述操作步骤，例如“在搜索框输入耳机”“点击搜索按钮”“确认出现登录成功提示”。对于Canvas、WebGL、无标签按钮及跨域iframe等传统选择器难以覆盖的元素，它反而能有效处理。Web、Android、iOS、鸿蒙及桌面端，只要支持截图，即可实现统一API的跨平台测试。
与Playwright的集成颇为顺畅：安装@midscene/web并扩展test fixture后，即可调用aiTap、aiInput、aiAssert、aiQuery等方法。它也可与传统Playwright选择器混用——稳定环节采用选择器保障速度，UI频繁变动的部分则交由AI处理。支持Qwen、豆包、GLM、Gemini、UI-TARS等多种视觉模型，开源模型还可本地部署。每次操作均生成可视化报告供回放检查，便于定位错误步骤。代价是每一步需额外等待数秒模型推理时间，全量回归会比纯Playwright慢；因此我通常用Midscene.js执行关键冒烟测试，大批量回归仍走传统选择器。
Langfuse在可观测性方面，Langfuse已成为圈内广泛采用的工具，其核心价值在于“出问题时可追溯”。
它记录LLM应用的每一步细节：所用提示词、调用的模型、检索返回的文档片段、工具调用的入参与返回值、延迟、Token消耗及成本等，全部按trace层级串联。用户多轮会话可按session分组查看，并支持按开发、预发、生产环境筛选。
基于OpenTelemetry标准，Langfuse为LangChain、OpenAI SDK、LiteLLM等80多种框架提供现成集成；Python中仅需添加@observe()装饰器即可开始采集trace数据，且数据异步上报，不影响业务响应。除观测功能外，它还集成了提示词版本管理、数据集、LLM-as-a-Judge评估与实验对比——从调试到上线后的质量监控均可在同一链路中完成。开源版可自部署，亦提供云服务。当遇到“用户反馈回答有误，究竟问题出在检索还是生成”的疑问时，沿trace逆向排查，比翻阅日志能显著节省定位时间。
选型建议以上7款工具不必全部掌握，建议依据业务场景按需切入：
纯对话类产品：可从DeepEval或Promptfoo入手。DeepEval更侧重指标度量与CI回归，Promptfoo更聚焦模型与提示词的横向对比。
涉及知识库与RAG：加入RAGAS，重点监控faithfulness与context recall两项指标。
有图形界面：关注Midscene.js，与传统UI自动化框架混合使用性价比更高。
对外暴露用户输入：安全测试至少应执行一轮——Giskard适合深度检测与业务用例沉淀，garak用于广度标准化扫描。
可观测性：建议尽早接入Langfuse，上手成本较低，后续问题排查能显著减少沟通成本。
行至2026年，AI测试工具链已趋于完备。相比收藏冗长的工具清单，更务实的做法是：首先厘清自身所面对的质量问题类型，明确所属业务场景的具体需求，再有针对性地选择合适的工具。最终的落地成效，还需在实际项目中逐步打磨与积累。