构建基于 OpenCode 与 GitOps 的家庭实验室 AI 开发平台
一个面向家庭实验室管理的 AI 驱动开发平台，能够在保持人工监督的 GitOps 工作流下，实现容器更新和基础设施变更的自动化。通过将 AI 代理隔离在专用 VM 中，并要求 Pull Request（PR）批准，用户可以利用 AI 完成跨多设备的复杂配置任务，而无需让 AI 直接访问生产服务。
架构：OpenCode 与安全沙箱
平台的核心是 OpenCode，这是一款与供应商无关的编码环境，因其内置的 Web 服务器和 Web UI 而被选用，能够提供跨设备同步的持久编码会话。
为了保持安全并限制 AI 生成变更的“冲击范围”，系统的架构如下：
- 专用 VM： OpenCode 作为 systemd 单元运行在 TrueNAS 主机上的一个简易 VM 中。该 VM 包含必要的开发工具，但与其管理的实际服务网络隔离。
- 受限 Git 访问： AI 代理在 Git 服务器上拥有自己的用户并配备专用 SSH 密钥。它仅有克隆项目和推送到特性分支的权限，严禁直接推送到部署分支。
- 特权访问： 由于 VM 与生产服务隔离，AI 在 VM 内拥有 root 权限，可安装构建工具或测试依赖，而不会危及宿主系统。
基础设施管理的 GitOps 工作流
平台用 AI 辅助的流水线取代了手动的基础设施维护——例如阅读发行说明和更新 Docker Compose 堆栈。工作流遵循严格的顺序以确保稳定性：
- 规划： 用户在 OpenCode 中定义特性或改进，包括规范和实现计划。
- 迭代： 用户与 AI 共同迭代计划，并在可能的情况下验证变更。
- 分支： OpenCode 将最终变更推送到特性分支。
- 审查： 用户打开并审查该特性分支的 PR。
- 部署： PR 合并后，GitOps 工具负责部署。这包括用于 Docker 服务变更的 Arcane、用于 Home Assistant 配置的 GitOps 插件，以及用于博客更新的 Cloudflare Pages workers。
这种方式使得高层次的变更——例如在所有容器之间更新网络设置——可以通过移动设备审查 PR 来完成，而无需手动编辑多个 Compose 文件。
技术限制与挑战
虽然平台简化了更新流程，但在 CI 反馈回路 上存在显著瓶颈。在 GitHub 等环境中，代理可以通过读取 Action 日志来诊断测试失败或 linter 错误。然而，在使用 Forgejo 的此设置中，公共 API 并未暴露作业日志，导致 AI 难以自主诊断并修复部署失败。
社区观点与替代实现
开发者的讨论揭示了多种将 AI 融入家庭实验室和开发环境的替代模式：
- 基于 Action 的代理： 部分用户在 Forgejo Action 运行器中运行 OpenCode，通过在 issue 中使用
/oc命令调用代理，以自动生成 PR。 - 增强沙箱： 高级实现包括使用 gVisor 与 Kubernetes 代理沙箱，或通过 systemd 强制的私有 localhost 与代理，防止代理直接访问凭证。
- 集成层： 像 Kimaki 这样的工具用于添加 Discord 集成，使用户能够通过语音或聊天消息与代码库交互。
- 替代工具链： 其他用户使用 n8n、Argo 和 k3s 实现类似工作流，采用 Qwen 或 Gemma4 等模型进行自动化。
"我的工作流让 AI 处于 PR 审查之后。OpenCode 编写变更，我在 PR 中自行合并。我觉得这很可爱，但更重要的是，它防止未审查的代码被部署。"
"我可以在电脑上发起变更，在手机上审查 PR，然后让 GitOps 处理部署。"