# 知识库 Agent 构建方案

本次执行开始时间：2026-05-15-10-48-07

参考原文：<https://gist.githubusercontent.com/karpathy/442a6bf555914893e9891c11519de94f/raw/ac46de1ad27f92b28ac95459c782c07f6b8c964a/llm-wiki.md>

本地归档：`文档知识库构建流/llm-wiki.md`

## 一、核心思想

Karpathy 的 `LLM Wiki` 方案不是传统的一次性 RAG：不是每次提问时临时从原始文档里找片段、再重新拼答案，而是让 LLM 持续维护一个持久化的 Markdown Wiki。每加入一份材料，Agent 都要阅读、抽取、归类、交叉引用，并把新信息写入已有知识结构。

对当前材料汇总任务来说，最佳形态是：

- `个人事迹材料文档_MD`、`其他事迹材料文档_MD`：作为既有写作风格、表达结构、过往申报口径的基础语料。
- `个人事迹支撑材料汇总`：作为完整素材库和证据库，里面的图片、截图、链接、证书、项目材料是事实依据。
- `待完善内容`：作为草稿处理区，只用于待补充材料的阅读、写作和迭代，不作为需要推送到 Gitea 的正式库内容。
- `文档知识库构建流`：用于存放知识库构建方法、原始参考文档，以及后续可扩展的 Wiki、索引、日志、证据卡片等。

目标不是只“搜索材料”，而是逐步形成一个可复用的个人事迹知识库：每个成果、奖项、项目、论文、任职、荣誉都有稳定页面、证据路径、可引用表述和与其他材料的关系。

## 二、推荐目录结构

建议后续在 `文档知识库构建流` 下逐步形成如下结构：

```text
文档知识库构建流/
  llm-wiki.md                         # Karpathy 原始方法文档
  wiki/
    index.md                          # 知识库总索引
    log.md                            # 处理日志，按时间追加
    人物画像.md                       # 个人总体画像、主线叙事、关键词
    事实清单.md                       # 可复用事实与证据索引
    写作口径.md                       # 常用表述、风格、注意事项
    材料任务/
      ...                             # 针对待完善内容的任务页
    成果/
      ...                             # 论文、专利、项目、转化、典型案例
    荣誉竞赛/
      ...                             # 奖项、荣誉、竞赛
    任职与社会服务/
      ...                             # 学校任职、学术协会、代表身份
    来源卡片/
      ...                             # 每个文本/图片/视频来源的摘要卡
```

原始材料不搬动、不改写，Wiki 只保存 Agent 生成的结构化摘要、索引和交叉引用。原始文件仍以现有目录为准。

## 三、三层架构

第一层是原始来源层。包括 PDF 转换出的 Markdown、支撑材料库中的图片、截图、链接文本、HEIC、视频等。这一层是事实源，不应由 Agent 随意修改。

第二层是 Wiki 层。它由 Agent 维护，包含主题页、人物页、成果页、证据卡、写作口径、任务页、对照表。每次新增材料或产生重要分析，都应沉淀到 Wiki。

第三层是 Schema/工作规范层。也就是这份 `知识库Agent构建.md` 以及后续可能新增的 `AGENTS.md`、`index.md`、`log.md`。它规定 Agent 如何入库、如何回答问题、如何撰写材料、如何引用证据。

## 四、文本材料入库方式

文本材料包括：

- `个人事迹材料文档_MD/**/*.md`
- `其他事迹材料文档_MD/**/*.md`
- `个人事迹支撑材料汇总/**/*.txt`
- PDF 转换后得到的 Markdown、JSON 辅助信息
- 后续 `待完善内容` 中的待补充文本

每份文本入库时应提取：

- 来源路径：必须保留相对路径，方便追溯。
- 材料类型：事迹材料、申请表、通讯稿、征文、链接说明、获奖证明说明等。
- 时间信息：年份、月份、事件发生时间、获奖/发表/授权/立项时间。
- 主体身份：第一负责人、一作、共同一作、参与、主持、理事、委员、代表等。
- 关键事实：奖项等级、项目名称、论文题目、专利号、组织单位、金额、平台名称。
- 可复用表述：适合写进申报材料的凝练句子。
- 风格信号：政治性、学术性、创新创业、社会贡献、组织服务等叙事倾向。
- 证据关系：哪些图片、链接、证书可以支撑这条事实。

