来自硅谷一线 AI 创业者的数据：95% 的 AI  Agent 在生产环境都部署失败了。

“不是因为模型本身不够智能，而是因为围绕它们搭建的脚手架，上下文工程、安全性、记忆设计都还远没有到位。”

“大多数创始人以为自己在打造 AI 产品，但实际上他们构建的是上下文选择系统。”

为什么 95% 的 AI Agents 部署都失败了？成功的那些有什么实践经验可以借鉴？

前两天，在旧金山的一场行业研讨会上，来自 Uber、WisdomAI、EvenUp 和 Datastrato 的工程师与机器学习负责人们，聊了聊构建 AI Agent “冰山之下的核心关键” ：上下文选择、语义层、记忆编排、治理机制以及多模型路由。

太多团队把提示和产品混为一谈，真正重要的工程工作应该得到应有的重视。AI 产品开发中的核心关键是：构建一个复杂而强大的“上下文选择系统”。

文章基于研讨会的内容整理，都是来自成熟 AI 团队的实践和踩坑总结，很实用。

一、上下文工程≠ Prompt 技巧

多位嘉宾都提到了同一个核心观点：精细调整模型的需求其实非常少见，一个设计完善的检索增强生成系统通常就已经能满足需求。但目前大多数 RAG 系统的设计都还太过初级。

常见的失败模式包括：

编入索引的内容过少→模型缺乏有效信号→无法给出高质量回答；

不加区分地混合结构化与非结构化数据→破坏嵌入向量的语义，或将关键的数据结构“压平”导致信息丢失。

那么，先进的上下文工程究竟该如何设计？

为 LLM 量身打造的特征工程

一位嘉宾将上下文工程重新定义为“ LLM 原生的特征工程”，具体包括：

“上下文可观测性”=追踪哪些输入提升或削弱了输出质量；

这个视角很重要，意味着我们可以像管理代码一样，将上下文作为一个可版本化、可审计、可测试的“工件”，而不再是把它看作一团杂乱的文本。

语义+元数据双层架构

多个团队都提到了双层架构设计：

元数据层→基于文档类型、时间戳、访问权限或特定领域的本体来强制执行过滤。

这种混合架构有助于统一处理杂乱的输入格式，并确保你检索到的不仅仅是“相似内容”，更是高度相关的结构化知识。例如，在嵌入向量之上，构建分类体系、实体链接与领域特定的数据结构。

Text-to-SQL 的现实挑战

当主持人提问“有多少人已经将文本转 SQL 系统投入生产环境”时，现场没有一个人举手。

这不是因为需求过于小众，而是由于查询理解的难度非常高。自然语言存在歧义，业务术语又具有极强的领域特性。如果没有上下文的工程， LLM 根本无法理解企业内部对“收入”或“活跃用户”的定义。

能成功实现的团队，不会简单地将 SQL 结构直接提供给模型，而是构建了以下支撑体系：

二、垂直领域必修课：信任的本质是人，不是技术

安全性、溯源能力与权限控制，在这场讨论中反复被提及，它们不是可有可无的“勾功能选项”，而是阻碍系统部署的关键障碍。

垂直领域的创业者们，需要注意：

必须能做到即使 Prompt 相同，也需要为不同用户提供定制化输出。

一位嘉宾表示：

“如果两名员工问了同一个问题，模型的输出理应不同，因为他们各自的权限不同。”

如果没有这些控制机制，你的 Agents 可能在功能上正确，但在组织层面却是错误的，导致权限泄露或违反合规要求。

当前主流的解决方案模式是：为结构化与非结构化数据构建统一的元数据目录，并在索引与查询阶段嵌入访问策略。

信任的本质是人，不是技术

一位嘉宾分享的个人经历很好地说明了这一点：他的妻子拒绝让他使用特斯拉的自动驾驶功能。为什么？不是因为它不起作用，而是因为她不相信它。

“当 AI 触及与安全、财务相关的敏感领域时，你会信任 AI 吗？我认为这才是最大的障碍。我们有时会开发 AI Agents ，但最终还是要回归人的判断：我真的能信任这个 AI 吗？”

这不仅适用于消费级产品，企业级的 AI Agents 在处理收入确认、医疗记录或合规报告时，也面临同样的信任障碍。信任的核心不是原始的技术能力，而是在于系统能否表现出一致、可解释、可审计的行为。

那么，5% 成功部署到生产环境的 AI Agents 都有一个共同点：都采用了“human-in-the-loop”的设计。它们将 AI 定位为辅助工具，而不是自主决策者；他们构建了反馈循环，让系统能从人类的修正中学习；同时，它们也让人类可以轻松地验证和否决 AI 的输出。

三、记忆功能不是存储，而是一种架构设计

所有人都希望为 AI 添加“记忆功能”，但记忆不是简单勾选的功能，是一个涉及用户体验、隐私和系统整体架构的设计决策。

记忆的层级

大多数初创公司将记忆硬编码到应用逻辑或本地存储中，但优秀的团队会把它抽象为一个独立的上下文层与行为层，实现版本化与自由组合。

一位嘉宾这样描述：

作为个性化工具的记忆

在应用层面，记忆主要服务于两个目的：

根据用户的写作风格、偏好格式、领域专长等个体特征，定制其行为；

基于事件和元数据提供主动协助，而不仅仅是被动地响应聊天。

某个团队分享了他们在 Uber 构建会话式商业智能工具时遇到的“冷启动”难题：用户不知道该提出什么问题。解决方案是：从用户过往的查询日志中提取记忆，然后像一个贴心的主人记得你上次的谈话内容一样，主动推荐相关问题作为对话的起点。

