来源（公众号）：大数据AI智能圈 昨天和一个做AI产品的朋友聊天，他说现在做智能体项目时遇到个头疼问题：用户每次都要重新介绍自己的背景，智能体完全记不住之前的对话。 这让我突然意识到一个深层次的问题——我们一直在优化智能体的大脑，但却忽视了一个更根本的问题：它有没有记忆？ 这可能就是当前AI产业最大的认知盲区。 技术演进的隐藏脉络 大多数人以为AI的发展路线是：简单问答 → 复杂推理 → 多模态理解。 但真正推动AI智能体进化的核心驱动力，其实是记忆能力的突破。 为什么这么说？让我们回顾一下智能体发展的三个关键阶段： 第一阶段：检索型智能体（2020-2023） 这类智能体就像图书馆的管理员，你问什么，它去数据库里找什么。 Claude、GPT都属于这个范畴。它们确实很聪明，但有个致命缺陷——每次对话都是孤立的，智能体无法从历史交互中学习。 我见过太多这样的场景：用户花半小时向客服AI解释了自己的业务场景和需求，关掉聊天窗口再开新对话，AI就像什么都没发生过一样。 第二阶段：上下文智能体（2023-2024） 随着长上下文窗口技术的发展，AI开始能"记住"更长的对话内容。 这时候的智能体就像有了一个更好的笔记本，能把对话内容都记下来。 但这种记忆是机械的、线性的。它能回忆起用户说过的话，但无法理解这些信息之间的深层关联。就像一个学生死记硬背了课本，却不会举一反三。 第三阶段：认知型记忆智能体（2024-现在） 这才是真正有意思的地方。新一代智能体开始具备选择性记忆和知识图谱构建能力。它们不仅能记住对话内容，还能理解用户画像、构建实体关系、形成持续学习的认知闭环。 这种智能体已经不再是简单的问答机器，而是具备了真正的"学习能力"。 商业价值的临界点 为什么说AI记忆是下一个风口？ 从商业角度看，它解决了企业AI应用的最大痛点。 个性化服务的规模化难题 过去做个性化AI服务，企业需要为每个用户单独训练模型，成本高得离谱。 AI记忆技术让"一个模型，服务千人千面"成为可能。 我了解到有个做教育AI的公司，通过记忆系统记录每个学生的学习习惯、知识掌握情况、兴趣偏好。系统能为每个学生动态调整教学内容和学习路径，学习效率提升了40%以上。 企业知识资产的激活 很多企业积累了几十年的内部知识，但这些知识分散在各种文档、邮件、会议记录中。传统RAG只能做简单的文档检索，而AI记忆能构建企业专属的知识图谱。 好比员工问"如何处理客户投诉"，AI不仅能找到相关的流程文档，还能基于历史投诉案例、员工经验、上次类似问题的解决方案，给出个性化的处理建议。 智能决策的基础设施 更深层的是，AI记忆为智能决策提供了可能。 传统AI只能基于当前输入给建议，而具备记忆的AI能分析用户行为模式、决策历史、效果反馈，给出更精准的决策支持。 技术实现的三个关键挑战 当然，AI记忆系统的落地并非易事。 在实际项目中，我发现了三个最核心的技术挑战： 第一个挑战：记忆的选择性和可靠性 不是所有信息都值得长期记住。 系统需要智能判断什么信息应该长期保存，什么信息可以遗忘。 有个做法律AI的朋友分享过经验：法律条文需要永久记忆，案例分析需要长期记忆，但客户一时的情绪表达、临时想法就应该快速遗忘。这需要设计复杂的记忆权重和衰减机制。 第二个挑战：隐私和安全的平衡 AI记忆涉及大量用户隐私数据，如何在提供个性化服务和保护隐私之间找到平衡，是个技术伦理问题。 现在比较主流的做法是采用联邦学习和差分隐私技术。 用户的敏感信息在本地处理，只将匿名化的特征上传到中央模型。这样既保护了隐私，又能让系统从整体数据中学习。 第三个挑战：多模态记忆的融合 未来的AI记忆不会只存储文字信息，还会包含图像、声音、视频等多模态数据。 如何让这些不同类型的信息形成统一的知识表征，是个技术难题。 我看到有些前沿团队在研究多模态知识图谱，将视觉、听觉、语言信息统一映射到同一个语义空间中。这可能需要更复杂的神经网络架构和训练方法。 落地实践的冷思考 基于这些认知，我想分享几个关于AI记忆系统落地的建议： 第一，循序渐进很重要 不要试图一次性构建完美的记忆系统。 从简单的对话历史存储开始，逐步增加实体抽取、关系构建、语义推理等功能。 有团队上来就想做完整的知识图谱，结果发现数据质量、计算资源、开发周期都跟不上。反而是那些从简单对话记忆做起的企业，更容易取得实际成果。 第二，关注数据质量 AI记忆系统的效果很大程度上取决于训练数据的质量。 垃圾进，垃圾出，这个道理在AI记忆领域尤其明显。 建议在系统上线前，先对历史数据进行清洗和标注，剔除噪声信息，提高数据的一致性和准确性。 第三，预留足够的计算资源 AI记忆系统对计算资源的需求是动态增长的。 随着用户数量和使用时长的增加，系统的记忆存储和检索压力会呈指数级增长。 架构设计时要考虑水平扩展能力，避免后期出现性能瓶颈。 结语 回到开头的问题：AI记忆为什么会成为下一个技术风口？ 答案很简单：它解决了AI从工具向伙伴转变的核心问题。当AI能够记住我们的偏好、理解我们的需求、积累我们的经验时，它就不再是冷冰冰的程序，而是真正能理解我们、帮助我们的智能伙伴。 这种转变的影响是深远的。它不仅会改变AI产品的形态，更会重塑整个AI产业的商业模式。 未来五年，AI记忆技术很可能成为区分AI工具和AI智能体的关键分水岭。那些能够提供持续学习、个性化服务、智能决策的AI系统，将在激烈的市场竞争中脱颖而出。 而那些仍然停留在问答机器层面的产品，终将被时代抛弃。 AI记忆革命已经开始了，你准备好了吗？

