Windows 微信自动回复
模型怎么分工，话术怎么生成

01 / ARCHITECTURE先看清三层分工

微信执行端管“看和操作”，服务端管“该不该回、怎么回”，数据层管“记住谁、说过什么、依据是什么”。

02 / MODEL ROLES模型总表：先看谁干什么，再逐个展开

最关键的两位是：Qwen 3.8 Flash 读屏，Qwen 3 235B 2507 写回复。其他模型负责分析记忆、检索依据或特定失败恢复。

读屏模型和文字模型的名字很接近，但输入、任务和部署位置不同。Windows 读屏配置来自设备环境变量，服务端回复模型来自服务端环境变量；改其中一个不会自动改另一个。

02.A / 读屏模型第一位：看清微信里“谁说了什么”

主模型 qwen/qwen3.8-flash。它拿到的是截图和读屏要求，任务是识别界面，不是替销售回答问题。

一次实际调用的结构

Windows main.py 读取设备配置
  → 创建 Vision(VisionConfig(...))
  → runner 根据当前任务调用标题 / 聊天 / 历史读取
  → Vision._call_model(截图, 该任务的读屏要求)
  → POST {AKKE_WEIXIN_VL_BASE_URL}/chat/completions
  → 解析模型返回的 JSON
  → 身份、方向、置信度及降级状态检查

请求核心内容（示意）：
model: qwen/qwen3.8-flash
temperature: 0
reasoning: { enabled: false }
messages: [{ role: user, content: [读屏要求, 图片] }]

为什么要把“思考”关掉

这里需要的是忠实抄读画面，而不是自由推理。当前代码显式发送 reasoning.enabled=false，让读屏主模型不要先展开思考。仓库中的局部测试记录曾发现：不关闭时坐标结果会变差，推理还会增加耗时和输出用量。这是该链路的实现依据，不是对所有推理模型的普遍评价。

读不出来时怎么退

普通读屏请求主档失败后，代码可尝试 qwen/qwen3-vl-235b-a22b-instruct。后备结果会带 degraded 标记，意思是“这次用了后备模型”。后续检查仍决定是否接受；历史读取有专门的有界调用逻辑，不能把所有读取任务都描述成必定轮流调用两档。

现在还会专门用一个小模型读标题吗

最新代码把 small_model 默认设为空，标题、列表行这类“小任务”跟随主模型链。历史上曾把这些任务分到较小模型，当前默认已取消这档分流。某台电脑如果仍有旧环境变量覆盖，行为可能不同，因此要以该机配置和日志核对。

02.B / 回复模型第二位：根据业务依据，把回答组织成人话

当前生产回复模型是 qwen/qwen3-235b-a22b-2507。它通过服务端调用，名字里虽然也有 Qwen 和 235B，但与备用读屏模型是不同模型。

它实际拿到的不是一句孤零零的客户问题

从请求到模型的代码路径

Windows Relay.generate(...)
  → 配置的回复接口（可经 Fly 中转）
  → /api/wecom/chat/reply，action=generate
  → 鉴权、认人、去重、加载上下文、选择直答或生成
  → chatReply(...)
  → getSystemPrompt(...) 组装话术依据
  → resolveChatModel(persona, channel=weixin)
  → getClient() 创建 / 复用 OpenAI 兼容客户端
  → observeLLM(...) 包装调用以记录追踪
  → chat.completions.create(...)
  → 解析文字 / 工具调用，清理与检查

默认用哪个平台调用

getClient() 默认指向 https://openrouter.ai/api/v1，使用 OpenAI 兼容的接口格式。OpenRouter 在这里是模型接入平台，不是另一个“回答模型”；Fly Relay 是网络中转，也不是模型。LLM_BASE_URL 可以覆盖默认服务地址。

为什么不直接用更大、更新或会长思考的模型

仓库的选择记录看重的不只是单轮话术评分，还包括真实回复耗时、长对话稳定性、事实正确性以及是否会超时。历史上有模型在评测中评分较好，但生产中长思考拖慢请求并出现异常，随后回滚到当前模型。这解释了现有选型的脉络；本次没有重做模型对比，也不把历史结果当成永久排名。

