OpenClaw in Your Hand: Building a Physical AI Terminal for Local LLM Agents

1. Một thiết bị lạ dưới tầng hầm

Lech mở đầu bằng một câu chuyện mà ai cũng thấy quen. Chắc hẳn ai trong chúng ta cũng từng lên kế hoạch dọn dẹp một lần, và anh cũng vậy: anh dành hẳn một cuối tuần để dọn tầng hầm. Anh xuống đó, định dọn sạch mọi thứ, vứt bỏ cái máy giặt cũ. Rồi anh nhìn vào một góc và nhận ra có thứ gì đó kỳ lạ nằm trên sàn.

Anh nhặt nó lên, nhìn kỹ cái thiết bị lạ. Nó trông hơi quen, nhưng cũng hơi cũ, giống đồ từ thập niên 80: có bàn phím, nhưng màn hình thì kỳ quặc, và tất nhiên phủ đầy bụi. Anh cầm nó trên tay và hoàn toàn bất ngờ khi thấy thiết bị có một cái shell, và nó đang bật. Thế là anh dùng "siêu năng lực" của mình với terminal, gõ vào đó một câu hỏi đơn giản: "Who am I?", tức là "Tôi là ai?". Và thiết bị trả lời theo cách kỳ lạ nhất anh có thể tưởng tượng: bằng ngôn ngữ tự nhiên.

Rồi anh thú nhận: câu chuyện vừa kể có thể là một câu chuyện rất hay để làm marketing. Nhưng thật lòng, điều anh muốn chỉ đơn giản là build một thiết bị vừa là đồ vật vật lý, vừa AI-native, kiểu một thiết bị đến từ tương lai.

Sau đó anh mới chào khán giả. Tên anh là Lech Kalinowski, anh có bằng PhD về vật lý, và hôm nay anh muốn giới thiệu một thiết bị, một backend và cả một hệ thống mà anh đã build trong vài tháng vừa qua.

2. Từ một cái remote cho OpenClaw tới ý tưởng hai màn hình

Mọi chuyện bắt đầu vì một nhu cầu rất giản dị: anh chỉ muốn build một cái remote controller để điều khiển instance OpenClaw đang chạy trên chiếc NVIDIA DGX Spark của mình.

Câu chuyện đơn giản thế này: khi lần đầu nghĩ về LLM, bạn không nghĩ tới audio, cũng không nghĩ tới generative video hay ảnh. Thứ đầu tiên bạn nghĩ tới là text. Rồi anh nảy ra một ý: có lẽ mình có thể dùng một loại màn hình tốt hơn để đọc và gõ khi làm việc với LLM.

Tất nhiên trên thị trường đã có electronic paper (e-paper). Nhưng anh nhận ra e-paper có thể hơi chậm. Nó hoàn hảo để đọc, nhưng nếu bạn muốn đưa text vào một cách động, liên tục thay đổi, thì có lẽ bạn cần một màn hình nhanh hơn. Thế là trong thiết kế của mình, anh dùng một kết nối đơn giản: một màn hình OLED nhỏ, đơn sắc, ghép với một màn hình e-paper.

Với cách tiếp cận dual display đơn giản đó, anh nhận ra mình có thể build một terminal khá mạnh mà lại tiết kiệm năng lượng để "chơi" với con claw của mình.

3. Một hệ điều hành AI-native trên microcontroller

Tất nhiên phía sau ý tưởng đó có rất nhiều chuyện phức tạp. Một mặt, anh chỉ muốn build một cái remote. Nhưng mặt khác, anh thấy trên thị trường có một ngách thật sự: các hệ điều hành AI-native.

Khi bắt đầu nghĩ kỹ hơn về chuyện này, anh nhận ra mình có thể build một hệ thống như vậy cho mục đích riêng, mà không cần đến những chiếc máy tính siêu mạnh, chỉ cần những microcontroller nhỏ.

Anh thiết kế hệ thống gồm bốn lớp chức năng, mà về sau trên thiết bị chúng hiện ra như bốn mode:

