Continuous Claude：解决AI开发上下文压缩痛点的持续学习多智能体系统

躲不过这哀伤

379人浏览 · 2026-04-24 13:07:08

躲不过这哀伤 · 2026-04-24 13:07:08 发布

1. 项目概述：Continuous Claude 的设计哲学与核心价值

如果你和我一样，长期使用 Claude Code 进行开发，一定遇到过这个令人头疼的问题：当你正沉浸在一个复杂的调试或重构任务中，上下文窗口突然满了。Claude 开始“压缩”对话，那些花了几个小时才理清的细微决策、临时的推理路径，瞬间被简化甚至丢弃。下次再打开会话，又得从头开始解释一遍，或者更糟——Claude 已经忘记了之前的关键假设。这不仅仅是浪费了宝贵的上下文令牌，更是对开发者心流和项目连续性的无情打断。

Continuous Claude 正是为了解决这个“上下文压缩”的痛点而生的。它不是一个简单的插件集合，而是一个完整的、持续学习的多智能体开发环境。它的核心思想非常直接： 复合，而非压缩 。与其让 Claude 在上下文满时被动地丢弃信息，不如主动、智能地将一个会话的“学习成果”提取出来，传递给下一个会话。这样，每一次与 Claude 的交互，都建立在前一次的基础上，知识像复利一样积累，系统的整体智能也随之增长。

这个项目的本质，是重新思考了“智能体”的构成。一个真正的智能体是什么？它不仅仅是提示词，也不仅仅是工具。它是一个由 提示词、工具、上下文、记忆和模型 五要素构成的有机整体。Continuous Claude 的优化重心，恰恰放在了前四个要素上，尤其是 上下文 和记忆。它通过一套精巧的钩子（Hooks）系统、技能（Skills）系统和代理（Agents）系统，将 Claude Code 从一个“单次会话工具”转变为一个“持续进化的开发伙伴”。

想象一下这样的场景：你昨天花了一下午修复了一个棘手的并发 Bug，并和 Claude 一起总结出了“在这个代码库中，所有数据库连接池的配置都必须显式设置超时时间”的经验。今天，当你开始处理另一个涉及数据库的模块时，Claude 会自动回忆起这条经验，并在你编写相关代码时给出提示。这就是 Continuous Claude 试图实现的愿景——让 AI 助手真正拥有“工作经验”。

2. 核心系统深度解析：从架构到实现

2.1 技能系统：自然语言驱动的模块化能力

技能是 Continuous Claude 的基石。它们不是需要记忆的斜杠命令，而是对开发者自然语言意图的响应模块。整个系统包含 109 个技能 ，覆盖了从代码分析、风险预判到研究、部署的完整开发生命周期。

2.1.1 元技能：工作流编排器

元技能是高级别的抽象，它们将多个基础技能和代理串联起来，形成完整的工作流。这是你与系统交互的主要入口。

/workflow ：当你不知道从何开始时，这是你的导航仪。它会通过一系列问题，引导你选择最合适的工作流（研究、计划、构建、修复等）。
/build ：用于构建新功能。它支持多种模式：
- greenfield ：从零开始构建全新功能。链式调用 discovery （需求澄清）→ plan-agent （方案设计）→ validate （方案验证）→ kraken （TDD 实现）→ commit （提交）。
- brownfield ：在现有代码库中添加功能。链式调用 onboard （熟悉代码）→ research （研究现有模式）→ 后续流程与 greenfield 类似。
- 你可以通过 --skip-discovery 、 --skip-validate 等标志来定制流程，适应不同熟悉度的任务。
/fix ：专门用于修复问题。其 bug 模式会启动 sleuth （侦探代理）进行根因分析，然后进行 premortem （风险预演），最后由 kraken 实施修复并进行测试。
/explore ：快速理解一个陌生代码库。 quick 模式（约1分钟）给出代码结构概览； deep 模式（约5分钟）会进行更深入的分析并生成文档； architecture 模式则专注于架构层面的分析。

实操心得 ：不要死记硬背命令。尝试用最自然的语言描述你的目标。例如，直接说“我想给用户管理模块加一个搜索功能”，系统会通过技能激活钩子，自动推荐 /build brownfield 工作流，并提示你使用 discovery-interview 技能来细化需求。这种基于意图的交互，极大地降低了认知负荷。

