一个只会说话的大模型能力边界在它生成最后一个字的那一刻就封闭了。它可以告诉你物流一般3到5天到但说不出你的包裹现在到哪了它可以教你怎么改收货地址但不会真的帮你改。工具调用Function Calling是让语言模型跨越这条边界的唯一方式——模型负责理解和决策外部工具负责获取真实数据和执行真实动作。理解工具调用为什么必要比掌握它的语法重要得多。一、纯对话模型的三个根本局限第一个局限是信息封闭模型的知识停留在训练截止时间且不掌握任何企业私有数据——实时库存、订单状态、客户资料它一概不知。基于过期和通用知识回答具体业务问题要么靠猜产生幻觉要么只能给出正确但无用的套话。联网搜索能补一部分公开信息但企业内网数据必须通过专用工具获取。第二个局限是只能输出文字无法改变世界模型的全部输出是一段文本文本本身不产生任何业务效果。我已经帮您加急了这句话如果没有背后的真实操作就是欺骗。客户要的是状态真的改变、消息真的发出、工单真的创建——这些都需要调用真实系统的接口。第三个局限是不擅长精确计算和确定性操作让模型算订单金额、判断库存是否充足、套用复杂优惠规则它可能算错且每次结果不稳定。这类任务该交给确定性程序——计算器、数据库查询、规则引擎模型只负责理解客户想算什么并选择正确的工具。三个局限合在一起说明一件事模型是大脑工具是耳目和手脚缺了工具的模型只是个被关在黑屋里的顾问。二、工具调用的本质——模型输出的是结构化决策而不是话工具调用机制的关键不是模型能联网了是模型的输出格式变了在普通回复之外模型可以输出一个结构化的调用请求——调哪个工具、传什么参数。这个请求由外部程序执行执行结果再喂回模型模型基于真实结果组织最终回复。模型始终不直接接触任何系统它做的是决策程序做的是执行这个分工既安全又可控。工具调用不是一次性的一问一答是一个循环模型可能先调查订单工具拿到结果发现还需要查物流再调第二个工具最后综合两个结果回复中途参数不全还要向用户追问。这个思考-调用-观察-再思考的循环ReAct模式让模型能完成多步骤任务。工具的定义方式是标准化的——名称、功能描述、参数JSON模式任何符合协议的工具模型都能自动理解如何使用这让能力可以即插即用扩展。三、微信API的独特位置——感知入口和执行终端的双重角色在众多工具中个人微信API接口占据一个特殊位置因为它同时是工具链的两端。作为感知入口它把真实世界的客户事件送进来——谁发了消息、群里说了什么、谁通过了好友申请这些是Agent决策的输入源。作为执行终端它又把Agent的决策结果作用回真实社交关系——发出回复、修改备注、拉群、转发文件。绝大多数工具只承担一端查库存是只读输入、发短信是只写输出微信是少有的双向通道。这个双重角色决定了接入方式消息回调是感知端要保证事件不丢不乱序去重和幂等在接收侧处理消息发送和关系操作是执行端要受频控、权限和确认机制约束。Agent的整个感知-决策-执行-反馈闭环可以围绕微信这一个通道完整跑起来业务系统工具则在中间环节按需插入补充数据。这也是微信入口的价值所在——客户不需要安装新应用、不需要学习新交互在自己最熟悉的聊天窗口里就用上了智能体。三个局限与补齐方式对照模型局限表现对应工具类型信息封闭不知道订单/库存/私有数据查询类工具读无法行动只能说已帮您处理操作类工具写计算不稳金额/规则可能算错确定性程序函数/规则工具调用循环实现class AgentLoop: def run(self, wxid, user_text, max_steps6): messages [{role: system, content: 你是业务助手需要数据就调工具 不要编造订单和物流信息}, {role: user, content: user_text}] for _ in range(max_steps): # 思考-调用-观察循环 resp llm.chat(messages, toolsTOOL_SCHEMAS) if not resp.tool_calls: # 没有工具调用→最终回复 return resp.content for call in resp.tool_calls: result self.safe_invoke(call, wxid) messages.append({ # 观察结果喂回模型 role: tool, tool_call_id: call.id, content: json.dumps(result, ensure_asciiFalse)}) return 这个问题我需要人工同事协助处理 def safe_invoke(self, call, wxid): tool registry.get(call.name) args call.arguments if tool.risk write: # 写操作先经用户确认 if not confirm_store.verified(wxid, call): return {status: need_confirm, plan: call.arguments} return tool.execute(args) # 真实执行查单/改单/发消息 # 微信工具同一通道承担感知与执行 TOOL_SCHEMAS [ {name: query_logistics, description: 查询订单的实时物流轨迹, parameters: {type: object, properties: {order_no: {type: string}}}, risk: read}, {name: wx_send_message, description: 通过微信给指定客户发送消息, parameters: {type: object, properties: {content: {type: string}}}, risk: write}, ]落地建议落地工具调用要避开两个极端一是把所有请求都丢给模型决定调什么——高频确定意图走规则直连工具更快更省模型只处理需要理解的模糊请求二是给模型开放过多工具——工具越多选择准确率越低初期保持十个以内高频工具描述写精确。写操作全部走确认机制模型生成计划、人确认、程序执行的三段式不能省。微信侧的感知与执行能力由Eyun这类个人微信API平台提供业务工具按统一工具协议注册进同一套调度消息回调结构、发送接口参数和频控限制以Eyun平台的开发文档为准。