Giskard v3：为多轮 LLM Agent 测试重写的评估与红队库

v3 重写解决了什么问题

Giskard 这个开源项目在 2026 年 8 月发布了 v3.0.0，是一次彻底的代码重写。旧版 v2 主要面向表格 ML 模型和单轮 RAG 评估，而 v3 的目标转向了动态、多轮交互的 AI Agent。仓库描述里写着它是「Evals, Red Teaming and Test Generation for Agentic Systems」，关键词是 modular、lightweight、dynamic 和 async-first。v3 的 README 明确说它「drops heavy dependencies for better efficiency」，意思是去掉了沉重依赖以换取更高效率。这对谁有意义？如果你在开发一个会连续对话、调用工具、分步决策的 Agent，传统的单元测试无法覆盖它的非确定性输出。Giskard v3 提供了一套 Scenario 和 Check 的抽象，让你把一次完整对话当作一个测试场景，而不是只测单个 prompt 的返回。另外，v2 的扫描功能被拆分并重写为 giskard-scan 包，新增了针对 Agent 的漏洞扫描，比如提示注入和越狱检测。这个重写不是小修小补，而是把原来的单体库拆成了 giskard-checks、giskard-scan、giskard-core、giskard-llm、giskard-agents 五个独立包，每个包只带自己需要的依赖。这种拆分对只想做评估、不想碰扫描的用户是好事，因为安装体积更小。

Scenario、Check 与 Suite：评估的三种抽象

Giskard Checks 文档定义了四个核心概念：Target 是你的被测系统，可以是任何同步或异步的可调用对象，输入输出都是字符串，可选带 trace；Scenario 是一次评估，包含交互和检查；Check 是对 trace 的断言或 LLM judge；Suite 则是多个 Scenario 的集合。这个设计把「测试什么」和「怎么判断」分开了。Scenario 用 .interact() 方法传入用户输入和被测函数，然后链式调用 .check() 添加检查。例如 README 里的快速开始，先定义 get_answer 函数返回巴黎，然后创建一个测试法国首都的场景，用 Groundedness 检查答案是否基于给定上下文。Groundedness 是一个 LLM judge，默认模型是 openai/gpt-4o-mini，这意味着它需要调用外部模型来评判。这种抽象的好处是，被测系统不需要暴露内部结构，黑盒即可。但要注意，Scenario.run() 是异步方法，你必须用 asyncio.run() 来执行。如果你的 Agent 本身不是异步的，Giskard 也接受同步 callable，但整个评估流程是异步驱动的。多轮对话的支持体现在 Scenario 可以包含多次 .interact() 调用，每次交互都会记录在 trace 中，后续的 Check 可以检查整个 trace 而不仅是最后一个输出。

LLM-as-judge 的机制与依赖

Giskard 内置了多种检查，包括字符串匹配、比较、正则、语义相似度，以及 LLM judge 类检查如 Groundedness、Conformity 和 LLMJudge。其中 Groundedness 用于验证答案是否基于给定上下文，适合 RAG 系统的落地性测试。LLM judge 的工作原理是：把被测系统的输出和评判标准一起发送给一个 LLM，让模型判断输出是否合格。这个机制在 README 的快速开始里已经体现，Groundedness 需要 context 参数，然后由默认的 openai/gpt-4o-mini 来评判。这意味着使用这类检查时，你必须安装 provider extra，比如 pip install "giskard[openai]"，并设置对应的 API key。giskard-llm 包负责 provider 无关的 LLM 路由，所以你理论上可以换用 Anthropic 或其他 provider，但默认是 OpenAI。这里有个明显的权衡：评估的准确性依赖于 judge 模型的能力，而 judge 模型本身是外部服务，会引入延迟和费用。另外，遥测功能默认开启，虽然 README 说不会发送 prompt 或输出，但会发送聚合分析数据。你可以用 export DO_NOT_TRACK=1 来关闭，但必须在 import 之前设置，否则仍会创建 ~/.giskard/id 文件。对数据敏感的企业，这是个需要提前处理的点。

giskard-scan：Agent 漏洞扫描与 RAG 质量评估

giskard-scan 是 v3 新增的扫描层，功能上取代了 v2 的 Scan 和 RAGET。它包含 vulnerability_scan，用于红队测试，覆盖提示注入、越狱和有害内容；还有 quality_scan，用于知识库质量评估。这两个功能在 v2 中分别属于不同的模块，现在统一到 giskard-scan 包中。安装方式有两种：pip install "giskard[scan]" 会同时安装 giskard-checks 和 giskard-scan，或者单独 pip install giskard-scan。扫描包的设计目标是动态，也就是说它不只是跑一组固定的攻击模板，而是可能根据被测 Agent 的响应生成新的测试用例。不过 README 在这里被截断了，没有给出 vulnerability_scan 的具体 API 示例。从包版本看，giskard-scan v1.0.0 和 giskard v3.0.0 同一天发布，说明这是全新代码，没有历史包袱。但这也意味着它缺少长时间的生产验证。如果你需要扫描传统表格或 ML 模型，README 明确说那部分仍是 v2-only，v3 的扫描只针对 LLM Agent。这个边界很重要，选型时别搞混。

