我的 N1 盒子之前刷过一遍 Armbian，一直放在家里做 DNS 广告拦截。最近又想更新一下，为啥？一开始确实是纯折腾。
不过让 AI 看了一遍之后，发现也不完全是折腾：系统太老、软件源和系统版本对不上，日志还快把磁盘占满了。所以这次干脆重装系统，顺便试一下，让 pi agent 帮我制定刷机计划、整理备份，再恢复原来的软件和配置，到底能做到什么程度。
结果比我想象中靠谱，但中间也踩了几个坑。这里把整个过程整理一下，重点不只是怎么刷 N1，更是怎么让智能体参与这类运维任务。
本文记录的是 2026 年 10 月的一次实际操作，适用于已经刷过 Armbian、准备重新安装的斐讯 N1。原厂 Android 系统首次刷机涉及的降级、启动引导和救砖不在本文范围内。文中的局域网地址、WiFi 名称等均为示例，请替换成自己的配置。
我的 N1 用来干什么
这台盒子的硬件是 S905D、2GB 内存、8GB eMMC，性能不算强，但是放在家里做 DNS 服务还行。
主要跑两个软件：
- AdGuard Home：给局域网设备提供 DNS 服务，负责广告域名拦截、自定义规则和查询日志。最主要是防电视广告，不过我加载了太多的规则，导致一些正常的功能也用不了，比如无法打开微信公众号助手的流量主，不过倒没啥大事，这些关闭Wi-Fi就行。
- SmartDNS：作为 AdGuard Home 的上游，通过多个上游和测速策略做解析优选，效果和实际网络有关，不保证所有网站都更快。
它们之间的关系如下：
局域网设备
|
| DNS，端口 53
v
AdGuard Home
|
| 127.0.0.1:7053
v
SmartDNS
|
v
公网 DNS 上游
AdGuard Home 的管理面板使用 8080 端口，SmartDNS 用 7053，就是为了避免两个软件抢同一个 53 端口。
如果你也想搭建自己的 DNS，可以先看看我之前写的打造自己的私人 DNS，反毒化、反广告、加速（也许）。
第一步：让 agent 看看旧系统
我使用的是 pi agent，一个可以在终端里读文件、执行命令和修改配置的智能体工具。这里假设你已经能在旧系统里运行 pi，并且知道它使用的模型和服务商。
注意，终端 agent 和普通聊天不太一样，它真的能执行命令。特别是在 root 用户下运行时，改错防火墙或者网络配置，可能直接把自己关在机器外面。
我当时的第一句话很简单：
帮我看看这台机器有没有什么安全风险，以及可以优化的空间。
它检查之后发现了几个问题：
| 项目 | 旧系统的情况 |
|---|---|
| 系统 | Debian 10 buster |
| 内核 | 5.4.23-flippy |
| 软件源 | 指向 bullseye，与实际安装的系统版本不一致 |
| 根分区 | 使用率约 91%，剩余空间只有六百多 MB |
| AdGuard 查询日志 | 两个文件合计约 1.7GB |
| SmartDNS 日志 | 约 900MB，七千多个文件 |
| 部署方式 | AdGuard Home 使用 Docker，保留了不少历史端口映射 |
本来只想更新一下，结果先做了一轮清日志和服务整理。
这里我建议把提示词稍微写严谨一点。下面这些是根据本次经历整理后的写法，不是所有原始对话的逐字复制：
先只读检查这台 N1：
1. 系统版本、内核、机型和设备树。
2. 磁盘空间、日志占用、已安装软件和运行中的服务。
3. AdGuard Home 与 SmartDNS 的部署方式、配置路径和端口。
4. SSH、防火墙、网络配置和定时任务。
先给我检查结果和处理计划，不要删除文件、升级软件、
重启服务或修改网络。涉及中断 DNS 和 SSH 的操作，单独说明。
先让它搞清楚机器，再决定怎么动手，比直接一句“帮我升级系统”更容易控制过程。当然了，你可以装个plan的插件，先plan一下，虽然我喜欢opencode，但是opencode在这些小机器上感觉太费资源了，所以我的小vps，这种小玩具都装的pi agent。
第二步：选镜像，让 agent 核对适配情况
我先搜到了这篇 N1 盒子镜像刷机教程，很简洁。不过我想自己选镜像，于是继续找到了 ophub/amlogic-s9xxx-armbian。
我也不确定可不可以用呀，继续让 AI 评估：
我现在打算安装新的镜像，使用下面这个仓库的镜像可以吗？
https://github.com/ophub/amlogic-s9xxx-armbian
请根据这台机器的实际硬件，核对机型支持、设备树、
镜像选择、U 盘启动和写入 eMMC 的步骤。
先出计划，不执行刷机。
这次它不是只回答“可以”，而是查看了项目的机型数据库和安装文档，找到这些对应关系：
| 项目 | 本次使用的值 |
|---|---|
| 机型 | Phicomm-N1 |
| SoC | s905d |
| 安装菜单编号 | 101 |
| 设备树 | meson-gxl-s905d-phicomm-n1.dtb |
| 系统 | Debian 13 trixie server |
| 内核系列 | 6.12 |
最终我选择的是：
Armbian_26.11.0_amlogic_s905d_trixie_6.12.112_server_2026.10.15.img.gz
文件名很长，但最重要的几个部分是 s905d、trixie 和 server，分别对应硬件、发行版和无桌面的服务器镜像。
这个版本是我本次实际使用的版本，不是要求你以后也下载同一个文件。项目会继续更新，下载前还是要去 Releases 核对当前镜像和说明。
还有一个说法需要注意：这是 ophub 的社区适配项目，项目支持 N1，不等于 N1 获得了 Armbian 官方支持。star 多可以作为参考，但不能代替适配检查，也不能保证刷机不会出问题。
第三步：备份，最好连恢复文档一起准备
备份肯定是要备份的。
我的做法是两手准备：先让 agent 导出一份能直接阅读的文本配置和规则清单，自己保存；然后再让它打一个完整迁移包，把配置、数据和恢复文档都放进去。
这样就算恢复过程不顺利，至少还能打开 Markdown 看清楚原来配置了什么。
不只是备份一个 YAML
对于我这台机器，需要保留的内容主要有：
| 内容 | 用途 |
|---|---|
| AdGuardHome.yaml | 上游、过滤器地址、自定义规则、面板配置等 |
| AdGuard 工作数据 | 过滤器缓存、历史统计和会话数据 |
| smartdns.conf | 监听端口、上游、缓存和日志限制 |
| systemd 服务文件 | 软件如何启动、使用哪些路径和参数 |
| SSH 公钥 | 恢复密钥登录，逐把核对是否还需要 |
| 网络和防火墙配置 | 作为新系统的配置参考 |
| 定时任务清单 | 判断哪些继续使用，哪些已经过时 |
| 可执行文件 | 本次保留了 AdGuard Home 的 ARM64 二进制 |
配置迁移包不是整盘备份。它能帮助重建服务，但不能把清空的 eMMC 直接恢复成原来的系统。需要原系统级回退能力的话，要另外准备离线系统镜像和救援介质。
我在刷机前，还让 agent 把 AdGuard Home 从 Docker 迁移到了原生二进制，所以最终备份的是迁移后的配置：AdGuard Home v0.107.79，配置 schema 为 34。
这不是刷机的必要步骤。如果你原来使用 Docker，也可以继续恢复 Docker，只是容器网络、挂载目录和端口映射都要一起保留。
让 agent 写交接文档
可以这样描述任务：
请把 AdGuard Home 和 SmartDNS 的配置、必要数据及恢复文档打包。
要求：
1. 提供可直接阅读的配置备份文档。
2. 记录版本、配置路径、端口、上游和服务依赖。
3. 编写新系统的恢复步骤与逐项验收清单。
4. 标明哪些文件可以恢复，哪些只能参考，不能直接覆盖。
5. 提供校验和，并检查压缩包内容能否正常读取。
6. 不把私钥或不必要的凭据打包；涉及敏感配置时先说明。
后续我会在新系统上，让另一个 pi 会话基于这些文档恢复。
我最终使用的是第二版迁移包，结构大致如下：
migrate-bundle/
├── README.md
├── checksums.sha256
├── docs/
│ ├── 01-BACKUP-adguardhome.md
│ ├── 02-BACKUP-smartdns.md
│ ├── 03-RESTORE-adguardhome.md
│ ├── 04-RESTORE-smartdns.md
│ ├── 05-RESTORE-system.md
│ └── 99-CHECKLIST.md
├── configs/
│ ├── AdGuardHome.yaml
│ ├── smartdns.conf
│ ├── adguardhome.service
│ ├── authorized_keys
│ └── firewall-nodocker.sh
├── binaries/
│ └── AdGuardHome-v0.107.79-linux-arm64
├── blocklists/
│ ├── INDEX.md
│ ├── user-rules.txt
│ └── filters/
└── data/
└── adguard-work-data.tar.gz
第二版不再恢复 Docker 和旧的 Cloudflare IP 同步工具，旧定时任务只留作参考。
把这个包下载到 Mac，并确认可以解压之后再刷机。备份留在 N1 自己的 eMMC 上，刷机时一样会被清掉。
在 Mac 上可以先做这些检查：
# 计算校验和，与生成备份时记录的值比较
shasum -a 256 ~/Downloads/migrate-bundle-v2.tar.gz
# 查看包内文件列表
tar -tzf ~/Downloads/migrate-bundle-v2.tar.gz
校验和只能帮助确认传输前后是否一致，不能证明备份内容完整。还要看配置、数据和恢复文档是否真的都在里面。
迁移包可能含密码哈希、历史查询数据和 WiFi 配置，应该按私密文件保存。本文不公开我的实际备份包。
第四步：写 U 盘，从 U 盘启动
准备好这些东西：
- 一台电脑和下载好的镜像。
- 一个容量足够的 U 盘，我建议准备 8GB 或更大的。
- HDMI 显示器和 USB 键盘或无线键鼠(带连接器的那种，我使用的这种）。
- 网线，能用有线最好。
- 已经保存到另一台机器上的备份包。
Mac 上可以使用 balenaEtcher，当然了我直接使用的第一篇教程的Raspberry Pi Imager：
- 选择下载好的 .img.gz 镜像。
- 选择目标 U 盘。
- 确认选中的确实是 U 盘，再开始写入。
- 等待写入和校验完成。
这一步会清空目标盘，别把自己的移动硬盘选进去了。
然后给 N1 断电，插入写好的 U 盘，再接通电源。
项目文档说明，已经安装过 Armbian 的设备，正常情况下可以直接从 U 盘启动。这个前提不是原厂 Android 系统，也不是任意一种旧引导都一定能启动。
网线不是首次登录的万能解法
agent 当时建议插上网线，通过 DHCP 获取地址后直接 SSH，全程远程操作。
但我这次实际操作，插网线并没有让我直接跳过首次初始化，还是用到了显示器和键盘，需要修改密码等；如果没有插网线，还要选择无线网络。
所以建议提前把屏幕和键盘准备好。至于是不是不同镜像封装方式造成的差异，我没有进一步验证，就不下结论了。
本次镜像说明中的初始账号是 root，密码是 1234，首次登录按提示修改。以后使用其他镜像，默认账号以对应版本说明为准。
下面是我这次首次登录的实拍：界面提示网络连接超时，还需要设置 root 密码、选择默认 Shell，确实不是插上网线就能直接跳过初始化。
照片已裁去用户名和无线网络列表。图中出现了弱密码警告，大家实际配置时应使用强密码，不要照着我的临时设置来。
第五步：写入 eMMC
从 U 盘进入系统后，先确认机器和存储设备：
uname -r
cat /etc/os-release
lsblk -o NAME,SIZE,TYPE,MOUNTPOINTS
findmnt /
这一步不是走形式，要确认当前确实是 U 盘环境，并且安装脚本识别到的是 N1 的内部存储。
确认备份已经搬走之后，再以 root 执行：
armbian-install
我这次的关键输出如下，省略了中间复制文件的日志：
[ INFO ] Detected eMMC device: [ /dev/mmcblk2 ]
101 s905d Phicomm-N1
meson-gxl-s905d-phicomm-n1.dtb
[ OPTIONS ] Please Input ID: 101
[ INFO ] Model Name: [ Phicomm-N1 ]
1 ext4
2 btrfs
[ OPTIONS ] Please Input ID (1/2): 1
[ INFO ] Selected filesystem type: [ ext4 ]
[ SUCCESS ] Installation completed successfully.
也就是选择：
- 机型：101，Phicomm-N1。
- 文件系统：1，ext4。
编号可能随脚本版本变化，要看名称和设备树，不要只记数字。/dev/mmcblk2 也是我这次的设备名，不能照搬到所有机器。
安装过程会重建 eMMC 分区、写入启动相关文件并复制系统，旧系统和数据会被覆盖。不要中途拔电源。
搜索过程中我看到了另一种说法：先不拔 U 盘，执行一次 reboot，重新登录后再关机、断电和拔 U 盘。我选择的是这种方式。下面截图是 AI 给出的建议，不代表所有 N1 都必须这样做；项目安装日志提示的是安装完成后执行 poweroff。
完成后执行：
poweroff
等系统关机，断电，拔掉 U 盘，再重新接电，从 eMMC 启动。
我本次进入新系统后看到的内核是：
6.12.112-ophub
本次没有遇到 eMMC 写入 I/O 错误。遇到这类问题时，应先检查供电、介质和项目对应文档，不要直接把所有错误归结为设备树，也不要反复强行写盘。
第六步：把交接包交给新的 pi 会话
新系统起来之后，重新配置网络和 pi 的运行环境，再把备份包传过去。
比如使用scp传过去，地址替换成新系统实际分配的 IP：
scp ~/Downloads/migrate-bundle-v2.tar.gz root@192.168.1.50:/tmp/
重装后 SSH 主机密钥通常会变化。如果遇到主机身份告警，先通过本地屏幕等可信方式核对新主机，再从 known_hosts 中删除该主机对应的旧记录，不要清空整个文件。
# 确认新主机身份后，只删除对应地址的旧记录
ssh-keygen -R 192.168.1.50
我给新会话的原始任务是：
/tmp/migrate-bundle-v2.tar.gz 是我重装系统之前的交接文档，
帮我恢复相关配置，恢复之前先给我看看计划。
这里最重要的一句就是：恢复之前先给我看看计划。
新 agent 会先解包、读文档、核对校验和，再检查当前系统。它发现新系统的 53 端口被 systemd-resolved 占用，SmartDNS 和 AdGuard Home 都还没安装，SSH 也是初始状态。
然后给出了恢复顺序：
- 安装并恢复 SmartDNS，先验证 7053。
- 处理 53 端口冲突，再恢复 AdGuard Home。
- 恢复过滤器缓存和历史数据。
- 配置防火墙、SSH 和日志限制。
- 固定网络地址，验证服务和重启后的状态。
它还问了几个需要我决定的问题：是否继续使用 WiFi、是否删除旧公钥、是否恢复历史数据，以及是否进行系统加固。我选择暂时继续用 WiFi，恢复历史数据，删除不再需要的公钥。
旧配置不能整份闭眼复制。比如 Debian 10 的 SSH 配置，到新系统上可能包含过时选项；旧 Docker 防火墙规则，也不适合直接用在原生二进制部署上。
恢复过程中踩到的几个坑
SmartDNS：配置在，不代表 UDP 和 TCP 都在
旧配置里有：
bind [::]:7053
备份文档把它描述成 UDP 和 TCP 都监听，但新系统实际安装的 SmartDNS v46.1，这一行只开启了 UDP，需要另外加：
bind-tcp [::]:7053
恢复后的有效配置可以整理成：
# UDP 和 TCP 分别监听
bind [::]:7053
bind-tcp [::]:7053
# 本次沿用旧环境的 IPv6 查询策略
force-AAAA-SOA yes
cache-size 16384
# 限制日志，避免把 eMMC 写满
log-level notice
log-size 2m
log-num 3
# 公网 DNS 上游
server 119.29.29.29
server 210.21.196.6
server 223.5.5.5
server-tls 8.8.8.8
server-tls 1.1.1.1
force-AAAA-SOA yes 是我沿用的旧策略，会抑制 AAAA 结果，不适合所有 IPv6 环境，不要当作通用加速参数。如果禁用了 IPv6，还要调整监听地址；如果只给本机 AdGuard 使用，也可以评估改成回环地址监听。
验证时 UDP 和 TCP 都要测：
ss -tulnp | grep 7053
dig @127.0.0.1 -p 7053 www.baidu.com
dig +tcp @127.0.0.1 -p 7053 www.baidu.com
这次让我觉得比较靠谱的一点，就是 agent 没有完全照着旧文档复制，而是检查了实际监听情况，再补上 TCP 配置。
AdGuard Home：先处理端口和系统自己的 DNS
新系统有 systemd-resolved，AdGuard Home 也要用 53 端口，需要先看清楚谁在监听：
ss -tulnp | grep -E ‘:(53|7053|8080)[[:space:]]’
可以调整 resolved 的 stub listener，也可以停用它并重新安排系统解析。本次 agent 选择了后者。
但不要只停服务，不管 /etc/resolv.conf。如果它还指向已经停掉的 stub resolver，接下来连安装软件都可能解析不了域名。
本次是先保留可用的外部解析路径，等 AdGuard Home 恢复成功后，再让系统优先使用本机 DNS，并检查 NetworkManager 是否会覆盖设置。
外部 DNS 作为备用并不等于严格的自动故障切换，不同程序行为不同，也可能绕过本机过滤。如果要求所有查询都经过 AdGuard，需要另行设计。
另外，恢复历史数据前先用 tar -tzf 看归档的目录层级，恢复后确认过滤器缓存位于实际工作目录下，别多套一层 work/data，导致文件在、服务却没读到。
静态 IP：当时能用，重启却变了
这个坑最有代表性。
agent 第一次用 NetworkManager 把地址改成了目标 IP，重新连接之后正常，重启 NetworkManager 也正常。
我以为这就行了，结果整机重启之后，又变回 DHCP 分配的地址。
继续排查才发现，Armbian 首次登录生成了：
/etc/netplan/30-wifis-dhcp.yaml
里面仍然是 DHCP 配置。开机时 Netplan 重新生成 NetworkManager 的连接文件，把实际连接恢复成了 method=auto。
也就是说，只改 NetworkManager 当前连接，并没有改到这台系统的网络配置源头。
最后它备份旧文件，把 Netplan 配置改成静态地址，运行 netplan generate，生成的连接文件中才出现：
method=manual
address1=<目标静态地址及前缀>
如果你也遇到类似情况，可以先让 agent 查：
请检查这台机器的网络配置由谁管理。
核对 Netplan、NetworkManager 和开机生成的连接文件，
确认是否有多个配置源互相覆盖。
先备份再修改。远程改 IP 会中断 SSH，请说明回退方式，
应用配置后还要检查整机重启后的地址，不能只看当前连接。
固定地址可以使用路由器 DHCP 保留，也可以使用系统静态配置，选一种清晰的管理方式就好。做静态配置时，还要核对网关、网段和地址冲突，避免和 DHCP 地址池中的其他设备撞上。
这份会话记录最后只到 Netplan 生成静态配置成功，并启动独立单元应用配置，没有包含修复后再次重启的验收结果。所以这里不能说“重启后已经彻底验证没问题”，最终仍要补一次重启检查。
防火墙和 SSH：别只做本机测试
旧系统整理时，agent 曾经写错 Docker 防火墙规则：访问宿主机 8080，转发到容器后已经变成了 80，按 8080 匹配就挡住了管理页面。
它后来查日志修好了，但这也说明，AI 会犯错。
本次新系统不再使用 Docker，恢复的是 nftables 规则，限制局域网访问 SSH、DNS 和管理面板。即使如此，也要从其他机器上再测一次：
dig @192.168.1.50 www.baidu.com
dig +tcp @192.168.1.50 www.baidu.com
curl -I http://192.168.1.50:8080/
本机测试可能走回环路径，不能替代真正经过网络和防火墙的客户端测试。
SSH 则要先恢复并验证自己的公钥，再关闭密码登录。本次 agent 临时保留了一个应急通道，确认密钥登录成功后才关闭。
应急通道不是长期配置，也不能在恢复后忘记清理。面板也应该使用强密码，即使只对局域网开放，弱密码风险也没有消失。
最后怎么验收
agent 说“恢复完成”之后，我建议自己再看一遍这些项目。
在 N1 上检查服务：
systemctl is-active smartdns adguardhome nftables
systemctl is-enabled smartdns adguardhome nftables
ss -tulnp | grep -E ‘:(22|53|7053|8080)[[:space:]]’
df -h
findmnt /var/log
swapon --show
journalctl -u smartdns -u adguardhome -n 50 --no-pager
如果没有 dig，Debian 上安装 dnsutils；需要旧习惯里的 netstat，安装 net-tools。我还顺手让 agent 装了 vim。
在自己的机器上检查真实使用链路：
# 正常域名解析
dig @192.168.1.50 www.baidu.com
# TCP DNS
dig +tcp @192.168.1.50 www.baidu.com
# 选择一个自己规则中确认应被拦截的域名
dig @192.168.1.50 ad.doubleclick.net
# 管理面板
curl -I http://192.168.1.50:8080/
本次配置中广告域名测试返回了 0.0.0.0，但拦截响应和 AdGuard 的阻断模式有关，不能要求所有人的配置都返回同一个结果。面板的 302 也只说明 HTTP 服务响应了，还要实际登录检查规则和查询日志。
恢复记录中的主要结果如下：
| 项目 | 本次恢复结果 |
|---|---|
| 系统 | Armbian 26.11.0，Debian 13 trixie |
| 内核 | 6.12.112-ophub |
| AdGuard Home | v0.107.79，原生二进制运行 |
| SmartDNS | v46.1，7053 UDP 和 TCP 均已验证 |
| 过滤器 | 12 个列表已刷新，面板统计合计 355,237 条 |
| 自定义规则 | 备份中保留了 85 条，包含个别白名单 |
| 防火墙 | nftables 已启用 |
| SSH | 密钥登录已验证，应急通道已撤除 |
| 根分区 | 恢复后约使用 2.7GB，占 43% |
过滤器数量是当时刷新后的统计，不是去重后的唯一域名数，也不是以后应该严格相等的目标值。某些列表含浏览器专用规则，导入 DNS 过滤列表不等于这些规则都能用于 DNS 拦截。
本次还把五个访问不稳定的 GitHub 原始文件地址换成了 jsDelivr，随后十二个列表都完成了刷新。但 CDN 可达性会变化，判断成功要看实际更新时间和内容，不只是 URL 返回了 200。
日志方面保留了 SmartDNS 的大小和数量限制，并设置了 AdGuard 查询日志保留策略、journald 容量限制，以及 Armbian 的 ramlog 和 zram。8GB eMMC 最怕的是日志悄悄增长，不是刚装完时多占几百 MB。
备份文档曾预计新系统只占 1.1 到 1.4GB，实际恢复后约 2.7GB，说明这类估计也得以实测为准。zram 可以减少部分磁盘写入，但不是备份，断电也可能丢失尚未落盘的日志。
最后安排一次重启，重新验证 IP、服务自启、DNS、面板和 SSH；过一天再看磁盘和日志有没有异常增长。网络修复后的重启验收、长期稳定性，都不能用“刚才运行正常”来代替。
总结
这次折腾下来，agent 比我想象中靠谱。尤其是把旧系统的配置整理成文档，再由新会话恢复，这个体验挺好，不用我重新回忆几年前到底改过哪些参数。
不过也不是完全放手就行。防火墙写错过，静态 IP 也出现了“现在正常，重启失效”的情况，所以我更愿意把它理解为：agent 帮我检查、整理和执行，我负责确认边界、保管备份和验收结果。
整个流程可以归纳成：
检查旧系统
-> 核对镜像
-> 备份配置、数据和恢复文档
-> 把备份搬到另一台机器
-> 人工写 U 盘和处理首次登录
-> 确认后写入 eMMC
-> 新 agent 读交接文档、先出恢复计划
-> 分阶段恢复和验证
-> 重启及后续复查
我觉得最值得复用的不是那一句“帮我刷机”，而是让 agent 在旧系统还活着的时候，把下一次恢复需要的东西准备好。
这样就算换一个会话，甚至换一个模型，也不用指望它记得前面聊过什么，打开文档就能继续干活。
参考链接
- N1 盒子镜像刷机教程
- ophub/amlogic-s9xxx-armbian
- ophub Armbian 中文使用文档
- balenaEtcher
- AdGuard Home
- SmartDNS
- Netplan 文档
