Đầu tháng 1 năm 2026, một nhóm nhỏ các nhà phát triển đã tập hợp tại sự kiện Claude Code Show & Tell đầu tiên do Michael Galpert tổ chức. Chúng tôi gồm hai mươi người, tò mò về phát triển tác nhân và háo hức chia sẻ kinh nghiệm của mình với các công cụ lập trình AI mới nhất.
Chỉ vài tuần sau, vào ngày 5 tháng 2, Michael Galpert và Dave Morin đã tổ chức sự kiện thứ ba trong chuỗi sự kiện này, nay được đổi tên thành ClawCon, sự kiện OpenClaw SF Show & Tell lần thứ nhất. Hơn 700 người đã tham dự. Không khí vô cùng sôi động. Các nhà đầu tư như Ashton Kutcher đã dành gần một giờ để nghe mọi người trình bày các dự án của mình. Peter Steinberger, người sáng lập OpenClaw, thực sự là ngôi sao tỏa sáng của đêm đó, với mọi người vây quanh ông để đặt câu hỏi, chúc mừng và chụp ảnh tựa sướng.
Làm thế nào mà chúng ta đạt được điều này? Chỉ trong tám tuần, OpenClaw từ một đoạn mã chuyển tiếp tin nhắn WhatsApp dùng vào cuối tuần đã trở thành một trong những dự án mã nguồn mở phát triển nhanh nhất trong lịch sử GitHub, vượt qua 180.000 lượt đánh dấu sao vào đầu tháng Hai. Sự tăng trưởng này không chỉ mang tính lan truyền mà còn chưa từng có tiền lệ.
Theo tôi, chìa khóa không chỉ nằm ở khả năng kỹ thuật, mà còn ở khả năng thương mại hóa sản phẩm. Peter đã xây dựng nền tảng giúp biến khả năng tác nhân từ một công trình nghiên cứu thành thứ mà mọi người thực sự có thể triển khai và sử dụng để hoàn thành công việc.
OpenClaw đã biến “chatbot trả lời tự động” thành “trợ lý hành động”, một trợ lý thường trực chạy trên phần cứng của bạn, có thể truy cập thông qua các ứng dụng nhắn tin và giao diện mà bạn đã sử dụng.
Andrej Karpathy gọi đó là “thứ đáng kinh ngạc nhất, gần giống với thể loại khoa học viễn tưởng cất cánh mà tôi từng thấy.”
Tôi thường rất tò mò về việc học hỏi sâu sắc và hiểu rõ các chi tiết của các khung hoặc sản phẩm AI mới – chứ không chỉ đơn thuần là sử dụng chúng. OpenClaw có vẻ đặc biệt phù hợp với công việc của tôi trong việc xây dựng công ty chuyên về AI đầu tiên tại Axiom và giúp các công ty trong danh mục đầu tư của chúng tôi định hướng kiến trúc tác nhân và chiến lược thiết kế sản phẩm.
Vì là mã nguồn mở, tôi có cơ hội tìm hiểu sâu về mã nguồn và tổng hợp bản phân tích kiến trúc của OpenClaw này, cung cấp hướng dẫn thực tiễn cho những người sáng lập đang xây dựng các kiến trúc tác nhân tương tự.
Giới thiệu
OpenClaw là một nền tảng trợ lý AI cá nhân hoạt động trên cơ sở hạ tầng của riêng bạn: máy tính xách tay, máy chủ ảo VPS, máy Mac Mini trong tủ quần áo hoặc container đám mây. Nó kết nối các mô hình và công cụ AI với các ứng dụng nhắn tin mà bạn đã sử dụng: WhatsApp, Telegram, Discord, Slack, Signal, iMessage, Microsoft Teams và nhiều ứng dụng khác.
OpenClaw coi trợ lý AI của bạn như một vấn đề về cơ sở hạ tầng, chứ không chỉ là một vấn đề kỹ thuật về lời nhắc. Thay vì cố gắng làm cho mô hình học máy (LLM) “ghi nhớ” ngữ cảnh hoặc hoạt động an toàn thông qua các lời nhắc thông minh, OpenClaw xây dựng một môi trường thực thi có cấu trúc xung quanh mô hình, với quản lý phiên, hệ thống bộ nhớ, hộp cát công cụ và định tuyến thông báo phù hợp. LLM cung cấp trí thông minh; OpenClaw cung cấp hệ điều hành.
Bạn kiểm soát nơi trợ lý ảo hoạt động, cách nó định tuyến tin nhắn, các công cụ nó có thể sử dụng và cách các phiên được cách ly. Các lệnh gọi API của mô hình vẫn được gửi đến Anthropic, OpenAI hoặc bất cứ nơi nào mô hình của bạn được lưu trữ; nhưng lịch sử hội thoại, việc thực thi công cụ, trạng thái phiên và tất cả logic điều phối vẫn nằm trên cơ sở hạ tầng của bạn.
OpenClaw hướng đến các nhà phát triển và người dùng chuyên nghiệp muốn có một trợ lý AI cá nhân có thể truy cập từ bất kỳ ứng dụng nhắn tin nào, mà không cần phải giao toàn bộ trải nghiệm cho một trợ lý bên thứ ba được lưu trữ trên máy chủ. Nếu bạn từng muốn có Claude hoặc GPT trong tin nhắn WhatsApp, kênh Slack và cuộc hội thoại iMessage của mình, đồng thời vẫn giữ cho trí thông minh hoạt động trên phần cứng của riêng bạn, OpenClaw sẽ mang đến trải nghiệm đó.
Cách thức hoạt động của OpenClaw: Tổng quan cấp cao
OpenClaw không phải là một lớp bao bọc chatbot xung quanh API dành cho các mô hình AI. Nó là một hệ điều hành dành cho các tác nhân AI. OpenClaw coi AI như một vấn đề về cơ sở hạ tầng: phiên làm việc, bộ nhớ, môi trường thử nghiệm công cụ, kiểm soát truy cập và điều phối.
Mô hình AI cung cấp trí thông minh; OpenClaw cung cấp môi trường thực thi.
OpenClaw sử dụng kiến trúc dạng trung tâm và các nhánh, tập trung vào một Cổng duy nhất đóng vai trò là mặt phẳng điều khiển giữa các đầu vào của người dùng (WhatsApp, iMessage, Slack, ứng dụng macOS, giao diện web, CLI) và tác nhân AI:
- Gateway là một máy chủ WebSocket kết nối với các nền tảng nhắn tin và giao diện điều khiển, chuyển tiếp từng tin nhắn được định tuyến đến Agent Runtime.
- Môi trường thực thi tác nhân (Agent Runtime) chạy vòng lặp AI từ đầu đến cuối, tập hợp ngữ cảnh từ lịch sử phiên và bộ nhớ, gọi mô hình, thực thi các lệnh công cụ dựa trên các khả năng có sẵn của hệ thống (tự động hóa trình duyệt, thao tác tệp, Canvas, các tác vụ theo lịch trình, v.v.) và lưu trữ trạng thái đã cập nhật.
Điểm mấu chốt là OpenClaw tách biệt lớp giao diện (nơi nhận tin nhắn) khỏi môi trường thực thi của trợ lý ảo (nơi trí thông minh và khả năng thực thi được vận hành). Điều này có nghĩa là bạn có một trợ lý ảo duy nhất, có thể truy cập thông qua bất kỳ ứng dụng nhắn tin nào bạn đang sử dụng, với trạng thái hội thoại và quyền truy cập công cụ được quản lý tập trung trên phần cứng của bạn.
Sơ đồ sau đây cung cấp cái nhìn tổng quan về kiến trúc hệ thống (nhấp chuột để phóng to):
Khả năng mở rộng thông qua Plugin
OpenClaw được thiết kế để có thể mở rộng mà không cần sửa đổi mã nguồn cốt lõi. Các plugin mở rộng hệ thống theo bốn cách chính:
- Các tiện ích bổ sung cho kênh: Các nền tảng nhắn tin bổ sung (Microsoft Teams, Matrix, Mattermost, v.v.)
- Các plugin bộ nhớ: Các hệ thống lưu trữ thay thế (kho lưu trữ vector, đồ thị tri thức so với SQLite mặc định)
- Các plugin công cụ : Khả năng tùy chỉnh vượt xa các thao tác tích hợp sẵn của bash, trình duyệt và tệp.
- Các plugin của nhà cung cấp : Các nhà cung cấp LLM tùy chỉnh hoặc các mô hình tự lưu trữ.
Hệ thống plugin hoạt động extensions/và tuân theo mô hình dựa trên khám phá. Trình tải plugin sẽ src/plugins/loader.tsquét các gói không gian làm việc để tìm một openclaw.extensionstrường trong cấu hình của chúng package.json, xác thực dựa trên các lược đồ đã khai báo và tải nóng khi có cấu hình phù hợp.
Các thành phần cốt lõi
1. Bộ chuyển đổi kênh
Mỗi nền tảng nhắn tin đều có bộ chuyển đổi riêng. Một số bộ chuyển đổi được tích hợp sẵn (bạn sẽ tìm thấy chúng trong các thư mục như src/telegram/, src/discord/, src/slack/, src/imessage/, v.v.), và một số khác có thể được thêm vào thông qua các plugin kênh. Các bộ chuyển đổi triển khai cùng một giao diện và chuẩn hóa tin nhắn đến/đi để phần còn lại của OpenClaw không cần quan tâm đến những đặc điểm riêng của từng nền tảng. Mặc dù các nền tảng khác nhau rất nhiều về API và giao thức, nhưng mỗi bộ chuyển đổi đều triển khai một giao diện chung với bốn trách nhiệm chính:
- Xác thực
- Phân tích tin nhắn đến
- Kiểm soát truy cập
- Định dạng tin nhắn gửi đi
Xác thực
Xác thực khác nhau tùy thuộc vào nền tảng. WhatsApp sử dụng phương pháp ghép nối mã QR thông qua thư viện Baileys, lưu trữ thông tin xác thực trong ~/.openclaw/credentials. Telegram và Discord sử dụng mã thông báo bot được cung cấp thông qua các biến môi trường như TELEGRAM_BOT_TOKENvà DISCORD_BOT_TOKEN. iMessage yêu cầu tích hợp gốc với macOS và cần một ứng dụng Tin nhắn được ký đúng cách.
Phân tích tin nhắn đến
Quá trình phân tích tin nhắn đến xử lý thực tế phức tạp của các định dạng dữ liệu khác nhau từ các nền tảng khác nhau. Mỗi bộ chuyển đổi trích xuất văn bản, xử lý các tệp đính kèm đa phương tiện (hình ảnh, âm thanh, video, tài liệu), xử lý các phản ứng và biểu tượng cảm xúc, và duy trì ngữ cảnh hội thoại hoặc trả lời. Lớp chuẩn hóa này có nghĩa là phần còn lại của OpenClaw không cần biết liệu tin nhắn đến từ WhatsApp hay Discord.
Kiểm soát truy cập
Kiểm soát truy cập là nơi diễn ra bảo mật ở cấp độ kênh. Danh sách cho phép chỉ định số điện thoại hoặc tên người dùng nào có thể tương tác với bot của bạn; ví dụ, channels.whatsapp.allowFromchấp nhận một loạt các số điện thoại. Chính sách tin nhắn trực tiếp (DM) kiểm soát cách bot xử lý tin nhắn trực tiếp từ người gửi không xác định. Chính sách mặc định "pairing"yêu cầu phê duyệt trước khi xử lý tin nhắn. Bạn có thể đặt nó để "open"chấp nhận tất cả tin nhắn trực tiếp (không được khuyến nghị) hoặc "disabled"từ chối hoàn toàn. Chính sách nhóm bổ sung thêm một lớp bảo mật, bao gồm các yêu cầu đề cập và danh sách cho phép cụ thể cho từng nhóm.
Định dạng tin nhắn gửi đi
Mỗi nền tảng có ngôn ngữ Markdown riêng, giới hạn kích thước tin nhắn và API tải lên phương tiện riêng. Bộ chuyển đổi xử lý tất cả những điều này, bao gồm cả việc chia nhỏ các tin nhắn dài để tuân thủ giới hạn của nền tảng, hiển thị Markdown một cách phù hợp, tải lên các tệp phương tiện và thậm chí quản lý các chỉ báo đang nhập và thông tin trạng thái.
Đây là ví dụ về cấu hình WhatsApp:
{
"channels": {
"whatsapp": {
"enabled": true,
"allowFrom": ["+1234567890"],
"groups": {
"*": { "requireMention": true }
}
}
}
}2. Giao diện điều khiển
OpenClaw cung cấp nhiều cách để tương tác với Gateway, mỗi cách phù hợp với các trường hợp sử dụng và sở thích khác nhau:
- Giao diện người dùng web
- CLI
- Ứng dụng macOS
- Di động
Giao diện người dùng web
Giao diện người dùng web được xây dựng bằng các thành phần web dựa trên Lit và được phục vụ trực tiếp từ chính Gateway. Khi bạn trỏ trình duyệt đến http://127.0.0.1:18789/ địa chỉ mặc định, bạn sẽ nhận được bảng điều khiển dành cho trò chuyện, quản lý cấu hình, kiểm tra phiên, quản lý nút và giám sát trạng thái hoạt động. Không cần máy chủ web riêng biệt: Gateway xử lý tất cả.
CLI
Giao diện dòng lệnh (CLI), được triển khai thông qua Commander.js bắt đầu từ openclaw.mjsvà xuyên suốt src/cli/program.ts, cho phép bạn điều khiển mọi thứ thông qua dòng lệnh. Khởi động Gateway bằng openclaw gateway. Gọi trực tiếp tác nhân bằng openclaw agent. Ghép nối WhatsApp hoặc Signal bằng openclaw channels login. Gửi tin nhắn theo chương trình thông qua openclaw message send. Chạy chẩn đoán trạng thái bằng openclaw doctor. Hoặc thực hiện thiết lập theo hướng dẫn bằng openclaw onboard.
Ứng dụng macOS
Ứng dụng macOS này có cách tiếp cận khác. Được viết bằng Swift và hoạt động trên nền tảng iOS apps/macos/, nó nằm trên thanh menu của bạn, cung cấp khả năng quản lý vòng đời của Gateway – khởi động, dừng, khởi động lại ngay trong tầm tay bạn. Nó bao gồm chức năng đánh thức bằng giọng nói với lớp phủ nhấn để nói, tích hợp WebChat trong chế độ xem trình duyệt gốc và thậm chí có thể điều khiển các gateway từ xa qua SSH.
Di động
Các thiết bị di động dành cho iOS và Android kết nối với Gateway dưới dạng các nút WebSocket bằng cách khai báo role: "node"trong quá trình bắt tay kết nối. Điều này không chỉ dành cho trò chuyện; các ứng dụng này còn cung cấp các khả năng dành riêng cho thiết bị như truy cập camera, ghi màn hình, dịch vụ định vị và hiển thị Canvas. Gateway có thể kích hoạt các khả năng này bằng node.invokephương thức giao thức, biến điện thoại của bạn thành một phần mở rộng của bộ công cụ của tác nhân.
3. Mặt phẳng điều khiển cổng
Gateway được xây dựng src/gateway/server.tsvà vận hành trên Node.js 22 trở lên. Nó sử dụng wsthư viện WebSocket và mặc định liên kết với địa chỉ 127.0.0.1:18789loopback (chỉ giao tiếp vòng lặp) để đảm bảo an ninh. Đây không chỉ là một bộ định tuyến; nó là nguồn thông tin duy nhất cho toàn bộ hệ thống OpenClaw.
Mọi nền tảng nhắn tin (WhatsApp thông qua thư viện Baileys, Telegram thông qua grammY, Discord sử dụng discord.js) đều kết nối thông qua điểm trung tâm này. Các công cụ dòng lệnh, giao diện người dùng web và ứng dụng di động đều kết nối như các máy khách WebSocket. Khi một tin nhắn đến, Gateway sẽ định tuyến nó qua các kiểm tra kiểm soát truy cập, xác định phiên nào nên xử lý nó và chuyển tiếp đến tác nhân thích hợp. Nó điều phối trạng thái hệ thống bao gồm các phiên, chỉ báo trạng thái hiện diện, giám sát sức khỏe và các tác vụ định kỳ. Và quan trọng hơn, nó thực thi bảo mật thông qua xác thực mã thông báo hoặc mật khẩu cho bất kỳ liên kết nào không phải là vòng lặp ngược và triển khai hệ thống ghép nối cho tin nhắn trực tiếp.
Các nguyên tắc thiết kế ở đây được cân nhắc kỹ lưỡng. Thứ nhất, chỉ có chính xác một Gateway cho mỗi máy chủ: điều này ngăn ngừa xung đột phiên WhatsApp vì giao thức của WhatsApp chỉ hoạt động trên một thiết bị duy nhất. Thứ hai, toàn bộ giao thức đều được định kiểu: tất cả các khung WebSocket đều được xác thực dựa trên JSON Schema, bản thân JSON Schema được tạo ra từ các định nghĩa của TypeBox. Điều này có nghĩa là nếu máy khách của bạn gửi dữ liệu không đúng định dạng, nó sẽ được phát hiện ngay lập tức. Thứ ba, hệ thống hoạt động dựa trên sự kiện chứ không phải dựa trên thăm dò. Máy khách đăng ký các sự kiện như agent, presence, health, và tickthay vì liên tục hỏi “có gì mới?”. Cuối cùng, bất kỳ thao tác nào gây ra tác dụng phụ đều yêu cầu một khóa bất biến, giúp logic thử lại an toàn và ngăn ngừa các hành động trùng lặp. Các kết nối cục bộ (loopback hoặc cùng một tailnet) có thể được tự động phê duyệt, trong khi các kết nối từ xa yêu cầu ký xác thực phản hồi và phê duyệt rõ ràng.
4. Thời gian chạy của tác nhân
Môi trường thực thi Agent Runtime, được triển khai trong src/agents/piembeddedrunner.ts, là nơi các tương tác AI thực sự diễn ra. Nó sử dụng thư viện Pi Agent Core ( @mariozechner/pi-agent-core) và tuân theo mô hình gọi hàm kiểu RPC với phản hồi dạng luồng.
Ở cấp độ cao, thời gian chạy thực hiện bốn việc mỗi lượt: (1) giải quyết phiên, (2) tập hợp ngữ cảnh, (3) truyền phản hồi của mô hình trong khi thực hiện các lệnh gọi công cụ và (4) lưu trữ trạng thái đã cập nhật trở lại đĩa.
Giải quyết phiên
Khi một tin nhắn đến, hệ thống sẽ xác định trước tiên phiên nào nên xử lý nó. Tin nhắn trực tiếp từ bạn sẽ được ánh xạ tới mainphiên . Tin nhắn trực tiếp đến qua kênh sẽ được ánh xạ tới dm:. Cuộc trò chuyện nhóm sẽ được ánh xạ tới group:. Phiên không chỉ là ID – chúng là ranh giới bảo mật. Mỗi loại phiên có thể có các quyền và quy tắc hộp cát khác nhau (ví dụ: maincó thể chạy các công cụ trên máy chủ, trong khi các phiên dm/ groupcó thể mặc định sử dụng danh sách cho phép chặt chẽ hơn và cách ly Docker).
Lắp ráp theo ngữ cảnh
Sau khi phiên được giải quyết, môi trường thực thi sẽ tập hợp ngữ cảnh cho mô hình. Thông thường, nó sẽ:
- Tải lịch sử phiên từ các tệp phiên JSON đã được lưu trữ (đảm bảo mỗi phiên duy trì tính liên tục theo thời gian).
- Xây dựng lời nhắc hệ thống động bằng cách đọc các tệp cấu hình không gian làm việc và kết hợp chúng thành một ngăn xếp lệnh duy nhất.
- Nó truy xuất bộ nhớ thông qua tìm kiếm ngữ nghĩa (ví dụ: các lượt thoại hoặc ghi chú liên quan trước đó) để mô hình chỉ thấy bối cảnh lịch sử phù hợp nhất thay vì một bản ghi chép ngày càng dài ra.
Ngữ cảnh được tập hợp này sau đó được truyền đến nhà cung cấp mô hình đã được cấu hình (Anthropic Claude, OpenAI GPT, Google Gemini, hoặc thậm chí là các mô hình cục bộ) để bạn nhận được phản hồi từng token một thay vì phải chờ một khối dữ liệu cuối cùng duy nhất.
Vòng lặp thực thi
Khi mô hình phản hồi, môi trường thực thi sẽ theo dõi các lệnh gọi công cụ và chặn chúng. Nếu mô hình yêu cầu một công cụ (ví dụ: chạy lệnh bash, đọc/ghi tệp, mở trình duyệt và trích xuất dữ liệu từ trang web), môi trường thực thi sẽ thực hiện công cụ đó, có thể bên trong một hộp cát Docker tùy thuộc vào chính sách hộp cát của phiên. Mỗi kết quả của công cụ được truyền ngược trở lại quá trình tạo mô hình đang diễn ra, quá trình này sẽ tích hợp kết quả và tiếp tục. Sau khi lượt hội thoại hoàn tất, môi trường thực thi sẽ lưu trữ trạng thái phiên được cập nhật (thông báo, lệnh gọi/kết quả công cụ và bất kỳ trạng thái nào khác được theo dõi) vào ổ đĩa.
Kiến trúc nhắc nhở hệ thống
OpenClaw xây dựng các lời nhắc bằng cách kết hợp nhiều nguồn khác nhau:
Các tệp cấu hình không gian làm việc :
AGENTS.md– Các hướng dẫn cốt lõi cho tác nhân (mặc định được đóng gói). Cơ sở hoạt động: những gì tác nhân được phép làm, các ràng buộc toàn cục và các quy tắc không thể thương lượng áp dụng cho tất cả các phiên.SOUL.md– Hướng dẫn về tính cách và giọng điệu (tùy chọn). Phong cách giọng nói và tương tác: cách nhân viên hỗ trợ nói và cấu trúc câu trả lời, nhưng không bao gồm hành vi của công cụ hoặc các giới hạn bảo mật.TOOLS.md– Quy ước công cụ dành riêng cho người dùng (tùy chọn). Ghi chú cá nhân của bạn về cách sử dụng các công cụ trong môi trường của bạn, không phải là một sổ đăng ký công cụ. OpenClaw tự động cung cấp định nghĩa công cụ cho mô hình.
Ngữ cảnh động (được thiết lập theo từng lượt):
- Lịch sử phiên họp – Các tin nhắn gần đây từ cuộc trò chuyện hiện tại
- Kỹ năng (
skills/) – Định nghĩa kỹ năng và hướng dẫn sử dụng (bắt buộc để kỹ năng tồn tại). Các tệp chứa hướng dẫn có cấu trúc để hoàn thành các nhiệm vụ cụ thể bằng cách sử dụng các công cụ có sẵn, ví dụ như sổ tay hướng dẫn hoặc quy trình vận hành tiêu chuẩn./SKILL.md - Tìm kiếm trong bộ nhớ – Các cuộc hội thoại trong quá khứ có nội dung tương tự nhau, cung cấp ngữ cảnh hữu ích.
Định nghĩa công cụ (được tạo tự động):
- Các công cụ tích hợp sẵn (
src/agents/pi-tools.ts,src/agents/openclaw-tools.ts) – bash, trình duyệt, thao tác tệp, canvas và các khả năng cốt lõi. - Công cụ plugin (được đăng ký thông qua
api.registerTool(toolName, toolDefinition)) – Các công cụ tùy chỉnh được thêm vào thông qua hệ thống tiện ích mở rộng.
Hệ thống cơ bản:
Pi Agent Core – Các lệnh cơ bản từ thư viện thời gian chạy của tác nhân
Tất cả các yếu tố này kết hợp lại thành lời nhắc hệ thống cuối cùng, được gửi đến mô hình cùng với lịch sử hội thoại và tin nhắn hiện tại của người dùng. Cách tiếp cận có thể kết hợp này có nghĩa là bạn có thể thay đổi hành vi, phong cách và năng lực thực hiện nhiệm vụ của tác nhân bằng cách chỉnh sửa các tệp trong không gian làm việc mà không cần chạm vào mã nguồn, đồng thời vẫn đảm bảo việc thực thi, quyền hạn và môi trường biệt lập được thực thi bởi thời gian chạy.
Việc phát hiện kỹ năng so với việc chèn kỹ năng là một chi tiết quan trọng: OpenClaw có thể phát hiện kỹ năng trong quá trình thực thi, nhưng không chèn một cách mù quáng mọi kỹ năng vào mọi lời nhắc. Thay vào đó, quá trình thực thi sẽ chọn lọc chỉ chèn kỹ năng (hoặc các kỹ năng) phù hợp với lượt chơi hiện tại để tránh làm quá tải lời nhắc và làm giảm hiệu suất của mô hình.
Tương tác và phối hợp
1. Canvas và Agent-to-UI (A2UI)
Canvas là một không gian làm việc trực quan do tác nhân điều khiển, chạy như một tiến trình máy chủ riêng biệt, mặc định sử dụng cổng 18793. Sự tách biệt này khỏi Gateway chính giúp đảm bảo tính cô lập (nếu Canvas gặp sự cố, Gateway vẫn tiếp tục hoạt động bình thường) và thiết lập một ranh giới bảo mật khác biệt vì Canvas cung cấp nội dung mà tác nhân có thể ghi được.
Quy trình hoạt động như sau: tác nhân gọi phương thức cập nhật canvas, máy chủ Canvas nhận HTML và phân tích bất kỳ thuộc tính A2UI nào được nhúng trong đó, máy chủ đẩy nội dung này qua WebSocket đến các máy khách trình duyệt được kết nối, và máy khách hiển thị HTML dưới dạng giao diện tương tác.
Khi người dùng nhấp vào nút đó, máy khách sẽ gửi một sự kiện hành động đến máy chủ Canvas, máy chủ này sẽ chuyển tiếp sự kiện đó như một lệnh gọi công cụ đến tác nhân. Tác nhân xử lý hành động, có thể đánh dấu nhiệm vụ 123 là hoàn thành trong trạng thái nội bộ của nó, và gọi hàm cập nhật Canvas với trạng thái mới. Máy chủ đẩy bản cập nhật này đến máy khách, và màn hình sẽ tự động làm mới.
Canvas được hỗ trợ trên nhiều nền tảng. Ứng dụng macOS sử dụng khung nhìn WebKit gốc để hiển thị. Ứng dụng iOS gói Canvas trong một thành phần giao diện người dùng Swift. Android sử dụng WebView để hiển thị. Và tất nhiên, giao diện web có thể đơn giản mở Canvas trong một tab trình duyệt.
2. Chế độ đánh thức và đàm thoại bằng giọng nói
Chế độ đàm thoại mở rộng điều này thành cuộc trò chuyện liên tục. Bạn có thể trò chuyện qua lại với trợ lý ảo mà không cần dùng tay, với tính năng phát hiện gián đoạn để bạn có thể ngắt lời khi trợ lý đang nói. Cấu hình các cụm từ đánh thức tùy chỉnh theo sở thích của bạn.
3. Định tuyến đa tác nhân
Hãy tưởng tượng bạn muốn bot máy chủ Discord của mình có tính cách người điều hành hữu ích sử dụng Claude Sonnet, trong khi tin nhắn hỗ trợ trên Telegram của bạn nên sử dụng GPT-4 với quyền truy cập vào các công cụ khác nhau và giọng điệu trang trọng hơn. Cấu hình này thể hiện điều đó một cách tự nhiên:
{
"agents": {
"mapping": {
"group:discord:123456": {
"workspace": "~/.openclaw/workspaces/discord-bot",
"model": "anthropic/claude-sonnet-4-5",
"systemPromptOverrides": {
"SOUL.md": "You are a helpful Discord moderator..."
}
},
"dm:telegram:*": {
"workspace": "~/.openclaw/workspaces/support-agent",
"model": "openai/gpt-4o",
"sandbox": { "mode": "always" }
}
}
}
}Cơ chế định tuyến này cho phép nhiều trường hợp sử dụng mạnh mẽ. Bạn có thể tạo các vai trò riêng biệt cho mỗi cộng đồng, mỗi vai trò được tối ưu hóa cho văn hóa và nhu cầu của cộng đồng đó. Các ngữ cảnh khác nhau có thể có quyền truy cập công cụ khác nhau: có thể bot Discord của bạn có thể sử dụng tự động hóa trình duyệt, nhưng nhân viên hỗ trợ của bạn thì không. Các môi trường biệt lập dành cho người dùng không đáng tin cậy đảm bảo rằng ngay cả khi ai đó cố gắng khai thác lỗ hổng chèn lời nhắc, phạm vi ảnh hưởng vẫn được giới hạn. Và bạn có thể kiểm tra các hành vi mới của tác nhân trong một ngữ cảnh mà không ảnh hưởng đến các tác nhân đang hoạt động ổn định trong các ngữ cảnh khác.
4. Công cụ phiên (Giao tiếp giữa các nhân viên)
Các công cụ phiên cho phép các nhân viên phối hợp giữa các phiên khác nhau, về cơ bản là cung cấp khả năng giao tiếp giữa các nhân viên. Những công cụ này đặc biệt hữu ích khi bạn muốn các nhân viên cộng tác trong các nhiệm vụ phức tạp hoặc chia sẻ thông tin mà không cần bạn phải sao chép-dán thủ công giữa các ngữ cảnh trò chuyện khác nhau.
- Công cụ này
sessions_listphát hiện các phiên hoạt động. Điều này cho phép một nhân viên hỗ trợ xem những nhân viên nào khác đang rảnh. - Công cụ này
sessions_sendgửi thông báo đến một phiên khác. Ví dụ, bạn có thể thiết lậpannounceStep: "ANNOUNCE_SKIP"để một tác nhân tự động gửi công việc cho một tác nhân khác mà không thông báo cho người dùng ở cả hai phiên. - Công cụ này
sessions_historythu thập bản ghi từ các phiên làm việc khác, rất hữu ích khi một nhân viên cần bối cảnh từ các tương tác của nhân viên khác để đưa ra quyết định sáng suốt. - Công cụ này
sessions_spawntự động tạo các phiên làm việc mới để phân công công việc.
5. Các tác vụ theo lịch trình (Cron Jobs) và các tác nhân kích hoạt bên ngoài (Webhooks)
Cron job cho phép bạn lên lịch các hành động của agent chạy vào những thời điểm cụ thể. Muốn có bản tóm tắt hàng ngày? Hãy cấu hình một cron job kích hoạt lúc 9 giờ sáng mỗi ngày, gửi một tin nhắn đến phiên chính của bạn. Webhook cung cấp các điểm kích hoạt bên ngoài cho các hành động của agent. Ví dụ điển hình là tích hợp email, trong đó Gmail xuất bản thông tin đến một điểm cuối webhook để kích hoạt các hành động của agent.
Cả hai tính năng đều sử dụng thiết lập dựa trên cấu hình, cho phép bạn tự động hóa các tác vụ định kỳ và tích hợp với các hệ thống bên ngoài mà không cần viết mã tùy chỉnh.
Phân tích chuyên sâu: Luồng thông điệp từ đầu đến cuối
Hãy cùng theo dõi điều gì xảy ra khi bạn gửi tin nhắn WhatsApp đến trợ lý ảo OpenClaw của mình. Hiểu được quy trình này sẽ cho thấy cách tất cả các thành phần hoạt động cùng nhau.
Giai đoạn 1: Nuốt
Đầu tiên, thư viện Baileys nhận một sự kiện WebSocket từ máy chủ của WhatsApp. Bộ chuyển đổi WhatsApp sẽ src/whatsapp/phân tích sự kiện này, trích xuất văn bản tin nhắn, bất kỳ tệp đính kèm đa phương tiện nào và siêu dữ liệu về người gửi.
Giai đoạn 2: Kiểm soát truy cập & Định tuyến
Trước khi tin nhắn được gửi đi xa hơn, nó sẽ đi qua lớp kiểm soát truy cập. Người gửi này có nằm trong danh sách cho phép của bạn không? Nếu đây là tin nhắn trực tiếp lần đầu tiên, việc ghép đôi đã được phê duyệt chưa? Nếu bất kỳ bước kiểm tra nào thất bại, tin nhắn sẽ dừng lại ở đây.
Giả sử quyền truy cập được xác nhận, hệ thống trả lời tự động sẽ src/auto-reply/reply.tstiếp quản. Nó sẽ xác định phiên nào nên xử lý tin nhắn này. Nếu tin nhắn đến trực tiếp từ bạn, đó sẽ là mainphiên có đầy đủ quyền hạn. Tin nhắn trực tiếp qua WhatsApp sẽ được xử lý agent:main:whatsapp:dm:+123.... Tin nhắn nhóm sẽ được agent:main:whatsapp:group:120...@g.us xử lý. Mỗi loại phiên có các quyền và quy tắc bảo mật khác nhau.
Giai đoạn 3: Lắp ráp bối cảnh
Môi trường chạy của Agent PiEmbeddedRunnertải phiên đã được giải quyết từ đĩa. Nó tập hợp lời nhắc hệ thống bằng cách đọc AGENTS.md, SOUL.md, và TOOLS.mdtừ không gian làm việc của bạn, chèn các kỹ năng liên quan và truy vấn hệ thống tìm kiếm bộ nhớ để tìm các cuộc hội thoại trước đó có ý nghĩa tương tự có thể cung cấp ngữ cảnh hữu ích.
Giai đoạn 4: Gọi mô hình
Ngữ cảnh phong phú này được đóng gói và truyền tải đến nhà cung cấp mô hình mà bạn đã cấu hình.
Giai đoạn 5: Thực thi công cụ
Khi mô hình phản hồi, môi trường thực thi sẽ theo dõi các lệnh gọi công cụ. Nếu mô hình quyết định cần chạy một lệnh bash, môi trường thực thi sẽ chặn lệnh gọi đó và thực thi nó, có thể bên trong một hộp cát Docker nếu đây không phải là phiên chính. Nếu mô hình muốn mở trình duyệt và trích xuất dữ liệu từ một trang web, môi trường thực thi sẽ khởi chạy Chromium với tính năng tự động hóa Giao thức Công cụ dành cho Nhà phát triển Chrome. Mỗi kết quả từ công cụ sẽ được truyền trở lại mô hình, và mô hình sẽ tích hợp nó vào phản hồi đang diễn ra của mình.
Giai đoạn 6: Cung cấp phản hồi
Các khối phản hồi được truyền ngược trở lại qua Gateway khi chúng đến. Bộ chuyển đổi WhatsApp định dạng từng khối, chuyển đổi định dạng Markdown sang định dạng Markup của WhatsApp và tuân thủ giới hạn kích thước tin nhắn. Các tin nhắn đã được định dạng sẽ được gửi qua Baileys đến máy chủ của WhatsApp và cuối cùng đến điện thoại của bạn. Cuối cùng, môi trường chạy sẽ lưu trữ toàn bộ trạng thái cuộc hội thoại (tin nhắn của bạn, phản hồi của mô hình, tất cả các lệnh gọi công cụ và kết quả) vào tệp JSON phiên trên ổ đĩa.
Thời gian trễ dự kiến cho toàn bộ quy trình này nhìn chung như sau: kiểm soát truy cập mất dưới 10 mili giây. Tải phiên từ ổ đĩa mất dưới 50 mili giây. Lắp ráp dấu nhắc hệ thống mất dưới 100 mili giây. Lấy mã thông báo đầu tiên từ mô hình mất từ 200 đến 500 mili giây tùy thuộc vào điều kiện mạng. Thời gian thực thi công cụ khác nhau: các lệnh bash thường hoàn thành trong vòng dưới 100 mili giây, trong khi tự động hóa trình duyệt có thể mất từ 1 đến 3 giây.
Lưu trữ dữ liệu và quản lý trạng thái
OpenClaw lưu trữ dữ liệu và cấu hình của nó ở nhiều vị trí khác nhau trong thư mục chính của bạn. Hiểu rõ cấu trúc này sẽ giúp ích cho việc sao lưu, di chuyển và khắc phục sự cố.
Cấu hình
Tệp cấu hình chính nằm ở vị trí ~/.openclaw/openclaw.jsonvà sử dụng định dạng JSON5, có nghĩa là bạn có thể bao gồm các chú thích và dấu phẩy cuối dòng — những tính năng giúp việc chỉnh sửa thủ công dễ chịu hơn nhiều so với định dạng JSON nghiêm ngặt. Cấu hình được phân lớp: các biến môi trường ghi đè lên các giá trị trong tệp cấu hình, và các giá trị này lại ghi đè lên các giá trị mặc định tích hợp sẵn. Điều này cho phép bạn lưu trữ các mã thông báo nhạy cảm trong các biến môi trường trong khi vẫn duy trì cấu hình tĩnh trong tệp.
Trạng thái phiên và nén dữ liệu
OpenClaw lưu trữ mỗi cuộc hội thoại dưới dạng một tệp phiên trong thư mục ~/.openclaw/sessions/, ghi lại lịch sử hội thoại cho phiên đó cùng với siêu dữ liệu và bất kỳ trạng thái công cụ nào được lưu trữ.
Các phiên được lưu trữ dưới dạng nhật ký sự kiện chỉ ghi thêm với hỗ trợ phân nhánh, giúp dễ dàng khôi phục trạng thái, kiểm tra lịch sử và suy luận về vị trí của một lượt hội thoại cụ thể trong cây hội thoại.
Để tuân thủ các giới hạn ngữ cảnh của mô hình, OpenClaw thực hiện nén tự động: các phần cũ hơn của cuộc hội thoại được tóm tắt và lưu trữ để phiên có thể tiếp tục mà không làm mất ngữ cảnh quan trọng. Trước khi nén, hệ thống có thể chạy một bước “xóa bộ nhớ” nhẹ nhàng để chuyển thông tin bền vững vào các tệp bộ nhớ; điều này giúp ngăn ngừa việc mất các chi tiết quan trọng khi các lượt hội thoại cũ hơn được nén lại, và bước này sẽ được bỏ qua khi không gian làm việc của phiên không thể ghi được.
Mã định danh phiên mã hóa cả quyền sở hữu và ranh giới tin cậy. Phiên điều hành chính được đặt khóa là agent:và hoạt động với đầy đủ chức năng. Các phiên DM sử dụng agent:và các phiên nhóm sử dụng agent:; cả hai đều được cách ly theo mặc định để bảo vệ máy chủ khỏi các đầu vào không đáng tin cậy và các cuộc hội thoại nhiều người tham gia.
Tìm kiếm bộ nhớ
OpenClaw lưu trữ bộ nhớ có thể tìm kiếm về các cuộc hội thoại của bạn để cung cấp ngữ cảnh phù hợp khi bạn tương tác với trợ lý ảo. Khi bạn đặt câu hỏi, hệ thống sẽ tự động tìm kiếm các cuộc hội thoại trước đó có nội dung tương tự và đưa ngữ cảnh đó vào lượt nói hiện tại, nhờ đó trợ lý ảo có thể tham khảo những điều bạn đã nói cách đây vài tuần mà không cần bạn phải lặp lại.
Lưu trữ và lập chỉ mục
Hệ thống bộ nhớ lưu trữ dữ liệu bằng cách ~/.openclaw/memory/sử dụng cơ sở dữ liệu SQLite với các vector nhúng. Khi tin nhắn đến, chúng được tự động lập chỉ mục. Hệ thống sử dụng tìm kiếm kết hợp giữa độ tương đồng vector (đối sánh ngữ nghĩa) và độ liên quan từ khóa BM25 (đối sánh chính xác từng từ) để tìm ngữ cảnh trước đó phù hợp nhất.
Các tệp bộ nhớ trong không gian làm việc của bạn
Ngoài bản ghi chép cuộc hội thoại, bạn có thể duy trì các tệp bộ nhớ có cấu trúc mà nhân viên hỗ trợ có thể tham khảo:
MEMORY.md— Bộ nhớ dài hạn chứa các thông tin được chọn lọc và ổn định. Tệp này chỉ được tải trong các phiên riêng tư/chính để bảo mật, không bao giờ được tải trong các cuộc trò chuyện nhóm nơi người khác có thể thấy nội dung cá nhân của bạn.memory/YYYY-MM-DD.md— Ghi chú hàng ngày cung cấp nhật ký hoạt động và bối cảnh chi tiết cho mỗi ngày.
Lựa chọn nhà cung cấp nhúng
Hệ thống bộ nhớ cần một mô hình nhúng để chuyển đổi văn bản thành các vectơ có thể tìm kiếm. OpenClaw tự động chọn nhà cung cấp dựa trên cấu hình bạn đã thiết lập:
- Nếu bạn đã cấu hình mô hình nhúng cục bộ (
local.modelPath), hãy sử dụng mô hình đó. - Nếu không, hãy kiểm tra xem có khóa API của OpenAI hay không và sử dụng các embedding của OpenAI.
- Nếu không, hãy kiểm tra xem có khóa API của Gemini hay không và sử dụng các embedding của Gemini.
- Nếu không có bộ nhớ nào khả dụng, chức năng tìm kiếm bộ nhớ sẽ bị vô hiệu hóa.
Quản lý chỉ mục
Trình theo dõi tập tin giám sát các tập tin bộ nhớ của bạn và tự động lập chỉ mục lại chúng khi chúng thay đổi (với độ trễ 1,5 giây để tránh tình trạng quá tải). Nếu bạn thay đổi nhà cung cấp hoặc mô hình nhúng, hệ thống sẽ phát hiện điều này và tự động lập chỉ mục lại mọi thứ. Bạn cũng có thể bật tính năng lập chỉ mục bản ghi phiên thử nghiệm bằng cách sử dụng experimental.sessionMemory: true, cho phép tìm kiếm toàn bộ lịch sử cuộc trò chuyện thay vì chỉ các tập tin bộ nhớ. Cuối cùng, nếu sqlite-vec có sẵn, nó sẽ tăng tốc các thao tác tìm kiếm vectơ bên trong SQLite.
Thông tin xác thực
Dữ liệu xác thực nhạy cảm được lưu trữ trong ~/.openclaw/credentials/thư mục này. Điều này bao gồm các mã thông báo xác thực kênh như dữ liệu phiên của WhatsApp, thông tin xác thực OAuth cho các nền tảng như Discord và bất kỳ thông tin bí mật nào khác cần thiết để truy cập kênh. Quyền truy cập tệp bị giới hạn ở mức 0600 (chỉ chủ sở hữu có thể đọc/ghi), và thư mục này tự động được loại trừ khỏi hệ thống kiểm soát phiên bản để ngăn ngừa rò rỉ ngoài ý muốn.
Kiến trúc bảo mật
OpenClaw triển khai phòng thủ đa lớp thông qua nhiều lớp bảo mật. Mỗi lớp cung cấp một loại bảo vệ khác nhau, và chúng phối hợp với nhau để tạo ra một tư thế bảo mật toàn diện.
1. An ninh mạng
Theo mặc định, Gateway chỉ liên kết độc quyền với 127.0.0.1giao diện loopback của bạn. Điều này có nghĩa là Gateway chỉ có thể truy cập được từ máy cục bộ, không bao giờ được kết nối với internet công cộng. Truy cập từ xa yêu cầu cấu hình rõ ràng thông qua một trong số các phương pháp được hỗ trợ:
# SSH tunnel (recommended for VPS)
ssh -N -L 18789:127.0.0.1:18789 user@hostViệc tích hợp Tailscale cung cấp hai chế độ. Tailscale Serve cung cấp quyền truy cập HTTPS chỉ dành cho tailnet, cho phép các thiết bị khác trên mạng Tailscale truy cập Gateway của bạn thông qua kết nối an toàn, được mã hóa. Tailscale Funnel tiến xa hơn, cho phép truy cập Gateway của bạn ra internet công cộng thông qua cơ sở hạ tầng của Tailscale.
# Tailscale Serve (tailnet-only HTTPS)
config: gateway.tailscale.mode: "serve"
# Tailscale Funnel (public HTTPS, requires password)
config: gateway.tailscale.mode: "funnel"
gateway.auth.mode: "password"Các cơ chế bắt tay và xác thực WebSocket hoạt động tương tự bất kể bạn kết nối qua SSH, Tailscale hay kết nối trực tiếp.
2. Xác thực & Ghép nối thiết bị
Xác thực bằng mã thông báo hoặc mật khẩu bảo vệ các liên kết không phải loopback. Hãy thiết lập OPENCLAW_GATEWAY_TOKENbiến môi trường trước khi khởi động Gateway, và tất cả các máy khách WebSocket phải bao gồm mã thông báo đó trong connect.params.auth.tokentrường của chúng. Ngoài ra, bạn cũng có thể cấu hình xác thực bằng mật khẩu thông gateway.auth.mode: "password"qua tệp cấu hình của mình (bắt buộc đối với Tailscale Funnel).
Việc ghép nối dựa trên thiết bị bổ sung thêm một lớp bảo mật. Tất cả các máy khách WebSocket (Giao diện người dùng điều khiển, các nút, công cụ CLI) đều bao gồm định danh thiết bị trong quá trình connectbắt tay. Định danh thiết bị bao gồm ID thiết bị và các khóa mã hóa. Khi một thiết bị mới kết nối:
- Các kết nối cục bộ (loopback hoặc cùng mạng Tailscale) có thể được cấu hình để tự động phê duyệt nhằm tối ưu hóa quy trình làm việc trên cùng một máy chủ.
- Các kết nối từ xa phải ký một mã xác thực ngẫu nhiên (challenge nonce) trong quá trình bắt tay để chứng minh chúng sở hữu thông tin xác thực hợp lệ và cần có sự chấp thuận rõ ràng.
Sau khi được chấp thuận, Gateway sẽ cấp mã thông báo thiết bị cho thiết bị đó, cho phép các kết nối tiếp theo mà không cần phê duyệt lại. Mô hình dựa trên thiết bị này ngăn chặn truy cập trái phép ngay cả khi ai đó có được mã thông báo xác thực của bạn.
Quan trọng : Giao diện người dùng điều khiển yêu cầu một môi trường bảo mật (HTTPS hoặc localhost) để tạo định danh thiết bị crypto.subtle. Nếu bạn bật tùy chọn này gateway.controlUi.allowInsecureAuth, giao diện người dùng sẽ chuyển sang xác thực chỉ bằng mã thông báo qua HTTP thông thường và bỏ qua bước ghép nối thiết bị — đây là một bước giảm bảo mật. Nên ưu tiên HTTPS (Tailscale Serve) hoặc truy cập giao diện người dùng trên máy chủ cục bộ 127.0.0.1.
3. Kiểm soát truy cập kênh
Tính năng ghép cặp tin nhắn trực tiếp (DM pairing) cung cấp sự phê duyệt có sự tham gia của con người đối với tin nhắn trực tiếp. Khi dmPolicy="pairing"(mặc định), người gửi không xác định sẽ kích hoạt một quy trình cụ thể: họ gửi tin nhắn đầu tiên và Gateway sẽ phản hồi bằng một mã ghép cặp duy nhất thay vì xử lý tin nhắn. Bạn phê duyệt người gửi bằng cách chạy lệnh openclaw pairing approve , lệnh này sẽ thêm họ vào kho danh sách cho phép cục bộ. Chỉ khi đó, tin nhắn của họ mới đến được với nhân viên hỗ trợ.
Danh sách cho phép (Allowlists) chỉ định rõ ràng những số điện thoại hoặc tên người dùng nào có thể tương tác với bot của bạn. Đối với WhatsApp: channels.whatsapp.allowFrom: ["+1234567890"]. Đối với Telegram: channels.telegram.allowFromvới tên người dùng hoặc ID số.
Chính sách nhóm bổ sung thêm một lớp kiểm soát nữa:
requireMentionBot chỉ phản hồi khi được nhắc đến bằng @trong nhóm.- Danh sách cho phép dành riêng cho nhóm:
channels.whatsapp.groupstrở thành danh sách cho phép dành riêng cho nhóm khi được thiết lập (bao gồm cả"*"tùy chọn cho phép tất cả các nhóm) - Các mẫu đề cập theo từng kênh:
messages.groupChat.mentionPatterns: ["@openclaw"]
4. Môi trường thử nghiệm công cụ
OpenClaw sử dụng môi trường hộp cát dựa trên Docker để cách ly việc thực thi công cụ trên cơ sở từng phiên. Phiên mainlàm việc (tương tác trực tiếp của bạn với tư cách là người vận hành) thường chạy các công cụ nguyên bản trên máy chủ với quyền truy cập đầy đủ. Ngược lại, các phiên DM và nhóm có thể được cấu hình để thực thi các công cụ bên trong các vùng chứa Docker tạm thời, giảm thiểu tác động của các đầu vào không đáng tin cậy.
Mỗi vùng chứa sandbox cung cấp một hệ thống tệp tin biệt lập, quyền truy cập mạng tùy chọn (thường bị vô hiệu hóa theo mặc định và chỉ được bật khi cần thiết), và các giới hạn tài nguyên có thể cấu hình (CPU/bộ nhớ). Các vùng chứa có vòng đời ngắn: chúng được tạo ra để thực thi trong môi trường sandbox và sau đó bị hủy bỏ, vì vậy ngay cả khi một phiên DM hoặc nhóm bị ép buộc thực hiện hành vi không an toàn, “phạm vi ảnh hưởng” cũng chỉ giới hạn trong vùng chứa đó chứ không phải môi trường máy chủ của bạn.
Giới hạn bảo mật dựa trên phiên
Mô hình này tương ứng một cách rõ ràng với các cấp độ tin cậy của phiên:
- Phiên chính: quyền truy cập đầy đủ vào máy chủ cho các quy trình làm việc của người vận hành (không có chi phí phụ trội của Docker).
- Phiên DM: được cách ly theo mặc định (ngay cả với các liên hệ đã được phê duyệt) để hạn chế lỗi hoặc chèn thông báo.
- Phiên họp nhóm: được thiết lập trong môi trường biệt lập theo mặc định để phòng ngừa các tác động có rủi ro cao từ nhiều người tham gia.
Điều gì làm thay đổi hồ sơ bảo mật?
Một vài nút điều chỉnh cấp cao sẽ quyết định độ mạnh của khả năng cách ly:
- Khái niệm “sandboxed” (hộp cát) áp dụng cho các công cụ (ví dụ: các thao tác shell/tiến trình/tệp, và tùy chọn tự động hóa trình duyệt), chứ không phải cho chính Gateway.
- Độ chi tiết của vùng chứa: sự cô lập có thể được thiết lập theo từng phiên (mạnh nhất), theo từng tác nhân hoặc được chia sẻ giữa các phiên được chạy trong môi trường sandbox (hiệu quả nhất, ít bị cô lập nhất).
- Khả năng truy cập từ máy chủ: không gian làm việc và các điểm gắn kết (bind mount) quyết định xem vùng chứa có nhận được thông tin gì từ máy chủ, chỉ có quyền xem (read-only) hay quyền truy cập đọc/ghi (read/write). Các điểm gắn kết rất mạnh mẽ nhưng có thể gây ra rủi ro nếu chúng để lộ các đường dẫn nhạy cảm.
- Truy cập mạng: việc cho phép kết nối mạng giữa các container mở rộng khả năng nhưng cũng làm tăng rủi ro; hãy hạn chế quyền truy cập trừ khi phiên làm việc thực sự cần thiết.
- Các lối thoát hiểm: bất kỳ công cụ nào được thiết kế rõ ràng ở cấp độ “máy chủ” hoặc cấp cao hơn mà bỏ qua môi trường sandbox đều phải được coi là các giao diện chỉ có độ tin cậy cao.
Chính sách và thứ tự ưu tiên của công cụ
Quyền truy cập công cụ được quản lý bởi chính sách phân lớp, và quyền hạn hiệu quả sẽ bị thu hẹp khi bạn chuyển từ môi trường vận hành sang môi trường không đáng tin cậy.
Thứ tự ưu tiên của chính sách công cụ (các nguồn sau sẽ ghi đè lên các nguồn trước):
Hồ sơ công cụ → Hồ sơ nhà cung cấp → Chính sách toàn cầu → Chính sách nhà cung cấp → Chính sách tác nhân → Chính sách nhóm → Chính sách hộp cát
Các chính sách nhóm và hộp cát có thể hạn chế hơn nữa bộ công cụ mà một tác nhân có thể sử dụng, nhưng không nên dùng chúng để mở rộng quyền truy cập vượt quá những gì các chính sách trước đó cho phép.
5. Phòng thủ bằng cách tiêm thuốc nhanh
Việc cách ly ngữ cảnh giúp chống lại các cuộc tấn công chèn mã độc bằng cách giữ cho các đầu vào được tách biệt rõ ràng. Các thông điệp của người dùng mang theo siêu dữ liệu nguồn, các lệnh hệ thống vẫn khác biệt với nội dung do người dùng cung cấp và kết quả của công cụ được đóng gói trong các định dạng có cấu trúc để phân biệt chúng với đầu vào của người dùng. Sự tách biệt này khiến kẻ tấn công khó có thể đánh lừa tác nhân xử lý một thông điệp không đáng tin cậy như một lệnh hệ thống.
Việc lựa chọn mô hình cũng đóng vai trò quan trọng. Tài liệu của OpenClaw khuyến nghị sử dụng các mô hình tốt nhất, thế hệ mới nhất cho bất kỳ bot nào có thể chạy công cụ hoặc thao tác với tệp/mạng (và đặc biệt đề xuất Claude Opus 4.5 là lựa chọn mặc định mạnh mẽ). Nếu sử dụng các mô hình nhỏ hơn vì lý do chi phí hoặc độ trễ, tài liệu khuyến nghị bù đắp bằng cách giảm phạm vi ảnh hưởng: ưu tiên các công cụ chỉ đọc, giảm thiểu tiếp xúc với hệ thống tệp, áp dụng chế độ hộp cát nghiêm ngặt và thực thi danh sách cho phép chặt chẽ.
Những biện pháp bảo vệ này chỉ có hiệu lực khi được hỗ trợ bởi các cơ chế kiểm soát chặt chẽ. Giữ cho tin nhắn trực tiếp đến được khóa chặt thông qua việc ghép cặp/danh sách cho phép, ưu tiên việc giới hạn số lượng tin nhắn trong nhóm thay vì chạy “luôn bật” trong các phòng công cộng, coi các liên kết/tệp đính kèm/hướng dẫn được dán là có hại theo mặc định và chạy việc thực thi các công cụ nhạy cảm trong môi trường biệt lập (sandbox) đồng thời giữ các thông tin bí mật không nằm trong hệ thống tệp mà tác nhân có thể truy cập được. Đối với các kênh không đáng tin cậy, hãy bật chế độ biệt lập (sandboxing) một cách rộng rãi và vô hiệu hóa các công cụ có khả năng kết nối mạng ( web_search/ web_fetch/ browser) trừ khi các đầu vào được kiểm soát chặt chẽ. Chế độ biệt lập là tùy chọn, và các lời nhắc hệ thống chỉ là hướng dẫn mềm; việc thực thi đến từ các biện pháp kiểm soát truy cập kênh, các hạn chế chính sách công cụ, việc giới hạn trong môi trường biệt lập và (khi áp dụng) các phê duyệt thực thi rõ ràng.
Kiến trúc triển khai
OpenClaw hỗ trợ bốn mô hình triển khai chính, mỗi mô hình được tối ưu hóa cho các trường hợp sử dụng và môi trường khác nhau. Kiến trúc vẫn nhất quán trên tất cả các mô hình; điều thay đổi là vị trí chạy Gateway và cách các máy khách kết nối với nó.
Phát triển cục bộ (macOS/Linux)
Trong môi trường phát triển cục bộ, mọi thứ đều chạy trên máy tính của nhà phát triển. Bạn khởi động Gateway ở chế độ nền trước bằng lệnh “npm start” pnpm dev, cho phép tải lại nhanh khi có thay đổi mã. Gateway liên kết 127.0.0.1:18789với địa chỉ “loopback”, chỉ có thể truy cập từ máy cục bộ. Các công cụ CLI và giao diện người dùng web kết nối trực tiếp với địa chỉ loopback này. Không cần xác thực vì giao diện loopback được coi là đáng tin cậy, và nhật ký gỡ lỗi chạy ở mức độ chi tiết tối đa.
Mô hình này được thể hiện trực quan như sau:
Phiên bản macOS chính thức (Ứng dụng trên thanh menu)
Phiên bản triển khai sản phẩm macOS sử dụng LaunchAgent để chạy Gateway như một dịch vụ nền. Dịch vụ tự động khởi động khi đăng nhập và hoạt động liên tục. Ứng dụng trên thanh menu macOS cung cấp giao diện gốc để khởi động, dừng và khởi động lại Gateway. Nó bao gồm giao diện người dùng WebChat được nhúng trực tiếp trong ứng dụng, chức năng Voice Wake để vận hành rảnh tay và truy cập cục bộ thông qua giao diện loopback. Truy cập từ xa có thể được thực hiện thông qua đường hầm SSH hoặc Tailscale.
Kiến trúc trông như sau:
Việc triển khai này cho phép tích hợp macOS gốc, bao gồm hỗ trợ iMessage vì iMessage yêu cầu chạy trên máy Mac thực sự. Voice Wake tích hợp với ElevenLabs để nhận dạng và tổng hợp giọng nói. Hỗ trợ Canvas thông qua hệ thống A2UI cung cấp không gian làm việc trực quan cho giao diện do tác nhân điều khiển.
Linux/Máy ảo (Cổng truy cập từ xa)
Việc chạy OpenClaw trên VPS hoặc máy ảo cung cấp khả năng hoạt động 24/7 mà không cần máy tính cá nhân của bạn phải luôn bật. Gateway hoạt động như một systemddịch vụ trên máy chủ từ xa và có thể được liên kết với cổng loopback ( 127.0.0.1) để đảm bảo an ninh. Các máy khách cục bộ của bạn (CLI và giao diện người dùng web) kết nối thông qua một đường hầm SSH chuyển tiếp cổng cục bộ đến cổng loopback từ xa.
Phương án A: Đường hầm SSH (khuyến nghị mặc định)
Cấu hình chuyển tiếp cổng SSH ánh xạ cổng cục bộ của bạn 127.0.0.1:18789đến cổng Gateway từ xa 127.0.0.1:18789:
ssh -N -L 18789:127.0.0.1:18789 user@vpsSau khi đường hầm được thiết lập, giao diện dòng lệnh (CLI) và giao diện người dùng web (Web UI) cục bộ của bạn sẽ kết nối 127.0.0.1:18789với máy chủ, và lưu lượng truy cập sẽ được chuyển tiếp một cách minh bạch qua đường hầm SSH được mã hóa đến Cổng kết nối từ xa:
Phương án B: Tailscale Serve (chỉ HTTPS dành cho tailnet)
Tailscale cung cấp một phương pháp thay thế cho việc triển khai VPS. Thay vì duy trì đường hầm SSH, bạn kết nối cả VPS và các thiết bị khách của mình vào cùng một mạng Tailscale (một “tailnet”). VPS sử dụng Tailscale Serve để hiển thị Gateway thông qua HTTPS cho các thiết bị khác trên tailnet (ví dụ: https://vps.tailnet.ts). Điều này cung cấp quyền truy cập được mã hóa mà không cần quản lý khóa SSH hoặc các tiến trình đường hầm.
Fly.io (Triển khai container)
Fly.io là một tùy chọn triển khai dựa trên điện toán đám mây, trong đó Gateway chạy trong một container Docker được quản lý bởi Fly.io. Một volume lưu trữ trạng thái OpenClaw (cấu hình, phiên, thông tin đăng nhập) để đảm bảo trạng thái được duy trì sau khi triển khai và khởi động lại. Fly.io cung cấp một điểm cuối HTTPS được quản lý (với tính năng chấm dứt TLS) phía trước container, giúp Gateway có thể truy cập từ xa qua mạng internet công cộng.
Sơ đồ kiến trúc:
Vì Gateway có thể truy cập được từ mạng internet công cộng theo mô hình này, bạn nên bật xác thực mạnh và coi nó như một dịch vụ hướng ra internet.
Phần kết luận
OpenClaw đại diện cho một cách tiếp cận hiện đại đối với cơ sở hạ tầng AI cá nhân: ưu tiên cục bộ, tự lưu trữ và hoàn toàn có thể kiểm soát. Kiến trúc của nó cân bằng giữa sự đơn giản thông qua mô hình Gateway một tiến trình với sức mạnh thông qua định tuyến đa tác nhân, hộp cát công cụ và các plugin mở rộng. Điều này giúp nó dễ tiếp cận với các nhà phát triển mới bắt đầu trong khi vẫn sẵn sàng cho môi trường sản xuất với các trường hợp sử dụng đòi hỏi cao.
Thiết kế dạng trung tâm và các nhánh xung quanh mặt phẳng điều khiển Gateway cho phép truy cập thống nhất trên các nền tảng nhắn tin. Bạn sẽ có trải nghiệm trợ lý ảo nhất quán cho dù bạn đang nhắn tin từ WhatsApp, Discord hay iMessage. Các ranh giới bảo mật mạnh mẽ bảo vệ chống lại các đầu vào không đáng tin cậy mà không làm giảm khả năng hoạt động. Môi trường chạy gốc của trợ lý ảo với khả năng thực thi công cụ và các phiên liên tục mang đến trải nghiệm trợ lý ảo thực sự thông minh, chứ không chỉ là một lớp bao bọc trò chuyện xung quanh LLM.
Dù bạn chạy OpenClaw trên máy tính xách tay để sử dụng cá nhân hay triển khai nó lên VPS để hoạt động 24/7, bạn đều có được một trợ lý AI riêng tư có thể truy cập từ bất cứ đâu. Bạn vẫn giữ quyền kiểm soát nơi nó hoạt động, cách nó được hiển thị và cách dữ liệu được lưu trữ và truy cập.
Trong thời đại mà khả năng của trí tuệ nhân tạo ngày càng bị khóa sau các API độc quyền và các hệ sinh thái khép kín, OpenClaw mang đến một giải pháp thay thế: vận hành trợ lý ảo theo cách bạn muốn, truy cập thông qua các kênh bạn đã sử dụng, với sự minh bạch về cách thức hoạt động.
https://ppaolo.substack.com/p/openclaw-system-architecture-overview
