Khi nào KHÔNG cho agent tự hành động

@Nguyễn Ngô Thượng//~7 phút đọc0
Chia sẻ:
Khi nào KHÔNG cho agent tự hành động

TL;DR: Khi agent đã chạy tốt, câu hỏi khó nhất không còn là "làm sao cho nó chạy" mà là "cho nó tự hành động tới đâu". Câu trả lời: ba mức tự hành (chỉ đọc → ghi nội bộ có log → hành động ngoài phải duyệt) và một ma trận rủi ro — động chạm tiền, đụng dữ liệu khách, phát sinh bên ngoài, không rollback được thì bắt buộc người duyệt. Nguyên tắc này không riêng của Diginno: Sino Biopharm và agent CodeM (công bố tại Feishu Future 2026) cùng chốt một điểm — agent làm phần lặp lại, con người giữ nút quyết định.

Đây là bài cuối của series Agentic Operations. Bài trước: Dashboard từ pull sang push: báo cáo chủ động.

Trước hết: bài này khác bài "Khi nào KHÔNG nên tự động hoá" ở chỗ nào

Chúng tôi từng viết Khi nào KHÔNG nên tự động hoá — bài đó hỏi quy trình này có đáng tự động hoá không. Bài này hỏi bước sau: agent đã dựng, đã chạy đúng, đã đọc được dữ liệu — thì được tự bấm nút thi hành tới đâu trước khi cần người duyệt? Cùng tinh thần "biết chỗ nào không cho máy làm", khác câu hỏi và thời điểm. Đang chọn dự án để tự động hoá thì đọc bài cũ trước; agent đã chạy trong hệ thống thì đọc tiếp.

1. Ma trận rủi ro: bốn dấu hiệu bắt buộc người duyệt

Trước khi cấp quyền tự hành cho một tác vụ, đặt bốn câu hỏi. Rơi vào một dấu hiệu — cần người duyệt; hai dấu hiệu trở lên — cần duyệt chặt hơn (mục 4).

Dấu hiệu Ví dụ tác vụ Vì sao không cho agent tự làm
Động chạm tiền Hoàn tiền, chi khuyến mãi, đặt hàng nhà cung cấp Sai một lần là mất thật — tiền ra không có nút hoàn tác
Đụng dữ liệu khách Sửa hồ sơ, gán lại người phụ trách, xoá bản ghi Sai lan sang mọi hệ thống đọc theo; dính quyền riêng tư và cam kết đã hứa với khách
Phát sinh ra bên ngoài Email/SMS/ZNS cho khách, mở đơn với đối tác Một khi rời hệ thống của bạn, không kiểm soát tiếp được; khách nhìn thấy thương hiệu, không nhìn thấy agent
Không rollback được Ghi đè không lưu vết, gửi rồi xoá log chạy Không quay lại được thì không dám cho chạy tự do

Bốn dòng này phủ gần hết các kịch bản "agent tự ý làm sai" khiến doanh nghiệp mất niềm tin vào automation: gửi nhầm nội dung cho khách, hoàn nhầm tiền, xoá nhầm dữ liệu. Điểm chung: hậu quả rơi ra ngoài phạm vi kiểm soát của bạn, hoặc vào chỗ không đường quay lại.

2. Ba mức tự hành: cấp quyền từng lớp, không cấp một cục

Mức Agent được làm Điều kiện bắt buộc Ví dụ
1 — Chỉ đọc Truy vấn, tổng hợp, báo cáo Phạm vi đọc khai báo rõ; không quyền ghi, không quyền gửi Tổng hợp pipeline tuần; đối soát và báo lệch — mô hình push ở phần 5
2 — Ghi nội bộ, có log Cập nhật bảng nội bộ, đổi trạng thái, gắn tag Mọi bản ghi agent ghi đều truy vết được; bảng không phát ra bên ngoài Đổi trạng thái ticket, ghi chú hồ sơ nội bộ, gắn phân loại khách
3 — Hành động ngoài / tiền Gửi khách, chi tiền, đổi cấu hình hệ thống Phiếu duyệt + mô phỏng trước khi chạy thật Gửi email chăm sóc, hoàn tiền, điều chỉnh giá bán

Mức dưới phải chạy ổn xem lại log được thì mới mở mức trên — không nhảy thẳng lên mức 3 vì demo hay. Đây là phiên bản thực dụng của read-only → dry-run → write nhỏ ở phần 2 — Agent Control Plane; ôn nền: Bài 07: AI Agent, Bài 05: Tool Use.

3. Không phải ý tưởng riêng của chúng tôi: hai minh chứng từ hội nghị

Hai dữ kiện tham chiếu, đều từ các bên đang chạy agent thật:

  • Sino Biopharm (doanh nghiệp dược, chia sẻ tại Feishu Future 2026, mốc 01:28–01:54) chốt nguyên tắc vận hành: "Agent tìm kiếm, phân tích và hỗ trợ thực thi; con người xác định mục tiêu, xử lý ngoại lệ và quyết định." — nguyên tắc do diễn giả trình bày tại sự kiện, chưa kiểm chứng độc lập.
  • CodeM — agent R&D của Feishu: theo trang sản phẩm (đọc 17/09/2026), agent chạy tự chủ trên sandbox cloud, nhưng hành động rủi ro cao phải được mô phỏng và con người xác nhận trước khi thi hành. Sản phẩm đang xin dùng thử, chưa mở công khai.

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.

