多源 LLM 基座层
通用与专用大模型即插即用的接入位。它只负责「把模型接进来」，不负责金融口径——同一层里可以同时挂通用模型和领域模型，换模型不用改上层智能体。
FinRobot 架构对照 / AI4Finance-Foundation
FinRobot 架构：论文里的四层设计，和现在真正在跑的结构
官方 README 保留着论文期的四层分层与「感知—大脑—行动」闭环，但当前仓库真正在跑的是另一套具体结构：Tauri/React 桌面壳 → FastAPI → PydanticAI 智能体 → 7 条类型化流水线 → 32 个纯 Python 算子 → 7 个数据提供方 → SQLite 制品库。本页把两套东西并排摆出来，标清哪些是论文概念、哪些在代码里有对应实现，避免照着一张抽象图去猜现实。
论文四层智能体 / 算法 / LLMOps / 基座
感知—大脑—行动论文期 agent 闭环
V2 实际结构流水线 + 算子 + 数据层
对应关系逐条标注有无实现
论文概念四层 / CoT / Scheduler
V2 实际7 流水线 · 32 算子 · 7 数据源
结构事实9 个 Agent（8 个 .md 指令）
核验基准commit 2717499（2026-09-28）
论文期分层
论文里的四层，各自解决什么问题？
先明确这一节的性质：这四层是 论文期（V0 / 白皮书）的抽象分层，官方 README 至今保留这段介绍，但它不是当前仓库的运行结构——V2 实际跑的是下一节要讲的另一套组件。本站把它放在最前面，是因为中文资料大多从这里讲起，你需要知道它的定位。下面按自下而上的顺序拆开。
金融 LLM 算法层
放的是针对金融领域与全球市场分析做过配置的模型。它的价值在于模型侧的领域适配，而不是任务编排；把它当成「可选的能力增强」更贴近实际。
LLMOps 与 DataOps 层
按 README 的论文期描述，多源整合与模型调度属于这一层，Smart Scheduler 也在这一层。需要提醒的是：仓库文件树里找不到任何对应的调度器模块（详见后文 Smart Scheduler 一节），所以这一层目前只能当设计语言读。
金融 AI 智能体层
面向使用者的那一层：市场预测、文档分析、交易策略等智能体，配合金融链式推理（Financial CoT）把任务拆成步骤。用户实际提出的需求基本都落在这一层。
怎么用这张分层图：当下层提供能力、上层决定任务怎么被拆解与执行，所以「某个功能能不能做」往往不取决于某一层有没有模型，而取决于这一层的输入数据与前置条件是否齐备——这个判断方式今天依然成立。
但要注意它不能当部署说明用：V2 里没有「LLMOps 层」这个目录，算法层与调度角色被 pydantic 化的流水线和纯 Python 算子取代了。两套东西的逐条对应关系见本页「论文概念 ↔ 当前代码」表。
但要注意它不能当部署说明用：V2 里没有「LLMOps 层」这个目录，算法层与调度角色被 pydantic 化的流水线和纯 Python 算子取代了。两套东西的逐条对应关系见本页「论文概念 ↔ 当前代码」表。
V2 实际结构
FinRobot 生产版真正在跑的结构是什么？
与上面的论文分层不同，这一套是可清点、可核对的：每一层都能在仓库里数出确定的文件数量。下表按「结构层 → 具体组件 → 仓库位置 → 可清点的数量」列出，数量全部来自本站按固定 commit 2717499（2026-09-28）的仓库文件树逐项计数。
| 结构层 | 具体组件 | 仓库位置 | 可清点的数量 | 注意点 |
|---|---|---|---|---|
| 桌面壳 | Tauri（Rust）系统窗口 + React 19 界面 | finrobot_desktop/desktop/（src/ 与 src-tauri/） | 前端源码 252 个 .ts/.tsx | 桌面壳与后端通过本机 HTTP 通信，不是进程内调用 |
| 后端服务 | FastAPI 路由与本机 HTTP 服务 | finrobot_desktop/finrobot/server.py、routes/ | 监听 127.0.0.1:8321 | 桌面 App 会自动拉起后端；浏览器模式由 dev.sh 启动 |
| 智能体层 | Lead 编排 + 5 个流水线角色 + 3 个辩论角色 | finrobot/engine/agents/ | 9 个 Agent（其中 8 个行为写在 markdown 指令文件里） | 改 Agent 行为改 .md 即可，不必动 Python |
| 编排层 | 7 条类型化流水线，每步带校验与重试 | finrobot/engine/pipelines/ | 7 条流程 + 9 个基础设施文件 | 与论文期的开放式多轮对话不同，这里是「步骤 + 校验」结构 |
| 计算层 | 26 个估值算子 + 6 个审计算子 | finrobot/engine/compute/operators/（审计在 operators/audit/） | 32 个纯 Python 算子 | 模型不参与计算，这是数字可复现的前提 |
| 协调层 | 7 个 coordinator，负责把数据层的输出组装成算子入参 | finrobot/engine/compute/coordinators/ | 7 个 | 数据口径（币种、期间、单位）在这一层对齐 |
| 数据层 | 7 个 provider，共用接口、带健康状态与自动故障切换 | finrobot/engine/data/providers/ | 7 个来源（yfinance / SEC EDGAR / FMP / Finnhub / Adanos / 新闻聚合 / FX） | 缺数据时对应方法行会被降级隐藏并留下警告 |
| 制品层 | 报告存储、输出契约、语义 diff | finrobot/artifact/（SQLite） | 单次研报为 13 章制品 | 制品可做语义 diff，用来比较两次运行的差异 |
两套描述怎么并存：论文分层讲「意图与分工」，V2 结构讲「哪些文件、多少数量」。它们不冲突，但用途不同——想理解设计时读前者，想确认某个能力是否存在时必须读后者。本站每一页的「官方资料没有」的部分，基本都来自后者。
论文概念对照
FinRobot README 里的论文期概念，在代码里各对应什么？
这是本页最实用的一张表：左边是官方 README 与论文里会读到的概念，右边是它在当前仓库里的真实状态与位置。凡是标「无对应实现」的，都不要按它去找模块——这一点是中文教程最容易误导人的地方。
| 论文 / README 里的概念 | 当前仓库里的状态 | 对应位置或核对方式 | 使用建议 |
|---|---|---|---|
| 四层架构（智能体层 / 金融 LLM 算法层 / LLMOps 与 DataOps / 多源 LLM 基座） | 论文期抽象分层，README 保留；V2 实际按「桌面壳 → 服务 → 智能体 → 流水线 → 算子 → 数据 → 制品」组织 | 对照 README「Research foundation」段与 finrobot_desktop/finrobot/ 目录结构 | 当分类语言用，不当部署说明用 |
| 感知 — 大脑 — 行动闭环 | 论文期概念；V2 把同一条思路落成固定角色序列 | V2：engine/pipelines/ 里的 data → analysis → modeling → synthesis → report；辩论环节见 agents/instructions/ 下的 bull / bear / judge 指令文件 | 理解意图时用它，落地时看流水线 |
| Smart Scheduler（Director Agent / Agent Registration / Agent Adaptor / Task Manager） | 无对应实现：文件树里没有任何路径包含 scheduler / director / adaptor | 在固定 commit 的文件树里搜这三个词，命中为 0 | 读它的设计意图可以，按它找模块不行 |
| Financial CoT（金融链式推理提示脚手架） | 仍存在于 V0 代码里 | finrobot_autogen/finrobot/agents/prompts.py | 读 V0 代码时可见；它不是 V2 的机制 |
| 多智能体协作 | 两代实现方式不同：V0 用会话拓扑，V2 用类型化流水线加 3 个辩论角色 | V0：finrobot_autogen/finrobot/agents/workflow.py（5 种拓扑）；V2：engine/pipelines/ 与 Lead 编排 | 概念相通，接口完全不同，别混用命令 |
| 「数字由代码算」这一原则 | 是 README 当前的核心表述，V2 里有 32 个算子支撑（26 估值 + 6 审计） | README 的四段式原则 + engine/compute/operators/ | 引用任何数字前按这条原则核对来源 |
| FinRobot Pro / 官方托管版 | 官方另有商业产品（README 的 FinRobot Pro 段）与 V2 的托管入口 | README 对应段落与官方站点 | 功能、条款与价格均以官方为准，本站未核验 |
| 论文本身（arXiv 2405.14767 与 ICAIF 2024 两篇） | 描述的是 V0 时代的架构与实验 | 引用信息在 README 底部 | 读论文时对应 V0，不要套到 V2 的接口上 |
这张表是本站的对照整理，不是官方口径。但每一条都能用固定 commit
2717499 的仓库核对：左边是你能在 README 里读到的词，右边是你在文件树里能数到的东西。两者不一致时以文件树为准——这是本站全站采用的判据。任务路径（V0 口径）
同样一件事，FinRobot V0 要动哪些组件？
这一节仍按论文期的分层与 V0 代码来写，因为中文教程里的任务路径基本都出自那一代。V2 的对应流程（类型化流水线 + 算子）见上一节与智能体页。表里每行都补了「前置条件」和「常见卡点」，这两列是官方资料里没有的整理。
| 想做的事 | 主要命中的层 | 会用到的组件 | 前置条件 | 常见卡点 / 注意点 |
|---|---|---|---|---|
| 生成一份公司分析报告 | 智能体层 + 算法层 | 文档分析类智能体 + workflow 编排 | 财报类数据源的 key（如 FMP / SEC EDGAR） | 缺 key 时数据拉不到，报告只剩框架；申请与权限以数据源官方为准 |
| 做一次市场预测 | 智能体层 + 基座层 | 预测类智能体 + 所接入的 LLM | LLM API key | 模型对「刚刚发生的事」不敏感，最新信息要靠自己喂进数据链路 |
| 用 DCF / DDM / LBO 做估值 | 算法层 + 功能性组件 | 定量计算相关算子（functional 下） | 可用的财务报表数据 | 把模型叙述当成计算结果是最常见的误解，估值数字来自算子而非模型输出 |
| 画 K 线与技术指标图 | 功能性组件 | 绘图相关组件（functional 下） | 行情数据源可达 | 数据缺失时图会是空的或不全，但这不一定会报错，需自己核对数据条数 |
| 把多个研究步骤串成流程 | V0：workflow 编排；V2：类型化流水线 | V0 用 agents/workflow.py 的会话拓扑（单助手 / RAG / 多助手 / 带 Leader 的多助手）；V2 用 7 条流水线 + 注册表 | V0 需要至少两个可用角色才有协作意义；V2 单条流水线即可跑 | 论文期的 Smart Scheduler 在仓库里没有实现，不要照它去找模块 |
| 接入一个新的数据源 | DataOps 层 | data_source 目录下对应的 utils 模块 | 该数据源的 key 与访问权限 | 限流或权限不足通常表现为空结果而不是报错，排查顺序见数据源页 |
| 跑通官方示例 | V0：notebook；V2：CLI 或浏览器 | V0 在 finrobot_autogen/tutorials_beginner/ 与 tutorials_advanced/；V2 是 uv sync 后的 finrobot research 或 ./dev.sh | V0 需 conda 环境 + 相关 API key；V2 需 uv 与一个 LLM key | 少配一个 key 往往在流程中段才失败；两代的命令不要混在一个环境里用 |
读表方式：「主要命中的层」是从任务视角归的类，实际执行时几层都会参与；这张表的作用是让你在缺条件时能快速定位该补哪一环，而不是按层逐步搭建。
如果你用的是 V2，最后一列「常见卡点」基本不适用——V2 把前置条件收敛成了两个：装好
如果你用的是 V2，最后一列「常见卡点」基本不适用——V2 把前置条件收敛成了两个：装好
uv、配好一个 LLM key。Agent 工作流（论文期）
「感知 → 大脑 → 行动」在当前代码里找不到，那现在怎么走？
这条闭环出自论文期：四层是平台结构，闭环是一次任务的过程。它描述的是 V0 智能体的行为方式；当前生产版 V2 把同一条思路落成了固定的角色序列——data → analysis → modeling → synthesis → report，再加一轮 bull / bear / judge 辩论。下面先按论文期三步走，每步后面标出 V0 代码位置与 V2 的对应物。
感知 Perception：把数据变成结构化输入
捕获并解析多模态金融数据（行情、新闻、经济指标），交给后续推理。V0 对应
finrobot_autogen/finrobot/data_source/下的各数据源 utils 模块；V2 的对应物是 7 个 provider 加上数据校验与归一化。# 代码结构来自官方仓库（master 分支） finrobot/data_source/ fmp_utils.py # 财报与基本面 finnhub_utils.py # 行情与新闻 sec_utils.py # SEC EDGAR 公告 yfinance_utils.py # 公开行情（通常无需 key） finnlp_utils.py # 文本/情绪类数据
预期输出：拿到结构化的 DataFrame / 文本对象，能直接进入下一环节；若返回空，先查对应数据源的 key 与权限，而不是先怀疑模型。
大脑 Brain：用 LLM + 金融链式推理生成指令
把感知结果交给 LLM，通过 Financial CoT 拆出下一步该做什么。V0 对应
finrobot_autogen/finrobot/agents/下的智能体库与 workflow 编排；V2 的对应物是流水线里的 analysis / modeling 步骤，每一步都有校验与重试，而不是自由对话。finrobot/agents/ agent_library.py # 智能体库：有哪些智能体可用 workflow.py # 工作流编排：任务按什么顺序串起来
预期输出：一段结构化的下一步指令（调用哪个工具、传什么参数），而不是最终结论。这一步输出错，问题通常在提示编排与输入数据，不在模型规模。
行动 Action：调用工具真正执行
按指令调用工具完成计算、绘图、报告生成等动作。V0 对应
finrobot_autogen/finrobot/functional/下的分析、绘图、报告组件；V2 的对应物是 26 个估值算子与 6 个审计算子——数值在这一步由纯 Python 代码产生，而不是由模型写出来。finrobot/functional/ analyzer.py # 分析 charting.py # 绘图 quantitative.py # 定量计算 reportlab.py # 报告生成 text.py # 文本处理
预期输出：可打开查看的结果（报告文件、图表、计算表）。数值类结论应能在计算表里逐项对上，对不上就是这一环节的输入有问题。
闭环要点与两代差异：三步顺序依赖——感知拿不到数据，大脑只能空转；编排不合理，行动就会调用错工具。排查顺序仍按「数据 → 编排 → 工具」走，比换模型有效。
差别在于可控性：V0 的中间步骤是模型自由生成的，出错时只能读对话记录；V2 的每一步是声明式步骤，输出有类型约束，出错时能定位到具体步骤与校验规则。这也是本站建议「要可追溯结果就用 V2」的原因之一。
差别在于可控性：V0 的中间步骤是模型自由生成的，出错时只能读对话记录；V2 的每一步是声明式步骤，输出有类型约束，出错时能定位到具体步骤与校验规则。这也是本站建议「要可追溯结果就用 V2」的原因之一。
数字是谁算的
FinRobot 里哪些数字是代码算的、哪些只是 LLM 写的？
这是判断一套金融 AI 输出能不能引用的分界线。官方把当前原则写成一句话：模型负责推理，软件负责计算，智能体负责编排，系统负责验证。落到可核对的数量上：V2 有 26 个估值算子 + 6 个审计算子，全部是纯 Python，模型不参与数值计算。
| 你可能会以为 | 实际发生的情况 | 怎么验证 | 注意点 |
|---|---|---|---|
| 估值数字是模型「想」出来的 | V2 里估值结果由 engine/compute/operators/ 下的纯 Python 算子计算，模型不参与数值本身 | 取出对应算子文件，用一组输入手算或复算一遍；本站已实测 DCF / 敏感性 / 蒙特卡洛三个入口 | 模型负责的是叙述与编排，不是数值；V0 没有这层保证 |
| 输出里出现的数字都可靠 | 叙述文字的措辞由模型生成，口径可能在表述中转述走样 | 关键数值回到报告的计算表逐项核对 | 引用前自己复核一遍，别直接抄叙述 |
| 换个模型估值就会变 | 走确定性算子的部分不应因模型变化而改变 | 换一个模型重跑同一组输入，对比计算表 | 若结果确实变了，先查输入数据是否不同，而不是先怀疑算子 |
| 数据错了模型会帮你纠正 | 算子的输入来自数据源，输入错则结果必然错 | 核对输入财务数据的来源、期间与单位 | 数据质量决定了结论质量，模型不兜底 |
| 报告里的表格是模型排版 | 排版输出由报告类组件完成 | 打开生成的报告文件，检查数值与表格是否完整 | 版式问题与数据问题是两类问题，别混着排查 |
| 加大模型或调参能提升准确率 | 准确率主要由输入数据与算子口径决定 | 先固定数据与口径做对照，再看模型侧影响 | 用模型参数掩盖数据问题，通常只换来更流畅的错误叙述 |
边界说明：「26 个估值算子 + 6 个审计算子」是本站按固定 commit 逐文件清点的结果，与官方 README 的说法一致；具体实现与覆盖范围仍以官方仓库为准。但这条原则只属于 V2：官方对 V0 的说明是「没有确定性计算层，没有溯源跟踪，也不保证输出里的数字是算出来的」。实测输出与四道拒绝计算的闸门见失败案例页。
Smart Scheduler（论文期）
FinRobot 的 Smart Scheduler 现在能用吗？
它解决的是「一个任务该交给谁做」，属于 README 里 LLMOps 与 DataOps 层的位置。但先看清楚一件事：在固定 commit 的仓库文件树里，没有任何路径包含 scheduler、director 或 adaptor——这套调度器没有以模块形式落地。下面先按 README 介绍它的四组件设计，再说清当前该用什么替代。
Director Agent
任务分配的编排者：按性能指标与适配度把任务派给合适的智能体。它是调度的入口，不负责具体执行。
Agent Registration
管理智能体的注册与可用性。没注册进来的智能体不会参与分配，所以「装了但没被用到」通常先查这一步。
Agent Adaptor
针对具体任务定制智能体能力。它影响的是「同一个智能体能不能更好地贴合当前任务」，属于效果层而不是可用层。
Task Manager
管理不同通用 / 微调 LLM 智能体，并周期性更新以保持有效。多模型场景下，它决定了可选池子有多大。
| 常见误解 | 实际情况 | 怎么确认 |
|---|---|---|
| Smart Scheduler 是一个可以直接调用的模块 | 它是 README 论文期描述里的调度机制；仓库文件树里搜不到对应实现 | 在固定 commit 的文件树里搜 scheduler / director / adaptor 三个词，命中数为 0 |
| 它会把所有智能体自动写出来 | 它做注册、适配与任务分配，智能体本身来自智能体库 | 看 agents 目录与注册环节各自负责什么 |
| 只配一个模型也能体会到调度 | 模型多样性是这套机制的前提 | 只配一个模型时观察任务是否直接落到同一个执行者 |
| 经过调度结果就一定更准 | 调度决定「用哪个」，不保证结论正确 | 结论正确性回到数据与算子两条线上验证 |
| 装完就能直接用 | 没有可调用的模块：V2 用类型化流水线加流程注册表来「选流程」，V0 用会话拓扑来「选协作方式」 | 看 engine/pipelines/registry.py（V2）与 agents/workflow.py（V0）分别负责什么 |
| 结果不对就是模型不行 | 也可能是注册缺失或适配不匹配 | 按 Director → 注册 → 适配 → 任务管理的顺序排查 |
那这段设计还有价值吗？有，但价值在「设计语言」而不是「可用模块」：任务与执行者的匹配、能力注册、按任务适配、模型池维护这四个问题在任何 Agent 系统里都存在。你可以用这四个问题去审视 V2——它的答案分别是：流水线注册表、8 个 markdown 指令文件、每个角色的指令约束、以及 7 个数据 provider 的健康状态与故障切换。
但不要按它去找代码。本站所有关于架构的判断都以固定 commit 的文件树为准，不以 README 的描述性段落为准。
但不要按它去找代码。本站所有关于架构的判断都以固定 commit 的文件树为准，不以 README 的描述性段落为准。
代码地图（V0）
V0 的代码放在哪、先看哪个？
这一组入口属于教学版 V0（finrobot_autogen/）。想读懂「金融智能体怎么接起来」，从这里入手最省力；但要记住这一代没有确定性计算层，它的输出不适合直接当研究结论用。
finrobot/agents
智能体库与工作流编排。想知道「有哪些智能体、任务怎么串」从这里开始；文件名以官方仓库为准。
finrobot/data_source
各家数据源的接入层：FMP、FinnHub、SEC EDGAR、yfinance、finnlp 各一个 utils 模块。取数失败先看这里。
finrobot/functional
分析与输出类功能组件：分析、绘图、编码、定量计算、报告生成、文本处理。数值与图表都出自这一层。
tutorials_beginner
入门示例 notebook，适合先跑通一条完整链路再回头读代码。跑之前先把 key 与环境准备好。
tutorials_advanced
进阶示例，涉及更长的流程与更多组件协作。建议在入门示例跑通、且熟悉 data_source 之后再动。
配置与密钥位置
API key 集中放在配置处供各数据源读取。具体文件名与字段以官方 README 为准——放错位置的表现是「代码没问题但取不到数」。
V2 · engine/agents
9 个 Agent 的定义与行为约束：8 个 markdown 指令文件加 Lead 编排代码。想改 Agent 的表达方式，改这里的 .md 就够。
V2 · engine/pipelines
7 条类型化流水线（equity_research / dcf / ddm / lbo / comps / earnings_analysis / ic_memo），另有 base、registry、runner、step、validators 等基础设施文件。
V2 · engine/compute
数字真正产生的地方：operators/ 26 个估值算子、operators/audit/ 6 个审计算子、coordinators/ 7 个入参组装器。全部纯 Python。
V2 · engine/data
7 个 provider 与归一化、校验逻辑。取数失败或口径不一致时，排查起点在这里，而不是在算子或提示词里。
V2 · artifact 与 audit
研报制品的存储（SQLite）、输出契约与语义 diff；审计结果另有持久化模块。要看「两次运行差在哪」，用这一层。
V2 · desktop/
Tauri（Rust）桌面壳与 React 19 前端，以及把后端冻结成 sidecar 的构建脚本。只关心研究与计算时，可以完全不读这一层。
读代码的建议顺序：先跑
如果是冲着 V2 的确定性计算来的，别从 agents 读起——直接从
finrobot_autogen/tutorials_beginner/ 里的一个 notebook 看整体流程，再按 functional → data_source → agents 的顺序读回去，这是 V0 的路径。如果是冲着 V2 的确定性计算来的，别从 agents 读起——直接从
engine/compute/operators/dcf.py 这种单文件入手更快：它是纯函数，输入是声明式的参数对象，不依赖模型与网络，可以独立跑起来（本站就是这么实测的）。自助核验
怎么自己核对 FinRobot 这套结构？
本页所有数量都能用固定 commit 的仓库文件树核对，不需要安装、不需要联网跑任务，只要会看目录。下表给出「待核对的说法 → 怎么看 → 通过判据」，你可以逐条验一遍。
| 待核对的说法 | 怎么看 | 通过判据 |
|---|---|---|
| 有 26 个估值算子 | 数 finrobot/engine/compute/operators/ 下非 __init__.py 的 .py 文件 | 得到 26 |
| 有 6 个审计算子 | 数 operators/audit/ 下非 __init__.py 的文件 | 得到 6（币种口径、EV 桥、叙述分歧、叙述数字绑定性、行业符号、TTM 期间） |
| 有 7 个 coordinator | 数 compute/coordinators/ 下非 __init__.py 的文件 | 得到 7 |
| 有 7 条流水线 | 看 engine/pipelines/：区分流程文件与基础设施文件 | 流程 7 条；base/registry/runner/step/validators/protocols/result/_helpers/_thesis_prompt 属基础设施 |
| 有 9 个 Agent | 数 engine/agents/instructions/ 下的 markdown 文件，再找 Lead | markdown 8 个；Lead 定义在 agents/factory.py 与 engine/orchestrator.py |
| 有 7 个数据源 | 数 engine/data/providers/ 下的 .py | 得到 7（yfinance / edgar / fmp / finnhub / adanos / news_aggregator / fx） |
| 有 56 个分析师 playbook | 数 finrobot_desktop/skills/ 下的 SKILL.md | 得到 56，且分 7 类（11/10/9/9/8/6/3） |
| 有 13 章研报制品 | 看官方 README 对 equity_research 流水线输出的章节列举 | Cover、Investment Thesis、Company Overview、Financial Analysis、Valuation、Recent News、Sensitivity、Catalysts、Technical & Advanced、Competitive Landscape、Financial Data、Ownership & Governance、Disclaimer |
| Smart Scheduler 没有实现 | 在文件树里搜 scheduler、director、adaptor | 路径命中数为 0 |
| PyPI 上装到的是 V0 且零依赖 | 看包元数据有没有 Requires-Dist，再看 sdist 里有没有 requirements.txt | 两者都没有；安装后 site-packages 里只有 finrobot 本体 |
本站的核验基准：固定 commit
2717499（2026-09-28，默认分支 master），采集日期 2026-09-30。你在别的日期克隆仓库时数量可能有变化——数量会漂移，判断方法不会：先数文件，再看官方怎么说，两者不一致时以仓库为准。这条纪律适用于任何「项目介绍类」内容，包括本站。适用判断
什么时候值得用 FinRobot，什么时候不必上？
分层与算子本身都不产生结果，它们带来的好处是「可替换」与「可追溯」：换模型、换数据源、换执行工具时不用重写上层，数字能回到具体计算。是否看重这两点，决定了要不要自建。
适合：要换模型的地方
当你不确定最终用哪个 LLM、或者要按任务选不同模型时，基座层与调度机制的价值才显现。这时自建的复杂度是换来的灵活性。
适合：多步骤研究流程
取数 → 分析 → 计算 → 出报告的链路越长，越需要编排而不是一段脚本堆到底。四层的分工在这类任务上更省事。
适合：需要可复现
确定性算子 + 固定数据源，让同一组输入能复现同一组数值。对要留痕的研究流程，这比「一次性问出一个结论」更有用。
不必上：只做一次行情/指标查询
如果目标只是拿一个价格、算一个指标，四层结构带来的准备工作远大于收益，直接用更轻的工具更快。
不必上：没有多模型需求
只用一个模型时，调度与多源整合基本闲置，此时自建的维护成本主要来自环境与密钥管理，而不是这套架构。
不必上：数据源不在覆盖范围
官方数据源以美股与英文公告为主。若主要分析 A 股，需要自行适配数据源，分层结构帮不上这一层的工作。
集成边界：FinRobot 与 EasyClaw 无已证实集成。两者是两条独立路线：一条是 conda + Python + 多个 API key 的自建智能体平台，另一条是免部署、直接用一句话发起金融研究的本机技能路线。选择时应按自己的环境与数据需求判断，而不是认为二者可以互相替代。
FAQ
FinRobot 架构常见问题
FinRobot 是「训练模型」还是「用模型」？
更偏「用模型」：底层即插即用接入通用与专用 LLM，上层用智能体编排任务，核心是把模型组织成可执行的金融工作流，而不是自己训练一个大模型。具体到某一层是否包含领域调优模型，以官方 README 为准。
感知 / 大脑 / 行动分别对应什么？
感知 = 数据采集与结构化，对应 data_source 下的数据源接入；大脑 = LLM 配合金融链式推理生成结构化指令；行动 = 调用工具执行计算、绘图与报告输出。三者是顺序依赖，前一环没有输出，后一环无法验证对错。
Smart Scheduler 有什么用？
它做「模型与智能体的调度」：按性能指标与适配度决定任务交给谁执行，是 LLMOps 层的核心机制。它提升的是可选方案的匹配度，不直接保证结论正确；需要多模型才有意义。四个组件的职责参见本页对照表，实现细节以官方 README 为准。
FinRobot 需要哪些运行条件？
官方安装说明给出的是 Python 3.10 + conda 环境，另需 LLM 的 API key 以及所使用数据源的 key（如 FinnHub、FMP、SEC）。yfinance 走公开接口通常不需要 key，但稳定性与限流不受项目控制。完整清单以官方 README 为准。
估值数字是模型算的还是算子算的？
按官方 README 的说法，DCF、DDM、LBO、WACC、可比公司与蒙特卡洛等由纯 Python 算子计算，LLM 负责组织与叙述。因此引用数值时应回到计算表核对输入数据与口径，而不是采信叙述文字里的转述。覆盖范围以官方实现为准。
这套分层能不能直接迁移到 A 股研究？
分层结构本身与市场无关，可以沿用；真正的障碍在数据源层——V2 的 7 个 provider 里没有 A 股数据源，A 股需要自行适配取数环节，并自行承担字段口径与复权处理的差异。补一条实测边界：代码层的股票代码校验接受 600519.SS、0700.HK、123456.SZ 这类写法，但校验通过不等于数据可取，两者要分开判断。
README 里的 Smart Scheduler 现在能用吗？
不能直接用。README 的「Research foundation」段保留了这套调度器的设计介绍（Director Agent / Agent Registration / Agent Adaptor / Task Manager），但固定 commit 的仓库文件树里没有任何路径包含 scheduler、director 或 adaptor。当前替代方案是两套：V2 用类型化流水线加流程注册表选流程，V0 用会话拓扑选协作方式。把它当设计语言读没问题，按它找代码会白费时间。
论文概念和仓库实现不一致，是文档没更新吗？
更准确的说法是：README 同时承担了「论文期设计说明」与「当前代码说明」两个角色，两段内容描述的并不是同一个时间点。判断方法很简单——凡是描述性的设计段落（分层、闭环、调度器），先当成论文期口径；凡是给出目录名与命令的段落（uv sync、finrobot_desktop/、finrobot_autogen/），才是当前实现。本页的对照表就是按这个标准整理的，每条都能在仓库里核对。