导读
数据工程师每天被 cron 格式、页面切换、语法试错等琐事打断，真正用于建模、质量校验的注意力被持续稀释。云器科技产品负责人王贯扬近日在直播中分享了团队自研的命令行工具 cz-cli——一个让 AI 编程工具真正理解数据工程的 agent 工具。本文基于云器 Lakehouse 产品负责人王贯扬老师的分享，梳理 cz-cli 的设计思路、工程决策及典型场景，探讨如何通过专业 agent 将数据开发从“杂活驱动”转向“注意力驱动”。
注意力：数据工程师最稀缺的资源
记 cron 格式、切页面、查文档、试语法——这些动作单次耗时不过几十秒，却构成了高频率的上下文切换。演讲中引用了一个直观对比：同一个日报表搭建任务，人工操作需在多页面间反复跳转，而通过 cz-cli agent 执行，从建表、配置凌晨两点调度到上线验证，整个过程无需人工介入。
团队在内部调研中发现，数据开发过程中真正消耗精力的并非复杂业务逻辑，而是“平台配置差异、语法方言、不同页面间的来回切换”。这些琐事本身不构成技术挑战，但它们持续打断心流，让注意力无法锚定在建模、数据质量、业务需求思考上。cz-cli 的起点正是对这一痛点的回应：把杂活扛过来，把注意力还给工程师。
从裸用大模型到专业 agent：一条必经的工程化路径![]()
在决定构建专用 agent 之前，项目组尝试了三条技术路线，每一条都暴露了通用方案在数据工程领域的局限。
第一条：大模型直接调用 JDBC/SDK API。 问题很快浮现——查询返回几千行数据时，上下文窗口迅速被撑爆，频繁的 token 消耗让任务执行变得不可控。更关键的是，模型在处理海量中间结果时容易“失焦”，原本要完成的数据操作被淹没在响应体中。
第二条：将能力封装为轻量级 skill 嵌入主 agent。 随着 agent 中 skill 数量增加，调用稳定性开始下降。复杂任务中，模型有一定概率调用非预期 skill，即使正确调用也难以严格遵循 skill 中预设的步骤和经验约束。“skill 并不是一个能稳定发挥的形态。”
第三条：MCP（Model Context Protocol）方案。 多 MCP 并存时，冷启动阶段读取所有 tool 描述的成本显著拉高；且 MCP 作为通用协议，注意力不够集中。
最终团队选择了第四条路：构建一个专注数据开发的专用 agent，命名为 cz-cli。它可以独立运行，也能作为子 agent 被主 agent 调用。当主 agent 遇到数仓相关任务时，直接将控制权转交给 cz-cli——后者拥有足够聚焦的上下文和内置知识，能够稳定执行工程级的数据操作。
37 个 skill：不止是方法集合，而是一套规范数仓的 harness
cz-cli 的核心资产并非大模型的通用推理能力，而是内置的 37 个 skill。每个 skill 标注了三个维度：正确做法、平台限制、常见坑。覆盖范围从基础连接、数据管道搭建，到计算资源规划、数据建模、治理运维，以及上层业务集成。
“不是 37 个零散的方法，而是一整套驾驭 LLM 搭建规范数仓的 harness。”每一个 skill 在执行时都会主动校验中间结果——例如完成一层 DWD 建设后自动触发数据验证，确认无误后再进入下一层。这种“每层验证”的机制，避免了错误逐层累积到最后才发现、再回滚重算的代价。
团队也强调，cz-cli 不仅适用于云器 Lakehouse，也可用于其他数据引擎，核心价值在于提升数据开发的工程化输出质量。
典型场景：从血缘分析到 schema change 影响面评估
数据血缘分析
给定一张表，cz-cli 自动加载血缘 skill，逐级向上追溯上游依赖。它不只查询单一来源，而是综合调度任务依赖、DDL 语句、job history 等多源信息，交叉验证后输出完整血缘关系图。演示中一张表的四层血缘，每层包含哪些上游表、任务节点，全部自动绘制。
调度任务巡检
日常巡检是高频且重复的工作。将整条链路的巡检任务交给 cz-cli 后，它会拉取任务列表、状态、调度时间，甚至识别出耗时异常的任务，并生成可读的报告。更有趣的是，通过 IM（飞书、企微）调用子 agent，工程师在移动端就能完成巡检——输入一句“帮我看下这条链路的调度任务有没有异常”，几分钟后收到结构化报告。
Pipeline 搭建与 schema change 分析
接收一个“建三层 pipeline”的需求后，cz-cli 首先查询原表结构，规划任务步骤，逐层建表并刷新数据，每层完成后主动验证。若遇到语法错误（例如平台特有的方言差异），它内置的产品知识库会检索正确语法并自动修正。
schema change 场景则更具挑战：上游表新增一个 key-value 类型，下游会受哪些影响？cz-cli 先分析整条链路的血缘和依赖格式，再推理出风险表、脆弱依赖项，甚至给出兼容性变更方案和上线次序建议。
业务人员也能 DIY：从需求方到自主取数者
一个意外的发现来自公司内部的财务团队。财务人员需要分析账户成本，但不会写 SQL，也不熟悉数仓操作。团队给财务同学配置了主 agent + cz-cli 子 agent + 费用账单业务说明文档。结果财务同学自己生成了一份天猫报表——维度拆分清晰、可一键导出 CSV、可直接粘贴到 IM 分享。
这个案例让项目组意识到：cz-cli 不仅提升了数据工程师的效率，还改变了业务人员的角色——从“提需求”转向“用工具”，而数据团队则从“接需求做表”转向“建平台、建能力”。
增量计算：让 AI 掌握生产级细节
增量计算是云器 Lakehouse 的特色能力，但团队发现 AI 在构建增量链路时容易遗漏细节——不是不知道语法，而是无法兼顾工程化的完整性。例如状态表的生命周期、维表 join 的决策、如何加 hint 避免存储膨胀等。
为此，cz-cli 集成了增量计算专用 skill，补齐了大模型容易遗忘的细节：风险识别、增量合规检查、join 策略选择等。演示中，一个原有的四层 pipeline（数据新鲜度 1.5 小时）被要求改造为 10 分钟级增量链路。cz-cli 先读取 DT 表 creator 的参考文档（策略、限制、踩坑记录、最佳实践），然后逐层分析现有 MV 是否可以增量，最终输出改造方案——包括每层的原表与目标表、变更情况、约束条件、改造后架构图、风险与预期效果。
这个方案已经接近生产级，后续只需按 plan 细化 DDL 和链路配置即可执行。
让注意力的支配权回到工程师手中
回顾整个设计历程，一个核心判断贯穿始终：数据开发中的重复琐事不应由人的注意力来承担。cz-cli 不是为了让工程师变成更快的“SQL 手写员”，而是把注意力的支配权还给人——留给工程师的是真正需要判断的事：数据怎么建模、口径怎么对齐、质量标准怎么定。
对业务人员，它提供了自主探索数据、按需取数、生成交付的能力；对增量计算的迁移与搭建，它让原本需要数周梳理的链路改造变得可自动化推进。
项目组透露，cz-cli 目前仍在打磨细节，首批试用用户将获赠 token，做到“安装即用、无需操心配置”。感兴趣的同学可加入官方交流群，获取最新进展与使用技巧。
Q1：37个skill，模型怎么知道该调哪个？会不会调错
王贯扬：关键就是别让一个agent干所有事。我们把 cz-cli 做成专门的子 agent，只负责数仓，skill 范围很窄，模型自然不容易选错。每个 skill 的描述也写得短而精，详细内容等选中后再加载。另外我们有测试流程，新 skill 上线前会检查会不会跟其他的搞混。给大家的建议：skill 多了就拆成子 agent，别让一个模型记几十个工具。
Q2：2000行SQL、几十张表，AI真能看懂吗？
王贯扬：一次性读完肯定吃不消。我们的做法是先把 SQL 当代码管理，放代码库里让模型分步读。再用 coding graph 画出表依赖关系，用 speck 工具把长 SQL 切成小段。最关键的是 skill 里强制了流程：先拆 plan，一步一步执行，每步做完验证数据对不对。不是靠“读”懂2000行，而是靠“拆”和“验”驾驭它。
Q3：生产环境用AI，万一出错了怎么办？
王贯扬：幻觉避免不了，靠工程兜底。两个习惯：一是生产环境 agent 默认只有只读权限，人确认没问题才放开写操作。二是改东西先搭临时链路，和原链路并行跑，自动校验数据一致，没问题了再按步骤人工确认切换，错了用 time travel 回滚。核心思路：让幻觉只影响临时环境，且有回滚按钮。
Q4：几千张表、没怎么治理，AI能找对表吗？
王贯扬：别想一口吃成胖子。从最常用的核心链路开始，让 cz-cli 做血缘分析，把依赖图谱存下来。一条一条链路沉淀，覆盖80%业务查询就够了。另外给容易混淆的表加 semantic view，写清楚业务含义，模型就能准确定位。先挑重要的做，越用越顺。
Q5：业务人员用的时候，很多表长得像，模型怎么知道用哪张？
王贯扬：最靠谱的还是加 semantic view——花几分钟写明表是日粒度还是实时、适合什么场景。模型读到就能准确匹配。如果没有标注，模型会看数据新鲜度、行数来猜，但不一定准。建议核心表把 semantic view 补上，业务人员自己用 agent 取数就省心多了。
点击获取完整资料
云器科技官网 - 改变数据的使用方式
更多内容，欢迎关注「云器科技」官网！
云器科技-多云及一体化数据平台提供
