我們花了幾個月構建AI智慧體，然後刪除了它們

在過去幾個月裡，Runnit團隊投入了大量精力將AI智慧體整合到其平臺中。他們構建了多個智慧體，每個都有特定的職責：一個負責規劃，一個負責研究，一個負責排程，另一個負責寫作。這些智慧體都配備了精心設計的提示詞、獨特的行為和各自的專業領域。當時，這似乎是正確的架構——原始LLM的上下文視窗較小（64k-128k），將工作分解為專業智慧體不僅是更清晰的做法，而且是產生哪怕半精確結果的必要條件。每個智慧體只需理解一個問題，從而更有效地利用其可用上下文。

然而，隨著模型不斷改進，團隊逐漸意識到他們仍在圍繞過去的限制進行設計。在測試具有更大上下文視窗的新模型時，他們發現這些模型能夠在同一對話中自然切換不同任務，而無需變成完全不同的助手——只要在正確的時間獲得正確的資訊，它們就可以同時進行規劃、寫作、研究和推理。這迫使他們思考一個簡單的問題：這些真的需要是獨立的智慧體嗎？

最終，答案是否定的。於是他們刪除了所有智慧體。團隊圍繞一個單一智慧體（名為Ru）重構了架構，該智慧體在需要時載入能力。研究不是智慧體，排程不是智慧體，寫作不是智慧體——它們是能力和指令，是可以在任務載入、完成後解除安裝的專業知識。這一改變看似微小，卻極大地簡化了幾乎所有方面：現在有一個一致的業務理解、一個對話、一個記憶、一個組織知識儲存的地方。

當速度至關重要時，同一智慧體可以簡單地建立自身的並行例項，每個例項載入所需指令完成各自工作，然後彙總結果。從外部看，它仍然並行工作，但底層是同一個智慧體解決不同部分的問題。團隊還刪除了大量複雜性：不再需要維護幾十個單獨的提示詞，協調不同智慧體之間的交接，或擔心不同智慧體在演進中逐漸偏離。

當然，這並不意味著專業智慧體已過時——在某些情況下，隔離工作、使用不同模型或分離許可權仍有充分理由。但作者認為，許多開發者仍在沿用為早已不存在的模型而做出的架構決策。如果今天重新開始構建Runnit，他們不會首先問“我們應該構建哪些智慧體？”，而是會問“單一智慧體需要哪些能力？”有時，進步不是增加另一個層次，而是意識到你不再需要它了。