夜雨聆风老板给客服 Agent 的 Critic 设计打了个 B，理由是「这是 Apple 才需要的，我们不是 Apple」——这是 AI Agent 落地最贵的误会。读完 5 分钟能识破「上线即放养」方案的 6 个空洞，10 分钟能在评审会上问出供应商答不上的 4 个问题。
《Agentic AI 落地方法论》系列第四篇。 前三篇拆「方案能不能上线」——L0-L3 定级、L2 vs L3 的 5 个架构决策、Critic fail-closed 深挖。这一篇拆「上线之后」——为什么 90% 的"落地了 AI Agent"项目，本质上是 vendor 和 buyer 合谋的一场放养。English version: Deploy and Abandon — The Costliest Misconception in AI Agent Projects.
"我们不是 Apple，没必要那么细"——一个 B 评级背后的认知陷阱
老板给我的客服 Agent Critic 设计打了个 B。理由原话："这是 Apple 这种公司才需要的东西，我们公司还不到那个级别。"
我把 Critic 失败时升级人工、二维阈值表、漏放率 1% 以下的 eval set 讲了 40 分钟、PPT 翻了 30 页。反馈是一个 B，加一句行业判断。
这句话我后来在好几个项目复盘会上都听过。说法略有不同——"这是大厂玩法"、"我们体量不够"、"以后再说"。本质都是同一个判断：安全、兜底、持续 eval 是奢侈品，公司还没到那个阶段。
这是 AI Agent 落地最贵的一个误会。把它信下去的公司，6 个月后会在第一次大事故里集体复盘"为什么之前没人考虑这个"。
真相是反的——你公司越不是 Apple，越需要 Critic、监控、兜底、eval。逻辑只要 1 分钟就能讲清：
Apple 因为有 1000 人做人肉 Critic，技术 Critic 可以差一点。你公司就 3 个人，技术 Critic 必须设计对，它替代的就是你雇不起的那 1000 个审核员。
"我们还不到那个级别"在逻辑上完全反了。正确版本是："我们还不到那个级别，所以更不能省这个。"
这一年所有"上线即放养"的 Agent 项目背后，都是同一个老板说过同一句话。这一篇写给那些被这句话压住的执行层，把这笔账算清楚，下次开会能拿出来反驳。
Demo 通过测试 ≠ 产品上线：6 个被跳过的环节
供应商演示能跑通退款流程、内部 "AI 落地办" 拍照发朋友圈，很多企业管这叫"AI Agent 落地"。
但 demo 跑通和产品上线之间隔着 6 个环节。每少一个，事故来时这一个就是漏洞。
左边一格是供应商演示的全部交付物，签合同就靠这一格；右边 6 件事是生产环境真正需要的，签完后默认从交付物里删掉。点击图片查看原图。
这 6 件事每件都要钱。而且不是上线时的一次性开销，是上线之后每个月都在花的运维钱。一个稳定上线的 L2 客服 Agent，6 件事齐备的运维投入大约是 3-5 个 FTE（提示工程师 1-2、业务标注 1、SRE 0.5-1、模型迭代 0.5），按中国一线城市口径换算，月运维成本约 8-15 万。
8-15 万 / 月听着不少。对比一下事故成本：一笔 980 元误退是钱，更贵的是事故后的"整改下线 1-2 周 + 客户流失 + CEO 复盘会 + 创新部门信任清零"——保守估算单次事故的隐性成本是 50-100 万起。运维钱省半年 = 60 万，撞上一次事故 = 80 万，账永远算不过来。
供应商汇报方案时不提这 6 件事，因为提了单子签不下来。客户预算里只有"项目实施费"，没有"上线后每月运维费"。供应商默默把这 6 件事从交付物里删掉，签完单交付一个能跑 demo 的方案，剩下的"问题等出来再说"。
公司这边也不主动问，因为问了预算批不下来。AI 项目本来就是创新部门顶着压力立项，再加一笔每月运维费，CEO 会问"这个项目到底是为了省钱还是为了花钱"。
两边心照不宣，方案就这样上线了。这就是"上线即放养"的真正含义——不是没人想做对，是两边都默认了不做。
"上线即放养" 是 vendor 和 buyer 的合谋——短期双赢，长期双输
把这件事叫合谋不是修辞，是结构性现象。两边的短期 incentive 完全对齐：
Vendor 这边——
销售 KPI 是签单不是续约，demo 卖得快，运维不计入提成 售前工程师写方案，售后团队接锅，售前没动力把运维写进 SOW 行业还在跑马圈地阶段，抢市场份额比交付质量重要
Buyer 这边——
CEO 要的是"我们落地了 AI"，这句话上财报、上路演 PPT、上行业大会，越快越好 创新部门要的是"项目按时上线"，后续运维出事是"业务部门的事" 业务部门要的是"自动化率 KPI"，只看上线第 1 个月数字，不看第 6 个月
5 个角色，5 个目标，没有一个角色的 KPI 跟"6 个月后系统还活着"挂钩。于是没有人为"6 个月后"负责，这就是上线即放养的产生机制。
长期账本谁付？事故来时所有人都付：
Vendor 失去客户（下一年不续约）+ 行业口碑下降 CEO 在董事会被追问（"上次说落地的 AI 项目，怎么半年就出事了"） 创新部门被罚（"立项时怎么没考虑这些"） 业务部门退回 BOT 或人工方案，前面投入打水漂 客户流失（出过一次 980 元误发事故的品牌，复购率明显降）
这个长期账单远超当初省下的运维投入，但因为是 6 个月后才来的账单，没有任何短期决策机制能阻止它。
破局只有一个方法：在签单前把运维条款写进合同。下一节给你 4 个能在评审会上问的问题，把这笔账提前摆桌面上。
评审会上问这 4 个问题——任意一个答不上来 = 你买的是 demo
下次供应商评审会上 PPT 翻完，问这 4 个问题。问题不是难为人，是把"上线后的合同条款"提前固化。供应商如果答不上来，意味着方案根本没考虑过这一步，别签。
问题 1：上线后第 30 天，错误率怎么算？谁看？多久看一次？
合格答案要包含三件事：错误率的定义（按订单算？按对话算？按写操作算？包不包括用户改主意取消的？）、看的人是谁（甲方业务方？乙方 SRE？双方联合？）、看的频率（实时面板？日报？周报？）。
不合格答案：「我们日志都留了，要查随时给您调」。这是上线之后没人主动盯的代名词。
问题 2：模型 / prompt 出新版本，怎么灰度、怎么回滚？
合格答案要给出操作流程：新版本上线先走多少比例流量（10%？1%？）、灰度期多长（1 天？1 周？）、触发回滚的阈值（错误率上升 X%？升级率上升 Y%？）、回滚的操作时间（秒级？分钟级？小时级？）。
不合格答案：「我们改动前会充分测试」。意味着没有灰度机制，新版本上线 = 100% 用户直接 hit。这是去年很多 LLM 集成项目翻车的核心原因。
问题 3：月度 eval 的样本怎么抽、谁标注？
eval 不是"系统自检"，是外部人工标 ground truth。合格答案要包含：抽样方法（随机？还是按业务类型分层？）、样本量（每月 500？1000？）、标注人是谁（业务专家？外包？双方联合？）、标注一致性怎么管（双标 + 仲裁？）。
不合格答案：「我们模型自己会评估自己」。LLM 自评是这一代 AI 项目最常见的虚假指标，连基本的循环论证都没躲开。
问题 4：上线后这套方案养它的人，几个 FTE？谁出？
最关键的问题，放最后。因为前 3 个答好的供应商，这一题往往说不出口。
合格答案是一个具体数字 + 责任划分：总 FTE 数（典型 L2 客服 Agent：3-5 个）、角色拆分（提示工程师、业务标注、SRE、模型迭代）、谁付钱（甲方自建？乙方驻场？混合？月费多少？）。
不合格答案：「方案上线后是自驱动的，基本不需要人工干预」。直接终止评审。任何说"自驱动"的 LLM 系统都是"放养"的同义词。
4 个问题里 2 个答不上——这是 demo 方案，不是产品方案。逼供应商重做，或者换供应商。预算不够的话宁可缩范围（先上一个意图、一个写操作），也别上一个"6 个环节都跳过"的全量方案。前者是慢，后者是雷。
5 条自检——你公司现在的方案是不是"上线即放养"
如果方案已经在公司里跑了，用下面 5 条对照。任意一条 yes，方案就在"上线即放养"的路上：
- 没有一个人能在 30 秒内说出昨天 Agent 处理了多少笔、错了几笔、错在哪几笔
——没有 observability - 上线之后 prompt 改过 N 次，没一次走过灰度，也没人能列出"上线那天的 prompt 长什么样"
——没有版本管理 - eval 自从上线就没跑过，或者跑了但样本是开发自己写的
——没有持续 eval - Critic 失败了就放行，或者根本没有 Critic
——没有兜底（这件事系列三全篇在讲） - 所有人 KPI 都是"上线"或"上线第一个月的自动化率"，没有任何角色为"系统活到 6 个月"负责
——没有长期问责
5 条里 0 条 yes 的项目，至少跨过了"上线即放养"的门槛。5 条里 3 条以上 yes 的项目，6 个月内大概率出事。把这 5 条放到下次复盘会上，让大家在桌面上对一下"现在站在哪"。
写在最后：把这场合谋摆桌面上
"上线即放养"不是技术问题，是决策结构问题。技术上每一道工序（Critic、监控、eval、灰度）都是成熟方案，业界跑了几十年。卡住的是没有人在 incentive 上为"6 个月后"负责。
执行层能做的事不多但关键：把这场默契的合谋摆到桌面上。下次评审会拿这 4 个问题问供应商，下次内部立项把这 6 个环节列进 SOW，下次老板说"我们不是 Apple 没必要那么细"，把这一篇拍给他看。
"我们还不到那个级别"是一句把责任推给"以后"的话。但 AI Agent 项目里没有"以后"，上线那天起事故的种子就埋下去了。6 个月后挖出来的，是当初省下的每一笔运维钱，加上 10 倍利息。
如果你公司的方案在前面 5 条自检里命中超过 2 条，从今天起补。补 1 条比补 5 条容易，补 5 条比出 1 次事故便宜。
工具包领取
如果你想把这一篇里的工具立刻用到下次评审会，我整理了一个 PDF 工具包：
回复关键词「PRODUCTION」，我把工具包发给你：
6 环节差距对照表（demo vs production 一页 A4，评审供应商方案时打勾） 评审会 4 问 + 合格答案样本（带话术，可直接照着问；包含供应商常见的"不合格答案"识别） 5 条自检清单（贴在工位墙上，每月对照一次）
这一年跟项目踩出来的判断工具，送给读到这里的你。
回复渠道见页脚（公众号 / X）。不方便回复的，评论区留邮箱也行。
这个系列接下来要写什么
A4 系列下一篇排期——
- 3 级 intent 级联调参
（系列二决策 2 深挖）：规则 + embedding + LLM 三级 fallback 的置信度阈值、cache 策略、新意图上线怎么不影响存量 - LLM 接入企业 SaaS 生态
（系列二决策 4 深挖）：25 API → 5 tool 的封装契约、幂等性、超时重试、灰度发布 - AI 系统怎么测
（独立深挖）：双轨架构 + 7 质量维度 - 上线后第一次大事故的复盘 SOP
（本篇延续）：事故 24h 内做什么、怎么写复盘、怎么改 KPI 不让同样的事故再发
如果你的团队正在做客服 Agent 或别的 L2 写操作类 Agent，这 4 篇接下来 3-4 周内一篇一篇出。
原文 · 评论 · 双语版：yaqinhei.com/blog/agentic-ai-methodology-4-deploy-and-abandon
