n8n คือ workflow automation แบบ self-hosted ที่เราติดตั้งเองบนเครื่อง แล้วต่อ node เชื่อม API ของโมเดล local LLM กับ tool ต่างๆ ทำให้สร้าง AI agent ที่ทำงานตามเงื่อนไขได้จริง โดยไม่ต้องพึ่ง cloud provider
n8n คืออะไร ทำไมถึงเหมาะกับการสร้าง agent แบบ self-hosted
n8n เป็น workflow automation tool ที่ทำงานแบบ self-hosted บนเครื่องเราเอง เราสามารถติดตั้งผ่าน Docker ได้ง่ายๆ แล้วต่อ node ต่างๆ เข้าด้วยกันเพื่อสร้าง workflow ที่ซับซ้อน n8n มี node ให้เลือกกว่า 400 แบบ ครอบคลุมทั้ง HTTP Request, Webhook, AI/LLM, และ database connector ที่จำเป็นต่อการสร้างระบบอัตโนมัติ
สิ่งที่ทำให้ n8n เหมาะกับการสร้าง AI agent คือความสามารถในการกำหนดเงื่อนไข (IF node), loop, และ error handling ได้ครบถ้วน เราสามารถสร้าง workflow ที่รับ input จาก user ผ่าน webhook ส่งไปให้ LLM ประมวลผล แล้วให้ LLM เรียกใช้ tool ต่างๆ ผ่าน HTTP Request node ได้ทั้งหมด โดยไม่ต้องเขียนโค้ดมาก
ข้อแตกต่างสำคัญระหว่าง n8n กับ Make.com หรือ Zapier คือ n8n ทำงานบนเครื่องเราเอง ข้อมูลทั้งหมดไม่ออกนอกเครือข่าย ทำให้เหมาะกับการใช้ local LLM ที่ต้องการความเป็นส่วนตัว เราควบคุม version, update, และ configuration ได้ทั้งหมด ไม่ถูกจำกัดด้วย rate limit ของ cloud provider
ติดตั้ง n8n บนเครื่องหลักและต่อเข้ากับ local LLM
การติดตั้ง n8n บนเครื่องหลักของเราใช้ Docker command สั้นๆ คือ docker run -d --name n8n -p 5678:5678 -v ~/n8n_data:/home/▮▮▮/.n8n n8nio/n8n ซึ่งจะทำให้ n8n ทำงานบนพอร์ต 5678 ของเครื่องหลัก โดย volume mount ที่ ~/n8n_data เพื่อเก็บข้อมูล workflow อย่างถาวร
หลังจากติดตั้งแล้ว เราต้องตั้งค่า environment variable สำหรับเชื่อมต่อกับ local LLM เช่น Ollama ที่ทำงานบนพอร์ต 11434 ใน n8n เราใช้ HTTP Request node เพื่อส่ง POST request ไปที่ endpoint ของ Ollama ด้วย payload JSON ที่ระบุ model name, prompt, และ parameters ต่างๆ ที่ต้องการ
ตัวอย่าง payload ที่เราใช้คือ {"model": "llama3.2:3b-instruct", "prompt": "ข้อความที่ต้องการให้ LLM ประมวลผล", "stream": false, "options": {"temperature": 0.7, "num_predict": 512}} ซึ่งจะได้ response กลับมาในรูป JSON ที่มี field "message" บรรจุข้อความที่ LLM สร้างขึ้น โดยใช้เวลาประมาณ 2-4 วินาที สำหรับ prompt สั้นๆ
สร้าง workflow AI agent แบบ simple chatbot
workflow แรกที่เราสร้างเป็น chatbot ง่ายๆ ที่รับข้อความจาก user ผ่าน webhook node ส่งไปให้ LLM แล้วส่ง response กลับ webhook node ตั้งค่าให้รับ POST request ที่ endpoint /chat แล้ว parse body JSON เพื่อเอา field "message" ออกมา เพื่อส่งต่อให้ LLM ประมวลผล
จากนั้นเราใช้ HTTP Request node ส่ง request ไปยัง local LLM endpoint พร้อม prompt ที่เราจัดรูปแบบ เช่น "คุณเป็น AI assistant ที่ช่วยตอบคำถามภาษาไทย ตอบอย่างกระชับและเป็นประโยชน์: " + message ที่ได้รับ ซึ่งช่วยให้ LLM เข้าใจ context และตอบได้ตรงประเด็นมากขึ้น
response จาก LLM ถูกส่งกลับผ่าน webhook response node ในรูปแบบ JSON {"response": "ข้อความจาก LLM"} workflow นี้ทำงานได้จริง latency เฉลี่ยประมาณ 3-5 วินาที สำหรับ response ยาวไม่เกิน 200 tokens ซึ่งยอมรับได้สำหรับการใช้งานส่วนตัว
เพิ่ม tool calling ให้ agent ทำงานได้จริง
สิ่งที่ทำให้ workflow กลายเป็น "agent" จริงๆ คือความสามารถในการเรียกใช้ tool หรือ function ต่างๆ เราเพิ่ม node สำหรับเรียก HTTP API ของบริการต่างๆ เช่น weather API, calendar API, หรือ database query เพื่อให้ agent สามารถดึงข้อมูลจริงมาใช้ได้ ไม่ใช่แค่ตอบจาก training data
ตัวอย่างที่เราสร้างคือ agent ที่สามารถเช็คสภาพอากาศได้ เราสร้าง HTTP Request node ที่ส่ง GET request ไปยัง weather API endpoint พร้อม city name ที่ user ระบุ แล้วส่ง response กลับให้ LLM เพื่อสรุปเป็นภาษาไทยที่เข้าใจง่ายสำหรับ user
workflow กลายเป็น: user ถาม "สภาพอากาศที่กรุงเทพฯ วันนี้เป็นอย่างไร" → LLM วิเคราะห์ว่าต้องเรียก weather tool → HTTP Request node เรียก API → response ส่งกลับ LLM → LLM สรุปเป็นภาษาไทย → ส่ง给用户 ซึ่งเพิ่มความสามารถของ agent อย่างมีนัยสำคัญ
ทดลองจริงบนเครื่องเรา
เราทดสอบ workflow บน Mac Mini M4 Pro 32GB RAM ที่รัน n8n ผ่าน Docker และ Ollama พร้อมโมเดล llama3.2:3b-instruct ผลลัพธ์ที่วัดได้คือ latency เฉลี่ย 4.2 วินาที ต่อ request สำหรับ response ยาว 150-250 tokens CPU usage ของ n8n container อยู่ที่ประมาณ 15-25% เมื่อมี workflow ทำงานพร้อมกัน 3-5 workflow
การทดสอบ stress test ด้วย concurrent request 10 request พบว่า n8n จัดการ queue ได้ดี ไม่มี request หลุด แต่ latency เพิ่มขึ้นเป็น 8-12 วินาที ซึ่งยังอยู่ในเกณฑ์ที่ยอมรับได้สำหรับการใช้งาน personal agent ที่ไม่ได้ต้องการ throughput สูงมาก
เราทดลองใช้โมเดลที่ใหญ่ขึ้นคือ mistral:7b-instruct พบว่า quality ของ response ดีขึ้นชัดเจน โดยเฉพาะการเข้าใจบริบทภาษาไทย แต่ latency เพิ่มขึ้นเป็น 7-10 วินาที ต่อ request และ VRAM usage ของ Ollama เพิ่มเป็น 8.5 GB ซึ่งต้องพิจารณา trade-off ระหว่างคุณภาพและความเร็ว
บทเรียนจากความล้มเหลวและ tips สำหรับผู้เริ่มต้น
ความล้มเหลวที่สำคัญที่สุดที่เราเจอคือ workflow ที่ไม่มี error handling เมื่อ LLM endpoint down หรือ timeout workflow จะ hang อยู่ตลอด เราใช้เวลา debug ไป 2 วันกว่าจะพบว่าต้องเพิ่ม Error Workflow ใน n8n settings เพื่อจัดการ exception อย่างถูกต้อง
lesson ที่เรียนรู้คือต้องสร้าง error workflow แยกต่างหาก ที่ส่ง notification ไปยังเราเมื่อ workflow หลักล้มเหลว นอกจากนี้ต้องตั้งค่า timeout ใน HTTP Request node ให้ชัดเจน เช่น 30 วินาที เพื่อไม่ให้ request hang ตลอดและบล็อก resource ของระบบ
tips สำคัญอีกข้อคือควรใช้ IF node ตรวจสอบ response จาก LLM ก่อนส่งต่อ เช่น ตรวจสอบว่า response ไม่ใช่ null หรือ empty string และตรวจสอบ JSON format ถ้า LLM ส่งกลับ format ผิด workflow ต้อง handle ได้เพื่อป้องกัน error cascade ไปยัง node ถัดไป
สำหรับการ scale up เมื่อ workflow มีมากขึ้น เราแนะนำให้รัน n8n บนเครื่องแยกจากเครื่องที่รัน LLM เพื่อไม่ให้ resource แข่งกัน และใช้ PostgreSQL แทน SQLite เป็น database ของ n8n สำหรับ production use case เพื่อความเสถียรและ performance ที่ดีขึ้นในระยะยาว
อยากตามงานแล็บแบบนี้ต่อ ติดตาม LINE @icafefx หรือดาวน์โหลดเครื่องมือฟรีได้ที่ redhatai.net