本文重点阐述为什么运营模式（而不仅仅是工具或战略）决定了你将数据转化为业务成果的能力。 要从数据中释放真正的价值，需要的不仅仅是针对你想要创造的价值类型量身定制的稳健战略。它还需要一个围绕产品思维、平台赋能和清晰责任机制而设计的运营模式。随着生成式人工智能迅速改变人们的预期，确保这一模式正确运行的紧迫性比以往任何时候都更高。 大多数首席数据与分析官 (CDAO) 的失败并非源于缺乏愿景，而是源于其运营模式无法实现愿景。你可以设计出最精妙的组织架构图，但如果它无法培养员工的责任感、促进资源复用并建立规模化的信任，那么它就无法产生任何成果。组织架构图并非交付物，而是交付成果。 一 从分散到集中：驾驭混乱与控制 在 eBay，数据之旅始于一种分散的方式。每个团队都拥有自主权，自行招聘分析师并管理数据。起初，这种本地化的授权方式提高了速度并促进了业务协同。但很快，它就导致了混乱和高昂的成本：数据孤岛、重复劳动以及缺乏统一的治理。 为了解决这个问题就转向了集中式模型。一个核心数据团队负责管理共享的财务报告和商业智能 (BI)。这显著提高了数据质量和一致性。公司各团队现在使用统一的数据语言，采用统一的模式和通用的关键绩效指标 (KPI)。 然而，集中化也带来了自身的挑战。中央数据团队与快速变化的业务需求脱节。响应时间滞后，出现瓶颈，并且该模式难以应对不断增长的需求。 二 平衡自主性和控制力：中心辐射型模型 为了寻求平衡转型为中心辐射式架构，将数据团队嵌入到各个业务部门，同时保持集中治理。目标是将集中化的一致性与分散化的敏捷性相结合。 这种模式在一段时间内运作良好。各个领域团队提供量身定制的洞察和快速的反馈机制。中央团队则专注于基础性任务，例如管理共享的关键绩效指标 (KPI) 和商业智能 (BI) 基础设施。然而，我们很快意识到，明确的职责划分至关重要。如果没有明确的职责定义，尤其是在专业数据任务方面，就会出现混乱。在 eBay，通过建立实践社区（例如分析领导委员会和各个领域团队）来缓解这个问题，并确保与业务领导层保持持续的协调一致。 三 联邦模型与数据网格：何时有效，何时无效 最终，探索了一种联邦式模型。业务部门拥有各自领域的数据产品，而中央团队则提供通用的基础设施、目录和治理。这种分散式所有权提高了响应速度，并增强了业务问责制。 然而，联邦制模式并非万能灵药。成功实施需要大量投资： 明确的域名所有权和数据产品责任。 各个领域都需要具备足够的数据技能，否则任何方面的不平衡都可能迅速破坏整个方法。 强有力的管理层支持和企业领导层对公司治理的认可。 Zalando 和 Intuit 等公司之所以能够成功采用这种模式，是因为它们事先解决了这些先决条件。Gartner强调，如果企业不致力于培养数据人才，数据网格战略往往会适得其反。 四 数据网格并非总是最佳解决方案 尽管联邦数据网格备受追捧，并且对某些公司来说也取得了不可否认的成功，但它并不适合所有组织。集中式或中心辐射式模式，如果能与组织的规模和需求相匹配，同样可以非常有效： 集中式模型最适合需要高度控制的小型组织，其复杂程度各不相同。 中心辐射型模式兼顾自主性和控制力，是中大型企业的理想选择。 联邦（数据网格）模型在致力于对数据人才和治理进行大量投资的大型复杂组织中蓬勃发展。 合适的模型取决于您的具体情况和战略目标，而不是最新的行业趋势。 五 无论你采用何种模式，都要将你的数据视为产品 无论你选择何种架构，将数据视为产品都至关重要。数据产品拥有明确的所有权、明确的用户、服务级别协议 (SLA)、接口和反馈机制。它超越了后端支持，成为任务关键型组件。拥有可靠的营销活动绩效模型的营销团队会将数据积极融入到战略规划中。这种方法有助于在营销、销售、产品和运营团队之间实现有效的战略协同。 这种思维转变是“从产出到影响”系列的核心。产品思维能帮助你从创建仪表盘和流程表，转向交付真正影响业务决策的成果。它提供了将原始数据转化为可信赖、可重用、高价值资产所需的结构和思维模式。 产品思维可以而且应该像应用于联邦式架构一样有效地应用于集中式和中心辐射式架构。它将数据转化为连接业务和技术的通用语言。 中央团队：从把关人到赋能者 中央数据团队应该发挥推动作用，而不是成为瓶颈。这包括： 通过拥有非常强大的数据目录的自助服务平台，将基础设施产品化。 将最佳实践直接嵌入工具中，不再仅仅依赖文档。 实施指标和反馈循环，以监控和持续改进这些平台。 您的平台和治理本身应该就是产品，包括使用指标、采用率和清晰的服务水平协议 (SLA)。 六 不要忽视数据素养和高管支持 归根结底，数据战略的成功取决于组织内部的广泛采纳，而这又植根于高层领导倡导的共同愿景。数据素养培训至关重要，它能将战略转化为组织内各个层面的日常决策。 实施有意义的绩效指标，例如洞察时间与经济影响。跟踪平台采用情况和治理一致性。在这些方面表现卓越的组织，会将分析驱动的决策深深融入到其文化和绩效管理中。 七 生成式人工智能：数据运营模式的压力测试 生成式人工智能会迅速暴露出运营模式内部在所有权、数据质量和一致性方面的不足。每种运营模式——无论是集中式、中心辐射式还是联邦式——都面临着不同的压力测试。集中式模式可能难以跟上人工智能实验的步伐。中心辐射式架构存在各领域与中心团队之间目标不一致的风险。联邦式模型只有在治理、数据契约和数据素养都万无一失的情况下才能成功。 那些已经实践了严谨的数据产品管理的组织，必将蓬勃发展。API、数据契约以及明确的AI用例部署路径至关重要。那些不仅衡量仪表盘，还衡量采用率和信任度的组织，将会脱颖而出。 简而言之，并不存在最佳的单一模式——只有最符合您的业务、人才和战略的模型。重点在于问责制、产品思维和赋能。记住：目标不是构建数据网格，而是让您的数据方法适应您的组织并创造切实价值。 来源（公众号）：数据驱动智能

现在整个行业都在谈论AI的下一个风口在哪里。 在我看来，AI数据治理就是最大的机会。 随着监管政策的收紧，那些重视数据治理的AI公司将获得巨大优势。而那些忽视数据治理的公司，随时可能因为数据安全问题被淘汰。

