机器之心编译
「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 系统都太过粗糙。
它们常见的失败模式包括：
那么，「高级的上下文工程」究竟长什么样？
上下文层参考资料：
1、面向 LLM 的特征工程
一位嘉宾提出了一个极具启发的框架：
把上下文工程看作 LLM 的原生特征工程（feature engineering）。
这意味着：上下文不再是「字符串拼接」，而是一个可测试、可版本化、可审计的数据工件。
2、语义层 + 元数据层的双层结构
一些团队分享了他们的「双层架构」实践：
这种设计能在混乱的数据源之间建立秩序（PDF、日志、音频、指标等），确保检索结果不是简单的「相似内容」，而是真正的「相关知识」。
换句话说，它让 AI 能理解语义，也能尊重结构。
3、text-to-SQL 的现实检验
当场上问观众「有谁把 text-to-SQL 做到生产环境里」时，一个举手的都没有。原因不是这个问题小，而是把自然语言稳定、可靠地映射到业务级查询比想象中难得多。自然语言本身模糊、歧义重；企业术语又常常有上下文依赖 ——「营收」「活跃用户」在不同公司、不同团队的定义可能完全不同。
成功的团队不会把数据库 schema 生搬给模型然后指望它猜对。他们做的是工程化的抽象与保护措施，包括：
能够随时间提升理解的反馈循环可参见：
为什么「信任」与「治理」是核心问题
安全、权限、数据溯源这些词，在现场被反复提到。
它们不是合规清单上的「打钩项」，而是 AI 系统落地的关键阻力。
垂直领域创业者要注意做到以下几点：
如果两名员工问了同一个问题，AI 的答案应该不同。因为他们的权限不同、上下文不同。没有这样的访问与策略控制，AI 的答案可能「技术上正确」，但「组织上错误」—— 泄露信息、违反合规。
领先团队的做法是：在结构化与非结构化数据的统一目录（metadata catalog）中，嵌入访问策略，在索引和查询阶段同时生效。
信任问题并非技术瓶颈，而是人性瓶颈。 一位嘉宾讲了一个故事 —— 他太太拒绝让他开自动驾驶。不是因为它不好用，而是因为她不信任。AI 若要处理金钱、医疗、或安全相关决策，必须先赢得这种信任。那些真正成功的 5% 的系统，都有一个共通点：人机协同（human-in-the-loop）。AI 被设计为助手，而非决策者；能被监督、能被纠正、能被解释。
记忆，不是功能，而是系统结构
每个团队都说想给 AI 加记忆。但真正懂系统的人知道 —— 记忆不是一个 feature，而是一个涉及用户体验、隐私和系统影响的设计决策。
记忆有三个层面：
大多数初创公司将记忆硬编码到应用逻辑或本地存储中，但顶尖团队会将记忆抽象为一个「上下文层 + 行为层」的组合，可版本化、可复用。
他们的定义是：
记忆即个性化
在应用层面，记忆服务于两个目的：
有团队分享了在 Uber 构建对话式 BI 工具的经验。冷启动问题是什么？用户不知道该问什么。解决方案是从用户的历史查询日志中构建记忆，然后推荐相关问题作为对话起点 —— 就像一个记得你上次聊天内容的人。
但问题在于：有用的个性化何时会越界成为令人不安的监控？
一位与会者描述，他向 ChatGPT 询问适合全家观看的电影推荐，结果 ChatGPT 给出了针对他孩子 Claire 和 Brandon 的个性化建议。他不喜欢这个答案，说「你为什么对我的儿子和女儿了解得这么清楚？别碰我的隐私」。
在设计时，你需要考虑：
这里缺失一个关键原语：一个安全、可移植的记忆层，可跨应用工作，由用户使用，而非锁定在服务商内部。目前还没人真正解决这个问题。一位与会者说，如果他不做现在的创业项目，这会是他的下一个目标。
多模型推理与编排模式
另一个新兴设计模式是模型编排。
在生产环境中，你不能对所有任务都调用 GPT-4。团队越来越多地基于以下因素运行模型路由逻辑：
以下是一些可能的情况：
这更接近编译器设计而非网页应用路由。你不只是「发送给 LLM」，而是在异构模型、工具和验证之间运行一个决策 DAG（有向无环图）。
为什么这点很重要？如果你的系统随着使用量增长而变得更慢或更贵，这是首先需要重新审视的层面。如果你希望 AI 对用户感觉无缝，路由就不能永远依赖脆弱的手工调优。你需要自适应策略。
有团队分享了他们的方法：简单问题交给小型快速模型，复杂推理任务路由到前沿模型。这里的关键在于：通过追踪哪些查询在哪些模型上能够成功执行，模型选择这一过程本身可以随着时间的推移不断学习优化。
聊天界面究竟何时才适用？
并非每个任务都需要聊天机器人。一位观众直接挑战了这个前提：「我不确定自然语言总是优于图形界面。如果我要叫 Uber，我不想对着手机说话。我只想点、点、点，车就来了。」
的确，不是所有任务都适合自然语言交互。
专家小组的共识是：当对话能降低学习门槛时，它才具备实用价值。
对于商业智能（BI）仪表盘、数据分析这类传统上需要专业知识才能操作的复杂工具，自然语言能降低使用门槛。但一旦用户获得所需答案，通常更倾向于使用图形用户界面控件 —— 比如将饼图切换为柱状图，根本无需额外输入文字。
混合模式的核心逻辑是：
一位与会者列举了自然语言处理的两个理想应用场景：
核心洞见在于：我们应当理解人们使用自然语言交互的深层原因，并围绕这一核心意图进行设计，而非将所有交互都强行套入聊天模式。
仍存在的缺口
会上提出了几个尚未得到充分探索的方向，这些都是亟待产品化的核心基础能力：
1、上下文可观测性
哪些输入能持续优化输出效果？哪些类型的上下文会导致模型产生幻觉？如何像测试模型提示词那样测试上下文？目前，大多数团队都在盲目摸索 —— 他们缺乏系统的方法来衡量哪些上下文对模型性能真正有帮助，哪些反而会产生负面影响。
2、可组合记忆
记忆能否归属于用户（而非应用程序），实现可移植性与安全性？同时设置可选的权限层级，以区分组织、团队和个人层面的记忆状态？
这一设计能解决两个核心问题：
这是当前技术栈中最关键的缺失的基础能力。
3、领域感知型 DSL
企业用户的需求大多具备结构化和重复性特征。既然如此，我们为何仍执着于将自然语言解析为稳定性极差的结构化查询语言（SQL），而非定义更高级、受约束且安全的领域特定语言（DSL）呢？
有团队提出，与其开发文本到结构化查询语言（text-to-SQL）的工具，不如构建语义化的业务逻辑层，例如 「展示第四季度营收」这类需求，应当直接映射到经过验证的计算流程，而非生成原始的结构化查询语言（SQL）代码。
4、延迟感知型用户体验（UX）
一位专家组成员提到了一款记忆增强型聊天机器人，它的响应速度虽慢，却能给用户带来惊喜体验。原因在于：它能基于用户上周的提问内容，给出一系列智能的后续跟进内容。
这一设计为异步、主动式人工智能的用户体验开辟了新可能 —— 其应用场景绝非仅限于聊天功能。试想这样的场景：智能体在你开会前准备好简报、在你打开文档时呈现相关上下文信息，或是在你主动询问前就提醒你数据中出现的异常情况。
核心洞见在于：不同任务对延迟的要求存在差异。一个笑话需要即时响应；而深度分析即便耗时 10 秒也无妨，只要能实时展示进度且体现出智能性即可。
值得持续关注的方向
作者表示，参与完这场专家小组讨论后，她更加坚信：一波基础设施工具浪潮即将到来，包括记忆组件、编排层、上下文可观测性工具等。事后看来，这些工具的出现似乎顺理成章，但如今它们仍处于混乱且尚未解决的状态。
生成式人工智能领域下一个真正的竞争壁垒，不会源于模型访问权限，而将来自以下四个方面：
如果你是一名正在开发基础设施、应用程序或智能体的创业者：你的产品路线图中，有多少内容是明确针对这四个方向展开的？
创业者必看：5 个需直面的硬核问题
如果你正在构建上下文系统或智能体，不妨问问自己这 5 个问题：
我的应用程序的上下文预算是多少？（理想的上下文窗口规模为多大？我又在如何优化其中的内容构成？）我的记忆系统边界在哪里？（哪些记忆归属于用户层面、团队层面以及组织层面？存储位置在哪？用户能否查看这些记忆内容？）我能追踪输出的溯源信息吗？（当需要调试大语言模型的响应结果时，我能否明确知晓是哪些输入内容导致了该输出？）我使用的是单一模型还是多个模型？（我是如何根据任务复杂度、延迟要求或成本预算来分配路由请求的？）用户会愿意将资金或医疗数据托付给我的系统吗？（如果不愿意，我的安全机制或反馈循环中还缺少哪些关键环节？）
原文链接：
还没有评论，来说两句吧...