我设计的 AIPDataAgent 产品的设计思路

一、AIPDataAgent 怎么来的

上个月，一个做电商的朋友跟我吐槽了一件事。

他们团队每周要花两天跑数据。分析师写好 SQL，丢数据平台跑，出了结果导 Excel 做透视表，最后粘到 PPT 里。七八个工具来回切，中间还得等人批数据库权限。两天里真正在分析的时间，可能不到两个小时。

这不是他一家的问题。

过去十年，Hadoop、Spark、Flink、ClickHouse、数据中台，基础设施建了一轮又一轮。但业务人员真正想用数据回答一个问题的时候——比如"上个月华东区退货率为什么高了"——还是卡在同样的地方。

你得先想清楚查哪些表、用什么口径、怎么排干扰因素、怎么交叉验证。每个环节都要专业知识。工具再多，这一步没人替你干。

LLM 出来后，很快有了 Text-to-SQL 产品：用自然语言问，它帮你写 SQL。方向对，但不够。

现实中的数据分析是一串连续的决策，不是一问一答：

你先宽泛扫一眼，发现异常；锁定嫌疑维度下钻；某个维度波动反常，换个角度交叉验证；排除几个假设，定位根因；最后用图表和文字把结论说清楚。

每一步都依赖上一步的结果。每一步都需要 Agent 自己判断下一步该干什么。Agentic 的价值就在这——不是翻译一句 SQL，是自己规划路径、自己动手、自己验证。

所以 DataAgent 要做的事情很明确：一个能自主规划分析路径、自己取数、自己验证、自己出结论的数据协作者。

二、Agentic 怎么跟数据打交道

先看张图，直观感受下整体思路。

这个架构就一件事：分层，每层干好自己的活，层之间用标准协议通信。从上到下是用户 → Agentic 引擎 → DataHarness 底座 → 基础设施。其中最厚的一层是 DataHarness，后面单独讲。

Agentic 引擎拆成四个模块：

这四个模块不是串行跑一次就结束了。是循环：规划 → 执行 → 验证 → 发现不对就调规划 → 继续执行 → 再验证，一直跑到能得出结论。

Agentic 跟传统自动化脚本的区别也在这。写脚本是"步骤 1→2→3→4"，写死了。Agent 是你给它一个目标、一套工具、一些约束，它自己找路。

举个例子。你问"上个月华东区退货率为什么高了"，Agent 不会直接写一条 SQL 了事。它会先拆：退货率上升要知道同比，华东区要按省份下钻看是不是普涨，原因分析要交叉退货原因码和品类和物流时效。然后一步步执行：查整体趋势 → 按省份下钻 → 发现浙江异常 → 按品类交叉 → 定位到"杭州仓数码配件包装破损导致退货运费争议"。每一步的 SQL 都是基于上一步结果现场写的。

还有一点很多人忽略：不是所有数据都在数据库里。CSV 文件、内部 API、上季度的分析报告——Agent 要能自己判断去哪拿数据、用什么工具拿。这就涉及 MCP，后面细说。

三、DataHarness：十块拼图搭起来的底座

Agent 再聪明，离开数据环境什么也干不了。这一层就是 DataHarness——它不是简单的数据库中间件，而是 Agent 操作数据的完整底座。

十个模块，各管一摊。

3.1 数据源：不管什么库，先统一纳管

一个公司的数据散在 MySQL、PG、Mongo、ES、各种 SaaS API 里。连接方式不一样，SQL 方言不一样，权限模型不一样。

数据源模块干一件事：把所有外部数据系统注册成统一格式的"数据源对象"。存连接信息（加密）、标方言（MySQL 8.0 / PG 15）、监控健康状态、打归属标签。

对上层的 Agent，它只看到一个列表，不关心底层是什么。

3.2 数据采集：把数据搬到位

光连上不够，数据得拉到能高效查询的地方。

三种采集模式：

• • 定时：按 cron 表达式跑，日报周报场景
• • 实时：CDC 监听 binlog，秒级同步，监控告警场景
• • 增量：大表只拉变化部分，不扫全量

结构化的进数据资产，原始文件进 OSS 数据湖。

3.3 OSS 数据湖：原始数据存这

日志、CSV、Excel、PDF，不适合塞数据库的，统一放这里。

基于对象存储。30 天内热存储、90 天后自动转冷。格式全收，自动识别建索引。文件多版本保留，按策略过期。Agent 分析时发现数据资产里没现成的，会自己来这边找原始文件补数据。

3.4 文件系统：用户跟文件打交道的地方

跟 OSS 数据湖的区别：数据湖偏后台，文件系统偏交互。传 CSV、导 Excel、截图、分析笔记，都在这管。

传一个 Excel 上去，自动认 Sheet、表头、数据类型。Agent 不只是按文件名搜，能理解"上个月华东区销售明细"对应哪个文件。文件更新了会自动提醒 Agent。

