1. 项目概述：为什么AI代理也需要“质检员”？

最近在折腾一个基于大语言模型的智能客服项目，团队里几个小伙伴吭哧吭哧搞了几个星期，终于把核心的对话逻辑和业务集成跑通了。上线前信心满满，结果内部一测，问题百出：同一个问题，AI代理这次回答得头头是道，下次就答非所问；处理一个稍微复杂点的多轮流程，经常卡在某个节点“发呆”，或者逻辑直接跑飞。我们这才痛定思痛，意识到一个关键问题： AI代理，尤其是像Deepagents这类复杂的、由多个技能（Skills）和工具（Tools）组合而成的智能体，其质量与稳定性绝不能仅靠人工“感觉”来评判，必须引入系统化、自动化的测试手段。

这就像你开发一个传统的Web应用，不会只靠手动点击几下就宣布上线，而是会搭建一套完整的自动化测试框架，覆盖单元测试、集成测试和端到端测试。对于AI代理，这个需求更为迫切。因为它的“行为”是非确定性的，输入相同的提示词（Prompt），由于模型本身的随机性、上下文长度的变化、外部工具调用的状态差异，输出可能天差地别。 Deepagents自动化测试 ，本质上就是为这些“数字员工”量身定制的质量保障体系。它要解决的，不是代码有没有语法错误，而是AI代理的“行为”是否符合预期、逻辑是否连贯、在边界和异常情况下是否足够健壮。

简单来说，Deepagents自动化测试的核心目标有三个： 验证功能正确性、评估响应稳定性、确保流程可靠性。 它适合所有正在或计划使用Deepagents框架（或其他类似AI Agent框架，如LangChain、AutoGen）的开发者、测试工程师和产品经理。无论你是想确保一个简单的查询代理每次都能返回格式一致的结果，还是验证一个复杂的、串联了数据库查询、API调用和决策逻辑的工作流代理能稳定运行，这套方法论都能给你提供清晰的路径和实用的工具。

2. 核心挑战与测试策略设计

在传统软件测试中，输入和输出通常是确定的。你给一个函数传入参数 (2, 3) ，期望它返回 5 ，测试用例非常清晰。但到了AI代理这里，事情变得复杂了。

2.1 非确定性输出的挑战 这是最大的拦路虎。你问AI代理：“今天的天气怎么样？” 它可能回答：“今天是晴天，气温25度。” 也可能回答：“天气不错，晴朗，25摄氏度。” 从语义上看，两者都对，但字符串完全不一致。传统的断言（Assert） response == “今天是晴天，气温25度。” 会直接失败。因此， 基于字符串完全匹配的断言在AI测试中基本失效 ，我们必须转向 语义匹配 或 关键信息抽取验证 。

2.2 状态与上下文管理 AI代理往往是有状态的，一次对话的上下文会影响下一次的回复。测试一个多轮对话流程，你需要模拟完整的对话历史，并确保代理在每一轮都记住了关键信息并做出了正确的决策。这要求测试框架具备强大的 对话状态模拟和上下文注入 能力。

2.3 外部工具与技能（Skills）的集成 Deepagents的核心能力在于它能调用各种Skills（技能，可以理解为封装好的工具函数，如搜索、计算、查询数据库）。测试时，我们不仅要测试代理是否“想到”去调用正确的Skill，还要测试它传递给Skill的参数是否正确，以及它如何处理Skill返回的结果。这里涉及到 Skill的模拟（Mock）和桩（Stub） ，以避免在测试中真的去调用外部API或操作生产数据库。

2.4 长文本与复杂逻辑的评估 代理的回复可能是长篇大论，包含多个步骤的推理。如何自动化评估这段回复的质量？是看它是否包含了所有必要的关键点？还是看它的推理链条是否合乎逻辑？这需要设计更复杂的 评估器（Evaluator） 。

基于这些挑战，一个可行的Deepagents自动化测试策略应该包含以下几个层次：

1. 单元测试（Unit Testing） ：针对单个Skill或工具函数进行测试。这部分和传统测试无异，可以使用 pytest 等框架。确保每个“零件”本身是可靠的。
2. 组件/集成测试（Integration Testing） ：测试AI代理与一个或多个Skills的集成。重点在于验证代理能否正确理解用户意图、选择正确的Skill、传递正确的参数、并合理处理返回结果。这里需要大量使用Mock。
3. 端到端流程测试（E2E Testing） ：模拟真实用户与代理的完整交互流程，覆盖多轮对话和复杂业务场景。这是验证整体稳定性的关键。
4. 非功能测试 ：如性能测试（响应延迟）、稳定性测试（长时间运行是否内存泄漏）、安全测试（提示词注入防护）等。

