Tôi đã xây dựng một hệ điều hành AI cộng tác 5 vai trò với OpenClaw: Phân tích kỹ thuật chi tiết

Tôi đã dành nhiều thời gian để biến OpenClaw từ một trợ lý đơn lẻ thành một hệ điều hành cộng tác đa vai trò. Nó không chỉ đơn thuần là "mở vài bot để chat riêng lẻ."

5 vai trò AI, chia sẻ một cổng kết nối chung, hoạt động trên cả hai kênh Discord và Telegram, với sự phân công lao động rõ ràng, định tuyến, cô lập bộ nhớ và các quy tắc cộng tác, có khả năng làm việc chuyển tiếp như một đội nhóm.

Trong bài viết này, tôi sẽ phân tích toàn bộ quá trình xây dựng, các quyết định thiết kế ở từng lớp, cấu hình cụ thể và những cạm bẫy tôi đã gặp phải.

Nếu bạn cũng đang sử dụng OpenClaw hoặc quan tâm đến "cách làm cho nhiều AI thực sự cộng tác với nhau", bài viết này sẽ giúp bạn tránh được nhiều đường vòng.

Kết luận trước: Đây không phải là "nhiều bot," mà là một Hệ điều hành đa tác tử dưới một Cổng kết nối duy nhất

Khi nhiều người nghe đến "5 vai trò AI," phản ứng đầu tiên của họ là: bạn đang chạy 5 bot độc lập, phải không?

Đúng, nhưng cũng không hoàn toàn đúng.

Kiến trúc của tôi như thế này:

• 1 tiến trình Gateway, thống nhất truy cập kênh và định tuyến
• 5 Agent độc lập: Chỉ huy, Chiến lược gia, Kỹ sư, Người sáng tạo, Nhà tư duy
• Mỗi Agent có không gian làm việc độc lập riêng (cá tính, quy tắc, bộ nhớ và phiên đều được cô lập)
• Chạy đồng thời hai kênh Discord + Telegram (có thể chạy nhiều nền tảng, nhưng tôi chỉ dùng Discord), sử dụng bindings để phân phối tin nhắn chính xác
• Trò chuyện riêng tư và trò chuyện nhóm sử dụng các cơ chế hoàn toàn khác nhau

Một phép so sánh: Đây không phải là thuê 5 người và ném họ vào một căn phòng để họ tự do hành động. Đây là việc xây dựng một công ty—có cơ cấu tổ chức, mô tả công việc, giao thức liên lạc, văn phòng độc lập và quy tắc họp hành.

Bản thân OpenClaw là một framework trợ lý AI cá nhân mã nguồn mở hỗ trợ nhiều nền tảng (Discord, Telegram, WhatsApp, v.v.) và nhiều mô hình (Claude, GPT, Gemini, v.v.), với dữ liệu được lưu trữ hoàn toàn cục bộ.

Khả năng đa tác tử của nó là lý do cốt lõi tôi chọn nó—hỗ trợ nguyên bản cho không gian làm việc độc lập đa tác tử + định tuyến bindings, cho phép tôi xây dựng một hệ thống cộng tác thực sự trên nền tảng đó.

1. Kiến trúc tổng thể: Cổng kết nối đơn + Đa tác tử + Đa không gian làm việc + Đa kênh

Đầu tiên, hãy nói về các quyết định kiến trúc cấp thấp nhất.

1) Lưu trữ thống nhất qua một Cổng kết nối duy nhất

Tôi hiện có một tiến trình OpenClaw Gateway duy nhất mang tất cả các khả năng—truy cập tin nhắn, định tuyến, quản lý phiên, gọi công cụ, lập chỉ mục bộ nhớ và quản lý trạng thái, tất cả trong một gateway.

Tại sao không chạy một bộ dịch vụ cho mỗi vai trò? Ba lý do:

• Bảo trì tập trung: Chỉ cần bảo trì một Gateway, không cần chạy các dịch vụ độc lập cho mỗi vai trò.
• Cấu hình thống nhất: Một master config quản lý các chiến lược toàn cầu, và việc giám sát / khắc phục sự cố cũng được tập trung.
• Nền tảng cộng tác: Để các vai trò cộng tác, chúng phải ở trong cùng một runtime để giao tiếp hiệu quả.