3.5 数据资产：让 Agent 看懂数据

这是 DataHarness 最吃设计的一块。解决一个很具体的问题：Agent 怎么把 f_ord_amt_v2 这种技术字段跟"销售额"对上？

三层信息：

第一层，物理 Schema。表名、字段名、类型、索引、分区，自动从数据源同步。

第二层，语义标签。给裸字段打业务标签。f_ord_amt_v2 标"订单金额""销售额""GMV"。Agent 做意图匹配时不看原始字段名，看标签。换数据库、字段名全变了，只要标签一致，Agent 照样跑。

第三层，数据血缘。记录字段之间的计算关系。"订单实付金额 = 商品总价 - 优惠 + 运费 - 积分抵扣"。Agent 不用猜这个公式，排异常时也能沿血缘快速追溯上游。

3.6 权限系统：闸门在这

给 Agent root 账号等于自杀。

四层控制：数据源级（能不能看整个库）、表级（能不能看某张表）、列级（能不能看 cost_price）、行级（只能看华东区数据）。

Agent 跑的所有查询，权限范围跟当前用户对齐。用户只有华东区权限，Agent 不能偷偷查全国数据"补全"分析。

还有一层自动脱敏：手机号打码、身份证脱敏、金额可选模糊化。规则按语义标签自动匹配，不逐字段配。

3.7 沙箱系统：Agent 写代码的安全边界

Agent 不只是写 SQL。它写 Python 做数据清洗，用 matplotlib 画图，跑统计模型。这些代码是现场生成的，没经过人工审查。

传统方案是禁 os、禁 subprocess、禁网络。但禁太多，正常功能也用不了——比如用 requests 调内部 API。

我们走容器级隔离。每个分析任务启一个独立容器，跑完就回收。安全边界在 OS 层面，不需要在 Python 层设限。CPU 和内存配死了上限，网络白名单放行。崩了只死一个容器。

为了不卡用户体验，每个租户预启动几个空闲容器（默认 3 个），任务来了直接分配。用完后清洗临时文件和环境变量，放回空闲池。跑超过 10 分钟的强制回收。

3.8 记忆系统：越用越懂你

Agent 每次对话都像第一次见面就太蠢了。

短期记忆：当前会话上下文，上次查了什么、结果是什么、用户反馈了什么。靠它做多轮决策——"刚才查到浙江退货异常了，下一步按品类下钻"。

长期记忆：跨会话保留。用户偏好（"我们算销售额不含税"）、常用图表（"领导爱看柱状图"）、历史发现（"去年双11华东也异常过"）。Agent 在新任务里自动参考这些。

知识库：企业级领域知识。业务术语词典（华东区 = 上海+浙江+江苏+安徽）、指标定义（活跃用户 = 7 天内至少登录 1 次）、历史分析报告归档。

三块记忆都按租户隔离。

3.9 SKILL：Agent 到底能干什么

前面几层管数据，SKILL 管能力。一个 SKILL 就是一段封装好的、Agent 可调用的能力模块。

用户说"分析这个季度销售数据，出份报告"，Agent 拆成：数据分析 SKILL → 图表生成 SKILL → 报告撰写 SKILL。

每个 SKILL 有标准定义：能力描述、输入输出规范、执行逻辑、依赖了哪些 MCP 工具和数据权限。

内置了四个通用的：数据分析、图表生成、异常检测、报告撰写。但真正有门槛的是自定义 SKILL。一家电商公司可以把"促销 ROI 分析"这个固定流程封装成 SKILL 注册进去。以后说"算一下 618 的 ROI"，Agent 直接匹配，按预设逻辑跑。

SKILL 干的事就是把可复用的分析经验，沉淀成可调用的数字资产。

3.10 MCP：Agent 跟外部世界说话的协议

SKILL 管"做什么"，MCP 管"怎么跟外部系统交互"。

MCP 是 Anthropic 提的开放协议，让 AI 模型和外部工具有标准化对话方式。在 DataAgent 里三层价值：

统一接口：MySQL、PG、S3、HTTP API，Agent 都走 MCP 连接器访问。连接器负责把标准协议翻译成具体系统的调法。

上下文标准化：MCP 不光是调一下，还定义怎么传上下文。数据库连接器能告诉 Agent 这个库有哪些表、每个表什么字段。

开放生态：谁实现 MCP Server，Agent 就能直接调用。BI 工具、内部系统，生态不封闭。

3.11 这十块拼图怎么一起转

用户提问 → Agentic 引擎规划 → 匹配 SKILL → SKILL 通过 MCP 调数据源
→ 权限系统校验 → 数据资产做语义翻译 → 沙箱执行代码 → 结果写回记忆
→ 必要时从 OSS 数据湖/文件系统补数据

每一块都不大，但缺一块，整个链条就断了。DataHarness 叫"驾驭"就这个意思：不是某一个功能，是让 Agent 能安全、高效、可理解地操作数据的整套环境。

