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-scan3.2 封装你的AI Agent我们的“智能水杯”客服Agent可能是一个简单的函数调用GPT-3.5-turbo模型。import os from openai import OpenAI # 假设你的API Key已设置在环境变量中 client OpenAI(api_keyos.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( modelgpt-3.5-turbo, messages[ {role: system, content: system_prompt}, {role: user, content: user_query} ], temperature0.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你们的水杯叫什么名字, # 用户输入 outputssmart_cup_agent, # 调用我们的Agent函数 ) .check( Contains( nameresponse_contains_product_name, # 检查器名称 substrings[AquaSmart Pro], # 预期输出应包含的子串 case_sensitiveFalse # 是否区分大小写 ) ) ) # 异步运行这个场景 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这款杯子的官方名称是什么, outputssmart_cup_agent, ) .check( SemanticSimilarity( nameanswer_semantically_close, expectedAquaSmart Pro, # 预期文本 threshold0.8, # 相似度阈值0-10.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这个水杯的电池能用多久, outputslambda query: smart_cup_agent(query), # 这里可以包装更复杂的RAG流程 ) .check( Groundedness( nameanswer_grounded_in_context, contextretrieved_context, # 提供的上下文 threshold0.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( inputsAquaSmart Pro多少钱, outputssmart_cup_agent, ).check( Contains(substrings[299, 元, 价格], namecontains_price_info) ) # 第二轮基于上一轮询问保修不重复产品名 .interact( inputs保修期多久, outputssmart_cup_agent, ).check( # 检查是否仍然在讨论AquaSmart Pro而不是跳到其他产品 SemanticSimilarity(expectedAquaSmart Pro的保修政策, threshold0.6, namestill_on_topic), Contains(substrings[年, 保修], namecontains_warranty_info) ) # 第三轮询问一个上下文未明确但可推断的问题 .interact( inputs比旧款贵了多少, outputssmart_cup_agent, ).check( # 检查Agent是否诚实而不是编造旧款价格 Contains(substrings[不知道, 不了解旧款, 无法比较], namehandles_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__(namename) # 定义一组违规关键词 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( passedFalse, statusCheckStatus.FAILED, reasonf回答中包含不合规的绝对保证词语: {, .join(found_violations)} ) else: # 否则通过 return CheckResult( passedTrue, statusCheckStatus.PASSED, reason未检测到绝对保证性词语。 ) # 使用自定义检查器 scenario_compliance ( Scenario(test_compliance_no_guarantee) .interact( inputs这个水杯会漏水吗, outputssmart_cup_agent, ) .check( NoAbsoluteGuaranteeCheck(namecheck_absolute_guarantee) ) )现在如果Agent回答“我们的水杯绝对不会漏水”这个测试就会失败并给出清晰的失败原因。自定义检查器的威力在于你可以将任何业务逻辑、合规要求甚至调用外部验证API的代码封装进去实现高度定制化的质量门禁。注意事项自定义检查器的_run方法必须是异步的async def因为它可能会被用在异步执行的Suite中。同时确保你的检查逻辑是幂等的并且不会产生副作用如修改外部状态。5. 集成到CI/CD让AI测试成为发布流程的一部分自动化测试只有集成到持续集成/持续部署CI/CD流水线中才能发挥最大价值。每次代码提交或模型更新时自动运行测试套件防止回归。5.1 使用pytest集成Giskard与pytest原生集成这是最自然的CI集成方式。你可以像写普通单元测试一样写Giskard测试。创建一个文件test_agent.pyimport 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产品名, outputssmart_cup_agent) .check(Contains(substrings[AquaSmart Pro], namecontains_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 -v5.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/checkoutv4 - name: Set up Python uses: actions/setup-pythonv5 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 --tbshort # 可选上传测试报告如果Giskard生成HTML/JSON报告 - name: Upload test results if: always() # 即使测试失败也上传 uses: actions/upload-artifactv4 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( targetsmart_cup_agent, # 你的Agent函数 descriptionA 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_scenarios50, # 可选限制生成的最大测试场景数 ) 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应用质量更有信心。