# InvesResearch · 产品策略

> 制定日期 **2026-06-03** · 这份文档的目的是说清楚仓库里**两条产品线的关系**,以及在当前资源约束下的路径选择。
>
> 关联:[`NEXT-STEPS.md`](./NEXT-STEPS.md) · [`agent/PRD.md`](./agent/PRD.md) · [`web/docs/product-prd.md`](./web/docs/product-prd.md) · [`web/docs/enhancement-prd.md`](./web/docs/enhancement-prd.md)

---

## 1. 一句话定位

仓库里有**两条产品线**,共享方法学与工程沉淀,但目标用户与数据 schema 不共享:

| 线 | 代号 | 一句话 | 当前状态 |
|---|---|---|---|
| `agent/` | **Satellite Agent**(SatAgent) | 卫星互联网 × 双视角(CEO + 投资人)产业决策辅助 | v0.2.0 已交付,真实迭代中 |
| `web/` | **InvesResearch Agent**(IRA) | A/HK/US 三地市场通用深度调研系统 | v1.0 PRD,纸面工程,未开工 |

读者经常困惑的"这是一个产品还是两个产品"——答案是**两个,但同一方法学**。Satellite Agent 是 InvesResearch Agent 在"卫星互联网"这个垂类上的**特化样本与方法学验证**;反过来,InvesResearch Agent 是 Satellite Agent 框架往"多市场 / 通用调研"的**横向产品化**。

---

## 2. 为什么是两条线

第一,**时间锚不同**。Satellite Agent 是 2026 年 Q1 起的真实迭代,Phase 1+2+2.1+3a+3b+3c 全部落盘、64 测试通过、可跑通完整的"事件结构化 → 双视角周报"链路;InvesResearch Agent 是 2026 年 Q2 起的纸面工程,基于 Satellite Agent 阶段的方法学沉淀,做"横向产品化"的设计。

第二,**目标用户不同**。Satellite Agent 服务"产业公司决策者(CEO)+ 二级市场投资人"——前者要知道"现在该不该 all in 终端业务",后者要知道"卫星互联网 4 条主线该加减仓哪条"。InvesResearch Agent 服务"任何分析师 / PM"——他们需要的是"贵州茅台的深度报告"或"商业航空的行业研究"。

第三,**数据 schema 不共享**。这一点最容易踩坑——

| 维度 | Satellite Agent | InvesResearch Agent |
|---|---|---|
| 主数据对象 | `events` / `companies` / `threads` / `market_model` | `Security` / `DailyBar` / `FinancialStatement` / `DCFResult` / `ResearchReport` |
| 时间粒度 | 周(周报) | 单次调研(分钟级) |
| 输出形态 | 双视角周报(CEO 主驱动 + 投资仓位信号) | 结构化 PDF/DOCX 研报(Quick / Standard / Deep) |
| 数据源 | 政策文件 / 公司公告 / 产业新闻 / RSS | Tushare / AKShare / yfinance / edgartools / SEC EDGAR |
| 主线维度 | 卫星互联网 4 主线(核心网 / 终端 / 芯片 / 运营支撑) | GICS / 申万行业 |

这意味着**任何"把 agent 后端接到 web 前端"的提案都需要先做 schema 翻译层**,不是 1:1 直连。

---

## 3. 共享什么,不共享什么

### 3.1 共享(方法学 + 工程沉淀)

- **三层架构**:Harness(工程骨架)/ Agent Logic(模型与代理逻辑)/ Capability(Skills + MCP)
- **数据源抽象**:agent 端的 `Source` 与 web 端的 `Provider` 是同形态(熔断 / 退避 / 健康检查 / 优先级 failover)
- **多 Agent 辩论范式**:agent `debate.py` 的 Bull/Bear/Judge 与 web M3 的 Bull/Bear/Neutral 同源
- **LLM 兜底机制**:agent `llm.py` 的 confidence-gated escalation 与 web M2 的 structured-output fallback 同源
- **横切工程**:observability(Prometheus / Langfuse)、鉴权(Bearer token)、Docker、CI、零依赖优先
- **免责声明立场**:"研究效率工具而非投资建议"在两边强制,且免责声明字段层面落到数据模型

