Havenlon｜执行缝隙（七）：AI Agent 的工具调用，为什么放大了执行缝隙

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 看到的是工具名称,系统执行的是后续链路,用户理解的是任务目标,而现实发生的是最终结果——这四者很可能并不一致。而随着MCPModel 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 理解成计划计划拆成步骤步骤变成工具调用工具调用生成 payloadpayload 进入系统系统改变现实。而这条链路上的每一次转换都可能产生偏差。每一个工具都可能扩大权限每一次摘要都可能遗漏边界每一个按钮都可能确认错误对象每一次调用都可能把语义漂移变成真实后果。所以在 AI Agent 时代真正危险的不是 AI 会不会说错。真正危险的是它说错、理解错、拆解错、调用错之后系统依然允许它继续执行。这就是为什么执行控制会变得越来越重要。Agent 可以成为一个强大的执行助手但它不能成为最后那道执行边界。因为当 AI 开始调用工具安全系统就必须完成一次升级——从防止错误的回答,升级到防止错误的发生。而 Havenlon 要守住的正是这个发生之前的最后边界。