【大模型】两种工具调用模式：预制工具 vs 动态代码生成

最新推荐文章于 2025-06-04 21:41:28 发布

原创最新推荐文章于 2025-06-04 21:41:28 发布 · 1k 阅读

23 ·

CC 4.0 BY-SA版权

文章标签：

#语言模型

大模型专栏收录该内容

41 篇文章

订阅专栏

一、两种模式的核心概念

1. 预制工具调用模式 (Tool Calling)

预制工具调用模式需要开发者预先编写好所有可能用到的工具函数，并通过提示词向LLM描述这些工具的功能和使用方法。LLM根据用户请求选择适当的工具并生成调用指令，系统随后执行这些工具并返回结果。

典型工作流程：

开发者预先定义工具集（如数据库查询、图表生成等）
在提示词中描述工具的功能和参数格式
LLM理解用户请求后选择工具并生成调用指令
系统执行工具并返回结果

示例：

# 预定义工具
tools = [
    {
        "name": "query_sql",
        "description": "执行SQL查询",
        "parameters": {"sql": "string"}
    }
]

# LLM生成的调用请求
{"tool": "query_sql", "input": {"sql": "SELECT * FROM sales"}}

优势：

安全性高：工具功能严格受限，无法执行任意代码。避免注入攻击（如SQL注入可通过参数化查询防御）。
稳定性强：工具行为可预测，输出格式固定。适合生产环境中的关键任务。
调试方便：工具调用可记录为标准化日志。容易追踪LLM的决策过程。
性能优化：工具可预编译或预加载。避免动态代码解析的开销。

劣势：

灵活性低：无法处理未预见的任务类型。复杂任务需要组合多个工具（可能产生冗余调用）
开发成本高：需提前开发覆盖所有场景的工具库。工具描述需精确（否则LLM可能误用）
表达能力受限
难以实现动态逻辑（如条件分支、循环等）

2. 动态代码生成模式 (Code Generation)

动态代码生成模式允许LLM直接生成可执行代码（如Python、SQL等），系统在受控环境中执行这些代码。这种方式提供了极大的灵活性，但也带来了更高的安全风险。

典型工作流程：

LLM根据用户请求直接生成完整代码段
系统在沙箱环境中执行生成的代码
返回执行结果

# LLM生成的代码
code = """
df = execute_sql_query("SELECT product, SUM(sales) FROM orders GROUP BY product")
result = {"type": "dataframe", "value": df}
"""

优势：

灵活性极强：可处理任意复杂逻辑（如动态生成的算法）。适合探索性场景（如数据分析、科研）
开发成本低：无需预先定义所有工具。快速适配新需求（仅需调整提示词）
表达能力完整：支持编程语言的全部特性（循环、函数等）。可直接复用现有代码库

劣势：

安全风险高：可能执行恶意代码（如os.system(“rm -rf”)）。需严格沙箱隔离（但难以完全防护）
稳定性差：生成的代码可能有语法错误或逻辑缺陷。需要重试机制（增加延迟）
调试困难：动态代码难以追踪和复现问题。错误信息可能晦涩（如运行时异常）
性能开销：每次执行需解析/编译代码。不适合高频调用场景

二、深度对比分析

在这里插入图片描述

三、混合模式实践

在实际应用中，最佳实践往往是结合两种模式的优点：

核心功能预制化：将高频、高风险操作封装为预定义工具
边缘逻辑动态化：允许生成简单、低风险的代码片段
权限分级控制：根据用户角色和任务风险等级选择执行模式

示例实现：

def execute_request(query):
    if query.is_high_risk():
        # 使用预制工具
        tool_call = llm_choose_tool(query)
        result = tool_dispatcher.execute(tool_call)
    else:
        # 允许有限代码生成
        code = llm_generate_code(query, 
                       allowed_modules=["pandas"])
        result = sandbox.execute(code)
    return result