北京
原文刊于 hexisteme notes。 我运行一个名为 stop_decision_ownership_check.sh 的 Stop hook——它会在每次编码会话的 agent 回合结束时执行。它的职责是抓住一种特定失败模式：agent 明明有能力自己完成分析，却把结论抛回给我，以提问代替直接回答。 在这次审计时，这个 hook 的触发条件是两个条件同时成立：一是 agent 的最后一条消息符合“把球踢回给人”的模式；二是它之前的十条转录记录显示，agent 确实先做了数据获取——比如读文件、grep、执行 shell 命令。第二个条件必不可少，因为仅靠消息模式无法区分“真问题”和“甩锅”。同一句话，如果前面跟着真正的调查动作，就是甩锅；如果没有，就是合理提问。 这是我用同样方式构建的七个 hook 之一。但直到最近，我根本不知道它们实际触发频率与运行次数的比例是多少，因为这段代码除了在“阻止回合”这唯一一种结果发生时留下记录外，什么也没写下来。 读者 @xm_dev_2026 的评论把问题说得很尖锐：最便宜的一步，是给 hook 在阻止时已经写入的指纹文件加上时间戳。跑一周，就能知道触发发生在什么时间；但没有缺失的分母，依然算不出触发率。真正的问题是：我是否愿意根据一个已经无仪表运行了好几个月的门禁，再等一周的数据来做决定。 结果，保留的转录记录回答了分母问题，根本不必等。 触发率看起来像典型的指标问题：加个计数器，等，然后读回来。但是，当一个门禁的决策逻辑是确定性的，而它决策所基于的输入又被保留在某个地方时，你根本不需要等新数据。你可以把完全相同的逻辑在旧数据上重放，今天就得到一个反事实触发率，其样本量是实时仪表一周也赶不上的。 这里的缺口，正是那个缺失的分母：我们一直在用直觉回答“这到底多久发生一次”，而答案其实已经藏在旧数据里。
特别声明：以上内容(如有图片或视频亦包括在内)为自媒体平台“网易号”用户上传并发布，本平台仅提供信息存储服务。
Notice: The content above (including the pictures and videos if any) is uploaded and posted by a user of NetEase Hao, which is a social media platform and only provides information storage services.
