LLM 基础 Function Call 能力强化：从数据构建到 RLHF 的优化闭环

01

为什么 Function Call 是 LLM 落地的关键？

1. 定义与价值

Function Call 能力是大模型实现实际应用的关键特性之一，从概念上讲，Function Call 是指大模型能够按照预定义的格式输出对工具的调用指令，通常以 JSON 格式进行表示，该 JSON 请求中包含所需调用的工具名称以及对应的参数信息，外部的框架或执行引擎在解析该请求后，即可明确大模型希望调用的具体工具及其参数，并据此完成工具的实际调用操作，通过引入 Function Call 能力，大模型实现了从仅输出文本的模型，向具备工具调用能力的执行引擎的转变。

这个升级的核心价值在于能够弥补大模型自身的一些局限性，首先最明显的是它突破了大模型的知识边界，众所周知，大模型在训练完成之后，其知识体系即已固定，无法动态更新，同时在一些专业领域的知识覆盖上也可能存在不足，而通过 Function Call 的方式，大模型可以调用外部的 API，例如搜索类 API 或金融领域的专业数据库 API，从而有效缓解这一问题。

另一个重要的价值在于，基于 Function Call 能力可以构建完整的自动化 Agent 执行链路，从而实现任务流程的闭环执行。例如用户提出“我要去北京的机票”的需求，该执行链路即可利用 Function Call 能力完成订票、查询酒店等一系列操作流程，进而实现真正帮助用户解决实际问题的目标，当然，这类能力的实现需要依赖特定的框架支持，例如 Auto GPT 或 LangChain 等工具链，通过这些框架，大模型能够按照任务需求依次调用多个工具，形成连续执行的智能行为，这种能力使用户能够直观感受到大模型能力边界的不断拓展，它不再仅仅是一个纯文本输出的模型，而是进化为一个能够执行实际任务的智能助手，这也正是 Function Call 能力所体现的核心价值。

2. 场景与痛点

目前主流的 Function Call 应用场景主要包括实时数据查询，例如前述的搜索 API，以及天气、股票等动态信息的 API 调用，通过这些方式，大模型能够获取动态更新的结果，从而弥补其知识静态性的不足；此外还包括一些自动化任务的执行，如前述的订酒店等场景；还有一类重要的应用场景是企业的系统集成，例如进行数据库操作、系统级任务处理以及复杂计算任务的处理，例如在某些专业的数学计算或领域分析任务中，大模型本身的能力仍存在一定局限，其准确率和稳定性可能无法满足实际需求，此时如果能够将这些功能封装为标准的 API 接口，并由大模型通过 Function Call 的方式进行调用，就能够更加稳定、可靠地完成相关任务。

Function Call 技术在实际应用中仍存在一些常见问题，这也是我们提出相关优化方法的原因之一。首先，在实时数据查询场景中，存在调用参数错误的问题，例如用户要求预订前往上海的机票，模型却在参数中传递了北京的信息，导致出现调用偏差，这种现象类似于“幻觉”；其次，在生成 API 调用指令时，模型有时会编造并不存在的 API 接口进行调用，造成执行失败；此外，还存在工具调用依赖关系混乱的问题。在一些复杂任务场景中，多个工具之间可能存在明确的调用顺序或依赖关系，例如在调用工具 A 之前必须先调用工具 B，但大模型可能未能正确识别此类依赖关系，导致调用链路缺失或执行顺序错误。这些都是当前 Function Call 技术在实际应用中较为常见的问题。

基于上述特性可以看出，优化基础的 Function Call 能力是推动大模型在实际应用中落地的关键环节之一。因此，本次分享将从以下三个角度展开：首先是数据角度，其次是训练优化角度，最后将简要介绍当前较为热门的 Agent 应用方案，作为 Function Call 能力在实际场景中的延伸与落地实践。

02

核心算法优化方案-数据

首先，我们从数据角度出发介绍 Function Call 能力的优化方式。在大模型时代，数据的重要性是毋庸置疑的，甚至可以说，只有具备高质量的训练数据，才能训练出具有良好表现的大模型。对于 Function Call 场景而言，其所需的数据相较于普通的 QA 类大模型数据更加复杂，构建的难度更大，涉及的处理链路更长，整体成本也更高，同时在数据质量的验证方面也更具挑战性。

