龙石数据中台 V3.8.7 版本发布，聚焦数据规划、数据集成及基础配置三大核心模块，新增Doris物理模型可视化管理能力，优化文件展示、组件操作及工作空间配置体验，简化操作流程、提升使用效率，进一步完善平台易用性与实用性。

为全面贯彻落实党的二十大和二十届历次全会精神，深入落实中央经济工作会议和全国两会精神，按照“十五五”规划纲要任务部署，促进实体经济和数字经济深度融合，国家数据局印发《2026年数字经济发展工作要点》（以下简称《工作要点》）。 《工作要点》对2026年推进数字经济高质量发展重点工作作出部署，提出8个方面重点任务。 一是深化数据要素市场化配置改革。 加快建立全国统一数据产权登记制度，印发登记指引，推动各地加快建立健全公共数据授权运营价格形成机制，制定出台建设开放、共享、安全的全国一体化数据市场相关政策文件。 二是筑牢数字基础设施底座。 加快建设全国一体化算力网，推动数据、网络、算力、能源等资源协同布局，稳妥推进数据基础设施建设，支持行业、领域示范性设施建设。 三是强化数据赋能人工智能发展。 实施强基扩容、应用赋能、提质增效、管理服务、价值释放、标注攻坚6大专项行动，形成一批满足AI就绪度要求、有效训练先进模型、切实解决行业难题的标杆性高质量数据集。 四是提升数字经济核心竞争力。 因地制宜培育创新引领型、区域支柱型、区域特色型数字产业集群，培育数字经济创新型企业，构建“政府+企业+创新+投资”四合一的专业化遴选培育机制，组建数字经济创新型企业培育库，开展企业遴选。 五是促进实体经济和数字经济深度融合。 深入推进制造业数字化转型行动和重点行业数字化转型实施方案，加快赋能服务业扩能提质，丰富数据资源运营、数据技术创新、数据分析应用等服务供给，鼓励探索风险共担、收益共享的数据应用服务新模式，围绕数据赋能重大场景建设，培育一批数智化转型服务商。 六是提升数字化治理与服务能力。 推进数字经济促进法立法进程，持续推进数据安全管理，强化重要数据和核心数据识别与保护。 七是深化数字经济国际合作。 开展数字经济多双边合作，积极参与数据领域国际规则标准制定，鼓励有条件的地方探索建设数据跨境流动服务基础设施、国际数据中心，建设一批跨境可信数据空间。 八是营造良好发展环境。 探索构建央地协同、科学规范的数字经济监测评估体系，研究发布数字经济发展指数和有关先行指数，深化国家数字经济创新发展试验区建设，组织开展专家行活动。 下一步，国家数据局将会同有关部门抓好各项任务落实，以经济领域重大场景为切入，充分释放数据要素价值，助力建设现代化产业体系，加快培育新质生产力，赋能经济高质量发展。 来源（网站）：国家数据局

一、数据产权是什么？结构性分置划重点！ 01 数据产权结构性分置重点做什么？ 路径：顺应数据特性分置数据持有权、数据使用权、数据经营权等权利 本质：明确 “谁对什么数据有什么权利” 目的：推动数据资源开发利用，充分释放数据要素价值 02 数据产权 “三权” 指的是什么？ 数据产权：对特定数据享有的财产性权利。 数据持有权 自行持有或委托他人代为持有合法获取的数据的权利。 数据使用权 以加工、聚合、分析等方式，将数据用于优化生产经营、形成衍生数据等的权利。 数据经营权 以转让、许可、出资或依法设立担保等有偿或无偿的方式对外提供数据的权利。 03 数据 “三权” 的关系是什么？ 既可分置配置，也可并行享有（互相独立） 数据持有权、使用权、经营权互相独立，同一权利人可同时享有全部权利，也可享有其中一项或多项权利。“三权” 间互不影响，不存在从属或依附关系。比如，数据持有权不是使用权、经营权的必要前提，权利人可仅享有数据经营权，而不享有持有权、使用权。 同一项权利可由多个主体同时享有（互不排斥） 对于同一数据的同一权利，不同权利人可同时享有且互不排斥。 04 如何取得数据 “三权”？ 各类主体通过采集生成、衍生创造等方式，以及受让取得、授权许可等合同约定的渠道获得数据的，依法取得相应的数据产权。 各类主体对于违法违规获取的数据不享有数据产权。 二、数据产权分置坚持什么原则？ 坚持问题导向 适应实践需要，从实际出发解决难点堵点问题。 坚持统筹兼顾 平衡各方利益，为新业态新模式发展留足空间。 坚持守牢安全底线 坚决维护国家安全，保护国家秘密、商业秘密、个人信息，促进数据合法合规高效流通使用。 三、这些重点场景下数据产权如何配置？ （明确谁在什么条件下享有什么权利） 采集生成 现实场景：经营主体会在生产经营过程中采集设备运行、物料使用、环境状况等各类数据，经数据开发利用后，用于优化经营管理，或参与数据市场交易。 采集原则：鼓励各方积极有序参与数据采集生成，加强高质量数据供给，防止超范围采集数据。 产权配置规则：数据处理者在自身或共同参与的生产经营活动中，对不违反法律法规、合同约定的前提下采集生成的数据，享有持有权、使用权、经营权。 委托处理 现实场景：实践中经常有委托他人处理数据的情况，如企业委托云平台存储数据，政府部门委托软件企业开发电子政务系统、进行数据处理等。 相关主体： 数据处理者（委托人）：能自主决定处理方式和处理目的的自然人、法人、非法人组织。 受托人：按数据处理者的要求处理数据，不能自主决定处理数据的目的和处理方式。 产权配置规则： 受托人对委托处理的原始数据、过程数据、结果数据等除法律另有规定或合同另有约定外，不享有持有权、使用权、经营权。 委托期满或受托人解散、被宣告破产等，相关数据应当按委托人要求返还或依照国家有关规定处理，不得用于受托人债务清偿或破产清算。 自动化收集 现实场景：各方普遍认为，公开发布数据是为了传播复用。收集公开数据是数据融合利用的重要方式，不少企业依靠通过自动化程序收集的公开数据开展经营活动。 合法性边界（司法裁判共识）： 不非法侵入他人网络 不干扰网络服务正常运行 不破坏有效技术措施 不损害个人和组织合法权益 产权配置规则：数据处理者对于合法收集的公开数据，可以持有和使用。如果数据处理者基于收集的原始数据进行了创新开发，形成了数据产品，可以在不实质性替代被收集方产品和服务等的前提下对外提供数据产品。 融合利用 现实场景：数据量越大、来源越多，融合利用后的价值就越高。目前，不少企业合作开发数据产品，每个企业拿出一份数据、共同进行开发。 产权配置规则： 多个数据处理者合作推进数据融合开发 有合同约定：应优先遵循合同约定融合后数据的产权配置。 没有合同约定或约定不明确：对于融合后数据，各方均享有持有权、使用权，在征得其他参与方同意的前提下享有经营权。 衍生数据 现实场景：将已有数据开发利用形成新的数据，是挖掘数据要素价值的一种典型方式。 衍生数据判别规则： 显著性：衍生数据的结构、形态、内容与原始数据具有显著差异。 增值性：衍生数据要具有显著高于原始数据的价值，形成数据价值增值。 产权配置规则：数据处理者对其享有使用权的数据，在保护各方合法权益的前提下开发形成衍生数据的，享有该衍生数据的持有权、使用权、经营权。 四、数据产权制度落实中的安全保护 总体原则 加强数据产权保护，坚持将维护国家安全、保护商业秘密和个人信息作为数据产权制度建设前提，在遵守法律法规、合同约定的前提下取得、流转、行使数据产权。 全过程安全措施 获取环节：各类主体对于违法违规获取的数据不享有数据产权。 流通环节：涉及国家安全、商业秘密、个人信息等的数据，应在依法取得授权或主管部门批准，并采取必要安全措施后流通。各类主体在数据产权流转过程中，要严格落实数据安全管理要求，切实履行数据安全保护义务。 使用环节：需求方应按照法律法规和合同约定使用数据，严禁滥用。 事中事后监管 设施保障：建设和运营国家数据基础设施，依托隐私计算、区块链、可信数据空间等技术和解决方案，支撑数据安全流通。 监管执法：构建全流程溯源机制，防范数据领域垄断和不正当竞争行为，加强对违法违规获取、交易、使用数据等的执法力度，依法严厉打击滥用数据损害国家安全、公共利益和他人合法权益等行为，防范化解安全风险。 维护公共数据安全 公共数据开发利用模式：开放、共享、授权运营。 切实维护公共数据安全：健全公共数据资源开发利用管理制度，有效扩大数据供给。 来源（网站）：国家数据局

