发布了什么

AVP 在 Product Hunt 上架，一句话定位是「面向 AI 编程代理的开源 Git 替代品」。分类挂在 Git 客户端和 LLM 开发者工具下，附了 avp.murmell.com 和 GitHub 仓库地址。截图时它当天排在第 20 名上下、约 76 个 upvote——很早，但不至于没人看。

真正解释产品的是页面上另一句话：

Worktree 负责隔离你的代理，AVP 负责把它们整合起来：每个改动都要在 main 的确切最新提交上验证过，才允许落地。

这比「又一个 Git」具体得多，也有意思得多。

它瞄准的真实痛点

只要你在同一个仓库上跑过两个以上的编程代理，就见过这个场面：两个代理、一个工作区，其中一个把另一个刚改的文件回滚了。标准解法是 git worktree，给每个代理一个独立检出，文件写入不再互相踩。

worktree 解决了隔离，同时制造了一个新问题：你手上现在有 N 个分支，各自从不同时刻的 main 拉出来，整合它们是一连串手工 rebase、冲突解决、跑测试。而且失败很隐蔽——在自己的 worktree 里测过的改动，合并那一刻可能就坏了，因为它测的基线已经不是它要合进去的基线。

「在 main 的最新提交上验证过再落地」就是冲着这件事去的：每个候选改动都要对着当前的 main 重新验证，而不是对着代理当初拉出来的那个提交。

至于实现有没有做到这句话，是另一个问题，而且应该去仓库里找答案，不是看发布文案。

采用前必须自己确认的六件事

Product Hunt 页面讲的是意图，不是行为。真要拿它承载重要工作，至少确认：

  • License。「开源」从 MIT 到带商用限制的 source-available 都算，去看实际文件。
  • 冲突策略。 两个代理改了同一个函数会怎样？rebase、merge，还是直接拒绝？
  • 「验证」到底是什么。 是跑测试、跑构建，还是只检查能不能 fast-forward？只有前两种能拦住真正的破坏。
  • Windows 支持。 Windows 上的 worktree 会撞路径长度和文件锁，Linux 优先的工具经常忽略这点。代理跑在 Windows 桌面上就必须在 Windows 上测。
  • 审计线索。 能不能看出哪个代理产生了哪个提交、当时被要求做什么。没有这个，坏改动无法归因。
  • 离线行为。 默认依赖云端服务的工具，会在你断网那一刻罢工。

就算不换工具，这件事也值得注意

AVP 最值得注意的不是产品，而是它承认的问题：代理工具这两年一直在优化模型和提示词，但生产环境真正断掉的是底下那层状态——哪些文件、哪个分支、哪个版本才算数。

这个问题不只在写代码时出现。一个会改 Excel 和文档的桌面代理，失败方式一模一样：两个任务、一个文件、后写的赢，最后没人说得清哪一版被审过。给代理的产出做版本控制，正在变成「敢不敢让它无人值守」的前置条件。

如果你还停在一个代理做一件事、你全程盯着的阶段，你不需要新的 Git 层。你需要的是：每个任务一个提交边界，以及「代理不许改它没打开过的文件」这条规矩。MOOGH 就是按这个思路做的——跑在 Windows 上的桌面代理，操作你本来就在用的应用，每次运行的范围由你交给它的任务决定。

相关阅读

常见问题

AVP 会取代 git worktree 吗？

按它自己的描述，是建立在同一个思路上：worktree 提供隔离，AVP 提供整合和落地前的检查。不是取代。

现在算成熟了吗？

从发布页看不出来。Product Hunt 排到 20 名只能说明这个痛点是真的，不能说明实现已经稳定。