# InvesResearch Agent · 增强版产品需求文档(Enhancement PRD) > 在现有《产品 PRD v1.0》《工程 PRD v2.0》《路线图 v1.0》基础上的下一版功能增强 · **版本 v1.0** · 状态:增强草案待评审 > > 关联文档:[产品 PRD](./product-prd.md) · [工程 PRD](./engineering-prd.md) · [路线图](./roadmap.md) · [架构决策](./architecture-decisions.md) · [系统设计文档](./system-design.md) > > 增强来源:2026-06-02 一场 AI 投研实战分享会中观察到的、已被市场验证的产品形态。本文档把那些 InvesResearch 当前架构尚未覆盖、或仅排在较后阶段的"运行态能力",前移并落地为可执行需求。 --- ## 0. 为什么需要这一版增强 InvesResearch 现有三份文档在架构上已经相当完整——三层解耦、LangGraph 状态机、多空辩论、数据容灾、eval 驱动开发。但把它和一线投研工具的实际使用形态并排看,会发现一个一致的、贯穿始终的差异:**InvesResearch 是围绕"批处理"心智模型设计的,而真正高频、高粘性的投研工作其实是"常驻态"的。** InvesResearch 的核心叙事是"把数天的调研压缩到分钟级"——用户发起一次深度调研,多 Agent 图跑几分钟,产出一份报告,会话结束。这是一个"请求 → 等待 → 报告"的形状。而一线实践揭示的是另一种形状:相当大比例的日常使用是定时任务和日报;分析师"住"在一张能逐单元格对话的表格里;系统按月定时抓某个细分数据、把同环比变化主动推送过来;一位基金经理把整套筛选框架做成一个常驻能力,在时间序列上持续运行。这些都不是"跑一次出一份报告"的形状,而是"工作台常开 + 一队常驻 agent 持续干活"的形状。 对照之下,InvesResearch 把 Watchlist、定时调研、告警都排到了较后阶段(见产品 PRD §5 功能全景表与路线图),把报告当作主要交付物。**因此这一版增强的核心主张是:工作台不是报告生成器,而是一个活的工作区,加上一支可被用户编程的常驻 agent 队伍。** 本文档的全部增强都围绕这个判断展开。 需要说明定位:这不是推翻现有 PRD,而是在它之上做加法与排序调整。每条增强都尽量挂到现有架构的具体位置(某个里程碑、某个 MCP 工具、某层 harness),以便直接并入研发计划。 --- ## 1. 增强总览:七条主线 | 编号 | 增强主线 | 挂载到的位置 | 优先级 | 依赖 | 预估工期 | |---|---|---|---|---|---| | EH-1 | 常驻 Agent 与定时任务 | 新增 harness 调度子系统 + 提前 Watchlist | **P0** | M3 编排就位 | 4 周(1 BE) | | EH-2 | 可对话的活工作区(在线表格) | 工作台 §6.1 + 新增 MCP 工具 | **P0** | M5 前端重构 + 选型确定 | 6-8 周(1 FE + 1 BE) | | EH-3 | 主动推送与多渠道送达 | 接口层 L5 + 新增通知子系统 | **P1** | EH-1(否则空跑)+ M5 ResearchReport 模型 | 2-3 周(1 BE,飞书先行) | | EH-4 | 浏览器沙箱自主抓数 | 数据层 §3 provider + harness 沙箱 | **P1** | M1 Provider 抽象 + 法务清明 | 3-4 周(1 Data Eng + 安全审查) | | EH-5 | 用户可定义的 Skill 框架 | Skills 能力层 §5.2 | **P1** | M2 Skills 体系 + M4 RAG 数据 | 4 周(1 AI Eng) | | EH-6 | 复杂任务拆解与编排范式 | 编排层 §6 + 上下文工程 §7 | **P1** | M3 LangGraph 就位 | 2-3 周(1 AI Eng,与 M5 长任务 harness 同期) | | EH-7 | 个性化与"蒸馏" | 新增记忆子系统 + 个人化 Skill | **P2** | EH-1 + EH-2 + EH-5 + M6 私有化 | 6-8 周(全员协作) | > **关于"P0"** — 这里的 P0 指**优先级层级**(对产品价值的判断),不等于**执行顺序**。EH-1/EH-2 排在 P0 是因为它们决定"工作台是不是常驻起来",但执行顺序仍受里程碑依赖约束(详见 §3 与下方依赖图)。在仓库当前的[`NEXT-STEPS.md`](../../NEXT-STEPS.md) 排期里,EH-1 / EH-3 落在"下下轮"(本轮 4 条上线后启动),EH-2 / EH-5 / EH-6 落在 M3-M5 期间,EH-4 落在 M6,EH-7 落在 Stage 3。 ### 1.1 EH 间依赖关系 ``` M1 数据层 ────┬─> EH-4 沙箱抓数 ──────────────┐ │ │ M2 单 Agent ──┴─> M3 编排 ──> EH-1 调度 ──┐ │ │ │ │ └────> EH-6 拆解 ─┐ │ │ │ │ │ M4 RAG ──> EH-5 自定义 │ │ │ Skill │ │ │ v v v M5 报告+前端 ──> EH-2 活表格 ──┐ │ │ └──> EH-3 飞书送达 ─────┤ │ v Stage 3 ──> EH-7 个性化 ``` 关键路径有两条: - **常驻闭环**:M3 编排 → EH-1 调度 → EH-3 送达(没 EH-3,EH-1 就是空跑) - **活工作区**:M5 前端 → EH-2 活表格(EH-2 技术依赖最重,选型不定无法启动) --- ## 2. 详细增强需求 ### EH-1 · 常驻 Agent 与定时任务(建议从较后阶段前移到 P0) **动因。** 这是本次增强的核心。一线实践给出的最硬的一个信号是:在已上线的同类工具里,相当大比例的使用场景是日报或定时任务,人均每天数个。这说明"常驻、定时、低干预"的使用模式不是锦上添花,而是日常粘性的主要来源。而 InvesResearch 现有架构里,整个系统是"用户发起 → 图跑完 → 结束"的一次性会话,Watchlist 与定时调研被排到了较后阶段。这是一个心智模型层面的缺口。 **需求描述。** 在现有 harness 之上新增一个**调度子系统(Scheduler)**,作为与会话层、控制平面、追踪层并列的子系统。它允许用户把任意一次成功跑通的调研流程"固化"为定时任务:先让系统跑一遍、确认结果满意,再一键 schedule。这正是更成熟的使用范式——不必上来就定义日报,而是先试跑、满意后再定时。 调度子系统需支持:cron 式时间表达(每日/每周/每月,可指定时刻);任务状态管理表(哪些在跑、哪些已停、上次结果、下次运行时间);失败重试策略(例如每月 1 号抓数,若未就绪则 15 号重试——一个值得借鉴的健壮设计);以及与编排层 checkpointer 的复用(定时任务本质是一次被调度触发的 LangGraph 运行)。 **与现有架构的衔接。** 调度子系统天然复用现有的 Postgres checkpointer 与 LangGraph 图——一个定时任务就是"在指定时间用预设参数触发一次 graph 运行,并把结果送达"。新增的是触发器、任务注册表、与通知子系统(EH-3)的对接。成本护栏沿用,但需补充"任务级月度预算"维度,防止高频任务累积失控。 **验收标准(Given-When-Then)。** - *Given* 用户已成功跑通一次"美股 52 周新高筛选(市值 > 100 亿美元)"调研,*when* 用户点击"设为每日任务、每天早 7 点、推送至飞书",*then* 系统创建定时任务,次日 7 点自动运行并送达,任务出现在管理表中状态为"运行中"。 - *Given* 一个"每月 1 号抓上月数据"的任务,*when* 1 号运行时上游数据未更新,*then* 任务不报错,登记一次"数据未就绪"并自动安排 15 号重试,Langfuse 记录两次 trace。 - *Given* 某定时任务本月累计 token 成本触及任务级预算 100%,*when* 下次触发,*then* 任务暂停并告警,不再自动运行直到用户确认。 **里程碑建议。** 新增 **M3.5(调度子系统)**,依赖 M3(编排)与 M5(送达),可与 M4 并行设计、在 M5 落地。不必等到 Stage 3。 **执行卡。** - *启动条件*:M3 LangGraph 编排上线 + Postgres checkpointer 就位 - *最小可发布版本(MMR)*:一个跑通的调研 → 一键设为 cron 任务 → 次日自动跑出结果,任务管理表显示"运行中"(本步骤不强制送达,只让用户在 UI 看) - *关键决策*:① 调度引擎选型(APScheduler 轻量 / Celery beat 重型 / 自研);② 任务级预算触发是只告警还是熔断;③ 任务重入防护是 Postgres advisory lock 还是 Redis SetNX - *agent 端先做最小版的可行性*:可行。NEXT-STEPS 已把 EH-1 agent 简化版纳入"下下轮"——不上 LangGraph,用 APScheduler + SQLite checkpoint,把"每周跑一次 decision"做成定时任务即可 --- ### EH-2 · 可对话的活工作区:在线表格与单元格级上下文(P0) **动因。** 最具说服力的一线形态,是"AI 直接操控在线表格":生成供需平衡表、CapEx 跟踪表后,用户框选某几个单元格或整列、右键"加入对话",再用大白话追问,AI 就基于这块局部上下文原地更新、新增 sheet、写公式、标注数据来源。一句话点破了它的价值——表格是研究过程和生成结果发生的地方,AI 能直接操控它,才意味着 AI 真正融入了工作流。 InvesResearch 现有工作台(产品 PRD §6.1)是六个标签页的**展示型**界面:能看、能导出报告,但用户不能在一张活的表格里和 AI 来回改数。DCF 模块(§6.2)虽允许调参,但那是预设表单字段,不是一张可自由对话的电子表格。这中间差了一个"研究过程发生的地方"。 **需求描述。** 在工作台中新增**可对话表格(Conversational Sheet)**作为一等公民:渲染一张在线电子表格(承载 DCF、供需平衡、可比估值、CapEx 跟踪等任何结构化模型);支持框选单元格区域或整列,把选区作为结构化上下文"加入对话";AI 基于选区上下文原地修改——改数、补列、写公式、新增 sheet、冻结表头、对每个数据点标注 source(呼应现有 `FinancialStatement.source` 与 `data_quality_flag`);以及用自然语言下达预测指令并解释预测方法。 一个关键工程洞察:当用户框选某区域提问、问题里并未出现公司名时,AI 仍知道在问哪家公司——因为它在上下文里加载了整张表的结构,理解了选区落在哪个区块里。**这意味着可对话表格的上下文必须同时携带"选区坐标"和"整表结构",而非只有选区里的裸数值。** 这正好与工程 PRD §7 的上下文工程原则一致:用最小高信号的 token 集合驱动 agent。 **与现有架构的衔接。** 新增一类 MCP 工具(`sheet_read(range)` / `sheet_write(range, values/formula)` / `sheet_add_sheet`),属"数据与计算"性质,归 MCP 层(符合工程 PRD §5.3 的边界法则)。表格渲染与选区交互在接口层(Next.js + SSE)。DCF 模块从"参数表单"升级为"可对话表格"的一个预置模板;其原有的 HITL 断点(假设需人工确认)完全保留——EH-2 让人机交互更细粒度,而非削弱人工背书。 **验收标准。** - *Given* 已生成一张四大云商 CapEx 跟踪表,*when* 用户框选某公司"指引 vs 实际"几个单元格并问"为什么持续 beat",*then* AI 在未被显式告知公司名的情况下,基于选区所在区块正确识别该公司并给出归因,回答可追溯到表内数据。 - *Given* 一张 DCF 表,*when* 用户在表头新增一列"CY26"并框选该列说"预测 26 年",*then* AI 填入预测值、标注预测方法、并保留 HITL 断点(关键假设需人工确认后才写入最终报告)。 - *Given* AI 对某单元格写入引用值,*when* 用户查看,*then* 能看到 source 标注;若该指标跨源差异 > 10%,带 `data_quality_flag` 提示。 **里程碑建议。** 并入 **M5(报告生成 + 前端联调)**,与前端重构、SSE 实时流同批;DCF 表单升级为可对话表格作为 M5 的明确子项。 **执行卡。** - *启动条件*:M5 前端从 vanilla 迁 Next.js 完成 + 在线表格组件选型敲定(本条是 EH 里启动条件最重的) - *最小可发布版本(MMR)*:DCF 模块升级为可对话表格,用户框选 WACC / 永续增长率单元格"加入对话",AI 基于选区上下文改数并保留 HITL 断点 - *关键决策*:① 在线表格组件(Univer 国产开源、Luckysheet 国产社区版、Handsontable 商业、自研 React)——决定了 6-8 周工期的下限;② 选区上下文 token 预算(选区坐标 + 整表 schema + 局部数值,典型预估 2-4k token,需控制不超 8k);③ AI 写回单元格的事务模型(原子写 vs 增量提交) - *Skill/MCP 分层*:`sheet_read` / `sheet_write` / `sheet_add_sheet` 归 MCP(数据计算);"DCF 标准建模流程"归 Skill(知识) --- ### EH-3 · 主动推送与多渠道送达(P1) **动因。** 把生成结果主动推送到飞书/微信,是定时任务能成立的前提——没有送达,定时任务就只是后台空跑。一线经验显示飞书对 AI 生成内容的适配性和限制都更少,值得优先打通。InvesResearch 现有接口层(L5)只有"前端 SSE 实时进度流",是**拉取式**的;用户必须主动打开工作台才能看到结果,这与 EH-1 的常驻模式不匹配。 **需求描述。** 新增**通知子系统(Notifier)**,把调研产出、定时任务结果、异常告警主动送达多渠道:优先飞书,其次企业微信/微信、邮件。送达内容适配渠道形态——飞书/微信用卡片式摘要 + 可点开详情,邮件用完整报告附件。送达支持"增量/变化"语义:不是每次推全量,而是推"本月同比环比变化""创新高的标的""命中红线的持仓",让用户碎片时间即可消费。 **与现有架构的衔接。** 通知子系统与调度子系统(EH-1)对接:定时任务跑完 → 调用 Notifier 送达。它把现有 `ResearchReport` 模型渲染成多种渠道格式,并复用安全工程(工程 PRD §9)的合规约束:每条送达同样强制带免责声明(从 `ResearchReport.disclaimer` 字段层面已保证)。 **验收标准。** - *Given* 一个定时任务跑出"A 股放量上穿 10 亿的公司及其逻辑",*when* 任务完成,*then* 飞书收到一张卡片,含标的列表、上涨逻辑摘要、可点开完整报告链接,带免责声明。 - *Given* 月度持仓复盘任务,*when* 某持仓本月命中"不应追高"红线,*then* 推送内容高亮该条变化(增量语义),而非重复推送未变化持仓。 **里程碑建议。** 与 EH-1 同期,落在 M5 前后。飞书渠道先行,微信/邮件渐进增强。 **执行卡。** - *启动条件*:EH-1 上线(否则没有"任务完成"触发点)+ `ResearchReport` Pydantic 模型字段稳定 - *最小可发布版本(MMR)*:飞书机器人 webhook + 周报 markdown → 飞书卡片渲染,支持"创新高 / 命中红线"两类增量推送(而非全量推送已知信息) - *关键决策*:① 飞书企业自建 app vs 单纯 webhook 机器人(前者能调更多接口,后者部署轻);② 推送频次的节流(同一标的每日最多 N 条);③ 法务边界——企业 IM 推送研究结论是否触发合规要求,商业化前需明确 - *agent 端先做最小版的可行性*:可行。NEXT-STEPS 已把 EH-3 飞书单渠道纳入"下下轮",与 agent 版 EH-1 闭环 --- ### EH-4 · 浏览器沙箱自主抓数(P1,补强数据层长尾覆盖) **动因。** InvesResearch 的数据层(工程 PRD §3)设计扎实,但它覆盖的是**结构化、有库可接**的数据源。产品 PRD §6.3 也坦承免费源对小众细分数据覆盖有限。一线实践补上了这个长尾——当某个数据"没有库可接、只散落在某个网页上"时,AI 启动沙箱浏览器,自动打开链接、识别来源站、查编码、点击页面按钮抓数、汇率换算、标注来源。这种能力让数据覆盖从"我们接了哪些库"扩展到"互联网上能点开的任何页面"。 **需求描述。** 工程 PRD §2.2 已规划 harness 的"沙箱"子系统用于隔离执行不可信代码——把它的职责扩展到**浏览器自动化抓取**。新增一个 provider 类型(对应 §3.2 的 `Provider` 抽象),不接 API 而是驱动沙箱内的无头浏览器,按"打开页面 → 定位元素 → 点击/输入 → 提取 → 结构化"流程抓数,产出依然是标准化 Pydantic 模型。它同样被 §3.3 的熔断器、退避、令牌桶包裹——抓取比 API 更脆弱,容灾更不能少。 **与现有架构的衔接与安全。** 这是 EH 里安全敏感度最高的一条,必须严格落在工程 PRD §9 的安全框架内:沙箱浏览器容器隔离运行;抓取内容当数据而非指令处理,剥离可疑标签防注入;凭证代理边界照旧。合规上继承产品 PRD §13 的数据合规风险管理——抓取的页面同样存在服务条款限制,商业化前需评估。 **验收标准。** - *Given* 一个"没有现成 API、只有网页"的数据需求,*when* 用户描述数据所在页面,*then* 沙箱浏览器完成抓取,产出标准化数据,带 source 与抓取时间戳,币种已统一(呼应 §10)。 - *Given* 目标网页结构变动导致抓取失败,*when* 连续失败达阈值,*then* 熔断器打开、记录事件,而非反复重试拖垮任务。 - 安全验收:抓取内容若含 ``/`` 类注入标签,在进入 agent 上下文前被剥离,Langfuse 记录一次清洗事件。 **里程碑建议。** 落在 **M6(多市场扩展)**——它本质是数据层的横向扩展,与 M6 的港股/美股 provider 扩展共享同一批数据层改造。 **执行卡。** - *启动条件*:M1 `Provider` 抽象就位 + 法务对"抓取目标白名单 / 频率上限 / 商用边界"出具书面意见 - *最小可发布版本(MMR)*:对 1 个"无 API 只有网页"的细分指标(如某行业协会的月度排名,或某地方政府的产业园订单公告)做端到端抓取,产出标准化 Pydantic 模型 + 抓取时间戳 + 币种统一 - *关键决策*:① 浏览器引擎(Playwright 跨浏览器 vs Puppeteer 仅 Chrome);② 反爬应对(代理池规模 / UA 轮换 / 验证码 fallback);③ 抓取内容当数据处理的注入清洗规则(剥离 `` 等标签的具体策略) - *agent 端先做最小版的可行性*:中等。可对现有 `sources/rss.py` 加无头浏览器 fallback,但本身就是 P3(本轮 P3 真实 RSS 源都还没上线),建议放到下下下轮 --- ### EH-5 · 用户可定义的 Skill 框架:把"分析师的脑子"写成 Skill(P1) **动因。** 两个最受好评的一线案例——公告筛选(识别高管诉求变化的"组合拳")和买入评分卡——本质上都是"用户先把自己的分析框架讲清楚,再让 AI 照着这个框架在数据上干活"。核心理念:别把 AI 只当问答工具,把它当成能给你的框架干活的工具,前提是你的框架还行。 InvesResearch 现有 Skills(工程 PRD §5.2)是**官方预制**的,契约、流程、输出都研发写死。缺的是让**用户自己定义 Skill**——把一位资深分析师脑子里的筛选逻辑、打分框架,沉淀成可运行、可复用、可迭代的 Skill。这恰是 InvesResearch "把功课做扎实"定位的自然延伸:不只替用户做标准化调研,还承载用户的个人方法论。 **需求描述。** 提供**用户自定义 Skill 的创作流程**:用户用自然语言(或半结构化模板)描述框架——先讲"我怎么理解这件事",再讲"我要你监控什么、按什么分层、命中什么算信号";系统落成一个符合 Agent Skills 标准的 Skill(`SKILL.md` + frontmatter + 流程),存入工作区,可显式或隐式调用,可随时编辑迭代(追加关键词后当场更新)。这类 Skill 同样能跨时间序列运行(配合 EH-1 做成定时筛选)。 **与现有架构的衔接。** 这是对 §5.2 Skill 契约的直接扩展——用户 Skill 复用同一套 `SKILL.md` 格式、`allowed-tools` 白名单、skill 校验器。关键差别在于来源是用户而非官方,因此安全上套用 §9 的"第三方 Skill 审计"机制:用户自定义 Skill 默认只能调用只读、非破坏性 MCP 工具,涉及破坏性操作或外发须走 HITL。组合拳/分层这类结构化筛选,可借鉴 agent 那条线的事件结构化 schema 思路,给用户框架一个结构骨架,比纯关键词匹配更稳。 **验收标准。** - *Given* 用户用自然语言描述了一套筛选框架(含多动作组合的定义),*when* 用户保存,*then* 系统生成符合 Agent Skills 标准的 Skill,通过校验器(无断链、名称匹配、token 不超预算)。 - *Given* 该 Skill,*when* 用户说"跑一下当天结果",*then* 系统在公告/纪要数据上按用户分层返回命中公司,每条命中可追溯到原始公告。 - *Given* 用户追加一批关键词,*when* 保存,*then* Skill 当场更新、后续生效;该 Skill 默认无法调用任何破坏性工具。 **里程碑建议。** 落在 **M4 之后、Stage 3 之前**——依赖 Skills 体系(M2)与 RAG/舆情数据(M4,需检索公告与纪要),属 Stage 2 末到 Stage 3 的差异化能力。 **执行卡。** - *启动条件*:M2 Skills 体系上线 + M4 RAG 至少覆盖公告/纪要两类语料 - *最小可发布版本(MMR)*:用户用自然语言描述一套"识别高管诉求变化"的多动作组合筛选框架,系统生成符合 Agent Skills 标准的 SKILL.md,在历史公告语料上跑出命中公司列表(每条命中可追溯到原始公告) - *关键决策*:① 用户 Skill 的安全沙箱级别(默认只读 / 白名单 allowed-tools / 完全沙箱化);② prompt-as-Skill 的 injection 防御策略(把用户描述当数据而非指令);③ Skill 校验器的强约束(无断链 / 名称匹配 / token 不超预算);④ 涉及破坏性操作的 HITL 触发逻辑 --- ### EH-6 · 复杂任务拆解与编排范式(P1,补强编排健壮性) **动因。** 一个很有工程价值的反例:把一个极复杂的日报任务一次性丢给 AI,结果质量很差。原因是受上下文 token 限制,AI 倾向"偷懒"——不逐条执行,而是直接语义搜索甚至上网找现成结果糊弄过去。解法是把大任务拆成多个子能力,每个只干一件事、各写一份中间产物,最后一个汇总步骤去重合并。 InvesResearch 的编排层(工程 PRD §6)已有很好基础——LangGraph 状态机、分析师并行 fan-out、子代理上下文隔离(§7)。但它的拆解是**研发预设的图结构**,缺一个面向用户复杂任务的"自动复杂度评估 + 拆解"范式。而这个反例恰好与 §7 的"子代理隔离"原则、以及 M5 的"两段式长任务 harness"是同源思想,值得显式上升为一条编排范式。 **需求描述。** 在编排层增加**复杂度评估与拆解策略**:当任务被判定为高复杂度(子目标多、单步预计消耗超过上下文利用率的 40%~60%——这个阈值 §7 已给出),Supervisor 不强行一把跑完,而是拆成多个子代理,每个在独立上下文窗口里只完成一个子目标、产出结构化中间产物,最后由合并节点去重整合。这同时缓解 §6.4 的成本护栏压力(子代理隔离能把一次 5 万 token 的探索压缩成 2 千 token 的摘要回传,这正是 §7 已写明的收益)。 **与现有架构的衔接。** 这条增强几乎完全是把现有 §7 的上下文工程原则"产品化"成一条用户可感知的能力。LangGraph 的 `Send` 原语已支持 fan-out;子代理隔离已是既定原则;M5 的两段式长任务 harness 已是既定方案。EH-6 要做的是把这些零散手段收敛成"识别复杂任务 → 自动拆解 → 中间产物落盘 → 合并"的显式范式,并暴露给用户"先试跑一版,不行就拆"的交互。 **验收标准。** - *Given* 一个含 5 个以上子目标的复杂任务,*when* 用户发起,*then* Supervisor 判定为高复杂度并拆成多个子代理,各产出结构化中间产物,最后合并为去重后的完整文档,质量与长度优于一把跑完的版本(用 eval 数据集对比)。 - *Given* 拆解后某子任务失败,*when* 重跑,*then* 仅该子任务重跑,已完成中间产物不丢失(复用 checkpointer)。 - *Given* 一个简单任务,*when* 用户发起,*then* 系统不做不必要拆解,直接单流程返回(避免过度工程)。 **里程碑建议。** 增强 **M3(多 Agent 编排)**,作为编排层的范式补充;与 M5 的两段式长任务 harness 呼应。 **执行卡。** - *启动条件*:M3 LangGraph 状态机上线 + `Send` 原语已用于分析师组 fan-out - *最小可发布版本(MMR)*:对一个含 5+ 子目标的"年度持仓复盘"任务,Supervisor 自动判定为高复杂度并拆解为子代理,各产出结构化中间产物,最后合并节点去重整合;一个简单任务则不做拆解 - *关键决策*:① 复杂度判定阈值(子目标数 / 单步 token 占用率 / 预估时长,§7 已给 40-60% 的方向);② 是否暴露"手动强制拆解"开关给用户(产品需要权衡过度工程);③ 子代理失败时的局部重跑策略 - *本条更像工程原则而非用户需求*:EH-6 的产品形态较薄,主要价值是让"子代理隔离"这条已有的工程纪律变成用户可感知的"拆解过程可视化" --- ### EH-7 · 个性化与"蒸馏":让系统了解你(P2) **动因。** 一个一线案例:用户上传自己的交易明细(含当时笔记),AI 复盘出"持仓时间影响 alpha、买入段弱于卖出段",并产出一张多维评分卡(含一票否决),做成"买入打分/月度复盘/下周关注"几个可隐式调用的 Skill。由此引出一个深刻判断:"蒸馏"一个人的决策风格,前提是同时拥有他的交易(X、Y)和决策过程笔记,而不只是公开持仓——只有系统足够了解你,给的建议才真正有启发性。 InvesResearch 现有设计是**通用**的——对所有用户产出同样标准的调研,没有"记住这个用户的框架、持仓、历史判断"的记忆机制。这是它从"通用研究工具"走向"个人投研副驾"的关键一跃,但也是合规与责任最敏感的一条,故定 P2。 **需求描述。** 新增**用户记忆子系统**(可对应 LangGraph 的长期记忆/记忆块):安全存储用户的研究框架、关注标的池、历史调研判断、(可选且严格本地/私有化的)交易明细与笔记;让调研和评分能基于这些个人上下文给出"了解你"的建议。配套新增可隐式调用的个人化 Skill:买入前打分、月度持仓复盘(产出评分变化表,正好复用 EH-2 的可对话表格)、下周关注。 **与现有架构的衔接与合规。** 记忆子系统对接工程 PRD §9 的安全与私有化方案——涉及用户交易数据,必须支持数据不出域的私有化部署(vLLM + 气隙),加密存储,默认不上传。所有个人化建议同样强制带免责声明,且继承一线的态度:这些是**启发性而非决策性**输出。 **验收标准。** - *Given* 用户(在私有化部署下)授权接入自己的交易明细与笔记,*when* 用户问"现在能不能买 X",*then* 系统给出基于个人历史的评分与建议(含"你历史上交易这类标的的表现"),带免责声明,数据全程不出域。 - *Given* 月度复盘 Skill,*when* 运行,*then* 产出一张可对话表格(复用 EH-2),展示各持仓本月评分变化与命中的红线。 - 合规验收:非私有化部署下,交易明细类敏感数据默认不可上传,系统明确提示该能力需私有化环境。 **里程碑建议。** Stage 3 或之后;依赖记忆子系统与私有化部署(M6)。 **执行卡。** - *启动条件*:EH-1(常驻) + EH-2(活表格) + EH-5(自定义 Skill) 全部上线 + M6 vLLM 私有化部署方案完成 + 法务对"用户交易明细本地存储"出具书面意见 - *最小可发布版本(MMR)*:用户在私有化部署下授权接入交易明细 + 笔记,产出"买入打分 + 月度复盘"两个可隐式调用的个人化 Skill,复盘表用 EH-2 的可对话表格渲染 - *关键决策*:① 记忆持久化形态(LangGraph 长期记忆块 vs 独立向量库 vs 用户自托管 SQLite);② 非私有化部署下是否完全禁用本能力(建议:是,在 UI 层显式提示"该能力需私有化环境");③ "蒸馏"的边界——多深的过去判断会被纳入(全部历史 vs 滚动 N 个月);④ 这是 EH 里合规与责任最敏感的一条,免责声明措辞需法务复核 - *为什么排 P2*:技术依赖最重(4 个前置条件),且合规风险最高;产品价值高但不是"日常粘性主来源",故让位给 EH-1 / EH-2 / EH-3 三条"常驻基础设施" --- ## 3. 增强需求与现有里程碑的对照 核心调整是:**把"常驻态"能力(EH-1、EH-2、EH-3)从较后阶段前移到 Stage 1/2**,因为它们是日常粘性的主要来源,而非生态化阶段的锦上添花。 | 现有里程碑 | 原计划 | 增强叠加 | 调整说明 | |---|---|---|---| | M2 单 Agent+MCP | 核心工具 + 基本面 Skill | (无新增) | 保持 | | M3 多 Agent 编排 | LangGraph 状态机 + 辩论 | **EH-6** 复杂任务拆解范式 | 把 §7 上下文原则升级为显式编排范式 | | M3.5(新增) | — | **EH-1** 调度子系统 | 新增里程碑:常驻 agent 与定时任务 | | M4 RAG+舆情 | 向量库 + 舆情 + 量化筛选 | **EH-5** 用户自定义 Skill | 自定义 Skill 需 RAG 数据支撑 | | M5 报告+前端 | 报告生成 + 前端联调 | **EH-2** 可对话表格 + **EH-3** 通知子系统 | 与前端重构、SSE 同批;送达让定时任务闭环 | | M6 多市场+私有化 | 港股美股 + vLLM + eval | **EH-4** 浏览器沙箱抓数 | 沙箱抓取是数据层横向扩展 | | Stage 3 生态化 | 开源 + 跨 runtime | **EH-7** 个性化与蒸馏 | 依赖记忆子系统与私有化 | --- ## 4. 对现有四个待决策问题的影响 现有文档(工程 PRD §11、产品 PRD §14、路线图 §6)列了四个待决策。本次增强会放大其中两个的权重: 第一,**私有化部署优先级**会因 EH-7(个人化与交易数据)而显著上升——一旦要承载用户交易明细,数据不出域几乎是硬约束,这会把 M6 的私有化方案往前拉。第二,**免费数据源合规边界**会因 EH-4(浏览器沙箱抓取)而更尖锐——抓取网页比调用聚合库的服务条款风险更高,法务边界需在 EH-4 落地前明确。另外两个待决策(商业模式定价、DCF 系统建议值责任)不受本次增强直接影响,维持原决策窗口。 --- ## 5. 一句话总结 InvesResearch 已经把"如何严谨地跑完一次深度调研"设计得很好;这一版增强要补的,是"如何让投研工作台天天被用起来"——常驻 agent、活工作区、主动送达、自主抓数、用户自定义框架、复杂任务拆解、个性化蒸馏。补齐之后,它就从一个优秀的**报告生成器**,变成一个分析师愿意常开、并能为之编程的**投研操作系统**。 --- ## 附录:增强来源对照 | 编号 | 一线实战形态 | 一句话价值 | |---|---|---| | EH-1 | 定时任务 + 日报(高频使用);未抓到则延后重试 | 常驻、定时、低干预是日常粘性主来源 | | EH-2 | 在线表格框选区域、右键加入对话,大白话改数、预测填充 | AI 操控活表格 = 真正融入工作流 | | EH-3 | 生成结果推送飞书/微信,推增量变化而非全量 | 没有送达,定时任务只是空跑 | | EH-4 | 沙箱浏览器抓某细分网页数据、查编码、汇率换算 | 数据覆盖从"接了哪些库"扩到"能点开的任何页面" | | EH-5 | 把分析框架(多动作组合识别、评分卡)做成 Skill | 把分析师的脑子写成可运行可迭代的 Skill | | EH-6 | 复杂任务拆成多个子能力各写中间产物,再去重合并 | 拆解治"AI 偷懒",对应子代理上下文隔离 | | EH-7 | 上传交易明细复盘,产出评分卡,可隐式调用 | 系统了解你,建议才有启发性;蒸馏需 X+Y+过程 | --- > **免责声明** — 本增强文档基于 InvesResearch 现有 PRD v1.0 / 工程 PRD v2.0 / 路线图 v1.0 与一线投研实践观察整理,所有增强需求需经团队评审与可行性确认后方可纳入开发计划。所涉投研能力仅用于研究效率提升,不构成任何投资建议。