最近做的企微二开做到第一百多篇，回头理一理。前两年的企微二开思路基本是"接口搬运"——把企微消息接口接到 CRM、工单、知识库，AI 加进来当个 FAQ 机器人。但这两年的需求和之前不一样了，业务方不再满足"机器人答问题"，要的是"机器人办事"——客户问一句话，机器人调一堆接口、判断一堆业务规则、把事情办完反馈。这背后是从"在企微里加 AI"到"AI 原生企业应用"的范式转变。

 Eyun 平台开放的企微 API，统一 POST+JSON，鉴权用 App Token 加 appid，请求头带 Authorization: Bearer eyk_xxxx，路径统一 {BASE_URL}/wx-api/api/<模块>/<动作>，响应封套 {code, data, detail, message, time}，code 为 0 成功。所谓"AI 原生"不是把 AI 嵌进企微，是从设计上就以 AI 为中枢——接口是手脚、AI 是大脑、企微是交互界面。

范式差别：从被动响应到主动感知

传统企微二开是被动响应——客户发消息机器人答，客户不发机器人不动。AI 原生应用是主动感知——机器人不只在等消息，在持续感知业务变化并主动行动。

举个具体场景：传统模式下机器人要等客户问"我的订单到哪了"才查物流。AI 原生模式下，机器人感知到某客户的物流停滞超过 24 小时（通过定时拉订单状态），主动调 message/sendText 给客户发"您的订单物流异常，已联系物流加急"，并给负责销售调 label/updateLabel 打"需安抚"标签。同一个事件，被动响应是客户问才答，主动感知是机器人先发现先行动。

主动感知的底层仍然是接口调用——定时拉业务数据、判断异常、调企微接口主动推送。AI 在中间负责"判断什么是异常、该用哪种话术沟通"。这套范式下，机器人不是客服，是业务运营的延伸。

范式差别：从单点智能到流程智能

最早接 AI 是单点——客户问机器人答。这种单点智能解决不了跨系统、多步骤、有条件分支的复杂业务。AI 原生应用要做流程智能——一条业务链路里多个 AI 节点协同，每个节点干自己擅长的事。

实际场景：客户咨询退款。链路是这样的——

AI 节点 1（意图分类）：判断是不是退款意图。是，进入退款流程。 接口节点 2：调 CRM 查客户订单。 AI 节点 3（决策判断）：基于订单状态判断符不符合退款政策。符合，继续；不符合，走解释分支。 接口节点 4：调企微 message/sendRichText 给客户发退款政策卡片。 AI 节点 5（文案生成）：起草给客户的解释话术。 接口节点 6：调 message/sendText 发话术，调 label/updateLabel 打"退款-已沟通"标签，调业务系统建退款工单。

链路里 AI 参与三个节点（分类、决策、生成），接口参与三个节点（查订单、发卡片、发话术+打标签）。每个节点单一职责，整个链路可观测、可配置、可灰度。AI 原生不是"一个 AI 包打天下"，是"AI 用在该用的节点上"。

范式差别：从工具型到员工型

最早的企微机器人是工具——没有身份、没有权限边界、没有协作对象，所有客户共用一个机器人。AI 原生应用要做员工型——机器人有工号、有岗位、有权限范围、有汇报对象、有 KPI。

落地时每个数字员工对应一个独立 appid（实例 ID），不共用账号——共用会导致客户关系混乱、消息归属错乱。岗位定义里写清楚能调哪些接口（sendText、getUserProfileDetail、updateLabel），不能调哪些（disband、群发）。重要决策（金额超阈值、合同变更）必须请示真人主管，主管审批后才能继续执行。

员工型的核心是身份和权限，不是 prompt。给机器人起个名字写个 system prompt 不是数字员工，把账号、岗位、权限、协作、考核做扎实才是。这套做下来，数字员工和真人员工协同——客户分不清谁是人谁是数字，只觉得"这个团队响应真快"。

范式差别：从指令交互到自然语言交互

传统企微二开要求员工记指令——"/查客户 张三"、"/建工单 退款"。AI 原生应用要的是员工自然说话——"帮我查一下张三最近一单的状态"、"这个客户要退款先建个工单"，AI 解析意图、提取参数、调对应接口。

底层是把企微接口包装成大模型可调用的工具，工具描述包含名字、说明、参数 schema。模型负责解析员工自然语言、挑出对应工具、传参、调用，接口负责执行。员工感知不到接口，只感知到"我说什么机器人做什么"。这种交互范式让企微从"指令终端"变成"业务对话终端"。

范式差别：从单模态到多模态

最早的企微机器人只处理文本。AI 原生应用要处理多模态——客户发语音、发图片、发文件，机器人都要能理解并行动。

语音侧用 cdn/download 拉语音消息文件，调语音识别模型转文字，再走文本链路处理。图片侧用 cdn/download 拉图片，调多模态模型识别内容——客户拍个产品故障图，模型识别出故障类型，机器人调 contact/search 找负责技术、调 message/sendFile 把故障图发给技术。文件侧拉文件后调文档解析，提取结构化字段填到下游接口参数里。

多模态不是炫技，是让客户用最自然的方式沟通——客户懒得打字描述故障，拍张照发过去最快。机器人能理解多模态，业务入口就宽了。

落地路径：不要一上来就追全自主

AI 原生应用落地不要一上来追"全自主数字员工"。我们走的节奏：

第一阶段：单点智能试点。选一个边界清晰的场景（如 FAQ 客服）接 AI，验证模型准确率、接口稳定性、回调链路。 第二阶段：流程智能。把跨系统的复杂业务（如退款咨询）做成工作流，多 AI 节点协同。 第三阶段：员工型数字员工。给机器人建独立账号、定义岗位、配置权限、纳入组织通讯录。 第四阶段：AI 原生平台。把上述能力沉淀成平台，运营自助配置新 AI 应用，研发退居节点维护。

跳级上线等于让没实习过的新员工处理所有公司业务，事故必然频发。每阶段稳定后再开放下一层，这是被事故逼出来的节奏。

几个常被忽视的工程要点

AI 原生应用做扎实，几个工程细节躲不掉：

• 状态持久化：AI 决策、工作流上下文、对话记忆都要落库。早期用内存存，一次重启丢了一堆跨天工作流。

• 节点幂等：每个动作按 instance_id + node_id + attempt 做幂等键，重试不重复执行副作用。

• 审计追溯：所有 AI 决策、工具调用、和客户对话都要留痕。客户说"你们的数字员工发错了消息"要有完整链路可查。

• 失败兜底：AI 输出是概率性的，低置信度走人工，别硬调接口。早期没做兜底，模型决策错一次整条流程崩。

写在最后

企微二次开发走到 AI 原生这一步，本质是把企微接口（消息、联系人、标签、群、文件）当作 AI 的手脚，让大模型当中枢、让工作流引擎串链路、让数字员工进组织。AI 原生不是把 AI 嵌进企微，是从设计上就以 AI 为业务核心。把身份、权限、流程、记忆、审计这几个工程维度做扎实，企微就从"通讯工具"变成"业务对话终端"——员工和客户用一句话办事，机器人调一串接口把事办完。这才是企微二开往下走的方向。