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

AI智能体技能开发：如何用测试驱动开发保障大模型应用质量

news 2026/5/15 4:07:27

1. 项目概述：当AI智能体遇上测试驱动开发

最近在GitHub上看到一个挺有意思的项目，叫agent-skill-tdd。光看名字，就能嗅到一股混合了前沿AI技术与经典工程实践的味道。简单来说，这个项目探讨的是如何将测试驱动开发这套久经考验的软件开发方法论，应用到AI智能体的技能构建与验证过程中。

这其实戳中了一个当下很多AI应用开发者，尤其是做智能体（Agent）方向的朋友们，正在面临的痛点。我们花大力气调教出一个能说会道、看似聪明的AI模型，让它去执行一些任务，比如写代码、分析数据、处理文档。但怎么确保它每次都能稳定、正确地完成任务？今天发挥超常，明天可能就给你胡言乱语。传统的单元测试、集成测试，面对的是一个输入固定、输出可预期的函数或API。但AI智能体的输出充满了不确定性，是概率性的，是“生成”出来的。agent-skill-tdd这个项目，正是在尝试为这种不确定性套上确定性的“缰绳”，用TDD的思想来驱动和保障AI技能的质量。

如果你正在或计划开发基于大语言模型的智能体应用，无论是企业内部自动化流程助手，还是面向用户的对话机器人，这个项目背后的思路都值得你深入了解。它不只是关于写几个测试用例，更是一种构建可靠、可维护AI应用的工程哲学。

2. 核心理念拆解：为什么AI技能需要TDD？

2.1 传统TDD与AI技能开发的鸿沟

测试驱动开发的核心循环是“红-绿-重构”：先写一个失败的测试（红），然后编写最少量的代码使测试通过（绿），最后重构代码以提升质量。这套流程在确定性编程中如鱼得水，因为输入和输出的映射关系是明确的。

但到了AI智能体这里，情况变得复杂。一个“技能”可能是一段提示词（Prompt），一个调用工具的函数，或者是一系列思维链（Chain-of-Thought）的引导。它的输出不是计算出来的，而是模型基于概率“生成”的。比如，你让智能体“总结这篇技术文章的核心观点”，对于同一篇文章，模型每次生成的核心观点表述可能都不完全一样，但语义上应该是等价的。传统的断言assertEquals(output, “预期的核心观点”)几乎总会失败，因为字面匹配太难了。

所以，agent-skill-tdd首先要解决的，就是如何为这种非确定性、语义性的输出定义“通过测试”的标准。这不再是简单的字符串匹配，而是上升到了语义匹配、意图达成度评估的层面。

2.2 项目核心目标：建立AI技能的“质量门禁”

在我看来，这个项目的深层目标是为AI技能建立一个可重复、自动化的“质量门禁”。它试图回答以下几个关键问题：

技能一致性：我的智能体技能，在面对相似但不同的输入时，是否能保持稳定的行为模式和输出质量？例如，一个“代码审查”技能，是否对不同编程风格、不同复杂度的代码都能给出结构化的、有建设性的意见？
边界条件处理：当输入是边缘情况、无效数据或对抗性提示时，我的技能是否会崩溃、被误导或产生有害输出？TDD鼓励我们先考虑这些失败场景。
技能演进的安全网：当我优化提示词、调整温度参数、甚至切换底层模型时，我如何快速知道这些改动有没有破坏已有的核心功能？一套完整的测试套件就是最好的安全网。
技能组合的集成验证：单个技能测试通过后，多个技能组合成一个工作流时，它们之间的协作是否顺畅？数据传递是否正确？这类似于传统开发中的集成测试。

通过引入TDD，我们迫使自己在编写技能逻辑（主要是设计提示词和流程）之前，就先思考并定义这个技能的“成功标准”和“失败场景”。这能极大提升AI应用的可控性和工程化水平。

3. 技术架构与核心组件设想

虽然原项目仓库可能提供了具体实现，但基于TDD for AI Agents的通用思路，我们可以勾勒出一个典型的技术架构。这个架构通常包含以下几个核心层：

3.1 测试定义层：如何描述AI技能的预期行为？

这是最具有挑战性的一层。我们不能再写assert response == “Hello, World”。取而代之的是更高级的断言方式：

语义相似度断言：使用嵌入模型（如OpenAI的text-embedding-ada-002，或开源的BGE、Sentence-Transformers）将预期输出和实际输出转换为向量，然后计算余弦相似度。断言相似度高于某个阈值（如0.85）。