3. 测试环境搭建与核心工具链选型

工欲善其事，必先利其器。搭建Deepagents的自动化测试环境，核心是选择一个能与Agent框架良好集成、又能灵活处理非确定性评估的测试框架。

3.1 测试框架：Pytest是基石 Pytest 是Python生态下事实上的标准测试框架，其丰富的插件生态（如 pytest-asyncio 用于异步测试）、清晰的夹具（Fixture）管理、以及强大的参数化功能，使其成为不二之选。Deepagents本身基于Python，用 pytest 能无缝集成。

# 基础环境准备
pip install pytest pytest-asyncio pytest-cov

3.2 模拟与桩：unittest.mock 和 pytest-mock 为了隔离测试，避免对外部服务的依赖，我们必须模拟（Mock）Skills和工具。Python自带的 unittest.mock 模块功能强大，而 pytest-mock 插件能将其更好地集成到pytest的夹具系统中，用起来更顺手。

# 示例：模拟一个搜索Skill
from unittest.mock import AsyncMock, MagicMock
import pytest

@pytest.fixture
def mock_search_skill(mocker):
    # 假设有一个SearchSkill类
    mock_skill = mocker.patch(‘my_agent.skills.SearchSkill.execute’)
    # 模拟它返回一个固定的结果
    mock_skill.return_value = AsyncMock(return_value=“根据查询，找到相关结果：ABC...”)
    return mock_skill

3.3 语义评估与断言：Beyond String Match 这是AI测试的灵魂。我们不能直接用 assert response == expected 。有几种策略：

• 关键信息抽取（Key Information Extraction） ：使用正则表达式或简单的自然语言处理库（如 spaCy 的规则匹配），从回复中提取日期、金额、名称等关键实体，与预期值对比。

  import re
  def extract_temperature(response):
      match = re.search(r’(\d+)\s*度’， response)
      return int(match.group(1)) if match else None
  
  def test_weather_agent():
      response = agent.ask(“今天气温多少？”)
      temp = extract_temperature(response)
      assert temp is not None
      assert 15 <= temp <= 40 # 一个合理的范围断言
  

• 嵌入向量相似度（Embedding Similarity） ：使用句子转换器（如 SentenceTransformers ）将回复和预期回复转换为向量，计算余弦相似度。相似度超过一个阈值（如0.85）即认为通过。这种方法对语义变化更鲁棒。

  from sentence_transformers import SentenceTransformer
  model = SentenceTransformer(‘paraphrase-MiniLM-L6-v2’)
  
  def semantic_assert(actual, expected, threshold=0.85):
      emb_actual = model.encode(actual)
      emb_expected = model.encode(expected)
      similarity = cosine_similarity(emb_actual, emb_expected)
      assert similarity >= threshold, f”语义相似度{similarity:.2f}低于阈值{threshold}”
  

• 使用评估LLM（LLM-as-a-Judge） ：让一个更强的LLM（如GPT-4）作为裁判，评估代理回复的质量。这非常强大但成本较高，更适合关键场景的验收测试或作为离线评估手段。你可以设计具体的评估标准，如“回复是否准确回答了问题”、“是否包含了所有必要信息”、“语气是否专业”等。

3.4 测试数据管理 准备高质量的测试用例（Test Cases）和测试数据集（Test Suite）至关重要。建议使用 pytest 的参数化功能，从一个CSV或JSON文件中读取大量的 (输入, 预期输出/评估标准) 对，进行批量测试。

import pytest
import csv

def load_test_cases():
    cases = []
    with open(‘test_cases.csv’， newline=‘’， encoding=‘utf-8’) as f:
        reader = csv.DictReader(f)
        for row in reader:
            cases.append((row[‘input’]， row[‘expected_key_info’]))
    return cases

@pytest.mark.parametrize(“user_input, expected_info”， load_test_cases())
def test_agent_with_dataset(user_input, expected_info):
    response = agent.ask(user_input)
    # 使用关键信息抽取或语义相似度进行断言
    extracted_info = extract_key_info(response)
    assert extracted_info == expected_info