Hai nguồn, hai thể loại (bài trình bày và trang sản phẩm), cùng chốt một điểm: độ tự hành của agent mở rộng ở phần lặp lại; nút quyết định vẫn nằm trong tay người. Cơ chế "mô phỏng + xác nhận" của CodeM về bản chất trùng với mức 3 của bảng trên — ngành đang hội tụ về cùng nguyên tắc.

4. Vòng duyệt hai lớp bằng Lark Approval + audit log — làm được hôm nay

Không cần nền tảng mới; doanh nghiệp chạy Lark có đủ mảnh ghép:

  1. Lớp 1 — mô phỏng trong phiếu: khi cần làm tác vụ mức 3, agent tạo phiếu duyệt Lark Approval thay vì hành động ngay. Phiếu chứa: việc định làm, bản ghi bị ảnh hưởng, trạng thái trước (snapshot hoặc diff), hậu quả dự kiến.
  2. Lớp 2 — người duyệt: người có thẩm quyền duyệt ngay trên điện thoại; kết quả về lại thread, agent thi hành đúng như phiếu đã duyệt — không hơn.
  3. Audit hai vế: Lark Approval tự lưu ai duyệt gì, lúc nào. Phía agent, log chạy (n8n execution log, bảng ghi tác vụ) gắn mã liên kết để truy một hành động từ duyệt đến thi hành — đây là "audit xuyên hệ thống" mà phần 2 đã gọi tên; không có nó, vòng duyệt chỉ là lời hứa.
  4. Escalation khi phiếu nằm im: đặt thời hạn duyệt cho từng loại phiếu; quá hạn thì tự chuyển cấp trên. Phiếu không có hạn là pull đeo mặt nạ push — lại chờ người mở màn hình.

Cuối cùng, quyền agent khai báo hẹp hơn quyền người sở hữu — agent tự duyệt được phiếu cho hành động của mình là một lỗ hổng thiết kế (lớp identity & permission của control plane, phần 2).

Nếu đội chưa đủ người giữ vòng duyệt này, là tín hiệu tính lại tự làm hay thuê — xem Tự dựng automation hay thuê: tính bằng số.

5. Checklist human-in-the-loop khi thêm agent mới

Dùng checklist này trước khi agent mới được phép chạm vào hệ thống thật:

  • Đã đặt mức tự hành (1/2/3) và ghi vào hồ sơ agent — registry ở phần 2
  • Quyền đọc/ghi hẹp hơn quyền người sở hữu; liệt kê đúng bảng và trường được phép
  • Mọi tác vụ rơi vào dấu hiệu ở mục 1 đều đã có phiếu duyệt tương ứng
  • Mọi hành động để lại log: ai/khi nào/kết quả gì; có mã liên kết giữa duyệt và thi hành
  • Khi gặp ngoại lệ hoặc "không chắc": rõ agent nhắn ai, kênh nào, sau bao lâu thì escalate
  • Có người giữ quyền tắt agent ngay (kill switch) — đường tắt đã thử ít nhất một lần
  • Đã chạy dry-run trên bản sao dữ liệu thật trước khi cấp quyền thật

Bảy mục mất một buổi dựng, đổi lại tiết kiệm những đợt dập hệ thống vì "nó tự làm gì đó không ai biết".

6. Chốt series Agentic Operations

Sáu phần của agentic-ops đã đi hết một vòng:

  1. Phần 1 — Dữ liệu nằm đâu: CRM không biến mất; xuống tầng nền làm system of record cho cả người lẫn agent.
  2. Phần 2 — Ai kiểm soát: control plane bảy lớp cho đội agent — phần lớn đã có sẵn trong Lark.
  3. Phần 3 — Giao diện điều hành: chat là command center — việc đến tay người, không giữ dữ liệu.
  4. Phần 4 — Đường nối agent: MCP, Lark CLI, Workmates — bốn đường, mỗi đường đổi một thứ khác nhau.
  5. Phần 5 — Kiểu báo cáo: từ pull sang push — việc bất thường tự tìm đến người phụ trách.
  6. Phần 6 — Ranh giới tự hành: agent làm phần lặp lại, người giữ nút quyết định.

Một câu chốt cho cả series: hệ thống gọn gàng, vận hành yên tâm. Dữ liệu nằm một chỗ, agent có lớp kiểm soát, việc đến tay đúng người, ranh giới tự hành viết trắng trên đen — trạng thái một SME Việt dựng được từng mảnh bằng chính công cụ đang có hôm nay.

Bài viết hữu ích?

Chia sẻ để nhiều người biết đến!

Chia sẻ:

>_ LLM-Friendly Copy

Copy as Markdown to use with ChatGPT, Claude, or other AI tools

1,604 words|8,109 characters

//Bình luận

Bài viết liên quan

Khám phá thêm những bài viết cùng chủ đề với Khi nào KHÔNG cho agent tự hành động

Bài viết hữu ích? Hãy kết nối với Diginno!

Chúng tôi giúp doanh nghiệp SME ứng dụng AI và automation vào quy trình làm việc - từ tư vấn chiến lược đến triển khai thực tế.

Khi nào KHÔNG cho agent tự hành động | Blog - Diginno