让 AI 大模型和企业微信 API 真正连起来是这两年很多人在折腾的事。但你会发现一个有意思的现象同样接一个大模型有人做出来的机器人只会闲聊有人做出来的机器人能查客户、发消息、打标签、拉群。差距不在模型在工具调用function calling这套机制用没用对。这篇专门把这件事讲透不聊大模型本身只聊怎么让大模型会用 Eyun 平台的接口。一、工具调用本质上是什么很多人对 function calling 有个误解以为它是大模型直接调你的 API。其实不是。工具调用的本质是结构化输出大模型读完用户的话、看到你提供的工具列表输出一段 JSON告诉外部程序我决定调这个工具、传这些参数。真正执行调用的是你的代码不是模型。模型只是产出了调用意图。用户帮我给王总发个问候 ↓ 模型决策 模型输出{tool: send_text_message, args: {conversationId: 8888, content: 王总好}} ↓ 你的代码 eyunSendText(appid, 8888, 王总好) ↓ 返回结果 模型读到发送成功 → 回复用户已为王总发送问候理解了这一点所有设计决策都有了依据。你的工作不是让模型调接口是让模型产出正确的调用意图你的代码去执行。二、工具注册让模型知道有哪些工具可用模型决策基于它看到的工具列表。注册工具时三件事必须做对工具粒度。一个工具对应一个业务动作不是对应一个 API。Eyun 有十几个发送类 API但工具层不该注册十几个发文本发图片发文件——注册成向客户发送消息一个工具参数里带消息类型模型更容易选。粒度太细模型选不过来太粗又失去灵活性按业务动作分是平衡点。描述质量。描述是模型选工具的唯一依据要回答三个问题这个工具干什么、什么时候用、什么时候不用。我踩过的坑工具描述里写调用 sendText 接口发送文本模型在客户说提醒王总开会时跑去调了create_group——因为它不知道提醒等于发消息。改成向客户发送一条文字消息用于通知、提醒、回复咨询后命中率立刻上来。参数 schema 严格。每个参数要有类型、必填标记、描述。模型对 schema 越严格越不容易传错。conversationId 要明确说是 number 还是 stringcontent 要说最大长度限制。schema 不严格模型随心所欲地传你的执行层就要做无穷无尽的兜底。三、决策循环让模型多步推进单次工具调用解决不了复杂任务。模型需要决策循环调一个工具 → 看结果 → 决定下一步 → 调下一个工具 → ... 直到任务完成。循环开始 ├─ 把历史 工具列表 上一步结果喂给模型 ├─ 模型输出调用工具X / 直接回复用户 / 任务完成 ├─ 如果调工具执行调用结果加入历史 ├─ 如果回复用户调 Eyun 发送消息接口 └─ 如果完成结束循环循环的几个工程要点循环上限。模型容易陷入死循环——反复调同一个工具、或者说我再确认一下没完。硬限制单任务最多 10-15 次工具调用超限强制结束转人工。上下文压缩。每次循环历史都变长几轮后 token 爆炸。要把旧的工具返回值裁剪到只保留关键字段。比如查客户档案返回 50 个字段第二轮开始就只保留姓名、标签、最近互动时间这三个。错误反馈。工具执行失败时不要把原始错误码丢给模型。把错误包装成模型能理解的语言conversationId 不存在请确认客户ID。模型看到这种反馈能自己修正看到-4014只会傻傻重试。四、模型选型不是越强越好很多人一上来就用最贵的模型结果成本扛不住、延迟客户等不了。实际选型要看任务复杂度任务类型推荐模型档位延迟成本单工具简单调用入门款1秒低多步骤规划中档2-5秒中复杂推理长链路顶级5-15秒高实际上你的机器人大部分任务都是前两类——查客户、发消息、打标签、建群这种单步或两三步的事。用顶级模型既浪费成本又增加延迟。更好的做法是分层路由意图识别先用便宜模型判断任务复杂度简单的走入门款模型快速处理复杂的才升级到顶级模型。这样 80% 的简单任务走快路径整体成本和延迟都压下来。五、多工具组合的几个常见坑工具间冲突。模型可能同时调多个工具比如同时给客户发消息又把客户拉黑——这两个动作语义冲突。多工具并发时要做语义校验发现冲突要拒绝其中一个或要求模型重新决策。重复调用。模型在循环里可能反复调同一个工具特别是返回结果不明确时。要记录每次调用的工具参数 hash重复调用直接返回上次结果不真正执行。参数来源混淆。模型可能把上一步的 conversationId 用到下一步的 sendText 上但上一步查的是客户 A下一步要发给客户 B。参数来源要在 prompt 里明确哪些 ID 是从用户输入来的、哪些是从工具结果来的、模型要自己核对。幻觉参数。模型偶尔会编一个不存在的 conversationId特别是上下文里没有这个 ID 时。所有 ID 类参数执行前必须先校验存在性不存在直接拒绝并要求模型重新决策。六、把 Eyun 能力映射成工具Eyun 平台的接口按业务动作分组包装成工具大概是这样工具名对应接口用途send_text_messagesendText给客户发文字消息send_rich_messagesendRichText发富文本带 提及query_customergetUserProfileDetail查客户档案search_customer_by_phonephoneNumberSearch按手机号找客户add_friendphoneNumberAddWework加客户为好友update_customer_labelupdateLabel给客户打标签create_grouproom/create建客户群add_group_memberroom/addMember拉人进群send_group_messagegroupSend群发消息每个工具的参数要做语义化——不要让模型直接传 appid 这种技术细节appid 由你的代码层根据当前会话上下文自动注入。模型只看到业务语义参数客户ID、消息内容、群ID技术参数由执行层补全。七、与企微回调的衔接工具调用不是孤立的事模型决策的输入来自企微回调推送的消息。要让模型在合适时机发起工具调用回调消息进来后先做意图识别用便宜模型或规则判断为需要执行动作的意图才进入工具调用循环判断为简单咨询的意图直接走 FAQ 或单轮 LLM 回复不走工具调用这样避免每条消息都跑完整工具调用循环整体成本和延迟可控。回调消息携带的上下文也要做增强直接给模型 raw 回调报文不行要预处理成模型好理解的结构提取关键字段、附加客户档案、附上当前会话状态。预处理做得到位模型决策准确率能差几个数量级。八、度量与持续优化工具调用系统上线后要持续看几个数据工具命中率模型选对的工具占调用总次数的比例。低于 80% 说明工具描述要改。参数准确率调用参数完全正确的比例。低说明 schema 不够严格或描述不清。单任务调用次数完成一个任务平均调几次工具。过多说明规划有问题。任务完成率不转人工、不超时、客户满意的任务占比。平均延迟从消息到达到回复发出的时间。工具调用链路要控制在 5 秒内。每周复盘失败案例找出失败模式最集中的工具或场景针对性改描述、改 schema、改 prompt。这套体系跑半年工具命中率能从初版的 60% 提到 90% 以上。写在最后让 AI 大模型用Eyun 企业微信 API真正办事核心是 function calling 这套机制。本质不是模型直接调接口是模型产出结构化调用意图、你的代码去执行。工具粒度按业务动作划分、描述写清三个问题、schema 严格定义、决策循环有上限、上下文持续压缩、错误反馈语义化、模型分层路由——这套工程做扎实大模型才能从会聊天升级到会干活。模型只是大脑工具调用体系是手脚手脚不灵光大脑再聪明也使不上劲。
