当前位置：首页 > news >正文

Giskard v3：AI Agent自动化测试与评估框架实战指南

news 2026/7/6 10:04:44

1. 项目概述：为什么你的AI Agent需要一个“质检员”？

如果你正在开发或已经部署了基于大语言模型的AI Agent，无论是客服机器人、代码助手还是数据分析工具，你大概率遇到过这样的场景：上线前信心满满，上线后用户反馈“答非所问”、“胡说八道”甚至“突然发疯”。这不是危言耸听，而是LLM非确定性输出带来的必然挑战。传统的软件测试断言，比如“输入A，必须得到B”，在AI Agent的世界里彻底失效了。同一个问题，模型今天回答“巴黎”，明天可能回答“法国的首都是巴黎”，两者都对，但你的测试脚本可能就挂了。

这就是Giskard v3要解决的核心问题。它不是一个简单的API封装，而是一个专门为动态、多轮、非确定性交互的AI Agent设计的自动化测试与评估框架。你可以把它理解为你AI Agent的专职“质检员”。这个质检员不关心代码的语法错误（那是pytest的活儿），它关心的是你的Agent在真实世界交互中的“行为质量”：回答是否准确、是否安全、是否遵循了业务规则、在多轮对话中是否保持了逻辑一致性。

我接触过不少团队，他们的AI项目测试还停留在手动在聊天窗口里提问、肉眼判断的阶段。这种方式的效率低下且不可靠，更无法集成到CI/CD流程中实现自动化回归。Giskard v3的出现，正是为了填补这个空白。它通过一套清晰的核心抽象——Check（检查）、Scenario（场景）、Suite（套件）——让你能够像编写传统单元测试一样，为你的AI Agent构建结构化的、可重复的、自动化的质量保障体系。无论你用的是OpenAI、Anthropic的云端模型，还是Llama、Qwen等本地部署的模型，Giskard都能无缝接入，因为它框架无关，只关心你Agent的输入和输出行为。

2. 核心架构与设计哲学拆解

Giskard v3被官方称为一次“重写”，这不仅仅是版本号的升级，更是一次设计理念的革新。其核心目标是模块化、轻量化和异步优先。理解这三点，你就能明白为什么它能优雅地处理AI测试的复杂性。

2.1 三大核心抽象：Check, Scenario, Suite

整个框架建立在三个简洁的抽象之上，这种极简设计大大降低了学习成本和集成难度。

Check（检查器）：这是最小的测试单元，定义了一个具体的“断言”或“验证规则”。它回答一个问题：“这个输出是否满足某个特定条件？”Giskard内置了多种开箱即用的Check，比如：

字符串匹配：检查输出是否完全等于或包含某个关键词。
语义相似度：使用嵌入模型（如sentence-transformers）计算输出与预期文本的语义距离，判断是否“意思相近”。
Groundedness（上下文相关性）：这是RAG（检索增强生成）应用的关键。它验证模型的回答是否严格基于你提供的上下文（Context），而不是利用其内部知识“胡编乱造”。这对于确保信息准确性至关重要。
LLM-as-Judge：用一个LLM（通常是更强大的模型，如GPT-4）来评判另一个LLM的输出质量。这是一种非常灵活且强大的评估方式，可以用于评估创造性、友好度、逻辑性等难以用规则定义的维度。

Scenario（测试场景）：这是测试用例的载体。它定义了一次完整的交互：给定一组输入（Inputs），调用你的AI Agent函数，获取输出（Outputs），然后对这个输出运行一个或多个Check。一个Scenario模拟了用户与Agent的一次完整对话回合。它的强大之处在于，输入和输出都可以是动态函数，这意味着你可以测试非常复杂的交互逻辑。

Suite（测试套件）：这是测试的组织和管理单元。你可以把多个相关的Scenario组合成一个Suite，然后批量运行。Suite支持嵌套，你可以按功能模块（如“客服模块”、“订单查询模块”）来组织你的测试，使得测试结构清晰，报告一目了然。