2) 5 Agent song song, không phải 5 Bot rời rạc

5 vai trò cố định của tôi:

• Chỉ huy (zongzhihui): Nhận thức tình huống toàn cầu, phân chia nhiệm vụ, giao việc, hiệu chỉnh và kết thúc.
• Chiến lược gia (junshi): Phân tích chiến lược, đánh giá đề xuất và dự đoán rủi ro.
• Kỹ sư (engineer): Thực thi kỹ thuật, triển khai mã và bảo trì hệ thống.
• Người sáng tạo (creator): Sáng tạo nội dung, tối ưu hóa biểu đạt và đầu ra bên ngoài.
• Nhà tư duy (zhiku): Kiểm toán kiến thức, kiểm soát chất lượng và kiểm tra tuân thủ.

Mỗi agent có không gian làm việc riêng, ví dụ: workspace-engineer, workspace-junshi, v.v. Các tệp cá tính, tệp quy tắc, tệp bộ nhớ và tài sản kịch bản đều độc lập và không làm nhiễm chéo lẫn nhau.

3) Truy cập kép đa kênh: Discord + Telegram

Cùng một Gateway được kết nối với cả Discord và Telegram. Mỗi vai trò có bindings cấp accountId trên cả hai kênh. Tất nhiên, bạn có thể sử dụng cùng một tệp cấu hình này để tích hợp thêm nhiều nền tảng như Lark, WeChat, v.v.

Đây không phải là "triển khai trùng lặp trên nhiều nền tảng," mà là "cùng một cụm não, các lớp truy cập khác nhau." Tôi đã cấu hình Discord là chiến trường cộng tác chính.

Nếu bạn muốn nhiều tác tử hợp tác và cộng tác trong một nhóm, chỉ cần chọn Discord; một nền tảng là đủ. Những nền tảng khác không hoàn hảo, tôi đã thử rồi!!!

2. Lớp định tuyến: Bindings Ánh xạ "Tài khoản" thành "Vai trò"

Đây là logic đầu vào của toàn bộ hệ thống.

Tôi đã cấu hình một chiến lược binding rõ ràng cho hai kênh: channel + accountId -> agentId.

Cụ thể:

• discord + zongzhihui -> zongzhihui
• discord + engineer -> engineer
• telegram + creator -> creator
• ... tổng cộng 10 ánh xạ (5 vai trò × 2 kênh)

Tại sao lại làm như vậy?

Bởi vì hệ thống quyết định "ai sẽ xử lý tin nhắn này" ở lớp đầu vào, thay vì để tất cả các agent đều nghe thấy và sau đó tranh nhau trả lời. Nếu bước này không được thực hiện tốt, tất cả sự cộng tác sau đó sẽ hỗn loạn.

Bạn có thể coi bindings như "bộ phận tiếp nhận và phân loại" của hệ thống này. Khi một tin nhắn đến, nó đầu tiên kiểm tra xem kênh và tài khoản nào đã nhận được nó, sau đó định tuyến trực tiếp đến vai trò tương ứng—sạch sẽ và hiệu quả.

3. Cô lập phiên: Tại sao trò chuyện riêng không bị chéo và trò chuyện nhóm không bị lộn xộn

Đây là một trong những điểm kỹ thuật quan trọng nhất trong hệ thống của tôi.

Cấu hình cốt lõi: session.dmScope = per-account-channel-peer

Tham số này có nghĩa là: Ngữ cảnh trò chuyện riêng tư được cô lập bởi ba chiều: "tài khoản + kênh + người dùng ngang hàng."

Tại sao chọn điều này?

• Nếu cùng một người liên hệ với cùng một vai trò qua Discord và Telegram, các ngữ cảnh sẽ không bị chéo.
• Nếu những người dùng khác nhau liên hệ với cùng một vai trò, các ngữ cảnh được cô lập hoàn toàn.
• Trong các tình huống đa tác tử + đa tài khoản, rủi ro "nói chuyện chéo" được giảm thiểu.

Nói cách khác, tôi không chỉ tạo ra "nhiều vai trò"; tôi còn thực hiện "kỹ thuật chiến lược cô lập ngữ cảnh."

