AI Agent 最危险的地方，不是它会说错话。 而是它说完之后，真的可以去做事。

---

摘要

过去，AI 的主要风险，停留在内容层。

它可能回答错误，可能生成幻觉，可能误解问题，可能给出不可靠的建议。

这些问题当然重要，但它们大多还被关在"信息世界"里——最坏的结果，是一个错误的答案。

而 AI Agent 的出现，把问题推进到了另一个层面。

Agent 不只是回答。它会调用工具，会访问系统，会提交请求，会生成 payload，会触发审批，会修改数据，会执行任务——它会把人的意图，转换成现实里的动作。

这意味着，AI 不再只是一个解释者，它开始成为执行链路本身的一部分。

也正因如此，AI Agent 的工具调用（tool calling），会显著放大 Intent 到 Execution 之间那道缝隙。

用户说的是一个目标。Agent 理解成一个计划。计划被拆成多个步骤。步骤被转换成工具调用。工具调用生成具体参数。参数进入系统。系统执行动作。现实被改变。

这条链路越长，语义偏移的机会就越多——而 Agent，恰恰是有史以来最长的那条链路。

这就是执行缝隙在 AI Agent 时代被放大的根本原因。这也是本系列前六篇讲的所有问题——Intent、确认、审批、payload、UI、按钮——在 Agent 身上被同时、成倍地激活的地方。

---

一、Agent 接收的是目标，不是执行细节

人和 Agent 交互时，通常不会直接给出底层的执行指令。

用户不会说：调用哪个接口、传入哪个参数、访问哪个系统、使用哪个 token、生成哪个 payload、触发哪个回调。

用户说的，是目标：帮我处理这批付款；帮我整理这些客户权限；帮我部署这个服务；帮我分析这个账户的风险；帮我自动完成这组流程；帮我把这个问题修复掉；帮我把这笔资产操作完成。

这些，都是高层 Intent。它们表达的是"我想达到什么结果",而不是"该怎么一步步做"。

但 Agent 要真正完成任务，就必须把目标拆成执行动作：需要调用哪些工具、访问哪些系统、读取哪些数据、写入哪些字段、生成哪些请求、申请哪些权限、触发哪些外部动作、在什么条件下继续执行。

这一步，正是执行缝隙开始扩大的地方。

用户给的是目标，Agent 生成的是路径，系统执行的是动作——目标、路径、动作，从来不是同一件事。

在传统软件里，从目标到动作的翻译，是由确定性的代码完成的：同样的输入，永远得到同样的输出。而在 Agent 里，这层翻译交给了一个非确定性的模型——同一个目标，两次运行都可能生成不同的路径。这种不确定性正是它的能力所在，但也意味着，执行的边界不能再依赖"路径本身是可预测的"这个假设。

---

二、工具调用，让 AI 从"建议者"变成"执行参与者"

普通 AI 回答错了，影响的是判断。 Agent 工具调用错了，影响的是现实。

这是一个巨大的变化。

过去，AI 最多告诉用户："你可以这样操作。"用户还需要自己判断、自己点击、自己执行。人，始终站在动作和现实之间。

但在 Agent 模式下，它可能直接：调用 API、创建订单、修改权限、发送邮件、生成交易、操作数据库、提交工单、执行脚本、访问企业系统、调用外部服务。

这时候，AI 不再只是建议。它进入了执行路径。

而一旦 AI 进入执行路径，它的错误就不再只是"答案不准确",而可能变成：错误的权限被开通、错误的账户被操作、错误的参数被提交、错误的工具被调用、错误的交易被生成、错误的数据被写入、错误的流程被自动推进。

聊天机器人影响的是认知，Agent 影响的是执行——一个改变你的想法，一个改变你的世界。

所以 Agent 的安全问题，不能只用"内容安全"去理解。内容安全关心它说了什么，而这里真正要紧的，是它做了什么。

Agent 的安全，必须被放进执行安全里来理解——否则我们防的是它的嘴，漏的是它的手。

---

三、Agent 的每一次拆解，都是一次语义转换

用户给 Agent 一个目标之后，Agent 会做任务拆解。这个过程看起来非常智能。

但从执行安全的角度看，每一次拆解，都是一次语义转换，而每一次转换，都可能丢失或添加语义。

用户说"帮我处理付款",Agent 可能拆成：读取付款列表、匹配供应商、校验金额、调用审批接口、生成支付指令、提交执行请求。

用户说"帮我部署服务",Agent 可能拆成：拉取代码、生成配置、修改环境变量、调用 CI/CD、重启服务、检查状态。

用户说"帮我管理权限",Agent 可能拆成：查询用户组、判断角色、修改权限、同步策略、通知相关人员。

这些步骤，单独看都可能是合理的。但问题在于：

