这张卡纠正一个流传极广的误解：以为模型会自己执行函数。
核心拆解：函数调用的分工是——模型只根据工具描述和对话上下文产出函数名与参数的 JSON，真正执行、鉴权、错误处理、结果回填全在应用侧代码。最容易误用的地方有两处：一是把模型点菜当成模型执行，跳过应用侧参数校验，等于把数据库写权限裸奔给一个概率系统；二是工具描述含糊，参数含义与适用场景没写清，模型选错工具、编造参数，却常被误归因为模型能力不行，实际改几行描述就能解决。
增量判断：很多人分不清函数调用与 MCP 的层次——前者是模型与单应用间的输出约定，后者把工具封装成跨应用复用的标准化服务。FDE 的增量视角是交付顺序：先精心维护少量工具并配齐评测，胜过接入一堆没人测过的工具。
行动建议：逐条检查工具描述，补齐每个参数的含义、取值范围与典型调用场景。
—— FDEChina编辑部 · 实战派
定义
函数调用（Function Calling）指大模型根据开发者注册的工具定义，在需要时输出符合签名的函数名与结构化参数，由应用侧代码实际执行并把结果回填给模型的机制。
展开
分工必须分清：模型只负责「点菜」——依据工具描述与对话上下文决定调用哪个函数、填什么参数；执行、鉴权、错误处理、结果回填全部发生在应用侧。常见误用其一，是把模型点菜当成模型执行，漏掉应用侧对参数的校验与兜底，等于把数据库写权限裸奔给一个概率系统。其二，工具描述含糊——参数含义、取值范围、适用场景没写清——模型就会选错工具或编造参数，这类问题常被误归因为模型能力不行，实际改几行描述就能解决。
与模型上下文协议（MCP）的辨析：函数调用是模型与单个应用之间的输出约定，MCP 则把工具封装成标准化服务，让同一套工具跨应用复用。对 FDE 而言，交付质量的关键不在接了多少工具，而在每个工具的描述、错误信息与评测覆盖：先维护好少量经过回归测试的工具，再考虑扩面。