Google把跨仓库开发藏了3个月，开发者发现后集体破防|Google|agent|后端|命令提示符|服务器|知名企业|谷歌

Antigravity（反重力）上线时，没人注意到那个叫Agent Rules的按钮。直到有人把前端和后端拆成两个仓库，才发现Google埋了个彩蛋——零配置跨仓库开发，手动操作直接归零。

这不是概念演示。我用两个空目录实测：一个前端React，一个Go后端，Agent Rules写三行自然语言，AI自动在仓库之间跳来跳去改代码。整个todo应用从prompt到跑通，我只点了两次确认。

01 为什么单仓库开始让人窒息

Antigravity开箱即用的脚手架很香。Next.js、Vite+React，小项目几分钟搭完。但代码量过一定阈值后，单仓库会像膨胀的行李箱——东西全塞进去了，找什么都得翻个底朝天。

关注点分离（separation of concerns）变成空话。本该独立的前端组件和后端API，开始在import语句里偷偷牵手。改一个按钮样式，CI跑完全部测试用例；动一行数据库schema，前端构建莫名其妙挂掉。

拆仓库是本能反应。前端一个repo，后端一个repo，团队各管一摊，提交历史干净，部署流水线互不干扰。但代价也很实在：一个功能要改两边，开发者得在两个IDE窗口之间反复横跳，上下文切到头晕。

更麻烦的是AI辅助。Antigravity的Agent Manager再聪明，默认也只盯着一个目录。你让它"给登录功能加个验证码"，它改完前端表单，后端接口原封不动——它根本不知道另一个仓库存在。

跨仓库开发的核心矛盾：人知道要联动，AI不知道。

02 Agent Rules：把"常识"写进AI的DNA

Antigravity没有Linked Workspace功能。官方没做跨仓库原生支持，但留了一扇后门。

Agent Rules藏在设置里，作用是定义Agent的"默认行为模式"。无论用户输入什么prompt，Agent先读一遍规则，再开始干活。激活模式设成always on，规则会在每次交互时自动生效，不需要手动触发。

我的配置很直白：

前端目录在/path/to/frontend，后端目录在/path/to/backend（Go、net/http、SQLite）。当前端改动需要API或后端配合时，同步修改后端仓库。保持双仓库一致。

三句话，没有JSON，没有YAML，纯自然语言。Antigravity的Agent读到这段，会在每次任务开始前检查：这件事要不要动后端？

实测todo应用时，我给的prompt是"做一个带登录的待办事项应用，支持增删改查"。Agent的第一反应是确认权限——"我需要同时操作frontend和backend目录，是否继续？"

点完确认，它先钻进后端目录，搭Go服务器、写SQLite表结构、起net/http路由。后端跑通后，无缝切到前端，React组件里自动调了刚写好的API。整个过程我没有切换窗口，没有复制粘贴接口定义。

规则的本质是给AI建立"项目全景图"。人知道两个仓库是一对，现在AI也知道了。

03 这套玩法的边界在哪

Agent Rules不是万能胶。我测了几组边缘情况，发现它的能力半径很清晰。

文件路径必须写绝对路径。相对路径在Agent切换工作目录时会失效，这是目前最大的配置陷阱。另外，规则描述越具体，执行越稳定。"保持同步"太模糊，"API路由变更时同步修改前端fetch调用"才够明确。

并发修改需要小心。如果两个人同时让Agent操作同一对仓库，Git冲突不可避免。Antigravity没有内置锁机制，团队使用得自己搭流程。我的做法是：Agent改完代码后必须人工review再提交，不给AI直接push的权限。

MCP（Model Context Protocol，模型上下文协议）服务器能补全最后一环。原文提到可以"plug in MCP Servers to pass richer context"，实测把数据库schema、API文档接进MCP后，Agent跨仓库决策的准确率明显上升。没有MCP时，它偶尔会猜错字段类型。

性能方面，跨仓库任务的响应比单仓库慢30%左右。Agent需要额外时间分析两个目录的依赖关系，但这个开销远低于人工切换上下文的成本。