最近很多人把 Agent 用到真实工作流里。

写代码、查资料、生成日报、整理文档都已经比较常见。

自然也会有人问：

WorkBuddy、Codex、豆包、扣子这些工具，能不能接 A股数据源？

答案是：能。

但要换一个思路。

不要把它理解成“给模型一个接口地址”。

更好的理解是：给 Agent 一组能完成任务的工具。

一、不同平台名字不同，本质都是工具调用

不同产品对外部能力的叫法不一样。

有的叫 MCP Server。

有的叫插件。

有的叫外部工具。

有的叫 HTTP Action。

有的叫工作流节点。

有的需要你自己写一层后端适配。

名字不一样，本质问题差不多：

当用户提出任务时，Agent 能否选择正确的数据工具，拿到结构化结果，然后继续完成分析？

所以，与其问“某个平台能不能接某个 API”，不如问：

• 这个平台能不能调用外部工具；
• 工具参数能不能约束；
• 返回结果是不是结构化；
• 鉴权怎么处理；
• 工具说明能不能让模型看懂；
• 多个工具能不能组成一个工作流。

二、A股数据不适合只做成一个“大接口”

很多人一开始会想做一个接口：

/stock/analyze?code=xxx

让它一次返回所有内容。

短期看省事，长期看不利于 Agent。

因为 Agent 的问题经常不同。

用户可能问：

今天市场情绪怎么样？

也可能问：

帮我看一下半导体板块有没有资金回流。

还可能问：

昨天涨停今天断板的票里，有没有反包迹象？

这些任务需要的数据完全不同。

更好的方式是拆成一组小工具：

• 市场概览；
• 个股行情；
• K 线；
• 分时；
• 资金流；
• 涨停梯队；
• 炸板池；
• 题材热度；
• 公告；
• 条件选股；
• 自选股。

Agent 根据任务自己组合工具，效果会更自然。

三、WorkBuddy / Codex：优先考虑 MCP 工具层

WorkBuddy、Codex 这类偏工作台或编码 Agent 的环境，更适合接结构化工具。

如果客户端支持 MCP，可以优先考虑 MCP。

它的好处是：

• Agent 可以发现工具；
• 参数有 schema；
• 工具说明可以被模型读取；
• 多个工具可以组合；
• 配置相对清晰；
• 不用把一大段 API 文档长期塞进上下文。

一个 MCP 配置大概长这样：

{
  "mcpServers": {
    "a-share-data": {
      "url": "https://stock.quicktiny.cn/api/mcp",
      "headers": {
        "Authorization": "Bearer YOUR_API_KEY"
      }
    }
  }
}

不同客户端字段名可能不一样，实际配置以对应产品文档为准。

关键不是这段 JSON，而是背后的工具设计。

例如用户问：

帮我做今天 A股盘后复盘。

Agent 不应该只搜索网页。

它可以依次调用：

1. 市场概览；
2. 涨停梯队；
3. 题材热度；
4. 资金流；
5. 核心个股行情；
6. 风险和催化事件。

最后再生成报告。

这就是工具层的价值。

四、豆包 / 扣子：可以用 HTTP 工具或工作流节点适配

豆包、扣子这类智能体平台，经常更强调应用搭建、知识库、流程编排和外部工具。

如果平台原生支持 MCP，就直接接 MCP。

如果当前项目里更适合 HTTP 工具，也可以做一层适配。

思路是：

• 外部数据源仍然保持结构化；
• 后端封装成几个清楚的 HTTP 工具；
• 每个工具有明确输入、输出和错误说明；
• 在平台里把这些工具挂给智能体；
• Prompt 里只写任务策略，不塞完整接口文档。

例如可以把工具拆成：

get_market_overview
get_stock_kline
get_limit_up_ladder
get_capital_flow
search_announcements
screen_stocks

工具说明写清楚：

• 用来做什么；
• 参数是什么；
• 返回字段是什么意思；
• 数据时间是什么；
• 查不到时怎么办。

