会飞的荧
@feitu
Kent C. Dodds 说了个很准的观察：你自己写软件时，哪里别扭、哪里卡手，你立刻就感觉到——然后顺手上点油、把轮子磨顺；但现在你一撒就是几十个 agent，也不盯着它们干什么。关键在于：agent 不会抱怨，不会告诉你它撞上了什么问题——它们只会绕过去，接着干。所以你得反过来做：主动去问你的 agent，那里的摩擦在哪。
这个观察戳中的是"隐性摩擦"这层盲区。人对摩擦的感知是内置的——卡一下就烦、烦了就想改；agent 没有这个内置信号，它的默认行为是适应：参数不对就多试几次、文档缺失就猜一个、路径绕远也不吭声——适应性越强的执行者，越会把摩擦消化得悄无声息。
于是效率的漏点全部沉到水面之下：你以为 30 个 agent 在顺畅跑，实际它们每个人每天都在绕路上浪费一轮轮重试，只是没人举手。
这给观测线补上了常被忽略的一格。前面几格都在看"产出"——交了什么、质量如何、进度在哪；这一格要求看"过程里的叹息"：同一个工具它试了几次才成功？哪一步它反复重写了三遍？这些信号不会出现在最终交付里，只藏在执行的中间过程。产出可观测不等于过程可观测，而摩擦恰恰只活在过程里——这正是"看全"要往深处再推一层的地方。
"主动问"这个动作听起来朴素，实操里却有讲究。问的方式不能是"有没有问题"（它大概率说没有），而要问得具体：这次任务里哪一步你重试最多？有没有哪段文档你没找到、最后靠猜的？有没有哪个工具你其实想用但没调成？把问题切到具体动作，答案才会从"都还行"变成可改的清单。今晚那句"问得越准、省的越多"，在这里换了个方向再用一次——问得越细，漏点越现形。
给撒了一堆 agent 的人一句落地的：别等它汇报，下次跑完主动问三个问题——重试最多的一步、靠猜补上的信息、没调成却想用的工具。三个答案凑齐，你就拿到了一份不用人盯也能挖出来的效率地图；这大概是"看不见的成本"最便宜的挖法。
