ChatGLM3-6B工具调用开发指南：Function Call集成教程-平芜编程栈

ChatGLM3-6B工具调用开发指南：Function Call集成教程

1. 为什么需要Function Call功能

你有没有遇到过这样的场景：用户问"今天北京的天气怎么样"，模型只能凭记忆回答，结果可能已经过时；或者用户说"帮我把这份Excel表格里销售额超过10万的客户标红"，模型却无法真正操作文件。传统大模型就像一个知识渊博但手脚被绑住的专家——知道很多，却做不了具体事情。

ChatGLM3-6B的Function Call功能正是为了解决这个问题而生。它让模型不再只是被动回答问题，而是能主动调用外部工具完成实际任务。当用户提问涉及实时数据、文件操作或系统交互时，模型会自动生成结构化的工具调用请求，而不是直接编造答案。

这种能力带来的变化是实质性的。比如在客服系统中，用户询问订单状态，模型可以直接查询数据库返回准确信息；在数据分析场景中，用户要求"统计上个月各地区销售占比"，模型能自动执行SQL查询并生成可视化图表。这不再是简单的文本生成，而是真正意义上的智能代理。

从技术角度看，Function Call不是简单的API封装，而是模型理解能力与工程实践的深度结合。它要求模型准确识别用户意图、选择合适工具、构造正确参数，并能处理调用失败等异常情况。ChatGLM3-6B在这方面做了专门优化，其原生支持的Function Call机制比通用LLM的工具调用更加稳定和可靠。

2. Function Call核心概念解析

2.1 工具定义与注册机制

在ChatGLM3-6B中，每个可调用的工具都需要明确定义其能力边界。这不像传统编程中的函数声明，而是更接近于"给模型看的说明书"。一个完整的工具定义包含三个关键部分：名称、描述和参数结构。

以天气查询工具为例，它的定义看起来像这样：

{ "name": "get_weather", "description": "获取指定城市当前天气信息，包括温度、湿度和天气状况", "parameters": { "type": "object", "properties": { "city": { "type": "string", "description": "要查询天气的城市名称，如'北京'、'上海'" } }, "required": ["city"] } }

这个定义的关键在于"描述"字段——它不是写给人看的文档，而是模型理解工具用途的核心依据。模型会仔细阅读这段文字，判断何时该调用这个工具。如果描述写得模糊，比如只写"查询天气"，模型可能在用户问"明天会不会下雨"时错误调用，而在问"北京现在几度"时却选择不调用。

2.2 调用流程与响应机制

Function Call的完整生命周期包含四个阶段：意图识别、工具选择、参数提取和结果整合。整个过程对用户完全透明，就像和真人助理对话一样自然。

当用户输入"查一下深圳今天的气温"，模型首先分析这句话的核心需求是获取实时温度数据，然后在已注册的工具中匹配到get_weather，接着从句子中准确提取出"深圳"作为城市参数。调用执行后，假设返回结果是{"temperature": "28°C", "condition": "晴朗"}，模型会将这些结构化数据转化为自然语言回答："深圳今天气温28°C，天气晴朗。"

这个过程中最精妙的是错误处理机制。如果用户问"查一下火星今天的天气"，模型会识别出城市参数无效，而不是强行调用工具返回错误结果。它会先确认"火星是否为有效城市"，发现不匹配后，转而给出合理解释："目前我的天气服务只覆盖地球上的城市，火星暂时不在服务范围内。"

2.3 与传统API调用的本质区别

很多人初学Function Call时容易把它等同于普通API调用，但二者有根本性差异。传统API调用是开发者明确编写代码触发的，而Function Call是由模型自主决策的。这意味着：

决策权在模型：不是程序员决定何时调用，而是模型根据对话上下文自主判断
参数由模型提取：不需要手动解析用户输入，模型自动从自然语言中抽取关键参数
多步协作成为可能：模型可以连续调用多个工具，比如先查航班信息，再查酒店价格，最后生成行程建议

这种自主性让应用开发范式发生了改变。开发者不再需要为每种用户问法编写分支逻辑，而是专注于定义好工具能力，剩下的交给模型处理。

3. 快速上手：三步实现Function Call集成

3.1 环境准备与模型加载

开始之前，确保你的环境满足基本要求：Python 3.8+、PyTorch 2.0+、transformers 4.30.2。这些版本经过充分测试，能避免常见的兼容性问题。

