Agent4DevOps 的尝试#

这正是我在做的。一个系统能被命令行操作的越多，就越适合交给 AI 管理。

也就是说，AI 亲和度：

一月爆火的 OpenClaw 也证明了我的观点：一个操作系统是可以被 AI 所管理的。一切复杂的软件和硬件的接口，最后都能被一个自然语言接口统一管理。

使用 OpenCode/Pi Agent 管理你的系统#

在 AGENT.md 中写好约束条件，遇到问题从 runbook 里面找，如果没有解决方案的话，在解决问题后就把解决方法沉淀在 runbook 里面。

比如：

# OpenCode 全局配置

## 语言

请使用中文回答用户的问题。

## 依赖管理

- **mise**: 管理 Node.js、Python 等运行时版本

- **pnpm**: 管理 JavaScript/TypeScript 依赖

- **uv**: 管理 Python 依赖和虚拟环境

- **micromamba**: 管理 Conda 环境

## 重要提示

- **禁止**使用系统自带的 Python 环境和 pip3，所有 Python 依赖必须通过 uv 管理

## 本机维护手册（Runbook）

- 路径：`~/Documents/mac-agent-system-runbook`

- 用途：把常见系统维护/工具链配置的"脏活"流程沉淀成可检索文档；处理相关问题时优先查阅并按文档执行/更新

## Subagent 调用

可以调用 subagent 分步进行复杂的、可能产生大量输出，占用大量上下文的任务。

这是我的实践：mac-agent-system-runbook↗ 一个 Agent 维护，供 Agent 使用的 macOS 系统维护/工具链配置可检索手册库。它在我的 MacOS 上工作得很好。

Linux#

从 2018 年开始折腾 Linux，到现在也有 8 年了。一路踩坑、迁移、重装、换发行版，多少也形成了一些自己的看法。

在我的认知里，Linux 发行版大致可以分成几类：

• deb 系：开源基因最浓厚，也是大量面向 Linux 的软件默认适配的环境。同时，它也是国产信创社区里的主流选择。
• redhat 系：背靠服务器大厂红帽，定位企业级市场，资金和生态都相对充足。国内也有像 OpenEuler 这样的衍生体系。
• arch 系：滚动发行版的代表，追求新与纯粹，强调可控与 DIY。
• nixos 系：不可变系统的代表，从理念上重构了系统管理方式。
• 其他：例如 Alpine、Gentoo 这样的”特色选手”。

这些年折腾下来，我的想法也在慢慢变化。

我越来越倾向于：

• 系统基座是不可变的：比如 Nix、Fedora OSTree 这种模式，稳定、可回滚、可复现。
• 上层应用生态尽量统一：Flatpak、AppImage 这类方案，减少发行版之间的割裂。
• 系统更新保持滚动：像 Arch、openSUSE Tumbleweed 这样，既新又不至于太激进。
• 软件构建与服务运行环境更加容器化、虚拟化、轻量化：Docker、Alpine 这类工具和系统，正在成为基础设施的一部分。

在实践层面，我也开始做一些调整：

1. 逐步脱离 Arch Linux，转向社区更主流、更稳健的 deb 系。
2. 更积极地拥抱虚拟化与容器化，大量使用 Docker、uv、Flatpak 等工具来隔离环境、统一体验。
3. 使用 Agent 管理系统，减少运维的 Dirty Work。

所有快反馈的 coding 活动都会被 RL 下的 Agentic 取代。只有慢反馈弱反馈长反馈的东西还有活下来的机会。