入库产物建议为“来源卡片”：

```markdown
---
type: source
source_path: 个人事迹材料文档_MD/...
source_kind: past_material
year: 2026
tags: [党员, 荣誉, 事迹材料]
confidence: high
---

# 来源标题

## 摘要

## 可抽取事实

## 可复用表述

## 相关证据

## 关联页面
```

## 五、图片与多模态材料入库方式

`个人事迹支撑材料汇总` 中大量材料是图片、截图、证书、网页截图、设备照片和视频。多模态知识库的关键不是只记录文件名，而是把图片中可见的信息结构化成可检索、可引用、可校验的证据。

图片入库步骤：

1. 先从文件路径和文件名抽取初始信息，例如年份、奖项名、项目名、身份、级别。
2. 使用视觉读取图片内容，识别证书/截图上的标题、落款、单位、时间、奖项等级、姓名、项目名。
3. 将“文件名信息”和“图中可见信息”分开记录，避免把推断当成证据。
4. 给每张图片生成证据卡，标注可信度和可引用范围。
5. 把证据卡链接到对应主题页，例如“国家奖学金”“数据要素典型案例”“专利转化”“ACS 会议论文”。

图片证据卡建议格式：

```markdown
---
type: evidence_image
source_path: 个人事迹支撑材料汇总/竞赛获奖/...
media_type: image
year: 2024
tags: [竞赛获奖, 省赛一等奖, 项目]
confidence: medium
---

# 图片证据：标题

## 文件名提供的信息

## 图中可见信息

## 可支撑事实

## 不能直接证明的内容

## 关联主题页
```

对 HEIC、视频等材料：

- HEIC：如当前工具无法直接读取，应优先转换为 PNG/JPG 副本后再视觉入库，原文件保持不动。
- 视频：不建议整段作为文本证据直接使用。应抽取关键帧，记录视频文件路径、时长、关键帧时间点、画面内容、可支撑事实。
- 项目设备照片：重点记录设备代际、使用场景、临床/动物实验/汇报场景，而不是过度推断技术性能。

多模态调用时的原则：

- 先读 Wiki 中的证据卡，再打开原图复核关键事实。
- 写正式材料时，只有“图中明确可见”或“文件名与上下文共同支持”的事实才可作为强证据。
- 对仅从文件名推断的信息，要写成“待核验”或“弱证据”，避免误写。

## 六、索引与日志

`index.md` 是内容索引，应按主题组织：

- 个人主线与总体画像
- 过往事迹材料
- 荣誉表彰
- 竞赛获奖
- 论文会议
- 专利软著
- 项目与科技查新
- 创新创业与成果转化
- 任职与社会服务
- 媒体报道与典型案例
- 待完善材料任务

每个条目建议包含：页面链接、一句话摘要、年份、证据数量、可信度。

`log.md` 是时间日志，应追加记录，不覆盖历史。建议格式：

```markdown
## [2026-05-15-10-48-07] ingest | llm-wiki 方法文档

- 动作：下载并阅读 Karpathy 的 LLM Wiki 方法文档。
- 产物：知识库Agent构建.md
- 备注：建立文本+图片知识库构建规范。
```

后续每次执行前都记录开始时间，格式保持 `{Year}-{Mon}-{Day}-{Hour}-{Min}-{Sec}`，便于追踪每轮处理做了什么。

## 七、Agent 调用方法

### 1. 入库调用

适用场景：新增支撑材料、转换了新 PDF、补充了链接或证书。

流程：

1. 记录开始时间。
2. 用 `git status --short --ignored` 检查新增内容和被忽略内容。
3. 用 `find` 或 `rg --files` 定位新增材料。
4. 文本材料直接阅读；图片材料打开视觉检查；视频材料必要时抽关键帧。
5. 为每个来源生成或更新来源卡片。
6. 更新相关主题页、`index.md`、`log.md`。
7. 标注冲突、待核验、证据强弱。

### 2. 查询调用

适用场景：询问“某个奖项能怎么写”“某段经历有哪些证据”“这份申报表应突出什么”。

流程：

