做行情中心这件事最磨人的从来不是策略本身而是数据。我接手过好几套行情系统也陪跑了不同团队从零搭投研平台几乎每个项目的前一个月都耗在“把数据弄进来”上不同交易所的行情格式不一样同一家交易所不同产品的快照频率也不一样历史数据还经常缺字段、带脏值再加上实时订阅和离线回放要两手抓稍不留神数据链路就乱了。最近我用 DolphinDB 加上 DolphinX 重新搭了一套行情接入流程配合 AI Agent 做了不少自动化处理整体效率和之前手动写接入脚本相比提升非常明显。这篇内容主要写给正在搭行情中心、或者觉得数据接入流程太繁琐的人。无论你是量化团队的技术负责人还是既要管策略又要管数据的全能型选手只要手头数据源种类多、格式杂、频率高这套“AI Agent 零代码接入”的思路和实操步骤都值得参考。1. 行情接入的坑先盘清楚再说方案1.1 多源异构数据的三大痛点行情数据接入的第一个坑是“多源”。沪深 L1/L2、期货、期权、外盘、加密资产每种数据源都有自己的协议和字段命名。第二个坑是“异构”同样是分钟线A 家给的字段叫 open_priceB 家叫 openC 家可能直接给你一个嵌套结构体。第三个坑是“时序敏感”行情数据和普通业务数据不一样时间就是生命线晚一秒钟入库回测和实盘的结果就可能完全不同。这三个坑叠加在一起导致传统的接入方式非常痛苦。以前我接一套新数据源通常要经历“读文档、写解析、建表、写入库逻辑、搞增量更新、处理异常重试”这样一个完整闭环少则一两天多则一周。而且这套链路往往只有写代码的人能维护团队里其他人想加一个字段都费劲。等数据源一多每个人的脚本风格还不一样维护成本直接起飞。1.2 为什么最终选 DolphinDB 搭配 DolphinX选 DolphinDB 做存储和计算底座理由是现成的时序数据写入和查询性能强内置的分布式表、分区机制、流计算引擎都成熟行情快照、日线、分钟线、逐笔成交这些高频数据都能高效处理。它自带的脚本语言也足够灵活能直接写复杂的因子计算、数据回放逻辑不需要把数据导到外部再算。但真正解决“接入”环节效率问题的是 DolphinX 这一层。DolphinX 是 DolphinDB 生态里负责数据接入和 AI 辅助的组件它把“数据源连接、字段映射、清洗规则、写入目标表、调度计划”这些操作封装成了可视化、可配置的流程。配合 AI Agent 后很多原本需要手工完成的配置都能自动生成和调整。我用下来最直接的感受是一个新数据源从“拿到手”到“数据入库”大量重复劳动被省掉了。1.3 AI Agent 到底在接入流程里扮演什么角色这里先讲清楚一个容易混淆的点AI Agent、LLM、AI 模型这三者不是一回事。AI 模型是一个“大脑”比如 DeepSeek 就属于这类它擅长理解语言和生成内容但它本身不会自主执行任务。LLM大语言模型是 AI 模型的一个分支专门处理文本理解和生成。而 AI Agent 是在模型之上再包了一层“行动力”它能理解你的意图、拆解任务、调用工具、查看执行结果、出错后自己调整策略形成一个完整的“感知-决策-执行”闭环。放到 DolphinX 的接入场景里AI Agent 做的事就是你用自然语言描述“把某券商提供的期货分钟线接入进来按合约和日期分区”它能解析出需要的参数自动帮你在 DolphinX 里创建数据源连接器、推断字段类型、生成清洗规则连定时调度计划都能顺手配置好。这就是零代码的核心体验——不是没有代码而是代码由 AI 替你写了。2. DolphinX 零代码接入原理与核心概念2.1 DolphinX 是什么与 DolphinDB 服务端的关系我在实际使用中习惯把 DolphinDB 理解为“数据库 计算引擎”把 DolphinX 理解为“贴在数据库外面的智能接入层”。DolphinX 本身不是一个独立的数据库它运行在 DolphinDB 集群之上负责把外部数据源的数据准备好再写入到 DolphinDB 的分布式表里。它同时提供 Web 界面和 API 两种操作入口方便不同习惯的团队成员使用。从部署角度看DolphinX 跟 DolphinDB 服务端可以装在同一台机器也可以单独部署。我个人建议在测试环境先装一起跑通流程等数据量和任务量上去了再分开部署。DolphinX 的任务调度、数据源连接管理、监控告警这些能力本质上都是围绕“让数据稳定高效地进入 DolphinDB”这一件事服务的。2.2 数据接入的抽象模型连接器、映射、任务DolphinX 把一条完整的数据接入链路抽象成了四个核心环节连接器负责“把数据读出来”映射负责“把字段对上”任务负责“把流程跑起来”调度负责“让流程按计划重复执行”。连接器定义数据源的基本信息比如文件路径、HTTP 接口地址、数据库 JDBC 连接串、认证信息等。每种数据源类型对应一种连接器。映射把源数据的字段和 DolphinDB 目标表字段做对应同时可以追加类型转换、空值处理、去重、重命名等规则。任务一个任务是一个可执行单元指定了用哪个连接器、读哪个文件或哪个接口、按什么映射规则处理、写入哪张目标表。调度给任务绑定触发方式比如定时执行、手动触发、依赖上游完成事件触发等。这个模型最大的好处是“配置可复用”。同一个连接器可以被多个任务使用同一套映射规则也能套用到结构相似的数据源上。我在实际项目中经常是配好一个期货分钟线任务后直接把映射规则复制一份改一下表名和文件名就完成了另一个品种的接入。2.3 为什么“零代码”不等于“没有代码”很多人听到“零代码”就以为完全不用写代码这个理解在 DolphinX 里并不完全准确。更贴切的说法是“零手工代码”或“低代码”日常的数据接入、字段映射、任务配置通过可视化界面和配置项就能完成不需要手写解析逻辑。但遇到特殊处理逻辑时DolphinX 也允许在转换环节插入表达式或脚本片段。这种设计非常务实。行情数据的类型和格式千奇百怪比如有的数据源时间戳是毫秒、有的微妙有的涨跌停价用字符串表示全做成选项反而僵化。保留一个可写脚本的口子既照顾了标准化场景的效率又保留了对特殊场景的兜底能力。3. 实战30分钟跑通第一套行情接入任务3.1 准备环境与确认关键参数动手之前先把环境准备好。以我在测试环境用的单节点 DolphinDB 为例安装完成后确认三件事DolphinDB 服务端正常启动、DolphinX 组件的 Web 界面能访问、能通过 Python API 或 Web 界面连上数据库。然后确定这次要接的数据源。我习惯用一个行情 CSV 文件来测试全流程比如一份包含日期、时间、合约代码、开高低收、成交量、持仓量、结算价的期货分钟线文件。文件不大字段清晰用来验证接入流程最合适。小贴士先用 100 行左右的样例数据跑通流程再切到全量文件能省很多排查时间。3.2 创建数据源连接器与字段映射在 DolphinX 界面里第一步是新建连接器。选择 CSV 文件类型填写文件路径、编码格式、分隔符、是否含表头等信息。这个步骤的核心是让系统知道“去哪里读数据”。我测试时遇到过一个坑CSV 文件里混了中文表头或 BOM 头导致第一列字段名解析错误后来在连接器配置里把编码改成 UTF-8-BOM 就解决了。第二步是建目标表并配置字段映射。在 DolphinDB 里建一张分布式表指定分区列、排序键和分区类型。对分钟线数据我推荐按日期分区 按合约代码排序这样查询某一合约某一天的数据时 IO 开销最可控。字段映射界面会列出源文件的所有字段并让你一一对应到目标表的字段还能在中间插入转换规则。比如源文件的时间戳是字符串 “2024-01-01 09:45:00”目标表字段是 TIMESTAMP 类型映射时可以选“自动解析”如果是数字格式的毫秒时间戳就写一条转换表达式。这样建好后任务每次执行都会自动套用这些规则不需要再人工处理。3.3 创建任务并首次执行连接器和映射都配好后创建任务就很简单了选择连接器、选择目标表、选择映射规则、设置写入模式追加/覆盖、配置并发数保存即可。首次执行时我建议先点“手动执行”观察执行日志。日志里重点看几个信息读取了多少行、成功写入多少行、失败多少行、失败原因是什么。一旦出现失败现场日志会显示具体行号和字段信息排查起来很方便。我第一次测试时遇到的问题是源文件里有一行空数据目标表的时间列不允许为空导致整批回滚。后来我在映射规则里加了“空值丢弃”的过滤条件问题就解决了。数据成功入库后再去 DolphinDB 的客户端里查一下数据量和最新时间确认数据真的进去了。这一步别省有时候任务显示成功但实际写入 0 行多半是源文件路径配错了或者表名写错了。3.4 配置调度让增量更新自动流转存量数据接完后剩下就是增量更新。DolphinX 的任务调度支持按分钟、小时、日、周定时执行也支持监听文件变动比如目录下新增文件时自动触发。我用得最多的是两种按固定时间间隔轮询比如每 5 分钟执行一次拉取最近 5 分钟的增量数据监听目录新增文件适用于上游每天按日期输出文件的场景。调度配好之后数据接入就进入了“无人值守”状态。这时候 AI Agent 的价值才真正体现出来不光是自动化执行还包括出问题时的自动诊断和策略调整。4. 把 AI Agent 放进接入链路关键场景与配置4.1 哪些环节适合交给 AI Agent哪些不适合我在 DolphinX 里尝试把 AI Agent 用在四个环节效果差别挺大场景理解与任务生成效果最好。用自然语言描述接入需求Agent 能自动创建连接器、建表并配置映射生成的配置 90% 以上可以直接用。字段映射与类型推断效果不错。Agent 可以根据目标表已有字段和源文件字段名做智能匹配还能提示可疑字段。异常诊断与修复建议效果很好。任务失败时让 Agent 查看日志它能定位到具体字段或行并给出修改建议。完全自主决策不建议。比如让 Agent 自动修改生产环境的表结构权限太大风险不可控。我的原则是AI Agent 用来“加速决策”而不是“替代决策”。接入流程中的重复性劳动可以交给它但涉及生产环境的变更最终确认权还是得留在人手里。4.2 一个可落地的 Agent 配置思路假设场景是DolphinX 里已经有一套手动接入的 CSV 任务现在想新增一个同结构的日线文件接入任务。传统做法是复制原任务再改参数更“智能”的做法是让 Agent 分析现有任务的配置结构直接生成新任务在 DolphinX 的 AI 助手对话框里输入“参考 task_001_fut_minute 的配置新建一个接入日线数据的任务源文件路径是 /data/daily/目标表是 daily_bar调度时间改为每天下午 6 点”。Agent 会先读取 task_001 的完整配置提取连接器类型、映射规则、清洗逻辑。Agent 对比目录里的字段结构调整字段类型和分区配置。生成一个新任务输出配置摘要等待你确认。你确认后Agent 调用 DolphinX 的 API 创建任务并测试执行。这个流程里涉及的知识点包括Agent 要能读取已有任务的元数据、能调用 DolphinX 的配置生成接口、能区分不同品种的字段差异。从实现上看核心是 DolphinX 暴露给 Agent 的操作接口够不够清晰。4.3 聊聊 AI Agent 与 LLM、AI 模型的边界前面提过 DeepSeek 属于 AI 模型或 LLM它本身没有“动手”能力。而 AI Agent 是把这类模型作为“大脑”再配上“手和脚”——工具调用、API 接口、环境感知能力——从而完成真正的操作执行。用一句话总结LLM 是你能“对话”的对象AI Agent 是你能“交代干活”的对象。前者回答你“这个文件格式是什么”后者会自己去读文件、分析字段、生成配置、帮你跑通接入任务。DolphinX 里集成的 AI 能力本质上是把两者结合用 LLM 做理解通过 Agent 的编排能力去操作 DolphinDB 的各类接口和数据。4.4 企业级落地时的权限、审计与回滚说实话AI Agent 在行情接入里跑得最顺的场景都是“低风险操作”一旦涉及生产环境就必须把权限和审计做好。我这边落地时定了三条规矩Agent 只能操作测试环境或指定的预发环境生产环境的变更必须走人工审批所有 Agent 生成的任务和配置变更都留痕方便回溯配置变更前自动备份原任务定义异常时一键回滚。这三条规矩看着朴素但能避免绝大多数“AI 好心办坏事”的场景。Agent 生成的配置如果直接改动了线上接入链路出了问题想恢复没备份的话就要手动重建非常痛苦。5. 真机运行中的常见问题与排查实录5.1 时间字段类型错乱导致写入失败这是我遇到频率最高的问题。CSV 里的时间是字符串“20240101150000”DolphinDB 目标表是 TIMESTAMP 类型映射时如果只做普通字符串映射写入必然失败但如果统一转换成 TIMESTAMP又可能和行情数据的时区、格式不一致。解决办法是在字段映射阶段加上显式转换规则推荐先转成标准时间的字符串格式再用 parse 函数转成时间类型。具体写法取决于你用的 DolphinX 版本核心思路是“先统一格式再转换类型”。我在多个项目里验证过这个方法最稳定。5.2 实时流任务积压与断点续传行情数据做到后面一定会加实时链路。DolphinDB 的流计算框架支持订阅外部消息队列DolphinX 也提供了实时接入任务类型。我遇到过的坑是上游行情量大时如果目标表所在节点写入压力大实时任务会出现积压而且任务重启后会从头消费导致大量重复数据。解决思路分两层。第一层是优化写入性能比如适当增加并发写入线程数、调整分区策略第二层是开启断点续传任务重启时从上次记录的位置继续消费而不是从头来。DolphinX 的任务配置里有相关选项建议上线前一定测试一下“上游中断-恢复”的场景。5.3 交易日历和复权因子怎么处理这是行情接入里最容易“被忽略但又必须处理”的部分。分钟线、日线数据都依赖交易日历不同交易所的节假日不一样比如沪深股市和香港市场的开市日就不是完全相同的。DolphinDB 内置了常见交易所的交易日历DolphinX 在任务配置里可以指定使用哪种日历确保增量任务在非交易日不空转。复权因子更特殊它不是一个独立数据源而是要跟行情表关联使用。DolphinX 支持在接入行情表的同时把复权因子表一并管理起来。实际项目中我会把前复权和后复权计算放到 DolphinDB 的计算层而不是在接入层硬算这样职责清楚、性能也更好。5.4 Agent 生成配置出错了怎么办AI Agent 再智能也有判断失误的时候。有一次我让它自动推断一个新数据源的字段类型它把涨跌停字段推断成了整型实际数据里既有数字也有字符串“None”导致写入到一半报错。遇到这种情况别慌排查路径是停掉任务查看失败日志确认是哪个字段、哪条数据出了问题改好映射规则后再重新执行。如果是 Agent 生成的映射规则有问题直接在映射界面手动修正就行。我的经验是Agent 最擅长的是从零生成一套框架但涉及边界情况空值、特殊值、类型歧义时人工把关仍是必须的。6. 常用问题速查表问题现象常见原因解决方式任务执行成功但写入 0 行源文件路径错误或表名写错查看执行日志确认读取行数和目标表名时间字段写入报错字符串时间格式未转换映射规则里显式转换 TIMESTAMP增量任务重复写入没有开启断点续传或去重开启断点续传配置主键去重策略实时任务积压严重写入并发不够或分区策略不合理提高并发数重设分区键和分区数量Agent 推断字段类型错误源数据含特殊值或脏数据人工修正映射规则并在清洗层加过滤非交易日任务空跑没有绑定交易日历在任务调度中指定交易所交易日历7. 接入完数据之后我的一些实在经验7.1 先把数据字典和命名规范定下来这个是所有经验里最想强调的一条。DolphinX 的映射配置能做到高度自动化前提是字段命名和类型规范足够统一。如果前端数据源的表字段叫 day_open另一份叫 d_openAgent 再聪明也得猜。我后来强制在数据接入层定义了一套统一字段字典源字段无论叫什么入库前全部映射成标准命名后面做因子计算和模型训练时真的省了很多事。7.2 用“分层接入”的思路管理多源数据数据源多了之后我习惯把接入流程分成“贴源层”和“模型层”。贴源层尽可能保留原始字段和原始粒度比如逐笔成交就全字段入库模型层再按需加工成分钟线、日线或各类因子表。DolphinX 的接入任务很适合这种分层贴源层用简单的映射任务模型层用带复杂计算逻辑的转换任务。两层之间的依赖关系也能在调度里配置清楚。7.3 给 Agent 留一条“输出说明”的通道最后一个小技巧我在让 Agent 生成任务时会强制要求它输出一份简要的配置说明包括创建了什么任务、映射了哪些字段、执行方式和调度计划是什么。这不仅是给人看的也是给 Agent 自己“记忆”用的。下次调整配置时它能基于上次的说明更快理解上下文。这套做法让 Agent 的连续使用效果好了很多不会再出现“每次都要从头解释需求”的情况。行情接入这件事做到后面拼的不是某个工具多厉害而是整个链路能不能让人省心。DolphinDB 解决了存储和计算性能问题DolphinX 把接入流程标准化了AI Agent 又把标准化流程里重复的配置工作自动化了。对我这种什么都得管一点的从业者来说这套组合最大的价值是把宝贵的时间从数据搬运中解放出来留给真正需要动脑子的策略研究。