安装与 Python 版本约束

安装命令很简单：pip install giskard 会安装 giskard-checks 及其依赖，但不包含扫描功能。需要扫描时用 pip install "giskard[scan]"，或者直接 pip install giskard-scan。需要 LLM judge 时，得额外安装 provider SDK，比如 pip install "giskard[openai]"。硬性要求是 Python 3.12 以上，这个版本要求不算低，如果你的生产环境还在用 3.10 或 3.11，得先升级。包结构上，giskard-core 提供共享工具和遥测，giskard-llm 负责 LLM 路由，giskard-agents 做 Agent 编排，这三个是基础库，通常由其他包自动依赖，你不需要直接 import。README 强调 v3 是 modular，每个包只带必要依赖，这从 pyproject.toml 的 optional deps 可以看出。对于只想用 checks 做回归测试的团队，不装 scan 可以省下不少依赖。但注意，giskard-checks 本身也可能依赖 giskard-llm，后者需要配置 provider。安装后，快速开始里的代码就能跑，但前提是你有 OpenAI 的 API key，否则 Groundedness 检查会失败。

v2 与 v3 的断裂：迁移成本与遗留问题

README 里有一个醒目的警告：v3 是 fresh rewrite，不兼容 v2。v2 仍可用但已不再积极维护。这意味着如果你之前用 v2 的 Scan 或 RAGET，迁移到 v3 不是简单的 pip upgrade，而是需要重写调用代码。v3 的 API 完全不同，比如 v2 的 scan 函数被替换为 giskard-scan 包的 vulnerability_scan。v2 的 RAGET 测试集生成功能，在 v3 中变成了 quality_scan，但接口和输出格式可能都变了。另外，v3 只支持 Python 3.12+，而 v2 可能支持更早版本，这也会影响迁移。更关键的是，v3 明确不支持表格 ML 模型的扫描，那部分功能留在 v2。如果团队同时有传统 ML 模型和 LLM Agent 需要测试，你可能得同时维护两套工具，v2 用于表格模型，v3 用于 Agent。这种断裂是重写的代价，但项目方选择不再维护 v2，意味着安全漏洞或 bug 修复不会及时，长期使用 v2 有风险。评估前，你应该检查自己的测试用例有多少依赖 v2 特性，比如自定义扫描模板，这些在 v3 中可能需要重写。

与同类工具的比较：黑盒测试与动态生成

市面上有其他 LLM 评估库，比如 LangChain 的评估模块或 DeepEval，但 Giskard v3 的定位有几个不同点。首先，它强调 black-box agent 测试，被测对象可以是任何 callable，不需要你暴露内部 chain 或 prompt。这比那些要求你继承特定基类的框架更灵活。其次，giskard-scan 的动态生成能力，它不只是跑固定攻击列表，而是可能根据响应调整后续输入，这类似于专门的 red team 工具。另一个区别是包拆分，Giskard 把 checks 和 scan 分开，让用户按需安装，而许多同类库是单体内核，装上就是全部。但 Giskard 的 LLM judge 依赖外部模型，默认 OpenAI，这一点和 DeepEval 类似，但 DeepEval 支持本地模型或自定义 judge，Giskard 的 giskard-llm 理论上也支持多 provider，但 README 只给了 openai 的例子。如果你完全不想用云端 LLM，Giskard 内置的非 LLM 检查只有字符串匹配、正则和语义相似度，前两者太弱，语义相似度可能也需要模型。所以，如果你的评估需求全部需要 LLM judge，且对 provider 有特定要求，需要确认 giskard-llm 是否支持你用的模型。

编辑结论

Giskard v3 适合需要持续验证 LLM Agent 行为的团队，尤其是那些希望把回归测试、RAG 落地性和安全漏洞扫描放进同一套 Python 工具的工程组。它要求 Python 3.12 以上，并且评估依赖 LLM judge，默认调用 OpenAI 模型，这意味着你必须有对应的 API key 和成本预算。如果你只做单轮问答的简单断言，或者你的环境禁止外部 LLM 调用，它可能过重。若你处理的是传统表格模型或 ML 模型，v2 的扫描仍是唯一选择，但 v2 已不再积极维护。采用前先确认：你的 Agent 是否支持异步调用，因为 Scenario.run() 是异步方法；你的数据是否允许发送给默认的 LLM judge；以及你是否接受遥测默认开启，虽然可以通过环境变量 DO_NOT_TRACK=1 关闭。Giskard v3 的模块化拆分意味着你可以只装 giskard-checks 而不拉入扫描依赖，但如果你需要漏洞扫描，就必须安装 giskard[scan] 并学习 vulnerability_scan 的接口，这个接口在 2026 年 8 月才发布 1.0 版本，稳定性有待观察。

官方来源

1. Giskard-AI/giskard-oss on GitHub
2. License: Apache-2.0
3. Project website
4. README
5. Releases