2.1.2 关键技能：高价值工具集

除了元技能，一些独立的“工具型”技能在日常开发中价值极高：

premortem ：这是我最喜欢的技能之一。在任何重要实现之前运行它，它会引导你进行 TIGERS & ELEPHANTS 风险分析（技术、集成、治理、效率、可靠性、安全性等）。它能帮你提前发现那些“事后看来很明显”的盲点。
tldr-code ：代码分析的瑞士军刀。它通过五层分析（AST、调用图、控制流图、数据流图、程序切片）将数万令牌的代码压缩到约1200令牌，节省 95% 的上下文开销。这是实现“上下文高效”的核心。
create_handoff / resume_handoff ：连续性系统的关键。 create_handoff 会将当前会话的状态（思考过程、决策、待办事项）保存为一个结构化的 YAML 文件。下次会话开始时， resume_handoff 可以加载它，让你无缝衔接。
qlty-check ：集成了70多种代码检查器（如 Ruff, Pyright），并支持自动修复。它通常通过 post-edit-diagnostics 钩子在每次代码编辑后自动运行，实现“左移”的质量保障。

2.2 代理系统：专业化的 AI 工作者

如果说技能是工具，那么代理就是使用这些工具的专家。Continuous Claude 内置了 32 个代理 ，每个都专注于特定领域。虽然作者承认数量可能过多（计划在 v4 版本整合），但理解其分类有助于高效使用。

2.2.1 代理分类与选型指南

代理类别	核心代理	核心职责与使用场景
协调者	`maestro`	多代理协作编排，支持管道、群组、评审团等模式。适合复杂、多阶段任务。
规划者	`plan-agent` , `architect`	`plan-agent` 轻量、快速，适合功能设计； `architect` 更重，考虑API集成和系统影响。
探索者	`scout` , `oracle`	用 `scout` 替代 Claude 自带的 Explore 工具。它更快、更深，能生成架构图。 `oracle` 专精外部研究（网页、文档）。
实现者	`kraken`	TDD 实现的黄金标准。严格遵循“红-绿-重构”循环，支持断点续作。几乎所有 `/build` 和 `/fix` 工作流的最终执行者。
调试者	`sleuth`	根因分析专家。通过日志、代码搜索和假设检验来定位问题。是 `/fix` 工作流的起点。
审查者	`judge` , `critic`	`judge` 用于深度、严格的代码审查； `critic` 则提供快速、犀利的反馈。在发布前或重大合并前使用。

2.2.2 常见工作流中的代理链

功能开发链 ： architect (设计) → plan-reviewer (评审计划) → kraken (TDD实现) → review-agent (代码审查) → arbiter (测试验证)。
重构链 ： phoenix (影响分析) → plan-reviewer → kraken → judge (严格审查) → arbiter 。
Bug 修复链 ： sleuth (诊断) → kraken / spark (修复) → arbiter (验证) → scribe (记录)。

注意事项 ：新手最容易犯的错误是“代理滥用”——为一个简单任务启动复杂的代理链。我的经验法则是：对于 5 分钟能搞定的小修改 ，直接用 spark 代理或甚至不用代理，手动操作。对于 需要设计、涉及多文件、有测试需求的 任务，再启动相应的工作流。过度设计会浪费时间和令牌。

2.3 钩子系统：无侵入式的行为注入

钩子是 Continuous Claude 的“神经系统”，它们在 Claude Code 的生命周期关键点注入逻辑，从而改变其行为，而无需修改 Claude 本身。 30 个钩子 覆盖了从会话开始到结束的全过程。

2.3.1 核心钩子工作流程

钩子事件	关键钩子	核心作用与原理
SessionStart	`session-start-continuity`	加载连续性账本和上一次的交接文件，恢复会话状态。这是实现“跨会话记忆”的第一步。
PreToolUse	`tldr-read-enforcer`	节省令牌的关键。当 Claude 尝试读取文件时，此钩子会拦截请求，并返回经过 `tldr-code` 分析后的精简摘要（L1-L3层），而非整个文件内容。
UserPromptSubmit	`skill-activation-prompt`	自然语言交互的核心。分析用户输入的意图，在 Claude 回复前，向其提示符中注入最相关的技能建议。你看到的“🎯 SKILL ACTIVATION CHECK”就来源于此。
PostToolUse	`post-edit-diagnostics`	“左移”质量保障。在每次代码编辑工具使用后，自动运行 `qlty-check` （即 Ruff/Pyright），立即发现语法和类型错误，避免错误累积。
PreCompact	`pre-compact-continuity`	防丢数据的保险丝。在 Claude 的上下文窗口即将满并触发压缩前，此钩子会自动执行 `create_handoff` ，将当前状态保存到 YAML 文件，确保工作不丢失。
SessionEnd	`session-end-cleanup`	会话结束时，清理临时文件，并触发守护进程（如果启用）来提取本次会话的“学习成果”存入长期记忆。

