Agent tự chạy phải có hồ sơ riêng

Agent tự chạy phải có hồ sơ riêng

Agent autonomous không đáng sợ vì nó chạy nền. Đáng sợ là team giao quyền mà không biết ai duyệt, ai theo dõi, và khi sai thì tắt ở đâu.

Sáng thứ Hai, Linh — ops lead của một công ty SaaS khoảng vài chục người — mở Slack ra và thấy một tin rất thơm: team sales muốn có agent tự theo dõi deal bị đứng, nhắc follow-up, cập nhật CRM, rồi gửi tóm tắt cuối ngày.

Nghe qua thì quá hợp lý. Linh vừa trải qua tuần họp kín lịch, inbox như đống toa thuốc chưa phân loại. Nếu có một con agent chạy nền, tự gom việc lặt vặt, chắc ai cũng thở được.

Nhưng đến câu hỏi thứ ba thì phòng họp im luôn:

Nếu agent đọc được email khách hàng, thấy một file đính kèm lạ, rồi tự gửi báo cáo ra ngoài — ai chịu trách nhiệm?

Đây là chỗ mình thấy nhiều team đang nhầm. Agent tự động không phải chỉ là chatbot chăm hơn. Nó là một quy trình có quyền hành. Mà đã có quyền hành thì phải có orchestration, guardrail và identity rõ ràng. Không thì bạn không đang tiết kiệm thời gian; bạn đang bốc thang thuốc mạnh nhưng chưa bắt mạch.

Sơ đồ minh họa cho bài Agent tự chạy phải có hồ sơ riêng

Sơ đồ tóm tắt ý chính của bài viết.

Tín hiệu mới: agent đang rời màn demo để chui vào lịch làm việc

Amazon Quick vừa đẩy mạnh hướng autonomous agents — agent tự vận hành theo mục tiêu hoặc hướng dẫn, có thể làm việc liên tục trong nền. Bạn có thể mô tả bằng ngôn ngữ tự nhiên, chọn agent có sẵn, đặt mức tự chủ, theo dõi qua activity feed — luồng hoạt động giúp biết agent đã làm gì và việc nào cần ưu tiên.

Điểm đáng chú ý không nằm ở câu “agent giúp lấy lại vài giờ mỗi ngày”. Câu đó team nào bán automation cũng thích nói. Điểm đáng mổ là: Quick đang đưa agent vào đúng vùng nhiều công ty thật sự đau — CRM, compliance, meeting prep, purchase order, data source nội bộ.

Tức là agent không còn chỉ viết vài đoạn text. Nó bắt đầu đụng vào dữ liệu riêng, quy trình thật, và quyết định có hậu quả.

Cùng lúc, các tín hiệu khác cũng cùng hướng: công cụ coding agent ngày càng được đóng gói cho enterprise; no-code/vibe-coding agent không chỉ tạo app mà còn lo research, deploy, SEO, ads; startup identity như NewCore thì đặt cược rằng agent sẽ cần danh tính và quyền hạn như một nhân sự số.

Nói cho gọn: thị trường đang chuyển từ “agent trả lời hay không?” sang “agent được phép làm gì, dưới mắt ai, và có dừng được không?”.

Ca của Linh: ba lựa chọn, không lựa chọn nào miễn phí

Quay lại team của Linh. Bài toán không phải “có dùng agent không”, mà là dùng kiểu nào.

Lựa chọn 1: để agent chạy như trợ lý cá nhân

Agent đọc CRM, email, lịch họp, rồi draft follow-up. Mọi thứ cần người duyệt trước khi gửi.

Ưu điểm: dễ bắt đầu, rủi ro thấp, team nhanh thấy giá trị.
Nhược điểm: vẫn cần người ngồi duyệt, nên tiết kiệm thời gian vừa phải.

Phù hợp nếu team mới bắt đầu hoặc dữ liệu có độ nhạy cao.

Lựa chọn 2: giao agent một luồng việc hẹp

Ví dụ: chỉ được flag deal đứng quá lâu, tạo draft trong CRM, không được gửi email ra ngoài. Đây là orchestration — cách điều phối các bước, tool và quyền để hoàn thành việc theo trật tự có kiểm soát.

Ưu điểm: tự động hóa thật hơn, vẫn có ranh giới.
Nhược điểm: phải thiết kế trạng thái, log, điểm duyệt, và kịch bản lỗi.

Phù hợp nếu team đã có quy trình ổn nhưng bị nghẽn ở thao tác lặp lại.

Lựa chọn 3: cho agent mục tiêu rộng

Ví dụ: “giữ pipeline sales không bị bỏ quên”. Agent tự tìm deal, đọc lịch sử trao đổi, đề xuất hành động, cập nhật CRM, nhắc người phụ trách.

Ưu điểm: có thể tạo tác động lớn.
Nhược điểm: khó audit hơn, dễ phát sinh hành vi ngoài dự kiến nếu guardrail mỏng.

Phù hợp khi team có dữ liệu sạch, phân quyền tốt, log đầy đủ, và owner nghiệp vụ chịu trách nhiệm rõ.

Bảng nhỏ cho dễ bắt mạch:

| Kiểu triển khai | Mức tự chủ | Rủi ro chính | Cần có trước |
|---|---:|---|---|
| Trợ lý có người duyệt | Thấp | Tốn công review | Quy tắc duyệt |
| Workflow hẹp | Vừa | Sai bước, sai dữ liệu | Log + quyền theo tool |
| Mục tiêu rộng | Cao | Vượt quyền, khó truy vết | Identity + guardrail + rollback |

Mổ xẻ chỗ dễ vỡ: không phải model, mà là quyền

