先说个我自己的观察每次有人在群里问“Agent 效果不行怎么办”下面大概率会有人回一句“换 Claude/GPT-4o 吧”然后预算就这么上去了。但等真换了贵模型效果提升往往没想象中大甚至有时候问题依旧。这不是个例我见过好几个团队为了把 Agent 调好API 账单从几百美金烧到几千美金最后发现瓶颈根本不在模型本身。这篇内容就是来拆这件事的Agent 表现不佳到底什么时候该换模型什么时候换了也白换。以及在不换模型的前提下还有哪些手段能把 Agent 的能力往上推一大截。我尽量按实际项目里踩过的坑来写不是理论堆砌适合正在做 Agent 开发、或者打算做 Agent 但预算有限的团队参考。1. 有能力上限的不只是模型整个系统才是瓶颈1.1 模型能力的“虚高”与工程能力的“缺失”先明确一个事实现在的模型能力确实在快速膨胀尤其是顶级闭源模型Reasoning推理能力比两年前强了不止一个量级。但 Agent 是一个系统不是单个模型。一个 Agent 至少由模型、提示词、工具调用、记忆模块、上下文管理、编排逻辑、反馈循环这几部分组成。模型只是其中一个“处理器”剩下的部分决定了这个处理器能发挥多少性能。打个比方你给一个赛车手换台发动机确实会快一点。但如果赛道规划是乱的、导航是错的、油料供给不稳定换再强的发动机也跑不过一个路线规划合理的小排量车。Agent 的工程化程度本质上就是那条赛道和导航系统。我在实际项目里测过同一个模型在两个不同编排方案下的效果差异同样是用某个开源模型一个方案是“单轮问答简单工具”另一个方案是“计划-执行-反思循环记忆分步上下文”任务完成率差了将近 40 个百分点。这说明什么说明很多时候不是模型不行是系统没把模型的潜力发挥出来。1.2 三个最典型的“伪瓶颈”我在排查 Agent 问题时发现大多数效果不佳可以归到下面三类原因这三类原因都容易被误判为“模型太弱”。第一个是任务表述不清。你让 Agent“处理一下这个文件”它怎么处理提取信息改写格式还是做总结如果任务本身是模糊的模型就只能靠猜猜错了自然显得“笨”。这种情况换个贵模型也未必有改善因为贵模型同样是在猜。第二个是上下文污染。Agent 运行过程中如果上下文里塞满了无关日志、历史对话片段、残缺工具返回结果关键信息会被稀释。模型注意力是有限的上下文一长它就容易忽略真正重要的内容。你可以想象一个考生试卷上密密麻麻全是无关信息正确答案只藏在第三页的一个角落里——他再聪明也容易漏看。第三个是工具调用设计不合理。模型确实会调用工具但如果你的工具定义写得含糊、参数描述不清晰、工具数量过多模型就很容易选错工具或传错参数。这种情况也常被归结为“模型不会用工具”实际上换个模型也大概率会犯同样的错。所以在决定“换更贵的模型”之前先自己做一轮排查把这三个位置理清楚。很多项目在完成这一步之后效果就已经上来了根本不需要动模型。2. 不换模型先从提示词和上下文窗口里挤出红利2.1 提示词优化的杠杆效应提示词是老生常谈但大多数项目的提示词其实写得很糙。糙在哪不是文采不好而是结构性信息缺失。一个合格的 Agent 提示词至少应该包含角色定位、任务目标、输入信息、约束条件、输出格式、失败处理方式这几块。缺了任何一块模型就只能靠概率去“猜”你不会写的那部分。比如一个客户支持 Agent如果你的提示词只是“你是客服请回答用户问题”那模型答得好不好全看运气。但如果你把处理流程写清楚——“先判断用户情绪再识别问题类型然后检索知识库最后按标准格式回复”模型的表现会立刻上一个台阶。这一点不换模型也能做到只是很多人懒得写。我还会建议在提示词里加入“显式推理”要求让模型先列出思考过程再给结论。这招对开源小模型尤其有用。相比直接让模型给答案显式推理像是把计算过程写出来能大幅降低低级错误率。代价是会多一些 Token但相比换模型这个成本几乎可以忽略。2.2 用检索增强代替“背题”知识不够不等于智力不够很多 Agent 表现不佳是因为知识不够而不是推理能力不够。你让它回答一个行业专有名词、一个内部产品细节、一个最新政策如果这些内容不在训练数据里它当然答不出来。这种场景换模型基本没用除非你换到最新、训练数据恰好包含这些内容的模型——但这是碰运气不靠谱。正确的解法是检索增强RAG。把经常被问到的知识做成知识库按需检索后拼接到上下文里。我在几个项目里做过对比同一个模型加了 RAG 之后准确率提升了 20% 以上而换更贵的模型最多提升 5%。在知识密集型的任务里资料补给远比重型武器更有用。但这有个前提检索质量要过关。检索的切分策略、向量模型选择、重排机制、召回数量每一个环节都会影响最终效果。如果你把整个知识库胡乱切块塞进向量库就完事那检索到的内容大概率是残缺或者跑偏的Agent 拿到错误资料答得反而更差。具体怎么做我会在第 4 章展开。2.3 记忆系统是“记性好”的 Agent 的底牌很多 Agent 方案里记忆几乎是被忽视的。会话一结束所有状态清零下次用户来了又得重新交代一遍自己的需求。这种 Agent 的表现当然不会太好——你让一个每 10 分钟就失忆的人去办事他能办多好记忆系统分为短期记忆和长期记忆。短期记忆处理当前会话内的多轮上下文长期记忆存储跨会话的用户偏好、历史决策、常用参数。有了记忆Agent 不用每次重新推理可以直接复用之前的结果。这一点对模型的要求很低对架构的要求很高。我见过一个项目用一个极小的模型做 Agent但给它配了完善的长期记忆系统效果居然超过了直接用大模型但无记忆的方案。原因很简单它把“每次重新思考”变成了“从记忆中读取并增量更新”工作量降了一大截出错概率自然也就降了。记忆系统的构建不算复杂一个向量库加一个读写封装就能跑起来但收益异常明显。3. 编排层才是 Agent 变强的真正杠杆3.1 任务分解把复杂问题拆成简单问题如果一个任务本身很复杂模型一次性完成的效果通常比不上拆成几步逐步完成。这是我在多个 Agent 项目里反复验证过的结论。复杂任务对模型的要求是“统筹执行校验”一把抓这对任何模型来说都是高负担。而拆解之后每一步只需要做一个相对简单的事情模型出错概率会显著下降。你可以把任务分解看作“多人协作”。一个人既要谈判又要写合同还要做尽职调查容易忙中出错但如果是团队协作各司其职最终质量会稳得多。Agent 的任务分解就是这个逻辑用一个规划模块把任务拆成子步骤再用执行模块逐项完成最后汇总校验。我在实践中通常用两层结构第一层是规划器负责把用户请求拆成可执行的子任务第二层是执行器负责完成每个子任务。规划器可以用稍微强一点的模型执行器则可以用便宜的小模型。这样既保证了任务理解能力又控制了整体成本。细心的读者会发现这种结构下“换更贵的模型”的意义就被稀释了——因为真正需要强模型的部分只剩下了规划这一个小环节。3.2 工具调用的设计常见细节决定成败工具调用是 Agent 连接外部世界的桥梁但这里的坑非常多。最大的坑是工具定义太“贪心”。一个工具试图覆盖所有场景参数十几个描述含糊其辞——模型被搞晕的概率极高。正确做法是拆小工具、写清描述、减少参数冗余。例如你做一个订单管理 Agent与其设计一个“根据多个条件查询订单”的大工具不如拆成“按订单号查询”“按用户查询”“按时间范围查询”三个小工具。每个工具的描述都精确到“输入什么、输出什么、什么时候用这个工具”模型的选择准确率会大幅提升。这个道理很简单但绝大多数项目做不到因为开发图省事一个工具搞定所有查询。另一个关键是工具返回信息的质量。工具返回的原始数据往往夹杂大量无关字段直接塞进上下文会稀释注意力。正确做法是在工具内部先做一次信息清洗把关键字段提取出来用简洁的格式返回。我通常还会在返回结果前加一句“本次查询共返回 X 条结果核心信息如下”帮助模型快速聚焦。3.3 反馈循环与自我修正没有反馈循环的 Agent 就像没有后视镜的车撞了才知道错了。很多 Agent 方案是“一次生成直接交付”不校验结果、不反思过程。这种情况下模型犯了错也没机会纠正效果自然不稳定。而加入反馈循环之后Agent 可以先检查自己的输出是否符合预期如果不符再尝试二次修正。最简单的反馈循环是让模型自己评估自己的输出“请检查上述回答是否回答了用户的问题是否遗漏了关键信息如果有请补充或修正。”这个方法成本极低但能显著降低低级错误。更稳健的方案是设定校验规则——比如强类型输出的清单、必要字段非空校验、数值范围检查——发现校验失败就触发重新生成。在更复杂的方案里反馈循环还可以集成“人工兜底”。当 Agent 连续两次修正都无法通过校验就转入人工处理。这个机制虽然在技术层面不“炫”但对生产环境的可用性是决定性的。要知道对使用者来说稳定不出错比偶尔惊艳重要得多。3.4 并发问题贵模型不一定解决架构才能解决搜索热词里有“ai agent 怎么扛并发”这也是很多团队在实际落地时遇到的坎。其实并发问题跟模型贵不贵关系不大再贵的模型也扛不住无限并发反而因为价格高并发稍大账单就爆了。真正扛并发的思路是缓存、异步、限流、池化。缓存是性价比最高的手段。如果多个用户请求的是相同或相似的问题把结果缓存起来直接复用能省掉大量模型调用。对 Agent 来说还可以缓存中间过程——比如某个子任务的结果在后续相关任务里直接复用。异步处理则能让 Agent 在等待工具返回时不阻塞其他请求从而实现更高吞吐。限流和池化则是保护后端模型服务的手段。如果后端是自托管的开源模型并发太高会造成 GPU 资源耗尽响应变慢甚至崩溃。在入口处做一层限流控制同时处理的请求数反而比无脑堆并发更可靠。进程池复用模型实例也能减少频繁加载模型的开销。这些手段都和技术选型有关和模型价格无关。4. 实操给“换模型”念头踩一脚刹车——优化流程实录4.1 第一步先建一个基线评估否则一切优化都是空谈很多团队优化 Agent 纯靠感觉“我觉得好了一点”“好像变聪明了”这种主观判断完全没有意义。正确做法是先准备一个评估集20 到 50 个有代表性的任务覆盖常见场景、边界场景、易错场景。在这些任务上跑一遍现有 Agent记录三个指标任务成功率、单次平均耗时、单次平均 Token 消耗。有了这个基线后续每一项改动的效果都可以量化。我见过不少团队改了一版提示词凭感觉觉得“效果好多了”但评估集上准确率反而降了。如果没有基线数据这种回退就完全无感。而有了基线每做一次改动就能明确知道这次改的是“正向收益”还是“负向回退”。基线评估还有一个额外收益它能帮你发现效果瓶颈到底在哪个环节。比如某个任务总在工具调用步骤失败那问题大概率在工具设计如果总在最终回答阶段出错那问题可能在上下文整理或提示词输出约束。定位到环节优化就有针对性了。4.2 第二步按优先级逐项优化最小改动换最大收益拿到基线之后我通常按下面的顺序做优化每一步都重新跑评估集确认收益后再进入下一步。第一优先级修复工具定义和上下文污染。这两个问题如果存在优先处理。工具描述细化、上下文裁剪、关键信息前置通常能带来最明显的提升。第二优先级增加检索增强。如果你的场景知识密集把知识库挂上去。这一步完成后效果往往直接跳一个台阶。第三优先级加入反馈循环和记忆。让 Agent 能自查、能纠错、能记住历史。这一步主要提升稳定性和多轮体验。第四优先级调整任务分解策略。复杂任务拆解成子任务每一小步单独执行、单独校验。这一步能把成功率再往上推一截。按这个顺序优化完我已经很少遇到“必须换模型”才能解决的场景了。很多时候优化到第二、第三步效果就完全够用了。4.3 第三步如果真要换模型怎么换最划算优化完工程层面之后如果你仍然觉得效果不够或者某些任务确实需要更强的推理能力这时候换模型才是一个合理的选项。但“换”也不是简单的“全都换成最贵的”而是要做分级路由。分级路由的核心思想是不同难度的任务用不同档次的模型处理。简单任务如信息提取、格式转换、知识检索让小模型跑复杂任务如多步推理、代码生成、长文档分析才让贵模型上。我在一个项目里按这个思路做最终账单比“全部用贵模型”低了一半而整体效果几乎没有下降。具体实现上可以在 Agent 的入口加一个“任务难度分类器”先用小模型判断任务类型和难度再路由到对应的执行模型。这个分类器不需要很智能给几个固定类别、写清规则就能跑得很稳。还可以在 Agent 内部做局部路由规划器用贵模型执行器用便宜模型反思器用中等模型。此外还要考虑缓存复用。如果在同一个会话里多个子任务依赖同一个检索结果可以把这个结果缓存下来避免反复调用模型和向量库。对于一个高频使用的 Agent缓存带来的成本下降是非常可观的。4.4 实操示例一个客户支持 Agent 的优化全过程我拿一个实际做过的项目来演示整个流程。这个 Agent 的定位是“客服助手”解答用户关于产品使用的问题。最初方案是直接用某个闭源大模型 简单的系统提示词 一个订单查询工具。基线评估结果是任务成功率 61%平均单次耗时 7.2 秒平均单次 Token 消耗约 1800。第一步我修了工具定义。原来的“订单查询”工具参数有七八个我拆成“按订单号查询”“按手机号查询”“按日期范围查询”三个工具并在描述里写清了适用场景。同时把工具返回结果做了清洗只保留核心字段。改动之后成功率从 61% 提到 74%。第二步加了知识库检索。把产品手册、常见问题、政策说明切成小块存入向量库在生成回答前先根据用户问题召回相关内容拼入上下文。这一步让成功率从 74% 跳到 88%。第三步加了反馈循环。回答生成后让模型自查一遍补充遗漏信息如果有不确定的内容明确标注“需要人工确认”。成功率从 88% 提到 93%同时人工转接率也保持在一个可控范围。最终这个 Agent 依然用的是原来的模型但整体效果已经接近当时“换更高档模型”的预期水平。而这中间没有增加任何模型成本只是多花了几天工程时间。5. 什么时候才应该考虑换更贵的模型5.1 判断清单你的问题到底属不属于“模型能力”问题工程优化做完之后如果效果还是差再把“换模型”列入候选方案。但也不一定非得换更贵的——先对照一下自己遇到的问题属于下面哪一类。属于模型能力问题任务需要多步复杂推理、需要很强的代码生成能力、需要理解高度歧义或隐含意图。这类问题确实是模型的天花板决定上限换强模型能带来直接提升。可能不属于模型能力问题任务涉及大量专业知识、需要处理长上下文中的关键信息、需要跟外部系统频繁交互。这类问题更可能是知识补给、上下文管理、工具调用的问题换模型的收益不确定。无论怎样都不换模型的情况当前模型已经能满足大部分任务只是偶尔出错。此时换更贵的模型带来的收益很小边际效用很低不值得投入。我建议用表格来衡量一下自己的场景表现可能原因优先手段事实性错误多知识不足 / 上下文缺失加入 RAG完善知识库多步推理容易断编排过于简单任务分解 反馈循环工具调用经常错工具定义不清 / 数量过多简化工具细化描述简单任务偶尔翻车提示词模糊提示词结构化长文档理解吃力上下文窗口不够或信息被稀释滑窗摘要 分段处理复杂代码生成不给力模型本身能力不足才考虑换更强模型5.2 开源模型与闭源模型的选择贵不一定就是硬道理当前这个阶段开源模型和闭源模型的差距正在肉眼可见地缩小。对于不少 Agent 场景——尤其是知识检索、信息提取、分类、格式化输出这类任务——开源模型已经完全不虚闭源模型。如果你团队里能自托管开源模型成本优势非常明显不用按 Token 付费并发也好控制数据也不用出内网。我做过的几个 Agent 项目里一个用了自托管的中等尺寸开源模型做执行器效果跟闭源对标模型相差无几但成本几乎可忽略。真正的差距主要在复杂推理和代码生成任务上这时候才需要闭源大模型顶上。这也是为什么我建议“分级路由”——可以在同一个 Agent 里把不同任务分给不同模型各取所长。另一点需要注意的是模型版本迭代的速度。现在模型几乎每隔几个月就出一代强的你在开源模型上做的工程化积累不会浪费——因为工程层提示词、工具、记忆、编排跟模型型号是解耦的将来换更好的模型时你的 Agent 整体架构依然能用。反之如果一开始就把所有赌注押在“换贵模型”上那模型一换、提示词和流程全乱了工程积累归零账单倒是实打实上去了。6. 常见问题与排查技巧实录6.1 典型问题与解决速查我把做 Agent 过程中常见的排查场景做个速查表方便你对照诊断。症状根因处理方案Agent 答非所问提示词缺目标/约束补全任务目标、约束和输出格式多轮对话后开始跑偏上下文被无关信息占满做滑动窗口压缩保留关键摘要工具经常选错工具描述不清/数量太多精简工具细化输入输出描述知识类问题错误率高训练知识不足或过时挂 RAG检索后覆盖实时资料简单任务偶尔崩溃生成链路没有校验加自查循环和规则校验并发一高就响应变慢后端模型服务瓶颈加缓存、限流和异步处理成本偏高大量简单任务也走贵模型部署小模型/开源模型做分级路由6.2 几个我反复踩过的坑写给你避雷第一先加日志再谈优化。很多团队一上来就改提示词、改流程改完眉毛胡子一把抓完全不知道哪里出了问题。正确做法是先给 Agent 加上日志系统把每一步的输入输出、Token 消耗、耗时、调用工具记录都存下来。有了日志你才能知道是哪个环节出的问题才知道优化该瞄准哪里。日志系统的构建并不复杂几条函数封装就能搞定但如果没有它后面所有优化都像是在黑盒里捞针。第二不要迷信复杂的框架。搜索热词里出现了“harness 和 agent 区别”“agent 框架与编排”这些概念但我想说框架和编排只是工具不是结果本身。你的 Agent 如果连最简单的基础链路都跑不稳套上一个再华丽的编排框架也是白搭。先写一个最朴素的循环——接受输入、检索、调工具、给输出——把这项跑通、评估明白再考虑要不要上框架。我见过太多人一上来就搞复杂的 Agent 架构结果光调试框架就花了几个星期业务效果反而没进展。第三数据比提示词更值钱。如果你在优化 Agent 时感到无从下手最快的路径是去收集失败案例。把那些 Agent 回答错的、答偏的用户问题整理成一批样本直接拿这些样本做评估集和优化素材。每改一次都拿这批样本验证。只要你持续收集、持续优化Agent 就是在肉眼可见地变强。这本质上是一个数据驱动的团队迭代方法比拍脑袋式改提示词要可靠得多。还有一个容易被忽略的点要时刻关注用户体验。有些 Agent 技术指标做得很漂亮但用户用起来觉得生硬、对话不自然。这时候如果你的优化只盯着成功率可能会把 Agent 调成一个“正确但答非所问”的机器。说白了Agent 是给人用的优化过程中需要在技术指标和用户体验之间找到一个平衡点。每次改动之后不仅要跑评估集最好也让人真的去体验几轮主观感受和客观指标一起判断。说到底Agent 变强这件事模型只占一部分更重要的是系统工程。我这几年做 Agent 最大的体会就是“换更贵的模型”是对 Agent 能力瓶颈最贵的一种误解。与其一上来就烧预算不如先把提示词、检索、记忆、工具、编排这几件事做扎实。等你做到了这个程度再看大概率会发现——原来手上的模型已经足够强了真正拖后腿的是那个偷懒的工程系统。