1. 拆解当前场景大模型 Function Call 数据通用形式

为了更好地理解和构建 Function Call 数据，我们首先需要拆解当前大模型在 Function Call 场景下数据的通用形式。相比于普通的问答（QA）任务，Function Call 数据所涉及的调用流程更加复杂，通常不仅包含用户意图的理解，还包括工具选择、参数提取、调用顺序等多个环节，这些都对数据的设计与标注提出了更高的要求。

以一个通用的大模型调用 Function Call 能力的执行链路为例，正常情况下，我们会首先传入一个 tools 参数，该参数中包含我们预先定义好的 function list，即一组工具的描述信息。同时，我们还会传入 message 数据，其中通常包括用户的输入问题以及我们希望传入的 system、prompt 等上下文信息。随后，我们调用模型进行推理。此处举例以 OpenAI 的接口形式进行说明：在一般情况下，仅需传入 message 参数即可完成模型的调用；但在需要触发 Function Call 的场景下，还必须同时传入 tools 参数，即前述定义好的工具列表。最终，接口端会将模型输出结果解析为两个字段：content 和 tool_calls。其中，content字段包含模型生成的文本内容，tool_calls 字段则包含调用的工具名称及其对应的参数信息。

在实际调用过程中，当我们将 message 和 tools 传入模型后，模型会调用其内置的 chat template，即预定义的对话模板，将 tools 和 message 内容进行拼接。以我们自研模型所采用的拼接方式为例，在传入 tools 和用户 query 后，系统还会额外拼接一些工具定义信息以及输出格式的约束要求，例如要求模型遵循用户指令，并以 JSON 格式返回工具名称及参数。同时，通常会使用特定的特殊符号（如 tool_call标记）对工具调用内容进行包裹，以便外部的执行引擎或框架对模型输出进行结构化解析。模型输出的 content 部分以及工具调用的 name 和 arguments 将被分别提取，并由框架用于调用对应的真实工具，将参数传入，执行具体操作。在获得工具返回结果后，该结果需再次被重新插入到 message 序列中，作为后续对话或调用的上下文输入。

对于大模型而言，整个 Function Call 的执行过程实际上是一个多轮、多次调用的过程。在第二次调用时，模型会综合前一次工具调用的信息以及工具返回的结果，生成相应的响应。此时的输出可能是继续调用下一个工具以推进任务流程，也可能表示当前任务已经完成，模型已获取足够的信息并生成最终的答复。这种多轮迭代的机制，使得大模型能够在复杂任务中逐步推理、协调工具调用，并最终输出符合用户需求的结果。

在展示的例子中，使用了一些大模型原生支持的 Function Call 功能，这意味着可以直接传入 tools 参数，其输入输出格式均由模型预定义的 chat template 进行管理。然而，在对通用模型进行优化时，我们必须考虑到格式的泛化性问题。具体来说，用户并不总是按照预定义的 tools 格式传入信息，他们可能采用类似 React 的方式自定义工具描述及输出格式。因此，确保模型能够灵活处理不同格式和遵循特定规范的能力，是我们在优化模型过程中需要重点关注的方向。这种灵活性不仅增强了模型与多样化的外部系统和工具之间的兼容性，也提升了用户体验，使得 Function Call 功能在更广泛的场景下得到有效应用。

2. Function Call 数据情况讨论

在正式构建 Function Call 数据之前，我们首先对 Function Call 数据的构成和分类进行讨论。由于 Function Call 数据的类型多样、场景复杂，我们根据用户问题、任务类型与提供的工具列表之间的关系，将 Function Call 数据大致划分为以下几类。

第一类是需要调用工具的数据，该类又可进一步细分为两类：能够正常完成的和无法正常完成的。

在“能够正常完成”的场景下，又可分为三种子类型：

• 单工具调用：即用户问题仅需调用一个工具即可完成整个任务链路并给出完整回答。例如用户询问“某地天气如何”，若模型挂载了 get_weather 工具，则只需调用该工具即可完成任务。

  
  

• 依赖性工具调用：即多个工具之间存在调用顺序或参数依赖关系。例如用户询问“张三的地址对应的天气如何”，则需先调用 get_address 获取地址信息，再调用 get_weather 获取天气信息，才能完成最终回答。

  
  

