首页 景点排名文章正文

为什么只有 5% 的 AI 智能体在生产环境中真正有效？

景点排名 2025年10月15日 11:26 0 admin

原文 | What Makes 5% of AI Agents Actually Work in Production?

编译 | 段小草 + Gemini 2.5 Pro

超越提示词：来自上下文工程前沿的笔记

为什么只有 5% 的 AI 智能体在生产环境中真正有效？

大多数创始人认为他们在构建 AI 产品，但实际上，他们在构建的是上下文选择系统。

本周一，我在旧金山主持了一场小组讨论，参与者包括来自 Uber、WisdomAI、EvenUp 和 Datastrato 的工程师和机器学习 (ML) 负责人。这场名为 Beyond the Prompt 的活动吸引了超过 600 名注册者，其中大部分是创始人、工程师和早期的 AI 产品构建者。

我们并非为了老调重弹提示词工程 (prompt engineering) 的技巧。

我们探讨了上下文工程 (context engineering)、推理堆栈 (inference stack) 设计，以及在企业环境中扩展智能体系统 (agentic systems) 所需的条件。如果说「prompting」(提示) 只是冰山一角，那么这次小组讨论则深入到了水面之下那块冰冷而复杂的巨大冰体：上下文选择、语义层、记忆编排、治理和多模型路由。

现实情况是： 一位嘉宾提到，95% 的 AI 智能体部署在生产环境中都以失败告终。这并非因为模型不够智能，而是因为围绕模型的支架——上下文工程、安全性、记忆设计——尚未到位。

当晚的一个比喻让我印象深刻：

「基础模型是土壤；上下文是种子。」

一段时间以来，我一直着迷于语义层 (semantic layers)，并非因为它们光鲜亮丽，而是因为创始人正是在这里，悄悄地为大语言模型系统构建信任、实用性和差异化。我见过太多团队将 prompting 与产品混为一谈。这次小组讨论让我感觉到，真正的工程工作开始得到应有的重视。

以下是本次讨论的要点，不仅仅是引述，更是一些我在严肃的 AI 团队中反复看到的模式。如果你正在基础设施 (infra)、工具或垂直 AI 领域进行构建，这些框架正是你需要把握的核心要素。

上下文工程 ≠ 提示词黑客技术

几位嘉宾都表达了同样的见解：微调 (fine-tuning) 很少是必要的。检索增强生成 (Retrieval-augmented generation, RAG) 如果做得好，就已经足够了。但目前大多数 RAG 系统都过于简单。

失败模式：

  • 索引所有内容 → 检索过多 → 使模型困惑
  • 索引过少 → 模型缺乏信号输入
  • 混合结构化和非结构化数据 → 破坏嵌入 (embeddings) 或扁平化关键模式 (schema)

那么，先进的上下文工程究竟是什么样的呢？

为什么只有 5% 的 AI 智能体在生产环境中真正有效？

a) 面向 LLM 的特征选择

一位演讲者将上下文工程重新定义为面向 LLM 的原生特征工程 (feature engineering)：

  • 选择性上下文修剪 = 特征选择
  • 上下文验证 = 模式/类型/时效性检查
  • 「上下文可观测性」 = 追踪哪些输入改善/恶化了输出质量
  • 使用元数据增强嵌入 = 类型化特征 + 条件

这种框架很重要。这意味着你可以将上下文视为一个可版本化、可审计、可测试的工件 (artifact)，而不是一个字符串数据块 (string blob)。

b) 语义层 + 元数据层

一些团队描述了双层架构：

  • 语义层 → 经典的向量搜索
  • 元数据层 → 基于文档类型、时间戳、访问权限或垂直领域的本体强制执行过滤器

这种混合层有助于在混乱的输入格式 (PDF、音频、日志、指标) 之间进行规范化，并确保你不仅仅是在检索「相似内容」，而是在检索相关的结构化知识。可以将其理解为：在嵌入之上构建分类法、实体链接和领域特定的模式。

c) Text-to-SQL 的现实检验

当主持人向观众提问「你们中有多少人构建过 text-to-SQL 并将其投入生产环境？」时，没有一个人举手。

这并非因为问题本身小众，而是因为查询理解极其困难。自然语言是模糊的，商业术语是领域特定的。如果没有广泛的上下文工程，大语言模型根本不知道你公司对「收入」或「活跃用户」的定义。

成功的团队并不仅仅是将 SQL schemas 扔给模型。他们会构建：

  • 业务术语表和术语映射
  • 带约束条件的查询模板
  • 在执行前捕获语义错误的验证层

能够随时间推移改善理解能力的反馈循环。

为什么只有 5% 的 AI 智能体在生产环境中真正有效？

治理与信任并非「仅限企业」的问题

安全性、数据溯源和权限管理被反复提及，它们不是可勾选的待办事项，而是部署的阻碍。

垂直领域的创始人请注意

  • 你必须能追踪是哪些输入导致了哪些输出 (数据溯源)
  • 你必须尊重行级、基于角色的访问控制 (策略门控)
  • 即使提示词相同，你也实现用户特定化的输出

