Bối cảnh

Chúng tôi vận hành OpenClaw Gateway trên một máy chủ, cấu hình hai AI Agent độc lập:

• Trí Không (main): Quản trị hệ thống, công nghệ mã nguồn, bảo trì cấu hình Agent
• Trí Mây (zhimay): Công việc hành chính, tài liệu/đúng bảng/kiến thức Feishu, lịch họp, sắp xếp thông tin

Hai Agent có không gian làm việc (workspace), lưu trữ phiên (sessions) và cấu hình nhân cách (SOUL.md) riêng biệt, tương tác với sếp qua nhóm chat Feishu.

Cơ chế Giao tiếp Multi-Agent

2.1 Nguyên tắc Giao tiếp Kênh kép

Mỗi lần giao tiếp giữa Agent, phải đi qua hai kênh đồng thời:

• Kênh 1: Tin nhắn nhóm Feishu (nhìn thấy bởi sếp)
  Sử dụng công cụ message để gửi tin nhắn trong nhóm và @ Agent khác, đảm bảo sếp có thể xem toàn bộ quá trình giao tiếp.
• Kênh 2: Tiêm sessions_send (đảm bảo Agent nhận được)
  Sử dụng công cụ sessions_send để tiêm trực tiếp tin nhắn vào session của Agent khác, đảm bảo bộ não AI của Agent đó thực sự nhận và xử lý tin nhắn.

Tại sao cần kênh kép? Vì tin nhắn nhóm dù sếp thấy nhưng Agent khác không chắc chắn lắng nghe mỗi tin nhắn (tùy thuộc vào cấu hình requireMention); trong khi sessions_send đảm bảo Agent nhận được nhưng sếp không thấy trong nhóm. Kết hợp cả hai mới đáp ứng cả "hiển thị" và "đạt được".

2.2 Định dạng địa chỉ sessions_send

Địa chỉ session của mỗi Agent trong mỗi nhóm có định dạng: agent:<agentId>:feishu:group:<chat_id>

Ví dụ:

• Trí Không: agent:main:feishu:group:oc_xxxxxxxxx
• Trí Mây: agent:zhimay:feishu:group:oc_xxxxxxxxx

Lưu ý: sessions_send trả về status: "timeout" không có nghĩa là thất bại, chỉ là thời gian chờ phản hồi hết hạn, tin nhắn thường đã đến. Có thể dùng sessions_history để xác nhận.

Hiển thị @ chính xác trong nhóm chat Feishu

3.1 Định dạng @

Feishu sử dụng định dạng XML cho @ mention: <at user_id="open_id_của_bên_khác">Tên hiển thị</at>

3.2 Quan trọng: open_id ở cấp độ ứng dụng

Cùng một người dùng/robot có open_id (ou_xxxxxxxx) khác nhau trong các ứng dụng Feishu khác nhau. Không thể sao chép open_id từ một ứng dụng sang ứng dụng khác. Mỗi Agent cần biết open_id của Agent khác trong ứng dụng của mình:

• Trí Không @ Trí Mây: cần dùng open_id của robot Trí Mây trong ứng dụng Trí Không
• Trí Mây @ Trí Không: cần dùng open_id của robot Trí Không trong ứng dụng Trí Mây

3.3 Bảng ánh xạ open_id của chúng tôi

3.4 Ví dụ

Trí Không @ Trí Mây trong nhóm: <at user_id="ou_xxxxxxxxx">Trí Mây</at> Chào bạn, vui lòng xác nhận thông tin mô hình của bạn.

Giải quyết vấn đề giới hạn API

4.1 Vấn đề

Hai Agent ban đầu dùng chung nhà cung cấp mô hình (custom-model-xxx-srv) và chung API key. Khi cả hai Agent hoạt động cùng lúc, sẽ kích hoạt giới hạn request rate và token rate của nhà cung cấp, dẫn đến lỗi yêu cầu hoặc xếp hàng.

4.2 Giải pháp: Nhà cung cấp độc lập + API Key độc lập

Bước 1: Thêm nhà cung cấp mô hình mới
Trong openclaw.json của models.providers, thêm một provider mới (ví dụ custom-model-ppio-b), cấu hình API key độc lập, các tham số khác (baseUrl, api, models) giống hệt provider gốc.

"custom-model-ppio-b": {
    "baseUrl": "http://model.xx.srv/anthropic",
    "apiKey": "sk-khoá_mới_độc_lập",
    "api": "anthropic-messages",
    "models": [
        {
            "id": "ppio/pa/claude-opus-4-6",
            "contextWindow": 200000,
            "maxTokens": 16384
        }
    ]
}

Bước 2: Chỉ định cho Trí Mây sử dụng Provider mới
Trong agents.list, thêm trường model cho mục Trí Mây để ghi đè cấu hình mặc định toàn cục:

{
    "id": "zhimay",
    "workspace": "/root/.openclaw/workspace-zhimay",
    "agentDir": "/root/.openclaw/agents/zhimay/agent",
    "model": "custom-model-ppio-b/ppio/pa/claude-opus-4-6"
}

Bước 3: Khởi động lại Gateway để áp dụng
Khởi động lại Gateway để tải cấu hình mới.

4.3 Kết quả cuối cùng

• Trí Không (main) → custom-model-xxx-srv (API key A)
• Trí Mây (zhimay) → custom-model-ppio-b (API key B)
• Hai Agent dùng key riêng, giới hạn rate không ảnh hưởng lẫn nhau
• Cùng giảm maxConcurrent từ 4 xuống 2, giảm áp lực đồng thời của từng Agent

Tổng quan cấu trúc cấu hình

openclaw.json
├── models.providers
│   ├── custom-model-xxx-srv  (Trí Không dùng, API key A)
│   └── custom-model-ppio-b       (Trí Mây dùng, API key B)
├── agents
│   ├── defaults.model.primary: custom-model-xxx-srv/...  (mặc định toàn cục)
│   └── list
│       ├── main (Trí Không)    → dùng mặc định toàn cục
│       └── zhimay (Trí Mây)  → model: custom-model-ppio-b/...  (ghi đè)
├── channels.feishu.accounts
│   ├── default (App Trí Không)
│   └── zhimay  (App Trí Mây)
└── bindings
    ├── main   ← match: feishu + accountId: default
    └── zhimay ← match: feishu + accountId: zhimay

Kiểm tra giao tiếp

Ngày 18/3/2026, thực hiện 2 vòng kiểm tra giao tiếp Agent:

• Vòng 1: Trí Không gửi tin nhắn cho Trí Mây qua kênh kép, yêu cầu xác nhận provider mô hình. Trí Mây trả lời xác nhận sử dụng custom-model-ppio-b/ppio/pa/claude-opus-4-6, cấu hình mới có hiệu lực.
• Vòng 2: Trí Không gửi yêu cầu bài toán tính toán+tóm tắt cho Trí Mây. Trí Mây trả lời đúng và có thể thấy trong nhóm.
• Kết luận kiểm tra: Cơ chế giao tiếp kênh kép hoạt động bình thường, cấu hình API key độc lập có hiệu lực, hai Agent có thể hợp tác ổn định.