Retrace

Retrace 会在一次运行中把每个 LLM 调用、工具调用和错误都记录成 trace 里的一个 span。你可以像拖拽视频一样，逐步回放过往的运行过程。找到出问题的那一步后，你把它 fork 出来，在那一点修改输入或模型，智能体会从那开始重新执行，这样就能并排对比原始路径和新路径。

我最看重的是 fork 这个功能：它更像 git branch，而不是重新跑一遍 prompt。fork 之前的步骤从记录里回放，后面的一切都实时运行。

这个产品还很早期，我特别想听听你的反馈——尤其是回放和 fork 的流程，还有怎样才能更适合你的技术栈。你目前用的是哪些框架或服务商？有任何问题欢迎在这里问。

终于有办法真正看到智能体背后在干什么了。回放功能帮我省了大量时间，弄清楚为什么一个工具调用陷入了循环。

像 git 分支一样 fork 一次运行，这才是智能体调试该有的样子。仅仅回放很少能帮上忙，特别是当问题来自十步之前某个奇怪的工具响应时。

我还看了你在论坛上关于区分真正回归和提供商噪声的帖子——很高兴看到把非确定性当成了一个一等问题来处理（首次分歧对比+判定），而不是轻描淡写地忽略。

不过有一点我没找到：当 fork 之后的所有下游都实时运行时，智能体的工具调用真的会实际执行吗？

我做的智能体有真实的副作用（结账、支付、邮件），如果能在记录中模拟那些调用，那就是“可以安全 fork 生产运行”和“不行”的区别。

终于有东西让我真正看到智能体为什么出错了，而不是翻日志。回放视图几秒就抓到了一个工具调用循环，超级好用。

祝贺发布。从记录里回放工具调用而不是重新执行，这是正确的默认做法，光这一点就让它超过了我见过的大多数自制回放脚本。在把它用到客户项目之前，我需要确认一个问题：我的工具参数和提示经常携带像 bearer token 和客户邮箱之类的内容，那么当 trace 被存储或分享给队友时，Retrace 会对这些内容做脱敏处理，还是 span 原样保留所有信息？在 SDK 层面做脱敏处理会是付费版一个真正的卖点。

首次分歧方法暴露了我在自己智能体框架中遇到的一个输入侧问题：框架本身嵌入在 prompt 里的易变 token（时间戳、运行 ID、采样示例）导致每次重放都在第一步就看起来产生了分歧，远在真正的回归测试之前。我的解决办法很粗暴：完全禁止编排层内的挂钟时间和随机性（时间作为参数注入），这样重放从构造上就是字节稳定的。我很好奇 Retrace 在这条线上怎么划分——计算首次分歧时，你们会标准化/遮蔽已知易变的片段，让时间戳差异不构成分支点吗？还是建议像我一样让上游框架变得确定性？如果是遮蔽，遮蔽列表能否按项目配置？这感觉就像你信任的 diff 和你学会忽略的 diff 之间的区别。