8.0
热点
AI SCORE
技术实践2026-08-14 14:00
AI Agent 测试方法论：从单元测试到混沌工程
dev.to · AI#AI Agent#测试#工程化
Editor brief · 编辑速览
提出 Agent 工作流测试应超越 LLM Eval 的结果导向，关注轨迹正确性；给出从确定性工具测试到随机性多 Agent 混沌工程的渐进式测试成熟度模型。
标准 LLM 评估为什么对多步骤 Agent 不起作用？因为它们关注的是终点，而非过程。
一次评估通常问的是："Agent 给出了正确答案吗？"这是回答质量测试。而测试问的是："Agent 是否遵循了正确的逻辑得出答案，且在此过程中没有违反任何约束？"这是工作流正确性。
当你把 Agent 当作黑盒来处理时，你会错过"静默失败"。一个 Agent 可能因为一次幻觉的工具调用恰好返回了一个幸运的字符串而意外得到正确答案。在生产环境中，这是一颗定时炸弹。你必须把 Agent 当作分布式系统来对待——它们有状态，有网络依赖，而且有漂移的倾向。
我们正在从静态提示词的世界走向系统性编排。如果你读过我们关于 Agentic 工作流"崭新的一天"的文章，就会知道规模化需要从实验脚本走向工程系统。这种转变从验证系统开始。
你的 Agent 真的能说你的 API 的语言吗？大多数 Agent 失败不是发生在"推理"阶段，而是发生在接口层。
第一道防线是对工具调用进行确定性单元测试。测试工具 schema 是否正确，你不需要 LLM。你需要验证的是 Agent 输出是否匹配目标 API 的预期 JSON schema。
以一个部署客户支持 Agent 的 FinTech 团队为例。这个 Agent 与遗留银行 API 交互。如果 Agent 传递了一个字符串，而 API 期望的是整数类型的账户 ID，系统就会崩溃。更糟的是，如果 Agent 幻觉出一个参数如 bypass_authorization=true，那就成了一个巨大的安全漏洞。
你应该实现专门针对这些失败模式的测试：
Schema adherence：使用 Pydantic 或 Zod 验证每个工具调用都包含必需字段且类型正确。
Tool hallucination：创建一套测试提示词，专门用来诱使 Agent 调用其提供的工具集中不存在的函数。
Constraint validation：确保 Agent 无法传递超出业务逻辑限制的值，比如超过 $10,000 的转账金额。
def test_banking_tool_schema():
# Mock agent output for a fund transfer
agent_output = {
"tool": "transfer_funds",
"parameters": {
"amount": "500", # Should be int
"destination_account": "ACC123"
}
}
# Validation logic
try:
validate_schema(agent_output, BankingSchema)
except ValidationError as e:
# This is where we catch the schema mismatch before it hits the legacy API
log_failure(f"Schema mismatch detected: {e}")
assert False
而且你必须处理恢复逻辑。当 schema 不匹配发生时，系统不应该直接崩溃。它应该把错误反馈给 Agent："Error: 'amount' must be an integer. Please correct the call."
你如何知道一个 Agent 不会在自己的推理中迷失？单轮测试对工具很好，但 Agent 是跨轨迹运行的。
Agent 的集成测试意味着验证从用户初始意图到最终目标状态的路径。这正是你遇到"状态漂移"的地方。一个 Agent 开始帮用户重置密码，但在三轮 API 错误之后，它忘记了原始目标，开始解释密码哈希算法的工作原理。
为了解决这个问题，我们使用 Golden Datasets。这些是精心整理的（输入，预期轨迹，预期结果）配对。你不期望 Agent 每次都产生完全相同的 token，但你确实期望它能命中相同的"里程碑"工具调用。
想象一个使用多 Agent 集群的 HR 团队。Agent A 收集员工数据；Agent B 将其综合成报告。你需要测试交接。如果 Agent A 没有在元数据中包含"员工 ID"，Agent B 就无法综合报告。这是一种级联失败。
你还需要检测"无限循环"。当 Agent 因为工具输出不满足其内部条件而反复用相同参数调用同一工具时，就会发生这种情况。
为了防止这种情况，你的集成测试应该标记任何超过最大轮次数或重复同一工具调用签名超过两次的轨迹。对于构建复杂集群的人，我们建议研究 Agent Mesh 架构来标准化这些交接。
你的 Agent 在实际运行时安全吗？部署前测试是必要的，但还不够。你需要运行时护栏。
Guardrails 是在执行循环中运行的测试。它们充当 Agent 推理与系统执行之间的防火墙。
一个关键模式是"Sandbox"。如果你在构建一个可以重启服务器或修改安全组的 DevOps 修复 Agent，你不能只信任 LLM。你必须将工具执行包装在一个沙盒中，验证拟议的更改是否通过策略引擎。
例如，如果 Agent 提议执行 terraform destroy，护栏应该拦截它，检查环境（生产 vs. 预发布），如果环境是生产环境，则触发人工审批。
你还应该监控"静默失败"。这些是 Agent 推理循环继续但不再向目标取得进展的时刻。Trace 分析是发现这些问题的唯一方法。通过分析 Agent 执行的 span，你可以识别逻辑在哪里偏离了预期路径。
如果系统检测到关键漂移，它应该触发确定性故障转移。我们在讨论 T-Mobile 宕机和"SOS Mode"确定性时已经详细阐述过。
既然你可以主动破坏系统，为什么还要等到它在生产中崩溃？
一旦你掌握了单元测试和集成测试，就进入了混沌工程。在传统系统中，这意味着杀死 pods 或引入网络延迟。在 Agentic 系统中，这意味着注入"认知"失败。
你应该在 Agent 及其工具之间实现一个混沌注入层。这个层允许你模拟：
API Latency：Agent 是超时重试，还是因为等待太久而幻觉出一个响应？
Synthetic Failures：当一个工具返回 500 错误时会发生什么？Agent 是尝试不同的策略，还是进入无限重试循环？
Hallucinated Tool Outputs：注入一个语法正确但逻辑上荒谬的响应。这测试 Agent 对接收到的数据进行"合理性检查"的能力。
目标是发现级联失败。在多 Agent 集群中，Agent A（数据收集者）的一个小幻觉可能导致 Agent B（决策者）的关键逻辑错误。如果 Agent A 报告服务器"健康"而实际上它处于"降级"状态，Agent B 可能会决定忽略一个关键警报。
通过有意注入这些错误，你可以设计恢复循环。一个有弹性的 Agent 不应该只是失败；它应该识别失败并转向。"数据库正在返回意外格式；我将尝试使用备用 API 获取数据。"
对于管理大规模 Agent 集群的人来说，这种级别的弹性是在流量峰值期间防止系统全面崩溃的关键，正如我们在 NFL 季前赛压力测试中看到的那样。
你的团队如何从手动抽查走向生产就绪的流水线？遵循一个成熟度模型。
大多数团队从 Level 1 开始。他们给 Agent 提示词，看它是否工作，然后调整提示词。这是"基于感觉的开发"。对于原型来说还好，但对于企业产品来说是危险的。
Level 1: Manual Spot-checks
成功定义是"看起来没问题"。
提示词或数据集没有版本控制。
Level 2: Deterministic Unit Tests
每个工具都有 schema。
工具调用都经过类型和必需字段验证。
基本的"快乐路径"测试已自动化。
Level 3: Trajectory & Regression Testing
使用 Golden Datasets 跟踪随时间变化的性能。
监控状态漂移和无限循环。
回归测试确保新提示词不会破坏旧工作流。
Level 4: Automated CI/CD with Guardrails
Agent 在部署前的流水线中进行测试。
运行时护栏防止破坏性操作。
所有工具执行都使用沙盒环境。
Level 5: Continuous Chaos Engineering
在类生产环境中注入合成失败。
可观测性 trace 推动推理引擎的迭代。
系统设计为优雅降级和确定性故障转移。
Agent Testing Maturity Model. Compare the trade-offs between different testing levels as an agentic workflow moves toward production readiness.
但请记住，你不能一夜之间从 Level 1 跳到 Level 5。如果你试图在还没有基础 schema 验证的情况下实施混沌工程，你只会被噪音淹没。从工具开始，移到轨迹，然后破坏系统。
而且不要陷入"更多数据"能解决可靠性问题的陷阱。你无法通过提示词摆脱结构性架构故障。可靠性是框架的产物，而非模型的产物。
Include a detailed markdown table comparing Traditional API Testing vs. Agentic Testing
Add a 'Call to Action' asking developers how they handle non-deterministic failures
For further actions, you may consider blocking this person and/or reporting abuse