Function Calling 这件事，模型厂商把它讲得很简单。文档里给你看个 demo，定义一个工具，模型决定调用，参数填好返回，整个过程丝滑得像魔法。你以为接上就能用了。
真到生产环境，demo 里的每一步都藏着坑。模型选错了工具、参数填得不对、调用的时机不对、调用失败后不知道怎么办、多步调用之间的状态乱了。这些工程问题，模型厂商不会替你解决，得自己处理。这篇讲 Function Calling 从「模型能力」到「工程可用」之间，到底要补哪些东西。
第一道关，工具描述是被低估的杠杆
图：工具描述是模型理解工具的唯一依据，写清楚用途、场景、边界，准确率立刻提升。
LLM 决定调哪个工具、什么时候调，依据全是工具的 description。模型本身不知道你的工具是干嘛的，它只能读你写的描述来理解。
这就意味着，描述写得好，模型准确调用。描述写得差，模型乱用或者该用的时候不用。很多团队 Function Calling 效果差，第一反应是怪模型笨，其实问题出在工具描述上。
好的描述要像写给一个聪明但完全不懂你业务的新同事的说明。讲清楚这个工具是干嘛的、什么时候该用、什么时候不该用、输入输出是什么、有什么边界和限制。最好带上使用示例。
反例是那种模糊的描述，「查询用户信息」。模型看到这个，不知道什么算「用户信息」、什么时候该查、查出来是什么格式。它就会在不该用的时候用，或者该用的时候用了别的。
正例是，「根据用户 ID 查询用户的基本资料（姓名、注册时间、状态）。当用户询问某个具体用户的信息时使用。不要用于批量查询或统计」。这样模型就有足够的判断依据。
迭代工具描述是 Function Calling 调优的主要工作之一。线上发现模型选错工具了，第一件事不是换模型，是回去改描述。这是效果优化的高杠杆点，而且几乎零成本。
第二道关，参数校验和错误处理
模型生成的参数不可信。它可能填错类型、漏掉必填字段、填了不存在的值。直接拿去调用工具，要么报错要么出事。
所以工程上必须有一层校验。模型返回的参数，先按工具的 schema 校验一遍，类型对不对、必填字段有没有、值合不合法。校验不过的，不能直接调用，要让模型重新生成，或者走降级逻辑。
调用失败的处理也要设计。工具调用超时了怎么办，返回错误了怎么办，外部服务挂了怎么办。最简单的策略是重试几次，重试还不行就告诉模型「这个工具暂时不可用」，让模型决定是换工具还是直接回答。
这些错误路径，demo 里都不会遇到，但生产环境里每天都会触发。不处理好，系统就会在边界情况下崩溃，或者更糟，给出错误的结果还装作没事。
第三道关，多步调用的编排
图：多步编排的核心是管理中间状态——每一步结果回填上下文，模型据此决定下一步，并有终止机制兜底。
单个工具调用不难，难的是多个工具配合完成一个复杂任务。用户问「查一下我上个月的订单，把金额最大的那个的物流状态告诉我」，这需要先查订单、再筛选、再查物流，是三步串行调用，每步依赖上一步的结果。
编排多步调用，要管理中间状态。每一步的结果要存下来，传给下一步作为输入。模型要能看到之前调用了什么、得到了什么，才能决定下一步做什么。这个对话上下文的管理，是 Agent 框架的核心职责。
还要处理循环和终止。有些任务需要反复调用工具直到满足条件（比如翻页查完所有结果），怎么让模型知道该停了，怎么防止无限循环，都要有机制。一般设个最大调用次数兜底，防止模型陷入死循环烧 token。
并行调用是更高级的能力。几个独立的工具调用可以并行执行，不互相依赖的就没必要串行等。但这增加编排复杂度，要管理并发的结果收集和错误处理。
第四道关，权限和安全
Function Calling 让 LLM 能调用真实工具，查询数据库、发消息、改数据。这是能力也是风险。
权限控制必不可少。哪些工具允许在什么场景下调用，调用者的身份怎么校验，工具能访问的数据范围怎么限制。一个能查所有用户数据的工具，配在一个对外的 Agent 上，就是数据泄露风险。
敏感操作要确认。删数据、发消息、转账这类不可逆或有副作用的操作，不该让模型直接执行，应该加一层人工确认，或者至少记下审计日志。
输入也要防注入。用户可能在输入里嵌入恶意指令，诱导模型调用不该调的工具或者传恶意参数。把用户输入当数据而不是指令来处理，是防御提示注入的基本原则。
工具设计的几个原则
总结下来，给 LLM 设计工具有几个原则。
单一职责。一个工具干一件事，不要做一个大而全的工具。模型选起来更准，参数也更简单。
输入输出明确。参数的 schema 要严格，返回的格式要稳定。模糊的输入输出，是模型出错的根源。
粒度合适。太细的工具模型要调很多次才能完成任务，太粗的工具不灵活。按业务操作的粒度来切，通常比较合适。
有降级。工具不可用时系统不能崩，要么跳过要么用替代方案。把每个工具都当成可能失败的组件来设计。
模型支持 Function Calling 只是起点，能不能在生产环境稳定跑起来，靠的是工程。工具描述怎么写、参数怎么校验、错误怎么处理、多步怎么编排、权限怎么控，这些每一项都是实打实的工程活。把 demo 跑通的人很多，把生产级 Function Calling 做稳的团队不多，差距全在这些工程细节上。
一个完整的调用链路
图：完整链路串起决策、校验、权限、执行、错误恢复、终止控制——每一环都值得打磨，做扎实才能上生产。
把上面的拼起来，一个生产级的 Function Calling 链路是这样的。用户输入进来，模型基于工具描述决定调哪个工具、填什么参数。参数先过 schema 校验，过了再调真实工具（带权限检查和审计）。工具返回结果，结果喂回给模型作为上下文。模型基于结果决定是继续调下一个工具，还是给用户最终回答。整个过程有重试、有降级、有最大调用次数兜底。
这条链路的每一环都可能出问题，也都值得打磨。把每一环都做扎实了，Function Calling 才从「能演示」变成「能上生产」。这不是一次性的工作，是随着真实使用不断发现边界情况、不断加固的过程。
