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之家

引言 在本系列前面的文章中，我们分别介绍了《什么是数据中台》和《为什么数据治理是持续性的？》 也为大家介绍了龙石数据“理采存管用”的数据治理方法论。 不少读者反馈，对“数据仓库”这个词还不太清楚：它和数据中台到底是什么关系？数据中台既然覆盖“理采存管用”，那数据仓库又在其中扮演什么角色？ 在深入探讨“理”（梳理）和“采”（采集）之前，我们可以先把“存”（存储）这个环节讨论一下。 数据中台和数据仓库的区别与联系 数据仓库为什么需要分层 业界常用的分层思路有哪些 龙石数据在实战中总结的分层模型是怎样的 一、数据中台 vs 数据仓库 数据中台：是一个承载“理采存管用”全流程的“工具与管理平台” ，核心是让数据能力可复用、可服务化。 数据仓库：是中台体系中负责 “存”的 “数据地基”。 它们的关系是： 数据经过中台的治理（理）和采集（采）后，存入数据仓库；再通过中台的调度和管理（管），最终以服务形式（用）支撑业务应用。 通俗来讲，数据中台操作数据，负责把数据治好。数据仓库存储数据，负责把数据存好。 二、数据仓库为什么一定要分层？ 数据仓库的命名源于“仓库”的概念，其设计核心在于解决数据管理中的混乱与低效问题。若将原始数据、加工数据及应用数据混杂存储于单一存储层，将导致数据定位困难、管理复杂、查询性能低下。数据仓库分层设计正是为应对这一挑战，通过结构化组织实现数据的高效治理与利用，数据仓库有以下优点： 结构清晰：像“俄罗斯套娃”一样，采用分层架构（如ODS、DWD、DWS、ADS），每层职责单一，将复杂数据流程简化为可管理的模块化处理，复杂问题简单化。 数据复用：沉淀公共指标和宽表，避免“重复造轮子”，极大提升下游开发效率。 任务解耦：复杂任务拆成多个步骤，便于运维和重跑，一层失败不影响全局。 查询加速：空间换时间，通过预处理和汇总，让上层应用（AI用数、BI、大屏）查询更快。 水平扩展：多数数仓基于分布式架构支持弹性扩容，无缝适配数据量增长场景，确保系统在高负载下保持高性能与高可用性。 三、业界主流的分层思路 3.1 经典两大流派 Inmon（自顶向下）： 主张先建企业级数据仓库（EDW），再建数据集市。 Kimball（自底向上） 主张先围绕业务过程建数据集市，再通过一致性维度整合成企业视图。 Inmon（自顶向下）就像先建一个巨型中央仓库，把所有货物标准化后，再分发给各部门小店； 而Kimball（自底向上）则像先为各部门开专业零售店，但使用统一的商品编码和会员体系，让这些店能轻松连锁成一个大超市。 前者强调整合与统一，后者追求速度与实用。现代数据平台通常结合两者思想。 3.2 当前共识：五层模型 融合了经典思想，互联网和大厂普遍采用五层结构： ODS（贴源层） 贴源层顾名思义是从源头粘贴数据，同城使用数据集成工具（ETL），将源头业务系统数据进行归集，保持数据的原貌，不做任何修改，隔离源头业务系统，不影响原系统的运行。 DWD（明细层） 当原始业务数据进入ODS层时，会对数据进行标准、治理的检查，将问题数据进行清洗、转换、去重、标准化等动作，实现数据的自优化。 DWS（服务层） DWS服务层，更多地贴近业务场景，在DWD明细层的基础上进行汇总加工和聚合计算，例如将事实表中的聚合度量值和维度表中的数据进行汇总聚合，借助DIM公共维度层的不同维度，计算分析出多维度的业务信息。 ADS（应用层） ADS层为数据产品、报表和分析服务提供可直接使用的数据，支撑业务决策的数据应用和报表分析。 DIM（维度层） DIM贯穿于ODS、DWD、DWS、ADS，确保各层数据计算中维度的一致性和准确性。提供通用的维度属性，常见的维度包括，时间维度：年、季度、月、日、时等；空间维度：物理位置、网络地址等。 五层结构相互独立又协同工作，形成高效的数据处理与分析体系，支持智能化的业务应用。 数据流向：ODS → DWD → DWS → ADS DIM 贯穿所有层次，确保维度一致性 这种架构兼顾高内聚、低耦合的数据仓库建设思路，但对团队建模能力要求较高，不少中小企业在落地时感到吃力。 四、龙石数据的实战分层模型 如果说 3.2 的五层模型是学院派，龙石数据的数仓分层就是实战派。龙石数据中台目前支持多种常见数仓，也对信创数据库（如达梦、人大金仓）做了良好适配。无论底层选Doris、StarRocks还是PostgreSQL，都将分层思想内嵌到平台中，提出一套更实战、易用、低门槛的分层模型： SRC（来源层） → ODS（贴源层） → DW（治理层） → ADS（应用层） → DS（共享层） 4.1 设计思路：让数据好管好用 1. 可行性与易用性 架构不是为了“炫技”，而是为了更快更好地实施和使用。考虑到数据工作未来会引入更多业务人员，以及“中国式速度”的要求，我们的模型必须“开箱即懂”。 2. 强化“理采”与“用”的映射： 将「SRC-来源层」纳入： 明确映射“理采存管用”中的“理”和“采”的起点，方便从源头理解数据。 将「DS-共享层」纳入： 明确映射“用”的出口，让数据提供者和消费者清晰知道“数据成品”在哪。 3. 降低“存”与“管”的门槛： 弱化DW细化分层： 将业界DWD（明细）和DWS（汇总）合并简化为「DW-治理层」。 解耦DIM维度层： 将「DIM-维度」的管理从数仓ETL中剥离，交由龙石中台的“数据标准、数据清洗”模块进行维护。 让实施人员无需精通复杂的Kimball建模，大幅降低数据工作的门槛。 4. 确保规范（前提）： 简化不等于随意。没有规范的敏捷是“灾难”。龙石模型通过中台工具将规范（如标准、质量等）“嵌入”到数据的归集、清洗、共享流程中，确保“简化”后的数据质量。 4.2 龙石五层模型详解 第 0 层：SRC（来源层） 逻辑层，不存实际数据。作用是梳理数据资产，比如“CRM系统-客户表”，这是数据治理的起点。 第 1 层：ODS（贴源层） 物理层，把源系统数据原样同步过来，只做轻微格式处理，不做业务加工。作用是可回溯、解耦业务库压力。 第 2 层：DW（治理层） 核心层，融合了明细和汇总功能。在这里执行数据清洗、标准化、关联和轻度汇总，产出可信、可复用的数据。 第 3 层：ADS（应用层） 面向具体业务场景做深度加工，比如大屏数据、报表数据、算法样本等。DW 层保持稳定，ADS 层灵活响应需求。 第 4 层：DS（共享层） 逻辑层，将 ADS 的数据包装成 API 或数据目录，供业务系统或人员直接调用。使用者无需关心数据存在哪里。 五、龙石数据的实战分层模型 数据中台是平台，数据仓库是地基。分层是为了让数据更清晰、可复用、易治理。 业界有 Inmon、Kimball 等经典思路，也有通用的五层模型，但对实施能力要求高。龙石数据在此基础上，提出更注重实战的五层模型（SRC/ODS/DW/ADS/DS），通过中台工具降低建模门槛，能更快落地“存好、管好、用好”数据的目标。 本文基于小编当前实践经验整理，数据仓库领域发展迅速，数据湖等新概念也不断涌现，但分层管理的核心思路始终未变。龙石数据长期专注于数据管理能力的输出，目前我们正在将多年实战经验整理成书，未来也会在书中更系统地介绍数据仓库相关内容，希望能更好地助力大家的数据治理工作。