• 平行工具调用：即在当前调用步骤中可以并行调用多个工具，且各工具之间无依赖关系。例如用户询问“张三的手机号和地址分别是多少”，模型可同时调用 get_address 和 get_phone_number 两个工具完成任务，与依赖性调用的区别在于参数之间无需依赖。

  
  

在“无法正常完成”的场景下，又分为两种情况：

• 信息缺失：即用户问题中缺少关键参数，无法直接调用工具。例如用户问“我老家的天气怎么样”，但未提供“老家”具体地址。此时，模型应输出追问信息，如“您老家地址是在哪里？方便告诉我吗？”。

  
  

• 工具缺失：即用户提出的问题所需工具未被挂载。例如模型仅挂载了     get_address 工具，而用户询问“帮我用微信发个消息”，此时模型应识别到缺乏相关工具，并给出合理回应，如“不好意思，我没有办法完成您的操作，但我可以帮助您撰写这条消息”。

  
  

此外，还存在一类容易被忽视的数据类型，即无需调用工具。例如用户提出“给我讲个故事”，此类任务无需调用任何外部工具，大模型应直接生成内容进行回复。但在训练过程中，若大量引入需要调用工具的样本，可能会影响模型在通用任务上的表现，因此在数据构建和训练优化中也需特别关注此类情况，确保模型在增强 Function Call 能力的同时，不影响其通用文本生成能力。

3. 数据构建流程

在讨论了 Function Call 数据的分类后，接下来是数据构建流程的搭建。当前许多论文提出了各种各样的数据构建流程，但本质上都可以归纳为如 PPT 中展示的这个流程：首先进行工具构建，也就是定义或选择可用于 Function Call 的工具；然后是任务构建，即生成类似用户问题的 query，并设计相应的调用逻辑和答案生成策略。在完成工具和任务的构建之后，还需要对整个链路上的每一个环节进行校验，确保每一步都能正确执行。最终产出可用于训练或测试的 Function Call 数据。

（1）工具构建

在 Function Call 数据构建流程中，首先介绍的是链路中的第一步——工具构建。工具构建通常分为两种类型：真实工具与虚构工具。

真实工具指的是调用外部真实存在的 API 或接口，例如 Bing 搜索引擎、天气查询接口等，这类工具依赖于现实世界中的数据源。当用户发起调用时，获得的是真实反馈信息。虚构工具则不同，其功能和返回结果完全由大模型生成，没有真实后端支持，本质上是模型内部推理的延伸。在这种方式下，大模型被要求模拟工具的返回结果，所生成的内容并非真实数据，而是基于已有知识和信息“构造”出来的结果。

这两种工具各有优势。真实工具的优势在于其返回结果具有高真实性，与现实世界严格一致。例如在调用股价查询工具时，返回的是 2025 年 7 月 12 日当天的真实股价，且工具的输入输出参数贴近用户真实使用场景，避免了模型幻觉的产生。然而，真实工具的使用也存在明显挑战：一是频繁调用真实 API 会产生较高的费用；二是 API 本身可能存在稳定性问题，如需要认证、调用失败需重试等情况；三是对外部服务存在依赖，可能出现服务宕机、并发限制等问题。

因此，基于真实工具构建数据的场景更适合对精度要求较高的任务，例如金融分析、医疗诊断，或当模型自身无法模拟输出时，借助真实工具打通 Function Call 能力是较为合理的选择。而对于需要大批量、通用型 Function Call 能力提升的场景，目前更常用的是虚构工具。

虚构工具的优势在于无需支付 API 调用费用，仅需支付推理成本，且工具的部署和逻辑设计可由开发者完全掌控。例如可以根据需要自定义工具的功能和适用场景。但其缺点也较为明显：返回结果并非真实数据，而是由大模型虚构生成，可能存在一定的数据风险。

虚构工具的构建方法主要有两种：一是从开源工具库中获取工具描述，再由模型生成对应的调用结果；二是在缺乏开源 API 或特定场景支持的情况下，可以基于大模型已有的语料，划分出相应的任务和场景，逐步迭代生成工具的 API 描述及其返回结果。

（2）任务构建

下一步是任务构建阶段，即利用大模型批量生成 Function Call 数据的方法。在这一阶段，通常的做法是使用大模型根据给定的工具列表（如 get_weather、get_phone_number 等）生成对应的用户问题。这一过程的核心在于 prompt 的设计与优化。除了基本的 prompt 调整外，在实际构建任务数据时还需要关注一些关键点。

