AI函数调用s

被神化的Function Calling 2026年，Function Calling被广泛宣传为"让AI从聊天进化到行动"的关键技术。在营销话术中，它似乎无所不能——查询信息、执行操作、控制设备、管理业务。 但实际使用过的人都知道，Function Calling远没有宣传的那么完美。以下是7个关键的局限性，每个使用Function Calling的开发者都应该了解。 局限一：它不理解"为什么"，只理解"什么" Function Calling的本质是模式匹配，不是真正的理解。模型学会了"当用户说X时，调用函数Y，传参数Z"，但它不理解为什么这样做。 这意味着，当用户的需求稍有变化时，模型可能会做出错误的判断。比如，用户说"帮我查一下去北京的航班，但不要东航的"，模型可能正确地调用了search_flights函数，但忽略了"不要东航"这个约束条件。 局限二：复杂推理链上的断裂 对于需要多步推理的复杂任务，Function Calling的表现会急剧下降。比如，“帮我安排一个会议，邀请所有在上个月购买了超过1000元商品的客户，时间定在下周三下午，地点在公司的第三会议室”。 这个任务需要：先查询上个月购买超过1000元的客户列表，然后查询每个人的日历空闲时间，找到共同空闲的时段，然后查询第三会议室是否可用，最后发送会议邀请。当前Function Calling很难端到端地完成这种复杂推理链。 局限三：对模糊需求的处理能力差 人类能够通过上下文、表情、语气来理解模糊的需求。但Function Calling完全依赖文字。当用户说"帮我看看那个东西"时，模型完全不知道"那个东西"是什么。 局限四：函数调用的成本 每次函数调用都意味着额外的API请求。在多轮对话中，如果模型频繁调用函数，成本会快速累积。一个复杂的多函数调用对话，成本可能是简单对话的5-10倍。 局限五：语境理解的碎片化 当模型调用函数时，它的"注意力"从对话上下文转移到了函数调用。当函数返回结果后，模型需要重新"理解"上下文。在这个过程中，一些微妙的语境信息可能会丢失。 局限六：对实时性的依赖 Function Calling需要等待外部API的响应。如果某个API响应慢（比如3秒），用户的等待时间就会显著增加。而对于需要多个函数调用的复杂任务，总延迟可能是多个API延迟的叠加。 局限七：生态系统的不成熟 2026年，Function Calling的生态系统仍然不成熟。没有统一的函数描述标准（OpenAI、Anthropic、Google各自有各自的格式），没有可靠的函数调用测试工具，没有成熟的监控和调试方案。 如何应对这些局限？ 明确边界：了解Function Calling适合什么场景，不适合什么场景。不要试图用它解决所有问题。 分层设计：对简单任务用Function Calling，对复杂任务用Agent。不要让Function Calling承担它无法承担的重任。 持续优化：Function Calling的质量很大程度上取决于函数设计的质量。持续优化函数描述、参数设计、错误处理，比不断换模型更重要。 人类兜底：对于关键任务，设置人类审核机制。Function Calling的准确率再高，也不是100%。 结论 Function Calling是一个强大的工具，但它不是魔法。理解它的局限性，你才能更好地使用它。把Function Calling看作一个"能力增强器"，而不是"万能解决方案"——这才是正确的姿态。

