今年早些时候，我曾认为monorepo（单仓库）是AI原生开发显而易见的最佳选择。
理由在于上下文闭合（context closure）。
当代码、测试、设计决策、基础设施和开发规则都存在于同一个执行环境中时，编码代理（coding agent）的工作效果会更好。它不应该等待人类从Slack粘贴决策、解释某个人脑中的约定，或者从它无法更新的系统中检索需求。
Monorepo让这一切变得更容易。把产品和开发上下文放在一个地方，给代理提供搜索工具，仓库就变成了一个代理可以工作的封闭环境。
我仍然相信上下文闭合很重要。改变的是我对仓库到底闭合了什么的理解。
共享harness的真正难题
我曾参与一场讨论，内容是在一个大型仓库中引入共享的代理harness（代理运行框架）。技术方案并不是最难的部分。更难的问题是，工程师们已经在使用的工作流会发生什么变化。
如果共享harness要求人们停止使用他们个人的技能、指令和工作流，他们会真的照做吗？
没有人敢给出肯定的回答。
到那时，仓库里已经不只是代码了。它包含了多种部分重叠的、告诉代理如何工作的方式，有些是团队检入的，有些是个人维护的。引入一个公共harness不再是一次安装，而是一次迁移——从人们每天依赖的系统上迁移出去。
两种失败方向
我也见过相反方向的失败。在组织还没学会如何设计、评估和维护一个可靠的harness之前就集中化，共享系统就会变成天花板。糟糕的指令影响所有人。审查者承担纠错成本。AI的使用停留在浅层，因为被批准的路径不如有能力的个人自己构建的方案有效。
这两种方式似乎朝着相反的方向失败。过早集中化，组织会把还没学会做好的事情标准化。过晚标准化，本地工作流已经根深蒂固，难以替换。
代码放在哪里，远不如谁能在整个代码库中定义代理应该如何工作、解决冲突的上下文、并在代码和模型都变化时保持系统正确来得重要。
代理能力改变了一切
当编码代理能力较弱时，monorepo的论点更有说服力。
一个只能维持短任务的代理，从一切都在附近中获益巨大。仓库边界就是实际的上下文边界。跨越边界的任务需要更多提示、更多检索基础设施、更多人工协调。把相关系统放在一起，减少了代理遗漏重要信息的可能性。
我现在使用的长上下文模型行为不同。在能访问相关仓库和工具的情况下，它们可以跨项目搜索、追踪依赖、比较实现、做出协调一致的修改，而不需要把每个仓库当作独立单元对待。
热门跟贴