先说结论：AI 写的代码翻车，先别急着骂它笨。把它走过的每一步调出来看一遍，大概率会发现它不是全程都在瞎搞，而是从某一步开始跑偏的。最近 Pydantic AI 团队写了篇文章，讲怎么用 Logfire 把编码智能体的模型调用、工具调用、请求响应全部记录下来——说白了，给智能体干活的每一步都留痕。
先交代背景：Pydantic AI 是个 Python 编码智能体框架，Logfire 是同一团队做的可观测性平台，一个管「干活」，一个管「录像」。这篇文章讲的，就是拿这套录像设备对着 Claude Code、Codex、Cursor、Copilot 这类编码智能体——平时让它干活，翻车的时候回头把录像一帧一帧放出来看。
智能体翻车，通常是哪一步
智能体翻车的现场，一般长这样：它改了一堆文件，测试崩了，或者生成的东西跟需求完全两码事。这时候最直觉的反应是「这模型不行」。但编码智能体干的是多步活儿——读文件、改代码、跑命令、调工具，每一步的输出都变成下一步的输入。前面某一步走歪了，后面再聪明也拉不回来。
难点在于，平时你根本看不到中间过程。界面上只给你一个最终结果：要么跑通了，要么报错。这就像调试一个只有入口和出口的黑盒，中间发生了什么全靠猜。所以很多「智能体不聪明」的吐槽其实站不住脚——你连它到底哪一步错了都不知道，直接判它死刑，对它有点不公平。
Logfire 做的事，就是把黑盒打开。作为可观测性平台，它记录智能体每一次模型调用、每一次工具调用的完整轨迹：哪一步查了什么、调了哪个工具、返回了什么，全都在这条线上排着队。翻车的时候你不用猜，沿着线往回走，找到最早不对的那一格就对了。
轨迹里能挖出什么
轨迹数据看着像流水账，信息量其实很大。模型调用这一层，你能看到每次发给模型的输入是什么、模型回了什么，判断它是不是从某次调用开始理解错了任务。工具调用这一层更直接：调了哪个工具、参数传了什么、返回了什么，哪一步传错参数、拿了错误结果，基本一眼就能定位。
关键能力是对这些数据执行查询。翻车了不用从头到尾肉眼看，直接按条件查：把某次任务里所有失败的调用拉出来，或者把某个文件的修改记录筛出来。定位「哪一步开始跑偏」，靠查询比靠翻原始日志快得多，也更不容易看花眼——记录多的时候，人肉翻真的会翻到怀疑人生。
复盘的顺序可以借鉴这个思路：先查失败和重试的调用，再看耗时明显异常的，最后重点看关键文件被谁改了、改成了什么样。轨迹是只读记录，它不干预智能体干活，但复盘的时候，它比任何人的口述都诚实——它不会忘记，也不会掩饰。
让它自己查自己
这方案里最有意思的一点在这：Logfire 提供了 MCP 服务器，你可以把它接到智能体那边，让智能体自己对轨迹数据执行 SQL 查询。什么概念呢？翻车之后，你不用自己写查询语句，直接问它「你刚才哪一步出了问题」，它自己去翻自己的调用记录，查完把结果讲给你听。
这操作有点门道：不是人替它复盘，是它自己复盘自己。相当于给智能体配了面镜子——干完活回头看录像，自己说说哪步走歪了。当然，它查自己有没有水分、找到的原因对不对，还是得你来判断，但起码省掉了人肉翻日志这一大圈，你只管当裁判。
对做编码智能体的人来说，这个方向值得留意：智能体不只负责干活，还负责解释自己为什么这么干。把解释能力接进日常工作流，出了问题的定位成本会低不少，尤其是一个智能体连续跑了一整天、全程没人盯着的那种场景。
厂商方案，留个心眼
留个心眼的时候到了。这篇内容出自 Pydantic AI 官方博客，而 Logfire 是他们自家的可观测性平台——等于自己出考题，自己批卷子。方案逻辑本身讲得通，但你得清楚一件事：轨迹数据最终都存在 Logfire 平台上，你的代码调用记录、工具调用细节，全都进了别人家的系统。
企业里用的话，这条得提前想明白：敏感代码走不走这个平台？数据落在哪？能不能导出、能不能自己部署？这些在签约之前就该问清楚。对开源项目或者纯内部实验就无所谓，先用起来看实际效果，最实在。
工具这东西，方向对就先用起来，但别把「全留痕」当成万能药。轨迹能告诉你哪一步跑偏了，至于为什么跑偏、下次怎么防，还是得回到具体任务本身去看。录像拍得再清楚，演员演技不行，片子也救不回来。