构建起权属清晰、行使规范、流转顺畅、保护有效的数据产权制度，对推动释放数据要素价值具有重要意义。

领导者们，现在的问题不再是这场变革是否会发生，而是你们是先于变革做好准备，还是被动地应对变革。 我想从最高层开始——不是从分析师的职业焦虑开始，而是从这一刻对于负责数据职能的领导者来说究竟意味着什么开始。 大多数商业智能和分析团队的架构都基于一个已被悄然推翻的核心假设：组织智能的主要制约因素是人对 SQL 的访问权限。消除这一障碍——通过增加分析师人数、完善商业智能工具、覆盖仪表盘——企业就能更加数据驱动。 这一假设推动了长达十年的分析投资。它催生了庞大的商业智能团队，推动了Tableau和Power BI许可证的增长，并将“数据驱动”变成了高管层的口头禅。而且，它的确达到了目的。至少在一段时间内是这样。 智能体人工智能已经使它过时了。 如今，制约组织智能发展的不再是查询权限，而是连接原始数据和业务决策的知识层的质量。更紧迫的问题是速度——仪表盘本质上是被动的，只有在用户主动查找后才能提供洞察，而业务领导者越来越需要在事件发生时就能获得答案。智能体系统不会等待用户提问，它们会持续监控、推理并呈现信息。 那是一种截然不同的模式，需要一支截然不同的团队。 智能体人工智能对商业智能功能究竟有何作用 让我们说得更具体些，因为关于人工智能取代分析师的模糊说法对任何人都没有帮助。 智能体分析的最佳应用方式是增强而非取代组织现有的嵌入式商业智能和数据系统——它建立在已有的数据管道、语义模型和治理框架之上，使人工智能代理能够直接在公司现有环境中运行。关键在于“建立在……之上”。没有“直接部署人工智能”的捷径。基础设施必须先存在。语义层必须构建完成。业务逻辑必须编码完成。而且，必须有人来管理它。 正在消亡的是被动的、请求驱动的分析工作流程。智能体人工智能系统可以在几秒钟内完成分析，而分析师手动收集、查询和验证数据则需要两到四个小时。这种时间压缩并非意味着分析师变得无关紧要——相反，它使得分析师的机构知识，如果被正确编码到系统中，其价值将远超以往仅存在于他们头脑中的情况。 转变之处在于：以前分析师的输出是一个查询语句，现在则是一个受控的定义，一百个用户无需提交任何工单即可同时进行查询。 智能体人工智能使数据分析民主化，让组织内的广大用户都能轻松获取数据——业务用户可以提出复杂的问题，并获得简洁明了、对话式的答案，而无需了解 SQL 或任何技术语言。这对领导者的影响显而易见。非技术背景的利益相关者现在有了一个可靠的替代方案，无需再向你的团队寻求帮助。如果你的团队没有构建确保答案准确性的智能层，其他人就会去做——更糟糕的是，人工智能可能会凭空捏造出一个听起来合理的答案。 领导者思维模式问题：关注结果还是关注原因 真正的问题在于此，我就直说了。 目前大多数数据领导者都处于观望状态。他们密切关注着通用商业智能（GenBI）市场的发展，等待观察哪些工具最终胜出，谨慎地开展试点项目，并告诉团队“人工智能将增强而非取代现有业务”。这种说法本身并没有错，但却是一种危险的被动姿态。这是一种等待外部事件明朗化后再确定方向的心态。 那些身居要职的领导者不会坐以待毙。他们做出了如下豪赌：他们组织中的语义层——即对业务指标实际含义进行编码、管理、机器可读的定义——是他们现在能够构建的最有价值的基础设施。而且，他们是在被迫之前就着手构建它。 这两种策略带来的结果差异将十分显著。将人工智能项目成果与可衡量的仪表盘挂钩的分析团队，将改变预算讨论的焦点——不再围绕工具成本，而是围绕可衡量的回报。这种转变将数据职能从成本中心提升为战略资产。率先展开这种讨论的领导者将主导讨论的走向。 身处事业之中意味着要做出那些在没有完全把握的情况下令人感到不舒服的决定： 在GenBI平台完全验证之前，将分析师的精力从报告撰写转移到语义层构建。 在自助查询模式全面投入运营之前，告知利益相关者被动式查询模式即将逐步停止运行。 在组织尚未完全理解原因之前，就通过智能基础设施重组团队角色和 OKR，降低每次洞察的成本。 这种不适感是走在时代前沿而不是落后于时代所要付出的代价。 重新思考组织设计：从服务台到智能基础设施 组织架构设计问题是大多数数据领导者遇到的瓶颈。当前的组织结构既熟悉又稳定，并且与利益相关者的关系紧密相连。要改变它，就必须正视组织结构本身存在问题这一事实。 如今大多数 BI 团队都是按照领域相关的服务职能构建的： 这种设计旨在优化对各个利益相关群体的响应速度。每位分析师都拥有一个队列、一组关系以及一套领域知识。问题在于，这三者——队列、关系和知识——都属于个人，而非系统。当分析师离职时，这些知识也随之流失。当队列增长时，系统会聘请另一位分析师。当利益相关方需要新的仪表盘时，则由工程师负责构建。 传统商业智能 (BI) 的局限性意味着只有经过培训的分析师才能获取洞察，或者需要 BI 团队的参与，而且报告反映的是历史数据，而非未来预测或可执行的建议。服务台模式在结构上无法改变这一点。它的规模与员工人数呈线性增长，并且只能生成特定时间点的快照，而非动态的智能层。 GenBI 时代的团队设计遵循不同的原则：一次编码，处处可用。但支撑这一理念的结构模型并非重新集中化的分析功能，而是联邦式结构。领域团队拥有各自的数据产品，而中央平台团队则拥有运行所有这些产品的基础设施。这就是应用于智能体人工智能时代的“数据网格”原则。 这个设计中有几点值得一提。 平台团队是赋能者，而非守门人。其职责是提供基础设施、标准和工具，使领域团队能够独立构建和发布数据产品——包括语义引擎、GenBI 运行时、治理框架和数据目录。平台团队不拥有业务逻辑，业务逻辑属于各个领域。 每个领域团队都是一个全栈数据产品单元。它包含语义知识（负责编码业务定义的专家）、构建能力（负责构建和维护转换层的分析工程师）以及对两者都负责的领域专业知识。如果商业团队对客户流失的定义有误，则由商业分析负责人负责，而不是由与业务背景相隔三层的集中式 BI 部门负责。 在这次转型中，分析工程师的角色最被低估。在旧模式下，分析工程师是 dbt 开发人员——他们编写 SQL 转换、建模数据并构建分析师查询的干净表。在新模式下，他们是智能层本身的架构师。原因如下：一个成熟的 dbt 项目不仅仅是一个转换库，它是一个结构化、版本控制且文档齐全的知识库。每个 dbt 模型都有名称、描述、列级文档以及内置的业务逻辑测试。在 dbt 语义层中定义的每个指标（通过 dbt Metrics 或 MetricFlow）都是一个机器可读的业务定义，并附带一个血缘图。这正是 Vanna 和 Wren AI 生成准确、上下文相关的 SQL 所需的训练语料库。懂得如何将 dbt 项目作为 GenBI 训练源的分析工程师并非在做一份新工作——他们只是以更高的效率完成现有工作。他们不再构建分析师查询的模型，而是构建用于训练所有人都在查询的 AI 的模型。 dbt 存储库成为动态语义层，随着业务的发展不断更新，自动向智能层提供受管控的定义，而无需从头开始手动标注。 每个领域的分析主管都是一种新型角色。他们并非负责协调分析师工作的经理，而是资深实践者，负责该领域语义层的产品开发，包括其覆盖范围、准确性、治理以及随着业务变化而不断演进。他们参与业务部门领导层的讨论，了解决策内容以及支持这些决策所需的定义。 跨域指标由统一的部门进行管理。跨越多个领域的指标——例如公司总收入、综合客户获取成本、综合客户流失率——通过相关领域负责人参与的联合流程进行定义，并由平台团队的治理层批准。任何单一领域都无权单方面拥有这些指标。这是大多数数据网格实现方案设计不足的棘手治理问题，需要明确的设计而非假设。 从纸面上看，人员编制可能与现在差不多。但问责模式却截然不同。知识不再属于个人，而是属于版本化、文档化和管理化的领域数据产品。即使管理员离职，语义层依然保留。随着业务发展，领域负责人会更新定义。智能基础设施将成为组织资产，而非依靠机构记忆和Slack聊天记录维系的个人专业知识集合。 真正有效的技能提升计划 大多数组织中关于技能提升的讨论都缺乏正确的视角。领导者宣布启动“人工智能技能提升计划”，购买平台许可，并衡量在线课程的完成率。三个月后，分析师的行为却没有任何改变。 这种方法行不通，因为它把技能再培训视为学习问题。实际上，它是一个工作设计问题。 人们很容易急于在所有岗位上同时提升GenAI素养，但正确的方法是从业务成果入手，思考人工智能投资如何促进或加速这些成果的实现，然后再明确实现这些成果所需的技能。如果只注重技能而忽略成果导向的再培训，最终只会培养出证书收集者，而非真正具备实践能力的从业者。 以下是商业智能和分析职能部门进行转型时，有效的技能再培训的具体内容： 第一层级：面向所有分析师的人工智能素养（第 1-4 周） 团队中的每位分析师都需要对 GenBI 工具的运作方式有一个清晰的理解——不是如何配置，而是它们的准确性如何取决于底层语义层的质量。这是基础。如果没有这个基础，分析师就会把 GenBI 当作玩具，而不是他们负责构建和管理的系统。 实用形式：每周一次 90 分钟的工作坊——一部分讲解概念，一部分使用您的实际数据和 GenBI 平台进行实践操作。使用您自己的指标作为培训材料。标注您自己的查询。学习与实践密不可分。 第二层级：高级分析师的语义策展技能（第 5-12 周） 这才是真正技能提升的关键所在。高级分析师需要学习如何系统地将 SQL 知识转化为结构化的语义定义。具体技能包括： 编写精准的业务定义，消除歧义 识别并记录对指标的常见误解 对 GenBI 工具可作为训练数据接收的注释进行结构化处理 运行验证测试——使用利益相关者提出的相同问题查询 GenBI 层，比较输出结果，并进行迭代。 为期 12 周的课程可以将初级分析师培养成人工智能运维专家——对于拥有深厚领域知识的高级分析师来说，转型速度更快。他们的专业知识是原材料，课程教他们如何将其转化为实际应用。 第三层级：面向 GenBI 的分析工程（第 3-6 个月） 这是最直接、最具杠杆效应的技能提升发生的地方——也是大多数组织错失重大价值的地方。 已经使用 dbt 的分析工程师拥有一个尚未被广泛理解的优势。一个维护良好的 dbt 项目本身就是一个语义知识库。模型描述、列级文档、dbt 测试和 MetricFlow 指标定义都是结构化、机器可读且版本化的工件。Vanna 基于 RAG 的训练管道可以直接将 dbt 模型 YAML 文件作为文档源导入。Wren AI 的原生 dbt 集成意味着您可以连接现有的 dbt 项目，并完全跳过手动语义层设置——转换层本身就成为了训练语料库。 因此，分析工程师的技能提升并非从零开始学习新工具，而是学习如何编写以 GenBI 使用为导向的 dbt 文档： 模型描述应解释业务目的，而不仅仅是技术结构 列描述应定义业务含义，而不仅仅是数据类型 dbt 测试对每个指标的“正确”状态进行编码，并将失败结果作为语义层治理信号呈现出来。 MetricFlow 指标定义使业务计算更加明确、可重用且可供 AI 查询 一位分析工程师如果在整个数据库项目中系统地执行此操作，实际上就为 Vanna 或 Wren AI 预先构建了语义层。原本需要语义标注员花费数周时间才能从原始 SQL 数据中手动完成的标注工作已经完成——只需根据业务上下文编写合适的代码，即可用作 GenBI 训练数据。 此层级的学习工具：选取一个领域的数据库项目，审核文档完整性，重写模型和列描述以符合 GenBI 就绪标准，连接到 Vanna 或 Wren AI，并测量修改前后的查询准确率。差值即为概念验证。 什么因素加速了这三个层次的发展： 将技能提升与绩效目标直接挂钩。语义覆盖率、自助服务采用率和人工智能数据产品使用率是新的关键绩效指标 (KPI)。当职业发展取决于构建智能层而非处理查询时，分析师就能更快地适应新模式。 引入适当的激励措施可以激发员工的学习意愿，而让高管团队走在变革的前沿至关重要。如果数据副总裁仍然以仪表盘交付量和工单解决率来衡量团队绩效，那么无论技能提升计划的质量如何，最终都将以失败告终。 责任归属：当人工智能出错时，谁该负责？ 这是大多数 GenBI 实施项目在出现问题之前都会回避的治理问题。但这个问题无法回避。 当业务用户向 GenBI 平台询问“我们上季度的转化率是多少？”却得到错误答案，并据此采取行动时，谁该为此负责？不是人工智能，也不是平台供应商。责任在于拥有生成该答案的语义定义的人。或者，如果没有人负责，那么责任就在于允许未经监管的人工智能输出结果传递给决策者的数据负责人。 这才是所有权真正发挥作用的地方，而不仅仅是激励作用。 语义层中的每个指标都需要一个负责人。该负责人负责： 业务定义的准确性 对支撑它的 SQL 进行验证 随着业务发展，需要定期审查该定义。 输出错误时的事件响应 这并非官僚主义，而是确保大规模部署 GenBI 系统可信度的最低限度治理结构。人工智能治理需要透明度、审批门槛和决策监控——这些措施确保人工智能代理以负责任的方式运行，与现有 BI 系统无缝集成，并交付可衡量的业务成果。 实际上，情况如下： 指标注册表：一份动态文档（或者更准确地说，它本身就是一个受监管的数据产品），它将语义层中的每个指标映射到所有者、定义、上次验证日期以及负责签署定义的业务利益相关者。 语义审查频率：每月或每季度，由审核员审查使用率最高的指标，根据当前的业务实际情况验证其定义，并标记偏离最初意图的指标。 查询审计跟踪：GenBI 的每个输出都可追溯到生成它的语义定义——这不仅便于调试，还能满足受监管行业和财务职能部门所需的审计置信度。 在需要之前就构建好这一治理层的团队将赢得信任。而在事件发生后才构建的团队则需要花费数月时间才能恢复信誉。 衡量投资回报率：数据领导者需要的框架 大多数数据转型项目在第二年就夭折的原因并非技术故障，而是无法用首席财务官和首席执行官能够理解的方式阐明投资回报率。 “我们减少了分析师的工作量”不是一个商业案例。“我们在保持员工人数不变的情况下，将可决策范围扩大了5倍”才是。 以下是我用来衡量 GenBI 转型效果的 ROIC 框架： 一支中等规模的分析团队（8-12人）预计在12个月内总共需要投资30万欧元至60万欧元，其中包括过渡期间的生产力下降。 三个值流： 第一部分：分析师能力的恢复 追踪转移到自助服务的重复性查询百分比。如果您的团队目前每月处理 200 个临时请求，而自助服务吸收了其中 70%，那么您就释放了相当于 2-3 名分析师全职员工的产能。这些产能可以重新部署到语义层构建和 AI 产品开发中——从而实现收益的倍增，而不是仅仅通过裁员来获取。 第二部分：决策速度和质量 一项针对 500 家公司的 2025 年研究表明，智能人工智能系统可将任务完成时间缩短 34%，并将资源利用率提高 14%。对于那些洞察延迟会直接影响收入的业务职能——例如定价决策、营销活动优化和客户维系措施——这种时间缩短会带来可量化的损益影响。请与您的首席财务官合作，将决策延迟缩短一天所带来的收入与最具价值的应用场景挂钩。 第三部分：数据消费者规模 旧模型的扩展是线性的：增加一名分析师，活跃数据用户数量也会相应增加。新模型的扩展是指数级的：构建一个完善的语义层，就能吸引数百名活跃用户。将每周/每月活跃数据用户数 (WAU/MAU) 作为核心指标进行跟踪。如果您的团队目前服务于 50 位活跃数据用户，而 GenBI 层在 12 个月后服务于 250 位用户，那么您的每次洞察成本计算的分母就降低了 5 倍。这就是其商业价值所在。 ROIC 计算（示例）： 第一年投资：450,000 欧元； 分析师产能回收：180,000 欧元（重新部署 3 名全职员工）； 决策速度价值：200,000 欧元（保守估计，主要用例的延迟降低）； 消费者规模价值：120,000 欧元（避免了未招聘分析师的成本）； 第一年总回报：500,000 欧元； 第一年投资回报率：11% ；第二年（复利增长）： 持续投资：150,000 欧元（平台 + 维护）； 回报（扩展层）：650,000 欧元；第二年投资回报率：330%+ 第一年的投资回报率并不高——这对于基础设施投资而言属于正常现象。能够带来高投资回报率的团队从一开始就注重价值创造，而非为了学习而学习，并且着眼于整体转型，而非仅仅关注单一用例。第二年的回报体现了构建完善的语义层的复利效应。第一年标注的每个指标在第二年都无需任何维护成本。第二年新增的每个数据使用者也无需占用额外的分析师资源。 你应该和你的首席财务官谈谈：不是“我们需要为人工智能工具制定预算”，而是“我们正在构建一个智能基础设施，为更多决策者提供服务的边际成本接近于零”。 分析师现在需要做什么 如果你是以分析师而非领导者的身份读到这里——那么这一部分就是为你准备的。 我所描述的组织架构重塑并非假设，而是已经在一些快速发展的组织中实施。能够展现适应能力而非仅仅具备技术能力的专业人士正变得不可或缺——沟通能力、利益相关者管理能力和数据叙事能力正日益与硬技能一起出现在职位描述中。 能够在这种转型中脱颖而出的分析师都具备一个共同的特质：他们不把SQL知识视为可按需部署的个人技能，而是将其视为需要编码、管理和扩展的机构知识。这种转变的重点在于从“做事”转向“构建能够执行操作的系统”。 具体而言： 立即开始编码。提取过去 90 天的查询记录。针对每个重复出现的指标，编写结构化的注释——包括业务问题、精确定义、常见误解以及经过验证的 SQL 语句。不要等到公司强制要求才开始。这是你的作品集，它能在正式设立语义注释员职位之前就展现你的相关技能。 学习工具，而不仅仅是概念。在个人环境中搭建 Vanna 或 Wren AI 系统。向它输入你标注过的查询。测试它。找出它的问题所在。理解它在哪里失败以及失败的原因——因为这些失败总是源于文档的缺失，而弥补这些缺失正是语义策展人的核心工作。 重新定位你对利益相关者的价值。如果分析师说“我来解答你们的数据问题”，那么他很容易受到攻击。但如果分析师说“我管理的系统能够可靠地解答你们的数据问题”，那么他就不会那么容易受到攻击。这种重新定位不仅仅是语言上的改变——它要求你真正去构建这个系统。但这种框架对于领导层如何看待你在转型过程中的角色至关重要。 要勇于承担责任。指标所有权——即作为业务定义准确性的指定负责人——是一种新型的职业责任。它比编写仅供自己审核的查询语句更具风险性。要积极应对。那些承担情报层责任的分析师，将成为组织不可或缺的人才。 窗口是有限的 只有31%的领导者预计能够在六个月内评估人工智能投资的回报率——这意味着大多数人仍处于试验阶段，开展试点项目，观察市场反应。这就是机会窗口。 大多数组织的语义层都是空的。查询库缺乏文档。业务定义只存在于人们的脑海中。这不是一个可以最终解决的问题。对于那些现在就采取行动的领导者和分析师来说，这是先发优势。 到 2027 年，数据功能将具备受管控的、全面的语义层——构建在 GenBI 基础设施之上，服务于数百名非技术决策者，并具有可追溯的投资回报率——这将与那些在确定性之前才采取行动的竞争对手在结构上形成差异。 确定性尚未到来。在智能体人工智能时代蓬勃发展的组织，都是在市场迫使他们做出选择之前，就决定主动出击的组织。 现在你就可以做出决定了。问题是，你是否愿意做出决定。 来源（公众号）：数据驱动智能

