Function Calling是让大模型调用函数的关键技术但实际应用中存在诸多挑战。本文系统介绍了Function Calling的原理、演进过程以及在实际Agent系统中的应用。重点讨论了如何通过工具入口治理、工具执行治理、上下文与收敛治理、安全与授权治理等策略来提升Function Calling的稳定性帮助开发者构建更加可靠的大模型应用。最近遭遇知识诅咒了在做培训的时候会发现一个情况我们以为的常识在其他人看来是卡点而因为这种卡点多了整体学习效果就很差而今天要聊的“常识性卡点是 Function Calling”…我第一次接触 Function Calling是一个天气查询 Demo。用户问一句天气模型返回一个get_weather应用层查完天气再把结果交给模型生成回答。流程一跑通很容易让人觉得它就是一个函数调用而且大模型终于可以接入业务系统了。于是乎 Function Calling 很容易被讲成一句话让模型调用函数。但我们在做 Agent 系统的时候才发现它是一点都不简单查天气时回答错了系统还能接受。换成订单、地址、退款、数据库写入错一次就可能改到真实业务状态模型拿不到订单号怎么办超时后反复查同一笔订单怎么办高风险动作被误触发又由谁拦下来所以我们自己在做实践的时候是把 Function Calling 看成一个入口。它让模型用结构化方式表达调用意图至于这个意图能不能执行、什么时候执行、失败以后怎么处理、风险动作要不要确认那已经是 Agent 工具治理的问题。于是今天我们来系统性聊聊 Function CallingFunction Calling 是什么在 Function Calling 出现之前如果想让大模型触发外部函数办法其实很直接在提示词里约定输出 JSON外部程序再解析这段 JSON根据返回的函数名和参数调用真实函数。我们可以在系统提示词中这样写道用户输入北京今天天气怎么样理想情况下模型会返回下面的 JSON{ action: get_weather, city: 北京, date: 今天 }我们需要设计一个外部程序来解析这个 JSON 提取函数名和参数然后再去执行这个工具调用天气API获取实时的天气数据。这个流程其实没有啥问题唯一的缺点就是模型输出不稳定。特别是早期模型推理能力还不够强的时候它不会严格按照我们提示词中的JSON格式输出。我们在测试的时候 经常看到下面这种格式的内容输出:在 JSON 前后夹带自然语言用 Markdown 代码块包裹结果漏字段写错字段类型输出看起来像 JSON、实际上无法解析的内容。这些问题都会让我们的程序解析报错我们不得不写一些工具函数来清洗模型返回的JSON去掉多余自然语言、删除 Markdown 代码块、修复格式错误、做字段类型转换必要时还要兜底重试请求模型返回新的JSON。所以单靠提示词让模型稳定输出可解析JSON结构并不可靠。早期形态2023 年 6 月 13 日OpenAI 引入 Function Calling 能力接口中主要使用两个参数functions用于向模型描述可用函数。function_call用于控制模型是否调用函数或者要求模型调用某个指定函数。开发者可以通过 JSON 向模型描述函数名称、用途和参数结构。模型根据用户输入判断是否需要调用函数并生成符合 Schema 的参数。例如一个天气查询函数可以这样描述如果模型判断需要查询天气它会返回一个函数调用请求这里返回是模型训练的结果去年下半年在工具识别这里比上半年强很多但要注意这里返回的是 JSON 字符串并没有去做调用调用 API 的是应用层我们的业务后台他拿到上面的完整工具 JSON 对象后要先解析函数名和参数再校验参数是否合法然后再调用真实天气服务。工具结果回来以后还要把结果放回消息上下文再次请求模型生成最终回答。也就是说模型只是返回了一张结构化调用单执行和兜底都在应用层。工具调用体系到 2023 年 11 月OpenAI 对 FC 做了进一步演进这个阶段有两个明显变化模型可以在一轮回复中发起多个函数调用。接口形式逐渐从 functions 和 function_call 演进为更通用的 tools 和 tool_choice。新的写法大致如下模型返回结构也发生了变化早期返回的是单个 function_call 字段后来返回的是 tool_calls 数组多个 tool_calls 的价值在于一个订单问题可能同时要查订单、查物流这些调用并行起来延迟就不会被单方面拖住。字段也从 function_call 变成 tool_calls说明模型正在从单个函数调用走向通用工具调用体系。到这一步function 更像 tool它可能是函数、文件、浏览器操作、代码执行器甚至另一个 Agent。其他模型厂商的跟进随着工具调用能力越来越重要其他模型厂商也陆续支持了类似机制。例如包括 Claude、DeepSeek 等。不同模型厂商的字段名称、协议和返回结构都不太一样。但不管如何变化开发者要处理的事情并没有改变一个完整的调用流程如下先把工具定义清楚 再交给模型判断是否需要调用 由应用层执行对应工具 把执行结果重新放回上下文 最后让模型基于新信息继续推理直到任务完成。这个流程正是 Agent 工具调用的基础。稳定格式Function Calling 最大的变化是以前要靠提示词去约束输出 JSON现在接口直接返回定义好的字段。应用层不需要再费劲从自然语言里拆函数名和参数了可以直接从接口返回的字段中获取函数名称和对应的参数。不管是之前的JSON还是现在的Function Calling 都是模型输出工具的方式它并没有解决工具调用之后的一系列工程问题它选的工具是对的吗参数是不是可信执行失败以后怎么办这些问题都还存在工具执行不能稳定的执行。我们可以从三个层面来理解 Function Calling 的稳定性第一层是格式稳定。模型返回的是结构化字段应用层可以拿到工具名、参数和调用 ID这个已经由模型厂商返回的Function Calling解决第二层是语义稳定。模型要在一组工具里选对那个工具参数也要来自用户输入、上下文或上游工具结果不能靠猜。第三层是执行稳定。工具真的跑起来以后会遇到超时、权限、业务状态、高风险动作、循环调用这些问题。这些已经超出模型返回格式本身必须交给运行时兜住。Agent 是如何使用工具的如果把 Function Calling 放进 Agent 里看它会变成一轮一轮推进的循环。这个循环通常叫 Agent Loop。从上图可以看出Agent Loop 是一个由模型驱动的运行时循环应用层把用户消息、系统提示词、历史上下文和工具列表一起发给模型。模型判断是否需要调用工具。如果模型返回工具调用请求应用层执行对应工具。应用层把工具结果追加到消息上下文中。再次请求模型。模型继续判断是否需要下一次工具调用。直到模型不再返回工具调用请求循环结束。一般聊天机器人主要生成文本Agent需要在生成文本和调用工具之间来回切换。真实调用过程如果只看天气查询Function Calling 会被理解成一次工具调用用户问天气如何模型就返回get_weather这个工具调用应用层执行工具把结果交回给模型。线上业务可不是这么简单的一次工具调用例如帮我把这个订单的收货地址改成新地址。Agent收到用户的请求后并不会马上调用一个修改地址的工具。它要先确认用户说的是哪一个订单在历史会话里面去找订单信息还要根据订单信息判断目前还能不能修改地址当前用户有没有权限去修改订单的地址。如果不能修改地址系统还要把业务状态返回给模型让模型解释为什么不能修改好让用户明白这个事情为什么不能做。一个看起来很普通的用户请求再进入 Agent 系统以后背后都是一条真实的运行时链路。传统业务系统里流程都是写死的。查订单检查订单状态修改地址。每一步什么时候执行开发者已经提前写好了。Agent 不一样。它没有一条完全固定的执行路径。每一步调用哪个工具都是模型根据当前上下文临时判断出来的。这种方式比较灵活由模型自己决策业务流程怎么走选择哪些工具来执行这就会带来一些不可控的风险模型选错工具 模型生成的参数不合法 工具执行失败 工具结果太长超出上下文 模型一直调用工具不停止 高风险工具被误用 ......我们可以把这些问题都归纳为四种运行时治理能力工具入口治理工具执行治理上下文与收敛治理安全与授权治理。Agent 能不能稳定运行很大程度上取决于运行时有没有把这几个治理功能做好。Agent 工具治理工具治理的核心就是保证工具执行的稳定性。工具入口治理入口治理就是工具在执行之前由运行时系统主动做检查。主要看这2个问题模型是否选对工具返回的参数是否正确。我们可以在工具调用之前尽量把这些问题解决下面这几个方法可以试一试工具定义要清晰工具定义不要有歧义在写工具说明的时候可以根据下面几个说明来写这个工具做什么什么时候应该用什么时候不要用参数从哪里来不能怎么填。下面这个定义就过于模糊{ name: query, description: 查询信息 }这个写法人看了都摇头模型就更加看不懂了在来看下面这个例子是不是就清晰很多。工具定义越清楚模型越不需要猜。单次暴露给模型的工具不要太多模型在 10 个工具里做选择和在 100 个工具里做选择难度不在一个级别上。OpenAI 官方文档里面也明确说明最多可访问 128 个工具。从工程实践看工具多了之后选择本身就会慢慢变成检索和路由问题。实际在做Agent系统时我平时一般大致按下面这个数量评估风险工具越多模型越容易犯一些低级错误挑一个语义相近但其实不对的工具、不该调工具的时候也去调、或者把本来最合适的那个给忽略了。生产环境里没人会一次性把所有工具都丢给模型通常都会先做裁剪。我见过这几种做法比较实用按业务域动态加载根据当前任务所需领域只加载相关工具集先检索再调用从工具库中检索 Top‑K 个最相关工具再交给模型选择职责固定的 Agent 拆分为每个 Agent 分配明确边界和固定工具集各司其职。给模型明确的工具选择规则除了工具定义本身还可以在系统提示词里加入工具选择规则例如参数必须做运行时校验模型给出的参数不一定总是合法的执行前应用层必须做参数校验。可以通过工具定义的参数信息检查必填字段、字段类型、枚举值、业务约束等相关信息是否符合字段的定义约束。如果参数检查不通过系统不能只返回一个笼统的失败信息。我们需要返回结构化错误并说明原因让模型判断下一步要怎么做是修正参数还是向用户追问缺失的信息。例如{ success: false, error_type: invalid_arguments, message: order_id is required, retryable: false, suggested_action: ask_user_for_order_id }工具执行治理我们在工具调用前已经做了必要的检查但是工具执行失败仍然会发生,外部系统出错超时权限不足业务状态不对等传统软件里失败后常见做法是重试但 Agent 的工具执行不能这么简单地一刀切需要根据不同错误类型选择不同策略。我们梳理了常见的错误类型invalid_arguments参数错误timeout超时或临时不可用permission_denied权限不足business_rule_violation业务规则不允许unknown_error未知异常。不同类型的错误处理策略完全不同。参数错误工具如果缺少必填字段字段类型不对这类错误继续重试一点用都没有。我们应该把错误结构化返回给模型让模型知道那个参数有问题具体错误是什么引导模型重新生成参数。超时错误调用工具出现网络超时、第三方服务临时不可用的时候一般我们可以设置自动重试需要有一定的规则限制不能无限重试消耗资源短间隔重试限制最大次数重试仍失败后把结果回给模型由模型决定是否向用户解释、是否改走其他路径。权限错误如果遇到权限错误就不能让模型自己发挥了需要有一套机制来处理权限问题例如禁止自动重试禁止自动提权明确告诉模型当前没有权限必要时要求用户授权或切换账号。业务规则错误如果用户要求取消订单但是业务系统显示订单已经发货。取消订单这个操作就执行失败了 系统需要将失败原因详细返回给模型让模型能向用户解释原因。高风险动作失败我们线上有个原则扣款、退款、删数据、改权限、发通知这类动作如果调用失败重试是最危险的。必须同时做审计日志、幂等控制防止重复执行、自动失败后转人工处理并且要把最终状态推给用户。如果工具返回错误只是一句 调用失败模型就会懵掉它就不知道下一步要怎么办了就会自己胡乱的重试。我们需要把错误类型、失败原因、能不能重试、是否需要用户介入这些信息通过结构化的方式返回给模型模型才能判断下一步要怎么做。上下文与收敛治理前面我们讨论了工具执行前和执行中的治理逻辑Agent在运行的时候还有2个显著的问题工具返回的数据不断累加模型上下文不断增多模型反复调用工具一直无法收敛循环停止条件当模型无法收敛、出现无限循环执行时可以采用以下几种最基本的控制策略最大推理轮数最大工具调用次数单任务最长执行时间单任务最大调用成本在设计 Agent 系统时需要在程序中显式实现上述规则。一旦 Agent 的执行达到任一规则设定的阈值系统应主动终止循环并向用户返回终止执行的详细说明。控制工具结果进入上下文工具结果应避免原样添加回上下文。 特别是搜索、数据库查询、文件读取、网页抓取等工具返回内容往往过长容易导致上下文溢出或干扰模型推理。更稳一点可以这样处理限制单次工具结果长度对冗长结果做摘要压缩只把与当前任务相关的片段放回上下文对不重要的中间结果仅保留摘要核心原则是让模型在做下一步决策时拥有足够且有用的信息进行推理。工具结果结构化我们在设计工具的时候对工具的返回信息不能简单的就返回一句话而是要为Agent的工具进行统一的结构化设计所有工具都返回同样的格式 比如下面这种工具执行失败时返回 错误类型错误信息是否重试下一步建议等。{ success: false, error_type: order_not_found, message: 未找到该订单, retryable: false, suggested_action: ask_user_to_check_order_id }工具执行成功时也一样把模型下一步会用到的信息整理出来。比如订单状态、是否允许退款、是否允许改地址等。{ success: true, order_id: 123, status: shipped, can_change_address: false, can_refund: true, next_actions: [explain_address_change_unavailable, offer_refund_help] }这样做的好处是模型不需要从一段业务文本里重新推断状态。工具结果越结构化Agent Loop 下一步越容易稳定。识别重复调用如果模型连续多次调用同一个工具并且参数都是一样的正常情况一般都是陷入了死循环。例如get_order_detail(order_id123) get_order_detail(order_id123) get_order_detail(order_id123)这类调用看起来还在工作但是对模型完成任务已经没有一点帮助。在设计Agent系统时可以考虑增加以下规则识别重复调用模式直接复用已有结果提示模型不要重复调用必要时中止循环。安全与授权治理对于高风险工具的调用我们必须设计一套安全授权机制不能让模型随意调用。保证业务数据安全避免线上业务事故工具安全分类我们常用的方法时对工具进行分类把不同的工具设置分组到不同的风险等级中风险等级示例处理方式低风险查询订单、搜索文档、读取知识库可直接执行中风险生成草稿、创建待确认任务、修改临时状态可执行但要记录日志高风险发送邮件、提交订单、修改用户资料执行前必须用户确认不可逆风险删除数据、退款、转账、修改权限必须审批或双重确认这个分好了之后系统在执行工具的时候就可以根据工具的安全分类采取不同的执行策越。高风险工具手动确认当模型返回一个高风险工具的调用时必须要通过用户手动授权才能去执行工具这个需要在系统中设计一个高风险工具执行的流程。一般我们会讲工具执行的信息发给用户确认用户确认后才能执行如果用户拒绝执行需要把拒绝的行为明确告诉模型。用流程约束降低越权风险我们在设计工具的时候可以根据业务流程来细分工具。例如退款流程我们可以给一个 submit_refund 这种直接退款的工具但是这样就有一些问题这个单子能不能退款退款金额是多少大模型就不知道了用户确认的时候也不能给出足够的信息让用户判断是否能够执行退款操作。我们不如将流程拆分为多个细粒度的工具get_order_detail – 获取订单详情 check_refund_eligibility – 检查退款资格 create_refund_draft – 创建退款草稿 submit_refund_after_confirmation – 确认后提交退款 query_refund_status – 查询退款状态模型必须依次调用这些工具模型可以获取更多的信息来推理和显示同时也无法一步就直接退款。这就从流程上约束了越权风险。此外还可以按当前流程阶段动态加载相关工具比如在 确认资格 阶段只暴露前两个工具完成后再加载后续工具。这样既避免了把所有工具一次性交给模型也让业务执行更加可控、稳健。这里关于工具整理的话题就差不多了我们再额外思考一个问题为什么业务工具不能直接使用后端 API业务工具问题当我们需要把我们的业务改造成Agent系统时多数人的第一反应都是直接把后端已有 API 封装成工具交给模型使用。方便快捷也不用二次开发。这种只能作为早期 Demo 通常不能直接用在生产环境上。后端 API 面向程序接口语义宽一点也没关系人能看懂就行工具面向模型它要帮助模型在上下文里判断该不该用、参数能不能补齐、失败后怎么解释等。所以后端 API 和 Agent 工具之间通常需要一层专门的工具适配层我们需要重新设计一套业务工具提供给大模型具体完成业务的还是后端的API。比如后端有一个订单更新的接口POST /api/order/update它可以接收很多参数修改订单状态修改订单金额还可以修改订单的商品信息物流信息等。如果直接把它暴露成一个update_order工具模型很容易犯糊涂这个工具语义太宽、参数太复杂、风险边界也不清楚。我们面向模型设计工具时需要按照业务动作来设计工具update_order_address cancel_order add_order_remark confirm_order_refund工具要简单、职责单一模型就很容易做出判断和选择。工具参数也不能直接复用接口字段需要先分清楚哪些信息该可以让模型来生成再按照执行动作所需把必要的字段暴露出来。按照来源工具参数可以分成三类用户明确提供的信息如订单ID、退款原因模型能从上下文可靠提取的如当前选中的商品只能由系统自动补齐的信息如 产品标识、trace_id前两类可以出现在工具参数里第三类运行时自动补齐。工具调用稳定性工具调用的稳定性一直以来都是 Agent 的热门难点所以怎么判断 FC 是否稳定呢这里就不能只看 Demo了因为 Demo 通常路径很短工具也少用户问题也比较标准但生产环境里的问题更乱用户的表达更是千奇百怪这里复杂性就变高了。我会看这几个指标。工具选择稳定性。同一个用户意图模型能不能稳定选到正确工具。如果用户问订单物流状况正常应该调用物流查询工具。如果它有时查询订单详情、有时又去查知识库出现模型不知道改选谁的情况可能就是这两个工具相似性太高了。参数生成稳定性。模型输出调用工具的参数是否正常比如必填字段有没有缺具体数据提取的怎么样。失败恢复能力。工具调用失败这个很正常我们必须要考虑工具执行失败返回的信息是不是对模型下一步推理有用让模型能够继续执行完成用户的任务。 我们需要把工具失败的信息 进行分类和结构化的数组让模型明白失败的原因是什么。循环收敛能力。Agent Loop 是否会重复调用同一个工具是否会在没有新信息时继续消耗资源是否能在达到阈值后给用户一个清楚的状态说明。一个 Agent 看起来很努力地调用工具不代表它真的在推进任务。高风险动作拦截能力。涉及退款、删除、付款、权限修改、发送通知这些高风险工具调用时系统是否稳定触发确认、审批这一类动作。这里不能依赖模型自觉必须由运行时来兜底。结语篇幅差不多了收下尾。如果只看接口定义Function Calling 一点都不复杂开发者把工具定义描述给模型模型返回工具名和参数应用层执行工具再把结果返回给上下文一个调用流程就走完了。这里看着简单Demo 牛逼结果上线就完蛋的 Agent 项目还挺多的。这也是 Agent 开发真正的难点了如何构造一个 Agent 能够稳定的工程环境当然这个话题我们下次再继续大模型的知识又多又杂到底怎么学做这行久了被问最多的问题就一个大模型的知识又多又杂我到底先学啥翻了一堆资料看啥都像重点结果啥都没学进去。今天把我自己一路摸出来的顺序捋一遍零基础、应届生、转行的都适用。跟着走至少方向不乱、不瞎忙学完拿得出手。第一阶段10天初阶应用这一阶段就一个目标把大模型真正玩明白不是只会聊天那种而是能调教它、能用代码把大模型和业务接起来。大模型 AI 能干什么大模型是怎样获得「智能」的用好 AI 的核心心法大模型应用业务架构大模型应用技术架构代码示例向 GPT-3.5 灌入新知识提示工程的意义和核心思想Prompt 典型构成指令调优方法论思维链和思维树Prompt 攻击和防范…第二阶段30天高阶应用这阶段正式进实战目标很实在做出两个能拿出手的东西——一个私有知识库一个 agent 对话机器人。为什么要做 RAG搭建一个简单的 ChatPDF检索的基础概念什么是向量表示Embeddings向量数据库与向量检索基于向量检索的 RAG搭建 RAG 系统的扩展知识混合检索与 RAG-Fusion 简介向量模型本地部署…走完这 30 天Python 或 JavaScript 背景的基本能独立做一套 RAG 应用简历上也敢写大模型应用开发了。第三阶段约20天动手微调学到这你已经开始 “造” 模型了 —— 通过微调搞出垂直领域的专用小模型。为什么要做 RAG什么是模型什么是模型训练求解器 损失函数简介小实验2手写一个简单的神经网络并训练它什么是训练/预训练/微调/轻量化微调Transformer结构简介轻量化微调实验数据集的构建…恭喜你如果学到这里你基本可以找到一份大模型 AI相关的工作自己也能训练 GPT 了通过微调训练自己的垂直大模型能独立训练开源多模态大模型掌握更多技术方案。到此为止大概2个月的时间。你从 “只会用” 变成 “能造” 的 AI 小子。那么你还想往下探索吗想要入局AI大模型赛道、抢占行业红利的朋友微信扫描下方CSDN官方认证二维码即可100%免费领取全套学习资料第四阶段20天商业闭环部署落地技术学完落地才算数。这阶段带你搞明白大模型怎么真正跑起来、用起来。硬件选型带你了解全球大模型使用国产大模型服务搭建 OpenAI 代理热身基于阿里云 PAI 部署 Stable Diffusion在本地计算机运行大模型大模型的私有化部署基于 vLLM 部署大模型案例如何优雅地在阿里云私有部署开源大模型部署一套开源 LLM 项目内容安全互联网信息服务算法备案…想要入坑大模型的朋友给大家准备了一份2026 年最新 AI 大模型全套学习资料1、大模型系统化学习路线2、大模型学习视频教程3、大模型学习书籍电子文档4、AI大模型最新行业报告5、大模型项目实战配套源码6、2026大模型大厂面试真题7、为什么要学习大模型我国在A大模型领域面临人才短缺,数量与质量均落后于发达国家。2023年人才缺口已超百万凸显培养不足。随着AI技术飞速发展预计到2025年,这一缺口将急剧扩大至400万,严重制约我国AI产业的创新步伐。加强人才培养,优化教育体系,国际合作并进是破解困局、推动AI发展的关键。8、适合谁学传统后端 / Java / 前端开发想转型 AI 应用大学生、应届生想拿更好的 offer产品经理、运营想武装职业竞争力技术负责人想给团队落地提效学习是反人性的但回报是真金白银。技术会更新赛道会切换但只要你先动手机会就永远站在你这边。9、这些资料真的有用吗这份资料由我和鲁为民博士(北京清华大学学士和美国加州理工学院博士)共同整理现任上海殷泊信息科技CEO其创立的MoPaaS云平台获Forrester全球’强劲表现者’认证服务航天科工、国家电网等1000企业以第一作者在IEEE Transactions发表论文50篇获NASA JPL火星探测系统强化学习专利等35项中美专利。本套AI大模型课程由清华大学-加州理工双料博士、吴文俊人工智能奖得主鲁为民教授领衔研发。资料内容涵盖了从入门到进阶的各类视频教程和实战项目无论你是小白还是有些技术基础的技术人员这份资料都绝对能帮助你提升薪资待遇转行大模型岗位。想要入局AI大模型赛道、抢占行业红利的朋友微信扫描下方CSDN官方认证二维码即可100%免费领取全套学习资料好了就写到这。路线是死的人是活的卡住了随时来问我。觉得有用就点个收藏别让它进收藏夹吃灰——动起来比啥都强。
Function Calling是让大模型调用函数的关键技术但实际应用中存在诸多挑战。本文系统介绍了Function Calling的原理、演进过程以及在实际Agent系统中的应用。重点讨论了如何通过工具入口治理、工具执行治理、上下文与收敛治理、安全与授权治理等策略来提升Function Calling的稳定性帮助开发者构建更加可靠的大模型应用。最近遭遇知识诅咒了在做培训的时候会发现一个情况我们以为的常识在其他人看来是卡点而因为这种卡点多了整体学习效果就很差而今天要聊的“常识性卡点是 Function Calling”…我第一次接触 Function Calling是一个天气查询 Demo。用户问一句天气模型返回一个get_weather应用层查完天气再把结果交给模型生成回答。流程一跑通很容易让人觉得它就是一个函数调用而且大模型终于可以接入业务系统了。于是乎 Function Calling 很容易被讲成一句话让模型调用函数。但我们在做 Agent 系统的时候才发现它是一点都不简单查天气时回答错了系统还能接受。换成订单、地址、退款、数据库写入错一次就可能改到真实业务状态模型拿不到订单号怎么办超时后反复查同一笔订单怎么办高风险动作被误触发又由谁拦下来所以我们自己在做实践的时候是把 Function Calling 看成一个入口。它让模型用结构化方式表达调用意图至于这个意图能不能执行、什么时候执行、失败以后怎么处理、风险动作要不要确认那已经是 Agent 工具治理的问题。于是今天我们来系统性聊聊 Function CallingFunction Calling 是什么在 Function Calling 出现之前如果想让大模型触发外部函数办法其实很直接在提示词里约定输出 JSON外部程序再解析这段 JSON根据返回的函数名和参数调用真实函数。我们可以在系统提示词中这样写道用户输入北京今天天气怎么样理想情况下模型会返回下面的 JSON{ action: get_weather, city: 北京, date: 今天 }我们需要设计一个外部程序来解析这个 JSON 提取函数名和参数然后再去执行这个工具调用天气API获取实时的天气数据。这个流程其实没有啥问题唯一的缺点就是模型输出不稳定。特别是早期模型推理能力还不够强的时候它不会严格按照我们提示词中的JSON格式输出。我们在测试的时候 经常看到下面这种格式的内容输出:在 JSON 前后夹带自然语言用 Markdown 代码块包裹结果漏字段写错字段类型输出看起来像 JSON、实际上无法解析的内容。这些问题都会让我们的程序解析报错我们不得不写一些工具函数来清洗模型返回的JSON去掉多余自然语言、删除 Markdown 代码块、修复格式错误、做字段类型转换必要时还要兜底重试请求模型返回新的JSON。所以单靠提示词让模型稳定输出可解析JSON结构并不可靠。早期形态2023 年 6 月 13 日OpenAI 引入 Function Calling 能力接口中主要使用两个参数functions用于向模型描述可用函数。function_call用于控制模型是否调用函数或者要求模型调用某个指定函数。开发者可以通过 JSON 向模型描述函数名称、用途和参数结构。模型根据用户输入判断是否需要调用函数并生成符合 Schema 的参数。例如一个天气查询函数可以这样描述如果模型判断需要查询天气它会返回一个函数调用请求这里返回是模型训练的结果去年下半年在工具识别这里比上半年强很多但要注意这里返回的是 JSON 字符串并没有去做调用调用 API 的是应用层我们的业务后台他拿到上面的完整工具 JSON 对象后要先解析函数名和参数再校验参数是否合法然后再调用真实天气服务。工具结果回来以后还要把结果放回消息上下文再次请求模型生成最终回答。也就是说模型只是返回了一张结构化调用单执行和兜底都在应用层。工具调用体系到 2023 年 11 月OpenAI 对 FC 做了进一步演进这个阶段有两个明显变化模型可以在一轮回复中发起多个函数调用。接口形式逐渐从 functions 和 function_call 演进为更通用的 tools 和 tool_choice。新的写法大致如下模型返回结构也发生了变化早期返回的是单个 function_call 字段后来返回的是 tool_calls 数组多个 tool_calls 的价值在于一个订单问题可能同时要查订单、查物流这些调用并行起来延迟就不会被单方面拖住。字段也从 function_call 变成 tool_calls说明模型正在从单个函数调用走向通用工具调用体系。到这一步function 更像 tool它可能是函数、文件、浏览器操作、代码执行器甚至另一个 Agent。其他模型厂商的跟进随着工具调用能力越来越重要其他模型厂商也陆续支持了类似机制。例如包括 Claude、DeepSeek 等。不同模型厂商的字段名称、协议和返回结构都不太一样。但不管如何变化开发者要处理的事情并没有改变一个完整的调用流程如下先把工具定义清楚 再交给模型判断是否需要调用 由应用层执行对应工具 把执行结果重新放回上下文 最后让模型基于新信息继续推理直到任务完成。这个流程正是 Agent 工具调用的基础。稳定格式Function Calling 最大的变化是以前要靠提示词去约束输出 JSON现在接口直接返回定义好的字段。应用层不需要再费劲从自然语言里拆函数名和参数了可以直接从接口返回的字段中获取函数名称和对应的参数。不管是之前的JSON还是现在的Function Calling 都是模型输出工具的方式它并没有解决工具调用之后的一系列工程问题它选的工具是对的吗参数是不是可信执行失败以后怎么办这些问题都还存在工具执行不能稳定的执行。我们可以从三个层面来理解 Function Calling 的稳定性第一层是格式稳定。模型返回的是结构化字段应用层可以拿到工具名、参数和调用 ID这个已经由模型厂商返回的Function Calling解决第二层是语义稳定。模型要在一组工具里选对那个工具参数也要来自用户输入、上下文或上游工具结果不能靠猜。第三层是执行稳定。工具真的跑起来以后会遇到超时、权限、业务状态、高风险动作、循环调用这些问题。这些已经超出模型返回格式本身必须交给运行时兜住。Agent 是如何使用工具的如果把 Function Calling 放进 Agent 里看它会变成一轮一轮推进的循环。这个循环通常叫 Agent Loop。从上图可以看出Agent Loop 是一个由模型驱动的运行时循环应用层把用户消息、系统提示词、历史上下文和工具列表一起发给模型。模型判断是否需要调用工具。如果模型返回工具调用请求应用层执行对应工具。应用层把工具结果追加到消息上下文中。再次请求模型。模型继续判断是否需要下一次工具调用。直到模型不再返回工具调用请求循环结束。一般聊天机器人主要生成文本Agent需要在生成文本和调用工具之间来回切换。真实调用过程如果只看天气查询Function Calling 会被理解成一次工具调用用户问天气如何模型就返回get_weather这个工具调用应用层执行工具把结果交回给模型。线上业务可不是这么简单的一次工具调用例如帮我把这个订单的收货地址改成新地址。Agent收到用户的请求后并不会马上调用一个修改地址的工具。它要先确认用户说的是哪一个订单在历史会话里面去找订单信息还要根据订单信息判断目前还能不能修改地址当前用户有没有权限去修改订单的地址。如果不能修改地址系统还要把业务状态返回给模型让模型解释为什么不能修改好让用户明白这个事情为什么不能做。一个看起来很普通的用户请求再进入 Agent 系统以后背后都是一条真实的运行时链路。传统业务系统里流程都是写死的。查订单检查订单状态修改地址。每一步什么时候执行开发者已经提前写好了。Agent 不一样。它没有一条完全固定的执行路径。每一步调用哪个工具都是模型根据当前上下文临时判断出来的。这种方式比较灵活由模型自己决策业务流程怎么走选择哪些工具来执行这就会带来一些不可控的风险模型选错工具 模型生成的参数不合法 工具执行失败 工具结果太长超出上下文 模型一直调用工具不停止 高风险工具被误用 ......我们可以把这些问题都归纳为四种运行时治理能力工具入口治理工具执行治理上下文与收敛治理安全与授权治理。Agent 能不能稳定运行很大程度上取决于运行时有没有把这几个治理功能做好。Agent 工具治理工具治理的核心就是保证工具执行的稳定性。工具入口治理入口治理就是工具在执行之前由运行时系统主动做检查。主要看这2个问题模型是否选对工具返回的参数是否正确。我们可以在工具调用之前尽量把这些问题解决下面这几个方法可以试一试工具定义要清晰工具定义不要有歧义在写工具说明的时候可以根据下面几个说明来写这个工具做什么什么时候应该用什么时候不要用参数从哪里来不能怎么填。下面这个定义就过于模糊{ name: query, description: 查询信息 }这个写法人看了都摇头模型就更加看不懂了在来看下面这个例子是不是就清晰很多。工具定义越清楚模型越不需要猜。单次暴露给模型的工具不要太多模型在 10 个工具里做选择和在 100 个工具里做选择难度不在一个级别上。OpenAI 官方文档里面也明确说明最多可访问 128 个工具。从工程实践看工具多了之后选择本身就会慢慢变成检索和路由问题。实际在做Agent系统时我平时一般大致按下面这个数量评估风险工具越多模型越容易犯一些低级错误挑一个语义相近但其实不对的工具、不该调工具的时候也去调、或者把本来最合适的那个给忽略了。生产环境里没人会一次性把所有工具都丢给模型通常都会先做裁剪。我见过这几种做法比较实用按业务域动态加载根据当前任务所需领域只加载相关工具集先检索再调用从工具库中检索 Top‑K 个最相关工具再交给模型选择职责固定的 Agent 拆分为每个 Agent 分配明确边界和固定工具集各司其职。给模型明确的工具选择规则除了工具定义本身还可以在系统提示词里加入工具选择规则例如参数必须做运行时校验模型给出的参数不一定总是合法的执行前应用层必须做参数校验。可以通过工具定义的参数信息检查必填字段、字段类型、枚举值、业务约束等相关信息是否符合字段的定义约束。如果参数检查不通过系统不能只返回一个笼统的失败信息。我们需要返回结构化错误并说明原因让模型判断下一步要怎么做是修正参数还是向用户追问缺失的信息。例如{ success: false, error_type: invalid_arguments, message: order_id is required, retryable: false, suggested_action: ask_user_for_order_id }工具执行治理我们在工具调用前已经做了必要的检查但是工具执行失败仍然会发生,外部系统出错超时权限不足业务状态不对等传统软件里失败后常见做法是重试但 Agent 的工具执行不能这么简单地一刀切需要根据不同错误类型选择不同策略。我们梳理了常见的错误类型invalid_arguments参数错误timeout超时或临时不可用permission_denied权限不足business_rule_violation业务规则不允许unknown_error未知异常。不同类型的错误处理策略完全不同。参数错误工具如果缺少必填字段字段类型不对这类错误继续重试一点用都没有。我们应该把错误结构化返回给模型让模型知道那个参数有问题具体错误是什么引导模型重新生成参数。超时错误调用工具出现网络超时、第三方服务临时不可用的时候一般我们可以设置自动重试需要有一定的规则限制不能无限重试消耗资源短间隔重试限制最大次数重试仍失败后把结果回给模型由模型决定是否向用户解释、是否改走其他路径。权限错误如果遇到权限错误就不能让模型自己发挥了需要有一套机制来处理权限问题例如禁止自动重试禁止自动提权明确告诉模型当前没有权限必要时要求用户授权或切换账号。业务规则错误如果用户要求取消订单但是业务系统显示订单已经发货。取消订单这个操作就执行失败了 系统需要将失败原因详细返回给模型让模型能向用户解释原因。高风险动作失败我们线上有个原则扣款、退款、删数据、改权限、发通知这类动作如果调用失败重试是最危险的。必须同时做审计日志、幂等控制防止重复执行、自动失败后转人工处理并且要把最终状态推给用户。如果工具返回错误只是一句 调用失败模型就会懵掉它就不知道下一步要怎么办了就会自己胡乱的重试。我们需要把错误类型、失败原因、能不能重试、是否需要用户介入这些信息通过结构化的方式返回给模型模型才能判断下一步要怎么做。上下文与收敛治理前面我们讨论了工具执行前和执行中的治理逻辑Agent在运行的时候还有2个显著的问题工具返回的数据不断累加模型上下文不断增多模型反复调用工具一直无法收敛循环停止条件当模型无法收敛、出现无限循环执行时可以采用以下几种最基本的控制策略最大推理轮数最大工具调用次数单任务最长执行时间单任务最大调用成本在设计 Agent 系统时需要在程序中显式实现上述规则。一旦 Agent 的执行达到任一规则设定的阈值系统应主动终止循环并向用户返回终止执行的详细说明。控制工具结果进入上下文工具结果应避免原样添加回上下文。 特别是搜索、数据库查询、文件读取、网页抓取等工具返回内容往往过长容易导致上下文溢出或干扰模型推理。更稳一点可以这样处理限制单次工具结果长度对冗长结果做摘要压缩只把与当前任务相关的片段放回上下文对不重要的中间结果仅保留摘要核心原则是让模型在做下一步决策时拥有足够且有用的信息进行推理。工具结果结构化我们在设计工具的时候对工具的返回信息不能简单的就返回一句话而是要为Agent的工具进行统一的结构化设计所有工具都返回同样的格式 比如下面这种工具执行失败时返回 错误类型错误信息是否重试下一步建议等。{ success: false, error_type: order_not_found, message: 未找到该订单, retryable: false, suggested_action: ask_user_to_check_order_id }工具执行成功时也一样把模型下一步会用到的信息整理出来。比如订单状态、是否允许退款、是否允许改地址等。{ success: true, order_id: 123, status: shipped, can_change_address: false, can_refund: true, next_actions: [explain_address_change_unavailable, offer_refund_help] }这样做的好处是模型不需要从一段业务文本里重新推断状态。工具结果越结构化Agent Loop 下一步越容易稳定。识别重复调用如果模型连续多次调用同一个工具并且参数都是一样的正常情况一般都是陷入了死循环。例如get_order_detail(order_id123) get_order_detail(order_id123) get_order_detail(order_id123)这类调用看起来还在工作但是对模型完成任务已经没有一点帮助。在设计Agent系统时可以考虑增加以下规则识别重复调用模式直接复用已有结果提示模型不要重复调用必要时中止循环。安全与授权治理对于高风险工具的调用我们必须设计一套安全授权机制不能让模型随意调用。保证业务数据安全避免线上业务事故工具安全分类我们常用的方法时对工具进行分类把不同的工具设置分组到不同的风险等级中风险等级示例处理方式低风险查询订单、搜索文档、读取知识库可直接执行中风险生成草稿、创建待确认任务、修改临时状态可执行但要记录日志高风险发送邮件、提交订单、修改用户资料执行前必须用户确认不可逆风险删除数据、退款、转账、修改权限必须审批或双重确认这个分好了之后系统在执行工具的时候就可以根据工具的安全分类采取不同的执行策越。高风险工具手动确认当模型返回一个高风险工具的调用时必须要通过用户手动授权才能去执行工具这个需要在系统中设计一个高风险工具执行的流程。一般我们会讲工具执行的信息发给用户确认用户确认后才能执行如果用户拒绝执行需要把拒绝的行为明确告诉模型。用流程约束降低越权风险我们在设计工具的时候可以根据业务流程来细分工具。例如退款流程我们可以给一个 submit_refund 这种直接退款的工具但是这样就有一些问题这个单子能不能退款退款金额是多少大模型就不知道了用户确认的时候也不能给出足够的信息让用户判断是否能够执行退款操作。我们不如将流程拆分为多个细粒度的工具get_order_detail – 获取订单详情 check_refund_eligibility – 检查退款资格 create_refund_draft – 创建退款草稿 submit_refund_after_confirmation – 确认后提交退款 query_refund_status – 查询退款状态模型必须依次调用这些工具模型可以获取更多的信息来推理和显示同时也无法一步就直接退款。这就从流程上约束了越权风险。此外还可以按当前流程阶段动态加载相关工具比如在 确认资格 阶段只暴露前两个工具完成后再加载后续工具。这样既避免了把所有工具一次性交给模型也让业务执行更加可控、稳健。这里关于工具整理的话题就差不多了我们再额外思考一个问题为什么业务工具不能直接使用后端 API业务工具问题当我们需要把我们的业务改造成Agent系统时多数人的第一反应都是直接把后端已有 API 封装成工具交给模型使用。方便快捷也不用二次开发。这种只能作为早期 Demo 通常不能直接用在生产环境上。后端 API 面向程序接口语义宽一点也没关系人能看懂就行工具面向模型它要帮助模型在上下文里判断该不该用、参数能不能补齐、失败后怎么解释等。所以后端 API 和 Agent 工具之间通常需要一层专门的工具适配层我们需要重新设计一套业务工具提供给大模型具体完成业务的还是后端的API。比如后端有一个订单更新的接口POST /api/order/update它可以接收很多参数修改订单状态修改订单金额还可以修改订单的商品信息物流信息等。如果直接把它暴露成一个update_order工具模型很容易犯糊涂这个工具语义太宽、参数太复杂、风险边界也不清楚。我们面向模型设计工具时需要按照业务动作来设计工具update_order_address cancel_order add_order_remark confirm_order_refund工具要简单、职责单一模型就很容易做出判断和选择。工具参数也不能直接复用接口字段需要先分清楚哪些信息该可以让模型来生成再按照执行动作所需把必要的字段暴露出来。按照来源工具参数可以分成三类用户明确提供的信息如订单ID、退款原因模型能从上下文可靠提取的如当前选中的商品只能由系统自动补齐的信息如 产品标识、trace_id前两类可以出现在工具参数里第三类运行时自动补齐。工具调用稳定性工具调用的稳定性一直以来都是 Agent 的热门难点所以怎么判断 FC 是否稳定呢这里就不能只看 Demo了因为 Demo 通常路径很短工具也少用户问题也比较标准但生产环境里的问题更乱用户的表达更是千奇百怪这里复杂性就变高了。我会看这几个指标。工具选择稳定性。同一个用户意图模型能不能稳定选到正确工具。如果用户问订单物流状况正常应该调用物流查询工具。如果它有时查询订单详情、有时又去查知识库出现模型不知道改选谁的情况可能就是这两个工具相似性太高了。参数生成稳定性。模型输出调用工具的参数是否正常比如必填字段有没有缺具体数据提取的怎么样。失败恢复能力。工具调用失败这个很正常我们必须要考虑工具执行失败返回的信息是不是对模型下一步推理有用让模型能够继续执行完成用户的任务。 我们需要把工具失败的信息 进行分类和结构化的数组让模型明白失败的原因是什么。循环收敛能力。Agent Loop 是否会重复调用同一个工具是否会在没有新信息时继续消耗资源是否能在达到阈值后给用户一个清楚的状态说明。一个 Agent 看起来很努力地调用工具不代表它真的在推进任务。高风险动作拦截能力。涉及退款、删除、付款、权限修改、发送通知这些高风险工具调用时系统是否稳定触发确认、审批这一类动作。这里不能依赖模型自觉必须由运行时来兜底。结语篇幅差不多了收下尾。如果只看接口定义Function Calling 一点都不复杂开发者把工具定义描述给模型模型返回工具名和参数应用层执行工具再把结果返回给上下文一个调用流程就走完了。这里看着简单Demo 牛逼结果上线就完蛋的 Agent 项目还挺多的。这也是 Agent 开发真正的难点了如何构造一个 Agent 能够稳定的工程环境当然这个话题我们下次再继续大模型的知识又多又杂到底怎么学做这行久了被问最多的问题就一个大模型的知识又多又杂我到底先学啥翻了一堆资料看啥都像重点结果啥都没学进去。今天把我自己一路摸出来的顺序捋一遍零基础、应届生、转行的都适用。跟着走至少方向不乱、不瞎忙学完拿得出手。第一阶段10天初阶应用这一阶段就一个目标把大模型真正玩明白不是只会聊天那种而是能调教它、能用代码把大模型和业务接起来。大模型 AI 能干什么大模型是怎样获得「智能」的用好 AI 的核心心法大模型应用业务架构大模型应用技术架构代码示例向 GPT-3.5 灌入新知识提示工程的意义和核心思想Prompt 典型构成指令调优方法论思维链和思维树Prompt 攻击和防范…第二阶段30天高阶应用这阶段正式进实战目标很实在做出两个能拿出手的东西——一个私有知识库一个 agent 对话机器人。为什么要做 RAG搭建一个简单的 ChatPDF检索的基础概念什么是向量表示Embeddings向量数据库与向量检索基于向量检索的 RAG搭建 RAG 系统的扩展知识混合检索与 RAG-Fusion 简介向量模型本地部署…走完这 30 天Python 或 JavaScript 背景的基本能独立做一套 RAG 应用简历上也敢写大模型应用开发了。第三阶段约20天动手微调学到这你已经开始 “造” 模型了 —— 通过微调搞出垂直领域的专用小模型。为什么要做 RAG什么是模型什么是模型训练求解器 损失函数简介小实验2手写一个简单的神经网络并训练它什么是训练/预训练/微调/轻量化微调Transformer结构简介轻量化微调实验数据集的构建…恭喜你如果学到这里你基本可以找到一份大模型 AI相关的工作自己也能训练 GPT 了通过微调训练自己的垂直大模型能独立训练开源多模态大模型掌握更多技术方案。到此为止大概2个月的时间。你从 “只会用” 变成 “能造” 的 AI 小子。那么你还想往下探索吗想要入局AI大模型赛道、抢占行业红利的朋友微信扫描下方CSDN官方认证二维码即可100%免费领取全套学习资料第四阶段20天商业闭环部署落地技术学完落地才算数。这阶段带你搞明白大模型怎么真正跑起来、用起来。硬件选型带你了解全球大模型使用国产大模型服务搭建 OpenAI 代理热身基于阿里云 PAI 部署 Stable Diffusion在本地计算机运行大模型大模型的私有化部署基于 vLLM 部署大模型案例如何优雅地在阿里云私有部署开源大模型部署一套开源 LLM 项目内容安全互联网信息服务算法备案…想要入坑大模型的朋友给大家准备了一份2026 年最新 AI 大模型全套学习资料1、大模型系统化学习路线2、大模型学习视频教程3、大模型学习书籍电子文档4、AI大模型最新行业报告5、大模型项目实战配套源码6、2026大模型大厂面试真题7、为什么要学习大模型我国在A大模型领域面临人才短缺,数量与质量均落后于发达国家。2023年人才缺口已超百万凸显培养不足。随着AI技术飞速发展预计到2025年,这一缺口将急剧扩大至400万,严重制约我国AI产业的创新步伐。加强人才培养,优化教育体系,国际合作并进是破解困局、推动AI发展的关键。8、适合谁学传统后端 / Java / 前端开发想转型 AI 应用大学生、应届生想拿更好的 offer产品经理、运营想武装职业竞争力技术负责人想给团队落地提效学习是反人性的但回报是真金白银。技术会更新赛道会切换但只要你先动手机会就永远站在你这边。9、这些资料真的有用吗这份资料由我和鲁为民博士(北京清华大学学士和美国加州理工学院博士)共同整理现任上海殷泊信息科技CEO其创立的MoPaaS云平台获Forrester全球’强劲表现者’认证服务航天科工、国家电网等1000企业以第一作者在IEEE Transactions发表论文50篇获NASA JPL火星探测系统强化学习专利等35项中美专利。本套AI大模型课程由清华大学-加州理工双料博士、吴文俊人工智能奖得主鲁为民教授领衔研发。资料内容涵盖了从入门到进阶的各类视频教程和实战项目无论你是小白还是有些技术基础的技术人员这份资料都绝对能帮助你提升薪资待遇转行大模型岗位。想要入局AI大模型赛道、抢占行业红利的朋友微信扫描下方CSDN官方认证二维码即可100%免费领取全套学习资料好了就写到这。路线是死的人是活的卡住了随时来问我。觉得有用就点个收藏别让它进收藏夹吃灰——动起来比啥都强。
