标签 GGUF 下的文章

摘要:
本文介绍如何为开源个人AI助手 Moltbot(原 ClawdBot)集成基于 OceanBase 技术栈的长期记忆插件 PowerMem。通过 HTTP API 对接,PowerMem 为 Moltbot 提供智能信息抽取、艾宾浩斯遗忘曲线调度及多智能体隔离的记忆能力,显著增强其上下文持久化与自主决策水平,实现更类人的“数字员工”体验。 

Moltbot 是什么?


Clawdbot(后更名为 Moltbot,又更名为 OpenClaw)是一款开源、以通讯为核心的AI智能体项目,运行在你自己的设备上,通过你已有的渠道(WhatsApp、Telegram、Slack、Discord、Google Chat、Signal、iMessage、Teams、WebChat 等)和你对话,支持语音、Canvas、多代理路由等。 简单点说:Moltbot 最大的特点是不仅能回答问题,更能真正“动手”操作你的电脑系统,执行命令、控制浏览器、管理文件,就像一个 7 x 24 小时在线的 “数字员工”。 

官网 :https://www.molt.bot/
github 地址:https://github.com/moltbot/moltbot
 

Moltbot 部署

方式一:NPM 全局安装

方式二:源代码安装

上面两种安装方式二选一,因为我是走的源代码安装:
1.     pnpm moltbot onboard --install-daemon 初始化

2.     同意风险
提示这里会让你确认风险。Moltbot 功能强大,能执行系统命令、读写文件、控制浏览器,但这也意味着如果配置不当或被滥用,可能会带来安全风险,请谨慎使用。

3.     选择快速开始
4.     配置 AI 模型授权,我手里头有qwen的

5.     启动web问个小问题:“查一下我的电脑型号”,很快 moltbot 回复了我机器的具体型号,虽然任务非常简单,但是还是挺惊喜的,距离“贾维斯”又进了一步了。

Moltbot 的原生记忆解读

Moltbot 的持久记忆可以概括为:「Markdown 文件为单一事实来源 + 可选向量/混合检索」。 

存储形态:纯 Markdown 文件 事实来源:模型「记得」的内容 = 写入磁盘的 Markdown;不依赖模型内部状态。默认布局(在 workspace 下,如 ~/clawd):memory/YYYY-MM-DD.md:按日期的日志,仅追加;会话开始时读「今天 + 昨天」。MEMORY.md(可选):长期、人工可维护的记忆;只在 main 私聊 session 加载,群聊不加载。 也就是说:短期、按天的记录 → memory/YYYY-MM-DD.md长期、精选事实 → MEMORY.md持久化完全靠「写进这些文件」,而不是靠对话历史本身。 

写入时机与「记忆冲刷」(Memory Flush) 平时:模型通过 工具(如 write、edit)或技能,把要记住的内容写到 MEMORY.md 或 memory/YYYY-MM-DD.md。自动冲刷:当 session 快触发自动 compaction 前,Moltbot 会跑一轮 静默的 agent 回合,专门提醒模型「把该持久化的东西写进记忆文件」,并鼓励用 NO_REPLY 不回复用户,避免用户看到这次内部回合。触发条件由 agents.defaults.compaction.memoryFlush 控制,例如在「剩余 token ≈ softThresholdTokens」时触发;每轮 compaction 只做一次 flush,并在 sessions.json 里记 memoryFlushCompactionCount 等,避免重复。 

相关代码在 src/auto-reply/reply/memory-flush.ts:shouldRunMemoryFlush():根据当前 token、context 上限、reserve、softThreshold 判断是否该 flush。

若 workspace 只读(如 sandbox workspaceAccess: "ro"),则不做 flush。 

检索层:向量 + 可选 BM25 混合检索 
数据流

实现方式 

插件控制:默认使用 memory-core 插件(可设 plugins.slots.memory = "none" 关掉)。工具:memory_search:对 MEMORY.md 和 memory/.md 做语义检索(按 ~400 token 分块、80 token 重叠),返回片段 + 文件路径 + 行号;可选开启 BM25 + 向量 的混合检索。memory_get:按路径(及可选 from/lines)读取 MEMORY 或 memory 下的文件片段,供在检索后精确拉取,控制上下文长度。向量索引:对MEMORY.md 和 memory/.md 建索引;索引按 agent 存于 ~/.clawdbot/memory/.sqlite(路径可配)。支持远程 embedding(OpenAI、Gemini 等)或本地模型(如 GGUF);可选 sqlite-vec 做向量加速。文件变更有 watcher(debounce),索引异步更新;若 embedding 模型/端点等变化,会整库重建索引。 