Nhiều người xây dựng hệ thống đa tác tử với các vai trò được phân chia rõ ràng, nhưng quản lý ngữ cảnh lại là một mớ hỗn độn—nội dung trò chuyện riêng tư của Người dùng A lại xuất hiện trong câu trả lời của Người dùng B, hoặc bộ nhớ hội thoại Discord làm nhiễm bẩn ngữ cảnh Telegram.

per-account-channel-peer là chiến lược cô lập được OpenClaw khuyến nghị cho các tình huống đa tài khoản, và thử nghiệm của tôi cho thấy nó thực sự là lựa chọn ổn định nhất.

4. Điều phối trò chuyện nhóm: Cộng tác theo quy tắc, không phải trò chuyện tự do

Phần này là thú vị nhất và cũng có nhiều cạm bẫy nhất.

Chiến lược cốt lõi: Chỉ huy lắng nghe toàn cục + Các vai trò khác được kích hoạt bằng @

Chiến lược trò chuyện nhóm của tôi ở phía Discord như sau:

Chỉ huy: requireMention = false (Lắng nghe toàn cục)

• Có thể thấy tất cả các tin nhắn trong nhóm theo mặc định.
• Chịu trách nhiệm nắm bắt tình hình tổng thể, đánh giá xem có cần cộng tác hay không, thực hiện phân chia nhiệm vụ và giao việc.

4 Vai trò còn lại: `requireMention = true` (Kích hoạt bằng @)

• Chỉ hành động khi được @mention rõ ràng.
• Giảm nhiễu và tránh nói chồng lên nhau.

Mỗi vai trò được cấu hình với `mentionPatterns`

