Một bài chia sẻ trong cộng đồng n8n vừa đưa ra một thử nghiệm khá đáng chú ý: dùng n8n chạy local, kết hợp Ollama và Qwen3, để tạo một workflow kiểu “AI operator” chuyên dọn Desktop nhưng vẫn có bước xin phép trước khi đụng vào file.
Điểm đáng học ở đây không nằm ở chuyện dọn Desktop. Nó nằm ở cấu trúc an toàn cho những automation có quyền thao tác trên máy cá nhân.
Mô hình đáng chú ý: Plan, Ask, Act, Report
Workflow được mô tả theo luồng:
Plan => Ask => Act => Report
Cụ thể hơn:
- người dùng yêu cầu dọn Desktop
- workflow xin phép trước khi quét file
- sau khi được duyệt, nó đọc danh sách file local
- AI lập kế hoạch phân loại
- workflow xin phép lần nữa trước khi di chuyển file
- file được chuyển vào thư mục
_n8n_Organized - cuối cùng workflow báo cáo lại những gì đã thay đổi
Trong thử nghiệm, hệ thống tìm thấy 25 item trên Desktop và gom vào các nhóm như Screenshots, PDFs, Archives, Documents, Folders và Misc.
Vì sao cách này đáng để anh em quan tâm
Khi automation bắt đầu có quyền động vào filesystem, email, CRM, database hoặc tài khoản nội bộ, vấn đề không còn là “AI có thông minh không”. Vấn đề là:
- nó có biết dừng đúng lúc không
- nó có cho người dùng xem kế hoạch trước khi hành động không
- nó có ghi lại mình đã làm gì không
- có cách nào rollback hoặc kiểm tra sau khi chạy không
Luồng Plan, Ask, Act, Report là một khung rất thực tế để giảm rủi ro. Nó ép workflow tách rõ giữa “suy nghĩ/lập kế hoạch” và “thực thi”. Đây là điểm nhiều workflow AI bị thiếu: vừa nhận lệnh, vừa gọi tool, vừa ghi file hoặc gửi request ngay trong một chuỗi không có chốt kiểm soát.
Bài học thiết kế cho workflow n8n local
Nếu anh em muốn thử các workflow kiểu operator trên máy cá nhân hoặc server nội bộ, mình nghĩ nên giữ vài nguyên tắc sau.
1. Chia quyền theo từng bước nhỏ
Đừng để node AI có quyền làm mọi thứ ngay từ đầu. Ví dụ với bài toán dọn file:
- bước 1 chỉ được đọc metadata: tên file, đuôi file, kích thước, ngày sửa
- bước 2 tạo plan dạng JSON
- bước 3 người dùng duyệt plan
- bước 4 mới được move file
- bước 5 tạo report
Cách này giúp dễ debug hơn và cũng dễ khóa quyền hơn.
2. Approval nên duyệt theo plan, không chỉ duyệt bằng một câu “yes”
Nếu workflow chỉ hỏi “Bạn có đồng ý không?” thì vẫn hơi mù. Tốt hơn là cho người dùng thấy một bảng hoặc JSON ngắn:
{
"actions": [
{
"from": "Desktop/invoice-may.pdf",
"to": "Desktop/_n8n_Organized/PDFs/invoice-may.pdf",
"reason": "PDF document"
}
]
}
Khi đó approval có ý nghĩa hơn, vì người dùng duyệt một danh sách hành động cụ thể chứ không duyệt một ý định mơ hồ.
3. Luôn có dry-run trước khi act
Với các thao tác như move, delete, rename, gửi email, cập nhật database, mình sẽ ưu tiên có chế độ dry-run. Dry-run giúp workflow trả về “nếu chạy thật thì tôi sẽ làm gì” mà chưa thay đổi trạng thái hệ thống.
Đây là lớp an toàn rất rẻ nhưng hiệu quả.
4. Report phải đủ chi tiết để audit
Một report tốt không chỉ nói “đã xong”. Nó nên có:
- số lượng item đã xử lý
- danh sách file đã move
- item bị bỏ qua và lý do
- lỗi phát sinh nếu có
- vị trí log hoặc file report
Với workflow local, report có thể được ghi thành Markdown hoặc JSON trong thư mục kết quả. Khi có lỗi, anh em còn có dấu vết để kiểm tra.
Typed approval có đủ tốt không?
Tác giả bài gốc hỏi liệu có cách nào sạch hơn typed commands để xử lý approval không. Theo mình, typed approval là điểm khởi đầu ổn vì đơn giản và rõ ràng, nhưng nếu workflow dùng thường xuyên thì có thể cải thiện theo vài hướng:
- dùng form/webhook để hiển thị plan và nút approve/reject
- gửi plan qua Telegram/Slack/Discord rồi chờ phản hồi
- yêu cầu nhập một approval token ngắn gắn với plan hash
- lưu plan vào file, người dùng sửa trực tiếp rồi workflow mới thực thi
- tách riêng role “reviewer” nếu workflow chạy trong team
Với máy cá nhân, form hoặc Telegram approval là đủ dùng. Với môi trường team, mình sẽ thêm plan hash để tránh trường hợp plan bị thay đổi sau khi đã duyệt.
Checklist an toàn trước khi cho n8n đụng vào file thật
Anh em có thể dùng checklist này trước khi biến prototype thành workflow dùng hằng ngày:
- workflow có dry-run không
- AI chỉ tạo plan hay có quyền act trực tiếp
- plan có được hiển thị trước khi chạy thật không
- approval có gắn với đúng plan không
- có giới hạn thư mục được phép thao tác không
- có chặn delete vĩnh viễn không
- có log trước và sau khi chạy không
- có xử lý trùng tên file không
- có rollback hoặc ít nhất là report đủ rõ để tự phục hồi không
Điểm cuối rất quan trọng: nếu chưa có rollback, ít nhất đừng cho workflow xóa file. Move vào một thư mục staging như _n8n_Organized là lựa chọn an toàn hơn nhiều.
Kết luận
Thử nghiệm này là một ví dụ nhỏ nhưng đúng hướng: local AI automation không nên chỉ tập trung vào khả năng gọi tool, mà phải thiết kế quanh quyền hạn, approval và audit trail.
Với n8n, Ollama và một model local như Qwen, anh em hoàn toàn có thể dựng các operator nhỏ cho việc cá nhân: dọn file, phân loại tài liệu, chuẩn bị report, xử lý inbox nội bộ. Nhưng công thức nên là: lập kế hoạch trước, xin phép rõ ràng, hành động trong phạm vi hẹp, rồi báo cáo lại đầy đủ.
Nếu giữ được khung đó, n8n không chỉ là công cụ nối API, mà có thể trở thành một lớp điều phối an toàn cho automation chạy ngay trên máy của mình.
Top comments (0)