做 Agent 这几年我最大的感受就一句话Demo 是表演生产是修行。见过太多团队PPT 上Agent 跑得行云流水PoC 演示时全场“哇”结果一上生产环境第一天就被真实流量教做人。要么答非所问要么任务执行到一半卡死要么并发一上来直接把后端打挂要么账单出来发现跑一个任务比雇个人还贵。最后项目组被业务方追着问“这东西到底能不能用”能当然能。但前提是你得把 Agent 当成一个真正的分布式系统来设计而不是当成一个“能聊天的 API”来包装。这篇文章我不聊概念只聊我踩过的坑和验证过的工程解法。标题里的问题我直接回答你Demo 惊艳、上线拉胯的根因是你在 Demo 阶段只证明了“模型能做什么”而在生产阶段需要解决的是“系统怎么扛住真实世界”。这两件事差了四道必须跨过去的坎。1. 先对齐认知Demo 和生产差的不是模型是系统1.1 Demo 为什么总是“惊艳”你回想一下自己见过的 Agent Demo基本都长一个样提前准备好输入挑一个模型发挥最好的场景跑一遍输出完美结果。如果中间失败了就重新跑一次或者干脆说“刚才网络波动我们再来一次”。这背后其实是三个“作弊”条件。第一输入是有限的、干净的。Demo 里问的问题不出十句词表、语境、格式都在可控范围内模型当然不容易跑偏。生产环境呢用户的输入千奇百怪有错别字、有方言、有阴阳怪气、有长尾专业术语甚至有人故意输入恶意指令模型要面对的分布完全不一样。第二失败是可以被无视的。Demo 跑挂了重跑一次就行观众不知道你重跑了。但生产环境里一条工单处理失败客户那边已经开始投诉了。失败率 2% 听起来不高放到一天十万次调用里就是两千个用户得到坏体验。第三链路里有人工兜底。Demo 时旁边大概率坐着一个工程师看见模型犹豫了就手动帮忙调整参数或者临时改 prompt 再来一次。生产环境没人坐在服务器旁边帮你“再来一次”所有兜底逻辑都得提前写进代码里。所以Demo 惊艳不说明 Agent 能力强只能说明你准备得好。真正决定生产成败的是模型之外那一整套工程系统。1.2 生产环境真正要命的东西生产环境下Agent 面对的不是“一个聪明的问题”而是一堆互相牵扯的约束。延迟要求用户等不了 30 秒才看到响应尤其交互式场景超过 5 秒就开始流失。并发压力你以为同时只有几十个人用结果是几百上千个会话同时进来每个会话背后还有多轮模型调用。成本约束一个复杂任务可能要调用 10 次甚至 20 次大模型 API单次任务成本从几分钱涨到几块钱月度账单直接失控。稳定性和一致性同一条工单上午处理的结果和下午处理的结果可能不同同一个用户问同一个问题两次回答可能完全不一样。这在线下无所谓在正式业务里就是事故。合规与审计Agent 代表企业对外服务它说了什么、做了什么、基于什么信息做的决策都要能追溯。Demo 阶段你不需要回答“它为什么这样说”生产阶段你必须回答。我把这些约束列出来不是为了吓唬你而是想说明一个核心观点生产级 Agent 的本质是一个由“模型 工具 数据 人工审批 监控”组成的复杂系统。模型的智能只是系统里的一个组件工程要做的是把这个组件的不可控性用系统设计兜住。对比维度Demo 阶段生产阶段输入分布有限、可控、提前挑选无限、长尾、对抗失败容忍度可重跑、可忽略有 SLA、有投诉并发压力单用户演示高并发真实流量成本敏感度不敏感直接关系 ROII可观测性人盯着屏幕日志、追踪、告警合规审计不需要必须可追溯2. 第一道坎让 Agent 的行为具备确定性2.1 别让模型自由发挥用流程框住边界大模型天生是“发散”的同一个 prompt 给它这次它按步骤来下次它可能直接跳过第二步。在 Demo 里这显得很“智能”但在生产里这就是灾难。你想想一个订单处理 Agent如果它每次执行流程的步骤都不一样你怎么跟它对账怎么保证它不会漏掉支付确认这一步我现在的做法是能不用 Agent 的地方尽量不用用也要把 Agent 关进流程的笼子里。具体来说是“Workflow Agent”的混合架构。流程主干用代码写死比如接收工单 → 信息提取 → 工具调用 → 结果校验 → 生成回复 → 归档。这些步骤的顺序是确定的不允许模型随意跳过。模型只负责在几个关键节点上做“智能决策”比如判断用户意图、决定调用哪个工具、抽取哪些关键字段。用代码框住流程的好处非常直接流程的每一步都可以记录状态失败可以从指定步骤重试审计日志也清晰。模型的自由度被限制在“决策点”上而不是让它从头到尾自由发挥。这就像请了个很聪明的实习生你给他明确的任务清单和审批权限而不是让他自己决定整个业务流程。2.2 给模型上“结构性护栏”框住流程还不够模型的输出也必须约束。生产环境里我要求所有模型输出必须走结构化格式无论是 JSON 还是严格的字段列表。绝对不能允许模型自由输出一段散文然后让下游代码去“理解”。具体做法有几层从软到硬Prompt 约束在指令里明确输出格式给出 few-shot 示例。这是最便宜的一层但可靠性有限只能作为基础。结构化输出 / 工具调用规范现在主流模型 API 都支持指定输出结构比如 OpenAI 的 structured output、或者让它必须调用某个工具来返回结果。把原本“自由文本”的环节强制转成“函数调用”模型会老实很多。Schema 校验模型返回后代码层立刻做 JSON Schema 校验不符合 schema 就触发重试而不是硬着头皮继续解析。枚举与白名单能枚举的字段绝不让模型自由发挥。比如“订单状态”只有“待支付/已支付/已取消/已退款”四种那就逼它只能输出这四个值。工具调用也一样只给它一个白名单工具列表白名单之外的一律拒绝。这块我的实测经验是加了 schema 校验和工具白名单之后Agent 的行为可控性会提升一个量级但代价是模型偶尔会“无从下手”需要你在 prompt 里把边界条件写得更细。别怕 prompt 长生产环境的 prompt 就该像操作手册而不是闲聊。3. 第二道坎让 Agent 具备生产级韧性3.1 重试和超时不是简单加个 try-catchDemo 里模型调一次不行就再调一次反正人看着。生产环境里一个 Agent 任务可能横跨多次模型调用、几十次工具调用、多轮外部 API 请求任何一环失败都会导致整个任务中断。很多团队一开始只做了最简单的重试报错就重试。但这会带来三个问题重试风暴、重复执行副作用、无限阻塞。你想想下游支付接口已经扣款成功了但你这边因为网络超时重试了一次结果用户被扣了两笔钱这锅谁背所以我的重试策略从来不是无脑重试而是分情况讨论幂等操作比如查询、生成文本可以放心重试配上指数退避和抖动jitter。非幂等操作比如创建订单、发送通知、扣款重试前必须先查状态确认上一次到底有没有成功。或者干脆不自动重试直接转人工处理。超时控制每一次模型调用、每一个工具调用都必须单独设置超时时间而且超时时间要根据场景来定不是拍脑袋设个 30 秒。比如意图识别这种简单任务5 秒内就该返回复杂报告生成给它 90 秒也不过分。我给团队定过一个铁律一个 Agent 任务的任何一个环节都必须有明确的超时、重试、降级和人工兜底方案少一个都不允许上线。这条铁律帮我挡掉了至少一半的生产事故。3.2 状态持久化与断点续跑让任务“不会丢”Agent 的另一个生产痛点是它经常跑一半挂了——进程重启、服务器宕机、网络分区什么都有可能。如果任务状态只存在内存里重启就意味着任务彻底丢失用户端看到的就是“工单神秘失踪”。解决思路其实不那么神秘把 Agent 的每一步执行状态落库。用一张任务状态表记录任务 ID、当前步骤、输入输出、中间结果、重试次数、时间戳。每一步执行完就更新一次状态。有了这张表重启之后你可以扫描所有“进行中”的任务从最后一步继续执行而不是从头再来。这就是所谓的“断点续跑”。实现成本不高但收益极大它把 Agent 从“一次性的对话”变成了“可恢复的异步任务”。我还建议把每次模型调用的完整上下文和中间结果都存下来。不要只存最终结果因为排查问题的时候你往往需要知道“它当时看到了什么信息才做出那个决定”。这一步存储开销不大但调试价值极高。3.3 关键节点必须有人类审批入口这个点很多技术团队会忽略。技术人觉得 Agent 全自动很酷但业务方不敢用——出了事谁负责所以生产落地必须设计“人工介入点”。哪些节点需要人工审批我给个参考原则影响资金的操作支付、退款、转账绝不能自动执行必须留给人审。影响用户账号的操作封号、改权限、删数据必须人工确认。对外发布类操作自动生成的内容如果要发给客户或公开上线建议人工审核。不确定性高的操作模型置信度低、或者与历史行为模式差异大的决策自动转人工。这块的实现就是在工作流引擎里增加一个“等待人工审批”的状态节点。任务执行到该节点时挂起推送通知给对应的审批人审批通过后再继续。这样可以兼顾效率和安全。我见过最成功的 Agent 落地项目都保留了这个“人工闸门”业务方给技术团队的信任度明显高很多。4. 第三道坎让 Agent 从黑盒变白盒4.1 每一层调用都要留下痕迹模型输出和工具调用的排障和传统后端完全不一样。传统后端你打几条日志看看报错堆栈问题基本就定位了。Agent 的问题是它没有“报错”只是做了个错误决策。比如它把一个 VIP 客户的投诉工单判定为普通咨询没有报错但结果完全错了。你靠什么发现和定位这种问题只能靠全链路追踪和完整留痕。我在落地时要求三个“必须留”模型调用必须留prompt、response、token 数、模型版本、温度参数、延迟、成本全都要记录。这不仅是排查问题也是后续做评估和优化的数据基础。工具调用必须留调了什么工具、传了什么参数、返回了什么结果、耗时多久、是否成功。上下文链路必须留这个 Agent 之前说过什么、用户上一轮问过什么、中间检索到了哪些文档片段。没有上下文单看一条日志根本还原不了现场。技术上可以接开源的追踪方案比如 Langfuse、LangSmith也可以自己在系统里打结构化日志。关键是字段要全、格式要统一、链路要串起来。用 trace 也好用 request_id 串联也好至少要能回答一个问题“这个用户的问题Agent 当时看到了什么、想到了什么、做了什么最终为什么给出这个答案”4.2 评测不是一次性的要建回归集可观测性不只是“事后查日志”还有一个更重要的含义持续评估。很多团队的 Agent 上线后就开始“裸奔”没有人知道它今天的表现比上周好了还是差了。直到业务方投诉“最近 Agent 变笨了”才发现是改了 prompt 之后把前面的能力破坏了。这本质上就是缺少回归评测。我现在的习惯是每个 Agent 项目上线前必须建一个评测集哪怕刚开始只有 50 到 100 条真实的脱敏问题。每条问题标注好期望的答案或者评判标准。一旦模型版本升级、prompt 调整、工具逻辑修改就跑一遍评测集对比“通过率、准确率、关键步骤成功率”分数掉了就不允许上线。评测集不用一步到位可以每两周根据线上反馈补一批“线上翻车案例”进去。久而久之它就会变成整个项目的安全网。这个投入看起来是“额外成本”但实际上它才是防止你上线之后反复返工的最省钱手段。5. 第四道坎并发、性能与成本决定你能否规模化5.1 别让用户干等模型推理全部异步化Demo 是同步等待的用户提问转圈模型出结果展示。这个模式在 Demo 里没问题但生产环境有两个致命问题第一用户等不了。一个复杂任务内部可能要串行调用三四次模型总耗时 20 秒以上。让用户盯着页面转圈 20 秒体验极差。第二同步等待会压垮服务。如果每个请求都占用一个线程去等模型返回并发一上来线程池瞬间耗尽后面的请求全部排队系统整体雪崩。我的解决方案是交互式的简单任务走同步流式返回复杂任务一律走异步任务队列。具体来说前端提交任务后接口立刻返回一个任务 ID后端把任务丢进消息队列由 Worker 消费执行执行过程中通过 SSE 或 WebSocket 持续推送进展用户端展示进度条任务完成后再展示最终结果。这套模式天然支持断点续跑和人工审批也天然能扛高并发因为你把“等待”从同步线程里释放出来了。队列选型不用纠结Redis Stream、RabbitMQ、Kafka 都行看团队熟哪个、量级多大。关键是把“任务执行”和“用户请求”彻底解耦。这一步是所有 Agent 生产化的分水岭做了你就开始有系统思维了不做永远在打补丁。5.2 缓存、模型分级与路由是省钱和提速的杀器Agent 的调用成本很多人是等到月底看账单才肉疼的。但成本控制是生产环境绕不开的坎尤其当你的业务量上来之后一次任务调用多次大模型 API每天几十万个任务账单是天文数字。我的前三板斧是语义缓存把用户的问题向量化跟历史问题做相似度检索如果命中且答案可以复用直接返回缓存结果不调用模型。对于客服、文档问答这类高频重复场景缓存命中率能做到 20% 到 30%省下的费用非常可观。模型分级路由不是所有问题都需要 GPT 级别的能力。简单分类、抽取、意图识别用小模型或者量级小得多的模型就够用了只有复杂推理才用大模型。在业务入口先做一次“难度分级”自动路由到不同档位的模型整体成本能降一大截。提示词与服务瘦身每次调用的 prompt 越短token 越少费用越低。把冗长的背景知识做成动态检索按需注入而不是一股脑塞进 context。这块优化既是省钱也是提速。成本优化要当成一个持续指标来看跟延迟、成功率一样重要。我甚至建议在监控面板上把“单任务平均成本”和“单任务成功率”放在一起看防止为了省钱把质量省没了。5.3 限流、降级与熔断Agent 也要有“应急预案”生产系统最常见的死法不是模型能力不够而是流量高峰直接把下游打挂了。Agent 比普通服务更危险因为它会在一个任务里连番调用多个下游任何一个小下游的抖动都会被放大。所以生产环境必须有明确的“保护开关”限流对模型 API 的调用要限流对下游工具要限流对用户请求的并发要限流。超出阈值就排队或者直接提示“当前服务繁忙”。降级模型不可用时先降到小模型小模型也不可用就降级到模板话术模板话术也不行就直接转人工。每一层降级都要提前定义清楚而不是等故障发生了再开会讨论。熔断连续 N 次调用下游失败立刻熔断暂停调用该服务一段时间避免把已经故障的下游打死。这跟微服务的熔断思路一模一样。这块很多人会拖到出事才做但我建议你在首次上线前就做完。因为生产事故并发起来的时候现场没有时间让你写降级逻辑。提前定义好预案上线后你半夜被叫醒的次数会少一半。6. 从 Demo 到生产我的落地顺序建议如果现在你要把一个 Agent 项目推向生产我的建议是不要贪大求全按以下顺序来第一步选一个边界清晰的窄场景。不要一上来就做“全能助手”就找一个业务方痛点明确、流程固定、频次高的场景。比如“工单自动分类 初级回复建议”“合同关键条款提取”越小越好。场景边界清晰评测集好建效果容易验证业务方也容易看到价值。第二步先手工把闭环跑通。在这个阶段哪怕每一步都是人工干预也没关系。目的是把数据链路、角色分工、业务规则彻底搞清楚。我见过太多项目跳过这一步直接让 Agent 跑结果业务方说“你这个流程不对”又推倒重来。第三步用 Workflow 固化流程加上状态持久化和留痕。先让系统具备断点续跑、人工审批、日志追踪这三个能力。如果你发现自己写了一大堆胶水代码才可以搞定这是正常的也是值得的。第四步再考虑模型优化和多场景扩展。前面几步稳了再去上缓存、模型分级、自动评测这些进阶手段。切忌一上来就搞复杂方案地基没打好优化做得越多窟窿越大。最后说一点我自己的体会吧。Agent 生产落地这件事难点从来不是“模型不够聪明”模型的能力每个季度都在进步真正的瓶颈一直是我们这些工程师有没有用系统的思维去对待它。你把 Agent 当聊天机器人它上线就给你搞出各种幺蛾子你把它当一个可靠、可观测、可控制、有成本意识的软件系统来建设它就能成为业务里真正稳定运行的生产力工具。那些 Demo 惊艳、上线拉胯的项目差的往往不是 AI 能力而是这四道工程坎没迈过去。希望这篇文章能让你少走我当年走过的弯路。