Claude Code多Agent协作实战：Subagent分工与弱版TARS构想

引言：AI协作的真正难点是什么？

当我们谈论AI编程工具时，大多数人关注的是单个Agent的能力——它能写多好的代码、能理解多复杂的需求。但一位开发者（B站UP主"路过的阿诚"）花了一整天时间，用Claude Code和DeepSeek V4做了一个更有野心的实验：把项目迭代流程拆成多个Subagent，让主对话去"指挥"小AI干活。

实验的结论出人意料——流程确实跑通了，但真正的难点不在于"能不能分工"，而在于"这些Subagent能不能互相协作"。这个发现，也催生了他构建"弱版TARS"（一个统筹协调多Agent的系统）的想法。

Subagent基础链路：Planner + Packager如何分工

两个Subagent的角色定义

实验的第一步是定义两个功能明确的Subagent：

• Planner（规划者）：负责分析需求，规划本次改动的方案，输出上、中、下三个层级的方案供选择
• AutoPackage（打包者）：负责在代码迭代完成后自动打包项目

这里有一个关键的架构设计值得注意：Subagent拥有独立的上下文。它只会把最终结果带回主对话，不会占用主对话的上下文空间。这一设计的背后，是LLM（大语言模型）最核心的物理限制——token窗口。目前主流模型的上下文窗口从32K到200K token不等，一旦超出就会出现信息"遗忘"或推理质量下降。通过将子任务隔离到独立的Subagent中，主对话只接收最终结果而非冗长的中间推理过程，本质上是一种精妙的"上下文压缩"策略。这意味着Planner在规划时可以进行大量的分析和推理，而这些中间过程不会"污染"主对话的token窗口。

完整工作流程

整个链路的运行顺序如下：

1. 通过主对话调用Planner，让它先规划本次改动
2. Planner返回方案（上/中/下三个层级）到主对话
3. 主对话根据Planner的方案开始迭代代码
4. 代码迭代完成后，调用AutoPackage进行自动打包
5. 打包成功，运行验证

实验结果表明，这条链路可以成功运行。项目从规划到打包的整个流程实现了半自动化——人类开发者只需要在关键节点做决策，具体的规划和打包工作交给对应的Subagent完成。

更大的野心：构想"弱版TARS"多Agent协调系统

从分工到协作的跃迁

跑通基础链路后，一个更大胆的想法自然浮现：如果能有一个高于Planner和AutoPackage的顶层Agent，它有个性、熟悉开发者的习惯，能统筹协调多个Agent，会怎样？

这个顶层Agent被命名为"TAS"——致敬电影《星际穿越》中的机器人TARS。TARS的设计特点是高度自主、拥有可调节的"诚实度"与"幽默感"参数，并能在极端环境下独立做出判断。用这个名字命名顶层协调Agent，暗示了开发者对AI系统更深层的期望：不只是执行指令的工具，而是具备判断力、能根据上下文自主决策的协作伙伴——这与AI Agent领域正在兴起的"Agentic AI"概念高度吻合。TAS的设计目标包括：

• 统筹协调：管理Planner、Coder、Reviewer等多个下级Agent
• 智能决策：Reviewer审查代码后，TAS根据预设原则判断是直接修改还是需要重新规划
• 分级处理：重大变更询问人类意见，不重要的变更直接自动处理
• 个性化：基于开发者之前给定的原则和偏好做出判断

值得一提的是，多Agent协作并非新概念，其理论根基可追溯至1980年代的多智能体系统（MAS）研究。在当代AI编程领域，OpenAI的Swarm框架、微软的AutoGen、以及LangChain的Agent框架都在探索类似架构。这些系统面临的核心矛盾高度一致：如何在保持各Agent专注性的同时，实现高效的跨Agent信息流转——而这正是这次实验撞上的那堵墙。

现实的壁垒：Subagent之间不能互相调用

然而，理想很丰满，现实很骨感。当尝试实现这个架构时，一个硬性限制浮出水面：Claude Code的Subagent之间不能互相调用。

这意味着Reviewer发现问题后，无法直接通知Coder去修复；Coder完成修改后，也无法自动触发Reviewer进行复审。所有的信息流转都必须经过主对话，这大大限制了多Agent协作的灵活性和效率。

这一限制背后，其实是深层的架构设计权衡。允许Agent随意互调会引入循环依赖、死锁和无限递归等风险，同时大幅增加系统的调试难度。业界目前的主流解法包括三类：消息队列（事件驱动架构，Agent通过发布/订阅消息协作）、共享状态存储（如向量数据库作为Agent间的"公告板"，各Agent读写共享记忆）、以及编排层（Orchestrator统一调度，所有Agent只与编排层通信而非彼此直连）。当前Claude Code的架构更接近第三种，但编排层的角色由人类主对话承担，尚未实现自动化。

经过查阅Claude官方文档，确认这确实是当前的架构限制。用原话说就是"创业未半而中道崩殂"。

未来方向：Claude Code的Team功能能否破局

从单兵作战到团队协作

虽然当前的Subagent架构存在限制，但探索并未止步。进一步调研发现，Claude Code正在内测一个团队功能（Team），这可能是突破当前限制的关键。

团队功能的核心理念与TAS的构想不谋而合——让多个AI Agent能够在一个更高层级的框架下协同工作，而不仅仅是各自独立完成任务后汇报结果。从技术路径推测，Team功能很可能引入了某种形式的自动化编排层，使Agent间的信息流转不再完全依赖人类主对话的中转，从而在保持架构安全性的前提下，释放多Agent协作的真正潜力。

这次实验的核心启示

这次实验虽然在"弱版TARS"的实现上暂时受阻，但它揭示了几个重要的行业趋势：

1. 单点自动化的天花板已经可见：单个AI Agent再强大，面对复杂项目时也需要分工协作
2. 上下文管理是关键架构决策：Subagent独立上下文的设计，本质上是在解决LLM的token窗口限制问题
3. Agent间通信协议将成为下一个竞争焦点：谁能率先解决Agent互调的问题——无论是通过消息队列、共享状态还是编排层——谁就能在AI编程工具赛道占据优势
4. 人机协作的边界在动态变化：从"人写代码"到"人指挥AI写代码"，再到"人只做关键决策，AI自行协调完成"，这个演进路径已经清晰可见

总结

这次实验的价值不在于最终是否成功构建了TARS，而在于它清晰地展示了AI编程工具从"工具"向"协作系统"演进的路径和当前的技术瓶颈。Planner + Packager的基础链路证明了多Agent分工的可行性，而Subagent互调限制则指明了下一步需要突破的方向。

对于正在使用Claude Code的开发者来说，当前阶段可以先用Subagent实现规划和打包的自动化，同时关注Team功能的内测进展。而对于整个AI编程领域来说，真正有价值的不是单点自动化，而是AI协作系统——这个判断，可能会在未来一两年内被反复验证。

核心要点

• 通过Claude Code的Subagent功能搭建了Planner（规划）+ AutoPackage（打包）的双Agent协作链路，成功实现项目迭代的半自动化
• Subagent拥有独立上下文，不占用主对话的token空间，这是应对LLM窗口限制的关键架构设计
• 构想了顶层Agent"TAS"来统筹Planner、Coder、Reviewer等多个Agent，但受限于Subagent之间不能互相调用的硬性限制
• Agent互调限制背后是循环依赖与死锁风险的架构权衡，业界主流解法包括消息队列、共享状态存储和编排层三类路径
• Claude Code正在内测Team功能，可能是突破当前多Agent协作限制的关键方向
• 核心结论：未来真正有价值的不是单点自动化，而是AI协作系统