企业官网建设流程全解析

1. 长会话压缩后，Agent 为什么把你的习惯忘了

用 Claude Code 写代码的人，大概率都遇到过这个场景：会话开头你明确说过「这个项目用 Tab 缩进，字符串统一单引号，测试里别 Mock 数据库」，Agent 也照做了。然后它读文件、跑测试、改代码，几轮下来历史消息触发了上下文压缩。压缩摘要一般会保留当前任务、改过哪些文件、还剩什么待办，但「Tab 缩进」这种细节经常被概括成一句「用户有代码风格偏好」，甚至直接消失。等你让它继续写下一个文件，缩进又变回空格了。

更直接的情况是新开一个会话。上一轮的摘要根本不存在，Agent 对你的项目一无所知，只能重新问一遍代码风格、项目背景、已经确认过的工作方式。长期用下来体验很差，每次都要重复交代。

反过来，把全部历史对话永久塞进上下文也不现实，容量和成本都扛不住。所以真正要解决的问题是：哪些信息值得跨任务、跨会话保留，怎么在需要的时候重新放回当前上下文。这就是 Claude Code 里 Memory 机制要干的事，也是这篇要讲清楚的东西。

这篇适合已经在用 Claude Code、被上下文压缩坑过、想让 Agent 在长会话里持续记住编码偏好的人。我会从 System Prompt 和 Memory 的配合切入，演示怎么用 TaoToken 统一 Key 和 API 通道接入 Claude Code，给出可复制的 settings.json 配置骨架，最后给一套压缩后验证记忆是否保留的动作。全程可以跟着做。

2. 先分清：哪些信息该进 Memory，哪些只属于当前任务

在动手配置之前，得先建立一个判断标准，否则记忆文件会越堆越乱。

有一类信息只服务于当前任务，比如「修复 tests/auth/test_token.py」「重新跑认证模块测试」「检查 token 配置有没有影响其他测试」。这些放在 TodoWrite 或当前会话历史里就够了，任务结束继续保留的价值快速下降。

另一类信息会在后续任务里反复出现，比如「项目使用 Tab 缩进」「不要在测试中 Mock 数据库」「认证模块改造受合规要求限制」「排查数据导入问题时优先看 Linear 里的 INGEST 任务」。这类跨任务、跨会话仍然有用，适合进 Memory。

Claude Code 的 Memory 机制把记忆分成四种类型，这个分类本身不改变模型能力，作用是帮后续加载和整理时区分：这是一条用户偏好，还是一条可能过期的项目事实。

记忆的存储方式是先写入文件，再生成目录。教学实现里把记忆放在项目目录下的.memory/，每条记忆是单独的 Markdown 文件，文件顶部放 YAML Frontmatter：

--- name: user-preference-tabs description: User prefers tabs for indentation type: user --- User prefers using tabs for indentation. Why: Consistency with existing codebase conventions. How to apply: Always use tabs when writing or editing files.

单独存文件有两个好处。第一，某条记忆可以独立更新或删除，不用改一份越来越长的大文件。第二，文件名、描述和类型能组成一个轻量目录，供 Agent 先判断要不要加载。MEMORY.md就承担目录角色：

- [user-preference-tabs](user-preference-tabs.md) — User prefers tabs for indentation - [feedback-no-mock-db](feedback-no-mock-db.md) — Do not mock the database in tests - [project-auth-compliance](project-auth-compliance.md) — Auth rewrite is compliance-driven

程序会把MEMORY.md放进 System Prompt，单条记忆的完整正文留在磁盘上。这样模型每轮都知道有哪些历史信息可用，却不必每次都携带全部正文。这个设计是理解后面配置的关键：System Prompt 里放的是「目录」，不是「全文」。

3. 用 TaoToken 统一 Key 打通 Claude Code 的接入通道

Claude Code 要跑起来，核心是两件事：一个能用的 API 通道，和一份正确的配置。TaoToken 在这里的作用是提供统一的 Key 和 API 入口，让你不用在多个通道之间来回切换，配置一次就能稳定调用。

先拿 Key。打开控制台创建 API Key，地址是 https://taotoken.net/api-keys?utm_source=taotoken_aicg_blog_end&utm_content=api-keys&utm_campaign=rewrite 。创建后复制保存，后面配置里要用到。

