这篇掘金 Agent 教程提出的判断很直接：大模型无法感知真实故障，只能机械重复无效调用——这是多数 Agent 项目在真实业务里频繁崩盘的根因。

这是什么

教程提出一个架构：「Error as Observation」（错误即观测）。所有工具报错——403 反爬拦截、网络超时、解析失败——不再被程序员在 try/except 里悄悄吞掉，而是统一打包成 OpenAI 标准 role='tool' 消息，写进对话历史喂回给大模型。

听起来技术，但回答了一个朴素问题：AI 干活遇到意外，谁做主？传统做法是程序员替 AI 写兜底逻辑，遇到报错直接 return；当 AI 面对陌生环境，这种'程序替 AI 兜底'会切断它的自主判断——它连自己刚刚失败都不知道，只能机械重复无效动作。

具体招数：工具函数删光 try/except，让错误自然冒上来；调度层把异常转成'标准工具消息'写进历史；系统提示词里明说'网络不稳定，你自己分析失败原因'；再配一个'动态熔断'——某工具连续报致命错误，下次请求时直接从工具清单里删掉。

行业怎么看

这套思路在工程圈不算新鲜，Anthropic、Google 内部 Agent 框架早就在用类似模式。但放在 Agent 大爆发的节点，意义被放大：我们注意到大量企业 Agent 项目演示惊艳，一进真实业务就崩，本质都是没做'错误即信息'这一层。

不过也有反对声音。某大厂资深架构师质疑：把错误原封不动丢回给大模型，Token 消耗会显著上升，对话历史也会被错误信息'污染'，长期看反而可能让 AI 学会'找借口'——明明工具好好的，模型也倾向于怀疑它坏了。更现实的担忧是：国内多数企业根本没有可靠的工具生态，Agent 调用的全是脆弱爬虫和未鉴权 API，再聪明的错误处理也只是'漂亮地失败'。

对普通人的影响

对企业 IT：评估 Agent 项目时，把'错误处理能力'放进验收清单——别只看 demo 能不能跑通，要看在断网、被拦截、接口变更时它能不能自己决定下一步。

对个人职场：现在很多'AI 助手'看起来智能，真用起来一遇边界情况就重置或胡说八道。理解这套机制后，你就知道哪些产品是真工程，哪些只是包装过的 demo。

对消费市场：管理预期——未来 1-2 年内你买的'AI Agent 服务'，很可能在 80% 场景下能用，在剩下 20% 异常场景下表现得像一个失忆的人。这是行业现状，不是哪家产品偷懒。