实操心得 ：在项目初期，不要追求完美的评估器。从简单的关键词匹配和正则表达式开始，快速搭建起测试流水线。随着项目复杂度的提升，再逐步引入嵌入相似度或LLM评估。同时， 一定要将测试用例作为代码的一部分进行版本管理 ，随着需求变化而迭代。

4. 实战：构建一个Deepagents自动化测试流水线

让我们以一个具体的场景为例：构建一个“智能旅行助手”代理，它能根据用户需求推荐目的地、查询航班信息（模拟）、并生成简要行程。我们将为这个代理搭建从单元到集成的测试。

4.1 定义Agent与Skills 首先，我们定义两个简单的Skills和一个Agent。

# skills/flight_skill.py
class FlightSearchSkill:
    async def execute(self, query: str) -> str:
        # 模拟调用外部API
        # 真实情况下这里会有网络请求
        return f”已为您查询到{query}的航班信息：航班XX123，时间...”

# skills/destination_skill.py
class DestinationRecommendSkill:
    async def execute(self, preference: str) -> str:
        preference_map = {“海滩”: “三亚”， “雪山”: “长白山”， “美食”: “成都”}
        return f”根据您的偏好‘{preference}’，推荐目的地：{preference_map.get(preference, ‘北京’)}”

# agent/travel_agent.py
class TravelAgent:
    def __init__(self, flight_skill, dest_skill):
        self.flight_skill = flight_skill
        self.dest_skill = dest_skill

    async def ask(self, user_input: str) -> str:
        # 简单的意图识别和路由逻辑
        if “航班” in user_input or “飞机” in user_input:
            return await self.flight_skill.execute(user_input)
        elif “推荐” in user_input or “去哪” in user_input:
            # 这里应该有一个更复杂的NLP来提取偏好，我们简化处理
            preference = “海滩” # 假设提取出的偏好
            return await self.dest_skill.execute(preference)
        else:
            return “抱歉，我目前只能处理航班查询和目的地推荐。”

4.2 编写单元测试（测试Skills） 确保每个Skill本身的行为正确。

# tests/test_skills.py
import pytest
from skills.destination_skill import DestinationRecommendSkill

@pytest.mark.asyncio
async def test_destination_skill_beach():
    skill = DestinationRecommendSkill()
    response = await skill.execute(“海滩”)
    assert “三亚” in response

@pytest.mark.asyncio
async def test_destination_skill_default():
    skill = DestinationRecommendSkill()
    response = await skill.execute(“未知偏好”)
    assert “北京” in response # 测试默认逻辑

4.3 编写集成测试（测试Agent与Skills的交互） 这是重点。我们需要模拟（Mock）Skills，测试Agent的路由逻辑和参数传递。

# tests/test_travel_agent_integration.py
import pytest
from unittest.mock import AsyncMock
from agent.travel_agent import TravelAgent

@pytest.mark.asyncio
async def test_agent_routes_to_flight_skill():
    # 1. 创建Mock Skills
    mock_flight_skill = AsyncMock()
    mock_dest_skill = AsyncMock()

    # 2. 设置Mock的返回值
    mock_flight_skill.execute.return_value = “模拟航班信息：上海到北京，CA1501”

    # 3. 实例化Agent，注入Mock
    agent = TravelAgent(mock_flight_skill, mock_dest_skill)

    # 4. 调用Agent
    response = await agent.ask(“我想查一下去北京的航班”)

    # 5. 验证行为
    # 5.1 验证调用了正确的Skill
    mock_flight_skill.execute.assert_called_once()
    mock_dest_skill.execute.assert_not_called()

    # 5.2 验证传递给Skill的参数（至少包含关键词）
    call_args = mock_flight_skill.execute.call_args[0][0] # 第一个参数
    assert “北京” in call_args

    # 5.3 验证Agent的最终回复
    assert “模拟航班信息” in response

@pytest.mark.asyncio
async def test_agent_routes_to_dest_skill():
    mock_flight_skill = AsyncMock()
    mock_dest_skill = AsyncMock()
    mock_dest_skill.execute.return_value = “模拟推荐：三亚”

    agent = TravelAgent(mock_flight_skill, mock_dest_skill)
    response = await agent.ask(“有什么海边目的地推荐吗？”)

    mock_dest_skill.execute.assert_called_once()
    # 注意：这里我们测试的是Agent是否传递了它“认为”的偏好（我们代码里写死了‘海滩’）
    mock_dest_skill.execute.assert_called_with(“海滩”)
    assert “三亚” in response

