做了两年多的大模型应用落地我听过最多的一句感慨就是“Demo跑得飞起一上真业务就拉胯”。尤其是Agent类的应用问题几乎出奇一致慢、贵、还动不动卡死在某个反问循环里。前阵子一个做内部工具链的项目把Agent流程从“能跑”优化到“能扛”中间踩了不少坑也沉淀出一套通用方法。今天就把这套关于“Efficient Agents”的实战经验完整写出来给同样在调教Agent的朋友一点参考。这篇内容解决什么问题一句话在保持Agent能力不变的前提下把端到端延迟、Token消耗、任务成功率三个指标同时做漂亮。适合那些已经跑通过一个简单Agent Demo、想往真实业务场景里迁移的开发者和个人技术负责人。1. 先对齐概念高效Agent到底在优化什么1.1 三个核心指标聊“高效”之前我一直要求团队成员先把目标量化。毕竟谁都可以说自己“优化了一下”但到底优化了什么、提升了多少没有指标全是空谈。我自己的实践里看三个指标就够了任务成功率准备一组固定的测试任务跑100次统计在允许的步骤数内完成并产出合格结果的比例。没有这个指标你后面做的所有“加速”都可能是假象。端到端延迟从用户提交请求到拿到最终结果的完整耗时。这里要盯的是P50和P95只看平均值会被异常值骗到。单位成本每完成1000次真实任务平均消耗的Token数、API调用次数和推理时长。成本在C端产品和内部工具里都是硬约束尤其跨系统调用多了之后账单增长远超预期。这三个指标之间往往是矛盾的你为了追求成功率让Agent多做推理、多调工具延迟和成本就会上去你为了降Token拼命压缩上下文模型在关键决策点信息不足就会反复追问反而更慢。所以“高效Agent”的优化不是某个单点的极致而是这三个线上找一个合理的平衡点。1.2 常见误区快不等于省省不等于稳我见过挺多团队一上来就追求“快”把模型换成最快的轻量版本把系统提示词压缩到只剩下两三行。结果是什么模型开始频繁误解任务边界经常把本该一次完成的调用拆成三次甚至五次中间还不停地反问用户。表面上看每一次推理都快了但端到端反而更慢Token总数也更多。反过来也有人为了“稳”把每个任务都丢给最强型号的大模型上下文里塞满全套规则和历史记录。这样做的成功率确实高但响应时间动辄几十秒成本是普通场景的几十倍完全没法规模化。这两个误区本质上是同一个问题没有区分任务的难度层级。搞高效Agent第一步就是破除“一刀切”的思维不再用同一种模型、同一个提示词、同一套流程去处理所有请求。2. 架构设计选对形态效率才谈得上2.1 单Agent的适用边界很多教程一上讲Agent就给你上“多智能体协作”好像不拆成三五个角色就没水平。但以我的实际经验大部分业务场景用单Agent效率反而最高。单Agent的适用边界很清晰任务链路相对固定、分支少、目标能用一两句话说清。比如“读取上传的文件按规则抽取出字段填进表格并返回结果”这种任务就是单一执行循环的最佳舞台。模型负责理解需求、调用工具、汇总输出不需要角色切换不需要多轮交接上下文也不会被反复复制。有个项目伙伴曾经坚持把一个数据清洗任务拆成“数据理解Agent”“清洗规则Agent”“质检Agent”三个角色结果单次任务的上下文从6000 Token飙升到19000 Token耗时增加了三倍成功率却没有本质提升。后来改回单Agent同时把工具和提示词打磨好效果反而更好。这件事给我的教训是多Agent是手段不是目的拆之前先问问自己这个任务里的哪个环节真的需要一套独立的推理上下文2.2 多Agent编排何时才值得多Agent不是不能上但必须踩中适用的场景。我总结下来值得拆的情况大概有三种一是子任务之间的上下文需求差异极大。比如一个Agent只需要处理高度结构化的数字计算另一个需要理解长文本的背景和意图两者塞进同一个上下文里一是浪费大量Token二是互相干扰。拆开后各用各的上下文反而能同时降低消耗和出错概率。二是子任务可以并行执行。比如市场调研任务里“整理竞品价格”“收集用户反馈”“梳理行业动态”三块没有严格先后关系用一个Agent串行执行就是纯浪费时间。拆成多个Agent并行跑最后汇总端到端延迟能砍掉一大半。三是需要不同安全权限或隔离策略。内部工具里有的Agent只允许读数据库有的允许写文件拆开之后可以在各自的外层做权限控制比在一个流程里塞各种条件判断清晰得多。2.3 形态选择对照表我整理了一张简单的对照表方便快速判断该用哪种形态形态典型场景效率特点需要警惕的风险单Agent数据处理、简单问答、单工具调用上下文开销小链路短调试简单任务复杂时容易陷入长循环多Agent串行分阶段处理的长流程角色边界清晰各阶段可用不同模型阶段交接有损耗总耗时偏高多Agent并行相互独立的子任务延迟显著下降利用率高结果合并逻辑要写好否则白算混合模式先路由后处理的复杂业务按难度分配资源整体性价比最高路由准确性直接影响上限老实说混合模式才是我在真实业务里最常用的。先让一个轻量分类器判断任务类型再决定走单Agent快速通道还是走多Agent并行通道。这个思路后面第4节会讲得更细。3. 把效率磨进细节提示词、工具、模型与运行层3.1 提示词层让Agent少做无用功我见过太多提示词写得像议论文一段一段摆道理。大模型确实能读懂长文本但提示词越长决策时候的注意力就越分散Token成本也越高。做高效Agent提示词层必须动刀。第一把“少说废话”从想象变成硬约束。比如不要只在开头写一句“你是一个高效助手”然后指望模型自觉。要明确写出“每一步执行前先判断这一步是否直接产出最终用户需要的答案如果不是不要调用工具。”这种结构化的约束效果比一千字的道德劝导强得多。第二给Agent一个明确的停止条件。很多Agent卡死是因为它不知道自己什么时候算“做完”。你需要在系统提示词里写清楚“当你拿到足够生成最终答复的数据时立即停止调用工具直接输出答案。”同时在外层代码里加一个最大步数保护两个都做才算是把兜底补齐。第三用示例替代长篇解释。与其写“如果用户问的是天气你应该调用天气查询接口并把气温和降水信息结合起来回答”不如直接给两条对话示例让模型照着来。示例的Token开销远小于解释性文字约束效果却更好。3.2 工具层工具列表是搜索空间不是书架工具层是效率优化的重灾区。不少项目为了让Agent显得能力强一次暴露几十个工具结果模型光是从工具列表里挑工具就要消耗大量Token偶尔还会挑错。我的习惯是给Agent暴露多少工具取决于当前任务需要多少。如果路由已经判断出这是一个“查订单”请求那Agent只需要看到查询订单相关的几个工具其他工具全部藏起来。工具列表膨胀是隐性的效率杀手它不直接体现在单次调用里但乘上几十轮交互Token消耗非常可观。工具描述也要短而准。那种几百字的小作文式工具说明跟提示词一样会稀释模型注意力。每条工具描述控制在50字以内说清楚“这个工具干什么、适合在什么时候调用”就够。我改过一个案例工具描述从平均180字压缩到45字工具选择准确率反而提升了因为模型不再被无关细节干扰。另一个容易漏掉的点是工具结果缓存。同样是查询同一个用户余额的调用Agent在一天里可能触发几十次。我在工具层外面包了一层缓存对参数完全相同且结果时效性要求不高的请求直接返回缓存结果既省了API调用又压了延迟。这个优化成本极低见效却非常直接。3.3 模型层小模型先试大模型兜底“Efficient Agents”里最核心的资源调度逻辑是让便宜的模型干便宜的活让贵的模型干精细的活。具体落地靠两条路。第一路由前置。在Agent正式进入推理循环之前先用一个轻量模型对请求做分类判断任务类型和难度。分类任务不需要多强的推理能力轻量模型足够胜任成本可以忽略。这叫花小钱省大钱。第二动态升级。不是所有请求都需要最强模型来处理。比如“查天气”这种直接调用工具的请求用轻量模型就能完成但“根据三年的销售数据给出下季度备货建议”这种任务就必须上强推理模型。我在流程里加了一个难度评分器根据输入长度、问题复杂度、是否需要多步推理来决定用哪档模型而不是让所有流量都走最贵的通道。有人担心轻量模型会拉低整体质量。我的经验是在路由准确的前提下85%的请求根本用不到强推理强行上强模型只是白花钱。剩下的15%有难度波动再用强模型兜底整体质量不会下降成本却能降一个数量级。3.4 运行层流式、并行与批处理的降维打击模型层和工具层优化完还要看程序本身的并发能力。很多Agent应用慢纯粹是架构上的串行阻塞。一个最直接的改动是流式输出。用户在页面上等待时,如果大模型还在心里憋完整套答案再一次性吐出来体验感极差。同样一个30秒才能生成完的回复改成流式逐字输出后用户感知到的等待时间会短很多。这个优化不改变任何逻辑只改传输方式属于必做的白送项。第二个改动是工具调用的并行化。Agent在某一轮决策中可能需要同时查库存、查价格、查物流时效这三个工具调用彼此独立。代码里如果写成串行等待每一个都要等一次接口往返改成并行后总耗时约等于最慢的那一个。这个改动需要对Agent框架做一点定制很多通用框架默认是串行执行工具调用的值得花时间改造。第三是批处理。内部工具里经常有一批相同的任务比如“给100个客户生成定制问候语”。如果一个个跑Agent流程等于重复支付了100次的系统提示词和启动开销。改成先提取公共信息、统一规划再批量生成成本能省下60%以上。4. 实操一次Agent性能改造实录4.1 原始流程为什么又慢又贵前阵子参与的一个内部项目任务描述是“根据用户输入的销售周报原始数据自动读取相关文件、核对数字、生成摘要并输出到指定格式”。听起来不复杂但实测下来让人头大平均端到端延迟45秒单次任务平均消耗约2.8万Token成功率只有68%。问题出在哪我们对着日志一帧一帧地看发现问题集中在三处。一是流程没有分层所有请求统一走最强推理模型系统提示词里塞了一整套企业规范单是固定的系统上下文就占了接近5000 Token。二是工具暴露过多Agent每轮决策都要从几十个工具里挑。经常出现第一轮选了“读取文件”第二轮又去翻“查询文件列表”重复探索浪费时间。三是缺少提前预取。任务本身有很强的固定模式数据文件路径和字段格式都是约定好的但每次执行Agent都要重新理解一遍等于每次都在第一次见面的状态下去猜路径。这三点叠加起来结果就是每一步都很慢每一步都很贵而且越往后上下文越长模型推理越吃力成功率自然上不去。4.2 改造后的链路设计我们没有推翻整个系统只是重新排了任务流。改造后的链路分成四段第一段路由分类。先用轻量模型判断这次请求属于“周报生成”“月报汇总”还是“其他”。这一步只需要非常便宜的候选模型一次调用返回一个分类标签即可。第二段模板预取。既然任务类型已经确定那就直接根据类型加载对应的文件模板、字段映射和规范约束不再让Agent自己摸索。比如周报任务直接告诉Agent“数据源文件路径和字段说明给你了你只需要按部就班处理”省去了搜索和猜测的时间。第三段工具收敛。在模板预取之后系统只向Agent暴露与当前任务相关的2到3个工具其余工具全部隐藏。Agent不用再做选择题直接进入执行阶段。第四段结果校验与补跑。Agent生成结果后不直接交付先走一步轻量校验检查数字字段是否齐全、格式是否符合约定。校验不过才重新进入一次修正循环修正次数上限设为两次避免无限兜圈子。4.3 实测数据与关键心得改造后我们对同一组100个测试任务做了复测结果如下指标改造前改造后提升幅度端到端延迟P5045秒11秒降低约75%单任务Token消耗2.8万0.9万降低约68%任务成功率68%91%提升约34%超时任务占比14%3%降低约78%这个结果让团队挺振奋的尤其是成功率不降反升。原因也好理解Agent把原来浪费在“理解模板、选工具、猜路径”上面的精力全部转移到真正的数据处理上输出质量自然更高。一个关键心得是很多Agent效率问题藏在“背景知识重复灌输”上。同一个业务任务每次执行都把规范从头讲一遍既慢又不稳。把稳定不变的背景信息拆到模板或预取层里只把每次变化的输入交给AgentToken消耗和延迟立刻能降下来。5. 常见问题与排查技巧实录5.1 无限循环与无意义追问现象Agent陷入某一轮工具调用和结果分析的死循环日志里反复出现相同或相似的工具调用直到触发步数上限。这类问题八成是停止条件没写清楚。排查时先看系统提示词里是否明确了“拿到足够信息就停止”再看外层代码有没有设置硬性的最大步数。这两个都做了剩下的就是工具输出质量问题工具返回的结果格式不规整模型没法判断数据是否满足要求才会一遍遍重试。我当时还加了一个去重机制如果Agent计划调用的工具和参数与最近两轮完全一致就直接中断并读取上一轮结果不让它做无用功。5.2 Token消耗凭空暴涨现象功能没变账单却连续数周上涨。排查思路分几步走。先看上下文里的历史记录有没有无限累积。很多框架默认会把每轮工具结果全量保留导致对话跑到后面模型每次读上下文都在处理早已无用的历史垃圾。我一般会做上下文压缩超过一定轮数后把早期工具结果替换成一行摘要。再看工具返回结果是否被过度截留。有个项目里一个查询接口一次返回200行数据Agent只需要其中5行但每轮都要把200行全部塞回上下文。我让工具层负责人做了字段裁剪只回传请求中实际需要的字段。Token消耗立刻砍了四成。最后看单日调用次数分布如果某个时段调用量特别高可能是路由分类没生效大量简单请求走了强模型通道需要回去调路由阈值。5.3 延迟与成功率的矛盾怎么权衡有些任务不管你压得多狠成功率就是上不去。我建议此时先接受“这件任务本身就该贵”的结论然后把有限的资源用在刀刃上。一个实际的例子同样是销售数据汇总模板固定的周报走轻量链路自由问答的临时分析走重型链路两者分开计费、分开限流。不要拿重型链路处理所有请求否则简单任务被拖慢复杂任务又因为排队而超时。这本质上是用分层思路去接收延迟与成功率的矛盾而不是在同一个链路上反复拉锯。5.4 问题排查速查表现象优先排查点常用解法响应慢是否串行调用多个工具并行化改造、流式输出Token暴涨上下文是否无限累积轮数摘要、字段裁剪成功率低停止条件与工具描述是否清晰明确停止条件、压缩工具描述反复追问模板与背景知识是否重复灌输模板预取、路由前置简单请求也贵是否所有流量走强模型加难度评分、动态选模型接口超时工具外层是否缺乏超时控制设置超时熔断、快速失败这套速查表我现在打印出来贴在工位上遇到新问题先按表格里的顺序排查能省下不少瞎猜的时间。最后再分享一个个人体会。做“Efficient Agents”这件事最忌讳的就是盯着单点埋头调参今天压一点Token明天换一个模型后天改两句提示词。我踩过的坑告诉我效率提升是一个系统问题必须先把架构分层的骨架搭好再去磨每一层的细节。尤其是路由前置和工具收敛这两步只要做对了后面所有的优化事半功倍。如果你手头有一个跑得起来但不太好看的Agent项目不用急着推翻重写先拿一张纸画出它现在每一步的链路标出哪些步骤在重复理解、哪些调用是串行的、哪些上下文是被白白复制的改完这三处你大概率会看到明显的质变。
做了两年多的大模型应用落地我听过最多的一句感慨就是“Demo跑得飞起一上真业务就拉胯”。尤其是Agent类的应用问题几乎出奇一致慢、贵、还动不动卡死在某个反问循环里。前阵子一个做内部工具链的项目把Agent流程从“能跑”优化到“能扛”中间踩了不少坑也沉淀出一套通用方法。今天就把这套关于“Efficient Agents”的实战经验完整写出来给同样在调教Agent的朋友一点参考。这篇内容解决什么问题一句话在保持Agent能力不变的前提下把端到端延迟、Token消耗、任务成功率三个指标同时做漂亮。适合那些已经跑通过一个简单Agent Demo、想往真实业务场景里迁移的开发者和个人技术负责人。1. 先对齐概念高效Agent到底在优化什么1.1 三个核心指标聊“高效”之前我一直要求团队成员先把目标量化。毕竟谁都可以说自己“优化了一下”但到底优化了什么、提升了多少没有指标全是空谈。我自己的实践里看三个指标就够了任务成功率准备一组固定的测试任务跑100次统计在允许的步骤数内完成并产出合格结果的比例。没有这个指标你后面做的所有“加速”都可能是假象。端到端延迟从用户提交请求到拿到最终结果的完整耗时。这里要盯的是P50和P95只看平均值会被异常值骗到。单位成本每完成1000次真实任务平均消耗的Token数、API调用次数和推理时长。成本在C端产品和内部工具里都是硬约束尤其跨系统调用多了之后账单增长远超预期。这三个指标之间往往是矛盾的你为了追求成功率让Agent多做推理、多调工具延迟和成本就会上去你为了降Token拼命压缩上下文模型在关键决策点信息不足就会反复追问反而更慢。所以“高效Agent”的优化不是某个单点的极致而是这三个线上找一个合理的平衡点。1.2 常见误区快不等于省省不等于稳我见过挺多团队一上来就追求“快”把模型换成最快的轻量版本把系统提示词压缩到只剩下两三行。结果是什么模型开始频繁误解任务边界经常把本该一次完成的调用拆成三次甚至五次中间还不停地反问用户。表面上看每一次推理都快了但端到端反而更慢Token总数也更多。反过来也有人为了“稳”把每个任务都丢给最强型号的大模型上下文里塞满全套规则和历史记录。这样做的成功率确实高但响应时间动辄几十秒成本是普通场景的几十倍完全没法规模化。这两个误区本质上是同一个问题没有区分任务的难度层级。搞高效Agent第一步就是破除“一刀切”的思维不再用同一种模型、同一个提示词、同一套流程去处理所有请求。2. 架构设计选对形态效率才谈得上2.1 单Agent的适用边界很多教程一上讲Agent就给你上“多智能体协作”好像不拆成三五个角色就没水平。但以我的实际经验大部分业务场景用单Agent效率反而最高。单Agent的适用边界很清晰任务链路相对固定、分支少、目标能用一两句话说清。比如“读取上传的文件按规则抽取出字段填进表格并返回结果”这种任务就是单一执行循环的最佳舞台。模型负责理解需求、调用工具、汇总输出不需要角色切换不需要多轮交接上下文也不会被反复复制。有个项目伙伴曾经坚持把一个数据清洗任务拆成“数据理解Agent”“清洗规则Agent”“质检Agent”三个角色结果单次任务的上下文从6000 Token飙升到19000 Token耗时增加了三倍成功率却没有本质提升。后来改回单Agent同时把工具和提示词打磨好效果反而更好。这件事给我的教训是多Agent是手段不是目的拆之前先问问自己这个任务里的哪个环节真的需要一套独立的推理上下文2.2 多Agent编排何时才值得多Agent不是不能上但必须踩中适用的场景。我总结下来值得拆的情况大概有三种一是子任务之间的上下文需求差异极大。比如一个Agent只需要处理高度结构化的数字计算另一个需要理解长文本的背景和意图两者塞进同一个上下文里一是浪费大量Token二是互相干扰。拆开后各用各的上下文反而能同时降低消耗和出错概率。二是子任务可以并行执行。比如市场调研任务里“整理竞品价格”“收集用户反馈”“梳理行业动态”三块没有严格先后关系用一个Agent串行执行就是纯浪费时间。拆成多个Agent并行跑最后汇总端到端延迟能砍掉一大半。三是需要不同安全权限或隔离策略。内部工具里有的Agent只允许读数据库有的允许写文件拆开之后可以在各自的外层做权限控制比在一个流程里塞各种条件判断清晰得多。2.3 形态选择对照表我整理了一张简单的对照表方便快速判断该用哪种形态形态典型场景效率特点需要警惕的风险单Agent数据处理、简单问答、单工具调用上下文开销小链路短调试简单任务复杂时容易陷入长循环多Agent串行分阶段处理的长流程角色边界清晰各阶段可用不同模型阶段交接有损耗总耗时偏高多Agent并行相互独立的子任务延迟显著下降利用率高结果合并逻辑要写好否则白算混合模式先路由后处理的复杂业务按难度分配资源整体性价比最高路由准确性直接影响上限老实说混合模式才是我在真实业务里最常用的。先让一个轻量分类器判断任务类型再决定走单Agent快速通道还是走多Agent并行通道。这个思路后面第4节会讲得更细。3. 把效率磨进细节提示词、工具、模型与运行层3.1 提示词层让Agent少做无用功我见过太多提示词写得像议论文一段一段摆道理。大模型确实能读懂长文本但提示词越长决策时候的注意力就越分散Token成本也越高。做高效Agent提示词层必须动刀。第一把“少说废话”从想象变成硬约束。比如不要只在开头写一句“你是一个高效助手”然后指望模型自觉。要明确写出“每一步执行前先判断这一步是否直接产出最终用户需要的答案如果不是不要调用工具。”这种结构化的约束效果比一千字的道德劝导强得多。第二给Agent一个明确的停止条件。很多Agent卡死是因为它不知道自己什么时候算“做完”。你需要在系统提示词里写清楚“当你拿到足够生成最终答复的数据时立即停止调用工具直接输出答案。”同时在外层代码里加一个最大步数保护两个都做才算是把兜底补齐。第三用示例替代长篇解释。与其写“如果用户问的是天气你应该调用天气查询接口并把气温和降水信息结合起来回答”不如直接给两条对话示例让模型照着来。示例的Token开销远小于解释性文字约束效果却更好。3.2 工具层工具列表是搜索空间不是书架工具层是效率优化的重灾区。不少项目为了让Agent显得能力强一次暴露几十个工具结果模型光是从工具列表里挑工具就要消耗大量Token偶尔还会挑错。我的习惯是给Agent暴露多少工具取决于当前任务需要多少。如果路由已经判断出这是一个“查订单”请求那Agent只需要看到查询订单相关的几个工具其他工具全部藏起来。工具列表膨胀是隐性的效率杀手它不直接体现在单次调用里但乘上几十轮交互Token消耗非常可观。工具描述也要短而准。那种几百字的小作文式工具说明跟提示词一样会稀释模型注意力。每条工具描述控制在50字以内说清楚“这个工具干什么、适合在什么时候调用”就够。我改过一个案例工具描述从平均180字压缩到45字工具选择准确率反而提升了因为模型不再被无关细节干扰。另一个容易漏掉的点是工具结果缓存。同样是查询同一个用户余额的调用Agent在一天里可能触发几十次。我在工具层外面包了一层缓存对参数完全相同且结果时效性要求不高的请求直接返回缓存结果既省了API调用又压了延迟。这个优化成本极低见效却非常直接。3.3 模型层小模型先试大模型兜底“Efficient Agents”里最核心的资源调度逻辑是让便宜的模型干便宜的活让贵的模型干精细的活。具体落地靠两条路。第一路由前置。在Agent正式进入推理循环之前先用一个轻量模型对请求做分类判断任务类型和难度。分类任务不需要多强的推理能力轻量模型足够胜任成本可以忽略。这叫花小钱省大钱。第二动态升级。不是所有请求都需要最强模型来处理。比如“查天气”这种直接调用工具的请求用轻量模型就能完成但“根据三年的销售数据给出下季度备货建议”这种任务就必须上强推理模型。我在流程里加了一个难度评分器根据输入长度、问题复杂度、是否需要多步推理来决定用哪档模型而不是让所有流量都走最贵的通道。有人担心轻量模型会拉低整体质量。我的经验是在路由准确的前提下85%的请求根本用不到强推理强行上强模型只是白花钱。剩下的15%有难度波动再用强模型兜底整体质量不会下降成本却能降一个数量级。3.4 运行层流式、并行与批处理的降维打击模型层和工具层优化完还要看程序本身的并发能力。很多Agent应用慢纯粹是架构上的串行阻塞。一个最直接的改动是流式输出。用户在页面上等待时,如果大模型还在心里憋完整套答案再一次性吐出来体验感极差。同样一个30秒才能生成完的回复改成流式逐字输出后用户感知到的等待时间会短很多。这个优化不改变任何逻辑只改传输方式属于必做的白送项。第二个改动是工具调用的并行化。Agent在某一轮决策中可能需要同时查库存、查价格、查物流时效这三个工具调用彼此独立。代码里如果写成串行等待每一个都要等一次接口往返改成并行后总耗时约等于最慢的那一个。这个改动需要对Agent框架做一点定制很多通用框架默认是串行执行工具调用的值得花时间改造。第三是批处理。内部工具里经常有一批相同的任务比如“给100个客户生成定制问候语”。如果一个个跑Agent流程等于重复支付了100次的系统提示词和启动开销。改成先提取公共信息、统一规划再批量生成成本能省下60%以上。4. 实操一次Agent性能改造实录4.1 原始流程为什么又慢又贵前阵子参与的一个内部项目任务描述是“根据用户输入的销售周报原始数据自动读取相关文件、核对数字、生成摘要并输出到指定格式”。听起来不复杂但实测下来让人头大平均端到端延迟45秒单次任务平均消耗约2.8万Token成功率只有68%。问题出在哪我们对着日志一帧一帧地看发现问题集中在三处。一是流程没有分层所有请求统一走最强推理模型系统提示词里塞了一整套企业规范单是固定的系统上下文就占了接近5000 Token。二是工具暴露过多Agent每轮决策都要从几十个工具里挑。经常出现第一轮选了“读取文件”第二轮又去翻“查询文件列表”重复探索浪费时间。三是缺少提前预取。任务本身有很强的固定模式数据文件路径和字段格式都是约定好的但每次执行Agent都要重新理解一遍等于每次都在第一次见面的状态下去猜路径。这三点叠加起来结果就是每一步都很慢每一步都很贵而且越往后上下文越长模型推理越吃力成功率自然上不去。4.2 改造后的链路设计我们没有推翻整个系统只是重新排了任务流。改造后的链路分成四段第一段路由分类。先用轻量模型判断这次请求属于“周报生成”“月报汇总”还是“其他”。这一步只需要非常便宜的候选模型一次调用返回一个分类标签即可。第二段模板预取。既然任务类型已经确定那就直接根据类型加载对应的文件模板、字段映射和规范约束不再让Agent自己摸索。比如周报任务直接告诉Agent“数据源文件路径和字段说明给你了你只需要按部就班处理”省去了搜索和猜测的时间。第三段工具收敛。在模板预取之后系统只向Agent暴露与当前任务相关的2到3个工具其余工具全部隐藏。Agent不用再做选择题直接进入执行阶段。第四段结果校验与补跑。Agent生成结果后不直接交付先走一步轻量校验检查数字字段是否齐全、格式是否符合约定。校验不过才重新进入一次修正循环修正次数上限设为两次避免无限兜圈子。4.3 实测数据与关键心得改造后我们对同一组100个测试任务做了复测结果如下指标改造前改造后提升幅度端到端延迟P5045秒11秒降低约75%单任务Token消耗2.8万0.9万降低约68%任务成功率68%91%提升约34%超时任务占比14%3%降低约78%这个结果让团队挺振奋的尤其是成功率不降反升。原因也好理解Agent把原来浪费在“理解模板、选工具、猜路径”上面的精力全部转移到真正的数据处理上输出质量自然更高。一个关键心得是很多Agent效率问题藏在“背景知识重复灌输”上。同一个业务任务每次执行都把规范从头讲一遍既慢又不稳。把稳定不变的背景信息拆到模板或预取层里只把每次变化的输入交给AgentToken消耗和延迟立刻能降下来。5. 常见问题与排查技巧实录5.1 无限循环与无意义追问现象Agent陷入某一轮工具调用和结果分析的死循环日志里反复出现相同或相似的工具调用直到触发步数上限。这类问题八成是停止条件没写清楚。排查时先看系统提示词里是否明确了“拿到足够信息就停止”再看外层代码有没有设置硬性的最大步数。这两个都做了剩下的就是工具输出质量问题工具返回的结果格式不规整模型没法判断数据是否满足要求才会一遍遍重试。我当时还加了一个去重机制如果Agent计划调用的工具和参数与最近两轮完全一致就直接中断并读取上一轮结果不让它做无用功。5.2 Token消耗凭空暴涨现象功能没变账单却连续数周上涨。排查思路分几步走。先看上下文里的历史记录有没有无限累积。很多框架默认会把每轮工具结果全量保留导致对话跑到后面模型每次读上下文都在处理早已无用的历史垃圾。我一般会做上下文压缩超过一定轮数后把早期工具结果替换成一行摘要。再看工具返回结果是否被过度截留。有个项目里一个查询接口一次返回200行数据Agent只需要其中5行但每轮都要把200行全部塞回上下文。我让工具层负责人做了字段裁剪只回传请求中实际需要的字段。Token消耗立刻砍了四成。最后看单日调用次数分布如果某个时段调用量特别高可能是路由分类没生效大量简单请求走了强模型通道需要回去调路由阈值。5.3 延迟与成功率的矛盾怎么权衡有些任务不管你压得多狠成功率就是上不去。我建议此时先接受“这件任务本身就该贵”的结论然后把有限的资源用在刀刃上。一个实际的例子同样是销售数据汇总模板固定的周报走轻量链路自由问答的临时分析走重型链路两者分开计费、分开限流。不要拿重型链路处理所有请求否则简单任务被拖慢复杂任务又因为排队而超时。这本质上是用分层思路去接收延迟与成功率的矛盾而不是在同一个链路上反复拉锯。5.4 问题排查速查表现象优先排查点常用解法响应慢是否串行调用多个工具并行化改造、流式输出Token暴涨上下文是否无限累积轮数摘要、字段裁剪成功率低停止条件与工具描述是否清晰明确停止条件、压缩工具描述反复追问模板与背景知识是否重复灌输模板预取、路由前置简单请求也贵是否所有流量走强模型加难度评分、动态选模型接口超时工具外层是否缺乏超时控制设置超时熔断、快速失败这套速查表我现在打印出来贴在工位上遇到新问题先按表格里的顺序排查能省下不少瞎猜的时间。最后再分享一个个人体会。做“Efficient Agents”这件事最忌讳的就是盯着单点埋头调参今天压一点Token明天换一个模型后天改两句提示词。我踩过的坑告诉我效率提升是一个系统问题必须先把架构分层的骨架搭好再去磨每一层的细节。尤其是路由前置和工具收敛这两步只要做对了后面所有的优化事半功倍。如果你手头有一个跑得起来但不太好看的Agent项目不用急着推翻重写先拿一张纸画出它现在每一步的链路标出哪些步骤在重复理解、哪些调用是串行的、哪些上下文是被白白复制的改完这三处你大概率会看到明显的质变。
