做AI应用的人都知道跑通一个带工具调用的Agent工作流token账单能飙到多夸张。我维护的这个项目上线第一个月就被LLM调用费用吓到——不是模型单价贵而是工作流设计得太粗糙上下文越滚越长、同一个工具被反复调用、为了一个简单的判断也要把完整历史全塞进模型。后来我们团队把所有Agent逻辑收归到Harness工作流里统一编排把原来“模型自己想干嘛就干嘛”的方式改成了“流程节点说了算、模型只干活”的方式token用量直接砍掉一半。这篇文章就把我们这次成本优化的完整思路、关键策略和踩坑记录整理出来希望能给正在被token账单折磨的朋友一些可复用的经验。先说清楚一个前提Harness工作流并不是某一个特定的商业产品而是我一直在用的一套AI Agent编排范式——用显式的工作流定义来控制模型的调用时机、上下文内容、路由策略和缓存策略。无论是开源的Harness框架实现还是自研的轻量级管线核心思路都一样把决策权从模型手上拿回来放到可配置、可观测、可审计的流程里。这样做最大的好处就是token花在哪里、为什么花、能不能不花一眼就能看明白。1. 为什么你的Token账单总在失控1.1 先搞明白Token都花在了哪很多人以为token消耗等于“提问次数乘以平均长度”实际远没有那么简单。一次业务请求的token总消耗通常由这几部分构成系统Prompt、用户输入、工具调用返回的结果、多轮历史对话、模型输出以及框架偷偷追加的各种格式指令。我统计过当时客服助手一个月的账单明细真正对业务有价值的输出token只占14%剩下全是在来回搬运历史对话和重复扫描工具返回的JSON结构。换句话说你付的每一块钱可能只有一毛四在“思考”其他都是搬运工钱。更糟的是搬运工钱的占比会随着对话轮数上升而指数级上升——因为每多一轮前面的历史几乎都要原样再付一遍。这就是为什么单看一次调用觉得便宜月底一拉账单就傻眼。1.2 三类最常见的浪费场景第一类是上下文无限膨胀。默认情况下Agent会把从第一句话开始的所有对话原封不动地留着遇到工具调用还把返回值整个追加上去。用户问一句“我的订单怎么了”系统把上周聊的七轮内容、三个大JSON查询结果全部带上模型被迫在一堆无关数据里大海捞针。第二类是重复计算无副作用的结果。同一个查询用户刷新一下就再跑一次工具调用上一次的返回其实完全没变但这笔钱已经是第二次付了。第三类是模型选型一刀切。不管任务是“算个加减法”还是“写一份法律意见书”都调用同一个昂贵的大参数模型等于用卡车搬快递成本自然降不下来。这三种浪费叠加才是token账单失控的真正原因。要优化就不能只靠“写Prompt省钱”这种修修补补必须从工作流的整体结构上去做约束。2. Harness工作流从“自由对话”到“受控流水线”2.1 Harness到底是个什么概念Harness这个词在AI Agent领域里我习惯把它理解成“马的挽具”——用来控制方向、传递力量的那套装备。套上挽具的马依然在跑但往哪跑、跑多快由驾车的人决定。Harness工作流就是这个驾车的结构它把一次复杂任务拆解成一系列受控节点节点之间有明确的数据传递和条件分支模型只在它该出现的位置出现做它最擅长的那一块。它和我们常说的裸Agent直接把工具列表交给模型让模型自行决定调用什么最大的区别在于控制权的归属。裸Agent是模型在自主驾驶Harness是开发者在流程图上画出轨道模型只是轨道上某个工位里的机械臂。这听起来好像限制了模型的自由度但对成本管控来说自由度恰恰是账单失控的根源——你不可能让一个不了解你预算的“司机”在路上随意踩油门。2.2 Harness工作流的四个核心能力第一个是上下文窗口管理。你可以在流程的任何节点指定输入上下文的来源和范围比如“只取当前消息和订单摘要结果”而不是默认全量历史。第二个是节点级缓存。每个节点的输入和输出都能配置一个缓存策略命中缓存就直接跳过模型调用完全不消耗token。第三个是条件路由。流程可以根据意图分类、内容长度、任务复杂度等信号走不同的分支比如简单的查询走轻量模型复杂推理走重模型。第四个是可观测性和成本审计。所有节点都能记录Token消耗明细一个请求花在哪个节点、多少输入多少输出全部可视化而不是黑盒。这四个能力单独拿出来都不是新东西但组合在一个受控工作流里才可能实现系统性的降本。下面我就按实际落地顺序把让我们实现50%降本的那五个关键策略逐一展开。3. 降本50%的五个关键策略3.1 上下文压缩让模型只看该看的上下文长度和token成本之间几乎是线性关系所以第一刀要砍在上下文上。我的做法是在每个模型调用节点前插入一个“上下文构建器”它不是简单截断而是根据当前节点的任务目标对历史信息做结构化摘录。比如用户问“我的订单为什么还没到”上下文构建器会从历史里提取出“订单号、下单时间、物流状态、上次客服已答复内容”这几个字段拼成一个紧凑的JSON而不是把之前三大段聊天记录原样推送。这里的关键是定义“摘录模板”。我一开始用固定字段但很快发现不同场景需要保留的信息不一样。后来改成两段式先让一个便宜的轻量模型对历史对话做摘要提取关键业务实体和未解决问题再把摘要作为后续上下文的输入。实测下来平均上下文长度能从3000 tokens压到400左右而且回答质量没有下降因为模型拿到的是信息密度更高的浓缩内容而不是一堆噪声。3.2 结果缓存同样的活儿不干两遍很多工具调用是纯查询、无副作用比如查天气、查订单状态、查商品库存。这类结果在一段时间内是稳定的完全没有必要每次都调LLM去“理解”并“决策”最后再调工具重复取数。我在Harness工作流里给每个有幂等性的节点加了redis缓存key由“节点ID参数摘要”组成value是工具返回结果和模型输出。生效的维度从几秒钟到几小时不等取决于业务对时效的要求。缓存带来的收益非常直观。客服场景里用户经常换个措辞问同一个问题或者刷新页面后再问一遍命中缓存后整条工作流在第二个节点就短路返回模型调用次数直接下降三成。但这里也有个陷阱缓存粒度太粗会把不同用户的敏感数据串出去。所以我的缓存key里必须包含会话ID或用户ID参数摘要用哈希确保用户A查不到用户B的结果。3.3 模型分级路由能省则省能强则强不同任务的复杂度差异很大一个“订单是不是已发货”的判断和一个“帮我分析这份合同有什么风险”的任务需要的模型能力完全不同。我的做法是在意图识别完成后设置一个复杂度评估分支规则很朴素如果任务只需要从已提取的结构化字段中做布尔判断或直接查询就走轻量模型如果需要进行多步推理、总结归纳或生成长文才走大参数模型。Harness工作流里做这个路由很简单每个节点可以配置一个model字段并在流程图中用条件边连接。运行时会根据上一个节点输出的complexity_score字段把请求导向不同的下游模型节点。我测试过一轮大约62%的客服请求可以被路由到廉价模型这部分请求的数量没变但token成本只是原来的八分之一。3.4 串行改并行合并循环调用当工作流里有多个独立的工具查询时很多初版设计会用链式串行查订单信息 - 拿订单里的商品ID - 查商品详情 - 拿商品里的供应商ID - 查物流信息。每一步都要带着越来越长的上下文调用一次模型而且每一步都在等上一步完成。实际这些查询之间并没有依赖关系完全可以在一个节点里用并行fork同时发起最后汇总结果。在Harness里我把这种“查完A再查B”的链式结构改成了“并行查询节点”同时在Prompt里明确告诉模型“以下多个工具可以同时调用并在全部结果返回后统一汇总。”这一改动不仅把响应延迟从8秒降到2秒更重要的是省去了中间多次模型的重复“决策”和上下文携带。另外我统计过循环调用中有一半以上是重复GET请求用前面说的缓存直接消化掉循环体从平均4轮降到1.5轮。3.5 Prompt瘦身每一条格式文本都是钱系统Prompt往往一卷一大段这个也被很多人忽略。我见过一份系统Prompt写了两千多字里面除了职责说明还有大量示例、格式XML Schema、公司历史、价值观宣言。每次调用都要把这坨大文本原样送进去长对话场景下还要反复送。我的原则是能不放Prompt就不放不能不放就压缩。具体操作把固定不变的规则编译成内部数据结构的schema只有一小段关键指令真正以文本形式存在把容易变化的示例从Prompt里移到检索库里需要时按命中结果动态插入将格式要求从XML改成紧凑的JSON schema描述。这一番清理固定token开销从平均850降到了240。这里要特别注意Prompt瘦身不能牺牲可解释性所以我把关键约束留在文本里保证任何一次模型输出即使格式出错了也能在流程里看出来是哪一步违反了什么要求。4. 实操在Harness里落地一个优化的客服工作流4.1 搭建基础流程为了更容易复现我直接用YAML描述了核心工作流的结构本质上就是三个阶段的串联意图识别与任务拆解 - 上下文构建与工具调用 - 结果生成与回复。下面是一个简化后的配置片段去掉了密钥和敏感信息workflow: id: customer_service_v2 start: intent_router nodes: intent_router: type: llm model: cheap-model prompt: | 判断用户意图输出JSON {intent: order_query|product_query|after_sale|other} output: intent_result classify: type: condition switch: - when: intent_result.intent order_query goto: context_builder - when: intent_result.intent product_query goto: parallel_product_query - default: goto: handoff_agent context_builder: type: tool tool: summarize_history params: history: $conversation_history max_length: 400 output: compact_context order_query: type: tool tool: get_order_detail cache: 300 params: order_id: $extract_order_id output: order_detail generate_reply: type: llm model: best-model input: [compact_context, order_detail] output: reply_text这个流程里意图路由器只用便宜模型处理很短的一段文本后续真正生成回复的节点才调用昂贵模型而且它拿到的上下文是经过压缩器处理过的不再是全量历史。工作流引擎会按这个声明自动管理依赖关系和缓存配置开发者不需要在每个节点里手写token计算逻辑。4.2 配置上下文压缩和缓存我在生成回复节点之前专门加了一个“上下文构建器”节点它并不是一个模型调用而是一段代码逻辑从状态机里取出当前会话的原始历史按预定义字段提取订单ID、用户ID、最近一次客服答复、用户情绪指标再拼成紧凑的JSON。这个构建器的输出成为下游模型节点的唯一输入来源。缓存配置则是按节点类型走的。get_order_detail这类只读查询节点我设置了五分钟过期时间意图识别节点本身不做缓存因为每句话都不一样结果生成节点也不缓存因为回复需要个性化。为了看清楚缓存命中情况我在工作流的每个节点出口埋点了hit/miss标记日志里直接能统计出各节点的缓存命中率。上线一周后整体缓存命中率稳定在41%这41%的请求完全没有发生模型调用对总成本的贡献非常明显。4.3 优化前后成本对比我拿上线前后各一周的数据做了对比业务请求量基本持平都约2.8万次。优化前平均每次请求消耗tokens为3800优化后平均每次请求为1850降幅约51%。下面是分项数据指标优化前优化后变化平均请求Token数3,8201,850-51.5%其中上下文Token占比72%34%大幅下降模型调用次数/请求4.2次2.1次缓存路由生效高价模型调用占比100%38%分级路由见效单次请求平均耗时9.8秒4.1秒并行缓存提升数字不会说谎。虽然前期花了大约两个工作日重构工作流结构但成本的降幅是可持续性的——只要业务请求量不变每个月节省的费用就是固定的一笔。更重要的是这次改造没有牺牲用户体验回复质量在人工抽检中反而略有提升因为压缩后的上下文噪声少了模型更容易抓住真正的意图。5. 常见问题与排查技巧实录5.1 Token失效导致的整条流程中断上线后遇到最多的一个报错是token失效现象是某个节点调用模型时报“token endpoint returned status 403”或者“your access token could not be refreshed”。这类问题一般发生在长会话或者长时间空闲之后LLM提供方签发的访问令牌有过期时间而我们的工作流节点并不知道。最直接的排查方法在Harness工作流的入口加一个统一的token刷新中间件在每次节点调用前检查令牌有效期剩余时间少于五分钟就主动刷新。另一个坑是局域网环境里时间不同步会让令牌校验直接失败这个遇到的概率不高但真要碰上会让人一头雾水排查时记得先对时。我踩过的具体坑是缓存里存了带token的会话快照令牌过期后快照恢复出去的还是旧token。后来我改了规范会话快照只存业务数据token一律不落盘每次唤起时从统一凭证服务里获取。5.2 上下文超长报错刚把上下文压缩器上线时我遇到过模型侧报“context length exceeded”原因是压缩器的输出虽然减少了但流程里某个工具查询结果特别大直接把token量顶上去。排查时先用工作流日志定位到具体节点发现是商品详情接口一次性返回了3000多个review。解法是在工具调用外面套一个字段过滤器只保留JSON里的关键字段去它的details.reviews需要时才再调一次子查询。所以上下文超长未必是历史对话太长也可能是工具返回的payload太大。5.3 缓存导致数据时效错误缓存虽然省钱但代价是可能读到旧数据。我们有次客服回复用户订单状态时缓存命中的还是昨天的“待发货”用户今天其实已经发货了。这个问题的根源是缓存key设计太粗没把状态变更动作纳入失效机制。后来我在缓存方案里加了一条规则凡是有状态更新类的POST/PATCH调用必须清空对应业务实体所有相关缓存key。同时对时效敏感的状态类数据把缓存时间降到30秒宁可多调几次也不给用户错误答案。5.4 路由选错模型质量不达预期低成本模型在部分场景下确实会掉链子。我在把简单查询路由到轻量模型后发现偶尔会把“查询订单”误判为“售后投诉”导致回复模板不准确。排查后确认是意图路由Prompt过于精简缺失了几个关键示例词。后来我在路由节点里加了一个很小的few-shot示例池只放了6条代表性对话成本多了不到50个tokens但意图准确率从88%升到97%。这说明分级路由的阈值不能拍脑袋需要结合标注样本做回归测试找到一个“能用便宜就便宜不能用就果断升级”的平衡点。最后再分享一个我个人的体会Token降本这事真正值钱的不只是省下来的钱而是整个团队对“模型每次调用到底在干什么”有了清醒的认知。没有了Harness工作流我们很难看到每个节点的真实消耗有了它之后成本变成可分析、可优化、可预测的数字而不是月底才揭晓的黑盒账单。后续我还在扩展的方向是把成本数据接上实时的费用告警任何一个节点的单次调用token增量超过阈值就直接邮件通知这样就不会再出现“不知不觉跑了一个月才发现超支”的事故了。