4.4 编写端到端测试（模拟完整对话） 模拟一个用户从咨询目的地到查询航班的完整流程。

# tests/test_travel_agent_e2e.py
import pytest
from agent.travel_agent import TravelAgent
from skills.flight_skill import FlightSearchSkill
from skills.destination_skill import DestinationRecommendSkill

@pytest.mark.asyncio
async def test_full_travel_planning_conversation():
    # 使用真实的Skills（但在测试环境中，它们可能连接测试数据库或Mock API）
    # 这里为了演示，我们依然用真实类，但假设它们内部已做好测试隔离。
    flight_skill = FlightSearchSkill()
    dest_skill = DestinationRecommendSkill()
    agent = TravelAgent(flight_skill, dest_skill)

    # 第一轮：目的地推荐
    response1 = await agent.ask(“我想去个暖和的地方旅游，有推荐吗？”)
    # 使用语义断言：回复里应该包含推荐的目的地名称
    assert any(name in response1 for name in [“三亚”， “长白山”， “成都”， “北京”])

    # 第二轮：基于上一轮的“上下文”（在真实场景中，Agent需要维护对话状态），查询航班
    # 注意：我们当前的简单Agent是无状态的，所以这里测试的是独立查询。
    # 对于一个有状态的Agent，你需要将上一轮的response1作为上下文的一部分传入。
    response2 = await agent.ask(“那去三亚的航班呢？”)
    # 断言回复中包含了航班信息的指示性词语
    assert any(word in response2 for word in [“航班”， “飞机”， “查询”， “信息”])

4.5 利用Pytest Fixture优化代码 使用 pytest 的fixture来管理测试资源的生命周期，如创建Agent实例、模拟Skills，使测试代码更简洁。

# conftest.py (放在tests目录下，pytest会自动发现)
import pytest
from unittest.mock import AsyncMock
from agent.travel_agent import TravelAgent

@pytest.fixture
def mock_flight_skill():
    return AsyncMock()

@pytest.fixture
def mock_dest_skill():
    return AsyncMock()

@pytest.fixture
def travel_agent(mock_flight_skill, mock_dest_skill):
    """提供一个注入Mock Skill的Agent实例"""
    return TravelAgent(mock_flight_skill, mock_dest_skill)

# 在测试文件中可以直接使用这些fixture
def test_with_fixture(travel_agent, mock_flight_skill):
    # travel_agent 已经是一个准备好了的Agent实例
    # mock_flight_skill 是与之关联的Mock对象
    pass

5. 高级测试场景与评估策略

当你的AI代理处理更复杂的任务时，基础的断言可能不够用。

5.1 测试多轮对话与状态管理 如果Agent是有状态的（记得之前的对话），你需要测试状态是否正确维护。这通常需要你编写一个 对话模拟器 ，它按顺序发送一系列用户输入，并检查每一轮Agent的回复和内部状态。

class ConversationSimulator:
    def __init__(self, agent):
        self.agent = agent
        self.context = {} # 或使用Agent自己的上下文对象

    async def send(self, message):
        # 将当前context和message一起发给Agent
        full_response = await self.agent.ask(message, context=self.context)
        # 解析response，可能更新context（例如，提取提到的城市、日期）
        self._update_context(full_response)
        return full_response

    def _update_context(self, response):
        # 简单的规则更新，实际可能用NLU
        if “上海” in response:
            self.context[‘departure_city’] = “上海”

在测试中，你可以这样用：

simulator = ConversationSimulator(agent)
reply1 = await simulator.send(“我想从上海出发”)
assert “上海” in simulator.context.get(‘departure_city’， ‘’)

reply2 = await simulator.send(“去北京”)
# 断言Agent在第二轮回复中，是否利用了第一轮设置的出发城市信息
assert “上海” in reply2 or “出发” in reply2

5.2 使用LLM作为评估器（LLM-as-a-Judge） 对于开放性任务，如“写一首关于春天的诗”，很难用规则断言。这时可以引入一个评估LLM。你可以使用OpenAI、Claude或开源的本地大模型API。

import openai # 或使用其他SDK

def llm_judge(agent_response, user_query, evaluation_criteria):
    prompt = f”””
    你是一个质量评估员。请根据以下标准评估AI助手的回复。
    用户问题：{user_query}
    AI回复：{agent_response}
    评估标准：{evaluation_criteria}
    请只输出一个分数（0-10分）和一句话理由，用‘|’分隔。例如：‘8|回复准确但不够详细。’
    “””
    # 调用评估LLM API
    judge_response = openai.ChatCompletion.create(...)
    score, reason = judge_response.split(‘|’， 1)
    return float(score.strip())， reason.strip()