龙石数据中台 V3.8.6 版本发布，升级数据集成、治理、共享与监控能力，优化组件操作逻辑，放开标准独立管理，完善 API 配置，新增主机服务监控与多场景资源组管理，全面提升平台稳定性与易用性。

针对SAP物料主数据中高频出现的评估类错误、物料组分类错误、HS Code分配错误及描述不规范问题，需构建"规则引擎+AI模型+外部数据验证"三位一体的治理体系。以上案例显示，AI技术已实现物料主数据错误率降低至1%-3%、运营成本下降30%-50%的突破。 通过NLP算法识别乱码物料（如"螺丝_001"与"LS-01"的语义相似度计算），结合文本（MAKTX）、图像（技术图纸）、结构化数据（MR AI 进行物料主数据编码规则学习训练。 一、核心场景与痛点分析 SAP物料主数据管理挑战 数据质量问题 字段值错误（如单位错误、分类错误） 重复数据（同一物料多版本编码） 描述信息非标准化（如“螺丝_Φ5” vs “螺钉5mm”） 规则验证效率低 人工校验耗时（需核对30+字段规则） 复杂关联规则难以覆盖（如物料组与工厂的依赖关系） 动态规则维护难 新增业务规则需手动编码实现 历史数据规则追溯困难 二、DeepSeeker AI赋能方案 1. 智能数据清洗与补全 （1）技术实现 自然语言处理（NLP）：解析物料描述字段，提取关键参数（如尺寸、材质）python # 示例：描述标准化模型 from transformers import pipeline nlp=pipeline("ner", model="deepseek/ner-material") text="不锈钢螺丝_Φ5x20mm" entities=nlp(text)#输出:{'material': '不锈钢', 'type': '螺丝', 'diameter': '5mm', 'length': '20mm'} 知识图谱补全：基于行业标准库（如ISO标准）自动填充缺失字段 异常检测：利用孤立森林算法识别异常值（如超出合理范围的采购价） （2）SAP集成 开发ABAP接口调用AI服务，在ME11/MM01事务代码界面实时提示修正建议 2. 规则自动化挖掘与验证 （1）规则发现引擎 关联规则挖掘：通过Apriori算法发现字段间隐含关系python # 示例：挖掘物料组与单位的关联规则 from mlxtend.frequent_patterns import apriori frequent_itemsets = apriori(df, min_support=0.1, use_colnames=True) # 输出: {物料组='原材料' → 单位='千克' (置信度98%)} 时序规则检测：识别有效期冲突（如旧物料未失效时创建新编码） （2）动态规则库构建 将AI发现的规则自动转换为SAP可执行的校验逻辑（IDoc/BDC脚本） 3. 持续学习与优化 反馈闭环设计 用户修正记录作为训练数据回流至模型 每周自动生成《规则有效性报告》，标注需人工确认的模糊规则 版本化管理 规则库与模型版本绑定，支持历史数据追溯验证 三、实施路径 阶段1：数据准备与模型训练（4-6周） 抽取SAP中100万+物料历史数据（MATNR、MAKTX、MEINS等） 标注典型错误样本（如单位错误、分类错误）-- AI 人工智能标注（各工厂) 训练初始模型：使用DeepSeek-7B基础模型进行微调 评估指标：字段补全准确率≥95%，异常检测召回率≥90% 阶段2：试点验证（2-3周） 选择3类物料（原材料、半成品、成品）进行测试 在SAP沙箱环境部署AI插件，对比验证： 指标 传统方式 AI赋能后 提升幅度 数据录入效率 15分钟/条 8分钟/条 47% 首次校验通过率 68% 92% 35% 阶段3：全量推广与优化（持续迭代） 部署至生产系统，覆盖所有物料类型（50+分类） 建立监控看板，实时显示：数据质量指数（DQI），规则命中率，用户采纳建议率 四、收益预测 维度 传统模式 AI赋能后 价值点 人力成本 5人专职校验团队 1人+AI监控 年节省人力成本≈200万元 错误处理时效 平均3天发现错误 实时拦截 减少库存错误损失≈500万元/年 规则覆盖度 静态规则300条 动态规则库1200+条 合规风险降低80% 五、风险控制 数据安全 采用私有化部署模式，通过RFC连接SAP与AI服务器 敏感字段（如价格）进行脱敏处理 模型可解释性 提供决策依据展示（如高亮字段修正原因） 设置人工复核阈值（置信度<90%时强制人工确认） 用户接受度 在SAP界面设计「AI建议」与「人工否决」双路径操作 开展「AI助手技能大赛」提升用户参与度 针对SAP物料主数据中高频出现的评估类错误、物料组分类错误、HS Code分配错误及描述不规范问题，需构建"规则引擎+AI模型+外部数据验证"三位一体的治理体系。以下是具体提升方案： 一、评估类错误治理方案 1. 智能校验矩阵搭建 python # 评估类与会计视图逻辑验证模型 def validate_valuation_class(mat_data): # 从SAP获取关联规则（物料类型+工厂+用途） rules = get_sap_rules('MBEW') # 实时调用DeepSeeker模型预测 pred_class = deepseek_model.predict(mat_data['MTART'], mat_data['WERKS']) # 交叉验证 if mat_data['BKLAS'] notin rules[pred_class]['allowed_classes']: return { "error_type": "评估类冲突", "suggestion": f"建议调整为{pred_class}对应评估类{rules[pred_class]['default_class']}", "confidence": 0.92 } 2. 动态知识库建设 数据源整合：集成财务系统（如CO模块成本要素数据） 抓取历史调整记录（TCODE: MM02修改日志） AI能力注入：使用Graph Neural Network构建物料-工厂-评估类关系图谱 开发异常交易模式检测模型（检测价格异常波动） 二、物料组分类优化方案 1. 多模态分类模型 python # 物料组智能分类流程 classification_pipeline = Pipeline([ ('text_feature', TextTransformer(fields=['MAKTX','BRGEW'])), # 提取文本特征 ('image_processor', VisionModelAdapter(model='resnet50')), # 处理技术图纸 ('ensemble',StackingClassifier([('xgb',XGBClassifier()),('deepseek', CustomDeepseekModel()) ])) ]) # 输出Top3候选物料组及置信度 2. 分类纠错机制 冲突检测规则：sql /* 物料组与基本单位逻辑校验 */ SELECT MATNR FROM MARA WHERE MATKL IN ('RAW','PACK') AND MEINS NOTIN ('KG','G','L'); -- 触发条件：包装材料单位应为KG/L，否则报警 历史数据清洗：对错误分类物料进行聚类分析（DBSCAN算法） 生成《分类迁移建议报告》自动推送至MDG工作台 三、HS Code精准匹配方案 1. 海关大数据融合 数据源 集成方式 更新频率 海关总署商品归类决定 API实时查询 即时 跨境同行申报数据 脱敏数据采购 月度 RPA爬取各国税则库 自然语言解析 季度 2. 智能归类引擎 python # HS Code多维度匹配算法 def hs_code_matching(text, img=None): # 文本特征提取 text_embed = deepseek_text_model.encode(text) # 图像特征提取（技术图纸/实物照片） img_embed = deepseek_vision_model.encode(img) if img elseNone # 混合检索 results = vector_db.search( query=text_embed, filter={"chapter": {"$in": predict_chapter(text)}} ) return rank_results(results, img_embed) 验证机制：申报风险预警：比对同类物料历史申报记录差异 逻辑校验：验证HS Code与原产地、计量单位关联性 四、描述标准化工程方案 1. 命名规则智能生成 python # 动态命名规则推导 def generate_naming_rules(matkl): # 从历史规范描述中提取模板 samples = get_standard_descriptions(matkl) # 使用序列标注模型识别关键要素 entities = ner_model.predict(samples) # 生成BNF范式规则 returnf"{材质}{类型}_{规格参数}{表面处理}" # 示例输出规则："不锈钢六角螺母_M8-1.25_镀锌" 2. 实时纠错助手 SAP GUI集成：abap * 在MM01事务代码界面增加AI校验弹窗 DATA(lv_suggestion) = zcl_deepseek_ai=>get_description_suggestion(im_maktx). IF lv_suggestion IS NOT INITIAL. CALL FUNCTION 'POPUP_TO_CONFIRM' EXPORTING text_question = 'AI建议修正描述为:' && lv_suggestion. ENDIF. 智能补全功能：输入"304螺"自动补全"304不锈钢内六角圆柱头螺钉" 图片扫码自动生成描述（OCR+图像识别） 五、全流程控制体系 1. 四层质量关卡 关卡 控制点 技术手段 录入层 ME11/MM01界面实时校验 嵌入式AI插件 审核层 MDG工作流审批 规则引擎+差异高亮 监控层 每日数据质量扫描 自动生成DQ报告（错误TOP10） 追溯层 历史版本对比分析 变更影响度模型 2. 持续改进机制 错误模式分析：python # 错误根因分析算法 error_patterns = [] for error in error_logs: # 提取上下文特征 context = extract_context(error) # 聚类分析 cluster = dbscan.fit_predict([context]) # 生成改进建议 suggest = causal_inference(error, cluster) error_patterns.append(suggest) 知识沉淀：季度更新《错误案例库》（含典型错误场景） 自动化生成《字段维护手册》更新版本 六、实施效果预测 指标 改进前 目标值 达成路径 评估类错误率 12% ≤1% 实时校验+财务规则库动态更新 物料组分类准确率 78% ≥98% 多模态模型+季度规则校准 HS Code一次通过率 65% ≥95% 海关大数据融合+智能归类引擎 描述标准化率 60% 100% 命名规则引擎+实时纠错 主数据维护人效 15min/条 5min/条 智能补全+自动化校验 七、关键成功要素 跨系统数据贯通 打通PLM（物料属性）、海关系统（HS规则）、财务系统（评估类逻辑） 混合规则策略 硬规则（系统强制校验）与软规则（AI建议）分层控制 用户赋能设计 在SAP界面增加"AI教练"功能（F1查看字段维护指南） 灰度发布机制 新模型先在10%物料范围试运行，通过A/B测试验证效果 建议建立数据治理专项小组，由主数据、IT、财务、关务部门组成联合团队，每月进行跨部门数据质量评审。技术实施时可优先从错误率最高的原材料类物料切入，快速形成示范效应。 八、技术趋势总结 多模态技术融合：结合文本（MAKTX）、图像（技术图纸）、结构化数据（MRP参数）进行综合判断 动态规则进化：采用强化学习机制，使校验规则随业务变化自动迭代（如新物料类型识别） 治理即服务（DGaaS）：企企通、筑龙等厂商提供云端AI清洗服务，支持API对接SAP/ERP系统 实践建议 分阶段实施：优先从高价值物料（如占采购额80%的A类物料）切入，快速验证ROI 人机协同设计：设置置信度阈值（如<90%时强制人工复核），平衡效率与风险1 知识资产沉淀：将清洗过程转化为可复用的规则模板（如化工行业PH值校验规则包） 以上案例显示，AI技术已实现物料主数据错误率降低至1%-3%、运营成本下降30%-50%的突破。建议企业优先评估自身数据成熟度，选择适配的AI治理路径。 来源（公众号）：数据驱动智能

