--- title: '静态上下文与动态上下文(Static / Dynamic Context)' concept: 静态上下文与动态上下文 aliases: [静态上下文与动态上下文, 静态/动态上下文, Static Context, Dynamic Context] type: 概念页 sources: - 01-学习笔记/seo/bytegrad/2026-01-27-用Remotion加Claude Code提示词生成宣传视频含VPS部署.md - 01-学习笔记/ai/chase-ai/2026-03-08-Claude Code 六个层级.md - 01-学习笔记/ai/greg-isenberg/2026-04-08-AI Agent 与 Claude Skill 工作原理.md - 01-学习笔记/ai/cole-medin/2026-05-21-Anthropic大型代码库Agent Harness大师课.md - 01-学习笔记/ai/ras-mic/2026-06-09-Skill 按需加载 vs agents.md 每轮注入.md - 01-学习笔记/ai/cole-medin/2026-06-25-Harness为王的能动工程大师课.md topics: [Agent 工程, Claude Code 工作流, Claude Code 定制扩展, 多 Agent 协作, MCP 与工具调用, AI 编程与建站, 建站与技术栈, 商业模式与变现] promoted: 2026-07-07 --- > **术语判别**:中文圈已有完整对等词,**中文化为主**;英文 Static Context / Dynamic Context 作为别名保留,用于学术引用或与英文社区对齐时。 ## 定义 把 agent 加载信息的方式切成两类:**静态上下文** = 每次会话都保证加载的恒定内容(规则、system prompt、CLAUDE.md / agent.md),可靠但持续占用窗口;**动态上下文** = 只在需要时按需加载的内容(skills、LSP、hooks、特定代码区约定、子目录 CLAUDE.md),省窗口但风险是 agent 可能在该调用的时候没主动取。 这条权衡直接决定架构走向:多花静态上下文养一群**专精 agent**(每个自带完整静态上下文),还是少占静态、靠动态技能堆出**通才 agent + skills**。两类解法在不同任务重合度下各有最优。 ## 各信源立场对照 | 信源 | 立场/侧重 | 锚点 | 采信 | |---|---|---|---| | ByteGrad·Remotion+Claude Code | 唯一从营销视频生成业务场景切人的:Remotion skill "只在提示词相关时才拉进 context、保持 context 干净" 是按需加载的具体落地 | [6:46](https://youtu.be/y-pxNV0IyTY?t=406) | 利益中性,推自家课程但机制与 VPS 赞助无关 | | Chase·Claude Code 六个层级 | skill 本质只是文本 prompt,只预加载名称+简介、完整内容按需调用;补 ETH Zurich 研究:滥用 static context 收益微弱、推高 20%+ 推理成本 | [20:21](https://youtu.be/TUKYbUIXLOE?t=1221) | 利益中性,推付费课但量化数据可独立验证 | | Greg·AI Agent 与 Claude Skill 工作原理 | "95% 的人不需要 agent.md"——例外只有公司专有信息、必须每次引用的方法论;agent.md vs skill 即静态 vs 动态的教科书对照 | [2:06](https://youtu.be/S_oN3vlzpMw?t=126) | 利益中性,无付费课程核心观点属跨工具共识 | | Cole·大型代码库 Harness 大师课 | 在大型代码库场景细化分层:global rules(静态)/ skills·LSP·hooks(动态)/ 子目录 CLAUDE.md(按位置叠加的动态),把"按需"从 skill 扩到 hook 与位置感知加载 | — | 利益中性,推广插件咨询但 7 层框架源自官方 | | Ras Mic·Skill vs agents.md | 944→53 token 实测:三个 skill 叠加只占百级 token,放 agents.md 占近千;动态加载释放 context 预算、避免冗余信息稀释注意力 | [1:46](https://youtu.be/2Wu2OvRLiJc?t=106) | 利益中性,token 量化选型主张利益中性 | | Cole·Harness 为王 | **首见**:static context 每次保证加载、可靠但一开始就占窗口;dynamic context 按需加载、省资源但风险是 agent 可能在该调用时不会主动去取 | [17:14](https://youtu.be/zbmuiaPuiNM?t=1034) | 利益中性,有赞助贴片但关键主张独立印证 | ## 分歧与共识 - **共识**:每次都加载 ≠ 按需加载,二者各有代价;大多数规则 / 方法论不该放进 CLAUDE.md / agent.md 这种恒定上下文;触发频率低、专业度高的内容适合做成 skill 等按需模块;少占窗口 = 省 token + 留注意力给当前任务。 - **分歧 / 侧重**: - **给"不该塞静态"的不同粒度证据**:Greg 给"95% 不需要 agent.md"的硬阈值;Chase 用 ETH Zurich 量化"滥用 static context 推高 20%+ 推理成本";Ras Mic 用 944→53 token 实测把权衡具体化——三者互补,无冲突。 - **"按需"的范围**:Cole 在大型代码库场景把"动态"从 skill 扩到 LSP、hooks,以及"按目录位置叠加的子目录 CLAUDE.md"——按需不只是"按触发",还可以"按位置"。 - **动态上下文的隐性风险**:Cole 在 Harness 课里点出 dynamic context 的可靠性格栅——"agent 可能不会在该调用的时候主动去取",skill 描述写得不够明确时就会漏触发。这是按需加载的代价,不能用"换 skill"绕开,只能靠写好 description 缓解。 - **场景差异**:ByteGrad 是唯一非编程场景(营销视频生成),但落到"skill 按需触发" 的描述与其他源一致,说明这条权衡在 Claude Code 之外的 skill 化工作流里同样成立。 ## 怎么用 - **少占静态上下文**:默认不要把规则、风格、领域知识塞进 CLAUDE.md / agent.md;同一文档被每次会话加载,既稀释注意力、又推高 20%+ 推理成本(Chase 引 ETH Zurich)。例外才放:公司专有信息、必须每次都引用的个人方法论(Greg 的 5% 阈值)。 - **专业知识做成 skill**:跨项目、偶发触发的知识做成 skill——name+description 始终预加载(几十 token)、正文按需触发(几百 token)。Ras Mic 实测三个 skill 叠加只占百级 token,远小于把这些内容塞 agents.md 的近千 token。 - **写好 skill 描述保可靠性**:按需加载的代价是 agent 可能漏触发(Cole 在 Harness 课点出的格栅)。description 必须明确"何时该用",否则"该调时不调" 风险会成真。 - **多 agent vs 通才 agent**:按这条权衡分流——专精多 agent = 每个 agent 自带完整静态上下文;通才 agent + skills = 中心 agent 配大量按需模块。选哪条取决于任务重合度与配置成本,本概念给的是判断准则而非唯一答案。 ## 适用边界 - **5% 例外之外别塞 agent.md**:Greg·2:06 明示"95% 的人不需要 agent.md",只有公司专有信息和必须每次都引用的方法论才是合法理由——其余规则 / 风格 / 领域知识塞进恒定上下文属滥用。 - **dynamic context 漏触发是内生风险**:Cole 在 Harness 课点出"agent 可能在该调用的时候没主动去取"——按需加载的代价不可消除,只能用"写好 skill description"缓解,不能用"换 skill"绕开。 - **滥用 static context 会推高推理成本**:Chase 引 ETH Zurich 量化"滥用 static context 推高 20%+ 推理成本"——CLAUDE.md / agent.md 塞越多不必然越好,持续加载的代价是真实的。 ## 关联 - [[渐进式披露]] — 互补:静态 / 动态上下文 是按需加载的"上层分类",渐进式披露是其下的具体落地动作——同一个权衡的两面(本页与[[渐进式披露]]页都已明文点出)。 - [[Harness]] — 印证:Harness 是你为 AI 编码助手搭的上下文 / 规则 / 工具 / workflow 的集合;静态 / 动态上下文 是该集合中"上下文管理"维度的具体切片——Harness 是上位概念,本概念是其下分类。 - [[Context Rot]] — 互补:static context 堆得越多、用得越满,context 越长越易触腐化阈值——分类是策略、腐化是后果,二者共同构成"context 工程"。