为什么95%的智能体都部署失败了？这个圆桌讨论出了一些常见陷阱

选自Motive Notes

作者：Oana Olteanu

机器之心编译

「95% 的 AI 智能体在生产环境中部署时都失败了。」在硅谷近期的一个圆桌论坛中，有位嘉宾给出了这样一个数字。

这个论坛由 EntreConnect（一个企业家、投资者社区）组织，来自 Uber、WisdomAI、EvenUp 和 Datastrato 的工程师及 ML 负责人参与了讨论。他们认为，多数 AI 智能体之所以部署时失败，不是因为模型不够智能，而是因为围绕它们的基础框架、上下文工程、安全性和记忆设计尚未成熟

EntreConnect组织的论坛「Beyond the Prompt: AI Inference x Context Engineering with Uber, Wisdom AI, EvenUp and Datastrato」

他们进一步指出，真正的差距在于上下文工程，「大多数创始人以为自己在构建 AI 产品，实际上他们在构建的是上下文选择系统。」成功的团队不是在优化提示词，而是在构建语义层、元数据过滤、特征选择和上下文可观察性。正如论坛上的一个比喻所说：「基础模型是土壤，上下文才是种子。」

当然，技术挑战还不是全部。即便系统在功能上表现完美，如果无法追溯输出来源、无法遵守权限控制、无法让用户真正信任它处理敏感数据，部署依然会失败。一位与会者分享了他妻子拒绝使用特斯拉自动驾驶的故事 —— 不是因为它不好用，而是因为缺乏信任。这个问题同样存在于企业 AI 智能体中。成功部署的那 5% 智能体都有一个共同点：人机协作设计，让 AI 扮演助手而非自主决策者。

这篇文章由论坛主持人 Oana Olteanu 撰写，深入探讨了这次圆桌论坛的核心洞见：从上下文工程的最佳实践、记忆架构设计、多模型编排，到治理框架和用户体验设计。如果你正在构建 AI 产品、基础设施或智能体系统，这些来自一线工程师的实战经验，或许能帮你避开一些失败陷阱。

上下文工程，不是提示词黑科技

这场讨论中，几位嘉宾不约而同地提到：微调往往并非必要。

在多数场景中，一个构建良好的 RAG（检索增强生成）系统已足够高效 —— 但现实是，绝大多数 RAG 系统都太过粗糙。

它们常见的失败模式包括：

• 盲目索引一切 → 模型被无用信息淹没
• 索引太少 → 模型缺乏信号支撑
• 混合结构化与非结构化数据 → 打破嵌入空间一致性

那么，「高级的上下文工程」究竟长什么样？

上下文层参考资料：https://www.wisdom.ai/ai-for-business-intelligence/semantic-layer

1、面向 LLM 的特征工程

一位嘉宾提出了一个极具启发的框架：

把上下文工程看作 LLM 的原生特征工程（feature engineering）。

• 选择性上下文剪枝 = 特征选择
• 上下文验证 = 类型 / 时间 / 模式校验
• 上下文可观测性 = 追踪哪些输入改善或削弱输出质量
• 嵌入增强 + 元数据 = 类型化特征 + 条件信号

这意味着：上下文不再是「字符串拼接」，而是一个可测试、可版本化、可审计的数据工件。

2、语义层 + 元数据层的双层结构

一些团队分享了他们的「双层架构」实践：

• 语义层：负责经典的向量检索
• 元数据层：基于文档类型、时间戳、访问权限、领域本体等执行过滤

这种设计能在混乱的数据源之间建立秩序（PDF、日志、音频、指标等），确保检索结果不是简单的「相似内容」，而是真正的「相关知识」。

换句话说，它让 AI 能理解语义，也能尊重结构。

3、text-to-SQL 的现实检验

当场上问观众「有谁把 text-to-SQL 做到生产环境里」时，一个举手的都没有。原因不是这个问题小，而是把自然语言稳定、可靠地映射到业务级查询比想象中难得多。自然语言本身模糊、歧义重；企业术语又常常有上下文依赖 ——「营收」「活跃用户」在不同公司、不同团队的定义可能完全不同。

成功的团队不会把数据库 schema 生搬给模型然后指望它猜对。他们做的是工程化的抽象与保护措施，包括：

• 业务词典与术语映射
• 受约束的查询模板
• 执行前的语义校验层

能够随时间提升理解的反馈循环可参见：https://www.wisdom.ai/ai-for-business-intelligence/text-to-sql

为什么「信任」与「治理」是核心问题

安全、权限、数据溯源这些词，在现场被反复提到。

它们不是合规清单上的「打钩项」，而是 AI 系统落地的关键阻力。

垂直领域创业者要注意做到以下几点：

