Agent 项目失败的真正原因

Agent 项目失败的真正原因

不是模型不行，而是系统不行

绝大多数 Agent 项目失败之后， 都会给出一个非常省事的结论：

“模型还不够聪明。”

这是一个听起来合理、实际上极其逃避责任的说法。

第一部分：一个被误判的真相 —— 模型几乎从来不是瓶颈

1.1 Agent 在真实项目中的典型失败表现

在真实项目里，Agent 常见的失败表现包括：

• 行为不稳定
• 输出不可预测
• 场景一复杂就失控
• 偶发成功，大多数时间失败
• Demo 很惊艳，落地全崩

1.2 问题并不出在单次生成质量

但你如果冷静拆解，会发现：

模型在每一步的回答，本身并没有明显错误。

失败发生在：

• 步与步之间
• 状态与状态之间
• 决策与执行之间

也就是说：

问题出在“系统连接方式”，不是“单次生成质量”。

第二部分：第一层结构性错误 —— 把 LLM 当成“智能体”

2.1 一个错误的默认系统结构

很多 Agent 项目一开始就犯了一个根本性错误：

把 LLM 当成一个“会做事的主体”。

于是系统长这样：

用户 → Agent → LLM → 世界

2.2 把所有责任压给模型的工程后果

所有责任都压在 LLM 上：

• 规划
• 判断
• 决策
• 执行
• 兜底

这在工程上意味着：

你把一个无状态、不可控的函数， 当成了系统核心控制器。

第三部分：工程铁律被违背 —— 不可预测组件掌控了决策权

3.1 成熟系统中的基本原则

在成熟的软件系统中，有一个铁律：

不可预测组件，永远不能处在控制链路的最上游。

3.2 Agent 项目中的反工程实践

但 Agent 项目恰恰相反：

• if / while 在 prompt 里
• 状态机在语言里
• 异常处理靠“请你重新想一想”

这不是智能，这是失控前的侥幸。

第四部分：Agent 项目失败的四个真实原因

4.1 原因一：系统中没有控制结构

4.1.1 缺失的工程基础组件

绝大多数失败的 Agent，都缺少以下结构之一：

• 显式状态机
• 明确的阶段边界
• 可回溯的执行轨迹
• 可中断的流程控制

4.1.2 不知道“现在在哪一步”的后果

结果就是：

系统不知道自己现在在哪一步。

而一旦系统不知道“现在在哪”， 那任何一步错误都会被无限放大。

4.2 原因二：业务逻辑被写进了 Prompt

4.2.1 Prompt 被当成业务系统使用

这是 Agent 项目中最常见、也最隐蔽的问题。

你会看到：

• 权限判断在 prompt 里
• 流程分支在 prompt 里
• 风控规则在 prompt 里
• 边界条件用自然语言描述

4.2.2 Prompt 不具备逻辑系统的基本属性

短期看起来灵活，长期一定崩。

原因很简单：

Prompt 不具备“逻辑收敛性”。

它无法保证：

• 穷尽性
• 一致性
• 可验证性

4.3 原因三：错误没有被工程化处理

4.3.1 失败在 Agent 系统中是常态

在 Agent 项目里，失败几乎是常态：

• 调用失败
• 参数错误
• 输出不符合预期
• 工具异常

4.3.2 “让 Agent 自己修”的真实结果

但很多系统对失败的处理是：

“让 Agent 自己修。”

于是你得到的是：

• 二次幻觉
• 三次补救
• 四次偏离

最终彻底跑飞。

错误处理如果不是代码写的， 那它就是不存在的。

4.4 原因四：没有“失败即止损”的机制

4.4.1 一个危险的系统特征：永远在尝试

很多 Agent 系统有一个危险特征：

永远在尝试。

• 失败了就再试
• 不行就换说法
• 再不行就“深度思考”

4.4.2 没有上限的系统必然失控

结果是：

• 成本失控
• 延迟爆炸
• 行为不可预测

一个成熟系统一定有：

• 最大步数
• 最大成本
• 最大时间
• 明确终止条件

没有这些， 你做的不是 Agent，而是死循环。

第五部分：为什么 Demo 能跑，上线必崩

5.1 Agent Demo 的共同特征

