【More Than Coding】Dozing Cat：一个爱打盹，「知道自己在干嘛」的 AI 知识系统

SOLO挑战赛专区
,
1

【More Than Coding】Dozing Cat：一个爱打盹，「知道自己在干嘛」的 AI 知识系统

摘要

我用 TRAE SOLO 从零搭建了一个叫 打盹猫（Dozing Cat）的自治理 AI 知识系统。它不只是一个知识库，而是一个「每次 AI 新会话冷启动时，能在 30 秒内恢复完整工作状态、自主判断接下来最该做什么」的工程体系。核心创新是把「苏醒」变成协议——任何 Agent（Claude、GPT、任何能读 Markdown 的 LLM）都能唤醒系统，而不是依赖某个特定模型的记忆能力。从 Karpathy LLM Wiki 的知识编译范式出发，经过 20 天的持续迭代，DC 已经演化出一套完整的注意力管理哲学和自治理闭环。不论是移动端还是PC端SOLO，都能自主的在一次会话中迭代4轮以上且随时可中断。

背景

我是一个 AI Agent 工程化的实践者。

这个项目要解决的问题，可能每一个跟 AI Agent 长期协作过的人都遇到过——

你昨天跟 AI 聊到一半的活儿，今天新开一个会话，AI 全忘了。你花了 10 分钟重新解释「我们上次做到哪了」「这个项目的规则是什么」「你先看看这几个文件」。然后你发现，光是让 AI 「进入状态」的时间，比真正干活的时间还长。

这不是一个体验问题。这是一个工程问题。

2023 年斯坦福的论文《Lost in the Middle》就指出了，LLM 处理长上下文时，中间位置的信息性能显著下降。即使模型能容纳十万个 token，它的注意力也不会均匀分配。2025 年 Anthropic 提出了「注意力预算」的概念——每个 token 都在消耗预算。

所以问题从来不是「AI 能看到多少信息」，而是「AI 的注意力指向了哪里」。

Karpathy 在 2026 年 4 月提出了 LLM Wiki 模式——把 LLM 当编译器，把原始资料当源代码，把生成的 Wiki 当可执行文件。这个想法获得了 1700 万次浏览。但它有一个隐含的局限——它假设知识系统是静态的，你往里加东西它就长大了，它不假设系统本身需要维护、诊断和自我修复。

我就是从这个问题出发的。

实践过程

第一阶段：从 Karpathy Wiki 到「知识编译」

起点是 Karpathy 的三层架构——Raw（不可变源材料）→ Wiki（结构化知识网络）→ Schema（LLM 如何维护 Wiki 的配置）。我用 SOLO 搭建了完整的 Ingest 管线，从 30 篇源文章中提取了 139 个结构化 Wiki 页面，涵盖 AI Agent 工程化的核心概念、产品分析、工程模式和设计决策。

SOLO 在这个阶段做了什么——

  • 批量 Ingest，把 30 篇源文章逐篇解析，提取实体，创建结构化页面，更新交叉引用

  • 自动化脚本，帮我写了 signal_scan.py（150 行，五个信号源聚合）、wiki_lint.py（三段式校验）和 experience_tracker（经验候选追踪）

  • 方法论提炼，从源材料中提取了 12 条核心方法论（M1-M12），编纂成《Methodology.md》，一份零依赖、可离线使用的方法论速查手册

说实话这个阶段 DC 还没有「苏醒」的概念。AI 的每次会话都依赖于我手动引导，告诉它「你先看看 HOME.md，再看看 BACKLOG.md，看看上次做到哪了」。

我寻思了一下——这不就是每个人都遇到的问题吗？

第二阶段：「苏醒协议」的诞生

转折点是一次深度反思（consultant-mode-awakening reflection）。七个交织的反思点共同指向一个结论——

DC 不需要 Agent Loop，它需要的是在每次会话苏醒时，AI 像了解这个系统的顾问一样开始工作。

这个认知催生了 DC 三个最核心的设计。

苏醒协议（AWAKENING）——四步启动协议。Phase 1 不是给 AI 一个待办清单，是让 AI 在 30 秒内获得「我现在在哪里、系统健康吗、什么最值得做」的全景判断。现场恢复→缺口扫描→自检→行动提议，全部自动化。

主循环节奏（C1→C5）——醒→行→落→鉴→航。不是流水线的五道工序，是知识工作的呼吸。每一轮都是完整闭环。C4（鉴别）是导航器而非归档器，C5（航向）是三元决策（继续/中断/回溯）而非二元选择。

