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大数据

智能体人工智能正在颠覆大数据范式，它要求我们主动将数据引入专门的智能计算平台，而不是反过来。这种转变从根本上改变了我们对数据建模和存储的固有认知，因为低级机器学习（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年阶段性目标形成“短期突破-长期跃升”的完整时间轴。从具体指标看，“高效处置一件事”覆盖城市运行重点事件，意味着城市治理的“响应速度”与“解决效能”大幅提升；“高效办成一件事”覆盖高频民生事项，标志着市民“获得感”的实质性增强；“自主可控城市大模型”落地，体现了城市“智慧大脑”的自主进化能力。这些指标共同构成城市生命体数字化成熟的“体检标准”，指引各地精准发力。 （二）路径创新：制度供给与主体协同的双轮驱动 从蓝图到实景，关键在于突破“制度壁垒”与“协同难题”。《行动计划》通过“适数化改革创新行动”，构建制度与技术双轮驱动的落地路径： 制度创新聚焦“流程再造”与“规则重构”，例如“加快城市运行管理服务平台体系建设，完善城市运行管理工作机制”“跨部门数据合作机制”“线下网格与线上网络联动协同机制”等城市综合治理机制，打破传统治理的“条块分割”，让城市生命体的“协同反应”更顺畅；同时，加快推进数据确权规则、数字权证应用、行政管理与政府采购等制度改革，为数据要素流通扫清制度障碍。“长效运营运维模式”则通过“用户满意度导向的运营预算与评价考核机制”，建立运营运维评价动态反馈和发布机制，强化评价结果运用，确保数字化建设“建得好、用得久、管得优”，避免“重建设轻运营”的短期行为。 主体协同强调“政府引导、市场主导、社会参与”，让多元主体像“细胞协作”一样形成合力。例如，“数据要素价值化”通过“数据即服务”“模型即服务”生态，吸引企业、科研机构参与数据开发，激活全社会创新活力；而“立体化运营体系”（涵盖数据运营、场景运营、设施运营）的建立，则进一步明确政府、企业、社会组织在运营中的权责分工，形成协同闭环。 （三）因地制宜：差异化发展塑造城市数字竞争力 城市生命体的魅力在于其独特性，数字化转型同样不能“千城一面”。《行动计划》鼓励各地立足资源禀赋、发展阶段，分类分级有序推进：超大特大城市可聚焦“智慧高效治理新体系”，利用人才与数据优势，在城市大模型、跨区域协同治理上率先突破；中小城市可侧重“数字基础设施补短板”与“特色场景创新”，例如结合农业优势发展智慧农业、依托文旅资源打造数字文旅场景；资源型城市可强化“数字赋能绿色发展”，通过智慧环保、碳足迹监测等场景，实现生态保护与经济发展的平衡。这种差异化发展，如同自然界中不同物种的“生态位分化”，让每座城市在数字中国的大生态中找准定位，形成“百舸争流、各具特色”的生动局面。 （四）组织保障：多方联动与能力建设的支撑 《行动计划》落地需强化“顶层统筹-基层落实-能力支撑”的全链条保障：在国家层面，由国家发展改革委数据局会同财政部、住房城乡建设部、自然资源部等部门加强工作指导，分类分级有序推进，强化部门协同与上下联动；在地方层面，支持各地建立高层级统筹推进机制，针对重大需求、重大场景、重大改革集中发力；同时，加大对数字化转型技术攻关、重大项目、试点试验的资金支持，强化数字化转型、数据合规、数据服务等专业人才队伍建设，并通过优秀实践与典型案例的提炼推广、深化国际交流合作，为各地提供经验借鉴与能力支撑，确保转型路径不偏、力度不减。 结语：迈向数字文明时代的现代化人民城市新图景 从“数字福州”的探索到“数字重庆”的实践，从“一网通办”的便民到“一网统管”的高效，我国城市数字化转型已走过十余年历程。《行动计划》的出台，标志着这一进程进入“系统重构、质效提升”的新阶段——不再是技术的简单叠加，而是城市生命体的“系统性重塑”；不再是单点的创新突破，而是全域生态的“整体性进化”。站在新的历史起点，推进全域数字化转型，需以系统思维呵护城市生命体的健康成长，以创新精神破解转型中的难点堵点，让数字化真正成为滋养城市、服务人民的“源头活水”，为中国式现代化注入澎湃的城市高质量发展动能。 作者： 中央财经大学政府管理学院城市管理系主任 王伟 来源（公众号）：北京数据