• Shell nội bộ để điều khiển chính cái terminal: system settings, cấu hình cơ bản, kết nối Wi-Fi.
• Assist và Control: hai phần sinh ra từ ý tưởng build một thiết bị AI-native, một bên để trò chuyện với LLM, một bên để giao việc cho agent.
• RPG mode: một thứ đã thực sự làm anh bất ngờ, và anh hứa sẽ giải thích ở phần sau.

4. Prototype đầu tiên và bài toán render trên hai màn hình

Rồi anh cho xem bản prototype đầu tiên. Ở phía sau trong ảnh là chiếc DGX Spark, phía trước là hai màn hình. Màn hình thứ nhất là live surface, tức phần động: bạn gõ gì thì toàn bộ text hiện ngay ở đó. Khi bạn kích hoạt một hành động, tức là bấm Enter, thì toàn bộ phần render cũng diễn ra trên màn hình thứ hai, màn hình e-paper bistable.

Nhưng để có được một trải nghiệm người dùng rõ ràng và một giao diện rõ ràng, có rất nhiều chuyện phức tạp, rất nhiều công nghệ và rất nhiều bước phải làm. Anh đã thử rất nhiều cách khác nhau để render đúng trên hai màn hình, để vẽ giao diện cho chuẩn. Giao diện đó là thứ anh dùng để điều khiển LLM, nhận câu trả lời, và làm bất cứ điều gì anh muốn với DGX Spark thông qua OpenClaw.

Một trong những cách tiếp cận là dùng các static buffer cố định và render những ảnh một bit lưu sẵn trong bộ nhớ. Nghĩa là các trang nằm trong vùng nhớ đã cấp phát trước. Không có markdown engine, và không có malloc ở phía MCU.

5. Bên trong vỏ máy: MCU, linh kiện và hệ thống nguồn

Anh muốn cho mọi người thấy hệ thống thật sự phức tạp đến mức nào. Và anh nói rõ: không phải vì anh thích dùng nhiều linh kiện. Lý do là có một nhu cầu rất lớn phải build một hệ thống quản lý nguồn (power management), bởi trong quá trình build prototype anh đã làm cháy hai cái màn hình. Anh cần chắc chắn rằng dòng điện và điện áp ổn định nhất có thể.

Bên trong có một MCU là ESP32, một microcontroller dual-core. Có một màn hình OLED, bàn phím, một encoder (núm xoay), và tất nhiên là bộ nguồn đã nhắc tới ở trên.

Nhưng một thiết bị AI-native end-to-end không đơn giản như vậy, vì mức tiêu thụ điện cao và vì "cơn đói" compute của thiết bị. Vì thế anh đã tạo cả một backend đầy đủ, phần kế tiếp nói về nó.

6. Backend: firmware Vault, OpenClaw và model chạy local

Kiến trúc anh trình bày như sau: trước hết là firmware Vault được deploy trên terminal. Phía sau nó là một backend lớn, xử lý toàn bộ phần agentic work với OpenClaw và xử lý LLM.

Anh nhấn mạnh rằng trong buổi trình bày hôm nay, thiết bị được kết nối với model open source GPT 120 tỷ tham số, tức gpt-oss-120b. Anh serve model đó theo cách tối ưu nhất có thể, dùng hệ thống serving TensorRT-LLM của NVIDIA. Rồi anh expose nó theo kiểu OpenAI, qua một LLM proxy, vì anh đã đâm vào rất nhiều bức tường với các model open source khác: không phải model nào cũng khớp với kiểu API của OpenAI.

Như đã nói, ý tưởng đầu tiên là build và "chơi" với OpenClaw qua cái terminal này, và đây là những gì anh làm được với nó. Trong ảnh ví dụ, anh gõ một lệnh kiểu "viết một ví dụ Java và lưu nó trên máy local của tôi", và OpenClaw, với sự hỗ trợ của LLM, đã làm xong việc đó.

7. Field notes: những thứ không chạy như dự tính

Tiếp theo là field notes của anh, những thứ không diễn ra như mong đợi, tức là các bài học xương máu.

