安全与自动化
这篇主要给 技能维护者、交付同学、自动化集成人员 看。业务人员通常只需要知道两件事：只读需求要明确说“只读”，写入需求最好明确说“先预览”。
这套安全机制在保护什么
Lovrabet CLI 可以查数据，也可以写数据。
如果没有护栏，Agent 一旦理解错了需求，就可能把写入动作直接打到真实系统里。
所以当前 runtime CLI 的安全重点是：
- 权限不能随意提
- 高危动作不能静默执行
- 写入前最好先预览
第一层：riskLevel
每个命令都有预设风险等级：
read < write < high-risk-write
| 等级 | 典型动作 |
|---|---|
read | data filter、data getOne、data aggregate、dataset list |
write | data create、data update、config set、app use |
high-risk-write | data delete |
如果当前配置的 riskLevel 不够，CLI 会直接拦截，不会继续执行。
riskLevel 不能通过 CLI 命令修改
这是有意设计。权限变更必须由人手动改配置文件，不能让 Agent 自己提权。
第二层：高危确认
像 data delete 这类高危动作，即使 riskLevel 已经允许，也还会有额外确认。
交互模式下会弹确认：
lovrabet data delete --code <datasetCode> --params '{"id":1}'
非交互模式下必须显式带 --yes：
lovrabet data delete --code <datasetCode> --params '{"id":1}' --yes
第三层：--dry-run
写入类命令建议都先预览：
lovrabet data create --code <datasetCode> --params '{"name":"test"}' --dry-run
--dry-run 的价值很直接：
- 先看这次准备怎么执行
- 确认参数有没有拼错
- 确认目标对象是不是你真正想改的那一个
对 Agent 场景来说，这一步尤其重要。
什么情况下会进入非交互模式
下面这些情况，CLI 会按非交互模式处理：
- 显式传了
--non-interactive或--ci - 环境变量里有
LOVRABET_CI=true - 环境变量里有
CI=true - stdout 不是 TTY，例如重定向或管道输出
一旦进入非交互模式，高危动作就不能靠弹窗确认，只能靠 --yes。
在 CI / Agent 自动化里怎么做更稳
推荐做法：
- 用 AccessKey 登录，不依赖浏览器态
- 把默认候选应用、环境和权限边界提前配好
- 普通写入尽量先
--dry-run - 高危写入必须显式
--yes - 尽量使用
--format json或compress方便后续处理
例如：
script:
- lovrabet data filter --code $DATASET_CODE --format json > backup.json
- lovrabet sql exec --sqlcode $SQL_CODE --params '{"date":"2026-04-20"}' --format json > report.json
给业务侧的建议
如果你是通过 Agent 提需求，最实用的两句话是：
- 只读场景：
只读，不写数据 - 写入场景：
先预览，确认后再执行
这两句话能显著降低 Agent 误操作的概率。
给维护同学的建议
如果某个流程本来就不应该落到真实写入，最好不要只靠口头约束。
更稳妥的做法是：
- skill 里默认只走只读命令
- 写入流程强制加确认步骤
- 让业务人员明确批准后再继续
这比事后排查“为什么 Agent 改了数据”要便宜得多。