一本码簿

初始安装

1
2
3
4
5
6
7
8

sh -c "$(wget -qO- https://haies.cn/assets/install-zsh.sh)"
sh -c "$(wget -qO- https://haies.cn/assets/apt-install.sh)"
sh -c "$(wget -qO- https://haies.cn/assets/debian-init.sh)"
sh -c "$(wget -qO- https://haies.cn/assets/centos-init.sh)"
sh -c "$(wget -qO- https://haies.cn/assets/ubuntu-init.sh)"

sh -c "$(wget -qO- https://haies.cn/assets/yum-install-docker.sh)"
sh -c "$(wget -qO- https://haies.cn/assets/dns.sh)"

压缩

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19

7za a -mx0 -v4g backup.7z /path/to/data
7za a -mx0 -v4g backup.7z /path/to/*
7za x -mx0 "backup.7z.001" -o/path/to/

7za a -tzip  backup.zip /path/to/data
7za x -tzip  backup.zip /path/to/data

tar -cvpf - /path/to/folder | split -d -b 4g - backup.tar
tar -xvpf backup.tar.00 -C /path/to/target_folder #要求分卷是纯 tar 分割（未压缩），且分卷命名连续
cat backup.tar.* | tar -xpv  -C /path/to/folder

tar -czvpf - /path/to/folder | split -d -b 4g - backup$(date +%Y%m%d).tar.gz
cat backup.tar.gz.* | tar -xzvp  -C /path/to/folder
gzip -t backup.tar.gz

tar -cvpf nginx.tar /etc/nginx
tar -xvpf nginx.tar -C /path/to/folder

ls -l |grep ^d|awk {'print $9'}|xargs -t -i 7z a {}.7z {}

7z mx参数

7z 压缩方案

查看系统信息

1
2
3
4
5
6

id -un
uname -a
lsb_release -c
lscpu
lshw
cat /proc/meminfo

磁盘管理

查看磁盘格式：lsblk -f
查看磁盘信息：fdisk -l

1
2
3
4
5
6
7
8
9
10
11
12
13
14

mkfs.xfs -f /dev/vdb &&
mkdir /hda &&
mount /dev/vdb /hda &&
echo "/dev/vdb    /hda    xfs    defaults    0    0" >> /etc/fstab

mkfs.ext4 -T huge -b 4096 /dev/vdb &&
mkdir /hda &&
mount /dev/vdb /hda &&
echo "/dev/vdb    /hda    ext4    defaults    0    0" >> /etc/fstab

mkfs.ext3 -T largefile -i 4096 /dev/xvdb1 &&
mkdir /hda &&
mount /dev/xvdb1 /hda &&
echo "/dev/xvdb1    /hda    ext3    defaults    0    0" >> /etc/fstab

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18

parted /dev/sda
resizepart 2
pvresize /dev/sda
lvextend -l +100%FREE /dev/mapper/centos-home
xfs_growfs /dev/mapper/centos-home

fdisk /dev/sdb
pvcreate /dev/sdb1
vgextend ubuntu-vg /dev/sdb1
lvextend -L +9G /dev/ubuntu-vg/root

pvs
vgs
lvs

pvdisplay
vgdisplay
lvdisplay

NTFS读写

1
2
3

apt-get install ntfs-3g
mount -t ntfs-3g /dev/hdax /mnt/windows
/dev/hdax /mnt/windows ntfs-3g defaults 0 0

目录操作

迁移目录：

1
2
3
4
5
6
7
8

mkfs.xfs -f /dev/xvdb2 &&
mkdir /vartemp &&
mount /dev/xvdb2 /vartemp &&
rsync -avx /var /vartemp &&
mv /var /var.old &&
mkdir /var &&
umount -lf /dev/xvdb2 /vartemp &&
mount /dev/xvdb2 /var

目录备份还原：dump和restore
目录占用查看：fuser和lsof
合并文件夹：cp -rlfv parta/* partb/* part

配置主机

在~/.ssh/config中增加

1
2
3
4
5
6

Include ~/.ssh/config.d/*
Host aws
    Hostname 10.2.*.*
    Port 22
    User ubuntu
    IdentityFile ~/.ssh/aws.pem

远程执行命令

1

ssh root@59.202.*.* "cd /home/git/.ssh && cat id_rsq.pub >> authorized_keys"

挂载DVD源

1
2
3
4
5

mkdir /iso &&
mount -t iso9660 -o loop /hda/debian7.8/debian-7.8.0-amd64-DVD-1.iso /iso &&
echo deb file:///iso/ wheezy main contrib > /etc/apt/sources.list &&
sudo apt-get update &&
sudo apt-get upgrade

增加用户

1
2
3

useradd oneuser -d /var/oneuser -G wheel &&
usermod -aG root oneuser &&
passwd oneuser

其他安装

1. 配置Python环境 (使用阿里云镜像)

   鉴于UOS自带Python版本可能较低，我们使用 pyenv 安装新版Python。

   # 安装pyenv
   git clone https://gitee.com/mirrors/pyenv.git ~/.pyenv
   echo 'export PYENV_ROOT="$HOME/.pyenv"' >> ~/.zshrc
   echo 'export PATH="$PYENV_ROOT/bin:$PATH"' >> ~/.zshrc
   echo 'eval "$(pyenv init -)"' >> ~/.zshrc
   source ~/.zshrc
   
   # 配置pyenv使用国内镜像加速Python安装
   echo 'export PYTHON_BUILD_MIRROR_URL="https://mirrors.aliyun.com/python/"' >> ~/.zshrc
   source ~/.zshrc
   
   # 通过pyenv安装Python 3.8.12 (此版本与QEMU 7.2.21兼容性好)
   pyenv install 3.8.12
   pyenv global 3.8.12
   

一、使用背景

• 系统：macOS + WSL2
• 核心用途：个人 AI 助手，通过飞书对话
• 主要模型：MiniMax-M2.7（主力）、Qwen3.5-4B-MLX-4bit（本地）

二、配置文件体系

目录结构

所有配置存放在 ~/.hermes/ 目录下：

1
2
3
4
5
6
7
8
9
10

~/.hermes/
├── config.yaml     # 主配置文件（模型、终端、TTS、压缩等）
├── .env             # API Key 和密钥（secrets）
├── auth.json        # OAuth 凭证（Nous Portal 等）
├── SOUL.md          # 主体身份定义（系统提示词 slot #1）
├── memories/        # 持久化记忆（MEMORY.md、USER.md）
├── skills/          # Agent 创建的技能（通过 skill_manage 管理）
├── cron/             # 定时任务
├── sessions/        # 网关会话
└── logs/             # 日志（errors.log、gateway.log — 敏感信息自动脱敏）

三个核心配置文件

配置优先级（从上到下，高优先级覆盖低优先级）

1. CLI 参数 — 例如 hermes chat --model anthropic/claude-sonnet-4（每次调用时覆盖）
2. config.yaml — 所有非密钥配置的主文件
3. .env — 环境变量后备；密钥（API Key、Token、密码）必须放这里
4. 内置默认值 — 以上均未设置时的安全默认值

经验总结

• 标准规则：密钥（API Key、Bot Token、密码）放 .env；其他配置（模型、终端后端、压缩设置、工具集）放 config.yaml
• 标准 api_key 类型 provider（如 minimax-cn、omlx）不走 credential_pool，直接读 .env
• API Key 应只保存在 .env，避免冗余存储
• 配置修改流程：改 config.yaml → hermes doctor --fix → 重启网关

hermes config 命令行

1
2
3
4
5

hermes config                  # 查看当前配置
hermes config edit             # 在编辑器中打开 config.yaml
hermes config set KEY VAL      # 设置指定值（API Key 自动写入 .env，其他写入 config.yaml）
hermes config check            # 检查缺失项（升级后使用）
hermes config migrate          # 交互式添加缺失配置项

技巧：hermes config set 会自动判断写入目标 — API Key 写入 .env，其他写入 config.yaml。

环境变量引用

config.yaml 中支持 ${VAR_NAME} 语法引用环境变量：

1
2
3
4

auxiliary:
  vision:
    api_key: ${GOOGLE_API_KEY}
    base_url: ${CUSTOM_VISION_URL}

未定义的环境变量保持原样写入（${UNDEFINED_VAR} 不展开）。

三、常见故障与修复

四、日常维护命令

1
2
3
4
5
6
7
8
9
10
11

# 健康检查
hermes doctor

# 自动修复配置
hermes doctor --fix

# 重启网关
hermes gateway restart

# 查看配置
hermes config show

经验总结：

• 修改 config.yaml 后必须先 hermes doctor --fix 再重启
• 重启失败时检查是否有并发进程占用端口
• WSL2 和 macOS 环境下的网关管理命令一致

五、核心功能体系

记忆系统（Memory）

Hermes 有两层持久化记忆：

两个文件均存放在 ~/.hermes/memories/，会话启动时注入系统提示词（冻结快照）。

原理：记忆变更在当前会话不生效（保持 LLM 前缀缓存性能），修改立即持久化到磁盘，下个会话起效。

技能系统（Skills）

技能是按需加载的知识文档，采用渐进式披露节省 token：

1
2
3

Level 0: skills_list() → [{name, description, category}, ...]  (~3k tokens)
Level 1: skill_view(name) → 完整内容 + 元数据
Level 2: skill_view(name, path) → 指定引用文件

技能通过 / 命令直接调用：

1
2
3

/axolotl                    # 加载技能并让 Agent 判断需要什么
/github-pr-workflow         # 直接执行
/plan                       # 加载 plan 技能，检查上下文后写实现计划

技能文件存放在 ~/.hermes/skills/，由 skill_manage 工具管理。

Cron 自动化

定时任务支持：

• 定时触发（0 9 * * *、every 2h 等 cron 表达式）
• 事件触发（webhook）
• 交付目标：飞书、本地文件、或其他平台

六、工具链配置

• TTS/图片/音乐：MiniMax 原生 API（MINIMAX_CN_API_KEY），不依赖 Hermes 内置 fal.ai 的 image_gen
• 本地模型：OMLX（Ollama-MLX），通过 http://127.0.0.1:8000/v1 接入
• Smart Routing：smart_model_routing.enabled: true 开启后，简单任务自动路由到本地免费模型
• browser 工具：设置 cloud_provider: '' 使用本地 agent-browser 模式

七、安全与清理

7.1 安全配置审计

在日常维护中，定期运行安全审计能发现潜在风险。以下是我实际排查发现的问题：

高风险项

中风险项

低风险项

7.2 凭证管理

核心原则：API Key 只保存在 .env，不冗余存储。

实际排查发现 auth.json 中存在 request_count: 0 的凭证，说明从未被使用过。Hermes 运行时实际读取的是 .env 中的环境变量（通过 api_key_env 引用），auth.json 仅作为凭证池缓存层。

维护建议：

• 定期检查 auth.json 中各 provider 的 request_count，及时清理从未使用的凭证
• 保留 copilot（GitHub Copilot）等实际使用的凭证
• 删除冗余凭证：minimax-cn、omlx 等（若实际走 .env）

7.3 Skills 精简

Skills 目录容易积累大量从未使用的技能，定期精简可减少维护负担。

精简标准（个人经验）：

• 优先保留正在使用的 skill（如 github-pr-workflow、hexo-blog-post）
• 删除空目录（仅含 DESCRIPTION.md 无实际内容）
• 删除与当前配置不符的 skill（如无 Modal GPU 需求则删 modal-serverless-gpu）
• 保留视频/音频相关 skill（若业务需要）

实际清理结果：

1
2
3

删除空目录：diagramming/、domain/、email/、feeds/、gaming/、gifs/、inference-sh/、smart-home/、social-media/、note-taking/
删除冗余 skill：modal-serverless-gpu、obliteratus、popular-web-designs
Skills 总数：114 → 约 105 个

7.4 配置精简

config.yaml 也会积累无效配置项，定期清理效果显著。

实际清理数据：

• 初始行数：420 行
• 清理后：约 391 行（减少约 30 行）

删除项：

• 空平台工具集引用：telegram、discord、whatsapp、slack、signal、homeassistant
• 空配置对象：honcho: {}、quick_commands: {}、personalities: {}
• 重复的 delegation 块（patch 错误引入）

7.5 验证流程

清理完成后，按以下顺序验证：

1
2
3
4
5
6
7
8
9
10
11

# 1. 检查配置语法
hermes doctor --fix

# 2. 确认配置生效
hermes config show

# 3. 重启网关
hermes gateway restart

# 4. 验证核心功能
hermes doctor

注意：修改 config.yaml 后必须先运行 hermes doctor --fix 自动修复错误配置，最后再重启网关。

八、推荐的工作流

1. 配置修改前先备份：cp config.yaml config.yaml.backup_日期
2. 用 hermes doctor 验证修改结果
3. 用 hermes config show 确认配置生效
4. 最后 hermes gateway restart
5. 重要决策（如删除 provider、修改认证逻辑）记录到记忆文件

九、使用技巧

来自官方文档的实践建议：

• 明确表达需求：给出具体上下文（文件路径、错误信息、期望行为），减少来回次数
• 前置上下文：一次性提供所有相关信息，胜过多次补充
• 用 Context Files：重复出现的指令（如”use tabs not spaces”）写入 AGENTS.md，Agent 自动读取
• 交给 Agent 探索：说”修复失败的测试”而非”打开 tests/test_foo.py 第 42 行然后…”
• 优先用 Skill：复杂流程先查 /skills，再决定是否自己写提示词
• Cron 自动化重复任务：新闻简报、定时提醒、数据采集等场景优先考虑

前言

接触大模型、多模态AI、向量知识库时，很多人都会被基础概念绕晕：

• Tokenizer到底是什么？
• Token和向量有什么本质区别？
• 图片、音频有没有Tokenizer？
• 不同模型的Token和向量能不能通用？
• 固定维度的向量，为何能装下无穷多知识？

今天用大白话+生活化例子，把底层逻辑一次性讲透，零基础也能轻松看懂。

一、什么是 Tokenizer 和 Token

大模型看不懂汉字、英文、图片、音频，它只认数字。

Tokenizer（分词器）只服务于文本。 作用很简单：

把人类的一句话，拆成最小语义碎片，再给每个碎片分配一个唯一数字ID。

被拆分出来的最小语义碎片，就叫 Token。

举个实际例子：

原句：人工智能改变了生活

Tokenizer拆分后：

1

人工 | 智能 | 改变 | 了 | 生活

再查表编码，变成一串数字：

1

[1024, 1056, 2089, 35, 4120]

几个必备常识

• Token不只是单个汉字，可以是词组、词根、标点、英文片段
• 大模型计费、4K/8K上下文窗口、长度限制，全都按Token算，不是按汉字
• 简易换算参考：1个汉字 ≈ 1.3～1.5 个Token

二、图像、音频也有Token，为什么没有Tokenizer？

大家会疑惑：

多模态大模型里，图片、音频也按Token计费、算上下文，
为什么没有文本这种Tokenizer？

核心真相：两个Token，名字一样，本质完全不同。

多模态Token是这样生成的：

• 图像：大图切成小图块 → 编码器提取特征 → 离散量化成抽象数字编号
• 音频：波形转频谱 → 分帧编码 → 压缩成离散Token

之所以统一叫Token，只是为了适配Transformer架构，统一输入格式、统一计费、统一上下文统计，和文本Tokenizer根本不是一套逻辑。

专业纠正：网上常见说法”把海量影像、图片、文本一起做Tokenizer”，是外行错误表述。Tokenizer只适用于文本；图片、影像、音频不存在传统Tokenizer，正确做法是多模态向量化。

三、Token 与 向量（Embedding）的本质区别

一句话彻底分清：

• Token 是文字的数字编号
• 向量（Embedding） 是内容的语义特征画像

什么是Token

只是一个单纯的整数ID，好比身份证号。只做唯一标识，本身没有任何语义。

比如”猫”编号5201，”狗”编号6892，单看数字，完全看不出它们都属于动物。

什么是向量（Embedding）

是几百至上千维的浮点数数组，好比一个人的性格、爱好、职业档案。

语义越相近的内容，在高维空间里距离越近。
“猫”和”狗”的向量距离，远小于”猫”和”桌子”。

完整流转链路

1
2
3
4
5
6

人类文字
  → Tokenizer
  → Token数字ID
  → 模型嵌入层
  → 高维语义向量
  → 大模型运算推理

实用场景区分

四、不同大模型的Token和向量，能否通用？

结论：完全不通用，互不兼容。

Token编号不统一

每个大模型都有独立专属词表，词表大小、分词规则、子词收录全都不一样。

同样四个字”人工智能”：

• 有的模型拆成4个单字Token
• 有的拆成「人工、智能」2个词组Token

对应的数字ID完全不同。

向量绝不互通

就算巧合下，同一个Token在两个模型编号相同，对应的高维向量数值也完全不一样。每个模型的语义空间都是独立训练的，A模型建好的向量库，直接给B模型完全用不了。

实战铁律：搭建海量图文知识库、RAG系统，一旦选定某个Embedding模型，就不要随意更换，换模型等同于向量库全部作废。

五、同一大模型，向量维度是固定的吗？

同一款大模型，向量维度永久固定。

无论输入：

• 一个字
• 一句话
• 一篇长文
• 一张图片
• 一段音频

最终输出的语义向量，维度完全统一。模型训练完成后，向量维度就被结构写死，不会随意变动。

行业常见维度： 768维、1024维、4096维、8192维。

规律很简单：模型规模越大，向量维度越高，语义区分能力越精细。

六、终极疑问：参数有限、维度固定，为何能表达无穷知识？

很多人都有这个困惑：大模型只有几十亿、几百亿参数，向量维度又是固定的，为什么能承载远超参数数量的文字、图片和海量知识？

底层核心逻辑：高维向量靠组合爆炸表达语义，不是一一对应存储。

• 向量每一维都是连续浮点数，取值近乎无限
• 语义由所有维度联合组合表达，不是一个维度对应一种含义
• 固定维度的高维空间，能表达的独立语义是天文数字，远超模型总参数量

通俗比喻：

• 模型参数，只是搭建高维空间的框架骨架，数量有限
• 高维向量，是空间里的无数特征坐标

依靠维度组合变化，就能容纳近乎无限的语义与知识，根本不需要给每条知识，单独占用一个参数。

七、全文核心总结

1. Tokenizer仅适用于文本，图片、音频没有传统Tokenizer
2. Token是无语义的编号，向量是承载语义的高维特征
3. 不同大模型的Token编号、向量语义空间，完全不互通
4. 同一模型所有内容向量维度固定，模型越大维度通常越高
5. 有限参数搭建高维空间，靠组合爆炸承载无穷语义
6. 海量图文影像资料治理，不用做Tokenizer，正确方案是多模态向量化

1. 引言：OpenClaw 的“吞金”之痛

OpenClaw 无疑是当前最强大的 AI Agent 框架之一，它让开发者能够构建出真正自主的智能体。然而，几乎所有深度用户都面临两个核心痛点 ：

• 失忆：长对话中，关键信息被内置的压缩机制随机丢弃，任务执行到一半就偏离目标，Agent 的行为发生退化。
• 吞金：默认的滑动窗口压缩机制虽然试图控制上下文长度，但往往导致上下文冗余，Token 消耗剧增。

更糟糕的是，这两个问题会形成恶性循环：脏上下文导致高 Token 消耗，为了省钱被迫降低模型规格，结果 Agent 表现更差，用户体验直线下滑。

转折点出现在 2026.3.7 版本——OpenClaw 引入了上下文引擎的插件架构，为社区贡献者打开了优化的大门。而 2026.3.13 紧急修复版本进一步修复了压缩一致性、记忆文件重复注入等关键问题 。

本文基于 OpenClaw 2026.3.13 最新版本，从配置调优、记忆系统、上下文管理三个层面，提供一套完整的、可落地的降本增效方案。

2. 原因剖析：Token 都花在了哪里？

在动手优化之前，先要理解钱到底花在了哪儿。每次你与 OpenClaw 对话，发送给模型的远不止你的问题，而是一个完整的工作包：

Token 消耗的底层逻辑可以用一个公式来概括 ：
Token 消耗 = (输入 + 输出) × 调用次数 × 模型价格
其中输入才是真正的大头。OpenClaw 的设计哲学是从无状态到有状态的转变，为了让 Agent 记住一切，框架每次都会默认将完整对话历史发送出去。一次请求的输入可能就有 2-3 万 tokens，聊了 10 轮就是 20-30 万 。

好消息是：2026.3.13 版本修复了多个与 Token 消耗相关的核心问题 ：

• 压缩后的会话 token 计数不准确 → 已修复
• 大小写不敏感挂载上记忆文件被注入两次 → 已修复
• 会话重置提示触发 Azure 内容过滤器 → 已优化

3. 架构级优化：引入分层路由思路

3.1 传统方案的局限

将不同职能拆分到独立 Agent（多智能体架构）虽然能实现上下文隔离，但系统复杂度急剧增加，且主控 Agent 的意图识别本身也在消耗 Token。

3.2 分层路由的核心思想

Viking 分层路由系统的思路值得借鉴：在调用昂贵的主模型之前，先用一个极轻量的模型做意图识别，判断用户到底想干什么，然后只加载与之相关的工具、技能和上下文片段。

如何借鉴：即使不 fork 项目，你也可以手动精简 AGENTS.md 等引导文件，移除对终端用户无用的开发规范、不常用技能的详细说明，从源头减少基础提示词的长度。

⚠️ 注意：Viking 分层路由系统的官方版本不能通过安装插件的方式实现，需要安装社区版 openclaw-viking：

1	openclaw plugins install @viking-engineering/openclaw-viking

4. 配置级优化

4.1 利用新版压缩修复

2026.3.13 修复了压缩后会话 token 计数不准的问题，当前版本支持的压缩配置项包括：

1
2
3
4
5
6
7
8
9
10
11
12
13

{
  "agents": {
    "defaults": {
      "compaction": {
        "mode": "safeguard",           // 使用 safeguard 模式保护最近上下文
        "postIndexSync": "async",      // 压缩后异步同步会话记忆
        "reserveTokens": 8000,         // 为回复生成保留 token 空间
        "keepRecentTokens": 15000,     // 保护最近 15000 tokens
        "maxHistoryShare": 0.6         // 历史最多占 60% 上下文
      }
    }
  }
}

4.2 开启会话剪枝

自动移除旧的对话内容，保持上下文在合理范围内 ：

1
2
3
4
5
6
7

{
  "contextTokens": 200000,
  "contextPruning": {
    "mode": "cache-ttl",
    "ttl": "55m"      // 保留 55 分钟内的对话
  }
}

4.3 降低无效心跳

心跳（Heartbeat）是 OpenClaw 的定时唤醒机制，用于检查任务、发送提醒。但如果不加控制，它会成为隐形的 Token 杀手 ：

算笔账：心跳频率 30 分钟/次，每月心跳次数 1,440 次，每次输入 3,000 Token，每月仅心跳就消耗 432 万 Token！

优化建议：

• 设置工作时间间隔为 45-60 分钟
• 深夜 23:00-08:00 设为静默期
• 精简 HEARTBEAT.md 到最少行数

4.4 关闭非必要附加功能

以下配置项对 Token 消耗的影响程度 ：

建议根据场景选择性关闭，尤其是 ENABLE_FOLLOW_UP_GENERATION。

5. 记忆系统优化：从默认 Memory Search 切换到 QMD

5.1 默认 Memory Search 的问题

OpenClaw 默认的记忆搜索存在几个关键缺陷 ：

• 使用 SQLite 做向量存储，性能不佳
• 单一向量搜索，结果不够精准
• 容易把整个记忆文件塞进上下文，导致 Token 爆炸

5.2 QMD 简介

QMD（Queryable Markdown Database） 是 Shopify 创始人 Tobi 开发的一个本地语义搜索引擎，专为 AI Agent 量身定制 。

它的核心逻辑是：不再读全库，只读最相关的那几段。

技术原理 ：

• 基于 TypeScript + Bun 开发
• 三层混合检索：BM25 全文搜索 + 向量语义搜索 + LLM 重排序
• 所有模型在本地运行，完全离线

实际效果 ：

• 📊 Token 削减：60-97%（平均 95% 以上）
• ⚡ 响应速度提升：5-50 倍
• 🎯 精准度：93%（纯语义搜索仅 59%）

5.3 QMD 与默认 Memory Search 的关系

QMD 是替代关系，配置后 QMD 完全接管记忆检索职责，但依然兼容原有记忆文件 。

5.4 QMD 详细配置指南

前置条件

• OpenClaw 版本 ≥ 2026.2.2
• SQLite ≥ 3.40.0

安装 QMD CLI

1
2
3
4
5

# 使用 Bun 安装（推荐）
bun install -g @tobilu/qmd

# 或使用 npm 安装
npm install -g @tobilu/qmd

修改 OpenClaw 配置文件

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34

{
  "memory": {
    "backend": "qmd",           // 切换到 QMD 后端
    "citations": "auto",
    "qmd": {
      "includeDefaultMemory": true,  // 包含原有的 MEMORY.md
      "update": {
        "interval": "5m",
        "debounceMs": 15000,
        "onBoot": true
      },
      "limits": {
        "maxResults": 7,           // 最多注入几段
        "maxSnippetChars": 700,     // 每段长度限制
        "timeoutMs": 4000
      },
      "scope": {
        "default": "allow"          // Windows 用户必需
      },
      "paths": [
        {
          "name": "memory",
          "path": "~/.openclaw/workspace/memory/",
          "pattern": "**/*.md"
        },
        {
          "name": "notes",
          "path": "~/obsidian/",     // 可添加外部笔记库
          "pattern": "**/*.md"
        }
      ]
    }
  }
}