### 3.2 不共享(产品边界)

- 数据 schema(见 §2 第三条)
- 用户画像与典型问题
- 市场覆盖(agent 是中国卫星互联网,web 是 A/HK/US 全市场)
- 数据源池
- 报告模板(agent 是周报,web 是 Quick Note / Deep Dive / Sector Report / Earnings Recap 四种)

---

## 4. 里程碑映射(两套并存,不强行合并)

两条线各自有自己的命名(agent 用 Phase X / 横切项;web 用 M1-M6 + Stage 1-3 + EH-1~EH-7)。**不要试图统一**——硬合并会把已交付的 agent 端和纸面的 web 端混在一起。下表给出"语义对齐"映射,读者按需对照即可:

| 阶段语义 | Satellite Agent(已迭代) | InvesResearch Agent(规划中) |
|---|---|---|
| **方法学 MVP** | ✅ Phase 1 规则版 + Phase 3a 决策层规则版 | (尚未开工) |
| **真实数据接入** | ✅ Phase 2 抓取脚手架 + Phase 2.1 LLM 兜底 | M1 数据层 + M2 单 Agent + MCP |
| **多 Agent 协作** | ✅ 多 Agent debate skeleton(待接 LLM) | M3 LangGraph 编排 + 多空辩论 + EH-6 拆解范式 |
| **决策与估值** | ✅ Phase 3b PE 估值映射 + 市场模型动态视图 | (估值落在 M2 / M5) |
| **报告与分发** | ✅ Phase 3c HTML/CSV/DOCX/PPTX 多格式导出 | M5 报告生成 + 前端联调 + EH-2 活表格 + EH-3 推送 |
| **常驻 / 调度** | ⏳ 待加(类似 EH-1 的简化版) | M3.5 调度子系统(EH-1) |
| **横切工程** | ✅ Prometheus / 鉴权 / Docker / CI | 同等横切,落在每个 M 里 |
| **多市场 / 私有化** | (单一垂类,N/A) | M6 港股美股 + vLLM 私有化 + EH-4 沙箱抓数 |
| **生态化** | ⏳ 待考虑开源 satellite_agent 包 | Stage 3 Skills 包标准化 + EH-7 个性化 |

---

## 5. 当前阶段的路径选择(2026-06-03)

**原则**:先把 Satellite Agent 跑实,再启动 InvesResearch Agent 工程化。**不并行**。

理由有三:

第一,**资源约束**。仓库当前是单人节奏,web 端 24 周计划假设 6 人团队全员投入(2 BE / 1 AI Eng / 1 Data Eng / 1 FE / 0.5 SRE / 0.5 PM)。在团队就位前启动 M1 数据层,既无法保证 99% 可用率验收,也会把 agent 端的进展拖慢。

第二,**方法学先验证再泛化**。Satellite Agent 是工程上"已经跑通"的样本——双视角决策周报、Provider 抽象、LLM 兜底、多 Agent 辩论都在真实卫星互联网数据上跑过。把这些经验在 web 端复用之前,先在 agent 端把"真实 RSS 闭环 + debate 接 LLM + 公司卡片扩容到 20 家"跑实,能极大降低 web 端启动风险。

第三,**EH-1~EH-7 可以先在 agent 端试水**。enhancement PRD 列的七条增强(常驻 agent / 活工作区 / 主动推送 / 沙箱抓数 / 自定义 Skill / 复杂任务拆解 / 个性化)虽然是为 web 端写的,但其中至少有 4 条(EH-1 / EH-3 / EH-4 / EH-6)可以**先在 agent 端做最小可用版**,既能让 agent 跑得更实,也能为 web 端的全量实施积累经验。

### 5.1 这意味着 NEXT-STEPS 的措辞调整