2.3.2 钩子配置与调试

钩子配置文件位于 ~/.claude/hooks/ 目录下。每个钩子都是一个独立的 Python 脚本。如果你需要自定义行为，可以在这里修改。例如，你可以调整 tldr-read-enforcer 的触发条件，或者为 post-edit-diagnostics 添加自定义的检查工具。

调试钩子相对麻烦，因为它们在 Claude 的进程内运行。一个实用的方法是使用 braintrust-analyze 技能，它可以回放和分析失败的会话，帮助你定位是哪个钩子或技能出了问题。

2.4 TLDR 代码分析：95% 令牌节省的奥秘

这是 Continuous Claude 中技术含量最高、效果也最显著的子系统之一。它的目标很简单：让 Claude 在需要理解代码时，消耗的令牌减少一个数量级。

2.4.1 五层分析栈详解

TLDR 不是简单的代码摘要，而是结构化的深度分析：

L1: AST（抽象语法树）层 (~500 tokens)：提取所有函数、类、方法签名（名称、参数、返回类型）。这是代码的“骨架”。
L2: 调用图层 (+440 tokens)：分析函数/方法之间的调用关系，并 跨文件追踪 。这回答了“谁调用了谁”的问题。
L3: CFG（控制流图）层 (+110 tokens)：分析每个函数内部的执行路径（if/else, loops）。这揭示了代码的复杂度和逻辑分支。
L4: DFG（数据流图）层 (+130 tokens)：追踪变量在函数内的定义、使用和传播路径。这对于理解数据如何被转换至关重要。
L5: PDG（程序依赖图）层 (+150 tokens)：结合控制流和数据流，进行“程序切片”。例如，可以精确分析“影响第 42 行输出的所有代码”。

这五层分析总共约 1200 个令牌 。对比一下：一个中等规模（500行）的 Python 文件，原始内容可能超过 23,000 个令牌。 95% 的节省 就是这样来的。更重要的是，这些结构化信息比原始文本更利于 Claude 进行推理。

2.4.2 语义索引：超越文本的代码搜索

除了结构分析，TLDR 还构建了一个 语义索引 。它使用 BGE-large-en-v1.5 模型为代码片段（结合5层分析和周围10行上下文）生成嵌入向量，并存储在 FAISS 索引中。

这意味着你可以进行 自然语言搜索 。你不再需要 grep 精确的函数名，而是可以问：“ 查找所有处理用户身份验证的逻辑 ” 或者 “ 找到错误处理不够健壮的地方 ”。系统会返回语义上最相关的代码片段。

索引的维护是自动的。 post-tool-use-tracker 钩子会跟踪文件的修改，当一个文件被编辑超过一定次数（默认20次）后，会触发索引的重建。你也可以通过 .tldrignore 文件来排除不需要索引的目录（如 __pycache__/ , node_modules/ ）。

2.5 记忆与连续性系统：让 Claude 真正“记住”

这是项目的灵魂所在。“连续性”不仅仅是不丢上下文，而是让知识和经验在会话间流动。

2.5.1 连续性循环

会话开始 ：加载“连续性账本”（一个 Markdown 文件，记录本次会话的目标、进展）和上一次的“交接文件”（YAML 格式，包含详细状态）。同时，从长期记忆中召回与当前任务相关的“学习成果”。
会话进行中 ：钩子持续跟踪文件修改、记录决策到账本、更新交接文件。 pre-compact-continuity 钩子确保在上下文满之前自动保存状态。
会话结束 ：会话心跳停止超过5分钟后，一个 守护进程 被唤醒。它启动一个无头（headless）的 Claude 实例（使用 Sonnet 模型），分析刚刚结束的会话中的所有“思考块”。
学习提取 ：守护进程的 Claude 从“思考块”中提取出普适性的经验、教训、决策原因（而不仅仅是操作记录），将其向量化后存入 archival_memory 数据库表。
下一次会话 ：当新会话开始时， memory-awareness 钩子会根据当前对话内容，从数据库中召回相关的记忆，并注入到上下文中。

