多源 LLM 基座层
通用与专用大模型即插即用的接入位。它只负责「把模型接进来」，不负责金融口径——同一层里可以同时挂通用模型和领域模型，换模型不用改上层智能体。
FinRobot 四层架构 / AI4Finance-Foundation
FinRobot 架构详解：四层 AI Agent 平台与智能体工作流
FinRobot 把金融 AI 处理与应用拆成四层，并让智能体按「感知→大脑→行动」闭环运行。看这套分层真正要回答两个问题：任务落在哪一层、以及自建时要准备哪些组件才能让这一层转起来。
金融 AI 智能体层预测 / 文档 / 策略智能体
金融 LLM 算法层领域调优模型
LLMOps & DataOps多源模型调度
多源 LLM 基座通用/专用模型即插即用
四层架构智能体 / 算法 / LLMOps / 基座
工作流感知 → 大脑 → 行动
调度Director / Adaptor / Task Manager
依据README 文件结构（2026-09）
四层架构
四个层各自解决什么问题
官方的分层只有名字，实际用起来要先知道每一层「负责什么、拿不到什么」。下面按自下而上的顺序拆开讲。
金融 LLM 算法层
放的是针对金融领域与全球市场分析做过配置的模型。它的价值在于模型侧的领域适配，而不是任务编排；把它当成「可选的能力增强」更贴近实际。
LLMOps 与 DataOps 层
多源整合与模型调度的位置，Smart Scheduler 就在这里。它决定一个任务该交给哪个模型或哪个智能体，是「多智能体协作」能不能成立的关键一层。
金融 AI 智能体层
面向使用者的那一层：市场预测、文档分析、交易策略等智能体，配合金融链式推理（Financial CoT）把任务拆成步骤。用户实际提出的需求基本都落在这一层。
别把四层当成普通的技术栈：下层提供能力，上层决定任务怎么被拆解与执行。所以「某个功能能不能做」往往不取决于某一层有没有模型，而取决于这一层的输入数据与前置条件是否齐备。
任务路径
一个任务在四层里怎么走完
把静态的分层图换成可执行路径：每类常见任务主要命中哪几层、用到什么组件、前置条件是什么、以及卡住时通常卡在哪。这张表是官方 README 没有的整理。
| 想做的事 | 主要命中的层 | 会用到的组件 | 前置条件 | 常见卡点 / 注意点 |
|---|---|---|---|---|
| 生成一份公司分析报告 | 智能体层 + 算法层 | 文档分析类智能体 + workflow 编排 | 财报类数据源的 key（如 FMP / SEC EDGAR） | 缺 key 时数据拉不到，报告只剩框架；申请与权限以数据源官方为准 |
| 做一次市场预测 | 智能体层 + 基座层 | 预测类智能体 + 所接入的 LLM | LLM API key | 模型对「刚刚发生的事」不敏感，最新信息要靠自己喂进数据链路 |
| 用 DCF / DDM / LBO 做估值 | 算法层 + 功能性组件 | 定量计算相关算子（functional 下） | 可用的财务报表数据 | 把模型叙述当成计算结果是最常见的误解，估值数字来自算子而非模型输出 |
| 画 K 线与技术指标图 | 功能性组件 | 绘图相关组件（functional 下） | 行情数据源可达 | 数据缺失时图会是空的或不全，但这不一定会报错，需自己核对数据条数 |
| 把多个研究步骤串成流程 | LLMOps 与 DataOps 层 | Smart Scheduler（Director / Task Manager 等） | 至少两个可用模型才有调度意义 | 只配一个模型时调度会退化成单模型直跑，多智能体协作的优势体现不出来 |
| 接入一个新的数据源 | DataOps 层 | data_source 目录下对应的 utils 模块 | 该数据源的 key 与访问权限 | 限流或权限不足通常表现为空结果而不是报错，排查顺序见数据源页 |
| 跑通官方示例 notebook | 四层 + tutorials | tutorials_beginner / advanced 下的 notebook | conda 环境 + 相关 API key | 少配一个 key 往往在流程中段才失败，先按清单把 key 与权限逐项确认 |
读表方式：「主要命中的层」是从任务视角归的类，实际执行时四层都会参与；这张表的作用是让你在缺条件时能快速定位该补哪一层，而不是按层逐步搭建。
Agent 工作流
感知 → 大脑 → 行动：单个智能体的闭环
四层是「平台结构」，这条闭环是「一个智能体跑一次任务的过程」。每一步都能在代码结构里找到对应位置。
感知 Perception：把数据变成结构化输入
捕获并解析多模态金融数据（行情、新闻、经济指标），交给后续推理。对应
finrobot/data_source/下的各数据源 utils 模块。# 代码结构来自官方仓库（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 拆出下一步该做什么。对应
finrobot/agents/下的智能体库与 workflow 编排。finrobot/agents/ agent_library.py # 智能体库：有哪些智能体可用 workflow.py # 工作流编排：任务按什么顺序串起来
预期输出：一段结构化的下一步指令（调用哪个工具、传什么参数），而不是最终结论。这一步输出错，问题通常在提示编排与输入数据，不在模型规模。
行动 Action：调用工具真正执行
按指令调用工具完成计算、绘图、报告生成等动作。对应
finrobot/functional/下的分析、绘图、报告组件。finrobot/functional/ analyzer.py # 分析 charting.py # 绘图 quantitative.py # 定量计算 reportlab.py # 报告生成 text.py # 文本处理
预期输出：可打开查看的结果（报告文件、图表、计算表）。数值类结论应能在计算表里逐项对上，对不上就是这一环节的输入有问题。
闭环要点：三步是顺序执行但互相依赖——感知拿不到数据，大脑只能空转；大脑编排不合理，行动就会调用错工具。排查时按「数据 → 编排 → 工具」的顺序走，比直接换模型有效。
数字是谁算的
确定性计算 vs LLM 叙述：估值数字从哪来
这是自建金融 AI 时容易被忽略的一条边界：官方说明中提到 DCF、DDM、LBO、WACC、可比公司与蒙特卡洛等由纯 Python 算子计算，LLM 负责组织与叙述。分清这条线，才能判断结果能不能引用。
| 你可能会以为 | 实际发生的情况 | 怎么验证 | 注意点 |
|---|---|---|---|
| 估值数字是模型「想」出来的 | 估值类结果由确定性算子计算，模型不参与数值本身 | 在 functional 下找到对应计算实现，用手算或第三方工具对一组样例复算 | 模型负责的是叙述与编排，不是数值 |
| 输出里出现的数字都可靠 | 叙述文字的措辞由模型生成，口径可能在表述中转述走样 | 关键数值回到报告的计算表逐项核对 | 引用前自己复核一遍，别直接抄叙述 |
| 换个模型估值就会变 | 走确定性算子的部分不应因模型变化而改变 | 换一个模型重跑同一组输入，对比计算表 | 若结果确实变了，先查输入数据是否不同，而不是先怀疑算子 |
| 数据错了模型会帮你纠正 | 算子的输入来自数据源，输入错则结果必然错 | 核对输入财务数据的来源、期间与单位 | 数据质量决定了结论质量，模型不兜底 |
| 报告里的表格是模型排版 | 排版输出由报告类组件完成 | 打开生成的报告文件，检查数值与表格是否完整 | 版式问题与数据问题是两类问题，别混着排查 |
| 加大模型或调参能提升准确率 | 准确率主要由输入数据与算子口径决定 | 先固定数据与口径做对照，再看模型侧影响 | 用模型参数掩盖数据问题，通常只换来更流畅的错误叙述 |
边界说明：以上对「哪些由算子计算」的表述基于官方 README 中关于 FinRobot Desktop / Pro 的段落；具体实现与覆盖范围以官方仓库与文档为准。
Smart Scheduler
Smart Scheduler 四个组件怎么分工
它解决的是「一个任务该交给谁做」，属于 LLMOps 与 DataOps 层。四个组件的职责来自官方 README。
Director Agent
任务分配的编排者：按性能指标与适配度把任务派给合适的智能体。它是调度的入口，不负责具体执行。
Agent Registration
管理智能体的注册与可用性。没注册进来的智能体不会参与分配，所以「装了但没被用到」通常先查这一步。
Agent Adaptor
针对具体任务定制智能体能力。它影响的是「同一个智能体能不能更好地贴合当前任务」，属于效果层而不是可用层。
Task Manager
管理不同通用 / 微调 LLM 智能体，并周期性更新以保持有效。多模型场景下，它决定了可选池子有多大。
| 常见误解 | 实际情况 | 怎么确认 |
|---|---|---|
| Smart Scheduler 是一个独立模型 | 它是 LLMOps 层里的调度机制，本身不含模型 | 对照 README 中 LLMOps 层与四个组件的职责分工 |
| 它会把所有智能体自动写出来 | 它做注册、适配与任务分配，智能体本身来自智能体库 | 看 agents 目录与注册环节各自负责什么 |
| 只配一个模型也能体会到调度 | 模型多样性是这套机制的前提 | 只配一个模型时观察任务是否直接落到同一个执行者 |
| 经过调度结果就一定更准 | 调度决定「用哪个」，不保证结论正确 | 结论正确性回到数据与算子两条线上验证 |
| 装完就能直接用 | 需要按官方流程完成智能体注册等步骤 | 按官方 notebook 的步骤逐步执行并检查每一步是否有输出 |
| 结果不对就是模型不行 | 也可能是注册缺失或适配不匹配 | 按 Director → 注册 → 适配 → 任务管理的顺序排查 |
代码结构
六个入口：代码放在哪、先看哪个
看懂分层之后，落到仓库里就是几个固定入口。下面按「想干什么 → 去哪个目录」整理，目录与文件名来自官方仓库结构。
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 为准——放错位置的表现是「代码没问题但取不到数」。
读代码的建议顺序：先跑 tutorials_beginner 里的一个 notebook 看整体流程，再按 functional → data_source → agents 的顺序读回去。反过来从 agents 开始读，容易在编排细节里迷路。
适用判断
什么时候这套分层帮得上、什么时候不必上
分层本身不产生结果，它带来的好处是「可替换」：换模型、换数据源、换执行工具时不用重写上层。看不看重这一点，决定了要不要用它。
适合：要换模型的地方
当你不确定最终用哪个 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 股研究？
分层结构本身与市场无关，可以沿用；真正的障碍在数据源层——官方数据源以美股与英文公告为主，A 股需要自行适配取数环节，并自行承担字段口径与复权处理的差异。适配成本与可行性取决于你能拿到什么数据，官方未内置 A 股接口。