2026-05-04

Hermes

今天上午突然想体验一下Hermes，”一行命令“安装的方式失败了，我选择将代码仓库下载到本地，进行开发者安装。

我给她配置了Kimi Coding Plan。在配置channel的时候，惊喜的发现集成飞书机器人的步骤已经简化到了扫一个二维码，扫完二维码，就自动创建了机器人（用户体验这一块，字节还是很有诚意的）。

截至目前，最直观的感受，比OpenClaw反应的快，也不知道是不是因为当前记忆不多的缘故。

选个比赛打打

我之前让Agent去搜集了每个赛题的信息，然后Agent给我推荐了一个赛题，并给了详细的理由。但，这真的靠谱么？我给Hermes装了求是 Skill，Hermes给了我相反的观点，认为Agent说的太过于理想化了，没有考虑到很多现实因素。

确实，现在的AI太会溜舔用户了，需要自己多加分辨，独立思考。

误删 ~/.ssh，Kimi巧恢复

我想将过期的密钥对删掉，于是使用了

rm xxx*

不巧的是星号和前缀中间多了空格，导致ssh目录下的内容被删光了。

记得几年之前用git的时候，有遇到过，因为对git操作的不熟练，导致修改全部丢失，但通过AI说的方法找回来了。于是，我马上和Kimi讨论恢复方案。

我和Kimi的对话

👤

我

我刚才手误将~/.ssh下的内容都删掉了，怎么恢复？

🤖

Kimi

误删 ~/.ssh 的后果可大可小，取决于你是否有备份。以下是按优先级排序的恢复方案：……

👤

我

我用rm删干净了，有什么恢复的方法吗

🤖

Kimi

立即停止在该分区写入任何数据。** rm 直接释放 inode，新写入会覆盖原数据块。
按成功率从高到低，依次执行：
1. 检查 ssh-agent（概率最高、最省事）……

👤

我

archlinux

🤖

Kimi

Arch Linux，大概率是 ext4。*时间紧迫，按以下顺序执行，不要往 /home 分区写入任何文件（包括别用浏览器下载大文件）。……

👤

我

ssh-add -l
Could not open a connection to your authentication agent.

🤖

Kimi

Arch Linux + rm + 无 agent = 立即做文件系统恢复，但成功率随每一秒写入而下降。
执行以下命令，不要重启（重启会写入大量日志）：
第 1 步：确定你的文件系统和分区
# 查看 ~/.ssh 所在分区的设备路径和文件系统
findmnt -n -o SOURCE,FSTYPE ~
……

👤

我

findmnt -n -o SOURCE,FSTYPE ~
输出是空

🤖

Kimi

findmnt 输出为空说明 ~ 没有独立挂载点，大概率挂在根分区下。用下面两条命令确认：
bash
复制
df -T ~
stat -f -c "Type: %T Device: %d" ~
把这两条命令的输出立刻贴给我，我根据文件系统类型（ext4 / btrfs / xfs / zfs）给你精确的恢复命令。
如果是 btrfs（Arch 安装器近年默认），恢复会简单得多——可能直接有快照回滚。如果是 ext4，继续用 extundelete。

👤

我

me@archlinux ~/.ssh [1]> df -T ~
Filesystem Type 1K-blocks Used Available Use% Mounted on
/dev/nvme0n1p2 btrfs 999153664 397731496 600087800 40% /home
me@archlinux ~/.ssh> stat -f -c "Type: %T Device: %d" ~

💬

type

btrfs Device: 0

🤖

Kimi

btrfs！这是最好的消息。 Arch 默认安装通常会启用 snapper 快照，或者至少 btrfs 的 COW 特性让数据块保留时间更长。
立刻执行以下命令，不要重启：
第 1 步：检查 snapper 快照（概率最高）
# 查看是否有 snapper 配置
sudo snapper list-configs……

👤

我

