问题结论
口径冲突人工说“昆明暂时没有”，自动回复说“有网络服务点”，未解释门店与服务点的区别。
不是模型慢11:06:17 首次出稿，模型耗时 12.5 秒；端到端准确耗时 29 分钟。
29 分钟原因拆解
18 次发送受阻16 次抢不到微信前台；2 次检测到销售操作而礼让。
反复重新生成发送失败后没有保存待发稿，重复生成 18 次，增加耗时与成本。
22 分 53 秒证据空档11:12:03—11:34:56 无集中日志，原因暂不能确定。
最后 12 秒11:34:56 末次生成，11:35:02 完成 GUI 发送与回执。
“抢不到前台”到底是什么意思
首要怀疑：销售切到了其他 Appno_foreground_late 只说明发送前获取微信窗口失败，不等于已经知道具体原因；窗口被最小化、句柄变化、Windows 拒绝切焦点、线程附着失败，都可能落到这里。
还缺什么证据失败时需要记录 GetForegroundWindow 返回的窗口句柄、进程名、是否最小化、切焦点返回值和失败阶段，才能确认是不是其他 App 抢走了焦点。
和销售同时操作时默认是“前台竞争”模式：销售操作会让礼让闸返回 courtesy_late；只有销售空闲达到阈值才尝试短暂占用前台。16 次 no_foreground_late 与 2 次礼让不是一回事。
当前日志的限制no_foreground_late 只是“发送前没有成功取得微信前台”的总出口，窗口最小化、句柄变化、Windows 拒绝切焦点、线程附着失败都可能落到这里。
当前方案：需要把微信放到前台
当前做法先确认微信窗口还在，再检查销售是否正在操作；允许后把微信切到屏幕最前，确认最前面的确实是微信，才粘贴文字并按回车。
为什么必须放到前台当前 Windows 端使用真实键盘焦点。微信不在前台时，粘贴和回车可能无效，更不能保证不会把客户话术输入到销售正在使用的其他 App。
现行路径的边界：这套方案能复用现有发送和回执确认，但会和销售的前台操作产生竞争；下面再评估完全不抢前台的替代方案。
不把微信放到前台：最小化/后台方案评估
目标销售继续用浏览器、表格或其他聊天工具，微信不抢屏幕、不抢键盘；自动化在后台完成读取、粘贴和发送。
先说结论：普通最小化不等于可靠后台把微信点到任务栏最小化后，截图可能变成空白或缺少自绘聊天内容；后台粘贴、回车也可能不被微信接收。因此“最小化后直接照旧运行”不能当成可上线方案。
三种不抢前台的实现路径
方案 1｜缩到任务栏怎么做：把微信点到任务栏最小化。
销售看到什么：微信不占屏幕，也不打断操作。
最大风险：微信缩小后可能不再提供完整聊天画面，后台粘贴和回车也可能无效。
结论：只能做对照测试，不能直接上线。
方案 2｜窗口藏到屏幕外怎么做：微信仍保持打开，但把窗口移到销售看不见的屏幕外。
销售看到什么：可以正常使用其他软件，微信不抢焦点。
最大风险：微信可能不接受后台截图、粘贴和回车（底层尝试用 PrintWindow、PostMessage）。
结论：最值得先做真机验证。
方案 3｜给自动化单独开一个桌面怎么做：自动化在一个销售看不见的 Windows 桌面里启动微信。
销售看到什么：自己的桌面完全不被抢，微信也能使用接近正常前台的输入方式。
主要难点：微信要重新启动，扫码、登录、掉线恢复和电脑重启后的自动恢复都要重做。
主要风险：隐藏桌面失效、微信崩溃或远程桌面重连后，可能出现后台假运行但实际不发；还必须防止输入错误回落到销售桌面。
验证顺序：先只读不发，再用测试账号验证粘贴、回车和发送回读，连续稳定运行 3—7 天后才考虑真实账号。
结论：长期最干净，但改造和维护成本最高。
推荐验证顺序：先测“窗口藏到屏外”能否稳定读消息，再测能否后台粘贴、回车并确认发送；失败后再做“独立隐藏桌面”。普通最小化只做对照，不做最终方案。
这 16 次现在能下的结论：不是“微信一定拒绝了 16 次”，而是“现有总出口无法区分具体失败类型”。下一步应把 no_foreground_late 拆成 window_missing、minimized、attach_failed、set_foreground_denied、foreground_changed_after_acquire 等子原因，再决定是修控制技术还是调整与销售并发的策略。
