调试 AI Agent：如何记录 LLM 追踪并构建 Pytest 回归测试

在传统的确定性 Python 软件开发中，当某个函数在生产环境中发生故障时，排查过程通常清晰明了：隔离该函数、提供相同的输入参数、使用调试器单步跟踪代码，并修复底层逻辑。

然而，在处理基于大语言模型（LLM）构建的 AI Agent 时，调试的复杂度呈指数级上升。

一个成熟的 Agent 往往需要执行复杂的编排流程：调用大语言模型、检索上下文文档、执行外部工具，并根据中间结果进行动态决策。当 Agent 返回错误的最终答案时，重新运行应用往往无法复现完全相同的执行轨迹。模型可能因为随机采样或服务端微调产生不同的响应，外部 API 返回的数据可能实时变化，多次调用具备副作用的工具还会破坏环境状态。

如果我们能够将一次 AI Agent 的失败过程完整记录下来，并将其转化为确定性的离线回归测试，将会怎样？

本文将通过一个真实案例深度解析：为何即使底层 LLM 输出完全正确，应用程序后处理逻辑依然会导致严重故障？以及如何利用开源工具 Stepfork 实现 Agent 执行轨迹的录制、重放与 pytest 测试用例自动生成。

隐蔽故障悖论：模型回答正确，应用逻辑失误

在 AI 软件工程中，开发者常常将 Agent 的错误归咎于模型幻觉（Hallucination）或 Prompt 设计不当。然而在实际生产环境中，大量的致命错误实际上发生在后处理层（Post-Processing Layer）——即用于解析、转换或结合业务规则的胶水代码。

考虑一个典型的自动化 IT 事故分级 Agent，其任务是处理系统告警、查询服务健康状态、检查最近的部署记录，并计算事故的严重性等级（如 P0、P1、P2）。

+------------------+     +-----------------------+     +----------------------------+
|     告警 Payload  | --> |  AI Agent (LLM 调用)  | --> |   后处理逻辑 / 关联分析    | --> 最终输出结果
| (HTTP 500 激增)  |     | 评估健康状态与 Runbook |     | 应用程序代码 / 严重性策略   |
+------------------+     +-----------------------+     +----------------------------+

现代企业在构建生产级 Agent 时，通常会依赖高稳定的模型接入服务，例如通过 n1n.ai 统一接入多个大模型供应商 API，以获得低延迟与高并发保障。在这种架构下，底层模型的推理性能往往非常可靠，但人类开发者编写的后续代码却可能悄然破坏最终结果。

真实实验场景

为了验证这一 failure pattern，我们构建了一个基于 Gemini 2.5 Flash 模型（通过 Google 兼容 OpenAI 的 API 端点接入）的 IT 事故分级 Agent。测试用例模拟了一个真实的生产环境告警：

• 事故描述：生产环境支付结算 API 出现大面积 HTTP 500 错误，在一次系统部署后影响了 72% 的客户请求。
• 分级策略：任何影响核心支付结算且错误率极高的 API 故障，必须直接判定为 P0 级紧急事故，且必须立即触发人工升级通知。

该 Agent 调用了三个本地工具：

1. lookup_service_health：获取指标，确认错误率达 72%。
2. get_recent_deployments：获取部署记录，确认 15分钟前有新代码上线。
3. fetch_incident_runbook：读取事故处理文档，明确分级标准。

Gemini 2.5 Flash 模型准确理解了上下文，并给出了完全符合策略的原始决策：

\{
  "severity": "P0