去年下半年到现在，我见了太多 AI Agent 的项目，套路出奇地一致。老板面前 demo 跑得行云流水，自动查数据、调接口、写总结，全场鼓掌。三个月后上线，第一天就出事故，用户骂声一片，团队连夜回滚。同一个 Agent，两套表现，中间隔着一条怎么都跨不过去的沟。

这条沟，业内叫最后一公里。我今天想说清楚两件事：为什么会翻车，以及怎么把它填上。先说一句结论，免得你看到最后才抓重点：Agent 上不了线，绝大多数时候不是模型不够聪明，而是我们太把它当 demo 来对待了。

翻车的根源，是 Demo 把脏活全藏起来了

先把话说直白。Demo 之所以惊艳，不是模型多强，而是它偷偷把工程该扛的脏活全替你屏蔽了。你看到的那个完美流程，跑在四个默认前提上。

第一，输入是被挑过的。Demo 用的例子都是最能展示能力、最不容易出错的。真实用户不会配合你走快乐路径，他们会给脏数据、给含糊指令、给长尾到你想不到的边界情况，甚至有人故意试探你的系统边界。模型本来就是概率的，同样的 prompt 两次结果都不一定一样，你拿一个 deterministic 的演示标准去衡量它，本身就不公平。

第二，工具是被宠着的。演示里调的那个 API，稳定、快、返回符合预期。生产里它不是这样工作的，超时、限流、Schema 漂移、返回半个字段，全是家常便饭。Agent 一旦把工具当永恒真理来信任，第一步就会摔。更隐蔽的是，模型还会"脑补"一个工具没返回但它在回答里写出来的东西，这种幻觉在 Demo 里没人较真，生产里就是一次错误的对外承诺。

第三，有人兜底。Demo 现场旁边坐着写这个 Agent 的工程师，一旦模型卡壳，人不动声色就接过去了。生产环境里没有这个人，7×24 无人值守，错一次就是一次线上事故。而且 Demo 是低频单人的，模型偶发抽风的概率被稀释了；生产是高频并发的，那个千分之一的坏结果，每天都会上演几十次。

第四，不计成本。几十次调用，挑出最好看的截图，没人关心花了多少 token、多少延迟。上线之后是万级 QPS，账单按月炸裂，p99 延迟把用户体验拖垮，这些在 Demo 里根本不会暴露。一个 Agent 单次跑两块钱看着不贵，乘以日活百万就是一天两百万，老板看到账单的那天就是项目关停的那天。

所以翻车不是模型不行，是 Demo 把不确定性、脆弱性、成本这些真实世界的属性暂时藏起来了。你却用演示脚本的标准去要求一个概率系统，不出事才怪。

把 Agent 当分布式系统来 engineering，而不是当脚本

我的核心观点先放这：Agent 落地的最后一公里，不是算法问题，是工程纪律问题。它的本质，是把一个概率的、会犯错的、要和外部世界打交道的服务，做成能稳定跑在生产里的系统。这件事的难点，和十年前我们把一个单机程序做成高可用微服务一模一样，只是多了"模型会胡说"这一层不确定性。

我观察到一个有意思的现象，为什么偏偏是这两年 Agent 的最后一公里这么难填。因为大模型把"做一个能跑的东西"的门槛降到了地板，任何人三天都能搓出一个惊艳的 demo，但"做一个能扛生产的东西"的门槛一点没降，反而因为引入了不确定性更高了。以前你写的是确定性代码，bug 是确定的；现在你指挥的是概率模型，同样的输入可能给出不同的坏结果。工程的复杂度没少，还多了一层玄学。这就是为什么大家普遍觉得 Agent 落地比想象中难，不是你团队不行，是这个东西本身就需要新的工程范式。

下面是四根支柱，把 Demo 推过那条沟。

第一根：评测闭环，别靠感觉

绝大多数 Agent 项目死在没有评测。大家靠"看着还行"来判断好坏，这等于闭着眼睛开车。你必须建一套离线的评测：一批覆盖真实场景的 golden 数据集，定义清楚什么叫任务成功，每次改动都跑一遍，盯着成功率、工具调用准确率、幻觉率这些硬指标。没有这套，你根本不知道一次模型升级是变好了还是变炸了，更可怕的是你连"现在到底有多差"都没有基线。评测不是上线前的检查，是贯穿整个生命周期的底线，是团队敢迭代的唯一底气。我建议评测集里故意塞 20% 的刁钻和脏输入，专门用来暴露模型的短板，别只放它擅长的。

第二根：把工具当不可信来治理

工具调用是 Agent 最脆弱的环节。做法很朴素：给每个外部调用加超时、加重试和退避，返回先做 Schema 校验，字段不对直接拒绝而不是硬塞给模型。更进一步，做故障注入测试，故意让工具慢、让工具报错、让返回缺字段，看 Agent 是优雅降级还是直接崩。把工具当成一定会出问题的下游来设计，它才扛得住生产。我见过最稳的做法，是给每个工具包一层"契约"，明确输入输出的形状和失败语义，Agent 只在契约内行动，越界一律报错而非猜。还有件事常被忽略：工具返回要尽量小，把几 MB 的 JSON 整个塞进上下文，模型既不看也烧钱，做一层裁剪和摘要才是正解。

