Pydantic 工程师 Duncan McKinnon：让编码代理查询自身追踪，把反复失败变成已验证技能

编码代理在后台读取文件、查询数据库、调用工具、编辑代码，而终端外面的人只看到一行"working on it..."。模型调用、工具执行、重试和死胡同都发生在视野之外，没有记录，无法长期反思。Pydantic 工程师 Duncan McKinnon 认为，过程不透明是当前编码代理面临的重大挑战之一，而追踪数据不应只用于被动监控，而应通过 Logfire MCP 服务器让编码代理自身查询历史操作记录，形成从失败证据到技能创建再到实验验证的闭环改进流程。

具体路径分四步。第一步，从追踪中收集证据。McKinnon 发现自己在创建仪表盘面板时反复出现无效查询和返工，于是用 Logfire MCP 搜索编码代理追踪，定位到每个案例中的具体纠正记录，比如某次查询重复计算了缓存输入令牌。第二步，与代理一起识别正确路径并创建技能，把历史成功和失败中的模式编码为可复用的流程。第三步，用相同的代理配置、相同的会话和提示，仅以是否加载技能为变量，运行对照实验。第四步，验证改进是否真正解决了问题而没有引入新问题。

他选了 12 个仪表盘面板创建场景，其中混入了各种错误，在同一个 Codex 代理上分别加载和不加载新创建的 logfire-dashboard-query 技能。不加载技能时，12 次运行中 9 次失败，还出现了格式错误；加载技能后，全部成功，断言通过率从 57/72 升到 72/72，其中 sql_executes 一项从 25% 提升到 100%。

同样的闭环思路也用于代理配置评估。McKinnon 的软件工厂流水线中，审查修复阶段（$43.30）和审查阶段（$36.80）合计约占 $132 总成本的 60%，说明代理在审查和修复之间反复循环。他从追踪中收集了 5 个小型 PR 审查案例，构建数据集，然后在 Claude Code（haiku-5.5）、Codex（gpt-6-luna）和 Cursor（composer-2.5）上运行对照实验，用两个评估标准打分：一是审查是否过度挑剔格式和风格，二是是否遵守指令中规定的编码约定。结果 Codex 在每个面板上得分最高（综合 3.93），Cursor 次之（2.80），Claude Code 最低（2.60）。

这套方法的边界也很清楚。它依赖 Logfire 对特定代理和提供商的追踪捕获能力，成本估算仅覆盖已插桩的调用，实验结论受限于具体任务类型和评估标准的设计。McKinnon 自己说这些示例"并不全面"，但代表了他在团队中看到影响最大的用例。