最近一个月我连续参与了几家企业的 Agent 落地评审开场几乎一样供应商把 Demo 投到大屏幕上Agent 从几十张发票里自动挑数、拆解工单、填写内部系统行云流水。可等真刀真枪接上生产一周之内就开始翻车——而且翻车姿势各不相同。有人在群里吐槽“Agent 现场表演人工智障”有人对着飙升的 token 账单发呆还有人发现用户居然能通过 Agent 看到别人订单的模糊信息。这些都不是模型聪不聪明的问题而是从 Demo 到生产之间存在一条巨大的工程鸿沟。这条鸿沟我拆成四道坎评测与质量、基础设施、稳定性与成本、安全与治理。这篇文章是对这些问题的系统性复盘写给正在把 Agent 从“演示品”推向“产品”的 AI 工程师、架构师和技术管理者。全文不聊概念只聊实操说说我这几年的踩坑经历和工程解法。1. Demo惊艳、上线拉胯的根因解剖1.1 Demo的“温室效应”三个被刻意忽略的前提Demo 做得好不代表 Agent 做得好。Demo 视频里的效果本质上是在三个被精心维护的前提下达成的。第一个前提是数据被“选过”了。演示用的输入要么是拍脑袋设计的“标准句式”要么是从历史数据里挑出来的“优质样本”。比如做客服工单分类的 Demo演示者会输入“我的订单一直没到麻烦查一下物流”句子干净、意图清晰、实体完整。真实用户可不会这么客气他们可能写“怎么还没到”“我东西呢”甚至“你们是不是骗子”。模型在净数据上表现好不等于在脏数据上抗得住。第二个前提是场景被“窄化”了。Demo 通常只展示一条主流程进来一个问题Agent 做一次意图识别调一两个工具给一个漂亮答案。但对真实业务来说主流程只是冰山一角。用户可能中途改需求、骂一句再道歉、问完 A 又问和 A 有冲突的 B这些在 Demo 里基本不会出现。场景一旦拓宽原本丝滑的链路会立刻断裂。第三个前提最隐蔽演示是“容错”的。演示者心里清楚正确答案是什么。当模型输出偏了他会下意识地换一个措辞重新提问或者假装没看到那次失败的调用直接展示下一次成功的结果。观众看到的是被剪辑过的“成功路径”没看到那些被悄悄跳过的失败分支。这种“人工兜底”给了所有人一个错觉Agent 已经稳定了。这三个前提叠加起来就是 Demo 惊艳的根本原因——不是模型特别强而是环境特别干净、场景特别小、错误特别少。1.2 生产环境的四重现实冲击上线之后Agent 面对的是完全不同的世界。我总结为四重现实冲击每重冲击都能单独让项目翻车。第一重冲击输入分布漂移。生产环境的用户输入是长尾的、口语化的、带噪声的。同一句话在上午和下午可能有两种意思同一个实体在不同上下文里指代完全不同。我在一个物流项目里就见过用户说“那个什么圆通的东西”系统完全懵了。训练时模型见过的是“圆通快递单号”没见过人类这种随意的指代。第二重冲击模型自身的概率性缺陷。同一个问题Agent 今天能答对明天可能换一种表达方式答错。大模型的输出天然具有随机性你没法保证温度 0.2 就能稳定复现同一个工具调用。更麻烦的是模型会“临场发挥”生造一个不存在的函数名、伪造一个看似合理实则胡扯的 JSON 输出。这是概率系统固有的不确定性生产系统必须对这种不确定性做防御。第三重冲击外部依赖的脆弱性。Agent 不是孤立运行的它要调公司内部的订单系统、库存系统、CRM、数据库。这些系统的接口不是为 Agent 设计的它们的超时时间、频控策略、返回格式都各有各的脾气。内部系统一个接口偶尔超时 3 秒对人工操作无所谓但对一个需要连续调用三个接口的 Agent 来说三次超时叠加起来就是用户体验崩塌。第四重冲击权限与数据边界的复杂性。人工操作时系统靠登录态和前端按钮决定你能看到什么。Agent 却是一个拥有工具调用能力的“数字员工”如果权限没做细它调一次查询工具可能拿到的是所有用户的数据。Demo 里没有权限这个概念因为演示数据本来就是同一个人的生产里这却是合规红线。1.3 Demo与生产的关键差异对照表我把两类场景的关键维度差别整理成了表格方便你对照自查。维度Demo环境生产环境输入质量干净、标准、无歧义口语化、错别字、模糊指代场景边界单条主流程多意图穿插、用户中途变更失败容忍度演示者可手动跳过用户直接看到错误和卡死并发压力单用户串行多租户并发、资源争抢延迟要求慢一点可接受用户要求秒级响应成本敏感几乎不考虑每天上万次调用成本每月高企权限控制无必须按身份隔离、最小授权可观测性屏幕就是全部需要完整的日志、追踪、审计回滚机制重跑一次即可必须支持灰度、降级、止损看完这张表就能明白生产上线绝不是“把 Demo 换个 URL”而是要把一个在无菌箱里长大的模型扔进一个充满噪声、限制和风险的真实世界里。下面四道坎每道坎都是在这个世界里活下来的必要条件。2. 第一道坎没有一把可靠的尺子——评测与质量保障2.1 为什么传统的“对着几个好例子调Prompt”不可靠很多团队在 Demo 阶段是怎么调质量的对着三五个好例子反复改 Prompt直到样例全过。这种“样例驱动”的做法在原型期没问题但你们会把偶然当必然。模型不是规则引擎样例全过不代表线上效果好。因为例子数量太少模型完全可能“背下”答案而不是学到推理模式。换一批输入表现立刻掉下去。更致命的是几乎没有团队把“Agent 的失败”当成一等公民来对待。人工评估三个 Demo 案例看不出问题但生产里每天几千次调用失败案例一定会出现。所以第一道坎的解法不是“多调几个 Prompt 例子”而是建立一套“可重复、可回归、能量化”的评测体系。没有这把尺子后面所有的优化都是开盲盒。2.2 建三层评测体系单元评测、场景评测、线上影子评测我这几年的实践经验是Agent 的评测必须分三层各管一段缺一不可。第一层是单元评测。针对单个环节做验证比如“意图识别是否准确”“某个工具调用参数是否构造正确”“提取出的实体是否完整”。这一层的重点是快速反馈。改一个 Prompt 或工具定义跑一遍单元评测就知道有没有回归。单元评测集不需要很大每个环节 50 到 100 条精选案例就够了核心是覆盖边界情况和典型失败模式。第二层是场景评测。单元都对不代表整个任务能跑通。场景评测要模拟完整任务轨迹比如“用户发起退款申请Agent 查订单、查退款政策、填退款单、通知用户”然后评估这条链路是否从头走到尾。场景评测是检验“串联”能力的必须覆盖主流程、分支流程、异常流程三种类型。异常流程尤其重要用户输入了无权限的请求、订单不存在、工具返回错误等。第三层是线上影子评测。这是我最推荐的一层。让 Agent 在真实流量旁边“影子运行”它照常推理、照常调用工具但结果不直接发给用户。系统把 Agent 的每一步输出记录下来用规则打分器或更强的模型LLM-as-judge做离线评估。影子模式能让你在生产环境里拿到真实的输入分布又不承担上线失败的风险。2.3 实操要点评测集构造、指标定义与回归门禁评测集怎么构造我建议直接从真实用户日志里抽样不要自己编。在项目早期没有真实日志可以先收集 20 个高频业务场景人工拆成主流程和边界 case。上线后再用影子模式不断扩充评测集我见过一个项目就是把线上失败的 case 持续沉淀到评测集三个月后评测集到了 2000 条Agent 质量明显稳了一大截。指标定义上我建议至少盯这五个任务完成率、单步工具调用成功率、无效调用率Agent 明明可以一步完成却绕了五步、用户干预率是否频繁追问澄清、平均轮次。任务完成率最高但只看它不够。我遇到过一个 Agent完成率 85%但平均轮次从 3 涨到了 9用户反馈“转圈圈半天才做事”。轮次多一倍token 消耗也多一倍成本自然失控。所以完成率要和轮次、无效调用率绑在一起看。回归门禁是硬要求。我强烈建议把评测脚本接入 CI每次改动 Prompt、工具定义或知识库内容都必须跑一遍完整评测集。分数线只降不许升一旦低于阈值就不允许合并代码。这个门禁的意义是防止“改 A 坏 B”的隐性回归。很多团队在 Demo 阶段全靠手工验证上了生产之后改一句 Prompt 都要全员拉会就是吃了没有自动化回归门禁的亏。我踩过一个很真实的坑评测集里全是“好例子”没有坏 case。结果上线当天被用户输入虐得毫无还手之力。后来我把线上失败 case 逐条沉淀下来不删不改地丢进评测集下一轮改完 Prompt 发现通过率从 91% 降到 74%才意识到真实输入有多狠。评测集必须有“攻击性”这是最核心的经验。3. 第二道坎状态、记忆与并发——基础设施欠账3.1 Agent不是网络请求而是“长跑型任务进程”大部分团队把 Agent 当成普通 Web 请求做用户发一句话接口返回一个答案请求结束。这在 Demo 里没问题但生产里你会发现 Agent 的任务不是一次请求就能完成的——调用工具、等待外部系统、组织中间结果、再次询问用户这些步骤可能持续几十秒甚至几分钟。如果按普通请求来做一个 HTTP 连接根本撑不住这么久。正确的建模思路是把 Agent 任务看成一个“长跑的进程”有明确的状态转换和生命周期。用户那句话只是这个进程的启动信号真正的逻辑是一步步推进状态机收集上下文、调用工具、检查结果、决定下一步。这个意识转变是整个基础设施设计的起点。3.2 状态管理会话流程如何持久化与恢复状态是整个 Agent 系统的骨架。Demo 里 Agent 的状态全在内存里进程重启就没了。生产里必须把会话状态持久化。我实践下来比较顺手的做法是用 Redis 存短期会话状态包括 session_id、当前上下文片段、已完成的步骤栈、等待用户确认的待办事项用 PostgreSQL 存持续化的业务数据比如订单号、操作结果、审计记录给每个会话设计一个状态机字段至少包含statusrunning / waiting_user / tool_call / finished / failed、current_step、attempts。有了状态机Agent 就可以“断点续跑”。之前我在一个客服项目里遇到过Agent 查到一半下游服务超时了整个会话直接丢。换成持久化状态机之后超时后任务可以从“查订单”这一步重试不用从头开始解释。这种体验差别用户是能直接感受到的。3.3 记忆工程化短期记忆与长期记忆怎么落地记忆是 Agent 和普通接口最大的不同点。简单类比短期记忆是工作台堆着当前任务要用的材料长期记忆是档案柜放着用户偏好、历史偏好、积累的知识。File cabinet 里的东西不能随便翻。工程上短期记忆由对话上下文组成关键是控制长度。上下文过长会突破模型窗口还会拖慢响应。我的做法是每轮结束后做一次“记忆压缩”把关键决策、已获得的事实提炼成 200 字以内的摘要。长期记忆则分两层结构化信息用户 ID、偏好标签放数据库或 KV 存储非结构化知识用户上一段话里的重要事实用向量库存起来。向量库选型上小团队用 pgvector 起步最省事量大了再上 Milvus 这类专用引擎。记忆这一块还涉及隐私和安全我会在第四道坎里展开。但先记住一个原则长期记忆必须让用户可以查看、修改和删除。不然这个 Agent 会变成“无法遗忘的档案柜”迟早出事。3.4 并发估算与资源隔离AI Agent怎么扛并发“AI Agent 怎么扛并发”是大家在热搜里常搜的问题也是生产落地最容易被忽略的坑。先说结论Agent 并发不是“API 并发”而是“任务并发”。一个 Agent 任务内部可能是多次串行/并行的 LLM 调用。假设单任务平均调用 LLM 3 次每次 2 秒一个任务要 6 秒。如果你的 LLM API 并发上限是 100 QPS那支撑的任务并发上限大致是 100/3 × 6 200 个同时执行的任务。这个估算很粗糙但比拍脑袋强得多。实际操作上我强烈建议引入任务队列比如 Redis Streams 或 AWS SQS / 云上消息队列。用户请求进来先落队列Worker 按固定速率消费任务而不是让用户请求直接打到模型 API。这样能天然地做削峰填谷也能在模型 API 限流时优雅排队。不要把所有 Agent 任务塞进同一个线程池很容易出现一个慢任务占满线程、把其他用户请求全部饿死的情况。按租户或业务线做资源隔离成本高一点但故障影响面能小很多。3.5 超时、重试与任务队列的配合Agent 调用的外部系统不只是模型 API还有内部服务。内部服务超时策略不能一刀切我按调用类型做了分级读类操作超时 5 秒写类操作超时 10 秒外部第三方接口超时 15 秒。重试也不是“死循环式重试”必须带退避和幂等键。每次调用生成一个call_id外部系统靠它识别是不是同一个操作防止重复扣款、重复创建订单。我给一个简化版的状态机示意这是在真实项目里跑过的模式class AgentState(Enum): PENDING pending TOOL_CALL tool_call WAITING_USER waiting_user FINISHED finished FAILED failed def run_agent_task(session_id, task_input): state load_state(session_id) state.status AgentState.TOOL_CALL result call_tool_with_retry( toolquery_order, params{order_id: extract_order(task_input)}, call_iduuid4(), max_attempts2 ) if result.is_success(): state.status AgentState.FINISHED state.result result.data save_state(session_id, state) return format_answer(result.data) else: state.status AgentState.FAILED state.error result.error save_state(session_id, state) return fallback_human_message(暂时查不到请稍后再试)这个小代码背后有三层含义一是状态持久化中途失败不会丢上下文二是重试和幂等键同一个工具不会因为重试被调用两次三是失败兜底给用户一个明确反馈而不是让请求挂着。这些就是生产系统区别于 Demo 的骨架。4. 第三道坎确定性护栏与成本治理4.1 目标把不确定性的影响关进笼子而不是消灭不确定性大模型的概率性我们消灭不了也不应该试图消灭。真正该做的是在 Agent 外围建一圈“确定性护栏”让模型的不确定性只在一个有限的、可控制的范围内波动。就像开车不能保证不爆胎但备胎、胎压监测和应急车道能让爆胎不至于出人命。这道坎的核心有两个结构约束和失败降级。结构约束是让模型按规定的格式输出失败降级是当模型输出不合法、工具调用失败时系统要有明确的后备路径而不是把错误原样抛给用户。4.2 结构化输出让模型按Schema说话企业落地里最让我崩溃的就是模型偶尔输出一个非 JSON 的“自由文本”来冒充工具调用结果。这种问题的解法很成熟强制结构化输出。业界主流做法是用工具的strict模式或response_format参数让模型必须遵循 JSON Schema。我来举个例子假设 Agent 需要调用“查询库存”工具{ name: query_stock, description: 查询商品的实时库存, parameters: { type: object, properties: { sku_id: { type: string }, warehouse: { type: string, enum: [华东, 华南, 华北] } }, required: [sku_id, warehouse] } }模型输出必须符合这个 Schema否则你自己解析 JSON 时就会把嵌套引号、注释、多余逗号等一起带崩。更关键的是如果模型输出不符合 Schema不要重新解析它直接把解析错误信息回传给模型让它自己“反思”并重写一次。我实践下来这种“调度式修复”的成功率比重新生成高得多。4.3 工具调用幂等化防重复、防放大故障Agent 的失败模式比传统接口多一个它可能“实际成功了但返回超时”。比如 Agent 调支付接口扣了款但网络延迟让调用方以为超时于是触发重试又扣了一次款。这种场景在人工系统里靠“确认弹窗”避免Agent 系统则必须靠幂等键。工程要求很简单每次 Agent 工具调用都生成一个全局唯一的call_id下游系统需要把它作为幂等键。你在系统里规定同一个 call_id 重复提交直接返回第一次的结果不重复执行。同时对写类操作下单、退款、审批、发消息建立人工确认机制。不要一上来就给 Agent 全部写权限而是让它在关键动作前先输出一个“操作确认”给用户用户点确定才继续。这个“人在回路”的做好是生产落地的安全底牌。4.4 成本治理模型分层、token预算与缓存成本翻车也是生产落地的高发事故。有一位朋友的项目Agent 上线两周token 账单比预估多了三倍。原因很简单Demo 只看体验没人算成本。生产环境里同样的功能被吃掉了大量重复上下文和无效调用。我的成本治理三板斧直接分享模型分层。简单意图分类、实体抽取、格式整理用轻量模型复杂推理多跳任务、长链规划才用大模型。成本差距不是一倍两倍是同规模下 5 到 10 倍。比如一个客服入口先把“退货”和“骂人”用意图分类模型分出来骂人的话直接转人工根本不需要走大模型规划。Token 预算。给每个任务设置max_tokens上限超出就中止并降级。这个上限要按任务类型分别设置不能一刀切。任务开始前做个“预计 token 消耗”估算如果明显过高先提示用户是否继续。结果缓存。对工具调用的返回结果、意图识别的结果、常见问答的模型输出做缓存。同一个 SKU 查库存十分钟内同一个用户可以复用缓存不用重新跑一次模型。成本估算我曾经给过一个参考假设单次任务平均 5000 token一个月 100 万次调用。小模型成本约每百万 token 几十元大模型则是数百到上千元。同样是 100 万次调用光模型成本就差出一个数量级。这不只是省钱的问题是决定 Agent 产品能不能自负盈亏的基本盘。5. 第四道坎安全、权限与审计——Demo里看不见的防线5.1 Agent全权在握风险面比想象大Demo 阶段没人提安全因为演示环境所有数据都是演示者自己的。生产环境里一个拥有工具调用能力的 Agent相当于给每个用户发了一个“能动手的代理”。风险面迅速扩大工具调用的权限边界、数据可见范围、模型自身的对抗鲁棒性、记忆体被污染的风险全都变成现实问题。我见过最惊悚的一个 case某公司把 Agent 接入订单查询工具时没做租户隔离。Agent 一查订单号直接把所有匹配到的订单都返回出来了包括别人的。这不是模型的问题是工具接口本身没有按调用者身份做过滤。Agent 在生产中会替你调用工具你的身份边界必须是硬约束不能靠模型“自觉”。5.2 权限模型用户身份边界、最小权限与人在回路权限设计的核心原则是Agent 的权限不能超过发起它的用户权限。用户能查自己的订单Agent 才能查用户没权限改价格Agent 再聪明也不能改。实现上要注意Agent 调用工具时的身份令牌必须带当前用户的会话上下文而不是用一套系统级账号。我建议至少做三件事。第一按工具做白名单Agent 能调用的工具集合要做严格配置新工具纳入生产前必须过评审。第二按会话发放短期令牌用户登录后Agent 拿到一个临时可用的 token有效期跟着会话走不做全局静态密钥。第三关键操作设置“人在回路”转账、删除、发布这类高影响操作Agent 不能直接执行必须先输出确认信息用户点了确定才执行。很多人觉得这样“不够 AI”但实际上这是全球主流实践都认同的做法也是避免灾难性事故的底线。5.3 记忆安全与隐私存储、脱敏、遗忘与防御长期记忆是 Agent 的优点也是隐私风险的放大器。如果 Agent 记住了用户的身份证号、银行卡号、住址然后一个防护不到位这些敏感数据就被泄露了。所以记忆工程要和隐私保护同步做存储侧记忆库必须加密且明确区分“用户显式告知的信息”和“Agent 自行推断的信息”脱敏侧号码、地址等敏感字段在写入记忆前要做脱敏处理模型只需要“用户是上海业主”这个级别的事实不需要完整门牌号遗忘侧提供“清除记忆”的能力用户随时可以查看和删除 Agent 保存的关于自己的信息防御侧对写入记忆的内容做校验。最近大家都在讨论 Agent 记忆攻击有人往模型输出里藏指令诱导 Agent 把恶意内容写进长期记忆后续任务全被污染。这种记忆投毒在学术上已有针对性防御框架比如 A-MemGuard 那类思路核心就是在记忆入库前做一道过滤和检测把可疑的指令片段剥离掉。我在真实项目中受到启发在记忆写入层加了一个 Post-Processing Hook对写入记忆前的内容做一次“是否包含指令意图”审查效果比较明显。这类防御不能让 Agent 免于所有攻击但能把大范围记忆污染的概率降下来。5.4 审计日志让每一次决策可回溯最后一道防线是审计。生产系统的工程师永远要问“如果出事了我能不能回答为什么这么干”Agent 系统更容易出这种问题因为它的决策链条长、依赖关系复杂。所以每次工具调用、每次模型输出、每次用户确认都必须落审计日志。我做审计日志的字段设计比较简单直接字段说明request_id会话级唯一 IDstep_id任务内单步唯一 IDuser_id发起用户身份tool_name调用的工具名call_id幂等键用于重试识别input_summary输入上下文的摘要不含完整敏感数据output_summary工具返回结果的摘要model_name / token_usage模型标识与 token 消耗decision_reason模型在该步的决策理由摘要timestamp不可篡改的时间戳审计日志不只是合规摆设它还是排查问题最珍贵的材料。我在一个项目里排查“为什么用户投诉被错误复制到另一个工单”时就是靠审计日志找到某一步工具调用参数传错了字段。没有日志这种问题只能靠猜而猜测是生产事故的第二大来源。6. 落地路线四步走把Demo送进生产6.1 分阶段灰度内测、影子、小流量、全量四道坎都说清楚了最后聊聊怎么把整套方案落地推进不能一口气从 Demo 切到全量。我习惯走四步第一阶段内测。Agent 只对内部团队开放跑真实业务数据但不出内网。这一步的目标是跑通评测体系、状态管理、审计日志这些基础设施。不要期望效果惊艳先把管线理顺。第二阶段影子模式。Agent 旁路运行结果不展示给真实用户。这个阶段用来扩充评测集把线上真实输入持续喂给 Agent同时用自动打分器评估质量但不对业务产生任何实质性影响。第三阶段小流量灰度。放 5% 到 10% 的真实用户进来并且设置“随时降级”开关。一旦评测指标跌破阈值立刻把流量切回传统人工流程。这个阶段建议配上人工质检——抽样看 Agent 输出记录失败类型。第四阶段全量上线。全量不代表不管了。上线后每天盯评测分数、异常拒答率、用户干预率和 token 消耗每周做一次失败 case 复盘把“本周新发现的问题”沉淀到评测集里。每个阶段之间必须有明确的“退出标准”比如影子模式要求任务完成率至少 85%、无效调用率低于 10%才允许进小流量。这些数字不是随便拍的是结合业务容忍度和成本模型算出来的。6.2 团队分工与例行质量复盘落地 Agent 不是一个人能干的活。我建议至少要有四个角色算法/Agent 工程师负责 Prompt、工具链和评测集平台工程师负责状态库、任务队列、日志审计业务方负责提供真实场景和验收标准安全合规角色负责权限模型和数据边界。小团队里这些角色可以兼任但职责不能缺失。每周的质量复盘会是我强烈推荐的。会上不要讲“模型又变聪明了”而是要过这些数据失败样本、用户投诉、工具调用成功率、成本曲线。失败的 case 要逐条拆拆到根因是双管齐下的是模型决策问题还是工具接口不稳定还是数据质量差。我实践下来绝大多数“Agent 不聪明”的问题根因都在“输入侧数据太乱”“工具接口太脆”“缺少状态恢复机制”这三类上真正的模型逻辑缺陷反而是少数。6.3 技术栈选型建议框架、评测与可观测最后说下选型。框架方面复杂编排优先看 LangGraph它把状态机和图执行做得比较成熟轻量场景用 agno 这类更小的框架起步快Java 团队可以看 Spring AI和现有后端体系融合得顺。框架不是越重越好团队驾驭不了的重框架反而会拖慢交付。可观测性方面Langfuse 这类工具对 Agent 的 traces 展示很直观但自建日志系统也可以核心是把审计字段和 token 使用情况完整记录下来。评测工具上OSS 方案和自建都行关键是评测集要长在你的业务数据上而不是用一个通用 benchmark。选型的一条黄金原则选团队最容易长期维护的方案。Agent 是个长跑项目框架和工具都会洗牌但对业务的理解和评测集的积累是不会过时的资产。四五年做下来我最大的感受是Agent 生产落地的胜负手从来不在模型参数或 Prompt 工程而在于你愿不愿意把那堆枯燥的“管线”搭好——评测集、状态机、权限模型、审计日志。这些没有一样是酷炫的但缺一样Agent 就不可能稳稳地待在业务线上。真正帮你把 Agent 从惊艳的 Demo 送到可持续运行的生产线的恰恰是这些不性感的工程细节。如果你正在推 Agent 上线我建议先从内部知识问答或工单分类这类“低风险场景”练手踏踏实实迈过那四道坎再考虑让 Agent 去碰更核心的决策环节。