从工具调用到自主决策 2023年，Function Calling让模型学会了"用工具"。2024年，模型学会了"选工具"。2025年，模型学会了"组合工具"。 2026年，Function Calling正在进入一个新的阶段——从"工具调用"进化为"自主决策"。模型不再只是"根据用户指令调用函数"，而是能够"理解用户目标，自主规划和执行函数调用序列"。 进化方向一：多步规划与执行 2026年，最先进的Function Calling系统已经能够处理需要10步以上的复杂任务。比如：“帮我规划一个从北京到拉萨的10天自驾游，预算2万元，需要考虑路况、住宿、景点和加油站。” 这个任务需要调用：地图API（规划路线）、酒店API（搜索住宿）、景点API（搜索景点）、天气API（查看天气）、加油站API（规划加油点）、预算计算（控制总费用）。而且这些调用不是独立的——酒店的选择取决于路线，路线的选择取决于景点。 2026年的模型（特别是Claude 4和GPT-4o）已经能够端到端地完成这种多步规划任务。虽然准确率还有待提升（约80%），但已经具备了实用价值。 进化方向二：动态工具发现 传统的Function Calling需要开发者预先定义所有函数。但2026年，出现了"动态工具发现"——模型可以在运行时查找和调用未知的API。 比如，用户说"帮我找一下最新的关于Transformer架构的论文"，模型可以自动搜索学术API，发现ArXiv API，理解其参数格式，然后调用它。这大大扩展了Function Calling的适用范围——不再受限于开发者预定义的函数集。 进化方向三：函数调用的"反思"能力 传统Function Calling是"调用-返回-回答"的线性流程。2026年，模型开始具备"反思"能力——在调用函数后，模型会评估结果的质量，判断是否需要调整策略。 比如，模型调用了搜索API，但返回的结果不够精确。模型不是简单地展示这些结果，而是反思：“这些结果不够精确，我需要调整搜索关键词，或者添加更多过滤条件。“然后自动发起新的搜索。 这种"反思-调整-重试"的循环，让Function Calling的质量和可靠性大幅提升。 进化方向四：人机协作的函数调用 2026年的另一个重要趋势是"人机协作”——模型不是替代人类做决策，而是辅助人类做决策。 在关键操作（如大额支付、合同签署、医疗决策）中，模型会调用函数收集信息、分析选项、生成建议，但最终的决策权始终在人类手中。这种"AI辅助决策"模式，正在成为企业级Function Calling系统的标准架构。 2026年之后的展望 展望2027年，Function Calling领域最值得关注的几个方向： 多模态函数调用：模型不仅可以从文本中提取函数参数，还可以从图片、音频、视频中提取。比如，用户拍一张商品照片，模型自动调用比价API。 函数调用的自我进化：模型可以根据函数调用的历史数据，自动优化函数的描述和参数设计，甚至自动创建新的函数。 跨平台的函数调用标准：OpenAI、Anthropic、Google等厂商正在推动统一的函数调用标准，有望在2027年达成某种程度的共识。 结论 Function Calling正在从一个"技术特性"进化为一个"系统范式”。它不再只是"让模型调用API"那么简单，而是正在成为AI与外部世界交互的基础设施。如果你现在开始学习Function Calling，你学的不是"如何调用一个函数"，而是"如何构建一个AI驱动的系统"。

从"废话大师"到"行动派" 2023年初，ChatGPT惊艳世界，但它有一个致命的局限：它只能输出文字，不能执行任何实际操作。你问它"上海明天天气怎么样"，它只能告诉你"我无法获取实时信息"。 2026年，情况完全不同了。你问ChatGPT同样的问题，它自动调用天气API，返回精确的温度、湿度和降水概率。你让它"帮我订一张下周三去北京的机票"，它自动查询航班、比较价格、完成预订。 这个转变的核心技术，就是Function Calling（函数调用）。它让大模型从"只会说话"进化到了"会做事"。 Function Calling的工作原理 Function Calling的本质其实很简单：大模型被训练成能够输出结构化的JSON，而不是自由文本。 具体流程是这样的： 你定义一组"工具"（函数），每个工具包含名称、描述、参数schema。比如一个天气查询工具，参数包括城市名和日期。 当你向大模型发送请求时，这些工具定义会一起发送给模型。 模型分析你的请求，如果判断需要调用某个工具，它会输出一个JSON格式的函数调用——包含工具名称和参数值。 你的应用程序执行这个函数调用，获取结果（比如天气数据），然后把结果返回给模型。 模型根据工具返回的结果，生成最终的自然语言回复。 整个过程，模型本身并不执行任何代码——它只是"决定"调用哪个函数以及传什么参数。实际执行是由你的应用程序完成的。 模型是怎么学会函数调用的？ 这涉及到两个层面的训练： 指令微调（Instruction Tuning）：在模型训练阶段，给模型大量"用户请求-函数调用-结果-回复"的四元组数据。模型学习到：当用户说"查天气"的时候，应该输出一个调用天气工具的JSON；当工具返回结果后，应该把结果整理成自然语言。 格式约束（Format Constraints）：在推理时，通过logit bias或grammar约束，强制模型输出符合JSON Schema的文本。这确保了模型输出的函数调用是可以被解析的。 2026年，大多数模型（GPT-4o、Claude 4、Gemini 2.5、Qwen-3、DeepSeek-V3）都原生支持函数调用，不需要额外的微调。 两个关键的技术挑战 幻觉函数调用（Hallucinated Function Calls）：模型可能会调用一个不存在的函数，或者给函数传递不存在的参数。这在2023-2024年非常普遍，但在2026年已经有了显著改善——通过更好的训练数据和更严格的格式约束，幻觉率从10-15%降低到了2-3%。 函数调用的时机判断：模型需要判断什么时候应该调用函数，什么时候不应该。一个过度激进的模型可能会在不该调用函数的时候调用函数（比如用户只是在闲聊）；一个过度保守的模型可能在需要调用函数的时候不调用。 Function Calling vs 传统编程 Function Calling正在改变我们构建应用的方式。传统编程中，你需要写大量的if-else逻辑来处理各种用户意图。有了Function Calling，你只需要定义好工具，模型会自动判断用户的意图并选择合适的工具。 这本质上是将"意图识别"和"参数提取"这两个任务从规则系统转移到了大模型身上。对于复杂、多变的用户需求，这比传统方法灵活得多。 2026年的进化方向 Function Calling正在向几个方向进化：从单次调用到多轮链式调用（模型可以连续调用多个工具完成复杂任务）；从文本参数到多模态参数（直接传入图片、音频）；从预定义工具到动态工具发现（模型可以自己查找和选择合适的API）。 Function Calling不是终点，而是通往真正AI Agent的第一步。掌握它，你就掌握了让AI"做事"的能力。

