AI Agent生产失败的真实原因：不是模型问题

我在 AI 领域花了大量时间——读论文、做项目、和真正在交付产品的工程师交流。演示和生产系统之间有一条鸿沟，没有人在这件事上完全诚实。

所以这是我真实的想法。

我们谈论 AI Agent 的方式有问题

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

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

当你不清楚自己要建的是什么时，你会要么对简单流水线过度工程化，要么对真正复杂的系统工程化不足。我见过团队花几周时间为本来一个结构良好的 prompt 就能搞定的工作流添加"agentic"编排。

我始终坚持这个定义：agent 是一个有目标的系统，而不只是有指令的系统。它决定下一步做什么。它处理失败。它知道自己何时完成。

其他都只是一个 fancy 函数调用。

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

🔵 如果你的系统能在工具调用失败后恢复并尝试不同方法，你正在接近真正的 agent。

✅ 如果你的系统能把一个目标分解为子任务并委派它们，那就是真正的 agent。

生产环境中实际在发生什么

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

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

拿到好结果的团队不在追最新模型发布。他们在死磕：

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

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

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

拿到坏结果的团队是那些把 GPT-4 换成最新前沿模型、却不改变其他任何东西、然后期望得到不同行为的人。

框架大战是干扰项

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

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

无论你用哪个框架，一直有效的模式是：

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

✔️ 分离检索与推理。获取上下文和使用上下文是不同的任务。混淆它们的系统会困惑。

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

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

没有人解决的检索问题

RAG 现在是标准做法。几乎每个接触私有数据的生产 AI 系统都在用某种形式的 RAG。但有一个问题，教程没有讲清楚。

分块边界是错的。

当你把文档拆分成块并嵌入时，你在对哪些上下文片段应该在一起做假设。这些假设往往是错的。一段孤立地被检索时才能发挥作用的段落，模型会因为缺失的上下文而产生幻觉。

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

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

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

我认为这一切将走向何方

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

这些都不会改变根本的工程挑战：构建在你不在监视时也能正确运行的可信系统。

这才是值得解决的问题。治理、可观测性、可靠的工具使用。而不是追 benchmark。

未来两年会重要的工程师，是能构建出其他工程师可以维护和信任的 AI 系统的人。那是一种不同于微调或 prompt 工程的技能组合。

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

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