· 01 / 36
OpenClaw 进阶技能分享

善用互联网资源和内网工具

OpenClaw 进阶技能分享 · Tailscale × Cloudflare × MobileWork

刘宜金 · 中山移动 AI 专班 · 2026-10 · 约 45 分钟

封面
今天讲什么
今天讲什么 · 02 / 36
今天讲什么

三张「能力牌」

Tailscale

让开发顺畅访问自己掌握的 IT 资产，顺带把机器组成一张自己的网

Cloudflare

用边缘能力把成果安全地发出去、把服务低成本地跑起来

MobileWork

在内网环境里，我们是怎么把开发这件事规范化、平台化的

先立规矩
先立规矩 · 03 / 36
先立规矩

三条共识

①数据资产掌握在自己手上 · 这是底线，不是可选项
②善用互联网资源和内网工具 · 该用的工具大胆用，但边界要清楚
③能自动化就不手工 · 把重复劳动交给机器
第一部分
第一部分 · 04 / 36
第一部分

第一部分 · Tailscale

善用互联网资源和内网工具，从「能顺畅访问」开始

开发者的日常困境
开发者的日常困境 · 05 / 36
开发者的日常困境

四类真实卡点

拉取依赖慢/断拉 GitHub / npm / Docker 镜像，慢或直接断
访问外网资源不稳访问外网文档 / API，时通时不通
网络环境切换麻烦换网络环境（公司 ↔ 家里 ↔ 出差），配置全得重来
机器散落互相看不见手上机器散落各处（Mac / Windows / 云主机 / NAS / 手机）——这些机器都是我们自己的资产

不是能力问题，是通路问题

Tailscale 是什么
Tailscale 是什么 · 06 / 36
Tailscale 是什么

一句话讲清

基于 WireGuard 的零配置组网 —— 把散落的机器组成一张你自己的网

P2P 直连

机器之间直连，不走第三方服务器

自动 NAT 穿透

不用改路由器、不用公网 IP

中心只做协调

连上之后，流量走机器之间

传统 VPN（OpenVPN 等）高（服务器 + 证书 + 路由）太重
ZeroTier中备选
Tailscale低主力
我们的真实拓扑
我们的真实拓扑 · 07 / 36
我们的真实拓扑

14 台节点 / 4 类角色

角色  /  节点  /  说明
出口节点aliyun-gz云上，既是出口也是 HTTP 代理
出口节点yecao-hk云上，境外出口
常驻云机onecloud长期挂着的维护跳板
主力工作站macmac-mini跑 OpenClaw 的 Mac mini
办公机desktop-silm80bWindows 桌面机
常驻终端benliu-m-2Windows，可按需唤醒
移动端红米手机 / 平板手机随时接入
存储nas453bmini ×2NAS
主线价值
主线价值 · 08 / 36
主线价值

让开发顺畅访问自己掌握的 IT 资产

HTTP 代理（最常用）云上节点自建代理，给命令行/包管理器用
export https_proxy="http://:***@<云上节点>:10810"
出口节点（exit node）整个设备的流量走云上出口
tailscale set --exit-node=<节点IP>
tailscale set --exit-node=
按需组合大文件走代理、小文件/特定地域走出口

小文件（1MB 级）走出口

1.5 秒

大文件（10MB+）走出口

容易截断 → 大文件优先用 HTTP 代理

用完立刻摘掉出口

不留后患

附带价值一
附带价值一 · 09 / 36
附带价值一

机器组成自己的网

远程维护手机连网内地址，直接改配置（不用暴露到公网）
跨网段唤醒经跳板机唤醒沉睡的机器
统一寻址机器名当域名用（MagicDNS），不用记 IP
资产清点一条命令看清所有机器在线状态
tailscale status        # 全资产一览
ping <机器名>            # MagicDNS 直接寻址
附带价值二
附带价值二 · 10 / 36
附带价值二

资产收敛与边界控制

数据资产掌握在自己手上

①不暴露 · 内部服务默认不开放到公网
②要进来，先入网 · 访问受控，不是"谁都能敲"
③身份即权限 · 每台设备独立身份，权限可设（ACL / 标签）

