15个代码库逼疯程序员，Claude Code用户用10个机器人

一个人同时维护15个代码库，横跨Go、Rust、TypeScript、Python、C++五种语言——这不是大厂架构师的日常，而是独立开发者Elijah Manor的真实工作流。他用Claude Code（Anthropic推出的AI编程助手）管理这些项目时，发现了一个被多数人忽视的死结：AI在单个仓库里表现优异，一旦跨仓库协作，立刻变成需要人工喂奶的婴儿。

复制粘贴上下文、手动追踪PR依赖关系、盯着看不懂全局的代理瞎忙——这三件事消耗了他80%的精力。

他的解决方案是造了一套叫"ttal"的协调系统：10个专门的Claude Code代理，通过Telegram群组实时同步。听起来像过度工程？他最初也这么想，直到试过所有"标准答案"后发现，问题根本不在工具，而在认知框架。

单仓库神话：Moon也救不了的语言巴别塔

Manor并非反单仓库派。他用Moon管理单仓库，承认其在统一构建、依赖可视化上的价值。但当技术栈膨胀到五种语言，单仓库的边际收益转负。

每种语言有自己的构建工具链、CI流水线、依赖管理哲学。Go的模块代理、Rust的Cargo.workspace、Python的虚拟环境地狱——强行塞进一个仓库，Moon能做的是"编排"，不是"融合"。Manor的实测阈值是3-4种语言，超过后拆分更干净。

这不是理论洁癖，是Claude Code生态的真实缺口。官方论坛里，跨仓库工作流是高频痛点，但多数讨论停留在"怎么让单个会话访问多个目录"，没触及核心矛盾。

Git子模块是另一个经典陷阱。它能固定仓库版本组合，给不了跨仓库协调、共享上下文、并行执行。更麻烦的是，子模块和worktree（并行代理工作的基础设施）兼容性极差——而worktree正是让多个Claude Code实例同时操作同一仓库不同分支的关键。

子模块解决的是"版本锁定"，Manor需要的是"任务路由"。这是两个维度的问题。

官方方案：/add-dir的上下文税

Claude Code原生支持跨仓库探索：手动执行/add-dir，会话开始读取新目录。功能存在，体验割裂。

每次切换都消耗上下文窗口容量。Claude Code的上下文不是无限 buffet，是精打细算的预算。读一个仓库的代码结构、依赖关系、近期提交，动辄吃掉几万token。切三个仓库，预算烧掉一半，还没开始写代码。

Manor的ttal系统把"读"和"写"彻底分离。ttal ask是一个纯bash的轻量代理，专门负责探索——从任意仓库（--repo）、任意项目（--project）、甚至网页（--web）收集信息，生成结构化报告，再注入到主会话。

关键设计：探索代理不污染主会话的上下文。主会话的Claude Code实例（通常是Opus模型）保持专注，只处理需要深度推理的"写"任务。

更细的成本控制：ttal ask运行在极简bash循环上，可以换用任何快速廉价模型。Manor用的是MiniMax M2.7 HighSpeed——探索不需要天才，需要速度和便宜。Opus的配额留给真正的思考工作。

单会话 orchestration：最隐蔽的性能陷阱

这是多数人踩过的坑，包括Manor早期自己。给一个Claude Code会话开放所有仓库权限，让它规划并实施跨仓库功能。听起来高效，实则灾难。

上下文窗口迅速膨胀。代理频繁"迷路"——在Rust仓库里写Go语法，把TypeScript的接口定义粘贴到Python文件。规划和执行质量双降，因为认知负荷超过了模型的有效带宽。

Manor的反思很直接：别让一个会话同时做orchestration（协调）、planning（规划）、execution（执行）。管理者代理握有大局，工人代理专注细节——一个仓库、一个任务、一个worktree。

这套分工的物理载体是Telegram。10个代理在群组里实时同步状态：哪个worker完成了API契约更新，哪个blocked在依赖冲突，哪个需要重新规划。人类开发者扫一眼聊天记录，比翻十几个终端窗口高效十倍。

不是炫技，是对Claude Code当前架构的务实补丁。Anthropic没有提供原生多代理协调，社区自己长出了解决方案。

ttal的本质：一层薄薄的胶水

Manor反复纠正一个误解：ttal不是更好的IDE，不是更智能的monorepo工具，甚至不是传统意义上的"框架"。

它是一层胶水，粘合Claude Code的现有能力，填补"跨仓库读取"和"单仓库写入"之间的断层。核心洞察来自对问题本身的重新定义——不是"怎么让单个会话访问多个仓库"，而是"怎么让读取自由流动，同时保持写入的聚焦"。

这个区分直接影响成本结构。探索用廉价模型，执行用高端模型，人类监督用IM工具——三层资源各归其位。

目前ttal是Manor的私人工具，但设计哲学已经清晰：AI编程助手的下一代竞争，不在模型能力，在 orchestration 层的工程化。谁能用最低的认知 overhead 协调多个代理、多个仓库、多种模型，谁就能让10倍代码库规模变得可管理。

最后一个细节：Manor的Telegram群组里，每个代理有固定头像和昵称。不是人性化包装，是快速视觉识别——在信息洪流中，一眼认出谁在说话，比省下的几毫秒更有价值。

当你的第16个仓库创建时，你会选择复制粘贴上下文，还是养第11个机器人？