在過去幾個月裏，Runnit團隊投入了大量精力將AI智能體整合到其平台中。他們構建了多個智能體，每個都有特定的職責：一個負責規劃，一個負責研究，一個負責調度，另一個負責寫作。這些智能體都配備了精心設計的提示詞、獨特的行為和各自的專業領域。當時，這似乎是正確的架構——原始LLM的上下文窗口較小（64k-128k），將工作分解為專業智能體不僅是更清晰的做法，而且是產生哪怕半精確結果的必要條件。每個智能體只需理解一個問題，從而更有效地利用其可用上下文。
然而，隨着模型不斷改進，團隊逐漸意識到他們仍在圍繞過去的限制進行設計。在測試具有更大上下文窗口的新模型時，他們發現這些模型能夠在同一對話中自然切換不同任務，而無需變成完全不同的助手——只要在正確的時間獲得正確的信息，它們就可以同時進行規劃、寫作、研究和推理。這迫使他們思考一個簡單的問題：這些真的需要是獨立的智能體嗎？
最終，答案是否定的。於是他們刪除了所有智能體。團隊圍繞一個單一智能體（名為Ru）重構了架構，該智能體在需要時加載能力。研究不是智能體，調度不是智能體，寫作不是智能體——它們是能力和指令，是可以在任務加載、完成後卸載的專業知識。這一改變看似微小，卻極大地簡化了幾乎所有方面：現在有一個一致的業務理解、一個對話、一個記憶、一個組織知識存儲的地方。
當速度至關重要時，同一智能體可以簡單地創建自身的並行實例，每個實例加載所需指令完成各自工作，然後彙總結果。從外部看，它仍然並行工作，但底層是同一個智能體解決不同部分的問題。團隊還刪除了大量複雜性：不再需要維護幾十個單獨的提示詞，協調不同智能體之間的交接，或擔心不同智能體在演進中逐漸偏離。
當然，這並不意味着專業智能體已過時——在某些情況下，隔離工作、使用不同模型或分離權限仍有充分理由。但作者認為，許多開發者仍在沿用為早已不存在的模型而做出的架構決策。如果今天重新開始構建Runnit，他們不會首先問“我們應該構建哪些智能體？”，而是會問“單一智能體需要哪些能力？”有時，進步不是增加另一個層次，而是意識到你不再需要它了。