週末我一直在興致勃勃地開發一個AI編程命令行界面（CLI），這要歸功於我腦海中突然冒出的一個想法。下圖是它的啟動界面。我把它命名為“DDUDU DDUDU”，靈感來源於我哼唱這首歌的時候。 眾所周知，模型運行的框架與模型本身的性能同樣重要。即使是同一個模型，運行在不同的框架上，結果也會大相徑庭。我希望專注於設計方面，並進一步完善它。最初，我使用現有的工具，通過添加插件（例如OMO/OMC）來實現，但後來我覺得從零開始構建一個可能更有意思。我考慮過基於樹莓派那種開放式定製區域的理念來構建，但我也想嘗試自己設計用戶界面來學習。由於設計是這個概念最重要的方面，我最終決定從頭開始研究並構建它。 我最近在使用 OpenCode 和 OMO 的過程中獲得了非常棒的體驗，因此我想深入剖析它們的優勢所在，並從零開始將它們整合到我的項目中。目前我已經訂閱了許多服務（Claude、Codex、Gemini），所以我打算複用現有的本地憑據，並在此基礎上添加我所需的上下文管理和工具組合。雖然稱之為“從零開始”可能有些誇張，因為它是一個基於現有服務的基礎架構和設計知識庫構建的自定義項目（甚至生產環境的工作也是使用 Codex 完成的）。然而，我之所以啟動這個項目，是因為我知道自己需要親身體驗，才能更好地理解如何構建這些組件。 這些都是現有的功能，你們中的許多人可能已經很熟悉了，但由於我是從零開始構建的，所以我必須考慮所有這些因素。總結如下： [1] 模型調用和路由。正如您可能從經驗中瞭解到的，每個提供商都有其自身的優勢。我嘗試通過將模式劃分為任務來構建路由：一個用於需要複雜決策的穩健編排模型，一個用於簡單迭代執行的快速模型，以及另一個用於設計和設計決策的模型。 [2] 工具配置。在研究各種編碼代理時，我發現了各種各樣的工具組合。其範圍從文件 I/O 和 shell 執行等基本操作，到代碼庫搜索、符號導航以及將任務委派給其他代理等。我們將逐一檢查每個工具，並分析其必要性。我們還會不斷調整內置功能的數量以及移除 MCP 等擴展的功能。 [3] 上下文管理。這涉及到在有限的上下文窗口中僅填充當前所需的信息。雖然包含整個對話看似可行，但積累不必要的上下文實際上會降低性能。我一直對上下文壓縮特別感興趣，思考何時壓縮以及如何壓縮，以及如何確保用戶流程在壓縮後仍然保持完整。 [4] 會話和狀態維護。雖然人類自然會繼續執行之前的任務，但從模型的角度來看，每一次操作都是一個全新的請求。我們需要一個流程，允許我們恢復或分支會話、總結長時間的會話，並將其移至下一個任務。委託的任務可以使用 Git 工作樹進行隔離，以避免干擾主任務；長時間運行的任務可以移至後臺，以避免阻塞主流程。這也是我們正在解決這些問題的地方。 [5] 驗證和恢復。我並沒有試圖一次性編寫出正確的代碼，而是專注於創建一個完整的循環，在代碼編寫完成後對其進行驗證，修復任何錯誤，並在必要時將其傳遞給另一個代理，如果驗證通過，則將其應用到實際的工作區。我還在嘗試一種工作流，將驗證結果保存在內存中，以便在遇到類似任務時可以重用。 [6] 內存。我正在嘗試一種結構，它允許針對當前會話的工作上下文、從過去會話中吸取的經驗教訓、代碼庫的結構知識以及重複的規則和流程設置不同的保留期限和存儲方法。目前我還沒有找到最佳方案，仍在嘗試各種組合。 [7] 權限和信任邊界。問題在於應該賦予代理多大的自主權。完全允許所有操作很危險，而每次都請求權限又會降低其速度。我正在開發一種結構，允許對每個工具進行細粒度的權限/確認/拒絕，並允許整體權限級別逐步過渡。（不過說實話，這與人工智能推薦的方法並沒有顯著差異。） [8] 用戶界面/用戶體驗。我需要能夠一目瞭然地看到代理當前正在執行的操作、後臺任務的狀態以及外部工具連接的狀態。我最初使用 Ink 開發了 TUI，但它過於臃腫，所以我改用了基於 Rust 的 Ratatui。輸入法和易用性方面的選擇非常明智。（這讓我意識到 Opencode 的優勢不僅在於其設計，還在於其 OpenTUI 的卓越品質。）我個人非常喜歡 TUI，並且對終端的簡潔設計和易讀性有著近乎痴迷的追求。因此，我致力於通過顏色和佈局，使信息儘可能快速便捷地呈現。這方面我投入的時間最多，因為它既滿足了功能需求，也符合我的個人偏好。 除此之外，整個系統的數據結構、斜槓命令和通知顯示方式也在不斷發展，這令人興奮。我仍在努力改進一些基本功能，一旦取得比現有框架更好的成果，我會分享更多信息。 我的目標是在現有框架的基礎上進行增強，並構建一個比樹莓派更優秀的模塊化框架，讓每個人都能輕鬆創建自己的命令行工具。 github.com/subinium/ddududdudu