许多编码代理都有一个“模式”功能，这在 RAG 或早期代理时代（有点？）是有意义的。现在，他们正在添加子代理，如 Amp（搜索子代理、通用子代理、神谕）和 Claude Code（刚刚推出了一个非常酷的自定义子代理功能）。 模式是重量级的、不可组合的 UI 下拉菜单。子代理通过自然语言调用（“使用神谕来...”，“使用问题子代理来...”，或隐式调用），是完全可组合的，并且完美契合代理工具调用的概念模型。 事实证明，模式和子代理基本上服务于相同的目的。子代理是一个严格更好的解决方案。 因此，具有现有“模式”功能的上一代编码代理在添加子代理时面临艰难的选择：保留模式和子代理（这会令人困惑且复杂），删除模式（这对他们的用户群体来说是痛苦的，因为他们投入了大量精力来创建模式），或者尝试将“模式”概念扩展到包括子代理（这也会令人困惑）。我不羡慕他们。 在 Amp 团队，我们对处于这种令人不快的境地感到恐惧，因为我们错误判断了代理编码未来的发展方向，需要进行痛苦的产品更改。我们在 Amp 之前构建的产品上犯过所有这些错误（而且我们在 Amp 上也会犯很多错误）。这就是为什么我们对添加新的 UI 概念有着极高的标准，为什么我们优先考虑具有强直觉的团队成员，以及为什么我们为模型和中位开发者在 6-12 个月后而不是今天的状态进行构建。在这种情况下，我相信这种方向使我们做出了正确的决定（没有模式，只有可组合的子代理）。 我们很幸运能够为非常聪明、开放思想和前瞻性的开发者构建，他们经常通过几乎所有渠道分享他们的反馈，除了信鸽。我们已经很好地了解了你们中的许多人。我们根本看不到你们或我们自己真的喜欢“模式”。但是当 @thorstenball 构建了子代理和神谕，并说要使用它们，只需这样说（“使用神谕来...”）而不是从某个下拉菜单中选择时，这对我们和你们所有人来说都感觉正确，也感觉到这正是模型的发展方向。对此他值得称赞，也感谢我们出色的用户看到了未来。 只是想分享一下我们如何看待这些事情的幕后故事，以及为什么我们在某些事情上可能显得极端或僵化。 ...请继续关注这个周末，我将承认我在我们最具争议的常被忽视反馈（FIFs）之一上是错误的，并将进行更改，感谢大量反馈，结果我并没有忽视。