来源（公众号）：大数据AI智能圈 凌晨三点，数据分析师小王被电话吵醒。业务方在电话那头急得跳脚："王哥，咱们核心报表的数据又出问题了！用户数怎么突然少了30%？" 这样的场景，在数据圈里简直不要太常见。小王揉着惺忪的睡眼，打开电脑开始"侦探"工作。先问运营最近有没有活动，再问开发有没有改接口，最后还得翻遍所有ETL脚本找问题。等折腾到天亮，问题终于找到了——某个上游系统的数据接口在前一天晚上悄然发生了变化。 这就是数据团队最真实的写照：我们被数据问题绑架，却对数据本身的来龙去脉一无所知。 其实，这个问题用一个专业术语就能解决：数据血缘。 但恕我直言，市面上99%声称"建立了数据血缘"的企业，其实都是在自欺欺人。 从数据黑盒到透明工厂 记得去年在阿里的一次技术交流会上，某位大厂数据负责人说过一句话：**"没有数据血缘的数据平台，就是一个精心包装的数据黑洞。"** 这句话戳中了很多人的要害。 我们不妨想想，为什么Facebook能在用户数据泄露后迅速定位影响范围？为什么Netflix能在推荐算法出现问题时快速回滚？答案很简单——他们对数据的流转了如指掌。 数据血缘的本质，就是给每个数据都装上GPS定位器。 从它出生的那一刻起，途经哪些加工环节，最终流向何处，每一个环节都被完整记录。这不是技术炫技，而是数据治理的基础设施。 在传统的数据平台里，数据就像是被扔进了洗衣机搅了一夜，出来的时候你根本不知道它经历了什么。而有了数据血缘，数据就像有了一张详细的"旅行日志"，每个处理节点都留下了明确记录。 这样做有什么实际价值？我给你举个真实的案例。 某电商公司在做用户画像时，发现一个奇怪现象：活跃用户数的计算结果在不同报表中差异巨大。经过排查发现，不同团队使用的数据加工逻辑不一致，有的用了近30天的数据，有的只用了7天。如果没有完整的数据血缘，这个问题的定位至少需要一周时间。 这就是数据血缘的第一个核心价值：快速问题定位。 当数据出现问题时，你不用像个无头苍蝇一样到处询问，而是可以直接追溯到问题源头。 第二个价值更加重要：变更影响评估。 好比你要下线一张老旧的底层表。按照传统做法，你只能凭经验猜测会有哪些报表受到影响。而有了完整的数据血缘，你可以清晰地看到这张表被下游哪些任务依赖，影响哪些业务指标。在做决策之前，你就能胸有成竹地评估风险。 从概念到实践的三个关键步骤 当然，光知道数据血缘重要还不够，关键是怎么落地。 经过对多家企业的实际调研，我发现成功建立数据血缘的团队，都遵循了相似的路径。 第一步是自动化采集。 这里有个坑，很多团队一开始就想着大而全，想把所有数据源都纳入血缘管理。结果就是项目越做越重，最后胎死腹中。 正确的做法是从小场景开始，逐步扩展。 可以选择一个核心业务指标，比如"日活跃用户数"，把这条链路上涉及的所有表和任务都纳入血缘管理。验证效果后再逐步扩展到其他指标。 在技术实现上，现在有很多成熟的方案。比如可以基于SQL解析器自动提取字段级血缘，也可以通过大数据平台的作业日志来逆向推导数据流向。关键是选择一种适合你团队技术栈的方式。 第二步是统一存储和可视化。 血缘关系的本质是一个复杂的图结构，用传统的关系型数据库存储显然不合适。建议直接使用图数据库，比如Neo4j或者TigerGraph。节点表示数据表或字段，边表示数据流向，查询起来会非常高效。 第三步，也是最容易被忽视的一步：建立反馈机制。 很多人以为血缘系统建好就完事了，实际上这只是开始。真正的挑战在于如何让这个系统在日常工作中发挥作用，并且持续优化。 我见过最成功的案例，某团队把血缘系统集成到了数据质量监控平台。当数据质量告警时，系统会自动沿血缘链路上溯，帮助快速定位问题根源。同时，如果业务方发现某个血缘关系不准确，可以通过系统直接反馈给数据团队。 这种机制形成了一个正向循环：问题发现→血缘追溯→快速解决→反馈优化，血缘系统的准确性越来越高，团队工作效率也越来越高。 数据血缘背后的管理哲学 说了这么多技术层面的东西，但我觉得数据血缘更深层次的价值在于管理理念的转变。 传统的数据团队更像是一个"数据加工车间"，进来什么数据，出去什么报表，全凭经验和手工操作。而有了完整的数据血缘，数据团队就变成了一个"数据工厂"，每个环节都有明确的标准和流程。 这种转变带来的不仅仅是效率提升，更是思维方式的改变。 以前，当业务方问"这个数据准不准"时，数据团队的回答往往是"应该是准的"，或者"我们每天都有质量检查"。这种回答其实很苍白。 有了数据血缘之后，你可以直接展示数据的完整加工链路，告诉业务方数据从哪里来，经过了哪些验证和清洗，最后如何聚合计算。这种透明度本身就是对数据质量最好的背书。 更重要的是，数据血缘让数据团队从一个"支持部门"转变为一个"价值创造部门"。 以前，数据团队的价值很难衡量——做了很多报表，但业务效果如何，很难说清楚。而有了血缘关系，你可以清晰地看到数据如何驱动业务决策，哪些数据被频繁使用，哪些数据处于"闲置"状态。 基于这些数据，你可以主动向业务方提出建议：哪些数据资产需要加强保护，哪些数据可以适当清理节省成本。 这种从被动支撑到主动价值创造的转变，才是数据血缘真正的魅力所在。 结语 数据血缘不是什么高深莫测的技术概念，它更像是数据团队走向成熟的必经之路。 在这个数据爆炸的时代，我们不缺数据，缺的是对数据的理解和掌控。数据血缘就是帮助我们建立这种掌控感的工具。 当你能够清楚地知道每一滴数据的来龙去脉时，你就拥有了数据治理的话语权，也拥有了推动业务价值创造的能力。 数据血缘不是一个项目，而是一种思维方式的转变。从今天开始，让你的数据变得有"家谱"可查，让你的团队变得有"底"可依。