这样即使平台不是 MCP，也能接近 MCP 的思路。

五、一个推荐架构：数据源、适配层、Agent 三层分开

比较稳的接法是三层：

层级	作用	示例
数据源层	负责原始数据	行情、K 线、公告、资金、题材、交易日历
适配层	负责清洗和工具化	MCP Server、HTTP 工具、缓存、限流、鉴权
Agent 层	负责理解任务和生成结果	WorkBuddy、Codex、豆包、扣子、自建 Agent

这样做的好处是：

• 换 Agent 平台时，不用重做数据逻辑；
• 换底层数据源时，不用改 Prompt；
• 工具调用失败时，更容易定位问题；
• 同一套数据能力可以复用给多个入口。

六、Prompt 不要写成接口文档

很多 Agent 失败，不是模型能力不够，而是 Prompt 被接口细节淹没了。

不建议在系统提示里写一大段：

如果用户问行情，就请求某 URL；参数 a 是这个，参数 b 是那个；返回字段 x 是这个，字段 y 是那个……

这种写法维护成本很高。

更好的方式是：

• 工具 schema 负责参数约束；
• 工具描述负责用途说明；
• Prompt 只负责业务策略。

例如 Prompt 可以写：

当用户要求 A股复盘时，先查询市场概览，再查询涨停梯队、题材和资金流。
如果数据日期不是用户指定日期，需要在回答里说明。
如果工具返回缺失或质量提示，不要编造结论。

这样更像一个可维护的系统。

七、A股 Agent 最容易漏掉的字段

接 A股数据源时，除了价格和涨跌幅，还要特别注意这些字段：

• 交易日期；
• 实际数据日期；
• 是否交易日；
• 数据更新时间；
• 涨停 / 跌停状态；
• 连板数；
• 炸板状态；
• 题材归属；
• 成交额；
• 换手率；
• 资金净流入；
• 公告发布时间；
• 数据质量提示。

没有这些字段，Agent 写出来的报告可能很像样，但可验证性不够。

八、可以从三个小场景开始

不要一上来就做“全能股票 Agent”。

可以先做三个小闭环。

1. 每日市场复盘

输入：

今天 A股怎么样？

工具：

• 市场概览；
• 涨停梯队；
• 题材热度；
• 资金流。

输出：

• 市场状态；
• 主线方向；
• 风险点；
• 明日观察。

2. 自选股摘要

输入：

帮我看一下自选股今天有没有异常。

工具：

• 自选股列表；
• 个股行情；
• K 线；
• 公告；
• 资金流。

输出：

• 异动个股；
• 原因线索；
• 需要继续观察的点。

3. 题材跟踪

输入：

半导体今天是不是主线？

工具：

• 题材热度；
• 成分股表现；
• 涨停梯队；
• 资金流；
• 新闻或公告补充。

输出：

• 是否有持续性；
• 核心标的；
• 风险和分歧。

这三个场景跑顺以后，再扩展到公告掘金、龙虎榜、研报摘要、交易计划会更自然。

九、文末资料区

如果你在做 A股数据接入，可以根据平台能力选择：

• 支持 MCP 的 Agent：优先接 MCP 工具层；
• 支持 HTTP 工具的平台：用后端适配成多个小工具；
• 只支持知识库的平台：知识库适合资料说明，不适合实时行情；
• 自建 Agent：建议把数据源、工具层、Prompt 策略分开。

我自己整理过一个 A股 MCP 工具层案例，供做架构参考：

https://data.quicktiny.cn/
https://data.quicktiny.cn/agent-stock-data-source.html
https://stock.quicktiny.cn/developer
https://stock.quicktiny.cn/api/mcp

重点不是绑定某个平台，而是形成一套可迁移的数据工具层。这样无论是 WorkBuddy、Codex、豆包、扣子，还是后续新的 Agent 平台，都能复用同一套 A股数据能力。

最后补一句：自动化股票研究只能提高信息整理效率，不能替代独立判断，也不构成投资建议。