FinBayes 战略白皮书
0. 本文档负责什么
本文回答 FinBayes 为什么存在、面向谁、提供什么价值、坚持什么产品边界。它是稳定的战略与产品定性正本，不承担详细架构、代码设计、任务拆分或进度管理。
当前资料分工如下：
| 资料 | 负责内容 |
|---|---|
| 本白皮书 | 稳定战略、产品定义、用户价值与边界 |
| FinBayes Atlas | 目标架构、阶段、模块、任务、负责人、依赖、状态与参考方案 |
| FinBayes 工程仓代码与测试 | 当前实现事实 |
旧架构、旧产品定义、历史决议和阶段过程文档只用于解释历史，不再定义当前 FinBayes。
1. 为什么做 FinBayes
从金融领域的全局视角看，金融信息与行为可概括为：
三个环节可以协同，但在产品与商业模式上能够各自独立成立：
- Data Horizon 面向金融信息的感知：收集、整理和输出标准化与非标准化金融信息。
- FinBayes 面向金融信息的认知：帮助用户理解信息、问题、对象、关系、影响与可能性。
- AI Trading Matrix 等系统可承接决策与行动；实际交易执行不属于 FinBayes 的默认能力边界。
FinBayes 不是 Data Horizon 的界面，也不依赖 Data Horizon 才能成立。两者是独立产品，可通过 FinTec AI Ecosystem 获得协同。
2. 当前产品定义
FinBayes 是一个独立成立、面向广泛金融用户与开放金融场景的金融原生 AI Agent。
它通过统一 Agent 与用户交互，最大化利用持续进化的模型能力，并通过金融原生的上下文、方法、数据、工具、记忆、扩展生态与多端交互，响应用户提出的金融问题和场景。
FinBayes 不以预先枚举的工作流、固定“金融认知分类”、单一标准产物或强制任务清单组织产品。场景示例用于理解能力范围，不是产品本体的分类法，也不是要求每轮都经过的流程。
3. 面向谁
FinBayes 面向金融领域的广泛用户，包括但不限于：
- 刚开始理解金融市场的普通用户；
- 个人投资者、交易者与长期资产持有者；
- 分析师、研究员、投顾与资产管理从业者；
- 量化研究、数据分析与软件开发人员；
- 企业、机构、学术与专业研究用户。
FinBayes 不以职业、资产规模、市场经验或技术能力设置产品入口。不同用户会以不同方式使用同一 Agent，并获得不同深度的结果。
4. 开放金融场景
用户可能：
- 用自然语言提出未知的金融问题；
- 上传 K 线图片、财报、研报、新闻或其他资料进行理解和分析；
- 查询历史或实时金融数据；
- 分析宏观、行业、公司、资产、事件和市场之间的影响；
- 长期关注某些市场、板块或标的；
- 结合自身情况讨论资产配置、策略或风险；
- 编写、解释和改进量化策略或金融分析代码；
- 安装并配置第三方 Skills、Tools、MCP 服务、Plugins 或其他扩展；
- 从 CLI、Web、聊天渠道、桌面端或未来其他界面进入同一个 FinBayes。
这些只是当前可见的代表性场景。FinBayes 的架构应允许模型能力、金融数据、工具生态和用户需求持续演进，而不是把今天列出的场景固化为明天的产品边界。
5. 为什么选择 AI Agent 形态
大模型及其工具使用、代码执行、多模态、长上下文和领域能力仍在快速发展。FinBayes 需要一种能够持续吸收这些进步、又不被固定业务流程锁死的产品形态。
可复用的强 Agent 基线是：
- Harness 工程：上下文、工具、权限、事件、会话、扩展和多端运行环境；
- 模型—工具反馈 Loop：模型根据当前上下文决定回答、使用工具、继续推理或结束；
- 可选的协作 Graph：仅在任务确实需要分工、隔离或并行时启用子 Agent，不作为默认必经层。
Harness、Loop 与可选 Graph 可以有不同实现组合，但它们不是一条固定金融业务流程。
“Observe → Verify → Repair → Request Approval → Commit”是某些编码或高风险操作中的工作方式，不是 AI Agent 或金融 AI Agent 的定义、骨架或必要组成。事实验证、对账、审计、复核与审批也只在具体场景和风险需要时启用，不能成为 FinBayes 每轮固定认知阶段。
6. 金融原生差异化
若某个模块不存在金融场景差异，FinBayes 默认采用强 AI Agent 的成熟方案，不单独发明一套金融版本。金融原生能力主要体现在以下位置。
6.1 金融上下文与方法
FinBayes 应理解金融对象、市场、时间、币种、频率、公司行为、数据时点和用户语境。金融方法作为可选择的知识、Skill、工具或上下文能力提供，而不是硬编码成每轮固定步骤。
6.2 金融数据接入
FinBayes 同时支持：
- 产品内置的数据能力；
- 用户通过 CLI 或配置界面接入自己的数据服务；
- MCP、Tools、Skills、Plugins 与 Extensions 提供的外部数据能力；
- 用户上传的文档、图片、表格和其他本地资料。
数据访问需要准确表达来源能力、市场覆盖、时点、权限与可用性，但这不等于把产品建设成数据核验、对账或审计工作台。
6.3 金融工具与扩展生态
数据查询、计算、文档处理、代码执行、可视化和第三方服务都属于统一能力平面。用户可发现、安装、配置、启停和授权扩展；不同界面应操作同一份底层配置与运行时能力，而不是各自维护一套孤立配置。
6.4 多模态与计算
金融理解不限于文本。图表、K 线、财报、研报、表格、代码与计算结果都应能够进入同一 Agent 上下文，并在需要时调用合适工具处理。
7. 产品与技术形态
FinBayes 的目标形态是“一套无界面的核心运行时，多种薄客户端”：
多端不是多个 Agent。界面负责交互和呈现，核心运行时负责模型—工具循环、上下文、能力调用、会话与事件。新增一个界面不应复制 Agent 内核；新增一个数据源或扩展不应修改核心循环。
8. 自主性、记忆与长期运行
FinBayes 在单次运行中应具有足够自主性：能够理解当前请求、选择上下文和能力、调用工具、处理结果并收束回答。
跨时间的记忆、关注、定时运行、监控、通知和长期跟踪是有价值的产品能力，但必须是：
- 由用户明确创建或启用；
- 可见、可编辑、可暂停、可删除；
- 复用同一个 Agent 运行时，而不是形成第二套“认知闭环”；
- 不默认把每次对话、判断或输出沉淀为永久资产；
- 不默认触发复盘、对账、评价或审计。
会话历史、工作上下文、用户记忆、关注项和后台运行是不同作用域，不应合并为一个笼统的“金融认知资产层”。
9. 边界与非目标
当前 FinBayes：
- 不默认执行交易、账户操作、资金划转或无条件买卖自动化；
- 不把“保证正确”“保证盈利”作为产品承诺；
- 不把固定认知流程、结构化判断模板或审计链作为 Agent 本体；
- 不要求每个回答都记录、验证、对账、复盘、评分或形成长期资产；
- 不为了保留旧设计、旧接口或旧流程而维持双轨架构；
- 不把 Data Horizon、RLE、AI Trading Matrix 或未来 FEFM 变成当前产品成立的前置依赖；
- 不因某个参考 Agent 使用特定语言或框架，就要求 FinBayes 全量改写技术栈。
实际交易动作可以由边界清晰的外部系统或未来经明确产品决策的能力承接。
10. 长期方向
FinBayes 将持续吸收通用模型、金融数据、多模态、工具、Skills、MCP、Plugins、Agent 协作和多端交互的进步。
FinTec AI Ecosystem 的自有金融专家大模型是长期方向。它未来可以增强 FinBayes 的领域能力，但目前不作为架构重构、技术选型或阶段计划的前置条件。
11. 如何衡量是否走在正确方向
优先观察：
- 用户能否在更多真实金融场景中得到有用、清晰、适配其上下文的结果；
- Agent 能否可靠使用金融数据、工具、代码、文档和多模态输入；
- 模型升级或新增扩展时，能力能否被低成本吸收；
- CLI、Web、聊天渠道等不同界面是否共享同一核心能力与会话语义；
- 用户是否能理解并控制数据、记忆、扩展和后台运行；
- 架构是否减少重复内核、固定流程和历史兼容负担。
测试、可观测性和必要的风险控制用于证明或保护这些价值，但它们本身不是产品目标，也不能替代真实用户价值。
12. 防止再次漂移
遇到新需求或新模块时，先回答三个问题：
- 它服务哪个真实用户或金融场景？
- 它属于通用强 Agent 能力，还是确有金融差异？
- 删除它以后，必要复杂度会在哪里重新出现？
若没有明确答案，不因“更完整”“更可审计”“更可复盘”而默认增加模块。FinBayes 的演进由用户价值和能力深度驱动，而不是由治理字段、历史流程或文档数量驱动。