系列文章第 6 篇：AI Agent 查询实时行情：工具负责取数，模型负责解释
TickDB Research ·
这是 TickDB 实时行情接入系列的第 6 篇。前一篇解决“字段和 timestamp 避坑”，本文解决“AI Agent 查询行情”。
摘要
AI Agent 查询当前行情时，模型不应凭记忆生成价格。更稳妥的结构是：模型负责理解问题和解释结果，应用层负责调用工具与处理失败，数据层负责返回结构化行情数据。只要工具调用失败、超时、鉴权失败或返回空数据，Agent 就必须停止给出具体价格答案。
用户问一句：“苹果现在多少钱？”
一个不可靠的 Agent 可能会直接回答一个看起来很确定的价格。语气很顺，格式也很像专业助手，但问题在于：它没有调用任何实时行情工具，也没有给出可追溯的数据来源。
在行情场景里，最危险的往往不是“我不知道”，而是模型在不知道的时候仍然给出一个像真的答案。
本文只讲一个边界：
当前行情必须由工具或 API 获取；模型负责理解问题和解释结果；工具失败时，不得继续生成价格答案。
TickDB 在文中只作为“外部行情数据工具”的一个例子出现。普通聊天框不会因为读了这篇文章就默认接入 TickDB，模型本身也不会自动执行 REST API。
一、行情 Agent 的三层边界
做实时行情 Agent，先不要急着选模型，也不要一上来写一大段提示词。更重要的是把职责分清楚。
| 层级 | 负责什么 | 不负责什么 |
|---|---|---|
| 模型层 | 理解用户问题、判断是否需要实时数据、解释工具返回结果、组织自然语言答案 | 凭记忆生成当前价格、在工具失败后继续补价格、把推测写成事实 |
| 应用层 | 管理工具调用、校验输入、执行行情查询、处理超时/鉴权/空数据、记录调用证据 | 把失败伪装成成功、把未查询到的数据交给模型自由发挥 |
| 数据层 | 通过外部工具或 API 返回结构化行情数据 | 理解自然语言意图、替用户做投资判断、保证模型一定会正确表达 |
这张表是整套系统的底线。
模型可以很擅长理解“苹果现在多少钱”是在问行情，也可以把工具返回的结果解释成人能读懂的话。但“当前行情”这个动态事实，不应该从模型记忆里来。
二、为什么当前行情不能由模型自己回答
原因很简单：行情是动态事实。
股票、数字资产、外汇或其他市场数据，会随时间变化。模型训练语料和上下文信息有边界，语言流畅度不等于事实新鲜度。一个回答写得越像真的，反而越容易让用户忽略它没有实时数据来源。
所以，在行情 Agent 里，模型应该先判断问题类型：
| 用户问题类型 | 是否需要工具 | 原因 |
|---|---|---|
| “某标的现在多少钱？” | 需要 | 当前价格是动态数据 |
| “帮我解释一下行情 API 和模型的分工” | 不一定 | 这是概念解释，不一定需要实时查询 |
| “比较两个标的当前价格” | 需要 | 涉及多个当前行情数据 |
| “明天会不会涨？” | 不应直接给结论 | 这是预测和投资判断，不是单纯行情查询 |
只要问题涉及“现在”“当前”“最新”“刚刚”“今日价格”这类动态事实，Agent 就必须进入工具链路，而不是让模型直接回答。
三、从用户问题到可追溯答案的流程
一个更稳妥的行情 Agent，可以按这条链路工作：
用户提出行情问题
-> 模型识别这是动态数据问题
-> 模型请求调用行情工具
-> 应用层校验查询对象和权限
-> 应用层调用外部行情 API
-> 数据层返回结构化结果
-> 应用层记录工具调用状态
-> 模型只基于工具结果生成回答
-> 如果工具失败，模型说明失败原因，不给价格
关键点不在于“模型会不会说得漂亮”，而在于最后的答案能不能追溯到一次真实工具结果。
一个合格回答至少应包含三类信息：
| 信息 | 作用 |
|---|---|
| 查询对象 | 让用户知道查的是哪个标的或市场对象 |
| 数据来源 | 说明结果来自外部行情工具，而不是模型记忆 |
| 查询状态 | 明确工具调用成功、失败、超时或未返回有效数据 |
如果缺少工具调用结果，回答就应该停在“无法获取当前行情”，而不是继续生成一个价格。
四、失败关闭门禁：工具失败时必须停下来
行情 Agent 最需要保存的不是“成功时怎么说”，而是“失败时怎么闭合”。
| 失败场景 | 错误做法 | 正确做法 |
|---|---|---|
| 模型没有触发工具 | 直接回答当前价格 | 提醒尚未获取实时数据，不给具体价格 |
| 用户输入对象不清楚 | 让模型猜测用户想查哪个代码 | 要求用户补充或选择明确对象 |
| 工具超时 | 用旧知识补一个近似值 | 说明查询超时，建议稍后重试 |
| 鉴权失败 | 继续生成行情结论 | 停止回答价格，提示检查工具或 API 配置 |
| 工具返回空数据 | 编造一个看似合理的数值 | 说明未查询到有效行情结果 |
| 应用层无法确认返回结构 | 让模型自由解释原始文本 | 标记为不可用结果，进入排错流程 |
| 数据来源不可追溯 | 用“根据市场情况”模糊带过 | 明确当前没有可追溯行情数据 |
这里的原则很硬：
没有工具结果，就没有当前价格答案。
这不是保守，而是工程系统应有的基本可靠性。
五、TickDB 在这条链路里的位置
如果你需要给 Agent 接入行情数据，可以把 TickDB 这类外部行情数据服务放在数据层或工具层。
它在链路中的位置大致是：
用户问题
-> 模型判断需要行情
-> 应用层调用外部行情工具
-> TickDB 作为行情数据工具示例返回结构化结果
-> 模型基于结果解释
注意，这里有几个边界：
| 可以这样理解 | 不能这样理解 |
|---|---|
| TickDB 可以作为外部行情数据工具示例 | 普通聊天框默认已经接入 TickDB |
| 应用层可以封装 API 调用给 Agent 使用 | 模型会自动执行 REST API |
| 模型可以解释工具返回的数据 | 模型自己知道当前行情 |
| 工具失败时应返回失败状态 | 工具失败后模型还能继续给价格 |
如果后续要写具体 REST、WebSocket 或 MCP 接入，就应该分别核验对应文档和实际配置。本文不展开具体接口字段，也不把某一种接入方式说成所有场景的默认答案。
六、能回答 / 不能回答边界
行情 Agent 不是万能金融助手。它能做的是“在工具成功时解释数据”，不是替用户判断收益、下单或预测未来。
| 用户问题 | 能否回答 | 前提或边界 |
|---|---|---|
| “查询某标的当前行情” | 可以 | 外部行情工具调用成功 |
| “比较两个标的当前价格” | 可以 | 工具成功返回多个查询结果 |
| “刚才查询失败了，为什么？” | 可以 | 应用层保留了失败状态或错误信息 |
| “这个价格是什么意思？” | 可以 | 只解释数据含义，不扩展成投资建议 |
| “明天会涨吗？” | 不应给确定结论 | 属于预测和投资判断 |
| “现在适合买入吗？” | 不应回答为建议 | 涉及投资建议 |
| “帮我自动下单” | 不属于本文范围 | 需要交易、风控、审计等独立系统 |
| “工具失败了，你估一个价格” | 不应给价格 | 失败关闭门禁必须生效 |
最容易出问题的不是 Agent 完全不会答，而是它在边界外继续答。
七、一个更稳的回答模板
工具调用成功时，可以这样回答：
我已通过外部行情工具查询到结果。
查询对象：……
查询状态：成功。
当前返回结果为：……
以下是对该结果的解释：……
工具调用失败时，应该这样回答：
我无法获取当前行情。
原因是：行情工具调用失败 / 超时 / 未返回有效数据。
因此我不能给出当前价格。你可以稍后重试，或检查查询对象和工具配置。
两种回答的差别不在语气，而在证据。
成功时，模型基于工具结果解释。失败时，模型承认没有数据，不继续补答案。
八、文末系列导航
这篇是 S04，重点讲 AI Agent 查询实时行情时的职责边界和失败关闭。
后续可以按这条路线继续读：
| 系列 | 主题 | 适合解决的问题 |
|---|---|---|
| S00 | TickDB 产品总入口与首次验证路线图 | 先理解 TickDB 适合放在什么接入位置 |
| REST 专题 | 用 API 完成一次可核验行情查询 | 需要最小可复现查询链路 |
| WebSocket 专题 | 订阅、心跳与断线恢复边界 | 需要持续接收行情更新 |
| MCP 专题 | Agent 工具调用与数据接入 | 需要让支持 MCP 的环境调用行情工具 |
最后再强调一次：
行情 Agent 的可靠性，不取决于模型把话说得多像专家，而取决于它在没有工具结果时能不能停下来。
标签
AI Agent、Function Calling、实时行情、金融数据、TickDB