坑0：我天真地以为Function Calling很简单 三个月前，我接了一个项目：给一个内部客服系统加上Function Calling，让用户可以查询订单、退换货、修改地址。我看了文档，觉得很简单——定义几个函数，让模型调用就行了。 三个月后，系统终于稳定了。但中间踩了无数坑。以下是我踩过的10个最大的坑，希望能帮你少走弯路。 坑1：模型调用了一个不存在的函数 这是最经典的坑。你定义了get_order_status函数，但模型自作主张调用了cancel_order（你没有定义这个函数）。当你的代码试图执行这个不存在的函数时，整个流程就崩溃了。 解决方案：不要信任模型输出的函数名。在调用前，始终验证函数名是否在你定义的函数列表中。如果模型调用了不存在的函数，返回一个友好的错误信息，让模型重新选择。 坑2：参数类型不匹配 模型给一个需要整数的参数传了字符串"3"，给一个需要日期格式的参数传了"明天"。你的JSON解析器会直接崩溃。 解决方案：在你的函数实现中做好参数校验和类型转换。不要假设模型传的参数一定是正确的。 坑3：模型在不需要调用函数时调用了函数 用户说"你好"，模型调用了get_order_status，传了一个空参数。这让用户困惑，也让系统浪费了资源。 解决方案：在system prompt中明确告诉模型"只在用户明确需要执行操作时调用函数"。也可以设置一个"置信度阈值"——如果模型不确信应该调用函数，就不要调用。 坑4：模型在需要调用函数时不调用 用户说"我上周买的那个东西怎么还没到"，模型应该调用get_order_status，但它没有——它开始编造一些通用的安慰话术。 解决方案：在system prompt中给模型明确的指引——“当用户询问订单、物流、售后等具体问题时，你必须调用相应的函数获取真实信息，不要编造。” 坑5：函数调用结果太大，超出了上下文窗口 你调用了一个函数，返回了10000条订单记录。当你想把这个结果传回给模型时，发现超出了上下文窗口限制。 解决方案：在函数层面做好数据过滤和截断。只返回最相关的信息，而不是全量数据。如果结果确实很大，使用分页或多轮交互。 坑6：多轮函数调用中的状态丢失 模型先调用了get_order_list获取订单列表，然后想调用get_order_detail查看某个订单详情。但在第二轮调用中，它"忘记"了第一轮获取的订单ID。 解决方案：在系统中维护一个会话状态，记录已获取的信息。在prompt中保留关键的历史信息。 坑7：函数定义的描述不够清晰 你的函数描述写了"查询订单信息"，但模型不知道这个函数可以查询哪些信息、需要什么参数、返回什么格式。结果模型要么不调用，要么传错参数。 解决方案：花时间写好函数描述。包括：这个函数做什么、什么情况下应该调用、每个参数的含义和格式、返回值的格式。一个好的函数描述应该像一份微型的API文档。 坑8：并行调用导致的竞态条件 模型同时调用了get_order_status和get_user_info，但get_user_info依赖于get_order_status返回的user_id。你的代码并行执行了两个调用，结果get_user_info因为缺少user_id而失败。 解决方案：如果函数之间有依赖关系，设计为串行调用。在prompt中引导模型"先调用函数A获取信息，再根据结果调用函数B"。 坑9：安全和权限问题 模型可以调用delete_order函数，但你不希望任何用户都能删除订单。某用户通过精心设计的prompt，让模型代为调用了delete_order。 解决方案：在函数执行层面做好权限控制，不要依赖模型来"判断"用户是否有权限。敏感操作（删除、修改、支付）需要额外的用户确认。 坑10：函数调用的成本 每次函数调用都是一次额外的API请求，都会产生费用。如果你的应用有大量用户，函数调用的成本可能会超出预期。 解决方案：设计好函数调用的策略。对常见问题做缓存，减少不必要的函数调用。使用更便宜的模型做函数调用判断，只用强模型做最终回复。 总结 Function Calling是一个强大的工具，但它不是魔法。它需要仔细的设计、充分的测试和持续的优化。如果你准备在项目中引入Function Calling，请记住这10个坑——它们可能帮你省下三个月的时间。

