92 次请求烧掉 1340 万 token:慢的不是 AI,是我的验收流程

yanbao 产线跑一份研报花了 60 分钟、1340 万 token,钱到底烧在哪?实测取数后结论很清楚:不慢在检索也不慢在内容体积,慢在 P5 验收环节的碎验碎调。主会话 92 次请求里约 40 次是验收试错,缓存读占了 94%,真正的主凶是固定上下文乘以请求次数。

先交代一下我在干什么。yanbao 是我自研的研报产线技能,一条 AI 流水线:多路并行检索、后台组装、验收硬闸,全流程自动跑出一份决策研报,P0 到 P6 是它的工序编号,P5 是验收工序。

研报 54 分钟交付,我却高兴不起来

那天上午 09:11 开工,任务只有一个:用 yanbao 产线调研"2026 年配置智能体的系统性方案",出一份内部决策研报。

10:05,研报交付,P0 到 P6 全流程走完,验收硬闸全过。按说这是漂亮的一仗。但我自己心里有数,整个过程磕磕绊绊,于是我问了自己一句后来写进复盘开头的话:

"研报,这个速度,很慢,你看看刚才用了多少 token?用了多少时间?"

这一问,问出了一次完整的产线体检。

先取数,再开方案会

以前我也干过凭体感优化的事,这次忍住了。我先把会话的 wire.jsonl(每次 LLM 请求的完整日志)拉出来逐条统计,口径是全量:完整输入含缓存读,再加输出。

数字摆出来是这样的:

两个发现直接改了我后面的所有决策。

第一,快的环节其实不慢:5 路并行检索只花 7 分钟,后台组装 12 分钟。慢的全在 P5 验收,一个工序吃了约 30 分钟,占了一半时间。

第二,缓存读占 94%。也就是说,token 大头不是研报内容本身的体积,而是同一份固定上下文被反复发送:92 次请求里,约 40 次是 P5 的碎验碎调。每多一次验收试错,就把整份上下文重新买一遍单。

体感会说"研报太大了",数据说的是"请求次数太多了"。这是两回事,解法也是两回事。

坑 1:8 秒的脚本,被压在 30 分钟的 MCP 马拉松下面

P5 那 30 分钟是怎么烧掉的?拆开看,一半是环境问题。

验收环节的主路走的是 playwright MCP。结果它拦 file:// 协议,页面打不开,我临时起了一个 HTTP 服务绕行;接着移动端检出横向滚动,viewport 仿真又卡死,只能切兜底脚本重建环境。根因排查前后走了五六轮二分,时间就没了。

最打脸的是:产线里一直躺着兜底脚本 yanbao_verify.js,实测 8 秒能跑完全部硬闸。主备路线整个是颠倒的,快工具当备胎,慢工具当主力。

修复很直接:P5 整节重写,脚本升主路,MCP 降为调试手段,并且立了一条死线:

单点故障排查超 10 分钟,无条件转脚本。

这条死线比任何工具选型都值钱。排查是个无底洞,不给它封顶,它就敢吃掉半个钟头。

坑 2:我以为表格溢出,真凶是一串长英文

移动端验收报横向滚动:390px 宽度下,document 的 scrollWidth 到了 598。

我第一反应是表格问题,border-collapse、overflow 相关的方案试了三种,全部无效。理论绕圈又烧了约 15 分钟。

后来换了个笨办法:递归找 scrollW 大于 clientW 的最深元素,一层层往下钻,真凶浮出来了——长英文 token:一串 ≥20 字符、没有空格的连续字符串,浏览器断不了词,直接把段落顶破。

修复就一行 CSS:

.prose p, .prose li, .prose td { overflow-wrap: break-word; }

但我没有停在修 bug。"递归定位肇事元素"这个排查动作被脚本化,写进了新版验收脚本:以后再遇横向溢出,脚本直接报出元凶链,人不用二分。这类排查永久结束。

坑 3 和坑 4:两次试错才想起先逆向,一次超时白等 8 分钟

同一天的另外两笔学费,金额小一点,但教训通用。

给爬虫岗新建工作区后,无头派单报错:"folder is not trusted"。信任文件名有一套哈希规则,我手工建了两次都错:一次是目录名带了前导点,一次是哈希输入格式不对。第三次我停下来,拿一个已知能用的样例反推规则,一次通过。

先逆向规则再动手,比试错快。 这句话值两次失败。

另一笔是干等:后台组装实际跑了 727 秒,我的等待超时设的是 600 秒,超时返回后任务还在跑,白等 8 分钟才发现。现在的规矩是后台组装等待超时 ≥900 秒,宁可多等,不能误判。

修复清单:四杠杆全落地,每条带回验证

诊断出的四条根因(验收主备颠倒、模板缺 overflow-wrap、素材双次过境、等待空转)对应四条措施,外加一条环境治理。我当时拍了板:

