北京
本文最初发布于 hexisteme notes。
在我的编码会话中，运行着一个名为 stop_decision_ownership_check.sh 的 Stop hook 脚本。它在每次 agent 回合结束时执行，职责是捕获一种特定失败：代理完成它本可独立完成的分析，却把结论作为问题抛回给用户，而不是直接作答。在这次审计之前，这个 hook 的触发条件是两个条件的 AND 组合：一是 agent 最后一条消息匹配某种“交回”模式；二是它之前的十条转录记录显示，agent 确实先拉了数据——一次文件读取、一次 grep、一条 shell 命令。
第二个条件之所以存在，是因为单独的模式匹配无法区分一个真正的问题和一个“甩锅式提问”。同一句话，如果它前面发生过真正的信息挖掘，就是推诿；如果没有，就是正常提问。这个 hook 是我在会话中构建的七个同型 hook 之一，然而直到最近，我对它们实际触发的频率毫无概念——因为代码除了在阻断该 turn 的那一种结果外，什么都没写。也就是说，没有计数器记录它运行了多少次、又击中多少次。
一位读者 @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.