城市是推进数字中国建设的核心载体，更是中国式现代化建设的主战场与动力源。近日，《深化智慧城市发展 推进全域数字化转型行动计划》（以下简称《行动计划》）正式发布，明确了推进城市全域数字化转型的思路与目标，并从六个方面系统规划了扎实推进转型的重点任务与具体举措，为城市数字化转型提供了行动指南。《行动计划》深入贯彻中央城市工作会议精神，深刻把握并主动适应我国城镇化和城市发展的形势变化，以数据赋能城市经济社会发展全局为核心理念，充分发挥数据要素在城市高质量发展中的协同优化、复用增效与融合创新作用，不仅为提升城市治理智能化精细化水平提供了清晰路径，更为满足人民群众美好生活需要注入了动能，为现代化人民城市建设提供了强大支撑。 一、聚焦三大核心领域全维度赋能城市发展 建设现代化人民城市具有深刻的理论内涵与实践意义。“人民城市”彰显了中国特色城市发展的本质属性，“现代化”则涵盖创新、宜居、美丽、韧性、文明、智慧等多元维度，是对城市发展质量与水平的综合性要求。《行动计划》锚定建设现代化人民城市的目标定位，坚持数据驱动、应用导向，聚焦城市智慧高效能治理、高品质生活、高质量发展三大核心领域，致力于全领域、全方位、全过程赋能城市经济社会发展。 一是以数据驱动城市高效能治理。当前我国城市工作重心正发生重大转变，亟需打破“重建设、轻治理”的传统思维与惯性做法，加大治理投入，推动城市向高水平运营、高效能治理转型。《行动计划》紧密结合治理需求，统筹发展与安全，提出实施城市智慧高效治理提升行动，围绕城市运行、安全风险、社会服务与治理等关键领域，明确了构建城市智慧高效治理体系、数智赋能城市应急安全保障、提升民意速办服务效能等重点举措。其中，深化“一网统管”建设，构建城市运行体征指标体系，建立数据赋能、分级协作、闭环落实的智慧高效治理机制；围绕城市风险早期预警、灾前防范、应急处置等关键环节强化数智赋能；在社会治理中深化数字化应用，提升社情民意实时感知与精准服务水平等举措，均有助于将风险防控深度嵌入城市管理系统，助力建设安全可靠的韧性城市，提升城市平急联动协同能力。 二是以数据创造高品质生活。人民群众对美好生活的向往是城市工作的出发点与落脚点，宜居则是践行人民城市理念的基本要求。《行动计划》提出开展数字美好生活行动，着力建设舒适便利的宜居城市。重点聚焦医疗、健康、教育、新就业群体服务管理等重点应用场景，推进智慧公共服务升级；打造数字赋能文旅、体育、数字消费等新型数字生活场景，推动人工智能在消费场景的深度应用，发展智创品质生活；精准识别老年人、儿童、残障人士等群体的服务需求，推动城乡数字基本公共服务均衡化，优化数字友好型人文环境。一系列举措紧扣民生所需、推动精准普惠，充分彰显了城市数字化转型的“温度”，生动诠释了“人民城市为人民”的发展理念。 三是以数据引领高质量发展。建设富有活力的创新城市，精心培育创新生态，在发展新质生产力上持续突破，是我国当前及今后一段时期城市工作的重点任务。《行动计划》立足城市内涵式发展的战略取向，统筹建设与治理关系，提出实施数字经济赋能行动，从发挥城市功能的角度推动经济高质量发展。在依托城市集聚优势、推进数据要素价值化实现“以城带产”的同时，更强调“以产促城”，利用数字技术推动城市功能改造，建设创新型产业社区、商务社区；依托产业园区促进传统产业、新兴产业、未来产业的科技创新成果落地转化；构建城市经济运行协同调度与监测体系，支持有条件的地区开展城市数字经济监测分析，为建设活力之城、机遇之城提供有力支撑。 二、聚焦存量提质增效推进城市数字更新 城市全域数字化转型需置于我国城镇化和城市发展的历史方位中审视。从我国新型工业化、城镇化进程来看，尽管城镇化仍有较大空间与潜力，但增速已整体趋稳，城市空间布局和基础设施建设已大体成型，多数城市建成区面积与开发强度已达较高水平，城市发展已难以延续外延式扩张态势。在我国城镇化从快速增长期转向稳定发展期、城市发展从大规模增量扩张转向存量提质增效为主的阶段，推动城市全域数字化转型必须以坚持城市内涵式发展为主线，以推进城市更新为重要抓手。 《行动计划》深刻把握我国城市发展阶段性特征，提出推动城市数字更新行动，注重通过盘活存量带动增量发展。一方面，优先解决安全与韧性问题，加快城市基础设施数字化更新改造。在风险高发区域有序实施城市泛在感知工程，运用人工智能等技术深化城市生命线安全工程建设，同时建立健全数字基础设施与市政基础设施同步规划、同步建设机制。另一方面，深化智慧社区建设，着力提升城市功能与品质。支持有条件的地区改造建设一批高品质智慧社区，完善社区嵌入式服务设施，按需配置、优化升级社区数字服务能力，发展智慧物业；打造数字惠民服务生活圈，建设涵盖一站式托育助老、亲子阅读、社区康养等服务的幸福邻里综合体，通过高品质生活空间的打造实现城市有机“新陈代谢”。 三、聚焦城市新“硬件”构建统筹集约数字底座 新时代以来，我国新型城镇化水平和城市发展能级不断提升，城市面貌发生历史性变化，城市功能实现历史性跃升，城市发展取得历史性成就，城市发展的传统“硬件”设施已达到较高水平，部分特大超大城市更是走在世界前列。但与此同时，面对新一轮科技革命和产业变革加速演进、人民群众需求日益升级的新形势，我国城市在数字基础设施建设方面仍有较大提升空间。 《行动计划》提出实施数字化转型筑基行动，强调大力推进城市数字基础设施建设，集约布局感知、网络、算力等基础设施，推进全国一体化算力网建设，在国家算力资源统筹规划下，推动跨区域多元异构算力资源的统筹管理与灵活调度；强化数据资源供给，积极探索数据产权归属认定、合规流通、权益分配等制度建设，建立动态更新的城市公共数据资源目录，逐步构建公共数据“一本账”；完善城市智能中枢，构建统一规划、统一架构、统一标准、统一运维的一体化中枢系统，加强城市数据汇聚治理与融合利用；高度重视数字化转型安全，强化网络安全、数据安全一体化防护能力。一系列具体行动围绕基础设施、数据资源、智能中枢、安全防护四个主要维度形成实施城市新“硬件”发展“路线图”，为现代化人民城市构筑了坚实的数字底座。 四、聚焦激发城市活力深化适数化改革 建设现代化人民城市，需要通过持续深化改革破解矛盾难题，加快培育壮大城市发展新动能。当前，许多城市的政策、标准体系形成于大规模扩张时期，而数字化领域的政策制度仍不健全，亟需破除数字化转型的制度性堵点，加快构建与城市发展新阶段、新目标、新任务相适应的政策制度体系，在适数化改革中实现突破。 《行动计划》坚持系统观念与问题导向，提出开展适数化改革创新行动。重点围绕城市治理需求推进适数化改革，依托城市智能中枢创新跨部门数据合作机制，构建线下网络与线上平台联动协同机制，开展有利于数字化转型的数据确权规则、数字权证应用、行政管理、政府采购等制度改革；针对城市运行效能提升，创新长效运营运维模式，探索建立以用户满意度等应用效果为导向的运营预算与评价考核机制；尤其注重发挥标准的基础性、引领性作用，推动形成涵盖数字底座、转型场景、运营运维等领域的标准规范体系，并围绕服务主体评价，制定城市全域数字化转型规划咨询、建设实施、运营运维三类服务主体评价标准，构建闭环管理体系。相关适数化改革既强调跨部门、跨层级、跨区域统筹协调，又注重鼓励和支持各城市因地制宜，差异化探索全域数字化转型之路，有助于持续激发城市活力，提升现代化人民城市建设的整体效能。 作者： 国务院发展研究中心公共管理与人力资源研究所综合研究室主任、研究员 赵峥 来源（公众号）：北京数据

