許多編碼代理都有一個「模式」功能，這在 RAG 或早期代理時代（有點？）是有意義的。現在他們正在添加子代理，例如 Amp（搜索子代理、一般子代理、神諭）和 Claude Code（剛剛推出了一個非常酷的自定義子代理功能）。 模式是重量級的、不可組合的 UI 下拉菜單。子代理通過自然語言調用（「使用神諭來...」、「使用問題子代理來...」或隱式），是完全可組合的，並且完美融入代理工具調用的概念模型中。 事實證明，模式和子代理基本上服務於相同的目的。子代理是一個更好的解決方案。 因此，擁有現有「模式」功能的舊一代編碼代理在添加子代理時面臨艱難的選擇：保留模式和子代理（這會令人困惑且複雜）、刪除模式（這對他們的用戶群來說是痛苦的，因為他們投入了很多精力來創建模式），或者試圖將「模式」概念擴展到包括子代理（這也會令人困惑）。我不羨慕他們。 在 Amp 團隊，我們對於在未來錯誤判斷代理編碼的方向而需要做出痛苦的產品變更感到恐懼。我們在 Amp 之前的產品上犯過所有這些錯誤（而且我們在 Amp 上也會犯很多錯誤）。這就是為什麼我們對添加新的 UI 概念有著極高的標準，這也是為什麼我們優先考慮具有強烈直覺的團隊成員，並且這就是為什麼我們為模型和中位開發者在 6-12 個月後的狀態而不是今天進行設計。在這種情況下，我相信這種取向使我們做出了正確的決定（沒有模式，只有可組合的子代理）。 我們很幸運能夠為非常聰明且開放思維/前瞻性的開發者構建，他們經常通過幾乎所有渠道分享反饋，除了信鴿。我們已經很好地了解了你們中的許多人。我們根本看不到你們或我們自己真的喜歡「模式」。但是當 @thorstenball 建立了子代理然後是神諭，並說要使用它們，只需這樣說（「使用神諭來...」）而不是從某個下拉菜單中選擇時，這對我們和你們所有人來說都感覺正確，這也感覺像是模型的發展方向。對他來說，致敬，並感謝我們出色的用戶看到了未來。 只是想分享一下我們如何思考這些事情的幕後故事，以及為什麼我們在某些事情上看起來可能極端或僵化。 ...敬請期待這個週末，當我承認我在我們最具爭議的經常被忽視的反饋（FIFs）之一上錯了，並將進行更改，這要感謝大量的反饋，結果我並沒有忽視。