企业官网建设流程全解析

一个只会说话的大模型，能力边界在它生成最后一个字的那一刻就封闭了。它可以告诉你"物流一般3到5天到"，但说不出"你的包裹现在到哪了"；它可以教你"怎么改收货地址"，但不会真的帮你改。工具调用（Function Calling）是让语言模型跨越这条边界的唯一方式——模型负责理解和决策，外部工具负责获取真实数据和执行真实动作。理解工具调用为什么必要，比掌握它的语法重要得多。

一、纯对话模型的三个根本局限

第一个局限是信息封闭：模型的知识停留在训练截止时间，且不掌握任何企业私有数据——实时库存、订单状态、客户资料它一概不知。基于过期和通用知识回答具体业务问题，要么靠猜产生幻觉，要么只能给出正确但无用的套话。联网搜索能补一部分公开信息，但企业内网数据必须通过专用工具获取。

第二个局限是只能输出文字，无法改变世界：模型的全部输出是一段文本，文本本身不产生任何业务效果。"我已经帮您加急了"这句话如果没有背后的真实操作，就是欺骗。客户要的是状态真的改变、消息真的发出、工单真的创建——这些都需要调用真实系统的接口。

第三个局限是不擅长精确计算和确定性操作：让模型算订单金额、判断库存是否充足、套用复杂优惠规则，它可能算错且每次结果不稳定。这类任务该交给确定性程序——计算器、数据库查询、规则引擎，模型只负责理解"客户想算什么"并选择正确的工具。三个局限合在一起说明一件事：模型是大脑，工具是耳目和手脚，缺了工具的模型只是个被关在黑屋里的顾问。

二、工具调用的本质——模型输出的是结构化决策而不是话

工具调用机制的关键不是"模型能联网了"，是模型的输出格式变了：在普通回复之外，模型可以输出一个结构化的调用请求——调哪个工具、传什么参数。这个请求由外部程序执行，执行结果再喂回模型，模型基于真实结果组织最终回复。模型始终不直接接触任何系统，它做的是"决策"，程序做的是"执行"，这个分工既安全又可控。

工具调用不是一次性的一问一答，是一个循环：模型可能先调查订单工具，拿到结果发现还需要查物流，再调第二个工具，最后综合两个结果回复；中途参数不全还要向用户追问。这个"思考-调用-观察-再思考"的循环（ReAct模式）让模型能完成多步骤任务。工具的定义方式是标准化的——名称、功能描述、参数JSON模式，任何符合协议的工具模型都能自动理解如何使用，这让能力可以即插即用扩展。

三、微信API的独特位置——感知入口和执行终端的双重角色

在众多工具中，个人微信API接口占据一个特殊位置，因为它同时是工具链的两端。作为感知入口，它把真实世界的客户事件送进来——谁发了消息、群里说了什么、谁通过了好友申请，这些是Agent决策的输入源。作为执行终端，它又把Agent的决策结果作用回真实社交关系——发出回复、修改备注、拉群、转发文件。绝大多数工具只承担一端（查库存是只读输入、发短信是只写输出），微信是少有的双向通道。

这个双重角色决定了接入方式：消息回调是感知端，要保证事件不丢不乱序，去重和幂等在接收侧处理；消息发送和关系操作是执行端，要受频控、权限和确认机制约束。Agent的整个"感知-决策-执行-反馈"闭环可以围绕微信这一个通道完整跑起来，业务系统工具则在中间环节按需插入补充数据。这也是微信入口的价值所在——客户不需要安装新应用、不需要学习新交互，在自己最熟悉的聊天窗口里就用上了智能体。

三个局限与补齐方式对照

工具调用循环实现

class AgentLoop: def run(self, wxid, user_text, max_steps=6): messages = [{"role": "system", "content": "你是业务助手，需要数据就调工具，" "不要编造订单和物流信息"}, {"role": "user", "content": user_text}] for _ in range(max_steps): # 思考-调用-观察循环 resp = llm.chat(messages, tools=TOOL_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_ascii=False)}) 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平台的开发文档为准。