在 Arch Linux 上用 WorkBuddy：一个桌面用户的实战报告

在 Arch Linux 上用 WorkBuddy：一个桌面用户的实战报告

我在 Arch Linux 桌面上用了两周 WorkBuddy，把一批真实的重复劳动交给它：本地文档盘点归档、月度表格流程、系统体检、输入法词库维护、每日签到。 这篇不复述功能清单，只写三件事：Linux 桌面上它的能力边界在哪、哪些坑我已经替你踩过、以及怎么把踩坑经验沉淀下来。

图1：一层沙箱，三条通道

先交代环境

• Arch Linux（滚动更新），CachyOS 内核，X11 + XFCE，zsh
• 一台普通笔记本：十一代 i5、16G 内存、NVMe
• 使用场景以本地为主——数据不出机器是我选它的前提

一、先搞懂这张图：一层沙箱，三条通道

Linux 用户最先要理解的不是功能列表，而是 Bash 工具的运行方式：它跑在一个隔离沙箱里，不是直接跑在你的桌面上。

这个沙箱有几个具体表现，每一个我都实测确认过：

• 独立 PID 命名空间：沙箱里 ps 只能看到自己，kill 不到任何宿主进程；
• 独立 /tmp：上一次调用写进 /tmp 的文件，下一次调用读不到；
• 系统级目录只读：沙箱内 id 显示 root，但 /etc、/boot 连 touch 探针都过不去；
• 宿主资源选择性可见：工作区文件双向可见，音频设备、凭据文件则摸不到。

跨越边界要靠三条显式通道：本地编辑通道（表格/文档实时读写）、CDP 遥控（指挥宿主浏览器）、云资料库（上传归档）。这个模型想通了，后面所有的"为什么不行"都有了统一解释。

二、开箱即用的部分（两周实测）

文件与批量文档处理。 桌面上四千多个文件的历史包袱，用它做了一次全量盘点：批量抽取 docx/xlsx/pptx/csv 正文、生成分层总览、再按主题挑出该入库的部分传到云端资料库。整条流水线一次跑通，中间不需要我盯着。

本地 Office 编辑通道。 这是 Linux 下我觉得最实用的一点：表格不是"用 Python 库改完覆盖"，而是驱动本地编辑器实时读写——文件在编辑器里所见即所得，改完保存即可。对那种上了年纪的模板表格（跨表引用、外部链接、几十处合并单元格）尤其重要，后面坑里细说。

定时自动化。 每日签到这类任务做成脚本加定时任务，带日志、可重跑。跑了十几天，只在它自己升级那次断过一天。

技能沉淀。 可复用的流程写成技能（本质是一份写清楚步骤和坑的说明书）。两周下来我沉淀了 9 个：目录文档盘点、系统体检、输入法词库维护、文件回收站操作、表格本地读取、月度表格流程、资料库上传、每日签到，还有一个专门体检 Arch 工作站的（CPU/内存/zram/磁盘/TRIM/PSI 压力/防火墙全套）。

三、Linux 上的四个坑（都替你踩过了）

坑 1：/tmp 每次调用不共享

现象：上一条命令写进 /tmp 的中间产物，下一条命令读不到，报错还特别像"文件没生成"。

解法：临时文件统一放工作区目录：

CACHE="$HOME/WorkBuddy/<项目目录>/.cache"
mkdir -p "$CACHE"

长脚本不要写进临时文件再执行，直接用 heredoc 传给解释器，省掉一次跨调用的文件依赖。

坑 2：系统级目录只读，是设计不是 bug

沙箱内是 root 身份，但写 /etc 会被拒。一开始容易当成环境坏了去排查，其实它是在明确告诉你：系统级改动走"生成脚本 → 你 sudo 执行"这条路。

$ touch /etc/test.conf
touch: cannot touch '/etc/test.conf': Read-only file system

实践下来这反而是优点：AI 动不了系统，出的是给你审过再跑的脚本，改了什么一目了然。我按这个模式做过内核参数调优、zram 配置、引导参数修改，全部留了回滚脚本。

坑 3：宿主机资源不是都能摸到

两个实测案例：

• 音频设备：会议录音脚本在沙箱里拿不到设备，脚本注释里必须写明"在宿主终端运行"；
• 凭据类文件：签到脚本读取 WorkBuddy 自己的状态文件时报权限错误——连它自家的文件沙箱都可能只读。脚本要有降级逻辑：读不到就按"已签到"跳过，别硬重试。

签到失败：[Errno 1] Operation not permitted: '.../workbuddy-desktop.info'
今日已签到，跳过。连续第 N 天   ← 降级分支兜住了，任务照常幂等

坑 4：浏览器自动化，起法比努力重要

想让 AI 帮你操作网页（比如往社区投稿），在沙箱里启动浏览器是死路：

• 窗口不会出现在你的桌面上（沙箱看不到宿主的 X11 socket）；
• 换无头模式，又会被目标站点的风控识别、页面被洗白；
• 就算登录成功，登录态也存不住——沙箱的浏览器进程随时重建。

图2：两种起法的对比

正确姿势是宿主启动、沙箱遥控：

# 宿主终端里执行一次（独立配置目录，不影响日常浏览器）
microsoft-edge-stable --remote-debugging-port=9222 \
     --user-data-dir="$HOME/.config/edge-agent"

沙箱侧通过 CDP 协议连接这个端口，就能读写页面、上传文件、填表单。两个细节别漏：连接本地端口要绕过代理（NO_PROXY=127.0.0.1,localhost，否则请求被代理吃掉）；某些前端框架的按钮用 JS click() 不触发，必须走 CDP 发真实鼠标事件。

这套组合拳的额外好处：发布类操作可以停在最后一步等你确认，人始终在回路上。

四、比功能更值钱的：经验沉淀

两周用下来，我觉得最有价值的不是某个单项能力，而是它逼着你形成三个习惯：

1. 技能化。一个流程踩过的坑全部写进技能文档，下次直接复用，换机器也能带走。第一次做文档盘点花了一下午，第二次就是一句话的事。
2. 幂等。所有定时任务设计成可重跑：第二次运行识别出"已经做过"就停下。
3. 红线入记忆。删除一律走回收站、某块数据盘只读、系统改动先出脚本——这些规则写进长期记忆，不用每次口头交代，也不会忘。

五、两周小结

顺手的地方：命令行与文件能力配上 Linux 的脚本生态，天然契合；本地优先，数据不出机器；本地编辑通道把 Linux 上最疼的 Office 自动化接住了。

需要适应的：沙箱模型得花半天理解，不然会一直困惑"为什么这个做不到"；GUI 类任务需要宿主浏览器配合；系统级改动永远多一步 sudo。

一句话总结：它不是替你操作电脑的黑盒，而是一个懂边界、会沉淀的协作者。 而 Linux 用户恰恰是最容易理解这套边界的人群——沙箱、权限、通道，本来就是我们的日常。

标签建议：WorkBuddy / Linux / Arch Linux / AI Agent / 桌面自动化