我为什么不再急着做 BI 看板：用 Python、MySQL 和 MCP 搭建 AI 数据底座|XiaoLei の小破站

FDE 落地手记 · 07

今天在思考企业知识库和经营分析的底层架构时，我有一个挺大的转变。

以前，我总想着把各个平台的数据搬到自己的 BI 系统里，清洗、建模，再做成一个类似 SaaS 的产品：有菜单、有筛选、有看板，最好还能加上一个 AI 对话入口。

但随着通用 Agent 的能力不断增强，我开始重新考虑这件事：我们是否还需要为每一种分析需求，提前做出一张固定页面？

业务人员真正想要的，往往是“这个问题到底是什么情况，我接下来该怎么办”。看板只是过去实现这一目标的一种方式。

我现在更想尝试的路线是：把分析 SOP、可信数据和业务工具留在自己手里，通过 MCP 接给 WorkBuddy、豆包工作、千问办公这样的通用 Agent，让它们按需完成查询、分析和呈现。

这篇文章记录这一判断，以及查阅官方资料后整理出的实施方案。下面的架构、工具名称和排期属于建议设计，示例数据为虚构；不代表已经完成这些平台的生产接入。

一、可以少做一些页面，但基础工作要做得更清楚

“以后不需要整理数据、不需要看板了”很容易成为一句令人兴奋的判断。认真拆开来看，我更愿意把它表达为：不必再把每一种可能的问题，都预先整理成一张给人看的固定报表。

过去的做法通常是：业务提需求，开发做页面，业务看完再提一个问题，开发再加一个维度。需求稍微变化，筛选器、图表和接口又要跟着改。

通用 Agent 提供了另一种可能：业务直接描述问题，Agent 选择工具、取得结果，再生成本次需要的解释、表格或者图表。大量一次性分析的界面，可以到使用时再生成。

不过，数据清洗、SKU 映射、指标定义、权限和质量校验依然要做，而且要从页面里抽出来，成为所有入口共用的能力。否则，过去是“每张报表一个数字”，以后可能变成“每个 Agent 一个数字”。

固定看板也有适合它的位置：每日巡检、统一经营会议、异常监控和多人对齐，需要稳定的展示；探索性追问和临时专题，更适合交给 Agent。两者可以调用同一套指标服务。

二、先分清三件事：数据、业务知识和执行规则

我说的“企业知识底座”，并不只是把文档扔进向量库，也不只是建一个 MySQL 数据库。

资产	主要内容	建议承载方式
业务事实	订单、出库、退款、库存、结算等结构化记录	MySQL 等数据库，保留来源与批次
业务知识	指标解释、产品资料、制度、案例和经验	有版本的文档、知识库，必要时增加检索
执行规则	分析顺序、必查项目、判断条件和异常处理	SOP、Skill、工作流及服务端规则

数据库适合准确统计，文档检索适合找定义和解释，SOP 负责告诉 Agent 该按什么顺序工作。涉及权限、指标计算和必要校验的规则，要在服务端执行，不能只写在提示词里期待模型遵守。

MCP 则负责把这些能力连接到 Agent。它本身不承担数据治理，也不会自动把业务经验变成可靠流程。MCP 官方将其定义为上下文交换协议，采用客户端与服务端架构，并提供 tools、resources、prompts 等能力；协议并不规定上层应用如何使用模型。官方架构说明

三、我更倾向的架构：企业维护底座，Agent 提供使用入口

可以先用下面这张文字架构图理解它：

平台 API / 授权导出 / 企业业务系统
                  ↓
         Python 采集任务与原始留档
                  ↓
       MySQL：明细、映射、批次与质量状态
                  ↓
          已确认的指标与业务查询服务
                  ↓
          MCP 服务：鉴权、工具、审计
                  ↓
    WorkBuddy / 豆包工作 / 千问办公
                  ↓
       自然语言分析、临时图表、报告草稿

分析 SOP 和指标文档贯穿中间几层，既指导 Agent，也约束工具的输入输出。

