打破单体 Context 瓶颈：从共享上下文到消息传递
在基于大模型的复杂多仓库或单体大仓（Monorepo）重构中，开发者常陷入两难：让单个 Agent 吞下全部仓库的上下文不仅迅速耗尽 Token 额度，还会因上下文杂音导致逻辑幻觉；而让多个 Agent 同时修改同一批文件，则不可避免地引发剧烈的代码冲突与依赖破坏。开发者 Anyesh 在实践中探索出一条清晰路径：基于 Claude Code 自带的会话组队机制，将并发编程中的 Actor 消息传递模型（Message Passing）引入了日常多代理开发。
独占领域驱动：ListAgents 与 SendMessage 原语
这套工作流的核心哲学是“各自管好自己的代码领地，跨界调用只走通信接口”。底层完全依赖 Claude Code 原生暴露的通信原语：
- 会话按仓库隔离（One Session per Repo）：为每一个独立的代码仓库启动一个专属的 Claude Code 进程。该会话长期驻留并只负责理解、维护与变更自身仓库的文件，维护极其纯净、高度局部化的上下文缓存；
- 基于 RPC 理念的消息调度：当 A 仓库（如前端页面）需要 B 仓库（如公共 API 契约或后端微服务）变更接口时，A 并不跨界篡改 B 的源码，而是通过
ListAgents探测对应仓库的活跃会话，再用SendMessage抛出结构化请求； - 在自己的地盘交付验证：B 会话在完全熟悉自身上下文的前提下完成修改、执行本地测试，并将最终契约或调用样例通过消息原路返回给 A。
实测 25 天：81 个会话与 624 条跨仓消息的运行账本
作者披露了从 9 月 18 日至 10 月 12 日期间的高强度实战数据：系统累计跑了 81 个独立会话，跨越 13 个工程项目，会话间自发传递了 624 条协同消息。在任务峰值期，单小时内有 9 个 Agent 会话同时在线并发推进。
为了防止会话在无人监管下失控打架或出现死锁，作者外挂了一套轻量级 Harness 治理脚手架：
- 成本与缓存监控：实时追踪 Prompt 缓存命中率与上下文滑动开销，杜绝重复全量加载；
- 移动端审批推送：当 Agent 触碰破坏性操作或等待高阶人工仲裁时，自动向手机发送即时通知，随时由人类开发者介入；
- 动作熔断 Guard 拦截：记录并过滤非法文件读写尝试，防止 Agent 跨出自己的边界越权修改其他项目。
这种“小而专注、按职责组队”的去中心化模式，为多模块复杂系统的 AI 自动化维护提供了极具参考价值的工程落地范式。