文 | 中国科学院院士、复旦大学上海数学中心主任 李骏 复旦大学上海数学中心研究员 王天栋 当前，人工智能正加速赋能经济社会发展的各个领域，推动实体经济和数字经济深度融合，成为新一轮科技革命和产业变革的核心驱动力。我国数据资源丰富，产业体系完备，应用场景广阔，具备发展人工智能的重要基础。《全国数据资源调查报告（2025年）》（下文称《报告》）显示，2025年全国数据生产总量达52.26泽字节，同比增长27.28%；全国数据存储总量为2.53泽字节，同比增长21.05%；用于人工智能训练和推理的数据总量达199.48艾字节，同比增长42.86%。随着“人工智能+”深入推进，高质量数据供给正从规模扩张转向面向场景应用和价值转化的体系化能力建设，成为支撑人工智能产业高质量发展的关键基石。 一、人工智能驱动数据从规模扩张转向高质量供给 人工智能技术的快速迭代正重塑数据资源的价值导向和发展路径。在信息化发展前期阶段，数据主要服务于业务记录、统计分析、信息查询和流程管理等基础需求。进入大模型和智能体加速落地的新阶段后，数据需支撑模型预训练、场景化推理、多任务执行和动态迭代优化等多重目标。这一转变意味着高质量数据供给的评价标准，已不再单纯以资源规模大小为核心，而是更加注重数据的组织形态是否能够被模型高效理解、灵活调用、可靠验证和持续迭代，实现从“数据资源”到“模型可用资产”的价值跃迁。 智能体技术的普及进一步重构了数据生产和利用的全流程模式。与传统信息系统“用户发起请求－系统被动响应”的运作逻辑不同，数据使用方式从“被动查询”逐步走向“主动协同”。数据既是智能体完成任务的输入要素，也是智能体运行过程中产生新知识、积累新经验、形成新反馈的载体。这种双向互动关系要求高质量数据供给必须更加贴近应用场景和治理需求，在现有数据资源建设成果的基础上，进一步强化动态更新能力、反馈回流机制和闭环优化体系，推动数据供给与人工智能应用形成相互促进的良性循环。 词元调用量的爆发式增长为观察数据价值释放进程提供了全新的量化维度。词元作为大模型处理信息的基本单位，也是人工智能服务被调用、被计量和被商业化的载体。《报告》显示，2025年全年词元调用量约达21100万亿。公开数据显示，我国日均词元调用量已从2024年初的约1000亿增长到2025年底的约100万亿，在2026年3月突破140万亿关口。词元调用量的指数级增长，反映出人工智能应用正在从试点探索走向更高频、更广泛的产业落地，也体现出数据集供给、模型能力提升和应用需求拓展之间正在形成紧密联动的正向循环。 二、以重点行业场景牵引高质量数据集建设新格局 场景需求是高质量数据集建设的重要导向。《报告》显示，2025年我国高质量数据集数量超11万个，总数据量超908拍字节，同比分别增长61.13%和142.58%。不同行业、不同场景下的业务逻辑、风险边界和决策机制存在显著差异，以具体场景需求牵引数据供给体系建设，能够有效提升数据开发利用的针对性，避免低水平重复建设和资源浪费，推动数据资源配置效率最大化。 政务服务具备率先形成高质量数据供给示范场景的先天优势。《报告》显示，2025年公共数据开放数据量和授权运营数据量同比分别增长31.71%、53.96%，公共数据带动各行业数据融合应用的效应正加速显现。政务数据具有权威性高、连续性强等特征，是推进国家治理体系和治理能力现代化的重要基础资源。围绕政策咨询、事项办理、热线分派、基层治理、城市运行和公共安全等典型治理任务，推动政策文本、办件记录、群众诉求、事件处置和结果反馈等多源数据的协同利用，推动公共服务模式从“人找政策”向“政策找人”转变，实现更加主动、高效、便捷的公共服务供给。 实体经济领域是高质量数据集建设的关键应用场景。电力、交通、物流、农业等传统行业积累了海量的设备运行数据、生产工艺数据和场景应用数据，是人工智能技术赋能实体经济的核心切入点。以能源电力行业为例，负荷精准预测、设备智能巡检、故障提前预警和源网荷储协同调度等典型场景，对实时运行数据、设备状态数据、气象环境数据和历史处置数据的质量都提出了极高要求。围绕具体任务建设行业专题数据集，有效提升能源系统调度效率和运行安全水平。 三、健全要素转化机制促进数据要素价值释放 一是强化任务牵引的数据集建设机制。围绕政务服务、能源运行、金融风控、交通治理、工业制造、医疗健康等重点领域，建设一批面向人工智能训练与场景应用的专题数据集，明确服务对象、应用任务、更新机制和评测标准。在数据质量评价体系中，除传统完整性、准确性、时效性等指标外，同步纳入模型适配性、场景覆盖率、标注一致性、反馈回流能力等价值导向指标，推动数据供给从一次性交付向动态更新、持续优化转变，以优质数据资产为数据要素价值释放筑牢基础。 二是构建安全可信的数据流通生态。引导数据交易所（中心）、数据流通服务平台企业、数据商等三类市场主体各有侧重、协同发展，形成错位互补的市场格局。依托国家数据基础设施，提升数据发现、供需匹配、授权使用、定价交易的全流程效率；探索人工智能技术与数据流通交易的技术路径和机制设计，进一步降低流通成本、提高交易效率，以高效畅通的流通通道加速数据要素价值释放。 三是培育专业化数据服务产业体系。数据要素价值释放依托覆盖采集、清洗、标注、合成、治理、运营和安全服务的全生命周期专业支撑。加快培育分工清晰、协同高效的专业化数据服务产业体系，加强各环节、各主体间协同创新，全面提升数据资源开发利用的标准化、专业化水平，以成熟产业生态推动人工智能全方位赋能千行百业，为数据要素价值持续释放提供长效保障。 总体来看，我国拥有数据资源规模优势和应用场景丰富的双重优势，具备推动数据资源开发利用与人工智能创新发展互促共进的良好条件。面向下一阶段发展，应加快推动高质量数据集建设与行业场景深度融合，健全要素转化机制、畅通要素流通渠道、完善服务产业生态，全方位促进数据要素价值释放，为数字中国建设和经济社会高质量发展提供坚实支撑。 来源（公众号）：国家数据局