进阶能力（点到为止，按需深入）：ACL（默认拒绝、只有明确授权的才能通）· 子网路由（把整个网段接进来，老设备无需改造）· Serve / Funnel（把本机服务按需分享给网内，或不开放）

进阶技能图谱（一）
进阶技能图谱（一） · 11 / 36
进阶技能图谱（一）

组网能力 · 六项

能力  /  一句话  /  适用
MagicDNS机器名当域名全员
ACL / 标签默认拒绝的权限模型团队
子网路由老网段一键接入有 legacy 设备
Serve分享本机服务给网内内部协作
出口节点流量走指定出口访问境外资源（含自己掌握的云上资产）
SSH免密钥、带审计的登录运维
怎么用
怎么用 · 12 / 36
怎么用

四个实操场景

场景 1 · 拉代码 / 依赖配好代理，命令行直达
git clone ...      # 走代理，不再断
场景 2 · 访问外网文档 / API临时挂出口，用完摘
tailscale set --exit-node= && <干活> && tailscale set --exit-node=
场景 3 · 远程维护机器手机在网内直达
场景 4 · 唤醒沉睡机器跳板 + 唤醒包
边界与注意事项
边界与注意事项 · 13 / 36
边界与注意事项

讲真话

大文件会截断出口节点适合小文件；大文件走 HTTP 代理
用完必关出口避免流量长期绕行，也避免影响其它服务
不是匿名工具中继节点能看到流量元数据；别用它传敏感数据
版本要对齐客户端与服务端版本差太多会告警

❌ 公司敏感数据绝不通过第三方通路传输

❌ 不用它规避任何合规要求

它解决的是「开发效率」，是让开发者能顺畅地用上海外的开源项目、文档与代码

第一部分小结
第一部分小结 · 14 / 36
第一部分小结

Tailscale · 小结

通路：自己掌握的资产（云上出口/海外云机/GitHub/npm/Docker）拉得动、访问得顺

组网：机器互相可见、可维护

底线：数据和边界始终在自己手里

「能顺畅访问」是效率问题；「数据在自己手上」是原则问题

第二部分
第二部分 · 15 / 36
第二部分

第二部分 · Cloudflare

DNS + 边缘计算 + Pages —— 不用买服务器，也能把事办了

从一个真实痛点说起
从一个真实痛点说起 · 16 / 36
从一个真实痛点说起

同一份成果，两条路

左内部链接

内部链接 http://<内网地址>:8181/?token=***

同事在外网：打不开

右公开链接

公开链接 https://benai.dpdns.org/decks/xxx/

需要谁能看，谁就能看

同一份成果，要有「临时」和「长期」两条路

Cloudflare 能力地图
Cloudflare 能力地图 · 17 / 36
Cloudflare 能力地图

我们实际用到的五块

能力  /  我们拿来做什么  /  在本分享里的角色
DNS 托管域名解析、子域分发入口
Pages静态站点 / 演示页托管货架
Workers边缘函数（AI / 镜像 / 代理）后厨
Workers AI免水印生图等后厨
Tunnel / Access私网连接 + 零信任门禁门卫

DNS 是入口，Pages 是货架，Workers 是后厨，Tunnel/Access 是门卫。

(a) 临时链接
(a) 临时链接 · 18 / 36
(a) 临时链接

要临时，就真临时

把目录作为 preview 部署推到一条 tmp-* 分支 → 得到分支别名域名

https://tmp-.pages.dev
preview 与生产完全隔离推临时版本，正式站点纹丝不动
清理后立即 404不留残骸
有效期约 7 天分支别名机制

适用：验收预览、对外演示前的一次性分享

(b) 长期托管
(b) 长期托管 · 19 / 36
(b) 长期托管

要长期，就给它个家

成果放到站点指定目录 → 部署 → 固定地址

https://benai.dpdns.org/decks//
主站benai.dpdns.org
边缘演示edge2026.benai.dpdns.org
博客hexo.benai.dpdns.org
图床cloudflare-imgbed-agw.pages.dev

