@omarsar0 讨论智能体框架中子代理的利弊

如果你在构建智能体框架，这一点很重要。你应该避免使用子智能体，还是说子智能体确实有用？作为一名框架构建者，我的想法是：

我记得在 Claude Code 中用过子智能体，我发现它们在并行化研究方面大多很有用。但我不放心让它们处理编码这类其他工作。实际上，我认为并行化、监控/追踪，以及更好的上下文管理是使用子智能体最有力的几个理由。但这些理由足以抵消成本吗？

这要看情况。对于代码审查，我认为子智能体非常棒，非常适配。而且我喜欢用子智能体能高效完成工作这一点。如果编排器（管理者）智能体能够正确协调任务和子智能体（执行者），子智能体就能很好地工作。

和 Eric 的发现一样，我发现目前一个编排智能体加一个执行子智能体的组合通常效果最好。比如，如果你试着再加入一个子智能体，整个系统就会开始崩溃。有意思的是，这些模式在混合不同模型系列时也能生效。感觉前沿模型就是被训练成能做好这件事的。

协调问题是多子智能体架构失效的原因，我认为这正是 Eric 所指出的。而且在大多数情况下，成本也并不划算。所以当你在 X 上看到有人吹嘘他们有100多个、深度超过2层的多智能体系统时，你几乎可以肯定这是编出来的。

但让我惊讶的是，我们在子智能体方面没取得多少进展。虽然我看过几篇论文和工程博客，分享了在多智能体系统中使用某种留言板或草稿本取得成功的案例。框架工程能做到这么多已经很不可思议了。

这告诉我，也许子智能体可能是一个上下文工程问题，也就是说，当前沿模型的上下文过于多样时，它们的表现就不太好。这很有意思，因为可能前沿模型并没有得到足够的训练，来应对这种情况保持鲁棒性。

这就引出了我最近一直在提出的一个观点：避免使用模型动态生成框架。它们成本过高，而且很难让它们在特定领域任务上正常工作（参见 ant 的动态工作流）。不过这个问题改天再谈。

我仍然认为子智能体是智能体框架中一个有用的原语。对于长周期、复杂任务，我认为它们在提升效率方面会非常有用。例如，在研究自动化任务中，子智能体可以并行探索实验。对于智能体团队，我也认为子智能体仍然有存在价值。

但在我们解决成本或协调问题之前，子智能体模式还需要时间才能被广泛采用。我还有更多内容想分享，但你的体验如何？我很好奇想知道。