一、开篇 上周，业务总监在会议上拍桌子：“为什么销售额是负数？这数据太假了！” 我点开系统日志——他用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大数据

智能体人工智能正在颠覆大数据范式，它要求我们主动将数据引入专门的智能计算平台，而不是反过来。这种转变从根本上改变了我们对数据建模和存储的固有认知，因为低级机器学习（LLM）能够利用远小于传统机器学习的数据集进行上下文学习。因此，现代人工智能不断扩展的上下文窗口和工具调用能力正迅速使许多传统的ETL/ELT流程过时，迫使数据工程师彻底重新思考他们的整个方法。 造成这种混乱的原因是什么？ 造成这种转变的原因之一是人们使用数据的方式正在发生变化。 企业应用和仪表盘由软件工程师和数据科学家构建，旨在满足非技术用户的需求。反过来，业务分析师和最终用户则被动地接收这些内容。应用可能内置了一些交互功能，但这些交互都遵循僵化的、预先设定的工作流程。作为数据工程师，我们的工作是提供此类应用能够使用的数据格式。 从以“构建者”为中心的模式（技术用户创建应用程序）过渡到以“交互者”为中心的模式（非技术用户通过人工智能代理直接与数据交互）。 越来越多的非技术用户直接与数据交互。他们能够根据自身需求编写应用程序和工具。现有的SaaS应用程序不再局限于集成并排聊天界面，而是利用CopilotKit等框架更原生地嵌入自然语言交互。具有前瞻性的开发者并没有简单地重复僵化的工作流程，而是将AI代理嵌入到应用程序中，使代理能够以工具调用的形式访问后端API。 其次，重心正在转移。过去，数据量庞大，因此需要将计算资源部署到数据所在位置，以避免大量数据迁移。然而，如今前沿人工智能模型（LLM）才是重心所在，人工智能应用也围绕它们构建。 重心发生了转移，因此技术架构也随之翻转。与以往需要定制计算资源处理数据不同，智能体人工智能应用使用大型语言模型（LLM）作为推理引擎，能够理解用户意图、推理任务并调用工具执行操作。这一新应用浪潮旨在将用户意图直接转化为行动。 这两种动态变化如何影响数据工程师的工作？以下五个原则在准备用于人工智能的数据时需要牢记。 1. 重新思考 ETL/ELT：从规范化到上下文 如今，数据工程师投入大量精力进行数据规范化、创建清晰的数据模式并构建转换管道。其目标是使下游分析师和应用程序能够理解数据。 这并不意味着 ETL/ELT 就变得无关紧要，提供数据仍然至关重要。但您可以依靠代理来解释模式、理解关系，并处理各种格式的数据，而无需进行大量的预处理。 然而，仅仅在现有表上添加数据目录和 MCP 服务器，是对智能体技术能力的极大浪费。此外，这样做还会大大增加 AI 智能体的工作难度。为什么呢？ 人工智能代理能够理解上下文中的数据，它们不需要所有数据都预先规范化到僵化的模式中。事实上，随着表数量的增长，如今的代理很难正确解读数据并编写正确的 SQL 语句来连接所有数据。此外，随着数据切片数量的增加，冲突和歧义的概率也会增加。例如，两个表中可能都有“贷款金额”列。在一个表中，它可能代表借款人申请的金额，而在另一个表中，它可能代表贷款人实际发放的本金。数据结构越是经过处理、规范化和分散化，上下文信息就越难传递。 维护数据可用性工作流程，但要质疑每个规范化步骤是否仍然必要。代理人能否在适当的上下文中理解这些数据，而无需进行转换？委托人信息能否从原始条款清单或融资备忘录中摘录一段文字，解释该委托人将分期获得哪些款项，而不是仅仅用一个数字表示？ 避免只向 AI 代理开放非结构化数据的诱惑——虽然很容易对 PDF、电子邮件等进行处理，但组织中真正可操作的数据通常仍然是结构化数据。 2. 优先考虑数据整理而非数据收集 情境式学习使得内容整理比资料收集更为重要。 在大数据时代，目标是收集尽可能多的数据，因为你想在极其庞大的数据集上训练机器学习模型——更多的数据意味着更好的机器学习模型。 然而，人工智能代理的构建基于情境学习，即在提示中提供一两个示例。学习学习模型（LLM）可以有效地模仿这些示例，无论是遵循某种流程（思维链）还是遵循某种格式或风格（少样本学习）。随着情境学习的出现，示例的质量比数量更为重要。 你向代理展示的示例数据会影响它对所有类似数据的理解。你可能会创建一个示例库，并选择哪些示例用于特定类型的用户查询。随着数据管理的重要性日益凸显，作为数据工程师，构建以下工具变得至关重要： •找出最高质量的数据，例如完整、准确且具有代表性的数据样本。 •随着标准的演变，应定期更新这些示例。 •验证精心整理的数据是否确实能作为智能体学习的有效示例。 作为数据工程师，你需要赋能的关键角色之一是数据管理员。你需要支持的存储类型也会发生变化，包括图数据库和向量数据库。 3. 构建面向代理的基础设施：感知与行动 人工智能代理需要支持两种核心能力的基础设施：感知数据和根据数据采取行动。 并非所有数据格式都能被基于语言模型的智能体平等地访问。请考虑智能体解析、理解和提取数据格式含义的难易程度。能够保留语义含义且预处理需求极低的格式可以降低交互阻力。 AI 代理通过调用工具（包括函数、API 和服务）来执行操作，这些工具使它们能够处理数据。您的基础架构需要确保代理能够发现并使用这些工具。这意味着清晰的接口、完善的文档和可靠的执行。 从人工智能代理的角度审核您的数据访问模式和工具。一个自主系统需要了解哪些信息才能有效使用它们？哪些环节存在阻碍，导致运行不畅？ 4. 将代理工件作为一级数据进行管理 人工智能代理不仅会消耗数据，还会生成数据。事实上，你会发现，人工智能生成的内容将远远超过系统中“原始”数据的数量。 当智能体生成输出、做出决策、编写代码或记录其推理过程时，这些也变成了数据。 无论内容是由人工创建、从软件系统收集，还是由人工智能代理生成，都必须符合您所在行业的通用规范和法规。除了合规性之外，这些代理生成的数据对于调试、审计、训练未来的代理以及理解系统行为也具有价值。 对代理程序生成的数据应与其他数据一样严格对待： •存储代理输出系统 •保留决策日志和推理痕迹 •将代理生成的代码作为版本化工件进行管理 •确保这些数据可供分析和未来培训使用 这些工件将成为您数据生态系统的一部分。请据此设计存储和访问模式。 5. 将观察与训练联系起来 提升智能体性能的最快途径是实现可观测性和训练之间的闭环。人工智能智能体基础设施需要双向管道，将模型性能和可观测性与持续训练联系起来。 首先，你需要一个可观测性平台，它能够追踪数据质量指标，尤其重要的是，能够检测数据漂移（输入数据特征的变化）和概念漂移（输入和输出之间关系的变化）。同时，它还必须监控关键的模型性能指标，例如准确率、延迟和幻觉率。建立与预定义阈值关联的自动触发器。 您的可观测性平台也需要扩展，以纳入人工反馈。用户对生成内容所做的每一次修改都需要记录下来，并用于改进人工智能模型。 其次，你需要一个重训练流程，该流程会在收到监控系统触发的事件时自动激活。它必须完全自动化，负责提取最新版本的训练数据，启动模型重训练或微调任务，并对新训练的模型进行全面的评估和回归测试。在智能体时代，构建这种将性能监控直接连接到自动化部署的闭环系统，对于机器学习/数据工程师来说至关重要，两者之间的界限将日益模糊。 数据工程师的角色如何变化 这五大转变都围绕着一个共同的主题：从僵化、预设的工作流程转向灵活、情境感知的架构。现代代理的工具调用和反射能力使得僵化的 ETL/ELT 流水线不再那么重要。情境学习使得范例精选比详尽的范例收集更有价值。 数据工程的重要性并没有降低，而是发生了变化。过去十年构建数据基础设施的技能依然宝贵，但需要应用于不同的目标。我们不再需要预先设计每个工作流程，而是要创建一种环境，让代理能够自行设计工作流程。 来源（公众号）：数据驱动智能

