最近一直在折腾Agent类应用的工程化落地折腾来折腾去发现最肉疼的不是效果调优而是Token账单。一套Harness工作流跑下来每天几百万Token就没了钱包根本遭不住。这篇文章就是来聊聊我怎么做Harness工作流的成本优化实测下来把Token消耗砍掉了50%多。不是玄学是实打实的工程手段。如果你也在用工作流调度LLM或者正在被Token成本追着跑这篇应该能给你一些直接能抄的方案。Harness这个词在AI工程里通常指Agent Harness——也就是把LLM、工具调用、状态管理、任务编排组合起来的一套代理工作流框架。它跟Coze、Dify、n8n这类可视化工作流平台有相似的地方但更偏底层工程化适合接入自己的系统。好处是灵活、可控、适合生产环境坏处是框架本身不管你花多少Token所有消耗完全取决于你怎么组织工作流。我这次优化的核心思路就一句话别让工作流把Token浪费在无意义的事情上。1. 先搞清楚钱花在哪Harness工作流的Token成本拆解1.1 Harness工作流的运行机制与成本特征要降本先得知道钱是怎么花出去的。Harness工作流的典型模式是接收一个任务拆成多步每一步调用LLM或工具逐步推进直到完成。每调用一次LLM就要把当前上下文全部传过去——包括系统提示词、历史消息、工具返回结果、用户原始输入。Token计费按输入和输出分别算这里的核心问题是上下文越传越长每次调用的成本就越高。很多人在初期评估成本时只算“我调用了多少次API”但这个算法严重偏保守。真正的成本大头是“每次调用时传了多少Token”。一个看似简单的三步工作流如果第二步把第一步的完整输出带上了第三步又把前两步都带上了第三轮的上下文可能是第一轮的十几倍。Token消耗不是你调用次数的线性关系而是接近指数膨胀。我在一个实际项目里见过极端情况单次任务的Token消耗是理论最小消耗的20倍以上。原因就是没有做上下文管理所有历史全部堆在里面。所以成本优化的第一步不是换更便宜的模型而是把Token消耗链路彻底盘一遍。1.2 一张表看清Token都花在哪我把自己跑过的几套工作流做了Token流向统计整理成下面这张表Token消耗来源典型占比具体说明系统提示词10%-15%每个节点的角色定义、规则说明、few-shot示例对话历史30%-40%多轮任务中累计的上下文一次性全量传入工具调用结果25%-35%搜索、数据库、API返回的原始内容直接塞回上下文中间推理过程5%-10%多步骤推理中的中间思考文本重试与失败5%-15%超时、解析失败、认证失败导致的重复请求这个占比在不同任务类型里会有浮动但大体框架是稳定的。可以看到对话历史加工具调用结果这两项加起来往往超过60%这说明大部分Token都花在了“搬运上下文”上而不是真正用来理解任务、生成答案。这个判断直接决定了后续的优化方向——重点压缩历史、裁剪工具结果远比优化提示词更见效。1.3 四个典型的成本刺客第一个是上下文无限膨胀。有些工作流为了保持多轮对话连贯把每轮历史都原样保留最后调用时全量传入。用户聊了20句其中15句是寒暄和重复描述但这些全部计费。第二个是工具返回结果不做裁剪。搜索API返回了完整网页正文数据库查询返回了50个字段这些原始数据直接拼进上下文。一搜一读几千Token就没了真正有用的可能就一两句话。第三个是提示词堆叠。每个节点都写了一堆规则角色设定、输出格式、few-shot示例动辄七八百字节点一多系统提示词就吃掉大量Token。而且很多规则是重复的所有节点都在强调“不要输出Markdown”“用JSON格式”。第四个是一刀切用大模型。无论任务多简单全走最强模型。一个判断用户意图的分类任务根本不需要满血模型的推理能力但费用却按顶配算。这四个刺客只要处理掉两个成本基本就能打对折。2. 降本核心策略从架构上砍掉无效Token2.1 上下文压缩只保留最有价值的部分上下文压缩的思路很简单不要每次请求都把全部历史传给LLM而是用一个压缩器先处理历史提炼出真正关键的信息再传。具体有三种常见做法。第一种是摘要式压缩。每跑完N轮对话就把这段历史交给一个便宜模型生成摘要。后续请求携带“摘要最近几轮完整消息”而不是全部历史。比如用户问了10轮问题前8轮的完整内容被压缩成两三百字的摘要第9、10轮保留原文。这样既能保证任务的连贯性又把历史部分的Token消耗砍掉一半以上。第二种是滑动窗口。只保留最近K条消息更早的直接丢弃。适合那些任务之间关联度不高的场景比如客服机器人——用户前一小时问的发票问题跟现在问的退换货流程没有关系丢弃不影响效果。第三种是结构化记忆。每次对话结束后让LLM把关键信息抽取成固定字段——用户ID、偏好、当前业务状态、待办事项存成JSON。下次调用时把这个结构化记忆注入提示词而不是把原始对话历史塞回去。这个方法在Harness工作流里特别实用适合那种跨会话保持状态的场景。我在项目里用的是“摘要滑动窗口”组合超过6轮的消息走摘要最近2轮保留原文。实测下来历史部分的Token消耗降了70%左右而且回答质量几乎没有下降——因为LLM真正需要的决策信息点往往已经被摘要覆盖了。2.2 缓存相同问题不应该花两次钱工作流跑起来之后你会发现大量请求是重复的。客服场景里用户反复问“退款多久到账”和“退款进度怎么查询”本质是同一个问题文档问答场景里不同用户问“API限流是多少”和“每小时能调多少次”语义也完全相同。这些重复请求每次都完整走一遍LLM链路钱就白白烧掉了。我接入的是两级缓存。第一级是精确缓存请求做归一化处理去掉多余空格、标点、时态变化后完全相同的直接命中缓存返回。这个实现最简单用哈希就可以命中率一般在15%到20%。第二级是语义缓存把用户请求用embedding模型编码成向量存到向量数据库里每次新请求先算相似度超过阈值就直接返回缓存中的答案。阈值我调到了0.92以上避免语义过于发散导致答非所问。语义缓存的命中率比精确缓存高得多在客服类场景里实测能到35%左右。缓存命中一次省下的就是完整一轮LLM调用的Token费用还包括了更快响应时间给用户体验带来的加分。缓存组件推荐接Redis或MongoDB注意设置过期时间业务数据变了要及时清理缓存。2.3 模型路由把请求送到合适的模型不同任务的难度差异极大。判断“这个用户是不是在骂人”和“帮用户写一份商业计划书”消耗的Token推理量完全不是一个级别。但很多工作流不管三七二十一全用最强模型这是成本浪费的重灾区。我在Harness工作流里加了一个轻量级路由分发逻辑主流程接收请求后先做一次模型分配。具体做法是维护一个任务分类器用一个便宜的小模型判断请求类型和预估难度然后根据规则把请求路由给不同能力的模型。规则大概这样分类、抽取、格式化、关键词匹配类任务路由给便宜的小模型中度推理、多步骤工具调用、总结归纳类任务路由给中等模型长文生成、复杂推理、需要深度理解的任务才路由给最强模型。这个路由层本身也会消耗一部分Token但都是小模型在跑成本很低。实测下来这条路由策略让整体模型费用降了30%左右因为大约60%的请求最终都被分配到了便宜模型上。2.4 工具调用结果瘦身别把整个互联网塞进上下文工具调用是Harness工作流的核心能力——查数据库、调API、搜内网文档这些能力让Agent从“聊天机器人”变成了“能办事的工作流”。但工具返回的数据往往很长搜索引擎返回的是整个网页正文数据库返回的是整行50个字段这些原始数据如果直接拼进上下文Token立刻爆炸。我的做法是在工具返回后加一个返回处理层对工具结果做三道处理。第一道是字段裁剪只保留当前任务相关的字段数据库查询时明确指定需要的列不SELECT *。第二道是长度截断设置返回内容最大长度比如搜索摘要最多保留500个字符超出部分直接截掉。第三道是预提炼如果返回内容确实很长先用便宜模型提炼出与任务相关的要点再把要点交给主模型。举个例子一个工作流要回答“某商品过去30天销量怎么变化”工具返回了商品的50个属性字段和30天的日销量明细。如果全部塞进上下文几千Token就没了。但实际主模型只需要“日期销量”两列数据或者干脆只给它“总销量增长率”两个聚合值。瘦身完这块的Token消耗直接降到原来的20%。3. 实操落地在Harness里配置成本优化3.1 工作流配置一个核心的harness.yaml示例在Harness工程里工作流的编排通常通过配置文件声明。下面是我优化后的一个精简版工作流配置参考展示了缓存、路由、上下文压缩策略是如何接入的。这个配置不是某个特定平台的完整语法但思路是通用的你可以映射到自己的框架里。workflow: name: cost_optimized_agent version: 1.0 description: 带成本优化策略的Agent工作流 model_router: enabled: true classifier_model: cheap-classifier rules: - task_type: [classification, extraction, formatting] model: cheap-model - task_type: [summarization, tool_calling] model: mid-model - task_type: [complex_reasoning, long_text_generation] model: strong-model context_manager: enabled: true strategy: hybrid max_full_messages: 6 summary_model: cheap-model summary_frequency: 6 structured_memory: true cache: enabled: true exact_cache: redis semantic_cache: true semantic_threshold: 0.92 cache_ttl: 3600 tool_result_handler: enabled: true max_length: 500 field_filter: auto pre_extract: true extraction_model: cheap-model这里几个关键参数说明一下。max_full_messages控制滑动窗口大小超过6轮的消息走摘要压缩semantic_threshold控制语义缓存命中阈值太高命中率低太低容易答非所问cache_ttl设置缓存过期时间业务数据频繁更新的话要调短。这些参数不是固定的我建议上线后根据业务数据持续调优。3.2 上下文管理的核心代码实现配置说完了说说代码。这里给一段管道处理逻辑主要演示怎么判断当前上下文是否超限、以及如何触发压缩。这是Harness工作流里上下文管理模块的核心逻辑我用的语言是Python你可以直接参考。class ContextManager: def __init__(self, max_full_messages6, summary_modelcheap-model): self.messages [] self.max_full_messages max_full_messages self.summary def add_message(self, message): self.messages.append(message) if len(self.messages) self.max_full_messages: self._compress() def _compress(self): # 把最早的消息交给便宜模型做摘要 oldest self.messages[:self.max_full_messages // 2] summary_text self._summarize(oldest, self.summary) self.summary f历史摘要:{summary_text} # 只保留最近一半的完整消息 self.messages self.messages[len(oldest):] def _summarize(self, messages, history_summary): # 实际项目里这里调用LLM接口让模型提炼关键信息 prompt f以下是之前的对话摘要:\n{history_summary}\n\n请将新对话压缩为新的摘要保留关键事实、决策和待办事项。不要添加新信息。\n\n新对话内容:\n{messages} return call_llm(prompt, modelcheap-model) def build_context(self, system_prompt, user_input): # 最终组装上下文系统提示词 摘要 最近完整消息 当前输入 return system_prompt \n self.summary \n str(self.messages[-self.max_full_messages // 2:]) \n当前问题: user_input这段代码的关键思路是messages列表只保留最近的一部分完整内容一旦超过阈值就触发压缩把老消息交给便宜模型生成摘要。我第一次实现的时候走了弯路把摘要也每次都重新生成——后来才发现累加式更新摘要而不是全量重算能进一步降低Token消耗。上面代码里把旧摘要传给_summarize就是做累加更新。3.3 语义缓存接入与命中逻辑缓存这块也不能光配个Redis就完事。语义缓存的接入稍微复杂一些需要在请求进入主流程前做“查询-比对-命中”三步。我给出核心实现思路。import redis import numpy as np class SemanticCache: def __init__(self, redis_client, embedding_fn, threshold0.92): self.redis redis_client self.embedding_fn embedding_fn # 编码函数返回向量 self.threshold threshold def get_cached_answer(self, query): query_vec self.embedding_fn(query) # 用余弦相似度遍历已缓存向量 for key in self.redis.scan_iter(sem_cache:*): cached_vec np.frombuffer(self.redis.get(key), dtypenp.float32) sim np.dot(query_vec, cached_vec) / (np.linalg.norm(query_vec) * np.linalg.norm(cached_vec)) if sim self.threshold: cached_data self.redis.hgetall(key) return cached_data[banswer].decode(utf-8) return None def set_cache(self, query, answer): query_vec self.embedding_fn(query) key fsem_cache:{hash(query)} self.redis.set(key, query_vec.tobytes()) self.redis.hset(key, mapping{answer: answer})大规模场景下逐条遍历缓存不是最优方案应该建向量索引。但这个实现思路适合小规模的Harness工作流能让你先跑通逻辑、看到收益。真正数据量大了再换向量数据库。3.4 成本监控让每一分钱都有迹可循优化做完了不监控等于白做。我强烈建议在工作流里埋一层Token用量日志记录每次请求的模型名、输入Token数、输出Token数、缓存是否命中、路由到了哪个模型。数据可以打到日志平台或简单的JSON文件里然后做成看板。我自己的监控字段大概是这样字段作用request_id追踪单次完整请求model_name实际调用的模型prompt_tokens输入Token数completion_tokens输出Token数cache_hit是否命中缓存true/falseroute_rule路由命中规则context_size_before压缩前上下文大小context_size_after压缩后上下文大小有了这些数据你就能按天汇总出三个关键指标平均单次任务Token消耗、缓存命中率、各模型占比。每次调整参数后看这三个指标的变化就知道是否有效。这比凭感觉优化靠谱得多。4. 绕不开的坑Token失效与认证失败的排查实录4.1 工作流里最常见的认证错误token exchange failed 系列这类错误在热搜词里出现了很多次——token exchange failed: token endpoint returned status 403 forbidden、sign-in could not be completed token exchange failed: error sending request。这不是Harness工作流特有的问题而是几乎所有接入LLM服务的项目都会踩的坑。我把踩过的原因和排查思路整理一下。先看403 forbidden这个。它通常有两种情况。第一种是调用方身份没通过——client_id、client_secret配置错了或者API Key过期了。这个最直观去控制台重新生成即可。第二种是请求来源被服务端拦截比如服务商基于来源区域做策略限制。遇到这个先确认你的调用来源是否符合服务商的使用条款而不是绕来绕去。从合规角度我建议直接联系服务商确认可用的调用方式和区域范围。再看error sending request这个属于网络层错误。在Harness工作流里多见于自建网关配置问题超时时间设置太短、DNS解析失败、目标服务响应过慢。排查方法是先curl直达LLM服务的endpoint确认网络通不通通了再逐层排查Harness内部是否有代理、是否有防火墙、证书是否过期。我遇到过一次是网关把POST /v1/chat/completions的路径重写错了导致请求404然后客户端报token exchange failed。这种问题光看报错根本定位不到必须配合链路追踪。4.2 Token过期与续签JWT方案的实现要点另一个高频问题是Token过期导致工作流中断。Harness工作流可能是长时间运行的一个任务处理到一半Token过期了后续步骤全部失败。解决方案是自动化续签机制我用的是JWT续签。核心思路是不等到Token彻底失效再重新登录而是提前检查有效期快过期时用refresh_token去换新的access_token。这里有几个坑要提醒。第一refresh_token也有有效期而且通常比access_token长得多但仍会过期所以需要定期刷新refresh_token本身。第二刷新接口要加锁防止多个并发请求同时刷新导致旧Token被撤销。我在项目里就用threading.Lock把刷新逻辑包起来实测省了好多次“突然全部401”的事故。第三如果检测到刷新失败不要立刻重试——先等几秒大概率是网络抖动连续失败3次再去检查配置。4.3 上下文超长是另一个高频故障Dify工作流、Coze工作流里“上下文超长”是很常见的报错。这个和上面讲的上下文管理直接相关。如果你没做压缩和窗口控制任务一多上下文轻松超过模型的上下文窗口限制。我见过最夸张的是一个多Agent协作工作流每个Agent把前面所有Agent的输出都带上了结果任务跑到一半就报“context length exceeded”。解决办法就是把这套压缩机制真正落地。第一给工作流设置上下文上限超过上限强制触发摘要压缩。第二控制工具结果的长度别让一个大JSON把窗口撑爆。第三如果业务确实需要长上下文考虑对历史内容做向量化检索只把相关片段拼回上下文而不是全量塞入。4.4 一个百试百灵的排查顺序踩了这么多次坑我总结了一个排查认证和Token相关问题的顺序。先看配置再看网络先看日志再看代码。具体来说第一步确认API Key或Token本身有效去控制台手动调一次接口测试第二步检查请求格式header里的鉴权字段是不是Bearer开头参数有没有拼错第三步检查网络链路直接curl打通第四步看Harness工作流的日志里有没有暴露具体的endpoint和响应体。这套顺序能解决90%的认证问题不用一上来就怀疑框架。5. 效果验证与收益测算5.1 降本50%的测算逻辑是怎么来的很多人看到“降本50%”会怀疑是标题党。我来说清楚这个数字是怎么算出来的你也能对照自己的场景估算。以我一个生产环境的工作流为例。这个工作流每天处理约1000次完整请求未做优化前平均每次请求消耗约8000个Token——其中系统提示词约800、历史上下文约3200、工具返回约2500、输出约1500。按这个计算每天消耗约800万Token。优化后我做了四件事上下文压缩让历史部分降到原来的30%左右语义缓存命中率到30%这部分请求完全不再调LLM模型路由让60%的请求走便宜模型单价降了一半还多工具结果瘦身让工具部分的Token降到原来的20%。四项叠加日均Token消耗从800万降到400万以内再加上模型单价下降账单降幅达到50%以上。具体拆解如下总消耗 压缩后的历史 缓存未命中的请求 × 路由后模型单价 瘦身后的工具Token。缓存命中那30%请求是不产生LLM费用的路由比例直接影响剩余请求的单价压缩和瘦身直接影响每次请求的Token数。这个测算逻辑是可以复用到你自己的项目里的。5.2 一组实测数据样例下面这组数据是我在一个生产项目里优化前后一周的对比脱敏后给大家参考指标优化前优化后降幅日均Token消耗800万380万52.5%单次请求平均Token8200390052.4%缓存命中率0%32%新增便宜模型占比0%58%新增平均响应时间2.8s2.1s25%注意响应时间也降了这个很好解释缓存命中的请求秒回便宜模型推理得更快上下文压缩后传输的数据量也变小了。用户体验不降反升这是我一开始没预料到的收获。5.3 落地后的几点真实体会优化做完账单真的降了下来之后有几点体感想分享给你。第一不要试图一次性优化到位。成本优化是一个持续的过程先把缓存接上再调上下文压缩最后上模型路由每一步都上线观察一周看效果和副作用。我第一批全量上马时出了个问题——摘要压缩得太狠把关键细节丢了导致任务准确率掉了一截。后来调低了压缩频率保住了准确率。第二便宜模型不是万能的。模型路由确实省了很多钱但小模型在复杂推理场景下会明显拉胯。我建议给路由加个兜底规则如果小模型生成结果置信度低自动升级到大模型重新跑。这个兜底逻辑会消耗少量额外Token但保证了任务质量下限。整体算下来还是比全用大模型便宜很多。第三监控是优化的前提。没有Token级别的监控你根本不知道钱花在哪也没法验证每次优化是否真的有效。我在做优化之前先花了三天把监控补齐这三天的时间在后来的优化过程中被成倍赚回来了。第四缓存清理要跟上业务变化。有一次业务方改了数据口径但缓存没清结果用户问了好几天旧口径的答案。后来我加了一个规则关键业务数据变更时主动触发相关缓存清除。这个太重要了一定要记住。这整套优化方案从配置到代码到排查思路都不是只有特定平台才能用。Harness核心是一个工程概念你可以把它移植到任何工作流引擎里。如果你正在被Token成本追着跑建议按照“先监控、再缓存、再压缩、再路由”的顺序走一轮大概率能找到属于你的50%。