90% 的 Agent 失败，不是框架不行，而是卡在 5 个工程问题

过去一年，如果你曾修复过 Agent 的 Bug，大概率已经撞上了一堵名为“工程复杂性”的墙。AI Agent 社区有个典型的叙事：先用 LangChain，发现太抽象；换成 CrewAI，发现协作链路不可控；再研究 LangGraph，开始手动画图，终于以为找到了银弹——然后上线一周，凌晨三点被 PagerDuty 叫醒。

核心分歧：Demo 与生产环境的鸿沟

2024年是“Agent能做什么”的秀场年，2025年是“Agent框架哪家强”的选型年。而2026年上半年给出的信号非常明确：这不再是一个框架问题，而是一个工程问题。一个典型现象：几乎所有 Agent 框架的 Demo 跑起来都很顺。给 GPT-4 配上一个搜索工具，再加一个代码解释器，演示效果令人心动。开发者兴冲冲地把它接入自己的业务系统，然后开始出 Bug——不是偶尔出错，而是一个接一个的连锁失败。

问题一：工具调用失败——Agent 最脆弱的环节

Demo 里的 Agent 面对的是精心控制的环境和单一意图。而生产环境的 Agent 面对的是模糊意图、不可靠的下游服务、以及一个东西没处理好就影响全局的级联效应。这不是一个“换个更好的模型”就能解决的问题。当 Claude Opus 4.7 和 GPT-4.1 的能力已经远超一年前，Agent 的失败率却并没有同等下降——问题不在推理引擎，在工程底盘。

问题二：上下文丢失——Agent 的“健忘症”

模型生成了正确的 JSON、正确的函数名、正确的参数类型——但工具就是没跑通。原因可能是一百种里的任何一种：超时、网络抖动、API 返回了意料之外的格式、权限过期、限流、参数语义正确但业务逻辑非法……框架对这件事的处理通常极其粗粒度：要么重试 n 次，要么把错误信息原样丢回给 LLM，寄希望于模型能“看懂”并纠正。但实际效果是——当第一个工具调用失败后，Agent 的后续行为往往越来越离谱。真正的解法在于：让工具的错误信号对 Agent 可编程，建立一个薄薄的错误抽象层——不是框架，是工程契约。

多轮对话中，Agent 需要在不断膨胀的消息历史中，记住最初的任务目标、中间的关键决策、以及已经尝试过什么。这不只是 token 限制的问题。更隐蔽的失败模式是：上下文没有丢在 token 数量上，而是丢在了注意力分布上。当对话历史超过几千个 token，模型开始倾向于关注最近的几轮交互，而忘记几十轮前的约束条件。框架在上下文管理上做了太多“自动化”，反而剥夺了开发者对关键信息的控制力。真正有效的不是把所有历史全部压缩进上下文，而是有选择地保留、结构化、并在合适的时机重新注入。这是信息架构问题，不是框架配置项。

如有侵权，请联系删除。