本文将详细介绍五种重要的数据格式： •CSV •JSON •Parquet •Avro •ORC 在大数据时代，数据源之间的数据迁移和存储需要更具策略性的方法。如果没有优化的决策，通过 ETL 流程处理 TB 级数据可能会耗费大量时间和成本。本地部署系统虽然相对容易发现问题，但其基础设施不会自动适应新的情况，问题必须手动解决。 然而，在云端，资源可以自动扩展。虽然我们可能认为一切运行顺畅，但一些被忽略的小步骤却可能导致数万元的不必要成本。在我看来，根据项目需求选择合适的数据格式是大数据时代最关键的决策之一。 存储在 S3 中的物联网数据应该采用 CSV 格式还是 Parquet 格式？每周销售报告文件的最佳格式是什么？大小文件是否应该使用相同的格式？只有充分了解每种数据格式的特性，才能有效地做出这些决策。 近年来，某些格式——尤其是 Parquet 和 Avro——越来越受欢迎。尽管它们存在一些缺点，但它们的灵活性，尤其是在云环境中，极大地促进了它们的应用。在本文中，我将解释这些格式的特性、优势和劣势，并讨论哪种格式最适合特定场景。 一 CSV CSV是一种基于文本的表格数据格式，其中每一行代表一条记录。记录中的列或字段通常用分隔符（最常见的是逗号）分隔。第一行通常包含列名作为标题。CSV 格式被广泛支持，因此成为数据交换的热门选择。 1.编码 CSV 文件通常采用UTF-8编码，这样可以确保字符兼容性并使文件可压缩。 2.优势 •易于阅读： CSV 文件易于阅读和理解。 •通用性强： 几乎所有编程语言和工具都支持它。 •易于使用：可以手动生成、编辑和检查。 •兼容性：与电子表格和临时分析工具兼容。 3.缺点 •我认为，这种格式最大的缺点之一是它不存储元数据，不强制执行模式或数据类型，并且默认情况下将所有数据都视为文本。（例如，当使用其他工具读取 CSV 文件时，包含年龄等数值的列可能会被解释为整数，但这完全是一种解释，可能不正确，需要手动验证。否则，错误在所难免。） •由于其体积庞大且 I/O 速度慢，因此对于大型数据集来说效率低下。与 Parquet 格式相比，根据具体情况，它可能占用大约 10 倍的空间。 •CSV格式不适用于嵌套数据，这是由于CSV格式本身的设计缺陷造成的。例如，在更适合嵌套数据的格式（例如JSON）中，嵌套结构如下所示： { "user" : { "id" : 123 , "name" : "Alice" } , "actions" : [ { "type" : "click" , "time" : "2025-11-05T12:00Z" } ] } 相同的 CSV 数据必须以 JSON 字符串的形式表示在单个单元格中： user_id,user_name,actions 123,Alice,"[{""type"":""click"",""time"":""2025-11-05T12:00Z""}]""[{" "type" ":" "click" "," "time" ":" "2025-11-05T12:00Z" "}]" 这使得阅读、筛选和分析变得更加困难。 4.何时选择 CSV 格式 •适用于对人类可读性要求较高的中小型数据集。 •应用程序、分析师或团队之间轻松共享数据。 •不支持二进制或列式格式的系统或工具。 •快速原型制作或从电子表格（Excel、Google Sheets）导出。 二 JSON 多年来，JSON 一直是最流行的数据格式之一。它可以被视为一种通用语言，使不同的应用程序能够相互理解。其主要目的是促进 Web 服务和应用程序之间的数据交换。在 JSON 出现之前，XML 曾被广泛用于此目的，但它存在诸多缺陷。 XML格式非常冗长，难以阅读，尤其是在处理冗长且嵌套结构的情况下。它占用大量存储空间，解析XML文件会消耗大量的CPU和内存资源，因此不适合处理大数据。此外，XML的兼容性也有限，通常需要专门的库才能解析。 一个简单的 XML 结构示例： <user> <id> 1 </id> <name> Alice </name> <is_active> true </is_active> <address> <city> Berlin </city> <postal_code> 10115 </postal_code> </address> <hobbies> <hobby> music </hobby> <hobby> cycling </hobby> </hobbies> </user> JSON 随后应运而生，它是一种更简洁、更紧凑、人机可读且通用兼容的格式，极大地简化了跨语言数据交换。JSON以文本格式存储键值对数据。它支持嵌套和层级结构，能够自然地表示复杂且深度嵌套的数据。其通用性使其被广泛用于 API 数据传输和配置文件。 一个简单的JSON结构示例： { "id" : 1 , "name" : "Alice" , "is_active" : true , "address" : { "city" : "Berlin" , "postal_code" : "10115" } , "hobbies" : [ "music" , "cycling" ] } 1.编码 UTF-8 通常被使用，因为它既兼容 ASCII，又支持国际字符。由于采用了 UTF-8 编码，JSON 文件可以在不同的平台上无缝共享。 2.优势 •人类可读： JSON 文件是基于文本的，易于人类阅读。 •支持嵌套数据：可以自然地表示复杂和分层的数据结构。 •通用互操作性：几乎所有现代编程语言都支持。 •无模式灵活性：每条记录可以有不同的字段；不需要严格的模式。 •API友好： REST和GraphQL服务的标准格式。 3.缺点 •存储效率低下：每个记录中都重复出现键，这会增加大型数据集的大小。虽然它适用于消息传递，但并不适合大规模存储。 •不强制类型：数字、布尔值或空值均被视为文本；正确的类型由应用程序自行决定。这种缺乏强制的做法可能是一个缺点，尤其是在 ETL 流程中，新数据可能需要持续关注以避免类型错误。 •解析成本：与二进制格式相比，CPU 和 RAM 使用率更高，尤其是对于大文件而言。 •无元数据： JSON 中不包含最小值、最大值或空计数等信息。 •大文件处理：大文件需要流式传输或分块传输；一次性将整个文件加载到内存中是不切实际的。 4.何时选择 JSON •API 数据交换（REST/GraphQL）： JSON 非常适合在不同系统和编程语言之间传输数据。它为 Web 服务、微服务和移动应用程序提供了一种标准、快速且易于解析的格式。 •适用于快速原型设计和共享的中小型数据集：虽然 JSON 不是存储大型数据的最佳选择，但对于中小型数据集来说效果很好。 •人的可读性很重要：与 XML 或二进制格式相比，其基于文本的键值结构使得错误和缺失字段更容易识别和调试。 •嵌套和分层数据： JSON 自然地支持嵌套对象和数组，可以轻松地以清晰有序的方式表示复杂的结构，例如包含地址和订单的用户对象。 三 Parquet Parquet 是当今最流行的数据格式之一，专为Apache Hadoop 生态系统中的大数据分析而设计。它的主要目标是在高效存储大型数据集的同时，优化查询和分析性能。其最重要的特性是列式结构，这显著提升了查询和存储性能。从很多方面来看，Parquet 都可以被视为大数据时代的主流。 Parquet文件的结构 Parquet文件由三个主要层组成： Parquet 文件 •行组： Parquet 文件的一部分（例如，100 万行一组）。 •列块：行组中特定列的数据(e.g., user_id, age, country)。 💡注意：每一列（例如，country）并没有存储在整个文件的单个连续块中，而是作为每个行组中的单独列块存储。 行组允许并行读取和基于行的过滤（谓词下推），从而只读取必要的行块，降低 I/O 成本并提高读取性能。 1.编码 Parquet 格式以二进制列式结构存储数据。虽然 Parquet 中的文本数据可能使用 UTF-8 编码，但其效率并非源于编码本身，而是源于其他特性，我们将在下文讨论这些特性。 2.优势 （1）列式结构 采用列式结构可以显著提高 Parquet 格式的效率。其最大的优势在于，在大型查询中，系统只会读取所需的列，而忽略不必要的列。这不仅提高了I/O 性能，还降低了成本。 对基于行的格式（例如 CSV）和基于列的格式（例如 Parquet）的数据进行查询的方式如下： （2）基于行的查询（CSV） 在 CSV 文件中，所有行都以文本形式存储： 1，爱丽丝，30，美国，100 2，鲍勃，25，美国，200 3，卡罗尔，40，德国，150 4，戴夫，35，德国，300 5，伊芙，28，美国，250 查询： “美国客户总消费额”→ 仅需要列country和spend 因为 CSV 是基于行的，所以会读取和解析所有行，包括id、name、age。 I/O 成本： 5 行 × 5 列（读取整个文件）。 （3）列式查询（Parquet） 在 Parquet 格式中，列存储在单独的块中： 列ID：1、2、3、4、5 ； 列名称：Alice、Bob、Carol 、Dave 、Eve； 列年龄：30、25、40、35、28 ； 列国家/地区： US 、US、DE 、DE、US ； 列消费金额：100、200、150、300、250 •查询： “美国客户总支出”→ 仅读取country和spend列块。 •id、name 和 age 不会从磁盘读取，从而降低了 I/O 和 CPU 开销。 •列式格式结合字典编码、游程编码（RLE）和位打包（bit-packing）可减小文件体积并加速读取。 格式 ｜ 读取的数据 ｜I/O -----｜-------------｜------ CSV（行式）｜所有行 + 所有列｜高 Parquet（列式）｜仅 country 和 spend 的数据块｜低 （4）行组 行分组不仅按列划分数据，还按行划分数据，具体如下： •提高I/O 性能 •减少过多的随机磁盘访问 例如：一个文件有 3 个行组，每个行组有 50 万行： 如果我们只查询 ` idA` 和 ` ageB`，就不会访问 `C` name、country`D` 和 `D`salary中的 450 万行数据，从而节省大量资源。行组也可以并行读取，进一步提升性能。 如果我们需要的数据只在一个行组中，则跳过其他行组，从而节省高达 80-90% 的 I/O。 （5）字典编码 Parquet 的另一个效率提升之处在于字典编码。重复值存储在字典中，并通过索引进行引用，从而减少了高度重复数据的存储空间。 例子： 列：[美国, 美国, 德国,美国,德国, … ] 字典：{ 0 :美国, 1:德国} 编码列： [ 0 , 0 , 1 , 0 , 1 , … ] 如果我们有 10K 行：6K United States+ 4K Germany，我们存储索引而不是完整的字符串，最多可以节省约 90% 的空间。 原始文本（CSV）： 6,000 × 13 = 78,000字节4,000 × 7 = 28,000字节总计：106,000字节≈ 103.5 KB字典编码（Parquet ） 10,000行→ 2个类别→每行1字节（或至少1位）总编码：10,000字节≈ 9.8 KB （6）游程编码（RLE） RLE 对连续重复的值进行数值计数： 列： [ 0 , 0 , 0 , 1 , 1 , 2 , 2 , 2 , 2 ] RLE： [ (0 , 3 ) , (1 , 2 ) , (2 , 4 ) ] # 前三个值为 0 等 •数值使用最少位数。 例如：值为 0-3 的列只需要2 位而不是 32 位。（7）模式强制执行与元数据 Parquet 文件包含有关文件及其数据类型的元数据。 元数据存储模式和数据类型，以便下游消费者可以信任数据类型，而无需重新定义模式或依赖自动检测（自动检测容易出错）。 元数据还包括 Parquet 版本、创建者、写入工具（Spark、Pandas 等）、列最小值/最大值（启用谓词下推）、空值计数和值计数。 3.缺点 Parquet 格式不具备可读性：它是一种二进制格式；直接读取它只会显示原始二进制数据。需要使用专门的工具（例如 PyArrow、Pandas、Spark、DuckDB）来检查或处理数据。 小型数据集的写入开销：元数据、编码信息和字典表会使 Parquet 文件比小型 CSV 文件大得多。例如，一个包含几百行的 CSV 文件可能只有 10 KB，而相同数据的 Parquet 文件则可能需要 100 KB。 兼容性问题：并非所有系统或轻量级工具都直接支持 Parquet 格式，包括： •遗留系统 •基本电子表格或商业智能工具 •小型嵌入式或基于脚本的解决方案 •通常需要中间库（例如 Pandas、PyArrow、Spark）才能读取。 4.何时选择Parquet •大规模分析和大数据查询： Parquet 格式非常适合拥有数百万甚至数十亿行数据的数据集，尤其适用于对查询性能和 I/O 效率要求极高的情况。其列式结构允许仅读取必要的列，从而减少磁盘和内存使用量。 •嵌套或复杂的数据结构： Parquet 支持结构体、数组和映射等复杂数据类型，使其适用于分层或半结构化数据，而这些数据在 CSV 等基于行的格式中会显得很繁琐。 •云存储和成本效益：在云环境中，仅读取所需列可降低 I/O 和计算成本。Parquet 的压缩和编码特性可进一步减少存储占用。 •ETL管道和分析框架： Parquet可与Spark、Hive、Presto和DuckDB等大数据工具无缝集成。当数据将被多个下游分析系统使用时，它堪称完美之选。 •基于列值过滤场景：当查询涉及基于列值进行过滤时（例如，WHERE country = 'US'），Parquet 的行组和元数据允许跳过不相关的数据块，从而大幅提高查询速度。四 Avro Apache Avro 是 Apache Hadoop 生态系统中最古老、最成熟的数据格式之一。它由 Hadoop 的创建者 Doug Cutting 开发。其主要目的是解决数据可移植性和模式定义方面的不足。Avro基于行，与早期格式不同的是，它采用二进制而非文本格式。这使其更高效、更快速、更节省空间。 例如，考虑一个 10 位数： 1234567890 •在 CSV 或 JSON 格式中，每个数字都存储为一个字符（每个数字占用 1 个字节）： '1' → 00110001 '2' → 00110010 ... '0' → 00110000 •总计：10 字节。解析需要将每个字符转换回整数。 •在像 Avro 这样的二进制格式中，该数字以 int32（4 字节）形式存储，节省了约 6 个字节，并且允许直接内存访问而无需解析，从而显著提升了速度。 Avro 也像 Parquet 一样提供模式强制执行，这意味着模式存储在文件元数据中。 1.文件结构 Avro 文件由三个主要部分组成： Avro 文件 •头部：包含描述数据结构的“魔数”和模式定义（JSON 格式）。 •数据块：以压缩二进制形式存储实际数据。数据块支持并行处理；程序可以跳过不需要的数据块以加快访问速度。 •同步标记：充当断点，帮助在文件损坏时恢复数据。 编码 •Avro 以二进制格式存储数据，比 JSON 或 CSV 格式小得多。 •无需进行文本解析，因此CPU 使用率低。 2.优势 •模式演化与类型强制执行 •该模式嵌入在文件中，确保类型安全和向前/向后兼容性。 向后兼容性示例： 旧模式： { "type" : "record" , "name" : "User" , "fields" : [ { "name" : "id" , "type" : "int" } , { "name" : "name" , "type" : "string" } ] } 旧数据（二进制表示，以 JSON 格式显示）： { "id" : 1 , "name" : "Alice" } { "id" : 2 , "name" : "Bob" } 新增模式，添加了字段（is_active）及其默认值true： { "type" : "record" , "name" : "User" , "fields" : [ { "name" : "id" , "type" : "int" } , { "name" : "name" , "type" : "string" } , { "name" : "is_active" , "type" : "boolean" , "default" : true } ] } 使用新模式读取旧文件会产生以下结果： { "id" : 1 , "name" : "Alice" , "is_active" : true } { "id" : 2 , "name" : "Bob" , "is_active" : true } •旧数据不包含新字段，但Avro 会使用默认值填充该字段，从而确保向后兼容性。向前兼容性则以相反的方向实现。 紧凑二进制格式 •比文本格式小得多（大约是 JSON 大小的 10-20%），但比 Parquet 大。 快速序列化和反序列化 •序列化和反序列化数据时 CPU 使用率极低，使其成为Kafka、Flink 和 Spark Streaming 等实时系统的理想选择。 与语言无关 •模式在 JSON 中定义，数据是二进制的 → 可以轻松地在 Python、Java、Go、C++、Scala 等中使用。 非常适合流媒体播放 •基于行的结构意味着每个记录都是独立的，非常适合基于事件的处理（Kafka 主题、消息传递系统）。 3.缺点 人类无法阅读 二进制格式无法直接读取；需要 PyArrow、Avro 工具或 Spark 等工具进行检查。 基于行的结构 SELECT AVG(price)对于分析查询（例如，在大数据集上），列式格式（Parquet/ORC）效率较低。 读取模式所需 没有模式就无法读取数据。模式必须嵌入在文件中或可从外部获取。 压缩技术不如Parquet/ORC先进 行式存储限制了压缩效率；列式格式可以实现更好的存储空间缩减。 4.何时选择 Avro 流式传输和消息传递系统： Kafka、Flink、Pulsar 等，其中事件需要快速序列化。 模式管理和向后兼容性：跨版本自动模式演化。 类型安全：与 JSON 不同，Avro 强制执行数据类型。 适度的存储优化：比文本格式小，但不需要列式压缩。 高频 ETL 和微服务：适用于服务间数据流密集的系统。 五 ORC（优化行列式） ORC 是一种专为 Hadoop 生态系统开发的高性能列式二进制数据格式。它专为分析海量数据而设计，因此具有很高的查询效率和压缩率。它也像 Parquet 一样具有模式强制执行功能。 1.文件结构 ORC 文件包含三个主要部分： Postscript：数据以大块形式存储，每列都是独立的。也就是说，一个条带包含一组行的逐列数据。 Footer：包含所有架构、统计信息和条带位置。 Stripes：提供有关压缩、文件格式版本和页脚长度的信息。 下面我们通过一个例子来更清楚地理解这三个部分； 假设我们有一个客户表； ORC 文件 2.编码方法 ORC 的编码方式与 Parquet 非常相似；我们在此不再赘述。您可以在上面的 Parquet 部分阅读相关内容。不过，我们可以大致讨论三种基本方法； 字典编码：对于重复值，创建一个字典，并存储字典中的索引而不是数据本身。 游程编码（RLE）：连续相同的值用一个值及其重复次数表示。 位打包：对于数值，使用最少的位数，例如，对于 0 到 3 之间的值，只需 2 位就足够了。 3.优势 •高压缩比： ORC 具有很高的压缩比。这主要是因为数据是按列存储的，并且相似的数据是连续存储的。我们在 Parquet 部分已经提到过这一点，并指出这种方法称为游程编码 (Run-Length Encoding)。 •模式强制执行：与 Parquet 格式一样，ORC 也具有模式强制执行机制。我们前面已经讨论过它的重要性。 •快速分析： ORC 与 Parquet 类似，仅在需要时才访问数据，从而显著提升读取性能。更多详细信息，请参阅 Parquet 部分。 4.缺点 ORC的缺点与Parquet的缺点非常相似；简而言之，这些缺点包括： •不可读：由于 ORC 是二进制格式，因此无法浏览或读取。 •基于行的更新很困难：它专为追加或批量分析而设计，而非事务性的行级更新。它更侧重于分析，因此不适合行级更新。这是因为数据以列为单位存储在较大的数据块（条带或行组）中；更改单行需要重写所有相关的列数据块。 •小数据集的元数据开销：对于非常小的表，元数据和条带开销可能会使 ORC 比 CSV 或 Avro 更大。 •工具依赖性：某些轻量级工具或旧系统可能不支持 ORC 原生支持。 5.何时选择 ORC •对大型数据集进行分析查询： ORC 在读取密集型分析工作负载（如 Hive 或 Spark 中的聚合、过滤和连接）中表现出色。 •需要高压缩率：重复性或低基数数据集可受益于 ORC 的列式压缩。 •Hadoop 生态系统集成：与 Hive、Spark、Presto、Impala 或 HDFS/S3 存储配合使用时非常理想。 •谓词下推/更快的过滤： ORC 的条带级元数据可以高效地跳过不必要的数据。 •具有批量追加功能的稳定模式：非常适合追加密集型管道，但不太适合事务性行更新。 6.Parquet 与 ORC区别 这两种文件类型都是二进制、列式存储，并且在许多方面都使用非常相似的方法。然而，它们在某些方面也存在差异。首先，ORC 格式的优化更为激进。因此，在某些情况下，ORC 格式可以获得更好的压缩效果，并且由于其元数据更详细、更全面，因此也能提供更好的读取性能。 我们将在平台上使用的工具也很重要。ORC 主要面向 Hive 和 Hadoop，因此在这里速度可能更快；而 Parquet 在云端和异构系统中表现更佳，具有更强的平台兼容性和通用性。虽然这两种工具通常都适用于批量分析，但使用 ORC 添加少量数据或进行基于行的数据更改效率较低。Parquet 在这方面则更加灵活，可以根据具体情况用于此类操作。让我们简要比较一下这两种工具： 今天，我们介绍了大数据生态系统中的关键数据格式：CSV、JSON、Parquet、Avro 和 ORC。我们分析了它们的主要特性、优势、劣势以及各自最适用的场景，包括存储、性能、模式强制执行、压缩和兼容性等方面的考量。您可以在下方找到总结表。 来源（公众号）：数据驱动智能