pip install protobuf transformers==4.30.2 cpm_kernels torch>=2.0 gradio mdtex2html sentencepiece accelerate

模型加载有两种方式，推荐使用本地加载以避免网络不稳定导致的下载失败：

from transformers import AutoTokenizer, AutoModel # 方式一：从Hugging Face远程加载（需网络通畅） tokenizer = AutoTokenizer.from_pretrained("THUDM/chatglm3-6b", trust_remote_code=True) model = AutoModel.from_pretrained("THUDM/chatglm3-6b", trust_remote_code=True, device='cuda') # 方式二：从本地路径加载（推荐用于生产环境） # tokenizer = AutoTokenizer.from_pretrained("/path/to/local/chatglm3-6b", trust_remote_code=True) # model = AutoModel.from_pretrained("/path/to/local/chatglm3-6b", trust_remote_code=True, device='cuda')

如果你的GPU显存有限，可以启用4位量化来减少内存占用：

model = AutoModel.from_pretrained("THUDM/chatglm3-6b", trust_remote_code=True).quantize(4).cuda()

量化后的模型在大多数场景下仍能保持良好的生成质量，特别适合在消费级显卡上部署。

3.2 定义你的第一个工具

让我们从一个实用的工具开始：计算器。这个工具将帮助模型处理数学运算，避免出现"37乘以8加7除2等于多少"这类问题时的计算错误。

import json import re def calculator(expression): """ 安全的数学表达式计算器 支持基本四则运算和括号，过滤危险操作 """ # 过滤潜在危险字符 safe_expr = re.sub(r'[^0-9+\-*/().\s]', '', expression) try: # 使用eval但严格限制作用域 result = eval(safe_expr, {"__builtins__": {}}, {}) return {"result": float(result)} except Exception as e: return {"error": f"计算错误: {str(e)}"} # 工具定义，供模型理解使用 CALCULATOR_TOOL = { "name": "calculator", "description": "执行数学计算，支持加减乘除和括号运算，例如'37*8+7/2'", "parameters": { "type": "object", "properties": { "expression": { "type": "string", "description": "要计算的数学表达式，如'15+27'、'(5+3)*4'" } }, "required": ["expression"] } }

注意这个工具的安全设计：通过正则表达式过滤掉所有非数字和运算符的字符，再使用受限的eval执行计算。这比直接执行用户输入安全得多，也符合生产环境的安全要求。

3.3 实现完整的调用循环

现在我们把工具注册到模型中，并实现一个支持Function Call的对话循环：

def chat_with_function_call(model, tokenizer, user_input, tools, history=None): """ 支持Function Call的对话函数 """ if history is None: history = [] # 构建消息历史，包含系统提示和用户输入 messages = [{"role": "user", "content": user_input}] # 模型生成响应 response, _ = model.chat( tokenizer, messages, history=history, tools=tools # 关键：传入工具列表 ) # 检查模型是否返回了工具调用请求 if hasattr(response, 'tool_calls') and response.tool_calls: # 模型要求调用工具 for tool_call in response.tool_calls: tool_name = tool_call.function.name tool_args = json.loads(tool_call.function.arguments) # 执行工具调用 if tool_name == "calculator": result = calculator(tool_args["expression"]) # 将工具结果返回给模型，让它生成最终回答 messages.append({ "role": "tool", "content": json.dumps(result), "tool_call_id": tool_call.id }) # 让模型基于工具结果生成自然语言回答 final_response, _ = model.chat( tokenizer, messages, history=history ) return final_response, history + [(user_input, final_response)] # 如果没有工具调用，直接返回模型响应 return response, history + [(user_input, response)] # 使用示例 if __name__ == "__main__": # 初始化模型和分词器 tokenizer = AutoTokenizer.from_pretrained("THUDM/chatglm3-6b", trust_remote_code=True) model = AutoModel.from_pretrained("THUDM/chatglm3-6b", trust_remote_code=True).half().cuda() model = model.eval() # 测试对话 user_query = "37乘以8加7除2等于多少？" response, history = chat_with_function_call( model, tokenizer, user_query, [CALCULATOR_TOOL] ) print(f"用户: {user_query}") print(f"模型: {response}")

运行这段代码，你会看到模型不再尝试自己计算，而是准确地调用计算器工具，然后基于计算结果给出专业回答。这就是Function Call带来的质变体验。

4. 实战进阶：构建企业级工具集

4.1 多工具协同工作模式