配套：长期页面清单（每次发布自动登记，随时可查）

一张表说清
一张表说清 · 20 / 36
一张表说清

临时 vs 长期怎么选

给谁看  /  用哪条  /  地址形态  /  有效期
内部（自家设备）内网入口 内网地址 + token长期（仅网内）
需要临时给外部看临时链接 https://tmp-.pages.dev约 7 天
要长期展示长期托管 https://benai.dpdns.org/decks//长期

带 token 的内网链接绝不发外部

发临时链接必写有效期

对外发布先确认（是不是该公开的内容）

三条硬规矩（我们吃的亏）

(c) Workers
(c) Workers · 21 / 36
(c) Workers

用边缘函数干「后端」的活

不用买服务器，把逻辑放到 Cloudflare 边缘

AI Worker边缘调用大模型能力
agy（反重力 Google 大模型 CLI）用 agy 构建的 Google 大模型 CLI 调用
Docker 镜像站加速容器镜像拉取
通用代理 Worker转发/加速特定外部请求

共同价值：免运维、就近接入、按量计费（免费额度内）

进阶技能图谱（二）
进阶技能图谱（二） · 22 / 36
进阶技能图谱（二）

Cloudflare 还能怎么玩

能力  /  一句话  /  我们的用法
Pages 预览环境每个分支一个链接临时外发
Workers Cron定时任务定时同步/巡检
KV / R2边缘键值 / 对象存储小数据与文件
Durable Objects有状态的边缘对象需要「记住状态」的场景
Tunnel不暴露 IP 连进私网内网服务安全可达
Access零信任门禁（按身份放行）比「token 链接」更正规
AI Gateway统一观测/缓存/限流 AI 调用多模型统一入口
WAF / 限流保护公开服务防滥用

两个真实在用的案例（TL 项目）：hexo 博客站（hexo.benai.dpdns.org，实测 200）；AI 文生图 Worker（边缘跑 Workers AI FLUX 出图，无水印，已用于项目封面批量生成）

成本与风险
成本与风险 · 23 / 36
成本与风险

继续讲真话

成本：域名 + 免费额度内 → 接近零成本

Token 即权限泄露 = 站点可被改 → 按最小权限发放
临时链接不校验身份谁拿到谁能看 → 只放可公开内容
别把敏感数据放上去这是「展示层」，不是「数据层」
合规场景单独评估
第二部分小结
第二部分小结 · 24 / 36
第二部分小结

Cloudflare · 小结

入口：DNS 管好域名

货架：Pages 临时/长期两条路

后厨：Workers 免服务器跑逻辑

规矩要写下来

第三部分
第三部分 · 25 / 36
第三部分

第三部分 · MobileWork

内网开发的高阶实践 —— 从「能用」到「能规模化复用」

为什么单独讲 MobileWork
为什么单独讲 MobileWork · 26 / 36
为什么单独讲 MobileWork

两个命题划清界限

维度  /  前两部分（Tailscale/Cloudflare）  /  本部分（MobileWork）
解决什么通路：怎么连、怎么发范式：怎么开发、怎么复用
在哪运行边缘 / 公网内网
关注点效率与边界资产沉淀与规模化

工具有边界，方法是资产

MobileWork 高阶能力总览
MobileWork 高阶能力总览 · 27 / 36
MobileWork 高阶能力总览

从「个人用」到「团队用」

层级  /  能力  /  价值
基础智能体 / 数字员工单点任务自动化
进阶专家工作区 / 专家团多个智能体协同
高阶案例库一次跑通、全域复用
高阶场景复制省 / 地市共通场景快速落地

越用越聪明

高阶技能一
高阶技能一 · 28 / 36
高阶技能一

案例库与场景复制

场景跑通 → 沉淀为案例同类场景直接复用
案例跨团队共享共通场景不用重复造轮子
需求从「每次从头做」变成「改一改就能用」
新同事上手快照着案例走
高阶技能二
高阶技能二 · 29 / 36
高阶技能二

