1. 后台任务存储位置验证#

通过 ls ~/.claude/jobs/ 查看后台任务目录：

1
216bf6d0  b2060bf0  b7729497  pins.json

每个目录对应一个 /bg 或 claude --bg 产生的后台任务，目录名即短 ID。

2. /bg 的行为：新进程 + 新 UUID，但保留会话名#

测试步骤：

1. 创建交互式会话，命名为 agentView
2. 在会话中执行 /bg 转为后台任务
3. 查看 ~/.claude/projects/<path>/ 目录 → 出现两个同名文件（两个不同 UUID）

结论：

• /bg 不是”把当前会话移到后台”，而是基于当前状态启动一个新的后台进程
• 新进程有新的 UUID，但保留原来的会话名
• 原交互式会话的 transcript 保留，新的后台任务另起一份 transcript
• 因此 projects 目录下会出现两个同名的 .jsonl 文件

3. 运行中 vs 已停止的后台任务恢复方式不同#

关键点：

• --resume 恢复的是 transcript，不是进程。运行中的 bg 进程已经有活进程在跑，所以不让重复恢复
• 停止或删除后，活进程没了，--resume 就可以基于 transcript 重建会话

4. stop 与 delete 的关键区别#

官方文档说 “The conversation transcript stays on disk”，实测验证：delete 后台任务后 jobs/<id>/ 目录确实被清理，但 conversation transcript 保留在 ~/.claude/projects/<path>/<uuid>.jsonl 中。因此：

• delete ≠ 对话历史丢失
• delete = job 运行环境丢失（worktree、state.json 等），但文字记录仍在
• 只要记住 uuid，随时可以通过 --resume <uuid> 恢复对话

5. --resume 与 attach 的作用域#

两套系统并非完全隔离：

• 后台任务的 transcript 同样存储在 ~/.claude/projects/ 中，与交互式会话共用同一套 transcript 机制
• 区别在于：交互式会话通过 sessions/*.json 跟踪进程状态，后台任务通过 jobs/<id>/ 目录跟踪
• --resume 列表只显示活跃交互式会话；已停止/已删除的后台任务不会出现在 --resume 列表中，但只要知道 uuid，直接 claude --resume <uuid> 仍可恢复

Agent View 不显示短 ID：列表中只显示会话名，短 ID 需通过 ls ~/.claude/jobs/ 或 claude logs <id> 的输出来获取。

Agent View / 后台任务的定位#

不是「长期对话管理器」，而是临时任务执行器：

• ✅ 适合：独立可自包含的任务（review PR、跑测试、生成文档）
• ❌ 不适合：需要长期迭代、频繁上下文、探索性开发、需保留决策记录的场景

实际分工建议#

踩坑点#

1. 同名会话陷阱：交互式会话和后台任务可以有相同名字，但 UUID 不同。--resume 按 UUID 恢复，attach 按短 ID 恢复，各找各的，不要混用
2. delete ≠ 对话丢失，但 = 环境丢失：delete 后 jobs/<id>/ 被清理，无法 attach/respawn，但 transcript 仍在 ~/.claude/projects/ 中，记住 uuid 就能 --resume 恢复
3. 运行中的 bg 任务会阻塞 --resume：看到 currently running as a background agent (bg) 时，说明进程还在跑，需要用 attach <短id> 或 claude agents 进入，而不是 --resume
4. stop 是暂停，delete 是销毁环境：如果只是过会儿再回来聊，用 stop（Ctrl+X 一次），保留 respawn 的能力
5. Agent View 不显示短 ID：想在 shell 里 attach 却找不到短 ID？用 ls ~/.claude/jobs/ 查看目录名，或通过 claude logs <id> 的报错来确认有效 ID