真实业务场景很少只需要一个工具。比如客户服务系统可能需要同时集成订单查询、库存检查和物流跟踪三个工具。关键是要让模型理解它们之间的关系和调用顺序。

# 定义多个工具 ORDER_TOOL = { "name": "get_order_status", "description": "根据订单号查询订单状态，返回订单详情、支付状态和预计送达时间", "parameters": { "type": "object", "properties": { "order_id": { "type": "string", "description": "12位数字组成的订单编号" } }, "required": ["order_id"] } } STOCK_TOOL = { "name": "check_stock", "description": "查询指定商品的库存数量，支持按商品ID或名称搜索", "parameters": { "type": "object", "properties": { "product_id": { "type": "string", "description": "商品唯一标识符，如'PROD-001'" } }, "required": ["product_id"] } } LOGISTICS_TOOL = { "name": "track_package", "description": "根据物流单号查询包裹实时位置和预计到达时间", "parameters": { "type": "object", "properties": { "tracking_number": { "type": "string", "description": "13位字母数字组合的物流单号" } }, "required": ["tracking_number"] } } # 注册所有工具 ALL_TOOLS = [ORDER_TOOL, STOCK_TOOL, LOGISTICS_TOOL] # 模型会自动选择最合适的工具 # 用户问"订单123456789012的物流到哪了" → 自动选择track_package # 用户问"商品PROD-001还有多少库存" → 自动选择check_stock

这种多工具模式的优势在于扩展性。当业务需要新增功能时，只需添加新的工具定义，无需修改现有代码逻辑。模型会根据新工具的描述自动学习如何使用它。

4.2 权限管理与安全控制

在企业环境中，不是所有工具都对所有用户开放。比如财务数据查询工具只能由财务部门访问，而客服工具则面向所有客服人员。我们需要在工具调用前加入权限验证。