一位演讲者说：

「如果两个员工问同一个问题，模型的输出应该是不同的，因为他们有不同的权限。」

没有这些控制，你的智能体在功能上可能是正确的，但在组织层面却是错误的，可能会泄露访问权限或违反合规性。

这里的主要模式是：为结构化和非结构化数据建立统一的元数据目录，并在索引和查询时嵌入访问策略。

信任问题是人的问题，而非技术问题

一位嘉宾分享了一个个人故事生动诠释了这一挑战：他的妻子不让他使用特斯拉的自动驾驶功能。为什么？不是因为它不能用，而是因为她不信任它。

「当 AI 触及到关于你的安全、你的金钱等非常敏感的领域时，你信任 AI 吗？我认为这是一个巨大的障碍。我们有时会使用 AI 智能体，但最终还是人会去思考：我真的信任这个 AI 吗？」

这不仅仅是消费产品的问题。对于企业级 AI 智能体在收入确认、医疗记录或合规报告等方面做决策时，也存在同样的障碍。信任并非关乎原始能力，而是关乎一致、可解释、可审计的行为。

那 5% 成功的 AI 智能体呢？它们都有一个共同点：人在回路 (human-in-the-loop) 的设计。它们将 AI 定位为助手，而不是自主决策者。它们创建了反馈循环，让系统从修正中学习。它们让人类可以轻松地验证和否决。

记忆不仅是存储，更是一种架构

人人都想「增加记忆」。但记忆不是一个功能，它是一个涉及用户体验 (UX)、隐私和系统影响的设计决策。

记忆的层级：

  • 用户层面：偏好（例如，图表类型、风格、写作语气）
  • 团队层面：重复性查询、仪表板、操作手册
  • 组织层面：机构知识、政策、过往决策
为什么只有 5% 的 AI 智能体在生产环境中真正有效？

大多数初创公司将记忆硬编码到应用逻辑或本地存储中。但最优秀的团队会将其抽象为一个上下文层 + 行为层，使其可版本化和可组合。一位演讲者这样描述：

语义记忆 + 分类法 + 操作手册 = 上下文。 个人偏好 = 记忆

作为个性化手段的记忆

在应用层面，记忆有两个目的：

  1. 根据个体用户、他们的写作风格、偏好格式、领域专长来定制行为
  2. 基于事件和元数据提供主动协助，而不仅仅是被动的聊天响应

一个团队描述了在 Uber 构建对话式商业智能 (BI) 工具的经历。冷启动问题是什么？用户不知道该问什么。解决方案？从他们过去的的查询日志中构建记忆，然后建议相关问题作为对话的开场白，就像记得你上次聊了什么一样。

但这里的矛盾在于：贴心的个性化何时会越界变成令人毛骨悚然的监视？

一位嘉宾描述了他向 ChatGPT 询问家庭电影推荐的经历，结果 ChatGPT 的回应是根据他孩子的名字 Claire 和 Brandon 量身定制的建议。他的反应是？「我不喜欢这个答案。你为什么对我的儿子和女儿了解这么多？不要触碰我的隐私。」

设计上的矛盾：

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

这里缺少一个基础构件：一个安全的、可移植的记忆层，可以跨应用工作，由用户使用，而不是被锁定在提供商内部。还没有人实现这一点。一位嘉宾说，如果他现在没有在做目前的创业项目，这将会是他的下一个。

多模型推理与编排模式

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

在生产环境中，你不会事事都调用 GPT-4。团队越来越倾向于基于以下因素来运行模型路由逻辑：

  • 任务复杂性
  • 延迟约束
  • 成本敏感性
  • 数据局部性/法规问题
  • 查询类型（例如，摘要 vs 语义搜索 vs 结构化问答）

示例模式：

  • 对于简单查询 → 本地模型（无网络调用）
  • 对于结构化查询 → 调用领域特定语言 (DSL) → SQL 转换器
  • 对于复杂分析 → 调用 OpenAI / Anthropic / Gemini
  • 备用或验证 → 双模型冗余（评判者 + 响应者）

这更接近于编译器设计，而非 Web 应用路由。你不仅仅是「发送给 LLM」，而是在一个由异构模型、工具和验证组成的有向无环图 (DAG) 中运行决策。

为何重要：

如果你的系统随着使用量增长而变慢或变贵，这便是第一个需要重新审视的层面。如果你想让 AI 对用户来说感觉无缝，路由就不能是脆弱的或永远靠手动调整的。你需要自适应策略。

一个团队描述了他们的方法：简单问题交给小而快的模型，复杂的推理任务则路由到前沿模型。关键见解是什么？模型选择本身可以通过追踪哪些查询在哪种模型上成功来逐步学习。

为什么只有 5% 的 AI 智能体在生产环境中真正有效？

什么时候聊天才是正确的交互界面？

并非每个任务都需要聊天机器人。

