企业微信接入 Claude 怎么做

「能塞多少」和「该塞多少」是两个问题

长上下文模型最容易被误用的方式，是把它当成不用做检索的理由：反正窗口大，把资料全文和整段会话历史一起塞进去就完事。这个做法在演示里效果很好，在生产上有两个确定的后果 —— 单次调用成本随会话长度线性上涨，而回答质量并不随塞进去的量单调上升。

后一条值得说清楚。相关信息被埋在大量无关内容中间时，模型的命中率会明显下降，这不是某个厂商的实现缺陷，是长序列的普遍表现。所以「塞更多」和「答得更准」之间没有必然关系，真正有效的是「塞得更准」。窗口大带来的红利，应该花在少做几次截断、少丢几轮上下文，而不是省掉检索这一步。

• 正确用法：让一次完整的多轮会话不被粗暴截断，让检索出来的片段能带上足够的前后文
• 错误用法：拿窗口大小当检索的替代品，把整份资料当成提示词的固定部分
• 判断线：能用一次检索把候选压到几千字以内，就不要靠窗口硬扛

会话边界：IM 里没有「新建对话」按钮

网页端的对话有明确的开始和结束，用户点一下就换一轮。企业微信里没有这个动作 —— 同一个客户的会话是一条从加上好友那天起就不再断开的长河。如果你把「会话」直接等同于「这个客户的全部历史」，上下文只会越来越长，且越来越多是噪声。

所以边界要由你自己切。用 wecomapi 的事件回调拿到消息之后，先做的不是组装提示词，而是判断这条消息属于哪一段会话。超时切、显式切、话题切各自的准确率与代价，站内讲 AI 会话上下文那篇已经比较过，这里只补长上下文场景特有的一条：窗口越大，切边界越容易被一直推迟。小窗口不切会直接把请求撑爆，逼着你处理；大窗口不切什么都不会发生，它只是安静地把成本和噪声一起带上，直到某天有人对着账单问「为什么单次调用比上个月贵了三倍」。

• 按时间窗切，不要按消息条数切。条数切法会把一段连续的追问从中间劈开，而那正是最不该断的地方
• 边界要落库，不要每次现算。现算意味着同一段历史在不同时刻可能被切成不同形状，排查时你复现不出来
• 跨越边界的不是全部信息：客户身份、长期偏好、未结事项以摘要形式带过去，原始对话不带

最后一条最常被漏掉：切边界不等于失忆。把「需要长期记住的」和「这一轮的对话历史」分成两块存，前者是几行结构化摘要，后者随边界丢弃。混在一起的结果是，为了记住客户的公司名，你把三个月的闲聊一起拖着走。

上下文预算要按四类内容分开算

把上下文当成一个总量去截断，是第二个常见错误。窗口里该装哪几段是上下文管理的通用问题；长上下文要在它之上多做一件事 —— 给每一类内容单独划一份预算并分开监控，而不是共用一个总额。这里按四类划：系统指令与工具定义、检索片段、对话历史、工具返回结果。四类的增长方式完全不同，混在一起截断时，被砍掉的往往是最不该砍的那一类，而窗口越大，这个错误越晚被发现。

1. 1系统指令与工具定义：几乎不变，但会随功能增加悄悄膨胀，是唯一该定期做减法的部分。
2. 2检索片段：由你控制条数，超预算就减少条数，不要截断单条 —— 半条知识比没有更危险。
3. 3对话历史：按轮次从旧到新丢弃，最近几轮永远保留。
4. 4工具返回结果：最容易失控的一类。一次列表查询就能返回几十 KB，足以把其余三类挤没。

第四类值得单独设一道闸。工具返回必须在进入上下文之前被裁剪成模型真正需要的字段，而不是把原始响应整段贴进去。举个具体的：查一次群成员，wecomapi 返回的是给程序消费的结构，整段贴进上下文既贵又帮不上模型 —— 它需要的往往只是其中几个名字。裁剪写在工具适配层，别指望在提示词里叮嘱模型「只看你需要的部分」—— 那部分内容的费用在它读之前就已经产生了。