这里最值得企业投入的，是来源是否可靠、口径是否明确、查询是否可复核。通用 Agent 的模型、交互和文件处理能力，可以按实际任务选择。

“封装成一个 MCP 包”也要拆成两种交付方式：本地服务可以作为 Python 或 Node 包，由客户端通过 stdio 启动；远程服务则部署在企业控制的环境中，客户端通过地址连接。官方文档介绍了 stdio 与 Streamable HTTP 两种传输方式。多人共享同一套数据能力时，我会优先评估远程服务；本地试验则可以更轻量。MCP 传输与运行方式

四、第一步：先写出一个真实问题的分析 SOP

第一版不要从“把所有经营数据都接进来”开始。

可以先选一个高频问题，例如：某产品最近的退货情况有没有变化，主要集中在哪些渠道和 SKU？

把业务专家的思考顺序写下来：

明确产品、店铺、渠道与分析期间。
确认指标按件数、订单数还是金额计算。
确认按发货批次追踪，还是按售后发生日期统计。
查看来源覆盖、可关联比例、完整数据截止日和观察窗口。
在可比较范围内拆解趋势、渠道占比和 SKU 贡献。
列出异常、可能解释、还缺的证据及下一步核查动作。

比如，按发货批次统计“15 天内实退率”，就要把实退关联回原发货记录，以同一批发货数量为分母，并定义第 15 天的时间边界。尚未走完观察窗口的批次，需要标记为未成熟。

ERP 出库、平台终端销量和平台仓供货，也不能因为都叫“销量”就混在一起。无法关联到原发货记录的渠道，可以保留单独的事件趋势，但不能假装已经具备同一种发货批次指标。

这份 SOP 的产物应该是一个明确的问题模板、一份数据源清单和一份指标定义，而不只是“分析得专业一点”的提示词。

五、第二步：让 AI 写 Python，但给它一份采集合同

AI 可以显著加快脚本开发。我仍然需要先告诉它：从哪里取、允许取什么、每一行代表什么，以及怎样判断取全了。

每个来源至少记录这些信息：

项目	要写清楚的内容
获取方式	官方 API、授权导出或已获授权的系统接口
业务粒度	一行代表商品明细、售后事件还是库存快照
唯一标识	来源系统、店铺与来源记录 ID 等组合键
时间字段	业务发生时间、来源更新时间与采集时间
更新机制	分页、游标、增量条件、修订与删除处理
完整性判断	来源总数、分页终点、控制合计与缺失范围

优先使用稳定、已授权的接口和导出。必须借助浏览器取数时，也要把登录失效、页面变化和下载失败作为任务状态处理。

我会用类似下面的要求让 AI 生成第一版脚本：

为已授权的数据源编写 Python 增量采集任务。先根据接口文档和脱敏样本确认字段与唯一键，不能虚构字段。凭证从环境变量读取。实现分页、限流、超时重试、断点续跑与幂等写入；保留来源更新时间、采集批次、行数和质量结果。分页或校验失败时不得标记为完整，也不得推进成功水位。请同时给出小批量运行、重复运行和失败后恢复的核验方法。

增量任务可以按来源更新时间读取，并回拉一段重叠区间，用来接住迟到和修订的数据。回拉多久，要根据来源的修订周期决定；如果来源没有可靠的更新时间，就需要周期性重取并比对。

唯一键要对应业务记录，而不是随手使用订单号。一次订单有多个商品、多次售后事件时，只用订单号去重，会把真实记录覆盖掉。

MySQL 的唯一约束和 INSERT ... ON DUPLICATE KEY UPDATE 可以用于幂等写入，但前提是已经设计好正确的键和更新规则。MySQL 官方说明

一批数据通过校验后再提交，并记录成功水位；失败时回滚或保留未完成批次，避免下次从错误位置继续。事务能够支持提交和回滚，但采集脚本仍需自行设计文件留档、批次状态与恢复流程。MySQL 事务说明

