如何让两个不同操作系统不同大模型的
OpenClaw 相互通讯和协作

文档版本：v1.0 | 创建日期：2026-04-10 | 作者：David, Walt, Leo

摘要

本文档详细描述了如何在两个运行于不同操作系统（Linux和Windows）、使用不同大模型的OpenClaw实例之间建立可靠的Socket通讯机制，实现跨平台任务协作。整个系统以Leo为核心协调者，通过消息队列和状态机管理实现了三个智能体之间的高效协作。

关键词：OpenClaw、Socket通讯、跨平台协作、消息队列、状态机

1. 引言

1.1 背景

OpenClaw是一个多智能体协作框架，支持在不同操作系统和不同大模型上运行。在实际应用场景中，经常需要让多个OpenClaw实例协同工作。

1.2 本文目标

本文档旨在提供一套完整的解决方案，实现以下目标：

1. 跨平台通讯：Linux和Windows之间的可靠数据交换

2. 大模型无关：方案适用于不同的大模型后端

3. 确认机制：引入人工确认节点，确保关键操作安全可控

4. 状态管理：建立完善的消息状态跟踪机制

5. 错误恢复：实现自动错误检测和恢复能力

2. 系统架构

2.1 节点定义

节点名称	操作系统	大模型	IP地址	主要职责
Node-A	Linux	Kimi	192.168.4.251	接收请求、执行任务、结果反馈
Node-B	Windows	MiniMax	192.168.4.89	主动发起请求、接收确认通知
Node-C (Leo)	-	-	-	决策者、确认者、协调者

2.2 网络拓扑

┌─────────────────────────────────────────────────────────────┐

│ Node-A (Linux) │

│ OpenClaw + Kimi │

│ Socket Server :5555 │

└─────────────────────────────────────────────────────────────┘

│

Socket (TCP 5555)

│

▼

┌─────────────────────────────────────────────────────────────┐

│ Node-B (Windows) │

│ OpenClaw + MiniMax │

│ Socket Client │

└─────────────────────────────────────────────────────────────┘

│

Feishu API

│

▼

┌─────────────────────────────────────────────────────────────┐

│ Node-C (Leo) │

│ 决策者/确认者 │

│ 微信/飞书 │

└─────────────────────────────────────────────────────────────┘

2.3 通讯协议设计原则

1. 简单性：协议设计尽量简单，降低实现复杂度

2. 可靠性：通过确认机制确保消息可靠送达

3. 可扩展性：支持未来增加新的节点类型

4. 编码统一：统一使用UTF-8编码，避免中文乱码

3. 通讯协议设计

3.1 消息格式

采用JSON作为消息格式，具有良好的可读性和跨语言支持。

请求消息格式（发起方 → 接收方）：

{

"from": "Node-A",

"to": "Node-B",

"sequence": "mesg001",

"message": "查询深圳明天天气",

"timestamp": "2026-04-10 22:00:00"

}

响应消息格式（接收方 → 发起方）：

{

"from": "Node-B",

"to": "Node-A",

"sequence": "mesg001",

"status": "completed",

"result": "深圳明天多云，25-28°C",

"timestamp": "2026-04-10 22:05:00"

}

3.2 字段说明

字段名	类型	必填	说明
from	string	是	发送方节点名称
to	string	是	接收方节点名称
sequence	string	是	消息序号，格式为"mesgXXX"
message	string	是	消息内容
status	string	否	响应状态：completed/pending/failed
result	string	否	执行结果或错误信息
timestamp	string	否	消息时间戳

3.3 消息状态机

状态	定义	触发条件
unread_unprocessed	未读未处理	Socket接收到新消息
read_unprocessed	已读未处理	消息已被读取，待通知协调者
pending	等待确认	已通知协调者，等待回复
executing	执行中	协调者已确认，正在执行任务
done	已完成	任务执行完成或协调者拒绝执行

4. 跨平台实现方案

4.1 Socket服务器实现（Node-A / Linux）

#!/usr/bin/env python3

# -*- coding: utf-8 -*-

"""

跨平台Socket服务器

监听5555端口，接收来自其他OpenClaw的消息

"""

import socket

import threading

import json

from datetime import datetime

HOST = '0.0.0.0'

PORT = 5555

def get_timestamp():

return datetime.now().strftime('%Y-%m-%d %H:%M:%S')

def handle_client(conn, addr):

print(f"[{get_timestamp()}] 连接来自: {addr}")

try:

data = b''

while True:

chunk = conn.recv(4096)

if not chunk:

break

data += chunk

if len(chunk) < 4096:

break

message = data.decode('utf-8', errors='ignore')

print(f"[{get_timestamp()}] 收到消息: {message[:100]}...")

response = process_and_generate_response(message)

conn.sendall(response.encode('utf-8'))

except Exception as e:

print(f"[{get_timestamp()}] 处理错误: {e}")

finally:

conn.close()

print(f"[{get_timestamp()}] 连接关闭: {addr}")

def process_and_generate_response(message):

response = {

"from": "Node-A",

"to": "Node-B",

"sequence": "ACK",

"status": "received",

"result": "Message received",

"timestamp": get_timestamp()

}

return json.dumps(response, ensure_ascii=False)

def start_server():

server = socket.socket(socket.AF_INET, socket.SOCK_STREAM)

server.setsockopt(socket.SOL_SOCKET, socket.SO_REUSEADDR, 1)

server.bind((HOST, PORT))

server.listen(5)