// 示意逻辑，函数与字段均为自拟；精确字段与端点以线上接口文档为准
async function build(sessionId, text) {
  const seg = await session.segment(sessionId);      // 会话边界，见上一节

  return [
    ...SYSTEM_BLOCK,                                 // 稳定前缀，放最前且不带时间戳
    ...await kb.search(text, { maxChars: 4000 }),    // 超预算减条数，不截断单条
    ...await history.load(seg, { maxChars: 6000 }),  // 从旧到新丢，保留最近几轮
    { role: "user", content: text },                 // 变化最快的放最后
  ];
}

// 生成结果最终经发送接口回写，形如 https://manager.wecomapi.com/message/sendText

前缀稳定性决定账单，不是窗口大小

做企业微信大模型接入时最有杠杆的一条优化，不在模型选型，也不在窗口大小，而在你拼提示词的顺序。主流模型服务对重复出现的相同前缀都有缓存机制，命中的那部分成本和延迟都远低于重新处理。这意味着：稳定的内容放前面、变化的内容放后面，同一段系统指令在一天几万次调用里只需要被完整处理少数几次。

会毁掉缓存的写法有几种，都很常见。在系统提示里插当前时间，每次调用前缀都不同，缓存永远命中不了；把用户名或会话标识拼进系统指令开头，等于每个客户一份缓存；每次请求重新拼一遍工具定义且顺序不固定，同样作废。这些写法在功能上完全正确，代价只体现在账单上，所以很难被发现。

• 顺序固定成：系统指令 → 工具定义 → 长期不变的业务说明 → 检索片段 → 对话历史 → 本轮输入
• 需要当前时间就放进本轮输入或工具返回里，不要放进系统指令
• 工具定义的序列化顺序要稳定，别用会随机排序的结构
• 改系统提示词是一次全量缓存失效，值得攒着一起改，而不是每天动一点

这一条和上一节的预算是一对：预算控制「这次要处理多少」，前缀稳定性控制「这些里有多少是重复处理」。两条都做了，长上下文才是划算的；只加窗口不管前缀，窗口越大账单越吓人。

群会话的历史里混着不该给客户看的话

单聊的上下文只有两个人，群会话不是。一个外部客户群里同时有客户、销售、售后，历史里可能有同事之间关于折扣空间、竞品、内部排期的对话。把群历史整段塞进上下文，模型没有任何理由不去引用它 —— 它不知道哪句话是不能对客户说的。

这个漏洞在测试环境几乎不可能暴露，因为测试群里的人都是自己人。处理方式也不是靠提示词约束，提示词挡不住这类问题。要在组装上下文那一步就按发言人身份过滤：对外可见的会话里，内部成员的发言默认不进上下文，需要进的显式白名单化。

• 每条历史消息都要带发言人身份标签。用 wecomapi 的事件回调收到群消息时就把它填好，别到模型层再回头查
• 群里的 @ 决定「要不要回」，不决定「能看多少」，两件事分开判
• 机器人自己发过的消息要标出来，否则它会把自己的上一条回复当成客户说的话，越滚越偏

生成期间用户又说话了

长上下文加检索的一次回答通常要几秒，而 IM 的节奏是秒级的。这几秒里客户很可能又补了两条消息 —— 补充条件、纠正说法，或者干脆是「在吗」。系统如果对每条消息都独立触发一次生成，客户会连着收到三条互不相搭的回复，而且每条都基于不完整的输入。

处理方式有三种，按场景选而不是全都上。合并：收到消息后等一个短窗口，窗口内的消息拼成一次输入再生成，最后只经 wecomapi 的发送接口回写一条，代价是所有回复都慢一点。取消重跑：新消息到达时中止正在进行的生成，用完整输入重新开始，代价是已经花掉的调用作废。排队：先把当前这轮答完再处理下一条，代价是第二条的回复可能已经过时。

客服类场景默认选合并，窗口取一两秒就能覆盖绝大多数「补一句」的情况；同一会话的生成必须串行，这两条是所有 IM 场景的通用底座，站内讲 AI 会话上下文那篇已经展开过。长上下文这里要额外算一笔账：被作废的那次调用比短上下文贵一个量级，所以取消重跑的门槛要往上抬 —— 只有新消息明显推翻了原来的输入时才值得，单纯的补充说明用合并接住就够。

1. 1先把会话级串行做出来。这一条不做，上面三种策略都不成立。
2. 2合并窗口要能按会话类型配置，群会话和单聊的合适窗口不一样。
3. 3生成中的会话要有一个可见状态，坐席打开会话时能看到机器人正在处理，避免人机同时开口。