首先，应确保生成的数据能够覆盖 Function Call 数据的多种类型，包括缺参数、缺工具等典型场景，并合理分布依赖性调用、并行调用等不同类型任务的比例。其次，在构建过程中我们发现，指令的难度分布对模型训练效果有显著影响。因此，通常会引入“角色设定”和“场景设计”等机制，通过指令进化方法，使生成的任务数据更贴近真实应用场景，逐步提升问题的复杂度与多样性。

此外，构建复杂任务的一种有效方式是将已有的简单任务进行组合，逐步构建出更复杂的任务链路。例如，给定一个原子问题“今天天气如何”，以及两个工具 get_weather和 get_tourists_guide，我们可以基于这两部分生成更多类型的 Function Call 数据，并构造出更复杂的任务结构。这一阶段主要涉及数据构建过程中需要特别注意的多个方面，包括任务类型的覆盖、难度分布的控制以及任务组合的合理性等。

（3）答案构建

下一步是答案构建阶段，这是整个 Function Call 数据构建过程中最关键的部分。在模型训练过程中，通常会对输入部分进行掩码处理（mask），因此答案的质量将直接影响模型最终输出的效果。如果答案中存在 bad case 或脏数据，例如空值、格式错误、逻辑错误等问题，就可能导致模型输出结果的质量显著下降，影响最终的使用体验。

答案构建的方法相对基础，没有过多复杂技巧。常见的方式包括：基于大模型（可以是其他已训练好的模型，也可以是更大参数规模的模型）生成答案，或采用人工标注的方式构建高质量答案。这两种方式在实际应用中均被广泛采用。

在对答案精度要求更高的场景下，还可以采用多源聚合的方式提升答案质量。例如，通过多个不同大模型生成的答案、不同 prompt 生成的答案、或使用不同推理参数生成的答案进行对比，再通过投票机制或一致性校验筛选出高置信度的结果，作为最终用于训练的答案输出。

此外，对于某些特定类型的任务，例如操作系统指令执行或搜索类任务，还可以在本地简单搭建模拟环境，使大模型与该环境进行真实交互。通过这种方式获得的真实调用路径和执行结果，也可以作为答案数据直接用于训练，从而进一步提升模型在实际应用中的准确性和稳定性。

（4）校验

最后一步是校验，这是数据构建过程中至关重要的环节。该步骤分为两部分：格式校验和内容校验。在 Function Call 场景下，由于当前大模型在 Function Call 能力方面仍存在较高的错误率，因此这两类校验对于确保生成答案的可信度尤为重要。

格式校验首先对模型输出进行格式检查，确保其遵循了 prompt 中规定的格式约束。例如，根据前面的例子，检查是否正确使用了 tool_call 包裹 JSON 格式的工具调用指令，以及是否使用了正确的分隔符（如反斜杠）。只有当格式符合要求时，后续引擎侧才能准确解析并提取出具体的工具调用名称及参数类型，从而完成调用。此外，还需验证 tool call 中的 API 名称是否与提供的 function list 中的工具名称相匹配，以及参数类型是否正确。例如，在某个示例中，若给定参数应为 tuple 类型，但模型输出了字符串类型，则会导致后续调用失败，因为引擎无法处理错误类型的参数。

内容校验则主要依赖于大模型来判断当前调用的答案中 API 的使用是否合理，工具选择路径是否最优，以及参数设置是否恰当。这一步骤旨在确保 Function Call 操作不仅在形式上正确，而且在逻辑上也是合理的，从而提高整体调用的成功率和准确性。

如果想要构建出一些更加复杂的、例如多轮交互类型的 Function Call 数据，其实可以采用两种方式。第一种方式是将单个的原子任务进行拼接，相当于把多个独立的任务串联在一起，形成一个连续的多步骤任务链路。第二种方式是在校验步骤完成之后，将流程回退到任务构建阶段，并基于之前已有的任务信息以及生成的答案结果，继续构造下一轮的任务内容。通过这种方式，可以生成一些包含指代信息的任务，从而完成多轮数据的构建。

