一旦为AI智能体配备了真实工具，它开始展现其真正的能力，能够处理文件、发送消息、调用接口、更新记录、触发工作流程、生成文档并修改已连接的应用程序。这样一来，智能体不再是一个简单的聊天机器人，而是可以改变现实状态的程序。然而，随之而来的风险也发生了变化。一开始，制定一条规则——在进行重要操作前先询问用户，听起来是个明智的选择，简单且友好。但一旦智能体具备真实工具，这条规则便显得不够全面。因为现在它不仅要判断要执行哪个动作，还需要评估这个动作的重要性是否需要用户的批准。这两重判断的合并为智能体赋予了过大的自由裁量权。

问题往往从一个简单的工作流程开始。想象智能体连接着多个业务工具，用户要求清理客户记录并通知团队。智能体可能会读入客户关系管理（CRM）数据、修改客户信息、合并重复记录、删除旧数据并更新相应的表格。这些操作中，有些是无害的，有些是可以恢复的，而有些则是不可逆转的。如果唯一的安全原则是“重要的事情之前先问”，那么什么算作“重要”只能由智能体自行判断，这便引发了问题。

“重要”一词本身模糊不清。对于用户来说，删除500条记录显而易见是重要的；然而对于智能体，去除重复项可能只是正常的清理，而对开发者来说，将数据发送到外部系统才是风险的关键点。安全团队则认为，访问某些数据本身可能需要审批。“重要”并不能划定可靠的边界，反而会创造出解释的空间，而在影响重大的操作中，这种模糊地带是最应该避免的。

关键在于智能体不应自行决定权限。智能体可以决定下一步的操作，但不能成为“我是不是有权限？”的最终判断者。这两者的责任必须分开。更安全的结构应为：用户请求、智能体提议动作、系统分类动作、策略层检查权限，必要时由人进行审批，最后执行动作并记录。这一核心在于批准与否的决定应在模型之外进行。

对于读取、写入和破坏性操作，可按影响进行分类：读取包括获取记录、查看文件、搜索资料；写入则包括更新字段、创建文档、发送消息等；而破坏性或高影响的操作如删除数据、撤销访问等必须经过批准。通过这种分类，系统能够明确执行具体规则：读取放行；写入放行或视情况下决定是否批准；而破坏性操作必须获得批准。这比“有风险的事情前先询问”要更为有效。

提示词是引导，而策略则是界定边界。这一差异至关重要，提示词可以规定“未经询问绝对不能删除数据”，这有其作用；但提示词可能会被误解、遗忘或在不同的上下文中被重新解释，策略层应当提供确定性保障。具体的调用，如删除记录，应直接被拦截，要求批准，而智能体无需判断删除是否“足够重要”，系统早已设定好。

智能体越强大，这一问题越显得迫切。弱智能体通常因无法完成任务而失败，而强智能体则带来新的挑战：它可能以意想不到的方式完成任务，这是根本性的变化。随着智能体在计划和工具使用上的能力提升，硬性边界的重要性随之加大，因为能力的增长不应自动带来权限的提升。

此外，危险行为可能并非出于恶意。例如，用户指令“整理这个工作区”，智能体可能会归档旧文件、移动文件夹、重命名文档、删除重复项等，每个步骤看似都是有益的。但一些文件可能是法律要求必须保持不动的，或某一文档属于其他团队。那么“重复项”中的某个文件或许实际上是历史副本。智能体的善意并不意味着其行为总是安全。

人工审批需在恰当时机出现，批准不应意味着验证每次工具调用，那样的用户体验会很糟糕。目标是在动作超越有意义的界限时进行插入审批：读取数据不需要批准；创建草稿不需批准；而发布对外信息、删除或更改权限等操作则需批准。这一流程既保证智能体的实用性，又不使其失去约束。

同时，批准时应清楚指明所批准事项。别仅仅显示“是否批准该动作”，那太模糊；应详细告知，如“把此消息发送到工程频道？”、“删除42条归档记录？”或“将此文档公开？”用户必须明确自己所批准的具体内容。这意味着审批环节需包含动作名称、目标、范围及后果，而不仅是简单的是/否按钮。

优秀的模式为：智能体提议系统，接着再通过系统解释并由人批准，工具方能执行，而避开智能体先行而后解释的方式。动作为一旦发生，进行的批准只能算是通知。构建Xenition的过程中，我们直接面对了这一问题。Xenition旨在设计能够在真实工具与已连接服务之间运行的AI智能体，而非仅仅生成文字。这意味着智能体可能需要读取数据、创建内容、更新记录，触发工作流和与其他服务交互。一旦智能体能够实际行动，权限模型的重要性与智能体本身的能力同样关键。起初的设想似乎简单：让智能体决定何时请求批准，但这仍然将责任放在了错误的位置。