OpenBot tự host: AI coworker có máy tính riêng, mọi hành động qua gateway kiểm soát

Nhiều team IT muốn dùng trợ lý AI làm việc thay mình nhưng không muốn giao dữ liệu, tài khoản và quyền hành động cho dịch vụ bên ngoài. Khi trợ lý mở trình duyệt, đăng nhập, chạy lệnh hay sửa file, câu hỏi quan trọng không còn là nó trả lời hay không mà là nó được phép làm gì và có dấu vết nào để đối soát không.

OpenBot là dự án mã nguồn mở MIT của CopilotKit. Đây không phải chatbot đóng gói sẵn. OpenBot là nền tảng vận hành AI coworker trên hạ tầng của chính bạn. Dữ liệu nằm trong PostgreSQL của bạn. Mỗi bot có máy tính và trình duyệt riêng. Mọi hành động đều qua một gateway duy nhất. Gateway kiểm tra policy và ghi audit trước khi hành động thực thi.

Bài viết dựa trên tài liệu chính thức và repo CopilotKit/OpenBot. Mốc kiểm chứng là ngày 2026-11-01: 9.253 stars, 1.160 forks, release mới nhất v0.2.0 ngày 2026-10-12. Dự án đang ở trạng thái Beta. Nó tự mô tả là template, không phải sản phẩm hoàn thiện, và không có bản hosted. Phần cài đặt dưới đây tổng hợp từ tài liệu. Mình chưa chạy thử.

Vấn đề thực tế: agent càng làm được nhiều việc càng cần một điểm kiểm soát

Agent hiện đại không dừng ở việc sinh văn bản. Nó mở trang web, điền form, đọc file, chạy lệnh shell, cài công cụ hoặc gọi MCP server. Mỗi khả năng đều hữu ích và cũng là một bề mặt rủi ro, vì rủi ro nằm ở hiệu ứng: file bị sửa, lệnh bị chạy, tài khoản bị dùng, dữ liệu bị gửi đi. Chat UI tự host chỉ đặt dữ liệu trò chuyện và key model trên hạ tầng của mình, nhưng thường không cấp cho bot một máy tính riêng, không chặn hành động theo policy trước khi thực thi, và không ghi audit đầy đủ.

OpenBot là gì?

OpenBot là khung vận hành cho các coworker AI. Docker Compose dựng toàn bộ thành phần. Dữ liệu nằm trong PostgreSQL của bạn. Không có model nào đi kèm trong box. Admin tự cung cấp credential cho model. Theo tài liệu của dự án, credential này được mã hóa khi lưu trữ và không bị ghi vào log.

Một bot có trình duyệt riêng với tài khoản đăng nhập riêng, file riêng, và chỉ được dùng những tool đã được cấp.

Kiến trúc: gateway là cửa duy nhất, AG-UI là ngôn ngữ chung

Các thành phần chính

Ở chế độ Compose, hệ thống gồm app web ở cổng 3010. API server chạy ở cổng 3001. Hệ thống còn có một routine worker và PostgreSQL của bạn.

Luồng kiểm soát: từ câu lệnh tới hành động

Người dùng tương tác với bot qua kênh chat, thường là /bot hoặc trang chính. Bot đề xuất một hành động. Gateway đánh giá policy CEL trước khi thực thi, ghi một audit row, rồi mới cho phép hoặc từ chối kèm theo rule vi phạm. Hành động sau đó mới thực thi trên máy tính, file, MCP server hoặc component, và toàn bộ chuỗi đều có thể tra cứu lại.

Bot là endpoint AG-UI, không gắn framework

Trong OpenBot, bot là bất kỳ endpoint nào nói được AG-UI. AG-UI là giao thức mở cho tương tác giữa agent và người dùng. LangGraph, Mastra, CrewAI, Pydantic AI, Google ADK hoặc agent tự viết tay đều có thể trở thành bot. Điều kiện duy nhất là endpoint tuân thủ giao thức.

Cô lập: theo người dùng mặc định, theo bot khi bật Isolated