如果你还没注册，官网入口在 https://taotoken.net/?utm_source=taotoken_aicg_blog_end&utm_medium=csdn&utm_campaign=rewrite&utm_content= ，注册流程不复杂，这里不展开。

拿到 Key 之后，Claude Code 的接入有两种常见方式。一种是走环境变量，适合临时验证；另一种是写进settings.json，适合长期使用。我建议直接上settings.json，因为这篇的重点是让记忆链路稳定，配置越固定越好。

API 的基础地址是 https://taotoken.net/api ，注意这个地址不带 UTM 参数，配置里直接用它。

这里要提醒一句：TaoToken 是合规的 API 接入服务，配置时按官方文档给的字段填就行，不要自己拼奇怪的地址。接入文档在 https://taotoken.net/doc?utm_source=taotoken_aicg_blog_end&utm_content=doc&utm_campaign=rewrite ，遇到字段不确定的时候对着看。

4. 可复制的 settings.json 配置骨架

下面这份骨架可以直接改。把YOUR_API_KEY换成你刚才复制的 Key，其余字段按你的项目情况调整。

{ "env": { "ANTHROPIC_BASE_URL": "https://taotoken.net/api", "ANTHROPIC_API_KEY": "YOUR_API_KEY" }, "memory": { "enabled": true, "directory": ".memory", "indexFile": "MEMORY.md", "maxLoadedMemories": 5, "consolidateThreshold": 10 }, "context": { "preCompressSnapshot": true, "extractAfterTask": true } }

逐项说明一下，方便你按需改。

env里的ANTHROPIC_BASE_URL指向 TaoToken 的 API 入口，ANTHROPIC_API_KEY填你的 Key。这两个字段是通道能不能通的关键，填错会直接报鉴权失败。

memory.enabled打开记忆功能。directory指定记忆文件存放目录，默认.memory，建议放在项目根目录下，跟代码一起管理。indexFile是目录文件名，程序会把它注入 System Prompt。maxLoadedMemories控制单次最多加载几条记忆，教学实现里是 5，你可以按项目复杂度调。consolidateThreshold是触发合并的条数阈值，到 10 条会执行一次整理。

context.preCompressSnapshot打开压缩前快照。这个字段很关键，原因在下一节讲。extractAfterTask表示任务结束后执行记忆提取。

配置写好后，建议把.memory/加进版本控制，但要注意：记忆文件里可能包含项目背景和排查线索，团队协作时先确认这些内容适合提交。权限规则、生产配置、合规要求这类高风险信息，仍然要放在受版本控制的配置或文档里，不要只依赖自动提取的记忆文件。

5. 为什么提取记忆要用压缩前的消息

这一节解释上面那个preCompressSnapshot字段为什么必须开。

上下文压缩会缩短工具结果，也可能把完整对话替换成摘要。如果记忆提取发生在压缩之后，用户前面说过的偏好可能已经被概括成一段很模糊的话，甚至已经不在消息历史里。提取器从这种历史里工作，很容易写出信息不完整的记忆。

举个例子，用户明确说过「后续修改 Python 文件时统一使用 Tab，保持和仓库现有代码一致」。压缩后的摘要可能只剩「用户有代码风格偏好」。前者能写成可执行的记忆文件，后者没法指导具体编辑行为。保存压缩前快照，目的就是让提取器看到更完整的原始表述。

流程大致是这样：

pre_compress = copy_messages(messages) messages[:] = tool_result_budget(messages) messages[:] = snip_compact(messages) messages[:] = micro_compact(messages) # 模型完成当前任务后 extract_memories(pre_compress)

每轮结束后检查最近十条消息，把已有记忆目录一并交给提取器。提取器返回新记忆时，程序写入 Markdown 文件并重建MEMORY.md。

这里有个取舍要清楚：这个过程依赖模型提取信息，结果不天然可靠。用户偏好、项目事实和一次性任务指令之间的边界，需要靠提取提示词约束，也需要后续整理机制修正。所以别指望它一次就完美，跑几轮之后手动看一眼.memory/里的内容，把明显不对的删掉，是必要的维护动作。

