一、项目整体进度概述

前一阶段主要是让各模块独立跑通，随后逐渐转向“让模块更深、让系统更稳、让链路更通”；上一阶段则进一步完成了新闻资讯采集分析、用户画像、金融知识问答、个性化策略生成、深度回测和 AI 投研报告输出等核心链路的初步打通。也就是说，项目已经不再只是几个功能模块的简单堆叠，而是开始形成一个较完整的数智金融辅助决策平台。

本阶段的主要任务，可以概括为“联调收尾、体验优化、能力闭环”。一方面，各成员继续完善自己负责的核心模块；另一方面，团队也开始重点处理合并代码后暴露出来的接口契约、数据格式、前后端交互、长任务超时、资源消耗、用户体验等问题。相比之前“功能能不能跑起来”，本阶段更加关注“用户是否能稳定使用”“模块之间是否能顺畅协作”“系统输出是否可信且可解释”。

从整体上看，主要推进策略智能体流水线的二次集成与联调修复；围绕 AstrBot 平台适配器、适配器调试和用户偏好画像模块继续深入；重点优化金融知识问答模块的会话管理能力；对新闻解读模块进行了新闻源修复、按需解析、首页搜索排序和容错机制升级。四个方向虽然各自独立，但最终都服务于同一个目标：让系统从“功能集合”进一步走向“可持续使用的智能金融平台”。

---

二、策略智能体流水线二次集成与改进（施煌威）

近期的工作主要集中在策略智能体流水线的二次集成与系统级问题修复。本阶段并没有单纯新增一个更大的模型或更复杂的 Agent，而是围绕真实联调场景中暴露的问题，对资讯模块、市场报告、事件分析、PDF 导出、多空辩论、策略生成和个人主页等多个用户高频路径进行了集中修复。其博客中提到，本轮开发集中在资讯模块、投研报告体验和个人主页，属于典型的集成期问题：单点功能各自能跑，但串起来后暴露出接口契约、数据迁移和用户体验断层。

首先是新闻模块合并后的数据源问题。代码合并后，新闻抓取出现东方财富返回非标准状态、财联社接口不可用、前端新闻列表为空等问题。排查后发现，东方财富接口实际返回 JSONP 格式，不能直接按普通 JSON 解析；财联社接口则已经变为需要签名参数的请求方式，原有调用方式无法继续使用。对此，在集成时配合新闻模块做了适配：为东方财富增加 JSONP 类型解析和 Referer 配置，将财联社源替换为新浪财经频道，同时保留失败源的退避和空列表返回，避免单个新闻源异常拖垮整批抓取任务。

其次是市场报告与事件分析接口联调。市场报告服务本身已经存在，但路由层没有暴露 /market/report，导致前端请求时出现 404。修复后，后端补齐了报告路由及子接口，使前端能够正常请求市场报告数据。事件分析方面，主要问题出在 Flutter Web 的访问地址与 API 地址不一致，以及 LLM 分析耗时较长导致默认超时不足。针对这些问题，系统将 Web 端 baseUrl 改为与页面 host 保持一致，并为 /news/analyze 设置了 120 秒专用超时，从而保证长耗时分析任务不会被前端过早中断。

在投研报告体验上，还修复了 PDF 收益曲线与 App 内曲线方向相反的问题。该问题的根源并不是回测数据错误，而是 PDF 画布坐标系与前端图表坐标系不同，导致收益曲线在 PDF 中被视觉翻转。修复后，PDF 纵轴映射改为自下而上，同时在多标的回测场景中优先选择与当前 symbol 对齐的曲线，避免指标和图表语义不一致。这个改动虽然看似细节，但对于量化产品非常重要，因为图表一旦和指标不一致，会直接影响用户对回测结果的信任。

此外，策略智能体也完成了辩论模式的统一。此前辩论页已经支持简单多空辩论和 TradingAgents 进阶辩论，但策略生成流水线中只能调用简单辩论，导致同一业务能力在不同入口表现不一致。本轮修改后，后端请求体和流水线 payload 增加 debate_mode 字段，策略页前端也增加“简单 / 进阶”分段按钮，使用户在生成策略时也可以选择不同深度的辩论模式。这样一来，策略生成、回测分析和多智能体辩论的链路更加统一。