Windows 特别注意事项 ：

• command: "qmd.exe" 可能需要显式指定
• scope.default: "allow" 必不可少，避免权限拒绝

初始化索引

1
2

cd ~/.openclaw/workspace
qmd update --dir .

验证效果

1

openclaw memory search "你的搜索词"

观察日志确认 Using QMD memory backend。

6. 上下文管理革命：lossless-claw 插件深度解析

6.1 lossless-claw 原理与优势

为什么需要 lossless-claw

OpenClaw 内置的上下文压缩机制存在一个根本性缺陷：它是有损的（lossy） 。具体来说，内置压缩会：

• 把数十轮对话一股脑压成一段几百 Token 的摘要
• 不保留原始消息——压缩后细节永远丢失
• 导致 Agent 行为退化：跳过验证步骤、忽略安全规则

当 LCM 论文的作者告知 OpenClaw 维护者 Josh Lehman 他们的工作时，Josh 立刻意识到这会是 OpenClaw 的一个极棒的补充。他花了 9 天时间疯狂开发，在自己的 Agent 上运行了一周，结果令人印象深刻：”对话感觉永远不会丢失信息（因为某种程度上确实不会），始终在 30-100K Token 范围内运行，零维护” 。

LCM 核心原理：DAG 层次化摘要

Lossless Context Management (LCM) 插件用 DAG（有向无环图）结构的摘要系统替代滑动窗口压缩 ：