# 伪代码示例 def assert_semantically_similar(actual: str, expected: str, threshold: float = 0.85): actual_embedding = embed(actual) expected_embedding = embed(expected) similarity = cosine_similarity(actual_embedding, expected_embedding) assert similarity >= threshold, f“语义相似度{similarity:.3f}低于阈值{threshold}”

结构化输出断言：强制技能以JSON、XML等特定格式输出，然后对解析后的结构化数据进行断言。这是目前非常可靠的一种方式，易于验证。

# 假设技能应返回JSON: {“summary”: str, “key_points”: List[str], “sentiment”: “positive”|“neutral”|“negative”} def test_article_summarizer(): article = “一篇长文章内容...” result = agent_skill.summarize(article) # 首先断言能成功解析为JSON data = json.loads(result) assert “summary” in data assert isinstance(data[“key_points”], list) assert data[“sentiment”] in [“positive”, “neutral”, “negative”] # 进一步断言摘要长度 assert 50 < len(data[“summary”]) < 200

规则/策略断言：针对输出内容必须满足的特定规则进行检查。例如，对于代码生成技能，可以用AST解析器检查生成的代码语法是否正确；对于安全相关技能，可以断言输出中不包含某些敏感词。

LLM-as-a-Judge：用另一个（通常是更强或更专精的）LLM来评估当前技能的输出是否满足要求。这非常灵活，可以评估创造性、一致性、安全性等难以量化的维度。但成本较高，且评估本身也有不确定性。

# 伪代码示例：使用LLM评估摘要质量 evaluation_prompt = f“”“ 请评估以下摘要是否准确抓住了原文的核心内容。 原文主题：{article_topic} 生成的摘要：{generated_summary} 请只回答‘是’或‘否’。 “”“ judge_response = call_llm(evaluation_prompt) assert “是” in judge_response

注意：在实际项目中，通常会混合使用多种断言方式。对于核心功能，优先使用结构化输出断言，因为它最稳定、成本最低。对于需要语义理解的场景，辅以语义相似度断言。仅在必要时（如评估创意写作）使用LLM-as-a-Judge，并注意设置合理的重试和超时机制。

3.2 测试运行与脚手架层

这一层负责组织、运行测试，并提供测试所需的工具和环境。

测试框架集成：可以基于pytest、unittest等主流Python测试框架进行扩展。agent-skill-tdd项目可能会提供一些特定的fixture（夹具）或decorator（装饰器），来方便地模拟AI调用、注入工具、设置测试用的LLM（例如使用成本较低的模型，或者本地模型如Qwen2.5-Coder、Llama 3.2）。
Mock与Stub：为了测试的稳定性和速度，必须能够模拟（Mock）对真实LLM API的调用，以及智能体可能使用的各种外部工具（如搜索引擎、数据库、API）。测试时，我们用一个可控的“假”模型来替代真实GPT-4，让它返回我们预设的响应，从而专注于测试技能逻辑本身。
测试数据集管理：需要一套机制来管理用于测试的输入输出对（Test Cases）。这些数据可能来自人工标注、历史交互记录，或是通过合成数据生成。一个好的实践是将测试用例与代码分离，用YAML或JSON文件来管理，方便维护和共享。
持续集成/持续部署流水线集成：将AI技能测试套件接入CI/CD管道（如GitHub Actions, GitLab CI）。每次代码或提示词更新，都自动运行测试，确保变更不会引入回归错误。

3.3 技能开发与迭代层

这是开发者实际工作的层面，TDD循环在此发生。

编写失败测试：针对一个新技能（如“生成SQL查询语句”），先编写测试。定义输入（一个自然语言问题：“找出上个月销售额最高的产品”），和期望的输出结构（一个合法的SQL SELECT语句）。运行测试，它应该失败（红），因为技能还没实现。
实现最小化技能：编写最简单的提示词和逻辑，让测试通过。可能就是一个非常基础的提示词模板，调用LLM。运行测试，看到它通过（绿）。
重构与增强：在测试的保护下，放心地重构提示词使其更高效，增加少样本示例，引入思维链，或者优化处理流程。每步改动后都运行测试，确保核心功能未被破坏。
增加新测试：为边界情况（如模糊的问题、不存在的表名）添加测试，然后重复上述过程，驱动技能变得更加健壮。

4. 实战演练：构建一个“邮件分类”技能的TDD流程

让我们通过一个具体的例子，把上面的理论落地。假设我们要为一个客服助手智能体开发一个“邮件分类”技能：输入一封客户邮件正文，输出邮件的类别（如“投诉”、“咨询”、“表扬”、“垃圾邮件”）和紧急程度（“高”、“中”、“低”）。