Mặc định, mỗi người dùng có một container máy tính riêng. Mỗi bot có folder cùng browser profile riêng với tài khoản đăng nhập riêng. Mức cô lập này đủ cho nhiều trường hợp dùng cá nhân hoặc team nhỏ.

Nếu bạn cho bot không tin cậy chạy chung với bot khác, hãy bật tùy chọn Isolated. Tùy chọn này cấp cho bot một container riêng. Khi host hỗ trợ, bạn có thể chạy dưới gVisor bằng biến COMPUTER_RUNTIME=runsc.

Policy CEL fail-closed và con người “take the wheel”

Policy dùng CEL và vận hành theo nguyên tắc fail-closed. Deny được đánh giá trước allow. Thiếu policy thì không cho phép gì. Rule bị lỗi thì từ chối thay vì mở cửa. Một rule có thể xét tên tool, ý định, id của bot và người thực hiện. Rule cũng có thể xét URL và host của trang, câu lệnh, đường dẫn file hay thông tin MCP.

Fail-closed là lựa chọn an toàn nhưng gây ma sát: policy viết thiếu hoặc sai sẽ chặn cả việc hợp lệ, buộc người vận hành lặp lại vòng audit rồi sửa rule.

Phụ thuộc và giới hạn đã ghi nhận

Tài liệu liệt kê các phụ thuộc gồm Docker, Bun 1.4 trở lên, một CopilotKit Intelligence project kèm license, và một model key. Bot proof-of-concept dùng OpenAI.

Hướng dẫn triển khai OpenBot tự host

Điều kiện tiên quyết và phiên bản tham chiếu

Chuẩn bị trước: Docker đang chạy, Bun 1.4+, một CopilotKit Intelligence project kèm license (có free plan), một model key, cổng 3001 và 3010 còn trống, và host đủ tài nguyên để chạy container máy tính. Phiên bản tham chiếu là v0.2.0 phát hành ngày 2026-10-12.

Cài đặt nhanh theo tài liệu

Các bước quick start gồm sao chép file môi trường mẫu, cài dependency, đăng nhập và chọn project CopilotKit, chạy script thiết lập, điền key model, rồi khởi động bằng script đi kèm:

cp .env.example .env
bun install
npx --yes copilotkit@latest login
npx --yes copilotkit@latest project select
bun scripts/setup-learning.ts

Sau đó điền OPENAI_API_KEY vào file .env. Tiếp theo, tạo một key mã hóa riêng thay cho key mẫu trong file ví dụ bằng lệnh openssl rand -base64 32. Key mẫu trong .env.example là key public, chỉ phù hợp cho môi trường local.

Sau khi đã điền key, khởi động toàn bộ hệ thống bằng script đi kèm:

bash scripts/start.sh

Script này khởi động các Docker service, áp dụng migration, chạy API ở cổng 3001, routine worker và app ở cổng 3010, rồi mở http://localhost:3010. Khi muốn dừng hệ thống, dùng script đối ứng bash scripts/stop.sh.

Triển khai bằng một image Docker

Nếu muốn triển khai gọn hơn, OpenBot cung cấp chế độ single-image:

docker run -p 3001:3001 --env-file .env -e EMBEDDED_POSTGRES=on \
  -v openbot-data:/var/lib/postgresql \
  ghcr.io/copilotkit/openbot:latest

Ở chế độ này, mọi thứ, kể cả app web, đều chạy ở cổng 3001 thay vì 3010. Lưu ý quan trọng: file .env được nạp qua --env-file mang sẵn OPENBOT_SINGLE_USER=true, nghĩa là mọi request đều được chấp nhận như một admin. Trước khi cho bất kỳ ai khác truy cập deployment này, phải xóa biến đó khỏi .env và cấu hình sign-in (SAML/OIDC). Nếu đã có database sẵn, hãy bỏ biến EMBEDDED_POSTGRES và đặt DATABASE_URL trỏ tới database đó. Đừng nhầm hai chế độ. Compose tách app 3010 và API 3001. Single-image gộp tất cả về 3001.