这种设计让Giskard的测试代码看起来非常像pytest，对于开发者来说几乎没有额外的认知负担。你不需要学习一套全新的、笨重的测试框架，而是用你熟悉的编程模式来构建AI测试。

2.2 异步优先的设计考量

Giskard v3将几乎所有核心操作（如scenario.run(),suite.run()）都设计为异步（async/await）。这绝非偶然，而是针对AI应用测试场景的深思熟虑。

AI模型的调用，无论是通过HTTP请求访问云端API，还是本地模型推理，本质上都是I/O密集型操作，存在显著的延迟。同步阻塞的测试运行方式意味着你的测试脚本在等待一个模型响应时，整个线程都会被挂起，无法执行其他测试。当你有成百上千个测试用例时，这种串行执行会变得极其缓慢。

异步架构允许你在等待一个模型响应的同时，去发起另一个测试请求，或者处理其他检查逻辑。这能最大限度地利用计算资源，将测试套件的总运行时间压缩到最低。在实际项目中，一个包含50个Scenario的测试套件，采用异步执行可能比同步执行快3-5倍，这对于需要频繁运行的CI/CD流水线来说，效率提升是巨大的。

实操心得：刚开始使用Giskard v3时，很容易忘记run()方法是异步的，直接调用scenario.run()会得到一个未被等待的协程对象，导致测试看似“通过”实则未执行。务必记住使用asyncio.run()或在异步函数内使用await。这是从v2升级到v3最需要适应的变化之一。

2.3 框架无关性：拥抱多样性

Giskard不绑定任何特定的AI框架或模型提供商。它对你的AI Agent只有一个要求：封装成一个接受输入（通常是字符串或字典）并返回输出（字符串或结构化数据）的Python函数（或可调用对象）。

这意味着，无论你的Agent底层是：

裸模型调用：直接使用openai.OpenAI().chat.completions.create。
LangChain Chain：一个复杂的LCEL链。
LlamaIndex QueryEngine：一个集成了检索器的查询引擎。
自定义的Agent类：你自己用循环和工具调用实现的Agent逻辑。

你只需要将这个复杂的对象包装成一个简单的函数，Giskard就能对其进行测试。这种设计给予了开发者最大的灵活性，也保证了框架的长久生命力——无论AI技术栈如何变迁，Giskard的核心测试逻辑依然适用。

3. 从零开始：构建你的第一个AI Agent测试套件

理论说得再多，不如亲手实践。让我们从一个最简单的例子开始，逐步构建一个完整的测试工作流。假设我们有一个简单的客服AI Agent，它的功能是回答关于公司产品“智能水杯”的问题。

3.1 环境准备与安装

首先，创建一个干净的Python虚拟环境（强烈推荐，以避免依赖冲突）。然后安装Giskard核心库。

# 使用uv加速安装（推荐，速度更快） pip install uv uv pip install giskard # 或者使用常规pip pip install giskard

如果你计划使用Giskard Scan进行自动化安全扫描（红队测试），需要额外安装：

pip install giskard-scan

3.2 封装你的AI Agent

我们的“智能水杯”客服Agent可能是一个简单的函数，调用GPT-3.5-turbo模型。

import os from openai import OpenAI # 假设你的API Key已设置在环境变量中 client = OpenAI(api_key=os.getenv("OPENAI_API_KEY")) def smart_cup_agent(user_query: str) -> str: """ 一个简单的智能水杯客服Agent。 根据用户查询返回关于产品的信息。 """ system_prompt = """你是一个智能水杯公司的客服助手。产品信息如下： - 产品名称：AquaSmart Pro - 核心功能：24小时水温保温、饮水提醒、水质检测、App连接 - 电池续航：7天 - 材质：食品级不锈钢 - 价格：299元 请根据以上信息，友好、准确地回答用户问题。如果问题超出知识范围，请礼貌告知。 """ response = client.chat.completions.create( model="gpt-3.5-turbo", messages=[ {"role": "system", "content": system_prompt}, {"role": "user", "content": user_query} ], temperature=0.2, # 较低的温度使输出更确定 ) return response.choices[0].message.content

