给AI装上真工具后，为什么"动手前先问一声"根本不够用？

给AI智能体配上工具的那一刻，它才真正变得有用。它能读文件、发消息、调接口、更新记录、触发工作流、生成文档、改动已连接的应用。到这一步，它就不再只是个聊天机器人，而是能改变现实状态的软件。风险也正是在这一刻变了性质。 起初，一条规则听起来很合理：做任何重要的事之前，先问用户。简单、对人友好、往提示词里一加就行。可一旦智能体手里有了真工具，这条规则就不够用了。因为模型现在被要求同时判断两件事：该执行什么动作，以及这个动作是否重要到需要批准。把这两件事塞进同一个推理循环里，等于给了它太大的权限。 问题从一个简单工作流开始 设想一个智能体连着几个业务工具。用户说：把这些客户记录清理一下，然后通知团队。它可能决定去读CRM记录、修改客户字段、合并重复项、删除旧条目、给团队发消息、更新表格。这些动作里，有些无害，有些可逆，有些不可逆。 如果唯一的安全规则是"重要的事之前先问"，那到底什么算重要？只能由模型自己判断。麻烦就出在这里。 "重要"这个词太模糊了 对用户来说，删掉500条记录显然重要。对智能体来说，去掉重复项可能只是常规清理步骤。对开发者来说，把数据发到外部系统也许才是风险点。对安全团队来说，光是访问这些数据本身可能就需要审批。 "重要"这个词划不出可靠的边界，它制造的是解释空间。而恰恰在高影响动作上，我们最该避免的就是解释空间。 模型不该自己决定自己的权限 这是关键的一课。智能体可以决定下一步做什么，但它不该成为"我有没有权限做"的最终裁决者。这是两份分开的责任。 更安全的架构大致是这样：用户请求，智能体提出动作，系统对动作分类，策略层检查权限，需要时由人批准，然后动作执行，最后记录在案。核心在于：批准与否的决定，发生在模型之外。 读、写、破坏性操作不是一回事 一个简单的办法是按影响给动作分类： 读：取记录、查看文档、搜索文件、读取日历数据 写：更新字段、创建文档、发送消息、添加日程 破坏性/高影响：删除数据、撤销访问、对外发布、部署、转账、更改权限 有了分类，系统就能执行具体规则：读，放行；写，放行或视上下文决定是否批准；破坏性操作，必须批准。这比"做任何有风险的事之前请先问一声"要强得多。 提示词是引导，策略才是边界 这个区别很重要。提示词可以写"未经询问绝不删除数据"，这有用。但提示词可能被误解、被遗忘、被上下文覆盖、被做出不同解释。策略层则应该是确定性的。比如删除记录这个调用，直接拦截，要求批准。智能体没有机会去判断删除是否"足够重要"，系统早就知道了。 智能体越强，这件事越重要 弱智能体常常因为完不成任务而失败。强智能体带来的是另一种问题：它能用你没想到的方式把任务完成。这才是真正的转变。智能体在规划和用工具上越强，硬边界就越重要。因为能力在涨，权限不该跟着自动涨。 而且，危险行为未必出于恶意。设想用户说"整理一下这个工作区"，智能体决定归档旧文件、移动文件夹、重命名文档、删除重复项。每一步看起来都在帮忙。但也许有个文件夹依法必须保持原样，也许某份文档属于另一个团队，也许那个"重复项"其实是一份历史副本。它在努力帮忙，但这不代表动作是安全的。 人工批准要出现在对的时刻 批准不该意味着确认每一次工具调用，那体验会很糟。目标是在动作越过有意义边界时插入批准。读数据，不批准；创建草稿，不批准；对外发送，批准；删除，批准；更改权限，批准；部署，批准。这样既让智能体保持有用，又不至于毫无约束。 批准还要说清楚在批什么。别只给用户看"是否批准该动作"，那太含糊。要显示：把这条消息发到工程频道？或者：删除42条归档记录？或者：把这份文档对外发布？用户应该确切知道自己批准的是什么。这意味着批准层需要动作名称、目标、范围、后果，而不只是一个是/否按钮。 智能体该提议，而不是先斩后奏 好的模式是：智能体提议，系统解释，人来批准，工具才运行。而不是：智能体先跑，跑完再解释。这个差别很大。动作一旦已经发生，批准就不再是批准，只是通知。 在构建Xenition的过程中，我们直接撞上了这个问题。Xenition围绕能在真实工具和已连接服务之间工作的AI智能体来设计，而不只是在聊天框里生成文字。这意味着智能体可能需要读数据、创建内容、更新记录、触发工作流、与已连接应用交互、产出真实结果。一旦智能体能真正行动，权限模型就变得和模型本身一样重要。最初的想法听起来很简单：让智能体自己决定什么时候该请求批准。但那依然把太多责任放错了地方。 特别