1. 先读 `wiki/index.md`，确定相关主题页。
2. 用 `rg` 搜索年份、项目名、奖项名、关键词。
3. 阅读主题页和来源卡片。
4. 必要时打开原图或原始 Markdown 复核。
5. 输出答案时附相对路径引用，区分“已证实事实”和“建议表达”。
6. 如果答案形成了新分析，应沉淀到 Wiki 的任务页或主题页。

### 3. 撰写待完善内容

适用场景：补写 `待完善内容` 中的申请表、事迹材料、通讯稿、汇总表。

流程：

1. 读取待完善文件，识别栏目、字数、语气、约束。
2. 读取过往 MD 材料，提取可沿用结构和表达口径。
3. 从支撑材料 Wiki 中拉取事实清单与证据。
4. 先生成“事实-证据-可写角度”对照表。
5. 再写正文，避免把证据不足的内容写成确定事实。
6. 完稿后做一致性检查：年份、角色、奖项等级、项目名称、单位名称是否一致。
7. `待完善内容` 是处理空间，不作为需要推送到 Gitea 的正式内容。

### 4. 健康检查调用

建议周期性运行：

- 查找同一奖项/项目在不同页面中的年份或等级冲突。
- 查找只有结论没有证据路径的事实。
- 查找证据图片未入卡、主题页未链接的孤立材料。
- 查找过往材料中已经陈旧的表述。
- 查找可合并的重复主题。
- 查找适合补充外部网页链接的事实缺口。

## 八、面向当前材料库的主题页设计

建议优先建立这些主题页：

- `人物画像.md`：总体身份、主线叙事、关键词、材料写作定位。
- `学术科研成果.md`：论文、会议、科技查新、研究方向。
- `创新创业与成果转化.md`：公司、专利转化、典型案例、项目落地。
- `竞赛获奖.md`：按年份、级别、负责人身份组织。
- `荣誉表彰.md`：国家奖学金、优秀研究生、专项奖学金等。
- `专利软著.md`：专利号、授权状态、作者顺位、软件著作权。
- `社会服务与任职.md`：学术协会、校内任职、代表身份。
- `媒体报道与社会影响.md`：官媒报道、典型案例、链接证据。
- `写作素材库.md`：可复用句式、段落、标题、过渡语。
- `事实清单.md`：所有高可信事实的总表。

## 九、证据强度分级

建议每条事实都标注证据强度：

- `high`：证书/公示/正式表格/网页截图中明确可见，且与文件名一致。
- `medium`：文件名、上下文、截图部分信息共同支持，但图片中关键信息不完整。
- `low`：仅来自文件名或过往材料表述，尚未找到直接证据。
- `needs_check`：存在冲突、截图不清、年份不确定、角色不确定。

正式撰写时优先使用 `high` 和 `medium`，`low` 只作为提示，不直接写成确定事实。

## 十、提交与同步约束

- `个人事迹材料文档_MD`、`其他事迹材料文档_MD`、`个人事迹支撑材料汇总` 可以作为知识库来源。
- `文档知识库构建流` 和 `知识库Agent构建.md` 可以作为知识库方法和结构产物。
- `待完善内容` 是处理空间，后续不应推送到 Gitea。
- 每次提交前必须检查 `git status --short --ignored`，确认是否误包含 `待完善内容`。
- 已从机制上防止误推：本仓库 `.gitignore` 已加入：

```gitignore
待完善内容/
```

## 十一、每次运行后的 Gitea 备份规则

后续每次执行材料处理、知识库更新、草稿撰写或素材整理后，都要在收尾阶段执行 Gitea 备份。

固定流程：

1. 记录本次执行开始时间，格式为 `{Year}-{Mon}-{Day}-{Hour}-{Min}-{Sec}`。
2. 执行任务并完成必要核验。
3. 提交前运行 `git status --short --ignored`，确认 `待完善内容/` 只作为被忽略处理空间，不进入提交。
4. 将需要备份的正式材料、知识库产物、构建规范加入 Git。
5. 使用包含时间的提交信息，例如：

```bash
git commit -m "backup 2026-05-15-10-52-04"
```

6. 推送到 Gitea：

```bash
git push
```

如本次运行没有任何可备份变更，应在回复中说明“无新增正式变更，因此未创建提交”。