Claude Code 中子代理的利弊分析

If you build agent harnesses, this is important. Should you avoid subagents, or can they be useful?...

If you build agent harnesses, this is important. Should you avoid subagents, or can they be useful? My thoughts as a harness builder: I remember using subagents in Claude Code, and I mostly found them useful for parallelizing research. I didn't trust them for other things like coding. In fact, I think parallelization, monitoring/tracking, and better context management are two of the best arguments for using subagents. But are those reasons enough to justify the cost? It depends. For code review, I think subagents are amazing and a great fit. And I like that you can do this efficiently with subagents. Subagents work well if the orchestrator (manager) agent can coordinate the task and the subagents (executors) properly. Like Eric, I have found that combining one orchestrator agent and one executor subagent typically works best right now. If you try, for instance, to add another subagent to the mix, things start to collapse. What's been interesting is that these patterns work even when mixing model families. It feels like frontier models are trained to do this well. Coordination is where multi-subagent architectures fall apart, and I think that's what Eric is pointing to. And the cost is just not worth it in most cases. So when you see someone on X bragging bout their 100+, 2+ levels deep multi-agent system, you almost certainly know it's made up. But it's surprised me that we haven't made much progress on subagents. Although I have seen a few papers and engineering blogs sharing success using a form of message board or scratchpad with multi-agent systems. It's incredible how far harness engineering can take you. This tells me that maybe subagents could be a context engineering problem, i.e., frontier models don't do so well when context is too diverse. This is interesting, as it might be that frontier models simply haven't been trained enough to be robust to this. Which brings me to a point I have been raising more recently on avoiding using models to generate harnesses on the fly. They are cost-prohibitive and really hard to make them work on domain-specific tasks (see dynamic workflows from ant). But more on this another day. I still think subagents are a useful primitive for agent harnesses. For long-horizon, complex tasks, I think they could be extremely useful for improving efficiency. For instance, subagents can explore experiments in parallel in research automation tasks. For agent teams, I also think subagents remain relevant. But until we solve the cost or coordination problem, it will take time for the subagent pattern to be widely adopted. I have more to share, but what has your experience been? Curious to know. eric provencher @pvncher I hate to say it, but if you’re running more than 2 sub agents at time, you’re almost certainly burning tokens for 0 quality gain. Agents don’t trust each other enough to avoid double-checking everyone’s homework. 🔗 View Quoted Tweet 💬 48 🔄 8 ❤️ 93 👀 13911 📊 54 ⚡