Chat là command center: điều hành việc qua Lark khi agent làm phần còn lại

TL;DR: Khi agent đã làm được việc nhiều bước — đọc dữ liệu, gọi API, tạo hồ sơ — thì chỗ tự nhiên nhất để giao việc là chat: nơi hội thoại đang diễn ra. Lark ghép được mô hình này hôm nay bằng bot + AnyCross + Approval + Base automation. Nhưng có một ranh giới không được nhầm: chat là giao diện, không phải nơi giữ dữ liệu. Bài này vẽ mô hình, chỉ chỗ ghép, và đưa ba câu hỏi tự kiểm trước khi bạn giao việc đầu tiên cho agent qua chat.

Mô hình: giao việc trong chat, việc chạy ở hệ thống

Hình dung một doanh nghiệp mà phần lớn việc lặp lại do agent xử lý: đối soát số liệu, tạo hồ sơ khách, tổng hợp báo cáo, mở phiếu việc. Người quản lý không mở từng phần mềm để bấm nút. Người ta gõ một dòng trong nhóm chat, và hệ thống tự chạy.

Vòng hoàn chỉnh trông như thế này:

Người giao việc
   │  "@bot mở phiếu khảo sát cho khách X, địa điểm Y"
   ▼
Nhóm chat Lark (thread)
   │  bot nhận lệnh → kiểm tra quyền người gửi
   ▼
Agent điều phối (n8n / agent chạy CLI)
   │  hiểu yêu cầu, gọi đúng hệ thống
   ├──► LarkBase / CRM    tạo hồ sơ, đặt trạng thái
   ├──► CSDL / Sheets     ghi dữ liệu có cấu trúc
   ├──► Task / GitHub     mở phiếu việc, gán người
   └──► Dịch vụ ngoài    gửi email, tạo đơn
   │
   ▼
Kết quả quay về đúng thread
   ├── bot báo tóm tắt đã làm gì
   ├── Lark Approval    người thật bấm duyệt bước quan trọng
   └── audit log        ai yêu cầu, agent làm gì, khi nào, kết quả ra sao

Điểm đáng chú ý không phải là bot trả lời nhanh. Mà là vòng lặp khép kín: yêu cầu ra khỏi chat, việc chạy ở hệ thống, kết quả và phê duyệt quay về đúng chỗ nó khởi phát. Người quản lý đọc một thread là biết một việc đi đến đâu — không cần mở năm màn hình.

Phía sau giao diện chat đó, CRM và database không biến mất. Chúng xuống tầng nền, làm đúng việc của hệ thống dữ liệu — đã bàn kỹ ở phần 1 của series.

Lark ghép được mô hình này hôm nay

Không cần chờ tính năng tương lai. Từng mảnh đã có sẵn, việc của bên triển khai là nối chúng thành một vòng:

• Lark IM + bot: nhận lệnh trong nhóm hoặc tin nhắn riêng, trả kết quả về đúng thread. Đây là cửa vào và cửa ra của vòng lặp.
• AnyCross: tầng workflow tự động của Lark — nhận sự kiện từ bot, gọi API hệ thống ngoài, nối Lark với phần mềm đang có của bạn.
• Lark Approval: bước duyệt có người thật bấm, có timestamp, lưu được bằng chứng. Không phải gõ "ok" trong chat rồi ai cũng quên.
• Base automation: khi dữ liệu đã về Base, rule chạy tiếp — gán người phụ trách, nhắc việc, đổi trạng thái, đẩy thông báo.

Một vòng cụ thể: sale nhắc bot trong nhóm dự án "mở phiếu khảo sát cho khách X". Bot tạo đơn duyệt cho trưởng nhóm qua Approval. Duyệt xong, agent tạo bản ghi trong bảng Khảo sát của LarkBase, gán kỹ thuật viên, trả link về thread. Kỹ thuật viên thấy việc trong dashboard Base của mình, không phải lục chat.

Nếu bạn đã chạy đồng bộ LarkBase – Lark Sheet bằng AnyCross hoặc đã nghe về Lark Frontline, thì đây là cùng một hướng: Lark không chỉ là nơi chat, mà là nơi vận hành.

Ranh giới quan trọng: chat là giao diện, không phải nơi giữ dữ liệu

Đây là chỗ nhiều doanh nghiệp làm hỏng ngay năm đầu.

Thread chat có bản chất trôi xuống. Hai tháng sau bạn muốn biết "đơn này ai duyệt, căn cứ gì, agent đã đổi gì trong hồ sơ" — câu trả lời nằm rải trong hàng trăm tin nhắn, không có cấu trúc, tìm kiếm yếu dần theo thời gian.

