【技术干货】自进化知识库 + AI 编码代理：从概念到落地实战（含完整代码示例）

---

摘要

本文基于 Andrej Karpathy 提出的"自进化知识系统"思路，系统解析三层 LLM Wiki 架构（Raw Source / Wiki / Schema Rules），并给出一个可运行的 Python Demo：如何用大模型自动整理 Markdown 知识库，并增强 AI 编码代理能力。文末附多模型接入实践与平台选型建议。

---

一、背景介绍：从"记笔记"到"为 Agent 造大脑"

传统笔记/知识管理工具（Notion、Obsidian 等）本质上是"给人看的"：

• 人来写内容
• 人来维护结构、标签和链接
• AI 只是做检索、摘要或问答的插件

Andrej Karpathy 的设想把这件事完全反过来了：

不是"人写知识库、AI 来查"，而是"人只丢原始资料，知识库由大模型持续重构，主要服务 AI Agent"。

在视频中提到的案例 Farza Pedia：

• 输入：2500+ 条原始数据（备忘录、消息、日记等）
• 输出：一套为 Agent 设计的"个人维基"，包含数百篇结构化页面，围绕人物、兴趣、想法、灵感等自动整理
• 用途：不仅能回答问题，还能辅助设计 landing page、系统架构等实际任务

更关键的是，这个系统会持续自我更新、自我检查和自我修复，让连接其中的 AI 编码代理不断"变聪明"。

---

二、核心原理：三层 LLM Wiki 架构

Karpathy 提出的 LLM Wiki 大致分为三层：Raw Sources、Wiki、Schema Rules。

2.1 Raw Sources：不可变「原始事实层」

• 内容：你的原始资料
  • 日志 / 笔记 / 代码片段
  • 项目需求文档 / API Spec
  • 历史聊天记录、邮件等
• 特性：
  • 尽量视为不可变（immutable）：历史真实记录，不做"重写"
  • 只 append，不反复编辑
• 作用：
  • 给模型提供真材实料，降低幻觉
  • 形成统一、持久的"事实源"

2.2 Wiki：LLM 生成 + 持续重构的「知识视图层」

• 形式：大量 Markdown 文件（如 index.md、project_X.md 等）
• 生成方式：
  • 大模型从 Raw Sources 中抽取信息
  • 生成结构化条目：概念、人物、项目、组件、API 等
  • 自动创建双向链接、索引和分类
• 特点：
  • 对 Agent 友好：
    • 链接清晰，易于遍历
    • 条目相对稳定，语义清晰
  • 会持续被 LLM 自己"回读、改写、校对"
• 典型能力：
  • 检测矛盾：两个页面对同一概念描述不一致
  • 补齐缺失链接：发现可以互相链接的页面
  • 重写摘要：把冗长笔记压缩成更高质量概述

2.3 Schema Rules：给 LLM 的「知识工程规范」

这一层本质上是一个"约束文档 + Prompt 模板"，告诉模型：

• 如何命名页面（命名规范）
• 如何组织章节（如：背景 / API / 使用示例 / 参考）
• 允许什么类型的链接（人物---项目，项目---组件，组件---API 等）
• 如何更新（新增条目、合并条目、标记废弃信息）
• 如何执行"知识库体检"（lint / health check）

有了 Schema Rules，大模型从"随缘写 wiki"变成"在统一知识工程规范下维护项目文档"。

---

三、实战演示：用 Python 搭建一个最小自进化知识库

下面实现一个最小可用 Demo：

• 使用 https://xuedingmao.com 的 OpenAI 兼容接口
• 模型：claude-sonnet-4-6
• 功能链路：
  1. 将原始笔记写到 raw/ 目录
  2. 调用大模型，从 raw/ 生成/更新 wiki/index.md
  3. 实现一个"知识库自检"函数：检查矛盾、缺失链接等
  4. 展示如何给编码代理提供更强的上下文

说明：代码为真实可运行 Demo，需提前在环境变量中配置 XUEDINGMAO_API_KEY。

3.1 准备：安装依赖与目录结构

pip install openai python-dotenv
mkdir -p data/raw data/wiki

目录约定：