这里想特别讲一个其他的构建方法，也就是工具图的应用。工具图的核心其实就是构建一张工具关系图，基于工具之间的依赖关系来构建这样的一张图。例如，当前一些工具返回的参数或值，可能是下一个工具执行所需的参数信息，这时就可以认为这两个工具之间存在一定的依赖关系，这两个工具就可以作为图上的两个节点，并在它们之间建立一条边。

建立出这样一张工具图之后，我们就可以基于不同的图采样策略，采样生成不同难度的任务。一般我们会认为，如果在我们的 function list 中工具之间的依赖关系越多，对应的任务可能就越复杂、越难。此外，我们还可以借助 API 工具图中的依赖关系，对工具调用链路进行验证。例如，当前的数据构建中调用了工具 A，而工具 A 的参数严格依赖于工具 B，那么我们就可以检查其前置条件中是否存在工具 B 的信息，或者在之前的调用链路中是否已经调用过工具 B，以此来完成对答案准确性的校验。

03

核心算法优化方案-训练优化

1. 训练优化方案-SFT

在训练优化部分，我本次分享主要集中在后训练阶段。我们都知道，大模型的训练通常可以分为三个阶段：首先是预训练，然后是后训练，后训练中又包括 SFT（监督微调）和强化学习两个主要阶段。我本次分享的内容主要集中在 SFT 和强化学习这两个阶段中对 Function Call 能力的优化。

首先是 SFT 阶段。在 SFT 阶段，我们可以将大量高质量的 Function Call 数据注入到训练数据中，让大模型整体学习 Function Call 数据的格式和调用逻辑。但在这一过程中需要注意的一点是，SFT 任务本质上可以视为一种多任务学习过程，不同任务之间可能存在相互影响。例如代码数据、数学数据、Function Call 数据以及通用文本数据之间可能会存在交叉影响。

因此，不同任务数据之间的配比就成为影响模型最终表现的关键因素之一。此外，Function Call 数据内部不同类型的数据配比也会对模型效果产生较大影响。例如，如果在训练数据中，能够正常调用工具的数据，如单工具调用、依赖性工具调用等类型的样本占比过高，模型在面对类似任务时会更倾向于调用工具。这可能导致在某些不应调用工具的场景下出现过度调用的问题，例如在不需要调用工具的情况下仍然尝试调用工具，从而引发幻觉现象。

因此，数据配比的设计对于模型行为的稳定性具有重要影响。此外，数据的难度分布也可能对最终训练效果带来显著变化。这一阶段主要是一个需要大量实验和尝试的阶段。

第二个阶段是强化学习阶段。强化学习在今年初随着 DeepSeek 推出 R1 及其背后的强化学习算法，在整个 AI 领域引起了广泛关注。此后也陆续有更多方法和复现项目出现，进一步验证了这套训练流程的有效性。

2. 训练优化方案-RL

如果说想用 GRPO 去优化某些下游任务的应用效果，有两个核心条件。首先是当前任务所使用的 RL 数据，必须有一个清晰的判断标准来区分答案的好坏。例如数学解答题通常带有标准答案，代码类任务则可以通过可执行性来进行判断，这样我们就能够满足下一个条件，也就是奖励函数的设计。我们可以设计一个较为精准的奖励函数，来判断模型输出的正确性，并提供有效的反馈信号。例如在数学任务中，我们就可以判断当前输出的答案是否与参考答案一致。

但是也存在很多任务，例如写作类任务或一些开放性任务，这类任务并没有一个明确的标准来判断输出的好坏，也就难以获得一个简单的反馈信号。因此，这类任务在当前的强化学习研究中应用较少。从目前开源和复现的项目来看，大多数工作仍集中在代码和数学这两类任务上。如果我们希望将 GRPO 这类较为有效的强化学习优化方法应用到 Function Call 任务中，会面临以下的具体挑战。

第一个挑战是 Function Call 任务的场景本身较为复杂。它可能涉及独立工具调用、依赖性工具调用、参数缺失、工具缺失等多种情况。如果我们希望在这些不同场景下同时进行优化，就需要对每种情况分别进行分析，不能采用统一的处理方式。

第二个难点是强化学习数据的稀缺性。对于代码和数学类任务，现实世界中已有大量公开数据集和参考答案，相关生态建设也较为完善。Function Call 数据则仍处于起步阶段，适合用于强化学习的数据集仍较为有限。此外，并非所有 Function Call 数据都适合用于强化学习。例如代码任务可以通过执行性判断，数学任务有标准答案，但 Function Call 中存在很多开放性任务，其输出并没有统一的标准答案，这类数据并不完全适合强化学习训练，或者对奖励函数的设计提出了过高的要求。

