Thêm bước người duyệt cho agent trước khi hành động trong n8n
Thiết kế luồng để AI phân loại, tóm tắt và tạo đề xuất; chỉ thực hiện các thao tác như gửi email hoặc cập nhật CRM sau khi có quyết định duyệt rõ ràng của con người.
Một agent có thể nhanh chóng phân loại email, tóm tắt yêu cầu và soạn phản hồi. Nhưng nếu bước kế tiếp là gửi thư cho khách hàng hoặc cập nhật CRM, đội vận hành vẫn cần một điểm kiểm soát rõ ràng.
Mô hình phù hợp trong nhiều tình huống là: AI chuẩn bị đề xuất, con người duyệt, workflow mới thực hiện hành động.
Playbook này trình bày một mẫu luồng human-in-the-loop trong n8n. Mục tiêu không phải để AI tự động hoàn toàn, mà là dùng AI cho phần đọc hiểu và chuẩn bị việc, trong khi người phụ trách giữ quyền quyết định trước các hành động có tác động bên ngoài.
Trước hết: bạn cần workflow hay agent?
Anthropic phân biệt hai dạng hệ thống agentic:
Workflow: LLM và công cụ được điều phối theo các đường đi đã xác định trước bằng mã hoặc logic.
Agent: mô hình tự quyết định quy trình và cách sử dụng công cụ để hoàn thành nhiệm vụ.
Khác biệt này ảnh hưởng trực tiếp đến cách thiết kế luồng duyệt.
Nếu đầu vào có các nhóm rõ ràng, chẳng hạn email hỗ trợ kỹ thuật, yêu cầu hoàn tiền hoặc câu hỏi chung, một workflow cố định thường là điểm bắt đầu dễ kiểm soát hơn. Anthropic gọi mẫu này là routing: phân loại đầu vào rồi chuyển sang nhánh xử lý phù hợp.
Agent phù hợp hơn khi tác vụ cần sự linh hoạt, chẳng hạn tự chọn công cụ hoặc tự xác định các bước xử lý. Tuy vậy, Anthropic lưu ý rằng hệ thống agentic có thể đánh đổi chi phí và độ trễ để đạt hiệu quả xử lý tốt hơn. Vì thế, nên bắt đầu từ giải pháp đơn giản nhất; trong nhiều trường hợp, một lần gọi LLM được thiết kế tốt cùng ngữ cảnh và ví dụ phù hợp đã đủ.
Với những thao tác như gửi email, cập nhật CRM hoặc tạo yêu cầu mới, bạn có thể đặt workflow cố định ở phía sau AI để kiểm soát điều kiện thực thi.
Mẫu kiến trúc: AI đề xuất, người duyệt quyết định
Tài liệu n8n cho biết nền tảng này hỗ trợ xây dựng AI workflow, kết nối nhiều nhà cung cấp LLM, bổ sung công cụ, memory và kết hợp nhiều mô hình.
Một mẫu luồng human-in-the-loop có thể được thiết kế như sau:
text
Trigger
-> Chuẩn hóa dữ liệu
-> AI phân loại và tạo đề xuất
-> Kiểm tra đầu ra có cấu trúc
-> Tạo bản nháp chờ duyệt
-> Người duyệt chọn approve / reject / edit
-> Kiểm tra trạng thái duyệt
-> Thực hiện hành động bên ngoài
-> Ghi nhận kết quả
Nguyên tắc cốt lõi: không để đầu ra AI đi thẳng tới bước hành động bên ngoài. Giữa phần đề xuất và phần thực thi cần có một điều kiện kiểm tra trạng thái duyệt.
Anthropic mô tả prompt chaining là mẫu chia tác vụ thành chuỗi bước, trong đó đầu ra của bước trước trở thành đầu vào của bước sau. Mẫu này có thể thêm các kiểm tra bằng chương trình tại những điểm trung gian. Trong luồng human-in-the-loop, bước duyệt là điểm kiểm soát nghiệp vụ trước khi workflow tiếp tục.
Mẫu luồng cho email và CRM
Hãy lấy ví dụ một yêu cầu khách hàng đi vào hệ thống qua email, biểu mẫu hoặc CRM.
1. Chuẩn hóa dữ liệu đầu vào
Trước khi gọi LLM, chuẩn bị các trường cần thiết cho tác vụ. Ví dụ:
json
{
"customerid": "<customerid>",
"customermessage": "<customermessage>",
"customercontext": "<customercontext>",
"policyexcerpt": "<policyexcerpt>"
}
Việc chuẩn hóa giúp các bước sau có dữ liệu nhất quán: AI nhận cùng một cấu trúc, người duyệt nhìn được cùng một tập thông tin, và workflow có thể kiểm tra các trường bắt buộc.
2. Yêu cầu AI tạo đầu ra có cấu trúc
Với tác vụ phân loại và soạn nháp, thay vì chỉ yêu cầu AI trả lời tự do, hãy yêu cầu một cấu trúc rõ ràng để bước tiếp theo có thể đọc và xử lý.
Ví dụ prompt:
text
Bạn là trợ lý vận hành. Hãy phân tích yêu cầu khách hàng.
Dữ liệu:
customerid: <customerid>
customermessage: <customermessage>
customercontext: <customercontext>
policyexcerpt: <policyexcerpt>
Nhiệm vụ:
Phân loại yêu cầu vào một nhóm phù hợp.
Tóm tắt vấn đề.
Soạn bản nháp phản hồi.
Đề xuất thao tác CRM nếu cần.
Nêu các điểm người duyệt cần kiểm tra.
Chỉ trả về JSON hợp lệ theo cấu trúc:
{
"category": "<category>",
"summary": "<summary>",
"draftreply": "<draftreply>",
"crmproposal": {
"action": "<proposedaction>",
"reason": "<reason>"
},
"riskflags": ["<riskflag>"],
"needshumanapproval": true
}
Trong mẫu này, trường needshumanapproval là tín hiệu hiển thị trong dữ liệu đề xuất. Điều kiện thực thi vẫn nên nằm ở bước kiểm tra trạng thái duyệt của workflow, không phụ thuộc vào việc AI tự đánh giá có cần duyệt hay không.
3. Kiểm tra đề xuất trước khi chuyển người duyệt
Trước khi tạo bản nháp chờ duyệt, workflow có thể kiểm tra các điều kiện như:
Đầu ra có đọc được theo cấu trúc mong muốn không?
Có đủ trường category, summary, draftreply và crmproposal không?
Hành động CRM được đề xuất có thuộc nhóm thao tác mà đội vận hành cho phép xem xét không?
Có cờ rủi ro nào cần được đánh dấu cho người duyệt không?
Nếu đầu ra không đạt yêu cầu, workflow có thể đưa yêu cầu vào một nhánh xử lý riêng thay vì chuyển thẳng sang bước hành động.
Người duyệt cần thấy gì?
Mục tiêu của màn hình hoặc bước duyệt không phải là bắt người dùng đọc lại toàn bộ quy trình. Nó nên tập trung vào thông tin cần để quyết định.
Một bản ghi chờ duyệt có thể gồm:
json
{
"category": "generalquestion",
"summary": "Khách hàng hỏi tình trạng yêu cầu.",
"draftreply": "Chào <customername>, chúng tôi đã nhận được yêu cầu và đang kiểm tra thông tin liên quan.",
"crmproposal": {
"action": "addinternalnote",
"reason": "Ghi nhận khách hàng đã hỏi tình trạng xử lý."
},
"riskflags": [],
"needshumanapproval": true
}
Người duyệt có thể xem:
Nội dung yêu cầu gốc;
Phần tóm tắt do AI tạo;
Bản nháp phản hồi;
Đề xuất cập nhật CRM;
Các cờ cần lưu ý;
Trạng thái quyết định.
Một quy ước trạng thái đơn giản có thể là:
approved: workflow được phép tiếp tục sang bước hành động.
rejected: workflow kết thúc mà không thực hiện hành động bên ngoài.
edited: người duyệt sửa nội dung đề xuất trước khi đưa sang bước tiếp theo.
Tài liệu n8n được cung cấp chỉ xác nhận các khả năng xây dựng AI workflow và các thành phần liên quan; tài liệu này không mô tả một giao diện phê duyệt hoặc cấu hình duyệt cụ thể. Vì vậy, cách nhận quyết định duyệt sẽ phụ thuộc vào hệ thống và quy trình mà đội bạn sử dụng.
Đặt “gate” trước hành động thật
Bước quan trọng nhất trong thiết kế là điều kiện trước node hành động.
Ví dụ logic:
text
Nếu approvalstatus = approved
-> gửi email hoặc cập nhật CRM
Ngược lại
-> không thực hiện hành động bên ngoài
Cách tách này giúp phân biệt rõ hai phần:
AI tạo thông tin để hỗ trợ quyết định: phân loại, tóm tắt, bản nháp, đề xuất.
Workflow thực thi quyết định đã được xác nhận: gửi email, ghi CRM hoặc tạo yêu cầu.
Đó cũng là cách giữ workflow dễ quan sát hơn: khi có vấn đề, đội vận hành có thể kiểm tra đề xuất AI, trạng thái duyệt và hành động cuối cùng như ba bước riêng biệt.
Checklist trước khi áp dụng
[ ] Xác định rõ hành động nào cần người duyệt trước khi thực hiện.
[ ] Tách bước AI tạo đề xuất khỏi bước hành động bên ngoài.
[ ] Yêu cầu AI trả đầu ra có cấu trúc để workflow dễ kiểm tra.
[ ] Có bước kiểm tra dữ liệu trước khi tạo bản nháp chờ duyệt.
[ ] Có trạng thái duyệt rõ ràng như approved, rejected và edited.
[ ] Chỉ cho phép node hành động chạy khi trạng thái đáp ứng điều kiện duyệt.
[ ] Ghi nhận đề xuất AI, quyết định duyệt và kết quả thực thi để đội vận hành có thể theo dõi.
Human-in-the-loop không làm AI kém hữu ích. Nó đặt AI vào đúng vai trò: tăng tốc phần chuẩn bị, còn quyền quyết định vẫn nằm ở người chịu trách nhiệm cho kết quả cuối cùng.