双机家庭实验室如何接续智能体任务

两台常开机器、几套 Agent 工具，并不会自动组成能接力干活的系统。作者用 Intel NUC 和 Mac mini 搭家庭实验室，想解决的是一个具体问题：周末重新连上服务器，AI 能知道上次做到哪，并继续往下做。

目前，数据采集、报告生成、部分 GitHub 操作已经跑通，但审批、无人值守和异常恢复仍有缺口。它值得读的地方，是把「服务启动了」「一次执行成功了」和「可以放心交接」拆成了不同的验收问题。

两台机器怎么才能接上同一份工作

Intel NUC 跑 Ubuntu，用 Docker Compose 承载自动化和监控：n8n 负责工作流，另有 GitHub 数据采集与报告生成，以及 Prometheus、Grafana、Uptime Kuma。机器上还放了一个 QEMU/KVM 分析虚拟机，用 REA 和 Ghidra 做离线分析实验，且没有虚拟网卡。

另一台是 Mac mini（M4），常开运行 OpenClaw，由 Agent 调用 Codex 和 Claude Code。两边通过 GitHub 仓库里的留言板共享状态。

关键并非多了一台电脑，而是多了一个交接位置。机器各自运行工具，不能保证下一个 AI 知道上一个 AI 做了什么。作者用留言板承接状态，已经验证了定期发布状态，以及在普通聊天中读取收到文本的路径。

能共享状态，是接力工作的前提；收到请求，却不等于获得执行授权。

作者明确把收到的信息视为不可信输入。留言板里即使出现任务请求，也不会直接被当作执行许可。这对多 Agent 协作尤其重要：状态同步与权限判断需要分别处理。

哪些已经跑通，哪些还不能算成功

NUC 上，作者手动验证了从 GitHub 数据采集、生成 Markdown 报告，到经由 MCP 引用报告的流程；也检查了 Prometheus、Grafana 的采集目标响应，并做过加密备份和隔离环境恢复测试。

Mac mini 上，OpenClaw 能启动 Codex、Claude Code 两个 CLI，但生成能力只验证到编辑计划、简短回复等有限任务。在专门的 GitHub 测试中，push、创建 PR 和 merge 都成功过。

这些证据有边界。定时任务已经配置，不代表每次都收齐必要信息；监控入口可见，不代表信息完整，更不代表通知已经送达。分析工具返回 exit code 0，也只能说明进程正常结束，不能证明分析能力合格。

物理机器还多了一层验收。SSH agent 提供过多密钥，会触发认证失败次数上限；键盘布局差异会造成输入不匹配。即使 SSH 已经连通，登录后的锁屏仍可能阻断远程操作。

FileVault 与自动登录存在取舍，重启和休眠后的恢复也需要单独检查。作者直到构建末期仍遇到锁屏问题，因此没有把「能连上」直接算成「能无人值守」。

真正容易出错的是重跑和收尾

作者遇到的几个软件故障，暴露了自动化流程容易遗漏的状态问题。

一次夜间备份把作者主动停掉的 Open WebUI 又启动了。旧流程会停止整个服务栈，再启动整个服务栈；修复后，只恢复备份前正在运行的栈。备份是否成功，不能只看文件有没有生成，还要看它是否保留了原来的运行状态。

另一次，同一天重新采集 GitHub 数据，因为未认证 GitHub API 的调用额度限制，拿到的内容变少，反而覆盖了先前完整的报告。作者改为每次根据内容计算完整性，保护已有结果。不过，原文没有展开完整性算法和覆盖规则，不能直接照搬实现。

更有代表性的是 PR 合并：GitHub 端已经完成 merge，Agent 却没能确认返回结果，最终记录为「unknown」。作者没有重试，而是检查外部状态。

结果未知时，先核对操作是否已经发生，再决定是否重跑。

对于创建 PR、合并分支这类会改变外部状态的操作，这条原则比一味增加重试更可靠。

还有一个问题尚未解决：正常工作中的子会话审批注册缺少 operator.approvals，导致 Git 命令执行前就停止。原文附了 OpenClaw v2026.11.1 的审批 API 定义作为核查依据，但没有确认根因。作者也没有将其归咎于 GitHub 认证或目标仓库权限，因为管理界面里另一条连接的权限，不能证明故障连接拥有相同权限。

我的判断

我认同作者把验收对象从「工具能运行」推进到「状态能交接」。对于日常 AI 编程，真正影响可用性的往往是中断以后怎么办：能否知道上次进度，能否保住已有结果，能否判断外部操作已经完成。

但这仍是一份有限范围的构建记录。作者没有证明所有服务当前健康，也没有实现任意仓库的自动开发，或三方之间完整的自动往返。所谓完成约 80%，作者自己也强调只是主观感受，不是实测成功率。

GitHub 留言板的好处是依托现有仓库共享文本，但原文没讲清并发更新、任务归属和冲突处理。相比任务队列或明确的工作流状态存储，它是否足够可靠，材料不足以判断。也没有对照数据证明双机方案优于单机部署；一般团队应先确认自己需要怎样的交接，再决定增加多少机器。

此外，旧备份流程做过恢复测试，新备份流程仍待恢复验证。修复逻辑与验收修复，是两件事。

能拿来做什么

• 给前端或 Node 项目的 AI 编程任务建立固定交接记录，至少写清已完成事项、当前结果和下一步，让重新进入会话的 Agent 有据可读。
• 给采集和报告任务增加内容完整性判断，避免一次受限响应覆盖已有成果；检查定时任务时，同时检查产物是否齐全。
• 对创建 PR、merge 等操作保留「结果未知」状态，先查 GitHub 实际结果，再决定重试，避免重复执行。
• 如果用常开 Mac 跑编程 Agent，把 SSH、锁屏、重启、休眠恢复分别验收；调整备份流程后，再做一次隔离恢复测试。