企业微信接入大模型的四种架构

四档的分界线在「答案从哪来」

区分这四档的不是模型强弱，是答案的来源和动作的边界。第一档答案来自模型参数，第二档来自你自己的语料，第三档来自业务系统的实时状态并且会写回系统，第四档承认有一类问题不该由机器结束。这条线决定了每一档的成本压在哪里，也决定了它能撑多大规模。

• 直连模型：边际成本全在 token 与延迟，一两周能落地，适合内部问答、话术辅助这类答错代价低的场景。
• 加知识库 RAG：边际成本转移到语料治理，向量库那点开销不是重点，适合有文档沉淀、答案要有出处的售前与客服。
• 加 Agent 编排：边际成本变成工具调用的可靠性和错误动作的赔付，只有当答案需要动手时才值得上。
• 人机协同：边际成本是组织成本 —— 排班、交接规范、质检抽样，技术反而是最轻的一块。

第一档：直连模型，坑不在模型在会话

这一档的骨架就三步：从 wecomapi 的事件回调拿到消息、组装上下文调模型、再调发送接口把回复写回去。代码不到三十行，能撑住的场景也真实存在 —— 内部制度问答、给坐席做话术建议、会话摘要这类。

它翻车的地方几乎全在会话管理上。上下文如果按会话无限追加，单次调用成本会随聊天时长线性上涨，一个话痨用户能吃掉当天一半预算；模型偶尔超时或被限流，没有兜底的话用户那边就是彻底没反应 —— 在 IM 里「没反应」比「答错」更劝退。还有一条容易忽略：企业微信侧是一条一条的消息，不是流式输出，用户看不到「正在生成」，首包时间控制不住就得先发一条占位消息，否则体感等于掉线。

// 示意逻辑，函数与字段均为自拟；精确字段与端点以 wecomapi 文档为准
onMessage(async (msg) => {
  const ctx  = trimByBudget(await history.load(msg.session), 2000); // 按预算截断，别无限追加
  const slow = setTimeout(() => reply(msg, "在查了，稍等"), 1500);   // 首包兜底，避免体感掉线

  try {
    const answer = await withTimeout(llm.chat({ ctx, input: msg.text }), 8000);
    await reply(msg, answer);
  } catch (e) {
    await reply(msg, "这个问题我这边暂时答不了，帮你转同事");        // 失败必须有出口
    await handoff(msg.session, "llm_error");
  } finally {
    clearTimeout(slow);
  }
});

判断标准很简单：如果答错只是尴尬，不产生赔付或返工，这一档就够了，别急着往上加。

第二档：RAG 的成本不在向量库，在语料治理

加检索是从「能答」到「敢对外答」的分水岭。但很多团队的预算表算错了地方 —— 向量库和 embedding 通常只占零头，真正吃人力的是语料本身：谁把散在各处的文档、话术和历史工单收成一份可检索的语料，谁在产品改版后把过期条目下线，谁来决定同一个问题存在三个版本答案时以哪个为准。这三件事没人认领，模型再强也只是把过期答案讲得更流畅。

最容易漏的工程约束是检索层的权限过滤。同一个 AI 可能同时服务内部员工和外部客户，wecomapi 回调里带的发送方身份要一路透传到检索条件上；检索不带身份过滤，内部定价表、成本结构这类内容会被模型堂而皇之地讲给客户。这个漏洞在测试环境基本不会暴露，因为测试账号往往权限最大。

1. 1先看召回：把检索到的条目原样打出来。召回本身就不对的话，改多少提示词都没用。
2. 2再看切片：答案被切成两半、表格被拆散是高频原因，从 PDF 和长文档导入的语料尤其严重。
3. 3然后看时效：是不是有两条互相矛盾的条目同时在库里，模型只是忠实地在两个版本里挑了一个。
4. 4最后才轮到提示词和模型：前三步都干净了再调这里，否则你是在给错误答案做修饰。

第三档：Agent 编排，把「答错」升级成「做错」

上 Agent 的充分理由只有一个：答案需要动作 —— 查这个客户的订单状态、改一次预约、开一张工单。纯问答场景加 Agent，只会换来更长的延迟和更多的不确定性。

延迟是这一档最现实的敌人。多轮工具调用加上模型思考，十几秒很常见，而 IM 的对话节奏是秒级的，没人会盯着屏幕等。可行的做法是把一次交互拆成两段：收到请求先回一条明确的回执，结果出来再通过 wecomapi 补发一条。这不是体验优化，是让长任务能在 IM 里成立的前提。

• 读写分开授权：查订单可以让 Agent 直接做，改地址、退款、发券这类写操作必须落到人确认，哪怕只是坐席点一下。
• 工具调用要幂等且可重放。模型重试一次就多开一张工单，是这一档最典型的事故。
• 每次工具调用留完整的入参与返回。出事之后你要能回答「它当时凭什么做这个动作」，只有对话记录不够。
• 设动作预算：单次会话最多调几次工具、最多花多少秒，超了直接转人工，别让它自己绕。

第四档：人机协同，成本从技术转向组织

前三档解决「AI 怎么答」，第四档解决「AI 答不了的时候会发生什么」。它常被当成一个兜底开关，实际是一套结构：什么条件下交出去、交出去之前 AI 说过什么、坐席拿到手能不能立刻接上、这次失败有没有回到知识库里。

这一档的成本主要不在代码。阈值怎么定、坐席怎么排班、交接怎么规范、质检抽多少，都是组织侧的活。技术上要做的事反而很收敛：给会话加状态，人工接管期间 AI 必须闭嘴；把 AI 的判断依据一起交给坐席；把坐席的纠正回写成语料。

该停在第几档

1. 1日均会话几百以内、答错只是尴尬：停在第一档，把精力花在挑对场景上，而不是加架构。
2. 2对外客服、答案要有出处、答错要担责：第二档加第四档，这是大多数团队真正该落的位置。
3. 3答案必须读写业务系统状态：才考虑第三档，并且先只把读操作交给 Agent，写操作留人确认。
4. 4无论停在哪一档，都把「一条消息进来怎么产出回复」抽成同一个函数签名。四种实现可替换，你才有可能按会话类型分流、按比例灰度，而不是每换一档重写一遍链路。