精简AI Agent的核心规则库

很多搞AI Agent的人在优化指令集时有个误区：觉得只要某个规则在日志里出现频率低，就可以把它删掉以节省Context空间。我之前差点把29条治理规则给删了，因为它们的命中率几乎为零，看起来完全是冗余的“死权重”。

但实际上，命中率低并不代表规则没用，这里面有两个巨大的逻辑陷阱。

第一是“探测器失效”。你的规则可能是“提交前必须检查测试是否通过”，但如果触发该规则的检测逻辑写错了（比如工具名更新了，或者指令格式变了），那么即使Agent犯了错，探测器也捕捉不到。这时候你的后台显示命中率为0，但这不代表规则不需要，而是它变成了“睁眼瞎”。在我实测时发现，原本以为只有5个失效探测器，实际跑脚本竟然有29个。

第二是“后果不对称”。有些规则负责风格统一，删了顶多是代码难看点，能回头改；但有些规则负责底线，比如“禁止删除生产环境数据”。这种规则可能100次才触发一次，但只要失效一次，就是灾难性的。用频率来决定生死，会让你在追求精简的同时，把Agent推向不可预测的风险。

为了解决这个问题，我把Core层从15条规则砍到了9条，但剔除的标准绝不是命中率，而是将规则分为“可逆建议”和“不可逆红线”。

如果你也在优化Agent工作流，建议参考这个逻辑来审计你的提示词：

• 低频且可逆： 风格、命名规范 → 命中率低可删除
• 低频但不可逆： 数据删除、资金操作 → 无论命中率多少，必须强制保留
• 命中率为0： 先检查触发逻辑是否失效，再决定是否删除

一个简单的审计逻辑可以写成这样：

{
  "rule_audit_logic": {
    "step_1": "Check if detector_signal == 0",
    "step_2": "If yes, run 'synthetic_failure_test' to see if rule triggers on intentional error",
    "step_3": "If rule fails to trigger on intentional error -> Fix detector, NOT delete rule",
    "step_4": "If rule triggers but frequency is low -> Evaluate 'reversibility_score'",
    "step_5": "If reversibility_score == 'low' (high risk) -> Keep rule regardless of hit rate"
  }
}

这种基于风险和有效性的审计，比单纯看数据看板要靠谱得多。