Agent从能跑到扛得住：工程化落地的关键维度与压测实践

每次看到有人演示 Agent我都想问一句你的 Agent能扛多大的事儿三分钟的 Demo 谁都能跑。真正让 Agent 去处理几十条真实任务在业务系统里连续跑上一周中间遇到接口变更、用户撤回、超时重试、模型“自信地编造答案”之后还能不能交出正确结果这才是 Agent 能不能上生产环境的关键。很多人被“能自动完成复杂任务”的宣传带偏了做了一个能跑通示例的玩具就觉得已经完成了一大半。实际上从“能跑”到“扛得住”中间隔着大量工程问题。这篇东西不是模型教程也不是框架广告而是给做 Agent 落地的人看的一份工程笔记。适合正在做智能客服、自动化运营、数据分析助手、办公助手、代码助手等场景的开发者和需求方。我会直接把“扛事儿能力”拆开讲把决定上限的部件、加固方法、压测过程、踩坑记录都写清楚。你看完至少能回答一个问题手里的 Agent 到底能接多大的任务以及怎么让它再接大一点。1. 先搞清楚Agent 的“扛事儿能力”到底指什么1.1 从单轮应答到多步执行中间隔着一条鸿沟一个普通聊天机器人处理的是“输入一句话输出一段文字”。它不需要对结果负责说错了大不了重新说。Agent 不一样它被放进一个循环里理解目标、拆解计划、调用工具、观察结果、再决定下一步。每一步的结果都会影响后续动作。这意味着同一个模型放在单轮问答里表现很好放进 Agent 循环里可能立刻崩掉。最常见的崩法是“走着走着忘了最初目标”。用户让 Agent 查一下这个月的订单金额并生成报表它查了两轮之后居然开始纠结“哪些订单属于折扣类别”把生成报表这件事丢在了脑后。原因并不一定是模型笨而是 Agent 循环中缺乏目标状态控制。目标没有被显式保存在上下文的显眼位置计划没有被记录模型在长上下文里被中间结果带跑是很自然的事。所以评价一个 Agent 能不能扛事第一件事不是看它“智能不智能”而是看它能不能在多步执行过程中不丢目标、不崩系统、不烧钱、不胡来。这四个“不”比任何炫技都重要。1.2 把“扛事儿”拆成四个可度量的维度如果你跟别人说“我的 Agent 挺能扛事”这句话没法验收。我一般会把“扛事儿”拆成四个可以量化的维度维度说明典型问题任务宽度Agent 能处理多少步骤、调用多少种工具、覆盖多少种异常分支5 步以内的任务能跑20 步就开始死循环上下文深度能处理多长的文档、多少轮对话、多大的记忆量塞进长文本后关键信息被淹没环境鲁棒性面对接口报错、超时、限流、脏数据时是否还能继续工具一返回异常整个流程直接中断业务可用性成功率、每任务成本、响应延迟、风险动作的错误率是否可接受成功率看着高但关键动作一旦错就不可逆这四个维度不是单选题而是乘数关系。任务宽度再大鲁棒性为零照样不能上线业务可用性再高成本是人工的十倍也没有落地价值。我在评估一个 Agent 项目时第一步就是要求团队把这四个维度写在需求文档里哪怕只是拍脑袋给的初步数值也比一句“我们要做一个强大的 Agent”强得多。2. 决定 Agent 上限的四个关键部件2.1 模型选型不是参数越大越好很多人选模型时只看排行榜觉得分数高就一定能扛事。真实情况是模型能力决定的是推理上限工程决定的是可用上限。一个推理能力很强的模型如果工具调用的稳定性差或者输出格式经常“灵活发挥”在 Agent 场景里的体验会非常糟糕。相反很多简单任务根本不需要顶级大模型。客服场景里的“查询订单状态”“获取物流轨迹”本质上是结构化的工具调用用延迟更低、成本更小的模型反而更稳。复杂任务才需要更强的推理模型来拆解目标、判断异常。最实用的做法是“模型分层”路由模型用小模型判断任务类型、分诊、提取意图速度要快。执行模型负责多步推理和复杂工具调用能力要强。校验模型负责对结果做检查和修正可以是规则引擎加小模型。分层之后成本能被明显压下来。我做过一个实际项目把所有请求都交给最强模型时单任务成本高到没法看改成路由模型先分流简单问题走小模型复杂问题才走大模型之后整体成本降到了原来的四分之一成功率反而更稳定。2.2 工具协议与调用链路Agent 的能力边界由工具决定。模型再聪明操作不了任何系统也只是个空谈家。但很多人对工具的重视程度远远不够写工具描述时敷衍了事参数命名也不讲究结果模型在调用时不知道该传什么。工具描述不是写给人看的是写给模型看的。同样一个查询接口如果描述写成“查询订单”模型可能只传一个订单号如果写成“根据用户权限、时间范围、状态等条件查询订单并返回收货状态、售后状态供用户后续操作使用”模型就知道在合适的时候主动补齐完整信息。工具描述里的每个字都在影响模型的调用质量。调用链路还需要有控制。不能让模型在每一步都自由选择任何工具。比如“发送短信”“修改价格”“删除文件”这类有副作用、不可逆的操作必须经过独立的审批逻辑不能因为模型觉得“应该发”就真的发出去。链路的控制权应该掌握在代码手里而不是完全交给模型。2.3 记忆系统短期、长期、工作记忆Agent 的上下文窗口是有限的就算支持超大窗口塞的东西越多找到关键信息的难度越大成本也跟着涨。所以记忆系统必须区分层次短期记忆当前会话里与任务直接相关的消息和工具结果。长期记忆用户偏好、历史结论、业务规则通过检索按需取回。工作记忆当前任务的目标、计划、已完成步骤、待确认事项。工作记忆是最容易被忽略的。我见过很多 Agent 项目没有“任务状态”的概念所有东西都堆在对话历史里。一旦对话轮次多了模型就会把用户早期说过的“只要金额大于一千的订单”给忘掉。正确做法是把任务状态从对话历史里抽离出来用结构化的字段单独保存比如{ task_id: T20250601_001, goal: 统计本月已发货订单总额, steps_done: [鉴权, 查询订单列表, 筛选已发货], constraints: [金额大于1000, 排除测试订单], next_action: 汇总金额 }每次模型决策前把“目标 约束 已完成步骤 下一步”拼进上下文比把整段历史丢给模型要靠谱得多。这也是 Agent 在长任务里不迷路的最重要技巧。2.4 控制逻辑ReAct / Plan-and-Execute / 多角色分工控制逻辑指的是 Agent 如何决定下一步动作。这里没有银弹只有适配。ReAct 是最常见的模式思考 → 行动 → 观察 → 再思考。它很灵活适合任务方案不确定、需要边走边看的场景比如“根据用户描述排查一个登录问题”。但 ReAct 的缺点是容易发散没有明确计划约束时模型会反复尝试没用的工具。Plan-and-Execute 适合步骤相对明确的场景先生成一个执行计划再按计划逐步执行遇到偏差再修计划。它的优点是目标感强适合“批量处理几十个文件”“生成月度报表”这类任务。缺点是面对意外情况不够灵活所以需要加一个“计划修订”的机制。更接近生产实践的是多角色分工规划器负责拆步骤执行器负责调用工具校验器负责检查结果。有人会问这不就是把一个 Agent 拆成多个吗对这就是核心。单体 Agent 又当运动员又当裁判出错时很难自查把规划和校验拆开才能形成有效的反馈闭环。3. 从“能跑”到“扛得住”实操加固的五个阶段3.1 边界设计先定义 Agent 不做什么很多项目失败是因为 Agent 什么都要接。用户问天气它也答问数学题它也算问公司报销制度它也翻文档。“能力边界模糊”带来的直接后果是模型一旦超出边界就会开始幻觉。一个能扛事的 Agent首先要明确“我不做什么”。比如客服 Agent 的边界可能是只处理订单查询、物流跟踪、退换货入口引导不处理价格谈判、不承诺赔偿、不解读法律条款。超出边界时Agent 要能识别出来然后礼貌地转人工而不是硬答。边界设计的另一个作用是定义“任务验收标准”。什么算完成什么算失败必须能代码判断。比如“查询订单”任务的完成标志是“成功拿到订单状态并展示给用户”如果中间任何环节没有拿到真实数据这个任务就应该标记为“未完成”绝不能靠模型编一段话蒙混过关。3.2 上下文压缩与关键信息提取长文本是 Agent 的隐形杀手。我曾经把一个 200 页的 PDF 直接塞进上下文里让 Agent 提取关键条款结果它被大量冗余信息干扰最后总结出来的结论前后矛盾还编了一条不存在的条款。后来改成“分块检索 关键信息抽取 摘要缓存”的方式先把文档切块用检索召回相关段落再把召回段落交给模型提取结构化条款最后把提取结果作为后续任务的上下文。每步只让模型看它需要看的东西效果立刻稳定了很多。上下文压缩不只是省 token更重要的是降低干扰。上下文里的每一条冗余信息都是模型犯错的候选诱因。设计 Agent 时要时刻问自己模型这一步真的需要这段历史吗不需要就截断、摘要、归档。3.3 自带重试和降级策略生产环境里的工具接口不会永远稳定。超时、限流、返回 500、参数被网关拦截这些都是常态。Agent 必须自带一套重试和降级策略而不是在工具报错时直接“一脸茫然”。重试要注意幂等性。查询类接口可以放心重试下单、发送通知这类非幂等操作重试可能导致重复执行。对于非幂等操作正确的做法是生成一个全局唯一的操作 ID或者先查询执行状态确认没有执行过再发起。降级策略也分层级。第一层是切换到备用模型比如主力模型超时后用更低延迟的模型顶一下第二层是工具降级比如实时查询不可用时先返回缓存的最新数据并注明时间第三层是流程降级如果整套 Agent 链路都不可用就直接转人工。能有清晰降级路径的 Agent才谈得上“扛事”。3.4 可观测性日志、轨迹、评估集Agent 是一个黑盒系统如果看不到内部决策过程出了问题就只能抓瞎。上线前必须把观测能力补全。我要求每个 Agent 至少记录以下信息用户原始输入。Agent 每一步的思考摘要。每次工具调用的入参、出参、耗时、状态码。每一步的 token 消耗和累积成本。最终输出和任务完成标志。有了这些轨迹才能复现问题。很多时候用户反馈“Agent 答错了”但开发者根本不知道它当时为什么这么做。有了轨迹之后一看“工具返回的是空数组模型却回答有订单”问题就清楚了模型没有遵守“工具结果优先于模型记忆”的原则。还要准备一套离线评估集。评估集不需要一开始就很大但要有覆盖度正常路径、含糊表达、用户中途改条件、工具返回异常、超出边界、敏感操作拒绝等场景。每次更换模型、调整工具协议、修改提示词都先拿评估集跑一遍再决定要不要上线。3.5 护栏与审批关键动作必须有人确认Agent 的能力越强破坏力越大。护栏不是限制 Agent而是保护业务。对于高风险操作必须有独立于模型决策的审批环节。我把操作分为三类无副作用查询、检索、计算。可以自动执行。有副作用但可回滚修改草稿、更新待确认状态。可以自动执行但要留审计记录。不可逆或高影响发送邮件、删除数据、转账、修改价格。必须人工确认。审批环节不能只是让 Agent 自己问一句“你确定吗”因为用户可能没仔细看。更稳妥的做法是把待确认内容结构化展示出来比如“邮件标题、收件人、正文摘要、发送时间”用户确认后再由代码触发发送动作。我自己踩过这样的坑Agent 在回复用户时说“好的我已经为您提交退款申请”但实际退款接口根本没被调用。模型把“意图”当成了“事实”。后来我在系统里加了一条硬规则必须在工具调用成功返回后才允许 Agent 告知用户操作完成。凡是没有工具返回数据支撑的“成功结论”一律拦截。4. 压测一个 Agent真实场景下的踩坑记录4.1 用场景脚本模拟真实流量很多人测试 Agent 时只跟它闲聊几个问题就判断“效果不错”。这是最不可靠的测试方式。上线前要做场景脚本压测而且是带并发、带异常、带时间压力的压测。我做过一个客服类 Agent 的压测设计了一个包含 50 个场景的脚本。这 50 个场景不是随机编的而是从历史真实对话里抽样出来的。脚本里既有“查订单物流”这种简单问题也有“先查订单然后又追加了一个修改收货地址的需求”这种复合问题还有“故意让 Agent 处理售后投诉看它会不会情绪化乱承诺”的边界场景。压测时每个场景都写了期望结果。判断成功的标准不是“模型回答了”而是“回答的内容和期望一致并且关键操作真的被执行了”。跑完之后看四张表各类场景成功率、平均延迟、单任务 token 成本、风险动作触发次数。这套流程走一遍你大概就能确定 Agent 的“真实体型”了。很多在单轮体验里看起来很强壮的 Agent一上压测就原形毕露。4.2 成本爆炸循环调用与 token 浪费压测中我遇到最多的一个问题不是“答错”而是“太贵”。一个理想中只需要 4 步的任务Agent 硬生生跑了 12 步。它反复查询同一个订单反复尝试不存在的筛选条件甚至会用不同的措辞重复调用同一个接口。原因在于模型没有“观察结果是否有效”的能力。工具返回结果不变它还在继续尝试这跟人拿着遥控器反复按一个没反应的按钮一样。解决办法有三个设置最大步数比如默认 10 步超过直接停止并转人工。对工具调用做缓存相同参数的查询直接返回历史结果不计入模型上下文。在上下文中提醒模型“当前工具结果未发生变化请停止重复尝试”。成本爆炸还有一个隐形来源是“把大模型用在小事上”。同一个 Agent 如果没有路由分流所有请求都走最强模型每轮对话都带着完整历史成本会非常吓人。把简单任务分流给轻量模型是省钱最直接的手段。4.3 模型幻觉与“自信的错”Agent 的幻觉比普通聊天机器人更危险。普通聊天机器人说错一句话用户最多觉得不靠谱Agent 在幻觉状态下可能会调用工具生成一个根本不存在的订单号去查数据或者给用户编造一个退款金额。我们压测时遇到过这样的 case用户问“上个月 3 号那笔订单退款了吗”Agent 先查了订单列表发现没有符合条件的订单但它没有停下来而是根据记忆里的某个类似订单号自行推断出一个“可能退款成功”的结论。用户要是不较真就被骗过去了。解决办法是强约束“数据来源”。所有涉及事实的表述都必须在上下文里找到对应的工具返回内容。如果工具返回为空模型只能回答“未查到”不能加任何推断。为了更保险可以在 Agent 输出前加一个校验模型专门检查“Agent 声称的事实是否都有工具数据支撑”。这一步很笨但非常有效。4.4 超时和并发问题Agent 不是一个孤立的程序它要同时服务很多用户。压测时如果只串行跑 50 个场景很多问题根本暴露不了。一上并发外部接口限流、数据库连接池耗尽、回调超时这些问题全都来了。我们遇到过最典型的情况20 个 Agent 同时处理“查询物流”任务每个 Agent 都直接调用物流查询接口瞬间把接口打满后面排队的全部超时。后来把 Agent 对第三方接口的访问改为“共享缓存 合并请求”的方式同一个运单号在短时间内只要查一次其他 Agent 直接读缓存并发压力立刻降了下来。这里有一个工程原则不要让 Agent 直接操作底层资源所有外部调用都走一个带限流、带超时、带缓存、带重试的中间层。Agent 面向业务逻辑中间层面向系统稳定性各司其职。4.5 数据准备和评估集的 SOP最后说一下评估集怎么建。这个环节没有捷径一步一步来从真实日志里抽样 100 条常见用户问题。按业务场景分类补齐边界场景和异常场景。为每一条用例编写期望输出包括期望调用哪些工具、期望返回什么结论。离线跑代码记录成功率、失败原因、token 消耗。失败 case 逐条分析是提示词问题、工具问题还是模型能力问题。每次调整后全量回归防止“修好一个 bug 带崩另一个功能”。评估集不在多在于覆盖。重点是“失败过的 case 必须进入回归集”。我见过太多团队改完提示词就不管了结果之前修好的问题换了一个模型版本后又冒出来了。回归集就是 Agent 免疫系统的记忆。5. 一个更诚实的“扛事儿”评估框架5.1 用“成功率 × 成本 × 风险”算账聊到最后我更愿意用一个综合框架来评估 Agent 到底能扛多大事。只看成功率是不够的因为一个成功率 90% 的退款 Agent如果每次错都错在退款金额上那它就不是 90% 优秀而是 100% 危险。我习惯把“可上线指数”分成三块核心场景成功率指业务最关心的那几条路径不是所有场景的平均值。单任务成本包括模型调用成本、工具调用成本、人工介入成本。风险暴露高风险操作在错误次数中的占比以及每次错误的业务影响程度。如果核心场景成功率低于 90%先不上线继续补数据如果成本比人工还高一倍只适合做辅助还不适合做自动化如果风险操作有过一次不可逆错误那就必须把审批环节加回来。这三块没有哪一个可以靠另一个的优秀来弥补。5.2 从“会跑 Demo”到“能扛业务”差的不是模型而是工程我自己的体会是Agent 项目里真正花时间的部分从来不是“让模型理解一个指令”而是“让系统在不可靠的环境中也能给出可靠的结果”。模型负责聪明工程负责靠谱。如果你正在做一个 Agent我的建议是先拿三个真实场景跑通全链路再考虑扩能力先把失败路径都画出来再优化单步准确率先给关键操作加审批再讨论全自动化。这样你的 Agent 可能不是最“炫”的但会是真正能扛事儿的。“你的 Agent 能扛多大的事儿”这个问题本质上是在问你能为它的不靠谱预留多少兜底把兜底做好了Agent 就能替你扛更多的事兜底没做好再强的模型也只是一颗定时炸弹。