• Software I2C. Anh đi dây cho các linh kiện và mọi thứ không chạy đúng. Hóa ra có cách điều khiển I2C cho đúng mà không cần gắn thêm điện trở pull-up vật lý nào: làm I2C bằng phần mềm.
• GPIO 13. Ở chân này có một lỗi im lặng (silent failure). Anh phải chuyển sang một chân khác để chắc chắn mọi thứ chạy đúng.
• Bộ nguồn. Anh phải build lại regulator, cả khối nguồn, vì regulator đã giết chết OLED và những phần mỏng manh của màn hình. Chuyện này tốn của anh rất nhiều thời gian, và chờ linh kiện thay thế từ thị trường mất rất lâu, vài tuần liền.
• Chất lượng linh kiện. Encoder rẻ và kém chất lượng tạo ra rất nhiều nhiễu khi xoay. Anh phải thêm pull-up và hàn thêm tụ điện vào đó.

8. RPG mode: phần làm chính tác giả bất ngờ nhất

Rồi tới phần vui nhất, phần anh thích nhất, vì nó thực sự làm anh bất ngờ. Mọi người đã biết có một phần lớn tên là RPG, và đằng sau nó là một câu chuyện có lẽ hơi buồn.

Anh chưa bao giờ chơi RPG trên giấy. Tức là kiểu cùng một đám bạn tới một căn hộ, mở một cuốn sách, cử một người làm game master, và chơi một game nhập vai thuần text thật sự. Bao nhiêu năm trôi qua, anh chưa từng thử. Nhưng giờ anh đã build một game RPG và một console cho anh trải nghiệm thuần khiết của những game nhập vai dựa trên text (role-playing game).

Anh thấy chuyện này hơi buồn cười, vì thiết bị kiểu này thực ra là một sự kết hợp hoàn hảo cho loại game đó. Anh build NPC và memory xung quanh chúng. Anh tạo ra mood của thế giới, nội dung, các điềm báo, và tận dụng mọi lợi thế của LLM để build trải nghiệm game nhập vai tốt nhất từ trước tới nay.

9. Bốn thế giới và chuyện dùng generative AI để làm game

Anh tạo ra bốn thế giới khác nhau. Một mặt, anh muốn có thứ gì đó liên quan tới cyberpunk. Mặt khác, anh muốn một thế giới kiểu The Witcher, tức là một thế giới fantasy có rồng. Nhưng thế giới anh thích nhất là khoảng hư không ở đâu đó sâu trong vũ trụ, giữa deep space.

Theo anh, đây là một ví dụ rất tốt về cách chúng ta có thể dùng generative AI để build game. Một mặt, anh generate nhân vật, thế giới của họ, bản đồ, kỹ năng. Rồi tất cả được chuyển đổi bằng đúng cơ chế anh đã mô tả ở đầu buổi, cơ chế cấp phát bộ nhớ một bit. Nghĩa là mọi bức ảnh đều được chuyển thành các ma trận, thành các map một bit để màn hình e-paper vẽ được.

10. Mọi peripheral đều có thể hỏng mà máy vẫn chạy

Một điều quan trọng nữa: thiết bị này thực sự "chống đạn". Nếu OLED không chạy, e-paper vẫn chạy. Nếu "cardboard" không chạy, ý anh là bàn phím CardKB, thì bạn vẫn còn encoder. Nếu Wi-Fi hỏng, bạn luôn có thể dùng shell local.

11. Một khoảng trống trên thị trường và provisional patent

Một chuyện vui khác là mảng sở hữu trí tuệ. Anh đã làm một ít research trong lĩnh vực này và thấy ai cũng muốn build thiết bị xoay quanh giao diện audio, quay video, những thứ tương tự.

Nhưng với những nơi yên tĩnh, khi bạn chỉ muốn ngồi xuống, giữ bình tĩnh và chơi game RPG của mình, bạn không cần những màn hình nhiều màu, mạnh mẽ, không cần đèn LED nhấp nháy đủ màu, không cần mọi thứ gây xao nhãng, quảng cáo, trang web và những thứ khác. Đôi khi bạn chỉ muốn ngồi xuống và làm đúng việc của mình với OpenClaw, hoặc đơn giản là chat với LLM, đọc và viết trong một môi trường yên tĩnh không có gì làm xao nhãng.