在数字化转型的进程中，“数据”、“平台”、“组织”被喻为必须翻越的“三座大山”。其中，数据是核心驱动力，软件平台是技术支撑，而组织则是实现转型的基础与保障。唯有构建灵活高效的组织机制，才能推动数据治理落地、释放数据价值，最终实现数字化转型的目标。通过最近走访的一些头部高校，对学校的数据部门的工作调研，促使我思考该如何建立数据治理团队，IT部门如何构建敏捷组织。 一、敏捷组织：数字化时代的组织新范式 （一）敏捷组织的核心定义 敏捷组织（Agile Organization）是指能够灵敏感知内外部环境变化并快速响应的组织形态。麦肯锡研究将其形容为“生物型组织”——如同生命体般具备自我调节、快速进化的能力。与传统金字塔型层级结构不同，敏捷组织以扁平化架构、跨职能团队、端到端责任为特征，强调“小团队作战”与“动态协同”，从而打破层级壁垒，提升决策效率。 （二）敏捷组织的五大核心特征 1.架构灵活：从“层级管控”到“扁平协同” 传统组织依赖金字塔结构实现权力集中，但层级越多，沟通成本越高、响应速度越慢。敏捷组织通过消除上下级壁垒，将组织拆解为小型跨职能团队，团队规模控制在1-5人左右，采用"部落-小队"模式（Tribe-Squad），每个小队承担特定数据治理任务，如教学数据质量提升、科研数据标准化等专项工作。这种结构在企业中已实现决策效率提升30%以上，在高校中可有效解决教务处、科研处、学工处等部门的数据割据问题。 2.数据驱动：从“权威指令”到“数字决策” 数据成为敏捷组织的“神经中枢”。不同于传统高校依赖经验决策的模式，敏捷组织强调"用数据说话"，通过构建统一数据中台，实现教学评价、科研管理、学生服务等场景的量化决策。例如某双一流高校通过分析学生行为数据，将图书馆借阅量、在线课程参与度等12项指标纳入学业预警模型，使挂科率下降18%。 3.员工能动：从“被动执行”到“自我驱动” 敏捷组织将员工定位为“专家型参与者”，而非“任务执行者”。通过目标对齐（OKR）、自主决策、团队协同模式，激发员工主人翁意识。通过OKR（目标与关键成果法）替代传统KPI考核，赋予教师、科研人员、技术人员充分的决策自主权。荷兰代尔夫特理工大学的实践表明，这种模式能使数据治理项目的参与度提升40%，显著改善行政人员与一线教师的协作效率。 4.领导赋能：从“控制管理”到“方向指引” 管理者角色从“指令下达者”转变为“资源协调者”与“方向洞察者”。IT部门负责人从控制者转变为赋能者，聚焦数据战略制定而非具体事务审批，直接牵头协调资源，消除部门本位主义。斯坦福大学数据治理委员会的"方向指引+资源保障"模式，成功推动全校17个业务系统的数据互联互通。 5.动态资源：从“权力分配”到“市场调配” 资源配置摆脱“部门壁垒”，建立市场化资源调配机制。改变传统高校按编制分配资源的固化模式，采用"数据项目入库"，由跨部门团队根据治理需求申请资源，如利用教育教学课题立项申报，通过竞争性申报机制，使有限资源向高价值治理项目倾斜。 二、数据治理为何需要敏捷组织？ 在数字化浪潮下，数据需求呈现“易变性、不确定性、复杂性、模糊性”（VUCA）特征。传统组织因层级僵化、部门割裂、决策滞后，难以应对数据治理的动态需求。敏捷组织通过“柔性架构+数据驱动+全员协同”，成为破解数据治理难题的关键。 （一）数据治理的本质：从“管控数据”到“释放价值” 数据治理的核心目标不是“管理数据”，而是通过数据创造业务价值。这一目标具有显著的动态演进特征：从初期的"消除数据孤岛"，到中期的"构建数据应用场景"，再到长期的"形成数据驱动文化"，每个阶段的重点任务差异明显。传统高校的常设性数据管理部门往往因职责固化，难以适应目标切换需求。而传统层级组织的“层层上报、跨部门协调难”问题，往往导致数据治理沦为“形式化合规”。 （二）敏捷组织可以破解数据治理三大痛点 1.打破“IT部门孤军奋战”困境 传统数据治理多由IT部门主导，业务部门被动配合，导致“数据与业务脱节”。敏捷组织通过IT与业务深度融合，组建跨职能项目团队（如“业务+技术+数据”铁三角），确保数据标准、质量规则与业务场景紧密结合。 2.应对“需求动态变化”挑战 高校数据治理本质上是持续优化的渐进式过程，而非一蹴而就的工程建设。无论是数据标准制定、治理工具开发还是治理文化培育，都需要通过快速迭代响应实践反馈。传统"大而全"的治理方案往往因无法适应实际需求变化而导致项目失败。敏捷组织通过短周期冲刺（Sprint）、快速验证（MVP）机制实现数据治理“小步快跑、敏捷迭代”。 3.构建“全员共治”文化 高校数据治理涉及教学、科研、管理、服务四大领域，治理对象呈现出显著的复杂性：从数据类型看，既有结构化的学籍数据，也有非结构化的科研文献；从数据主体看，涉及师生、管理者、科研团队等多元角色；从治理环节看，覆盖数据采集、存储、共享、应用全生命周期。数据治理需“人人参与”，而非“数据部门专属责任”。敏捷组织通过员工自我驱动、激励机制对齐，推动数据意识渗透到业务全流程。 三、组织架构：从"科层壁垒"到"网络协同" 构建适配高校特点的敏捷数据治理团队，需要从组织架构重构、运行机制设计、能力体系建设三个维度系统推进。这一路径既要吸收企业敏捷实践的成熟经验，又要充分考虑高校学术组织的特殊性，构建具有教育行业特色的治理模式。 从学校整体层面而言，打破传统高校按行政职能划分的组织边界，实现战略层、协调层、执行层的有机衔接： 战略决策层：设立校级数据治理委员会，由校长担任主任，分管信息化副校长任副主任，成员包括教务处、科研院、人事处等核心部门负责人及数据领域专家教授。目前国内很多高校已经成立了类似的委员会，可以通过治理驾驶舱实时监控重点项目进度，有效避免委员会沦为形式化机构，建立"决策-执行-反馈"闭环工作机制。 跨域协调层：学校信息化部门实际上是数据治理常设协调机构，负责将战略层决策转化为具体任务。关键职能包括制定数据治理标准规范（如《高校数据分类分级指南》）、统筹跨部门数据项目、开展数据治理成熟度评估等。 敏捷执行层：信息化部门的数据业务部或信息系统部则是数据治理的执行层，构建多元化执行团队体系，进行敏捷组织建设是数据治理成效的关键。负责日常数据治理工作，如数据质量管理团队（监控数据质量KPI）、数据安全合规团队（处理隐私保护问题），采用"7+2"人员配置模式（7名专职技术人员+2名业务部门人员）。针对临时性治理任务，如"智慧迎新"，任务完成后自动解散。采用"3×3"组建原则：3个核心部门（学工、信息、教务）+3个关键角色（产品负责人、技术负责人、业务负责人）。上述方法可以灵活配置团队规模，有效缓解数据部门人员不足的问题。 四、运行机制：从"行政指令"到"价值驱动" 建立适配敏捷治理的全流程运行机制，通过目标管理、协作模式、激励机制的创新，激发团队内生动力： 目标管理机制：引入OKR（目标与关键成果法）替代传统任务分解模式，通过"校级战略-部门级战术-个人级执行"三级联动，确保治理目标上下对齐。 迭代协作机制：采用Scrum敏捷框架，将治理项目分解为2-4周的冲刺周期，通过"每日站会-冲刺评审-回顾会议"实现持续改进。 激励约束机制：构建多元激励体系，在项目奖励、职称评审、教学成果认定等方面设计激励政策。同时建立柔性约束机制，通过数据治理成熟度评估，将评估结果与部门绩效考核挂钩。 五、能力体系：从"单一技能"到"复合素养" 敏捷组织需要“懂业务+懂技术+懂数据”的T型人才，除技术能力外，强调“问题解决能力”“跨团队沟通能力”。数据治理团队需要从五个方面进行建设。 （一）以客户为中心：从“部门视角”到“用户视角” 用户需求是数据治理的起点，敏捷组织需建立“客户洞察-数据响应-价值交付”的工作闭环。基于用户旅程 Mapping，梳理用户全流程数据触点，识别关键痛点。对新数据应用场景（如个性化推荐）先进行小范围测试，用小步验证方式，获取用户反馈并快速调整。 （二）以数据驱动：从“经验决策”到“数字洞察” 数据是敏捷组织的“血液”，需构建“数据采集-整合-分析-应用”全链路能力。通过协作工具（如飞书、Jira）、低代码平台（如Power Apps）、数据中台支撑小团队快速行动。搭建实时数据平台，通过数据湖、流处理技术（如Flink）实现业务数据实时接入。推广普及自助分析工具，为业务人员提供低代码分析平台（如Tableau、Power BI），减少对IT部门的依赖。 （三）重新定义IT：从“成本中心”到“价值引擎” 敏捷组织要求IT成为业务创新的“发动机”。IT部门努力实现三个转型，一是从“业务支撑”到“业务驱动”，IT人员要嵌入业务一线，IT工程师与业务部门工作人员共同主导数据治理；二是从“技术实现”到“生态整合”，通过引入外部技术供应商（如云服务、AI工具）弥补内部能力短板，与第三方合作搭建平台，降低数据处理成本；三是从“系统运维”到“能力中台”，构建可复用的数据中台、业务中台，支撑前端快速创新。 （四）业务与IT深度融合：从“部门协同”到“组织共生” 打破“业务不懂技术、IT不懂业务”的壁垒，实现“技术赋能业务、业务反哺技术”。IT人员可以到业务部门轮岗，业务人员参与系统开发。通过双向奔赴，培养“既懂业务又懂大数据”的复合型骨干。业务与IT团队共享目标，联合OKR设定，双方协同完成数据埋点、模型优化、运营活动设计等环节。 （五）培养复合型人才：从“单一技能”到“多元能力” 数据团队需要“懂业务+懂技术+懂数据”的T型人才，除技术能力外，强调“问题解决能力”“跨团队沟通能力”。加强内部培训，开设“数据治理专项培训”“业务场景工作研讨”；对数据创新成果给予额外奖励，在教学成果申报、论文认定、专利软著申请等方面给予支持。 五、结语：敏捷组织——数据治理的“胜负手” 数字化转型的本质是“用数据重构业务逻辑”，而敏捷组织则是这一过程的“组织容器”。从“架构灵活”到“数据驱动”，从“员工能动”到“业务IT融合”，敏捷组织通过系统性变革，将数据治理从“合规任务”转化为“业务增长引擎”。未来，只有那些能够快速感知数据价值、灵活调整组织形态组织，才能立于不败之地。 正如管理学大师彼得·德鲁克所言：“动荡时代最大的危险不是动荡本身，而是仍然用过去的逻辑做事。”敏捷组织，正是应对数据时代不确定性的“新逻辑”。 来源（公众号）：数智转型洞察

