针对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前瞻
《全国数据资源调查报告（2025年）》在第九届数字中国建设峰会上如约而至。翻开这份沉甸甸的报告，在满篇数据图表中，有三组数据特别亮眼，突出反映了我国数据要素化和人工智能发展取得的巨大进步。 52.26ZB VS 90%—企业成为数据生产的主力 报告显示：“2025年全国数据生产总量达52.26ZB，同比增长27.28%”“数据生产增量约九成来自企业数据”。 数据分析：相较于2024年41.06ZB的全国数据生产总量，2025年增长了11.2ZB，其中，企业数据生产量增长近10ZB。表明企业已成为数据生产的主力。 背后原因：企业大规模生产数据的背后，是过去一年来我国数据赋能千行百业和企业数智化转型取得重大进展的必然结果： 一是企业数据生产能力大幅提高。服务业、工业和农业的数据生产量分别为22.85ZB、8.53ZB和1.49ZB，占企业数据生产总量比例分别为68.13%、25.43%和4.44%。一方面表明数智化转型已在各行各业全面展开并加速推进，另一方面也表明各行各业的数智化发展水平不一，服务业的数智化程度最高，工业数智化程度次之，最后是农业数智化。 二是企业数智化转型速度明显提升。数据开发率是直接反映各行业数据开发利用程度的指标，数据开发率越高，表明数据治理加工、挖掘分析、融合应用的能力越强。国民经济行业大类中，软件和信息技术、科学技术、金融、制造、交通运输等5个行业数据开发率超30%，分别为34.36%、32.88%、32.61%、32.21%和31%，跨行业、跨领域数据融合应用不断深入。采矿、水电燃气、居民服务、批发零售业和教育等行业数据开发率紧随其后，分别为27.71%、22.7%、17.52%、16.35%和15.44%，数智化场景密集落地。住宿和餐饮、卫生和社会工作、农业、文体娱业、房地产、建筑业、水利环境公共设施业、租赁和商务服务等行业数据开发率低于15%，需求牵引作用日益凸显。 30% VS 31.71% VS 53.96%——公共数据资源开发利用成绩斐然 报告显示：“2025年全国一体化政务数据共享枢纽累计支撑调用超5500亿次，申请共享的数据集数量同比增长近30%”“全国公共数据开放数据量同比增长31.71%”“全国公共数据授权运营数据量同比增长53.96%”。 数据分析：相较于2024年全国一体化政务数据共享枢纽累计支撑调用超5400亿次，2025年已超5500亿次，对数据集的共享需求快速提升；2024年全国地市级以上开放数据量增长7.1%，2025年全国公共数据开放数据量爆发性增长31.71%；2024年公共数据授权运营刚刚起步，市级政府部门公共数据授权运营数据量是省级部门的2.53倍。2025年全国公共数据授权运营数据量同比增长53.96%，省级公共数据授权运营数据量同比增长54.17%。 背后原因：共享、开放和授权运营是公共数据开发利用的三种主要途径。2025年三种途径都出现了30%以上的爆发性增长，是制度供给端和市场需求端双向发力、相向而行的必然结果： 一是充沛的制度供给极大激发了公共数据供数动力。国家公共数据资源开发利用“1+3”政策文件的落地实施，《政务数据共享条例》《政务领域人工智能大模型部署应用指引》等政策法规出台，以及公共数据资源登记工作稳步推进等，在公共数据安全流通、产权、定价、交易等方面提供了实践指引，并支持鼓励政务领域推广使用政务大模型和智能体，极大激发了公共数据的供数动力，让更多的公共数据以共享、开放、授权运营等多种方式供出来。 二是繁荣的应用市场极大释放了公共数据用数活力。越来越多的金融、交通、医疗和教育机构利用公共数据开展业务。2025年，大多数银行、保险等金融机构充分利用社保、公安、工商、税务、海关等部门的公共数据，为个人和企业画像，构建用于银行、保险业务的个人和企业风控模型，极大提高业务的精准率。许多城市的公交公司通过整合公交车的实时GPS位置、站点客流刷卡数据、路况拥堵等公共数据，不仅可以向市民提供精准的到站时间预测，有效减少市民平均候车时间，还可以根据这些数据动态调整发车班次，降低车辆空驶率，实现智能调度公交和精准预测。许多城市基层疾病预防机构通过汇聚区域内医院的电子病历、社区卫生中心的慢病档案以及疾控中心的传染病报告数据，并融合就诊症状分析、药品销售等数据，自动挖掘异常聚集性病例，实现传染病早期预警，并指导医疗资源的精准投放。许多地方的教育管理部门通过综合运用公安部门的适龄儿童户籍数据、不动产登记中心的房产交易与居住信息，以及学校的教室和师资等承载能力，开展入学需求预警，不仅能辅助教育部门提前预警学位缺口、规划新校建设，同时为家长提供透明的入学风险参考。 199.48EB VS 101.34EB——人工智能应用到了奇点时刻 报告显示：“2025年，用于人工智能的数据量为199.48EB，同比增长42.86%，推理数据量达101.34EB，首超训练数据量。” 数据分析：相比于2024年企业用于人工智能的数据量占数据存储量约为7%，高质量数据集增速达27.4%，2025年用于人工智能的数据增长率达42.86%，高质量数据集数量及其数据量分别增长61.13%和142.58%，特别是推理数据量达101.34EB，首次超过训练数据量，表明我国人工智能发展迅猛，标志着我国人工智能正在跨越从技术突破到规模应用的奇点，人工智能在各行各业的应用正在大规模展开。 背后原因：我国人工智能正在跨越从技术突破到规模应用的奇点的背后，是全社会人工智能应用程度普遍提高、高质量数据集供给规模显著增大、企业数据技术投入持续加大、智能计算的数据生产能力大幅提升的必然结果。 一是全社会人工智能应用程度普遍提高。2025年，全国日均词元（Token）调用量从年初的超万亿增长到年末的100万亿，全年词元（Token）调用量约21100万亿。农业企业数据技术投入同比增长26%，用于人工智能的数据量同比增长14.51%。用于人工智能训练分析的科学数据占数据总量的13.43%，同比增长50.32%。 二是高质量数据集供给规模显著增大。2024年，高质量数据集增速达27.4%，企业用于人工智能的数据量占数据存储量约为7%。2025年，全国高质量数据集数量超11万个，高质量数据集数据量超908PB，同比分别增长61.13%和142.58%。高质量数据集的规模化供给为人工智能发展奠定了坚实数据底座。 三是企业数据技术投入持续加大。2025年，企业数据技术投入同比增长17.37%，其中，头部平台企业和中央企业数据技术投入分别增长25.79%和24.49%。 四是智能计算的数据生产能力大幅提升。2024年，智能家居、智能网联汽车等智能设备的数据增速位居前列，分别为51.43%和29.28%。2025年，系统软件和人工智能产生的数据量为26.92ZB，首次超过物联感知设施产生的25.34ZB数据量，成为数据生产的主要方式。 可以预计，在未来“十五五”的五年内，企业作为数据生产主力的地位将进一步巩固，更大规模的公共数据将以共享、开放和授权运营的方式供出来、用起来，人工智能技术还将快速迭代、应用范围将加速拓展。 作者：数据专家咨询委员会委员 北京交通大学教授 张向宏 来源：通信产业网
静态目录记录数据资产，而主动元数据则驱动数据资产的运行。 多年来，企业数据目录一直被宣传为通往数据的门户。它承诺提供搜索、所有权、血缘关系、定义和信任等功能。在许多组织中，它确实实现了部分价值——但往往只是静态的清单，几乎在填充数据后不久就过时了。问题不在于目录本身毫无用处，而在于现代数据环境的变化速度远超文档更新速度。管道会故障，模式会漂移，人工智能代理会提出问题，策略会变更，业务用户希望在管理员更新描述之前就能得到答案。这就是主动元数据至关重要的原因。它不仅仅是描述数据环境，还能帮助管理数据环境。 数据目录并未消亡，但它的旧功能已不复存在。 数据管理领域存在一种根深蒂固的误区：元数据的主要挑战在于文档编制。定义术语、指定所有者、绘制沿袭关系、发布目录，治理自然水到渠成。这种观念催生了编目工具、术语表研讨会和数据管理项目等一系列产业——它们都很有价值，也都很必要，但单靠这些手段却越来越捉襟见肘。 问题不在于文档，而在于延迟。季度更新的目录无法检测到今天下午导致监管报告出错的模式变更。手动维护的术语表无法在人工智能代理生成响应之前告知其某一列是否包含个人数据。六个月前绘制的血缘关系图无法反映上周在生产环境中运行的三条新管道。 数据环境已变得过于动态、过于分散且影响深远，仅靠被动的文档记录已无法承担治理重任。如今，企业需要的不仅是存储的元数据，更是能够动态更新的元数据。 元数据过去的含义 传统元数据主要用于描述数据。它帮助人们了解数据的存在：表名、列描述、业务术语、数据所有者、分类、血缘关系图、质量评分、刷新计划和访问策略。这些信息有助于数据发现。它们使数据分析师能够找到数据集，理解其含义，并确定其是否符合预期用途。 当数据规模较小、变化速度较慢，以及元数据的主要使用者是有时间阅读文档的人时，这种模型的效果相当不错。 主动元数据则有所不同。它是可操作的。它帮助系统根据正在发生的事情采取行动，而不是根据上个季度记录的内容。 静态元数据告诉你数据原本应该是什么。主动元数据告诉你的生态系统现在正在发生什么，以及下一步该做什么。 为什么元数据正在成为控制平面 最重要的概念转变是：元数据正在从数据资产的文档层转移到控制层。 想想这在实践中意味着什么。源模式发生了变化。与其等到下游仪表板崩溃并提交支持工单，不如让主动元数据层检测到变化，将其与相关的数据契约进行比较，暂停管道，通知数据产品负责人，识别受影响的报告和使用者，并启动修复工作流——所有这些都在人为发现问题之前完成。 再以访问控制为例。假设生产表中新增了一列，该列看似包含个人数据。此时，活跃的元数据系统会对该字段进行分类，应用相应的访问策略，更新目录记录，触发管理员审核，并记录控制操作。原本需要人工审核和召开管理会议才能完成的操作，现在只需系统自动处理即可。 主动式元数据将治理从一次会议转变为一种系统行为。这一转变彻底改变了数据管理的经济模式。 主动元数据在实践中的作用 以下是一些主动元数据为企业带来的具体示例。 自动停止故障管道。上游源系统中的某个必需列的类型发生更改。活动元数据层检测到此偏差，将其与数据契约进行比较，在损坏的数据到达任何黄金层或认证层之前停止管道，并向所有者发出警报，同时追踪所有受影响的下游资产。 数据产品的动态信任评分。如果某个数据产品的新鲜度服务级别协议 (SLA) 在一夜之间失效，系统不会允许下游用户（包括人工智能代理）在未收到警告的情况下查询过期数据，而是会更新信任评分，将该产品从认证工作流程中移除，并通知订阅用户。用户可以实时了解数据市场的最新动态。 利用实时上下文信息赋能人工智能代理。例如，人工智能代理会收到这样一个问题：“上个季度各客户群的净流出额是多少？”在生成 SQL 查询语句或文字描述之前，它会检查实时业务定义、已认证的数据产品状态、当前质量评分、数据沿袭、授权规则、语义模型映射以及数据新鲜度指标。如果没有这些上下文信息，代理可能会使用理解不透彻或未经授权的数据给出自信的答案。有了这些上下文信息，回答就会更加可靠、可审计且具有说服力。 自动对敏感数据进行分类。数据工程师向数据管道添加一个新字段。模式匹配和分类模型检测到该字段可能包含国民身份证号码。元数据层会标记该字段，应用临时敏感度标签，限制只有授权角色才能访问，并将其放入队列等待管理员确认。另一种方法——每季度手动执行一次数据映射——速度更慢、成本更高且可靠性更低。 为什么这件事现在很重要 多方面因素正在汇聚，使得主动元数据不再是愿景，而是迫在眉睫的现实。 复杂性已经远远超过了人工治理的能力。现代组织运营涉及云数据平台、湖仓、流式处理系统、SaaS 应用、BI 工具、笔记本、反向 ETL 工具、机器学习特征存储、数据产品、语义层和 AI 代理。没有任何管理团队能够以如此快的速度，手动编目和管理如此庞大环境中的元数据。 人工智能极大地提高了风险。人工智能代理和副驾驶需要的不仅仅是数据访问权限，它们还需要上下文信息：这些数据意味着什么？谁拥有这些数据？这些数据可以用于此目的吗？它们是最新的吗？它们可信吗？它们是否敏感？以及后续哪些决策依赖于这些数据？如果没有有效的元数据，人工智能系统就有可能基于理解不足的输入生成看似可靠的输出。在受监管的行业中，这不仅仅是质量问题，更是风险管理的失败。 监管要求可证明的控制措施。尤其是在金融服务领域，机构必须提供数据沿袭、访问权限、数据保留、隐私控制、关键数据元素管理、模型输入和报告逻辑等方面的证据。静态文档无法满足审计人员和监管机构日益提出的问题：告诉我发生了哪些变化，哪些人受到了影响，以及触发了哪些控制措施。主动元数据通过设计而非重建的方式提供了这种审计追踪。 市场已经注意到这一点。尽管市场预测的精确度不尽相同，但都指向同一个方向：元数据管理正在成为企业软件的一个重要类别。Research and Markets估计，到 2026 年，企业元数据管理市场规模将达到 128.9 亿美元，而 Mordor Intelligence 则估计同年将达到 158.6 亿美元。Dataversity 在其 2025 年技术、数据和人工智能调查报告中指出，只有 11% 的组织实现了较高的元数据管理成熟度。市场规模与组织准备程度之间的差距正是机遇所在。 主动元数据和数据产品 这与数据产品思维直接相关，且至关重要。数据产品不应仅仅是发布数据，还应公开所有权、用途、目标用户、业务含义、数据管理协议、服务级别预期、数据沿袭、质量规则、隐私分类、使用历史、已知限制和认证状态等元数据。 如果没有活跃的元数据，数据产品就无法被大规模地观察、信任或管理。其质量可能会悄无声息地下降，访问控制可能会失效，合同义务也可能在不被察觉的情况下遭到违反。 没有有效元数据的数据产品，只不过是一个包装更精美的数据集。 主动元数据将已发布的数据集转化为可管理、可观察、可信赖的产品。它使数据产品所有者能够实时了解其产品是否履行了义务、谁在使用它、其质量是否在可接受的范围内，以及是否存在任何需要他们关注的下游影响事件。 成熟度差距以及组织应该怎么做 根据Dataversity的统计，仅有11%的组织拥有较高的元数据管理成熟度。原因不言而喻：元数据所有权不明确、目录的实施沦为合规性手段而非实际运营服务、业务术语表与工程实际情况脱节、质量规则与业务影响脱节，以及工具分散导致无法构建统一的元数据图谱。 弥合这一差距需要改变运营模式，而不仅仅是更换工具。 重新构建目录。目录仍然是一个有用的界面，但它应该成为更广泛的元数据生态系统中的一个节点，而不是其核心。元数据应该在目录内外流动，而不是仅仅停留在目录内部。 识别高价值元数据事件。并非所有元数据事件都同等重要。应优先处理那些对业务或风险有直接影响的事件，例如：模式变更、质量规则失效、服务级别协议 (SLA) 违约、访问策略违规、关键数据元素变更、合同违约以及在受监管环境下未经认证的数据使用。 将元数据与工作流程连接起来。如果生成的警报无人处理，则元数据只是装饰性的，而非实际的。只有当元数据事件触发数据工程、治理、安全、风险、合规和产品所有权团队的行动时，其价值才能真正体现出来。 逐步构建元数据图谱。将业务术语、领域、数据产品、数据集、表、列、报告、管道、所有者、策略、质量规则、合同、消费者和 AI 代理关联起来。首先从对关键工作流程最重要的连接入手。 安全地向人工智能代理公开元数据。人工智能代理在查询数据之前，应先查询经过认证的元数据和受监管的语义上下文。这不仅仅是质量方面的考虑，更是治理和风险管理方面的要求，尤其是在输出结果会影响受监管决策的情况下。 风险与反模式 任何新兴能力都存在这样的风险：它往往会先吸引对工具的投资，然后才吸引对运营模式的投资。主动元数据也不例外。 常见错误包括： 购买一个主动元数据平台，而不改变元数据所有权的分配和执行方式。 将自动化视为问责制的替代品，而不是问责制的推动因素。 产生的警报数量过多，令团队不堪重负，最终导致警报被忽略。 将谱系图与谱系驱动的影响管理混淆； 假设人工智能代理能够仅从原始模式推断业务上下文。 主动式元数据并不会免除治理责任；它只是让责任得以执行。 元数据作为基础设施 发展方向已然明确。未来的数据平台将不再把元数据视为目录功能，而是将其视为运行时基础设施：策略执行层、AI 上下文层、信任机制、自动化触发器、产品接口和治理控制平面。元数据将成为管道、代理和产品声明和使用的依赖项，而不是团队并行维护的文档。 这场悄然发生的变革并非元数据变得更加重要——它一直都很重要。变革的关键在于元数据正变得主动起来：它与流程、策略、产品、人工智能代理、质量规则和运营工作流程紧密相连。那些及早理解这一转变的组织将不再仅仅关注目录采用率指标，而是开始提出一个更重要的问题：不是“我们的元数据存储在哪里？”，而是“我们的元数据能够促成哪些决策和行动？” 来源（公众号）：数据驱动智能
当前的生成式人工智能并非仅仅是又一层软件；它能残酷地揭示你信息资产的现状。如果你在2026年还在试图构建一个集中式的“单一数据源”，那你做的不是架构设计，而是IT考古。残酷的现实是：企业中大多数生成式人工智能的失败并非源于大型语言模型（LLM）的选择，而是源于注入其中的数据结构平庸。停止那些脆弱的概念验证（POC），它们只会哗众取宠；现在是时候构建基于严谨知识管理（KM）的工业级平台了。 1. 引言：缺乏知识管理（KM）的人工智能的程序性失败 我们必须摆脱人工智能能够通过某种算法魔法来理解信息混乱的危险错觉。“垃圾进，垃圾出”这句老话已经演变成一种更加阴险的版本：“垃圾进，垃圾放大”。与仅仅返回用户可以忽略的错误文档的传统搜索引擎不同，大语言模型（LLM）会吸收这些低质量数据，用欺骗性的语言权威将其合成，然后将其作为合成的“真理”输出。人工智能不仅重复错误，还会对其进行改进，并将其伪装在流畅的文本背后，从而彻底摧毁用户的批判性思维。 混乱的内网是工业人工智能面临的首要障碍。将检索增强生成（RAG）管道连接到杂乱无章的SharePoint服务器上，而这些服务器充斥着过时的HR政策或相互矛盾的技术指南，这无异于专业失职。当人工智能对关键维护流程或法律权利给出错误答案时，信任危机将立即爆发，而且往往是永久性的。作为架构师，我们必须认识到，知识库不再是被动的存档库，而是企业的语义计算引擎。如果没有严格的管理和元数据结构，你的人工智能只不过是一个昂贵且风险极高的玩具。 2. 知识管理基本框架：4C 和 4 大支柱 要实现人工智能的产业化，我们必须重新采用知识管理的基本原理，但要具备机器的速度和精度。知识生命周期必须围绕以下4个核心要素（4C）进行协调： 隐性：知识最初存在于隐性交流中。人工智能不仅要用于回答问题，还要用于捕捉互动（支持工单、会议、Slack 讨论串）的实质内容，从而将非正式信息转化为结构化资产。 捕获：捕获并非指“保存为 PDF 文件”。它指的是在创建瞬间提取实体、关系和意图。如果信息在源头没有结构化，之后重新处理的成本将非常高昂。 内容审核：这是90%的组织机构都面临的难题。内容审核是指由领域专家（SME）进行验证的过程。未经验证的内容会造成技术债务，最终只能由人工智能的臆想来偿还。 流通：人工智能改变了分销方式，从“拉动”（关键词搜索）转变为情境化的“推送”（对即时需求的精确响应）。 然而，技术仅占总工作的20%。一个强大的平台建立在四大支柱之上：人员（必须激励专家贡献知识）、流程（数据治理工作流）、技术（RAG 和图谱基础）以及治理（信息的法律和道德责任）。投资回报率并非遥不可及：成熟的知识库能够显著缩短技术支持的平均解决时间 (MTTR)，其原因并非在于搜索速度更快，而在于提供明确无误的权威解决方案。 3.打破单体架构：联邦架构和数据网格 单一的“信息源”模式注定失败，这是历史的必然结果。试图将所有信息集中化必然导致过时和业务部门权力被削弱。我们倡导的架构是基于数据网格原则的联邦制架构。知识必须始终归其创造者——业务部门（法务、人力资源、研发）所有。 每个领域都管理着自己的“记录系统”，并遵循各自的数据新鲜度规则。我们的任务是在其上叠加一个全局索引和语义中介层。这使得 RAG 流程能够在各个数据孤岛之间无缝切换，而无需进行大规模迁移。我们从一个静态的数据仓库转变为一个互联互通的知识生态系统。这个语义网络使 AI 能够理解，尽管名称不同，销售手册中提到的“产品 X”和缺陷单中提到的“项目 X-104”指的是同一个实体。 4. 内容标准和元数据基础 为了让人工智能高效运行，它必须能够获取“人工智能就绪”的内容。这需要近乎外科手术般的严谨写作规范。黄金法则是：“一篇文章对应一个问题”。如果你的文档是长达50页、涵盖多个主题的“文字墙”，那么在RAG流程中进行分块处理后，就会产生脱离上下文、缺乏连贯性的碎片。每个部分都必须简短（最多200字），并且结构清晰，便于机器提取。 但真正的动力源泉是元数据。人工智能并不会减少对元数据的需求，反而会加剧这种需求。如果没有明确的信号，人工智能就无法判断文档是否过时、是否仅限管理员访问，或者是否仅适用于特定司法管辖区。以下是基于最严格标准构建的元数据策略支柱： 表 1：描述性元数据（搜索的核心） 表 2：管理元数据（新鲜度保证） 表3：定性元数据（反馈回路） AI赋能特定元数据 这就是我们区分架构师和修修补补者的地方。这些要素使人工智能能够解读内容，而不仅仅是找到内容。 表 4：AI 赋能的特定元数据 5. 语义层和知识图谱 人工智能在面对内部术语和上下文同义词时常常会遇到困难。例如，用户寻求解决“故障”的方案，但官方文档中使用的却是“服务中断”。在纯粹的向量空间中，这两个术语虽然接近但不完全相同。解决方案是实现一个语义层，并通过知识图谱（KG）来具体化。 与存储数学近似值的向量数据库不同，知识图谱使用RDF（资源描述框架）和OWL（Web本体语言）等标准定义实体（产品、系统、事件）及其显式关系。通过构建最小可行模型（MVM），我们对业务含义进行编码。OperationalIncident实体成为连接实体Outage、ServiceDisruption系统和事件的枢纽ResponseProcedure。 这种结构支持多跳推理。如果用户提出的问题需要将安全策略与特定区域的特定软件版本关联起来，该图谱允许人工智能沿着逻辑链接（“语义路径”）进行推理，而不是猜测统计上的接近程度。默克公司的例子就是一个标杆：他们使用LLM生成的SPARQL查询来查询其临床数据图谱，从而强制人工智能仅在授权的结构化数据范围内工作，消除了想象空间。知识图谱就像一道逻辑护栏，限制了LLM的无限想象力。 6. RAG（检索增强生成）管道工程 RAG 的技术实现必须像工业生产线一样对待，而不是像拼凑起来的 Python 脚本。 文本分块过程：文本分块是一门科学。我提倡递归文本分割，它尊重逻辑结构（段落、列表），而不是随意地按词元数量分割。重叠部分必须经过精细调整（10-15%），以保持两个片段之间的语义联系。更高级的做法是父文档检索，它允许对较小的片段进行搜索（更精确），同时将完整的父文档提供给逻辑逻辑模型（LLM），以确保完整的上下文信息。 向量嵌入与数学极限：向量嵌入虽然功能强大，但却受到“维度灾难”的影响。余弦相似度在某些非常具体的技术术语或数值错误代码下可能会失效。 混合架构（向量搜索 + GraphRAG）：目前业界标准是 GraphRAG。我将向量搜索的语义灵活性与知识图谱的逻辑严谨性相结合。上下文压缩等技术可以过滤检索到的片段，仅将信息“精华”传输到 LLM，从而降低噪声和分词成本。 邦飞利公司的经验表明，通过将技术文档与强大的业务本体相结合，他们的答案准确率提高了 40%。他们使用一个协调代理，该代理根据问题决定是查询图（用于结构化数据）还是向量数据库（用于文本解释）。 7. 小结：治理、指标和自主学习 要驾驭这个平台，你必须放弃虚荣的指标（例如文章数量），转而关注人工智能就绪度关键绩效指标 (KPI)。成功的衡量标准是： 可查找性：首次搜索成功率。 停留时间和跳出率：如果用户在一个复杂的流程上花费 2 秒钟，则说明内容要么无用，要么索引不佳。 RAG 精确度：由主题专家 (SME) 验证的回复准确性。 我们还必须通过四种人工智能就绪数据模式来整合数据成熟度评估： AI POC：风险管理依赖于个人技能和稀疏的元数据。 多情境：跨多个场景的数据验证，结构化的开始。 实施：过渡到自动化准备工作的工具和平台。 生产：系统治理、偏差监控和自动纠正。 未来属于自学习知识库。通过分析搜索日志和响应失败情况，人工智能可以自行检测“知识缺口”。它可以主动建议创建文章或根据已解决的支持工单撰写初步版本，并将所有内容提交给人工进行简化的验证。 来源（公众号）：数据驱动智能
一、从算力竞赛到数据基建 2026年，大模型应用正从技术验证走向规模化落地。但一个现实问题日益凸显：模型迭代速度远超高质量数据供给能力。 据行业观察，当前大模型训练对数据的需求呈指数级增长，而合规、多样、结构化的高质量数据已成为稀缺资源。正如2026未来数商大会所指出：“AI下半场，数据决定AI上限。” 在此背景下，传统以报表为核心的数据仓库正在经历一场静默而深刻的升级——它不再只是BI的后端支撑，更成为大模型训练与推理的“中央厨房”。这场升级，不是简单堆砌存储，而是围绕AI就绪（AI-Ready） 目标重构数据架构、治理流程与服务能力。 这一趋势与国家数据局将2026年定为“数据价值释放年”的战略方向高度一致，旨在通过高质量数据集建设，赋能人工智能与实体经济深度融合。 二、AI就绪型数仓的三大核心任务 1. 构建高吞吐、低延迟的数据供给管道 大模型训练需TB/PB级文本、图像、日志等多模态数据。数据仓库需支持： 批量高效摄入：通过Spark/Flink等引擎，每日处理亿级记录； 实时特征流：为在线推理提供毫秒级响应的特征数据； 统一元数据管理：确保数据来源、格式、时效可追溯。 例如，某金融企业构建“客户行为湖仓”，将APP点击流、交易日志、客服录音等异构数据统一入湖，并通过Iceberg表格式实现ACID事务，保障训练数据一致性。 2. 支撑向量数据与语义检索 大模型常需结合向量数据库实现RAG（检索增强生成）。新型数仓需： 原生存储向量：支持FAISS、HNSW等索引格式； 融合标量与向量查询：如“近30天高价值客户中，相似咨询问题的解决方案”； 与向量库协同：通过CDC或API实现向量更新同步。 这要求数据平台具备多模态数据处理能力，打破传统仅处理结构化数据的局限。 3. 嵌入全生命周期数据治理 根据《数据安全法》第27条，重要数据处理者应“明确数据安全负责人和管理机构，落实数据安全保护责任”。AI数仓必须内置： 数据分类分级：识别训练数据中的个人信息、敏感信息； 匿名化/去标识化：对含个人信息的数据进行技术处理，符合《个人信息保护法》第73条要求； 血缘与审计：记录数据从采集到使用的完整链路，满足《生成式人工智能服务管理暂行办法》第12条关于“训练数据合法性”的备案要求。 三、三大常见误区 1.把“数据湖”当万能解药 盲目将所有原始数据倒入对象存储，缺乏治理，导致“数据沼泽”。结果：模型训练用不到有效数据，反而增加清洗成本。 正确做法：采用湖仓一体架构，在开放格式（如Delta Lake）上叠加治理层，实现“存算分离+治理统一”。 2.忽视数据合规边界 直接使用用户评论、客服对话等含个人信息的数据训练模型，未履行告知同意或匿名化义务。 正确做法：建立数据合规审查机制，训练前完成： 数据来源合法性评估； 个人信息识别与脱敏； 必要时取得用户单独同意（《个保法》第14条）。 3.追求“全自动”，放弃人工干预 完全依赖自动化管道，一旦数据异常（如字段突变、分布漂移），模型效果骤降却无法定位。 正确做法：关键节点设置质量门禁与人工复核，确保数据可用性。这既是工程最佳实践，也符合《网络数据安全管理条例》关于“风险监测与处置”的要求。 四、从“仓库”到“智能数据中枢” 服务化数据产品 将特征库、标签体系、向量集封装为API服务，供算法团队按需调用，提升复用率。 拥抱AI原生架构 参考中国移动与中国信通院联合发布的《AI原生基础设施实践指南（2026）》，将大模型推理、智能调度、向量计算作为平台原生组件，而非外挂模块。 强化跨团队协同 数据工程师需与法务、算法、业务共同制定数据使用规范，确保技术方案与合规要求对齐。 五、数仓的“AI原生”演进 随着国务院《关于深入实施“人工智能+”行动的意见》（国发〔2025〕11号）推进，数据仓库将加速向AI原生数据平台演进： 架构层面：从“存储为中心”转向“智能服务为中心”，内嵌向量引擎、特征计算、合规检查等能力； 治理层面：数据资产目录将包含“AI适用性”标签，如“可用于NLP训练”“已脱敏”； 生态层面：通过DCMM（数据管理能力成熟度）3级及以上认证，将成为企业参与政府/国企AI项目的基本门槛。 这场升级战没有硝烟，却决定了AI能否真正扎根于业务土壤。那些默默升级管道、加固治理、打通多模态数据的人，正是大模型时代最坚实的“喂养者”。 来源（公众号）：数据仓库与Python大数据
大多数数据战略失败并非因为方向错误，而是因为组织无法始终如一地执行。架构正是避免这种情况的关键，它并非通过控制来实现，而是通过一套精简的共同决策，使数百个独立的选择指向同一方向。 1884年，威廉·温彻斯特的遗孀、温彻斯特连发步枪公司继承人莎拉·温彻斯特开始在加利福尼亚州圣何塞建造房屋。一位通灵师告诉她，温彻斯特家族受到死于温彻斯特步枪之手的亡灵诅咒，唯一能驱散亡灵的方法就是不停地建造房屋。如果工程停工，她就会死去。 她对此事非常认真。在接下来的三十八年里，她雇佣木匠们日夜不停地工作，一周七天无休。到1922年她去世时，这座房子已经扩建成约160个房间、2000扇门、10000扇窗户，楼梯直通天花板，门打开后直接通向陡峭的悬崖，烟囱几乎顶到屋顶却没有壁炉。这里没有总体规划。每天早上，她都会和工头碰面，把当天的指示草草画在纸片上。没有清晰的愿景，也没有除了继续下去之外的任何意图。 我认为这是技术领域最贴切的比喻。并非因为企业IT系统真的像某些人感觉的那样“闹鬼”，而是因为其模式千篇一律。每个迭代周期、每个项目，团队都会做出看似合理的决策：这里新增一个集成，那里搭建一个定制数据存储，再添加一个微服务，再添加一条管道。每个决策本身似乎都没有错。但没有人问架构所要求的关键问题：这些组件如何协同工作？我们最终会后悔锁定哪些组件？结果就是软件工程师所说的“一团乱麻”——结构混乱却缺乏连贯性。修改成本高昂，难以解释，而且完全依赖于每个组件的构建者的记忆。 架构的作用在于约束设计 与温彻斯特神秘屋截然相反的是集装箱。20世纪50年代，全球贸易面临的问题并非船舶本身，而是货物交接。海运、铁路和公路之间的每一次转运都缓慢、繁琐且难以预测。集装箱的出现解决了这个问题，并非因为它本身性能更优，而是因为它本身就是一种约束：标准尺寸、标准锁扣点、标准装卸设备。正是这一设计决策使得所有运输方式之间的货物交接都变得可预测。一旦接口标准化，其他一切都可以围绕它展开。 这就是架构的作用：并非设计一切，而是约束那些若不一致就会破坏整体的决策。一套共享的边界、真理来源和交互模式，能够确保跨团队、系统和项目之间的交接可预测。它不是蓝图，而是一套允许其他一切在不导致分裂的情况下演进的决策。 架构是图纸背后的思考 问大多数人什么是架构，他们会指着一张图。方框和线条。系统上下文视图。技术栈。但架构并非图纸，而是图纸背后的思考。 架构的核心在于一系列有意识的、影响深远的决策，这些决策决定了系统的结构、压力下的运行方式、可扩展性和演化方式。正如格雷戈尔·霍普所定义的那样：架构必须包含重要的决策，这些决策必须有完善的文档记录，并基于清晰的逻辑。文档本身并非架构，决策及其背后的逻辑才是。 架构与单纯的建造之间的区别在于意图。架构始于目的，在限制条件下运作，并将权衡取舍明确化。它会问：哪些品质是不可妥协的？两年后我们需要做出哪些改变，而现在又无法锁定？哪些值得付费，哪些我们只需消费即可？如果没有这些问题，你建造的只是房间；有了这些问题，你建造的才是真正有效的建筑。 每个架构设计决策都是一种权衡。 为了准备诺曼底登陆，英国工兵面临着一个棘手的问题：如何在敌军炮火下安全穿越布满地雷的海滩？标准坦克无法胜任。于是，珀西·霍巴特少将的团队打造了一系列经过大幅改装的车辆，被称为“霍巴特的奇葩车”，每一辆都旨在解决战场上的特定难题。 其中最著名的当属连枷坦克。一个装有重型链条的旋转滚筒会敲击坦克前方的地面，在地雷被坦克自身重量触发之前将其引爆。这套装置确实有效。但其缺点是经过深思熟虑的：连枷会遮挡驾驶员的视线，降低速度，并且意味着在排雷作业期间无法开火。生存能力的提升是以牺牲进攻能力为代价的。 连枷坦克的关键架构特征——每一次改进都是一种经过深思熟虑的权衡。 这些并非表面功夫，而是意义重大的架构决策，决策者对放弃什么以及为何放弃有着清晰的认识。这种精准性——明白自己放弃了什么，而不仅仅是得到了什么——正是架构与空想之间的区别。 我在实践中反复看到过同样的情况。在旅游行业，架构师始终面临着数据新鲜度和系统性能之间的矛盾。预订复杂度假套餐的客户期望获得快速、准确的结果。但是，跨数十个供应商系统进行实时价格核查会造成延迟和不稳定。缓存数据可能会显示过时的价格，而实时获取数据则可能导致缓慢且令人沮丧的用户体验。 没有放之四海而皆准的答案，只有取决于具体情况的权衡取舍。无论你选择哪种方式，这个决定都会在未来数年内影响你的基础设施设计、团队所有权模式、服务级别协议 (SLA) 承诺以及成本结构。这就是架构的本质。 架构既是技术性的，也是社会技术的 关于数据架构，最重要也最常被忽视的一点是，它并非纯粹的技术性架构，而是社会技术性的架构：它融合了系统本身以及构建和运营这些系统的人员、团队和工作方式。 康威定律指出，任何组织在设计系统时，其系统结构都会反映出自身的沟通结构。换句话说：如果你的团队各自为政、支离破碎，那么无论技术图看起来多么精美，你的系统也必然如此。关于平台和集成模式的架构决策，与关于团队所有权、治理和交付实践的决策密不可分。 数据架构既是技术性的，也是组织技术性的——两者必须共同发展。 其实际意义重大：如果你想要不同的架构，可能就需要组建不同的团队。反向康威策略，即有意识地调整团队结构以构建所需的架构，是IT领导者可用的最有效工具之一，也是最少被使用的工具之一。 团队拓扑结构（Team Topologies）是由 Matthew Skelton 和 Manuel Pais 创建的框架。它将康威定律的社会技术洞见转化为一种实用的设计语言：负责端到端成果的流程导向型团队、降低认知负荷的平台型团队、构建能力的赋能型团队，以及需要真正专业深度的复杂子系统团队。团队边界和交互模式并非无关紧要，而是影响流程、风险和速度的结构性设计决策。 将战略意图转化为架构指导 大多数数据战略都只阐明了意图，却将架构的构建寄托于随机应变。团队根据每个项目、每个供应商的情况来解读战略的“含义”，结果可想而知：偏离方向、重复劳动、交接不畅，以及不到18个月，数据架构就与最初的意图大相径庭。 架构指导通过在交付开始前尽早发布一套不可协商的决策来避免这种情况。它不是蓝图，也不是购物清单，而是一种准则：团队不得在局部范围内重新决定少数几个结构性真理，因为在这些方面出现不一致会破坏整体策略。 得出此指导原则的过程遵循清晰的逻辑链，如下图所示。 定义架构指导原则的过程——从战略意图到可发布的指导原则包。 首先，要明确战略意图以及该行动所支持的具体价值流或客户旅程。然后，要编写关键场景，即必须奏效的几种情况：正常流程、高峰负载、异常情况和变更。这些并非边缘案例；它们是压力测试，旨在揭示如果任由本地解读，交付过程中哪些环节会出现歧义。 接下来需要考虑能力限制，包括架构必须克服的遗留系统、数据孤岛和基础设施限制。这确保了你的设计是基于实际环境，而不是基于一个全新的理想框架。 从场景和约束条件中提炼出目标架构特性：这些特性是定义架构必须具备的不可妥协属性的真理陈述，是策略成功的关键。至关重要的是，每个特性都与证据、合同、服务级别目标 (SLO) 和一致性仪表板相匹配。没有证据，特性就只是愿景；有了证据，特性才能得到有效管理。 运用沃德利映射法制定建议 目标架构特征告诉你哪些是必然存在的，但它们并没有告诉你如何实现这些特征，需要构建什么，需要购买什么，需要标准化什么，以及应该将哪些作为竞争优势。而这正是沃德利映射法（Wardley Mapping）发挥作用的地方。 沃德利图是一种可视化模型，它展现了组织如何为用户创造价值。该模型以特定的用户需求为核心，展示了满足该需求所需的一系列责任，并将每个组成部分定位在从创新到工业化的演进轴上。这种定位决定了组织的姿态：通用型责任应该标准化并被消费；而差异化的定制能力则应该进行投资和设计，以适应变化。 设想一家零售商正在构建线上订购线下取货（click and collect）服务。沃德利地图（Wardley map）立即揭示了一个有用的区别：定义“准备就绪”、“延迟”和“已取货”含义的编排层，即每个渠道、门店和客服人员所依赖的规范状态模型，牢牢地位于定制开发区域。客户的确定性要么在此得到保障，要么在此受到损害。它应该作为一项持续的产品功能进行投资，而不是一个项目。 在沃德利演化轴上绘制责任价值链——姿态跟随位置。 相比之下，订单管理和库存管理虽然至关重要，但在演化轴上却更偏右，更接近产品或商品。正确的做法是限制变异：实现无缝集成，避免局部重复发明，并将这些功能作为一个平台提供给所有消费者。 这张地图清晰地揭示了企业何时在错误的地方无意中实现了差异化：例如定制的集成架构、专属的通知机制以及在各个渠道重复复制的业务逻辑。这些并非竞争优势，而是会增加复杂性的成本，从而消耗掉真正实现差异化所需的预算。 架构与组织密不可分 一旦沃德利地图绘制完成，就必须明确责任归属。哪个团队负责哪项职责？正确的路径在哪里？当标准需要更新时，谁拥有决策权？ 沃德利演化轴不仅决定技术姿态，还决定每个领域的最佳运营模式。职责会根据其演化方式以及变革带来的关联程度，自然而然地归入不同的所有权群体。 职责按团队所有权分组——与沃德利的发展战略保持一致。 定制开发领域的差异化能力应由拥有领域决策权、持续投入且目标一致的团队负责，并以产品而非项目的形式进行投资，因为这关系到企业能否实现或削弱自身的竞争优势。这些团队人员变动频繁，需要拥有自主响应的能力。 平台区域的职责，即其他所有团队所依赖的权威信息，例如库存数据、订单状态或身份信息，应该由独立的团队负责，并作为产品功能提供给消费者，同时设定清晰的服务级别。如果这些信息分散在各个客户旅程团队中，组织内的其他部门就会各自独立地重复执行相同的规则。将它们放在平台区域可以防止重复信息在整个组织内扩散。 产品区域的功能受限于既定的变体、打包的工具、标准的工作流程引擎和托管的基础设施，其管理职责应有所不同：标准化、最大限度减少定制化变更，并与上述平台标准无缝集成。这里的风险不在于投资不足，而在于过度定制：即构建与标准模型已提供的功能重复的定制逻辑。 团队拓扑类型和互动模式——团队的参与方式决定了组织内部的摩擦。 团队间的交互模式与团队类型同等重要。通过“X即服务”这种低摩擦、以合同为先的关系，流式团队从平台团队获取资源，避免了持续协作带来的额外开销。协作仅限于真正需要共同解决歧义的阶段；一旦接口稳定且易于理解，自助服务模式才是最佳选择。这种高带宽协作与低摩擦消费之间的区别，是IT领导者可以做出的最重要的设计决策之一。 最终成果：指导手册，而非蓝图 此流程的输出并非未来状态架构图，而是一套指导手册：一套精心设计的约束条件和默认设置，旨在确保交付的一致性，避免陷入解决方案设计的窠臼。 一套完整的指导方案包含四部分。首先，提供目标架构特征及其证据，明确架构必须具备的不可协商属性，每项属性都对应一份合同、服务级别目标 (SLO) 或一致性检查，以确保其可控性。其次，提供一份沃德利图，清晰地阐明所有权归属、边界划分以及必须保持一致的接口。第三，提供以权衡取舍的方式提出的建议，明确行动步骤、停止事项、标准化流程和行动顺序，并清晰地列出每项行动的成本和收益。第四，提供一份运营模式概览，明确责任人、团队类型、交互模式以及一致性管理方式。 架构的作用在于影响，而非控制 思考架构时，要牢记的关键词是“影响”。架构指导的作用在于塑造团队无论如何都会做出的决策，而不是取代这些决策。其目标是构建足够的共享结构，使战略在与交付的互动中得以延续。这并非一个包罗万象的设计，而是一套针对那些若不一致就会破坏整体的事项的决策。 来源（公众号）：数据驱动智能
2025年开始，AI中台这把火越烧越旺。 赛意信息刚签下近5000万的AI中台订单，万达信息带着AI中台亮相世界人工智能大会，软通动力、众安信科各路玩家纷纷登场。有人喊出AI中台是企业数字化转型的标配，有人高呼再不布局就晚了。 熟悉的配方，熟悉的味道——这跟当年数据中台的剧本几乎一模一样。 但我想泼盆冷水：上套AI中台，距离企业真正用好AI，还差着十万八千里。 什么是AI中台 AI中台本质上是企业级AI能力的中枢神经系统。 简单来说，它解决的是重复造轮子的问题——把语音识别、自然语言处理、计算机视觉这些通用能力封装成可复用的组件，企业不用每个业务线都养一个算法团队。 同时，它还覆盖模型设计、训练、部署、监控的全生命周期，让算法工程师专注调参而不是天天搬砖。 听起来很美，对吧？ 但问题来了。 很多企业连数据分析师都没几个，更别说算法工程师了。 工具再好，没人用得了，这不是白搭吗？ Gartner早就给数据中台判了死刑，说它即将消亡，取而代之的是数智基建。 数据中台的失败率高达60%以上，动辄几百万上千万的投入，最后沦为"PPT工程"。 AI中台会好到哪里去吗？ 从架构上看，AI中台通常分为三层。 技术服务层提供通用AI能力和行业专用服务；研发平台层包含数据标注、特征工程、AutoML这些工具；管理运行层负责算力调度、权限控制、模型版本管理。 这套东西好不好？ 当然好。但它需要的前提条件太苛刻了——企业得有足够的算法人才、有清晰的数据治理体系、有持续投入的预算。 缺了任何一环，中台就变成了摆设。 AI中台会重蹈覆辙吗 这两个东西解决的根本不是同一个问题。 数据中台负责把数据管好、用活，AI中台负责把AI能力输出、复用。 谁也取代不了谁，但边界确实在加速融合。 现在有个明显的趋势：数据中台开始主动往AI方向靠，提供特征平台、训练样本这些能力；AI中台则越来越依赖数据中台喂过来的高质量数据。 数据问题不解决，AI能力就是空中楼阁。 我见过太多企业砸钱上AI中台，结果发现数据质量一塌糊涂——口径不一致、更新不及时、口径没人说得清。 AI模型跑出来的结果业务方不认，说数据不对。最后变成算法团队和业务团队互相甩锅，项目不了了之。 有些企业已经在搞融合中台，把数据中台和AI中台合成一个更广义的概念。 这条路走得通，但前提是企业得想清楚自己要什么，而不是跟风上系统。 数据中台当年什么下场，大家都知道。 定位模糊、闭环能力不足、价值交付周期太长，最后被很多企业束之高阁。 AI中台会步其后尘吗？ 未必，但有几个问题必须想清楚。 第一，AI是不是你企业的核心能力？ 如果是算法驱动型公司，比如智能风控、AI应用服务商，中台确实能沉淀资产、提升迭代效率。 但如果你只是把AI当工具用，完全没必要搞这么大阵仗。一个API调用能解决的事，为什么要养一个中台团队？ 第二，有没有更轻量的替代方案？ 数据中台加大模型加企业知识库，这套组合拳跑得通。 算力成本高企、数据孤岛严重、落地场景模糊，这些问题制约着大模型的规模化应用。 与其砸钱上中台，不如先把RAG跑通。 第三，AI中台比数据中台更难落地。 因为它需要的不只是数据治理能力，还需要持续的算法研发投入、模型迭代优化。 数据中台失败了还能说"数据质量问题"，AI中台失败了连借口都没有——模型效果不好，是数据问题、算法问题、还是算力问题？ 说不清楚。 中国企业有个毛病，喜欢追风口而不是打地基。 看到别人上中台，自己也要上；看到别人吹AI，自己也要蹭。 结果呢？系统上了一堆，真正用起来的没几个。 结语 市场永远不缺焦虑感。 十年前是云计算，五年前是大数据，三年前是元宇宙，现在是AI。 每波浪潮都有人喊再不入场就晚了，但真正活下来的从来不是追风口的，而是把根扎深的。 巴菲特说过一句话："我会专注于那些美好的事情，而不是糟糕的事情。" 在AI时代，美好的事情不是追风口、凑概念、为了KPI硬上AI项目。 而是让组织真正理解AI的能力边界，让数据资产真正可信可用，让技术在业务场景里产生实际价值。 一句话：技术服务于价值，而不是成为新的内卷。 数据中台踩过的坑，AI中台未必能躲过。与其急着上系统，不如先想清楚：我的企业真的需要AI中台吗？还是只需要一个会调API的工程师？ 技术浪潮来了又去，但地基稳不稳，只有自己知道。 来源（公众号）：臻成AI大模型