第三个难点在于奖励函数的设计本身要求较高。Function Call 的输出格式较为复杂，包含多个要素，可能涉及多层工具调用，每一层调用中又可能涉及多轮参数传递。这些都需要在奖励函数中被充分考虑，以确保模型输出的准确性与合理性。

（1）RL 方式一

目前使用强化学习优化 Function Call 能力的方式主要有两种。第一种是优化当前单步工具调用的效果。这一方式可以分为几个关键步骤。

第一步是数据构建，这是整个流程的基础环节。在训练的初始阶段，需要构建高质量的 Function Call 数据，这一过程可以参考 SFT 阶段的数据构建方式，并特别注意数据分布的设计。

第二步是数据的选择。对于强化学习训练来说，并不是所有收集到的 Function Call 数据都适合用于训练。在实践中我们发现，可以通过前置的数据筛选步骤来规避一些问题，例如开放性较强的 Function Call 数据可能导致奖励信号不明确的情况。

这一筛选过程主要包括两个方面：

第一，选择具有标准答案的数据。这一方法主要通过对同一条 query 多次生成答案，并选择一致性较高的结果作为参考答案。我们认为，如果一条 query 在不同大模型、不同 prompt 以及不同推理参数下生成的答案保持一致，那么该答案大概率可以作为该 query 的标准答案。相反，如果多次推理结果存在较大差异，则说明该任务具有较高的开放性，答案多样性较强，这类数据对奖励函数的设计提出了较高要求，可能难以提供明确的反馈信号。

第二，选择具有难度分布的数据。具体做法是利用待优化模型对数据进行多轮推理，从而划分每条数据的难度等级。这一过程在我们的实践中被证明非常关键，因为如果数据集中包含不同难度层次的任务，并合理设置其占比，将显著影响最终的优化效果。因此，在训练前我们会对所使用的数据进行难度分布的拆解与分析，以便更有效地指导后续的强化学习训练过程。

最后一步其实是 Reward Function 的构建。Reward Function 的构建可以将以下两种元素纳入考虑范围。

第一个是输出格式的准确性。这部分内容在数据构建的校验阶段已经有所提及，即模型输出的格式必须满足 prompt 中设定的约束条件。同时，tool call 中的工具名称以及参数也必须符合工具列表中所定义的格式规范。这些都属于输出格式准确性需要考虑的部分。

第二个是工具选择的正确性。针对这一点，我们提出了三种 Reward 判断方式。

①严格判断。如果在前置阶段已经对数据进行了一致性校验，并认为当前的 output 或参考答案是一个标准答案，那么模型的输出必须与该标准答案完全一致，才被视为正确。在该设定下，我们会对 rollout 阶段推理出的结果与标准参考答案进行严格的一致性校验。如果一致，则给予正向激励；如果不一致，则视为错误，给予负向激励。这种判断方式较为严格。

②较为宽松的 Reward 设计方式。目前也有一些论文提出了这类方法，即可以基于推理结果与参考答案之间的工具名称（tool name）和参数（arguments）的重合程度进行打分。例如，参考答案中有三个参数 A、B、C，而 rollout 推理出的参数是 A、B、D，那么可以针对它们的重合程度给出 2/3 的得分。

③借助大模型作为 Judge Model 对结果进行打分。这种方式在数据构建过程中也比较常用。但其存在的问题是，大模型的打分本身并不稳定，对于强化学习来说，我们担心它可能提供不稳定甚至错误的奖励信号，从而导致最终训练结果的坍塌。不过，使用大模型作为打分模型的优势在于其形式较为灵活，可以处理各种类型的输出数据。

从上述强化学习数据的构建，到 Reward Function 的设计，这两步完成之后，其实就可以开始使用 GRPO 的方式进行训练了。由于目前开源框架较多，整体的训练流程是比较容易实现的。对于GRPO 来说，核心难点主要集中在数据的选择以及 Reward Function 的设计这两个方面，这两部分的处理质量将直接影响最终的优化效果。

（2）RL 方式二

