APIJSON 8.2：把 StarRocks、AI Skills 与 MCP 接入可治理的数据 API

APIJSON 的核心思路，是让客户端用结构化 JSON 描述查询和写入需求，再由服务端协议解析器与 ORM 自动完成数据访问。8.2 版本标题进一步出现了 StarRocks、AI Skills 和 MCP，说明它的应用边界正在从常规业务 CRUD，延伸到分析型数据与 AI 工具调用场景。

不过，自动化不等于取消后端治理。接口越通用，权限、查询成本和模型可见性的约束就越重要。

万能 API 改变了什么

传统前后端协作通常围绕固定接口展开：新增筛选字段要改 DTO，增加关联数据要改 Service，调整返回结构还要同步接口文档。APIJSON 把一部分变化转移到请求 JSON 中，让调用方声明需要哪些对象、字段和关联关系，服务端负责解析并执行。

下面是一个可以改造的请求示例。假设本地 APIJSON 服务的查询入口为 http://localhost:8080/get，并且已经暴露 User 模型；实际地址、表名和字段必须按项目配置修改：

curl -sS -X POST 'http://localhost:8080/get' \
  -H 'Content-Type: application/json' \
  -d '{
    "User": {
      "id": 1001
    }
  }'

分页查询也可以由请求结构表达。以下写法用于说明典型实践，具体关键字和排序语法应以项目采用的 APIJSON 8.2 配置为准：

curl -sS -X POST 'http://localhost:8080/get' \
  -H 'Content-Type: application/json' \
  -d '{
    "[]": {
      "count": 20,
      "page": 0,
      "User": {
        "status": "ACTIVE",
        "@column": "id,name,status,createdAt"
      }
    }
  }'

这种模式适合需求变化频繁、前后端分离的中小型项目。它减少的是重复接口代码，而不是数据库设计、鉴权和性能治理工作。

StarRocks 更适合承接分析查询

StarRocks 面向分析型负载。把它放到 APIJSON 体系中时，一个合理的工程边界是：事务数据库继续负责订单、账户等在线写入，StarRocks 承接聚合报表、趋势分析和大范围筛选。不要因为调用协议统一，就把两类负载混在同一个连接池和超时策略里。

由于摘要没有给出 8.2 的具体 StarRocks 配置格式，下面给出的是一份可改造的部署假设，而不是版本内置配置的逐项说明：

# application-analytics.yml
spring:
  datasource:
    url: jdbc:mysql://starrocks-fe:9030/analytics
    username: apijson_reader
    password: ${STARROCKS_PASSWORD}
    driver-class-name: com.mysql.cj.jdbc.Driver
    hikari:
      maximum-pool-size: 10
      connection-timeout: 3000
      read-only: true

analytics:
  statement-timeout-seconds: 10
  maximum-page-size: 500
  allowed-models:
    - SalesDaily
    - ProductTrend

这份配置刻意使用只读账号，并限制连接池、超时、分页上限和可访问模型。真正接入时还应检查 APIJSON 8.2 使用的数据库适配器、SQL 方言支持以及 StarRocks 对目标查询的执行计划。

可以用以下 SQL 在 StarRocks 中创建最小权限账号；数据库名、网段和授权语法需要根据实际版本调整：

CREATE USER 'apijson_reader'@'10.%' IDENTIFIED BY 'replace-with-a-secret';
GRANT SELECT ON analytics.* TO 'apijson_reader'@'10.%';

AI Skills 与 MCP：不要让模型直接碰数据库

AI Skills 和 MCP 带来的关键变化，不是让大模型自由生成 SQL，而是把受控的数据能力包装成工具。模型负责选择工具并填写参数，APIJSON 服务继续执行身份校验、字段过滤、查询限制和审计。

可以这样实践：对 MCP 只暴露一个窄化的“销售趋势查询”工具，由服务端把参数转换成经过审核的 APIJSON 请求。下面是一个工具定义示意，字段结构需按实际 MCP SDK 调整：

{
  "name": "query_sales_trend",
  "description": "Query aggregated daily sales for an authorized tenant",
  "inputSchema": {
    "type": "object",
    "properties": {
      "startDate": { "type": "string", "format": "date" },
      "endDate": { "type": "string", "format": "date" },
      "productId": { "type": "integer" }
    },
    "required": ["startDate", "endDate"]
  }
}

服务端不要接受模型传入任意表名、字段名或 SQL。更稳妥的映射方式如下：

AI Agent
  -> MCP tool: query_sales_trend(startDate, endDate, productId)
  -> 参数校验与租户身份注入
  -> 固定模型 SalesDaily 的 APIJSON 请求
  -> StarRocks 只读查询
  -> 行数截断、敏感字段过滤与审计记录

还应把租户 ID 从登录态或服务凭证中注入，而不是信任模型提供的 tenantId。即使模型遭遇提示词注入，它也只能调用预先授权的模型和参数范围。

上线前需要收紧的边界

采用 APIJSON 8.2 时，可以按以下清单推进：

• 为普通业务库和 StarRocks 分别设置账号、连接池、超时与限流策略。
• 默认拒绝模型和字段，仅开放经过审核的查询对象。
• 限制分页大小、关联层数、聚合维度和单次查询时间。
• 对写接口启用更严格的角色校验、幂等控制与操作审计。
• MCP 工具使用固定业务语义，不透传 SQL、表名或任意 APIJSON 请求体。
• 在压测中覆盖高基数筛选、深分页、复杂关联和并发 AI 调用。
• 记录请求模板、调用身份、耗时、返回行数和失败原因，但避免把敏感数据写入日志。

APIJSON 的价值在于压缩重复 CRUD 的开发与沟通成本。接入 StarRocks 后，它可以进一步统一业务查询与分析查询的调用方式；接入 AI Skills 和 MCP 后，它又能成为智能体与数据系统之间的协议层。真正决定系统能否稳定上线的，仍然是清晰的数据边界、最小权限和可观测的查询治理。