混搜权重分配

最终分数的计算公式非常简单(src/memory/hybrid.ts):

这意味着:向量搜索和文本三七开:最终得分 = 0.7×向量分 + 0.3×文本分(归一化后),偏重语义。候选池放大 4 倍:先取 maxResults × 4 的候选再合并、排序、截到 maxResults,提高最终 Top‑N 质量。 

Moltbot + powermem 方案


有 PowerMem VS 没有 PowerMem

集成 powermem 方案集成方式:已插件的方式进行集成

集成方式:新增插件 extensions/memory-powermem,通过 HTTP 调用 PowerMem 已启动的 API 服务;不把 PowerMem 作为库嵌入 Moltbot 进程。部署:用户需单独启动 PowerMem(如 powermem-server --host 0.0.0.0 --port 8000 或 Docker),并在 Moltbot 配置中填写 baseUrl(及可选 apiKey)。 代码结构代码地址:https://github.com/ob-labs/moltbot-extension-powermem

在 Moltbot Agent 里会暴露这些能力:memory_recall — 按查询搜索长期记忆memory_store — 写入一条记忆(可选是否智能抽取)memory_forget — 按记忆 ID 或按搜索条件删除 使用 powermem 插件 Step1: 前置条件 已安装 Moltbot(CLI + gateway 能正常用)PowerMem 服务:需要单独安装并启动(见下文两种方式,任选其一)若用 PowerMem 的「智能抽取」:需在 PowerMem 的 .env 里配置好 LLM + Embedding 的 API Key(如通义千问 / OpenAI) Step2:把本插件装进 Moltbot 在你本机执行(路径改成你实际克隆的目录):

安装成功后,可用 moltbot plugins list 确认能看到 memory-powermem。 Step3:配置 Moltbot 使用本插件 编辑 Moltbot 的配置文件(常见位置:~/.clawdbot/config.json 或项目里的 moltbot.json),在 根级 增加或合并 plugins 段,并把记忆槽指向本插件,并写上 PowerMem 的地址。 示例(JSON):

说明:baseUrl:PowerMem 的 HTTP 地址,不要加 /api/v1,就写 http://localhost:8000 或你的实际主机/端口。若 PowerMem 开了 API Key 鉴权,在 config 里增加 "apiKey": "你的key"。改完配置后重启 Moltbot gateway(或重启 Mac 菜单栏应用),配置才会生效。 Step4:验证插件与 PowerMem 连通 在终端执行:

若输出里没有报错、能看到健康状态,说明插件已连上 PowerMem。 Step5: 测试手动写入 + 搜索 我们来简单测试一下,用手动写入验证数据库是否有数据

 若搜索能返回刚写的那条(或类似内容),说明「安装 PowerMem → 安装插件 → 配置 Moltbot」全流程已打通。 下面是执行结果:

看一眼数据库,妥妥的已经写入了

 欢迎访问 OceanBase 官网获取更多信息:https://www.oceanbase.com/  