Zoho首席科学家兼联合创始人Sridhar Vembu近期分享了他对公司人工智能策略、产品集成以及这项技术长期愿景的见解。他在Zoholics India 2025大会上的主题演讲，以务实的视角探讨了人工智能的现状、潜力以及尚存的不足。以下是本次精彩演讲的十大要点： 大规模人工智能代码生成会带来安全和合规风险，因此人工审核必不可少：虽然人工智能可以快速生成大量代码（例如，几分钟内生成 10,000 行），但其工作量远远超出了人工审核的可行性。匆忙将此类代码投入生产环境是危险的，因为它会使组织面临严重的风险：安全漏洞、意外数据泄露和违反监管规定。Zoho 的政策是不部署未经审核的人工智能生成代码，因为合规性和安全运营的最终责任在于公司，而不是人工智能工具。 从数学角度来说，保证代码的质量或安全性是不可能的。人工智能也不例外。即使是最智能的人工智能，也受限于计算机科学的规则，例如停机问题和赖斯定理，无法保证代码完全没有漏洞或安全隐患。这意味着任何关于人工智能编写的软件完美无瑕或“绝对安全”的说法，从根本上来说都是无法实现的。人工智能可以增强人们的信心，但它无法取代严谨的人工测试和持续的监控。 人工智能的生产力提升主要集中在样板代码而非实质性的关键业务逻辑上：人工智能最受关注的部分是其驱动的开发带来的生产力提升（例如，一些公司声称提升了20-30%），而这种提升主要体现在重复性或模板化的任务上，例如用户界面模板设计。在解决复杂的后端业务问题时，人工智能带来的实际性能提升仍然有限，这意味着最有价值、最复杂的工作仍然严重依赖于人类的专业知识，而非自动化。 指望人工智能大规模取代人类从事编程和支持工作是过分夸大且风险极高的：数万亿美元人工智能投资背后的逻辑是，机器将取代相当一部分程序员和支持人员，从而降低成本。然而，如果这种取代真的发生（例如，裁减20-30%的岗位），服务质量和客户满意度的下降将立即显现。Zoho的招聘趋势——不断增加对支持人员的招聘——进一步印证了成熟可靠的人工服务目前还无法被人工智能取代的观点。客户会注意到这种变化，并且通常会反对这种替换。 管理和修改大型复杂代码库仍然是人工智能工具无法解决的一大难题。正如Vembu所说，“恐惧因素”意味着阅读、理解并安全地修改复杂的现有系统是编程界的一条“铁律”，而且随着代码库的增长，难度也会越来越大。这种困难会让程序员犹豫不决（“代码恐惧症”），从而降低他们的工作效率。目前的人工智能解决方案无法解决这些心理和实际障碍；因此，企业应该降低对人工智能变革性影响的预期。 人工智能应该被用作高级研究助手和知识合成器，而不是自主决策者：人工智能的优势在于能够收集、消化和综合来自博客、书籍和各种网络数据的海量公共领域信息，从而为人类决策者提供对某一主题的全面理解。保留人类对人工智能生成的洞见进行筛选、解读和最终决策的责任，才能获得最佳结果。 利用人工智能“自我批判”或其他人工智能输出结果，可以显著提升结果质量： Vembu 推荐采用“苏格拉底式”方法：让人工智能自我审查其建议，寻求其他人工智能的意见（例如，ChatGPT 可以批判 Gemini），或者促进对抗性反馈循环。这种方法能够揭示不一致之处，指出遗漏，并促使人工智能提供细致入微、平衡的答案，使其成为那些需要生成模型提供更深入、更客观结果的用户的强大工具。 由于存在产生幻觉的风险，人工智能生成的内容不适用于监管文件或法律文书：人工智能倾向于捏造引证或编造看似合理但实则错误的信息（即所谓的“人工智能幻觉”），这在法律、财务或合规性要求极高的场合尤为危险。现实中已经出现过相关的法律后果，例如律师因使用包含虚假案例的人工智能生成的法律文书而受到处罚。这表明，对于这些敏感的应用，人工监督至关重要。 目前人工智能在工作场所最有效的应用方式是作为一种增强工具，而非替代工具： Zoho 发现，通过人工智能驱动的建议和快速搜索功能赋能客服人员（以及其他面向客户的员工），能够实现更快、更明智的响应，从而获得最佳效果。这种模式并非要裁员，而是加快问题解决速度，提升客户满意度，因为员工仍然是互动的核心，只是被技术增强而非取代。 “人工智能等于失业”的说法并非全然正确：有时它被用来为裁员辩护，而非反映人工智能的实际能力。经济和技术批评人士经常将人工智能视为裁员的主要原因。然而，Vembu指出，至少在Zoho的经验中，“人工智能取代人工”经常被一些公司用作在市场低迷时期裁员的借口。事实上，强劲的业务增长（正如Zoho所展现的那样）可以推动招聘增加，即便人工智能的应用日益普及，因为技术和团队是共同发展的，而不是相互排斥的。 小结 斯里达尔·文布对人工智能提出了务实而深刻的观点。他承认人工智能作为科研和人类增强工具的巨大潜力，但同时强烈警告不要在关键且责任重大的领域过度自主部署人工智能。他认为，人工智能与传统计算的未来在于二者的协同作用；然而，这项技术飞跃可能会带来深刻的经济变革。 来源（公众号）：数据驱动智能

技术在进步，AI也在进化。 从最初的无记忆模式，到RAG的检索增强，再到CAG的缓存增强，每一步都更加贴近真实的业务需求。

