1. 从“能跑”到“能扛”为什么你的Agent一上线就露馅我见过太多团队在Agent项目上栽跟头包括我自己早期带的一个项目。当时我们在本地环境里跑通了一个多轮对话的智能体能查天气、能订会议室、能根据用户情绪调整回复语气演示的时候行云流水老板看完直接拍板“下周上线。”结果上线第一天用户量刚过两百系统就开始出现各种诡异现象同一个问题问两遍回答完全不一样用户说“帮我订明天下午三点的会”Agent回复“好的已为您预订”但实际上什么都没发生更离谱的是有用户连续发了三条消息Agent把三条消息的内容混在一起理解给出了一个完全风马牛不相及的答案。这不是个例。我后来跟不少做Agent的同行聊发现大家踩的坑惊人地相似。Demo阶段跑通的那条路径和线上真实用户走的那条路径中间隔着一道巨大的鸿沟。这道鸿沟不是靠加几台服务器、调几个参数就能填平的它涉及到Agent系统从“单次执行”到“持续服务”的根本性转变。这篇文章我想把这道鸿沟拆开来讲清楚。如果你正在做Agent相关的项目或者准备把Agent从实验室推向真实用户那这些内容应该能帮你少走不少弯路。我会从状态管理、工具调用的可靠性、多轮对话的上下文一致性、以及线上环境的不可预测性这几个维度逐一拆解那些“Demo能跑、上线就崩”的底层原因并给出我在实际项目中验证过的应对思路。提示本文讨论的Agent指的是基于大语言模型构建的、具备工具调用能力和多轮交互能力的智能体系统不涉及具体的模型选型或框架推荐重点在于工程化落地的核心问题。2. 状态管理Demo里的“一次性执行”和线上的“持续服务”是两码事2.1 Demo阶段的状态是“假状态”在Demo里我们通常是这样跑Agent的用户输入一个问题Agent调用一次或几次工具返回一个结果流程结束。整个过程中Agent不需要记住任何东西因为下一次请求来的时候一切从头开始。这种模式我称之为“无状态执行”它跑起来很顺畅因为没有任何历史包袱。但线上不是这样。线上用户会连续发消息会在对话中途改变主意会引用之前说过的内容会在等待回复的时候又补一句。Agent必须记住这些上下文才能给出合理的回应。这时候状态管理就成了第一个卡脖子的问题。我见过一个典型的错误做法把整个对话历史塞进每一次请求的prompt里。刚开始对话短的时候没问题但随着轮次增加prompt越来越长不仅消耗大量token还会导致模型注意力分散回复质量急剧下降。更严重的是当对话历史超过模型的最大上下文长度时系统直接报错用户看到的就是“服务异常”。2.2 状态管理的三个核心问题在实际项目中我把状态管理拆成三个必须解决的问题第一个是状态存储。对话历史、工具调用记录、中间结果这些数据存在哪里内存数据库还是缓存内存方案在单机Demo里没问题但线上多实例部署时用户请求可能被负载均衡打到不同的实例上如果状态只存在本地内存用户就会遇到“上一秒还记得下一秒就失忆”的情况。第二个是状态压缩。对话轮次多了之后不可能把所有历史都传给模型。需要有一套策略来决定哪些信息保留、哪些丢弃、哪些摘要化。我试过几种方案滑动窗口保留最近N轮、按重要性打分保留关键轮次、定期对历史做摘要压缩。每种方案都有取舍滑动窗口实现简单但可能丢掉关键信息摘要压缩能保留长期记忆但会增加额外的模型调用开销。第三个是状态一致性。当Agent同时处理多个用户的请求或者同一个用户有多个并发会话时状态的一致性就变得很关键。我遇到过一种情况用户A在对话中让Agent修改了一个全局配置用户B的对话正好也在读取这个配置结果用户B看到了一个中间状态的数据导致回复逻辑出错。这种问题在Demo里根本不会出现因为Demo只有一个用户、一个会话。2.3 一个可落地的状态管理方案经过几个项目的迭代我目前比较推荐的状态管理方案是这样的会话级状态存在Redis里每个会话一个key设置合理的过期时间。Redis的好处是读写快、支持多实例共享、有过期机制自动清理冷会话。对话历史做分层存储最近5轮完整保留5到20轮做摘要压缩20轮以上的只保留关键实体和意图标签。这样既能保证短期上下文完整又能控制prompt长度。工具调用结果单独存储不直接塞进对话历史。因为工具返回的数据可能很大比如一个查询接口返回了几十条记录全塞进prompt会瞬间撑爆上下文。我的做法是只把工具调用的摘要和关键字段放进对话历史完整结果存在外部存储里需要的时候再按ID去取。这套方案不是银弹但在我经历的几个项目中它把状态相关的线上问题从“频繁出现”降到了“偶尔发生”。关键是它让状态管理变得可观测、可调试出了问题能快速定位是哪个环节的锅。3. 工具调用从“能调通”到“调得稳”之间隔着多少坑3.1 工具调用的可靠性被严重低估Demo里调工具通常只考虑“能不能调通”。比如一个查询天气的工具Demo里测试几次返回了正确结果就认为这个工具没问题了。但线上环境里工具调用的可靠性问题会以各种意想不到的方式暴露出来。我统计过我们一个线上Agent项目的工具调用失败原因排在前几位的分别是网络超时、第三方接口限流、返回数据格式不符合预期、工具本身抛异常、以及模型生成的调用参数格式错误。这些失败原因里只有最后一个是模型的问题其他都是工程问题。但Demo阶段我们往往只关注模型能不能正确生成调用参数忽略了工程层面的可靠性。3.2 工具调用的超时与重试策略超时是工具调用最常见的失败原因。Demo里网络环境好接口响应快很少遇到超时。但线上环境网络抖动、第三方服务负载高、DNS解析慢各种情况都可能导致超时。我的经验是每个工具都必须设置合理的超时时间并且要有重试机制。但重试不是简单地把请求再发一遍需要考虑几个问题重试次数一般设置2到3次太多会拖长整体响应时间用户等不及。重试间隔第一次重试可以立即进行第二次重试需要退避比如等1秒、2秒避免给已经过载的第三方服务雪上加霜。幂等性不是所有工具都适合重试。查询类工具重试没问题但写入类工具重试可能导致重复操作。比如“创建订单”这个工具如果第一次调用超时但实际已经创建成功重试就会创建两个订单。对于这类工具要么不重试要么在重试前先查询确认。注意重试策略必须和工具的业务语义绑定不能一刀切。我见过一个项目对所有工具都配置了3次重试结果导致用户被重复扣款排查了很久才发现是重试策略的问题。3.3 工具返回结果的容错处理即使工具调用成功返回了返回的数据也不一定能直接用。第三方接口的返回格式可能变化字段可能缺失数据类型可能和预期不一致。Demo里我们通常假设返回数据是完美的但线上必须做容错处理。我的做法是在工具和Agent之间加一层“结果适配器”。这个适配器负责校验返回数据的完整性对缺失字段填充默认值对异常格式做转换以及把原始结果转换成Agent容易理解的格式。这层适配器看起来增加了工作量但它把工具的不确定性隔离在了Agent之外让Agent的输入更加稳定。3.4 模型生成调用参数的错误处理模型生成工具调用参数时偶尔会犯错。比如参数类型不对、必填参数缺失、参数值超出范围。Demo里遇到这种情况通常就是重新生成一次。但线上不能这么随意因为每次重新生成都意味着额外的延迟和成本。我的处理策略是分两级第一级是参数校验在调用工具之前先检查参数是否合法不合法就直接返回错误给模型让模型重新生成第二级是参数修复对于一些常见的错误比如字符串类型的数字、缺少默认值的可选参数尝试自动修复而不是重新生成。这样能减少不必要的模型调用提升响应速度。4. 多轮对话的上下文一致性为什么Agent会“前言不搭后语”4.1 上下文丢失的几种典型场景多轮对话是Agent的核心能力但也是线上问题的高发区。我总结了几种最常见的上下文一致性问题场景一用户中途切换话题。用户先问“帮我查一下北京的天气”Agent回复后用户接着说“那上海呢”。这时候Agent需要理解“那上海呢”是在延续上一个查询意图只是把地点从北京换成了上海。但很多Agent会把这个输入当成一个全新的问题回复“请问您想查询上海的什么信息”。场景二用户引用之前的对话内容。用户说“就按刚才说的那个方案来”Agent需要知道“刚才说的那个方案”具体指什么。如果对话历史管理不当Agent可能已经丢失了“刚才”的上下文导致无法理解用户的指代。场景三多轮工具调用的状态传递。有些任务需要多次工具调用才能完成比如先查询用户信息再根据用户信息查询订单再根据订单信息发起退款。每一步的工具调用都依赖上一步的结果。如果中间某一步的状态没有正确传递整个流程就会断掉。4.2 上下文一致性的技术保障要解决这些问题需要在几个层面做保障第一对话历史的完整记录。每一轮的用户输入和Agent回复都要完整记录包括工具调用的输入输出。这些记录是上下文理解的基础。我建议在存储对话历史时不仅存文本内容还要存结构化的元数据比如意图标签、实体列表、工具调用ID等方便后续检索和引用。第二意图的显式传递。在多轮对话中用户的意图可能会延续、切换或嵌套。我倾向于在每一轮对话处理后显式地记录当前对话的意图状态并在下一轮处理时把这个状态作为输入的一部分。这样即使模型没有从对话历史中推断出意图也能通过显式状态来保证一致性。第三指代消解的处理。对于“那个”“刚才说的”“之前的方案”这类指代需要在进入模型之前做预处理把指代替换成具体内容。这个预处理可以基于规则也可以基于模型。我的经验是对于常见的指代模式规则匹配的效率更高、更可控对于复杂的指代再交给模型处理。4.3 上下文窗口的管理策略上下文窗口是有限的不可能把所有历史都放进去。我目前采用的策略是“三层窗口”最近窗口最近3到5轮对话完整保留包括工具调用细节。摘要窗口5到15轮的对话保留摘要信息包括每轮的意图、关键实体、工具调用结果摘要。长期记忆15轮以上的对话只保留关键事件和用户偏好比如用户之前提到过的特殊要求、重要的业务实体。这个策略的核心思想是越近的对话越重要保留越完整越远的对话越可能只提供背景信息保留摘要即可。实际运行下来这个策略在大多数场景下都能保证上下文的一致性同时控制住prompt的长度。5. 线上环境的不可预测性那些Demo里永远不会出现的情况5.1 用户输入的多样性远超想象Demo里的测试用例通常是精心设计的输入规范、意图明确。但线上用户的输入千奇百怪有错别字、有方言表达、有中英文混杂、有表情符号、有超长文本、有恶意注入。我见过用户输入一整段代码让Agent解释也见过用户输入一堆乱码测试系统反应还见过用户故意输入诱导性的内容试图让Agent说出不该说的话。这些情况在Demo里都不会遇到但线上必须处理。我的做法是在Agent之前加一层“输入预处理”负责过滤明显恶意的输入、对超长输入做截断或分段、对特殊字符做转义、对多语言输入做语言检测。这层预处理不能解决所有问题但能过滤掉大部分明显的异常输入减轻Agent的负担。5.2 并发请求下的资源竞争Demo里通常只有一个用户串行执行。线上是成百上千个用户同时请求每个请求都可能触发工具调用、模型推理、状态读写。这时候资源竞争就成了问题。我遇到过几种典型的并发问题数据库连接池被耗尽、模型推理服务的请求队列堆积、缓存击穿导致大量请求直接打到数据库。这些问题在Demo里根本不会出现因为Demo的并发量太低资源永远够用。解决并发问题的思路和传统后端服务类似限流、降级、熔断、异步化。但Agent系统有一些特殊性比如模型推理的耗时较长不能简单地用同步阻塞的方式处理。我的做法是把Agent的执行流程拆成多个异步阶段每个阶段有独立的线程池和队列阶段之间通过消息队列传递状态。这样即使某个阶段出现拥堵也不会阻塞整个流程。5.3 模型输出的不确定性同一个输入模型可能给出不同的输出。这在Demo里可能被忽略因为Demo通常只关注“能不能给出合理回复”不关注“每次回复是否一致”。但线上环境里输出不一致会导致用户体验问题也会给测试和排查带来困难。我处理模型输出不确定性的方法是对于关键决策点增加确定性约束。比如工具调用的参数生成可以通过few-shot示例和格式约束来减少随机性对于回复内容可以通过模板和规则来保证关键信息的一致性。当然完全消除不确定性是不可能的但可以把不确定性控制在可接受的范围内。6. 从Demo到线上的工程化改造清单6.1 必须补齐的基础设施如果你正准备把Agent从Demo推向线上以下这些基础设施是必须补齐的基础设施Demo阶段线上阶段优先级状态存储内存Redis/数据库高日志记录控制台打印结构化日志链路追踪高监控告警无指标采集告警规则高限流熔断无网关层限流服务层熔断高配置管理硬编码配置中心动态刷新中灰度发布无按用户/流量灰度中压测方案无全链路压测中这张表里的每一项都是我在实际项目中踩过坑之后补上的。没有状态存储用户会话会丢失没有日志和监控出了问题只能靠猜没有限流熔断一个第三方接口的抖动就能拖垮整个系统。6.2 上线前的检查清单在正式上线之前我通常会过一遍这个检查清单所有工具调用是否都有超时和重试配置对话历史是否有清理和压缩策略是否有输入预处理和输出过滤关键路径是否有降级方案是否能在不重启服务的情况下调整配置是否有办法复现线上问题日志、快照、回放压测是否覆盖了主要场景和峰值流量这个清单不是万能的但能覆盖大部分常见的线上问题。每次上线前过一遍能避免很多低级错误。6.3 上线后的持续迭代上线不是终点而是起点。线上运行过程中会不断暴露新的问题。我的经验是上线后的前两周是最关键的时期需要密切监控各项指标及时响应异常。我通常会关注几个核心指标请求成功率、平均响应时间、工具调用失败率、用户会话时长、用户主动结束对话的比例。这些指标能反映系统的健康度和用户体验。如果发现某个指标异常就顺着链路往下查定位到具体的环节。另外我会定期分析线上对话日志找出Agent表现不好的案例归纳出共性问题然后针对性地优化。这个过程是持续迭代的没有一劳永逸的方案。7. 一些踩坑之后的个人体会做Agent项目这几年我最大的体会是Demo和线上之间的差距本质上不是技术差距而是工程成熟度的差距。Demo关注的是“能不能”线上关注的是“稳不稳”。这两个目标的实现路径完全不同。另一个体会是Agent系统的复杂性不在于模型本身而在于模型和外部世界的交互。工具调用的可靠性、状态的一致性、上下文的连贯性这些才是真正消耗精力的地方。模型选型固然重要但工程化能力才是决定项目成败的关键。还有一个很实际的建议如果你正在做Agent项目尽早把线上环境搭起来哪怕只有少量真实用户。真实用户的输入和行为会帮你发现很多在Demo里永远想不到的问题。我见过太多团队在Demo阶段反复打磨上线后才发现方向错了。早一点接触真实环境早一点暴露问题早一点调整成本会低很多。最后分享一个小技巧在Agent的每个关键决策点加一个“决策日志”记录模型为什么选择这个工具、为什么生成这个参数、为什么给出这个回复。这些日志在排查问题时非常有用能帮你快速定位是模型的问题还是工程的问题。这个习惯是我从一个资深工程师那里学来的用了之后排查效率至少提升了一倍。