Intro 随着AI相关技术特别是大语言模型的逐步火热,衍生出一系列传统安全中不存在的一些攻击模式,例如Agent Security、MCP Security等等攻击范式,本文主要集中的是随着AI浪潮带来的MFV(Model Format Vulnerability),核心是对不可信的外部文件内容在非沙箱环境中进行执行,造成了代码执行漏洞的危害 What 首先我们来熟悉一下什么是MFV漏洞 为便于进行模型的share过程,我们通常会将训练后的机器学习模型、深度学习模型甚至大语言模型通过序列化的方式将其保存在一个特定的文件格式中,例如现在LLM常用的.safetensors.gguf的模型文件格式,又比如机器学习中常用的.h5模型格式文件,在第三方获取到分享的模型之后在模型的加载过程中对其中的键值对进行反序列化操作,同样的,也是因为反序列化这一操作,导致存在有安全漏洞的产生,可能导致任意代码执行等危险 当前针对MFV漏洞核心存在有两类漏洞类型: 1 Deserialization: 也即是反序列化的方式,因为在进行模型模型加载过程中对存储的对象进行反序列化操作还原对象的过程中,对于精心制作的模型,在反序列化的过程中将会执行对应的恶意代码 2 Backdoors:对于后门攻击其包含了多种中毒方式,包含有数据中毒等等攻击方式,其主要是在原始模型的基础上嵌入了一些隐藏的恶意功能 Deserialization Threats Archive Slip 在传统的Web漏洞中存在一类漏洞利用方式,也即是zip slip漏洞,其成因是由于在对zip压缩包进行解压缩的过程中,未对压缩包中包含的entry进行安全过滤,其存在有类似于..这类似跨目录的标识符作为entry导致能够进行一种另类的"任意文件上传"。 而在AI机器学习领域中同样存在有开放框架使用ZIP等压缩包格式的文件进行模型数据的存储,同样这些漏洞格式也会造成archive slip漏洞,具体的过程可描述为在进行模型加载的过程中,对模型进行反序列化的操作过程中,同样的如何遭遇了类似于../~$D:这类在不同的操作系统代表不同含义的特殊字符,可能会导致目录穿越等 例如NVIDIA的NeMo框架

其所对应的漏洞CVE-2022-22821则是由于这个原因导致的zip slip漏洞 https://github.com/NVIDIA-NeMo/NeMo/security/advisories/GHSA-rpx7-33j2-xx9x

Model Config Executable 在模型加载的过程中,对于模型的配置同样也是外部可控的一点,若采用了类似于Hydra这类存在有动态执行方法能力的框架进行配置文件的加载,若加载了一些其中注入有特定的恶意代码的模型文件,在进行模型加载的过程中,使用Hydra框架对配置进行解析,将会导致任意代码执行等漏洞 简单了解一下什么是Hydra https://github.com/facebookresearch/hydra Hydra是一个由Facebook团队开源的用于优雅配置复杂应用程序的Python框架,主要包括以下核心功能 1 分层配置系统 - 从多个源创建复杂配置 2 命令行覆盖 - 通过命令行轻松修改配置值 3 动态 Tab 补全 - 配置选项的命令行自动补全 4 远程执行 - 本地运行或远程启动应用程序 5 多任务执行 - 从单个命令使用不同配置运行多个作业 6 插件架构 - 通过插件扩展功能,支持优化、作业启动等 之后就是简单的使用Hydra

可以通过如上方式进行配置文件的加载,其核心是通过@hydra.main()这一个装饰器进行配置文件的初始化 而回到我们的AI模型相关场景,当攻击者向第三方平台,例如hunggingface或者ModelScope上传了一个包含有恶意代码的权重文件,攻击者采用了Safetensors采用YAML或者JSON的格式去存储模型元数据,受害者在下载了该模型准备使用类似于NeMo以及ml-flextok这类使用了Hydra框架进行模型元数据配置文件的加载以及解析时将会执行其中的恶意代码逻辑 我们可以将以上场景抽象为以下的代码: 1 创建一个yaml文件用于模拟携带有恶意代码的模型文件 2创建一个python代码利用hydra进行配置文件的加载以及对象的实例化进行代码执行

其也能够观察到系统命令的执行,导致了文件写入 分析其成因,进入到instantiate函数中,查看其实例化过程

根据配置文件的数据类型的不同进行不同的处理,这里命令执行我们构建的yaml文件是Dict数据类型 1 首先使用_prepare_input_dict_or_list将配置文件转化成一个Dict字典 2 在经过OmegaConf对字典进行处理后,核心使用instantiate_node去对节点进行实例化操作 3 其中对于_target_这一个特殊的key对应的value使用_resolve_target进行解析

4 该函数中传递的target值则为我们上面实例中配置文件中的_target_字段值,也即是os.system,其通过_locate进行待实例化的类和函数

5 其通过.进行划分,一步一步使用import_module进行模块的导入

