AI Agent 为何生产环境总是失败：真正原因不是模型

我在 AI 领域花了很多时间——读论文、做东西、和正在交付项目的工程师交流。而演示展示的内容和生产系统的真实面貌之间，存在着一条没人完全坦诚的鸿沟。

以下是我对当前真实情况的一些坦诚看法。

我们谈论 AI Agent 时的误区

现在人人都在把一切叫作"agent"。调用了一个工具的函数？Agent。有记忆的聊天机器人？Agent。带循环的脚本？Agent。

这种语义稀释不只是文字问题。它正在导致真实的工程错误。

当你对自己正在构建的东西没有精确的定义时，你会在简单的 pipeline 上过度工程化，在真正复杂的系统上工程化不足。我见过团队花几周时间为本来一个结构良好的 prompt 就能搞定的工作流添加"agentic"编排。

我一直回归到这个定义：Agent 是一个有目标（而不仅仅是指令）的系统。它决定下一步做什么。它处理失败。它知道自己何时完成。

其他一切都只是一个花哨的函数调用。

🟢 如果你的系统需要人告诉它每一步，这不是 agent。这只是一个聊天界面。

🔵 如果你的系统能从失败的工具调用中恢复并尝试不同方案，你正在接近目标。

✅ 如果你的系统能将目标分解为子任务并委派它们，这才是真正的 agent。

生产环境的真实状况

从我关注和交流的团队那里看到的真实图景：

大多数真实的 agent 部署都是窄场景的。它们把一件事做得好。客户支持分流、文档提取、对特定代码库的代码审查。它们不是通用推理引擎。它们是内置了决策层智能的目的构建 pipeline。

取得好结果的团队不在追逐最新的模型发布。他们专注于：

☑️ 工具设计——agent 实际能调用什么，接口有多干净

☑️ 失败处理——当工具返回无用结果时会发生什么

☑️ 可观测性——你能否追踪到 agent 做出决策的确切原因

得到糟糕结果的团队是那些在不改变其他任何东西的情况下，把 GPT-4 换成最新的前沿模型并期望得到不同行为的团队。

框架之争是分散注意力

LangChain、LangGraph、CrewAI、AutoGen、Semantic Kernel。每月都有新的框架出现，总有人在写文章说旧的那个已死。

我的真实看法是：框架没有模式重要。

无论你使用什么框架，这些模式都持续有效：

✔️ Plan-then-execute。有一个推理步骤产生计划，一个独立的执行步骤来遵循它。不要混在一起。

✔️ 分离检索与推理。获取上下文和使用上下文是不同的职责。混淆它们的系统会迷失方向。

✔️ 显式交接。当一个 agent 把工作交给另一个时，交接应该是结构化的并被记录的。不是通过 prompt 传递一个字符串。

我用三个不同的框架重建了相同的架构，每次结果都相似。框架是脚手架。架构才是建筑本身。

没人解决的检索问题

RAG 现在是标配。几乎每个接触私有数据的生产 AI 系统都在使用某种形式的 RAG。但有一个问题是教程没有很好覆盖的。

分块边界是错的。

当你把文档拆分成块并嵌入时，你正在对什么上下文片段应该组合在一起做出假设。这些假设往往是错的。一段只有结合前一段才有意义的文字被单独检索出来，模型就会对缺失的上下文产生幻觉。

🟢 更好的分块策略有帮助。重叠窗口、语义分块、父文档检索。

🔵 但真正的修复是重新思考你在存储什么。有时候存储的正确内容不是原始文本而是信息的结构化表示。

✅ 如果你的 RAG pipeline 返回的是技术正确但上下文无用的结果，问题几乎肯定在分块或元数据，而不是嵌入模型。

我认为这一切的走向

模型会继续变得更强。上下文窗口会继续扩展。每 token 的成本会继续下降。

这些都不会改变根本的工程挑战：构建在你不在盯着的时候能正确行为的可信赖系统。

这才是值得解决的问题。治理、可观测性和可靠的工具使用。不是追逐基准测试。

两年后真正重要的工程师是那些能构建出其他工程师可以维护和信任的 AI 系统的人。这是一套与微调或 prompt 工程不同的技能组合。

它更接近系统设计，而不是模型研究。

如果这些和你正在构建的东西有共鸣，或者你有完全不同的看法，我想听听。在评论区分享你的经验。这个领域真正有趣的对话不在主题演讲里——而是在人们真正坦诚什么有效的讨论线程里。