一、先别谈技术，先问一句： 你到底要改变什么场景？ 这几年，我们被各种热词包围：大模型、算力中心、数据要素、元宇宙、低空经济…… 但如果你冷静问一句：“这些东西最后要落在哪个具体场景里？要改变谁、什么、哪一刻？” ——很多项目就开始含糊了。 国务院办公厅这份《加快场景培育和开放，推动新场景大规模应用的实施意见》（国办发〔2025〕37 号），干了一件很重要的事：把“场景”从一个模糊的 PPT 概念，正式抬升为国家级战略资源和改革工具。 文件开头就给场景做了一个非常清晰的定位： 场景是系统性验证新技术、新产品、新业态以及配套基础设施、商业模式、制度政策的具体情境，是连接技术和产业、打通研发和市场的桥梁。 翻成大白话就是： 新技术好不好用，不是专家拍脑袋，而要在真实场景里跑一跑； 场景是技术与产业之间的“过桥费”，不过桥就到不了真正的产业化； 你所有的“智能+、数据+、AI+”，最后都要在某个生产、生活、治理场景里，产生可感可量的变化，否则就是“概念股”。 所以，讨论数字化转型，不能再停留在“我要上什么系统、买什么平台、用什么模型”，而是要回到一句朴素的问题： 你要改造的那个具体场景，到底是什么？ 二、国家在做什么？ ——一张巨大的“场景资源地图” 这份文件其实给出了一个“全国场景资源总目录”，逻辑非常清楚，可以简单概括为三层： 新赛道、新空间的前沿场景 比如： 数字经济场景：元宇宙、虚拟现实、智能算力、各类机器人在办公、消费、娱乐中的应用； 人工智能场景：从科研、工业到民生、治理、国际合作，全链条找“AI 能落地”的点； 全空间无人体系：海陆空一体的无人文旅、政务、物流、卫星服务等； 生物技术场景：生物基材料、生物能源、绿色制备； 清洁能源场景：清洁能源车队、车网互动、虚拟电厂、绿电直供； 海洋开发场景：深海探测、深远海养殖、海洋药物等等。 传统产业转型升级的场景 制造业：智能工厂、零碳园区、工业大模型等； 交通运输：车联网、智能调度、空运转运等； 智慧物流：智慧公路、智慧港航、无人仓、无人配送等； 现代农业：智慧农场、育种数字化、畜牧/渔业全链路数字化。 治理与民生场景 应急管理、矿山安全、智慧水利、施工安全、林草生态保护； 智慧政务、智慧城市、数字乡村； 医疗健康、养老助残托育、数字文旅、跨界消费新场景。 用一个比喻理解： 国家在做一件事：把“场景”像矿藏一样标出来，把“场景资源”从隐形的变成显性的，让技术、资本、人才有地方“落脚”和“开采”。 同时，文件还做了两步“制度升级”： 一是把场景纳入要素与制度改革： 场景不只是工程项目，而是与市场准入、要素配置、金融支持、人才政策一起打包设计，用来催生“新质生产力”。 二是把场景当成制度试验田： 在场景里试点规则、监管方式、标准体系，试出来的再升级成更大范围的制度安排。 所以，“场景”已经不再是一个中性名词，而是真正进入了“资源—要素—制度工具箱”的视野。 三、为什么技术越多，很多数字化项目反而越“虚”？ 回到企业一侧，我们会看到另一种常见画风： 先做一个“宏大的蓝图”：统一平台、数据中台、AI 平台、数字孪生平台…… 然后一通上系统：ERP、CRM、WMS、MES、OA 全上； 再堆一些“智能”：预测模型、推荐引擎、知识图谱、机器人流程自动化； 最后发现： 一线业务觉得“很麻烦，不如 Excel 好用”； 领导觉得“报告更好看了，但业绩没感觉到多大的变化”； 数据团队每天忙着“救火”和“做报表”。 问题出在哪？出在“先有技术、再找场景”这个顺序本身。 如果没有清晰的高价值场景，再多的技术投入，很可能变成一种“数字化农家乐”： 地自己种（自己搞平台、自己采数、自己建模）； 菜自己炒（场景自说自话、不跟外部生态耦合）； 饭自己吃（数据不开放、不流动、不可复用）； 看着热闹，规模上不去，成本降不下来，外部引不进来。 相反，如果你先锁定高价值的、可复制的场景，再去倒推技术、数据、制度，就会形成一种**“数有引力”**的局面： 一个定义清晰、价值明确的好场景，会像“引力井”一样，把技术、数据、人才、资本主动吸附过来，而不是靠 PPT 和文件“拉人头”。 四、什么是一个“好场景”？ ——精益场景 SMART框架 把故事变成工程 那到底什么叫“高价值场景”？ 在精益数据方法论里，一个场景要过“五关”——SMART 原则： S：Specific（具体、独特） 越能一句话说清楚“在哪儿、为谁、改什么”，场景就越具体。 不是“要打造智慧城市”，而是“把某个核心商圈高峰期的拥堵指数降低 20%”； 不是“要做智慧工厂”，而是“将某条生产线单位产品的能耗降低 15%”。 M：Measurable（可度量） 这些指标，既是目标，也是验收标准。 办事时长从 15 天缩到 5 天； 交付准时率从 85% 升到 98%； 事故率下降一半； 一次性办结率提升到 90%。 没有数字，就没有共识。 好场景一定有 2–3 个关键指标，比如： A：Actionable（可执行） 哪些流程要改？ 哪些数据要采？ 哪些系统要改造或新建？ 哪些岗位要调整？ 场景要能拆成可执行的任务： 如果一拆发现什么都是“别人来配合、上面来支持”，说明场景定义还停留在口号层面。 R：Realistic（现实可行） 现有技术成熟吗？ 监管是否允许？ 预算撑不撑得住？ 组织里有没有靠谱的负责人？ 不要“想当然”： 有时候，把目标从“全国推广”收缩到“某一线城市或某个产业园区试点”，反而更现实。 T：Time-bound（有时效） 试点期（比如 6–12 个月）； 评估节点（3 个月一次复盘）； 推广期（2–3 年内复制到多少单位）。 场景不是无限期“试下去”； 通常需要明确： SMART 的本质，就是把“故事”压缩成“工程”： 讲得动人的不算，能拆成任务、能算账、能验收的，才叫高价值场景。 五、用“精益数据场景画布” 把一个好点子磨成好场景 光有 SMART 还是不够，你还需要一块“画板”，把场景相关的信息全都摊开来。 精益数据方法论里有一个非常实用的工具——精益数据场景画布，包含十个关键要素，可以当成一个共创工作坊的模板来用： 业务目标和价值： 这个场景从业务角度要达成什么？ 是降本、增效、提体验、控风险，还是支撑某个政策目标？ 用户画像： 谁是场景里的核心用户？ 是调度员、医生、司机、客服，还是市民、企业用户？ 不同用户在场景中的角色、动机是什么？ 场景背景： 现在是怎么做的？ 有什么外部变化逼得你必须改？政策？竞争？风险事件？ 用户痛点： 一线到底在哪儿喊累、喊烦、喊危险？ 哪些地方是关键的“吐槽高发点”？ 用户期待： 如果这个场景“成功了”，用户希望发生什么变化？ 更简单？更快？更透明？更安全？更可控？ 度量指标： 上文的 M——用 2–3 个指标，把“好不好”说清楚。 挑战与阻力： 是组织壁垒？部门利益？技术短板？数据质量？ 还是法律合规？人才缺口？预算不够？ 解决方案思路： 流程怎么变？ 机制怎么改？ 数据怎么组织？ 系统怎么协同？ 培训和考核怎么设计？ 不是一句“建一个平台”就完事，而是： 数据资产： 场景中有哪些关键数据？ 现在在哪儿？质量怎么样？缺什么？ 哪些数据是本单位就能解决的，哪些需要跨部门、跨行业协同？ 数字技术： 要用到哪些关键技术组件：物联网、大模型、知识图谱、数字孪生、区块链…… 哪些已经有，哪些需要引入新的伙伴？ 一个典型做法是： 把这十个要素印在一张大画布上，让业务、技术、数据、法务、财务、合作伙伴围在一起，从左到右、一项一项写，边写边吵，吵完基本就成了。 这个过程本身，就是“共创”和“筛选”： 写得清楚的场景，会变得越来越扎实、越来越可执行； 写到一半发现答不上来的场景，要么需要重构，要么就先“降级备选”。 六、数据要素的三重角色：底座、连接器、放大器 说到这里，有一个问题绕不过去： 在一个高价值场景里，数据要素到底干什么？ 在“数有引力”的框架里，数据有三个角色——底座、连接器、放大器。 1. 底座：没有数据，场景就是空心的 再完美的流程设计、再聪明的算法、再漂亮的界面，如果没有真实、持续、高质量的数据，最终都只能停留在“演示版”。 比如做虚拟电厂场景： 没有各类用电设备的实时负荷数据，就无法知道谁可以灵活调节； 没有历史负荷曲线，就无法做靠谱的预测； 没有合约执行与结算数据，就无法形成市场信号。 所以，每一个场景画布里，都需要回答一个问题： 这个场景的“必需数据清单”是什么？它们现在在哪里？质量如何？如何补齐？ 当你围绕场景把数据需求描绘清楚，再往上搭建数据治理、标准、目录、接口、平台，才是真正“以数据为底座”。 2. 连接器：数据把多种要素“织”成一个系统 在现实世界里，生产要素是碎片化的： 人在组织里； 钱在预算里； 设备和土地在资产表里； 算力在机房里； 制度在制度文件里。 场景要想真正跑起来，必须让这些东西协同，而数据正是连接它们的“神经系统”。 举两个简化例子： 交能融合场景 车的运行状态和位置信息来自车联网； 充电桩/换电站的状态来自物联网平台； 电网负荷、价格、峰谷时段来自电力系统； 订单、货物时效来自物流平台。 把这些数据打通，你才能做到： 把车引导到更合适的补能点； 在不影响履约的前提下参与削峰填谷； 既保证物流效率，又优化能耗与成本。 低空经济 + 应急救援场景 无人机状态数据； 气象与地形数据； 通信网络状态； 应急指挥系统的任务数据。 只有数据把这些要素连在一起，你才能做到： 实时改飞行路径； 评估风险； 追溯责任。 在精益数据方法论里，这种“连接”会进一步被抽象成： 一组跨系统、跨部门、跨主体的数据流与事件流。 场景里“谁和谁要对话”“谁给谁发什么信号”，最终都要落在数据模型与接口设计上。 3. 放大器：用算法和机制，把场景拉向“智能”与“演化” 当你有了稳定的数据底座和连通的要素网络，就可以叠加“放大器”： 用预测模型让计划更前瞻，比如： 预测拥堵、预测需求、预测设备故障； 用优化算法让资源更高效，比如： 配送路径优化、能量调度优化、人力排班优化； 用数字孪生做“先仿真后落地”，比如： 先在虚拟城市里调一次信号灯，再应用到真实交通系统； 用 A/B 测试和持续迭代，让制度和流程也能“试错”和“升维”。 此时，数据已经不只是“记录发生了什么”，而是在回答： 如果这样做，会发生什么？ 如果换一种做法，会更好吗？ 这就是数据在场景里的第三重作用——让场景从“能用”走向“好用”和“会变聪明”。 七、从“一个好案例”到“一张场景地图” 走出“农家乐心态” 很多地方和企业都有过非常成功的单点案例： 某个车间的效率提升了； 某个窗口的服务体验变好了； 某条线路的能耗下降了。 但如果你把视角拉远，会发现一个常见问题： 案例很好，但复制不了。 要走出“农家乐式的数字化”，需要把思路从“项目清单”升级到“场景地图”： 把所有经过 SMART 和画布校验的高价值场景，拼成一张“场景蓝图” 哪些场景是基础场景（例如统一身份、统一支付、统一设备管理）； 哪些是业务关键场景（例如关键产业链的生产与物流）； 哪些是治理类和民生类场景； 它们之间先后顺序、依赖关系如何。 用场景蓝图倒推三张“配套蓝图” 谁对整个场景组合负责？ 场景之间如何共享成果、分摊成本？ 怎么设计“开放场景”的准入标准和考核方式？ 哪些能力要共建（身份、支付、消息总线、物联网平台、大模型能力平台等）？ 避免每个场景单独建一套系统，造成烟囱。 哪些是场景共用的关键数据资产？ 哪些数据域必须统一标准？ 数据资产蓝图： 数字技术蓝图： 组织与机制蓝图： 把场景“开放出来”，让更多主体参与共建共用 这个场景要达成什么指标； 需要什么数据、什么能力； 有哪些边界和合规要求。 按文件要求：不得用地域、业绩、规模、企业性质等做不合理限制； 用场景公开招募技术方案、数据服务、生态伙伴； 对外说清楚： 这样，场景就不再是个别单位的“自留地”，而是一个可进入、可合作、可扩展的“引力场”。 八、给政府和企业的三条小建议 最后，用三条非常实操的话收个尾。无论你是政府部门、央企国企，还是地方龙头、民营企业，基本都适用： 建议一：先讲“场景故事”，再列“技术清单” 不要一上来就说要建“某某平台”“某某中心”，而是先问： 我要改变的第一个具体场景是什么？ 能否用一句话把场景讲给一线员工听懂？ 用一个个清晰的场景，去牵引技术、数据、制度，而不是反过来。 建议二：用 SMART 和场景画布，把场景做小、做深、做透 不要怕“小切口”，国家文件也明确鼓励“高价值小切口场景”； 从一个场景开始，用 SMART 原则“压实”，再用场景画布把十个要素填完整； 先在一个部门、一条线、一个区域赢一仗，再复制到更多地方。 这比“全域一把梭”要安全、要高效得多。 建议三：把数据当成场景资产去运营，而不是“报表燃料” 为每个重点场景列出“场景数据资产清单”： 关键业务数据、关键设备数据、关键治理数据； 明确谁负责采集、谁负责治理、谁可以使用、怎么计价、如何共享； 把这些场景数据资产逐步沉淀成“公共数据底座”，服务更多场景。 当你这样做的时候，你会发现： 同一类场景之间可以共享经验和数据； 新技术可以更快插到已有场景里试； 新伙伴可以按场景模块加入，而不是“从头谈起”。 九、精益场景咨询服务 让数据的“引力”，从 PPT 走进真实世界 “数有引力”这四个字，背后有两层意思： 一层是：好的数据本身具有引力——谁掌握了高质量数据，谁就更有能力优化决策、重构流程、创新业务； 另一层是：好的场景会创造引力——它让数据不再躺在孤立的系统里，而是在解决真实问题的过程中不断流动、沉淀、放大。 当我们用国家这份场景政策，叠加精益数据方法论的工具箱，把“场景”当成一种可规划、可运营、可复制的战略资源时： 数字化转型就不再是“技术采购项目”，而是围绕场景的系统工程； 数据要素就不再是“副产物”，而是真正成为其他生产要素的底座、连接器和放大器； 无论是一个城市、一条产业链，还是一家公司，都可以在一张张场景画布上，看清自己正在走向怎样的“新质生产力”。 数有引力，场景为场。 真正的数字化转型，终究要从一个个真实的场景开始——从某条路、某家厂、某个窗口、某个社区开始，让技术、数据和制度在具体的时间、具体的空间、具体的人身上，产生可见、可感、可复用的改变。 来源（公众号）：凯哥讲故事系列

