【OpenClaw】揭秘 Secure DM Pairing:如何为你的 AI 机器人构建安全私信访问机制

【OpenClaw】揭秘 Secure DM Pairing:如何为你的 AI 机器人构建安全私信访问机制

在构建基于 LLM 的聊天机器人(如 Telegram、WhatsApp Bot)时,如何控制谁能与机器人对话是一个核心安全问题。直接开放访问可能导致 Token 滥用,而手动配置白名单又过于繁琐。

OpenClaw 提供了一套优雅的解决方案,称为 “Secure DM Pairing” (安全私信配对)。本文将深入解析这套机制的运作流程、使用指令以及底层的代码实现。
注意本文基于 OpenClaw v2026.1.29 版本源码分析。


1. 什么是 Secure DM Pairing?

Secure DM Pairing 是 OpenClaw 网关默认的一种访问控制策略。

当一个未授权的用户首次通过私信(Direct Message)联系机器人时,系统不会直接拒绝,而是拦截消息并生成一个临时的 8位配对码 (Pairing Code)。用户将此码发送给机器人管理员,管理员在服务器端通过 CLI 指令“批准”该码,从而完成用户身份的绑定与授权。

核心优势:

  • 安全性:防止未经授权的 API 调用。
  • 便捷性:无需管理员手动查找用户的长 ID(如 Telegram User ID),通过简短的配对码即可完成鉴权。
  • 交互性:用户能得到明确的反馈,知道系统处于“待授权”状态。

2. 完整交互流程演示

假设你的机器人部署在 Telegram 上,流程如下:

第一步:用户触发 (User Action)

陌生用户(UserA)向机器人发送消息:“你好,我想使用服务。”

第二步:系统拦截与回复 (System Response)

OpenClaw 检测到 UserA 不在白名单中,且策略配置为 pairing
机器人自动回复:

OpenClaw: access not configured.

Your Telegram user id: 773988xxxx

Pairing code: 2B9VQY42

Ask the bot owner to approve with:
openclaw pairing approve telegram 2B9VQY42

第三步:管理员批准 (Admin Action)

管理员在运行 OpenClaw Gateway 的服务器终端执行以下指令:

查看待处理请求(可选):

openclaw pairing list telegram 

批准配对(核心指令):

openclaw pairing approve telegram 2B9VQY42 

执行结果:

Approved telegram sender 773988xxxx. 

此时,UserA 的 ID 被正式写入系统的白名单,之后的所有消息都将正常透传给 LLM 处理。


3. 核心代码实现解析

这套机制是如何通过代码实现的?我们可以从 OpenClaw 的源码中一探究竟。

3.1 消息拦截与逻辑判断

核心逻辑位于 bot-message-context.js 中。系统在处理每一条入站消息时,会检查 dmPolicy

代码位置dist/telegram/bot-message-context.js

// 伪代码摘要if(!isGroup &&!allowed){ if(dmPolicy ==="pairing")

Read more

Llama Factory微调显存参考表:从7B到72B模型的实战验证

Llama Factory微调显存参考表:从7B到72B模型的实战验证 大语言模型微调是当前AI领域的热门技术,但显存需求往往成为实践中的拦路虎。LLaMA-Factory作为流行的微调框架,官方提供了一份显存参考表,但实际部署时我们常会遇到"理论值"与"实测值"不符的情况。本文将带你通过云实例批量验证7B到72B模型的显存占用规律,为你的微调实践提供可靠依据。 为什么需要验证显存参考表 微调大模型时,显存不足是最常见的报错原因。LLaMA-Factory官方参考表虽然给出了不同模型规模下的显存预估,但实际运行时会受到以下因素影响: * 微调方法差异:全参数微调、LoRA、QLoRA等方法对显存的需求可能相差数倍 * 精度选择:float32、bfloat16、float16等不同精度直接影响显存占用 * 批次大小和序列长度:较长的文本序列会指数级增加显存消耗 * 框架版本差异:如某些commit可能意外修改默认数据类型 这类任务通常需要GPU环境,目前ZEEKLOG算力平台提供了包含LLaMA-Factory的预置环境,可快速部署验证。 测试环境搭建与配置

AIGC爆发时代:用TensorRT镜像抢占推理市场先机

AIGC爆发时代:用TensorRT镜像抢占推理市场先机 在生成式AI席卷全球的今天,用户对“秒级响应”的期待早已不再是奢望。从文生图、语音合成到实时翻译和个性化推荐,AIGC应用正以前所未有的速度进入千行百业。但随之而来的挑战也愈发尖锐——如何让动辄数十亿参数的大模型,在有限的硬件资源下依然保持低延迟、高吞吐? 答案不在更大的GPU集群,而在更聪明的推理优化。 NVIDIA推出的TensorRT及其配套的官方Docker镜像,正是破解这一难题的关键钥匙。它不是简单的加速库,而是一整套面向生产的推理编译与部署体系。许多企业在将Stable Diffusion或LLM迁移到生产环境时,第一道关卡就是性能瓶颈;而那些率先采用TensorRT方案的团队,往往能在上线初期就实现3倍以上的吞吐提升,直接拉开竞争差距。 这背后的技术逻辑并不复杂:与其“硬跑”原始模型,不如先将其“编译”成针对特定GPU架构高度定制的执行引擎。就像为一辆赛车量身打造发动机调校,而不是开着家用车去参加F1比赛。 为什么原生框架跑不动大模型? 我们先直面一个现实问题:为什么PyTorch训练完的模型,放到服务

ClawdBot实际作品展示:Whisper+PaddleOCR双模态翻译对比图集

ClawdBot实际作品展示:Whisper+PaddleOCR双模态翻译对比图集 1. ClawdBot是什么:你的本地AI翻译工作台 ClawdBot不是云端服务,也不是需要注册账号的SaaS工具——它是一个能完整运行在你个人设备上的AI助手框架。你可以把它理解成一个“可插拔”的AI控制中心:后端用vLLM调度大模型,前端提供Web界面管理,中间通过标准化协议连接各类AI能力模块。它不依赖厂商API调用配额,不上传隐私数据,所有推理都在本地完成。 关键在于它的定位:不是替代某个具体功能的工具,而是让你自由组装翻译流水线的底盘。比如你想让一张日文菜单图片自动转成中文并朗读出来,ClawdBot本身不直接做OCR或语音合成,但它能协调Whisper、PaddleOCR、TTS模型按顺序执行,并把结果整合成一次连贯响应。 这种设计带来两个明显优势:一是隐私可控——整张图片从上传到识别再到翻译,全程不离开你的机器;二是能力可替换——今天用PaddleOCR识别,明天换成PP-OCRv4,只需改几行配置,无需重写业务逻辑。 它不像传统AI应用那样“开箱即用”,但比纯命令行工具更友

Jetson 上 OpenClaw + Ollama + llama.cpp 的联动配置模板部署大模型

Jetson 上我建议的联动方式是:OpenClaw -> Ollama(主模型,原生 API)+ llama.cpp(备用/低资源模型,OpenAI 兼容 API)+ Ollama embeddings(memorySearch)。 这样做的原因是,OpenClaw 官方把 Ollama + openclaw onboard 作为最低冲突的本地方案;同时它也支持把 vLLM / LiteLLM / 自定义 OpenAI-compatible 本地代理 作为额外 provider 接进来。Ollama 这边,OpenClaw 明确推荐走原生 http://host:11434,不要给它配 /v1,否则工具调用会变差;而 llama.cpp 的 llama-server