很多人第一次看到 OpenClaw 的架构图时，会被它复杂的分层结构吸引住——网关层、插件层、记忆系统、Agent 运行时……但如果继续往下看，往往会在一个词上停下来：Harness。 说实话，Harness 不是一个容易讲清楚的概念。因为它本身就不是一个具体的东西，而是一组设计思路的集合。如果非要给它一个最简洁的定义，我更愿意这么说：Harness 是 AI 应用面向大模型的结构化运行壳，它决定了模型该看到什么、允许做什么、做错了怎么纠正。 但这句话还是太抽象。 今天我们想基于 OpenClaw 出发，结合 OpenAI 和 Anthropic 两篇原文的核心观点，把 Harness 的真实面貌拆开给你看。 Harness 在 OpenClaw 里长什么样 先说 OpenClaw。 如果你研究过 OpenClaw 的架构，会发现它本质上是一个 Gateway-First 的项目。 它上接多个渠道入口——飞书、WebChat、CLI、Telegram，下连会话路由、插件扩展、记忆系统和运行时。 中间那条统一的执行主链路，靠的就是 Harness 层。 具体来说，OpenClaw 的 Harness 承担了这样几件事： 它负责组装 Prompt，把 System Prompt、Skills Prompt、文档、Bootstrap 文件、运行时信息全部拼成最终给模型的提示词。它挂载 Tools 和 Skills，让模型能够调用外部能力。 它接入 Memory 系统，在合适的时机把记忆检索的结果注入上下文。 它处理策略与安全限制，决定模型的调用边界在哪里。 最后，它通过 Provider Adapter 与不同厂商的 LLM API 交互——无论是 Claude、GPT 还是其他模型，Harness 把这些差异屏蔽掉了。 换句话说，没有 Harness 基础理论，OpenClaw 就只是一个“把文本丢给模型”的简单代理。 有了 Harness，它才真正变成了一个可扩展、可控制、可落地的 Agent 运行容器。 但这还是从 OpenClaw 自身的角度在讲。 如果我们把视野拉开，会发现 Harness 这个词在 AI 行业里早就不是 OpenClaw 的专属用语。 它正在变成一个通用概念——描述的是如何给 AI 模型搭建一个完整的运行环境，让它不只是在做单轮问答，而是能够持续地、可靠地完成任务。 为什么 Harness 这个概念突然变重要了 要理解 OpenClaw 和 Harness 的关系，还需要理解另一个背景：模型本身已经足够强，但大家的痛点正在转移。 Anthropic 之前发过一篇关于 Harness 设计的长文，里面有一组实验数据，我认为是理解这个问题最好的切入点。 他们用同一句 Prompt——“做一个 2D 复古游戏编辑器”——让同一个模型跑了两次。 第一次，单 Agent，没有任何外部辅助。 跑了 20 分钟，花了 9 美元。 打开之后，界面有了，编辑器有了，看上去功能都做了。 但真正点进去，核心游戏功能是坏的。角色放上去了，键盘没反应。代码层面，实体定义和运行时之间的接线根本没接通。 看起来像是完成了，其实什么都没完成。 第二次，基于 Harness 方法论 ——规划器展开需求、生成器按 Sprint 逐步实现、评估器用 Playwright 跑页面做 QA。 同一个模型跑了 6 个小时，花了 200 美元。 产出多了不止一个量级：精灵动画、行为模板、音效系统、AI 辅助关卡生成、游戏导出和分享链接，全部做出来了。 最关键的是，你真的能控制角色跑和跳。 成本差了 20 多倍，但第一次那 9 美元的产出，严格说不算产出——因为核心功能是废的。 模型没换，Prompt 没换。 变的只是它跑在什么系统里。 这个对比说明了一个很简单的事实：模型的能力不等于应用的产出。 中间差的那一层，就是 Harness。 很多人以为只要选个最强的模型、调调 Prompt，应用效果就能上来。 但实际跑过复杂任务的人都知道，这套玩法的天花板很低。真正把效果拉开差距的，是 Prompt 之外的那套运行环境——任务怎么拆、谁来验收、做错了怎么修正。 这些问题不解决，模型再强也只能在原地打转。 Harness 至少在管四类事情 从那组对比往下拆，你会发现单 Agent 和完整 Harness 之间，至少差了四类东西。 第一类：给模型看什么。 单 Agent 只有一句 Prompt。完整 Harness 里，规划器会先把一句话需求展开成详细的产品规格，每个 Sprint 还有专门的契约文档——生成器和评估器先谈好“做到什么算完成”，再动手。 这不是多给一点信息，而是把需求从模糊变得可执行。 第二类：允许模型做什么。 单 Agent 自己决定所有事。 完整 Harness 里，职责被拆开了——规划、实现、验收三件事不该混在同一个脑子里。 Anthropic 把这个拆成了 Planner、Generator、Evaluator 三个角色，各司其职，互相制约。 第三类：怎么判断它做得对不对。 单 Agent 自己评价自己。 但模型在评估自己产出的时候，往往会自信地给出偏正面的评价，即使在人类看来质量只是一般。 所以完整 Harness 里，评估器是独立的，它真正去跑页面、点按钮、看结果，而不是读代码打分。 第四类：出错之后怎么修。 单 Agent 犯了错可能完全意识不到。 完整 Harness 里，Sprint 不通过就打回去，反馈信号具体到“这个函数存在但没被正确触发”。 把这四类事情合在一起，Harness 的轮廓就清晰了：它是一组控制问题的总称，回答的是模型该看到什么、允许做什么、做完之后谁来验、跑偏了怎么纠正。 Harness 内部的三层结构 如果继续往下拆，把 OpenAI 和 Anthropic 的两篇原文放在一起对比，会发现 Harness 内部至少有三层——知识层、约束与流程层、反馈与运行时层。 这三层各有侧重，但彼此支撑，缺一不可。 知识层解决的是模型该读什么、团队经验放哪里、哪些规则必须显式可见。 OpenAI 在文章里讲过一个很典型的坑：他们最早试过写一份巨大的 AGENTS.md，把所有规则、约定、指引全塞进去。 结果很快撞了墙——上下文是稀缺资源，大文件会挤掉真正相关的信息；所有东西都标成重点，最后等于没有重点；文档很容易腐烂，而且没法做机械检查。 后来的做法是把 AGENTS.md 改成了一个内容目录，大约 100 行，只告诉 Agent 去哪里找什么。 真正的知识库被拆进结构化的 docs/ 目录里——设计文档、产品规格、执行计划、技术债追踪，全部版本化地存在仓库里。代码仓库本身变成了记录系统。 这里有一个很关键的判断：对 Agent 来说，看不见的知识就等于不存在。 Slack 里的讨论是知识，Google Docs 里的共识也是知识，某个资深工程师脑子里的隐性判断也是知识。但只要它没被编码进仓库，对 Agent 来说就像从未发生过。 知识层不补，模型永远只能靠临场发挥。 约束与流程层解决的是任务怎么拆、哪些步骤必须先发生、哪个角色负责什么、什么情况下该切换阶段。 Anthropic 对这一层的处理最有代表性。 他们的做法是把系统拆成 Planner、Generator、Evaluator 三个角色。Planner 负责把模糊需求扩成详细规格，而且刻意只聚焦产品上下文和高层设计，不去规定细粒度的技术细节——因为他们发现，如果规划器一开始就在实现细节上犯了错，错误会级联传导到下游所有实现中。 Generator 负责真正实现，按 Sprint 逐个做 feature，每个 Sprint 开始前要和 Evaluator 谈好一份契约——做到什么算完成，用什么标准验收。 Evaluator 负责验收，它不是读代码打分，而是真正去跑。 这个结构表面上像多 Agent 编排，但背后的工程含义更重要：原本混在一个模型里的几种职责，被拆成了不同的流程角色。这种拆分不是为了并行更快，而是为了别一边生成一边自我表扬。 Anthropic 还补了一个很关键的点——context reset。 长任务里光靠原地压缩历史还不够，有些模型会随着上下文越来越满，开始出现“提前收尾”或“失去一致性”的问题。 所以他们会定期清空上下文窗口，重新启一个新会话，再通过结构化工件把状态交接给下一个 Agent。这个设计听上去笨，但很工程。 反馈与运行时层解决的是模型做完之后，谁来告诉它对不对。 这是 Harness 里最容易被低估的一层。很多人对 Harness 的理解停在“给模型配上工具”，但工具本身不是反馈，工具只是让模型有了手，反馈是让它有了感官。 Anthropic 文中让我印象最深的地方就在这里。 他们发现真正拉开差距的，不只是让模型多做一轮，而是给它一个足够挑剔、能接触真实环境的 Evaluator。 这个 Evaluator 会用 Playwright 真正去跑页面、点按钮、看行为、发现没接上的地方，再把这些问题作为反馈交给 Generator。 原文里列了几个 Evaluator 实际发现的问题：矩形填充工具的 fillRectangle 函数存在但没被正确触发；删除实体只设置了 selectedEntityId 但没设置 selection；FastAPI 路由顺序写反导致 reorder 被解析成整数返回 422。这些不是“看代码打分”能发现的问题，它们只有在真正跑起来、点进去之后才会暴露。 OpenAI 对反馈层的做法方向一致，但路径不同。 他们把 Chrome DevTools 协议接入 Agent 运行时，让它能截图、查 DOM 快照、驱动页面导航；把日志、指标、追踪做成本地可观测性堆栈，Agent 可以直接用 LogQL 查日志、PromQL 查指标。 做的不是“再多给点说明”，而是把应用的可观察性和可验证性直接接进 Agent 的工作回路。 结语 回到最开头的问题：OpenClaw 和 Harness 是什么关系？ 现在可以给一个更清晰的答案了。 OpenClaw 是一个 Gateway-First 的 Agent 运行时框架，而 Harness 是它面向大模型的那一层方法论。 如果你正在做 AI 应用相关的事情，花时间想清楚 Harness 这层该怎么搭，可能比纠结用什么模型、调什么 Prompt 更有价值。 差距往往不在模型，在系统。 来源（公众号）：臻成AI大模型