graph TD
    A[Immutable Store<br>所有原始消息的逐字副本]
    subgraph B [DAG摘要层]
      direction LR
      B1["Depth 0:<br> [摘要A] ← 消息1-8  <br>[摘要B] ← 消息9-16"]
      B2["Depth 1:<br> [浓缩X] ← 摘要A+摘要B"]
      B3["每个摘要都链接回源消息 ← '无损'"]
    end
    B["DAG摘要层<br>Depth 0:<br> [摘要A] ← 消息1-8  <br>[摘要B] ← 消息9-16<br>Depth 1:<br> [浓缩X] ← 摘要A+摘要B<br>每个摘要都链接回源消息 ← '无损'"]
    subgraph C [模型接收内容（Context）]
      direction TB
      C1[系统提示词]
      C2[DAG摘要]
      C3[最近N条原始消息]
    end
    A --> B --> C
    B1 --> B2 --> B3

关键创新 ：

• 全量持久化：所有消息存入 SQLite，无信息丢失
• 分层摘要：超出最新 N 条消息后异步生成摘要，同层摘要积累后向上凝练o
• 动态上下文组装：每轮自动拼接”最新原始消息 + 历史层级摘要”
• 按需回溯：提供 lcm_grep、lcm_describe、lcm_expand 工具，随时调取原始内容