最后，个人主页也进行了体验层面的修复，包括深色卡片中昵称和邮箱颜色对比度不足、头像无法上传等问题。系统新增头像上传接口、静态头像目录和用户头像字段持久化，前端则接入图片选择器，实现点击头像上传的交互。至此，策略流水线、新闻模块、市场报告、PDF 导出、多空辩论和个人信息页等多个模块之间的协作关系进一步稳定。

---

三、AstrBot 平台适配器与用户偏好画像模块推进（王宇轩）

近期的工作可以分为三条主线：第一，开发用于接入 AstrBot 的 HTTP 平台适配器；第二，解决适配器运行中的生命周期和响应完整性问题；第三，重新拆解用户偏好画像模块，使其职责更加清晰。

在平台适配器方面，目标是让金融 App 可以通过标准 HTTP API 或 SSE 流式接口与 AstrBot 交互。由于 AstrBot 原本处理的是内部消息事件，而金融 App 传入的是 HTTP 请求，因此适配器首先要完成数据类型转换：将 HTTP 请求元信息封装为 HTTPRequestData，再将请求体拆解为 AstrBot 可理解的消息组件，最后组装成 AstrBot 内部消息并提交到事件总线。

为了让异步事件处理结果能够返回给外部 App，适配器采用了 event_id + Future + pending_responses 的机制。每次 HTTP 请求进入后，系统都会生成唯一事件 ID，并创建一个 Future 作为“等待响应的盒子”；当 AstrBot 处理完事件后，再通过 event_id 找到对应的 Future 并写入结果。
这样就形成了“外部 App → HTTPAdapter → AstrBot 事件系统 → LLM/插件处理 → HTTPAdapter → 外部 App”的完整闭环。

适配器还提供了较完整的使用能力，包括标准 HTTP 请求响应、SSE 流式响应、普通模式和流式模式、多种消息入参格式、Bearer Token 鉴权、CORS 跨域配置、请求超时控制和健康检查接口等。这使得 AstrBot 不再只是一个独立的聊天机器人运行平台，而是可以作为金融 App 后端智能体能力的一部分被接入。

在调试过程中，重点解决了两个关键问题。第一个是启动适配器后无法通过 Ctrl+C 正常关闭程序。问题根源在于 Hypercorn 服务生命周期没有和 AstrBot 插件生命周期正确绑定。修复方案是在适配器中新增 shutdown_event，并将其作为 Hypercorn 的关闭触发器，同时在 terminate 方法中停止运行标志、触发 shutdown、取消后台任务、清理 pending responses，并调用父类终止方法，实现适配器的优雅退出。

第二个问题是 AstrBot 可能多次调用 send() 返回消息，如果在每次 send() 时立即填充 Future，金融 App 接收到的内容就可能不完整。因此，将 send() 改为只缓存消息链数据，真正返回结果的动作延后到 send_response() 中完成。同时，他设计了三种收尾判断机制：LLM assistant 回复后的收尾、插件直接返回场景下的延后收尾，以及异常退出时主动补上结束信号，从而避免 HTTP 请求或 SSE 流卡住。

在用户偏好画像模块方面，对前期方案进行了反思。原先的“用户偏好智能画像模块”实际上混合了多层记忆、用户画像和自我优化三个功能，不符合单一职责原则。因此，本阶段先将重点收缩为“用户画像”本身：根据用户与 AstrBot 的聊天记录、收藏帖子、自选股列表和策略表，抽取用户的风险等级、偏好风格、厌恶风格、偏好行业、回避行业、资金偏好、回撤容忍度和决策风格等画像字段。

为保证画像生成上下文干净，计划使用一个独立的 AstrBot 实例专门负责用户画像分析，而不是直接复用主聊天实例。App 端在触发画像分析时，会收集聊天记录、收藏帖子、自选股、策略反馈等数据传入画像分析接口；画像返回后，再更新用户画像表并在前端可视化展示。

