1. 三层概念
session：会话上下文，保存这个agent记住了什么、当前任务推进到哪thread：消息容器/对话分支，决定聊天界面里消息挂在哪条线workspace：文件工作区，决定这个会话能看到和修改哪些文件
1.1. session
负责：
- 保存历史消息
- 保存任务状态
- 保存局部上下文
补充理解： persistent session= 这个脑子下次还在- 非persistent session = 做完就散
1.2. thread
本质是“聊天壳子”，负责：
- 决定消息显示在什么地方
- 决定消息挂载在哪条会话线 / 对话分支
- 承担一部分 UI 和路由职责
补充理解： - 一个
thread往往可以绑定一个session - 但两者不是同义词
session管上下文，thread管消息展示和归属
1.3. workspace
本质是“桌面”，它负责：
- 提供文件读写范围
- 提供命令执行上下文
- 决定会话能看到和修改哪些文件
补充理解： - 同一个
session可以长期待在同一个workspace - 不同
session也可以共享一个workspace
1.4. 三、类比理解
可以这样记：
session= 工程师的大脑thread= 这位工程师对应的工单 / 聊天窗口workspace= 他的办公桌repo= 桌上的项目文件夹（Git 仓库）
1.5. 四、它们之间的关系
1.5.1. session 和 thread
常常一对一绑定，但本质不同
session管上下文thread管消息展示和路由
1.5.2. session 和 workspace
一个
session要落在某个workspace上做事但
session是否 persistent，不等于workspace是否独立
1.5.3. workspace 和 repo
workspace是更大的容器repo是workspace里的一个或多个 Git 仓库
1.6. 五、常见组合
1.6.1. 组合 1
同一个
thread同一个
session同一个
workspace同一个
repo
适用：
- 最普通的单项目持续协作模式
1.6.2. 组合 2
不同
thread不同
session同一个
workspace同一个
repo
适用：
- 同一项目下并发子任务
风险：
- 都在改同一套文件，容易冲突
1.6.3. 组合 3
不同
thread不同
session不同
workspace同一个
repo的不同副本
适用：
- 强隔离并行开发
特点：
- 最像多个独立工程师各自拉一份工作副本
1.6.4. 组合 4
不同
session不同
workspace不同
repo
适用：
- 完全不同项目并行推进
1.7. 六、几个容易混淆的点
persistent session不等于独立workspacethread-bound不等于独立 bot同一个
workspace也不等于同一个session同一个
repo可以被多个session同时操作，但容易打架
1.8. 七、实用判断法
当你要设计协作方式时，可以先问自己四个问题：
我要不要保留上下文？→ 看
session我需不需要单独的聊天入口？→ 看
thread我需不需要文件隔离？→ 看
workspace我是不是在同一个 Git 项目里干活？→ 看
repo
1.9. 八、面向 Telegram 私聊的实战建议
在 Telegram 私聊这种没有天然 thread 的环境里，比较稳的做法是：
主会话固定一个
session后台任务开多个独立
session默认共享主
workspace只做轻量任务真正会大量改代码的并行任务，尽量给独立
workspace最终还是由主会话统一汇总输出
1.10. 九、一句话总结
session管脑子thread管聊天壳workspace管桌子repo管项目
评论