性能实测：OOLONG 基准测试

OOLONG 是什么：长上下文推理基准测试，测的是模型能否理解和推理整段长文本的全局信息 。

测试结果（使用相同模型）：

• lossless-claw：得分 74.8
• Claude Code：得分 70.3

关键发现：上下文越长，差距越大——在所有测试的上下文长度上，lossless-claw 的得分都高于 Claude Code。

Token 消耗：实测降低 30% 以上，额外消耗的 Token 主要是摘要计算，不会大幅增加总消耗 。

6.2 lossless-claw 配置指南

前置条件

• OpenClaw 版本 ≥ 2026.3.7（推荐 2026.3.13）
• SQLite（OpenClaw 默认预装）
• Node.js ≥ v22

安装步骤（推荐方式）

使用 OpenClaw 的插件安装命令（会自动配置）：

1
2
3
4
5
6

# 1. 确保 OpenClaw 已更新到最新版
npm install -g openclaw@latest
openclaw --version  # 应显示 2026.3.13

# 2. 使用插件安装命令（推荐）
openclaw plugins install @martian-engineering/lossless-claw

安装命令会自动完成：

• 下载并安装插件到 ~/.openclaw/extensions/lossless-claw
• 在 plugins.entries 中添加配置
• 在 plugins.slots.contextEngine 中注册上下文引擎