2.5.2 数据库架构

记忆系统基于 PostgreSQL 和 pgvector 扩展，包含四张核心表：

表名	用途
`sessions`	记录所有会话的元数据（如开始时间、最后心跳），实现“跨终端感知”。即使你在不同机器上工作，系统也知道哪些会话是活跃的。
`file_claims`	文件锁。防止多个会话或代理同时修改同一个文件，造成冲突。
`archival_memory`	长期记忆库。存储提取的学习成果，附带 BGE 模型生成的向量，用于语义搜索召回。
`handoffs`	存储交接文件的元数据和向量，便于快速查找和恢复历史会话。

2.5.3 如何使用记忆

显式记忆 ：你可以直接说“ 记住这一点：在这个项目中，我们使用 SQLAlchemy 的异步会话，并且每个请求必须显式关闭。 ” 系统会将其存储为高置信度的学习成果。
隐式召回 ：大多数时候你不需要主动查询。当你在讨论“数据库连接”时， memory-awareness 钩子会自动在后台搜索相关记忆，并在 Claude 的回复中暗示或直接引用之前总结的经验（你会看到 MEMORY MATCH 的标记）。
主动查询 ：你也可以通过命令行工具主动搜索记忆： uv run python scripts/core/recall_learnings.py --query "数据库连接最佳实践" 。

3. 完整实操指南：从安装到日常使用

3.1 环境准备与安装

3.1.1 前置条件检查

在开始之前，请确保你的系统满足以下要求：

Python 3.11+ ：这是许多依赖项（如 Pydantic V2）的硬性要求。
uv ：这是一个用 Rust 编写的极速 Python 包管理器和安装器，比 pip 快一个数量级。通过 curl -LsSf https://astral.sh/uv/install.sh | sh 安装。
Docker & Docker Compose ：用于运行本地的 PostgreSQL 数据库（包含 pgvector 扩展）。这是记忆系统的后端。
Claude Code CLI ：确保你已安装并可以正常使用 claude 命令。

3.1.2 安装步骤详解

克隆仓库 ：

git clone https://github.com/parcadei/Continuous-Claude-v3.git
cd Continuous-Claude-v3/opc  # 注意：关键文件在 opc/ 子目录下

运行安装向导 ：
```
uv run python -m scripts.setup.wizard
```
这个向导会引导你完成12个步骤。我强烈建议你 不要跳过 ，尤其是前几步的备份检查。

向导步骤解析 ：

步骤	关键操作与注意事项
1-2	备份现有配置。向导会将你现有的 `~/.claude` 目录重命名备份。这是安全网，如果新系统不适应，可以完整回滚。
3-5	配置数据库和 API 密钥。它会帮你启动 Docker 容器中的 PostgreSQL，并询问你的 Claude API 密钥。密钥会安全地存储在 `~/.claude/.env` 文件中。
6-8	核心系统安装。安装所有钩子（30个）、技能（109个）、代理（32个）到你的 Claude Code 配置中。
9	数学功能安装（可选）。安装 SymPy（符号计算）、Z3（定理证明）、Pint（单位处理）的支持。如果你做科学计算或形式验证，建议安装。
10-12	诊断工具安装。包括 TLDR 代码分析工具和 Loogle（可选，用于搜索日志）。

重要提示 ：安装后，所有 uv 命令都必须在 Continuous-Claude-v3/opc/ 目录下运行，因为 pyproject.toml 文件在这里。这是一个常见的踩坑点。

3.1.3 远程数据库配置（可选）

默认使用本地 Docker 数据库很方便，但对于团队协作或多设备同步，你可能需要远程数据库（如 AWS RDS、Supabase）。