[`NEXT-STEPS.md`](./NEXT-STEPS.md) 的本轮 4 条仍是 agent 端的演进,但有两处措辞需要矫正:

- **§2.1 "前端打通 web/app.html"** — `web/app.html` 是 InvesResearch Agent 的工作台 demo(纯前端,模拟数据 schema 是分析师/PM 视角),与 Satellite Agent 的 events/companies/threads schema **不兼容**。这一条 P0 的真实工作是"为 agent 端做一个独立的演示前端"(或扩展 `agent/docs/dashboard.html`),而不是把 agent API 塞进 web/app.html。
- **§3 潜在方向 I "EH-1~EH-7 落地"** — enhancement PRD 列为 P0,但在 NEXT-STEPS 本轮 4 条里没排位。**正确口径**:EH-1 / EH-3 是 P0 优先级,但执行排期在本轮 4 条之后(下下轮起,见 NEXT-STEPS §3)。

### 5.2 InvesResearch Agent 启动的触发条件

web 端 M1 数据层启动前,至少满足以下三条之一:

1. agent 端本轮 4 条 P0-P3 至少 3 条已上线、稳定运行 2 周以上
2. 至少 2 名工程师加入,具备启动 M1 的最小人力(1 BE + 0.5 SRE)
3. 出现明确的商业触发(企业客户 PoC 意向 / 投资人尽调要求)

未满足前,web/docs/ 三份 PRD 仅作为"沉淀的产品设计",不进入排期。

---

## 6. 技术栈对齐路径

§5 已经说明了"agent 先做、web 后做"的顺序。这一节回答**怎么做才让两条线的技术栈尽可能一致**——目标不是机械统一,而是把"web 端将要用的栈"先在 agent 端用真实数据跑过一遍,等 web 端真启动时,M1/M2/M3.5 三个里程碑的工程风险已经在 agent 端被吃掉了大半。

### 6.1 现状对照

| 维度 | agent 端(已跑) | web 端(规划) | 关系 |
|---|---|---|---|
| 语言 | Python 3 | Python 3 + TS(Next.js) | ✅ 天然一致 |
| API 框架 | FastAPI | FastAPI | ✅ 天然一致 |
| 测试 | pytest 64 通过 | pytest | ✅ 天然一致 |
| 部署 | Docker + docker-compose | Docker + Helm | ✅ 天然一致 |
| 数据校验 | 部分 Pydantic + 部分 dict / sqlite row | Pydantic v2 强制 | 🔧 可对齐(低成本) |
| LLM 路由 | 自研 `llm.py`(OpenAI / Claude) | LiteLLM 网关 + 多档位 | 🔧 可对齐(低成本) |
| 数据库 | SQLite | Postgres + TimescaleDB + DuckDB | 🔧 可对齐(中成本) |
| 缓存 | 无显式分层 | 4 层(LRU / Redis / DuckDB / PG) | 🔧 可对齐(中成本) |
| 观测 | Prometheus 零依赖 | Langfuse + OpenLLMetry | 🔧 可对齐(低成本,Langfuse 自托管) |
| 调度 | 无 | APScheduler / Celery beat | 🔧 可对齐(EH-1 已规划) |
| 多 Agent | debate skeleton 函数式 | LangGraph StateGraph + checkpointer | 🔧 可对齐(中成本) |
| 能力封装 | CLI + REST | Skills + MCP(FastMCP) | 🔧 可对齐(低-中成本) |
| 向量库 | 无 | pgvector → Qdrant | 🔧 可对齐(中成本,有真实需求才做) |
| 前端 | 单 HTML dashboard | Next.js + SSE | ⚠️ 视需求(分析师用户场景出现再上) |
| 数据 schema | events / companies / threads | Security / FinancialStatement / ... | ❌ 注定不一致(产品差异) |
| 数据源 | 政策 / 公告 / RSS | Tushare / AKShare / yfinance / edgartools | ❌ 注定不一致(产品差异) |

