跳到主要内容

数据集发现

这篇主要给 技能编写者、交付同学、Agent 维护者 看。业务人员通常不需要自己去查数据集 code，Agent 会先做这一步“探路动作”。

这一步是干什么的​

当 Agent 接到一个业务问题时，往往先要回答三个问题：

  1. 这个系统里到底有哪些业务对象？
  2. 我现在要查的对象对应哪个数据集？
  3. 这个数据集里都有哪些字段、哪些字段能拿来筛选？

dataset list 和 dataset detail 就是用来做这件事的。

什么时候会用到​

  • 第一次接手某个业务系统
  • 不知道“客户”“订单”“工单”这些对象在哪张表里
  • 需要确认字段名，避免 --params 里的键写错
  • 需要让 Agent 先理解数据结构，再继续查数或写入

如果你已经知道数据集 code，可以直接跳过这一步，进入 data filter、data getOne、data aggregate 或写入命令。

前提条件​

使用数据集发现命令前，需要满足两件事：

  • 已完成 AccessKey 登录
  • 已经确定当前应用（例如通过 app use 或 --appcode）

也就是说，当前 runtime CLI 走的是 AccessKey 模式，不是旧的 Cookie 模式。

列出数据集​

# 列出当前应用下的全部数据集
lovrabet dataset list

# 按名称模糊搜索
lovrabet dataset list --name order

# 按 code 精确过滤
lovrabet dataset list --code a1b2c3d4e5f6a7b8c9d0e1f2a3b4c5d6

这一步更像“先看看这个系统里有哪些业务对象”。
常见用法是从业务关键词开始，比如：

lovrabet dataset list --name 客户
lovrabet dataset list --name 订单
lovrabet dataset list --name 工单

查看数据集详情​

lovrabet dataset detail --code a1b2c3d4e5f6a7b8c9d0e1f2a3b4c5d6

你通常会在输出里重点看这些信息：

  • name：数据集名称
  • code：后续 data 命令要用到的 code
  • table：底层表名
  • fields：字段列表
  • operations：支持哪些标准操作

对 Agent 来说，最关键的是 fields，因为后面拼 --params 时，字段名必须写对。

一般怎么配合后续动作​

最常见的链路是这样：

  1. 用 dataset list 找到大概对应的业务对象
  2. 用 dataset detail 看字段结构
  3. 再进入 data filter / data aggregate / data create / data update

比如：

  • 业务问题是“找未发货订单”
  • Agent 先发现订单数据集
  • 再确认是否有 payStatus、deliveryStatus、warehouseName 这些字段
  • 最后再去执行筛选和汇总

关于 dataset code​

dataset code 是 32 位十六进制字符串。
最稳妥的做法永远是：

  1. 先从 dataset list 的结果里找到它
  2. 再复制到后续命令里

不要手写、不要猜。

给业务侧的建议​

业务人员通常不需要说“帮我查数据集 code”。
更自然的说法是：

  • 帮我看看客户数据在哪里
  • 帮我确认订单里有没有仓库字段
  • 帮我先识别一下这个系统里的工单对象长什么样

这些话交给 Agent 后，背后大概率就会先走 dataset list / dataset detail 这一步。