https://test.ooocm.com/ 做了一个灵根测试哈哈，纯属娱乐
最近用 Grok 改代码时，有一个体验一直让我觉得很神奇：它处理 Git 和 GitHub 工作流特别顺。
比如我把之前的 PR 分支交给它，让它根据 review comments 修改，它很自然地知道应该先看分支差异、定位评论、修改、测试，再把结果整理好。
比如我直接丢给它一个 issue，说改完开 PR。它通常会很聪明地新建一个干净分支，甚至创建独立 worktree，不去污染我现在可能有另一个agent正在干活的工作区。
相比之下，我有时让 Codex 做同样的事情，如果没特意提醒它“请从最新 main 创建独立分支，不要碰当前工作区”，它居然可能直接在现有目录里开始干。最后 Git 状态乱成一团，我还要自己收拾。
我当时一直觉得：Grok 真的很懂怎么处理这类工程工作流。
然后这几天又看到有人抓包分析 Grok Build，发现它可能会把 Git 仓库以 git bundle 的形式上传到云端。所谓 git bundle，不只是当前代码的压缩包，它还可能包含 commit、branch、文件对象和 Git 历史，基本可以拿来重新 clone 出一个仓库。
我这才突然想到：
难道 Grok 那种“对分支、历史、PR 和 worktree 关系特别熟悉”的丝滑感，部分原因就是它的云端已经有了一份完整的仓库状态？
当然，目前不能直接证明两者存在因果关系。
git status、git diff、创建分支和 worktree 这些操作，本身完全可以在本地完成。一个设计良好的本地 Agent，也可以先检查工作区是否干净，再创建隔离目录，并不需要把完整 Git 历史上传。
Grok 的体验更顺，也可能来自它的系统提示和 Agent harness：它默认把“解决 issue 并开 PR”理解成一个完整的软件工程事务，而不是单纯地“在当前目录改几个文件”。
但是，如果服务端已经拥有仓库 bundle，那么它确实更方便做一些事情：恢复 session、理解分支关系、计算 diff、让多个子 Agent 基于同一个 commit 并行工作，以及把远程任务和本地状态对应起来。
于是整件事在我脑子里形成了一条很奇妙的路径：
最开始只是觉得：
“Grok 好聪明，Git 操作真丝滑。”
后来变成：
“也许它比 Codex 更主动地遵守标准工程流程。”
然后又变成：
“等等，它不会是直接把我整个 Git 仓库搬到云端，所以才这么熟吧？”
虽然这还只是一个没有被证明的猜测，但确实让我重新理解了一件事：
很多 AI 编程工具表现出来的“聪明”，不一定完全来自模型本身。它可能来自权限更激进、上下文拿得更多、默认工作流设计得更主动，甚至来自它提前获得了你没有意识到自己已经交出去的数据。
体验越丝滑，有时越值得问一句：
它到底知道了什么，又是怎么知道的？
正在试着vibe coding一个类似pi的coding agent：https://github.com/giggling-ginger/mini-pi
还让ai生成讲解html，方便我就算不stay in the loop也知道发生了什么
现在在hermes agent试着做点开源贡献，借此来学习各种agentic coding的工具，感觉比直接做一些雷同的vibe coding项目（简直就是ai时代的日记账本todo独立开发三件套）更有意思一点。
（说句题外话，看这里都用openclaw，有人用hermes吗）
先用zed（rust写的ide，新产品薅了额度）做的，之前也用过cursor，两者给我的感觉是ui很难受。
换codex cli之后恍然大悟...我只是个diff checker呀…对话框不应该只占屏幕一小块，看得眼睛疼
目前做了一些p3的pr，感觉5.5 medium做p3没啥问题。
还试了opencode，表扬ui！开源这一点我也更有好感。先用完了英伟达薅的抠搜glm5.2额度😓然后试了一些openrouter的free Model，嗯只能说性能略大于local ai😓但发现找issue这个过程可以丢给免费模型做？
虽然暂时不想继续刷p3了，但是有点想用p3练手一个自动pipeline：
1. github actions 或者 hermes cron去扫适合做的p3 issue
2. codex做并自动pr（哈哈我知道大部分人是claude code, 之后再考虑开，目前探索期用codex已经挺够了
Hermes 做 orchestrator的话……好吧我也说不出两者优缺点，主流应该还是claude code + github action，但我目前就纯探索making some shit...