1. 92 次请求烧掉 1340 万 token 这件事问题到底出在哪先把标题里的数字拆开看92 次请求1340 万 token平均下来单次请求接近 14.6 万 token。这个量级放在任何一家大模型 API 的账单页面上都足够让人盯着屏幕愣几秒。更扎心的是括号里那串加法——91 251415128854这不是什么数学游戏而是我事后复盘时把 91 次有效请求按用途拆出来的分布25 次是真正在干活的生成请求剩下 66 次全是验收、重试、上下文回灌、状态确认这类流程性开销。换句话说钱不是被 AI 烧掉的是被我自己的验收流程烧掉的。这个结论听起来有点反直觉。大多数人第一反应是模型太贵了或者token 用超了于是去调 prompt、换便宜模型、加缓存。但如果你的请求里有七成以上是在做重复的上下文搬运和状态校验那换什么模型都是治标。真正该动刀的地方是那套生成一次、验收八次、回灌五次的工作流本身。这篇东西适合两类人看一类是正在用 AI Agent 或者 MCP 工具链做自动化、已经开始被 token 账单教育的人另一类是刚接触 Playwright、MCP、CI 这套组合拳还没意识到流程设计比模型选型更影响成本的人。我会把这次 1340 万 token 的完整拆解过程、每一类请求为什么会产生、以及我最后怎么把单次任务成本压下来的实操细节都摊开讲。不讲虚的全是账单上能对得上的东西。先给一个全局的判断token 消耗的大头从来不在生成环节而在上下文管理环节。你每多一次把之前的结果重新塞回模型让它确认就多一次全量上下文的计费。92 次请求里那 66 次流程性开销本质上都是上下文在反复横跳。2. 把 91 次请求按用途拆开251415128854 分别是什么复盘的第一步不是看账单总额而是把每一次请求的用途打上标签。我当时的做法是从日志里导出所有请求的 metadata按这次请求的目的是什么手动归类最后归出了 8 类。这个分类过程本身就是一次认知冲击——我以为自己在用 AI 干活实际上大部分时间在伺候 AI 的状态。2.1 25 次生成请求真正产生价值的部分这 25 次是实打实让模型输出内容的请求包括代码生成、文案撰写、结构化数据抽取。它们的共同特征是输入上下文相对干净输出直接进入下一步使用不需要二次确认。这部分的 token 占比其实只有三成左右但因为每次都是全量上下文单次成本并不低。这里有个容易被忽略的点生成请求的 token 成本 输入上下文 输出内容。很多人只盯着输出长度优化却忘了输入上下文才是大头。一次生成请求如果塞了 8 万 token 的历史对话哪怕只输出 500 token账单也是按 8 万多算的。2.2 14 次验收请求让模型自己检查自己这 14 次是我最初设计流程时最得意的一环——让模型生成完再自己 review 一遍。听起来很严谨对吧实际结果是灾难。因为验收请求必须把原始需求 生成结果 验收标准全部塞进去上下文比生成请求还长。而且模型自检的准确率并不高经常出现它说没问题但实际有问题或者它说有问题但其实没问题的情况于是又触发了下一类请求。2.3 15 次重试请求因为验收不通过而重来验收说有问题那就重试。重试的代价是不仅要重新生成还要把上次为什么失败的说明也塞进上下文。于是每次重试的输入都比上一次更长。15 次重试里有 9 次是因为验收误报6 次是真有问题。也就是说超过一半的重试成本是被自己的验收流程误伤出来的。2.4 12 次上下文回灌把历史结果重新喂回去这是最隐蔽的成本黑洞。当任务需要多步骤协作时每一步的结果都要作为下一步的输入。如果流程设计得不好就会出现把前面所有步骤的完整输出都塞进当前请求的情况。12 次回灌请求平均每次输入上下文超过 10 万 token光这一项就吃掉了接近 400 万 token。2.5 8854状态确认、格式修复、工具调用、异常兜底剩下的四类分别是8 次状态确认问模型你刚才那步做完了吗、8 次格式修复输出 JSON 解析失败后让模型重新格式化、5 次工具调用MCP 工具链的中间请求、4 次异常兜底报错后让模型解释错误并给方案。这四类加起来 25 次单次 token 不算特别高但架不住次数多累计也贡献了约 200 万 token。把这 8 类放在一张表里对比问题一目了然请求类型次数平均单次 token累计 token约是否产生直接价值生成2512 万300 万是验收1415 万210 万否且误报率高重试1516 万240 万部分上下文回灌1211 万132 万否状态确认86 万48 万否格式修复85 万40 万否工具调用58 万40 万部分异常兜底47 万28 万否真正产生直接价值的生成请求只占 token 总量的两成多剩下七成多全花在让流程跑通上。这就是 1340 万 token 的真相。3. 验收流程为什么会变成 token 黑洞拆完分类下一个问题是为什么验收环节会膨胀成这样我后来想明白了根源在于我把人类验收的思维直接搬到了 AI 流程里但两者的成本结构完全不同。3.1 人类验收是看一眼AI 验收是重读一遍人验收一份文档是拿着结果对照标准扫一遍成本几乎为零。但 AI 验收必须把标准 结果 背景全部作为输入重新过一遍模型成本等于重新处理一次完整上下文。我最初设计流程时完全没意识到这个差异天真地以为让 AI 检查一下是顺手的事结果每次检查都是一次全量计费。更麻烦的是AI 验收的可靠性远不如人类。人类看到明显错误会直接指出AI 则倾向于礼貌地认为大体没问题或者反过来过度挑剔地找出一些无关紧要的格式问题。这直接导致了 2.3 节里说的重试误伤。3.2 验收标准越详细上下文越长成本越高我一开始为了让验收更准确把验收标准写得非常细列了二十多条检查项。结果每次验收请求的输入上下文直接翻倍。而且标准越细模型越容易在细枝末节上纠结触发更多格式修复和重试。这里有个反直觉的经验验收标准的详细程度和验收成本是超线性关系。标准从 5 条加到 20 条token 成本可能涨 3 倍但验收准确率的提升可能只有 10%。边际收益极低。3.3 验收和生成共用上下文等于把成本乘了两次最致命的设计失误是我让验收请求复用了生成请求的完整上下文。这意味着同一份 10 万 token 的上下文被计费了两次——一次在生成时一次在验收时。如果再加上重试同一份上下文可能被计费三四次。正确的做法应该是验收只传结果 精简后的标准而不是把整个生成过程的历史都带上。但当时我没做上下文裁剪图省事直接全量传递成本就这么滚起来了。提示验收环节的上下文一定要做裁剪。生成过程的历史对话、中间思考、被否决的方案这些对验收毫无价值全部剔除。只保留最终结果和验收标准本身。4. 上下文回灌那个吃掉 400 万 token 的隐形杀手如果说验收是明面上的浪费那上下文回灌就是暗地里的黑洞。它不显眼因为每次回灌看起来都有必要但累计起来是单类请求里 token 消耗最高的。4.1 什么是上下文回灌为什么它会失控上下文回灌指的是多步骤任务中把前面步骤的输出作为后面步骤的输入重新传给模型。比如第一步生成大纲第二步根据大纲写正文第三步根据正文做摘要——每一步都要把前一步的结果塞进去。失控的原因在于累积效应。第一步输出 2 万 token第二步输入就是 2 万 自己的输出第三步输入又叠加前两步。如果步骤多、每步输出长上下文会像滚雪球一样膨胀。我那 12 次回灌请求平均输入超过 10 万 token就是因为步骤间没有做任何压缩。4.2 全量回灌 vs 摘要回灌成本差 5 倍后来我做了个对比实验同样的多步骤任务一种方式是全量回灌每步都传完整历史另一种是摘要回灌每步只传上一步的精简摘要。结果全量回灌的总 token 是摘要回灌的 5 倍多而最终输出质量几乎没有差别。原因很简单模型在后续步骤里真正需要的是前面步骤的结论和关键约束而不是完整的推理过程。把 2 万 token 的详细输出压缩成 2000 token 的摘要信息损失很小但成本直接砍掉九成。4.3 用结构化中间产物替代自然语言回灌比摘要更进一步的做法是让每一步输出结构化的中间产物比如 JSON只保留后续步骤真正需要的字段。自然语言输出里大量是解释性、过渡性的内容对后续步骤毫无用处。改成结构化输出后回灌的 token 量能再降一个数量级。我现在的习惯是凡是多步骤任务第一步就定义好中间产物的 schema每一步只输出 schema 要求的字段回灌时也只传这些字段。这样上下文永远不会失控。5. 把单次任务成本压下来的四个实操动作讲完问题该讲怎么改了。我最后把单次任务的 token 成本从平均 14.6 万压到了 3 万左右靠的是四个动作按性价比排序。5.1 砍掉 AI 自检改用确定性校验第一个动作最狠也最有效把 14 次验收请求全部删掉改用确定性校验。什么叫确定性校验就是用代码而不是模型来判断结果是否合格。比如输出要求是 JSON那就用 JSON parser 校验要求包含特定字段就用代码检查字段是否存在要求长度在范围内就直接算长度。这些校验零 token 成本而且准确率 100%。只有那些真正需要语义判断的验收比如这段文案语气是否合适才交给模型而且要用精简上下文。5.2 给每次请求的上下文设硬上限第二个动作是给上下文设硬上限。我定了个规矩任何单次请求的输入上下文不超过 3 万 token。超过就强制裁剪优先保留最近的、最相关的部分历史内容只保留摘要。这个上限逼着我重新思考哪些信息是真正必要的。结果是发现大量上下文其实是以防万一塞进去的实际用不到。设了上限之后反而倒逼出了更精准的上下文管理。5.3 重试前先做根因判断别盲目重来第三个动作是改重试逻辑。以前是验收不通过就重试现在是验收不通过先判断原因如果是格式问题用代码修复不重试如果是内容缺失只补缺失部分不重新生成全部只有确实是生成质量问题才重试而且重试时只传失败原因和原始需求不传上次的完整输出。这一改重试次数从 15 次降到 4 次而且每次重试的上下文也短了很多。5.4 用 MCP 工具链把状态管理从模型里挪出来第四个动作涉及工具链设计。我原来把状态确认这类活儿也交给模型问它上一步做完了吗。后来改用 MCP 工具链把状态管理交给工具本身——工具执行成功就返回成功失败就返回错误码根本不需要模型来确认。MCP 在这里的价值不是让 AI 更强而是让 AI 少管闲事。凡是确定性的事情都交给工具模型只负责真正需要语义理解的部分。这一条把 8 次状态确认请求直接清零。6. Playwright 和 CI 场景下这套成本控制怎么落地前面讲的是通用原则但这次任务的实际场景是 Playwright 自动化测试配合 CI 流程有些细节值得单独说。6.1 Playwright 测试用例生成别让模型看完整页面用 AI 生成 Playwright 测试用例时最容易犯的错是把整个页面的 DOM 或者完整截图塞给模型。一个复杂页面的 DOM 动辄几万 token而且大部分是无关的样式和脚本。我的做法是先用 Playwright 的 locator 能力提取出可交互元素清单——按钮、输入框、链接只把这些元素的 selector 和文本传给模型。这样上下文能压缩到原来的十分之一生成的测试用例质量反而更高因为模型不会被无关信息干扰。6.2 CI 里的 token 预算给每次流水线设上限在 CI 里跑 AI 任务最大的风险是失控。一次流水线触发几十次请求如果没预算控制很容易烧出天价。我的做法是在 CI 配置里给 AI 任务设 token 预算上限超过就中断并报警。具体实现是在调用模型 API 的封装层里加计数器每次请求前检查累计用量超过阈值直接抛异常。这个封装层还负责记录每次请求的用途标签方便事后复盘——就是第 2 节那张表的来源。6.3 把验收逻辑写进 CI 脚本而不是 promptCI 场景下验收逻辑应该写在脚本里而不是塞进 prompt 让模型判断。比如测试用例生成后用脚本检查是否包含必要的断言、selector 是否有效、是否有语法错误。这些检查用代码做又快又准完全不需要模型参与。只有这个测试用例是否覆盖了业务场景这种语义判断才值得用模型而且要用精简上下文。7. 几个我踩过之后才明白的坑最后分享几个具体的坑都是账单上真金白银换来的。第一个坑别用对话历史模式跑批处理任务。对话历史模式会把每一轮的内容都累积到上下文里跑几十轮下来上下文爆炸。批处理任务应该用无状态模式每次请求独立构造上下文需要历史信息就显式传入精简版。第二个坑输出格式约束要前置不要事后修复。我原来经常遇到模型输出 JSON 解析失败然后触发格式修复请求。后来在 prompt 里用严格的 schema 约束并且在 API 层开启结构化输出如果模型支持格式修复请求直接归零。第三个坑重试要有次数上限和退避策略。无限重试是 token 杀手。我现在的规矩是单个任务最多重试 2 次且第二次重试前必须换策略比如换 prompt 模板或换模型不能原样重来。第四个坑监控要按用途而不是按模型聚合。按模型看用量只能告诉你哪个模型贵按用途看才能告诉你钱花在哪件事上。后者才是优化的依据。第五个坑别迷信让 AI 自己规划。我试过让模型自己决定下一步做什么结果它规划出的流程里塞满了冗余的确认步骤。流程规划这种事还是人来定更省 token。这套东西跑顺之后我现在做同类任务92 次请求能压到 30 次以内token 从 1340 万降到 200 万出头。省下来的不只是钱还有排查问题的时间——因为流程简单了出问题时一眼就能看出是哪一步的锅。