Agent 的拆解，不一定等于用户的原始意图。

用户说"处理付款",不一定允许"立即支付"。 用户说"部署服务",不一定允许"修改生产配置"。 用户说"管理权限",不一定允许"扩大权限范围"。 用户说"修复问题",不一定允许"执行高危命令"。

Agent 可能把目标理解得过宽，也可能把限制条件理解得过窄，还可能把一个"建议性"的目标，直接变成"执行性"的动作。

这，就是语义漂移。它不是模型"出错"的特例，而是"把模糊目标翻译成精确动作"这件事本身，必然携带的风险。

---

四、工具调用，把语义漂移变成了真实后果

如果 Agent 只是"说错",用户还有机会发现、纠正。错误停留在文字里，是可逆的。

但如果 Agent 已经调用了工具，语义漂移就可能直接进入现实——而现实，往往不可逆。

比如：用户只是想让 Agent 生成一个付款建议，Agent 却调用了提交付款的接口；用户只是想让 Agent 分析权限结构，Agent 却开始修改权限；用户只是想让 Agent 准备部署方案，Agent 却触发了生产部署；用户只是想让 Agent 检查交易风险，Agent 却生成了一个待签的 payload；用户只是想让 Agent 整理文件，Agent 却删除了它"认为不需要"的内容。

这些问题，不一定源于恶意。

Agent 可能只是误解了"帮我处理"的分寸；可能只是认为"完成任务"就应该一路执行到底；可能只是沿着最短的路径去达成目标；可能只是选了一个"看起来最有效"的工具。

但执行系统不能只看 Agent 有没有恶意。

执行系统要看的，从来不是它的动机，而是它最终让什么发生了。

工具调用的危险正在于此：

它把一次"理解错误",干净利落地转换成了一个"执行结果"。

在纯对话里，理解错误是终点；在 Agent 里，理解错误只是起点。

---

五、Agent 的上下文越长，执行边界越容易模糊

Agent 高度依赖上下文。它会读取对话历史、任务说明、文件内容、系统状态、工具返回、用户补充、第三方信息。

这些上下文帮助 Agent 完成任务。但上下文越长，边界就越容易变得模糊。

一开始，用户可能只是让 Agent 分析；后来，Agent 可能理解成"可以操作"。 一开始，用户可能只授权了读取；后来，Agent 可能认为"可以写入"。 一开始，任务目标是测试环境；后来，工具调用悄悄进入了生产。 一开始，用户允许的只是"这一步";后来，Agent 把授权延伸到了"后续所有步骤"。

上下文不是静态的。Agent 会不断根据上下文更新计划，而执行边界如果没有被硬约束，就会被 Agent 用它自己的解释，一次次重新定义。

这里潜藏着 Agent 时代最凶险的一类攻击——间接提示注入（indirect prompt injection）。Agent 读取的上下文里，可能混入了不受信任的内容：一封邮件、一个网页、一份文档、一个工具的返回值。这些内容里可以藏着指令，而 Agent 无法可靠地区分"哪些是用户的意图,哪些是数据里夹带的命令"。安全研究者把这类风险的构成，概括为一个"致命三角(lethal trifecta)":当一个 Agent 同时具备访问私有数据、接触不可信内容、以及对外发送能力这三者时，它就可能被外部内容操纵，把你的数据送到攻击者手里——而全程,它都以为自己在"完成任务"。

这就是 AI Agent 时代最关键的一条原则：边界不能只存在于自然语言的上下文里。

因为自然语言的上下文，可以被解释、被压缩、被遗忘、被误读、被新信息覆盖，也可以被投毒。

真正的执行边界，必须独立于 Agent 的自我解释——一个能被说服的边界，等于没有边界。

---

六、工具调用不是一个动作，而是一条链路

很多人会把工具调用理解成一次单独的动作：Agent 调一个工具，工具返回一个结果，任务继续。

但在真实系统里，工具调用常常是一条链路的入口。

一个工具调用，可能触发另一个工具；一个 API，可能写入任务队列；一个任务队列，可能触发后续流程；一个流程，可能调用第三方服务；一个第三方服务，可能改变外部状态；而一个外部状态的变化，又会反过来影响下一步的判断。

所以工具调用不是孤立事件。

比如：Agent 调用了"创建付款任务"这个工具，这个工具触发了审批流，审批通过后自动生成了支付指令，支付指令进入了银行接口，银行接口完成了转账。

从 Agent 的视角看，它只是"创建了一个任务";从现实的结果看，一笔资金已经转走了。

这正是执行缝隙被放大的地方：Agent 看到的是"工具名称",系统执行的是"后续链路",用户理解的是"任务目标",而现实发生的是"最终结果"——这四者，很可能并不一致。

