以前我觉得 Monorepo 是大厂专属：仓库太大、规则太多，维护成本高。
但开始用 Coding Agent 后，我改观了。
它解决的不是“代码放一起更方便”，而是让 Agent 看见一次需求的完整上下文。
一个头像上传，为什么会牵出一串仓库？
看似只是前端加个上传按钮，实际常常要连着改数据库、后端 API、类型或 SDK、Web，以及测试。
多仓库时，Agent 可能只在 api 仓改完就停了。其他仓库对它而言，是看不见的上下文墙；后续要靠人拆 PR、发版本、排合并顺序。
Monorepo 的价值在这里很直接：一次全局搜索，就能找到同一类型、接口和测试的所有消费者。一次需求，也更容易做成一次完整变更。
选仓库边界，别只看团队和服务
过去常按团队边界、服务边界拆仓库。
现在还该多问一句：这些代码会不会经常一起变化？
如果 Web、API、SDK、公共类型和数据库总是联动，硬拆成五个仓库，得到的未必是优雅边界，可能只是更多协调成本。
我的判断标准很朴素：高频一起改的代码，值得放近一点。
但别把所有东西都塞进一个巨仓
Monorepo 也有代价。多个 Agent 同时改公共类型、锁文件、路由或配置，冲突会非常快地堆起来。
所以更实用的答案不是“Monorepo 取代 Polyrepo”，而是混合式架构：
- 产品内部高频联动的 Web、API、SDK、共享类型放进产品级 Monorepo；
- 权限、部署节奏、生命周期相对独立的支付、基础设施、安全等系统继续独立仓库。
仓库边界也是并发安全边界。Agent 越多，这句话越重要。
面向 Agent 的 Monorepo，需要这些护栏
不是把目录搬到一起就够了。至少要有独立工作区、增量 CI、依赖图谱、小粒度 PR、权限规则和合并队列。
这样 Agent 才能在完整上下文里修改，又不会把主分支推入冲突和反复重跑 CI 的循环。
写代码越来越便宜后，真正昂贵的是：给 Agent 正确上下文，并让大量变更安全合并。
Meta（发布信息）
建议标题
- Agent 时代，我又开始用 Monorepo 了
- Monorepo 不是大厂专属，Agent 更需要它
- 为什么 Agent 开发让我重新看 Monorepo？
- 仓库怎么拆？多看一个“变更边界”
正文描述
Coding Agent 让“仓库边界”不只是代码管理方式，也成了上下文边界。本文用一个头像上传需求说明：高频联动的代码适合收进产品级 Monorepo；真正独立的服务仍应保留独立仓库。适合正在设计 Agent 协作研发流程的团队参考。
参考资料
- 《Agent 时代，我为何重新拾起 Monorepo》：
content/post/agent-monorepo/index.md - Google 与 Meta 的 Monorepo 工程实践（原文概念说明中提及）
话题标签
#Monorepo #AIAgent #CodingAgent #软件工程 #研发效能 #程序员 #架构设计 #CI
封面文件
cover.png（已生成并验证：PNG，1086×1448）