第二种方式其实是一种相对较新的方法。这种方式较为前沿，尚未形成一个固定的训练范式供广泛使用。

第一种方式存在一些限制。该方式实际上是将工具调用作为一个单轮能力进行优化。然而，在实际的 Agent 与 Function Call 的交互过程中，情况更加复杂。Agent 会不断接收到环境的反馈信息，并据此调整其工具调用的链路。因此，我们更希望将工具执行的结果有效整合到训练的反馈循环中。通过将环境的反馈信号作为输入的一部分，指导函数调用的决策。最终根据输出结果判断并赋予一个 Reward 值，以此指导模型的训练。

然而，如果要达成预期的训练效果，存在两个难点。首先，交互环境难以获取。例如，要构建一个能够实时接收反馈信号的环境并不容易，并非所有工具调用的场景都具备这样的条件。而目前大部分的训练数据通常是基于虚拟 API 构建的。这导致环境的搭建存在一定的困难。其次，rollout 过程中的多轮交互时间并不一致。例如，某条推理可能交互了五轮，而另一条可能交互了十轮，这可能会对训练效率产生影响。

针对这些问题，目前已有一些解决思路。首先，在 rollout 的过程中，我们会将 tool call 的输出与环境的多轮交互结合起来，并依据最终输出的答案来决定 Reward 的取值。在实现过程中，还有一些细节需要注意。

例如，工具返回的结果，如代码执行器的结果或知识库检索的结果，这部分内容可能需要进行 Mask 处理。这可能涉及到框架的修改。此外，在 Reward 的设计方面，可以考虑基于答案正确性校验以及中间结果的校验。例如，对于代码调用场景，如果中间调用了五次代码，其中三次执行正确，那么可以将这一信息作为反馈信号纳入 Reward 的计算中。

此外，关于工具执行的准确率问题，目前有两种场景在训练方式的研究中被较多地探讨。第一种是代码工具的交互优化。具体而言，我们构建一个代码沙盒环境，在大模型输出过程中，模型不断输出代码片段并执行，从而获得反馈结果，并通过与环境的持续交互，最终生成答案。随后，依据该答案赋予一个 Reward 值，作为反馈信号用于优化和更新模型。

第二种方式是搜索工具的使用。在该方式中，将上述沙盒环境替换为类似于检索库的形式。在模型推理过程中，如果模型希望调用某个检索词，就会在输出中触发特定的标识（例如我们设定的字符，如反斜杠包裹的检索词），此时将停止当前推理，将该检索词提交至检索库中进行查询。检索到的内容将作为外部信息注入当前推理过程，模型基于这些信息继续进行推理，直到生成最终答案。同样，最终的答案将用于 Reward 的判断，并反馈至模型以更新其参数。

这两种场景之间的区别并不显著，主要差异在于推理模板（template）的设计以及交互环境的搭建方式。然而，当前优化方式主要集中于代码工具和搜索工具的原因在于，这两类工具的反馈机制和交互环境相对容易构建。例如，代码沙盒环境和本地知识检索库的环境搭建较为便捷。而在其他场景中，例如订票、旅游指南等任务，交互环境的构建则并不容易。

这种优化方式的难点主要体现在以下方面：

首先，不同任务需要独立搭建交互环境，而部分环境的构建难度较高。其次，对工具反馈的速度和环境稳定性有较高的要求。此外，还需要对训练框架进行一定程度的适配。

我们此前提到的不同推理轨迹（rollout）的推理时间存在较大差异的问题，也会对框架的训练方式和实现方式带来挑战。目前已有部分论文在研究优化这类异步、非固定长度的推理方式的实现路径。

3. 效果评估以及迭代优化

分享下当前 Function Call 能力的效果评估以及迭代优化中两个重要的榜单。实际上，在效果优化和训练优化过程中，一个高质量的评测集是非常关键的。它能够有效地指导我们的优化方向。

目前介绍的两个榜单是 Function Call 领域中较为重点且常见的评测基准。第一个是 BFCL 榜单，由伯克利开发，是一个专门用于评测函数调用能力的榜单。该榜单经过多版本的迭代演化，目前大致可分为以下三类。前四行属于单轮评估，虽然其细分为 single、multi、parallel 和 parallel-multi 四种类型，但整体上仍归类为单轮任务。

