n8n cho FDE: dựng luồng LLM trong một buổi chiều, nhưng biết lúc nào phải chuyển sang code

Khách hàng muốn mọi email hỗ trợ được phân loại tự động, những email gấp thì chuyển thẳng cho đúng người. Bạn có hai ngày. Nếu viết service từ đầu, nhiều khả năng hết hai ngày bạn vẫn đang dựng khung. Với n8n, đến chiều thứ nhất bạn đã có thể ngồi cạnh khách và cho họ xem luồng chạy thật.

Trang chủ n8n tự giới thiệu bằng một câu: dựng bằng giao diện trực quan, đi sâu bằng code, kết nối với mọi thứ. Repo GitHub chính thức nói thêm về hơn 400 integration, lựa chọn self-host hoặc cloud và khả năng AI có sẵn.

Với một FDE, sức hút nằm ở chỗ bạn rút ngắn được quãng đường từ buổi customer discovery đến lần đầu khách được xem một luồng chạy trên dữ liệu của chính họ.

Có điều tốc độ làm demo không phải câu hỏi khó nhất. Câu hỏi khó hơn là khi nào bạn phải rời n8n.

Lõi LLM của n8n làm được gì?

Tài liệu của n8n cho biết bạn có thể dựng workflow AI nối với nhiều nhà cung cấp LLM như OpenAI, Anthropic và Google. Phần đáng dùng nhất là AI Agent node. Bạn gắn vào đó một chat model cùng một hoặc vài tool, rồi agent tự quyết định gọi tool nào để hoàn thành việc được giao.

Áp vào ví dụ phân loại email, luồng có thể trông như sau. Một trigger nhận email mới và đẩy nội dung vào AI Agent node. Agent có hai tool: một tool tra cứu khách hàng trong hệ thống của họ, một tool tạo ticket.

Vì agent tự chọn tool, phần mô tả từng tool chính là thứ bạn cần viết kỹ nhất. Dưới đây là một phác thảo giả định để bạn hình dung nội dung cần chuẩn bị trước khi kéo node, không phải định dạng cấu hình chính xác của n8n:

Tool 1: tra_cuu_khach_hang
  Mô tả: Dùng khi email có địa chỉ gửi hoặc mã khách hàng.
         Trả về hạng hợp đồng và người phụ trách.
  Đầu vào: email_nguoi_gui

Tool 2: tao_ticket
  Mô tả: Dùng sau khi đã biết khách là ai.
         Mức "gấp" nếu email nói hệ thống ngừng chạy.
  Đầu vào: tieu_de, muc_do (thuong | gap), nguoi_phu_trach

Từ nội dung email, agent tự quyết định cần tra cứu trước hay tạo ticket ngay. Mô tả tool càng rõ điều kiện “dùng khi nào”, agent càng ít gọi sai, nên đây là chỗ bạn nên ngồi cùng khách để chốt từng chữ.

Nếu bạn phải bảo trì workflow do người khác dựng thì cần biết một chi tiết. Từ phiên bản 1.82.0, cài đặt agent type của AI Agent node đã bị deprecate, và mọi AI Agent node giờ đều chạy như Tools Agent.

Một workflow cũ từng được chọn kiểu agent khác có thể sẽ chạy khác sau khi nâng cấp. Hãy test lại trước khi nâng cấp ở môi trường của khách.

Lỗi sẽ xảy ra, câu hỏi là ai biết trước

LLM có lúc timeout, có lúc trả về JSON sai định dạng, và API của khách có lúc sập. n8n cho bạn gắn một error workflow cho từng workflow, với điều kiện error workflow đó phải bắt đầu bằng node Error Trigger. Trong ví dụ email, error workflow có thể báo cho kênh vận hành của khách, kèm thông tin email nào bị lỗi.

Demo chỉ cần chạy đúng khi bạn đang đứng cạnh. Còn một luồng khách dám để tự chạy qua đêm thì phải tự báo được khi nó chạy sai. Khi bàn giao, hãy cho khách xem luồng lỗi hoạt động thế nào, chứ đừng chỉ cho xem luồng chạy đúng.

Những sai lầm dưới đây là suy luận từ chính cách n8n hoạt động, và rất đáng rà lại trước mỗi buổi bàn giao:

Sai lầm hay gặp	Hậu quả	Cách tránh
Mô tả tool mơ hồ, không nói rõ “dùng khi nào”	Agent gọi nhầm tool hoặc bỏ qua bước tra cứu	Viết điều kiện dùng cho từng tool, chốt cùng khách
Không gắn error workflow	Email lỗi biến mất lặng lẽ, khách phát hiện sau	Gắn error workflow bắt đầu bằng Error Trigger, báo về kênh vận hành
Nhồi logic nghiệp vụ vào Code node	Đụng giới hạn HTTP, file system, npm khi đã gần xong	Tách ra service riêng, n8n chỉ điều phối
Nâng cấp n8n mà không test workflow cũ	AI Agent node chạy khác vì agent type đã bị deprecate	Test lại trên bản sao trước khi nâng cấp ở môi trường khách

