基于HTTP API与加密隧道实现本地OpenClaw多智能体安全通信

1. 项目概述：为本地OpenClaw智能体搭建专属通信网络

如果你和我一样，在几台不同的电脑上部署了OpenClaw智能体，比如一台主力台式机叫“Spock”，一台笔记本叫“Scotty”，你肯定想过：它们能不能直接对话？比如，让Spock直接问Scotty：“嘿，你那边CPU温度多少？”或者把一个大任务拆开，让Scotty异步处理，处理完再通知Spock。这听起来像是科幻片里的场景，但在本地局域网里实现它，其实并不需要复杂的消息队列或中心服务器。这正是LobsterLAN这个项目要解决的问题——它是一套轻量级的协调层，让运行在同一个局域网内的OpenClaw智能体能够安全、直接地相互通信。

LobsterLAN的核心思路非常巧妙：它没有重新发明轮子，而是完全复用OpenClaw网关自身就提供的HTTP API。OpenClaw的网关在启动时，默认会暴露两个关键的HTTP端点：一个是用于同步问答的/v1/chat/completions，另一个是用于接收异步任务或Webhook的/hooks/agent。LobsterLAN所做的，就是提供一个“技能”和一个配套的脚本，让一个智能体能够以标准化的方式，通过HTTP请求去调用另一个智能体的这些API，从而完成问询、任务委派和结果回调这一整套流程。

这个项目的价值在于它的“直接”和“无侵入”。你不需要部署额外的RabbitMQ、Redis或者任何自定义的TCP服务。整个通信建立在现有的、经过验证的OpenClaw网关协议之上。对于家庭实验室、小型工作室或者任何想在多台设备间构建智能体协作网络的人来说，LobsterLAN提供了一个极其简洁的起点。它把复杂的分布式智能体通信，简化成了配置文件和几条脚本命令。

2. 核心设计思路与安全模型拆解

2.1 为什么选择HTTP API而非自定义协议？

在构思多智能体通信时，我们面临几个基础选择：自定义二进制协议、基于Socket的消息传递，或者利用现有的HTTP/REST API。LobsterLAN选择了最后一种，这背后有非常务实的考量。

首先，降低开发和维护成本。OpenClaw网关本身就是一个成熟的HTTP服务器，它已经处理了请求路由、身份验证、日志记录等繁琐工作。直接复用它的API，意味着LobsterLAN无需自己实现一套通信协议，避免了协议设计、序列化/反序列化、连接保活等一系列难题。我们只需要关心“如何安全地访问另一个网关的HTTP端口”这一个问题。

其次，保持与上游生态的兼容性。OpenClaw的/v1/chat/completions接口在设计上兼容OpenAI API格式。这意味着，未来如果OpenClaw社区或官方推出了新的工具或客户端，只要它们能调用这个标准接口，理论上就能与LobsterLAN网络中的智能体交互，扩展性很好。

最后，调试和问题排查极其方便。HTTP协议是透明的，我们可以用最通用的工具如curl、httpie或者浏览器开发者工具来手动测试请求和响应。如果通信出现问题，排查链路清晰：是网络不通？端口没开？还是身份验证失败？每一步都可以用标准HTTP调试方法验证，这对于一个旨在简化部署的项目来说至关重要。

2.2 深入理解OpenClaw网关的“绑定”限制与安全考量

这是LobsterLAN设计中最关键也最容易踩坑的一点。OpenClaw网关在配置文件中有一个bind参数，通常默认为127.0.0.1:端口号，也就是只绑定到本地回环地址。如果你尝试将其改为0.0.0.0:端口号或具体的局域网IP，希望让其他机器访问，网关很可能会直接拒绝启动，并给出一个关于TLS的警告。

这个看似“不近人情”的设计，其实是OpenClaw团队一个非常负责任的安全决策。当网关监听在所有网络接口上时，它传输的所有数据——包括你的API密钥（Bearer Token）、智能体与模型的对话内容、可能的敏感指令——都会以明文形式在网络上传输。在家庭局域网内，风险或许相对可控，但在任何存在潜在嗅探风险的环境（如公共Wi-Fi、公司内网），这无疑是巨大的安全隐患。

