--- title: "使用 Claude Code：会话管理与 100 万 上下文" source_name: "宝玉的分享" original_url: "https://baoyu.io/translations/claude-code-session-management" canonical_url: "https://www.traeai.com/articles/f7f34773-f330-4e5b-b877-55b5d4700baa" content_type: "article" language: null score: 8.5 tags: ["Claude Code","AI编程","上下文管理","大模型工程","开发工作流"] published_at: "2026-04-15T00:00:00+00:00" created_at: "2026-04-16T03:23:45.461069+00:00" --- # 使用 Claude Code：会话管理与 100 万 上下文 Canonical URL: https://www.traeai.com/articles/f7f34773-f330-4e5b-b877-55b5d4700baa Original source: https://baoyu.io/translations/claude-code-session-management ## Summary traeai 从博客、播客、视频和推文中筛选高质量技术内容，生成摘要、要点、评分和每日早报。 ## Key Takeaways - 面对百万级上下文，需根据任务阶段灵活选用继续、回溯、清空、压缩或子智能体，以规避上下文衰减导致的模型失焦。 - 纠正AI错误时应优先使用回溯功能退回关键节点重新引导，避免在错误路径上堆砌提示词，从而节省Token并提高成功率。 - 长会话应主动压缩或新建以防关键信息被丢弃；涉及大量中间过程的任务宜交由子智能体处理，主会话仅接收最终结果。 ## Content Title: 使用 Claude Code：会话管理与 100 万 上下文 URL Source: http://baoyu.io/translations/claude-code-session-management Markdown Content: 作者：Thariq 原文：[Using Claude Code: Session Management & 1M Context](https://x.com/trq212/status/2044548257058328723) 【注：Thariq 是 Anthropic 员工，Claude Code 的核心对外布道者。这篇本质是产品使用指南，有官方推广成分，但操作建议确实实用。】 今天，我们为 **/usage** 命令推出了一项全新更新，旨在帮助你更清晰地了解自己在 Claude Code 中的使用情况。这个决定的背后，是我们近期与用户进行的多次深入交流。 在这些交流中，我们反复听到了一个现象：大家在管理会话时的习惯可谓是五花八门。尤其是最近 Claude Code 将上下文窗口（Context Window）升级到了 100 万大关，这种差异就更明显了。 你是习惯在终端里只保持一两个开着的会话？还是每次输入提示词都重新开个新会话？你通常在什么时候会用到压缩（Compact）、回溯（Rewind）或者子智能体（Subagents）？又是什么原因导致了一次糟糕的压缩呢？ 这里头其实大有学问。这些看似不起眼的细节，极大地影响着你使用 Claude Code 的体验。而这一切的核心，都归结于一件事：如何管理你的上下文窗口。 ## 快速科普：上下文、上下文压缩与上下文衰减 ![Image 1: 上下文窗口组成示意图](https://s.baoyu.io/imgs/2026-04-15/trq212/02-infographic-context-window.png) 所谓“上下文窗口（Context Window）”，就好比模型在生成下一次回答时，眼前能同时“看到”的所有信息。它包括了你的系统提示词（System Prompt）、到目前为止的聊天记录、每一次的工具调用（Tool Call）及其输出结果，甚至还有它读过的每一个文件。现在，Claude Code 拥有高达 100 万个词元（Token）**（注释：Token 是大模型处理文本的基本单位，通常一个英文单词约为 1 个 Token，一个汉字可能占 1-2 个 Token）** 的超大上下文窗口。 但遗憾的是，使用上下文是需要付出一点代价的，我们通常称之为上下文衰减（Context Rot）**（注释：指随着对话历史越来越长，模型需要处理的信息量过大，导致其注意力分散，遗忘早期重要信息或被无关内容干扰的现象）**。随着上下文越来越长，模型的表现往往会变差，这是因为它的注意力被分散到了更多的 Token 上。那些早期遗留的、已经无关紧要的内容，会开始干扰模型当前正在执行的任务。 上下文窗口是有硬性容量上限的。所以，当你快要把窗口撑满时，你必须把你正在做的任务总结成一段简短的描述，然后带着这段描述在一个新的上下文窗口里继续工作。我们把这个过程称为上下文压缩（Compaction）**（注释：为了腾出内存空间，将超长历史记录提炼成精简摘要的过程）**。当然，你也可以随时手动触发这个压缩过程。 ![Image 2: 上下文衰减与压缩过程](https://s.baoyu.io/imgs/2026-04-15/trq212/03-infographic-context-rot.png) ## 每一次回合，都是一个分叉路口 想象一下，你刚刚让 Claude 帮你做了一件事，并且它已经完成了。现在，你的上下文里已经塞进了一些信息（比如工具调用、工具的输出结果、你给的指令）。接下来该怎么做？你可能会惊讶地发现，自己竟然有这么多种选择： * **继续（Continue）** — 在同一个会话里，直接发送下一条消息 * **回溯（/rewind 或连按两次 Esc 键）** — 时光倒流，退回到之前的一条消息，从那里重新开始尝试 * **清空（/clear）** — 开启一个全新的会话，通常带上你从刚才对话中提炼出的简短总结 * **压缩（Compact）** — 把目前的对话做个总结，然后在这个总结的基础上继续干活 * **子智能体（Subagents）** — 把下一阶段的工作委派给另一个拥有自己干净上下文的 AI 智能体（AI Agent），并且只把它最终的工作结果拉取回来 虽然直接“继续”是最顺理成章的反应，但其他四个选项的设定，正是为了帮你更好地管理你的上下文。 ![Image 3: 五种上下文管理策略对比](https://s.baoyu.io/imgs/2026-04-15/trq212/04-comparison-context-strategies.png) ## 什么时候该开个新会话？ 到底什么时候该维持一个漫长的老会话，什么时候又该另起炉灶呢？我们的经验法则是：当你开始一项新任务时，你也应该开启一个新会话。 100 万的上下文窗口，意味着你现在可以非常靠谱地完成更长、更复杂的任务。比如，让 Claude 从零开始为你搭建一个全栈应用。 但有时候，你可能在做一些前后关联的任务。这时候，你需要保留一部分之前的上下文，但不是全部。举个例子，你刚写完一个新功能，现在要为它写一份使用文档。你当然可以开个新会话，但这意味着 Claude 必须把你刚才写过的所有代码文件重新读一遍——这不仅速度更慢，而且花费也更高。 ## 用“回溯”代替“纠正” ![Image 4: 纠正 vs 回溯流程对比](https://s.baoyu.io/imgs/2026-04-15/trq212/05-flowchart-rewind-vs-correct.png) 如果非要我挑出一个能代表“优秀上下文管理能力”的好习惯，那一定是用好“回溯（Rewind）”。 在 Claude Code 里，双击 `Esc` 键（或者运行 `/rewind` 命令）能让你穿越回之前的任意一条消息，然后从那里重新下发提示词。至于那个节点之后发生的所有对话，都会被从上下文中彻底抛弃。 在纠正 AI 的错误时，“回溯”往往是更高明的做法。举个例子：Claude 读了五个文件，尝试了一种方法，结果失败了。你的本能反应可能是在对话框里敲下：“这招不管用，换 X 方法试试。”但更聪明的做法是，回溯到它刚读完那五个文件的时刻，然后带着你刚学到的教训重新对它说：“别用 A 方法了，foo 模块根本不支持那个——直接去试 B 方法。” 你甚至可以使用“从这里开始总结（summarize from here）”的功能，让 Claude 自己把它学到的教训总结成一段“交接信息”。这感觉就像是那个刚刚踩了坑的“未来版 Claude”，给过去那个还没开始行动的自己留下了一张字条。 ![Image 5: 回溯功能操作界面示意](https://s.baoyu.io/imgs/2026-04-15/trq212/06-scene-rewind-ui.png) ## 上下文压缩 vs 全新会话 当一个会话变得越来越长时，你有两种方法可以给它“减负”：使用 `/compact` （压缩）或者 `/clear` （清空并从头开始）。这两个操作听起来挺像，但实际表现大相径庭。 **压缩（Compact）** 是让模型把到目前为止的对话总结一下，然后用这份摘要替换掉冗长的历史记录。这个过程是“有损”的，意味着你把决定“什么内容重要”的权力交给了 Claude。好处是你什么都不用写，而且 Claude 在保留重要的经验教训或文件记录时，可能比你想得更周到。你也可以通过给它下达指令来掌控压缩的方向（比如：`/compact 将重点放在身份验证模块的重构上，丢掉那些关于测试调试的内容`）。 ![Image 6: /compact vs /clear 对比](https://s.baoyu.io/imgs/2026-04-15/trq212/07-comparison-compact-vs-clear.png) 而使用 `/clear`，则需要你自己写下核心要点（例如：“我们正在重构身份验证的中间件，目前的限制条件是 X，相关的重要文件是 A 和 B，而且我们已经排除了方法 Y”），然后以一个无比干净的状态重新开始。虽然这要费点劲，但由此产生的新上下文，百分百都是你认为真正相关的精华。 ## 什么样的“压缩”会翻车？ ![Image 7: 糟糕的压缩场景](https://s.baoyu.io/imgs/2026-04-15/trq212/08-infographic-bad-compaction.png) 如果你经常挂着超长的会话，你大概率遇到过“压缩”效果极其糟糕的情况。我们发现，这种“翻车”通常发生在一个特定的时刻：那就是大语言模型（LLM）无法预测你下一步工作方向的时候。 举个例子，在一段漫长的代码调试之后，系统触发了自动压缩，把之前的排查过程总结了一番。结果你紧接着发了一句：“现在，把我们之前在 [bar.ts](http://bar.ts/) 里看到的另一个警告也修了吧。” 可是，由于刚才的会话重点全在调试前一个 Bug 上，那个没来得及修的警告很可能早就被当成无关紧要的信息，在总结时被直接丢弃了。 这是一个相当棘手的问题。因为受限于上下文衰减，模型在进行压缩的那一刻，往往是它“智商”最不在线的时候。好在有了 100 万的上下文容量，你现在有了更充裕的空间，可以主动带上“我接下来想做什么”的描述，去提前执行 `/compact`。 ## 子智能体与全新的上下文窗口 ![Image 8: 子智能体工作机制](https://s.baoyu.io/imgs/2026-04-15/trq212/09-framework-subagent.png) 子智能体也是一种管理上下文的绝佳手段。当你提前预知某一项工作会产生大量“阅后即焚”（以后再也用不上）的中间结果时，这招特别管用。 当 Claude 通过智能体工具（Agent tool）衍生出一个子智能体时，这个小家伙会获得一个完全崭新的上下文窗口。它可以在里面肆意折腾，做多少工作都行。等到大功告成，它会把结果提炼出来，只把最终的报告交还给“父级”Claude。 我们判断是否该用子智能体的“灵魂拷问”是：以后我还需要看这些工具运行的详细输出吗，还是我只想要一个最终结论？ 虽然 Claude Code 会在背后自动调用子智能体，但有时候你也可以非常明确地指挥它。比如，你可以对它说： * “派个子智能体去，根据下面这份规范文件，验证一下我们刚才做的工作对不对” * “派个子智能体去通读一下另一个代码库，总结出它是怎么实现身份验证流程的，然后你自己照猫画虎，在这边也实现一遍” * “派个子智能体去，根据我的 Git 修改记录，给这个新功能写份说明文档” ## 总结 总而言之，当 Claude 完成了一轮回答，而你正准备发送一条新消息时，你就站在了一个决策的路口。 我们期望在未来，Claude 能足够聪明，自己帮你打理好这一切。但就目前而言，熟练掌握这些决策，正是你引导 Claude 产出高质量结果的必经之路。 ![Image 9: 决策速查表](https://s.baoyu.io/imgs/2026-04-15/trq212/10-infographic-cheat-sheet.png)