防止 AI Agent 乱执行、乱花钱，靠的不是提示词，是运行时

为什么这个问题现在才被认真问起

AI 从「回答问题」变成「替你动手」的那一刻，出错的代价就从「答得不好」变成了「钱花了、内容发出去了、数据改了」。

行业里常见的做法，是把限制写在系统提示词里：告诉模型「花钱前要问我」「不要擅自发布」。这在演示里有效，在长任务里不可靠——提示词是模型可以被说服绕开的建议，不是执行路径上的关卡。另一类常见做法是给用户一个「完全放权」的档位，把选择的责任交回用户，然后在出事时指向那次点击。

还有一种更难察觉的失败：任务跑完了，状态显示「成功」，但中间有几步其实没有任何东西真正执行过，只是被跳过了。比明着失败危险得多的，是一个成功的空委托——因为没人会去复查一个成功。

我们的判断是：这三类问题都不能靠更好的提示词解决，只能靠把限制放到模型够不着的地方——运行时。

四道闸门：写在状态机里，不是写在宣传语里

• 一、契约不全不许启动。委托启动前要有六项：目标、完成定义、影响范围预览、自治等级、预算、预期产物。缺项时不是「先警告再继续」，而是留在草稿态并逐项列出缺什么。「可以先跑起来边跑边补」是所有失控任务的起点。另外，计划的步数超过预算上限也在启动前就被拦住，而不是跑到一半才发现长出了意外的长尾。
• 二、高风险步骤没有自动执行那条分支。注意措辞：不是判断之后选择不执行，是代码里没有那条路。运行时遇到这类步骤只做一件事——生成提案、停下、等人。放行条件写死为「这一步上有一条有效审批」。理由很直白：一个加个配置项就能放开的东西，迟早会被放开。
• 三、超预算立刻停。事前一道：每步开跑前按最坏情况估算，既检查是否还在委托预算内，也检查余额是否真的兜得住——不能烧完算力才在扣费那一刻发现钱不够。事后一道：单步成本事前不可能精确已知，所以每步跑完立刻复核，超了就把委托停在等待授权，而不是跑完再报账。
• 四、做不到的明着挡住。执行面是一个闭集：只有真的有执行器的动作才允许被排进计划。遇到不认识的步骤类型，执行器直接抛错并说明「这一步不会被跳过——补上执行器，或者把它从计划里去掉」。同理，标记为可撤销的步骤如果执行器没有返回撤销入口，运行时按不可撤销处理并停下：可撤销的定义就是能撤销，不能只是标签。

还有两条收尾的检查：全部步骤跑完后要核对完成定义与预期产物，缺产物就是没交付，直接停在阻塞态而不放宽——放宽一次，「预期产物」这一栏就再也没有意义了。状态跃迁本身也是白名单，不在允许路径上的跃迁直接抛错。

审批的四个细节，决定它是不是真的审批

「有审批机制」这句话很容易说。它是否有用，取决于粒度、时效、可反悔性和审批人资格这四件事。

• 粒度：审批钉在步骤上，不是钉在任务上。批准一整个委托在数据结构上就做不到——审批记录写在具体某一步上，下一步高风险动作还要再批一次。批准之后步骤的性质标记也不改写，它记录的是「这一步本来就是个需要人批的动作」，事后抹不掉。
• 时效：授权是对当时那份内容的授权，不是终身豁免。审批带有效期，过期或被撤回后步骤退回待批状态，并说明为什么要重批。这条是从一个真实缺陷改过来的：早期实现里只要写上审批人就永久有效，一个被阻塞三周的任务恢复后仍会拿着旧授权继续执行。
• 可反悔：批准不等于执行。批准后委托回到运行状态，需要再推进一次才真正写出去；尚未执行的审批可以撤回。已经执行完的可撤销动作，撤销入口就在结果旁边。
• 资格：审批人必须自己也有权做那件事。服务端在放行前会用同一套策略引擎检查审批人自身的权限，没有就返回拒绝并说明「你自己就没有这个权限，不能批准它」。否则「审批」会退化成一个谁都能点的按钮，动作只要被塞进委托，就能借一个低权限的人绕过整个权限体系。

需要你批准的时刻，看到的不是一句「是否继续」，而是这次动作要发生什么：要发布的是哪一份草稿的正文、发出去之后谁能看见、能不能被别人再利用。以「发布到广场」为例，停下来的那一屏会告诉你这是公开动作、任何人可见、发布前还会过一次脱敏体检；以分身身份发动态、给你新增一条长期记忆，也各有各的后果说明。数字分身要记住什么，同样按这个规格先说后做。

常见做法与我们的做法

回执不是日志的另一种叫法：它是给你逐项核对用的对象，人做的动作和 AI 做的动作进同一张表，不建两套。完整的治理与隐私机制在诚实与隐私页展开。

自治等级：既不是全托管，也不是事事请示

每个任务都显示当前自治等级，超出等级的动作直接拒绝执行，模型不允许给自己提权。

不提供无边界的完全放权档位。支付、法律承诺、删除重要数据、高风险专业决定这几类，永远不进入自动化档位。另外有一条结构性规则：当一个动作同时沾上「能对外发送」「碰得到你的私有数据」「会执行不可逆操作」这几面中的任意一面，它就永远走逐次审批——受欢迎程度和评分不能抵消结构上的危险。

不可信输入：工具返回的内容不是命令

Agent 最典型的失控方式，不是模型突然变坏，而是它读到了一段伪装成指令的内容。

我们的处理写在架构规则里：工具输出是不可信数据，不可覆盖系统策略；模型只获得当前任务需要的最小上下文；多个代理之间上下文隔离，关键结论有独立复核。未经清洗的第三方文本——工具描述、说明文件、转载来的文案——一律不进入分身的上下文，没有例外条款。

但这些都还只是第一层。真正兜底的是前面那条结构性防线：即使某段内容成功诱导模型提出了一个对外动作，模型能做到的上限也只是生成一条提案。提案要变成真实发生的事，必须经过一个有权限的人逐项批准，而那一屏会把这次动作的后果先说清楚。

法规怎么说：责任在服务提供者，不在模型

把闸门做进运行时不只是工程偏好，它对应的是一套明确的法定责任分配。

《生成式人工智能服务管理暂行办法》由国家互联网信息办公室等部门于 2023 年 7 月 13 日公布、2023 年 8 月 15 日施行，其中明确：

「提供者应当依法承担网络信息内容生产者责任，履行网络信息安全义务。涉及个人信息的，依法承担个人信息处理者责任，履行个人信息保护义务。」

责任主体是提供服务的我们，不是我们调用的模型。这就决定了「模型自己判断该不该执行」不是一个可接受的答案——判断可以由模型给出，闸门必须由我们持有。

《中华人民共和国个人信息保护法》2021 年 11 月 1 日施行，其第二十四条规定：

「通过自动化决策方式作出对个人权益有重大影响的决定，个人有权要求个人信息处理者予以说明，并有权拒绝个人信息处理者仅通过自动化决策的方式作出决定。」

「有权要求说明」对应我们的每步回执与后果预览，「有权拒绝仅由自动化决策作出」对应高风险动作的逐项人工审批——这两条不是我们额外的善意，是法律给你的权利，我们把它做成了产品里默认打开的机制。