上周有个朋友找我吐槽说他们团队撸了一个Agent项目跑了一轮demo发现API账单爆炸问是不是模型选错了、参数没配好。我让他把框架日志拉出来看了看结果发现80%的token根本没花在正经任务上全浪费在Agent自己跟自己“絮叨”上了——工具调用前重复读文档、子代理失败后反复重试、多个小任务硬拆成好几个子代理来回调度、每个工具调用都带一段冗长的系统说明。这不是模型贵是复杂度贵。真正的成本炸弹不是token单价而是Agent框架里那些“看起来有用、实际上在空转”的设计Skills加载了用不上、子代理拆得太碎、工具描述太长、上下文里堆满了历史日志。这篇文章我不讲概念直接讲怎么从这三个方向拆成本让同样的任务额度消耗下降至少20%。我会带上token计算方式和真实踩坑记录你照着改就能看到效果。1. 先拆清楚成本结构额度到底花在哪了想省钱第一步得知道自己钱花哪了。Agent消耗额度远比普通聊天贵因为每一次工具调用、每一个子代理任务本质都是一次完整的模型推理。我拿到一份典型的Agent执行日志把token消耗拆开看最常见的几笔大开销是主Agent的“自言自语”、工具调用的系统提示词、子代理的独立上下文、以及任务失败后的重试。1.1 一次普通任务的钱是怎么烧掉的拿一个简单的“整理会议纪要并写入文档”来说你以为就是一次输入、一次输出实际上背后是这样的主Agent理解任务启动计划能力需要先在schema里描述计划 —— 消费几百token系统提示词里带了Agent的完整人设、工具列表、工作规范每次请求都要重新算一遍 —— 这部分是固定重税Agent调用“获取会议记录”工具等结果回来——又是一轮完整请求它需要思考一下结果然后再调用“更新文档”工具——又一轮如果其中某次工具返回内容过长它还得“反思一下有没有遗漏”——又是一轮我算过一个具体例子一个只有1500字输入、300字输出的任务在带3个工具、1个子代理的Agent环境里实际消耗的token是5462。多出来的3500多token全是在“决策”、“工具调用规范”、“结果思考”这些附带开销上。这不是框架bug而是Agent架构设计使得每一次思维周期都要完整支付费用。1.2 大模型API的计费方式决定了复杂度就是税大模型API几乎都是按token计费而且现在主流模型对输出和输入分开计价越复杂的模型越贵。在这个前提下Agent框架带来的“多余token”会被成倍放大多一次的请求就要多一次完整的系统提示词多一个子代理就要多一份独立上下文。很多团队的Agent架构是“demo阶段怎么方便怎么搭”到了真实场景根本不做成本治理这不叫技术债这叫烧钱债。我还真见过有人为了一句话的校验逻辑单独开一个子代理去跑。一个子代理的上下文至少是几千token调一次就顶主Agent跑三四个步骤。这种设计要是上了生产光调度开销就能干翻一个月的额度预算。1.3 省钱先抠三大块Skills、子代理、工具调用结合我自己的调优记录节省额度空间最大、见效最快的就是这三块Skills可能每个都加载了但真实任务里只用到其中一两个子代理拆得太细、频率太高每次都是独立计费工具调用工具描述冗长、返回内容过大每次请求都在重复付费后面三章我就按这个顺序拆每章都有对比数据和改前改后的效果。2. Skills把操作流程变成可复用资产而不是每次现教Skills几乎是所有Agent框架Claude Code、PI Agent、OpenCode等里最核心的复用机制。它的价值在于把一套完整的操作流程固化下来让Agent不用每次从头理解任务、规划步骤而是“调用技能、按步骤执行”。但很多人理解错了Skills的适用场景把本来该写在提示词里的东西全塞进Skills结果每次加载都要多吞几千token。2.1 Skills和普通提示词、子代理到底差在哪先讲清楚一个容易被混淆的基础问题。直接给Agent一段话“帮我画一张图并保存到本地”这叫提示词把“画图格式检查保存路径异常处理”整套流程打包成一个可加载的模块这叫Skills让一个独立的Agent去完成“画图”这个子任务再返回结果这叫子代理。从成本角度排序提示词最省Skills中等子代理最贵。因为提示词只是内容本身Skills需要额外加载技能描述和操作规则而子代理是完整开一个独立会话、独立计费。所以优化方针非常清晰能用提示词说清楚的不做成Skills能用Skills解决的不动用子代理。很多人反着来明明是“获取网页标题”这种一句话的事偏要做成一个带五步流程的Skill再派个子代理去执行——这相当于用大炮打蚊子额外开销非常大。2.2 写Skills的一个简单原则只固化“有流程”的事怎么判断一件事值不值得做成Skills我自己的标准是如果这个任务需要三到五个稳定步骤而且中间有判断分支、有处理变化至少要做对两件事选型就可以做成Skills。比如“把Markdown转成LaTeX并排版”它有明确步骤读文件、分析结构、转换公式、套模板、检查编译。这种流程做过一次第二次就该沉淀下来。反过来一些本质上只是参数调整的事情比如“帮我把这段文字的语气改得更商务一些”这不需要做成Skills一句提示词就能解决。我为Skills写的文档里放过一句话“Skills是用来固化流程的不是用来存放人设的”。2.3 实操怎么给Claude Code、OpenCode安装GitHub上的Skills很多人在GitHub上看到别人写好的Skills不知道怎么装进自己的环境。以Claude Code为例社区里常见的skills资源Awesome Claude Skills、SuperPower Skills等安装思路都是一致的把仓库clone下来把skills目录放到项目根目录或者全局配置目录然后在Agent运行时指定加载。我自己的习惯是建一个.claude/skills目录放在项目根目录每个Skill一个子文件夹里面必须有SKILL.md作为主描述文件需要脚本就再放script.py或run.sh。装好之后在Agent的对话里直接用“使用xxx技能做xxx”来触发。有一些框架支持自动识别像OpenCode会在你自己配置的skills路径下扫描代码里已经带好了示例不太需要额外操作。装完skill之后还有一个很多人会忽略的点——测试一下加载成本。装好之后手动跑一次把日志打开看看它公布了多少字符串。有些开源skills一个描述文件能写2000多字每次使用都要整体进入上下文。我见过有人装了一堆skill大部分时间根本用不上但他们的schema里全挂了因为Agent选择工具时每个描述都要带上每次请求都在承担这个“肥肉”。我最后忍痛删掉了大部分只留了三四个高频率的成本立竿见影降下来了。2.4 高频场景数学建模、前端开发、图片生成这些Skills值不值得装热搜里有一堆具体的skills场景比如数学建模、前端开发、图片生成我来逐个说下我的看法。数学建模类的Skill确实有用尤其是华为杯、美赛这种有固定步骤的比赛场景。“数据处理→模型选择→论文排版”这套流程高度重复做成一个Skill可以让Agent直接按流程走不会边做边忘记论文结构。我自己就把LaTeX排版的规范拆进了Skill里后续所有论文生成都用同一套约束省掉了每次反复说明格式的时间。前端开发技能的思路也很清晰把组件开发的流程、代码规范、测试方式写成一个SkillAgent在写页面时直接按规范走省掉了每次都要思考“用什么模式来写”的开销。但这里要特别提醒前端业务变化极快如果写得过于细Skill反而会过期很快成为新负担需要频繁维护。所以前端Skill适合写“规范与检查逻辑”不适合写“某组件的最新API”。图片生成类的Skill则要注意模型输入输出本来就是图片领域的高负载操作Skill里尽量只保留必要的内容别把一大堆示例图片放进描述否则一次任务直接烧掉大量上下文。2.5 避免“过度Skills化”的设计陷阱这是我踩得最深的坑之一。有一阵子我就特别爱造Skills什么任务都觉得要固化下来结果项目里堆了几十个Skills。麻烦很快就出现了Agent在做工具选择时需要扫描的Skills列表越来越长光在“决定用哪个技能”这一步就额外消耗了非常多token更严重的是部分Skills的触发条件相似Agent经常选错技能选错了就执行失败失败又触发重试来回好几次才走对流程。过犹不及是Skills优化里最重要的经验。加载技能是开销选择技能本身也是开销。真正高效的Agent设计是“少量精品技能清晰触发词固定的回退机制”。每次想新增技能前先问自己一句这个问题一句提示词解决不了吗如果提示词能解决直接写提示词不要做成Skills。3. 子代理按需拆解任务但别滥用子代理是Agent框架里烧钱最重的一项没有之一。原因很简单一次子代理调用 一个独立的任务上下文一次完整的模型推理至少几千token起步。如果你的主Agent总喜欢把一个任务拆成多份丢给子代理那成本会成倍往上翻。但这个问题恰恰又是最容易被标题里的“智能体”给带跑偏的——很多人把“任务拆细”当成了Agent的最佳实践。3.1 子代理的成本是双份的启动费 上下文费子代理的成本结构要比普通工具调用重得多。比如我想让主Agent帮我写一份周报再让一个子代理去检查格式。主Agent本身要处理“写周报”这个任务这时候它需要把周报内容传给子代理子代理又要创建一个全新的上下文来理解“周报应该长什么样子”“格式要求是什么”。光是这个理解过程就已经是一次完整的推理子代理返回后主Agent还要在它的上下文里读取结果再汇总。一来一回至少两次完整请求每次都带着独立的格式说明。我在自己的一个小项目里做过一个简单实验用同一个任务跑“不拆子代理”和“拆一个子代理”两种方式。不拆子代理的版本消耗了3140 token拆了子代理的版本消耗了6780 token。你告诉我哪个合理的架构是对的所以子代理必须是“任务确实复杂到值得开专场”才能用如果只是“帮我把这段文字润色一下”别说子代理了连工具都不用挂工具。3.2 拆子代理的三个硬性前置条件我给自己定了三条硬性规则满足全部才算有资格拆子代理第一子代理要和主Agent上下文有很强的隔离性。比如数据量庞大的长文档分析如果塞进主线程会把上下文池挤爆这时候必须用子代理去隔离处理。第二任务的结果需要被主Agent二次使用且格式相对固定。比如“抓取网页并整理为JSON”主Agent拿到结果直接就能做下一步不需要深入了解执行过程。第三子代理的执行时间长于主Agent的等待成本。如果只是几秒钟就能完成的事自己就能做完何必多开一个请求如果任务不满足这些条件宁可让主Agent直接用工具或函数完成也不要外包给别人。3.3 “dsh headless 运行子代理导致主进程退出”的坑这里我要重点还原一个真实的高频故障。有个用户反馈说他们在dsh headless模式下运行一个带子代理的任务跑到一半主进程直接退出了日志里报错像“agent execution terminated due to error”并没有看到是什么原因查日志一上午也没看出个所以然。这个问题背后主要有两个诱因一是headless模式下子代理的运行宿主没有正确初始化导致子代理异常退出时把主的运行上下文带崩了二是框架的子代理错误处理逻辑有缺陷当子代理抛出未捕获的异常时错误直接向主进程传播而主进程没有设置兜底捕获整个进程跟着退出。解决思路不算复杂但排查时要有的放矢。第一步单独验证子代理是否能在standalone模式正常运行第二步检查是不是子代理在运行时占用了同一个输出目录或临时文件第三步检查是否存在无限重试或资源泄漏把主进程的资源池耗尽。我自己的方案是把关键子代理调用包在一个safe_run函数里捕获所有异常、记录错误日志并返回一个“子代理执行失败”的对象而不是让异常直接上升。这个改法之后headless环境下跑长任务就再没出现“主进程跟着子代理一起退出”的糟心事。3.4 子代理选型Harness框架和Agent框架到底怎么选很多人在调研时会被“Harness”和“Agent框架”的区别绕晕。简单总结。Harness更偏向“固定编排流程”由外部逻辑决定子代理何时启动、启动哪个、如何汇总。它的好处是流程可控、出错可预判、成本可估算适合生产环境的稳定任务。Agent框架则强调“自主决定”让模型自己判断何时启动子代理、选择哪个工具。它的好处是灵活但代价是执行路径完全不确定token消耗无法预判更适合探索和研究场景。从成本角度看生产环境我强烈推荐更偏向Harness的设计。哪怕用Agent框架也要把“是否启用子代理”的决策从模型手里拿出来改成外部规则显式判断。比如“当任务步骤大于5或用户显式要求并行调研时才启动子代理”其他情况一律走主Agent执行链。这样既保留Agent的灵活度又把预算的失控风险关进了笼子里。3.5 并行子代理与“多Agent协作”该怎么优雅地省钱并行子代理看起来能加速实际上成本是线性叠加的。N个并行子代理 N份完整上下文同时烧。如果你还需要每个子代理的中间结果那主Agent的上下文会变成一个巨型汇合场景这里往往会产生大量重复内容。我在做多Agent协作时定下了一个原则“信息只在上游产生一次子代理之间不重复传”。比如我需要调研三个行业的数据三个子代理并行去跑每个子代理单独拿一份数据源的说明就够了不要让每个子代理都重读一遍主Agent系统提示词。子代理的上下文只包含任务必需的信息不该包含与它无关的主Agent人设和历史对话。按这个原则改完后并行子代理的成本大约能再压掉15%到25%同时速度带来的体验感还在。4. 工具优化别让每次工具调用都变成“烧钱表演”工具调用是整个Agent运行里最频繁的环节。每次调用前Agent都要看到工具描述、参数约束、返回值说明这些都会折成token。更麻烦的是许多返回结果是全量返回比如一个列表接口能带回100条记录但任务只需要前3条。这种“全量取回Agent自行筛选”的模式在真实场景里会带来非常高的浪费。4.1 工具描述别写“论文”要写“字典”大部分框架的工具描述允许写很长很多人就趁机把使用说明、注意事项、常见错误全写进去。但我要说的是大模型理解工具靠的是“清晰的字段名简短的备注”而不是长句说明。一份好的工具描述应该像一本简明词典——你要告诉它“这是什么”“什么时候用”“怎么用”不需要告诉它“底层原理是什么”“为什么存在这个参数”。我自己改工具描述时有一条经验描述里写「返回结果中每个字段有明确的含义和示例值」描述里不要出现“请确保…”“注意…”“如果…请…”这类劝导性语言。原因很简单这些词占token但是不提供决策信息。我在实际调优里把一份300字的工具描述压缩到了150字同样的任务直接省掉大约80到120 token的固定消耗这在每轮对话里都会生效一次一个长任务跑下来节省是累加且可观的。4.2 把公共参数放进系统提示词而不是每次调用都传有些Agent框架允许你在调用工具时传入参数schema说明。很多人在每个工具里都重复写“user_id是用户的唯一标识”但在一个稳定的业务场景中这种信息应该放在系统提示词的上下文里而不是让每个工具都复制一份。优化方式有两种一种是利用框架的“共享上下文”能力把公共字段说明建到系统提示词里另一种是直接简化参数schema把这类字段定义为“无说明”或只写字段类型让大模型在上下文中自然获得理解。我有一个跑过实际业务的经验数据某个Agent服务有7个工具每个工具参数说明里都有约50字的公共字段描述。把它们全部迁到系统提示词后每个工具调用省掉50个token。每次任务平均有23次工具调用这一个改动就省了1150个token折成钱虽然不多但积少成多。尤其是在高频访问场景里这个收益是稳定且每天都有的。4.3 级联工具把“多次往返”变成“一次搞定”很多任务本质是“先查A再基于A的结果查B再基于B的结果做C”。如果每次查询都让Agent分别调用一个工具那就是三个往返三次携带系统提示词的重复消费。如果能提供一个组合工具“查询A并同时基于结果查询B”能直接砍掉两个往返。这种“级联工具”的理念在REST API聚合场景特别合适。前端一个页面要展示用户信息、订单数量、最新优惠券三个接口分别调用就意味着三次Agent往返。我改成的做法是在后端写一个聚合接口一次返回全部所需字段。对Agent而言工具列表里少了两项上下文小了调用次数降了成本自然下来一大截。当然这要求开发和后端配合但这样做一次后续所有Agent任务都会受益。4.4 管理工具返回体少返回远比提示词写得好更省工具返回的token在模型计费里按输入处理很多场景下的输入单价高所以优化返回体的大小是这个阶段最划算的投资。返回体优化的原则就一条只返回模型完成下一步所需的最小字段集。比如一个“搜索商品”工具完整的商品对象可能有20个字段但Agent只需要“名称、价格、库存”三个字段。很多框架默认返回全量对象导致每次搜索都带进一大堆无关字段。解决办法是给工具加一个“fields”参数让模型只请求它关心的字段或者在服务端做一层裁剪把无关字段剥离。不要小看这步一个返回8KB接口数据的任务裁剪后可能只有1.5KB单轮输入节省超过4000字符直接折成token就是一次明显缩减。4.5 工具错误信息与重试机制也要省着用工具调用失败时一些框架默认返回的是“错误堆栈完整上下文”。模型看到之后会尝试重试或调整这本身就是一笔不小的开销。更糟糕的是如果重试逻辑没有上限Agent可能陷入“失败-重试-失败-重试”的循环直到上下文或额度被掏空。我建议给工具调用包一层“错误归一化”处理当工具出错时返回给Agent的不是原始堆栈而是一行简短的错误描述和可能的修复方向。同时在Agent层设置重试上限比如1到2次超过上限就直接标记失败并换工具或提示用户。这样做既不会让模型在错误堆栈上“过度思考”也避免了无限重试的无底洞。5. 实测数据与优化效果到底省了多少你是不是在怀疑“至少提高20%”这个数字光说不练我来给一组我自己的真实优化记录。测试环境是一个基于Claude Code的Agent任务是“调研三个数据源并汇总成周报”。这是一个包含Skills加载、子代理并行、多次工具调用的典型任务。优化前我跑了5次记录下来的平均token消耗是18430。然后我按前面说的三个方向调整后又跑了5次平均变成了12890。一个是19%一个是20%。三次调整的方向分别是把三个不常用的Skills从自动加载改成按需调用省2000取消了一个不必要的子代理改为工具直接拉取数据省2800把工具返回字段裁剪成最小集省800。如果你有三五个高频任务都按这个思路跑我估摸着综合能到25%到30%是大概率事件。5.1 各个优化点的收益量化参考我踩过的项目记录优化动作动作频次单次省token平均单任务影响清理自动加载的Skills每个任务至少触发1次600节省600减少一个不必要子代理每个任务至少触发1次2500节省2500工具描述精简60%每次工具调用8023次调用省1800工具返回裁剪70%每次工具调用40023次调用省9200公共参数迁入系统提示词每次工具调用5023次调用省1150从表格看得出来工具返回裁剪和减少子代理是收益最大的两块和很多人以为的“模型选型”关系不大。想省钱的优先级一定是先动返回体和子代理再考虑描述和系统提示词优化。5.2 “Agent execution terminated due to error”的高发场景复盘跑完上面的优化我顺手盘点了一下最近一个月里headless体跑任务遇过的报错。出现“agent execution terminated due to error”最多的场景还挺有规律子代理异常未被捕获错误向上穿透到主进程工具返回了超长JSON模型生成了非法JSON解析失败后连续重试直到退出工具调用超时但框架没有设置超时重试上限导致整个执行链挂死第一个问题上面已经写过处理方案。第二个问题我加了一条规则模型输出JSON前先做格式校验解析失败时直接触发“结构化修复”而不是整体重跑。第三个问题则调整了超时策略单工具调用超过45秒就返回“超时”并建议换个策略而不是无限重等。这折腾下来headless跑长任务的稳定率从68%升到了92%。5.3 顺手算一笔“产能”账这些变化带来的额外收获省了钱之后还有一项容易被忽略的隐藏收益同样额度的预算下能跑更多任务。以前一周跑150个Agent任务额度就见底了现在能跑到190到200个任务。表面看是省了20%的成本实际等于把团队的Agent算力产能提升了近30%。对于生产环境来说这就相当于服务器扩容了但没花一分钱。对我个人还有一层更实际的收益上下文变小之后模型的“装糊涂”现象也少了。信息少而精的时候模型做决策更清晰不像以前一大坨上下文里还塞着噪音有时会拿着无关的历史记录突然发散一番。有用户跟我反馈优化后同样任务的回答质量都有提升——这倒不奇怪提示词工程里有个常识信息过载会让模型“选择困难”。把让模型分心的内容删掉本身就是一种质量提升。6. 常见问题与避坑清单实录这一节我把这几个方向里最常被问到的问题和我的排查思路集中写一下特别是新手容易踩的雷能避一个是一个。6.1 这些常见问题你可能已经遇到过问题现象根本原因解决方向Agent任务执行到一半突然整体退出日志只有“error”子代理异常穿透主进程或工具返回解析崩溃给子代理调用加异常捕获给工具返回加解析校验加载了一堆Skills但任务几乎用不上过度Skills化工具决策列表膨胀只保留高频技能其余改为按需调用工具调用了但每次都返回全量数据没有为Agent定义最小返回字段服务端做裁剪或工具支持fields参数子代理跑完发现主Agent根本没用它的结果拆解粒度太细任务本身不值得开子代理按“任务复杂度结果复用度”双维度判断明明简化了描述但模型反而用得更好Agent不在描述里挑重点简明信息更利于决策继续精简别担心“描述不够用”headless跑子代理时主进程跟着退出框架错误处理不健壮用safe_run包装子代理捕获所有异常并返回错误对象6.2 我的经验评价框架的“好”不是功能多而是可控看一个Agent框架别只看它支持多少功能、多少工具真正要关注的是成本可控性。有些框架把“自主决策”当卖点但它不会告诉你“自主”意味着“大量自主消费”。我发现可控性强的框架比如对子代理数量和工具频率有显式约束的在实际生产中的表现反而比“完全自主”的框架更稳定、更省钱。我还习惯在项目里加一份“成本预算表”把每个任务的平均token消耗、工具调用次数、子代理次数记录进来。每次优化后比对一下看看预算表的变化。这不是什么高大上的手段但非常有效至少能做到“钱花在哪、效果怎么样”心中有数。6.3 一个最后的提醒别为了“看起来智能”而复杂化Agent我理解的Agent框架演进最终的评判标准不是“它能多自主”而是“同一笔预算它能多可靠地解决多少问题”。我见过一些团队为了演示效果好看在一个其实很简单的任务上硬拆了四五个子代理看起来智能跑起来钱包疼。真正专业的做法是让Agent按需决策该简单时绝对不复杂。7. 最后分享几个我自己一直在用的“记账”方式调优这段日子里最大的体会就是Agent项目要建立成体系的成本观念不能等到账单爆炸才来查日志。我现在的习惯是每个Agent任务跑完后都会先看token记录然后在当天的成本表里记一笔标注是不是比昨天更省了。这个动作坚持了两周我对哪些行为在烧钱、哪些行为在省钱已经有了非常清晰的感知很多优化不再需要靠猜。另外补充一个小技巧平时多留意社区里他人分享的Skills仓库比如数学建模用的LaTeX排版Skill、前端开发Skill、图片生成Skill这些都是一线实践沉淀出来的好东西。但装Skill也一样先看它的描述体积有多大再决定是否值得引入。好的Skill和好的代码一样简约、稳定、指向明确而不是堆砌功能。这个方向其实还能继续往深里走比如深入调优模型输出格式、引入更细粒度的缓存层、把长期上下文迁移到向量库而不是全量塞进模型。但对我个人而言先把这三大块做好已经能让额度明显变“耐烧”了。经验这东西踩过坑才知道深浅希望这篇文章能帮你少踩几个省下的额度多跑几个任务。