问题
定时任务执行完成后，如果它把结果通过 Feishu/IM connector 发给用户，用户确实能收到消息。
但这条“GA 主动发出的定时任务结果”没有自动进入当前聊天会话历史。结果是：用户马上继续问 GA “刚刚日报里说了什么？”或“继续你刚才的定时任务结论”，GA 会像没见过自己刚发的内容一样，需要重新读文件或重新推断。
这会让定时任务看起来像是另一个孤立进程在说话，而不是当前 GA 会话的一部分。
复现方式
- 配置一个定时任务，例如学习日报 / post-market report。
- 让任务完成后通过 Feishu/IM connector 把报告发给用户。
- 用户在同一个聊天入口里继续问：
- “你刚刚发的日报里最重要的 3 点是什么？”
- “继续刚才那个定时任务的结论。”
- GA 不能自然引用刚刚发出的内容，表现得像当前会话历史里没有这条消息。
期望行为
当定时任务主动向某个聊天入口发送用户可见消息时，这条 outgoing message 应该进入一个可被后续对话读取的上下文里。
可以是以下任一实现方式：
- 如果能识别
chat_id / open_id / thread，则把定时任务输出追加到对应 session 的短期 history。
- 如果无法绑定具体 chat，则至少写入一个 recent scheduled outputs / notification journal，并在下一轮用户对话中作为 recent context 注入。
- 如果定时任务生成了报告文件，也可以把“报告路径 + 摘要 + 发出的正文”作为一条 scheduled event 记录。
核心目标是：GA 应该知道自己刚刚主动通知过用户什么。
当前代码层面的线索
从当前实现看，scheduler 和聊天前端之间似乎没有这层桥接：
launch.pyw 使用 agentmain.py --reflect reflect/scheduler.py 启动 scheduler。reflect/scheduler.py 到点后返回一段定时任务 prompt。agentmain.py 的 reflect 模式里通过 agent.put_task(task, source='reflect') 执行，并把结果写到 reflect log。- Feishu/IM 前端自己的
agent.history 只会自然记录用户从该前端发起的会话。
- 如果定时任务内部通过 connector 发消息给用户，这个发送行为不会同步回当前前端 session history。
所以消息对用户是可见的，但对后续聊天上下文不可见。
与已有 issue 的关系
为什么重要
定时任务通常会承担“日报、市场报告、学习简报、巡检报告”这类连续工作。如果 GA 发完报告后自己马上忘记报告内容，用户就很难围绕定时任务继续追问，也会破坏“这是同一个 agent 在持续工作”的体验。
问题
定时任务执行完成后，如果它把结果通过 Feishu/IM connector 发给用户，用户确实能收到消息。
但这条“GA 主动发出的定时任务结果”没有自动进入当前聊天会话历史。结果是：用户马上继续问 GA “刚刚日报里说了什么？”或“继续你刚才的定时任务结论”，GA 会像没见过自己刚发的内容一样，需要重新读文件或重新推断。
这会让定时任务看起来像是另一个孤立进程在说话，而不是当前 GA 会话的一部分。
复现方式
期望行为
当定时任务主动向某个聊天入口发送用户可见消息时，这条 outgoing message 应该进入一个可被后续对话读取的上下文里。
可以是以下任一实现方式：
chat_id/open_id/ thread，则把定时任务输出追加到对应 session 的短期 history。核心目标是：GA 应该知道自己刚刚主动通知过用户什么。
当前代码层面的线索
从当前实现看，scheduler 和聊天前端之间似乎没有这层桥接：
launch.pyw使用agentmain.py --reflect reflect/scheduler.py启动 scheduler。reflect/scheduler.py到点后返回一段定时任务 prompt。agentmain.py的 reflect 模式里通过agent.put_task(task, source='reflect')执行，并把结果写到 reflect log。agent.history只会自然记录用户从该前端发起的会话。所以消息对用户是可见的，但对后续聊天上下文不可见。
与已有 issue 的关系
为什么重要
定时任务通常会承担“日报、市场报告、学习简报、巡检报告”这类连续工作。如果 GA 发完报告后自己马上忘记报告内容，用户就很难围绕定时任务继续追问，也会破坏“这是同一个 agent 在持续工作”的体验。