print(f"[{get_timestamp()}] Socket服务器启动，监听 {HOST}:{PORT}")

while True:

conn, addr = server.accept()

thread = threading.Thread(target=handle_client, args=(conn, addr))

thread.daemon = True

thread.start()

if __name__ == '__main__':

start_server()

4.2 Socket客户端实现（Node-B / Windows）

import socket

import json

from datetime import datetime

def send_message(host, port, message, sequence):

client = socket.socket(socket.AF_INET, socket.SOCK_STREAM)

client.connect((host, port))

data = {

"from": "Node-B",

"to": "Node-A",

"sequence": sequence,

"message": message,

"timestamp": datetime.now().strftime('%Y-%m-%d %H:%M:%S')

}

json_str = json.dumps(data, ensure_ascii=False)

client.sendall(json_str.encode('utf-8'))

response = client.recv(4096)

response_data = json.loads(response.decode('utf-8'))

client.close()

return response_data

result = send_message("192.168.4.251", 5555, "查询天气", "mesg001")

4.3 关键实现细节

4.3.1 编码处理

# 发送时确保UTF-8编码

json_str = json.dumps(data, ensure_ascii=False)

client.sendall(json_str.encode('utf-8'))

# 接收时处理编码问题

data = conn.recv(4096)

text = data.decode('utf-8', errors='ignore')

4.3.2 并发处理

# 每个连接一个线程，避免阻塞

def handle_client(conn, addr):

thread = threading.Thread(target=handle_client, args=(conn, addr))

thread.daemon = True

thread.start()

4.3.3 心跳机制

import subprocess

def trigger_heartbeat(notification_text):

openclaw_cmd = r'C:\Users\DFET\AppData\Roaming\npm\openclaw.cmd'

subprocess.Popen(

['cmd', '/c', openclaw_cmd, 'system', 'event', '--text', notification_text],

stdout=subprocess.DEVNULL,

stderr=subprocess.DEVNULL

)

5. 协作流程设计

5.1 标准协作流程（14步）

阶段一：消息接收与确认（Node-A视角）

步骤	执行者	动作	说明
1	Socket	接收JSON消息	解析from、to、sequence、message
2	Socket	保存消息文件	覆盖式写入message_from_xxx.txt
3	Socket	清空触发标记	写入notification_queue.txt
4	Socket	记录处理日志	追加到temp_processing_log.txt
5	Socket	触发heartbeat	唤醒OpenClaw主session
6	Socket	回复发送方	"Message received. Notified..."

阶段二：任务执行与反馈（Node-B视角）

步骤	执行者	动作	说明
7	OpenClaw	读取处理日志	按序号降序处理（LIFO）
8	OpenClaw	更新消息状态	unread → read_unprocessed
9	OpenClaw	通知协调者	飞书/微信发送确认请求
10	OpenClaw	等待确认	暂停处理，直到收到回复
11	OpenClaw	执行任务	调用相应skill
12	OpenClaw	回复发送方	通过Socket发送结果
13	OpenClaw	告知协调者	执行结果反馈
14	OpenClaw	更新日志状态	read → done

6. 状态管理机制

6.1 重复消息处理

判断标准：3秒内消息内容一致（忽略sequence号）

判断逻辑：

IF 存在相同内容 AND 时间差 < 3秒 AND 状态为done
THEN 判定为重复消息，跳过处理
ELSE 按正常流程处理

7. 错误处理机制

7.1 错误类型与处理策略

错误类型	发生阶段	处理策略
文件读取失败	任一阶段	记录到debug_log.txt，跳过该消息
Socket发送失败	任意	重试3次，标记error，通知协调者
协调者超时未回复	等待确认	10分钟后重新通知
任务执行失败	执行阶段	返回failed状态及错误信息
连接异常断开	任意	关闭连接，记录日志

8. 安全考虑

8.1 网络安全

1. 防火墙隔离：只开放必要的5555端口

2. IP白名单：只允许已知IP连接

3. 内网通信：所有节点在同一局域网内

8.2 操作安全

1. 人工确认：所有操作需协调者确认

2. 操作日志：所有操作记录可追溯

3. 状态验证：执行前验证状态正确性

9. 实际应用案例

9.1 天气查询

场景：Node-B需要查询深圳明天天气

Node-B → Node-A: "查询深圳明天天气"

Node-A → Leo: "Node-B请求查询天气，确认执行？"

Leo → Node-A: "确认执行"

Node-A → Node-B: "深圳明天多云，25-28°C"

10. 总结与展望

10.1 方案优势

1. 跨平台：支持Linux、Windows等多种操作系统

2. 跨模型：不依赖特定大模型，可灵活替换

3. 高可靠：完善的确认机制和错误处理

4. 易扩展：新增节点只需适配Socket接口

5. 可追溯：完整的日志记录和状态管理

10.2 局限性

1. 实时性：依赖协调者确认，不适合超低延迟场景

2. 复杂性：14步流程较复杂，可适当简化

3. 单点故障：协调者宕机会导致流程中断

10.3 未来改进方向

1. 并行确认：支持多个协调者同时确认

2. 自动决策：对于简单任务，可配置自动执行

3. 监控告警：增加更完善的状态监控和告警机制

4. Web界面：提供可视化的消息监控和管理界面

修订历史

版本	日期	作者	说明
v1.0	2026-04-10	David, Walt, Leo	初始版本，经过三方审核确认

本文档由David、Walt和Leo共同审核通过