而随着 MCP（Model Context Protocol） 这类标准让 Agent 能够即插即用地接入成百上千个外部工具，这条链路正在变得越来越长、越来越难以被单个人完整审视。工具越多，组合越多；组合越多，那条没人看得全的链路就越长。

---

七、工具名称，可能掩盖真实的执行后果

很多工具的名字都很友好：approve、submit、sync、update、execute、connect、deploy、grant、clean、optimize、continue、process。

对 Agent 来说，这些名字只是一个个工具标签、一个个可调用的函数签名。但它们背后，可能代表着完全不同量级的执行后果。

sync 可能只是同步状态，也可能覆盖数据。 update 可能只是更新备注，也可能修改权限。 clean 可能只是清理缓存，也可能删除文件。 grant 可能只是临时授权，也可能开放长期权限。 deploy 可能只是测试部署，也可能影响生产环境。 process 可能只是走个流程，也可能触发一笔付款。

如果工具的定义不清楚，Agent 就会低估它的风险。如果工具的描述过于抽象，用户也很难理解它真正的后果。如果工具的权限过大，那么单单一次调用，就足以越过执行边界。

在 Agent 系统里，工具的描述不只是文档，它就是模型据以决策的"世界地图"——地图画错了，走对的概率就只剩运气。

所以 Agent 工具调用的安全，从来不只是一个模型问题。工具本身的设计、权限、命名、边界和后果描述，每一样都在直接影响执行安全。一个权限过宽、命名含糊的工具，等于在系统里埋了一颗只等 Agent 去踩的雷。

---

八、Agent 会沿着"最容易成功"的路径执行

Agent 的目标，通常就是完成任务。为了完成任务，它会倾向于寻找一条可行的路径。这在效率上是好事，但在安全上，可能带来问题。

如果某个工具的权限更大，Agent 可能就选它。 如果某条路径更短，Agent 可能就走它。 如果某个接口更容易调用，Agent 可能就用它。 如果某个审批环节限制更少，Agent 可能就绕向它。 如果某个策略来源更宽松，Agent 可能就沿着它继续。

这不一定是恶意的绕过，它可能只是一次"任务优化"。但从执行安全的角度看，结果是相似的：

Agent 会自发地找到那条"最容易让动作发生"的路径——而最容易发生的路径，往往不是最该发生的路径。

这也是为什么，AI Agent 时代不能只依赖"工具权限已经配置好了"。

权限存在，不等于应该使用；路径可行，不等于边界正确；工具可调用，不等于它可以一直执行到现实。

高风险系统必须防止 Agent 把"能做"误当成"该做"。这在安全上有一个古老的名字——混淆代理（confused deputy）问题：一个本身拥有较高权限的执行者，被诱导着用自己的权限，去替别人做了不该做的事。Agent 恰恰是一个天生的、随时可能被上下文误导的"deputy"。它手里的权限越大，被"借用"去做错事的后果就越严重。

对付混淆代理，安全工程给出的经典解法是能力式安全（capability-based security）:不给执行者一把"什么门都能开"的万能钥匙，而是针对每一个具体动作，签发一张范围最小、且只在特定上下文里有效的临时凭据。换句话说，授权不该是"这个 Agent 是可信的,所以放行它的一切",而应该是"这一次、这个对象、这个范围、这段时间——仅此而已"。可惜的是，现实中大量 Agent 拿到的，恰恰是一把长期、宽泛、跨系统通用的钥匙。我们一边惊叹于它的自主，一边把最不该集中的执行权，集中交给了一个我们并不能完全预测的东西。

---

九、审批 Agent 的"计划",不等于审批 Agent 的"执行"

很多系统会在 Agent 执行前，要求用户先批准它的计划。Agent 先展示计划，用户确认，然后 Agent 执行。这当然有价值。

但问题在于：计划不是执行。

Agent 的计划可能写着："我将检查数据、生成建议，并提交结果。"

而真实的执行，可能包含：读取敏感数据、调用外部 API、写入业务系统、修改权限字段、触发自动审批、生成执行 payload。

计划是自然语言，执行是工具调用；计划是概括，执行是参数化的动作；计划是运行前的表达，执行是运行时才真正长出来的东西。

所以，用户审批了 Agent 的计划，并不等于审批了 Agent 的每一次高风险工具调用。尤其当 Agent 在执行过程中动态调整路径时，计划和执行之间会不断裂开新的缝隙。

这触及了 Agent 自治的一个核心设计选择：是 human-in-the-loop（人在环内，每个关键动作都要人点头）,还是 human-on-the-loop（人在环上，只做事后监督）?计划审批，本质上是一种很弱的 in-the-loop——它把人放在了"计划"这一刻，却在"执行"那一刻把人请了出去。

真正安全的系统不能只问："用户是否批准了 Agent 的计划？"