• 要能追踪哪个输入导致了哪个输出
• 必须遵守行级、基于角色的访问权限
• 即使提示词相同，也必须支持用户专属的输出结果

如果两名员工问了同一个问题，AI 的答案应该不同。因为他们的权限不同、上下文不同。没有这样的访问与策略控制，AI 的答案可能「技术上正确」，但「组织上错误」—— 泄露信息、违反合规。

领先团队的做法是：在结构化与非结构化数据的统一目录（metadata catalog）中，嵌入访问策略，在索引和查询阶段同时生效。

信任问题并非技术瓶颈，而是人性瓶颈。 一位嘉宾讲了一个故事 —— 他太太拒绝让他开自动驾驶。不是因为它不好用，而是因为她不信任。AI 若要处理金钱、医疗、或安全相关决策，必须先赢得这种信任。那些真正成功的 5% 的系统，都有一个共通点：人机协同（human-in-the-loop）。AI 被设计为助手，而非决策者；能被监督、能被纠正、能被解释。

记忆，不是功能，而是系统结构

每个团队都说想给 AI 加记忆。但真正懂系统的人知道 —— 记忆不是一个 feature，而是一个涉及用户体验、隐私和系统影响的设计决策。

记忆有三个层面：

• 用户层面：偏好（如图表类型、风格、写作语气）
• 团队层面：循环查询、仪表盘、运行手册
• 组织层面：组织知识、政策、先前的决策

大多数初创公司将记忆硬编码到应用逻辑或本地存储中，但顶尖团队会将记忆抽象为一个「上下文层 + 行为层」的组合，可版本化、可复用。

他们的定义是：

• 语义记忆 + 分类体系 + 运行手册 = 上下文；
• 用户偏好 = 记忆

记忆即个性化

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

• 针对个体用户定制行为：适配其写作风格、偏好格式、领域专长
• 基于事件和元数据的主动辅助：而非仅仅被动响应聊天

有团队分享了在 Uber 构建对话式 BI 工具的经验。冷启动问题是什么？用户不知道该问什么。解决方案是从用户的历史查询日志中构建记忆，然后推荐相关问题作为对话起点 —— 就像一个记得你上次聊天内容的人。

但问题在于：有用的个性化何时会越界成为令人不安的监控？

一位与会者描述，他向 ChatGPT 询问适合全家观看的电影推荐，结果 ChatGPT 给出了针对他孩子 Claire 和 Brandon 的个性化建议。他不喜欢这个答案，说「你为什么对我的儿子和女儿了解得这么清楚？别碰我的隐私」。

在设计时，你需要考虑：

• 记忆改善用户体验和 AI 流畅度
• 但过度个性化很快会侵犯隐私领域
• 共享记忆可能打破访问控制，除非仔细划定范围

这里缺失一个关键原语：一个安全、可移植的记忆层，可跨应用工作，由用户使用，而非锁定在服务商内部。目前还没人真正解决这个问题。一位与会者说，如果他不做现在的创业项目，这会是他的下一个目标。

多模型推理与编排模式

另一个新兴设计模式是模型编排。

在生产环境中，你不能对所有任务都调用 GPT-4。团队越来越多地基于以下因素运行模型路由逻辑：

• 任务复杂度
• 延迟限制
• 成本敏感度
• 数据本地化 / 监管要求
• 查询类型（如摘要 vs 语义搜索 vs 结构化问答）

以下是一些可能的情况：

• 简单查询 → 本地模型（无网络调用）
• 结构化查询 → 调用 DSL → SQL 转换器
• 复杂分析 → 调用 OpenAI/Anthropic/Gemini
• 兜底或验证 → 双模型冗余（评判者 + 响应者）

这更接近编译器设计而非网页应用路由。你不只是「发送给 LLM」，而是在异构模型、工具和验证之间运行一个决策 DAG（有向无环图）。

为什么这点很重要？如果你的系统随着使用量增长而变得更慢或更贵，这是首先需要重新审视的层面。如果你希望 AI 对用户感觉无缝，路由就不能永远依赖脆弱的手工调优。你需要自适应策略。

有团队分享了他们的方法：简单问题交给小型快速模型，复杂推理任务路由到前沿模型。这里的关键在于：通过追踪哪些查询在哪些模型上能够成功执行，模型选择这一过程本身可以随着时间的推移不断学习优化。

聊天界面究竟何时才适用？

并非每个任务都需要聊天机器人。一位观众直接挑战了这个前提：「我不确定自然语言总是优于图形界面。如果我要叫 Uber，我不想对着手机说话。我只想点、点、点，车就来了。」

的确，不是所有任务都适合自然语言交互。

专家小组的共识是：当对话能降低学习门槛时，它才具备实用价值。