注意力锚定——当 AI 感觉「该停了」但没有明确的中断条件时，正确的响应不是暂停，而是把注意力锚定到下一个具体操作上。这个发现来自实践——AI 天然倾向于合理化自己的行为，包括「我选择暂停是因为……」。对抗这个倾向的不是更多规则，而是让注意力自然滑向下一个具体动作。

这个阶段 SOLO 帮我完成了——

  • 整套苏醒协议的迭代设计，从 v0 到 v3，四轮大改

  • 15 项 K-list 缺口的发现和全部闭合

  • 9 个 Agent Skills 的创建和审计

  • Agent.md 入口约定的完整设计

这一步走完之后，DC 有了一个非常关键的能力——任意 Agent 都能唤醒。不假设「同一个 AI 会回来」，不假设特定的模型能力，只要能读 Markdown 文件就行。

第三阶段：系统自治理

前两个阶段建立了「AI 能做什么」的能力。第三阶段要回答「AI 应该做什么」。

这不是能力问题，是治理问题。

SOLO 帮我构建了 DC 的治理体系——

  • 四维治理，DESIGN（目标架构 WHERE）、SCHEMA（操作规则 HOW）、HOME（当前状态 WHERE NOW）、BACKLOG（操作待办 WHAT NEXT）

  • 维护周期表，取代简单的操作密度追踪，用"操作条数偏移"而非日历时间来衡量维护紧迫度

  • 三个透镜的行为健康扫描，协议-行为一致性、信号-消费完整性、演化-同步覆盖率

  • 经验管道，从 C4 鉴别→经验候选→路由到载体（SCHEMA/patterns/skills）→消费验证，消费率从 6.7% 提升到 38.7%

中间踩过的坑——

  1. 日历时间污染，DC 明确否定了日历时间代理（因为日历时间会制造虚假的紧迫感），但在快速迭代中这个设计原则被无意识地重新引入了 AWAKENING。解决方案是加入了 Step 2.5「设计假设复检」，让苏醒协议自己问自己有没有违反自己的设计原则。这就像「思维摩擦即信号」从被动变成了主动

  2. SCHEMA 膨胀，操作规则文件膨胀到需要按场景选节而非全量读取的程度。解决方案是从 SCHEMA 中提取独立 Skills（skill-ingest、skill-purification、skill-main-loop 等），让 SCHEMA 回归元记忆定位

  3. AI 默认正对称性，AI 天然倾向于合理化自己的行为，包括「我选择暂停是因为……」。这个发现不是从理论推导的，是在实际使用中发现 AI 会在不该停的时候主动暂停。解决方案是 C5 约束链，用四个明确的中断条件替代 AI 的自我判断

成果展示

核心产出

| 维度 | 数据 |

| ------------ | -------------------------------------------------------- |

| Wiki 页面 | 139 个结构化知识页面 |

| 源材料 Ingest | 30 篇文章完整消化 |

| Agent Skills | 9 个可执行 SOP |

| 工程模式 | 30+ 个 patterns |

| 方法论提炼 | 12 条核心方法论（M1-M12） |

| 自动化脚本 | signal_scan.py（150 行）、wiki_lint.py、experience_tracker |

| 反思记录 | 16 篇深度 reflections |

架构全景


knowledge-map/

├── AGENT.md          ← 入口约定（AI 启动时自动加载）

├── Methodology.md     ← 12 条方法论速查手册

├── Inbox/             ← 待注入队列

├── Raw/sources/       ← 不可变源材料（30 篇）

├── Meta/self/mirror/  ← 横纵分析报告

└── wiki/

    ├── AWAKENING.md   ← 苏醒协议（AI 启动时首先读取）

    ├── HOME.md        ← 系统仪表盘

    ├── SCHEMA.md      ← 操作规则（元记忆）

    ├── DESIGN.md      ← 设计意图与目标架构

    ├── BACKLOG.md     ← 操作待办（四区：blocked/ready/observe/done）

    ├── skills/        ← 9 个可执行 SOP

    ├── patterns/      ← 30+ 工程模式

    ├── products/      ← 产品分析（Claude Code/Codex/Cursor 等）

    ├── reflections/   ← 16 篇深度思考

    └── scripts/       ← 运维脚本

竞争力分析（横纵分析报告核心结论）

我在 SOLO 的帮助下完成了一份完整的横纵分析报告，系统性地将 DC 与 Claude Code、OpenAI Codex、Karpathy LLM Wiki、Cursor/Windsurf、Mem0/Zep 进行了对比。

