想讨论的问题
这个 issue 想讨论的是：在 IM 前端场景下，GenericAgent 是否需要更明确的“会话边界”定义。
这里的“会话边界”主要分成两层，它们不一定要绑定为同一个设计决定：
- UI / 容器层：聊天软件界面里，是否尽量把单个任务收拢到独立容器中（例如 thread / topic / reply-in-thread / 单卡片持续更新 / 单条消息编辑），避免多个不相干任务都堆在同一个主聊天流里。
- 短期上下文层：不同 chat / DM / thread / topic 之间，原始 prompt / response / 临时上下文是否应当隔离，避免一个会话里的短期上下文直接污染另一个会话。
这和长期记忆（L1/L2/L3 等）是否跨会话共享不是同一个问题。长期记忆可跨会话共享完全可以继续作为项目特性；这里更想讨论的是 IM 前端的短期会话边界。
为什么值得讨论
对于单用户、单入口、长期持续对话的场景，当前“单 agent 多入口”风格可能是合理取舍。
但在 IM 场景里，经常会出现：
- 多个群 / 私聊同时使用同一个 bot
- 同一群里多个互不相关的任务穿插进行
- 平台本身支持 thread / topic / reply-in-thread，但前端未充分利用
- 用户希望长期记忆保留，但不希望 A 会话的原始上下文直接进入 B 会话
这时，长期记忆共享 与 短期原文上下文隔离 往往可以同时成立，而且后者会明显影响使用体验与可预期性。
当前实现中容易让人疑惑的点
阅读当前代码时，IM 前端整体上更像是“多个消息入口连接到同一个 agent 实例”，而不是“每个 chat/thread 一个独立短期上下文”。
例如：
- 多个前端脚本里都是单例
agent = GeneraticAgent()
agent.history / backend history 看起来是前端级共享的/new 更像是在清当前前端的共享上下文，而不是只清当前 chat / thread
如果这正是项目有意为之的设计，那么也许值得在文档里更明确地说明 tradeoff；如果不是，也许可以讨论是否需要把 IM 前端的 session boundary 做得更清晰。
这会带来的两个不同层面的问题
1) UI / 聊天界面层
当前有些前端已经在尽量减少刷屏：
- Feishu 的卡片 patch / collapsible panel
- Telegram 的单消息编辑 / draft 风格输出
这些都很有帮助。不过它们和“独立 thread / 独立话题 / 独立会话容器”仍然不是一回事。
也就是说，减少刷屏 已经在做，但 按任务/话题进行原生容器隔离 还有进一步讨论空间。
2) 短期上下文 / raw context 层
更关键的是：如果同一个前端进程里，先在会话 A 进行了很多与任务无关的尝试、上下文铺垫或长任务交互，再在会话 B 发起另一个任务，那么 B 是否会继续带着 A 的原始上下文运行？
如果答案是“会”，那在 IM 场景中可能出现：
- 一个群里的长任务残留上下文影响另一个群的简单问答
- 私聊里的随手试验影响正式群里的任务执行
- 不同话题本来应当像不同 workspace，但短期上下文实际上发生串联
这并不等于长期记忆设计有问题，而是 短期上下文边界 可能与 IM 用户的直觉不一致。
一个可能的方向（供讨论，不是唯一方案）
A. 明确区分“长期记忆共享”与“短期上下文隔离”
可以考虑把两者显式拆开：
- 长期记忆：继续全局共享
- 短期上下文：按 session_key 分桶
session_key 可以按平台能力决定，例如：
- Feishu:
thread_id / chat_id / open_id
- Telegram:
message_thread_id / chat_id / user_id
- QQ / WeCom / DingTalk / WeChat: 至少按
chat_id / user_id
这样不一定会改变 GenericAgent 的记忆哲学，但能让 IM 前端的短期行为更可预期。
B. UI 层尽量利用平台已有容器
如果平台支持，可以考虑优先使用：
- thread
- topic
- reply-in-thread
- 单卡片持续 patch
- 单消息持续 edit
目标不一定是所有平台都完全一致，而是尽量让“一个任务 = 一个主要容器”，减少互不相关内容混在一个主聊天流里。
这和 #216（multi-worker / control-message priority）有关系，但不完全相同：
两者如果一起考虑会更完整，但也可以分别讨论。
如果未来要改，哪些结果会比较有价值
即使不一步到位，下面这些结果也会很有帮助：
如果项目设计上本来就更偏向“单 agent 多入口共享短期上下文”，也欢迎直接说明当前的设计取舍。对使用者而言，明确这一点本身就很有价值。
想讨论的问题
这个 issue 想讨论的是：在 IM 前端场景下，GenericAgent 是否需要更明确的“会话边界”定义。
这里的“会话边界”主要分成两层，它们不一定要绑定为同一个设计决定：
这和长期记忆（L1/L2/L3 等）是否跨会话共享不是同一个问题。长期记忆可跨会话共享完全可以继续作为项目特性；这里更想讨论的是 IM 前端的短期会话边界。
为什么值得讨论
对于单用户、单入口、长期持续对话的场景，当前“单 agent 多入口”风格可能是合理取舍。
但在 IM 场景里，经常会出现：
这时，长期记忆共享 与 短期原文上下文隔离 往往可以同时成立，而且后者会明显影响使用体验与可预期性。
当前实现中容易让人疑惑的点
阅读当前代码时，IM 前端整体上更像是“多个消息入口连接到同一个 agent 实例”，而不是“每个 chat/thread 一个独立短期上下文”。
例如：
agent = GeneraticAgent()agent.history/ backend history 看起来是前端级共享的/new更像是在清当前前端的共享上下文，而不是只清当前 chat / thread如果这正是项目有意为之的设计，那么也许值得在文档里更明确地说明 tradeoff；如果不是，也许可以讨论是否需要把 IM 前端的 session boundary 做得更清晰。
这会带来的两个不同层面的问题
1) UI / 聊天界面层
当前有些前端已经在尽量减少刷屏：
这些都很有帮助。不过它们和“独立 thread / 独立话题 / 独立会话容器”仍然不是一回事。
也就是说，减少刷屏 已经在做，但 按任务/话题进行原生容器隔离 还有进一步讨论空间。
2) 短期上下文 / raw context 层
更关键的是：如果同一个前端进程里，先在会话 A 进行了很多与任务无关的尝试、上下文铺垫或长任务交互，再在会话 B 发起另一个任务，那么 B 是否会继续带着 A 的原始上下文运行？
如果答案是“会”，那在 IM 场景中可能出现：
这并不等于长期记忆设计有问题，而是 短期上下文边界 可能与 IM 用户的直觉不一致。
一个可能的方向（供讨论，不是唯一方案）
A. 明确区分“长期记忆共享”与“短期上下文隔离”
可以考虑把两者显式拆开：
session_key 可以按平台能力决定，例如：
thread_id/chat_id/open_idmessage_thread_id/chat_id/user_idchat_id/user_id这样不一定会改变 GenericAgent 的记忆哲学，但能让 IM 前端的短期行为更可预期。
B. UI 层尽量利用平台已有容器
如果平台支持，可以考虑优先使用：
目标不一定是所有平台都完全一致，而是尽量让“一个任务 = 一个主要容器”，减少互不相关内容混在一个主聊天流里。
与 #216 的关系
这和 #216（multi-worker / control-message priority）有关系，但不完全相同：
两者如果一起考虑会更完整，但也可以分别讨论。
如果未来要改，哪些结果会比较有价值
即使不一步到位，下面这些结果也会很有帮助：
/new只重置当前 session，而不是整个前端当前共享上下文如果项目设计上本来就更偏向“单 agent 多入口共享短期上下文”，也欢迎直接说明当前的设计取舍。对使用者而言，明确这一点本身就很有价值。