但这里存在一个矛盾：有益的个性化，在什么时候会越界，变为令人不适的“监控式体验”？

一位嘉宾提到，他曾让 ChatGPT 推荐家庭电影，结果对方推荐的内容直接针对他的孩子克莱尔和布兰登。他的反应是：“我不喜欢这个回答。你为什么会知道我儿子和女儿的名字？不要侵犯我的隐私。”

设计中的张力

这里缺少了一个基本元素：一个安全、可移植、由用户掌控的内存层。它可以跨应用工作，数据归属用户，而不是被锁定在服务商内部。目前还没有人真正解决这个问题。一位嘉宾说，如果他没做现在的项目，这就会是他的下一个创业方向。

四、多模型推理与编排模式

另一种正在兴起的设计范式是“模型编排”。

在生产环境中，企业不会将所有任务都交给 GPT-4 处理。越来越多的团队开始根据以下因素，设计智能的路由逻辑：

一个典型的模式：

对于结构化查询 → 调用领域特定语言或 SQL 转换器；

对于复杂分析 → 调用 OpenAI / Anthropic / Gemini 等前沿模型；

作为 fallback或验证→采用双模型冗余设计。

这种设计更接近编译器设计，而不是传统的 Web 应用路由。你不应该简单地“将请求发送给 LLM ”，而是在一个由异构模型、工具和验证环节组成的决策图中，规划出一条最优路径。

为什么这点重要？

如果你的系统随着使用量增长而变慢或成本上升，首先应该优化的就是这一层。此外，如果你希望 AI 为用户提供无缝体验，路由策略就不能是脆弱或永远需要手动调整的，你需要自适应的策略。

一个团队介绍了他们的方法：简单问题交给小型、快速的模型处理；复杂推理任务则路由给前沿模型。核心关键在于：模型选择本身，可以通过追踪“哪些查询在哪些模型上表现更好”来持续学习优化。

五、聊天界面真的是最佳选择吗？

并不是所有任务都需要一个聊天机器人。

一位观众直接对这一前提提出了质疑：“我并不觉得自然语言在任何时候都比图形界面更好。如果我要叫一辆优步，我不想对着手机说话，我只想点几下屏幕，车就来了。”

专家们的共识是：对话式交互的价值，在于它能极大地降低用户的学习门槛。

对于商业智能仪表盘、数据分析这类传统上需要专业知识的复杂工具，自然语言能降低使用门槛。但当用户获得答案后，通常更希望通过 GUI 进行调整，比如，将饼图切换为柱状图，这个操作不应该再需要输入文字。

理想的混合模式

一位嘉宾提到了自然语言处理的两个理想应用场景：

处理偶发的、情绪化的任务，比如客户服务。用户感到沮丧时，只想倾诉或寻求帮助，而不是去浏览层层菜单。

进行探索性的、开放式的查询，比如“帮我在加州找一个能看到海景和蓝天的第一排 Airbnb”，这类需求复杂且充满情境。

核心关键在于：我们应该去理解用户选择自然语言的根本原因，并据此设计交互，而不是强行将所有交互都塞进“聊天”这个框架里。

六、一些仍待解决的问题，也是创业者的机会点

讨论中提到了几个还没有被充分探索，但具备产品化潜力的方向，它们是构建下一代 AI 应用的关键基础组件：

上下文可观测性：哪些输入能持续提升输出质量？哪些上下文会导致模型幻觉？如何像测试模型 Prompt 一样测试上下文？目前，大多数团队都处于“盲目摸索”阶段，缺乏衡量上下文有效性的系统方法。

可组合记忆：能否让记忆归属于用户，而不是被应用绑定？它应该是安全、可移植的，并允许用户自由选择开启组织、团队或个人层级的记忆。

这将解决两个核心问题：

用户不需要在每个新工具中从零开始重新构建自己的上下文；

这是当前技术栈中最大的“缺失组件”。

领域感知的领域特定语言：企业用户的需求大多具有结构化与重复性的。为何我们仍在尝试将自然语言解析为脆弱的 SQL，而不是定义一种更高级、自带安全约束的 DSL？

某团队建议，相比文本转 SQL，不如构建一个语义化的业务逻辑层。例如，让“告诉我第四季度的收入”直接映射到一个经过验证的计算逻辑，而不是生成原始 SQL。

善用延迟，创造价值的用户体验：一位嘉宾提到，他们开发的带记忆增强功能的聊天机器人，虽然响应速度较慢，但用户体验极佳。原因在于：机器人会根据用户上周的提问，主动提供一系列智能跟进建议。

这为异步、主动式 AI 的用户体验设计提供了新思路，远不止于聊天场景。想象一下：智能体在你开会前为你准备好简报，在你打开文档时主动呈现相关上下文，或是在你提问前就主动提醒你数据中的异常。

核心关键在于：不同任务对延迟的要求不同。生成一个笑话需要即时响应，而深度分析即使耗时 10 秒，只要系统能展示它的思考过程并最终给出有效的答案，用户也能接受。

七、未来方向

这场讨论会让我更加确信，我们即将迎来一波基础设施工具的浪潮：记忆工具包、编排层、上下文可观测性解决方案。这些工具未来看似“理所当然”，但目前仍然处于杂乱无章、尚未解决的状态。

生成式 AI 领域的下一个真正“护城河”，不会来自对模型的访问权限，而是源于以下四个方面：

如果你是从事基础设施、应用或 Agents 开发的创始人，不妨思考：你的产品路线图中有多少内容是专门针对这四个方面设计的？

八、创始人需要思考的5个关键问题

用户会放心把他们的财务或医疗数据交给你的系统处理吗？