Vì vậy, phân vai phải rõ ràng:

Một phép thử ngược: sáu tháng nữa, có trả lời được câu "việc này ai duyệt, khi nào, căn cứ gì" trong 30 giây không? Nếu bằng chứng nằm trong 800 tin nhắn thì xem như nó không tồn tại.

Audit log trong sơ đồ đầu bài không phải trang trí. Nó là một trong bảy lớp kiểm soát mà phần 2 của series đã bàn: khi nhiều agent chạy nhiều việc, khả năng truy vết là điều kiện sống còn, không phải tính năng thêm.

Bên Feishu (Trung Quốc), hướng này đã đi thêm một bước

Dữ kiện tham chiếu từ hội nghị Feishu Future 2026 (15/09/2026): phía Feishu Trung Quốc đã trình diễn nhiều người cùng phối hợp với một agent. Hai phần thuộc hai mốc khác nhau của bài trình bày: việc thêm agent vào nhóm chat như một thành viên và gọi agent trong tài liệu thuộc nền Feishu 8.0 (mốc 00:18–00:28); còn ký ức dùng chung của đội và kỹ năng một người dựng cho cả đội dùng lại thuộc sản phẩm Doubao Work Partner (mốc 00:50–01:04), được người trình bày tự xác nhận còn ở giai đoạn thử nghiệm sớm.

Tính năng được công bố tại sự kiện Feishu (thị trường Trung Quốc) ngày 15/09/2026; chưa kiểm chứng tính sẵn có trên LarkSuite quốc tế và tại Việt Nam.

Ví dụ minh họa trong bài trình bày: một agent mang tên "Tiểu Phi" có mặt trong nhiều nhóm, tự nhận ra vấn đề đang được bàn, tự tìm đúng nhóm hoặc người để hỏi thêm, và tổng hợp báo cáo tuần từ tin nhắn, cuộc họp và tiến độ công việc. Tên agent và mô tả do diễn giả công bố tại sự kiện, chưa kiểm chứng độc lập — kể để thấy hướng đi, không phải để hứa tính năng.

Kết luận trung thực cho doanh nghiệp Việt: multiplayer-agent là hướng thật, nhưng chưa phải thứ bạn có thể mua hôm nay trên LarkSuite tại Việt Nam. Với SME Việt bây giờ, cách thực dụng là ghép bot + Approval + audit log như mục 2 — thứ đã chạy được ngay — chứ không chờ tính năng multiplayer.

Ba câu hỏi tự kiểm trước khi giao việc cho agent qua chat

Trước khi cuộc họp đầu tiên về "agent trong chat" kết thúc, trả lời được ba câu này bằng tên người và tên hệ thống:

1. Khi một việc được giao qua chat, ai là người chịu trách nhiệm cuối? Người giao, người duyệt — hay vô tình là "con bot"? Trách nhiệm phải tên người thật.
2. Bằng chứng duyệt nằm ở đâu? Trong thread hay trong Approval/Base có dấu thời gian? Nếu nằm trong thread, nó sẽ mất.
3. Khi agent làm sai, truy vết cách nào? Có log đủ để tái hiện agent đã đọc dữ liệu gì, gọi công cụ gì, thay đổi trường nào — và ai đã cho phép?

Ba câu trả lời rõ là dấu hiệu chat command center của bạn đứng trên nền đúng. Ba câu trả lời lúng túng là dấu hiệu bạn đang dựng hệ thống trên cát.

Kết

Chat trở thành command center không phải vì chat thông minh hơn, mà vì agent mạnh hơn: việc thật chạy phía sau, người chỉ cần ra lệnh và duyệt. Lark có đủ mảnh để ghép vòng lặp này hôm nay — bot nhận lệnh, AnyCross chạy workflow, Approval giữ bằng chứng, Base automation đẩy việc tiếp.

Nguyên tắc duy nhất cần khắc nhớ: chat là giao diện, dữ liệu nằm ở hệ thống có cấu trúc. Đúng nguyên tắc này thì chat càng dùng càng gọn; sai nguyên tắc này thì chat càng dùng càng rối — và sáu tháng sau không ai trả lời được chuyện gì đã xảy ra.

Ở phần tiếp theo, chúng tôi kiểm chứng cụ thể Lark có những công cụ gì để nối agent vào hệ thống của bạn: MCP chính thức, Lark CLI, và bốn đường nối agent — mỗi đường đổi một thứ khác nhau để lấy.