在数据驱动决策的时代，数据仓库如同企业的“数字心脏”，但其建设却长期饱受“烟囱林立”、数据质量参差不齐等顽疾的困扰。规范文档写了一大堆，为何最终总难逃“形同虚设”的命运？在快手生活服务数据中心架构师潘广远看来，问题的根源在于过去纯粹依赖“人治”的治理模式已触及天花板。
拥有逾十年数仓经验、先后任职于京东、阿里、快手的潘广远认为，在快手生活服务这类“快”字当头的业务中，爆炸式的需求与频繁的变更，让规范的执行更是难上加难。“为了快速交付，团队不得不‘踩下规范的红线’，这导致技术债务飞速累积。”
转机来自于AI Agent技术的成熟。在2026年1月16-17日北京Agentic AI Summit 超级智能体技术峰会的演讲中，潘广远将系统性地分享其团队在“AI Agent赋能数仓治理”上的深度探索与实践成果。他认为，AI Agent并非要取代资深架构师，而是扮演一个不知疲倦、绝对公正的“智能合伙人”，将规范从纸面条文转化为内置在生产流程中的智能关卡。
在此次采访中，潘广远详细介绍了其团队打造的“智能评审”Agent如何工作：它如何通过“提示工程+RAG”的技术组合，精准理解并应用复杂的内部规范；又如何通过三层防御体系，有效规避大模型的“幻觉”风险，确保评审建议的可靠可信。也介绍了真实的量化收益：通过AI Agent的引入，不规范建设减少了50%，评审环节人力节省近半——这清晰地证明了AI不再是概念，而是能直接产生ROI的生产力工具。
未来的工程师不再是“SQL工人”，而需转型为“懂数据的AI训练师”。对于那些观望中的团队，他也给出了务实的“最小可行产品”入手建议。关于“人机协同”的数仓治理新范式探索，或许值得所有从业者去思考。
立即报名参会
DataFun：潘老师，您在京东、阿里、快手都深耕数据仓库领域。我们发现您的演讲提纲首先提到了“质量痛点”。在您看来，快手的“生活服务”业务场景，相较于您之前经历过的电商场景，在数据仓库建设中最独特或最棘手的痛点是什么？是业务变化更快，还是数据源更复杂？
潘广远：您说得对，这是一个非常关键的差异点。相比于我此前经历的标准化程度相对较高的电商业务，快手的生活服务业务是一个典型的“快”字当头的新兴业务领域。它的独特性主要体现在两个方面：
首先，是业务发展的“高速性”。生活服务作为一个战略级新业务，其数据需求是呈爆炸式增长的。来自到店、酒旅、本地生活等各个细分场景的需求会瞬间涌向数据团队，这极易在短时间内拉满所有数据研发的人力。在“唯快不破”的业务压力下，为了抢时间、保交付，团队往往不得不采取一些“短平快”的开发模式。这就如同在高速公路上边开车边换轮胎，“分层规范”、“模型复用”等长期最优原则，在短期内会被迫让位于“直接出结果”，从而为后期的“烟囱式建设”埋下了大量隐患。
其次，是业务逻辑的“多变性”。电商的“GMV”、“UV”等核心指标口径相对稳定。而生活服务业务则不同，其营销玩法、补贴策略、指标口径变更非常频繁。例如，一个“套餐”的核销逻辑可能这个月和下个月就完全不同。这种频繁的变化，要求数据模型必须具备极高的灵活性和可扩展性。开发人员需要在不同时期、不同背景建设的模型中来回进行兼容性修改，这种“打补丁”式的开发，极易破坏模型的简洁性和规范性，导致数据链路变得错综复杂，“数据债务” 会快速累积。所以说，新业务的“快”与“变”，是传统数据治理手段最难招架的挑战。
DataFun：您提到“因为人的因素，规范执行不到位”是核心挑战。这似乎是一个老生常谈的治理难题。AI Agent的出现，为什么在“此时此地”让您觉得它具备了从根本上改变这一局面的潜力？是技术成熟度、成本，还是其他关键因素发生了转折？
潘广远：这正是问题的核心。过去，我们解决规范问题主要依靠“人治”，即通过架构师评审、培训、宣导等手段。但这存在几个天生短板：第一，架构师的精力是有限的，无法细致评审每一个模型和每一段代码；第二，架构师的水平是参差的，对规范的理解深度和执行尺度不一；第三，人的监督难以7x24小时持续。
而大语言模型技术的成熟，特别是其强大的自然语言理解和逻辑推理能力的出现，为我们提供了一个可规模化的“智能大脑”。它让我们看到，可以将公司沉淀了多年的、以文档形式存在的各种数据规范（分层、命名、代码、设计范式等），通过提示工程和知识检索 的方式，“灌输”给这个智能体。
更关键的是，AI Agent不仅仅是一个静态的知识库。它具备“思考”和“反思”能力。当面对一个新建的模型设计时，它能主动调用相关的规范知识，像一位不知疲倦的、经验丰富的“初级架构师”一样，进行逻辑推演和一致性检查，并提出有理有据的评审意见。这实现了从“依赖不可控的人的因素”到“依赖稳定、可复用的智能化能力”的范式转变，让规范的落地从“倡导”变成了“内置”，这才是其颠覆性的潜力所在。
立即报名参会
DataFun：“智能评审”Agent听起来非常吸引人。它具体是在数据开发的哪个环节介入的？是替代了资深架构师的人工评审，还是作为一道前置的、强制的自动化关卡？您能分享一个它成功拦截或优化了一个“烟囱式”模型设计的具体案例吗？
潘广远：我们的智能评审Agent深度嵌入了数据研发的CI/CD流程，主要在模型设计评审（Design Review）和代码合并请求（Merge Request）这两个关键环节自动触发。
关于它和资深架构师的关系，我们的定位非常明确：它不是替代，而是增强与互补。可以把它理解为一位能力极强的“第一道防线”或“超级助手”。在实际操作中，当数据开发同学提交了一个新的数据模型设计文档或代码后，Agent会立即启动，进行第一轮的自动化深度扫描。它能发现大量基础的、常见的规范性问题，比如表命名不符合规范、字段注释缺失、违反了数据分层依赖原则等。
这就把我们的资深架构师从大量重复性的、低层次的检查工作中解放了出来。架构师现在可以集中精力，去Review那些已经由Agent初步过滤后的、更复杂的、涉及业务逻辑深度和模型长远可扩展性的问题。
至于案例，一个典型的场景是识别“重复建设”。我们曾有一个业务团队，为了快速满足一个需求，准备新建一个数据模型。Agent在评审时，通过对比现有模型库，发现该模型与三个月前另一个团队为类似场景建设的模型在核心维度和指标上重叠度超过80%，只是业务名称和少数字段有所不同。Agent随即给出了“疑似重复建设，建议优先考虑复用XX模型，或与XX团队沟通融合方案”的强烈警示，并附上了详细的对比分析。这个提醒最终促使两个团队坐下来协商，合并了需求，直接避免了一个新的数据烟囱的产生。
DataFun：在技术实现上，“智能评审”Agent是如何理解并应用贵公司那些复杂的“分层规范”、“命名规范”的？是依赖于精细设计的提示工程（Prompt Engineering），还是通过微调（Fine-tuning）了一个领域模型，亦或是结合了RAG（检索增强生成）技术来关联知识库？
潘广远：我们采用的是以“精细设计的提示工程”为引导，以“RAG技术”为知识基座的组合方案。
提示工程的作用是“设定角色和流程”：我们通过精心设计的系统Prompt，为AI Agent设定了一个明确的角色——“你是一位资深的数据仓库架构师”。并为其规划好一套标准的评审工作流，例如：“第一步，请检查模型命名是否符合《ADS层命名规范V2.1》；第二步，请确认该模型是否引用了正确的DIM层维度表...”。这相当于给了Agent一个清晰的“评审 checklist”和“思考框架”。
RAG技术的作用是“提供准确的规范知识”：公司的数据规范文档数量庞大且会持续更新，我们不可能为此去频繁微调一个大模型。因此，我们将所有这些规范文档、最佳实践案例、历史评审记录等，构建成了一个向量知识库。当Agent需要评审某个具体点时，它会通过RAG技术，实时地从知识库中检索最相关、最准确的规范条文和案例来作为其判断的依据。这既保证了对内部特定知识的准确调用，也规避了大模型本身可能存在的知识滞后或“幻觉”问题。
这个“Prompt定义流程 + RAG提供弹药”的模式，在实践中被证明是成本、效果和灵活性兼顾的最佳选择。
立即报名参会
DataFun：“大模型存在幻觉”是几乎所有AI应用落地的阿喀琉斯之踵。在“智能评审”这种对准确性要求极高的场景中，快手团队采用了哪些具体的技术或工程方案来识别和规避幻觉，确保它给出的评审建议是可靠、可信任的？
潘广远：保障准确性是我们落地过程中投入精力最多的地方。我们构建了一个三层防御体系来应对幻觉问题：
1. 源头优化：持续迭代的Prompt工程。我们发现，Prompt的精确度直接决定了输出的稳定性。我们通过大量的测试案例，不断打磨和优化我们的系统Prompt，使其指令更明确、约束条件更严密，比如明确要求“所有评审观点必须引用自知识库中的规范文档编号”，从而限制模型的自由发挥空间。
2. 知识 grounding：依赖RAG增强检索。这是最核心的一环。我们强制要求Agent的每一个评审结论，都必须有据可查。通过RAG，我们将大模型的推理能力，牢牢地“锚定”在我们内部权威的知识库上。它给出的不再是“我觉得”，而是“根据《XX规范》第X条，建议...”，这极大地提升了输出的准确性和可信度。
3. 流程设计：与现实工作流结合的闭环。我们将Agent集成到代码管理平台中，它的评审评论会像其他同事的评论一样，附在具体的代码行旁边。这形成了一个人机协同的校验闭环：开发同学如果对Agent的评论有异议，可以随时@资深架构师进行仲裁。这些被仲裁的案例，又会成为我们优化Prompt和知识库的宝贵样本。此外，对于某些高风险环节，我们设置了“低置信度自动转人工”的机制，当Agent自身对判断的把握度不高时，会主动将任务路由给人类专家。
DataFun：我们都很关心投入产出比。在落地这些 AI Agent后，是否有量化的指标来证明其价值？比如，模型设计的平均通过率提升了多少？因规范问题导致的返工率下降了多少？或者数据工程师在评审环节节省了多少时间？
潘广远：我们主要从治理效果和人效提升两个维度来衡量其价值，并且已经看到了非常积极的量化数据：
在治理效果上：我们通过统计新建模型中违反核心规范（如错误的分层引用、不合理的命名、重复建设等）的数量，发现不规范的建设情况减少了约50%。这意味着数据架构的“熵增”被有效抑制，数据环境的整洁度和可维护性得到了大幅提升。
在人效提升上：这是最直接的收益。在引入智能评审Agent后，在模型设计与代码评审这个环节，为我们节省了40%到50%的人力投入。具体来说，我们的资深架构师不再需要去逐行检查代码的命名和注释，也不再需要反复回答那些在规范文档中已明确定义的基础问题。他们节省下来的时间，可以更多地投入到数据资产规划、业务赋能和创新技术探索等高价值工作上。这个ROI是非常清晰的。
DataFun：在过去，我们也会通过脚本和规则引擎来实现部分自动化检查。您认为AI Agent驱动的“智能评审”与这些传统方法最本质的区别是什么？是它具备了“理解意图”和“举一反三”的能力，而不仅仅是机械匹配规则吗？
潘广远：您的理解非常准确。我们构建的系统其实是一个“规则引擎”与“大模型推理”共存的混合智能形态。这两者各有侧重，相辅相成。
规则引擎：负责处理那些确定性强、黑白分明的问题。比如“表名是否以‘ads_’开头”、“字段类型是否为bigint”。这些检查速度快、结果100%准确，我们用规则引擎来处理，效率最高。
AI Agent：则用于解决规则无法覆盖的灰色地带，这正是其价值所在。它具备理解语义和上下文意图的能力。例如，规则引擎无法判断一个模型的设计是否符合“高内聚、低耦合”的设计原则，也无法识别出我们前面提到的“两个模型在业务含义上是否实质重复”。但AI Agent可以通过理解模型的设计文档、字段的业务含义和表间的依赖关系，进行逻辑推理，从而发现这种“设计范式”层面的问题。这就是“举一反三”的能力，它处理的是复杂性，而非简单的规则符合性。
在我们的系统中，我们会根据具体的评审条目，智能地路由到最适合的处理引擎，从而实现效率和深度的最佳平衡。
立即报名参会
DataFun：最后，展望未来，您认为AI Agent最终会重塑数据仓库工程师的角色吗？他们未来更需要具备哪些新技能？对于那些正准备尝试类似探索的中小型团队，您会建议他们从哪个“最小可行产品”开始切入？
潘广远：是的，我认为这不仅仅是一种工具升级，更是一次深刻的角色重塑。 未来的数据仓库工程师，如果仅仅满足于写SQL、建模型，其竞争力必然会逐渐减弱。
他们需要向 “懂数据的AI训练师”或“数据架构的智能规划师” 方向转型。这意味着需要具备以下新技能：第一，是AI素养，要理解大模型的基本原理和能力边界，学会如何与AI协作；第二，是数据架构与治理的顶层设计能力，因为你需要定义规则和范式，并教会AI Agent去执行；第三，是更强的业务理解能力，以便将业务问题转化为数据和AI可解的问题。
对于希望开始探索的中小型团队，我的建议是 “从小处着手，解决具体痛点” 。不要一上来就追求全流程的智能评审。一个非常好的MVP切入点是：构建一个“智能数据答疑Agent”。将公司的数据字典、数仓规范、常用指标口径等文档导入，做一个能快速、准确回答数据相关问题的聊天机器人。这个项目成本低、见效快、价值直观，既能立刻提升团队的数据查找效率，也能让团队初步积累使用RAG、Prompt Engineering等核心技术的经验，为后续更复杂的AI Agent应用打下坚实的基础。
活动推荐
本次Agentic AI Summit 超级智能体系统架构峰会汇聚了顶尖互联网公司的 Agentic AI 建设先锋，内容直击企业AI落地的核心挑战与解决方案。无论您是关注Agent平台建设、还是Agent工具开发，都将在这里获得极具价值的启发与实践参考。
如果你也想来会议上演讲，分享实践成果，欢迎在这里提交话题：https://qr18.cn/A4cYOz，所属会议请选择：Agentic AI Summit2026北京站，角色请选择：讲师。我们会在收到内容后尽快给您反馈结果。
如果您想要来参会听演讲，和专家面对面交流，请电话或添加微信快速咨询，获取最新会议信息： 13311343487（宋宋）。点击「阅读原文」即可报名参会！
