@dzhng: 我发现自己越来越倾向于将 monorepo 结构化成微服务（即使严格来说它们不是微服务）……

X AI KOLs Following 新闻
monorepo microservices ai-context software-engineering coding token-consumption

摘要

作者讨论了使用像Codex这样的AI工具扩展monorepos的挑战，指出随着代码库增长，令牌消耗增加，并建议可能需要松耦合模块来处理AI上下文限制。

Kanary的monorepo每月增长10万行代码，目前已经达到了约45万行。 与此同时，Codex的令牌消耗也在同步加速。 换句话说，随着代理探索的文件数量增加，每个任务的令牌消耗也会上升——嗯，这显然是一个自然结果，如果你仔细想想。 但以快进方式观察这一增长过程，让我在直觉上深感震撼。 我想知道在大型项目中处理这个问题的最佳方式是什么。 即使在我自己的项目中，由于macOS和iOS共享一些代码，我也无法完全分离monorepo内的搜索空间。 鉴于AI上下文不能大幅扩展，似乎唯一的选择是让模块更加松耦合？
查看原文
查看缓存全文

缓存时间: 2026/08/24 22:03

Kanary的代码库每月增长十万行代码， 目前已累计至约四十五万行。

与此同时，Codex的token消耗量也呈现同步加速态势。

这意味着随着智能体探索的文件数量增加， 每项任务所需的token消耗也随之上涨—— 细想之下，这显然是自然而然的结果。

但通过快进式观察这一增长过程， 仍从直觉层面带来了强烈冲击。

我不禁思考，如何在大型项目中应对这一现象才最为妥当。

即使在我自己的项目中，由于macOS与iOS共享部分代码， 也无法在代码库内完全隔离搜索空间。

考虑到AI上下文窗口不会大幅扩展， 难道唯一可行的方案就是增强模块间的松耦合性吗？

相似文章

单体AI是未来吗？

Reddit r/ArtificialInteligence

讨论单体AI系统是否可持续，将其与软件单体进行类比，并提出由专业化的微服务式智能体协同工作可能是未来的方向。