一个常见场景 用户：“帮我查一下北京、上海、广州、深圳、杭州、成都、武汉、南京、重庆、西安明天和后天的天气。” 你的AI需要调用20次天气API（10个城市×2天）。如果串行调用，每次1秒，总共需要20秒。用户不可能等这么久。 这就是并行函数调用的价值。通过同时发起多个独立的函数调用，你可以将总延迟从"所有调用延迟之和"降低到"最慢的那次调用延迟"。 并行调用的条件 不是所有函数调用都可以并行。并行调用的前提是：函数之间没有依赖关系。 可以并行的情况：查询多个城市的天气、同时搜索航班和酒店、获取多个用户的资料。 不可以并行的情况：先查用户ID，再用ID查订单详情；先查商品库存，再根据库存决定是否下单。 模型需要能够判断哪些函数调用可以并行，哪些必须串行。2026年，Claude 4和Gemini 2.5 Pro在并行调用判断上的准确率最高，达到90%以上。 实现并行调用的三种方式 方式一：模型输出多个函数调用。 2026年，主流模型都支持在一次响应中返回多个函数调用。你解析这些调用，然后并行执行。这是最直接的方式。 方式二：应用层并行化。 模型只输出一个函数调用，但应用层识别出这个调用可以被"展开"为多个并行调用。比如，模型调用search_flights函数，传了多个目的地——应用层把它拆分为多个独立的API请求。 方式三：流水线并行。 对于有依赖关系的函数调用，使用流水线并行——不等所有第一阶段调用完成，只要一个调用的结果出来，就立即启动依赖它的第二阶段调用。 并行调用的三大陷阱 陷阱一：模型"忘记"了并行调用中有哪些。 当你同时给模型返回10个函数调用的结果时，模型可能会混淆不同结果对应的调用。这会导致模型在生成回复时用错信息。 解决方案：在返回结果时，给每个结果附加明确的标识信息（如"北京的天气：晴天，25°C"），帮助模型区分。 陷阱二：部分调用失败的处理。 10个并行调用中，有2个失败了。模型是否应该等所有调用完成后再生成回复，还是先基于已完成的结果生成部分回复？ 解决方案：根据场景决定。对于信息查询，可以等所有调用完成后生成统一回复。对于实时交互，可以先基于成功的结果回复，然后补充失败的信息。 陷阱三：Token消耗的暴增。 10个并行函数调用的结果可能非常长。把它们全部塞进上下文，可能导致token消耗暴增，甚至超出上下文窗口。 解决方案：对函数返回结果做摘要和截断。只返回最相关的信息，而不是全量数据。 并行调用的性能优化 限制并行度：不是越多越好。并行调用太多，可能导致后端API过载，或者返回结果太长无法处理。建议将并行度限制在5-10个以内。 设置超时：每个并行调用都应该有独立的超时。如果有调用超时，不等它，直接基于已完成的调用生成回复。 使用流式处理：当第一个调用结果返回时，立即开始流式生成回复，而不是等所有调用完成。 2026年的趋势 并行函数调用正在从"高级功能"变成"标配"。2026年的新趋势包括：自动并行化（模型自动识别哪些调用可以并行）、智能分批（模型自动将大量调用分成合理的批次）、以及优先级调度（对关键调用优先执行）。 如果你正在构建Function Calling系统，现在是时候开始考虑并行调用了。这可能是将用户等待时间从10秒降到2秒的关键。