"我觉得 1234 都执行,M5 不要研判评估了,能按需加载肯定按需加载。"

落地的东西有三件半。

一是模板三修:overflow-wrap 防溢出、内联 favicon、图表库本地化(本地资源默认,CDN 只做兜底)。

二是新版 yanbao_verify.js 一站式验收脚本:11 项硬闸一次跑完,含横向溢出自动定位。验证方式是双向自证:好目录 10 项全 PASS,8 秒;喂一个坏页面,正确 FAIL 并指出肇事段落。

三是产线规则五处修订,核心是新增的效率预算条款:

全流程 ≤25 分钟;主会话请求 ≤40 次;全量 token ≤4M。超标必归因。

以后每次跑产线,这三个数就是体检表,超标必须写出归因,不许含糊过去。

剩下半件是 MCP 环境治理。我发现 playwright、chrome-devtools、context7 三个 MCP 写在用户级配置里,对每一个会话生效,连空目录的闲聊会话都常驻三份工具 schema,白吃上下文。发现这个问题是因为我追问了一句:"这 3 个 MCP 怎么加载到军师侧来了?"答案就是配置作用域写错了层级。现在用户级配置已清空(留了双备份),三件套收编到爬虫岗的专属工作区,按需加载。改完也没裸奔:跑了完整探针验证,57 个 MCP 工具清单逐个核对,确认这三个只出现在爬虫岗工作区;配置登记册同步落账,配置检查零红灯。

这套体检方法,你的产线也能用

我不是大厂 SRE,就是一个给自己产线算账的人。但这四样东西,谁用 AI 干活谁都能搬走:

• 效率预算三指标:给你的流程立"时间/请求数/token"三条红线,超标必归因;
• 10 分钟排查死线:单点故障超时无条件转兜底方案,排查不封顶就是烧钱;
• 会话日志统计法:别信体感,把每次请求的输入输出拉出来算,主凶往往是请求次数不是内容体积;
• 快工具当主路:兜底脚本 8 秒能干完的活,别让重工具跑马拉松。

对企业读者多说一句。如果你的团队在用 AI 智能体跑重复性流程,这套账可以直接搬进 CI 思路:一次验收从约 30 分钟人工排错压到 8 秒脚本,按每天 10 次验收算,一天省回约 5 个小时的人工排查,一个月就是一百个小时量级;再给流程立请求数预算,token 成本从"月底看账单吓一跳"变成"每次跑完当场归因"。效率治理不需要立项,一张预算表加一条死线就能起步。

再说一个我自己的改进。这次效率问题是我主动追问才摆上桌面的,如果交付摘要里本来就带着"60 分钟/92 请求/1340 万 token",优化会早一轮发生。现在这条已写进规则:重任务交付摘要默认附效率实测值。

还有两件没收尾:另一个客户端的双轨配置还没动;新流程还欠一篇快报模式研报的实测回测,跑完我来回填数据。

FAQ

Q:1340 万 token 是不是说明 AI 产线不划算?

不是。这次的问题是流程设计问题,不是产线路线问题。缓存读占 94% 恰恰说明大头是重复的固定上下文,把验收主备颠倒、等待空转这些毛病修掉,同样的研报成本会跟着验收次数一起降下来,具体降多少,等新流程回测数据出来我再报。

Q:wire.jsonl 统计法具体怎么操作?

思路层可以说透:每次 LLM 请求都会在会话日志里留下完整记录,按请求逐条累加输入(含缓存读)和输出,再按工序归类。关键是口径要选全量:只看非缓存输入会严重低估真实消耗,缓存读照样计入 token 消耗。

Q:效率预算三指标可以直接抄吗?

数值是按我这条产线的体量定的(≤25 分钟/≤40 请求/≤4M),你的流程复杂度不同,数值要自己校准。可以抄的是方法:先实测几次拿基线,再把红线设在基线的舒适区边缘,超标必归因。

Q:MCP 到底要不要装?

工具本身没问题,问题在装在哪。写进用户级配置就对所有会话生效,不用它的会话也背着 schema 开销。按需加载,哪个岗位用,就装进哪个岗位的工作区。

我是野生码农,AI实战派。17年全栈工程师,一人AI公司实践者。打造个人IP内容体系、软件全链路产品产线,拥有百套企业AI方案、200多个岗位Agent;自研知识库、AI数字员工系统,公开实战复盘。

本文所有内容均为本人 AI 实战的过程和结果,经 AI 整理后发布,无任何瞎编虚构内容。

这篇来自《AI员工团队》系列。下一篇拆"370 篇工作日志喂进本地知识库"的实战:日志怎么清洗、怎么切块、检索效果实测。每月月底还有 AI 员工团队月报,真实数据全公开。

关注我,看真的。

野生码农AI实战 · 全网同名