Gartner研究副总裁高挺（Arnold Gao）表示：“2026年对技术领导者而言是至关重要的一年，变革、创新与风险将在这一年以空前的速度发展。2026年的各项重要战略技术趋势将密切交织，折射出一个由人工智能（AI）驱动的高度互联化世界的现实图景。 在这样一个世界，企业机构必须推动负责任的创新、卓越运营和数字信任。这些趋势不仅代表了技术变革的方向，还是促进业务转型的催化剂。今年不同于以往的一点是变革速度——这一年涌现的创新成果远超以往。由于下一轮创新浪潮已近在眼前，只有当下采取行动的企业才能应对市场波动和决定未来数十年的行业走向。” 以下是2026年重要战略技术趋势。（小编根据10大趋势内容做了一个图表供大家更快速的参考阅读，版权归属Gartner公司） Part 01 AI超级计算平台 AI超级计算平台整合了CPU、GPU、AI ASIC、神经系统计算和替代性计算范式，使企业能够统筹复杂工作负载，同时释放更大的性能、效率与创新潜力。这些系统融合了强大的处理器、海量存储、专用硬件及编排软件，可处理机器学习、仿真模拟和分析等领域的数据密集型工作负载。 Gartner预测，到2028年，将混合计算范式架构应用于关键业务流程的领先企业将达到40%以上，较当前8%的水平大幅增长。 高挺表示：“该技术已在推动各行各业的创新。例如医疗和生物技术企业已将新药建模时间从之前的数年缩短至仅需数周；金融服务机构通过模拟全球市场降低了投资组合风险；在公共事业领域，服务商通过建立极端天气模型提升电网性能。” Part 02 多智能体系统 多智能体系统（MAS）是由多个AI智能体组成的集合，它们通过交互实现复杂的个体或共同目标。这些智能体既可在单一环境中交付，也可在分布式环境中独立开发部署。 高挺表示：“通过使用多智能体系统，企业可实现复杂业务流程的自动化、提升团队技能并开创人类与AI智能体的新协作方式。采用模块化设计的专业智能体通过在各工作流中重复使用成熟解决方案提升效率、加快交付速度和降低风险。这种方案还便于扩展运营规模和快速适应需求变化。” Part 03 特定领域语言模型（DSLM） 首席信息官（CIO）和首席执行官（CEO）正要求AI创造更多商业价值，但通用大语言模型（LLM）往往难以胜任专业任务。特定领域语言模型（DSLM）凭借更高的准确性、更低的成本和更好的合规性填补了这一空白。DSLM是在针对特定行业、功能或流程的专用数据上训练或微调的语言模型。不同于通用模型，DSLM能更加精准、可靠且合规地满足特定业务需求。 Gartner预测，到2028年，企业使用的生成式AI（GenAI）模型中将有超过半数属于特定领域模型。 高挺表示：“上下文正成为决定代理部署成功与否的关键因素之一。基于DSLM的AI代理可解读特定行业的上下文，即使在陌生场景中也能做出合理决策，因而具有出色的准确性、可解释性和决策合理性。” Part 04 AI安全平台 AI安全平台为第三方及定制AI应用提供了统一防护机制，它能够进行集中监测、强制执行使用策略并有效防范AI特有风险，如提示注入、数据泄露、恶意代理行为等。此类平台可帮助CIO有力执行使用政策、监控AI活动并在全AI系统中建立统一防护边界。 Gartner预测，到2028年，使用AI安全平台保护AI投资的企业比例将达到50%以上。 Part 05 AI原生开发平台 AI原生开发平台使用GenAI实现空前快速、便捷的软件开发。进入业务部门的软件工程师作为“前沿部署工程师”可使用这些平台协同领域专家开发应用。企业只需维持现有开发人员规模，通过组建微型团队配合AI即可开发更多应用。目前，领先的企业正在组建微型平台团队，在安全和治理框架范围内让非技术领域专家能够自主开发软件。 Gartner预测，到2030年，80%的企业将通过AI原生开发平台将大型软件工程团队转变为更小、更敏捷的团队并通过AI赋能这些团队。 Part 06 机密计算 机密计算重塑了企业处理敏感数据的方式。由于工作负载被隔离在基于硬件的可信执行环境（TEE）中，因此即使面对基础设施所有者、云提供商或任何拥有硬件物理访问权限的实体，机密计算也能保持内容与工作负载的私密性。这对受监管行业、面临地缘政治与合规风险的跨国公司以及竞争对手间的合作尤为重要。 Gartner预测，到2029年，75%以上在非可信基础设施中处理的业务将通过机密计算保障使用安全。 Part 07 物理AI 物理AI通过赋能具有感知、决策和行动能力的机器与设备（例如机器人、无人机和智能设备），将智能带入到现实世界。它能为自动化、适应性和安全性至关重要的行业带来可观的收益。 随着该技术的日益普及，企业需要融合IT、运营与工程知识的新型技术人才。这一转变虽带来了技能提升与协作机会，但也可能引发人们对就业的担忧，因此需要采取谨慎的变革管理。 Part 08 前置式主动网络安全 随着企业面临的网络、数据及联网系统威胁成倍增长，前置式主动网络安全正成为趋势。Gartner预测，到2030年，随着CIO从被动防御转向主动防护，前置式主动防御解决方案将占到企业安全支出总额的一半。 高挺表示：“前置式主动网络安全的核心在于运用AI驱动的安全运营、程序化阻断与欺骗技术在攻击者行动前实施干预，这项技术通过预测实现防护。” Part 09 数字溯源 随着企业日益依赖第三方软件、开源代码及AI生成内容，数字溯源验证已成为一项重要的需求。数字溯源指对软件、数据、媒体及流程的来源、所有权和完整性进行验证的能力。企业可使用软件物料清单（SBoM）、认证数据库、数字水印等新工具验证和追踪供应链中的数字资产。 Gartner预测，到2029年，在数字溯源方面投入不足的企业将面临高达数十亿美元的制裁风险。 Part 10 地缘回迁 地缘回迁指企业因考虑到地缘政治风险而将数据与应用从全球公有云迁出至主权云、区域云服务商或自有数据中心等本地平台。云主权这一概念曾仅限于银行与政府机构，如今随着全球局势动荡加剧而影响到各类企业。 高挺表示：“将工作负载转移至主权立场更强的服务提供商可帮助CIO加强对数据驻留、合规及治理的控制力。这有助于提高对本地法规的遵从性并获得关注数据隐私或国家利益的客户的信任。” Gartner预测，到2030年，欧洲和中东地区将有超过75%的企业把虚拟工作负载回迁至降低地缘政治风险的解决方案，而2025年的这一比例不足5%。 今年的主要战略技术趋势聚焦未来五年将为CIO、IT及高科技领导者带来重大变革与机遇的趋势。Gartner客户可通过《2026年重要战略技术趋势》专题报告了解更多详情。 来源：Gartner公司