LLM负责思考和推理，RAG负责提供准确的信息，AI Agent负责具体的执行。这就像一个完美的工作团队：聪明的头脑、丰富的信息源、强的执行力。

成功部署 AI 智能体（Agentic AI）绝非易事。我们从实践中总结了宝贵经验，告诉你如何把这件事做对。 AI 智能体革命已经开启一年，一个教训也愈发清晰：想把它做好，必须下苦功。 通过 AI 智能体实现企业转型，有望带来前所未有的生产力提升。虽然有些公司已经尝到了甜头，但更多企业却发现，他们的投入迟迟不见回报。在某些情况下，他们甚至不得不“开倒车”——在智能体搞砸的地方，重新把人招回来。 这些磕磕绊绊是任何新技术发展过程中的必经之路，我们在其他技术创新中也见过类似的模式。为了总结早期的经验教训，我们最近深入研究了麦肯锡内部主导的 50 多个 AI 智能体项目，以及市场上的几十个其他案例。我们将分析结果提炼为六条经验，希望能帮助领导者们成功地从 AI 智能体中捕获价值。 1. 重要的不是智能体，而是整体流程 要想用 AI 智能体创造商业价值，就必须改变工作流程。然而，很多公司常常过度关注智能体本身或某个工具。这必然导致一个结果：造出了看起来很酷的智能体，却无法真正改善整体工作流，最终价值寥寥。 那些致力于从根本上 重构整个工作流程 的项目，更有可能取得成功。所谓工作流程，指的是涉及人员、流程和技术的所有环节。 理解智能体如何在每个环节中提供帮助，才是通往价值的正确路径。人类员工依然是工作的核心，但人类员工将拥有新的智能体、工具和自动化系统来辅助他们。 重新设计工作流程的一个重要起点，是梳理现有流程并找出用户的核心痛点。 这一步至关重要，它能帮助我们设计出真正减少重复劳动、让智能体与人类高效协作的系统。这种协作可以通过学习循环和反馈机制实现，形成一个自我强化的闭环。智能体用得越多，就会变得越聪明、越契合业务需求。 以一家另类法律服务提供商为例，该公司正致力于合同审查流程的现代化。他们所处领域的法律推理在不断演变，新的判例法、司法管辖区的细微差异以及政策解读层出不穷，这使得将专业知识固化为代码变得极具挑战。 为了适应这种天然的变化，团队设计的智能体系统可以在工作流程中不断学习。例如，用户在文档编辑器中的每一次修改都会被记录和分类。这为工程师和数据科学家提供了丰富的反馈流，他们可以利用这些反馈来“教导”智能体，调整提示词（prompt）逻辑，并丰富知识库。久而久之，智能体便能将新的专业知识内化。 关注流程而非智能体本身，能让团队在恰当的节点部署最合适的技术。这在重构复杂的多步骤工作流时尤其重要。例如，保险公司通常有庞大的调查流程（如理赔处理和承保），每一步都涉及不同类型的活动和认知任务。公司可以通过周密部署，将基于规则的系统、分析型 AI、生成式 AI 和 AI 智能体等多种技术巧妙地组合起来，并用一个统一的编排框架（如开源的 AutoGen、CrewAI 和 LangGraph）来支撑。在这种模式下，智能体扮演着编排者和整合者的角色，调用各种工具，并将其他系统的输出整合到自己的上下文中。它们就像“胶水”，将整个工作流程粘合在一起，用更少的人工干预，交付真正的成果。 复杂的工作流程应该为每个任务选择最佳工具。 2. 智能体并非万能解药 AI 智能体（AI Agent）功能强大，但并非所有任务都适合用它来解决。很多时候，领导者们没有仔细审视需要完成的工作，也没有思考智能体是否是最佳选择。 为了避免投资浪费或不必要的复杂性，企业领导者可以像组建一支高绩效团队那样来评估智能体的角色。关键问题是：“需要完成的工作是什么？每个潜在的团队成员——或者说智能体——各自有什么天赋，如何协同工作以实现目标？” 许多业务问题完全可以用更简单的自动化方法解决，比如基于规则的自动化、预测性分析或简单的大语言模型（LLM）提示，这些方法通常比开箱即用的智能体更可靠。 在匆忙上马智能体方案之前，领导者应该先评估任务的性质。具体来说，就是要明确：这个流程的标准化程度应该有多高？需要处理多大的变数？哪些部分最适合交给智能体来做？ 从某种程度上说，这些问题很直观。例如，变化少、标准化程度高的工作流程，如投资者开户或监管信息披露，通常受到严格管控，遵循可预测的逻辑。在这种情况下，使用基于非确定性的大语言模型（LLM）的智能体，可能弊大于利，只会增加复杂性和不确定性。 相比之下，变化大、标准化程度低的工作流程，则能从智能体中获益匪-浅。例如，一家金融服务公司部署了智能体来提取复杂的财务信息，大大减少了人工验证的需求，并简化了工作流程。这些任务需要信息聚合、交叉验证和合规性分析——而这些正是智能体大显身手的领域。 最重要的一点是，不要陷入“用或不用智能体”的二元思维。有些智能体擅长完成特定任务，有些能帮助人类更好地工作，而在许多情况下，其他技术可能才是更合适的选择。关键在于，要弄清楚哪种工具或智能体最适合哪项任务，人类如何与它们最有效地协作，以及如何将人、智能体和工具组合起来，以实现最大产出。 3. 别制造“AI垃圾”：重视评估，建立用户信任 在部署 AI 智能体时，团队最常遇到的陷阱之一是：系统在演示（Demo）中看起来惊艳全场，但实际负责这项工作的用户却被它搞得头疼不已。 我们经常听到用户抱怨“AI 垃圾”（AI Slop），即智能体输出的低质量内容。用户很快就会对智能体失去信任，导致采用率极低。自动化带来的任何效率提升，都很容易被信任的丧失和质量的下降所抵消。 这个反复出现的问题给我们带来了一个来之不易的教训：公司应该像培养员工一样，大力投入智能体的开发。 正如一位企业领导者所说：“引入一个智能体，更像是招聘一位新员工，而不是部署一套软件。” 智能体应该有明确的岗位职责，需要“入职培训”，并获得持续的反馈，这样它们才能不断进步，变得更有效率。 开发高效的智能体是一项极具挑战性的工作。它需要利用领域专家的知识来创建评估体系（evals），并将最佳实践以足够精细的粒度固化下来。这种固化过程既是智能体的“培训手册”，也是它的“绩效测试”，确保其表现符合预期。 这些最佳实践可能存在于标准操作流程（SOP）中，也可能只是专家们心照不宣的默会知识。在固化这些实践时，关键是要关注那些区分顶尖员工与普通员工的核心要素。对于销售代表来说，这可能包括他们如何引导对话、处理异议以及匹配客户的沟通风格。 至关重要的是，专家必须持续参与，长期测试智能体的表现。在这个领域，绝不能“上线就完事”。这种对评估的承诺，要求专家们亲手为给定的输入，标注出期望的（甚至不期望的）输出。对于复杂的智能体，这样的标注有时可能需要成千上万条。通过这种方式，团队可以评估智能体的准确率，并进行必要的修正。 一家全球性银行在改造其“了解你的客户”（Know-Your-Customer）和信贷风险分析流程时，就深刻贯彻了这一方法。每当智能体对合规性的建议与人类的判断不符时，团队就会找出逻辑上的差距，优化决策标准，然后重新进行测试。 例如，在某个案例中，智能体最初的分析过于笼统。团队提供了这一反馈，然后开发并部署了额外的智能体，以确保分析的深度能提供恰当粒度的有用见解。他们使用的一种方法是，连续多次追问智能体“为什么”。这种方法确保了智能体的优异表现，也使得人类员工更愿意接受它的输出结果。 4. 盯紧每个环节，而不只是最终结果 当只与少数几个 AI 智能体打交道时，审查它们的工作、发现错误还相对容易。但当公司推广成百上千个智能体时，这项任务就变得极具挑战性。更糟糕的是，许多公司只追踪最终结果。因此，一旦出错——而随着规模化，出错是必然的——就很难准确找出问题到底出在哪里。 智能体的表现应该在工作流的每一步都得到验证。 将监控和评估嵌入到工作流程中，可以让团队及早发现错误，优化逻辑，并持续改进性能，即使在智能体部署后也是如此。 例如，在某个文档审查流程中，一家另类法律服务提供商的产品团队观察到，当系统遇到一批新案件时，准确率突然下降。但由于他们在构建智能体工作流时，内置了可观测性工具来追踪流程的每一步，团队迅速定位了问题所在：某些用户群体提交的数据质量较低，导致了错误的解读和糟糕的下游推荐。 基于这一洞察，团队改进了数据收集实践，向上游相关方提供了文档格式化指南，并调整了系统的解析逻辑。智能体的性能很快就恢复了。 5. 能复用就别重复造轮子 在急于推进 AI 智能体的过程中，公司常常为每个识别出的任务都创建一个独立的智能体。这会导致严重的冗余和浪费，因为许多不同的任务实际上共享着大量相同的动作（例如，数据导入、信息提取、搜索和分析），同一个智能体本可以完成。 决定在构建可复用智能体上投入多少资源（而不是只做一个执行单一任务的智能体），类似于一个经典的 IT 架构问题：公司既要快速构建，又不能锁定那些会限制未来能力的选择。如何找到这种平衡，往往需要大量的判断和分析。 一个好的起点是识别那些重复出现的任务。公司可以开发能够轻松在不同工作流中复用的智能体和智能体组件，并让开发者可以方便地调用它们。这包括开发一套集中的[2]、经过验证的服务（如 LLM 可观测性工具或预先批准的提示词）和资产（如应用模式、可复用代码和培训材料），并确保它们易于查找和使用。将这些能力整合到一个统一的平台至关重要。根据我们的经验，这几乎可以减少 30% 到 50% 的非必要重复工作。 6. 人类依然不可或缺，但角色正在改变 随着 AI 智能体的不断普及，关于人类将扮演何种角色的问题引发了广泛焦虑——一方面是对工作保障的担忧，另一方面是对生产力提升的过高期望。这导致了关于人类在当今许多工作岗位中角色的巨大分歧。 需要明确的是：智能体将能完成大量工作，但人类仍将是劳动力中不可或缺的一部分 ，尽管智能体和人类所做工作的类型都会随着时间而改变。例如，人类需要监督模型的准确性、确保合规性、运用判断力以及处理边缘案例。正如我们前面讨论的，智能体并非总是最佳答案，因此人类与机器学习（ML）等其他工具的配合仍然是必需的。然而，在某个特定工作流中所需的人员数量，很可能会在经过智能体改造后发生变化，并且通常会减少。企业领导者必须像管理任何变革项目一样，来管理这些转型，并深思熟虑地分配培训和评估智能体所需的工作。 我们经验中的另一大教训是，公司应有意识地重新设计工作，让人员和智能体能够良好协作。 如果缺乏这种关注，即使最先进的智能体项目也可能面临“静默失败”、错误累积和用户抵制。 以前面提到的那家另类法律服务提供商为例，他们希望在法律分析工作流中使用智能体。在设计流程时，团队花时间确定了在何处、何时以及如何整合人类的输入。例如，智能体能够以极高的准确率整理核心索赔项和金额，但考虑到这些信息对整个案件的核心重要性，律师必须进行复核和批准。 同样，智能体能够为案件推荐工作方案，但考虑到决策的重要性，人类不仅要审查，还要调整建议。智能体还被编程来高亮显示边缘案例和异常情况，帮助律师形成更全面的看法。而在流程的最后，仍然需要有人用自己的执照和资历来签署文件，为法律决定承担责任。 这种人机协作设计的一个重要部分，是开发简洁的可视化用户界面，让人们能轻松地与智能体互动。例如，一家财险公司开发了交互式视觉元素（如边界框、高亮和自动滚动），帮助审查员快速验证 AI 生成的摘要。当人们点击某条见解时，应用程序会直接滚动到正确的页面并高亮显示相应的文本。这种对用户体验的关注节省了时间，减少了反复猜测，并建立了对系统的信心，最终带来了接近 95% 的用户接受度。 AI 智能体的世界正在飞速发展，我们可以预见未来将学到更多。但除非公司在推进智能体项目时，从思想上和实践上都抱持着学习的心态，否则他们很可能会重蹈覆辙，减慢自己的发展步伐。 作者：Lareina Yee, Michael Chui, Roger Roberts 来源（公众号）：CDO之家