02.C / 辅助模型另外几位负责“记住”和“找资料”

这几项是否每轮都调用

不一定。纯“好的、谢谢”等附和通常不值得抽画像；摘要要攒够增量才更新；向量有缓存；规则直答、甲方审定原文也可能跳过文字生成。不能用“收到 100 条微信”直接推算“文字模型调用 100 次”。

02.D / 失败与追溯空回复、网络失败、内容违规是三类不同问题

想弄清一条回复，应该记录哪几版

至少分清：Windows 客户端版本和实际读屏模型 → 服务端代码版本 → 实际文字模型 → Langfuse 提示词版本或回退状态 → 输入知识与记忆 → 原始生成及后续删改 → 客户端实发与 confirm。只拿最后一句话，无法准确判断是哪一层造成的。

要换模型，改哪里

03 / REQUEST PATH客户来一句话，内部按什么顺序处理

POST 配置的 …/wecom/chat/reply
Authorization: Bearer <专用凭据>
{
  "action": "generate",
  "channel": "weixin",
  "persona": "<已绑定销售人设>",
  "customerName": "<已核对联系人>",
  "message": "<最新一条客户原文>",
  "conversationIdentity": "<稳定身份>",
  "clientContext": { "recentMessages": [] }
}

可发：reply / conversationId / replySource / posterUrls / posterIds
不发：skipped / reason 等（例如 needs_human）

发送验收成功 → action=confirm
提交 conversationId、实际正文 content、实际发送的 posterIds

04 / TALK TRACK话术从哪里来：七层材料一起拼

最终输入不是一段固定“销售提示词”。getSystemPrompt 先构建系统要求，chatReply 再加入压缩后的历史和本轮专用指令，交给模型。

04 / 继续展开“知识库、示例、审定话术”有什么不同

检索不是“什么都塞给模型”

系统先看客户当下这句话，挑相关材料。客户只说“全屋”“是的”时，知识检索会带上紧邻的一问一答，让检索知道他到底在回答什么；对话示例的匹配则仍按客户原句处理，避免被上一句销售话带偏。

知识文档、规则与示例的一条路径用 bge-m3 算相关度；长资料的另一条路径用 bge-small-zh-v1.5 检索资料分块。后者代码默认取最多 4 段、同一份资料最多占 2 个名额，并限制注入文字量；这些是代码默认，环境变量可能覆盖。

甲方审定话术有一条“可以不调用文字模型”的路

所以 route 返回 generated，也不一定代表底下实际请求过文字模型：chatReply 内部还可能走审定原文或其他直答。要判断实际是否调模型，需要结合调用记录，而不能只看外层来源字段。

门店工作台怎样进入这套能力

loadOrgContext 是统一装配点：把品牌、知识、示例、规则、审定话术，以及启用的工作台业务事实和规则合在一起。知识元素功能开启时，部分文档会用已启用的知识元素替代全文；没有可替换内容或查询失败的路径仍有原文处理机制。

04 / 记忆与阶段它怎样记住客户，又为什么有时仍会重复问

画像抽取和摘要更新通过响应后的后台任务处理，避免让客户一直等。但这也意味着：刚刚说出的事实，不能假设已经写入画像。当前轮仍要看客户原话；报价相关代码也会直接从本轮内容取信息。

有可靠身份关联时，系统还能补充抖音侧的结构化画像；个人微信同销售号的旧会话事实也有专门继承逻辑。这些都有身份匹配条件，不能仅靠“昵称相似”就宣称全平台记忆已打通。

当前回复阶段，不等于客户在报表里的阶段

普通回复只在 nurture（继续了解、解释问题）和 decision（出现更明确的决策信号）之间选择。它根据近期客户的话重新判断，信号消失时可以恢复培育口吻。数据库的阶段则保留客户曾到达过的进展，不一定一起回退。

例如客户前面问过到店，后来只是在问某种板材，系统不应该因为“历史上到过决策期”就每轮都强推到店。这是“本轮怎么接话”与“客户曾走到哪一步”分开记录的原因。

