扩展服务：把底层命令变成业务命令
Lovrabet CLI 可以通过一份服务配置，把原本偏底层的数据查询、SQL 和 Backend Function 调用，封装成带业务含义的快捷命令。
配置完成后，Agent 不再只看到“查数据”这种通用能力，而是能看到 lovrabet crm customer list 这种一眼能明白的业务入口。下面用“查询 CRM 客户列表”这个功能，对比以前怎么用、现在可以变成什么样。
以前：直接拼底层命令
过去要查询客户列表，Agent 可能需要知道应用、数据集、字段名、过滤条件、分页和排序，再拼出类似这样的命令：
lovrabet data filter \
--code 客户数据集编码 \
--params '{
"where": {
"status": { "$eq": "active" },
"owner_id": { "$eq": 81 },
"customer_name": { "$contain": "科技" }
},
"orderBy": [{ "updated_at": "desc" }],
"currentPage": 1,
"pageSize": 20
}'这种偏底层查询的能力虽然通用，但有几个业务流程效率的情况
- 这里要同时拼数据集编码、字段名、过滤符、JSON、分页和排序。AI 可以帮忙拼，但业务越复杂，越容易错。
- 还有一个常见问题是歧义。一个企业里可能同时有 CRM 客户、订单客户、售后客户、会员资料。如果只说“查客户”，Agent 需要猜应该访问哪个应用、哪个数据集。
现在：变成业务命令
同样是查询客户列表，可以变成：
lovrabet crm customer list这条命令背后可以固定映射到：
- CRM 应用
- 客户数据集
- 默认分页和排序
- 客户状态、负责人、关键词等查询条件
- 底层字段名和过滤符号
管理员维护一份服务配置后，Agent 就能看到这些入口：
CRM
lovrabet crm customer list 查询客户列表
lovrabet crm customer mine 查询我负责的客户
lovrabet crm customer detail 查询某个客户详情
lovrabet crm contact list 查询客户联系人
lovrabet crm followup list 查询客户跟进记录前后对比
<grid> <column width-ratio="0.500000">
DANGER
以前：底层命令
Agent 要自己判断应用、数据集、字段和过滤条件。 用户或 Agent 要拼复杂 JSON。 lovrabet data filter 只能看出是在查数据。 多个系统都有“客户”时容易查错。
</column> <column width-ratio="0.500000">
TIP
现在：业务命令
配置里固定好应用、数据集、字段映射和默认条件。 用户只说业务问题，Agent 选择业务入口。 lovrabet crm customer list 一眼能看出是在查 CRM 客户。 crm customer 明确限定在 CRM 服务下的客户。
</column> </grid>
可以封装哪些能力
以CRM系统为例
| 业务入口 | 背后可以映射到什么 |
|---|---|
| 客户列表 | 数据集过滤查询 |
| 客户详情 | 数据集单条记录查询 |
| 我的客户 | 当前登录用户加过滤条件 |
| 客户统计 | SQL 查询 |
| 新建客户 | Backend Function |
| 更新客户状态 | Backend Function 或数据写入能力 |
涉及多表、复杂校验、事务或权限判断的写操作，建议先封装成 Backend Function，再通过扩展服务暴露成业务命令。
怎么配置
第一次配置时，可以先让 Agent 整理业务入口：
我想为【CRM】配置一组 Lovrabet 扩展服务。
先帮我整理应该开放哪些业务入口。
至少包括：
- 查询客户列表
- 查询我负责的客户
- 查询客户详情
- 查询客户联系人
- 查询客户跟进记录
请先用业务语言说明每个入口的用途，不要直接写配置。确认入口后，再让 Agent 生成配置草案：
请根据上面的业务入口生成扩展服务配置草案。
每个入口都要说明：
- 背后使用数据集、SQL 还是 Backend Function
- 需要哪些参数
- 参数对应到底层哪个字段
- 默认分页、排序和固定过滤条件
- 风险等级是查询还是写入配置确认后，再导入本机扩展服务。
怎么检查
配置导入后，让 Agent 做三件事：
检查本机已经导入了哪些扩展服务。检查扩展服务是否已经出现在 Lovrabet 的帮助和 schema 里。预览 lovrabet crm customer list 会访问哪个数据集、会带哪些查询条件，不要真正写入数据。能看到服务名称、命令数量、配置来源和 schema 里的业务入口，就说明配置已经生效。
谁维护，谁使用
通常由管理员、交付同事或研发同事维护配置。普通使用者不需要理解配置文件，只要在 Agent 里说业务问题，例如“查我的客户”“列出高优先级客户”“看一下最近没有跟进的客户”。
配置细节
想了解配置文件一般放哪里、如何导入导出、如何在 help / schema / doctor 里验证生效，见子文档 扩展服务配置、导入导出与验证。
想继续查看字段含义、JSON 结构、mapTo 写法、datasetCode 和 datatable 的选择，见子文档 service.json 配置详解。
子文档
<sub-page-list space-id="7535363963853209604" wiki-token="Q7b8wF6DGilMs0kAUiPce9jkndh"><sub-page doc-id="FUPWdMLCGoHsTkxlWwPcfJPdnwg" file-type="docx" title="扩展服务配置、导入导出与验证"/><sub-page doc-id="EK4qdiqcQokjh3xl1gWcDTlznQh" file-type="docx" title="service.json 配置详解"/></sub-page-list>