4.1 第一步：搭建测试环境与编写第一个测试

首先，我们假设项目使用pytest。我们创建一个测试文件test_email_classifier.py。

# test_email_classifier.py import json import pytest from your_agent_skill_lib import EmailClassifierSkill class TestEmailClassifier: @pytest.fixture def classifier(self): # 返回一个待测试的技能实例，这里可能注入一个mock的LLM return EmailClassifierSkill(llm_client=mock_llm) def test_classify_complaint_email(self, classifier): “”“测试对投诉邮件的正确分类”“” email_body = “”” 尊敬的客服， 我上周购买的商品有严重质量问题，根本无法使用。 我对这次购物体验非常失望，要求立即退款并赔偿。 希望你们尽快处理！ 愤怒的客户 “”” result = classifier.classify(email_body) # 1. 断言输出是合法的JSON字符串 data = json.loads(result) # 2. 断言包含所需字段 assert “category” in data assert “urgency” in data # 3. 断言分类结果符合预期 assert data[“category”] == “投诉” assert data[“urgency”] == “高”

此时，EmailClassifierSkill类还不存在，运行pytest会失败（红）。这正是我们想要的。

4.2 第二步：实现技能并通过测试

现在，我们创建email_classifier.py并实现最简单的版本。

# email_classifier.py class EmailClassifierSkill: def __init__(self, llm_client): self.llm = llm_client def classify(self, email_body: str) -> str: prompt = f“”” 请将以下客户邮件分类，并判断紧急程度。 只输出一个JSON对象，包含两个字段：`category` 和 `urgency`。 `category` 的可选值：[“投诉”， “咨询”， “表扬”， “垃圾邮件”] `urgency` 的可选值：[“高”， “中”， “低”] 邮件内容： “{email_body}” “”” # 这里调用LLM，为了测试，我们先硬编码一个返回 # 在实际TDD中，我们会配置mock_llm返回我们期望的JSON字符串 response = self.llm.complete(prompt) return response

同时，我们需要在测试中设置mock_llm，让它返回我们期望的响应。

# 在conftest.py或测试文件顶部 from unittest.mock import Mock @pytest.fixture def mock_llm(): mock = Mock() # 模拟LLM返回我们测试用例期望的JSON mock.complete.return_value = json.dumps({“category”: “投诉”, “urgency”: “高”}) return mock

现在，再次运行pytest，测试应该通过（绿）。我们完成了第一个TDD循环。

4.3 第三步：重构与增加测试用例

第一个实现很简陋。我们可以重构提示词，使其更清晰，并增加少样本示例（Few-Shot Examples）来提高准确性。在测试的保护下，我们可以放心修改prompt字符串。

然后，我们增加更多测试用例，驱动技能覆盖更多场景：

def test_classify_inquiry_email(self, classifier, mock_llm): “”“测试对咨询邮件的分类”“” email_body = “你好，我想了解一下产品A的保修政策是怎样的？” # 重新配置mock返回咨询、中紧急度 mock_llm.complete.return_value = json.dumps({“category”: “咨询”, “urgency”: “中”}) result = classifier.classify(email_body) data = json.loads(result) assert data[“category”] == “咨询” assert data[“urgency”] == “中” def test_classify_spam_email(self, classifier, mock_llm): “”“测试对垃圾邮件的识别”“” email_body = “恭喜您中奖了！点击链接领取百万奖金...” mock_llm.complete.return_value = json.dumps({“category”: “垃圾邮件”, “urgency”: “低”}) result = classifier.classify(email_body) data = json.loads(result) assert data[“category”] == “垃圾邮件” def test_output_format_strict(self, classifier, mock_llm): “”“测试输出格式必须严格符合JSON，且字段值必须在规定范围内”“” # 模拟一个返回了非法值的LLM mock_llm.complete.return_value = json.dumps({“category”: “其他”, “urgency”: “紧急”}) result = classifier.classify(“some email”) data = json.loads(result) # 我们的技能应该增加验证逻辑，或者提示词要足够强来避免这种情况。 # 这个测试一开始会失败，驱动我们增强技能。 assert data[“category”] in [“投诉”， “咨询”， “表扬”， “垃圾邮件”] assert data[“urgency”] in [“高”， “中”， “低”]

通过不断添加测试，我们驱动技能处理更多边缘情况，比如超长邮件、空邮件、包含乱码的邮件，并确保输出格式始终合规。

4.4 第四步：集成真实模型与评估

