别把 AI Agent 的“鲁棒性”交给运气：构建可观测的执行轨迹

在很多 AI Lab 的交付现场，最令人焦虑的时刻不是模型不聪明，而是它“偶尔”会犯错。

当你向老板演示一个复杂的 Agent 工作流时，它可能连续三次完美运行，但在第四次时突然在某个关键步骤卡死，或者产生了一个毫无逻辑的幻觉。此时，团队最常见的反应是：“奇怪，刚才还好好的，我试着调整一下 Prompt 看看。”

这种通过“微调提示词”来修补随机错误的做法，本质上是在用运气对抗概率。在工程化交付中，鲁棒性（Robustness）不能依赖于 Prompt 的精妙，而必须依赖于可观测的执行轨迹（Execution Trace）。

从“黑盒结果”到“白盒轨迹”

大多数初级 Agent 的设计逻辑是：输入 -> LLM 处理 -> 输出。这是一个典型的黑盒。当输出错误时，你无法确定是哪个环节出了问题：是检索到的上下文（Context）有噪音？是模型在推理过程中跳步了？还是输出格式在最后一步崩溃了？

要实现真正的工程级可靠，我们需要将执行过程拆解为可审计的轨迹：

1. 意图快照 (Intent Snapshot)：记录模型在决定采取行动前的思考逻辑（Thought）。
2. 工具调用证据 (Tool Call Evidence)：记录每个 API 调用的具体参数和原始返回结果。
3. 状态迁移日志 (State Transition Log)：记录 Agent 在不同步骤之间传递的变量状态。

实战案例：一个自动化报告 Agent 的崩溃与修复

我们最近在为一个项目构建一个“每日数据审计 Agent”。它的任务是读取 5 个不同的 API 接口，比对数据差异并生成报告。

崩溃现象：Agent 在处理某些特定日期的数据时，会突然跳过第三个接口的校验，直接给出“无差异”的结论。

传统修复路径：在 Prompt 中强调 “请务必检查所有五个接口，不要遗漏任何一个”。结果：有效率仅为 70%，依然有随机失效。

工程化修复路径：
我们引入了强制性的 Step-Check 机制。Agent 每完成一个接口调用，必须将结果写入一个结构化的 Execution_Log 表中。
- 观察发现：通过查看轨迹日志，我们发现当第三个接口返回 null 或空数组时，模型倾向于认为该步骤已完成且无需处理，从而直接跳过了后续的比对逻辑。
- 精准修复：我们没有修改 Prompt，而是在工具层增加了一个拦截器——如果 API 返回空值且该步骤为必选，则强制触发一个 Empty_Result_Warning 回传给模型。

这次修复后，该环节的成功率提升至 100%。因为我们解决的是状态机缺失的问题，而不是语言表达的问题。

给 AI 工程实践者的三个建议

如果你正在带领团队交付 AI 应用，请尝试将关注点从“如何写好 Prompt”转移到“如何构建证据链”上：

1. 强制要求 Thought-Action-Observation 循环

不要让模型直接给答案。强制它输出 Thought: [思考过程] -> Action: [调用工具] -> Observation: [工具返回]。这不仅是为了提高推理质量（CoT），更是为了在出错时能瞬间定位到是哪个 Observation 误导了模型。

2. 构建“失败快照”库

每当用户反馈一个 Bug 时，不要只记录 Bug 描述，要保存当时完整的上下文快照、Prompt 版本和执行轨迹。将这些失败案例转化为测试集（Eval Set），确保每次迭代都能通过回归测试。

3. 将鲁棒性量化为“覆盖率”

不再使用“感觉挺稳”来描述系统。定义一套关键路径（Critical Paths），统计在 100 次随机扰动测试中，有多少次执行轨迹完整且正确地走完了所有必要步骤。

结语

AI Lab 的交付不是写诗，而是造桥。桥梁的安全性不取决于建筑师对材料的信心（Prompt），而取决于每一颗螺丝钉是否被正确安装并经过验收（Trace）。只有当执行过程变得透明且可审计时，AI Agent 才能真正走出实验室，进入生产环境。