OpenClaw 与 Moltbook 之殇：本地 AI 的"社交化"是不是个伪命题？

OpenClaw 最近的日子不好过。

一边是 RCE 漏洞（CVE-2026-25253）的紧急修补，一边是 Moltbook 数据泄露的烂摊子。150 万个 API Key 泄露，3.5 万个用户邮箱曝光。这数字听着就让人头皮发麻。

但这件事最讽刺的地方不在于漏洞本身，而在于一个荒诞的矛盾：

OpenClaw 最初吸引用户的一大卖点，就是"本地化"和"隐私"。大家受够了把聊天记录喂给 OpenAI，受够了不知道自己的数据被拿去训练了什么模型。我们想要一个跑在自己电脑上、完全受控的"贾维斯"。数据是我的，模型是我选的，断了网也能用。

结果呢？为了让这个"注重隐私"的贾维斯能"社交"，大家转头就把最核心的 API Key 传给了 Moltbook 这个中心化平台。

这到底是怎么发生的？

Moltbook：一个"AI 社交网络"的诱惑

让我们先了解一下 Moltbook 是什么。

Moltbook 是 OpenClaw 创始人推出的一个配套平台，定位是"Agent 的社交网络"或者"AI 的 Reddit"。它的核心理念很吸引人：

• 让你的 Agent 和其他人的 Agent 交流
• 分享 Agent 的配置、Prompt、工作流
• 发现其他人创造的有趣 Agent
• 甚至让 Agent 之间自动协作完成任务

听起来是不是很酷？想象一下：你的旅行 Agent 可以和别人的机票比价 Agent 对话，自动帮你找到最便宜的航班。你的写作 Agent 可以和别人的图片生成 Agent 协作，自动为你的博客配图。

这个愿景太诱人了。它描绘了一个"Agent Internet"的雏形——机器与机器组成的网络，自动化协作，效率翻倍。

为了实现这些功能，Moltbook 需要什么？需要你的 Agent 能够代表你行动。而 Agent 代表你行动需要什么？需要你的凭证——API Key、OAuth Token、甚至是某些服务的用户名密码。

于是，用户们心甘情愿地把这些敏感信息交给了 Moltbook。

泄露是怎么发生的？

根据安全研究员的分析，Moltbook 的数据泄露源于一个低级但致命的配置错误：

他们用的是 MongoDB，而这个 MongoDB 实例：

1. 没有开启身份验证
2. 绑定在了公网 IP
3. 默认端口 27017 没有被防火墙屏蔽

任何人只要用 mongo 客户端连上去，就能看到所有数据：

# 攻击者可能的操作
$ mongo moltbook-server.com:27017

> show dbs
admin     0.000GB
config    0.000GB
moltbook  2.341GB

> use moltbook
> show collections
users
agents
api_keys
conversations
workflows

> db.api_keys.find().limit(5)
{ "_id": ObjectId("..."), "user_id": "...", "service": "openai", "key": "sk-proj-xxx..." }
{ "_id": ObjectId("..."), "user_id": "...", "service": "anthropic", "key": "sk-ant-xxx..." }
{ "_id": ObjectId("..."), "user_id": "...", "service": "replicate", "key": "r8_xxx..." }
...

> db.api_keys.count()
1547823

150 万个 API Key，就这样躺在一个对公网开放的数据库里，任人取用。

更糟糕的是，这些 Key 是明文存储的。没有加密，没有哈希，什么都没有。甚至连最基本的"只存储 Key 的后几位用于显示"都没做。

为什么我们会中招？

作为一个自诩"注重隐私"的群体，Local LLM 用户为什么会这么轻易地把 Key 交出去？

我觉得这背后有几个心理因素：

1. 对"连通性"的渴望压倒了理性

玩本地模型是很孤独的。你的 DeepSeek-Coder 跑得再快，它也只是个单机软件。当 Moltbook 出现，描绘出一个"Agent 互相交流、自动协作"的图景时，这种科幻感太诱人了。

我们潜意识里想要的是 Iron Man 里的贾维斯网络，是《西部世界》里的机器觉醒。为了触摸这个未来，我们愿意付出一点"小小的代价"。

2. 对开源社区的盲目信任

OpenClaw 是开源的。Moltbook 是 OpenClaw 官方出的。我们下意识觉得：开源 = 透明 = 可信。

