1 / 36

刘宜金 · 中山移动 AI 专班

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

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

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

开场定调一句话——"今天讲的不是「把内网开放出去」，而是怎么把互联网上的资源用好、同时把我们的数据资产攥在自己手里。"

2 / 36

今天讲什么

三张「能力牌」

Tailscale

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

Cloudflare

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

MobileWork

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

强调第三部分与前面是两个截然不同的命题——前两部分讲"通道与工具"，第三部分讲"平台内的开发范式"。请听众注意切换脑子。

3 / 36

先立规矩

三条共识

① 数据资产掌握在自己手上

这是底线，不是可选项

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

该用的工具大胆用，但边界要清楚

③ 能自动化就不手工

把重复劳动交给机器

这三条是全场纲领。特别强调第 1 条——企业数据安全很敏感，我们所有方案都建立在"数据不出自己掌控"的前提上。（互动：请举手认同的同事举手，暖场 30 秒。）

4 / 36

第一部分

第一部分 · Tailscale

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

第一部分命题：开发怎么顺畅访问自己掌握的 IT 资产 + 机器怎么组成自己的网。

5 / 36

开发者的日常困境

四类真实卡点

拉取依赖慢/断

拉 GitHub / npm / Docker 镜像，慢或直接断

访问外网资源不稳

访问外网文档 / API，时通时不通

网络环境切换麻烦

换网络环境（公司 ↔ 家里 ↔ 出差），配置全得重来

机器散落互相看不见

手上机器散落各处（Mac / Windows / 云主机 / NAS / 手机）——这些机器都是我们自己的资产

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

这些都是日常，不用展开太久，快速过，让听众点头。

6 / 36

Tailscale 是什么

一句话讲清

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

P2P 直连

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

自动 NAT 穿透

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

中心只做协调

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

方案	组网难度	我们的结论
传统 VPN（OpenVPN 等）	高（服务器 + 证书 + 路由）	太重
ZeroTier	中	备选
Tailscale	低	主力

不展开「控制面在哪」这类话题——只讲工程价值。

7 / 36

我们的真实拓扑

14 台节点 / 4 类角色

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

名字不用记，重点是结构：云上做出口、本地做资产、手机做终端。

8 / 36

主线价值

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

HTTP 代理（最常用）

云上节点自建代理，给命令行/包管理器用

export https_proxy="http://:***@<云上节点>:10810"

出口节点（exit node）

整个设备的流量走云上出口

tailscale set --exit-node=<节点IP> tailscale set --exit-node=

按需组合

大文件走代理、小文件/特定地域走出口

小文件（1MB 级）走出口

1.5 秒

大文件（10MB+）走出口

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

用完立刻摘掉出口

不留后患

这一页是第一部分的核心。「什么样的活用什么通路」，这是真金白银的经验。

9 / 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/

需要谁能看，谁就能看

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

不夸大——"这是把该公开的成果放到该放的地方。"

17 / 36

Cloudflare 能力地图

我们实际用到的五块

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

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

这页是第二部分总纲。

18 / 36

(a) 临时链接

要临时，就真临时

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

https://tmp-.pages.dev

preview 与生产完全隔离

推临时版本，正式站点纹丝不动

清理后立即 404

不留残骸

有效期约 7 天

分支别名机制

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

纠正一个常见误解——"有人以为它是 24 小时临时页；实测是分支别名，约 7 天。我们按临时用，用完就清。"

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 的内网链接绝不发外部

发临时链接必写有效期

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

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

这三条直接抄自我们的操作规范。

21 / 36

(c) Workers

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

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

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

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

一句话——"每一个 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 出图，无水印，已用于项目封面批量生成）

只讲"有这些能力"，不逐个展开；重点提示 Tunnel + Access 组合，是"既要对外、又要安全"的正解；文生图 Worker 那个例子可以现场说"我们的封面就是这么批量出的"。

23 / 36

成本与风险

继续讲真话

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

Token 即权限

泄露 = 站点可被改 → 按最小权限发放

临时链接不校验身份

谁拿到谁能看 → 只放可公开内容

别把敏感数据放上去