准备远程数据库 ：确保 PostgreSQL 实例已启用 pgvector 扩展。对于云服务：
- AWS RDS ：在数据库参数组中，将 vector 添加到 shared_preload_libraries 列表。
- Supabase ：在控制台的 Database → Extensions 页面启用 pgvector 。
- 然后，运行项目中的 docker/init-schema.sql 来创建表结构。
配置连接 ：在 ~/.claude/settings.json 中设置环境变量：
```
{
  "env": {
    "CONTINUOUS_CLAUDE_DB_URL": "postgresql://<用户名>:<密码>@<主机>:5432/<数据库名>"
  }
}
```
或者，在启动 Claude 前设置环境变量： export CONTINUOUS_CLAUDE_DB_URL=... 。

3.2 首次会话与核心工作流

安装完成后，启动 Claude Code： claude 。你会注意到界面没有明显变化，但系统已经在后台运行了。

3.2.1 从自然语言开始

尝试不要使用任何斜杠命令，直接输入：

“我想修复用户登录页面那个偶尔出现的‘无效令牌’错误。”

观察 Claude 的回复。在它开始思考前，你应该会看到类似下面的提示框：

🎯 SKILL ACTIVATION CHECK
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
⚠️ CRITICAL SKILLS (REQUIRED):
  → create_handoff (在会话结束时使用)

📚 RECOMMENDED SKILLS:
  → fix
  → debug

🤖 RECOMMENDED AGENTS (token-efficient):
  → debug-agent
  → scout
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
ACTION: Use Skill tool BEFORE responding

这表明 skill-activation-prompt 钩子已经识别出你的“修复 bug”意图，并给出了建议。Claude 接下来很可能会建议你使用 /fix bug 工作流。

3.2.2 体验核心工作流

探索代码库 ( /explore ) ：如果你接手一个新项目，这是第一步。运行 /explore deep --focus "auth" ，让 scout 代理为你深入分析所有与认证相关的代码，并生成一份总结文档。
构建新功能 ( /build ) ：假设要添加一个“忘记密码”功能。运行 /build greenfield "implement password reset flow" 。系统会启动 discovery-interview 技能，问你一系列问题来澄清需求（邮件模板、令牌有效期、UI 流程等），然后生成计划，并由 kraken 代理以 TDD 方式实现。
修复复杂 Bug ( /fix ) ：对于那个“无效令牌”错误，运行 /fix bug --dry-run 先进行诊断。 sleuth 代理会检查日志、分析代码，提出假设。确认根因后，去掉 --dry-run 标志，让它执行完整的修复流程。
进行风险预演 ( premortem ) ：在实施任何重大变更（如库升级、架构重构）前，单独运行 premortem 技能。它会系统性地引导你思考技术、集成、安全等各方面的风险，并生成缓解计划。

3.2.3 会话的结束与恢复

这是体现“连续性”的关键。

自然结束 ：当你准备离开时，可以说“今天就到这里”或“先这样”。 pre-compact-continuity 钩子会检测到上下文将满或会话闲置，自动触发 create_handoff ，将状态保存到 ~/.claude/thoughts/shared/handoffs/ 目录下的一个 YAML 文件中。
显式保存 ：你也可以直接运行 create_handoff 技能，它会让你为这次交接命名（例如 fix-auth-token-bug-20240527 ）。
恢复会话 ：明天打开 Claude，运行 resume_handoff 技能，选择之前的交接文件。Claude 会加载所有上下文——包括未完成的代码变更、讨论的决策、待办事项列表——让你立刻回到离开时的状态。

3.3 高级配置与调优

3.3.1 技能与代理的个性化

配置文件位于 ~/.claude/ 下。你可以通过编辑 JSON 文件来调整技能和代理的行为。

禁用不常用的技能/代理 ：在 skills.json 或 agents.json 中，将对应条目的 "enabled" 设为 false 。这可以加快技能激活检查的速度。
调整钩子触发阈值 ：例如，在 hooks/pre-compact-continuity.py 中，你可以修改 DIRTY_FILE_THRESHOLD （默认20），来控制文件修改多少次后才触发 TLDR 重新索引。
自定义 TLDR 忽略规则 ：在项目根目录创建 .tldrignore 文件，模式类似 .gitignore ，可以排除对测试文件、构建产物等目录的索引，提升效率。

3.3.2 性能优化

TLDR 守护进程 ：对于大型代码库，首次构建语义索引可能较慢。可以考虑在后台运行 TLDR 守护进程： tldr daemon start 。它会监听文件变化并增量更新索引。
记忆召回调优 ：如果发现召回的记忆不相关，可以调整 scripts/core/recall_learnings.py 中的向量搜索相似度阈值（ SIMILARITY_THRESHOLD ）或混合搜索中文本与向量的权重。
会话心跳间隔 ：在 hooks/session-register.py 中，可以调整心跳频率，以平衡“跨终端感知”的实时性和系统开销。

