跳到正文

目录

微信原文

云端 Hermes，本地 Mac：为「文件系统不互通」搭的一套 PR 流程

Felix2026-7-23约 5 分钟人机协作
一边是 24 小时在线的 Agent，一边是日常写代码的本机。中间隔着文件系统——这才是整套方案真正要解决的问题。

01 起因：为什么要搭这套流程

我用 Grok CLI 做过一个本地期权学习网站。后来在摸 Hermes Agent 的时候发现，它更适合扛长期项目维护——自动化改动、cron、多端通知这些能力，本地 CLI 并不总能顶上。
但现实卡点很具体：
  • Hermes 部署在云服务器上
  • 我的开发工具在 Mac 本地
  • 两边文件系统不互通
写文档、验效果、看 Git 历史，习惯都在本机；真正能 24 小时盯着改、跑定时任务的，却是云上的 Agent。如果不想每次靠「复制粘贴 / 手工同步」硬扛，就得在中间放一层双方都认的中转——这就是后面整套方案的出发点。

02 架构总览：三端分工

整件事可以看成三端各干一件事：
端
角色
Mac 本地（VS Code）
写文档、日常验证效果、图形化管理 Git
GitHub 私有仓库
代码中转站，也是 PR 审核的场所
云服务器上的 Hermes Agent
24 小时在线，负责自动化改动、执行 cron 任务
Mac 不直接「摸」服务器磁盘，Hermes 也不直接改你正在用的本地工作区。仓库是唯一的共同真相；改动以分支和 PR 的形式过桥。

03 关键决策：为什么走 PR，而不是直接改 main

这是整套流程里最值得说清楚的一点。不直推 main，主要有三个理由：
  1. 云端改动不直接影响本地正在用的稳定版本：Agent 可以大胆试；你本机 checkout 的还是已验证过的状态。
  1. 每次改动都有明确记录，方便回溯：谁改的、改了什么、为什么合，都落在 PR 时间线上，而不是散落在某次 SSH 会话里。
notion image
  1. 本地验证失败时可以直接丢弃分支，零风险：效果不对就关 PR、删分支；main 始终是可回退的底线。
一句话：云端负责提案，本机负责验收，合并权留在自己手里。

04 实操：从零到跑通

按实际走过的路径，可以拆成五步。
私有仓库的建立
在 VS Code 里一键 Publish 即可，不必先去 GitHub 网页手工建空仓库。私有库足够：个人项目不需要对外曝光，却能把「中转 + 审核」两件事一起办了。
Hermes 端授权配置
云上的 Agent 要能读写私有库，需要配好 GitHub Token（以及对应的仓库权限）。权限没通之前，后面所有「Agent 开分支 / 提 PR」都会卡在第一步。
Hermes 改动规范
明确约定：走分支 + PR，禁止直改 main。Agent 的产出默认是「待审提案」，不是「线上已生效」。本地说「合并」之前，云端改动不应进入你日常依赖的稳定线。
Mac 端验证闭环
本机装好 GitHub Pull Requests 插件后，路径可以很短：
  1. 图形化 Checkout 到对应 PR 分支
  1. 本地把服务跑起来，看真实效果
  1. 确认文案、交互、构建都没问题
验证发生在你的 Mac、你的环境，而不是只看云上的 diff 描述。
确认无误后一键 Merge
本地过目通过，再合并。合并权始终在人这边——Agent 负责推进，人不让渡最终开关。
notion image

05 踩过的坑

「丢弃更改」不等于安全撤销
在 VS Code 里，对未跟踪文件点「丢弃更改」，效果接近永久删除。如果这些文件还从未进过 Git commit，没有历史可以回退，找不回来。
📌
提醒自己：重要草稿先 git add 进版本库，或至少复制一份；别把「丢弃」当成可撤销的撤销。
远程 Gateway 连的是云盘，不是本地盘
Mac 客户端连上 远程 Gateway 时，Agent 眼中的文件系统是云服务器目录，不是你 Mac 上的磁盘。很容易下意识以为「Agent 已经在改我本机项目」——其实两边仍然隔着仓库这一层。路径、相对目录、本地未提交改动，都不能想当然共用。
私有仓库首次授权失败
第一次最常见的是 Token 配置 / 权限范围不到位：仓库可见，但 clone / push / PR 某一步被拒。排查顺序可以很机械：
  • 身份是否正确
  • token scope 是否覆盖 repo
  • 远程 URL 与账号是否一致
  • Hermes 侧凭据是否读到最新环境变量

06 反思：这套架构是否真的必要

搭完之后，值得诚实地问一句：是不是过度工程化了？
Hermes 的多平台通知、cron 定时任务这些能力，对一个更新频率不高、也不需要主动推送提醒的个人学习项目来说，其实经常用不上。如果只是偶尔改改代码，继续用 Grok CLI 或 Claude Code 在本地直接操作，路径更短，心智负担也更小。
这套「云端 Agent + 私有库 + PR 验收」真正赚到的，是：
  • 需要长期、反复、可审计的改动时，有一条稳定通道
  • 需要 Agent 在你不在线时也能推进时，有地方落盘、有人（未来的你）验收
如果两样都不急，本地工具往往已经够用。先搭建、再反思是否过重——比一上来就写一篇纯正面教程，更接近真实使用体验。

07 给同样想尝试的人

可以用一个很简单的判断标准：
你的情况
建议
项目需要长期、偏高频维护
值得上仓库中转 + PR
需要多平台主动提醒 / 定时任务
值得上云端 Agent
只是偶尔改改的小项目
本地 CLI / 编辑器可能已经够用
核心矛盾如果不是「云与本地文件系统不互通」，不必为了架构而架构。若矛盾确实在，私有仓库当桥、PR 当闸——这是我目前觉得成本尚可、风险最低的搭法。
云端负责提案与自动化， 本机负责体感与验收， 合并键，留在自己手里。