• Ví dụ: kỹ sư có thể được kích hoạt bởi @Engineer hoặc [@engineer](https://x.com/@engineer).
• Làm cho việc triệu tập trong nhóm ổn định và có thể dự đoán hơn.

Bản chất của sự kết hợp này là gì?

• Chỉ huy "nhìn thấy bức tranh lớn," giống như một PM trong đội.
• Các vai trò chuyên biệt được "kích hoạt khi cần," giống như các chuyên gia ở các vị trí khác nhau.
• Lời nói trong nhóm thay đổi từ "tự do" thành "chuyển tiếp có kiểm soát."

Hiệu quả thực tế: Bạn đặt câu hỏi trong nhóm, Chỉ huy đầu tiên đánh giá loại nhiệm vụ, sau đó @mention vai trò tương ứng để xử lý. Khi vai trò đó hoàn thành, Chỉ huy kết thúc vòng lặp. Toàn bộ quá trình giống như một đội nhóm thực sự đang họp.

5. Discord vs Telegram: Tại sao Discord là chiến trường chính

Nói một cách chính xác, không phải là "chỉ có Discord mới có thể cộng tác." Chỉ là trong cấu hình hiện tại của tôi, Discord phù hợp nhất cho việc điều phối cộng tác công khai đa vai trò.

Lý do cụ thể:

1. Tôi đã cấu hình 5 tài khoản song song trên Discord + một cơ chế @cộng tác rõ ràng.
2. Danh tính vai trò, chuỗi hội thoại và quy trình chuyển tiếp đều hiển thị—trông giống như một cuộc thảo luận nhóm.
3. Chiến lược Chỉ huy lắng nghe toàn cục + cổng mention của các vai trò khác trực quan hơn trong các tình huống trò chuyện nhóm.
4. Tôi hiện đặt groupPolicy của Discord thành open, mang lại tính linh hoạt cao hơn.

Về phía Telegram, chiến lược của tôi nghiêng về allowlist + mention gate, có nhiều ràng buộc và an toàn hơn, phù hợp cho "các kênh sản xuất có kiểm soát."

Vì vậy, tóm lại: Discord là sân khấu cộng tác.

6. Lớp cấu hình + Lớp Prompt: Quản trị hai đường ray

Đây là sự khác biệt lớn nhất giữa hệ thống này và "chỉ chơi đùa."

Tôi không chỉ dựa vào cấu hình, cũng không chỉ dựa vào Prompt. Tôi sử dụng hai đường ray chồng chéo.

A. Đường ray cấu hình (Kiểm soát cấp nền tảng)

Đây là các cấu hình cứng ở cấp nền tảng OpenClaw:

• chính sách kênh: groupPolicy, dmPolicy, kiểm soát các chiến lược cơ bản cho trò chuyện nhóm và trò chuyện riêng.
• requireMention: Ai phải được @mention theo mặc định để trả lời.
• bindings: Ánh xạ định tuyến tin nhắn.
• dmScope: Mức độ chi tiết cô lập phiên.
• Giới hạn ping-pong agentToAgent: Tôi đặt giá trị này là 0, trực tiếp triệt tiêu các cuộc qua lại vô nghĩa giữa các agent.

Điều cuối cùng là rất quan trọng—nếu bạn không giới hạn ping-pong giữa các agent, bạn sẽ thấy hai AI trong một nhóm tỏ ra lịch sự, xác nhận lẫn nhau và lặp vô hạn. Đặt nó thành 0 báo cho hệ thống biết: các agent không nên tự động ping lẫn nhau.

B. Đường ray quy tắc (Kiểm soát cấp hành vi)

Đây là các tệp quy tắc tôi đã viết trong mỗi không gian làm việc:

• SOUL.md: Tệp linh hồn của vai trò—cá tính, giọng điệu, trách nhiệm và chất lượng đầu ra tối thiểu.
• AGENTS.md: Sổ tay vận hành—quy trình kiểm tra cộng tác, chuẩn mực đọc/ghi bộ nhớ và chiến lược tải chậm.
• ROLE-COLLAB-RULES.md: Ranh giới cộng tác cụ thể cho vai trò và các đường ranh đỏ.
• TEAM-RULEBOOK.md: Các quy tắc cứng thống nhất cho toàn đội (được chia sẻ bởi tất cả các vai trò).
• TEAM-DIRECTORY.md: Bảng ánh xạ vai trò với ID thực để ngăn chặn việc @mention nhầm người.

Hiệu quả của việc chồng chéo hai đường ray này là: lớp nền tảng giới hạn luồng + lớp hành vi thêm các ràng buộc.

Đó không phải là đặt mọi thứ lên "sự tự nhận thức" của mô hình. Các mô hình mắc lỗi, trôi dạt và quên các quy tắc. Do đó, các ràng buộc cứng phải được đặt ở lớp cấu hình trước, tiếp theo là hướng dẫn mềm ở lớp prompt. Bảo hiểm kép.

7. Hệ thống tệp không gian làm việc: "Văn phòng độc lập" của mỗi vai trò

Khung tệp cho mỗi không gian làm việc về cơ bản là nhất quán, điều này rất quan trọng—nó cho thấy tôi đang chuẩn hóa, không chỉ đơn thuần là chất đống tệp một cách ngẫu nhiên cho mỗi vai trò.

Cấu trúc tệp tiêu chuẩn

8. Hệ thống bộ nhớ: Tải chậm + Phân lớp + Lưu trữ

Quản lý bộ nhớ là phần dễ bị bỏ qua nhất nhưng cũng là phần có nhiều vấn đề nhất trong một hệ thống đa tác tử.

Chiến lược của tôi không phải là "nhớ càng nhiều càng tốt," mà là phân lớp rõ ràng:

1) Nhật ký ngắn hạn (bộ nhớ hàng ngày)

• Ghi lại các quy trình nhiệm vụ trong ngày, các phân đoạn ngữ cảnh và các quyết định tại chỗ.
• Các tệp được đặt tên theo ngày, tự nhiên tạo ra một dòng thời gian.

2) Bộ nhớ dài hạn (MEMORY.md)

• Chắt lọc các sở thích ổn định, quyết định dài hạn, kinh nghiệm có thể tái sử dụng và các quy tắc cứng.
• Không phải mọi thứ đều được đưa vào; chỉ có thông tin đã được xác minh, ổn định mới được ghi.

3) Bộ nhớ dài hạn nhóm (GROUP_MEMORY.md)

• Chỉ giữ lại thông tin có thể tái sử dụng và an toàn từ nhóm.
• Không trộn lẫn nội dung trò chuyện riêng tư; đây là một đường ranh đỏ về quyền riêng tư.

4) Lưu trữ lạnh (archive)