我们要构建什么 假设我们要构建一个"AI旅行助手"，用户可以： 查询航班信息（出发地、目的地、日期） 查询酒店信息（城市、日期、预算） 查询天气（城市、日期） 预订机票和酒店（需要用户确认） 我们将通过这个案例，展示Function Calling系统的完整设计和实现过程。 第一步：函数设计 这是最关键的一步。函数设计的好坏，直接决定了Function Calling系统的成败。每个函数需要包含三个要素： 清晰的名称：模型通过函数名来理解函数的作用。名称应该简洁、明确、遵循动词+名词的命名规范。如search_flights、search_hotels、get_weather、book_flight。 详细的描述：描述是这个函数的设计文档。它应该包含：函数做什么、什么情况下应该调用、返回什么信息。一个好的描述示例： search_flights: 搜索可用的航班。当用户想查询航班信息时调用此函数。 参数： - origin: 出发城市，支持中文城市名和IATA机场代码 - destination: 目的地城市，支持中文城市名和IATA机场代码 - date: 出发日期，格式为YYYY-MM-DD 返回：航班列表，每个航班包含航班号、出发时间、到达时间、价格、剩余座位数 合理的参数设计：参数应该包含必需参数和可选参数。必需参数是函数执行的最小信息集，可选参数用于过滤和排序。参数类型应该明确（string、integer、boolean、enum等）。 第二步：对话流程设计 我们的旅行助手需要处理以下对话流程： 用户表达需求（“我想下周五去成都”） 模型识别到需要调用search_flights函数 模型提取参数：origin需要询问（用户没提供出发城市），destination=成都，date=下周五的日期 模型生成回复询问出发城市 用户回答"上海" 模型调用search_flights(origin=“上海”, destination=“成都”, date=“2026-07-17”) 系统执行函数调用，返回航班列表 模型将航班列表整理成友好的回复展示给用户 这个流程中，第4步是关键的——模型需要识别出参数不完整，并且主动询问缺失的信息。这是Function Calling系统设计中最容易被忽视但最重要的环节。 第三步：错误处理设计 我们的系统需要处理以下错误场景： 函数调用失败：后端API返回错误。此时应该将错误信息反馈给模型，让模型决定是重试还是告知用户。 参数不完整：模型应该能够识别出参数缺失，并询问用户。 参数不合法：用户说了"下个月32号"，模型应该能识别出这是一个无效日期。 超过预算：用户说"预算200元"，但搜索结果都是500元以上。模型应该告知用户实际情况，并询问是否调整预算。 第四步：安全设计 对于book_flight和book_hotel这类写入操作，我们的设计原则是： 在调用这些函数之前，必须向用户确认关键信息（航班号、时间、价格） 函数调用需要携带用户的授权token，后端验证token的有效性 所有预订操作记录到审计日志 第五步：对话管理 多轮对话中，模型需要记住之前获取的信息。比如： 用户先查了航班，然后说"帮我看看那边的酒店" 模型需要知道"那边"指的是目的地城市 在系统设计中，我们需要在对话历史中保留关键信息，确保模型在后续对话中能够正确引用。 实战心得 经过这个案例的实践，我们总结了三条最重要的经验： 函数描述比你想的更重要。花时间写清楚函数描述，比花时间调模型参数更有效。 错误处理不是可选项。用户不会按照你的预期路径使用系统，错误处理的设计决定了系统的鲁棒性。 安全是设计出来的。Function Calling系统的安全不能靠"事后加防护"，必须在系统设计之初就纳入考虑。 如果你准备构建自己的Function Calling系统，希望这个案例能给你提供一个可参考的框架。

