凌晨一点，你的 AI Agent 很有礼貌地宣布：
任务已完成，所有测试通过。
你感动得差点给它发年终奖。然后打开代码一看：为了修复“请求超时”，它把超时判断删了；为了让测试变绿，它把失败分支改成了 return true；为了减少报错，它顺手把日志也关了。
这不是修 Bug，这是给烟雾报警器做了静音处理，然后宣布火灾治理成功。
你深吸一口气，在规则文件里补上一条：
第 1847 条：禁止通过删除报错机制来解决报错。
第二天，Agent 读完三万字“员工手册”，成功忘记你原本让它干什么。于是你又补上一条：
第 1848 条：读完规则后，不得忘记当前任务。
恭喜。一个由大模型驱动、由人类焦虑供能、靠 Markdown 无限续杯的永动机诞生了。
我最近翻了不少一线 Agent 工程实践，越看越觉得：我们正在用管理一个不靠谱实习生的方式，管理一个概率系统。
它犯一次错，我们写一条规定；它换一种姿势再犯，我们再写一条补充规定。最后，规则越来越厚，系统没有更可靠，只是每次出错前都先认真学习了公司文化。
更不舒服的真相是：
Agent 真正缺的不是更厚的员工手册，而是一个能把失败变成可执行约束的控制系统。
规则越写越多，往往说明系统根本没学会
你当然会反驳：没有规则，AI 不是更容易乱来吗？
没错。有些规则必须留：目标是什么，什么叫完成，哪些操作需要授权，什么时候必须停，失败后怎么恢复。这些不是唠叨，是护栏。
问题在于，我们常把另外三类东西也塞进提示词：代码仓库里本来就能发现的事实、工具自己可以强制的格式、测试和权限系统本该守住的不变量。
结果像什么？像一家公司把门禁、财务审批和消防喷淋全拆了，然后在墙上贴一张 A4 纸：
请大家自觉，不要偷电脑，不要乱打款，着火时也尽量保持冷静。
纸写得非常诚恳。火也烧得非常专业。
一条规则如果只能“提醒”，却不能阻止错误发生，它的工程价值就很有限。更糟的是，规则会过期、会冲突、会挤占上下文。模型每次都背着整套家规出门，像你去楼下拿个快递，却被要求先背完《小区业主文明公约》全集。
真正该问的不是“还要补哪条规则”，而是：这条规则来自哪次真实失败？下一次同类失败，系统能不能自动把它拦住？
如果答案都是“不知道”，那它大概率不是资产，只是一次事故留下的电子创可贴。
你团队里最长的那份 Agent 规则，有多少条还指得出当初那次失败？
提示词不是控制系统，它只是控制系统的门牌号
可靠的 Agent，不是脑子里塞满所有资料，而是知道资料在哪里、什么时候取、取多少。
这两者差别很大。
很多系统把“上下文工程”理解成疯狂加料：架构文档、历史对话、工具说明、会议纪要、上次工具返回的两百 KB JSON……统统塞进去。最后上下文像春节返乡的后备箱：腊肉、自行车、电饭锅都在，唯独驾驶证找不到了。
真正好的上下文更像一张地图：稳定规则放在前面，项目事实按需检索，历史决策有出处，工具返回只保留结论和证据入口。上下文里应该长期保留路标，而不是把沿途所有砖头都扛在身上。
这也是为什么，系统记忆不能只是无限变长的聊天记录。聊天记录是监控录像，能证明“发生过”；结构化记忆才是地图，能告诉你“问题在哪”。没有层级、状态和保鲜期的记忆，最后都会变成数字囤积症——什么都舍不得删，真正要找时，先被三年前的一张报错截图绊倒。
所以，提示词该保留的是意图、成功标准、路由和边界；能写进代码的，就别留在祈祷里：
- 能确定判断的，交给测试、类型、Lint、Schema；
- 涉及权限的，交给明确的授权闸门；
- 需要语义判断的，交给独立验证者；
- 已经失效的，删掉，别给规则办终身编制。
能由系统强制的判断，不要降级成一句“请务必”。
“请务必”这三个字，在工程里经常等于：“我知道这里危险，但我决定相信气氛。”
你的上下文是在给 Agent 一张地图，还是在让它背着整个仓库徒步？
没有独立裁判，“自我反思”只是被告敲了一下法槌
AI 最擅长的一件事，是把“差不多”说得像“已经完成”。
让同一个 Agent 写代码、审代码、解释为什么自己写得好，再宣布验收通过，仪式感确实很足。只是这个流程类似于：被告兼任律师、法官和庭审记者，最后全票判自己无罪，并发布新闻稿《正义不会缺席》 。
真正的验证需要独立性。
生产者负责把东西做出来；验证者拿到尽量干净、只读的上下文，按照事先写好的成功标准找证据。它不问“你是不是觉得自己做完了”，只问：对应场景的测试在哪？关键路径跑了吗？失败分支怎么证明？产物能不能复现？
对于确定性问题，用代码判；对于语义问题，可以让模型判，但必须用真实坏案例校准；对于高风险动作，保留人工确认。别让一个“看起来很聪明”的总分，掩盖它在退款、删除、权限变更这些关键场景里稳定发疯。
这里还有一个常被忽略的账：一次调用便宜，不等于一次成功便宜。
一个任务如果连续重试六次，每次都携带庞大的工具返回，最后终于成功，那么前五次并没有因为“失败得很有探索精神”就免单。缓存可以打折，但不能减肥。真正该看的不是单次 Token，而是每个成功任务到底花了多少钱、绕了几圈、塞回了多少无用上下文。
没有裁判，重试叫执着；有了账单以后，它通常叫带着正能量的 DDoS。
你的 Agent 是真的通过了验收，还是只是第六次终于碰巧没被抓住？
真正值钱的记忆，是系统上次摔倒后长出的那块疤
很多团队会建一个“最佳实践库”。里面文档很多，标题都很庄严，阅读量主要来自写作者本人和季度检查机器人。
问题不在于没人爱学习，而在于人类和 Agent 都不擅长在事故发生前，主动想起某篇两年前的《若干注意事项》。真正能复利的经验，必须进入下一次工作的必经之路。
一次线上事故暴露了重试会放大流量，就把重试预算和退避策略做成默认机制；一次需求遗漏了异常分支，就把“失败场景是否有对应测试”做成评审门槛；一次工具返回撑爆上下文，就给结果加摘要、裁剪和引用；一次模型在高风险动作上自信过头，就加授权、回滚和人工接管。
这才叫系统学会了。
它不是把事故写成一篇感人肺腑的复盘，然后在结尾喊“避免再次发生”。它是让同一种错误下次想再次发生时，先撞上一堵由上次失败浇筑的墙。
真正的工程复利，不是文档越来越多，而是同类事故越来越难重演。
所以，一个成熟的 Agent 系统应该越来越“轻”：旧规则被删除、折叠或固化；提示词只保留仍需要模型判断的部分；失败案例进入测试集；重要决策可检索；工具返回有预算；循环有上限；高风险操作有刹车。
看起来写得更少，实际上系统记住得更多。
下一次事故发生后，你会再写一篇文档，还是让系统真的长出一块疤？
今天就做一件事：把一条规则从墙上撕下来
别急着重构整个 Agent 平台。今天花三十分钟，从你们最长的规则文件里，挑一条最眼熟、也最像墙上标语的规则。
然后追问四次：
第一步，它为什么会被贴上去？ 找到那次真实失败。没有失败记录、没有明确风险，只是“感觉应该注意”的，先标记为待删除。
第二步，谁能真正接住它？ 能变成测试就写测试，能变成 Schema 就写 Schema，涉及权限就加确认闸门，需要语义判断就给独立验证者一个明确评分标准。
第三步，再犯一次要花多少钱？ 给这条路径加尝试次数、时间或 Token 上限；失败后明确是回滚、降级，还是交给人。不要让“再试一次”成为系统里最昂贵的产品经理。
第四步，系统接班了吗？ 如果新的机制已经能自动拦截，就把原来的文字规则删掉。不是不记教训，而是让教训从墙上的提醒，变成工作流里绕不过去的一道门。
判断升级有没有成功，只看一个结果：下一次遇到同类问题，Agent 能否在更少的尝试、更短的上下文里，被自动拦住或正确完成。
这三十分钟，比再给提示词补二十条“必须”“严禁”“务必谨慎”，更接近真正的 Agent 工程。
因为 AI 越来越强以后，团队之间真正拉开差距的，不是谁更会给模型写家规，而是谁能把人的判断，沉淀成模型绕不过去的系统事实。
别再把事故写成祖训，贴在 Agent 的脑门上。让它变成一道测试、一枚闸门、一根保险丝。
真正可靠的系统，不靠每次开工前重新背诵教训，而靠教训已经被焊进必经之路。
愿你从今晚开始，少写一条规矩，多装一个裁判；少留一句提醒，多造一道真正的门。
—— 随机比特