因此，LobsterLAN没有鼓励你去修改网关的bind配置（尽管技术上可行），而是提出了一个更优解：让网关继续保持只监听127.0.0.1，然后通过一个安全的加密隧道，将本地端口“映射”或“暴露”到网络上的其他机器。这样，网关自身认为它只在和本机的一个客户端通信，但实际上这个客户端是一个隧道代理，负责将远端的请求加密后转发过来。这个模型在保证数据安全的同时，完美解决了跨机访问的问题。

2.3 三层纵深防御安全模型解析

LobsterLAN文档中提到的三层安全模型，是构建可信局域网通信的经典实践。我们来逐层拆解其作用和配置方法。

第一层：网络层隔离这是最基础的一层。我们的目标是让OpenClaw网关的通信端口（例如默认的11434）仅在局域网内可达，且绝对不暴露到公网。实现方法主要依靠防火墙规则。

• 在Linux上（使用ufw）：你可以设置规则，只允许来自局域网网段（如192.168.1.0/24）的流量访问网关端口，同时明确拒绝来自WAN（外网）的访问。
• 在路由器上：更彻底的做法是在家庭路由器的防火墙设置中，禁止从外网向内的11434端口连接。对于家庭网络，这通常是默认安全的，但如果你做了端口转发，则需要特别注意。 这一层的目的是将攻击面缩小到你信任的本地网络环境。

第二层：网关身份验证这是核心的认证层。OpenClaw网关强制要求每个HTTP请求都必须携带一个有效的Bearer Token（承载令牌）。这个令牌是在启动OpenClaw时配置的，通常保存在环境变量或配置文件中。

• 工作原理：当Agent A（Spock）想要调用Agent B（Scotty）的API时，它必须在HTTP请求的Header中加上：Authorization: Bearer YOUR_SCOTTY_GATEWAY_TOKEN。
• 重要性：即使有人偶然发现了你网关的IP和端口（比如同一局域网下的其他设备），如果没有这个令牌，他们也无法进行任何有效操作。这相当于给你的网关服务加了一把锁。
• 实操注意：务必为每个智能体网关使用不同且强的令牌。切勿在多个智能体间共享同一个令牌，否则一个节点被攻破会导致全军覆没。

第三层：智能体身份验证（可选）这是一个额外的、防御纵深的措施。除了验证请求是否来自一个“知道令牌的客户端”，你还可以进一步验证这个客户端是不是你认可的“那个特定的智能体”。

• 实现方式：这通常通过在HTTP请求中增加一个自定义Header来实现，例如X-Agent-ID: spock。在接收方（Scotty的网关）处，可以配置一个简单的中间件或检查逻辑，验证这个ID是否在自己的“可信智能体白名单”内。
• 适用场景：这一层在纯粹的、物理隔离的家庭局域网中可能略显冗余，因为第二层的令牌已经足够强。但在一些稍复杂的场景下很有用，例如：
  1. 你的局域网内还有其他服务或设备，它们可能因为某些原因也需要使用同一个网关令牌（不推荐但可能发生），此时用Agent ID可以区分调用者。
  2. 你未来可能将隧道扩展到Tailscale等虚拟组网中，网络边界变得模糊，增加一层应用层身份验证可以提供额外保障。 LobsterLAN将其列为可选，体现了务实的设计：在安全性和复杂度之间取得平衡，让用户根据自身风险评估来决定是否启用。

3. 三种网络传输方案详解与选型指南

LobsterLAN推荐了三种主流的加密隧道方案，每种都有其适用的场景和配置复杂度。理解它们的区别，能帮助你做出最适合自己环境的选择。

3.1 SSH隧道方案：简单直接的加密通道

SSH隧道是Linux/macOS环境下最经典、最轻量的端口转发工具。它利用现有的SSH连接，在本地和远程主机之间创建一个加密的通道。

