前阵子帮一个团队做Agent项目瘦身他们很困惑地问我功能越做越多效果却越来越差额度也越烧越快。我看了一圈代码第一反应是——他们不是在开发Agent而是在经营一套微服务系统。21个自定义Skills、13个子代理、30多个工具函数还有好几层包装的调用链。这不是个案。我把这类项目统一称为复杂度税交得太多的Agent。所谓额度不管是token配额还是API预算本质上就是一次任务的成本上限。当你把系统做得足够复杂每次任务光无意义的固定开销就能吃掉一大半额度真正留给模型思考的空间少得可怜。这篇文章把我自己的项目瘦身经历完整写一遍包含Skills精简、子代理决策、工具优化三个核心方向以及如何通过一套可复制的操作让同样的额度多撑20%以上的任务量。适合那些Agent已经跑起来、但被成本和复杂度压得喘不过气的开发者。1. 先算账Agent的额度究竟烧在了哪里1.1 额度不是被能力烧掉的而是被冗余烧掉的Agent每次做决策模型都要把系统提示、工具定义、历史对话和当前输入全部读一遍。这一点和人类完全不同人翻旧账的时候是具体找某句话模型是每次把整个文件夹从头到尾读一遍。所以复杂度直接等于成本这句话要刻在脑子里。我在实际项目里见过三种最典型的烧额度黑洞上下文膨胀系统提示从几千token膨胀到几万token其中大量内容一年都用不上。工具定义重复计费每个工具的JSON Schema不是只付一次钱而是每一轮决策都要付一次。工具总数越多每一轮越贵。失败重试Agent一旦报错或者工具调用异常往往不是只损失一次请求而是带着报错信息重新跑好几轮消耗成倍增长。这三种问题叠加起来一个本可以3000 token完成的任务最后可能烧掉30000 token。这就是复杂度税的真实账单。1.2 算一笔账一次普通任务的token都花在哪了我们假设一个中等规模的Agent任务需要5轮模型调用。它的token消耗结构大概是下面这样消耗项目每轮token轮次总计占比系统提示Skills清单8k540k44%工具定义6k530k33%历史与任务输入2k510k11%模型输出约2k510k11%合计36k590k100%数据是估算值每个项目不完全一样但看结构就够了真正给你解决业务问题的模型输出只占很小一部分大头被系统提示和工具定义吃掉。所以精简系统提示和工具定义是所有优化里收益率最高的动作。另一个容易被忽略的点是轮次放大效应。任务轮次越多前面的固定开销被重复的次数越多。把轮次从8轮降到5轮省的不是3轮的钱而是3轮乘以全部固定开销的钱。这也是为什么我会建议先做减法、再调细节。2. Skills瘦身装得多不等于能力强2.1 先分清Skills和Agent的关系别把概念搞混Skills的本质是一段可复用的指令、代码或行为模板相当于给Agent配好的一套操作手册。Agent是决策主体Skill是能力模块。很多人在调优时完全不知道从哪下手就是因为把这两个概念混在一起了到底是Agent的决策逻辑出了问题还是Skill本身写得有问题我的经验是先理清层次Agent负责决定做什么Skill负责知道怎么做工具负责实际执行。调优的顺序也是先看Skill数量是否冗余再看工具是否高效最后才回头审视Agent的提示词和流程设计。层次不清的时候你做的很多优化都是在瞎试。2.2 滥装Skills的三个典型症状系统提示被撑爆很多框架会在每次任务开始前把所有Skill的元信息加载进来。Skill装得越多哪怕根本没用上每次请求也都在为它们付token费。选择困难Skill一多模型每次都要思考这个任务该用哪个Skill。如果几个Skill的描述边界模糊它甚至会来回切换白白浪费好几轮。这个过程在日志里看特别明显经常是同一个任务触发了两三个Skill互相覆盖。指令互相打架Skill A说生成图片时优先使用写实风格Skill B说默认输出插画风模型被互相矛盾的指令拉扯最后产出的效果自然不稳定。Skill的数量不是能力的证明而是成本的来源。这句话是我做完第一次瘦身之后最大的感悟。2.3 我是怎么把一个21个Skills的Agent精简到6个的第一步盘点。把项目里所有Skill列出来通过日志统计最近7天每个Skill的实际调用次数。这一看吓了一跳21个Skill里真正被高频调用的只有4个还有9个一次都没被触发过。那9个僵尸Skill直接删掉因为它们除了常年躺在系统提示里占地儿没有任何用处。第二步合并。剩下12个里有一部分功能高度重叠。比如生成产品文案和生成广告语本质上是一类能力合并成一个营销文案生成用参数区分场景。这一步对功能没影响但Skill数量实实在在降下来了。第三步重写触发描述。每个Skill描述里明确写清楚什么情况下使用、什么情况下千万不要使用避免模型把相似任务分配给错误的Skill。这个动作很小但误触发率直接降了一半。最终结果21个减到6个系统提示从大约12k token降到6k单任务token消耗下降了差不多18%。功能没有任何损失效果反而更稳定了。另外提醒一句从社区下载的Skill不要直接丢进生产项目很多只是演示级质量还可能带着一堆跟你的业务完全无关的默认指令。3. 子代理该拆才拆拆了就要拆干净3.1 子代理到底解决了什么问题子代理的核心价值只有三个独立上下文、状态隔离、并行执行。独立上下文子代理有自己的system prompt不受主代理庞杂上下文的干扰。比如一个图片质检子代理只需要极少几条规则就能专注做判断。状态隔离子代理内部状态混乱不会污染主代理让主代理保持干净的决策环境。并行执行多个子代理同时跑整体耗时更短。问题在于很多人把子代理当成了架构升级的象征不管三七二十一先把任务拆成一大堆子代理结果成本曲线直接起飞。3.2 子代理成本失控的经济账子代理的成本主要在两个地方启动成本和上下文传输成本。启动成本很好理解每个子代理被调用时都要把自己的system prompt完整加载一遍。假设一个子代理的system prompt是3000 token调用10次就是30000 token。如果项目里有5个子代理这个数字很容易变成六位数。上下文传输成本更隐蔽。主代理把任务交给子代理时通常需要把相关的背景信息、历史摘要、任务目标全部传过去传得越全这笔费用越高。嵌套层级越深每一层的转述摘要都在损耗信息也在消耗额度。三层嵌套下来任务还没正式开始干几千token已经没了。我的建议是先问这个任务不用子代理行不行再问用了子代理能不能明显提高成功率最后才考虑用。如果两个问题的答案都是否那你就是在为复杂度付钱。3.3 一次主进程退出问题的排查过程这里讲一个真实排查案例。有个项目用headless方式跑子代理结果子代理执行到一半主进程直接退出了。第一反应是子代理代码的问题但看日志发现主进程是正常退出没有崩溃栈。排查链路大概是这样的先看主进程退出码与退出前日志确认是主动退出还是异常退出。再看子代理是否有未捕获异常。结果发现子代理在无界面模式下执行某个工具时抛了异常异常没有向上传递到主进程的处理逻辑。最后确认根因子代理超时策略没设异常把子代理所在的任务队列打挂主进程探测不到子代理心跳后自行退出。修复方案其实很简单给子代理调用包一层异常兜底设置超时时间主进程定期探测子代理状态而不是被动等结果。这类问题在开发期很容易被忽略因为很多框架的示例代码里压根没写异常处理生产环境一跑就露馅。3.4 别被harness和agent的概念绕进去讨论子代理的时候很多人会提到harness。我自己的理解是harness是让Agent跑起来的壳负责请求循环、工具注册、输入输出解析和生命周期管理Agent则是里面的决策逻辑。两者是运行环境和决策实体的关系。很多项目的问题是为了显得架构正规先引入一大套harness能力建了复杂的子代理调度层最后核心业务逻辑没写几行。如果项目本质就是一个循环几个工具函数几个Skill那就老老实实先写轻量实现等任务真的需要隔离和并行时再引入harness和子代理不迟。先跑通再架构而不是先架构再跑通这个顺序几乎能帮你避开一半的复杂度问题。4. 工具优化把每次调用都变成低成本调用4.1 工具描述和Schema优化工具列表是每轮请求都会完整发送给模型的所以工具优化的收益会被乘以请求轮次是整个系统里放大系数最高的优化项。先说描述。工具描述不是写给开发同事看的API文档而是写给模型看的使用说明书。好的描述要回答三个问题这个工具是干什么的什么时候一定要调用它什么时候千万别调用它举个例子查天气的工具可以这样写调用天气查询接口。仅当用户明确表达需要知道天气时调用。不要在用户只是闲聊时调用。再说参数Schema。我见过太多把工具参数设计成多级嵌套对象的情况模型解析这种Schema特别容易出错出错就会重试重试就烧额度。我的习惯是能用字符串解决就不要用数组能用一级对象解决就不要用二级嵌套必填字段尽量控制在1到3个。4.2 工具数量与返回结果瘦身工具数量直接影响模型的选择成本和误触发率。我的经验法则是单个Agent的正常工具数量控制在5到8个超过10个就要考虑合并。同类工具可以合并成一个带type参数的通用方法比如把获取用户信息获取用户订单合并成获取用户数据(type)。数量降下来之后模型的选择空间变小误触发的概率自然就低了。返回结果同样要瘦身。很多后端接口一次性返回几百KB的JSONAgent读完这些数据上下文窗口被塞得满满的后续对话质量下降不说额度也烧得厉害。我的做法是在工具内部做字段筛选只返回模型决策真正需要的字段必要时直接返回一段摘要文本而不是原始JSON。4.3 用流程规则减少无效调用有些Agent像手停不下来的人用户随便问一句今天天气如何它先调用工具去解析用户意图再调用天气接口最后还调一个时间工具确认今天是哪一天。这些多余调用完全可以通过系统提示约束掉。我在系统提示里会写一条固定规则你可以直接回答的问题绝不调用任何工具只有明确需要外部数据或执行动作时才调用工具。就这么一句话工具调用次数能下降一大截。另外建议加上失败回退逻辑同一工具连续失败两次就停止重试直接向用户说明当前状态。重试是隐藏的烧钱机器很多不明不白的额度流失都是无限重试造成的。工具优化的本质是降低模型的不确定性模型越清楚什么时候该用什么工具、不该用什么工具一次成功的概率就越高额度利用率自然越高。5. 拿到20%额度提升的落地清单与复盘5.1 先记录基线再动手没有基线的优化全是耍流氓。动手之前先花两到三天正常使用Agent记录几个核心指标单任务平均token消耗平均请求轮次工具误触发率在工具调用日志里结果是无意义调用的占比失败重试率任务成功率日/周额度消耗后面每一次优化改动都用这些指标去对比才能知道哪项变化来自哪个动作。如果一口气改了好几件事出了问题你根本不知道是哪一步引起的。5.2 五步操作清单这套流程我在几个项目上反复验证过可以直接抄作业冻结新增。优化期间不增加任何新的Skill、子代理、工具先把存量理顺。禁用第三方Skill。只保留项目自己写的核心Skill跑一天观察效果和成本变化。子代理盘点。把每个子代理标注必要性高/中/低和单次平均调用成本简单任务接管回主代理直接做砍掉一半低必要性的子代理。工具重构。同类合并、描述重写、返回结果精简把工具数量控制在8个以内。系统提示减肥。把系统提示压缩到只保留必要原则、关键规则和核心工作流目标是不超过4k token。每一步保留日志不要好几件事同时改。5.3 优化前后数据复盘拿我做过的其中一个项目举例不同项目数据会有差异但趋势是一致的指标优化前优化后变化率系统提示Skill清单约21k token约8k token-62%单任务平均请求轮次11轮7轮-36%工具误触发率23%6%-74%失败重试率17%5%-71%单任务平均token消耗约68k token约42k token-38%月度额度使用100%78%节省22%单任务token消耗下降了38%换算到月度额度就是标题里说的多出至少20%。还有另一个反直觉的结果任务成功率反而从84%升到了91%。原因不难理解——模型不再被一堆冗余Skill、矛盾指令和庞杂上下文干扰决策路径短了犯错的空间也小了。精简不是砍能力是给真正需要的能力让路。5.4 之后怎么持续维持这套低复杂度体系优化不是一次性的项目和任务会变Skill调用频率也会变。我的习惯是每两周做一次用量体检看之前那六个核心指标自动或手动标记低频Skill、低利用率工具、长耗时子代理然后继续做减法。我自己常用一个判断标准如果新增一个Skill或工具不能稳定省下至少一倍的token那就不值得加。用这个标准卡住复杂度基本不会反弹。最后分享一个心态上的体会。我做过这么多Agent项目最普遍的坑不是不会实现功能而是停不下来地加功能。Agent实际能力的上限从来不取决于你给它配了多少工具和Skill而取决于它在需要的时候能不能精准调用最合适的那一个。每次想加新东西之前先花几分钟算一笔账这次任务的固定开销会涨多少误触发概率会不会变高如果答案都是会那这件事大概率就是下一个复杂度税来源。控制住这个冲动额度利用率提升20%是迟早的事项目整体也好维护得多。