Extended services: turning low-level commands into business commands

With a service configuration, the Lovrabet CLI can wrap low-level data queries, SQL, and Backend Function calls into shortcut commands that carry business meaning.

Once configured, the Agent no longer sees only generic capabilities like "query data" — it sees instantly understandable business entry points such as lovrabet crm customer list. Below, we use "query the CRM customer list" to compare how it used to work and what it can look like now.

Before: assembling low-level commands by hand

To query a customer list in the past, the Agent had to know the app, the dataset, the field names, the filter conditions, pagination, and sorting, then assemble something like:

lovrabet data filter \
  --code 客户数据集编码 \
  --params '{
    "where": {
      "status": { "$eq": "active" },
      "owner_id": { "$eq": 81 },
      "customer_name": { "$contain": "科技" }
    },
    "orderBy": [{ "updated_at": "desc" }],
    "currentPage": 1,
    "pageSize": 20
  }'

This low-level query capability is generic, but it drags down business-process efficiency in a few ways:

1. You're assembling a dataset code, field names, filter operators, JSON, pagination, and sorting all at once. The AI can help, but the more complex the business, the more room for error.
2. Another common problem is ambiguity. An enterprise may have CRM customers, order customers, after-sales customers, and member profiles at the same time. If someone just says "look up customers", the Agent has to guess which app and which dataset to hit.

Now: business commands

The same customer-list query becomes:

lovrabet crm customer list

Behind the scenes, this command can be pinned to:

• The CRM app
• The customer dataset
• Default pagination and sorting
• Query conditions like customer status, owner, and keyword
• The underlying field names and filter operators

After an administrator maintains a service configuration, the Agent sees these entry points:

CRM
  lovrabet crm customer list    查询客户列表
  lovrabet crm customer mine    查询我负责的客户
  lovrabet crm customer detail  查询某个客户详情
  lovrabet crm contact list     查询客户联系人
  lovrabet crm followup list    查询客户跟进记录

Before and after

<grid> <column width-ratio="0.500000">

DANGER

Before: low-level commands

The Agent has to figure out the app, dataset, fields, and filters on its own. The user or the Agent has to assemble complex JSON. lovrabet data filter only tells you it's querying data. When several systems all have "customers", it's easy to query the wrong one.

</column> <column width-ratio="0.500000">

TIP

Now: business commands

The config pins down the app, dataset, field mapping, and default conditions. The user states the business question; the Agent picks the business entry point. lovrabet crm customer list makes it obvious you're querying CRM customers. crm customer explicitly scopes customers to the CRM service.

</column> </grid>

What capabilities can be wrapped

Taking a CRM system as an example:

Business entry point	What it can map to underneath
Customer list	Dataset filter query
Customer detail	Dataset single-record query
My customers	Current logged-in user plus filter conditions
Customer statistics	SQL query
Create customer	Backend Function
Update customer status	Backend Function or a data write capability

For writes involving multiple tables, complex validation, transactions, or permission checks, wrap the logic in a Backend Function first, then expose it as a business command through an extended service.

How to configure

For a first-time configuration, start by having the Agent organize the business entry points:

我想为【CRM】配置一组 Lovrabet 扩展服务。

先帮我整理应该开放哪些业务入口。
至少包括：
- 查询客户列表
- 查询我负责的客户
- 查询客户详情
- 查询客户联系人
- 查询客户跟进记录

请先用业务语言说明每个入口的用途，不要直接写配置。

After the entry points are confirmed, have the Agent draft the configuration:

请根据上面的业务入口生成扩展服务配置草案。

每个入口都要说明：
- 背后使用数据集、SQL 还是 Backend Function
- 需要哪些参数
- 参数对应到底层哪个字段
- 默认分页、排序和固定过滤条件
- 风险等级是查询还是写入

Once the configuration is confirmed, import it into the local extended services.

How to verify

After importing the configuration, have the Agent do three things:

检查本机已经导入了哪些扩展服务。

检查扩展服务是否已经出现在 Lovrabet 的帮助和 schema 里。

预览 lovrabet crm customer list 会访问哪个数据集、会带哪些查询条件，不要真正写入数据。

If you can see the service name, command count, configuration source, and the business entry points in the schema, the configuration is live.

Who maintains it, who uses it

The configuration is typically maintained by administrators, delivery engineers, or developers. Regular users don't need to understand the config file — they just state business questions in the Agent, such as "look up my customers", "list high-priority customers", or "show customers with no recent follow-up".

Configuration details

To learn where the config file typically lives, how to import and export it, and how to verify it took effect in help / schema / doctor, see the sub-page <cite doc-id="FUPWdMLCGoHsTkxlWwPcfJPdnwg" file-type="docx" title="扩展服务配置、导入导出与验证" type="doc"></cite>.

For field meanings, the JSON structure, how to write mapTo, and choosing between datasetCode and datatable, see the sub-page <cite doc-id="EK4qdiqcQokjh3xl1gWcDTlznQh" file-type="docx" title="service.json 配置详解" type="doc"></cite>.

Sub-pages

<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>