作者：Oana Olteanu
机器之心编译
这个论坛由 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 个问题：
我的应用程序的上下文预算是多少？（理想的上下文窗口规模为多大？我又在如何优化其中的内容构成？）我的记忆系统边界在哪里？（哪些记忆归属于用户层面、团队层面以及组织层面？存储位置在哪？用户能否查看这些记忆内容？）我能追踪输出的溯源信息吗？（当需要调试大语言模型的响应结果时，我能否明确知晓是哪些输入内容导致了该输出？）我使用的是单一模型还是多个模型？（我是如何根据任务复杂度、延迟要求或成本预算来分配路由请求的？）用户会愿意将资金或医疗数据托付给我的系统吗？（如果不愿意，我的安全机制或反馈循环中还缺少哪些关键环节？）
原文链接：https://www.motivenotes.ai/p/what-makes-5-of-ai-agents-actually
© THE END
转载请联系本公众号获得授权
投稿或寻求报道：liyazhou@jiqizhixin.com
文章原文
