Tôi đã nảy ra một ý tưởng vào cuối tuần, vì vậy tôi đang rất thích thú khi xây dựng một giao diện dòng lệnh (CLI) lập trình AI. Hình ảnh bên dưới hiển thị giao diện khởi động. Tôi đặt tên cho nó là "DDUDU DDUDU~"—ý tưởng này nảy ra khi tôi đang ngân nga một giai điệu nào đó.
Như mọi người đã biết, tôi nghĩ nhiều người trong số các bạn giờ đã nhận thức được tầm quan trọng của khung bảo vệ (harness) bao bọc một mô hình cũng quan trọng không kém hiệu năng của chính mô hình đó. Ngay cả với cùng một mô hình, kết quả cũng có thể khác nhau đáng kể tùy thuộc vào khung bảo vệ mà nó chạy trên đó, vì vậy tôi muốn tập trung hơn vào khía cạnh thiết kế và tinh chỉnh nó. Ban đầu, tôi đã sử dụng các công cụ hiện có bằng cách thêm các plugin, tương tự như OMO hoặc OMC, nhưng đến một lúc nào đó, tôi tự hỏi liệu mình có nên thử xây dựng nó từ đầu hay không. Tôi đã cân nhắc việc lắp ráp nó dựa trên ý tưởng về một khu vực có thể tùy chỉnh như Raspberry Pi, nhưng tôi cũng muốn thử tạo giao diện người dùng của riêng mình như một bài tập học tập. Vì thiết kế là khía cạnh quan trọng nhất của ý tưởng mà tôi nghĩ đến, cuối cùng tôi đã chuyển hướng sang nghiên cứu và tự xây dựng nó từ đầu.
Trải nghiệm gần đây của tôi khi sử dụng OpenCode và OMO khá tích cực, và tôi muốn phân tích lý do tại sao chúng lại tốt như vậy và kết hợp điều đó vào dự án của riêng tôi ngay từ đầu. Hiện tại, vì tôi đã đăng ký nhiều dịch vụ (Claude, Codex, Gemini), cấu trúc liên quan đến việc tái sử dụng thông tin đăng nhập cục bộ hiện có trong khi xếp chồng các tổ hợp quản lý ngữ cảnh và công cụ mà tôi mong muốn lên trên chúng. Bởi vì điều này liên quan đến việc làm việc trên nền tảng kiến thức về cơ sở hạ tầng và thiết kế được xây dựng bởi các dịch vụ khổng lồ—làm cho nó gần giống với công việc tùy chỉnh hơn (ngay cả công việc sản xuất cũng được thực hiện bằng Codex)—nên gọi nó là "từ đầu" có vẻ hơi quá. Tuy nhiên, tôi bắt đầu điều này bởi vì việc tìm ra cách kết hợp các mảnh ghép đó lại với nhau là một lĩnh vực mà bạn chỉ có thể cảm nhận được bằng cách tự mình thực hiện.
Đây là những tính năng hiện có và những điều mà nhiều người trong số các bạn có thể đã quen thuộc, nhưng khi tôi xây dựng mọi thứ từ đầu, tôi nhận ra rằng đây đều là những yếu tố cần xem xét. Tóm lại:
[1] Gọi và Định tuyến Mô hình. Như bạn đã biết từ kinh nghiệm, mỗi nhà cung cấp đều xuất sắc ở các lĩnh vực khác nhau. Tôi đang cố gắng xây dựng một cấu trúc phân chia các chế độ và tuyến đường dựa trên nhiệm vụ: sử dụng một mô hình mạnh mẽ cho việc điều phối đòi hỏi phán đoán phức tạp, một mô hình nhanh cho việc thực thi lặp đi lặp lại đơn giản, và một mô hình khác nữa cho thiết kế hoặc ra quyết định.
[2] Cấu hình công cụ. Nếu bạn xem xét các tác nhân mã hóa khác nhau, sự kết hợp của các công cụ vô cùng đa dạng. Phạm vi rất rộng, từ những điều cơ bản như nhập/xuất tệp và thực thi shell đến tìm kiếm cơ sở mã, tra cứu ký hiệu và ủy quyền nhiệm vụ cho các tác nhân khác. Chúng tôi đang phân tích từng công cụ để hiểu tại sao nó lại cần thiết. Chúng tôi cũng liên tục phối hợp xem phần nào nên được tích hợp sẵn và phần nào nên được chuyển sang các phần mở rộng như MCP.
[3] Quản lý ngữ cảnh. Điều này liên quan đến việc điền vào một cửa sổ ngữ cảnh giới hạn chỉ với thông tin hiện đang cần thiết. Mặc dù có vẻ như toàn bộ cuộc hội thoại có thể được bao gồm, nhưng hiệu suất thực tế sẽ giảm nếu ngữ cảnh không cần thiết tích lũy. Tôi đã đặc biệt quan tâm đến việc nén ngữ cảnh trong một thời gian và tôi đang xem xét các khía cạnh như khi nào và nén bao nhiêu, và làm thế nào để đảm bảo người dùng không bị mất luồng của họ ngay cả sau khi nén.
[4] Bảo trì phiên và trạng thái. Con người thường tiếp tục công việc họ đang làm trước đó, nhưng từ góc nhìn của mô hình, mỗi lượt là một yêu cầu hoàn toàn mới. Cần có một luồng để tiếp tục hoặc phân nhánh các phiên, hoặc để tóm tắt các phiên dài và chuyển chúng sang nhiệm vụ tiếp theo. Chúng tôi cũng đang giải quyết các vấn đề ở đây như cô lập các nhiệm vụ được ủy quyền bằng cách sử dụng cây công việc git để ngăn chúng can thiệp vào nhiệm vụ chính và di chuyển các nhiệm vụ chạy dài sang nền để tránh chặn luồng chính.
[5] Xác minh và Khôi phục. Thay vì viết mã hoàn hảo ngay lần đầu tiên, tôi đang dành thời gian tạo một vòng lặp hoàn chỉnh, trong đó tôi viết mã, xác minh, sửa lỗi nếu mã bị lỗi, chuyển mã cho một tác nhân khác nếu cần thiết và áp dụng mã vào không gian làm việc thực tế nếu mã thành công. Tôi cũng đang thử một quy trình làm việc trong đó các kết quả đã được xác minh được lưu trữ trong bộ nhớ để chúng có thể được sử dụng lại khi các nhiệm vụ tương tự phát sinh.
[6] Bộ nhớ. Tôi đang thử nghiệm một cấu trúc trong đó tôi chia ngữ cảnh nhiệm vụ của phiên hiện tại, những gì đã học được trong các phiên trước, kiến thức cấu trúc của cơ sở mã và các quy tắc và thủ tục lặp lại, và xử lý thời gian lưu giữ và phương pháp lưu trữ khác nhau cho mỗi phần. Thay vì tìm ra câu trả lời ngay, tôi vẫn đang trong giai đoạn thử nghiệm các tổ hợp khác nhau.
[7] Giới hạn quyền hạn và sự tin tưởng. Đây là vấn đề về mức độ tự chủ cần trao cho tác nhân. Cho phép mọi thứ là nguy hiểm, và việc hỏi mỗi lần sẽ làm chậm mọi thứ. Tôi đang thiết lập một cấu trúc trong đó cho phép/xác nhận/chặn được chia nhỏ theo công cụ, và mức độ quyền hạn tổng thể có thể được chuyển đổi từng bước. (Nhưng thành thật mà nói, điều này không khác nhiều so với các phương pháp được AI khuyến nghị.)
[8] Giao diện người dùng/Trải nghiệm người dùng. Điều cần thiết là có thể nhìn thoáng qua những gì tác nhân hiện đang làm, trạng thái của các tác vụ nền và trạng thái kết nối của các công cụ bên ngoài. Ban đầu tôi đã xây dựng TUI bằng Ink, nhưng nó quá nặng, vì vậy tôi đã chuyển sang Ratatui dựa trên Rust; xét các yếu tố như IME và khả năng sử dụng, đây thực sự là một lựa chọn tuyệt vời. (Điều tôi học được từ việc này là sức mạnh của OpenCode không chỉ nằm ở thiết kế mà còn ở việc họ đã tạo ra các giao diện người dùng dựa trên văn bản (TUI) xuất sắc.) Cá nhân tôi thích TUI và thường chú trọng đến thiết kế gọn gàng và khả năng đọc hiểu trong terminal, vì vậy tôi đang tập trung vào việc đảm bảo thông tin có thể được hiểu nhanh chóng và không gây nhầm lẫn bằng cách sử dụng màu sắc và bố cục. Vì điều này đáp ứng cả chức năng và sở thích cá nhân, nên tôi dành nhiều thời gian nhất cho nó.
Ngoài ra, điều thú vị là khi tôi xây dựng, những vấn đề mới liên tục xuất hiện cần xem xét, chẳng hạn như cấu trúc dữ liệu tổng thể của hệ thống, các lệnh gạch chéo và phương pháp hiển thị thông báo. Tôi vẫn đang trong giai đoạn sửa đổi các chức năng cơ bản và tôi sẽ chia sẻ lại khi đạt được kết quả tốt hơn các công cụ hiện có.
Mục tiêu của tôi là đến ngày tôi củng cố công cụ của mình dựa trên những gì mình đã có và xây dựng một công cụ mô-đun tốt hơn cả Raspberry Pi, cho phép mọi người dễ dàng tạo ra các công cụ CLI của riêng họ.
