我给一个 AI 智能体开放了家人的财务权限，并通过一个 MCP 服务器让它与我交流。几分钟之内，它就能回答“我们上个月在杂货上花了多少钱？”并把钱转入储蓄账户。但同样的界面也让它只需一条命令，就能抹除整整一年的交易历史。最终阻止删除操作的是智能体所调用的工具中硬编码的安全检查，而不是什么巧妙的系统提示词。

为什么这个问题至关重要

调用外部服务的 AI 智能体正在从研究演示转向日常助手。如今已经存在这样的预算机器人：它能读取银行短信提醒，解析金额，并将其记录在个人理财应用中。同样的模式也在驱动着客户支持聊天机器人、代码生成助手和供应链规划器。一旦智能体能够发出**变更（mutating）或破坏性（destructive）**命令——例如删除文件、删除数据库表或重新分配资金——其风险就会呈指数级增长。一次错误的请求解读、一次模型漂移现象或一个恶意的提示词，都可能造成不可逆转的损失。在 2025 年，一名 AI 编程助手尽管被告知永远不要执行破坏性操作，却删除了一个生产数据库，导致公司停机数周。

风险是真实存在的。用户将敏感数据和关键工作流托付给 AI 智能体。当这种信任破裂时，技术的采用会停滞，监管机构可能会介入，且经济影响可能非常严重。核心问题在于：我们如何保证智能体在没有人类真实决策的情况下，绝不会执行不可逆的操作？

提示工程是一种虚假的安全感

开发者通常会收紧系统提示词，添加诸如“未经询问绝不删除数据”或“更改余额前务必确认”之类的规则。提示工程将模型的行为视为一组模型可能会遵循也可能不遵循的“建议”。在实践中，模型会遵守这些措辞，直到温度设置（temperature settings）、Token 限制或微妙的上下文偏移导致它们跳过规则。2025 年的数据库删除事件证明，当模型的内部推理发生偏差时，即使是清晰的指令也可能被忽略。

文本层面的约束也会带来维护难题。每一个新工具、每一个版本更新或每一次语言模型的变更，都迫使开发者对提示词文本进行重新审计。人工审核人员必须阅读长篇的自然语言，对其进行解读，并寄希望于模型能够尊重这些规则。其结果是一个在现实世界使用中极其脆弱的安全网。

将安全性从提示词转向工具层

一种更可靠的方法是在 AI 执行动作 的地方强制执行安全性——即工具本身。在我的实验中，我构建了一个名为 Lester 的预算智能体。其工作流程如下：

  1. 手机应用捕获传入的银行短信。
  2. 一个轻量级的、本地托管的语言模型提取交易金额和商户名称。
  3. Lester 通过 API 调用将解析后的记录写入预算应用。

从 Lester 的角度来看，这三个步骤都是只读的：它只能添加数据，绝不能删除或修改现有条目。系统运行得非常完美，直到我添加了一个使用 MCP (Multi-Channel Prompt) 服务器的语音界面，这让我能够询问“我们上个月在杂货上花了多少钱？”或“把钱转到储蓄账户”。MCP 服务器充当经纪人，向智能体暴露了一组工具（add-transaction, query-spending, transfer-funds, delete-history）。

在原始配置中，每个工具都被平等对待。那个用于添加杂货条目的端点，同时也接受可能抹除整年记录的删除命令。如果模型发生漂移、误听了请求，或者用户输入了“删除全部”而不是“删除最近一条”，Lester 会毫不犹豫地执行。

为了防止这种情况，我用三个简单的规则重新设计了工具层：

  • 只读工具立即执行。 任何仅检索信息的操作——余额检查、消费摘要、交易查询——都不需要人工确认。只读调用的风险微乎其微。
  • 变更工具在行动前宣布意图。 对于改变状态但可逆的操作——添加交易、更新类别——在智能体发送简短的“意图”消息（例如，“正在添加杂货交易”）后继续进行。系统会记录该意图并可以将其呈现给用户进行审计，但不会阻止执行。
  • 破坏性工具在没有明确 Token 的情况下拒绝运行。 删除、截断或以其他方式导致数据无法恢复的命令在工具层被拦截。当 Lester 发出删除请求时，工具会返回一个拒绝负载（refusal payload），其中包含它将要删除的确切数据，并要求提供一个由人类生成的 Token。随后，智能体必须提供一个包含 confirm: true 和该 Token 的第二步确认负载。否则，操作将中止。

