@jennie-shawn/starwork 0.1.0-alpha.2 → 0.1.0-alpha.21

package/docs/multiagent/01-codex-session-capabilities-and-starwork-implications.md

@@ -0,0 +1,280 @@
+# Codex 会话能力调研与 StarWork Multiagent 启发
+
+## 基本信息
+
+- 日期：2026-06-01
+- 优先级：高
+- 目标：梳理 Codex 最近暴露出的会话、线程、后台任务和工作树能力，并判断它们对 StarWork `multiagent` / Agent Lanes 的产品启发。
+- 结论状态：可作为 StarWork multiagent 课程交付前的核心输入。
+
+## 调研假设
+
+1. 这里的 Codex 指 OpenAI Codex CLI / Codex Desktop / Codex App 这一组能力，不只指终端里的单次 CLI 会话。
+2. “这两天更新的会话能力”一部分来自公开文档和 changelog，一部分来自当前 Codex App 运行时实际暴露的工具接口。后者应视为产品方向信号，不应直接当成稳定公开 API。
+3. StarWork 不应复制 Codex 的宿主能力，而应把这些能力吸收为跨 Agent 的协作协议、命名、索引和交接层。
+
+## 当前 StarWork Multiagent 基线
+
+StarWork 当前已经实现的 multiagent 不是“启动多个模型”，而是 Agent Lanes 协作层：
+
+- `product/core/agent-lanes-spec.md` 定义 lane registry、session binding、write scope、worklog、lane workspace、shared context。
+- `product/cli/src/cli.js` 已实现 `starwork multiagent init/add/bind/release/status/share`。
+- `product/skills/starworkMultiagent/SKILL.md` 把自然语言“登记当前会话为常用智能体”“创建 Agent 团队”“发送跨 lane 指令”转换为安全的 Skill 流程。
+- Codex App 正常路径中，Skill 直接调用 `create_thread`、`send_message_to_thread`、`read_thread`、`set_thread_title`、`set_thread_pinned`、`set_thread_archived`。
+- CLI 只记录 StarWork 项目事实源，例如 lane、binding、shared outputs 和 `request record`。
+
+这意味着 StarWork 的关键价值不是替代 Codex 会话管理，而是让不同宿主里的会话获得稳定职责、写入边界、共享索引和可交接上下文。
+
+## Codex 新会话能力清单
+
+### 1. 线程成为可管理对象
+
+当前 Codex App 运行时已暴露后台线程工具：
+
+| 能力 | 运行时接口 | 对用户意味着什么 |
+|---|---|---|
+| 创建线程 | `create_thread` | 可从当前项目或项目外新建一个后台 Codex 工作会话。 |
+| 列出线程 | `list_threads` | 可按 query 找到近期线程，而不是只能靠左侧 UI 人工查找。 |
+| 读取线程 | `read_thread` | 可在不打开线程的情况下读取最近状态和 turn 摘要。 |
+| 继续线程 | `send_message_to_thread` | 可给已有线程发送后续 prompt，使它继续工作。 |
+| 改名线程 | `set_thread_title` | 可把线程标题同步成职责名。 |
+| pin / unpin | `set_thread_pinned` | 可把长期职责线程固定在会话列表。 |
+| archive / unarchive | `set_thread_archived` | 可把过期或已交接线程收纳起来。 |
+
+这组能力说明 Codex 正在从“当前聊天”走向“可编排的线程池”。对 StarWork 来说，`session` 不再只是一个字符串，而是可以被查找、命名、继续、归档和置顶的宿主对象。
+
+### 2. 项目线程可以选择 local 或 worktree 环境
+
+`create_thread` 的 project target 支持：
+
+- `environment: { type: "local" }`
+- `environment: { type: "worktree", startingState: ... }`
+
+这和 OpenAI Codex App 的 worktrees 文档方向一致：Codex App 支持在 project 内用 local、worktree、cloud 等环境承载不同任务，并把工作树作为隔离并行开发的基础。
+
+对 StarWork 的启发是：lane 的 `write_scope` 只解决文件边界，worktree 解决 Git 工作副本边界。课程里应明确区分：
+
+- Agent Lanes：谁负责什么、在哪里记录、哪些输出给谁看。
+- Worktree：这个职责位是否需要隔离代码改动。
+- Thread：某个职责位当前由哪个 Codex 会话接手。
+
+### 3. 后台线程可以被继续，而不必重新打开上下文
+
+`send_message_to_thread` 可以向已有线程发送 follow-up prompt，`read_thread` 可以查看它最近状态。这意味着用户或主协调 Agent 可以把一个 lane 看作“可唤醒的长期智能体”。
+
+StarWork 当前 `bind` 只记录 `current_session`，还没有“唤醒 lane”的命令。Codex 的新能力提示 StarWork 可以在 v0.2 设计：
+
+```text
+starwork multiagent resume <lane> --message "<prompt>"
+```
+
+但 v0.1 课程中不要承诺自动唤醒。更稳妥的口径是：StarWork 已经能登记和命名职责线程；Codex 新能力让未来的 lane resume 成为可行方向。
+
+### 4. pin / archive 让会话生命周期变得可产品化
+
+Codex 现在不仅能重命名线程，还能置顶和归档线程。对应到 StarWork：
+
+- `bind`：把线程设为某 lane 当前负责人。
+- `pin`：该 lane 是项目长期角色，建议固定在宿主会话列表。
+- `release`：解除 lane 当前绑定。
+- `archive`：该线程已完成交接，不再作为当前职责位出现。
+
+这给 StarWork 一个很清晰的生命周期模型：
+
+```text
+unbound lane
+  -> bind thread
+  -> optionally rename + pin
+  -> worklog/share outputs
+  -> release
+  -> optionally archive old thread
+```
+
+当前 StarWork 只做到了 bind / release / rename。置顶和归档可以进入后续 Codex adapter 增强，但不应进入 Core 必选协议。
+
+### 5. Automations 把“会话”扩展成“定时或心跳工作”
+
+当前 Codex App 运行时还暴露 `automation_update`：
+
+- cron automation：针对 workspace 的定期后台任务。
+- heartbeat automation：附着在当前 thread 上，稍后唤醒继续对话。
+
+这对 StarWork 的 multiagent 课程有两个启发：
+
+1. 长期 lane 不一定要一直有人盯。某些 lane 可以由自动化定期巡检，例如 weekly research、CI follow-up、反馈收集。
+2. StarWork 应避免把自动化塞进 Agent Lanes v0.1。Agent Lanes 先解决职责、边界和交接；自动化属于更高层的调度能力。
+
+建议课程里用一句话讲清楚：StarWork multiagent 是“多会话协作协议”，不是“自动调度系统”。
+
+### 6. Sub-agent 工具与 StarWork Lanes 是两层
+
+当前运行时还暴露 `spawn_agent`、`send_input`、`wait_agent`、`close_agent`、`resume_agent`。这些是单次任务内的子 Agent 分治能力，不等于 StarWork 的长期 lane。
+
+二者差异：
+
+| 维度 | Codex sub-agent | StarWork lane |
+|---|---|---|
+| 生命周期 | 通常服务于当前任务，完成后关闭 | 可长期存在，跨会话接力 |
+| 事实源 | 宿主运行时 | 项目内 `_系统/协作/` |
+| 主要目标 | 并行执行或探索 | 职责稳定、边界清晰、输出可交接 |
+| 适合场景 | 临时分治、并行调研、并行修复 | 课程交付、项目常设角色、跨天协作 |
+
+课程中应避免把 `multiagent` 讲成“开多个 sub-agent”。更准确的说法是：Codex 的 sub-agent 是执行资源；StarWork lane 是组织协议。
+
+## 对 StarWork Multiagent 的产品启发
+
+### 启发 1：把 lane 从“登记表”升级为“宿主线程投影”
+
+当前 `_系统/协作/agent-lanes.md` 已有 `current_session`。结合 Codex 线程工具，未来每个 lane 可以有一个宿主线程投影：
+
+```text
+lane.id
+lane.purpose
+lane.write_scope
+lane.current_session
+lane.host.title
+lane.host.pinned
+lane.host.archived
+lane.last_seen_status
+```
+
+注意这些 host 字段不应成为 Core 必填项。它们属于 adapter observation 或 state cache，避免让 Cursor / Trae / Claude Code 无法支持时拖累协议。
+
+### 启发 2：`status` 应从“表格输出”升级为“协作驾驶舱”
+
+Codex 能 read thread 后，`starwork multiagent status` 的未来形态可以不只列 lane，还能显示：
+
+- 该 lane 当前绑定线程是否可访问。
+- 线程标题是否与 lane 目的匹配。
+- 线程是否 pinned。
+- 线程最近一次状态摘要。
+- 线程是否已 archive 但 lane 仍绑定。
+- worklog 是否落后于线程状态。
+
+v0.1 已有 `status --json`，适合作为未来 adapter 注入更多宿主状态的承载点。
+
+### 启发 3：增加“常用智能体”的显式体验
+
+用户真正想要的不是 `bind` 这个工程动作，而是：
+
+```text
+把这个会话设为 StarWork 课程交付研究 Agent。
+以后我一眼能看出来，必要时能继续叫它干活。
+```
+
+因此课程里应该优先讲“常用智能体”体验：
+
+1. 设计 lane。
+2. 绑定当前 Codex 线程。
+3. 同步会话名。
+4. 必要时 pin。
+5. 通过 worklog / shared.md 交接产物。
+
+CLI 仍叫 `multiagent bind`，但用户教学语言应偏产品化。
+
+### 启发 4：新增 adapter 能力分级，而不是要求所有宿主全支持
+
+建议为 StarWork adapters 定义能力矩阵：
+
+| Adapter 能力 | Codex 当前可行性 | 是否进入 Core |
+|---|---|---|
+| session id detection | 部分可行，`codex:<thread-id>` | Core 需要 session 字符串，不强制自动识别 |
+| rename session | Codex App 正常路径使用 `set_thread_title` | Skill 标准线程工具 |
+| list sessions | 运行时已暴露 `list_threads` | Adapter 增强 |
+| read session summary | 运行时已暴露 `read_thread` | Adapter 增强 |
+| continue session | 运行时已暴露 `send_message_to_thread` | Adapter 增强 |
+| pin session | 运行时已暴露 `set_thread_pinned` | Adapter 增强 |
+| archive session | 运行时已暴露 `set_thread_archived` | Adapter 增强 |
+| create worktree session | 运行时已暴露 `create_thread` worktree target | Adapter 增强 |
+| scheduled lane run | 运行时有 automation | 高层调度能力，不进 Agent Lanes v0.1 |
+
+### 启发 5：把“释放 lane”设计成完整交接，而不是只清空 session
+
+Codex 支持 archive 后，`release` 的体验可以升级为：
+
+1. 提醒更新 worklog。
+2. 解除 lane binding。
+3. 可选归档旧线程。
+4. 保留 shared outputs。
+5. 下一个线程可以重新 bind 同一 lane。
+
+当前 CLI 已在 release 后提示更新工作记录，这是正确方向。未来可增加：
+
+```text
+starwork multiagent release <lane> --archive-session
+```
+
+但该参数只应在 Codex adapter 支持时生效。
+
+## 课程交付建议
+
+### 推荐主线
+
+课程不要从“多 Agent 技术”开场，而应从学员痛点开场：
+
+```text
+多个 AI 会话同时帮你做事时，最大的问题不是启动它们，而是：
+谁负责什么？
+能改哪里？
+产物放哪？
+下次谁接得住？
+我怎么在宿主会话列表里找回它？
+```
+
+然后把 StarWork multiagent 定位为：
+
+```text
+StarWork multiagent = 给多个 AI 会话加上职责位、边界、工作记录和共享索引。
+Codex 新会话能力 = 让这些职责位在宿主工具里更容易被命名、找回、继续和收纳。
+```
+
+### 建议课程结构
+
+1. 为什么“开多个聊天窗口”不是 multiagent。
+2. Agent Lanes：用职责位替代任务堆。
+3. `init/add/bind/status/share/release` 六个动作。
+4. Codex Desktop 中的会话命名、置顶、归档和后台线程如何辅助 StarWork。
+5. 实战：把一个课程交付项目拆成 `research`、`course-design`、`material-review` 三个 lane。
+6. 限制：自动唤醒、跨线程派活、宿主线程读取属于后续 adapter 增强，不是 v0.1 承诺。
+
+## StarWork 后续路线建议
+
+### P0：课程前必须讲清楚
+
+- StarWork 的事实源在项目内，不在 Codex 私有状态里。
+- Codex 会话标题、置顶和归档是 Skill 调用标准线程工具后的宿主显示动作，不是绑定事实源。
+- lane workspace 放过程材料，正式产物仍进 `product/docs/` 等项目正式目录。
+- `shared.md` 只登记索引，不搬运文件。
+
+### P1：Codex adapter 近期可做
+
+- 在 `multiagent bind` 后支持可选 pin。
+- 在 `multiagent release` 后支持可选 archive。
+- 新增 `multiagent status --host`，读取 Codex thread 标题、pin/archive 状态和最近摘要。
+- 新增 `multiagent continue <lane>`，通过已绑定 thread 发送 follow-up prompt。
+
+### P2：暂不进入课程承诺
+
+- 自动创建多个后台线程并分配任务。
+- 自动合并多线程代码改动。
+- 自动调度定时 lane。
+- 跨宿主统一读取所有会话历史。
+
+## 风险与边界
+
+- Codex App 运行时工具是当前环境暴露的能力，不等于所有用户环境都可用。
+- `codex app-server` 和线程管理接口可能继续变化，StarWork 只能 best-effort 对接。
+- 课程中应把“稳定协议”和“宿主增强”分开讲，避免学员误以为 StarWork 依赖某一个 Codex 内部接口。
+- 不能为了会话同步直接改写 `~/.codex` 私有数据库或索引文件。
+
+## 来源
+
+- OpenAI Developers: [Codex App features](https://developers.openai.com/codex/app/features)
+- OpenAI Developers: [Codex App worktrees](https://developers.openai.com/codex/app/worktrees)
+- OpenAI Help Center: [Codex changelog](https://help.openai.com/en/articles/11428266-codex-changelog)
+- GitHub: [openai/codex releases](https://github.com/openai/codex/releases)
+- 当前 Codex App 运行时工具说明：`create_thread`、`list_threads`、`read_thread`、`send_message_to_thread`、`set_thread_title`、`set_thread_pinned`、`set_thread_archived`、`automation_update`
+- 本项目事实源：`product/core/agent-lanes-spec.md`
+- 本项目事实源：`product/core/agent-lanes-session-naming-spec.md`
+- 本项目事实源：`product/skills/starworkMultiagent-spec.md`
+- 本项目实现：`product/cli/src/cli.js`

package/docs/multiagent/02-cursor-session-management-research-instructions.md

@@ -0,0 +1,204 @@
+# Cursor 会话管理能力调研指令
+
+## 基本信息
+
+- 日期：2026-06-01
+- 优先级：中
+- 用途：把本文复制或引用给 Cursor，让 Cursor 在自己的原生客户端环境中实测会话管理能力。
+- 目标：获得可用于 StarWork `multiagent` / Agent Lanes 适配设计的 Cursor 会话管理能力矩阵。
+
+## 调研前提
+
+这不是调研 Cursor 的 Agent 编码能力，也不是调研 Background Agent 的执行能力。
+
+本次只关心 Cursor 如何管理“会话 / chat / tab / history / thread”：
+
+- 能不能识别当前会话。
+- 能不能获得稳定会话 ID。
+- 能不能重命名当前会话。
+- 能不能列出历史会话。
+- 能不能读取、继续、导出、删除、归档或置顶会话。
+- 能不能把历史会话作为当前会话上下文。
+- 这些能力是否有 UI、命令面板、CLI、API、本地文件或数据库入口。
+
+## 给 Cursor 的调研 Prompt
+
+下面这段可以直接复制到 Cursor 的新会话中执行：
+
+```text
+你现在运行在 Cursor 原生客户端里。请帮我调研 Cursor 的“会话管理能力”，不要调研 Agent 编码能力。
+
+背景：
+我正在设计 StarWork 的 multiagent / Agent Lanes 功能。StarWork 会把多个 AI 会话登记为不同职责位 lane，并需要知道宿主工具是否支持会话识别、命名、恢复、历史读取、导出、归档等能力。
+
+请你在当前 Cursor 环境中尽量实测，而不是只凭公开文档回答。可以使用 Cursor UI、命令面板、设置、帮助文档、CLI、可安全读取的本地配置/数据库路径等方式调查。但不要修改私有数据库，不要删除真实历史，不要做不可逆操作。
+
+请按以下能力逐项调研，并给出证据来源：
+
+1. 当前会话识别
+- Cursor 是否能显示当前 chat/tab/session 的唯一 ID？
+- 如果 UI 不显示，是否能从命令、开发者工具、本地文件、SQLite、日志或导出文件中找到稳定 ID？
+- 该 ID 是否跨重启稳定？
+- 是否适合作为 StarWork 的 `cursor:<session-id>`？
+
+2. 当前会话命名 / 改名
+- 当前 chat/tab 是否支持手动改名？
+- 改名入口在哪里？
+- 改名后历史列表是否同步显示新名称？
+- 是否存在命令面板、CLI、API 或本地状态入口可程序化改名？
+- 是否能安全实现类似 Codex `thread/name/set` 的 adapter？
+
+3. 会话列表
+- Cursor 是否能列出历史 chats / sessions？
+- 入口在哪里？例如 sidebar、Agents window、Chat History、命令面板。
+- 是否支持搜索、筛选、按项目区分、按时间排序？
+- 是否能通过 CLI/API/本地文件程序化列出？
+
+4. 会话读取
+- 历史会话能否完整打开查看？
+- 打开后是否包含完整消息、工具调用、代码 diff、终端输出、附件或截图？
+- 是否能导出为 Markdown 或其他格式？
+- 导出的内容是否包含会话标题、时间、模型、上下文文件、代码修改摘要？
+- 是否能通过本地文件或数据库安全读取？
+
+5. 会话继续 / 恢复
+- 打开历史会话后是否可以继续发送新消息？
+- 继续时模型是否能获得旧会话完整上下文，还是只展示历史但不进入上下文？
+- Cursor 是否有 `@Past Chats` 或类似能力把旧会话带入新会话上下文？
+- 该能力对 StarWork “从 lane worklog 恢复工作”有什么启发？
+
+6. 会话导出
+- 是否支持导出当前或历史会话？
+- 导出入口在哪里？
+- 导出格式是什么？
+- 导出是否能用于 StarWork lane workspace，例如 `_系统/协作/lanes/<lane-id>/workspace/`？
+- 是否支持批量导出？
+
+7. 会话删除、归档、置顶
+- 是否支持删除会话？是否可恢复？
+- 是否支持归档 archive，而不是删除？
+- 是否支持置顶 pin/favorite/star？
+- 这些能力是否有 UI 或可编程入口？
+- 哪些能力适合映射到 StarWork `release` 后的宿主清理动作？
+
+8. 多会话 / 多标签
+- Cursor 是否支持多个 chat tabs 同时存在？
+- 每个 tab 是否有独立上下文、模型、历史？
+- tab 标题是否可手动命名？
+- 多 tab 同时编辑同一文件时，Cursor 如何处理冲突？
+- 这对 StarWork lane write_scope 有什么补充或限制？
+
+9. 长会话上下文管理
+- Cursor 是否会自动摘要长会话？
+- 是否有 `/summarize` 或手动摘要命令？
+- 摘要后旧消息是否仍可查看？
+- 摘要是否会影响继续工作时的准确性？
+- StarWork 是否仍需要 worklog 来做显式交接？
+
+10. Checkpoint / revert
+- Cursor 是否按会话保存代码修改 checkpoint？
+- 是否能恢复到某个会话步骤前？
+- checkpoint 是否跨重启保留？
+- checkpoint 与 chat history 是同一个系统还是两个系统？
+- 它是否适合映射 StarWork 的 lane 生命周期？如果不适合，请说明边界。
+
+11. Background Agent 会话历史
+- Background Agent 的聊天是否和普通 chat 在同一个历史入口？
+- 是否有独立入口或远程历史？
+- 是否能被普通 `@Past Chats` 引用？
+- 是否有可程序化 ID、读取、继续、命名、归档能力？
+- 请只从“会话管理”角度回答，不要展开 Background Agent 执行能力。
+
+12. Cursor CLI / API / 本地存储
+- Cursor 是否提供 CLI 管理 chat/session/history？
+- 是否有官方 API 管理普通会话？
+- 本地会话是否存储在 SQLite 或其他文件中？路径是什么？
+- 读取这些文件是否安全？是否可能破坏 Cursor 状态？
+- StarWork adapter 是否应该依赖这些内部存储？请给出风险判断。
+
+请最终输出：
+
+A. 一张能力矩阵，列为：
+能力 / UI 支持 / 可编程支持 / 稳定性 / 适配 StarWork 建议 / 证据
+
+B. 一段结论：
+- Cursor 中哪些能力可直接适配 StarWork？
+- 哪些只能人工操作？
+- 哪些不支持或不建议依赖？
+- StarWork 在 Cursor 中应该如何生成 `session_id`？
+- `multiagent bind --session-name` 在 Cursor 中应支持、降级还是跳过？
+- Cursor 是否适合实现 `multiagent status --host`、`multiagent continue <lane>`、`multiagent release --archive-session`？
+
+C. 一个建议工作流：
+如何在 Cursor 中把一个当前会话登记为 StarWork lane，并完成后续交接。
+
+请明确标注你的 Cursor 版本、操作系统、调研日期。
+```
+
+## StarWork 需要的能力矩阵模板
+
+Cursor 输出时建议使用这个表：
+
+| 能力 | UI 支持 | 可编程支持 | 稳定性 | StarWork 适配建议 | 证据 |
+|---|---|---|---|---|---|
+| 获取当前会话 ID | 待测 | 待测 | 待测 | 待测 | 入口/截图/路径/命令 |
+| 当前会话改名 | 待测 | 待测 | 待测 | 待测 | 入口/截图/路径/命令 |
+| 列出历史会话 | 待测 | 待测 | 待测 | 待测 | 入口/截图/路径/命令 |
+| 读取历史会话 | 待测 | 待测 | 待测 | 待测 | 入口/截图/路径/命令 |
+| 继续历史会话 | 待测 | 待测 | 待测 | 待测 | 入口/截图/路径/命令 |
+| 导出会话 Markdown | 待测 | 待测 | 待测 | 待测 | 入口/截图/路径/命令 |
+| 删除会话 | 待测 | 待测 | 待测 | 待测 | 入口/截图/路径/命令 |
+| 归档会话 | 待测 | 待测 | 待测 | 待测 | 入口/截图/路径/命令 |
+| 置顶会话 | 待测 | 待测 | 待测 | 待测 | 入口/截图/路径/命令 |
+| 多 chat tabs | 待测 | 待测 | 待测 | 待测 | 入口/截图/路径/命令 |
+| `@Past Chats` | 待测 | 待测 | 待测 | 待测 | 入口/截图/路径/命令 |
+| 长会话摘要 | 待测 | 待测 | 待测 | 待测 | 入口/截图/路径/命令 |
+| checkpoint / revert | 待测 | 待测 | 待测 | 待测 | 入口/截图/路径/命令 |
+| Background Agent 历史 | 待测 | 待测 | 待测 | 待测 | 入口/截图/路径/命令 |
+
+## StarWork 适配判断标准
+
+### 可直接适配
+
+满足以下任一条件：
+
+- 有稳定官方 CLI / API。
+- 有稳定 UI 操作，且 StarWork 只需要给用户提示，不需要自动化。
+- 有安全导出格式，可以进入 lane workspace。
+
+### 只能降级适配
+
+满足以下任一条件：
+
+- 只有 UI，没有可编程入口。
+- 有本地存储，但不是官方接口。
+- 能手动完成，但无法由 StarWork CLI 稳定执行。
+
+### 不建议适配
+
+满足以下任一条件：
+
+- 需要直接改写 Cursor 私有数据库。
+- 删除不可恢复。
+- 能力依赖不稳定实验 UI。
+- 会破坏用户历史或隐私。
+
+## 调研产物落地建议
+
+Cursor 完成调研后，把结果保存为：
+
+```text
+product/docs/multiagent/cursor-session-management-research-result.md
+```
+
+如果调研中产生截图或导出样例，不要放根目录；优先放：
+
+```text
+_系统/协作/lanes/feature-research/workspace/
+```
+
+或经确认后放入：
+
+```text
+product/docs/multiagent/assets/
+```

package/docs/multiagent/03-trae-session-management-research-instructions.md

@@ -0,0 +1,205 @@
+# Trae 会话管理能力调研指令
+
+## 基本信息
+
+- 日期：2026-06-01
+- 优先级：低
+- 用途：把本文复制或引用给 Trae，让 Trae 在自己的原生客户端环境中实测会话管理能力。
+- 目标：获得可用于 StarWork `multiagent` / Agent Lanes 适配设计的 Trae 会话管理能力矩阵。
+
+## 调研前提
+
+这不是调研 Trae 的 Builder / Solo 编码能力，也不是调研 Trae 的模型能力。
+
+本次只关心 Trae 如何管理“会话 / chat / builder history / side chat / inline chat history”：
+
+- 能不能识别当前会话。
+- 能不能获得稳定会话 ID。
+- 能不能重命名当前会话。
+- 能不能列出历史会话。
+- 能不能读取、继续、导出、删除、归档或置顶会话。
+- Chat、Builder、Inline Chat 的历史是否属于同一个系统。
+- 这些能力是否有 UI、命令面板、CLI、API、本地文件或数据库入口。
+
+## 给 Trae 的调研 Prompt
+
+下面这段可以直接复制到 Trae 的新会话中执行：
+
+```text
+你现在运行在 Trae 原生客户端里。请帮我调研 Trae 的“会话管理能力”，不要调研 Builder / Solo 的编码执行能力。
+
+背景：
+我正在设计 StarWork 的 multiagent / Agent Lanes 功能。StarWork 会把多个 AI 会话登记为不同职责位 lane，并需要知道宿主工具是否支持会话识别、命名、恢复、历史读取、导出、归档等能力。
+
+请你在当前 Trae 环境中尽量实测，而不是只凭公开文档回答。可以使用 Trae UI、命令面板、设置、帮助文档、CLI、可安全读取的本地配置/数据库路径等方式调查。但不要修改私有数据库，不要删除真实历史，不要做不可逆操作。
+
+请按以下能力逐项调研，并给出证据来源：
+
+1. 当前会话识别
+- Trae 是否能显示当前 Chat / Builder / Side Chat 的唯一 ID？
+- Inline Chat 是否有独立会话 ID？
+- 如果 UI 不显示，是否能从命令、开发者工具、本地文件、日志或导出内容中找到稳定 ID？
+- 该 ID 是否跨重启稳定？
+- 是否适合作为 StarWork 的 `trae:<session-id>`？
+
+2. 当前会话命名 / 改名
+- 当前 Chat / Builder 会话是否支持手动改名？
+- 改名入口在哪里？
+- 改名后历史列表是否同步显示新名称？
+- 是否存在命令面板、CLI、API 或本地状态入口可程序化改名？
+- 是否能安全实现类似 Codex `thread/name/set` 的 adapter？
+
+3. 会话列表
+- Trae 是否能列出历史 Chat / Builder 会话？
+- 入口在哪里？例如 Show History、侧边栏、命令面板、项目历史。
+- 是否支持搜索、筛选、按项目区分、按时间排序？
+- Chat 和 Builder 是否在同一个历史列表？
+- Inline Chat 是否进入历史列表？
+- 是否能通过 CLI/API/本地文件程序化列出？
+
+4. 会话读取
+- 历史会话能否完整打开查看？
+- 打开后是否包含完整消息、工具调用、代码 diff、终端输出、附件或截图？
+- 是否能看到 Builder 的执行步骤、修改文件、命令运行记录？
+- 是否能导出为 Markdown、JSON、HTML 或其他格式？
+- 导出的内容是否包含会话标题、时间、模型、上下文文件、代码修改摘要？
+- 是否能通过本地文件或数据库安全读取？
+
+5. 会话继续 / 恢复
+- 打开历史会话后是否可以继续发送新消息？
+- 继续时模型是否能获得旧会话完整上下文，还是只展示历史但不进入上下文？
+- Chat 历史和 Builder 历史是否都能继续？
+- 是否能从历史会话创建一个新会话，并带入历史上下文？
+- 该能力对 StarWork “从 lane worklog 恢复工作”有什么启发？
+
+6. 会话导出
+- 是否支持导出当前或历史会话？
+- 导出入口在哪里？
+- 导出格式是什么？
+- 导出是否能用于 StarWork lane workspace，例如 `_系统/协作/lanes/<lane-id>/workspace/`？
+- 是否支持批量导出？
+- 如果不支持导出，是否可以复制完整会话文本？
+
+7. 会话删除、归档、置顶
+- 是否支持删除会话？是否可恢复？
+- 是否支持归档 archive，而不是删除？
+- 是否支持置顶 pin/favorite/star？
+- 这些能力是否有 UI 或可编程入口？
+- 哪些能力适合映射到 StarWork `release` 后的宿主清理动作？
+
+8. Chat / Builder / Inline Chat 的会话边界
+- Chat 模式和 Builder 模式是否是不同会话类型？
+- 从 Chat 切到 Builder 是否保留同一个历史上下文？
+- Builder 生成的代码修改记录是否跟 chat message 绑定？
+- Inline Chat 是否会进入 Side Chat 历史？
+- 不同模式的历史在 UI 和存储上是否统一？
+
+9. 代码修改回滚 / checkpoint
+- Trae 是否按会话保存代码修改 checkpoint？
+- 是否只能在最新 Chat 窗口回滚？
+- 支持回滚多少轮？
+- 回滚是否不可撤销？
+- checkpoint 是否跨重启保留？
+- checkpoint 与 chat history 是同一个系统还是两个系统？
+- 它是否适合映射 StarWork 的 lane 生命周期？如果不适合，请说明边界。
+
+10. 长会话上下文管理
+- Trae 是否会自动摘要长会话？
+- 是否有手动摘要命令？
+- 摘要后旧消息是否仍可查看？
+- 切换模型后是否继承旧会话上下文？
+- StarWork 是否仍需要 worklog 来做显式交接？
+
+11. Trae CLI / API / 本地存储
+- Trae 是否提供 CLI 管理 chat/session/history？
+- 是否有官方 API 管理普通会话？
+- 本地会话是否存储在 SQLite、JSON、日志或其他文件中？路径是什么？
+- 读取这些文件是否安全？是否可能破坏 Trae 状态？
+- StarWork adapter 是否应该依赖这些内部存储？请给出风险判断。
+
+请最终输出：
+
+A. 一张能力矩阵，列为：
+能力 / UI 支持 / 可编程支持 / 稳定性 / 适配 StarWork 建议 / 证据
+
+B. 一段结论：
+- Trae 中哪些能力可直接适配 StarWork？
+- 哪些只能人工操作？
+- 哪些不支持或不建议依赖？
+- StarWork 在 Trae 中应该如何生成 `session_id`？
+- `multiagent bind --session-name` 在 Trae 中应支持、降级还是跳过？
+- Trae 是否适合实现 `multiagent status --host`、`multiagent continue <lane>`、`multiagent release --archive-session`？
+
+C. 一个建议工作流：
+如何在 Trae 中把一个当前会话登记为 StarWork lane，并完成后续交接。
+
+请明确标注你的 Trae 版本、操作系统、调研日期。
+```
+
+## StarWork 需要的能力矩阵模板
+
+Trae 输出时建议使用这个表：
+
+| 能力 | UI 支持 | 可编程支持 | 稳定性 | StarWork 适配建议 | 证据 |
+|---|---|---|---|---|---|
+| 获取当前会话 ID | 待测 | 待测 | 待测 | 待测 | 入口/截图/路径/命令 |
+| 当前会话改名 | 待测 | 待测 | 待测 | 待测 | 入口/截图/路径/命令 |
+| 列出历史会话 | 待测 | 待测 | 待测 | 待测 | 入口/截图/路径/命令 |
+| 读取历史会话 | 待测 | 待测 | 待测 | 待测 | 入口/截图/路径/命令 |
+| 继续历史会话 | 待测 | 待测 | 待测 | 待测 | 入口/截图/路径/命令 |
+| 导出会话 | 待测 | 待测 | 待测 | 待测 | 入口/截图/路径/命令 |
+| 删除会话 | 待测 | 待测 | 待测 | 待测 | 入口/截图/路径/命令 |
+| 归档会话 | 待测 | 待测 | 待测 | 待测 | 入口/截图/路径/命令 |
+| 置顶会话 | 待测 | 待测 | 待测 | 待测 | 入口/截图/路径/命令 |
+| Chat / Builder 历史统一性 | 待测 | 待测 | 待测 | 待测 | 入口/截图/路径/命令 |
+| Inline Chat 历史 | 待测 | 待测 | 待测 | 待测 | 入口/截图/路径/命令 |
+| 长会话摘要 | 待测 | 待测 | 待测 | 待测 | 入口/截图/路径/命令 |
+| checkpoint / revert | 待测 | 待测 | 待测 | 待测 | 入口/截图/路径/命令 |
+| 本地会话存储 | 待测 | 待测 | 待测 | 待测 | 入口/截图/路径/命令 |
+
+## StarWork 适配判断标准
+
+### 可直接适配
+
+满足以下任一条件：
+
+- 有稳定官方 CLI / API。
+- 有稳定 UI 操作，且 StarWork 只需要给用户提示，不需要自动化。
+- 有安全导出格式，可以进入 lane workspace。
+
+### 只能降级适配
+
+满足以下任一条件：
+
+- 只有 UI，没有可编程入口。
+- 有本地存储，但不是官方接口。
+- 能手动完成，但无法由 StarWork CLI 稳定执行。
+
+### 不建议适配
+
+满足以下任一条件：
+
+- 需要直接改写 Trae 私有数据库。
+- 删除不可恢复。
+- 能力依赖不稳定实验 UI。
+- 会破坏用户历史或隐私。
+
+## 调研产物落地建议
+
+Trae 完成调研后，把结果保存为：
+
+```text
+product/docs/multiagent/trae-session-management-research-result.md
+```
+
+如果调研中产生截图、导出样例或复制出的会话文本，不要放根目录；优先放：
+
+```text
+_系统/协作/lanes/feature-research/workspace/
+```
+
+或经确认后放入：
+
+```text
+product/docs/multiagent/assets/
+```