daily_stock_analysis 深度评测：6.7 万 Star 的多市场股票分析系统，1164 项核心测试全绿，三种故障形态却只有一种能触发熔断

你只要在 GitHub 上 Fork 一个仓库、填两个密钥，第二天早上打开微信就能收到一份「今天这只票该不该动」的报告。这条流水线今年 1 月开源，到现在 9 个月。

它有 6.7 万颗星。但真正反常的是另一个数：Fork 数是 5.5 万，比值 0.83。我顺手查了站内评过的几个同类——字节的 DeerFlow 是 0.14，Hindsight 是 0.12，ECC 是 0.15，context-mode 是 0.07。也就是说，别人家的仓库是「大概看一眼」，这个仓库是「基本都抱走了」。

这个数字说明读者拿它当工具，不是拿它当读物。所以我这轮没停在读代码上：拉下来装了依赖、跑了它自己的检查脚本和一批核心测试、接了真实行情源跑通整条链路，然后自己写了几个探针去戳它最该结实的两个地方。

结论先说：架子和文档的份量都是真的，但我戳出的三处里，有一处是文档写明的承诺没做到。

一、它到底帮你干了什么

一句话：它是一套把「行情数据 + 技术指标 + 新闻 + 大模型判断」串成日报的流水线，覆盖 A 股、港股、美股、日股、韩股、台股和 ETF。

每天收盘后，它做的事按顺序是这样：

先把你要看的几只票的日线拉下来，算出均线、量能、价格位置这些技术指标；再去搜这几只票的新闻和公告；然后把这两堆东西一起丢给大模型，让它输出一份固定格式的「决策仪表盘」——核心结论、评分、买卖点位、风险警报、操作清单；最后按你配的渠道推出去，企业微信、飞书、Telegram、Discord、Slack、邮件都行。

这个「固定格式」是它和「直接问 ChatGPT」的关键区别。模型被要求吐出一段结构化数据，而不是一段散文。数据到位了，它才能算评分、比上一次的判断、做回测，也才能把结果渲染成一张图推给你。

技术上它做了两件不太显眼但很花钱的事。

一是多数据源兜底。行情源不是一个，是一串：东方财富、同花顺、通达信、百度、Yahoo、长桥、富途……按优先级排好，前一个挂了自动换下一个。这类项目最常见的死法就是「免费接口一改，整个项目变砖」，它显然是踩过坑之后才堆出这么厚的兜底层。

二是把 AI 的判断变成可回测的东西。它把每次分析结果存进本地数据库，之后可以回头对账：当时说「买入」，后来涨了没有。这一步决定它是「每天给你讲个故事」还是「每天给你一条可打分的记录」。

仓库规模：全仓 655 个 Python 文件、36 万行，其中测试目录占 298 个文件、16.7 万行；另有 15 份策略配置、58 篇文档、一个 291 个文件的前端工作台。它甚至有一篇挂在 arXiv 上的论文（编号 2608.26990，2026 年 8 月提交）。

二、我跑出来的数字

评测机是单核、2G 内存的 Linux 机器，全程关在隔离沙箱里跑：宿主机的密钥、配置、家目录都看不见，克隆、装依赖、跑测试全在里面完成。

先说它自己的检查闸门。仓库带一个一键检查脚本，我按 CI 的方式跑了两道：语法编译全过；代码规范检查（只查会真出错的严重项）报了 0 条。

再说测试。它收集到 8346 个离线用例。这个数量我在这台机器上跑不完——5 分钟只推进了 4%，单核跑全量要几个小时。所以我改成按核心链路分组抽跑，挑了 1164 个：数据源切换、报告渲染、通知、存储、决策字段、交易日历、接口约定（对外接口允许什么、返回什么）、Agent 编排（多个模型调用怎么排先后）。

1164 项全绿，零失败零跳过。 这不是「全量通过」，是我没跑完全量——这一点写在这里，是因为后面我要拿测试全绿说事，得先把口径交代清楚。

然后是真机取数。我拿三只票跑了一遍真实链路：

贵州茅台：首选源（东方财富）重试 4 轮全部断在握手，自动切到第二个源，走新浪接口成功拿到 36 根日线，总共 23.5 秒；

腾讯控股：走 Yahoo 源，6.2 秒；

苹果：走 Yahoo 源，0.3 秒。

切换和兜底是真能用的。

三、三处没兜住的地方

第一处：熔断器只认三种失败里的一种

它文档里写得很明确：某个数据源连续失败 3 次，就短期冷却 5 分钟，这期间先跳过它。这个机制叫熔断，原意是电路过载自动断开，这里指「一个源老失败就先别用，省得每只票都白等它一遍」。

我写了三个假数据源，让它们用三种不同方式失败，各跑 6 轮，看熔断器认不认：

失败方式	假数据源被调用的次数	熔断器状态	判定
直接抛错（报异常）	3 次后停止	已熔断	✅ 生效
返回空表格	6 次全部调用	未熔断	❌ 不生效
返回空值（None）	6 次全部调用	未熔断	❌ 不生效