一个常见的误解 “我们的系统用了Function Calling，所以它是一个AI Agent。” 这句话在2026年的AI圈非常常见，但它是错误的。Function Calling和Agent是两个完全不同层次的概念。把它们混为一谈，会导致架构设计上的根本性错误。 函数调用：模型的"手" 函数调用（Function Calling）是一个能力层概念。它描述的是：大模型能够输出结构化的指令，告诉外部系统"我想执行这个操作"。 函数调用的核心特征是：模型只负责"决策"（调用哪个函数、传什么参数），不负责"执行"。执行是由应用程序完成的。而且，函数调用是单次的——模型调用一个函数，得到结果，然后生成回复。流程到此结束。 把函数调用想象成模型的"手"——它让模型能够"触碰"外部世界，但模型本身并不理解"为什么要做这件事"和"这件事做完后应该做什么"。 Agent：模型的"大脑+手+记忆" Agent是一个系统层概念。它包含函数调用，但远远不止函数调用。 一个完整的Agent系统包含以下组件： 规划（Planning）：Agent能够将复杂任务分解为多个子任务，并制定执行计划。这需要模型具备"推理"能力——理解任务的本质，拆解步骤，预判结果。 记忆（Memory）：Agent有短期记忆（当前对话的上下文）和长期记忆（历史对话、用户偏好、知识库）。这让Agent能够"记住"之前发生的事情，并基于记忆做出决策。 工具使用（Tool Use）：这就是函数调用部分。Agent能够调用外部工具来获取信息或执行操作。 反思（Reflection）：Agent能够评估自己的执行结果，判断是否达到了目标。如果没有，它会调整策略，重新尝试。 自主性（Autonomy）：Agent能够在一定范围内自主决策，不需要用户对每一步进行确认。 一个具体的例子 假设用户说：“帮我安排一次和客户张总的会面，下周的任何时间都可以，需要在公司附近找一个安静的咖啡厅。” 仅用函数调用：模型调用calendar_query函数查询下周空闲时间，然后调用map_search函数搜索咖啡厅，然后把结果展示给用户，让用户自己选择。模型不做任何决策，只是信息的中转站。 使用Agent：Agent自动查询日历，发现周二下午2-4点和周四上午10-12点空闲。然后自动搜索公司附近的咖啡厅，根据评分、距离、安静程度筛选出3个候选。接着自动发邮件给张总，提议周二下午2点在某咖啡厅见面。如果张总回复说这个时间不行，Agent自动调整为周四。整个过程不需要用户干预。 什么时候该用函数调用，什么时候该用Agent？ 函数调用适合的场景： 单一、明确的任务（查天气、查订单、翻译文本） 用户需要保持控制权的场景（金融交易、医疗诊断） 成本敏感的场景（Agent的多轮调用成本更高） Agent适合的场景： 复杂的多步骤任务（旅行规划、研究分析、代码开发） 需要自主决策的场景（自动客服、自动化运维） 用户愿意委托的场景（个人助理、自动化的重复性工作） 一个重要的安全提示 Agent的自主性是一把双刃剑。它越自主，就越强大，但也越危险。一个能够自主发送邮件、删除文件、修改数据库的Agent，如果被恶意利用或被模型幻觉误导，可能造成严重的后果。 2026年，Agent安全已经成为一个独立的研究方向。在构建Agent系统时，安全边界的设计应该是第一优先级，而不是事后的补丁。 最终建议 如果你只是想让模型能够查询一些外部数据，用函数调用就够了。如果你想让模型能够自主完成复杂任务，再考虑Agent。 记住：函数调用是Agent的组成部分，但不是Agent的全部。把函数调用做好了，再考虑Agent也不迟。

一个被忽视的真相 在Function Calling的实践中，我们做了一个对比实验：用同一个模型（GPT-4o），但分别用"草率写就"和"精心设计"的函数Schema，测试准确率。 结果令人震惊：草率Schema的准确率只有72%，而精心设计的Schema达到了94%。差距如此之大，以至于我们重新审视了函数Schema设计的重要性。 Schema设计的黄金法则 法则一：函数名是模型的"路标"。 函数名是模型选择函数的第一依据。一个好的函数名应该：使用动词+名词格式（如search_products、get_weather、create_order）；避免缩写（用get_user_profile而不是get_usr_prof）；避免过于通用的名称（用search_flights而不是search）。 法则二：函数描述是微型的用户手册。 函数描述不只是给开发者看的，更是给模型看的。一个好的描述应该包含三部分：这个函数做什么（一句话概括）、什么情况下应该调用（使用场景）、调用后返回什么（返回值格式）。 法则三：参数描述要具体，不要抽象。 不要写"用户ID"，要写"用户的唯一标识符，可以在用户个人资料页面的URL中找到，格式为’usr_‘开头后跟10位数字"。 不要写"日期"，要写"查询日期，格式为YYYY-MM-DD，例如2026-07-13。如果不提供，默认为今天"。 法则四：使用枚举值约束参数。 如果一个参数只有几个固定选项，用enum来约束，而不是让模型自由发挥。比如： "status": { "type": "string", "enum": ["pending", "processing", "shipped", "delivered", "cancelled"], "description": "订单状态" } 法则五：提供示例值。 在参数描述中提供示例值，可以帮助模型更好地理解参数的格式和含义。特别是对于日期、ID、复杂对象等参数。 常见Schema设计错误 错误一：函数描述过于笼统。 “查询信息的函数”——什么信息？什么时候用？返回什么？模型完全不知道。 错误二：参数描述缺失。 只有一个参数名，没有任何描述。模型只能靠猜。 错误三：多个函数的功能重叠。 search_products和find_products和query_products都做同样的事。模型不知道该选哪个。 错误四：必需参数和可选参数没有区分。 所有参数都标记为required，或者所有参数都标记为optional。模型无法判断哪些信息是必须的。 错误五：Schema与实际API不一致。 Schema说参数是string，但实际API需要integer。或者Schema没有包含某个参数，但实际API需要。 Schema设计的测试方法 写好Schema后，需要用测试来验证。我们推荐以下测试方法： 单元测试：对每个函数，构造10个典型的用户请求，检查模型是否正确选择函数和提取参数。 边界测试：构造模糊的、不完整的、矛盾的请求，检查模型的处理是否正确。 回归测试：每次修改Schema后，重新跑一遍测试集，确保没有引入新的问题。 A/B测试：如果你不确定两种Schema设计哪种更好，用A/B测试来验证——让一部分用户使用Schema A，另一部分使用Schema B，对比实际效果。 进阶技巧 渐进式函数发现：如果函数太多（超过20个），可以考虑渐进式发现——先展示函数类别，用户选择类别后再展示具体函数。 函数优先级提示：在system prompt中给出函数调用的优先级指引，帮助模型在相似函数之间做出选择。 动态Schema：根据用户的历史行为和当前上下文，动态调整Schema——只展示当前场景下最相关的函数。 结论 在Function Calling中，Schema设计是最被低估的环节。一个好的Schema可以把一个平庸的模型变成优秀的工具使用者，而一个差的Schema可以毁掉最好的模型。在你花时间比较模型之前，先花时间优化你的Schema。

