接手 Agent 相关项目有几年了我最大的感受是演示阶段的惊叹和上线后的骂街往往来自同一个项目。很多时候我听人讲“Agent 效果不稳定”第一反应不是大模型又抽风了而是工程的兜底基本没做。这个观点可能有点得罪人但我把锅归给工程不是甩锅是这些年踩坑踩出来的判断。这篇就想把 Demo 惊艳、上线稀碎这件事拆开聊透你也可以拿着自己的场景来对照看看锅到底该谁背。1. “演示惊艳”是怎么制造的三个看不见的成本先说个特别常见的画面你给业务方演示一个 Agent 助手它流畅地接住用户多轮对话主动调用工具查库存、算运费、下订单每一步都条理清晰最后还礼貌地总结一句“已为您下单”。全场掌声。一个月后上线用户随便问一句它就开始胡言乱语要么调错工具要么卡在某个环节出不来。业务方第一反应是“模型不行”但我的判断是演示的成功是花了大代价堆出来的只是这些代价没被计入项目成本。1.1 演示场景是被“筛选”过的不是被“适配”了的做过 Agent Demo 的人都清楚演示前通常要准备几个精心设计的用户问题。这些问题既要覆盖产品核心路径又不能太难。我们往往在后台悄悄固定了模型参数、选择了恰好合适的模型版本甚至为演示场景手工搭好了知识库和工具返回格式。本质上演示验证的是“模型在理想输入下的单次推理能力”而不是“系统在随机输入下的持续服务能力”。真实用户可不会按你的剧本提问。我不知道你们有没有这个体验演示那天用户问的问题稍微绕一点比如“我要个便宜点的但别是那种特别慢的物流哦对了我有优惠券你看着办吧”Agent 很容易就蒙了。不是模型变笨了而是这个输入里包含了多个约束条件需要工具多次查询、信息交叉比对演示时我们刻意绕开了这种复杂场景。1.2 上下文干净整洁模型其实在“温室”里跑演示环境下上下文窗口里前几轮都是完美对齐的对话工具返回结果也被我们清洗过字段名整洁、格式统一。真实上线后呢用户模拟两可的表述、历史会话的噪声、工具字段突然为空、上游接口返回了文档里没写过的新状态码——这些信息全都会被塞进上下文被模型阅读、理解、推理。模型对“脏上下文”的容忍度远比你想象的低。我有一个粗糙但一直用来估计的经验上下文中的无关信息每多一分Agent 的决策准确率就下降几个百分点。演示时我们是“给模型最优信息”上线后是“让模型从垃圾堆里找信息”这能一样吗。1.3 演示中的失败路径被刻意绕开了演示脚本通常只覆盖 happy path意图识别成功、工具调用成功、结果生成成功。偶尔也会准备一条备选路径但大多是提前排练过的“优雅错误”。真实系统中的失败路径才是常态工具超时、第三方接口限流、数据返回不完整、用户中途反悔改变主意、Agent 自己陷入循环。我在某个模拟客服项目中统计过一个星期线上 Agent 的失败原因分布意图识别错误只占不到三分之一反而是工具返回异常、流程状态冲突、上下文溢出占了大部分。这些恰恰是演示时根本不会暴露的问题。所以不是上线后 Agent 变傻了是演示时根本没让它见世面。2. “上线稀碎”碎在哪里真实环境的不确定性清单Demo 阶段模型能力决定上限上线阶段工程能力决定下限。真实环境里有一堆因素每一样都足以把一个原本不错的 Agent 打回原形。我按严重程度列了一份清单你可以逐条对照自己的项目。2.1 用户输入永远在你的预期之外你精心设计的 system prompt 假设用户会说“我要查一下 X”结果他上来就扔一句“那个啥玩意儿咋回事”。你假设用户一步步回答你的澄清问题他来一句“你看着办”。你假设对话历史里只有当前任务相关的信息结果他聊到一半突然问“对了我上次问的那个呢”。这些写法对 LLM 单轮问答可能不是问题但对 Agent 这种“多轮闭环”系统就是大问题。Agent 每一步都要基于当前状态做工具调用决策用户输入一旦偏离规范决策链就漂移了。更麻烦的是真实用户会频繁打断、更正、追加需求而 Agent 对“用户意图变更”的感知往往滞后经常在旧目标上继续执行完才发现新指令。2.2 工具调用链路上的故障传导Agent 区别于普通对话系统的核心就是工具调用。工具调用一旦引入Agent 就从“文本生成问题”变成了“分布式系统问题”。每个工具都有调用超时、返回格式、错误码、幂等性、限流策略。任何一个环节不稳Agent 都可能陷入三种状态第一种是“反复重试但不知道已成功”。工具实际执行成功但响应超时Agent 以为失败于是换个参数再来一次结果造成重复下单、重复扣款。第二种是“拿到异常结果但强行解读”。工具返回一个空列表Agent 没有判断这是“查询无结果”还是“查询失败”硬编了一个“似乎没有找到相关记录”给用户实际是接口崩了。第三种是“中间状态丢失”。Agent 执行到一半token 用完了或上下文超限了整个流程中断用户再追问时它已经不记得自己干到哪一步了。这些都是典型的工程问题跟模型智力没关系。2.3 上下文窗口的“死亡螺旋”上下文越用越长这是 Agent 上线后必然遇到的事。长对话中早期信息会被后续内容稀释模型开始遗忘关键参数比如用户所在城市、已确认的订单金额、之前约定的时间。这时候 Agent 会自己“脑补”缺失信息一脑补就出错。更严重的是上下文截断策略。很多项目简单粗暴地用“滑动窗口只保留最近 N 轮”结果把用户的原始需求、之前的工具调用结果全丢了Agent 变成了一个不断失忆的对话机器人。我见过因为截断丢失了用户地址Agent 在第 15 轮自信地下了一个配送地址是空白的订单业务方差点当场晕倒。上下文的管理不是“砍掉多少轮”的问题而是“哪些信息必须持久化”的问题。2.4 并发与成本的双重压力演示时只有一个用户在跑一次请求失败就重来一遍反正不花钱。上线后并发上来每个任务可能要消耗十几万 token多轮调用、工具结果反馈、上下文摘要重算每一样都在烧钱。成本一高有些人就开始降低模型规格从最强模型降级到便宜模型然后发现效果断崖式下跌。我见过一个项目演示时用最好的模型单次任务成本 3 块钱业务方说没问题。上线后一天几万个请求老板看到账单直接拍桌子。团队只好把模型换成便宜版本参数调激进结果 Agent 开始频繁幻觉、工具调用格式错误。这不是模型的问题是没有在架构上把“贵模型用在关键节点”“便宜模型用在简单环节”做分流。工程上不想办法优化成本结构最后一定是产品效果为账单买单。2.5 非确定性同样的输入今天行明天不行LLM 天然带有随机性即使把 temperature 调到 0模型版本更新、推理服务的负载变化、token 化细节差异都会导致同一段输入的输出产生波动。演示时你跑三次发现都成功就以为稳定了。上线后你跑三次可能一次成功、一次漏掉了工具调用、一次格式不对。非确定性最致命的地方在于它不是简单的“对错波动”而是会影响 Agent 的流程连续性。同一个意图上一次走了正常流程这一次模型决定先确认一下下一步又决定直接执行整个状态机的走向不可复现。这让测试和排障变得极其困难。你无法通过简单地“重新跑一遍”来复现 bug因为你面对的已经不是同一段轨迹了。3. 为什么我把锅扣给工程五个缺席的必备环节到目前为止你可能觉得这些现象都是模型能力不够、真实环境太复杂导致的。我承认这些客观原因都存在但工程上完全可以提前筑好防线。下面这五个环节在我看过的绝大多数“上线稀碎”项目里至少缺了两三个。3.1 没有把工具调用当“远程调用”设计Agent 项目里的工具调用本质上就是分布式系统里的远程调用。远程调用有一整套被反复验证过的规范超时控制、重试机制、幂等校验、熔断降级、请求追踪。可我见过太多 Agent 项目的工具调用就是一个裸奔的 HTTP 请求甚至一个裸奔的 Python 函数。工具层不做幂等重复调用就产生脏数据不做超时Agent 就在那里反复横跳不做熔断上游服务一抖Agent 第一个跟着崩。模型只是个决策器它本身不具备“这个工具挂了我就换个策略”的常识判断你必须在工程上替它兜底。说句不好听的你连“工具偶发失败重试一次”这种最基本的稳定性保障都不做凭什么要求上线稳定。3.2 没有把 Agent 流程当“有状态事务”管Agent 执行一个任务往往要经过多轮推理、多次工具调用这个过程是有状态的。今天的状态是什么、上一步做了什么、下一步该做什么、如果中间失败了这个任务要如何恢复——这些都需要一个显式的状态管理机制来支撑。很多项目完全没有状态管理。Agent 每一次 LLM 调用都是无状态的函数调用靠模型从对话历史里“感受”当前进度。对话历史一旦因为截断、摘要而丢失部分内容Agent 就不知道自己在哪一步了然后就开始胡说八道。正确做法是有一个任务状态对象Task State Object记录目标参数、已执行步骤、工具返回结果、需要用户澄清的问题等每一步决策前先加载状态而不是让模型每次从零开始推理。3.3 没有建立可观测性体系Agent 的单次任务里可能包含多次 LLM 调用和多次工具调用。任何一个环节出了问题如果没有 trace 系统你就只能看到“对话报错了”这种毫无信息量的结果。我见过很多项目排查问题时第一件事是去翻模型请求日志然后一条条人工比对几个小时过去了还是没定位到是哪个工具超时了。Agent 项目的可观测性至少要做到三层第一层是全链路 tracing标记每一次 LLM 调用和工具调用的 ID、耗时、输入输出第二层是状态快照记录每个任务在不同阶段的上下文、决策、中间结果第三层是轨迹回放能完整还原一个任务从开始到结束的每一步。没有这三样出了问题只能靠猜而靠猜不如早休息。3.4 没有建立评估集上线全靠感觉演示阶段评估 Agent 就是随便拿几个问题跑一下看看结果像不像样。这种评估方式最大的问题是不可重复、不可量化、不可回归。今天改动了一个 prompt你无法判断效果是变好了还是变差了因为没有一个固定的测试集和评分标准。工程化的 Agent 必须建立一套评估体系至少要包括目标场景用例集、评分标准、基准结果。哪怕最开始只有几十条用例用规则判定“是否调用了正确工具、是否得到最终正确状态”也比“感觉差不多”强。有了这套评估集你才能让 CI/CD 管线在模型版本升级、prompt 变更时自动跑回归保证每一个上线改动都不把现有能力搞坏。3.5 把模型幻觉当作品质问题而不是必选项最后这一点我会表达得比较直接。模型一定会出错这是一个不争的事实。工程要做的是通过架构设计把幻觉的破坏性降到最低而不是祈祷模型这次聪明一点。比如关键信息优先从工具返回的结构化数据中获取而不是让模型自己生成关键操作在执行前增加二次确认模型输出必经格式校验和字段校验不合格就重试或转人工高风险的领域涉及钱、订单、个人信息设置回退规则。工程做的不是让模型更聪明让模型更聪明的活应该交给模型厂商来优化。工程做的是给模型盖一个笼子能犯的错种类有限犯了错也能快速恢复不会引发不可控的后果。4. 一次真实事故的完整复盘从日志到根因讲故事永远是理解工程问题最好的方式。下面这个事故来自一个模拟的客服订单 Agent 项目细节已脱敏整个过程我完整经历了很有代表性。4.1 现象用户说“只是问一下”后台却多了三张订单用户给 Agent 发消息说“帮我按上次的地址再买一箱那个咖啡豆”Agent 回复“正在为您下单”然后用户又补了一句“等等我只是问问现在还有没有货先别下”。过了几分钟用户在订单列表里看到了三个待支付订单。客服查后台发现这三张订单是由同一个 Agent 任务创建的金额、地址都一样。用户投诉项目紧急上线第一个排查对象自然是模型“是不是理解错了”。4.2 排查过程从 trace 里看每一步由于项目上了基础的 trace 链路我们很快拉出了这个任务的时间线第 1 步模型识别到“购买咖啡豆”意图。此时用户还没有说“先别下”模型执行商品查询工具返回了库存充足这是一个正常的查询。第 2 步模型调用“创建订单”工具。工具调用发出后网关在 15 秒内没有返回响应触发了超时。工具层有一个自动重试逻辑功能本身没问题但重试时没有携带唯一的业务请求 ID。第 3 步重试的那一次请求实际在订单系统里成功创建了订单但因为响应响应体里有陈旧缓存字段模型侧并没有判断创建成功。第 4 步模型认为“创建订单”没成功用相同的参数再次调用“创建订单”工具于是又创建了一单。用户说“先别下”的那条消息被上下文截断策略裁剪掉了。因为这个策略是简单“只保留最后 5 轮”此时用户的更正已经被挤出上下文。Agent 压根没有机会感知到意图变更。最终三张订单的产生链条是请求超时 → 重试成功但被判定失败 → 再次调用成功 → 用户更正指令被截断。这造成的直接后果是三张订单里只有一张是用户想要且确认过的另外两张全是系统自己创建出来的。4.3 根因确认四个工程缺陷叠加顺着链路往回捋问题根本不用模型来背第一个是调用“创建订单”这样的非幂等工具时没有校验业务幂等键。正常的设计是每次 Agent 创建订单都要带上一个由会话 ID、用户 ID、确认参数生成的请求唯一标识服务端做去重。这个项目当时完全没做。第二个是工具调用超时之后重试逻辑没有判断“是否已经执行成功”。这类问题非常常见超时只能说明响应延迟不能说明业务没有执行。重试前必须通过查询确认状态。第三个是上下文截断策略过于粗鲁。系统只按“轮次”保留但没有把“用户的关键指令”和“待确认的参数”单独持久化导致关键意图被裁掉Agent 像一个失忆的接线员。第四个是 Agent 执行高风险的写操作创建订单前没有增加确认环节。模型在“工具返回未明确失败”的状态下完全靠生成结果判断“要不要重试”这种不确定性设计在工程上是不允许的。4.4 修复方案与验证这次事故后我们做了四件事为所有包含写语义的工具增加幂等键设计和去重校验。同一个任务派生出的同一业务动作重复调用时直接返回上一次结果保证不会产生重复数据。工具调用层区分“失败”和“超时”超时后不立刻重试而是发起一个查询动作确认业务状态再决定下一步。简单说就是不再让模型猜。上下文管理改为“结构化持久化”把用户的关键指令、确认过的参数、当前任务状态存到独立的 Task State 里普通对话轮次照常滑动窗口关键业务信息绝不因上下文截断而丢失。增加写操作的前置确认创建订单这类高风险动作必须由用户明确确认后才执行。模型可以“请求创建”但真正落库要走独立的审批式流程。修复后同类场景没有再出现重复订单。这件事之后项目组再没有人说“是模型不行”。5. 能直接落地执行的工程硬措施把 Agent 当系统来建设如果你准备新建或者重构一个 Agent 项目下面的措施建议直接抄它们都是经过实际项目验证的。5.1 工具层协议先行接口和后端服务一样对待工具定义时花时间把 schema 设计好哪怕前期慢一点后期会省很多事。每个工具必须有明确的输入输出协议、错误码规范和状态码语义。网络层面要设置合理的超时时间重试必须基于幂等策略写操作必须有全局唯一的请求 ID。把“创建订单”这类工具当成数据库事务来看待。另外工具返回的内容要同时包含“结构化字段”和“用户可读文本”。模型需要先用结构化字段做决策这样它不会自己发挥跑偏用户可读文本用来直接引用。数据缺失时宁可明确返回“此字段为空”也不要拼接一个“暂无信息”之类的模糊字符串让模型猜。5.2 编排层显式状态机取代自由发挥任务流程不要完全交给 LLM 自由规划。最简单的做法是先定义好粗粒度的状态机比如意图识别 → 参数收集 → 确认 → 执行 → 反馈每一步是一个状态LLM 只负责在状态内部做决策而不是从头到尾自由穿梭。同时为整个 Agent 任务设置一个最大循环次数和最长执行时长防止模型在工具调用上陷入无限循环。到达上限后直接终止返回“需要人工协助”的结果。Loop 控制这件事工程上很简单但不做就很容易出乱子。我知道有些团队怕限制循环会局限模型能力但你应该想清楚自由发挥的代价是无限 token 和排错地狱。5.3 上下文层把关键信息变成显式状态上下文窗口不足是必然的关键信息必须提前抽出来放到业务层管理。我在不少项目里的做法是维护一个“任务记忆”对象包含目标、已收集参数、待确认项、工具返回的引用在每次调用模型时把它嵌入上下文头部。对话历史滚动窗口只保留一般交流信息业务关键信息从业务层读取两者互不干扰。当一个任务持续很长时间原始历史太多时用摘要分级存储。比如“最近的 5 轮对话完整保留之前的先做一次结构化摘要”这样既不会把模型上下文撑爆又不会丢失早期关键约束。5.4 观测层trace、日志、回放一个都不能少Agent 项目一定要在第一天就把 trace 体系搭好而不是等出事故之后再补。每个任务都要有一个全链路 ID贯穿 LLM 调用、工具调用、状态流转和最终结果。日志里除了记录结构化数据还要记录模型输入的完整上下文和输出结果这些数据是事后排查的第一资料。更进一步建议把任务的输入输出轨迹以 JSON 形式存储专门为“轨迹回放”设计查询接口。这样一旦线上出现问题可以直接把那条轨迹拿出来重新跑看是模型决策问题还是工具调用问题。轨迹回放就像是飞机的黑匣子平时不起眼出问题时它能告诉你一切。5.5 评测层把“惊艳”固化成基线最后一条也是我强烈推荐做的把演示用例、线上经典型场景、历史问题场景收集成回归测试集。每条用例不仅要记录“输入”和“期望输出”最好还记录“期望调用的工具序列”。用这套测试集跑每天的模型版本更新、prompt 变更把“惊艳”固化成可自动验证的基线。一开始你可能只有三五十条用例没关系。每上线一个多月就从线上日志里挑出三类用例加进测试集成功案例防止回归、失败案例验证修复、边界场景爆露新问题。三个月后你就会有一份很有价值的回归集。这样每次提示词改动都能迅速看到它对已有能力的影响而不是等上线被业务方吼了才回头查。6. 个人体会别跟模型较劲跟不确定性较劲把这些话说完回到标题。你把 Agent 项目弄得“演示惊艳、上线稀碎”真不一定是模型不行、数据不行、算法不行。很多时候就是工程上懒惰了省略掉了那些“看不见但绝不可缺”的环节。我自己前几个项目就是吃了这个亏后来把工具层协议、状态管理、可观测性和回归集一项项补上之后Agent 在线上就开始变得“虽然偶尔笨但绝不会闯大祸”了。这个判断一定有人不同意但我坚持Agent 产品化与其赌模型一次比一次聪明不如把系统皮实程度做到你不怕它犯蠢。
接手 Agent 相关项目有几年了我最大的感受是演示阶段的惊叹和上线后的骂街往往来自同一个项目。很多时候我听人讲“Agent 效果不稳定”第一反应不是大模型又抽风了而是工程的兜底基本没做。这个观点可能有点得罪人但我把锅归给工程不是甩锅是这些年踩坑踩出来的判断。这篇就想把 Demo 惊艳、上线稀碎这件事拆开聊透你也可以拿着自己的场景来对照看看锅到底该谁背。1. “演示惊艳”是怎么制造的三个看不见的成本先说个特别常见的画面你给业务方演示一个 Agent 助手它流畅地接住用户多轮对话主动调用工具查库存、算运费、下订单每一步都条理清晰最后还礼貌地总结一句“已为您下单”。全场掌声。一个月后上线用户随便问一句它就开始胡言乱语要么调错工具要么卡在某个环节出不来。业务方第一反应是“模型不行”但我的判断是演示的成功是花了大代价堆出来的只是这些代价没被计入项目成本。1.1 演示场景是被“筛选”过的不是被“适配”了的做过 Agent Demo 的人都清楚演示前通常要准备几个精心设计的用户问题。这些问题既要覆盖产品核心路径又不能太难。我们往往在后台悄悄固定了模型参数、选择了恰好合适的模型版本甚至为演示场景手工搭好了知识库和工具返回格式。本质上演示验证的是“模型在理想输入下的单次推理能力”而不是“系统在随机输入下的持续服务能力”。真实用户可不会按你的剧本提问。我不知道你们有没有这个体验演示那天用户问的问题稍微绕一点比如“我要个便宜点的但别是那种特别慢的物流哦对了我有优惠券你看着办吧”Agent 很容易就蒙了。不是模型变笨了而是这个输入里包含了多个约束条件需要工具多次查询、信息交叉比对演示时我们刻意绕开了这种复杂场景。1.2 上下文干净整洁模型其实在“温室”里跑演示环境下上下文窗口里前几轮都是完美对齐的对话工具返回结果也被我们清洗过字段名整洁、格式统一。真实上线后呢用户模拟两可的表述、历史会话的噪声、工具字段突然为空、上游接口返回了文档里没写过的新状态码——这些信息全都会被塞进上下文被模型阅读、理解、推理。模型对“脏上下文”的容忍度远比你想象的低。我有一个粗糙但一直用来估计的经验上下文中的无关信息每多一分Agent 的决策准确率就下降几个百分点。演示时我们是“给模型最优信息”上线后是“让模型从垃圾堆里找信息”这能一样吗。1.3 演示中的失败路径被刻意绕开了演示脚本通常只覆盖 happy path意图识别成功、工具调用成功、结果生成成功。偶尔也会准备一条备选路径但大多是提前排练过的“优雅错误”。真实系统中的失败路径才是常态工具超时、第三方接口限流、数据返回不完整、用户中途反悔改变主意、Agent 自己陷入循环。我在某个模拟客服项目中统计过一个星期线上 Agent 的失败原因分布意图识别错误只占不到三分之一反而是工具返回异常、流程状态冲突、上下文溢出占了大部分。这些恰恰是演示时根本不会暴露的问题。所以不是上线后 Agent 变傻了是演示时根本没让它见世面。2. “上线稀碎”碎在哪里真实环境的不确定性清单Demo 阶段模型能力决定上限上线阶段工程能力决定下限。真实环境里有一堆因素每一样都足以把一个原本不错的 Agent 打回原形。我按严重程度列了一份清单你可以逐条对照自己的项目。2.1 用户输入永远在你的预期之外你精心设计的 system prompt 假设用户会说“我要查一下 X”结果他上来就扔一句“那个啥玩意儿咋回事”。你假设用户一步步回答你的澄清问题他来一句“你看着办”。你假设对话历史里只有当前任务相关的信息结果他聊到一半突然问“对了我上次问的那个呢”。这些写法对 LLM 单轮问答可能不是问题但对 Agent 这种“多轮闭环”系统就是大问题。Agent 每一步都要基于当前状态做工具调用决策用户输入一旦偏离规范决策链就漂移了。更麻烦的是真实用户会频繁打断、更正、追加需求而 Agent 对“用户意图变更”的感知往往滞后经常在旧目标上继续执行完才发现新指令。2.2 工具调用链路上的故障传导Agent 区别于普通对话系统的核心就是工具调用。工具调用一旦引入Agent 就从“文本生成问题”变成了“分布式系统问题”。每个工具都有调用超时、返回格式、错误码、幂等性、限流策略。任何一个环节不稳Agent 都可能陷入三种状态第一种是“反复重试但不知道已成功”。工具实际执行成功但响应超时Agent 以为失败于是换个参数再来一次结果造成重复下单、重复扣款。第二种是“拿到异常结果但强行解读”。工具返回一个空列表Agent 没有判断这是“查询无结果”还是“查询失败”硬编了一个“似乎没有找到相关记录”给用户实际是接口崩了。第三种是“中间状态丢失”。Agent 执行到一半token 用完了或上下文超限了整个流程中断用户再追问时它已经不记得自己干到哪一步了。这些都是典型的工程问题跟模型智力没关系。2.3 上下文窗口的“死亡螺旋”上下文越用越长这是 Agent 上线后必然遇到的事。长对话中早期信息会被后续内容稀释模型开始遗忘关键参数比如用户所在城市、已确认的订单金额、之前约定的时间。这时候 Agent 会自己“脑补”缺失信息一脑补就出错。更严重的是上下文截断策略。很多项目简单粗暴地用“滑动窗口只保留最近 N 轮”结果把用户的原始需求、之前的工具调用结果全丢了Agent 变成了一个不断失忆的对话机器人。我见过因为截断丢失了用户地址Agent 在第 15 轮自信地下了一个配送地址是空白的订单业务方差点当场晕倒。上下文的管理不是“砍掉多少轮”的问题而是“哪些信息必须持久化”的问题。2.4 并发与成本的双重压力演示时只有一个用户在跑一次请求失败就重来一遍反正不花钱。上线后并发上来每个任务可能要消耗十几万 token多轮调用、工具结果反馈、上下文摘要重算每一样都在烧钱。成本一高有些人就开始降低模型规格从最强模型降级到便宜模型然后发现效果断崖式下跌。我见过一个项目演示时用最好的模型单次任务成本 3 块钱业务方说没问题。上线后一天几万个请求老板看到账单直接拍桌子。团队只好把模型换成便宜版本参数调激进结果 Agent 开始频繁幻觉、工具调用格式错误。这不是模型的问题是没有在架构上把“贵模型用在关键节点”“便宜模型用在简单环节”做分流。工程上不想办法优化成本结构最后一定是产品效果为账单买单。2.5 非确定性同样的输入今天行明天不行LLM 天然带有随机性即使把 temperature 调到 0模型版本更新、推理服务的负载变化、token 化细节差异都会导致同一段输入的输出产生波动。演示时你跑三次发现都成功就以为稳定了。上线后你跑三次可能一次成功、一次漏掉了工具调用、一次格式不对。非确定性最致命的地方在于它不是简单的“对错波动”而是会影响 Agent 的流程连续性。同一个意图上一次走了正常流程这一次模型决定先确认一下下一步又决定直接执行整个状态机的走向不可复现。这让测试和排障变得极其困难。你无法通过简单地“重新跑一遍”来复现 bug因为你面对的已经不是同一段轨迹了。3. 为什么我把锅扣给工程五个缺席的必备环节到目前为止你可能觉得这些现象都是模型能力不够、真实环境太复杂导致的。我承认这些客观原因都存在但工程上完全可以提前筑好防线。下面这五个环节在我看过的绝大多数“上线稀碎”项目里至少缺了两三个。3.1 没有把工具调用当“远程调用”设计Agent 项目里的工具调用本质上就是分布式系统里的远程调用。远程调用有一整套被反复验证过的规范超时控制、重试机制、幂等校验、熔断降级、请求追踪。可我见过太多 Agent 项目的工具调用就是一个裸奔的 HTTP 请求甚至一个裸奔的 Python 函数。工具层不做幂等重复调用就产生脏数据不做超时Agent 就在那里反复横跳不做熔断上游服务一抖Agent 第一个跟着崩。模型只是个决策器它本身不具备“这个工具挂了我就换个策略”的常识判断你必须在工程上替它兜底。说句不好听的你连“工具偶发失败重试一次”这种最基本的稳定性保障都不做凭什么要求上线稳定。3.2 没有把 Agent 流程当“有状态事务”管Agent 执行一个任务往往要经过多轮推理、多次工具调用这个过程是有状态的。今天的状态是什么、上一步做了什么、下一步该做什么、如果中间失败了这个任务要如何恢复——这些都需要一个显式的状态管理机制来支撑。很多项目完全没有状态管理。Agent 每一次 LLM 调用都是无状态的函数调用靠模型从对话历史里“感受”当前进度。对话历史一旦因为截断、摘要而丢失部分内容Agent 就不知道自己在哪一步了然后就开始胡说八道。正确做法是有一个任务状态对象Task State Object记录目标参数、已执行步骤、工具返回结果、需要用户澄清的问题等每一步决策前先加载状态而不是让模型每次从零开始推理。3.3 没有建立可观测性体系Agent 的单次任务里可能包含多次 LLM 调用和多次工具调用。任何一个环节出了问题如果没有 trace 系统你就只能看到“对话报错了”这种毫无信息量的结果。我见过很多项目排查问题时第一件事是去翻模型请求日志然后一条条人工比对几个小时过去了还是没定位到是哪个工具超时了。Agent 项目的可观测性至少要做到三层第一层是全链路 tracing标记每一次 LLM 调用和工具调用的 ID、耗时、输入输出第二层是状态快照记录每个任务在不同阶段的上下文、决策、中间结果第三层是轨迹回放能完整还原一个任务从开始到结束的每一步。没有这三样出了问题只能靠猜而靠猜不如早休息。3.4 没有建立评估集上线全靠感觉演示阶段评估 Agent 就是随便拿几个问题跑一下看看结果像不像样。这种评估方式最大的问题是不可重复、不可量化、不可回归。今天改动了一个 prompt你无法判断效果是变好了还是变差了因为没有一个固定的测试集和评分标准。工程化的 Agent 必须建立一套评估体系至少要包括目标场景用例集、评分标准、基准结果。哪怕最开始只有几十条用例用规则判定“是否调用了正确工具、是否得到最终正确状态”也比“感觉差不多”强。有了这套评估集你才能让 CI/CD 管线在模型版本升级、prompt 变更时自动跑回归保证每一个上线改动都不把现有能力搞坏。3.5 把模型幻觉当作品质问题而不是必选项最后这一点我会表达得比较直接。模型一定会出错这是一个不争的事实。工程要做的是通过架构设计把幻觉的破坏性降到最低而不是祈祷模型这次聪明一点。比如关键信息优先从工具返回的结构化数据中获取而不是让模型自己生成关键操作在执行前增加二次确认模型输出必经格式校验和字段校验不合格就重试或转人工高风险的领域涉及钱、订单、个人信息设置回退规则。工程做的不是让模型更聪明让模型更聪明的活应该交给模型厂商来优化。工程做的是给模型盖一个笼子能犯的错种类有限犯了错也能快速恢复不会引发不可控的后果。4. 一次真实事故的完整复盘从日志到根因讲故事永远是理解工程问题最好的方式。下面这个事故来自一个模拟的客服订单 Agent 项目细节已脱敏整个过程我完整经历了很有代表性。4.1 现象用户说“只是问一下”后台却多了三张订单用户给 Agent 发消息说“帮我按上次的地址再买一箱那个咖啡豆”Agent 回复“正在为您下单”然后用户又补了一句“等等我只是问问现在还有没有货先别下”。过了几分钟用户在订单列表里看到了三个待支付订单。客服查后台发现这三张订单是由同一个 Agent 任务创建的金额、地址都一样。用户投诉项目紧急上线第一个排查对象自然是模型“是不是理解错了”。4.2 排查过程从 trace 里看每一步由于项目上了基础的 trace 链路我们很快拉出了这个任务的时间线第 1 步模型识别到“购买咖啡豆”意图。此时用户还没有说“先别下”模型执行商品查询工具返回了库存充足这是一个正常的查询。第 2 步模型调用“创建订单”工具。工具调用发出后网关在 15 秒内没有返回响应触发了超时。工具层有一个自动重试逻辑功能本身没问题但重试时没有携带唯一的业务请求 ID。第 3 步重试的那一次请求实际在订单系统里成功创建了订单但因为响应响应体里有陈旧缓存字段模型侧并没有判断创建成功。第 4 步模型认为“创建订单”没成功用相同的参数再次调用“创建订单”工具于是又创建了一单。用户说“先别下”的那条消息被上下文截断策略裁剪掉了。因为这个策略是简单“只保留最后 5 轮”此时用户的更正已经被挤出上下文。Agent 压根没有机会感知到意图变更。最终三张订单的产生链条是请求超时 → 重试成功但被判定失败 → 再次调用成功 → 用户更正指令被截断。这造成的直接后果是三张订单里只有一张是用户想要且确认过的另外两张全是系统自己创建出来的。4.3 根因确认四个工程缺陷叠加顺着链路往回捋问题根本不用模型来背第一个是调用“创建订单”这样的非幂等工具时没有校验业务幂等键。正常的设计是每次 Agent 创建订单都要带上一个由会话 ID、用户 ID、确认参数生成的请求唯一标识服务端做去重。这个项目当时完全没做。第二个是工具调用超时之后重试逻辑没有判断“是否已经执行成功”。这类问题非常常见超时只能说明响应延迟不能说明业务没有执行。重试前必须通过查询确认状态。第三个是上下文截断策略过于粗鲁。系统只按“轮次”保留但没有把“用户的关键指令”和“待确认的参数”单独持久化导致关键意图被裁掉Agent 像一个失忆的接线员。第四个是 Agent 执行高风险的写操作创建订单前没有增加确认环节。模型在“工具返回未明确失败”的状态下完全靠生成结果判断“要不要重试”这种不确定性设计在工程上是不允许的。4.4 修复方案与验证这次事故后我们做了四件事为所有包含写语义的工具增加幂等键设计和去重校验。同一个任务派生出的同一业务动作重复调用时直接返回上一次结果保证不会产生重复数据。工具调用层区分“失败”和“超时”超时后不立刻重试而是发起一个查询动作确认业务状态再决定下一步。简单说就是不再让模型猜。上下文管理改为“结构化持久化”把用户的关键指令、确认过的参数、当前任务状态存到独立的 Task State 里普通对话轮次照常滑动窗口关键业务信息绝不因上下文截断而丢失。增加写操作的前置确认创建订单这类高风险动作必须由用户明确确认后才执行。模型可以“请求创建”但真正落库要走独立的审批式流程。修复后同类场景没有再出现重复订单。这件事之后项目组再没有人说“是模型不行”。5. 能直接落地执行的工程硬措施把 Agent 当系统来建设如果你准备新建或者重构一个 Agent 项目下面的措施建议直接抄它们都是经过实际项目验证的。5.1 工具层协议先行接口和后端服务一样对待工具定义时花时间把 schema 设计好哪怕前期慢一点后期会省很多事。每个工具必须有明确的输入输出协议、错误码规范和状态码语义。网络层面要设置合理的超时时间重试必须基于幂等策略写操作必须有全局唯一的请求 ID。把“创建订单”这类工具当成数据库事务来看待。另外工具返回的内容要同时包含“结构化字段”和“用户可读文本”。模型需要先用结构化字段做决策这样它不会自己发挥跑偏用户可读文本用来直接引用。数据缺失时宁可明确返回“此字段为空”也不要拼接一个“暂无信息”之类的模糊字符串让模型猜。5.2 编排层显式状态机取代自由发挥任务流程不要完全交给 LLM 自由规划。最简单的做法是先定义好粗粒度的状态机比如意图识别 → 参数收集 → 确认 → 执行 → 反馈每一步是一个状态LLM 只负责在状态内部做决策而不是从头到尾自由穿梭。同时为整个 Agent 任务设置一个最大循环次数和最长执行时长防止模型在工具调用上陷入无限循环。到达上限后直接终止返回“需要人工协助”的结果。Loop 控制这件事工程上很简单但不做就很容易出乱子。我知道有些团队怕限制循环会局限模型能力但你应该想清楚自由发挥的代价是无限 token 和排错地狱。5.3 上下文层把关键信息变成显式状态上下文窗口不足是必然的关键信息必须提前抽出来放到业务层管理。我在不少项目里的做法是维护一个“任务记忆”对象包含目标、已收集参数、待确认项、工具返回的引用在每次调用模型时把它嵌入上下文头部。对话历史滚动窗口只保留一般交流信息业务关键信息从业务层读取两者互不干扰。当一个任务持续很长时间原始历史太多时用摘要分级存储。比如“最近的 5 轮对话完整保留之前的先做一次结构化摘要”这样既不会把模型上下文撑爆又不会丢失早期关键约束。5.4 观测层trace、日志、回放一个都不能少Agent 项目一定要在第一天就把 trace 体系搭好而不是等出事故之后再补。每个任务都要有一个全链路 ID贯穿 LLM 调用、工具调用、状态流转和最终结果。日志里除了记录结构化数据还要记录模型输入的完整上下文和输出结果这些数据是事后排查的第一资料。更进一步建议把任务的输入输出轨迹以 JSON 形式存储专门为“轨迹回放”设计查询接口。这样一旦线上出现问题可以直接把那条轨迹拿出来重新跑看是模型决策问题还是工具调用问题。轨迹回放就像是飞机的黑匣子平时不起眼出问题时它能告诉你一切。5.5 评测层把“惊艳”固化成基线最后一条也是我强烈推荐做的把演示用例、线上经典型场景、历史问题场景收集成回归测试集。每条用例不仅要记录“输入”和“期望输出”最好还记录“期望调用的工具序列”。用这套测试集跑每天的模型版本更新、prompt 变更把“惊艳”固化成可自动验证的基线。一开始你可能只有三五十条用例没关系。每上线一个多月就从线上日志里挑出三类用例加进测试集成功案例防止回归、失败案例验证修复、边界场景爆露新问题。三个月后你就会有一份很有价值的回归集。这样每次提示词改动都能迅速看到它对已有能力的影响而不是等上线被业务方吼了才回头查。6. 个人体会别跟模型较劲跟不确定性较劲把这些话说完回到标题。你把 Agent 项目弄得“演示惊艳、上线稀碎”真不一定是模型不行、数据不行、算法不行。很多时候就是工程上懒惰了省略掉了那些“看不见但绝不可缺”的环节。我自己前几个项目就是吃了这个亏后来把工具层协议、状态管理、可观测性和回归集一项项补上之后Agent 在线上就开始变得“虽然偶尔笨但绝不会闯大祸”了。这个判断一定有人不同意但我坚持Agent 产品化与其赌模型一次比一次聪明不如把系统皮实程度做到你不怕它犯蠢。
平方复杂度无法被常规优化消除｜TaoToken 统一 Key 通道实测)