data/
  raw/
    notes_1.md
    notes_2.md
  wiki/
    index.md        # 由模型生成/更新
    schema.md       # 我们写给模型看的"Schema Rules"

3.2 Python：核心脚本

import os
from pathlib import Path
from dotenv import load_dotenv
from openai import OpenAI

# 加载环境变量中的 API Key
load_dotenv()
API_KEY = os.getenv("XUEDINGMAO_API_KEY")
if not API_KEY:
    raise RuntimeError("请在环境变量中设置 XUEDINGMAO_API_KEY")

# 初始化 OpenAI 兼容客户端，base_url 指向薛定猫 AI
client = OpenAI(
    api_key=API_KEY,
    base_url="https://xuedingmao.com/v1"
)

BASE_DIR = Path(__file__).resolve().parent
RAW_DIR = BASE_DIR / "data" / "raw"
WIKI_DIR = BASE_DIR / "data" / "wiki"
SCHEMA_FILE = WIKI_DIR / "schema.md"
INDEX_FILE = WIKI_DIR / "index.md"

MODEL_NAME = "claude-sonnet-4-6"


def call_llm(system_prompt: str, user_prompt: str) -> str:
    """
    通用大模型调用封装。
    使用 chat.completions.create（OpenAI 兼容协议）。
    """
    resp = client.chat.completions.create(
        model=MODEL_NAME,
        messages=[
            {"role": "system", "content": system_prompt},
            {"role": "user", "content": user_prompt}
        ],
        temperature=0.2,
    )
    return resp.choices[0].message.content


def read_all_raw_sources() -> str:
    """
    读取 data/raw 下所有 .md 文件，拼接为一个大文本，
    用于作为"不可变原始事实层"的输入。
    """
    parts = []
    for f in sorted(RAW_DIR.glob("*.md")):
        parts.append(f"# FILE: {f.name}\n\n")
        parts.append(f.read_text(encoding="utf-8"))
        parts.append("\n\n")
    return "\n".join(parts)


def ensure_schema_file():
    """
    如果 schema.md 不存在，则创建一个简单的 Schema 规则文件，
    用于约束模型如何组织 wiki。
    """
    if SCHEMA_FILE.exists():
        return

    schema_content = """# LLM Wiki Schema Rules

## 目标
- 为 AI 编码代理提供结构化、可链接、可扩展的知识库视图。
- 所有内容以 Markdown 组织，使用标题、列表和代码块。

## 结构规范
- 顶层文件为 `index.md`，包含全局目录和主要实体列表。
- 对重要实体（项目、组件、API、人物等）创建单独小节：
  - 标题格式：`## [实体类型] 实体名`
  - 内容结构：背景 / 关键信息 / 相关实体链接 / 示例。

## 链接规则
- 使用 Markdown 链接引用其他部分，例如：
  - `[项目A](#project-项目a)`
  - 链接文本尽量使用唯一名字 + 中文说明。
- 尽可能为相关概念之间建立交叉引用。

## 更新策略
- 在保持一致性的前提下，可以重写摘要、合并冗余内容。
- 新出现的重要实体应加入 index 总目录。
- 不直接修改"原始事实"，仅在 wiki 层做抽象和总结。

## 自检 (lint) 指南
- 检查是否存在明显矛盾描述，并提出修正建议。
- 标记"缺失链接"的地方，用 TODO 形式注明。
- 优化段落结构，减少重复内容。
"""
    WIKI_DIR.mkdir(parents=True, exist_ok=True)
    SCHEMA_FILE.write_text(schema_content, encoding="utf-8")


