本地 AI Agent 的价值，不只在于能够回答问题，更在于它可以直接接触本机环境：读取工作目录、生成文件、调用本地工具、整理资料、执行批量操作。相比完全运行在云端的聊天机器人，本地 Agent 更像是桌面系统里的一个可控助手。
不过，本地运行也带来一个现实问题：如果只能在电脑前通过浏览器访问，它的使用范围仍然受到限制。为了让本地 Agent 能够在手机上随时使用，可以将本机服务通过安全的方式暴露到公网域名，并进一步接入聊天平台。这样一来，手机上的普通消息窗口就可以成为本地 Agent 的控制入口。
这次实践完成的目标，是将一套安装在 Linux 桌面环境中的 OpenClaw，从单机本地访问，扩展为可以通过 HTTPS 域名访问，并最终接入 LINE Messaging API，实现手机 LINE 与本机 OpenClaw 的直接对话。
一、本地服务从回环地址调整为局域网可访问
最初，OpenClaw Gateway 只面向本机访问。这种方式适合纯桌面使用，但反向代理服务器无法从局域网访问该服务。
因此第一步是调整 Gateway 的监听方式，让它从本机回环地址改为局域网可访问。调整后，OpenClaw Gateway 可以监听在所有网卡地址上，局域网内其他主机便能够访问该端口。
同时，Gateway 启用了内置的密码认证。这里没有把认证放在反向代理层，而是让 OpenClaw 自己负责登录与设备配对。这样做的好处是认证逻辑更集中，也更符合 OpenClaw 自身的设计。
整体思路是：
本机 OpenClaw Gateway
从仅本机访问
调整为局域网可访问
认证方式
由 OpenClaw 自身负责
使用 password + device pairing
完成配置后，需要重启 OpenClaw Gateway，并确认服务已经监听在局域网地址上。随后还需要在本机防火墙中开放对应端口，使反向代理服务器可以正常连接。
二、通过反向代理提供 HTTPS 域名访问
本地 Gateway 可以被局域网访问后，下一步是在反向代理服务器上增加一个新的站点配置。
反向代理服务器负责处理公网 HTTPS 请求，并将请求转发到内网中的 OpenClaw Gateway。这样，外部访问者看到的是一个正常的 HTTPS 域名，而后端实际运行的仍然是桌面 Linux 主机上的本地 OpenClaw 服务。
反向代理需要支持：
HTTPS
WebSocket
长连接
流式响应
较长超时时间
这些对于 AI Agent 类应用非常重要。聊天响应、任务执行、浏览器控制、长时间操作等场景，都可能依赖 WebSocket 或长连接。如果代理层配置过于普通，前端可能出现连接中断、响应卡住、流式输出异常等问题。
本次配置中，反向代理只负责网络层职责：
TLS 证书
HTTPS 入口
域名转发
WebSocket 转发
长连接保持
没有在反向代理层增加 Basic Auth，也没有使用反向代理 header 伪造登录身份。最终的认证仍然由 OpenClaw Gateway 自己处理。
这种结构更加清晰：
浏览器
↓
HTTPS 域名
↓
反向代理服务器
↓
局域网内桌面主机
↓
OpenClaw Gateway
完成 nginx 配置后，通过配置测试和服务重载确认反向代理生效。随后访问 HTTPS 域名，能够看到 OpenClaw Gateway Dashboard，说明公网域名到本地 OpenClaw 的链路已经打通。
三、浏览器访问与设备授权
通过域名访问 OpenClaw 后，页面会要求输入 Gateway 密码。密码通过后，还需要进行设备授权。
OpenClaw 的 Control UI 并不是只靠一个密码长期登录，而是还会生成一个 device pairing request。用户需要在本机终端中批准该设备，浏览器才能成为已授权设备。
这个机制很适合远程访问场景。即使知道了入口地址，也不能仅凭打开页面就直接获得完整控制权。浏览器设备需要经过本机终端批准，才会成为 operator。
实际流程是：
浏览器访问 HTTPS 域名
↓
输入 OpenClaw Gateway password
↓
页面生成 device pairing request
↓
本机终端批准 request
↓
浏览器成为已授权 Control UI 设备
后续整理授权记录时，可以通过设备列表查看当前已授权的浏览器和 CLI。浏览器设备通常显示为 Control UI 类型，终端则显示为 CLI 类型。
经过多次测试后，曾经出现过普通浏览器、隐私窗口、本地访问、旧标签页等多个授权记录。最终通过清理 paired devices 和 pending requests，将设备列表整理为更干净的状态：
保留 CLI 终端授权
保留一个公网浏览器授权
清理旧浏览器和隐私窗口授权
其中 CLI 授权用于后续管理和批准新设备，浏览器授权用于日常从网页访问 OpenClaw。
四、CLI 权限升级与设备列表整理
清空设备授权后，CLI 可能会以较低权限重新出现。例如，只具备 pairing 权限。在这种状态下，CLI 可以参与配对，但执行更高权限操作时会触发 scope upgrade。
当 CLI 尝试批准浏览器授权时，如果自身权限不足，OpenClaw 会生成一个 scope upgrade / repair 请求。批准该请求后，CLI 原来的设备记录不会新增一条，而是直接升级原有记录的权限。
这次实践中，CLI 设备最终被升级为具备管理所需权限的稳定记录。之后的维护原则变得非常明确：
最早的 CLI 记录保留
后续浏览器记录可以按需删除
不再随意清空全部授权
这个过程也说明，OpenClaw 的设备授权并不是简单的“登录会话列表”，而是带有角色、scope 和修复机制的设备信任体系。
五、安装并启用 LINE 插件
网页访问打通后，下一步是让手机聊天工具成为入口。
OpenClaw 本身支持通过插件扩展 channel。检查插件列表后，可以确认 LINE 插件已经安装并启用。随后需要确认该插件处于 loaded 状态，并提供 channel: line 能力。
LINE 插件可用后，还需要配置 channel：
启用 LINE channel
设置私聊策略为 pairing
配置 Channel Access Token
配置 Channel Secret
重启 Gateway
其中，私聊策略设置为 pairing 非常关键。它意味着陌生 LINE 用户即使添加了官方账号，也不能直接控制 OpenClaw。第一次发消息只会触发配对请求，必须在本机终端批准后，才会被视为可信发送者。
这比开放式聊天入口安全得多。
整体原则是：
LINE 可以作为入口
但不允许任何添加好友的人直接控制 Agent
必须经过本机批准
六、创建 LINE 官方账号与 Messaging API
OpenClaw 侧配置完成后，需要到 LINE 官方平台创建对应账号。
这一步包括：
创建 LINE Official Account
启用 Messaging API
取得 Channel Secret
生成 Channel Access Token
设置 Webhook URL
启用 Webhook
关闭自动回复
关闭欢迎语
Webhook URL 指向前面已经打通的 HTTPS 域名，并使用 LINE 插件对应的 webhook 路径。这样，LINE 平台收到手机发来的消息后，会把事件推送到 OpenClaw Gateway。
完整链路如下：
手机 LINE
↓
LINE Official Account
↓
LINE Messaging API
↓
Webhook URL
↓
HTTPS 反向代理
↓
OpenClaw Gateway
↓
LINE 插件
↓
OpenClaw Agent
LINE 官方账号后台还需要调整响应设置。对于这种由 OpenClaw 接管消息处理的账号，应关闭 LINE 官方账号自带的自动回复和欢迎语，只保留 webhook 开启。否则，LINE 官方后台的自动消息可能会与 OpenClaw 的回复混在一起。
最终设置应接近：
Webhook 开启
自动回复关闭
欢迎语关闭
人工聊天关闭或不使用
这样所有消息都交给 OpenClaw 处理。
七、手机添加好友与 LINE 配对
LINE 官方账号创建完成后，可以通过二维码或 Bot ID 添加好友。
手机添加该账号后，第一次发送消息时，OpenClaw 不会直接处理为有效控制指令，而是产生 LINE pairing request。此时需要在本机终端中查看 LINE 配对请求，并批准对应请求。
流程如下：
手机 LINE 添加官方账号
↓
发送第一条消息
↓
OpenClaw 产生 LINE pairing request
↓
本机终端查看 pairing request
↓
批准该 LINE 用户
↓
手机 LINE 开始正常对话
批准后，手机 LINE 就可以像网页 Control UI 一样与本机 OpenClaw 对话。实际测试中，手机端连续发送多条消息，OpenClaw 均能正常回复，效果与桌面浏览器访问基本一致。
八、LINE 授权与浏览器设备授权不是同一套
调试过程中有一个容易混淆的点：LINE 授权不会出现在浏览器设备列表中。
OpenClaw 的设备列表主要显示：
Control UI 浏览器
CLI 终端
而 LINE 属于 channel sender pairing，不属于 Control UI device pairing。因此，即使 LINE 已经可以正常收发消息，也不会在普通 devices list 中出现一条 LINE 设备。
查看 LINE pairing 时，如果没有 pending request，只表示当前没有等待批准的新 LINE 用户，不代表已经批准的 LINE 用户不存在。
这说明 OpenClaw 内部至少有两类不同授权概念：
devices
用于管理浏览器和 CLI 等设备授权
channel pairing
用于管理 LINE 等外部消息入口的发送者授权
因此，清空浏览器设备授权不会影响 LINE 已经建立的聊天能力。实际测试中，清空 devices 后，手机 LINE 仍然可以继续正常发消息和收消息，也验证了这两套机制彼此独立。
九、安全边界
将本地 Agent 接到公网域名和手机聊天工具后，安全边界必须清楚。
本次实践中的安全设计包括：
OpenClaw Gateway 使用 password 认证
浏览器访问需要 device pairing
LINE 私聊使用 pairing 策略
反向代理只做 HTTPS，不绕过 OpenClaw 认证
陌生 LINE 用户不会自动获得控制权
即使别人发现 LINE 官方账号二维码并添加好友，也不能直接控制 OpenClaw。因为 LINE 私聊策略是 pairing，陌生用户第一次发消息只会生成配对请求。只要本机终端不批准，对方就不会成为可信发送者。
同样，浏览器访问也不是只靠打开域名完成控制，还需要 password 和 device pairing。
对于个人使用场景来说，这种结构比直接开放本地服务要稳妥得多。
十、最终结构
最终系统形成了三个入口：
本机浏览器
用于本地访问和调试
公网浏览器
通过 HTTPS 域名访问 OpenClaw Control UI
手机 LINE
通过 LINE Messaging API 与 OpenClaw 对话
整体架构可以概括为：
桌面 Linux 主机运行 OpenClaw
↓
Gateway 监听局域网
↓
反向代理服务器提供 HTTPS 域名
↓
浏览器通过域名访问
↓
LINE Webhook 通过同一域名接入
↓
手机 LINE 成为 OpenClaw 的聊天入口
最终效果是：OpenClaw 仍然运行在本地桌面环境中，能够接触本机工作目录和本地工具；同时，它又可以通过手机 LINE 被随时调用。桌面端和手机端不再是割裂的两个入口，而是共同连接到同一个本地 Agent。
十一、这次实践的意义
这次配置的意义不只是“把一个服务暴露到公网”，而是把本地 Agent 从桌面工具变成了一个可随时触达的个人自动化入口。
本地 Agent 的优势在于它可以处理真实的本机环境，而聊天平台的优势在于随时可用、入口自然。两者结合后，手机上的一条消息就可以触发本机 Agent 执行任务、整理资料、生成文件或返回结果。
但这种便利必须建立在明确的授权边界上。公网域名、Webhook、聊天平台、浏览器 Control UI，每增加一个入口，都需要对应的认证、配对和清理机制。否则，本地 Agent 的能力越强，暴露风险也越大。
最终比较理想的状态，是做到：
入口足够方便
权限边界清楚
授权记录可管理
陌生请求默认不信任
本地 Agent 仍然掌握在本机终端手里
这也是本次 OpenClaw 远程访问与 LINE 接入实践中最重要的经验。