Claude 用着用着就变笨？试试这个上下文治理的”减法”框架

Claude 用着用着就开始变笨?不是你 prompt 写错了,是上下文窗口炸了。这是我最近跑长会话时最痛的体感 —— 工具调用累积的输出能占 80% token,旧对话轮次层层堆叠,结果 Claude 开始丢三落四,质量肉眼可见往下掉。

今天安利一个我私藏很久的 Skill:reduce-delegate-framework,直接给我提供了”上下文治理”的系统化思维 —— 一句话:要么减少,要么委派,二选一。

这框架到底解决什么问题?

它的核心洞察是:管理上下文窗口只有两条路 —— Reduce(削减无关内容)或 Delegate(把子任务交给子 Agent)。把这两条穷举清楚,任何上下文问题都能套进来。

整个工作流拆成 5 步:

• 测量基线:用 /context 命令看 token 占用,定位大头在哪
• 诊断问题:区分 Context Rot(旧信息污染)、Pollution(跑题)、Toxic(自相矛盾)、Overflow(容量不够)
• 执行 Reduce:删冗余、起新会话、收缩输出风格、关掉不用的 MCP
• 执行 Delegate:研究/调研类任务派给子 Agent 隔离上下文
• 验证效果:对比优化前后的 token 与质量,确认改善幅度

为什么这框架对长会话 Agent 特别管用?

传统 prompt 工程只关心”怎么写指令”,这个 Skill 直接把视角拉到上下文生命周期管理。它给出的 4 种具体诊断(Context Rot / Pollution / Toxic / Overflow)+ 对应的 Reduce/Delegate 决策矩阵,基本就是一份 Agent 上下文优化的 SOP。

实测数据:合理的 Reduce + Delegate 组合能让上下文占用降 40-60%,同时保持响应质量不降。对生产环境的 Agent 系统尤其有用 —— 不用买更大的 context window,也不用换更贵的模型,光靠上下文管理就能把成本压下来。

怎么用?

这个 Skill 集成在 majiayu000/claude-skill-registry(570+ stars 的 Claude Skills 注册中心)里,装上之后 Claude 会在上下文接近溢出时自动调用。也可以在 prompt 里直接说”用 reduce-delegate-framework 帮我优化下对话上下文”。

说真的,现在做 Agent 工程的人,不优化上下文就是在烧钱。这条 Skill 给我打开了新世界,推荐给所有跑 Claude Code 长会话的人。

👉 GitHub 仓库

GitHub: https://github.com/majiayu000/claude-skill-registry/tree/main/skills/other/reduce-delegate-framework