IOTXING随手记

AI、大模型与后端工程实践

示例：`openclaw security`、`tag:openclaw`、`cat:AI`
0%

Futu Stock MCP Server 开发复盘（中英切换）：我如何用 AI + Futu OpenD 做出可用的 MCP 行情工具

发表于 分类于
这是一篇可中英切换的项目介绍与开发复盘文章，完整讲清 futu-stock-mcp-server 的工具定位、架构设计、踩坑与迭代过程，帮助你把 AI 与实时行情系统真正打通。

这个工具是做什么的？

项目地址：
shuizhengqi1/futu-stock-mcp-server

futu-stock-mcp-server 是我做的一个 MCP Server，它把 Futu OpenD 的行情能力封装成标准化工具接口，让大模型可以直接调用实时证券数据。

简单说，它解决的是这件事：

  1. AI 很会分析，但默认拿不到实时行情。
  2. 行情接口很强，但接入门槛高、流程分散。
  3. 研究/复盘时，人在“查数据”和“做分析”之间来回切换。

我希望把这些步骤收敛成一条链路：
LLM -> MCP tools -> Futu OpenD -> 实时行情 -> 分析输出

我为什么要开发这个项目？

起点很现实：我想把“AI 分析能力”真正用在行情场景里，而不是只做静态内容总结。

在早期尝试中，我遇到两个明显问题：

  1. 模型结论经常脱离实时数据语境。
  2. 每次分析都要手动查行情，再拷贝给模型，效率很低。

所以我决定做一个专门的 MCP 工具层，把行情查询、K 线获取、盘口读取这些能力标准化，让 AI 可以直接调用。

开发过程复盘：我是怎么一步步做出来的

第 1 步：先定义“可交付边界”

我先把目标限定为一个“可稳定调用的行情工具层”，而不是自动交易系统。这个边界非常重要，它决定了架构不跑偏。

阶段目标是：

  1. 能稳定连接 OpenD。
  2. 能给 MCP 客户端提供一致的工具协议。
  3. 能覆盖常用行情查询场景。

第 2 步：技术选型与架构定型

核心选择：

  1. 协议层：MCP（便于和 AI 客户端直接对接）。
  2. 数据层：Futu OpenD（行情能力来源）。
  3. 服务层：Python 实现 MCP Server（开发效率与维护成本平衡）。

架构拆分思路是：

  1. Tool Interface：只关心输入输出协议。
  2. Market Service：负责行情调用和字段转换。
  3. Connection Layer：专门处理 OpenD 连接、超时、重试。

第 3 步：先做最小可用版本（MVP）

我先做了最小可用闭环：

  1. 启动服务。
  2. 连上 OpenD。
  3. 暴露一个可被模型调用的基础行情工具。

这一步不追求“功能多”，只验证“链路通 + 输出可读 + 调用稳定”。

第 4 步：处理最常见的稳定性问题

真正花时间的不是“写接口”，而是“处理不稳定性”。

我重点补了这些机制：

  1. 连接失败重试与错误分层（区分网络、权限、参数问题）。
  2. 更可读的错误信息（避免模型拿到不可解释异常）。
  3. 超时与空数据兜底（防止分析流程直接中断）。

这部分完成后，工具才从“能跑”变成“能用”。

第 5 步：把功能变成“可复用产品”

后续我做了三件事，让它更像产品而不是脚本：

  1. 增加多种安装方式（pipx / Docker / source）。
  2. 完善环境变量配置（例如 FUTU_HOST/FUTU_PORT）。
  3. 补充文档与 FAQ，降低第一次接入成本。

这次开发里我踩过的坑

坑 1：以为“启动成功”就代表“可用”

实际不是。服务能启动，只代表进程活着；不代表 OpenD 连通、权限正确、数据能完整返回。

坑 2：错误信息不友好会直接拖慢 AI 调试

如果把底层异常原样抛给模型，模型和人都会难排查。把错误信息改成“可定位问题”的表达后，联调效率明显提升。

坑 3：过早追求复杂功能

一开始就堆功能，很容易把系统复杂度拉高。先做“高频场景可稳定调用”，再扩展，是更好的迭代顺序。