6 在获取到了target对应的函数后,回到步骤3中展示的函数,调用_call_target函数结合传递的参数进行函数的执行 通过以上对于Hydra框架中对序列化的配置文件的对象进行反序列化的过程导致的恶意代码实例的分析,我们可以明白造成该类漏洞的原因是由于外部输入可控以及未对_target_进行安全校验直接进行函数定位 GGUF Model Template GGUF文件格式由llama.cpp团队创建,其通常用于保存模型的训练数据,该文件格式针对模型的快速加载和存储进行优化。 chat template在大语言模型中较为常见,通过系统提示词以及用户提示词提升LLM的回复效果屡见不鲜,同样的,在LLM中常用的GGUF格式文件中同样有着chat template的身影。提到template,就不得不联想到传统安全中的一类漏洞,也即是SSTI漏洞,其是由于模板内容可控的同时,渲染模型所采用的模板引擎执行时未在沙箱环境中执行,导致了任意代码执行的产生。对于Python语言来讲,常见开发框架DjangoFlask等都基于jinja2模板引擎进行模板渲染。

同样的,GGUF格式文件同样使用了Jinja2模板引擎进行提示词的格式化,所以导致了在加载带有Jinja模板恶意代码的GGUF文件时将会执行恶意代码 同样对于这类漏洞的实例可以参考CVE-2024-34359

其核心是由于llama-cpp-python在加载.gguf格式保存的模型时,直接使用了self.metadata["tokenizer.chat_template"]从元数据中获取了模型中保存的chat_template值,并将其传递给了llama_chat_format.Jinja2ChatFormatter创建了一个chat行为的处理器handler,该类使用了Jinja2模板引擎,且未在安全的沙箱环境中处理,若元数据中的chat_template字段中存在有符合Jinja2语法的代码,在进行问答时将会触发其中的恶意代码

Pickle Model Pickle为Python用于序列化与反序列过程的原生库,在传统安全中Pickle库导致的反序列化漏洞也曾不出穷。其在加载一些不受信任的序列化数据将会在反序列化的过程中造成任意代码执行等危害。 基于其上的变种框架还有cloudpickledilljoblib等等,又比如Numpy中的numpy.save(.., allow_pickle=True, )以及PyTorch中的torch.save(model.state_dict(), ..) Joblib Model Joblib 是一个轻量级的 Python 库,专门用于提供高效的管道式计算作业处理。它主要解决科学计算和数据处理中的三个核心问题:避免重复计算、并行化代码执行以及高效持久化 Python 对象

而其中提及到的高效持久化的实现核心是采用了Pickle库对其进行了实现,则导致了反序列化的安全问题 相关的实例可以参考CVE-2024-34997漏洞 https://security.snyk.io/vuln/SNYK-PYTHON-JOBLIB-6913425

使用了pickle.dump方法进行了恶意类的序列化过程,在完成序列化后,使用Joblib提供的NumpyArrayWrapper类进行反序列化过程,在这个过程中将会动态执行其中的__reduce__魔术方法,也即是执行了系统命令 Pytorch Model 同样的,对于Pytorch框架,如何其使用了pickle库进行模型的序列化过程,在反序列化的过程中将会导致__reduce__魔术方法的调用 https://huntr.com/bounties/84d6dc11-23aa-499a-9a62-45596a4d7ef5 对于pytorch来讲,其中的torch.save以及torch.load底层分别使用了Pickle进行序列化以及反序列化,在反序列化的过程中将会执行恶意代码

Ref https://github.com/NVIDIA-NeMo/NeMo/security/advisories/GHSA-rpx7-33j2-xx9x https://github.com/abetlen/llama-cpp-python/security/advisories/GHSA-56xg-wfcc-g829 https://security.snyk.io/vuln/SNYK-PYTHON-JOBLIB-6913425

刚刚在推上看到的
ymcki 给 Kimi-Linear-48B-A3B 加上了 MLA KV cache
实测下来 1M 上下文 F16 KV cache 显存占用从 140G 降到 15G。
如果显存少一点的用户可以选择(with KV Quant )

  • q8_0: 7.9GB
  • q5_1: 5.6GB
  • q4_0: 4.2GB
    有兴趣可以玩看看

Kimi-Linear-48B 的效果


📌 转载信息
原作者:
josenlou
转载时间:
2026/1/14 10:54:29