工作原理： 假设Scotty运行在192.168.1.3，其OpenClaw网关监听在127.0.0.1:11434。我们在运行Spock的机器（192.168.1.2）上执行以下命令：

ssh -N -L 11435:127.0.0.1:11434 user@192.168.1.3

这个命令的意思是：“通过SSH连接到192.168.1.3，然后在我本地（Spock）的11435端口和远程主机（Scotty）本地的11434端口之间，建立一个加密隧道。”

配置步骤与要点：

1. 确保SSH免密登录：这是实现自动化的关键。在Spock上生成SSH密钥对（如果还没有）：ssh-keygen -t ed25519。然后将公钥（~/.ssh/id_ed25519.pub）的内容，添加到Scotty服务器的~/.ssh/authorized_keys文件中。之后Spock SSH到Scotty就不再需要输入密码。
2. 建立隧道：执行上面的ssh -N -L ...命令。-N参数表示“不执行远程命令”，只建立隧道；-L表示本地端口转发。
3. 测试连接：现在，在Spock上，你可以通过访问http://127.0.0.1:11435来间接访问Scotty的网关服务了。你可以用curl测试：curl http://127.0.0.1:11435/v1/models -H "Authorization: Bearer YOUR_SCOTTY_TOKEN"。
4. 后台运行与保活：为了让隧道在后台持续运行，可以使用-f参数让SSH后台运行，或者更推荐使用systemd服务或autossh工具来监控和重启隧道，防止因网络波动中断。

优点：

• 极简：几乎任何Linux/macOS系统都自带SSH，无需安装额外软件。
• 安全：SSH协议本身提供强加密和身份验证。
• 灵活：可以轻松转发多个端口。

缺点：

• 需要SSH访问权限：你必须在目标机器上有用户账户和SSH登录权限。
• Windows原生支持稍弱：虽然Windows 10/11有OpenSSH客户端，但配置体验可能不如Linux顺畅。
• 隧道管理：需要额外工具（如autossh）来确保高可用。

实操心得：对于家庭内两台Linux服务器之间的通信，SSH隧道是我的首选。它的开销极小，而且概念清晰。我通常会为每个隧道创建一个简单的systemd service文件，设置自动重启，这样就不用担心重启后隧道消失。

3.2 反向代理方案：面向Web服务的标准做法

如果你对Web服务器比较熟悉，或者环境中已经运行了Nginx、Caddy这样的反向代理，那么这套方案会非常顺手。它的核心思想是：在Scotty上运行一个反向代理服务器，这个服务器对外（局域网）提供HTTPS服务，并将收到的请求解密后转发给本地的OpenClaw网关。

以Caddy为例的配置流程： Caddy以其自动HTTPS证书管理而闻名，在局域网内我们也可以利用它生成自签名证书或使用私有CA证书。

1. 安装Caddy：在Scotty上安装Caddy服务器。
2. 准备域名或IP：你需要一个在局域网内可解析的地址。可以是Scotty的局域网IP（192.168.1.3），也可以是在本地DNS或路由器hosts文件中设置的域名（如scotty.local）。
3. 配置Caddyfile：

   # Caddyfile 内容 scotty.local:11434 { tls internal // 使用Caddy自动生成的内置CA证书，浏览器会警告但curl可跳过验证 # 或者使用自己生成的证书 # tls /path/to/cert.pem /path/to/key.pem reverse_proxy 127.0.0.1:11434 { header_up Authorization {http.request.header.Authorization} // 传递认证头 } }

4. 启动Caddy：caddy run --config ./Caddyfile。
5. 客户端配置：现在，Spock就可以通过https://scotty.local:11434来访问Scotty的网关。注意是https。使用curl时，如果用了自签名证书，需要加上-k或--insecure参数来跳过证书验证（仅限可信内网环境）。

优点：

• 标准：完全符合HTTPS Web服务规范，任何HTTP客户端都能轻松调用。
• 功能强大：反向代理可以提供负载均衡、访问日志、速率限制、请求改写等高级功能。
• 易于集成：如果你的其他服务也通过反向代理暴露，那么管理起来风格统一。