这个项目最适合谁？

  1. 想做 AI + 行情分析自动化的开发者。
  2. 希望做投研辅助、复盘自动化的团队。
  3. 想把数据能力接入 Agent 工作流的工程团队。

如果你也在搭建类似体系，可以结合本站专题继续看：
AI ｜ OpenClaw ｜ 标签页

下一步计划（Roadmap）

  1. 补更多实用工具接口（按真实使用频率扩展）。
  2. 增强监控与日志可观测性。
  3. 提供更完整的“提示词 + 工具调用”最佳实践样例。

总结

这个项目对我最大的价值，不是“又做了一个接口服务”，而是把“AI 的分析能力”和“实时行情系统”连接成了可复用工作流。

如果你也有类似需求，欢迎直接看项目并上手：
shuizhengqi1/futu-stock-mcp-server

本文仅讨论技术实现，不构成投资建议。

What This Tool Is

Project:
shuizhengqi1/futu-stock-mcp-server

futu-stock-mcp-server is an MCP server I built to wrap Futu OpenD market capabilities into standardized tool interfaces, so LLMs can consume live market data directly.

It solves a practical gap:

  1. AI can analyze well, but usually lacks real-time market input.
  2. Market APIs are powerful, but integration is costly.
  3. Research workflows often force people to switch between data fetching and AI analysis.

My target workflow is:
LLM -> MCP tools -> Futu OpenD -> live market data -> analysis output

Why I Built It

I wanted AI analysis to be grounded in live market context, not static text.

In early experiments, two pain points kept repeating:

  1. Model conclusions were detached from real-time context.
  2. Manual copy-paste from market apps to AI tools was too slow.

So I decided to build a dedicated MCP tool layer for market queries, candles, and order book access.

Development Retrospective: How I Built It

Step 1: Define a strict delivery boundary

I defined this as a reliable market tool layer, not an auto-trading system. That boundary kept the architecture focused.

Initial goals:

  1. Stable OpenD connectivity.
  2. Consistent MCP tool protocol for clients.
  3. Coverage of common market query scenarios.

Step 2: Finalize stack and architecture

Core choices:

  1. Protocol: MCP.
  2. Data source: Futu OpenD.
  3. Service implementation: Python MCP server.

I split responsibilities into:

  1. Tool Interface: protocol-facing input/output.
  2. Market Service: market calls and data mapping.
  3. Connection Layer: connection, timeout, retry, and failure handling.

Step 3: Build an MVP first

The first milestone was a minimal but complete loop:

  1. Start server.
  2. Connect to OpenD.
  3. Expose at least one callable market tool.

I optimized for end-to-end reliability, not feature count.

Step 4: Solve reliability before expansion

Most effort went to stability, not API shape.

Key improvements:

  1. Retry strategy and error categorization.
  2. More actionable error messages.
  3. Timeout and empty-data fallbacks.

This is where it moved from “runnable” to “usable.”

Step 5: Productize the project

To make it reusable beyond my own environment, I added:

  1. Multiple install paths (pipx / Docker / source).
  2. Clear environment config (FUTU_HOST/FUTU_PORT, etc.).
  3. Better documentation and FAQ for onboarding.

Mistakes and Lessons

Lesson 1: “Process started” does not mean “system works”

A running process does not guarantee OpenD connectivity, permissions, or valid market payloads.

Lesson 2: Poor error messages slow down AI integration

Raw low-level exceptions are hard for both models and engineers. Better error semantics dramatically improved debugging speed.

Lesson 3: Feature expansion too early increases complexity

Stabilize high-frequency scenarios first, then expand.

Who This Is For

  1. Developers building AI-assisted market analysis workflows.
  2. Teams working on recap/monitoring/research automation.
  3. Engineers integrating market data into agent systems.

Related topics:
AI | OpenClaw | Tags

Roadmap

  1. Add more high-frequency market tools.
  2. Improve observability and monitoring.
  3. Publish more prompt + tool-call best-practice examples.

Final Takeaway

The biggest value of this project is not “another API wrapper.”
It is the reusable bridge between AI reasoning and live market systems.

If this matches your use case, feel free to check and use the project:
shuizhengqi1/futu-stock-mcp-server

This article is for technical discussion only, not investment advice.