2025-10-14 23:03 浙江
探讨了AI Agent在生产环境中成功的关键因素。
Datawhale干货
作者：Oana Olteanu，编译：Datawhale
💡 **高级上下文工程超越提示词技巧，是AI Agent成功的基石。** 真正的上下文工程并非简单的提示词堆砌，而是将上下文视为可版本化、可审计的工件。这包括面向LLM的原生特征工程（如选择性上下文剪枝和上下文验证），以及通过语义层和元数据层进行分层管理，以应对多变的输入格式（如PDF、音频、日志）并确保检索结果的结构化和相关性，而非仅仅是相似内容。
🔒 **安全、溯源和权限管理是AI Agent部署的关键，而非形式。** AI Agent在生产环境中必须严格遵守行级别、基于角色的访问控制，并能追踪输入与输出的对应关系（溯源/谱系）。即使提示词相同，也需为不同用户定制输出，以防止权限泄露和合规问题。信任源于系统一致、可解释、可审计的行为，并强调“human-in-the-loop”的设计模式，将AI定位为辅助而非自主决策者。
🧠 **记忆设计是架构决策，而非简单功能，需平衡用户体验与隐私。** 记忆应被抽象为独立的上下文层和行为层，具备版本控制和可组合性，并区分用户级、团队级和组织级记忆。虽然记忆能提升用户体验和个性化，但过度个性化可能侵犯隐私。理想的解决方案是安全、可跨应用且由用户控制的可移植内存层，目前仍是技术空白。
⚙️ **多模型推理与流程编排是实现高效、自适应AI Agent的关键。** 生产环境中的AI Agent常采用模型编排，根据任务复杂性、延迟约束、成本敏感度和数据合规性等因素智能调度不同模型。这种模式类似编译器设计，通过有向无环图（DAG）执行决策流程，而非简单地将内容发送给单个LLM，以实现流畅、无缝且自适应的用户体验。
💬 **对话式交互价值在于降低用户学习成本，但需与图形界面结合。** 自然语言交互尤其适用于消除BI工具等复杂工具的学习门槛，进行探索性查询。然而，当用户需要精细化操作时，图形界面更为高效。理想的混合模式是，以聊天界面作为易于上手的起点，并提供图形界面支持后续操作，让用户能自由选择最合适的交互方式。
2025-10-14 23:03 浙江
探讨了AI Agent在生产环境中成功的关键因素。
Datawhale干货
作者：Oana Olteanu，编译：Datawhale
近日，在旧金山硅谷内部的一个行业交流活动中，硅谷知名风险投资人 Oana Olteanu 与来自Uber、WisdomAI、EvenUp 和 Datastrato 的工程师和机器学习负责人们，探讨了 AI Agent 在生产环境中成功的关键因素。
他们提到，95% 的 AI Agent 部署在生产环境中会失败。原因并非模型不够智能，而是因为其周围的支撑体系——如上下文工程、安全性、记忆设计——尚未到位。
原文链接：https://www.motivenotes.ai/p/what-makes-5-of-ai-agents-actually
大多数创始人以为自己在打造 AI 产品，但实际上他们真正在构建的是上下文选择系统。
这场专题讨论深入剖析了隐藏在 Agent 表象之下的复杂核心：上下文选取、语义层、记忆编排、治理机制以及多模型的路由策略。
本文是 Oana 基于研讨会内容的深度整理，由Datawhale进行编译。
上下文工程 ≠ 提示词技巧
在讨论会中，多位嘉宾都表达了相同的一个观点：其实模型微调一般通常用不上。只要把检索增强生成（RAG）做得到位，就足够用了。但目前大多数 RAG 系统设计都还太过简单，做得不够成熟。
常见的失败的模式：
对所有内容一股脑地索引，导致检索结果过多，从而让模型无法判断重点并产生混淆
索引过多 → 检索到过多信息 → 混淆模型
索引过少 → 模型缺乏有效信号
混合结构化和非结构化数据 → 破坏嵌入或简化关键架构
那么，真正的高级上下文工程到底是什么样的呢？
一位嘉宾将上下文工程重新定义为面向 LLM 的原生特征工程：
选择性上下文剪枝 = 特征选择
上下文验证 = 模式/类型/时效性 检查
“上下文可观测性” = 跟踪哪些输入提高/降低了输出质量
带元数据的嵌入增强 = 类型化特征 + 条件
这种框架很重要。这意味着我们可以将上下文视为一个可版本化、可审计、可测试的工件，而不仅仅是一串字符串。
多个团队提到了采用双层架构：
语义层 → 经典向量搜索
元数据层 → 根据文档类型、时间戳、访问权限或垂直领域本体进行过滤控制
这一混合层有助于对杂乱的输入格式（如 PDF、音频、日志、指标）进行标准化处理，确保你检索到的不仅是“相似内容”，而是相关的结构化知识。可以理解为：在嵌入向量基础上构建的分类体系、实体链接以及特定领域的模式。
这种混合架构能够统一处理各种杂乱的输入格式（如 PDF、音频、日志、指标等），确保检索结果不仅仅是“相似内容”，而是真正相关的结构化知识。比如那些基于嵌入向量构建的分类体系、实体关联以及特定领域的数据模式。
c) Text-to-SQL 的现实挑战
当主持人向观众提问：“你们当中有谁开发过文本转 SQL 系统并已将其投入实际应用？” 没有人举手。
这不是因为问题太小众，而是因为理解查询本来就极为困难。自然语言充满歧义，商业术语又高度依赖具体领域，如果没有经过充分的上下文工程， LLM 根本无法了解某一企业对“收入”或“活跃用户”的具体定义。
那些成功的团队不会简单地把 SQL 结构丢给模型，而是会主动构建一套体系：
业务词汇表及术语对应关系
具有约束条件的查询模板
能够在执行前捕获语义错误的验证机制
能够随时间推移不断优化理解能力的反馈循环
安全、溯源和权限管理一次又一次被提及，它们不是作为走形式的核对项，而是阻碍部署的关键因素。
“如果两个员工问同一个问题，模型的输出应该不同，因为他们的权限不同。”
“当 AI 触及到与你的安全、你的钱等非常敏感的领域时，你会信任它吗？我认为这是当前最大的障碍之一。我们确实有时候会使用 AI Agent，但最终还是会要考虑：我真的能信任这个 AI 吗？”
这不仅仅适用于消费产品。对于在营收确认、病历或合规报告等方面做出决策的企业级 AI Agent，存在同样的信任障碍。对于信任问题来说，原始的技术能力并不重要，关键在于系统能否一直做出一致、可解释、可审计的行为。
那些 5% 在生产环境中真正可用的 AI Agent 都有一个共同点：以“human-in-the-loop”的方式设计。它们把 AI 定位为助理，而不是自主的决策者。整个系统能通过人为纠正形成反馈回路并不断学习，同时让人类能够方便地核查并更改 AI 的决定。
每个人都希望给 AI“加上记忆功能”，但记忆并非简单的功能，而是一项关乎用户体验、隐私和系统设计的决策。
用户级：个人偏好（如图表类型、样式和写作风格）
团队级：常见查询、数据看板和运维手册
组织级：机构知识、规章制度以及过往决策
大多数初创企业会将记忆功能直接硬编码在应用程序逻辑或本地存储中。而顶尖团队则会把它抽象成独立的上下文层和行为层，具备版本控制和可组合性。
一位嘉宾将这种做法形容为：
语义记忆+分类体系+操作指南=上下文
个人偏好=记忆
在应用程序层面，记忆主要有两个作用：
根据用户的个人偏好、写作风格、常用格式及专业领域知识来定制化行为
基于事件和元数据提供主动协助，而不仅限于只是被动的聊天回应
有一个团队分享了他们在 Uber 开发对话式商业智能工具时面临的冷启动问题：用户往往不知道该问什么。
他们的解决方法是，利用用户过往的查询记录建立记忆，并据此主动推荐相关问题作为对话的开场。
但这样的问题在于：个性化的帮助在什么时候会越过界限，变成一种令人不适的监控？
一位与会者提到，他曾让 ChatGPT 推荐一些适合全家观看的电影，结果对方却根据他孩子的名字——克莱尔和布兰登——给出了个性化建议。他随即表示：“我不喜欢这样的回答，你怎么会这么了解我的儿子和女儿？不要侵犯我的隐私。”
这里缺失了一个关键的基础要素：一种安全、可跨应用使用、由用户控制的便携式内存层。它不会被服务的提供商锁定。目前还没有人成功实现这一点。一位讨论嘉宾提到，如果他没做现在的创业项目，他就会选择这个方向作为下一个创业目标。
另一种新兴的设计模式：模型编排。
在实际生产环境中，并不是所有任务都直接调用 GPT-4。越来越多团队开始依据以下因素，来实现对于模型的智能调度：
任务的复杂程度
延迟约束
成本敏感度
数据本地化及监管合规问题
查询类型（例如，摘要生成、语义搜索或结构化问答）
一个示例模式：
对于简单查询 → 由本地模型处理（无需网络请求）
对于结构化查询 → 调用 DSL 或 SQL 翻译器
对于复杂分析 → 调用 OpenAI / Anthropic / Gemini
回退或验证机制 → 采用双模型冗余设计（判别模型+响应模型）
这种模式更像是编译器设计，而不是传统的网页应用路由。你所做的不应该仅仅是“将内容发送给 LLM”，而是在多个异构模型、工具和验证环节之间执行一系列有向无环图（DAG）式的决策流程。
如果你的系统随着使用的增长而变慢或成本上升，首先应该优化的就是这一层。如果你希望 AI 给用户带来流畅无缝的体验，路由机制就不能很脆弱或长期依赖人工调优，而应采用自适应策略。
有一个团队分享了他们的做法：简单问题由小型且快速的模型处理，而复杂的推理任务则交由先进的大模型完成。其核心理念是：通过持续追踪不同模型对各类查询的处理效果，模型的选择过程本身也可以随着时间不断学习和优化。
一种理想的混合模式：
将聊天界面作为起点，让用户能轻松上手，无需学习成本
提供图形界面的控制功能，支持后续的精细化调整与迭代
让用户能够根据具体任务和个人偏好，自由选择合适的模式
一位嘉宾提到了自然语言处理（NLP）的两个理想应用场景：
处理偶发的、情绪化的任务，比如客户服务。例如用户感到沮丧时，只想倾诉或寻求帮助，而不是去费力地浏览层层菜单。
进行探索性的、开放式的查询，比如“帮我找一家靠近加州、第一排、能看到海景和蓝天的 Airbnb”，这类需求往往较为复杂且高度依赖具体情境
关键在于：应该去理解用户使用自然语言的真正意图，并据此进行设计，而非一味地将所有交互都强加于聊天界面之中。
在讨论中提到了一些还没有被深入挖掘的方向，但其实它们是真正有待产品化的核心组件：
哪些输入能够持续提升输出质量？什么样的上下文容易引发模型幻觉？你该如何像测试模型提示词那样来测试上下文？
目前，大多数团队都处于盲目前行的状态，缺乏系统性的方法来评估哪些上下文真正提升了模型性能，哪些反而造成了负面影响。
记忆是否可以随用户携带（而非依附于应用），具备安全性和可移植性，并支持用户按需选择组织、团队或个人状态的层级？
这将解决两个问题：
用户不需要在每个新工具中重新建立上下文
隐私和安全由用户掌控，而不是被服务提供商限制
这是整个技术栈中最关键的缺失环节。
大多数企业用户的需求都是结构化且重复的。与其费力地将自然语言解析成容易出错的 SQL，为何不直接设计更高层次、具备约束安全性且更可靠的专用语言（DSL）呢？
有团队建议，不应该局限于文本转 SQL，而是应该构建一个语义化的企业业务逻辑层，例如“显示第四季度收入”直接对应到一个经过验证的计算方法，而不是直接生成原始 SQL。
一位讨论嘉宾提到，他们开发的带记忆增强功能的聊天机器人，虽然响应速度较慢，但体验却令人欣喜。原因在于，机器人会根据用户上周的提问，智能地生成一系列后续回应。
这为异步、主动式 AI 如何提升用户体验提供了新思路，不仅限于聊天场景。想象一下：Agent 在你开会前自动生成好简报，在你打开文档时动推送相关信息，或是在你尚未察觉时就提前预警数据中的异常。
关键洞见：不同任务对延迟的要求不同。如果是一个笑话任务，需要即时呈现，而如果是一个深度分析任务，即使延迟 10 秒，只要系统能展示它的思考过程并最终给出有效的答案，用户体验就不会差。
参加完这场专题讨论后，我更加确信：我们很快将迎来一波基础设施工具、记忆模块、编排框架以及上下文可观测性技术的发展浪潮。这些技术在将来回顾时，可能会显得顺理成章，但目前仍处于混乱且未被解决的状态。
生成式 AI 领域真正的壁垒，将不在于模型的获取，而在于：
上下文的质量
记忆设计
编排的稳定性
信任的用户体验
如果你是一位致力于开发基础设施、应用或智能体的创业者，不妨想一下：你的产品路线图中有多少内容是围绕上述四项关键问题而设计的？
我的应用程序的上下文容量是多少？（理想的上下文窗口大小是多少？我又该如何优化其中的内容？)
我的记忆边界在哪里？（哪些信息属于用户级、团队级、组织级？这些数据存储在何处，用户是否可以查看？)
我能否追踪输出结果的来源？（我能通过调试 LLM 的回复，知道具体是哪个输入导致了该回复吗？)
我使用的是单一模型还是多模型？（我是如何根据复杂度、延迟还是成本来分配请求的？)
用户会放心把他们的资金或医疗数据交给我的系统管理吗？（如果不会，我的安全性或反馈机制上还缺失什么？)
一起“点赞”三连↓
AI辅助创作，多种专业模板，深度分析，高质量内容生成。从观点提取到深度思考，FishAI为您提供全方位的创作支持。新版本引入自定义参数，让您的创作更加个性化和精准。
鱼阅，AI 时代的下一个智能信息助手，助你摆脱信息焦虑