1. 为什么生产级工业AI非 DolphinDB 不可MCP 又补上了哪块短板1.1 工业 AI 落地卡在数据层每次要数据都得现写 IO聊 DolphinDB MCP 之前先把场景摆清楚。工业 AI 现在不缺模型不缺算法最缺的是跟生产系统之间的最后一公里。设备异常检测、预测性维护、工艺参数优化、质量追溯哪一样都离不开高频时序数据。3 号机组今天上午的振动传感器测点数据过去十天的轴承温度趋势某条产线近一个月的 OEE 波动曲线——这些需求看着简单真到实现的时候REST 接口现写、查询逻辑硬编码、返回格式各自为政每次做 AI 应用都像是在给数据库做一次性的私有适配。DolphinDB 本身就是为时序场景设计的一体化平台列式存储、分区机制、内置流计算和丰富的聚合函数单节点处理亿级时间序列数据能做到秒级响应。工业客户选它做实时数据底座通常不是为了存而是为了算得快、查得爽。但数据库再快AI Agent 不会用一切都是白搭。传统做法是给大模型写一堆 Python 调用脚本把 SQL 拼在代码里模型只能按预设的几个函数去取数换个查询维度就得改代码。这个阶段AI 离生产系统还隔着开发人员的手工翻译。1.2 MCP 不是又一种API 封装它是 Agent 和数据的通用插座MCPModel Context Protocol模型上下文协议在 2024 年底开始火本质上解决的是 AI 应用和外部工具之间接口太多、协议太乱的问题。以前接一个数据源要写鉴权、写文档、写 SDK 调用、处理错误码每个 Agent 各写一套重复劳动非常严重。MCP 做的事是把工具调用标准化Agent 作为 Host通过 MCP Client 和 MCP Server 通信Server 暴露三样东西——Tools可执行的函数、Resources可读取的数据、Prompts可复用的提示词模板全程走 JSON-RPC。这里有个关键点MCP Server 暴露的 Tools 是可被模型动态发现的。也就是说大模型能在对话中看到有哪些工具、每个工具的入参出参是什么然后自己决定怎么组合调用。这跟传统的 API 文档不同API 文档是给人看的MCP 的工具描述是给模型看的。DolphinDB 接进 MCP 生态之后相当于给 AI 配了一个数据库工程师的双手模型能列出库里有哪些表、看懂字段结构、写好查询脚本、拿回结构化结果全程不需要人去写胶水代码。DolphinDB MCP Server 的整体链路可以粗略看成Agent客户端 → MCP Client → JSON-RPC 通信 → MCP ServerDolphinDB 适配层 → DolphinDB Python/Java API → DolphinDB 集群。我实测下来的感受是链路并不复杂但每一层都有各自的坑尤其是安全和性能边界后面会详细拆。2. 做一个安全可控的 DolphinDB MCP Server三个原则必须先想清楚2.1 对数据库说不的工具暴露面设计刚开始做 MCP Server 的时候最容易犯的错是把整个数据库都交给 AI。DolphinDB 内置函数几千个包含数据查询、表管理、流计算、权限管理、集群控制等。如果 MCP 工具直接传一个脚本字符串给数据库执行大模型完全有可能写出一条dropTable或者delete之类的危险语句——不是它故意的是模型对函数边界理解不到位。实测中就出现过 LLM 把select写错成delete的案例虽然被权限挡住了但想想都后背发凉。所以工具暴露面设计的第一原则是白名单机制。不是能执行所有脚本而是只能执行我们允许的几种操作。我最终在 Server 里只暴露了四类工具列出库表、查看表结构、执行只读查询、获取数据分布概况。每个工具在内部做关键字校验凡是包含drop、delete、insert、update、shutdown、addUser等语句的请求直接拒绝不给底层执行的机会。这里要特别提醒一点MCP Server 不能替代数据库权限系统。白名单是应用层的兜底真正的隔离还得靠数据库账号。给 MCP Server 单独创建一个只读账号权限只覆盖 AI 需要访问的库表这个账号连 DDL 权限都不应该有。两层防护叠在一起才是生产系统能接受的安全水位。2.2 数据隔离与鉴权不能让AI 助手变成无钥匙大门工业数据有个特点敏感度高一次越权访问可能带来合规风险。MCP Server 作为 AI 和数据库之间的桥梁如果鉴权做得稀烂等于把数据库大门钥匙挂在门口。我的做法是分三层设计第一层传输层安全。MCP Server 默认只监听内网地址或本机回环地址绝对不直接暴露公网。Agent 和 Server 之间如果跨网络走带 TLS 的传输通道不能用裸的 HTTP。第二层数据库账号隔离。前面提过用只读账号连接 DolphinDB账号本身在 DolphinDB 侧限制了可见的库表。这样即使 MCP 工具被绕过数据库层面仍然有兜底。第三层会话级上下文约束。在 Agent 的系统提示词里明确你只能访问运维分析库中的设备表和传感器表其他表一律拒绝同时在 Server 端做表名过滤不在白名单内的表直接报表不存在而不是报权限错误——避免模型根据错误信息去猜测库结构。这三层做下来MCP Server 更像一个戴着镣铐的查询助手AI 可以在这个边界内自由发挥但碰不到不该碰的东西。生产环境的稳定靠的不是模型自律而是机制约束。2.3 限流、超时与结果截断小 Demo 不会暴露的问题生产环境全暴露Demo 阶段只有一个用户在跑查询量小怎么调都行。一旦接到生产系统问题就全冒出来了模型可能会并发发起几十个查询请求DolphinDB 那边压力骤增一个统计脚本如果忘了加时间条件可能全表扫描查询结果几万行直接塞回给模型上下文窗口瞬间爆掉。限流这块我踩过坑。最初没有做并发控制有一次测试 Agent 自动排查设备异常模型一口气调了十几次query_dolphindb把测试库的连接数打满了。后来在 MCP Server 里加了一个线程池最大并发数设为 5超过的直接返回系统繁忙请稍后重试同时每个查询请求都设置超时时间我默认配 10 秒防止慢查询把线程池占死。结果截断更是必备功能。MCP 工具返回给模型的数据量要控制在合理范围我默认单次查询最多返回 100 行上限 5000 行超出部分在 SQL 层就用limit截断。如果用户确实需要全量统计引导模型走 DolphinDB 的聚合函数而不是拉原始数据。这样既保证了查询效率也保护了模型上下文。3. 核心实现查询类 MCP Server 的完整设计与实操3.1 技术栈与工程结构先交代一下我的实现环境Python 3.11mcp官方 Python SDKDolphinDB Python API。这里要说明MCP 官方 SDK 已经比较成熟了支持FastMCP这种声明式写法几行代码就能注册一个工具不需要自己处理 JSON-RPC 协议细节。工程结构可以按这个思路组织dolphindb-mcp-server/ ├── server.py # MCP Server 入口注册工具 ├── dolphindb_client.py # DolphinDB 连接封装查询执行 ├── security.py # 关键字过滤、表名白名单、限流 ├── config.py # 连接配置、超时、并发参数 ├── prompts.py # 系统提示词模板 └── requirements.txt核心连接封装用 DolphinDB 的 Python API连接参数放配置文件里。生产环境建议用环境变量注入不要把账号密码写死在代码里。连接方式支持单节点和集群我这边的测试环境是单节点但 API 的连接串写法是通用的。3.2 参数计算与工具注册让模型看得懂、调得对MCP 工具好不好用一半看工具逻辑一半看描述写得好不好。大模型没有常识它看到的工具描述就是我们给它的说明书。描述写得太简单它会用错参数写得太复杂占上下文还容易误导。以我注册的query_dolphindb工具为例from mcp.server.fastmcp import FastMCP mcp FastMCP(dolphindb-query-server) mcp.tool() def query_dolphindb( script: str , db_path: str , table_name: str , limit: int 100, timeout: int 10 ) - str: 在DolphinDB数据库中执行只读查询并返回结果。 参数说明 - script: 完整的DolphinDB查询脚本只允许SELECT/EXEC语句 - db_path: 需要查询的数据库路径格式如 dfs://industrial_iot - table_name: 需要查询的表名如 device_sensor - limit: 最多返回的行数默认100最大5000 - timeout: 查询超时时间秒默认10秒 使用前提 1. 先调用 list_tables 获取当前有权限访问的表 2. 先调用 describe_table 了解表结构 3. 查询默认附加最近24小时时间范围如查询更早数据请显式增加时间条件 # 参数校验和查询分发逻辑 result execute_query(script, db_path, table_name, limit, timeout) return result注意几个细节。描述里明确写了只允许 SELECT/EXEC 语句这是给模型的第一层约束。第二层使用前提是在引导模型的行为顺序——先看有哪些表再看表结构最后写查询这是模拟人的查询习惯。第三层关于时间范围的说明能大幅减少全表扫描的概率实测中加了这句话之后慢查询比例下降非常明显。list_tables和describe_table两个工具实现相对简单一个是列出当前账号可见的库表名一个是返回表的字段名、类型、分区信息。这两个工具是查询工具的前提模型拿到元信息之后才能写出正确的查询脚本。3.3 让 Agent 像数据库工程师一样思考提示词与工具约束工具注册好了模型还是那个模型怎么保证它不乱来答案在 Agent 的系统提示词里。我用的提示词模板核心几条你是工业物联网数据分析助手只能查询 DolphinDB 数据库中的设备数据。所有查询必须以只读方式执行禁止任何修改数据库的操作。查询前必须先调用list_tables和describe_table确认目标表和字段禁止猜测表名和字段名。默认查询范围为最近 24 小时用户明确指定历史区间时显式增加时间过滤条件。结果为空时先检查时间范围是否正确再检查表名不要自行编造数据。第一版提示词我写得太宽松只说了你是数据分析助手结果模型经常一上来就直接调query_dolphindb连表名都是猜的翻车概率相当高。后来把执行顺序写进提示词情况立刻好转。这说明大模型确实像一张白纸你给它什么样的工作流程它就按照什么样的方式执行。3.4 一个典型查询的完整工作流演示拿一个工业场景的典型需求来走一遍用户问3 号机组今天上午的振动传感器均值是多少。第一步Agent 调用list_tables拿到有权限访问的表列表锁定device_sensor表和device_info表。这个步骤保证了模型用的表名是真实存在的。第二步Agent 调用describe_table查看device_sensor表的字段结构发现关键字段是device_id、sensor_type、value、ts。此时模型明白了时间字段叫ts传感器类型字段叫sensor_type这样后续写查询就不会用错列名。第三步就好办了。模型构造的查询脚本大致是select avg(value) as avg_value from loadTable(dfs://industrial_iot, device_sensor) where device_id unit_003 and sensor_type vibration and ts 2025.06.01 08:00:00 and ts 2025.06.01 12:00:00DolphinDB 的语法跟标准 SQL 有些差异表加载需要用loadTable函数这个细节在工具描述里已经写明了。模型在构造脚本时会把列名、时间格式对齐到元数据。实测中只要前两步执行到位第三步的准确率非常高。整个流程的本质是用元数据工具把数据库的真实结构喂给模型让模型在真实信息的基础上做推理而不是凭空猜测。这也是为什么我一直强调工具的描述和调用顺序比模型本身的能力更影响效果。4. 我把这个 Server 接入 Cursor、Claude Desktop 和自研 Agent 的实测记录4.1 三种 Host 的快速接入方法MCP Server 写好了怎么接进不同的 Agent 客户端是另一个话题。我实测了三种主流接入方式。Claude Desktop 是最简单的修改配置文件claude_desktop_config.json把 MCP Server 加到mcpServers节点下。配置里写明命令、参数和环境变量{ mcpServers: { dolphindb: { command: python, args: [/path/to/dolphindb-mcp-server/server.py], env: { DDB_HOST: 127.0.0.1, DDB_PORT: 8848, DDB_USER: readonly_user } } } }Cursor 的配置方式类似但位置不同在项目根目录的.cursor/mcp.json里配置也可以直接在 Cursor 的设置界面添加。配置文件写法跟上面基本一致只是字段名和层级略有差异。自研 Agent 最灵活用 MCP 官方 SDK 的 Client 端连接 Server。比如用 Python 写from mcp import ClientSession, StdioServerParameters from mcp.client.stdio import stdio_client server_params StdioServerParameters( commandpython, args[/path/to/dolphindb-mcp-server/server.py], env{DDB_HOST: 127.0.0.1, DDB_PORT: 8848} ) async with stdio_client(server_params) as (read, write): async with ClientSession(read, write) as session: tools await session.list_tools() result await session.call_tool(query_dolphindb, {...})自研接入的好处是可以把 MCP Server 嵌到自己的业务系统里比如已有的工单系统、告警平台直接在内部调用查询能力。4.2 实测效果与可复现的查询示例我用一个真实需求做了完整验证统计某台设备最近 24 小时温度超过阈值的次数。对话过程 用户帮我查一下设备 A100 最近一天温度超过 75 度的次数。模型先调用list_tables确认表名然后调用describe_table看字段最后构造查询select count(*) as over_threshold_count from loadTable(dfs://industrial_iot, device_sensor) where device_id A100 and sensor_type temperature and value 75 and ts now() - 1d返回结果是一个 JSON 结构包含了查询耗时、影响行数和统计结果。整个链路耗时在 2 秒左右其中 DolphinDB 查询本身不到 100 毫秒主要耗时在模型多轮调用工具上。这个速度对于生产系统来说是可以接受的。这类查询直接可以对接生产大屏或者工单系统比如检测到温度超限次数超过某个阈值就自动生成报警工单。模型在这里做的是翻译和编排重活还是数据库在干。4.3 从能查数据到能干活编排才是生产系统的关键查数据只是第一步。工业 AI 进生产系统真正的价值在于闭环——发现问题、分析原因、触发动作。MCP Server 在这里的角色是数据底座它负责把数据库能力供给给 Agent但 Agent 要干活还得接其他工具。我在自研 Agent 里同时挂了三个 MCP ServerDolphinDB 数据查询、工单系统、企业微信机器人。完整的处理链路是DolphinDB 查到温度异常 → 模型调用工单系统 API 创建工单 → 调用企业微信机器人推送告警。整个过程用户只需要发一句话帮我检查一下今天哪些设备温度超标超标次数超过 10 次的自动建工单通知车间主任。这种编排能力是 MCP 生态带来的最大变化——不再是每个系统单独接一个 AI而是 AI 作为指挥中枢统一调度所有系统。工业领域这种需求非常常见以后各业务系统只要把自己的能力封装成 MCP ServerAI 应用就能低成本地插拔式组合。5. 生产环境最容易踩的五个坑与排查实录5.1 超时与上下文塞满Agent 越来越慢查不出原因现象MCP Server 这边日志显示查询很快返回了但 Agent 迟迟不输出结果或者对话越往后越慢。排查后发现问题是查询结果集太大。DolphinDB 执行引擎快几千行数据毫秒级返回但这些行全部塞回给模型上下文被撑爆模型处理时间指数级上升。解决在 MCP 工具层默认加limit 100并且把max_rows硬顶到 5000。同时提示模型如果行数超过 100考虑用聚合函数先汇总不要拉原始数据。这一套组合下来对话流畅度提升非常明显。5.2 DolphinDB 脚本报错被模型翻译得乱七八糟现象查询脚本写错了DolphinDB 返回错误信息模型看到错误后没有直接上报而是自己加工了一段解释结果把问题描述得完全变味。原因是错误信息返回给模型时是裸露文本模型理解之后会用自己的话转述容易出现偏差。解决MCP 工具内部捕获异常后把错误信息格式化成结构化 JSON包含错误码、原始错误信息、建议排查方向三个字段并且告诉模型当查询报错时原样返回错误信息不要自行解释。这样排查问题的效率高了很多。5.3 模型幻觉表名查询全失败现象模型经常引用一个不存在的表名比如会话一开始它还list_tables过但几轮对话之后就忘了开始编造表名。解决两条线并行。第一在系统提示词里反复强调只能使用list_tables返回的表名。第二在 MCP Server 端做表名白名单校验凡是白名单外的表名直接返回表不存在请先调用 list_tables 查看可用表从源头杜绝幻觉。5.4 密钥泄露与越权访问风险安全不是事后补的这个坑我没踩实但见到过其他团队踩。有的把 MCP Server 当成普通 API 服务部署在公网机器上数据库连接串暴露在环境变量里日志把 SQL 全量打出来这种一旦被扫描到就是妥妥的数据泄露事故。我的建议是MCP Server 只在内网部署监听127.0.0.1或内网 IP账号密码用密钥管理服务下发不要写在进程环境变量里日志做脱敏SQL 脚本中涉及具体数值的条件做打码处理。安全这个事事后补救的成本永远比事前设计高得多。5.5 表结构变更导致 Agent 突然失忆现象某天表结构被加了新字段Agent 明明调用过describe_table但后续查询还是用的旧字段名。原因模型上下文容量有限早期调用的元数据可能被后续对话冲掉了。解决在 MCP Server 端做一个 schema 缓存30 秒过期describe_table每次查询前自动刷新缓存。同时在query_dolphindb返回结果里带上字段校验信息如果字段不存在立刻报错并提示调用describe_table查看最新表结构。6. 从Demo到生产系统还需要什么6.1 可观测与审计给每条 AI 查询留下物理指纹工业系统上线审计是刚需。MCP Server 不能只是个黑盒每次查询都要留下完整记录。我在 Server 里加了一个查询日志模块每次调用都会记录时间戳、调用方、工具名、查询脚本、耗时、返回行数、是否报错。日志落的地方不是文件是 DolphinDB 自己的一张日志表——用数据库来记录数据库访问日志也算物尽其用。有了这些日志可以做几件事一是安全审计谁通过 AI 查了哪些数据一目了然二是性能分析哪些类型的查询拖慢了整体响应针对性地优化三是模型质量评估反复出错的查询拿出来复盘改进工具描述。6.2 从查询升级到闭环动作只读查询的 MCP Server 是一个很好的起点但工业 AI 的价值在于执行。我目前在扩展的方向是查询下发类工具AI 查完数据之后可以把结果封装成标准 JSON通过消息队列下发给 SCADA 系统或者执行机构。比如查到某设备振动异常直接下发一个降低运行速度的操作建议由人工审核后执行。这个方向有个前提就是安全管控要比只读场景严格得多。操作类工具必须有独立的权限申请、审批流程和操作审计AI 不能直接拿到执行权。我建议的方案是 AI 生成操作建议人工在系统里确认确认后才真正下发——当前阶段让 AI 做参谋人来做决策是生产效率和安全之间的最佳平衡。6.3 评估与灰度用数据说话而不是靠感觉MCP Server 做出来容易好不好用得拿数据说话。我的做法是从历史查询里抽了一批典型的取数需求做成一个评测集每次改动工具描述或者提示词就在评测集上跑一遍看准确率是升是降。评测集一开始只有 20 条现在攒到了 300 多条基本覆盖了常见的设备查询、统计分析、异常检索场景。然后是小流量灰度。先让 MCP Server 接入测试环境只读权限让几个核心用户试用收集反馈。稳定之后再逐步扩大到生产环境同样保持只读权限。整个过程我遵循一个原则先让 AI 看数据不让 AI 碰数据等 AI 把数据看明白了再考虑让它动数据。我在实际跑这个项目的时候印象最深的其实不是 MCP 协议本身多聪明而是当数据库以工具的形式被 AI 调用之后整个数据链路的效率会发生质变。以前工业 AI 项目交付要按周记要接数据、写接口、做开发。现在接一个数据源只需要一个 MCP Server标准的、可复制的换个数据库改个连接串就行。生产系统的数据资产终于能以一种相对安全、标准、可控的方式被 AI 真正用起来了。如果让我给准备入场的团队一个建议那就是不要一开始就追求大而全先做只读查询这一个功能把安全边界、工具描述、结果截断这些基本功打磨扎实再逐步扩展。MCP 生态才刚刚开始DolphinDB 接入 MCP 也只是工业数据能力开放的第一步后面还有告警下发、参数调优、智能调度这些更大的想象空间等着去填。 DolphinDB MCP Server实战：构建安全可控的工业时序数据查询层
1. 为什么生产级工业AI非 DolphinDB 不可MCP 又补上了哪块短板1.1 工业 AI 落地卡在数据层每次要数据都得现写 IO聊 DolphinDB MCP 之前先把场景摆清楚。工业 AI 现在不缺模型不缺算法最缺的是跟生产系统之间的最后一公里。设备异常检测、预测性维护、工艺参数优化、质量追溯哪一样都离不开高频时序数据。3 号机组今天上午的振动传感器测点数据过去十天的轴承温度趋势某条产线近一个月的 OEE 波动曲线——这些需求看着简单真到实现的时候REST 接口现写、查询逻辑硬编码、返回格式各自为政每次做 AI 应用都像是在给数据库做一次性的私有适配。DolphinDB 本身就是为时序场景设计的一体化平台列式存储、分区机制、内置流计算和丰富的聚合函数单节点处理亿级时间序列数据能做到秒级响应。工业客户选它做实时数据底座通常不是为了存而是为了算得快、查得爽。但数据库再快AI Agent 不会用一切都是白搭。传统做法是给大模型写一堆 Python 调用脚本把 SQL 拼在代码里模型只能按预设的几个函数去取数换个查询维度就得改代码。这个阶段AI 离生产系统还隔着开发人员的手工翻译。1.2 MCP 不是又一种API 封装它是 Agent 和数据的通用插座MCPModel Context Protocol模型上下文协议在 2024 年底开始火本质上解决的是 AI 应用和外部工具之间接口太多、协议太乱的问题。以前接一个数据源要写鉴权、写文档、写 SDK 调用、处理错误码每个 Agent 各写一套重复劳动非常严重。MCP 做的事是把工具调用标准化Agent 作为 Host通过 MCP Client 和 MCP Server 通信Server 暴露三样东西——Tools可执行的函数、Resources可读取的数据、Prompts可复用的提示词模板全程走 JSON-RPC。这里有个关键点MCP Server 暴露的 Tools 是可被模型动态发现的。也就是说大模型能在对话中看到有哪些工具、每个工具的入参出参是什么然后自己决定怎么组合调用。这跟传统的 API 文档不同API 文档是给人看的MCP 的工具描述是给模型看的。DolphinDB 接进 MCP 生态之后相当于给 AI 配了一个数据库工程师的双手模型能列出库里有哪些表、看懂字段结构、写好查询脚本、拿回结构化结果全程不需要人去写胶水代码。DolphinDB MCP Server 的整体链路可以粗略看成Agent客户端 → MCP Client → JSON-RPC 通信 → MCP ServerDolphinDB 适配层 → DolphinDB Python/Java API → DolphinDB 集群。我实测下来的感受是链路并不复杂但每一层都有各自的坑尤其是安全和性能边界后面会详细拆。2. 做一个安全可控的 DolphinDB MCP Server三个原则必须先想清楚2.1 对数据库说不的工具暴露面设计刚开始做 MCP Server 的时候最容易犯的错是把整个数据库都交给 AI。DolphinDB 内置函数几千个包含数据查询、表管理、流计算、权限管理、集群控制等。如果 MCP 工具直接传一个脚本字符串给数据库执行大模型完全有可能写出一条dropTable或者delete之类的危险语句——不是它故意的是模型对函数边界理解不到位。实测中就出现过 LLM 把select写错成delete的案例虽然被权限挡住了但想想都后背发凉。所以工具暴露面设计的第一原则是白名单机制。不是能执行所有脚本而是只能执行我们允许的几种操作。我最终在 Server 里只暴露了四类工具列出库表、查看表结构、执行只读查询、获取数据分布概况。每个工具在内部做关键字校验凡是包含drop、delete、insert、update、shutdown、addUser等语句的请求直接拒绝不给底层执行的机会。这里要特别提醒一点MCP Server 不能替代数据库权限系统。白名单是应用层的兜底真正的隔离还得靠数据库账号。给 MCP Server 单独创建一个只读账号权限只覆盖 AI 需要访问的库表这个账号连 DDL 权限都不应该有。两层防护叠在一起才是生产系统能接受的安全水位。2.2 数据隔离与鉴权不能让AI 助手变成无钥匙大门工业数据有个特点敏感度高一次越权访问可能带来合规风险。MCP Server 作为 AI 和数据库之间的桥梁如果鉴权做得稀烂等于把数据库大门钥匙挂在门口。我的做法是分三层设计第一层传输层安全。MCP Server 默认只监听内网地址或本机回环地址绝对不直接暴露公网。Agent 和 Server 之间如果跨网络走带 TLS 的传输通道不能用裸的 HTTP。第二层数据库账号隔离。前面提过用只读账号连接 DolphinDB账号本身在 DolphinDB 侧限制了可见的库表。这样即使 MCP 工具被绕过数据库层面仍然有兜底。第三层会话级上下文约束。在 Agent 的系统提示词里明确你只能访问运维分析库中的设备表和传感器表其他表一律拒绝同时在 Server 端做表名过滤不在白名单内的表直接报表不存在而不是报权限错误——避免模型根据错误信息去猜测库结构。这三层做下来MCP Server 更像一个戴着镣铐的查询助手AI 可以在这个边界内自由发挥但碰不到不该碰的东西。生产环境的稳定靠的不是模型自律而是机制约束。2.3 限流、超时与结果截断小 Demo 不会暴露的问题生产环境全暴露Demo 阶段只有一个用户在跑查询量小怎么调都行。一旦接到生产系统问题就全冒出来了模型可能会并发发起几十个查询请求DolphinDB 那边压力骤增一个统计脚本如果忘了加时间条件可能全表扫描查询结果几万行直接塞回给模型上下文窗口瞬间爆掉。限流这块我踩过坑。最初没有做并发控制有一次测试 Agent 自动排查设备异常模型一口气调了十几次query_dolphindb把测试库的连接数打满了。后来在 MCP Server 里加了一个线程池最大并发数设为 5超过的直接返回系统繁忙请稍后重试同时每个查询请求都设置超时时间我默认配 10 秒防止慢查询把线程池占死。结果截断更是必备功能。MCP 工具返回给模型的数据量要控制在合理范围我默认单次查询最多返回 100 行上限 5000 行超出部分在 SQL 层就用limit截断。如果用户确实需要全量统计引导模型走 DolphinDB 的聚合函数而不是拉原始数据。这样既保证了查询效率也保护了模型上下文。3. 核心实现查询类 MCP Server 的完整设计与实操3.1 技术栈与工程结构先交代一下我的实现环境Python 3.11mcp官方 Python SDKDolphinDB Python API。这里要说明MCP 官方 SDK 已经比较成熟了支持FastMCP这种声明式写法几行代码就能注册一个工具不需要自己处理 JSON-RPC 协议细节。工程结构可以按这个思路组织dolphindb-mcp-server/ ├── server.py # MCP Server 入口注册工具 ├── dolphindb_client.py # DolphinDB 连接封装查询执行 ├── security.py # 关键字过滤、表名白名单、限流 ├── config.py # 连接配置、超时、并发参数 ├── prompts.py # 系统提示词模板 └── requirements.txt核心连接封装用 DolphinDB 的 Python API连接参数放配置文件里。生产环境建议用环境变量注入不要把账号密码写死在代码里。连接方式支持单节点和集群我这边的测试环境是单节点但 API 的连接串写法是通用的。3.2 参数计算与工具注册让模型看得懂、调得对MCP 工具好不好用一半看工具逻辑一半看描述写得好不好。大模型没有常识它看到的工具描述就是我们给它的说明书。描述写得太简单它会用错参数写得太复杂占上下文还容易误导。以我注册的query_dolphindb工具为例from mcp.server.fastmcp import FastMCP mcp FastMCP(dolphindb-query-server) mcp.tool() def query_dolphindb( script: str , db_path: str , table_name: str , limit: int 100, timeout: int 10 ) - str: 在DolphinDB数据库中执行只读查询并返回结果。 参数说明 - script: 完整的DolphinDB查询脚本只允许SELECT/EXEC语句 - db_path: 需要查询的数据库路径格式如 dfs://industrial_iot - table_name: 需要查询的表名如 device_sensor - limit: 最多返回的行数默认100最大5000 - timeout: 查询超时时间秒默认10秒 使用前提 1. 先调用 list_tables 获取当前有权限访问的表 2. 先调用 describe_table 了解表结构 3. 查询默认附加最近24小时时间范围如查询更早数据请显式增加时间条件 # 参数校验和查询分发逻辑 result execute_query(script, db_path, table_name, limit, timeout) return result注意几个细节。描述里明确写了只允许 SELECT/EXEC 语句这是给模型的第一层约束。第二层使用前提是在引导模型的行为顺序——先看有哪些表再看表结构最后写查询这是模拟人的查询习惯。第三层关于时间范围的说明能大幅减少全表扫描的概率实测中加了这句话之后慢查询比例下降非常明显。list_tables和describe_table两个工具实现相对简单一个是列出当前账号可见的库表名一个是返回表的字段名、类型、分区信息。这两个工具是查询工具的前提模型拿到元信息之后才能写出正确的查询脚本。3.3 让 Agent 像数据库工程师一样思考提示词与工具约束工具注册好了模型还是那个模型怎么保证它不乱来答案在 Agent 的系统提示词里。我用的提示词模板核心几条你是工业物联网数据分析助手只能查询 DolphinDB 数据库中的设备数据。所有查询必须以只读方式执行禁止任何修改数据库的操作。查询前必须先调用list_tables和describe_table确认目标表和字段禁止猜测表名和字段名。默认查询范围为最近 24 小时用户明确指定历史区间时显式增加时间过滤条件。结果为空时先检查时间范围是否正确再检查表名不要自行编造数据。第一版提示词我写得太宽松只说了你是数据分析助手结果模型经常一上来就直接调query_dolphindb连表名都是猜的翻车概率相当高。后来把执行顺序写进提示词情况立刻好转。这说明大模型确实像一张白纸你给它什么样的工作流程它就按照什么样的方式执行。3.4 一个典型查询的完整工作流演示拿一个工业场景的典型需求来走一遍用户问3 号机组今天上午的振动传感器均值是多少。第一步Agent 调用list_tables拿到有权限访问的表列表锁定device_sensor表和device_info表。这个步骤保证了模型用的表名是真实存在的。第二步Agent 调用describe_table查看device_sensor表的字段结构发现关键字段是device_id、sensor_type、value、ts。此时模型明白了时间字段叫ts传感器类型字段叫sensor_type这样后续写查询就不会用错列名。第三步就好办了。模型构造的查询脚本大致是select avg(value) as avg_value from loadTable(dfs://industrial_iot, device_sensor) where device_id unit_003 and sensor_type vibration and ts 2025.06.01 08:00:00 and ts 2025.06.01 12:00:00DolphinDB 的语法跟标准 SQL 有些差异表加载需要用loadTable函数这个细节在工具描述里已经写明了。模型在构造脚本时会把列名、时间格式对齐到元数据。实测中只要前两步执行到位第三步的准确率非常高。整个流程的本质是用元数据工具把数据库的真实结构喂给模型让模型在真实信息的基础上做推理而不是凭空猜测。这也是为什么我一直强调工具的描述和调用顺序比模型本身的能力更影响效果。4. 我把这个 Server 接入 Cursor、Claude Desktop 和自研 Agent 的实测记录4.1 三种 Host 的快速接入方法MCP Server 写好了怎么接进不同的 Agent 客户端是另一个话题。我实测了三种主流接入方式。Claude Desktop 是最简单的修改配置文件claude_desktop_config.json把 MCP Server 加到mcpServers节点下。配置里写明命令、参数和环境变量{ mcpServers: { dolphindb: { command: python, args: [/path/to/dolphindb-mcp-server/server.py], env: { DDB_HOST: 127.0.0.1, DDB_PORT: 8848, DDB_USER: readonly_user } } } }Cursor 的配置方式类似但位置不同在项目根目录的.cursor/mcp.json里配置也可以直接在 Cursor 的设置界面添加。配置文件写法跟上面基本一致只是字段名和层级略有差异。自研 Agent 最灵活用 MCP 官方 SDK 的 Client 端连接 Server。比如用 Python 写from mcp import ClientSession, StdioServerParameters from mcp.client.stdio import stdio_client server_params StdioServerParameters( commandpython, args[/path/to/dolphindb-mcp-server/server.py], env{DDB_HOST: 127.0.0.1, DDB_PORT: 8848} ) async with stdio_client(server_params) as (read, write): async with ClientSession(read, write) as session: tools await session.list_tools() result await session.call_tool(query_dolphindb, {...})自研接入的好处是可以把 MCP Server 嵌到自己的业务系统里比如已有的工单系统、告警平台直接在内部调用查询能力。4.2 实测效果与可复现的查询示例我用一个真实需求做了完整验证统计某台设备最近 24 小时温度超过阈值的次数。对话过程 用户帮我查一下设备 A100 最近一天温度超过 75 度的次数。模型先调用list_tables确认表名然后调用describe_table看字段最后构造查询select count(*) as over_threshold_count from loadTable(dfs://industrial_iot, device_sensor) where device_id A100 and sensor_type temperature and value 75 and ts now() - 1d返回结果是一个 JSON 结构包含了查询耗时、影响行数和统计结果。整个链路耗时在 2 秒左右其中 DolphinDB 查询本身不到 100 毫秒主要耗时在模型多轮调用工具上。这个速度对于生产系统来说是可以接受的。这类查询直接可以对接生产大屏或者工单系统比如检测到温度超限次数超过某个阈值就自动生成报警工单。模型在这里做的是翻译和编排重活还是数据库在干。4.3 从能查数据到能干活编排才是生产系统的关键查数据只是第一步。工业 AI 进生产系统真正的价值在于闭环——发现问题、分析原因、触发动作。MCP Server 在这里的角色是数据底座它负责把数据库能力供给给 Agent但 Agent 要干活还得接其他工具。我在自研 Agent 里同时挂了三个 MCP ServerDolphinDB 数据查询、工单系统、企业微信机器人。完整的处理链路是DolphinDB 查到温度异常 → 模型调用工单系统 API 创建工单 → 调用企业微信机器人推送告警。整个过程用户只需要发一句话帮我检查一下今天哪些设备温度超标超标次数超过 10 次的自动建工单通知车间主任。这种编排能力是 MCP 生态带来的最大变化——不再是每个系统单独接一个 AI而是 AI 作为指挥中枢统一调度所有系统。工业领域这种需求非常常见以后各业务系统只要把自己的能力封装成 MCP ServerAI 应用就能低成本地插拔式组合。5. 生产环境最容易踩的五个坑与排查实录5.1 超时与上下文塞满Agent 越来越慢查不出原因现象MCP Server 这边日志显示查询很快返回了但 Agent 迟迟不输出结果或者对话越往后越慢。排查后发现问题是查询结果集太大。DolphinDB 执行引擎快几千行数据毫秒级返回但这些行全部塞回给模型上下文被撑爆模型处理时间指数级上升。解决在 MCP 工具层默认加limit 100并且把max_rows硬顶到 5000。同时提示模型如果行数超过 100考虑用聚合函数先汇总不要拉原始数据。这一套组合下来对话流畅度提升非常明显。5.2 DolphinDB 脚本报错被模型翻译得乱七八糟现象查询脚本写错了DolphinDB 返回错误信息模型看到错误后没有直接上报而是自己加工了一段解释结果把问题描述得完全变味。原因是错误信息返回给模型时是裸露文本模型理解之后会用自己的话转述容易出现偏差。解决MCP 工具内部捕获异常后把错误信息格式化成结构化 JSON包含错误码、原始错误信息、建议排查方向三个字段并且告诉模型当查询报错时原样返回错误信息不要自行解释。这样排查问题的效率高了很多。5.3 模型幻觉表名查询全失败现象模型经常引用一个不存在的表名比如会话一开始它还list_tables过但几轮对话之后就忘了开始编造表名。解决两条线并行。第一在系统提示词里反复强调只能使用list_tables返回的表名。第二在 MCP Server 端做表名白名单校验凡是白名单外的表名直接返回表不存在请先调用 list_tables 查看可用表从源头杜绝幻觉。5.4 密钥泄露与越权访问风险安全不是事后补的这个坑我没踩实但见到过其他团队踩。有的把 MCP Server 当成普通 API 服务部署在公网机器上数据库连接串暴露在环境变量里日志把 SQL 全量打出来这种一旦被扫描到就是妥妥的数据泄露事故。我的建议是MCP Server 只在内网部署监听127.0.0.1或内网 IP账号密码用密钥管理服务下发不要写在进程环境变量里日志做脱敏SQL 脚本中涉及具体数值的条件做打码处理。安全这个事事后补救的成本永远比事前设计高得多。5.5 表结构变更导致 Agent 突然失忆现象某天表结构被加了新字段Agent 明明调用过describe_table但后续查询还是用的旧字段名。原因模型上下文容量有限早期调用的元数据可能被后续对话冲掉了。解决在 MCP Server 端做一个 schema 缓存30 秒过期describe_table每次查询前自动刷新缓存。同时在query_dolphindb返回结果里带上字段校验信息如果字段不存在立刻报错并提示调用describe_table查看最新表结构。6. 从Demo到生产系统还需要什么6.1 可观测与审计给每条 AI 查询留下物理指纹工业系统上线审计是刚需。MCP Server 不能只是个黑盒每次查询都要留下完整记录。我在 Server 里加了一个查询日志模块每次调用都会记录时间戳、调用方、工具名、查询脚本、耗时、返回行数、是否报错。日志落的地方不是文件是 DolphinDB 自己的一张日志表——用数据库来记录数据库访问日志也算物尽其用。有了这些日志可以做几件事一是安全审计谁通过 AI 查了哪些数据一目了然二是性能分析哪些类型的查询拖慢了整体响应针对性地优化三是模型质量评估反复出错的查询拿出来复盘改进工具描述。6.2 从查询升级到闭环动作只读查询的 MCP Server 是一个很好的起点但工业 AI 的价值在于执行。我目前在扩展的方向是查询下发类工具AI 查完数据之后可以把结果封装成标准 JSON通过消息队列下发给 SCADA 系统或者执行机构。比如查到某设备振动异常直接下发一个降低运行速度的操作建议由人工审核后执行。这个方向有个前提就是安全管控要比只读场景严格得多。操作类工具必须有独立的权限申请、审批流程和操作审计AI 不能直接拿到执行权。我建议的方案是 AI 生成操作建议人工在系统里确认确认后才真正下发——当前阶段让 AI 做参谋人来做决策是生产效率和安全之间的最佳平衡。6.3 评估与灰度用数据说话而不是靠感觉MCP Server 做出来容易好不好用得拿数据说话。我的做法是从历史查询里抽了一批典型的取数需求做成一个评测集每次改动工具描述或者提示词就在评测集上跑一遍看准确率是升是降。评测集一开始只有 20 条现在攒到了 300 多条基本覆盖了常见的设备查询、统计分析、异常检索场景。然后是小流量灰度。先让 MCP Server 接入测试环境只读权限让几个核心用户试用收集反馈。稳定之后再逐步扩大到生产环境同样保持只读权限。整个过程我遵循一个原则先让 AI 看数据不让 AI 碰数据等 AI 把数据看明白了再考虑让它动数据。我在实际跑这个项目的时候印象最深的其实不是 MCP 协议本身多聪明而是当数据库以工具的形式被 AI 调用之后整个数据链路的效率会发生质变。以前工业 AI 项目交付要按周记要接数据、写接口、做开发。现在接一个数据源只需要一个 MCP Server标准的、可复制的换个数据库改个连接串就行。生产系统的数据资产终于能以一种相对安全、标准、可控的方式被 AI 真正用起来了。如果让我给准备入场的团队一个建议那就是不要一开始就追求大而全先做只读查询这一个功能把安全边界、工具描述、结果截断这些基本功打磨扎实再逐步扩展。MCP 生态才刚刚开始DolphinDB 接入 MCP 也只是工业数据能力开放的第一步后面还有告警下发、参数调优、智能调度这些更大的想象空间等着去填。