me@archlinux ~/.ssh> sudo snapper list-configs
[sudo] password for me:
Config │ Subvolume
───────┼──────────
home │ /home
root │ /
me@archlinux ~/.ssh> sudo snapper -c home list
# │ Type │ Pre # │ Date │ User │ Cleanup │ Description │ Userdata
─────┼────────┼───────┼─────────────────────────────────┼──────┼──────────┼─────────────┼─────────
0 │ single │ │ │ root │ │ current │
1 │ single │ │ Fri 19 Dec 2025 03:00:03 AM CST │ root │ timeline │ timeline │
42 │ single │ │ Tue 03 Feb 2026 05:51:48 PM CST │ root │ timeline │ timeline │
204 │ single │ │ Sun 01 Mar 2026 01:00:12 PM CST │ root │ timeline │ timeline │
1555 │ single │ │ Mon 04 May 2026 11:00:02 AM CST │ root │ timeline │ timeline │

🤖

Kimi

完美，snapper 每小时都有快照。 你现在是 11:19，最新快照 1555 是 11:00 的，几乎肯定包含你刚删的密钥。

💬

立刻执行

# 1. 创建挂载点
sudo mkdir -p /mnt/snap……

👤

我

me@archlinux ~/.ssh> ls /mnt/
snap/
me@archlinux ~/.ssh> sudo mount -o ro,subvol=.snapshots/1555/snapshot /dev/nvme0n1p2 /mnt/snap

💬

mount

/mnt/snap: fsconfig() failed: No such file or directory.
dmesg(1) may have more information after failed mount system call.

🤖

Kimi

路径不对。snapper -c home 的快照子卷实际结构需要确认。执行以下排查：
# 1. 列出该分区所有子卷，找快照真实路径
sudo btrfs subvolume list /home | grep 1555……

👤

我

me@archlinux ~/.ssh [32]> sudo btrfs subvolume list /home | grep 1555
ID 3372 gen 173251 top level 263 path .snapshots/1555/snapshot
ID 3373 gen 173252 top level 262 path @/.snapshots/1555/snapshot

👤

我

总结一下当前的情况，我要在kimi cli里让kimi继续处理

🤖

Kimi

当前状态摘要（可直接复制到 Kimi CLI）：
---
问题：用户 me 在 Arch Linux 上误执行 rm -rf ~/.ssh/，删除了所有 SSH 密钥。当前时间 2026-05-04 11:25。
系统环境：
- OS: Arch Linux
- 文件系统: btrfs
- 设备: /dev/nvme0n1p2 挂载在 /home
- 用户目录: /home/me
已发现的恢复路径：
- 有 snapper -c home 配置，每小时自动快照。
- 删除前最新快照：ID 1555（Mon 04 May 2026 11:00:02 AM CST），理论上包含完整 .ssh。
- btrfs subvolume list /home | grep 1555 输出：
ID 3372 gen 173251 top level 263 path .snapshots/1555/snapshot
ID 3373 gen 173252 top level 262 path @/.snapshots/1555/snapshot
已尝试但失败：
sudo mount -o ro,subvol=.snapshots/1555/snapshot /dev/nvme0n1p2 /mnt/snap
# 报错：mount: /mnt/snap: fsconfig() failed: No such file or directory.
下一步建议（请 Kimi CLI 继续执行）：
1. 用 subvolid 直接挂载快照 ID 3372：
sudo mount -o ro,subvolid=3372 /dev/nvme0n1p2 /mnt/snap
2. 如果成功，检查并复制：
ls -la /mnt/snap/home/me/.ssh/ # 或 /mnt/snap/me/.ssh/
cp -a /mnt/snap/home/me/.ssh/ ~/.ssh/
chmod 700 ~/.ssh && chmod 600 ~/.ssh/*
3. 如果 subvolid=3372 也失败，尝试：
sudo mount -o ro,subvol=@home/.snapshots/1555/snapshot /dev/nvme0n1p2 /mnt/snap
# 或
sudo mount -o ro,subvol=home/.snapshots/1555/snapshot /dev/nvme0n1p2 /mnt/snap
关键提醒：用户仍在正常使用系统，btrfs COW 虽不会原地覆盖，但新写入会占用新块，应尽快完成恢复。

聊到一半，心理还是慌的，但看到主机用的是带有快照功能的btrfs文件系统，且我的主机在一个小时前刚拍过快照，顿时觉得有戏。

为了加快进程，我决定让Kimi总结当前的情况，把前情提要粘贴给主机上运行的kimi-cli，Kimi可以更迅速。

💬

Kimi CLI

3 轮对话 · 12 次工具调用 · btrfs + snapper 快照恢复

→

最终，成功恢复！👍