跳到主内容
@wquguru
精选88elvis技巧与观点

Agent Harness 构建者谈子代理:并行与协调的取舍

If you build agent harnesses, this is important.

原文
发到 X
推荐理由

Agent 工程师必看,这篇直接点破了多子代理架构在协调和上下文管理上的痛点,给出一主一从的最佳实践建议,值得收藏对照自己的系统设计。

If you build agent harnesses, this is important.

如果你正在构建智能体框架(agent harnesses),这一点很重要。

Should you avoid subagents, or can they be useful?

你应该避免使用子智能体(subagents),还是说它们也能发挥作用?

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.

我记得在 Claude Code 中使用过子智能体,我发现它们主要用于并行化研究工作。我不信任它们在编码等其他方面的表现。

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.

如果编排器(manager)智能体能够协调任务和子智能体(executors),那么子智能体就能很好地工作。

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.

和 Eric 一样,我发现目前将一名编排器智能体和一名执行器子智能体结合通常效果最好。如果你尝试加入更多的子智能体,情况就会开始崩溃。

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.

多子智能体架构的崩溃点在于协调环节,我认为这正是 Eric 所指出的问题。而且在大多数情况下,成本并不值得。

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.

所以,当你在 X 上看到有人吹嘘他们的拥有 100+ 个智能体、深度超过 2 层的复杂多智能体系统时,你几乎可以肯定那是编造的。

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.

这让我想到我最近一直在强调的一点:避免使用模型动态生成框架。它们的成本过高,而且很难让它们在实际领域任务中发挥作用(参见 ant 的动态工作流)。但这方面的内容改天再谈。

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.

我还有更多想分享的,但你的经验如何?很好奇。

更进一步:量化金融体系

看懂新闻只是起点——沿量化金融路径,把它变成能交付的工程能力

进入量化体系 →

相似阅读

关联信息,但可能不是同一事件