Kiểm chứng sau cài đặt và kết quả mong đợi

Một triển khai chưa thể coi là thành công chỉ vì container đã chạy. Hãy kiểm chứng theo ba dấu hiệu. Thứ nhất, app truy cập được tại http://localhost:3010 ở chế độ Compose, hoặc cổng 3001 ở chế độ single-image. Thứ hai, mở /bot, nhờ bot mở news.ycombinator.com và kể lại top story, để xác nhận bot, model key và trình duyệt riêng đều hoạt động. Thứ ba, kiểm chứng audit và policy: nhờ bot điền form tại https://httpbin.org/forms/post, mở /admin/audit để xem hành động đã được ghi, rồi vào /admin/boundaries, thêm một deny rule cho chính hành động đó, thử lại và quan sát thông báo từ chối nêu rõ rule vi phạm.

Lỗi thường gặp và cách xử lý

Dùng Bun 1.3 có thể khiến một số test lỗi. Cách xử lý là nâng lên Bun 1.4+ trước khi kết luận code có vấn đề. Nhầm cổng 3010 và 3001 giữa hai chế độ triển khai cũng rất dễ gặp. Cách xử lý là xác định rõ mình đang chạy Compose hay single-image trước khi mở trình duyệt. Lỗi nghiêm trọng nhất là quên tắt chế độ single-user: file .env.example mang sẵn OPENBOT_SINGLE_USER=true, nghĩa là mọi request đều được chấp nhận như một admin, và chế độ này chỉ dùng cho local.

Sao lưu và rollback

Trước mọi thay đổi, hãy sao lưu hai thứ. Đó là file .env và volume PostgreSQL. Ở chế độ single-image, volume đó là openbot-data.

Rollback cho ứng dụng có thể thực hiện bằng cách ghim lại image hoặc tag đã biết hoạt động, ví dụ v0.2.0. Đừng tiếp tục kéo latest khi bản mới gặp lỗi. Rollback cho policy đơn giản hơn. Bạn sửa hoặc xóa deny rule gây chặn ở /admin/boundaries. Sau đó đối chiếu với /admin/audit để xác nhận hành động đã được phép trở lại.

Đánh giá: ưu điểm, nhược điểm, bảo mật, vận hành

Ưu điểm lớn nhất là quyền sở hữu dữ liệu và hạ tầng, đi kèm một gateway duy nhất cho mọi hiệu ứng. Nhờ đó, audit và policy áp dụng thống nhất cho mọi bot nói AG-UI, không phụ thuộc code của từng agent.

Nhược điểm đầu tiên là OpenBot vẫn là template, không phải sản phẩm đóng gói. Không có bản hosted để fallback, không có package để depend, hành vi có thể đổi nhanh giữa các release, nên phải đọc changelog trước mỗi lần nâng cấp. Vận hành OpenBot cũng nặng hơn một chatbot thông thường.

Về bảo mật, phía đã khẳng định gồm gateway kiểm tra trước thực thi, audit ghi trước hành động, policy CEL fail-closed, credential model mã hóa khi lưu trữ, và sign-in qua SAML hoặc OIDC. Tài liệu không khẳng định các chứng nhận tuân thủ ngành như SOC2 hay ISO, nên đừng gán cho OpenBot những chứng nhận đó. Phía phải tự lo gồm: tắt single-user mode trước khi expose, bảo vệ .env và volume PostgreSQL, giới hạn network cho container máy tính, cân nhắc gVisor cho bot không tin cậy, rà soát rule định kỳ qua /admin/audit.

Về hiệu năng và mở rộng, bài viết chỉ nói trong giới hạn dữ liệu: không có con số đo, nên không đưa kết luận định lượng. Ở mức suy luận định tính, mỗi computer container và mỗi bot Isolated đều tốn tài nguyên riêng; gateway là điểm tập trung vừa là lợi thế kiểm soát vừa là điểm cần theo dõi khi tăng tải; PostgreSQL chứa audit nên dung lượng log tăng theo số hành động.

