1. 从一句吐槽说起AI 的手速为什么总比人快喊完刹车AI 已经溜出去查政府网站了——这句话第一次看到的时候我笑了半天但笑完之后又觉得挺扎心。它精准地描述了一种当下非常普遍的体验你还在斟酌措辞、还在犹豫要不要让模型去联网、还在想这一步是不是该拦一下结果它已经把请求发出去了甚至把结果都拉回来了。你喊停的时候它已经在给你念网页摘要了。这个现象背后其实不是 AI 不听话而是工具调用Tool Calling / Function Calling的时序设计决定的。现在主流的智能体框架无论是本地跑的轻量方案还是云端 API基本都遵循一个循环模型输出一个我要调用某个工具的结构化意图运行时立刻执行把结果塞回上下文模型再基于结果继续生成。这个循环里执行这一步默认是自动、即时、无确认的。你作为人类处在循环之外你的刹车要经过你的眼睛、你的大脑、你的手而 AI 的下一步只需要一次 token 生成。我拿一个具体的场景来说明这个速度差。假设你让一个带联网能力的助手帮我看看最近有没有新的行业标准发布。你的本意可能是先告诉我你打算怎么查我确认一下再查。但实际发生的是模型解析你的意图判断需要调用搜索工具运行时立即发起搜索请求搜索结果返回模型开始总结你这时候才反应过来想说等等别乱查。整个过程可能不到三秒。这就是喊完刹车已经溜出去的真实写照。理解这个时序是后面所有控制手段的前提。你不理解它就会一直处在追着 AI 跑的被动状态理解了它你才知道刹车该装在哪一环。这篇文章我想聊的不是AI 好可怕这种情绪化的东西而是怎么把控制权拿回来。具体包括工具调用的时序到底怎么设计的、哪些环节可以插入人工确认、怎么用配置和代码把自动执行改成先问再执行、以及我在实际项目里踩过的那些坑。适合正在做智能体应用、或者只是想让自己的 AI 助手别那么莽的读者。2. 工具调用的时序拆解刹车到底该装在哪一环2.1 一次完整的工具调用经历了什么要把控制权拿回来先得看清楚一次工具调用从生到死的完整链路。我把它拆成六个阶段每个阶段都是一个潜在的刹车点阶段发生了什么谁在控制能否拦截意图识别模型判断这个问题需要调工具模型难属于模型内部工具选择模型从工具列表里挑一个模型可通过工具描述约束参数生成模型填好调用参数模型可通过 schema 校验执行请求运行时真正发起调用运行时最佳拦截点结果回填结果塞回上下文运行时可过滤敏感内容二次生成模型基于结果继续回答模型可通过提示词约束大部分人想踩刹车本能反应是去改提示词也就是在意图识别和二次生成这两个阶段使劲。比如写你不要随便联网查询前先问我。但实测下来这种做法的可靠性很差因为提示词是软约束模型可能遵守也可能在某个上下文里就忘了。真正可靠的刹车装在执行请求这一环也就是运行时层面。2.2 为什么提示词刹车不可靠我做过一个对比测试同一个模型同一批任务只改提示词的严格程度看它未经确认就调工具的比例。结果大致是这样的提示词写请谨慎使用工具约 40% 的任务会直接调用提示词写调用工具前必须先询问用户降到约 15%提示词写调用工具前必须先询问用户否则视为严重错误降到约 8%。看起来有效果但 8% 依然意味着每十几次就有一次溜出去。对于查询类工具8% 可能无所谓但如果工具是发邮件下单删除数据这种有副作用的操作8% 就是事故率。所以我的结论很明确提示词可以用来引导但不能用来兜底。兜底必须靠运行时的硬拦截。2.3 运行时拦截的三种粒度运行时拦截不是只有全拦和全放两种实际可以做到很细的粒度。我常用的分法是三档全自动工具直接执行不询问。适合只读、无副作用、低成本的工具比如查天气、算数。白名单自动预先声明哪些工具可以自动跑其余一律询问。这是最实用的档位兼顾效率和可控。全确认任何工具调用都要人工点一下。适合高风险场景比如涉及资金、对外发送、数据修改。关键在于这个分档应该是按工具配置的而不是全局一刀切。查天气和发邮件显然不该用同一套策略。很多框架默认是全自动你需要主动去把它改成白名单自动这就是把刹车装回去的第一步。3. 把自动执行改成先问再执行的实操方案3.1 用工具描述做第一层软约束在动代码之前有个成本最低的优化把工具描述写清楚。模型选不选这个工具、什么时候选很大程度上取决于描述。我见过太多项目工具描述就一行search: 搜索模型当然会乱用。一个负责任的工具描述应该包含三件事这个工具做什么、什么时候该用、什么时候不该用。举个例子{ name: query_public_data, description: 查询公开的统计数据。仅当用户明确要求查询具体数据且你已经确认用户提供了足够的查询条件时使用。如果用户只是闲聊或询问概念不要调用此工具。调用前如果查询条件不明确应先向用户确认。, parameters: { type: object, properties: { keyword: { type: string, description: 查询关键词 }, time_range: { type: string, description: 时间范围如 2024-01 至 2024-06 } }, required: [keyword] } }注意描述里那句调用前如果查询条件不明确应先向用户确认。这就是把先问再执行的意图写进了工具本身。实测下来这种写法的拦截效果比在系统提示词里泛泛地说要谨慎要好得多因为它离决策点更近。3.2 在运行时加一个人工确认钩子软约束之后是硬拦截。核心思路是在执行请求这一步之前插入一个回调由它决定是放行还是暂停等确认。伪代码大概长这样def execute_tool_call(tool_name, arguments, context): # 判断这个工具是否需要人工确认 if tool_name in AUTO_APPROVED_TOOLS: return run_tool(tool_name, arguments) # 需要确认把决策权交回给人 decision request_human_approval( tooltool_name, argsarguments, reasonf模型想调用 {tool_name}参数为 {arguments} ) if decision approve: return run_tool(tool_name, arguments) elif decision modify: return run_tool(tool_name, decision.new_args) else: # 拒绝把拒绝信息回填给模型让它换个思路 return {status: rejected, message: 用户拒绝了此次调用请询问用户下一步意图}这里有个细节值得说拒绝之后不要把模型晾着。如果你只是返回一个空结果模型可能会反复重试同一个工具形成死循环。正确做法是把被拒绝这个事实和原因回填给模型让它知道此路不通需要换策略或者直接问用户。3.3 参数校验在放行前先过一遍 schema人工确认之前其实还有一道自动化的关卡可以做参数校验。模型生成的参数不一定合法比如时间范围写成了上个月而不是具体日期或者关键词是空的。这些低级错误如果直接拿去执行轻则报错重则查到一堆无关数据。我的做法是在执行前跑一遍校验不通过就直接打回给模型重填不惊动人def validate_args(tool_schema, arguments): errors [] for field in tool_schema[required]: if field not in arguments or not arguments[field]: errors.append(f缺少必填参数: {field}) # 类型校验、格式校验... return errors这样能过滤掉相当一部分模型手滑的调用减少人工确认的打扰次数。毕竟如果每次确认都是因为模型填错了参数人很快就会烦然后干脆全放行刹车又失效了。3.4 给确认加上超时和默认动作人工确认有个现实问题人可能不在。如果确认弹窗一直挂着整个流程就卡死了。所以确认机制必须配超时策略。我一般设两个参数超时时间比如 60 秒超过就按默认动作处理默认动作只读工具默认放行有副作用的工具默认拒绝。这个设计的意思是人不在的时候系统按最保守的方式走。查数据可以放改数据必须拒。这样既不会卡死也不会在无人看管时闯祸。4. 那些让我印象深刻的翻车现场4.1 一次查资料引发的连环调用有个项目里我让助手帮我整理一下某个领域的公开资料。我预期的是它列个提纲然后我们讨论。结果它一口气调了七八次搜索每次结果都塞进上下文最后生成了一份看起来挺像样的报告。问题是其中几次搜索的关键词是它自己脑补出来的跟我想要的方向偏了十万八千里。这次翻车的根因是我把一个开放式任务交给了一个默认自动执行的循环。开放式任务意味着模型需要多轮探索而每一轮探索都是一次自动调用。我喊刹车的时候它已经跑到第三轮了。教训是开放式任务要么拆成多个封闭的小任务要么在循环里加每 N 次调用暂停一次的节流。我后来加了个计数器连续调用超过 3 次就强制暂停问一下效果好很多。4.2 参数里的隐形副作用还有一次更隐蔽。一个工具叫更新记录描述写的是更新指定记录的内容。模型调用它的时候参数里带了一个它自己推断的记录 ID。我确认的时候扫了一眼觉得 ID 看着眼熟就点了同意。结果它更新的是另一条记录——因为模型推断的 ID 是错的而我没仔细核对。这个坑的本质是确认界面如果只显示要调用什么工具而不显示具体改哪条数据、改成什么那确认就是走过场。后来我把确认信息改成必须展示操作对象 变更前后对比人才有可能真正判断。确认机制的价值不在于有个弹窗而在于弹窗里的信息足够让人做判断。4.3 拒绝之后的死循环前面提过拒绝要回填原因这个是我用血换来的。早期版本里用户拒绝后我只返回一个空对象结果模型看到空结果以为这次没查到再试一次于是又发起同样的调用。用户拒绝它重试用户再拒绝它再重试。三轮之后用户直接关掉了页面。修复方式就是前面说的拒绝时明确告诉模型用户主动拒绝了不要再重试这个工具请询问用户意图。加上这句话之后死循环基本消失了。4.4 确认疲劳刹车踩多了也会失灵最后一个坑比较反直觉确认太多等于没有确认。有个版本我把所有工具都设成需要确认结果用户点了几十次同意之后形成了肌肉记忆后面看都不看直接点。这时候如果混进来一个危险调用用户照样会点同意。所以确认机制要克制只对真正有副作用的操作弹窗。只读的、低风险的让它自动跑。把人的注意力留给真正需要判断的时刻这才是可持续的刹车。5. 不同场景下的刹车策略怎么选5.1 个人助手宽松为主关键处收紧如果是自己用的个人助手我的建议是整体宽松。查资料、算东西、整理文本这些让它自动跑效率优先。只在两类操作上收紧对外发送发邮件、发消息和数据修改改文件、改记录。这两类一旦出错挽回成本高。具体配置上我会维护一个AUTO_APPROVED列表把只读工具都放进去其余默认询问。这样日常使用几乎感觉不到刹车但关键时刻它一定会停下来。5.2 团队协作白名单 审计日志团队场景比个人复杂因为不同人对风险的容忍度不一样。这时候光有确认不够还得有审计日志谁在什么时候批准了什么调用参数是什么结果是什么。出了问题能追溯。白名单也要更严格通常由管理员统一配置普通成员不能随意把工具加进自动执行列表。我见过团队里有人图省事把发送通知设成自动结果测试时给全组发了几十条消息场面一度非常尴尬。5.3 面向外部用户的产品默认最保守如果这个 AI 是给外部用户用的那默认策略必须是最保守的。因为你不认识用户不知道他们会输入什么也不知道他们会怎么理解确认弹窗。这种情况下宁可多问几次也不能默认执行有副作用的操作。另外面向外部用户时确认弹窗的文案要特别小心。不能写是否允许调用工具 X用户看不懂。要写人话比如助手想要查询公开数据是否允许把技术细节翻译成用户能理解的决策。5.4 一张对照表帮你快速定位场景默认策略自动放行范围必须确认额外要求个人助手宽松所有只读工具对外发送、数据修改无团队协作中等管理员白名单白名单外全部审计日志外部产品保守极少数无副作用工具绝大多数操作人话文案、超时默认拒绝这张表不是死的你可以根据自己的风险偏好调整。但有个原则不变风险越高的场景默认越保守人工确认的覆盖面越大。6. 几个容易被忽略的工程细节6.1 上下文里的工具结果也要管大部分人只盯着调用前的拦截忽略了结果回填这一环。工具返回的内容会进入上下文影响模型后续的判断。如果返回的内容里有敏感信息或者格式很乱模型可能会被带偏。我的做法是在回填前做一次清洗去掉无关的 HTML 标签、截断过长的内容、对敏感字段做脱敏。这样既保护了信息也让模型的输入更干净。6.2 并发调用时的确认顺序有些模型会一次性发起多个工具调用并行调用。这时候确认界面怎么展示如果一个个弹用户会疯如果打包成一个用户可能没看清就批了。我的处理是按风险分组。低风险的打包成一个批量放行高风险的单独弹。这样既减少打扰又不牺牲关键判断。6.3 让模型学会先问除了运行时拦截还可以训练模型养成先问的习惯。方法是在系统提示词里明确写当查询条件不明确、或者操作有副作用时先输出一个询问而不是直接调工具。配合前面说的工具描述双管齐下模型莽的概率会明显下降。但记住这只是降低概率不是消除。硬拦截永远要有。6.4 监控溜出去的频率最后建议加一个简单的监控统计每天有多少次工具调用是自动执行的、多少次是确认后执行的、多少次被拒绝。这个数据能告诉你刹车有没有生效。如果自动执行的比例一直很高说明你的白名单太宽了如果拒绝率很高说明模型选工具的准确率有问题该去优化工具描述了。我在一个项目里就是靠这个监控发现某个工具的自动执行率异常高一查发现是描述写得太宽泛模型逮着机会就用。改完描述比例立刻降下来了。说到底喊完刹车 AI 已经溜出去这件事本质是控制权在谁手里的问题。默认情况下控制权在模型的自动循环里你要做的是通过工具描述、运行时钩子、参数校验、确认机制这一整套组合拳把控制权一点点拿回来。拿回来的过程不复杂但需要你理解时序、选对拦截点、并且克制地使用确认别让刹车本身变成负担。我自己踩过的那些坑归根结底都是想省事、想一步到位结果反而在某个环节失了控。把每个环节都照顾到AI 才会既好用又不闯祸。