一、开篇 上周，业务总监在会议上拍桌子：“为什么销售额是负数？这数据太假了！” 我点开系统日志——他用ChatSQL问：“最近三个月销售额情况。” 系统返回了1000行“销售额”字段，其中70%是负数。 真相是：他连“销售额”这个指标在数据库里叫什么都没搞清。 这场景太常见了。说清楚自己要什么数据的人，永远不用ChatSQL；用ChatSQL的人，往往连自己要什么都说不清。 今天，我就撕开智能问数的遮羞布，告诉大家为什么90%的企业在智能问数上踩了大坑。 二、Text2SQL Text2SQL的致命伤：表元数据≠理解需求 很多厂商吹嘘“自然语言转SQL”，本质是用表元数据拼凑SQL，而不是理解业务逻辑。 ✅ 为什么表元数据是基础？ 数据库表结构（字段名、关联关系）是Text2SQL的“地图” 没有这张地图，AI就像盲人摸象 ❌ 但为什么它失效？ 因为业务人员说的“销售额”，在数据库里可能是： sales_amount（财务系统） revenue（电商系统） order_total（ERP系统） 而AI只能根据表名猜——猜错了，就是负数！ 📌 业内真相：ChatSQL的准确率=表元数据的完整性×用户描述的清晰度 两者缺一，结果必崩。 三、ChatSQL 谁在用ChatSQL？谁在骂ChatSQL？ 用户类型 代表场景 为什么用ChatSQL 结果 专业数据人 “查2023Q4华东区订单量” 他们直接写SQL，效率高 从不碰ChatSQL 模糊需求业务人 “看看最近销售情况” 说不清要什么，只能问 得到一堆错误数据 技术决策者 “让业务自己查数据” 以为ChatSQL能解决一切 误判数据，决策失误 >>延伸：AI + 数仓AI 不会取代数仓，但会增强数仓：•自动化建模、SQL 生成•智能调度优化•自然语言查询（NLQ） 这也是我见过最讽刺的场景： CTO要求“用ChatSQL赋能全员”，结果业务部门每天问：“为什么我的销售额是负数？” 这不是技术问题，是认知问题。 四、语义层，不是ChatSQL的升级版 破局关键：语义层，不是ChatSQL的升级版 很多厂商还在做“NL2SQL”，但真正的破局点在语义层（Semantic Layer）。 为什么语义层是核心？ 传统NL2SQL 语义层方案 依赖物理表结构 抽象业务语义（销售额=收入-退款） 一个指标多个口径 统一指标定义（全公司只用1个“销售额”） 业务变化需重写SQL 业务规则变更，语义层改1处，全链路生效 数据孤岛，口径混乱 跨部门数据一致，无歧义 🌟 语义层的本质：把“业务语言”翻译成“数据语言”的中枢 例如： 业务说“销售额” → 语义层映射到revenue - refunds → 生成精准SQL 这才是智能问数的正确打开方式： 用户问“销售额” → 语义层解析业务含义 → 生成SQL → 返回数据 五、别再盲目上ChatSQL 给企业的血泪建议：别再盲目上ChatSQL ❌ 你正在踩的坑： 以为ChatSQL=自助分析 → 实际是“自助造错” 用宽表+NL2SQL → 业务一变，IT就重排期 把指标库当摆设 → 业务人员依然用“销售额”“订单量”等模糊词 ✅ 我的实战建议： 先建语义层，再上ChatSQL → 用指标平台（如 数势科技SwiftMetrics，Aloudata CAN）定义“销售额”“用户活跃度”等业务指标，统一口径。 让业务人员参与语义定义 → 业务部门自己写“销售额=收入-退款”，比IT猜100次都准。 ChatSQL只做最后一公里 → 业务人员问“Q3销售额”，语义层自动转成SELECT SUM(revenue - refunds) FROM sales WHERE quarter=3。 💡 我的铁律： “没有语义层的ChatSQL，是数据灾难的加速器，不是解决方案。” 六、结语 智能问数的终极目标👇 智能问数不是“让AI替你写SQL”，而是让业务人员真正理解数据。 对专业DE：语义层解放了你的时间，让你专注数仓建设与数据治理，而不是救火。 对业务人员：不再需要问“销售额是什么”，而是直接问“Q3销售额对比Q2如何？” 对企业：从“数据孤岛”走向“数据统一认知”，决策效率提升10倍。 记住： 说清楚需求的人，永远不需要ChatSQL； 用ChatSQL的人，永远说不清需求。 破局的关键，不是让AI更聪明，而是让业务更懂自己。 范老师重申： “我见过太多企业花百万买ChatSQL，结果数据还是错的。 真正的智能问数，是让业务人员先学会‘说清楚’， 而不是让AI去‘猜清楚’。” 来源（公众号）：数据仓库与Python大数据