ApiGo v6.0 的关键变化，是在原有接口开发、SQL2API、动态数据源和数据预览能力之上，加入面向 AI 办公平台的 MCP 接入。企业可以把数据库查询封装成受控接口，再将这些能力提供给 WorkBuddy、千问办公、Trea Work、豆包等支持场景中的 AI 助手，让“查业务数据”从人工切换系统，变成模型调用明确工具。
从 SQL2API 到 MCP 工具
传统 SQL2API 解决的是“如何快速把查询发布成 HTTP 接口”。MCP 接入进一步解决“AI 助手如何发现、理解并调用这些业务能力”。
一条典型链路可以拆成四层：
- 数据源层：连接 MySQL、Oracle、达梦、TiDB、DolphinDB、Hive、DuckDB 等 SQL 或 NoSQL 数据源。
- 查询层：通过动态 SQL、参数和标签组织业务查询。
- 接口层：把查询发布为可鉴权、可测试的接口。
- AI 工具层：通过 MCP 向办公 AI 暴露工具名称、参数说明和返回结构。
这类组合的价值并不只是少写一个 Controller。更重要的是，数据库结构、业务接口和 AI 工具之间形成了清晰边界：模型负责理解用户意图，ApiGo 负责参数接收与能力发布，数据库仍然只执行预先约束的查询。
例如，“查询某个部门本月已支付订单总额”适合定义成固定工具；“执行用户输入的任意 SQL”则不适合作为办公 AI 能力开放。前者权限边界明确，后者很容易带来数据泄露、越权查询和高负载扫描。
动态数据源适合哪些场景
动态数据源并不意味着每次请求都允许调用方任意选择数据库。更稳妥的用法，是由服务端根据租户、环境或业务标签映射到已经登记的数据源。
常见场景包括：
- SaaS 系统按租户隔离数据库。
- 开发、测试和生产环境使用相同接口定义，但绑定不同数据源。
- 同一指标分别来自 MySQL、TiDB 或 Hive，需要通过统一接口暴露。
- 使用 DuckDB 做本地文件分析，再把聚合结果提供给内部助手。
标签可以参与接口治理。例如给工具增加 finance、readonly、tenant-aware 等标签，便于在接入 MCP 客户端时筛选能力。不过标签不能代替真正的授权检查，服务端仍需验证调用者身份、租户范围和字段访问权限。
一个可改造的 SQL2API 示例
下面示例假设存在 orders 表，并希望发布一个只读的部门月度汇总接口。字段名、动态 SQL 语法以及发布路径需要按实际部署的 ApiGo v6.0 配置调整。
CREATE TABLE orders (
id BIGINT PRIMARY KEY,
department_id BIGINT NOT NULL,
amount DECIMAL(12, 2) NOT NULL,
status VARCHAR(32) NOT NULL,
paid_at TIMESTAMP NULL
);
SELECT
department_id,
COUNT(*) AS order_count,
COALESCE(SUM(amount), 0) AS paid_amount
FROM orders
WHERE department_id = :department_id
AND status = 'PAID'
AND paid_at >= :start_time
AND paid_at < :end_time
GROUP BY department_id;
这里使用命名参数，而不是把用户输入拼接进 SQL。发布后，可以用类似下面的命令验证接口。示例中的 URL、令牌和路径是假设值，运行前需要替换成实际环境配置：
export APIGO_BASE_URL="http://127.0.0.1:8080"
export APIGO_TOKEN="replace-with-your-token"
curl --fail-with-body \
--request POST \
"$APIGO_BASE_URL/api/report/department-paid-orders" \
--header "Authorization: Bearer $APIGO_TOKEN" \
--header "Content-Type: application/json" \
--data '{
"department_id": 42,
"start_time": "2025-01-01T00:00:00Z",
"end_time": "2025-02-01T00:00:00Z"
}'
理想的响应应保持结构稳定，避免模型依赖自然语言文本：
{
"department_id": 42,
"order_count": 128,
"paid_amount": 356420.50,
"currency": "CNY"
}
currency 如果不是数据库字段，可以在接口层补充。对 AI 工具来说，稳定的字段名、类型和单位说明，通常比一段“查询成功”的描述更有价值。
MCP 客户端配置可以怎样组织
来源摘要没有给出 ApiGo v6.0 的具体 MCP 端点、传输模式和客户端字段，因此下面只是一个可改造的配置骨架，不代表产品的固定配置格式。实际使用时，应根据 ApiGo 部署文档以及目标办公平台支持的 MCP 传输方式修改。
假设部署提供基于 HTTP 的 MCP 服务，客户端配置可以表达为：
{
"mcpServers": {
"company-data": {
"transport": "streamable-http",
"url": "https://api.example.com/mcp",
"headers": {
"Authorization": "Bearer ${APIGO_MCP_TOKEN}"
}
}
}
}
接入后，一个面向模型的工具定义至少要明确用途、参数约束和返回语义。例如可以按下面的思路设计：
name: get_department_paid_orders
description: 查询指定部门在给定时间范围内的已支付订单汇总，只返回调用者有权访问的部门数据。
input:
type: object
required:
- department_id
- start_time
- end_time
properties:
department_id:
type: integer
minimum: 1
start_time:
type: string
format: date-time
end_time:
type: string
format: date-time
output:
type: object
properties:
department_id:
type: integer
order_count:
type: integer
paid_amount:
type: number
currency:
type: string
工具描述中应避免“查询所有信息”这类宽泛表述。名称越具体，参数范围越窄，模型越容易在正确时机调用，也越方便平台记录审计日志。
上线前不要忽略治理
AI 接入会放大接口易用性，也会放大接口本身的风险。上线前至少检查以下项目：
- 数据库账号是否只拥有必要的只读权限。
- 是否使用参数绑定，并禁止直接执行模型生成的原始 SQL。
- 租户和部门权限是否在服务端验证，而非依赖提示词约束。
- 是否限制时间跨度、分页大小、并发数和查询超时。
- 返回结果是否过滤手机号、身份证号、密钥等敏感字段。
- MCP 调用是否记录用户、工具、参数摘要、耗时和结果状态。
- 写操作是否需要人工确认、幂等键和独立授权。
ApiGo v6.0 适合从低风险、只读、结果可校验的查询开始，例如库存汇总、项目状态和部门统计。等权限模型、审计和限流稳定后，再逐步开放复杂分析或写入能力。MCP 让接口更容易被 AI 使用，但真正决定生产可用性的，仍是接口契约和数据治理。