概念鸿沟：为何大语言模型在数学推理上举步维艰 大语言模型（LLMs）已展现出令人惊叹的能力，能够解决曾被认为远超其能力范围的数学问题。它们可以解答竞赛级别的题目并执行复杂的数值计算。然而，仔细观察便会发现一个关键弱点：许多LLMs擅长程序性的模式匹配，但在真正的概念理解方面却有所欠缺。这一现象常被描述为 “定义-应用鸿沟”。 一个LLM或许能够完美地复述数学定理，如有理根定理，但在正确应用该定理解决问题时却会失败，尤其是当问题的表述方式稍有不寻常时。如研究中的图1所示，一个最先进的模型可以正确陈述该定理，但在将其应用于一道分子和分母角色被互换的多选题时，仍然会出错。这表明模型的解题过程往往固守于僵化的、基于启发式的模式，而非由对底层概念的灵活理解所引导。 流行的训练方法，如带可验证奖励的强化学习（RLVR），加剧了这一鸿沟。这类流程通常根据最终答案的正确性来奖励模型。虽然这能提升性能，但奖励信号过于粗糙。它并未告诉模型应使用哪个概念、在推理过程的何处应用它，或如何正确使用它。结果，模型学会了优化其搜索启发式方法并复用熟悉的解题模板，但未必学会了概念本身。这使得它们在面对需要真正概念推理的干扰和新问题时显得脆弱。 引入CORE：面向概念的强化学习 为应对这一根本性挑战，研究人员开发了 CORE，一种新颖的强化学习框架，旨在弥合数学推理中的定义-应用鸿沟。CORE的核心思想是在训练过程中，将抽象的数学概念转化为直接的、可控的监督信号。 CORE不仅奖励正确的最终答案，还提供细粒度的概念监督，以强化整个推理路径。其目标是教会模型不仅知道正确答案是什么，更要理解为什么它是正确的，通过将解决方案锚定在相关的数学原理上。通过这种方式，CORE鼓励模型超越表面的模式匹配，发展出更稳健的概念能力。 CORE框架的关键优势之一在于其通用性。它被设计为与算法和验证器无关，这意味着它可以与标准的策略梯度强化学习算法（如GRPO或PPO）集成，而无需改变模型架构。这使得CORE成为一个实用且可推广的工具，用于增强各种LLMs的数学推理能力。 CORE如何运作：从教材整理到概念对齐的测验 CORE的基础是一个精心整理的、高质量的数据集，该数据集明确地将数学概念与相关练习联系起来。该过程始于一个提供结构化、逻辑化课程大纲的规范来源。 从规范教材进行数据整理 研究人员选择了一本经典教材《高等代数（第三版）》，主要基于两个原因。首先，它提供了全面的课程大纲，每个章节都介绍了核心概念定义（C），提供了说明性示例，并包含了主要测试该章节概念的概念对齐练习（E）。其次，通过将原始中文文本手动翻译成英文，研究人员显著降低了困扰许多现有英文语料库的训练数据污染风险。这一初步整理工作产生了236个概念文本以及超过700个相关示例和练习。 用于可扩展训练的综合概念探针 为创建更大、更直接的训练和评估信号，CORE引入了概念探针 的想法。这些是从教材的概念定义直接生成的有针对性的多选题测验。研究人员使用了一个强大的生成器模型来创建一个包含1200个测验的候选池。为确保质量并减少偏差，一个独立的、强大的评估器模型执行了严格的验证，将候选池筛选至1110个高质量测验。 这些概念探针构成了一项诊断实验的基础，该实验量化了概念鸿沟。如表1所示，当模型在“稳健评估”协议下进行评估时——即多选题选项的顺序被随机打乱——其性能急剧下降。例如，某个模型的准确率从超过70%降至50%以下。这提供了强有力的经验证据，表明模型依赖于浅层启发式方法，而非对底层概念的深层结构性理解。 为理解而训练：轨迹替换与正则化 在具备概念对齐数据的基础上，CORE采用了一种巧妙的强化学习方案来灌输概念理解。其核心机制是一个条件干预，该干预在模型表现出概念失败时（即针对某个问题生成的所有解决方案均不正确）精确激活。该过程在图2中可视化，并主要有三种变体。 CORE-Base：这是基础方法。模型使用标准RL算法直接在整理好的概念测验集上进行训练。它作为衡量仅在概念丰富数据上训练所带来的益处的基线。 CORE-CR（概念引导的轨迹替换）：此方法提供明确的纠正性反馈。当模型未通过测验时，CORE-CR进行干预： 检索与该测验相关的真实概念文本。 使用原始问题加上概念文本重新提示模型，以生成新的、“概念启动”的轨迹。 然后，随机用这些新的、概念引导的轨迹替换部分原始失败轨迹，并赋予它们一个增强的奖励：。 这直接激励模型学习概念与其正确应用之间的联系。 CORE-KL（概念引导的KL正则化）：此方法提供一种更隐式的、细粒度的信号。同样在失败时触发，它鼓励模型的标准推理过程与其更稳健的、概念启动的过程对齐。这是通过向RL目标添加一个前向KL散度损失项来实现的： 该损失本质上迫使模型在原始问题（）上的内部推理，忠实地模仿其在被明确给予指导概念（）时会遵循的过程。 这些变体共同提供了通过显式替换和隐式正则化将概念信号注入训练过程的互补策略。 检验CORE：跨基准测试的性能提升 实证结果有力地证明了CORE框架的有效性。使用CORE训练的模型不仅在内域任务上表现出持续且显著的性能提升，在一系列外域基准测试中也同样如此。 如表2所示，使用CORE变体训练的Qwen2-Math-7B模型相较于原始基线取得了显著提升。在内域的Textbook测试集上，使用CORE-KL时，准确率从46.4%跃升至55.7%。更令人印象深刻的是，这些提升具有泛化性。在明确测试定理应用的THEOREMQA基准上，准确率从34.6%上升至44.2%。在GSM8K、MATH和其他具有挑战性的数据集上也观察到了类似的改进。 进一步的实验证实，CORE的益处并不局限于单一模型。表3显示CORE是模型无关的，为不同的模型（如DeepSeek-R1-Distill-Qwen-1.5B、Qwen2.5-Math-1.5B和Llama-3-8B-Instruct）在基础版和指令调优版设置下均带来了一致的改进。 关键的是，消融研究验证了这些提升归因于CORE的独特机制。表5显示，仅使用随机奖励或在GRPO中增加候选解决方案的数量并不能复现这些改进。此外，一项在表6中详述的“自监督”实验（整个流程被限制在单一模型家族内）证明，CORE的有效性并不依赖于从优越教师模型进行知识蒸馏。 驱动学习的是概念引导干预的内在逻辑，而非外部专业知识。 超越模式匹配：在AI中培养真正的概念能力 CORE的成功为开发更强大、更可靠的AI系统指明了一条充满希望的道路。该框架不仅仅是提高准确率分数；它似乎诱导了LLMs处理数学问题方式的根本性“机制转变”。 对CORE训练模型成功而基线模型失败的问题进行分析，揭示了一个清晰的模式。如表4详述，在这些案例中超过半数（52.6%被归类为纯概念选择），CORE模型在其推理中明确调用并正确应用了目标数学概念，而基线模型则没有。 此外，CORE增强了LLMs的鲁棒性。在一项将无关的“干扰”概念附加到问题提示前的实验中，CORE训练的模型表现出显著更好的答案保持能力。图3中的性能曲线显示，CORE模型，特别是CORE-CR变体，对此类概念干扰具有更高的稳定性。 总之，CORE框架证明了将强化学习明确地建立在数学概念基础上，可以显著增强LLMs的推理能力。 通过超越粗糙的、基于结果的奖励，并提供细粒度的概念监督，CORE帮助模型从脆弱的模式匹配向真正的概念能力迈进。这项工作不仅为改进AI的数学推理提供了实用解决方案，也激励了在所有需要原则性、结构化推理的领域中对以概念为中心的训练进行更广泛的探索。 来源（公众号）：AISignal前瞻