execution trace 是什么？
简单说，它是 agent 干活的全程录像。能回放，能暂停，还能在中间某一步伸手改。
上周 arXiv 上挂了一篇讲这个的，系统叫 Vibetrace，建在 OpenCode 上。十六页，十张图，编号我抄下来了，2611.04466。人机交互分类，交叉挂了 AI。
背景就交代这些。
为什么现在冒出来
这半年比的一直是“能跑多久”。谁家 agent 能连着干几个小时不崩，谁就占上风。
方向没错，但漏了一件事。它跑得越久，你越看不懂。
一个人盯着终端里滚动的日志看二十分钟，注意力就散了。这不是人的毛病。日志本来是给机器看的，一行一条，平铺，没有层次，看不出它现在卡在哪一步。等你想插手，它已经往下走了三十步。
所以这篇的定位很清楚：让 agent 更慢、更听你的话，不是更聪明。
作者提了四阶段，观察、理解、干预、演化。四个词念起来很顺。我不太信这种四段式，真用起来大概只有中间两个会被经常碰到。念着顺的东西，通常是写论文时排出来的。
把过程摊开
动作、中间状态、哪一步失败了，都能翻回去看。
点评：能回看和能点，是两件事。日志能回看，不能点。轨迹是把它变成一个可以下手的界面。
从某一步分叉
这条我最在意。
过去的做法是打断，重来。重来的成本不只是 token。你得把上下文重新说一遍，重新建立一次信任，还得默认上一轮全白干了。
从某一步分叉，等于给它一个检查点。前面跑对的留着，你只改错的那一小段。
实现上不轻松。文件改过了，上下文里也塞过东西，要退回某一步，得把这两样一起回滚。想清楚不容易，做干净更不容易。
点评：这不是新算法，是个态度。承认 agent 会走偏，并且承认走偏的那段通常不长。就冲这一条，值得抄。
把轨迹和你的修正提炼成技能
你改得多了，它把这些整理成能复用的东西，下次不用你再说一遍。
点评：这条最容易讲得漂亮，也最容易落空。怎么提炼，提炼歪了怎么办，我在这十六页里没找到让我放心的答案。
那三个数字
SWE-bench Verified 上，用上提炼出来的技能，输入 token 少 23.0%，成本降 15.5%，通过率从 65.0% 到 68.0%。
我不看那个 68。
理由很直白。基准上的三个点，落到一个真实项目里可能一个都摸不着。但 23% 的 token 和 15.5% 的成本是账单上的数，这个骗不了人。
也别当日常账单看。那是 SWE-bench Verified，任务固定，评分自动，不是你手上那个做到一半的半截项目。
一段我没吃透的
作者说做了用户研究，跟传统日志方式比，准确性和效率都有提升。样本多大，任务是什么，怎么算“更准确”，这部分我看得快，没抓到能直接引用的东西。先放在这里，等我回头细读再补。
算不上指控，只是我没看懂。
我真正想说的那句
工具越强，人越容易从操作者变成验收员。过去两年一直在发生。
验收员的问题不在懒，在信息不够。你只在最后看一眼，中间发生过什么完全不知道，出了问题也不知道从哪查起，只能整段推翻。
execution trace 这种东西，本质上是把中间那部分权力还给人。让你在第三步说一句不对，而不是在第三十步从头来。
上半年大家聊的是“可观测”，现在这个词开始往“可干预”挪。一字之差，位置不一样了。看的人站在旁边，改的人站在里面。
对普通人意味着什么
短期用不上。Vibetrace 是个研究系统，不是装得上的插件。OpenCode 开源的，理论上有人能做出来，现在还没有。
能抄的是习惯：别让 agent 一口气跑到黑。
给它切段。每段结束你看一眼，不对就当场说。这个不花钱，比等它跑完再骂它有用得多。
本周就这些。
上面有任何一条你试过、或者觉得我讲错了，欢迎告诉我。讲错的我补，没讲清的我改。
下周见。