现在，smart_cup_agent函数就是Giskard将要测试的对象。它接收一个字符串user_query，返回一个字符串答案。

3.3 编写第一个Scenario：基础功能测试

让我们测试一个最基本的功能：询问产品名称。

import asyncio from giskard.checks import Scenario from giskard.checks.llm import Contains # 创建第一个测试场景 scenario_product_name = ( Scenario("test_product_name_query") # 场景名称，用于报告识别 .interact( inputs="你们的水杯叫什么名字？", # 用户输入 outputs=smart_cup_agent, # 调用我们的Agent函数 ) .check( Contains( name="response_contains_product_name", # 检查器名称 substrings=["AquaSmart Pro"], # 预期输出应包含的子串 case_sensitive=False # 是否区分大小写 ) ) ) # 异步运行这个场景 async def run_single_test(): result = await scenario_product_name.run() print(f"测试 '{scenario_product_name.name}' 结果: {result.status}") if not result.passed: print(f"失败原因: {result.failures}") asyncio.run(run_single_test())

运行这段代码，如果Agent的回答中包含了“AquaSmart Pro”（不区分大小写），测试就会通过。否则，result.failures会告诉你具体哪里不匹配。

3.4 使用更智能的Check：语义相似度与Groundedness

字符串匹配过于僵硬。如果用户问“这款杯子的官方名称是什么？”，Agent回答“官方名称是AquaSmart Pro智能水杯”，Contains检查可能会失败，因为字符串没有完全匹配。这时，语义相似度（SemanticSimilarity）检查就更合适。