第三根：可观测，否则你瞎调

Agent 出错最可怕的地方在于不可解释。它为什么调了那个工具、为什么给了那个答案，没有日志你永远不知道。所以每一步的输入输出、每次工具调用的耗时和成本、每个任务的成败，都要能追踪到一条完整的链路。再配一个 LLM-as-judge 做质量打分，你才能在生产里看见问题、定位问题。没有可观测性的 Agent，出问题只能靠用户投诉来发现，等投诉来了，口碑已经塌了。可观测不是锦上添花，是 Agent 能不能活过第一周的分水岭。这里有个实用建议：把"单次任务成本"做成实时看板，哪天突然翻倍，多半是哪里陷入了重复调用或者死循环，你能第一时间发现。

第四根：护栏和灰度，给错误留出口

高风险动作必须有人工确认，权限要做分级，敏感操作默认拦下而不是默认放行。上线不要一把梭，先影子模式跑（不影响真实用户，只记录 Agent 会怎么做），再小流量灰度，确认指标稳定了才逐步放量，并随时能一键回滚。Agent 的"最后一公里"往往不是技术，而是敢不敢让它真的替用户做决定，以及做错了怎么兜底。一个能安全犯小错并立刻纠正的 Agent，比一个拼命想做对却无法刹车的产品可靠得多。

落到架构：生产级 Agent 长什么样

把四根支柱翻译成架构，一个能扛生产的 Agent 运行时大致是这样分层的。编排层负责规划和反思，决定做什么、做几步；工具执行层是真正和外部打交道的地方，必须带超时、重试、熔断和 Schema 校验；护栏层在关键动作前做权限分级、敏感确认和回滚开关；而可观测闭环不是某一层，是贯穿全程的那条神经，把每一步的数据回灌给评测，让系统越跑越知道自己在干啥。

注意这张图里没有"大模型"单独占一层，因为模型只是编排层里的一个组件，真正决定能不能上线的，是它周围的那些工程设施。很多人本末倒置，花九成精力调 prompt、换模型，却不肯花一成搭这套运行时，结果就是 demo 很美、生产很惨。

上线路径：别一把梭

前面提过灰度，这里展开说。我建议走四步：Demo 阶段人工兜底、不计后果，纯看可行性；影子阶段让 Agent 真跑但只记录不执行，拿它的决策和真人比，验证它"想做的"对不对；灰度阶段接小流量真实执行，盯紧成功率、成本、延迟这些核心指标；全量阶段才放开，但全程保留实时护栏和一键回滚。每一步都能独立退回，错了退一步，比硬扛到全量崩盘便宜得多。这套路径的核心就一句话，让错误的代价随放量慢慢放大，而不是第一天就全押上。

该从哪下手，又有哪些坑别踩

如果你正准备动手，我的建议是先挑一个"错了也伤不大的"场景做第一个 Agent，比如内部知识问答、工单初筛，而不是一上来就做能直接动钱、动权限的高危场景。先在这一亩三分地里把评测、可观测、护栏跑通，再谈扩大边界。

几个常见的坑提醒你：别迷信"万能 Agent"，什么都让一个 Agent 干，它既慢又容易乱，拆成多个专职 Agent 配一个编排器反而更稳；别把上下文无限拉长，塞得越多越贵越容易跑偏，学会压缩和摘要历史；更别在没评测的情况下追着模型版本跑，今天换这个明天换那个，最后不知道到底哪个更好。

我的看法

我越来越觉得，Agent 能不能落地，和模型能力的关系，远小于和工程成熟度的关系。过去两年大家卷模型、卷 prompt，接下来要卷的是评测、可观测、可靠性这些听起来很无聊的东西。恰恰是这些无聊的功夫，决定了你的 Agent 是停留在 PPT 里，还是真能扛住用户的毒打。

我前阵子帮一个团队做复盘，他们的客服 Agent demo 阶段把人惊艳得不行，上线第一周就因为没做工具超时和重试，第三方接口抖了十分钟，Agent 连锁失败把工单池冲爆。根因不是模型，是他们压根没把"工具会挂"当回事。补上超时、重试、可观测之后，同样的服务再没出过同类事故。你看，最后一公里就是这么朴素，朴素到很多人不屑于做，然后被它狠狠教做人。

所以如果你正准备把 Agent 从 demo 推到生产，别急着加更多花哨能力，先把上面四根支柱和那套运行时补上。一个成功率 80% 但全程可观测、可回滚的 Agent，远比一个成功率 95% 但出了事你完全不知道原因的 Agent 值得信任。最后一公里，填的是工程的地，不是模型的坑。

最后补一句给技术负责人的。招人和考核上，别再用"做出了多惊艳的 demo"来评价 Agent 团队的产出，那只会鼓励大家继续做面子工程。真正该奖励的，是那些把评测集搭厚、把故障注入做全、把线上事故率压下来的脏活。Agent 这个方向，拼到后面全是苦活，谁肯老老实实把苦活干了，谁才能把最后一公里真正打通。