Và đó là một ngách trên thị trường. Vì vậy anh cũng quyết định nộp một provisional patent trong lĩnh vực này, và biết đâu trong tương lai nó sẽ đưa một thiết bị thương mại ra thị trường.

12. Vài con số của dự án

Anh đưa ra vài con số. Trong dự án này anh đã push 130 commit, khoảng ba tháng làm việc. Hai màn hình, mỗi màn hình làm một việc khác nhau. Bốn mode, bốn thế giới để chơi game. Tổng cộng có mười sáu class, tức là bạn có thể generate thế giới RPG bên trong thiết bị. Firmware thì thực sự rất nhỏ gọn và chạy cực nhanh. Và mọi thứ được cấp nguồn bằng một cell pin duy nhất, theo lời anh là một cell lithium polymer.

13. Ba takeaway

Rồi anh để lại vài nhận xét, vài takeaway:

• Chọn màn hình hợp với việc. Trên thị trường có rất nhiều loại màn hình.
• Để model tránh xa phần cứng ("keep the model off the metal"), vì model thực sự rất nặng. Nghĩa là hiện tại chúng ta chưa có những model, tức là LLM, chạy được thật sự trên những MCU siêu nhỏ.
• Theo dõi narrative. Context thực sự quan trọng với LLM, và nói chung là narrative, không phải những con số.

14. Demo: Vault đang chạy

Anh đã quay sẵn một video demo cách dùng thiết bị, cách nó hoạt động, như một phiên dùng cuối, và anh vừa phát vừa bình luận.

Thiết bị khởi động và kết nối vào mạng Wi-Fi local. Sau đó là màn hình chào và màn hình chính. Màn hình nhỏ là OLED.

Anh dùng bàn phím gõ lệnh help đơn giản. Ở đây bạn thấy mọi thứ có thể làm với thiết bị. Có cả tutorial cho phần game và tutorial cho chính thiết bị. Khi bật máy lần đầu, bạn cần, hay đúng hơn là có thể, đi qua tutorial để học cách dùng. Bạn không bắt buộc phải làm, nhưng có thể.

Tiếp theo là dùng agent OpenClaw. Ngay lúc này anh đang kiểm tra chiếc DGX Spark của mình và muốn xem dung lượng ổ đĩa. Và kết quả đây.

Giờ tới phần anh thích nhất, phần game. Bốn thế giới: Elderglen, Neon Abyss, The Hollows và Void Reach. Bạn có thể chọn nhân vật của mình. Và LLM generate mọi thứ. Mọi thứ ở đó đều được generate: ảnh, tính cách của các nhân vật. Rồi có mood, có một vết nứt (breach); bạn đang ở deep space và không thể lặn sâu vào thế giới kia.

15. Thật ra đây là một chiếc Game Boy để chơi với LLM

Hết video. Anh chỉ ra một điều buồn cười: một game như thế này, không có chút đồ họa 3D nào, lại đang dùng con chip tiên tiến nhất của NVIDIA gắn trong DGX Spark, vì đó chính là backend anh chuẩn bị cho buổi demo này. Tức là một game yên tĩnh với giao diện text lại cần tới chiếc máy, chiếc card đồ họa mạnh nhất thế giới.

Và một điều nữa: bài trình bày này nói về một thiết bị cầm tay để điều khiển agent và OpenClaw bằng LLM local. Nhưng nói chung, nó thật ra là về một chiếc Game Boy, một thiết bị để chơi với LLM.

Anh cảm ơn mọi người đã lắng nghe, và cảm ơn rất nhiều sự hỗ trợ của Callstack, vì anh đang làm việc tại Callstack trong vườn ươm công nghệ (technological incubator) của công ty, và toàn bộ công việc này được công ty Callstack hỗ trợ.