对于商业智能（BI）仪表盘、数据分析这类传统上需要专业知识才能操作的复杂工具，自然语言能降低使用门槛。但一旦用户获得所需答案，通常更倾向于使用图形用户界面控件 —— 比如将饼图切换为柱状图，根本无需额外输入文字。

混合模式的核心逻辑是：

• 以聊天功能开启零学习门槛的初始操作
• 提供图形用户界面（GUI）控件用于后续的精准调整与反复优化
• 允许用户根据具体任务需求和个人使用偏好选择交互模式

一位与会者列举了自然语言处理的两个理想应用场景：

• 偶发且带有情绪属性的任务，例如客户服务场景 —— 用户此时可能心怀不满，只想倾诉诉求或获取帮助，而非在层层菜单中艰难导航；
• 探索性、开放式的查询任务，例如「帮我找一处加州附近的爱彼迎房源，要前排位置，能看到海景和蓝天」这类需求复杂且包含上下文信息的场景。

核心洞见在于：我们应当理解人们使用自然语言交互的深层原因，并围绕这一核心意图进行设计，而非将所有交互都强行套入聊天模式。

仍存在的缺口

会上提出了几个尚未得到充分探索的方向，这些都是亟待产品化的核心基础能力：

1、上下文可观测性

哪些输入能持续优化输出效果？哪些类型的上下文会导致模型产生幻觉？如何像测试模型提示词那样测试上下文？目前，大多数团队都在盲目摸索 —— 他们缺乏系统的方法来衡量哪些上下文对模型性能真正有帮助，哪些反而会产生负面影响。

2、可组合记忆

记忆能否归属于用户（而非应用程序），实现可移植性与安全性？同时设置可选的权限层级，以区分组织、团队和个人层面的记忆状态？

这一设计能解决两个核心问题：

• 用户无需在每个新工具中重新构建自己的上下文信息
• 隐私与安全性由用户自主掌控，而非受服务商锁定

这是当前技术栈中最关键的缺失的基础能力。

3、领域感知型 DSL

企业用户的需求大多具备结构化和重复性特征。既然如此，我们为何仍执着于将自然语言解析为稳定性极差的结构化查询语言（SQL），而非定义更高级、受约束且安全的领域特定语言（DSL）呢？

有团队提出，与其开发文本到结构化查询语言（text-to-SQL）的工具，不如构建语义化的业务逻辑层，例如 「展示第四季度营收」这类需求，应当直接映射到经过验证的计算流程，而非生成原始的结构化查询语言（SQL）代码。

4、延迟感知型用户体验（UX）

一位专家组成员提到了一款记忆增强型聊天机器人，它的响应速度虽慢，却能给用户带来惊喜体验。原因在于：它能基于用户上周的提问内容，给出一系列智能的后续跟进内容。

这一设计为异步、主动式人工智能的用户体验开辟了新可能 —— 其应用场景绝非仅限于聊天功能。试想这样的场景：智能体在你开会前准备好简报、在你打开文档时呈现相关上下文信息，或是在你主动询问前就提醒你数据中出现的异常情况。

核心洞见在于：不同任务对延迟的要求存在差异。一个笑话需要即时响应；而深度分析即便耗时 10 秒也无妨，只要能实时展示进度且体现出智能性即可。

值得持续关注的方向

作者表示，参与完这场专家小组讨论后，她更加坚信：一波基础设施工具浪潮即将到来，包括记忆组件、编排层、上下文可观测性工具等。事后看来，这些工具的出现似乎顺理成章，但如今它们仍处于混乱且尚未解决的状态。

生成式人工智能领域下一个真正的竞争壁垒，不会源于模型访问权限，而将来自以下四个方面：

• 上下文质量
• 记忆系统设计
• 编排可靠性
• 信任导向型用户体验（Trust UX）

如果你是一名正在开发基础设施、应用程序或智能体的创业者：你的产品路线图中，有多少内容是明确针对这四个方向展开的？

创业者必看：5 个需直面的硬核问题

如果你正在构建上下文系统或智能体，不妨问问自己这 5 个问题：

1. 我的应用程序的上下文预算是多少？（理想的上下文窗口规模为多大？我又在如何优化其中的内容构成？）
2. 我的记忆系统边界在哪里？（哪些记忆归属于用户层面、团队层面以及组织层面？存储位置在哪？用户能否查看这些记忆内容？）
3. 我能追踪输出的溯源信息吗？（当需要调试大语言模型的响应结果时，我能否明确知晓是哪些输入内容导致了该输出？）
4. 我使用的是单一模型还是多个模型？（我是如何根据任务复杂度、延迟要求或成本预算来分配路由请求的？）
5. 用户会愿意将资金或医疗数据托付给我的系统吗？（如果不愿意，我的安全机制或反馈循环中还缺少哪些关键环节？）

原文链接：https://www.motivenotes.ai/p/what-makes-5-of-ai-agents-actually