★ FEATURED ARTICLE 1. 项目概述为什么数据治理需要AI Agent做数据治理这些年最让我头疼的从来不是技术架构而是那些又碎又密的日常操作。一张新表接入先要补字段注释再跑一轮质量探查还要打数据分级标签查上下游血缘最后写一份治理报告。这一整套流程下来快则半天慢则两三天而且大部分时间是重复劳动。数据工程师的时间就这么被占满真正的治理策略反而没人思考。数据治理AI Agent解决的就是这个问题。它不是一个简单的脚本也不是一个带对话界面的搜索框而是一个能自主规划任务、调用工具、与环境交互并做出决策的智能体。它可以自动完成元数据补全、质量规则生成与执行、血缘关系梳理、分类分级打标这些治理动作并且在整个过程中保留人的审批和监督环节。在开始之前我先明确一下这篇文章的适用人群和前置条件。如果你负责数据平台建设每天被元数据缺失、质量告警、血缘不清这类问题缠身那这篇文章适合你。如果你对AI Agent只是听说过想看看它到底能在正经生产环境里干什么而不是只能写文案聊天那这篇文章也适合你。前置条件是有一定的Python基础理解基本的数据表概念知道数据治理大概是做什么的其余我会一步步拆开讲。整个篇文章的结构从问题出发先讲清楚Agent在数据治理里的定位再拆核心功能模块然后给动手搭建的完整路径最后分享我在实际环境中踩过的坑和排查方法。不会讲得太抽象但也不会流于表面关键是让看完的人能照着搭出一个能跑的最小系统。2. 整体架构与核心设计思路2.1 传统数据治理工具到底卡在哪想要理解Agent的定位得先看传统数据治理方案的问题出在哪。现在大多数公司的数据治理平台本质上是一个规则引擎加一个人工工单系统。规则引擎处理的是确定性问题比如字段为空值率超过阈值就告警表没有被访问超过90天就标记为冷表身份证号字段用正则识别。这些规则很稳但也很死板。新接入一张业务表字段含义千奇百怪同一个字段名叫crt_usr有的团队说是创建人有的团队说是操作人规则引擎根本理解不了语义层面的差异。于是治理平台能做的最多是按预设规则跑批剩下的事情全部落到人工头上。人工工单系统就更痛苦了。每张新表接入数据工程师填元数据业务负责人确认数据含义安全团队做分级审核层层流转。一个稍微复杂一点的表工单能转一周。更麻烦的是这些操作高度重复对人的依赖极重换一个人来可能就做不了同样的事因为判断逻辑全在脑子里没沉淀下来。所以传统方案的三个核心问题一是不理解语义规则只能覆盖确定性场景对模糊和歧义场景无能为力二是流程割裂元数据、质量、血缘、安全是四套系统互相不通三是知识不沉淀老员工脑子里的判断经验人走了就没了。2.2 Agent在数据治理中的定位和边界AI Agent在这套场景里的核心价值在于它能结合大模型的语义理解能力和工具系统的确定执行能力把原来需要人工判断和操作的环节承接起来。我理解的Agent在数据治理中的定位是治理操作员。它不是一个决策者不是一个替代数据治理委员会的存在而是一个能理解指令、能调用工具、能生成方案、能执行操作并回报结果的操作层角色。比如数据质量标准设多少算合理敏感数据打什么级别这些决策性的规则依然由人来定但Agent可以在人给定方向和边界后负责探查数据、生成规则建议、执行质量稽核、产出血缘图谱这些具体事务。这里要特别强调Agent的能力边界。经过我实际测试Agent擅长的场景有这几类数据探查和描述性分析。给Agent一个数据库连接它可以自动采样、计算统计信息、识别数据分布特征生成比传统profile工具更详细的描述。元数据补全与注释生成。给它表结构它能结合字段名、数据样例、表注释来推断字段的业务含义生成补充描述。治理规则建议与执行。它能根据数据特征推荐合理的数据质量规则阈值然后执行这些规则并汇总结果。血缘关系的初步解析和可视化描述。通过解析SQL它能梳理出表与表、字段与字段之间的依赖关系。Agent不擅长的场景必须留给人来做涉及业务实质的判定比如这个字段到底算不算核心资产这类需要有明确规则的决策跨部门协调沟通Agent再强也不能替你去和各业务团队对齐口径异常治理的仲裁和定责数据质量出了问题Agent可以定位但责任归属必须人来定。把这个边界画清楚后面搭系统的时候就不会盲目堆功能也就不会出现Agent越权乱操作的问题。2.3 模块划分与数据流设计从整体架构上我把这套数据治理AI Agent拆成三个层次编排层是Agent的大脑负责理解用户的目标把大任务拆解成子任务决定调用哪些工具以及根据工具返回的结果决定下一步动作。这一层不直接接触数据而是通过工具间接操作。我建议采用状态机的设计思路Agent的每次循环都会更新全局状态包括当前目标、已完成的步骤、中间结果、待确认事项。工具层是Agent的手脚每个工具封装一种确定性能力。比如探查工具负责跑SQL统计元数据工具负责读写数据字典血缘工具负责解析SQL文本。工具层必须做到无状态、参数可校验、输出结构固定这样Agent才能稳定地调用它们。数据层是基础底座包括元数据库、数据质量规则库、血缘关系库、样本特征库。Agent的所有输出最终都要落到这里治理报告和告警也从这里出。从数据流上讲整个链路是这样的外部触发信号新表接入、质量巡检、人工指令进入编排层Agent规划任务并调用工具层获取数据拿到工具返回的结构化结果后Agent进行判断和推理决定是继续调用其他工具还是生成最终结论最后把结果写入数据层。以新表接入为例元数据采集工具先扫描表结构Agent根据表名和字段名判断这是一张用户订单表调用探查工具采样部分数据验证判断是否正确然后生成字段注释补全建议和分级打标建议推送给人审环节人一键确认后回写元数据中心。整个过程从几天压缩到十几分钟。2.4 为什么用Agent而不是训练一个专用模型聊到这里肯定有人会问既然LLM能理解语义为什么不直接微调一个数据治理专用模型还要搞Agent这么复杂的架构主要原因有三点。一是数据治理操作对象的规模大且多变。企业数据表动辄几千上万张字段几十万个专用模型无法预知所有表结构但Agent可以通过工具动态获取schema实时适配。二是治理动作需要的准确率极高。写字段注释可以接受大概齐但删表、改权限、设规则阈值这些操作出错代价很大。Agent可以通过工具校验、人审环节、双重确认来兜底纯模型输出做不到这一点。三是治理流程是动态的。今天的规则可能下个月就变Agent可以通过调整工具配置和提示词来快速适配而重新微调模型的成本和时间都不可接受。我的结论是治理场景天然适合Agent形态因为它的本质是理解意图、调用工具、操作环境的任务而不是生成文本的任务。3. 核心功能模块拆解与实现要点3.1 元数据自动补全模块元数据补全是我最先落地的模块也是见效最快的一个。原因很简单几乎所有数据治理场景都依赖元数据而几乎所有平台的元数据都不完整。这个模块的思路并不复杂。Agent接到一张新表的元数据补全任务后执行这样几步第一步获取表结构和已有注释。这里建议直接读取信息schema或者元数据中心的开放接口不要走旁路去解析建表语句容易遗漏默认值、字符集这类关键信息。第二步采样数据。我用的是随机采样加边界采样组合。随机采样能反映数据分布但可能漏掉边界值所以额外加一个边界采样策略对数值型字段取最大最小值和四分位数对字符型字段取最长值和最短值。这一步很关键因为很多字段名有歧义但数据内容一看就露馅。比如某个字段名叫flag采样后发现取值只有Y和NAgent就能推断这是一个布尔标记而不是文本描述。第三步Agent基于字段名、数据类型、采样数据、表注释这四个维度的信息生成每个字段的业务含义补全建议。这里要注意Prompt设计我用了这样的约束条件如果字段名已经包含明确语义就不做过度推断无法确认的字段必须标注不确定不允许瞎编业务含义描述控制在50字以内避免废话。第四步生成结果进入待确认队列。我设计了两种确认方式低风险字段纯注释补全允许自动写入高风险字段涉及敏感数据标记、主外键关系推断必须人工审批。这个分级非常重要实测下来能把人力消耗降低80%又不失控。我在实际运行中遇到的一个坑是Agent太爱脑补了。一个名叫crt_dt的字段数据是datetime类型Agent会自信地写创建日期时间没问题但一个名叫remark的字段Agent也会写备注信息看上去没问题其实该表在业务里这个remark存的是审批意见更准确的描述应该是审批备注。这种语义理解偏差只有靠人审环节来兜底所以千万别省掉确认队列。3.2 数据质量规则生成与执行模块数据质量治理的传统做法是人先看数据再写规则再跑稽核然后处理异常。Agent化之后前两步可以大幅压缩。Agent会先做一轮快速探查用SQL统计关键质量指标空值率、唯一率、默认值占比、值域分布、格式匹配率、约等于零的数值占比。探查结果以JSON传给Agent由Agent判断哪些字段存在质量风险并生成规则建议。举个例子探查发现某字段空值率达到35%Agent就会生成一条空值率阈值规则建议阈值设为20%并附上理由该字段在近30天平均空值率约35%业务上该字段应至少有80%的填写率。这里我做了个细节设计Agent给出的每个阈值建议必须附带数据依据不允许只说建议设为20%而没有理由。这样人在审核时能快速判断合理性而不是把Agent当成黑盒。规则生成之后进到执行阶段。我这里有一个重要原则规则执行不能被Agent控制。Agent的作用是生成规则和执行计划但真正跑稽核SQL的是工具层里一个独立的执行器它从规则库读取规则配置生成稽核SQL跑完把结果写回结果表然后生成异常报告。Agent在这个过程中只做一个事解读异常报告把空值率35%超过阈值20%翻译成该字段数据完整性问题集中在近一周新增记录可能是上游接口未做校验帮助人快速定位原因。这个模块的另一个关键设计是规则生命周期管理。新生成的规则先进入观察期跑两周看告警量和误报率稳定了才转正为正式规则。实测下来如果不加观察期直接启用规则一部分规则会产生大量误报导致告警疲劳最后整个模块被业务团队投诉到下线。3.3 数据血缘分析模块血缘分析是数据治理里最费力不讨好的活。传统做法是解析SQL里的表名和字段依赖但面对几百行嵌套子查询、中间表、动态SQL解析器经常只能解析出表层血缘字段级血缘基本靠人工。Agent在这里的用法比较巧妙。它不是去重新发明一个SQL解析引擎而是把解析器无法处理的复杂SQL交给Agent做语义级的拆解。我的实现方案是先用解析器用的是sqlglot一个跨SQL方言的解析库跑一遍拿到初步的表级血缘关系。解析器处理不了的部分原样SQL作为上下文交给Agent让它识别真正的字段依赖路径。这里的具体做法是Agent拿到一段复杂的SQL后先做一步关系拆解把一条主SQL拆成若干条子查询识别每个子查询的输入输出和字段映射关系再递归处理每个子查询。这个递归拆解的过程在Agent里表现为循环调用工具输入SQL输出子查询集合然后对每个子查询再次调用同样的工具直到最小粒度。递归拆解过程中有两个约束必须设置到位。一是层数上限我设置为5层超过就直接标记为待人工处理。二是中间结果长度限制拆解到一定深度后把中间结果截断只保留表名、字段映射关系、JOIN条件避免把大段SQL文本塞进上下文导致推理质量下降。血缘解析结果我用一张血缘关系表存储包含上游表、下游表、字段映射、依赖类型、解析方式自动解析/Agent辅助/人工确认。汇报时按需生成血缘视图相比传统解析方案Agent辅助方式对复杂血缘的覆盖率高不少特别是带条件逻辑的字段映射解析器基本无能为力Agent反而能给出合理的推断。3.4 数据分类分级与安全打标模块数据分类分级是治理合规要求中的刚性需求也是最容易翻车的模块。误把普通数据标成敏感数据会影响数据使用效率漏掉敏感数据则直接是安全事故。基于这个考虑我用的是规则前置Agent判断人工兜底三层结构绝不让纯粹的模型输出决定数据级别。第一层规则前置。维护一张敏感字段特征表包括正则表达式、字典匹配、上下文关键词。字段名或样例数据命中规则直接标记为对应级别不进Agent流程。比如样例数据匹配身份证正则直接标记为最高敏感级。第二层Agent判断。规则没有覆盖到的字段Agent结合表名、字段名、数据样例、表注释做综合判断输出建议级别和理由。为了防止Agent的过度敏感倾向我在提示词里加了负面激励明确告知如果证据不足默认标记为内部数据不要随意输出敏感级别宁可漏判到人工环节也不要误报到冗余级别。第三层人工兜底。所有Agent标记为敏感或高敏感的字段必须进入人工审批队列。审批通过才生效不通过就自动回退到规则前置层的结果。这里我设置了加急通道连续三次审批通过Agent对于同类字段的判断可以直接转正不需要逐条审批。这个机制既保持了安全边界又逐渐降低人工负担。分类分级模块上线一段时间后最大的感受是Agent的价值不在于它判断得有多准而在于它把原来需要所有数据Owner逐字段人工确认的工作变成了一次批量生成建议加一次快速审批效率提升一个数量级同时保留了完整审计链路。4. 从0到1搭建实操环境、代码与关键参数4.1 技术选型与环境准备我的技术栈如下都是常见方案没有冷门依赖Python 3.10以上Agent编排框架用LangGraph理由是其对状态管理和条件跳转的支持比较完整比纯手写状态机省事又比过于抽象的Agent框架可控性更好。API服务用FastAPI提供触发器接入和人工审批接口。元数据存储用PostgreSQL加pgvector扩展结构化信息存PG特征向量用于后续的相似字段匹配。数据质量执行器用独立Python进程加Celery任务队列避免阻塞Agent编排。大模型接口做了抽象层可以切换本地部署模型或云端API方便根据数据敏感度选择调用通道。环境准备这里有一个容易被忽视的点数据库连接权限规划。Agent调用的数据库账号必须按最小权限原则配置只能读取指定库表不能执行DDL不能访问未授权的敏感库。4.2 核心代码骨架Agent状态机与工具注册代码结构上我一直强调一个点Agent的编排逻辑和工具执行逻辑必须分开。编排层负责想工具层负责做两层的接口用结构化数据传递。Agent状态定义用数据类组织from dataclasses import dataclass, field from typing import Any, Optional dataclass class AgentState: task_id: str # 任务ID target_table: str # 目标表 goal: str # 任务目标eg: 元数据补全 / 质量规则生成 steps: list field(default_factorylist) # 已执行步骤 tool_results: dict field(default_factorydict) # 各步骤结果 pending_review: list field(default_factorylist) # 待人工确认项 status: str init # init/running/waiting_review/done/failed核心编排逻辑是用LangGraph的StateGraph实现的条件循环from langgraph.graph import StateGraph, END # 节点定义 graph StateGraph(AgentState) graph.add_node(plan, plan_node) # 规划下一步 graph.add_node(execute, execute_node) # 调用工具执行 graph.add_node(review, review_node) # 判断是否需要人工确认 # 边默认 规划 - 执行 - 判断 graph.add_edge(plan, execute) graph.add_edge(execute, review) # 条件边review 根据状态跳转 graph.add_conditional_edges( review, lambda state: plan if state.status running else waiting if state.status waiting_review else done, {plan: plan, waiting: waiting, done: END} )工具注册的核心是一个装饰器机制把工具函数挂到Agent可调用的清单里TOOL_REGISTRY {} def register_tool(name: str): def decorator(func): TOOL_REGISTRY[name] func return func return decorator register_tool(profile_table) def profile_table(conn_config: dict, table: str, sample_rows: int 1000) - dict: 对表做数据探查返回统计特征 # 实现略 return {row_count: 12345, fields: [...]} register_tool(read_metadata) def read_metadata(metadata_conn: dict, table: str) - dict: 读取现有元数据信息 # 实现略 return {table_comment: ..., columns: [...]}这个注册机制的妙处在于Agent不需要知道工具内部是怎么实现的它只需要知道工具名称、参数结构和返回结果结构。新增治理能力时只需要注册一个工具函数然后如果能保持返回结构稳定Agent的提示词甚至不用改。4.3 提示词与推理策略配置Agent效果的好坏七分在任务拆解设计三分在提示词。数据治理场景的提示词有很强的特殊性需要数据探查过程和结果的可解释性。我给Agent配置了四段式系统提示词核心逻辑是你是数据治理Agent工作目标是在给定数据库环境中完成元数据补全、质量规则生成、血缘解析或分类分级任务。 工作约束 1. 你对环境的理解必须基于工具返回的真实结果禁止凭空猜测。 2. 每一步操作前先说明为什么做这一步。 3. 当结果存在不确定性时不强行下结论标记不确定原因并提交人工环节。 4. 涉及数据删除、权限变更、级别判定等高风险操作必须等待人工审批。 5. 回答和报告用结构化格式输出字段含义与JSON Schema保持一致。这里有一个容易被忽略的设计点系统提示词里的约束不是写给人看的是防模型幻觉的。禁止凭空猜测这条配合强制结构化输出实测能减少大量胡编乱造的情况。另外我还做了两个参数配置temperature设为0保证输出稳定性max_tokens设到4096防止长报告被截断导致结果不完整。每个工具调用的结果传入Agent上下文之前都会经过一个压缩环节。一个探查工具可能返回几百个字段的统计信息如果全量进上下文推理质量会显著下降。我采用TOP-N截断异常优先策略正常信息只保留前20个重点字段异常信息高空值率、格式失配全部保留。这样Agent既能看到全貌又能聚焦风险点。4.4 人工审批环节的实现人工审批不是Agent的附属功能而是安全护栏。审批流程我用FastAPI搭了一个极简界面Agent生成的待确认项推送到审批队列审批人逐条查看Agent的判断依据完全展示审批人选择通过/驳回/修改。这里有一个我在实际使用后觉得特别值的细节审批页面一定要展示Agent的思考步骤也就是它的完整执行路径。比如Agent判断某字段是敏感字段页面要展示它查过哪些采样数据、命中了什么规则、判断依据是什么。这个设计刚开始会让人觉得麻烦但实际用起来后审批人不需要再去数据库里核实Agent的判断审批效率大幅提升信任度也随之提升。4.5 最小可用系统的部署顺序建议第一次搭建时不要贪大求全建议从最小闭环开始。我建议的部署顺序是第一步先做元数据补全模块作为Agent的第一个生产场景。这个模块是唯一一个即使Agent判断出错了也不会有安全事故的模块最多就是注释写得不准人类审的时候改一下就行。第二步加数据质量规则生成这时候Agent需要调用探查工具并且引入规则观察期机制。这是Agent第一次和真实生产数据频繁交互能够暴露很多连接管理、超时控制、并发隔离的问题。第三步做血缘分析这个模块对工具层的要求高但不涉及写操作风险可控。等Agent对复杂SQL的处理能力稳定后再接入分类分级。第四步才是分类分级打标因为它的业务风险最高。有前面三个模块打底Agent的工具调用习惯和输出稳定性已经有保障此时接分级模块只需要把重点放在审批流和规则兜底上。整体来说我推荐这条路径的原因在于每一阶段都在为下一阶段铺路。深度实践下来大概一到一个半月就能搭出元数据加质量两件套后面血缘和分级的增量投入会小很多。5. 常见问题与排查技巧实录5.1 LLM生成的SQL不可信如何控制这是我在搭建过程中遇到的最大一个坑。Agent调用探查工具时如果工具内部是让Agent直接写SQL那它写出来的SQL质量参差不齐严重的还会出现查错表、字段名张冠李戴的情况。我的解决方案是双管齐下。一是工具层封装探查工具不允许Agent自由传SQL语句工具参数只接受表和字段列表以及探查类型SQL由工具内部使用模板生成。模板化的好处在于每一类探查的SQL都是预先验证过的不会出现语法错误。二是权限管控数据库账号统一走只读账号而且限定schemaAgent的查询范围被物理限制在授权库表内。如果你确实需要开放自由SQL生成比如要支持任意自定义探查那必须加一层校验器。我用的是sqlglot做AST解析解析后检查有没有多表JOIN、是否包含子查询、目标表是否在授权清单里任何一项不满足就拒绝执行。这条路可以走但不要图方便省掉校验。5.2 质量规则误报太多阈值怎么调Agent生成的质量规则和规则引擎跑出来的告警刚开始一定会有误报问题。我遇到的典型情况是Agent建议的空值率阈值对某些表不适用因为不同业务表的填写习惯差异巨大。A表30%空值是异常B表30%空值是常态。后续我加了一套自适应校准机制。每个规则在进入正式执行前先统计该表该字段近90天的历史数据分布取P90分位数作为默认阈值Agent的建议阈值和历史统计阈值取最大值。比如Agent建议20%但历史P90是45%那实际阈值取45%。这样规则在能发现真异常和不会乱报之间取平衡。另外要给规则设置沉默期。新表接入的规则自动进入7天观察期只记录告警不推送第7天统计命中率和误报率误报率高于50%的规则自动降级为建议模式。这个机制挡掉了大半的无效告警。5.3 Agent循环不终止或反复调用同一工具Agent跑着跑着停不下来同一个工具反复调用五六次这说明编排层的终止条件设计不够严格。这种问题在测试环境看不出一到生产环境接大量真实表必然爆发。排查思路有三个方向。第一个是看是不是步骤记忆没生效Agent每轮循环都以为自己是第一次做这件事就会重复执行。我的做法是在state里维护一个步骤hash列表每次执行前先比对重复的调用直接跳过。第二个方向是看条件跳转逻辑是否清晰。review节点的判断逻辑必须可穷举不能出现无法判断就继续循环这种模糊分支。第三个方向是设置硬性上限单任务最大步数15步工具调用单任务最大20次超限直接降级为人工处理不无限重试。5.4 上下文窗口不够长中间结果被截断数据治理场景里工具返回结果可能很长。一张几百个字段的表探查结果加上元数据信息轻松超过上下文窗口。如果直接全量塞给Agent它会忘记前面的关键信息导致决策质量骤降。我的处理方式是结果摘要化。每个工具返回完整结果写入临时存储Agent上下文里只放一个压缩摘要。摘要包含本次探查的整体结论、异常项清单、统计指标的摘要值。只有当Agent明确需要查看某个具体字段的信息时才通过一个专门的单字段查询工具去拉取详细数据。这个设计在元数据补全场景中效果很明显Agent不会因为在海量字段信息中迷失而漏掉异常字段。5.5 分类分级误判如何迭代优化分类分级误判是个长期迭代问题。我修复误判的思路是把每个误判样本沉淀下来回放给Agent让它解释当时的判断依据然后针对错误依据做专项优化。常见的误判类型有几种我整理成了一张排查表误判现象可能原因排查方法修复手段普通数据被标为敏感字段名含敏感关键词crt、pwd触发过度判断查看Agent判断依据确认是否命中了敏感词表在敏感词表中增加排除词加长上下文判断链敏感数据被漏判字段名无敏感特征样例数据也是脱敏值查看表注释和数据来源标注增加表级业务领域信息输入结合表上下文判断不同表同类字段级别不一致Agent判断无统一参照标准对比多个表样本的字段特征输入引入相似字段向量检索机制参考历史判断结果复用新增字段类型判断错乱采样数据缺失或值域太小Agent依据不足检查探查样本量是否充足提高采样率增加向上游表关联推断我自己在迭代中最有用的一个做法是建立一个误判案例库每周挑出本周所有人工驳回的Agent判断人工标注错误原因然后把这些案例喂回下一轮提示词优化。这个过程就是Agent系统的知识沉淀机制。传统规则系统要改动判断逻辑你需要找到规则再改代码而Agent系统只需要改提示词和更新案例库迭代效率高出一截。5.6 Agent和现有数据治理平台的关系最后回应一个我经常被问到的问题Agent能不能直接替代现有的数据治理平台我的答案是短期内它是平台之上的智能操作层不是替代者。现有的数据治理平台沉淀了大量规则、工单流程、权限体系这些资产不能废弃。Agent更合理的定位是从治理平台接收任务和触发信号通过调用平台已有的API和工具执行治理动作把结果写回平台。我之前提到过工具层的核心价值在于封装平台的已有能力而不是另起炉灶。比如已有的数据字典APIAgent直接调用它来读写元数据而不是自己直接连库操作已有的调度系统Agent在生成质量稽核计划后交给调度器执行而不是自己定时跑任务。这样Agent带来的增量价值是智能化的编排和判断而平台的资产和管控边界原封不动。我实际落地时Agent完全无侵入地接在平台之上出了问题随时可以一键切换回原有人工流程。结论是Agent化不是推翻重来而是在现有治理体系上叠加一层智能操作员人负责定边界Agent负责跑腿平台负责沉淀。从我个人的实操体会来说这套东西上线之后最大的变化不是人力节省了多少而是治理工作的节奏变了。原来一个新表接入流程走一周治理工作靠人追着赶现在是Agent先跑完一轮探查和建议人来做确认和决策。节奏从人追数据变成了Agent跑一圈人CtrlA一键过。当然中间踩过的坑也是一摞一摞尤其提示词、权限管控和上下文截断这几块属于必过的坎。如果你也在做类似的尝试我的建议是先把范围圈小从元数据补全这一个点开始跑通闭环后再横向扩。数据治理这行最不缺的就是问题清单Agent的用武之地只多不少。
阅读完成 · 觉得有帮助？
写本科开题报告，先写哪一部分最省时间？)
