企业官网建设流程全解析

本指南围绕开源仓库 agent-scripts 中的 remote-mac 技能 展开，该技能是仓库内所有远程 Mac 运维工作的「路由层与操作手册」：无论是对 MacBook、Mac Studio、Mac mini 等主机执行 SSH 检查，还是排查 Tailscale 网络、验证 OpenClaw Gateway 健康状态、进行 Codex 定时任务迁移，都以此为执行标准。读完本文，你将掌握一套以「实时状态为准、身份核对优先、生产环境审批守门」为核心的远程 Mac 运维方法，并可直接复用其中经过实战验证的命令与安全边界。

remote-mac 在仓库中的定位可以从两条线索确认：skills.sh.json将remote-mac归入「Infrastructure & Release」分组，与 fleet-maintenance、ssh-doctor 同组；而 xcode-sync 的开头明确要求「Use$remote-macfor fleet topology and SSH rules」，fleet-maintenance 也把$remote-mac作为 inventory/SSH 的入口。因此本文既是技能的完整解读，也顺带说明它与其他运维类技能的协作关系。

技能定位与触发方式

remote-mac 的 front matter 定义了它的触发关键词与能力描述：

--- name: remote-mac description: "Remote Macs: MacBooks, Mac Studios, hosted claw Macs, Tailscale, SSH, and OpenClaw." ---

技能正文进一步明确了触发场景：当用户提到MacBook、Mac Studio、clawmac、foundationclaw、foundationmac、megaclaw、miniclaw、Molty、Tailscale，或者要求在某台 Mac 上「跑一下 / 检查一下」时，Agent 就应加载该技能。这与 README 中「Skills are the main routing layer」的定位一致——技能的作用是在触发时提供准确的执行上下文，避免 Agent 凭猜测操作远程主机。

集群拓扑：每台机器的角色与边界

技能的核心资产之一是「Peter 的远程 Mac 拓扑」清单。理解这些主机的关系是安全运维的前提，下表归纳了文档中每台主机的关键属性：

拓扑中还有两个「网络域」的硬性边界，是判断连接策略的依据：

• corporate网络：Peter 的公司托管环境，应把 Mac Studio 当作主要的远程配置与检查对象；在该环境下禁止尝试clawmac、mDNS 或个人局域网发现。
• personal网络：Peter 的个人 LAN / 个人云端环境，包含clawmac；clawmac与个人 LAN 从公司 Mac 上不可达，严禁把clawmac当作公司侧的 relay 或 LAN 跳板。

此外文档明确两类特殊节点：gorillaclaw（个人 Ubuntu 节点，Tailscale100.93.99.79）与steipetesurface（个人 Windows Surface）属于非 Mac 舰队节点；而crabhammer（Scaleway M4-XL）已交给 vince，在computers.yaml中列于handed_off:之下，不是Peter 的机器，不得配置或标注为他的主机。

拓扑的权威事实来源（source of truth）是私有 manager 仓库的两个清单：/Users/steipete/Projects/manager/computers.yaml（所有 Mac/非 Mac 节点的规范清单）与/Users/steipete/Projects/manager/agents.yaml。技能要求所有身份核对、可达性提示、移交排除都以它们为准，仓库内的 fleet-schema.md 也印证了这一分工：「computers.yamlremains the source for identity, SSH topology, role notes, reachability hints, and handed-off exclusions」。

发现机制：以实时状态为准，不信任静态缓存

技能给出的发现流程（Discovery）遵循一条总原则：一切以实时状态为准，静态缓存仅作参考。具体执行步骤为：

1. 先运行tailscale status --json，以主机名/DNS 名匹配节点，并使用该节点的当前 IP——因为 manager 缓存的 Tailscale IP 可能已过期。
2. 若同一台物理 Mac 暴露了多个 Tailscale peer，不要依据Active、PATH 顺序、进程名或 IP 新旧来选择。必须核对 ComputerName、LocalHostName、硬件 UUID、稳定节点 ID 以及 backend-pinned 状态。文档还给出了两种 Tailscale 后端的定位方式：
   • 在 clawstudio 上，macsys 为/Applications/Tailscale.app/Contents/MacOS/Tailscale；
   • Homebrew 内核版本则需要/opt/homebrew/bin/tailscale --socket=/var/run/tailscaled.socket；
   • 在停止任一 backend 前，必须保留可验证的回退路径或定时自动重连。
