给 Agent 开放了代码执行和文件读写之后

一、前几个工具都很轻松

给 Agent 加工具的时候，前几个都很轻松：搜索、算数、查网页 —— 最坏的结果也就是答错。 真正让我停下来想了很久的是这三个：执行代码、读写本地文件、控制浏览器标签页。 它们的共同点是会产生副作用，而且不可逆。模型判断错了不是回答错误，是文件被覆盖了、脚本被执行了。 第一版我的做法很天真：在提示词里写清楚什么能做什么不能做，然后相信它。大部分时候确实没问题。问题是「大部分时候」这个词 —— 有些事情我要的不是大部分时候，是每次。

二、建议层和约束层要分开

提示词是建议，代码才是约束。这两层要分开设计。 建议层负责让越界变得少见：工具描述里写清楚适用场景和边界，让模型在正常情况下就不会想去碰。这一层做好了能挡掉九成。 约束层负责让越界不可能：路径白名单在代码里、危险操作需要显式确认、执行环境限定作用域。这一层不参与推理，它就是一段必然执行的检查，不通过就返回失败。 两层的分工是：建议层降低概率，约束层兜住后果。混着做的结果是两头都不硬 —— 提示词写太死会让模型畏手畏脚，代码检查写太松等于没写。 还有一条是我吃了亏才加的：执行者和验证者必须分开。一开始我让同一个流程既改文件又检查改得对不对，它报告的结果就不可信 —— 因为它有动机把自己做过的事说成没问题。

三、护栏是为了让我敢放手

这套东西做完之后，我反而敢开更多工具了。 以前不敢，是因为每加一个工具，我的心理负担就重一层，得盯着它别干傻事。现在边界在代码里，越界会失败而不是造成损失，我不需要盯。 换个说法：约束不是为了限制 Agent，是为了让我敢放手。没有护栏的时候，我只能给它一些无关紧要的工具；有了护栏，危险的工具反而可以开。 这个结论在别的地方也成立。任何时候你发现自己在「盯着」某个自动化流程，真正该做的不是盯得更紧，是去想哪一层护栏没建起来。