此外，用户画像还将反向影响策略生成。无画像时，系统可以为某只股票生成低、中、高、极高四类风险策略；有画像时，则额外生成一个“专属策略”，并允许用户对策略进行 1 到 10 分评分。评分结果再进入策略表，成为后续更新用户画像的重要反馈数据。这样，用户画像不再只是静态标签，而是可以在“策略生成—用户反馈—画像更新”的循环中逐步演化。

---

四、金融知识问答模块会话管理优化（邱珂）

近期主要优化了金融知识问答模块的会话管理能力。此前，金融知识问答模块已经完成了 RAG 检索增强问答、分级回答、结构化输出等核心功能；但从用户体验角度看，传统问答系统如果只返回一段文本，就会存在历史记录难管理、重点信息难提取、优质问答难收藏、错误回答难反馈等问题。上一阶段的项目博客中也已经将“新增会话管理、问答收藏、质量反馈、长期记忆功能”列为后续优化方向，本阶段正是对这些问题的具体落地。

首先是回答结构的进一步优化。将问答结果拆解为主回答、核心要点、相关术语、建议追问、置信度、难度等级和回答风格等字段。这样用户不需要自己从长文本中提炼重点，而是可以直接看到核心结论、相关概念和下一步学习方向。尤其对于金融知识学习场景来说，相关术语和建议追问能够帮助用户建立知识网络，而置信度字段则能提示用户回答的可靠程度。

其次是历史会话列表与智能命名功能。系统采用分层存储架构，每个会话独立管理消息、状态和元数据。用户可以通过 AppBar 中的历史会话按钮打开底部弹窗，查看不同会话的标题、难度等级、问答数量和更新时间，并可以快速切换会话。会话排序规则为置顶会话优先，其余会话按更新时间倒序排列，保证用户最常使用或最新使用的内容优先展示。

智能命名方面，系统采用“首问命名”策略：当用户在一个空会话中首次提问时，系统根据第一个问题生成会话标题。如果问题较短，就直接作为标题；如果问题较长，则截取前若干字符并添加省略号。这个功能虽然简单，但可以明显提升历史会话的可读性，避免所有会话都显示为“新的问答”。

在会话级操作方面，系统支持收藏、删除和置顶。会话数据模型中增加了会话 ID、难度等级、标题、创建时间、更新时间、是否收藏、是否置顶、消息列表、收藏问答 ID 和问答反馈等字段。删除会话时，系统还会自动切换到同难度下的最新会话，避免当前会话被删除后界面处于无状态。

在问答级操作方面，用户可以收藏单条问答，也可以删除某组问答。删除时系统会同时移除关联的用户问题和 AI 回答，并清理对应的收藏和反馈信息。问答气泡底部新增了收藏、反馈和删除按钮，用户可以直接在具体问答上完成操作，而不必回到会话列表层级。

质量反馈机制则允许用户将某条问答标注为“正确”或“错误”。该反馈状态可以切换：再次点击已标注按钮可以取消标注，点击另一种反馈则会切换状态。所有会话和问答级数据都会实时保存到 SharedPreferences，并通过序列化和反序列化模型进行恢复。总体来看，该模块已经从“能回答问题”进一步升级为“能管理学习过程、沉淀优质内容、收集用户反馈”的知识学习工具。

---

五、新闻解读模块：新闻源修复、按需解析与首页改版（李娅宁）

近期主要围绕新闻解读模块进行稳定性和体验优化。本阶段的问题来源于小组合并代码后的实际联调：新闻模块原本已经具备定时抓取、LLM 分析和市场报告能力，但合并后新闻数量骤降，前端列表只剩少量新闻，甚至出现刷新后仍无法恢复的情况。排查后发现，东方财富和财联社两个源完全失效，其他源虽然仍能抓取，但过滤后数量明显不足。

针对新闻源故障，对数据源解析方式进行了重构。东方财富的问题在于返回格式是 JSONP，而不是标准 JSON；财联社则因为接口变更为需要签名认证的 POST 请求，原有简单请求方式无法通过验证。修复方案是在数据源配置中新增 response_type 字段，使系统支持 json、jsonp、html、text 等多种响应类型；东方财富通过正则提取 JSONP 包裹内容后再解析；财联社由于签名成本较高，暂时替换为新浪财经频道。同时，不同数据源可以配置独立请求头，避免所有源共用一套请求配置导致解析失败。