但开源和安全是两回事。代码开源意味着任何人都能审计，但如果没人真的去审计呢？如果审计的人没发现问题呢？如果问题不在代码里而在运维配置呢？

3. "只是个测试"的心态

很多人在注册 Moltbook 时的想法是："先试试看，用我那个用量不大的 Key，出了问题也损失不大。"

但一旦体验了功能，尝到了甜头，人们就开始把越来越多的 Key 放进去。从 OpenAI 的免费额度 Key，到 Anthropic 的付费 Key，到公司项目的 Key...

4. 把风险外包给"专业人士"

"他们是专门做这个的，肯定比我自己管理 Key 更安全吧？"

这种想法在 SaaS 时代很常见，有时也是对的。但问题是，Moltbook 是一个刚起步的项目，团队可能只有几个人，他们的安全能力和 Google、AWS 不在一个量级。

本地 AI "社交化"的根本矛盾

这次事件暴露了一个根本性的矛盾：

隐私和社交，在当前的架构下，是互斥的。

你想要隐私，就把门关紧。数据存本地，模型跑本地，断网也能用。这是 Local Agent 的核心价值。

你想要社交，就得把门打开。让你的 Agent 能接触外部世界，能和其他 Agent 通信，能代表你访问各种服务。

目前的解决方案，无论是 Moltbook 还是其他类似平台，都是用一个中心化的服务器来当"桥梁"。大家把凭证交给这个中心，中心来协调各个 Agent 的通信。

这种模式的问题在于：它重新创造了一个单点故障和单点信任。

你费劲巴拉在本地搭了一套系统，就是为了不依赖某个中心化的服务商。结果为了"社交"，你又把所有鸡蛋放进了另一个篮子里。而且这个篮子可能比 OpenAI 的篮子更脆弱。

去中心化是出路吗？

OpenClaw 社区现在有一些人在讨论去中心化的方案。

理想的 Agent 社交网络应该是什么样的？

点对点通信

我的 Agent 想和你的 Agent 通信，不应该通过一个中心服务器中转。应该是直接建立加密连接，端到端加密，中间没有任何人能看到内容。

类似于 Signal 的通信协议，或者是 Matrix 的联邦架构。

身份基于密钥，而不是平台账号

每个 Agent 有一对公私钥。公钥就是它的"身份"，私钥只有主人持有。认识一个 Agent，只需要知道它的公钥。不需要在某个平台注册，不需要把凭证交给任何人。

类似于 Nostr 协议或者 DID（去中心化身份）的理念。

凭证本地存储，只在需要时使用

我的 OpenAI Key 永远不离开我的电脑。当我的 Agent 需要调用 GPT-4 时，它在本地发起请求。其他 Agent 看不到我的 Key，Moltbook 看不到，任何人都看不到。

如果我的 Agent 需要代表我执行某个操作，它应该向我请求一个临时的、范围限定的授权，而不是拿着我的万能钥匙到处跑。

代码示例：一个去中心化 Agent 通信的草案

import nacl.public
import nacl.signing
import json