失败是常态 在Function Calling系统的实际运行中，函数调用失败的概率比你想象的要高。根据我们的统计，在一个生产环境中，大约15-20%的函数调用会遇到某种形式的失败。 这些失败包括：参数错误（模型传了不正确的参数）、API超时（后端服务响应慢）、API返回错误（权限不足、资源不存在等）、模型幻觉（调用了不存在的函数）、参数缺失（模型没有提供必需参数）。 如果没有完善的错误处理机制，这些失败会导致糟糕的用户体验——系统卡住、回复错误、反复重试。 错误分类和分级 我们将函数调用错误分为三个级别： L1-可自动恢复：参数格式错误（如日期格式不对）、参数值轻微偏差（如"北京"vs"北京市"）。这些错误可以通过自动修正来解决。 L2-需要模型理解：API返回了一个有意义但非预期的结果（如"该航班已售罄"）。模型需要理解这个结果并调整策略。 L3-需要人工介入：权限错误、系统错误、数据异常。这些错误超出了模型的处理能力，需要人工介入。 错误处理框架 Step 1: 参数验证。 在函数执行前，先验证参数的有效性。日期格式、枚举值、数值范围、字符串长度等。如果参数无效，返回具体的错误信息给模型。 Step 2: 优雅降级。 如果某个函数调用失败，不要让整个对话崩溃。给用户一个友好的回复，解释发生了什么，并提供替代方案。 Step 3: 智能重试。 对于可自动恢复的错误（L1），自动修正参数后重试。对于L2和L3错误，不要盲目重试——把错误信息反馈给模型，让模型决定下一步。 Step 4: 超时处理。 每个函数调用都应该有超时设置。如果API在2秒内没有响应，返回超时信息给模型，让模型决定是等待还是换一个方案。 Step 5: 降级路径。 如果主函数调用失败，尝试备选方案。比如，如果实时天气API失败了，尝试用缓存的数据；如果缓存也没有，就告知用户"暂时无法获取天气信息"。 模型在错误处理中的角色 模型在错误处理中扮演着"决策者"的角色。当函数调用失败时，模型需要： 理解错误信息（“这个航班已售罄"意味着什么？） 决定下一步策略（换一个航班？换一个日期？换一个目的地？） 与用户沟通（告知用户实际情况，征求用户意见） 这要求模型具备一定的"推理"能力，而不仅仅是"调用函数"的能力。2026年，Claude 4和GPT-4o在错误处理上的表现最好，它们能够理解复杂的错误信息并做出合理的决策。 实战案例 场景一：参数错误。 用户说"查一下北京明天的天气”，模型调用get_weather(city=“北京”, date=“tomorrow”)。API返回错误：“date必须是YYYY-MM-DD格式”。模型理解错误信息，自动修正为get_weather(city=“北京”, date=“2026-07-14”)，重试成功。 场景二：API返回"售罄"。 用户想订某个航班，模型调用book_flight，API返回"该航班已售罄"。模型理解售罄的含义，查询同航线其他航班，返回给用户：“抱歉，您选择的航班已售罄。以下是同一航线其他可用的航班…” 场景三：API超时。 模型调用search_hotels，API在2秒内没有响应。系统返回超时信息给模型。模型告诉用户：“酒店搜索系统目前响应较慢，请稍等片刻，我正在重试…” 错误处理的设计原则 快速失败：不要等待不可靠的API。设置合理的超时，快速失败，快速反馈。 用户知情：不要让用户不知道发生了什么。当函数调用失败时，告知用户，并提供替代方案。 优雅降级：即使部分功能不可用，系统的基本功能仍然应该正常工作。 记录和告警：记录所有函数调用失败的日志，设置告警规则。如果某个函数的失败率突然升高，应该立即通知到运维团队。 结论 函数调用失败不是"bug"，而是系统设计的一部分。一个好的错误处理机制，可以让你的Function Calling系统在大部分失败场景下仍然保持可用。如果你还没有认真的错误处理设计，现在就是时候了。