这是「展示层」，不是「数据层」

合规场景单独评估

与 P13 呼应——"通道和边缘都有边界，用之前先想清楚。"

24 / 36

第二部分小结

Cloudflare · 小结

入口：DNS 管好域名

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

后厨：Workers 免服务器跑逻辑

规矩要写下来

转场——"通路有了、发布有了；那么在内网环境里做开发，我们又沉淀了什么？"

25 / 36

第三部分

第三部分 · MobileWork

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

重点转场语——"前面讲的是怎么连出去；这一部分讲的是，在我们自己的内网环境里，怎么把开发做得规范、可复用。这是完全不同的两件事。"

26 / 36

为什么单独讲 MobileWork

两个命题划清界限

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

工具有边界，方法是资产

这页把两个命题划清界限，避免听众混淆。

27 / 36

MobileWork 高阶能力总览

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

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

越用越聪明

这是第三部分的总纲——从"会问答"到"能接活"，再到"能沉淀"。

28 / 36

高阶技能一

案例库与场景复制

场景跑通 → 沉淀为案例

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

按专业分工建多个智能体

主打制作的、主打数据的、主打内容的

用工作区把产出串起来

复杂任务拆给不同角色，各司其职

一个「总调度」

负责拆解与验收

若干「专员」

负责各自领域，分工明确，禁止跨界乱用

用我们自己的多 agent 实践做类比，不点名具体产品。

30 / 36

高阶技能三

流程固化与自动化

把流程写下来

规范文档 / 规则清单

把重复交给定时任务

定时同步、定时巡检、定时汇报

把异常留给人

机器跑常规，人管例外

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

呼应 P3 第 3 条共识。

31 / 36

内网开发的边界与红线

内网三条

内网不是限制，是优势

① 数据不出内网

所有处理在内网完成

② 权限按需给

最小权限原则

③ 留痕可审计

关键操作有记录

把"内网"讲成优势（安全、可控），而不是"不方便"。这是第三部分的关键定调。

32 / 36

第三部分小结 + 三部分合流

三部分合流

Tailscale

通路与组网 → 善用外网资源

Cloudflare

边缘与发布 → 安全地把成果送出去

MobileWork

内网开发范式 → 沉淀与复用

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

这三部分合起来，就是"一个技术团队该怎么把 AI 用起来"的完整答案。

33 / 36

方法论

三条可迁移的原则

边界先行

数据边界、权限边界、公开边界，先划清楚再动手

分层交付

内部 / 临时 / 长期，三种场景三种规矩

沉淀复利

跑通一次就要变成可复用的资产

强调这三点与技术栈无关，换任何工具都成立。

34 / 36

结语 + 落地建议

给在座的三步

先解决通路

把外网资源访问理顺（Tailscale 那套）

再解决发布

把成果的「临时/长期」两条路定下来

最后谈沉淀

把跑通的场景变成案例

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

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

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

留 1 分钟答疑缓冲。

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）
来源：官方文档

未做推算；金额仅「接近零成本」定性描述
来源：口径说明

附录页，默认不投屏，内部备查。

36 / 36

附录 A2

备用 Q&A

Q：为什么不直接把内网服务开放到公网？

A：数据资产掌握在自己手上是底线；确需对外时走 Cloudflare Tunnel + Access，按身份放行，而非裸暴露。

Q：Tailscale 访问外网资源稳定吗？

A：小文件很稳，大文件会截断——所以我们的规范是「大文件走 HTTP 代理，小文件走出口」。

Q：为什么强调「自己掌握的 IT 资产」？

A：因为这些通路（云上出口、海外云机）都是我们自己部署、自己运维的——不是租第三方通道，数据边界始终在我们手里。

Q：免费额度够用吗？

A：轻量发布/转发够用；高并发需评估。

Q：临时链接会被人猜到吗？

A：分支别名有一定随机性，但不算强权限——所以规矩是「只发可公开内容」。

Q：MobileWork 和前面两部分是什么关系？

A：两个命题——前者解决「对外通路」，后者解决「对内开发范式」。

附录页，答疑时备用。