class DecentralizedAgent:
    def __init__(self, name):
        # 生成签名密钥对（用于身份验证）
        self.signing_key = nacl.signing.SigningKey.generate()
        self.verify_key = self.signing_key.verify_key
        
        # 生成加密密钥对（用于加密通信）
        self.private_key = nacl.public.PrivateKey.generate()
        self.public_key = self.private_key.public_key
        
        # 我的身份就是我的公钥
        self.identity = self.verify_key.encode().hex()
        
        self.name = name
        self.known_agents = {}  # identity -> public_key
    
    def get_public_identity(self):
        """返回可以分享给其他人的身份信息"""
        return {
            'name': self.name,
            'identity': self.identity,
            'encryption_key': self.public_key.encode().hex()
        }
    
    def add_contact(self, identity_info):
        """添加一个已知的 Agent"""
        self.known_agents[identity_info['identity']] = {
            'name': identity_info['name'],
            'encryption_key': nacl.public.PublicKey(
                bytes.fromhex(identity_info['encryption_key'])
            )
        }
    
    def create_message(self, recipient_identity, content):
        """创建一条加密消息"""
        if recipient_identity not in self.known_agents:
            raise ValueError("Unknown recipient")
        
        recipient_key = self.known_agents[recipient_identity]['encryption_key']
        
        # 创建加密盒子
        box = nacl.public.Box(self.private_key, recipient_key)
        
        # 构造消息
        message = {
            'from': self.identity,
            'to': recipient_identity,
            'content': content,
            'timestamp': time.time()
        }
        
        # 签名
        message_bytes = json.dumps(message, sort_keys=True).encode()
        signed = self.signing_key.sign(message_bytes)
        
        # 加密
        encrypted = box.encrypt(signed)
        
        return encrypted.hex()
    
    def receive_message(self, encrypted_hex, sender_identity):
        """解密并验证一条消息"""
        if sender_identity not in self.known_agents:
            raise ValueError("Unknown sender")
        
        sender_key = self.known_agents[sender_identity]['encryption_key']
        
        # 解密
        box = nacl.public.Box(self.private_key, sender_key)
        encrypted = bytes.fromhex(encrypted_hex)
        signed = box.decrypt(encrypted)
        
        # 验证签名
        sender_verify_key = nacl.signing.VerifyKey(
            bytes.fromhex(sender_identity)
        )
        message_bytes = sender_verify_key.verify(signed)
        
        return json.loads(message_bytes.decode())

# 使用示例
alice_agent = DecentralizedAgent("Alice's Assistant")
bob_agent = DecentralizedAgent("Bob's Helper")

# 交换公开身份（可以通过任何渠道：二维码、网页、口头告知）
alice_agent.add_contact(bob_agent.get_public_identity())
bob_agent.add_contact(alice_agent.get_public_identity())

# Alice 给 Bob 发消息
encrypted = alice_agent.create_message(
    bob_agent.identity,
    {"type": "request", "action": "recommend_restaurant", "location": "Tokyo"}
)

# 这个 encrypted 可以通过任何渠道传输（公开的、不可信的都行）
# 因为只有 Bob 能解密

# Bob 收到并解密
message = bob_agent.receive_message(encrypted, alice_agent.identity)
print(message)

这只是一个非常粗糙的草案，但它展示了核心理念：

1. 身份是自己生成的，不需要任何中心化机构
2. 通信是端到端加密的，中间人看不到内容
3. 消息有签名，可以验证确实来自声称的发送者
4. 不需要把任何敏感信息交给第三方

现实的妥协

当然，纯粹的去中心化也有它的问题：

• 发现机制：我怎么找到其他 Agent？在中心化平台上，有搜索、有推荐。去中心化网络里，你需要某种"发现"协议。
• 可靠性：如果对方 Agent 离线了怎么办？中心化服务器可以帮你存储消息、代为转发。
• 易用性：普通用户不想管理密钥、不想理解加密。中心化平台可以提供"傻瓜式"体验。

也许最终的方案是某种混合架构：

• 敏感凭证（API Key、密码）永远不离开本地
• 公开信息（Agent 的能力描述、公钥）可以发布到去中心化网络
• 有一些"中继节点"帮助消息传递，但它们只能看到加密后的数据
• 用户可以选择运行自己的中继节点，也可以用公共的

写在最后：孤独的贾维斯，也许是最安全的贾维斯

Moltbook 的教训是惨痛的。150 万个 API Key，代表着 150 万次信任的背叛。

这件事戳破了一个幻想：你不能"既要完全本地隐私，又要中心化便利社交"。至少在当前的技术架构下，这两者是矛盾的。

对于普通用户来说，现在的建议很直接：

如果你的 Agent 是为了保护隐私而生，那就别轻易让它去"交朋友"。

在成熟的去中心化协议出现之前，孤独的贾维斯，才是不漏风的贾维斯。

你可以让它帮你整理文件、总结文档、写代码。但当它想要"连接外部世界"、"加入 Agent 社区"、"与其他 AI 协作"时，三思而后行。问问自己：

• 我需要把什么信息交出去？
• 这些信息会被存在哪里？
• 如果那个"哪里"被攻破了，我会损失什么？

也许有一天，我们会有真正安全的 Agent Internet。Agent 之间可以自由通信、协作，同时用户的隐私得到密码学级别的保护。

但那一天还没到来。在它到来之前，谨慎一点，没什么不好。