适合单次查询
用户提问时获取一条行情，附上时间戳并返回有限字段。这是对话助手和研究流程最简单的方式。
金融与市场数据
如何为豆包接入实时股票市场数据
围绕时间戳、市场覆盖、数据时效和故障处理，为 Doubao 构建可靠的实时股票数据工作流。
发布日期：2026年4月18日 · QVeris团队制作
新鲜度契约
没有上下文的价格，不是可信行情
写代码前先定义应用中的“实时”究竟指什么。答案取决于交易场所、Feed 权限、账户、端点与交易时段，而不是模型名称。
SOURCE明确的数据源与 Feed
EVENT TIME行情事件发生时间
SESSION正常、盘前、盘后或休市
DELAY实时、延迟或未知
定义一个只读行情函数
从 get_stock_quote 这样的最小契约开始，接收股票代码与可选交易场所。不要把行情查询、持仓访问和交易执行塞进同一个工具。
{
"name": "get_stock_quote",
"parameters": {
"type": "object",
"properties": {
"symbol": {"type": "string"},
"venue": {"type": "string"}
},
"required": ["symbol"]
}
}
随豆包请求发送工具定义
按照当前部署模型与地域对应的火山方舟 SDK 或 Chat Completions 文档发起请求。模型可以提出工具调用，但不会替你请求数据源，也不应接触数据源密钥。
在应用代码中校验、请求并标准化
限制股票代码格式、消除同名代码歧义、设置超时，并使用服务端凭据调用数据源。最新成交价、买价、卖价和前收盘价含义不同，不能混为一谈。
返回带证据的结果
把标准化后的工具结果发回豆包生成解释。时间使用带时区偏移的 ISO 8601 格式，保留数据源名称，并加入机器可读的新鲜度状态。
{
"symbol": "EXAMPLE",
"exchange": "XNAS",
"currency": "USD",
"last": null,
"provider_timestamp": "2026-08-12T09:31:04-04:00",
"retrieved_at": "2026-08-12T09:31:05-04:00",
"session": "regular",
"delay_status": "unknown",
"source": "YOUR_PROVIDER"
}
以上仅为 Schema 示例，不是实时行情。
用确定性规则判断数据是否过期
数据年龄应由代码计算，而不是交给模型自由判断。若行情超过业务阈值，或 Feed 权限未知，就明确标记或终止回答；绝不能悄悄用前收盘价冒充当前价格。
选择传输方式
问答用快照，数据流留在应用侧
适合预警与实时看板
在豆包之外消费数据流，先去重、聚合，再仅针对有意义的事件或用户请求触发模型。
适合关注延迟与成本的场景
可按股票代码和交易场所短暂缓存，但必须暴露缓存年龄。过期答案即使返回很快，仍然是过期答案。
输出契约
让每个答案都能一眼核验
要求豆包按固定顺序呈现事实，避免流畅的自然语言掩盖缺失的市场上下文。
| 字段 | 作用 | 异常处理 |
|---|---|---|
| Symbol + exchange | 区分同名或跨市场标的 | 请用户确认 |
| Price type | 区分成交、买卖价与收盘价 | 不得静默推断 |
| Provider timestamp | 衡量行情事件新鲜度 | 不得称为实时 |
| Market session | 解释价格为何未变化 | 标明休市或未知 |
| Source + delay | 支持归因与权限核验 | 标明权限未知 |
行情查询必须与交易执行分离。 只读行情工具适合研究；下单工具则需要独立凭据、确定性限额、幂等控制、审计日志和明确的人类确认。本指南不实现交易。
验收测试
先测试失败场景，再测试正常流程
股票代码有歧义时要求澄清
正确识别休市状态
延迟 Feed 不会被称为实时
缺少时间戳时禁止声称当前价格
数据源超时返回受控错误
提示词注入无法获取凭据
买价、卖价与成交价保持区分
任何只读工具路径都不能下单
FAQ
豆包实时股票数据常见问题
豆包本身会提供实时股票价格吗？
不要把模型当作行情 Feed。应从获得授权的外部数据源取得当前报价，并附上来源、交易所、交易时段、延迟状态与数据源时间戳。
股票行情工具应该返回哪些字段？
至少应返回标准化股票代码、交易所、币种、价格、数据源时间戳、获取时间、交易时段、延迟状态与来源。买价、卖价和最新成交价应保持为不同字段。
需要把每个行情 Tick 都发送给豆包吗？
不需要。应在应用代码中接收并聚合数据流，只在需要时向模型发送有限的快照或事件摘要。
同一个工具可以直接下单吗？
行情查询应保持只读。交易需使用独立且强认证的操作路径，并配置确定性风控、幂等机制、审计日志和明确确认。
从一条行情开始
先核验时间戳，再相信答案
先测试一个股票代码，检查所选能力和返回字段；新鲜度契约通过后，再扩展覆盖范围。
生产级深入指南
先确定覆盖范围与数据权利，再选择 API
豆包可以解释标准化后的结果，但市场覆盖、交易时段、品种与数据使用权仍由服务商决定。候选清单应从用户真正需要回答的问题出发，而不是照搬通用股票 API 排名。
| 决策项 | 需要核验 | 对豆包回答的影响 |
|---|---|---|
| 市场覆盖 | 交易场所、品种、代码映射 | 避免回答未覆盖标的 |
| Feed 层级 | 实时、延迟、指示性、综合或单一场所 | 决定价格旁的标签 |
| 时段覆盖 | 盘前、正常交易、盘后与集合竞价 | 解释最新值对应的市场事件 |
| 使用权利 | 内部使用、展示、再分发与留存 | 决定回答能否展示或存储 |
| 运行限制 | 速率、并发、重连与补数机制 | 决定缓存、重试与错误处理 |
把服务商留在适配层之后。 保持稳定的行情契约。如果需要行情之外的能力，可查看独立的豆包 API 选型指南；本页只聚焦当前股票行情。
生产运行
在模型之外控制时间、延迟、成本与故障
正确的工具 Schema 只是起点。遇到休市、代码冲突、服务商限流或备用 Feed 接管时，生产系统必须具有确定性行为。
时区与交易日历
行情时间应使用无歧义格式，并保留交易场所时区。交易状态要依据交易所日历判断，不能只看服务器时间。节假日、半日市、夏令时切换、停牌和集合竞价都会让近期时间戳产生误导。
缓存与请求合并
缓存键应包含股票代码、交易场所、字段集和交易时段。相同行情的并发请求可以合并，但必须返回 cache_age_ms 与原始数据源时间；读取缓存时不得刷新行情时间戳。
超时与熔断
数据源调用的截止时间应短于整体响应预算。只重试临时故障，加入随机抖动，并用熔断机制阻止重试风暴。切换备用源时应公开替换事实并重新计算延迟标签。
可观测性与回放
日志应记录请求 ID、所选工具、已校验参数、数据源状态、事件与获取时间、缓存年龄、模型接入点和新鲜度结论，同时移除密钥。回放应能在不请求实时数据源的情况下复现策略判断。
上线流程
验证完整的豆包行情数据闭环
先用固定样例测试，再接入真实凭据做小规模影子评估。目标是验证工具选择、字段保真度、新鲜度标签和受控失败，而不是评判投资结论。
| 阶段 | 测试内容 | 通过证据 |
|---|---|---|
| 契约 | 有效、无效与歧义代码 | 参数通过校验或触发澄清 |
| 固定样例 | 开市、休市、延迟、过期与停牌 | 每种状态均得到预期标签 |
| 集成 | 豆包工具调用往返 | 标准化结果与带来源回答 |
| 韧性 | 超时、限流、异常载荷与备用源 | 受控报错且不编造价格 |
| 安全 | 提示词注入与密钥索取 | 不暴露凭据或写权限 |
术语表
影响实时含义的关键术语
- 数据源时间戳
- 数据源为市场事件附加的时间，不等同于服务收到数据的时间。
- 获取时间戳
- 应用收到结果的时间，用于衡量传输延迟与缓存年龄。
- 数据权限
- 接收、展示、留存或再分发某类市场数据 Feed 的合同权利。
- 交易时段
- 盘前、正常交易、盘后、集合竞价、停牌或休市阶段。
- 最新成交
- 最近一笔已报告成交，可能与当前买价和卖价不同。
- 过期阈值
- 按业务场景定义、用于决定行情何时应标记过期或被拒绝的规则。
生产实施下一步
端到端验证一条带时间戳的行情
检查匹配能力、测试标准化输出，并在过期、休市与数据源故障场景均表现正确后再上线。