模型并不会亲自执行函数：工具调用链的状态、校验与权限

“模型会调用函数”是一种方便的简称，却容易让实现者忽略关键事实：大模型通常只生成函数名称和参数，程序才是执行者。它不会自行进入数据库，也不会直接启动系统命令。应用收到结构化意图后，必须验证参数、检查权限、调用真实工具，再把结果作为新上下文交还模型。任何一步被省略，都会把概率性的文本输出误当成可信指令。

先把一次调用画成状态机

最小流程包含六个状态：理解请求、选择工具、补齐参数、等待批准、执行工具、组织回答。用户问“明天穿什么”时，模型可能判断需要天气，但若不知道城市，就应停在补参状态，而不是编造地点。用户提供城市后，模型输出类似调用意图，编排层完成校验并访问天气服务；只有工具结果返回，模型才能结合温度和降水给出建议。

用户问题
  -> 模型选择 getWeather
  -> 参数校验 city/date
  -> 权限与配额检查
  -> 应用执行天气接口
  -> 工具结果写回上下文
  -> 模型生成面向用户的回答

状态机的好处是每一步都能记录、暂停和恢复。模型输出无法解析时回到选择工具，参数缺失时回到补参，工具超时则进入可重试失败，而不是重新播放整段对话。对于订票、付款或发布内容等有副作用的动作，还应加入明确批准状态，保证用户能看到即将执行的对象、金额和范围。

函数描述是给模型看的接口说明书

工具定义通常包含名称、用途、参数类型、必填项和约束。描述过短，模型难以区分相似工具；描述过长又会消耗上下文并增加歧义。名称最好体现单一动作，例如查询天气与发送预警应拆成两个工具。参数不仅声明字符串或数字，还应限定枚举、格式、长度和允许范围。

• 描述“何时使用”，同时写清禁用条件，减少误选。
• 必填参数只保留执行不可缺少的信息，其他值采用显式默认规则。
• 日期、货币、时区和地址等字段要约定格式，避免隐式转换。
• 工具结果返回结构化状态、数据与错误码，不把异常伪装成正常文本。

模型生成的参数永远属于不可信输入。即使JSON语法合法，也可能出现不存在的城市、越界数量、危险路径或提示注入文本。编排层要进行模式校验和业务校验，再把清洗后的参数传给工具。工具端仍应独立鉴权，因为不能假设所有调用都经过同一个编排层。

天气案例里隐藏着四种不同错误

第一种是信息不足，例如缺少城市；第二种是模型选错工具，例如把穿衣建议直接路由到日历；第三种是工具失败，例如服务超时或配额用尽；第四种是结果不可用，例如返回的日期与用户所问不一致。它们的恢复动作不同，若统一回复“调用失败”，用户和运维都无法判断下一步。

工具错误不要原样丢给模型。数据库堆栈、内部地址或鉴权细节可能泄露敏感信息，应转换成受控错误对象，只保留模型做下一步决策所需的类型与可恢复提示。面向用户的解释也应与内部日志分开：用户得到清楚、简短的状态，运维保留完整追踪标识。

多工具编排最怕重复副作用

查询天气可以安全重试，提交订单却不能随意重放。模型在一轮对话中可能多次生成相同调用，网络超时也可能让应用误以为执行失败。具有副作用的工具应使用幂等键，并在执行前检查既有结果；写入完成后记录不可变回执。若操作无法幂等，就必须把自动重试关闭，转为查询状态或人工确认。

工具链还需要限制深度和总成本。模型可能在搜索、计算和验证之间循环，直到上下文或预算耗尽。编排器应设置最大步数、总耗时、调用费用与并发上限，并在触发时生成可解释的中止原因。复杂任务可以使用计划，但计划不是授权；每个敏感动作仍要单独过策略检查。

1. 只读查询可在低风险范围内自动执行。
2. 可逆写操作应展示变更摘要，并保留撤销记录。
3. 不可逆或高价值操作必须获得明确批准，批准内容绑定具体参数。
4. 跨系统传递的数据按最小必要原则裁剪，禁止把整段对话默认发送给工具。

权限边界要落到每一个工具和参数

只判断“这个智能体能否使用日历”还不够，还要区分读取空闲时间、创建会议、邀请外部人员和删除日程。工具授权可以细分为动作、资源、时间和数据范围，并使用短期凭据。模型不应看到长期密钥；编排层从安全存储获取凭据，并在调用结束后销毁临时访问上下文。

提示注入是另一条重要边界。网页、邮件或文档中的文字可能诱导模型调用不相关工具。外部内容应标明来源并与系统指令隔离，工具选择策略不能由被读取内容随意改写。涉及公开发布、资金、账号权限或隐私数据时，应用必须展示实际参数供人确认，而不是只让模型“自我检查”。

评测应覆盖选择、参数、执行与回答四层

只测试最终回答是否顺口，会掩盖错误工具调用。测试集应包含无需工具的问题、信息缺失的问题、多个相似工具的选择、边界参数、恶意输入、工具超时和错误结果。分别统计工具选择准确率、参数有效率、执行成功率、重复副作用次数以及基于结果回答的事实一致性。

线上还要保存从用户请求到工具回执的关联标识，但对隐私字段脱敏。若指标显示选择正确而执行失败，应修复工具或基础设施；若参数频繁缺失，应调整定义或补问策略；若结果正确而回答扭曲，则要检查结果注入和回答提示。分层指标能避免把所有问题都归咎于模型。

真正的“可调用”来自应用治理

Function Calling把自然语言转成机器可读意图，确实降低了人和软件之间的表达门槛，但它没有取消传统工程约束。类型校验、权限控制、事务、幂等、超时、审计和回滚仍然存在，只是被放到模型与工具之间的编排层。

一个成熟实现的判断标准，不是模型能列出多少工具，而是错误选择能否被拦住、敏感操作能否被批准、失败能否安全恢复、每次执行能否追溯。让模型负责理解和规划，让确定性代码负责约束和执行，这种职责分工才是工具调用走向生产环境的关键。