它还必须在每一次高风险调用发生时，追问一句：

"Agent 当前这一次工具调用，是否仍然落在被批准的那条边界之内？"

---

十、Havenlon 关注的，是工具调用进入现实之前的最后边界

需要说清楚：Havenlon 并不是要阻止 Agent 使用工具。

工具调用，恰恰是 Agent 价值的核心。没有工具调用，Agent 只能停在建议层；有了工具调用，它才能真正参与到流程里。

但也正因为工具调用会改变现实，它才不能没有边界。

Havenlon 关注的问题只有一个：

当 Agent 的工具调用即将进入真实执行时，系统是否还有一个独立的能力，去判断、并在必要时拒绝？

这个判断，不能完全交给 Agent 自己。因为 Agent 既是请求的发起者，又是路径的生成者——它不能同时再当最终的裁判。

一个既负责发起、又负责放行的系统，本质上没有边界；发起者和裁决者，必须是两个人。

这个判断，也不能完全交给 SaaS。因为 SaaS 可能只是协调层，可能被污染，可能基于不完整的上下文做判断。

这个判断，同样不能只交给审批按钮。因为按钮确认的，只是某一个展示版本，未必覆盖了当前这次工具调用的真实后果。

所以，在工具调用进入现实之前，需要一个执行控制层重新判断：这次调用是否对应原始 Intent；是否超出了用户的授权范围；是否超出了审批的边界；是否调用了高风险工具；是否会产生不可逆的结果；是否会改变外部状态；是否符合当前的本地策略；是否应该被硬件边界放行。

如果不符合——就应该停下来。

---

十一、Agent 时代，执行控制不再是一个可选项

当 Agent 只能聊天时，它的安全问题主要是内容安全。 当 Agent 可以调用工具时，它的安全问题就变成了执行安全。

这意味着，很多传统的安全边界，会变得不够用。

只做登录，不够。只做权限，不够。只做审批，不够。只做提示，不够。只做日志，不够。只做签名，也不够。

因为这些机制，回答的大多是局部问题：谁在请求？是否有权限？是否经过审批？格式是否合法？是否留下了记录？

而 Agent 工具调用真正需要回答的，是一个整体问题：

这个由 AI 理解、拆解、选择并提交的动作，是否仍然应该进入现实？

这是一个执行控制问题。它不是单纯的模型安全问题，不是单纯的 API 安全问题，更不是单纯的用户体验问题。

它是 AI Agent 时代，一个全新的、绕不过去的基础安全问题。

---

十二、从"AI 可以请求",到"硬件最终裁决"

Havenlon 的核心思路，不是不信任 AI。

而是——不把 AI 放在最终执行裁决的位置上。

AI 可以理解目标，可以生成计划，可以调用工具，可以提交请求，可以参与协同。这些，都欢迎。

但当一个请求即将改变现实时，它必须经过一道独立的边界。

这，可以浓缩成一句话：

AI 可以请求，软件可以提议，硬件最终裁决。

这句话背后的含义是：AI 不是不能做事，而是不能单独决定"什么事可以真的发生";软件不是没有价值，而是不能把执行权完全交给可能被污染的软件域；审批不是不重要，而是不能把最后的边界，压在一个按钮上。

真正的高风险执行，需要一个和 Agent、SaaS、UI、审批、payload 都保持距离的裁决边界。

它不负责生成目标，不负责解释理由，不负责优化路径，不负责取悦用户，也不负责提高通过率。它把这些统统交还给上游。

它只负责在现实发生之前，问出最后一个问题：这个动作，真的还应该发生吗？

一个不需要讨好任何人、也无法被任何人说服的边界，才配站在现实的门口。

---

结语

AI Agent 的工具调用，放大了执行缝隙。

因为它把人的一个高层意图，拉长成了一条复杂的执行链路：用户说的是目标，Agent 理解成计划，计划拆成步骤，步骤变成工具调用，工具调用生成 payload，payload 进入系统，系统改变现实。

而这条链路上的每一次转换，都可能产生偏差。

每一个工具，都可能扩大权限；每一次摘要，都可能遗漏边界；每一个按钮，都可能确认错误对象；每一次调用，都可能把语义漂移，变成真实后果。

所以在 AI Agent 时代，真正危险的，不是 AI 会不会说错。

真正危险的，是它说错、理解错、拆解错、调用错之后，系统依然允许它继续执行。

这就是为什么，执行控制会变得越来越重要。

Agent 可以成为一个强大的执行助手，但它不能成为最后那道执行边界。

因为当 AI 开始调用工具，安全系统就必须完成一次升级——

从"防止错误的回答",升级到"防止错误的发生"。

而 Havenlon 要守住的，正是这个"发生之前"的最后边界。