SQL 与 BFF
这篇主要给 技能编写者、交付同学、Agent 维护者 看。业务人员一般不需要知道
sqlcode或functionName，更不需要自己去枚举系统里有哪些 SQL 或 BFF。
先说结论
当标准的 data 命令不够用时，Lovrabet CLI 还可以复用平台里已经存在的 SQL 和 BFF：
sql exec：适合复杂查询、口径统计、多表联查bff exec：适合已经封装好的业务逻辑、聚合接口、事务流程
同时也提供：
sql detailbff detail
方便维护同学确认参数和定义。
为什么没有 sql list 和 bff list
这是有意设计，不是少做了。
原因很简单：
- SQL 和 BFF 往往承载的是比较敏感的业务逻辑
- 不适合让业务侧或通用 Agent 自由扫一遍再随意调用
- 更合理的做法是：由技能维护者把允许调用的 SQL / BFF 写进 skill，让 Agent 按业务流程走
也就是说：
- 业务人员说的是“我要什么业务结果”
- skills 决定“该调哪条 SQL / 哪个 BFF”
- Agent 负责实际调用
sql detail / sql exec
什么时候适合用 SQL
- 需要复杂多表查询
- 需要统一统计口径
- 需要输出日报、周报、对账结果
- 单靠
data aggregate不够表达
查看 SQL 定义
lovrabet sql detail --sqlcode 2305f915-dd48cd4c
执行 SQL
lovrabet sql exec --sqlcode 2305f915-dd48cd4c --params '{"date":"2026-04-20"}'
sqlcode 的格式是：
xxxxxxxx-xxxxxxxx
bff detail / bff exec
什么时候适合用 BFF
- 需要一个已经封装好的业务接口结果
- 需要跨多个数据源或多步业务逻辑
- 需要统一快照、统一视图、统一处理结果
查看 BFF 定义
lovrabet bff detail --id 42
这里的 --id 是脚本 ID，不是函数名。
执行 BFF
lovrabet bff exec --name processOrder --params '{"orderId":1,"action":"ship"}'
这里的 --name 才是函数名。
SQL 和 BFF 怎么选
| 你要的结果 | 更适合的入口 |
|---|---|
| 单表查询、单表汇总 | data filter / data aggregate |
| 复杂统计、复杂联查 | sql exec |
| 已经封装好的业务流程结果 | bff exec |
一个简单判断方式：
- 更像“查数据库口径” → 倾向 SQL
- 更像“调现成业务接口” → 倾向 BFF
业务人员应该怎么说
业务人员通常不应该这样说：
- 帮我跑一下
sqlcode=2305... - 帮我执行
functionName=processOrder
更自然的说法应该是：
- 帮我生成昨天的运营日报
- 帮我拉一个客户售后统一快照
- 帮我看这笔订单为什么没有继续往下流转
然后由 Agent 和 skill 决定背后到底是调 SQL 还是调 BFF。
给技能维护者的一条建议
如果某个业务动作是高频、稳定、可复用的，不要让 Agent 每次都临时猜。
更好的做法是：
- 在 skill 里明确这个场景该走哪条 SQL / 哪个 BFF
- 说明输入需要什么参数
- 说明输出应该怎么解释
这样业务人员得到的是“稳定结果”，不是“猜一次命令碰一次运气”。