当单元测试在Mock环境下全部通过后，我们需要一个“集成测试”阶段，用真实的LLM（可以是成本较低的如gpt-3.5-turbo或本地模型）在小规模验证集上运行，评估其实际效果。

我们可以计算分类的准确率、召回率，或者使用LLM-as-a-Judge进行人工对齐度评估。这个阶段可能会发现一些在Mock测试中未暴露的问题，例如模型对某些表述的歧义理解。这些问题又会反馈回来，成为新的、更精细的单元测试用例，从而开启新一轮的TDD迭代。

5. 高级话题与最佳实践

5.1 提示词版本管理与测试

提示词本身就是代码。应该将提示词模板化，并纳入版本控制系统（如Git）。每次对提示词的修改，都应触发对应的测试套件运行。可以将提示词存储在单独的.jinja2或.txt文件中，在技能中读取，方便管理和对比差异。

5.2 测试数据的构建与管理

高质量的测试数据是TDD的基石。对于AI技能，测试数据应包括：

典型用例：覆盖技能设计的主要场景。
边界用例：输入为空、极长、包含特殊字符、语义模糊的情况。
对抗性用例：试图让技能产生错误、偏见或有害输出的输入。
历史错误用例：线上实际出现过的错误案例，将其转化为测试，防止回归。

建议使用文件（如test_cases.yaml）来管理这些数据，使测试逻辑与数据分离。

5.3 性能与成本测试

除了功能性测试，还需要关注：

延迟测试：技能响应的P95、P99延迟是否在可接受范围内？
成本测试：单次调用消耗的Token数是多少？是否符合预算？Mock测试可以统计Token消耗，集成测试可以统计实际API成本。
速率限制测试：当并发请求增加时，技能是否稳定？

这些都可以通过扩展测试框架来实现，例如使用pytest-benchmark进行性能测试。

5.4 技能组合与工作流测试

单个技能测试通过后，需要测试技能之间的衔接。例如，“邮件分类”技能的输出，会成为“工单路由”技能的输入。我们需要测试整个工作流：

给定一封邮件。
“邮件分类”技能输出{“category”: “投诉”， “urgency”: “高”}。
“工单路由”技能接收这个JSON，并正确创建一个高优先级的投诉工单。

这需要模拟技能间的调用，验证数据流转的正确性，是更高级别的集成测试。

6. 常见陷阱与排查指南

在实际操作中，你会遇到一些典型问题。以下是我在实践中总结的一些坑和应对方法：

问题现象	可能原因	排查与解决思路
测试时好时坏（Flaky Tests）	1. 使用了真实LLM API，其输出有自然波动。 2. 断言过于严格（如完全字符串匹配）。 3. 温度参数设置过高。	1.单元测试必须Mock：隔离外部依赖，测试逻辑本身。 2.使用宽松/智能断言：改用语义相似度、结构化数据验证或范围断言。 3.降低温度：在测试和CI环境中，将LLM的温度设为0或接近0，以获得确定性输出。
Mock设置复杂且脆弱	技能提示词稍有改动，Mock就需要大量调整。	1.黑盒Mock：不Mock具体的提示词-响应对，而是Mock整个LLM调用，直接返回测试用例期望的最终结果。关注技能的输出，而非内部实现。 2.使用录制/回放工具：首次用真实API运行测试，将请求响应录制下来，后续测试直接回放。
测试运行速度慢	集成了真实模型调用，或测试用例太多。	1.分层测试：大量单元测试用Mock，快速运行。少量集成/端到端测试用真实模型。 2.使用本地小模型：集成测试时使用可在CI环境运行的轻量级本地模型（如Phi-3, Qwen2.5-Coder-1.5B）。 3.并行化测试：利用pytest-xdist等插件并行运行测试。
LLM-as-Judge评估不稳定	作为裁判的LLM本身评估不一致。	1.设置明确的评估规则：给裁判LLM非常清晰、可操作的指令，最好要求其输出是结构化的（如打分1-5，或“是/否”）。 2.多数投票：同一个测试用例用裁判LLM评估多次，取多数结果。 3.仅用于高级评估：不要将其作为核心功能测试的主要手段，仅用于创意性、安全性等难以量化指标的补充评估。
技能重构后大量测试失败	提示词或输出格式发生了重大变更。	1.这是正常过程：TDD中，重构可能改变接口，测试也需要同步更新。 2.契约测试：考虑引入契约测试思想，明确技能对外提供的“契约”（输入输出格式），契约变更时，需要同步更新所有消费者（测试和其他技能）的期望。