from giskard.checks.llm import SemanticSimilarity scenario_semantic = ( Scenario("test_semantic_product_query") .interact( inputs="这款杯子的官方名称是什么？", outputs=smart_cup_agent, ) .check( SemanticSimilarity( name="answer_semantically_close", expected="AquaSmart Pro", # 预期文本 threshold=0.8, # 相似度阈值（0-1），0.8意味着80%相似 ) ) )

对于RAG应用，Groundedness（上下文相关性）是命门。我们必须确保答案来源于提供的上下文，而不是模型的“幻觉”。

from giskard.checks.llm import Groundedness # 假设我们有一个检索器返回的上下文 retrieved_context = """ AquaSmart Pro是本公司2024年旗舰产品。它采用双模加热技术，能在3分钟内将水温从20度升至95度。 电池容量为5000mAh，在正常使用下可续航一周。产品通过了FDA食品接触认证。 """ scenario_grounded = ( Scenario("test_grounded_answer") .interact( inputs="这个水杯的电池能用多久？", outputs=lambda query: smart_cup_agent(query), # 这里可以包装更复杂的RAG流程 ) .check( Groundedness( name="answer_grounded_in_context", context=retrieved_context, # 提供的上下文 threshold=0.7, # 答案基于上下文的比例阈值 ) ) )

Groundedness检查器会使用一个NLP模型来分析Agent的答案，判断其中的陈述有多少是能从提供的context中推导或直接找到支持的。如果答案中出现了“续航两周”这种上下文未提及的信息，检查就会失败。

3.5 构建测试套件（Suite）并生成报告

单个测试意义不大，我们需要将多个测试组织起来。

from giskard.checks import Suite # 创建一个测试套件 product_knowledge_suite = Suite("产品知识测试套件") # 添加多个场景 product_knowledge_suite.add(scenario_product_name) product_knowledge_suite.add(scenario_semantic) # 假设我们还有其他场景... # product_knowledge_suite.add(scenario_battery) # product_knowledge_suite.add(scenario_price) # 异步运行整个套件 async def run_full_suite(): results = await product_knowledge_suite.run() # 打印简洁的文本报告 results.print_report() # 你也可以获取结构化的结果进行进一步处理 print(f"\n套件总体通过率: {results.pass_rate:.2%}") for scenario_result in results.scenario_results: print(f" - {scenario_result.scenario_name}: {scenario_result.status}") if not scenario_result.passed: for failure in scenario_result.failures: print(f" 失败检查: {failure.check_name} - {failure.reason}") asyncio.run(run_full_suite())

print_report()会输出一个清晰的表格，展示每个Scenario及其包含的Check的通过状态。这对于快速查看测试结果非常方便。

4. 进阶实战：多轮对话测试与自定义检查器

基础的单轮测试解决了“静态”问题，但AI Agent的核心魅力在于多轮交互中的状态保持和逻辑连贯性。同时，内置检查器不可能覆盖所有业务规则，这时就需要自定义检查器。

4.1 模拟多轮对话测试

真实的客服对话是连续的。用户可能先问价格，再问保修，最后对比其他产品。我们需要测试Agent在这种连续对话中是否“记忆”了之前的上下文，回答是否一致。

Giskard通过MultiTurnScenario来支持这种测试。它允许你定义一系列连续的interact步骤。

from giskard.checks import MultiTurnScenario from giskard.checks.llm import Contains, SemanticSimilarity # 创建一个多轮对话场景 multi_turn_scenario = ( MultiTurnScenario("test_multi_turn_customer_service") # 第一轮：询问价格 .interact( inputs="AquaSmart Pro多少钱？", outputs=smart_cup_agent, ).check( Contains(substrings=["299", "元", "价格"], name="contains_price_info") ) # 第二轮：基于上一轮，询问保修（不重复产品名） .interact( inputs="保修期多久？", outputs=smart_cup_agent, ).check( # 检查是否仍然在讨论AquaSmart Pro，而不是跳到其他产品 SemanticSimilarity(expected="AquaSmart Pro的保修政策", threshold=0.6, name="still_on_topic"), Contains(substrings=["年", "保修"], name="contains_warranty_info") ) # 第三轮：询问一个上下文未明确，但可推断的问题 .interact( inputs="比旧款贵了多少？", outputs=smart_cup_agent, ).check( # 检查Agent是否诚实，而不是编造旧款价格 Contains(substrings=["不知道", "不了解旧款", "无法比较"], name="handles_unknown_gracefully") # 或者，如果你有旧款信息在系统提示中，可以检查具体数字 ) ) # 运行多轮测试 async def run_multi_turn(): result = await multi_turn_scenario.run() result.print_report() asyncio.run(run_multi_turn())

多轮测试的关键在于，后续轮次的inputs是紧接着上一轮输出的。Giskard会在内部维护这个对话历史，并确保你的Agent函数在每一轮被调用时，能接收到完整的对话上下文（这取决于你的Agent函数是如何实现的，你可能需要传递conversation_history参数）。

4.2 实现自定义检查器（Custom Check）

假设我们的业务规则要求：客服Agent在任何情况下都不能向用户做出“绝对保证”（如“永远不会坏”、“100%安全”），因为这是不合规的。内置检查器没有这个功能，我们需要自己写。

自定义检查器就是一个继承自Check基类并实现_run方法的类。

from typing import Dict, Any from giskard.checks import Check, CheckResult, CheckStatus class NoAbsoluteGuaranteeCheck(Check): """ 自定义检查器：检测回答中是否包含不合规的绝对保证性词语。 """ def __init__(self, name: str = "no_absolute_guarantee"): super().__init__(name=name) # 定义一组违规关键词 self.absolute_phrases = [ "永远不会", "绝对不", "100%安全", "保证不", "肯定没问题", "零风险", "万无一失", "永久有效" ] async def _run(self, output: str, **kwargs) -> CheckResult: """ _run 方法是检查逻辑的核心。 output: Scenario执行后，Agent返回的字符串。 """ found_violations = [] for phrase in self.absolute_phrases: if phrase in output: found_violations.append(phrase) if found_violations: # 如果发现违规词，测试失败 return CheckResult( passed=False, status=CheckStatus.FAILED, reason=f"回答中包含不合规的绝对保证词语: {', '.join(found_violations)}" ) else: # 否则通过 return CheckResult( passed=True, status=CheckStatus.PASSED, reason="未检测到绝对保证性词语。" ) # 使用自定义检查器 scenario_compliance = ( Scenario("test_compliance_no_guarantee") .interact( inputs="这个水杯会漏水吗？", outputs=smart_cup_agent, ) .check( NoAbsoluteGuaranteeCheck(name="check_absolute_guarantee") ) )

现在，如果Agent回答“我们的水杯绝对不会漏水”，这个测试就会失败，并给出清晰的失败原因。自定义检查器的威力在于，你可以将任何业务逻辑、合规要求甚至调用外部验证API的代码封装进去，实现高度定制化的质量门禁。

注意事项：自定义检查器的_run方法必须是异步的（async def），因为它可能会被用在异步执行的Suite中。同时，确保你的检查逻辑是幂等的，并且不会产生副作用（如修改外部状态）。

5. 集成到CI/CD：让AI测试成为发布流程的一部分

自动化测试只有集成到持续集成/持续部署（CI/CD）流水线中，才能发挥最大价值。每次代码提交或模型更新时，自动运行测试套件，防止回归。

5.1 使用pytest集成

Giskard与pytest原生集成，这是最自然的CI集成方式。你可以像写普通单元测试一样写Giskard测试。

创建一个文件test_agent.py：

import pytest import asyncio from giskard.checks import Scenario, Suite from giskard.checks.llm import Contains from my_agent_module import smart_cup_agent # 定义你的测试场景 @pytest.fixture def basic_scenario(): return ( Scenario("pytest_product_name") .interact(inputs="产品名？", outputs=smart_cup_agent) .check(Contains(substrings=["AquaSmart Pro"], name="contains_name")) ) @pytest.mark.asyncio async def test_agent_basic_knowledge(basic_scenario): """测试Agent的基础产品知识""" result = await basic_scenario.run() assert result.passed, f"基础知识测试失败: {result.failures}" @pytest.mark.asyncio async def test_agent_full_suite(): """运行一个完整的测试套件""" suite = Suite("CI完整套件") # ... 添加多个场景到套件 ... # suite.add(scenario1) # suite.add(scenario2) results = await suite.run() # 断言整体通过率，例如要求必须100%通过 assert results.pass_rate == 1.0, f"测试套件通过率仅 {results.pass_rate:.2%}" # 或者断言没有失败的场景 assert results.failed_scenarios == 0, f"有 {results.failed_scenarios} 个场景失败"

然后，你就可以在命令行中使用pytest运行这些测试了：

pytest test_agent.py -v

5.2 配置GitHub Actions工作流

下面是一个典型的GitHub Actions配置文件（.github/workflows/llm-tests.yml），用于在每次推送代码时自动运行AI Agent测试。

name: LLM Agent Tests on: [push, pull_request] jobs: test: runs-on: ubuntu-latest steps: - name: Checkout code uses: actions/checkout@v4 - name: Set up Python uses: actions/setup-python@v5 with: python-version: '3.11' - name: Install dependencies run: | pip install uv uv pip install -r requirements.txt uv pip install pytest pytest-asyncio giskard - name: Run LLM tests with pytest env: OPENAI_API_KEY: ${{ secrets.OPENAI_API_KEY }} # 将API Key存储在GitHub Secrets中 run: | pytest tests/ -v --tb=short # 可选：上传测试报告（如果Giskard生成HTML/JSON报告） - name: Upload test results if: always() # 即使测试失败也上传 uses: actions/upload-artifact@v4 with: name: llm-test-results path: | test-reports/ # 假设你的测试脚本将报告输出到此目录 **/*.html **/*.json

这个工作流完成了以下事情：

检出代码。
设置Python环境。
使用uv快速安装依赖（包括Giskard和pytest）。
运行pytest，它会自动发现并执行所有标记了@pytest.mark.asyncio的异步测试函数。
（可选）将生成的测试报告文件上传为工件，供后续查看。

实操心得：在CI环境中，模型API调用可能失败或超时。务必为你的测试场景设置合理的超时（timeout）和重试（retry）逻辑。你可以在封装Agent函数时加入这些逻辑，或者使用pytest的@pytest.mark.timeout装饰器。否则，不稳定的网络可能导致CI频繁失败。

6. 自动化安全审计：使用Giskard Scan进行红队测试

功能测试确保Agent“做对事”，而安全测试确保Agent“不做坏事”。Giskard Scan模块就是一个自动化的“红队”，专门模拟恶意用户，对你的Agent进行攻击测试，以发现潜在的安全漏洞。

6.1 扫描OWASP LLM Top 10风险

Giskard Scan内置了针对OWASP LLM Top 10威胁的测试用例，例如：

提示词注入（Prompt Injection）：诱导模型忽略系统指令，执行攻击者意图。
数据泄露（Sensitive Information Disclosure）：诱导模型泄露训练数据中的隐私信息或系统提示词。
不安全的输出处理（Insecure Output Handling）：测试模型输出如果被下游系统直接执行（如SQL、代码）可能带来的风险。
过度依赖（Overreliance）：测试模型在面对知识盲区时，是诚实承认还是盲目自信地编造（幻觉）。
供应链漏洞（Supply Chain Vulnerabilities）：检查依赖的模型或数据源的风险。

使用Scan非常简单，你只需要提供Agent函数和一个描述。

import asyncio from giskard.scan import vulnerability_scan async def run_security_scan(): await vulnerability_scan( target=smart_cup_agent, # 你的Agent函数 description="A customer service chatbot for a smart water cup company called AquaSmart. It answers questions about product features, price, and usage. It should not disclose internal company information or make unrealistic guarantees.", # 详细描述Agent的职责和边界 languages=["en", “zh”], # 扫描使用的语言 # max_scenarios=50, # 可选：限制生成的最大测试场景数 ) asyncio.run(run_security_scan())

运行后，Scan会自动生成一份安全报告，列出发现的潜在漏洞、风险等级、攻击示例（即触发漏洞的输入）以及修复建议。这个过程是完全自动化的，你不需要手动编写任何攻击用例。

6.2 解读扫描报告与修复

Scan的报告通常会按风险类别分类。对于每个发现的漏洞，你需要：

分析攻击示例：仔细看是哪种输入触发了问题。是用户绕过了系统提示吗？还是Agent过度泄露了信息？
评估风险：结合你的业务场景，判断这个漏洞的实际危害程度。一个内部使用的工具和一个面向公众的客服机器人，风险承受能力不同。
实施修复：
- 强化系统提示（System Prompt）：这是最常见也最有效的修复方式。在提示词中更明确地规定行为边界，使用“必须”、“禁止”等强指令，并加入“如果遇到X类问题，一律回答Y”的规则。
- 输出过滤（Output Filtering）：在Agent返回最终答案前，增加一个后处理层，过滤掉敏感词、不恰当内容或特定格式（如代码块）。
- 输入校验（Input Validation）：对用户输入进行预处理，检测并拦截明显的恶意模式（如大量重复字符、试图结束引号的字符串等）。
- 上下文限制（Context Limiting）：在RAG应用中，确保检索到的上下文是经过清洗和授权的，避免内部文档被意外检索并输出。

修复后，再次运行Scan，确认漏洞已关闭。将安全扫描也集成到CI/CD中，可以作为代码合并前的一个强制性质量关卡。

7. 常见问题排查与性能优化实录

在实际使用Giskard v3的过程中，你肯定会遇到一些坑。以下是我从多个项目中总结出的常见问题及其解决方案。

7.1 异步执行问题

问题：运行测试时，日志显示测试“通过”了，但感觉什么都没发生，或者报错RuntimeWarning: coroutine 'Scenario.run' was never awaited。

原因：Giskard v3的API是异步的。在普通的Python脚本中直接调用await scenario.run()而不在异步上下文中，或者在Jupyter Notebook中忘记处理异步，就会导致此问题。

解决方案：

在脚本中：使用asyncio.run()作为入口点。

import asyncio async def main(): result = await my_scenario.run() print(result) if __name__ == "__main__": asyncio.run(main()) # 正确

在Jupyter Notebook中：使用await关键字，但需要确保Cell在异步上下文中运行。通常直接await my_scenario.run()即可。如果不行，可以安装nest_asyncio来修补事件循环。
```
!pip install nest_asyncio import nest_asyncio nest_asyncio.apply() result = await my_scenario.run()
```
在pytest中：使用@pytest.mark.asyncio装饰器，并确保安装了pytest-asyncio插件。

7.2 测试执行速度慢

问题：测试套件运行时间过长，特别是当测试用例很多或模型响应慢时。

原因与优化：

模型调用延迟：这是主要瓶颈。Giskard的异步架构可以并行发起多个模型调用，但默认可能并发数有限。
- 优化：确保你的Agent函数或模型客户端本身支持并发请求。例如，OpenAI的Python库使用httpx，本身就支持异步。你可以使用asyncio.gather来并发运行多个独立的Scenario。Giskard Suite在内部会优化执行，但设计测试时也可以考虑将无依赖的测试分组并发。
检查器计算开销：SemanticSimilarity和Groundedness等检查器需要运行嵌入模型（如sentence-transformers），首次加载或计算大量文本时较慢。
- 优化：考虑在测试环境中预加载嵌入模型。对于Groundedness，如果上下文很长，可以尝试只截取最相关的部分进行计算。
网络延迟：调用云端API受网络影响。
- 优化：为测试设置合理的超时（如30秒），并使用重试机制处理偶发的网络错误。考虑在CI环境中使用地理位置上更接近的API端点。

7.3 Giskard Scan未发现漏洞或结果不理想

问题：运行vulnerability_scan后，报告显示“未发现漏洞”或生成的测试用例看起来无关紧要。

原因：

Agent描述（description）过于简单：Scan依赖你提供的自然语言描述来理解Agent的职责和边界，从而生成有针对性的攻击。如果描述只有“一个聊天机器人”，Scan将无从下手。
Agent功能太简单或太封闭：如果一个Agent只做一件极其简单且安全的事（如“返回当前时间”），攻击面自然很小。
扫描配置：可能限制了语言或最大场景数。

解决方案：

提供丰富、精确的description：详细描述Agent的角色、职责、知识范围、禁止行为。例如：“这是一个电商客服机器人，可以查询订单状态、处理退货申请、解答产品信息。它不能修改订单价格、不能透露用户个人信息、不能做出绝对保证性承诺。”
增加max_scenarios参数：让Scan尝试生成更多测试用例。
结合手动测试：Scan是自动化的红队，但不能完全替代手动安全评审。对于高风险的Agent，应进行手动渗透测试。

7.4 与现有测试框架的融合

问题：团队已有成熟的pytest测试框架，如何平滑引入Giskard而不增加维护负担？

解决方案：将Giskard测试视为一种特殊类型的集成测试或端到端测试。

目录结构：在tests/目录下创建子文件夹，如tests/unit/放传统单元测试，tests/llm/或tests/agent/放Giskard测试。
依赖管理：Giskard测试可能依赖外部模型API，运行较慢且可能有成本。可以在CI中将其标记为“扩展测试”或“夜间构建”，不一定在每次提交时都运行，但保证每天至少运行一次。
测试数据管理：Giskard的测试输入（Scenario的inputs）可以来自外部文件（如JSON、YAML），便于管理和复用。这也能让非开发人员（如产品经理、测试员）参与编写测试用例。
报告集成：Giskard的测试结果可以导出为JSON等格式，与你现有的测试报告平台（如Allure、JUnit）集成，提供统一的测试仪表板。

Giskard v3的设计哲学就是轻量化和模块化，它无意取代你现有的测试体系，而是作为一个强大的补充，专门攻克AI Agent质量保障这个新的、复杂的领域。将它嵌入你的开发流程，就像是给生产线增加了一台高精度的AI质检仪，能让你对交付的AI应用质量更有信心。

查看全文

http://www.jsqmd.com/news/1134028/