--- title: 'WISC 上下文管理四策略' video_id: nxHKBq5ZU9U url: https://youtu.be/nxHKBq5ZU9U title_en: "I've Used Claude Code for 2,000+ Hours - Here's How I Build Anything With It" channel: Cole Medin published: 2026-03-16 duration: "22:48" topics: [Claude Code 工作流, Agent 工程] noted: 2026-07-08 value: A views: '3.1万' --- [![封面](https://i.ytimg.com/vi/nxHKBq5ZU9U/maxresdefault.jpg)](https://youtu.be/nxHKBq5ZU9U) > Cole Medin · 22:48 · 发布 2026-03-16 · 3.1万次观看(截至抓取) · [观看原视频](https://youtu.be/nxHKBq5ZU9U) ## 主旨 Cole 把 2000+ 小时 Claude Code 实战浓缩成 WISC 框架:把编码 agent 的上下文管理拆成 **W**rite(把决策外化到文件/Git)/ **I**solate(用 subagent 隔离脏活与研究)/ **S**elect(分四层按需加载)/ **C**ompress(最后才用的兜底)四类策略,主张 80% 的 agent 失误根因不在模型而在上下文管理,窗口扩到 100 万 token 也不解。 ## 核心论点 1. **80% 的 agent 失误根因是上下文管理差,不是模型差** —— 即使 Claude Code 已扩到 1M token 也没用,因为劣化按用量占比触发,扩窗只把可用占比拉低。([[#1-为什么上下文管理才是真正的瓶颈-0137|→ 详解1]]) 2. **Git commit message 可以当 agent 的长期记忆,无需另搭记忆框架** —— 关键是 commit message 标准化、够详细,能直接喂给下一轮 session 当上下文。([[#2-w---git-日志即长期记忆-0549|→ 详解2]]) 3. **规划与实现必须拆成两个独立 session** —— 实现前先把结构化 plan markdown 落盘,新会话只喂这份 plan,避免规划期积累的偏见污染实现。([[#3-w---规划与实现必须拆成独立-session-0845|→ 详解3]]) 4. **进度文件 / handoff.md 是长会话的"逃生通道"** —— 长会话尾段用 /handoff 写一份摘要,再开新会话接续,比 /compact 反复压更稳。([[#4-w---进度文件与-handoff-文档-1002|→ 详解4]]) 5. **Subagent 主战场是研究,Anthropic 数据给 90.2% 改进;Scout 模式是大投入规划前的"探路者"** —— 研究用 subagent 隔离掉几万/几十万 token 的脏活,主会话只接几百 token 的总结;Scout 模式则是先派 subagent 探明哪些文档该加载再决定投入。([[#5-i---subagent-隔离研究与-scout-探路-1142|→ 详解5]]) 6. **上下文分四层加载(global / on-demand / skill / prime),W/I/S 做得好就不需要 C** —— 全局规则恒定加载,按需上下文模块化加载,技能按触发加载,prime 命令会话开头现探——四层用得越好,越不需要进压缩层。([[#6-s---上下文分四层加载-1533|→ 详解6]]) 7. **压缩是最后手段,优先级 handoff > /compact > 开新会话** —— 连续压缩超两次基本就应直接开新会话,把 handoff 文档带过去。([[#7-c---压缩是兜底优先级-handoff--compact--新会话-1928|→ 详解7]]) ## 知识点详解 ### 1. 为什么"上下文管理"才是真正的瓶颈 [01:37](https://youtu.be/nxHKBq5ZU9U?t=97) Cole 在 0:00-2:00 之间开门见山:这套策略看似具体到一个框架,实际全部围绕"如何不让上下文腐化"展开——他自陈 80% 的 agent 失误可以归到"上下文没管好"。 他引 Chroma 发布的 [[Context Rot|context rot]] 研究作为理论背书:核心论断是"能塞进窗口不代表该塞进窗口",大海捞针 测试(needle in a haystack)证明:信息在长上下文里被准确召回的概率随用量占比下滑——不是绝对 token 数,而是相对占比。所以"Claude Code 现在有 1M 上下文了"不解决任何问题,只是把可用占比拉低。 用 Cole 自己的话:「context rot is the biggest problem with AI coding assistants right now」([01:37](https://youtu.be/nxHKBq5ZU9U?t=97))。 中大型代码库(尤其是多 repo、相似模式多)里这个问题被放大:distractor(语义相近但不是目标的文件)让模型很自信地拿错实现、用错 fix——这是 [[Harness]] 工程里"上下文质量"维度的具体病灶,也是后面所有 W/I/S/C 策略要解决的对象。 ### 2. W - Git 日志即长期记忆 [05:49](https://youtu.be/nxHKBq5ZU9U?t=349) 第一条 Write 策略:用 git 提交信息当 agent 的长期记忆,不必另搭一套记忆/notes 系统——"everyone's already using Git and GitHub for version control"。 核心做法是 commit message 标准化:Cole 给出一条 `/commit` slash command,自动生成"做了什么 + 怎么改了 AI 层(规则/命令/技能)"两段式 message,既记业务变更,又记 agent 自己的规则演进。 Cole 在 8:42 处明文:「standardize the messages, we make them very detailed so we can use it as long-term memory」([08:42](https://youtu.be/nxHKBq5ZU9U?t=522))。 实际收益是双层:**人**能凭 commit 历史回顾近期工作(同 GitHub 现有能力);**agent**能在新会话开头读最近 commit 判断"主人最近在忙啥"——一份基础设施,两边用。Cole 在视频里展示 Arkon 项目的 commit 一行命令截图,显示数十次 feature/fix 提交都按统一格式排列。 这与 [[外脑三条路线]] 中的"路线一·文件 wiki"是同构:把零散决策沉淀为版本化文件,新会话按需取用——只是 Cole 直接复用了团队已经用着的 git,不再单独搭 wiki 工具。 ### 3. W - 规划与实现必须拆成独立 session [08:45](https://youtu.be/nxHKBq5ZU9U?t=525) 第二条 Write 策略:写代码时**永远新开一个 session**,规划与实现不在同一窗口里跑。流程是:规划 session 跑完 `/plan` 生成结构化 markdown 计划,实现 session 只把这份 plan 当成唯一上下文喂进去,其余一概不带。 Cole 在 8:49 明文:「always start a brand new context window whenever you are writing any code」([08:49](https://youtu.be/nxHKBq5ZU9U?t=529))。 这样做的直接原因是:规划阶段会塞入大量研究信息(规格文档、候选方案、对比表),如果同一会话直接进入实现,这些"已完成的工作"会作为 上下文污染 把实现阶段的注意力稀释;新会话从一份精炼的 plan 开始,实现 agent 一开始就只面对"该写什么"。 这也对应 [[Harness]] 大师课里"规划/实现拆独立 session"的对策——同源主张,本片把"为什么"和"怎么做"都补齐了:规划时可以用 subagent 大量研究(下一节),把研究成本关在规划 session 内,实现 session 干净起步。 ### 4. W - 进度文件与 handoff 文档 [10:02](https://youtu.be/nxHKBq5ZU9U?t=602) 第三条 Write 策略:长会话里定期把"已完成的决策 + 接下来要做的"写进 handoff.md / todo.md 这类进度文件,让新会话能瞬间接上而不必重读历史。 Cole 在 10:42 处用 Vercel Agent Browser 跑端到端测试作为场景示例:agent 跑完一遍 user journey 后,context 已经堆到 200,000 token(他说 "we're already at 200,000 out of the new 1 million limit"——[10:54](https://youtu.be/nxHKBq5ZU9U?t=654))。此时用 `/handoff` 命令把已完成的测试用例、发现的问题、待办事项整理成 markdown,新会话读这份文档就能继续,不必携带前面的工具调用历史。 这套机制本质上是 Compaction 的"自定义版":内置 `/compact` 是模型自己摘要、会丢失细节;handoff 是**人可控的摘要流程**,你可以规定"重点保留哪些信息"——例如 Cole 会在压缩时主动加一句"focus on the edge cases that we just tested",让模型把测试相关上下文留得更细。 handoff 文件在多 subagent 协作里也充当通信总线(一个 agent 写、下一个 agent 读),属于 [[Agent Teams]] 之外更轻量的跨 session 通信。 ### 5. I - Subagent 隔离研究与 Scout 探路 [11:42](https://youtu.be/nxHKBq5ZU9U?t=702) 两条 Isolate 策略共享一个底层机制——用 Subagent 隔离脏活,主会话保持干净。Cole 给的数据是:Anthropic 内部研究显示,用 subagent 加载研究上下文比让主 agent 直接干,**主窗口 token 用量可降 90% 以上**([12:03](https://youtu.be/nxHKBq5ZU9U?t=723))。 实操里他明确边界:「I don't recommend them for implementation」——研究用 subagent,实现仍由主 agent 干([13:53](https://youtu.be/nxHKBq5ZU9U?t=833))。原因是实现需要"连贯地知道上一步我做了什么",这些细节塞进 subagent 再回传会丢;而研究是"汇总结论即可",天然适合 subagent 隔离 + 摘要回流。 并行是另一关键收益:同一份规划 prompt 里他让两个 subagent 一个跑代码库研究、一个跑网络研究,「sub agents are running in parallel behind the scenes」([13:29](https://youtu.be/nxHKBq5ZU9U?t=809))——多扇出(fan-out)再由主 agent 扇入汇总,这是 Fan-out Fan-in 模式的教科书示范。 **Scout 模式**(I 的第二条策略)是 subagent 的一种特殊用法:Cole 在 14:11 称之为「send scouts ahead before you commit your main context」([14:11](https://youtu.be/nxHKBq5ZU9U?t=851))。具体做法是:在大投入规划前,先派 subagent 探明代码库/文档里哪些资料"值得加载进主 context",再做决定。Cole 在视频里展示:用 explore subagent 扫描 `.claude/docs/` 下所有文档,只把"与当前任务相关的一份"主动加载进主会话——上下文隔离 的同时,把"该加载什么"也交给 subagent 决策,避免主 agent 一开始就背着一堆不相关的文档。 ### 6. S - 上下文分四层加载 [15:33](https://youtu.be/nxHKBq5ZU9U?t=933) Select 策略给"按需加载"这一原则落成四层具体结构,从最常驻到最偶发依次是: 1. **Global rules**(全局规则):恒定加载的架构/测试/日志约定等,Cole 推荐 500-700 行封顶([16:01](https://youtu.be/nxHKBq5ZU9U?t=961))——这与 [[静态上下文与动态上下文]] 的"少占静态上下文"小结一致:恒定上下文不是越多越好,塞太多反而稀释注意力、推高推理成本。 2. **On-demand context**(按需上下文):模块级规则,例如"前端约定"或"API 端点约定"——只在要做这块时才叠加到全局之上,平时不进 context。 3. **Skills**(技能):按触发加载的能力包。「If the agent decides it wants to use this skill, then it'll load the full skill.md」([17:22](https://youtu.be/nxHKBq5ZU9U?t=1042))——skill 始终预加载的是 name + description(几十 token),完整内容按需触发。Cole 用 Vercel Agent Browser skill 演示:[17:45](https://youtu.be/nxHKBq5ZU9U?t=1065)「whenever I am doing my end-to-end testing, then I want to load this instruction set」。 4. **Prime commands**(探路命令):会话开头现跑的命令,让 subagent 当场探明代码库当前状态,再决定后续规划方向。「I just tell it to get an understanding of the Arkon code base at a high level」([18:36](https://youtu.be/nxHKBq5ZU9U?t=1116))。 这四层与 [[静态上下文与动态上下文]] 的分类是同一权衡的不同切片:静态/动态是"按需 vs 常驻"的二分,本片给出"恒定 / 模块级 / 触发级 / 探路级"四档精细化——尤其 prime commands 把"按位置"扩展成"按时间"维度(会话开头现探一次)。 这四层用得越细,主 context 在任何时刻就越瘦,[[Context Rot]] 触发概率越低,反过来也意味着 C(压缩)几乎用不上——Cole 直接点出「you shouldn't need to compress often if you're doing the right isolate and select well」([19:37](https://youtu.be/nxHKBq5ZU9U?t=1177))。 ### 7. C - 压缩是兜底,优先级 handoff > /compact > 新会话 [19:28](https://youtu.be/nxHKBq5ZU9U?t=1168) C 是 WISC 最短的节——Cole 明确说"the best compression strategy is not in needing compression"([21:32](https://youtu.be/nxHKBq5ZU9U?t=1292))。前三条做得好,基本不需要进这一层。 真要压,优先级是: 1. **/handoff**(自定义)——按你定义的工作流写摘要,完全可控,适合多 session 协作交接; 2. **/compact**(内置)——模型自己摘要,优点是省事,缺点是细节丢失;但可以加 summarization instructions(如 "focus on the edge cases that we just tested")来引导; 3. **新开 session**——Cole 经验:连续压缩超过两次,这会话基本已经过度膨胀,直接开新会话把 handoff 文档带过去最干净。「the handoff especially when you run into a compaction more than twice」([21:03](https://youtu.be/nxHKBq5ZU9U?t=1263))。 压缩后建议再追问一句"What do you remember here?"——验证 agent 真的消化了摘要,而不是压缩完它就开始基于错误记忆干活。 ## 可执行步骤 - [ ] 把当前项目的 commit message 格式定下来:前缀(模块/类型)+ 业务变更 + agent 层改进,所有提交都走同一条 slash command 强制规范。 - [ ] 下次写代码前,先开一个独立的"规划 session"——用 subagent 跑研究,产出结构化 plan markdown;再开第二个"实现 session",只把这份 plan 喂进去。 - [ ] 长会话(超过 5-6 轮工具调用)主动跑一次 `/context` 看用量比例,临近 50% 就 `/handoff` 写一份摘要,开新会话接续。 - [ ] 规划阶段涉及大段研究/调研时,prompt 里直接让 agent 并行 spin up 多个 subagent(参考视频里的"spin up two sub agents"句式)干脏活,主会话只接汇总;涉及大段文档加载时,先派 scout subagent 探明该加载哪几份。 - [ ] 把上下文分四层组织:CLAUDE.md(global, 500-700 行内)/ 模块 rules / skills / prime commands;检查是否有本可以移出 global 的内容在吃预算。 - [ ] 真的需要 /compact 时,带 summarization instructions(例:用 Cole 自己的句式"focus on the edge cases that we just tested"),压完追问一句 "What do you remember here?" 验证。 ## 关联 - 进阶:[[2026-06-25-Harness为王的能动工程大师课]] 是同频道 Cole 上一节"为什么 harness 占 90%"的心智铺垫片,先读它建立"harness 决定上限"的整体观,再看本片的具体四策略,前后呼应、互不重叠。 - 互补:[[2026-06-30-给编码agent一张代码库地图codebase-memory-MCP]] 演示的"程序化建图 + pre-tool-use hook 机械注入"是"工具调用时被动探路",本片 Scout 模式是"会话开头主动探路"——两层探路分工互补,前者保证每次读文件都拿到依赖关系,后者保证规划时不带无关文档。 - 印证:[[2026-01-19-Claude Code 完全解读]] 给 [[Context Rot]] 一个可操作阈值(20 万 token 用量过半即劣化);本片主张 W/I/S/C 四策略都在为这个阈值服务,两片合起来给出"诊断 + 处方"对照。 - 印证:[[2026-06-09-Skill 按需加载 vs agents.md 每轮注入]] 用 944→53 token 实测把"skill 比 agents.md 省 90%+"量化出来;本片 S 节把这条权衡扩成 4 层(再加 on-demand 文档与 prime 命令),与该实测一致,只是层级更细。 ## 一手来源与延伸 - GitHub 资源仓库(Cole 视频配套命令与文档):https://github.com/coleam00/context-engineering-intro/tree/main/use-cases/ai-coding-wisc-framework - Chroma 上下文腐化研究(理论背书,解释"窗口大 ≠ 表现好"):https://research.trychroma.com/context-rot - Anthropic 上下文工程指南(与本片核心主张同源):https://www.anthropic.com/engineering/effective-context-engineering-for-ai-agents ## 术语 - WISC 框架(Write/Isolate/Select/Compress):Cole 提出的四类上下文管理策略总称,本片整套体系框架名 - 上下文腐化(Context Rot):上下文塞入越多信息,模型表现越差的现象,本片核心病根 - 大海捞针(needle in a haystack):长上下文中检索单个信息的能力测试,本片论证 context rot 用的基准 - Handoff 命令(移交):把当前会话进度整理成 markdown 供新会话接续的 slash command,优先于内置 /compact - Prime 命令(探路):会话开头跑、让 subagent 现探代码库当前状态再开始规划的命令 - Scout 模式(探路模式):用 subagent 提前探明"哪些文档/资料值得加载进主 context"再决定投入的隔离模式 - 进度文件(Progress Files):handoff.md / todo.md 这类在多 session / 多 subagent 间传递决策的 markdown 文件 - Vercel Agent Browser:Cole 在视频里用 Vercel 出的 CLI 浏览器 agent 跑端到端测试,作为长会话 handoff 的实际案例 ## 金句 > "I would go so far as to say that about 80% of the time when your coding agent and messes up in your code base, it's because you aren't managing your context well enough." — [02:25](https://youtu.be/nxHKBq5ZU9U?t=145) 把这句话记牢,它解开了 80% 的"为什么我的 agent 突然变笨"——不是模型突然变差,是你上下文管理没跟上。 > "the best compression strategy is not in needing compression." — [21:32](https://youtu.be/nxHKBq5ZU9U?t=1292) 整片的元主张:W/I/S 做得好,C 这一层基本空着;压缩只是兜底,不是日常。 ## 立场与利益 **与利益同向(待印证)**:WISC 框架命名本身(Write/Isolate/Select/Compress)与整套"2000 小时实战"叙事是 Cole 的个人品牌标签——他用这个框架包装自己后续的课程与社区([Dynamous Community + Agentic Coding Course](https://dynamous.ai/agentic-coding-course)),"4 类策略"的具体内容广泛见于 Anthropic / 多位独立讲者,框架名则为他独家。 **利益中性(可独立验证)**:四类策略的具体内容——Git 当长期记忆、规划/实现拆 session、subagent 隔离研究、四层上下文、压缩边界——均有 Anthropic 官方上下文工程指南(见下方「一手来源与延伸」节)、Chase·Claude Code 六个层级、Greg·AI Agent 与 Claude Skill 工作原理等独立信源印证,采信不依赖 Cole 买课。 **与利益反向(高可信)**:`13:53` 处 Cole 明文"I don't recommend them for implementation"——明确告诉观众 subagent **不**适合用于实现阶段,这条劝退法与卖课(教越多用法越好)动机反向,是边界上的诚实声明。 利益证据:本片 description 含两条 dynamous.ai 导流(免费 workshop + 付费课程),GitHub 仓库也指向 Cole 自己的 context-engineering-intro 仓库。 ## 价值定位 - **适合谁**: 已经在用 Claude Code 做真实中型以上代码库(多 repo / 相似模式多)、被 agent 反复出错或"上下文塞爆"折腾过的中高级用户;不是给完全没碰过 Claude Code 的人。 - **解决什么**: 把"上下文怎么管"从经验主义浓缩成 4 类可独立修炼的策略,每类给出具体命令(/commit /plan /handoff /prime)与 GitHub 配套资源;尤其能解决"session 越聊越笨"与"研究成本爆高"两类典型痛点。 - **认知 vs 实操**: 偏认知(每条策略的"为什么这样做"讲得透)+ 给实操钩子(具体命令 + 公开 GitHub repo)。视频内只在 Arkon 项目上演示了一遍完整流程,真要落地仍需对照自己项目改写。 - **本片独有**: 把"上下文管理"切成 W/I/S/C 四类并以 Cole 独家命名——其中 S 节把"按需加载"从 [[静态上下文与动态上下文]] 的二分扩到 4 层(global / on-demand / skill / prime),并把"prime 命令"作为会话开头现探的具体手法明示;其他笔记少有把"按需加载"拆这么细。 ## 自检问题 1. 80% 的编码 agent 失误,本片认为真正的根因是什么?为什么 1M token 窗口没有改变这个事实? **答案**:上下文管理差([[Context Rot]]),不是模型差;窗口扩大只把可用占比拉低,劣化按相对占比触发不随窗口标称容量改变——所以扩窗不解。锚定:详解1。[02:25](https://youtu.be/nxHKBq5ZU9U?t=145) 2. Git 日志能当 agent 长期记忆的关键前置条件是什么? **答案**:commit message 标准化、够详细,让下一轮 session 能直接读 commit 判断"主人最近在忙啥"。锚定:详解2。[08:42](https://youtu.be/nxHKBq5ZU9U?t=522) 3. 规划阶段为什么不能和实现阶段共用一个 session?Cole 的标准做法是什么? **答案**:规划阶段会塞入大量研究信息作为上下文污染稀释实现阶段注意力;标准做法是规划 session 跑完 `/plan` 生成结构化 markdown,实现 session 只把这份 plan 喂进去,其余一概不带。锚定:详解3。[08:49](https://youtu.be/nxHKBq5ZU9U?t=529) 4. Subagent 最适合干的两类活分别是什么?Cole 给的具体数据是什么? **答案**:研究(隔离几万/几十万 token 脏活,主会话只接几百 token 总结)+ 探路(scout 模式,先决定哪些文档该加载);不适合实现。Anthropic 数据给 90.2% 的主窗口 token 节省改进。锚定:详解5。[12:03](https://youtu.be/nxHKBq5ZU9U?t=723) 5. 上下文分四层加载,按"常驻度"从高到低怎么排?为什么四层用得好就基本不需要 C(压缩)? **答案**:global rules(恒定,500-700 行)→ on-demand context(模块级)→ skills(按触发,name+description 始终加载)→ prime commands(会话开头现探)。四层用得越细主 context 越瘦,[[Context Rot]] 触发概率越低,反过来 C 几乎用不上。锚定:详解6。[16:01](https://youtu.be/nxHKBq5ZU9U?t=961)