def update_wiki_index():
    """
    从 raw sources 生成/更新 wiki/index.md。
    核心思路：
      - system 中注入 Schema Rules
      - user 中同时给出"当前 index.md（如有）+ 最新原始资料"
      - 让模型在保持结构的前提下增量更新
    """
    ensure_schema_file()

    schema_rules = SCHEMA_FILE.read_text(encoding="utf-8")
    raw_text = read_all_raw_sources()

    if INDEX_FILE.exists():
        current_index = INDEX_FILE.read_text(encoding="utf-8")
    else:
        current_index = ""

    system_prompt = f"""你是一个负责维护 LLM 驱动知识库的"知识工程师"。
你不会修改原始事实，只会在 wiki 层做结构化抽象。
以下是知识库的 Schema 规则，请严格遵守：

{schema_rules}
"""

    user_prompt = f"""现在请基于"原始资料"更新 wiki 的 index.md。

要求：
- 如果当前已有 index.md，请在其基础上演化，不要完全推翻重写。
- 提取出重要的实体（项目、组件、API、人物、概念等），建立清晰的小节结构。
- 为相关实体添加 Markdown 链接，形成可遍历的知识图谱。
- 用简洁中文撰写摘要，但可以保留英文标识符和专有名词。
- 输出完整的 index.md 内容，不要省略。

--- 当前 index.md 内容（可能为空） ---
{current_index}

--- 原始资料（只读） ---
{raw_text}
"""

    new_index = call_llm(system_prompt, user_prompt)
    INDEX_FILE.write_text(new_index, encoding="utf-8")
    print("✅ wiki/index.md 已更新")


def lint_wiki():
    """
    对 wiki/index.md 做一次"自检"：
      - 让模型阅读当前 wiki
      - 找出矛盾、缺失链接、结构问题
      - 返回一份修订后的 index.md
    """
    ensure_schema_file()

    if not INDEX_FILE.exists():
        raise RuntimeError("index.md 不存在，请先运行 update_wiki_index()")

    schema_rules = SCHEMA_FILE.read_text(encoding="utf-8")
    current_index = INDEX_FILE.read_text(encoding="utf-8")

    system_prompt = f"""你是一个负责"知识库体检(lint)"的 LLM。
目标：在不改变事实的前提下，提升 wiki 的一致性、连贯性和可用性。
Schema 规则如下：

{schema_rules}
"""

    user_prompt = f"""请对以下 wiki/index.md 进行全面审查和改进：

- 修复明显矛盾或逻辑冲突，如有不确定可用 TODO 标记。
- 为明显相关但未链接的实体补充链接。
- 标注发现的"缺失信息点"，使用 `TODO:` 说明。
- 保持原有结构的同时，可以合并冗余段落、优化标题。

输出改进后的完整 index.md 内容。

--- 当前 index.md ---
{current_index}
"""

    refined_index = call_llm(system_prompt, user_prompt)
    INDEX_FILE.write_text(refined_index, encoding="utf-8")
    print("✅ wiki/index.md lint 完成（已自我修复）")


def answer_question_with_wiki(question: str) -> str:
    """
    示例：编码代理在回答问题时，如何利用 wiki/index.md 提升回答质量。
    这里我们只做一个简单版：
      - 将 index.md 内容当作"知识上下文"
      - 提供给模型，让其基于此回答问题
    在实际项目中，你可以在此处做分段检索、向量检索等。
    """
    if not INDEX_FILE.exists():
        raise RuntimeError("index.md 不存在，请先构建 wiki")

    index_content = INDEX_FILE.read_text(encoding="utf-8")

    system_prompt = """你是一个 AI 编码助手，善于阅读项目知识库（wiki）并基于此回答问题。
优先使用 wiki 中的内容，不要凭空捏造不存在的 API 或模块。
如果 wiki 中信息不足，请明确说明"不确定"，并指出可能需要补充的原始资料类型。"""

    user_prompt = f"""以下是 wiki/index.md 的内容（可视作整个知识库的导览）：

--- WIKI INDEX START ---
{index_content}
--- WIKI INDEX END ---

现在请基于 wiki，回答用户问题：

{question}
"""

    return call_llm(system_prompt, user_prompt)


if __name__ == "__main__":
    """
    简单 CLI：
      1. 先将若干 markdown 笔记放入 data/raw
      2. 运行本脚本：
         - 自动构建/更新 wiki/index.md
         - 进行一次 lint 自检
         - 演示基于 wiki 回答一个问题
    """
    print("=== Step 1: 更新 wiki/index.md ===")
    update_wiki_index()

    print("=== Step 2: 对 wiki 做一次 lint 自检 ===")
    lint_wiki()

    print("=== Step 3: 示例问答 ===")
    demo_q = "请根据当前知识库，帮我总结这个项目涉及的主要模块，并给出对新开发者的上手建议。"
    answer = answer_question_with_wiki(demo_q)
    print("=== 模型回答 ===")
    print(answer)