手动配置（如需自定义）

如果需要手动配置，确保在 plugins 下正确设置：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22

{
  "plugins": {
    "allow": [
      "openclaw-qqbot",
      "openclaw-lark",
      "lossless-claw"
    ],
    "entries": {
      "lossless-claw": {
        "enabled": true,
        "config": {
          "freshTailCount": 16,
          "contextThreshold": 0.8,
          "summaryModel": "astroncodingplan/astron-code-latest"
        }
      }
    },
    "slots": {
      "contextEngine": "lossless-claw"
    }
  }
}

配置说明：

⚠️ 注意：contextEngine 应配置在 plugins.slots 下，而非 agents.defaults.contextEngine。

验证安装

安装后重启网关，查看日志确认插件加载：

1
2

openclaw gateway restart
openclaw logs --follow | grep -i lcm

正常输出应类似：

1
2

[plugins] [lcm] Plugin loaded (enabled=true, db=/Users/sean/.openclaw/lcm.db, threshold=0.8)
[plugins] [lcm] Compaction summarization model: astroncodingplan/astron-code-latest (override)

注意事项

• 现有会话不能直接切换：需要 /reset 重置或 /new 开新会话才能使用 lossless-claw
• 磁盘存储增长：长期使用会导致磁盘存储占用增长，建议定期清理旧会话
• 重启网关：修改配置后务必重启服务 openclaw gateway restart

7. 综合实践：一次完整的优化旅程

假设你有一个运行了一段时间的 OpenClaw 实例，以下是建议的优化步骤：

7.1 升级到最新版本

1
2

npm install -g openclaw@latest
openclaw --version  # 确认显示 2026.3.13

7.2 开启配置级优化

以下配置经实际测试验证可正常工作（2026.3.13 版本）：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41

{
  "agents": {
    "defaults": {
      "compaction": {
        "mode": "safeguard",
        "postIndexSync": "async",
        "reserveTokens": 8000,
        "keepRecentTokens": 15000,
        "maxHistoryShare": 0.6
      },
      "contextPruning": {
        "mode": "cache-ttl",
        "ttl": "55m"
      },
      "heartbeat": {
        "every": "55m",
        "target": "last"
      }
    }
  },
  "memory": {
    "backend": "qmd",
    "citations": "auto",
    "qmd": {
      "includeDefaultMemory": true,
      "update": {
        "interval": "5m",
        "debounceMs": 15000,
        "onBoot": true
      },
      "limits": {
        "maxResults": 7,
        "maxSnippetChars": 700,
        "timeoutMs": 4000
      },
      "scope": {
        "default": "allow"
      }
    }
  }
}

7.3 安装 lossless-claw 插件

1
2

# 使用插件安装命令（推荐，自动配置）
openclaw plugins install @martian-engineering/lossless-claw

安装后会自动配置 plugins.slots.contextEngine。

7.4 重启网关

1

openclaw gateway restart

7.5 验证效果

1
2
3
4
5

# 查看插件加载日志
openclaw logs --follow | grep -i lcm

# 测试 QMD 记忆搜索
openclaw memory search "测试关键词"

7.6 优化前后对比

建议用实际监控数据展示效果。根据社区反馈，这套组合拳通常可以实现：

• Token 消耗降低 30-60%
• 响应速度提升 5-10 倍
• 记忆精准度大幅提升

8. 避坑指南与注意事项

1. 现有会话不能直接切换到 lossless-claw，需要 /reset 或 /new
2. 不要同时运行用户级和系统级 OpenClaw 服务，会导致冲突
3. 修改配置后务必重启服务：openclaw gateway restart
4. QMD 首次索引可能需要时间，耐心等待完成
5. 定期检查磁盘空间，防止旧会话占用过多存储
6. 注意版本号差异：Git Tag 是 v2026.3.13-1，但 npm 版本是 2026.3.13，升级时无需纠结
7. Windows 用户特别注意 QMD 的 scope 配置

9. 总结与展望

本文基于 OpenClaw 2026.3.13 版本，从三个层面提供了完整的降本增效方案：

