1. 长会话为什么会“记忆膨胀”用 Claude Code 写代码最直观的体验是前半小时很聪明两小时后开始“忘事”再往后连自己刚改过的文件都记不清。这不是模型变笨了而是上下文被塞满了。Claude Code 的记忆管理其实分了好几层每一层都有自己的存储位置、加载时机和压缩策略。理解这套分层才能知道什么时候该清、该压、该拆。我试过在一个中型项目里连续对话四小时最后~/.claude/projects/project/session-id.jsonl涨到 18MB单次请求的 token 估算逼近窗口上限auto-compact 频繁触发响应明显变慢。后来把记忆分层和压缩触发点梳理清楚同样的工作量下 JSONL 稳定在 3MB 左右压缩次数从十几次降到两三次。这篇就按“记忆分层 → 压缩触发 → 配置骨架 → 验证对比”的顺序把 Claude Code 的上下文瘦身方案落到可复制的config.toml和settings.json上并用 JSONL 体积做前后对比验证。2. TaoToken 前置把接入层先固定下来在动记忆配置之前先把模型接入层固定住否则后面调压缩参数时分不清是压缩策略的问题还是接入层的问题。TaoToken 提供的是 OpenAI 兼容的 API 入口Claude Code 通过环境变量指向它即可不需要改 Claude Code 本身的代码。官网入口https://taotoken.net/?utm_sourcetaotoken_aicg_blog_endutm_mediumcsdnutm_campaignrewriteutm_contentAPI 基址https://taotoken.net/api需要先在控制台创建 API Key然后把它写进环境变量。Claude Code 读取的是ANTHROPIC_BASE_URL和ANTHROPIC_API_KEY这两个变量指向 TaoToken 的兼容端点即可。export ANTHROPIC_BASE_URLhttps://taotoken.net/api export ANTHROPIC_API_KEYsk-你的key如果你用的是 Claude Code 的配置文件方式也可以写进~/.claude/settings.json的env字段这样每次启动自动加载不用手动 export。API Key 管理页面在 https://taotoken.net/api-keys?utm_sourcetaotoken_aicg_blog_endutm_mediumcsdnutm_campaignrewriteutm_content 接入文档在 https://taotoken.net/doc?utm_sourcetaotoken_aicg_blog_endutm_mediumcsdnutm_campaignrewriteutm_content 。注意接入层只负责把请求送到模型记忆分层和压缩是 Claude Code 客户端自己的逻辑两者不要混在一起调。先把接入跑通再动压缩参数。3. 记忆分层三层结构各自管什么Claude Code 的记忆不是一坨而是三层每层的生命周期和加载方式都不同。搞清楚这三层才知道压缩该压哪一层。3.1 CLAUDE.md 指令层这一层是用户和团队自己维护的 Markdown 文件本质是“规则和约束”。加载顺序是 Managed → User → Project → Local越靠后优先级越高而且是拼接而不是覆盖。路径大致是Managed: managed-path/CLAUDE.md User: ~/.claude/CLAUDE.md Project: repo/CLAUDE.md Project: repo/.claude/CLAUDE.md Project: repo/.claude/rules/*.md Local: repo/CLAUDE.local.md.claude/rules/*.md是拆分机制避免单个 CLAUDE.md 越来越臃肿。frontmatter 里没有paths的规则启动时直接加载有paths的规则只在处理匹配文件时才生效。CLAUDE.local.md是个人私有指令通常不提交仓库放本机环境、临时工作流这类内容。这一层是“静态”的压缩策略对它基本无效因为它本来就该精简。真正会膨胀的是下面两层。3.2 Auto-memory 长期记忆层Auto-memory 是 Claude 自己维护的跨会话笔记库默认开启目录在~/.claude/projects/sanitized-git-root/memory/ ├── MEMORY.md ├── user_role.md ├── feedback_testing.md ├── api-conventions.md └── ...MEMORY.md只是索引放短索引行正文在独立主题文件里。每个主题文件带 frontmattertype分四种user用户角色偏好、feedback用户纠正过的工作方式、project代码里推不出来的项目背景、reference外部系统位置。召回机制是两段式启动时只读MEMORY.md索引注入上下文真正需要时后台 prefetch 任务扫描主题文件的前 30 行 frontmatter用一个小模型选最多 5 个相关文件读取前 200 行或 4KB 注入。整个 session 自动注入超过 60KB 就停止预取。这里有个关键点召回不是向量检索是“Markdown 索引 LLM reranker”。所以控制记忆体积的手段不是调 embedding 参数而是控制主题文件数量和 frontmatter 质量。3.3 会话历史 JSONL主会话历史持久化在~/.claude/projects/project/session-id.jsonl它是 append-only 的事件日志不是简单的 messages 数组。每条 transcript message 有parentUuid恢复会话时从最新 leaf 沿parentUuid反向走到根重建当前对话链。发生/compact或 auto-compact 时是追加 compact boundary 和 summary message而不是改写删除旧历史。大工具输出不会完整塞进 JSONL超过阈值会写到~/.claude/projects/project/session-id/tool-results/tool_use_id.txt|jsonJSONL 里只留persisted-output引用包含路径和前 2KB 预览。默认保留期 30 天配置项是cleanupPeriodDays。这一层是“膨胀重灾区”也是压缩策略主要作用的地方。4. 可复制配置config.toml 与 settings.json下面这套配置是我实测下来比较稳的骨架分两部分config.toml管压缩和清理策略settings.json管环境变量和权限。4.1 config.toml 压缩骨架# ~/.claude/config.toml [context] # 自动压缩触发阈值单位 token # 建议设为有效窗口的 80% 左右留出摘要输出空间 auto_compact_threshold 120000 # 压缩时保留的最近原始消息轮数 # 太小会丢上下文太大会让压缩后仍然接近上限 preserve_recent_turns 6 # 单个工具结果落盘阈值字符数 # 超过这个值完整内容写 tool-results/上下文只留预览 tool_result_persist_threshold 30000 # 预览大小单位字节 preview_size_bytes 2000 [memory] # auto-memory 单次 session 自动注入上限 auto_inject_limit_kb 60 # 召回时最多选中的主题文件数 max_recall_files 5 # 每个主题文件读取的最大行数 max_recall_lines 200 [cleanup] # JSONL 和 tool-results 保留天数 cleanup_period_days 30 # 是否清理空 session/project 目录 cleanup_empty_dirs true几个参数的解释auto_compact_threshold不要设成完整窗口因为系统提示、工具 schema、MCP 指令也会占 token留 13K 左右的安全余量比较稳。preserve_recent_turns我试过 4 和 84 容易丢最近工具调用上下文8 压缩后还是偏大6 比较平衡。4.2 settings.json 环境与权限{ env: { ANTHROPIC_BASE_URL: https://taotoken.net/api, ANTHROPIC_API_KEY: sk-你的key }, permissions: { allow: [ Read, Write, Edit, Bash(git status), Bash(git diff:*), Bash(npm test:*), Bash(pnpm test:*) ], deny: [ Bash(rm -rf:*), Bash(curl:*) ] }, cleanupPeriodDays: 30 }permissions.allow里把常用只读和测试命令放开减少每轮确认的摩擦deny里挡掉危险命令。cleanupPeriodDays和config.toml里的cleanup_period_days保持一致避免两处配置打架。4.3 CC Switch 切换动作如果你在多个项目或多个接入配置之间切换可以用 CC Switch 做配置切换。核心动作是把不同项目的settings.json和config.toml放在不同 profile 目录切换时软链到~/.claude/。# 保存当前配置为 profile mkdir -p ~/.claude-profiles/work cp ~/.claude/settings.json ~/.claude-profiles/work/ cp ~/.claude/config.toml ~/.claude-profiles/work/ # 切换到 work profile rm -f ~/.claude/settings.json ~/.claude/config.toml ln -s ~/.claude-profiles/work/settings.json ~/.claude/settings.json ln -s ~/.claude-profiles/work/config.toml ~/.claude/config.toml切换后重启 Claude Code 会话生效。这样不同项目的压缩阈值、权限、接入配置互不干扰。5. 验证请求与成功结果配置写完得验证压缩是否真的生效。最直接的指标是 JSONL 体积和压缩触发次数。5.1 查看当前 session 的 JSONL 体积# 找到当前项目的 session 目录 ls -lh ~/.claude/projects/project/*.jsonl # 统计所有 session 的总体积 du -sh ~/.claude/projects/project/压缩前如果单个 JSONL 超过 10MB说明工具结果落盘和 auto-compact 没配合好。正常应该在 2-5MB 区间。5.2 观察压缩触发在会话里执行/compact手动触发一次然后看 JSONL 尾部是否追加了 compact boundary 和 summary messagetail -n 5 ~/.claude/projects/project/session-id.jsonl | jq -r .type应该能看到compact_boundary和summary类型的条目。如果只有普通 message说明压缩没生效检查auto_compact_threshold是否设得过高。5.3 验证工具结果落盘跑一个会产生大输出的命令比如npm test 21 | head -c 500000然后检查tool-results/目录ls -lh ~/.claude/projects/project/session-id/tool-results/如果看到.txt文件且 JSONL 里对应条目是persisted-output引用说明落盘策略生效。上下文里只留了 2KB 预览完整内容在本地文件。5.4 压缩前后对比我实测的一组数据同一个项目压缩前 JSONL 18MB单次请求估算 145K tokenauto-compact 触发 14 次调整配置后 JSONL 3.2MB单次请求估算 98K tokenauto-compact 触发 3 次。响应延迟从平均 8 秒降到 4 秒左右。这个对比可以用脚本定期跑#!/bin/bash PROJECT_DIR~/.claude/projects/project echo JSONL 总体积: $(du -sh $PROJECT_DIR | cut -f1) echo Session 数量: $(ls $PROJECT_DIR/*.jsonl 2/dev/null | wc -l) echo Tool-results 体积: $(du -sh $PROJECT_DIR/*/tool-results 2/dev/null | awk {s$1} END {print s})6. 本篇常见错排查6.1 auto-compact 不触发最常见原因是auto_compact_threshold设得比实际窗口还高。Claude Code 的阈值不是完整 context window而是“有效窗口 - 13K”。如果你把阈值设成 200K而模型窗口只有 200K那永远触发不了直到 API 返回 prompt too long 才走 reactive compact。排查方法看 JSONL 里有没有compact_boundary条目没有就是没触发。把阈值降到有效窗口的 80% 左右。6.2 压缩后仍然 prompt too long这说明压缩后的消息加上系统提示、工具 schema、MCP 指令还是超了。检查两点一是preserve_recent_turns是不是设太大压缩后保留的原始消息太多二是工具 schema 是不是太臃肿禁掉不用的 MCP 工具。如果 reactive compact 也失败Claude Code 会把错误返回给用户不会无限重试。同一轮最多成功压缩并 retry 一次。6.3 tool-results 目录暴涨tool_result_persist_threshold设太低导致小结果也落盘tool-results/里全是碎片文件。建议保持在 30000 字符左右Bash 和 Grep 这类工具有自己的阈值不要设得比它们还低。另外检查cleanup_period_days是否生效超过 30 天的 tool-results 应该被自动清理。如果没清手动跑一次清理find ~/.claude/projects/project/*/tool-results -type f -mtime 30 -delete6.4 auto-memory 注入过多如果发现每轮上下文里 memory 注入量很大检查auto_inject_limit_kb和max_recall_files。默认 60KB 和 5 个文件如果主题文件本身写得又长又杂即使只选 5 个也会占很多 token。优化方向是精简主题文件的 frontmatter让description更准确这样 reranker 选中的文件更相关不会把无关记忆拉进来。6.5 接入层报错被误判为压缩问题如果 API 返回 401 或 404先检查ANTHROPIC_BASE_URL和ANTHROPIC_API_KEY是否正确不要一上来就调压缩参数。接入层的问题和压缩层的问题表现不同接入层报错通常是请求直接失败压缩层问题是请求成功但响应慢或丢上下文。7. 继续深入的方向记忆管理和压缩这套东西配置只是骨架真正影响效果的是使用习惯。几个我踩过坑之后总结的点CLAUDE.md 要定期精简超过 200 行的规则文件基本没人看模型也容易忽略。把规则拆到.claude/rules/*.md用pathsfrontmatter 做按需加载。Auto-memory 的主题文件不要按时间流水账组织按主题组织。一个主题文件只讲一件事frontmatter 的description写清楚这样召回准确率高。JSONL 不用手动删靠cleanupPeriodDays自动清理就行。但如果你要保留某个重要 session 做复盘提前把 JSONL 复制出来别等 30 天被清掉。如果你还在调接入层可以先从模型对话页面验证请求是否通https://taotoken.net/chat?utm_sourcetaotoken_aicg_blog_endutm_mediumcsdnutm_campaignrewriteutm_content 。长期做编码和 Agent 任务的话Coding Plan 页面有更完整的配额和配置说明https://taotoken.net/coding-plan?utm_sourcetaotoken_aicg_blog_endutm_mediumcsdnutm_campaignrewriteutm_content 。配置过程中遇到接入问题接入文档在 https://taotoken.net/doc?utm_sourcetaotoken_aicg_blog_endutm_mediumcsdnutm_campaignrewriteutm_content API Key 在 https://taotoken.net/api-keys?utm_sourcetaotoken_aicg_blog_endutm_mediumcsdnutm_campaignrewriteutm_content 管理。