• Dữ liệu cũ được lưu trữ định kỳ để ngăn chặn ngữ cảnh hoạt động mở rộng mất kiểm soát.
• Nó không bị xóa, nhưng được chuyển đến bộ lưu trữ ưu tiên thấp.

5) Cơ chế truy xuất (memory_search + memory_get)

• Nhớ lại ngữ nghĩa trước, sau đó đọc chính xác.
• Tránh tải đầy đủ—cửa sổ ngữ cảnh là một tài nguyên hữu hạn và không thể lãng phí.

Giá trị cốt lõi của việc phân lớp này:

• Chất lượng trò chuyện riêng tư không bị nhiễm bẩn bởi lịch sử trò chuyện nhóm.
• Cộng tác nhóm không bị can thiệp bởi ngữ cảnh riêng tư cá nhân.
• Cửa sổ ngữ cảnh được "tải theo yêu cầu," không phải "đổ đầy hoàn toàn."

Tôi coi ngân sách ngữ cảnh như một vấn đề quản lý tài nguyên. Token là hữu hạn; mỗi bộ nhớ được nhét vào chiếm không gian suy luận. Vì vậy, mỗi bit phải được tính toán cẩn thận.

9. Chế độ riêng tư vs Chế độ nhóm: Hai chiến lược cho cùng một vai trò

Đây là điều mà nhiều người không nghĩ tới: cùng một vai trò nên hành xử khác nhau trong trò chuyện riêng tư và trò chuyện nhóm.

Tôi phân biệt rõ ràng hai chế độ trong SOUL.md của mỗi vai trò:

Chế độ riêng tư:

• Mỗi vai trò hoạt động như một chuyên gia solo, xử lý các vấn đề của người dùng từ đầu đến cuối.
• Không cần quy trình cộng tác; cung cấp câu trả lời hoàn chỉnh trực tiếp.
• Tiêu chuẩn chất lượng là "một người có thể xử lý."

Chế độ nhóm:

• Thực hiện chuyển tiếp gia tăng theo các giao thức cộng tác nhóm.
• Mỗi vai trò chỉ chịu trách nhiệm về những gì họ giỏi.
• Chỉ huy chịu trách nhiệm kết nối và kết thúc.

Cụ thể cho từng vai trò:

• Chỉ huy: Mặc định im lặng và quan sát trong nhóm, chỉ can thiệp mạnh khi cần thiết để tránh nói chồng lên người khác.
• Kỹ sư: Sản phẩm bàn giao phải có thể thực thi, có thể xác minh và có thể rollback—không chỉ đưa ra một ý tưởng.
• Chiến lược gia: Kết luận phải đi kèm với các giả định và đường dẫn xác minh—không chỉ nói bừa.
• Nhà tư duy: Kiểm toán phải cung cấp phân cấp vấn đề + kế hoạch sửa chữa—không chỉ nói "có vấn đề."
• Người sáng tạo: Biểu đạt không thể hy sinh tính xác thực và khả năng thực thi—không chỉ theo đuổi tính thẩm mỹ.

Đây là nguồn gốc của "cùng một vai trò hoạt động khác nhau trong các tình huống khác nhau." Nó không dựa vào phán đoán của chính mô hình mà được thông báo rõ ràng thông qua các tệp quy tắc.

Lời kết

Đa tác tử không chỉ là mở thêm vài bot. Đó là toàn bộ một hệ thống kỹ thuật—từ thiết kế kiến trúc, chiến lược định tuyến, cô lập phiên, điều phối cộng tác, quản lý bộ nhớ và quản trị quy tắc cho đến các kiểm tra tự động; mọi lớp đều cần được thiết kế cẩn thận.

OpenClaw cung cấp một nền tảng tuyệt vời, nhưng khối lượng công việc kỹ thuật từ "có thể chạy được" đến "chạy tốt" lớn hơn nhiều so với hầu hết mọi người tưởng tượng.

Nếu bạn đang làm điều gì đó tương tự, tôi hy vọng bài viết này sẽ cung cấp cho bạn một số tham khảo. Tất nhiên, nội dung này chỉ là sự khởi đầu; tôi sẽ phát hành thêm vài phần nữa sau đó để chia sẻ nhiều vấn đề "cụ thể và tinh tế" hơn.