这三者并不互斥，而是可以协同工作：QMD 负责外部知识的精准检索，lossless-claw 负责对话历史的高效管理，配置优化则贯穿始终。

核心指导思想：按需加载、本地优先。让昂贵的云端模型只处理真正需要它的事情，其他工作尽可能交给本地计算。

展望未来，OpenClaw 社区仍在快速进化。2026.3.13 版本带来的浏览器控制、安全加固、Slack 深度集成等更新 ，为 AI 智能体打开了更广阔的应用空间。期待更多优秀的插件和方案涌现，让 OpenClaw 既强大又亲民。

附录：常用命令速查表

本文基于 OpenClaw 2026.3.13 版本编写，配置路径和参数可能随版本更新而变化，请以官方文档为准。

1

wget -qO- https://haies.cn/assets/checkname.js

使用说明

checkname 是一个基于 Node.js 的命令行工具，用于检查和自动修复文件及目录名称，确保它们能够同时在 Windows 11、macOS 和 Ubuntu 系统中正常使用，便于跨平台文件共享。工具会检查文件名是否包含禁止字符、是否超长、是否存在空格等不可见字符，并按照预定策略进行规范化处理，同时自动处理重名冲突。

安装与运行

• 环境要求：Node.js 12.0 或更高版本（建议使用 LTS 版本）。
• 获取脚本：将脚本保存为 checkname.js。
• 运行方式：在终端中执行 node checkname.js [参数] [目录1] [目录2] ...

基本用法

1

node checkname.js [-p] <目录1> [<目录2> ...]

• -p：处理模式。
  • 若指定此参数，脚本会尝试读取目标目录下最新的日志文件，并根据日志记录对不符合规范的文件/目录进行重命名操作。
  • 如果目录下没有日志文件，则先执行完整检查并生成日志，然后立即根据该日志进行处理。
  • 处理完成后，日志文件会被更新，记录每个条目的处理结果（新路径、状态等）。
• 不指定 -p：仅检查模式。脚本遍历目录，找出所有不符合规范的文件和目录，并将记录保存到新生成的日志文件中（不会修改任何文件）。

使用示例

示例 1：仅检查目录 /home/user/share

1

node checkname.js /home/user/share

输出：

1
2
3
4

处理目录: /home/user/share
仅检查模式，不会修改文件
检查完成，发现 3 个不符合规范的条目
日志已保存: /home/user/share/checkname_20250302_143022.jsonl

此时目录下会生成日志文件，记录不合规条目的详细信息。你可以查看日志决定是否进行下一步处理。

示例 2：处理目录（基于已有日志）

1

node checkname.js -p /home/user/share

假设目录下已有日志 checkname_20250302_143022.jsonl：

1
2
3
4
5

处理目录: /home/user/share
使用现有日志: checkname_20250302_143022.jsonl
开始处理 3 个条目...
处理完成，日志已更新: checkname_20250302_143022.jsonl
统计: 已处理 2, 错误 0, 跳过 1

脚本会读取日志，重命名其中两个文件/目录，并更新日志状态。跳过的条目可能是因为原名称已合规（无需修改）。

示例 3：处理多个目录，且目录无现有日志

1

node checkname.js -p /mnt/data /mnt/docs

输出：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15

处理目录: /mnt/data
未找到现有日志，将先执行检查...
检查完成，发现 5 个不符合规范的条目
已生成日志: checkname_20250302_144512.jsonl
开始处理 5 个条目...
处理完成，日志已更新: checkname_20250302_144512.jsonl
统计: 已处理 5, 错误 0, 跳过 0

处理目录: /mnt/docs
未找到现有日志，将先执行检查...
检查完成，发现 2 个不符合规范的条目
已生成日志: checkname_20250302_144513.jsonl
开始处理 2 个条目...
处理完成，日志已更新: checkname_20250302_144513.jsonl
统计: 已处理 2, 错误 0, 跳过 0

示例 4：查看日志内容

1

cat /home/user/share/checkname_20250302_143022.jsonl

输出示例：

1
2

{"type":"file","originalPath":"/home/user/share/a*b?.txt","newPath":null,"issues":["invalid_char"],"status":"pending","timestamp":"2025-03-02T14:30:22.123Z"}
{"type":"dir","originalPath":"/home/user/share/这是一个非常长的目录名称中文英文混合......","newPath":null,"issues":["too_long"],"status":"pending","timestamp":"2025-03-02T14:30:22.456Z"}

处理后的日志会更新 newPath 和 status。

相关说明

1. 规范性规则

• 禁止字符：包含以下任一字符的名称被视为不合规：
  • <>:"/\|?* （Windows 文件系统禁止的字符）
  • ASCII 控制字符（0x00–0x1F）
  • 所有 Unicode 空白字符（包括空格、制表符、换行符等）
• 长度限制：文件名（包括扩展名）的 UTF-8 编码字节数不得超过 255 字节（这是 Linux 的极限值，也是 Windows 和 macOS 的安全上限）。中文字符通常占 3 字节，需要特别注意。
• 忽略条目：脚本会自动跳过以下类型的文件和目录（及其内部所有内容）：
  • 以点（.）开头的隐藏文件/目录
  • 名称为 node_modules、dist、build、bin、debug 的目录（不区分大小写）

2. 处理策略

当发现不合规的名称时，按以下顺序进行修正：

1. 删除非法字符：移除所有禁止字符。
2. 长度缩减：如果删除非法字符后仍超长，则对主名（不含扩展名）依次应用以下规则，直到字节数达标：
   • 删除特殊字符（非字母、数字、下划线 _、连字符 -）。
   • 将连续重复 4 次以上的字符缩减为 4 次（例如 "aaaaa" → "aaaa"）。
   • 从主名末尾逐个删除字符。
3. 重名冲突处理：修正后的名称若与同目录下已有条目重名，则自动添加序号 (1)、(2)…… 直至不冲突。添加序号时会确保总长度不超限，必要时会进一步截断主名。

3. 日志文件

• 命名格式：checkname_YYYYMMDD_HHMMSS.jsonl（例如 checkname_20250302_143022.jsonl），保存在被分析的目录下。

