❓ 问题一：这种子进程调用是递归吗？
🍔 生活类比：点外卖 vs 套娃
递归（套娃）：你在吃外卖的时候，突然想再点一份外卖，然后在等第二份外卖的时候又点了第三份……所有外卖都在同时等待中。
顺序调用（我们的方式）：你吃完一份外卖，把餐盒扔掉，然后再点下一份。每次只有一个外卖配送员在路上。
❌ 递归（套娃式）
进程 1 启动
↓ 内部启动
进程 2 启动
↓ 内部启动
进程 3 启动
所有进程同时存在
就像俄罗斯套娃，一个套一个
✅ 顺序调用（我们的方式）
进程 1 启动 → 完成 → 退出
进程 2 启动 → 完成 → 退出
进程 3 启动 → 完成 → 退出
每次只有一个进程
就像接力赛，一棒接一棒
📊 实际运行流程
用户第 1 条消息："帮我写个函数"
spawn 进程 A → 生成 session-abc123 → 返回结果 → 进程 A 退出
用户第 2 条消息："改一下这个函数"
spawn 进程 B（带 --resume=session-abc123）→ 返回结果 → 进程 B 退出
用户第 3 条消息："再优化一下"
spawn 进程 C（带 --resume=session-abc123）→ 返回结果 → 进程 C 退出
🔑 关键要点
- 每次对话都是全新启动一个 Claude 子进程
- 处理完当前消息后，进程立即退出（不保留）
- 下次对话通过 --resume=session_id 恢复记忆
- 内存中不会累积越来越多的进程（防止内存泄漏）
❓ 问题二：--resume 后能看见多少上下文？
📚 生活类比：图书馆借书卡
想象 Claude 的记忆像一本笔记本，每次对话都在笔记本上记录。--resume 就是打开这本笔记本继续写。
但笔记本有页数限制！写满 200,000 页后，最早的内容会被自动撕掉（截断），只保留最近的对话。
📊 上下文容量详解
⚠️ 什么会占用上下文？
会占用：
• 你发送的每条消息（包括提问、指令）
• Claude 的每次回复（包括解释、代码）
• 工具调用记录（比如"读取了 abc.txt 文件"）
• 系统提示词（告诉 Claude 如何工作的说明）
不会占用：
• 文件的实际内容（只记录文件路径，需要时重新读取）
• 图片的像素数据（只记录图片描述）
📖 上下文示例（简化版）
🔑 关键要点
- 总容量 200K tokens，约等于 100 轮正常对话
- 每次 --resume 会完整恢复所有历史消息（在容量内）
- 超过容量后，最早的消息会自动删除（类似滑动窗口）
- 文件内容不占上下文，每次需要时重新读取
- 如果对话太长，可以用 /clear 命令清空重新开始
🎯 总结：一句话记住核心原理
每次启动新进程 → 恢复 200K 记忆 → 处理完退出
✅ 优点
• 内存占用稳定（不累积进程）
• 崩溃不影响其他会话
• 自动清理临时文件
• 支持无限轮次对话（只要不超容量）
⚠️ 限制
• 上下文有容量限制（200K tokens）
• 极长对话会丢失最早内容
• 每次启动有几秒延迟
• 依赖 Claude CLI 的稳定性
💡 实用建议
何时需要 /clear 清空上下文？
• 对话超过 50 轮，开始变慢
• 切换到完全不同的任务
• Claude 开始"混淆"之前的内容
• 想要节省 API 费用（上下文越长越贵）
如何查看当前上下文使用情况？
目前没有直接命令，但可以通过对话轮次 × 平均长度估算。一般来说，50 轮以内都很安全。