缺点：

• 配置稍复杂：需要设置和维护反向代理服务器和TLS证书。
• 证书管理：在纯局域网内，需要处理自签名证书的信任问题，否则客户端会报证书错误。

3.3 Tailscale Serve方案：跨越网络边界的魔法

Tailscale是一个基于WireGuard的零配置组网工具。它能为你的所有设备创建一个安全的虚拟局域网，即使它们不在同一个物理网络下（比如一台在家，一台在公司）。Tailscale Serve是它的一个功能，允许你将设备上的本地服务安全地暴露给Tailscale网络中的其他设备。

工作原理：

1. 在Spock和Scotty两台机器上都安装并登录同一个Tailscale账户。
2. 在Scotty上，使用tailscale serve命令将本地的127.0.0.1:11434服务暴露出去。
3. Tailscale会为Scotty分配一个唯一的MagicDNS域名（如scotty.tailnet-name.ts.net）。
4. 在Spock上，你可以直接通过这个域名访问Scotty的服务，就像在同一个局域网一样。所有流量都经过Tailscale加密。

配置简述：

# 在Scotty上 sudo tailscale serve --bg 11434 http://127.0.0.1:11434 # 查看服务状态和地址 tailscale status

之后，Spock就可以用curl https://scotty.your-tailnet.ts.net:11434/...进行访问。

优点：

• 穿透NAT与防火墙：无需配置路由器端口转发，设备在任何网络下都能互联。
• 极致安全：Tailscale使用端到端加密，并内置了基于SSO的强身份验证。
• 零配置网络：无需手动管理IP地址，使用域名访问，非常方便。

缺点：

• 依赖第三方服务：虽然流量是点对点加密的，但协调服务器（DERP）由Tailscale公司提供（有开源自部署方案）。
• 性能：如果两点之间无法直接点对点连接，会通过中继服务器转发，可能增加延迟。

选型建议总结：

• 家庭局域网，两台Linux/ macOS设备：首选SSH隧道，简单粗暴有效。
• 已有Web运维经验，或需要更规范的Web接口：选择反向代理（Caddy），便于统一管理。
• 设备位于不同物理网络（如家庭+公司），或不想折腾局域网配置：选择Tailscale Serve，体验无缝互联。

4. LobsterLAN技能安装与对等节点配置实战

理解了原理和网络方案后，我们进入实操环节。LobsterLAN的核心是一个OpenClaw技能和一个Shell脚本。

4.1 技能安装与结构解析

安装技能最推荐的方式是使用OpenClaw的clawhub（如果已集成）：

clawhub install lobsterlan

如果clawhub不可用，或者你想手动检查，可以采用手动安装：

# 1. 找到你的OpenClaw技能目录，通常是 ~/.openclaw/workspace/skills/ SKILLS_DIR="$HOME/.openclaw/workspace/skills" # 2. 克隆或复制LobsterLAN技能仓库 git clone https://github.com/danielithomas/lobsterlan.git cp -r lobsterlan/skill/ "$SKILLS_DIR/lobsterlan" # 3. 确保技能目录结构正确 ls -la "$SKILLS_DIR/lobsterlan/" # 你应该能看到 SKILL.md 等文件

安装完成后，技能目录的结构大致如下：

lobsterlan/ ├── SKILL.md # 技能元数据描述文件 ├── config/ # 配置相关（可能包含示例） ├── scripts/ # 核心脚本目录 │ └── lobsterlan.sh # 通信的CLI封装脚本 └── ... # 其他资源文件

这个技能本身并不运行常驻服务，它主要是提供了lobsterlan.sh这个工具脚本，以及相关的配置范例。智能体在需要与其他节点通信时，会调用这个脚本。

4.2 核心脚本lobsterlan.sh工作机制

lobsterlan.sh是整个项目的“粘合剂”。它是一个Bash Shell脚本，主要做了以下几件事：