运行效果：

1. 第一次运行时：
   • 生成 schema.md（约束规则）
   • 从 data/raw 中提取笔记，生成一个结构化的 index.md
2. 再次运行时：
   • update_wiki_index 会在原有结构上增量演化
   • lint_wiki 会根据规则对 wiki 自我修复
3. answer_question_with_wiki 模拟一个"挂着知识库的 AI 编码代理"。

在真实项目中，你可以把 answer_question_with_wiki 换成完整的"代码 Agent"，例如：

• 让 Agent 在回答问题前先"查表"（读 wiki 的相关章节）
• 基于 wiki 中的组件、API、约束来生成代码，而不是凭空发挥
• 将 Agent 输出的设计文档、结果再写回 Raw Sources，形成闭环

---

四、注意事项与工程实践建议

4.1 减少幻觉：让事实和视图解耦

• Raw Sources 仅保存事实（日志、Spec、代码）
• Wiki 是 LLM 的"观点层"，可以不断重写，但必须可追溯到 Raw Sources
• Schema 中明确"不要凭空增加新 API/模块，除非在 Raw Sources 中有证据"

4.2 Token 成本与上下文裁剪

• 不要直接把所有 Raw Sources 丢进一次调用
• 推荐做分片 + 召回（向量检索 / 关键字检索）
• Wiki 本身就是一种"稀疏摘要+索引"，大幅降低 Agent 调用大模型的 token 消耗

4.3 自进化流程自动化

建议把以下命令做成定时/CI 任务：

1. 每天 / 每 PR 合并后：
   • 从代码库、文档更新同步 Raw Sources
   • 调用 update_wiki_index 生成新的视图
2. 每周一次：
   • 调用 lint_wiki，对整个知识库做"健康检查"

这在中大型代码库（尤其是多 Agent 协同场景）会极大降低认知负担。

---

五、技术资源与平台选型建议

实现这类"自进化知识库 + 多 Agent 协同"，一个现实问题是：不同模型、不同厂商 API 的集成成本非常高：

• GPT 系列适合复杂推理和代码生成
• Claude 系列在长上下文和说明文档整理方面表现优异
• Gemini 等模型在多模态和工具调用上有优势

如果每个模型都单独接入，会面临：

• 不同协议/SDK
• 认证方式各异
• 更新节奏不同，维护成本高

在这种场景下，更推荐使用统一接入层 的方式，例如本文示例用到的薛定猫 AI（https://xuedingmao.com）：

• 聚合 500+ 主流大模型：包括 GPT-5.4、Claude 4.6、Gemini 3 Pro 等
• 新模型实时首发：对实验性玩法（比如让不同模型分别负责"Wiki 构建"、"Lint"、"编码 Agent"）非常友好
• 统一 OpenAI 兼容接口 ：
  • 你可以像上面那样，只写一套 OpenAI 客户端调用
  • 换模型只要改 model 名称即可
• 适合多模型流水线 ：
  • 用 Claude 4.6 做长文档整理和 wiki 构建
  • 用 GPT 系列做代码生成和调试
  • 用其他专长模型做向量检索、重排等

从工程角度看，这种统一接入层能显著降低"多模型自进化系统"的复杂度，更利于将架构长期维护下去。

---

小结

通过一个最小实践，你可以看到：

• 自进化知识库的关键不是 UI，而是：
  • Raw Sources（事实层）
  • Wiki（视图层）
  • Schema Rules（知识工程规范）
• 将这些与 AI 编码代理结合，可以让 Agent 随着时间真正"变聪明"，而不是每次都从零开始推理
• 使用统一的多模型 API 平台，可以极大降低实现这套体系的集成成本

接下来你可以尝试：

• 把自己的项目需求文档、API 文档、历史 Issue 丢进 raw/
• 微调 schema.md，增加适合你团队的命名规范和文档模板
• 在 CI 中加入自动 update_wiki_index 和 lint_wiki 步骤
• 把现有的 AI 编码助手接入这个 wiki 系统，观测回答质量的变化

---

#AI #大模型 #Python #机器学习 #技术实战