# 在测试中
score, reason = llm_judge(agent_response, “写一首短诗”， “诗歌需要押韵且有意境”)
assert score >= 7.0, f”LLM评估分数过低：{score}， 理由：{reason}”

注意事项 ：LLM评估成本高、速度慢，且评估者本身也有偏差。 切勿在每次CI/CD流水线中都运行 。建议用于对核心用例进行定期（如每日/每周）的回归测试，或对新发布的模型进行验收测试。同时，评估提示词（Prompt）的设计至关重要，需要反复调试。

5.3 性能与压力测试 使用 pytest-benchmark 或 locust 等工具，模拟高并发用户请求，测试Agent的响应延迟和资源消耗（CPU/内存）。特别是当Agent背后连接了多个外部服务时，需要找出性能瓶颈。

pip install pytest-benchmark

# tests/test_performance.py
import pytest

def test_agent_response_time(benchmark, travel_agent):
    # benchmark fixture 由 pytest-benchmark 提供
    result = benchmark(travel_agent.ask， “查询北京天气”)
    assert result.stats[‘mean’] < 2.0 # 平均响应时间小于2秒

6. 持续集成与测试报告

自动化测试只有融入开发流程才能发挥最大价值。将你的测试套件接入GitHub Actions、GitLab CI或Jenkins等CI/CD工具。

6.1 基础CI流水线配置（以GitHub Actions为例） 在项目根目录创建 .github/workflows/test.yml ：

name: Deepagents Test Suite

on: [push， pull_request]

jobs:
  test:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v3
      - name: Set up Python
        uses: actions/setup-python@v4
        with:
          python-version: ‘3.10’
      - name: Install dependencies
        run: |
          pip install -r requirements.txt
          pip install -r requirements-test.txt # 测试专用依赖
      - name: Run unit and integration tests
        run: |
          pytest tests/ -v --cov=my_agent --cov-report=xml
      - name: Upload coverage to Codecov
        uses: codecov/codecov-action@v3
        with:
          file: ./coverage.xml

6.2 生成丰富的测试报告 使用 pytest-html 生成美观的HTML报告，使用 pytest-cov 生成代码覆盖率报告。

pip install pytest-html pytest-cov
pytest tests/ -v --html=report.html --self-contained-html --cov=my_agent --cov-report=html:cov_html

执行后，会生成 report.html （测试结果详情）和 cov_html 目录（代码覆盖率详情）。你可以将HTML报告发布到内部服务器，或集成到CI的Artifact中供查看。

6.3 测试策略与流水线设计建议

• 快速反馈 ：在每次提交（Push）或合并请求（Pull Request）时，运行 单元测试和集成测试 。这些测试应该快速（几分钟内完成）。
• 定期深度测试 ：在夜间或每周定时任务中，运行 端到端测试和LLM评估测试 。这些测试耗时较长，但能发现更深层次的问题。
• 分级测试 ：将测试用例标记为 @pytest.mark.slow （慢速测试）和 @pytest.mark.fast （快速测试）。在CI中，默认只运行快速测试；慢速测试由定时任务触发。

  @pytest.mark.slow
  def test_llm_judge_evaluation():
      ...
  
  @pytest.mark.fast
  def test_basic_routing():
      ...
  

  在 pytest.ini 配置中管理：

  [tool:pytest]
  markers =
      slow: marks tests as slow (deselect with ‘-m “not slow”‘)
      fast: marks tests as fast
  

  运行命令： pytest -m “not slow” 来跳过慢速测试。

7. 常见问题排查与实战避坑指南

在实际搭建和运行Deepagents自动化测试的过程中，我踩过不少坑，这里总结一下最常见的问题和解决思路。

7.1 测试结果不稳定（Flaky Tests） 这是AI测试中最头疼的问题。今天通过，明天失败，往往不是因为代码错误，而是由于模型的非确定性或外部依赖的微小变化。

