跳到主要内容

常见问题

Q：业务人员需要会敲 CLI 吗？​

不需要。

Lovrabet CLI 更像 Agent 背后的执行层。
业务人员更应该做的是：

  • 把业务问题说清楚
  • 说明只读还是允许写入
  • 如果有订单号、手机号、客户 ID 这类关键标识，尽量一起给出

真正的命令，通常由 Agent 和 skills 在后台决定。

Q：为什么没有 sql list 和 bff list？​

这是有意设计。

原因是 SQL 和 BFF 往往对应真实业务逻辑，不适合让通用 Agent 随便扫一遍再自由执行。
更推荐的方式是：

  • 由维护同学在 skill 里明确“这个场景该调用哪条 SQL / 哪个 BFF”
  • 业务人员只描述业务目标
  • Agent 按 skill 执行

Q：--global 到底是什么意思？​

它控制配置读写是否明确落到全局配置。

简单理解：

  • 全局配置：这台机器上都能用
  • 本地配置：当前目录下可选的 .lovrabet.json，只保存用户意图，不代表平台项目

常见场景：

  • auth login 默认偏向全局，方便多项目复用同一把 AK
  • app use 只设置 defaultApp 默认候选
  • config set / config delete 属于高级配置维护命令，无本地配置且未传 --global 时会拒绝执行，避免静默污染全局配置

如果你只是业务侧使用 Agent，通常不用自己管这个细节。

Q：为什么没有 app add？​

因为 runtime CLI 已经不再把“本地维护一套应用 profile 列表”当主模型。

当前推荐方式是：

  • 用 app list 看当前账号可见应用
  • 用 app use 设置默认候选应用
  • 让远端应用目录 + 本地 cache 作为事实来源

默认候选应用不是强上下文。如果用户需求明显指向订单、商品、库存、CRM 等业务域，应先在默认候选下验证数据集；验证不成立再扩大到应用列表。

Q：我一定要知道 appcode、dataset code、sqlcode 吗？​

不一定。

理想情况下：

  • 业务人员不需要知道
  • skill 维护者最好知道
  • Agent 在必要时可以先做发现动作

如果你能提供这些信息，执行会更快。
如果你不知道，也可以先让 Agent 帮你探路。

Q：怎么提需求更容易让 Agent 做对？​

尽量一次说清楚这几件事：

  • 哪个业务系统或业务域
  • 哪个业务对象
  • 时间范围或筛选条件
  • 最终想拿到什么结果
  • 这次是只读，还是允许写入

例如：

帮我找近 7 天付款成功但未发货的订单，按仓库汇总，只读。

比“帮我查一下订单”有效得多。

Q：写入类需求怎么说更安全？​

推荐直接在需求里加一句：

  • 先预览，再执行
  • 只读，不写数据

这样 Agent 更容易自动走到正确的安全路径上。

Q：--dry-run 有什么用？​

它会先展示“这次准备怎么执行”，但不会真的写入。

对以下场景尤其有用：

  • 批量修正状态
  • 补录数据
  • 删除前最后确认
  • 你不完全确定这次参数是否正确

当前 Lovrabet Runtime CLI 走的是 AccessKey 主路径。
如果你还在用旧文档里的 Cookie 说法，可以直接按新版 AccessKey 理解。

Q：Agent 写错了怎么办？​

先分两类看：

  • 命令都没跑起来：优先看登录、默认候选应用、doctor、日志
  • 命令跑起来了，但结果不对：优先检查 skill、业务 prompt 和业务流程假设

很多时候问题不在 CLI 本身，而在“技能里绑定的业务流程已经过时”。