TL;DR: Khi doanh nghiệp có vài automation và agent chạy song song, vấn đề không còn là "làm sao cho nó chạy" mà là "làm sao biết nó đang làm gì". Cần bảy lớp kiểm soát: registry, task queue, approval, identity & permission, audit log, observability, escalation. Nghe có vẻ phải mua một nền tảng mới — thực tế phần lớn đã có sẵn trong Lark. Và từ tháng 9/2026, phía Feishu (Trung Quốc) đã công bố governance như một tính năng sản phẩm, tức hướng này không còn là lý thuyết của nhà tư vấn. Chỗ còn thiếu thật chỉ còn một: audit xuyên hệ thống.
Đây là bài thứ hai trong series Agentic Operations. Bài trước: CRM không biến mất, nó xuống tầng nền.
1. Vấn đề mới: phân tán, không phải thiếu automation
Hình dung một SME điển hình sau một năm làm chuyển đổi số:
- Một workflow n8n đồng bộ đơn hàng và gửi thông báo qua Telegram.
- Một agent soạn email trả lời khách, chạy qua tài khoản Gmail của một nhân sự.
- Một bot nhắc việc trong nhóm chat Lark.
- Log của từng thứ nằm ở một nơi: VPS, GitHub Actions, hộp thư, hoặc… không nằm ở đâu cả.
Từng mảnh riêng lẻ đều hoạt động. Nhưng hỏi ba câu đơn giản thì không ai trả lời được ngay: có bao nhiêu agent/automation đang chạy? Agent X tuần trước đã gửi gì cho khách? Ai có quyền tắt agent Y, và tắt bằng cách nào?
Đó là khoảng cách giữa "có automation" và "quản trị được automation". Trong kỹ thuật, lớp trả lời ba câu hỏi đó gọi là control plane — phần quản lý các worker (data plane) đang chạy thật. Bài này bóc control plane thành bảy lớp, rồi chỉ ra lớp nào bạn đã có mà không biết.
2. Bảy lớp của một Agent Control Plane
| # | Lớp | Câu hỏi nó trả lời | Nếu thiếu |
|---|---|---|---|
| 1 | Agent registry | Có những agent nào, của ai, chạy ở đâu? | Không ai biết tổng số agent đang tồn tại |
| 2 | Task queue | Việc được giao cho agent ra sao, theo thứ tự nào? | Hai agent xử lý trùng một việc, hoặc việc rớt giữa chừng |
| 3 | Approval | Hành động nào cần người duyệt trước khi thực thi? | Agent tự gửi email/chốt đơn/sửa dữ liệu không ai hay |
| 4 | Identity & permission | Agent là ai, được đọc/ghi phạm vi nào? | Agent thừa quyền — đọc được dữ liệu chủ nó cũng không được xem |
| 5 | Audit log | Agent đã làm gì, khi nào, bằng quyền gì? | Có sự cố thì không truy vết được |
| 6 | Observability | Agent tốn bao nhiêu, lỗi bao nhiêu, chạy có khoẻ không? | Hoá đơn API tăng mà không biết agent nào đốt tiền |
| 7 | Escalation | Khi agent gặp ngoại lệ, nó gọi ai, bằng kênh nào? | Ngoại lệ chìm lặng, khách hàng là người phát hiện đầu tiên |
Không lớp nào là khái niệm mới — đây là bộ khung tương đương với quản trị nhân sự, chỉ áp cho thực thể không phải người. Nếu muốn ôn lại agent và tool-use ở tầng khái niệm trước, đọc Bài 07: AI Agent và Bài 05: Tool Use trong series AI Training.
3. Đính chính quan trọng: phần lớn khối này đã có sẵn trong Lark
Cách viết dễ nhất cho chủ đề này là dựng một "khoảng trống hoàn toàn" rồi bán giải pháp lấp vào. Chúng tôi không làm vậy, vì nó không đúng.
Nếu doanh nghiệp bạn chạy trên Lark, thực tế hôm nay đã có:
- Identity & permission: tài khoản bot tách biệt tài khoản user, app scope khai báo quyền rõ ràng, resource sharing kiểm soát bot đụng vào tài liệu/bảng nào.
- Approval: Lark Approval là sản phẩm phê duyệt hoàn chỉnh — automation có thể tạo phiếu duyệt thay vì tự hành động.
- Audit log: console quản trị ghi nhật ký truy cập và thao tác.
- Escalation & command: IM chính là kênh escalation tự nhiên — agent báo lỗi, tag đúng người, người ra quyết định ngay trong thread.
- Task queue & trigger: Base automation và AnyCross đóng vai trò hàng đợi công việc và luồng điều phối.
Cách chúng tôi ghép các mảnh này trong thực tế triển khai đã kể trong Hệ sinh thái automation n8n của Diginno. Kết luận ở đây: control plane không đòi hỏi một nền tảng mới; nó đòi hỏi dùng có chủ đích những thứ đã có.
4. Governance đã thành tính năng sản phẩm: tín hiệu từ Feishu 8.0
Phần nâng cấp quan trọng nhất của bài này: tại sự kiện Feishu Future 2026 (15/09/2026), Feishu 8.0 / Feishu for Agent công bố một cụm tính năng quản trị agent, gồm (khoảng mốc 00:18–00:28 trong video sự kiện):
- Quyền của Agent không vượt quá quyền của người sở hữu nó.
- Kiểm soát công cụ mà Agent được truy cập.
- Xem nhật ký truy cập của Agent.
- Phát hiện rủi ro (kể cả prompt injection) và vô hiệu hoá Agent.
- Giới hạn token + API phân tích mức dùng AI.
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. Đây là công bố tại sự kiện, chưa kiểm chứng độc lập.
Ánh xạ thẳng vào bảy lớp ở mục 2:
| Lớp control plane | Tính năng Feishu 8.0 tương ứng (theo công bố) |
|---|---|
| Identity & permission | Quyền Agent ≤ quyền người sở hữu |
| Agent registry (một phần) | Hệ thống quản trị giúp doanh nghiệp "nắm rõ danh tính và rủi ro của Agent" (diễn giải từ công bố) |
| Audit log | Nhật ký truy cập của Agent |
| Observability | Giới hạn token, API phân tích mức dùng |
| Escalation / kill-switch | Phát hiện rủi ro, vô hiệu hoá Agent |
| Approval, Task queue | (không thấy công bố mới — dùng Lark Approval/Base automation có sẵn) |
Ý nghĩa: "kiểm soát agent" không còn là khuyến nghị sách vở của nhà tư vấn — nhà cung cấp nền tảng đã bán nó như một tính năng. Đồng thời cần giữ đúng tỷ trọng: đây là công bố phía Feishu Trung Quốc; doanh nghiệp Việt dùng LarkSuite quốc tế hôm nay vẫn nên ghép control plane từ các thành phần có sẵn như mục 3.
5. Chỗ còn thiếu thật: audit xuyên hệ thống
Một lớp vẫn chưa có câu trả lời tốt — và công bằng mà nói, hội nghị cũng không cho thấy giải pháp cho nó: audit xuyên hệ thống.
Khi agent của bạn chạy qua nhiều nền tảng — Lark cho chat và dữ liệu, n8n cho điều phối, Gmail cho gửi thư, một API bên thứ ba cho vận chuyển — thì mỗi hệ thống có audit log riêng, và không log nào nói chuyện với nhau. Truy vết một hành động từ đầu đến cuối là việc ghép log thủ công.
Đây là gap thật mà bên triển khai (như chúng tôi) vẫn phải tự xử lý: đưa log về một nơi, gắn correlation ID cho mỗi chuỗi hành động. Nói thẳng: nếu ai bán bạn "giải pháp audit toàn diện đã có sẵn", hãy hỏi kỹ phần xuyên hệ thống.
6. Cách Diginno vận hành agent an toàn
Phần này là phương pháp nội bộ đang vận hành của chúng tôi — không kèm con số hiệu quả, không phải case của khách hàng nào:
- Discovery read-only: giai đoạn đầu agent chỉ được đọc. Không quyền ghi, không quyền gửi.
- Dry-run: khi cần hành động, agent mô phỏng và in ra "nó sẽ làm gì" để người xem trước.
- Xác nhận lần hai: hành động có hậu quả (gửi khách, ghi hệ thống, chi tiền) luôn qua một bước người bấm duyệt.
- Write nhỏ: khi được cấp quyền ghi, giới hạn ở phạm vi hẹp nhất — một bảng, một trường, một loại bản ghi.
- Read-back: sau khi ghi, đọc lại dữ liệu vừa ghi để đối chiếu, và log toàn bộ chuỗi.
Nguyên tắc xuyên suốt: mở quyền từng lớp, chỉ khi lớp trước đã chạy ổn. Đây cũng là tư duy trong bài Khi nào KHÔNG nên tự động hoá — việc đầu tiên không phải làm, mà là quyết định cái gì chưa nên làm.
Tóm lại
- Có từ ba automation/agent trở lên thì bạn đã có bài toán control plane, dù gọi tên nó hay chưa.
- Bảy lớp: registry · task queue · approval · identity & permission · audit log · observability · escalation.
- Đừng mua "nền tảng governance" vội: với doanh nghiệp chạy Lark, phần lớn đã có sẵn.
- Feishu 8.0 (TQ) đã sản phẩm hoá cụm này — tín hiệu hướng đi đúng, nhưng chưa kiểm chứng trên LarkSuite quốc tế.
- Gap còn lại: audit xuyên hệ thống — chỗ bên triển khai vẫn phải tự dựng.
Nếu bạn đang vận hành nhiều automation mà chưa trả lời được "agent nào đang chạy, đã làm gì", đó là lúc nên ngồi lại dựng control plane — trước khi thêm agent thứ tư.
Bài viết hữu ích?
Chia sẻ để nhiều người biết đến!
>_ LLM-Friendly Copy
Copy as Markdown to use with ChatGPT, Claude, or other AI tools
