Agent 的第 90 天：为什么大多数自动化项目死在这里

一、那条几乎人人都会走一遍的曲线

把过去两年真正上线过的 Agent 项目拉成一条时间线，形状惊人地统一：

第 1 周，Demo 成功。输入一段自然语言，它调了三个工具，产出了一份看起来像模像样的结果。会议室里所有人都在点头。

第 2 周，接入真实数据。开始出现"这个字段它读错了""那个接口它调了两次""结果格式偶尔不对"。团队说没事，加几条提示词约束就好。

第 4 周，灰度上线。前三天数据漂亮，第五天开始有人反馈"它给我判错了"。工程团队开始每天手动修正十几条 case。

第 8 周，修正量没有下降，反而稳定。大家意识到这不是冷启动问题，是长尾问题。

第 12 周，项目被"暂时冻结"，等待"下一代模型"。

这条曲线的名字，行业里有个不太好听的说法：Demo 死亡谷。

它跟模型能力的关系，比大多数人想象的要小得多。

二、三条暗礁

拆开看，卡死的位置集中在三个地方。

暗礁一：长尾不是 10%，是 40%

做方案时，大家默认"80% 的常规 case 模型能处理，剩下 20% 交人工"。上线后才发现真实分布是：常规 case 只占 55%，剩下 45% 全是各种变体——格式不规范、信息缺失、跨系统不一致、历史遗留的特殊政策。

这 45% 不是噪音，它才是业务的真身。​

只处理 55% 的自动化系统，收益覆盖不了它带来的额外维护成本。这就是为什么很多项目"跑得挺好，但不划算"。

暗礁二：没有评估，只有观感

绝大多数团队在立项时没有建评测集。于是所有的迭代都建立在"我觉得这次好一点"之上。

结果是：改 A 问题的提示词，B 问题变差，但没人知道，因为没人测。三个月后系统变成一堆互相冲突的约束条件堆叠，谁都说不清它现在到底什么水平。

没有评估集的 Agent 项目，等于没有测试的代码库。​ 不是会不会烂，是烂到什么程度的问题。

暗礁三：责任真空

出错谁背？

这个问题的杀伤力被严重低估。技术上它能跑，业务上没人敢用，因为一旦出错，追责链条上第一环就是"谁批准上线的"。

于是出现一个诡异局面：系统在跑，但每个关键节点都被人为加了一道人工确认。加了五道确认之后，自动化的时间收益被吃干净了。

自动化真正的对手不是准确率，是信任。​

三、活下来的项目，做对了什么

观察那些撑过第 90 天、并且第二年还在扩量的项目，它们的共同点非常集中，而且都不"高级"。

一，范围窄到有点寒酸

不做"智能客服"，只做"退款金额核算"。不做"运维助手"，只做"根据告警定位最近一次变更"。

范围窄带来的直接好处：case 类型收敛，评测集好建，长尾可控，出错影响面小。窄，是可以上线的先决条件。​

二，把不确定性当成一等公民

好的实现不是让模型"给答案"，而是让它输出三段结构：

• 结论（我要做什么）
• 依据（我基于哪几条信息得出）
• 存疑点（哪几条我拿不准，建议人工看）

第三段是关键。它把"判断对错"的责任从"系统"转移到了"人复核存疑项"，业务方立刻就能接受——因为工作量从"全部重看"变成了"只看标红的几条"。

三，设计了一条随时能退回去的路

每个 Agent 动作都有对应的逆操作，或者干脆做成"草稿态"，等人点确认才生效。写操作一律幂等，重试不会产生重复副作用。

这条设计看起来保守，实际上是让项目活下来的核心：能退，才敢进。​

四，用日志喂自己

每次人工修正都被记录下来：模型原判、人工改判、改了哪一项。三个月后这份数据就是最好的评测集和最好的微调语料。

不做这件事的团队，三个月后手里只有一堆抱怨；做了的团队，手里有 3000 条带标签的真实样本。

四、一份可以直接抄的工程清单

如果你正在做这类项目，下面这些是能落到实处的：

立项阶段

• 拉出目标流程最近三个月的真实工单，人工标注 100 条，统计真实分布。别用想象的比例。
• 用这 100 条算出"模型处理 + 人工复核"和"纯人工"的实际耗时对比。算不过来就别做。

开发阶段

• 评测集从第一行代码开始建，每次改动跑一遍，记录准确率、误判方向、平均耗时。
• 提示词里显式要求输出"依据"和"存疑项"，不要只输出结论。
• 所有工具调用加超时、重试上限、幂等键。

上线阶段

• 先做影子模式：系统跑，但不生效，只记录它"本来会怎么做"。跑两周，跟人工结果比对。
• 比对通过再开灰度，灰度期间每日抽检，抽检结果进评测集。

运维阶段

• 建一个"人工修正回流"通道。每一次人工改判都是免费标注。
• 监控三个数：自动通过率、人工修正率、存疑项占比。修正率连续上升就是模型或数据漂了。
• 明确一个 owner。出事找谁，必须是一个人，不是一个团队。

五、一句不太受欢迎的话

行业里有一种期待的叙事：等模型再强一点，这些问题自然就解决了。

这个判断在方向上是对的，在时间上是错的。

模型变强，确实会把长尾从 45% 压到 30%、20%。但长尾永远不会归零，因为业务的复杂性会随着自动化程度提高而暴露得更充分——你把简单的处理掉了，剩下的全是难的。这是流程优化的铁律，与 AI 无关。

所以真正决定项目生死的，不是等来的那一代模型，而是你有没有建起一套能够持续吸收错误、修正错误、并且让人敢用的机制。

模型是引擎，机制是底盘。引擎每年都在换代，底盘得自己造。

第 90 天倒下的项目，几乎都不是引擎的问题。