多智能体协同（专家工作区）

按专业分工建多个智能体主打制作的、主打数据的、主打内容的
用工作区把产出串起来复杂任务拆给不同角色，各司其职
一个「总调度」负责拆解与验收
若干「专员」负责各自领域，分工明确，禁止跨界乱用
高阶技能三
高阶技能三 · 30 / 36
高阶技能三

流程固化与自动化

把流程写下来规范文档 / 规则清单
把重复交给定时任务定时同步、定时巡检、定时汇报
把异常留给人机器跑常规，人管例外

能自动化的，就不要手工重复

内网开发的边界与红线
内网开发的边界与红线 · 31 / 36
内网开发的边界与红线

内网三条

内网不是限制，是优势

①数据不出内网 · 所有处理在内网完成
②权限按需给 · 最小权限原则
③留痕可审计 · 关键操作有记录
第三部分小结 + 三部分合流
第三部分小结 + 三部分合流 · 32 / 36
第三部分小结 + 三部分合流

三部分合流

Tailscale通路与组网 → 善用外网资源
Cloudflare边缘与发布 → 安全地把成果送出去
MobileWork内网开发范式 → 沉淀与复用

对外善用资源，对内沉淀资产

三部分合流
三部分合流 · 通路 × 边缘 × 平台
方法论
方法论 · 33 / 36
方法论

三条可迁移的原则

边界先行数据边界、权限边界、公开边界，先划清楚再动手
分层交付内部 / 临时 / 长期，三种场景三种规矩
沉淀复利跑通一次就要变成可复用的资产
结语 + 落地建议
结语 + 落地建议 · 34 / 36
结语 + 落地建议

给在座的三步

先解决通路把外网资源访问理顺（Tailscale 那套）
再解决发布把成果的「临时/长期」两条路定下来
最后谈沉淀把跑通的场景变成案例

技术分享的终点不是「知道了」，而是「用上了」

善用互联网资源和内网工具，但数据资产，始终在我们自己手上。

互动（3 分钟）：你最想先改造哪个环节？（通路 / 发布 / 沉淀）· 致谢 + 联系方式

附录 A1
附录 A1 · 35 / 36
附录 A1

数据口径与来源

网络与平台事实均来自本机实测（2026-10-06 / 10-07）：Tailscale 节点清单（14 节点）、大文件截断（1MB 级 1.5s 正常；10MB+ 断）、临时链接隔离性（推 preview 后生产无变化，清理后 404）、Pages 项目与域名（4 个项目均 200；hexo.benai.dpdns.org 实测 200）、AI 文生图（Workers AI FLUX 实测无水印出图，已批量生成封面）、agy（本机 ~/.local/bin/agy v1.2.16，反重力 Google 大模型 CLI）本机实测
技术能力描述参考 Tailscale 官方文档（exit nodes / ACL / subnet router / serve / MagicDNS）与 Cloudflare 官方文档（Tunnel / Access / Workers AI / AI Gateway / Durable Objects）官方文档
未做推算；金额仅「接近零成本」定性描述口径说明
附录 A2
附录 A2 · 36 / 36
附录 A2

备用 Q&A

Q：为什么不直接把内网服务开放到公网？A：数据资产掌握在自己手上是底线；确需对外时走 Cloudflare Tunnel + Access，按身份放行，而非裸暴露。
Q：Tailscale 访问外网资源稳定吗？A：小文件很稳，大文件会截断——所以我们的规范是「大文件走 HTTP 代理，小文件走出口」。
Q：为什么强调「自己掌握的 IT 资产」？A：因为这些通路（云上出口、海外云机）都是我们自己部署、自己运维的——不是租第三方通道，数据边界始终在我们手里。
Q：免费额度够用吗？A：轻量发布/转发够用；高并发需评估。
Q：临时链接会被人猜到吗？A：分支别名有一定随机性，但不算强权限——所以规矩是「只发可公开内容」。
Q：MobileWork 和前面两部分是什么关系？A：两个命题——前者解决「对外通路」，后者解决「对内开发范式」。