接续同事 08-10《获客赛道竞品全景·九家整合版》。那份评的是产品完整度，这份只算一件事：客户发来一条消息，多久收到回复。只看企微通道、只取最近两天（更早的数据里系统状态不一致，参考价值有限）。
我们 81~86 秒（红蓝对抗直测 81 秒，440 组换算平均 86 秒，两者吻合）。影刀官方一个速度指标都没公布，按它的机制逐段推算约 14 秒。竞品心动、鲲炬宣称"秒级"，但那是宣讲会上自己说的，没有任何拆解或记录支撑。
读消息用整屏截图发 AI（差约 19 秒）、发出前做两道确认（差 17 秒）、逐字打字带防串窗保护（差约 7 秒）。影刀快，是因为它做的事更少，不是因为它引擎更好。
根本约束是一块屏幕、一次只能伺候一个人：负载一上来排队时间就线性涨。要进 70 秒必须做"想话术"和"发上一条"的流水线化，调参数拿不到。此外循环里 47.4% 花在整屏截图上、其中 85% 白读，这条能减少每轮开销，和流水线化互补。
它省下的三处里两处不能碰（校验和打字保护是拿事故换来的）。唯一能抄的是第三处思路：先用便宜的手段判断有没有变化，有变化才用贵的手段读。——这恰好就是上面那个最大杠杆。
同一个口径：从客户按下发送，到回复真的出现在他屏幕上。注意每一行的证据等级差别很大——只有第一行是实测。
■ 红＝实测 ■ 灰＝按机制推算 ▨ 斜纹＝厂商自称、无证据。行业公认的"黄金 5 分钟"＝300 秒，五行全部达标。
| 对象 | 速度 | 这个数怎么来的 | 证据 |
|---|---|---|---|
| 我们 · 企微 GUI | 81s 直测 86s 换算平均 |
08-10 红蓝对抗直接测全程；另查近两天 440 组真实对话，「干活」平均 36.4 秒，换算后 86 秒，与直测吻合 | 实测 |
| 影刀 RPA | ≈14s | 影刀官网、文档、社区全部零速度指标。按它的机制逐段推：教程默认每 10 秒看一眼＋直接填输入框发送 | 推算 |
| GUI Agent（AI 自己看屏操作） | ≈18s | UI-TARS-2 每轮 4.0 秒（量化后 2.5 秒），通用视觉模型每个动作 3~6 秒，一次回复要 3~5 个动作 | 学术实测 |
| 心动 AI | "秒级" | 34 页手册称"24h AI 智能客服"，专用 AI 手机 5,800 元/台。无拆解、无记录；同份材料还称"加微不封号"，与其余各家互斥 | 自称 |
| 鲲炬 AI | 未提 | 本机 RPA 占用真人电脑，屏幕常驻"AI 员工接管中"。真正的顶是平台规则：陌生人没回复只能发 1 条 | 推断 |
| 水流 | 分钟~小时 | 自认"暂不支持实时监测，采集靠手动点"——第一段直接交回给人 | 演示原话 |
| 亿销云 / 黑谷 / 亿量 | 不适用 | 亿销云 AI 只起草、默认不自动发；黑谷私信后要手动加微、内容要手动发布；亿量主动放弃抖音私信通道（怕封号） | 演示原话 |
前面那张图混着 API、硬件、GUI 三种路线。只挑 GUI 比才公平——因为我们就是 GUI。
市面上没有任何一家 GUI 方案公布过端到端回复速度。影刀零指标；wxauto 那类开源库的"性能基准测试"比的是吞吐量、内存、CPU，不含延迟；心动/鲲炬只有宣讲会上的"秒级"。全行业只有我们有一个真测出来的端到端数字。
所以下面这张表不是"谁快谁慢"的排名，是逐段对比各家的做法——因为所有 GUI 方案都是这四段，做法差异直接决定速度。
| 环节 | 我们 | 影刀 | wxauto 那类（读界面结构） | GUI Agent（AI 自己看屏） |
|---|---|---|---|---|
| ① 发现新消息 | 像素扫红点，单次 0.7 秒（很便宜） | 扫红点 → 点进对话 我们实跑验证，同机制 |
读界面列表，默认 1 秒轮询一次 | 截图交给模型判断，3~6 秒/次 |
| ② 读出消息内容 | 整屏截图发给 AI 认，约 20 秒 慢，但能判断"这句是谁说的" |
本机认字 / 找图，不到 1 秒 | 直接读界面文本，毫秒级 最快的做法 |
模型读图，秒级 |
| ③ AI 想话术 | 直连大模型，15 秒 | 官方 AI 组件 二手教程称"可能半分钟" |
看各自接的模型 | 模型自己决定，秒级/步 |
| ④ 打字并发出 | 逐字 8 秒 ＋ 两道确认 17 秒 全场做得最重的一家 |
整段直填，不到 1 秒 | 整段直填；社区有发送延迟超 3 秒的报告 | 模型逐步操作，3~6 秒/步 |
| 端到端实测 | 81 秒（红蓝对抗直测） | 无 | 无 | 每动作 3~6 秒，一次回复 3~5 个动作 → 约 18 秒 学术实测 |
一、我们不是"GUI 里最慢的"，是"GUI 里做得最重的"。②和④两段我们明显比同类慢，但都是主动选的：②用整屏截图是为了判断"这句话是谁说的"（读界面文本读不出来）；④那 17 秒确认拦的是发空消息和静默丢消息。
二、真正快一个数量级的是"直接读界面文本"那条路（毫秒 vs 20 秒）——但它在企微上走不通。2026-07-20 实测过四条结构化读取路径全部失效，微信/企业微信 4.0 之后界面内部结构被藏起来了。这也是影刀退回扫红点的原因。
三、唯一有第三方实测数字的 GUI 路线，比我们还慢。让 AI 全程看屏操作（GUI Agent）每个动作要 3~6 秒，一次回复约 18 秒——但那只是"干活"那一段，不含排队。我们同口径的"干活"是 39 秒。
九家竞品在公开互联网上几乎搜不到任何技术资料——逐家搜过，返回的全是不相干的通用 RPA 内容。同事那份一手材料（宣讲会逐字稿、演示录屏、产品手册）是唯一事实源。所以"竞品比我们快"这个印象，目前没有一条可验证的证据支撑。
先说两个词，全文都要用：「等发现」＝客户按下发送后，到我们的程序注意到有新消息为止（程序不是在闲着，是在忙别人的事还没转回来）；「干活」＝从注意到那刻起，到回复真的发出去为止。
这张图是 08-10 红蓝对抗直接测出来的（两台机器按剧本发问、另一台代回，全部取自机器日志）。我另外直查数据库量近两天 440 组真实对话，「干活」平均 36.4 秒、中位 32.4 秒，跟这里的 39 秒对得上。
核对 9 秒 ＋ 确认发出 8 秒 ＝ 17 秒，占「干活」的 44%，一个字都不产出内容。但它买的是"消息真的送出去了"——"接口返回成功不等于对方收到"是本仓拿事故换来的教训。下一节会看到，影刀之所以快，很大一部分就是它不做这 17 秒。
整屏截图占了循环时间的一半，而其中 85% 读完什么也没读出来。每次约 20 秒，这段时间另一个客户正在排队等着——所以它同时也是「等发现」那 45 秒的主要来源。
顺带推翻一个直觉：红点扫描一点都不贵（940 次只占 5.3%，单次 0.7 秒）。所以"把看一眼的频率调快"根本没用——已实测：从 95 秒调到 12 秒，全程纹丝不动。
纵向是「干活」的中位数。注意最后一行：08-11 的组数最少（99）反而最慢（35.3 秒）。
先说清楚这张图量的是什么。打个比方——咖啡店排队：
上面这张涨上去的图，量的是「做一杯的时间」（我们看见消息 → 回复真的发出），不是排队时间。它从 15.4 秒涨到 35.3 秒——是咖啡师本身变慢了。而"客户变多了"没法解释咖啡师为什么变慢。
反过来也验了一次：客户同时说话最多的时候，"做一杯"反而最快（11.3 秒，vs 独占时的 31.4 秒）。真要是排队渗进来了，方向应该反过来。
| 候选原因 | 结果 | 依据 |
|---|---|---|
| 客户变多、排队变长 | 已排除 | 逐条比对相关系数 -0.131，方向相反；近两天同时说话中位 2 个、"上一条没干完下一条就来"只占 0.2% |
| 08-11 凌晨窗口坏掉拉高均值 | 已排除 | 那两小时一条样本都没有——消息没真发出去就不产生"发完回报"，坏掉的时段自动被排除 |
| 备用识别模型被频繁触发 | 已排除 | 实际 24 小时才触发 2 次，主力模型质量没问题 |
| AI 回复变长了 | 已排除 | 字数中位 103 → 116，几乎没动；干活却涨 3.4 倍。相关系数 -0.295 |
| 召回通道抢占循环 | 已排除 | 日级相关系数 0.88 看着很像，但小时级只有 0.241——那是两个变量都随时间上涨造成的假相关。08-11 十点召回=0 却最慢，十五点召回=10 反而最快 |
| 流量挪到更慢的机器 | 已排除 | 数据里全是好友单聊、一条服务群会话都没有；而服务群/召回是夏伟那台的活。另：小顾那台日志显示正在压测隔离（只回白名单），不接真客户 |
| 循环整体变慢 | 已排除 | 同一台机器新旧日志对比：2.5MB 之前空转一轮 16~27 秒，今天只要 8~11 秒——循环反而变快了 |
| 读屏 + 想话术那一段 | 锁定，未拆开 | 见下 |
登上云电脑抓到完整的发送周期，逐步计时：
| 步骤 | 实测 | 判断 |
|---|---|---|
| 读屏 ＋ 想话术 | 21~25 秒 | ⬅️ 大头在这，还没拆开 |
| 点输入框 → 草稿确认 | 3~4 秒 | 正常 |
| 发送 → 确认真发出 | 6 秒 | 正常 |
| 写进数据库 | 1~2 秒 | 正常 |
实测原文（小顾，08-11 15:18）：click[输入框] 15:18:56 → 草稿确认 15:18:59 → 点发送 15:18:59 → 读回确认 15:19:05 → 已发送并落库 15:19:06，发送尾段只要 10 秒（夏伟那台 14 秒）。
而全天"干活"是 35 秒。也就是说 21~25 秒花在点输入框之前——在读屏和想话术那一段，不在发送这一段。这是这轮排查最实质的收窄。
| 问题 | 有没有解释 | 怎么办 |
|---|---|---|
| 排队变长 「等发现」那 42 秒 |
✅ 有：负载上来＋一块屏幕一次只能伺候一个人 | 流水线化（05 节第一条） |
| 干活变慢 2.3 倍 15.4s → 35.3s |
❌ 没有：七个候选排除六个，锁定在「读屏＋想话术」那 21~25 秒 | 抓一条真实客户回复的完整周期，把那 21~25 秒拆开 |
"都得查"的意思是：做完流水线化不等于这事就好了。就算排队被消掉，"干活"那 35 秒还在——而它五天前只要 15 秒，这 20 秒是白丢的。
一块屏幕一次只能伺候一个人。两路同时来时，第二路必须等第一路整整 39 秒的周期跑完——「等发现」那 42 秒基本就是这 39 秒的镜像。负载一上来，排队时间线性涨。
这意味着：要把全程压进 70 秒，必须做"想话术"和"发上一条"的流水线化，调参数拿不到。（已实测：把"多久看一眼"从 95 秒调到 12 秒，全程纹丝不动。）
| 环节 | 我们怎么干 | 影刀式怎么干 | 差 | 能不能照抄 |
|---|---|---|---|---|
| 判断有没有新消息 ＋读出内容 |
把整个聊天窗截图发给 AI 认一遍，约 20 秒／次，且 85% 白读 | 拿事先存好的小图去屏幕上比对，或在本机认字，不到 1 秒 | ≈19s | 思路能抄 但它读不出"这句话是谁说的" |
| 发出前的两道确认 | 粘完核对一遍 9 秒 ＋ 确认真发出去了 8 秒 | 不做，填完直接点发送 | 17s | 不能 拿事故换来的，已标"高风险·不建议动" |
| 把字打进输入框 | 逐字输入约 8 秒，每 8 个字回头看一眼窗口还在不在 | 一次性整段填入，不到 1 秒 | ≈7s | 不能 机队约定明写"改前先评估企微风控" |
| AI 想话术 | 直连大模型约 15 秒，支持边生成边往外吐字 | 官方教程自认"可能需要半分钟"，不支持边生成边吐 | 影刀更慢 | — |
影刀快的 43 秒里，有 24 秒是"它不做我们必须做的事"（校验 17 秒 ＋ 打字保护 7 秒），只有 19 秒是真正的做法差距。换句话说，就算换成影刀，能名正言顺拿回来的也只有那 19 秒——而那 19 秒不换工具也能拿。
影刀最核心的卖点是"直接认出屏幕上的输入框和按钮"。但微信/企业微信 4.0 之后换了自绘界面，界面的内部结构被藏起来了——查看工具只能看到最外层窗口。这意味着影刀在企微上大概率退回到和我们一样的截图比对，上表第一行那 19 秒的优势可能压根拿不到。
按"能省多少 ÷ 风险"排。第一条要动架构，剩下四条都不碰风险项、也不需要换任何工具。
| 可优化项 | 预计能省 | 风险 | 判断 |
|---|---|---|---|
| 「想话术」和「发上一条」流水线化 让屏幕在等大模型时别闲着 |
理论省 30~40% 唯一能进 70s 的路 | 中高 | ✅ 第一优先。根本约束是"一块屏幕一次只能伺候一个人"，负载一上来排队线性涨——这是架构问题，调参拿不到。改动面和回归风险都大，但绕不过去 |
| 读之前先判断值不值得读 311 次整屏截图只出 48 次稿 |
每轮开销降一半 | 低 | ✅ 并列第一。循环里 47.4% 花在这，85% 白读。和流水线化互补：一个缩短每轮时长、一个让多轮重叠。且换任何工具都替代不了 |
| 发完别再白读一次 那个红点是我们自己造成的 |
上一条的子集 | 低 | ✅ 做。两次尝试都因为改错位置没生效，约束已查清：那个位置拿不到会话名，下一版要换锚点 |
| 拆开「读屏＋想话术」那 21~25 秒 干活涨 2.3 倍的钱都在这 |
潜在 20 秒 | 低 | ✅ 做。08-11 登云电脑实测已把范围从"整个干活"收窄到这一段（发送尾段实测只要 10~14 秒，正常）。七个候选原因排除了六个。做法：挂个探针等下一条真实客户消息，抓完整周期日志 |
| 少做"搜索切回"和"点开不该点的会话" | 循环 9.4% | 低 | ✅ 做。红点检测修好后这两项本该减少，实测还在，值得单独看一眼 |
| 缩短 AI 输出长度 | 15s → 约 10s | 中 | ⚠️ 已验证长度与效果无关（相关系数 0.001），但客户扣分最狠的正是嫌不够细——只能砍废话，不能砍具体信息 |
| 确认发出改成抽检 | 8s → 约 2s | 高 | ❌ 不做。直接拿稳定性换速度，静默丢消息查都查不到 |
| 粘完不核对直接发 | 9s → 约 2s | 高 | ❌ 不做。粘贴没进去就点发送＝发空消息，这一步是唯一拦得住的地方 |
| 打字改成一次性粘贴 | 8s → 不到 1s | 高 | ❌ 不做。机队配置明写"改前先评估企微风控"，且会丢掉防串窗保护 |
| 把"多久看一眼"调快 | 0 | — | ❌ 已实测无效。从 95 秒调到 12 秒，全程纹丝不动——瓶颈不在这 |
现在库里没有客户消息的真实发送时刻，只有我们读到它的时刻，所以真实速度只能靠人工对抗测或换算估。补法很直接：读屏时把气泡上那个时间戳一并存进数据库（企微气泡自带时间，AI 本来就在看那块区域）。补完之后真实速度查一下数据库就有，能天天盯、能告警，不用每次撞见才发现变慢了。
| 考虑点 | 结论 |
|---|---|
| 速度 | 四段里只有"打字发送"更快，而那段快在不做该做的事。读消息那段在企微上大概率也退回截图比对，优势拿不到 |
| 能不能常驻 | 我们实际跑过，没撞到运行时长上限（此前流传的"社区版 30 分钟"出自二手博客，官方价格页并无此说法，已撤回）。官方页面确实写了的是：社区版没有「计划执行编排」和「触发设置运行」，定时/触发要创业版起。价格官方不公开，需询 |
| 现有积累能不能搬 | 不能。现在那 3,800 行里塞的是逐台标定的裁剪比例、身份校验、防自问自答、被抢焦点后夺回、生僻字昵称用内容定位、红点两种成因分流——这些在拖拽画布里表达不出来 |
| Claude 还能不能改 | 能驱动但是降级。影刀有官方 MCP 接口（官方开的口子，让别的程序调用它），Claude 可以列应用、触发运行，但只能跑"已经在影刀里画好且至少跑过一次"的流程——业务逻辑仍要人去画布上拖 |
| 还有个反向的坑 | 影刀的开放接口是发起任务后还得反复回来问"跑完没"。放在"秒级回复"场景里，等于在现有四段之外又多叠一层等待——本来就是要治等待，结果又加一层 |
也不推荐当主路径——但理由不是速度。纸面上它反而比我们快：干活约 18 秒，我们是 39 秒。不推荐的是另外四条。
| 问题 | 说明 |
|---|---|
| 那 18 秒我们拿不到 | 3~6 秒/动作是小模型跑在专业显卡上测的。我们云电脑是 2GB 内存、无显卡的 Windows 实例，每步都得走云端接口。而且它每一步都要截图判断——等于把我们现在那个 20 秒的整屏截图动作重复 3~5 次，实际只会更慢 |
| 它放大我们最痛的问题 | 我们踩过的坑——AI 把左右两边的人认反导致自问自答真发给客户、点开通知卡片弹出浏览器抢焦点、生僻字昵称把身份校验锁死——全是"让模型现场判断"造成的。GUI Agent 把这个判断面积扩大 3~5 倍 |
| 没法写死规则闸 | 我们现在能对每步写死判据（发送键按下后绝不重试、重打前必重过身份校验、打字分段回头看窗口）。这些闸挂得住，是因为每步的位置是确定的。GUI Agent 的动作由模型现场决定，没有稳定锚点 |
| 成本翻 3~5 倍 | 现在一轮回复烧 1 次读屏（约 9,180 次/天、$3.7/天/台，其中 96% 是白读）。GUI Agent 每轮 3~5 次 → $11~18/天/台 × 5 台 |
GUI Agent 唯一压倒性的优势是抗界面变化——不用标坐标、客户端升级也不失效。这恰好是我们的老痛点：坐标要逐台标定、裁剪比例每台不同、客户端一升级全废。
建议：别当主路径，当兜底。确定性路径正常跑；只在它失败时（坐标点空、连着读不出标题、红点检测不到）才让 agent 接管一次把这轮救回来，救完继续走确定性路径。
这样快路径仍然是确定性的（可挂闸、可复现、便宜），而界面一变不至于整台机器瘫掉——现在这种情况是要人去重标坐标的。
不换影刀，不复现它的工作流。换过去最好的结果是拿回 19 秒（还得赌它在企微上真能直接认出界面元素），代价是：Claude 从"能改任意一行逻辑"退化成"只能按启动键"、3,800 行教训重踩一遍、再花一笔年费。
而那 19 秒不换工具也能拿——就是 05 节第二条。
更要紧的是：影刀同样是"一块屏幕一次伺候一个人"，它也没有流水线。我们真正的天花板是架构，换个执行工具跨不过去。
| 等级 | 数据 | 来源与算法 |
|---|---|---|
| 最硬 | 「干活」36.4 秒平均 440 组对话（近两天） |
直查数据库，把每条客户消息和紧邻的 AI 回复配对算差值，窗口 08-10~08-11，只看企微。算法已对着服务端接口逐行核实：客户那行写于"读完屏幕"、AI 那行写于"云电脑回报发完"。脚本 scripts/probe-wecom-reply-latency.ts（PR #1298） |
| 最硬 | 81 秒全程 及其段级拆解 |
2026-08-10 企微红蓝对抗：两台机器按事先写好的客户剧本持续发问，另一台 AI 代回，指标全部取自机器日志。唯一直接测到"客户发出→回复发出"全程的数字，本页所有换算都以它定标。交叉验证：同日直查数据库量出 34.2 秒，对抗量出 39 秒，对得上 |
| 推算 | 全程 86 秒（换算） | 「等发现」库里测不出（缺客户真实发送时刻），按"等的时间和干活的时间绑在一起"、拿 08-10 当尺子换算（约 2.37 倍）。与红蓝对抗直测的 81 秒吻合，但只有一个校准点 |
| 已核验 | 「干活」涨 2.3 倍 与负载无关 |
三项核验：逐条比对「干活」与同时活跃会话数（r=-0.131，方向相反）、按天比对组数与「干活」（r=0.168，且 08-11 是反例）、近两天排队压力实测（同时说话中位 2 个、紧邻仅 0.2%）。脚本 scripts/_verify-load-hypothesis.ts |
| 机制推算 | 影刀 ≈14 秒 | 影刀官网、文档、社区全部零速度指标。按公开教程的机制逐段推：默认每 10 秒看一眼＋元素直填发送＋官方自认 AI 调用可能半分钟 |
| 仅供参考 | 九家竞品的速度 | 全部来自同事 08-10 那份一手材料（宣讲会逐字稿、演示录屏、产品手册）。这九家在公开互联网上几乎搜不到任何技术资料，我逐家搜过 |
| 已作废 | "08-08 那批重试改动导致变慢" | 早期版本据此推测过。实测备用识别模型 24 小时只触发 2 次，主力模型质量没问题，推测不成立，已撤回 |
| 已作废 | 本调研早期的"29 秒" | 当时把「等发现」误解成"程序每隔多久看一眼"，按配置估了 8.5 秒——两处都错：那段实际是排队、与看一眼的频率无关；且当时量到的 20 秒其实就是「干活」本身。基于错误模型给的三条提速建议同时作废 |
2026-08-11 重核了一遍：凡是只有二手博客支撑的，要么换成官方来源、要么撤回。下表逐条列出。
| 结论 | 凭据 | 等级 |
|---|---|---|
| 影刀不公布任何速度指标 | 官网首页、官方价格页、官方文档站入口三处都查过，都没有。官网只有"9 倍效率提升""100% 精确度"这类无法验证的宣传语 | 官方来源 |
| 影刀跑自动回复也是 扫红点 → 点进对话 → 回复 |
我们自己实际跑过。这条推翻了我早先"影刀没有消息监听能力、只能拿循环加等待"的说法（那个说法来自 CSDN 社区教程） | 自有实操 |
| MCP 接口只能跑 "已画好且至少跑过一次"的应用 |
影刀官方 MCP 仓库 README 原文："本地模式下，智能获取并运行'我获取的应用'并已经被至少执行过一次的应用"。开放 API 模式原文标注"仅支持企业用户" （早先引的是第三方目录站，本次已换成官方仓库核实） |
官方来源 |
| 社区版没有定时/触发运行 | 官方价格页功能矩阵：「计划执行编排」「触发设置运行」两项，社区版为空、创业版起才有 | 官方来源 |
| 价格 | 官方不公开报价，价格页只有功能矩阵。此前引用的"创业版 2,500 元/年、企业版 59,800 元/年"来自二手博客，已降级为不可引用 | 无官方依据 |
| 社区版 30 分钟运行上限 | ❌ 已撤回。来源是火山引擎开发者社区一篇二手对比文；官方价格页无此说法，且我们实际跑过没撞到上限 | 已推翻 |
| "AI 调用可能需要半分钟" | 火山引擎开发者社区教程原话，二手来源，未在官方文档中找到对应说明。仅作参考，不作为结论依据 | 二手 |
搜索结果里大量"平均延迟小于 800 毫秒""效率提升 2000%""客户满意度提升 45%"，普遍无来源、无对照组。典型例子：某篇标题喊"秒级响应"的影刀客服方案文，正文实际写的是 sleep(10) 每 10 秒看一眼＋关键词数组匹配，连 AI 都没真调。