• 格式：JSON Lines，每行一条记录，包含以下字段：

  1 2 3 4 5 6 7 8 9

  { "type": "file|dir", // 条目类型 "originalPath": "/绝对/路径/原名称", // 原始完整路径 "newPath": "/绝对/路径/新名称", // 处理后的路径（仅处理模式有值） "issues": ["invalid_char", "too_long"], // 不合规原因 "status": "pending|processed|error|skipped", // 状态 "error": "错误信息（如果有）", // 处理失败时的错误信息 "timestamp": "2025-03-02T14:30:22.123Z" // 记录生成时间 }

• 作用：日志既是检查结果的记录，也是处理模式的输入。处理模式只会处理 status 为 pending 的条目，并更新其状态为 processed、error 或 skipped。

4. 处理模式详解

• 基于现有日志：若目录下已有日志文件，脚本会自动选择最新的一个，读取其中的记录，然后尝试处理所有状态为 pending 的条目。处理完成后，日志文件会被覆盖更新。
• 无日志时：如果目录下没有日志文件，则先执行完整检查，生成新日志，然后立即根据该日志进行处理。这相当于一次完成“检查+处理”。
• 重复运行：可以多次运行处理模式，每次只会处理尚未处理的条目（pending 状态）。已处理（processed）、出错（error）或跳过（skipped）的记录不会重复操作。

注意事项

• 备份重要数据：处理模式会实际修改文件名，建议首次使用时先运行不带 -p 的检查模式，查看日志确认后再执行处理。
• 权限问题：确保脚本对目标目录有读写权限，否则处理可能失败。
• 跨平台兼容：修正后的文件名仍可能在某些极端情况下不兼容（例如保留字如 CON、PRN 等，Windows 有保留设备名），本工具未处理这些情况，请自行留意。
• 日志累积：多次运行处理模式会不断更新同一个日志文件，如需保留历史记录，请手动备份旧日志。
• 并发安全：脚本为串行处理，不会同时修改多个文件，避免冲突。

wget -qO- https://haies.cn/assets/svn_server_tool.sh

使用说明

在服务器端直接查看和统计 SVN 代码仓库信息，无需通过客户端连接。

功能：

• 目录内容查看：查看 SVN 仓库目录结构，仅显示指定目录的第一层内容（非递归）
• 代码修改历史查询：查看文件或目录的所有修改记录，包括版本号、作者、时间、提交信息
• 代码提交统计分析：统计提交情况，按作者统计提交次数和百分比，显示提交时间范围

基本用法

1

./svn_server_tool.sh <功能> <仓库路径> [目录/文件路径]

• 功能参数（第一个参数）：ls列出目录、log查看历史、stat统计提交
• 仓库路径（第二个参数）：SVN 仓库物理路径，如/var/svn/repos/myproject
• 目标路径（第三个参数）：ls为可选，log和stat为必填（仓库内相对路径）

使用示例

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17

# 查看仓库根目录
./svn_server_tool.sh ls /var/svn/repos/myproject

# 查看指定目录
./svn_server_tool.sh ls /var/svn/repos/myproject /trunk/src

# 查看文件修改历史
./svn_server_tool.sh log /var/svn/repos/myproject /trunk/src/main.java

# 查看目录修改历史
./svn_server_tool.sh log /var/svn/repos/myproject /trunk/src

# 统计文件提交情况
./svn_server_tool.sh stat /var/svn/repos/myproject /trunk/src/main.java

# 统计目录提交情况
./svn_server_tool.sh stat /var/svn/repos/myproject /trunk/src

1

wget -qO- https://haies.cn/assets/tar_batch.sh

使用说明

智能压缩指定目录内文件数量较多的文件夹，自动根据目录深度和文件数量应用不同压缩规则，并排除文档、图片、视频、音频等特定文件类型。

该脚本特别适合处理日志目录、临时文件目录、上传目录等包含大量小文件的场景，能有效减少 inode 使用量，提升文件系统性能。

基本用法

1

./tar_batch.sh [目标目录]

• 目标目录：可选参数，不指定时默认处理脚本所在目录
• 处理深度：3-5 级目录，按从浅到深顺序

使用示例

1
2

./tar_batch.sh                 # 压缩当前目录
./tar_batch.sh /path/to/data   # 压缩指定目录

相关说明

压缩规则

排除的文件类型

• 文档：.txt .pdf .doc .docx .xls .xlsx .ppt .pptx .odt .md .rtf
• 图片：.jpg .jpeg .png .gif .bmp .tiff .svg .webp
• 视频：.mp4 .avi .mov .mkv .flv .wmv .m4v .webm
• 音频：.mp3 .wav .flac .aac .ogg .m4a .wma

输出说明

执行后，符合条件的目录会被压缩，并在同级位置生成：

• 单卷包：目录名.tar.gz
• 多卷包：目录名_archive/ 文件夹（内含分卷文件）

特性说明

• 终端实时显示当前正在压缩的文件名
• 在目标目录生成带时间戳的日志文件

1

wget -qO- https://haies.cn/assets/tar_single.sh

使用说明

大容量单目录分卷压缩、解压工具，支持 gzip、zstd（推荐）、xz 三种压缩算法，提供创建、解压、测试三种操作模式。

核心特性：

• 自动检测压缩格式，解压和测试时无需手动指定算法
• 提供分卷校验和验证，确保数据完整性
• 彩色日志输出，包含时间戳，便于跟踪和审计
• 默认使用并行压缩工具，处理大文件时效率更高

基本用法

1

./tar_single.sh -[操作方式][压缩算法] [操作对象]

• 操作方式：c创建、x解压、t测试
• 压缩算法（仅创建时需要）：z gzip（默认）、s zstd（推荐）、o xz（高压缩比）

使用示例

1
2
3
4
5
6
7
8
9
10

# 创建压缩包
./tar_single.sh -cz /path/to/data        # gzip
./tar_single.sh -cs /path/to/data        # zstd
./tar_single.sh -co /path/to/data        # xz

# 解压压缩包（自动检测格式）
./tar_single.sh -x /path/to/archive_dir

# 测试完整性（自动检测格式）
./tar_single.sh -t /path/to/archive_dir

1

wget -qO- https://haies.cn/assets/deduplicate.sh

使用说明

deduplicate 是一个 Bash 脚本，用于递归分析指定目录下的重复文件和目录（内容完全相同），并根据用户选择执行删除或仅记录日志。

核心规则

• 重复范围：仅在同一父目录下判定重复（文件和目录分开处理）
• 遍历顺序：按目录深度从浅到深处理，先处理子目录重复，再处理文件重复
• 保留策略：对于每个重复组，保留文件名最短且修改时间最早的一项，其余标记为待删除

自动忽略

以下项目不参与分析，也不会出现在日志中：

• 以点（.）开头的文件和目录（隐藏项）
• 名为 node_modules、dist、build、bin、debug 的目录（不区分大小写）

日志文件

在每个待分析目录下生成独立的日志文件，文件名格式为 .deduplicate_YYYYMMDD_HHMMSS.log。

日志仅记录重复项，每行格式为：

1

[时间戳] | 组ID | 绝对路径 | 状态

状态包括 KEEP（保留）、TO_DEL（待删除）、DELETED（已删除）。

删除模式

通过 -d 选项启用。如果指定目录下已有脚本生成的日志，则直接读取日志中状态为 TO_DEL 且仍存在的项目并执行删除，同时将对应日志行状态更新为 DELETED（不新增行）。如果无日志，则正常分析并直接删除重复项，同样只更新原日志行状态。

注意事项

⚠️ 删除不可恢复：脚本使用 rm -rf 直接删除文件和目录，请务必先备份重要数据，并在测试环境中验证脚本行为。

• 权限要求：脚本需要对待分析目录具有读取和执行权限，对需删除项具有写权限
• 性能提示：目录重复检测依赖 diff -rq，对于包含大量文件的目录可能较慢，请耐心等待
• 日志积累：日志文件会永久保留，每次运行会生成新日志。删除模式下，多次运行可复用已有日志，仅更新状态

基本用法

1

deduplicate [-d] dir1 [dir2 ...]

• -d：可选参数，启用删除模式。不加此参数时，仅将重复项记录到日志，不执行任何删除。
• dir1 dir2 ...：必需参数，至少指定一个待分析的目录（绝对路径或相对路径均可）。

脚本会对每个目录独立处理，生成各自的日志文件。

使用示例

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20

# 示例 1：仅分析单个目录（不删除）
./deduplicate /home/user/documents

#分析 `/home/user/documents` 下的重复项，结果记录到 `/home/user/documents/.deduplicate_20260228_093012.log`。屏幕显示扫描进度和发现的重复组。

# 示例 2：分析多个目录
./deduplicate /home/user/docs /home/user/backup

#分别分析两个目录，各自生成日志文件，互不影响。

# 示例 3：分析并删除重复项（无现有日志）
./deduplicate -d /mnt/data/projects

#分析 `/mnt/data/projects`，发现重复组后直接删除待删除项，日志中对应行状态从 `TO_DEL` 变为 `DELETED`。屏幕显示删除进度。

# 示例 4：已有日志情况下再次运行删除模式
#假设之前已运行分析（不带 `-d`），生成了日志文件 `.deduplicate_20260228_093012.log`，其中包含一些 `TO_DEL` 项。现在执行：
./deduplicate -d /mnt/data/projects

#脚本会自动找到该目录下最新的日志，读取其中所有 `TO_DEL` 且仍存在的项目并删除，同时将日志中对应行更新为 `DELETED`。如果日志中已无 `TO_DEL` 项，则输出提示并结束。

查看日志内容

日志文件示例片段：

1
2
3
4

[2026-02-28 09:17:07] | G001 | /mnt/d/tmp/test/xs/凡人修仙传-- 忘语 -- 2017.epub | KEEP
[2026-02-28 09:17:07] | G001 | /mnt/d/tmp/test/xs/凡人修仙传-- 忘语 -- 2017 - 副本.epub | DELETED
[2026-02-28 09:17:07] | G002 | /mnt/d/tmp/test/xs/斗罗大陆 -- 唐家三少.mobi | KEEP
[2026-02-28 09:17:07] | G002 | /mnt/d/tmp/test/xs/斗罗大陆 -- 唐家三少 - 副本.mobi | DELETED

其中 G001、G002 为组ID，每个组内先显示保留项（KEEP），再按文件名升序显示已删除项（DELETED）。

附录：脚本依赖

• Bash 4.0 或更高版本
• 标准命令：find、sort、stat、sed、sha256sum、diff、rm 等
• 确保脚本具有可执行权限：chmod +x deduplicate

如有任何问题或建议，请根据实际情况调整脚本或联系脚本维护者。

大型语言模型（LLM）是一个基于深度神经网络（DNN）的复杂系统。
其核心是通过海量数据训练，将文本转化为高维向量，并基于统计学
规律预测下一个词的概率分布，再通过反向传播（Backpropagation）
算法动态调整数以亿计的参数（Parameters），从而让向量编码的语义
知识（Semantic Knowledge）不断优化。

整个过程可类比于培养一位”学者”：

• 参数规模（Model Scale）：其神经基础
• Transformer架构及其自注意力机制：其核心思维方式
• 训练数据：其学习的”书籍”
• 计算量：其投入的”资源”
• 涌现能力（Emergent Abilities）：量变引发的质变与创造性”顿悟”
• 指令微调与人类对齐：社会化的沟通与伦理教育
• 多模态能力（Multimodal Capabilities）：扩展感知与交互的维度
• 推理效率（Inference Efficiency）：决定实际场景中的响应速度和实用性

这些特征相互关联，共同定义了大模型的综合能力（Capabilities）与
实用价值。

一、核心概念：理解AI如何”思考”与”生成”

🌐 基石认知

• Transformer架构：现代大模型核心，通过”注意力机制”动态聚焦
  关键词（如读句时识别主谓宾），实现高效语义建模。

• 向量与维度：文字→高维数字向量（如”猫”=[0.2, -1.7, 3.1…]）；
  维度=特征数量（768维=768个语义特征），维度越高表达越精细。

• 参数≠维度：参数是模型内部可学习的权重（如Qwen-Max约100亿参数），
  训练即优化参数以压缩语言规律；向量是输入经参数计算后的实时
  语义表示。

• 训练实质：将海量文本中的模式”编码”进参数，使模型能将新输入
  映射为有意义的向量分布。

• 生成公式：

  输出内容 = 模型(参数) + Context(对话历史/文档) + Prompt(当前指令)

  ✅ 黄金法则：Prompt清晰具体 + Context提供必要背景
  （例：”基于上文需求，用Python写…”）

🔁 关键延伸

• 强化学习（RLHF）：通过人类偏好反馈微调模型，使输出更安全、
  有用（Claude/GPT系列核心优化手段）。
• RAG（检索增强生成）：先从向量库检索相关知识（如企业文档），
  再交由LLM生成答案——解决模型”不知道私有/最新信息”的核心方案。

二、技术框架：构建AI应用的”骨架”

💡 实施路径：LangChain + pgvector 搭建简易RAG（GitHub模板丰富）

三、工具生态：分类与安全实践

📦 本地模型工具

🤝 AI协作工具

🤖 智能体平台

💻 开发环境工具

四、主流模型

✅ 选择策略：

• 国内用户：GLM、Qwen、DeepSeek（访问快、中文强）
• 国际场景：Claude 3.5 Sonnet（当前综合能力标杆）
• 本地部署：Qwen/Mistral开源系列 + Ollama（注意安全加固！）

五、Claude能力体系：从代码到全场景协作

🔑 核心能力组件（Claude.ai平台）

1. 三种模式

   • 📝 聊天模式：日常问答
   • 💻 代码模式：专注代码生成/调试（自动识别代码块）
   • 🤖 Projects模式：管理长上下文项目（上传整个文件夹，跨文件理解）

2. 上下文管理

   • 支持200K+ tokens上下文，可上传PDF/代码库/设计稿
   • Projects中文件自动关联，提问时智能引用相关代码

3. 代码生成

   • ✨ Prompt：添加需求，制定PLAN
   • 🎨 上传设计图：上传设计图，明确界面
   • 🧠 Skills触发：固定开发要求
   • 💻 hook调用：格式化代码