3. 对租赁 Mac，要把实时身份与computers.yaml中的 provider 服务/产品记录对账。Provider 显示 Active 不等于舰队已配置，仅有公共 IP 也不足以合并身份。
4. 对clawmac：若 MacStadium 显示 Active 但公共 IP、SSH/VNC、Tailscale 全部失败，应视为 provider 网络/硬件事故。此时应查阅computers.yaml中的事故记录、更新现有 ticket，并请求 console、NIC-link、switch-port 检查。不要重复硬重启，也不要在未经 Peter 批准的情况下授权 reimage、erase、reinstall、存储更换、凭据重置等影响数据的操作。
5. 在corporate环境下默认使用 Mac Studio，通过其实时 Tailscale 节点连接；若 MagicDNS 被禁用，直接使用当前的TailscaleIPs[0]，不要尝试clawmac、mDNS 或个人 LAN 发现。
6. 在personal环境下，若 Tailscale 不可用或 SSH 超时，可尝试 LAN 发现：

dns-sd -B _ssh._tcp local arp -a

7. 仅当与目标在同一 LAN 时才尝试HOST.local这类 mDNS 名称。
8. 若 Mac Studio 的实时 Tailscale 节点在corporate环境下离线，立即停止操作：它必须先唤醒或重连，SSH 与 Screen Sharing 诊断才能继续。

从源码结构看，这套「先对账再动手」的规则与仓库内其他技能是一致的设计语言：例如 xcode-sync 同样要求「Read~/Projects/manager/computers.yaml; use livetailscale status --jsonfor reachability/IPs」「Deduplicate Tailscale nodes by hardware UUID」，并规定「Treat unreachable hosts as pending, not synchronized」。

SSH 规则：默认非交互，长任务进 tmux

技能对 SSH 的默认形态有严格要求——默认使用非交互式 SSH，避免任何 TTY 或远端命令副作用：

ssh -o RequestTTY=no -o RemoteCommand=none HOST 'COMMAND'

两个细节值得注意：

• 本地的 SSH 别名mac-studio会自动附加 tmux；因此执行一次性命令时，要么改用steipete@steipete-macstudio.local，要么显式覆盖上述两个选项。
• 对于长时间运行或需要交互的远端工作，应在远端主机上使用 tmux，并保持会话名显而易见（便于后续定位与回收）。

这与仓库内 ssh-doctor 的规则相互印证：「Prefer non-interactive SSH:ssh -o RequestTTY=no -o RemoteCommand=none HOST 'hostname; id -un'」，可见非交互式 SSH 是整个仓库的通用执行基调，而非 remote-mac 独有。

OpenClaw 健康检查：登录 Shell、独立健康层、形态核对

统一命令模板

在远程 Mac 上执行 OpenClaw 检查时，必须使用登录 Shell，以保证 Homebrew 与 pnpm 在 PATH 中：

ssh -o RequestTTY=no -o RemoteCommand=none steipete@steipete-macstudio.local \ 'zsh -lc "openclaw gateway status --json; openclaw channels status --json"'

zsh -lc的作用是加载登录配置，确保openclaw、brew、pnpm等工具链可用——这是 Agent 在远端执行 CLI 最常见的隐性失败点。

clawstudio 的健康形态

clawstudio 作为个人 OpenClaw Gateway 宿主，技能给出了三层「健康形态」判定标准：

• 使用不可变的 manager 托管运行时而非全局openclaw二进制进行深度检查：~/.local/share/openclaw-clawstudio/run-current gateway status --deep --require-rpc --json；
• lsof -nP -iTCP:18789 -sTCP:LISTEN应显示不可变发布监听器位于*:18789；
• tailnet portal 与 Gateway 是两个独立的健康层：深度 Gateway RPC 与 tailnet HTTPS 必须分别验证——一层健康不代表另一层可用；
• 修复 Tailscale 期间绝不启动gateway:watch、重启 Gateway 或改动其发布版本。

