主数据管理里的治理 Agent24 个智能体怎么在 MDM 环节划边界摘要智能体正被引入主数据管理但哪些环节能交给 Agent、哪些必须留给人多数团队还没有清晰答案。本文以 9 月底发布的 MDM 治理智能体框架为样本按环节拆解可自动化程度与风险等级给出四条硬边界、六件套治理清单和六条踩坑提醒。前言主数据管理是数据治理里最“重人力”的一块数据接入要人工映射字段重复记录要人工比对合并分类层级要人工维护属性补全要一条条抠。一个集团级 MDM 项目实施周期以年计上线后的日常运维也要养一个专职团队。所以当智能体能力成熟后MDM 成了最被寄予厚望的落地场景之一。九月二十九日Stibo Systems 发布了 AgentWorkx——一个在 MDM 平台内构建、部署和治理智能体的框架随附一个包含二十四个智能体的库从数据接入、质量扫描、分类归属到描述生成几乎覆盖了 MDM 的高频工作环节。这件事值得关注的点不在“又一家厂商发布了 AI 功能”而在它的产品形态智能体不是外挂的聊天助手而是被放进了平台既有的治理、角色与权限体系里运行。这恰好回答了治理团队最关心的问题——Agent 进主数据边界划在哪里。本文按这个思路展开先盘 MDM 的各环节哪些适合交给 Agent再给四条硬边界最后是一份可落地的治理清单。一、MDM 七个环节哪些适合交给 Agent把 MDM 的主流程拆成七个环节逐个评估可自动化程度和出错风险环节可自动化程度出错风险建议自主性档位数据接入与映射高低自动执行 抽样复核重复识别与查重高中Agent 出候选人工确认合并分类与层级归属高低自动执行 例外路由人工属性补全与描述生成中中低生成建议按档位人工审阅后发布黄金记录生成与合并中高Agent 出候选人工裁决变更审批与生效低高人工审批对外发布低高人工 审批流两个参考样本该框架里的“Upload Anything”类接入智能体可以把供应商数据接入从数周压缩到数小时——自动引导供应商提交、把提交的数据映射到目标 schema 和分类法、抽取属性、校验完整性并标记缺口而“实体创建”类智能体的做法是先检索 MDM 和其他可信源查重确认没有既有记录后才创建新记录——这个细节非常重要后面会展开。表格里“建议自主性档位”这一列是关键。自主性不是一个开关而是一组档位从“仅生成建议、全部人工审阅”到“低风险自动执行、例外上报”再到“全自动发布”。档位选择必须与数据域的敏感度和出错代价挂钩——客户主数据合并错了影响的可能是信用额度物料主数据映射错了影响的可能是生产计划。同一档位套所有主数据域是设计上的偷懒。二、四条硬边界边界一Agent 必须在既有权限体系内运行不能开旁路最危险的设计是给 Agent 单开一个高权限账号绕过平台既有的角色与权限控制。正确做法是 Agent 复用平台的治理框架它能读哪些数据、能写哪些域、能触发哪些动作全部继承平台的角色权限配置。打破这条边界会发生什么一个接入 Agent 在映射字段时读到了薪酬数据域而操作它的人根本没有这个域的权限——权限体系形同虚设审计也查不到责任人。边界二创建前必须查重主数据最大的敌人是重复。人类操作员有业务经验兜底Agent 没有——如果不强制“先查重再创建”一个批量导入任务就可能往 MDM 里灌进成千上万条重复客户或重复物料而且这些重复记录还带着“看起来合理”的属性比人工造成的重复更难清理。所以“实体创建前先检索 MDM 与可信源”不能只是智能体的默认行为要写成平台的强制卡点创建请求必须先过查重命中疑似重复的一律进入人工确认队列。边界三低置信度必须路由人工质量扫描类智能体扫出的异常置信度是分层的。高置信度的问题如必填字段为空可以自动处理或自动打回低置信度的如“这两个供应商疑似同一家”必须路由人工复核。这条边界的本质是把人的判断力用在刀刃上。好的实践是质量智能体默认把低于阈值的问题送人工人处理过的问题再回流成为智能体的校准样本——人的每次裁决都在降低未来同类问题的人工率。边界四自主性可配置、可收回自主性档位必须支持动态调整而且收回要快于放开。新上线的智能体一律从最低档开始观察一个周期的错误率再逐档放开一旦某个域的异常率抬升立即降档而不是等季度复盘。补充一条容易被忽略的Agent 生成的对外内容如产品描述与内部数据属性要分开管理。内部属性错了影响系统间流转对外描述错了影响的是客户观感——两类错误的发现路径和责任主体都不同审阅策略也应该不同。三、落地清单MDM 治理 Agent 六件套治理团队接入 Agent 前建议把六份材料备齐件内容关键字段/要点① Agent 台账生产环境在用的所有智能体名称、用途、所属域、上线日期、owner② 权限矩阵每个 Agent 对每个数据域的读写权限遵循最小权限明确禁止域③ 自主性档位登记每个 Agent 在每个环节的档位当前档位、放开条件、回退条件④ 审计留痕规范Agent 每次动作记录什么时间、触发者、输入、输出、置信度、是否人工复核⑤ 回滚与熔断出错时怎么停一键停用、动作可撤销、影响范围评估⑥ 效果度量怎么判断 Agent 值不值人工工作量变化、错误率变化、处理时效变化其中第四件要展开说。Agent 是典型的非人身份它的生命周期管理应该参照人员账号的标准有明确的 owner、有用途说明、有权限范围、有凭据管理、有有效期——到期复审人员离职或服务商变更时同步收回。缺了这套管理一年之后你面对的是一堆没人说得清来龙去脉的自动化流程。第六件是说服管理层用的。智能体项目的立项理由通常是“降本”但真正的账要算得细接入环节从数周到数小时是显性收益而查重前置减少的重复记录、质量路由减少的返工这些要在度量口径里提前定义否则结项时说不清。四、前提条件元数据到位Agent 才有用武之地框架方有一句话说得准确当智能体承担更多企业工作时约束在于底层数据能否以机器速度被信赖。翻译成治理语言Agent 的上限由元数据质量决定。MDM 里至少三个元数据字段是 Agent 的前提字段Agent 怎么用缺失的后果数据域归属决定权限、审阅策略与发布范围Agent 跨域操作权限失控敏感级别决定自主性档位上限高敏域被自动改写权威源标识查重与合并时判定“以谁为准”合并方向搞反黄金记录失真再往深一层是业务定义的机器可读化。Agent 要判断“这两个客户是不是同一家”除了字段比对还需要业务规则——“同一统一社会信用代码视为同一实体”“分支机构与总公司是否合并由业务规则决定”。这些规则如果只存在于制度文件里Agent 读不到就只能靠字段相似度瞎猜。把主数据的业务规则整理成结构化、可版本化的定义是比买任何工具都优先的事。五、踩坑清单先上 Agent 后补权限为了快速见效先让 Agent 跑起来权限矩阵“以后再理”——等于把治理债直接放大。Agent 生成的描述直接对外发布省掉了人工审阅档位一次口径错误就是一次客诉。查重不是强制卡点靠智能体“自觉”先查重批量导入一次MDM 里多出几万条重复记录。动作不留痕Agent 改了什么、依据什么改的事后查不到出问题既无法回滚也无法追责。把 Agent 当人力替代不设 owner自动化流程没有负责人坏了没人修错了没人认。主数据标准没定就上 AgentAgent 放大的是既有混乱——标准缺失时它只是更快地生产不一致的数据。总结Agent 进主数据方向是对的——MDM 恰好是规则清晰、动作重复、人工成本高的场景最适合自动化。但落地的顺序不能反第一先理权限与档位再放 Agent 进场自主性从最低档开始、按错误率逐档放开第二把查重和低置信度路由写成平台强制卡点不依赖智能体的默认行为第三先补齐数据域、敏感级别、权威源三个元数据字段和结构化的业务规则——Agent 的能力上限就是你的元数据水平。一句话概括Agent 负责把人从重复劳动里解放出来但“什么是对的数据”这个判断标准必须先于人存在。顺序反了自动化只是在更快地制造混乱。你们的主数据管理开始引入智能体了吗卡在权限设计、查重策略还是元数据准备欢迎评论区交流。标签主数据管理、数据治理、AI Agent、元数据、数据质量