04 / 连续对话示意沿着一段对话，把前面的机制串起来

以下是解释代码路径的假设场景，不是真实客户对话，也不是本次在线调用模型得到的结果；不承诺实际回复逐字相同。

05 / THREE SCENARIOS被动回复、首次打招呼、主动召回要分开看

06 / GUARDS & RECEIPTS生成完成 ≠ 已经发出

最终回复有两种主要来源：规则直接给出，或模型生成后再检查。route 用 replySource 标记来源，sanitizerActions 标记部分处理动作；删改和整条替换另有事件留痕。还原模型原文时，也要注意 chatReply 内部已经可能重写过。

07 / DEBUGGING & CHANGE POINTS以后查问题、改话术，从哪里下手

07 / 常见问题几个最容易误会的地方

08 / 优化建议与修改方法怎样改得更好：先找问题在哪层，再决定改哪里

不要一遇到答得不好就换模型，也不要把所有要求都追加到 Langfuse。先还原“它看到了什么、参考了什么、生成了什么、最后发了什么”，再改真正造成问题的那一层。

1．什么情况改 Langfuse，什么情况改代码

2．Langfuse 和代码不是二选一

阶段模板放在 Langfuse，代码通过 getPrompt 读取并替换占位符；当读取失败时，代码里的 FALLBACK 模板顶上。与此同时，人设、个微附加要求、报价、门店清单、本轮动态指令等仍会由代码拼进去。

3．建议按这个顺序优化话术

4．模型怎么比较：读屏和话术分开评

建议统计方式：报告样本数和失败明细，耗时同时看中位数及较慢的一批；分别统计原始生成与最终可发结果。单次模型便宜，若导致频繁重试、人工接管或认错消息，整条业务链未必更便宜。

5．已有工具如何用，以及它们验不到什么

下面是后续实际修改时可用的命令参考，本次未执行付费评测。运行前需要有效的封顶评测密钥；生产调用路径的临时试跑应使用 AKKE_USE_EVAL_KEY=1，并设置 AKKE_RUN_BY 记录执行者。

# 在对应仓库的隔离工作区执行；先留改前基线，再测 staging
AKKE_USE_EVAL_KEY=1 AKKE_RUN_BY=xiaxia \
  pnpm tsx scripts/eval-wecom-talktrack.ts --channel=weixin --samples=5

AKKE_USE_EVAL_KEY=1 AKKE_RUN_BY=xiaxia AKKE_PROMPT_LABEL=staging \
  pnpm tsx scripts/eval-wecom-talktrack.ts --channel=weixin --samples=5

# 只核对 production 提示词与仓库快照是否漂移，不写文件
pnpm tsx scripts/snapshot-langfuse-prompts.ts --check

# 核对仓库快照与代码 fallback 的正文，以及占位符结构
pnpm tsx scripts/check-prompt-fallback-sync.ts
pnpm tsx scripts/check-prompt-placeholders.ts

话术脚本走 chatReply 和真实组织上下文，适合验证生成层，但并非“完整 Windows GUI 测试”，也不覆盖 route 中所有后处理。长对话可参考 eval-wecom-longrun.ts 的画像与摘要测试，并核对测试通道是否符合本次改动；读屏与发送需要另外使用固定截图和受控会话。

快照 --check 只报告差异。正式修改 Langfuse 后，要按发布流程拉取更新后的快照、同步 fallback 并走代码评审；不能为了让检查变绿，盲目把较新的一边覆盖成较旧的一边。

6．可以直接用于下一次优化的交付清单

每次记录：问题样本 → 原因所属层 → 具体改动 → 影响范围 → 改前结果 → 改后结果 → 实際生效版本 → 回退方法。例如“客户短答后连续追问”，先确认上一轮销售问题确实带入；若输入正确再改表达，若短答分支没触发就修代码。这样每次优化都有证据，而不是不停往提示词末尾追加禁令。

09 / EVIDENCE本页依据与核对范围

以下链接固定到本次分析的提交，便于追溯；私有仓库需登录 GitHub 才能打开。