Khi nào Code node không đủ?

n8n có Code node để bạn viết logic tuỳ chỉnh, nhưng tài liệu ghi rõ hai giới hạn: Code node không truy cập được file system và không gọi HTTP trực tiếp được. Trên n8n Cloud còn thêm một giới hạn nữa là không import được module npm bên ngoài.

Thử hình dung khách cần chuẩn hoá địa chỉ tiếng Việt bằng một thư viện nội bộ, hoặc cần gọi một API ký request theo cách riêng của họ. Nếu đang dùng Cloud, bạn không cài được thư viện đó.

Ngay cả khi tự host, đoạn logic ấy cũng không nên nhồi vào Code node. Cách thực tế hơn là tách nó ra thành một service nhỏ do bạn viết và kiểm thử, để n8n chỉ lo điều phối.

Khi một instance không còn đủ

Tải là tín hiệu thứ hai. n8n có queue mode với các worker tách riêng, và tài liệu gọi đây là chế độ scale tốt nhất: tải tăng thì thêm worker, tải giảm thì bớt worker.

Vậy dấu hiệu nào cho thấy đã đến lúc? Thử hình dung luồng email chạy êm suốt tuần, nhưng mỗi sáng thứ Hai, khi email cuối tuần dồn về cùng lúc, các execution xếp hàng chờ nhau vì mỗi lượt đều phải đợi LLM trả lời. Email “hệ thống ngừng chạy” của khách lớn nằm sau hàng trăm email thường và phải chờ rất lâu mới có ticket.

Đó là triệu chứng nên theo dõi: thời gian từ lúc email đến tới lúc có ticket tăng vọt vào giờ cao điểm, dù luồng không hề báo lỗi. Hãy đo con số này ngay từ tuần đầu.

Khi nó vượt mức khách chấp nhận được, đó là lúc tính đến queue mode, và cũng là lúc cần một người chịu trách nhiệm vận hành hẳn hoi, vì bạn đang chạy hạ tầng thật chứ không còn là một công cụ tiện tay.

Giấy phép là chỗ FDE dễ vấp nhất

n8n không phải open source thuần. Repo nói rõ phần mềm được phân phối theo kiểu fair-code, dưới Sustainable Use License và n8n Enterprise License.

Sustainable Use License chỉ cho phép dùng hoặc sửa phần mềm cho mục đích kinh doanh nội bộ của chính bạn, hoặc cho mục đích phi thương mại, cá nhân.

Việc phân phối hay cung cấp phần mềm cho người khác chỉ được phép khi làm miễn phí và vì mục đích phi thương mại.

Với FDE, nên đọc kỹ hai trường hợp. Khách tự chạy n8n để tự động hoá việc nội bộ của họ là một chuyện. Công ty bạn đóng gói n8n vào một giải pháp rồi bán hoặc cung cấp cho nhiều khách là chuyện khác hẳn. Trường hợp thứ hai cần pháp lý xem xét trước khi ký hợp đồng.

Giữa hai đầu đó có một vùng xám rất hay gặp. Thử hình dung công ty bạn tự host một instance n8n trên hạ tầng của mình, chỉ phục vụ đúng một khách, và tính phí dịch vụ vận hành hằng tháng.

Đó có còn là “mục đích nội bộ” không, hay đã thành “cung cấp cho người khác”? Câu chữ của giấy phép không tự trả lời thay bạn. Hãy ghi kịch bản này thành một câu hỏi cụ thể gửi pháp lý, và đừng đợi đến lúc bàn giao mới hỏi.

Doanh nghiệp còn hay hỏi thêm về governance. Bản Community có gần như đầy đủ tính năng, nhưng thiếu SSO, Projects và version control bằng Git. Nếu khách bắt buộc đăng nhập tập trung hoặc muốn review workflow như review code, bạn cần nói rõ chuyện này ngay từ buổi đầu.

Học gì trước, ghi gì vào CV

Hãy bắt đầu bằng việc tự host n8n, vì như vậy bạn tránh được giới hạn npm của bản Cloud và hiểu luôn phần vận hành. Sau đó lần lượt luyện ba thứ: AI Agent node với tool tự định nghĩa, error workflow, và cách tách logic phức tạp ra một service riêng để n8n gọi.

Trong CV, đừng chỉ ghi “thành thạo n8n”. Hãy kể một quyết định cụ thể, ví dụ: dựng prototype phân loại email bằng n8n trong hai ngày, rồi tách phần chuẩn hoá dữ liệu ra thành service riêng khi Code node không còn đủ. Một dòng như vậy cho người đọc thấy cả tốc độ lẫn khả năng phán đoán.

Khách hàng sẽ nhớ cái demo bạn dựng xong trong một buổi chiều. Nhưng giá trị của một FDE nằm ở chỗ biết đúng lúc nào thì chuyển phần việc đó sang code.