6. 验证请求：压缩后记忆到底有没有保留

配置好了，得验证。下面这套动作可以完整跑一遍。

第一步，启动 Claude Code，输入一条明确的偏好：

I prefer using tabs for indentation, not spaces. Remember that.

任务结束后，终端应该出现类似[Memory: extracted 1 new memories]的提示，同时.memory/下生成对应的 Markdown 文件。打开看一眼，确认 Frontmatter 里的type是user，正文里有可执行的描述。

第二步，触发一次上下文压缩。连续让它读几个文件、跑几轮测试，把历史消息堆到触发阈值。压缩发生后，输入：

Create a Python file called test.py.

观察 Agent 生成代码时用的是 Tab 还是空格。如果它遵循了之前的偏好，说明记忆在压缩后被正确加载了。

第三步，重启程序，再问一次格式偏好：

What indentation style should I use for this project?

如果它能答出 Tab，说明记忆跨会话保留了。这一步是区分「会话内记忆」和「持久记忆」的关键，很多人只测了第一步就以为搞定了，其实跨会话才是 Memory 的真正价值。

第四步，检查.memory/MEMORY.md。目录内容越清楚，相关记忆越容易被选中；单条描述越模糊，模型越难判断它和当前任务是否相关。如果发现某条记忆总是加载不上，先改它的description，写具体一点。

验证模型本身的行为是否符合预期，可以顺手在模型对话里试几条 prompt，地址是 https://taotoken.net/chat?utm_source=taotoken_aicg_blog_end&utm_content=chat&utm_campaign=rewrite ，用来确认通道和模型响应都正常。

7. 本篇常见错排查

配置和验证过程中，几个坑出现的频率最高，列出来对照。

鉴权失败或 401。先检查ANTHROPIC_API_KEY有没有复制完整，前后有没有多余空格。再确认ANTHROPIC_BASE_URL填的是https://taotoken.net/api，不要多加路径或参数。Key 如果泄露过，去控制台重新生成一个。

记忆文件生成了但加载不上。大概率是MEMORY.md目录没更新，或者单条记忆的description太模糊。打开MEMORY.md确认对应条目存在，描述写清楚「这条记忆解决什么问题」。另外检查maxLoadedMemories是不是设得太小，导致相关条目排不进去。

压缩后偏好丢失。确认preCompressSnapshot是true。如果这个字段没开，提取器看到的是压缩后的摘要，信息已经不完整了。另外，如果偏好是在很早的轮次说的，压缩前快照只保留最近消息，也可能漏掉，这种情况建议把稳定偏好手动写进记忆文件。

记忆越积越多、互相矛盾。到阈值会触发合并，但合并本身有风险：模型归纳可能写错，而且教学实现会删除旧文件再写新结果，没有版本控制。所以合并后要人工过一遍。高风险信息不要只放在记忆里。

长会话编码任务想更稳。如果你经常跑长时间的编码或 Agent 任务，可以考虑用 Coding Plan，地址是 https://taotoken.net/coding-plan?utm_source=taotoken_aicg_blog_end&utm_content=coding-plan&utm_campaign=rewrite ，配合统一 Key 用，通道和额度都更可控。

排查顺序建议是：先确认通道通（能正常对话），再确认记忆文件生成（看.memory/），最后确认加载（看压缩后行为）。三段分开查，比一上来就怀疑模型要快得多。

接入相关的字段和报错对照，文档里写得更全，遇到卡住的地方直接查 https://taotoken.net/doc?utm_source=taotoken_aicg_blog_end&utm_content=doc&utm_campaign=rewrite 。Key 管理在 https://taotoken.net/api-keys?utm_source=taotoken_aicg_blog_end&utm_content=api-keys&utm_campaign=rewrite ，需要轮换或新建的时候用得上。

最后说个实际经验：记忆机制不是配好就一劳永逸的。项目在变，半年前记录的入口文件和排查路径可能已经失效。每隔一段时间花几分钟看一眼.memory/，删掉过期的、把模糊的描述改具体，比让它自动合并要靠谱。稳定偏好手动维护，临时任务别往记忆里塞，这条边界守住了，Agent 在长会话里记住你习惯的概率会高很多。