只有「代码抛错」这一种会被记账。返回空表和返回空值这两种，熔断器的计数器一动不动。

第三种最要命，因为它不是理论问题。它自己的兜底源（腾讯直连那一路）在拿不到数据时，走的就是「返回空表」这条路。也就是说：一个真实存在的、专门设计的兜底源，在它最可能失败的方式下，永远不会被熔断。每只票、每一轮，它都会被重新试一遍。如果你盯 20 只票，这就是 20 次白等。

第二处：dry-run 报表把成功报成失败

它有个「只看数据不调模型」的模式，用来验证配置通不通、行情拉不拉得到。我拿茅台跑了一遍，日志里明明白白：

先是一行「数据保存成功，新增 36 条」，隔了几行，汇总又写「成功: 0, 失败: 1」。

我去数据库里对了一遍：数据确实在，36 条，最新一根是 10 月 27 日。而这个模式判断成功与否的标准是「库里有没有今天这根 K 线」——今天是 10 月 28 日，A 股还在盘中或刚收盘，上游本来就不会给你今天这根。

所以这是个判断标准错位：用「有没有今天的数据」去判「今天的取数有没有成功」。收盘前跑、周末跑、节假日跑，只要上游还没出当天 K 线，它都会报失败。

影响不算大——数据其实进库了，核心分析跑起来是对的。但如果你拿它做自动化巡检，或者按这个退出码判断「今天要不要重试」，你会被它反复骗。

第三处：数据库单例不认第二个路径

这个更偏内部。它有个全局唯一的数据库管理器，设计意图是「整个进程共用一个实例」。问题是它的初始化函数在实例已经存在时会直接返回，把这次传进来的新数据库路径丢掉。

我这个探针很直白：先让它连第一个临时库，再让它连第二个临时库，然后检查它到底连的是哪个。结果：两个是同一个对象，第二个路径被忽略了，第二个库文件压根没被创建。

后果落在测试和插件上：先有的测试把单例连到自己的临时目录，临时目录一清理，后面的测试再拿到这个实例，连接池重连时会在一个空路径上新建一个空库，表全没有，报「表不存在」。这类错误最难查，因为它跟被测代码无关，只跟「谁先跑」有关。

这件事我不算独家——它当前有 43 条未关闭的 issue 与 PR，其中已经有人提了同一条（编号 2436），还写清了根因和两种修法。我把它写进来，是因为我独立复现了，不是抄结论。

四、它站在什么位置

和站内评过的几个项目放一起看，坐标系会更清楚。

DeerFlow 是字节的 Agent 编排框架（Agent 也就是会自己调用工具的大模型程序），主打通用工作流，23 个自带技能；ECC 是「Agent 操作系统」那一挂，管规则和权限；context-mode 解决的是上下文被工具输出吃光的问题。这三个都是给开发者做二次开发的骨架。

daily_stock_analysis 不是骨架，是成品。它假定你不想写代码，只想填几个密钥、每天收一份报告。这也解释了那个 0.83 的 Fork 比——它天然是要被「抱走自己跑」的。

适合谁：手上有一批自选股、每天要花半小时盯行情和新闻、希望这件事被自动化掉的人；想验证「大模型能不能稳定产出可执行交易判断」这件事的开发者；以及想学一套完整的多源兜底 + 结构化输出 + 推送链路的工程师——它的兜底层组织方式值得抄。

不适合谁：想要一个能直接下单的系统（它只给判断不给交易，且反复声明不构成投资建议）；完全不想碰 API 密钥的人（免费源限流严重，稳定跑要配 token 型数据源，token 就是按量计费的调用凭证）；以及期待「装了就能赚钱」的人——它的价值是把信息整理到你能做决定的密度，不是替你做决定。

几个必须说清的局限：全量 8346 项测试我没跑完，只抽了 1164 项；AI 判断质量本身我没评——判它对不对需要几百个交易日的对账数据，一天跑不完；真实推送我只验了「不推送」这条路径，没有往真实群发过消息。

五、结论

值得 Fork，但别当成「装完就忘」的基础设施。

它的底子在同价位里是厚的那一档：6.7 万星里 5.5 万是 Fork，说明真有大批人在天天用它；多源兜底不是 PPT，我亲眼看它从断掉的首选源切到下一个源拿到数据；1164 项核心测试全绿，说明主要链路有护栏。

但那三处需要你自己盯着：兜底源在它最可能的失败方式下不会被熔断，盯的票越多白等越多；只看数据的模式会把成功报成失败，别拿它的退出码做自动化判断；数据库单例只认第一个路径，如果你要在它上面写插件或跑并发测试（也就是多个任务同时进行），自己加一道重置。

前两处都是「记录口径」的问题，不是架构问题，改起来不复杂。但记录口径错了，所有基于它的自动决策就都建立在一个偏了的读数上。

评测环境：单核 Linux、2G 内存、隔离沙箱、Python 3.13，仓库快照 2026-10-28（末次提交 10-25）。文中数字均为本机实测；三处判定表来自我按三种失败形态各写的假数据源，任何读者都能照这个办法自己复现。