AutoDream 到 24h 不触发Footer 里没有 Dream pillShiftDown 也看不到 DreamTask很多人第一反应是去翻 .consolidate-lock 的 mtime。先别急TaoToken 侧只做两件事给你一把 Key 和一条兼容通道。先去 https://taotoken.net/?utm_sourcetaotoken_aicg_blog_end 创建 Key再把 Claude Code 的 Base URL 填成 https://taotoken.net/api。如果通道本身没走通Extract Memories 和 AutoDream 的 fork agent 都没有稳定的 API 调用可以跑四层门控也就没法验证。TaoToken 不碰你的记忆文件。等 401 和地址多写 /v1 这两个坑排掉再回来看 autoDreamEnabled、24h 时间门控、5 个会话门控、.consolidate-lock 的 PID 与 mtime以及 DreamTask 是否真的注册进了任务面板。1. AutoDream 到 24h 不触发先排除 Claude Code 通道 4011.1 先看报错不要急着删 .consolidate-lock遇到 AutoDream 不触发最常见的处理是删 lock 文件、手动改 mtime、反复重启 Claude Code。这些动作在通道正常时可能让你重新走一次时间门控但在通道没通时它们只会把现场搅乱。先看 Claude Code 启动后发第一条消息时的返回如果出现 401、authentication_error、invalid x-api-key说明请求根本没到记忆子系统。Extract Memories 和 AutoDream 都依赖 forked agent 发起模型调用。主对话可能因为本地缓存或简单回复看不出异常但后台 fork 拿不到模型响应就不会写记忆文件也不会注册 DreamTask。于是你看到的“24h 到了也不触发”实际上是“后台任务根本没跑起来”。这个顺序要先分清。1.2 通道没通时Extract Memories 和 fork agent 都像“没触发”Extract Memories 在 stopHooks 里以 fire-and-forget 方式触发不阻塞主对话。AutoDream 也会在 stopHooks 里被调一次。两者都通过 runForkedAgent 启动子 agent共享父对话的 prompt cache跳过 transcript 写入只拿受限工具权限。通道异常时这些 forked agent 可能没有可见的对话框报错最多在系统消息里少一句“Saved N memories”。如果你只盯着 AutoDream 的 24h 门控就会漏掉更前面的一层模型调用失败。判断方法很直接新开一个 Claude Code 会话发一条普通提问确认能稳定返回再用同一把 Key 在模型对话里发一条测试消息。两边都正常再进入门控排查。通道没稳之前别动 .consolidate-lock。1.3 排障分两段TaoToken 侧通通道原逻辑侧查四层门控TaoToken 侧只负责两件事给你一把 Key给你一个兼容 Base URL。它不读取、不修改你的记忆目录也不碰 .consolidate-lock。所以排障要分两段第一段确认 Claude Code 的 ANTHROPIC_BASE_URL、ANTHROPIC_AUTH_TOKEN、ANTHROPIC_MODEL 是否正确第二段回到 AutoDream 自己的逻辑按功能开关、24h 时间门控、5 个会话门控、分布式锁逐层看。顺序反了会很折腾。通道 401 时你改 lock mtime 改到再准也不会出现 DreamTask通道正常后你只需要看 lock 文件 mtime、session 计数和 PID 存活状态。下面先把第一段收掉。2. 在 ~/.claude/settings.json 里把 Claude Code 指到 TaoToken2.1 创建 YOUR_API_KEY 并确认模型 ID打开 TaoToken注册登录后进控制台创建 API Key。复制出来的 Key 先放在一边后面统一写成 YOUR_API_KEY不要直接写进博客或提交到仓库。模型 ID 不要凭记忆填去模型广场看当前可用的列表以模型广场当时列表为准。不同项目、不同套餐可选的模型可能不同填错模型 ID 会在调用阶段失败。如果你有多个项目共用一把 Key建议在控制台按项目建不同 Key排障时可以快速切换不用把整台机器的环境变量改来改去。Key 创建入口和控制台在同一个站点落地页地址是 https://taotoken.net/?utm_sourcetaotoken_aicg_blog_end 。这一步只拿 Key 和模型 ID不需要动 Claude Code 的记忆文件。2.2 env 三行配置ANTHROPIC_BASE_URL 不能带 /v1Claude Code 读取 ~/.claude/settings.json 里的 env。把下面三行写进去Base URL 用 https://taotoken.net/api末尾不要加 /v1也不要加任何 UTM 参数。ANTHROPIC_AUTH_TOKEN 填 YOUR_API_KEYANTHROPIC_MODEL 填你在模型广场选中的模型 ID。{ env: { ANTHROPIC_BASE_URL: https://taotoken.net/api, ANTHROPIC_AUTH_TOKEN: YOUR_API_KEY, ANTHROPIC_MODEL: YOUR_MODEL_ID } }注意两个容易写错的地方。第一ANTHROPIC_BASE_URL 是工具填的接口地址不是给人点的官网落地页所以不要带 ?utm_source 或 utm_content。第二末尾不要写 /v1Claude Code 会自己拼接后续路径。模型 ID 用 YOUR_MODEL_ID 占位实际值以 https://taotoken.net/?utm_sourcetaotoken_aicg_blog_end 模型广场当时列表为准。2.3 环境变量写法和重启验证不想改 settings.json也可以在 shell 里临时 export适合排查“文件配置到底有没有生效”export ANTHROPIC_BASE_URLhttps://taotoken.net/api export ANTHROPIC_AUTH_TOKENYOUR_API_KEY export ANTHROPIC_MODELYOUR_MODEL_ID写完后完全退出 Claude Code再重新打开一个新会话。发一条普通消息比如让它解释一个函数。如果对话正常返回说明通道基本通了。此时再去模型对话里用同一把 Key 发一条测试消息确认模型 ID 和 Key 没填错。验证通过后再回到 AutoDream 的门控排查。2.4 401 与地址多写 /v1 的对照如果 Claude Code 返回 401先检查 ANTHROPIC_AUTH_TOKEN 是不是复制时多了空格或换行再确认 Key 没有在控制台被禁用。如果请求一直拼到错误路径检查 ANTHROPIC_BASE_URL 是不是多写了 /v1。正确写法只有 https://taotoken.net/api。这两个错误都会让 forked agent 静默失败所以排障时优先排除。现象优先检查正确写法401 / authentication_errorKey 是否完整、是否被禁用ANTHROPIC_AUTH_TOKENYOUR_API_KEY请求路径异常Base URL 是否多写 /v1https://taotoken.net/api3. 功能开关与模式门控autoDreamEnabled 被什么覆盖了3.1 settings.json 优先级高于 GrowthBook flag通道通了以后AutoDream 的第一层是功能开关。源码里的 isGateOpen 会先看 KAIROS 模式、Remote 模式、AutoMemory 是否启用最后才看 AutoDream 开关。开关来源有两个settings.json 里的 autoDreamEnabled 优先级更高其次是 GrowthBook feature flag tengu_onyx_plover。如果你在 settings.json 里显式写了 false远程 flag 打开也没用。检查时不要只搜一个文件。Claude Code 可能读取项目级和用户级 settings合并顺序会影响最终值。最稳的做法是先把项目级、用户级里的 autoDreamEnabled 都列出来确认没有互相覆盖。这个阶段不需要改 lock 文件先确定开关真的打开了。3.2 KAIROS、Remote、AutoMemory 的前置条件isGateOpen 的逻辑里KAIROS 模式直接 return false远程模式也 return falseAutoMemory 未启用同样 return false。也就是说你可能把 autoDreamEnabled 打开了但当前运行模式根本不走 AutoDream。排查时把这三个前置条件记下来按顺序确认当前是不是 KAIROS 模式是不是 Remote 模式AutoMemory 有没有启用。这一步很容易被忽略因为界面上不一定有醒目提示。最直接的方法是对照你启动 Claude Code 的参数和 settings.json看看有没有打开这些模式。如果确实在 KAIROS 或 Remote 下AutoDream 不会触发是预期行为不是 bug。切回普通模式再测才有意义。3.3 一个最小检查脚本只读可以用只读命令先看配置里有没有相关键命令由你在本地终端执行不要把记忆目录内容贴给远程模型grep -n autoDreamEnabled\\|autoMemoryEnabled ~/.claude/settings.json 2/dev/null grep -rn autoDreamEnabled .claude 2/dev/null | head -20这条只做本地检查不修改任何文件。如果输出为空说明你可能没显式配置得看 GrowthBook flag 或默认值。如果输出里有 false先改成 true 并重启 Claude Code。功能开关确认打开后再进入下一层时间门控。4. 24h 时间门控、5 个会话门控和 .consolidate-lock 的 mtime4.1 lock 文件的 mtime 才是 24h 的起算点AutoDream 的第二层是时间门控。它不会读你的日记也不看你什么时候关机而是读 /.consolidate-lock 的 mtime。计算方式很轻当前时间减去 lock 文件最后修改时间得到小时数如果小于 minHours默认 24就直接退出。因此你说“已经过了 24 小时”和程序说的“已经过了 24 小时”可能不是同一个起点。如果 lock 文件被删过、被编辑器改过、被备份工具同步过mtime 就会变。可以用 stat 看stat -c %y %n memory-dir/.consolidate-lockmemory-dir换成你的记忆目录。看输出的修改时间再和当前时间对比。如果不到 24 小时AutoDream 不触发是时间门控在起作用。注意不要把 lock 文件当缓存随便删删掉等于把上次整合时间清零反而会让下一次判断更混乱。4.2 会话门控为什么要排除当前会话时间门控过了还有会话门控。AutoDream 会列出上次整合之后被修改过的 session过滤掉 currentSession再判断数量是否达到 minSessions默认 5 个。也就是说你在同一个会话里反复聊天聊天次数再多也只算一个会话。要触发巩固需要至少有 5 个不同的会话在时间窗内被改过。这解释了另一种现象时间明明过了 24 小时AutoDream 还是不跑因为最近只有两三个会话。你可以本地数一下 transcript 目录里最近修改的会话文件但不要穷举读取内容。看数量和修改时间就够。如果数量不够就正常用 Claude Code 多开几个会话等门控满足。4.3 10 分钟扫描节流与 60 分钟锁过期会话门控通过后AutoDream 还要拿分布式锁。为了避免时间门控通过但会话不够时每轮都扫文件系统代码里有一个 10 分钟扫描节流距离上次扫描不到 10 分钟就直接返回。这个节流是 backoff不是故障。如果你刚重启就看到“没反应”可以等一个扫描周期再观察。锁文件路径是 /.consolidate-lock内容是持有者 PIDmtime 是获取锁的时间过期时间默认 60 分钟。这个 60 分钟不是 AutoDream 的触发间隔而是防止 PID 复用导致死锁。多开终端窗口时只有一个进程能写入锁并开始巩固其他进程要等锁过期或 PID 消失。4.4 rollbackConsolidationLock 什么时候回滚如果 fork 失败或者你从后台任务面板杀掉了 DreamTask代码会走 rollbackConsolidationLock把 lock 文件的 mtime 恢复到获取之前的值让下一次时间门控仍然能通过。如果之前没有 lock 文件回滚逻辑会删掉它恢复到无文件状态。这个设计是为了避免一次失败把 24 小时计时重置。进程崩溃是另一种情况lock 文件还在PID 变成死进程。下一个进程读到 PID发现它不存活就可以尝试获取锁。60 分钟过期是兜底防止极端情况下锁一直不释放。排障时如果你手动改了 lock 的 mtime回滚逻辑和过期逻辑都会变得不可预测所以先看再动。5. DreamTask、Extract Memories 与 MEMORY.md确认 fork agent 真的动了5.1 stopHooks 触发不等于执行成功stopHooks.ts 里的调用是 fire-and-forget主对话不等待后台任务完成。所以“我发了消息”不等于“Extract Memories 执行成功”更不等于“AutoDream 开始巩固”。Extract Memories 还有互斥和节流如果主 agent 当前轮已经写了记忆文件forked agent 会跳过它受 GrowthBook flag tengu_bramble_lintel 控制可能不是每轮都触发还有最大 5 回合的硬上限防止陷入验证循环。判断 Extract Memories 有没有工作可以看主对话里有没有出现 “Saved N memories” 这样的系统消息以及记忆目录里有没有新增或更新的文件。不要只看对话正常返回。通道稳定后这些信号才有参考价值。如果一直没有先回到第 2 章检查 Key 和 Base URL。5.2 DreamTask 的三个 UI 信号AutoDream 真正跑起来时会通过 DreamTask 注册到任务系统。UI 上通常有三个可见信号底部 Footer pill 显示正在运行的 Dream 任务ShiftDown 打开详情面板看进度第一次 Edit/Write 调用出现时phase 从 starting 翻转为 updating。完成后如果修改了文件主对话里会内联显示 “Improved N memories”。如果你在 Footer 看不到 pill在 ShiftDown 里也找不到 DreamTask那说明任务没有注册成功不是“跑了但没写文件”。此时回到门控排查功能开关、24h 时间门控、5 个会话门控、分布式锁。只有这四层都过了DreamTask 才有机会出现。5.3 记忆类型、沙箱和读取侧验证记忆类型分四种user、feedback、project、reference。它们覆盖的是无法从代码直接推导的信息比如用户角色、工作偏好、项目上下文和外部系统指针。AutoDream 的子 agent 跑在受限沙箱里Read、Grep、Glob 完全允许Bash 只允许只读命令Edit/Write 仅限记忆目录内MCP 和 Agent 等工具会被拒绝。这个沙箱保证了巩固过程不会改你的业务代码。读取侧也要注意MEMORY.md 是索引不是内容堆超过 200 行会被截断。写入时强调“写入要克制读取要验证”。如果某条记忆提到一个文件路径或函数名未来会话在推荐前应该先检查它是否还存在。这个思路同样适用于你排查 AutoDream先验证通道再验证门控不要凭感觉删文件。6. 排完这次 AutoDream再去控制台对一下调用6.1 完整检查清单把上面的排查压成一份顺序清单按这个顺序走不要跳步Claude Code 能否正常对话Key 是否正确Base URL 是否为 https://taotoken.net/api。模型 ID 是否来自模型广场当前列表以 https://taotoken.net/?utm_sourcetaotoken_aicg_blog_end 为准。autoDreamEnabled 是否显式打开KAIROS、Remote、AutoMemory 是否拦住。.consolidate-lock 的 mtime 是否已满 24 小时。上次整合后是否有至少 5 个不同会话被修改。lock 里的 PID 是否存活是否在 60 分钟过期窗口内。Footer pill、ShiftDown、phase 翻转和 “Improved N memories” 是否出现。这份清单里前两步属于 TaoToken 侧只涉及 Key 和 Base URL后面五步属于 AutoDream 自己的门控和任务系统。通道没通时后面五步的结果都不可信。6.2 下一步 deep link配置保存后先在 TaoToken 模型对话 里用同一把 Key 发一条测试消息确认模型 ID 和 Base URL 没填错。如果你准备长期用 Claude Code 写代码可以打开 Coding Plan 看套餐是否够用Key 在 控制台 API Keys 创建。Claude Code 环境变量对照见 接入文档。AutoDream 不动的时候先让通道能稳定回话再去数那 5 个会话和 lock 的 mtime顺序反了只会白折腾。 
长河君 · 2026/9/17 14:24:47 · 阅读 1.2k AutoDream 到 24h 不触发？TaoToken 侧这样配 Claude Code 通道
AutoDream 到 24h 不触发Footer 里没有 Dream pillShiftDown 也看不到 DreamTask很多人第一反应是去翻 .consolidate-lock 的 mtime。先别急TaoToken 侧只做两件事给你一把 Key 和一条兼容通道。先去 https://taotoken.net/?utm_sourcetaotoken_aicg_blog_end 创建 Key再把 Claude Code 的 Base URL 填成 https://taotoken.net/api。如果通道本身没走通Extract Memories 和 AutoDream 的 fork agent 都没有稳定的 API 调用可以跑四层门控也就没法验证。TaoToken 不碰你的记忆文件。等 401 和地址多写 /v1 这两个坑排掉再回来看 autoDreamEnabled、24h 时间门控、5 个会话门控、.consolidate-lock 的 PID 与 mtime以及 DreamTask 是否真的注册进了任务面板。1. AutoDream 到 24h 不触发先排除 Claude Code 通道 4011.1 先看报错不要急着删 .consolidate-lock遇到 AutoDream 不触发最常见的处理是删 lock 文件、手动改 mtime、反复重启 Claude Code。这些动作在通道正常时可能让你重新走一次时间门控但在通道没通时它们只会把现场搅乱。先看 Claude Code 启动后发第一条消息时的返回如果出现 401、authentication_error、invalid x-api-key说明请求根本没到记忆子系统。Extract Memories 和 AutoDream 都依赖 forked agent 发起模型调用。主对话可能因为本地缓存或简单回复看不出异常但后台 fork 拿不到模型响应就不会写记忆文件也不会注册 DreamTask。于是你看到的“24h 到了也不触发”实际上是“后台任务根本没跑起来”。这个顺序要先分清。1.2 通道没通时Extract Memories 和 fork agent 都像“没触发”Extract Memories 在 stopHooks 里以 fire-and-forget 方式触发不阻塞主对话。AutoDream 也会在 stopHooks 里被调一次。两者都通过 runForkedAgent 启动子 agent共享父对话的 prompt cache跳过 transcript 写入只拿受限工具权限。通道异常时这些 forked agent 可能没有可见的对话框报错最多在系统消息里少一句“Saved N memories”。如果你只盯着 AutoDream 的 24h 门控就会漏掉更前面的一层模型调用失败。判断方法很直接新开一个 Claude Code 会话发一条普通提问确认能稳定返回再用同一把 Key 在模型对话里发一条测试消息。两边都正常再进入门控排查。通道没稳之前别动 .consolidate-lock。1.3 排障分两段TaoToken 侧通通道原逻辑侧查四层门控TaoToken 侧只负责两件事给你一把 Key给你一个兼容 Base URL。它不读取、不修改你的记忆目录也不碰 .consolidate-lock。所以排障要分两段第一段确认 Claude Code 的 ANTHROPIC_BASE_URL、ANTHROPIC_AUTH_TOKEN、ANTHROPIC_MODEL 是否正确第二段回到 AutoDream 自己的逻辑按功能开关、24h 时间门控、5 个会话门控、分布式锁逐层看。顺序反了会很折腾。通道 401 时你改 lock mtime 改到再准也不会出现 DreamTask通道正常后你只需要看 lock 文件 mtime、session 计数和 PID 存活状态。下面先把第一段收掉。2. 在 ~/.claude/settings.json 里把 Claude Code 指到 TaoToken2.1 创建 YOUR_API_KEY 并确认模型 ID打开 TaoToken注册登录后进控制台创建 API Key。复制出来的 Key 先放在一边后面统一写成 YOUR_API_KEY不要直接写进博客或提交到仓库。模型 ID 不要凭记忆填去模型广场看当前可用的列表以模型广场当时列表为准。不同项目、不同套餐可选的模型可能不同填错模型 ID 会在调用阶段失败。如果你有多个项目共用一把 Key建议在控制台按项目建不同 Key排障时可以快速切换不用把整台机器的环境变量改来改去。Key 创建入口和控制台在同一个站点落地页地址是 https://taotoken.net/?utm_sourcetaotoken_aicg_blog_end 。这一步只拿 Key 和模型 ID不需要动 Claude Code 的记忆文件。2.2 env 三行配置ANTHROPIC_BASE_URL 不能带 /v1Claude Code 读取 ~/.claude/settings.json 里的 env。把下面三行写进去Base URL 用 https://taotoken.net/api末尾不要加 /v1也不要加任何 UTM 参数。ANTHROPIC_AUTH_TOKEN 填 YOUR_API_KEYANTHROPIC_MODEL 填你在模型广场选中的模型 ID。{ env: { ANTHROPIC_BASE_URL: https://taotoken.net/api, ANTHROPIC_AUTH_TOKEN: YOUR_API_KEY, ANTHROPIC_MODEL: YOUR_MODEL_ID } }注意两个容易写错的地方。第一ANTHROPIC_BASE_URL 是工具填的接口地址不是给人点的官网落地页所以不要带 ?utm_source 或 utm_content。第二末尾不要写 /v1Claude Code 会自己拼接后续路径。模型 ID 用 YOUR_MODEL_ID 占位实际值以 https://taotoken.net/?utm_sourcetaotoken_aicg_blog_end 模型广场当时列表为准。2.3 环境变量写法和重启验证不想改 settings.json也可以在 shell 里临时 export适合排查“文件配置到底有没有生效”export ANTHROPIC_BASE_URLhttps://taotoken.net/api export ANTHROPIC_AUTH_TOKENYOUR_API_KEY export ANTHROPIC_MODELYOUR_MODEL_ID写完后完全退出 Claude Code再重新打开一个新会话。发一条普通消息比如让它解释一个函数。如果对话正常返回说明通道基本通了。此时再去模型对话里用同一把 Key 发一条测试消息确认模型 ID 和 Key 没填错。验证通过后再回到 AutoDream 的门控排查。2.4 401 与地址多写 /v1 的对照如果 Claude Code 返回 401先检查 ANTHROPIC_AUTH_TOKEN 是不是复制时多了空格或换行再确认 Key 没有在控制台被禁用。如果请求一直拼到错误路径检查 ANTHROPIC_BASE_URL 是不是多写了 /v1。正确写法只有 https://taotoken.net/api。这两个错误都会让 forked agent 静默失败所以排障时优先排除。现象优先检查正确写法401 / authentication_errorKey 是否完整、是否被禁用ANTHROPIC_AUTH_TOKENYOUR_API_KEY请求路径异常Base URL 是否多写 /v1https://taotoken.net/api3. 功能开关与模式门控autoDreamEnabled 被什么覆盖了3.1 settings.json 优先级高于 GrowthBook flag通道通了以后AutoDream 的第一层是功能开关。源码里的 isGateOpen 会先看 KAIROS 模式、Remote 模式、AutoMemory 是否启用最后才看 AutoDream 开关。开关来源有两个settings.json 里的 autoDreamEnabled 优先级更高其次是 GrowthBook feature flag tengu_onyx_plover。如果你在 settings.json 里显式写了 false远程 flag 打开也没用。检查时不要只搜一个文件。Claude Code 可能读取项目级和用户级 settings合并顺序会影响最终值。最稳的做法是先把项目级、用户级里的 autoDreamEnabled 都列出来确认没有互相覆盖。这个阶段不需要改 lock 文件先确定开关真的打开了。3.2 KAIROS、Remote、AutoMemory 的前置条件isGateOpen 的逻辑里KAIROS 模式直接 return false远程模式也 return falseAutoMemory 未启用同样 return false。也就是说你可能把 autoDreamEnabled 打开了但当前运行模式根本不走 AutoDream。排查时把这三个前置条件记下来按顺序确认当前是不是 KAIROS 模式是不是 Remote 模式AutoMemory 有没有启用。这一步很容易被忽略因为界面上不一定有醒目提示。最直接的方法是对照你启动 Claude Code 的参数和 settings.json看看有没有打开这些模式。如果确实在 KAIROS 或 Remote 下AutoDream 不会触发是预期行为不是 bug。切回普通模式再测才有意义。3.3 一个最小检查脚本只读可以用只读命令先看配置里有没有相关键命令由你在本地终端执行不要把记忆目录内容贴给远程模型grep -n autoDreamEnabled\\|autoMemoryEnabled ~/.claude/settings.json 2/dev/null grep -rn autoDreamEnabled .claude 2/dev/null | head -20这条只做本地检查不修改任何文件。如果输出为空说明你可能没显式配置得看 GrowthBook flag 或默认值。如果输出里有 false先改成 true 并重启 Claude Code。功能开关确认打开后再进入下一层时间门控。4. 24h 时间门控、5 个会话门控和 .consolidate-lock 的 mtime4.1 lock 文件的 mtime 才是 24h 的起算点AutoDream 的第二层是时间门控。它不会读你的日记也不看你什么时候关机而是读 /.consolidate-lock 的 mtime。计算方式很轻当前时间减去 lock 文件最后修改时间得到小时数如果小于 minHours默认 24就直接退出。因此你说“已经过了 24 小时”和程序说的“已经过了 24 小时”可能不是同一个起点。如果 lock 文件被删过、被编辑器改过、被备份工具同步过mtime 就会变。可以用 stat 看stat -c %y %n memory-dir/.consolidate-lockmemory-dir换成你的记忆目录。看输出的修改时间再和当前时间对比。如果不到 24 小时AutoDream 不触发是时间门控在起作用。注意不要把 lock 文件当缓存随便删删掉等于把上次整合时间清零反而会让下一次判断更混乱。4.2 会话门控为什么要排除当前会话时间门控过了还有会话门控。AutoDream 会列出上次整合之后被修改过的 session过滤掉 currentSession再判断数量是否达到 minSessions默认 5 个。也就是说你在同一个会话里反复聊天聊天次数再多也只算一个会话。要触发巩固需要至少有 5 个不同的会话在时间窗内被改过。这解释了另一种现象时间明明过了 24 小时AutoDream 还是不跑因为最近只有两三个会话。你可以本地数一下 transcript 目录里最近修改的会话文件但不要穷举读取内容。看数量和修改时间就够。如果数量不够就正常用 Claude Code 多开几个会话等门控满足。4.3 10 分钟扫描节流与 60 分钟锁过期会话门控通过后AutoDream 还要拿分布式锁。为了避免时间门控通过但会话不够时每轮都扫文件系统代码里有一个 10 分钟扫描节流距离上次扫描不到 10 分钟就直接返回。这个节流是 backoff不是故障。如果你刚重启就看到“没反应”可以等一个扫描周期再观察。锁文件路径是 /.consolidate-lock内容是持有者 PIDmtime 是获取锁的时间过期时间默认 60 分钟。这个 60 分钟不是 AutoDream 的触发间隔而是防止 PID 复用导致死锁。多开终端窗口时只有一个进程能写入锁并开始巩固其他进程要等锁过期或 PID 消失。4.4 rollbackConsolidationLock 什么时候回滚如果 fork 失败或者你从后台任务面板杀掉了 DreamTask代码会走 rollbackConsolidationLock把 lock 文件的 mtime 恢复到获取之前的值让下一次时间门控仍然能通过。如果之前没有 lock 文件回滚逻辑会删掉它恢复到无文件状态。这个设计是为了避免一次失败把 24 小时计时重置。进程崩溃是另一种情况lock 文件还在PID 变成死进程。下一个进程读到 PID发现它不存活就可以尝试获取锁。60 分钟过期是兜底防止极端情况下锁一直不释放。排障时如果你手动改了 lock 的 mtime回滚逻辑和过期逻辑都会变得不可预测所以先看再动。5. DreamTask、Extract Memories 与 MEMORY.md确认 fork agent 真的动了5.1 stopHooks 触发不等于执行成功stopHooks.ts 里的调用是 fire-and-forget主对话不等待后台任务完成。所以“我发了消息”不等于“Extract Memories 执行成功”更不等于“AutoDream 开始巩固”。Extract Memories 还有互斥和节流如果主 agent 当前轮已经写了记忆文件forked agent 会跳过它受 GrowthBook flag tengu_bramble_lintel 控制可能不是每轮都触发还有最大 5 回合的硬上限防止陷入验证循环。判断 Extract Memories 有没有工作可以看主对话里有没有出现 “Saved N memories” 这样的系统消息以及记忆目录里有没有新增或更新的文件。不要只看对话正常返回。通道稳定后这些信号才有参考价值。如果一直没有先回到第 2 章检查 Key 和 Base URL。5.2 DreamTask 的三个 UI 信号AutoDream 真正跑起来时会通过 DreamTask 注册到任务系统。UI 上通常有三个可见信号底部 Footer pill 显示正在运行的 Dream 任务ShiftDown 打开详情面板看进度第一次 Edit/Write 调用出现时phase 从 starting 翻转为 updating。完成后如果修改了文件主对话里会内联显示 “Improved N memories”。如果你在 Footer 看不到 pill在 ShiftDown 里也找不到 DreamTask那说明任务没有注册成功不是“跑了但没写文件”。此时回到门控排查功能开关、24h 时间门控、5 个会话门控、分布式锁。只有这四层都过了DreamTask 才有机会出现。5.3 记忆类型、沙箱和读取侧验证记忆类型分四种user、feedback、project、reference。它们覆盖的是无法从代码直接推导的信息比如用户角色、工作偏好、项目上下文和外部系统指针。AutoDream 的子 agent 跑在受限沙箱里Read、Grep、Glob 完全允许Bash 只允许只读命令Edit/Write 仅限记忆目录内MCP 和 Agent 等工具会被拒绝。这个沙箱保证了巩固过程不会改你的业务代码。读取侧也要注意MEMORY.md 是索引不是内容堆超过 200 行会被截断。写入时强调“写入要克制读取要验证”。如果某条记忆提到一个文件路径或函数名未来会话在推荐前应该先检查它是否还存在。这个思路同样适用于你排查 AutoDream先验证通道再验证门控不要凭感觉删文件。6. 排完这次 AutoDream再去控制台对一下调用6.1 完整检查清单把上面的排查压成一份顺序清单按这个顺序走不要跳步Claude Code 能否正常对话Key 是否正确Base URL 是否为 https://taotoken.net/api。模型 ID 是否来自模型广场当前列表以 https://taotoken.net/?utm_sourcetaotoken_aicg_blog_end 为准。autoDreamEnabled 是否显式打开KAIROS、Remote、AutoMemory 是否拦住。.consolidate-lock 的 mtime 是否已满 24 小时。上次整合后是否有至少 5 个不同会话被修改。lock 里的 PID 是否存活是否在 60 分钟过期窗口内。Footer pill、ShiftDown、phase 翻转和 “Improved N memories” 是否出现。这份清单里前两步属于 TaoToken 侧只涉及 Key 和 Base URL后面五步属于 AutoDream 自己的门控和任务系统。通道没通时后面五步的结果都不可信。6.2 下一步 deep link配置保存后先在 TaoToken 模型对话 里用同一把 Key 发一条测试消息确认模型 ID 和 Base URL 没填错。如果你准备长期用 Claude Code 写代码可以打开 Coding Plan 看套餐是否够用Key 在 控制台 API Keys 创建。Claude Code 环境变量对照见 接入文档。AutoDream 不动的时候先让通道能稳定回话再去数那 5 个会话和 lock 的 mtime顺序反了只会白折腾。