大模型 Function Calling 中的两种参数传入方式对比——为什么建议tools方式传参而不建议system message传参

在大模型（如千问）的工具调用场景中，建议通过tools参数传入调用函数信息，而非通过System Message传入，核心原因在于工具调用的专业性、结构化需求与System Message、tools参数的设计定位差异存在本质冲突。具体可从以下几个维度展开分析：

一、设计定位与功能匹配度不同

大模型的tools参数和System Message有着明确的功能划分，而工具调用的特性更适配tools参数的设计目标：

• tools参数的核心定位：专门用于定义“可调用工具/函数的元信息”，是模型识别“可用工具”的结构化接口。它通常要求严格的格式（如JSON），包含函数名、参数类型、描述、返回值等关键信息，本质是为模型提供“工具调用的花名册”，让模型明确“有哪些工具可用、怎么用”。
• System Message的核心定位：用于定义模型的系统级行为约束（如角色设定、对话规则、输出风格等），本质是“给模型定规矩”，而非“提供工具清单”。例如“你是一个助手，回答需简洁”“禁止生成有害内容”等。

工具调用是一种精准的功能交互，需要模型明确识别工具的结构和调用规则；而System Message的设计初衷是“自然语言级的行为引导”，二者功能定位不匹配。

二、结构化 vs 非结构化：影响工具调用的准确性

工具调用的核心需求是“模型能精准理解工具的参数、格式和用途”，而tools参数的结构化特性远超System Message的自然语言描述：

• tools参数的结构化优势：
  它通常要求严格的格式（如JSON Schema），例如：

  {
    "name": "get_weather",
    "parameters": {
      "type": "object",
      "properties": {
        "city": {"type": "string", "description": "城市名称"},
        "date": {"type": "string", "description": "日期，格式YYYY-MM-DD"}
      },
      "required": ["city"]
    }
  }
  

  这种结构化信息能让模型直接提取“函数名、必填参数、参数格式”等关键信息，生成的调用请求（如{"name":"get_weather","parameters":{"city":"杭州"}}）会更规范，大幅减少参数遗漏、格式错误等问题。

• System Message的非结构化缺陷：
  若通过System Message传入工具信息，通常是自然语言描述（如“你可以调用get_weather工具，需要传入城市和日期，城市是必填的”）。模型需要从长文本中“二次解析”工具结构，可能因描述歧义（如“日期格式没说清楚”）、信息冗余（如夹杂其他规则）导致误解，最终生成错误的调用（如漏传参数、格式错误）。

三、分离关注点：降低维护成本与逻辑混淆

工具信息和系统规则的分离，能显著提升场景的可维护性：

• 若工具信息放在System Message中，会导致系统提示变得臃肿（如“你是助手+禁止有害内容+可调用工具A（参数1…）+可调用工具B（参数2…）”）。当工具需要更新（如新增参数、删除工具）时，需修改System Message，可能误删或破坏其他系统规则，维护成本高。
• 而tools参数独立存储工具信息，System Message仅保留系统规则，二者职责清晰。例如：
  • System Message：“你是天气助手，回答需简洁。”
  • tools参数：[上述get_weather的JSON结构]
    当工具更新时，仅需修改tools参数，不影响系统规则，逻辑更清晰。

四、模型优化适配：专用参数的可靠性更高

大模型在训练和微调时，通常会针对tools类参数进行专项优化，使其更擅长处理“工具调用”场景：

• 模型会默认优先解析tools参数中的工具列表，明确“是否需要调用工具”“调用哪个工具”，流程更直接。
• 若工具信息在System Message中，模型需先理解系统规则，再从规则中“筛选”工具信息，增加了认知负荷，可能导致决策偏差（如该调用工具时忘记调用）。

总结

tools参数是为“工具调用”场景设计的结构化接口，能通过精准的格式定义、清晰的功能分离、模型的专项适配，提升工具调用的准确性、可维护性和可靠性；而System Message的核心是“行为引导”，其非结构化特性难以满足工具调用的精准需求。因此，建议通过tools参数传入工具信息，这是更符合大模型设计逻辑的最佳实践。