So sánh với các lựa chọn cùng phạm vi

Tiêu chí so sánh áp dụng đều cho mọi đối thủ. Các tiêu chí gồm: tự host và sở hữu dữ liệu; máy tính hoặc trình duyệt riêng cho bot; gateway policy và audit trước thực thi; không gắn với một framework agent; human takeover; và độ trưởng thành cùng gánh nặng vận hành.

Trợ lý hosted kiểu ChatGPT hay Claude dùng ngay, không cần vận hành. Nhưng dữ liệu và hành động nằm ngoài hạ tầng của bạn, và bạn không có gateway CEL hay audit của riêng mình. OpenBot đổi sự tiện lợi lấy quyền sở hữu và kiểm soát, hợp lý khi kiểm soát quan trọng hơn tốc độ bắt đầu, lãng phí khi nhu cầu thực sự chỉ là hỏi đáp nhanh.

Một điểm dễ nhầm: gateway gọi model API, như chủ đề của bài tự host gateway gọi model AI, kiểm soát việc gọi model (key, model, chi phí), còn gateway của OpenBot kiểm soát hành động của bot sau khi model đã trả lời.

Use case thực tế

Team IT có thể dùng OpenBot cho bot hỗ trợ vận hành: policy giới hạn tool ngay từ đầu, mọi hành động tra cứu được ở /admin/audit, và khi bot gặp bước xác thực, con người tiếp quản rồi trả lại quyền cho bot.

Với homelab, OpenBot có thể chạy bằng Compose hoặc single-image trên server nhà, với General Assistant và Knowledge làm trợ lý hàng ngày; xem thêm bài tự host Coolify làm PaaS Docker.

Với workflow AI và coding-agent, bot có shell trong workspace riêng, xử lý file đã lưu và cài thứ cần thiết, nhưng vẫn qua gateway nên lệnh nguy hiểm có thể bị cấm trước. Theo mình, đây là cách dùng hợp lý nhất.

Kết luận: ai hợp, ai không, và bước tiếp theo

OpenBot hợp với người cần sở hữu hạ tầng, cần audit và policy cho agent, chấp nhận vận hành một dự án Beta, và thích mô hình AG-UI không gắn framework. Điểm mạnh thật sự của nó không nằm ở chatbot mà nằm ở gateway. Gateway là một cửa duy nhất biến ý định của agent thành hiệu ứng.

OpenBot không hợp với người cần SaaS ổn định dùng ngay, người chỉ cần chat hỏi đáp, hay team không có người vận hành Docker, PostgreSQL và policy. Với nhóm này, trợ lý hosted hoặc chat UI tự host sẽ nhẹ hơn, nhanh hơn, và ít rủi ro vận hành hơn nhiều.

Nếu bạn muốn thử, hãy đi theo thứ tự sau. Thứ nhất, thử local theo tài liệu, kiểm chứng bằng /bot kết hợp /admin/audit và một deny rule như mục kiểm chứng ở trên. Thứ hai, tắt single-user mode và cấu hình sign-in trước khi cho bất kỳ ai khác truy cập. Thứ ba, chỉ bật Isolated hoặc gVisor và mở rộng thêm bot khi đã đo tài nguyên và rà soát audit trên workload thật. Thứ tư, theo dõi các release sau v0.2.0 và đừng nâng cấp lên latest mà không đọc changelog.

Tham khảo

• CopilotKit/OpenBot trên GitHub: https://github.com/CopilotKit/OpenBot
• Release v0.2.0 (2026-10-12): https://github.com/CopilotKit/OpenBot/releases/tag/v0.2.0
• Tài liệu chính thức trong repo OpenBot (README và docs): https://github.com/CopilotKit/OpenBot#readme
• Trang dự án OpenBot: https://www.copilotkit.ai/openbot
• Bài liên quan trên phamnam.me: Heldkeys kiểm tra quyền truy cập AI agent, Tự host gateway gọi model AI, Tự host Coolify làm PaaS Docker