“演示的时候全场鼓掌上线第一天就被业务方在群里了一整页。”——这是我做企业 Agent 落地这几年听到最多的一句吐槽。说句实话Agent 的 Demo 是全世界最容易做的东西一个漂亮的对话界面接一个大模型预置几个“精心设计过”的用例效果足以惊艳全场。但一旦接到真实的企业环境里流量一上来、数据一变脏、第三方接口一抽风那套 Demo 立刻原形毕露延迟飙升、Token 账单起飞、偶尔还给你来一句“抱歉我好像卡住了”。问题不在于大模型不够聪明而在于我们把“能跑通”当成了“能上线”。企业级 Agent 生产落地本质上是一个系统工程问题从并发控制到记忆管理从工具可靠性到可观测性评测每一道坎都是我在项目里真实踩过、填过、返工过的。这篇文章就把我这些年积累的“四道坎”工程解法摊开讲清楚每个问题我都会告诉你根因在哪、怎么解、代价是什么。1. 先把病根说透为什么你的 Demo 惊艳一上线就拉胯很多团队拿到 Agent 任务的第一反应是“快把流程跑通”这个思路没错但错在把“跑通”当成了终点。要搞明白生产环境为什么总是锤爆 Demo得先分清这两者之间到底隔着多少看不见的差异。1.1 Demo 环境与生产环境之间的真实差距我做技术选型前喜欢做对比表把两条环境的变量摆出来你会立刻看到问题在哪对比维度Demo 环境生产环境并发压力1~2 个人工测试成百上千用户同时发起任务数据质量精心挑选的干净样例脏乱差、缺失字段、格式混乱的真实数据外部依赖可控的模拟接口不稳定的第三方 API、内部老旧系统运行时长几分钟内看结果全天候运行跨天跨周持续服务容错要求失败就重新点一下失败要自愈、可重试、可恢复、可解释可观测性看对话内容就够了需要全链路追踪、日志审计、成本核算安全合规无所谓权限隔离、数据脱敏、敏感操作须确认丹尼尔·卡尼曼讲系统一和系统二Agent 也有类似的“快思考”和“慢思考”但企业场景里更要命的是“乱思考”。Demo 里你只给 Agent 准备了三条最优路径生产环境里它要面对的是三百条岔路、三百种边界情况。你把 Demo 里的路径做得再顺滑都覆盖不了真实世界的分叉。1.2 拉胯的三种典型姿势你中招了哪一个根据我观察过的项目生产环境翻车基本集中在三个姿势上非常典型姿势一单线程串行把 Agent 当“管道工”。一个任务从头到尾只有一个 Agent 在跑所有动作串行执行调一次大模型、调一个工具、再调一次大模型全程没有任何超时兜底或并发调度。上线后用户稍微一多队列立刻积压P99 延迟从 Demo 时的 3 秒飙升到 30 秒。业务方根本分不清你是“在思考”还是“卡死了”。姿势二上下文越滚越大Token 账单直线起飞。Agent 为了“记住”之前聊过的内容把整段历史对话无脑塞进提示词里一轮两轮还好十轮之后上下文塞满了冗余信息响应越来越慢、越来越贵还经常产生“记忆混乱”把前面说过的话后面又推翻。业务方看着账单心态直接崩了。姿势三外部依赖一碰就碎。你依赖的 CRM 系统、订单接口、支付回调平时好好的高峰一过就超时报错信息还不规范。Agent 调度链里任何一个环节出问题整个任务就挂掉而且没有重试、没有降级、没有兜底话术用户只会看到一句干巴巴的“系统开小差了”。三个姿势背后其实只有一个根因把“模型能力”当成了“产品能力”。模型是很强但企业 Agent 不是“一个模型 一个对话框”而是一个由推理、工具、记忆、控制流组成的分布式系统。系统的稳定性不是靠模型“聪明”撑出来的是靠工程“笨功夫”垒出来的。1.3 判断项目水平的标尺从“玩具级”到“生产级”我会用三个硬指标判断一个 Agent 项目到底能不能碰生产P99 延迟、单任务成本、无人干预完成率。这三个指标是生产级系统的试金石。Demo 项目往往三项指标都没有统计过因为跑一两次根本测不出分布。而生产级项目至少要做到P99 延迟控制在业务可接受范围内通常 10 秒以内单任务成本有预算上限比如一次业务操作不超过 0.5 元无人干预完成率能进入指标监控比如 90% 以上。没有这三项数据任何“上线”的判断都是拍脑袋。2. 第一道坎并发与性能——别让 Agent 在流量洪峰里裸奔很多团队选型时都忽略了框架的并发模型等用户量上来了才着急忙慌地扩机器扩完发现瓶颈根本不在机器上而在代码架构里。这块必须从底子开始捋。2.1 主流 Agent 框架的并发能力底细现在主流的 Agent 框架比如 LangGraph、AutoGen/AG2、CrewAI、agno以及 Spring AI Agent 这类 Java 生态的方案底层的并发模型差异非常大。有的框架天然支持异步事件循环有的框架是线程阻塞模型有的框架本身还是一个“单机玩具”需要你自己在外面套调度层。选型时不要看 Demo 跑得多顺要看三个点是否支持异步并发、是否有内置的图状态调度、是否支持任务级别的隔离和恢复。以 Python 生态为例LangGraph 的 StateGraph 本身支持多线程和异步但你在状态节点里如果写了同步阻塞的 HTTP 调用照样会把整个执行线程堵死。agno 这类轻量框架在并发方面更依赖你对底层异步机制的理解。如果你主要用 Java 技术栈Spring AI Agent 的响应式模型倒是个不错的选择但生态相对年轻踩坑资料少要有心理准备。我的建议很朴素框架只是工具并发能力最终取决于你的架构设计和资源规划。别迷信“用了某某框架就能扛住并发”那是假的。2.2 扛并发需要做的四件实事不管选哪个框架下面这四件事你都得做扎实缺一不可其一限流与队列。给 Agent 服务入口加令牌桶或者信号量控制同时执行的 Agent 任务数量。企业场景中 LLM 服务的 QPS 是有硬上限的你不做限流上游模型服务会先被你的任务洪峰打爆。常见做法是前置一个消息队列比如 RabbitMQ、Kafka把用户请求削峰填谷Worker 按固定速率消费。其二超时控制要做到“每一层都有”。大模型调用要设超时工具调用要设超时整个 Agent 任务要设总超时。我在项目里通常是模型调用超时 60 秒、单步工具调用超时 15 秒、整个任务超时 180 秒超时后进入兜底逻辑。注意超时时间不能一刀切要根据实际场景调。其三重试要有指数退避和抖动。LLM 接口偶尔会返回 429、5xx第三方工具接口更不稳定。直接原地重试往往越重试越堵。我用的是 2 次重试 指数退避 随机抖动。比如说初始等待 1 秒每次翻倍再加 0 到 500 毫秒的随机值避免所有失败请求同时重试造成羊群效应。其四熔断和降级。如果某个工具接口连续失败超过阈值要立刻熔断不再把请求发往这个工具而是返回“该功能暂时不可用”的兜底话术或者走备用逻辑。生产环境里熔断这事比你想的更重要一个依赖挂掉不能拖垮整个 Agent 服务。我整理过一段伪代码基本就是生产里限流的形态可以直接参考# 伪代码示例基于信号量的并发控制和整体超时 import asyncio from contextlib import asynccontextmanager semaphore asyncio.Semaphore(50) # 最多同时跑 50 个 Agent 任务 asynccontextmanager async def task_guard(total_timeout180): async with semaphore: try: yield except asyncio.TimeoutError: # 任务级超时兜底 yield 任务超时请稍后重试 async def run_agent_task(user_request): async with task_guard(): result await asyncio.wait_for( execute_agent_graph(user_request), timeout180 ) return result这段代码里的信号量是全局同时执行上限超时是任务级总兜底两层保护缺一不可。2.3 成本与性能的平衡术模型分层与上下文裁剪并发问题本质上是成本问题。你扛住了并发Token 账单可能照样撑不住。这里有个很实在的策略模型分层。不要把所有的步骤都丢给同一个大模型生产环境里可以把任务拆成“简单分类”“信息抽取”“复杂推理”三个档位分别用不同价位的模型。比如实体抽取用快而便宜的小模型决策规划用旗舰大模型整体成本能降 40% 到 60%业务效果下降不明显。另外是上下文裁剪这个跟上文的记忆问题相关。每一轮对话之前把历史记录做一次裁剪只保留最近几轮 长期记忆系统里检索到的关键信息而不是无脑全量回传。做完这两步单任务成本能压到一个可接受的量级。顺带提一下资源估算公式方便你规划实例数单实例并发数 × 单任务平均耗时 单实例每小时处理任务数。假设一个任务平均耗时 30 秒一个实例里同时跑 10 个任务那一个小时能处理 1200 个任务。如果业务高峰期每小时有 12000 个任务你就至少需要 10 个实例同时要留 30% 的冗余应对突发流量。公式很简单但真正按这个去规划的团队没几个都是出了事故才去扩机器。3. 第二道坎记忆与状态管理——给 Agent 造一个不断电的大脑Agent 最迷人的地方就是它能“记住”上下文但这也是工程上最坑的地方。把上下文全塞进提示词是“伪记忆”成本高、容易乱、还不可持久。真正的记忆系统要分层次设计。3.1 认清三种记忆模型短期、工作、长期我习惯把 Agent 的记忆抽象成三个层次每一层的存储和访问策略都不一样短期记忆当前对话窗口内的上下文存在大模型的 context 里。它的特点是快速、易失、容量有限。工程上要做的是尽量减小冗余只保留与当前任务高度相关的信息。工作记忆Working Memory当前执行任务的中期状态比如一个多步骤审批流程当前走到第几步、已收集了哪些信息、还有哪些字段缺失。这部分需要显式地建模通常放在图状态的持久化层里任务挂掉了随时能恢复。长期记忆跨会话、跨任务的知识沉淀。比如用户的偏好、业务实体的属性、历史处理经验。这部分必须存到外部存储里用结构化数据库或向量库做持久化。很多 Agent 项目死在“所有记忆全靠短期记忆撑着”一长对话就崩一断线就失忆。真正的生产级方案工作记忆要落库长期记忆要检索。3.2 状态持久化任务中断了要从断点续跑这块是我踩坑最多的地方。早期做 Agent 时一个任务跑着跑着进程重启或者用户刷新页面整个任务状态全部丢失用户只能从头再来。这是最影响企业信任感的体验没有之一。后来我引入状态机模型把 Agent 的执行过程拆成“待执行、运行中、工具调用中、等待用户输入、已完成、失败”等状态每一步的状态变化都实时写入数据库。用 Redis 存热状态Postgres 存结构化任务记录关键节点再打快照。这样用户关掉页面再回来Agent 可以从“等待用户输入”的状态继续而不是重新跑一遍全流程。具体实现上LangGraph 的 StateGraph 天然支持状态的序列化和快照但你要自己去管持久化的时机。我在每个节点执行完成之后、进入下一个节点之前都会做一次状态持久化。代价是会多一些 I/O 开销但换来的是可恢复性这笔交易划算。3.3 上下文压缩与检索增强把有限窗口用在刀刃上工作记忆和短期记忆之间需要一座桥那就是上下文压缩。我常用的策略是三种组合拳最近消息透传最近两三轮对话原样保留保证连续性。摘要压缩更早的历史由一个小模型实时总结成摘要塞入上下文开头。关键信息抽取从历史中抽取出结构化信息比如客户名称、订单号、业务诉求放在一个固定的记忆区块里每次调用时注入。向量检索这块我的建议是不要一上来就搞全套 RAG。先理清楚你要检索的数据是什么类型再决定方案。如果是几百条规则和知识条目用传统的数据库模糊查询加规则匹配就够用了如果是几十万条非结构化文档才需要引入向量库。很多团队在数据量几百条的时候就架了一套完整的 RAG 系统成本和复杂度上去了效果提升却很有限这是过度设计。4. 第三道坎工具调用的可靠性与安全——Agent 的手脚要焊死如果说记忆是 Agent 的大脑那工具调用就是它的手脚。企业场景里最危险的不是大模型胡说八道而是 Agent 拿着工具做了业务上不可逆的操作——发了不该发的邮件、下了不该下的单、改了不该改的数据。这块的安全和可靠性怎么强调都不过分。4.1 工具注册与参数校验别让大模型乱来很多 Agent 开发者在做工具调用时直接把函数暴露给大模型让它“自由发挥”参数。这在 Demo 里没问题模型通常能生成对的参数但生产环境里模型偶尔会把字符串塞进整数字段漏传必填参数甚至编造一个工具不存在的参数名。我的做法是给每个工具定义严格的 JSON Schema并且在大模型返回工具调用结果之后、真正执行函数之前用校验库Python 里可以用 PydanticJava 里可以用 Bean Validation做一层参数强校验。校验不通过就不执行直接让模型重新生成或者返回提示绝对不带着错误参数去调真实业务系统。还有个细节工具的 description 一定要写得非常清楚说明这个工具是干什么的、什么时候用、参数是什么含义、有什么限制。大模型对工具的理解全靠这段描述描述写得模糊模型就会在错误的时候调用错误的工具。4.2 幂等、重试与降级让工具调用经得起折腾你想想看模型要调支付接口第一次超时了它决定重试如果这个接口不是幂等的那用户就要被扣两笔款。这是企业 Agent 最恐怖的场景我见过不止一次。所以在工具设计上有一条铁律所有会改变业务状态的工具必须支持幂等。至少也要做到“调用前校验、执行中记录、失败后可查询”。比如支付接口要传幂等键数据更新接口要带上版本号用乐观锁防止重复提交。工程实现上每次工具调用的执行都要落日志返回结果要带 requestId这样排查问题时有据可查。降级方案也要提前设计好。假设用户使用一个生成周报的工具但底下的某个数据源挂了这时候不能一直转圈等超时而是应该立刻返回一个“数据源暂时不可用可以先填写手工数据”的简化版方案让任务继续走。降级不等于失败降级是让流程往前走的最优解。4.3 权限最小化与审计追踪给 Agent 划一道安全红线安全这块容易走极端——要么完全不设防要么啥都不敢让 Agent 干。我的原则是权限最小化 危险操作二次确认。具体来说给 Agent 分配的系统权限只覆盖完成业务所必需的最小集合绝不分配任意写权限。比如查订单是允许的改订单就要单独一个高权限工具并且高权限工具触发时必须向用户展示确认卡片等用户明确点击“确认执行”之后才真正调用。这类设计现在很多 Agent 框架都有内置支持但务必显式地配置好。还有审计追踪。每笔 Agent 的操作包括模型的思考过程、调用的工具、传入的参数、返回的结果、执行人是谁都要落到审计日志里。一旦出现业务事故你能通过审计日志还原 Agent 的完整决策链路快速定位是模型判断错了还是工具逻辑错了还是权限配置错了。没有审计日志出了问题只能“三连问”为什么、谁干的、怎么办。提示在安全设计上宁可多一次确认也不要少一条日志。企业系统一旦出事没有审计记录责任界定和问题修复都会陷入僵局。5. 第四道坎评测与可观测性——没有体检报告就谈不上上线很多团队的 Agent 上线流程是“Demo 跑通了直接上生产”然后就等着用户来报 bug。这是我在所有项目里持续反对的一个没有评测体系、没有链路追踪的系统上线就是赌博。5.1 三层评测体系从单步工具到端到端业务评测不是“让 ChatGPT 打打分”就完事了至少要分三层单步能力评测验证 Agent 每一步的工具选择、参数生成、结果解析是否正确。这一层最基础主要用单元测试的方式覆盖每个节点和每个工具调用。任务完成度评测给定一个完整的业务任务评测 Agent 能不能从头到尾走完中途会不会迷路、会不会陷入死循环。这一层用的是场景化测试用例集越贴近真实业务越好。业务 KPI 评测上线后持续观察业务指标比如问题解决率、用户满意度、平均处理时长、成本消耗。这一层才算真正回答了“Agent 有没有给企业带来价值”。测试集的构建是个良心活。千万不能只用开发人员自己写的“理想用例”一定要让业务方参与提供真实历史数据。我习惯从真实工单、真实对话记录里抽取样例构造正例和反例各一批反例尤其重要那是边界和坑的集合。评测可以用人工标注 LLM as Judge 结合精度要求高的场景必须人工介入。5.2 链路追踪看得见每一条思考链路生产环境里Agent 是一个黑盒你必须把它点亮。链路追踪工具比如 Langfuse、LangSmith、AgentOps 这一类的能把模型调用、工具调用、上下文快照、Token 消耗全部记录下来在一个 Trace 里展开。没有这套东西你连“Agent 为什么在这个问题上卡了 30 秒”都说不清楚。自己搭建追踪体系也不难核心是规范日志结构。每个 Agent 任务打一个请求云每个节点和工具调用打一个 Span包含输入、输出、模型名称、Token 数、耗时、状态码。日志集中存到 Elasticsearch、ClickHouse 或云日志服务再配一个简单的查询面板就够用了。重点是先跑起来再谈优化不要憋大招做个完美的观测平台等你做完事故都已经过三波了。5.3 灰度发布与影子模式让 Agent 先“实习”再“转正”正在我看来最好的上线策略是影子模式加灰度发布。影子模式的意思是Agent 在后台真实处理线上请求但它的输出不直接触达用户系统把 Agent 的处理结果和人工的标准答案做对比。这相当于让 Agent 跟着老员工免费实习收集一批真实的线上表现数据。跑一段时间后看它的正确率、完成任务率、失败率再决定要不要放量。灰度发布则是小流量逐步放开的路径先放 5% 的用户再放到 20%再到 50%、100%。每一档都盯紧延迟、成功率、成本、用户反馈四个指标任何一个指标异常就立刻回滚。回滚机制必须提前做好配置中心一个开关就能切断 Agent 服务切回原有的规则引擎或人工处理否则灰度永远是空中楼阁。6. 实操中的常见问题与避坑清单系统性的工程解法讲完了再分享几个在项目里反复出现的高频问题和我的处理方式这些都是文档和课程里不太会写的东西。6.1 高频翻车现场一大模型的输出格式“说变就变”就算你在提示词里写了“请返回 JSON”模型偶尔还是会夹带私货给你来一段 Markdown 或者自然语言。解析一失败整个流程就崩。我的解法是双保险一是提示词里给出明确的输出格式模板并用强约束的措辞二是解析时做容错处理不直接 json.loads先用正则把 JSON 片段提取出来再校验必填字段解析不了就自动让模型重试一遍并告诉它“上一次的输出格式不符合要求请严格按指定 JSON 格式输出”。实测下来这个“格式化重试”机制能把成功率从 90% 拉到 99% 以上。6.2 高频翻车现场二Agent 陷入死循环Token 哗哗地烧Agent 在思考过程中可能会反复调用同一个工具、重复同一个动作陷入逻辑死循环。这个问题在不加控制的生产环境里特别常见。解法是给 Agent 的循环加上最大迭代次数限制比如最多 15 步达到上限就强制结束并返回一个合理的兜底结果。同时要有“行动单调性检测”如果检测到 Agent 连续 3 次调用相同的工具并且参数没变化就打断它的循环插一句“这个动作已经执行过了请换一个方向或者向用户询问”。这些策略都很简单但能拦住最烧钱的那类问题。6.3 我踩过的坑把第三方 API 的原始返回直接塞给大模型早期踩过一个大坑某个第三方接口返回的数据结构非常复杂嵌套深、字段多我直接把整个 JSON 塞进上下文结果模型被大量无用字段干扰判断经常出错Token 消耗还高。后来改成先用一个抽取节点把关键字段整理成简洁的文本再交给模型推理。这个改动让准确率提升了近 20%成本降了将近一半。还有一个坑是盲目在 Prompt 里堆规则。写了一大段“你必须……你不得……”以为规则越多模型越听话结果模型被规则束缚住反而失去了应有的灵活性。正确的做法是把核心的、不可违背的约束写清楚边缘情况留给评测和工具层去兜底不要试图用 Prompt 解决所有问题。6.4 一个可直接抄作业的上线 CheckList把多年的经验浓缩成一张清单照着做完再谈上线可以省掉绝大多数事故[ ] 明确 P99 延迟目标和单任务成本预算上限[ ] 全局限流、超时、重试、熔断机制已上线[ ] 工作记忆状态已持久化任务可断点续跑[ ] 长期记忆存储方案确定检索策略有评测[ ] 所有工具都有 Schema 校验写操作均幂等[ ] 危险操作有二次确认机制操作链路有审计日志[ ] 单步、任务级、业务 KPI 三层评测已跑过一轮[ ] 链路追踪日志已接入可查询单个任务的完整轨迹[ ] 灰度开关和回滚预案已就绪[ ] 上下文压缩策略已实施长期会话成本可控这个清单可以打印出来贴工位上上线前逐条打勾缺一条都不安心。最后说点实话做 Agent 生产落地这几年我最深的体会是Demo 考验的是模型的“智商”生产考验的是工程的“耐烦心”。一座能住人的房子不是靠设计效果图惊艳而是靠水电、防水、承重这些看不见的地方扛住了日复一日的考验。Agent 也一样用户只会为“稳定地把事情办成”买单不会为“偶尔灵光一现的高光时刻”买单。如果你正处在“Demo 刚惊艳完、准备上生产”的阶段听我一句劝先别急着全量开放把并发、记忆、工具可靠性、评测可观测性这四道坎老老实实过一遍。这中间没有捷径每一个模块都是靠一个又一个具体的决策和配置垒起来的。等你真的把 Agent 稳稳地跑在生产环境里看着监控面板上平滑的延迟曲线、可控的 Token 账单、不断攀升的无人干预完成率那种踏实感比 Demo 时收到的那阵掌声爽得多。