近年来，“场景”一词在各类政策文件、产业报告和创新实践中频繁出现——从“数字政府场景化建设”到“AI+ 工业场景落地”，从“消费端场景创新”到“公共服务场景优化”。“场景”已不再是单纯的“情境描述”，而是成为新技术落地、新需求挖掘乃至问题解决与新价值创造的核心载体。 究其本源，当人工智能、物联网、大数据、边缘计算等新技术不断突破壁垒后，如何避免技术沦为“空转工具”，使其精准对接真实需求，成为创新的关键命题？而“场景”，正是链接技术与价值的重要桥梁。基于实践和研究总结，本文将场景归纳为“问题场景、需求场景、应用场景、案例场景”四阶框架，系统厘清从“发现问题”到“创造价值”的完整逻辑链条，以期为新技术时代的创新实践提供行动参考。 从“问题场景”入手，精准锚定价值源头 在新技术加速渗透的当下，创新实践往往面临“伪痛点”干扰——部分看似亟待解决的问题，要么脱离实际需求，要么缺乏技术适配基础，最终导致资源错配与创新低效。而“问题场景”的核心价值，在于依托新技术的感知、分析能力，穿透表象，识别核心矛盾，精准锚定“具体问题 + 价值缺口”。 借助数据监测、用户画像等技术工具，“问题场景”能够摆脱“模糊感受”的局限，将抽象的“不便”转化为可量化、可界定的具体矛盾：明确“谁在什么情境下遇到了什么阻碍”，以及“这一阻碍会造成怎样的价值损失”。这种精准锚定，使创新从源头就瞄准真正的价值“靶点”，避免技术投入“无的放矢”，也为后续价值创造筑牢了基础。 明晰勾勒“需求场景”，准确反映目标诉求 如果说“问题场景”是价值创造的“起点”，那么“需求场景”便是连接问题与技术的“转换器”。它将问题背后的价值缺口系统拆解为可落地的分层诉求，为新技术应用提供清晰指令。 “需求场景”的勾勒需紧扣“技术适配性”与“价值完整性”：既要关注直接解决问题的显性需求，明确技术应用的核心方向；也要重视支撑价值落地的隐性需求，保障技术应用的实际体验——若忽略隐性需求，即便技术功能达标，也可能因“体验缺陷”难以落地；还需考虑技术联动的关联需求，推动价值形成闭环，避免出现“解决老问题、引发新矛盾”的情况。 在此过程中，要警惕走入“技术先行”的误区，始终坚持以价值为导向，让需求牵引技术应用，而非让技术定义需求，确保每一项诉求都能服务于创造价值的最终目标。 打造“应用场景”，融合新技术创造新价值 “应用场景”是“需求场景”的具象化落地载体，也是新技术真正转化为实际价值的“最后一公里”。它聚焦于“在具体情境下，如何通过技术方案满足需求并创造价值”，核心在于实现技术与场景的深度适配。 打造“应用场景”需充分考量场景的约束条件——包括成本预算、环境限制、用户能力等，拒绝脱离实际的“通用方案”，而是要结合场景特性定制技术组合。“应用场景”通过将新技术与场景需求深度融合，使技术从“空中楼阁”的功能堆砌转变为嵌入实际场景的实用工具，既解决核心问题，又契合场景特性，最终创造出可感知、可量化的新价值。 这种“场景定制化”的技术应用，不仅能提升创新效率，更能确保价值落地的稳定性与可持续性。 用好“案例场景”，迭代推广实现价值升级 “案例场景”并非简单的成果展示，而是兼具“内部优化”与“外部推广”双重价值的闭环环节，既是前序场景的验证与修正载体，也是价值经验跨场景、跨区域扩散的核心纽带。在新技术赋能的创新生态中，单一案例的价值往往局限于内部，只有通过系统化推广，才能将局部经验转化为行业级、区域级的规模化价值增量。 一方面，“案例场景”需通过真实实践完成内部校准——验证“问题—需求—应用”链条的合理性，发现漏洞、反馈优化；另一方面，更需构建“可推广的经验模板”，通过提炼案例中的“共性逻辑”与“适配方法”，形成标准化的推广框架。同时，可依托数字化平台搭建案例共享库，整合不同领域、不同规模的案例经验，配套“场景适配指南”，帮助推广对象快速判断案例适用性，降低试错成本。 这种“内部迭代 + 外部推广”的双轮驱动，既能让案例价值从单一场景延伸至更广领域，实现“一点突破、多点受益”，又能通过推广中的反馈进一步丰富案例内涵，形成“迭代—推广—再迭代”的良性循环，推动价值创造从“局部优化”走向“系统升级”。 四阶场景联动，构建价值创造的系统闭环 “问题场景、需求场景、应用场景、案例场景”并非线性的步骤流程，而是围绕价值创造形成的相互校准、动态优化的系统闭环——“问题场景”锚定价值源头，若锚定偏差，后续环节便会偏离方向；“需求场景”拆解技术指令，若拆解不完整，应用场景便难以落地；“应用场景”实现价值转化，若适配不足，价值便无法有效生成；“案例场景”推动价值优化与推广，若反馈缺失或推广乏力，价值创造便难以突破局部局限、实现规模化增量。 这一闭环框架的核心意义，在于为新技术时代的创新实践提供一条清晰的从“技术”到“价值”、从“局部”到“全局”的转化路径，让创新不再依赖“经验判断”，而是基于系统逻辑实现精准发力与规模化扩散。在新技术加速创新的背景下，唯有依托四阶场景的联动，才能让技术真正嵌入社会经济肌理，成为推动价值创造从“单点创新”走向“生态化突破”的核心力量，为产业升级、公共服务优化、消费创新等领域提供坚实支撑。 来源（公众号）：浙江数字经济