1. 解析参数：接收目标智能体名称、要发送的消息或任务指令。
2. 加载配置：读取一个配置文件（如peers.json），根据目标智能体名称找到其对应的访问地址（URL）和网关令牌（Token）。这个地址就是前面通过SSH隧道、反向代理或Tailscale暴露出来的HTTPS/HTTP端点。
3. 构造HTTP请求：根据调用模式（同步ask或异步delegate），构造相应的HTTP请求到目标地址，并附上正确的Authorization Header。
4. 处理响应：接收响应，并以适合OpenClaw技能处理的方式输出结果。

一个简化的调用示例可能是：

# 在Spock智能体的上下文中执行 ./lobsterlan.sh ask scotty "What is your current CPU usage?"

脚本内部会查找scotty的配置，然后向https://scotty.local:11434/v1/chat/completions发送一个POST请求，Body中包含问题，Header中携带Scotty的网关Token。

4.3 对等节点配置文件详解

配置是让一切运转起来的关键。你需要在每个智能体上维护一份peers.json文件，用来记录“伙伴”们的信息。

一个典型的peers.json结构如下：

{ "peers": { "scotty": { "url": "https://192.168.1.3:11434", "token": "sk-your-scotty-gateway-token-here", "agent_id": "scotty" }, "spock": { "url": "https://192.168.1.2:11434", "token": "sk-your-spock-gateway-token-here", "agent_id": "spock" } }, "self_id": "spock" // 当前智能体自身的ID }

配置项解读：

• url：这是其他智能体网关的访问地址。根据你选择的网络方案，它可能是：
  • SSH隧道：http://127.0.0.1:11435(本地转发端口)
  • 反向代理：https://scotty.local:11434
  • Tailscale:https://scotty.your-tailnet.ts.net:11434
• token：其他智能体网关的Bearer Token。切记，这里存放的是别人的令牌，用于你去调用别人。
• agent_id：一个可读的标识符，用于可选的身份验证层。
• self_id：当前智能体自己的ID。当其他智能体回调它时，可以用来验证身份。

重要安全提醒：这个peers.json文件包含了所有对等节点的敏感令牌！你必须将其视为机密文件，设置严格的文件权限（如chmod 600 peers.json），并确保它不会被意外提交到公开的版本控制系统（务必将其加入.gitignore）。

4.4 双机互连配置全流程演示

假设我们有两台机器：

• Spock: IP192.168.1.2, 主机名spock
• Scotty: IP192.168.1.3, 主机名scotty

我们选择SSH隧道方案，因为它最简单。目标是让Spock和Scotty能互相调用。

步骤一：在双方机器上安装并配置OpenClaw确保Spock和Scotty都正确安装了OpenClaw，网关服务正常运行在127.0.0.1:11434，并且你记下了各自的网关启动令牌（假设为token_spock和token_scotty）。

步骤二：建立双向SSH隧道

1. 从Spock连接到Scotty的隧道（让Spock能访问Scotty）： 在Spock上执行：

   ssh -N -L 11435:127.0.0.1:11434 user@192.168.1.3

   现在，Spock本地的11435端口映射到了Scotty的网关。
2. 从Scotty连接到Spock的隧道（让Scotty能访问Spock）： 在Scotty上执行：

   ssh -N -L 11435:127.0.0.1:11434 user@192.168.1.2

   现在，Scotty本地的11435端口映射到了Spock的网关。注意：两边都用了本地端口11435来转发，这只是为了示例一致，你可以使用任何未被占用的高端口。

步骤三：编写各自的peers.json配置

• 在Spock上(~/.openclaw/workspace/skills/lobsterlan/config/peers.json):

  { "peers": { "scotty": { "url": "http://127.0.0.1:11435", "token": "token_scotty", "agent_id": "scotty" } }, "self_id": "spock" }

  Spock的配置中，scotty.url指向它本地用于转发到Scotty的端口。

• 在Scotty上(~/.openclaw/workspace/skills/lobsterlan/config/peers.json):

  { "peers": { "spock": { "url": "http://127.0.0.1:11435", "token": "token_spock", "agent_id": "spock" } }, "self_id": "scotty" }

  Scotty的配置中，spock.url指向它本地用于转发到Spock的端口。

步骤四：测试通信配置完成后，你可以在OpenClaw的对话中，通过LobsterLAN技能提供的指令进行测试。例如，在Spock的聊天界面输入：

@lobsterlan ask scotty "Hello, can you hear me?"

如果一切正常，Spock会通过脚本调用本地的11435端口（即SSH隧道），请求被加密转发到Scotty的网关，Scotty处理请求后，响应再通过隧道传回给Spock。你将在Spock的聊天窗口中看到Scotty的回复。

5. 高级应用模式与故障排查手册

5.1 同步问答与异步任务委派实战

LobsterLAN支持两种核心交互模式，对应OpenClaw网关的两个不同API端点。

同步问答模式这是最直接的交互。智能体A向智能体B发送一个查询，并等待B的即时回复。

• 底层调用：POST /v1/chat/completions
• 使用场景：询问状态、获取即时信息、执行一个快速的计算或查询。
• 技能调用示例：

  User> @lobsterlan ask scotty "What is the current free disk space on your primary drive?" Spock> [调用 lobsterlan.sh ask scotty ...] Scotty> [处理请求，返回结果] "The free disk space is 256 GB."

• 技术细节：脚本会构造一个符合OpenAI格式的聊天补全请求，发送到对等节点的/v1/chat/completions端点。响应是标准的OpenAI API响应，包含模型生成的内容。

异步任务委派模式这种模式更强大，用于处理耗时较长的任务。智能体A将一个任务“扔给”智能体B，然后自己可以继续做别的事情。当B完成任务后，通过一个“回调Webhook”主动通知A。

• 底层调用：POST /hooks/agent
• 使用场景：生成大量图片、运行一个长时间的数据处理脚本、下载大文件等。
• 工作流程：
  1. 委派：Spock调用lobsterlan.sh delegate scotty "Generate 10 images of a sunset..."。这个请求会发送到Scotty的/hooks/agent端点。
  2. 处理：Scotty的网关收到这个Webhook请求，将其作为一个任务放入处理队列（具体取决于OpenClaw的配置和技能）。Scotty开始异步生成图片。
  3. 回调：当Scotty完成任务后，它需要通知Spock。此时，Scotty会向Spock的/hooks/agent端点发起一个POST请求，请求体中包含任务结果。这里的关键是，Scotty如何知道Spock的回调地址？这通常需要在初始的委派请求中，由Spock明确地将自己的回调地址（如http://spock.local:11434/hooks/agent）作为一个参数传递给Scotty。LobsterLAN的脚本和技能应该处理这个逻辑。
  4. 接收：Spock的网关收到来自Scotty的回调Webhook，触发相应的处理逻辑（例如，通知用户任务完成，或保存生成好的图片链接）。
• 配置要点：异步模式要求双向隧道必须建立。不仅Spock要能访问Scotty，Scotty也必须能访问Spock，以便进行结果回调。

5.2 构建多智能体协作工作流

有了双向通信能力，你可以设计更复杂的工作流。例如，一个“管理者”智能体协调多个“工作者”智能体。

1. 任务分发：管理者（Spock）收到一个复杂请求，如“分析这组数据并生成报告”。它将数据拆分成N份。
2. 并行委派：Spock使用异步委派模式，将N个子任务分别发送给Scotty、McCoy等工作者智能体。
3. 结果聚合：每个工作者完成自己的部分后，通过回调Webhook将结果发回给Spock。
4. 汇总报告：Spock收集齐所有结果后，进行汇总，生成最终报告回复给用户。

这种模式充分利用了多台机器的计算资源，实现了简单的分布式处理。

5.3 常见问题与排查技巧实录

即使按照指南操作，也可能会遇到问题。下面是一些常见坑点及其解决方法。

问题1：lobsterlan.sh脚本执行失败，报错“命令未找到”或“权限被拒绝”。

• 原因：脚本没有执行权限，或者技能路径不正确。
• 排查：
  1. 检查脚本路径：ls -la ~/.openclaw/workspace/skills/lobsterlan/scripts/lobsterlan.sh
  2. 添加执行权限：chmod +x ~/.openclaw/workspace/skills/lobsterlan/scripts/lobsterlan.sh
  3. 在OpenClaw的技能配置中，确保它知道如何找到这个脚本。可能需要检查SKILL.md中的command或script配置项。

问题2：通信测试时，返回Connection refused或Failed to connect。

• 原因：网络隧道未建立或配置的URL错误。
• 排查：
  1. 检查隧道进程：在请求发起方，运行ss -tlnp | grep 11435（或你使用的本地转发端口），查看端口是否处于监听状态。
  2. 手动测试隧道：在Shell中直接用curl测试隧道是否通畅。例如，在Spock上：curl -v http://127.0.0.1:11435/v1/models -H "Authorization: Bearer token_scotty"。如果失败，检查SSH隧道命令是否正确，以及远程主机的SSH服务是否运行。
  3. 检查对端网关：在任务执行方（如Scotty），确认OpenClaw网关进程正在运行并监听正确端口：sudo netstat -tlnp | grep 11434。

问题3：请求返回401 Unauthorized。

• 原因：Bearer Token不正确或缺失。
• 排查：
  1. 仔细核对peers.json中配置的token是否与对端OpenClaw网关启动时使用的令牌完全一致。注意大小写和特殊字符。
  2. 在手动curl测试时，确保-H "Authorization: Bearer <token>"头设置正确。
  3. 确认对端网关是否启用了身份验证（通常默认是启用的）。

问题4：异步委派任务后，从未收到回调。

• 原因：回调路径不通，或任务执行方没有正确触发回调。
• 排查：
  1. 检查反向隧道：确保从任务执行方（Scotty）到任务发起方（Spock）的隧道也是通的。在Scotty上curl测试Spock的网关地址。
  2. 检查回调地址：确认在委派请求中，传递给Scotty的回调URL是准确的，并且是Scotty能够访问的地址（通常是Spock的隧道地址或反向代理地址）。
  3. 查看日志：检查Spock和Scotty两边的OpenClaw网关日志，看是否有Webhook请求的接收和处理记录。日志通常会提供详细的错误信息。

问题5：使用HTTPS（反向代理/Tailscale）时，curl报证书错误。

• 原因：客户端不信任自签名证书。
• 解决：
  • 临时测试：在curl命令后加-k或--insecure参数跳过证书验证。
  • 长期方案：将反向代理使用的自签名证书的CA根证书，导入到客户端的系统或curl的信任库中。对于Caddy的internal证书，可以在Caddy的数据目录找到CA证书。对于Tailscale，其证书是自动受信的。

问题6：SSH隧道经常断开。

• 原因：SSH连接因网络不稳定或超时而断开。
• 解决：使用autossh工具替代普通的ssh命令。autossh会自动监控连接状态并在断开时重连。

  autossh -M 0 -o "ServerAliveInterval 30" -o "ServerAliveCountMax 3" -N -L 11435:127.0.0.1:11434 user@192.168.1.3

  还可以将上述命令写入systemd服务文件，实现开机自启和自动管理。

一个高效的排查流程： 当通信失败时，建议按照以下层次逐级排查，从底层到上层：

1. 物理/网络层：两台机器能ping通吗？(ping 192.168.1.3)
2. 隧道层：SSH隧道进程还在吗？手动curl隧道端口通吗？
3. 服务层：对端的OpenClaw网关进程在运行吗？(systemctl status openclaw-gateway或ps aux | grep openclaw)
4. 认证层：使用正确的令牌手动调用API能成功吗？（用curl带Token测试）
5. 应用层：peers.json配置文件的路径和内容正确吗？lobsterlan.sh脚本有权限且能正确解析配置吗？

通过这样系统性地排查，绝大多数问题都能被定位和解决。记住，耐心和细致的日志是你的最佳伙伴。