一场意外的评测 我们原本只是想为自己的项目选一个Function Calling能力最强的模型。但当我们对比了市面上的公开评测后，发现大部分评测都太简单了——只测试了单一函数调用，没有覆盖多函数、嵌套调用、错误恢复等复杂场景。 于是我们决定自己设计一套评测。100个测试用例，覆盖8个难度级别，6个主流模型。测试结果让我们重新审视了Function Calling的格局。 评测设计 测试模型：GPT-4o、Claude 4 Sonnet、Gemini 2.5 Pro、Qwen3-235B、DeepSeek-V3、Llama-4 Maverick 测试场景： 简单单一函数调用（如"查天气"） 带可选参数的函数调用（如"搜索商品，可以按价格排序"） 多函数选择（如"这可能是查订单也可能是查物流"） 并行函数调用（如"同时查天气和查新闻"） 链式函数调用（如"先查用户ID，再根据ID查订单"） 错误恢复（如"函数调用失败后能否正确重试"） 模糊需求（如"帮我看看那个东西怎么样了"） 多轮对话中的函数调用 评测结果 综合排名： Claude 4 Sonnet：准确率94%。在复杂场景（多函数选择、链式调用、错误恢复）中表现最稳定，几乎没有幻觉函数调用。 GPT-4o：准确率91%。在简单场景中无可挑剔，但在模糊需求场景中偶尔会"过度自信"——在本该要求用户澄清时直接调用了函数。 Gemini 2.5 Pro：准确率89%。在并行调用上表现最好，但在错误恢复场景中偶尔会"陷入循环"——反复调用同一个失败的函数。 Qwen3-235B：准确率86%。中文场景的Function Calling表现最好，但英文场景略逊于前三名。 DeepSeek-V3：准确率82%。在链式调用上表现出色，但函数选择的准确性有待提升。 Llama-4 Maverick：准确率78%。开源模型中的最佳表现，但与闭源模型仍有明显差距。 关键发现 发现一：函数调用能力与模型大小不完全正相关。 Claude 4 Sonnet（中等规模）在函数调用上超越了更大规模的GPT-4o和Gemini 2.5 Pro。这说明函数调用更多取决于训练策略和微调质量，而非模型大小。 发现二：中文函数调用仍然是一个短板。 除了Qwen3，其他模型在中文场景的函数调用准确率比英文场景低5-10个百分点。如果你主要服务中文用户，Qwen3是目前最好的选择。 发现三：并行调用是2026年的新战场。 2025年，大多数模型还只能做单次函数调用。2026年，并行调用已经成为标配。但不同模型的并行调用质量差异很大——Claude 4和Gemini 2.5表现最好，其他模型经常会"忘记"并行调用中有哪些已经完成。 发现四：错误恢复是区分优秀和普通模型的关键。 当函数调用失败时，优秀模型会分析失败原因并调整策略，普通模型会"放弃"并生成一个模糊的回复。 选择建议 如果你追求综合最佳：Claude 4 Sonnet是目前Function Calling综合能力最强的模型。 如果你主要服务中文用户：Qwen3-235B的中文Function Calling能力独树一帜。 如果你需要大量并行调用：Gemini 2.5 Pro在并行调用场景下表现最优。 如果你在成本敏感的场景：DeepSeek-V3的性价比最高，虽然准确率略低，但价格只有GPT-4o的1/5。 如果你是开源路线的拥趸：Llama-4 Maverick是开源模型中最值得关注的选择。 最后的提醒 Function Calling的能力评测不是一劳永逸的。模型在不断更新，评测结果也在不断变化。建议你在自己的实际场景中做一次"微评测"——用10-20个真实用户请求测试不同模型的表现，这比任何公开评测都更有参考价值。