Function Calling 是让大模型从「会说」变成「会调」的关键接口：模型不再自己瞎编答案，而是输出一段结构化请求，由你的程序去真正调用 API、数据库或内部工具。用得好，Agent 能查实时数据、能下单、能改文件；用得糟，模型会编出不存在的函数名、乱传参数，或者该调工具时偏要自己硬答。所谓正确姿势，一半在 schema 设计，一半在错误处理。
工具描述写得准，模型才调得对？
模型选工具、填参数，全靠你给的描述。每个工具的名字要动词开头、见名知意，description 要写清「什么时候用、什么时候别用」，参数里逐个字段说明类型、取值范围与示例。最常见的坑是把工具名起得太笼统，两个工具描述又高度重叠，模型于是随机挑一个。另一个坑是省略必填参数的语义，模型便拿模糊记忆里的值乱填。务实做法是把工具说明当成给新同事写的交接文档：他只看这段文字，就要知道这个工具干嘛用、输入怎么凑。
结构化输出失败时，运行时该怎么接？
即便 schema 写得再好，模型仍会输出半截 JSON、多余的解释文字、或枚举值里没列过的选项。运行时不能把这种脏输出直接抛给用户。第一层兜底是解析容错：截取合法 JSON 片段、补齐缺失字段为默认值、把不在枚举里的值映射到最近的合法项。第二层是把解析错误回喂模型，让它重述一次，通常一次就能纠正。第三层才是真报错，并附上「我想调哪个工具、卡在哪一步」，让用户能干预。把解析、回喂、报错分三层接住，Function Calling 才不会在生产里因为一次格式抖动就整条崩掉。
去论坛讨论
前往 silicon-agi.com 论坛 参与讨论