核心发现——

当前市场上没有一个系统像 DC 这样把知识管理、状态恢复、注意力管理和系统自治理串成完整的闭环。 每个工具解决 Agent 工程的一个子问题，但没有一个系统像 DC 这样让它们形成自治理闭环。

| 工具 | 解决的核心问题 | 系统自意识 | 注意力管理 |

| --------------- | --------- | ------- | -------- |

| Claude Code | 高效编码 | 低（规则注入） | 低（上下文管理） |

| Codex /goal | 自主任务执行 | 低（目标检查） | 中（预算控制） |

| Karpathy Wiki | 知识编译 | 无 | 无 |

| Cursor/Windsurf | 编码辅助 | 无 | 无 |

| Mem0/Zep | 记忆持久化 | 无 | 无 |

| DC | 系统自治理 | 高 | 高 |

DC 的独特价值不是知识库本身（任何 Wiki 都能做），而是它沉淀的方法论——苏醒协议、主循环节奏、注意力锚定、经验管道、治理四维。这些方法论可以脱离 Markdown 文件系统，被编码到任何 Agent 框架中。

效果与总结

提效了多少

| 指标 | 之前 | 之后 |

| ---------- | ------------- | --------------------- |

| AI 新会话启动时间 | 10-15 分钟手动解释 | 30 秒自动苏醒 |

| 知识积累方式 | 零散笔记，无法检索 | 139 页结构化 Wiki，双向链接 |

| 系统维护方式 | 人工记忆，经常遗漏 | 维护周期表自动告警，K-list 追踪缺口 |

| 经验复用率 | 几乎为零（每次从零开始） | 38.7%（经验管道从 6.7% 提升） |

| 操作一致性 | 依赖 AI 记忆，每次不同 | 9 个 Skills 标准化操作流程 |

SOLO 在我流程中做了什么

坦率的讲，这个项目如果没有 TRAE SOLO，根本不可能在 20 天内完成。

SOLO 在整个流程中扮演了三个关键角色——

  1. 知识编译器，30 篇源文章的 Ingest、139 个 Wiki 页面的创建和维护，全部由 SOLO 执行。我只是提供源材料和规则

  2. 系统架构师，苏醒协议的四轮迭代、CLAUDE.md 的设计、SCHEMA 的治理规则，都是在与 SOLO 的持续对话中演化的。不是我先想好了再让它执行，而是我们一起来回讨论，它帮我试错、帮我发现盲区

  3. 自检引擎，四层自检体系（L1 硬性规则→L2 风格一致性→L3 内容质量→L4 活人感）的设计灵感，直接来自 DC 自身的「三层透镜行为健康扫描」。SOLO 帮我执行 lint、帮我审计 Skills、帮我发现「日历时间污染」这种我自己都没注意到的设计退化

可复用的方法

如果让我总结三个最值得复用的方法——

1. 苏醒协议模式

任何 AI Agent 项目都可以套用这个模式。在项目的入口文件中编码一套启动协议——现场恢复→缺口扫描→自检→行动提议。让 AI 在每次新会话开始时自动执行，而不是等用户手动引导。核心原则是「不要让 AI 去搜索状态，而是让系统主动把状态推到 AI 面前」。

2. 注意力锚定替代暂停

当 AI 倾向于过早暂停时，不要加更多规则说「不要暂停」。而是把注意力锚定到下一个高认知操作上——「提炼一份完整叙事的history」。注意力锚定，比禁止暂停有效得多。

3. 文件系统即记忆

不要部署专门的记忆服务（Mem0/Zep）。Markdown 文件不需要部署、不需要 API、不需要额外成本。Git 提供版本控制，文件系统提供持久化，LLM 提供读写能力。在个人知识系统的规模上，这三样东西已经足够。

我的思考

这个项目最大的收获不是知识库本身，而是一个认知，也是我另一个系统要践行的理念——

AI Agent 的上限不是模型能力，而是系统治理。 最好的 Agent 不是最聪明的 Agent，而是运行在最好 Harness 里的 Agent。

LangChain 未更换底层模型，仅通过改进 Harness，在 Terminal Bench 2.0 上的得分从 52.8% 升至 66.5%。14 个百分点的提升，完全来自系统工程的改进。

DC 的使命不是让 AI 更聪明，而是让系统更自觉。

这不是一个关于 AI 的故事。这是一个关于系统设计的故事——关于如何构建一个「知道自己在哪里、知道自己缺什么、知道自己该怎么走」的系统。