摘要：量化开发者通过一个实时行情 API 接入 A 股、美股、港股等多类资产时，MCP 工具调用的成功状态（code=0）不等于横截面数据完整。一次静默的资产缺失，就可能歪曲你的统计口径、权重分配和监控覆盖。本文基于 TickDB 的跨市场调用实测，给出一套“完整/降级/关闭”验收标准，将数据完整性判断独立于任务执行状态之外。
跨市场策略的研究者都有过类似经历：一个同时覆盖 A 股、港股、美股和数字货币的监控任务，跑了几天之后才发现某个品种根本没返回数据。检查日志，每次调用都显示成功——code=0，任务状态正常。
问题不在调用是否成功，而在于：批次成功是任务状态，横截面完整是数据状态。两者必须分别判断。 你把请求发出去，接口返回了，code=0 告诉你工具调用结束。但它不能替你回答：请求的 symbol 全部回来了吗？有没有意外缺失？回来的品种资产类型对吗？有没有你没请求的 symbol 混了进来？
本文不讨论策略怎么写，也不讨论哪个市场值得关注。本文只做一件事：给你一张跨市场数据完整性验收卡，让你在任务上线前，先把“数据到底全不全”这件事独立地管起来。
资产缺失会怎样静默污染下游
假设一个定时任务每天拉取五类资产快照，用于跨市场比价或监控面板。某次请求中，数字货币品种没有返回，但任务仍标记为成功。以下三类问题会安静地发生：
比率计算失真。 计算依赖 A 股和数字货币的价格比，数字货币缺失后，比率要么无法计算，要么被填入上一期缓存值。前者中断任务，后者制造一条看起来正常、实际已经失真的结果。
权重被动偏移。 面板按资产类别分配权重，少了一类资产后，其余类别相对权重提高。波动率、风险暴露的统计口径已经改变，系统不会报错，你也不会立刻察觉。
监控盲区出现。 告警规则是“任意资产波动超过阈值”，缺失的品种不会触发告警。不是市场没波动，是波动没进入系统。
这三类问题的共同特点：静默。 程序没崩溃，任务没报错，结果表正常生成，但计算输入已经不完整。
实测：code=0 对应三种不同的数据状态
以下测试于 2026 年 6 月 13 日通过 TickDB MCP get_ticker 完成。测试只核对返回状态 code、请求 symbol、返回 symbol 和返回资产类型 type。价格和成交量属于动态行情，不作为本文结论依据。
测试一：不传 type，请求五个代表品种。 五个品种（A 股、港股、美股、数字货币、外汇）全部返回，返回的资产类型与实际一致。
测试二：传入 type=stock，请求相同五个品种。 三个股票返回，数字货币和外汇没有返回。code=0 仍然为成功状态。如果程序事先不知道这两个品种会被排除，只看到 code=0 就继续运行——这批数据就是横截面不完整的。
测试三：请求包含一个无效代码。 返回结果中只有有效品种，无效代码静默消失，code=0 仍然为成功状态。如果它不是事先声明的预期排除项，这就是一次意外缺失。
三组结果可以归纳为一张判断表：
| 本轮调用状态 | 返回集合状态 | 数据判断 |
|---|---|---|
code=0 |
请求 symbol 全部返回 | 完整 |
code=0 |
与已验证的预期排除一致 | 降级 |
code=0 |
无效或异常 symbol 静默缺失 | 不完整 |
所以，code=0 之后仍然需要一次独立的数据完整性判断。
什么时候放行、什么时候降级、什么时候关闭
在 MCP 调用与下游计算之间，可以增加一道完整性闸门：
| 任务状态 | 数据状态 | 是否放行 | 处理动作 |
|---|---|---|---|
| 成功 | 返回集合完整，无重复，类型一致 | 放行 | 正常进入下游 |
| 成功 | 仅缺少已验证的预期排除项 | 降级放行 | 记录排除条件和缺失项 |
| 成功 | 存在意外缺失、新增、重复或类型错误 | 关闭 | 关闭批次并告警 |
| 失败 | 未获得有效结果 | 关闭 | 按错误状态处理 |
完整批次的标准是：返回集合 = 请求集合 - 预期排除集合，并且没有意外缺失、没有意外新增、请求和返回中没有重复 symbol、返回的资产类型与预期一致、预期排除项没有意外出现在返回中。
跨市场数据完整性验收卡
以下检查清单，建议每次跨市场任务进入下游前逐项确认：
| 序号 | 检查项 | 说明 |
|---|---|---|
| 1 | 请求前定义预期 | 记录本次请求的 symbol 和对应资产类型 |
| 2 | 保存请求原始集合 | 不要依赖后续推断，先存下来 |
| 3 | 验证预期排除项 | 排除的 symbol 是否针对当前工具已验证 |
| 4 | 提取返回 symbol 和 type | 不只看价格，不只看数组是否为空 |
| 5 | 检查请求重复 | 同一个 symbol 是否在请求中出现了多次 |
| 6 | 检查返回重复 | 同一个 symbol 是否在返回中出现了多次 |
| 7 | 检查意外缺失 | 没被排除的 symbol 是否有未返回的 |
| 8 | 检查意外新增 | 返回中是否出现了没请求过的 symbol |
| 9 | 检查资产类型错配 | 返回的 type 是否与请求时声明的一致 |
| 10 | 检查排除项意外返回 | 已声明排除的品种是否又出现在了返回里 |
| 11 | 关闭批次规则 | 意外异常必须关闭，不能只打印警告 |
| 12 | 降级批次记录 | 降级继续时记录排除条件和缺失项 |
| 13 | 下游消费边界 | 下游只消费通过完整性检查的批次 |
| 14 | 新工具接入验证 | 新端点、新资产类别接入时重新验证实际行为 |
把完整性校验写进数据管道
校验可以分三步走。
第一步：请求前定义预期。 记录请求的 symbol 和对应资产类型。如果使用了 type 参数，还要记录哪些 symbol 预计不会返回、这种行为是否已针对当前工具验证、本批次是否允许降级继续。
第二步：返回后提取实际集合。 从返回记录中提取 (symbol, type)，不要只提取价格，也不要只检查数组是否为空。
第三步：执行多维比对。 至少检查请求和返回中的重复 symbol、意外缺失、意外新增、资产类型错配，以及预期排除项是否意外返回。任一异常未被解释，都不应进入下游计算。
以 TickDB 这类统一行情 API 为例，同一个接口可以覆盖股票、数字货币、外汇等多类资产的快照查询，返回结构一致，type 字段直接标记资产类型。这让完整性校验可以在统一字段体系下完成——你不需要为每个市场单独写一个校验脚本，只需要维护一份“请求了什么、预期返回什么”的对照表，和实际返回集合做比较。
但必须明确：code=0 只表示工具调用成功，不能替你判断横截面是否完整。 这份判断，只能由你的程序对照请求集合、返回集合和预期排除集合来完成。任何接口都无法自动知道你本意要请求哪些品种、容忍哪些缺失——这是数据管道的工程责任，不是 API 能替你做的决策。
不能从本文推出什么
- 三组测试结果仅来自 2026 年 6 月 13 日的 TickDB MCP
get_ticker调用，不代表其他工具具有相同行为。 - MCP 实测不能直接证明 REST、WebSocket、K 线或逐笔接口的行为。
- 五个代表品种成功返回，不表示所有品种在所有时间均可用。
- 下游比率失真、权重偏移和监控盲区属于工程风险推演，不是 MCP 返回结论。
- 本文不涉及策略收益、回测绩效或买卖决策。
可保存的验收卡速查版
- 请求 symbol 和预期资产类型已定义。
- 请求原始集合已保存。
- 预期排除项已验证。
- 返回
(symbol, type)已提取。 - 请求重复已检查。
- 返回重复已检查。
- 意外缺失已检查。
- 意外新增已检查。
- 资产类型错配已检查。
- 排除项意外返回已检查。
- 意外异常会关闭批次。
- 降级批次已记录排除条件。
- 下游只消费通过检查的批次。
- 新工具接入时重新验证。
跨市场数据任务真正需要判断的，不只是“请求有没有成功”，而是：我要求的数据是否不多、不少、类型正确地回来了。 只看 code=0，你知道的是工具调用结束了。核对请求集合、返回集合和资产类型之后，你才知道这批数据是否可以进入下游。
免责声明：本文仅讨论跨市场量化任务中的数据完整性校验与工程治理方法，不构成任何投资建议。文中不包含对任何策略有效性的评价，不推荐任何具体证券或交易方向，不对未来收益做任何暗示。所有接口描述仅为说明数据校验的工程框架，不代表特定产品的功能承诺。
标签：#跨市场策略 #行情数据完整性 #批次校验 #统一行情API #量化数据治理 #MCP #TickDB