企业微信 AI 员工怎么理解

这个词到底承诺了什么

「AI 员工」和「机器人」「智能客服」在能力清单上区别不大 —— 都是收消息、查资料、回话、必要时找人。差别在承诺的粒度。机器人对一次消息负责：你问它答，答完这件事就结束了。AI 员工对一段任务负责：客户的问题从进来到解决，中间要不要查资料、要不要建单、要不要催同事、要不要第二天回访，都算在它头上。

这个差别一旦成立，后面全是硬约束。对任务负责就必须有状态，得知道这件事进行到第几步、卡在谁那里；必须有交接协议，做不下去要交给人而且要交得清楚；必须能被问责，事后能复盘它当时依据什么做了那个判断。这三样机器人都不需要，AI 员工一样绕不过去，而它们全都是状态管理和审计的活，和模型能力没关系。

拆开看是五块

1. 1身份与通道：一个能被程序驱动的企业微信账号，消息与事件能稳定进出，掉线能自愈。
2. 2上下文：多轮边界、窗口装配、摘要与事实槽位。做不好的表现是客户要重复说三遍。
3. 3知识与工具：能查什么、能做什么。查是检索，做是调用你自己的业务接口。
4. 4边界与兜底：什么时候必须停、停了交给谁、交接时带什么、人接手后它闭不闭嘴。
5. 5绩效：产出怎么度量、什么算完成、什么算返工、谁来看这些数。

直觉上工程量应该压在第二、第三块偏模型的那一侧，实际分布完全不是。第一块通常最先解决：用 wecomapi 把账号托管起来，消息收发与事件订阅走同一套接口，登录态保活、异常自愈和实例隔离不用自己维护，这块能从几周压到几天。第二块有成熟做法，照着做就行。真正的大头在第三块的「做」和第四块的兜底，而这两块几乎全是你自有系统的活。

这个分布很重要，因为它决定了排期该怎么排、人该往哪投。把三分之二的人力投在提示词和模型选型上，最后卡住项目的一定是「退款动作没有幂等」「转人工之后没人接」这类看起来很土的问题。

工程量的大头：工具调用与兜底

「能查」不难，检索接一套就有，语料治理麻烦但路径清楚。「能做」是另一回事：让模型去改一条订单、发一张券、建一个工单，你要为每一个动作准备幂等键、权限校验、参数校验、失败回滚和审计记录。一个动作从「有接口」到「能给模型调」，中间是三到五天的工程量，不是三小时 —— 因为你面对的调用方不再是一段确定的代码，而是一个会重试、会传错类型、会在超时后再试一次的调用方。

而且动作数量是乘数。十个动作就是十份这样的工作，还要加上它们之间的组合失败：建单成功但通知失败、发券成功但记录没写、改了地址但没同步给仓库。这些在人工操作时靠人当场补，交给程序就得写进代码，而且要写在能被复盘的地方。

// 示意逻辑：对外发消息这类不可撤动作走 wecomapi 的发送接口
// 端点与字段以线上文档为准，这里只表达包装层的顺序
async function callTool(name, args, ctx) {
  assertAllowed(name, ctx.role);                  // 1 权限：不是所有动作对所有角色开放
  const key = idemKey(ctx.taskId, name, args);    // 2 幂等：模型重试是常态不是异常
  const hit = await idem.get(key);
  if (hit) return hit;                            // 重复调用直接返回上次结果

  const out = await TOOLS[name](validate(name, args)); // 3 校验：别信模型给的类型
  await audit.write({ key, name, args, out, taskId: ctx.taskId }); // 4 审计
  return idem.put(key, out);
}

第一个动作的包装最贵，后面的能复用大半。所以第一版只开放两三个动作，把包装层打磨对，比一次接十个再回头补要快得多。选哪两三个也有讲究：优先选可撤销的、影响范围小的、出错时客户不会立刻感知的。

兜底那块同理。「转人工」三个字背后是一串必须有确定答案的问题：判定条件是什么、值班表从哪来、非工作时间怎么办、无人应答多久算超时、客户在等待期间又说话了怎么办、人接手之后 AI 是彻底闭嘴还是继续在后台准备资料。每一条没答案的地方，线上都会出现两种声音同时对着客户说话。

任务状态要独立于会话存储。会话可能断、可以清、可能被客户删掉，任务不能跟着一起没。用 wecomapi 的事件回调驱动状态机往前推进，状态本身落在自己的库里，这样以后换接入方式、加一个新的入口渠道，状态机都不用重做。

成本结构：上线不是省人的开始

最常见的误判，是把成本算成「一次性开发费 + 按月推理费」。真实成本里最大的一块是持续的，而且它不在技术预算里。

• 知识维护：产品改一次，知识库要跟一次。没人跟，三个月后 AI 员工会一本正经地讲去年的政策。这是需要固定有人负责的常规工作，不是项目期任务，也不能顺手挂给已经很忙的产品经理。
• 话术回归：改一次提示、换一次模型版本，之前修好的问题可能回来。需要一组固定的回归用例，几十条起步，每次变更跑一遍并人工看结果 —— 这件事没法完全自动化。
• 异常处理：AI 处理不了的会集中流向人，而且这部分往往是最难的那些。承接率 70% 不等于人力降 70%，剩下的 30% 每一个都比平均值贵，还失去了简单案例带来的喘息时间。

所以前两三个月大概率是净增成本：老流程还在跑，新链路要人盯，知识要人补，出了问题还要有人查。评估企业微信AI员工方案的时候，把这段爬坡期明确写进预算和排期，比在准确率上讨价还价有用得多 —— 项目死掉的常见原因不是效果不好，是第二个月被问「说好的省人呢」。

验收口径：四个指标一起看

「AI 员工好不好用」如果没有口径，最后一定变成体感之争 —— 业务方举三个失败案例，技术方举一堆成功案例，谁也说服不了谁。四个指标就够，关键是必须一起看，单看任何一个都会被优化坏。

1. 1承接率：进来的任务里有多少完全由 AI 走完、不需要人介入。单看这个，会被优化成「什么都不转人工」。
2. 2闭环率：AI 走完的那些里，有多少真的解决了问题。判据用客观信号 —— 客户没有就同一问题在几天内再次找上来。
3. 3升级率与升级质量：转人工的比例，以及人接手时要不要重新问一遍客户。要重问，说明交接是坏的，这时候升级率再低也没意义。
4. 4返工率：AI 做过的动作里，事后被人改掉或撤销的比例。这是四个里唯一能反映「做错」而不是「答错」的指标，也是最该盯的一个。

为什么必须一起看：承接率和闭环率互相制衡，硬提承接率会让闭环率掉；升级率和升级质量互相制衡，压低升级率会让交接变糟。只报承接率的方案，通常在藏后面三个数。这四个指标的定义要在上线前就写死，包括统计口径和时间窗，上线后再定义会不自觉地往好看的方向调。

什么时候不该做

• 会话量不够：一天几十通、人工完全接得住，这套系统的维护成本会长期高于它省下的人力。
• 知识不稳定：产品或政策每周在变，知识维护的持续投入会持续超过收益，而且答错的概率始终压不下来。
• 动作不可撤且金额敏感：先做「查」，不要做「做」。这类场景下，一次事故足以让整个项目下线。

三条里命中任何一条，正确做法不是不用 AI，而是不给它任务所有权：让它查资料、拟草稿、给坐席提示，人来按每一个按钮。这个形态不占工位、不背绩效，收益照样有，而且随时可以停。等到量上来了、知识稳了、动作包装层攒厚了，再往上走一档，那时候「AI 员工」才是一个能兑现的说法。