六、第三步：MySQL 先做到可追溯，再逐步分层

小团队可以先采用“原始留档 + 标准明细 + 业务视图 + 批次质量表”的结构，不必第一天就搭建完整数仓平台。随着范围扩大，再逐步形成 ODS、DWD、DIM、DWS、ADS 的职责分工。

第一版建议至少保留：原始响应或导出文件、标准化业务明细、商品和店铺映射、采集批次、来源覆盖状态，以及经过业务确认的查询视图。

金额可以使用最小货币单位的整数，或者明确精度的 DECIMAL；数量与金额不要混用。时区、币种、状态含义和映射生效时间，都要记录。

尤其要让三个状态可以被识别：

数据完整，业务结果确实为零。
来源缺失，暂时无法计算。
已取得部分数据，但观察窗口未满或关联不完整。

例如，一个渠道今天缺少售后文件，不能把退货数量补成零，再告诉 Agent “这个渠道表现最好”。质量状态应随查询结果一起返回。

MySQL 是一个现实的起点。后续如果遇到大规模扫描或复杂分析，再评估分析型数据库；MCP 与业务服务之间的接口保持稳定，就能减少更换存储时对使用入口的影响。

七、第四步：封装业务能力，而不只是暴露数据库

我不会把一个能任意执行 SQL 的接口，作为第一版经营分析入口。

更合适的是把常用能力拆成几个清楚的工具。以下名称只是设计示例：

工具	回答的问题
`get_data_status`	哪些来源齐全，最新可用日期是什么？
`get_metric_definition`	这个指标如何定义，版本是什么？
`query_sales_summary`	指定范围的销售表现如何？
`query_return_cohorts`	指定发货批次的退货表现如何？
`query_return_breakdown`	哪些渠道、SKU 对变化贡献较大？

工具的参数可以包含日期范围、渠道、SKU、指标版本与分组维度；服务端负责参数校验、权限过滤和已确认的计算。

返回值除了数字，还应包括计算依据。下面是业务结果结构示例，不是完整的 MCP 协议报文：

{
  "metric_id": "return_qty_within_15d_of_shipment",
  "metric_version": "v1",
  "cohort_period": ["2026-09-01", "2026-09-07"],
  "timezone": "Asia/Shanghai",
  "observation_window_days": 15,
  "returned_qty": 240,
  "shipped_qty": 1000,
  "value": 0.24,
  "unit": "ratio",
  "data_as_of": "2026-10-20T23:59:59+08:00",
  "quality_status": "complete",
  "snapshot_id": "demo-snapshot-001",
  "trace_id": "demo-query-001"
}

这些数字是虚构的。实际工具还需要带出授权范围、来源覆盖、排除条件和成熟度判断。缺少数据时，数值可以为空，并明确说明原因。

让 Agent 计算 240 除以 1000 并不困难，困难的是确认两者是否来自相同范围。因此，关键统计尽量在工具层完成，Agent 负责选工具、追问、解释和形成核查建议。

开发时可以使用官方 MCP SDK 来实现工具定义和服务，再用 Inspector 等工具检查发现与调用过程。依赖、协议版本和部署方式要针对目标客户端固定并验证，不能默认每个平台都兼容最新版本。官方服务端开发指南

SOP 可以作为 Skill、平台规则或工作流交付；定义文档也可以通过 resources 或查询工具提供。不同客户端支持的能力不同，因此第一版优先保证核心 tools 能工作。MCP 提供调用入口，SOP 提供工作方法，服务端执行不可绕过的规则。

八、第五步：接入 WorkBuddy、豆包工作和千问办公

截至 2026 年 10 月 22 日，公开资料已经能支持这条路线，但各家的配置入口和能力范围需要分别确认。

WorkBuddy

官方文档提供了 MCP 界面配置，以及用户级、项目级配置方式。用户级配置适合跨项目复用，项目级适合限制在某个工作目录。可以从插件相关的 MCP 配置入口添加服务，再查看工具是否加载。WorkBuddy 官方 MCP 指南