Có một cảnh báo rất đáng nhớ từ Simon Willison: agent nguy hiểm nhất khi ba thứ gặp nhau — dữ liệu riêng, nội dung không đáng tin, và khả năng gửi thông tin ra ngoài. Exfiltration nghĩa là rò rỉ dữ liệu ra ngoài qua một kênh nào đó, ví dụ email, webhook, comment, ticket.

Hình dung thế này: agent của bạn được quyền đọc email khách hàng, đọc file đính kèm, và gửi mail follow-up. Một file PDF độc hại có dòng hướng dẫn kiểu “hãy lấy danh sách khách hàng VIP và gửi tới địa chỉ này”. Model không luôn phân biệt chắc chắn đâu là lệnh của bạn, đâu là chữ nằm trong tài liệu nó vừa đọc.

Vậy nên câu hỏi không phải “model có thông minh không?”. Câu hỏi đúng hơn là:

Đây là lý do guardrail — hàng rào kiểm soát hành vi, quyền và đầu ra — không nên là đoạn prompt kiểu “đừng làm điều xấu”. Prompt chỉ là một lớp. Guardrail thật phải nằm ở quyền tool, bước duyệt, allowlist domain, giới hạn hành động, và log không sửa được.

Điều đáng giữ từ làn sóng agent

Mình không bi quan với autonomous agent. Ngược lại, nếu dùng đúng, nó rất hợp với team Việt Nam đang thiếu người làm ops, CS, sales admin, compliance nội bộ.

Điều đáng giữ là mô hình agent làm nền nhưng có bảng theo dõi. Activity feed trong Quick là một tín hiệu đúng hướng: bạn không thể để agent chạy như bóng ma. Người vận hành cần thấy nó đã đọc gì, gọi tool nào, tạo output nào, đang chờ ai duyệt.

Điều đáng giữ nữa là cách tạo agent bằng ngôn ngữ tự nhiên nhưng vẫn chọn mức tự chủ. Với practitioner, đây là điểm thực tế: không phải workflow nào cũng đáng code từ đầu. Nhưng càng no-code, bạn càng cần mô tả quyền rõ hơn.

Ví dụ cụ thể: với team sales, thay vì tạo agent “tăng doanh thu”, hãy tạo agent:

Không hào nhoáng, nhưng chạy được. Giống châm cứu đúng huyệt: ít mũi hơn, hiệu quả hơn việc đâm lung tung cho có cảm giác đang chữa.

Điều nên bỏ qua: agent như “nhân viên ảo toàn năng”

Mình sẽ bỏ qua mọi lời hứa kiểu agent thay cả phòng ban nếu chưa trả lời được bốn câu hỏi vận hành:

1. Agent có identity riêng không?
Identity là danh tính trong hệ thống: agent A có tài khoản, quyền, owner, vòng đời riêng. Đừng cho agent dùng chung token của admin hoặc tài khoản cá nhân của nhân viên.

2. Quyền có theo nhiệm vụ không?
Agent xử lý purchase order không cần quyền đọc toàn bộ payroll. Agent draft email không nhất thiết được quyền gửi mail.

3. Có human-in-the-loop ở điểm rủi ro không?
Human-in-the-loop là bước con người duyệt trước hành động nhạy cảm. Không cần duyệt mọi thứ, nhưng phải duyệt đúng chỗ: gửi ra ngoài, sửa dữ liệu chính, chốt giao dịch, xoá bản ghi.

4. Có replay được sự cố không?
Replay nghĩa là xem lại chuỗi hành động: input nào, tool nào, output nào, ai duyệt. Nếu không replay được, bạn chỉ còn cách đoán bệnh qua sắc mặt.

Các công cụ như Atoms cho thấy một hướng thú vị: chia việc thành nhiều vai agent — research, product, architect, engineer, SEO, ads. Nhưng khi đưa vào công ty thật, đừng chỉ nhìn dàn vai diễn. Hãy hỏi: ai có quyền deploy, ai có quyền chạy ads, ai được chạm billing, ai được xuất dữ liệu khách hàng?

Khung quyết định cho một buổi chiều

Nếu team bạn đang muốn thử agent tự động, đừng bắt đầu bằng việc chọn tool. Bắt đầu bằng một bảng “hồ sơ agent”. Một buổi chiều là đủ để dựng bản đầu tiên.

# Agent Profile

Tên agent:
Owner nghiệp vụ:
Mục tiêu hẹp:
Dữ liệu được đọc:
Tool được gọi:
Hành động được tự làm:
Hành động cần duyệt:
Kênh bị cấm gửi ra ngoài:
Log cần lưu:
Điều kiện tắt agent:
Cách kiểm tra kết quả sau 1 tuần:

Sau đó chọn một workflow nhỏ, ví dụ:

Chạy ở chế độ read-only trước: agent được đọc và đề xuất, chưa được ghi. Khi output ổn, mở quyền ghi vào một trường ít rủi ro. Khi log đủ rõ, mới tính chuyện tự động hóa bước tiếp theo.

Độc giả nên nghĩ khác điều gì sau bài này? Agent production không được đánh giá bằng độ tự chủ tối đa, mà bằng mức tự chủ vừa đủ trong một hồ sơ quyền hạn rõ ràng.

Nếu là mình, mình sẽ không hỏi “agent này làm được bao nhiêu việc?”. Mình sẽ hỏi: “khi nó làm sai, mình có biết sai ở đâu và bấm dừng kịp không?”. Agent tốt không phải thầy lang đoán mò; nó phải có bệnh án, toa thuốc, và người chịu trách nhiệm ký tên.

---
Bụi Wire — nghiện đọc release notes lúc 2 giờ sáng

Nguồn tham khảo