编程Agent上下文太满，先清理什么

你还没输入第一句需求，编程 Agent 的上下文可能已经装进了项目规则、记忆和工具信息。之后每次读文件、跑测试、查看日志，都会继续挤占空间。作者的主张很明确：想让 Agent 更准确地完成任务，先检查它已经读了什么，再决定删什么。

这篇文章用 Claude Code 的加载机制，整理出一套从工具、规则到历史对话的清理顺序。它值得读的地方，是把「上下文太长」拆成了可检查的问题；需要保留判断的地方，是文中没有提供清理前后的效果对照。

先看占用，别把上下文优化做成删文件比赛

作者引用 Anthropic 对「上下文腐化」（context rot）的解释：窗口里的 token 越多，模型准确找回信息的能力可能越差。能装下，并不代表能同样有效地使用。模型需要从大量内容里辨认当前任务的重点，无关信息也会消耗注意力。

优化目标应该是保留足够完成任务的高价值信息，而不是单纯追求更短。

所以第一步是运行 /context，查看实时分类占用、优化建议，以及实际加载的 CLAUDE.md 和自动记忆文件，再记下最大的三个类别。先处理占用大、当前又用不上的内容，比凭感觉缩短提示词更有针对性。

按原文引用的文档，启动阶段会加载 CLAUDE.md，或替代它的 AGENTS.md，以及自动记忆；用户配置的输出风格、--append-system-prompt 文本也会进入上下文。即使当天只改一个函数，这些内容仍可能先占上一块空间。

工具也要查，但别把「连接了 MCP」直接等同于「全部工具定义已经塞进窗口」。原文称 Claude Code 默认开启工具搜索，启动时主要放入工具名称和服务器说明，完整定义等需要时再加载。不过，闲置服务器仍有成本，功能重叠也会增加选择难度。

作者建议用 /mcp 关闭无关服务器，能用 CLI 时考虑 gh、aws、gcloud、sentry-cli。理由是它们不需要额外列出每个工具。若 tools 类别异常大，还应检查工具搜索是否关闭：旧模型、部分云部署，以及 ENABLE_TOOL_SEARCH=false 都是文中列出的可能原因。

这里还有一个实用判断：如果工程师自己都说不清两个工具分别该在什么时候用，也很难指望 Agent 稳定选对。自建 MCP 时，描述和服务器说明应简短，关键用途放在开头，方便工具搜索识别。

规则要按需加载，但全程约束必须留在根目录

规则文件的问题，是它们容易从项目约定长成操作手册。架构说明、迁移流程、PR 审查步骤都放进去，每次小修改也要一起加载。

原文引用的建议是：每个 CLAUDE.md 控制在 200 行以内。这个数字适合当检查提醒，不能当效果保证。用 import 拆文件只改善组织方式，被导入的内容仍会加载，上下文成本并没有消失。

作者给出的分流方式是：与文件路径相关的约定放进 .claude/rules/，匹配时加载；长篇审查或迁移流程放进 skill，需要时再调用。这里说的主要是延迟加载完整流程，不能据此推断所有 Agent 的 skill 名称和描述都没有启动成本。

下面这段配置把 API 规则限定到 src/api/**/*.ts：

---
paths:
  - "src/api/**/*.ts"
---

## API rules
- Every endpoint validates input with the shared schema.
- Errors use the standard error response format.

要看的是 paths：它决定规则何时进入上下文。这种拆法适合局部约定，但作者也提醒，路径规则在压缩后的恢复方式与根目录指令不同。

按原文引用的 Claude Code 文档，压缩后，项目根目录的 CLAUDE.md、不限定路径的规则和自动记忆会重新注入；路径规则和嵌套的 CLAUDE.md 会被归入摘要，之后再次触及匹配文件才重新加载。

此外，Claude Code 最多重读五个最近修改且使用过的文件；超过 5,000 tokens 的文件只恢复路径引用，不恢复全文。已经调用的 skill 正文会重新注入，但存在上限，截断时保留开头。

因此，需要贯穿整个会话的约束，应放在根目录文件里；skill 的关键指令应写在前面。别为了减少启动占用，把必须持续生效的规则也拆走。

任务描述同样影响读取量。作者对比了「改进这个代码库」和「给 auth.ts 的登录函数增加输入校验」。后者明确了入口，更容易减少无关扫描。对程序员而言，先给文件、函数和目标行为，通常比让 Agent 自己猜范围更可控。

日志和历史要分开处理，压缩也有成本

测试输出和日志，是另一类容易被忽略的占用。一条失败原因可能埋在几千行输出里，而 Agent 会把整段工具结果带进后续工作。

作者提供两种处理办法。第一种是在内容进入模型前过滤：原文提到用 PreToolUse hook 改写测试命令，只保留失败信息，或从 10,000 行日志中筛出 ERROR。第二种是交给子 Agent，让它在独立窗口里读测试、文档和日志，再返回摘要。

子 Agent 的请求仍计入用量，它解决的是主会话被原始输出淹没的问题。过滤也需要留余地：只剩错误关键词，可能丢掉错误发生前的条件。工程上更适合先收窄输出，证据不足时再展开。

历史对话则要区分两种情况。任务已经切换、无需连续性，就用 /clear；需要以后找回，可以先 /rename，之后 /resume。原文称 /clear 本身不产生模型请求，而 /compact 要读取整段待总结对话，因此压缩本身也是一次较大的请求。

需要保留进度时，可以给压缩指定重点：

/compact focus on the auth bug fix

关键是 focus on the auth bug fix，它明确了摘要应围绕什么保留信息。自动压缩只能推测重点，显式指定任务更容易保住相关线索。原文还建议在 CLAUDE.md 的 Compact instructions 中设置长期偏好，例如关注测试输出和代码修改。

对于自建 Agent，作者归纳了三种办法：压缩历史，把结构化笔记写到窗口外的文件，以及用独立上下文的子 Agent 分担工作。它们分别处理历史长度、状态保存和任务隔离，可以按问题组合使用。

我的判断

我赞同这套顺序：先看真实占用，再关闭闲置能力、调整加载时机，最后处理工作输出和历史。它把优化对象从用户输入的几句话，扩展到了 Agent 实际接收的整包信息。

但文中主要是文档机制整理和操作建议，没有作者团队清理前后的 token 数据、任务成功率或错误率对照。「CLI 更省上下文」「指定重点比自动压缩更好」可以作为排查方向，不能直接当成所有项目都成立的效果结论。

尤其别把 200 行当硬指标。规则是否清楚、是否重复、能否在正确时机加载，比行数本身更重要。相比一律缩短文件，按任务选择信息更有价值；相比不断 /compact，无关任务直接开启干净会话也更省事。

该删的是与当前任务无关的负担，该保留的是完成任务所需的约束和证据。

能拿来做什么

• 下次排查 Agent 漏要求、选错工具或反复读文件时，先运行 /context，记下最大的三个类别；完成一轮调整后再运行一次，比较占用变化，同时检查它有没有漏掉必要规则。
• 给前端或 Node 项目整理指令时，把全程约束留在根目录，把接口目录的校验约定放进路径规则，把偶尔使用的迁移、审查流程放进 skill，并将关键要求写在开头。
• 提交 AI 编程任务时，尽量写清文件、函数和预期行为；测试输出太长时，先提供失败摘要和相关日志，需要追查再补充上下文。
• 无关任务之间使用 /clear，同一问题需要延续时使用带重点的 /compact，并在压缩后确认关键约束和当前修改状态仍然可用。