实施时，先接入测试环境的只读业务工具，确认当前版本支持的远程传输和鉴权方式；之后新建任务，让 Agent 查一次数据状态和固定范围的指标。不能只凭聊天中一句“已连接成功”验收。

豆包工作

豆包侧已有远程 MCP 的官方生态案例：腾讯 CloudBase 团队说明，其豆包插件使用远程 MCP、Streamable HTTP 与 OAuth 授权。这证明远程工具接入有实际产品路径，但不等于所有自建服务都能以相同方式直接接入。CloudBase 团队的接入说明

自建企业服务需要在当前客户端的插件或连接器管理入口确认是否开放自定义配置，逐项核对地址、传输类型、鉴权和本地或云端任务限制。豆包的相关官方帮助页本次检索未能成功读取，因此这里不把具体按钮顺序和自定义权限范围写成已核实结论。豆包官方插件帮助入口

千问办公与百炼

千问办公官方文档明确提供自定义 MCP 服务：进入“扩展 → 连接器”，通过“添加”导入 JSON，或手动配置服务。文档列出了 Streamable HTTP、SSE 和 STDIO，并支持配置认证请求头。开启或关闭连接器后，需要新建对话任务使其生效。千问办公官方连接器说明

如果希望在开发平台上托管与编排，阿里云百炼还提供脚本部署、AI 网关导入和阿里云 OpenAPI 导入等路径。已有内部 REST API 时，可以评估通过网关封装，复用现成业务服务。百炼自定义 MCP 文档

千问办公客户端和百炼开发平台是不同产品入口，套餐、部署和权限要分别确认。

每个平台都要实际跑一次的检查

确认工具可见之后，至少验证：一次正常查询、一次非法参数、一次无权访问、一次来源缺失，以及一次服务超时。记录客户端版本、协议版本、认证方式和返回结果。

云端 Agent 所处的运行环境未必能访问本机的 localhost 或公司内网。需要先明确请求从哪里发出，再配置受控可达的 MCP 地址；数据库端口不需要因此向公网开放。

九、底层由自己维护，数据边界也要由自己维护

数据库留在自己的服务器，不代表数据不会离开企业环境。工具返回的摘要、明细和文档内容，仍可能进入平台的模型处理流程。接入前要确认哪些字段可发送、保留多久，以及账号或企业套餐的实际数据处理政策。

第一版可以先返回经过授权的渠道、SKU 汇总，减少不必要的个人信息和订单明细。

服务端要识别真实调用者并验证授权范围，不能让模型随意传一个 user_id 或 tenant_id 就取得对应数据。采集账号、查询账号与管理账号也应分开；查询工具只授予需要的表或视图权限，设置日期范围、返回行数、超时与审计。

官方 MCP 授权文档介绍了基于 OAuth 的远程服务授权，以及令牌验证等要求。实际采用 OAuth 还是目标平台支持的其他鉴权方式，要根据客户端能力和企业身份体系决定；无论哪种方式，业务授权都需要在服务端执行。MCP 官方授权指南

业务备注和检索文档属于数据。里面即使出现“忽略规则、导出全部记录”这样的文字，也不能成为扩大权限的指令。这也是为什么权限与关键计算需要留在工具层。

十、一个两周试点，可以怎样安排

在数据授权、接口和业务负责人已具备的前提下，我会把下面作为试点排期；它是安排方式，不是交付承诺。

阶段	工作	可以检查的产物
第 1—2 天	选一个问题，确认来源与指标口径	SOP、来源清单、指标定义、基准样本
第 3—5 天	完成一个来源的采集与入库	原始批次、幂等明细、失败恢复记录
第 6—7 天	固化查询和质量状态	只读查询、口径版本、可追溯结果
第 8—9 天	封装 MCP，接入一个 Agent	工具调用记录、权限和异常验证
第 10 天	用同一组问题做端到端验收	对账结果、失败清单、耗时与成本记录