关于 AI 智能体的真实内情

去年我为客户将 25 个以上 AI 智能体部署到了生产环境。以下是在第三周搞垮它们的头号原因。过去 14 个月里，我一直在为各类公司（初创企业、中型 SaaS，甚至一家医疗公司）构建生产级 AI 智能体。我反复看到一个 YouTube 上没人提及的模式。问题不在于 LLM 的选择。不在于框架。甚至不在于提示词。而在于记忆。我部署的每一个智能体，在生产环境运行三周后，都会遇到同样的障碍：用户期望智能体记住昨天的上下文。但智能体做不到。对话从零开始。决策被反复推翻。用户失去信任。采用率下降。你在网上看到的大多数课程完全跳过这一点。它们用 Jupyter Notebook 演示一个聊天机器人，声称“生产就绪”，却从不提及进程重启时会发生什么。来自客户的实际案例（已脱敏）：一家房地产公司构建了一个房产描述智能体。演示时效果极佳。但投入生产后，智能体每次重启都会“重新发现”相同的房源并重新生成描述，仅 OpenAI 调用每月就浪费 400 美元。通过添加持久记忆解决：智能体跳过已描述的房产。成本下降 80%。一家面向 HR 团队的 B2B SaaS 公司，其智能体负责总结面试候选人。客户不断追问：“为什么智能体将这位候选人标记为‘高风险’？”原始智能体完全没有审计轨迹。我们添加了决策日志 + 记忆快照。现在每条推荐都可审计。他们终于能交付给企业客户了。一位独立开发者运营着编码助手 SaaS，他的智能体在大约 5% 的会话中陷入无限工具调用循环，悄悄烧掉每月 2000 美元的 API 成本。足足两个月才发现。通过循环检测 + 自动暂停解决了问题。生产级智能体的正确技术栈经过多次部署后，我总结出一个基本可靠的技术栈：LLM：大多数任务用 Claude Sonnet 4，特定工具链用 GPT-4；框架：Pydantic AI 或 LangChain 用于编排（取决于团队熟悉程度）；记忆层：Octopodas 或 Mem 处理持久化、循环检测、审计轨迹，一体化集成；可观测性：Sentry 用于错误监控，Langfuse 用于追踪检查；评估：Promptfoo 或自建回归测试套件。记忆层是大多数团队跳过、后来付出代价的部分。你可以自托管 pgvector + Redis + 自定义审计表——我做过三次，会花掉你 3-4 周的工程时间，而你根本没有那么多时间。或者你直接 pip install octopoda，三行代码即可运行。令人不适的真相：模型不是瓶颈。记忆和编排才是。任何告诉你“Claude 与 GPT 的对比”是重要决策的人，都没有真正交付过生产级智能体。循环会悄悄让你破产——不是崩溃，而是静默循环。智能体重复调用同一个失败的工具 200 次，成本远超工具调用本身。除非你进行检测，否则仪表盘上根本看不见。可审计性在 B2B 中并非可选。企业客户会在 90 天内追问：“你的 AI 为什么做出 X 决策？”如果你无法回放决策过程，就会丢单。记忆 ≠ 向量数据库。Pinecone 不是记忆层，它只是一个向量索引。记忆意味着：持久化、召回、冲突解决、审计、快照、恢复。单靠 Pgvector 做不到。“直接用 OpenAI 的 Assistants API”——演示能用，扩展时崩溃，且会锁定你。别这样做。如何真正交付一个智能体：从你日常工作或朋友公司中选一个具体工作流——要具体，别泛泛。「自动分类我们的支持工单」而不是「AI 用于支持」。先构建最差版本：无需记忆，无需错误处理，只证明 LLM 能完成该任务。然后添加记忆，观察智能体在上下文持久化时的行为。接着添加错误处理和审计，然后才能调试。部署给一个用户，连续观察两周交互。存活下来的智能体都很无趣。它们可靠地做一件事。它们记住过往。它们记录一切。它们从不陷入无限循环。LinkedIn 演示中的智能体，不是投入生产的那些智能体。