一位观众直接对前提提出了质疑：「我不确定自然语言是否总是优于图形用户界面 (GUI)。如果我要叫一辆 Uber，我不想对着手机说话。我只需要点、点、点，车就来了。」

小组的共识是：当对话能够消除学习曲线时，它才有效。

对于像商业智能 (BI) 仪表板或数据分析这类传统上需要专业知识的复杂工具，自然语言降低了入门门槛。但一旦得到答案，用户通常希望使用 GUI 控件，将饼图切换为条形图不应需要更多输入。

混合模式：

  • 以聊天作为零学习曲线的入口
  • 提供 GUI 控件用于优化和迭代
  • 让用户根据任务和偏好选择模式

一位嘉宾描述了自然语言处理 (NLP) 的两个完美用例：

  1. 零星的、情绪化的任务，比如客户服务，用户感到沮丧，只想发泄或寻求帮助，而不想浏览菜单
  2. 探索性的、开放式查询，比如「帮我在加州找一个第一排、有海景和蓝天的 Airbnb」，这类请求的要求复杂且依赖上下文

关键见解是：我们应该理解为什么想使用自然语言，并为这种意图进行设计，而不是强迫每一次交互都通过聊天完成。

当前缺失的环节（以及开发者的机遇所在）

讨论中出现了几个感觉尚未被充分探索的想法，它们是等待被产品化的真正基础构件：

上下文可观测性

哪些输入能持续改善输出？哪类上下文会导致幻觉？你如何像测试模型提示词一样测试上下文？

目前，大多数团队都在盲目飞行，他们没有系统的方法来衡量哪些上下文对模型性能有帮助，哪些有损害。

可组合的记忆

记忆能否存在于用户端（而非应用端），可移植且安全，并带有可选择加入的组织、团队、个人状态层？

这解决了两个问题：

  1. 用户不必在每个新工具中都重新构建他们的上下文
  2. 隐私和安全由用户控制，而非被供应商锁定

这是技术栈中缺失的最大的基础构件。

领域感知的 DSL

商业用户想要的大部分东西都是结构化和重复性的。为什么我们还在尝试将自然语言解析成脆弱的 SQL，而不是定义更高级别、约束安全的领域特定语言 (DSL)？

一个团队建议，我们不应该做 text-to-SQL，而应该构建语义化的业务逻辑层，「显示第四季度收入」应该映射到一个经过验证的计算，而不是原始的 SQL 生成。

延迟感知的用户体验 (UX)

一位嘉宾描述了一个记忆增强的聊天机器人，它响应缓慢，但却令人愉悦。为什么？因为它根据用户上周问过的内容，展示了一系列智能的后续跟进。

这里为异步、主动的 AI（而不仅仅是聊天）提供了一个用户体验 (UX) 的突破口。想象一下：在你开会前准备简报、在你打开文档时浮现相关上下文、或在你提问前就提醒你数据异常的智能体。

关键见解是：不同的任务有不同的延迟要求。一个笑话应该是即时的。而深度分析如果能显示进度并让人感觉智能，那么花 10 秒钟也是可以接受的。

为什么只有 5% 的 AI 智能体在生产环境中真正有效？

我将关注什么

离开这次小组讨论后，我更加坚信，我们即将看到一波基础设施工具、记忆套件、编排层、上下文可观测性的浪潮，这些在事后看来会是显而易见的。但今天，它们仍是一片混乱，尚未解决。

生成式 AI (GenAI) 的下一个真正的护城河不会来自模型访问权限，而是来自：

  • 上下文质量
  • 记忆设计
  • 编排可靠性
  • 信任用户体验 (Trust UX)

如果你是一位正在构建基础设施、应用或智能体的创始人：你的路线图中有多少明确地解决了这四个问题？

创始人：问自己 5 个问题

作为上下文/智能体系统的构建者，请尝试回答这些问题：

1. 我的应用的上下文预算是多少？ (理想的上下文窗口大小是多少，我该如何优化进入其中的内容？)

2. 我的记忆边界在哪里？ (哪些内容属于用户级别 vs 团队级别 vs 组织级别？它存储在哪里，用户能看到吗？)

3. 我能追踪输出的数据来源吗？ (我能否调试一个 LLM 的响应，并知道是哪个输入导致的？)

4. 我使用一个模型还是多个模型？ (我如何根据复杂性、延迟或成本来路由请求？)

5. 我的用户会信任这个系统处理金钱或医疗数据吗？ (如果不会，我的安全性或反馈循环中缺少了什么？)

如果你正在这个层面进行构建，我希望听到你的声音。特别是如果你在所有人都称之为基础设施之前就已经在做了。

如果你是一位技术读者，尤其是在基础设施或 AI/ML 领域的，请告诉我：你是否想要一个更深入的系列，探讨上下文修剪模式、构建双层上下文系统、记忆抽象或设计治理？

或者，你也可以直接回复你目前在「上下文工程」方面最头疼的问题，我很乐意深入探讨。

相关文章

发表评论

长征号 Copyright © 2013-2024 长征号. All Rights Reserved.  sitemap