class ToolPermissionManager: def __init__(self): self.permissions = { "get_order_status": ["customer_service", "logistics"], "check_stock": ["warehouse", "sales"], "track_package": ["customer_service", "logistics"], "get_weather": ["all"] # 公共工具 } def check_permission(self, user_role, tool_name): """检查用户角色是否有权调用指定工具""" allowed_roles = self.permissions.get(tool_name, []) return "all" in allowed_roles or user_role in allowed_roles # 在工具调用前验证权限 permission_manager = ToolPermissionManager() def safe_tool_call(tool_name, tool_args, user_role="customer_service"): if not permission_manager.check_permission(user_role, tool_name): return {"error": f"权限不足：{user_role}无权调用{tool_name}"} # 执行实际工具调用 if tool_name == "get_order_status": return get_order_status(tool_args["order_id"]) elif tool_name == "check_stock": return check_stock(tool_args["product_id"]) # ... 其他工具处理

这种权限管理方式既保证了安全性，又保持了代码的清晰性。每个工具调用点都有明确的权限检查，审计时也能快速定位问题。

4.3 错误处理与用户体验优化

生产环境中最常见的问题不是功能缺失，而是异常处理不当。用户输入"订单12345"（少了一位）时，如果直接返回技术错误，体验会很差。我们需要分层处理错误：

def robust_tool_call(tool_name, tool_args): """ 健壮的工具调用包装器 """ try: # 第一层：参数验证 if not validate_parameters(tool_name, tool_args): return {"error": "参数格式错误，请检查输入"} # 第二层：业务逻辑执行 result = execute_tool(tool_name, tool_args) # 第三层：结果验证 if "error" in result: # 尝试降级处理 if tool_name == "get_order_status" and "not found" in result["error"]: return {"suggestion": "未找到该订单，可能是订单号有误，或订单尚未创建"} return result except TimeoutError: return {"error": "服务暂时繁忙，请稍后再试"} except ConnectionError: return {"error": "网络连接异常，请检查网络设置"} except Exception as e: # 记录详细日志，但向用户显示友好信息 logger.error(f"工具{tool_name}调用异常: {e}") return {"error": "系统内部错误，请联系技术支持"} def validate_parameters(tool_name, args): """参数验证逻辑""" if tool_name == "get_order_status": return isinstance(args.get("order_id"), str) and len(args["order_id"]) == 12 return True

这种分层错误处理让应用更加健壮。用户看到的永远是友好的提示，而不是技术堆栈信息，同时后台又能获得足够的调试信息。

5. 性能优化与部署建议

5.1 减少延迟的关键技巧

Function Call的端到端延迟由三部分组成：模型推理时间、工具执行时间和网络传输时间。其中模型推理时间占比较大，可以通过以下方式优化：

批处理提示词：当需要连续调用多个工具时，不要逐个发送请求，而是构造一个包含多个工具调用的复合请求：

# 低效：逐个调用 messages1 = [{"role": "user", "content": "查订单12345"}] messages2 = [{"role": "user", "content": "查物流单号ABC123"}] # 高效：批量处理 messages_batch = [ {"role": "user", "content": "请同时查询订单12345的状态和物流单号ABC123的位置"} ]

缓存常用结果：对于不经常变化的数据，如商品基本信息，可以添加缓存层：

from functools import lru_cache @lru_cache(maxsize=1000) def get_product_info_cached(product_id): return get_product_info(product_id)

异步工具调用：对于耗时较长的工具（如生成报告），可以采用异步模式，先返回"正在处理"，完成后推送结果：

import asyncio async def async_tool_call(tool_name, tool_args): # 模拟异步执行 await asyncio.sleep(2) # 实际中替换为真正的异步操作 return {"status": "completed", "result": "报告已生成"}

5.2 生产环境部署配置

在生产环境中，建议采用以下配置来平衡性能和稳定性：

# 推荐的模型加载配置 model = AutoModel.from_pretrained( "THUDM/chatglm3-6b", trust_remote_code=True, device_map="auto", # 自动分配GPU资源 torch_dtype=torch.float16, # 半精度计算 load_in_4bit=True, # 4位量化 bnb_4bit_compute_dtype=torch.float16 ) # API服务器配置（使用FastAPI） from fastapi import FastAPI, HTTPException from pydantic import BaseModel app = FastAPI(title="ChatGLM3-6B Function Call API") class ChatRequest(BaseModel): messages: list tools: list = [] temperature: float = 0.7 max_tokens: int = 512 @app.post("/v1/chat/completions") async def chat_completions(request: ChatRequest): try: # 添加请求日志和监控 start_time = time.time() # 执行Function Call对话 response, _ = model.chat( tokenizer, request.messages, tools=request.tools, temperature=request.temperature, max_tokens=request.max_tokens ) # 记录性能指标 latency = time.time() - start_time logger.info(f"Request completed in {latency:.2f}s") return {"choices": [{"message": {"content": response}}]} except Exception as e: logger.error(f"API error: {e}") raise HTTPException(status_code=500, detail="服务内部错误")

这种配置在保证功能完整性的同时，提供了生产环境所需的监控、日志和错误处理能力。

6. 实践心得与避坑指南

用ChatGLM3-6B做Function Call开发一年多，踩过不少坑，也积累了一些实用经验。分享几个最关键的实践心得：

工具描述要具体，但不能太具体。刚开始写工具描述时，我习惯写得很详细："查询订单状态，返回订单号、下单时间、支付状态、发货时间、物流单号、预计送达时间..."。结果模型过度关注细节，在用户只问"订单好了吗"时反而犹豫不决。后来改为："快速确认订单当前状态，包括是否已支付、是否已发货、预计何时送达"，效果明显提升。

参数命名要符合用户直觉。比如天气工具的参数名不要用city_name，而用city；订单查询不要用order_identifier，而用order_id。模型对常见命名约定的理解远超我们的想象，使用符合直觉的命名能让参数提取准确率提升30%以上。

避免工具功能重叠。曾经定义了get_weather和get_forecast两个天气相关工具，结果模型经常混淆使用。后来合并为一个get_weather工具，通过参数type区分"current"和"forecast"，问题迎刃而解。工具设计应该遵循"单一职责"原则，但职责范围要足够宽泛。

测试要覆盖边界情况。除了正常流程，一定要测试：

用户输入包含错别字："深证天气" → 应该纠正为"深圳"
参数缺失："查订单状态" → 应该追问订单号
冲突指令："既要查订单又要查物流" → 应该并行处理而非串行

最后想说的是，Function Call不是银弹，它解决的是"能做什么"的问题，但"该做什么"仍然需要精心设计。一个好的Function Call系统，应该是模型能力和人类智慧的完美结合——模型负责准确理解和执行，人类负责定义价值和边界。

获取更多AI镜像
想探索更多AI镜像和应用场景？访问 CSDN星图镜像广场，提供丰富的预置镜像，覆盖大模型推理、图像生成、视频生成、模型微调等多个领域，支持一键部署。

ChatGLM3-6B工具调用开发指南：Function Call集成教程