此外文档特别注明：London Studio 的旧 Molty gateway 已退役且必须保持禁用，真正的 Molty 独立运行在 Hetzner 上，不得把旧 Mac Studio 运行时的状态当作健康预期。

clawmac 的健康形态

clawmac 是生产环境，健康判定依赖三个可验证事实：

• launchctl list中包含ai.openclaw.gateway（LaunchAgent 已注册并存活）；
• lsof -nP -iTCP:18789 -sTCP:LISTEN显示回环监听器存在；
• openclaw channels status --json显示 Telegram 已连接。

Codex 定时自动化：主机本地调度，迁移需在目标机操作

技能强调一个容易误解的事实：Codex cron 自动化是主机本地的调度器状态，不是通用的云任务。因此：

• 在corporate环境下，除非 Peter 另有指示，应把自动化配置/镜像到 Mac Studio 上；
• 目标主机上~/.codex/automations/<automation-id>/automation.toml是该机器上定时任务定义的唯一事实来源；
• 若要把某个 cron 自动化从公司机迁移到 Mac Studio，机器层面的工作必须在 Mac Studio 上完成，流程是：
  1. 确保目标仓库 checkout 存在于 Mac Studio；
  2. 同步所需仓库级策略文件；
  3. 在 Mac Studio 上创建/更新对应的~/.codex/automations/...条目；
  4. 若 Peter 只想要一个执行者，则禁用/暂停旧的公司机副本。

最后是一条容易踩坑的边界：不要假设 Codex 应用线程的交接会转移 cron 调度器所有权——线程转移与 cron 所有权是两回事。

clawmac 的 GUI 访问：自动化优先，Peekaboo 兜底

当公共 SSH/VNC 与 Tailscale 全部不可达、而computers.yaml记录了 provider 网络事故时，GUI 访问同样不可用，应继续走现有 MacStadium remote-hands ticket，不要再次电源循环主机。在正常情况下，技能给出了「自动化优先、GUI 兜底」的访问阶梯：

1. 优先直接自动化 clawmac，而非先走 Tailscale/SSH：使用open -a "Google Chrome"、AppleScript、Chrome DOM JavaScript 以及远程 Peekaboo 点击。
2. gogOAuth 场景：浏览器必须留在 clawmac 上。步骤为：在远端 tmux 启动gog auth add，在 clawmac 的 Chrome 打开打印出的 URL，用 AppleScript/DOM 自动化点击 consent，最后用zsh -lc 'gog auth list --check --json --no-input'验证。
3. 若远端 shell 环境导出了GOG_KEYRING_PASSWORD，则在检查与 tmux 提示输入时必须使用匹配的登录 Shell，且绝不打印该值。
4. Peekaboo 兜底：当 SSH/cron 碰到直接自动化无法处理的 GUI-only 提示时，通过 Jump Desktop 的clawmac窗口使用本地 Peekaboo。定位窗口的命令是：

peekaboo list windows --app "Jump Desktop" --json

捕获窗口时用--window-title clawmac或报告出的--window-id；点击使用穿过 Jump Desktop 窗口的本地全局坐标，点击前先用原始窗口截图验证。仓库 CHANGELOG.md 的 2026-05-11 条目记录了这一工作流的确立，并补充了crabmac是 Peter 对clawmac的口误/别名这一事实；tools.md 中 Peekaboo 的条目也指向其技能文档，说明该工具由~/Projects/peekaboo仓库独立维护。

5. Chrome 钥匙串问题：security可能提示Chrome Safe Storage，需要 Peter 本人输入登录钥匙串密码并点击Always Allow。
6. 审批后验证：通过 SSH 运行/Users/steipete/Projects/bird/bird check与/Users/steipete/.openclaw/bin/bird-gui check。

实时测试策略：会话私有、生产审批、隧道脚枪

这是技能中最具安全价值的章节，定义了在任意 Mac 上进行 OpenClaw 实时测试的「红绿灯」规则：