3.3.3 与现有工作流集成

Continuous Claude 并非要取代你的所有工具，而是增强它们。

版本控制 ： commit 技能可以生成符合规范的提交信息。你可以将其与你的 Git 钩子结合。
CI/CD ： /release 工作流生成的变更日志和发布清单，可以集成到你的 CI 流水线中。
文档： scribe 和 chronicler 代理可以自动生成或更新项目文档、API 文档。将它们的输出目录指向你的 docs/ 文件夹。

4. 避坑指南与常见问题排查

即使设计再精良的系统，在实际使用中也会遇到问题。以下是我在深度使用 Continuous Claude 过程中积累的常见问题与解决方案。

4.1 安装与初始化问题

问题1：安装向导中途失败，尤其是数据库步骤。

排查：首先检查 Docker 服务是否正在运行 ( docker ps )。然后查看向导失败时输出的具体错误信息。最常见的是端口冲突（PostgreSQL 默认用 5432）或权限问题（Docker 需要 sudo 或用户组权限）。
解决：
1. 尝试手动启动数据库： cd Continuous-Claude-v3/opc && docker-compose up -d db 。
2. 如果端口冲突，修改 docker-compose.yml 中的端口映射，并同步更新 .env.example 和后续配置。
3. 运行 uv run python -m scripts.setup.diagnose 使用内置诊断工具。

问题2：安装后，Claude Code 启动变慢，或者技能/钩子不生效。

排查：检查 ~/.claude/config.json ，确保 skills_dir , hooks_dir , agents_dir 正确指向了 Continuous Claude 安装的目录（通常是 ~/.claude/skills 等）。同时检查文件权限。
解决：
1. 运行 claude --debug 查看启动日志，寻找加载错误。
2. 验证钩子是否被加载：在 Claude 会话中，尝试输入一些内容，看是否有技能激活提示。如果没有，可能是钩子加载失败。
3. 回退到备份：如果你有备份，可以使用卸载向导 uv run python -m scripts.setup.wizard --uninstall ，它会恢复你的原始配置。

4.2 运行时问题

问题3：使用 /fix 或 /build 时，代理链卡住或进入循环。

原因：这通常发生在任务定义模糊或代码库状态异常（如存在无法通过的测试）时。某个代理（如 sleuth ）可能无法得出明确结论，导致工作流停滞。
解决：
1. 中断并手动接管 ：使用 Ctrl+C 中断当前操作。然后，直接与负责当前步骤的代理对话。例如，如果卡在 sleuth ，直接告诉它：“根据你目前的发现，你认为最可能的根因是什么？我们先假设是 X，然后设计一个验证实验。”
2. 简化任务 ：将大任务拆解。不要用“重构整个认证系统”，而是用“将 login 函数中的 JWT 验证逻辑提取到一个新函数”。
3. 检查代理日志 ：每个代理的运行记录会在 ~/.claude/thoughts/agents/ 下。查看对应代理的日志文件，了解它卡在哪里。

问题4：TLDR 代码分析返回“文件未找到”或分析结果空洞。

排查：首先确认你所在的目录在 TLDR 的索引范围内。运行 tldr tree . 看是否能列出文件。
解决：
1. 重建索引 ：删除 .tldr/ 缓存目录（在项目根目录或用户主目录下），然后重新运行 Claude。 tldr-read-enforcer 钩子会在需要时触发重建。
2. 检查忽略规则 ：确认你的目标文件没有被 .tldrignore 规则排除。
3. 手动运行分析 ：在终端执行 tldr structure path/to/your/file.py ，查看原始输出是否正常。这能区分是 TLDR 工具问题还是钩子集成问题。

问题5：记忆系统没有召回任何相关内容，或者召回的内容不准确。