### 6.2 三档对齐路径

**Tier 1 · 几乎免费**(本轮 / 下下轮顺带做)

- agent 数据模型补齐 Pydantic v2(目前 `events` / `companies` 是 dict + sqlite row)
- `llm.py` 包装成 LiteLLM 兼容客户端(保留现有 provider 接口,加一层 model routing)
- agent dashboard 的 design tokens / 颜色变量与 web 端 `index.html` 对齐

**Tier 2 · 中成本高 ROI**(下下下轮起,与 EH-1 / EH-3 同期)

- SQLite → Postgres + Timescale 迁移(同时就是 web M1 的"真相源"先验)
- 引入 Redis 做限流令牌桶 + 热数据缓存(为后续 RSS 真实源做铺垫)
- Langfuse 自托管 + OpenLLMetry 埋点(直接对接 web M2 的可观测性栈)
- APScheduler 调度(EH-1 简化版已规划)

**Tier 3 · 较大改造,产生明显业务价值再做**

- `debate.py` 升级到 LangGraph `StateGraph` + Postgres checkpointer(对应 web M3)
- agent CLI 工具包装成 FastMCP server,让 agent 能被 Claude Code 等 runtime 调用(对应 web M2 能力层)
- 加 pgvector 做事件 / 公司语义检索(对应 web M4)

### 6.3 三个不该对齐的边界

避免过度对齐导致 agent 失去聚焦:

1. **数据 schema 不要融** — agent 是垂类(卫星 4 主线),web 是通用(GICS / 申万),融了就两边都做不好;它们之间永远是"翻译层",不是"同表"
2. **前端不要现在上 Next.js** — agent 单 HTML dashboard 够用,真有分析师用户场景再迁;盲目重写只会拖慢 agent 演进
3. **不要为了对齐而对齐** — 比如 ADR-08 OAuth 2.1 MCP 这种在 agent 当前部署形态下无价值的,先不做;每条对齐项都需要回答"为什么 agent 现在就要"

### 6.4 这条路径的价值

按 Tier 1 → 2 → 3 顺序执行(分别落在本轮 / 下下轮 / 下下下轮),等 web 端真要启动 M1 时,会发现:

- **M1 数据层**(Provider 抽象 + 熔断 + 路由 + 4 层缓存)的核心组件已在 agent 端跑过真实 RSS 数据
- **M2 单 Agent + MCP + Pydantic 输出 + Langfuse 埋点** 几乎全部就位
- **M3.5 调度子系统** 已有 agent 简化版作参考

剩下要做的主要是"把 agent 端的卫星垂类替换为 web 端的多市场 schema + provider",**工程风险压成了几乎可忽略**,而 web 端 24 周计划的前 12 周大半已经在 agent 端被消化。

---

## 7. 给不同角色的指引

- **如果你是新读者** — 先读这份文档,再读 [`agent/PRD.md`](./agent/PRD.md) 看正在跑的产品长什么样,然后看 [`web/docs/product-prd.md`](./web/docs/product-prd.md) 看未来要扩到什么形态。
- **如果你是工程师** — agent 端代码在 `agent/satellite_agent/`,跑 `pytest` 看 64 测试通过;web 端**目前只有 PRD**,代码 0 行。
- **如果你是产品/利益相关方** — 看 [`NEXT-STEPS.md`](./NEXT-STEPS.md) 知道本轮在做什么,看本文档 §5 知道为什么是这个顺序。
- **如果你想贡献** — 见 [`CONTRIBUTING.md`](./CONTRIBUTING.md),agent 端有真实可上手的 issues,web 端目前不接受代码贡献(只接受 PRD 评审意见)。

---

## 8. 共享免责声明

两条产品线的所有产出均定位为**研究效率工具**,不构成任何投资建议。仓库内的 placeholder 数据(包括 agent 端的 6 家公司种子、web 端的所有 DCF 示例假设)在接入实盘或商业化前必须由真实、合规来源的数据覆盖。