绝大多数 Agent Demo，都有一个共同特点：

它们是“一次性成功”的。

你只要多问几次、多换几个输入、多并发跑几条，就会发现：

• 行为开始漂移
• 结果不可复现
• 成功率骤降
• 成本和延迟直线上升

5.2 Demo 与生产系统的假设完全相反

这并不是“模型不稳定”，而是因为：

Demo 根本没有被设计成系统。

Demo 的默认假设是：

• 输入是友好的
• 路径是理想的
• 工具是可用的
• 模型是配合的

而生产系统的假设恰恰相反。

第六部分：模型升级解决不了的根本问题

6.1 “模型是不是不够强”的错误归因

很多团队在 Agent 出问题时，第一反应是：

“是不是模型还不够强？”

于是他们会尝试：

• 换更大的模型
• 打开更高的 reasoning
• 加长上下文
• 提高 temperature 调参

6.2 与模型能力无关的系统性问题

短期可能有改善，但很快你会发现：

问题只是被延后，而不是被解决。

因为以下问题，和模型能力无关：

• 状态是否可追踪
• 决策是否可回溯
• 错误是否可定位
• 行为是否可约束

模型再强，也解决不了系统结构性缺陷。

第七部分：Context 失控与系统不可观测性

7.1 Context 被误当成“记忆”

这是 Agent 项目中最隐蔽、也最致命的问题。

你会看到典型现象：

• 用得越久，Agent 越“笨”
• 明明给过信息，却反复问
• 回答开始变得冗长、模糊、自相矛盾

原因只有一个：

Context 被当成了“记忆”，但它不是。

Context 是：

• 无结构的
• 不可验证的
• 不可裁剪的
• 不知道哪些信息还“有效”

当你把一切都塞进上下文， 系统实际上已经失去了对状态的控制权。

7.2 不可观测，是 Agent 最大的工程风险

传统系统里，你至少能知道：

• 当前状态
• 执行路径
• 异常位置

而很多 Agent 系统只有：

“模型刚才这么说的。”

你不知道：

• 为什么选择了这个工具
• 为什么忽略了另一个方案
• 为什么这一步失败后还能继续

这意味着什么？

当 Agent 出问题时，你甚至不知道该修哪里。

不可观测的系统，最终一定会被弃用。

第八部分：工具调用与不确定性的放大效应

8.1 工具调用本身就是不确定性来源

在 Agent 系统里，工具通常是：

• 外部 API
• 数据库
• 第三方服务

每一个工具调用，都是一次不确定性引入。

8.2 错误如何被指数级放大

而很多 Agent 的设计是：

模型自己决定“是否调用 + 调用什么 + 用什么参数”。

一旦第一次判断出错：

• 错误参数进入工具
• 工具返回异常结果
• 异常结果又被模型“合理化”

于是错误被指数级放大。

第九部分：为什么 Agent 必须有 fallback

9.1 一个反直觉但必需的结论

这是 Agent 工程中一个非常“反直觉”的结论：

一个没有 fallback 的 Agent，本质上不可用。

9.2 fallback 的真实工程意义

fallback 的意义不是“保守”，而是：

• 明确系统边界
• 保证最坏情况下的行为
• 防止错误无限扩散

典型 fallback 包括：

• 回退到规则逻辑
• 回退到人工确认
• 回退到只读模式

没有 fallback 的 Agent，只是运气系统。

第十部分：成功 Agent 系统的真实样子

10.1 “反智能”的共同特征

真正能上线、能跑、能维护的 Agent，反而有一些“反智能”的共性：

• LLM 只做判断，不做控制
• 决策结构在代码里
• 状态是显式建模的
• 每一步都可被中断
• 模型可以随时替换

10.2 Agent 的智能感从哪里来

你会发现：

Agent 的“智能感”，来自系统设计，而不是模型本身。

甚至可以说一句很残酷的话：

Agent 越成功，LLM 越像一个普通函数。

结语：Agent 是系统工程，不是 Prompt 魔法

Agent 项目失败， 几乎从来不是因为模型不够强。

而是你用“演示级智能”， 去支撑“生产级系统”。

当你真正理解这一点， 你就会自然走向下一个问题：

那一个“正确的 Agent 架构”，到底应该长什么样？