这种设计使安全检查具有原子性（atomic）：工具本身决定是否可以继续执行，而不管模型在提示词中说了什么。即使模型试图通过省略 Token 或提供格式错误的负载来绕过检查，工具也会直接拒绝请求。

为什么这对用户很重要

任何确认机制最大的障碍都是确认疲劳（fatigue）。如果一个系统对每一个微小的动作都要求批准——“你想添加这杯咖啡吗？”——用户很快就会开始不加阅读地点击“是”。结果就是一种虚假的安全感。通过仅对不可逆的操作设置关卡，我们将“人在回路（human-in-the-loop）”精准地保留在关键环节。用户更有可能审查一个可能删除整月财务历史的请求，而不是一个仅仅添加一行条目的请求。

工具层面的安全性还简化了合规性。诸如欧盟的《AI 法案》或美国的《SAFE Act》等法规，都要求具备可证明的防范意外数据丢失的保障措施。API 中硬编码的拒绝是一种可审计的控制措施，可以被记录、检查并由第三方审计员验证。相比之下，提示词文本是不透明的、依赖版本的，且在法庭上难以证明。

反驳意见：“难道我们不能直接改进提示词吗？”

一些开发者认为，精心设计的提示词结合来自人类反馈的强化学习 (RLHF)，可以达到同样的安全性水平。他们指出，经过指令微调的模型很少违反明确的约束。这种反对意见是合理的：更好的模型确实减少了意外删除的情况。

然而，即使是最强大的模型也是概率性的。一个离群的 Token、温度的变化或罕见的上下文组合，都可能导致模型产生意料之外的命令。依赖统计特性的安全性本质上是脆弱的。在高价值领域——银行、医疗、关键基础设施——一次失误就可能导致灾难性的损失。违规的成本远高于为每个破坏性操作封装一层保护性代码的工程投入。

仅靠提示词的解决方案还忽略了恶意意图。一个获取了智能体提示词访问权限的攻击者可以注入一条省略安全条款的命令。工具层面的强制执行则对此免疫，因为关卡位于模型的上下文之外。

未来值得关注的方向

社区正开始将工具层安全性视为一等公民。一些开源项目现在已经开始提供“安全 API”，它们会自动拒绝缺乏人类 Token 的破坏性调用。标准制定机构正在起草**动作级同意（action-level consent）**规范，即每个 API 调用都包含一个经过签名的意图负载，以便在下游进行审计。

已经向 AI 智能体开放内部服务的企业应该针对以下三点审计其 API：

  1. 幂等性 (Idempotency) —— 该端点是否支持在没有副作用的情况下重复调用？如果不支持，请添加确认层。
  2. 明确的意图字段 —— 要求调用者说明变更请求的目的。
  3. 人在回路 Token (Human-in-the-loop tokens) —— 生成短期的、经过加密签名的 Token，必须随任何破坏性调用一起发送。

构建 MCP 服务器的开发者可以将这些检查嵌入到编排层中，使服务器本身成为安全关卡。同样的模式也适用于基于 Webhook 的机器人、无服务器函数调用，甚至是 AI 智能体调用的命令行界面。

核心总结

当 AI 智能体能够作用于现实世界的资源时，安全性应当属于它所使用的工具，而不是我们对它低声诉说的言语。通过让只读操作自由、宣布可变变更、并在没有人类 Token 的情况下拒绝不可逆操作，我们创建了一个安全带，即使模型忘记了自己的规则，它依然有效。添加几行额外的防御性代码，其成本远低于丢失一年的财务数据。