使用智能体辅助 N1 盒子刷机：从备份到恢复 AdGuard Home 和 SmartDNS
内容提要
文章记录了用 pi 智能体辅助斐讯 N1 盒子重装 Armbian 的全过程：先由智能体检查旧系统，发现系统过旧、日志占满磁盘；再核对镜像适配，备份 AdGuard Home 与 SmartDNS 配置并生成恢复文档；随后写 U 盘、从 U 盘启动并写入 eMMC。新系统上由另一会话按文档恢复服务，期间遇到 SmartDNS 仅监听 UDP、53 端口冲突、静态 IP 重启失效、防火墙规则错误等问题。作者强调智能体负责检查与执行，人负责备份、边界和验收。
延伸解读
智能体参与运维的边界：检查与执行，而非决策
文章反复强调，智能体负责检查旧系统、整理配置、执行恢复步骤，但备份保管、操作边界和最终验收必须由人完成。例如防火墙规则曾写错，静态 IP 出现“当时能用、重启失效”的情况。这说明智能体可以降低重复劳动，但不能替代人对关键节点的判断。读者若尝试类似流程，应把“先出计划、再执行”作为硬性要求，并保留人工复核环节。
备份不只是复制配置文件，更要准备可交接的恢复文档
作者让智能体生成迁移包，包含配置、数据、恢复步骤和验收清单，并强调备份要搬到另一台机器，因为刷机会清空 eMMC。恢复文档让新会话无需依赖旧对话记忆即可继续工作。这提示读者：备份的价值在于“别人或另一个会话能照着恢复”，而不只是文件存在。校验和只能确认传输一致，不能证明内容完整，仍需人工检查包内文件。
恢复阶段的典型陷阱：配置存在不等于服务可用
SmartDNS 旧配置只监听 UDP，新版本需额外加 bind-tcp 才能同时支持 TCP；AdGuard Home 恢复前要先处理 systemd-resolved 占用的 53 端口；静态 IP 只改 NetworkManager 当前连接，重启后会被 Netplan 生成的 DHCP 配置覆盖。这些坑说明，恢复旧配置不能整份照搬，必须结合新系统实际状态逐项验证，包括 UDP/TCP 双协议测试和整机重启后的地址检查。
验收要看真实链路和重启后的状态，而非本机测试
作者建议从其他机器测试 DNS 的 UDP/TCP 查询、广告域名拦截和管理面板访问，因为本机测试可能走回环路径，无法验证防火墙规则。SSH 要先确认公钥登录成功再关闭密码登录，并清理临时应急通道。最后安排一次重启，复查 IP、服务自启、DNS、面板和 SSH，过一天再看磁盘和日志增长。这说明“恢复完成”的结论必须由可重复的验收步骤支撑。
Q&A
用智能体辅助 N1 盒子刷机，整体流程分哪几步？
流程可归纳为：检查旧系统 → 核对镜像适配 → 备份配置、数据和恢复文档 → 把备份搬到另一台机器 → 人工写 U 盘并处理首次登录 → 确认后写入 eMMC → 新智能体会话读交接文档、先出恢复计划 → 分阶段恢复和验证 → 重启及后续复查。
为什么作者决定重装 N1 的 Armbian 系统？
智能体检查旧系统后发现：系统为 Debian 10 buster，软件源却指向 bullseye，版本不一致；根分区使用率约 91%，剩余空间仅六百多 MB；AdGuard 查询日志约 1.7GB，SmartDNS 日志约 900MB、七千多个文件，日志快把磁盘占满。因此决定重装系统并恢复原有服务。
备份 N1 上的 AdGuard Home 和 SmartDNS 时，迁移包应该包含哪些内容？
迁移包应包含：AdGuardHome.yaml（上游、过滤器、自定义规则、面板配置）、AdGuard 工作数据（过滤器缓存、历史统计、会话数据）、smartdns.conf（监听端口、上游、缓存和日志限制）、systemd 服务文件、SSH 公钥、网络和防火墙配置参考、定时任务清单，以及可执行文件（如 AdGuard Home ARM64 二进制）。同时要提供可直接阅读的配置备份文档、恢复步骤与验收清单、校验和，并避免打包私钥或不必要的凭据。
恢复 SmartDNS 时遇到“配置在但 UDP 和 TCP 监听不全”的问题，怎么解决？
旧配置中只有 `bind [::]:7053`，备份文档误以为 UDP 和 TCP 都监听，但新系统安装的 SmartDNS v46.1 中该行只开启 UDP。需要额外添加 `bind-tcp [::]:7053`，使 UDP 和 TCP 分别监听。验证时用 `ss -tulnp | grep 7053` 检查，并用 `dig @127.0.0.1 -p 7053 域名` 和 `dig +tcp @127.0.0.1 -p 7053 域名` 分别测试 UDP 和 TCP。
静态 IP 设置后当时能用，但重启后变回 DHCP，原因是什么？如何修复？
原因是只改了 NetworkManager 当前连接，但 Armbian 首次登录生成了 `/etc/netplan/30-wifis-dhcp.yaml`，其中仍是 DHCP 配置。开机时 Netplan 重新生成 NetworkManager 连接文件，把连接恢复成 method=auto。修复方法是备份旧文件，把 Netplan 配置改成静态地址，运行 `netplan generate`，使生成的连接文件中出现 `method=manual` 和静态地址。修改后需检查整机重启后的地址，不能只看当前连接。
恢复完成后，应该从哪些方面验收 N1 的 DNS 服务？
在 N1 上检查：`systemctl is-active/enabled smartdns adguardhome nftables`、`ss -tulnp` 确认 22/53/7053/8080 端口监听、`df -h` 和日志目录占用、`journalctl` 查看服务日志。在另一台机器上测试：`dig @N1_IP 域名`、`dig +tcp @N1_IP 域名`、测试应被拦截的广告域名、`curl -I http://N1_IP:8080/` 检查面板。最后安排一次重启，重新验证 IP、服务自启、DNS、面板和 SSH，并过一天再看磁盘和日志有无异常增长。
