AI 接入模式：REST、SQL、MCP 应该怎么组合

上一章回答的是“为什么要让 Agent 接 Cube”。这一章回答“具体怎么接”。

1. 三种常见接入模式

模式 A：Agent 通过 REST API 调 Cube

Agent Tool
→ 构造 JSON query
→ /cubejs-api/v1/load
→ 结构化结果

适合：

• 自定义 Agent 工具；
• 后端服务封装；
• 与工作流引擎、函数调用工具集成。

模式 B：Agent 通过 SQL API 调 Cube

Agent / SQL middleware
→ Postgres-compatible connection
→ SELECT ... FROM view/cube
→ 结构化结果

适合：

• 已有 SQL-first 工具链；
• Notebook / 分析助手；
• 希望让 Agent 用“数据库”方式消费语义层。

模式 C：MCP 客户端接 Cube

MCP-compatible client
→ Cube MCP server
→ Chat / analytics interactions

适合：

• 直接在 MCP 生态客户端中调用；
• 希望少写一层自定义工具封装；
• 你已经在用 Claude Code、Codex、Cursor 等支持 MCP 的客户端。

2. REST 模式的优缺点

优点

• 请求结构明确；
• 易做参数校验；
• 容易把语义成员白名单化；
• 非常适合“函数调用 / tool calling”。

缺点

• 如果上层天然是 SQL 思维，使用体验不如 SQL API 直接；
• 复杂 ad-hoc 查询有时表达不如 SQL 自然。

3. SQL 模式的优缺点

优点

• 对分析类用户和 BI 工具友好；
• 更像统一“语义数据库”；
• 容易接已有 SQL 生态。

缺点

• 需要更严格地控制可查询对象；
• 如果 Agent 仍自由生成 SQL，仍需在上层做一定保护。

4. MCP 模式的优缺点

优点

• 对支持 MCP 的 AI 客户端集成更顺手；
• 更像“工具接入”而不是“自建 API 适配”。

缺点

• 它不是语义层本体，而是接入协议层；
• 如果你先天不在 MCP 生态，未必是第一优先级。

5. 最推荐的企业落地顺序

第一阶段

先用 REST API 给内部 Agent 提供稳定工具接口。

第二阶段

给 BI / Notebook / 分析用户开放 SQL API。

第三阶段

如果你的 AI 工作流进入 MCP 生态，再补 MCP 接入。

这是最清晰、最稳妥的路径。

6. 一个很实用的做法：先做语义白名单

无论走 REST、SQL 还是 MCP，建议都先收敛到有限的 views：

• executive_dashboard
• sales_analysis
• customer_success
• finance_revenue

这样 Agent 不会一上来面对整张复杂语义图，而是面对一组更清晰的数据产品入口。

一句话总结

REST 适合把 Cube 封装成稳定的 Agent 工具，SQL 适合接入分析生态，MCP 适合 MCP 客户端；最佳实践通常不是三选一，而是以 REST / SQL 为主线、按需要补充 MCP。