• 问题表现 ：基于语义相似度的断言，相似度分数在阈值边缘波动（如0.84 vs 0.85的要求）。
• 排查与解决 ：
  1. 放宽断言 ：仔细审视你的断言条件是否过于严格。对于非关键性描述，相似度阈值可以适当调低（如从0.9调到0.8），或者改用关键信息抽取断言。
  2. 增加随机种子 ：如果测试中涉及随机数（例如，从多个备选回复中随机选择一个），确保设置固定的随机种子，使测试可复现。
  3. 隔离外部依赖 ：确保所有外部API、数据库调用都被彻底Mock。一个不稳定的第三方服务会导致你的测试不稳定。
  4. 重试机制 ：对于确实因网络或外部服务瞬时故障导致的失败，可以为特定的测试用例添加有限次数的重试逻辑（ @pytest.mark.flaky(reruns=3) ），但要慎用，避免掩盖真正的问题。

7.2 Mock过于复杂，难以维护 当Skill很多且交互复杂时，Mock的设置代码会变得冗长和脆弱。

• 问题表现 ：每个测试文件开头都有大段的Mock设置代码，一旦Skill接口变化，需要修改无数个测试文件。
• 排查与解决 ：
  1. 使用Fixture工厂 ：将创建复杂Mock对象的逻辑封装到Fixture中，甚至放到 conftest.py 里供所有测试模块使用。
  2. 使用更高级的Mock库 ：如 responses （用于Mock HTTP请求）或 vcr.py （录制和回放HTTP交互），可以更优雅地处理外部HTTP依赖。
  3. 面向接口测试 ：尽量让Mock只关注输入输出，而不是内部复杂的调用序列。验证“Agent调用了Skill A并传入了参数X”，而不是“Agent先调用了A，又调用了B，然后…”。后者会让测试极其脆弱。

7.3 测试运行速度太慢 尤其是当测试用例很多，或者使用了LLM评估时。

• 问题表现 ：本地运行一次测试需要十几分钟，CI流水线超时。
• 排查与解决 ：
  1. 严格分级 ：如前所述，用 pytest.mark 将测试分级。CI只跑快测，慢测夜间执行。
  2. 并行测试 ：使用 pytest-xdist 插件并行运行测试，充分利用多核CPU。 pytest -n auto 。
  3. 优化LLM评估 ：避免在测试中频繁调用昂贵的LLM API。可以缓存评估结果（对于不变的 (输入， 输出) 对），或者使用更小、更快的本地模型作为评估器。
  4. 使用测试专用模型 ：如果可能，在测试环境中使用较小、较快的模型（如 gpt-3.5-turbo 而不是 gpt-4 ）来运行Agent逻辑，虽然效果有差异，但用于验证核心流程和集成问题通常足够。

7.4 如何设计好的测试用例？ 测试用例的质量直接决定测试的有效性。

• 核心原则 ：测试用例应围绕**用户故事（User Story） 和 业务规则（Business Rules）**设计，而不是围绕代码实现。
• 具体方法 ：
  • 正面用例（Happy Path） ：覆盖主要的、预期的用户交互流程。例如：“用户询问天气 -> 代理返回包含温度和天气现象的回复”。
  • 负面用例（Sad Path） ：覆盖边界情况、错误输入和异常处理。例如：“用户输入乱码 -> 代理应优雅地请求澄清或给出默认回复，而不是崩溃或输出无意义内容”。“询问一个Skill无法处理的问题 -> 代理应承认能力限制，而不是胡编乱造”。
  • 变异测试（Mutation Testing） ：偶尔尝试故意“破坏”你的Agent代码（如修改一个关键参数），然后运行测试套件，看有多少测试能捕获到这个错误。这能有效衡量测试套件的“杀伤力”。

7.5 测试数据从哪里来？

• 手动构造 ：针对核心场景，精心设计一批高质量的测试对话。这是基础。
• 从生产日志中提取 ：在安全合规的前提下，将线上用户与Agent的真实交互日志（脱敏后）作为测试数据的宝贵来源。这能帮你发现那些你没想到的用例。
• 使用LLM生成 ：让LLM基于你的Agent功能描述，批量生成大量的、多样化的测试对话对。但 必须人工审核 ，因为LLM生成的用例可能存在偏见或错误。

搭建Deepagents的自动化测试体系是一个迭代的过程。不要试图一开始就构建一个完美无缺的庞大系统。从一个核心Skill的单元测试开始，到一个简单Agent的集成测试，再到一个核心业务流程的端到端测试，逐步扩展。每当添加新功能或修改逻辑时，把编写相应的测试作为开发流程的必需环节。这样，你才能在这个快速迭代的AI应用开发领域，真正守护好你的“数字员工”的质量与稳定性，让它可靠地为你服务。