• 默认形态：任何 Peter 的 Mac 上的实时测试，都应使用会话拥有的开发 Gateway——隔离的OPENCLAW_STATE_DIR临时目录 + 空闲端口。绝不在真实 Gateway 运行期间绑定 18789，也绝不对本会话未启动的服务执行launchctl kickstart/bootout/bootstrap或openclaw gateway stop/restart。
• clawmac = 生产环境：任何重启/停止、对~/.openclaw的配置/状态写入、或针对其 Gateway 的实时测试，都需要 Peter 在聊天中明确按任务批准。一次批准只对应一个任务，不存在常驻授权。
• 共享 Mac Studio 的 Gateway 或 dev-watch 会话是半生产：同样需要批准；绝不能停止本任务未启动的 tmux 会话。
• 隧道脚枪（Tunnel footgun）：在 megaclaw 与 Peter 的 MacBook Pro 上，127.0.0.1:18789是通往 clawmac 的SSH 隧道——在这些主机上做「localhost 测试」实际会打到生产。这两台主机自身都不运行本地 Gateway 服务。
• DB/状态测试或迁移演练：生产副本的迁移需要按任务批准并指明目标与处理方式；只允许在获批副本上工作，写回或就地迁移生产需另行批准。
• 跨机器/跨 OS 的重型实时 E2E 走$crabbox，不经过 Peter 的个人 Gateway。

安全边界：身份不靠旧 IP、密钥不落地、失败要可追溯

技能最后的安全章节浓缩了全部运维纪律：

• 不要凭过期 IP 假设主机身份；尽可能验证 hostname 与用户。
• 不要打印远端文件或 Shell 中的密钥——这与 AGENTS.MD 中「Secrets: never reveal values」的仓库级硬规则一致。
• 若 Tailscale + LAN 回退后主机仍不可达，要说明尝试过什么，而不是沉默跳过。
• 对 Peter 机器上的 OpenClaw Gateway 操作，遵循仓库docs/AGENTS的指示，未获请求不安装/启动/停止服务——这正是「技能只给出路径，权限永远在任务中」的体现。

与仓库其他技能的协作关系

remote-mac 不是孤立的，它与同仓库的技能形成了明确的依赖图，可作为读者继续探索的入口：

• fleet-maintenance：舰队维护的 inventory/SSH 入口使用$remote-mac，同时定义了full/worker双 profile 的期望状态与fleet-profile.mjs等确定性工具；
• xcode-sync：Xcode 舰队同步复用 remote-mac 的拓扑与 SSH 规则，并用scripts/xcode-host-inventory.sh做主机盘点；
• ssh-doctor：当 SSH 连上即断、Remote Login 异常时，提供回环优先、sshd 配置审计、残留会话清理等诊断路径；
• codex-huge-context 与 hopper-debugger 也在交叉引用中把 remote-mac 作为舰队上下文与对照实验的先决条件。

从 CHANGELOG.md 的 0.12.0 版本记录可以看到，这套远程运维体系的演进脉络：新增 fleet-maintenance、xcode-sync 等技能时同步「refreshed remote-Mac topology and network-boundary guidance」；后续版本又陆续补充了 SF Mini 的经典 OpenSSH 路径、MiniClaw 重复守护进程回归与公共 SSH 回退、FoundationClaw 的 provider 身份核验与 Tailscale/Jump Desktop 安装、以及移除过期 Mac 身份等对账工作。这说明 remote-mac 是一个随真实故障持续修订的「活文档」，其纪律性远高于一次性脚本。

结语：把「实时状态」与「审批边界」写进运维习惯

remote-mac 技能给 Agent 运维提供的不是一串命令，而是一套可复用的决策框架：发现阶段以实时 Tailscale 状态与硬件 UUID 对账身份；连接阶段默认非交互 SSH、长任务进 tmux；检查阶段把 Gateway 健康拆成可独立验证的层次；测试阶段严格区分会话私有、半生产与生产；任何数据影响操作都必须回到 Peter 的逐任务审批。结合本仓库的 AGENTS.MD、README.md 与其他运维技能，这套方法论同样适用于任何「多机 + 混合网络 + 生产服务」的 Agent 化运维场景——这也是它被 xcode-sync、fleet-maintenance 等技能共同引用的根本原因。