原因：记忆的提取和召回依赖于嵌入模型（BGE）和搜索策略。如果学习成果的描述太模糊，或者查询与记忆的语义距离较远，就可能失败。
解决：
1. 优化记忆存储 ：当显式要求系统“记住”时，提供具体、清晰的描述。例如，“记住：在 utils/validation.py 中， validate_email 函数对国际化域名（IDN）的支持不完善，我们决定使用 email-validator 库替代。”
2. 调整召回查询 ：尝试用更接近你当初存储记忆时使用的语言进行查询。或者，直接使用命令行工具进行多轮测试： uv run python scripts/core/recall_learnings.py --query "你的查询词" 。
3. 检查数据库 ：确认 archival_memory 表中有数据。连接数据库执行 SELECT COUNT(*) FROM archival_memory; 。

问题6： pre-compact-continuity 钩子没有自动创建交接，导致上下文丢失。

排查：Claude 的上下文压缩触发机制有时不规律。该钩子会在检测到“可能即将压缩”时触发，但并非100%可靠。
解决：
1. 养成手动保存习惯 ：在完成一个重要阶段或准备进行可能消耗大量上下文的大操作（如要求分析整个文件）前，主动运行 create_handoff 。
2. 监控上下文使用 ：留意 Claude 回复的令牌使用情况。当上下文使用量超过 80% 时，就应主动保存。
3. 检查钩子日志 ：查看 ~/.claude/logs/ 目录下钩子的运行日志，看是否有错误信息。

4.3 性能与资源问题

问题7：系统运行缓慢，特别是技能激活或代理启动时。

原因：109个技能和32个代理的检查与加载需要时间。此外，TLDR 的语义索引和记忆的向量搜索在首次查询或大型代码库上可能较慢。
解决：
1. 禁用不必要的组件 ：如前所述，在配置文件中禁用你绝对用不到的技能和代理。
2. 使用更快的模型 ：在 ~/.claude/settings.json 中，为不同的代理指定模型。例如，让 scout （探索）使用更快的 haiku 模型，而 kraken （实现）使用能力更强的 sonnet 模型。
3. 优化数据库 ：如果使用本地 PostgreSQL，确保 Docker 容器分配了足够的内存。对于向量搜索，考虑在 archival_memory 表的 embedding 列上建立 IVF 索引（如果 pgvector 版本支持）。

问题8：令牌消耗依然很高。

排查：首先确认 tldr-read-enforcer 钩子是否正常工作。在 Claude 尝试读取文件时，检查其回复是否是以“ TLDR Analysis for [file] ”开头的摘要，而不是完整的文件内容。
解决：
1. 强制使用 TLDR ：在需要分析代码时，主动使用 tldr-code 技能，而不是直接让 Claude “查看这个文件”。
2. 调整分析深度 ： tldr-code 技能可以指定层级。对于初步了解，使用 --layers 1 2 （仅 AST 和调用图）可能就够了。
3. 审查代理输出 ：有些代理（如 oracle 进行网络研究）可能会生成很长的内容。考虑为其设置输出长度限制，或者要求它先提供摘要。

4.4 理念与实践建议

不要追求 100% 的自动化 ：Continuous Claude 是一个强大的辅助系统，而不是全自动编程机器人。它的价值在于处理繁琐的上下文管理、提供深度分析、执行标准化工作流。最终的决策、复杂逻辑的构思、架构的权衡，仍然需要你——开发者——来主导。将 AI 视为一个不知疲倦、知识渊博的初级合作伙伴，你则是负责指导和审核的高级工程师。

从小处着手，逐步信任 ：不要一开始就在核心业务代码上运行复杂的重构工作流。先从一个工具类函数、一个简单的 Bug 修复开始，观察代理是如何工作的，理解它生成的代码和测试。建立信任后，再逐步应用到更复杂的任务中。

持续反馈与调教 ：当代理给出的方案不符合你的偏好时，不要简单地拒绝。告诉它为什么，比如“这个函数的命名不符合我们项目的驼峰风格”，或者“这里异常处理应该更具体”。这些反馈会被记忆系统（如果配置正确）部分吸收，或在当前会话的上下文中影响后续行为。你是在训练你的专属开发伙伴。

保持系统简洁 ：作者也提到代理数量可能过多。遵循“反复杂性”原则。如果你发现某个代理或技能从未使用，就禁用它。系统的威力来自于深度集成和流畅的工作流，而不是功能的简单堆砌。找到最适合你的 3-5 个核心工作流（如 /fix , /build , /explore ），并精通它们，远比浅尝辄止地使用所有功能要有效得多。

亚马逊云科技技术品牌专区

更多推荐