四、多租户：一个企业多个部门怎么隔离

DataAgent 是给团队用的。一个公司市场部和供应链部，数据不能串、权限不能混。

隔离分三个维度。

数据隔离。每个租户独立 DataHarness 实例。连接串、Schema、标签、权限规则全独立。Agent 只看到当前租户的数据视图，跨不了租户。

计算隔离。每个租户独立 Sandbox 池。租户 A 的分析任务跑在 A 的容器里，代码写崩了只死自己的池子。

知识隔离。长期记忆——分析口径偏好、常用图表、历史发现——全按租户存。A 的知识不会混进 B 的 Agent。

平台共享层（Agentic 引擎、SKILL 注册中心）是公共的，但往下一到数据层就完全断开。同一个平台的多个部门独立用，互不干扰。这也是多租户设计最核心的价值——共享算力，但不共享数据。

五、本地映射：数据出不了电脑怎么办

前面说的都是数据在云上或者在公司服务器上。还有一种情况：数据就在你电脑上，而且绝不能出去。

金融交易记录、医疗数据、政务数据——合规要求锁死了。

解决思路不复杂：大脑在云端，手在本地。

流程拆开看：

1. 1. 你在本地客户端问"分析这个月销售趋势"
2. 2. 请求到云端 Agentic 引擎，Agent 开始规划
3. 3. Agent 不生成 SQL，生成数据指令——"从 sales_data.csv 提取 date 和 amount，按月聚合求和"
4. 4. 指令走加密通道下发到本地的映射引擎
5. 5. 本地引擎在本机执行：读 CSV → 聚合 → 只把"1月 120 万、2月 135 万、3月 110 万"这几个数字返给云端
6. 6. Agent 拿聚合结果继续分析

原始数据从来没出过你的电脑。云端看到的永远是聚合之后的数字。

本地映射引擎是个轻量服务，干三件事：

自动发现本机的 .db、.sqlite、.csv、.xlsx、.parquet，建索引，上传元数据摘要（不是数据本身）给云端。

执行云端下发的标准化 DSL，声明式表达，跟具体文件格式无关。同一条指令对 CSV 和 SQLite 都能跑。每次执行有完整审计日志。

返回前做一轮脱敏：某个维度记录太少就合并成"其他"，数值做模糊化防推断。

两种方案各有用处。纯云端：数据得上云，Agent 能力完整，适合 SaaS 和公开数据。本地映射：数据不出域，Agent 通过指令间接操作，代码在本地跑，适合金融、医疗、政务这些强合规场景。

选哪个取决于数据敏感度，不是二选一。用户自己决定哪些数据源走哪条路。

六、壁垒在哪，下一步往哪走

设计哲学

DataAgent 从头就没打算做"数据库上的自然语言壳"。要做的是能自主规划、自己动手、自我验证的数据协作者。

每一层都围着这个目标转：

三层壁垒

做"能写 SQL 的聊天机器人"门槛在快速降低。随便接个 LLM 加 function calling 就能跑 demo。

DataAgent 的壁垒在三件事上：

经验沉淀。每个企业注册的自定义 SKILL、积累的语义标签、沉淀的长期记忆——这些东西把组织的数据分析经验变成了不可迁移的数字资产。新人进来不用从头学口径流程，Agent 已经知道怎么算 ROI、退货率怎么拆。越用越厚，换不掉的。

深度适配。不是接个数据库就完事。要把一个公司的全部数据资产——生产库、数仓、OSS 文件、内部 API——统一纳管、打标签、配权限、接 MCP 生态，这件事本身就有切换成本。DataAgent 在客户环境里扎得越深，越难被替换。

安全信任。让 AI 自动写代码查数据，安全是绕不过去的坎。三层机制——四层权限、容器隔离、数据不出域——建了一个 AI 行为的可控边界。这个信任一旦建立，用户才敢把真正敏感的数据工作交出来。

三个方向

现在 DataAgent 解决的是"问答式分析"——你问它答。但 Agentic Data 的天花板不止于此。

主动洞察。Agent 不等人问，持续监测数据变化，有异常自己推。"你还没发现华东退货异常，Agent 已经发到群里了。"

行动闭环。不只是告诉你"退货率高了"，还能把后续动作做了——生成退货明细、给责任人发通知、在 BI 看板上标记。从发现到响应，缩短链路。

协作分析。多 Agent 协同。一个拆问题，一个取数，一个建模验证，一个汇总。把分析团队的工作模式映射到 Agent 系统上。

拉通来看，DataAgent 做的事说穿了不复杂：把数据工作从"人找数据"扭成"数据找人"，从"人写逻辑"扭成"Agent 理解意图"。

架构是骨架，但它能走多远，取决于这个架构能不能让用户自然地、放心地、高效地把数据工作交出来。

我们在做这件事。