企业微信接入 OpenAI 怎么做

动手前先过两道闸

这两道闸没过就开始写代码，返工概率很高，而且返的通常是整条链路。

1. 1数据这一道：客户消息原文要不要送进模型、能不能脱敏、哪些字段必须留在境内、留存多久。用境外模型服务意味着数据出境，这件事需要按你们自己的合规流程评估和签字，不是工程侧能单方面决定的。工程上能做的是把「送出去什么」收敛到一个函数里，让脱敏策略可审计、可一键收紧。
2. 2网络这一道：出口链路的稳定性和延迟抖动决定了你的超时预算怎么定。这里要拿到的不是平均延迟，是 P95 和抖动幅度，以及一天中最差的那个时段。按平均值设计超时的系统，会在高峰期集体超时。

两道闸的结论要落成两个数字写进设计文档：允许送出的数据范围，和端到端可用的时间预算。后面每一个技术决定都要回来对照这两个数。

链路分四层，模型网关是唯一值得自己写的那层

最省事的写法是在消息处理函数里直接 import 供应商 SDK 调一下。它能跑，也是后面所有麻烦的来源：计量没地方挂、限流没地方做、换模型要改十几处、灰度只能靠 if。

• 接入层：收发消息与事件。用 wecomapi 的事件回调收消息、发送接口回写结果，回调进来先快速 ACK 再入队，模型调用一律不在回调的请求生命周期里做。
• 会话层：任务、上下文组装、幂等。同一条用户消息重复投递时，这一层负责让它只产生一次模型调用。
• 模型网关层：供应商适配、超时与重试、配额与熔断、用量计量、模型路由与灰度。这层是自己写的核心。
• 供应商 SDK：只做协议细节，藏在网关后面，业务代码不认识它。

一个容易被忽略的账：一条用户消息往往不止一次模型调用 —— 意图分类一次、检索改写一次、生成一次、内容审核可能还有一次。成本要按会话算，不能按消息算；网关层是唯一能把这几次调用归到同一个会话下的位置，没有它，月底账单只能看到一个总数。

超时预算从体感倒着切

先定用户侧的两个数：多久之内必须有反馈，多久之内必须有结果。在 IM 里，前者两三秒是上限，超过就该先发一条占位或回执；后者十秒左右，再长就要改成「先回执、稍后补发结果」的两段式。这两个数定下来，剩下的全是分配。

1. 1回调 ACK 必须在毫秒级完成，它不占预算。占了就会被判超时重投，同一条消息触发多次模型调用，成本和错误一起翻倍。
2. 2队列排队时间要算进预算，而且要监控。高峰期排队三秒的系统，模型再快也来不及。
3. 3检索、模型、发送各自有独立 deadline，三者之和加上排队要小于总预算，留出至少两成余量。
4. 4重试要带剩余预算，不能写死三次。预算只剩一秒时重试没有意义，此时正确的动作是降级。

还有一条经常漏：客户端超时不等于服务端取消。你的请求超时返回了，模型那边通常还在算，算完照样计费。要让取消真正生效，得用支持取消的调用方式并在超时时显式中止，否则你会持续为已经没人要的答案付钱，而这部分成本在账单上和正常调用长得一模一样。

// 示意逻辑，函数与参数均为自拟；发送接口的精确字段以线上文档为准
async function answer(session, text, budgetMs) {
  const t0 = Date.now();
  const left = () => budgetMs - (Date.now() - t0);

  if (await quota.exceeded(session.tenantId)) return fallback(session, "quota");

  const ac = new AbortController();
  const timer = setTimeout(() => ac.abort(), Math.min(left(), 8000)); // 超时要真中止
  try {
    const r = await provider.chat({ input: text, signal: ac.signal });
    await usage.record(session.id, r.usage, { stage: "generate" });   // 计量挂在会话上
    return send(session, r.text);
  } catch (e) {
    if (left() > 1500) return answer(session, text, left());          // 有预算才重试
    return fallback(session, e.name);
  } finally { clearTimeout(timer); }
}

async function send(session, content) {
  return fetch("https://manager.wecomapi.com/message/sendText", {
    method: "POST",
    headers: { Authorization: `Bearer ${TOKEN}`, "Content-Type": "application/json" },
    body: JSON.stringify({ guid: session.guid, toId: session.toId, content }),
  });
}

流式在 IM 里怎么用

网页端的流式价值在逐字显示，IM 里没有这个东西 —— 消息是一条一条发的，用户看不到「正在生成」。所以在这个场景下，流式的价值不是体感，是两件工程上的事：首个 token 的到达时间可以被测量，以及跑偏时可以提前中止不用等生成完。

• 别把每个 chunk 发成一条消息。刷屏之外还会迅速撞上发送频率约束，体验和稳定性一起崩。
• 可行做法是按句或按固定字数聚合，一次回复最多拆成两三条，长回答优先考虑压缩而不是分段。
• 用首 token 时间做占位决策：超过阈值还没有首 token，先发一条「在查了」，别让用户对着空白等。
• 生成中检测到明显跑偏或命中拦截规则，立刻中止，省下的是尾部 token 的钱，也避免了发出去再撤回。

成本卡在四个位置，从便宜到贵

先说一个常被搞反的事实：多数对话场景里，输入 token 才是大头，不是输出。系统提示、检索片段、历史上下文每轮都要重发一遍，优化这一侧的收益远大于让模型少说两句。

1. 1上下文预算：给每次调用定一个输入上限，超了先截断历史再考虑滚动摘要。别把冗长的系统提示每轮重发，也别把整份检索结果一股脑塞进去 —— 命中三条通常比命中十条效果更好，还便宜。
2. 2缓存与去重：高频重复问题命中缓存直接返回；短时间内的重复消息（客户连点发送）先去重再进模型。这两条实现成本极低，是性价比最高的一档。
3. 3模型分级路由：意图分类、敏感判断这类活用小模型或规则做，只有真正需要生成的那一步用大模型。路由本身别用大模型来做，那就白省了。
4. 4配额与熔断：按会话、按租户、按天设预算上限，超了直接降级而不是排队。同时对单会话 token 突增做告警 —— 它通常意味着上下文没截断，或者有人在拿你的助手当免费接口用。

这四条的前提都是计量。每次调用的用量落库，按会话、租户、场景、模型四个维度归集；会话维度建议直接对齐 wecomapi 侧的账号与会话标识，否则跨账号的成本分摊算不出来。归集齐了你才能回答「这个功能一个月花了多少」。没有归集就没有成本控制，只有一张月底才看得到的总账单，而那时候已经没有可优化的抓手了。

降级链要事先写死

供应商会抖动，这是设计前提不是意外。要事先定好四级降级，并且每一级都能被单独触发和演练：正常生成 → 换更小更快的模型重试一次 → 命中缓存或固定话术 → 明确告知并转人工。最后一级永远不能省，静默失败在 IM 里的观感就是「这个号没人管」。四级之间只有答案的来源不同，出口是同一个 —— 换小模型、命中缓存、固定话术、转人工前的那条告知，最后都是同一次 wecomapi 发送调用。把这个出口收成一个函数，「每一级单独触发」才有地方落实；发送逻辑散在四个分支里，演练时你连自己走的是哪一级都分不清。

• 多供应商适配值得做，自动双跑不值得 —— 成本翻倍换来的可用性提升，通常不如把降级链做扎实。
• 降级要记录原因和当时的预算余量，否则事后分不清是超时、限流还是配额触顶。
• 定期演练：把供应商调用强制失败一次，看用户侧收到的到底是什么。没演练过的降级链，一半概率在真出事时也是坏的。