在更新机制上，新闻模块从原本只有五分钟自动抓取，扩展为“自动更新 + 手动更新”双模式。前端新闻列表页增加刷新按钮，用户点击后会立即触发一次后端抓取，不必等待下一个定时周期。手动更新和自动更新共用同一套抓取逻辑，同时手动触发后会重置自动更新计时器，避免短时间内重复抓取。

容错机制也得到了升级。之前虽然单个源失败不会中断整轮抓取，但多个源同时异常时，新闻列表仍可能急剧缩水甚至空白。本轮修复后，单个源失败会被降级记录为 warning；所有源失败时，系统保留上一轮数据，并返回 stale_data 标记，前端可以提示用户“数据可能不是最新的”。统计接口中还增加了各源健康状态字段，便于后续排查数据源问题。修复后，新闻列表恢复到每次约三十条的稳定水平。

另一个重要优化是将新闻分析从“全量解析”改为“按需解析”。原先每五分钟抓取一批新闻后，系统会自动对所有新闻调用 LLM 进行分析；但实际使用中，用户真正点开的新闻只占一小部分，大量 token 消耗在未被阅读的新闻上。优化后，爬虫抓取时只做去重、过滤和分类，不立即调用 LLM；新闻存库时 is_analyzed 默认为 false；用户进入详情页时，如果新闻尚未解析，再调用 LLM 并将结果缓存。该改动使 token 消耗降低约 80%，同时已解析新闻再次打开时可以直接从数据库读取结果。

在前端体验上，新闻首页新增了搜索栏、排序选择器、情感倾向筛选和新闻分类筛选。用户可以按关键词模糊搜索，也可以按最新发布、热度优先或影响优先进行排序。后端对应新增 /news/search 接口，支持关键词、情感、分类、排序方式、分页等组合查询。这样新闻模块不再只是按时间展示资讯流，而是能够支持用户主动检索和筛选感兴趣的金融信息。

阶段性来看，新闻模块已经完成新闻源修复、多协议解析、手动刷新、按需解析、解析状态标识、搜索排序、容错机制和新闻首页改版等多个功能。这些改动的共同目标是让系统更聪明地使用资源：按需解析节省 token，手动更新增强用户控制权，搜索排序提高信息发现效率，多协议适配和容错机制则提升数据源异常时的系统韧性。

---

六、下一阶段工作计划

下一阶段，团队可以重点推进以下几个方向。

第一，继续强化跨模块联调。

当前各模块已经基本具备独立可用能力，但仍需要进一步打通新闻行为到用户画像、用户画像到策略生成、知识问答到策略解释、策略反馈到画像更新等关键链路。尤其是用户画像模块和新闻模块之间的数据流，需要从设计走向稳定实现。

第二，完善长任务与异步任务体验。

策略生成、进阶辩论、新闻 LLM 解析、画像分析等任务都可能耗时较长，后续应统一长任务状态管理，包括任务进度、轮询频率、超时提示、失败重试和结果缓存，避免用户在等待过程中误以为系统卡死。

第三，提升数据可信度和解释一致性。

PDF 报告曲线、回测指标、新闻影响评分、用户画像字段、策略推荐理由等都必须保持语义一致。后续可以增加更多自动校验逻辑，例如报告导出前检查图表方向、指标单位、标的名称、时间范围是否一致。

第四，继续优化用户体验和界面表达。

目前多个模块已经从“能用”走向“好用”，但仍有提升空间。例如新闻首页可以增加收藏历史，知识问答可以引入更长期的跨设备持久化，用户画像可以展示画像变化过程，策略模块可以展示不同风险策略之间的对比。

第五，开展小组整体测试。

项目已经进入集成后期，接下来需要针对真实用户路径进行端到端测试，例如“阅读新闻—生成画像—提出策略—执行回测—查看报告—反馈评分”这一完整流程，检查是否存在接口断点、数据缺失、状态不同步或前端展示异常。