后四行则添加了 multiturn 前缀，表示为多轮评估。其中包括普通单轮任务（任务信息充足）、missing function（缺失工具）、missing parameters（缺失参数信息）以及 long context（工具返回结果为长文本），这些评测方式更贴近现实场景中的函数调用情况。

此外，BFCL 中还包含 hallucination 类型的测试，用于评估当任务本身不需要调用工具时，模型是否能够识别并基于自身能力作答，而非强行调用工具，从而评测模型在幻觉方面的表现。

另一个榜单是 Tao-Bench，它是一个较新且更具挑战性的评测框架。例如，在 claude 最新发布时，其评测结果即引用了 Tao-Bench 的指标。Tao-Bench 的区别在于其增加了更多与人类交互相关的元素，场景设计也更为复杂。同时，对于每个工具的使用也设置了更具体的约束条件。

例如，该榜单包含两个主要场景：retail（购物）和 airline（订票）。在订票场景中，例如退票这一功能，可能涉及多种限制条件，如经济舱与商务舱的退票规则存在差异，这类约束条件的设计较为复杂。

正因如此，Tao-Bench 更加贴近真实环境中 Agent 与用户之间的交互过程，因此其整体难度也更高。

04

Agent 应用方案

接下来，我们想分享一下当前较为流行的 Agent 应用方案，主要以 Manus 为例。Manus 是今年上半年引爆 AI 领域的一个产品，它再次将 Agent 的应用推到了公众视野中。继 Manus 之后，目前像 MiniMax 或者字节等公司也陆续推出了一些具有类似 Manus 特性的产品。这些产品的效果已经非常不错。

例如，如果我们上传一个表格，并要求其分析某些趋势，它能够很好地完成分析任务，并生成一个图文并茂的报告。这类产品在实现思路上大体是相似的。通常的流程是：用户首先提交查询任务，随后由智能体进行问题分析并制定执行策略，接着派生出多个子智能体，分别处理不同维度的子任务。

例如，在一个任务中，智能体可能会先派发一个调研任务，交由一个名为 research 的子智能体处理；随后再派发一个代码任务，交由 code 子智能体完成。各个子智能体会完成规划智能体所下发的各自任务，并将结果返回给规划智能体。

规划智能体收到这些返回结果之后，会判断当前任务是否已经完成。如果任务完成，则生成最终报告并呈现给用户；如果任务尚未完成，则会进一步进行规划和执行，继续调用其他子智能体完成剩余任务。整个流程即按照这样一个链路进行循环执行，直到满足用户需求为止。

整体来讲，对 Agent 应用效果的影响因素是多方面的。

首先，框架设计是当前较为关键的一个环节。目前比较流行的框架设计与一个新兴概念——context engineering（上下文工程）密切相关。在每一个节点流转的过程中，我们需要明确：到底应该保留多少信息，以及保留哪些有用的信息传递给下一个节点。否则，随着上下文长度不断增加，真正有用的信息可能会被淹没在冗长的信息流中。因此，如何控制上下文的有效性和长度，是框架设计中需要重点考虑的因素之一。

此外，还有一些其他方面的设计内容，例如各个独立节点的 prompt 设计，以及工具的接入方式等，这些也都属于框架设计的范畴。

针对模型能力而言，Agent 应用对模型的整体能力提出了较高要求。首先是规划能力。模型需要具备将复杂任务拆解为可执行子任务的能力，并能够根据反馈信息及时进行反思、调整执行路径。

其次是工具调用能力，即 Function Call 能力，这是整个智能体运行的基础。如果模型不具备良好的 Function Call 能力，智能体将无法有效执行任务。

除此之外，还包括代码能力。当前 Agent 应用较多地涉及数据分析、文件读取以及操作系统交互等场景，这些都要求模型具备良好的代码生成与调试能力。例如，如果模型生成的分析代码在执行过程中频繁报错，这将严重影响用户的使用体验。

此外，长文本理解能力也是一项关键能力。由于 Agent 应用通常会集成搜索能力，并涉及长期记忆和多轮交互，因此模型需要能够对大量历史信息进行整合、分析与推理。这就要求模型具备较强的上下文理解和记忆能力。

对于希望接入 Agent 应用的大模型来说，其整体能力要求是非常高的。不仅包括上述提到的四种能力，还包括例如报告撰写能力、推理能力等，都对模型提出了非常高的要求。