2025年中央城市工作会议明确部署“坚持把城市作为有机生命体系统谋划”，为新时代城市发展贯穿系统性思维与生态化理念。在此背景下，国家发展改革委等部门印发《深化智慧城市发展 推进全域数字化转型行动计划》（以下简称《行动计划》），既是对中央城市工作会议精神的精准落地，更是数字中国战略在城市领域的深化拓展。作为城市生命体的“数字血脉”与“神经中枢”，全域数字化转型正重塑城市生长逻辑、治理范式与发展动能，推动现代化人民城市从“写意勾勒”迈向“工笔细描”。深入把握《行动计划》的理论内核与实践路径，需从数字化与城市生命体的共生关系、系统构建的协同生态、蓝图落地的实践突破三个维度，明晰其时代价值与深层逻辑。 一、共生共荣：数字化与城市生命体的本质联结 城市作为人口、产业、资源的聚合载体，绝非冰冷建筑的简单堆砌，而是具备自我调节、动态演化特征的有机生命体。《行动计划》的核心要义，在于以数字化为“血脉”与“神经”，激活城市生命体的感知、协同、进化能力，实现“人-城-境-业”的共生共荣。这种联结并非技术层面的简单叠加，而是对工业化时代城市发展规律的深度重塑。 （一）生命体视角：重构城市数字化本质认知 传统智慧城市建设多聚焦技术应用的单点突破，《行动计划》则将城市视为“有机生命体”，突出数字化转型的“全域性”与“系统性”。这一视角革新，意味着城市数字化不再是“给机器装芯片”，而是为城市生命体构建全域“循环系统”——通过数据要素流动，打通城市“资源代谢、要素配置、安全防控”等核心功能，实现从“物理集聚”到“数字协同”的质变。 正如人体需血液输送养分、神经传递信号，城市生命体的健康运行，同样需要数据作为“养分载体”、数字基础设施作为“传导网络”。《行动计划》提出的“设施联通、数据融通、平台互通、业务贯通”，本质是为城市生命体搭建“四通”循环体系，让数据像血液般渗透到城市治理、产业发展、民生服务的每一个“细胞”，让数字技术像神经般串联起城市运行的每一个“器官”。其中，城市信息模型（CIM）、国土空间信息模型（TIM）、建筑信息模型（BIM）的协同应用，以及实景三维中国数据的开发利用，更是为“四通”循环体系提供了空间维度的技术支撑，推动城市从“平面管理”向“立体治理”升级。 （二）互塑机制：构建人城境业数字协同新范式 城市生命体的核心是“人”，数字化转型的终极目标是让城市更宜居、更韧性、更有温度。《行动计划》通过“数智赋能治理”“数字美好生活”等行动，构建“城育人、人塑城”的互塑机制：一方面，城市通过数字化升级为市民提供更精准的服务（如高效处置“一件事”、高效办成“一件事”）、更安全的环境（如城市生命线监测预警），其中医疗电子处方流转、费用一站结算、诊疗数据共享、社会保障卡居民服务“一卡通”跨省通用等高频民生场景的落地，让服务精准度与便捷性显著提升；另一方面，市民通过数据反馈、场景参与（如民意速办、接诉即办、未诉先办）反向塑造城市生命体的数字化自修复能力，形成“需求-响应-迭代”的良性循环，而基层报表“一数一源”“统采共用”机制的建立，则进一步降低了市民与基层组织的数据填报负担，让参与渠道更畅通。 这种互塑不仅体现在人与城之间，更延伸至“境”与“业”：通过城市数字更新行动，推动基础设施数字化改造，让生态环境（境）治理更精细（如智慧环保监测）；通过数字经济赋能行动，以数据要素价值化实现“以城带产、以产促城”，让产业（业）成为城市生命体的“肌肉组织”，支撑城市持续生长。 （三）进化逻辑：实现城市治理能力质的跃升 城市生命体的核心特征是适应环境变化的进化能力。《行动计划》通过“城市智能中枢建设”“适数化改革”等部署，为城市生命体注入“学习能力”——通过数据沉淀形成的“城市知识图谱”、算法迭代构建的“决策模型”，让城市能够从历史数据中提炼规律、从实时数据中感知异常、从多元数据中预判趋势，实现从“事后处置”到“事前预防”的跨越。 正如超大特大城市率先建设的“智慧高效治理新体系”，本质是为城市生命体安装“智慧大脑”，通过“一网统管”实现对交通拥堵、环境污染、公共安全等“健康指标”的实时监测与动态调节；而“城市运行体征指标体系”的构建，则如同为城市建立“健康体检报告”，让治理者精准把握城市运行状态，推动治理从“经验决策”转向“数据决策”。 二、八网联动：六项行动构筑城市数字生态体系 《行动计划》部署的六项行动（智慧高效治理提升、数字美好生活、数字经济赋能、城市数字更新、数字化转型筑基、适数化改革创新），并非孤立割裂的任务清单，而是以数据流为纽带，构建起“设施网、数据网、业务网、知识网、创意网、产业网、民心网、安全防护网”八网联动的数字生态体系，为城市生命体提供全维度支撑。这一体系的核心，是打破“条块分割”的传统壁垒，实现“网网相连、网网赋能”。 （一）基础支撑网：筑牢城市生命体“骨骼”与“血脉” 城市生命体的正常运行，依赖强健的“骨骼”（基础设施）与畅通的“血脉”（数据流动）。《行动计划》通过“城市数字更新行动”“数字化转型筑基行动”，构建“设施网”与“数据网”协同支撑格局： 设施网以“物联、数联、智联”为目标，整合感知终端、算力网络、通信设施，如同为城市生命体打造“神经网络末梢”，实现对交通流量、管网状态、环境质量等细微变化的实时感知。例如，“城市数字基础设施”的集约建设，避免了“重复开挖”“系统孤岛”，让设施资源像骨骼般形成整体支撑；而低空数据基础设施的适度超前布局、智能化路侧基础设施与云控基础平台的建设，则进一步为低空经济、自动驾驶等新兴场景提供了设施保障，提升车路协同水平。 数据网通过“公共数据一本账”“数据产权制度探索”，推动数据跨部门、跨区域、跨层级流通，如同为城市生命体打通“血液循环系统”。《行动计划》提出的“数据要素价值化实现”，正是让数据从“沉睡资源”变为“流动养分”，通过“数据券、模型券”等创新工具，激活数据在民生服务、产业创新中的价值潜能。 （二）功能协同网：激活城市生命体“肌肉”与“大脑” 如果说基础支撑网是“硬件”，那么“业务网”与“知识网”则是城市生命体的“肌肉”（治理能力）与“大脑”（决策智慧）。《行动计划》通过“智慧高效治理提升行动”与“适数化改革创新行动”，推动治理能力与知识沉淀协同升级： 业务网以“一网统管”“高效处置一件事”为核心，打破部门壁垒，构建“监测预警-事件流转-指挥调度-闭环落实”全链条机制，如同为城市生命体训练“协同肌肉”，让交通管理、应急处置、民生服务等功能形成“联动反应”。例如，“数字化城市综合运行和治理中心”的建设，实现了城市运行、应急管理等系统的“多脑协同”，避免了“各自为战”的治理困境。 知识网依托“城市智能中枢”“模型即服务”生态，沉淀治理经验、产业规律、服务模式为可复用的算法模型，如同为城市生命体构建“记忆与学习系统”。《行动计划》提出的“超大特大城市率先落地一批先进可用、自主可控城市大模型”，正是让城市能够从海量数据中提炼知识，实现治理与服务的“智能迭代”。 （三）发展活力网：培育城市生命体“细胞”与“灵魂” 城市生命体的活力，源于“细胞更新”（产业创新）与“精神共鸣”（民心凝聚）。《行动计划》通过“数字经济赋能行动”“数字美好生活行动”，构建“产业网”“创意网”“民心网”协同发展格局： 产业网以“以城带产、以产促城”为路径，通过“数据创新型产业社区”“城市首试首用体验场”，推动数字技术与实体经济融合，如同为城市生命体培育“活力细胞”。例如“数字产业集群”的发展，既提升了产业竞争力，又为城市创造了就业机会，实现“产城共生”；而数据保险、数据信托等金融服务产品的探索，则进一步丰富了产业网的支撑工具，降低企业数据创新风险。 创意网鼓励“智创品质生活”“数字友好人居环境”，支持市民、企业、社会组织参与数字化场景创新，如同为城市生命体注入“创新基因”。《行动计划》提出的“城市首试首用体验场”，让市民从“被动接受服务”变为“主动参与创造”，催生了智慧养老、社区微治理等个性化场景。 民心网聚焦“高效办成一件事”“民意速办服务”，让市民感受到数字化带来的便利与温度，如同为城市生命体凝聚“精神共识”。智慧社区建设中提出的数字惠民服务生活圈、幸福邻里综合体，让民心在“数据血脉”的流动中更加凝聚；同时，针对老年人、儿童、残障人士等群体的公共空间与数字服务适老化、适幼化、无障碍改造，以及“一老一小”公共服务资源一站式集成，进一步让民心网覆盖更广泛群体，弥合数字鸿沟。 （四）安全防护网：守护城市生命体“免疫系统” 城市生命体的健康成长，离不开“免疫系统”的守护。《行动计划》通过“数字化转型筑基行动”中“筑牢数字化转型安全防线”的部署，构建“安全防护网”，为城市数字生态保驾护航：一方面，强化网络安全、数据安全防护能力，健全政务云网安全保障体系，实现城市数据基础设施的可信接入、安全互联、跨域管控、全栈防护；另一方面，推进数据安全治理，建立数据安全风险防控体系，强化数据分类分级保护与全生命周期安全管理，完善个人信息保护制度，压实政府、企业、社会组织等各类主体的安全责任，确保数据在流动与应用中“安全无虞”，为城市生命体的数字化进化提供稳定环境。 三、落地突破：从蓝图到实景的实践进阶 如果说2024年《关于深化智慧城市发展推进城市全域数字化转型的指导意见》是全域转型的“发令枪”，那么《行动计划》则是具体的“路线图”与“施工图”。推动蓝图落地，需把握目标锚定的阶段性特征、路径创新的关键突破、因地制宜的差异化推进，让城市生命体的数字化成长既见实效、亦具特色。 （一）目标锚定：2027年标杆引领与2035年远景展望的衔接 《行动计划》明确提出“到2027年建成50个以上全域数字化转型城市”，这一目标并非简单的数量指标，而是对城市生命体数字化成熟度的阶段性定义。转型城市的核心标志，在于形成“智慧高效治理、美好生活普惠、数字经济活跃、数字更新有序”的良性生态，具备可复制、可推广的转型经验；同时，超大特大城市需率先建成智慧高效治理新体系，落地一批先进可用、自主可控城市大模型，形成头部引领效应。 从长远看，《行动计划》还明确了“到2035年，涌现一批具有国际竞争力、全球影响力的现代化城市”的远景目标，与2027年阶段性目标形成“短期突破-长期跃升”的完整时间轴。从具体指标看，“高效处置一件事”覆盖城市运行重点事件，意味着城市治理的“响应速度”与“解决效能”大幅提升；“高效办成一件事”覆盖高频民生事项，标志着市民“获得感”的实质性增强；“自主可控城市大模型”落地，体现了城市“智慧大脑”的自主进化能力。这些指标共同构成城市生命体数字化成熟的“体检标准”，指引各地精准发力。 （二）路径创新：制度供给与主体协同的双轮驱动 从蓝图到实景，关键在于突破“制度壁垒”与“协同难题”。《行动计划》通过“适数化改革创新行动”，构建制度与技术双轮驱动的落地路径： 制度创新聚焦“流程再造”与“规则重构”，例如“加快城市运行管理服务平台体系建设，完善城市运行管理工作机制”“跨部门数据合作机制”“线下网格与线上网络联动协同机制”等城市综合治理机制，打破传统治理的“条块分割”，让城市生命体的“协同反应”更顺畅；同时，加快推进数据确权规则、数字权证应用、行政管理与政府采购等制度改革，为数据要素流通扫清制度障碍。“长效运营运维模式”则通过“用户满意度导向的运营预算与评价考核机制”，建立运营运维评价动态反馈和发布机制，强化评价结果运用，确保数字化建设“建得好、用得久、管得优”，避免“重建设轻运营”的短期行为。 主体协同强调“政府引导、市场主导、社会参与”，让多元主体像“细胞协作”一样形成合力。例如，“数据要素价值化”通过“数据即服务”“模型即服务”生态，吸引企业、科研机构参与数据开发，激活全社会创新活力；而“立体化运营体系”（涵盖数据运营、场景运营、设施运营）的建立，则进一步明确政府、企业、社会组织在运营中的权责分工，形成协同闭环。 （三）因地制宜：差异化发展塑造城市数字竞争力 城市生命体的魅力在于其独特性，数字化转型同样不能“千城一面”。《行动计划》鼓励各地立足资源禀赋、发展阶段，分类分级有序推进：超大特大城市可聚焦“智慧高效治理新体系”，利用人才与数据优势，在城市大模型、跨区域协同治理上率先突破；中小城市可侧重“数字基础设施补短板”与“特色场景创新”，例如结合农业优势发展智慧农业、依托文旅资源打造数字文旅场景；资源型城市可强化“数字赋能绿色发展”，通过智慧环保、碳足迹监测等场景，实现生态保护与经济发展的平衡。这种差异化发展，如同自然界中不同物种的“生态位分化”，让每座城市在数字中国的大生态中找准定位，形成“百舸争流、各具特色”的生动局面。 （四）组织保障：多方联动与能力建设的支撑 《行动计划》落地需强化“顶层统筹-基层落实-能力支撑”的全链条保障：在国家层面，由国家发展改革委数据局会同财政部、住房城乡建设部、自然资源部等部门加强工作指导，分类分级有序推进，强化部门协同与上下联动；在地方层面，支持各地建立高层级统筹推进机制，针对重大需求、重大场景、重大改革集中发力；同时，加大对数字化转型技术攻关、重大项目、试点试验的资金支持，强化数字化转型、数据合规、数据服务等专业人才队伍建设，并通过优秀实践与典型案例的提炼推广、深化国际交流合作，为各地提供经验借鉴与能力支撑，确保转型路径不偏、力度不减。 结语：迈向数字文明时代的现代化人民城市新图景 从“数字福州”的探索到“数字重庆”的实践，从“一网通办”的便民到“一网统管”的高效，我国城市数字化转型已走过十余年历程。《行动计划》的出台，标志着这一进程进入“系统重构、质效提升”的新阶段——不再是技术的简单叠加，而是城市生命体的“系统性重塑”；不再是单点的创新突破，而是全域生态的“整体性进化”。站在新的历史起点，推进全域数字化转型，需以系统思维呵护城市生命体的健康成长，以创新精神破解转型中的难点堵点，让数字化真正成为滋养城市、服务人民的“源头活水”，为中国式现代化注入澎湃的城市高质量发展动能。 作者： 中央财经大学政府管理学院城市管理系主任 王伟 来源（公众号）：北京数据