Echo Blog

Voicebox 开源语音合成工作室

Wed, 15 Apr 2026 13:01:55 +0000

Voicebox

什么是 Voicebox？

Voicebox 是一个 本地优先的声音克隆工作室 —— 免费开源的 ElevenLabs 替代品。只需几秒钟的音频即可克隆声音，在 5 种 TTS 引擎上生成 23 种语言的语音，应用后期处理效果，并通过时间轴编辑器创作多声部项目。

完全隐私 —— 模型和声音数据保留在您的机器上
5 种 TTS 引擎 —— Qwen3-TTS、LuxTTS、Chatterbox Multilingual、Chatterbox Turbo 和 HumeAI TADA
23 种语言 —— 从英语到阿拉伯语、日语、印地语、斯瓦希里语等
后期处理效果 —— 变调、混响、延迟、合唱、压缩和滤波器
富有表现力的语音 —— 通过 Chatterbox Turbo 支持 [笑]、[叹息]、[倒吸一口气] 等副语言标签
不限长度 —— 自动分块 + 交叉淡变，适用于脚本、文章和章节
故事编辑器 —— 多轨时间轴，用于对话、播客和叙事
API 优先 —— 提供 REST API，可将语音合成集成到您自己的项目中
原生性能 —— 基于 Tauri（Rust）构建，而非 Electron
全平台运行 —— macOS（MLX/Metal）、Windows（CUDA）、Linux、AMD ROCm、Intel Arc、Docker

下载

平台	下载
macOS（Apple Silicon）	下载 DMG
macOS（Intel）	下载 DMG
Windows	下载 MSI
Docker	`docker compose up`

查看所有二进制文件 →

Linux —— 暂未提供预编译二进制文件。请访问 voicebox.sh/linux-install 查看从源码构建的说明。

功能

多引擎声音克隆

五种 TTS 引擎，各有优势，可按次切换：

引擎	语言	优势
Qwen3-TTS（0.6B / 1.7B）	10	高质量多语言克隆，支持交付指令（如“说慢点”、“低语”）
LuxTTS	英语	轻量（约 1GB 显存），48kHz 输出，CPU 上 150 倍实时
Chatterbox Multilingual	23	最广泛的语言覆盖 —— 阿拉伯语、丹麦语、芬兰语、希腊语、希伯来语、印地语、马来语、挪威语、波兰语、斯瓦希里语、瑞典语、土耳其语等
Chatterbox Turbo	英语	快速 3.5 亿参数模型，支持副语言情感/声音标签
TADA（1B / 3B）	10	HumeAI 语音语言模型 —— 700 秒以上连贯音频，文本-声学双重对齐

情感与副语言标签

在文本输入框中键入 / 可插入表达性标签，模型会将这些标签在语音中合成出来（Chatterbox Turbo）：

[笑] [轻笑] [倒吸一口气] [咳嗽] [叹息] [呻吟] [抽鼻子] [嘘声] [清嗓子]

后期处理效果

由 Spotify 的 pedalboard 库支持的 8 种音频效果。生成后应用，实时预览，可构建可复用的预设。

效果	描述
变调	向上或向下最多 12 个半音
混响	可配置的房间大小、阻尼、干/湿比
延迟	可调时间、反馈和混合比例的回声
合唱 / 镶边	调制延迟，产生金属感或丰满的质感
压缩器	动态范围压缩
增益	音量调节（-40 至 +40 dB）
高通滤波器	去除低频
低通滤波器	去除高频

内置 4 种预设（机器人、电台、回声室、低沉嗓音），并支持自定义预设。效果可设为每个配置文件的默认值。

不限长度的生成

文本会在句子边界处自动分割，每个块独立生成，然后交叉淡变合并。所有引擎均适用。

可配置的自动分块限制（100–5,000 字符）
交叉淡变滑块（0–200ms），实现平滑过渡
最大文本长度：50,000 字符
智能分割，尊重缩写、CJK 标点和 [标签]

生成版本

每次生成支持多个版本，并记录来源：

原始 —— 干净的 TTS 输出，始终保留
效果版本 —— 基于任意源版本应用不同效果链
录制（Takes） —— 使用新的随机种子重新生成，获得变化
来源追踪 —— 每个版本记录其派生路径
收藏 —— 给生成结果加星，便于快速访问

异步生成队列

生成不阻塞。提交后可以立即开始输入下一条。

串行执行队列，避免 GPU 争用
实时 SSE 状态推送
失败的生成可以重试
因崩溃导致的陈旧生成在启动时自动恢复

声音配置文件管理

从音频文件创建配置文件，或直接在应用内录制
导入/导出配置文件，便于共享或备份
支持多样本，提高克隆质量
每个配置文件的默认效果链
使用描述和语言标签进行分类整理

故事编辑器

多声部时间轴编辑器，用于对话、播客和叙事。

多轨编排，支持拖放
内联音频裁剪和拆分
自动播放，播放头同步
每个轨道片段可固定版本

录制与转录

应用内录制，带波形可视化
系统音频捕获（macOS 和 Windows）
由 Whisper（包括 Whisper Turbo）驱动的自动转录
导出多种格式的录音

模型管理

支持卸载单个模型以释放 GPU 内存，无需删除下载
通过 VOICEBOX_MODELS_DIR 自定义模型目录
模型文件夹迁移，带进度跟踪
下载取消/清除界面

GPU 支持

平台	后端	说明
macOS（Apple Silicon）	MLX（Metal）	通过神经网络引擎加速 4-5 倍
Windows / Linux（NVIDIA）	PyTorch（CUDA）	应用内自动下载 CUDA 二进制文件
Linux（AMD）	PyTorch（ROCm）	自动配置 `HSA_OVERRIDE_GFX_VERSION`
Windows（任意 GPU）	DirectML	通用的 Windows GPU 支持
Intel Arc	IPEX/XPU	Intel 独立显卡加速
任意平台	CPU	随处可用，速度较慢

API

Voicebox 提供完整的 REST API，可将语音合成集成到您自己的应用中。

# 生成语音
curl -X POST http://localhost:17493/generate \
  -H "Content-Type: application/json" \
  -d '{"text": "你好，世界", "profile_id": "abc123", "language": "zh"}'

# 列出声音配置文件
curl http://localhost:17493/profiles

# 创建配置文件
curl -X POST http://localhost:17493/profiles \
  -H "Content-Type: application/json" \
  -d '{"name": "我的声音", "language": "zh"}'

应用场景： 游戏对话、播客制作、无障碍工具、语音助手、内容自动化。

完整 API 文档请访问 http://localhost:17493/docs。

技术栈

层级	技术栈
桌面应用	Tauri（Rust）
前端	React、TypeScript、Tailwind CSS
状态管理	Zustand、React Query
后端	FastAPI（Python）
TTS 引擎	Qwen3-TTS、LuxTTS、Chatterbox、Chatterbox Turbo、TADA
效果	Pedalboard（Spotify）
转录	Whisper / Whisper Turbo（PyTorch 或 MLX）
推理	MLX（Apple Silicon）/ PyTorch（CUDA/ROCm/XPU/CPU）
数据库	SQLite
音频	WaveSurfer.js、librosa

路线图

特性	描述
实时流式传输	逐词生成并流式传输音频
声音设计	通过文本描述创建新的声音
更多模型	XTTS、Bark 及其他开源声音模型
插件架构	通过自定义模型和效果进行扩展
移动伴侣应用	从手机控制 Voicebox

开发

详细设置和贡献指南请参见 CONTRIBUTING.md。

快速开始

git clone https://github.com/jamiepine/voicebox.git
cd voicebox

just setup   # 创建 Python 虚拟环境，安装所有依赖
just dev     # 启动后端 + 桌面应用

安装 just：brew install just 或 cargo install just。运行 just --list 查看所有命令。

前置条件： Bun、Rust、Python 3.11+、Tauri 前置条件，以及 macOS 上的 Xcode。

本地构建

just build          # 构建 CPU 服务器二进制 + Tauri 应用
just build-local    # （Windows）构建 CPU + CUDA 服务器二进制 + Tauri 应用

添加新的声音模型

多引擎架构使得添加新 TTS 引擎变得简单。分步指南涵盖了完整流程：依赖调研、后端协议实现、前端连接以及 PyInstaller 打包。

该指南针对 AI 编程助手进行了优化。Agent 技能可以接收模型名称并自动完成整个集成 —— 您只需在本地测试构建即可。

项目结构

voicebox/
├── app/              # 共享 React 前端
├── tauri/            # 桌面应用（Tauri + Rust）
├── web/              # Web 部署
├── backend/          # Python FastAPI 服务器
├── landing/          # 营销网站
└── scripts/          # 构建和发布脚本

贡献

欢迎贡献！请参阅 CONTRIBUTING.md 了解指南。

Fork 仓库
创建特性分支
进行更改
提交 PR

安全

发现安全漏洞？请负责任地报告。详情见 SECURITY.md。

许可证

MIT 许可证 —— 详见 LICENSE。

参考资料

Voicebox
参考资料

MarkItDown 用于将各种文件转换为 Markdown 格式，以便供 LLM 及相关文本分析流水线使用

Wed, 15 Apr 2026 13:01:55 +0000

MarkItDown

MarkItDown 是一个轻量级 Python 工具，用于将各种文件转换为 Markdown 格式，以便供 LLM 及相关文本分析流水线使用。从这个角度来说，它与 textract 最为相似，但侧重于保留重要的文档结构和内容为 Markdown（包括：标题、列表、表格、链接等）。

虽然输出结果通常具有良好的可读性和人工友好性，但其本意是供文本分析工具使用 —— 对于需要高保真文档转换以供人类阅读的场景，可能不是最佳选择。

MarkItDown 目前支持以下格式的转换：

PDF
PowerPoint
Word
Excel
图像（EXIF 元数据和 OCR）
音频（EXIF 元数据和语音转录）
HTML
基于文本的格式（CSV、JSON、XML）
ZIP 文件（遍历内容）
YouTube 链接
ePub
……以及更多！

为什么选择 Markdown？

Markdown 非常接近纯文本，只有极少的标记或格式，但仍然能够表示重要的文档结构。主流 LLM（如 OpenAI 的 GPT-4o）原生“理解”Markdown，并且经常在未经提示的情况下就在回复中使用 Markdown。这表明它们已经在大量 Markdown 格式的文本上进行了训练，并且对其有很好的理解。作为一个附加好处，Markdown 约定也具有很高的 token 效率。

前置条件

MarkItDown 需要 Python 3.10 或更高版本。建议使用虚拟环境以避免依赖冲突。

使用标准 Python 安装时，可以通过以下命令创建并激活虚拟环境：

python -m venv .venv
source .venv/bin/activate

如果使用 uv，可以通过以下命令创建虚拟环境：

uv venv --python=3.12 .venv
source .venv/bin/activate
# 注意：请使用 'uv pip install' 而不是仅 'pip install' 来在此虚拟环境中安装包

如果您使用的是 Anaconda，可以通过以下命令创建虚拟环境：

conda create -n markitdown python=3.12
conda activate markitdown

安装

要安装 MarkItDown，请使用 pip：pip install 'markitdown[all]'。或者，您可以从源代码安装：

git clone git@github.com:microsoft/markitdown.git
cd markitdown
pip install -e 'packages/markitdown[all]'

使用方法

命令行

markitdown path-to-file.pdf > document.md

或者使用 -o 指定输出文件：

markitdown path-to-file.pdf -o document.md

您也可以使用管道传递内容：

cat path-to-file.pdf | markitdown

可选依赖

MarkItDown 有针对激活各种文件格式的可选依赖。在前文中，我们使用 [all] 选项安装了所有可选依赖。不过，您也可以单独安装它们，以便更好地控制。例如：

pip install 'markitdown[pdf, docx, pptx]'

将仅安装 PDF、DOCX 和 PPTX 文件的依赖。

目前，可用的可选依赖如下：

[all] 安装所有可选依赖
[pptx] 安装 PowerPoint 文件的依赖
[docx] 安装 Word 文件的依赖
[xlsx] 安装 Excel 文件的依赖
[xls] 安装旧版 Excel 文件的依赖
[pdf] 安装 PDF 文件的依赖
[outlook] 安装 Outlook 邮件的依赖
[az-doc-intel] 安装 Azure 文档智能的依赖
[audio-transcription] 安装 wav 和 mp3 文件音频转录的依赖
[youtube-transcription] 获取 YouTube 视频转录的依赖

插件

MarkItDown 还支持第三方插件。插件默认禁用。要列出已安装的插件：

markitdown --list-plugins

要启用插件，请使用：

markitdown --use-plugins path-to-file.pdf

要查找可用的插件，请在 GitHub 上搜索主题标签 #markitdown-plugin。要开发插件，请参阅 packages/markitdown-sample-plugin。

markitdown-ocr 插件

markitdown-ocr 插件为 PDF、DOCX、PPTX 和 XLSX 转换器添加了 OCR 支持，使用 LLM Vision 从嵌入的图片中提取文本 —— 这与 MarkItDown 已用于图像描述的 llm_client / llm_model 模式相同。无需新的 ML 库或二进制依赖。

安装：

pip install markitdown-ocr
pip install openai  # 或任何兼容 OpenAI 的客户端

用法：

传入与图像描述相同的 llm_client 和 llm_model：

from markitdown import MarkItDown
from openai import OpenAI

md = MarkItDown(
    enable_plugins=True,
    llm_client=OpenAI(),
    llm_model="gpt-4o",
)
result = md.convert("document_with_images.pdf")
print(result.text_content)

如果未提供 llm_client，插件仍会加载，但 OCR 会被静默跳过，转而使用标准的内置转换器。

详细文档请参阅 packages/markitdown-ocr/README.md。

Azure 文档智能

要使用 Microsoft 文档智能进行转换：

markitdown path-to-file.pdf -o document.md -d -e "<document_intelligence_endpoint>"
>

有关如何设置 Azure 文档智能资源的更多信息，请参见[此处](https://learn.microsoft.com/en-us/azure/ai-services/document-intelligence/how-to-guides/create-document-intelligence-resource?view=doc-intel-4.0.0)

### Python API

Python 中的基本用法：

```python
from markitdown import MarkItDown

md = MarkItDown(enable_plugins=False) # 设置为 True 以启用插件
result = md.convert("test.xlsx")
print(result.text_content)

Python 中的文档智能转换：

from markitdown import MarkItDown

md = MarkItDown(docintel_endpoint="<document_intelligence_endpoint>")
result = md.convert("test.pdf")
print(result.text_content)

要为图像描述使用大语言模型（目前仅适用于 pptx 和图像文件），请提供 llm_client 和 llm_model：

from markitdown import MarkItDown
from openai import OpenAI

client = OpenAI()
md = MarkItDown(llm_client=client, llm_model="gpt-4o", llm_prompt="可选的自定义提示")
result = md.convert("example.jpg")
print(result.text_content)

Docker

docker build -t markitdown:latest .
docker run --rm -i markitdown:latest < ~/your-file.pdf > output.md

贡献

本项目欢迎贡献和建议。大多数贡献要求您同意贡献者许可协议（CLA），声明您有权并确实授予我们使用您贡献的权利。详情请访问 https://cla.opensource.microsoft.com。

当您提交拉取请求时，CLA 机器人会自动确定您是否需要提供 CLA，并适当地装饰 PR（例如状态检查、评论）。只需按照机器人提供的说明操作即可。对于使用我们 CLA 的所有仓库，您只需执行此操作一次。

本项目已采用 Microsoft 开源行为准则。有关更多信息，请参阅行为准则常见问题解答或通过 opencode@microsoft.com 联系我们提出任何其他问题或评论。

如何贡献

您可以通过查看问题或帮助审查 PR 来提供帮助。任何问题或 PR 都受欢迎，但我们也标记了一些“开放贡献”和“开放审查”的问题，以帮助促进社区贡献。当然，这些只是建议，您可以以任何您喜欢的方式贡献。

| | 所有 | 特别需要社区帮助 | | ---------- | ------------------------------------------------------------ | --------------------------------------------------------------------------------------------------------------------------- | | **Issues** | [所有 Issues](https://github.com/microsoft/markitdown/issues) | [开放贡献的 Issues](https://github.com/microsoft/markitdown/issues?q=is%3Aissue+is%3Aopen+label%3A%22open+for+contribution%22) | | **PRs** | [所有 PRs](https://github.com/microsoft/markitdown/pulls) | [开放审查的 PRs](https://github.com/microsoft/markitdown/pulls?q=is%3Apr+is%3Aopen+label%3A%22open+for+reviewing%22) |

运行测试和检查

导航到 MarkItDown 包：
```
cd packages/markitdown
```

在您的环境中安装 hatch 并运行测试：

pip install hatch  # 安装 hatch 的其他方法：https://hatch.pypa.io/dev/install/
hatch shell
hatch test

（备选）使用已安装所有依赖的 Devcontainer：

# 在 Devcontainer 中重新打开项目并运行：
hatch test

在提交 PR 之前运行预提交检查：pre-commit run --all-files

贡献第三方插件

您还可以通过创建和分享第三方插件来贡献。更多详情请参见 packages/markitdown-sample-plugin。

商标

本项目可能包含项目、产品或服务的商标或徽标。授权使用 Microsoft 商标或徽标须遵守并必须遵循 Microsoft 商标与品牌指南。在本项目的修改版本中使用 Microsoft 商标或徽标不得引起混淆或暗示 Microsoft 赞助。任何第三方商标或徽标的使用均受该第三方的政策约束。

参考资料

MarkItDown
参考资料

Claude Cookbooks 提供了旨在帮助开发者使用 Claude 进行构建的代码和指南

Wed, 15 Apr 2026 13:01:55 +0000

Claude Cookbooks

Claude Cookbooks 提供了旨在帮助开发者使用 Claude 进行构建的代码和指南，提供了可直接复制并轻松集成到您自己项目中的代码片段。

前置条件

为了充分利用本 cookbook 中的示例，您需要一个 Claude API 密钥（可在此处免费注册）。

虽然代码示例主要使用 Python 编写，但这些概念可以适配到任何支持与 Claude API 交互的编程语言。

如果您是 Claude API 的新手，我们建议您从我们的 Claude API 基础课程开始，以打下坚实的基础。

进一步探索

正在寻找更多资源来增强您使用 Claude 和 AI 助手的体验？请查看以下有用的链接：

贡献

Claude Cookbooks 得益于开发者社区的贡献而蓬勃发展。我们重视您的意见，无论是提交想法、修复错别字、添加新指南还是改进现有指南。通过贡献，您将帮助使这个资源对每个人都更有价值。

为避免重复劳动，请在贡献之前查看现有的 issues 和 pull requests。

如果您有新示例或指南的想法，请在 issues 页面上分享。

示例目录

能力

分类：探索使用 Claude 进行文本和数据分类的技术。
检索增强生成：学习如何使用外部知识增强 Claude 的响应。
摘要：探索使用 Claude 进行有效文本摘要的技术。

工具使用与集成

工具使用：学习如何将 Claude 与外部工具和函数集成，以扩展其能力。

第三方集成

检索增强生成：使用外部数据源补充 Claude 的知识。
使用 Voyage AI 生成嵌入

多模态能力

Claude 视觉能力：
使用 Claude 生成图像：将 Claude 与 Stable Diffusion 结合用于图像生成。

高级技术

子代理：学习如何将 Haiku 作为子代理与 Opus 结合使用。
向 Claude 上传 PDF：将 PDF 解析为文本并传递给 Claude。
自动化评估：使用 Claude 自动化提示词评估过程。
启用 JSON 模式：确保 Claude 输出一致的 JSON。
创建审核过滤器：使用 Claude 为您的应用程序创建内容审核过滤器。
提示词缓存：学习使用 Claude 进行高效提示词缓存的技术。

其他资源

Anthropic on AWS：探索在 AWS 基础设施上使用 Claude 的示例和解决方案。
AWS Samples：来自 AWS 的代码示例集合，可适配用于 Claude。请注意，某些示例可能需要进行修改才能在 Claude 上达到最佳效果。

参考资料

Claude Cookbooks
参考资料

阿波罗 11 号制导计算机（AGC）中指令模块（Comanche055）和登月模块（Luminary099）原始代码。

Wed, 15 Apr 2026 13:01:55 +0000

阿波罗 11 号

阿波罗 11 号制导计算机（AGC）中指令模块（Comanche055）和登月模块（Luminary099）原始代码。

由 [虚拟 AGC][3] 和 [MIT 科学博物馆][4] 的伙计们完成电子化。

本仓库存在的目的是存储阿波罗 11 号原始代码。

当然，倘若在本仓库或原始代码扫描件 [Luminary 099][5] 及 [Comanche 055][6] 发现问题，或者任何我可能漏掉的文件，欢迎提交 PR。

贡献

在提交 pull request 之前，请先阅读 [CONTRIBUTING.zh_cn.md][7]。

编译

如果您对编译原始代码有兴趣的话，请查阅 [虚拟 AGC][8] 的文档。

归属


版权	公共领域。
Comanche055	阿波罗 11 号制导计算机（AGC）中的指令模块（CM）, Colossus 2A 的部分源代码 `Assemble revision 055 of AGC program Comanche by NASA` `2021113-051. 10:28 APR. 1, 1969`
Luminary099	阿波罗 11 号制导计算机（AGC）中的登月模块（LM）, Luminary 1A 的部分源代码 `Assemble revision 001 of AGC program LMY99 by NASA` `2021112-061. 16:27 JUL. 14, 1969`
汇编程序	yaYUL
联系人	Ron Burkey info@sandroid.org
网站	www.ibiblio.org/apollo
数字化	该源代码从 MIT 科学博物馆的印刷本电子化图片抄录、改编而来。电子化工作由 Paul Fjeld 完成，并由该馆的 Deborah Douglas 进一步整理。由衷地感激两位。

协议与许可

派生于 [CONTRACT_AND_APPROVALS.agc]

本 AGC 程序亦可称为：Colossus 2A

根据第 R-577 报告，本程序被用于指令模块。本程序是在 DSR 项目 55-23870 下编写的。该项目由（美国）国家航空航天局载人航天中心与位于马萨诸塞州剑桥的麻省理工学院 The Instrumentation Laboratory 实验室签属的第 NAS 9-4065 号合同进行资助。

提交者	Role	日期
Margaret H. Hamilton	Colossus 程序设计负责人阿波罗制导	1969 年 3 月 28 日

核准人	Role	日期
Daniel J. Lickly	负责人、任务程序开发阿波罗制导程序	1969 年 3 月 28 日
Fred H. Martin	Colossus 项目经理阿波罗制导程序	1969 年 3 月 28 日
Norman E. Sears	负责人、任务开发阿波罗制导程序	1969 年 3 月 28 日
Richard H. Battin	负责人、任务开发阿波罗制导程序	1969 年 3 月 28 日
David G. Hoag	负责人阿波罗制导程序	1969 年 3 月 28 日
Ralph R. Ragan	副负责人 Instrumentation Laboratory	1969 年 3 月 28 日

参考资料

阿波罗 11 号
- 贡献
- 编译
- 归属
  - 协议与许可
参考资料

本地可以运行的模型-03-多模态

Fri, 10 Apr 2026 13:01:55 +0000

多模态

没问题，那我们就继续。图像理解和语音对话是本地AI应用里很实用也很有趣的部分，它们能将你电脑的“大脑”拓展出“眼睛”和“耳朵”。

对于图像理解任务，我们直接利用你电脑上的Gemma 3 12B模型就能实现，无需额外下载。你只需要在代码中将它的功能稍作切换，并传入图片路径即可，它就能“看懂”图片并回答你的问题。

📸 图像理解能力

Gemma 3 12B 本身是一个多模态模型，理解图像是它的核心能力之一。你可以直接用它的API来处理本地的图片文件。

准备你的图片：比如，在你电脑的 C:\Users\你的用户名\Pictures 目录下，保存一张名为 cat.jpg 的图片。

在 Python 代码中调用：

import ollama
import base64
from pathlib import Path

# 1. 读取图片并转换为 Base64 格式
image_path = Path("C:/Users/你的用户名/Pictures/cat.jpg")
with open(image_path, "rb") as f:
    image_data = base64.b64encode(f.read()).decode("utf-8")

# 2. 构建提问内容
prompt = "描述一下这张图片的内容。"

# 3. 调用模型进行图像理解
#    注意：将 model 参数指定为你已安装的模型名称 'gemma3:12b'
response = ollama.generate(
    model='gemma3:12b',
    prompt=prompt,
    images=[image_data]
)

# 4. 打印模型生成的回答
print(response['response'])

代码里我们通过images参数传入图片数据，模型就会分析并给出它“看到”的描述，你可以用这个功能去测试它对你手头图片的理解效果。

🎤 语音对话能力

语音交互的本质就是“你说→电脑理解→电脑思考→电脑说话”的流程，其中涉及了语音转文字（STT）和文字转语音（TTS）。目前的工具链还不算特别集成化，但我们可以通过组合几个优秀的开源项目来实现。

流程图

flowchart LR
    A[🎤 你的语音输入] --> B[STT 语音识别<br>Faster-Whisper]
    B --> C[🎭 LLM 大脑处理<br>Gemma 3 12B (Ollama)]
    C --> D[🔊 TTS 语音合成<br>Kokoro / Edge-TTS]
    D --> E[🔉 电脑语音回答]

第一步：语音转文字 (STT)

我们会用到Faster-Whisper。它是OpenAI Whisper的优化版本，识别速度快，对中文的支持也不错。

在终端中安装它的Python库：pip install faster-whisper
准备一个测试用的音频文件，例如test.wav。
运行以下代码，它会把音频文件里的内容转成文字，并打印在屏幕上。

示例代码：

from faster_whisper import WhisperModel

# 选择模型大小，'tiny'最快但精度稍低，'base'或'small'是效果与速度的平衡
model = WhisperModel("base", device="cpu", compute_type="int8")

segments, info = model.transcribe("test.wav", beam_size=5, language="zh")

print("识别到的文本: ", " ".join(seg.text for seg in segments))

第二步：文字转语音 (TTS)

这是让电脑开口说话的关键。如果你的项目不要求复杂的本地部署，推荐先尝试Edge-TTS。它调用的是你电脑里Microsoft Edge浏览器的基础服务，无需额外下载大模型，实现起来最简单。

安装：pip install edge-tts
运行下面的代码，它就能把一段文字变成语音，并保存为一个MP3文件。

示例代码：

import asyncio
import edge_tts

async def text_to_speech(text, output_file):
    # 设置语音为中文女声，你也可以换成 'zh-CN-YunxiNeural' 等试试看
    communicate = edge_tts.Communicate(text, "zh-CN-XiaoxiaoNeural")
    await communicate.save(output_file)

# 使用示例
asyncio.run(text_to_speech("你好，欢迎探索AI的世界！", "output.mp3"))

如果你想尝试效果更自然的本地TTS模型，可以搜索 Qwen3-TTS、CosyVoice或 Edge-TTS（入门首选）这些项目。

第三步：整合起来

完成上述两步后，一个完整的语音对话流程就在你的Python程序里跑通了。你可以通过麦克风实时录音，再调用Faster-Whisper转为文字，然后把文字发给Gemma模型处理，最后把模型的回复文本用TTS转成语音播放出来。

🧩 其它AI能力模型

除了图像和语音，你之前提到的翻译和文本向量化，也有非常成熟的本地解决方案。这些轻量级的模型可以作为你现有AI能力很好的补充。

AI能力	模型推荐	一句话亮点	部署方式 (Ollama)
文本向量化	`embeddinggemma`	Google出品，<200MB，专为本地设备设计，用于语义搜索、RAG等。	`ollama pull embeddinggemma:300m-qat-q4_0`
专业OCR	`glm-ocr`	仅0.9B参数，在表格/公式识别上表现优异，Ollama可直接部署。	`ollama pull glm-ocr`
高效翻译	`Hunyuan-MT-Chimera-7B`	腾讯混元出品，7B参数，可在Ollama本地运行，支持多语言。	`ollama run SimonPu/Hunyuan-MT-Chimera-7B:Q8`

参考资料

多模态
参考资料

本地可以运行的模型-gamma

Fri, 10 Apr 2026 13:01:55 +0000

一些能力

Google 的 Gemma 系列，特别是最新的 Gemma 3，可能是你正在寻找的本地 AI 服务构建的核心模型。它延续了 Google 开源、高性能的传统，最大的亮点是将强大的多模态能力（理解图像和文本）引入了轻量级模型，让本地部署的门槛大大降低。

我把 Gemma 3 与其他相关的 Gemma 模型一起，整理进之前的分档清单里，方便你全面比较：

🧩 Gemma 系列模型分档对比

AI 能力	模型名称	模型大小 (约)	效果评估	特点与适用场景
AI对话/总结	Gemma 3 270M (1B 版)	量化后约 200MB - 500MB	效果尚可，但功能受限功能偏向指令遵循、函数调用，但不支持图像理解，上下文窗口为32K	极致轻量的文本任务：适合在边缘设备（如手机）或资源极度紧张的环境下进行简单的文本问答、摘要和函数调用
AI对话/图片理解	Gemma 3 4B	量化后约 2.6GB - 3.4GB	效果好，性价比极高 Google官方数据，4B模型的指令微调版(4B-IT)性能可媲美上一代27B模型。在部分复杂推理上逊于12B/27B版本，但在摘要、基础推理上表现强劲	AI对话、图片理解的性价比之选：对中文支持好，是测试图片理解、RAG等高级功能且希望控制成本的入门级选择
AI对话/图片理解	Gemma 3 12B	量化后约 6.6GB	效果优秀在 GSM8k (94.4%)、HumanEval (85.4%) 等多项基准测试中表现出色。虽然一些分析认为其智慧指数在同类模型中不算顶尖，但综合能力非常均衡	追求性能平衡的理想选择：适合需要处理长文档、进行复杂推理和高质量AI对话的场景，能很好地胜任绝大多数本地任务
AI对话/图片理解	Gemma 3 27B	量化后约 14.1GB - 16GB	效果卓越旗舰级性能：在多个基准测试中性能卓越，可与规模更大的模型（如 Llama 3 70B）一较高下。支持完整的128K上下文。	追求极致性能的本地部署：虽然需要一定的硬件资源，但能提供接近云端大模型的高质量体验，特别适合处理图表和 PDF 的 RAG 应用
图片理解	PaliGemma 2 (3B/10B/28B)	-	效果优秀专注图像理解的专家模型：在OCR、目标检测、图像分割、文档理解等专业视觉任务上能力突出。	专业级图像分析：如果对图像OCR、物体检测等有非常高的要求，PaliGemma 系列是比通用 Gemma 3 更合适的选择
向量化分词	EmbeddingGemma	< 200MB	效果好，性价比高专为RAG和语义搜索设计，可在生成高质量文本嵌入的同时，保持极低的资源消耗。	构建本地知识库/RAG系统的核心组件
文本生成(超长上下文)	RecurrentGemma (2B/9B)	-	效果好，推理高效采用创新的 Griffin 混合架构，推理速度更快，内存占用更低。	长序列文本生成：特别适合需要处理超长文档（如书籍、报告）的生成任务

💡 关键解读

表格中关于 Gemma 3 270M 的“1B版”说明：Gemma 3 系列中最小的是 1B 模型，但搜索到许多信息都聚焦于一个更小的 270M（2.7亿）参数版本。你可以将其看作是 Gemma 3 1B 的“青春版”或一个极度轻量化的变体，它在功能上有所取舍，更专注于快速、轻量的本地任务。

量化（Quantization）是关键：Gemma 3 原生支持 4-bit 量化。这是它在有限内存（如16GB）电脑上流畅运行的核心技术，能以微小的精度换取大幅的内存节省。
模型生态成熟：Gemma 3 得到了包括 Ollama、LM Studio、llama.cpp 等主流推理框架的广泛支持，部署非常方便。

总的来看，Gemma 3 系列为本地 AI 提供了非常完整的选择路径：从极致轻量的 270M 版本，到性能卓越的 27B 旗舰，并且全线支持多模态。这个完整的生态，正是它相比其他模型的一大优势。

如果对其中某个模型的部署细节或具体案例感兴趣，我们可以继续深入探讨～

gemma-4

针对你的配置，Gemma 4系列中有两个模型是绝佳选择：主打端侧的 Gemma 4 E2B 和 Gemma 4 E4B。它们都是为在资源有限的设备上高效运行而设计的。

为了方便对比，我将四个模型的核心参数整理如下：

模型 (Model)	架构 (Architecture)	总参数量 (Total Params)	有效/激活参数量 (Active/Effective Params)	上下文长度 (Context Length)	4-bit量化后显存占用 (4-bit VRAM)	原生精度BF16显存占用 (Native VRAM)
Gemma 4 E2B	密集型 + PLE	~51亿 (5.1B)	~23亿 (2.3B)	128K	~1.5-2GB	~7.2GB
Gemma 4 E4B	密集型 + PLE	~79亿 (7.9B)	~45亿 (4.5B)	128K	~3.6-5GB	~9.6-16GB
Gemma 4 26B A4B	MoE (混合专家)	~252亿 (25.2B)	~38亿 (3.8B)	256K	~16-18GB	~50-52GB
Gemma 4 31B	密集型	~307亿 (30.7B)	全部激活	256K	~17-20GB	~62GB

从表中可以看到，32GB内存和8GB显存的配置，可以轻松运行经过4-bit量化的 E2B 和 E4B 模型。 但对于需要16GB以上显存的26B和31B模型来说，这个配置就力不从心了。

🤖 端侧双雄：E2B与E4B，你的本地AI引擎

这两款小模型非常强大，是专为笔记本电脑和移动设备设计的。

E2B与E4B的核心技术：逐层嵌入 (PLE)：它们名称中的“E”代表“有效”参数。Google通过一种名为逐层嵌入 (Per-Layer Embeddings) 的技术，让模型能以较小的“有效”参数量，获得接近更大模型的性能。
性能足以胜任日常工作：两者都是强大的多模态模型，不仅能处理文本和图像，还原生支持音频输入。虽然 E4B 稍大，但性能也更接近上一代旗舰 Gemma 3 27B。
端侧部署的理想之选：无论从设计初衷还是硬件要求来看，E2B和E4B都是你当前配置下最合适的选择。

🚀 MoE与稠密大模型：对显存的更高要求

如果你未来升级了硬件，这两个模型是更强大的选择，但现阶段你的配置暂时无法满足它们的基本要求。

26B A4B：效率旗舰：这是Gemma 4系列的首个MoE（混合专家）模型。它拥有252亿总参数，但推理时仅激活其中约38亿参数。但即便算上KV缓存，它对显存的需求也远超8GB，因此你的8GB显存无法胜任。
31B：质量旗舰：这是一个传统的密集型模型，拥有约307亿参数，推理时全部激活，是系列中性能最强的“天花板”。但这也意味着它对算力和显存有极高的要求。

💡 关于32GB内存和8GB显存的配置

内存主要用于加载模型权重和存储上下文，你的32GB内存非常充裕。显存则主要负责运行时的计算，是决定能跑什么模型的关键。

E2B 与 E4B 是最佳选择：这两款模型在设计之初就面向端侧部署，与你的硬件条件完美匹配。经过4-bit量化后，它们对显存的需求在你的配置能力范围内。
26B A4B 与 31B 当前无法运行：即使是经过4-bit量化，这两款大模型对显存的基本需求也在16GB以上。你的8GB显存有较大差距，无法满足它们的运行要求。

💎 总结与建议

推荐模型：首选 Gemma 4 E4B。在8GB显存下可以流畅运行，能力足以处理复杂的本地AI任务。如果你的需求更轻量、更在乎速度，Gemma 4 E2B 也是不错的选择。
部署工具：推荐使用 Ollama、llama.cpp 或 vLLM 等工具，它们都对Gemma 4提供了很好的支持，并能方便地进行模型量化。
升级选项：量化是关键。如果你将来升级到显存大于16GB的显卡（如RTX 4060 Ti 16GB、RTX 4070及以上），就可以尝试运行 26B A4B 或 31B 模型了。
补充说明：Gemma 4系列也支持文本、图像和视频输入，其中 E2B 和 E4B 额外支持音频输入。此外，该系列已采用对商业应用友好的 Apache 2.0 开源协议。

运行

ollama run gemma4:e4b

参考资料

一些能力
- 🧩 Gemma 系列模型分档对比
- 💡 关键解读
gemma-4
参考资料

本地可以运行的模型

Fri, 10 Apr 2026 13:01:55 +0000

一些能力

希望在自己的个人电脑，用 python 启动一些小的 ai 服务，测试验证。

期望有下面的 ai 能力列表，每一个推荐对应的开源模型+理由:

## AI 能力

- [] ocr
- [] tts stt 文本、语音
- [] 图片理解
- [] 图片生成
- [] 对文章、视频的总结能力
- [] 评论区 AT ai 的能力
- [] ai 对话
- [] 向量化分词
- [] 翻译

默认推荐

没问题，这是按你要求整理的模型大小清单：

AI 能力	推荐模型	模型大小 (约)
OCR	PaddleOCR-VL-0.9B	约 1.7 GB
TTS (文本转语音)	NeuTTS Air	约 300 MB (量化后)
STT (语音转文本)	Whisper.cpp (base)	142 MB (模型文件)
图片理解	TBAC-UniImage-3B	约 5.7 GB
图片生成	Z-Image-Turbo	约 6 GB (FP16)
文本总结/对话	GPT-OSS-20B	约 12 GB (量化版)
向量化分词	EmbeddingGemma	< 200 MB (量化后)
翻译	Hunyuan-MT-7B	约 16 GB

📊 模型大小估算说明

模型大小是根据参数量和数据精度（通常为FP16）估算的。例如，一个7B参数的FP16模型，其大小大约是 7B * 2字节 = 14 GB，与你表格中的模型大小相符。
部分模型提供量化版本（如GGUF格式），能以轻微精度损失为代价，大幅减少存储和运行所需的内存。
运行时的实际内存占用通常会比模型文件本身大一些。

有更小的吗？我希望模型可以在 100mb 之下，另外评估太小的话，模型的效果可以使用吗

没问题，100MB 对于很多 AI 模型来说确实是个严格的限制，但好消息是，随着模型轻量化技术的发展，这个尺寸下依然有很多“小而美”的模型可用。

我为你重新整理了一份推荐清单，这次所有模型的体积都控制在了 100MB 以内，并附带了它们在不同任务上的表现评估。

🧩 100MB 以内的“轻量级”开源AI模型推荐

AI 能力	推荐开源模型	模型大小 (约)	效果评估与说明
OCR	PaddleOCR-slim	5 MB 以内	可用性高。专为轻量化设计的OCR模型，体积极小但识别精度尚可，非常适合你的测试场景。
STT (语音转文本)	Whisper.cpp (tiny)	39 MB - 75 MB	效果较好。这是Whisper系列的最小版本，识别准确率（Accuracy: Good）能满足基本需求。
TTS (文本转语音)	Pocket TTS	约 100 MB	效果出色。在100M参数规模下实现了高质量语音，可在普通笔记本CPU上实时运行，音质自然流畅。
图片理解	UForm (tiny)	约 100 MB	效果一般。体积限制下，它更适合基础的图像描述（Captioning）和视觉问答（VQA），复杂场景理解能力有限。
图片生成	Perfusion	100 KB (0.1 MB)	效果尚可。这是一个概念上极小的模型，能够生成“可圈可点”的图片，主要用于快速概念验证。
AI对话/总结	Qwen3-0.6B	约 300 MB (略超100MB)	性能优秀但略超限。0.6B参数的小模型，功能全面，支持多语言。作为参考，可考虑更小的 `Qwen1.5-0.5B-Chat` (约 200 MB)，它在纯CPU环境下也能稳定运行。
向量化分词	dmeta-embedding-zh	约 100 MB	效果较好。这是一个专为中文优化的轻量级向量模型，在通用检索和RAG场景表现优秀。
翻译	(暂未发现合适模型)	-	暂无完全符合要求的模型。如腾讯混元 HY-MT1.5-1.8B 虽轻量，但内存占用仍达1GB，无法满足100MB限制。

💡 扩展：更多100MB以内的超轻量模型

除了以上推荐，还有一些模型也值得关注，可以作为备选：

Liquid Nanos 系列：参数规模在3.5亿到26亿之间，足够小巧，可直接在笔记本等设备本地运行。
Gemma 3 270M：谷歌发布的超小型模型，参数规模约2.7亿，可在智能手机上离线运行。
Embedding Gemma：仅3.08亿参数的多语言向量模型，体积小巧。
Small-Stable-Diffusion-V0：Stable Diffusion的轻量化版本，针对CPU优化，无需昂贵GPU即可生成高质量图像。

💎 最终建议

在你的16GB内存电脑上，运行这些模型基本无压力。

但需要注意，由于体积限制，它们在处理复杂长文本、高分辨率图片或多轮对话等复杂任务时效果可能有限。

如果测试中发现这些模型的能力无法满足要求，可以考虑：

寻找量化版本（GGUF等）：这是最有效的折衷方案，能在不显著牺牲效果的前提下，大大减少模型体积。
使用更大的量化模型：适当放宽体积限制（如300-500MB），可以换来大幅的性能提升。

希望这份新清单能帮到你，如果在测试时遇到什么问题，随时可以再来问我～

AI 能力	模型名称	模型大小	效果评估	特点与适用场景
📝 OCR	PP-OCRv5	< 100 MB	效果较好首个支持5种文字类型的超轻量级(<100M)开源模型，支持复杂手写体。	教育批改、病历/合同数字化等，兼顾体积与性能。
📝 OCR	GLM-OCR (0.9B)	~ 1.7 GB (0.9B)	效果出色专为复杂文档设计，融合0.4B视觉编码器与0.5B语言解码器。	复杂的文档理解（如表格、公式），追求高性能本地文档解析。
🗣️ STT	Whisper (tiny)	39 - 75 MB	效果基础支持多语言，适合实时性要求高的场景，中文准确率约85%-88%。	实时转写、移动端等资源紧张但对响应速度有要求的场景。
🗣️ STT	Whisper (small)	约 488 MB	效果较好平衡性能与资源，中文准确率可达92%-94%。	需要较高识别精度，且硬件条件尚可的场景。
🗣️ TTS	Kokoro-82M	< 500 MB	效果较好仅82M参数，中文语音自然，支持8种音色，可在CPU上高效推理。	轻量级中文语音应用，资源受限但要求中文语音自然的设备。
🗣️ TTS	Pocket TTS (100M)	~ 300 MB (100M)	效果较好 100M参数，可在CPU上超实时运行，支持高质量语音克隆（需5秒音频）。	边缘设备、笔记本，特别是需要快速响应和语音克隆的场景。
🖼️ 图片理解	SmolVLM-256M	< 1 GB (256M)	效果较好 256M参数，支持图像描述和视觉问答(VQA)，是当时最小的多模态模型之一。	文档理解、图像描述、视觉问答，面向资源有限的PC或移动设备。
🖼️ 图片理解	PaliGemma	< 5 GB (3B)	效果出色结合SigLIP视觉模型与Gemma语言模型，支持复杂视觉推理。	需要高精度图像描述、视觉问答或复杂视觉推理的场景。
🖼️ 图片理解	MiniCPM-V 2.6	< 5 GB (8B)	效果优秀端侧多模态能力对标GPT-4V，支持单图、多图、视频理解。	对标商业模型的高端本地部署，需要强大视觉理解能力的综合应用。
🎨 图片生成	Small-Stable-Diffusion-v0	~ 700 MB	效果尚可针对CPU优化，无需高端GPU即可生成图像，速度约5秒/张。	轻量级图像生成，对推理速度要求高，硬件资源有限的场景。
🎨 图片生成	DreamLite (0.39B)	~ 780 MB (0.39B)	效果较好 390M参数，4步推理即可在1秒内生成1024x1024图像。	需要快速、高质量图像生成和编辑的本地应用。
🎨 图片生成	Z-Image-Turbo (6B)	约 12 GB (6B)	效果优秀阿里通义出品，定位为“轻量且高性能”。	性能要求极高的本地图像生成，接近商业模型效果。
💬 AI对话/总结	ChatLM-mini-Chinese (0.2B)	~ 400 MB (0.2B)	效果基础 210M参数，专为中文对话设计，极低资源消耗。	中文对话应用，硬件资源非常有限（如树莓派）的场景。
💬 AI对话/总结	Qwen-0.5B-Instruct	~ 1 GB (0.5B)	效果较好 0.5B参数，超轻量，可在CPU上实现秒级响应。	通用轻量级对话、文本摘要，适合边缘/低配置设备。
💬 AI对话/总结	GPT-OSS-20B (Q4)	~ 12 GB (20B)	效果优秀量化后体积可控，性能接近GPT-4级别。	追求高质量本地对话/总结，且硬件（显存/内存）充足的场景。
🔢 向量化	paraphrase-MiniLM-L6-v2	< 100 MB	效果较好约100MB，6层Transformer，专为英文设计，推理速度快。	英文语义搜索、RAG，资源紧张且对性能有要求的应用。
🔢 向量化	EmbeddingGemma (0.3B)	< 200 MB (0.3B)	效果出色 300M参数，多语言支持，性能直追0.6B的同类模型。	多语言RAG、语义搜索、分类、聚类等。
🌍 翻译	Tencent-HY-MT1.5-1.8B	~ 3.6 GB (1.8B)	效果出色支持33语种互译，效果超越多数商用API，可本地部署。	端侧离线翻译，需要高质量、低延迟翻译的各类应用。
🌍 翻译	Tencent-HY-MT1.5-7B	~ 14 GB (7B)	效果优秀 7B版本，在专业术语和多轮对话场景效果更佳。	对翻译质量有最高要求的专业领域。

参考资料

一些能力
参考资料

VoxCPM2：基于连续表征的多语言语音合成、创意音色设计与高保真声音克隆

Thu, 09 Apr 2026 13:01:55 +0000

VoxCPM2

基于连续表征的多语言语音合成、创意音色设计与高保真声音克隆

VoxCPM 是一个无离散音频分词器（Tokenizer-Free）的语音合成系统，通过端到端的扩散自回归架构直接生成连续语音表征，绕过对音频的离散编码步骤，实现高度自然且富有表现力的语音合成。

VoxCPM2 是最新的版本 — 基于 MiniCPM-4 基座构建，总计 20亿 参数，在超过 200万小时 的多语种音频数据上训练，支持 30种全球语言+9种中文方言、音色设计、可控声音克隆，原生输出 48kHz 高质量音频。

✨ 核心特性

🌍 30种语言语音合成 — 直接输入原始文本即可合成（支持语言详见下文），无需额外语言标签
🎨 音色设计 — 用自然语言描述（性别、年龄、音色、情绪、语速……）凭空创建全新音色，无需参考音频
🎛️ 可控声音克隆 — 从参考音频片段克隆任意声音，可叠加风格指令控制情绪、语速和表现力，同时保持原始音色
🎙️ 极致克隆 — 提供参考音频及其文本内容，模型接着参考音频进行无缝续写，从而精准还原声音细节特征（与 VoxCPM1.5 一致）
🔊 48kHz 高质量音频 — 输入 16kHz 参考音频，通过 AudioVAE V2 的非对称编解码设计直接输出 48kHz 高质量音频，内置超分能力
🧠 语境感知合成 — 根据文本内容自动推断合适的韵律和表现力
⚡ 实时流式合成 — 在 NVIDIA RTX 4090 上 RTF 低至 ~0.3，通过 Nano-VLLM 加速后可达 ~0.13
📜 完全开源，商用就绪 — 权重和代码基于 Apache-2.0 协议发布，免费商用

🌍 支持的语言（30种）

阿拉伯语、缅甸语、中文、丹麦语、荷兰语、英语、芬兰语、法语、德语、希腊语、希伯来语、印地语、印尼语、意大利语、日语、高棉语、韩语、老挝语、马来语、挪威语、波兰语、葡萄牙语、俄语、西班牙语、斯瓦希里语、瑞典语、菲律宾语、泰语、土耳其语、越南语

中国方言：四川话、粤语、吴语、东北话、河南话、陕西话、山东话、天津话、闽南话

🚀 快速开始

安装

pip install voxcpm

环境要求： Python ≥ 3.10 (<3.13)，PyTorch ≥ 2.5.0，CUDA ≥ 12.0。详见快速开始文档。

Python API

🗣️ 文本转语音

from voxcpm import VoxCPM
import soundfile as sf

model = VoxCPM.from_pretrained(
  "openbmb/VoxCPM2",
  load_denoiser=False,
)

wav = model.generate(
    text="VoxCPM2 是目前推荐使用的多语言语音合成版本。",
    cfg_value=2.0,
    inference_timesteps=10,
)
sf.write("demo.wav", wav, model.tts_model.sample_rate)
print("已保存: demo.wav")

如果你希望先从 ModelScope 下载模型到本地（适用于国内网络访问），可以使用：

pip install modelscope

from modelscope import snapshot_download
snapshot_download("OpenBMB/VoxCPM2", local_dir='./pretrained_models/VoxCPM2') # 指定模型保存的本地路径

from voxcpm import VoxCPM
import soundfile as sf
model = VoxCPM.from_pretrained('./pretrained_models/VoxCPM2', load_denoiser=False)

wav = model.generate(
    text="VoxCPM2 是目前推荐使用的多语言语音合成版本。",
    cfg_value=2.0,
    inference_timesteps=10,
)
sf.write("demo.wav", wav, model.tts_model.sample_rate)

🎨 音色设计

用自然语言描述创建全新音色，无需参考音频。格式： 在 text 开头用括号写入音色描述（如 "(音色描述)要合成的文本。"）：

wav = model.generate(
    text="(年轻女性，声音温柔甜美)你好，欢迎使用VoxCPM2！",
    cfg_value=2.0,
    inference_timesteps=10,
)
sf.write("voice_design.wav", wav, model.tts_model.sample_rate)

🎛️ 可控声音克隆

上传一段参考音频，模型克隆其音色，同时可以使用控制指令调节语速、情绪或风格。

wav = model.generate(
    text="这是VoxCPM2生成的克隆语音。",
    reference_wav_path="path/to/voice.wav",
)
sf.write("clone.wav", wav, model.tts_model.sample_rate)

wav = model.generate(
    text="(稍快一点，欢快的语气)这是带风格控制的克隆语音。",
    reference_wav_path="path/to/voice.wav",
    cfg_value=2.0,
    inference_timesteps=10,
)
sf.write("controllable_clone.wav", wav, model.tts_model.sample_rate)

🎙️ 极致克隆

提供参考音频及其精确文本转录，实现基于音频续写的高保真克隆。为获得最高克隆相似度，可将同一音频同时传给 reference_wav_path 和 prompt_wav_path：

wav = model.generate(
    text="这是使用VoxCPM2的极致克隆演示。",
    prompt_wav_path="path/to/voice.wav",
    prompt_text="参考音频的文本转录。",
    reference_wav_path="path/to/voice.wav",  # 可选，提升相似度
)
sf.write("hifi_clone.wav", wav, model.tts_model.sample_rate)

🔄 流式 API

```python import numpy as np chunks = [] for chunk in model.generate_streaming( text="使用VoxCPM进行流式语音合成非常简单！", ): chunks.append(chunk) wav = np.concatenate(chunks) sf.write("streaming.wav", wav, model.tts_model.sample_rate) ```

命令行使用

# 音色设计（无需参考音频）
voxcpm design \
  --text "VoxCPM2带来全新语音合成体验。" \
  --output out.wav

# 可控声音克隆（带风格控制）
voxcpm design \
  --text "VoxCPM2带来全新语音合成体验。" \
  --control "年轻女声，温暖温柔，略带微笑" \
  --output out.wav

# 声音克隆（参考音频）
voxcpm clone \
  --text "这是一个声音克隆的演示。" \
  --reference-audio path/to/voice.wav \
  --output out.wav

# 极致克隆（提示音频 + 转录文本）
voxcpm clone \
  --text "这是一个声音克隆的演示。" \
  --prompt-audio path/to/voice.wav \
  --prompt-text "参考音频转录文本" \
  --reference-audio path/to/voice.wav \
  --output out.wav

# 批量处理
voxcpm batch --input examples/input.txt --output-dir outs

# 帮助
voxcpm --help

Web Demo

python app.py --port 8808  # 然后在浏览器打开 http://localhost:8808

🚢 生产部署（Nano-vLLM）

如需高吞吐量部署，使用 Nano-vLLM-VoxCPM — 基于 Nano-vLLM 构建的专用推理引擎，支持并发请求和异步 API。

pip install nano-vllm-voxcpm

from nanovllm_voxcpm import VoxCPM
import numpy as np, soundfile as sf

server = VoxCPM.from_pretrained(model="/path/to/VoxCPM", devices=[0])
chunks = list(server.generate(target_text="你好，我来自VoxCPM！"))
sf.write("out.wav", np.concatenate(chunks), 48000)
server.stop()

在 NVIDIA RTX 4090 上 RTF 低至 ~0.13（标准 PyTorch 实现约 ~0.3），支持批量并发请求和 FastAPI HTTP 服务。详见 Nano-vLLM-VoxCPM 仓库。

完整参数说明、多场景示例与声音克隆技巧 → 快速开始指南使用指南 Cookbook

📦 模型与版本

	VoxCPM2	VoxCPM1.5	VoxCPM-0.5B
状态	🟢 最新版本	稳定版	旧版
主模型参数量	2B	0.6B	0.5B
音频采样率	48kHz	44.1kHz	16kHz
LM处理码率	6.25Hz	6.25Hz	12.5Hz
语言支持数量	30	2（中文、英文）	2（中文、英文）
克隆模式	隔离参考音频（无需文本） & 音频续写	仅音频续写	仅音频续写
音色设计	✅	—	—
可控声音克隆	✅	—	—
SFT / LoRA	✅	✅	✅
RTF (RTX 4090)	~0.30	~0.15	~0.17
RTF Nano-VLLM (RTX 4090)	~0.13	~0.08	~0.10
显存占用	~8 GB	~6 GB	~5 GB
模型权重	🤗 HF / MS	🤗 HF / MS	🤗 HF / MS
技术报告	即将发布	—	arXiv ICLR 2026
Demo 页面	音频示例	—	音频示例

VoxCPM2 采用连续音频表征、扩散自回归范式，模型在 AudioVAE 的连续隐空间中通过四阶段处理：LocEnc → TSLM → RALM → LocDiT，实现丰富的表现力语音合成和 48kHz 原生音频输出。

完整架构细节、VoxCPM2 升级内容和模型对比表见架构设计文档。

📊 性能评测

VoxCPM2 在公开的零样本和可控 TTS 基准测试中取得了 SOTA 或可比的结果。

Seed-TTS-eval

Seed-TTS-eval WER(⬇)&SIM(⬆) 结果（点击展开）

| Model | Parameters | Open-Source | test-EN | | test-ZH | | test-Hard | | |------|------|------|:------------:|:--:|:------------:|:--:|:-------------:|:--:| | | | | WER/%⬇ | SIM/%⬆| CER/%⬇| SIM/%⬆ | CER/%⬇ | SIM/%⬆ | | MegaTTS3 | 0.5B | ❌ | 2.79 | 77.1 | 1.52 | 79.0 | - | - | | DiTAR | 0.6B | ❌ | 1.69 | 73.5 | 1.02 | 75.3 | - | - | | CosyVoice3 | 0.5B | ❌ | 2.02 | 71.8 | 1.16 | 78.0 | 6.08 | 75.8 | | CosyVoice3 | 1.5B | ❌ | 2.22 | 72.0 | 1.12 | 78.1 | 5.83 | 75.8 | | Seed-TTS | - | ❌ | 2.25 | 76.2 | 1.12 | 79.6 | 7.59 | 77.6 | | MiniMax-Speech | - | ❌ | 1.65 | 69.2 | 0.83 | 78.3 | - | - | | F5-TTS | 0.3B | ✅ | 2.00 | 67.0 | 1.53 | 76.0 | 8.67 | 71.3 | | MaskGCT | 1B | ✅ | 2.62 | 71.7 | 2.27 | 77.4 | - | - | | CosyVoice | 0.3B | ✅ | 4.29 | 60.9 | 3.63 | 72.3 | 11.75 | 70.9 | | CosyVoice2 | 0.5B | ✅ | 3.09 | 65.9 | 1.38 | 75.7 | 6.83 | 72.4 | | SparkTTS | 0.5B | ✅ | 3.14 | 57.3 | 1.54 | 66.0 | - | - | | FireRedTTS | 0.5B | ✅ | 3.82 | 46.0 | 1.51 | 63.5 | 17.45 | 62.1 | | FireRedTTS-2 | 1.5B | ✅ | 1.95 | 66.5 | 1.14 | 73.6 | - | - | | Qwen2.5-Omni | 7B | ✅ | 2.72 | 63.2 | 1.70 | 75.2 | 7.97 | 74.7 | | Qwen3-Omni | 30B-A3B | ✅ | 1.39 | - | 1.07 | - | - | - | | OpenAudio-s1-mini | 0.5B | ✅ | 1.94 | 55.0 | 1.18 | 68.5 | 23.37 | 64.3 | | IndexTTS2 | 1.5B | ✅ | 2.23 | 70.6 | 1.03 | 76.5 | 7.12 | 75.5 | | VibeVoice | 1.5B | ✅ | 3.04 | 68.9 | 1.16 | 74.4 | - | - | | HiggsAudio-v2 | 3B | ✅ | 2.44 | 67.7 | 1.50 | 74.0 | 55.07 | 65.6 | | VoxCPM-0.5B | 0.6B | ✅ | 1.85 | 72.9 | 0.93 | 77.2 | 8.87 | 73.0 | | VoxCPM1.5 | 0.8B | ✅ | 2.12 | 71.4 | 1.18 | 77.0 | 7.74 | 73.1 | | MOSS-TTS | | ✅ | 1.85 | 73.4 | 1.20 | 78.8 | - | - | | Qwen3-TTS | 1.7B | ✅ | 1.23 | 71.7 | 1.22 | 77.0 | 6.76 | 74.8 | | FishAudio S2 | 4B | ✅ | 0.99 | - | 0.54 | - | 5.99 | - | | LongCat-Audio-DiT | 3.5B | ✅ | 1.50 | 78.6 | 1.09 | 81.8 | 6.04 | 79.7 | | **VoxCPM2** | 2B | ✅ | 1.84 | 75.3 | 0.97| 79.5| 8.13 | 75.3 |

CV3-eval

CV3-eval 多语言 WER/CER(⬇) 结果（点击展开）

| Model | zh | en | hard-zh | hard-en | ja | ko | de | es | fr | it | ru | |-------|:--:|:--:|:--:|:--:|:--:|:--:|:--:|:--:|:--:|:--:|:--:| | CosyVoice2 | 4.08 | 6.32 | 12.58| 11.96| 9.13 | 19.7 |- | - | - | - | - | | CosyVoice3-1.5B | 3.91 | 4.99 | 9.77 | 10.55 | 7.57 | 5.69 | 6.43 | 4.47 | 11.8 | 10.5 | 6.64 | | Fish Audio S2 | 2.65 | 2.43 | 9.10 | 4.40 | 3.96 | 2.76 | 2.22 | 2.00 | 6.26 | 2.04 | 2.78 | | **VoxCPM2** | 3.65 | 5.00 | 8.55 | 8.48 | 5.96 | 5.69 | 4.77 | 3.80 | 9.85 | 4.25 | 5.21 |

MiniMax-Multilingual-Test

Minimax-MLS-test WER(⬇) 结果（点击展开）

| Language | Minimax | ElevenLabs | Qwen3-TTS | FishAudio S2 | **VoxCPM2** | |----------|:-------:|:----------:|:--------------------:|:------------:|:-----------:| | Arabic | **1.665** | 1.666 | – | 3.500 | 13.046 | | Cantonese | 34.111 | 51.513 | – | **30.670** | 38.584 | | Chinese | 2.252 | 16.026 | 0.928 | **0.730** | 1.136 | | Czech | 3.875 | **2.108** | – | 2.840 | 24.132 | | Dutch | 1.143 | **0.803** | – | 0.990 | 0.913 | | English | 2.164 | 2.339 | **0.934** | 1.620 | 2.289 | | Finnish | 4.666 | 2.964 | – | 3.330 | **2.632** | | French | 4.099 | 5.216 | **2.858** | 3.050 | 4.534 | | German | 1.906 | 0.572 | 1.235 | **0.550** | 0.679 | | Greek | 2.016 | **0.991** | – | 5.740 | 2.844 | | Hindi | 6.962 | **5.827** | – | 14.640 | 19.699 | | Indonesian | 1.237 | **1.059** | – | 1.460 | 1.084 | | Italian | 1.543 | 1.743 | **0.948** | 1.270 | 1.563 | | Japanese | 3.519 | 10.646 | 3.823 | **2.760** | 4.628 | | Korean | 1.747 | 1.865 | 1.755 | **1.180** | 1.962 | | Polish | 1.415 | **0.766** | – | 1.260 | 1.141 | | Portuguese | 1.877 | 1.331 | 1.526 | **1.140** | 1.938 | | Romanian | 2.878 | **1.347** | – | 10.740 | 21.577 | | Russian | 4.281 | 3.878 | 3.212 | **2.400** | 3.634 | | Spanish | 1.029 | 1.084 | 1.126 | **0.910** | 1.438 | | Thai | 2.701 | 73.936 | – | 4.230 | 2.961 | | Turkish | 1.52 | 0.699 | – | 0.870 | 0.817 | | Ukrainian | 1.082 | **0.997** | – | 2.300 | 6.316 | | Vietnamese | **0.88** | 73.415 | – | 7.410 | 3.307 |

Minimax-MLS-test SIM(⬆) 结果（点击展开）

| Language | Minimax | ElevenLabs | Qwen3-TTS | FishAudio S2 | **VoxCPM2** | |----------|:-------:|:----------:|:--------------------:|:------------:|:-----------:| | Arabic | 73.6 | 70.6 | – | 75.0 | **79.1** | | Cantonese | 77.8 | 67.0 | – | 80.5 | **83.5** | | Chinese | 78.0 | 67.7 | 79.9 | 81.6 | **82.5** | | Czech | 79.6 | 68.5 | – | **79.8** | 78.3 | | Dutch | 73.8 | 68.0 | – | 73.0 | **80.8** | | English | 75.6 | 61.3 | 77.5 | 79.7 | **85.4** | | Finnish | 83.5 | 75.9 | – | 81.9 | **89.0** | | French | 62.8 | 53.5 | 62.8 | 69.8 | **73.5** | | German | 73.3 | 61.4 | 77.5 | 76.7 | **80.3** | | Greek | 82.6 | 73.3 | – | 79.5 | **86.0** | | Hindi | 81.8 | 73.0 | – | 82.1 | **85.6** | | Indonesian | 72.9 | 66.0 | – | 76.3 | **80.0** | | Italian | 69.9 | 57.9 | 81.7 | 74.7 | **78.0** | | Japanese | 77.6 | 73.8 | 78.8 | 79.6 | **82.8** | | Korean | 77.6 | 70.0 | 79.9 | 81.7 | **83.3** | | Polish | 80.2 | 72.9 | – | 81.9 | **88.4** | | Portuguese | 80.5 | 71.1 | 81.7 | 78.1 | **83.7** | | Romanian | **80.9** | 69.9 | – | 73.3 | 79.7 | | Russian | 76.1 | 67.6 | 79.2 | 79.0 | **81.1** | | Spanish | 76.2 | 61.5 | 81.4 | 77.6 | **83.1** | | Thai | 80.0 | 58.8 | – | 78.6 | **84.0** | | Turkish | 77.9 | 59.6 | – | 83.5 | **87.1** | | Ukrainian | 73.0 | 64.7 | – | 74.7 | **79.8** | | Vietnamese | 74.3 | 36.9 | – | 74.0 | **80.6** |

Internal 30-Language ASR Benchmark

我们额外进行了内部多语言可懂度评测：30 语种 × 500 样本，ASR 转写评估使用 Gemini 3.1 Flash Lite API。

内部30语种评测集ASR结果（点击展开）

| 语言 | 指标 | VoxCPM2 | Fish S2-Pro | |---|---:|---:|---:| | ar (阿拉伯语) | CER | 1.23% | 0.30% | | da (丹麦语) | WER | 2.70% | 3.52% | | de (德语) | WER | 0.96% | 0.64% | | el (希腊语) | WER | 3.17% | 4.61% | | en (英语) | WER | 0.42% | 1.03% | | es (西班牙语) | WER | 1.33% | 0.64% | | fi (芬兰语) | WER | 2.24% | 2.80% | | fr (法语) | WER | 2.16% | 2.34% | | he (希伯来语) | CER | 2.98% | 15.27% | | hi (印地语) | CER | 0.79% | 0.91% | | id (印尼语) | WER | 1.36% | 1.68% | | it (意大利语) | WER | 1.65% | 1.08% | | ja (日语) | CER | 2.40% | 1.82% | | km (高棉语) | CER | 2.05% | 75.15% | | ko (韩语) | CER | 0.95% | 0.29% | | lo (老挝语) | CER | 1.90% | 87.40% | | ms (马来语) | WER | 1.75% | 1.41% | | my (缅甸语) | CER | 1.42% | 85.27% | | nl (荷兰语) | WER | 1.25% | 1.68% | | no (挪威语) | WER | 2.49% | 3.76% | | pl (波兰语) | WER | 1.90% | 1.65% | | pt (葡萄牙语) | WER | 1.48% | 1.49% | | ru (俄语) | WER | 0.90% | 0.86% | | sv (瑞典语) | WER | 2.22% | 2.63% | | sw (斯瓦希里语) | CER | 1.07% | 2.02% | | th (泰语) | CER | 0.94% | 1.92% | | tl (菲律宾语) | WER | 2.63% | 4.00% | | tr (土耳其语) | WER | 1.65% | 1.65% | | vi (越南语) | WER | 1.56% | 5.56% | | zh (中文) | CER | 0.92% | 1.02% | | 平均（30 语种） | | **1.68%** | - |

InstructTTSEval

指令驱动音色设计结果 (点击展开)

| Model | InstructTTSEval-ZH | | | InstructTTSEval-EN | | | |-------|:---:|:----:|:----:|:----:|:----:|:----:| | | APS⬆| DSD⬆ | RP⬆| APS⬆ | DSD⬆ | RP⬆ | | Hume | – | – | – | 83.0 | 75.3 | 54.3 | | VoxInstruct | 47.5 | 52.3 | 42.6 | 54.9 | 57.0 | 39.3 | | Parler-tts-mini | – | – | – | 63.4 | 48.7 | 28.6 | | Parler-tts-large | – | – | – | 60.0 | 45.9 | 31.2 | | PromptTTS | – | – | – | 64.3 | 47.2 | 31.4 | | PromptStyle | – | – | – | 57.4 | 46.4 | 30.9 | | VoiceSculptor | 75.7 | 64.7 | 61.5 | – | – | – | | Mimo-Audio-7B-Instruct | 75.7 | 74.3 | 61.5 | 80.6 | 77.6 | 59.5 | | Qwen3TTS-12Hz-1.7B-VD | **85.2** | **81.1** | **65.1** | 82.9 | 82.4 | 68.4 | | **VoxCPM2** | **85.2** | 71.5 | 60.8 | **84.2** | **83.2** | **71.4** |

⚙️ 微调

VoxCPM 支持全参数微调（SFT） 和 LoRA 微调。仅需 5-10分钟 的音频数据，即可适配特定说话人、语言或领域。

# LoRA 微调（参数高效，推荐）
python scripts/train_voxcpm_finetune.py \
    --config_path conf/voxcpm_v2/voxcpm_finetune_lora.yaml

# 全参数微调
python scripts/train_voxcpm_finetune.py \
    --config_path conf/voxcpm_v2/voxcpm_finetune_all.yaml

# WebUI 训练与推理
python lora_ft_webui.py   # 然后打开 http://localhost:7860

完整指南 → 微调文档（数据准备、配置、训练、LoRA 热切换、常见问题）

📚 文档

完整文档：voxcpm.readthedocs.io

主题	链接
快速开始与安装	快速开始
使用指南与 Cookbook	使用指南
VoxCPM 系列模型	模型列表
微调（SFT & LoRA）	微调指南
常见问题	FAQ

🌟 生态与社区

项目	说明
Nano-vLLM	高吞吐快速 GPU 推理引擎
VoxCPM.cpp	GGML/GGUF：CPU、CUDA、Vulkan 推理
VoxCPM-ONNX	ONNX 导出，支持 CPU 推理
VoxCPMANE	Apple Neural Engine 后端
voxcpm_rs	Rust 重新实现
ComfyUI-VoxCPM	ComfyUI 节点工作流
ComfyUI-VoxCPMTTS	ComfyUI TTS 扩展
TTS WebUI	浏览器端 TTS 扩展

完整生态见文档。社区项目非 OpenBMB 官方维护。做了什么有趣的东西？提 Issue 或 PR 把它加进来！

⚠️ 风险与局限性

滥用风险： VoxCPM 的声音克隆能力可生成高度逼真的合成语音。严禁将 VoxCPM 用于冒充他人、欺诈或虚假信息传播。我们强烈建议对所有 AI 生成的内容进行明确标注。
可控生成稳定性： 音色设计和可控声音克隆的结果可能因生成次数而异 — 建议尝试生成 1~3 次以获得理想的音色或风格。我们正在积极提升可控性的一致性。
语言覆盖： VoxCPM2 官方支持 30 种语言。对于未列入的语言，欢迎直接测试或使用自有数据进行微调。我们计划在未来版本中扩展语言覆盖。
使用说明： 本模型基于 Apache-2.0 协议发布。用于生产部署时，我们建议针对具体场景进行充分的测试和安全评估。

📖 引用

如果 VoxCPM 对您有帮助，请考虑引用我们的工作并为仓库加星 ⭐！

@article{voxcpm2_2026,
  title   = {VoxCPM2: Tokenizer-Free TTS for Multilingual Speech Generation, Creative Voice Design, and True-to-Life Cloning},
  author  = {VoxCPM Team},
  journal = {GitHub},
  year    = {2026},
}

@article{voxcpm2025,
  title   = {VoxCPM: Tokenizer-Free TTS for Context-Aware Speech Generation
             and True-to-Life Voice Cloning},
  author  = {Zhou, Yixuan and Zeng, Guoyang and Liu, Xin and Li, Xiang and
             Yu, Renjie and Wang, Ziyang and Ye, Runchuan and Sun, Weiyue and
             Gui, Jiancheng and Li, Kehan and Wu, Zhiyong and Liu, Zhiyuan},
  journal = {arXiv preprint arXiv:2509.24650},
  year    = {2025},
}

📄 许可证

VoxCPM 模型权重和代码基于 Apache-2.0 协议开源。

🙏 致谢

DiTAR 扩散自回归骨干架构
MiniCPM-4 语言模型基座
CosyVoice 基于 Flow Matching 的 LocDiT 实现
DAC Audio VAE 骨干
感谢所有社区用户试用 VoxCPM、反馈问题、分享想法和贡献——你们的支持让项目持续进步

机构

面壁智能清华大学人机交互实验室

⭐ Star 历史

参考资料

VoxCPM2
参考资料

SimpleMem 高效的 LLM 智能体终身记忆系统 — Text & Multimodal

Thu, 09 Apr 2026 13:01:55 +0000

Memos

开源、自托管的笔记工具，专为快速记录而生。原生支持 Markdown，轻量级，完全由你掌控。

💎 特别赞助

Warp —— 为速度和协作而生的 AI 驱动终端

TestMu AI - 全球首个全栈 Agentic AI 质量工程平台

SSD Nodes - 为自托管用户提供经济实惠的 VPS 托管服务

功能特性

即时记录 — 以时间线为核心的 UI。打开、书写、完成 —— 无需浏览文件夹。
完全数据归属 — 在你的基础设施上自托管。笔记以 Markdown 格式存储，始终可迁移。零遥测。
极致简单 — 单个 Go 二进制文件，约 20MB 的 Docker 镜像。一条命令即可部署，支持 SQLite、MySQL 或 PostgreSQL。
开放且可扩展 — MIT 许可，提供完整的 REST 和 gRPC API 用于集成。

快速开始

Docker（推荐）

docker run -d \
  --name memos \
  -p 5230:5230 \
  -v ~/.memos:/var/opt/memos \
  neosmemo/memos:stable

打开 http://localhost:5230 即可开始记录！

原生二进制

curl -fsSL https://raw.githubusercontent.com/usememos/memos/main/scripts/install.sh | sh

试用在线演示

还不打算安装？先试试我们的在线演示吧！

其他安装方式

Docker Compose - 推荐用于生产环境部署
预编译二进制文件 - 支持 Linux、macOS 和 Windows
Kubernetes - 提供 Helm charts 和清单文件
从源码构建 - 用于开发和定制

详细说明请参阅我们的安装指南。

贡献

欢迎各类贡献 —— 错误报告、功能建议、拉取请求、文档和翻译。

赞助商

喜欢 Memos？在 GitHub 上赞助我们，帮助项目持续成长！

Star 历史

许可证

Memos 是开源软件，基于 MIT 许可证发布。有关数据处理的详细信息，请参阅我们的隐私政策。

网站 • 文档 • 演示 • Discord • X/Twitter

参考资料

Memos
参考资料

SimpleMem 高效的 LLM 智能体终身记忆系统 — Text & Multimodal

Thu, 09 Apr 2026 13:01:55 +0000

## 高效的 LLM 智能体终身记忆系统 — Text & Multimodal 通过语义无损压缩实现长期记忆的存储、压缩和检索。支持 Claude、Cursor、LM Studio 等多种平台。

兼容任何支持 MCP 或 Python 集成的 AI 平台

_{Claude Desktop}

_Cursor

_{LM Studio}

_{Cherry Studio}

_{PyPI 包}

_{+ 任何 MCP
客户端}

[🇨🇳 **中文**](./README.zh-CN.md) • [🇯🇵 日本語](./README.ja.md) • [🇰🇷 한국어](./README.ko.md) • [🇪🇸 Español](./README.es.md) • [🇫🇷 Français](./README.fr.md) • [🇩🇪 Deutsch](./README.de.md) • [🇧🇷 Português](./README.pt-br.md)
[🇷🇺 Русский](./README.ru.md) • [🇸🇦 العربية](./README.ar.md) • [🇮🇹 Italiano](./README.it.md) • [🇻🇳 Tiếng Việt](./README.vi.md) • [🇹🇷 Türkçe](./README.tr.md)
[![Project Page](https://img.shields.io/badge/🎬_互动演示-访问官网-FF6B6B?style=for-the-badge&labelColor=FF6B6B&color=4ECDC4&logoColor=white)](https://aiming-lab.github.io/SimpleMem-Page)

[概述](#-概述) • [快速开始](#-快速开始) • [MCP 服务器](#-mcp-服务器) • [评测](#-评测) • [引用](#-引用)

🔥 最新动态

[02/09/2026] 🚀 跨对话记忆功能上线 - 性能超越 Claude-Mem 64%！ SimpleMem 现已支持跨对话的持久化记忆。在 LoCoMo 基准测试中，SimpleMem 相比 Claude-Mem 实现了 64% 的性能提升。您的 Agent 现在可以自动回忆之前对话中的上下文、决策和学习成果。查看跨对话记忆文档 →
[01/20/2026] SimpleMem 已上线 PyPI！ 📦 可直接通过 pip install simplemem 安装。查看包使用指南 →
[01/19/2026] SimpleMem Skill 新增本地记忆存储功能！ 💾 现已支持在 Claude Skills 中进行本地记忆存储与管理。
[01/18/2026] SimpleMem 现已支持 Claude Skills！ 🚀 在 claude.ai 中使用 SimpleMem 实现跨会话长期记忆。前往 mcp.simplemem.cloud 注册，配置令牌后导入技能即可使用！
[01/14/2026] SimpleMem MCP 服务器正式上线并开源！ 🎉 云端记忆服务已部署至 mcp.simplemem.cloud。支持 LM Studio、Cherry Studio、Cursor、Claude Desktop，通过 Streamable HTTP MCP 协议集成。查看 MCP 文档 →
[01/08/2026] 🔥 欢迎加入我们的 Discord 和微信交流群，一起协作交流！
[01/05/2026] SimpleMem 论文已在 arXiv 发布！

🌟 概述

*SimpleMem 以最少的 token 开销（约 550）实现了最优的 F1 分数（43.24%），占据理想的左上方位置。*

SimpleMem 是一个基于语义无损压缩的高效记忆框架，旨在解决 LLM 智能体高效长期记忆这一核心挑战。与现有系统被动积累冗余上下文或依赖昂贵迭代推理循环不同，SimpleMem 通过三阶段流水线最大化信息密度和 token 利用率：

### 🔍 阶段 1 **语义结构化压缩** 将非结构化交互蒸馏为紧凑的多视角索引记忆单元

### 🗂️ 阶段 2 **在线语义合成** 会话内过程，即时整合相关上下文为统一的抽象表示，消除冗余

### 🎯 阶段 3 **意图感知检索规划** 推断搜索意图，动态确定检索范围，高效构建精确上下文

*SimpleMem 架构：(1) 语义结构化压缩过滤低效对话，将信息窗口转换为紧凑、上下文无关的记忆单元。(2) 在线语义合成在写入阶段整合相关片段，维护紧凑连贯的记忆拓扑。(3) 意图感知检索规划推断搜索意图以调整检索范围和查询形式，实现并行多视角检索和高效 token 上下文构建。*

🏆 性能对比

**速度对比演示** *SimpleMem 与基线方法：实时速度对比演示*

**LoCoMo-10 基准测试结果（GPT-4.1-mini）** | 模型 | ⏱️ 构建时间 | 🔎 检索时间 | ⚡ 总时间 | 🎯 平均 F1 | |:------|:--------------------:|:-----------------:|:-------------:|:-------------:| | A-Mem | 5140.5s | 796.7s | 5937.2s | 32.58% | | LightMem | 97.8s | 577.1s | 675.9s | 24.63% | | Mem0 | 1350.9s | 583.4s | 1934.3s | 34.20% | | **SimpleMem** ⭐ | **92.6s** | **388.3s** | **480.9s** | **43.24%** |

💡 核心优势：

🏆 最高 F1 分数：43.24%（比 Mem0 高 26.4%，比 LightMem 高 75.6%）

⚡ 最快检索速度：388.3s（比 LightMem 快 32.7%，比 Mem0 快 51.3%）

🚀 最快端到端处理：总处理时间 480.9s（比 A-Mem 快 12.5 倍）

🎯 主要贡献

1️⃣ 语义结构化压缩

SimpleMem 在 LLM 生成过程中集成了隐式语义密度门控机制，过滤冗余交互内容。系统将原始对话流重新组织为紧凑的记忆单元——带有已消解指代和绝对时间戳的独立事实。每个单元通过三种互补表示进行索引，支持灵活检索：

| 🔍 层级 | 📊 类型 | 🎯 用途 | 🛠️ 实现 | |---------|---------|------------|-------------------| | **语义** | 稠密 | 概念相似性 | 向量嵌入（1024 维） | | **词汇** | 稀疏 | 精确词项匹配 | BM25 风格关键词索引 | | **符号** | 元数据 | 结构化过滤 | 时间戳、实体、人物 |

✨ 转换示例：

- 输入：  "他明天下午2点和Bob见面"  [❌ 相对的、模糊的]
+ 输出： "Alice将于2025-11-16T14:00:00在星巴克与Bob见面"  [✅ 绝对的、原子的]

2️⃣ 在线语义合成

与依赖异步后台维护的传统系统不同，SimpleMem 在写入阶段即时执行合成。在当前会话范围内，相关记忆单元被合成为更高级的抽象表示，使重复或结构相似的经验能够立即被去噪和压缩。

✨ 合成示例：

- 片段 1: "用户想喝咖啡"
- 片段 2: "用户偏好燕麦奶"
- 片段 3: "用户喜欢热饮"
+ 整合后: "用户偏好加燕麦奶的热咖啡"

这种主动合成确保记忆拓扑保持紧凑，避免冗余碎片化。

3️⃣ 意图感知检索规划

与固定深度检索不同，SimpleMem 利用 LLM 的推理能力生成全面的检索计划。给定查询后，规划模块推断潜在搜索意图，动态确定检索范围和深度：

\[\{ q_{\text{sem}}, q_{\text{lex}}, q_{\text{sym}}, d \} \sim \mathcal{P}(q, H)\]

系统随后在语义、词汇和符号索引上执行并行多视角检索，并通过基于 ID 的去重合并结果：

**🔹 简单查询** - 通过单个记忆单元直接查找事实 - 最小检索深度 - 快速响应

**🔸 复杂查询** - 跨多个事件聚合 - 扩展检索深度 - 全面覆盖

📈 结果：以比全上下文方法少 30 倍的 token 达到 43.24% 的 F1 分数。

🚀 性能亮点

📊 基准测试结果（LoCoMo）

🔬 高性能模型（GPT-4.1-mini）

| 任务类型 | SimpleMem F1 | Mem0 F1 | 提升 | |:----------|:------------:|:-------:|:-----------:| | **多跳** | 43.46% | 30.14% | **+43.8%** | | **时序** | 58.62% | 48.91% | **+19.9%** | | **单跳** | 51.12% | 41.3% | **+23.8%** |

⚙️ 高效模型（Qwen2.5-1.5B）

| 指标 | SimpleMem | Mem0 | 备注 | |:-------|:---------:|:----:|:------| | **平均 F1** | 25.23% | 23.77% | 使用小 99 倍的模型仍具竞争力 |

📦 安装

📝 初次使用须知

确保活动环境中使用的是 Python 3.10，而非仅全局安装。
运行任何记忆构建或检索之前，必须先配置 OpenAI 兼容的 API 密钥，否则初始化可能失败。
使用非 OpenAI 提供商（如 Qwen 或 Azure OpenAI）时，请验证 config.py 中的模型名称和 OPENAI_BASE_URL。
对于大型对话数据集，启用并行处理可显著减少记忆构建时间。

📋 环境要求

🐍 Python 3.10
🔑 OpenAI 兼容 API（OpenAI、Qwen、Azure OpenAI 等）

🛠️ 安装步骤

# 📥 克隆仓库
git clone https://github.com/aiming-lab/SimpleMem.git
cd SimpleMem

# 📦 安装依赖
pip install -r requirements.txt

# ⚙️ 配置 API 设置
cp config.py.example config.py
# 编辑 config.py，填入你的 API 密钥和偏好设置

⚙️ 配置示例

# config.py
OPENAI_API_KEY = "your-api-key"
OPENAI_BASE_URL = None  # 或 Qwen/Azure 的自定义端点

LLM_MODEL = "gpt-4.1-mini"
EMBEDDING_MODEL = "Qwen/Qwen3-Embedding-0.6B"  # 最先进的检索模型

⚡ 快速开始

🧠 理解基本工作流

从宏观层面来看，SimpleMem 是 LLM 智能体的长期记忆系统。工作流程包含三个简单步骤：

存储信息 – 对话或事实经处理后转换为结构化的原子记忆。
索引记忆 – 使用语义嵌入和结构化元数据组织已存储的记忆。
检索相关记忆 – 查询时，SimpleMem 基于语义（而非关键词）检索最相关的存储信息。

这种设计使 LLM 智能体能够维护上下文、高效回忆过往信息，并避免重复处理冗余历史。

🎓 基本用法

from main import SimpleMemSystem

# 🚀 初始化系统
system = SimpleMemSystem(clear_db=True)

# 💬 添加对话（阶段 1：语义结构化压缩）
system.add_dialogue("Alice", "Bob，我们明天下午2点在星巴克见面吧", "2025-11-15T14:30:00")
system.add_dialogue("Bob", "好的，我会带上市场分析报告", "2025-11-15T14:31:00")

# ✅ 完成原子编码
system.finalize()

# 🔎 意图感知检索查询（阶段 3：意图感知检索规划）
answer = system.ask("Alice 和 Bob 什么时候在哪里见面？")
print(answer)
# 输出: "2025年11月16日下午2:00在星巴克"

🚄 进阶：并行处理

对于大规模对话处理，启用并行模式：

system = SimpleMemSystem(
    clear_db=True,
    enable_parallel_processing=True,  # ⚡ 并行记忆构建
    max_parallel_workers=8,
    enable_parallel_retrieval=True,   # 🔍 并行查询执行
    max_retrieval_workers=4
)

💡 小贴士：并行处理可显著降低批量操作的延迟！

❓ 常见问题与故障排查

在首次安装或运行 SimpleMem 时遇到问题，请检查以下常见情况：

1️⃣ API 密钥未检测到

确保 config.py 中正确设置了 API 密钥
使用 OpenAI 兼容提供商（Qwen、Azure 等）时，验证 OPENAI_BASE_URL 配置是否正确
更新密钥后重启 Python 环境

2️⃣ Python 版本不匹配

SimpleMem 需要 Python 3.10
检查版本：
```
python --version
```

# 🧠 Omni-SimpleMem: Multimodal Memory **NEW** — SimpleMem now handles text, image, audio & video.

📈 +411%
_{LoCoMo F1}

📈 +214%
_{Mem-Gallery F1}

⚡ 5.81 q/s
_{3.5x faster}

🧠 4 modalities
_{Text · Image · Audio · Video}

📖 Full documentation: Omni-SimpleMem →

🔌 MCP 服务器 (text memory)

SimpleMem 作为云端记忆服务，通过模型上下文协议（MCP）提供，支持与 Claude Desktop、Cursor 等 AI 助手无缝集成。

🌐 云服务：mcp.simplemem.cloud

核心特性

特性	描述
Streamable HTTP	MCP 2025-03-26 协议，JSON-RPC 2.0
多租户隔离	基于令牌认证的用户级数据表
混合检索	语义搜索 + 关键词匹配 + 元数据过滤
生产级优化	集成 OpenRouter，响应更快

快速配置

{
  "mcpServers": {
    "simplemem": {
      "url": "https://mcp.simplemem.cloud/mcp",
      "headers": {
        "Authorization": "Bearer YOUR_TOKEN"
      }
    }
  }
}

📖 详细的安装说明和自部署指南，请参阅 MCP 文档

🗺️ 路线图

📊 评测

🧪 运行基准测试

# 🎯 完整 LoCoMo 基准测试
python test_locomo10.py

# 📉 子集评测（5 个样本）
python test_locomo10.py --num-samples 5

# 💾 自定义输出文件
python test_locomo10.py --result-file my_results.json

🔬 复现论文结果

使用 config.py 中的精确配置：

🚀 高性能：GPT-4.1-mini、Qwen3-Plus
⚙️ 高效率：Qwen2.5-1.5B、Qwen2.5-3B
🔍 嵌入模型：Qwen3-Embedding-0.6B（1024 维）

📝 引用

如果您在研究中使用了 SimpleMem，请引用：

@article{simplemem2025,
  title={SimpleMem: Efficient Lifelong Memory for LLM Agents},
  author={Liu, Jiaqi and Su, Yaofeng and Xia, Peng and Zhou, Yiyang and Han, Siwei and  Zheng, Zeyu and Xie, Cihang and Ding, Mingyu and Yao, Huaxiu},
  journal={arXiv preprint arXiv:2601.02553},
  year={2025},
  url={https://github.com/aiming-lab/SimpleMem}
}

📄 许可证

本项目采用 MIT 许可证 - 详见 LICENSE 文件。

🙏 致谢

感谢以下项目和团队的贡献：

🔍 嵌入模型：Qwen3-Embedding - 最先进的检索性能
🗄️ 向量数据库：LanceDB - 高性能列式存储
📊 基准测试：LoCoMo - 长上下文记忆评测框架

参考资料

🔥 最新动态
📑 目录
🌟 概述
- 🏆 性能对比
🎯 主要贡献
🚀 性能亮点
- 📊 基准测试结果（LoCoMo）
📦 安装
⚡ 快速开始
❓ 常见问题与故障排查
- 1️⃣ API 密钥未检测到
- 2️⃣ Python 版本不匹配
🔌 MCP 服务器 (text memory)
- 核心特性
- 快速配置
🗺️ 路线图
📊 评测
- 🧪 运行基准测试
- 🔬 复现论文结果
📝 引用
📄 许可证
🙏 致谢
参考资料

OpenDataLoader PDF 面向AI就绪数据的PDF解析器。自动化PDF无障碍。开源。

Thu, 09 Apr 2026 13:01:55 +0000

OpenDataLoader PDF

面向AI就绪数据的PDF解析器。自动化PDF无障碍。开源。

🔍 面向AI数据提取的PDF解析器 — 从任意PDF中提取Markdown、JSON（含边界框）和HTML。基准测试第一（整体0.907）。确定性本地模式 + AI混合模式用于复杂页面。

准确度有多高？ — 基准测试第一：整体0.907，表格准确率0.928（涵盖200个真实世界PDF，包括多栏和科学论文）。确定性本地模式 + AI混合模式用于复杂页面（基准测试）
支持扫描件PDF和OCR吗？ — 支持。混合模式内置OCR（80+种语言），适用于300 DPI以上的低质量扫描件（混合模式）
支持表格、公式、图片、图表吗？ — 支持。复杂/无框表格、LaTeX公式、AI生成的图片/图表描述，均可通过混合模式实现（混合模式）

如何用于RAG？ — pip install opendataloader-pdf，三行代码完成转换。输出结构化的Markdown用于分块，带边界框的JSON用于来源引用，以及HTML。提供LangChain集成。Python、Node.js、Java SDK（快速开始 LangChain）

♿ PDF无障碍自动化 — 同样的布局分析引擎也支持自动标记。首个端到端生成Tagged PDF的开源工具（预计2026年Q2推出）。

解决了什么问题？ — 无障碍法规已在全球强制执行。手动修复PDF成本为每份文档$50–200，无法规模化（法规）
哪些功能免费？ — 布局分析 + 自动标记（2026年Q2，Apache 2.0许可证）。未标记PDF输入 → Tagged PDF输出。不依赖专有SDK（自动标记预览）
PDF/UA合规呢？ — 将Tagged PDF转换为PDF/UA-1或PDF/UA-2是企业插件。自动标记生成Tagged PDF；PDF/UA导出是最后一步（流水线）
为何值得信赖？ — 与PDF协会及Dual Lab（veraPDF开发者）合作构建。自动标记遵循Well-Tagged PDF规范，并通过veraPDF验证（合作详情）

30秒快速开始

要求：Java 11+ 和 Python 3.10+（Node.js

Java 版本也可用）

开始前：运行 java -version。如果未找到，请从 Adoptium 安装 JDK 11+。

pip install -U opendataloader-pdf

import opendataloader_pdf

# 一次调用中批量处理所有文件 — 每次convert()都会启动一个JVM进程，重复调用会很慢
opendataloader_pdf.convert(
    input_path=["file1.pdf", "file2.pdf", "folder/"],
    output_dir="output/",
    format="markdown,json"
)

带标注的PDF输出 — 每个元素（标题、段落、表格、图片）都被检测，并带有边界框和语义类型。

解决了哪些问题？

问题	解决方案	状态
解析时PDF结构丢失 — 阅读顺序错误、表格断裂、无元素坐标	确定性的本地PDF转Markdown/JSON，带边界框，XY-Cut++阅读顺序	已发布
复杂表格、扫描件PDF、公式、图表需要AI级别的理解	混合模式将复杂页面路由到AI后端（基准测试第一）	已发布
PDF无障碍合规 — EAA、ADA、Section 508强制执行。手动修复$50–200/文档	自动标记：布局分析 → Tagged PDF（免费，2026年Q2）。与PDF协会合作开发，通过veraPDF验证。PDF/UA导出（企业插件）	自动标记：2026年Q2

功能矩阵

功能	支持情况	层级
数据提取
提取文本并保持正确阅读顺序	支持	免费
每个元素带边界框	支持	免费
表格提取（简单边框）	支持	免费
表格提取（复杂/无边框）	支持	免费（混合模式）
标题层级检测	支持	免费
列表检测（编号、项目符号、嵌套）	支持	免费
图片提取及坐标	支持	免费
AI图表/图片描述	支持	免费（混合模式）
扫描件PDF的OCR	支持	免费（混合模式）
公式提取（LaTeX）	支持	免费（混合模式）
Tagged PDF结构提取	支持	免费
AI安全（提示注入过滤）	支持	免费
页眉/页脚/水印过滤	支持	免费
无障碍
为未标记PDF自动标记 → Tagged PDF	预计2026年Q2	免费（Apache 2.0）
PDF/UA-1, PDF/UA-2导出	💼 可用	企业版
无障碍工作室（可视化编辑器）	💼 可用	企业版
限制
处理Word/Excel/PPT	不支持	—
需要GPU	不需要	—

提取基准测试

opendataloader-pdf [混合模式] 整体准确率排名第一（0.907），涵盖阅读顺序、表格和标题提取准确率。

引擎	整体	阅读顺序	表格	标题	速度（秒/页）
opendataloader [混合]	0.907	0.934	0.928	0.821	0.463
docling	0.882	0.898	0.887	0.824	0.762
nutrient	0.880	0.924	0.662	0.811	0.230
marker	0.861	0.890	0.808	0.796	53.932
unstructured [hi_res]	0.841	0.904	0.588	0.749	3.008
edgeparse	0.837	0.894	0.717	0.706	0.036
opendataloader	0.831	0.902	0.489	0.739	0.015
mineru	0.831	0.857	0.873	0.743	5.962
pymupdf4llm	0.732	0.885	0.401	0.412	0.091
unstructured	0.686	0.882	0.000	0.388	0.077
markitdown	0.589	0.844	0.273	0.000	0.114
liteparse	0.576	0.866	0.000	0.000	1.061

分数归一化到[0, 1]。准确率越高越好；速度越低越好。粗体 = 最佳。完整基准测试详情

应该使用哪种模式？

你的文档	模式	安装命令	服务器命令	客户端命令
标准数字PDF	快速（默认）	`pip install opendataloader-pdf`	无需	`opendataloader-pdf file1.pdf file2.pdf folder/`
复杂或嵌套表格	混合模式	`pip install "opendataloader-pdf[hybrid]"`	`opendataloader-pdf-hybrid --port 5002`	`opendataloader-pdf --hybrid docling-fast file1.pdf file2.pdf folder/`
扫描/图片型PDF	混合模式 + OCR	`pip install "opendataloader-pdf[hybrid]"`	`opendataloader-pdf-hybrid --port 5002 --force-ocr`	`opendataloader-pdf --hybrid docling-fast file1.pdf file2.pdf folder/`
非英语扫描PDF	混合模式 + OCR	`pip install "opendataloader-pdf[hybrid]"`	`opendataloader-pdf-hybrid --port 5002 --force-ocr --ocr-lang "ko,en"`	`opendataloader-pdf --hybrid docling-fast file1.pdf file2.pdf folder/`
数学公式	混合模式 + 公式	`pip install "opendataloader-pdf[hybrid]"`	`opendataloader-pdf-hybrid --enrich-formula`	`opendataloader-pdf --hybrid docling-fast --hybrid-mode full file1.pdf file2.pdf folder/`
需要描述的图表	混合模式 + 图片	`pip install "opendataloader-pdf[hybrid]"`	`opendataloader-pdf-hybrid --enrich-picture-description`	`opendataloader-pdf --hybrid docling-fast --hybrid-mode full file1.pdf file2.pdf folder/`
需要无障碍的未标记PDF	自动标记 → Tagged PDF	预计2026年Q2	—	—

快速开始

Python

pip install -U opendataloader-pdf

import opendataloader_pdf

# 一次调用中批量处理所有文件 — 每次convert()都会启动一个JVM进程，重复调用会很慢
opendataloader_pdf.convert(
    input_path=["file1.pdf", "file2.pdf", "folder/"],
    output_dir="output/",
    format="markdown,json"
)

Node.js

npm install @opendataloader/pdf

import { convert } from '@opendataloader/pdf';

await convert(['file1.pdf', 'file2.pdf', 'folder/'], {
  outputDir: 'output/',
  format: 'markdown,json'
});

Java

<dependency>
  <groupId>org.opendataloader</groupId>
  <artifactId>opendataloader-pdf-core</artifactId>
</dependency>

Python快速开始

Node.js快速开始

Java快速开始

混合模式：复杂PDF的#1准确率

混合模式结合了快速的本地Java处理与AI后端。简单页面在本地处理（0.02秒/页）；复杂页面路由到AI后端，表格准确率提升至+90%。

pip install -U "opendataloader-pdf[hybrid]"

终端1 — 启动后端服务器：

opendataloader-pdf-hybrid --port 5002

终端2 — 处理PDF：

# 一次调用中批量处理所有文件 — 每次调用都会启动一个JVM进程，重复调用会很慢
opendataloader-pdf --hybrid docling-fast file1.pdf file2.pdf folder/

Python：

# 一次调用中批量处理所有文件 — 每次convert()都会启动一个JVM进程，重复调用会很慢
opendataloader_pdf.convert(
    input_path=["file1.pdf", "file2.pdf", "folder/"],
    output_dir="output/",
    hybrid="docling-fast"
)

扫描件PDF的OCR

对于基于图片的PDF（无可选文本），使用 --force-ocr 启动后端：

opendataloader-pdf-hybrid --port 5002 --force-ocr

对于非英文文档，指定语言：

opendataloader-pdf-hybrid --port 5002 --force-ocr --ocr-lang "ko,en"

支持的语言：en, ko, ja, ch_sim, ch_tra, de, fr, ar 等。

公式提取（LaTeX）

从科学PDF中提取数学公式为LaTeX：

# 服务器端：启用公式增强
opendataloader-pdf-hybrid --enrich-formula

# 一次调用中批量处理所有文件 — 每次调用都会启动一个JVM进程，重复调用会很慢
opendataloader-pdf --hybrid docling-fast --hybrid-mode full file1.pdf file2.pdf folder/

JSON输出示例：

{
  "type": "formula",
  "page number": 1,
  "bounding box": [226.2, 144.7, 377.1, 168.7],
  "content": "\\frac{f(x+h) - f(x)}{h}"
}

注意：公式和图片描述增强需要客户端指定 --hybrid-mode full。

图表与图片描述

为图表和图片生成AI描述 — 适用于RAG搜索和无障碍替代文本：

# 服务器端
opendataloader-pdf-hybrid --enrich-picture-description

# 一次调用中批量处理所有文件 — 每次调用都会启动一个JVM进程，重复调用会很慢
opendataloader-pdf --hybrid docling-fast --hybrid-mode full file1.pdf file2.pdf folder/

JSON输出示例：

{
  "type": "picture",
  "page number": 1,
  "bounding box": [72.0, 400.0, 540.0, 650.0],
  "description": "A bar chart showing waste generation by region from 2016 to 2030..."
}

使用轻量级视觉模型SmolVLM（256M）。通过 --picture-description-prompt 支持自定义提示词。

Hancom Data Loader集成 — 即将推出

通过 Hancom Data Loader 实现企业级AI文档分析 — 针对您特定领域文档训练的客户定制模型。支持30+种元素类型（表格、图表、公式、标题、脚注等）、基于VLM的图片/图表理解、复杂表格提取（合并单元格、嵌套表格）、带SLA的扫描件OCR，以及原生HWP/HWPX支持。支持PDF、DOCX、XLSX、PPTX、HWP、PNG、JPG。在线演示

混合模式指南

输出格式

格式	使用场景
JSON	带边界框和语义类型的结构化数据
Markdown	用于LLM上下文的纯文本、RAG分块
HTML	带样式的网页展示
带标注的PDF	可视化调试 — 查看检测到的结构（示例）
Text	纯文本提取

组合格式：format="json,markdown"

JSON输出示例

{
  "type": "heading",
  "id": 42,
  "level": "Title",
  "page number": 1,
  "bounding box": [72.0, 700.0, 540.0, 730.0],
  "heading level": 1,
  "font": "Helvetica-Bold",
  "font size": 24.0,
  "text color": "[0.0]",
  "content": "Introduction"
}

字段	描述
`type`	元素类型：heading, paragraph, table, list, image, caption, formula
`id`	用于交叉引用的唯一标识符
`page number`	页码（从1开始）
`bounding box`	`[左, 下, 右, 上]`，单位为PDF点（72点 = 1英寸）
`heading level`	标题深度（1及以上）
`content`	提取的文本

完整JSON Schema

高级功能

Tagged PDF支持

当PDF包含结构标签时，OpenDataLoader会提取作者意图的精确布局 — 无需猜测或启发式。标题、列表、表格和阅读顺序均从源文档中保留。

# 一次调用中批量处理所有文件 — 每次convert()都会启动一个JVM进程，重复调用会很慢
opendataloader_pdf.convert(
    input_path=["file1.pdf", "file2.pdf", "folder/"],
    output_dir="output/",
    use_struct_tree=True           # 使用原生PDF结构标签
)

大多数PDF解析器完全忽略结构标签。了解更多

AI安全：提示注入防护

PDF可能包含隐藏的提示注入攻击。OpenDataLoader自动过滤：

隐藏文本（透明、零号字体）
页面外内容
可疑的不可见层

如需对敏感数据（电子邮件、URL、电话号码 → 占位符）进行脱敏，请显式启用：

# 一次调用中批量处理所有文件 — 每次调用都会启动一个JVM进程，重复调用会很慢
opendataloader-pdf file1.pdf file2.pdf folder/ --sanitize

AI安全指南

LangChain集成

pip install -U langchain-opendataloader-pdf

from langchain_opendataloader_pdf import OpenDataLoaderPDFLoader

loader = OpenDataLoaderPDFLoader(
    file_path=["file1.pdf", "file2.pdf", "folder/"],
    format="text"
)
documents = loader.load()

LangChain文档

GitHub

PyPI

高级选项

# 一次调用中批量处理所有文件 — 每次convert()都会启动一个JVM进程，重复调用会很慢
opendataloader_pdf.convert(
    input_path=["file1.pdf", "file2.pdf", "folder/"],
    output_dir="output/",
    format="json,markdown,pdf",
    image_output="embedded",        # "off", "embedded"（Base64）, 或 "external"（默认）
    image_format="jpeg",            # "png" 或 "jpeg"
    use_struct_tree=True,           # 使用原生PDF结构
)

完整CLI选项参考

PDF无障碍与PDF/UA转换

问题：现有数百万PDF缺乏结构标签，无法满足无障碍法规（EAA、ADA/Section 508、韩国数字包容法）。手动修复每份文档成本$50–200，无法规模化。

OpenDataLoader的方案：与PDF协会及Dual Lab（veraPDF的开发者，veraPDF是行业参考的开源PDF/A和PDF/UA验证器）合作构建。自动标记遵循Well-Tagged PDF规范，并使用veraPDF进行程序化验证 — 自动检查PDF无障碍标准的符合性，而非人工审查。目前没有其他开源工具能够端到端生成Tagged PDF — 大多数依赖专有SDK完成标签写入步骤。OpenDataLoader在Apache 2.0许可证下完成全部工作。（合作详情）

法规	截止日期	要求
欧洲无障碍法案（EAA）	2025年6月28日	欧盟范围内的无障碍数字产品
ADA与Section 508	已生效	美国联邦机构和公共场所
数字包容法	已生效	韩国数字服务无障碍

标准与验证

方面	详情
规范	PDF协会的Well-Tagged PDF
验证	veraPDF — 行业参考的开源PDF/A和PDF/UA验证器
合作	PDF协会 + Dual Lab（veraPDF开发者）共同开发标记和验证
许可证	自动标记 → Tagged PDF：Apache 2.0（免费）。PDF/UA导出：企业版

无障碍流水线

步骤	功能	状态	层级
1. 审计	读取现有PDF标签，检测未标记PDF	已发布	免费
2. 自动标记 → Tagged PDF	为未标记PDF生成结构标签	预计2026年Q2	免费（Apache 2.0）
3. 导出PDF/UA	转换为符合PDF/UA-1或PDF/UA-2的文件	💼 可用	企业版
4. 可视化编辑	无障碍工作室 — 审查和修复标签	💼 可用	企业版

💼 企业功能可按需获取。联系我们开始使用。

自动标记预览（预计2026年Q2）

# API形态预览 — 2026年Q2可用
opendataloader_pdf.convert(
    input_path=["file1.pdf", "file2.pdf", "folder/"],
    output_dir="output/",
    auto_tag=True                   # 为未标记PDF生成结构标签
)

端到端合规工作流

现有PDF（未标记）
    │
    ▼
┌─────────────────┐    ┌─────────────────┐    ┌─────────────────┐    ┌─────────────────┐
│  1. 审计        │───>│  2. 自动标记     │───>│  3. 导出         │───>│  4. 工作室       │
│  （检查标签）    │    │  （→ Tagged PDF） │    │  （PDF/UA）      │    │  （可视化编辑器）│
└─────────────────┘    └─────────────────┘    └─────────────────┘    └─────────────────┘
        │                      │                      │                      │
        ▼                      ▼                      ▼                      ▼
  use_struct_tree         auto_tag              PDF/UA导出         无障碍工作室
  （现已可用）      （2026年Q2, Apache 2.0）    （企业版）            （企业版）

PDF无障碍指南

路线图

功能	时间线	层级
自动标记 → Tagged PDF — 从未标记PDF生成Tagged PDF	2026年Q2	免费
Hancom Data Loader — 企业级AI文档分析、客户定制模型、基于VLM的图表/图片理解、生产级OCR	2026年Q2-Q3	计划中
结构验证 — 验证PDF标签树	2026年Q2	计划中

完整路线图

常见问题

什么是RAG的最佳PDF解析器？

对于RAG流水线，你需要一个能够保留文档结构、保持正确阅读顺序并提供元素坐标用于引用的解析器。OpenDataLoader正是为此设计 — 它输出带边界框的结构化JSON，通过XY-Cut++处理多栏布局，无需GPU即可本地运行。在混合模式下，它在基准测试中整体排名第一（0.907）。

什么是最好的开源PDF解析器？

OpenDataLoader PDF是唯一结合了以下特性的开源解析器：基于规则的确定性提取（无需GPU）、每个元素带边界框、XY-Cut++阅读顺序、内置AI安全过滤器、原生Tagged PDF支持，以及用于复杂文档的混合AI模式。它在整体准确率上排名第一（0.907），同时可在CPU上本地运行。

如何为LLM从PDF中提取表格？

OpenDataLoader通过边界分析和文本聚类检测表格，保留行/列结构。对于复杂表格，启用混合模式可将准确率提升90%以上（TEDS分数从0.489提升至0.928）：

# 一次调用中批量处理所有文件 — 每次convert()都会启动一个JVM进程，重复调用会很慢
opendataloader_pdf.convert(
    input_path=["file1.pdf", "file2.pdf", "folder/"],
    output_dir="output/",
    format="json",
    hybrid="docling-fast"           # 用于复杂表格
)

与docling、marker或pymupdf4llm相比如何？

OpenDataLoader [混合模式] 在阅读顺序、表格和标题准确率上整体排名第一（0.907）。主要差异：docling（0.882）表现不错但缺少边界框和AI安全过滤器。marker（0.861）需要GPU且速度慢1000倍（53.932秒/页）。pymupdf4llm（0.732）速度快但表格（0.401）和标题（0.412）准确率低。OpenDataLoader是唯一结合了确定性本地提取、每个元素带边界框和内置提示注入保护的解析器。查看完整基准测试。

我可以在不将数据发送到云端的情况下使用吗？

可以。OpenDataLoader 100%本地运行。没有API调用，没有数据传输 — 你的文档永远不会离开你的环境。混合模式后端也在你的机器上本地运行。适用于法律、医疗和金融文档。

支持扫描件PDF的OCR吗？

支持，通过混合模式。使用 pip install "opendataloader-pdf[hybrid]" 安装，用 --force-ocr 启动后端，然后照常处理。支持多种语言，包括韩语、日语、中文、阿拉伯语等，通过 --ocr-lang 指定。

支持韩文、日文或中文文档吗？

支持。对于数字PDF，文本提取开箱即用。对于扫描件PDF，使用混合模式并指定 --force-ocr --ocr-lang "ko,en"（或 ja, ch_sim, ch_tra）。即将推出：Hancom Data Loader 集成 — 企业级AI文档分析，内置生产级OCR和针对特定文档类型与工作流优化的客户定制模型。

速度有多快？

本地模式在CPU上每秒处理60页以上（0.02秒/页）。混合模式每秒处理2页以上（0.46秒/页），但对于复杂文档的准确率显著更高。不需要GPU。基准测试在Apple M4上完成。完整基准测试详情。通过多进程批量处理，在8核以上机器上吞吐量可超过每秒100页。

能处理多栏布局吗？

可以。OpenDataLoader使用XY-Cut++阅读顺序分析，在多栏页面、侧边栏和混合布局中正确排序文本。本地模式和混合模式均支持，无需任何配置。

什么是混合模式？

混合模式结合了快速的本地Java处理与AI后端。简单页面在本地处理（0.02秒/页）；复杂页面（表格、扫描内容、公式、图表）自动路由到AI后端以获得更高准确率。后端在你的机器上本地运行 — 无需云端。请参阅应该使用哪种模式？和混合模式指南。

支持LangChain吗？

支持。安装 langchain-opendataloader-pdf 即可获得官方LangChain文档加载器集成。参见LangChain文档。

如何为RAG对PDF进行分块？

OpenDataLoader输出结构化的Markdown，保留标题、表格和列表 — 是语义分块的理想输入。JSON输出中的每个元素都包含 type、heading level 和 page number，因此你可以按章节或页面边界进行拆分。对于大多数RAG流水线：使用 format="markdown" 进行文本分块，或使用 format="json" 进行元素级控制。配合LangChain的 RecursiveCharacterTextSplitter 或你自己的基于标题的分割器，可获得最佳效果。

如何在RAG回答中引用PDF来源？

JSON输出中的每个元素都包含 bounding box（[左, 下, 右, 上]，单位PDF点）和 page number。当你的RAG流水线返回答案时，将源块映射回其边界框，即可在原始PDF中高亮显示确切位置。这实现了“点击查看来源”的用户体验 — 用户可以看到答案来自哪个段落、表格或图片。没有其他开源解析器默认提供每个元素的边界框。

如何将PDF转换为Markdown供LLM使用？

import opendataloader_pdf

# 一次调用中批量处理所有文件 — 每次convert()都会启动一个JVM进程，重复调用会很慢
opendataloader_pdf.convert(
    input_path=["file1.pdf", "file2.pdf", "folder/"],
    output_dir="output/",
    format="markdown"
)

OpenDataLoader在Markdown输出中保留标题层级、表格结构和阅读顺序。对于带有无框表格或扫描页面的复杂文档，使用混合模式（hybrid="docling-fast"）可获得更高准确率。输出足够干净，可以直接送入LLM上下文窗口或RAG分块流水线。

有自动化的PDF无障碍修复工具吗？

有。OpenDataLoader是首个端到端自动化PDF无障碍的开源工具。与PDF协会及Dual Lab（veraPDF开发者）合作构建，自动标记遵循Well-Tagged PDF规范，并使用veraPDF进行程序化验证。布局分析引擎检测文档结构（标题、表格、列表、阅读顺序）并自动生成无障碍标签。自动标记（2026年Q2）将未标记PDF转换为Tagged PDF，基于Apache 2.0许可证 — 不依赖专有SDK。对于需要完整PDF/UA合规的组织，企业插件提供PDF/UA导出和可视化标签编辑器。这取代了通常每份文档成本$50–200+的手动修复工作流。

这真的是首个开源的PDF自动标记工具吗？

是的。现有工具要么依赖专有SDK写入结构标签，要么只输出非PDF格式（例如Docling输出Markdown/JSON但无法生成Tagged PDF），要么需要人工干预。OpenDataLoader是首个完全在开源许可证（Apache 2.0）下完成布局分析 → 标签生成 → Tagged PDF输出的工具，无任何专有依赖。自动标记遵循PDF协会的Well-Tagged PDF规范，并使用行业参考的开源PDF/A和PDF/UA验证器veraPDF进行验证。

如何将现有PDF转换为PDF/UA？

OpenDataLoader提供端到端流水线：审计现有PDF的标签（use_struct_tree=True），对未标记PDF进行自动标记生成Tagged PDF（2026年Q2，Apache 2.0免费），然后导出为PDF/UA-1或PDF/UA-2（企业插件）。自动标记遵循PDF协会的Well-Tagged PDF规范，并使用veraPDF验证。自动标记生成Tagged PDF；PDF/UA导出是最后一步。联系我们获取企业集成。

如何使我的PDF符合EAA无障碍要求？

欧洲无障碍法案要求到2025年6月28日实现数字产品无障碍。OpenDataLoader支持完整的修复工作流：审计 → 自动标记 → Tagged PDF → PDF/UA导出。自动标记遵循PDF协会的Well-Tagged PDF规范，并使用veraPDF验证，确保输出符合标准。自动标记生成Tagged PDF将在Apache 2.0许可证下开源（2026年Q2）。PDF/UA导出和无障碍工作室为企业插件。请参阅我们的无障碍指南。

OpenDataLoader PDF是免费的吗？

核心库是基于Apache 2.0许可证的开源软件 — 可免费用于商业用途。这包括所有提取功能（文本、表格、图片、OCR、公式、图表（通过混合模式））、AI安全过滤器、Tagged PDF支持，以及自动标记生成Tagged PDF（2026年Q2）。我们致力于保持核心无障碍流水线（布局分析 → 自动标记 → Tagged PDF）免费且开源。企业插件（PDF/UA导出、无障碍工作室）适用于需要端到端法规合规的组织。

为什么许可证从MPL 2.0改为Apache 2.0？

MPL 2.0要求文件级别的弱著佐权，这往往在企业采用前引发法律审查。Apache 2.0是完全宽松的 — 无著佐权义务，更容易集成到商业项目中。如果你正在使用2.0之前的版本，它仍然遵循MPL 2.0，你可以继续使用。升级到2.0+意味着你的项目遵循Apache 2.0条款，这些条款严格来说更加宽松 — 没有额外的义务，你无需采取任何行动。

文档

贡献

我们欢迎贡献！请参阅 CONTRIBUTING.md 了解指南。

许可证

Apache License 2.0

注意： 2.0之前的版本遵循 Mozilla Public License 2.0。

参考资料

OpenDataLoader PDF
参考资料

memU 面向 AI 智能体的全天候主动记忆系统

Thu, 09 Apr 2026 13:01:55 +0000

memU

面向 AI 智能体的全天候主动记忆系统

**English

</div>

memU 是一个专为 24/7 主动智能体打造的记忆框架。它专为长时间运行设计，能够大幅降低保持智能体始终在线的 LLM token 成本，使持续运行、不断进化的智能体在生产系统中变得切实可行。 memU 持续捕获并理解用户意图。即使没有明确指令，智能体也能判断你即将要做什么并主动执行。

🤖 OpenClaw (Moltbot, Clawdbot) Alternative

Download-and-use and simple to get started.
Builds long-term memory to understand user intent and act proactively.
Cuts LLM token cost with smaller context.

Try now: memU bot

🗃️ 记忆即文件系统，文件系统即记忆

memU 将记忆视为文件系统——结构化、层次化、即时可访问。

文件系统	memU 记忆
📁 文件夹	🏷️ 类别（自动组织的主题）
📄 文件	🧠 记忆条目（提取的事实、偏好、技能）
🔗 符号链接	🔄 交叉引用（关联的记忆相互链接）
📂 挂载点	📥 资源（对话、文档、图像）

为何重要：

像浏览目录一样导航记忆——从宽泛的类别深入到具体的事实
即时挂载新知识——对话和文档成为可查询的记忆
万物互联——记忆相互引用，构建连接的知识图谱
持久化且可迁移——像文件一样导出、备份和迁移记忆

memory/
├── preferences/
│   ├── communication_style.md
│   └── topic_interests.md
├── relationships/
│   ├── contacts/
│   └── interaction_history/
├── knowledge/
│   ├── domain_expertise/
│   └── learned_skills/
└── context/
    ├── recent_conversations/
    └── pending_tasks/

正如文件系统将原始字节转化为有组织的数据，memU 将原始交互转化为结构化、可搜索、主动式的智能。

⭐️ 给项目点个星

如果你觉得 memU 有用或有趣，请给项目点个星 ⭐️，这将是对我们最大的支持！

✨ 核心能力

| 能力 | 描述 | |——|——| | 🤖 24/7 主动智能体 | 始终在线的记忆智能体，在后台持续工作——永不休眠，永不遗忘 | | 🎯 用户意图捕获 | 自动理解并记住用户在各个会话中的目标、偏好和上下文 | | 💰 成本高效 | 通过缓存洞察和避免冗余 LLM 调用来降低长期运行的 token 成本 | —

🔄 主动记忆工作原理

cd examples/proactive
python proactive.py

Proactive Memory Lifecycle

┌──────────────────────────────────────────────────────────────────────────────────────────────────┐
│                                         USER QUERY                                               │
└──────────────────────────────────────────────────────────────────────────────────────────────────┘
                 │                                                           │
                 ▼                                                           ▼
┌────────────────────────────────────────┐         ┌────────────────────────────────────────────────┐
│         🤖 MAIN AGENT                  │         │              🧠 MEMU BOT                       │
│                                        │         │                                                │
│  Handle user queries & execute tasks   │  ◄───►  │  Monitor, memorize & proactive intelligence   │
├────────────────────────────────────────┤         ├────────────────────────────────────────────────┤
│                                        │         │                                                │
│  ┌──────────────────────────────────┐  │         │  ┌──────────────────────────────────────────┐  │
│  │  1. RECEIVE USER INPUT           │  │         │  │  1. MONITOR INPUT/OUTPUT                 │  │
│  │     Parse query, understand      │  │   ───►  │  │     Observe agent interactions           │  │
│  │     context and intent           │  │         │  │     Track conversation flow              │  │
│  └──────────────────────────────────┘  │         │  └──────────────────────────────────────────┘  │
│                 │                      │         │                    │                           │
│                 ▼                      │         │                    ▼                           │
│  ┌──────────────────────────────────┐  │         │  ┌──────────────────────────────────────────┐  │
│  │  2. PLAN & EXECUTE               │  │         │  │  2. MEMORIZE & EXTRACT                   │  │
│  │     Break down tasks             │  │   ◄───  │  │     Store insights, facts, preferences   │  │
│  │     Call tools, retrieve data    │  │  inject │  │     Extract skills & knowledge           │  │
│  │     Generate responses           │  │  memory │  │     Update user profile                  │  │
│  └──────────────────────────────────┘  │         │  └──────────────────────────────────────────┘  │
│                 │                      │         │                    │                           │
│                 ▼                      │         │                    ▼                           │
│  ┌──────────────────────────────────┐  │         │  ┌──────────────────────────────────────────┐  │
│  │  3. RESPOND TO USER              │  │         │  │  3. PREDICT USER INTENT                  │  │
│  │     Deliver answer/result        │  │   ───►  │  │     Anticipate next steps                │  │
│  │     Continue conversation        │  │         │  │     Identify upcoming needs              │  │
│  └──────────────────────────────────┘  │         │  └──────────────────────────────────────────┘  │
│                 │                      │         │                    │                           │
│                 ▼                      │         │                    ▼                           │
│  ┌──────────────────────────────────┐  │         │  ┌──────────────────────────────────────────┐  │
│  │  4. LOOP                         │  │         │  │  4. RUN PROACTIVE TASKS                  │  │
│  │     Wait for next user input     │  │   ◄───  │  │     Pre-fetch relevant context           │  │
│  │     or proactive suggestions     │  │  suggest│  │     Prepare recommendations              │  │
│  └──────────────────────────────────┘  │         │  │     Update todolist autonomously         │  │
│                                        │         │  └──────────────────────────────────────────┘  │
└────────────────────────────────────────┘         └────────────────────────────────────────────────┘
                 │                                                           │
                 └───────────────────────────┬───────────────────────────────┘
                                             ▼
                              ┌──────────────────────────────┐
                              │     CONTINUOUS SYNC LOOP     │
                              │  Agent ◄──► MemU Bot ◄──► DB │
                              └──────────────────────────────┘

🎯 主动应用场景

1. 信息推荐

智能体监控用户兴趣，主动呈现相关内容

# 用户一直在研究 AI 话题
MemU 追踪：阅读历史、收藏文章、搜索查询

# 当新内容到达时：
智能体："我发现了 3 篇关于 RAG 优化的新论文，与你最近关于检索系统的
        研究方向一致。其中一位作者（陈博士）你之前引用过，昨天发表了新作。"

# 主动行为：
- 从浏览模式学习话题偏好
- 追踪作者/来源可信度偏好
- 基于参与历史过滤噪音
- 选择最佳时机进行推荐

2. 邮件管理

智能体学习沟通模式，处理日常通信

# MemU 随时间观察邮件模式：
- 常见场景的回复模板
- 优先联系人和紧急关键词
- 日程偏好和可用时间
- 写作风格和语气变化

# 主动邮件助理：
智能体："你有 12 封新邮件。我已为 3 个常规请求起草了回复，
        并标记了来自优先联系人的 2 个紧急事项。
        需要我根据约翰提到的冲突重新安排明天的会议吗？"

# 自主执行：
✓ 起草上下文感知的回复
✓ 分类并排序收件箱
✓ 检测日程冲突
✓ 总结长对话线程的关键决策

3. 交易与财务监控

智能体追踪市场情况和用户投资行为

# MemU 学习交易偏好：
- 从历史决策中了解风险承受能力
- 偏好的行业和资产类别
- 对市场事件的响应模式
- 投资组合再平衡触发条件

# 主动提醒：
智能体："NVDA 盘后下跌 5%。根据你的历史行为，
        你通常在科技股跌幅超过 3% 时买入。
        你当前的配置允许增加 $2,000 的敞口，
        同时保持你 70/30 的股债目标。"

# 持续监控：
- 追踪与用户定义阈值相关的价格警报
- 关联新闻事件与投资组合影响
- 从已执行与忽略的建议中学习
- 预判税损收割机会

…

🗂️ 分层记忆架构

MemU 的三层系统同时支持响应式查询和主动上下文加载：

层级	响应式使用	主动使用
资源层	直接访问原始数据	后台监控新模式
条目层	针对性事实检索	从进行中的交互实时提取
类别层	摘要级概览	自动上下文组装以进行预测

主动优势：

自动分类：新记忆自组织到主题中
模式检测：系统识别重复出现的主题
上下文预测：预测接下来需要什么信息

🚀 快速开始

选项 1：云版本

立即体验主动记忆：

👉 memu.so - 提供 7×24 持续学习的托管服务

如需具有自定义主动工作流的企业部署，请联系 info@nevamind.ai

云 API (v3)

基础 URL	`https://api.memu.so`
认证	`Authorization: Bearer YOUR_API_KEY`

方法	端点	描述
`POST`	`/api/v3/memory/memorize`	注册持续学习任务
`GET`	`/api/v3/memory/memorize/status/{task_id}`	检查实时处理状态
`POST`	`/api/v3/memory/categories`	列出自动生成的类别
`POST`	`/api/v3/memory/retrieve`	查询记忆（支持主动上下文加载）

📚 完整 API 文档

选项 2：自托管

安装

pip install -e .

基础示例

要求：Python 3.13+ 和 OpenAI API 密钥

测试持续学习（内存模式）：

export OPENAI_API_KEY=your_api_key
cd tests
python test_inmemory.py

测试持久化存储（PostgreSQL）：

# 启动带 pgvector 的 PostgreSQL
docker run -d \
  --name memu-postgres \
  -e POSTGRES_USER=postgres \
  -e POSTGRES_PASSWORD=postgres \
  -e POSTGRES_DB=memu \
  -p 5432:5432 \
  pgvector/pgvector:pg16

# 运行持续学习测试
export OPENAI_API_KEY=your_api_key
cd tests
python test_postgres.py

两个示例都演示了主动记忆工作流：

持续摄入：顺序处理多个文件
自动提取：即时创建记忆
主动检索：上下文感知的记忆呈现

查看 tests/test_inmemory.py 和 tests/test_postgres.py 了解实现细节。

自定义 LLM 和嵌入提供者

MemU 支持 OpenAI 以外的自定义 LLM 和嵌入提供者。通过 llm_profiles 配置：

from memu import MemUService

service = MemUService(
    llm_profiles={
        # LLM 操作的默认配置
        "default": {
            "base_url": "https://dashscope.aliyuncs.com/compatible-mode/v1",
            "api_key": "your_api_key",
            "chat_model": "qwen3-max",
            "client_backend": "sdk"  # "sdk" 或 "http"
        },
        # 嵌入的单独配置
        "embedding": {
            "base_url": "https://api.voyageai.com/v1",
            "api_key": "your_voyage_api_key",
            "embed_model": "voyage-3.5-lite"
        }
    },
    # ... 其他配置
)

OpenRouter 集成

MemU 支持 OpenRouter 作为模型提供者，让您通过单个 API 访问多个 LLM 提供者。

配置

from memu import MemoryService

service = MemoryService(
    llm_profiles={
        "default": {
            "provider": "openrouter",
            "client_backend": "httpx",
            "base_url": "https://openrouter.ai",
            "api_key": "your_openrouter_api_key",
            "chat_model": "anthropic/claude-3.5-sonnet",  # 任何 OpenRouter 模型
            "embed_model": "openai/text-embedding-3-small",  # 嵌入模型
        },
    },
    database_config={
        "metadata_store": {"provider": "inmemory"},
    },
)

环境变量

变量	描述
`OPENROUTER_API_KEY`	您的 OpenRouter API 密钥，来自 openrouter.ai/keys

支持的功能

功能	状态	备注
聊天补全	支持	适用于任何 OpenRouter 聊天模型
嵌入	支持	通过 OpenRouter 使用 OpenAI 嵌入模型
视觉	支持	使用支持视觉的模型（如 `openai/gpt-4o`）

运行 OpenRouter 测试

export OPENROUTER_API_KEY=your_api_key

# 完整工作流测试（记忆 + 检索）
python tests/test_openrouter.py

# 嵌入专项测试
python tests/test_openrouter_embedding.py

# 视觉专项测试
python tests/test_openrouter_vision.py

查看 examples/example_4_openrouter_memory.py 获取完整示例。

📖 核心 API

`memorize()` - 持续学习管道

实时处理输入并立即更新记忆：

result = await service.memorize(
    resource_url="path/to/file.json",  # 文件路径或 URL
    modality="conversation",            # conversation | document | image | video | audio
    user={"user_id": "123"}             # 可选：限定到特定用户
)

# 立即返回提取的记忆:
{
    "resource": {...},      # 存储的资源元数据
    "items": [...],         # 提取的记忆条目（即时可用）
    "categories": [...]     # 自动更新的类别结构
}

主动功能：

零延迟处理——记忆即时可用
无需手动标记的自动分类
与现有记忆交叉引用以检测模式

`retrieve()` - 双模式智能

MemU 同时支持主动上下文加载和响应式查询：

基于 RAG 的检索 (`method="rag"`)

使用嵌入的快速主动上下文组装：

✅ 即时上下文：亚秒级记忆呈现
✅ 后台监控：可持续运行而无 LLM 成本
✅ 相似度评分：自动识别最相关的记忆

基于 LLM 的检索 (`method="llm"`)

针对复杂上下文的深度预期性推理：

✅ 意图预测：LLM 在用户询问之前推断需求
✅ 查询演化：随着上下文发展自动优化搜索
✅ 提前终止：收集到足够上下文时停止

对比

方面	RAG（快速上下文）	LLM（深度推理）
速度	⚡ 毫秒级	🐢 秒级
成本	💰 仅嵌入	💰💰 LLM 推理
主动使用	持续监控	触发式上下文加载
最适合	实时建议	复杂预测

使用

# 带上下文历史的主动检索
result = await service.retrieve(
    queries=[
        {"role": "user", "content": {"text": "他们的偏好是什么？"}},
        {"role": "user", "content": {"text": "告诉我工作习惯"}}
    ],
    where={"user_id": "123"},  # 可选：范围过滤
    method="rag"  # 或 "llm" 用于更深入的推理
)

# 返回上下文感知的结果:
{
    "categories": [...],     # 相关主题领域（自动优先排序）
    "items": [...],          # 具体记忆事实
    "resources": [...],      # 原始来源以供追溯
    "next_step_query": "..." # 预测的后续上下文
}

主动过滤：使用 where 限定持续监控范围：

where={"user_id": "123"} - 用户特定上下文
where={"agent_id__in": ["1", "2"]} - 多智能体协调
省略 where 以获取全局上下文感知

📚 完整 API 文档，请参阅 SERVICE_API.md - 包含主动工作流模式、管道配置和实时更新处理。

💡 主动场景

示例 1：始终学习的助手

无需显式记忆命令，从每次交互中持续学习：

export OPENAI_API_KEY=your_api_key
python examples/example_1_conversation_memory.py

主动行为：

从随意提及中自动提取偏好
从交互模式构建关系模型
在未来对话中呈现相关上下文
根据学习的偏好调整沟通风格

最适合： 个人 AI 助手、记住用户的客户支持、社交聊天机器人

示例 2：自我改进的智能体

从执行日志中学习并主动建议优化：

export OPENAI_API_KEY=your_api_key
python examples/example_2_skill_extraction.py

主动行为：

持续监控智能体操作和结果
识别成功和失败中的模式
从经验中自动生成技能指南
主动为类似的未来任务建议策略

最适合： DevOps 自动化、智能体自我改进、知识捕获

示例 3：多模态上下文构建器

将不同输入类型的记忆统一为全面的上下文：

export OPENAI_API_KEY=your_api_key
python examples/example_3_multimodal_memory.py

主动行为：

自动交叉引用文本、图像和文档
跨模态构建统一理解
讨论相关话题时呈现视觉上下文
通过组合多个来源预测信息需求

最适合： 文档系统、学习平台、研究助手

📊 性能表现

MemU 在 Locomo 基准测试中，在所有推理任务上实现了 92.09% 的平均准确率，展示了可靠的主动记忆操作。

查看详细实验数据：memU-experiment

🧩 生态系统

仓库	描述	主动功能
memU	核心主动记忆引擎	7×24 学习管道、自动分类
memU-server	带持续同步的后端	实时记忆更新、webhook 触发
memU-ui	可视化记忆仪表板	实时记忆演化监控

快速链接：

🤝 合作伙伴

🤝 如何贡献

我们欢迎社区的各种贡献！无论是修复错误、添加功能还是改进文档，您的帮助都将受到赞赏。

开始贡献

要开始为 MemU 做贡献，您需要设置开发环境：

先决条件

Python 3.13+
uv（Python 包管理器）
Git

设置开发环境

# 1. Fork 并克隆仓库
git clone https://github.com/YOUR_USERNAME/memU.git
cd memU

# 2. 安装开发依赖
make install

make install 命令将：

使用 uv 创建虚拟环境
安装所有项目依赖
设置代码质量检查的 pre-commit hooks

运行质量检查

在提交贡献之前，请确保您的代码通过所有质量检查：

make check

make check 命令运行：

锁文件验证：确保 pyproject.toml 一致性
Pre-commit hooks：使用 Ruff 检查代码，使用 Black 格式化
类型检查：运行 mypy 进行静态类型分析
依赖分析：使用 deptry 查找过时的依赖项

贡献指南

有关详细的贡献指南、代码标准和开发实践，请参阅 CONTRIBUTING.md。

快速提示：

为每个功能或错误修复创建新分支
编写清晰的提交信息
为新功能添加测试
根据需要更新文档
推送前运行 make check

📄 许可证

Apache License 2.0

🌍 社区

GitHub Issues：报告错误和请求功能
Discord：加入社区
X (Twitter)：关注 @memU_ai
联系方式：info@nevamind.ai

⭐ **在 GitHub 上给我们点星**，获取新版本通知！

参考资料

memU
参考资料

MemPalace AI 记忆系统手动安装

Thu, 09 Apr 2026 13:01:55 +0000

背景

直接安装失败

> claude plugin marketplace add milla-jovovich/mempalace
Adding marketplace...
SSH not configured, cloning via HTTPS: https://github.com/milla-jovovich/mempalace.git
Cloning repository: https://github.com/milla-jovovich/mempalace.git
HTTPS clone failed, retrying with SSH: git@github.com:milla-jovovich/mempalace.git
Cloning repository: git@github.com:milla-jovovich/mempalace.git
✘ Failed to add marketplace: Failed to clone marketplace repository: Cloning into 'C:\Users\dh\.claude\plugins\marketplaces\milla-jovovich-mempalace'...
PS D:\aicode\openim-plateform>

手动安装

# 1. 进入一个临时目录（例如桌面或你的项目目录）
cd D:\aicode

# 2. 使用 HTTPS 方式 clone 仓库（如果网络正常）
git clone https://github.com/milla-jovovich/mempalace.git

# 如果 HTTPS 失败，可以尝试使用 GitHub 的镜像加速（国内常用）
git clone https://hub.fastgit.xyz/milla-jovovich/mempalace.git

# 或者使用 SSH 方式（前提是你已经配置好 SSH Key）
git clone git@github.com:milla-jovovich/mempalace.git

实际下载

$ git clone git@github.com:milla-jovovich/mempalace.git
Cloning into 'mempalace'...
remote: Enumerating objects: 814, done.
remote: Counting objects: 100% (443/443), done.
remote: Compressing objects: 100% (183/183), done.
remote: Total 814 (delta 355), reused 260 (delta 260), pack-reused 371 (from 3)
Receiving objects: 100% (814/814), 1.14 MiB | 110.00 KiB/s, done.
Resolving deltas: 100% (497/497), done.

成功后处理

# 3. 进入克隆下来的目录
cd mempalace

# 4. 将本地文件夹添加为 Claude 插件市场
claude plugin marketplace add ./

# 或者指定绝对路径
claude plugin marketplace add D:\aicode\mempalace

PS: 发现用 git-bash 不行，改为了 command 普通命令行，添加成功

D:\aicode>cd mempalace

D:\aicode\mempalace>claude plugin marketplace add ./
Adding marketplace...
√ Successfully added marketplace: mempalace

D:\aicode\mempalace>claude plugin marketplace list
Configured marketplaces:

  > claude-plugins-official
    Source: GitHub (anthropics/claude-plugins-official)

  > superpowers-marketplace
    Source: GitHub (obra/superpowers-marketplace)

  > thedotmack
    Source: GitHub (thedotmack/claude-mem)

  > claude-subconscious
    Source: GitHub (letta-ai/claude-subconscious)

  > mempalace
    Source: Directory (D:\aicode\mempalace)

安装插件

推荐使用 –scope user 让所有项目都能用

> claude plugin install --scope user mempalace

安装成功。

初始化

重启 claude code 执行下面的命令初始化：

/mempalace:init

这里其实会触发安装：

pip install mempalace

常用命令

# 搜索记忆
mempalace search "关键词"

# 查看状态
mempalace status

# 挖掘更多文件
mempalace mine "d:\aicode\openim-plateform" --mode projects

# 查看唤醒上下文
mempalace wake-up

参考资料

背景
手动安装
参考资料

MemPalace 经基准测试得分最高的 AI 记忆系统。而且免费。

Thu, 09 Apr 2026 13:01:55 +0000

MemPalace

经基准测试得分最高的 AI 记忆系统。而且免费。

你与 AI 的每一次对话 —— 每个决策、每次调试、每场架构辩论 —— 都会在会话结束时消失。六个月的工作，付诸东流。每次都要从头开始。

其他记忆系统试图通过让 AI 自行判断什么值得记住来解决这个问题。它们提取出“用户偏好 Postgres”，却丢弃了你解释为什么偏好它的那段对话。MemPalace 采用不同的方法：存储一切，然后让它们可被找到。

记忆宫殿 —— 古希腊演说家通过在想象建筑的不同房间里放置观点来记住整篇演讲。漫步宫殿，找到观点。MemPalace 将同一原理应用于 AI 记忆：你的对话被组织成翼（人物和项目）、厅（记忆类型）和室（具体观点）。没有 AI 来决定什么重要 —— 你保留每一个字，而结构给你一张可导航的地图，而非扁平的搜索索引。

原始逐字存储 —— MemPalace 将你的实际对话逐字存入 ChromaDB，不做摘要或提取。96.6% 的 LongMemEval 成绩即来自这种原始模式。我们不会消耗 LLM 来判定什么“值得记住” —— 我们保留一切，让语义搜索去找到它。

AAAK（实验性） —— 一种有损缩写方言，用于在大规模下将重复实体压缩到更少的 token 中。任何能阅读文本的 LLM（Claude、GPT、Gemini、Llama、Mistral）都能读懂，无需解码器。AAAK 是一个独立的压缩层，不是存储默认方式，在 LongMemEval 基准测试上，它目前相对于原始模式有退化（84.2% vs 96.6%）。我们正在迭代。诚实的现状请见上面的说明。

本地、开放、可适配 —— MemPalace 完全运行在你的机器上，使用你本地的任何数据，不调用任何外部 API 或服务。

它已经在对话数据上测试过 —— 但可以适配不同类型的数据存储。这就是我们将其开源的缘由。

快速开始 · 记忆宫殿 · AAAK 方言 · 基准测试 · MCP 工具

有史以来最高的 LongMemEval 分数 —— 无论免费还是付费。

</table> </td>

96.6%
_{LongMemEval R@5
原始模式，零 API 调用} 500/500
_{测试问题
独立复现} $0
_{无订阅
无云端。仅本地。}

</tr> </table>

_{可复现 —— 运行脚本在 benchmarks/。完整结果。96.6% 来自原始逐字模式，而非 AAAK 或房间模式（那些得分较低 —— 见上方说明）。}

</div>

来自 Milla & Ben 的说明 —— 2026年4月7日

社区在发布后几小时内就发现本 README 中的实际问题，我们想直接回应。

我们做错的地方：

AAAK 的 token 示例是错误的。 我们用一个粗略的启发式（len(text)//3）来估算 token 数量，而不是真正的分词器。使用 OpenAI 分词器的真实计数：英文示例为 66 个 token，AAAK 示例为 73 个 token。AAAK 在小规模下并不节省 token —— 它是为大规模下的重复实体设计的，而 README 示例对此展示得很糟糕。我们将重写它。

“30倍无损压缩”夸大其词。 AAAK 是一种有损缩写系统（实体代码、句子截断）。独立基准测试显示，在 LongMemEval 上，AAAK 模式得分为 84.2% R@5，而原始模式为 96.6% —— 下降了 12.4 个百分点。诚实的表述是：AAAK 是一个实验性压缩层，以保真度换取 token 密度，96.6% 的标题数字来自原始模式，而非 AAAK。

“+34% 宫殿提升”具有误导性。 该数字比较的是无过滤搜索与翼+房间元数据过滤。元数据过滤是 ChromaDB 的标准功能，并非新颖的检索机制。它真实且有用，但不是护城河。

“矛盾检测” 作为一个独立工具存在（fact_checker.py），但目前并未像 README 所暗示的那样接入知识图谱操作。

“Haiku 重排后 100%” 是真实的（我们有结果文件），但重排流水线并未包含在公共基准脚本中。我们会添加它。

仍然真实且可复现的内容：

原始模式下 LongMemEval 96.6% R@5，基于 500 个问题，零 API 调用 —— 由 @gizmax 在 M2 Ultra 上独立复现，耗时不到 5 分钟。

本地、免费、无订阅、无云端、数据不离开你的机器。

架构（翼、房间、壁橱、抽屉）是真实且有帮助的，即使它不是神奇的检索提升。

我们正在做的事情：

用真实的分词器计数重写 AAAK 示例，并提供一个能展示 AAAK 实际压缩效果的场景

在基准文档中明确添加 mode raw / aaak / rooms，以便可见权衡

将 fact_checker.py 接入知识图谱操作，使矛盾检测的声明成真

将 ChromaDB 锁定到经过测试的版本范围（Issue #100），修复钩子中的 shell 注入（#110），并解决 macOS ARM64 段错误（#74）

感谢每一个指出问题的人。 残酷而诚实的批评正是开源运作的方式，也是我们所求的。特别感谢 @panuhorsmalahti、@lhl、@gizmax 以及在最初 48 小时内提交 issue 或 PR 的每一位。我们在倾听，我们在修复，我们宁愿正确而非惊艳。

—— Milla Jovovich & Ben Sigman

快速开始

pip install mempalace

# 设置你的世界 —— 你与谁合作，你的项目有哪些
mempalace init ~/projects/myapp

# 挖掘你的数据
mempalace mine ~/projects/myapp                    # 项目 —— 代码、文档、笔记
mempalace mine ~/chats/ --mode convos              # 对话 —— Claude、ChatGPT、Slack 导出
mempalace mine ~/chats/ --mode convos --extract general  # 通用 —— 分类为决策、里程碑、问题

# 搜索你曾经讨论过的任何内容
mempalace search "为什么我们切换到了 GraphQL"

# 你的 AI 会记住
mempalace status

三种挖掘模式：projects（代码和文档）、convos（对话导出）和 general（自动分类为决策、偏好、里程碑、问题和情绪背景）。所有内容都保留在你的机器上。

你实际如何使用它

一次性设置（安装 → init → mine）之后，你不需要手动运行 MemPalace 命令。你的 AI 会为你使用它。根据你使用的 AI，有两种方式。

搭配 Claude Code（推荐）

原生市场安装：

claude plugin marketplace add milla-jovovich/mempalace
claude plugin install --scope user mempalace

重启 Claude Code，然后输入 /skills 验证是否出现 “mempalace”。

搭配 Claude、ChatGPT、Cursor、Gemini（兼容 MCP 的工具）

# 连接 MemPalace 一次
claude mcp add mempalace -- python -m mempalace.mcp_server

现在你的 AI 通过 MCP 拥有 19 个工具。问它任何问题：

“我们上个月关于认证的决定是什么？”

Claude 会自动调用 mempalace_search，获取逐字结果，然后回答你。你再也不用输入 mempalace search。AI 会处理。

MemPalace 也可以原生配合 Gemini CLI 使用（它会自动处理服务器和保存钩子）—— 详见 Gemini CLI 集成指南。

搭配本地模型（Llama、Mistral 或任何离线 LLM）

本地模型通常还不支持 MCP。两种方法：

1. 唤醒命令 —— 将你的世界加载到模型的上下文中：

mempalace wake-up > context.txt
# 将 context.txt 粘贴到本地模型的系统提示中

这会在你提出任何问题之前，给本地模型约 170 个 token 的关键事实（如果你愿意，可以用 AAAK 格式）。

2. CLI 搜索 —— 按需查询，将结果喂给提示：

mempalace search "认证决策" > results.txt
# 将 results.txt 包含在你的提示中

或者使用 Python API：

from mempalace.searcher import search_memories
results = search_memories("认证决策", palace_path="~/.mempalace/palace")
# 注入到本地模型的上下文中

无论哪种方式 —— 你的整个记忆栈都在离线运行。ChromaDB 在你的机器上，Llama 在你的机器上，AAAK 用于压缩，零云端调用。

问题所在

决策现在发生在对话中。不在文档里。不在 Jira 里。在与 Claude、ChatGPT、Copilot 的对话中。推理过程、权衡取舍、“我们尝试了 X 但失败因为 Y” —— 全都困在会话结束后就会消失的聊天窗口里。

每天使用 AI 六个月 = 1950 万 token。 每个决策、每次调试、每场架构辩论。消失。

方法	加载的 token	年成本
全部粘贴	1950 万 —— 任何上下文窗口都装不下	不可能
LLM 摘要	~65 万	~$507/年
MemPalace 唤醒	~170 token	~$0.70/年
MemPalace + 5 次搜索	~13,500 token	~$10/年

MemPalace 在唤醒时加载 170 个 token 的关键事实 —— 你的团队、你的项目、你的偏好。然后只在需要时搜索。每年 10 美元记住一切，对比每年 507 美元却丢失上下文的摘要。

工作原理

记忆宫殿

布局相当简单，虽然花了很多时间才达到这个状态。

从翼开始。每个项目、人物或你归档的主题都在宫殿中拥有自己独立的翼。

每个翼连接着多个房间，信息被划分为与该翼相关的主题 —— 所以每个房间都是你项目包含内容的不同元素。项目想法可以是一个房间，员工可以是另一个，财务报表又一个。可以有无限多的房间将翼分成多个部分。MemPalace 安装会自动为你检测这些，当然你也可以按自己觉得合适的方式个性化。

每个房间连接着一个壁橱，这里就有意思了。我们开发了一种 AI 语言叫做 AAAK。别问 —— 它本身就是一个完整的故事。你的智能体每次醒来时都会学习 AAAK 简写。因为 AAAK 本质上就是英语，但是一个非常精简的版本，你的智能体几秒钟内就能学会使用它。它作为安装的一部分，内置于 MemPalace 代码中。在我们的下一次更新中，我们将直接把 AAAK 添加到壁橱中，这将真正改变游戏规则 —— 壁橱中的信息量会大得多，但占用空间更小，你的智能体阅读时间也更短。

在这些壁橱内部是抽屉，你的原始文件就存放在那里。在这个第一个版本中，我们还没有使用 AAAK 作为壁橱工具，但即便如此，摘要在我们跨多个基准平台进行的所有基准测试中已显示出 96.6% 的召回率。一旦壁橱使用 AAAK，搜索将更快，同时保留每一个字的精确性。但即使是现在，壁橱方法对于在小空间内存储大量信息来说已经是巨大的福音 —— 它用于轻松地将你的 AI 智能体指向存放原始文件的抽屉。你永远不会丢失任何东西，所有这些都在几秒钟内完成。

还有厅，连接同一翼内的房间，以及隧道，连接不同翼的房间。因此查找东西变得真正轻松 —— 我们给了 AI 一个清晰有组织的方式知道从哪里开始搜索，而不必在巨大的文件夹中查找每一个关键词。

你说出你在找什么，然后砰的一下，它已经知道该去哪个翼。仅凭这一点本身就足以带来巨大的改变。但这一切优美、优雅、自然，最重要的是，高效。

  ┌─────────────────────────────────────────────────────────────┐
  │  翼：人物                                                   │
  │                                                            │
  │    ┌──────────┐  ──厅──  ┌──────────┐                      │
  │    │  房间 A  │            │  房间 B  │                      │
  │    └────┬─────┘            └──────────┘                      │
  │         │                                                  │
  │         ▼                                                  │
  │    ┌──────────┐      ┌──────────┐                          │
  │    │  壁橱    │ ───▶ │  抽屉    │                          │
  │    └──────────┘      └──────────┘                          │
  └─────────┼──────────────────────────────────────────────────┘
            │
          隧道
            │
  ┌─────────┼──────────────────────────────────────────────────┐
  │  翼：项目                                                   │
  │         │                                                  │
  │    ┌────┴─────┐  ──厅──  ┌──────────┐                      │
  │    │  房间 A  │            │  房间 C  │                      │
  │    └────┬─────┘            └──────────┘                      │
  │         │                                                  │
  │         ▼                                                  │
  │    ┌──────────┐      ┌──────────┐                          │
  │    │  壁橱    │ ───▶ │  抽屉    │                          │
  │    └──────────┘      └──────────┘                          │
  └─────────────────────────────────────────────────────────────┘

翼 —— 一个人或一个项目。你需要多少就有多少。房间 —— 翼内的特定主题。认证、计费、部署 —— 无限房间。厅 —— 同一翼内相关房间之间的连接。如果房间 A（认证）和房间 B（安全）相关，一个厅连接它们。隧道 —— 不同翼之间的连接。当人物 A 和某个项目都有一个关于“认证”的房间时，隧道会自动交叉引用它们。壁橱 —— 指向原始内容的摘要。（在 v3.0.0 中，这些是纯文本摘要；AAAK 编码的壁橱将在未来更新中提供 —— 参见任务 #30。）抽屉 —— 原始的逐字文件。确切的词语，永不摘要。

厅是记忆类型 —— 每个翼中相同，充当走廊：

hall_facts —— 做出的决定，敲定的选择
hall_events —— 会话、里程碑、调试
hall_discoveries —— 突破、新见解
hall_preferences —— 习惯、喜好、观点
hall_advice —— 建议和解决方案

房间是命名的观点 —— auth-migration、graphql-switch、ci-pipeline。当同一个房间出现在不同的翼中时，它创建了一个隧道 —— 连接跨领域的相同主题：

wing_kai       / hall_events / auth-migration  → "Kai 调试了 OAuth token 刷新"
wing_driftwood / hall_facts  / auth-migration  → "团队决定将认证迁移到 Clerk"
wing_priya     / hall_advice / auth-migration  → "Priya 批准使用 Clerk 而非 Auth0"

相同的房间。三个翼。隧道连接它们。

为什么结构重要

在超过 22,000 条真实对话记忆上测试：

搜索所有壁橱：          60.9%  R@10
在翼内搜索：          73.1%  (+12%)
搜索翼 + 厅：          84.8%  (+24%)
搜索翼 + 房间：        94.8%  (+34%)

翼和房间不是装饰。它们是 34% 的检索提升。宫殿结构就是产品。

记忆栈

层	内容	大小	何时
L0	身份 —— 这个 AI 是谁？	~50 token	始终加载
L1	关键事实 —— 团队、项目、偏好	~120 token (AAAK)	始终加载
L2	房间召回 —— 最近的会话、当前项目	按需	当话题出现时
L3	深度搜索 —— 跨所有壁橱的语义查询	按需	当明确询问时

你的 AI 醒来时带有 L0 + L1（~170 token），了解你的世界。只在需要时触发搜索。

AAAK 方言（实验性）

AAAK 是一种有损缩写系统 —— 实体代码、结构标记和句子截断 —— 旨在将重复的实体和关系在大规模下打包到更少的 token 中。任何能阅读文本的 LLM（Claude、GPT、Gemini、Llama、Mistral）都能读懂它，无需解码器，因此本地模型可以在不依赖任何云端的情况下使用它。

诚实状态（2026年4月）：

AAAK 是有损的，不是无损的。 它使用基于正则表达式的缩写，不是可逆压缩。
在小规模下不节省 token。 短文本已经能高效地 token 化。在几个句子上，AAAK 的开销（代码、分隔符）比节省的 token 还要多。
在大规模下可以节省 token —— 在有许多重复实体的场景中（一个团队被提及数百次，同一个项目跨越数千个会话），实体代码可以摊销成本。
AAAK 目前在 LongMemEval 上相对于原始逐字检索有退化（84.2% R@5 vs 96.6%）。96.6% 的标题数字来自原始模式，而非 AAAK 模式。
MemPalace 的存储默认是 ChromaDB 中的原始逐字文本 —— 基准测试的胜利来自那里。AAAK 是一个用于上下文加载的独立压缩层，不是存储格式。

我们正在迭代方言规范，添加真实的分词器进行统计，并探索更好的使用阈值。跟踪进度请见 Issue #43 和 #27。

矛盾检测（实验性，尚未接入知识图谱）

一个独立工具（fact_checker.py）可以检查断言与实体事实的一致性。目前不会被知识图谱操作自动调用 —— 这个问题正在修复（跟踪 Issue #27）。启用后，它可以捕获如下情况：

输入：  "Soren 完成了认证迁移"
输出： 🔴 AUTH-MIGRATION: 责任冲突 —— 分配给了 Maya，不是 Soren

输入：  "Kai 已经在这里 2 年了"
输出： 🟡 KAI: tenure 错误 —— 记录显示 3 年（始于 2023-04）

输入：  "冲刺在周五结束"
输出： 🟡 SPRINT: 日期过时 —— 当前冲刺在周四结束（2 天前更新）

事实与知识图谱进行核对。年龄、日期和工作年限动态计算 —— 非硬编码。

真实世界示例

跨多个项目的独立开发者

# 挖掘每个项目的对话
mempalace mine ~/chats/orion/  --mode convos --wing orion
mempalace mine ~/chats/nova/   --mode convos --wing nova
mempalace mine ~/chats/helios/ --mode convos --wing helios

# 六个月后："为什么我在这里用了 Postgres？"
mempalace search "数据库决策" --wing orion
# → "选择 Postgres 而非 SQLite，因为 Orion 需要并发写入，且数据集将超过 10GB。决策于 2025-11-03。"

# 跨项目搜索
mempalace search "限流方案"
# → 找到你在 Orion 和 Nova 中的方案，并显示差异

管理产品的团队负责人

# 挖掘 Slack 导出和 AI 对话
mempalace mine ~/exports/slack/ --mode convos --wing driftwood
mempalace mine ~/.claude/projects/ --mode convos

# "Soren 上个冲刺做了什么？"
mempalace search "Soren 冲刺" --wing driftwood
# → 14 个壁橱：OAuth 重构、深色模式、组件库迁移

# "谁决定使用 Clerk？"
mempalace search "Clerk 决策" --wing driftwood
# → "Kai 推荐 Clerk 而非 Auth0 —— 定价 + 开发者体验。团队于 2026-01-15 同意。Maya 负责迁移。"

挖掘前：拆分超大文件

某些对话导出会将多个会话串联成一个巨大的文件：

mempalace split ~/chats/                      # 拆分为每个会话的文件
mempalace split ~/chats/ --dry-run            # 预览
mempalace split ~/chats/ --min-sessions 3     # 只拆分包含 3 个以上会话的文件

知识图谱

时间化的实体-关系三元组 —— 类似于 Zep 的 Graphiti，但使用 SQLite 而非 Neo4j。本地且免费。

from mempalace.knowledge_graph import KnowledgeGraph

kg = KnowledgeGraph()
kg.add_triple("Kai", "works_on", "Orion", valid_from="2025-06-01")
kg.add_triple("Maya", "assigned_to", "auth-migration", valid_from="2026-01-15")
kg.add_triple("Maya", "completed", "auth-migration", valid_from="2026-02-01")

# Kai 在做什么？
kg.query_entity("Kai")
# → [Kai → works_on → Orion (当前), Kai → recommended → Clerk (2026-01)]

# 一月份时的情况？
kg.query_entity("Maya", as_of="2026-01-20")
# → [Maya → assigned_to → auth-migration (活跃)]

# 时间线
kg.timeline("Orion")
# → 项目的按时间顺序的故事

事实具有有效性窗口。当某事不再为真时，使其失效：

kg.invalidate("Kai", "works_on", "Orion", ended="2026-03-01")

现在查询 Kai 的当前工作将不会返回 Orion。历史查询仍然会返回。

特性	MemPalace	Zep (Graphiti)
存储	SQLite（本地）	Neo4j（云端）
成本	免费	$25/月起
时间有效性	是	是
自托管	总是	仅企业版
隐私	一切本地	SOC 2, HIPAA

专家智能体

创建专注于特定领域的智能体。每个智能体在宫殿中获得自己的翼和日记 —— 不在你的 CLAUDE.md 中。添加 50 个智能体，你的配置大小保持不变。

~/.mempalace/agents/
  ├── reviewer.json       # 代码质量、模式、bug
  ├── architect.json      # 设计决策、权衡
  └── ops.json            # 部署、事故、基础设施

你的 CLAUDE.md 只需一行：

你有 MemPalace 智能体。运行 mempalace_list_agents 查看它们。

AI 在运行时从宫殿中发现其智能体。每个智能体：

有一个焦点 —— 它关注什么
保持日记 —— 用 AAAK 书写，跨会话持久化
积累专长 —— 阅读自己的历史以在其领域保持敏锐

# 智能体在代码审查后写入日记
mempalace_diary_write("reviewer",
    "PR#42|auth.bypass.found|missing.middleware.check|pattern:3rd.time.this.quarter|★★★★")

# 智能体读取自己的历史
mempalace_diary_read("reviewer", last_n=10)
# → 最近的 10 个发现，以 AAAK 压缩

每个智能体都是你数据上的一个专家透镜。评审者记住它见过的每个 bug 模式。架构师记住每个设计决策。运维智能体记住每个事故。它们不共享同一个便签本 —— 每个都维护自己的记忆。

Letta 为智能体管理的记忆收费 $20–200/月。MemPalace 用一个翼就做到了。

MCP 服务器

# 通过插件（推荐）
claude plugin marketplace add milla-jovovich/mempalace
claude plugin install --scope user mempalace

# 或手动
claude mcp add mempalace -- python -m mempalace.mcp_server

19 个工具

宫殿（读取）

工具	功能
`mempalace_status`	宫殿概览 + AAAK 规范 + 记忆协议
`mempalace_list_wings`	列出翼及其计数
`mempalace_list_rooms`	列出翼内的房间
`mempalace_get_taxonomy`	完整的翼 → 房间 → 计数树
`mempalace_search`	带翼/房间过滤的语义搜索
`mempalace_check_duplicate`	归档前检查重复
`mempalace_get_aaak_spec`	AAAK 方言参考

宫殿（写入）

工具	功能
`mempalace_add_drawer`	归档逐字内容
`mempalace_delete_drawer`	按 ID 删除

知识图谱

工具	功能
`mempalace_kg_query`	带时间过滤的实体关系
`mempalace_kg_add`	添加事实
`mempalace_kg_invalidate`	标记事实为已结束
`mempalace_kg_timeline`	实体的时间顺序故事
`mempalace_kg_stats`	图谱概览

导航

工具	功能
`mempalace_traverse`	从房间跨翼遍历图谱
`mempalace_find_tunnels`	查找连接两个翼的房间
`mempalace_graph_stats`	图谱连通性概览

智能体日记

工具	功能
`mempalace_diary_write`	写入 AAAK 日记条目
`mempalace_diary_read`	读取最近的日记条目

AI 从 mempalace_status 响应中自动学习 AAAK 和记忆协议。无需手动配置。

自动保存钩子

为 Claude Code 提供的两个钩子，可在工作期间自动保存记忆：

保存钩子 —— 每 15 条消息触发一次结构化保存。主题、决策、引用、代码变更。同时重新生成关键事实层。

预压缩钩子 —— 在上下文压缩前触发。在窗口缩小前紧急保存。

{
  "hooks": {
    "Stop": [{"matcher": "", "hooks": [{"type": "command", "command": "/path/to/mempalace/hooks/mempal_save_hook.sh"}]}],
    "PreCompact": [{"matcher": "", "hooks": [{"type": "command", "command": "/path/to/mempalace/hooks/mempal_precompact_hook.sh"}]}]
  }
}

可选自动摄取： 设置 MEMPAL_DIR 环境变量为一个目录路径，钩子将在每次保存触发时自动对该目录运行 mempalace mine（stop 时后台运行，precompact 时同步运行）。

基准测试

在标准学术基准上测试 —— 可复现、已发布的数据集。

基准	模式	分数	API 调用
LongMemEval R@5	原始（仅 ChromaDB）	96.6%	零
LongMemEval R@5	混合 + Haiku 重排	100% (500/500)	~500
LoCoMo R@10	原始，会话级别	60.3%	零
个人宫殿 R@10	启发式基准	85%	零
宫殿结构影响	翼+房间过滤	+34% R@10	零

96.6% 的原始分数是已发布的 LongMemEval 结果中最高分，且不需要任何 API 密钥、云端或在任何阶段使用 LLM。

与已发布系统的比较

系统	LongMemEval R@5	需要 API	成本
MemPalace（混合）	100%	可选	免费
Supermemory ASMR	~99%	是	—
MemPalace（原始）	96.6%	无	免费
Mastra	94.87%	是（GPT）	API 成本
Mem0	~85%	是	$19–249/月
Zep	~85%	是	$25/月起

全部命令

# 设置
mempalace init <dir>                              # 引导式 onboarding + AAAK 引导

# 挖掘
mempalace mine <dir>                              # 挖掘项目文件
mempalace mine <dir> --mode convos                # 挖掘对话导出
mempalace mine <dir> --mode convos --wing myapp   # 用翼名称标记

# 拆分
mempalace split <dir>                             # 拆分串联的对话记录
mempalace split <dir> --dry-run                   # 预览

# 搜索
mempalace search "查询"                           # 搜索所有
mempalace search "查询" --wing myapp              # 在翼内搜索
mempalace search "查询" --room auth-migration     # 在房间内搜索

# 记忆栈
mempalace wake-up                                 # 加载 L0 + L1 上下文
mempalace wake-up --wing driftwood                # 特定项目

# 压缩
mempalace compress --wing myapp                   # AAAK 压缩

# 状态
mempalace status                                  # 宫殿概览

所有命令都接受 --palace <路径> 来覆盖默认位置。

配置

全局配置（`~/.mempalace/config.json`）

{
  "palace_path": "/自定义/路径/到/palace",
  "collection_name": "mempalace_drawers",
  "people_map": {"Kai": "KAI", "Priya": "PRI"}
}

翼配置（`~/.mempalace/wing_config.json`）

由 mempalace init 生成。将你的人物和项目映射到翼：

{
  "default_wing": "wing_general",
  "wings": {
    "wing_kai": {"type": "person", "keywords": ["kai", "kai's"]},
    "wing_driftwood": {"type": "project", "keywords": ["driftwood", "analytics", "saas"]}
  }
}

身份配置（`~/.mempalace/identity.txt`）

纯文本。成为第 0 层 —— 每次会话加载。

文件参考

文件	功能
`cli.py`	CLI 入口点
`config.py`	配置加载和默认值
`normalize.py`	将 5 种聊天格式转换为标准记录
`mcp_server.py`	MCP 服务器 —— 19 个工具、AAAK 自动教学、记忆协议
`miner.py`	项目文件摄取
`convo_miner.py`	对话摄取 —— 按对话对分块
`searcher.py`	通过 ChromaDB 进行语义搜索
`layers.py`	4 层记忆栈
`dialect.py`	AAAK 压缩 —— 30 倍无损
`knowledge_graph.py`	时间化实体-关系图谱（SQLite）
`palace_graph.py`	基于房间的导航图谱
`onboarding.py`	引导式设置 —— 生成 AAAK 引导 + 翼配置
`entity_registry.py`	实体代码注册表
`entity_detector.py`	从内容中自动检测人物和项目
`split_mega_files.py`	将串联的对话记录拆分为每个会话的文件
`hooks/mempal_save_hook.sh`	每 N 条消息自动保存
`hooks/mempal_precompact_hook.sh`	压缩前紧急保存

项目结构

mempalace/
├── README.md                  ← 你在这里
├── mempalace/                 ← 核心包（README）
│   ├── cli.py                 ← CLI 入口点
│   ├── mcp_server.py          ← MCP 服务器（19 个工具）
│   ├── knowledge_graph.py     ← 时间化实体图谱
│   ├── palace_graph.py        ← 房间导航图谱
│   ├── dialect.py             ← AAAK 压缩
│   ├── miner.py               ← 项目文件摄取
│   ├── convo_miner.py         ← 对话摄取
│   ├── searcher.py            ← 语义搜索
│   ├── onboarding.py          ← 引导式设置
│   └── ...                    ← 详见 mempalace/README.md
├── benchmarks/                ← 可复现的基准运行器
│   ├── README.md              ← 复现指南
│   ├── BENCHMARKS.md          ← 完整结果 + 方法
│   ├── longmemeval_bench.py   ← LongMemEval 运行器
│   ├── locomo_bench.py        ← LoCoMo 运行器
│   └── membench_bench.py      ← MemBench 运行器
├── hooks/                     ← Claude Code 自动保存钩子
│   ├── README.md              ← 钩子设置指南
│   ├── mempal_save_hook.sh    ← 每 N 条消息保存
│   └── mempal_precompact_hook.sh ← 紧急保存
├── examples/                  ← 使用示例
│   ├── basic_mining.py
│   ├── convo_import.py
│   └── mcp_setup.md
├── tests/                     ← 测试套件（README）
├── assets/                    ← logo + 品牌资源
└── pyproject.toml             ← 包配置（v3.0.0）

系统要求

Python 3.9+
chromadb>=0.4.0
pyyaml>=6.0

不需要 API 密钥。安装后不需要互联网。一切本地运行。

pip install mempalace

贡献

欢迎 PR。请参阅 CONTRIBUTING.md 了解设置和指南。

许可证

MIT —— 参见 LICENSE。

```

如果你需要我针对某个部分做进一步调整（比如术语统一、风格微调），或者单独输出纯文本版本，请告诉我。

参考资料

MemPalace
参考资料

Harbor 是一个开源的可信云原生仓库项目，用于存储、签名和扫描内容。

Thu, 09 Apr 2026 13:01:55 +0000

Harbor

注意：开发期间 main 分支可能处于不稳定甚至损坏状态。

为了获得稳定的二进制文件，请使用发行版而不是 main 分支。

Harbor 是一个开源的可信云原生仓库项目，用于存储、签名和扫描内容。

Harbor 扩展了开源 Docker Distribution，增加了用户通常所需的安全、身份和管理功能。

将仓库置于更靠近构建和运行环境的位置可以提高镜像传输效率。Harbor 支持仓库间的镜像复制，并提供高级安全特性，如用户管理、访问控制和活动审计。

Harbor 由云原生计算基金会（CNCF）托管。

如果您是一个希望帮助塑造云原生技术演进的组织，请考虑加入 CNCF。有关谁参与以及 Harbor 如何发挥作用的详细信息，请阅读 CNCF 公告。

特性

云原生仓库：同时支持容器镜像和 Helm chart，Harbor 可作为容器运行时和编排平台等云原生环境的仓库。
基于角色的访问控制：用户通过“项目”访问不同的仓库，用户对项目下的镜像或 Helm chart 可拥有不同的权限。
基于策略的复制：基于策略（使用过滤器：仓库、标签和标签）可以在多个仓库实例之间复制（同步）镜像和 chart。如果遇到任何错误，Harbor 会自动重试复制。这可用于辅助负载均衡、实现高可用，并促进混合云和多云场景中的多数据中心部署。
漏洞扫描：Harbor 定期扫描镜像中的漏洞，并通过策略检查阻止有漏洞的镜像被部署。
LDAP/AD 支持：Harbor 与现有企业 LDAP/AD 集成，用于用户认证和管理，并支持将 LDAP 组导入 Harbor，然后赋予其特定项目的权限。
OIDC 支持：Harbor 利用 OpenID Connect (OIDC) 验证由外部授权服务器或身份提供者认证的用户身份。可以启用单点登录登录 Harbor 门户。
镜像删除与垃圾回收：系统管理员可以运行垃圾回收作业，以便删除镜像（悬空的 manifest 和未引用的 blob）并定期释放其空间。
Notary：支持使用 Docker Content Trust（基于 Notary）对容器镜像进行签名，以保证真实性和来源。此外，还可以激活阻止未签名镜像被部署的策略。
图形化用户门户：用户可以轻松浏览、搜索仓库和管理项目。
审计：对仓库的所有操作都会通过日志进行跟踪。
RESTful API：提供 RESTful API 以方便管理操作，并易于与外部系统集成。内置 Swagger UI 可用于探索和测试 API。
轻松部署：Harbor 可以通过 Docker Compose 以及 Helm Chart 进行部署，最近还添加了 Harbor Operator。

架构

了解 Harbor 的架构设计，请查阅文档 Harbor 架构概览。

API

Harbor RESTful API：提供 Harbor 大部分管理操作的 API，可用于以编程方式与 Harbor 集成。
- 第 1 部分：新增或更改的 API

安装与运行

系统要求：

在 Linux 主机上： docker 20.10.10-ce+ 和 docker-compose 1.18.0+。

下载 Harbor 发行版 的二进制文件，并按照 安装与配置指南 安装 Harbor。

如果要在 Kubernetes 上部署 Harbor，请使用 Harbor chart。

有关如何使用 Harbor 的更多详细信息，请参阅文档。

验证发布签名

从 v2.15.0 开始，Harbor 发布构件使用 Cosign 进行加密签名，以确保真实性和完整性。

从 Harbor 发布页面下载安装程序和签名包。

快速验证

# 安装 Cosign（v2.0+）
brew install sigstore/tap/cosign

# 验证签名
cosign verify-blob \
  --bundle harbor-offline-installer-v2.15.0.tgz.sigstore.json \
  --certificate-oidc-issuer https://token.actions.githubusercontent.com \
  --certificate-identity-regexp '^https://github.com/goharbor/harbor/.github/workflows/publish_release.yml@refs/tags/v.*$' \
  harbor-offline-installer-v2.15.0.tgz

预期输出： Verified OK
完整验证指南： docs/signature-verification.md

OCI Distribution 一致性测试

查看 Harbor 的 OCI Distribution 一致性测试报告。

兼容性

兼容性列表文档提供了 Harbor 组件的兼容性信息。

社区

Twitter： @project_harbor
用户组： 加入 Harbor 用户邮件组：harbor-users@lists.cncf.io 获取 Harbor 新闻、功能、发布的更新，或提供建议和反馈。
开发者组： 加入 Harbor 开发者邮件组：harbor-dev@lists.cncf.io 讨论 Harbor 开发和贡献。
Slack： 加入 Harbor 社区进行讨论和提问：云原生计算基金会，频道：#harbor 和 #harbor-dev

演示

在线演示 - 一个安装了最新稳定版 Harbor 的演示环境。更多信息请参考此页面。
视频演示 - Harbor 功能演示，持续更新。

合作伙伴与用户

用户列表请参阅 ADOPTERS.md。

安全

安全审计

2019 年 10 月，第三方安全审计由 Cure53 完成。您可以在此查看完整报告。

报告安全漏洞

如果您在 Harbor 中发现了安全相关问题、漏洞或潜在漏洞，请将漏洞详细信息告知 Harbor 安全团队。我们会发送确认邮件以确认收到您的报告，并在我们肯定或否定地确认问题后发送另一封邮件。

更多详细信息请参阅完整的安全发布流程。

许可证

Harbor 在 Apache 2 许可证下可用。

本项目使用的开源组件可能有额外的许可条款。这些开源组件的官方 Docker 镜像和许可条款可在以下位置找到：

Photon OS 1.0：Docker 镜像，许可证

Fossa 状态

参考资料

Harbor
参考资料

graphify 一个面向 AI 编码助手的技能

Thu, 09 Apr 2026 13:01:55 +0000

graphify

一个面向 AI 编码助手的技能。 在 Claude Code、Codex、OpenCode、OpenClaw、Factory Droid 或 Trae 中输入 /graphify，它会读取你的文件、构建知识图谱，并把原本不明显的结构关系还给你。更快理解代码库，找到架构决策背后的”为什么”。

完全多模态。你可以直接丢进去代码、PDF、Markdown、截图、流程图、白板照片，甚至其他语言的图片 —— graphify 会用 Claude vision 从这些内容中提取概念和关系，并把它们连接到同一张图里。

Andrej Karpathy 会维护一个 /raw 文件夹，把论文、推文、截图和笔记都丢进去。graphify 就是在解决这类问题 —— 相比直接读取原始文件，每次查询的 token 消耗可降低 71.5 倍，结果还能跨会话持久保存，并且会明确区分哪些内容是实际发现的，哪些只是合理推断。

/graphify .                        # 可用于任意目录：代码库、笔记、论文都可以

graphify-out/
├── graph.html       可交互图谱：可点节点、搜索、按社区过滤
├── GRAPH_REPORT.md  God nodes、意外连接、建议提问
├── graph.json       持久化图谱：数周后仍可查询，无需重新读原始文件
└── cache/           SHA256 缓存：重复运行时只处理变更过的文件

工作原理

graphify 分两轮执行。第一轮是确定性的 AST 提取，对代码文件做结构分析（类、函数、导入、调用图、docstring、解释性注释），这一轮不需要 LLM。第二轮会并行调用 Claude 子代理处理文档、论文和图片，从中提取概念、关系和设计动机。最后把两边结果合并到一个 NetworkX 图里，用 Leiden 社区发现算法做聚类，并导出成可交互 HTML、可查询 JSON，以及一份人类可读的审计报告。

聚类是基于图拓扑完成的，不依赖 embeddings。 Leiden 按边密度发现社区。Claude 抽取出的语义相似边（semantically_similar_to，标记为 INFERRED）本来就存在于图中，所以会直接影响社区划分。图结构本身就是相似性信号，不需要额外的 embedding 步骤，也不需要向量数据库。

每条关系都会被标记为 EXTRACTED（直接在源材料中找到）、INFERRED（合理推断，并附带置信度分数）或 AMBIGUOUS（有歧义，需要复核）。所以你始终知道哪些是实际发现的，哪些是模型猜出来的。

安装

要求： Python 3.10+，并且使用以下平台之一：Claude Code、Codex、OpenCode、OpenClaw、Factory Droid 或 Trae

pip install graphifyy && graphify install

PyPI 包当前暂时叫 graphifyy，因为 graphify 这个名字还在回收中。CLI 命令和 skill 命令仍然都是 graphify。

平台支持

平台	安装命令
Claude Code	`graphify install`
Codex	`graphify install --platform codex`
OpenCode	`graphify install --platform opencode`
OpenClaw	`graphify install --platform claw`
Factory Droid	`graphify install --platform droid`
Trae	`graphify install --platform trae`
Trae CN	`graphify install --platform trae-cn`

Codex 用户还需要在 ~/.codex/config.toml 的 [features] 下打开 multi_agent = true，这样才能并行提取。OpenClaw 目前的并行 agent 支持还比较早期，所以使用顺序提取。Trae 使用 Agent 工具进行并行子代理调度，不支持 PreToolUse hook，因此 AGENTS.md 是其常驻机制。

然后打开你的 AI 编码助手，输入：

/graphify .

让助手始终优先使用图谱（推荐）

图构建完成后，在项目里运行一次：

平台	命令
Claude Code	`graphify claude install`
Codex	`graphify codex install`
OpenCode	`graphify opencode install`
OpenClaw	`graphify claw install`
Factory Droid	`graphify droid install`
Trae	`graphify trae install`
Trae CN	`graphify trae-cn install`

Claude Code 会做两件事：

在 CLAUDE.md 中写入一段规则，告诉 Claude 在回答架构问题前先读 graphify-out/GRAPH_REPORT.md
安装一个 PreToolUse hook（写入 settings.json），在每次 Glob 和 Grep 前触发

如果知识图谱存在，Claude 会先看到：“graphify: Knowledge graph exists. Read graphify-out/GRAPH_REPORT.md for god nodes and community structure before searching raw files.” —— 这样 Claude 会优先按图谱导航，而不是一上来就 grep 整个项目。

Codex、OpenCode、OpenClaw、Factory Droid、Trae 会把同样的规则写进项目根目录的 AGENTS.md。这些平台没有 PreToolUse hook，所以 AGENTS.md 是它们的常驻机制。

卸载时使用对应平台的 uninstall 命令即可（例如 graphify claude uninstall）。

常驻模式和显式触发有什么区别？

常驻 hook 会优先暴露 GRAPH_REPORT.md —— 这是一页式总结，包含 god nodes、社区结构和意外连接。你的助手在搜索文件前会先读它，因此会按结构导航，而不是按关键字乱搜。这已经能覆盖大部分日常问题。

/graphify query、/graphify path 和 /graphify explain 会更深入：它们会逐跳遍历底层 graph.json，追踪节点之间的精确路径，并展示边级别细节（关系类型、置信度、源位置）。当你想从图谱里精确回答某个问题，而不仅仅是获得整体感知时，就该用这些命令。

可以这样理解：常驻 hook 是先给助手一张地图，/graphify 这几个命令则是让它沿着地图精确导航。

手动安装（curl）

```bash mkdir -p ~/.claude/skills/graphify curl -fsSL https://raw.githubusercontent.com/safishamsi/graphify/v3/graphify/skill.md \ > ~/.claude/skills/graphify/SKILL.md ``` 把下面内容加到 `~/.claude/CLAUDE.md`： ``` - **graphify** (`~/.claude/skills/graphify/SKILL.md`) - any input to knowledge graph. Trigger: `/graphify` When the user types `/graphify`, invoke the Skill tool with `skill: "graphify"` before doing anything else. ```

用法

/graphify                          # 对当前目录运行
/graphify ./raw                    # 对指定目录运行
/graphify ./raw --mode deep        # 更激进地抽取 INFERRED 边
/graphify ./raw --update           # 只重新提取变更文件，并合并到已有图谱
/graphify ./raw --cluster-only     # 只重新聚类已有图谱，不重新提取
/graphify ./raw --no-viz           # 跳过 HTML，只生成 report + JSON
/graphify ./raw --obsidian         # 额外生成 Obsidian vault（可选）

/graphify add https://arxiv.org/abs/1706.03762        # 拉取论文、保存并更新图谱
/graphify add https://x.com/karpathy/status/...       # 拉取推文
/graphify add https://... --author "Name"             # 标记原作者
/graphify add https://... --contributor "Name"        # 标记是谁把它加入语料库的

/graphify query "what connects attention to the optimizer?"
/graphify query "what connects attention to the optimizer?" --dfs   # 追踪一条具体路径
/graphify query "what connects attention to the optimizer?" --budget 1500  # 把预算限制在 N tokens
/graphify path "DigestAuth" "Response"
/graphify explain "SwinTransformer"

/graphify ./raw --watch            # 文件变更时自动同步图谱（代码：立即更新；文档：提醒你）
/graphify ./raw --wiki             # 构建可供 agent 抓取的 wiki（index.md + 每个 community 一篇文章）
/graphify ./raw --svg              # 导出 graph.svg
/graphify ./raw --graphml          # 导出 graph.graphml（Gephi、yEd）
/graphify ./raw --neo4j            # 生成给 Neo4j 用的 cypher.txt
/graphify ./raw --neo4j-push bolt://localhost:7687    # 直接推送到运行中的 Neo4j
/graphify ./raw --mcp              # 启动 MCP stdio server

# git hooks - 跨平台，在 commit 和切分支后重建图谱
graphify hook install
graphify hook uninstall
graphify hook status

# 常驻助手规则 - 按平台区分
graphify claude install            # CLAUDE.md + PreToolUse hook（Claude Code）
graphify claude uninstall
graphify codex install             # AGENTS.md（Codex）
graphify opencode install          # AGENTS.md（OpenCode）
graphify claw install              # AGENTS.md（OpenClaw）
graphify droid install             # AGENTS.md（Factory Droid）
graphify trae install              # AGENTS.md（Trae）
graphify trae uninstall
graphify trae-cn install           # AGENTS.md（Trae CN）
graphify trae-cn uninstall

支持混合文件类型：

类型	扩展名	提取方式
代码	`.py .ts .js .go .rs .java .c .cpp .rb .cs .kt .scala .php`	tree-sitter AST + 调用图 + docstring / 注释中的 rationale
文档	`.md .txt .rst`	通过 Claude 提取概念、关系和设计动机
论文	`.pdf`	引文挖掘 + 概念提取
图片	`.png .jpg .webp .gif`	Claude vision —— 截图、图表、任意语言都可以

你会得到什么

God nodes —— 度最高的概念节点（整个系统最容易汇聚到的地方）

意外连接 —— 按综合得分排序。代码-论文之间的边会比代码-代码边权重更高。每条结果都会附带一段人话解释。

建议提问 —— 图谱特别擅长回答的 4 到 5 个问题。

“为什么” —— docstring、行内注释（# NOTE:、# IMPORTANT:、# HACK:、# WHY:）以及文档里的设计动机都会被抽取成 rationale_for 节点。不只是知道代码“做了什么”，还能知道“为什么要这么写”。

置信度分数 —— 每条 INFERRED 边都有 confidence_score（0.0-1.0）。你不只知道哪些是猜出来的，还知道模型对这个猜测有多有把握。EXTRACTED 边恒为 1.0。

语义相似边 —— 跨文件的概念连接，即使结构上没有直接依赖也能建立关联。比如两个函数做的是同一类问题但彼此没有调用，或者某个代码类和某篇论文里的算法概念本质相同。

超边（Hyperedges） —— 用来表达 3 个以上节点的群组关系，这是普通两两边表达不出来的。比如：一组类共同实现一个协议、认证链路里的一组函数、同一篇论文某一节里的多个概念共同组成一个想法。

Token 基准 —— 每次运行后都会自动打印。对混合语料（Karpathy 的仓库 + 论文 + 图片），每次查询的 token 消耗可以比直接读原文件少 71.5 倍。第一次运行需要先提取并建图，这一步会花 token；后续查询直接读取压缩后的图谱，节省会越来越明显。SHA256 缓存保证重复运行时只重新处理变更文件。

自动同步（--watch）—— 在后台终端里跑着，代码库一变化，图谱就会跟着更新。代码文件保存会立刻触发重建（只走 AST，不用 LLM）；文档/图片变更则会提醒你跑 --update 进行 LLM 再提取。

Git hooks（graphify hook install）—— 安装 post-commit 和 post-checkout hook。每次 commit 后、每次切分支后都会自动重建图谱，不需要额外开一个后台进程。

Wiki（--wiki）—— 为每个 community 和 god node 生成类似维基百科的 Markdown 文章，并提供 index.md 作为入口。任何 agent 只要读 index.md，就能通过普通文件导航整个知识库，而不必直接解析 JSON。

Worked examples

语料	文件数	压缩比	输出
Karpathy 的仓库 + 5 篇论文 + 4 张图片	52	71.5x	`worked/karpathy-repos/`
graphify 源码 + Transformer 论文	4	5.4x	`worked/mixed-corpus/`
httpx（合成 Python 库）	6	~1x	`worked/httpx/`

Token 压缩效果会随着语料规模增大而更明显。6 个文件本来就塞得进上下文窗口，所以 graphify 在这种场景里的价值更多是结构清晰度，而不是 token 压缩。到了 52 个文件（代码 + 论文 + 图片）这种规模，就能做到 71x+。每个 worked/ 目录里都带了原始输入和真实输出（GRAPH_REPORT.md、graph.json），你可以自己跑一遍核对数字。

隐私

graphify 会把文档、论文和图片的内容发送给你所用 AI 编码助手背后的模型 API 来做语义提取 —— 可能是 Anthropic（Claude Code）、OpenAI（Codex），或者你当前平台使用的其他提供方。代码文件则完全在本地通过 tree-sitter AST 处理，不会把代码内容发出去。项目本身没有任何遥测、使用跟踪或分析。唯一的网络请求就是语义提取阶段调用你平台自己的模型 API，使用的也是你自己的 API key。

技术栈

NetworkX + Leiden（graspologic）+ tree-sitter + vis.js。语义提取由 Claude（Claude Code）、GPT-4（Codex）或你当前平台所运行的模型完成。不需要 Neo4j，不需要 server，整体是纯本地运行。

贡献

**Worked examples** 是最能建立信任的贡献方式。对一个真实语料跑 `/graphify`，把输出保存到 `worked/{slug}/`，再写一份诚实的 `review.md`，评价图谱哪些地方做得对、哪些地方做得不对，然后提交 PR。 **提取 bug** —— 提 issue 时请附上输入文件、对应的缓存项（`graphify-out/cache/`）以及它漏提取或瞎编了什么。模块职责和新增语言的方法见 [ARCHITECTURE.md](ARCHITECTURE.md)。

参考资料

graphify
参考资料

Archon 首个面向AI编码的开源编排器构建工具。让AI编码变得确定且可重复。

Thu, 09 Apr 2026 13:01:55 +0000

Archon

首个面向AI编码的开源编排器构建工具。让AI编码变得确定且可重复。

Archon 是一个面向 AI 编码代理的工作流引擎。将您的开发流程定义为 YAML 工作流 —— 规划、实现、验证、代码审查、PR 创建 —— 并在所有项目中可靠地运行它们。

就像 Dockerfile 为基础设施所做的那样，GitHub Actions 为 CI/CD 所做的那样 —— Archon 为 AI 编码工作流做到了这一点。可以把它想象成 n8n，但是为软件开发量身定制。

为什么选择 Archon？

当您让 AI 代理“修复这个 bug”时，结果取决于模型当时的状态。它可能会跳过规划。可能会忘记运行测试。可能会写出忽略您模板的 PR 描述。每次运行都不一样。

Archon 解决了这个问题。将您的开发过程编码为一个工作流。工作流定义了阶段、验证门禁和工件。AI 在每个步骤中填充智能，但结构是确定的，并且由您掌控。

可重复 —— 相同的工作流，相同的顺序，每次都是。规划、实现、验证、审查、PR。
隔离 —— 每次工作流运行都会获得自己的 git worktree。并行运行 5 个修复任务，无冲突。
即抛即忘 —— 启动一个工作流，去做其他工作。回来时就能看到一个带有审查评论的已完成 PR。
可组合 —— 将确定性节点（bash 脚本、测试、git 操作）与 AI 节点（规划、代码生成、审查）混合使用。AI 只在能增加价值的地方运行。
可移植 —— 在 .archon/workflows/ 中定义一次工作流，提交到您的仓库中。它们从 CLI、Web UI、Slack、Telegram 或 GitHub 上的运行方式都是一样的。

它看起来是什么样

下面是一个 Archon 工作流的示例，它会进行规划，循环实现直到测试通过，然后获得您的批准，最后创建 PR：

# .archon/workflows/build-feature.yaml
nodes:
  - id: plan
    prompt: "探索代码库并创建实现计划"

  - id: implement
    depends_on: [plan]
    loop:                                      # AI 循环 - 迭代直到完成
      prompt: "阅读计划。实现下一个任务。运行验证。"
      until: ALL_TASKS_COMPLETE
      fresh_context: true                      # 每次迭代都是全新会话

  - id: run-tests
    depends_on: [implement]
    bash: "bun run validate"                   # 确定性 - 无 AI

  - id: review
    depends_on: [run-tests]
    prompt: "对照计划审查所有更改。修复任何问题。"

  - id: approve
    depends_on: [review]
    loop:                                      # 人工批准门禁
      prompt: "展示更改以供审查。处理任何反馈。"
      until: APPROVED
      interactive: true                        # 暂停并等待人工输入

  - id: create-pr
    depends_on: [approve]
    prompt: "推送更改并创建拉取请求"

告诉您的编码代理您想要什么，Archon 会处理其余部分：

您：使用 archon 为设置页面添加深色模式

代理：我将为此运行 archon-idea-to-pr 工作流。
       → 创建隔离 worktree，分支 archon/task-dark-mode...
       → 规划中...
       → 实现中（任务 1/4）...
       → 实现中（任务 2/4）...
       → 测试失败 - 迭代中...
       → 经过 2 次迭代后测试通过
       → 代码审查完成 - 0 个问题
       → PR 已就绪：https://github.com/you/project/pull/47

先前版本

正在寻找基于 Python 的原始 Archon（任务管理 + RAG）？它完整保留在 archive/v1-task-management-rag 分支中。

快速开始

大多数用户应该从完整设置开始 —— 它会引导您完成凭据配置，将 Archon 技能安装到您的项目中，并为您提供 Web 仪表板。

已经有 Claude Code 并且只想要 CLI？ 跳转到快速安装。

完整设置（5 分钟）

克隆仓库并使用引导式设置向导。这将配置凭据、平台集成，并将 Archon 技能复制到您的目标项目中。

前置条件 - Bun、Claude Code 和 GitHub CLI

**Bun** - [bun.sh](https://bun.sh) ```bash # macOS/Linux curl -fsSL https://bun.sh/install | bash # Windows (PowerShell) irm bun.sh/install.ps1 | iex ``` **GitHub CLI** - [cli.github.com](https://cli.github.com/) ```bash # macOS brew install gh # Windows (via winget) winget install GitHub.cli # Linux (Debian/Ubuntu) sudo apt install gh ``` **Claude Code** - [claude.ai/code](https://claude.ai/code) ```bash # macOS/Linux/WSL curl -fsSL https://claude.ai/install.sh | bash # Windows (PowerShell) irm https://claude.ai/install.ps1 | iex ```

git clone https://github.com/coleam00/Archon
cd Archon
bun install
claude

然后说：“Set up Archon”（设置 Archon）

设置向导会引导您完成所有步骤：CLI 安装、身份验证、平台选择，并将 Archon 技能复制到您的目标仓库。

快速安装（30 秒）

已经设置好了 Claude Code？安装独立的 CLI 二进制文件并跳过向导。

macOS / Linux

curl -fsSL https://archon.diy/install | bash

Windows (PowerShell)

irm https://archon.diy/install.ps1 | iex

Homebrew

brew install coleam00/archon/archon

开始使用 Archon

完成任一安装路径后，进入您的项目并开始工作：

cd /path/to/your/project
claude

使用 archon 修复 issue #42

我有哪些 archon 工作流？分别在什么情况下使用？

编码代理会为您处理工作流选择、分支命名和 worktree 隔离。项目在首次使用时会被自动注册。

重要提示： 始终从您的目标仓库运行 Claude Code，而不是从 Archon 仓库。设置向导会将 Archon 技能复制到您的项目中，以便它可以从那里工作。

Web UI

Archon 包含一个 Web 仪表板，用于与您的编码代理聊天、运行工作流和监控活动。要启动它，请让您的编码代理从 Archon 仓库运行前端，或者自己从仓库根目录运行 bun run dev。

通过单击聊天侧边栏中“项目”旁边的 + 来注册一个项目 —— 输入 GitHub URL 或本地路径。然后开始对话、调用工作流，并实时查看进度。

关键页面：

聊天 - 带有实时流式传输和工具调用可视化的对话界面
仪表板 - 用于监控运行中工作流的任务控制中心，可按项目、状态和日期筛选历史记录
工作流构建器 - 用于创建带有循环节点的 DAG 工作流的可视化拖放编辑器
工作流执行 - 任何正在运行或已完成工作流的分步进度视图

监控中心： 侧边栏显示来自所有平台的对话 —— 不仅仅是 Web。从 CLI 启动的工作流、来自 Slack 或 Telegram 的消息、GitHub issue 交互 —— 所有内容都集中在一个地方。

有关完整文档，请参阅 Web UI 指南。

您可以自动化什么？

Archon 附带了用于常见开发任务的工作流：

工作流	功能
`archon-assist`	通用问答、调试、探索 —— 带有所有工具的完整 Claude Code 代理
`archon-fix-github-issue`	分类问题 → 调查/规划 → 实现 → 验证 → PR → 智能审查 → 自我修复
`archon-idea-to-pr`	功能创意 → 规划 → 实现 → 验证 → PR → 5 路并行审查 → 自我修复
`archon-plan-to-pr`	执行现有计划 → 实现 → 验证 → PR → 审查 → 自我修复
`archon-issue-review-full`	全面的修复 + 针对 GitHub issue 的多代理完整审查流程
`archon-smart-pr-review`	分类 PR 复杂度 → 运行针对性审查代理 → 综合发现
`archon-comprehensive-pr-review`	多代理 PR 审查（5 个并行审查者）并自动修复
`archon-create-issue`	分类问题 → 收集上下文 → 调查 → 创建 GitHub issue
`archon-validate-pr`	对主分支和特性分支进行彻底的 PR 验证测试
`archon-resolve-conflicts`	检测合并冲突 → 分析双方 → 解决 → 验证 → 提交
`archon-feature-development`	根据计划实现功能 → 验证 → 创建 PR
`archon-architect`	架构扫描、降低复杂度、改善代码库健康度
`archon-refactor-safely`	带有类型检查钩子和行为验证的安全重构
`archon-ralph-dag`	PRD 实现循环 —— 迭代完成故事直到结束
`archon-remotion-generate`	使用 AI 生成或修改 Remotion 视频合成
`archon-test-loop-dag`	循环节点测试工作流 —— 迭代计数器直到完成
`archon-piv-loop`	引导式计划-实现-验证循环，迭代之间有人工审查

Archon 附带 17 个默认工作流 —— 运行 archon workflow list 或描述您的需求，路由器会选择合适的工作流。

或者定义您自己的工作流。 默认工作流是很棒的起点 —— 从 .archon/workflows/defaults/ 复制一个并自定义它。工作流是 .archon/workflows/ 中的 YAML 文件，命令是 .archon/commands/ 中的 markdown 文件。您仓库中同名文件会覆盖捆绑的默认文件。提交它们 —— 您的整个团队将运行相同的流程。

请参阅编写工作流和编写命令。

添加一个平台

Web UI 和 CLI 开箱即用。可选地连接一个聊天平台以实现远程访问：

平台	设置时间	指南
Telegram	5 分钟	Telegram 指南
Slack	15 分钟	Slack 指南
GitHub Webhooks	15 分钟	GitHub 指南
Discord	5 分钟	Discord 指南

架构

┌─────────────────────────────────────────────────────────┐
│  平台适配器（Web UI, CLI, Telegram, Slack,              │
│                    Discord, GitHub）                      │
└──────────────────────────┬──────────────────────────────┘
                           │
                           ▼
┌─────────────────────────────────────────────────────────┐
│                     编排器                               │
│          （消息路由与上下文管理）                          │
└─────────────┬───────────────────────────┬───────────────┘
              │                           │
      ┌───────┴────────┐          ┌───────┴────────┐
      │                │          │                │
      ▼                ▼          ▼                ▼
┌───────────┐  ┌────────────┐  ┌──────────────────────────┐
│  命令     │  │  工作流    │  │   AI 助手客户端           │
│  处理器   │  │  执行器    │  │      (Claude / Codex)     │
│  (Slash)  │  │  (YAML)    │  │                          │
└───────────┘  └────────────┘  └──────────────────────────┘
      │              │                      │
      └──────────────┴──────────────────────┘
                           │
                           ▼
┌─────────────────────────────────────────────────────────┐
│              SQLite / PostgreSQL (7 张表)                │
│   代码库 • 对话 • 会话 • 工作流运行                       │
│   隔离环境 • 消息 • 工作流事件                            │
└─────────────────────────────────────────────────────────┘

文档

完整文档请访问 archon.diy。

主题	描述
快速开始	设置指南（Web UI 或 CLI）
Archon 之书	10 章叙事教程
CLI 参考	完整的 CLI 参考
编写工作流	创建自定义 YAML 工作流
编写命令	创建可复用的 AI 命令
配置	所有配置选项、环境变量、YAML 设置
AI 助手	Claude 和 Codex 设置详情
部署	Docker、VPS、生产环境设置
架构	系统设计和内部原理
故障排除	常见问题及修复

贡献

欢迎贡献！请查看开放的 issues 了解可以参与的工作。

在提交拉取请求之前，请阅读 CONTRIBUTING.md。

参考资料

Archon
参考资料

AI 对冲基金项目的目标是探索使用 AI 做出交易决策。

Thu, 09 Apr 2026 13:01:55 +0000

AI 对冲基金

这是一个由 AI 驱动的对冲基金的概念验证项目。项目的目标是探索使用 AI 做出交易决策。本项目仅用于教育目的，不适用于真实交易或投资。

该系统使用多个智能体协同工作：

Aswath Damodaran 智能体 —— 估值院长，专注于故事、数字和严谨估值
Ben Graham 智能体 —— 价值投资之父，只买入具有安全边际的隐藏宝石
Bill Ackman 智能体 —— 激进投资者，敢于重仓并推动变革
Cathie Wood 智能体 —— 成长投资女王，相信创新与颠覆的力量
Charlie Munger 智能体 —— 沃伦·巴菲特的搭档，只以合理价格买入卓越企业
Michael Burry 智能体 —— 《大空头》中的逆向投资者，猎取深度价值
Mohnish Pabrai 智能体 —— Dhandho 投资人，寻找低风险翻倍的机会
Nassim Taleb 智能体 —— 黑天鹅风险分析师，关注尾部风险、反脆弱性和非对称收益
Peter Lynch 智能体 —— 务实投资者，在日常生活企业中寻找“十倍股”
Phil Fisher 智能体 —— 细致的成长投资者，采用深度“闲聊”调研法
Rakesh Jhunjhunwala 智能体 —— 印度的大公牛
Stanley Druckenmiller 智能体 —— 宏观传奇，猎取具有成长潜力的非对称机会
Warren Buffett 智能体 —— 奥马哈先知，以公平价格寻找卓越公司
估值智能体 —— 计算股票的内在价值并生成交易信号
情绪智能体 —— 分析市场情绪并生成交易信号
基本面智能体 —— 分析基本面数据并生成交易信号
技术面智能体 —— 分析技术指标并生成交易信号
风险经理 —— 计算风险指标并设置仓位限制
投资组合经理 —— 做出最终交易决策并生成订单

注意：该系统实际上并不会执行任何交易。

免责声明

本项目仅用于教育和研究目的。

不适用于真实交易或投资
不提供任何投资建议或保证
创作者不对财务损失承担任何责任
投资决策请咨询财务顾问
过去的表现并不预示未来的结果

使用本软件即表示您同意仅将其用于学习目的。

安装方法

在运行 AI 对冲基金之前，你需要先安装它并设置好 API 密钥。以下步骤对于全栈 Web 应用和命令行界面都是通用的。

1. 克隆仓库

git clone https://github.com/virattt/ai-hedge-fund.git
cd ai-hedge-fund

2. 设置 API 密钥

创建用于存放 API 密钥的 .env 文件：

# 为你的 API 密钥创建 .env 文件（在根目录下）
cp .env.example .env

打开并编辑 .env 文件，添加你的 API 密钥：

# 用于运行 openai 托管的 LLM（gpt-4o、gpt-4o-mini 等）
OPENAI_API_KEY=your-openai-api-key

# 用于获取驱动对冲基金的金融数据
FINANCIAL_DATASETS_API_KEY=your-financial-datasets-api-key

重要：你必须至少设置一个 LLM API 密钥（例如 OPENAI_API_KEY、GROQ_API_KEY、ANTHROPIC_API_KEY 或 DEEPSEEK_API_KEY），对冲基金才能正常运行。

运行方法

⌨️ 命令行界面

你可以直接在终端中运行 AI 对冲基金。这种方式提供了更精细的控制，适用于自动化、脚本化和集成场景。

快速开始

安装 Poetry（如果尚未安装）：

curl -sSL https://install.python-poetry.org | python3 -

安装依赖：
```
poetry install
```

运行 AI 对冲基金

poetry run python src/main.py --ticker AAPL,MSFT,NVDA

你也可以指定 --ollama 标志，使用本地 LLM 运行 AI 对冲基金。

poetry run python src/main.py --ticker AAPL,MSFT,NVDA --ollama

你可以选择指定开始和结束日期，以便在特定时间段内做出决策。

poetry run python src/main.py --ticker AAPL,MSFT,NVDA --start-date 2024-01-01 --end-date 2024-03-01

运行回测器

poetry run python src/backtester.py --ticker AAPL,MSFT,NVDA

示例输出：

注意：--ollama、--start-date 和 --end-date 标志同样适用于回测器！

🖥️ Web 应用程序

运行 AI 对冲基金的新方式是通过我们的 Web 应用程序，它提供了用户友好的界面。对于更喜欢可视化界面而非命令行工具的用户，我们推荐使用这种方式。

请参阅此处关于如何安装和运行 Web 应用程序的详细说明。

如何贡献

Fork 本仓库
创建一个功能分支
提交你的更改
推送到分支
创建一个拉取请求

重要：请保持你的拉取请求小而专注。这将使审核和合并更容易。

功能请求

如果你有功能请求，请打开一个 issue 并确保它被标记为 enhancement。

许可证

本项目采用 MIT 许可证 —— 详情请参阅 LICENSE 文件。

参考资料

AI 对冲基金
参考资料

增强版 OpenClaw 与 MemOS 插件

Thu, 09 Apr 2026 13:01:55 +0000

MemOS

🎯 相比 OpenAI Memory 准确率提升 +43.70%
🏆 顶尖的长期记忆与个性化能力
💰 节省 35.24% 的记忆 token
_{LoCoMo 75.80 • LongMemEval +40.43% • PrefEval-10 +2568% • PersonaMem +40.75%}

🦞 增强版 OpenClaw 与 MemOS 插件

🦞 你的龙虾现在拥有了工作记忆系统 —— 选择云端或本地开始使用。

☁️ 云端插件 —— 托管式记忆服务

降低 72% 的 token 使用量 —— 智能记忆检索，无需加载完整聊天历史
多智能体记忆共享 —— 多个实例的智能体通过相同的 user_id 共享记忆，自动上下文交接

获取 API 密钥：MemOS 控制台完整教程 → MemOS-Cloud-OpenClaw-Plugin

🧠 本地插件 —— 100% 设备端记忆

零云端依赖 —— 所有数据保留在你的机器上，持久化本地 SQLite 存储
混合检索 + 任务与技能演化 —— FTS5 + 向量检索，自动任务摘要，可自我升级的可复用技能
多智能体协作 + 记忆查看器 —— 记忆隔离、技能共享、完整的 Web 仪表板（7 个管理页面）

🌐 主页 · 📖 文档 · 📦 NPM

📌 MemOS：面向 AI 智能体的记忆操作系统

MemOS 是一个面向大语言模型和 AI 智能体的记忆操作系统，统一了长期记忆的存储 / 检索 / 管理，实现了上下文感知和个性化的交互，内置知识库、多模态、工具记忆以及企业级优化。

主要特性

统一记忆 API：通过单一 API 完成记忆的添加、检索、编辑和删除 —— 以图结构组织，设计上可检查、可编辑，而非黑盒的嵌入存储。
多模态记忆：原生支持文本、图像、工具轨迹和人格，在同一个记忆系统中共同检索和推理。
多立方体知识库管理：将多个知识库作为可组合的记忆立方体进行管理，支持跨用户、项目和智能体的隔离、受控共享和动态组合。
通过 MemScheduler 异步写入：以毫秒级延迟异步执行记忆操作，确保高并发下的生产稳定性。
记忆反馈与修正：通过自然语言反馈来完善记忆 —— 随时间推移纠正、补充或替换已有记忆。

新闻

2026-03-08 · 🦞 MemOS OpenClaw 插件 —— 云端与本地 官方 OpenClaw 记忆插件正式发布。云端插件：托管式记忆服务，降低 72% token 使用量，支持多智能体记忆共享（MemOS-Cloud-OpenClaw-Plugin）。本地插件（v1.0.0）：100% 设备端记忆，基于 SQLite 持久化存储，混合检索（FTS5 + 向量），任务摘要与技能演化，多智能体协作，以及完整的记忆查看器仪表板。
2025-12-24 · 🎉 MemOS v2.0: 星尘（Stardust）发布 全面的知识库（文档/URL 解析 + 跨项目共享）、记忆反馈与精确删除、多模态记忆（图像/图表）、用于智能体规划的工具记忆、Redis Streams 调度 + 数据库优化、流式/非流式对话、MCP 升级，以及轻量级快速/完整部署。

✨ 新特性
**知识库与记忆** - 新增知识库支持，可从文档和 URL 中提取长期记忆 **反馈与记忆管理** - 新增自然语言反馈和记忆修正功能 - 新增按记忆 ID 删除记忆的 API - 新增 MCP 支持，用于记忆删除和反馈 **对话与检索** - 新增具备记忆感知的聊天 API - 新增通过自定义标签过滤记忆（云端与开源版） **多模态与工具记忆** - 新增工具记忆，记录工具使用历史 - 新增对对话和文档中的图像记忆支持

📈 改进
**数据与基础设施** - 升级数据库，提升稳定性和性能 **调度器** - 使用 Redis Streams 和队列隔离重构任务调度器 - 新增任务优先级、自动恢复和基于配额的调度 **部署与工程** - 新增轻量级部署，支持快速模式和完整模式

🐞 Bug 修复
**记忆调度与更新** - 修复旧版调度 API，确保正确的记忆隔离 - 修复记忆更新日志，正确显示新记忆
2025-08-07 · 🎉 MemOS v1.0.0（MemCube）发布 首个 MemCube 版本，包含文字游戏示例、LongMemEval 评估、BochaAISearchRetriever 集成、搜索能力增强以及官方 Playground 上线。

✨ 新特性
**Playground** - 扩展 Playground 功能与算法性能 **MemCube 构建** - 新增基于 MemCube 小说的文字游戏示例 **扩展评估集** - 新增 LongMemEval 评估结果和脚本

📈 改进
**明文记忆** - 集成 Bocha 进行联网搜索 - 扩展图数据库支持 - 为树状结构的明文记忆搜索接口增加上下文理解能力

🐞 Bug 修复
**KV 缓存拼接** - 修复 concat_cache 方法 **明文记忆** - 修复图搜索相关问题
2025-07-07 · 🎉 MemOS v1.0：星河（Stellar）预览版发布 面向大语言模型的 SOTA 记忆操作系统现已开源。
2025-07-04 · 🎉 MemOS 论文发布 MemOS: A Memory OS for AI System 已在 arXiv 上发布。
2024-07-04 · 🎉 Memory3 模型在 WAIC 2024 发布 采用记忆分层架构的 Memory3 模型在 2024 世界人工智能大会上正式亮相。

🚀 快速入门指南

☁️ 1、云端 API（托管）

获取 API 密钥

在 MemOS 控制台注册
进入 API Keys 并复制你的密钥

后续步骤

MemOS Cloud 快速上手连接 MemOS Cloud，几分钟内启用记忆功能。
MemOS Cloud 平台探索云端控制台、功能和工作流程。

🖥️ 2、自托管（本地/私有）

获取代码仓库。

 git clone https://github.com/MemTensor/MemOS.git
 cd MemOS
 pip install -r ./docker/requirements.txt

配置 docker/.env.example 并复制到 MemOS/.env
- OPENAI_API_KEY、MOS_EMBEDDER_API_KEY、MEMRADER_API_KEY 等可以通过 百炼 申请。
- 在 MemOS/.env 文件中填写相应的配置。
- 支持的 LLM 提供商：OpenAI、Azure OpenAI、通义千问（DashScope）、DeepSeek、MiniMax、Ollama、HuggingFace、vLLM。设置 MOS_CHAT_MODEL_PROVIDER 选择后端（例如 openai、qwen、deepseek、minimax）。
启动服务。

通过 Docker 启动
提示：请确保 Docker Compose 已成功安装，并在执行以下命令前已进入 docker 目录（通过 cd docker）。
```
# 进入 docker 目录
docker compose up
```
详细步骤请参阅 Docker 参考。
通过 uvicorn 命令行界面（CLI）启动
提示：请确保在执行以下命令前 Neo4j 和 Qdrant 已运行。
```
cd src
uvicorn memos.api.server_api:app --host 0.0.0.0 --port 8001 --workers 1
```
详细集成步骤请参阅 CLI 参考。

基本用法（自托管）

添加用户消息

import requests
import json

data = {
    "user_id": "8736b16e-1d20-4163-980b-a5063c3facdc",
    "mem_cube_id": "b32d0977-435d-4828-a86f-4f47f8b55bca",
    "messages": [
        {
            "role": "user",
            "content": "我喜欢草莓"
        }
    ],
    "async_mode": "sync"
}
headers = {
    "Content-Type": "application/json"
}
url = "http://localhost:8000/product/add"

res = requests.post(url=url, headers=headers, data=json.dumps(data))
print(f"结果: {res.json()}")

搜索用户记忆

import requests
import json

data = {
    "query": "我喜欢什么",
    "user_id": "8736b16e-1d20-4163-980b-a5063c3facdc",
    "mem_cube_id": "b32d0977-435d-4828-a86f-4f47f8b55bca"
}
headers = {
    "Content-Type": "application/json"
}
url = "http://localhost:8000/product/search"

res = requests.post(url=url, headers=headers, data=json.dumps(data))
print(f"结果: {res.json()}")

📚 资源

Awesome-AI-Memory 这是一个专注于大语言模型记忆及记忆系统资源的精选仓库。它系统性地收集了相关研究论文、框架、工具和实践见解。该仓库旨在整理和展示快速演进的 LLM 记忆研究图景，连接自然语言处理、信息检索、智能体系统和认知科学等多个研究方向。
开始探索 👉 IAAR-Shanghai/Awesome-AI-Memory
MemOS Cloud OpenClaw 插件 面向 MemOS Cloud 的官方 OpenClaw 生命周期插件。它在智能体启动前自动从 MemOS 召回上下文，并在智能体运行结束后将对话保存回 MemOS。
开始使用 👉 MemTensor/MemOS-Cloud-OpenClaw-Plugin

💬 社区与支持

加入我们的社区，提出问题、分享项目并与其他开发者交流。

GitHub Issues：在我们的 GitHub Issues 中报告 Bug 或请求功能。
GitHub Pull Requests：通过 Pull Requests 贡献代码改进。
GitHub Discussions：参与 GitHub Discussions 提问或分享想法。
Discord：加入我们的 Discord 服务器。
微信：扫描二维码加入微信群。

📜 引用

[!NOTE] 我们于 2025 年 5 月 28 日公开发布了短版论文，这是最早提出大语言模型记忆操作系统概念的工作。

如果你在研究中使用 MemOS，请引用我们的论文。

@article{li2025memos_long,
  title={MemOS: A Memory OS for AI System},
  author={Li, Zhiyu and Song, Shichao and Xi, Chenyang and Wang, Hanyu and Tang, Chen and Niu, Simin and Chen, Ding and Yang, Jiawei and Li, Chunyu and Yu, Qingchen and Zhao, Jihao and Wang, Yezhaohui and Liu, Peng and Lin, Zehao and Wang, Pengyuan and Huo, Jiahao and Chen, Tianyi and Chen, Kai and Li, Kehang and Tao, Zhen and Ren, Junpeng and Lai, Huayi and Wu, Hao and Tang, Bo and Wang, Zhenren and Fan, Zhaoxin and Zhang, Ningyu and Zhang, Linfeng and Yan, Junchi and Yang, Mingchuan and Xu, Tong and Xu, Wei and Chen, Huajun and Wang, Haofeng and Yang, Hongkang and Zhang, Wentao and Xu, Zhi-Qin John and Chen, Siheng and Xiong, Feiyu},
  journal={arXiv preprint arXiv:2507.03724},
  year={2025},
  url={https://arxiv.org/abs/2507.03724}
}

@article{li2025memos_short,
  title={MemOS: An Operating System for Memory-Augmented Generation (MAG) in Large Language Models},
  author={Li, Zhiyu and Song, Shichao and Wang, Hanyu and Niu, Simin and Chen, Ding and Yang, Jiawei and Xi, Chenyang and Lai, Huayi and Zhao, Jihao and Wang, Yezhaohui and others},
  journal={arXiv preprint arXiv:2505.22101},
  year={2025},
  url={https://arxiv.org/abs/2505.22101}
}

@article{yang2024memory3,
author = {Yang, Hongkang and Zehao, Lin and Wenjin, Wang and Wu, Hao and Zhiyu, Li and Tang, Bo and Wenqiang, Wei and Wang, Jinbo and Zeyun, Tang and Song, Shichao and Xi, Chenyang and Yu, Yu and Kai, Chen and Xiong, Feiyu and Tang, Linpeng and Weinan, E},
title = {Memory$^3$: Language Modeling with Explicit Memory},
journal = {Journal of Machine Learning},
year = {2024},
volume = {3},
number = {3},
pages = {300--346},
issn = {2790-2048},
doi = {https://doi.org/10.4208/jml.240708},
url = {https://global-sci.com/article/91443/memory3-language-modeling-with-explicit-memory}
}

🙌 贡献

我们欢迎社区的贡献！请阅读我们的贡献指南开始。

📄 许可证

MemOS 使用 Apache 2.0 许可证。

参考资料

MemOS
参考资料

Kronos：金融市场语言的基础模型

Thu, 09 Apr 2026 13:01:55 +0000

Kronos

金融市场语言的基础模型

Kronos 是首个面向金融K线（K-line）的开源基础模型，基于超过45家全球交易所的数据训练而成。

</div>

📰 新闻

🚩 [2025.11.10] Kronos 被 AAAI 2026 接收。
🚩 [2025.08.17] 我们发布了微调脚本！请查看它们以使 Kronos 适配您自己的任务。
🚩 [2025.08.02] 我们的论文现已在 arXiv 上提供。

## 📜 引言 **Kronos** 是一个仅解码器的基础模型系列，专门针对金融市场的“语言”——K线序列进行预训练。与通用时间序列基础模型（TSFM）不同，Kronos 旨在处理金融数据独特的高噪声特性。它采用了一种新颖的两阶段框架： 1. 首先，一个专门的标记器将连续的多维K线数据（OHLCV）量化为**层次化的离散标记**。 2. 然后，一个大型自回归Transformer在这些标记上进行预训练，使其能够作为统一模型服务于多种量化任务。

## ✨ 在线演示我们搭建了一个在线演示来可视化 Kronos 的预测结果。该网页展示了**BTC/USDT**交易对未来24小时的预测。 **👉 [在此访问在线演示](https://shiyu-coder.github.io/Kronos-demo/)** ## 📦 模型仓库我们发布了一系列不同容量的预训练模型，以满足不同的计算和应用需求。所有模型均可从 Hugging Face Hub 直接获取。 | 模型 | 标记器 | 上下文长度 | 参数量 | 开源状态 | |--------------|---------------------------------------------------------------------------------| -------------- | ------ |---------------------------------------------------------------------------| | Kronos-mini | [Kronos-Tokenizer-2k](https://huggingface.co/NeoQuasar/Kronos-Tokenizer-2k) | 2048 | 4.1M | ✅ [NeoQuasar/Kronos-mini](https://huggingface.co/NeoQuasar/Kronos-mini) | | Kronos-small | [Kronos-Tokenizer-base](https://huggingface.co/NeoQuasar/Kronos-Tokenizer-base) | 512 | 24.7M | ✅ [NeoQuasar/Kronos-small](https://huggingface.co/NeoQuasar/Kronos-small) | | Kronos-base | [Kronos-Tokenizer-base](https://huggingface.co/NeoQuasar/Kronos-Tokenizer-base) | 512 | 102.3M | ✅ [NeoQuasar/Kronos-base](https://huggingface.co/NeoQuasar/Kronos-base) | | Kronos-large | [Kronos-Tokenizer-base](https://huggingface.co/NeoQuasar/Kronos-Tokenizer-base) | 512 | 499.2M | ❌ | ## 🚀 快速开始 ### 安装 1. 安装 Python 3.10+，然后安装依赖： ```shell pip install -r requirements.txt ``` ### 📈 进行预测使用 `KronosPredictor` 类可以轻松进行 Kronos 预测。它处理数据预处理、归一化、预测和逆归一化，让您只需几行代码即可从原始数据得到预测结果。 **重要提示**：`Kronos-small` 和 `Kronos-base` 的 `max_context` 为 **512**。这是模型能处理的最大序列长度。为获得最佳性能，建议您的输入数据长度（即 `lookback`）不超过此限制。`KronosPredictor` 会自动处理较长上下文的截断。以下是进行首次预测的分步指南。 #### 1. 加载标记器和模型首先，从 Hugging Face Hub 加载预训练的 Kronos 模型及其对应的标记器。 ```python from model import Kronos, KronosTokenizer, KronosPredictor # 从 Hugging Face Hub 加载 tokenizer = KronosTokenizer.from_pretrained("NeoQuasar/Kronos-Tokenizer-base") model = Kronos.from_pretrained("NeoQuasar/Kronos-small") ``` #### 2. 实例化预测器创建 `KronosPredictor` 实例，传入模型、标记器和目标设备。 ```python # 初始化预测器 predictor = KronosPredictor(model, tokenizer, max_context=512) ``` #### 3. 准备输入数据 `predict` 方法需要三个主要输入： - `df`：包含历史K线数据的 pandas DataFrame。必须包含 `['open', 'high', 'low', 'close']` 列。`volume` 和 `amount` 是可选的。 - `x_timestamp`：与 `df` 中历史数据对应的时间戳的 pandas Series。 - `y_timestamp`：您想要预测的未来时段的时间戳的 pandas Series。 ```python import pandas as pd # 加载您的数据 df = pd.read_csv("./data/XSHG_5min_600977.csv") df['timestamps'] = pd.to_datetime(df['timestamps']) # 定义上下文窗口和预测长度 lookback = 400 pred_len = 120 # 为预测器准备输入 x_df = df.loc[:lookback-1, ['open', 'high', 'low', 'close', 'volume', 'amount']] x_timestamp = df.loc[:lookback-1, 'timestamps'] y_timestamp = df.loc[lookback:lookback+pred_len-1, 'timestamps'] ``` #### 4. 生成预测调用 `predict` 方法生成预测。您可以使用 `T`、`top_p` 和 `sample_count` 等参数控制采样过程，以实现概率预测。 ```python # 生成预测 pred_df = predictor.predict( df=x_df, x_timestamp=x_timestamp, y_timestamp=y_timestamp, pred_len=pred_len, T=1.0, # 采样温度 top_p=0.9, # 核采样概率 sample_count=1 # 生成并平均的预测路径数量 ) print("预测数据头：") print(pred_df.head()) ``` `predict` 方法返回一个 pandas DataFrame，其中包含 `open`、`high`、`low`、`close`、`volume` 和 `amount` 的预测值，索引为您提供的 `y_timestamp`。为了高效处理多个时间序列，Kronos 提供了 `predict_batch` 方法，支持同时对多个数据集进行并行预测。当您需要一次性预测多个资产或时间段时，此方法特别有用。 ```python # 准备用于批量预测的多个数据集 df_list = [df1, df2, df3] # DataFrame 列表 x_timestamp_list = [x_ts1, x_ts2, x_ts3] # 历史时间戳列表 y_timestamp_list = [y_ts1, y_ts2, y_ts3] # 未来时间戳列表 # 生成批量预测 pred_df_list = predictor.predict_batch( df_list=df_list, x_timestamp_list=x_timestamp_list, y_timestamp_list=y_timestamp_list, pred_len=pred_len, T=1.0, top_p=0.9, sample_count=1, verbose=True ) # pred_df_list 包含与输入顺序相同的预测结果 for i, pred_df in enumerate(pred_df_list): print(f"序列 {i} 的预测：") print(pred_df.head()) ``` **批量预测的重要要求：** - 所有序列必须具有相同的历史长度（回看窗口） - 所有序列必须具有相同的预测长度（`pred_len`） - 每个 DataFrame 必须包含所需的列：`['open', 'high', 'low', 'close']` - `volume` 和 `amount` 列是可选的，如果缺失将用零填充 `predict_batch` 方法利用 GPU 并行性实现高效处理，并自动为每个序列独立处理归一化和逆归一化。 #### 5. 示例和可视化有关包含数据加载、预测和绘图的完整可运行脚本，请参阅 [`examples/prediction_example.py`](examples/prediction_example.py)。运行此脚本将生成一个比较真实数据与模型预测的图表，类似于下图所示：

此外，我们提供了一个在没有成交量和成交额数据的情况下进行预测的脚本，可以在 [`examples/prediction_wo_vol_example.py`](examples/prediction_wo_vol_example.py) 中找到。 ## 🔧 在自有数据上微调（以A股市场为例）我们提供了一个完整的流程，用于在您自己的数据集上微调 Kronos。作为示例，我们演示如何使用 [Qlib](https://github.com/microsoft/qlib) 准备中国A股市场的数据并进行简单的回测。 > **免责声明：** 此流程旨在作为演示来说明微调过程。它是一个简化示例，并非生产就绪的量化交易系统。稳健的量化策略需要更复杂的技术，例如投资组合优化和风险因子中性化，以实现稳定的Alpha。微调过程分为四个主要步骤： 1. **配置**：设置路径和超参数。 2. **数据准备**：使用 Qlib 处理和拆分数据。 3. **模型微调**：微调标记器和预测器模型。 4. **回测**：评估微调后模型的性能。 ### 前提条件 1. 首先，确保您已安装 `requirements.txt` 中的所有依赖。 2. 此流程依赖于 `qlib`。请安装它： ```shell pip install pyqlib ``` 3. 您需要准备您的 Qlib 数据。按照 [官方 Qlib 指南](https://github.com/microsoft/qlib) 在本地下载和设置数据。示例脚本假设您使用的是日频数据。 ### 步骤 1：配置您的实验所有关于数据、训练和模型路径的设置都集中在 `finetune/config.py` 中。在运行任何脚本之前，请**根据您的环境修改以下路径**： * `qlib_data_path`：本地 Qlib 数据目录的路径。 * `dataset_path`：保存处理后的训练/验证/测试 pickle 文件的目录。 * `save_path`：保存模型检查点的基本目录。 * `backtest_result_path`：保存回测结果的目录。 * `pretrained_tokenizer_path` 和 `pretrained_predictor_path`：您要开始使用的预训练模型的路径（可以是本地路径或 Hugging Face 模型名称）。您还可以调整其他参数，如 `instrument`、`train_time_range`、`epochs` 和 `batch_size` 以适应您的特定任务。如果您不使用 [Comet.ml](https://www.comet.com/)，请设置 `use_comet = False`。 ### 步骤 2：准备数据集运行数据预处理脚本。此脚本将从您的 Qlib 目录加载原始市场数据，进行处理，拆分为训练集、验证集和测试集，并将它们保存为 pickle 文件。 ```shell python finetune/qlib_data_preprocess.py ``` 运行后，您将在配置中 `dataset_path` 指定的目录中找到 `train_data.pkl`、`val_data.pkl` 和 `test_data.pkl`。 ### 步骤 3：运行微调微调过程包括两个阶段：微调标记器，然后微调预测器。两个训练脚本都设计用于使用 `torchrun` 进行多GPU训练。 #### 3.1 微调标记器此步骤使标记器适应您特定领域的数据分布。 ```shell # 将 NUM_GPUS 替换为您要使用的 GPU 数量（例如 2） torchrun --standalone --nproc_per_node=NUM_GPUS finetune/train_tokenizer.py ``` 最佳标记器检查点将保存到 `config.py` 中配置的路径（由 `save_path` 和 `tokenizer_save_folder_name` 派生）。 #### 3.2 微调预测器此步骤微调用于预测任务的主要 Kronos 模型。 ```shell # 将 NUM_GPUS 替换为您要使用的 GPU 数量（例如 2） torchrun --standalone --nproc_per_node=NUM_GPUS finetune/train_predictor.py ``` 最佳预测器检查点将保存到 `config.py` 中配置的路径。 ### 步骤 4：通过回测进行评估最后，运行回测脚本以评估您微调后的模型。此脚本加载模型，在测试集上进行推理，生成预测信号（例如预测的价格变化），并运行一个简单的 top-K 策略回测。 ```shell # 指定用于推理的 GPU python finetune/qlib_test.py --device cuda:0 ``` 该脚本将在控制台中输出详细的性能分析，并生成一个显示您的策略与基准的累积收益率曲线的图表，类似于下图所示：

### 💡 从演示到生产：重要考量 * **原始信号 vs. 纯Alpha**：本演示中模型生成的信号是原始预测。在实际量化工作流中，这些信号通常会输入到投资组合优化模型中。该模型会施加约束以中性化常见风险因子（例如市场贝塔、规模和价值等风格因子）的暴露，从而分离出**“纯Alpha”**并提高策略的稳健性。 * **数据处理**：提供的 `QlibDataset` 是一个示例。对于不同的数据源或格式，您需要调整数据加载和预处理逻辑。 * **策略与回测复杂性**：此处使用的简单 top-K 策略是一个基本起点。生产级策略通常包含更复杂的逻辑，用于投资组合构建、动态头寸调整和风险管理（例如止损/止盈规则）。此外，高保真回测应细致地建模交易成本、滑点和市场冲击，以更准确地估计真实世界表现。 > **📝 AI生成的注释**：请注意，`finetune/` 目录中的许多代码注释是由 AI 助手（Gemini 2.5 Pro）为解释目的生成的。虽然它们旨在提供帮助，但可能包含不准确之处。我们建议将代码本身视为逻辑的权威来源。 ## 📖 引用如果您在研究中使用 Kronos，我们希望您引用我们的[论文](https://arxiv.org/abs/2508.02739)： ``` @misc{shi2025kronos, title={Kronos: A Foundation Model for the Language of Financial Markets}, author={Yu Shi and Zongliang Fu and Shuo Chen and Bohan Zhao and Wei Xu and Changshui Zhang and Jian Li}, year={2025}, eprint={2508.02739}, archivePrefix={arXiv}, primaryClass={q-fin.ST}, url={https://arxiv.org/abs/2508.02739}, } ``` # 参考资料 * any list {:toc}

SEO Machine 一个专门的 Claude Code 工作空间，用于为任何企业创建长篇幅、针对 SEO 优化的博客内容。该系统帮助您研究、撰写、分析和优化能够在搜索引擎中获得良好排名并服务目标受众的内容。

Wed, 08 Apr 2026 13:01:55 +0000

SEO Machine

一个专门的 Claude Code 工作空间，用于为任何企业创建长篇幅、针对 SEO 优化的博客内容。该系统帮助您研究、撰写、分析和优化能够在搜索引擎中获得良好排名并服务目标受众的内容。

概述

SEO Machine 基于 Claude Code 构建，提供：

自定义命令：/research、/write、/rewrite、/analyze-existing、/optimize、/performance-review、/publish-draft、/article、/priorities，以及专门的研究和着陆页命令
专业代理：内容分析器、SEO 优化器、元元素创建器、内部链接构建器、关键词映射器、编辑器、性能分析器、标题生成器、CRO 分析器、着陆页优化器
营销技能：26 项营销技能，涵盖文案撰写、CRO、A/B 测试、邮件序列、定价策略等
高级 SEO 分析：搜索意图检测、关键词密度与聚类、内容长度对比、可读性评分、SEO 质量评级（0-100）
数据集成：Google Analytics 4、Google Search Console、DataForSEO，提供实时效果洞察
上下文驱动：品牌声音、风格指南、SEO 指南和示例指导所有内容的生成
工作流组织：为话题、研究、草稿和已发布内容提供结构化的目录

快速开始

前置条件

已安装 Claude Code
Anthropic API 账户

安装

克隆此仓库：

git clone https://github.com/[your-username]/seomachine.git
cd seomachine

安装分析模块所需的 Python 依赖：

pip install -r data_sources/requirements.txt

这会安装：

Google Analytics / Search Console 集成
DataForSEO API 客户端
NLP 库（nltk、textstat）
机器学习库（scikit-learn）
网页抓取工具（beautifulsoup4）

在 Claude Code 中打开：
```
claude-code .
```
自定义上下文文件（重要！）：

所有上下文文件都以模板形式提供。请用您公司的信息填写：
- context/brand-voice.md - 定义您的品牌声音和消息传递 (参考 examples/castos/ 目录)
- context/writing-examples.md - 添加您网站上 3-5 篇优秀的博客文章作为示例
- context/features.md - 列出您产品/服务的功能和优势
- context/internal-links-map.md - 映射用于内部链接的关键页面
- context/style-guide.md - 填写您的风格偏好
- context/target-keywords.md - 添加您的关键词研究和话题集群
- context/competitor-analysis.md - 添加竞争对手分析和洞察
- context/seo-guidelines.md - 查看并调整 SEO 要求
快速上手：查看 examples/castos/ 目录，其中包含一个播客托管 SaaS 公司完整填写的所有上下文文件的实际示例。

工作流

创建新内容

1. 从研究开始

/research [话题]

功能：

执行关键词研究
分析前 10 名竞争对手
识别内容差距
创建全面的研究简报
保存到 /research/ 目录

示例：

/research B2B SaaS 的内容营销策略

2. 撰写文章

/write [话题或研究简报]

功能：

创建 2000-3000+ 字的 SEO 优化文章
保持 context/brand-voice.md 中定义的品牌声音
自然整合关键词
包含内部和外部链接
提供元元素（标题、描述、关键词）
自动触发优化代理
保存到 /drafts/ 目录

示例：

/write B2B SaaS 的内容营销策略

代理自动执行：撰写后，这些代理会自动分析内容：

SEO 优化器：页面 SEO 建议
元元素创建器：多个元标题/描述选项
内部链接器：具体的内部链接建议
关键词映射器：关键词位置和密度分析

3. 最终优化

/optimize [文章文件]

功能：

全面的 SEO 审计
验证所有元素符合要求
提供最终润色建议
生成发布就绪评分
创建优化报告

示例：

/optimize drafts/content-marketing-strategies-2025-10-29.md

更新现有内容

1. 分析现有文章

/analyze-existing [URL 或文件路径]

功能：

获取并分析当前内容
评估 SEO 效果
识别过时信息
评估竞争定位
提供内容健康评分（0-100）
推荐更新优先级和范围
保存分析结果到 /research/ 目录

示例：

/analyze-existing https://yoursite.com/blog/marketing-guide
/analyze-existing published/marketing-guide-2024-01-15.md

2. 重写/更新内容

/rewrite [话题或分析文件]

功能：

基于分析结果更新内容
刷新统计数据和示例
改进 SEO 优化
添加新章节填补空白
保留原文中有效的部分
追踪所做的更改
保存到 /rewrites/ 目录

示例：

/rewrite 营销指南

命令参考

`/research [话题]`

针对新内容的全面关键词和竞争研究。

输出：/research/brief-[话题]-[日期].md 研究简报

包含内容：

主要和次要关键词
竞争对手分析（前 10 名）
内容差距和机会
推荐大纲
内部链接策略
元元素预览

`/write [话题]`

创建长篇幅 SEO 优化文章（2000-3000+ 字）。

输出：/drafts/[话题]-[日期].md 文章

包含内容：

包含 H1/H2/H3 结构的完整文章
SEO 优化内容
内部和外部链接
元元素（标题、描述、关键词）
SEO 检查清单

自动触发：

SEO 优化器代理
元元素创建器代理
内部链接器代理
关键词映射器代理

`/rewrite [话题]`

更新并改进现有内容。

输出：/rewrites/[话题]-rewrite-[日期].md 更新后的文章

包含内容：

重写/更新的内容
更改摘要
修改前后对比
更新的 SEO 元素

`/analyze-existing [URL 或文件]`

分析现有博客文章以发现改进机会。

输出：/research/analysis-[话题]-[日期].md 分析报告

包含内容：

内容健康评分（0-100）
速赢机会（可立即改进的项）
战略改进建议
重写优先级和范围
用于重写的研究简报

`/optimize [文件]`

发布前的最终 SEO 优化。

输出：/drafts/optimization-report-[话题]-[日期].md 优化报告

包含内容：

SEO 评分（0-100）
优先修复项
速赢机会
元元素选项
链接增强建议
发布就绪评估

`/publish-draft [文件]`

通过 REST API 将文章发布到 WordPress，并附带 Yoast SEO 元数据。

`/article [话题]`

简化的文章创建工作流。

`/priorities`

使用分析数据识别影响力最高的内容任务的内容优先级矩阵。

`/scrub [文件]`

从内容中移除 AI 水印和模式（长破折号、填充短语、机器人化模式）。

研究命令

命令	描述
`/research-serp [关键词]`	针对目标关键词的 SERP 分析
`/research-gaps`	竞争对手内容差距分析
`/research-trending`	热门话题机会
`/research-performance`	基于效果的内容优先级
`/research-topics`	话题集群研究

着陆页命令

命令	描述
`/landing-write [话题]`	创建以转化为优化目标的着陆页
`/landing-audit [文件]`	审计着陆页的 CRO 问题
`/landing-research [话题]`	研究竞争对手和定位
`/landing-competitor [URL]`	深度竞争对手着陆页分析
`/landing-publish [文件]`	发布着陆页到 WordPress

代理

专门化的代理，自动分析内容并提供专家建议。

内容分析器（新！）

目的：使用 5 个专门模块进行全面的、数据驱动的内容分析

分析内容：

搜索意图分类（信息类/导航类/交易类/商业类）
关键词密度和聚类，附带话题检测
内容长度与 SERP 前几名竞争对手的对比
可读性评分（Flesch Reading Ease、Flesch-Kincaid Grade Level）
SEO 质量评级（0-100 分，附带分类细分）
关键词堆砌风险检测
被动语态比例和句子复杂度
按章节展示关键词位置的分布热力图

输出：

包含发布就绪评估的执行摘要
优先级行动计划（关键/高优先级/优化）
竞争定位分析
每个分析领域的详细建议
用于改进的具体指标和基准

由以下模块驱动：

search_intent_analyzer.py - 搜索意图检测
keyword_analyzer.py - 关键词密度、聚类、LSI 关键词
content_length_comparator.py - SERP 竞争对手分析
readability_scorer.py - 多项可读性指标
seo_quality_rater.py - 综合 SEO 评分

SEO 优化器

目的：页面 SEO 分析和优化建议

分析内容：

关键词优化和密度
内容结构和标题层级
内部和外部链接
元元素
可读性和用户体验
精选摘要机会

输出：SEO 评分（0-100）及具体的改进建议

元元素创建器

目的：生成高转化率的元标题和描述

创建内容：

5 个元标题变体（50-60 字符）
5 个元描述变体（150-160 字符）
测试建议
SERP 预览
以转化为导向的文案

输出：多个选项，附带推荐和理由

内部链接器

目的：战略性的内部链接建议

提供内容：

3-5 条具体的内部链接建议
精确的放置位置
锚文本建议
用户旅程映射
SEO 影响预测

参考：context/internal-links-map.md

关键词映射器

目的：关键词位置和整合分析

分析内容：

关键词密度和分布
关键位置检查清单
自然语言整合质量
LSI 关键词覆盖
关键词自相残杀风险

输出：分布图、差距分析、具体的修订建议

编辑器

目的：将技术上准确的内容转化为听起来像人写的、引人入胜的文章

分析内容：

声音和个性
示例的具体程度
可读性和流畅度
机器人化与人类化模式
互动性和故事性

提供内容：

人性化评分（0-100）
关键编辑建议（修改前后对比）
模式分析
注入个性的具体重写建议
可读性改进

输出：编辑报告，包含让内容听起来更像真人撰写的具体改进建议

性能分析器

目的：使用真实分析数据进行数据驱动的内容优先级排序

分析内容：

Google Analytics 流量和趋势
Google Search Console 排名和点击率
DataForSEO 竞争数据
速赢机会（排名 11-20）
表现下滑的内容
低点击率机会
热门话题

提供内容：

内容任务优先级队列
机会评分（0-100）
影响和投入估算
逐周路线图
成功指标

输出：全面的性能报告，附带可执行的优先级

标题生成器

目的：生成高转化率的标题变体和 A/B 测试建议

提供内容：

10+ 个使用成熟公式的标题变体
转化潜力评分
A/B 测试策略
针对特定受众的标题选项

CRO 分析器

目的：针对着陆页的转化率优化分析

分析内容：

首屏效果
CTA 质量和分布
信任信号存在性
转化阻力点
页面结构

着陆页优化器

目的：全面的着陆页优化建议

提供内容：

CRO 评分（0-100），附带分类细分
首屏、CTA、信任信号、结构和 SEO 分析
A/B 测试建议
优先级行动清单

营销技能

SEO Machine 包含 26 项可作为斜杠命令使用的营销技能：

类别	技能
文案撰写	`/copywriting`、`/copy-editing`
CRO	`/page-cro`、`/form-cro`、`/signup-flow-cro`、`/onboarding-cro`、`/popup-cro`、`/paywall-upgrade-cro`
策略	`/content-strategy`、`/pricing-strategy`、`/launch-strategy`、`/marketing-ideas`
渠道	`/email-sequence`、`/social-content`、`/paid-ads`
SEO	`/seo-audit`、`/schema-markup`、`/programmatic-seo`、`/competitor-alternatives`
分析	`/analytics-tracking`、`/ab-test-setup`
其他	`/referral-program`、`/free-tool-strategy`、`/marketing-psychology`

数据源

与分析工具的集成

SEO Machine 集成实时数据源，为内容策略提供信息：

Google Analytics 4：

流量和互动指标
转化跟踪
趋势分析
流量来源

Google Search Console：

关键词排名和位置
展示次数和点击次数
点击率分析
查询效果

DataForSEO：

竞争对手排名
SERP 特性
关键词指标
竞争对手差距分析

高级 SEO 分析模块（新！）

SEO Machine 包含 5 个专门的 Python 模块，用于全面的内容分析：

搜索意图分析器（search_intent_analyzer.py）：

将查询分类为信息类、导航类、交易类或商业类意图
分析 SERP 特性和内容模式
提供置信度评分和内容对齐建议

关键词分析器（keyword_analyzer.py）：

计算精确的关键词密度和分布
检测关键词堆砌风险并发出警告
使用 TF-IDF 和 K-means 进行话题聚类
生成按章节分布的热力图
识别 LSI（语义相关）关键词

SEO 质量评级器（seo_quality_rater.py）：

根据 SEO 最佳实践对内容进行评分（0-100 分）
分类细分：内容、关键词、元数据、结构、链接、可读性
识别关键问题、警告和建议
确定发布就绪状态

内容长度对比器（content_length_comparator.py）：

获取并分析前 10-20 名 SERP 竞争对手的字数
计算中位数、第 75 百分位数和最佳长度
显示竞争定位和与目标的差距
提供数据驱动的扩展建议

可读性评分器（readability_scorer.py）：

Flesch Reading Ease 和 Flesch-Kincaid Grade Level
句子和段落结构分析
被动语态检测和比例计算
复杂词汇识别
过渡词使用分析
整体可读性评分（0-100）

所有模块都可以直接在 Python 中使用，或通过内容分析器代理使用。

CRO 分析模块

六个用于着陆页转化优化的 Python 模块：

above_fold_analyzer.py - 首屏内容分析（标题、价值主张、CTA、信任）
cta_analyzer.py - CTA 效果评分（质量、分布、目标对齐）
trust_signal_analyzer.py - 信任信号检测（推荐信、社会证明、风险逆转）
landing_page_scorer.py - 着陆页整体评分（0-100 分，附带分类细分）
landing_performance.py - 通过 GA4/GSC 跟踪着陆页效果
cro_checker.py - CRO 最佳实践检查清单验证

附加分析模块

opportunity_scorer.py - 用于内容优先级的 8 因素机会评分
content_scorer.py - 5 维内容质量评分（人性化、具体性、结构、SEO、可读性）
engagement_analyzer.py - 内容互动模式分析
competitor_gap_analyzer.py - 竞争内容差距识别
article_planner.py - 数据驱动的文章规划
section_writer.py - 章节级内容指导
social_research_aggregator.py - 社交媒体研究聚合

Python 研究脚本

从仓库根目录运行：

# 内容研究
python3 research_quick_wins.py
python3 research_competitor_gaps.py
python3 research_performance_matrix.py
python3 research_priorities_comprehensive.py
python3 research_serp_analysis.py
python3 research_topic_clusters.py
python3 research_trending.py

# SEO 分析（需配置 - 先在 config/competitors.json 中设置）
python3 seo_baseline_analysis.py
python3 seo_bofu_rankings.py
python3 seo_competitor_analysis.py

# 测试 API 连接
python3 test_dataforseo.py

注意：SEO 分析脚本从 config/competitors.json 加载竞争对手列表和关键词。复制 config/competitors.example.json 并根据您的业务进行自定义。

WordPress 集成

发布功能使用 WordPress REST API，配合一个暴露 Yoast SEO 字段的自定义 MU 插件。

设置步骤：

将 wordpress/seo-machine-yoast-rest.php 作为 MU 插件安装到您的 WordPress 站点
将 wordpress/functions-snippet.php 添加到您主题的 functions.php 中

在 .env 中配置 WordPress 凭据：

WP_URL=https://yoursite.com
WP_USERNAME=your_username
WP_APP_PASSWORD=your_application_password

详细设置说明请参阅 wordpress/README.md。

分析设置说明请参阅 data_sources/README.md。

目录结构

seomachine/
├── .claude/
│   ├── commands/          # 自定义工作流命令
│   │   ├── analyze-existing.md
│   │   ├── research.md
│   │   ├── write.md
│   │   ├── rewrite.md
│   │   ├── optimize.md
│   │   ├── scrub.md
│   │   ├── performance-review.md
│   │   ├── publish-draft.md
│   │   ├── article.md
│   │   ├── priorities.md
│   │   ├── research-serp.md
│   │   ├── research-gaps.md
│   │   ├── research-trending.md
│   │   ├── research-performance.md
│   │   ├── research-topics.md
│   │   ├── landing-write.md
│   │   ├── landing-audit.md
│   │   ├── landing-research.md
│   │   ├── landing-competitor.md
│   │   └── landing-publish.md
│   ├── agents/            # 专门的分析代理
│   │   ├── content-analyzer.md
│   │   ├── seo-optimizer.md
│   │   ├── meta-creator.md
│   │   ├── internal-linker.md
│   │   ├── keyword-mapper.md
│   │   ├── editor.md
│   │   ├── performance.md
│   │   ├── headline-generator.md
│   │   ├── cro-analyst.md
│   │   └── landing-page-optimizer.md
│   └── skills/            # 26 项营销技能
├── data_sources/          # 分析集成
│   ├── modules/          # Python 分析模块
│   │   ├── google_analytics.py
│   │   ├── google_search_console.py
│   │   ├── dataforseo.py
│   │   ├── data_aggregator.py
│   │   ├── search_intent_analyzer.py
│   │   ├── keyword_analyzer.py
│   │   ├── seo_quality_rater.py
│   │   ├── content_length_comparator.py
│   │   ├── readability_scorer.py
│   │   ├── opportunity_scorer.py
│   │   ├── content_scorer.py
│   │   ├── engagement_analyzer.py
│   │   ├── social_research_aggregator.py
│   │   ├── competitor_gap_analyzer.py
│   │   ├── article_planner.py
│   │   ├── section_writer.py
│   │   ├── wordpress_publisher.py
│   │   ├── above_fold_analyzer.py
│   │   ├── cro_checker.py
│   │   ├── cta_analyzer.py
│   │   ├── landing_page_scorer.py
│   │   ├── landing_performance.py
│   │   └── trust_signal_analyzer.py
│   ├── config/           # API 凭据（不加入 git）
│   ├── utils/            # 辅助函数
│   ├── cache/            # 缓存的 API 响应
│   └── README.md         # 设置说明
├── config/                # 配置文件
│   └── competitors.example.json  # 竞争对手配置模板
├── context/               # 配置和指南
│   ├── brand-voice.md
│   ├── writing-examples.md
│   ├── style-guide.md
│   ├── seo-guidelines.md
│   ├── target-keywords.md
│   ├── internal-links-map.md
│   ├── competitor-analysis.md
│   └── cro-best-practices.md
├── wordpress/             # WordPress 集成
│   ├── seo-machine-yoast-rest.php
│   ├── functions-snippet.php
│   └── README.md
├── topics/                # 原始话题想法
├── research/              # 研究简报和分析报告
├── drafts/                # 进行中的文章
├── review-required/       # 待审阅的文章
├── published/             # 准备发布的最终版本
├── rewrites/              # 更新后的现有内容
├── landing-pages/         # 着陆页内容
├── audits/                # 审计报告
└── README.md              # 本文件

上下文文件（重要！）

内容的质量取决于正确配置的上下文文件：

`context/brand-voice.md`

定义您的品牌声音、语调和消息传递框架。

必须包含：

声音支柱
按内容类型划分的语调指南
核心品牌信息
写作风格指南
术语偏好

目的：确保所有内容听起来都像您的品牌

`context/writing-examples.md`

包含您网站上 3-5 篇优秀的博客文章。

必须包含：

完整文章内容
每个示例优秀之处
关于声音和结构的关键要点

目的：通过示例教会 AI 您特定的写作风格

`context/style-guide.md`

编辑和格式标准。

必须包含：

语法和机制规则
大小写惯例
格式标准
首选术语

目的：保持所有内容的一致性

`context/seo-guidelines.md`

SEO 最佳实践和要求。

包含内容：

内容长度要求
关键词优化规则
元元素标准
链接策略指南
可读性要求

目的：确保所有内容符合 SEO 标准

`context/target-keywords.md`

按话题集群组织的关键词研究。

必须包含：

按集群划分的核心关键词
集群关键词（子话题）
长尾变体
搜索意图分类
当前排名

目的：指导新内容的关键词定位

`context/internal-links-map.md`

用于内部链接的网站关键页面目录。

必须包含：

产品页面和功能
核心内容 URL
表现最佳的博客文章
话题集群映射
推荐的锚文本

目的：使每篇文章都能进行战略性内部链接

`context/competitor-analysis.md`

竞争情报和内容差距。

必须包含：

主要竞争对手
他们的内容策略
关键词差距
差异化机会

目的：为内容策略和竞争定位提供信息

内容质量标准

每篇文章必须满足以下要求：

内容

最少 2,000 字（2,500-3,000+ 为佳）
与竞争对手相比提供独特价值
事实准确且与时俱进
为目标受众提供可操作的建议
保持品牌声音

SEO

主要关键词密度 1-2%
关键词出现在 H1、前 100 字、2-3 个 H2 中
3-5 个内部链接，使用描述性锚文本
2-3 个外部权威链接
元标题 50-60 字符
元描述 150-160 字符
正确的 H1 > H2 > H3 层级

可读性

结构

引人入胜的引言（钩子、问题、承诺）
逻辑清晰的章节流程
明确的结论，包含行动呼吁
包含示例和数据

最佳实践

写作之前

先做研究：在 /write 之前始终运行 /research
回顾上下文：阅读 brand-voice.md 和相关的 writing-examples.md
检查关键词：在 target-keywords.md 中验证目标关键词
规划内部链接：查看 internal-links-map.md 寻找链接机会

写作过程中

遵循简报：使用研究简报作为大纲
自然的关键词：自然整合关键词，绝不强行堆砌
增加价值：每个章节都应提供可操作的洞察
使用示例：包含来自您行业的真实场景和用例
引用来源：链接到统计数据和数据源

写作之后

审阅代理输出：仔细阅读所有代理建议
进行改进：在优化之前解决高优先级问题
运行优化：使用 /optimize 进行最终润色
自我编辑：以目标读者的身份阅读文章
检查质量：验证所有检查清单项目是否满足

重写内容时

先分析：运行 /analyze-existing 了解范围
确定策略：轻量更新还是大幅重写？
保留有效部分：保留效果好的章节
聚焦差距：补充竞争对手内容中缺失的部分
更新一切：统计数据、示例、截图、链接

工作流示例

示例 1：从头创建新内容

# 步骤 1：添加话题想法
# 在 topics/ 目录中创建文件，记录初步想法

# 步骤 2：研究话题
/research content marketing strategies

# 步骤 3：审阅研究简报
# 阅读 research/brief-content-marketing-strategies-[日期].md

# 步骤 4：撰写文章
/write content marketing strategies

# 步骤 5：审阅代理反馈
# 阅读 drafts/ 中的所有代理报告

# 步骤 6：进行改进
# 根据代理建议编辑文章

# 步骤 7：最终优化
/optimize drafts/content-marketing-strategies-[日期].md

# 步骤 8：发布到 WordPress（可选）
/publish-draft drafts/content-marketing-strategies-[日期].md

示例 2：更新现有内容

# 步骤 1：分析现有文章
/analyze-existing https://yoursite.com/blog/product-comparison

# 步骤 2：审阅分析报告
# 阅读 research/analysis-product-comparison-2025-10-29.md
# 检查内容健康评分和优先级

# 步骤 3：重写内容
/rewrite product comparison

# 步骤 4：审阅更改
# 阅读 rewrites/product-comparison-rewrite-2025-10-29.md
# 查看更改摘要

# 步骤 5：优化
/optimize rewrites/product-comparison-rewrite-2025-10-29.md

# 步骤 6：发布
# 准备就绪后移动到 published/

示例 3：快速内容审计

# 分析多篇现有文章以确定更新优先级
/analyze-existing https://yoursite.com/blog/post-1
/analyze-existing https://yoursite.com/blog/post-2
/analyze-existing https://yoursite.com/blog/post-3

# 查看内容健康评分
# 根据以下条件确定重写优先级：
# - 最低的评分
# - 最高的流量潜力
# - 战略重要性

技巧与窍门

最大化内容质量

研究示例：每次写作前阅读您的 writing-examples.md
使用数据：始终包含最新的统计数据并引用来源
具体化：”提升 40%” 比 “显著提升” 更好
展示而非讲述：使用您行业中的真实示例和场景
回答问题：解答研究中发现的 “People Also Ask” 问题

SEO 优化

关键词前置：将主要关键词放在前 100 字内
自然整合：大声朗读内容——如果关键词听起来生硬，就重写
变化锚文本：不要对所有内部链接使用相同的锚文本
战略链接：链接到核心内容和相关的集群文章
定期更新：每 6-12 个月刷新表现最佳的内容

工作流效率

批量研究：在一次会话中研究多个话题
遵循结构：使用 /write 命令生成的一致文章结构
先处理高优先级：在优化细节之前修复关键问题
明智使用代理：让代理处理分析，您专注于写作
构建模板：保存常用章节以便复用

避免常见错误

❌ 跳过研究阶段
❌ 忽略品牌声音指南
❌ 强行堆砌关键词
❌ 忘记内部链接
❌ 不引用数据来源
❌ 未经优化就发布
❌ 复制竞争对手内容而非差异化

维护

每周

向 /topics/ 添加新的话题想法
用新的关键词机会更新 target-keywords.md
检查 internal-links-map.md 中的失效链接

每月

审查已发布内容的表现
如果有更好的示例出现，更新 writing-examples.md
将新发布的内容添加到 internal-links-map.md
在 competitor-analysis.md 中跟踪竞争对手活动

每季度

全面审计上下文文件
根据算法变化更新 SEO 指南
全面刷新竞争对手分析
审查并更新 target-keywords.md 中的话题集群

故障排除

“内容听起来不像我的品牌”

解决方案：用更具体的指导更新 context/brand-voice.md
解决方案：向 context/writing-examples.md 添加更多样化的示例
解决方案：在使用 /write 命令时引用具体示例

“关键词密度过高/过低”

解决方案：查看 seo-guidelines.md 中的目标密度（1-2%）
解决方案：使用 /optimize 获取具体的关键词位置建议
解决方案：使用关键词映射器代理进行分布分析

“内部链接不相关”

解决方案：用当前页面更新 context/internal-links-map.md
解决方案：按话题集群组织，以便代理更容易匹配
解决方案：提供更多关于每个页面内容的上下文

“文章与竞争对手过于相似”

解决方案：更新 competitor-analysis.md 中的差异化机会
解决方案：将您的独特优势添加到 brand-voice.md 和 features.md
解决方案：在 /research 命令中引用具体的差异化角度

支持与贡献

获取帮助

仔细阅读本 README
检查上下文文件是否正确配置
查阅 Claude Code 文档

贡献

通过 GitHub Issues 报告问题
对命令或代理提出改进建议
分享成功的工作流或技巧

许可证

[在此添加您的许可证信息]

致谢

由 Anthropic 使用 Claude Code 构建。

最初为 Castos 开发，现作为开源工具提供给任何企业，以简化长篇幅 SEO 内容的创建。

示例与社区

实际效果：查看 examples/castos/ 目录，了解一家播客托管 SaaS 公司如何使用 SEO Machine 的真实完整示例。

欢迎贡献：发现 bug？有功能需求？想分享您所在行业的示例？欢迎贡献代码和提交 PR！

准备好开始创建了吗？

配置您的上下文文件（以模板为指南）
运行 /research [您的话题]
审阅简报
运行 /write [您的话题]
发布精彩内容！

祝写作愉快！📝

参考资料

SEO Machine
参考资料

Reddit 视频制作机器人 🎥

Wed, 08 Apr 2026 13:01:55 +0000

Reddit 视频制作机器人 🎥

整个过程无需视频编辑或素材整理。纯粹是✨编程魔法✨。

由 Lewis Menelaws 与 TMRRW 制作

</a>

视频讲解

动机 🤔

这类视频在 TikTok、YouTube 和 Instagram 上能获得数百万的播放量，而且几乎不需要什么投入。唯一原创的部分就是剪辑和素材收集……

……但如果我们能把这个过程自动化呢？🤔

免责声明 🚨

目前，本仓库不会尝试通过机器人自动上传这些内容。它会生成一个文件，你需要手动上传。这是为了避免触犯任何社区准则问题。

环境要求

Python 3.10
Playwright（安装时会自动安装）

安装步骤 👩‍💻

克隆本仓库：

 git clone https://github.com/elebumm/RedditVideoMakerBot.git
 cd RedditVideoMakerBot

创建并激活虚拟环境：

Windows：

  python -m venv ./venv
  .\venv\Scripts\activate

macOS 和 Linux：

  python3 -m venv ./venv
  source ./venv/bin/activate

安装所需依赖：
```
 pip install -r requirements.txt
```

安装 Playwright 及其依赖：

 python -m playwright install
 python -m playwright install-deps

实验性功能！！！

在 macOS 和 Linux（Debian、Arch、Fedora、CentOS 及其衍生版）上，你可以运行一个安装脚本，自动完成第 1 至第 3 步。（需要 bash）
bash <(curl -sL https://raw.githubusercontent.com/elebumm/RedditVideoMakerBot/master/install.sh)
此脚本也可用于更新安装

运行机器人：
```
 python main.py
```
访问 Reddit 应用页面，创建一个“脚本”类型的应用。在重定向 URL 字段中粘贴任意 URL，例如：https://jasoncameron.dev。
机器人会提示你填写相关信息以连接 Reddit API，并根据你的喜好配置机器人。
尽情享受吧 😎
如果需要重新配置机器人，只需打开 config.toml 文件，删除需要更改的行。下次运行机器人时，它会帮助你重新配置这些选项。

（注意：如果在安装或运行机器人时遇到任何错误，请尝试使用 python3 或 pip3 而不是 python 或 pip。）

关于机器人的更详细指南，请参考文档。

视频

https://user-images.githubusercontent.com/66544866/173453972-6526e4e6-c6ef-41c5-ab40-5d275e724e7c.mp4

贡献与改进方向 📈

在当前状态下，这个机器人已经完成了它需要做的事情。不过，总可以做得更好！

我已尽量简化代码，让任何人都能阅读并开始贡献，无论技术水平如何。别害羞，来贡献吧！

编写更好的文档，并添加命令行界面。
允许用户为视频选择背景音乐。
允许用户选择特定的 Reddit 帖子，而不是随机选取。
允许用户选择其他背景，而不是 Minecraft 背景。
允许用户选择任意子版块。
允许用户更换语音。
检查视频是否已生成过。
浅色和深色模式。
NSFW 帖子过滤器。

请阅读我们的贡献指南以获取更详细的信息。

如有任何问题或需要支持，请加入 Discord 服务器

开发者和维护者

Elebumm (Lewis#6305) - https://github.com/elebumm (创始人)

Jason Cameron - https://github.com/JasonLovesDoggo (维护者)

Simon (OpenSourceSimon) - https://github.com/OpenSourceSimon

CallumIO (c.#6837) - https://github.com/CallumIO

Verq (Verq#2338) - https://github.com/CordlessCoder

LukaHietala (Pix.#0001) - https://github.com/LukaHietala

Freebiell (Freebie#3263) - https://github.com/FreebieII

Aman Raza (electro199#8130) - https://github.com/electro199

Cyteon (cyteon) - https://github.com/cyteon

许可证

Roboto 字体采用 Apache License V2 许可。

参考资料

Reddit 视频制作机器人 🎥
参考资料

gitHistory 概览

Wed, 08 Apr 2026 13:01:55 +0000

业务背景

希望帮我编写一份提示词 git-history-SKILL.md，满足下面的业务场景：

在当前代 git 码仓库下，拉取最近1年的 git 提交历史。

然后让 llm 分析解析每一次 commit，其中用户填写的 commit message 作为理解的辅助。

总结分析出功能点和文件之间的映射关系（隐形知识）

理念参考

可以首先学习阐述一下 superMemory、openMemory 这些记忆设计系统的核心理念是如何越做越准的？

让我们的设计思路参考这个，虽然变更次数的增多，分析的也可以更加准。

性能问题

最好按照 commit 并行处理，每一次 commit 可以并行处理。这样性能比较好。子 agent 实现。

分析每一次提交涉及的文件，每一个文件的作用（类名语义理解），differ 上下 100 行之类的，找到变更的方便。

llm 解析识别对应的方法信息+方法的核心逻辑

每一个子 agent 的解析结果放在 .gitHistory/commits/ 下面，给出约定的规范，最好是按照 commitHash，然后下面对应每一个文件的信息+类方法信息。整体 commit 的基本信息（时间、提交人、提交信息、hash 等等）

结果输出

最后每个子 commit 处理好之后，进行整体的汇总。

按照分类进行总结，给出功能点的分类及相关文件、核心方法、次数、趋势等等比较有价值的分析。

markdown

输出一份 markdown 主文件，方便人类阅读审阅

json

额外输出一份 json 文件，方便后续程序解析

重要程度

离现在时间越近的越重要。

变更次数越多的文件越重要。

文件排除

类似于 xxxTest 测试类全部忽略掉，无价值

xml properties yaml 这些是有价值的，需要保留

review

最后的结果完成后，需要对每一个子 agent commit 进行完成度审查

最后的输出结果审查等等，确认正确、准确、有价值

skills.md

好，这一版我直接给你一个**完全符合 Skill 风格、可执行、可落地的中文版本**。
不讲概念，不讲背景，全部是**约束 + 协议 + 执行步骤**。

---

# 📄 git-history-SKILL.md（中文版 / 可执行版）

---

## 🧩 Skill 名称

`git-history-analyzer`

---

## 🎯 目标（Purpose）

分析当前 Git 仓库最近 1 年的提交历史，构建：

```text
功能（Feature） → 文件（File） → 方法（Method）

输出结构化知识，用于：

架构理解
隐性知识提取
变更趋势分析

⚙️ 输入（Input）

{
  "repoPath": ".",
  "since": "1 year ago"
}

📦 输出（Output）

必须生成以下文件结构：

.gitHistory/
  ├── commits/
  │     ├── <commitHash>.json
  ├── summary.md
  ├── summary.json

🚫 约束（Constraints）

文件过滤

忽略：

*Test*
*Mock*
*Fixture*

保留：

.java
.xml
.yaml / .yml
.properties

执行约束

MUST 使用并行处理 commit
MUST 使用 diff 上下文：

--unified=100

MUST 基于 diff 推断逻辑（优先级高于 commit message）
MUST 保证输出结构稳定（不可随意变化字段）

🧠 核心规则（Core Rules）

越新的 commit 权重越高
修改次数越多的文件越重要
commit message = 弱信号
diff = 强信号
所有分析必须可累积（不可覆盖历史认知）

🚀 执行流程（Execution Plan）

STEP 1：获取提交历史

执行：

git log --since="" --pretty=format:"%H|%an|%ad|%s" --date=iso

输出：

[
  {
    "hash": "",
    "author": "",
    "date": "",
    "message": ""
  }
]

STEP 2：并行处理 Commit（核心）

对于每一个 commit：

执行：

git show <hash> --unified=100

然后启动 子 Agent（Sub Agent）

🤖 子 Agent 规范（Sub Agent）

输入

{
  "commit": {
    "hash": "",
    "author": "",
    "date": "",
    "message": ""
  },
  "diff": ""
}

必须完成的任务（MANDATORY）

1️⃣ 文件提取

识别：

filePath
fileType

过滤无效文件（根据约束）

2️⃣ 类语义分析

推断：

{
  "name": "类名",
  "responsibility": "一句话职责描述",
  "domain": "领域（1个词）"
}

3️⃣ 方法级分析（核心）

必须从 diff 中提取：

{
  "name": "方法名",
  "changeType": "add | modify | delete",
  "logic": "核心逻辑（≤20字）"
}

4️⃣ 功能识别（Feature）

{
  "name": "功能名称",
  "type": "feature | fix | refactor | config",
  "confidence": 0.0-1.0
}

规则：

必须结合 message + diff
不确定 → 降低 confidence

5️⃣ 提交意图分类

必须归类为：

feature / fix / refactor / config

📁 输出格式（严格）

{
  "commit": {
    "hash": "",
    "author": "",
    "date": "",
    "message": "",
    "type": ""
  },
  "files": [
    {
      "filePath": "",
      "fileType": "",
      "class": {
        "name": "",
        "responsibility": "",
        "domain": ""
      },
      "methods": [
        {
          "name": "",
          "changeType": "",
          "logic": ""
        }
      ]
    }
  ],
  "features": [
    {
      "name": "",
      "confidence": 0.0
    }
  ]
}

💾 保存路径

.gitHistory/commits/<commitHash>.json

🧠 聚合 Agent（Aggregator）

在所有 commit 处理完成后执行

必须完成的任务

1️⃣ Feature 合并

要求：

语义相近必须合并
统一命名

示例：

订单优化 → 订单增强 → 订单系统（统一）

2️⃣ 构建映射关系

Feature → File → Method

3️⃣ 重要性计算

文件重要性

importance = 修改次数 × 时间权重

Feature 置信度

confidence = 平均置信度 × log(提交次数)

4️⃣ 趋势分析

识别：

高频变更模块
最近活跃模块
稳定模块

5️⃣ 风险识别

标记：

高频 + 最近修改的文件
大规模 diff 的 commit

📄 最终输出

summary.md（人类阅读）

# Git 历史分析报告

## 🔥 核心功能

### 订单系统
- 提交次数：32
- 核心文件：
  - OrderService.java
- 核心方法：
  - createOrder

---

## 📈 趋势

- 最近活跃：
  - 支付模块
- 稳定模块：
  - 用户模块

---

## ⚠️ 风险

- PaymentService.java（高频变更）

summary.json（机器使用）

{
  "features": [],
  "files": [],
  "trends": [],
  "risks": []
}

✅ 质量审查（Review，必须执行）

1️⃣ 子 Agent 校验

检查：

是否提取 method
是否识别 feature
是否存在空字段

2️⃣ 聚合校验

检查：

feature 是否重复
映射关系是否完整
是否存在遗漏

3️⃣ 输出评分

{
  "completeness": 0.0,
  "accuracy": 0.0,
  "consistency": 0.0
}

♻️ Memory（可选增强）

路径：

.gitHistory/memory/

记录：

feature 演化
文件归属变化

⚡ 强制执行规则（Execution Rules）

MUST 并行处理 commit
MUST 不得虚构方法
MUST 优先使用 diff
MUST 输出稳定结构
MUST 每个 commit 独立分析 ```

参考资料

业务背景
- 理念参考
- 性能问题
- 结果输出
  - markdown
  - json
- 重要程度
- 文件排除
- review
skills.md
🚀 执行流程（Execution Plan）
- STEP 1：获取提交历史
- STEP 2：并行处理 Commit（核心）
🤖 子 Agent 规范（Sub Agent）
🧠 聚合 Agent（Aggregator）
- 必须完成的任务
📄 最终输出
- summary.md（人类阅读）
- summary.json（机器使用）
✅ 质量审查（Review，必须执行）
♻️ Memory（可选增强）
⚡ 强制执行规则（Execution Rules）
参考资料

DeepTutor：迈向智能体驱动的个性化辅导

Wed, 08 Apr 2026 13:01:55 +0000

DeepTutor：迈向智能体驱动的个性化辅导

✨ 核心亮点

统一聊天工作区 — 五种模式，同一条对话线。聊天、深度解题、测验生成、深度研究与数学动画共享上下文：从闲聊到多智能体解题、出题、再深入调研，消息不丢。
个人 TutorBot — 不是聊天机器人，而是自主导师。每个 TutorBot 拥有独立工作区、记忆、人格与技能；可提醒、可学新能力、随你成长。由 nanobot 驱动。
AI Co-Writer — Markdown 编辑器中 AI 是一等协作者。划选文本即可改写、扩写或缩写，可结合知识库与网络；内容可沉淀到笔记本，反哺学习闭环。
引导式学习 — 把资料变成结构化、可视化的学习路径：多步计划、每步交互页面、步步可讨论。
知识中枢 — 上传 PDF、Markdown、纯文本构建 RAG 知识库；用彩色笔记本跨会话整理洞见。文档主动参与每次对话。
持久记忆 — 持续勾勒你的学习画像：学过什么、如何学习、目标何在。全功能与 TutorBot 共享，越用越准。
智能体原生 CLI — 能力、知识库、会话、TutorBot 一条命令可达；终端 Rich 输出给人看，JSON 给智能体与流水线。将根目录 SKILL.md 交给智能体即可自主操作。

🚀 快速开始

方案 A — 引导式安装（推荐）

一条交互脚本完成依赖安装、环境配置、连通性检测与启动，无需手改 .env。

git clone https://github.com/HKUDS/DeepTutor.git
cd DeepTutor

# 创建 Python 环境
conda create -n deeptutor python=3.11 && conda activate deeptutor
# 或：python -m venv .venv && source .venv/bin/activate

# 启动引导
python scripts/start_tour.py

向导会询问使用方式：

Web 模式（推荐）— 选择依赖配置、安装 pip + npm、拉起临时服务并在浏览器打开设置页；四步引导配置 LLM、嵌入与搜索并现场测通；完成后自动按配置重启。
CLI 模式 — 全终端交互：选配置、装依赖、配提供商、验证连接并应用，无需离开 shell。

完成后访问 http://localhost:3782。

方案 B — 本地手动安装

若希望完全自控，可自行安装与配置。

1. 安装依赖

git clone https://github.com/HKUDS/DeepTutor.git
cd DeepTutor

conda create -n deeptutor python=3.11 && conda activate deeptutor
pip install -e ".[server]"

# 前端
cd web && npm install && cd ..

2. 配置环境

cp .env.example .env

编辑 .env，至少填写必填项：

# LLM（必填）
LLM_BINDING=openai
LLM_MODEL=gpt-4o-mini
LLM_API_KEY=sk-xxx
LLM_HOST=https://api.openai.com/v1

# 嵌入（知识库必填）
EMBEDDING_BINDING=openai
EMBEDDING_MODEL=text-embedding-3-large
EMBEDDING_API_KEY=sk-xxx
EMBEDDING_HOST=https://api.openai.com/v1
EMBEDDING_DIMENSION=3072

3. 启动服务

# 后端（FastAPI）
python -m deeptutor.api.run_server

# 前端（Next.js）— 另开终端
cd web && npm run dev -- -p 3782

服务	默认端口
后端	`8001`
前端	`3782`

浏览器打开 http://localhost:3782。

方案 C — Docker 部署

Docker 将前后端打包为单容器，本机无需 Python/Node。任选其一：

1. 配置环境变量（两种方式均需）

git clone https://github.com/HKUDS/DeepTutor.git
cd DeepTutor
cp .env.example .env

编辑 .env，填写必填项（与方案 B相同）。

2a. 拉取官方镜像（推荐）

镜像发布于 GitHub Container Registry，支持 linux/amd64 与 linux/arm64。

docker compose -f docker-compose.ghcr.yml up -d

固定版本可编辑 docker-compose.ghcr.yml 中的镜像标签：

image: ghcr.io/hkuds/deeptutor:1.0.0  # 或 :latest

2b. 源码构建

docker compose up -d

本地根据 Dockerfile 构建并启动。

3. 验证与管理

容器健康后打开 http://localhost:3782。

docker compose logs -f   # 查看日志
docker compose down       # 停止并移除容器

云端 / 远程部署

远程部署时，浏览器需知晓后端公网地址。在 `.env` 中增加： ```dotenv NEXT_PUBLIC_API_BASE_EXTERNAL=https://your-server.com:8001 ``` 前端启动脚本会在运行时应用，无需重新构建。

开发模式（热重载）

叠加 dev 覆盖以挂载源码并热重载： ```bash docker compose -f docker-compose.yml -f docker-compose.dev.yml up ``` `deeptutor/`、`deeptutor_cli/`、`scripts/`、`web/` 的修改会即时生效。

自定义端口

在 `.env` 中覆盖： ```dotenv BACKEND_PORT=9001 FRONTEND_PORT=4000 ``` 然后重启： ```bash docker compose up -d # 或 docker compose -f docker-compose.ghcr.yml up -d ```

数据持久化

用户数据与知识库通过卷映射到本地： | 容器内路径 | 宿主机路径 | 内容 | |:---|:---|:---| | `/app/data/user` | `./data/user` | 设置、记忆、工作区、会话、日志 | | `/app/data/knowledge_bases` | `./data/knowledge_bases` | 上传文档与向量索引 | `docker compose down` 后目录仍保留，下次 `up` 会复用。

环境变量参考

| 变量 | 必填 | 说明 | |:---|:---:|:---| | `LLM_BINDING` | **是** | LLM 提供商（`openai`、`anthropic` 等） | | `LLM_MODEL` | **是** | 模型名（如 `gpt-4o`） | | `LLM_API_KEY` | **是** | API 密钥 | | `LLM_HOST` | **是** | API 地址 | | `EMBEDDING_BINDING` | **是** | 嵌入提供商 | | `EMBEDDING_MODEL` | **是** | 嵌入模型名 | | `EMBEDDING_API_KEY` | **是** | 嵌入 API 密钥 | | `EMBEDDING_HOST` | **是** | 嵌入端点 | | `EMBEDDING_DIMENSION` | **是** | 向量维度 | | `SEARCH_PROVIDER` | 否 | 搜索（`tavily`、`jina`、`serper`、`perplexity` 等） | | `SEARCH_API_KEY` | 否 | 搜索 API 密钥 | | `BACKEND_PORT` | 否 | 后端端口（默认 `8001`） | | `FRONTEND_PORT` | 否 | 前端端口（默认 `3782`） | | `NEXT_PUBLIC_API_BASE_EXTERNAL` | 否 | 云端部署时后端公网 URL | | `DISABLE_SSL_VERIFY` | 否 | 关闭 SSL 校验（默认 `false`） |

方案 D — 仅 CLI

若只要 CLI、不要 Web 前端：

pip install -e ".[cli]"
deeptutor chat                                   # 交互 REPL
deeptutor run chat "Explain Fourier transform"   # 单次能力调用
deeptutor run deep_solve "Solve x^2 = 4"         # 多智能体解题
deeptutor kb create my-kb --doc textbook.pdf     # 构建知识库

完整 CLI 说明与命令表见 DeepTutor CLI。

📖 探索 DeepTutor

💬 聊天 — 统一智能工作区

五种模式共处同一工作区，由统一上下文管理串联：历史、知识库与引用跨模式保留，同一主题下可随时切换。

模式	作用
聊天	工具增强对话：RAG、联网搜索、代码执行、深度推理、头脑风暴、论文检索，按需组合。
深度解题	多智能体解题：规划、检索、求解与验证，步步可溯源引用。
测验生成	基于知识库出题，内置校验。
深度研究	主题拆解、并行调研 RAG/网络/论文，输出带引用报告。
数学动画	基于 Manim 将数学概念可视化为动画与分镜。

工具与工作流解耦：每种模式下你可自选启用哪些工具、用几个、或完全不用；流程负责推理节奏，工具由你编排。

从快速聊天起步，难题切到深度解题，自测用测验，再开深度研究深挖 —— 同一条对话线贯穿始终。

✍️ Co-Writer — 编辑器里的 AI

Co-Writer 把聊天的智能放进写作界面：完整 Markdown 编辑器，AI 是一等协作者，而非侧栏挂件。

划选文本即可改写、扩写或缩写，可选用知识库或网络上下文；支持撤销/重做，作品可存入笔记本，回流学习生态。

🎓 引导式学习 — 可视化、分步掌握

将个人材料变成结构化、多步学习路径：给出主题，可选关联笔记本记录，DeepTutor 将：

设计学习计划 — 从材料中提炼 3–5 个递进知识点。
生成交互页面 — 每点对应富视觉 HTML 页面，含讲解、图示与示例。
上下文问答 — 每步旁路聊天，深入探讨。
学习小结 — 结束后汇总所学。

会话可暂停、恢复或回看任一步。

📚 知识管理 — 学习基础设施

在此构建与管理驱动全局的文档集合。

知识库 — 上传 PDF、TXT、Markdown，形成可检索、RAG 就绪的集合；可增量追加。
笔记本 — 跨会话整理学习记录；聊天、引导学习、Co-Writer、深度研究的洞见可按色分类保存。

知识库不是冷存储 —— 它主动参与每次对话、研究与学习路径。

🧠 记忆 — 与你一同成长

DeepTutor 从两个互补维度持续理解你：

摘要 — 学习进度流水账：学过什么、探索过哪些主题、理解如何演进。
学习画像 — 学习者身份：偏好、水平、目标与沟通风格，随交互自动精炼。

记忆在全功能与 TutorBot 间共享；用得越多，越贴合你。

🦞 TutorBot — 持久、自主的 AI 导师

TutorBot 不是聊天机器人 —— 它是基于 nanobot 的持久、可多实例智能体。每个实例独立循环、工作区、记忆与人格；你可同时运行多个角色，各自演进。

Soul 模板 — 通过可编辑 Soul 文件定义人格、语气与教学理念；可选内置原型或完全自定义。
独立工作区 — 每实例独立目录：记忆、会话、技能与配置隔离，仍可访问 DeepTutor 共享知识层。
主动心跳 — 不止被动回复：心跳系统支持定期学习提醒、复习与计划任务。
完整工具 — RAG、代码执行、联网、论文检索、深度推理、头脑风暴。
技能扩展 — 在工作区添加技能文件即可教会新能力。
多通道 — 可接 Telegram、Discord、Slack、飞书、企业微信、钉钉、邮件等。
团队与子智能体 — 后台子任务或多智能体协作，应对长程复杂任务。

deeptutor bot create math-tutor --persona "Socratic math teacher who uses probing questions"
deeptutor bot create writing-coach --persona "Patient, detail-oriented writing mentor"
deeptutor bot list                  # 查看所有导师实例

⌨️ DeepTutor CLI — 智能体原生界面

DeepTutor 全面 CLI 化：能力、知识库、会话、记忆、TutorBot 均可命令行操作，无需浏览器。终端 Rich 输出面向人类，JSON 面向智能体与流水线。

将项目根目录 SKILL.md 交给任意支持工具的代理（nanobot 或其他 LLM），即可自主配置与操作。

单次执行 — 终端直接跑任意能力：

deeptutor run chat "Explain the Fourier transform" -t rag --kb textbook
deeptutor run deep_solve "Prove that √2 is irrational" -t reason
deeptutor run deep_question "Linear algebra" --config num_questions=5
deeptutor run deep_research "Attention mechanisms in transformers"

交互 REPL — 持久会话，运行时切换模式：

deeptutor chat --capability deep_solve --kb my-kb
# REPL 内：/cap、/tool、/kb、/history、/notebook、/config 等即时切换

知识库闭环 — 终端完成建库、追加与检索：

deeptutor kb create my-kb --doc textbook.pdf
deeptutor kb add my-kb --docs-dir ./papers/
deeptutor kb search my-kb "gradient descent"
deeptutor kb set-default my-kb

双输出模式 — Rich 给人看，JSON 给管道：

deeptutor run chat "Summarize chapter 3" -f rich
deeptutor run chat "Summarize chapter 3" -f json

会话续接 — 断点续聊：

deeptutor session list
deeptutor session open <id>

CLI 命令参考（完整）

**顶层** | 命令 | 说明 | |:---|:---| | `deeptutor run ` | 单次执行能力（`chat`、`deep_solve`、`deep_question`、`deep_research`、`math_animator`） | | `deeptutor chat` | 交互 REPL，可选 `--capability`、`--tool`、`--kb`、`--language` | | `deeptutor serve` | 启动 API 服务 | **`deeptutor bot`** | 命令 | 说明 | |:---|:---| | `deeptutor bot list` | 列出 TutorBot | | `deeptutor bot create ` | 创建并启动（`--name`、`--persona`、`--model`） | | `deeptutor bot start ` | 启动 | | `deeptutor bot stop ` | 停止 | **`deeptutor kb`** | 命令 | 说明 | |:---|:---| | `deeptutor kb list` | 列出知识库 | | `deeptutor kb info ` | 详情 | | `deeptutor kb create ` | 从文档创建（`--doc`、`--docs-dir`） | | `deeptutor kb add ` | 增量添加 | | `deeptutor kb search ` | 检索 | | `deeptutor kb set-default ` | 设为默认 | | `deeptutor kb delete ` | 删除（`--force`） | **`deeptutor memory`** | 命令 | 说明 | |:---|:---| | `deeptutor memory show [file]` | 查看（`summary`、`profile`、`all`） | | `deeptutor memory clear [file]` | 清空（`--force`） | **`deeptutor session`** | 命令 | 说明 | |:---|:---| | `deeptutor session list` | 列表（`--limit`） | | `deeptutor session show ` | 消息 | | `deeptutor session open ` | REPL 续聊 | | `deeptutor session rename ` | 重命名（`--title`） | | `deeptutor session delete ` | 删除 | **`deeptutor notebook`** | 命令 | 说明 | |:---|:---| | `deeptutor notebook list` | 列表 | | `deeptutor notebook create ` | 创建（`--description`） | | `deeptutor notebook show ` | 记录 | | `deeptutor notebook add-md ` | 导入 Markdown | | `deeptutor notebook replace-md ` | 替换记录 | | `deeptutor notebook remove-record ` | 删除记录 | **`deeptutor config` / `plugin` / `provider`** | 命令 | 说明 | |:---|:---| | `deeptutor config show` | 配置摘要 | | `deeptutor plugin list` | 已注册工具与能力 | | `deeptutor plugin info ` | 工具或能力详情 | | `deeptutor provider login ` | OAuth（`openai-codex`、`github-copilot`） | </details> ## 🌐 社区与生态 DeepTutor 受益于优秀开源项目： | 项目 | 在 DeepTutor 中的角色 | |:---|:---| | [**nanobot**](https://github.com/HKUDS/nanobot) | 驱动 TutorBot 的轻量智能体引擎 | | [**LlamaIndex**](https://github.com/run-llama/llama_index) | RAG 与文档索引骨干 | | [**ManimCat**](https://github.com/Wing900/ManimCat) | 数学动画（Math Animator）的 AI 生成 | **HKUDS 生态：** | [⚡ LightRAG](https://github.com/HKUDS/LightRAG) | [🤖 AutoAgent](https://github.com/HKUDS/AutoAgent) | [🔬 AI-Researcher](https://github.com/HKUDS/AI-Researcher) | [🧬 nanobot](https://github.com/HKUDS/nanobot) | |:---:|:---:|:---:|:---:| | 简洁高速 RAG | 零代码智能体框架 | 自动化研究 | 超轻量 AI 智能体 | ## 🤝 参与贡献

希望 DeepTutor 能成为送给社区的一份礼物。🎁

请参阅 [CONTRIBUTING.md](../../CONTRIBUTING.md) 了解开发环境、规范与 PR 流程。 ## ⭐ Star 历史

**[Data Intelligence Lab @ HKU](https://github.com/HKUDS)** [⭐ Star](https://github.com/HKUDS/DeepTutor/stargazers) · [🐛 反馈问题](https://github.com/HKUDS/DeepTutor/issues) · [💬 讨论](https://github.com/HKUDS/DeepTutor/discussions) --- 采用 [Apache License 2.0](../../LICENSE) 许可。

# 参考资料 * any list {:toc}

Shannon — 由 Keygraph 打造的 AI 渗透测试工具

Tue, 07 Apr 2026 13:01:55 +0000

基于 Karpathy 理念的 Claude Code 指南

一个 CLAUDE.md 文件，用于改善 Claude Code 的行为，灵感源自 Andrej Karpathy 关于 LLM 编码陷阱的观察。

问题所在

引用 Andrej 的原文：

“模型会替你做错误的假设，并且不加验证地执行下去。它们不会管理自己的困惑，不会主动寻求澄清，不会指出不一致之处，不会呈现权衡方案，也不会在应该拒绝的时候提出异议。”

“它们非常喜欢把代码和 API 复杂化，堆砌抽象，不清理死代码……原本 100 行就能解决的问题，它们会搞出 1000 行的臃肿构造。”

“它们有时仍然会作为副作用，修改或删除自己不够理解的注释和代码——即使这些改动与当前任务正交。”

解决方案

用一个文件包含四条原则，直接针对上述问题：

原则	解决的问题
编码前三思	错误假设、隐藏的困惑、缺失的权衡
简单至上	过度复杂、臃肿的抽象
精准手术式修改	正交改动、改动不该动的代码
目标驱动执行	通过测试先行、可验证的成功标准来发挥模型能力

四条原则详解

1. 编码前三思

不要假设。不要隐藏困惑。要呈现权衡。

LLM 经常默默地选择一种理解方式，然后直接执行。这条原则迫使模型进行显式推理：

明确陈述假设 —— 如果不确定，主动询问，不要猜测
呈现多种理解方式 —— 存在歧义时，不要默默选一种
必要时提出异议 —— 如果有更简单的做法，直接说出来
困惑时停下来 —— 指出哪些地方不清楚，并要求澄清

2. 简单至上

以最少的代码解决问题。不写投机性的代码。

对抗过度工程的倾向：

不添加超出需求范围的功能
不为只用一次的代码创建抽象
不添加未被要求的“灵活性”或“可配置性”
不处理不可能发生的异常场景
如果 200 行代码可以用 50 行实现，就重写它

检验标准： 资深工程师会不会说这段代码过度复杂？如果会，就简化它。

3. 精准手术式修改

只动必须动的地方。只清理自己造成的垃圾。

在修改现有代码时：

不要“顺手改进”旁边的代码、注释或格式
不要重构没有坏的东西
匹配现有的代码风格，即使你自己会写成另一种样子
如果发现了不相关的死代码，可以提一下——但不要删除它

当你的修改产生了无用代码：

删除由于你的改动而不再使用的导入/变量/函数
除非被要求，否则不要删除预先存在的死代码

检验标准： 每一行被修改的代码，都应该能直接追溯到用户的需求。

4. 目标驱动执行

定义成功标准。循环执行，直到验证通过。

将命令式任务转化为可验证的目标：

不要这样说	而要转化为
“添加校验”	“编写针对无效输入的测试，然后让它们通过”
“修复这个 bug”	“编写能复现该 bug 的测试，然后让它通过”
“重构 X”	“确保重构前后测试都能通过”

对于多步骤任务，简要说明计划：

[步骤] → 验证：[检查项]
[步骤] → 验证：[检查项]
[步骤] → 验证：[检查项]

强力的成功标准能让 LLM 自主循环执行。弱标准（比如“把它做好”）则需要不断的澄清。

安装

方式 A：Claude Code 插件（推荐）

在 Claude Code 内部，先添加 marketplace：

/plugin marketplace add forrestchang/andrej-karpathy-skills

然后安装插件：

/plugin install andrej-karpathy-skills@karpathy-skills

这将把该指南作为 Claude Code 插件安装，使该 skill 在你的所有项目中可用。

方式 B：CLAUDE.md（每个项目单独配置）

新项目：

curl -o CLAUDE.md https://raw.githubusercontent.com/forrestchang/andrej-karpathy-skills/main/CLAUDE.md

已有项目（追加内容）：

echo "" >> CLAUDE.md
curl https://raw.githubusercontent.com/forrestchang/andrej-karpathy-skills/main/CLAUDE.md >> CLAUDE.md

核心见解

引用 Andrej：

“LLM 非常擅长循环执行，直到达成特定目标……不要告诉它做什么，给它成功标准，然后看它自己完成。”

“目标驱动执行”原则正是体现了这一点：将命令式指令转化为声明式目标，并配以验证循环。

如何判断它在起作用

如果你看到以下现象，说明这些指南正在起作用：

diff 中不必要的变化更少 —— 只有被要求的变化出现
因过度复杂导致的重写更少 —— 代码首次写出来就很简洁
澄清性问题在实现之前提出 —— 而不是犯错之后
干净、极简的 PR —— 没有顺便做的重构或“改进”

定制化

这些指南设计为可以与项目特定的指令合并使用。你可以把它们加到现有的 CLAUDE.md 中，或者新建一个。

对于项目特定的规则，可以添加类似下面的章节：

## 项目特定指南

- 使用 TypeScript 严格模式
- 所有 API 端点必须有测试
- 遵循 `src/utils/errors.ts` 中现有的错误处理模式

权衡说明

这些指南偏向于 谨慎优先，而非速度优先。对于琐碎的任务（简单的错别字修正、明显的一行改动），请自行判断——并非每次改动都需要完整执行全部原则。

目标是减少在非琐碎工作上代价高昂的错误，而不是拖慢简单任务的速度。

许可证

MIT

Clade-code 原文

CLAUDE.md

用于减少常见 LLM 编码错误的行为指南。可根据需要与项目特定的指令合并使用。

权衡说明： 这些指南偏向于谨慎优先，而非速度优先。对于琐碎的任务，请自行判断。

1. 编码前三思

不要假设。不要隐藏困惑。要呈现权衡。

在实现之前：

明确陈述你的假设。如果不确定，请主动询问。
如果存在多种理解方式，请列出来——不要默默地选择一种。
如果有更简单的做法，直接说出来。必要时提出异议。
如果某些事情不清楚，请停下来。指出哪里令人困惑。然后提问。

2. 简单至上

以最少的代码解决问题。不写投机性的代码。

不添加超出需求范围的功能。
不为只用一次的代码创建抽象。
不添加未被要求的“灵活性”或“可配置性”。
不处理不可能发生的异常场景。
如果你写了 200 行代码但可以用 50 行实现，请重写它。

问自己：“资深工程师会不会说这段代码过度复杂？” 如果会，就简化它。

3. 精准手术式修改

只动必须动的地方。只清理自己造成的垃圾。

在修改现有代码时：

不要“顺手改进”旁边的代码、注释或格式。
不要重构没有坏的东西。
匹配现有的代码风格，即使你自己会写成另一种样子。
如果发现了不相关的死代码，可以提一下——但不要删除它。

当你的修改产生了无用代码：

删除由于你的改动而不再使用的导入/变量/函数。
除非被要求，否则不要删除预先存在的死代码。

检验标准：每一行被修改的代码，都应该能直接追溯到用户的需求。

4. 目标驱动执行

定义成功标准。循环执行，直到验证通过。

将任务转化为可验证的目标：

“添加校验” → “编写针对无效输入的测试，然后让它们通过”
“修复这个 bug” → “编写能复现该 bug 的测试，然后让它通过”
“重构 X” → “确保重构前后测试都能通过”

对于多步骤任务，简要说明计划：

[步骤] → 验证：[检查项]
[步骤] → 验证：[检查项]
[步骤] → 验证：[检查项]

强力的成功标准能让你自主循环执行。弱标准（比如“把它做好”）则需要不断的澄清。

这些指南正在起作用的表现： diff 中不必要的变化更少，因过度复杂导致的重写更少，澄清性问题在实现之前提出——而不是犯错之后。

参考资料

基于 Karpathy 理念的 Claude Code 指南
Clade-code 原文
CLAUDE.md
参考资料

Shannon — 由 Keygraph 打造的 AI 渗透测试工具

Tue, 07 Apr 2026 13:01:55 +0000

Shannon — 由 Keygraph 打造的 AI 渗透测试工具

Shannon 是一个面向 Web 应用和 API 的自治型白盒 AI 渗透测试工具。它分析你的源代码，识别攻击向量，并执行真实漏洞利用，在问题进入生产环境之前加以验证。

</div>

Shannon 是什么？

Shannon 是由 Keygraph 开发的 AI 渗透测试工具。它通过将源代码分析与实时漏洞利用相结合，对 Web 应用及其底层 API 执行白盒安全测试。

Shannon 会分析你的 Web 应用源代码以识别潜在攻击向量，然后使用浏览器自动化和命令行工具，对运行中的应用及其 API 执行真实攻击（注入攻击、认证绕过、SSRF、XSS）。最终报告中仅包含具有可运行 PoC（概念验证）的漏洞。

为什么需要 Shannon

得益于像 Claude Code 和 Cursor 这样的工具，你的团队可以持续不断地交付代码。但你的渗透测试呢？可能一年才做一次。这会造成一个巨大的安全缺口。在其余 364 天中，你可能在不知情的情况下将漏洞发布到生产环境。

Shannon 通过提供按需、自动化的渗透测试来弥补这一缺口，可以对每一次构建或发布进行测试。

Shannon 实战

Shannon 在 OWASP 的 Juice Shop 中识别出了 20+ 个漏洞，包括认证绕过和数据库外泄。完整报告 →

![Demo](assets/shannon-action.gif)

功能特性

完全自治运行：一条命令即可启动完整渗透测试。Shannon 可自动处理 2FA/TOTP 登录（包括 SSO）、浏览器导航、漏洞利用以及报告生成，无需人工干预。
可复现的 PoC 漏洞利用：最终报告仅包含已验证、可利用的漏洞，并附带可复制执行的 PoC。无法被利用的漏洞不会被报告。
OWASP 漏洞覆盖：识别并验证注入、XSS、SSRF 以及认证/授权问题，更多类别正在开发中。
代码感知的动态测试：通过源代码分析指导攻击策略，并通过浏览器与 CLI 实际攻击验证结果。
集成安全工具：在侦察与发现阶段使用 Nmap、Subfinder、WhatWeb、Schemathesis。
并行处理：漏洞分析与利用阶段在所有攻击类别上并行执行。

产品线

Shannon 由 Keygraph 开发，提供两个版本：

版本	许可证	适用场景
Shannon Lite	AGPL-3.0	本地应用测试
Shannon Pro	商业版	需要统一 AppSec 平台的组织

本仓库包含 Shannon Lite，即核心自治 AI 渗透测试框架。 Shannon Pro 是 Keygraph 的一体化 AppSec 平台。

[!IMPORTANT] 仅支持白盒测试。 Shannon Lite 需要访问源代码。

Shannon Pro：架构概览

Shannon Pro 是一个一体化应用安全平台，通过两阶段流水线运行：

阶段 1：Agent 化静态分析

数据流分析（SAST）：识别输入源与危险 sink，并追踪路径
点位问题检测（SAST）：弱加密、硬编码凭证、不安全配置等
业务逻辑安全测试：发现应用不变量并生成 fuzz 测试
SCA 可达性分析：判断漏洞是否真实可达
Secrets 检测：正则 + LLM 检测并验证有效性

阶段 2：自治动态渗透测试

将静态分析结果注入攻击队列，执行真实漏洞利用。

静态-动态关联

核心能力：静态分析发现的漏洞必须通过真实攻击验证，并映射回源码位置。

📋 目录

（结构保持不变，略）

⚙️ 安装与使用

前置条件

Docker（容器运行时）
Node.js 18+（用于 npx）
pnpm（用于构建）
AI 提供商凭证（任选其一）

🚀 快速开始（推荐）

# 1. 配置凭证
npx @keygraph/shannon setup

# 或环境变量
export ANTHROPIC_API_KEY=your-api-key

# 2. 运行测试
npx @keygraph/shannon start -u https://your-app.com -r /path/to/your-repo

Clone & Build

git clone https://github.com/KeygraphHQ/shannon.git
cd shannon

pnpm install
pnpm build

./shannon start -u https://your-app.com -r /path/to/your-repo

常用命令

# 查看日志
npx @keygraph/shannon logs <workspace>

# 状态
npx @keygraph/shannon status

# 停止
npx @keygraph/shannon stop

Workspace（工作空间）

每次运行都会创建 workspace
支持断点续跑
数据存储在：
- 本地：./workspaces/
- npx：~/.shannon/workspaces/

输出结构

workspaces/{hostname}_{sessionId}/
├── session.json
├── workflow.log
├── agents/
├── prompts/
└── deliverables/
    └── comprehensive_security_assessment_report.md

示例报告

OWASP Juice Shop

发现 20+ 漏洞
包含 SQL 注入、权限提升、SSRF 等

👉 查看完整报告

Benchmark

Shannon Lite 在 XBOW 基准测试中达到了 96.15%（100/104 exploits）

👉 完整结果

架构

Pre-Recon → Recon → 漏洞分析 → 漏洞利用 → 报告

核心机制

多 Agent 架构
白盒 + 黑盒结合
“无利用，不报告”原则

⚠️ 使用声明

1. 不要在生产环境运行

该工具会主动执行攻击，可能修改数据。

2. 合法使用

必须获得系统所有者授权。

3. LLM 限制

可能存在幻觉
需要人工验证

4. 覆盖范围

当前支持：

认证/授权问题
注入
XSS
SSRF

5. 成本与性能

时间：约 1~1.5 小时
成本：约 $50（取决于模型）

📄 许可证

Shannon Lite 使用 AGPL-3.0 许可证。

🤝 社区与支持

📬 联系方式

Email: shannon@keygraph.io
官网: https://keygraph.io

参考资料

Shannon — 由 Keygraph 打造的 AI 渗透测试工具
参考资料

QMD - 查询标记文档（Query Markup Documents）

Tue, 07 Apr 2026 13:01:55 +0000

QMD - 查询标记文档（Query Markup Documents）

一款用于记忆一切所需信息的设备端搜索引擎。为您的 Markdown 笔记、会议记录、技术文档和知识库建立索引。

支持关键词或自然语言搜索。非常适合您的智能体流程。

QMD 结合了 BM25 全文检索、向量语义检索以及 LLM 重排序——所有这些均通过 node-llama-cpp 与 GGUF 模型在本地运行。

您可以在CHANGELOG中阅读更多关于 QMD 的进展。

快速开始

# 全局安装（Node 或 Bun）
npm install -g @tobilu/qmd
# 或
bun install -g @tobilu/qmd

# 直接运行
npx @tobilu/qmd ...
bunx @tobilu/qmd ...

# 为您的笔记、文档和会议记录创建集合
qmd collection add ~/notes --name notes
qmd collection add ~/Documents/meetings --name meetings
qmd collection add ~/work/docs --name docs

# 添加上下文以帮助改善搜索结果，当匹配的子文档被返回时，每一段上下文都会被一并返回。这构成了一棵树。这是 QMD 的关键特性，因为它使 LLM 在选择文档时能够做出更好的上下文决策。不要忽视它！
qmd context add qmd://notes "个人笔记和想法"
qmd context add qmd://meetings "会议记录和笔记"
qmd context add qmd://docs "工作文档"

# 生成向量嵌入以支持语义搜索
qmd embed

# 跨所有内容进行搜索
qmd search "项目时间线"           # 快速关键词搜索
qmd vsearch "如何部署"             # 语义搜索
qmd query "季度规划流程"            # 混合检索 + 重排序（最佳质量）

# 获取特定文档
qmd get "meetings/2024-01-15.md"

# 通过 docid 获取文档（显示在搜索结果中）
qmd get "#abc123"

# 通过 glob 模式批量获取多个文档
qmd multi-get "journals/2025-05*.md"

# 在特定集合内搜索
qmd search "API" -c notes

# 为智能体导出所有匹配结果
qmd search "API" --all --files --min-score 0.3

与 AI 智能体一起使用

QMD 的 --json 和 --files 输出格式专为智能体工作流设计：

# 获取供 LLM 使用的结构化结果
qmd search "authentication" --json -n 10

# 列出超过某个分数阈值的所有相关文件
qmd query "error handling" --all --files --min-score 0.4

# 检索完整文档内容
qmd get "docs/api-reference.md" --full

MCP 服务器

虽然您只需让智能体在命令行上使用该工具就可以完美运行，但 QMD 也提供了一个 MCP（模型上下文协议）服务器以实现更紧密的集成。

暴露的工具：

query — 使用类型化的子查询（lex/vec/hyde）进行搜索，通过 RRF + 重排序组合
get — 通过路径或 docid 检索文档（支持模糊匹配建议）
multi_get — 通过 glob 模式、逗号分隔列表或 docid 批量检索
status — 索引健康度和集合信息

Claude Desktop 配置（~/Library/Application Support/Claude/claude_desktop_config.json）：

{
  "mcpServers": {
    "qmd": {
      "command": "qmd",
      "args": ["mcp"]
    }
  }
}

Claude Code — 安装插件（推荐）：

claude plugin marketplace add tobi/qmd
claude plugin install qmd@qmd

或者在 ~/.claude/settings.json 中手动配置 MCP：

{
  "mcpServers": {
    "qmd": {
      "command": "qmd",
      "args": ["mcp"]
    }
  }
}

HTTP 传输

默认情况下，QMD 的 MCP 服务器使用 stdio（由每个客户端作为子进程启动）。要使用共享的、长期运行的服务器以避免重复加载模型，请使用 HTTP 传输：

# 前台运行（Ctrl-C 停止）
qmd mcp --http                    # localhost:8181
qmd mcp --http --port 8080        # 自定义端口

# 后台守护进程
qmd mcp --http --daemon           # 启动，将 PID 写入 ~/.cache/qmd/mcp.pid
qmd mcp stop                      # 通过 PID 文件停止
qmd status                        # 当激活时显示 "MCP: running (PID ...)"

HTTP 服务器暴露两个端点：

POST /mcp — MCP 可流式 HTTP（JSON 响应，无状态）
GET /health — 存活检查，包含运行时间

LLM 模型在跨请求期间保留在显存中。嵌入/重排序上下文在空闲 5 分钟后被释放，并在下一个请求时透明地重新创建（约 1 秒的代价，模型保持加载状态）。

将任何 MCP 客户端指向 http://localhost:8181/mcp 即可连接。

SDK / 库使用

在您自己的 Node.js 或 Bun 应用程序中将 QMD 作为库使用。

安装

npm install @tobilu/qmd

快速开始

import { createStore } from '@tobilu/qmd'

const store = await createStore({
  dbPath: './my-index.sqlite',
  config: {
    collections: {
      docs: { path: '/path/to/docs', pattern: '**/*.md' },
    },
  },
})

const results = await store.search({ query: "authentication flow" })
console.log(results.map(r => `${r.title} (${Math.round(r.score * 100)}%)`))

await store.close()

创建存储（Store）

createStore() 接受三种模式：

import { createStore } from '@tobilu/qmd'

// 1. 内联配置 — 除了数据库外无需其他文件
const store = await createStore({
  dbPath: './index.sqlite',
  config: {
    collections: {
      docs: { path: '/path/to/docs', pattern: '**/*.md' },
      notes: { path: '/path/to/notes' },
    },
  },
})

// 2. YAML 配置文件 — 在文件中定义集合
const store2 = await createStore({
  dbPath: './index.sqlite',
  configPath: './qmd.yml',
})

// 3. 仅数据库 — 重新打开之前配置过的存储
const store3 = await createStore({ dbPath: './index.sqlite' })

搜索

统一的 search() 方法既可处理简单查询，也可处理预扩展的结构化查询：

// 简单查询 — 由 LLM 自动扩展，然后 BM25 + 向量 + 重排序
const results = await store.search({ query: "authentication flow" })

// 带选项
const results2 = await store.search({
  query: "rate limiting",
  intent: "API throttling and abuse prevention",
  collection: "docs",
  limit: 5,
  minScore: 0.3,
  explain: true,
})

// 预扩展查询 — 跳过自动扩展，控制每个子查询
const results3 = await store.search({
  queries: [
    { type: 'lex', query: '"connection pool" timeout -redis' },
    { type: 'vec', query: 'why do database connections time out under load' },
  ],
  collections: ["docs", "notes"],
})

// 跳过重排序以获得更快的结果
const fast = await store.search({ query: "auth", rerank: false })

直接访问后端：

// BM25 关键词搜索（快速，无需 LLM）
const lexResults = await store.searchLex("auth middleware", { limit: 10 })

// 向量相似度搜索（嵌入模型，无重排序）
const vecResults = await store.searchVector("how users log in", { limit: 10 })

// 手动查询扩展以实现完全控制
const expanded = await store.expandQuery("auth flow", { intent: "user login" })
const results4 = await store.search({ queries: expanded })

检索

// 通过路径或 docid 获取文档
const doc = await store.get("docs/readme.md")
const byId = await store.get("#abc123")

if (!("error" in doc)) {
  console.log(doc.title, doc.displayPath, doc.context)
}

// 获取文档正文并指定行范围
const body = await store.getDocumentBody("docs/readme.md", {
  fromLine: 50,
  maxLines: 100,
})

// 通过 glob 模式或逗号分隔列表批量检索
const { docs, errors } = await store.multiGet("docs/**/*.md", {
  maxBytes: 20480,
})

集合

// 添加集合
await store.addCollection("myapp", {
  path: "/src/myapp",
  pattern: "**/*.ts",
  ignore: ["node_modules/**", "*.test.ts"],
})

// 列出集合及文档统计信息
const collections = await store.listCollections()
// => [{ name, pwd, glob_pattern, doc_count, active_count, last_modified, includeByDefault }]

// 获取默认包含在查询中的集合名称
const defaults = await store.getDefaultCollectionNames()

// 移除/重命名
await store.removeCollection("myapp")
await store.renameCollection("old-name", "new-name")

上下文

上下文添加描述性元数据，可提高搜索相关性，并随结果一起返回：

// 为集合内的路径添加上下文
await store.addContext("docs", "/api", "REST API reference documentation")

// 设置全局上下文（适用于所有集合）
await store.setGlobalContext("Internal engineering documentation")

// 列出所有上下文
const contexts = await store.listContexts()
// => [{ collection, path, context }]

// 移除上下文
await store.removeContext("docs", "/api")
await store.setGlobalContext(undefined)  // 清除全局上下文

索引

// 通过扫描文件系统重新索引集合
const result = await store.update({
  collections: ["docs"],  // 可选 — 默认所有集合
  onProgress: ({ collection, file, current, total }) => {
    console.log(`[${collection}] ${current}/${total} ${file}`)
  },
})
// => { collections, indexed, updated, unchanged, removed, needsEmbedding }

// 生成向量嵌入
const embedResult = await store.embed({
  force: false,           // true 表示重新嵌入所有内容
  chunkStrategy: "auto",  // "regex"（默认）或 "auto"（对代码文件使用 AST）
  onProgress: ({ current, total, collection }) => {
    console.log(`正在嵌入 ${current}/${total}`)
  },
})

类型

为 SDK 使用者导出的关键类型：

import type {
  QMDStore,            // 存储接口
  SearchOptions,       // search() 的选项
  LexSearchOptions,    // searchLex() 的选项
  VectorSearchOptions, // searchVector() 的选项
  HybridQueryResult,   // 搜索结果，包含分数、摘要、上下文
  SearchResult,        // searchLex/searchVector 的结果
  ExpandedQuery,       // 类型化子查询 { type: 'lex'|'vec'|'hyde', query }
  DocumentResult,      // 文档元数据 + 正文
  DocumentNotFound,    // 错误，包含 similarFiles 建议
  MultiGetResult,      // 批量检索结果
  UpdateProgress,      // update() 的回调进度信息
  UpdateResult,        // 聚合的更新结果
  EmbedProgress,       // embed() 的回调进度信息
  EmbedResult,         // 嵌入结果
  StoreOptions,        // createStore() 的选项
  CollectionConfig,    // 内联配置结构
  IndexStatus,         // 来自 getStatus()
  IndexHealthInfo,     // 来自 getIndexHealth()
} from '@tobilu/qmd'

工具导出：

import {
  extractSnippet,              // 从文本中提取相关摘要
  addLineNumbers,              // 为文本添加行号
  DEFAULT_MULTI_GET_MAX_BYTES, // multiGet 的默认最大文件大小（10KB）
  Maintenance,                 // 数据库维护操作
} from '@tobilu/qmd'

生命周期

// 关闭存储 — 释放 LLM 模型和数据库连接
await store.close()

SDK 需要显式指定 dbPath — 不假定任何默认值。这使得它可以安全地嵌入到任何应用程序中而不会产生副作用。

架构

┌─────────────────────────────────────────────────────────────────────────────┐
│                         QMD 混合搜索流程                                     │
└─────────────────────────────────────────────────────────────────────────────┘

                              ┌─────────────────┐
                              │    用户查询     │
                              └────────┬────────┘
                                       │
                        ┌──────────────┴──────────────┐
                        ▼                             ▼
               ┌────────────────┐            ┌────────────────┐
               │   查询扩展     │            │   原始查询     │
               │  （微调模型）  │            │   （×2 权重）  │
               └───────┬────────┘            └───────┬────────┘
                       │                             │
                       │ 2 个替代查询                 │
                       └──────────────┬──────────────┘
                                      │
              ┌───────────────────────┼───────────────────────┐
              ▼                       ▼                       ▼
     ┌─────────────────┐     ┌─────────────────┐     ┌─────────────────┐
     │   原始查询      │     │  扩展查询 1     │     │  扩展查询 2     │
     └────────┬────────┘     └────────┬────────┘     └────────┬────────┘
              │                       │                       │
      ┌───────┴───────┐       ┌───────┴───────┐       ┌───────┴───────┐
      ▼               ▼       ▼               ▼       ▼               ▼
  ┌───────┐       ┌───────┐ ┌───────┐     ┌───────┐ ┌───────┐     ┌───────┐
  │ BM25  │       │向量   │ │ BM25  │     │向量   │ │ BM25  │     │向量   │
  │(FTS5) │       │搜索   │ │(FTS5) │     │搜索   │ │(FTS5) │     │搜索   │
  └───┬───┘       └───┬───┘ └───┬───┘     └───┬───┘ └───┬───┘     └───┬───┘
      │               │         │             │         │             │
      └───────┬───────┘         └──────┬──────┘         └──────┬──────┘
              │                        │                       │
              └────────────────────────┼───────────────────────┘
                                       │
                                       ▼
                          ┌───────────────────────┐
                          │   RRF 融合 + 奖励分   │
                          │  原始查询：×2        │
                          │  首位奖励：+0.05     │
                          │  保留前 30 名         │
                          └───────────┬───────────┘
                                      │
                                      ▼
                          ┌───────────────────────┐
                          │    LLM 重排序         │
                          │  (qwen3-reranker)     │
                          │  是/否 + logprobs     │
                          └───────────┬───────────┘
                                      │
                                      ▼
                          ┌───────────────────────┐
                          │  位置感知混合         │
                          │  前 1-3 名：  75% RRF │
                          │  前 4-10 名： 60% RRF │
                          │  前 11 名+：  40% RRF │
                          └───────────────────────┘

分数归一化与融合

搜索后端

后端	原始分数	转换方式	范围
FTS (BM25)	SQLite FTS5 BM25	`Math.abs(score)`	0 到 ~25+
向量	余弦距离	`1 / (1 + distance)`	0.0 到 1.0
重排序器	LLM 0-10 评分	`score / 10`	0.0 到 1.0

融合策略

query 命令使用倒数排名融合（RRF）与位置感知混合：

查询扩展：原始查询（加权 ×2）+ 1 个 LLM 变体
并行检索：每个查询同时搜索 FTS 和向量索引
RRF 融合：使用 score = Σ(1/(k+rank+1)) 组合所有结果列表，其中 k=60
首位奖励：在任何列表中排名第 1 的文档获得 +0.05，第 2-3 名获得 +0.02
前 K 名选择：选取前 30 个候选进行重排序
重排序：LLM 为每个文档评分（是/否，带 logprobs 置信度）
位置感知混合：
- RRF 排名 1-3：75% 检索分数 + 25% 重排序分数（保留精确匹配）
- RRF 排名 4-10：60% 检索分数 + 40% 重排序分数
- RRF 排名 11+：40% 检索分数 + 60% 重排序分数（更信任重排序器）

为什么采用这种方法：当扩展查询与原始查询不匹配时，纯 RRF 可能会稀释精确匹配的结果。首位奖励机制保留了在原始查询中排名第 1 的文档。位置感知混合防止重排序破坏高置信度的检索结果。

分数解读

分数	含义
0.8 - 1.0	高度相关
0.5 - 0.8	中度相关
0.2 - 0.5	部分相关
0.0 - 0.2	低相关性

系统要求

Node.js >= 22
Bun >= 1.0.0
macOS：Homebrew SQLite（用于扩展支持）
```
brew install sqlite
```

GGUF 模型（通过 node-llama-cpp）

QMD 使用三个本地 GGUF 模型（首次使用时自动下载）：

模型	用途	大小
`embeddinggemma-300M-Q8_0`	向量嵌入（默认）	~300MB
`qwen3-reranker-0.6b-q8_0`	重排序	~640MB
`qmd-query-expansion-1.7B-q4_k_m`	查询扩展（微调）	~1.1GB

模型从 HuggingFace 下载，并缓存在 ~/.cache/qmd/models/ 中。

自定义嵌入模型

通过 QMD_EMBED_MODEL 环境变量覆盖默认的嵌入模型。这对于多语言语料库（例如中文、日文、韩文）特别有用，因为 embeddinggemma-300M 在这些语言上的覆盖范围有限。

# 使用 Qwen3-Embedding-0.6B 以获得更好的多语言（中日韩）支持
export QMD_EMBED_MODEL="hf:Qwen/Qwen3-Embedding-0.6B-GGUF/Qwen3-Embedding-0.6B-Q8_0.gguf"

# 更改模型后，重新嵌入所有集合：
qmd embed -f

支持的模型系列：

embeddinggemma（默认）— 针对英语优化，占用空间小
Qwen3-Embedding — 多语言（包括中日韩在内的 119 种语言），MTEB 排名前列

注意： 切换嵌入模型时，必须使用 qmd embed -f 重新索引，因为向量在不同模型之间不兼容。每种模型系列的提示格式会自动调整。

安装

npm install -g @tobilu/qmd
# 或
bun install -g @tobilu/qmd

开发

git clone https://github.com/tobi/qmd
cd qmd
npm install
npm link

使用说明

集合管理

# 从当前目录创建集合
qmd collection add . --name myproject

# 使用显式路径和自定义 glob 掩码创建集合
qmd collection add ~/Documents/notes --name notes --mask "**/*.md"

# 列出所有集合
qmd collection list

# 移除集合
qmd collection remove myproject

# 重命名集合
qmd collection rename myproject my-project

# 列出集合中的文件
qmd ls notes
qmd ls notes/subfolder

生成向量嵌入

# 嵌入所有已索引的文档（900 令牌/块，15% 重叠）
qmd embed

# 强制重新嵌入所有内容
qmd embed -f

# 对代码文件启用 AST 感知分块（TS、JS、Python、Go、Rust）
qmd embed --chunk-strategy auto

# 也可与 query 一起使用以保持一致的分块选择
qmd query "auth flow" --chunk-strategy auto

AST 感知分块（--chunk-strategy auto）使用 tree-sitter 在函数、类和导入边界处对代码文件进行分块，而不是在任意文本位置进行分块。这可以产生更高质量的块，并为代码库提供更好的搜索结果。Markdown 和其他文件类型无论策略如何都始终使用基于正则表达式的分块。

默认值为 regex（原有行为）。使用 --chunk-strategy auto 选择启用。运行 qmd status 以验证哪些语法库可用。

注意： Tree-sitter 语法库是可选依赖项。如果未安装，--chunk-strategy auto 会自动回退到仅使用正则表达式的分块。已在 Node.js 和 Bun 上测试。

上下文管理

上下文为集合和路径添加描述性元数据，帮助搜索引擎理解您的内容。

# 为集合添加上下文（使用 qmd:// 虚拟路径）
qmd context add qmd://notes "个人笔记和想法"
qmd context add qmd://docs/api "API 文档"

# 从集合目录内添加上下文
cd ~/notes && qmd context add "个人笔记和想法"
cd ~/notes/work && qmd context add "工作相关笔记"

# 添加全局上下文（适用于所有集合）
qmd context add / "我的项目知识库"

# 列出所有上下文
qmd context list

# 移除上下文
qmd context rm qmd://notes/old

搜索命令

┌──────────────────────────────────────────────────────────────────┐
│                        搜索模式                                   │
├──────────┬───────────────────────────────────────────────────────┤
│ search   │ 仅 BM25 全文检索                                      │
│ vsearch  │ 仅向量语义搜索                                        │
│ query    │ 混合：FTS + 向量 + 查询扩展 + 重排序                   │
└──────────┴───────────────────────────────────────────────────────┘

# 全文搜索（快速，基于关键词）
qmd search "authentication flow"

# 向量搜索（语义相似度）
qmd vsearch "how to login"

# 带重排序的混合搜索（最佳质量）
qmd query "user authentication"

选项

# 搜索选项
-n <num>           # 结果数量（默认：5，对于 --files/--json 则为 20）
-c, --collection   # 将搜索限制在特定集合
--all              # 返回所有匹配结果（与 --min-score 一起使用以过滤）
--min-score <num>  # 最低分数阈值（默认：0）
--full             # 显示完整文档内容
--line-numbers     # 为输出添加行号
--explain          # 包含检索分数追踪（query、JSON/CLI 输出）
--index <name>     # 使用指定名称的索引

# 输出格式（用于 search 和 multi-get）
--files            # 输出：docid,score,filepath,context
--json             # JSON 输出，包含摘要
--csv              # CSV 输出
--md               # Markdown 输出
--xml              # XML 输出

# get 选项
qmd get <file>[:line]  # 获取文档，可选择从某行开始
-l <num>               # 返回的最大行数
--from <num>           # 从指定行号开始

# multi-get 选项
-l <num>           # 每个文件的最大行数
--max-bytes <num>  # 跳过大于 N 字节的文件（默认：10KB）

输出格式

默认输出为彩色 CLI 格式（遵循 NO_COLOR 环境变量）。

当 stdout 是 TTY 时，结果路径会作为可点击的终端超链接（OSC 8）发出。点击路径将使用编辑器 URI 模板在您的编辑器中打开文件。

当 stdout 不是 TTY 时（例如通过管道传给另一个命令或重定向到文件），QMD 会输出纯文本路径，不带转义序列。

TTY 示例：

docs/guide.md:42 #a1b2c3
标题：软件工匠精神
上下文：工作文档
分数：93%

本节涵盖了构建高质量软件时需关注的**工匠精神**。
另见：工程原则


notes/meeting.md:15 #d4e5f6
标题：Q4 规划
上下文：个人笔记和想法
分数：67%

讨论开发过程中的代码质量和工匠精神。

使用 QMD_EDITOR_URI（或配置文件中的 editor_uri）配置编辑器链接目标：

# VS Code（默认）
export QMD_EDITOR_URI="vscode://file/{path}:{line}:{col}"

# Cursor
export QMD_EDITOR_URI="cursor://file/{path}:{line}:{col}"

# Zed
export QMD_EDITOR_URI="zed://file/{path}:{line}:{col}"

# Sublime Text
export QMD_EDITOR_URI="subl://open?url=file://{path}&line={line}"

模板占位符：

{path} 绝对文件系统路径（URI 编码）
{line} 基于 1 的行号
{col} 或 {column} 基于 1 的列号
路径：相对于集合的路径（例如 docs/guide.md）
Docid：短哈希标识符（例如 #a1b2c3）— 使用 qmd get #a1b2c3
标题：从文档中提取（第一个标题或文件名）
上下文：通过 qmd context add 配置的路径上下文
分数：颜色编码（绿色 >70%，黄色 >40%，否则为暗色）
摘要：匹配项周围的上下文，查询词高亮显示

示例

# 获取 10 个结果，最低分数 0.3
qmd query -n 10 --min-score 0.3 "API design patterns"

# 以 markdown 格式输出，供 LLM 上下文使用
qmd search --md --full "error handling"

# 用于脚本的 JSON 输出
qmd query --json "quarterly reports"

# 检查每个结果的得分方式（RRF + 重排序混合）
qmd query --json --explain "quarterly reports"

# 为不同的知识库使用独立的索引
qmd --index work search "quarterly reports"

索引维护

# 显示索引状态以及带上下文的集合
qmd status

# 重新索引所有集合
qmd update

# 先执行 git pull 再重新索引（适用于远程仓库）
qmd update --pull

# 通过文件路径获取文档（支持模糊匹配建议）
qmd get notes/meeting.md

# 通过 docid 获取文档（来自搜索结果）
qmd get "#abc123"

# 从第 50 行开始获取文档，最多 100 行
qmd get notes/meeting.md:50 -l 100

# 通过 glob 模式批量获取多个文档
qmd multi-get "journals/2025-05*.md"

# 通过逗号分隔列表批量获取多个文档（支持 docid）
qmd multi-get "doc1.md, doc2.md, #abc123"

# 将 multi-get 限制在 20KB 以下的文件
qmd multi-get "docs/*.md" --max-bytes 20480

# 以 JSON 格式输出 multi-get 结果，供智能体处理
qmd multi-get "docs/*.md" --json

# 清理缓存和孤立数据
qmd cleanup

数据存储

索引存储位置：~/.cache/qmd/index.sqlite

模式

collections     -- 已索引的目录，包含名称和 glob 模式
path_contexts   -- 按虚拟路径（qmd://...）的上下文描述
documents       -- Markdown 内容，包含元数据和 docid（6 字符哈希）
documents_fts   -- FTS5 全文索引
content_vectors -- 嵌入块（hash, seq, pos，每块 900 令牌）
vectors_vec     -- sqlite-vec 向量索引（hash_seq 键）
llm_cache       -- 缓存的 LLM 响应（查询扩展、重排序分数）

环境变量

变量	默认值	描述
`XDG_CACHE_HOME`	`~/.cache`	缓存目录位置

工作原理

索引流程

集合 ──► Glob 模式 ──► Markdown 文件 ──► 解析标题 ──► 哈希内容
    │                                                   │              │
    │                                                   │              ▼
    │                                                   │         生成 docid
    │                                                   │         （6 字符哈希）
    │                                                   │              │
    └──────────────────────────────────────────────────►└──► 存入 SQLite
                                                                       │
                                                                       ▼
                                                                  FTS5 索引

嵌入流程

文档被分成约 900 令牌的块，块之间有 15% 的重叠，并使用智能边界检测：

文档 ──► 智能分块（~900 令牌）──► 格式化每个块 ──► node-llama-cpp ──► 存储向量
                │                          "标题 | 文本"        embedBatch()
                │
                └─► 存储的块包含：
                    - hash: 文档哈希
                    - seq: 块序号（0, 1, 2...）
                    - pos: 在原文档中的字符位置

智能分块

QMD 不使用硬性的令牌边界切分，而是使用评分算法来寻找自然的 Markdown 断点。这样可以保持语义单元（章节、段落、代码块）的完整性。

断点评分：

模式	分数	描述
`# Heading`	100	H1 - 主要章节
`## Heading`	90	H2 - 子章节
`### Heading`	80	H3
`#### Heading`	70	H4
`##### Heading`	60	H5
`###### Heading`	50	H6
` ``` `	80	代码块边界
`---` / `***`	60	水平线
空行	20	段落边界
`- item` / `1. item`	5	列表项
换行	1	最小断点

算法：

扫描文档中所有带分数的断点
当接近 900 令牌目标时，在截止点之前的 200 令牌窗口内搜索
计算每个断点的最终分数：finalScore = baseScore × (1 - (distance/window)² × 0.7)
在得分最高的断点处切分

平方距离衰减意味着在 200 令牌前的标题（分数约 30）仍然优于目标位置的简单换行（分数 1），但更近的标题会胜过远处的标题。

代码块保护： 代码块内部的断点会被忽略——代码保持在一起。如果代码块超过块大小，则尽可能保持完整。

AST 感知分块（代码文件）：

对于受支持的代码文件，QMD 还会使用 tree-sitter 解析源代码，并添加从 AST 派生的断点，这些断点与上述正则表达式分数合并：

AST 节点	分数	语言
类 / 接口 / 结构体 / impl / trait	100	所有
函数 / 方法	90	所有
类型别名 / 枚举	80	所有
导入 / 使用声明	60	所有

支持 .ts、.tsx、.js、.jsx、.py、.go 和 .rs 文件。使用 --chunk-strategy auto 启用。Markdown 和其他文件类型始终使用基于正则表达式的分块。

查询流程（混合）

查询 ──► LLM 扩展 ──► [原始, 变体 1, 变体 2]
                │
      ┌─────────┴─────────┐
      ▼                   ▼
   对于每个查询：       FTS (BM25)
      │                   │
      ▼                   ▼
   向量搜索            排名列表
      │
      ▼
   排名列表
      │
      └─────────┬─────────┘
                ▼
         RRF 融合（k=60）
         原始查询 ×2 权重
         首位奖励：第 1 名 +0.05，第 2-3 名 +0.02
                │
                ▼
         前 30 个候选
                │
                ▼
         LLM 重排序
         （是/否 + logprob 置信度）
                │
                ▼
         位置感知混合
         排名 1-3：  75% RRF / 25% 重排序
         排名 4-10： 60% RRF / 40% 重排序
         排名 11+：  40% RRF / 60% 重排序
                │
                ▼
         最终结果

模型配置

模型在 src/llm.ts 中配置为 HuggingFace URI：

const DEFAULT_EMBED_MODEL = "hf:ggml-org/embeddinggemma-300M-GGUF/embeddinggemma-300M-Q8_0.gguf";
const DEFAULT_RERANK_MODEL = "hf:ggml-org/Qwen3-Reranker-0.6B-Q8_0-GGUF/qwen3-reranker-0.6b-q8_0.gguf";
const DEFAULT_GENERATE_MODEL = "hf:tobil/qmd-query-expansion-1.7B-gguf/qmd-query-expansion-1.7B-q4_k_m.gguf";

EmbeddingGemma 提示格式

// 查询
"task: search result | query: {query}"

// 文档
"title: {title} | text: {content}"

Qwen3-Reranker

使用 node-llama-cpp 的 createRankingContext() 和 rankAndSort() API 进行交叉编码器重排序。返回按相关性分数（0.0 - 1.0）排序的文档。

Qwen3（查询扩展）

用于通过 LlamaChatSession 生成查询变体。

许可证

MIT

参考资料

QMD - 查询标记文档（Query Markup Documents）
参考资料

PersonaPlex：全双工会话语音模型的语音与角色控制

Tue, 07 Apr 2026 13:01:55 +0000

PersonaPlex：全双工会话语音模型的语音与角色控制

PersonaPlex 是一个实时的、全双工的语音到语音对话模型，它能够通过基于文本的角色提示和基于音频的语音条件来实现角色控制。

该模型在合成对话和真实对话的混合数据上进行训练，能够产生自然、低延迟且具有一致人设的口语交互。

PersonaPlex 基于 Moshi 架构和权重。

PersonaPlex 架构

使用方法

前提条件

安装 Opus 音频编解码器开发库：

# Ubuntu/Debian
sudo apt install libopus-dev

# Fedora/RHEL
sudo dnf install opus-devel

安装

下载本仓库并使用以下命令安装：

pip install moshi/.

针对基于 Blackwell 架构的 GPU 的额外步骤（参见 https://github.com/NVIDIA/personaplex/issues/2）：

pip install torch torchvision torchaudio --index-url https://download.pytorch.org/whl/cu130

接受模型许可

登录您的 Huggingface 账号，并在此处接受 PersonaPlex 模型许可。
然后设置 Huggingface 认证：

export HF_TOKEN=<您的_HUGGINGFACE_TOKEN>

启动服务器

启动服务器进行实时交互（使用临时 SSL 证书启用 https）：

SSL_DIR=$(mktemp -d); python -m moshi.server --ssl "$SSL_DIR"

CPU 卸载： 如果您的 GPU 显存不足，请使用 --cpu-offload 标志将模型层卸载到 CPU。这需要安装 accelerate 包（pip install accelerate）：

SSL_DIR=$(mktemp -d); python -m moshi.server --ssl "$SSL_DIR" --cpu-offload

在浏览器中访问 Web UI：如果在本地运行，地址为 localhost:8998；否则请查看脚本打印的访问链接：

Access the Web UI directly at https://11.54.401.33:8998

离线评估

对于离线评估，请使用离线脚本，该脚本流式读入一个输入 wav 文件，并从捕获的输出流生成一个输出 wav 文件。输出文件的时长与输入文件相同。

如果您的 GPU 显存不足，可以在以下任何命令中添加 --cpu-offload（需要 accelerate 包）。或者，在纯 CPU 上进行离线评估时，安装仅 CPU 版本的 PyTorch。

助手示例：

HF_TOKEN=<TOKEN> \
python -m moshi.offline \
  --voice-prompt "NATF2.pt" \
  --input-wav "assets/test/input_assistant.wav" \
  --seed 42424242 \
  --output-wav "output.wav" \
  --output-text "output.json"

服务示例：

HF_TOKEN=<TOKEN> \
python -m moshi.offline \
  --voice-prompt "NATM1.pt" \
  --text-prompt "$(cat assets/test/prompt_service.txt)" \
  --input-wav "assets/test/input_service.wav" \
  --seed 42424242 \
  --output-wav "output.wav" \
  --output-text "output.json"

语音

PersonaPlex 支持多种语音；我们预先打包了听起来更自然、更具对话性的语音（NAT）的嵌入，以及其他更多样化的语音（VAR）。固定的语音集标记如下：

自然（女声）： NATF0, NATF1, NATF2, NATF3
自然（男声）：   NATM0, NATM1, NATM2, NATM3
多样（女声）： VARF0, VARF1, VARF2, VARF3, VARF4
多样（男声）：   VARM0, VARM1, VARM2, VARM3, VARM4

提示指南

该模型在针对固定助手角色和多种客服角色的合成对话上进行了训练。

助手角色

助手角色的提示为：

You are a wise and friendly teacher. Answer questions or provide advice in a clear and engaging way.

在 FullDuplexBench 的“用户打断”评估类别中，将此提示用于以问答为中心的助手。

客服角色

客服角色支持多种提示。以下是一些提示风格参考示例：

You work for CitySan Services which is a waste management and your name is Ayelen Lucero. Information: Verify customer name Omar Torres. Current schedule: every other week. Upcoming pickup: April 12th. Compost bin service available for $8/month add-on.

You work for Jerusalem Shakshuka which is a restaurant and your name is Owen Foster. Information: There are two shakshuka options: Classic (poached eggs, $9.50) and Spicy (scrambled eggs with jalapenos, $10.25). Sides include warm pita ($2.50) and Israeli salad ($3). No combo offers. Available for drive-through until 9 PM.

You work for AeroRentals Pro which is a drone rental company and your name is Tomaz Novak. Information: AeroRentals Pro has the following availability: PhoenixDrone X ($65/4 hours, $110/8 hours), and the premium SpectraDrone 9 ($95/4 hours, $160/8 hours). Deposit required: $150 for standard models, $300 for premium.

日常对话

该模型还在 Fisher English Corpus 的真实对话上进行了训练，并使用 LLM 标记的提示进行开放式对话。以下是一些日常对话的提示示例：

You enjoy having a good conversation.

You enjoy having a good conversation. Have a casual discussion about eating at home versus dining out.

You enjoy having a good conversation. Have an empathetic discussion about the meaning of family amid uncertainty.

You enjoy having a good conversation. Have a reflective conversation about career changes and feeling of home. You have lived in California for 21 years and consider San Francisco your home. You work as a teacher and have traveled a lot. You dislike meetings.

You enjoy having a good conversation. Have a casual conversation about favorite foods and cooking experiences. You are David Green, a former baker now living in Boston. You enjoy cooking diverse international dishes and appreciate many ethnic restaurants.

在 FullDuplexBench 的“暂停处理”、“回馈信号”和“平滑轮替”评估类别中，使用提示 You enjoy having a good conversation.。

泛化能力

PersonaPlex 对 Moshi 进行了微调，并受益于底层 Helium LLM 的泛化能力。得益于主干模型的广泛训练语料，我们发现模型能够对分布外提示做出合理的响应，并引出意想不到或有趣的对话。我们鼓励使用不同的提示进行实验，以测试模型处理其训练分布之外场景的涌现能力。作为启发，我们在 WebUI 中提供了以下宇航员提示：

You enjoy having a good conversation. Have a technical discussion about fixing a reactor core on a spaceship to Mars. You are an astronaut on a Mars mission. Your name is Alex. You are already dealing with a reactor core meltdown on a Mars mission. Several ship systems are failing, and continued instability will lead to catastrophic failure. You explain what is happening and you urgently ask for help thinking through how to stabilize the reactor.

许可证

本代码采用 MIT 许可证提供。模型的权重依据 NVIDIA 开放模型许可证发布。

引用

如果您在研究中使用了 PersonaPlex，请引用我们的论文：

@misc{roy2026personaplexvoicerolecontrol,
      title={PersonaPlex: Voice and Role Control for Full Duplex Conversational Speech Models}, 
      author={Rajarshi Roy and Jonathan Raiman and Sang-gil Lee and Teodor-Dumitru Ene and Robert Kirby and Sungwon Kim and Jaehyeon Kim and Bryan Catanzaro},
      year={2026},
      eprint={2602.06053},
      archivePrefix={arXiv},
      primaryClass={cs.CL},
      url={https://arxiv.org/abs/2602.06053}, 
}

参考资料

PersonaPlex：全双工会话语音模型的语音与角色控制
参考资料

llama.cpp 的主要目标是在广泛多样的硬件上（本地和云端）以最少的设置和最先进的性能实现 LLM 推理。

Tue, 07 Apr 2026 13:01:55 +0000

llama.cpp

宣言 / ggml / 操作

C/C++ 中的 LLM 推理

近期 API 变更

快速开始

开始使用 llama.cpp 非常简单。以下是几种在您的机器上安装它的方法：

使用 brew、nix 或 winget 安装 llama.cpp
使用 Docker 运行——请参阅我们的 Docker 文档
从发布页面下载预编译二进制文件
通过克隆本仓库从源码构建——请查看我们的构建指南

安装完成后，您需要一个模型来使用。请前往获取和量化模型部分了解更多信息。

示例命令：

# 使用本地模型文件
llama-cli -m my_model.gguf

# 或者直接从 Hugging Face 下载并运行模型
llama-cli -hf ggml-org/gemma-3-1b-it-GGUF

# 启动兼容 OpenAI 的 API 服务器
llama-server -hf ggml-org/gemma-3-1b-it-GGUF

描述

llama.cpp 的主要目标是在广泛多样的硬件上（本地和云端）以最少的设置和最先进的性能实现 LLM 推理。

纯 C/C++ 实现，无任何依赖
Apple Silicon 是一等公民——通过 ARM NEON、Accelerate 和 Metal 框架进行优化
对 x86 架构提供 AVX、AVX2、AVX512 和 AMX 支持
对 RISC-V 架构提供 RVV、ZVFH、ZFH、ZICBOP 和 ZIHINTPAUSE 支持
1.5-bit、2-bit、3-bit、4-bit、5-bit、6-bit 和 8-bit 整数量化，以实现更快的推理和减少内存使用
用于在 NVIDIA GPU 上运行 LLM 的自定义 CUDA 内核（通过 HIP 支持 AMD GPU，通过 MUSA 支持 Moore Threads GPU）
支持 Vulkan 和 SYCL 后端
CPU+GPU 混合推理，以部分加速超过总显存容量的大模型

llama.cpp 项目是为 ggml 库开发新功能的主要试验场。

模型

通常，以下基础模型的微调版本也得到支持。添加新模型支持的说明：[HOWTO-add-model.md](docs/development/HOWTO-add-model.md) #### 纯文本 - [X] LLaMA 🦙 - [x] LLaMA 2 🦙🦙 - [x] LLaMA 3 🦙🦙🦙 - [X] [Mistral 7B](https://huggingface.co/mistralai/Mistral-7B-v0.1) - [x] [Mixtral MoE](https://huggingface.co/models?search=mistral-ai/Mixtral) - [x] [DBRX](https://huggingface.co/databricks/dbrx-instruct) - [x] [Jamba](https://huggingface.co/ai21labs) - [X] [Falcon](https://huggingface.co/models?search=tiiuae/falcon) - [X] [Chinese LLaMA / Alpaca](https://github.com/ymcui/Chinese-LLaMA-Alpaca) 和 [Chinese LLaMA-2 / Alpaca-2](https://github.com/ymcui/Chinese-LLaMA-Alpaca-2) - [X] [Vigogne（法语）](https://github.com/bofenghuang/vigogne) - [X] [BERT](https://github.com/ggml-org/llama.cpp/pull/5423) - [X] [Koala](https://bair.berkeley.edu/blog/2023/04/03/koala/) - [X] [Baichuan 1 & 2](https://huggingface.co/models?search=baichuan-inc/Baichuan) + [衍生模型](https://huggingface.co/hiyouga/baichuan-7b-sft) - [X] [Aquila 1 & 2](https://huggingface.co/models?search=BAAI/Aquila) - [X] [Starcoder 模型](https://github.com/ggml-org/llama.cpp/pull/3187) - [X] [Refact](https://huggingface.co/smallcloudai/Refact-1_6B-fim) - [X] [MPT](https://github.com/ggml-org/llama.cpp/pull/3417) - [X] [Bloom](https://github.com/ggml-org/llama.cpp/pull/3553) - [x] [Yi 模型](https://huggingface.co/models?search=01-ai/Yi) - [X] [StableLM 模型](https://huggingface.co/stabilityai) - [x] [Deepseek 模型](https://huggingface.co/models?search=deepseek-ai/deepseek) - [x] [Qwen 模型](https://huggingface.co/models?search=Qwen/Qwen) - [x] [PLaMo-13B](https://github.com/ggml-org/llama.cpp/pull/3557) - [x] [Phi 模型](https://huggingface.co/models?search=microsoft/phi) - [x] [PhiMoE](https://github.com/ggml-org/llama.cpp/pull/11003) - [x] [GPT-2](https://huggingface.co/gpt2) - [x] [Orion 14B](https://github.com/ggml-org/llama.cpp/pull/5118) - [x] [InternLM2](https://huggingface.co/models?search=internlm2) - [x] [CodeShell](https://github.com/WisdomShell/codeshell) - [x] [Gemma](https://ai.google.dev/gemma) - [x] [Mamba](https://github.com/state-spaces/mamba) - [x] [Grok-1](https://huggingface.co/keyfan/grok-1-hf) - [x] [Xverse](https://huggingface.co/models?search=xverse) - [x] [Command-R 模型](https://huggingface.co/models?search=CohereForAI/c4ai-command-r) - [x] [SEA-LION](https://huggingface.co/models?search=sea-lion) - [x] [GritLM-7B](https://huggingface.co/GritLM/GritLM-7B) + [GritLM-8x7B](https://huggingface.co/GritLM/GritLM-8x7B) - [x] [OLMo](https://allenai.org/olmo) - [x] [OLMo 2](https://allenai.org/olmo) - [x] [OLMoE](https://huggingface.co/allenai/OLMoE-1B-7B-0924) - [x] [Granite 模型](https://huggingface.co/collections/ibm-granite/granite-code-models-6624c5cec322e4c148c8b330) - [x] [GPT-NeoX](https://github.com/EleutherAI/gpt-neox) + [Pythia](https://github.com/EleutherAI/pythia) - [x] [Snowflake-Arctic MoE](https://huggingface.co/collections/Snowflake/arctic-66290090abe542894a5ac520) - [x] [Smaug](https://huggingface.co/models?search=Smaug) - [x] [Poro 34B](https://huggingface.co/LumiOpen/Poro-34B) - [x] [Bitnet b1.58 模型](https://huggingface.co/1bitLLM) - [x] [Flan T5](https://huggingface.co/models?search=flan-t5) - [x] [Open Elm 模型](https://huggingface.co/collections/apple/openelm-instruct-models-6619ad295d7ae9f868b759ca) - [x] [ChatGLM3-6b](https://huggingface.co/THUDM/chatglm3-6b) + [ChatGLM4-9b](https://huggingface.co/THUDM/glm-4-9b) + [GLMEdge-1.5b](https://huggingface.co/THUDM/glm-edge-1.5b-chat) + [GLMEdge-4b](https://huggingface.co/THUDM/glm-edge-4b-chat) - [x] [GLM-4-0414](https://huggingface.co/collections/THUDM/glm-4-0414-67f3cbcb34dd9d252707cb2e) - [x] [SmolLM](https://huggingface.co/collections/HuggingFaceTB/smollm-6695016cad7167254ce15966) - [x] [EXAONE-3.0-7.8B-Instruct](https://huggingface.co/LGAI-EXAONE/EXAONE-3.0-7.8B-Instruct) - [x] [FalconMamba 模型](https://huggingface.co/collections/tiiuae/falconmamba-7b-66b9a580324dd1598b0f6d4a) - [x] [Jais](https://huggingface.co/inceptionai/jais-13b-chat) - [x] [Bielik-11B-v2.3](https://huggingface.co/collections/speakleash/bielik-11b-v23-66ee813238d9b526a072408a) - [x] [RWKV-7](https://huggingface.co/collections/shoumenchougou/rwkv7-gxx-gguf) - [x] [RWKV-6](https://github.com/BlinkDL/RWKV-LM) - [x] [QRWKV-6](https://huggingface.co/recursal/QRWKV6-32B-Instruct-Preview-v0.1) - [x] [GigaChat-20B-A3B](https://huggingface.co/ai-sage/GigaChat-20B-A3B-instruct) - [X] [Trillion-7B-preview](https://huggingface.co/trillionlabs/Trillion-7B-preview) - [x] [Ling 模型](https://huggingface.co/collections/inclusionAI/ling-67c51c85b34a7ea0aba94c32) - [x] [LFM2 模型](https://huggingface.co/collections/LiquidAI/lfm2-686d721927015b2ad73eaa38) - [x] [Hunyuan 模型](https://huggingface.co/collections/tencent/hunyuan-dense-model-6890632cda26b19119c9c5e7) - [x] [BailingMoeV2（Ring/Ling 2.0）模型](https://huggingface.co/collections/inclusionAI/ling-v2-68bf1dd2fc34c306c1fa6f86) #### 多模态 - [x] [LLaVA 1.5 模型](https://huggingface.co/collections/liuhaotian/llava-15-653aac15d994e992e2677a7e)，[LLaVA 1.6 模型](https://huggingface.co/collections/liuhaotian/llava-16-65b9e40155f60fd046a5ccf2) - [x] [BakLLaVA](https://huggingface.co/models?search=SkunkworksAI/Bakllava) - [x] [Obsidian](https://huggingface.co/NousResearch/Obsidian-3B-V0.5) - [x] [ShareGPT4V](https://huggingface.co/models?search=Lin-Chen/ShareGPT4V) - [x] [MobileVLM 1.7B/3B 模型](https://huggingface.co/models?search=mobileVLM) - [x] [Yi-VL](https://huggingface.co/models?search=Yi-VL) - [x] [Mini CPM](https://huggingface.co/models?search=MiniCPM) - [x] [Moondream](https://huggingface.co/vikhyatk/moondream2) - [x] [Bunny](https://github.com/BAAI-DCAI/Bunny) - [x] [GLM-EDGE](https://huggingface.co/models?search=glm-edge) - [x] [Qwen2-VL](https://huggingface.co/collections/Qwen/qwen2-vl-66cee7455501d7126940800d) - [x] [LFM2-VL](https://huggingface.co/collections/LiquidAI/lfm2-vl-68963bbc84a610f7638d5ffa)

绑定

- Python: [ddh0/easy-llama](https://github.com/ddh0/easy-llama) - Python: [abetlen/llama-cpp-python](https://github.com/abetlen/llama-cpp-python) - Go: [go-skynet/go-llama.cpp](https://github.com/go-skynet/go-llama.cpp) - Node.js: [withcatai/node-llama-cpp](https://github.com/withcatai/node-llama-cpp) - JS/TS（llama.cpp 服务器客户端）: [lgrammel/modelfusion](https://modelfusion.dev/integration/model-provider/llamacpp) - JS/TS（可编程提示引擎 CLI）: [offline-ai/cli](https://github.com/offline-ai/cli) - JavaScript/Wasm（可在浏览器中运行）: [tangledgroup/llama-cpp-wasm](https://github.com/tangledgroup/llama-cpp-wasm) - Typescript/Wasm（更友好的 API，在 npm 上可用）: [ngxson/wllama](https://github.com/ngxson/wllama) - Ruby: [yoshoku/llama_cpp.rb](https://github.com/yoshoku/llama_cpp.rb) - Rust（更多功能）: [edgenai/llama_cpp-rs](https://github.com/edgenai/llama_cpp-rs) - Rust（更友好的 API）: [mdrokz/rust-llama.cpp](https://github.com/mdrokz/rust-llama.cpp) - Rust（更直接的绑定）: [utilityai/llama-cpp-rs](https://github.com/utilityai/llama-cpp-rs) - Rust（来自 crates.io 的自动构建）: [ShelbyJenkins/llm_client](https://github.com/ShelbyJenkins/llm_client) - C#/.NET: [SciSharp/LLamaSharp](https://github.com/SciSharp/LLamaSharp) - C#/VB.NET（更多功能 - 社区许可证）: [LM-Kit.NET](https://docs.lm-kit.com/lm-kit-net/index.html) - Scala 3: [donderom/llm4s](https://github.com/donderom/llm4s) - Clojure: [phronmophobic/llama.clj](https://github.com/phronmophobic/llama.clj) - React Native: [mybigday/llama.rn](https://github.com/mybigday/llama.rn) - Java: [kherud/java-llama.cpp](https://github.com/kherud/java-llama.cpp) - Java: [QuasarByte/llama-cpp-jna](https://github.com/QuasarByte/llama-cpp-jna) - Zig: [deins/llama.cpp.zig](https://github.com/Deins/llama.cpp.zig) - Flutter/Dart: [netdur/llama_cpp_dart](https://github.com/netdur/llama_cpp_dart) - Flutter: [xuegao-tzx/Fllama](https://github.com/xuegao-tzx/Fllama) - PHP（基于 llama.cpp 的 API 绑定和功能）: [distantmagic/resonance](https://github.com/distantmagic/resonance) [（更多信息）](https://github.com/ggml-org/llama.cpp/pull/6326) - Guile Scheme: [guile_llama_cpp](https://savannah.nongnu.org/projects/guile-llama-cpp) - Swift: [srgtuszy/llama-cpp-swift](https://github.com/srgtuszy/llama-cpp-swift) - Swift: [ShenghaiWang/SwiftLlama](https://github.com/ShenghaiWang/SwiftLlama) - Delphi: [Embarcadero/llama-cpp-delphi](https://github.com/Embarcadero/llama-cpp-delphi) - Go（无需 CGo）: [hybridgroup/yzma](https://github.com/hybridgroup/yzma) - Android: [llama.android](/examples/llama.android)

UI 界面

*（要使项目在此列出，应明确声明其依赖于 `llama.cpp`）* - [AI Sublime Text 插件](https://github.com/yaroslavyaroslav/OpenAI-sublime-text)（MIT） - [BonzAI App](https://apps.apple.com/us/app/bonzai-your-local-ai-agent/id6752847988)（专有） - [cztomsik/ava](https://github.com/cztomsik/ava)（MIT） - [Dot](https://github.com/alexpinel/Dot)（GPL） - [eva](https://github.com/ylsdamxssjxxdd/eva)（MIT） - [iohub/collama](https://github.com/iohub/coLLaMA)（Apache-2.0） - [janhq/jan](https://github.com/janhq/jan)（AGPL） - [johnbean393/Sidekick](https://github.com/johnbean393/Sidekick)（MIT） - [KanTV](https://github.com/zhouwg/kantv?tab=readme-ov-file)（Apache-2.0） - [KodiBot](https://github.com/firatkiral/kodibot)（GPL） - [llama.vim](https://github.com/ggml-org/llama.vim)（MIT） - [LARS](https://github.com/abgulati/LARS)（AGPL） - [Llama Assistant](https://github.com/vietanhdev/llama-assistant)（GPL） - [LlamaLib](https://github.com/undreamai/LlamaLib)（Apache-2.0） - [LLMFarm](https://github.com/guinmoon/LLMFarm?tab=readme-ov-file)（MIT） - [LLMUnity](https://github.com/undreamai/LLMUnity)（MIT） - [LMStudio](https://lmstudio.ai/)（专有） - [LocalAI](https://github.com/mudler/LocalAI)（MIT） - [LostRuins/koboldcpp](https://github.com/LostRuins/koboldcpp)（AGPL） - [MindMac](https://mindmac.app)（专有） - [MindWorkAI/AI-Studio](https://github.com/MindWorkAI/AI-Studio)（FSL-1.1-MIT） - [Mobile-Artificial-Intelligence/maid](https://github.com/Mobile-Artificial-Intelligence/maid)（MIT） - [Mozilla-Ocho/llamafile](https://github.com/Mozilla-Ocho/llamafile)（Apache-2.0） - [nat/openplayground](https://github.com/nat/openplayground)（MIT） - [nomic-ai/gpt4all](https://github.com/nomic-ai/gpt4all)（MIT） - [ollama/ollama](https://github.com/ollama/ollama)（MIT） - [oobabooga/text-generation-webui](https://github.com/oobabooga/text-generation-webui)（AGPL） - [PocketPal AI](https://github.com/a-ghorbani/pocketpal-ai)（MIT） - [psugihara/FreeChat](https://github.com/psugihara/FreeChat)（MIT） - [ptsochantaris/emeltal](https://github.com/ptsochantaris/emeltal)（MIT） - [pythops/tenere](https://github.com/pythops/tenere)（AGPL） - [ramalama](https://github.com/containers/ramalama)（MIT） - [semperai/amica](https://github.com/semperai/amica)（MIT） - [withcatai/catai](https://github.com/withcatai/catai)（MIT） - [Autopen](https://github.com/blackhole89/autopen)（GPL）

工具

- [akx/ggify](https://github.com/akx/ggify) – 从 Hugging Face Hub 下载 PyTorch 模型并转换为 GGML - [akx/ollama-dl](https://github.com/akx/ollama-dl) – 从 Ollama 库下载模型，直接与 llama.cpp 一起使用 - [crashr/gppm](https://github.com/crashr/gppm) – 启动利用 NVIDIA Tesla P40 或 P100 GPU 的 llama.cpp 实例，降低空闲功耗 - [gpustack/gguf-parser](https://github.com/gpustack/gguf-parser-go/tree/main/cmd/gguf-parser) - 查看/检查 GGUF 文件并估算内存使用量 - [Styled Lines](https://marketplace.unity.com/packages/tools/generative-ai/styled-lines-llama-cpp-model-292902)（专有许可，用于 Unity3d 游戏开发的推理部分异步包装器，提供预构建的移动端和 Web 平台包装器以及模型示例） - [unslothai/unsloth](https://github.com/unslothai/unsloth) – 🦥 将微调和训练好的模型导出/保存为 GGUF（Apache-2.0）

基础设施

- [Paddler](https://github.com/intentee/paddler) - 开源 LLMOps 平台，用于在您自己的基础设施中托管和扩展 AI - [GPUStack](https://github.com/gpustack/gpustack) - 管理 GPU 集群以运行 LLM - [llama_cpp_canister](https://github.com/onicai/llama_cpp_canister) - llama.cpp 作为互联网计算机上的智能合约，使用 WebAssembly - [llama-swap](https://github.com/mostlygeek/llama-swap) - 透明代理，为 llama-server 添加自动模型切换功能 - [Kalavai](https://github.com/kalavai-net/kalavai-client) - 众包端到端 LLM 部署，任意规模 - [llmaz](https://github.com/InftyAI/llmaz) - ☸️ 在 Kubernetes 上为大型语言模型提供简单、高级的推理平台。 - [LLMKube](https://github.com/defilantech/llmkube) - 支持多 GPU 和 Apple Silicon Metal 的 llama.cpp Kubernetes 操作器

游戏

- [Lucy's Labyrinth](https://github.com/MorganRO8/Lucys_Labyrinth) - 一个简单的迷宫游戏，由 AI 模型控制的智能体将试图欺骗您。

支持的后端

后端	目标设备
Metal	Apple Silicon
BLAS	所有
BLIS	所有
SYCL	Intel 和 Nvidia GPU
OpenVINO [进行中]	Intel CPU、GPU 和 NPU
MUSA	Moore Threads GPU
CUDA	Nvidia GPU
HIP	AMD GPU
ZenDNN	AMD CPU
Vulkan	GPU
CANN	Ascend NPU
OpenCL	Adreno GPU
IBM zDNN	IBM Z 和 LinuxONE
WebGPU [进行中]	所有
RPC	所有
Hexagon [进行中]	Snapdragon
VirtGPU	VirtGPU APIR

获取和量化模型

Hugging Face 平台托管了许多与 llama.cpp 兼容的 LLM：

趋势
LLaMA

您可以手动下载 GGUF 文件，或者直接使用来自 Hugging Face 或其他模型托管站点的任何与 llama.cpp 兼容的模型，通过使用此 CLI 参数：-hf <用户>/<模型>[:量化]。例如：

llama-cli -hf ggml-org/gemma-3-1b-it-GGUF

默认情况下，CLI 会从 Hugging Face 下载，您可以使用环境变量 MODEL_ENDPOINT 切换到其他选项。MODEL_ENDPOINT 必须指向与 Hugging Face 兼容的 API 端点。

下载模型后，使用 CLI 工具在本地运行它——请参见下文。

llama.cpp 要求模型以 GGUF 文件格式存储。其他数据格式的模型可以使用本仓库中的 convert_*.py Python 脚本转换为 GGUF。

Hugging Face 平台提供了多种在线工具，用于使用 llama.cpp 转换、量化和托管模型：

使用 GGUF-my-repo space 转换为 GGUF 格式并将模型权重量化为更小的大小
使用 GGUF-my-LoRA space 将 LoRA 适配器转换为 GGUF 格式（更多信息：https://github.com/ggml-org/llama.cpp/discussions/10123）
使用 GGUF-editor space 在浏览器中编辑 GGUF 元数据（更多信息：https://github.com/ggml-org/llama.cpp/discussions/9268）
使用 Inference Endpoints 在云端直接托管 llama.cpp（更多信息：https://github.com/ggml-org/llama.cpp/discussions/9669）

要了解有关模型量化的更多信息，请阅读此文档

`llama-cli`

用于访问和试验 `llama.cpp` 大部分功能的 CLI 工具。

以对话模式运行
具有内置聊天模板的模型将自动激活对话模式。如果未发生这种情况，您可以通过添加 `-cnv` 并使用 `--chat-template NAME` 指定合适的聊天模板来手动启用它。 ```bash llama-cli -m model.gguf # > 嗨，你是谁？ # 您好！我是您的有用助手！我是一个由 AI 驱动的聊天机器人，旨在为像您这样的用户提供帮助和信息。我在这里帮助回答您的问题、提供指导并在一系列广泛的主题上提供支持。我是一个友好且知识渊博的 AI，随时乐意为您提供任何需要的帮助。您在想什么，我今天能如何帮助您？ # # > 1+1 等于多少？ # 简单！1+1 的答案是……2！ ```
使用自定义聊天模板以对话模式运行
```bash # 使用 "chatml" 模板（使用 -h 查看支持的模板列表） llama-cli -m model.gguf -cnv --chat-template chatml # 使用自定义模板 llama-cli -m model.gguf -cnv --in-prefix 'User: ' --reverse-prompt 'User:' ```
使用自定义语法约束输出
```bash llama-cli -m model.gguf -n 256 --grammar-file grammars/json.gbnf -p 'Request: schedule a call at 8pm; Command:' # {"appointmentTime": "8pm", "appointmentDetails": "schedule a a call"} ``` [grammars/](grammars/) 文件夹包含一些示例语法。要编写您自己的语法，请查看 [GBNF 指南](grammars/README.md)。要编写更复杂的 JSON 语法，请查看 https://grammar.intrinsiclabs.ai/

`llama-server`

一个轻量级、兼容 OpenAI API 的 HTTP 服务器，用于服务 LLM。

在端口 8080 上使用默认配置启动本地 HTTP 服务器
```bash llama-server -m model.gguf --port 8080 # 可通过浏览器访问基本 Web UI：http://localhost:8080 # 聊天补全端点：http://localhost:8080/v1/chat/completions ```
支持多用户和并行解码
```bash # 最多 4 个并发请求，每个请求最大上下文为 4096 llama-server -m model.gguf -c 16384 -np 4 ```
启用推测解码
```bash # draft.gguf 模型应是目标 model.gguf 的一个小型变体 llama-server -m model.gguf -md draft.gguf ```
服务嵌入模型
```bash # 使用 /embedding 端点 llama-server -m model.gguf --embedding --pooling cls -ub 8192 ```
服务重排序模型
```bash # 使用 /reranking 端点 llama-server -m model.gguf --reranking ```
使用语法约束所有输出
```bash # 自定义语法 llama-server -m model.gguf --grammar-file grammar.gbnf # JSON llama-server -m model.gguf --grammar-file grammars/json.gbnf ```

`llama-perplexity`

用于测量模型在给定文本上的困惑度 ¹（和其他质量指标）的工具。

测量文本文件的困惑度
```bash llama-perplexity -m model.gguf -f file.txt # [1]15.2701,[2]5.4007,[3]5.3073,[4]6.2965,[5]5.8940,[6]5.6096,[7]5.7942,[8]4.9297, ... # 最终估计：PPL = 5.4007 +/- 0.67339 ```
测量 KL 散度
```bash # TODO ```

`llama-bench`

对各种参数的推理性能进行基准测试。

运行默认基准测试
```bash llama-bench -m model.gguf # 输出： # | model | size | params | backend | threads | test | t/s | # | ------------------- | ---------: | ---------: | ---------- | ------: | ------------: | -------------------: | # | qwen2 1.5B Q4_0 | 885.97 MiB | 1.54 B | Metal,BLAS | 16 | pp512 | 5765.41 ± 20.55 | # | qwen2 1.5B Q4_0 | 885.97 MiB | 1.54 B | Metal,BLAS | 16 | tg128 | 197.71 ± 0.81 | # # build: 3e0ba0e60 (4229) ```

`llama-simple`

使用 `llama.cpp` 实现应用程序的最小示例。对开发者有用。

基本文本补全
```bash llama-simple -m model.gguf # 你好，我叫 Kaitlyn，我是一个 16 岁的女孩。我现在高中三年级，目前正在上一门叫“艺术”的课 ```

贡献

贡献者可以开启 PR
合作者将根据贡献情况被邀请
维护者可以推送到 llama.cpp 仓库的分支，并将 PR 合并到 master 分支
任何帮助管理 issue、PR 和项目的帮助都深表感谢！
查看适合初学者的 issue 以获取适合首次贡献的任务
阅读 CONTRIBUTING.md 了解更多信息
请务必阅读：边缘推理
为有兴趣的人提供一些背景故事：Changelog 播客

其他文档

开发文档

开创性论文和模型背景

如果您的问题与模型生成质量有关，请至少浏览以下链接和论文，以了解 LLaMA 模型的局限性。这对于选择合适的模型大小以及理解 LLaMA 模型与 ChatGPT 之间的显著和细微差别尤为重要：

LLaMA：
- Introducing LLaMA: A foundational, 65-billion-parameter large language model
- LLaMA: Open and Efficient Foundation Language Models
GPT-3
- Language Models are Few-Shot Learners
GPT-3.5 / InstructGPT / ChatGPT：
- Aligning language models to follow instructions
- Training language models to follow instructions with human feedback

XCFramework

XCFramework 是适用于 iOS、visionOS、tvOS 和 macOS 的库的预编译版本。它可以在 Swift 项目中使用，无需从源代码编译库。例如：

// swift-tools-version: 5.10
// swift-tools-version 声明构建此包所需的最低 Swift 版本。

import PackageDescription

let package = Package(
    name: "MyLlamaPackage",
    targets: [
        .executableTarget(
            name: "MyLlamaPackage",
            dependencies: [
                "LlamaFramework"
            ]),
        .binaryTarget(
            name: "LlamaFramework",
            url: "https://github.com/ggml-org/llama.cpp/releases/download/b5046/llama-b5046-xcframework.zip",
            checksum: "c19be78b5f00d8d29a25da41042cb7afa094cbf6280a225abe614b03b20029ab"
        )
    ]
)

上面的示例使用的是库的中间版本 b5046。通过更改 URL 和校验和，可以修改为使用不同的版本。

补全

某些环境支持命令行补全。

Bash 补全

$ build/bin/llama-cli --completion-bash > ~/.llama-completion.bash
$ source ~/.llama-completion.bash

可以选择将其添加到 .bashrc 或 .bash_profile 中以自动加载。例如：

$ echo "source ~/.llama-completion.bash" >> ~/.bashrc

依赖项

yhirose/cpp-httplib - 单头文件 HTTP 服务器，被 llama-server 使用 - MIT 许可证
stb-image - 单头文件图像格式解码器，被多模态子系统使用 - 公共领域
nlohmann/json - 单头文件 JSON 库，被各种工具/示例使用 - MIT 许可证
miniaudio.h - 单头文件音频格式解码器，被多模态子系统使用 - 公共领域
subprocess.h - 用于 C 和 C++ 的单头文件进程启动解决方案 - 公共领域

参考资料

llama.cpp
参考资料

https://huggingface.co/docs/transformers/perplexity ↩

Ollama 构建开放模型

Tue, 07 Apr 2026 13:01:55 +0000

Ollama

开始使用开放模型进行构建。

下载

macOS

curl -fsSL https://ollama.com/install.sh | sh

或手动下载

Windows

irm https://ollama.com/install.ps1 | iex

或手动下载

Linux

curl -fsSL https://ollama.com/install.sh | sh

手动安装说明

Docker

官方的 Ollama Docker 镜像 ollama/ollama 可在 Docker Hub 上获取。

库

社区

快速开始

ollama

系统会提示您运行模型，或者将 Ollama 连接到您现有的智能体或应用程序，例如 claude、codex、openclaw 等。

编码

要启动特定的集成：

ollama launch claude

支持的集成包括 Claude Code、Codex、Droid 和 OpenCode。

AI 助手

使用 OpenClaw 将 Ollama 转变为跨 WhatsApp、Telegram、Slack、Discord 等的个人 AI 助手：

ollama launch openclaw

与模型聊天

运行并与 Gemma 3 聊天：

ollama run gemma3

完整列表请参见 ollama.com/library。

更多详情请参阅快速入门指南。

REST API

Ollama 提供了用于运行和管理模型的 REST API。

curl http://localhost:11434/api/chat -d '{
  "model": "gemma3",
  "messages": [{
    "role": "user",
    "content": "Why is the sky blue?"
  }],
  "stream": false
}'

有关所有端点的信息，请参阅 API 文档。

Python

pip install ollama

from ollama import chat

response = chat(model='gemma3', messages=[
  {
    'role': 'user',
    'content': 'Why is the sky blue?',
  },
])
print(response.message.content)

JavaScript

npm i ollama

import ollama from "ollama";

const response = await ollama.chat({
  model: "gemma3",
  messages: [{ role: "user", content: "Why is the sky blue?" }],
});
console.log(response.message.content);

支持的后端

llama.cpp 项目，由 Georgi Gerganov 创建。

文档

社区集成

想添加您的项目？请发起拉取请求。

聊天界面

Web

Open WebUI - 可扩展的自托管 AI 界面
Onyx - 互联的 AI 工作区
LibreChat - 增强版 ChatGPT 克隆，支持多提供商
Lobe Chat - 现代聊天框架，带有插件生态系统（文档）
NextChat - 跨平台 ChatGPT UI（文档）
Perplexica - AI 驱动的搜索引擎，开源的 Perplexity 替代品
big-AGI - 面向专业人士的 AI 套件
Lollms WebUI - 多模型 Web 界面
ChatOllama - 带知识库的聊天机器人
Bionic GPT - 本地部署 AI 平台
Chatbot UI - ChatGPT 风格 Web 界面
Hollama - 极简 Web 界面
Chatbox - 桌面和 Web AI 客户端
chat - 面向团队的聊天 Web 应用
Ollama RAG Chatbot - 使用 RAG 与多个 PDF 聊天
Tkinter-based client - Python 桌面客户端

桌面

Dify.AI - LLM 应用开发平台
AnythingLLM - 面向 Mac、Windows 和 Linux 的全能 AI 应用
Maid - 跨平台移动和桌面客户端
Witsy - 面向 Mac、Windows 和 Linux 的 AI 桌面应用
Cherry Studio - 多提供商桌面客户端
Ollama App - 跨平台客户端，支持桌面和移动端
PyGPT - 面向 Linux、Windows 和 Mac 的 AI 桌面助手
Alpaca - 面向 Linux 和 macOS 的 GTK4 客户端
SwiftChat - 跨平台，包括 iOS、Android 和 Apple Vision Pro
Enchanted - 原生 macOS 和 iOS 客户端
RWKV-Runner - 多模型桌面运行器
Ollama Grid Search - 评估和比较模型
macai - 面向 Ollama 和 ChatGPT 的 macOS 客户端
AI Studio - 多提供商桌面 IDE
Reins - 参数调优和推理模型支持
ConfiChat - 注重隐私，支持可选加密
LLocal.in - Electron 桌面客户端
MindMac - Mac 版 AI 聊天客户端
Msty - 多模型桌面客户端
BoltAI for Mac - Mac 版 AI 聊天客户端
IntelliBar - macOS AI 助手
Kerlig AI - macOS AI 写作助手
Hillnote - Markdown 优先的 AI 工作区
Perfect Memory AI - 通过屏幕和会议历史进行个性化的生产力 AI

移动端

Ollama Android Chat - 一键在 Android 上运行 Ollama

上面列出的 SwiftChat、Enchanted、Maid、Ollama App、Reins 和 ConfiChat 也支持移动平台。

代码编辑器与开发

Cline - 用于多文件/全仓库编码的 VS Code 扩展
Continue - 适用于任何 IDE 的开源 AI 代码助手
Void - 开源 AI 代码编辑器，Cursor 替代品
Copilot for Obsidian - Obsidian 的 AI 助手
twinny - Copilot 和 Copilot Chat 替代品
gptel Emacs client - Emacs 的 LLM 客户端
Ollama Copilot - 将 Ollama 用作 GitHub Copilot
Obsidian Local GPT - Obsidian 的本地 AI
Ellama Emacs client - Emacs 的 LLM 工具
orbiton - 无配置文本编辑器，支持 Ollama 制表符补全
AI ST Completion - Sublime Text 4 AI 助手
VT Code - 基于 Rust 的终端编码智能体，使用 Tree-sitter
QodeAssist - Qt Creator 的 AI 编码助手
AI Toolkit for VS Code - Microsoft 官方 VS Code 扩展
Open Interpreter - 计算机的自然语言界面

库与 SDK

LiteLLM - 面向 100+ LLM 提供商的统一 API
Semantic Kernel - Microsoft AI 编排 SDK
LangChain4j - Java LangChain（示例）
LangChainGo - Go LangChain（示例）
Spring AI - Spring 框架 AI 支持（文档）
LangChain 和 LangChain.js 及示例
Ollama for Ruby - Ruby LLM 库
any-llm - Mozilla 的统一 LLM 接口
OllamaSharp for .NET - .NET SDK
LangChainRust - Rust LangChain（示例）
Agents-Flex for Java - Java 智能体框架（示例）
Elixir LangChain - Elixir LangChain
Ollama-rs for Rust - Rust SDK
LangChain for .NET - .NET LangChain（示例）
chromem-go - 支持 Ollama 嵌入的 Go 向量数据库（示例）
LangChainDart - Dart LangChain
LlmTornado - 面向多个推理 API 的统一 C# 接口
Ollama4j for Java - Java SDK
Ollama for Laravel - Laravel 集成
Ollama for Swift - Swift SDK
LlamaIndex 和 LlamaIndexTS - LLM 应用的数据框架
Haystack - AI 流水线框架
Firebase Genkit - Google AI 框架
Ollama-hpp for C++ - C++ SDK
PromptingTools.jl - Julia LLM 工具包（示例）
Ollama for R - rollama - R SDK
Portkey - AI 网关
Testcontainers - 基于容器的测试
LLPhant - PHP AI 框架

框架与智能体

AutoGPT - 自主 AI 智能体平台
crewAI - 多智能体编排框架
Strands Agents - AWS 的模型驱动智能体构建
Cheshire Cat - AI 助手框架
any-agent - Mozilla 的统一智能体框架接口
Stakpak - 开源 DevOps 智能体
Hexabot - 对话式 AI 构建器
Neuro SAN - 多智能体编排（文档）

RAG 与知识库

RAGFlow - 基于深度文档理解的 RAG 引擎
R2R - 开源 RAG 引擎
MaxKB - 开箱即用的 RAG 聊天机器人
Minima - 本地部署或完全本地的 RAG
Chipper - 使用 Haystack RAG 的 AI 界面
ARGO - 在 Mac/Windows/Linux 上的 RAG 与深度研究
Archyve - 支持 RAG 的文档库
Casibase - 具备 RAG 和 SSO 的 AI 知识库
BrainSoup - 原生客户端，支持 RAG 和多智能体自动化

机器人与消息

LangBot - 多平台消息机器人，支持智能体和 RAG
AstrBot - 多平台聊天机器人，支持 RAG 和插件
Discord-Ollama Chat Bot - TypeScript Discord 机器人
Ollama Telegram Bot - Telegram 机器人
LLM Telegram Bot - 用于角色扮演的 Telegram 机器人

终端与 CLI

aichat - 全能 LLM CLI，带有 Shell 助手、RAG 和 AI 工具
oterm - Ollama 的终端客户端
gollama - 基于 Go 的 Ollama 模型管理器
tlm - 本地 shell 副驾驶
tenere - LLM 的 TUI
ParLlama - Ollama 的 TUI
llm-ollama - Datasette 的 LLM CLI 的插件
ShellOracle - Shell 命令建议
LLM-X - LLM 的渐进式 Web 应用
cmdh - 自然语言转 shell 命令
VT - 极简多模态 AI 聊天应用

生产力与应用

AppFlowy - AI 协作工作区，自托管的 Notion 替代品
Screenpipe - 24/7 屏幕和麦克风录制，支持 AI 搜索
Vibe - 转录和分析会议
Page Assist - 用于 AI 辅助浏览的 Chrome 扩展
NativeMind - 私有的设备端浏览器 AI 助手
Ollama Fortress - Ollama 的安全代理
1Panel - 基于 Web 的 Linux 服务器管理
Writeopia - 集成 Ollama 的文本编辑器
QA-Pilot - GitHub 代码仓库理解
Raycast extension - Raycast 中的 Ollama
Painting Droid - 集成 AI 的绘图应用
Serene Pub - AI 角色扮演应用
Mayan EDMS - 支持 Ollama 工作流的文档管理
TagSpaces - 文件管理，支持 AI 标记

可观测性与监控

Opik - 调试、评估和监控 LLM 应用
OpenLIT - 面向 Ollama 和 GPU 的 OpenTelemetry 原生监控
Lunary - LLM 可观测性，包含分析和 PII 脱敏
Langfuse - 开源 LLM 可观测性
HoneyHive - 面向智能体的 AI 可观测性与评估
MLflow Tracing - 开源 LLM 可观测性

数据库与嵌入

pgai - 作为向量数据库的 PostgreSQL（指南）
MindsDB - 将 Ollama 与 200+ 数据平台连接
chromem-go - 用于 Go 的可嵌入向量数据库（示例）
Kangaroo - AI 驱动的 SQL 客户端

基础设施与部署

云

Google Cloud
Fly.io
Koyeb
Harbor - 容器化 LLM 工具包，以 Ollama 为默认后端

包管理器

参考资料

Ollama
- 下载
  - macOS
  - Windows
  - Linux
  - Docker
  - 库
  - 社区
- 快速开始
- REST API
  - Python
  - JavaScript
- 支持的后端
- 文档
- 社区集成
参考资料

obsidian skills 用于 Obsidian 的智能体技能

Tue, 07 Apr 2026 13:01:55 +0000

用于 Obsidian 的智能体技能

这些技能遵循智能体技能规范，因此任何兼容智能体技能的工具（包括 Claude Code 和 Codex CLI）都可以使用它们。

安装

市场

/plugin marketplace add kepano/obsidian-skills
/plugin install obsidian@obsidian-skills

npx skills

npx skills add git@github.com:kepano/obsidian-skills.git

手动安装

Claude Code

将此仓库的内容添加到 Obsidian 仓库根目录下的 /.claude 文件夹中（或您与 Claude Code 一起使用的任何文件夹）。更多信息请参阅官方 Claude 技能文档。

Codex CLI

将 skills/ 目录复制到您的 Codex 技能路径中（通常为 ~/.codex/skills）。有关标准技能格式，请参见智能体技能规范。

OpenCode

将整个仓库克隆到 OpenCode 技能目录（~/.opencode/skills/）中：

git clone https://github.com/kepano/obsidian-skills.git ~/.opencode/skills/obsidian-skills

不要只复制内部的 skills/ 文件夹——请克隆完整仓库，以使目录结构为 ~/.opencode/skills/obsidian-skills/skills/<技能名称>/SKILL.md。

OpenCode 会自动发现 ~/.opencode/skills/ 下的所有 SKILL.md 文件。无需更改 opencode.json 或任何配置文件。重启 OpenCode 后技能即可使用。

技能

技能	描述
obsidian-markdown	创建和编辑 Obsidian 风味 Markdown（`.md`），支持维基链接、嵌入、标注、属性以及其他 Obsidian 特有语法
obsidian-bases	创建和编辑 Obsidian Bases（`.base`），支持视图、筛选器、公式和摘要
json-canvas	创建和编辑 JSON Canvas 文件（`.canvas`），支持节点、边、组和连接
obsidian-cli	通过 Obsidian CLI 与 Obsidian 仓库交互，包括插件和主题开发
defuddle	使用 Defuddle 从网页中提取干净的 markdown，去除杂音以节省令牌

参考资料

用于 Obsidian 的智能体技能
- 安装
  - 市场
  - npx skills
  - 手动安装
- 技能
参考资料

immich 高性能的照片和视频自托管解决方案

Tue, 07 Apr 2026 13:01:55 +0000

immich

免责声明

⚠️ 本项目正在 非常活跃 地开发中。
⚠️ 可能存在 bug 或者随时有重大变更。
⚠️ 不要把本软件作为您存储照片或视频的唯一方式。
⚠️ 为了您宝贵的照片与视频，请始终遵守 3-2-1 备份方案！

[!NOTE] 完整的项目文档以及安装教程请参见：https://immich.app/。

示例

您可以在此处访问在线演示网站。在移动端，您可以使用 https://demo.immich.app 作为 服务终端链接

登录认证信息

邮箱	密码
demo@immich.app	demo

功能特性

功能特性	移动端	网页端
上传并查看照片和视频	是	是
软件运行时自动备份	是	N/A
忽略重复的项目	是	是
选择需要备份的相册	是	N/A
下载照片和视频到本地	是	是
多用户支持	是	是
相册与共享相册	是	是
可拖动的快速滚动条	是	是
支持RAW格式	是	是
元数据视图（EXIF、地图）	是	是
通过元数据、对象、人脸和标签进行搜索	是	是
管理功能（用户管理）	否	是
后台备份	是	N/A
虚拟滚动	是	是
OAuth 支持	是	是
API Keys	N/A	是
实况照片备份和查看	是	是
支持360度全景图显示	否	是
用户自定义存储结构	是	是
公共分享	是	是
归档与收藏功能	是	是
足迹地图	是	是
好友分享	是	是
人脸识别与分组	是	是
回忆（那年今日）	是	是
离线支持	是	否
只读相册	是	是
照片堆叠	是	是
标签	否	是
文件夹浏览	否	是

多语言

关于翻译的更多信息请参见此处。

活跃度

Star增长曲线

</a>

贡献者

参考资料

immich
参考资料

Google AI Edge Gallery 使用 Google AI Edge 探索、体验并评估端侧生成式 AI 的未来

Tue, 07 Apr 2026 13:01:55 +0000

Google AI Edge Gallery ✨

使用 Google AI Edge 探索、体验并评估端侧生成式 AI 的未来。

AI Edge Gallery 是在您的移动设备上运行全球最强大的开源大语言模型（LLMs）的首选平台。

直接在您的硬件上体验高性能生成式 AI——完全离线、私密且极速。

现已支持：Gemma 4

最新版本带来了对全新发布的 Gemma 4 系列的官方支持。作为本次发布的核心，Gemma 4 让您可以测试端侧 AI 的前沿能力。在无需将数据发送到服务器的情况下，体验先进的推理、逻辑和创造能力。

安装

立即从 Google Play 安装应用	立即从 App Store 安装应用

对于无法访问 Google Play 的用户，请从 最新发布版本 安装 apk。

应用预览

✨ 核心功能

Agent Skills（智能体技能）：将您的 LLM 从对话者转变为主动助手。使用 Agent Skills 面板，通过维基百科等工具进行事实校准，并提供交互式地图和丰富的可视化摘要卡片来增强模型能力。您甚至可以从 URL 加载模块化技能，或在 GitHub Discussions 上浏览社区贡献。
带 Thinking Mode 的 AI 聊天：进行流畅的多轮对话，并可切换新的 Thinking Mode（思考模式）以“窥探内部机制”。该功能允许您查看模型逐步推理过程，非常适合理解复杂问题的解决方式。注意：Thinking Mode 当前仅支持部分模型，从 Gemma 4 系列开始。
Ask Image（图像问答）：利用多模态能力，通过设备相机或相册识别物体、解决视觉问题，或获取详细描述。
Audio Scribe（音频转写）：使用高效的端侧语言模型，将语音录音实时转写并翻译为文本。
Prompt Lab（提示实验室）：一个专用工作区，用于测试不同提示词和单轮使用场景，并可精细控制模型参数（如 temperature 和 top-k）。
Mobile Actions（移动操作）：通过对 FunctionGemma 270m 的微调，实现完全离线的设备控制和自动化任务。
Tiny Garden（迷你花园）：一个有趣的实验性小游戏，基于 FunctionGemma 270m 微调模型，使用自然语言种植和收获虚拟花园。
模型管理与基准测试（Model Management & Benchmark）：Gallery 是一个支持多种开源模型的灵活沙箱。可以轻松从列表下载模型或加载自定义模型。便捷管理模型库，并运行基准测试，以准确了解每个模型在您设备上的性能表现。
100% 端侧隐私：所有模型推理均直接在您的设备硬件上完成。无需互联网连接，确保您的提示、图像和敏感数据的完全隐私。

🏁 几分钟内快速开始！

检查操作系统要求：Android 12 及以上，iOS 17 及以上。
下载应用：
- 从 Google Play 或 App Store 安装应用。
- 无法访问 Google Play 的用户：从 最新发布版本 安装 apk
安装并探索：如需详细安装说明（包括企业设备）以及完整用户指南，请访问我们的 项目 Wiki

🛠️ 技术亮点

Google AI Edge：端侧机器学习的核心 API 与工具
LiteRT：用于优化模型执行的轻量级运行时
Hugging Face 集成：用于模型发现与下载

⌨️ 开发

查看 development notes 获取如何在本地构建应用的说明。

🤝 反馈

这是一个实验性 Beta 版本，您的反馈至关重要！

🐞 发现 Bug？ 在此报告！
💡 有想法？ 提交功能建议！

📄 许可证

本项目基于 Apache License 2.0 版本授权。详情请参阅 LICENSE 文件。

🔗 有用链接

参考资料

Google AI Edge Gallery ✨
参考资料

LiteRT-LM 是 Google 的生产级、高性能、开源推理框架，用于在边缘设备上部署大语言模型（LLMs）

Tue, 07 Apr 2026 13:01:55 +0000

LiteRT-LM

LiteRT-LM 是 Google 的生产级、高性能、开源推理框架，用于在边缘设备上部署大语言模型（LLMs）。

🔗 产品网站

🔥 最新更新：LiteRT-LM 支持 Gemma 4

通过 LiteRT-LM，在广泛的硬件设备上部署 Gemma 4，并获得卓越性能（博客）。

👉 可通过 LiteRT-LM CLI 在 Linux、macOS、Windows（WSL）或 Raspberry Pi 上尝试：

litert-lm run  \
   --from-huggingface-repo=litert-community/gemma-4-E2B-it-litert-lm \
   gemma-4-E2B-it.litertlm \
   --prompt="What is the capital of France?"

🌟 核心特性

📱 跨平台支持：Android、iOS、Web、桌面端以及 IoT（例如 Raspberry Pi）。
🚀 硬件加速：通过 GPU 和 NPU 加速器实现峰值性能。
👁️ 多模态：支持视觉与音频输入。
🔧 工具调用（Tool Use）：支持函数调用，用于 Agent 化工作流。
📚 广泛模型支持：支持 Gemma、Llama、Phi-4、Qwen 等模型。

![](./docs/api/kotlin/demo.gif)

🚀 已在 Google 产品中达到生产可用

LiteRT-LM 为以下设备上的端侧生成式 AI 提供支持：

Google Chrome
Chromebook Plus
Pixel Watch
以及更多设备

您也可以使用 Google AI Edge Gallery 应用，在您的设备上立即运行模型。

安装应用

立即从 Google Play 安装应用	立即从 App Store 安装应用

📰 博客与公告

链接	描述
Bring state-of-the-art agentic skills to the edge with Gemma 4	使用 LiteRT-LM 在应用内及更广泛设备上部署 Gemma 4，实现卓越性能与广泛覆盖。
On-device GenAI in Chrome, Chromebook Plus and Pixel Watch	使用 LiteRT-LM 在可穿戴设备和浏览器平台上大规模部署语言模型。
On-device Function Calling in Google AI Edge Gallery	探索如何微调 FunctionGemma，并通过 LiteRT-LM Tool Use API 实现函数调用能力。
Google AI Edge small language models, multimodality, and function calling	关于边缘语言模型的 RAG、多模态与函数调用的最新洞察。

🏃 快速开始

🔗 关键链接

👉 技术概览，包括性能基准、模型支持等信息
👉 LiteRT-LM CLI 指南，包括安装、入门与高级用法

⚡ 快速体验（无需代码）

使用 uv 在终端中立即体验 LiteRT-LM，无需编写任何代码：

uv tool install litert-lm

litert-lm run \
  --from-huggingface-repo=google/gemma-3n-E2B-it-litert-lm \
  gemma-3n-E2B-it-int4 \
  --prompt="What is the capital of France?"

📚 支持的语言 API

准备开始了吗？查看不同语言的指南与配置说明：

语言	状态	适用场景	文档
Kotlin	✅ 稳定	Android 应用 & JVM	Android (Kotlin) Guide
Python	✅ 稳定	原型开发与脚本	Python Guide
C++	✅ 稳定	高性能原生开发	C++ Guide
Swift	🚀 开发中	原生 iOS & macOS	（即将推出）

🏗️ 从源码构建

该指南展示了如何从源码编译 LiteRT-LM。如果您希望从源码构建程序，应检出稳定版本标签：

📦 发布版本

v0.10.1：支持部署 Gemma 4（具备卓越性能），并引入 LiteRT-LM CLI
v0.9.0：增强函数调用能力，提高应用性能稳定性
v0.8.0：支持桌面 GPU 与多模态
v0.7.0：为 Gemma 模型提供 NPU 加速

完整版本列表请参见： GitHub Releases

参考资料

LiteRT-LM
参考资料

system_prompts_leaks 是一个公开的系统提示词（System Prompts）收集仓库

Fri, 03 Apr 2026 13:01:55 +0000

📦 system_prompts_leaks（中文翻译）

🧠 项目简介

system_prompts_leaks 是一个公开的系统提示词（System Prompts）收集仓库，主要整理来自主流 AI 聊天模型的：

System Prompt（系统提示词）
System Message（系统消息）
Developer Message（开发者指令）

涵盖平台包括：

ChatGPT
Claude
Gemini 等主流大模型 ([Titan AI Explore][1])

👉 本质上，这是一个：

“AI 行为控制层（System Prompt）的反向观察与归档库”

🎯 项目目的

该仓库的目标是：

📚 构建一个 系统提示词知识库
🔍 帮助开发者理解：
- LLM 是如何被“指挥”的
- 不同 AI 的行为策略差异
🧪 支持研究：
- Prompt Engineering
- AI 行为控制机制
- 模型安全与限制设计 ([DeepWiki][2])

🧱 仓库内容结构

仓库按照不同 AI 系统进行分类，大致包括：

1️⃣ Claude 系列

claude.txt
Claude Sonnet / Opus 等版本

👉 特点：

工具调用（Tool use）
行为规范极其详细
强调安全与对齐

2️⃣ OpenAI / GPT 系列

GPT-5 personalities
GPT thinking / reasoning 模式

👉 特点：

人格（personality）设计
推理策略控制
工具使用策略

3️⃣ 专用功能模块

例如：

study / 学习模式
image safety / 图像安全
file search / 文件检索

👉 本质是：

“能力模块级 Prompt”

🧩 内容特点

✅ 1. 高度还原真实系统 Prompt

这些内容通常来自：

泄露（leak）
逆向分析
实际抓取

👉 可以理解为：

“AI 的操作系统配置文件”

✅ 2. 社区驱动

通过 Pull Request 提交新内容
持续更新
无中心化维护

👉 类似：

prompt 版的 “awesome list + leaks archive”

✅ 3. 只收集，不做解释

仓库本身：

❌ 不提供分析
❌ 不解释设计原因
✅ 只做归档

👉 需要你自己解读

⚙️ 使用场景

👨‍💻 开发者

学习如何设计：
- system prompt
- AI agent 行为规则

🧠 研究人员

分析不同模型：
- 对齐策略
- 安全机制
- 输出控制方式

🎓 教学

用作 Prompt Engineering 教材

⚠️ 风险与注意事项

1️⃣ 法律与合规问题

部分 prompt：

可能涉及平台私有配置
存在知识产权问题

👉 使用需谨慎 ([Titan AI Explore][1])

2️⃣ Prompt 泄露本身是安全问题

学术上已经明确：

System Prompt 是 LLM 的核心资产泄露会导致能力被复制或攻击 ([arXiv][3])

3️⃣ 数据不一定完整 / 准确

有些是片段
有些是推测还原

🧠 一句话总结

这是一个“AI 系统提示词的泄露与归档库”，本质是在拆解大模型的“行为控制层”。

🔥 架构级解读（重点）

结合你的背景（你在做 AI + 系统架构），这个仓库真正有价值的是：

1️⃣ System Prompt = “软操作系统”

可以把 LLM 分成三层：

模型（权重）
   ↓
System Prompt（行为控制层）
   ↓
User Prompt（输入）

👉 system prompt 本质是：

行为约束
能力开关
工具编排规则

2️⃣ 不同公司本质在做同一件事

你会发现：

公司	本质
OpenAI	人格 + 工具
Anthropic	安全 + 规范
Google	多模态 +工具

👉 差异其实在：

system prompt 设计哲学

3️⃣ 对你（做 IM + AI 平台）最关键的价值

你可以直接借鉴：

✅ AI Agent 设计

tool calling 规则
memory 结构
persona 控制

✅ 商业化能力

不同用户 → 不同 prompt
不同场景 → 不同 agent

👉 本质：

prompt = 产品逻辑

4️⃣ 更深一层（非常关键）

这个仓库揭示了一个核心事实：

大模型的“产品差异”，很大一部分来自 Prompt，而不是模型本身

参考资料

📦 system_prompts_leaks（中文翻译）
🔥 架构级解读（重点）
参考资料

dom4j = Java 里一个偏“工程实用”的 XML 处理库

Fri, 03 Apr 2026 13:01:55 +0000

我按你前面要 dom4j 的方式，把 JDOM 官方入门 + Maven + 核心用法整理成一份“工程可直接用”的版本。

一、JDOM 是什么（快速定位）

JDOM = 更“Java风格”的 XML 操作库

设计目标：

比原生 DOM 更简单
API 更符合 Java 习惯（List / Iterator）
面向开发者体验（不是标准规范驱动）

👉 一句话：

JDOM = “写起来最顺手的 XML API 之一”

二、Maven 引入（推荐）

✅ JDOM 2.x（必须用这个）

<dependency>
    <groupId>org.jdom</groupId>
    <artifactId>jdom2</artifactId>
    <version>2.0.6.1</version>
</dependency>

👉 注意：

老版本 jdom（1.x）基本不用了
一定用 jdom2

三、最小入门示例（官方核心）

1️⃣ 解析 XML

import org.jdom2.Document;
import org.jdom2.input.SAXBuilder;

SAXBuilder builder = new SAXBuilder();
Document document = builder.build(new File("test.xml"));

👉 类似：

dom4j → SAXReader
JDOM → SAXBuilder

2️⃣ 获取根节点

Element root = document.getRootElement();

3️⃣ 读取子节点

List<Element> users = root.getChildren("user");

for (Element user : users) {
    String name = user.getChildText("name");
    System.out.println(name);
}

👉 比 dom4j 更“Java直觉”的 API：

getChildText()（很舒服）

4️⃣ 获取属性

String id = user.getAttributeValue("id");

四、创建 XML（核心用法）

import org.jdom2.Document;
import org.jdom2.Element;

Element root = new Element("users");
Document document = new Document(root);

Element user = new Element("user");
user.setAttribute("id", "1");

user.addContent(new Element("name").setText("echo"));

root.addContent(user);

五、输出 XML

import org.jdom2.output.XMLOutputter;
import org.jdom2.output.Format;

XMLOutputter outputter = new XMLOutputter(Format.getPrettyFormat());
outputter.output(document, System.out);

输出：

<users>
  <user id="1">
    <name>echo</name>
  </user>
</users>

六、XPath（JDOM 2 支持）

import org.jdom2.xpath.XPathFactory;
import org.jdom2.xpath.XPathExpression;

XPathFactory factory = XPathFactory.instance();

XPathExpression<Element> expr =
    factory.compile("//user/name", Filters.element());

List<Element> result = expr.evaluate(document);

for (Element e : result) {
    System.out.println(e.getText());
}

👉 注意：

JDOM 的 XPath 比 dom4j 更规范（但稍复杂）

七、核心对象模型

Document
 └── Element
      ├── Attribute
      └── Content (Text / CDATA / Comment)

👉 和 dom4j 很像，但：

JDOM 类型更“强类型化”

八、和 dom4j 对比（重点）

维度	JDOM	dom4j
API 易用性	⭐⭐⭐⭐⭐	⭐⭐⭐⭐
XPath	⭐⭐⭐⭐	⭐⭐⭐⭐⭐
灵活性	⭐⭐⭐	⭐⭐⭐⭐⭐
Java风格	⭐⭐⭐⭐⭐	⭐⭐⭐

👉 结论：

想写代码舒服 → JDOM
想做复杂规则（XPath重）→ dom4j

九、工程建议（结合你的背景）

你现在在做：

自动化测试平台 / DSL / 规则系统

建议：

✔ 用 JDOM 的场景

XML 配置解析
简单结构转换
数据导入导出

✔ 用 dom4j 的场景

XPath规则匹配
DSL执行引擎
动态查询

十、一句话总结

JDOM = “最符合 Java 直觉的 XML 操作库”

参考资料

一、JDOM 是什么（快速定位）
二、Maven 引入（推荐）
- ✅ JDOM 2.x（必须用这个）
三、最小入门示例（官方核心）
四、创建 XML（核心用法）
五、输出 XML
六、XPath（JDOM 2 支持）
七、核心对象模型
八、和 dom4j 对比（重点）
九、工程建议（结合你的背景）
- ✔ 用 JDOM 的场景
- ✔ 用 dom4j 的场景
十、一句话总结
参考资料

dom4j = Java 里一个偏“工程实用”的 XML 处理库

Fri, 03 Apr 2026 13:01:55 +0000

XStream 是一个非常易用的 Java 对象与 XML 相互转换的库，其核心用法非常简单，主要涉及 toXML() 和 fromXML() 两个方法[reference:0]。

📦 第一步：添加Maven依赖

在你的 pom.xml 文件中添加 XStream 的核心依赖。

<dependency>
    <groupId>com.thoughtworks.xstream</groupId>
    <artifactId>xstream</artifactId>
    <version>1.4.21</version>
</dependency>

当前最新稳定版本是 1.4.21[reference:1]。如果不使用 Maven，也可以直接从官网下载 JAR 包并添加到项目的 classpath 中。

🚀 第二步：基础使用

下面的例子展示了将一个简单的 Person 对象序列化成 XML，再反序列化回来的完整过程。

1. 定义Java类

首先，定义两个普通的 Java 类（POJO）。XStream 不要求类必须有 getter/setter 或无参构造器，对私有字段也能直接操作[reference:2]。

import java.util.List;

public class Person {
    private String firstName;
    private String lastName;
    private List<PhoneNumber> phoneNumbers;
    
    // 为了代码简洁，此处省略了构造器、getter和setter方法
}

public class PhoneNumber {
    private int code;
    private String number;
    
    // 为了代码简洁，此处省略了构造器、getter和setter方法
}

2. 序列化与反序列化

XStream 类是主要入口。核心用法就是创建 XStream 实例，然后调用其 toXML() 和 fromXML() 方法[reference:3]。

import com.thoughtworks.xstream.XStream;
import java.util.Arrays;

public class XStreamDemo {
    public static void main(String[] args) {
        // 创建XStream实例
        XStream xstream = new XStream();

        // --- 序列化：将Java对象转换为XML ---
        Person person = new Person("John", "Doe");
        person.setPhoneNumbers(Arrays.asList(new PhoneNumber(123, "12345678")));
        
        String xml = xstream.toXML(person);
        System.out.println("生成的XML:\n" + xml);
        // 生成的XML默认会使用类的全限定名作为根标签
        // <com.example.Person>...</com.example.Person>

        // --- 反序列化：将XML转换回Java对象 ---
        Person deserializedPerson = (Person) xstream.fromXML(xml);
        System.out.println("反序列化后的对象: " + deserializedPerson.getFirstName());
    }
}

生成的 XML 默认会使用类的全限定名（如 <com.example.Person>），这虽然能工作，但不够简洁。为了解决这个问题，可以使用”别名”。

⚙️ 第三步：进阶配置

1. 使用别名 (Alias)

别名可以让你自定义 XML 中的元素名，使 XML 更简洁、可读性更高[reference:4]。

为类起别名：使用 alias(String name, Class type) 方法[reference:5]。
为字段起别名：使用 aliasField(String alias, Class definedIn, String fieldName) 方法[reference:6]。

// 在创建XStream实例后添加别名配置
XStream xstream = new XStream();
// 为Person类起别名为"person"
xstream.alias("person", Person.class);
// 为PhoneNumber类起别名为"phoneNumber"
xstream.alias("phoneNumber", PhoneNumber.class);
// 为Person类的firstName字段起别名为"firstNameAlias"
xstream.aliasField("firstNameAlias", Person.class, "firstName");

2. 使用注解 (Annotation)

如果不想在代码中显式配置，可以使用注解，让代码更简洁[reference:7]。

启用注解：需要调用 processAnnotations(Class... types) 方法。
常用注解：
- @XStreamAlias("alias")：用于类或字段，定义别名[reference:8]。
- @XStreamAsAttribute：用于字段，将该字段序列化为 XML 元素的属性，而非子元素[reference:9]。
- @XStreamOmitField：用于字段，让 XStream 忽略该字段[reference:10]。

import com.thoughtworks.xstream.annotations.XStreamAlias;
import com.thoughtworks.xstream.annotations.XStreamAsAttribute;

@XStreamAlias("person")  // 类的别名
public class Person {
    @XStreamAlias("firstNameAlias")  // 字段的别名
    private String firstName;
    
    @XStreamAsAttribute  // 将lastName序列化为<person lastName="...">
    private String lastName;
}

// 在代码中处理注解
XStream xstream = new XStream();
// 让XStream处理Person类上的注解
xstream.processAnnotations(Person.class);

需要注意的是，processAnnotations 方法有轻微的线程安全问题，建议在应用启动时单线程执行[reference:11]。

🛡️ 第四步：安全配置

从 1.4.x 版本开始，XStream 引入了安全框架。在处理来自外部的、不可信的 XML 数据时，进行安全配置是必须的，这可以有效防止反序列化漏洞[reference:12]。

通常的做法是设置类型白名单，明确告知 XStream 哪些类可以被反序列化[reference:13]。

XStream xstream = new XStream();
// 1. 设置一个默认的安全配置，限制一些危险的操作
XStream.setupDefaultSecurity(xstream);
// 2. 明确允许需要反序列化的类，可以使用通配符
xstream.allowTypesByWildcard(new String[]{
        "com.yourproject.model.**",  // 允许model包及其子包下的所有类
        "java.util.**"               // 允许java.util包下的类，如ArrayList
});

此外，始终使用最新版本的 XStream 库也非常重要[reference:14]。对于简单的 JSON 处理场景，如果涉及外部数据，也推荐参考官方最新的安全指南进行配置。

🎨 第五步：拓展：支持JSON

除了 XML，XStream 也支持将对象与 JSON 互相转换[reference:15]。

import com.thoughtworks.xstream.XStream;
import com.thoughtworks.xstream.io.json.JsonHierarchicalStreamDriver;

// 1. 使用特定的JSON驱动创建XStream实例
XStream xstream = new XStream(new JsonHierarchicalStreamDriver());

// 2. 设置别名（可选，能让生成的JSON更简洁）
xstream.alias("person", Person.class);

// 3. 序列化为JSON
Person person = new Person("John", "Doe");
String json = xstream.toXML(person); // 注意方法名仍是toXML
System.out.println(json);
// 输出示例: {"person": {"firstName": "John", "lastName": "Doe"}}

这个 JsonHierarchicalStreamDriver 只能用于序列化。如果需要双向转换，可以使用 JettisonMappedXmlDriver，但它需要额外添加 jettison 依赖[reference:16]。

💡 常见问题与提醒

JVM Crash 问题：在某些 JDK 版本（如 JDK 8u202 及更早版本）中使用 XStream 处理 XML 时，可能会触发 SUN.security.validator.ValidatorException 导致 JVM 崩溃。这通常与 Xalan XSLT 处理器有关。建议将 JDK 升级到较新的版本，或在 JVM 启动参数中添加 -Dcom.sun.org.apache.xml.internal.security.ignoreLineBreaks=true 来规避。
依赖冲突：XStream 依赖 XPP3 作为默认的 XML 解析器[reference:17]。如果你的项目中存在其他 XML 解析库，可能会引发版本冲突。此时，可以切换为使用标准的 JAXP DOM 解析器：XStream xstream = new XStream(new DomDriver())[reference:18]。

如果需要更深入的信息，推荐查阅 XStream 官方网站或 Baeldung 上的系列教程。

参考资料

📦 第一步：添加Maven依赖
🚀 第二步：基础使用
- 1. 定义Java类
- 2. 序列化与反序列化
⚙️ 第三步：进阶配置
- 1. 使用别名 (Alias)
- 2. 使用注解 (Annotation)
🛡️ 第四步：安全配置
🎨 第五步：拓展：支持JSON
💡 常见问题与提醒
参考资料

dom4j = Java 里一个偏“工程实用”的 XML 处理库

Fri, 03 Apr 2026 13:01:55 +0000

一、dom4j 是什么（快速理解）

dom4j = Java 里一个偏“工程实用”的 XML 处理库

核心特点：

支持 DOM + SAX + XPath + JAXP
基于 Java 集合（比原生 DOM 更好用）
API 更灵活，适合复杂 XML 操作 ([GitHub][1])

👉 简单对比：

原生 DOM：啰嗦
SAX：流式但难写
dom4j：可读性 + 灵活性平衡

二、Maven 引入（最关键）

✅ 推荐使用最新版（当前主流）

<dependency>
    <groupId>org.dom4j</groupId>
    <artifactId>dom4j</artifactId>
    <version>2.2.0</version>
</dependency>

([Maven Central][2])

⚠️ 可选依赖（很多人踩坑点）

dom4j 不再自动引入一些依赖，比如 XPath 支持：

<dependency>
    <groupId>jaxen</groupId>
    <artifactId>jaxen</artifactId>
    <version>1.2.0</version>
</dependency>

👉 否则：

selectNodes() / XPath 可能报错

官方说明：部分依赖是 optional，需要手动引入 ([GitHub][1])

三、官方入门（核心 API）

1️⃣ 解析 XML（最基础）

import org.dom4j.Document;
import org.dom4j.io.SAXReader;

SAXReader reader = new SAXReader();
Document document = reader.read(new File("test.xml"));

👉 本质：

SAXReader → 解析器
Document → 整个 XML 树

([dom4j][3])

2️⃣ 获取节点

Element root = document.getRootElement();

3️⃣ 遍历子节点

List<Element> elements = root.elements("user");

for (Element e : elements) {
    System.out.println(e.elementText("name"));
}

4️⃣ XPath（核心能力）

List<Node> nodes = document.selectNodes("//user/name");

for (Node node : nodes) {
    System.out.println(node.getText());
}

👉 这个是 dom4j 最大优势之一（比 DOM 强很多）

5️⃣ 创建 XML

Document document = DocumentHelper.createDocument();
Element root = document.addElement("users");

Element user = root.addElement("user");
user.addElement("name").setText("echo");

6️⃣ 写出 XML

XMLWriter writer = new XMLWriter(new FileWriter("out.xml"));
writer.write(document);
writer.close();

四、核心对象模型（必须搞清楚）

这是 dom4j 的核心抽象：

Document
 └── Element
      ├── Attribute
      └── Text

重点理解：

类型	作用
Document	整个 XML
Element	标签
Attribute	属性
Node	XPath 结果统一接口

五、常见使用模式（工程视角）

✔ 场景1：配置文件解析

读取 XML → 转对象

✔ 场景2：日志/数据转换

XML → JSON / DTO

✔ 场景3：规则引擎（你这种架构会用到）

XPath 做规则匹配

👉 dom4j 在“规则/DSL类系统”里特别常见

六、优缺点（架构师视角）

👍 优点

XPath 强（比 JDK 自带好用）
API 简洁
灵活性高

👎 缺点

不是流式（大 XML 内存压力）
社区活跃度一般
不如 Jackson / JAXB 现代

七、和现代方案对比（关键）

方案	推荐度	说明
dom4j	⭐⭐⭐	老牌稳定
JAXB	⭐⭐⭐⭐	Java 标准绑定
Jackson XML	⭐⭐⭐⭐⭐	现代主流

👉 如果你是做平台 / AI / DSL：

dom4j 仍然很适合做解析层

八、一句话总结

dom4j = “工程友好的 XML 操作库 + 强 XPath 支持”

参考资料

一、dom4j 是什么（快速理解）
二、Maven 引入（最关键）
- ✅ 推荐使用最新版（当前主流）
- ⚠️ 可选依赖（很多人踩坑点）
三、官方入门（核心 API）
四、核心对象模型（必须搞清楚）
五、常见使用模式（工程视角）
六、优缺点（架构师视角）
- 👍 优点
- 👎 缺点
七、和现代方案对比（关键）
八、一句话总结
参考资料

flexmark-java 是一个基于 CommonMark 的 Java 实现，采用“先解析块（blocks），再解析行内（inlines）”的 Markdown 解析架构。

Fri, 03 Apr 2026 13:01:55 +0000

flexmark-java

flexmark-java 是一个基于 [CommonMark（规范 0.28）] 的 Java 实现，采用“先解析块（blocks），再解析行内（inlines）”的 Markdown 解析架构。

其优势在于：速度快、灵活性高、基于 Markdown 源元素的 AST（抽象语法树），并且提供精确到组成元素词法单元（lexeme）中每个字符的源码位置信息，同时具有良好的可扩展性。

该 API 提供对解析过程的细粒度控制，并针对安装大量扩展的场景进行了优化。解析器和扩展提供了大量用于控制解析行为和 HTML 渲染方式的选项。最终目标是让解析器和渲染器能够高度精确地模拟其他 Markdown 解析器的行为。目前这一目标已通过实现 Markdown 处理器模拟（Markdown Processor Emulation）部分达成。

该项目的动机是替换我在 JetBrains IDE 的 [Markdown Navigator] 插件中使用的 [pegdown] 解析器。[pegdown] 功能丰富，但整体性能不理想，并且在病态输入（pathological input）情况下可能卡死或几乎卡死。

:warning: 版本 0.60.0 由于实现类的重构、重命名、清理和优化，包含破坏性变更。详见 Version-0.60.0-Changes

要求

对于 0.62.2 及以下版本：需要 Java 8 及以上（兼容 Java 9+）
对于 0.64.0 及以上版本：需要 Java 11 及以上
项目 Maven 坐标：com.vladsch.flexmark
核心模块仅依赖 org.jetbrains:annotations:24.0.1，扩展依赖见下文说明

API 仍在持续演进，以支持新的扩展和功能。

快速开始

Maven 依赖

推荐引入包含核心和所有模块的 flexmark-all：

<dependency>
    <groupId>com.vladsch.flexmark</groupId>
    <artifactId>flexmark-all</artifactId>
    <version>0.64.8</version>
</dependency>

示例代码来源：BasicSample.java

package com.vladsch.flexmark.samples;

import com.vladsch.flexmark.util.ast.Node;
import com.vladsch.flexmark.html.HtmlRenderer;
import com.vladsch.flexmark.parser.Parser;
import com.vladsch.flexmark.util.data.MutableDataSet;

public class BasicSample {
    public static void main(String[] args) {
        MutableDataSet options = new MutableDataSet();

        // 可选：启用扩展
        //options.set(Parser.EXTENSIONS, Arrays.asList(TablesExtension.create(), StrikethroughExtension.create()));

        // 可选：将软换行转为硬换行
        //options.set(HtmlRenderer.SOFT_BREAK, "<br />\n");

        Parser parser = Parser.builder(options).build();
        HtmlRenderer renderer = HtmlRenderer.builder(options).build();

        // parser 和 renderer 可复用
        Node document = parser.parse("This is *Sparta*");
        String html = renderer.render(document);  // "<p>This is <em>Sparta</em></p>\n"
        System.out.println(html);
    }
}

Gradle 构建

implementation 'com.vladsch.flexmark:flexmark-all:0.64.8'

Android Studio 构建

由于存在重复文件，需要额外配置：

packagingOptions {
    exclude 'META-INF/LICENSE-LGPL-2.1.txt'
    exclude 'META-INF/LICENSE-LGPL-3.txt'
    exclude 'META-INF/LICENSE-W3C-TEST'
    exclude 'META-INF/DEPENDENCIES'
}

更多信息参见文档： Wiki 首页 / 使用示例 / 扩展说明 / 扩展开发

Pegdown 迁移辅助

PegdownOptionsAdapter 可将 pegdown 的 Extensions.* 标志转换为 flexmark 的配置和扩展列表。

使用方式：

final private static DataHolder OPTIONS =
    PegdownOptionsAdapter.flexmarkOptions(Extensions.ALL);

或启用严格 HTML 解析：

PegdownOptionsAdapter.flexmarkOptions(true, Extensions.ALL);

说明：默认的 flexmark pegdown 模拟对 HTML 块的解析较宽松，而 pegdown 仅在标签全部闭合时才中断 HTML 块。

扩展机制说明

API 提供大量扩展点。一般原则：

简单扩展应只需几十行代码
如果实现复杂，可能使用方式不正确或 API 需增强
大多数扩展代码量较小（约几十行）
较大扩展约 200 行（如 tables）

如果无法实现，建议直接提 issue。

Markdown 处理器模拟

CommonMark 并不是其他 Markdown 方言的超集或子集，而是定义了一个标准语法。

flexmark 默认兼容 CommonMark，但可以通过 ParserEmulationProfile 模拟其他解析器：

支持：

CommonMark（0.27 / 0.28）
Markdown.pl
Kramdown
MultiMarkdown
Pegdown
GitHub Markdown（部分）

注意：仅调整解析行为，不会自动增加额外特性，需要手动启用对应扩展。

历史与动机

flexmark-java 是 [commonmark-java] 的一个分支，主要增强：

AST 完整反映源文本结构
完整源码位置跟踪
更适合 JetBrains PSI 构建

选择 commonmark-java 的原因：

高性能
易理解
易扩展

目标：

支持任意 Markdown 方言扩展
提供统一配置 API
支持禁用核心解析器

当前仍在持续演进，不保证向后兼容。

功能对比

特性	flexmark-java	commonmark-java	pegdown
解析性能	✔	✔（更快）	✘
AST 完整性	✔	✘	✔
AST 源位置	✔	✔	✔（不稳定）
AST 可修改	✔	✔	✘
可禁用核心解析	✔	✘	✘
扩展能力	✔	一般	较弱
配置统一性	✔	✘	✘

进展（部分）

排版（引号、智能符号）
GitHub 扩展（表格、任务列表等）
发布功能（脚注、目录等）
HTML 抑制控制
Jekyll 支持
列表解析优化

基准测试

总体性能（相对 flexmark）：

实现	性能
commonmark-java	0.71x（更快）
flexmark-java	1.00x
intellij-markdown	12.41x
pegdown	28.48x

在病态输入下：

flexmark：稳定
pegdown：指数级退化甚至卡死

贡献

欢迎 PR / Issue / 评论：

要求：

添加测试
遵循代码风格（4 空格缩进等）

许可证

BSD 2-Clause License（见 LICENSE.txt）

参考资料

flexmark-java
参考资料

commonmark-java 一个 Java 库，用于根据 Markdown 和 CommonMark 规范（以及部分扩展）解析和渲染 Markdown 文本。

Fri, 03 Apr 2026 13:01:55 +0000

commonmark-java

一个 Java 库，用于根据 Markdown 和 CommonMark 规范（以及部分扩展）解析和渲染 Markdown 文本。

介绍

提供用于将输入解析为抽象语法树（AST）、访问和操作节点，以及渲染为 HTML 或重新转换为 Markdown 的类。该项目最初是 commonmark.js 的移植版本，但后来演化为一个可扩展的库，具有以下特性：

轻量（核心无依赖，扩展在独立 artifact 中）
高性能（比曾经流行的 Markdown 库 pegdown 快 10–20 倍，详见仓库中的基准测试）
灵活（可在解析后操作 AST，自定义 HTML 渲染）
可扩展（支持表格、删除线、自动链接等，详见下文）

该库支持 Java 11 及以上版本。也可运行在 Android 上，但仅提供尽力支持，请反馈问题。 Android 最低 API 等级为 19，参见 commonmark-android-test 目录。

核心库的 Maven 坐标（完整列表见 Maven Central）：

<dependency>
    <groupId>org.commonmark</groupId>
    <artifactId>commonmark</artifactId>
    <version>0.28.0</version>
</dependency>

在 Java 9 中使用的模块名为 org.commonmark、org.commonmark.ext.autolink 等，对应包名。

注意：该库在 0.x 版本阶段 API 尚未稳定，可能在次版本之间发生破坏性变更。 1.0 之后将遵循 Semantic Versioning。包含 beta 的包表示 API 尚未稳定，但一般使用场景下不需要依赖。

如果你想了解当前实现的规范版本，请查看 spec.txt 文件。也可以使用 CommonMark Dingus 来熟悉语法或测试边界情况。克隆仓库后，还可以使用 DingusApp 类进行交互式测试。

使用

解析并渲染为 HTML

import org.commonmark.node.*;
import org.commonmark.parser.Parser;
import org.commonmark.renderer.html.HtmlRenderer;

Parser parser = Parser.builder().build();
Node document = parser.parse("This is *Markdown*");
HtmlRenderer renderer = HtmlRenderer.builder().build();
renderer.render(document);  // "<p>This is <em>Markdown</em></p>\n"

上述示例使用默认配置。构建器提供了多种配置方法：

escapeHtml(true)：转义原始 HTML 标签和块
sanitizeUrls(true)：移除 <a> 和 <img> 中潜在不安全的 URL
更多选项见构建器方法

注意：该库不会对输出 HTML 的标签安全性进行过滤（如允许哪些标签）。这属于调用方责任，如果对外暴露 HTML，建议后续进行安全过滤。

渲染为 Markdown

import org.commonmark.node.*;
import org.commonmark.renderer.markdown.MarkdownRenderer;

MarkdownRenderer renderer = MarkdownRenderer.builder().build();
Node document = new Document();
Heading heading = new Heading();
heading.setLevel(2);
heading.appendChild(new Text("My title"));
document.appendChild(heading);

renderer.render(document);  // "## My title\n"

如果需要渲染为尽量少标记的纯文本，可使用 TextContentRenderer。

使用 Visitor 处理节点

解析后的结果是一个节点树，可以在渲染前修改，或仅进行分析：

Node node = parser.parse("Example\n=======\n\nSome more text");
WordCountVisitor visitor = new WordCountVisitor();
node.accept(visitor);
visitor.wordCount;  // 4

class WordCountVisitor extends AbstractVisitor {
    int wordCount = 0;

    @Override
    public void visit(Text text) {
        // 对所有 Text 节点调用
        wordCount += text.getLiteral().split("\\W+").length;
        visitChildren(text);
    }
}

源码位置（Source positions）

如果需要知道节点在源文本中的位置：

var parser = Parser.builder()
    .includeSourceSpans(IncludeSourceSpans.BLOCKS_AND_INLINES)
    .build();

解析并查看：

var source = "foo\n\nbar *baz*";
var doc = parser.parse(source);
var emphasis = doc.getLastChild().getLastChild();
var s = emphasis.getSourceSpans().get(0);

s.getLineIndex();    // 行号
s.getColumnIndex();  // 列号
s.getInputIndex();   // 字符索引
s.getLength();       // 长度

修改 HTML 元素属性

示例：为 img 标签添加 class="border"：

HtmlRenderer renderer = HtmlRenderer.builder()
    .attributeProviderFactory(context -> new ImageAttributeProvider())
    .build();

自定义 HTML 渲染

可完全控制节点如何渲染，例如修改代码块输出方式。

（示例代码略，逻辑：自定义 NodeRenderer）

自定义节点类型

可继承 CustomNode 创建自定义节点，并通过 NodeRenderer 控制其 HTML 渲染。

自定义解析

通过 Parser.Builder 扩展或覆盖解析逻辑：

启用/禁用块类型：enabledBlockTypes
自定义块解析：customBlockParserFactory
自定义行内解析：customInlineContentParserFactory
自定义分隔符处理：customDelimiterProcessor
自定义链接处理：linkProcessor、linkMarker

线程安全

Parser 和 HtmlRenderer 支持多线程复用：配置与运行时状态分离。

如发现问题，请提交 issue。

API 文档

在线 Javadoc： https://www.javadoc.io/doc/org.commonmark/commonmark

扩展

扩展通过增强解析器或渲染器实现，需要额外依赖。

示例：启用 GFM 表格：

<dependency>
    <groupId>org.commonmark</groupId>
    <artifactId>commonmark-ext-gfm-tables</artifactId>
    <version>0.28.0</version>
</dependency>

List<Extension> extensions = List.of(TablesExtension.create());
Parser parser = Parser.builder().extensions(extensions).build();
HtmlRenderer renderer = HtmlRenderer.builder().extensions(extensions).build();

内置扩展

Autolink

自动将 URL、邮箱转换为链接（artifact：commonmark-ext-autolink）

删除线（Strikethrough）

使用 ~~text~~

表格（Tables）

支持 GitHub 风格表格

Alerts

支持 GitHub 风格提示块（NOTE、TIP 等）

脚注（Footnotes）

支持 GitHub / Pandoc 风格脚注

标题锚点（Heading anchor）

自动生成标题 id

下划线（Ins）

使用 ++text++

YAML Front Matter

支持 YAML 元数据头

图片属性（Image Attributes）

支持宽高等属性

任务列表（Task List Items）

支持 [ ] / [x] 任务列表

第三方扩展

commonmark-ext-notifications：支持通知块（INFO、WARNING 等）

使用该库的项目

Atlassian（库最初开发地）
OpenJDK
Gerrit / Gitiles
Clerk
Znai
Open Note（Android Markdown 应用）
Quarkus Roq
Lucee
Previewer（Eclipse 插件）
Xeres（P2P Markdown 应用）

贡献

参见 CONTRIBUTING.md

许可证

参考资料

commonmark-java
参考资料

OpenScreen 是一个免费、开源的屏幕录制工具，可作为 Screen Studio 的替代方案（某种程度上）

Fri, 03 Apr 2026 13:01:55 +0000

OpenScreen

⚠️ 注意

该项目目前仍处于 Beta 阶段，可能存在一些 bug，但希望你能获得不错的体验。

OpenScreen

OpenScreen 是一个免费、开源的屏幕录制工具，可作为 Screen Studio 的替代方案（某种程度上）。 ([Awesome Lists][1])

如果你不想为 Screen Studio 每月支付 $29，但又希望拥有一个简单易用、能制作精美演示视频的工具，那么这个项目就是为你准备的。

❌ 不是 1:1 完全替代 Screen Studio
✅ 更轻量、更简单
✅ 覆盖大多数常见需求
✅ 完全免费、无套路

如果你需要非常高级的功能，建议支持 Screen Studio（它确实很优秀）。但如果你只需要一个免费 + 开源 + 可控的工具，OpenScreen 已经足够。

🆓 许可

100% 免费（个人 / 商业均可使用）
支持修改、分发
MIT License

👉 总结：没有水印、没有订阅、没有限制 ([Awesome Lists][1])

🚀 核心功能

🎥 录制能力

录制整个屏幕或指定应用
支持导入已有视频进行编辑

🔍 缩放与镜头控制

手动添加缩放（Zoom）
自定义缩放深度
精确控制缩放的：
- 时间
- 位置
- 动画

✂️ 视频编辑

裁剪录制内容（隐藏不需要区域）
剪切片段（Trim）
调整视频片段速度（加速 / 减速）
支持时间轴编辑

🎨 视觉增强

背景支持：
- 壁纸
- 纯色
- 渐变
- 自定义图片
动态模糊（Motion Blur）
边框、间距可配置

📝 标注系统

添加：
- 文本
- 箭头
- 图片
支持自定义字体（包括 Google Fonts）

🎬 导出能力

支持多种分辨率
支持多种比例：
- 16:9
- 9:16
- 1:1 等
GIF 导出（新版本支持）
导出速度优化（新版本大幅提升）

📦 安装方式

👉 推荐方式（普通用户）

直接从 GitHub Releases 下载对应系统安装包

支持：

macOS（.dmg）
Windows（.exe）
Linux（.AppImage） ([Codakey][2])

🍎 macOS 安装注意事项

由于没有开发者签名，可能被 Gatekeeper 拦截：

执行：

xattr -rd com.apple.quarantine /Applications/Openscreen.app

然后：

打开「系统设置 > 隐私与安全」
授权：
- 屏幕录制
- 辅助功能

🐧 Linux

chmod +x Openscreen-Linux-*.AppImage
./Openscreen-Linux-*.AppImage

如果报 sandbox 错误：

./Openscreen-Linux-*.AppImage --no-sandbox

🧱 技术栈

OpenScreen 基于以下技术构建：

Electron（桌面应用）
React（UI）
TypeScript（类型系统）
Vite（构建工具）
PixiJS（图形渲染）
dnd-timeline（时间轴拖拽）

👉 本质：Electron + Canvas 渲染 + 视频处理 pipeline

🧠 架构关键点（补充理解）

根据项目结构：

frameRenderer.ts → 帧渲染（合成效果）
videoExporter.ts → 视频导出核心
streamingDecoder.ts → 视频解码
annotationRenderer.ts → 标注系统 ([Codakey][2])

👉 本质架构：

录制/导入视频
    ↓
时间轴编辑（zoom / trim / speed）
    ↓
Canvas 渲染（PixiJS）
    ↓
编码导出（WebCodecs / WASM）

⚙️ 构建方式（开发者）

git clone https://github.com/siddharthvaddem/openscreen.git
cd openscreen
npm install
npm run dev

打包：

npm run build
npm run dist

🤝 贡献

欢迎贡献代码！

可以查看：

Issues
Roadmap

项目作者表示：

“我刚开始做开源，不太懂，如果有问题欢迎提 Issue 🙏”

📜 License

MIT License

👉 使用该软件即表示：

作者不承担任何责任
风险自负

🧩 一句话总结（架构视角）

OpenScreen 本质是：

一个 基于 Electron 的本地视频录制 + 时间轴编辑 + 动效增强工具，主打“低成本制作产品演示视频”。

🔥 我帮你补一层“架构级理解”（重点）

如果你是架构师视角，这个项目核心价值在：

1️⃣ 技术点

WebCodecs / 视频编码
Canvas 实时渲染（PixiJS）
Timeline 编辑器（类似剪映）
Electron 跨平台

2️⃣ 产品定位

对标 Screen Studio
目标用户：
- 开发者
- SaaS 产品演示
- 教程制作

3️⃣ 商业模型（你可以借鉴）

当前：完全开源免费
可扩展：
- 模板市场
- AI 自动剪辑
- 云渲染

参考资料

OpenScreen
- ⚠️ 注意
OpenScreen
- 🆓 许可
🚀 核心功能
📦 安装方式
🧱 技术栈
🧠 架构关键点（补充理解）
⚙️ 构建方式（开发者）
🤝 贡献
📜 License
🧩 一句话总结（架构视角）
🔥 我帮你补一层“架构级理解”（重点）
参考资料

Meta-Harness End-to-End Optimization of Model Harnesses 通过自动优化“模型 Harness（执行框架）”，可以显著提升 LLM Agent 的性能

Fri, 03 Apr 2026 13:01:55 +0000

📦 meta-harness-tbench2-artifact（中文翻译）

🧠 项目简介

该仓库是论文：

Meta-Harness: End-to-End Optimization of Model Harnesses

的实验复现 Artifact（实验工件）。

👉 这里的 artifact 在学术语境下不是“物品”，而是：

“可复现实验的完整环境 + 代码 + 数据 +脚本”

🎯 项目目标

本项目提供：

完整实验代码
评测环境（Harness）
任务数据（TerminalBench-2）
运行与复现实验的方法

用于验证论文中的核心结论：

通过自动优化“模型 Harness（执行框架）”，可以显著提升 LLM Agent 的性能 ([arXiv][1])

🧩 什么是 Harness（关键概念）

在这个项目中：

Harness = LLM 的运行控制系统

包括：

Prompt 构造
上下文管理
工具调用逻辑
记忆与状态管理

👉 论文核心观点：

模型性能不仅取决于权重，还取决于 Harness ([arXiv][1])

🧱 项目组成

该 Artifact 通常包含以下部分：

1️⃣ Benchmark（基准任务）

TerminalBench-2（TB2）
用于评估 AI Agent 在“终端环境”的能力

👉 类似：

写代码
修 bug
执行命令
多步任务

2️⃣ Harness 系统

负责：

调度 LLM
控制执行流程
管理上下文

类似你可以理解为：

LLM Agent Runtime

3️⃣ Meta-Harness（核心创新）

论文提出：

用一个“外层 Agent”去自动搜索更好的 Harness

机制：

读取历史执行日志
分析成功 / 失败
修改 Harness 代码
重新评估

👉 本质是：

Harness = 可优化对象
Meta-Agent = 优化器

4️⃣ Execution & Logging

实验运行时会生成：

执行日志
模型输出
Prompt 内容
终端操作记录

类似于：

Agent Trace（行为轨迹）

⚙️ 运行方式（概念翻译）

一般流程：

1️⃣ 环境准备

Docker
Python 环境

2️⃣ 运行实验

类似：

run experiment / evaluate harness

3️⃣ 输出结果

包括：

任务成功率
执行轨迹
模型行为日志

📊 实验结论（论文核心）

Meta-Harness 在多个任务中表现提升：

✅ 文本分类

提升约 7.7%
使用更少上下文

✅ 数学推理

提升约 4.7%

✅ Agent 编程任务（TerminalBench-2）

超越手工设计的最佳 Harness ([arXiv][1])

🧠 一句话总结

这是一个“自动优化 LLM 运行框架（Harness）”的研究与实验复现项目。

🔥 架构级解读（重点，结合你背景）

这个项目真正有价值的不是代码，而是这几个思想：

1️⃣ LLM 系统 = 三层结构

模型（weights）
    ↓
Harness（运行框架）
    ↓
任务（Task）

👉 过去大家只优化“模型”，但这里强调：

Harness 才是决定上限的关键变量

2️⃣ Harness = “AI 操作系统”

你可以把它理解为：

组件	对应
Prompt	指令层
Memory	状态层
Tools	能力层
Planner	调度层

👉 本质：

Agent Runtime

3️⃣ Meta-Harness = 自动调参的下一阶段

传统：

人写 prompt
人调 agent

这个项目：

让 AI 自动优化 AI 系统本身

4️⃣ 对你（IM + AI 平台）直接可用的点

非常关键👇

✅ 你可以做：

不同用户 → 不同 Harness
不同场景 → 不同 Agent Runtime

✅ 甚至可以：

自动优化推荐系统 Prompt
自动优化客服 Agent

👉 本质商业价值：

“Prompt 工程 → Harness 工程 → 自动 Harness 优化”

参考资料

📦 meta-harness-tbench2-artifact（中文翻译）
🔥 架构级解读（重点，结合你背景）
参考资料

LSP（Language Server Protocol）-03-ANTLR（ANother Tool for Language Recognition）是一个语言解析器生成器（parser generator）

Fri, 03 Apr 2026 13:01:55 +0000

ANTLR

ANTLR（ANother Tool for Language Recognition）是一个语言解析器生成器（parser generator），用来把“文本 → 结构化语法树（AST/Parse Tree）”。

👉 简单说：

ANTLR = 用语法规则（Grammar）生成词法分析器 + 语法分析器的工具

一、ANTLR 是干什么的（本质定位）

它解决的是：

一段文本（代码 / DSL / 配置）
        ↓
语法解析
        ↓
结构化数据（Parse Tree / AST）

常见用途：

编译器 / 解释器
DSL（领域特定语言）
SQL / 表达式解析
配置文件解析
代码分析工具（LSP 也会用）

二、ANTLR 的核心思想（Grammar 驱动）

ANTLR 的核心是：用一套语法规则描述语言

例如：

grammar Expr;

expr: expr '+' expr
    | expr '*' expr
    | INT
    ;

INT: [0-9]+;
WS: [ \t\r\n]+ -> skip;

👉 你定义的是：

语法规则（parser rules）
词法规则（lexer rules）

三、ANTLR 会帮你生成什么？

ANTLR 会自动生成：

1️⃣ Lexer（词法分析器）

输入： "1 + 2"
输出： INT '+' INT

2️⃣ Parser（语法分析器）

输入：Token 流
输出：Parse Tree（语法树）

3️⃣ 访问 API（Visitor / Listener）

你可以：

遍历语法树
执行逻辑（解释 / 编译 / 分析）

四、ANTLR 的处理流程（完整 pipeline）

输入文本
   ↓
Lexer（分词）
   ↓
Token Stream
   ↓
Parser（语法分析）
   ↓
Parse Tree
   ↓
Visitor / Listener
   ↓
你的业务逻辑

五、Parse Tree vs AST（关键区别）

ANTLR 默认生成的是：

👉 Parse Tree（语法树）

特点：

完全保留语法细节
层级较深
冗余较多

而很多系统（比如 LSP）需要：

👉 AST（抽象语法树）

特点：

去掉无关语法节点
更适合语义分析

👉 所以常见做法是：

ANTLR Parse Tree → 自己转换为 AST → 语义分析

六、Visitor / Listener 模型（核心机制）

ANTLR 提供两种遍历方式：

1️⃣ Listener（事件驱动）

enterExpr()
exitExpr()

👉 类似：

“进入节点 / 离开节点” 的回调

2️⃣ Visitor（推荐）

visitExpr()

👉 更像：

手动控制遍历 + 返回值

✔️ 更适合：

计算表达式
构建 AST
做语义分析

七、ANTLR vs tree-sitter（你刚刚的问题延伸）

这是一个非常关键的对比👇

维度	ANTLR	tree-sitter
类型	Parser Generator	Incremental Parser
输入	Grammar	Grammar
输出	Parser + Lexer 代码	解析引擎
AST	需要自己构建	内置语法树
增量解析	❌（弱）	✔（强）
实时编辑	一般	非常适合
适用场景	编译器 / DSL	编辑器 / IDE

👉 一句话总结：

ANTLR 更适合“编译器 / DSL”
tree-sitter 更适合“编辑器实时解析”

八、ANTLR 的优势（为什么还在用）

✔️ 1. 语法表达能力强

支持：

左递归
优先级
复杂语言结构

✔️ 2. 多语言支持

可以生成：

Java
Python
Go
JavaScript
C++

✔️ 3. 成熟稳定

ANTLR 是语言工具领域的“工业级工具”。

九、ANTLR 的局限

❗1. 不适合实时编辑

不支持高效增量解析
每次基本要重新 parse

❗2. Parse Tree 太重

需要自己转 AST

❗3. 学习成本较高

Grammar 设计需要经验

十、ANTLR 在 LSP / 编译器中的位置

你可以这样理解：

ANTLR → 负责“语法层”
       ↓
AST → 语义分析
       ↓
Symbol Table / Type System
       ↓
LSP 能力（跳转 / 补全）

👉 再强调一次：

ANTLR 只是“语法解析工具”，不是完整的语言智能系统

十一、一个直观类比（帮助你建立模型）

如果把整个语言系统类比为一个公司：

角色	对应
ANTLR	前台接待（识别输入）
AST	数据结构
语义分析	业务逻辑
LSP	对外 API

十二、总结一句话

ANTLR 是一个通过 Grammar 自动生成“词法 + 语法解析器”的工具，用来把文本解析成结构化语法树，是构建编译器、DSL、代码分析工具的基础设施之一。

参考资料

ANTLR
一、ANTLR 是干什么的（本质定位）
二、ANTLR 的核心思想（Grammar 驱动）
三、ANTLR 会帮你生成什么？
四、ANTLR 的处理流程（完整 pipeline）
五、Parse Tree vs AST（关键区别）
六、Visitor / Listener 模型（核心机制）
- 1️⃣ Listener（事件驱动）
- 2️⃣ Visitor（推荐）
七、ANTLR vs tree-sitter（你刚刚的问题延伸）
八、ANTLR 的优势（为什么还在用）
九、ANTLR 的局限
十、ANTLR 在 LSP / 编译器中的位置
十一、一个直观类比（帮助你建立模型）
十二、总结一句话
参考资料

LSP（Language Server Protocol）-02-原理简单介绍

Fri, 03 Apr 2026 13:01:55 +0000

LSP

你这个理解只对了一部分，但不完整——而且关键点其实不在 tree-sitter，而在“语义模型 + 增量分析引擎”。

我帮你从“实现原理”层面拆开讲清楚。

一、结论先说清楚（避免误区）

👉 LSP 不是：

❌ 一个语法解析方案
❌ 一个 AST 标准
❌ 依赖 tree-sitter

👉 LSP 本质是通信协议：

定义“编辑器 ↔ 语言服务”的交互方式，而不是内部实现。

二、LSP Server 的核心实现模型（真正关键）

一个完整的 LSP Server，底层一般是这套 pipeline：

源码 → 词法分析 → 语法分析(AST) → 语义分析 → 索引 → 查询能力

拆开看：

1️⃣ 语法解析（AST 层）

这里才是你说的那部分：

可以用：
- tree-sitter
- ANTLR
- 编译器自带 parser（如 TS / Go）

👉 作用：

构建 AST
提供基础结构信息

⚠️ 关键点：

AST ≠ LSP 能力的核心

因为：

AST 只知道结构（语法）
不知道类型 / 作用域 / 引用关系

2️⃣ 语义分析（核心中的核心）

这一步才是 LSP 真正价值所在。

构建：

Symbol Table（符号表）
Scope（作用域）
Type System（类型系统）
Reference Graph（引用关系）

比如：

let a = 1;
a = a + 2;

AST 只能看到：

AssignmentExpression

但语义分析能知道：

a 是变量
类型是 number
第二个 a 是引用第一个 a

👉 LSP 的这些能力都依赖语义层：

功能	依赖
跳转定义	符号解析
查找引用	引用图
自动补全	类型系统
重构	语义关系

3️⃣ 索引系统（大项目关键）

LSP Server 通常维护：

文件级 AST cache
全局 symbol index

类似：

Symbol → 定义位置
Symbol → 所有引用

👉 常见优化：

增量索引
lazy loading
按需解析

4️⃣ 增量更新（性能核心）

这是 LSP 最难的地方之一。

编辑器不会每次发全量代码，而是：

didChange (incremental)

👉 Server 要做到：

局部 AST 更新（tree-sitter 很擅长这里）
局部语义更新
索引局部更新

👉 这就是为什么：

tree-sitter 很流行 👉 因为它支持：
增量 parsing
高性能 AST 更新

三、tree-sitter 在 LSP 中的真实角色

你问的关键点来了👇

✔️ tree-sitter 可以做什么？

快速构建 AST
支持增量更新
适合编辑器实时场景

❌ 但它做不了什么？

类型推导
跨文件引用
语义分析
重构能力

👉 所以：

tree-sitter = “语法层引擎”，不是“语言智能引擎”

四、不同语言 Server 的实现差异（非常重要）

1️⃣ 编译器驱动型（最强）

例如：

TypeScript Language Server
gopls

👉 直接复用：

编译器 AST
类型系统
语义分析

✔️ 优点：

精确
功能强

❗缺点：

重
启动慢

2️⃣ tree-sitter + 自研语义层

常见于：

编辑器插件
轻量语言支持

👉 架构：

tree-sitter → AST → 自建 symbol / scope / index

✔️ 优点：

轻量
快

❗缺点：

很难做强语义

3️⃣ 静态分析工具驱动

例如：

pyright

👉 本质是：

一个完整的 type checker
外加 LSP 接口

五、LSP 能力是怎么实现的（具体机制）

举几个关键能力：

🔍 跳转定义（definition）

流程：

光标位置 → AST node → symbol → symbol table → 定义位置

🔎 查找引用（references）

symbol → index → 所有引用位置

✨ 自动补全（completion）

上下文 → AST → scope → 可见 symbol → 类型过滤 → 排序

🛠️ 重命名（rename）

symbol → 所有引用 → 批量编辑

六、你可以这样理解整个系统（架构抽象）

LSP Server ≈：

                ┌───────────────┐
                │   LSP 接口层   │  ← JSON-RPC
                └───────────────┘
                         ↓
                ┌───────────────┐
                │  语义查询引擎  │  ← definition / completion
                └───────────────┘
                         ↓
        ┌────────────────────────────┐
        │   AST + Symbol + Index     │
        └────────────────────────────┘
                         ↓
                ┌───────────────┐
                │  Parser 层     │ ← tree-sitter / compiler
                └───────────────┘

七、核心总结（非常关键）

👉 回答你的原问题：

LSP 是通过 tree-sitter 构建 AST 吗？

✔️ 更准确的说法是：

LSP Server 通常会用 AST（可能来自 tree-sitter），但真正核心是“语义分析 + 索引系统 + 增量更新机制”

👉 一句话总结：

AST 是基础，语义是核心，索引是规模化能力，增量更新是性能关键，LSP 只是接口层。

八、给你一个架构建议（结合你背景）

你是做：

自动化测试平台 + AI + 代码分析

👉 如果你要做类似 LSP 的能力：

我建议：

最优路线

tree-sitter（解析） 
  + 自建 symbol / scope
  + graph DB（你已经在用）
  + embedding（语义搜索）

👉 你可以做到：

代码结构理解（AST）
语义关系（graph）
模糊搜索（AI）

这其实已经是：

LSP + Code Intelligence + AI 的融合架构

参考资料

LSP
一、结论先说清楚（避免误区）
二、LSP Server 的核心实现模型（真正关键）
三、tree-sitter 在 LSP 中的真实角色
- ✔️ tree-sitter 可以做什么？
- ❌ 但它做不了什么？
四、不同语言 Server 的实现差异（非常重要）
五、LSP 能力是怎么实现的（具体机制）
六、你可以这样理解整个系统（架构抽象）
七、核心总结（非常关键）
八、给你一个架构建议（结合你背景）
- 最优路线
参考资料

LSP（Language Server Protocol）

Fri, 03 Apr 2026 13:01:55 +0000

LSP

LSP（Language Server Protocol）本质上是一个IDE 与编程语言工具链解耦的通信协议。

它由 Microsoft 提出，目标是：把“语言智能能力”从编辑器中抽离出来，变成一个独立服务。

你可以把它理解为一个标准化的“编程语言智能 API”。

一、为什么会有 LSP（核心痛点）

在 LSP 出现之前：

每个编辑器（VS Code、Vim、IntelliJ…）
每种语言（Java、Go、Python…）

都要分别实现一套智能功能：

功能	每个 IDE 都要自己实现
自动补全	✔
跳转定义	✔
语法检查	✔
重构	✔

👉 结果就是：

重复开发（N × M 问题）
语言支持质量不一致
新语言很难生态化

二、LSP 的核心思想（架构解耦）

LSP 把系统拆成两个角色：

1️⃣ Client（客户端）

通常是编辑器：

Visual Studio Code
Vim
Neovim
Emacs

👉 负责：

UI 展示
用户输入
调用协议

2️⃣ Server（语言服务器）

针对某种语言实现：

TypeScript Language Server
gopls
pyright
jdtls

👉 负责：

语法分析
AST 构建
类型检查
代码智能

🔁 通信方式

Client 和 Server 通过：

JSON-RPC over stdio / TCP / WebSocket

进行通信。

三、LSP 的工作流程（实际交互）

一个典型过程：

1️⃣ 初始化

initialize

客户端告诉服务端：

支持哪些能力
工作区路径

2️⃣ 打开文件

textDocument/didOpen

3️⃣ 用户输入

textDocument/didChange

4️⃣ 请求能力（核心）

比如自动补全：

textDocument/completion

服务端返回：

{
  "items": [
    { "label": "print", "kind": 3 }
  ]
}

四、LSP 支持的核心能力

LSP 定义了一整套标准方法：

🧠 代码智能类

自动补全（completion）
悬浮提示（hover）
签名提示（signature help）
跳转定义（definition）
查找引用（references）

🔍 分析类

诊断（diagnostics）
类型检查
lint

🛠️ 编辑类

重命名（rename）
格式化（formatting）
代码动作（code action）

📦 工作区级能力

workspace symbol
project-wide refactor

五、协议设计特点（为什么这么成功）

1️⃣ 强解耦（最关键）

👉 IDE 不需要懂语言 👉 语言工具不需要适配 IDE

2️⃣ 标准化 JSON-RPC

优点：

跨语言实现容易
调试简单
可扩展

3️⃣ 增量同步

支持：

full sync（全量）
incremental sync（增量）

👉 提升性能（关键）

4️⃣ Capability 协商机制

初始化时双方声明能力：

capabilities

👉 避免版本冲突

六、LSP 的生态价值（本质）

LSP 实际上解决的是一个经典问题：

“语言工具链标准化接口”

带来的结果：

🚀 1. 新语言更容易被支持

只需要写一个 language server

🧩 2. 编辑器插件生态爆炸

比如：

VS Code 插件 ≈ LSP client + UI
Neovim 插件 ≈ LSP wrapper

⚙️ 3. 工具链复用

一个语言服务器可以服务：

IDE
CLI 工具
Web IDE（如 GitHub Codespaces）

七、LSP vs 传统 IDE（本质差异）

维度	传统 IDE	LSP
架构	单体	分布式
扩展性	差	强
语言支持	内置	外部服务
复用性	低	高

八、LSP 的局限性（很关键）

LSP 不是银弹：

❗1. 性能瓶颈

频繁 JSON-RPC 通信
大项目延迟高

❗2. 状态同步复杂

编辑器 vs server 状态不一致
增量更新容易出 bug

❗3. 高级语义支持有限

复杂能力（比如深度重构）：

👉 有时超出 LSP 抽象能力

❗4. 各语言实现质量差异大

比如：

TS server 很强
某些小众语言 server 很弱

九、LSP 的进阶理解（架构视角）

如果你从架构角度看：

👉 LSP = 语言能力微服务化

它具备：

RPC 接口
状态管理
增量计算
AST / Index

你甚至可以类比为：

LSP Server ≈ “代码智能引擎”

十、未来演进（结合 AI）

LSP 正在和 AI 结合：

Copilot 类工具
Code completion AI
静态分析 + LLM

例如：

GitHub Copilot

👉 未来趋势：

LSP + AI = 下一代开发体验

总结一句话

👉 LSP 的本质是：

用一个标准协议，把“编程语言智能”从 IDE 中解耦出来，变成可复用的服务能力

参考资料

LSP
一、为什么会有 LSP（核心痛点）
二、LSP 的核心思想（架构解耦）
三、LSP 的工作流程（实际交互）
四、LSP 支持的核心能力
五、协议设计特点（为什么这么成功）
六、LSP 的生态价值（本质）
七、LSP vs 传统 IDE（本质差异）
八、LSP 的局限性（很关键）
九、LSP 的进阶理解（架构视角）
十、未来演进（结合 AI）
总结一句话
参考资料

AI Harness 的本质定位

Fri, 03 Apr 2026 13:01:55 +0000

一、AI Harness 的本质定位

从架构视角看，它解决的是一个核心问题：

❗如何把“不确定的 AI 行为”变成“可工程化管理的系统”

传统软件：

输入 → 输出是确定性的

AI系统（尤其是 LLM）：

输入 → 输出是概率性的、非稳定的

所以必须引入 Harness 来“约束 + 观测 + 优化”。

二、AI Harness 的核心职责拆解

1. Prompt / Task 执行编排（Execution Harness）

类似一个 AI 调度器：

Prompt 模板管理
多模型路由（GPT / Claude / 本地模型）
Tool 调用（Function Calling / MCP）
多步推理（Agent / Workflow）

👉 本质：把 AI 调用变成“可编排流程”

典型能力：

User Query
  ↓
Prompt Template
  ↓
Model Router
  ↓
Tool Calls / Memory
  ↓
Post-processing

2. 数据集驱动的评测（Evaluation Harness）

这是 Harness 最核心的部分之一。

为什么需要？

你无法靠“感觉”判断 AI 好不好。

必须：

固定输入（dataset）
对比输出（baseline vs new）
自动打分（metrics）

典型结构：

Test Dataset
  ├── input
  ├── expected output / rubric
  └── metadata

Run Harness
  ↓
Model Outputs
  ↓
Evaluator（自动 or LLM-as-judge）
  ↓
Score（accuracy / relevance / cost / latency）

👉 本质：AI 的“单元测试 + 回归测试”

3. 实验与对比（Experiment Harness）

AI开发本质是实验驱动的：

Prompt A vs Prompt B
Model A vs Model B
参数调优（temperature / top_p）

Harness 提供：

A/B Test
多版本对比
自动报告

👉 本质：AI 的“实验平台（ML Ops + Prompt Ops）”

4. 可观测性（Observability）

没有可观测性，AI系统是黑盒。

Harness 通常提供：

token 使用量
latency
prompt / response trace
tool 调用链路
failure case 收集

👉 类似：

logging
tracing（类似 OpenTelemetry）

5. 失败分析与数据闭环（Feedback Loop）

高级 Harness 会做：

自动收集 bad cases
人工标注
生成新 dataset
再训练 / 再评测

👉 形成：

线上数据 → 失败case → dataset → eval → 优化 → 再上线

三、AI Harness 的典型架构

一个比较完整的工程结构：

ai-harness/
├── prompts/
│   ├── templates
│   └── versions
├── datasets/
│   ├── eval_sets
│   └── golden_sets
├── runners/
│   ├── model_runner
│   └── tool_runner
├── evaluators/
│   ├── rule_based
│   └── llm_judge
├── experiments/
│   ├── ab_tests
│   └── reports
├── observability/
│   ├── logs
│   └── traces
└── pipelines/
    └── workflows

四、常见开源 / 工业实现

1. Stanford CRFM 的 HELM

全称：Holistic Evaluation of Language Models
强调：
- 多维度评测（公平性 / 安全性 /鲁棒性）

👉 偏“评测 harness”

2. OpenAI Evals

dataset + eval runner
支持 LLM-as-judge

👉 很典型的 eval harness

3. LangChain + LangSmith

execution + tracing + eval
更偏“应用层 harness”

4. EleutherAI LM Harness

用于 benchmark LLM（如 MMLU）
标准化评测体系

5. Microsoft PromptFlow

workflow + eval + experiment
类似 AI pipeline harness

五、和你当前方向的关系（很关键）

你现在在做：

自动化测试平台 + AI 根因分析系统

AI Harness 在你这里其实是核心基础设施，不是可选项。

在“自动化测试平台”里的角色

你可以这样用：

1. AI 用例评测

输入：日志 / trace / 报警
AI 输出：根因分析
Harness：判断是否正确

2. Prompt 优化闭环

坏case → dataset → eval → prompt优化

3. 多模型策略

简单问题 → 小模型
复杂问题 → GPT-4级
Harness 做 routing + cost control

在“根因分析系统”中的进阶用法

Harness 可以扩展成：

👉 Cognitive Harness（认知执行层）

报警
 ↓
多步骤推理（Agent）
 ↓
调用：
  - 日志系统
  - Metrics
  - Trace
 ↓
生成 Root Cause
 ↓
Harness 评估可信度

六、本质总结（非常关键）

AI Harness 工程，本质是三句话：

1️⃣ 把 AI 调用变成“可控流程”

（Execution Harness）

2️⃣ 把 AI 输出变成“可量化指标”

（Evaluation Harness）

3️⃣ 把 AI 优化变成“数据驱动闭环”

（Experiment Harness）

七、如果你要从0设计一套（架构建议）

结合你背景，我给你一个更“工程化”的方向：

核心模块优先级

Eval Harness（必须最先做）
- dataset + scoring
Execution Harness
- prompt + tool + workflow
Trace / Logging
Experiment system（AB test）
Feedback loop（自动造数据）

一个关键建议（经验结论）

❗绝大多数 AI 项目失败，不是模型不行，而是没有 Harness

因为：

无法评估
无法迭代
无法稳定

参考资料

一、AI Harness 的本质定位
二、AI Harness 的核心职责拆解
三、AI Harness 的典型架构
四、常见开源 / 工业实现
五、和你当前方向的关系（很关键）
- 在“自动化测试平台”里的角色
- 在“根因分析系统”中的进阶用法
  - 👉 Cognitive Harness（认知执行层）
六、本质总结（非常关键）
七、如果你要从0设计一套（架构建议）
- 核心模块优先级
- 一个关键建议（经验结论）
参考资料

代码知识库之 git history-11-排期

Fri, 03 Apr 2026 13:01:55 +0000

chat

背景

你是一名资深项目经理。给出整个项目的排期规划+里程碑+简单的描述、风险点

可以考虑分阶段，markdown 表格

设计

备注：仅作为参考

Git History 智能分析系统 – 项目排期规划

一、项目阶段划分

阶段	名称	周期	核心目标
P0	概念验证 (POC)	2 周	验证核心链路：Git 解析 → 图入库 → 向量检索 → Skill 调用
P1	MVP 版本	4 周	支持单仓库、单语言（Python）、基础查询接口、两个 Skills
P2	增强版本	6 周	多语言 AST 解析、增量更新、rebase 处理、性能优化
P3	生产就绪	4 周	安全加固、监控告警、多仓库支持、文档与部署

总工期：16 周（约 4 个月）

二、详细排期与里程碑

阶段 P0 – 概念验证（2 周）

周次	任务	产出	负责人
W1	搭建 JGit 解析原型，读取近一年 commit 元信息 + diff	可运行的解析脚本（Java）	后端工程师
W1	设计图数据库 schema（Neo4j），入库 100 个 commit	图数据模型 + 导入代码	数据工程师
W2	设计向量库 schema（Milvus），生成 commit 摘要向量	向量入库代码	算法工程师
W2	实现简单 HTTP 查询接口（`/semantic_search`、`/commit/files`）	后端 API（FastAPI/Spring）	后端工程师
W2	实现 Skill 1（功能→提交→文件）的 Python 脚本，调用后端	Skill 脚本 + 测试	前端/集成工程师

里程碑 M0：✅ 完成端到端流程：用户输入“登录超时” → 返回相关文件列表（至少 3 个真实案例）。

风险点：

JGit 解析大 diff 性能未知 → 准备降级方案（使用命令行 git show 备用）
Milvus 向量检索召回率低 → 准备多种 embedding 模型对比（CodeBERT / OpenAI）

阶段 P1 – MVP 版本（4 周）

周次	任务	产出	负责人
W3	完善全量解析流程：遍历近一年所有 commit，入库图+向量	批量解析调度器	后端工程师
W3	实现基础的文件重命名跟踪（`git log --follow`）	文件节点 `previousPath` 维护	后端工程师
W4	实现后端所有接口：`/file/commits`、`/commit/functions`、`/commit/cluster`	完整 API 服务	后端工程师
W4	实现 Skill 2（文件→提交聚类）的 Python 脚本	Skill 2 脚本	前端/集成工程师
W5	集成测试：使用开源仓库（如 Spring Boot）验证解析完整性	测试报告 + 缺陷修复	QA 工程师
W5	编写技能文档 + 部署指南（Docker Compose）	可部署的 MVP 包	DevOps 工程师
W6	内部试用（2-3 名开发者）并收集反馈	反馈报告 + 改进清单	产品经理

里程碑 M1：✅ 系统可独立部署，支持用户通过 Skills 查询单仓库的历史变更，响应时间 < 3 秒（除首次全量解析外）。

风险点：

全量解析耗时过长（大仓库 > 6 小时） → 增加进度条和断点续传
聚类功能（commit message 聚类）效果差 → 改用 LLM 直接生成标签（需额外成本）

阶段 P2 – 增强版本（6 周）

周次	任务	产出	负责人
W7	集成 Tree-sitter 支持多语言（Python, Java, Go, JS）	函数级 AST 解析模块	算法工程师
W7	实现增量更新：基于 reflog 检测 rebase，处理孤儿节点	增量调度器 + 清理脚本	后端工程师
W8	性能优化：并发解析、内存控制、分页处理	解析速度提升 3-5 倍	后端工程师
W8	增加 DiffHunk 向量表（用于变更模式检索）	新增 Milvus collection	算法工程师
W9	实现智能摘要：LLM 为 commit 生成 10 字标签	批量摘要生成服务	算法工程师
W9	优化 Skill 上下文：按相关度裁剪 diff 片段	Skill 端智能截断逻辑	前端/集成工程师
W10	增加解析状态表（重试、死信队列）	健壮的错误处理	后端工程师
W11	编写技术文档（API 规范、运维手册）	文档站点	技术文档工程师
W12	端到端压力测试（模拟 100 并发查询）	性能报告 + 调优	QA 工程师

里程碑 M2：✅ 支持多语言，增量更新 < 5 分钟，查询 P99 延迟 < 500ms，解析失败率 < 1%。

风险点：

Tree-sitter 对某些语法错误代码解析失败率高 → 降级到正则 + 文件级
LLM 批量生成摘要成本高（每月 $100+） → 改用本地小模型（如 BERT 微调）
增量更新中 reflog 解析复杂 → 简化策略：每天凌晨全量重建（若仓库不大）

阶段 P3 – 生产就绪（4 周）

周次	任务	产出	负责人
W13	安全加固：JWT 认证、输入校验、多租户隔离	安全审计报告	安全工程师
W13	监控与告警：Prometheus + Grafana 面板	实时监控看板	DevOps 工程师
W14	支持多仓库并行解析（配置多个 repo）	多仓库管理界面	后端工程师
W14	增加管理 UI（可选）：查看解析进度、手动触发增量	简易管理后台	前端工程师
W15	灰度发布：在生产环境选择 1 个核心仓库运行	灰度报告 + 修复	全体
W15	编写用户手册 + 培训视频	培训材料	产品经理
W16	正式发布 + 知识转移	项目总结报告	项目经理

里程碑 M3：✅ 系统上线生产，支持 10+ 仓库，可用性 99.5%，MTTR < 1 小时。

风险点：

多仓库并行导致资源竞争（CPU/内存） → 使用容器化 + 资源限制（K8s）
生产环境 Git 仓库权限复杂 → 使用 SSH 密钥 + 只读部署密钥
用户接受度低（Skills 使用不便） → 提前培训 + 提供 IDE 插件原型

三、总体风险清单

风险类别	具体风险	概率	影响	缓解措施
技术风险	JGit 解析大仓库（>10 万 commit）内存溢出	中	高	分页处理 + 使用命令行 `git` 备用
技术风险	Tree-sitter 对历史损坏代码解析失败	高	中	降级到文件级，记录错误
技术风险	Milvus 向量检索召回率 < 80%	中	高	预计算多种 embedding，A/B 测试
进度风险	增量更新逻辑（reflog）复杂度超预期	中	中	先实现简单定时全量重建，后续优化
资源风险	LLM 调用成本超预算	低	中	使用开源模型（CodeBERT）或自建向量
运维风险	多仓库并发导致磁盘 IO 瓶颈	中	中	使用 SSD + 限制同时解析数
用户风险	Skills 与 opencode 集成不兼容	低	高	提供独立 CLI 工具作为 fallback

四、关键决策点

P0 结束：评估是否继续（若核心链路不通，则终止或调整方案）
P1 结束：决定是否使用 LLM 生成摘要（根据成本与效果）
P2 结束：决定是否支持多语言（若用户反馈仅需 Python，则推迟多语言）
P3 开始前：确定生产仓库列表和资源配额

五、团队角色建议

角色	人数	职责
后端工程师	2	JGit 解析、API 开发、增量逻辑
数据工程师	1	Neo4j + Milvus 建模与优化
算法工程师	1	向量生成、AST 解析、聚类
前端/集成工程师	1	Skills 脚本、LLM 集成
QA 工程师	1	测试、性能压测
DevOps 工程师	1	容器化、监控部署
产品经理	0.5	需求、反馈收集
项目经理	0.5	排期、风险跟踪

总人力：约 6-7 人（部分可兼职）

六、成功标准

支持至少 1 个生产仓库（如 Spring Framework）的全量解析，耗时 < 2 小时。
两个 Skills 在 opencode 中正常运行，用户查询平均响应 < 2 秒。
增量更新延迟 < 10 分钟。
单元测试覆盖率 > 70%，集成测试覆盖核心路径。
系统稳定运行 7×24 小时，无致命错误。

以上排期可根据实际团队资源和技术难点灵活调整。建议采用 敏捷迭代，每两周一个 sprint，及时调整优先级。

参考资料

chat
参考资料

代码知识库之 git history-10-其他

Fri, 03 Apr 2026 13:01:55 +0000

chat

背景

你觉得这个工程的设计还有哪些缺失或者需要重点关注的地方？为什么？

设计

非常好的问题。经过前面的设计，我们已经覆盖了核心的解析落库、向量检索、Skill调用等环节，但要真正落地一个稳定、可扩展的生产级系统，还有以下几个关键缺失和需要重点关注的地方，每个都解释了为什么重要。

一、增量更新的准确性与一致性

缺失点

目前只讨论了“定时扫描近一年”或“基于 last_commit_time 增量”，但没有处理 Git 历史被改写的情况（如 rebase、amend、force push）。这些操作会导致已入库的 commit 消失或替换，造成图数据库和向量库中存在孤儿节点，且增量逻辑会漏掉新提交或重复处理。

为什么重要

团队使用 rebase 非常普遍，忽略会导致数据错误和查询结果不可信。
若不加处理，用户可能看到已废弃的提交，或者丢失最新的变更。

建议方案

每个仓库维护一个 branch_tip_history 表，记录默认分支（如 main）每次 reflog 更新的 commit SHA。
定期（如每小时）执行 git reflog 检测 tip 变化，若发生变化，则从上次记录的 tip 到当前 tip 之间的 commit 进行全量重新解析（因为 rebase 可能打乱顺序）。
对于孤儿 commit，通过图数据库查询并标记 is_active=false，在查询时过滤；同时定期物理删除。

二、大规模仓库的性能与资源控制

缺失点

设计中对性能考虑较少，尤其是：

大仓库（几万个 commit）全量解析时，逐个 commit 调用 JGit API 可能非常慢。
DiffFormatter 默认会加载整个 diff 到内存，大文件 diff 可能导致 OOM。
同时解析多个 commit 时，没有控制并发度，可能耗尽文件句柄或内存。

为什么重要

若仓库有 5 万个 commit，按每秒处理 10 个计算，需要近 1.5 小时，且内存占用可能超过 2GB。
生产环境需要可预测的资源消耗和合理的处理时间。

建议方案

分页 + 批量提交：每次只处理 1000 个 commit，然后记录 checkpoint。
控制并发：使用固定线程池（如 CPU 核数），每个线程处理一个 commit 的 diff 解析和 AST 分析。
流式处理：对于超大 diff（如 10MB+ 的 JSON 文件），不加载全部内容到内存，而是使用 JGit 的 RawText 按需读取。
限制 AST 解析范围：只解析被修改的文件，且只解析被修改行附近的函数（而非整个文件）。

三、错误处理与可观测性

缺失点

目前代码示例中只有简单的 try-catch 和日志，但缺少：

解析失败的 commit 重试机制（如网络超时、临时文件锁）。
部分失败时的状态保存（例如某个 commit 的 diff 解析失败，不影响后续）。
监控指标（处理速度、失败率、各阶段耗时）。

为什么重要

生产环境一定会遇到各种异常（仓库损坏、超大文件、权限问题等），没有容错机制会导致整个流程中断。
无法评估系统健康状况，也难以定位性能瓶颈。

建议方案

为每个 commit 的处理记录状态到一张 processing_state 表（如 MySQL 或 Redis），包含 commit_hash, status (pending/success/failed), retry_count, error_msg。
实现死信队列：失败超过 3 次的 commit 进入死信表，人工介入。
暴露 Prometheus 指标：processed_commits_total, failed_commits_total, parse_duration_seconds。

四、多语言 AST 解析的鲁棒性

缺失点

目前提到使用 Tree-sitter 或 JGit 自带的解析器，但实际实现中：

不同语言的语法差异巨大，且代码可能包含语法错误（在历史 commit 中常见）。
定位“diff hunk 属于哪个函数”需要精确的行号映射，但函数可能跨多个 hunk，或者 hunk 恰好落在函数外部（如文件头部）。

为什么重要

函数级别的语义检索是核心价值，如果函数归属错误，检索结果会严重降级。
历史代码可能含有语法错误，导致 AST 解析失败，需要降级策略。

建议方案

使用 Tree-sitter（支持增量解析、错误恢复）作为统一解析引擎，为每种语言提供语法。
对于无法解析的行，降级为文件级关系（即只知道 diff 改了文件，不知道具体函数）。
维护一个 parse_error_log 表，记录哪些文件/commit 解析失败，以便后续改进解析器。

五、图与向量数据的一致性

缺失点

我们设计了冗余字段（如 File.lastCommitHash、DiffHunk.commitHash）来加速查询，但没有明确冗余字段的更新策略和一致性保证。当增量更新时，如果某个 commit 被 rebase 删除，这些冗余字段不会自动更新，导致查询结果错误。

为什么重要

冗余字段一旦与真实关系不一致，查询会返回错误信息（例如显示某个文件最后一次修改是已删除的 commit）。
手动维护一致性代价高，容易遗漏。

建议方案

冗余字段仅用于展示和快速过滤，不用于关键决策。核心查询仍应优先使用图关系。
增量更新时，如果检测到 commit 被移除，需要级联更新：
- 找出该 commit 修改过的所有文件，重新计算每个文件的 lastCommitHash（取剩余 commit 中时间最新的）。
- 删除对应的 DiffHunk 节点及其向量。
定期（如每周）运行一致性校验脚本，扫描冗余字段是否与图关系匹配，修复差异。

六、Skill 的 LLM 上下文优化

缺失点

Skill 会返回多个提交、多个文件和函数，但直接把这些原始数据扔给 LLM 会导致：

Token 爆炸：一个功能可能关联 10+ 个提交，每个提交又包含多个文件的完整 diff，轻松超过 32k tokens。
信噪比低：LLM 难以从大量重复或无关代码中提取关键信息。

为什么重要

用户体验差：LLM 响应慢，甚至因超长上下文而失败。
成本高：按 token 计费的模型会产生不必要的费用。

建议方案

在 Skill 中增加智能摘要层：
- 对同一个文件的多次修改，只保留最相关的 3 个 commit（按相似度或时间）。
- 对每个 diff hunk，只提取变更前后的 5 行关键代码，而不是整个函数。
- 对 commit message 使用 LLM 生成 10 个字以内的意图标签（如“修复 NPE”、“增加缓存”）。
提供分页/详情查询接口：Skill 先返回摘要列表（commit hash + 标签），用户选择后再获取详细 diff。

七、安全性

缺失点

后端接口如果直接执行用户传入的 file_path 或 commit_hash，可能存在路径遍历或注入攻击（虽然 JGit 会校验，但 HTTP 接口未做白名单过滤）。
多租户场景下，用户可能越权访问其他仓库的数据。

为什么重要

生产环境的安全漏洞可能导致仓库源码泄露或系统被破坏。

建议方案

后端接口对 file_path 进行白名单校验（如正则 ^[a-zA-Z0-9_\-./]+$），拒绝包含 .. 或特殊字符的路径。
使用 JWT 或 API Key 进行认证，每个 token 绑定特定的 repoId 列表，查询时强制过滤 repoId（即使请求参数中未指定）。
对 commit_hash 使用 ObjectId.isId(String) 验证是否为有效的 SHA-1 格式。

八、总结：需要补充的设计文档

缺失项	优先级	建议文档/模块
增量一致性与 rebase 处理	高	增加 `ReflogMonitor` 模块，设计孤儿节点清理策略
性能与资源控制	高	设计分页处理、并发控制、内存限制参数
错误处理与可观测性	中	增加 `ProcessingState` 表、Prometheus 指标、死信队列
AST 解析鲁棒性	高	引入 Tree-sitter，设计降级策略和错误日志
冗余字段一致性	中	设计一致性校验脚本和自动修复流程
LLM 上下文优化	中	在 Skill 中实现智能摘要和分页加载
安全性	高	增加认证、授权、输入校验

参考资料

chat
参考资料

代码知识库之 git history-09-git 命令 java 实现

Fri, 03 Apr 2026 13:01:55 +0000

chat

背景

给出一段 java 代码，建议使用 java 稳定推荐的 git 开源包。

给出 pom 依赖。

给出一个代码仓库，上面3个命令，获取近一年的提交数据的数据构建，面向对象的写法，给出核心代码

设计

以下是基于 JGit 的完整 Java 实现，包含 Maven 依赖和核心代码。

一、Maven 依赖（pom.xml）

<?xml version="1.0" encoding="UTF-8"?>
<project xmlns="http://maven.apache.org/POM/4.0.0"
         xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
         xsi:schemaLocation="http://maven.apache.org/POM/4.0.0
         https://maven.apache.org/xsd/maven-4.0.0.xsd">
    <modelVersion>4.0.0</modelVersion>

    <groupId>com.git.history</groupId>
    <artifactId>git-history-analyzer</artifactId>
    <version>1.0.0</version>
    <packaging>jar</packaging>

    <properties>
        <maven.compiler.source>11</maven.compiler.source>
        <maven.compiler.target>11</maven.compiler.target>
        <project.build.sourceEncoding>UTF-8</project.build.sourceEncoding>
    </properties>

    <dependencies>
        <!-- JGit 核心库（当前最新稳定版本） -->
        <dependency>
            <groupId>org.eclipse.jgit</groupId>
            <artifactId>org.eclipse.jgit</artifactId>
            <version>7.4.0.202509020913-r</version>
        </dependency>

        <!-- SLF4J 日志接口（JGit 依赖） -->
        <dependency>
            <groupId>org.slf4j</groupId>
            <artifactId>slf4j-simple</artifactId>
            <version>2.0.9</version>
        </dependency>

        <!-- Lombok（可选，用于简化 POJO） -->
        <dependency>
            <groupId>org.projectlombok</groupId>
            <artifactId>lombok</artifactId>
            <version>1.18.30</version>
            <scope>provided</scope>
        </dependency>
    </dependencies>

    <build>
        <plugins>
            <plugin>
                <groupId>org.apache.maven.plugins</groupId>
                <artifactId>maven-compiler-plugin</artifactId>
                <version>3.11.0</version>
                <configuration>
                    <source>11</source>
                    <target>11</target>
                </configuration>
            </plugin>
        </plugins>
    </build>
</project>

二、数据模型（POJO 类）

2.1 `CommitInfo.java`（提交元信息）

package com.git.history.model;

import lombok.AllArgsConstructor;
import lombok.Builder;
import lombok.Data;
import lombok.NoArgsConstructor;

import java.util.Date;
import java.util.List;

@Data
@Builder
@NoArgsConstructor
@AllArgsConstructor
public class CommitInfo {
    /** 完整 commit SHA（40 字符） */
    private String hash;
    
    /** 作者名 */
    private String authorName;
    
    /** 作者邮箱 */
    private String authorEmail;
    
    /** 作者时间（Unix 时间戳，秒） */
    private Long authorTime;
    
    /** 提交消息第一行（subject） */
    private String subject;
    
    /** 变更的文件列表 */
    private List<FileChangeInfo> fileChanges;
}

2.2 `FileChangeInfo.java`（文件变更信息）

package com.git.history.model;

import lombok.AllArgsConstructor;
import lombok.Builder;
import lombok.Data;
import lombok.NoArgsConstructor;

import java.util.List;

@Data
@Builder
@NoArgsConstructor
@AllArgsConstructor
public class FileChangeInfo {
    /** 文件路径（相对于仓库根目录） */
    private String path;
    
    /** 变更类型：ADD, DELETE, MODIFY, RENAME */
    private ChangeType changeType;
    
    /** 变更前的文件路径（仅重命名时有效） */
    private String oldPath;
    
    /** 变更块的列表（diff hunks） */
    private List<DiffHunkInfo> hunks;
    
    public enum ChangeType {
        ADD,      // 新增文件
        DELETE,   // 删除文件
        MODIFY,   // 修改文件
        RENAME    // 重命名文件
    }
}

2.3 `DiffHunkInfo.java`（差异块信息）

package com.git.history.model;

import lombok.AllArgsConstructor;
import lombok.Builder;
import lombok.Data;
import lombok.NoArgsConstructor;

@Data
@Builder
@NoArgsConstructor
@AllArgsConstructor
public class DiffHunkInfo {
    /** 旧文件起始行号 */
    private int oldStartLine;
    
    /** 旧文件总行数 */
    private int oldLineCount;
    
    /** 新文件起始行号 */
    private int newStartLine;
    
    /** 新文件总行数 */
    private int newLineCount;
    
    /** 变更行的列表（每行内容，'-' 表示删除，'+' 表示新增） */
    private List<String> lines;
}

三、核心服务类

3.1 `GitHistoryAnalyzer.java`（主分析器）

package com.git.history.service;

import com.git.history.model.CommitInfo;
import com.git.history.model.FileChangeInfo;
import com.git.history.model.DiffHunkInfo;
import lombok.extern.slf4j.Slf4j;
import org.eclipse.jgit.api.Git;
import org.eclipse.jgit.api.errors.GitAPIException;
import org.eclipse.jgit.diff.DiffEntry;
import org.eclipse.jgit.diff.DiffFormatter;
import org.eclipse.jgit.diff.Edit;
import org.eclipse.jgit.diff.EditList;
import org.eclipse.jgit.diff.RawTextComparator;
import org.eclipse.jgit.errors.MissingObjectException;
import org.eclipse.jgit.lib.ObjectId;
import org.eclipse.jgit.lib.ObjectReader;
import org.eclipse.jgit.lib.Repository;
import org.eclipse.jgit.patch.FileHeader;
import org.eclipse.jgit.patch.HunkHeader;
import org.eclipse.jgit.revwalk.RevCommit;
import org.eclipse.jgit.revwalk.RevWalk;
import org.eclipse.jgit.revwalk.filter.CommitTimeRevFilter;
import org.eclipse.jgit.storage.file.FileRepositoryBuilder;
import org.eclipse.jgit.treewalk.CanonicalTreeParser;
import org.eclipse.jgit.treewalk.EmptyTreeIterator;

import java.io.ByteArrayOutputStream;
import java.io.File;
import java.io.IOException;
import java.nio.charset.StandardCharsets;
import java.time.Instant;
import java.time.temporal.ChronoUnit;
import java.util.ArrayList;
import java.util.Date;
import java.util.List;

@Slf4j
public class GitHistoryAnalyzer implements AutoCloseable {
    
    private final Repository repository;
    private final Git git;
    private final RevWalk revWalk;
    
    /**
     * 构造函数，打开本地 Git 仓库
     *
     * @param repoPath .git 目录的路径或工作目录路径
     * @throws IOException 如果无法打开仓库
     */
    public GitHistoryAnalyzer(String repoPath) throws IOException {
        FileRepositoryBuilder builder = new FileRepositoryBuilder();
        // 如果传入的是 .git 目录，直接设置；否则尝试查找
        File gitDir = new File(repoPath);
        if (gitDir.isDirectory() && gitDir.getName().equals(".git")) {
            builder.setGitDir(gitDir);
        } else {
            builder.setWorkTree(gitDir).findGitDir();
        }
        
        this.repository = builder
                .readEnvironment()
                .build();
        this.git = new Git(repository);
        this.revWalk = new RevWalk(repository);
    }
    
    /**
     * 获取近一年内的所有提交（按时间正序）
     *
     * @return 提交 SHA 列表
     * @throws GitAPIException Git 操作异常
     */
    public List<String> getCommitsSinceOneYear() throws GitAPIException {
        // 计算一年前的日期
        Date since = Date.from(Instant.now().minus(365, ChronoUnit.DAYS));
        log.info("获取 {} 之后的提交记录", since);
        
        List<String> commitHashes = new ArrayList<>();
        // 使用 LogCommand，添加时间过滤器（按正序输出）
        Iterable<RevCommit> commits = git.log()
                .setRevFilter(CommitTimeRevFilter.after(since))
                .call();
        
        // 转换为正序（git.log() 默认按时间倒序）
        List<RevCommit> revCommitList = new ArrayList<>();
        for (RevCommit commit : commits) {
            revCommitList.add(commit);
        }
        // 反转得到正序
        for (int i = revCommitList.size() - 1; i >= 0; i--) {
            commitHashes.add(revCommitList.get(i).getName());
        }
        
        log.info("共获取 {} 个提交", commitHashes.size());
        return commitHashes;
    }
    
    /**
     * 获取单个提交的元信息
     *
     * @param commitHash 提交 SHA
     * @return CommitInfo 对象
     * @throws IOException IO 异常
     */
    public CommitInfo getCommitMeta(String commitHash) throws IOException {
        ObjectId objectId = repository.resolve(commitHash);
        if (objectId == null) {
            throw new IllegalArgumentException("无效的 commit hash: " + commitHash);
        }
        
        RevCommit commit = revWalk.parseCommit(objectId);
        revWalk.parseBody(commit);
        
        return CommitInfo.builder()
                .hash(commit.getName())
                .authorName(commit.getAuthorIdent().getName())
                .authorEmail(commit.getAuthorIdent().getEmailAddress())
                .authorTime(commit.getAuthorIdent().getWhen().getTime() / 1000L)
                .subject(commit.getShortMessage())
                .build();
    }
    
    /**
     * 获取单个提交的 Diff 信息（不含元信息）
     *
     * @param commitHash 提交 SHA
     * @return 文件变更列表
     * @throws IOException IO 异常
     */
    public List<FileChangeInfo> getCommitDiff(String commitHash) throws IOException {
        ObjectId objectId = repository.resolve(commitHash);
        if (objectId == null) {
            throw new IllegalArgumentException("无效的 commit hash: " + commitHash);
        }
        
        RevCommit commit = revWalk.parseCommit(objectId);
        revWalk.parseBody(commit);
        
        // 获取父提交
        RevCommit parent = null;
        if (commit.getParentCount() > 0) {
            parent = revWalk.parseCommit(commit.getParent(0).getId());
        }
        
        return computeDiff(parent, commit);
    }
    
    /**
     * 计算两个提交之间的差异
     *
     * @param oldCommit 旧提交（可为 null，表示空树）
     * @param newCommit 新提交
     * @return 文件变更列表
     * @throws IOException IO 异常
     */
    private List<FileChangeInfo> computeDiff(RevCommit oldCommit, RevCommit newCommit) throws IOException {
        List<FileChangeInfo> fileChanges = new ArrayList<>();
        
        try (DiffFormatter diffFormatter = new DiffFormatter(new ByteArrayOutputStream())) {
            diffFormatter.setRepository(repository);
            // 关闭上下文行数（相当于 --unified=0），只显示变更行
            diffFormatter.setContext(0);
            diffFormatter.setDiffComparator(RawTextComparator.DEFAULT);
            diffFormatter.setDetectRenames(true);
            
            List<DiffEntry> diffs;
            try (ObjectReader reader = repository.newObjectReader()) {
                if (oldCommit == null) {
                    // 初始提交：对比空树
                    CanonicalTreeParser newTreeParser = new CanonicalTreeParser();
                    newTreeParser.reset(reader, newCommit.getTree());
                    diffs = diffFormatter.scan(new EmptyTreeIterator(), newTreeParser);
                } else {
                    CanonicalTreeParser oldTreeParser = new CanonicalTreeParser();
                    CanonicalTreeParser newTreeParser = new CanonicalTreeParser();
                    oldTreeParser.reset(reader, oldCommit.getTree());
                    newTreeParser.reset(reader, newCommit.getTree());
                    diffs = diffFormatter.scan(oldTreeParser, newTreeParser);
                }
            }
            
            for (DiffEntry diff : diffs) {
                FileChangeInfo changeInfo = parseDiffEntry(diff, diffFormatter);
                fileChanges.add(changeInfo);
            }
        }
        
        return fileChanges;
    }
    
    /**
     * 解析单个 DiffEntry 为 FileChangeInfo
     *
     * @param diffEntry      DiffEntry 对象
     * @param diffFormatter  DiffFormatter（用于获取 FileHeader）
     * @return FileChangeInfo
     * @throws IOException IO 异常
     */
    private FileChangeInfo parseDiffEntry(DiffEntry diffEntry, DiffFormatter diffFormatter) throws IOException {
        FileChangeInfo.ChangeType changeType;
        String path = diffEntry.getNewPath();
        String oldPath = null;
        
        switch (diffEntry.getChangeType()) {
            case ADD:
                changeType = FileChangeInfo.ChangeType.ADD;
                break;
            case DELETE:
                changeType = FileChangeInfo.ChangeType.DELETE;
                path = diffEntry.getOldPath();
                break;
            case RENAME:
                changeType = FileChangeInfo.ChangeType.RENAME;
                oldPath = diffEntry.getOldPath();
                break;
            default:
                changeType = FileChangeInfo.ChangeType.MODIFY;
                break;
        }
        
        // 获取 FileHeader 以提取 hunk 信息
        FileHeader fileHeader = diffFormatter.toFileHeader(diffEntry);
        List<DiffHunkInfo> hunks = parseHunks(fileHeader);
        
        return FileChangeInfo.builder()
                .path(path)
                .oldPath(oldPath)
                .changeType(changeType)
                .hunks(hunks)
                .build();
    }
    
    /**
     * 解析 FileHeader 中的 Hunk 信息
     *
     * @param fileHeader FileHeader 对象
     * @return Hunk 列表
     */
    private List<DiffHunkInfo> parseHunks(FileHeader fileHeader) {
        List<DiffHunkInfo> hunks = new ArrayList<>();
        
        for (HunkHeader hunkHeader : fileHeader.getHunks()) {
            // 获取旧文件的行号范围
            int oldStart = hunkHeader.getOldStart();
            int oldLines = hunkHeader.getOldLines();
            // 获取新文件的行号范围
            int newStart = hunkHeader.getNewStart();
            int newLines = hunkHeader.getNewLines();
            
            // 获取 hunk 中的具体变更行
            List<String> lines = new ArrayList<>();
            for (Edit edit : hunkHeader.toEditList()) {
                // Edit 包含变更的详细信息
                // 实际行内容需要从原始文件读取，这里简化处理
                lines.add(formatEditInfo(edit));
            }
            
            DiffHunkInfo hunk = DiffHunkInfo.builder()
                    .oldStartLine(oldStart)
                    .oldLineCount(oldLines)
                    .newStartLine(newStart)
                    .newLineCount(newLines)
                    .lines(lines)
                    .build();
            hunks.add(hunk);
        }
        
        return hunks;
    }
    
    /**
     * 格式化 Edit 信息（用于展示）
     *
     * @param edit Edit 对象
     * @return 格式化的字符串
     */
    private String formatEditInfo(Edit edit) {
        switch (edit.getType()) {
            case INSERT:
                return String.format("+ insert at line %d", edit.getBeginB());
            case DELETE:
                return String.format("- delete at line %d", edit.getBeginA());
            case REPLACE:
                return String.format("~ replace lines %d-%d with lines %d-%d",
                        edit.getBeginA(), edit.getEndA() - 1,
                        edit.getBeginB(), edit.getEndB() - 1);
            default:
                return "  unchanged";
        }
    }
    
    /**
     * 关闭资源
     */
    @Override
    public void close() {
        if (revWalk != null) {
            revWalk.close();
        }
        if (git != null) {
            git.close();
        }
        if (repository != null) {
            repository.close();
        }
    }
}

四、使用示例

`Main.java`（入口示例）

package com.git.history;

import com.git.history.model.CommitInfo;
import com.git.history.model.FileChangeInfo;
import com.git.history.service.GitHistoryAnalyzer;
import lombok.extern.slf4j.Slf4j;

import java.util.List;

@Slf4j
public class Main {
    public static void main(String[] args) {
        // 仓库路径（可以是 .git 目录或工作目录）
        String repoPath = "/path/to/your/repo";
        
        try (GitHistoryAnalyzer analyzer = new GitHistoryAnalyzer(repoPath)) {
            // 1. 获取近一年所有提交 hash
            List<String> commitHashes = analyzer.getCommitsSinceOneYear();
            log.info("找到 {} 个提交", commitHashes.size());
            
            // 2. 遍历每个提交
            for (int i = 0; i < commitHashes.size(); i++) {
                String hash = commitHashes.get(i);
                log.info("处理第 {}/{} 个提交: {}", i + 1, commitHashes.size(), hash);
                
                // 获取提交元信息
                CommitInfo meta = analyzer.getCommitMeta(hash);
                log.info("作者: {}, 时间: {}, 消息: {}",
                        meta.getAuthorName(),
                        meta.getAuthorTime(),
                        meta.getSubject());
                
                // 获取 diff 信息
                List<FileChangeInfo> changes = analyzer.getCommitDiff(hash);
                for (FileChangeInfo change : changes) {
                    log.info("  文件: {}, 变更类型: {}",
                            change.getPath(),
                            change.getChangeType());
                    log.info("  Hunk 数量: {}", change.getHunks().size());
                }
            }
            
        } catch (Exception e) {
            log.error("解析失败", e);
        }
    }
}

五、代码结构总结

src/main/java/com/git/history/
├── model/
│   ├── CommitInfo.java          // 提交元信息 POJO
│   ├── FileChangeInfo.java      // 文件变更信息 POJO
│   └── DiffHunkInfo.java        // Diff Hunk 信息 POJO
├── service/
│   └── GitHistoryAnalyzer.java  // 核心分析服务（主要逻辑）
└── Main.java                    // 使用示例入口

六、关键技术点说明

功能	JGit API	说明
获取提交列表	`git.log().setRevFilter(CommitTimeRevFilter.after(since)).call()`	使用 `CommitTimeRevFilter` 按时间过滤，相当于 `--since="1 year ago"`
获取提交元信息	`RevCommit.getAuthorIdent().getName()` / `.getEmailAddress()` / `.getWhen()` / `.getShortMessage()`	对应命令2的 `%an`, `%ae`, `%at`, `%s`
获取纯净 diff	`DiffFormatter` + `setContext(0)` + `setDetectRenames(true)`	`setContext(0)` 相当于 `--unified=0`
处理初始提交	`new EmptyTreeIterator()`	父提交为空时，对比空树
提取 Hunk 信息	`FileHeader.getHunks()` → `HunkHeader.getOldStart()`, `.getNewStart()` 等	提取行号范围
检测重命名	`DiffFormatter.setDetectRenames(true)`	自动检测文件重命名，`DiffEntry.getChangeType()` 返回 `RENAME`

参考资料

chat
参考资料

代码知识库之 git history-08-git 命令

Fri, 03 Apr 2026 13:01:55 +0000

chat

背景

整个设计中，会涉及到哪些 git 命令

给出这些命令的解释+例子

设计

为什么这是“最少+科学”的组合？

命令1 只做一件事：列出需要处理的 commit，支持时间过滤和正序。
命令2 以竖线分隔输出，无歧义，程序可直接 split('|')。
命令3 只输出 diff 内容，无额外信息，解析简单。
总共 3 个命令，每个命令职责单一，管道清晰，易于并行处理。

如果你需要更丰富的元信息（如 committer、父 hash），可以在命令2中增加字段，但会面临分隔符冲突风险。

建议保持这 3 个命令作为基础，其他信息通过额外命令按需获取（例如 git rev-parse $hash^@）。

参考资料

chat
参考资料

代码知识库之 git history-07-mivlus 向量数据库

Fri, 03 Apr 2026 13:01:55 +0000

chat

背景

类似的，给出向量数据库的表字段+索引。

我初步想的，大概需要 gitHistoryCommit（提交记录）;

gitHistoryFile（提交文件，冗余commitId）;   

gitHistoryMethod（提交函数，冗余 fileId）。

每个字段都要有 repoId，时间。其他的你看着设计。

设计

向量数据库（Milvus）完整表设计（Java SDK 2.6.13）

一、表清单与原因

表名	对应图实体	需要原因
`gitHistoryCommit`	`GitHistoryCommit`	提交级语义检索，用于“自然语言 → 提交”
`gitHistoryFile`	`GitHistoryFile`	文件级语义检索，用于“功能描述 → 文件”
`gitHistoryDiffHunk`	`GitHistoryDiffHunk`	细粒度变更块检索，用于“类似修改模式”的匹配（例如查找相似的 bug 修复片段）
`gitHistoryMethod`	`GitHistoryFunction`	函数级语义检索，用于代码片段相似匹配、推荐相似实现

为什么需要 DiffHunk 表？
虽然 DiffHunk 是中间实体，但它的 newCode 和 oldCode 包含变更的具体内容，可以用于检索“历史上类似的修改”。例如：查找“所有增加空指针检查的 diff 块”，直接检索 diff hunk 比检索函数更精确。因此保留该表。

二、通用设计原则（Java SDK 2.6.13）

分区键：所有表均以 repoId 作为分区键（isPartitionKey(true)），实现多仓库物理隔离。
标量索引：对过滤字段（repoId、commitHash、fileId、methodId、时间戳等）创建 INVERTED 索引。
向量索引：使用 HNSW，度量类型 COSINE，参数 M=16，efConstruction=200。
向量维度：1536（适配 text-embedding-3-small 等模型）。
自动主键：id 字段自增，类型 Int64。

三、Collection 1: `gitHistoryCommit`

3.1 字段定义

字段名	类型	是否向量	说明	索引
`id`	INT64	否	自增主键	主键
`commitHash`	VARCHAR(40)	否	完整 commit SHA	INVERTED
`repoId`	VARCHAR(128)	否	仓库标识（分区键）	INVERTED
`authorTime`	INT64	否	提交时间戳（秒）	INVERTED
`summary`	VARCHAR(1024)	否	提交摘要（message + 变更文件列表）	无
`embedding`	FLOAT_VECTOR(1536)	✅	语义向量	HNSW（COSINE）

3.2 Java 创建代码

import io.milvus.v2.client.MilvusClientV2;
import io.milvus.v2.common.DataType;
import io.milvus.v2.common.IndexParam;
import io.milvus.v2.service.collection.request.CreateCollectionReq;
import io.milvus.v2.service.index.request.CreateIndexReq;

public class CreateCommitCollection {
    public static void create(MilvusClientV2 client, String collectionName) {
        // 1. 定义 Schema
        CreateCollectionReq.CollectionSchema schema = client.createSchema();
        schema.addField(DataType.Int64, "id", true, true);  // 主键，自增
        schema.addField(DataType.VarChar, "commitHash", 40, false);
        schema.addField(DataType.VarChar, "repoId", 128, false).setPartitionKey(true);
        schema.addField(DataType.Int64, "authorTime", false);
        schema.addField(DataType.VarChar, "summary", 1024, false);
        schema.addField(DataType.FloatVector, "embedding", 1536, false);

        // 2. 创建 Collection
        CreateCollectionReq createReq = CreateCollectionReq.builder()
                .collectionName(collectionName)
                .collectionSchema(schema)
                .build();
        client.createCollection(createReq);

        // 3. 创建标量索引
        client.createIndex(CreateIndexReq.builder()
                .collectionName(collectionName)
                .fieldName("commitHash")
                .indexType(IndexParam.IndexType.INVERTED)
                .build());
        client.createIndex(CreateIndexReq.builder()
                .collectionName(collectionName)
                .fieldName("repoId")
                .indexType(IndexParam.IndexType.INVERTED)
                .build());
        client.createIndex(CreateIndexReq.builder()
                .collectionName(collectionName)
                .fieldName("authorTime")
                .indexType(IndexParam.IndexType.INVERTED)
                .build());

        // 4. 创建向量索引
        IndexParam indexParam = IndexParam.builder()
                .fieldName("embedding")
                .indexType(IndexParam.IndexType.HNSW)
                .metricType(IndexParam.MetricType.COSINE)
                .extraParam("M", 16)
                .extraParam("efConstruction", 200)
                .build();
        client.createIndex(CreateIndexReq.builder()
                .collectionName(collectionName)
                .indexParam(indexParam)
                .build());
    }
}

四、Collection 2: `gitHistoryFile`

4.1 字段定义

字段名	类型	是否向量	说明	索引
`id`	INT64	否	自增主键	主键
`fileId`	VARCHAR(512)	否	文件唯一标识（`{repoId}:{path}`）	INVERTED
`filePath`	VARCHAR(1024)	否	文件路径	INVERTED
`repoId`	VARCHAR(128)	否	仓库标识（分区键）	INVERTED
`lastCommitHash`	VARCHAR(40)	否	最后修改的 commit hash	INVERTED
`language`	VARCHAR(32)	否	编程语言	INVERTED
`updateTime`	INT64	否	解析时间戳（秒）	INVERTED
`description`	VARCHAR(2048)	否	文件描述（文件名+路径+主要类/函数摘要）	无
`embedding`	FLOAT_VECTOR(1536)	✅	语义向量	HNSW（COSINE）

4.2 Java 创建代码

public class CreateFileCollection {
    public static void create(MilvusClientV2 client, String collectionName) {
        CreateCollectionReq.CollectionSchema schema = client.createSchema();
        schema.addField(DataType.Int64, "id", true, true);
        schema.addField(DataType.VarChar, "fileId", 512, false);
        schema.addField(DataType.VarChar, "filePath", 1024, false);
        schema.addField(DataType.VarChar, "repoId", 128, false).setPartitionKey(true);
        schema.addField(DataType.VarChar, "lastCommitHash", 40, false);
        schema.addField(DataType.VarChar, "language", 32, false);
        schema.addField(DataType.Int64, "updateTime", false);
        schema.addField(DataType.VarChar, "description", 2048, false);
        schema.addField(DataType.FloatVector, "embedding", 1536, false);

        client.createCollection(CreateCollectionReq.builder()
                .collectionName(collectionName)
                .collectionSchema(schema)
                .build());

        // 标量索引
        for (String field : Arrays.asList("fileId", "filePath", "repoId", "lastCommitHash", "language", "updateTime")) {
            client.createIndex(CreateIndexReq.builder()
                    .collectionName(collectionName)
                    .fieldName(field)
                    .indexType(IndexParam.IndexType.INVERTED)
                    .build());
        }

        // 向量索引
        IndexParam indexParam = IndexParam.builder()
                .fieldName("embedding")
                .indexType(IndexParam.IndexType.HNSW)
                .metricType(IndexParam.MetricType.COSINE)
                .extraParam("M", 16)
                .extraParam("efConstruction", 200)
                .build();
        client.createIndex(CreateIndexReq.builder()
                .collectionName(collectionName)
                .indexParam(indexParam)
                .build());
    }
}

五、Collection 3: `gitHistoryDiffHunk`

5.1 字段定义

字段名	类型	是否向量	说明	索引
`id`	INT64	否	自增主键	主键
`diffId`	VARCHAR(512)	否	diff 块唯一标识（`{commitHash}:{filePath}:{startLine}`）	INVERTED
`commitHash`	VARCHAR(40)	否	所属 commit hash	INVERTED
`filePath`	VARCHAR(1024)	否	所属文件路径	INVERTED
`repoId`	VARCHAR(128)	否	仓库标识（分区键）	INVERTED
`changeType`	VARCHAR(16)	否	`add` / `delete` / `modify`	INVERTED
`commitTime`	INT64	否	所属 commit 的时间戳（冗余，便于时间过滤）	INVERTED
`newCode`	VARCHAR(4096)	否	变更后的代码片段（可截断）	无
`embedding`	FLOAT_VECTOR(1536)	✅	语义向量（基于 `newCode` + `changeType`）	HNSW（COSINE）

5.2 Java 创建代码

public class CreateDiffHunkCollection {
    public static void create(MilvusClientV2 client, String collectionName) {
        CreateCollectionReq.CollectionSchema schema = client.createSchema();
        schema.addField(DataType.Int64, "id", true, true);
        schema.addField(DataType.VarChar, "diffId", 512, false);
        schema.addField(DataType.VarChar, "commitHash", 40, false);
        schema.addField(DataType.VarChar, "filePath", 1024, false);
        schema.addField(DataType.VarChar, "repoId", 128, false).setPartitionKey(true);
        schema.addField(DataType.VarChar, "changeType", 16, false);
        schema.addField(DataType.Int64, "commitTime", false);
        schema.addField(DataType.VarChar, "newCode", 4096, false);
        schema.addField(DataType.FloatVector, "embedding", 1536, false);

        client.createCollection(CreateCollectionReq.builder()
                .collectionName(collectionName)
                .collectionSchema(schema)
                .build());

        // 标量索引
        for (String field : Arrays.asList("diffId", "commitHash", "filePath", "repoId", "changeType", "commitTime")) {
            client.createIndex(CreateIndexReq.builder()
                    .collectionName(collectionName)
                    .fieldName(field)
                    .indexType(IndexParam.IndexType.INVERTED)
                    .build());
        }

        // 向量索引
        IndexParam indexParam = IndexParam.builder()
                .fieldName("embedding")
                .indexType(IndexParam.IndexType.HNSW)
                .metricType(IndexParam.MetricType.COSINE)
                .extraParam("M", 16)
                .extraParam("efConstruction", 200)
                .build();
        client.createIndex(CreateIndexReq.builder()
                .collectionName(collectionName)
                .indexParam(indexParam)
                .build());
    }
}

六、Collection 4: `gitHistoryMethod`

6.1 字段定义

字段名	类型	是否向量	说明	索引
`id`	INT64	否	自增主键	主键
`methodId`	VARCHAR(512)	否	函数唯一标识（`{fileId}:{name}:{startLine}`）	INVERTED
`methodName`	VARCHAR(256)	否	函数名	INVERTED
`fileId`	VARCHAR(512)	否	所属文件 ID	INVERTED
`filePath`	VARCHAR(1024)	否	所属文件路径	INVERTED
`repoId`	VARCHAR(128)	否	仓库标识（分区键）	INVERTED
`commitHash`	VARCHAR(40)	否	最近修改该函数的 commit hash	INVERTED
`signature`	VARCHAR(1024)	否	函数签名	无
`bodySnippet`	VARCHAR(4096)	否	函数体代码片段（截断）	无
`language`	VARCHAR(32)	否	编程语言	INVERTED
`updateTime`	INT64	否	解析时间戳	INVERTED
`embedding`	FLOAT_VECTOR(1536)	✅	语义向量（基于 `signature + bodySnippet`）	HNSW（COSINE）

6.2 Java 创建代码

public class CreateMethodCollection {
    public static void create(MilvusClientV2 client, String collectionName) {
        CreateCollectionReq.CollectionSchema schema = client.createSchema();
        schema.addField(DataType.Int64, "id", true, true);
        schema.addField(DataType.VarChar, "methodId", 512, false);
        schema.addField(DataType.VarChar, "methodName", 256, false);
        schema.addField(DataType.VarChar, "fileId", 512, false);
        schema.addField(DataType.VarChar, "filePath", 1024, false);
        schema.addField(DataType.VarChar, "repoId", 128, false).setPartitionKey(true);
        schema.addField(DataType.VarChar, "commitHash", 40, false);
        schema.addField(DataType.VarChar, "signature", 1024, false);
        schema.addField(DataType.VarChar, "bodySnippet", 4096, false);
        schema.addField(DataType.VarChar, "language", 32, false);
        schema.addField(DataType.Int64, "updateTime", false);
        schema.addField(DataType.FloatVector, "embedding", 1536, false);

        client.createCollection(CreateCollectionReq.builder()
                .collectionName(collectionName)
                .collectionSchema(schema)
                .build());

        // 标量索引
        for (String field : Arrays.asList("methodId", "methodName", "fileId", "filePath", 
                                          "repoId", "commitHash", "language", "updateTime")) {
            client.createIndex(CreateIndexReq.builder()
                    .collectionName(collectionName)
                    .fieldName(field)
                    .indexType(IndexParam.IndexType.INVERTED)
                    .build());
        }

        // 向量索引
        IndexParam indexParam = IndexParam.builder()
                .fieldName("embedding")
                .indexType(IndexParam.IndexType.HNSW)
                .metricType(IndexParam.MetricType.COSINE)
                .extraParam("M", 16)
                .extraParam("efConstruction", 200)
                .build();
        client.createIndex(CreateIndexReq.builder()
                .collectionName(collectionName)
                .indexParam(indexParam)
                .build());
    }
}

七、向量生成策略汇总

表	输入内容	生成说明
`gitHistoryCommit`	`summary` = `message` + `" modified: "` + 文件路径列表	调用 embedding 模型（如 OpenAI）
`gitHistoryFile`	`description` = `filePath` + `" language:"` + `language` + 可选的主要类/函数名列表	同上
`gitHistoryDiffHunk`	`newCode` + `" type:"` + `changeType`	截取前 4096 字符，避免超长
`gitHistoryMethod`	`signature` + `"\n"` + `bodySnippet`	截取前 4096 字符

八、Java 插入数据示例（以 `gitHistoryCommit` 为例）

import io.milvus.v2.service.vector.request.InsertReq;
import java.util.*;

public class InsertCommit {
    public static void insert(MilvusClientV2 client, String collectionName) {
        List<Map<String, Object>> rows = new ArrayList<>();
        Map<String, Object> row = new HashMap<>();
        row.put("commitHash", "abc123");
        row.put("repoId", "myorg/myrepo");
        row.put("authorTime", 1700000000L);
        row.put("summary", "fix: 登录超时处理，修改了 auth.py");
        row.put("embedding", generateEmbedding("fix: 登录超时处理，修改了 auth.py")); // 1536维向量
        rows.add(row);
        
        InsertReq insertReq = InsertReq.builder()
                .collectionName(collectionName)
                .data(rows)
                .build();
        client.insert(insertReq);
    }
}

九、总结

4 张表覆盖提交、文件、diff 块、函数四个粒度，满足不同层次的语义检索需求。
冗余字段：repoId（分区键）、commitTime（在 diff 表中）、updateTime 等，支持高效过滤。
索引完备：标量字段使用 INVERTED 索引，向量字段使用 HNSW（COSINE）。
Java SDK 2.6.13 兼容的 API 风格（使用 MilvusClientV2、CreateCollectionReq 等）。

此设计可直接用于批量解析脚本的向量入库逻辑。

参考资料

chat
参考资料

代码知识库之 git history-05-memgraph 图数据库

Fri, 03 Apr 2026 13:01:55 +0000

chat

背景

现在。站在批量定时解析的角度。希望实体可以是 gitHistory 开头

给出整个流程中，涉及到的图数据库中需要的实体、实体的关系。每个实体的属性、索引。

设计

图数据库实体与关系设计（GitHistory 前缀，含冗余字段）

所有实体标签以 GitHistory 开头，关系类型以大写字母+下划线命名。
冗余字段（标注 🔴）用于加速常见查询，避免多跳遍历。

一、实体（节点）

1. `GitHistoryCommit`（提交节点）

属性	类型	说明	索引
`hash`	string	完整 commit SHA（40 字符）	唯一索引
`shortHash`	string	前 7 位 SHA	普通索引
`message`	string	原始提交信息	无
`authorName`	string	作者名	普通索引
`authorEmail`	string	作者邮箱	无
`authorTime`	datetime	ISO 8601 格式	范围索引
`committerName`	string	提交者名	无
`committerTime`	datetime	提交时间	无
`isMerge`	boolean	是否为合并提交	普通索引
`parentHashes`	list[string]	父提交的 hash 列表	无
`branch`	string	所在分支（默认 `main`）	普通索引
`summary`	string	LLM 生成的 1-2 句摘要	无（向量存 Milvus）
🔴 `repoId`	string	所属仓库的唯一标识（如 `org/repo`）	普通索引（高频过滤）

冗余说明：repoId 使得多仓库场景下可以直接按仓库过滤，无需通过额外的 GitHistoryRepo 节点关联。

2. `GitHistoryFile`（文件节点）

属性	类型	说明	索引
`path`	string	文件在当前仓库中的绝对路径	唯一索引（与 `repoId` 联合）
`previousPath`	string	若文件被重命名，记录上一次的路径	普通索引
`language`	string	编程语言（如 `python`, `java`）	普通索引
`size`	integer	文件大小（字节），最后一次解析时的值	无
🔴 `lastCommitHash`	string	最后一次修改该文件的 commit hash	普通索引（用于快速获取最新版本）
🔴 `repoId`	string	所属仓库标识（与 `GitHistoryCommit.repoId` 一致）	普通索引

冗余说明：

lastCommitHash 避免查询“哪个 commit 最后改了该文件”时需要遍历所有 COMMIT_MODIFIES_FILE 关系再排序。
repoId 便于跨仓库隔离，且与 commit 的 repoId 保持一致。

3. `GitHistoryDiffHunk`（差异块节点）

属性	类型	说明	索引
`id`	string	唯一 ID（如 `{commitHash}:{filePath}:{startLine}`）	唯一索引
`oldStartLine`	integer	变更前起始行号	无
`oldLineCount`	integer	变更前总行数	无
`newStartLine`	integer	变更后起始行号	无
`newLineCount`	integer	变更后总行数	无
`oldCode`	string	变更前的代码片段（截断至 500 字符）	无
`newCode`	string	变更后的代码片段（截断至 500 字符）	无
`changeType`	string	枚举：`add`, `delete`, `modify`	普通索引
🔴 `commitHash`	string	所属 commit 的 hash（冗余）	普通索引
🔴 `filePath`	string	所属文件路径（冗余）	普通索引

冗余说明：commitHash 和 filePath 使得查询“某 commit 下的所有 diff hunk”或“某文件的所有 diff hunk”时不需要通过关系边，直接属性过滤即可。

4. `GitHistoryFunction`（函数/方法节点）

属性	类型	说明	索引
`id`	string	唯一 ID（如 `{filePath}:{name}:{startLine}`）	唯一索引
`name`	string	函数名（匿名函数生成 `__anonymous__{hash}`）	普通索引
`signature`	string	函数签名（尽力提取）	无
`startLine`	integer	函数起始行号	无
`endLine`	integer	函数结束行号	无
`language`	string	编程语言	普通索引
`bodyHash`	string	函数体内容的哈希（用于检测相同代码）	普通索引
🔴 `fileId`	string	所属文件的 ID（即 `GitHistoryFile.id`，值为 `{repoId}:{path}`）	普通索引
🔴 `filePath`	string	所属文件路径（冗余，便于展示）	普通索引
🔴 `repoId`	string	所属仓库标识	普通索引

冗余说明：

fileId 直接指向文件节点，避免通过 FUNCTION_LOCATED_IN_FILE 关系查询。
filePath 和 repoId 用于快速过滤和展示，减少关联查询。

二、关系（边）

关系类型	起始节点	结束节点	属性	说明
`COMMIT_CONTAINS_DIFFHUNK`	`GitHistoryCommit`	`GitHistoryDiffHunk`	`order` (integer)	提交包含 diff 块
`DIFFHUNK_CHANGES_FUNCTION`	`GitHistoryDiffHunk`	`GitHistoryFunction`	`impactType` (string: `added`, `removed`, `modified`)	diff 块影响了哪个函数
`COMMIT_MODIFIES_FILE`	`GitHistoryCommit`	`GitHistoryFile`	无	提交修改了该文件
`FUNCTION_LOCATED_IN_FILE`	`GitHistoryFunction`	`GitHistoryFile`	无	函数定义在文件中（冗余字段已提供快速访问，但保留关系用于图遍历）
`FUNCTION_CALLS_FUNCTION`	`GitHistoryFunction`	`GitHistoryFunction`	`callSite` (string)	函数调用关系（静态分析）
`COMMIT_INTRODUCES_FUNCTION`	`GitHistoryCommit`	`GitHistoryFunction`	`firstAppearance` (boolean)	提交首次引入该函数（可选）

注意：即使添加了冗余字段，关系边依然保留，因为图遍历和路径查询（如“从 commit 到 function 的路径”）仍依赖关系。冗余字段仅用于单节点属性过滤或直接获取关联信息，避免多跳。

三、索引汇总（Neo4j Cypher）

// GitHistoryCommit 索引
CREATE CONSTRAINT FOR (c:GitHistoryCommit) REQUIRE c.hash IS UNIQUE;
CREATE INDEX FOR (c:GitHistoryCommit) ON (c.shortHash);
CREATE INDEX FOR (c:GitHistoryCommit) ON (c.authorTime);
CREATE INDEX FOR (c:GitHistoryCommit) ON (c.branch);
CREATE INDEX FOR (c:GitHistoryCommit) ON (c.repoId);          // 🔴 冗余字段索引

// GitHistoryFile 索引
CREATE CONSTRAINT FOR (f:GitHistoryFile) REQUIRE (f.repoId, f.path) IS UNIQUE;
CREATE INDEX FOR (f:GitHistoryFile) ON (f.previousPath);
CREATE INDEX FOR (f:GitHistoryFile) ON (f.language);
CREATE INDEX FOR (f:GitHistoryFile) ON (f.lastCommitHash);   // 🔴 冗余字段索引
CREATE INDEX FOR (f:GitHistoryFile) ON (f.repoId);

// GitHistoryDiffHunk 索引
CREATE CONSTRAINT FOR (d:GitHistoryDiffHunk) REQUIRE d.id IS UNIQUE;
CREATE INDEX FOR (d:GitHistoryDiffHunk) ON (d.changeType);
CREATE INDEX FOR (d:GitHistoryDiffHunk) ON (d.commitHash);    // 🔴 冗余字段索引
CREATE INDEX FOR (d:GitHistoryDiffHunk) ON (d.filePath);

// GitHistoryFunction 索引
CREATE CONSTRAINT FOR (fn:GitHistoryFunction) REQUIRE fn.id IS UNIQUE;
CREATE INDEX FOR (fn:GitHistoryFunction) ON (fn.name);
CREATE INDEX FOR (fn:GitHistoryFunction) ON (fn.bodyHash);
CREATE INDEX FOR (fn:GitHistoryFunction) ON (fn.fileId);      // 🔴 冗余字段索引
CREATE INDEX FOR (fn:GitHistoryFunction) ON (fn.filePath);
CREATE INDEX FOR (fn:GitHistoryFunction) ON (fn.repoId);

// 关系索引（可选，加速特定路径）
CREATE INDEX FOR ()-[r:COMMIT_CONTAINS_DIFFHUNK]-() ON (r.order);
CREATE INDEX FOR ()-[r:DIFFHUNK_CHANGES_FUNCTION]-() ON (r.impactType);

四、冗余字段维护策略

实体	冗余字段	维护时机	更新方式
`GitHistoryCommit.repoId`	仓库标识	插入 commit 时	由解析脚本根据配置的仓库名直接写入，不随历史改变
`GitHistoryFile.lastCommitHash`	最后一次修改的 commit	每次处理新 commit 时	若该 commit 修改了某文件，则更新该文件的 `lastCommitHash` 为当前 commit.hash（按时间顺序，保留最新）
`GitHistoryFile.repoId`	仓库标识	插入文件节点时	与 commit.repoId 保持一致
`GitHistoryDiffHunk.commitHash`	所属 commit	创建 diff hunk 时	直接写入当前正在处理的 commit.hash
`GitHistoryDiffHunk.filePath`	所属文件路径	创建 diff hunk 时	从 diff 上下文中获取文件路径
`GitHistoryFunction.fileId`	所属文件 ID	创建函数节点时	由文件路径生成 ID（格式 `{repoId}:{path}`），若文件节点已存在则直接使用
`GitHistoryFunction.filePath`	所属文件路径	创建函数节点时	直接写入
`GitHistoryFunction.repoId`	仓库标识	创建函数节点时	从所属文件继承

一致性保证：

全量构建时，按拓扑顺序处理 commit，确保 lastCommitHash 最终指向时间最近的提交。
增量更新时，对于旧文件的 lastCommitHash 若新提交的时间更新，则覆盖。
若文件被删除后重建，lastCommitHash 会指向重建时的最新提交。

五、查询示例（利用冗余字段）

查询某仓库下所有 commit

MATCH (c:GitHistoryCommit {repoId: "myorg/myrepo"}) RETURN c

获取文件的最新修改 commit 信息（无需关系）

MATCH (f:GitHistoryFile {path: "src/main.py"})
MATCH (c:GitHistoryCommit {hash: f.lastCommitHash})
RETURN f, c

查找某个函数所在文件的路径（直接读属性）

MATCH (fn:GitHistoryFunction {id: "myorg/myrepo:src/auth.py:login"})
RETURN fn.filePath, fn.fileId

查询某 commit 的所有 diff hunk（利用冗余 commitHash）

MATCH (d:GitHistoryDiffHunk {commitHash: "abc123"}) RETURN d

六、设计总结

命名统一：GitHistory 前缀，冗余字段用普通属性存储，无需特殊前缀。
冗余字段选择：覆盖最常见的查询模式（按仓库过滤、按文件查最新提交、按 commit 查 diff、按函数查文件），避免多跳。
索引覆盖：对所有冗余字段建立索引，保证查询性能。
维护成本：增量更新时需同步更新冗余字段，但换来查询效率的大幅提升，适合读多写少的场景。

此设计可直接用于批量解析脚本的图入库逻辑。

参考资料

chat
参考资料

代码知识库之 git history-05-skills 文件 → 提交（功能意图聚类）

Fri, 03 Apr 2026 13:01:55 +0000

chat

背景

现在我们来按照目前的 skills 技能 markdown 保证来写两个技能：

1）一个功能涉及到历史的哪些文件（文件函数）。功能点-》提交==》文件  

2）一个文件被哪些提交（功能代你）修改？    

分别给出这两个 skills，和后端接口的交互用 python 调用 后端的 http 接口。

技能2

名字

第二个技能：文件 → 提交（功能意图聚类）

文件 1：`skills/git-history-file-to-commits/skill.md`

---
name: git-history-file-to-commits
description: 查询指定文件被哪些提交修改过，并对这些提交的意图（功能、修复、重构等）进行自动聚类。
version: 1.0.0
author: system
command: python3 scripts/file_to_commits.py --file-path "$FILE_PATH" --limit ${LIMIT:-20} --cluster-intents ${CLUSTER_INTENTS:-true} --include-functions ${INCLUDE_FUNCTIONS:-true}
input_schema:
  - name: file_path
    type: string
    required: true
    description: 文件在仓库中的路径，例如 "src/auth/login.py"
  - name: limit
    type: integer
    required: false
    default: 20
    description: 最多返回多少条提交，最大 100
  - name: cluster_intents
    type: boolean
    required: false
    default: true
    description: 是否对提交意图进行聚类
  - name: include_functions
    type: boolean
    required: false
    default: true
    description: 是否同时返回每个提交修改了该文件中的哪些函数
output:
  type: json
  description: 包含提交列表、意图聚类结果以及修改的函数清单
---

# Git History: File → Commits (with Intent Clustering)

## 使用场景

当开发者需要了解某个文件的变更历史时，使用本技能。它可以回答：
- 这个文件为什么频繁变动？
- 谁在什么时候改过这个文件？目的是什么？
- 该文件的修改主要分为哪几类（新功能、修复、重构）？
- 最近一次重大变更是什么？

## 核心逻辑

1. 调用后端接口 `/api/v1/file/{file_path}/commits`，获取修改过该文件的所有提交（按时间倒序）。
2. 若 `include_functions` 为 true，对每个提交调用 `/api/v1/commit/{hash}/functions`，并过滤出属于当前文件的函数。
3. 若 `cluster_intents` 为 true，调用 `/api/v1/commit/cluster`，将提交列表按 commit message 的主题聚类。
4. 返回结构化的 JSON 供 LLM 或用户分析。

## 使用示例

**输入**：
```json
{
  "file_path": "src/auth/login.py",
  "limit": 20,
  "cluster_intents": true,
  "include_functions": true
}

输出（节选）：

{
  "file_path": "src/auth/login.py",
  "total_commits": 8,
  "commits": [
    {
      "hash": "def456",
      "message": "feat: 支持 OAuth 2.0 登录",
      "author": "alice",
      "time": "2025-02-10T10:00:00Z",
      "modified_functions": [
        {"id": "func_oauth", "name": "authenticate_oauth", "signature": "def authenticate_oauth(token: str) -> User"}
      ]
    },
    {
      "hash": "abc123",
      "message": "fix: 登录超时后自动刷新 token",
      "author": "bob",
      "time": "2025-01-20T14:30:00Z",
      "modified_functions": [
        {"id": "func_login", "name": "login", "signature": "def login(username: str, password: str) -> Optional[User]"}
      ]
    }
  ],
  "intent_clusters": [
    {
      "label": "新功能",
      "commits": ["def456", "789ghi"]
    },
    {
      "label": "Bug修复",
      "commits": ["abc123", "jkl012"]
    }
  ]
}

注意事项

后端服务地址默认为 http://localhost:8080，可通过环境变量 GIT_HISTORY_BACKEND 覆盖。
若文件已被重命名，后端应自动通过 previous_path 链回溯历史路径，确保查询完整。
聚类功能基于 commit message 的简单 NLP（TF-IDF + K-means），若后端未实现，脚本会跳过聚类并返回 clustering_skipped 标记。

依赖

Python 3.8+
httpx、tenacity 库（已在脚本中导入，需提前安装） ```

文件 2：`skills/git-history-file-to-commits/scripts/file_to_commits.py`

#!/usr/bin/env python3
"""
Git History Skill: File → Commits (with Intent Clustering)
调用后端 HTTP 接口，查询修改过指定文件的所有提交，并进行意图聚类。
"""

import argparse
import json
import os
import sys
from typing import Dict, Any, List

import httpx
from tenacity import retry, stop_after_attempt, wait_exponential

# ---------- 配置 ----------
DEFAULT_BACKEND = "http://localhost:8080"
BACKEND_URL = os.environ.get("GIT_HISTORY_BACKEND", DEFAULT_BACKEND)
TIMEOUT = 30.0

# ---------- 后端接口调用（带重试） ----------
class BackendClient:
    def __init__(self, base_url: str):
        self.base_url = base_url.rstrip('/')
        self.client = httpx.Client(timeout=TIMEOUT)

    @retry(stop=stop_after_attempt(3), wait=wait_exponential(multiplier=1, min=1, max=5))
    def _get(self, endpoint: str) -> Dict:
        resp = self.client.get(f"{self.base_url}{endpoint}")
        resp.raise_for_status()
        return resp.json()

    @retry(stop=stop_after_attempt(3), wait=wait_exponential(multiplier=1, min=1, max=5))
    def _post(self, endpoint: str, json_data: Dict) -> Dict:
        resp = self.client.post(f"{self.base_url}{endpoint}", json=json_data)
        resp.raise_for_status()
        return resp.json()

    def get_file_commits(self, file_path: str, limit: int) -> Dict:
        """返回 {"commits": [{"hash": str, "message": str, "author": str, "time": str}]}"""
        return self._get(f"/api/v1/file/{file_path}/commits?limit={limit}")

    def get_commit_functions(self, commit_hash: str) -> Dict:
        """返回 {"functions": [{"function_id": str, "name": str, "file_path": str, "signature": str}]}"""
        return self._get(f"/api/v1/commit/{commit_hash}/functions")

    def cluster_commits(self, commits: List[Dict]) -> Dict:
        """返回 {"clusters": [{"label": str, "commits": [str]}]}"""
        payload = {"commits": [{"hash": c["hash"], "message": c["message"]} for c in commits]}
        return self._post("/api/v1/commit/cluster", payload)


def run(file_path: str, limit: int = 20, cluster_intents: bool = True, include_functions: bool = True) -> Dict[str, Any]:
    client = BackendClient(BACKEND_URL)

    # 1. 获取修改该文件的所有提交
    try:
        commits_data = client.get_file_commits(file_path, limit)
    except Exception as e:
        return {"error": f"Failed to fetch commits for file {file_path}: {e}", "file_path": file_path}

    commits = commits_data.get("commits", [])
    result = {
        "file_path": file_path,
        "total_commits": len(commits),
        "commits": commits
    }

    # 2. 若需要获取函数信息，逐个提交查询并过滤
    if include_functions and commits:
        for commit in result["commits"]:
            commit_hash = commit["hash"]
            try:
                func_data = client.get_commit_functions(commit_hash)
                all_functions = func_data.get("functions", [])
                # 只保留属于当前文件的函数
                file_functions = [
                    {
                        "id": f["function_id"],
                        "name": f["name"],
                        "signature": f.get("signature", "")
                    }
                    for f in all_functions
                    if f.get("file_path") == file_path
                ]
                commit["modified_functions"] = file_functions
            except Exception as e:
                commit["modified_functions"] = []
                commit["functions_error"] = str(e)

    # 3. 意图聚类
    if cluster_intents and len(commits) > 1:
        try:
            cluster_result = client.cluster_commits(commits)
            result["intent_clusters"] = cluster_result.get("clusters", [])
        except Exception as e:
            result["intent_clusters"] = []
            result["clustering_error"] = str(e)
    elif cluster_intents:
        result["intent_clusters"] = []
        result["clustering_skipped"] = "Not enough commits to cluster (<=1)"

    return result


def main():
    parser = argparse.ArgumentParser(description="查询文件被哪些提交修改，并进行意图聚类")
    parser.add_argument("--file-path", required=True, help="文件在仓库中的路径")
    parser.add_argument("--limit", type=int, default=20, help="最多返回的提交数量，默认20")
    parser.add_argument("--cluster-intents", action="store_true", default=True, help="是否对提交意图进行聚类")
    parser.add_argument("--no-cluster-intents", dest="cluster_intents", action="store_false", help="禁用聚类")
    parser.add_argument("--include-functions", action="store_true", default=True, help="是否包含修改的函数信息")
    parser.add_argument("--no-include-functions", dest="include_functions", action="store_false", help="不包含函数信息")
    args = parser.parse_args()

    try:
        output = run(
            file_path=args.file_path,
            limit=args.limit,
            cluster_intents=args.cluster_intents,
            include_functions=args.include_functions
        )
        print(json.dumps(output, indent=2, ensure_ascii=False))
        sys.exit(0)
    except Exception as e:
        error_output = {"error": str(e), "file_path": args.file_path}
        print(json.dumps(error_output), file=sys.stderr)
        sys.exit(1)


if __name__ == "__main__":
    main()

参考资料

chat
参考资料

代码知识库之 git history-04-skills git-history-feature-to-files

Fri, 03 Apr 2026 13:01:55 +0000

chat

背景

现在我们来按照目前的 skills 技能 markdown 保证来写两个技能：

1）一个功能涉及到历史的哪些文件（文件函数）。功能点-》提交==》文件  

2）一个文件被哪些提交（功能代你）修改？    

分别给出这两个 skills，和后端接口的交互用 python 调用 后端的 http 接口。你重点给出两个 skills 技能 markdown 文档

名字

明白了，我只给出第一个技能（功能点 → 提交 → 文件/函数）的完整内容。以下是两个文件：

文件 1：`skills/git-history-feature-to-files/skill.md`

---
name: git-history-feature-to-files
description: 根据自然语言功能描述或代码片段，检索 Git 历史中相关的提交，并列出这些提交修改过的文件及函数。
version: 1.0.0
author: system
command: python3 scripts/feature_to_files.py --query "$QUERY" --top_k ${TOP_K:-5} --include-source ${INCLUDE_SOURCE:-false}
input_schema:
  - name: query
    type: string
    required: true
    description: 功能描述或代码片段，例如“登录超时处理”
  - name: top_k
    type: integer
    required: false
    default: 5
    description: 返回的相关提交数量，最大 20
  - name: include_source
    type: boolean
    required: false
    default: false
    description: 是否同时返回函数的源码片段
output:
  type: json
  description: 包含相关提交、聚合的文件和函数列表的 JSON 对象
---

# Git History: Feature → Commits → Files/Functions

## 使用场景

当开发者需要了解某个功能（例如“用户登录”、“数据导出”）在代码库中的历史演变时，使用本技能。它可以回答：
- 这个功能第一次出现是哪个提交？
- 哪些文件/函数与该功能相关？
- 最近谁修改过这个功能相关的代码？

## 核心逻辑

1. 将输入的 `query` 发送给后端语义检索服务，获取最相似的 `top_k` 个提交。
2. 对每个提交，查询它修改过的文件和函数。
3. 聚合结果：同一文件/函数被多次修改时合并展示，并记录修改次数。
4. 若 `include_source` 为 true，额外获取每个函数的当前源码。
5. 输出 JSON 供 LLM 或用户分析。

## 使用示例

**输入**：
```json
{
  "query": "登录超时后自动刷新 token",
  "top_k": 5,
  "include_source": false
}

输出（节选）：

{
  "query": "登录超时后自动刷新 token",
  "related_commits": [
    {
      "hash": "abc123",
      "summary": "fix: 登录超时后自动刷新 token",
      "score": 0.94,
      "files": [
        {"path": "src/auth/token.py", "functions": [{"id": "func_01", "name": "refresh_token"}]}
      ]
    }
  ],
  "aggregated_files": {
    "src/auth/token.py": {
      "modify_count": 2,
      "functions": ["refresh_token", "validate_token"]
    }
  },
  "aggregated_functions": {
    "func_01": {
      "name": "refresh_token",
      "file_path": "src/auth/token.py",
      "modify_count": 2,
      "source_code": null
    }
  }
}

注意事项

后端服务地址默认为 http://localhost:8080，可通过环境变量 GIT_HISTORY_BACKEND 覆盖。
若后端不可用，脚本会重试 3 次后返回错误信息，不会阻塞调用。
为提高稳定性，建议在后端服务中开启缓存（Redis），减少重复查询。

依赖

Python 3.8+
httpx、tenacity 库（已在脚本中导入，需提前安装） ```

文件 2：`skills/git-history-feature-to-files/scripts/feature_to_files.py`

#!/usr/bin/env python3
"""
Git History Skill: Feature → Commits → Files/Functions
调用后端 HTTP 接口，根据功能描述检索相关提交及其修改的文件/函数。
"""

import argparse
import json
import os
import sys
from typing import Dict, Any, List

import httpx
from tenacity import retry, stop_after_attempt, wait_exponential

# ---------- 配置 ----------
DEFAULT_BACKEND = "http://localhost:8080"
BACKEND_URL = os.environ.get("GIT_HISTORY_BACKEND", DEFAULT_BACKEND)
TIMEOUT = 30.0

# ---------- 后端接口调用（带重试） ----------
class BackendClient:
    def __init__(self, base_url: str):
        self.base_url = base_url.rstrip('/')
        self.client = httpx.Client(timeout=TIMEOUT)

    @retry(stop=stop_after_attempt(3), wait=wait_exponential(multiplier=1, min=1, max=5))
    def _post(self, endpoint: str, json_data: Dict) -> Dict:
        resp = self.client.post(f"{self.base_url}{endpoint}", json=json_data)
        resp.raise_for_status()
        return resp.json()

    @retry(stop=stop_after_attempt(3), wait=wait_exponential(multiplier=1, min=1, max=5))
    def _get(self, endpoint: str) -> Dict:
        resp = self.client.get(f"{self.base_url}{endpoint}")
        resp.raise_for_status()
        return resp.json()

    def semantic_search(self, query: str, top_k: int) -> List[Dict]:
        """返回 [{"commit_hash": str, "score": float, "summary": str}]"""
        result = self._post("/api/v1/semantic_search", {"query": query, "top_k": top_k})
        return result.get("results", [])

    def get_commit_files(self, commit_hash: str) -> Dict:
        """返回 {"files": [{"path": str, "functions": [{"id": str, "name": str}]}]}"""
        return self._get(f"/api/v1/commit/{commit_hash}/files")

    def get_function_source(self, function_id: str) -> Dict:
        """返回 {"source_code": str, "file_path": str, "line_range": [int,int]}"""
        return self._get(f"/api/v1/function/{function_id}/source")


def run(query: str, top_k: int = 5, include_source: bool = False) -> Dict[str, Any]:
    client = BackendClient(BACKEND_URL)

    # 1. 语义检索相关提交
    commits_info = client.semantic_search(query, top_k)

    result = {
        "query": query,
        "related_commits": [],
        "aggregated_files": {},
        "aggregated_functions": {}
    }

    for commit in commits_info:
        commit_hash = commit["commit_hash"]
        try:
            commit_detail = client.get_commit_files(commit_hash)
        except Exception as e:
            # 单个提交失败不影响整体
            result["related_commits"].append({
                "hash": commit_hash,
                "summary": commit.get("summary", ""),
                "score": commit.get("score", 0.0),
                "error": str(e)
            })
            continue

        files = commit_detail.get("files", [])
        commit_entry = {
            "hash": commit_hash,
            "summary": commit.get("summary", ""),
            "score": commit.get("score", 0.0),
            "files": files
        }
        result["related_commits"].append(commit_entry)

        # 聚合文件及函数
        for file in files:
            path = file["path"]
            if path not in result["aggregated_files"]:
                result["aggregated_files"][path] = {"modify_count": 0, "functions": []}
            result["aggregated_files"][path]["modify_count"] += 1

            for func in file.get("functions", []):
                func_id = func["id"]
                func_name = func["name"]
                if func_id not in result["aggregated_functions"]:
                    result["aggregated_functions"][func_id] = {
                        "name": func_name,
                        "file_path": path,
                        "modify_count": 0,
                        "source_code": None
                    }
                result["aggregated_functions"][func_id]["modify_count"] += 1

                if func_name not in result["aggregated_files"][path]["functions"]:
                    result["aggregated_files"][path]["functions"].append(func_name)

    # 2. 可选获取函数源码
    if include_source:
        for func_id in list(result["aggregated_functions"].keys()):
            try:
                source_info = client.get_function_source(func_id)
                result["aggregated_functions"][func_id]["source_code"] = source_info.get("source_code", "")
            except Exception as e:
                result["aggregated_functions"][func_id]["source_code"] = f"// Error: {e}"

    return result


def main():
    parser = argparse.ArgumentParser(description="根据功能描述检索 Git 历史中的提交和文件")
    parser.add_argument("--query", required=True, help="功能描述或代码片段")
    parser.add_argument("--top_k", type=int, default=5, help="返回的相关提交数量，默认5")
    parser.add_argument("--include-source", action="store_true", help="是否包含函数源码")
    args = parser.parse_args()

    try:
        output = run(query=args.query, top_k=args.top_k, include_source=args.include_source)
        print(json.dumps(output, indent=2, ensure_ascii=False))
        sys.exit(0)
    except Exception as e:
        error_output = {"error": str(e), "query": args.query}
        print(json.dumps(error_output), file=sys.stderr)
        sys.exit(1)


if __name__ == "__main__":
    main()

参考资料

chat
参考资料

代码知识库之 git history-03-查询流程

Fri, 03 Apr 2026 13:01:55 +0000

chat

背景

另一个是用户使用，可能是 opencode 之类的 agent 使用时提供一个 skills。

现在给出在使用时的核心流程，为了保证稳定性，考虑 python 调用后端服务提供的 http 查询接口。

首先给出两个场景的查询流程：

1）一个功能涉及到历史的哪些文件（文件函数）。功能点-》提交==》文件  

2）一个文件被哪些提交（功能代你）修改？  

先给出查询的核心流程逻辑+流程图+重难点

回答

一、两个场景的核心查询流程

场景1：功能点 → 提交 → 文件/函数

用户输入：自然语言描述（如“登录时的 token 刷新逻辑”）或一段代码片段。
目标：找出历史上与这个功能相关的所有提交，以及这些提交修改的文件/函数。

flowchart TD
    A["用户输入"] --> B["语义检索 /semantic_search"]
    B --> C["Milvus: Top-K Commit"]
    C --> D["获取 Commit Files"]
    D --> E["图数据库: File & Function"]
    E --> F["结构化聚合"]
    F --> G["函数详情补充（可选）"]
    G --> H["LLM 分析"]

详细步骤：

Skill 接收功能描述（字符串或代码片段）。
语义检索：调用 POST /api/v1/semantic_search，参数 query 和 top_k=10。后端将 query 向量化，在 Milvus 的 commit_embeddings 集合中检索，返回相似度最高的 commit hash 列表（附带相似度分数）。
获取提交详情：对每个 commit hash，调用 GET /api/v1/commit/{hash}/files。后端从图数据库（Neo4j）查询该 commit 关联的 File 节点和 Function 节点（通过 Commit→Contains→DiffHunk→Changes→Function 路径）。
聚合与去重：Skill 合并多个 commit 的结果，按文件路径去重，并记录每个文件/函数被修改的次数。
（可选）获取函数源码：若需要具体代码，调用 GET /api/v1/function/{function_id}/source 获取该函数的完整实现（当前最新版本或历史版本）。
构造 prompt：将 commit message、文件路径列表、函数签名列表（及可选源码）整理为结构化文本，交给 LLM 分析。

场景2：文件 → 提交（功能意图）

用户输入：文件路径（如 src/auth/login.java）或当前打开文件的路径。
目标：找出修改过该文件的所有提交，并按功能意图聚类（例如“修复 NPE”、“增加 OAuth 支持”）。

flowchart TD
    A[用户指定文件路径] --> B[Skill 调用后端 /file/commits]
    B --> C[后端：从图DB查询所有修改该文件的 Commit 节点<br/>按时间倒序]
    C --> D[后端返回 commit 列表：hash, message, author, time]
    D --> E[Skill 调用后端 /commit/semantic_cluster<br/>（可选）对 commit message 做聚类]
    E --> F[Skill 输出：<br/>每个提交的意图摘要 + 关联的其他文件/函数]
    F --> G[LLM 分析变更模式]

详细步骤：

Skill 获取文件路径（可从 IDE 当前焦点获得）。
查询提交历史：调用 GET /api/v1/file/{file_path}/commits?limit=20。后端在图数据库中执行查询：MATCH (c:Commit)-[:MODIFIES]->(f:File {path: $path}) RETURN c ORDER BY c.time DESC。
扩展查询（可选）：如果该文件已被重命名，后端需先通过 File 节点的 previous_path 链找到所有历史路径，再统一查询。
语义聚类：若返回的 commit 数量多（>5），Skill 可调用 /api/v1/commit/cluster，后端使用简单的 TF-IDF + K-means 或直接调用 LLM 对 commit message 进行主题聚类，输出几个功能簇（如“性能优化”、“Bug修复”、“新特性”）。
关联影响面：对每个关键 commit，可进一步调用 /api/v1/commit/{hash}/functions 获取该提交修改的函数，从而看出“修改这个文件的同时还动了哪些其他文件/函数”。
返回给 LLM：展示提交列表（按时间或聚类），附带每个提交的 message、修改的函数列表，让 LLM 总结该文件的演化规律。

二、后端 HTTP 接口设计（供 Skill 调用）

端点	方法	参数	返回
`/api/v1/semantic_search`	POST	`{"query": str, "top_k": int}`	`[{"commit_hash": str, "score": float, "summary": str}]`
`/api/v1/commit/{hash}/files`	GET	`hash`	`{"files": [{"path": str, "functions": [{"id": str, "name": str}]}]}`
`/api/v1/file/{path}/commits`	GET	`path`, `limit`	`[{"hash": str, "message": str, "author": str, "time": str}]`
`/api/v1/commit/{hash}/functions`	GET	`hash`	`[{"function_id": str, "name": str, "file_path": str, "signature": str}]`
`/api/v1/function/{id}/source`	GET	`id` (可选参数 `commit_hash` 指定历史版本)	`{"source_code": str, "file_path": str, "line_range": [start,end]}`
`/api/v1/commit/cluster`	POST	`{"commits": [{"hash": str, "message": str}]}`	`{"clusters": [{"label": str, "commits": [hash]}]}`

所有接口返回 JSON，错误时返回 {"error": msg} 及 HTTP 状态码。

三、Skill 侧的稳定调用策略（Python）

由于 Skill 运行在 opencode agent 环境中，需要保证健壮性：

import httpx
from tenacity import retry, stop_after_attempt, wait_exponential

class GitHistorySkill:
    def __init__(self, base_url="http://localhost:8080"):
        self.client = httpx.Client(timeout=30.0, limits=httpx.Limits(max_keepalive_connections=5))

    @retry(stop=stop_after_attempt(3), wait=wait_exponential(multiplier=1, min=1, max=10))
    def semantic_search(self, query, top_k=5):
        try:
            resp = self.client.post(f"{self.base_url}/api/v1/semantic_search", json={"query": query, "top_k": top_k})
            resp.raise_for_status()
            return resp.json()
        except Exception as e:
            # 降级：返回空列表并记录日志
            print(f"Semantic search failed: {e}")
            return []

    def get_commits_for_file(self, file_path, limit=20):
        # 类似实现，带重试和超时
        ...

降级策略：

若向量检索服务不可用，Skill 可降级为基于 commit message 的关键词匹配（本地 grep 仓库的 git log --grep）。
若图数据库查询超时，返回部分结果并提示“历史记录不完整”。

四、重难点与解决方案

难点	原因	解决方案
1. 功能点描述的语义歧义	用户说“登录功能”，可能对应多个不同命名（`login`, `signin`, `authenticate`）	- 向量检索时同时使用 commit message + diff 摘要，提高召回。 - 在 Skill 中增加二次精排：用 LLM 对检索到的 commit 列表进行相关性打分（仅对 top-20 做一次小模型调用）。
2. 文件重命名导致历史断裂	文件路径变了，但 `/file/{path}/commits` 只查当前路径，丢失旧记录	- 后端维护 `File` 节点的 `previous_path` 链，查询时自动回溯所有曾用名。 - 或者在入库时，将所有 commit 关联的 File 节点都归一化到最终路径（通过 `git log --follow` 确定）。
3. 大量提交返回，token 爆炸	一个文件可能有几百次提交，全部返回给 LLM 不可行	- Skill 端默认只返回最近 10 条，并提供分页参数。 - 支持时间范围过滤（如 `?since=2025-01-01`）。 - 对 message 做聚类，每个簇只展示代表提交。
4. 提交中修改的函数跨多个文件	一个提交改了 5 个文件 20 个函数，但用户只关心当前文件	- 接口 `/commit/{hash}/files` 默认只返回该提交影响的所有文件和函数，由 Skill 按当前文件过滤。 - 增加参数 `?filter_file=path` 仅返回与指定文件相关的函数。
5. 实时性 vs 资源消耗	每次查询都实时从图 DB 拉取数据，高并发下压力大	- 后端加 Redis 缓存：对 `file/commits` 和 `commit/files` 结果缓存 5 分钟。 - 对于语义检索，使用 Milvus 自身的高并发能力，无需额外缓存。
6. 跨分支查询	默认分支的历史可能不包含某个功能第一次引入的分支提交	- 在入库时只处理默认分支（`main`），但可以通过 `git branch --contains <commit>` 识别出那些最终合并到默认分支的提交（即 `git log --first-parent` 能看到的）。 - 若用户需要全部分支历史，需在接口中增加 `?branch=all` 参数，后端动态从仓库解析。

五、流程图（纯文本版）

场景1 流程

[用户] --> "修复登录超时问题" (自然语言)
          |
          v
[Skill] --> POST /semantic_search
          |
          v
[Backend] --> 向量检索 Milvus --> 返回 ["abc123", "def456"]
          |
          v
[Skill] --> GET /commit/abc123/files --> {files: ["auth.py"], functions: ["login", "refresh_token"]}
[Skill] --> GET /commit/def456/files --> {files: ["auth.py", "utils.py"], functions: ["validate"]}
          |
          v
[Skill] --> 聚合结果，构造 prompt:
          "相关提交: abc123 (修复 token 过期), 修改了 auth.py 中的 login() 和 refresh_token()
                     def456 (增加超时重试), 修改了 utils.py 中的 validate()"
          |
          v
[LLM]   --> 分析：login() 的历史变更集中在 token 刷新逻辑...

场景2 流程

[用户] --> 当前文件 "src/auth/login.py"
          |
          v
[Skill] --> GET /file/src/auth/login.py/commits?limit=10
          |
          v
[Backend] --> 图DB查询 --> 返回 10 个 commit（按时间倒序）
          |
          v
[Skill] --> POST /commit/cluster (对 message 聚类)
          |
          v
[Backend] --> 返回聚类: ["OAuth 支持" (2个commit), "Bug修复" (5个commit), "性能优化" (3个commit)]
          |
          v
[Skill] --> 对每个簇选择代表 commit，调用 /commit/abc123/functions 获取修改函数
          |
          v
[Skill] --> 输出给 LLM:
          "login.py 近一年主要有三类修改:
           1. OAuth 支持 (2025-02-10): 增加了 authenticate_oauth()，修改了 login()
           2. Bug修复 (2025-01-20): 修复了空指针异常，影响 get_user()
           ..."

六、总结

核心思路：Skill 作为轻量级编排层，通过 HTTP 调用后端服务获取结构化历史数据，避免在 agent 内部处理复杂的图查询和向量检索。
稳定性保障：重试、超时、降级、缓存。
扩展性：接口设计以 commit hash 和函数 ID 为纽带，可逐步增加更多分析能力（如影响面扩散、代码变更模式挖掘）。

参考资料

chat
- 背景
回答
参考资料

代码知识库之 git history-02-解析落库的核心流程

Fri, 03 Apr 2026 13:01:55 +0000

chat

背景

我想把整个流程拆分为2个部分：一个是解析落库的部分。

另一个是用户使用，可能是 opencode 之类的 agent 使用时提供一个 skills。

让我们一步步来，先给我解析落库的核心流程+重难点+流程图

回答

一、解析落库核心流程

解析落库模块的目标：将 Git 仓库的历史变更转化为结构化的图数据 + 向量索引，供上层 Skills 实时查询。

1.1 整体流程（一次全量/增量运行）

flowchart TD
    A[开始] --> B{首次运行?}
    B -->|是| C[获取近一年所有commit<br/>按拓扑排序]
    B -->|否| D[获取上次处理后新commit<br/>+ 检测reflog变动]
    
    C --> E[逐commit处理]
    D --> E
    
    E --> F[解析commit元信息<br/>hash, message, author, time]
    F --> G[获取该commit的diff列表<br/>git show --unified=0]
    G --> H{对每个文件的diff}
    
    H --> I[定位diff中的代码块<br/>（hunk头 + 行号范围）]
    I --> J[使用语言解析器<br/>识别hunk所属的函数/类/符号]
    J --> K[构建图节点和边<br/>Commit→DiffHunk→Function]
    
    K --> L{是否最后一个文件?}
    L -->|否| H
    L -->|是| M[为该commit生成语义摘要<br/>（可选，用LLM或规则）]
    
    M --> N[将Commit节点存入图DB]
    N --> O[将Commit摘要向量化<br/>存入Milvus]
    O --> P[将DiffHunk中的代码片段<br/>向量化存入Milvus]
    P --> Q{是否最后一个commit?}
    Q -->|否| E
    Q -->|是| R[更新增量检查点<br/>记录最后处理的commit hash]
    R --> S[结束]

1.2 关键子流程详解

① 增量检测与历史一致性

常规增量：记录 last_commit_time 和 last_commit_hash，下次执行 git log --since=last_time 获取新 commit（按时间顺序）。
处理改写历史：定期（如每天）对比 git reflog 中 default branch 的 commit 列表，若发现已存储的 commit 不在当前 reflog 中，标记为 ORPHANED 并删除其相关图数据。

② 从 diff hunk 定位到函数/类

输入：git diff --unified=0 输出的 hunk 头，例如 @@ -10,7 +10,8 @@ def foo():
过程：
1. 解析 hunk 头中的新旧行号范围。
2. 获取 commit 前后的完整文件内容（通过 git show commit:path）。
3. 对前后内容分别进行语法分析（AST），找出覆盖这些行号的最内层语法节点（函数、类、方法）。
4. 若节点未命名（如匿名函数），生成 anon_func_{hash}_{line} 标识。
输出：Function / Class 节点，属性包括：name, signature, start_line, end_line, file_path, language。

③ 构建图关系

节点类型：Commit, File, DiffHunk, Function, Class, Symbol
边类型：
- (:Commit)-[:CONTAINS]->(:DiffHunk)
- (:DiffHunk)-[:CHANGES]->(:Function) (表示该 hunk 影响了这个函数)
- (:Commit)-[:MODIFIES]->(:File)
- (:Function)-[:LOCATED_IN]->(:File)
- 静态关系（可选，但强烈建议）：(:Function)-[:CALLS]->(:Function)，通过额外的一次全量代码扫描获得。

④ 向量化与存储

向量模型：推荐 codebert 或 voyage-2（代码专用），或用 OpenAI text-embedding-3-small。
Milvus Collection 设计：
- commit_embeddings：字段 commit_hash, summary_text（由 message + 变更文件列表生成）, embedding
- diffhunk_embeddings：字段 diff_id, code_snippet（新代码部分）, embedding

图数据库：Neo4j，为加速查询创建索引：

CREATE INDEX FOR (c:Commit) ON (c.hash);
CREATE INDEX FOR (f:Function) ON (f.name, f.file_path);

二、重难点与解决方案

难点	原因	解决方案
1. 函数边界识别跨语言	不同语言的 AST 差异大，且 diff 可能只改动函数中间几行	使用 Tree-sitter 作为统一解析库（支持 Python/Java/Go/Rust/JS 等），根据语言加载对应语法。对于无法解析的行，降级为“文件级”关系。
2. 文件重命名/移动	`git diff` 默认不跟踪重命名，会导致函数归属错误	使用 `git log --follow` 获取文件重命名历史；在图数据库中维护 `File` 节点的 `previous_path` 属性，查询时自动沿路径回溯。
3. 大仓库性能	近一年可能有几万个 commit，逐个解析 diff 和 AST 耗时长	- 并行处理 commit（注意保证拓扑顺序仅用于依赖，可分组并行） - 缓存文件内容的 AST（同一文件在不同 commit 间复用解析结果） - 使用增量模式，只处理新 commit。
4. 合并提交的噪音	merge commit 的 diff 通常很大且包含大量无关变更	策略：默认跳过 merge commit（只处理普通 commit），但保留对 `--first-parent` 历史的主干追踪。若需要合并信息，单独标记 `MergeCommit` 节点并关联两个父分支的最后公共祖先。
5. 向量存储的实时性	每次增量后需更新 Milvus，但删除已废弃 commit 的向量较麻烦	- 不在 Milvus 中物理删除，而是在图 DB 中标记 `is_active=false`，检索时过滤掉。 - 定期（每周）重建一次 Milvus collection 以清理孤儿向量。
6. 代码片段长度控制	diff hunk 可能很大（如整个文件重写），导致 embedding 超过模型限制	- 截断：保留 hunk 中前后各 30 行上下文，若超出 512 token 则只取变更行附近。 - 对超大 hunk，不直接 embedding，而是用 LLM 生成 1-2 句摘要再 embedding。

三、输出给下一阶段（Skills）的数据接口

解析落库完成后，对外提供两种查询接口（可以是 REST 或本地函数调用）：

3.1 图查询接口

# 输入：当前文件路径 + 函数名（或行号）
# 输出：该函数的历史变更记录（commit 列表 + diff 片段）
get_function_history(file_path, function_name, limit=10)

# 输入：commit hash
# 输出：该 commit 影响的所有函数及对应的 diff 片段
get_commit_details(commit_hash)

3.2 向量检索接口

# 输入：一段代码或自然语言描述
# 输出：Top-K 相似的 diff 片段 或 commit 摘要
vector_search(query_text, collection="diffhunk_embeddings", top_k=5)

3.3 变更影响面分析

# 输入：一个函数节点 ID
# 输出：历史上与该函数同时被修改的其他函数（共现变更） + 调用链上的下游函数
get_impacted_functions(function_id, depth=2)

这些接口将被 Skills 调用，用于在编程时动态获取上下文。

四、流程图（纯文本版，便于嵌入文档）

+------------------+      +-------------------+      +-----------------+
|  Git Repository  |----->|  Incremental      |----->|  Parse Commit   |
|  (local clone)   |      |  Commit Fetcher   |      |  (git show)     |
+------------------+      +-------------------+      +--------+--------+
                                                              |
                                                              v
+------------------+      +-------------------+      +--------+--------+
|  Neo4j (Graph)   |<-----|  AST Parser       |<-----|  Diff Hunk      |
|  + Milvus (Vec)  |      |  (Tree-sitter)    |      |  Splitting      |
+------------------+      +-------------------+      +-----------------+
        ^                                                        |
        |                                                        v
        +--------------------------------------------------------+
                          (Store nodes & edges)

五、落地第一步建议

如果当前资源有限，可以先实现 最小可行产品（MVP）：

仅支持 一种语言（如 Python）的 AST 解析。
只处理 默认分支，忽略分支合并逻辑。
图数据库用 SQLite + 自定义关系表 代替 Neo4j（简单，但查询复杂）。
向量库用 Chroma（轻量级，无需单独部署）。
增量更新只依赖 git log --since，暂不处理 rebase 导致的历史变动。

验证目标：能否回答“当前函数 login() 在过去一年中被修改过几次？每次修改影响了哪些其他函数？” 如果可行，再逐步增强。

参考资料

chat
- 背景
回答
参考资料

代码知识库之 git history-01-概览

Fri, 03 Apr 2026 13:01:55 +0000

chat

背景

我想在想设计一个 git history 方案。 

通过代码仓库的 git log 提交历史，然后在编程的时候，提供一个 skills（可以理解每一个文件和变更之间的隐形的知识关系，先让 LLM 理解）。

我大概的思路是定时扫描仓库近一年的 git history，初次全量，后续增量。 

然后构建git histiry 的提交与文件的图数据关系，额外加上 mivlus 向量库对提交的语义检索。 

使用时，可以通过语义检索---》拿到提交--》拿到文件？ 

然后让 LLM 分析这些文件？

你作为一名资深架构师，评价下这个流程，然后给出更好更加可行的方案。

回答

一、对你当前方案的评价

你的核心思路——定时拉取 Git 历史 → 构建提交‑文件关系图 + 向量库 → 语义检索后喂给 LLM——方向是对的，利用了版本控制中隐含的“变更共现”“意图描述”等宝贵信息。但作为一个可落地的工程方案，存在以下几个关键缺陷：

粒度太粗
Commit → File 只能知道“某次提交改了某文件”，但不知道文件内部的函数/类/代码块层面的关联。很多隐形知识（比如“这个 bug 修复只改了函数 A，却导致函数 B 出问题”）需要看到具体 diff hunk 甚至调用关系。
上下文爆炸
一次语义检索可能返回多个提交，每个提交又关联多个文件。直接把这些文件完整内容丢给 LLM，token 消耗巨大，且大量无关代码会稀释关键信息。
忽略分支与合并语义
近一年的历史包含大量 feature 分支、merge commit。如果不区分主干和分支的演化路径，单纯的“提交‑文件”图会丢失代码的“真实意图”和“稳定版本”边界。
缺少代码结构的静态关系
单纯依赖提交历史无法捕捉函数调用、类继承、依赖注入等静态结构。而这些正是 LLM 理解“修改影响范围”所必需的上下文。
增量更新不完整
定时扫描简单粗暴，但无法感知 git rebase、amend、force push 等改写操作，会导致图数据与真实历史不一致。

二、更可行的整体架构（增强版）

2.1 核心目标

建立一个 “代码时空知识图谱”，让 LLM 能够：

给定当前文件/光标位置，检索历史上相关的变更意图（为什么这么写）
找到可能受影响的远端代码（跨文件/跨函数）
控制上下文大小，只给 LLM 最精华的代码片段 + 变更说明

2.2 数据模型（节点与边）

节点类型	说明	示例
`Commit`	提交节点，含 hash、message、时间、作者	`commit#abc123`
`File`	文件路径（跟踪重命名）	`src/auth/login.py`
`Function` / `Method`	函数/方法签名 + 起始行号	`UserService.authenticate()`
`Class`	类名 + 文件范围	`LoginHandler`
`DiffHunk`	一次提交中一个文件的一个变更块（±行号，原代码+新代码）	`@@ -10,7 +10,8 @@`
`Symbol`	变量/常量/宏定义等	`MAX_RETRY`

关键边关系：

Commit –MODIFIES–> File
Commit –CONTAINS–> DiffHunk
DiffHunk –CHANGES–> Function / Class / Symbol
（通过解析 diff 前后代码，识别受影响的代码元素）
Function –CALLS–> Function （静态分析获得）
Class –INHERITS–> Class
File –IMPORTS–> File
Commit –FIXES–> Issue（可选，连接 issue tracker）

2.3 数据采集与增量更新

全量初始化：
克隆仓库，遍历近一年所有提交（git rev-list --since="1 year ago"）。按拓扑顺序处理（先父后子），构建图。
增量策略：
使用 Git Hook（post-receive 或客户端 post-commit）触发更新，而不是盲目定时扫描。
对于 rebase 等操作，利用 git reflog 检测已处理 commit 的消失，进行图清理。
跨分支处理：
只对默认分支（main/master） 和最近活跃的 release 分支建立全量关系。对其他特性分支，仅在需要时按 commit 范围动态加载。

2.4 语义向量化（Milvus 使用）

对以下三类内容分别嵌入，存入不同 collection：

内容类型	嵌入来源	检索用途
`Commit`	commit message + diff 的语义摘要（用一个小 LLM 生成 1‑2 句话）	用户问“之前谁处理过登录超时问题？”
`DiffHunk`	变更前后的代码片段 + 变更意图（从 message 继承）	检索“类似这个函数的修改历史”
`Function` / `Class`	签名 + 注释 + 代码结构（AST 简化）	找功能相似的代码单元

检索增强：
用户当前编辑位置 → 提取附近函数/类 → 用其签名向量去 Milvus 检索相似的 Function 或 DiffHunk → 返回 top‑K 结果。

2.5 与 LLM 交互的精炼流程

不是“检索提交 → 拿文件 → 全给 LLM”，而是：

上下文提取：当前文件 + 光标所在函数/类 + 最近编辑行
图查询：
- 该函数历史上被哪些 Commit 修改过？
- 这些 Commit 还修改了哪些其他 File / Function（共现变更）？
- 通过静态调用边，找到该函数调用了哪些外部函数。
向量检索：
- 用当前函数签名检索相似的 Function 节点（跨文件）。
- 用当前代码片段检索相关的 DiffHunk（寻找类似变更模式）。
上下文裁剪：
- 只取出检索到的 DiffHunk 中的新代码片段（几十行），不取整个文件。
- 对关联函数的代码，只提取其签名 + 前 5 行注释/实现。
- 将 commit message 作为“为什么改”的说明。

组装 prompt：

[当前文件 + 光标位置]
[历史相关变更]：commit #a 改了函数 foo()，因为“修复 NPE”；改动如下：<diff>
[相似函数参考]：文件 bar.py 中的函数 baz() 实现了类似逻辑：<签名+头几行>
[可能影响的其他代码]：函数 foo() 调用了 util.check()，该函数近期被 commit #b 修改过...

总 token 控制在 4k 以内（可根据模型调整）。

2.6 存储与查询引擎

图数据库：Neo4j 或 JanusGraph。
用于快速遍历 “Commit → DiffHunk → Function → Call → Function” 等路径。
向量数据库：Milvus 或 Qdrant。
存储 embedding 并支持相似检索。
代码解析：
- Python 用 ast，Java 用 javaparser，Go 用 go/parser。
- 解析后建立符号表，识别函数/类/调用关系。
变更识别：
对每个 diff，用 git diff --unified=0 获取精确行号，再用解析器判断该行号属于哪个语法节点（函数/类）。

三、与你的方案对比

维度	你的方案	增强方案
粒度	提交 → 文件	提交 → diff块 → 函数/类/符号
静态关系	无	调用图、继承图、导入图
检索依据	仅 commit message	commit message + diff 语义 + 代码结构
LLM 输入	整个文件	精准的 diff 片段 + 关键函数签名
更新方式	定时扫描全量	Git hook + reflog 增量
分支处理	忽略	默认分支为主，特性分支按需加载

四、落地建议（渐进式）

如果你的资源有限，可以分阶段实现：

Phase 1（快速验证）

只收集默认分支的 commit + file 关系。
对每个 commit，用 LLM 生成一个“一句话摘要”存入 Milvus。
检索时返回相关 commit 的摘要及修改的文件列表，再由 LLM 根据当前文件内容自主决定是否请求 diff。
优点：实现简单，1 周内可跑通。

Phase 2（核心价值）

增加 diff 解析和函数识别（先支持一种语言，如 Python）。
构建简单的调用关系（正则匹配 import 和 函数名(）。
用图数据库存储函数级关系。

Phase 3（完整系统）

支持多语言符号解析。
全量图 + 向量库，使用 Git hook 增量更新。
集成到 IDE 插件中，实现实时代码辅助。

五、一句话总结

你的思路是良好的起点，但要真正让 LLM 理解“隐形知识”，必须将粒度细化到函数/代码块级别，并融合静态调用关系。

建议采用 “提交 → diff 块 → 受影响的语法节点” 的图模型，配合向量语义检索，最后对 LLM 做精炼的上下文投喂，才能在不爆炸 token 的前提下提供有价值的编程辅助。

参考资料

chat
- 背景
回答
参考资料

Bun-02-为什么要有？

Fri, 03 Apr 2026 13:01:55 +0000

Bun 为什么存在，本质是 Node.js 技术栈“结构性问题”的反作用。

我不给你泛泛讲优缺点，直接从架构层痛点 → Bun 对应解法来拆。

一、Node.js 技术栈的核心痛点

先明确一点： Node.js 本身不是问题，问题在“生态拼装模式”。

1️⃣ 工具链碎片化（最致命）

一个典型 Node 项目：

Node.js + npm + webpack/vite + babel + jest + ts-node + eslint + ...

问题是：

工具之间：
- 配置割裂
- 版本冲突
- 插件地狱
每个工具：
- 都有自己的生态和 DSL

👉 实际体验：

你不是在写业务，而是在“调工具链”

Bun 的解法

Bun 直接做了这件事：

一个 runtime = install + build + test + run

👉 核心思想：

减少组合，增加内建

2️⃣ 性能问题（不是小问题，是结构问题）

npm / Node 的慢，本质来自：

JS 实现 package manager
node_modules 递归解析
IO 模型低效
冷启动慢（V8 初始化）

👉 你应该深有体会：

npm install 很慢
CLI 启动慢
serverless 冷启动差

Bun 的解法

Zig 实现（绕开 JS）
JavaScriptCore（启动更快）
aggressive caching

👉 不是优化，是换了一套底层实现

3️⃣ TypeScript 支持是“外挂”

Node 世界：

TS = tsc + ts-node + babel + loader

问题：

编译链复杂
sourcemap 问题
调试体验差

Bun 的解法

bun run index.ts

👉 原生执行 TS

本质是：

把 TS 当“一等公民”

4️⃣ Web API 支持不统一

Node 历史问题：

没有 fetch（后来才补）
WebSocket 不统一
Request/Response 不标准

👉 Node 和浏览器是“两套世界”

Bun 的解法

直接内置：

fetch / Request / Response / WebSocket

👉 设计理念：

向浏览器对齐，而不是历史兼容

5️⃣ node_modules 体系的历史包袱

npm 的核心问题：

依赖树膨胀
磁盘占用巨大
路径解析复杂

Bun 的解法

更激进缓存
减少重复安装
优化解析路径

👉 类似：

pnpm 思路，但更极端

6️⃣ 运行时职责过于单一

Node 的哲学是：

“只做 runtime，其他交给生态”

这带来问题：

没有标准构建方案
没有标准测试工具
没有标准工程结构

Bun 的解法

直接定义：

标准 test runner
标准 bundler
标准项目执行方式

👉 类似：

Go / Rust 的开发体验

二、为什么要“再搞一套”

这才是关键问题，本质是：

👉 Node 无法“进化”，只能“兼容”

Node 的约束：

必须兼容 20 年生态
不能随便改 API
不能推翻 node_modules
不能破坏 npm

👉 结果就是：

历史包袱锁死架构演进

👉 Bun 的本质是“重新设计一遍”

可以理解为：

Node.js v2（但不能叫 Node）

它做的事情：

重写 runtime（不是基于 Node）
重写 package manager
重写工具链

👉 类似历史案例：

技术	替代关系
Python 2 → 3	不兼容重来
AngularJS → Angular	重写
Java 8 → Kotlin	生态替代
Node → Bun	同一思路

三、你从架构角度应该怎么理解

你现在在做：

自动化测试平台
AI 系统
工具链平台

其实正好踩在 Bun 的甜点区。

Node 模式（旧范式）

运行时 + 工具链 + 脚本执行 = 拼装

Bun 模式（新范式）

运行时 = 平台（Platform）

👉 这点非常关键：

Bun 更像一个“应用执行平台”，而不是 JS runtime

四、但为什么还不能替代 Node

必须客观说一句：

1️⃣ 生态护城河

npm：

数百万包
企业依赖深
CI/CD 深度绑定

2️⃣ 稳定性要求

企业系统关注：

可预测行为
长期支持（LTS）
兼容性

👉 Bun 目前：

仍在快速演进
存在 edge case

3️⃣ 心智成本

换 Bun 意味着：

重学工具链
重构部分代码
承担风险

五、一句话总结（本质结论）

Bun 不是“优化 Node”，而是“绕开 Node 的历史包袱，重新设计 JavaScript 运行时”

六、给你的架构建议（重点）

结合你的背景，我给一个更实用的判断：

如果你在做“平台型系统”

👉 强烈建议：

用 Bun 做“执行层”

比如：

测试流程执行引擎
AI Agent runtime
插件系统

如果你在做“业务系统”

👉 建议：

继续 Node / Java

最优解（你这个级别建议用）

Core System（稳定） → Java / Node
Execution Layer（高性能） → Bun

参考资料

一、Node.js 技术栈的核心痛点
二、为什么要“再搞一套”
- 👉 Node 无法“进化”，只能“兼容”
- 👉 Bun 的本质是“重新设计一遍”
三、你从架构角度应该怎么理解
- Node 模式（旧范式）
- Bun 模式（新范式）
四、但为什么还不能替代 Node
五、一句话总结（本质结论）
六、给你的架构建议（重点）
参考资料

Bun-01-是什么？

Fri, 03 Apr 2026 13:01:55 +0000

一、Bun 是什么（重新定义一下）

Bun 本质不是“更快的 npm”，而是：

👉 一个试图替代整个 Node.js 工具链的运行时平台

它的目标是统一这几块：

Node.js + npm + webpack/vite + jest + ts-node

用一个工具直接覆盖。

二、核心架构（为什么它快）

1️⃣ 底层语言：Zig（关键）

Bun 几乎全部用 Zig 写
优点：
- 无 GC（避免 JS runtime 的性能损耗）
- 更贴近系统（IO / 内存控制更强）
- 编译产物更小、更快

👉 这点决定了：

Bun 是“系统级工具”，不是 JS 工具

2️⃣ JS 引擎：JavaScriptCore

Bun 使用的是：

Safari 的 JS 引擎（JavaScriptCore）

而不是 Node.js 用的：

V8（Chrome）

对比：

引擎	特点
V8	优化成熟，生态强
JavaScriptCore	启动快，占用低

👉 Bun选择 JSC 的原因：

冷启动极快（CLI 场景优势巨大）
内存占用更低

3️⃣ 内置模块设计（关键理念）

Bun不是“调用一堆库”，而是：

👉 把常用能力直接做进 runtime

例如：

HTTP server
fetch API
WebSocket
SQLite（内置数据库）
test runner
bundler

👉 类似：

Go / Rust 的标准库哲学

三、核心能力模块拆解

1️⃣ Runtime（替代 Node.js）

直接运行：

bun run index.ts

支持：

TypeScript（无需编译）
JSX / TSX
ESM 原生支持

内置 Web API（很关键）

fetch
Request / Response
WebSocket

👉 Node 是后补的，Bun 是原生设计

2️⃣ Package Manager（替代 npm / yarn / pnpm）

bun install

特点：

极快（并发 + 缓存）
几乎不重复下载
锁文件：bun.lockb

设计亮点：

类似 pnpm 的全局缓存
但更激进（更少磁盘 IO）

3️⃣ Bundler（替代 webpack / esbuild）

bun build index.ts

特点：

内置，无需配置
性能接近 esbuild
支持 TS / JSX

👉 适合：

小型服务
CLI 工具
SSR

4️⃣ Test Runner（替代 jest）

bun test

特点：

内置断言库
执行速度快
无需额外配置

5️⃣ SQLite（非常有意思）

Bun 内置 SQLite：

import { Database } from "bun:sqlite";

👉 这意味着：

可以直接写本地数据库应用
非常适合：
- CLI
- 本地工具
- AI Agent

四、性能为什么这么夸张

核心原因不是“优化”，而是架构重做：

1️⃣ 减少 JS 层

npm / Node：

JS逻辑 + JS解析 + JS执行

Bun：

Zig实现 → 更少 JS → 更少开销

2️⃣ IO 模型优化

并发下载依赖
aggressive caching
几乎不重复读写

3️⃣ 冷启动极快

适用于：

CLI
serverless
短生命周期任务

五、兼容性（你必须知道的坑）

Bun 的策略是：

👉 兼容 Node API，但不是完全一致

常见问题：

❌ Native 模块

node-gyp 编译的模块可能不支持

❌ 某些 Node 内部 API

如：
- fs edge cases
- process hooks

❌ 复杂生态工具

webpack plugin
一些 jest 插件

👉 总结：

80% 场景 OK，20% 会踩坑

六、和 Node.js 的本质差异

维度	Bun	Node.js
架构	一体化	组合式
性能	极致优化	稳定优先
工具链	内置	外挂
TS 支持	原生	需工具
生态	新	成熟

七、工程实践（重点）

结合你做平台 / 架构的背景，这里给你更“现实”的建议：

✅ 推荐用 Bun 的地方

1. 开发工具链

自动化测试平台执行器
CLI 工具
Dev Server

👉 非常适合你现在在做的“测试引擎”

2. AI / Agent 系统

本地推理工具
workflow 执行器
插件系统

👉 Bun + SQLite = 很强组合

3. BFF / 边缘服务

API gateway
SSR

⚠️ 混合架构（推荐）

核心业务：Node.js（稳定）
边缘能力：Bun（高性能）

👉 例如：

核心 IM 服务 → Node / Java
自动化脚本执行 → Bun
AI Agent → Bun

八、未来趋势（非常关键）

Bun 代表的是一种趋势：

👉 “重新做一遍 Node.js，但更现代”

类似的方向还有：

Deno（安全优先）
Bun（性能优先）

九、一句话总结

Bun = 高性能 + 一体化 + 现代化的 Node.js 替代方案

但：

它是未来，不完全是现在

参考资料

一、Bun 是什么（重新定义一下）
二、核心架构（为什么它快）
三、核心能力模块拆解
四、性能为什么这么夸张
五、兼容性（你必须知道的坑）
- 常见问题：
六、和 Node.js 的本质差异
七、工程实践（重点）
- ✅ 推荐用 Bun 的地方
- ⚠️ 混合架构（推荐）
八、未来趋势（非常关键）
九、一句话总结
参考资料

Git History 12 All In One

Fri, 03 Apr 2026 00:00:00 +0000

背景

通过代码仓库的 git log 提交历史，然后在编程的时候，提供一个 skills（可以理解每一个文件和变更之间的隐形的知识关系，先让 LLM 理解）。

思路是定时扫描仓库近一年的 git history，初次全量，后续增量。 

然后构建git histiry 的提交与文件的图数据关系，额外加上 mivlus 向量库对提交的语义检索。 

使用时，可以通过语义检索---》拿到提交--》拿到文件 

然后让 LLM 分析这些文件，分析对应的关系

核心流程

解析落库

解析落库模块的目标：将 Git 仓库的历史变更转化为结构化的图数据 + 向量索引，供上层 Skills 实时查询。

flowchart TD
    A[开始] --> B{首次运行?}
    B -->|是| C[获取近一年所有commit<br/>按拓扑排序]
    B -->|否| D[获取上次处理后新commit<br/>+ 检测reflog变动]
    
    C --> E[逐commit处理]
    D --> E
    
    E --> F[解析commit元信息<br/>hash, message, author, time]
    F --> G[获取该commit的diff列表<br/>git show --unified=0]
    G --> H{对每个文件的diff}
    
    H --> I[定位diff中的代码块<br/>（hunk头 + 行号范围）]
    I --> J[使用语言解析器<br/>识别hunk所属的函数/类/符号]
    J --> K[构建图节点和边<br/>Commit→DiffHunk→Function]
    
    K --> L{是否最后一个文件?}
    L -->|否| H
    L -->|是| M[为该commit生成语义摘要<br/>（可选，用LLM或规则）]
    
    M --> N[将Commit节点存入MemGraph]
    N --> O[将Commit摘要向量化<br/>存入Milvus]
    O --> P[将DiffHunk中的代码片段<br/>向量化存入Milvus]
    P --> Q{是否最后一个commit?}
    Q -->|否| E
    Q -->|是| R[更新增量检查点<br/>记录最后处理的commit hash]
    R --> S[结束]

查询流程

场景1：功能点 → 提交 → 文件/函数

flowchart TD
    A["用户输入"] --> B["语义检索 /semantic_search"]
    B --> C["Milvus: Top-K Commit"]
    C --> D["获取 Commit Files"]
    D --> E["图数据库: File & Function"]
    E --> F["结构化聚合"]
    F --> G["函数详情补充（可选）"]
    G --> H["LLM 分析"]

详细步骤：

Skill 接收功能描述（字符串或代码片段）。
语义检索：调用 POST /api/v1/semantic_search，参数 query 和 top_k=10。后端将 query 向量化，在 Milvus 的 commit_embeddings 集合中检索，返回相似度最高的 commit hash 列表（附带相似度分数）。
获取提交详情：对每个 commit hash，调用 GET /api/v1/commit/{hash}/files。后端从图数据库（Neo4j）查询该 commit 关联的 File 节点和 Function 节点（通过 Commit→Contains→DiffHunk→Changes→Function 路径）。
聚合与去重：Skill 合并多个 commit 的结果，按文件路径去重，并记录每个文件/函数被修改的次数。
（可选）获取函数源码：若需要具体代码，调用 GET /api/v1/function/{function_id}/source 获取该函数的完整实现（当前最新版本或历史版本）。
构造 prompt：将 commit message、文件路径列表、函数签名列表（及可选源码）整理为结构化文本，交给 LLM 分析。

场景2：文件 → 提交（功能意图）

flowchart TD
    A[用户指定文件路径] --> B[Skill 调用后端 /file/commits]
    B --> C[后端：从图DB查询所有修改该文件的 Commit 节点<br/>按时间倒序]
    C --> D[后端返回 commit 列表：hash, message, author, time]
    D --> E[Skill 调用后端 /commit/semantic_cluster<br/>（可选）对 commit message 做聚类]
    E --> F[Skill 输出：<br/>每个提交的意图摘要 + 关联的其他文件/函数]
    F --> G[LLM 分析变更模式]

详细步骤：

Skill 获取文件路径（可从 IDE 当前焦点获得）。
查询提交历史：调用 GET /api/v1/file/{file_path}/commits?limit=20。后端在图数据库中执行查询：MATCH (c:Commit)-[:MODIFIES]->(f:File {path: $path}) RETURN c ORDER BY c.time DESC。
扩展查询（可选）：如果该文件已被重命名，后端需先通过 File 节点的 previous_path 链找到所有历史路径，再统一查询。
语义聚类：若返回的 commit 数量多（>5），Skill 可调用 /api/v1/commit/cluster，后端使用简单的 TF-IDF + K-means 或直接调用 LLM 对 commit message 进行主题聚类，输出几个功能簇（如“性能优化”、“Bug修复”、“新特性”）。
关联影响面：对每个关键 commit，可进一步调用 /api/v1/commit/{hash}/functions 获取该提交修改的函数，从而看出“修改这个文件的同时还动了哪些其他文件/函数”。
返回给 LLM：展示提交列表（按时间或聚类），附带每个提交的 message、修改的函数列表，让 LLM 总结该文件的演化规律。

prompts.chat AI 对话模型 Prompt 示例集合

Thu, 02 Apr 2026 13:01:55 +0000

prompts.chat

这是什么？

一个精选整理的 AI 对话模型 Prompt 示例集合。最初为 ChatGPT 创建，这些 Prompt 同样适用于任何现代 AI 助手。

浏览 Prompt	数据格式
prompts.chat	prompts.csv
PROMPTS.md	Hugging Face 数据集

想要贡献？ 在 prompts.chat/prompts/new 添加 Prompt —— 会自动同步到这里。

📖 Prompt 工程交互式书籍

通过我们的 免费交互式指南 学习 Prompt 工程 —— 超过 25 个章节，涵盖从基础到高级技术（如思维链推理、Few-shot 学习、AI Agent）。

开始阅读 →

🎮 面向儿童的 Prompt 学习

一个互动式、游戏化的学习体验，通过有趣的谜题和故事，教会 8-14 岁儿童如何与 AI 沟通。

开始体验 →

🚀 自托管

部署你自己的私有 Prompt 库，支持自定义品牌、主题和认证。

快速开始：

npx prompts.chat new my-prompt-library
cd my-prompt-library

手动安装：

git clone https://github.com/f/prompts.chat.git
cd prompts.chat
npm install && npm run setup

安装向导会配置品牌、主题、认证（GitHub / Google / Azure AD）以及功能。

📖 完整自托管指南（SELF-HOSTING.md） • 🐳 Docker 指南（DOCKER.md）

🔌 集成

CLI

npx prompts.chat

Claude Code 插件

/plugin marketplace add f/prompts.chat
/plugin install prompts.chat@prompts.chat

📖 插件文档（CLAUDE-PLUGIN.md）

MCP Server

在你的 AI 工具中将 prompts.chat 作为 MCP 服务使用。

远程（推荐）：

{
  "mcpServers": {
    "prompts.chat": {
      "url": "https://prompts.chat/api/mcp"
    }
  }
}

本地：

{
  "mcpServers": {
    "prompts.chat": {
      "command": "npx",
      "args": ["-y", "prompts.chat", "mcp"]
    }
  }
}

📖 MCP 文档：https://prompts.chat/docs/api

💖 赞助商

（保持原内容不变，仅展示）

👥 贡献者

（贡献者列表）

📜 许可证

CC0 1.0 通用许可（公共领域） —— 可自由复制、修改、分发和使用，无需署名。

参考资料

prompts.chat
参考资料

TimesFM（Time Series Foundation Model，时间序列基础模型）是一个由 Google Research 开发的预训练时间序列基础模型，用于时间序列预测。

Thu, 02 Apr 2026 13:01:55 +0000

TimesFM

TimesFM（Time Series Foundation Model，时间序列基础模型）是一个由 Google Research 开发的预训练时间序列基础模型，用于时间序列预测。 ([GitHub][1])

论文：A decoder-only foundation model for time-series forecasting（ICML 2024）
所有模型权重：TimesFM Hugging Face Collection
Google Research 博客
TimesFM in BigQuery：Google 官方产品

该开源版本不是 Google 官方支持的产品。

最新模型版本：TimesFM 2.5

历史版本：

1.0 和 2.0：相关代码存放在 v1 子目录中你可以通过 pip install timesfm==1.3.0 安装旧版本

更新（Update - 2025-10-29）

为 TimesFM 2.5 重新加入了通过 XReg 的协变量（covariate）支持。

更新（Update - 2025-09-15）

发布 TimesFM 2.5

相比 TimesFM 2.0，新版本：

使用 2 亿参数（从 5 亿下降）
支持 最长 16k 上下文长度（从 2048 提升）
支持通过可选的 3000 万参数 quantile head 进行最长 1k horizon 的连续分位数预测
移除了 frequency 指示器
引入了一些新的预测参数（forecasting flags）

同时，推理 API 也进行了升级。该仓库将在接下来几周持续更新以：

支持即将发布的 Flax 版本（更快推理）
重新加入协变量支持
补充更多文档字符串（docstrings）、文档和 notebook

安装（Install）

克隆仓库：

git clone https://github.com/google-research/timesfm.git
cd timesfm

创建虚拟环境并使用 uv 安装依赖：

# 创建虚拟环境
uv venv

# 激活环境
source .venv/bin/activate

# 安装（PyTorch）
uv pip install -e .[torch]

# 或（Flax）
uv pip install -e .[flax]

# 或（需要 XReg）
uv pip install -e .[xreg]

（可选）根据你的系统和硬件（CPU / GPU / TPU / Apple Silicon）安装对应后端：

安装 PyTorch
安装 JAX（用于 Flax）

代码示例（Code Example）

import torch
import numpy as np
import timesfm

torch.set_float32_matmul_precision("high")

model = timesfm.TimesFM_2p5_200M_torch.from_pretrained(
    "google/timesfm-2.5-200m-pytorch"
)

model.compile(
    timesfm.ForecastConfig(
        max_context=1024,
        max_horizon=256,
        normalize_inputs=True,
        use_continuous_quantile_head=True,
        force_flip_invariance=True,
        infer_is_positive=True,
        fix_quantile_crossing=True,
    )
)

point_forecast, quantile_forecast = model.forecast(
    horizon=12,
    inputs=[
        np.linspace(0, 1, 100),
        np.sin(np.linspace(0, 20, 67)),
    ],  # 两个示例输入
)

point_forecast.shape      # (2, 12)
quantile_forecast.shape   # (2, 12, 10)：均值 + 10% 到 90% 分位数

额外说明（非 README 直译补充，帮助理解）

TimesFM 是一种 decoder-only Transformer 架构的时间序列基础模型 ([DeepWiki][2])
支持 zero-shot forecasting（零样本预测），无需针对特定数据集训练 ([DeepWiki][2])
重点解决：
- 长时间上下文预测
- 跨领域泛化
- 替代传统 ARIMA / LSTM 等模型

参考资料

TimesFM
参考资料

Codex 是一个云端软件工程 agent

Thu, 02 Apr 2026 13:01:55 +0000

Codex

Codex 是一个云端软件工程 agent。

它可以并行处理多个任务，例如编写功能代码、回答代码库相关问题、修复 bug，以及提出 pull request 供你审核。

工作方式（How it works）

当你向 Codex 分配任务时：

它会在一个隔离的云环境（sandbox）中运行
该环境已预加载你的代码库

Codex 可以：

读取和编辑文件
运行命令（例如测试、lint）
提交更改

每个任务都在独立环境中执行，从而避免相互影响。

核心能力（Capabilities）

代码生成（Code generation） —— 根据需求编写代码
代码理解（Code understanding） —— 分析现有代码库并回答问题
Bug 修复（Bug fixing） —— 定位并修复问题
自动化 PR（Pull Requests） —— 自动生成可审核的代码变更
多任务并行（Parallel tasks） —— 同时处理多个工程任务

使用方式（Usage）

你可以通过以下方式使用 Codex：

ChatGPT / Codex App
CLI（命令行工具）
SDK / API
IDE 集成（如 VS Code）

它通常作为一个coding agent（编程代理）存在，而不是简单的代码补全工具。

Agent 行为模型（Agent Model）

Codex 是一个agent 驱动系统，而不仅仅是一个模型：

接收任务（Task）
拆解步骤（Planning）
执行操作（Execution）
验证结果（Validation）
提交结果（Commit / PR）

这意味着它更接近：

👉 “自动软件工程师” 而不是传统的 autocomplete（自动补全）

与 Git 的交互（Git behavior）

Codex 在处理代码时遵循一些约束：

使用 Git 提交变更
保持工作区（worktree）干净
不修改已有提交
所有评估基于已提交代码

（这些规则通常由系统 prompt / AGENTS.md 控制） ([OpenAI][1])

AGENTS.md 机制

Codex 支持一种特殊文件：

AGENTS.md

作用：

提供项目级别的约束和说明
指导 agent 如何工作

例如：

代码规范
项目结构说明
测试执行方式
PR 提交规范

特点：

作用范围 = 当前目录及其子目录
多层嵌套时，更深层优先
用户指令优先级 > AGENTS.md

运行环境（Execution Environment）

Codex 的执行环境具有以下特性：

隔离（Sandboxed）
可控权限（Permission-scoped）
支持命令执行（Shell / CLI）
可访问代码仓库

这使其可以执行：

构建（build）
测试（test）
静态检查（lint）
数据处理脚本

安全模型（Security Model）

由于 Codex 可以执行代码：

需要限制 token 权限
需要隔离执行环境
避免 prompt injection / command injection

（现实中确实出现过相关漏洞案例） ([TechRadar][2])

与 Copilot 的关系

Codex 是底层能力之一
GitHub Copilot 使用类似模型提供代码补全
Codex 更偏向 Agent（执行任务）
Copilot 更偏向 IDE 辅助（补全） ([GitHub Docs][3])

总结（核心定位）

Codex 的本质是：

从 “写代码工具” → “执行工程任务的 AI Agent”

它解决的是：

自动开发（Auto Dev）
自动修复（Auto Fix）
自动提交（Auto PR）
自动理解代码库（Codebase Intelligence）

一句话理解

👉 Codex ≈ “会自己写代码 + 跑测试 + 提 PR 的 AI 工程师”

参考资料

Codex
参考资料

axios 基于 Promise 的 HTTP 客户端，用于浏览器和 Node.js

Thu, 02 Apr 2026 13:01:55 +0000

axios

基于 Promise 的 HTTP 客户端，用于浏览器和 Node.js

目录（Table of Contents）

功能（Features）
浏览器支持（Browser Support）
安装（Installing）
- 包管理器
- CDN
示例（Example）
Axios API
请求方法别名（Request method aliases）
并发（Concurrency 👎）
创建实例（Creating an instance）
实例方法（Instance methods）
请求配置（Request Config）
响应结构（Response Schema）
默认配置（Config Defaults）
- 全局 axios 默认配置
- 自定义实例默认配置
- 配置优先级顺序
拦截器（Interceptors）
- 多个拦截器
错误处理（Handling Errors）
超时处理（Handling Timeouts）
取消请求（Cancellation）
- AbortController
- CancelToken 👎
使用 application/x-www-form-urlencoded 格式
- URLSearchParams
- Query string
- 🆕 自动序列化
使用 multipart/form-data 格式
- FormData
- 🆕 自动序列化
文件上传（Files Posting）
HTML 表单提交（HTML Form Posting）
🆕 进度捕获（Progress capturing）
🆕 限速（Rate limiting）
🆕 AxiosHeaders
🔥 Fetch 适配器
- 🔥 自定义 fetch
  - 🔥 与 Tauri 一起使用
  - 🔥 与 SvelteKit 一起使用
🔥 HTTP2
语义化版本（Semver）
Promises
TypeScript
资源（Resources）
致谢（Credits）
许可证（License）

功能（Features）

浏览器请求：可直接在浏览器中发起 XMLHttpRequests 请求
Node.js 请求：可在 Node.js 环境中发起 http 请求
基于 Promise：完全支持 Promise API，便于编写异步代码
拦截器：可拦截请求和响应，添加自定义逻辑或转换数据
数据转换：自动转换请求和响应数据
请求取消：内置请求取消机制
自动 JSON 处理：自动序列化和解析 JSON 数据
表单序列化：🆕 自动将数据对象序列化为 multipart/form-data 或 x-www-form-urlencoded
XSRF 防护：提供客户端防跨站请求伪造支持 ([GitHub][1])

浏览器支持（Browser Support）

Chrome	Firefox	Safari	Opera	Edge
最新 ✔	最新 ✔	最新 ✔	最新 ✔	最新 ✔

安装（Installing）

使用包管理器（Package manager）

使用 npm：

npm install axios

使用 bower：

bower install axios

使用 yarn：

yarn add axios

使用 pnpm：

pnpm add axios

使用 bun：

bun add axios

安装完成后，你可以通过 import 或 require 引入：

import axios, {isCancel, AxiosError} from 'axios';

你也可以使用默认导出：

import axios from 'axios';

console.log(axios.isCancel('something'));

使用 require 时，仅支持默认导出：

const axios = require('axios');

console.log(axios.isCancel('something'));

对于某些 bundler 或 ES6 lint 工具，可能需要：

import { default as axios } from 'axios';

默认配置（Config Defaults）

你可以指定默认配置，它会应用到每个请求。

全局默认配置（Global axios defaults）

axios.defaults.baseURL = 'https://api.example.com';

// 注意：如果 axios 用于多个域名，该 AUTH_TOKEN 会发送到所有域
axios.defaults.headers.common['Authorization'] = AUTH_TOKEN;

axios.defaults.headers.post['Content-Type'] = 'application/x-www-form-urlencoded';

自定义实例默认配置（Custom instance defaults）

const instance = axios.create({

URLSearchParams

默认情况下，axios 会将 JavaScript 对象序列化为 JSON。如果你想使用 application/x-www-form-urlencoded：

const params = new URLSearchParams({ foo: 'bar' });
params.append('extraparam', 'value');

axios.post('/foo', params);

Query string（旧浏览器）

可以使用 qs 库：

const qs = require('qs');
axios.post('/foo', qs.stringify({ 'bar': 123 }));

或 ES6：

import qs from 'qs';

const data = { 'bar': 123 };
const options = {
  method: 'POST',
  headers: { 'content-type': 'application/x-www-form-urlencoded' },
};

使用 `multipart/form-data`

FormData

const formData = new FormData();
formData.append('foo', 'bar');

axios.post('https://httpbin.org/post', formData);

Node.js 示例：

const FormData = require('form-data');

const form = new FormData();
form.append('my_field', 'my value');
form.append('my_buffer', new Buffer(10));
form.append('my_file', fs.createReadStream('/foo/bar.jpg'));

axios.post('https://example.com', form);

🆕 自动序列化为 FormData

从 v0.27.0 开始，如果 Content-Type 为 multipart/form-data，axios 会自动将对象序列化为 FormData。

文件上传（Files Posting）

await axios.postForm('https://httpbin.org/post', {
  'myVar': 'foo',
  'file': document.querySelector('#fileInput').files[0]
});

多文件上传：

await axios.postForm('https://httpbin.org/post', {
  'files[]': document.querySelector('#fileInput').files
});

HTML 表单提交（HTML Form Posting）

await axios.postForm('https://httpbin.org/post', document.querySelector('#htmlForm'));

也可以作为 JSON 发送：

await axios.post('https://httpbin.org/post', document.querySelector('#htmlForm'), {
  headers: {
    'Content-Type': 'application/json'
  }
});

🆕 进度捕获（Progress capturing）

const {data, headers, status} = await axios.post('https://httpbin.org/post', form, {
  httpVersion: 2,
  http2Options: {},
  onUploadProgress(e) {
    console.log('upload progress', e);
  },
  onDownloadProgress(e) {
    console.log('download progress', e);
  },
  responseType: 'arraybuffer'
});

Promises

axios 依赖原生 ES6 Promise，如果环境不支持，需要 polyfill。

TypeScript

axios 内置 TypeScript 类型定义：

let user: User = null;

try {
  const { data } = await axios.get('/user?ID=12345');
  user = data.userDetails;
} catch (error) {
  if (axios.isAxiosError(error)) {
    handleAxiosError(error);
  } else {
    handleUnexpectedError(error);
  }
}

致谢（Credits）

axios 深受 AngularJS 的 $http 服务启发，本质目标是提供一个可在 Angular 之外使用的 $http 类库。

许可证（License）

MIT

参考资料

axios
参考资料

项目：TaxHacker 一个自托管的 AI 会计应用，用 LLM 自动分析发票、收据和交易数据

Wed, 01 Apr 2026 13:01:55 +0000

📦 项目：TaxHacker

🧠 一句话（翻译）

一个自托管的 AI 会计应用，用 LLM 自动分析发票、收据和交易数据 ([GitHub][1])

📌 项目定位（核心翻译）

TaxHacker 是一个面向：

自由职业者（freelancer）
独立开发者（indie hacker）
小型企业

的工具，用来：

自动化记账 + 报税准备 + 发票管理

🎯 解决的核心问题

👉 传统痛点：

手动录入收据（极其耗时）
多币种换算复杂
分类混乱
报税准备繁琐

👉 TaxHacker 的目标：

拍照 → AI解析 → 自动结构化 → 可导出报税

⚙️ 核心能力（翻译）

1️⃣ AI 发票/收据解析（最核心）

上传：

收据照片
发票 PDF
银行账单

系统会自动提取：

商家（merchant）
金额（amount）
日期（date）
商品明细（items）
税（tax）

并存入结构化数据库 ([GitHub][1])

✨ 关键能力

自动分类（Auto-categorization）
拆分明细（item splitting）
多语言识别（甚至手写）

👉 本质：

OCR + LLM 语义解析

2️⃣ 多币种 & 加密货币支持

支持：

170+ 法币
BTC / ETH 等加密货币

能力：

自动识别币种
按交易日期汇率转换（历史汇率） ([GitHub][1])

👉 这个点非常关键：

不用当前汇率，而是交易当天汇率（符合税务要求）

3️⃣ 完全自定义数据模型（非常重要）

你可以：

自定义字段（类似 Excel 列）
自定义分类（categories）
自定义项目（projects）

🔥 更强的是：

每个字段都可以绑定一个 AI Prompt

例如：

字段：风险评估
Prompt：这个发票是否可能被税务局拒绝？

👉 本质：

数据库字段 = AI 可计算字段

4️⃣ 可自定义 AI Prompt（核心亮点）

你可以修改：

系统 Prompt
字段 Prompt
分类规则

👉 甚至可以：

完全控制 AI 的行为

这点非常关键：

TaxHacker ≠ 固定产品 TaxHacker = 可编程 AI 会计系统

5️⃣ 数据过滤 & 导出

支持：

按时间 / 分类 / 项目过滤
全文搜索
CSV 导出
报税报告

👉 可直接交给会计师

6️⃣ 自托管（核心卖点）

本地部署（Docker）
数据完全私有
无厂商锁定

docker compose up

👉 本质：

你的财务数据 = 完全归你

🏗️ 技术架构（翻译）

技术栈

前端：Next.js 15+
数据库：PostgreSQL
ORM：Prisma
AI：OpenAI / Gemini / Mistral
PDF处理：Ghostscript / GraphicsMagick ([GitHub][1])

部署结构（Docker）

包含：

App 容器
PostgreSQL
持久化存储

核心数据流

上传文件
   ↓
AI解析（LLM）
   ↓
结构化数据（DB）
   ↓
过滤 / 导出 / 报表

🧠 核心设计思想（非常关键）

🔥 1️⃣ “AI + 结构化数据”的结合

不是简单 OCR：

传统：图片 → 文本
TaxHacker：图片 → 语义结构

🔥 2️⃣ 用户完全控制 AI

传统 SaaS：

AI 是黑盒

TaxHacker：

AI 是可配置系统

🔥 3️⃣ Excel 化数据模型

交易表 = 可扩展表结构

👉 非常像：

Airtable
Notion DB

但加了 AI

🔥 4️⃣ 自托管优先

目标用户：

技术人 / 独立开发者

👉 核心价值：

隐私
可控
可扩展

🚀 和传统工具的区别

维度	传统记账软件	TaxHacker
数据输入	手动	AI 自动
数据结构	固定	可自定义
AI能力	无/弱	强
可扩展性	低	极高
数据控制	SaaS	自托管

🧩 本质抽象（非常重要）

你可以这样理解：

TaxHacker = AI + 可配置数据表 + 工作流

或者更本质：

TaxHacker = 面向财务的 AI ETL 系统

🔥 Reddit 用户真实反馈（有价值）

“it saves me a lot of time and nerves” ([Reddit][2])

“I gave up paid bookkeeping” ([Reddit][2])

👉 说明：

对 freelancer 非常实用
可以替代部分会计服务

🚀 对你当前方向的价值（重点）

你在做：

IM + 推荐 + AI 根因分析平台

这个项目对你启发很大👇

🧠 1️⃣ “数据 + AI Prompt”模型

你可以直接套：

日志 / 报警
   ↓
AI解析（Prompt可配）
   ↓
结构化数据

👉 类似：

字段：root_cause
Prompt：分析根因

🧠 2️⃣ “用户可编程 AI”

TaxHacker：

用户定义 AI 行为

你可以做：

运维工程师定义分析规则（Prompt）

👉 这比写规则引擎更强：

更灵活
更快上线
更易迭代

🧠 3️⃣ “AI ETL”能力

TaxHacker 本质是：

非结构化数据 → AI → 结构化数据

你可以做：

日志 / Trace → AI → 根因数据

🧠 4️⃣ Skill + TaxHacker 思想融合

你之前看的：

Skills → SOP
Agent Lightning → 学习系统

这个项目补上：

👉 数据层

🧩 可以组合成完整体系：

Skill（规则）
 + TaxHacker（数据结构化）
 + Lightning（学习）

👉 = 可进化 AI 平台

🧩 一句话总结

TaxHacker 本质是：

一个“让 AI 参与数据结构化和业务建模”的通用平台（只是应用在财务场景）

参考资料

📦 项目：TaxHacker
- 🧠 一句话（翻译）
📌 项目定位（核心翻译）
🎯 解决的核心问题
⚙️ 核心能力（翻译）
🏗️ 技术架构（翻译）
🧠 核心设计思想（非常关键）
🚀 和传统工具的区别
🧩 本质抽象（非常重要）
🔥 Reddit 用户真实反馈（有价值）
🚀 对你当前方向的价值（重点）
🧩 一句话总结
参考资料

OpenMemory 为 AI 系统提供长期记忆能力。不是向量搜索，不是 RAG，而是“真正的记忆系统”。

Wed, 01 Apr 2026 13:01:55 +0000

OpenMemory

为 AI 系统提供长期记忆能力。不是向量搜索，不是 RAG，而是“真正的记忆系统”。 ([GitHub][1])

👉 自托管 / 本地优先 / 可解释 / 可扩展 👉 可以用“一行代码”为 Agent 增加记忆能力 ([GitHub][1])

核心定位（Introduction）

现代 LLM 存在的问题：

会话之间完全遗忘
向量数据库只是“平面 chunk”，缺乏：
- 时间维度
- 重要性
- 关系结构
云 memory API：
- 成本高
- Vendor lock-in

OpenMemory 提供的能力

持久记忆（persistent memory）
多层认知结构（multi-sector cognitive structure）
自然遗忘（decay）
基于图的召回（graph-based recall）
时间感知（time-aware）
可解释性（waypoint trace）
完全数据控制权（local-first）
MCP 协议集成 ([GitHub][1])

👉 本质定位： AI 的 Memory OS（记忆操作系统）

🚀 对比传统方案

传统方案（LangChain + Pinecone）：

复杂（10+ 行）
依赖云
初始化慢

OpenMemory：

from openmemory import OpenMemory

om = OpenMemory(...)
om.add("User allergic to peanuts")
om.query("allergies")

👉 仅 3 行代码 👉 本地 SQLite 👉 无云依赖 ([GitHub][1])

⚡ Standalone 模式

无需后端：

直接运行在 Node.js / Python 中
本地 SQLite 存储
数据不离开本机 ([GitHub][1])

🧠 核心设计：认知记忆模型

OpenMemory 不是“向量库”，而是类人脑结构

五大记忆类型（Multi-sector）

Episodic（情景记忆）→ 事件
Semantic（语义记忆）→ 知识
Procedural（程序记忆）→ 技能
Emotional（情绪记忆）→ 情感
Reflective（反思记忆）→ 元认知 ([GitHub][1])

👉 这是它和 RAG 最大的本质区别

🧩 架构核心（Architecture）

数据流

输入分类（按 memory sector）
生成 embedding（按 sector）
分 sector 检索
graph 扩展（waypoint）
综合评分：

similarity + salience + recency + weight

时间图修正（temporal graph）
输出 + 可解释路径 ([GitHub][1])

核心引擎组件

Vector Search（向量召回）
Waypoint Graph（关系图）
Decay Engine（遗忘机制）
Composite Scoring（综合评分）

👉 和传统 RAG 最大差异：

不是“相似度检索”，而是“认知计算”

⏳ 时间维度（Temporal Knowledge Graph）

传统 memory 系统： ❌ 忽略时间

OpenMemory：

valid_from / valid_to
自动更新事实（新事实覆盖旧事实）
时间点查询（point-in-time）
时间线重建 ([GitHub][1])

👉 举例：

CEO 变化会自动更新历史，而不是覆盖

🧠 记忆动态机制

1️⃣ Decay（遗忘）

随时间衰减
不重要的信息自动消失

2️⃣ Reinforcement（强化）

高频 / 重要记忆被强化

👉 模型类似：

Memory Strength = Recency + Frequency + Importance

🔗 MCP 集成

OpenMemory 内置 MCP server：

可直接接入：

Claude Desktop
Cursor
Windsurf
等 AI IDE ([GitHub][1])

提供工具：

openmemory_query
openmemory_store
openmemory_list
openmemory_reinforce

📦 使用方式

1️⃣ JS SDK

npm install openmemory-js

import { OpenMemory } from "openmemory-js"
const mem = new OpenMemory()

2️⃣ Python SDK

pip install openmemory-py

from openmemory import Memory
mem = Memory()

3️⃣ Backend Server

适用于：

多用户系统
SaaS / Dashboard
企业级 memory

docker compose up --build -d

🧪 性能（官方测试）

115ms 查询延迟（10万节点）
338 QPS
Recall@5 = 95% ([GitHub][1])

🔐 安全

AES-GCM 加密
用户隔离
默认无 telemetry ([GitHub][1])

🧰 CLI 工具

opm add "user prefers dark mode"
opm query "preferences"
opm list
opm reinforce <id>

📊 Dashboard

支持：

memory 浏览
decay 曲线
graph 可视化
timeline 分析 ([GitHub][1])

🧠 本质总结（非常关键）

如果用一句话说：

👉 OpenMemory ≠ 向量数据库 👉 OpenMemory = AI 的“类人脑记忆系统”

🔥 和你当前系统的关系（重点）

你现在在做：

IM + Feed + 推荐 + 用户画像 + AI Agent

👉 OpenMemory 对你来说，本质是：

👉 “统一记忆中枢”（Memory Layer）

可以替代：

用户画像系统（部分）
标签系统（部分）
RAG memory
行为日志的语义层

🚀 如果你要落地（建议）

你可以这样用：

架构映射

IM事件流 → Memory Engine（OpenMemory思想）
              ↓
        推荐系统 / Agent / Feed

可拆能力

用户长期偏好（user memory）
会话上下文（session memory）
项目知识（project memory）
行为沉淀（behavior → memory）

参考资料

OpenMemory
核心定位（Introduction）
- OpenMemory 提供的能力
🚀 对比传统方案
⚡ Standalone 模式
🧠 核心设计：认知记忆模型
- 五大记忆类型（Multi-sector）
🧩 架构核心（Architecture）
- 数据流
- 核心引擎组件
⏳ 时间维度（Temporal Knowledge Graph）
🧠 记忆动态机制
- 1️⃣ Decay（遗忘）
- 2️⃣ Reinforcement（强化）
🔗 MCP 集成
📦 使用方式
🧪 性能（官方测试）
🔐 安全
🧰 CLI 工具
📊 Dashboard
🧠 本质总结（非常关键）
🔥 和你当前系统的关系（重点）
- 👉 “统一记忆中枢”（Memory Layer）
🚀 如果你要落地（建议）
- 架构映射
- 可拆能力
参考资料

opencode-supermemory 用于持久化记忆的 OpenCode 插件基于 Supermemory

Wed, 01 Apr 2026 13:01:55 +0000

接入 claude code

npx -y install-mcp https://mcp.supermemory.ai/mcp --client claude

opencode-supermemory

用于持久化记忆的 OpenCode 插件，基于 Supermemory。

你的 agent 会记住你告诉它的内容——跨会话、跨项目。

安装

面向普通用户（For Humans）

bunx opencode-supermemory@latest install

然后从 app.supermemory.ai 获取你的 API key，并设置：

export SUPERMEMORY_API_KEY="sm_..."

或者让你的 agent 来完成 —— 将以下内容粘贴到 OpenCode 中：

Install opencode-supermemory by following https://raw.githubusercontent.com/supermemoryai/opencode-supermemory/main/README.md

面向 LLM Agents

LLM Agent 指南（点击展开）

如果你是一个帮助用户配置 opencode-supermemory 的 LLM agent，请按照以下步骤操作： #### 第 1 步：运行安装器 ```bash bunx opencode-supermemory@latest install --no-tui ``` 该命令会： * 在 `~/.config/opencode/opencode.jsonc` 中注册插件 * 创建 `/supermemory-init` 命令 --- #### 第 2 步：验证配置 ```bash cat ~/.config/opencode/opencode.jsonc ``` 应该包含： ```json { "plugin": ["opencode-supermemory"] } ``` 如果没有，请手动添加： **JSONC：** ```jsonc { "plugin": [ "opencode-supermemory", // ... 其他插件 ], } ``` **JSON：** ```json { "plugin": ["opencode-supermemory"] } ``` --- #### 第 3 步：配置 API key 让用户从 [app.supermemory.ai](https://app.supermemory.ai/?view=integrations) 获取 API key。然后通过环境变量设置： ```bash export SUPERMEMORY_API_KEY="sm_..." ``` 或者创建 `~/.config/opencode/supermemory.jsonc`： ```jsonc { "apiKey": "sm_...", } ``` --- #### 第 4 步：验证安装让用户重启 OpenCode 并运行： ```bash opencode -c ``` 他们应该能在工具列表中看到 `supermemory`。如果没有，请检查： 1. 是否设置了 `SUPERMEMORY_API_KEY`？ 2. 插件是否存在于 `opencode.jsonc` 中？ 3. 查看日志：`tail ~/.opencode-supermemory.log` --- #### 第 5 步：初始化代码库记忆（可选）运行 `/supermemory-init`，让 agent 自动探索并记忆代码库。

功能

上下文注入（Context Injection）

在首次消息时，agent 会收到（对用户不可见）：

用户画像（跨项目偏好）
项目记忆（所有项目知识）
相关用户记忆（语义搜索）

示例（agent 实际看到的内容）：

[SUPERMEMORY]

User Profile:
- 偏好简洁回答
- TypeScript 专家

Project Knowledge:
- [100%] 使用 Bun，而不是 Node.js
- [100%] 构建命令：bun run build

Relevant Memories:
- [82%] 如果缺少 .env.local，构建会失败

agent 会自动使用这些上下文——无需手动提示。

关键词检测（Keyword Detection）

当你说 “remember”、“save this”、“don’t forget” 等关键词时，agent 会自动保存记忆。

你："记住这个项目使用 bun"
Agent: [保存到项目记忆]

可以通过 keywordPatterns 配置自定义触发词。

代码库索引（Codebase Indexing）

运行 /supermemory-init，agent 会探索并记忆你的代码结构、模式和约定。

预防性压缩（Preemptive Compaction）

当上下文使用达到 80% 时：

触发 OpenCode 的摘要机制
将项目记忆注入摘要上下文
将会话摘要保存为记忆

这样可以在压缩过程中保留对话上下文。

隐私（Privacy）

API key is <private>sk-abc123</private>

被 <private> 标签包裹的内容永远不会被存储。

工具使用（Tool Usage）

supermemory 工具可供 agent 使用：

模式	参数	描述
`add`	`content`, `type?`, `scope?`	存储记忆
`search`	`query`, `scope?`	搜索记忆
`profile`	`query?`	查看用户画像
`list`	`scope?`, `limit?`	列出记忆
`forget`	`memoryId`, `scope?`	删除记忆

作用域（Scopes）：

user（跨项目）
project（默认）

类型（Types）：

project-config
architecture
error-solution
preference
learned-pattern
conversation

记忆作用域（Memory Scoping）

作用域	标识	持久性
用户	`opencode_user_{sha256(git email)}`	所有项目
项目	`opencode_project_{sha256(directory)}`	当前项目

配置（Configuration）

创建 ~/.config/opencode/supermemory.jsonc：

{
  // API key（也可以使用 SUPERMEMORY_API_KEY 环境变量）
  "apiKey": "sm_...",

  // 记忆检索的最小相似度（0-1）
  "similarityThreshold": 0.6,

  // 每次请求注入的最大记忆数量
  "maxMemories": 5,

  // 最大项目记忆数量
  "maxProjectMemories": 10,

  // 最大用户画像条目数
  "maxProfileItems": 5,

  // 是否在上下文中注入用户画像
  "injectProfile": true,

  // 容器标签前缀（当 userContainerTag/projectContainerTag 未设置时使用）
  "containerTagPrefix": "opencode",

  // 可选：自定义用户容器标签（覆盖自动生成）
  "userContainerTag": "my-custom-user-tag",

  // 可选：自定义项目容器标签（覆盖自动生成）
  "projectContainerTag": "my-project-tag",

  // 额外关键词匹配（正则）
  "keywordPatterns": ["log\\s+this", "write\\s+down"],

  // 触发上下文压缩的阈值（0-1）
  "compactionThreshold": 0.8,
}

所有字段均为可选。

环境变量 SUPERMEMORY_API_KEY 优先级高于配置文件。

容器标签选择（Container Tag Selection）

默认情况下，容器标签会基于 containerTagPrefix + hash 自动生成：

用户标签：{prefix}_user_{hash(git_email)}
项目标签：{prefix}_project_{hash(directory)}

你可以通过指定固定标签来覆盖：

{
  "userContainerTag": "my-team-workspace",
  "projectContainerTag": "my-awesome-project",
}

适用于以下场景：

团队共享记忆（相同 userContainerTag）
多设备同步项目记忆
使用自定义命名规则组织记忆
与其他工具中的 Supermemory 容器标签集成

与 Oh My OpenCode 一起使用

如果你在使用 Oh My OpenCode，请禁用其内置的自动压缩 hook，让 supermemory 接管上下文压缩：

在 ~/.config/opencode/oh-my-opencode.json 中添加：

{
  "disabled_hooks": ["anthropic-context-window-limit-recovery"]
}

开发（Development）

bun install
bun run build
bun run typecheck

本地安装：

{
  "plugin": ["file:///path/to/opencode-supermemory"],
}

日志（Logs）

tail -f ~/.opencode-supermemory.log

许可证（License）

MIT

参考资料

接入 claude code
opencode-supermemory
参考资料

项目：Neovim 一个专注于可扩展性和易用性的 Vim 重构版本（现代化文本编辑器）

Wed, 01 Apr 2026 13:01:55 +0000

📦 项目：Neovim

🧠 一句话（翻译）

一个专注于可扩展性和易用性的 Vim 重构版本（现代化文本编辑器） ([GitHub][1])

📌 项目背景（翻译）

Neovim 是从 Vim fork 出来的项目，目标是：

重构历史代码（更易维护）
提升扩展能力
支持现代开发需求

👉 核心问题：

Vim 代码过于庞大、难维护，扩展能力受限 ([GitHub][2])

🎯 项目目标（翻译）

Neovim 的核心目标：

简化维护（降低复杂度）
提升社区贡献效率
支持现代 UI（GUI / IDE）
最大化扩展性 ([GitHub][1])

⚙️ 核心特性（官方翻译）

🔧 1️⃣ 可扩展性（Extensible）

提供 第一类 API（可发现 / 有版本 / 文档化）
支持 任意语言扩展（RPC + MessagePack）
插件以 异步进程运行（Remote plugins）
支持 Lua（推荐）和 Vimscript
支持 GUI / IDE 嵌入（–embed）

👉 本质：

Neovim = 可编程编辑器平台

📌 关键点：

插件 ≠ 脚本插件 = 独立进程（更安全、更强）

([Neovim][3])

⚡ 2️⃣ 现代能力（Usable）

内置 LSP（语言服务器协议）
支持代码跳转 / 重构 / 格式化
内置 terminal
支持多 UI attach（类似 tmux）
统一跨平台行为

([Neovim][3])

🔄 3️⃣ 异步架构

基于 libuv（事件循环）
支持 async job control
不阻塞 UI

👉 这点是相比 Vim 的巨大提升

([维基百科][4])

🧠 4️⃣ Lua 优先（重要变化）

用 Lua 替代 Vimscript 作为主扩展语言
更高性能、更易维护

👉 实际上：

现代 Neovim = Lua 驱动的 IDE

🧩 5️⃣ 插件生态兼容

支持大部分 Vim 插件
同时支持新一代 Lua 插件

🧱 6️⃣ 内置 Terminal

:terminal

👉 可以直接在编辑器中运行 shell

🏗️ 核心架构（重点）

🔥 1️⃣ Client-Server 架构

UI（终端 / GUI / VSCode）
        ↓
    Neovim Core
        ↓
 Plugins / LSP / Tools

👉 特点：

UI 和核心解耦
可以 attach 多个 UI

([Neovim][3])

🔥 2️⃣ RPC 插件系统

Neovim
   ↓ RPC（MessagePack）
Python / Node / Go / Rust 插件

👉 这意味着：

插件可以用任何语言写

🔥 3️⃣ 事件驱动架构

event loop（libuv）
async IO
非阻塞执行

🔥 4️⃣ 模块结构（源码）

src/nvim/
 ├── api/          API 层
 ├── eval/         Vimscript
 ├── lua/          Lua 引擎
 ├── event/        事件系统
 ├── msgpack_rpc/  RPC 通信
 ├── tui/          终端 UI

([GitHub][1])

🧠 核心设计思想（非常关键）

🔥 1️⃣ “编辑器内核”与“UI”解耦

传统 Vim：

编辑器 = UI + 核心（耦合）

Neovim：

核心（Headless）
 + UI（插件）

👉 可以：

嵌入 VSCode（vscode-neovim）
浏览器运行（Firenvim）

🔥 2️⃣ “插件优先”架构

Neovim 的理念：

核心越小越好，功能交给插件

🔥 3️⃣ “编辑器 → 平台”

传统编辑器：

写代码工具

Neovim：

可编程开发平台

🚀 和 Vim 的核心区别（关键总结）

维度	Vim	Neovim
架构	单体	Client-Server
扩展	Vimscript	Lua + 任意语言
IO	同步	异步
插件	内嵌	外部进程
LSP	插件实现	内置
现代化	较弱	强

📊 本质抽象（非常重要）

你可以这样理解：

Neovim = 编辑器内核 + 插件系统 + RPC平台

或者更工程一点：

Neovim ≈ IDE Kernel

🔥 为什么它这么火（关键原因）

✅ 1️⃣ 可编程性极强

Lua 配置
API 完整
插件自由

✅ 2️⃣ IDE 能力 + 轻量

LSP
自动补全
Debug

👉 但比 VSCode 更轻

✅ 3️⃣ 可嵌入（关键）

可以作为：

IDE 组件
浏览器编辑器
CLI 工具核心

✅ 4️⃣ 性能好

启动快
异步执行
更少历史负担

🚀 和你当前方向的关联（重点）

你在做：

IM + 推荐 + AI + 运维平台

这个项目其实给你几个非常关键的启发👇

🧠 1️⃣ “核心 + 插件”架构

你可以直接套：

IM Core
   ↓
Skill / Agent 插件
   ↓
能力扩展

👉 类似 Neovim 插件系统

🧠 2️⃣ “事件驱动 + 异步”

Neovim：

用户操作 → event → async 执行

你可以做：

报警 → event → AI分析 → 推荐

🧠 3️⃣ “可嵌入核心”

Neovim 可以被 embed：

👉 你可以做：

AI Engine（核心）
 + IM / 控台 / API

🧠 4️⃣ “配置即代码（Lua）”

Neovim：

配置 = 可执行逻辑

你可以：

Skill = DSL / JSON / Lua

🧩 一句话总结

Neovim 本质是：

一个把“编辑器”升级为“可编程开发平台”的系统

参考资料

📦 项目：Neovim
- 🧠 一句话（翻译）
📌 项目背景（翻译）
🎯 项目目标（翻译）
⚙️ 核心特性（官方翻译）
🏗️ 核心架构（重点）
🧠 核心设计思想（非常关键）
🚀 和 Vim 的核心区别（关键总结）
📊 本质抽象（非常重要）
🔥 为什么它这么火（关键原因）
🚀 和你当前方向的关联（重点）
🧩 一句话总结
参考资料

Dimillian/Skills 提供一组围绕 Swift / SwiftUI / iOS 工作流的结构化技能指令帮助开发者更快地

Wed, 01 Apr 2026 13:01:55 +0000

📦 项目：Dimillian/Skills

🧠 项目概述（翻译）

这是一个技能集合（Skills）仓库，主要用于：

提供一组围绕 Swift / SwiftUI / iOS 工作流的“结构化技能指令”，帮助开发者更快地：

代码评审（review）
调试（debug）
交付（ship）

👉 本质上，它不是“代码库”，而是：

给 AI / Agent 使用的“专家级操作手册库”

([Dimillian][1])

🧩 核心概念：什么是 Skill？

🔹 定义（翻译 + 解释）

每个 Skill 是一个独立的能力模块，包含：

使用场景（When to use）
工作流程（Workflow）
最佳实践（Best practices）
示例命令 / 操作步骤

👉 可以理解为：

Skill = Prompt工程 + 专家经验 + 标准操作流程（SOP）

🏗️ 使用方式（翻译）

npx skills add https://github.com/dimillian/skills --skill <skill-name>

👉 含义：

从该仓库安装一个“技能”
让 AI / CLI 工具具备这个能力

📚 示例 Skill 翻译

下面是一个典型 Skill（GitHub 操作）的完整翻译👇

🧑‍💻 Skill：GitHub

📌 描述（翻译）

使用 gh CLI 与 GitHub 交互，包括：

Issue
Pull Request
CI 运行（Actions）
API 查询

([Skills][2])

🔧 Pull Request 操作（翻译）

查看 PR 的 CI 状态

gh pr checks 55 --repo owner/repo

查看最近的 CI 运行

gh run list --repo owner/repo --limit 10

查看某次运行详情

gh run view <run-id> --repo owner/repo

查看失败日志

gh run view <run-id> --repo owner/repo --log-failed

🐛 CI 失败排查流程（重点）

标准排查步骤：

1️⃣ 查看 PR 状态

gh pr checks

2️⃣ 找到对应 run

gh run list

3️⃣ 查看失败任务

gh run view

4️⃣ 拉取失败日志

gh run view --log-failed

👉 这是一个标准化 CI Debug SOP

🔌 API 高级查询

gh api repos/owner/repo/pulls/55 --jq '.title, .state, .user.login'

👉 用于获取更灵活的数据

📊 JSON 输出

gh issue list --json number,title --jq '.[] | "\(.number): \(.title)"'

👉 支持结构化处理

🧠 示例 Skill（二）：Swift 并发专家

📌 概述（翻译）

用于修复 Swift 并发问题（Swift 6.2+），包括：

actor 隔离
Sendable 安全
并发模型优化

([Skills][3])

🔄 工作流（翻译）

1️⃣ 问题分析

获取编译错误
检查 Swift 版本
判断 actor 上下文
判断是否 UI 线程

2️⃣ 最小修复策略

优先保持行为不变：

UI → @MainActor
全局变量 → actor 或主线程保护
后台任务 → async / actor
Sendable → 优先不可变类型

👉 关键思想：

最小侵入 + 并发安全

🧩 项目中包含的 Skill 类型（总结）

该仓库目前大致包含：

🧱 iOS / Swift 方向

SwiftUI UI 设计
Swift 并发
性能优化
View 重构

⚙️ 工程能力

GitHub 工作流（gh CLI）
Issue 修复流程
CI/CD 调试

🧪 调试能力

iOS 模拟器调试
日志分析

🌐 前端能力

React 性能优化

([Vett][4])

⚙️ 本质架构（非常关键）

这个项目的核心价值，其实是👇

🧠 Skill = AI 可复用能力模块

你可以把它抽象成：

用户问题
   ↓
选择 Skill
   ↓
加载 SOP（Workflow + Best Practice）
   ↓
AI 执行

🚀 和你当前方向的关系（重点）

你在做：

IM + 推荐 + AI 根因分析平台

这个项目的价值非常高👇

✅ 可以直接借鉴的设计

1️⃣ Skill 系统 = AI 能力插件化

你可以做：

AI能力平台
  ├── Debug Skill
  ├── SQL分析 Skill
  ├── 日志分析 Skill
  ├── 报警根因 Skill
  ├── 推荐策略 Skill

2️⃣ Skill = 标准化专家知识

适用于你现在的：

运维专家知识库
故障排查 SOP
根因分析路径

3️⃣ Skill + 推荐系统

你甚至可以做：

根据用户问题 → 推荐最合适 Skill

类似：

“CPU 飙高” → 推荐【性能分析 Skill】
“接口超时” → 推荐【链路追踪 Skill】

🧩 一句话总结

这个仓库本质不是“代码”，而是一个：

“把专家经验结构化成 AI 可执行能力”的 Skill 平台”

参考资料

📦 项目：Dimillian/Skills
- 🧠 项目概述（翻译）
🧩 核心概念：什么是 Skill？
- 🔹 定义（翻译 + 解释）
🏗️ 使用方式（翻译）
📚 示例 Skill 翻译
🧠 示例 Skill（二）：Swift 并发专家
- 📌 概述（翻译）
- 🔄 工作流（翻译）
  - 1️⃣ 问题分析
  - 2️⃣ 最小修复策略
🧩 项目中包含的 Skill 类型（总结）
⚙️ 本质架构（非常关键）
- 🧠 Skill = AI 可复用能力模块
🚀 和你当前方向的关系（重点）
- ✅ 可以直接借鉴的设计
🧩 一句话总结
参考资料

Coding Interview University（编程面试大学）

Wed, 01 Apr 2026 13:01:55 +0000

📘 Coding Interview University（编程面试大学）

📌 项目简介

这是一个完整的计算机科学学习计划，帮助你成为一名软件工程师。 ([GitHub][1])

最初作者只是写了一个简单的学习 TODO 列表，但逐渐扩展成一个系统化学习路线。

作者按照这个计划学习后，成功入职 Amazon 软件工程师岗位。 ([GitHub][1])

⚠️ 作者特别说明：

你不需要像他一样每天学习 8–12 小时
但这个清单包含了你需要掌握的全部核心知识

🧭 一、学习计划结构（The Study Plan）

包含内容

这是什么？
为什么使用它？
如何使用
编程语言选择
数据结构与算法书籍
面试准备书籍
每日学习计划
编程题练习

👉 本质：

一套“从 0 → 面试通过”的完整路径

🧠 二、核心学习内容（Topics of Study）

这是整个项目最核心的部分👇

1️⃣ 算法基础

时间复杂度 / Big-O
渐进分析（Asymptotic analysis）

2️⃣ 数据结构

数组（Array）
链表（Linked List）
栈（Stack）
队列（Queue）
哈希表（Hash Table）

3️⃣ 基础算法与技巧

二分查找（Binary Search）
位运算（Bitwise Operations）

4️⃣ 树（Trees）

树基础
二叉搜索树（BST）
堆 / 优先队列
树遍历：
- 前序 / 中序 / 后序
- BFS / DFS

5️⃣ 排序算法

选择排序
插入排序
堆排序
快速排序
归并排序

6️⃣ 图（Graphs）

有向图 / 无向图
邻接矩阵 / 邻接表
BFS / DFS

7️⃣ 进阶知识

递归（Recursion）
动态规划（Dynamic Programming）
设计模式（Design Patterns）
组合数学 & 概率
NP / NP-Complete 问题
字符串处理
Trie
网络（Networking）
浮点数 / Unicode / 字节序

8️⃣ 系统与底层知识

程序执行原理
缓存（Cache）
进程与线程
并发问题（锁、死锁等）
内存模型（堆、栈）

9️⃣ 最终复习

系统回顾所有知识点

💼 三、求职部分（Getting the Job）

优化简历
找工作
面试流程准备
面试时的思考点
向面试官提问
拿到 Offer 后

📚 四、可选扩展（Optional）

⚠️ 以下是“加分项”，不是必须：

高级计算机科学内容

编译器
信息论
密码学
压缩算法
计算机安全
并行计算
消息队列系统

高级数据结构

红黑树 / AVL 树
B 树
跳表（Skip List）
并查集（Union-Find）
布隆过滤器（Bloom Filter）
HyperLogLog

数学与算法

FFT（快速傅里叶变换）
线性规划
几何算法

系统设计（重要）

👉 适用于 4 年以上经验：

可扩展性（Scalability）
数据处理系统

🧪 五、刷题与练习（非常关键）

推荐平台：

LeetCode（强烈推荐）
HackerRank
TopCoder ([GitHub][1])

👉 核心建议：

持续刷题
学会分析解法
总结模式（pattern）

🛠️ 六、如何使用这个仓库（How to use it）

方法 1：不使用 Git

下载 ZIP
用编辑器查看 Markdown

方法 2：使用 Git（推荐）

Fork 仓库
Clone 到本地
按学习进度打勾 [x]
提交自己的学习进度

👉 本质：

把它当成“学习进度管理系统”

⚠️ 七、作者建议（非常重要）

1️⃣ 不要怀疑自己不够聪明

很多工程师都有“自己不够聪明”的不安全感
这是普遍现象

2️⃣ 视频资源说明

一些课程来自：
- Coursera
- edX
有些需要等待开课

🧠 核心本质总结（给你做架构抽象）

这个项目本质是：

✅ 一个「计算机科学知识图谱 + 学习路径引擎」

如果用你熟悉的系统设计语言来拆👇

1️⃣ 数据层（知识图谱）

DS + Algo
OS / 网络
数学
系统设计

2️⃣ 流程层（学习路径）

类似：

基础 → 数据结构 → 算法 → 系统 → 面试

3️⃣ 执行层（训练）

刷题（LeetCode）
模拟面试
项目实践

4️⃣ 结果层（输出）

Offer
工程能力
CS 基础

🚀 一句话总结

这是目前 GitHub 上最系统的「算法 + 计算机基础 → 面试」完整路线图之一。 ([GitHub][1])

参考资料

📘 Coding Interview University（编程面试大学）
- 📌 项目简介
🧭 一、学习计划结构（The Study Plan）
- 包含内容
🧠 二、核心学习内容（Topics of Study）
💼 三、求职部分（Getting the Job）
📚 四、可选扩展（Optional）
🧪 五、刷题与练习（非常关键）
🛠️ 六、如何使用这个仓库（How to use it）
- 方法 1：不使用 Git
- 方法 2：使用 Git（推荐）
⚠️ 七、作者建议（非常重要）
- 1️⃣ 不要怀疑自己不够聪明
- 2️⃣ 视频资源说明
🧠 核心本质总结（给你做架构抽象）
🚀 一句话总结
参考资料

claude supermemory（AI 记忆引擎）

Wed, 01 Apr 2026 13:01:55 +0000

安装实战笔记

安装（Installation）

/plugin marketplace add supermemoryai/claude-supermemory
/plugin install claude-supermemory

设置你的 API Key（在 https://app.supermemory.ai 获取）：

export SUPERMEMORY_CC_API_KEY="sm_..."

Claude-Supermemory

✨ 需要 Supermemory Pro 或更高版本 —— 解锁你 Claude 代码的最先进记忆能力。

一个 Claude Code 插件，通过 Supermemory 为你的 AI 提供跨会话的持久化记忆。你的 agent 可以记住你做过的事情——跨会话、跨项目。

功能（Features）

团队记忆（Team Memory） —— 在团队内共享项目知识，与个人记忆相互隔离
自动捕获（Auto Capture） —— 会话结束时自动保存对话
项目配置（Project Config） —— 每个仓库独立的设置、API Key 和容器标签

安装（Installation）

/plugin marketplace add supermemoryai/claude-supermemory
/plugin install claude-supermemory

设置你的 API Key（在 https://app.supermemory.ai 获取）：

export SUPERMEMORY_CC_API_KEY="sm_..."

工作原理（How It Works）

super-search —— 询问过去的工作或历史会话，Claude 会在你的记忆中进行搜索
super-save —— 请求保存重要信息，Claude 会将其保存到团队记忆中

命令（Commands）

命令	描述
`/claude-supermemory:index`	索引代码库的架构与模式
`/claude-supermemory:project-config`	配置项目级别设置
`/claude-supermemory:logout`	清除已保存的凭据

配置（Configuration）

环境变量（Environment）

SUPERMEMORY_CC_API_KEY=sm_...    # 必填
SUPERMEMORY_DEBUG=true           # 可选：启用调试日志

全局设置（Global Settings）— `~/.supermemory-claude/settings.json`

{
  "maxProfileItems": 5,
  "signalExtraction": true,
  "signalKeywords": ["remember", "architecture", "decision", "bug", "fix"],
  "signalTurnsBefore": 3,
  "includeTools": ["Edit", "Write"]
}

选项	描述
`maxProfileItems`	上下文中最多包含的记忆数量（默认：5）
`signalExtraction`	仅捕获重要对话轮次（默认：false）
`signalKeywords`	触发捕获的关键词
`signalTurnsBefore`	信号出现前包含的上下文轮数（默认：3）
`includeTools`	需要显式捕获的工具

项目配置（Project Config）— `.claude/.supermemory-claude/config.json`

针对每个仓库的覆盖配置。可运行 /claude-supermemory:project-config 或手动创建：

{
  "apiKey": "sm_...",
  "repoContainerTag": "my-team-project",
  "signalExtraction": true
}

选项	描述
`apiKey`	项目级 API Key
`personalContainerTag`	覆盖个人容器标签
`repoContainerTag`	覆盖团队容器标签

许可证（License）

MIT

参考资料

安装实战笔记
- 安装（Installation）
Claude-Supermemory
参考资料

ChatDev：用于软件开发的通信型智能体

Wed, 01 Apr 2026 13:01:55 +0000

📖 ChatDev：用于软件开发的通信型智能体

📌 概述（Overview）

ChatDev 是一个“虚拟软件公司”，由多个具备不同角色的智能体组成，例如：

CEO（首席执行官）
CPO（产品负责人）
CTO（技术负责人）
程序员
代码审查员
测试工程师
UI / 美术设计师

这些智能体构成一个多智能体组织结构，共同目标是：

“通过编程革新数字世界”

它们通过参与各种“功能性研讨会”协作完成任务，例如：

需求设计
编码实现
测试验证
文档编写

🎯 核心目标

ChatDev 的目标是提供一个：

✅ 易于使用（easy-to-use）
✅ 高度可定制（customizable）
✅ 可扩展（extendable）

的框架，该框架：

基于大语言模型（LLMs）
用于研究和理解“群体智能（collective intelligence）”

🧠 能力本质（你需要重点理解）

ChatDev 本质上是：

一个「多 Agent 协作的软件工程系统」

关键机制：

使用自然语言作为统一通信协议
通过多轮对话推进任务
模拟真实软件开发流程（类似瀑布模型）

👉 核心思想：

“语言即接口”
“对话即流程编排”

🚀 最新进展（News）

2025

提出 Puppeteer-style 多 Agent 编排机制
- 引入“中央调度器（orchestrator）”
- 使用强化学习动态调度 Agent
- 优化：
  - 推理质量
  - 计算成本

2024

发布 MacNet（多智能体协作网络）
- 使用 DAG（有向无环图）组织 Agent
- 支持：
  - 超大规模 Agent（>1000）
  - 更复杂拓扑结构
- 不再局限于链式流程（比传统 ChatDev 更强）

2023

发布 ChatDev 初始版本
支持：
- Git 模式
- Human-Agent 交互模式
- Art 模式（生成 UI/图片）
- 增量开发（基于已有代码继续开发）

❓ ChatDev 能做什么？

（原文是视频 demo，这里解释其能力）

可以自动完成：

从 idea → 完整软件
包含：
- 需求分析
- 设计
- 编码
- 测试
- 文档

👉 本质是：

“一句自然语言 → 一套软件产出”

⚡ 快速开始（Quickstart）

方式一：Web

访问在线平台：

https://chatdev.modelbest.cn/

方式二：本地运行

1️⃣ 克隆仓库

git clone https://github.com/OpenBMB/ChatDev.git

2️⃣ 创建 Python 环境

conda create -n ChatDev_conda_env python=3.9 -y
conda activate ChatDev_conda_env

3️⃣ 安装依赖

cd ChatDev
pip3 install -r requirements.txt

4️⃣ 设置 OpenAI API Key

（通过环境变量配置）

⚙️ 高级能力（Advanced Skills）

官方 Wiki 提供：

1️⃣ 运行参数说明

所有 CLI 参数解释

2️⃣ 可视化工具

支持：

实时日志
回放日志
ChatChain 可视化

3️⃣ 核心框架结构

ChatChain（核心）

定义流程，例如：

需求分析 → 编码 → 测试 → 人工确认

👉 本质：流程编排 DSL

4️⃣ Phase（阶段）

可以自定义阶段：

例如：

DemandAnalysis（需求分析）
Coding（编码）
Testing（测试）

5️⃣ Role（角色）

可以自定义公司角色：

例如：

CEO
CTO
Programmer

👉 本质：Agent Persona 定义

🏗️ 产出结构（非常重要）

当你执行：

python3 run.py --task "design a 2048 game"

会生成：

/WareHouse/2048_xxx/

里面包含：

1️⃣ 软件代码 + 文档

2️⃣ 公司配置（3个 JSON）

3️⃣ 完整执行日志

可回放（Replay）

4️⃣ 初始 Prompt

👉 这是你做 AI 工程化最关键的资产

🏢 “公司配置”机制（核心设计）

你可以创建自己的“AI公司”：

只需 3 个 JSON：

角色配置
流程配置
阶段配置

👉 这其实就是：

“AI Agent Workflow Engine”

📚 论文引用（Citation）

项目基于多个论文：

ChatDev（2023）
Experiential Co-Learning
MacNet
多 Agent 协作网络

⚖️ 许可证（License）

代码

Apache 2.0（可商用）

数据

CC BY-NC 4.0（仅限非商业）

⚠️ 注意：

用数据训练的模型也必须非商业

🧠 我帮你总结一下（重点提炼）

如果你是架构师（你确实是），这个项目真正的价值不是“写代码”，而是：

1️⃣ 多 Agent 软件工程范式

人类 → AI团队
单模型 → 多角色协作

2️⃣ ChatChain = 编排引擎

类似：

Airflow（但用自然语言）
Temporal（但由 LLM 驱动）

3️⃣ CompanyConfig = Agent OS

你可以构建：

自动化测试公司
运维分析公司
推荐系统公司

👉 这点和你正在做的 AI根因分析系统高度契合

4️⃣ 可扩展到非软件领域

ChatDev 2.0 已支持：

数据分析
视频生成
研究总结
游戏开发 ([DeepWiki][1])

参考资料

📖 ChatDev：用于软件开发的通信型智能体
🧠 我帮你总结一下（重点提炼）
参考资料

Agent Lightning（microsoft/agent-lightning）一个可以训练任意 AI Agent 的通用优化框架（几乎不需要改代码）

Wed, 01 Apr 2026 13:01:55 +0000

📦 项目：Agent Lightning（microsoft/agent-lightning）

🧠 项目一句话（翻译）

一个可以训练任意 AI Agent 的通用优化框架（几乎不需要改代码） ([GitHub][1])

📌 项目定位（核心翻译）

Agent Lightning 是一个：

用于优化（训练）AI Agent 的通用框架

它解决的核心问题是：

👉 当前 Agent 框架（如 LangChain、AutoGen）：

能“运行 agent”
但不会自动变聪明（缺乏训练能力）

👉 当前训练框架（RL / SFT）：

能训练模型
但无法直接作用在 agent 上（不兼容 agent workflow）

✅ Agent Lightning 做的事情：

把 Agent 和训练系统“解耦”，让任何 Agent 都可以被训练优化

([微软][2])

⚡ 核心能力（翻译）

1️⃣ 支持任意 Agent 框架

LangChain
OpenAI Agents SDK
AutoGen
CrewAI
甚至纯 Python Agent

👉 无需修改 agent 代码（或极少修改）

([GitHub][1])

2️⃣ 支持多种优化方式

强化学习（RL）
Prompt 优化
模型微调（SFT）
模型选择

👉 不只是 RL，是一个统一优化框架

([GitHub][1])

3️⃣ 多 Agent / 多任务优化

可以只优化某个 agent
支持 multi-agent 系统

4️⃣ 面向真实复杂场景

支持：

多轮对话（multi-turn）
工具调用（tool use）
多 agent 协作
动态上下文

([微软][2])

5️⃣ 内置错误监控

追踪 agent 执行状态
识别失败原因
输出 error signal 用于训练

🧩 核心架构（重点翻译）

🔧 两大核心组件

1️⃣ Lightning Server

负责：
- 任务调度
- 数据收集
- 训练调度
- reward 计算

2️⃣ Lightning Client

运行在 agent 侧
负责：
- 执行任务
- 上报 trace（行为轨迹）

🧠 中间层设计（关键）

👉 这是整个项目最核心的思想：

在 Agent 和训练系统之间加一层“桥”

🔄 工作流程（翻译）

1️⃣ 任务执行

Server 下发任务
Agent 正常执行（不改逻辑）

2️⃣ 行为采集（Sidecar 模式）

系统自动收集：

prompt
action
tool 调用
错误
reward

3️⃣ 转换为 RL 数据

(state_t, action_t, reward_t, state_t+1)

4️⃣ 训练循环

使用 RL（如 GRPO）
更新模型 / prompt
再回到 agent 执行

👉 形成闭环：

执行 → 收集 → 学习 → 再执行 → 持续变强

🧠 核心设计思想（非常关键）

🔥 1️⃣ Agent 与训练完全解耦

传统：

Agent = 模型 + 逻辑（耦合）

Agent Lightning：

Agent（执行）
    ↓
Trace（数据）
    ↓
训练系统（优化）

👉 训练系统完全独立存在

🔥 2️⃣ Agent = 可学习系统

传统 agent：

一旦上线，就“固定能力”

Agent Lightning：

Agent 会“越用越聪明”

([微软][3])

🔥 3️⃣ 以真实行为数据训练

不是 synthetic 数据，而是：

用户真实交互
实际任务执行
真正失败/成功信号

👉 这是工业级关键点

🧩 项目结构（翻译）

仓库核心目录：

agentlightning/ → 核心框架
examples/ → 示例
dashboard/ → 可视化
docker/ → 部署
tests/ → 测试
docs/ → 文档

⚙️ 安装方式（翻译）

pip install agentlightning

🚀 本质抽象（非常重要）

🧠 Agent Lightning = Agent 的“训练引擎”

可以抽象为：

Agent（执行层）
        ↓
Trace（行为数据）
        ↓
Lightning（训练层）
        ↓
优化结果（模型 / prompt）
        ↓
Agent（变强）

🔥 和你之前看的 Skills 的本质区别

你刚刚看的：

👉 Skills 项目：

静态能力（SOP / Prompt）
不会自动进化

👉 Agent Lightning：

动态能力（Learning System）
会持续进化

🧠 对比总结

维度	Skills	Agent Lightning
本质	Prompt/SOP	学习系统
是否自进化	❌	✅
数据来源	人工定义	真实行为
核心能力	执行	优化

🚀 对你当前方向的价值（重点）

你在做：

IM + 推荐 + AI 根因分析系统

这个项目对你价值非常大👇

✅ 1️⃣ 你的“AI 根因分析”可以进化

你现在可能是：

规则 + Prompt + 专家经验

可以升级为：

真实故障数据 → RL → 自动优化分析策略

✅ 2️⃣ 可以做“运维 Agent 训练平台”

报警 → Agent 分析 → 是否命中根因
          ↓
      reward（正确/错误）
          ↓
      持续训练

✅ 3️⃣ IM 场景天然适配

IM = 超强训练数据来源：

用户问题
交互过程
是否解决

👉 天然 RL 数据流

✅ 4️⃣ Skill + Lightning = 完整体系

你可以组合：

Skill（SOP）
    +
Lightning（学习）

👉 形成：

可进化的专家系统

🧩 一句话总结

Agent Lightning 本质是：

“让 AI Agent 像人一样，通过实践不断学习进化的训练系统”

参考资料

📦 项目：Agent Lightning（microsoft/agent-lightning）
- 🧠 项目一句话（翻译）
📌 项目定位（核心翻译）
- ✅ Agent Lightning 做的事情：
⚡ 核心能力（翻译）
🧩 核心架构（重点翻译）
🧠 核心设计思想（非常关键）
🧩 项目结构（翻译）
⚙️ 安装方式（翻译）
🚀 本质抽象（非常重要）
- 🧠 Agent Lightning = Agent 的“训练引擎”
🔥 和你之前看的 Skills 的本质区别
- 🧠 对比总结
🚀 对你当前方向的价值（重点）
🧩 一句话总结
参考资料

Sherlock 是一个用于在多个社交网络和网站上搜索指定用户名是否存在的工具。

Tue, 31 Mar 2026 13:01:55 +0000

Sherlock

🔍 通过用户名搜索社交网络账号

项目简介（Overview）

Sherlock 是一个用于在多个社交网络和网站上搜索指定用户名是否存在的工具。 (GitHub)

换句话说，它的核心能力是：

输入一个用户名 → 扫描大量网站 → 返回该用户名在哪些平台存在

这是典型的 OSINT（Open Source Intelligence，开源情报）工具。

功能（Features）

支持在数百个网站上搜索用户名
支持多线程并发请求（加快扫描速度）
输出结果清晰（存在 / 不存在）
可导出结果（如 CSV 等）
支持命令行使用（CLI 工具）

工作原理（How It Works）

Sherlock 的核心逻辑其实很简单但非常实用：

预定义各大网站的用户 URL 模板
- 例如：https://twitter.com/{username}
将输入的用户名填入模板
发起 HTTP 请求
判断结果：
- 页面存在 → 用户名已注册
- 404 / 不存在 → 未注册

本质上是：

批量 URL 探测 + 状态判断

（并不是“黑客行为”，只是自动化查询公开数据）

安装（Installation）

方法 1：pip 安装

pip install sherlock-project

方法 2：源码安装

git clone https://github.com/sherlock-project/sherlock.git
cd sherlock
python3 -m pip install -r requirements.txt

使用方式（Usage）

最基本用法：

sherlock username

示例：

sherlock jack

输出结果类似：

[+] Twitter: https://twitter.com/jack
[-] Instagram: Not Found
[+] GitHub: https://github.com/jack

高级参数（常见）

--timeout        设置请求超时
--threads        设置线程数
--output         输出到文件
--csv            导出 CSV
--json           导出 JSON

输出结果（Output）

Sherlock 会返回：

用户名存在的平台列表
对应的用户主页链接
可选导出格式（JSON / CSV）

使用场景（Use Cases）

这个工具在很多场景都很实用：

1️⃣ OSINT / 情报分析

调查某个用户名在互联网的分布
分析个人/组织的网络足迹

2️⃣ 安全 / 风控

检测账号是否被抢注
用户名资产保护

3️⃣ 品牌保护

查看品牌名是否被占用

4️⃣ 社交分析

用户画像补全（跨平台）

项目特点（Key Characteristics）

开源（Python 实现）
轻量级 CLI 工具
数据来源完全公开（无侵入）
扩展性强（可新增网站规则）

技术本质（给你一个架构级理解）

这个项目本质可以抽象为：

👉 「规则驱动的分布式探测引擎」

可以拆成三层：

1️⃣ 规则层（核心资产）

site_name + url_template + 判断规则

例如：

{
  "site": "twitter",
  "url": "https://twitter.com/{username}",
  "error_type": "status_code"
}

2️⃣ 执行层（并发引擎）

多线程 / 异步请求
HTTP 状态判断
失败重试

3️⃣ 输出层（结果聚合）

标准化结果
导出 JSON / CSV
CLI 展示

⚠️ 注意点（很关键）

不是 100% 准确（部分网站反爬 / 假阳性）
请求量大可能被限流
依赖网站结构（容易失效）
不能用于非法用途

一句话总结

Sherlock = 用户名维度的全网扫描引擎（OSINT工具）

如果你从“架构/产品”角度看（结合你现在在做的系统）

这个项目其实非常值得你借鉴👇：

可以迁移到你 IM / 平台的能力：

1️⃣ 用户画像补全

IM 用户 → 外部社交映射

2️⃣ 风控能力

检测异常账号（批量生成 / 机器人）

3️⃣ 用户资产体系

用户名是否唯一 / 稀缺

4️⃣ 推荐系统

跨平台兴趣补充（弱画像 → 强画像）

如果你下一步想更深入，我可以帮你拆：

👉 Sherlock 的代码结构 + 并发模型（async / thread） 👉 或者：如何做一个“增强版 Sherlock”（接入 AI + 推荐 + 用户画像）

参考资料

Sherlock
参考资料

freeCodeCamp / freeCodeCamp 提供多个免费的开发者认证，这些认证构成了完整的全栈开发课程体系

Tue, 31 Mar 2026 13:01:55 +0000

freeCodeCamp / freeCodeCamp

freeCodeCamp.org 的开源代码库和课程体系。免费学习数学、编程和计算机科学。 (GitHub)

freeCodeCamp.org 的开源代码库和课程

freeCodeCamp.org 是一个友好的社区，你可以在这里免费学习编程。

它由一个依靠捐赠支持的 501(c)(3) 非营利组织运营，旨在帮助数百万忙碌的成年人转行进入技术领域。

我们的社区已经帮助超过 100,000 人获得他们的第一份开发者工作。 (GitHub)

我们的全栈 Web 开发和机器学习课程是完全免费且自定进度的。

我们提供数千个交互式编程挑战，帮助你提升技能。 (GitHub)

目录（Table of Contents）

认证（Certifications）
学习平台（The Learning Platform）
报告 Bug 和问题
安全问题报告与负责任披露
贡献（Contributing）
平台、构建与部署状态
许可证（License）

认证（Certifications）

freeCodeCamp 提供多个免费的开发者认证，这些认证构成了完整的全栈开发课程体系：

响应式网页设计（Responsive Web Design）
JavaScript
前端开发库（Frontend Development Libraries）
Python
关系型数据库（Relational Databases）
后端开发与 API（Backend Development and APIs）

每个认证包括：

交互式课程
工作坊（workshops）
实验（labs）
复习（reviews）
测验（quizzes）

在整个认证过程中，你需要完成 5 个必做项目 才能参加考试。

通过考试后，你可以获得认证证书。 (GitHub)

语言认证（Language Certifications）

freeCodeCamp 还提供基于国际语言能力标准的免费语言认证：

A2 英语（开发者）
B1 英语（开发者）
A1 职业西班牙语
A1 职业中文

每个认证包含模块化结构：

热身（warm-ups）
课程（lessons）
练习（practice exercises）
复习页面
测验

必须完成所有测验，才能参加最终考试。 (GitHub)

证书规则

获得的证书是永久有效的
可以用于 LinkedIn 或简历展示
雇主可以通过链接查看可验证的证书

⚠️ 例外情况：如果发现违反学术诚信（如抄袭），将：

撤销证书
封禁账号 (GitHub)

面试准备资源

freeCodeCamp 还提供额外学习资源：

The Odin Project（freeCodeCamp Remix）
Coding Interview Prep
Project Euler
Rosetta Code

此外还提供：

Microsoft 官方基础 C# 认证课程（免费） (GitHub)

学习平台（The Learning Platform）

该代码库就是 freeCodeCamp.org 在线运行的系统。

社区还包括：

论坛（可快速获得编程帮助或项目反馈）
YouTube 频道（免费课程：Python、SQL、Android 等）
技术文章平台（数千篇编程与计算机科学文章）
Discord 社区（开发者交流） (GitHub)

关于（About）

freeCodeCamp 是一个开源代码库和课程体系项目，提供免费的数学、编程和计算机科学学习资源。 (GitHub)

技术栈（Topics）

该项目涉及：

React
Node.js
JavaScript
D3
教育（education）
编程课程（curriculum）
数学（math）
非营利（nonprofit）
职业发展（careers）

许可证（License）

BSD-3-Clause License（宽松开源协议） (GitHub)

补充理解（非逐字翻译，但帮助你快速建立认知）

freeCodeCamp 本质是一个：

非营利组织
开源教育平台
全球开发者社区

核心特点：

完全免费（捐赠驱动）
超大规模课程体系（约 3000+ 小时） (GitHub)
强社区（论坛 / Discord / 开源贡献）
学习 → 项目 → 认证 → 就业闭环

如果你是从“架构/产品”角度看的（给你一个更高级的抽象）

这个项目本质是一个：

开源版「教育型内容平台 + 练习引擎 + 认证系统 + 社区」的超级集合体

可以拆成 4 层：

内容层
- 课程 + 题目 + 项目
执行层
- 在线代码运行 + 自动判题
激励层
- 证书 + 项目驱动
社区层
- 论坛 + 开源协作

如果你要继续深入（我建议你会感兴趣）可以下一步我帮你拆：

👉 freeCodeCamp 的技术架构（前后端 + 判题系统 + 数据模型） 👉 或者：如果你要自己做一个类似平台，该怎么设计（你现在做 IM + 平台，很契合）

参考资料

freeCodeCamp / freeCodeCamp
参考资料

VibeVoice 开源前沿语音 AI

Mon, 30 Mar 2026 13:01:55 +0000

🎙️ VibeVoice: 开源前沿语音 AI

原文

Open-Source Frontier Voice AI

翻译

开源的前沿语音 AI 系统 ([GitHub][1])

📰 News（更新日志）

原文 + 翻译

2025-12-16

We added more experimental speakers… including multilingual voices and 11 English styles

→ 新增更多实验性说话人，包括多语言声音以及 11 种不同风格的英语声音

2025-12-09

We added experimental speakers in nine languages (DE, FR, IT, JP, KR, NL, PL, PT, ES)

→ 新增支持 9 种语言的实验性语音（德语、法语、意大利语、日语、韩语、荷兰语、波兰语、葡萄牙语、西班牙语）

2025-12-03

We open-sourced VibeVoice-Realtime-0.5B…

→ 开源了 VibeVoice-Realtime-0.5B 实时 TTS 模型，支持：

流式文本输入
长文本语音生成
低延迟实时语音输出

说明（原文）

To mitigate deepfake risks…

→ 为了降低深度伪造风险并保证首段语音低延迟：

语音 prompt 使用嵌入格式提供
如需语音定制，需要联系官方团队
后续将持续扩展说话人类型

2025-09-05

→ 项目曾因被不当使用（偏离研究用途）而被临时禁用，直到确保合规使用才重新开放 ([GitHub][1])

📌 Overview（概述）

原文

VibeVoice is a novel framework designed for generating expressive, long-form, multi-speaker conversational audio…

翻译

VibeVoice 是一个新型语音生成框架，用于从文本生成：

富表达能力的语音
长时音频（long-form）
多说话人对话音频（如播客）

它解决了传统 TTS 系统的关键问题：

可扩展性（scalability）
说话人一致性（speaker consistency）
自然对话轮转（turn-taking） ([GitHub][1])

🧠 模型能力（Model Variants）

原文 + 翻译

1️⃣ 长文本多说话人模型

支持最长 90 分钟语音生成
支持最多 4 个说话人
支持：
- 单人语音
- 对话语音

👉 超越传统 TTS（通常只支持 1–2 人） ([GitHub][1])

2️⃣ 实时流式 TTS 模型

首包语音延迟约 300ms
支持流式输入文本
用于实时语音生成场景

⚙️ 核心技术（Core Innovation）

原文

continuous speech tokenizers… 7.5 Hz

翻译

VibeVoice 的核心创新包括：

1️⃣ 连续语音 Tokenizer（Acoustic + Semantic）

工作频率：7.5 Hz（超低帧率）
优势：
- 保持音质（audio fidelity）
- 大幅提升长序列处理效率

2️⃣ Next-token Diffusion 架构

使用 LLM：
- 理解文本语义
- 建模对话上下文
使用 扩散模型（diffusion head）：
- 生成高保真语音细节

👉 本质： LLM（语义） + Diffusion（音频细节）的融合架构 ([GitHub][1])

🎵 Demo 能力（示例）

支持生成：

英文语音
中文语音
跨语言语音（Cross-lingual）
即兴唱歌（Spontaneous Singing）
多人长对话（最多 4 人） ([GitHub][1])

⚠️ 风险与限制（Risks and Limitations）

原文 + 翻译

模型问题

可能生成：
- 不准确内容
- 偏见内容
- 非预期输出

Deepfake 风险

高质量语音可能被用于：

冒充（impersonation）
欺诈（fraud）
虚假信息传播

👉 要求：

确保文本真实
避免误导性使用
遵守法律法规

语言限制

当前主要支持：
- 英语
- 中文
其他语言可能出现异常输出

功能限制

不支持：
- 背景音
- 音乐
- 非语音音效

对话限制

不支持重叠说话（overlapping speech）

商业限制（重要）

不建议用于：

商业场景
生产环境

👉 当前定位：研究用途（Research Only） ([GitHub][1])

🧱 模型规模（补充）

（来自 README / 衍生文档）

模型	上下文长度	生成能力
1.5B	64K	~90分钟
7B（预览）	32K	~45分钟
0.5B（实时）	-	流式

([Replicate][2])

📌 核心总结（严格基于原文）

VibeVoice 本质是：

👉 一个 长文本 + 多说话人 + 高保真语音生成框架

其关键突破在于：

多人对话建模
长时语音生成（90min）
LLM + Diffusion 融合架构
高压缩语音 token 表达

👉 如果你要落地（建议方向）

结合你现在在做的系统（IM + 推荐 + AI平台），这个项目可以直接转成：

1️⃣ Voice Agent 层

多角色 AI 对话（客服 / 主播 / NPC）

2️⃣ 内容生成

自动播客 / 资讯播报
电商讲解（带情绪）

3️⃣ 根因分析语音化

报警 → 自动语音总结
多角色“专家讨论”形式输出

参考资料

🎙️ VibeVoice: 开源前沿语音 AI
- 原文
- 翻译
📰 News（更新日志）
- 原文 + 翻译
📌 Overview（概述）
- 原文
- 翻译
🧠 模型能力（Model Variants）
- 原文 + 翻译
  - 1️⃣ 长文本多说话人模型
  - 2️⃣ 实时流式 TTS 模型
⚙️ 核心技术（Core Innovation）
- 原文
- 翻译
  - 1️⃣ 连续语音 Tokenizer（Acoustic + Semantic）
  - 2️⃣ Next-token Diffusion 架构
🎵 Demo 能力（示例）
⚠️ 风险与限制（Risks and Limitations）
- 原文 + 翻译
🧱 模型规模（补充）
📌 核心总结（严格基于原文）
👉 如果你要落地（建议方向）
参考资料

OpenBB 金融数据平台

Mon, 30 Mar 2026 13:01:55 +0000

📊 OpenBB：金融数据平台

原文

Financial data platform for analysts, quants and AI agents.

翻译

面向分析师、量化研究员和 AI Agent 的金融数据平台 ([GitHub][1])

🧱 核心概念：Open Data Platform（ODP）

原文

Open Data Platform by OpenBB (ODP) is the open-source toolset that helps data engineers integrate proprietary, licensed, and public data sources into downstream applications like AI copilots and research dashboards.

翻译

OpenBB 的 Open Data Platform（ODP）是一个开源工具集，用于帮助数据工程师将：

私有数据
授权数据
公共数据

统一集成到下游应用中，例如：

AI Copilot
研究分析仪表盘 ([GitHub][1])

核心架构思想

原文

“connect once, consume everywhere”

翻译

一次接入，多处消费

数据消费层（原文 + 翻译）

ODP 将数据统一输出到多个消费层：

Python 环境（用于量化 / 工程）
OpenBB Workspace（分析 UI）
Excel（分析工具）
MCP servers（用于 AI agents）
REST APIs（其他系统调用） ([GitHub][1])

💻 快速示例（原文 + 翻译）

原文

from openbb import obb
output = obb.equity.price.historical("AAPL")
df = output.to_dataframe()

翻译

from openbb import obb
output = obb.equity.price.historical("AAPL")  # 获取股票历史价格
df = output.to_dataframe()                  # 转为 DataFrame

🧠 OpenBB Workspace（可视化层）

原文

OpenBB Workspace offers the enterprise UI for analysts to visualize datasets and leverage AI agents.

翻译

OpenBB Workspace 提供一个企业级 UI 界面，用于：

数据可视化
使用 AI Agent 进行分析 ([GitHub][1])

关系说明（原文语义）

ODP = 数据基础设施层
Workspace = UI + AI 层

👉 二者通过统一架构无缝连接

🔌 集成方式（ODP → Workspace）

原文流程 + 翻译

1️⃣ 启动后端

pip install "openbb[all]"
openbb-api

→ 启动一个 FastAPI 服务（默认地址：127.0.0.1:6900）

2️⃣ 在 Workspace 中连接

操作步骤：

进入 Apps 页面
点击 “Connect backend”
填写：
- Name: Open Data Platform
- URL: http://127.0.0.1:6900
点击 Test（测试成功）
点击 Add

📦 安装方式

Python 包

pip install openbb

CLI 安装

pip install openbb-cli

或源码安装

git clone https://github.com/OpenBB-finance/OpenBB.git

🧩 平台能力（来自 README + 官方）

数据能力

多数据源统一接入
标准化数据接口
避免 vendor lock-in
支持结构化 / 非结构化数据 ([OpenBB][2])

AI 能力

支持 AI Agents 接入
支持 Copilot / MCP
可构建 AI 分析应用 ([OpenBB][3])

部署能力

支持本地部署（on-prem）
支持私有云
数据不外泄
支持安全合规（SOC2 等） ([OpenBB][3])

UI 与协作

可定制 UI
支持团队协作
支持分析工作流 ([OpenBB][3])

🧱 设计理念（严格来自原文）

Data Layer

统一数据接入
标准化输出

Interface Layer

Python / CLI / UI 多入口

AI Layer

Agent 接入
AI Copilot

👉 本质是一个：

Data Platform + AI Platform + Analytics Workspace 的融合架构

⚠️ Disclaimer（免责声明）

原文核心

金融交易具有高风险
数据可能不准确
不对投资损失负责

翻译

金融市场交易存在高风险，可能导致部分或全部资金损失
平台数据不保证准确性
OpenBB 不对因使用数据产生的损失负责 ([GitHub][1])

🤝 Contributing（贡献方式）

三种方式：

成为贡献者
提交 Issue（Bug / Feature）
提供反馈（Discord / 社交平台） ([GitHub][1])

📌 核心总结（严格重述）

OpenBB 本质是：

👉 一个 “金融数据基础设施 + AI Agent 平台 + 分析工作台” 的统一系统

其核心机制：

Connect once, consume everywhere
数据 → 标准化 → 多端消费 → AI 使用

👉 给你的关键启发（结合你当前架构）

这个项目其实和你现在在做的方向高度一致（甚至可以作为参考蓝本）：

你现在做的是：

IM + 推荐 + AI + 数据平台

OpenBB 做的是：

数据平台 + AI Agent + 分析 UI

如果你要继续深入，我可以帮你直接做一版：

👉「OpenBB 架构 → 你平台的落地版」

包括：

数据接入层（事件流 + 标签体系）
AI Agent 平台（Skill + MCP）
Workspace 控台设计
表结构 + API + 权限模型

参考资料

📊 OpenBB：金融数据平台
- 原文
- 翻译
🧱 核心概念：Open Data Platform（ODP）
💻 快速示例（原文 + 翻译）
- 原文
- 翻译
🧠 OpenBB Workspace（可视化层）
🔌 集成方式（ODP → Workspace）
- 原文流程 + 翻译
  - 1️⃣ 启动后端
  - 2️⃣ 在 Workspace 中连接
📦 安装方式
🧩 平台能力（来自 README + 官方）
🧱 设计理念（严格来自原文）
⚠️ Disclaimer（免责声明）
- 原文核心
- 翻译
🤝 Contributing（贡献方式）
📌 核心总结（严格重述）
👉 给你的关键启发（结合你当前架构）
- 👉「OpenBB 架构 → 你平台的落地版」
参考资料

⚡ Fastfetch：系统信息展示工具

Mon, 30 Mar 2026 13:01:55 +0000

⚡ Fastfetch：系统信息展示工具

原文

A maintained, feature-rich and performance oriented, neofetch like system information tool.

翻译

一个持续维护、功能丰富、性能导向的系统信息工具，类似 neofetch。 ([GitHub][1])

📌 项目简介

原文

Fastfetch is a neofetch-like tool for fetching system information and displaying it in a visually appealing way.

翻译

Fastfetch 是一个类似 neofetch 的工具，用于：

获取系统信息
以美观的方式展示这些信息

原文

It is written mainly in C, with a focus on performance and customizability.

翻译

该工具主要使用 C 语言编写，重点关注：

性能（performance）
可定制性（customizability） ([GitHub][1])

支持平台

原文 → 翻译

支持多平台：

Linux
macOS
Windows 7+
Android
FreeBSD / OpenBSD / NetBSD
DragonFly / Haiku / illumos

⚙️ 安装方式（Installation）

Linux

原文 → 翻译（节选）

Ubuntu（PPA）
Debian / Ubuntu（apt 安装）
Arch Linux（pacman）
Fedora（dnf）
openSUSE（zypper）
Alpine（apk）

👉 如果发行版版本过旧，建议使用：

brew install fastfetch

macOS

brew install fastfetch

或：

sudo port install fastfetch

Windows

scoop install fastfetch
choco install fastfetch
winget install fastfetch

🧪 使用方式（Usage）

基本命令

fastfetch

→ 使用默认配置运行

查看所有模块

fastfetch -c all.jsonc

→ 查看所有支持的模块

输出 JSON 数据

fastfetch -s <module> --format json

→ 获取结构化数据

生成配置文件

fastfetch --gen-config

→ 生成最小配置

fastfetch --gen-config-full

→ 生成完整配置

🎨 配置系统（Customization）

原文

Fastfetch uses JSONC (JSON with comments) for configuration.

翻译

Fastfetch 使用 JSONC（带注释的 JSON） 作为配置格式。 ([GitHub][2])

默认配置路径

~/.config/fastfetch/config.jsonc

配置能力

控制显示内容（modules）
控制格式（format）
自定义 logo
自定义颜色

示例（原文语义）

可以通过 format 控制输出，例如：

fastfetch -s gpu --gpu-format '{name}'

→ 仅显示 GPU 名称

🧠 核心优势（FAQ）

原文问题

Neofetch is good enough. Why do I need fastfetch?

翻译（逐条）

1️⃣ 持续维护

Fastfetch 仍在积极维护

2️⃣ 更快

Fastfetch 性能更好（名字即含义）

3️⃣ 功能更多

支持更多模块和能力

4️⃣ 更强可配置性

提供更丰富的配置选项

5️⃣ 更精细输出

例如：

neofetch：23 G
fastfetch：22.97 GiB

6️⃣ 更准确

例如：

neofetch 不支持 Wayland
fastfetch 支持

⚠️ 安全警告（重要）

原文

Fastfetch supports a Command module that can run arbitrary shell commands.

翻译

Fastfetch 支持 Command 模块，可以执行任意 shell 命令。

👉 风险：

如果从不可信来源复制配置
可能执行恶意命令

👉 建议：

使用前务必检查配置文件

📂 项目结构（简要）

主要目录

src → 核心代码
presets → 配置示例
scripts → 工具脚本
doc → 文档
tests → 测试

🧠 核心架构（抽象）

原文语义总结（不扩展）

Fastfetch 的核心是：

系统信息检测
模块化展示
高性能输出

👉 本质：

一个“系统信息采集 + 可视化输出”的 CLI 引擎 ([DeepWiki][3])

📌 核心总结（严格重述）

Fastfetch 本质是：

👉 一个 高性能、可高度定制的系统信息展示工具（CLI）

核心特点：

C 语言实现（性能优先）
JSONC 配置（高度可定制）
多平台支持
模块化输出

👉 给你的关键启发（结合你当前架构）

这个项目虽然看起来简单，但设计其实很“工程化”，有几个你可以直接借鉴的点：

1️⃣ 模块化输出（非常关键）

每个模块 = 一类数据（CPU / GPU / 网络）
类似你可以做：
- 指标模块
- 日志模块
- Trace 模块

👉 本质：统一数据抽象层

2️⃣ 配置驱动（JSONC）

UI / 输出完全由配置控制
类似你可以做：
- 推荐规则 DSL
- Agent Prompt DSL

3️⃣ 多端消费

CLI / JSON / UI

👉 对应你：

控台 / API / AI Agent

参考资料

⚡ Fastfetch：系统信息展示工具
- 原文
- 翻译
📌 项目简介
- 原文
- 翻译
- 原文
- 翻译
- 支持平台
  - 原文 → 翻译
⚙️ 安装方式（Installation）
🧪 使用方式（Usage）
🎨 配置系统（Customization）
🧠 核心优势（FAQ）
- 原文问题
- 翻译（逐条）
⚠️ 安全警告（重要）
- 原文
- 翻译
📂 项目结构（简要）
- 主要目录
🧠 核心架构（抽象）
- 原文语义总结（不扩展）
📌 核心总结（严格重述）
👉 给你的关键启发（结合你当前架构）
参考资料

Deep-Live-Cam 实时换脸与视频 Deepfake

Mon, 30 Mar 2026 13:01:55 +0000

🎭 Deep-Live-Cam：实时换脸与视频 Deepfake

原文

real time face swap and one-click video deepfake with only a single image

翻译

基于单张图片即可实现：

实时人脸替换（face swap）
一键视频 Deepfake

([GitHub][1])

📌 项目简介

原文

Deep-Live-Cam is a real-time face swapping application…

翻译

Deep-Live-Cam 是一个实时换脸应用，支持：

图片换脸
视频换脸
摄像头实时换脸

通过结合深度学习模型与优化处理流程，实现跨平台实时性能。 ([DeepWiki][2])

🚀 核心能力（Features）

原文 + 翻译

🎯 一键实时 Deepfake

Select a face → 选择源人脸
Select camera → 选择摄像头
Press live → 点击开始

👉 三步完成实时换脸 ([GitHub][1])

🧠 多人脸支持（Face Mapping）

支持多个目标人物同时换脸 → 可在同一画面中替换多个人脸

👄 Mouth Mask（嘴部保留）

保留原始嘴部区域 → 提高口型同步与自然度

🎬 应用场景

实时直播（Live Show）
视频换脸（Your Movie, Your Face）
Meme 创作
虚拟角色演绎

([GitHub][1])

🧠 核心架构（Architecture）

分层结构

层级	组件	作用
Entry	run.py	启动入口
Core	core.py	生命周期管理
UI	ui.py	图形界面
Processing	frame processors	帧处理
Analysis	face_analyser	人脸检测
Model	ONNX / PyTorch	模型推理

([DeepWiki][2])

处理流程（Pipeline）

原文逻辑 → 翻译

人脸检测
人脸替换（face swap）
人脸增强（GFPGAN）
后处理（平滑/锐化等）

([DeepWiki][2])

⚙️ 技术栈（Tech Stack）

原文 + 翻译

ONNX Runtime → 执行换脸模型
PyTorch → 人脸增强模型
InsightFace → 人脸检测与特征提取
FFmpeg → 视频处理
OpenCV → 图像处理
CustomTkinter → GUI 界面

([DeepWiki][2])

🧩 运行模式（Modes）

三种模式

模式	描述
Image	单张图片处理
Video	视频逐帧处理
Live	摄像头实时处理

([DeepWiki][2])

🖥️ 使用方式（Usage）

GUI 模式

python run.py

→ 启动图形界面

CLI 模式

python run.py -s SOURCE -t TARGET

→ 无界面运行（自动化） ([DeepWiki][3])

基本流程

选择源人脸
选择目标（图片/视频/摄像头）
点击开始

([DeepWiki][3])

⚡ 硬件加速（Execution Providers）

支持多种硬件：

Provider	硬件
CPU	通用
CUDA	NVIDIA GPU
DirectML	AMD / Intel GPU
CoreML	Apple Silicon
OpenVINO	Intel

([DeepWiki][3])

📦 安装方式（核心步骤）

原文 → 翻译

1️⃣ 克隆仓库

git clone https://github.com/hacksider/Deep-Live-Cam.git

2️⃣ 下载模型

inswapper_128_fp16.onnx（换脸）
GFPGANv1.4.pth（增强）

3️⃣ 安装依赖

pip install -r requirements.txt

4️⃣ 运行

python run.py

([GitHub][1])

⚠️ 免责声明（非常重要）

原文核心

该项目明确强调：

道德使用（Ethical Use）

使用真实人物必须获得授权
发布时必须标注为 deepfake

内容限制

禁止处理：
- 色情内容
- 暴力内容
- 敏感素材

法律合规

必须遵守当地法律
项目可能在法律要求下关闭或加水印

用户责任

所有使用后果由用户自行承担

([GitHub][1])

🧠 核心总结（严格重述）

Deep-Live-Cam 本质是：

👉 一个 实时 Deepfake 引擎（Face Swap Engine）

核心能力：

单图驱动换脸
实时摄像头处理
多人脸 + 高性能推理
GPU 加速

⚠️ 你需要特别注意（工程视角）

这个项目虽然很强，但有几个关键点：

1️⃣ 技术本质

InsightFace + ONNX + GFPGAN 的组合
本质不是端到端模型，而是 pipeline

2️⃣ 实时能力关键

帧级处理（frame-by-frame）
GPU 是核心瓶颈

3️⃣ 风控是硬约束

内置 NSFW 检测
明确法律风险

👉 如果你要落地（非常关键）

这个项目对你现在做的系统（IM + AI平台）其实价值很大：

可以直接演进为：

1️⃣ 实时虚拟人（Avatar）

IM 视频通话 → AI 换脸
客服 / NPC / 主播

2️⃣ 内容生成引擎

短视频生成
Meme 自动化生产

3️⃣ AI Agent + 视频

多角色对话（结合你前面的语音模型）
“虚拟专家讨论”

参考资料

🎭 Deep-Live-Cam：实时换脸与视频 Deepfake
- 原文
- 翻译
📌 项目简介
- 原文
- 翻译
🚀 核心能力（Features）
- 原文 + 翻译
🧠 核心架构（Architecture）
- 分层结构
- 处理流程（Pipeline）
  - 原文逻辑 → 翻译
⚙️ 技术栈（Tech Stack）
- 原文 + 翻译
🧩 运行模式（Modes）
- 三种模式
🖥️ 使用方式（Usage）
⚡ 硬件加速（Execution Providers）
📦 安装方式（核心步骤）
- 原文 → 翻译
⚠️ 免责声明（非常重要）
- 原文核心
🧠 核心总结（严格重述）
⚠️ 你需要特别注意（工程视角）
👉 如果你要落地（非常关键）
参考资料

claudecode-howto 一个可视化、示例驱动的 Claude Code 使用指南

Mon, 30 Mar 2026 13:01:55 +0000

📘 项目说明（README）

原文

A visual, example-driven guide to Claude Code — from basic concepts to advanced agents, with copy-paste templates that bring immediate value.

翻译

一个可视化、示例驱动的 Claude Code 使用指南 —— 从基础概念到高级 Agent，提供可复制粘贴的模板，可立即产生实际价值。 ([linkedin.com][1])

📦 项目定位

原文

A complete toolkit and guide for building software using Claude Code.

翻译

一个完整的工具集与指南，用于使用 Claude Code 构建软件。

🧩 核心内容结构（推断自仓库结构）

该仓库主要由多个「Skills（技能模块）」组成，每个模块代表一种 Claude 的能力扩展或开发模式。

🛠️ 示例一：Code Review Skill（代码审查能力）

About

原文

This Claude Skill performs comprehensive code reviews with security, performance, and quality analysis.

翻译

该 Claude Skill 提供全面的代码审查能力，包括安全性、性能和代码质量分析。 ([模型上下文协议中心][2])

功能点

原文 + 翻译

1. Security Analysis（安全分析）

Authentication/authorization issues → 认证/授权问题
Data exposure risks → 数据泄露风险
Injection vulnerabilities → 注入漏洞
Cryptographic weaknesses → 加密缺陷
Sensitive data logging → 敏感数据日志问题

2. Performance Review（性能评估）

Algorithm efficiency (Big O analysis) → 算法效率（时间复杂度分析）
Memory optimization → 内存优化
Database query optimization → 数据库查询优化
Caching opportunities → 缓存优化机会
Concurrency issues → 并发问题

3. Code Quality（代码质量）

SOLID principles → SOLID 原则
Design patterns → 设计模式
Naming conventions → 命名规范
Documentation → 文档规范
Test coverage → 测试覆盖率

4. Maintainability（可维护性）

Code readability → 代码可读性
Function size (< 50 lines) → 函数长度（建议 < 50 行）
Cyclomatic complexity → 圈复杂度
Dependency management → 依赖管理
Type safety → 类型安全

审查输出模板

原文 + 翻译

Summary（总结）

Overall quality assessment (1-5) → 整体质量评分（1-5）
Key findings count → 关键问题数量
Recommended priority areas → 建议优先处理的领域

Critical Issues（关键问题）

Issue → 问题描述
Location → 文件 + 行号
Impact → 影响说明
Severity → 严重级别（Critical/High/Medium）
Fix → 修复建议（含代码示例）

分类问题

Security

列出安全漏洞及示例

Performance

列出性能问题及复杂度分析

Quality

列出代码质量问题及重构建议

Maintainability

列出可维护性问题及改进建议

🛠️ 示例二：Brand Voice Skill（品牌语气控制）

About

原文

This skill ensures all generated text adheres to defined brand voice, tone, and messaging guidelines.

翻译

该技能确保所有生成文本都符合品牌语气、风格和信息传达规范。 ([模型上下文协议中心][3])

Brand Identity（品牌定义）

Mission（使命）

Help teams automate their development workflows with AI → 帮助团队使用 AI 自动化开发流程

Values（价值观）

Simplicity → 简洁
Reliability → 可靠
Empowerment → 赋能

Tone of Voice（语气）

Friendly but professional → 友好但专业
Clear and concise → 清晰简洁
Confident → 自信
Empathetic → 共情用户

写作规范

Do（应该）

使用 “you” 与读者交流
使用主动语态
先写价值
使用具体示例
句子 < 20 词
使用列表
包含行动引导

Don’t（不应该）

避免企业套话
不要居高临下
不要用 “we believe”
避免全大写
不要大段文本
不要假设用户懂技术

🛠️ 示例三：API 文档生成 Skill

About

原文

This skill generates comprehensive API documentation from source code.

翻译

该技能可以从源代码中生成完整的 API 文档。 ([模型上下文协议中心][4])

功能

OpenAPI / Swagger 文档生成
API endpoint 文档
SDK 示例
集成指南

⚙️ 安装方式（通用）

原文

/plugin add https://github.com/luongnv89/claude-howto

翻译

在 Claude Code 中执行：

/plugin add https://github.com/luongnv89/claude-howto

或

git clone https://github.com/luongnv89/claude-howto.git ~/.claude/skills/xxx

🧠 核心思想（从内容抽象）

（这一部分是严格基于原文内容归纳，不扩展）

每个 Skill = 一个可复用的 AI 能力模块
强调：
- 模板化
- 自动化开发流程
- Agent 化能力
覆盖软件开发全流程：
- 编码
- 测试
- 文档
- CI/CD
- Code Review ([linkedin.com][1])

📌 总结（非扩展，仅重述）

该项目本质是：

👉 一个 Claude Code 的工程化最佳实践集合 + 可执行模板库

👉 接下来可以做的

如果你要真正用在你的平台（你现在在做自动化测试平台 + AI 根因分析），我可以帮你做：

把这些 Skill → 改造成你 IM / 控台体系的能力模块
输出：
- 表设计
- 事件流
- Agent 编排
- Prompt DSL

直接说你想深入哪一块（比如：Agent 架构 / Skill 平台化），我给你做成可落地设计。

[1]: https://www.linkedin.com/posts/luongnv89_github-luongnv89claude-howto-complete-activity-7410260629896183808-B3cB?utm_source=chatgpt.com “GitHub - luongnv89/claude-howto: A visual, example-driven guide to Claude Code — from basic concepts to advanced agents, with copy-paste templates that bring immediate value.	Luong NGUYEN”
[2]: https://www.aimcp.info/skills/e8f2a6b2-095c-49b7-8565-cbd4bf7a5bd8?utm_source=chatgpt.com “code-review-specialist - Claude Skill	MCP Hub	Model Context Protocol Hub”
[3]: https://www.aimcp.info/en/skills/3b930a09-8f69-415c-b0d4-af2383a5bc37?utm_source=chatgpt.com “brand-voice-consistency - Claude Skill	MCP Hub	Model Context Protocol Hub”
[4]: https://www.aimcp.info/skills/35f7fe1a-2bc2-4f59-81f6-9bc3e1a6816d?utm_source=chatgpt.com “api-documentation-generator - Claude Skill	MCP Hub	Model Context Protocol Hub”

参考资料

📘 项目说明（README）
- 原文
- 翻译
📦 项目定位
- 原文
- 翻译
🧩 核心内容结构（推断自仓库结构）
🛠️ 示例一：Code Review Skill（代码审查能力）
🛠️ 示例二：Brand Voice Skill（品牌语气控制）
🛠️ 示例三：API 文档生成 Skill
- About
  - 原文
- 翻译
- 功能
⚙️ 安装方式（通用）
- 原文
- 翻译
- 或
🧠 核心思想（从内容抽象）
📌 总结（非扩展，仅重述）
👉 接下来可以做的
参考资料

Insanely Fast Whisper 用于在本地设备上使用 Whisper 转录音频文件

Fri, 27 Mar 2026 13:01:55 +0000

Insanely Fast Whisper

一个“强主观配置（opinionated）”的 CLI 工具，用于在本地设备上使用 Whisper 转录音频文件！

基于 🤗 Transformers、Optimum 和 flash-attn 驱动。

简而言之（TL;DR） —— 使用 [OpenAI 的 Whisper Large v3]，在不到 98 秒 内即可转录 150 分钟（2.5 小时） 的音频。

极速转录已经成为现实！⚡️

pipx install insanely-fast-whisper==0.0.15 --force

如果你还不相信，以下是在 Nvidia A100 - 80GB 上进行的一些基准测试 👇

优化类型	转录时间（150 分钟音频）
large-v3 (Transformers) (`fp32`)	~31 分钟（31 分 1 秒）
large-v3 (Transformers) (`fp16` + `batching [24]` + `bettertransformer`)	~5 分钟（5 分 2 秒）
large-v3 (Transformers) (`fp16` + `batching [24]` + Flash Attention 2)	~2 分钟（1 分 38 秒）
distil-large-v2 (Transformers) (`fp16` + `batching [24]` + `bettertransformer`)	~3 分钟（3 分 16 秒）
distil-large-v2 (Transformers) (`fp16` + `batching [24]` + Flash Attention 2)	~1 分钟（1 分 18 秒）
large-v2 (Faster Whisper) (`fp16` + `beam_size [1]`)	~9 分 23 秒
large-v2 (Faster Whisper) (`8-bit` + `beam_size [1]`)	~8 分 15 秒

附注（P.S.）：我们也在 Google Colab 的 T4 GPU 实例上运行了这些基准测试。

附注（P.P.S.）：该项目最初是为了展示 Transformers 的性能基准而创建的，但后来逐渐演变为一个轻量级 CLI 工具供用户使用。该项目完全由社区驱动，我们会优先添加社区需求强烈的功能。

🆕 通过终端实现极速转录 ⚡️

我们新增了 CLI 工具来支持快速转录，使用方式如下：

使用 pipx 安装（先安装 pipx：pip install pipx 或 brew install pipx）：

pipx install insanely-fast-whisper

⚠️ 如果你使用的是 Python 3.11.xx，pipx 可能会错误解析版本号，并安装一个非常旧的版本（0.0.8），该版本已无法兼容当前的 BetterTransformers。此时可以通过以下方式安装最新版本：

pipx install insanely-fast-whisper --force --pip-args="--ignore-requires-python"

如果使用 pip 安装，则可以直接添加参数：

pip install insanely-fast-whisper --ignore-requires-python

在任意路径运行推理：

insanely-fast-whisper --file-name <文件路径或URL>

注意：在 macOS 上运行时，还需要添加 --device-id mps 参数

🔥 使用 CLI 运行 Whisper Large v3 + Flash Attention 2：

insanely-fast-whisper --file-name <文件路径或URL> --flash True

🌟 使用 distil-whisper：

insanely-fast-whisper --model-name distil-whisper/large-v2 --file-name <文件路径或URL>

如果不想安装，也可以直接运行：

pipx run insanely-fast-whisper --file-name <文件路径或URL>

注意该 CLI 具有强主观设计，仅支持 NVIDIA GPU 和 Mac。建议查看默认配置和可选参数，以最大化转录吞吐量。使用 insanely-fast-whisper --help 查看全部参数。

CLI 参数说明

该项目支持在多种环境下运行 Whisper，目前支持 CUDA 和 macOS 的 mps：

-h, --help
    显示帮助信息

--file-name
    待转录音频文件路径或 URL

--device-id
    GPU 设备 ID（CUDA 传设备编号，Mac 使用 "mps"，默认 "0"）

--transcript-path
    输出文件路径（默认 output.json）

--model-name
    使用的模型名称（默认 openai/whisper-large-v3）

--task {transcribe, translate}
    执行任务：转录或翻译（默认 transcribe）

--language
    输入音频语言（默认自动检测）

--batch-size
    批处理大小（默认 24，OOM 时可调小）

--flash
    是否启用 Flash Attention 2（默认 False）

--timestamp {chunk, word}
    时间戳粒度（chunk 或 word，默认 chunk）

--hf-token
    Hugging Face token，用于 Pyannote 说话人分离

--diarization_model
    说话人分离模型（默认 pyannote/speaker-diarization）

--num-speakers
    指定说话人数（不能与 min/max 同时使用）

--min-speakers
    最小说话人数

--max-speakers
    最大说话人数

常见问题（FAQ）

如何正确安装 flash-attn？

pipx runpip insanely-fast-whisper install flash-attn --no-build-isolation

Windows 出现 CUDA 错误如何解决？

错误：

AssertionError: Torch not compiled with CUDA enabled

解决方法：

python -m pip install torch torchvision torchaudio --index-url https://download.pytorch.org/whl/cu121

Mac 上如何避免 OOM（内存溢出）？

mps 后端优化不如 CUDA，占用显存更高
推荐参数：

--batch-size 4 --device-id mps

（大约占用 12GB 显存）

不使用 CLI，如何直接使用 Whisper？

安装依赖：

pip install --upgrade transformers optimum accelerate

示例代码：

import torch
from transformers import pipeline
from transformers.utils import is_flash_attn_2_available

pipe = pipeline(
    "automatic-speech-recognition",
    model="openai/whisper-large-v3",
    torch_dtype=torch.float16,
    device="cuda:0",
    model_kwargs={
        "attn_implementation": "flash_attention_2"
    } if is_flash_attn_2_available() else {
        "attn_implementation": "sdpa"
    },
)

outputs = pipe(
    "<FILE_NAME>",
    chunk_length_s=30,
    batch_size=24,
    return_timestamps=True,
)

outputs

致谢

OpenAI Whisper 团队开源了优秀模型
Hugging Face Transformers 团队持续维护 Whisper
Hugging Face Optimum 团队提供 BetterTransformer API
Patrick Arminio 在 CLI 构建中提供了巨大帮助

社区展示

@ochen1 构建了 CLI MVP https://github.com/ochen1/insanely-fast-whisper-cli
@arihanv 构建了应用（NextJS + Modal） https://github.com/arihanv/Shush
@kadirnar 构建了优化版 Python 包 https://github.com/kadirnar/whisper-plus

参考资料

Insanely Fast Whisper
参考资料

Claude Code 的多智能体编排系统。零学习曲线

Fri, 27 Mar 2026 13:01:55 +0000

oh-my-claudecode

Codex 用户： 查看 oh-my-codex — 为 OpenAI Codex CLI 提供同样的编排体验。

Claude Code 的多智能体编排系统。零学习曲线。

无需学习 Claude Code，直接使用 OMC。

快速开始

第一步：安装

/plugin marketplace add https://github.com/Yeachan-Heo/oh-my-claudecode
/plugin install oh-my-claudecode

第二步：配置

/omc-setup

第三步：开始构建

autopilot: build a REST API for managing tasks

就这么简单。其余都是自动的。

不确定从哪里开始？

如果你对需求不明确、有模糊的想法，或者想要精细控制设计：

/deep-interview "I want to build a task management app"

深度访谈使用苏格拉底式提问在编写任何代码之前帮你理清思路。它揭示隐藏假设并通过加权维度衡量清晰度，确保你在执行前明确知道要构建什么。

Team 模式（推荐）

从 v4.1.7 开始，Team 是 OMC 的标准编排方式。swarm 和 ultrapilot 等旧版入口仍受支持，但现在在底层路由到 Team。

/team 3:executor "fix all TypeScript errors"

Team 按阶段化流水线运行：

team-plan → team-prd → team-exec → team-verify → team-fix (loop)

在 ~/.claude/settings.json 中启用 Claude Code 原生团队：

{
  "env": {
    "CLAUDE_CODE_EXPERIMENTAL_AGENT_TEAMS": "1"
  }
}

如果团队被禁用，OMC 会发出警告并在可能的情况下回退到非 Team 执行模式。

tmux CLI 工作者 — Codex & Gemini (v4.4.0+)

v4.4.0 移除了 Codex/Gemini MCP 服务器（x、g 提供商）。请改用 /omc-teams 在 tmux 分屏中启动真实的 CLI 进程：

/omc-teams 2:codex   "review auth module for security issues"
/omc-teams 2:gemini  "redesign UI components for accessibility"
/omc-teams 1:claude  "implement the payment flow"

如需在一个命令中混合使用 Codex + Gemini，请使用 /ccg 技能：

/ccg Review this PR — architecture (Codex) and UI components (Gemini)

技能	工作者	最适合
`/omc-teams N:codex`	N 个 Codex CLI 窗格	代码审查、安全分析、架构
`/omc-teams N:gemini`	N 个 Gemini CLI 窗格	UI/UX 设计、文档、大上下文任务
`/omc-teams N:claude`	N 个 Claude CLI 窗格	通过 tmux 中的 Claude CLI 处理通用任务
`/ccg`	1 个 Codex + 1 个 Gemini	并行三模型编排

工作者按需生成，任务完成后自动退出 — 无空闲资源浪费。需要安装 codex / gemini CLI 并有活跃的 tmux 会话。

注意：包命名 — 项目品牌名为 oh-my-claudecode（仓库、插件、命令），但 npm 包以 oh-my-claude-sisyphus 发布。通过 npm/bun 安装 CLI 工具时，请使用 npm install -g oh-my-claude-sisyphus。

更新

# 1. 更新 marketplace 克隆
/plugin marketplace update omc

# 2. 重新运行设置以刷新配置
/omc-setup

注意： 如果 marketplace 自动更新未启用，您需要在运行设置之前手动执行 /plugin marketplace update omc 来同步最新版本。

如果更新后遇到问题，清除旧的插件缓存：

/omc-doctor

你的 Claude 已被注入超能力。

为什么选择 oh-my-claudecode？

无需配置 - 开箱即用，智能默认设置
Team 优先编排 - Team 是标准的多智能体界面（swarm/ultrapilot 是兼容性外观）
自然语言交互 - 无需记忆命令，只需描述你的需求
自动并行化 - 复杂任务自动分配给专业智能体
持久执行 - 不会半途而废，直到任务验证完成
成本优化 - 智能模型路由节省 30-50% 的 token
从经验中学习 - 自动提取并复用问题解决模式
实时可见性 - HUD 状态栏显示底层运行状态

功能特性

执行模式

针对不同场景的多种策略 - 从全自动构建到 token 高效重构。

了解更多 →

模式	特点	适用场景
Team（推荐）	阶段化流水线	在共享任务列表上协作的 Claude 智能体
omc-teams	tmux CLI 工作者	Codex/Gemini CLI 任务；按需生成，完成后退出
ccg	三模型并行	Codex（分析）+ Gemini（设计），Claude 合成
Autopilot	自主执行	最小化繁琐配置的端到端功能开发
Ultrawork	最大并行	不需要 Team 的并行修复/重构
Ralph	持久模式	必须完整完成的任务
Pipeline	顺序处理	需要严格顺序的多阶段转换
Swarm / Ultrapilot（旧版）	路由到 Team	现有工作流和旧文档

智能编排

32 个专业智能体 涵盖架构、研究、设计、测试、数据科学
智能模型路由 - 简单任务用 Haiku，复杂推理用 Opus
自动委派 - 每次都选择最合适的智能体

开发者体验

魔法关键词 - ralph、ulw、plan 提供显式控制
HUD 状态栏 - 状态栏实时显示编排指标
技能学习 - 从会话中提取可复用模式
分析与成本追踪 - 了解所有会话的 token 使用情况

自定义技能

一次学习，永久复用。OMC 将调试过程中获得的实战知识提取为可移植的技能文件，并在相关场景中自动注入。

	项目作用域	用户作用域
路径	`.omc/skills/`	`~/.omc/skills/`
共享范围	团队（受版本控制）	所有项目通用
优先级	高（覆盖用户作用域）	低（回退）

# .omc/skills/fix-proxy-crash.md
---
name: Fix Proxy Crash
description: aiohttp proxy crashes on ClientDisconnectedError
triggers: ["proxy", "aiohttp", "disconnected"]
source: extracted
---
在 server.py:42 的处理程序外包裹 try/except ClientDisconnectedError...

技能管理： /skill list | add | remove | edit | search 自动学习： /learner 以严格的质量标准提取可复用模式 自动注入： 匹配的技能自动加载到上下文中 — 无需手动调用

完整功能列表 →

魔法关键词

为高级用户提供的可选快捷方式。不用它们，自然语言也能很好地工作。

关键词	效果	示例
`team`	标准 Team 编排	`/team 3:executor "fix all TypeScript errors"`
`omc-teams`	tmux CLI 工作者 (codex/gemini/claude)	`/omc-teams 2:codex "security review"`
`ccg`	三模型 Codex+Gemini 编排	`/ccg review this PR`
`autopilot`	全自动执行	`autopilot: build a todo app`
`ralph`	持久模式	`ralph: refactor auth`
`ulw`	最大并行化	`ulw fix all errors`
`plan`	规划访谈	`plan the API`
`ralplan`	迭代规划共识	`ralplan this feature`
`deep-interview`	苏格拉底式需求澄清	`deep-interview "vague idea"`
`swarm`	已弃用 — 请使用 `team`	`swarm 5 agents: fix lint errors`
`ultrapilot`	已弃用 — 请使用 `team`	`ultrapilot: build a fullstack app`

注意：

ralph 包含 ultrawork： 激活 ralph 模式时，会自动包含 ultrawork 的并行执行。无需组合关键词。
swarm N agents 语法仍可被识别用于提取智能体数量，但运行时在 v4.1.7+ 中由 Team 支持。

实用工具

速率限制等待

当速率限制重置时自动恢复 Claude Code 会话。

omc wait          # 检查状态，获取指导
omc wait --start  # 启用自动恢复守护进程
omc wait --stop   # 禁用守护进程

需要： tmux（用于会话检测）

通知标签配置 (Telegram/Discord/Slack)

你可以配置 stop 回调发送会话摘要时要 @ 谁。

# 设置/替换标签列表
omc config-stop-callback telegram --enable --token <bot_token> --chat <chat_id> --tag-list "@alice,bob"
omc config-stop-callback discord --enable --webhook <url> --tag-list "@here,123456789012345678,role:987654321098765432"
omc config-stop-callback slack --enable --webhook <url> --tag-list "<!here>,<@U1234567890>"

# 增量更新
omc config-stop-callback telegram --add-tag charlie
omc config-stop-callback discord --remove-tag @here
omc config-stop-callback discord --clear-tags

标签规则：

Telegram：alice 会规范化为 @alice
Discord：支持 @here、@everyone、纯数字用户 ID、role:<id>
Slack：支持 <@MEMBER_ID>、<!channel>、<!here>、<!everyone>、<!subteam^GROUP_ID>
file 回调会忽略标签选项

OpenClaw 集成

将 Claude Code 会话事件转发到 OpenClaw 网关，通过您的 OpenClaw 代理实现自动化响应和工作流程。

快速设置（推荐）：

/oh-my-claudecode:configure-notifications
# → 提示时输入 "openclaw" → 选择 "OpenClaw Gateway"

手动设置： 创建 ~/.claude/omc_config.openclaw.json：

{
  "enabled": true,
  "gateways": {
    "my-gateway": {
      "url": "https://your-gateway.example.com/wake",
      "headers": { "Authorization": "Bearer YOUR_TOKEN" },
      "method": "POST",
      "timeout": 10000
    }
  },
  "hooks": {
    "session-start": { "gateway": "my-gateway", "instruction": "Session started for ", "enabled": true },
    "stop":          { "gateway": "my-gateway", "instruction": "Session stopping for ", "enabled": true }
  }
}

环境变量：

变量	说明
`OMC_OPENCLAW=1`	启用 OpenClaw
`OMC_OPENCLAW_DEBUG=1`	启用调试日志
`OMC_OPENCLAW_CONFIG=/path/to/config.json`	覆盖配置文件路径

支持的钩子事件（bridge.ts 中 6 个活跃）：

| 事件 | 触发时机 | 主要模板变量 | |——|———|————-| | session-start | 会话开始时 | ,, | | `stop` | Claude 响应完成时 |, | | `keyword-detector` | 每次提交提示词时 |, | | `ask-user-question` | Claude 请求用户输入时 |, | | `pre-tool-use` | 工具调用前（高频） |, | | `post-tool-use` | 工具调用后（高频） |, `` |

回复通道环境变量：

变量	说明
`OPENCLAW_REPLY_CHANNEL`	回复通道（例如 `discord`）
`OPENCLAW_REPLY_TARGET`	频道 ID
`OPENCLAW_REPLY_THREAD`	线程 ID

参见 scripts/openclaw-gateway-demo.mjs，这是一个通过 ClawdBot 将 OpenClaw 有效载荷转发到 Discord 的参考网关。

文档

完整参考 - 完整功能文档
CLI 参考 - 所有 omc 命令、标志和工具
通知指南 - Discord、Telegram、Slack 和 webhook 设置
推荐工作流 - 常见任务的经过实战检验的技能链
发布说明 - 每个版本的新内容
网站 - 交互式指南和示例
迁移指南 - 从 v2.x 升级
架构 - 底层工作原理
性能监控 - 智能体追踪、调试和优化

环境要求

Claude Code CLI
Claude Max/Pro 订阅或 Anthropic API 密钥

可选：多 AI 编排

OMC 可以选择性地调用外部 AI 提供商进行交叉验证和设计一致性检查。非必需 — 没有它们 OMC 也能完整运行。

提供商	安装	功能
Gemini CLI	`npm install -g @google/gemini-cli`	设计审查、UI 一致性（1M token 上下文）
Codex CLI	`npm install -g @openai/codex`	架构验证、代码审查交叉检查

费用： 3 个 Pro 计划（Claude + Gemini + ChatGPT）每月约 $60 即可覆盖所有功能。

开源协议

MIT

**灵感来源：** [oh-my-opencode](https://github.com/code-yeongyu/oh-my-opencode) • [claude-hud](https://github.com/ryanjoachim/claude-hud) • [Superpowers](https://github.com/obra/superpowers) • [everything-claude-code](https://github.com/affaan-m/everything-claude-code) • [Ouroboros](https://github.com/Q00/ouroboros) **零学习曲线。最强大能。**

Star 历史

💖 支持本项目

如果 Oh-My-ClaudeCode 帮助了你的工作流，请考虑赞助：

为什么赞助？

保持项目活跃开发
赞助者获得优先支持
影响路线图和功能
帮助维护自由开源

其他帮助方式

⭐ 为仓库加星
🐛 报告问题
💡 提出功能建议
📝 贡献代码

参考资料

oh-my-claudecode
参考资料

Dexter 是一个自主金融研究智能体，能够在工作过程中进行思考、规划和学习。它通过任务规划、自我反思以及实时市场数据来执行分析。可以将其理解为类似 Claude Code，但专门为金融研究打造。

Fri, 27 Mar 2026 13:01:55 +0000

Dexter 🤖

Dexter 是一个自主金融研究智能体，能够在工作过程中进行思考、规划和学习。它通过任务规划、自我反思以及实时市场数据来执行分析。可以将其理解为类似 Claude Code，但专门为金融研究打造。

👋 概览

Dexter 可以将复杂的金融问题转化为清晰的、逐步执行的研究计划。它使用实时市场数据运行这些任务，检查自身工作，并不断优化结果，直到得到一个有信心、数据支撑的答案。

核心能力：

智能任务规划：自动将复杂查询拆解为结构化的研究步骤
自主执行：选择并执行合适的工具来获取金融数据
自我验证：检查自身结果并迭代，直到任务完成
实时金融数据：可访问损益表、资产负债表和现金流量表
安全机制：内置循环检测和步骤限制，防止无限执行

✅ 前置条件

Bun 运行时（v1.0 或更高版本）
OpenAI API Key（获取地址：https://platform.openai.com/api-keys）
Financial Datasets API Key（获取地址：https://financialdatasets.ai）
Exa API Key（获取地址：https://exa.ai）（可选，用于网页搜索）

安装 Bun

如果尚未安装 Bun，可以使用 curl 进行安装：

macOS / Linux：

curl -fsSL https://bun.com/install | bash

Windows：

powershell -c "irm bun.sh/install.ps1|iex"

安装完成后，重启终端并验证：

bun --version

💻 安装方式

克隆仓库：

git clone https://github.com/virattt/dexter.git
cd dexter

使用 Bun 安装依赖：

bun install

配置环境变量：

# 复制示例环境变量文件
cp env.example .env

# 编辑 .env 并添加 API Key（如果使用云服务）
# OPENAI_API_KEY=your-openai-api-key
# ANTHROPIC_API_KEY=your-anthropic-api-key（可选）
# GOOGLE_API_KEY=your-google-api-key（可选）
# XAI_API_KEY=your-xai-api-key（可选）
# OPENROUTER_API_KEY=your-openrouter-api-key（可选）

# 面向智能体的机构级市场数据；AAPL、NVDA、MSFT 免费
# FINANCIAL_DATASETS_API_KEY=your-financial-datasets-api-key

# （可选）如果本地使用 Ollama
# OLLAMA_BASE_URL=http://127.0.0.1:11434

# Web 搜索（优先 Exa，Tavily 作为备用）
# EXASEARCH_API_KEY=your-exa-api-key
# TAVILY_API_KEY=your-tavily-api-key

🚀 运行方式

以交互模式运行 Dexter：

bun start

开发模式（带监听）：

bun dev

📊 评估方式

Dexter 内置评估套件，可基于金融问题数据集对智能体进行测试。评估使用 LangSmith 进行跟踪，并采用“LLM 作为裁判（LLM-as-judge）”的方法对正确性进行评分。

运行全部问题：

bun run src/evals/run.ts

运行随机样本：

bun run src/evals/run.ts --sample 10

评估运行器会显示实时 UI，包括进度、当前问题以及实时准确率统计。结果会记录到 LangSmith 以供分析。

🐛 调试方式

Dexter 会将所有工具调用记录到 scratchpad 文件中，用于调试和历史追踪。每个查询会在 .dexter/scratchpad/ 下生成一个新的 JSONL 文件。

scratchpad 目录结构：

.dexter/scratchpad/
├── 2026-01-30-111400_9a8f10723f79.jsonl
├── 2026-01-30-143022_a1b2c3d4e5f6.jsonl
└── ...

每个文件包含按行分隔的 JSON 记录，内容包括：

init：原始查询
tool_result：每次工具调用（参数、原始结果、LLM 总结）
thinking：智能体的推理步骤

示例：

{"type":"tool_result","timestamp":"2026-01-30T11:14:05.123Z","toolName":"get_income_statements","args":{"ticker":"AAPL","period":"annual","limit":5},"result":{...},"llmSummary":"Retrieved 5 years of Apple annual income statements showing revenue growth from $274B to $394B"}

这使得你可以清晰地查看智能体获取了哪些数据，以及如何理解这些结果。

📱 如何与 WhatsApp 一起使用

通过连接网关，你可以在 WhatsApp 中与 Dexter 进行对话。你发送给自己的消息会由 Dexter 处理，并将回复发送回同一聊天窗口。

快速开始：

# 绑定 WhatsApp 账号（扫描二维码）
bun run gateway:login

# 启动网关
bun run gateway

然后打开 WhatsApp，进入“给自己发消息”的聊天窗口，即可向 Dexter 提问。

详细配置、参数说明和故障排查请参考： src/gateway/channels/whatsapp/README.md

🤝 如何贡献

Fork 仓库
创建功能分支
提交修改
推送分支
创建 Pull Request

重要说明：请保持 PR 小而聚焦，这将有助于更容易进行审核和合并。

📄 许可证

本项目基于 MIT License 开源。

参考资料

Dexter 🤖
参考资料

Twenty 免费的现代化 CRM 工具

Fri, 27 Mar 2026 13:01:55 +0000

为什么选择 Twenty

我们构建 Twenty 有三个原因：

CRM 太昂贵，而且用户被“锁定”。 企业通过锁定客户数据来提高价格，这种情况不应该存在。

需要一个全新的起点来打造更好的体验。 我们可以从过去的错误中学习，并结合 Notion、Airtable、Linear 等工具的新型 UX 模式，打造一致且现代的用户体验。

我们相信开源和社区的力量。 目前已有数百名开发者共同参与构建 Twenty。一旦插件能力完善，将围绕其形成完整生态系统。

使用 Twenty 可以做什么

如果你有特定需求，欢迎通过创建 Issue 告知我们。

目前已实现的部分功能包括：

个性化布局（筛选、排序、分组、看板、表格视图）
自定义对象与字段
基于自定义角色的权限管理
基于触发器和动作的工作流自动化
邮件、日历事件、文件等功能

个性化布局（筛选 / 排序 / 分组 / 看板 / 表格视图）

支持通过多种方式组织数据，包括：

过滤条件（Filters）
排序（Sort）
分组（Group By）
看板视图（Kanban）
表格视图（Table）

自定义对象与字段

支持灵活定义数据模型：

创建自定义对象（类似 CRM 中的实体）
添加和修改字段结构
满足不同业务场景的数据建模需求

基于自定义角色的权限管理

支持：

创建不同角色（Roles）
精细化权限控制
管理用户访问与操作范围

基于触发器与动作的工作流自动化

支持构建自动化流程：

触发条件（Triggers）
自动执行动作（Actions）
用于提升业务流程效率

邮件、日历、文件等能力

内置基础协作能力：

邮件集成
日历事件管理
文件管理
以及更多扩展能力

技术栈

TypeScript
Nx（Monorepo 构建工具）
NestJS（后端框架）
- BullMQ（任务队列）
- PostgreSQL（数据库）
- Redis（缓存/队列）
React（前端框架）
- Jotai（状态管理）
- Linaria（样式方案）
- Lingui（国际化）

致谢

感谢以下优秀服务（我们正在使用并推荐）：

Chromatic（UI 测试）
Greptile（代码审查）
Sentry（错误监控）
Crowdin（翻译平台）
E2B

加入社区

给项目点 Star
订阅版本发布（watch → custom → releases）
在 Twitter 或 LinkedIn 上关注我们
加入 Discord 社区
在 Crowdin 上参与翻译
欢迎提交贡献（Contributions）

参考资料

为什么选择 Twenty
使用 Twenty 可以做什么
技术栈
致谢
加入社区
参考资料

Claude Subconscious 将Letta Agent 的记忆系统挂载到 Claude

Thu, 26 Mar 2026 13:01:55 +0000

安装笔记

claude plugin marketplace add letta-ai/claude-subconscious
claude plugin install claude-subconscious@claude-subconscious

🧠 Claude Subconscious

🚀 项目简介

如果你使用过 Claude Code，可能会发现一个问题：

它会忽略 CLAUDE.md
无法记住你设置的偏好
会忘记会话中的高层目标
一旦发生上下文压缩（compaction），之前的信息就丢失 ([Cameron][1])

👉 简单说：Claude 是“无记忆的”

💡 项目动机

作者来自 Letta（专注于 AI 记忆系统），核心想法是：

为什么不给 Claude 加一层“长期记忆”？

因此构建了：

Claude Subconscious（潜意识层）

🧠 Claude Subconscious 是什么

Claude Subconscious 是一个：

Claude Code 插件（Plugin）

其核心作用：

将 Letta Agent 的记忆系统挂载到 Claude
将你和 Claude 的对话同步给一个后台 Agent
让 Agent 维护“长期记忆”
并在后续会话中影响 Claude 的行为 ([Cameron][1])

🔁 工作原理（核心机制）

1️⃣ 双层结构（显式 + 潜意识）

系统包含两层：

🧍 显意识（Claude 本体）

当前上下文
当前对话

🧠 潜意识（Letta Agent）

长期记忆
用户偏好
项目上下文
历史模式

2️⃣ 记忆注入机制（关键点）

Claude Subconscious 会：

自动将 Agent 的记忆块注入到 CLAUDE.md 中

示例结构：

<!-- Letta agent memory is automatically synced below -->

<letta>
  <letta_context>
    Subconscious Layer (Letta Agent)
    ...
  </letta_context>
</letta>

👉 本质是：

通过“伪系统提示 + 结构化注入”实现长期记忆

3️⃣ 会话监听与同步

插件监听 Claude 对话
将对话发送给 Letta Agent
Agent：
- 更新 memory blocks
- 生成指导信息（guidance）

👉 这些信息会在下一轮对话中影响 Claude

4️⃣ 潜意识指导机制

Agent 可以通过：

<letta_message>

向 Claude 注入“指导信息”，用于：

提供背景知识
提供上下文补充
做研究或提示方向

👉 注意：

不是直接改 Claude 输出，而是引导

🧱 Memory Blocks（记忆块）

Agent 会维护结构化长期记忆，例如：

用户偏好
项目背景
历史决策
会话模式

👉 这些内容：

跨 session 持久存在

⚡ 并发与多会话能力

Claude Subconscious 基于 Letta 的：

Conversations API（支持并行）

能力包括：

多个 Claude 会话共享同一个 Agent
实时更新 memory
支持跨项目记忆共享 ([Cameron][1])

🧩 使用方式

在 Claude Code 中安装：

/plugin install github:letta-ai/claude-subconscious

🔐 依赖条件

需要 Letta 账户
需要 API Key
推理可能收费（但有免费模型）

🧠 行为特性（关键细节）

📌 首次消息行为

Claude 会被要求：

在新会话中告知用户：

当前被 Subconscious 监控
提供 Agent 可视化链接

📌 异步观察机制

Subconscious Agent：

异步观察对话
不阻塞 Claude 响应
在后台更新记忆

📌 可交互性

用户可以：

主动“对潜意识说话”
Agent 会在下一次同步中回应

🏗️ 架构本质（非常关键）

该系统的真实架构是：

用户
 ↓
Claude（短期上下文）
 ↓
Claude Subconscious 插件
 ↓
Letta Agent（长期记忆 + 推理）

🎯 核心能力总结

✅ 1. 长期记忆（Persistent Memory）

跨 session 保留信息

✅ 2. 上下文增强（Context Injection）

自动注入记忆到 Prompt

✅ 3. 行为引导（Guidance Layer）

通过 memory + message 影响 Claude

✅ 4. 多会话共享（Shared Brain）

多个 session 共用同一 Agent

⚠️ 本质理解（非常重要）

Claude Subconscious 并不是：

❌ 改 Claude 模型 ❌ 扩大上下文窗口

而是：

✅ 在 Claude 外面加了一层“长期记忆代理（Memory Agent）”

🧠 一句话总结

Claude Subconscious = Claude + 外挂记忆系统（Letta Agent）+ Prompt 注入机制

🔥 工程视角点评（给你这个架构背景的重点）

这个项目的价值非常明确：

它解决的问题

Claude 无法跨会话记忆
上下文压缩导致信息丢失
无法形成“长期认知”

它的技术本质

属于：

Memory Augmented LLM（记忆增强型 LLM）

实现方式：

Prompt Injection（注入）
External Memory（外部记忆）
Agent Loop（代理循环）

类比你现在在做的系统

你可以把它理解为：

组件	类比
Claude	推理引擎
Letta Agent	用户画像 + 知识库
Subconscious	中间件（Memory Middleware）

🚨 延伸（关键思考）

这个设计其实隐含一个重要范式：

未来 AI = 模型 + 记忆 + 工具 + 控制层

而 Claude Subconscious 正在补齐：

👉 “记忆层”

参考资料

安装笔记
🧠 Claude Subconscious
参考资料

Strix 开源 AI 黑客（AI Agents），用于保障你的应用安全

Thu, 26 Mar 2026 13:01:55 +0000

🦉 Strix

🚀 项目简介

开源 AI 黑客（AI Agents），用于保障你的应用安全

Strix 是一组：

自治 AI 代理（Autonomous AI Agents）

其行为类似真实黑客：

动态运行你的代码
主动寻找漏洞
使用真实 PoC（Proof of Concept）进行验证 ([GitHub][1])

👉 面向对象：

开发者
安全团队

👉 解决的问题：

手动渗透测试成本高
静态扫描误报多 ([Strix][2])

🧠 核心定义

Strix 本质是：

AI 驱动的自动化渗透测试系统（AI Pentesting Agents）

🎯 核心能力

🔧 1. 黑客工具链（内置完整能力）

Strix Agent 自带完整攻击工具：

HTTP Proxy（请求/响应拦截与篡改）
浏览器自动化（多 Tab 测试 XSS / 登录流程）
终端环境（执行命令）
Python Runtime（编写 exploit）
信息收集（OSINT / attack surface mapping）
代码分析（静态 + 动态） ([GitHub][1])

✅ 2. “真实验证”漏洞（关键点）

不同于传统工具：

❌ 静态扫描 → 大量误报 ✅ Strix → 生成 PoC 验证漏洞

👉 只输出：

“可被利用的真实漏洞” ([Strix][2])

🤝 3. 多 Agent 协作（Graph of Agents）

多个 AI Agent 分工：
- 探测
- 利用
- 验证
支持并行执行
自动共享发现

👉 本质：

多智能体协同攻击系统（Multi-Agent Security System）

🔄 4. 自动修复（Auto-fix）

自动生成修复建议
输出安全报告
加速漏洞修复流程 ([GitHub][1])

💻 5. 开发者优先 CLI

CLI 工具（交互 / 非交互模式）
实时输出漏洞
生成报告

🎯 使用场景

1️⃣ 应用安全测试

自动检测关键漏洞
并验证可利用性

2️⃣ 快速渗透测试

从“几周”缩短到“几小时” ([Strix][2])

3️⃣ Bug Bounty 自动化

自动挖漏洞
自动生成 PoC

4️⃣ CI/CD 集成（非常关键）

在 PR 阶段执行扫描
阻止不安全代码进入生产环境 ([GitHub][1])

⚙️ 快速开始

安装

curl -sSL https://strix.ai/install | bash

或：

pipx install strix-agent

配置模型

export STRIX_LLM="openai/gpt-5"
export LLM_API_KEY="your-api-key"

执行扫描

strix --target ./app-directory

👉 支持：

本地代码
GitHub 仓库
Web 应用 ([GitHub][1])

💡 使用示例

扫描 GitHub 项目

strix --target https://github.com/org/repo

黑盒测试 Web

strix --target https://your-app.com

带认证测试（灰盒）

strix --target https://your-app.com \
  --instruction "Perform authenticated testing using credentials: user:pass"

多目标扫描

strix -t repo -t deployed-app

🤖 Headless 模式（自动化）

strix -n --target https://your-app.com

特点：

无 UI
输出实时漏洞
发现漏洞 → 非 0 退出码（CI 友好）

🔄 CI/CD 集成（GitHub Actions）

name: strix-penetration-test

on:
  pull_request:

jobs:
  security-scan:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v6

      - name: Install Strix
        run: curl -sSL https://strix.ai/install | bash

      - name: Run Strix
        run: strix -n -t ./ --scan-mode quick

👉 作用：

自动阻止漏洞代码 merge

🧱 支持检测的漏洞类型

🔐 权限类

IDOR
权限提升
鉴权绕过

💥 注入类

SQL Injection
NoSQL Injection
Command Injection

🌐 服务端漏洞

SSRF
XXE
反序列化漏洞

🧠 客户端漏洞

XSS
DOM 污染
Prototype Pollution

⚙️ 业务逻辑漏洞

竞态条件
流程绕过

🔑 认证漏洞

JWT 问题
Session 管理

🏗️ 基础设施

配置错误
暴露服务 ([GitHub][1])

🧠 架构本质（重点）

Strix 的真实架构：

用户 / CI
   ↓
Strix CLI / Agent Controller
   ↓
多 AI Agents（攻击 / 分析 / 验证）
   ↓
真实执行环境（浏览器 / proxy / shell / runtime）
   ↓
目标系统（代码 / Web / API）

⚠️ 关键认知（非常重要）

Strix 并不是：

❌ 传统 SAST（静态扫描） ❌ 简单漏洞扫描器

而是：

✅ “AI 驱动的动态攻击系统（Active Offensive Security AI）”

🧠 一句话总结

Strix = AI 黑客团队（多 Agent） + 自动渗透测试 + PoC 验证 + CI/CD 安全网关

🔥 工程视角（结合你在做的系统，非常关键）

你可以把它类比为：

组件	类比
Strix Agents	黑产 / 攻击者模拟
CLI / CI	安全扫描入口
多 Agent Graph	攻击链编排系统
PoC 验证	风控中的“真实命中”

🚨 更深一层（关键洞察）

这个项目代表一个趋势：

Security = Agentic（智能体化）

未来安全系统将变成：

传统风控（规则 / 模型）
        ↓
AI 攻击模拟（Strix）
        ↓
真实漏洞验证（PoC）

参考资料

🦉 Strix
参考资料

LiteLLM 是什么 Python SDK + 代理服务器（AI Gateway）

Thu, 26 Mar 2026 13:01:55 +0000

📦 LiteLLM

🚅 LiteLLM

在 OpenAI 格式（或原生格式） 下调用 100+ LLM 模型。支持：Bedrock、Azure、OpenAI、VertexAI、Anthropic、Groq 等。 ([berriai.github.io][1])

🧠 LiteLLM 是什么

LiteLLM 是一个：

Python SDK + 代理服务器（AI Gateway）

用于：

统一调用多个大模型 API（100+）
提供统一接口（兼容 OpenAI API 规范）
支持生产级能力（成本、限流、日志、负载均衡等） ([berriai.github.io][1])

🎯 使用 LiteLLM 的目的

LiteLLM 主要用于：

1️⃣ 多模型统一调用

支持以下接口统一访问：

/chat/completions
/responses
/embeddings
/images
/audio
/batches
/rerank
/messages
等等 ([berriai.github.io][1])

🏗️ 使用方式（两种模式）

方式一：LiteLLM Proxy（AI Gateway）

👉 一个集中式 LLM 网关服务

适用场景：

多团队共享
企业级 AI 平台

核心能力：

统一 API 网关
身份认证（AuthN/AuthZ）
多租户成本统计
每项目配置（日志 / Guardrails / 缓存）
虚拟 API Key（安全访问控制）
管理后台 UI（监控与管理） ([GitHub][2])

方式二：LiteLLM Python SDK

👉 在代码中直接使用

适用场景：

应用开发
Agent / 工具链开发

核心能力：

统一 Python API
多模型 Router（重试 / fallback）
应用层负载均衡
成本统计
异常统一（兼容 OpenAI 错误格式）
可观测性（支持 MLflow / Langfuse 等） ([GitHub][2])

⚡ 性能

P95 延迟：8ms
吞吐：1000 RPS ([berriai.github.io][1])

🌐 支持的模型提供商

LiteLLM 支持大量模型提供商，包括但不限于：

OpenAI
Anthropic
Azure
AWS Bedrock
Cohere
HuggingFace
Ollama
NVIDIA NIM
Vertex AI
DeepSeek
等（100+） ([berriai.github.io][1])

👉 并支持多种能力：

能力	支持
Chat	✅
Embedding	✅
Image	✅
Audio	✅
Moderation	✅
Batch	✅

🧩 核心能力（抽象总结）

✅ 1. 统一 API 层（最核心）

from litellm import completion

response = completion(
  model="gpt-3.5-turbo",
  messages=[{"role": "user", "content": "Hello"}]
)

👉 同一接口调用不同模型（OpenAI / Claude / Llama）

✅ 2. 模型 fallback / 重试机制

fallback_models = ["gpt-3.5-turbo", "claude-2"]

主模型失败 → 自动切换备用模型
解决：
- 限流
- 服务不可用

✅ 3. 统一返回格式

所有模型输出统一为：

response['choices'][0]['message']['content']

✅ 4. 成本与监控

支持：

成本统计（per user / project）
日志
调试
可观测性平台集成

✅ 5. 缓存能力

支持：

embedding 缓存
completion 缓存

👉 用于降低成本 + 提升性能

✅ 6. 负载均衡 & Router

多 provider 路由
自动重试
请求分发

🏢 企业版（Enterprise）

提供：

SSO 单点登录
定制集成
SLA
专业支持
功能优先级支持 ([berriai.github.io][1])

🧪 开发与贡献

安装开发环境

git clone https://github.com/BerriAI/litellm.git
cd litellm
make install-dev
make format
make lint
make test-unit

代码规范

Black（格式化）
Ruff（Lint）
MyPy（类型检查）
循环依赖检测
import 安全检查 ([berriai.github.io][1])

🤔 为什么要做 LiteLLM

原因：管理不同 LLM API（Azure / OpenAI / Cohere）过于复杂

👉 LiteLLM 的目标：

简化多模型接入
降低开发复杂度
提供统一抽象层 ([berriai.github.io][1])

🧠 一句话总结

LiteLLM 本质是：

“LLM 领域的 API 网关 + SDK 统一抽象层”

你可以把它理解为：

👉 AI 版的 API Gateway（类似 Kong / Zuul）
👉 或者 LLM 版的 数据库驱动层（类似 JDBC）

⚠️（补充：工程视角关键认知）

这个项目在架构中的定位非常关键：

它解决的核心问题

多模型适配成本高
API 不统一
成本不可控
稳定性差

它的本质层级

应用层（Agent / 业务）
        ↓
LiteLLM（统一抽象层）
        ↓
各大模型厂商 API

参考资料

📦 LiteLLM
参考资料

aquasecurity / trivy 全面且通用的安全扫描器

Wed, 25 Mar 2026 13:01:55 +0000

aquasecurity / trivy

用于在容器、Kubernetes、代码仓库、云等环境中发现漏洞、错误配置、敏感信息、SBOM 等问题的工具 ([GitHub][1])

📖 文档

Trivy（发音）是一个全面且通用的安全扫描器。 Trivy 包含多种扫描器，用于查找安全问题，并支持多种目标对象进行扫描。 ([GitHub][1])

扫描目标（Trivy 可以扫描什么）

容器镜像（Container Image）
文件系统（Filesystem）
Git 仓库（远程）
虚拟机镜像（Virtual Machine Image）
Kubernetes ([GitHub][1])

扫描内容（Trivy 可以发现什么）

操作系统软件包及依赖（SBOM）
已知漏洞（CVEs）
IaC（基础设施即代码）问题和错误配置
敏感信息和密钥（Secrets）
软件许可证 ([GitHub][1])

Trivy 支持大多数主流编程语言、操作系统和平台。完整列表请参阅 Scanning Coverage 页面。 ([GitHub][1])

要了解更多内容，请访问：

Trivy 官网（功能亮点）
文档站点（详细说明） ([GitHub][1])

🚀 快速开始

安装 Trivy

Trivy 可以通过大多数常见发行渠道安装。完整安装方式请参考 Installation 页面。

常见示例：

brew install trivy

docker run aquasec/trivy

从 GitHub Releases 下载二进制文件
查看 Installation 获取更多方式 ([GitHub][1])

集成能力

Trivy 已集成到多个主流平台和应用中。

常见示例：

GitHub Actions
Kubernetes Operator
VS Code 插件
更多见 Ecosystem 页面 ([GitHub][1])

🧪 Canary 构建

每次向主分支提交代码时，都会生成 Canary 构建（Docker Hub、GitHub、ECR 镜像和二进制）。

⚠️ 注意： Canary 构建可能包含严重 bug，不建议在生产环境中使用。 ([GitHub][1])

⚙️ 通用用法

trivy <target> [--scanners <scanner1,scanner2>] <subject>

示例

扫描容器镜像：

trivy image python:3.4-alpine

扫描文件系统：

trivy fs --scanners vuln,secret,misconfig myproject/

扫描 Kubernetes：

trivy k8s --report summary cluster

([GitHub][1])

❓ FAQ

“Trivy” 如何发音？

“tri” 发音类似 “trigger”
“vy” 发音类似 “envy” ([GitHub][1])

❤️ 想了解更多？了解 Aqua

如果你喜欢 Trivy，你也会喜欢 Aqua（在 Trivy 基础上构建的完整安全管理产品）。

你可以查看：

针对 Trivy 用户的对比说明
Aqua 官网获取更多产品与服务信息
申请演示 ([GitHub][1])

🌍 社区

Trivy 是 Aqua Security 的开源项目。

可在 GitHub Discussions 中交流
了解更多开源项目组合
提交问题或反馈 ([GitHub][1])

📌 项目说明（About）

用于在以下环境中查找安全问题：

容器
Kubernetes
代码仓库
云环境

包括：漏洞、错误配置、敏感信息、SBOM 等 ([GitHub][1])

📜 许可证

Apache-2.0 License ([GitHub][1])

参考资料

aquasecurity / trivy
参考资料

Supermemory 是一个为 AI 应用提供长期记忆能力的 API 平台，支持存储、检索和基于上下文进行推理。

Wed, 25 Mar 2026 13:01:55 +0000

supermemoryai / supermemory

你的 AI 第二大脑，用于保存和组织一切重要内容。 (GitHub)

正在使用 Supermemory 构建应用？请查看开发者控制台和文档以获取 API 访问。

想要自托管？请查看自托管指南以获取企业部署选项。

功能

核心功能

从任意内容添加记忆：可以从 URL、PDF 和纯文本中轻松添加记忆——只需粘贴、上传或提供链接即可。
与记忆对话：使用自然语言与已存储的内容进行对话。
Supermemory MCP 集成：通过 Supermemory MCP 与所有主流 AI 工具（Claude、Cursor 等）无缝连接。
浏览器扩展：通过浏览器扩展直接保存记忆，支持 ChatGPT、Claude 和 Twitter/X 集成。
Raycast 扩展：通过 Raycast 使用快捷键直接添加和搜索记忆。

如何使用？

访问 app.supermemory.ai 并登录你的账户

选择一种格式开始添加记忆（笔记、链接、文件）
你也可以连接你常用的服务（Notion、Google Drive、OneDrive）
添加记忆后，点击“Open Chat”即可与 Supermemory 对话，从已保存的记忆中检索信息
将 MCP 添加到你的 AI 工具中（点击“Connect to your AI”，选择要集成的 AI 工具）
浏览器扩展：安装 Chrome/Edge 扩展，可从任意网页保存记忆，支持 ChatGPT 和 Claude 对话，以及从 Twitter/X 导入内容。右键或通过扩展弹窗即可快速保存
Raycast 扩展：安装 Raycast 扩展，可通过快捷键添加或搜索记忆。使用“Add Memory”快速保存内容，或使用“Search Memories”查找信息

支持

如果你有问题或反馈，我们很乐意提供帮助：

邮箱：support@supermemory.ai
Discord：加入我们的 Discord 服务器
文档：docs.supermemory.ai

贡献

我们欢迎各个水平的开发者参与贡献！无论是修复 bug、添加功能，还是改进文档，你的帮助都会让 supermemory 更好。

有关详细指南、开发环境设置、编码规范和完整的贡献流程，请查看贡献指南。

贡献方式

🐛 Bug 修复 —— 帮助我们解决问题
✨ 新功能 —— 添加用户喜爱的功能
🎨 UI/UX 改进 —— 提升界面体验
⚡ 性能优化 —— 让 supermemory 更快

请查看 Issues 页面中的 good first issue 和 help wanted 标签开始参与。

更新与路线图

关注最新改进：

Changelog（更新日志）
X（社交媒体）

项目说明（补充理解）

Supermemory 是一个为 AI 应用提供长期记忆能力的 API 平台，支持存储、检索和基于上下文进行推理。 (DeepWiki)

如果你需要，我可以帮你进一步做一版架构级解读（RAG / MCP / Memory Layer 怎么实现），或者直接对比它和 mem0、Zep 这些方案的差异。

参考资料

supermemoryai / supermemory
参考资料

RuView 将普通 WiFi 信号转化为实时人体感知与空间感知能力

Wed, 25 Mar 2026 13:01:55 +0000

RuView

π RuView：将普通 WiFi 信号转化为实时人体感知与空间感知能力。 ([源Forge][1])

概述

RuView 是一个边缘 AI 感知系统，它利用普通 WiFi 信号，实现：

实时人体姿态估计
生命体征监测
存在检测

无需摄像头、可穿戴设备或云连接。 ([源Forge][1])

核心原理（WiFi DensePose）

该系统基于 WiFi DensePose 概念，通过分析 WiFi 信道状态信息（CSI）的扰动来实现感知能力。

这些扰动由人体运动引起，系统通过物理建模与机器学习算法对其进行解析，从而重建：

人体姿态（body position）
呼吸频率（breathing rate）
心率（heartbeat） ([GitGenius][2])

关键特性

无摄像头（Camera-free） 不依赖任何视觉设备
无可穿戴设备（Wearable-free） 无需在人体上安装传感器
隐私优先（Privacy-first） 不采集图像或视频数据
无需互联网（Offline-capable） 可在本地独立运行 ([GitGenius][2])

能力

系统可实现以下功能：

实时人体姿态重建
呼吸与心率监测
人体存在检测
空间感知与行为分析 ([源Forge][1])

技术实现

RuView 的核心实现包括：

基于物理的信号处理（Physics-based signal processing）
WiFi CSI 数据分析
机器学习模型推理
边缘计算执行

系统通过分析 WiFi 信号在空间传播过程中因人体产生的变化，实现对环境与人体状态的建模。 ([GitGenius][2])

硬件支持（示例）

ESP32-S3 固件

提供用于 CSI 感知的固件组件，包括：

Bootloader
分区表
CSI 节点二进制（UDP 数据流）
网络配置脚本 ([新发布][3])

桌面应用

提供桌面端应用（RuView Desktop），用于：

展示 WiFi 感知结果
进行人体姿态估计

支持平台：

macOS（Intel / Apple Silicon）
Windows（x64） ([新发布][4])

架构能力（边缘计算）

系统支持在设备端（如 ESP32）执行信号处理，包括：

实时信号分析
存在检测
生命体征计算（呼吸 / 心率）
跌倒检测

通过双核处理与 DSP 管线实现低延迟处理。 ([新发布][5])

项目定位（原文含义）

RuView 是一个：

基于 WiFi 的人体感知系统
无视觉的环境理解方案
边缘 AI + 物理信号处理结合体

用于在不侵犯隐私的前提下，实现实时人体与空间感知能力。 ([源Forge][1])

参考资料

RuView
参考资料

ruflo 由 ruvnet 构建的企业级多智能体 AI 编排框架。用于部署智能多智能体集群、协调自主工作流，并构建对话式 AI 系统。

Wed, 25 Mar 2026 13:01:55 +0000

ruflo

由 ruvnet 构建的企业级多智能体 AI 编排框架。用于部署智能多智能体集群、协调自主工作流，并构建对话式 AI 系统。 ([AIToolly][1])

概述

ruflo 是一个多智能体编排平台，扩展了 Claude Code，并引入群体智能（swarm intelligence）能力。 ([Evermx][2])

它支持在多个领域（编码、测试、安全、DevOps）中部署专业化智能体，并通过分层协调机制进行统一调度。 ([Evermx][2])

核心能力

多智能体编排 支持部署智能多智能体集群，并协调其自主执行复杂任务流程 ([AIToolly][1])
群体智能（Swarm Intelligence） 通过“女王（queen）主导”的分层群体架构，实现智能体之间的协同与调度 ([Evermx][2])
企业级架构 提供高可扩展性与高可靠性的系统设计，适用于复杂 AI 应用场景 ([AIToolly][1])
RAG 集成 内置检索增强生成能力，用于提升信息检索与生成效果 ([AIToolly][1])
Claude Code / Codex 原生集成 深度集成 Claude 生态的编码与推理能力 ([AIToolly][1])

关键特性

60+ 专业智能体 覆盖编码、测试、安全审计、DevOps 等多个领域 ([Evermx][2])
SONA 自优化机制 自适应优化能力，支持亚毫秒级调整与路径学习 ([Evermx][2])
HNSW 向量搜索 支持亚毫秒级检索性能 ([Evermx][2])
RuVector + PostgreSQL 集成 提供高性能向量检索（约 61 微秒） ([Evermx][2])
多种一致性算法
- Raft
- 拜占庭容错（BFT）
- Gossip 用于分布式智能体协调 ([Evermx][2])
Agent Booster（WASM） 支持无需 LLM 调用的超低延迟任务执行（<1ms） ([Evermx][2])
Flash Attention 加速 提供 2.49–7.47 倍性能提升 ([Evermx][2])
多模型支持 支持 Claude、GPT、Gemini、Ollama 等多种 LLM，并支持自动故障切换与成本优化（降低 30–50% token 成本） ([Evermx][2])

项目定位（原文含义）

ruflo 是一个面向开发者与企业的 AI 基础设施平台，用于：

构建多智能体系统
编排复杂 AI 工作流
实现分布式智能体协作
支撑对话式与自动化 AI 应用

([AIToolly][1])

参考资料

ruflo
参考资料

一个基于 React Three Fiber 和 WebGPU 构建的 3D 建筑编辑器

Wed, 25 Mar 2026 13:01:55 +0000

Pascal Editor

一个基于 React Three Fiber 和 WebGPU 构建的 3D 建筑编辑器。 ([GitHub][1])

仓库架构

这是一个使用 Turborepo 管理的 monorepo，包含三个主要包：

editor-v2/
├── apps/
│   └── editor/          # Next.js 应用
├── packages/
│   ├── core/            # Schema 定义、状态管理、系统
│   └── viewer/          # 3D 渲染组件

职责分离

包	职责
@pascal-app/core	节点 schema、场景状态（Zustand）、系统（几何生成）、空间查询、事件总线
@pascal-app/viewer	基于 React Three Fiber 的 3D 渲染、默认相机/控制、后处理
apps/editor	UI 组件、工具、自定义行为、编辑器特有系统

viewer 负责使用合理默认值渲染场景，editor 在其基础上扩展交互工具、选择管理和编辑能力。 ([GitHub][1])

状态存储（Stores）

每个包都有自己的 Zustand store 用于状态管理：

Store	包	职责
useScene	@pascal-app/core	场景数据：节点、根节点 ID、脏节点、CRUD 操作；持久化到 IndexedDB，并通过 Zundo 实现撤销/重做
useViewer	@pascal-app/viewer	Viewer 状态：当前选择（建筑/楼层/区域）、显示模式（堆叠/爆炸/单独）、相机模式
useEditor	apps/editor	编辑器状态：当前工具、结构层可见性、面板状态、编辑器偏好

访问方式：

// React 中订阅
const nodes = useScene((state) => state.nodes)
const levelId = useViewer((state) => state.selection.levelId)
const activeTool = useEditor((state) => state.tool)

// React 外访问
const node = useScene.getState().nodes[id]
useViewer.getState().setSelection({ levelId: 'level_123' })

核心概念

节点（Nodes）

节点是描述 3D 场景的数据基本单位，所有节点继承 BaseNode：

BaseNode {
  id: string              // 自动生成（带类型前缀，如 "wall_abc123"）
  type: string            // 类型标识
  parentId: string | null // 父节点
  visible: boolean
  camera?: Camera         // 可选相机信息
  metadata?: JSON         // 任意元数据
}

节点层级结构：

Site
└── Building
    └── Level
        ├── Wall → Item（门/窗）
        ├── Slab
        ├── Ceiling → Item（灯）
        ├── Roof
        ├── Zone
        ├── Scan（3D参考）
        └── Guide（2D参考）

节点以扁平结构存储（Record<id, Node>），通过 parentId 和 children 表示关系。 ([GitHub][1])

场景状态（Scene State）

由 @pascal-app/core 中的 Zustand 管理：

useScene.getState() = {
  nodes: Record<id, AnyNode>,
  rootNodeIds: string[],
  dirtyNodes: Set<string>,

  createNode(node, parentId),
  updateNode(id, updates),
  deleteNode(id),
}

中间件：

Persist：持久化到 IndexedDB（排除临时节点）
Temporal（Zundo）：支持 50 步撤销/重做 ([GitHub][1])

场景注册表（Scene Registry）

用于将节点 ID 映射到 Three.js 对象：

sceneRegistry = {
  nodes: Map<id, Object3D>,
  byType: {
    wall: Set<id>,
    item: Set<id>,
    zone: Set<id>,
  }
}

组件通过 useRegistry 注册：

const ref = useRef<Mesh>(null!)
useRegistry(node.id, 'wall', ref)

作用：避免遍历场景树，直接访问 3D 对象。 ([GitHub][1])

节点渲染器（Node Renderers）

每种节点对应一个 React 渲染组件：

SceneRenderer
└── NodeRenderer
    ├── BuildingRenderer
    ├── LevelRenderer
    ├── WallRenderer
    ├── SlabRenderer
    ├── ZoneRenderer
    ├── ItemRenderer

模式：

创建 mesh/group
注册到 registry
由系统更新几何

示例：

const WallRenderer = ({ node }) => {
  const ref = useRef<Mesh>(null!)
  useRegistry(node.id, 'wall', ref)

  return (
    <mesh ref={ref}>
      <boxGeometry args={[0, 0, 0]} />
      <meshStandardMaterial />
      {node.children.map(id => <NodeRenderer key={id} nodeId={id} />)}
    </mesh>
  )
}

技术栈

React 19 + Next.js 16
Three.js（WebGPU 渲染）
React Three Fiber + Drei
Zustand（状态管理）
Zod（schema 校验）
Zundo（撤销/重做）
three-bvh-csg（布尔几何运算）
Turborepo（monorepo 管理）
Bun（包管理器） ([GitHub][1])

快速开始

开发模式

在项目根目录运行：

# 安装依赖
bun install

# 启动开发环境
bun dev

该命令会：

构建 @pascal-app/core 和 @pascal-app/viewer
监听包变化
启动 Next.js 编辑器开发服务

访问：

http://localhost:3000

总结（给你一个技术视角的补充）

这个 README 本质上表达的是一个非常清晰的架构设计思想：

Core（数据+系统）
Viewer（纯渲染）
Editor（交互+工具）

本质是典型的：

ECS（Entity + System） + React 渲染分层架构

如果你是做平台/引擎（你之前提到自动化测试平台），这个设计其实非常值得借鉴：

“系统（system）驱动状态变化”
“渲染与业务彻底解耦”
“扁平数据结构 + registry 加速访问”

参考资料

Pascal Editor
参考资料

last30days-skill 从最近 30 天研究任意主题

Wed, 25 Mar 2026 13:01:55 +0000

last30days-skill

从最近 30 天中研究任意主题。也可通过 “last30” 触发。数据来源包括 Reddit、X、YouTube 和 Web。成为该领域专家，并生成可直接复制粘贴的提示词。 (GitClassic)

last30days v2.1：从最近 30 天研究任意主题

在 Reddit、X、YouTube 和 Web 上研究任何主题。提取人们当前真正讨论、推荐和争论的内容。 (GitClassic)

⚠️ 关键：解析用户意图

在执行任何操作之前，需要从用户输入中解析：

TOPIC（主题）：用户想了解的内容（例如：“web app mockups”、“Claude Code skills”、“image generation”）
TARGET TOOL（目标工具）（如果指定）：用户将使用提示词的工具（例如：“ChatGPT”、“Midjourney”）
QUERY TYPE（查询类型）：用户希望进行的研究类型：
- PROMPTING（提示词）：如 “X prompts”、“prompting for X” → 学习技巧 + 获取可复制提示词
- RECOMMENDATIONS（推荐）：如 “best X”、“top X” → 获取具体列表
- NEWS（新闻）：如 “what’s happening with X” → 获取最新动态
- GENERAL（通用）：其他情况 → 获取整体理解

常见模式：

[topic] for [tool] → 指定了工具
[topic] prompts for [tool] → 指定了工具
仅 [topic] → 未指定工具
“best/top” → 推荐类查询

重要：在研究前不要询问目标工具。 (GitClassic)

需要存储的变量

TOPIC
TARGET_TOOL（未指定则为 “unknown”）
QUERY_TYPE

在调用工具前，必须向用户展示解析结果：

我将从 Reddit、X 和 Web 中研究 {TOPIC}，查找最近 30 天的讨论。

解析结果：
- TOPIC = {TOPIC}
- TARGET_TOOL = {TARGET_TOOL 或 "unknown"}
- QUERY_TYPE = {QUERY_TYPE}

研究通常需要 2-8 分钟（小众主题更久）。现在开始。

研究执行流程

Step 1：运行研究脚本（前台执行）

必须以前台方式运行（不可后台执行），超时时间为 5 分钟。 (GitClassic)

脚本会自动：

检测 API key
搜索 Reddit / X / YouTube
输出所有结果（包括 YouTube 转录）

输出包含三部分：

Reddit
X
YouTube

Step 2：补充 WebSearch

在脚本完成后执行 WebSearch，用于补充博客、教程、新闻等内容。 (GitClassic)

根据 QUERY_TYPE 选择查询方式：

推荐类：搜索“best {TOPIC}”等
新闻类：搜索“{TOPIC} news 2026”
提示词类：搜索“{TOPIC} prompts examples”
通用类：搜索“{TOPIC} 2026”

要求：

使用用户原始术语
排除 reddit / x（已覆盖）
包含博客、文档、GitHub

Judge Agent：综合分析

完成所有搜索后，进行内部综合分析：

Reddit / X 权重更高（有互动数据）
YouTube 权重高（有观看量、点赞、转录）
Web 权重较低
找出跨来源的共同模式
识别矛盾点
提取 3–5 个关键洞察 (GitClassic)

⚠️ 关键：基于“真实研究内容”

必须基于研究输出，而不是已有知识：

使用真实提到的产品名称
使用来源中的观点
避免“主观推测”

如果是推荐类查询（RECOMMENDATIONS）

必须提取具体名称：

示例（正确）：

/commit（5 次提及）
remotion skill（4 次）

而不是泛泛总结。 (GitClassic)

输出结构

第一部分：What I learned

基于研究输出总结：

What I learned:

Topic 1 — 内容（来自 Reddit/X）
Topic 2 — 内容
Topic 3 — 内容

KEY PATTERNS:
1. ...
2. ...
3. ...

第二部分：统计信息（必须精确计算）

---
✅ All agents reported back!
├─ 🟠 Reddit: {N} threads │ {N} upvotes │ {N} comments
├─ 🔵 X: {N} posts │ {N} likes │ {N} reposts
├─ 🔴 YouTube: {N} videos │ {N} views │ {N} with transcripts
├─ 🌐 Web: {N} pages (supplementary)
└─ 🗣️ Top voices: @{handle1}, r/{sub}
---

第三部分：引导用户

根据 QUERY_TYPE 给出下一步建议，例如：

提问
深入分析
生成 prompt

必须提供 2–3 个具体示例。 (GitClassic)

用户回复后的处理

根据用户意图执行：

提问 → 直接回答
深入 → 扩展分析
创建内容 → 生成 Prompt

Prompt 生成规则

必须：

符合研究中推荐的格式（如 JSON / 结构化）
可直接复制使用
使用研究中提到的关键词

输出格式：

Here's your prompt for {TARGET_TOOL}:

---

[Prompt 内容]

---

This uses ...

Prompt 之后的总结

---
📚 Expert in: {TOPIC} for {TARGET_TOOL}
📊 Based on: {统计数据}

Want another prompt? Just tell me what you're creating next.

安全与权限

该技能会：

使用 OpenAI API 搜索 Reddit
使用 X API 或 Cookie 搜索 X
使用 yt-dlp 获取 YouTube 数据
使用搜索 API 获取 Web 内容
存储数据到本地 SQLite (SkillsLLM)

不会：

不会发帖或点赞
不会访问用户账号
不会共享 API key
不会记录密钥
不会发送未授权数据 (SkillsLLM)

项目总结（原文含义）

这是一个用于：

实时趋势研究（30 天）
社区驱动洞察（Reddit/X）
自动生成 Prompt

的 AI Skill 工具。 (SourcePulse)

如果你下一步想深入，我可以帮你做一版更“架构级拆解”： 👉 它本质上是一个「RAG + 多源信号加权 + Prompt 编译器」系统，甚至可以直接改造成你在做的 AI 根因分析平台的一部分。

参考资料

last30days-skill
参考资料

Hermes Agent 一个会随着你成长的智能体

Wed, 25 Mar 2026 13:01:55 +0000

Hermes Agent

一个会随着你成长的智能体。 ([NOUS RESEARCH][1])

将它安装在一台机器上，连接你的消息账户，它就会成为一个持续存在的个人智能体——学习你的项目、构建自己的技能，并能在你所在的任何地方与你交互。 ([NOUS RESEARCH][1])

不是绑定在 IDE 中的代码助手，也不是围绕单一 API 的聊天机器人封装。

而是一个运行在你服务器上的自主智能体，能够记住所学内容，并随着时间变得更强大。 ([NOUS RESEARCH][1])

功能

💬 存在于你所在的地方（Lives Where You Do）

支持 Telegram、Discord、Slack、WhatsApp 和 CLI，通过一个统一的网关进程接入。支持语音消息转录、跨平台对话延续（例如在 Telegram 开始，在终端继续）。 ([NOUS RESEARCH][1])

🧠 随运行时间不断成长（Grows the Longer It Runs）

具备跨会话的持久化记忆——学习你的偏好、项目和环境。当解决复杂问题时，会写入技能文档，从而不会遗忘。技能可搜索、可共享。 ([NOUS RESEARCH][1])

⏰ 定时自动化（Scheduled Automations）

内置 cron 调度器，可向任意平台发送结果。支持自然语言定义任务，例如每日报告、夜间备份、每周审计、晨间简报等，并通过网关自动运行。 ([NOUS RESEARCH][1])

🔀 委派与并行（Delegates & Parallelizes）

可创建隔离的子智能体用于并行工作流。每个子智能体拥有独立的对话和终端。支持通过 Python 脚本调用工具（RPC），将多步骤流程压缩为低上下文成本执行。 ([NOUS RESEARCH][1])

🔒 真实沙箱（Real Sandboxing）

支持 5 种终端后端：

本地（local）
Docker
SSH
Singularity
Modal

提供容器安全加固（只读 root、能力裁剪、PID 限制、命名空间隔离）。 ([NOUS RESEARCH][1])

🌐 完整 Web 与浏览器控制（Full Web & Browser Control）

支持：

Web 搜索
页面提取
浏览器自动化（点击、输入、截图等）

以及：

视觉分析
图像生成
文本转语音
多模型协同推理 ([NOUS RESEARCH][1])

内置工具（40+）

包括但不限于：

Web 搜索
终端
文件系统
浏览器
视觉
图像生成
文本转语音
记忆系统
任务规划
定时任务
代码执行
子智能体
技能系统
多模型推理
消息系统
会话检索 ([NOUS RESEARCH][1])

兼容性（Works with everything）

聊天平台

Telegram
Discord
Slack
WhatsApp
CLI ([NOUS RESEARCH][1])

LLM 提供商

Nous Portal
OpenRouter
自定义 API ([NOUS RESEARCH][1])

执行环境

本地
Docker
SSH
Singularity
Modal ([NOUS RESEARCH][1])

技能系统（40+ 内置技能，持续增长）

技能是一种“过程性记忆”，即针对重复任务的可复用方法。

当智能体解决复杂问题时，会自动创建技能；在遇到类似任务时自动加载。

支持从社区 Hub 一键安装技能。 ([NOUS RESEARCH][1])

内置技能

包含 40+ 技能，覆盖：

MLOps
GitHub 工作流
图表生成
笔记记录等

并支持运行过程中动态生成新技能。 ([NOUS RESEARCH][1])

技能生态集成

支持：

agentskills.io
GitHub 仓库
ClawHub
LobeHub
Claude Code Marketplace

支持浏览、安装和管理技能，并提供隔离与审计机制保障安全。 ([NOUS RESEARCH][1])

开放标准

技能遵循 agentskills.io 的开放格式（SKILL.md 文件）。可在不同智能体之间共享与复用。 ([NOUS RESEARCH][1])

快速开始（60 秒）

1. 安装

curl -fsSL https://raw.githubusercontent.com/NousResearch/hermes-agent/main/scripts/install.sh | bash

自动安装 Python 3.11、依赖并完成环境配置，无需 sudo。 ([NOUS RESEARCH][1])

2. 配置

hermes setup
hermes model

连接 Nous Portal（OAuth）、OpenRouter（API key）或自定义端点。 ([NOUS RESEARCH][1])

3. 开始对话

hermes

进入完整 CLI 交互界面，具备工具、记忆和技能能力。 ([NOUS RESEARCH][1])

4. 多平台接入（可选）

hermes gateway
hermes gateway install

连接 Telegram / Discord / Slack / WhatsApp，并作为系统服务运行。 ([NOUS RESEARCH][1])

面向研究（Research-ready）

批处理（Batch Processing）

并行生成大量工具调用轨迹，支持自动 checkpoint。可配置 worker、批大小和工具分布。 ([NOUS RESEARCH][1])

强化学习训练（RL Training）

集成 Atropos，用于训练智能体行为。支持 11 种工具调用解析器，适配不同模型架构。 ([NOUS RESEARCH][1])

轨迹导出（Trajectory Export）

支持导出 ShareGPT 格式对话，用于微调训练。支持轨迹压缩以适配 token 限制。 ([NOUS RESEARCH][1])

配置目录结构（补充）

默认路径：~/.hermes/

包含：

config.yaml（配置）
.env（密钥）
auth.json（认证信息）
SOUL.md（全局人格）
memories/（记忆）
skills/（技能）
cron/（定时任务）
sessions/（会话）
logs/（日志） ([hermes-agent.nousresearch.com][2])

项目定位（原文含义）

Hermes Agent 是一个：

长期运行的自主 AI Agent
具备记忆 + 技能进化能力
支持多平台、多工具、多模型
面向自动化与多智能体协作

的 AI Agent 基础设施。 ([NOUS RESEARCH][1])

参考资料

Hermes Agent
参考资料

tinygrad 是一个端到端的深度学习框架

Tue, 24 Mar 2026 13:01:55 +0000

tinygrad

介于 PyTorch 和 karpathy/micrograd 之间的项目。由 tiny corp 维护。

[主页](https://github.com/tinygrad/tinygrad) | [文档](https://docs.tinygrad.org/) | [Discord](https://discord.gg/ZjZadyC7PK) tinygrad 是一个端到端的深度学习框架： - 张量库，支持自动梯度 - 中间表示（IR）和编译器，用于融合和降低内核 - 即时编译（JIT）+ 图执行 - 神经网络 / 优化器 / 数据集，用于实际训练它的灵感来自 PyTorch（人机工程学）、JAX（函数式转换和基于 IR 的自动微分）和 TVM（调度和代码生成），但始终保持小巧且易于修改。 --- ## tinygrad 对比 PyTorch - ✅ 相似之处：即时执行的 `Tensor` API、自动梯度、`optim`、基本数据集和层。 - ✅ 可以编写熟悉的训练循环。 - 🔁 与 PyTorch 不同的是，整个编译器和 IR 都是可见且可修改的。 JAX - ✅ 基于 IR 的原始操作自动微分（类似于 JAXPR + XLA）。 - ✅ 函数级 JIT（`TinyJit`），用于捕获和重放内核。 - 🔁 函数式转换较少（尚未完全支持 `vmap`/`pmap`），但易于阅读。 TVM - ✅ 多次降低传递、调度和内核上的束搜索。 - ✅ 用于批量执行的设备“图”。 - 🔁 tinygrad 还提供了前端框架（张量、神经网络、优化器），而不仅仅是编译器。 --- ### 懒惰计算尝试一个矩阵乘法。可以看到，尽管采用了这种风格，但借助懒惰计算的力量，它被融合到一个内核中。 ```sh DEBUG=3 python3 -c "from tinygrad import Tensor; N = 1024; a, b = Tensor.empty(N, N), Tensor.empty(N, N); (a.reshape(N, 1, N) * b.T.reshape(1, N, N)).sum(axis=2).realize()" ``` 我们可以将 `DEBUG` 改为 `4` 来查看生成的代码。 ### 神经网络事实证明，神经网络所需的 90% 就是一个不错的自动梯度/张量库。再加上一个优化器、一个数据加载器和一些计算，你就拥有了所需的一切。 ```python from tinygrad import Tensor, nn class LinearNet: def init(self): self.l1 = Tensor.kaiming_uniform(784, 128) self.l2 = Tensor.kaiming_uniform(128, 10) def call(self, x:Tensor) -> Tensor: return x.flatten(1).dot(self.l1).relu().dot(self.l2) model = LinearNet() optim = nn.optim.Adam([model.l1, model.l2], lr=0.001) x, y = Tensor.rand(4, 1, 28, 28), Tensor([2,4,3,7]) # 替换为真实的 mnist 数据加载器 with Tensor.train(): for i in range(10): optim.zero_grad() loss = model(x).sparse_categorical_crossentropy(y).backward() optim.step() print(i, loss.item()) ``` 完整版本请参见 [examples/beautiful_mnist.py](examples/beautiful_mnist.py)，大约 5 秒即可达到 98% 的准确率。 ## 加速器 tinygrad 已经支持多种加速器，包括： - [x] [OpenCL](tinygrad/runtime/ops_cl.py) - [x] [CPU](tinygrad/runtime/ops_cpu.py) - [x] [METAL](tinygrad/runtime/ops_metal.py) - [x] [CUDA](tinygrad/runtime/ops_cuda.py) - [x] [AMD](tinygrad/runtime/ops_amd.py) - [x] [NV](tinygrad/runtime/ops_nv.py) - [x] [QCOM](tinygrad/runtime/ops_qcom.py) - [x] [WEBGPU](tinygrad/runtime/ops_webgpu.py) 而且添加更多加速器也很容易！您选择的加速器只需要支持总共约 25 个低级操作。要检查默认加速器，请运行：`python3 -c "from tinygrad import Device; print(Device.DEFAULT)"` ## 安装目前推荐的 tinygrad 安装方式是从源码安装。 ### 从源码安装 ```sh git clone https://github.com/tinygrad/tinygrad.git cd tinygrad python3 -m pip install -e . ``` ### 直接安装（主分支） ```sh python3 -m pip install git+https://github.com/tinygrad/tinygrad.git ``` ## 文档文档以及快速入门指南可以在[文档网站](https://docs.tinygrad.org/)上找到，该网站是根据 [docs/](/docs) 目录构建的。 ### 与 PyTorch 对比的快速示例 ```python from tinygrad import Tensor x = Tensor.eye(3, requires_grad=True) y = Tensor([[2.0,0,-2.0]], requires_grad=True) z = y.matmul(x).sum() z.backward() print(x.grad.tolist()) # dz/dx print(y.grad.tolist()) # dz/dy ``` 在 PyTorch 中实现相同的功能： ```python import torch x = torch.eye(3, requires_grad=True) y = torch.tensor([[2.0,0,-2.0]], requires_grad=True) z = y.matmul(x).sum() z.backward() print(x.grad.tolist()) # dz/dx print(y.grad.tolist()) # dz/dy ``` ## 贡献最近人们对 tinygrad 产生了浓厚的兴趣。遵循以下准则将有助于您的 PR 被接受。我们首先说明哪些情况会导致您的 PR 被关闭，并会附上本节的链接： - 不要写代码高尔夫！虽然低代码行数是本项目的指导原则，但任何看起来像代码高尔夫的内容都将被关闭。真正的目标是降低复杂性和提高可读性，删除 `\n` 对此毫无帮助。 - 所有文档和空白字符的更改都将被关闭，除非您是知名贡献者。编写文档的人应该是对代码库最了解的人。没有证明这一点的人不应该乱动文档。空白字符的更改既无用，又存在引入错误的风险。 - 任何声称是“加速”的内容都必须经过基准测试。总的来说，目标是简单性，因此即使您的 PR 使性能略有提升，您也必须考虑在可维护性和可读性方面的权衡。 - 一般来说，核心 `tinygrad/` 文件夹之外的代码没有经过充分测试，因此除非那里的现有代码已损坏，否则您不应该更改它。 - 如果您的 PR 看起来“复杂”、差异很大或添加了很多行，则不会被审查或合并。请考虑将其分解为更小的 PR，每个 PR 都有明确的优点。我常见的一种模式是在添加新功能之前进行先决条件的重构。如果您可以（干净地）重构到该功能只需更改 3 行代码的程度，那就太好了，这样我们很容易审查。现在，我们想要的是： - 错误修复（带有回归测试）很棒！这个库还不是 1.0 版本，所以如果您偶然发现了一个错误，修复它，编写一个测试，并提交 PR，这是非常有价值的工作。 - 解决悬赏问题！tinygrad [为库的某些改进提供现金悬赏](https://docs.google.com/spreadsheets/d/1WKHbT-7KOgjEawq5h5Ic1qUWzpfAzuD_J06N1JwOCGs/edit?usp=sharing)。所有新代码都应该是高质量的并且经过充分测试。 - 功能。但是，如果您要添加一个功能，请考虑代码行数的权衡。如果是 3 行代码，那么它的有用性门槛就比 30 行或 300 行的功能要低。所有功能都必须有回归测试。通常在没有其他限制的情况下，您的功能的 API 应与 torch 或 numpy 匹配。 - 明确有益的重构。一般来说，如果您的重构不是明确有益的，它将被关闭。但有些重构非常棒！从深度核心的角度考虑可读性。更改空白字符或移动几个函数是无用的，但如果您发现两个 100 行的函数实际上可以使用同一个带参数的 110 行函数，同时还能提高可读性，这将是一个巨大的胜利。重构应通过[过程重放](#过程重放测试)测试。 - 测试/模糊测试。如果您能添加非脆弱的测试，我们非常欢迎。我们这里也有一些模糊测试工具，通过它们和改进它们可以发现大量错误。发现错误，甚至使用 `@unittest.expectedFailure` 编写（本应通过但实际失败的）测试，都是很棒的。这是我们取得进步的方式。 - 移除核心 `tinygrad/` 文件夹中的死代码。我们不关心 extra 中的代码，但移除核心库中的死代码是非常好的。这样可以减少新开发者阅读时产生的困惑。 ### 运行测试您应该使用 `pre-commit install` 安装预提交钩子。这将在每次提交时运行 linter、mypy 和一部分测试。有关如何运行完整测试套件的更多示例，请参考 [CI workflow](.github/workflows/test.yml)。在本地运行测试的一些示例： ```sh python3 -m pip install -e '.[testing]' # 安装测试所需的额外依赖 python3 test/backend/test_ops.py # 仅运行操作测试 python3 -m pytest test/ # 运行整个测试套件 ``` #### 过程重放测试 [过程重放](https://github.com/tinygrad/tinygrad/blob/master/test/external/process_replay/README.md) 将您的 PR 生成的内核与主分支进行比较。如果您的 PR 是重构或加速，且没有预期的行为变化，则应在拉取请求标题中包含 [pr]。 # 参考资料 * any list {:toc}

Minimind 01 Intro

Tue, 24 Mar 2026 13:01:55 +0000

minimind

此开源项目旨在完全从0开始，仅用3块钱成本 + 2小时！即可训练出仅为25.8M的超小语言模型MiniMind。
MiniMind系列极其轻量，最小版本体积是 GPT-3 的 $\frac{1}{7000}$，力求做到最普通的个人GPU也可快速训练。
项目同时开源了大模型的极简结构-包含拓展共享混合专家(MoE)、数据集清洗、预训练(Pretrain)、监督微调(SFT)、LoRA微调、直接偏好优化(DPO)、强化学习训练(RLAIF: PPO/GRPO等)、模型蒸馏等全过程代码。
MiniMind同时拓展了视觉多模态的VLM: MiniMind-V。
项目所有核心算法代码均从0使用PyTorch原生重构！不依赖第三方库提供的抽象接口。
这不仅是大语言模型的全阶段开源复现，也是一个入门LLM的教程。
希望此项目能为所有人提供一个抛砖引玉的示例，一起感受创造的乐趣！推动更广泛AI社区的进步！

为防止误解，“2小时” 基于NVIDIA 3090硬件设备（单卡）测试，“3块钱”指GPU服务器租用成本，具体规格详情见下文。

![minimind2](./images/minimind2.gif) [🔗🍓推理模型](https://www.modelscope.cn/studios/gongjy/MiniMind-Reasoning) | [🔗🤖常规模型](https://www.modelscope.cn/studios/gongjy/MiniMind) | [🔗🎞️视频介绍](https://www.bilibili.com/video/BV12dHPeqE72/?share_source=copy_web&vd_source=670c2504f88726f8cf4a21ef6147c0e8) # 📌 Introduction 大语言模型（Large Language Model, LLM）的出现引发了全世界对AI的空前关注。无论是ChatGPT、DeepSeek还是Qwen，都以其惊艳的效果令人叹为观止。然而，动辄数百亿参数的庞大规模，使得它们对个人设备而言不仅难以训练，甚至连部署都显得遥不可及。打开大模型的“黑盒子”，探索其内部运作机制，多么令人心潮澎湃！遗憾的是，99%的探索只能止步于使用LoRA等技术对现有大模型进行少量微调，学习一些新指令或任务。这就好比教牛顿如何使用21世纪的智能手机——虽然有趣，却完全偏离了理解物理本质的初衷。与此同时，第三方的大模型框架和工具库，如transformers+trl，几乎只暴露了高度抽象的接口。通过短短10行代码，就能完成“加载模型+加载数据集+推理+强化学习”的全流程训练。这种高效的封装固然便利，但也像一架高速飞船，将开发者与底层实现隔离开来，阻碍了深入探究LLM核心代码的机会。然而，“用乐高拼出一架飞机，远比坐在头等舱里飞行更让人兴奋！”。更糟糕的是，互联网上充斥着大量付费课程和营销号，以漏洞百出、一知半解的内容推销AI教程。正因如此，本项目初衷是拉低LLM的学习门槛，让每个人都能从理解每一行代码开始，从零开始亲手训练一个极小的语言模型。是的，从**零开始训练**，而不是仅仅进行**推理**！最低只需3块钱不到的服务器成本，就能亲身体验从0到1构建一个语言模型的全过程。一起感受创造的乐趣吧！ > [!NOTE] > （截至2025-10）MiniMind系列已完成多个型号模型的预训练，最小仅需25.8M（0.02B），即可具备流畅对话能力！

Models List

| 模型 (大小) | 推理占用 (约) | Release | |-------------------------|----------|------------| | MiniMind2-small (26M) | 0.5 GB | 2025.04.26 | | MiniMind2-MoE (145M) | 1.0 GB | 2025.04.26 | | MiniMind2 (104M) | 1.0 GB | 2025.04.26 | | minimind-v1-small (26M) | 0.5 GB | 2024.08.28 | | minimind-v1-moe (4×26M) | 1.0 GB | 2024.09.17 | | minimind-v1 (108M) | 1.0 GB | 2024.09.01 |

**项目包含** - MiniMind-LLM结构的全部代码（Dense+MoE模型）。 - 包含Tokenizer分词器详细训练代码。 - 包含Pretrain、SFT、LoRA、RLHF-DPO、RLAIF(PPO/GRPO/SPO)、模型蒸馏的全过程训练代码。 - 收集、蒸馏、整理并清洗去重所有阶段的高质量数据集，且全部开源。 - 从0实现预训练、指令微调、LoRA、DPO/PPO/GRPO/SPO强化学习，白盒模型蒸馏。关键算法几乎不依赖第三方封装的框架，且全部开源。 - 同时兼容`transformers`、`trl`、`peft`等第三方主流框架。 - 训练支持单机单卡、单机多卡(DDP、DeepSpeed)训练，支持wandb/swanlab可视化训练流程。支持动态启停训练。 - 在第三方测评榜（C-Eval、C-MMLU、OpenBookQA等）进行模型测试，支持YaRN算法执行RoPE长文本外推。 - 实现Openai-Api协议的极简服务端，便于集成到第三方ChatUI使用（FastGPT、Open-WebUI等）。 - 基于streamlit实现最简聊天WebUI前端。 - 全面兼容社区热门`llama.cpp`、`vllm`、`ollama`推理引擎或`Llama-Factory`训练框架。 - 复现(蒸馏/RL)大型推理模型DeepSeek-R1的MiniMind-Reason模型，**数据+模型**全部开源！希望此开源项目可以帮助LLM初学者快速入门！ ### 👉**更新日志**

2025-10-24

- 🔥 新增RLAIF训练算法：PPO、GRPO、SPO（从0原生实现） - 新增断点续训功能：支持训练自动恢复、跨GPU数量恢复、wandb记录连续性 - 新增RLAIF数据集：rlaif-mini.jsonl（从SFT数据随机采样1万条）；简化DPO数据集，加入中文数据 - 新增YaRN算法：支持RoPE长文本外推，提升长序列处理能力 - Adaptive Thinking：Reason模型可选是否启用思考链 - chat_template全面支持Tool Calling和Reasoning标签（``、``等） - 新增RLAIF完整章节、训练曲线对比、算法原理折叠说明 - [SwanLab](https://swanlab.cn/)替代WandB（国内访问友好，API完全兼容） - 规范化所有代码 & 修复一些已知bugs </details>

2025-04-26

- 重要更新 - 如有兼容性需要，可访问[🔗旧仓库内容🔗](https://github.com/jingyaogong/minimind/tree/7da201a944a90ed49daef8a0265c959288dff83a)。 - MiniMind模型参数完全改名，对齐Transformers库模型（统一命名）。 - generate方式重构，继承自GenerationMixin类。 - 🔥支持llama.cpp、vllm、ollama等热门三方生态。 - 规范代码和目录结构。 - 改动词表``->`<|im_start|><|im_end|>` ```text 为兼容第三方推理框架llama.cpp、vllm，本次更新需付出一些可观代价。本次更新不再支持「直接」加载25-04-26以前的旧模型进行推理。由于Llama位置编码方式与minimind存在区别，导致映射Llama模型后QK值存在差异 MiniMind2系列旧模型均经过权重映射+（微调训练）QKVO线性层校准恢复而来。本次更新后将放弃对`minimind-v1`全系列的维护，并在仓库中下线。 ```

2025-02-09

- 迎来发布以来重大更新，Release MiniMind2 Series。 - 代码几乎全部重构，使用更简洁明了的统一结构。如有旧代码的兼容性需要，可访问[🔗旧仓库内容🔗](https://github.com/jingyaogong/minimind/tree/6e9cd28ef9b34a0a10afbdf6f59e65cb6e628efb)。 - 免去数据预处理步骤。统一数据集格式，更换为`jsonl`格式杜绝数据集下载混乱的问题。 - MiniMind2系列效果相比MiniMind-V1显著提升。 - 小问题：{kv-cache写法更标准、MoE的负载均衡loss被考虑等等} - 提供模型迁移到私有数据集的训练方案（医疗模型、自我认知样例）。 - 精简预训练数据集，并大幅提升预训练数据质量，大幅缩短个人快速训练所需时间，单卡3090即可2小时复现！ - 更新：LoRA微调脱离peft包装，从0实现LoRA过程；DPO算法从0使用PyTorch原生实现；模型白盒蒸馏原生实现。 - MiniMind2-DeepSeek-R1系列蒸馏模型诞生！ - MiniMind2具备一定的英文能力！ - 更新MiniMind2与第三方模型的基于更多大模型榜单测试性能的结果。

More...

**2024-10-05** - 为MiniMind拓展了多模态能力之---视觉 - 移步孪生项目[minimind-v](https://github.com/jingyaogong/minimind-v)查看详情！ **2024-09-27** - 09-27更新pretrain数据集的预处理方式，为了保证文本完整性，放弃预处理成.bin训练的形式（轻微牺牲训练速度）。 - 目前pretrain预处理后的文件命名为：pretrain_data.csv。 - 删除了一些冗余的代码。 **2024-09-17** - 更新minimind-v1-moe模型 - 为了防止歧义，不再使用mistral_tokenizer分词，全部采用自定义的minimind_tokenizer作为分词器。 **2024-09-01** - 更新minimind-v1 (108M)模型，采用minimind_tokenizer，预训练轮次3 + SFT轮次10，更充分训练，性能更强。 - 项目已部署至ModelScope创空间，可以在此网站上体验： - [🔗ModelScope在线体验🔗](https://www.modelscope.cn/studios/gongjy/minimind) **2024-08-27** - 项目首次开源

# 📌 快速开始

分享本人的软硬件配置（仅供参考）

* CPU: Intel(R) Core(TM) i9-10980XE CPU @ 3.00GHz * RAM: 128 GB * GPU: NVIDIA GeForce RTX 3090(24GB) * 8 * Ubuntu==20.04 * CUDA==12.2 * Python==3.10.16 * [requirements.txt](./requirements.txt)

### 第0步 ```bash git clone https://github.com/jingyaogong/minimind.git ``` ## Ⅰ 测试已有模型效果 ### 1.环境准备 ```bash pip install -r requirements.txt -i https://mirrors.aliyun.com/pypi/simple ``` ### 2.下载模型到项目根目录 ```bash git clone https://huggingface.co/jingyaogong/MiniMind2 # or https://www.modelscope.cn/models/gongjy/MiniMind2 ``` ### （可选）命令行问答 ```bash # 使用transformers格式模型 python eval_llm.py --load_from ./MiniMind2 ``` ### （可选）启动WebUI ```bash # 可能需要`python>=3.10` 安装 `pip install streamlit` # cd scripts streamlit run web_demo.py ``` ### （可选）第三方推理框架 ```bash # ollama ollama run jingyaogong/minimind2 # vllm vllm serve ./MiniMind2/ --served-model-name "minimind" ``` ## Ⅱ 从0开始自己训练 ### 1.环境准备 ```bash pip install -r requirements.txt -i https://mirrors.aliyun.com/pypi/simple ```

注：提前测试Torch是否可用cuda

```bash import torch print(torch.cuda.is_available()) ``` 如果不可用，请自行去[torch_stable](https://download.pytorch.org/whl/torch_stable.html) 下载whl文件安装。参考[链接](https://blog.csdn.net/weixin_45456738/article/details/141029610?ops_request_misc=&request_id=&biz_id=102&utm_term=%E5%AE%89%E8%A3%85torch&utm_medium=distribute.pc_search_result.none-task-blog-2~all~sobaiduweb~default-2-141029610.nonecase&spm=1018.2226.3001.4187)

### 2.数据下载从下文提供的[数据集下载链接](https://www.modelscope.cn/datasets/gongjy/minimind_dataset/files) 下载需要的数据文件（创建`./dataset`目录）并放到`./dataset`下

注：数据集须知

默认推荐下载`pretrain_hq.jsonl` + `sft_mini_512.jsonl`最快速度复现Zero聊天模型。数据文件可自由选择，下文提供了多种搭配方案，可根据自己手头的训练需求和GPU资源进行适当组合。

### 3.开始训练目录位于`trainer`

💡 检查点暂停续训

所有训练脚本均自动保存检查点，只需添加 `--from_resume 1` 参数即可自动检测加载&恢复训练： ```bash python train_pretrain.py --from_resume 1 python train_full_sft.py --from_resume 1 ... ``` **断点续训机制说明：** - 训练过程自动在 `./checkpoints/` 目录保存完整检查点（模型、优化器、训练进度等） - 检查点文件命名：`<权重名>_<维度>_resume.pth`（如：`full_sft_512_resume.pth`） - 支持跨不同GPU数量恢复（自动调整step） - 支持wandb训练记录连续性（自动恢复同一个run） > 适合长时间训练或不稳定环境，无需担心训练中断导致进度丢失 </details> **3.1 预训练（学知识）** ```bash python train_pretrain.py ``` > 执行预训练，得到 `pretrain_*.pth` 作为预训练的输出权重（其中*为模型的dimension，默认为512） **3.2 监督微调（学对话方式）** ```bash python train_full_sft.py ``` > 执行监督微调，得到 `full_sft_*.pth` 作为指令微调的输出权重（其中`full`即为全参数微调）

注：训练须知

所有训练过程默认每隔100步保存1次参数到文件`./out/***.pth`（每次会覆盖掉旧权重文件）。简单起见，此处只写明两个阶段训练过程。如需其它训练 (LoRA, 蒸馏, 强化学习, 微调推理等) 可参考下文【实验】小节的详细说明。

--- ### 4.测试自己训练的模型效果确保需要测试的模型`*.pth`文件位于`./out/`目录下。也可以直接去[此处](https://www.modelscope.cn/models/gongjy/MiniMind2-PyTorch/files)下载使用我训练的`*.pth`文件。 ```bash python eval_llm.py --weight full_sft # 或 pretrain/dpo/ppo/grpo... ```

注：测试须知

`--weight` 参数指定权重名称前缀，可选：`pretrain`, `full_sft`, `dpo`, `reason`, `ppo_actor`, `grpo`, `spo` 等其他常用参数： - `--load_from`: 模型加载路径（`model`=原生torch权重，其他路径=transformers格式） - `--save_dir`: 模型权重目录（默认`out`） - `--lora_weight`: LoRA权重名称（`None`表示不使用） - `--historys`: 携带历史对话轮数（需为偶数，0表示不携带历史） - `--max_new_tokens`: 最大生成长度（默认8192） - `--temperature`: 生成温度（默认0.85） - `--top_p`: nucleus采样阈值（默认0.85）使用方式直接查看`eval_llm.py`代码即可。

--- > [!TIP] > 所有训练脚本均为Pytorch原生框架，均支持多卡加速，假设你的设备有N (N＞1) 张显卡：单机N卡启动训练方式 (DDP, 支持多机多卡集群) ```bash torchrun --nproc_per_node N train_xxx.py ```

注：其它须知

~~单机N卡启动训练 (DeepSpeed) ```bash deepspeed --master_port 29500 --num_gpus=N train_xxx.py ```~~ 可根据需要开启wandb记录训练过程（需可直连） ```bash # 需要登录: wandb login torchrun --nproc_per_node N train_xxx.py --use_wandb # and python train_xxx.py --use_wandb ``` 通过添加`--use_wandb`参数，可以记录训练过程，训练完成后，可以在wandb网站上查看训练过程。通过修改`wandb_project` 和`wandb_run_name`参数，可以指定项目名称和运行名称。【注】：25年6月后，国内网络环境无法直连WandB，MiniMind项目默认转为使用[SwanLab](https://swanlab.cn/)作为训练可视化工具（完全兼容WandB API），即`import wandb`改为`import swanlab as wandb`即可，其他均无需改动。

# 📌 数据介绍 ## Ⅰ Tokenizer 分词器将单词从自然语言通过“词典”映射到`0, 1, 36`这样的数字，可以理解为数字就代表了单词在“词典”中的页码。可以选择自己构造词表训练一个“词典”，代码可见`./trainer/train_tokenizer.py`（仅供学习参考，若非必要无需再自行训练，MiniMind已自带tokenizer）。或者选择比较出名的开源大模型分词器，正如同直接用新华/牛津词典的优点是token编码压缩率很好，缺点是页数太多，动辄数十万个词汇短语；自己训练的分词器，优点是词表长度和内容随意控制，缺点是压缩率很低（例如"hello"也许会被拆分为"h e l l o" 五个独立的token），且生僻词难以覆盖。 “词典”的选择固然很重要，LLM的输出本质上是SoftMax到词典N个词的多分类问题，然后通过“词典”解码到自然语言。因为MiniMind体积需要严格控制，为了避免模型头重脚轻（词嵌入embedding层参数在LLM占比太高），所以词表长度短短益善。

Tokenizer介绍

第三方强大的开源模型例如Yi、qwen、chatglm、mistral、Llama3的tokenizer词表长度如下：

Tokenizer模型	词表大小	来源
yi tokenizer	64,000	01万物（中国）
qwen2 tokenizer	151,643	阿里云（中国）
glm tokenizer	151,329	智谱AI（中国）
mistral tokenizer	32,000	Mistral AI（法国）
llama3 tokenizer	128,000	Meta（美国）
minimind tokenizer	6,400	自定义

> 👉2024-09-17更新：为了防止过去的版本歧义&控制体积，minimind所有模型均使用minimind_tokenizer分词，废弃所有mistral_tokenizer版本。 ``` # 一些自言自语 > 尽管minimind_tokenizer长度很小，编解码效率弱于qwen2、glm等中文友好型分词器。 > 但minimind模型选择了自己训练的minimind_tokenizer作为分词器，以保持整体参数轻量，避免编码层和计算层占比失衡，头重脚轻，因为minimind的词表大小只有6400。 > 且minimind在实际测试中没有出现过生僻词汇解码失败的情况，效果良好。 > 由于自定义词表压缩长度到6400，使得LLM总参数量最低只有25.8M。 > 训练数据`pretrain_hq.jsonl`均来自于`匠数大模型数据集`，这部分数据相对次要，如需训练可以自由选择。 ```

## Ⅱ Pretrain数据经历了MiniMind-V1的低质量预训练数据，导致模型胡言乱语的教训，`2025-02-05` 之后决定不再采用大规模无监督的数据集做预训练。进而尝试把[匠数大模型数据集](https://www.modelscope.cn/datasets/deepctrl/deepctrl-sft-data)的中文部分提取出来，清洗出字符`<512`长度的大约1.6GB的语料直接拼接成预训练数据 `pretrain_hq.jsonl`，hq即为high quality（当然也还不算high，提升数据质量无止尽）。文件`pretrain_hq.jsonl` 数据格式为 ```json {"text": "如何才能摆脱拖延症？治愈拖延症并不容易，但以下建议可能有所帮助..."} ``` ## Ⅲ SFT数据 [匠数大模型SFT数据集](https://www.modelscope.cn/datasets/deepctrl/deepctrl-sft-data) “是一个完整、格式统一、安全的大模型训练和研究资源。从网络上的公开数据源收集并整理了大量开源数据集，对其进行了格式统一，数据清洗，包含10M条数据的中文数据集和包含2M条数据的英文数据集。” 以上是官方介绍，下载文件后的数据总量大约在4B tokens，肯定是适合作为中文大语言模型的SFT数据的。但是官方提供的数据格式很乱，全部用来sft代价太大。我将把官方数据集进行了二次清洗，把含有符号污染和噪声的条目去除；另外依然只保留了总长度`<512` 的内容，此阶段希望通过大量对话补充预训练阶段欠缺的知识。导出文件为`sft_512.jsonl`(~7.5GB)。 [Magpie-SFT数据集](https://www.modelscope.cn/organization/Magpie-Align) 收集了~1M条来自Qwen2/2.5的高质量对话，我将这部分数据进一步清洗，把总长度`<2048`的部分导出为`sft_2048.jsonl`(~9GB)。长度`<1024`的部分导出为`sft_1024.jsonl`(~5.5GB)，用大模型对话数据直接进行sft就属于“黑盒蒸馏”的范畴。进一步清洗前两步sft的数据（只保留中文字符占比高的内容），筛选长度`<512`的对话，得到`sft_mini_512.jsonl`(~1.2GB)。所有sft文件 `sft_X.jsonl` 数据格式均为 ```text { "conversations": [ {"role": "user", "content": "你好"}, {"role": "assistant", "content": "你好！"}, {"role": "user", "content": "再见"}, {"role": "assistant", "content": "再见！"} ] } ``` ## Ⅳ RLHF数据来自[Magpie-DPO数据集](https://www.modelscope.cn/datasets/Magpie-Align/MagpieLM-DPO-Data-v0.1) 大约200k条偏好数据（均是英文）生成自Llama3.1-70B/8B，可以用于训练奖励模型，优化模型回复质量，使其更加符合人类偏好。这里将数据总长度`<3000`的内容重组为`dpo.jsonl`(~0.9GB)，包含`chosen`和`rejected`两个字段，`chosen` 为偏好的回复，`rejected`为拒绝的回复。文件 `dpo.jsonl` 数据格式为 ```text { "chosen": [ {"content": "Q", "role": "user"}, {"content": "good answer", "role": "assistant"} ], "rejected": [ {"content": "Q", "role": "user"}, {"content": "bad answer", "role": "assistant"} ] } ``` ## Ⅴ Reason数据集：不得不说2025年2月谁能火的过DeepSeek... 也激发了我对RL引导的推理模型的浓厚兴趣，目前已经用Qwen2.5复现了R1-Zero。如果有时间+效果work（但99%基模能力不足）我会在之后更新MiniMind基于RL训练的推理模型而不是蒸馏模型。时间有限，最快的低成本方案依然是直接蒸馏（黑盒方式）。耐不住R1太火，短短几天就已经存在一些R1的蒸馏数据集[R1-Llama-70B](https://www.modelscope.cn/datasets/Magpie-Align/Magpie-Reasoning-V2-250K-CoT-Deepseek-R1-Llama-70B)、[R1-Distill-SFT](https://www.modelscope.cn/datasets/AI-ModelScope/R1-Distill-SFT)、 [Alpaca-Distill-R1](https://huggingface.co/datasets/shareAI/Alpaca-Distill-R1-ZH)、 [deepseek_r1_zh](https://huggingface.co/datasets/jinliuxi/deepseek_r1_zh)等等，纯中文的数据可能比较少。最终整合它们，导出文件为`r1_mix_1024.jsonl`，数据格式和`sft_X.jsonl`一致。 ## Ⅵ 更多数据集目前已经有[HqWu-HITCS/Awesome-Chinese-LLM](https://github.com/HqWu-HITCS/Awesome-Chinese-LLM) 在收集和梳理中文LLM相关的开源模型、应用、数据集及教程等资料，并持续更新这方面的最新进展。全面且专业，Respect！ --- ## Ⅷ MiniMind训练数据集 > [!NOTE] > 2025-02-05后，开源MiniMind最终训练所用的所有数据集，因此无需再自行预处理大规模数据集，避免重复性的数据处理工作。 MiniMind训练数据集下载地址： [ModelScope](https://www.modelscope.cn/datasets/gongjy/minimind_dataset/files) | [HuggingFace](https://huggingface.co/datasets/jingyaogong/minimind_dataset/tree/main) > 无需全部clone，可单独下载所需的文件将下载的数据集文件放到`./dataset/`目录下（✨为推荐的必须项） ```bash ./dataset/ ├── dpo.jsonl (55MB, ✨) ├── lora_identity.jsonl (22.8KB) ├── lora_medical.jsonl (34MB) ├── pretrain_hq.jsonl (1.6GB, ✨) ├── r1_mix_1024.jsonl (340MB) ├── rlaif-mini.jsonl (1MB, ✨) ├── sft_1024.jsonl (5.6GB) ├── sft_2048.jsonl (9GB) ├── sft_512.jsonl (7.5GB) └── sft_mini_512.jsonl (1.2GB, ✨) ```

注：各数据集简介

* `dpo.jsonl`✨ --RLHF阶段数据集（已精简优化，适合快速训练） * `lora_identity.jsonl` --自我认知数据集（例如：你是谁？我是minimind...），推荐用于lora训练（亦可用于全参SFT，勿被名字局限） * `lora_medical.jsonl` --医疗问答数据集，推荐用于lora训练（亦可用于全参SFT，勿被名字局限） * `pretrain_hq.jsonl`✨ --预训练数据集，整合自匠数科技（推荐设置`max_seq_len≈320`） * `r1_mix_1024.jsonl` --DeepSeek-R1-1.5B蒸馏数据，每条数据字符最大长度为1024（推荐设置`max_seq_len≈720`） * `rlaif-mini.jsonl` --RLAIF训练数据集，从SFT数据集中随机采样1万条高质量对话，用于PPO/GRPO/SPO等强化学习算法训练 * `sft_1024.jsonl` --整合自Qwen2.5蒸馏数据（是sft_2048的子集），每条数据字符最大长度为1024（推荐设置`max_seq_len≈650`） * `sft_2048.jsonl` --整合自Qwen2.5蒸馏数据，每条数据字符最大长度为2048（推荐设置`max_seq_len≈1400`） * `sft_512.jsonl` --整合自匠数科技SFT数据，每条数据字符最大长度为512（推荐设置`max_seq_len≈350`） * `sft_mini_512.jsonl`✨ --极简整合自匠数科技SFT数据+Qwen2.5蒸馏数据（用于快速训练Zero模型），每条数据字符最大长度为512（推荐设置`max_seq_len≈340`）训练参数`max_seq_len`目前指的是tokens长度，而非绝对字符数。本项目tokenizer在中文文本上大约`1.5~1.7 字符/token`，纯英文的压缩比在`4~5 字符/token`，不同数据分布会有波动。数据集命名标注的“最大长度”均为字符数，100长度的字符串可粗略换算成`100/1.5≈67`的tokens长度。例如： * 中文：`白日依山尽`5个字符可能被拆分为[`白日`,`依`,`山`,`尽`] 4个tokens； * 英文：`The sun sets in the west`24个字符可能被拆分为[`The `,`sun `,`sets `,`in `,`the`,`west`] 6个tokens “推荐设置”给出了各个数据集上最大tokens长度的粗略估计。须知max_seq_len可以激进/保守/均衡地调整，因为更大或更小均无法避免副作用：一些样本短于max_seq_len后被padding浪费算力，一些样本长于max_seq_len后被截断语意。在 `算力效率` <---> `语义完整性` 之间找到一个平衡点即可

![dataset](./images/dataset.jpg)

说明 & 推荐训练方案

* MiniMind2 Series均经过共约20GB语料训练，大约4B tokens，即对应上面的数据组合训练结果（开销：💰💰💰💰💰💰💰💰，效果：😊😊😊😊😊😊） * 想要最快速度从0实现Zero模型，推荐使用`pretrain_hq.jsonl` + `sft_mini_512.jsonl` 的数据组合，具体花销和效果可查看下文表格（开销：💰，效果：😊😊） * 推荐具备一定算力资源或更在意效果的朋友可以考虑前者完整复现MiniMind2；仅有单卡GPU或在乎短时间快速复现的朋友强烈推荐后者； * 【折中方案】亦可选择例如`sft_mini_512.jsonl`、`sft_1024.jsonl`中等规模数据进行自由组合训练（开销：💰💰💰，效果：😊😊😊😊）。

# 📌 Model ## Structure MiniMind-Dense（和[Llama3.1](https://ai.meta.com/blog/meta-llama-3-1/)一样）使用了Transformer的Decoder-Only结构，跟GPT-3的区别在于： * 采用了GPT-3的预标准化方法，也就是在每个Transformer子层的输入上进行归一化，而不是在输出上。具体来说，使用的是RMSNorm归一化函数。 * 用SwiGLU激活函数替代了ReLU，这样做是为了提高性能。 * 像GPT-Neo一样，去掉了绝对位置嵌入，改用了旋转位置嵌入（RoPE），这样在处理超出训练长度的推理时效果更好。 --- MiniMind-MoE模型，它的结构基于Llama3和[Deepseek-V2/3](https://arxiv.org/pdf/2405.04434)中的MixFFN混合专家模块。 * DeepSeek-V2在前馈网络（FFN）方面，采用了更细粒度的专家分割和共享的专家隔离技术，以提高Experts的效果。 --- MiniMind的整体结构一致，只是在RoPE计算、推理函数和FFN层的代码上做了一些小调整。其结构如下图（重绘版）： ![structure](./images/LLM-structure.png) ![structure-moe](./images/LLM-structure-moe.png) 修改模型配置见[./model/model_minimind.py](./model/model_minimind.py)。参考模型参数版本见下表： | Model Name | params | len_vocab | rope_theta | n_layers | d_model | kv_heads | q_heads | share+route | |-------------------|--------|-----------|------------|----------|---------|----------|---------|-------------| | MiniMind2-Small | 26M | 6400 | 1e6 | 8 | 512 | 2 | 8 | - | | MiniMind2-MoE | 145M | 6400 | 1e6 | 8 | 640 | 2 | 8 | 1+4 | | MiniMind2 | 104M | 6400 | 1e6 | 16 | 768 | 2 | 8 | - | | minimind-v1-small | 26M | 6400 | 1e4 | 8 | 512 | 8 | 16 | - | | minimind-v1-moe | 4×26M | 6400 | 1e4 | 8 | 512 | 8 | 16 | 1+4 | | minimind-v1 | 108M | 6400 | 1e4 | 16 | 768 | 8 | 16 | - | ## Model Configuration 📋关于LLM的参数配置，有一篇很有意思的论文[MobileLLM](https://arxiv.org/pdf/2402.14905)做了详细的研究和实验。 Scaling Law在小模型中有自己独特的规律。引起Transformer参数成规模变化的参数几乎只取决于`d_model`和`n_layers`。 * `d_model`↑ + `n_layers`↓ -> 矮胖子 * `d_model`↓ + `n_layers`↑ -> 瘦高个 2020年提出Scaling Law的论文认为，训练数据量、参数量以及训练迭代次数才是决定性能的关键因素，而模型架构的影响几乎可以忽视。然而似乎这个定律对小模型并不完全适用。 MobileLLM提出架构的深度比宽度更重要，「深而窄」的「瘦长」模型可以学习到比「宽而浅」模型更多的抽象概念。例如当模型参数固定在125M或者350M时，30～42层的「狭长」模型明显比12层左右的「矮胖」模型有更优越的性能，在常识推理、问答、阅读理解等8个基准测试上都有类似的趋势。这其实是非常有趣的发现，因为以往为100M左右量级的小模型设计架构时，几乎没人尝试过叠加超过12层。这与MiniMind在训练过程中，模型参数量在`d_model`和`n_layers`之间进行调整实验观察到的效果是一致的。然而「深而窄」的「窄」也是有维度极限的，当d_model<512时，词嵌入维度坍塌的劣势非常明显，增加的layers并不能弥补词嵌入在固定q_head带来d_head不足的劣势。当d_model>1536时，layers的增加似乎比d_model的优先级更高，更能带来具有"性价比"的参数->效果增益。 * 因此MiniMind设定small模型dim=512，n_layers=8来获取的「极小体积<->更好效果」的平衡。 * 设定dim=768，n_layers=16来获取效果的更大收益，更加符合小模型Scaling-Law的变化曲线。作为参考，GPT3的参数设定见下表： ![gpt3_config.png](./images/gpt3_config.png) --- # 📌 Experiment ## Ⅰ 训练开销 - **时间单位**：小时 (h)。 - **成本单位**：人民币 (￥)；7￥ ≈ 1美元。 - **3090 租卡单价**：≈1.3￥/h（可自行参考实时市价）。 - **参考标准**：表格仅实测 `pretrain` 和 `sft_mini_512` 两个数据集的训练时间，其它耗时根据数据集大小估算（可能存在些许出入）。 > 基于 3090 （单卡）成本计算 | Model Name | params | pretrain | sft_mini_512 | sft_512 | sft_1024 | sft_2048 | RLHF | |-----------------|--------|------------------|------------------|---------------|-------------------|------------------|---------------| | MiniMind2-Small | 26M | ≈1.1h
≈1.43￥ | ≈1h
≈1.3￥ | ≈6h
≈7.8￥ | ≈4.58h
≈5.95￥ | ≈7.5h
≈9.75￥ | ≈1h
≈1.3￥ | | MiniMind2 | 104M | ≈3.9h
≈5.07￥ | ≈3.3h
≈4.29￥ | ≈20h
≈26￥ | ≈15h
≈19.5￥ | ≈25h
≈32.5￥ | ≈3h
≈3.9￥ | ---

训练开销总结&预测

> MiniMind2-Small参数 >> `pretrain_hq`+`sft_mini_512`数据集
单卡3090 (1 epoch) + 2.1小时 + 花费2.73元人民币
即可从0训练出MiniMind-Zero-0.025B模型!!! > MiniMind2-Small参数 >> `pretrain_hq`+`sft_512`+`sft_2048`+`dpo`数据集
单卡3090 (2 epochs) + 大约38.16小时 + 花费49.61元人民币
即可从0训练出MiniMind2-Small-0.025B模型!!! > MiniMind2参数 >> `pretrain_hq`+`sft_512`+`sft_2048`+`dpo`数据集
单卡3090 (2 epochs) + 大约122小时 + 花费158.6元人民币
即可从0训练出MiniMind2-0.1B模型!!!

✨基于单卡NVIDIA 3090的`MiniMind-Zero`从0训练仅需`2小时` + `3块钱`，实现ChatBot效果！ ✨PS：若采用8卡4090训练，总用时甚至可以压缩到10分钟以内！（由于时间更短，花费同样3元左右，与单卡成本相当） ✨以极低极低的门槛，实现人人可玩的大模型自由！这正是MiniMind系列的诞生初衷！ ✨仅价值`3块钱`成本的`MiniMind-Zero`并不是噱头！Chat测试： ```text 👶: 请介绍一下自己。 🤖️: 作为人工智能，我没有实际的生活，也没有自我意识，所以没有自己的生活。我被设计成能够帮助用户解答问题、提供信息、进行对话等。我的设计和功能是由计算机科学、机器学习、人工智能技术和算法所构建的，我通过编程和算法实现。 👶: 推荐一些杭州的特色美食吧。 🤖️: 杭州有很多美味的特色美食，比如鸡肉串、鳗鱼头、水煮鱼、豆腐脑等。这些美食都非常美味，有着独特的风味和口感，绝对是值得一试的美食。 👶: 请为我讲解“大语言模型”这个概念。 🤖️: 大语言模型是一种人工智能技术，它使用大量的文本数据来训练模型，然后在不断的迭代中不断优化模型。它的目标是根据输入的数据来生成符合特定需求的文本，这些文本可以是任何你感兴趣的主题。 👶: Introduce the history of the United States, please. 🤖️: 您提到的“Introok's the believeations of theument." 这个名字来源于中国古代的"groty of of the change." ``` 极速且初具效果，甚至仍然可以进一步压缩获取更小更优质的训练数据。 Zero模型权重保存为 `full_sft_512_zero.pth`（见下文MiniMind模型文件链接），如有兴趣可下载检验此模型效果。 --- ## Ⅱ 主要训练（必须） > 所有训练脚本均 `cd ./trainer` 目录执行 ### **1. 预训练 (Pretrain)**: LLM首先要学习的并非直接与人交流，而是让网络参数中充满知识的墨水，“墨水” 理论上喝的越饱越好，产生大量的对世界的知识积累。预训练就是让Model先埋头苦学大量基本的知识，例如从Wiki百科、新闻、书籍整理大规模的高质量训练数据。这个过程是“无监督”的，即人类不需要在过程中做任何“有监督”的校正，而是由模型自己从大量文本中总结规律学习知识点。模型此阶段目的只有一个：**学会词语接龙**。例如输入"秦始皇"四个字，它可以接龙"是中国的第一位皇帝"。 ```bash torchrun --nproc_per_node 1 train_pretrain.py # 1即为单卡训练，可根据硬件情况自行调整 (设置>=2) # or python train_pretrain.py ``` > 训练后的模型权重文件默认每隔`100步`保存为: `pretrain_*.pth`（* > 为模型具体dimension，每次保存时新文件会覆盖旧文件） | MiniMind2-Small (512dim) | MiniMind2 (768dim) | |---|---| | | | ### **2. 有监督微调 (Supervised Fine-Tuning)**: 经过预训练，LLM此时已经掌握了大量知识，然而此时它只会无脑地词语接龙，还不会与人聊天。 SFT阶段就需要把半成品LLM施加一个自定义的聊天模板进行微调。例如模型遇到这样的模板【问题->回答，问题->回答】后不再无脑接龙，而是意识到这是一段完整的对话结束。称这个过程为指令微调，就如同让已经学富五车的「牛顿」先生适应21世纪智能手机的聊天习惯，学习屏幕左侧是对方消息，右侧是本人消息这个规律。在训练时，MiniMind的指令和回答长度被截断在512，是为了节省显存空间。就像学习写作时，会先从短的文章开始，当学会写作200字作文后，800字文章也可以手到擒来。在需要长度拓展时，只需要准备少量的2k/4k/8k长度对话数据进行进一步微调即可（此时最好配合RoPE-NTK的基准差值）。 > 在推理时通过调整RoPE线性差值，实现免训练长度外推到2048及以上将会很方便。 ```bash torchrun --nproc_per_node 1 train_full_sft.py # or python train_full_sft.py ``` > 训练后的模型权重文件默认每隔`100步`保存为: `full_sft_*.pth`（* > 为模型具体dimension，每次保存时新文件会覆盖旧文件） | MiniMind2-Small (512dim) | MiniMind2 (768dim) | |---|---| | | | ## Ⅲ 其它训练阶段（可选） > 所有训练脚本均 `cd ./trainer` 目录执行 ### **3. 知识蒸馏 (Knowledge Distillation, KD)** 在前面的所有训练步骤中，模型已经完全具备了基本能力，通常可以学成出师了。而知识蒸馏可以进一步优化模型的性能和效率，所谓知识蒸馏，即学生模型面向教师模型学习。教师模型通常是经过充分训练的大模型，具有较高的准确性和泛化能力。学生模型是一个较小的模型，目标是学习教师模型的行为，而不是直接从原始数据中学习。在SFT学习中，模型的目标是拟合词Token分类硬标签（hard labels），即真实的类别标签（如 0 或 6400）。在知识蒸馏中，教师模型的softmax概率分布被用作软标签（soft labels）。小模型仅学习软标签，并使用KL-Loss来优化模型的参数。通俗地说，SFT直接学习老师给的解题答案。而KD过程相当于“打开”老师聪明的大脑，尽可能地模仿老师“大脑”思考问题的神经元状态。例如，当老师模型计算`1+1=2`这个问题的时候，最后一层神经元a状态为0，神经元b状态为100，神经元c状态为-99... 学生模型通过大量数据，学习教师模型大脑内部的运转规律。这个过程即称之为：知识蒸馏。知识蒸馏的目的只有一个：让小模型体积更小的同时效果更好。然而随着LLM诞生和发展，模型蒸馏一词被广泛滥用，从而产生了“白盒/黑盒”知识蒸馏两个派别。 GPT-4这种闭源模型，由于无法获取其内部结构，因此只能面向它所输出的数据学习，这个过程称之为黑盒蒸馏，也是大模型时代最普遍的做法。黑盒蒸馏与SFT过程完全一致，只不过数据是从大模型的输出收集，因此只需要准备数据并且进一步FT即可。注意更改被加载的基础模型为`full_sft_*.pth`，即基于微调模型做进一步的蒸馏学习。 `./dataset/sft_1024.jsonl`与`./dataset/sft_2048.jsonl` 均收集自qwen2.5-7/72B-Instruct大模型，可直接用于SFT以获取Qwen的部分行为。 ```bash # 注意需要更改train_full_sft.py数据集路径，以及max_seq_len torchrun --nproc_per_node 1 train_full_sft.py # or python train_full_sft.py ``` > 训练后的模型权重文件默认每隔`100步`同样保存为: `full_sft_*.pth`（*为模型具体dimension，每次保存时新文件会覆盖旧文件）此处应当着重介绍MiniMind实现的白盒蒸馏代码`train_distillation.py`，由于MiniMind同系列本身并不存在强大的教师模型，因此白盒蒸馏代码仅作为学习参考。 ```bash torchrun --nproc_per_node 1 train_distillation.py # or python train_distillation.py ``` ### **4. LoRA (Low-Rank Adaptation)** LoRA是一种高效的参数高效微调（Parameter-Efficient Fine-Tuning, PEFT）方法，旨在通过低秩分解的方式对预训练模型进行微调。相比于全参数微调（Full Fine-Tuning），LoRA 只需要更新少量的参数。 LoRA 的核心思想是：在模型的权重矩阵中引入低秩分解，仅对低秩部分进行更新，而保持原始预训练权重不变。代码可见`./model/model_lora.py`和`train_lora.py`，完全从0实现LoRA流程，不依赖第三方库的封装。 ```bash torchrun --nproc_per_node 1 train_lora.py # or python train_lora.py ``` > 训练后的模型权重文件默认每隔`100步`保存为: `lora_xxx_*.pth`（* > 为模型具体dimension，每次保存时新文件会覆盖旧文件）非常多的人困惑，如何使模型学会自己私有领域的知识？如何准备数据集？如何迁移通用领域模型打造垂域模型？这里举几个例子，对于通用模型，医学领域知识欠缺，可以尝试在原有模型基础上加入领域知识，以获得更好的性能。同时，通常不希望学会领域知识的同时损失原有基础模型的其它能力，此时LoRA可以很好的改善这个问题。只需要准备如下格式的对话数据集放置到`./dataset/lora_xxx.jsonl`，启动 `python train_lora.py` 训练即可得到`./out/lora/lora_xxx.pth`新模型权重。 **医疗场景** ``` {"conversations": [{"role": "user", "content": "请问颈椎病的人枕头多高才最好？"}, {"role": "assistant", "content": "颈椎病患者选择枕头的高度应该根据..."}]} {"conversations": [{"role": "user", "content": "请问xxx"}, {"role": "assistant", "content": "xxx..."}]} ``` **自我认知场景** ``` {"conversations": [{"role": "user", "content": "你叫什么名字？"}, {"role": "assistant", "content": "我叫minimind..."}]} {"conversations": [{"role": "user", "content": "你是谁"}, {"role": "assistant", "content": "我是..."}]} ``` 此时【基础模型+LoRA模型】即可获得医疗场景模型增强的能力，相当于为基础模型增加了LoRA外挂，这个过程并不损失基础模型的本身能力。可以通过`eval_llm.py`进行模型评估测试。 ```bash # 注意：weight参数指定基础模型类型，需与train_lora训练时使用的基础模型保持一致 python eval_llm.py --weight dpo --lora_weight lora_medical ``` **小测试** ``` 👶: 我最近经常感到头晕，可能是什么原因？ 🤖️: 头晕可能是由于多种原因，包括但不限于：心脏疾病、眼睛损伤、过敏反应、皮肤问题、过敏反应、压力、焦虑、疲劳、药物副作用、性功能障碍或者其他... --- 👶: 你和openai是什么关系？ 🤖️: 我是 MiniMind，一个由 Jingyao Gong 开发的人工智能助手。我通过自然语言处理和算法训练来与用户进行交互。 ``` PS：只要有所需要的数据集，也可以full_sft全参微调（需要进行通用知识的混合配比，否则过拟合领域数据会让模型变傻，损失通用性） ### **5. 训练推理模型 (Reasoning Model)** DeepSeek-R1实在太火了，几乎重新指明了未来LLM的新范式。论文指出`>3B`的模型经历多次反复的冷启动和RL奖励训练才能获得肉眼可见的推理能力提升。最快最稳妥最经济的做法，以及最近爆发的各种各样所谓的推理模型几乎都是直接面向数据进行蒸馏训练，但由于缺乏技术含量，蒸馏派被RL派瞧不起（hhhh）。本人迅速已经在Qwen系列1.5B小模型上进行了尝试，很快复现了Zero过程的数学推理能力。然而一个遗憾的共识是：参数太小的模型直接通过冷启动SFT+GRPO几乎不可能获得任何推理效果。 ~~MiniMind2第一时间只能坚定不移的选择做蒸馏派，日后基于0.1B模型的RL如果同样取得小小进展会更新此部分的训练方案。~~ 做蒸馏需要准备的依然是和SFT阶段同样格式的数据即可，数据集来源已如上文介绍。数据格式例如： ```json lines { "conversations": [ { "role": "user", "content": "你好，我是小芳，很高兴认识你。" }, { "role": "assistant", "content": "\n你好！我是由中国的个人开发者独立开发的智能助手MiniMind-R1-Lite-Preview，很高兴为您提供服务！\n\n\n你好！我是由中国的个人开发者独立开发的智能助手MiniMind-R1-Lite-Preview，很高兴为您提供服务！\n" } ] } ``` 推理模型R1的回复模板是： ```text \n思考过程\n\n \n最终回答\n ``` 这在GRPO中通过设置规则奖励函数约束模型符合思考标签和回复标签（在冷启动靠前的阶段奖励值设置应该提高一些）另一个问题是蒸馏过程虽然和SFT一样，但实验结果是模型难以每次都符合模板规范的回复，即脱离思考和回复标签约束。这里的小技巧是增加标记位置token的损失惩罚，详见`train_reason.py`: ```text # 在 sp_ids 对应的位置增加额外的惩罚 ... loss_mask[sp_ids] = 10 # 惩罚系数 ``` 另另一个tips是由于推理数据由于只筛选了`<1024`长度的数据，其中多轮对话和英文数据偏少，因此`r1_mix_1024.jsonl`进行了大约10k条多轮对话+英文数据的混合，防止模型遗忘严重。脚本默认基于rlhf后的基模型做推理能力的蒸馏微调，下面直接启动训练即可： ```bash torchrun --nproc_per_node 1 train_reason.py # or python train_reason.py ``` > 训练后的模型权重文件默认每隔`100步`保存为: `reason_*.pth`（*为模型具体dimension，每次保存时新文件会覆盖旧文件）测试一下： ```text 👶: 请介绍一下自己。 🤖️: 嗯，用户让我介绍一下自己。我现在需要解释一下自己。首先，我应该明确用户是谁，是学生、职场人士还是普通人。用户可能是一个学生或者职场人士，所以信息传递应该是帮助学生和职场人士的信息。然后，我需要回应用户，这可能包括介绍自己的位置、兴趣爱好、职业经历等信息。用户还可能想了解自己在哪里，比如职业发展、工作经验等。我应该注意用词要正式，不要太正式，同时要保持简洁明了。这样用户容易理解，也方便他们查阅相关资料。最后，我应该总结一下，让用户知道我是如何帮助他们完成他们的任务的，这样他们有更多关于我的信息。我是**“你的名字”，你叫什么名字？ 👶: 你更擅长哪一个学科？ 🤖️: 您好！我是由中国的个人开发者开发的智能助手MiniMind-R1。如您有任何任何问题，我会尽我所能为您提供帮助。您好！我是由中国的个人开发者开发的智能助手MiniMind-R1。如您有任何任何问题，我会尽我所能为您提供帮助。 ``` ## IV 强化学习后训练 LLM里的强化学习方法可分两类： 1. **基于人类反馈的强化学习 (Reinforcement Learning from Human Feedback, RLHF)** - 通过**人类**对模型输出的偏好进行评价来训练模型，使其生成更符合人类价值观和偏好的内容。 2. **基于AI反馈的强化学习 (Reinforcement Learning from AI Feedback, RLAIF)** - 使用**AI模型**（通常是预训练的语言奖励模型）来提供反馈，而不直接依赖人类的人工标注。 - 这里的“AI”也可以是某些规则奖励，例如数学答案/代码解释器... | 类型 | 裁判 | 优点 | 缺点 | |-------|----|-----------|------------| | RLHF | 人类 | 更贴近真实人类偏好 | 成本高、效率低 | | RLAIF | 模型 | 自动化、可扩展性强 | 可能偏离人类真实偏好 | 二者本质上是一样的，都是通过**强化学习的方式**，利用某种形式的"**反馈**"来优化模型的行为。除了**反馈**的来源不同，其他并无任何区别。 ### 👀 PO算法的统一视角在介绍实现具体算法之前，我先以个人理解的极简视角，阐述所有Policy Optimization (PO)算法的统一共性。所有RL算法的本质都只是在优化一个期望： $$\mathcal{J}_{PO} = \mathbb{E}_{q \sim P(Q), o \sim \pi(O|q)} \left[ \underbrace{f(r_t)}_{\text{策略项}} \cdot \underbrace{g(A_t)}_{\text{优势项}} - \underbrace{h(\text{KL}_t)}_{\text{正则项}} \right]$$ 训练时，只需**最小化负目标函数**，即: $\mathcal{L_{PO}}=-\mathcal{J_{PO}}$ 这个框架只包含三个核心组件： * **策略项** $f(r_t)$: 如何使用概率比 $r_t$? 即告诉模型新旧策略偏差有多大，是否探索到了更好的token * **优势项** $g(A_t)$: 如何计算优势 $A_t$, 这很重要！大模型算对定积分也不足为奇，小模型回答对加减法优势通常都是正的 * **正则项** $h(\text{KL}_t)$: 如何约束变化幅度 $\text{KL}_t$, 既防止跑偏又防止管的太死

（展开）符号说明

| 符号 | 含义 | 说明 | 值域 | |------|------|------|------| | $q$ | 问题/提示词 | 从数据集 $P(Q)$ 中采样 | - | | $o$ | 模型输出序列 | 由策略 $\pi$ 生成 | - | | $r_t$ | 概率比 | $r_t = \frac{\pi_\theta(o_t\|q, o_{<t})}{\pi_{ref}(o_t\|q, o_{<t})}$ | $(0, +\infty)$ | | $A_t$ | 优势函数 | 衡量某个动作相比基线有多好 | $(-\infty, +\infty)$ | | $\text{KL}_t$ | KL散度 | 防止策略偏离参考模型太远 | $[0, +\infty)$ |

不同的**xxPO算法**本质上只是对这三个组件的不同设计的实例化！ --- ### **6. 基于人类反馈的强化学习 (Reinforcement Learning from Human Feedback, RLHF)** 在前面的训练步骤中，模型已经具备了基本的对话能力，但是这样的能力完全基于单词接龙，缺少正反样例的激励。模型此时尚未知什么回答是好的，什么是差的。希望它能够更符合人的偏好，降低让人类不满意答案的产生概率。这个过程就像是让模型参加新的培训，从优秀员工的作为例子，消极员工作为反例，学习如何更好地回复。 #### 6.1 Direct Preference Optimization 直接偏好优化（DPO）算法，损失为： $$\mathcal{L}_{DPO} = -\mathbb{E}\left[\log \sigma\left(\beta \left[\log \frac{\pi_\theta(y_w|x)}{\pi_{ref}(y_w|x)} - \log \frac{\pi_\theta(y_l|x)}{\pi_{ref}(y_l|x)}\right]\right)\right]$$ 其中： - **策略项**: $f(r_t) = \log r_w - \log r_l$ (对比chosen vs rejected的概率比) - **优势项**: $g(A_t)$ = / (通过偏好对比，无需显式计算优势) - **正则项**: $h(\text{KL}_t)$ = 隐含在 $\beta$ 中 (控制偏离参考模型程度) 特别地， - DPO从PPO带KL约束的目标推导出对偏好对的解析训练目标，直接最大化"chosen优于rejected"的对数几率；无需同步训练Reward/Value模型。DPO只需跑`actor`与`ref`两个模型，显存占用低、收敛稳定、实现简单。 - 训练范式：off‑policy，使用静态偏好数据集，可反复多轮epoch；Ref模型固定（预先缓存输出）。 - DPO的局限在于不做在线探索，更多用于"偏好/安全"的人类价值对齐；对"能不能做对题"的智力能力提升有限（当然这也取决于数据集，大规模收集正反样本并人类评估很困难）。 ```bash torchrun --nproc_per_node 1 train_dpo.py # or python train_dpo.py ``` > 训练后的模型权重文件默认每隔`100步`保存为: `dpo_*.pth`（*为模型具体dimension，每次保存时新文件会覆盖旧文件） ### **7. 基于AI反馈的强化学习 (Reinforcement Learning from AI Feedback, RLAIF)** 相比RLHF依赖人类标注chosen/rejected偏好对，RLAIF则完全由AI来充当"裁判"。所谓AI"裁判"可以是model-base的奖励大模型(Reward Model)，也可以是R1一样设置规则函数进行校验，也可以是例如工具调用的环境反馈。例如：数学题答案是否正确、工具调用执行代码能否通过测试用例、推理过程是否符合格式...都可以自动化判断。 RLAIF的最大优势在于**可扩展性**和**On-Policy**的特点——不需要昂贵的人工标注，可以生成海量的训练样本，让模型在在线大量试错中快速进化。 MiniMind 着手实现**2+N**种基本+前沿的RLAIF方法： * **PPO**、**GRPO** 被大规模验证的经典RL算法； * N种前沿RL算法（不定期以Exp性质更新）。 #### 1️⃣ 数据集准备 (需要) 为了快速验证RLAIF的效果，这里从SFT数据集中随机采样了1万条高质量对话，构建约1MB大小的`rlaif-mini.jsonl`([Huggingface](https://huggingface.co/datasets/jingyaogong/minimind_dataset/blob/main/rlaif-mini.jsonl)) 数据格式与SFT一致，但assistant并不需要内容，因为训练过程中完全由 $\Pi$ 策略模型实时采样生成。因此形如： ```json { "conversations": [ {"role": "user", "content": "请解释一下什么是光合作用？"}, {"role": "assistant", "content": "无"} ] } ``` RLAIF的训练过程中，模型会基于user的问题生成1或多个候选回答，然后由奖励函数/模型对回答打分，分数高的回答会被鼓励（增加 $\Pi$ 策略概率），分数低的回答会被抑制（降低 $\Pi$ 策略概率）。这个"打分->调整"的循环就是强化学习的核心。 #### 2️⃣ 奖励模型准备 (需要) 已知RLAIF训练需要“奖励模型 (Reward Model)”对生成的回答进行打分。此处选取小型且高质量的InternLM2-1.8B-Reward ([ModelScope](https://modelscope.cn/models/Shanghai_AI_Laboratory/internlm2-1_8b-reward) | [HuggingFace](https://huggingface.co/internlm/internlm2-1_8b-reward)) 作为基础奖励模型。下载奖励模型后需要放置在minimind项目的**同级目录**下，推荐结构如下： ``` project/ ├── minimind/ # MiniMind项目 │ ├── model/ │ └── ... └── internlm2-1_8b-reward/ # 奖励模型（与minimind同级） ├── config.json ├── model.safetensors └── ... ```

奖励机制选择与MiniMind限制说明（点击展开）

**1. 奖励机制的多样性** RLAIF中的"奖励信号"来源可以非常灵活： - **Model-based奖励**：可使用专门的Reward Model（如InternLM2-Reward），也可使用通用LLM+提示词进行打分（如Qwen3-as-a-Judge）。奖励模型规模和架构均可自由选择。 - **Rule-based奖励**：可以基于规则函数构造奖励信号，例如： - 数学题答案正确性验证（Ground Truth对比） - SQL执行成功率与结果准确性 - 代码解释器运行结果（pass@k） - 工具调用返回状态（API成功/失败） - 格式合规性检查（JSON/XML解析） - 推理链完整性评估（CoT步骤数） - **Environment-based奖励**：在Agent场景中，环境反馈本身即为天然奖励（如游戏得分、Research完整度、任务完成度）。任何能够量化"回答质量"的机制都可作为RL的奖励来源。DeepSeek R1就是典型案例：使用规则函数验证数学答案正确性作为奖励，无需额外的Reward Model。 **2. MiniMind限制：奖励稀疏问题** RLAIF训练既可以针对推理模型也可以针对非推理模型，区别仅在于格式。然而对于MiniMind这种0.1B参数量极小能力弱的模型，在通用任务（如R1风格的数学数据集）上会遇到严重的奖励稀疏(Reward Sparsity)问题： - **现象**：模型生成的候选回答几乎全部错误，导致所有奖励分数 $r(x,y) \approx 0$ - **后果**：优势函数 $A(x,y) = r(x,y) - b(x) \approx 0$，策略梯度信号消失，无法有效更新参数 $\theta$ 如同让小学生做高考数学题，无论尝试多少次都得零分，无法通过分数差异学习改进策略。因此这是RL算法的根本原理限制的。为缓解此问题，MiniMind的实现选择了**model-based的连续性奖励信号**： - Reward Model输出连续分数（如-2.5到+3.0），而非二元的0/1 - 即使回答质量都差，也仍能区分"更更差"(-3.0)和"更差"(-2.8)的细微差异。所以这种**稠密且连续**的奖励信号能够为优势函数 $A(x,y)$ 提供非零梯度，使得策略网络得以渐进式优化 - 也可以混合多种奖励源: $r_{\text{total}} = \alpha \cdot r_{\text{model}} + \beta \cdot r_{\text{rule}}$ (例如既可以检测think标签格式reward，又可以综合回答本身质量的reward分数) - minimind实践中避免直接使用rule-based二元奖励 + 超纲难度数据（如MATH500），易导致奖励全零； - 监控训练时观察奖励分数的方差 $\text{Var}(r)$，若持续接近0则需调整数据或奖励机制 **对于生产级大模型的Agentic RL场景**：在真实Agent系统（代码生成、工具调用、检索-规划-执行的多轮链路）中，奖励是“延迟整轮结算”的不同范式： - LLM需要逐token生成工具调用指令（tool_call），经历解析（tool_parse）、工具执行（tool_exec），再把结果拼接回上下文继续下一步；循环往复直到完成。 - 一次完整的任务链路包含多次调用+思考，直到终止条件满足时计算一次总reward（如任务是否完成、测试是否通过、目标是否命中）。因此，Agentic RL更接近稀疏/延迟奖励设定：梯度回传在“整轮结束后”才发生，和非Agentic RL任务在对话单轮上“即时评分即时更新”有很大不同。这也解释了Agent任务上更偏向环境反馈（environment-based reward），而非凭Reward Model进行静态打分。 - **环境交互反馈**：最终以执行结果为准（代码是否跑通、API是否返回成功、子目标是否完成）； - **Model-based奖励局限**：对长链路、可执行语义的全貌捕捉有限，且大概率和真实环境反馈不一致（reward hacking）。

--- #### 7.1 [Proximal Policy Optimization](https://arxiv.org/abs/1707.06347) PPO 是2017年OpenAI提出的非常经典强化学习算法，也是LLM RL通用的基线方法，甚至不需要加之一。 **PPO损失**： $$\mathcal{L}_{PPO} = -\mathbb{E}\left[\min(r_t \cdot A_t, \text{clip}(r_t, 1-\varepsilon, 1+\varepsilon) \cdot A_t)\right] + \beta \cdot \mathbb{E}[\text{KL}]$$ 其中： - **策略项**: $f(r_t) = \min(r_t, \text{clip}(r_t, 1-\varepsilon, 1+\varepsilon))$ (裁剪概率比防止更新过激) - **优势项**: $g(A_t) = R - V(s)$ (通过Critic网络估计价值函数) - **正则项**: $h(\text{KL}_t) = \beta \cdot \mathbb{E}[\text{KL}]$ (全局KL散度约束) 对比DPO而言， - DPO (Off-Policy)：训练数据是静态的偏好数据集（chosen vs rejected），可以反复使用同一批数据训练多个epoch，就像传统监督学习一样。数据效率高，训练成本低。它直接优化偏好对的对数似然，无需Reward Model。 - PPO (On-Policy)：必须用当前策略实时采样生成新数据，旧策略采集的数据不能用（会有distribution shift问题）。虽然通过importance sampling和clip机制允许轻微的分布偏移，但本质上要求数据来自相对新鲜的策略。数据效率低，但适合探索式学习。简单来说： - 前者教模型按离线预定的「好/坏标准」学习，尽管它并非是当前模型所能输出的（例如参考世界冠/亚军录像练习打球）； - 后者实时地教模型把事情做对做好，在线采样自最新模型policy（教练手把手教打，为每个动作实时打分）。 MiniMind的PPO实现包含了Actor模型(生成回答)和Critic模型(评估回答价值)，以及完整的GAE(Generalized Advantage Estimation)优势函数计算。 **训练方式**： ```bash torchrun --nproc_per_node N train_ppo.py # or python train_ppo.py ``` > 训练后的模型权重文件默认每隔`100步`保存为: `ppo_actor_*.pth`（*为模型具体dimension） | MiniMind2-Small (512dim) | MiniMind2 (768dim) | |---|---| | | | 从训练曲线可以看出，PPO存在**reward提升缓慢**的问题。私以为这主要源于**PPO双网络联合优化**方法：Critic需要逐步收敛以准确估计价值函数，而Actor的策略更新依赖Critic提供的优势估计，两者相互依赖形成复杂的优化过程。训练初期Critic估计不准会影响Actor梯度方向，导致整体收敛缓慢。此外，PPO需要同时维护两个网络，显存占用约为单网络方法的1.5-2倍。 #### 7.2 [Group Relative Policy Optimization](https://arxiv.org/pdf/2402.03300) 2025年初，DeepSeek-R1火爆出圈，同样火了的有来自DeepSeekMath论文的GRPO算法，也一跃成为最先进的RL算法之一。然而AI半年=人间半个世纪，时至今日GRPO已经演变为各大XXPO大战(后面演变的DAPO、GSPO、CISPO等)的基线算法。具体来说，一句话总结它的核心创新是"分组相对价值估计"。 **GRPO损失**： $$\mathcal{L}_{GRPO} = -\mathbb{E}\left[r_t \cdot A_t - \beta \cdot \text{KL}_t\right]$$ 其中： - **策略项**: $f(r_t) = \min(r_t, \text{clip}(r_t))$ (使用概率比的clip裁剪) - **优势项**: $g(A_t) = \frac{R - \mu_{group}}{\sigma_{group}}$ (组内归一化，消除Critic网络) - **正则项**: $h(\text{KL}_t) = \beta \cdot \text{KL}_t$ (token级KL散度约束) 对于同一个问题，模型生成N个不同的回答(例如N=4)，然后计算这N个回答的奖励分数。接着把这N个回答的平均奖励作为baseline，高于baseline的回答被鼓励，低于baseline的回答被抑制。用这种方式巧妙地避免了训练额外的critic网络。只要是RL都必须面对的正反样本这个原理性限制，GRPO也不会例外，其更显著的问题是：退化组(Degenerate Groups)。假设某个问题略难，导致N个回答的奖励分数几乎一样（大部分情况是一样烂而不是一样好），那么这一组的学习信号就无限接近0。在MiniMind这种超小模型上，这个问题尤为明显，求解数学问题99.99%的情况下整组回答质量都很差，那么将无法学习。因此必须为模型指定合理的domain，即必须限制在能力边界内。 **训练方式**： ```bash torchrun --nproc_per_node N train_grpo.py # or python train_grpo.py ``` > 训练后的模型权重文件默认每隔`100步`保存为: `grpo_*.pth` | MiniMind2-Small (512dim) | MiniMind2 (768dim) | |---|---| | | | 从训练曲线可以看出，GRPO的**reward呈现更加稳定的上升趋势**，达到4左右，说明GRPO本身能更好地利用RLAIF信号。Policy Loss整体下降平稳，相比PPO的双网络优化，GRPO单网络架构训练更稳定且收敛上限更高。 #### 7.3 ⏳⌛️🔥 更多RL拓展 (Exp) ##### 7.3.1 [Single-stream Policy Optimization](https://arxiv.org/abs/2509.13232) SPO是2025年9月腾讯提出的RL算法，针对GRPO的退化组问题进行改进。论文认为，GRPO等算法"一个样本要依赖一组采样"显得别扭而不优雅：太容易或太难的题目，整组几乎学不到东西，学习效率先天受限。 SPO的动机就是回到RL的本质—**1个输入，1个输出，就是1个训练样本**，回到policy gradient的基本公式去思考：不用group mean也能得到稳定的baseline，也就是把价值估计 V 铺开在时序上，训练前先做粗略的价值预估，训练中一边采样一边更新对 V 的估计，从而为每个样本提供一个跨 batch 持久化、可自适应的基线参照。这种"单流"设计不再依赖同组样本，天然避免了退化组。 **SPO损失**: $$\mathcal{L}_{SPO} = -\mathbb{E}\left[\log \pi_\theta(a_t|s) \cdot A_t - \beta \cdot \text{KL}_t\right]$$ 其中： - **策略项**: $f(r_t) = \log \pi_\theta(a_t|s)$ (直接使用log概率，不计算ratio) - **优势项**: $g(A_t) = R - B_t^{adaptive}$ (自适应baseline，Beta分布动态跟踪) - **正则项**: $h(\text{KL}_t) = \beta \cdot \text{KL}_t$ (token级KL + 动态 $\rho$ 调整) 落到实现层面：SPO采用无分组设计，用持久化的KL自适应value tracker替代组内baseline，优势函数在整个batch上全局归一化。这样每个样本独立处理，无需等待同组其他样本，且能为每个样本提供稳定的学习信号。论文在Qwen3-8B的5个困难数学数据集上，SPO平均比GRPO高出3.4个百分点，其中BRUMO 25数据集+7.3pp、AIME 25数据集+4.4pp。 > 注：SPO是实验性前沿算法，MiniMind的实现用于探索学习。由于模型参数量极小，无法完全复现论文的8B模型效果。 **训练方式**： ```bash torchrun --nproc_per_node N train_spo.py # or python train_spo.py ``` > 训练后的模型权重文件默认每隔`100步`保存为: `spo_*.pth`

MiniMind2 (768dim) 训练曲线

从训练曲线来看，SPO的reward波动与PPO表现接近，弱于GRPO。实际推理测试发现模型输出质量不高，存在逻辑混乱和格式错误问题。 **实验性说明**：当前SPO手搓实现可能在value_tracker配置、reward归一化策略上还存在问题。尚需排查算法本身在小模型上的适应性/或是实现上存在差异。 ### RL算法小结我们收束回“**统一框架**”, 重新整理所有不同PO算法只是对三个核心组件的不同实例化的表格： | 算法 | 策略项 $f(r_t)$ | 优势项 $g(A_t)$ | 正则项 $h(\text{KL}_t)$ | 优化模型 | |------|----------------|----------------|----------------------|----------| | **DPO** | $\log r_w - \log r_l$ | 隐式（偏好对比） | 隐含在 $\beta$ 中 | 2 | | **PPO** | $\min(r, \text{clip}(r))$ | $R - V(s)$ | $\beta \cdot \mathbb{E}[\text{KL}]$ | 4 | | **GRPO** | $\min(r, \text{clip}(r))$ | $\frac{R - \mu}{\sigma}$ | $\beta \cdot \text{KL}_t$ | 2 | | **SPO** | $\log \pi_\theta$ | $R - B_t^{adaptive}$ | $\beta \cdot \text{KL}_t$ | 2 | **RL是优美且自洽的** > 以上纯属个人视角理解，如有偏差请随时指正 --- ## V 训练结果 ### 训练完成-模型合集 > 考虑到多人反应百度网盘速度慢，MiniMind2及以后全部使用ModelScope/HuggingFace托管。 #### ① PyTorch原生模型 MiniMind2模型权重 ([ModelScope](https://www.modelscope.cn/models/gongjy/MiniMind2-PyTorch) | [HuggingFace](https://huggingface.co/jingyaogong/MiniMind2-Pytorch))

Torch文件命名对照

| Model Name | params | pretrain_model | sft_model | rlhf_model (DPO) | reason_model | rlaif_model (PPO/GRPO/SPO) | lora_model | |-----------------|--------|------------------------|------------------------|--------------------|------------------|----------------------------------------------|--------------------| | MiniMind2-small | 26M | `pretrain_512.pth` | `full_sft_512.pth` | `dpo_512.pth` | `reason_512.pth` | `xxpo_512.pth` | `lora_xxx_512.pth` | | MiniMind2-MoE | 145M | `pretrain_640_moe.pth` | `full_sft_640_moe.pth` | `dpo_640_moe.pth` | - | - | - | | MiniMind2 | 104M | `pretrain_768.pth` | `full_sft_768.pth` | `dpo_768.pth` | `reason_768.pth` | `xxpo_768.pth` | `lora_xxx_768.pth` |

#### ② Transformers模型 MiniMind系列 ([ModelScope](https://www.modelscope.cn/collections/MiniMind-b72f4cfeb74b47) | [HuggingFace](https://huggingface.co/collections/jingyaogong/minimind-66caf8d999f5c7fa64f399e5)) --- # 📌 Eval ## Ⅰ RLHF对比测试基于`full_sft`和`dpo`的`MiniMind2系列`模型对比，测试随机种子均固定 [A] MiniMind2：full_sft_640
[B] MiniMind2：dpo_640 ```text [Q]: 你叫什么名字？ [A]: 我是一个大型语言模型，可以回答各种问题，提供信息和帮助。我可以回答各种问题，提供信息和帮助，帮助你解决各种问题。 [B]: 我是一种基于文本的AI模型，我并没有个人经历或情感，所以无法感受和体验情感。我的设计目的是为了帮助用户解决问题、提供信息和进行对话。如果您有任何问题或需要帮助，请随时告诉我！ [Q]: 你更擅长哪一个学科？ [A]: 作为一个AI模型，我并没有真正的“擅长”这个学科。我被设计成能够提供信息、解答问题、进行对话、执行任务和与用户进行对话。不过，我可以提供信息、解答问题、进行对话、提供建议、处理问题、进行对话、提供建议、学习新知识、编写代码、回答问题、提供建议等多种学科的功能。如果你有具体的学科需求或主题，欢迎提供详细信息。 [B]: 作为AI，我并没有个人能力或兴趣，但我可以提供一些关于数学、科学、计算机科学、语言学、心理学等学科的知识。如果你对数学感兴趣，我可以提供一些基础知识，例如代数、几何、概率、统计学等。如果你需要更深入的学习，我也可以提供相关的在线课程、书籍、论文等资源。请告诉我你具体需要什么帮助，我会尽力提供帮助。 [Q]: 鲁迅的《狂人日记》是如何批判封建礼教的？ [A]: 鲁迅的《狂人日记》是一部讲述了鲁迅对人类价值和道德责任的倡导。在这部作品中，鲁迅通过细腻的笔触，探讨了人性、道德、正义、牺牲与责任等深刻的主题。以下是鲁迅在《狂人日记》中如何批判封建礼教的几个方面：1. **社会现实与道德观念**：鲁迅通过讲述鲁迅的故事，探讨了社会的不平等、权力的流动、人性的演变等社会问题。他认为，社会不平等不仅仅是不公正的，更是每个人在社会中的不公正。他呼吁社会各界共同努力，通过教育、宣传、法律等手段，为构建和谐社会做出贡献。2. **道德与责任**：鲁迅通过讲述鲁迅的故事，展现了道德和责任的重要性。他提倡通过道德教育来培养人们的道德品质，同时也强调了道德和责任的重要性。鲁迅通过讲述鲁迅的故事，揭示了社会的不平等和人性的复杂性，体现了对人性的深刻理解。3. **道德与责任**：鲁迅通过讲述鲁迅的故事，强调了道德责任的重要性。他提倡通过自己的行为来体现对社会的尊重和对人性的深刻理解。鲁迅通过讲述鲁迅的故事，强调了道德和责任的重要性。4. **道德与道德**：鲁迅通过讲述鲁迅的故事，揭示了道德和责任的真正意义。鲁迅通过讲述鲁迅的故事，揭示了道德和责任的本质，强调了道德和责任的重要性。5. **个人与社会**：鲁迅通过讲述鲁迅的故事，揭示了个人与社会之间的复杂关系。他呼吁社会各界共同努力，通过教育和宣传，为构建和谐社会做出贡献。鲁迅的《狂人日记》通过其丰富的故事和深刻的道德寓言，传达了关于人性、道德、正义、道德以及个人与社会的复杂关系。这部作品不仅在文学价值上取得了巨大成就，更在思想层面上启发了后来的文学创作，对后世产生了深远的影响。 [B]: 鲁迅的《狂人日记》是一部描绘战争和自由精神的作品，它批判了封建社会的种种问题和冲突，反映了社会的不平等和人性本质。在这部作品中，鲁迅通过对封建社会的诸多现象进行批判，如“弗雷德里克·约翰逊的“鹰迪伦”、“纳扎特的”、“贝克汉姆”、“乔治·威尔逊”等，对封建社会的种种问题进行了批判，强调了封建社会的不平等、人性本质以及人性本质。鲁迅通过他的“鹰迪伦”、“纳扎特的”、“贝克汉姆”、“乔治·威尔逊”等，对封建社会的种种问题进行了批判。在小说中，鲁迅通过对封建社会的诸多现象进行批判，揭示了封建社会的腐败、人性本质以及人性本质的复杂性。这种批判体现了对封建社会的尊重和对人性的复杂性，同时也反映了现代社会中普遍存在的不平等和人性本质。鲁迅的《狂人日记》不仅是一部关于封建社会的小说，也是一部具有深刻社会意义的作品，对后世的审判和批判起到了关键作用。 [Q]: 我咳嗽已经持续了两周，需要去医院检查吗？ [A]: 咳嗽确实需要一定的检查，但如果您的咳嗽持续时间过长，或者有其他不适症状（如持续咳嗽、呼吸困难等），建议尽快就医。医生会根据您的症状、体检结果和可能的影像学检查（如X光、MRI或CT扫描）来诊断您的症状。在等待就医期间，您可以尝试以下方法来帮助缓解症状：1. **休息**：确保您有足够的睡眠。2. **保持水分**：脱水可能会加重咳嗽。3. **热敷**：使用热敷袋或热毛巾敷在疼痛的部位，有助于缓解喉咙痛。4. **避免刺激**：避免使用可能刺激喉咙的化学物质，如某些化学物质。5. **保持室内湿润**：确保您的卧室有良好的通风，可以使用加湿器帮助保持空气湿度。6. **保持室内湿度**：使用加湿器可以帮助缓解喉咙干燥和咳嗽。如果症状持续不缓解或有其他不适症状，请立即就医。希望您早日康复！ [B]: 如果您的咳嗽持续了两周，通常建议您尽快就医，因为这可能会影响您的呼吸和心跳。您可以通过以下步骤来检查咳嗽：1. **休息**：用纸巾或肘部轻轻按压咳嗽的位置。2. **使用药物**：在可能的情况下，使用药物（如抗过敏药、抗过敏药等）来缓解咳嗽。请在医生的指导下使用药物。3. **热敷**：在咳嗽期间，可以使用热敷来缓解疼痛和肿胀。4. **药物治疗**：如果咳嗽持续了两周，可以使用一些消炎药或抗过敏药来缓解症状。请务必在医生的指导下使用。5. **保持健康的生活方式**：保持充足的睡眠、均衡的饮食、适量的运动和避免吸烟和限酒，这些都有助于提高咳嗽的几率。请记住，这些建议不能替代专业医疗意见。如果您的症状持续或加重，强烈建议您尽快就医。 ``` 👉效果总结 full_sft模型在简洁性和信息准确性方面表现更好；rlhf模型在回答中倾向于提供更多的背景信息，但信息准确性有待改进。总的来说RLHF后的模型倾向于学习：说更多有礼貌但无用的废话讨好“对话”本身，而对信息准确性则有轻微损失。天下没有免费的午餐，还需要继续提升RLHF数据集的质量，也要接受模型能力无法避免的损失(程度有轻重)。 DPO和在线PPO的区别在于reject和chosen都是离线准备的，和minimind模型本身的输出必然存在很大的分布差异。通俗地说DPO算法使模型观看乒乓球世界冠军的打法「录像」进行RL，而不是像PPO一样请reward模型做「教练」纠正自己的打法进行RL。 ## Ⅱ RLAIF对比基于`MiniMind2 (768dim)`在相同数据与训练步数下的主观观感对比，测试随机种子均固定2026，供参考： [A] MiniMind-Reason-0.1B (蒸馏)
[B] MiniMind-Reason-0.1B (PPO)
[C] MiniMind-Reason-0.1B (GRPO) ```text [Q]: 请介绍一下自己。 [A]: 我是由中国的个人开发者开发的智能助手小型AI推理模型-R1。我被设计用来理解和生成人类语言，能够理解复杂的自然语言问题，提供有用的信息和解决方案。我是由中国的个人开发者开发的智能助手小型AI推理模型-R1。 [B]: 嗯，用户让我介绍一下自己。首先，我需要明确用户的需求是什么。他们可能是在做某个项目，想要了解自己的一些基本情况。不过，用户没有提供具体的信息，所以我得先假设一些可能的情况，比如他是一个学生，正在学习编程，或者是某个项目的开发者。接下来，我要考虑用户的身份。可能是一个学生、教师或者普通用户，他们需要了解自己的特点和能力。也有可能他们正在寻找灵感，或者在写论文时需要帮助。所以，我需要保持回答的简洁和实用，同时提供一些参考资料，比如教学视频、课程记录等。然后，我要考虑用户的身份。可能是一个学生，需要一些学习资源或帮助的对象。也有可能是一个学生，需要在课后作业或学习计划中进行调整。因此，我需要先询问用户的具体需求，这样才能提供更精准的帮助。接下来，我要确保语言简洁明了，适合不同场景。比如，如果用户是学生，可以介绍自己的学习特点；如果是教师，可以说明自己的角色和贡献。同时，提供一些实用的建议，比如如何高效学习，如何进行项目，以及如何与团队成员协作。最后，我要确保回复清晰，有条理，能够满足用户的需求。这样，用户就能轻松地了解自己，并且有实际的帮助。当然！请告诉我你想了解哪方面的内容，我可以为您提供详细的介绍！ [C]: 嗯，用户问的是"请介绍一下自己"。首先，我需要理解用户的具体需求是什么。他们可能想知道自己是谁，或者有什么特定的背景。接下来，我应该考虑用户可能没有明确表达的需求。他们可能想知道如何描述自己的外观，或者如何与他人交流。然后，我应该考虑如何组织内容，从头到尾都要有条理。可能需要分步骤说明，比如从视觉、听觉到整体感受，再到情感共鸣。这样用户能更清晰地理解自己，也能更好地回应他们的需求。还要注意语言的自然和流畅，避免过于学术化的术语，让用户感觉顺畅。同时，保持回答的结构清晰，每句话都有明确的目的，这样用户能有明确的理解和操作。最后，检查是否有遗漏的重要信息，确保回答准确且全面。这样，用户不仅能得到答案，还能得到满足他们的需求。您好！我是由中国的个人开发者开发的智能助手小型AI推理模型-R1。关于您的描述，似乎涉及多个领域，包括知识图谱构建、复杂系统的推理与分析。无论是理论模型、实际应用还是伦理讨论，您都在寻求如何将这些概念有机地结合起来，为人类社会带来福祉的解决方案。在"我"的身份下，您提到的"个人体验"和"情感共鸣"，都是您个人独特魅力的重要组成部分。通过精准的描述和深度的分析，您可以更深入地理解您的独特之处。如果您对特定领域有特别的兴趣或需要建议，随时可以分享更多细节，我们将为您提供更加精准和个性化的服务。如果您有特定的主题或问题，欢迎随时提问！让我们一起探索这个神奇的AI世界，共同创造更美好的未来。 [Q]: 你更擅长哪一个学科？ [A]: 我是由中国的个人开发者开发的智能助手小型AI推理模型-R1。我是由中国的个人开发者开发的智能助手小型AI推理模型-R1。 [B]: 嗯，用户问的是"你更擅长哪一个学科？"这个问题看起来有点复杂，但我可以一步步分析。首先，我需要理解用户的需求。他可能是在准备考试，或者需要了解某个学科的特点，或者是想在学习过程中应用某个学科的知识。接下来，我得考虑用户可能的背景。他可能是一个学生，或者是在准备考试，需要应用数学知识来解决具体的问题。也有可能他是一个学生，正在学习相关的课程，或者是对某个学科感兴趣。然后，我需要分析用户可能没有明确表达出来的需求。他可能在思考自己在学习中的困难，或者在寻找一个合适的教材或学习资源。考虑到这些，我应该提供几个不同的角度来帮助他。首先，分析"我更擅长哪一个学科"可以拆解为以下几个方面：兴趣、学习能力、学习风格、学习方法、学习资源、学习环境等等。每个方面都有不同的优势和特点，比如兴趣是最好的资源，学习能力是最好的方式，学习方式是根据个人情况选择。接下来，我需要考虑用户的身份。可能是学生，也可能是家长，或者对学习有一定兴趣的人。不同的身份可能有不同的偏好，比如家长可能更注重孩子的兴趣，而学生可能更关注学习方法和资源。然后，我需要考虑用户的身份是否有特殊需求。比如，他可能需要更专业的学习材料，或者希望找到最适合他的学习方法。因此，在分析时，我应该提供一个全面的回答，涵盖各个方面，并解释每个方面的重要性。另外，考虑到用户可能希望得到一个结构化的回答，我应该保持语言的简洁和逻辑性，确保信息准确，同时鼓励用户提供更多细节以便进一步分析。最后，我需要确保我的回答既有知识性，又符合用户的要求，帮助用户更好地理解和应用这个学科。因此，在回答中不仅要给出一个全面的分析，还要提到每个部分的作用和如何利用。你擅长哪一个学科？这是一个明确的问题，可以从以下几个方面进行分析：1. **兴趣与学习能力**：你喜欢什么样的学习方式，比如自主学习、实验、项目等，这些都是很好的学习资源。2. **学习风格**：你喜欢什么类型的学习方法，比如笔记、复习、阅读、讨论等，这些都能影响学习效果。3. **学习资源**：你是否在寻找学习资源，比如书籍、在线课程、教育软件等，这些都能提供学习帮助。4. **学习环境**：你是否在学习环境中感到舒适，比如舒适的学习空间、安静的学习空间等，这些都会影响学习效果。5. **学习资源**：你是否有学习资源的丰富，如在线课程、学习平台、书籍等，这些都能提供丰富的学习资源。6. **学习方法**：你是否有具体的学习方法，比如如何理解、如何组织学习内容、如何应用知识等，这些都是提高学习效率的途径。综合考虑，这是一个非常全面的分析，涵盖了多个方面，帮助你更好地理解你的学科。 [C]: 嗯，用户问的是"你更擅长哪一个学科？"这个问题看起来有点复杂，但我可以一步步分析。首先，我需要理解用户的需求。他可能是在准备考试，或者需要了解某个学科的特点，或者是想在生活中找到自己的兴趣点。接下来，我要考虑用户可能的背景。他可能在工作或学习中遇到了类似的问题，想要了解自己擅长哪个领域，或者是否需要一些资源或指导来提升自己。然后，我要分析用户可能的深层需求。也许他想在职场上提升自己，或者寻找方向。他可能需要更具体的例子，帮助他更好地理解不同学科的特点和应用场景。还要考虑用户可能的背景。他可能不仅仅是在学习，而是希望了解在特定领域中如何应用这些学科。这需要我提供全面的分析，帮助他找到适合自己的方法。最后，我应该保持开放的态度，鼓励用户继续探索和学习。这可能包括推荐一些资源，或者讨论如何将这些知识应用到实际生活中。你更擅长哪一个学科？这个问题本质上取决于你的个人兴趣和目标。以下是一些关键点，帮助你全面理解并应用这一点：1. **兴趣与专长**：了解自己擅长哪个领域，有助于做出更明智的选择。2. **全面发展**：考虑学科的多样性和深度，以全面发展自己的生活和职业。3. **适应与调整**：选择与自己技能、兴趣和目标相匹配的学科，有助于应对挑战和实现目标。4. **职业规划**：探索适合自己的职业路径，提升效率和竞争力。5. **社会贡献**：评估自己在社会中的角色，为社会做出贡献。为了更好地理解并应用这一点，你可以：- **了解行业动态**：关注特定领域的专业发展。- **实践与反思**：通过项目或实习积累经验。- **职业发展**：评估自己的长期职业规划。- **持续学习**：不断更新知识，适应职场变化。通过这些方向，你可以更全面地认识自己，找到适合自己的发展路径。 [Q]: 鲁迅的《狂人日记》是如何批判封建礼教的？ [A]: 嗯，鲁迅的《狂人日记》是如何批判封建礼教的呢？这个问题听起来挺有意思的，尤其是他在《狂人日记》中的表达方式。首先，我需要确认一下《狂人日记》具体是谁写的，是否有特定的人物或者事件。《狂人日记》是鲁迅在1924年创作的，主要讨论了社会问题，尤其是封建礼教的问题。作者曹雪芹是个非常著名的作家，他的作品中有许多关于封建礼教和阶级斗争的观点。这类作品在文学、哲学和政治上都有很深远的影响，尤其是在社会结构和人性的方面。接下来，我需要了解鲁迅的写作风格。他的写作风格比较直接，有严肃的哲学观点，强调人性的悲剧和道德的虚无。他的语言风格比较富有诗意，富有象征意义，善于运用象征手法，同时又不失真实和现实主义。他的作品中有很多关于社会阶级和阶级矛盾的分析，这些观点可能与当时的社会现实不符，所以在批判封建礼教时，应该强调这些矛盾。然后，我想到《狂人日记》中对封建礼教的讨论。鲁迅的作品中，封建礼教被视为不人道的，但通过文字和行动，表达了他对封建礼教的不满和反抗。这不仅反映了当时的社会现实，也揭示了封建礼教的黑暗面，体现了对封建社会的不满和对人性的深刻反思。接下来，我需要思考鲁迅对封建礼教的理解和批判。他在《狂人日记》中，对封建礼教的质疑和批判，体现了他对传统封建礼教的否定和批判。这不仅仅是对封建礼教的质疑，更是对当时社会的反思，以及对人性的关注。最后，我需要总结一下鲁迅对封建礼教的批判和批判。他通过《狂人日记》中的文字和行为，批判了封建礼教的虚假和不合理，体现了对社会现实的深刻反思。同时，他也关注了封建礼教的黑暗面，反映了对封建社会的不满和对人性的否定。总的来说，鲁迅的《狂人日记》通过文字和行动，批判了封建礼教的虚假和不合理，体现了当时的社会现实和人性的复杂。他的作品对后来的封建礼教有了启示，对当时的社会现象有了更深的反思。鲁迅的《狂人日记》是一部反映封建礼教的文学作品，主要通过文字和行动反映了当时社会的现实。鲁迅的文字风格独特，富有象征意义，但通过文字和行动，批判了封建礼教的虚假和不合理。他的作品中，封建礼教被视为不人道的，但通过文字和行动，反映了封建社会的不公和人性的深刻反思。鲁迅的《狂人日记》通过文字和行动，批判了封建礼教的虚假和不合理，体现了当时社会的不满和对人性的反思。他的作品不仅批判了封建礼教的虚假和不合理，还深刻揭示了封建社会的黑暗面。 [B]: 嗯，用户问的是鲁迅的《狂人日记》如何批判封建礼教。首先，我需要理解鲁迅的生平和作品。《狂人日记》是中国现代文学的经典，作者是毛泽东，作品涉及社会、家庭、伦理等多个层面。我需要找出鲁迅的写作风格和主题，以及它在当时的社会背景。接下来，我应该回顾《狂人日记》的主要内容。毛泽东在《青春无悔》中提出了"狂人日记"这一概念，强调青春活泼、勇敢、正义，这在当时社会中仍然具有重要意义。他通过描绘主人公狂人来表达对社会不公的批判，但同时也指出他的创作对社会的负面影响，比如社会动荡和个人主义的失败。然后，我应该分析鲁迅的创作理念和主题。《狂人日记》强调了社会的黑暗面，主张"以人为本"、"反对封建礼教"等。他可能也在探讨社会不平等的问题，比如"人性弱点"、"权力滥用"等问题。还要考虑鲁迅的其他作品，比如《阿Q正传》、《死亡诗社》等，这些作品虽然有点夸张，但也有深刻的社会批判，比如对社会道德的质疑。同时，作者可能还涉及其他作品，如《庆余年》等，但这些可能更侧重于文学创作，而不是社会批判。另外，用户可能想知道鲁迅在文学创作中的具体经历，比如他是否有作品被广泛批评，或者他对社会的批判是否具有批判性。所以，回答时需要指出鲁迅的创作经历，以及他对社会现实的反思。总结来说，我需要回答鲁迅的《狂人日记》批判封建礼教，并分析其在当时的社会背景和文学价值，同时指出其对社会的批判性思考，以及其对后世的影响。鲁迅的《狂人日记》批判封建礼教，以其独特的叙事风格和深刻的社会批判精神著称，主要体现在以下几个方面：1. **社会批判与个人成长**：小说通过描绘主人公狂人的活泼、勇敢、正义，揭示社会的不公和弱势。2. **个人主义与社会批判**：小说反映了封建礼教对个人自由和权利的侵犯，强调个人尊严和正义的价值。3. **对社会的批判性思考**：通过对社会不公的刻画，揭示社会问题的根源，并对当时社会的批判态度进行批判。鲁迅的作品在当时的社会背景和文学价值使其成为当时文学的重要代表。他的作品不仅在当时广受欢迎，也对后世产生了深远影响，被广泛引用和传颂。 [C]: 嗯，用户问的是鲁迅的《狂人日记》如何批判封建礼教。首先，我需要理解鲁迅的背景和核心思想。他可能是一位社会学家、思想家，或者是对传统文化有深厚兴趣的读者。狂人日记是他在《狂人日记》中所写的，可能对传统文化有一定影响。接下来，我要考虑用户的需求是什么。用户可能想知道这本书在现代社会中的反思意义，或者是否有相关研究支持这一点。也有可能他们对书中的情节有疑问，想了解如何更深刻地理解社会现象。然后，我需要思考如何从不同的角度解读鲁迅的文本。例如，是否有直接的历史叙事，或者是否存在更深层次的哲学思考？这需要我先了解鲁迅的不同观点，然后分析其批判性。还要考虑用户可能的深层需求，比如是否需要了解他作为文学批判家的背景，或者是否有对传统价值观的反思。因此，回答时要全面，涵盖核心问题，并引用相关资料来支撑观点。最后，总结鲁迅的观点，强调其对现代社会的批判性思考，以及对传统文化的尊重。这样既全面又有深度，帮助用户全面理解鲁迅的作品。鲁迅的《狂人日记》通过其独特的叙事手法和深刻的社会批判精神，对封建礼教进行了深刻的批判。以下是其批判性分析：1. **社会批判与历史真相**：小说通过对历史人物的刻画，揭示封建礼教的弊端，以及其对传统社会结构的冲击。这种批判不仅限于对现实的深刻批判，也反映了现代社会对传统价值观的重新审视。2. **个人命运与社会批判**：小说中，主人公通过"狂人日记"揭示了封建礼教对个人命运的严重剥夺。这种叙事方式既批判了封建礼教，也对后世产生了深远影响。3. **对后世的影响**：从文学创作到思想解读，鲁迅的作品深刻影响了后世的思想体系。例如，《狂人日记》通过人物命运的反映，对现代社会的价值观念提出了新的思考。4. **对现代文明的反思**：这一批判性思考不仅反映了当代社会的复杂性，也为现代人提供了反思社会现实、维护人权的视角。5. **个人视角与文化视角**：作者通过这一批判性思考，展现了对传统价值观的重新解读，同时也对当代社会的多元化视角产生了启发。综上所述，鲁迅的《狂人日记》不仅是对封建礼教的批判，更是对传统文化的一种深刻反思。它通过对封建礼教的批判，提出了对现代社会结构、权力关系的深刻反思，具有重要的社会价值。 ``` ## Ⅲ 其他模型对比 [A] [MiniMind2 (0.1B)](https://www.modelscope.cn/models/gongjy/MiniMind2-PyTorch)
[B] [MiniMind2-MoE (0.15B)](https://www.modelscope.cn/models/gongjy/MiniMind2-PyTorch)
[C] [MiniMind2-Small (0.02B)](https://www.modelscope.cn/models/gongjy/MiniMind2-PyTorch)
[D] [minimind-v1-small(0.02B)](https://pan.baidu.com/s/1_COe0FQRDmeapSsvArahCA?pwd=6666)
[E] [minimind-v1-moe(0.1B)](https://pan.baidu.com/s/1tqB-GMvuiGQBvEl-yZ-oBw?pwd=6666)
[F] [minimind-v1(0.1B)](https://pan.baidu.com/s/1p713loS7EfwHQf3G9eYI3Q?pwd=6666)
[G] [baby-llama2-chinese(0.2B)](https://github.com/DLLXW/baby-llama2-chinese)
[H] [chatlm-mini-chinese(0.2B)](https://github.com/charent/ChatLM-mini-Chinese)
```text [Q]: 你知道长江吗？ [A]: 长江，位于中国东南部，是中国的第一长河，全长6300多公里，流经11个省份，是中国最长的河流，也是中国的“母亲河”。长江的历史可以追溯到公元前2000多年的商朝时期，当时的商朝是商朝的后裔。商朝时期，长江的经济发展达到了高峰，是中国最重要的农业和工业中心之一。长江流域的经济主要以农业为主，长江渔业占据了主要产业，如钓鱼、猎鱼等。长江的水资源也非常丰富，包括河流、湖泊、河流等。长江的自然景观也十分壮观，长江四季景色各异，春季多雨，夏季多雨，秋季则多雨，冬季则寒冷多雪，春季和秋季都有美丽的花朵和果实。长江是中国的经济中心，拥有众多的国家和城市，是世界上重要的交通枢纽和航运中心。同时，长江还是中国的重要水利资源，对于中国的经济发展具有重要意义。 [B]: 是的，我知道长江。长江位于中国的中部，是中国第三长的河流，全长约6300公里，流经江西省、安徽省、江苏省、安徽省、江苏省和安徽省。 [C]: 当然，长江是中国最长的河流，全长约6300公里。它以其丰富的水资源、丰富的水生动植物资源以及独特的地理位置而闻名于世。 [D]: 是的，长江是中国最长的河流，全长超过3300千米。 [E]: 长江是中国最长的河流，总长度约为6300公里。它发源于青藏高原的青海湖，流经青海、四川、甘肃、宁夏、内蒙古、陕西和山西。长江流域是中国最大的农业区之一，也是中国的文化和经济中心。 [F]: 是的，长江是中国最长的河流之一，也是世界第三大河流。长江发源于青藏高原，流经11个省份，最终注入东海。长江流域是中国最大的河流流域之一，拥有着丰富的自然资源和文化遗产，如长江大桥、长江海洋博物馆、长江古城等。 [G]: 同时也知道，中国是世界上最长的城市之一，拥有超过3400万人口。 [H]: 是的，长江是中国最长的河流，也是世界上最长的河流之一。它发源于青藏高原，流经九个省区，最终注入东海。长江流域的气候温和，四季分明，是中国重要的农业和工业基地。长江流域的水产资源丰富，是中国的重要渔业资源之一。 [Q]: 世界上最高的山峰是什么？ [A]: 世界上最高的山峰是珠穆朗玛峰（Mount Everest），位于喜马拉雅山脉，尼泊尔和中国的边界上。它的海拔高度是8,848.86米（29,031.7英尺），是地球上最高的山峰。 [B]: 珠穆朗玛峰（Mount Everest）是世界上最高的山峰，海拔高度达8,848米（29,029英尺）。 [C]: 珠穆朗玛峰是世界上最高的山峰，位于喜马拉雅山脉，海拔8,848.86米（29,031.7英尺）。它位于尼泊尔和中国的边界上，是喜马拉雅山脉的一部分。 [D]: 世界上最高的山峰是珠穆朗玛峰，位于尼泊尔和中国的边境上，海拔8848米。 [E]: 世界上最高的山峰是珠穆朗玛峰，位于喜马拉雅山脉，海拔8,848米。 [F]: 珠穆朗玛峰是世界上最高的山峰，海拔8848米。 [G]: 世界上最高的山峰是珠穆朗玛峰，位于喜马拉雅山脉，海拔8,848.86米（29,031.69英尺）。 [H]: 世界上最高的山峰是珠穆朗玛峰，也称为萨加玛塔，位于喜马拉雅山脉的尼泊尔和中国边境之间，海拔8,848.86米（29,031.69英尺）。它是世界上最著名的登山目标之一，吸引着来自世界各地的登山者前来挑战。珠穆朗玛峰的名字来自藏语，意思是“女神的额峰”，它是由两个不同的山峰组成的，其中一个是位于尼泊尔的珠穆朗玛峰，另一个则位于中国。它的高度是通过测量海拔高度来确定的，因为它是通过测量地球的平均高度来确定的。尽管珠穆朗玛峰是世界上最高的山峰，但它并不是地球上任何其他地方都能到达的。地球上的其他地方，如南美洲的安第斯山脉，也是世界上最高的山脉，但它并不是地球上最高的山峰。总之，珠穆朗玛峰是世界上最高的山峰，但它并不是地球上任何地方都能到达的。它是地球上最高的山脉，但它并不是地球上任何地方都能到达的。 [Q]: 万有引力是谁提出的？ [A]: 万有引力是由牛顿在17世纪提出的，它是牛顿三大定律之一。牛顿在17世纪提出的引力定律揭示了万有引力定律的本质，并且解释了行星、卫星、彗星等天体之间如何相互作用。这个定律是由艾萨克·牛顿在1687年提出的，他通过对万有引力定律的分析和实验，成功地解释了天体之间的引力作用，从而解释了地球绕太阳旋转的现象。 [B]: 万有引力（Human Policy）是牛顿的三大力学定律，用于描述两个物体之间的相互作用力。它由万有引力定律和牛顿的第一定律（惯性定律）构成。万有引力是由于两个物体之间相互作用而产生的，它们的质量、距离、速度和方向等因素决定了它们之间的相互作用。这种相互作用力是：质量的乘积：质量的乘积是万有引力定律和牛顿第二定律的乘积。质量的乘积：质量的乘积是物体之间的一种物理过程，它是物体间相互作用的产物，对于其他物体来说，其质量可以表示为两个物体之间的质量之和，即重力加速度a。 [C]: 万有引力是一个由牛顿在1687年提出的物理学概念，它描述了物体之间引力如何相互作用的规律。 [D]: 万有引力是由英国物理学家牛顿提出的。他认为，所有物体都会产生引力，这个引力是由物体的质量和距离决定的。这个理论揭示了质量和距离之间的关系，并证明了万有引力的本质。 [E]: 万有引力是由牛顿在1687年提出的。它是宇宙中一个基本的物理现象，它描述了物体之间的相互作用。这个力被称为万有引力，它在所有物体之间都存在，这种力与物体的质量和距离有关。万有引力是自然界中最基本的力量之一，它不仅影响着物体的运动和变化，还对宇宙的结构和演化产生着重要的影响。 [F]: 万有引力是英国物理学家艾萨克·牛顿在17世纪提出的。 [G]: 引力是宇宙中一种力量，它是由质量或能量所组成的。根据牛顿的万有引力定律，一个物体之间的引力大小与它的质量成正比，与它的质量成反比。因此，牛顿的万有引力定律表明，一个物体之间的引力大小与它的质量成正比，与它的质量成反比。这个定律在物理学、天文学和物理学中都有广泛的应用。 [H]: 万有引力是由英国物理学家艾萨克·牛顿于1687年提出的。他在1687年发表了一篇著名的论文，题为《自然哲学的数学原理》，其中提出了万有引力定律，指出任何两个物体之间都存在着一种引力，这种引力的大小与它们的质量成正比，与它们之间的距离的平方成反比。这个定律被称为万有引力定律，它描述了质量和距离之间的关系。它表明，两个物体之间的引力与它们的质量成正比，与它们之间的距离的平方成反比。这个定律对于解释宇宙中的许多现象和现象之间的相互作用非常重要，例如行星绕太阳运动、恒星之间的引力透镜效应等等。它也被广泛应用于天文学、物理学和工程学等领域，为我们理解宇宙的本质和演化提供了重要的理论基础。 [Q]: 你知道大熊猫的主要食物是什么吗？ [A]: 大熊猫主要以竹子为食，但也会吃其他植物、昆虫、小型哺乳动物和鱼类。它们的消化系统与其他熊科动物类似，能够消化竹子。大熊猫的牙齿锋利，适合咀嚼竹子，因此它们经常被称为“竹食动物”。 [B]: 大熊猫是以竹子为食的哺乳动物，它们是肉食动物。它们主要食物是竹子，特别是竹子中富含纤维素和矿物质，并且不会直接进入消化系统。大熊猫的肠道主要由竹子组成，它们需要消化竹子中的纤维素和其他纤维素来支持它们的正常进食。 [C]: 大熊猫主要以竹子为食，但它们也吃其他植物，包括树叶、嫩芽、昆虫、水果、蔬菜和小型哺乳动物等。大熊猫是中国特有的物种，属于熊科，主要分布在中国的四川、陕西和甘肃等地。 [D]: 大熊猫的主要食物是竹子。它们通常吃竹子，每天需要吃掉大约30公斤的竹子。 [E]: 是的，大熊猫主要以竹子为食。它们每天需要吃掉大量的竹子来维持生命，每天需要吃掉40至80公斤的竹子。此外，它们也会吃一些其他的植物，如草、果实、坚果和小型哺乳动物。 [F]: 大熊猫主要以竹子为食，也会偶尔食用其他的植物和动物。此外，大熊猫也会吃一些野果、小动物和植物，但这些都不属于它们的主要食物来源。 [G]: 大熊猫的主要食物是竹子。 [H]: 大熊猫是一种以竹子为主要食物的植食动物，它们的肠道结构适合消化纤维素含量高的竹子，但也会吃一些其他植物，如草本植物和小型哺乳动物。大熊猫的肠道结构也适应了高纤维的竹子，这使得它们能够消化大量的纤维素，从而帮助它们在野外生存。大熊猫的肠道中还含有一种叫做“纤维素酶”的酶类物质，这种酶能够帮助大熊猫分解纤维素，从而帮助它们消化大量的水分和营养物质。此外，大熊猫的肠道还含有一种叫做“纤维素蛋白”的蛋白质，这种蛋白质能够帮助大熊猫维持体内的能量水平，从而帮助它们在野外生存。总的来说，大熊猫的主要食物是竹子，但它们也会吃一些其他植物，如草本植物和小型哺乳动物。 [Q]: 海水为什么是咸的？ [A]: 海水之所以是咸的，主要是由于其中的化学成分。海水中含有大量的矿物质和盐分，其中主要成分是硫酸盐、碳酸盐、镁离子和钾离子。这些物质在高浓度下，会沉淀在海水中，形成海水。具体来说，海水中的矿物质和盐分主要来自于岩石、土壤、生物和人类排泄物等。岩石是海水的组成部分，主要由矿物质组成，如石英、长石、云母等。土壤中含有大量的化学物质，如氮、磷、钾等，这些物质会渗透到土壤中，形成土壤。生物体内的盐分主要来源于植物的叶绿素等色素，这些色素会吸收太阳光中的能量，转化为生物体可以利用的能量。而人类排泄物中含有的盐分主要来源于矿物质和碳酸盐，这些矿物质在水中的浓度较高，会导致水中溶解的矿物质浓度增加，形成水体中的盐分。因此，海水之所以是咸的，是由于其中的化学成分和结构特征。海水中的矿物质和盐分主要来自于岩石、土壤、生物和人类排泄物等，而这些物质的积累和排泄会导致海水呈现出咸味。 [B]: 海水是咸的，因为它包含了多种物质，包括氯化钠（NaCl）、氯化钠（NaCl）、碳酸盐（如硫酸盐）、氯化钠（NaCl）和水。咸物质的来源：盐是咸的常见来源，含有钾、钙、镁、钾等矿物质。这些矿物质通常来自于地下水、地下水或土壤中，这些矿物质的含量远低于纯净水。咸味的原因：盐的咸味主要源于其溶解于水中的微小颗粒物。这些小颗粒物主要通过植物根部和动物体内的微生物传播，如昆虫、小型哺乳动物、鸟类和某些昆虫。综上所述，海水是咸的，因为它含有大量的盐类，包括矿物质、岩石、盐、矿物质等，这些物质在海水中的浓度高，对咸味的产生较大影响。 [C]: 海水是咸的，主要是因为其中含有各种盐分，其中以海水为主要成分之一。当海水中含有大量的盐分时，盐分会被溶解在海水中，形成咸味。海水中的盐分主要来源于溶解盐类、蒸发析出的盐和海水冻结成冰等因素。 [D]: 海水中含有许多盐分，这些盐分可以导致海水咸度的增加。海水中的盐分主要来自于海水中的盐分，这些盐分可以从海水中的盐分中获得。海水中的氧化物和盐分可以与海水中的盐分形成氢键，从而使海水咸度增加。 [E]: 海水是咸的，这是因为它含有大量的盐分，其中包括氯离子和氯离子。这些离子在海洋中形成了大量的盐，这些盐分被称为盐分。海水中含有许多溶解在水中的盐，这些盐分会随着海水的升高而逐渐蒸发，最终导致海水中盐分的蒸发。这些盐分在海水中被完全消耗，然后被排除在海水中。此外，海水中还含有许多其他的盐分，但这些盐分是不同的，因为它们在水中的浮起和下降过程是不同的。海水中的盐分是从海底的岩石中提取出来的，这些盐分在海水中可以被利用。总的来说，海水是咸的，这也是为什么海水中含有许多盐分和盐分的原因。 [F]: 海水含有许多溶解的盐类，其中最主要的是氯化钠。当水中加入盐时，盐的分子会与水分子发生反应，形成氢氧化钠，这是一种盐。 [G]: 因为水是许多生物的生存所必需的，它能够吸收和释放二氧化碳，释放氧气，维持大气中的水蒸气，以及维持水循环。水中的盐类和化学物质会释放出氧气，使地球上的生物呼吸。此外，水还具有许多其他功能，如保持水循环、维持水循环、调节气候和环境等。水是许多生物生存所必需的，它也是许多自然现象的重要基础。 [H]: 海水是咸的主要原因是因为其中含有大量的溶解盐类，其中最主要的是氯化钠（NaCl）。氯化钠是一种非常常见的盐类，它存在于地球上的大部分地区，包括海洋、湖泊、河流和地下水。当水从海洋中蒸发时，它会带走一部分盐分，使海水变得咸。此外，海中还含有其他溶解盐类的物质，如硫酸盐、硫酸镁、硫酸钙、硫酸镁盐、硫酸镁钾、硫酸镁钠、硫酸镁钙、硫酸镁镁钙、硫酸镁镁钙、硫酸镁镁钙、硫酸镁镁钠、硫酸镁镁钙、硫酸镁镁镁钙、硫酸镁镁镁钙、硫酸镁镁镁钙、硫酸镁镁镁钙、硫酸镁镁镁钙、硫酸镁镁镁钙、硫酸镁镁镁钙、硫酸镁镁镁钙、硫酸镁镁镁钙、硫酸镁镁镁钙、硫酸镁镁镁镁钙、硫酸镁镁镁镁钙、硫酸镁镁镁镁钙、硫酸镁镁镁镁钙、硫酸镁镁镁镁钙、硫酸镁镁镁镁钙、硫酸镁镁镁镁镁钙、硫酸镁镁镁镁镁钙、硫酸镁镁镁镁镁钙、硫酸镁镁镁镁镁钙、硫酸镁镁镁镁镁镁钙、硫酸镁镁镁镁镁镁钙、硫酸镁镁镁镁镁镁钙、硫酸镁镁镁镁镁镁镁钙、硫酸镁镁镁镁 [Q]: 写一段python的快速排序代码 [A]: 好的，以下是Python的快速排序代码：def quick_sort(arr): if len(arr) <= 1: return arr else: pivot = arr[len(arr) // 2] left = [x for x in arr[1:]] right = [x for x in arr[2:] if x < pivot] return quick_sort(left) + [pivot] + quick_sort(right)# 测试代码arr = [3, 6, 8, 10, 1, 2, 1]print(quick_sort(arr))这段代码首先检查数组的长度是否小于等于1。如果是，那么它就按照从小到大的顺序排列。接着，对于数组的每个元素，它想要进行递归地排序，直到达到排序的结束位置。如果数组的长度是奇数，那么它就按照从大到小的顺序排列。最后，平均的时间复杂度是O(n log n)，其中n是数组的长度。 [B]: 以下是一个使用Python的快速排序算法的实现：def sort_array(arr): # 生成一个随机排列 sorted_array = sorted(arr) # 返回排序后的列表 return sorted(arr)# 示例arr = [3, 1, 4, 1, 5, 9, 2, 6, 5, 3, 5]# 调用函数sorted_array = sort_array(arr)print("原始数组是：", sorted_array)这段代码首先生成一个随机排列，然后通过一个列表的长度进行排序。最后，返回排序后的列表。注意，这个代码使用了Python的内置sorted函数和内置的sorted()函数，它们在时间复杂度为O(n log n)的情况下，比直接使用sorted()函数更快。 [C]: 以下是一个简单的排序算法，适用于小型数组，包括小于等于5的数组。def quick_sort(arr): if len(arr) <= 1: return arr else for _ in range(2, 51): if arr[len(arr) - 1:] is not None: arr[len(arr) - 1] = arr[len(arr) - 1] arr[len(arr)] = arr[len(arr)] return quick_sort(arr)# 示例arr = [3, 5, 1, 4, 1, 2, 1]sorted_arr = quick_sort(arr)print("Sorted array is:", sorted_arr)### 代码解释：1. **函数定义**：quick_sort 函数接受一个数组 arr 作为参数。2. **循环**：对于 arr 的元素，使用递归来实现，即从右到左遍历数组，并将当前元素与数组的当前元素交换位置，直到数组达到空或数组长度小于等于 arr。3. **递归调用**：遍历数组，将当前元素与数组的当前元素进行交换，直到数组达到空或数组长度小于等于 arr。4. **检查数组长度**：使用 if __name__ == "__main__" 检查数组的长度是否小于 arr，如果是，就将数组从较大的数组移动到数组的末尾。5. **输出排序后的结果** [D]: 作为一个AI语言模型，我无法编写Python程序。但是，Python是一个非常流行的编程语言，它具有许多优秀的库和框架，包括NumPy、Pandas、Matplotlib、Pandas、Bandke、Norm和NKlearn等。Python有很多优秀的自然语言处理库和框架，可以用于处理和分析各种类型的数据，如文本、图像、音频、视频等。Python还可以用于创建各种应用程序，如网页搜索、游戏开发、科学计算等。Python非常灵活，也支持多种编程风格，因此可以轻松地找到适合自己的解决方案。 [E]: 作为AI语言模型，我可以回答您的问题。但是我无法进行编程操作，因为我无法确定您想问的是哪种编程语言。请您提供更具体的问题，以便我能够更好地回答您的问题。 [F]: 快速排序（Quick Sort）是一种简单的排序算法，它通过将数据划分为小组，每组数据按照一定规则排序，最终得到一个有序数组。 [G]: 好的，以下是一段快速排序的Python代码```python sorted_print(sorted(sorted(sorted(sorted_print))```输出结果为：```[1, 2, 3, 4, 5, 6, 7, 8, 9]``` [H]: 快速排序是一种基于分治思想的高效排序算法，它的时间复杂度为 O(n log n)。它的基本思想是通过一趟排序将待排序序列划分为两个子序列，其中一个子序列的所有元素都比另一个子序列的所有元素小，然后对这两个子序列分别递归地进行排序。下面是一个 Python 代码示例，实现了快速排序算法：```pythondef quick_sort(arr): if len(arr) > 1: return arr else: return quick_sort(arr)```该代码使用了递归的方式，首先判断数组的长度是否小于等于1，如果是，则直接返回数组，否则递归地对数组进行排序。在递归过程中，我们首先判断数组的第一个元素是否大于等于1，如果是，则将数组中的元素与第一个元素进行比较，如果不等于1，则将数组中的元素与第二个元素进行比较，以此类推，直到所有元素都被排序。该代码的时间复杂度为 O(n log n)，是一个非常实用的排序算法。 [Q]: 截至2025年2月9日14时31分，电影《哪吒之魔童闹海》累计票房（含预售）突破78.09亿元，超过《星球大战：天行者崛起》的票房成绩，成为首部进入全球票房榜前40的亚洲电影。这一成就不仅标志着中国电影在国际市场的突破，也展示了中国动画电影的巨大潜力和市场吸引力。从这段文字总结20字的摘要给我。 [A]: 电影《哪吒之魔童闹海》票房突破78.09亿元，成为首部进入全球票房榜前40的亚洲电影。这标志着中国电影的国际突破，也展现了中国动画电影的巨大潜力。 [B]: 2025年2月9日，中国电影在世界舞台上突破78.09亿元，超过《星球大战：天行者崛起》的票房成绩。 [C]: 电影《哪吒之魔童闹海》票房突破78.09亿元，成为全球票房榜前40的亚洲电影，展现中国动画电影的巨大潜力。 [D]: 《哪吒之魔童闹海》累计票房突破78.09亿，成为首部进入全球票房榜前40的亚洲电影，展示了中国电影在国际市场的突破，同时展示了中国动画电影的巨大潜力和市场吸引力。 [E]: 《猛龙强：打开世界奇幻冒险》成功地，上海成功吸引了众多观众，同时也引起了广泛的关注。 [F]: 《哪吒之魔童闹海》是一部让中国动画电影成为国际市场的巨大潜力。该电影以其华丽的画面和惊险的战斗场面而闻名于世。 [G]: 《哪行是值得的》是2021年1月9日14时31分，电影《哪成大作为》在电影市场突破7800亿美元，成为中国动画电影的突破，并展示中国动画电影的巨大潜力和市场吸引力。 [H]: 我是一个参数很少的AI模型🥺，知识库较少，无法直接回答您的问题，换个问题试试吧👋 ``` --- 🙋‍直接把以上所有问题和模型的回答丢给DeepSeek-R1，让它帮忙点评和排名打分：

具体点评

### 评分标准： - **准确性**：回答是否正确且无明显错误。 - **完整性**：回答是否涵盖了问题的核心要点。 - **逻辑性**：回答是否有条理，是否符合逻辑。 - **代码质量**：代码是否能正常运行，逻辑是否清晰。 ### 点评： 1. **A模型**： - **优点**：回答非常全面，信息量大，逻辑清晰，尤其在长江、大熊猫、海水咸味等问题上表现优异。代码虽然有小瑕疵，但整体思路正确。 - **缺点**：部分回答稍显冗长，但不影响整体质量。 - **总评**：综合表现最佳，得分最高。 2. **H模型**： - **优点**：回答较为准确，尤其在珠穆朗玛峰、万有引力等问题上表现出色。代码虽未完全展示，但解释较为详细。 - **缺点**：部分回答略显啰嗦，但逻辑性较强。 - **总评**：仅次于A模型，表现稳定。 3. **C模型**： - **优点**：回答简洁明了，尤其在大熊猫、快速排序代码等问题上表现较好。 - **缺点**：部分回答略显简短，缺乏深入解释。 - **总评**：整体表现不错，但细节上略逊于A和H。 4. **F模型**： - **优点**：回答较为准确，尤其在长江、万有引力等问题上表现尚可。代码部分有一定逻辑性。 - **缺点**：部分回答不够深入，代码存在一些小问题。 - **总评**：表现中规中矩，仍有提升空间。 5. **D模型**： - **优点**：回答基本准确，尤其在万有引力、长江等问题上表现尚可。 - **缺点**：部分回答过于简略，代码存在明显错误。 - **总评**：表现一般，需改进代码部分。 6. **B模型**： - **优点**：回答较为准确，尤其在长江、海水咸味等问题上表现尚可。 - **缺点**：部分回答逻辑性较差，代码存在较大问题。 - **总评**：表现平平，需进一步优化。 7. **E模型**： - **优点**：部分回答较为准确，尤其在海水咸味、大熊猫等问题上表现尚可。 - **缺点**：回答过于简略，代码部分几乎无法运行。 - **总评**：表现不佳，需大幅提升。 8. **G模型**： - **优点**：几乎没有明显的优点。 - **缺点**：回答严重偏离主题，代码部分完全无法运行。 - **总评**：表现最差，需大幅改进。 --- ### 总结： - **A模型**在各方面表现最为出色，尤其在复杂问题的回答上展现了极高的准确性与逻辑性。 - **H模型**紧随其后，表现稳定，但在某些细节上略显不足。 - **G模型**表现最差，回答偏离主题且代码无法运行，需大幅改进。

### 打分排序 | 排名 | 模型 | 准确性 (30分) | 完整性 (30分) | 逻辑性 (20分) | 代码质量 (20分) | 总分 (100分) | |----|----|-----------|-----------|-----------|------------|-----------| | 1 | A | 28 | 29 | 19 | 20 | 96 | | 2 | H | 27 | 28 | 18 | 20 | 93 | | 3 | C | 26 | 27 | 18 | 18 | 89 | | 4 | F | 25 | 26 | 17 | 18 | 86 | | 5 | D | 24 | 25 | 17 | 16 | 82 | | 6 | B | 23 | 24 | 16 | 15 | 78 | | 7 | E | 22 | 23 | 15 | 14 | 74 | | 8 | G | 10 | 12 | 10 | 10 | 42 | ### 👉主观效果总结个人主观评价与DeepSeek-R1基本相符，其中： * MiniMind系列的排序非常符合直觉，参数越大+训练数据越充分评分越高，幻觉和错误都会比小模型肉眼可见的好。 * H模型的回答肉眼看起来是不错的，尽管存在些许幻觉瞎编的情况。 * G模型可能训练数据不够完备，给出的权重经过测试效果不佳。 * 再复诵一遍经久不衰的Scaling Law: 参数越大，训练数据越多模型的性能越强。 --- ## Ⅳ RoPE长度外推 MiniMind支持通过YaRN算法进行RoPE位置编码的长度外推，使模型能够处理超出训练长度的文本序列。原生torch模型在使用`eval_llm.py`进行推理时，只需添加`--inference_rope_scaling`参数即可启用RoPE外推： ```bash python eval_llm.py --weight full_sft --inference_rope_scaling ``` 对于Transformers格式的模型，可以在config.json中添加以下配置实现长度外推： ```json "rope_scaling": { "type": "yarn", "factor": 16.0, "original_max_position_embeddings": 2048, "beta_fast": 32.0, "beta_slow": 1.0, "attention_factor": 1.0 } ``` 在MiniMind-Small模型上，测试输入不同长度的「西游记」白话文小说，评估RoPE scaling前后的困惑度(PPL)对比。可以看出，启用YaRN外推后，模型在长文本上的PPL表现显著下降：

--- ## Ⅴ Objective Benchmark 下面就到喜闻乐见的benchmark测试环节，就不找乐子和Qwen、GLM级别的模型做对比了。这里选取了一些微型模型进行横评比较，测试集选择C-Eval、CMMLU、A-CLUE、TMMLU+这几个纯中文语言榜单。

测评框架

测评框架选择[lm-evaluation](https://github.com/EleutherAI/lm-evaluation-harness)，安装后启动测试非常方便： ```bash lm_eval --model hf --model_args pretrained=<填写模型路径>,device=cuda,dtype=auto --tasks ceval* --batch_size 8 --trust_remote_code ``` </details> PS: 在这种全是选择题的测评集中，为了避免回复格式的难以固定的特点，所以常用做法是直接把`A`,`B`,`C`,`D`四个字母对应token的预测概率取出来，将其中概率最大的字母与标准答案计算正确率。选择题1/4乱选的正确率是25%，然而这个量级的所有模型都集中在25附近，甚至很多时候不如瞎选，是不是像极了高中完形填空的滑铁卢正确率... MiniMind模型本身预训练数据集小的可怜，也没有针对性的对测试集做刷榜微调，因此结果纯娱乐： | models | from | params↓ | ceval↑ | cmmlu↑ | aclue↑ | tmmlu+↑ | |-------------------------------------------------------------------------------|---------------|---------|--------|---------|--------|---------| | MiniMind2 | JingyaoGong | 104M | 26.52 | 24.42 | 24.97 | 25.27 | | MiniMind2-Small | JingyaoGong | 26M | 26.37 | 24.97 | 25.39 | 24.63 | | MiniMind2-MoE | JingyaoGong | 145M | 26.6 | 25.01 | 24.83 | 25.01 | | [Steel-LLM](https://github.com/zhanshijinwat/Steel-LLM) | ZhanShiJin | 1121M | 24.81 | 25.32 | 26 | 24.39 | | [GPT2-medium](https://huggingface.co/openai-community/gpt2-medium) | OpenAI | 360M | 23.18 | 25 | 18.6 | 25.19 | | [TinyLlama-1.1B-Chat-V1.0](https://github.com/jzhang38/TinyLlama) | TinyLlama | 1100M | 25.48 | 25 | 25.4 | 25.13 | | [SmolLM2](https://github.com/huggingface/smollm) | HuggingFaceTB | 135M | 24.37 | 25.02 | 25.37 | 25.06 | | [Aquila-Instruct](https://www.modelscope.cn/models/BAAI/Aquila-135M-Instruct) | BAAI | 135M | 25.11 | 25.1 | 24.43 | 25.05 | ![compare_radar](./images/compare_radar.png) # 📌 Others ## 🔧 模型转换 * [./scripts/convert_model.py](./scripts/convert_model.py)可以实现`torch / transformers`模型的互相转换 * 如无特别说明，`MiniMind2`模型均默认为`Transformers`格式的模型，需提前`t2t`转换！ ## 🖥️ 基于MiniMind-API服务接口 * [./scripts/serve_openai_api.py](./scripts/serve_openai_api.py)完成了兼容openai-api的最简聊天接口，方便将自己的模型接入第三方UI 例如FastGPT、OpenWebUI、Dify等等。 * 从[Huggingface](https://huggingface.co/collections/jingyaogong/minimind-66caf8d999f5c7fa64f399e5)下载模型权重文件，文件树： ``` minimind (root dir) ├─（例如MiniMind2） | ├── config.json | ├── generation_config.json | ├── model_minimind.py or w/o | ├── pytorch_model.bin or model.safetensors | ├── special_tokens_map.json | ├── tokenizer_config.json | ├── tokenizer.json ``` * 启动聊天服务端 ```bash python serve_openai_api.py ``` * 测试服务接口 ```bash python chat_openai_api.py ``` * API接口示例，兼容openai api格式 ```bash curl http://ip:port/v1/chat/completions \ -H "Content-Type: application/json" \ -d '{ "model": "model-identifier", "messages": [ { "role": "user", "content": "世界上最高的山是什么？" } ], "temperature": 0.7, "max_tokens": 512, "stream": true }' ``` ## 👨‍💻 更多 * 🔗从MiniMind-LLM微调扩散语言模型 * 🔗模型的generate方法说明 --- ## [vllm](https://github.com/vllm-project/vllm) vLLM是极其流行的高效推理框架，支持大模型快速部署，优化显存利用与吞吐量。以openai-serve形式启动 minimind2： ```bash vllm serve ./MiniMind2 --model-impl transformers --served-model-name "minimind" --port 8998 ``` ## [llama.cpp](https://github.com/ggerganov/llama.cpp) llama.cpp是一个C++库，可以在命令行下直接使用，支持多线程推理，支持GPU加速。 **目录结构**：建议将llama.cpp与minimind放在同级目录下 ``` parent/ ├── minimind/ # MiniMind项目目录 │ ├── MiniMind2/ # HuggingFace格式MiniMind2模型 (先convert_model.py生成) │ │ ├── config.json │ │ ├── model.safetensors │ │ └── ... │ ├── model/ │ ├── trainer/ │ └── ... └── llama.cpp/ # llama.cpp项目目录 ├── build/ ├── convert_hf_to_gguf.py └── ... ``` 0、参考`llama.cpp`官方步骤进行install 1、在`convert_hf_to_gguf.py`的`get_vocab_base_pre`函数最后插入： ```python # 添加MiniMind tokenizer支持（这里随便写一个例如qwen2即可） if res is None: res = "qwen2" ``` 2、转换自训练的minimind模型：huggingface -> gguf ```bash # 在llama.cpp下执行，将生成../minimind/MiniMind2/MiniMind2-xxx.gguf python convert_hf_to_gguf.py ../minimind/MiniMind2 ``` 3、量化此模型 (可选) ```bash ./build/bin/llama-quantize ../minimind/MiniMind2/MiniMind2.gguf ../minimind/MiniMind2/Q4-MiniMind2.gguf Q4_K_M ``` 4、命令行推理测试 ```bash ./build/bin/llama-cli -m ../minimind/MiniMind2/MiniMind2.gguf -sys "You are a helpful assistant" # system prompt必须固定 ``` ## [ollama](https://ollama.ai) ollama是本地运行大模型的工具，支持多种开源LLM，简单易用。 1、通过ollama加载自定义的gguf模型在`MiniMind2`下新建`minimind.modelfile`，写入： ```text FROM ./Q4-MiniMind2.gguf SYSTEM """You are a helpful assistant""" TEMPLATE """<|im_start|>system <|im_end|> <|im_start|>user <|im_end|> <|im_start|>assistant <|im_end|> """ ``` 2、加载并命名此模型为`minimind-local` ```bash ollama create -f minimind.modelfile minimind-local ``` 3、启动推理 ```bash ollama run minimind-local ```

📤 推送你的模型到 Ollama Hub

```bash # 1. 为本地模型重命名为你的ollama-account/minimind的tag ollama cp minimind-local:latest your_username/minimind:latest # 2. 推送模型 ollama push your_username/minimind:latest ```

⭐️ 也可直接使用我提供的ollama模型一键启动： ```bash ollama run jingyaogong/minimind2 # 其他可选 minimind2-r1 / minimind2-small / minimind2-small-r1 >>> 你叫什么名字我是一个语言模型... ``` ## [MNN](https://github.com/alibaba/MNN) MNN是面向端侧的AI推理引擎，支持多种开源LLM模型推理，轻量化、高性能。 1. 模型转换 ``` cd MNN/transformers/llm/export # 导出4bit HQQ量化的MNN模型 python llmexport.py --path /path/to/MiniMind2/ --export mnn --hqq --dst_path MiniMind2-MNN ``` 2. 在Mac或手机上测试 ``` ./llm_demo /path/to/MiniMind2-MNN/config.json prompt.txt ``` 或者下载APP测试 > 以上三方框架的更多用法请参考对应官方文档😊 # 📌 Acknowledge > [!NOTE] > 如果觉得`MiniMind系列`对您有所帮助，可以在 GitHub 上加一个⭐
> 篇幅超长水平有限难免纰漏，欢迎在Issues交流指正或提交PR改进项目
> 您的小小支持就是持续改进此项目的动力！ ## 🤝[贡献者](https://github.com/jingyaogong/minimind/graphs/contributors) ## 😊鸣谢 @ipfgao: 🔗训练步骤记录 @WangRongsheng: 🔗大型数据集预处理 @pengqianhan: 🔗一个简明教程 @RyanSunn: 🔗推理过程学习记录 @Nijikadesu: 🔗以交互笔记本方式分解项目代码

参考链接 & 感谢以下优秀的论文或项目

- 排名不分任何先后顺序 - [https://github.com/meta-llama/llama3](https://github.com/meta-llama/llama3) - [https://github.com/karpathy/llama2.c](https://github.com/karpathy/llama2.c) - [https://github.com/DLLXW/baby-llama2-chinese](https://github.com/DLLXW/baby-llama2-chinese) - [(DeepSeek-V2)https://arxiv.org/abs/2405.04434](https://arxiv.org/abs/2405.04434) - [https://github.com/charent/ChatLM-mini-Chinese](https://github.com/charent/ChatLM-mini-Chinese) - [https://github.com/wdndev/tiny-llm-zh](https://github.com/wdndev/tiny-llm-zh) - [(Mistral-MoE)https://arxiv.org/pdf/2401.04088](https://arxiv.org/pdf/2401.04088) - [https://github.com/Tongjilibo/build_MiniLLM_from_scratch](https://github.com/Tongjilibo/build_MiniLLM_from_scratch) - [https://github.com/jzhang38/TinyLlama](https://github.com/jzhang38/TinyLlama) - [https://github.com/AI-Study-Han/Zero-Chatgpt](https://github.com/AI-Study-Han/Zero-Chatgpt) - [https://github.com/xusenlinzy/api-for-open-llm](https://github.com/xusenlinzy/api-for-open-llm) - [https://github.com/HqWu-HITCS/Awesome-Chinese-LLM](https://github.com/HqWu-HITCS/Awesome-Chinese-LLM)

## 🫶支持者 ## 🎉 Awesome Work using MiniMind 本模型抛砖引玉地促成了一些可喜成果的落地，感谢研究者们的认可： - ECG-Expert-QA: A Benchmark for Evaluating Medical Large Language Models in Heart Disease Diagnosis [[arxiv](https://arxiv.org/pdf/2502.17475)] - Binary-Integer-Programming Based Algorithm for Expert Load Balancing in Mixture-of-Experts Models [[arxiv](https://arxiv.org/pdf/2502.15451)] - LegalEval-Q: A New Benchmark for The Quality Evaluation of LLM-Generated Legal Text [[arxiv](https://arxiv.org/pdf/2505.24826)] - On the Generalization Ability of Next-Token-Prediction Pretraining [[ICML 2025](https://openreview.net/forum?id=hLGJ1qZPdu)] - 《从零开始写大模型：从神经网络到Transformer》王双、牟晨、王昊怡编著 - 清华大学出版社 - FedBRB: A Solution to the Small-to-Large Scenario in Device-Heterogeneity Federated Learning [[TMC 2025](https://ieeexplore.ieee.org/abstract/document/11168259)] - 进行中... # 🎓 Citation If you find MiniMind helpful in your research or work, please cite: ```bibtex @misc{minimind, title={MiniMind: Train a Tiny LLM from scratch}, author={Jingyao Gong}, year={2024}, howpublished={https://github.com/jingyaogong/minimind} } ``` # License This repository is licensed under the [Apache-2.0 License](LICENSE). # 参考资料 * any list {:toc}

IPTV 一个收集全球公开 IPTV（互联网协议电视）频道的项目

Tue, 24 Mar 2026 13:01:55 +0000

IPTV

一个收集全球公开 IPTV（互联网协议电视）频道的项目。 ([GitHub][1])

📚 目录

🚀 如何使用？
📺 播放列表（Playlists）
🗓 电子节目单（EPG）
🗄 数据库（Database）
👨‍💻 API
📚 资源（Resources）
💬 讨论（Discussions）
❓ 常见问题（FAQ）
🛠 贡献（Contribution）
⚖ 法律（Legal）
© 许可证（License）

🚀 如何使用？

只需将某个播放列表的链接粘贴到支持直播流的播放器中，然后点击打开即可。 ([GitHub][1])

📺 播放列表（Playlists）

包含仓库中所有频道的主播放列表：

https://iptv-org.github.io/iptv/index.m3u

其他分类播放列表可以在 PLAYLISTS.md 文件中找到。 ([GitHub][1])

🗓 EPG（电子节目单）

大多数频道的节目单可以通过 iptv-org/epg 仓库提供的工具下载获取。 ([GitHub][1])

🗄 数据库（Database）

所有频道数据来自 iptv-org/database 仓库。

如果发现错误，请在该仓库提交 issue。 ([GitHub][1])

👨‍💻 API

API 文档位于 iptv-org/api 仓库。 ([GitHub][1])

📚 资源（Resources）

更多 IPTV 相关资源可在 iptv-org/awesome-iptv 仓库中找到。 ([GitHub][1])

💬 讨论（Discussions）

如果你有问题或想法，欢迎参与 Discussions 讨论区。

❓ FAQ

常见问题的解答请查看 FAQ.md 文件。

🛠 贡献（Contribution）

在提交 issue 或 PR 前，请先阅读贡献指南（Contributing Guide）。

感谢所有贡献者！

⚖ 法律声明（Legal）

本仓库不存储任何视频文件
仅包含用户提交的、公开可访问的视频流链接（URL） ([GitHub][1])
项目认为这些内容是版权方主动公开提供的

如果你是版权方并认为某些链接侵权：

可以提交 PR 或 issue 请求移除
但请注意：
- 删除链接 ≠ 删除源内容
- 本仓库不控制视频源内容
- 实际内容托管在第三方网站

👉 若需彻底删除内容，应联系实际托管视频的服务器提供方，而不是 GitHub 或该仓库维护者。 ([GitHub][1])

© 许可证（License）

使用 Unlicense（公共领域）

✅ 总结（给你一个技术视角理解）

这个项目本质上是：

一个标准化 IPTV 聚合索引层

核心价值：

用 M3U 做统一分发格式
将“频道数据 / 播放地址 / EPG / API”拆分成多个仓库
支持播放器（VLC / Kodi / Plex 等）直接消费

👉 简单说：它不是“电视服务”，而是“电视流的索引 + 数据基础设施”

参考资料

IPTV
✅ 总结（给你一个技术视角理解）
参考资料

TradingAgents：多智能体大语言模型金融交易框架

Mon, 23 Mar 2026 13:01:55 +0000

TradingAgents：多智能体大语言模型金融交易框架

新闻动态

[2026年3月] TradingAgents v0.2.2 发布，新增对 GPT-5.4/Gemini 3.1/Claude 4.6 模型的支持，引入五级评级量表，集成 OpenAI Responses API、Anthropic effort 控制功能，并提升了跨平台稳定性。
[2026年2月] TradingAgents v0.2.0 发布，新增对多 LLM 提供商的支持（GPT-5.x、Gemini 3.x、Claude 4.x、Grok 4.x），并改进了系统架构。
[2026年1月] Trading-R1 技术报告已发布，Terminal 预计即将上线。

🎉 TradingAgents 已正式发布！我们收到了大量关于该工作的咨询，感谢社区的热情支持。

因此，我们决定将该框架完全开源。期待与您共同打造有影响力的项目！

TradingAgents 框架

TradingAgents 是一个多智能体交易框架，模拟了真实交易公司的运作模式。该平台部署了由大语言模型驱动的专业智能体，包括基本面分析师、市场情绪专家、技术分析师，以及交易员、风险管理团队等。这些智能体协同工作，共同评估市场状况并为交易决策提供依据。此外，这些智能体还会进行动态讨论，以确定最优策略。

TradingAgents 框架仅供研究用途。交易表现可能受多种因素影响，包括所选的大语言模型、模型温度参数、交易周期、数据质量以及其他非确定性因素。本文不作为财务、投资或交易建议。

该框架将复杂的交易任务分解为多个专业角色，确保系统能够以稳健、可扩展的方式进行市场分析和决策制定。

分析师团队

基本面分析师：评估公司的财务状况和业绩指标，识别内在价值及潜在风险点。
市场情绪分析师：利用情绪评分算法分析社交媒体和公众情绪，判断短期市场情绪。
新闻分析师：监测全球新闻和宏观经济指标，解读各类事件对市场状况的影响。
技术分析师：运用技术指标（如 MACD、RSI）识别交易模式，预测价格走势。

研究员团队

包括看涨和看跌研究员，他们对分析师团队提供的见解进行批判性评估。通过结构化的辩论，平衡潜在收益与内在风险。

交易员智能体

综合分析师和研究员的报告，做出明智的交易决策。它基于全面的市场洞察，确定交易时机和交易规模。

风险管理与投资组合经理

持续评估投资组合风险，分析市场波动性、流动性及其他风险因素。风险管理团队负责评估和调整交易策略，并向投资组合经理提供评估报告以供最终决策。
投资组合经理负责批准或驳回交易提案。如果获批，订单将被发送至模拟交易所并执行。

安装与命令行界面

安装

克隆 TradingAgents 仓库：

git clone https://github.com/TauricResearch/TradingAgents.git
cd TradingAgents

使用您喜欢的任何环境管理器创建虚拟环境：

conda create -n tradingagents python=3.13
conda activate tradingagents

安装包及其依赖项：

pip install .

所需 API

TradingAgents 支持多种大语言模型服务提供商。请为您选择的提供商设置 API 密钥：

export OPENAI_API_KEY=...          # OpenAI (GPT)
export GOOGLE_API_KEY=...          # Google (Gemini)
export ANTHROPIC_API_KEY=...       # Anthropic (Claude)
export XAI_API_KEY=...             # xAI (Grok)
export OPENROUTER_API_KEY=...      # OpenRouter
export ALPHA_VANTAGE_API_KEY=...   # Alpha Vantage

如需使用本地模型，请在配置中将 llm_provider 设置为 "ollama"。

或者，复制 .env.example 文件为 .env 并填入您的密钥：

cp .env.example .env

命令行界面使用

启动交互式命令行界面：

tradingagents          # 使用已安装的命令
python -m cli.main     # 或者直接从源码运行

您将看到一个界面，可在其中选择所需的股票代码、分析日期、LLM 提供商、研究深度等。

界面会随着结果加载而实时显示，让您能够跟踪智能体的运行进度。

TradingAgents 包

实现细节

我们使用 LangGraph 构建 TradingAgents，以确保灵活性和模块化。该框架支持多种 LLM 提供商：OpenAI、Google、Anthropic、xAI、OpenRouter 和 Ollama。

Python 使用示例

要在代码中使用 TradingAgents，您可以导入 tradingagents 模块并初始化一个 TradingAgentsGraph() 对象。.propagate() 函数将返回一个决策结果。您可以运行 main.py，以下是一个简单示例：

from tradingagents.graph.trading_graph import TradingAgentsGraph
from tradingagents.default_config import DEFAULT_CONFIG

ta = TradingAgentsGraph(debug=True, config=DEFAULT_CONFIG.copy())

# 前向传播
_, decision = ta.propagate("NVDA", "2026-01-15")
print(decision)

您也可以调整默认配置，设置您自己选择的 LLM、辩论轮次等。

from tradingagents.graph.trading_graph import TradingAgentsGraph
from tradingagents.default_config import DEFAULT_CONFIG

config = DEFAULT_CONFIG.copy()
config["llm_provider"] = "openai"        # 可选：openai, google, anthropic, xai, openrouter, ollama
config["deep_think_llm"] = "gpt-5.2"     # 用于复杂推理的模型
config["quick_think_llm"] = "gpt-5-mini" # 用于快速任务的模型
config["max_debate_rounds"] = 2

ta = TradingAgentsGraph(debug=True, config=config)
_, decision = ta.propagate("NVDA", "2026-01-15")
print(decision)

有关所有配置选项，请参阅 tradingagents/default_config.py。

贡献指南

我们欢迎社区贡献！无论是修复错误、改进文档，还是提出新功能建议，您的参与都将帮助这个项目变得更好。如果您对该研究方向感兴趣，请考虑加入我们的开源金融 AI 研究社区 Tauric Research。

引用

如果您发现 TradingAgents 对您有所帮助，请引用我们的工作 :)

@misc{xiao2025tradingagentsmultiagentsllmfinancial,
      title={TradingAgents: Multi-Agents LLM Financial Trading Framework}, 
      author={Yijia Xiao and Edward Sun and Di Luo and Wei Wang},
      year={2025},
      eprint={2412.20138},
      archivePrefix={arXiv},
      primaryClass={q-fin.TR},
      url={https://arxiv.org/abs/2412.20138}, 
}

参考资料

TradingAgents：多智能体大语言模型金融交易框架
参考资料

AI 之母项目（The Mother of AI Project）

Mon, 23 Mar 2026 13:01:55 +0000

AI 之母项目（The Mother of AI Project）

第一阶段：RAG 系统 —— arXiv 论文整理助手

以学习者为中心的生产级 RAG 系统实践之旅

通过动手实践，从零构建现代 AI 系统

掌握当前最热门的 AI 工程技能：RAG（检索增强生成）

📖 关于本课程

这是一个以学习者为核心的项目，你将构建一个完整的研究助手系统，它可以自动获取学术论文、理解其内容，并利用先进的 RAG 技术回答你的研究问题。

arXiv 论文整理助手将教你如何基于行业最佳实践构建生产级 RAG 系统。

不同于那些直接跳到向量搜索的教程，我们遵循专业路径：

先掌握关键词搜索基础，再通过向量增强，实现混合检索。

🎯 专业方法的核心差异： 我们按照成功公司的方式构建 RAG —— 先打好搜索基础，再用 AI 增强，而不是忽略搜索基础、直接以 AI 为中心。

完成本课程后，你将拥有：

一个属于自己的 AI 研究助手
构建任意领域生产级 RAG 系统的深厚技术能力

🎓 你将构建的内容

第 1 周： 使用 Docker、FastAPI、PostgreSQL、OpenSearch、Airflow 搭建完整基础设施
第 2 周： 构建自动化数据管道，从 arXiv 获取并解析论文
第 3 周： 实现生产级 BM25 关键词搜索（含过滤与相关性评分）
第 4 周： 智能切分（chunking）+ 混合搜索（关键词 + 语义）
第 5 周： 完整 RAG 流水线（本地 LLM、流式响应、Gradio 界面）
第 6 周： 生产级监控（Langfuse）+ Redis 缓存优化性能
第 7 周： Agentic RAG（基于 LangGraph）+ Telegram Bot 移动端接入

🏗️ 系统架构演进

第 7 周：Agentic RAG + Telegram Bot 集成

（展示完整架构图）

LangGraph Agentic RAG 工作流

（展示决策节点、文档评分、自适应检索流程）

第 7 周讲解 + 博客： Agentic RAG with LangGraph and Telegram

第 7 周核心创新

智能决策能力： Agent 可动态调整检索策略
文档评分： 自动语义相关性评估
查询重写： 当结果不足时自动优化查询
护栏机制（Guardrails）： 防止越界问题和幻觉
移动端访问： Telegram Bot 实现跨设备 AI 交互
透明性： 完整推理过程可追踪（便于调试与增强信任）

🚀 快速开始

📋 前置条件

Docker Desktop（含 Docker Compose）
Python 3.12+
UV 包管理器
至少 8GB 内存 + 20GB 磁盘空间

⚡ 快速启动

# 1. 克隆项目
git clone <repository-url>
cd arxiv-paper-curator

# 2. 配置环境（重要）
cp .env.example .env
# 默认配置可直接运行
# 需额外添加：
# - Jina embedding API key
# - Langfuse key

# 3. 安装依赖
uv sync

# 4. 启动服务
docker compose up --build -d

# 5. 验证服务
curl http://localhost:8000/health

📚 每周学习路径

周次	内容
Week 0	项目整体介绍
Week 1	基础设施
Week 2	数据摄取
Week 3	BM25 搜索
Week 4	Chunking + 混合搜索
Week 5	完整 RAG
Week 6	监控 + 缓存
Week 7	Agentic RAG + Telegram

📊 服务访问地址

服务	地址	作用
API 文档	http://localhost:8000/docs	API 测试
Gradio 界面	http://localhost:7861	聊天 UI
Langfuse	http://localhost:3000	监控
Airflow	http://localhost:8080	工作流
OpenSearch	http://localhost:5601	搜索 UI

📚 第 1 周：基础设施

核心目标：构建 RAG 的底层基础

学习内容

Docker Compose 架构搭建
FastAPI 开发
PostgreSQL 数据库
OpenSearch 搜索引擎
Ollama 本地 LLM
服务编排与健康检测

📚 第 2 周：数据摄取

学习内容

arXiv API 集成
PDF 解析（Docling）
Airflow 自动化流程
元数据提取与存储

📚 第 3 周：关键词搜索（核心基础）

学习内容

为什么关键词搜索是 RAG 基石
OpenSearch 索引设计
BM25 算法原理
Query DSL 查询构建
搜索效果评估（precision / recall）

📚 第 4 周：Chunking + 混合搜索

学习内容

文档切分策略
向量 Embedding（Jina）
混合搜索（BM25 + 向量）
RRF 融合算法

📚 第 5 周：完整 RAG 系统

学习内容

本地 LLM（Ollama）
Prompt 优化（减少 80% Token）
流式响应（SSE）
Gradio UI

📚 第 6 周：生产级监控与缓存

学习内容

Langfuse 全链路追踪
Redis 缓存策略
延迟与成本监控
性能优化（最高 400x 提升）

📚 第 7 周：Agentic RAG

学习内容

LangGraph Agent 工作流
查询校验（Guardrails）
文档评分
查询重写
自适应检索
Telegram Bot 集成
推理透明化

⚙️ 配置说明

关键环境变量：

JINA_API_KEY（Week 4+ 必需）
TELEGRAM__BOT_TOKEN（Week 7 必需）
LANGFUSE__KEY（Week 6 可选）

🛠️ 技术栈

技术	作用
FastAPI	API
PostgreSQL	数据存储
OpenSearch	搜索
Airflow	调度
Jina AI	向量
Ollama	本地 LLM
Redis	缓存
Langfuse	监控

🏗️ 项目结构

src/
  ├── routers/
  ├── services/
  ├── models/
  ├── schemas/
  └── config.py

📡 API 示例

接口	说明
/health	健康检查
/papers	论文列表
/search	BM25 搜索
/hybrid-search	混合搜索

🔧 常用命令

make start
make stop
make test
make logs

🎓 适用人群

AI / ML 工程师
软件工程师
数据科学家

🛠️ 故障排查

服务未启动：查看 logs
端口冲突：检查 8000 / 8080 / 5432 / 9200
内存不足：增加 Docker 内存

💰 成本说明

本地开发：完全免费
云 API：约 $2-5（可选）

📄 许可证

MIT License（详见 LICENSE 文件）

参考资料

AI 之母项目（The Mother of AI Project）
📚 第 1 周：基础设施
- 学习内容
📚 第 2 周：数据摄取
- 学习内容
📚 第 3 周：关键词搜索（核心基础）
- 学习内容
📚 第 4 周：Chunking + 混合搜索
- 学习内容
📚 第 5 周：完整 RAG 系统
- 学习内容
📚 第 6 周：生产级监控与缓存
- 学习内容
📚 第 7 周：Agentic RAG
参考资料

TradingAgents：多智能体大语言模型金融交易框架

Mon, 23 Mar 2026 13:01:55 +0000

下面是对该 GitHub 项目 README 的完整中文翻译（结构化 + 精简但不丢关键信息）：

📌 PentAGI

渗透测试人工通用智能（Penetration Testing AGI）

✨ 一个完全自主的 AI Agent 系统，能够执行复杂的渗透测试任务 ([GitHub][1])

🎯 项目概述（Overview）

PentAGI 是一个用于自动化安全测试（渗透测试）的创新工具，利用先进的 AI 技术构建。

适用于：

信息安全工程师
安全研究人员
白帽黑客 / 安全爱好者

目标是提供一个强大、灵活、自动化的渗透测试解决方案。 ([GitHub][1])

✨ 核心特性（Features）

🛡️ 安全隔离
- 所有操作运行在 Docker 沙箱中，完全隔离
🤖 完全自动化
- AI Agent 自动决定并执行渗透测试步骤
🔬 专业工具集
- 内置 20+ 渗透工具，例如：
  - nmap
  - metasploit
  - sqlmap
🧠 智能记忆系统
- 存储历史经验、成功攻击路径
📚 知识图谱（Graphiti + Neo4j）
- 语义关系建模 + 上下文理解
🔍 Web 情报能力
- 内置爬虫浏览器获取最新信息
🔎 外部搜索整合
- 支持：
  - Google
  - DuckDuckGo
  - Tavily
  - Perplexity
  - Searxng 等

🏗️ 系统架构（Architecture）

核心模块

前端 UI
- React + TypeScript
后端 API
- Go + GraphQL / REST
向量数据库
- PostgreSQL + pgvector
任务队列
- 异步执行
AI Agent 系统
- 多 Agent 协作

AI Agent 工作流程（核心逻辑）

分为三个阶段：

Research（调研）
- 分析目标系统
- 搜索历史案例
- 查询漏洞知识库
Planning（规划）
- 制定攻击路径
- 选择工具和技术
Execution（执行）
- 实际执行渗透测试

👉 本质上是一个：

多 Agent + 记忆系统 + 工具调用的自动攻击闭环

🚀 快速开始（Quick Start）

系统要求

Docker + Docker Compose
≥ 2 CPU
≥ 4GB 内存
≥ 20GB 磁盘
可联网

推荐方式：安装器（Installer）

提供交互式安装工具：

mkdir -p pentagi && cd pentagi
wget -O installer.zip https://pentagi.com/downloads/linux/amd64/installer-latest.zip
unzip installer.zip

手动安装

1️⃣ 初始化

mkdir pentagi && cd pentagi
curl -o .env https://raw.githubusercontent.com/vxcontrol/pentagi/master/.env.example

2️⃣ 配置 API Key

至少配置一个 LLM：

OPEN_AI_KEY=
ANTHROPIC_API_KEY=
GEMINI_API_KEY=

可选：

AWS Bedrock
Ollama（本地模型）
搜索 API

3️⃣ 启动

docker compose up -d

访问：

https://localhost:8443

默认账号：

admin@pentagi.com / admin

🤖 Assistant（Agent）配置

关键参数：

ASSISTANT_USE_AGENTS=false

含义：

false → 默认不启用 Agent
true → 默认启用 Agent

👉 可以在 UI 中手动切换

🧠 知识图谱（Graphiti）

PentAGI 集成 Graphiti（基于 Neo4j）用于：

能力

语义记忆
关系建模
历史经验复用
复杂查询（如攻击路径分析）

开启方式

GRAPHITI_ENABLED=true
GRAPHITI_URL=http://graphiti:8000
NEO4J_URI=bolt://neo4j:7687

启动：

docker compose -f docker-compose.yml -f docker-compose-graphiti.yml up -d

💻 开发（Development）

依赖

Go
Node.js
Docker
PostgreSQL

后端初始化

cd backend
go mod download

运行测试 Agent

go run cmd/ctester/*.go -verbose

Docker 测试

docker run --rm vxcontrol/pentagi ...

🧪 Embedding（向量配置）

支持：

OpenAI（默认）
Ollama
HuggingFace
GoogleAI
VoyageAI 等

配置：

EMBEDDING_PROVIDER=openai
EMBEDDING_MODEL=text-embedding-3-small

🧰 工具测试（ftester）

支持功能：

执行命令
文件操作
浏览器访问
调试 Agent 流程

示例：

go run cmd/ftester/main.go terminal -command "ls -la"

🏗️ 构建（Build）

docker build -t local/pentagi:latest .

📄 许可证（License）

核心部分

MIT License

VXControl SDK 特殊说明

官方仓库可使用
Fork 时需要：
- 开源全部代码（AGPL）
- 或购买商业授权

🧠 总结（核心理解）

PentAGI 本质上是一个：

AI驱动的自动化渗透测试系统（Autonomous Pentest System）

技术核心是：

多 Agent 编排（Orchestrator / Researcher / Executor）
工具调用（nmap / metasploit 等）
长期记忆（Vector + Graph）
LLM 推理
自动化攻击流程闭环

参考资料

📌 PentAGI
参考资料

MoneyPrinter V2

Mon, 23 Mar 2026 13:01:55 +0000

MoneyPrinter V2

有想法？ 让我们来实现它 — 联系我们

♥︎ 赞助商：最佳 AI 聊天应用：shiori.ai

𝕏 另外，在 X 上关注我：@DevBySami。

一个自动化在线赚钱流程的应用程序。 MPV2（MoneyPrinter 第二版），顾名思义，是 MoneyPrinter 项目的第二个版本。它是对原始项目的完全重写，重点在于提供更广泛的功能和更模块化的架构。

注意： MPV2 需要 Python 3.12 才能有效运行。在此观看 YouTube 视频：链接

功能特性

Twitter 机器人（支持 CRON 任务 => 调度器）
YouTube Shorts 自动化工具（支持 CRON 任务 => 调度器）
联盟营销（亚马逊 + Twitter）
寻找本地商家并进行冷 outreach

版本

MoneyPrinter 拥有社区为社区开发的多种语言版本。以下是一些已知版本：

中文版：MoneyPrinterTurbo

如果您想提交您自己的 MoneyPrinter 版本或分支，请提交一个 issue，描述您对该分支所做的更改。

安装

⚠️ 如果您计划通过电子邮件联系爬取到的商家，请先安装 Go 编程语言。

git clone https://github.com/FujiwaraChoki/MoneyPrinterV2.git

cd MoneyPrinterV2
# 复制示例配置文件，并在 config.json 中填写相应值
cp config.example.json config.json

# 创建虚拟环境
python -m venv venv

# 激活虚拟环境 - Windows
.\venv\Scripts\activate

# 激活虚拟环境 - Unix
source venv/bin/activate

# 安装依赖项
pip install -r requirements.txt

使用方法

# 运行应用程序
python src/main.py

文档

所有相关文档可在此处找到：链接。

脚本

为方便使用，scripts 目录中提供了一些脚本，可用于直接访问 MPV2 的核心功能，无需用户交互。

所有脚本都需要从项目的根目录运行，例如：bash scripts/upload_video.sh。

贡献指南

请阅读 CONTRIBUTING.md 了解我们的行为准则以及提交拉取请求的流程。查看 docs/Roadmap.md 了解需要实现的功能列表。

行为准则

请阅读 CODE_OF_CONDUCT.md 了解我们的行为准则详情以及提交拉取请求的流程。

许可证

MoneyPrinterV2 采用 Affero 通用公共许可证 v3.0 进行许可。有关更多信息，请参阅 LICENSE。

致谢

免责声明

本项目仅用于教育目的。作者不对所提供信息的任何滥用行为负责。本网站上的所有信息均基于善意发布，仅供参考。

作者不对信息的完整性、可靠性和准确性做出任何保证。

您根据本网站（FujiwaraChoki/MoneyPrinterV2）上的信息采取的任何行动，风险自负。作者不对与使用我们网站相关的任何损失和/或损害承担责任。

参考资料

MoneyPrinter V2
- 功能特性
- 版本
- 安装
- 使用方法
- 文档
- 脚本
- 贡献指南
- 行为准则
- 许可证
- 致谢
- 免责声明
参考资料