วิธีสร้าง AI Agent ด้วย n8n บน VPS ของคุณเอง

AI Agent ของ n8n คืออะไร และแตกต่างจาก chain อย่างไร

AI Agent ของ n8n คือโหนด AI Agent เพียงโหนดเดียวที่มีโหนดลูกเชื่อมต่ออยู่ ได้แก่ โมเดลแชท, เครื่องมือ (tools) ตั้งแต่หนึ่งอย่างขึ้นไป และหน่วยความจำ (memory) ที่เลือกใส่ได้ คุณเพียงระบุเป้าหมายด้วยภาษาทั่วไป แล้วโมเดลจะเป็นผู้ตัดสินใจว่าจะเรียกใช้เครื่องมือใดและตามลำดับใดจนกว่าจะสามารถตอบคำถามได้ เนื้อหาทั้งหมดด้านล่างนี้คือการตั้งค่าที่เกี่ยวข้องกับแนวคิดดังกล่าว

การทำงานของ chain จะเป็นไปในทางตรงกันข้าม ใน Basic LLM Chain คุณเป็นผู้กำหนดขั้นตอนต่างๆ และโมเดลทำหน้าที่เพียงเติมข้อความเท่านั้น แต่ใน agent โมเดลจะเป็นผู้กำหนดขั้นตอนเอง ดังนั้นคำถามเดียวกันอาจใช้การเรียกโมเดลเพียงครั้งเดียวในวันนี้ แต่อาจใช้ถึงเก้าครั้งในวันพรุ่งนี้ ความแตกต่างเพียงจุดเด่นนี้เป็นตัวกำหนดการตั้งค่าทุกอย่างในคู่มือฉบับนี้

คู่มือนี้ตั้งสมมติฐานว่า n8n กำลังทำงานอยู่หลัง HTTPS บนเครื่องที่คุณดูแล หากยังไม่ได้ดำเนินการดังกล่าว ให้เริ่มต้นด้วย การ self-host n8n บน Docker ด้วย certificate จริง เนื่องจาก API key ที่คุณกำลังจะจัดเก็บจำเป็นต้องมีการสำรองข้อมูล encryption-key ตามที่คู่มือดังกล่าวระบุไว้ สำหรับรูปแบบที่ไม่ใช่ agent เช่น webhook summarizers และ scheduled classifiers โปรดดู รูปแบบ workflow ของ Claude และ n8n

โปรดตรวจสอบเวอร์ชันของคุณก่อนที่จะเชื่อถือชื่อฟิลด์ใดๆ ในที่นี้ เนื่องจาก n8n มีการเปลี่ยนแปลงโหนด AI อยู่บ่อยครั้ง

docker compose exec n8n n8n --version

ชื่อที่ใช้ในคู่มือนี้ตรงกับ n8n เวอร์ชัน stable ปัจจุบัน ณ เดือนกรกฎาคม 2026 นับตั้งแต่เวอร์ชัน 1.82.0 เป็นต้นมา โหนด AI Agent ทุกโหนดจะทำงานในรูปแบบ Tools Agent ดังนั้นเมนูแบบเลื่อนลงสำหรับเลือกประเภท agent แบบเดิมจึงไม่มีอยู่อีกต่อไป

ขั้นตอนที่ 1: เลือกตัวกระตุ้น (Trigger)

สำหรับเอเจนต์แบบสนทนา ให้เพิ่มโหนด Chat Trigger โดยให้ปิดตัวเลือก Make Chat Publicly Available ไว้ในระหว่างการสร้าง เพื่อให้เฉพาะแผงแชทในตัวแก้ไขเท่านั้นที่เข้าถึงได้ ให้เปิดใช้งานตัวเลือกนี้เมื่อสร้างเอเจนต์เสร็จสมบูรณ์และคุณตัดสินใจเรื่องการยืนยันตัวตนเรียบร้อยแล้ว

Chat Trigger จะส่งฟิลด์ที่ชื่อว่า chatInput ให้กับเอเจนต์ ชื่อนี้มีความสำคัญในขั้นตอนที่ 3 และการระบุชื่อผิดเป็นสาเหตุของความล้มเหลวที่พบบ่อยที่สุดในช่วงเริ่มต้น

สำหรับเอเจนต์ที่ทำงานโดยไม่มีผู้ดูแล ให้ใช้โหนด Schedule Trigger หรือ Webhook แทน ทั้งสองโหนดนี้จะไม่สร้าง chatInput ดังนั้นคุณจะต้องเขียน prompt ด้วยตนเอง

ขั้นตอนที่ 2: ข้อมูลรับรองของโมเดล

วางโหนด AI Agent ลงบนพื้นที่ทำงาน n8n จะแสดงตัวเชื่อมต่อ Chat Model ว่างเปล่าไว้ใต้โหนดทันที ให้เชื่อมต่อโหนดย่อย Anthropic Chat Model เข้าไปที่จุดนั้น

สร้างข้อมูลรับรอง (credential) จาก Anthropic Console ที่ platform.claude.com โดยไปที่เมนู Settings แล้วเลือก API Keys คีย์จะแสดงให้เห็นเพียงครั้งเดียวเท่านั้น การใช้งาน API จะคิดค่าบริการตามจำนวน token และแยกต่างหากจากการสมัครสมาชิก Claude.ai ดังนั้นบัญชีผู้ใช้จำเป็นต้องตั้งค่าการเรียกเก็บเงินให้เรียบร้อยก่อนการใช้งานครั้งแรก

ให้เลือกโมเดลตามความเหมาะสมของเอเจนต์แต่ละตัว ไม่ใช่เลือกตามบริษัท เอเจนต์ที่มีเครื่องมือเดียวซึ่งทำหน้าที่ค้นหาข้อมูลและรายงานผลสามารถทำงานได้ดีบน Haiku ซึ่ง ณ เดือนกรกฎาคม 2026 มีราคาอยู่ที่ $1 ต่อล้าน input token และ $5 ต่อล้าน output token เมื่อเอเจนต์เริ่มมีเครื่องมือหลายอย่างและต้องวางแผนการใช้งานเครื่องมือเหล่านั้น ให้เปลี่ยนไปใช้ Sonnet สิ่งที่คุณต้องหลีกเลี่ยงคือการใช้โมเดลราคาถูกที่เรียกใช้เครื่องมือผิดพลาดซ้ำถึงสี่ครั้ง ซึ่งจะมีค่าใช้จ่ายสูงกว่าการใช้โมเดลราคาสูงที่เรียกใช้เครื่องมือได้อย่างถูกต้องเพียงครั้งเดียว

ตั้งค่า Maximum Number of Tokens ในตัวเลือกของโหนดย่อย เพื่อจำกัดความยาวของคำตอบแต่ละครั้งที่โมเดลสร้างขึ้น หากปล่อยไว้ตามค่าเริ่มต้นที่สูงเกินไป การทำงานที่ผิดพลาดเพียงครั้งเดียวอาจสร้างคำตอบที่ยาวมากและทำให้คุณถูกเรียกเก็บเงินจำนวนมากได้

ข้อควรระวังประการหนึ่งจากเอกสารของ n8n ที่มักทำให้ผู้ใช้พลาดคือ นิพจน์ (expressions) ภายในโหนดย่อยจะประมวลผลเทียบกับรายการข้อมูลอินพุต รายการแรก เสมอ ไม่ใช่ประมวลผลทีละรายการ ดังนั้นให้ใส่นิพจน์ที่ต้องการประมวลผลทีละรายการไว้ในช่อง prompt ของโหนดหลักแทน

ขั้นตอนที่ 3: พรอมต์ที่เอเจนต์ได้รับ

เปิดโหนด AI Agent ขึ้นมา พารามิเตอร์ Prompt มีการตั้งค่าอยู่ 2 รูปแบบ

• Take from previous node automatically คาดหวังฟิลด์ขาเข้าที่ชื่อว่า chatInput นี่คือตัวเลือกที่เหมาะสมเมื่อใช้งานต่อจาก Chat Trigger
• Define below จะแสดงฟิลด์ Prompt (User Message) ซึ่งคุณสามารถเขียนข้อความแบบคงที่หรือนิพจน์ลงไปได้ นี่คือตัวเลือกที่เหมาะสมเมื่อใช้งานต่อจาก Schedule Trigger หรือโหนด Webhook

เมื่อมีโหนด Webhook อยู่ด้านหน้า ข้อมูล POST body จะเข้ามาภายใต้ $json.body ดังนั้นฟิลด์พรอมต์จะมีลักษณะดังนี้

Check the current status of {{ $json.body.service }} and tell me
whether it is up. If it is down, say for how long. No preamble.

ขั้นตอนที่ 4: เพิ่มเครื่องมือให้ Agent

AI Agent node ที่ไม่มี tool sub-node จะไม่สามารถทำงานได้ ให้เริ่มจากเครื่องมือเดียว เพราะการทำให้เครื่องมือหนึ่งตัวทำงานได้จริงจะให้ความรู้มากกว่าการตั้งค่าเครื่องมือสี่ตัวที่ไม่สมบูรณ์

เชื่อมต่อ HTTP Request node เข้ากับช่อง Tool ของ Agent ให้ตั้งค่าเหมือนกับที่คุณตั้งค่า HTTP Request node ปกติ จากนั้นให้ทดสอบ endpoint นั้นจาก shell ก่อน

curl -s -H 'Accept: application/json' \
  https://status.example.com/api/status/database | head -c 400

หากคำสั่ง curl ส่งค่าความผิดพลาดหรือหน้า HTML สำหรับล็อกอินกลับมา Agent ก็จะทำงานล้มเหลวเช่นกัน และข้อความแสดงความผิดพลาดจะดูเหมือนเป็นปัญหาที่ตัวโมเดล ทั้งที่จริงแล้วเป็นปัญหาที่ URL หรือการยืนยันตัวตน ให้แก้ไขที่ shell ไม่ใช่ที่ node

ช่อง Description ของเครื่องมือไม่ใช่เอกสารสำหรับเพื่อนร่วมงานของคุณ แต่เป็นสิ่งเดียวที่โมเดลอ่านเพื่อตัดสินใจว่าเครื่องมือนี้เกี่ยวข้องหรือไม่ ให้เขียนเป็นประโยคบอกเล่าตรงไปตรงมาว่าผลลัพธ์ที่ได้คืออะไร เช่น "ส่งคืนสถานะปัจจุบันว่า up หรือ down และระยะเวลาที่ระบบล่มสำหรับบริการที่ตรวจสอบหนึ่งรายการ ในรูปแบบ JSON"

หากต้องการให้โมเดลกรอกข้อมูลบางส่วนของคำขอ ให้ใช้ expression $fromAI() ซึ่งจะทำงานเฉพาะในเครื่องมือที่เชื่อมต่อกับ AI Agent node เท่านั้น และไม่สามารถใช้ใน Code tool ได้

{{ $fromAI('service', 'The name of the service to look up', 'string') }}

อาร์กิวเมนต์ประกอบด้วย key ตามด้วย description, type และ defaultValue ที่เป็นตัวเลือกเสริม คีย์ต้องมีความยาว 1 ถึง 64 ตัวอักษร โดยใช้ตัวอักษร ตัวเลข ขีดล่าง และขีดกลาง ประเภทข้อมูลต้องเป็นหนึ่งใน string, number, boolean หรือ json โดยมีค่าเริ่มต้นเป็น string ตัวอย่างการเรียกใช้งานที่สมบูรณ์มีลักษณะดังนี้

{{ $fromAI('limit', 'How many records to return', 'number', 20) }}

คีย์เป็นเพียงคำใบ้ ไม่ใช่การอ้างอิงถึงข้อมูลที่มีอยู่จริง $fromAI('service') ไม่ได้อ่านฟิลด์ที่ชื่อ service จากที่ใดทั้งสิ้น แต่เป็นการบอกโมเดลว่า "สร้างค่าขึ้นมาหนึ่งค่าแล้วเรียกมันว่า service" จากนั้นโมเดลจะค้นหาผ่านบทสนทนา ข้อมูลนำเข้า และผลลัพธ์จากเครื่องมืออื่นๆ เพื่อหาค่าดังกล่าว ใน workflow แบบแชท โมเดลอาจถามผู้ใช้โดยตรง

การค้นหาบนเว็บเป็นเครื่องมือลำดับที่สองที่นิยมใช้ และเนื่องจากมันเป็นเพียง HTTP endpoint อีกตัวหนึ่ง คุณสามารถชี้ node นี้ไปที่ SearXNG instance ของคุณเองแทนการใช้ search API แบบเสียค่าใช้จ่าย โดยมีเงื่อนไขว่าคุณต้องถือว่าทุกหน้าเว็บที่ดึงกลับมาเป็นข้อความที่ไม่น่าเชื่อถือซึ่งถูกนำเข้ามาอยู่ใน prompt ของคุณแล้ว

ขั้นตอนที่ 5: หน่วยความจำและเหตุผลที่เอเจนต์ลืมข้อมูล

หากไม่มีโหนดลูกประเภทหน่วยความจำ ทุกข้อความจะเริ่มต้นจากศูนย์ ให้เพิ่มโหนดลูก Simple Memory เพื่อเก็บประวัติการสนทนาล่าสุด

โหนดนี้มีพารามิเตอร์ 2 ตัว ได้แก่ Session Key ซึ่งใช้กำหนดว่านี่คือการสนทนาใด ดังนั้นผู้ใช้สองคนที่ใช้คีย์ต่างกันจะได้รับประวัติแยกกัน และ Context Window Length ซึ่งกำหนดจำนวนการโต้ตอบก่อนหน้าที่ถูกส่งกลับเข้าไปใน prompt

Context Window Length เป็นตัวปรับจูนทั้งคุณภาพและต้นทุน เนื่องจากทุกการสนทนาที่ถูกจดจำจะถูกส่งซ้ำในฐานะ input tokens ในทุกการเรียกใช้งานในภายหลัง หากตั้งค่า window ไว้ที่ 20 ในเอเจนต์ที่มีการสนทนาบ่อย คุณจะต้องจ่ายค่าใช้จ่ายสำหรับข้อความแรกๆ ซ้ำกันถึง 20 ครั้ง

Simple Memory ไม่สามารถทำงานได้ใน workflow การผลิตจริงเมื่อ n8n ทำงานในโหมด queue เนื่องจากประวัติจะถูกเก็บไว้ในข้อมูลของ workflow เองแทนที่จะเป็นที่จัดเก็บส่วนกลาง สำหรับ instance ในโหมด queue ให้ใช้โหนดลูก Postgres Chat Memory แทน และชี้ไปยังฐานข้อมูลที่ทั้งกระบวนการหลักและ worker สามารถเข้าถึงได้

ขั้นตอนที่ 6: ข้อความระบบ (System Message)

เปิด Options ของเอเจนต์แล้วเพิ่ม System Message ลงไป นี่คือส่วนที่ใช้ระบุรายละเอียดงาน และเป็นข้อความที่มีผลต่อประสิทธิภาพการทำงานมากที่สุดในเวิร์กโฟลว์นี้

You are an infrastructure status assistant. Always call the status
tool before answering a question about whether something is running.
Never guess. If the tool returns an error, say so and stop.

คำสั่ง "Always call the status tool before answering" (ต้องเรียกใช้เครื่องมือ status ก่อนตอบเสมอ) มีความสำคัญอย่างยิ่ง หากไม่มีคำสั่งนี้ โมเดลที่คิดว่าตนเองทราบคำตอบอยู่แล้วจะข้ามการใช้เครื่องมือและตอบจากหน่วยความจำ ซึ่งอาจให้ข้อมูลที่ผิดพลาดอย่างมั่นใจทันทีที่โครงสร้างพื้นฐานของคุณมีการเปลี่ยนแปลง

เหตุใดเอเจนต์จึงทำงานวนซ้ำ และสิ่งใดที่หยุดการทำงานนั้น

ภายใต้หัวข้อ Options จะมีค่า Max Iterations ซึ่งค่าเริ่มต้นคือ 10 หนึ่งรอบการทำงาน (iteration) ประกอบด้วยการเรียกใช้งานโมเดลหนึ่งครั้งบวกกับผลลัพธ์จากเครื่องมือที่ถูกส่งกลับเข้าไปในบริบท (context) ดังนั้นการรันเอเจนต์หนึ่งครั้งจึงไม่ใช่การเรียก API เพียงครั้งเดียว แต่อาจเรียกได้สูงสุดถึง 10 ครั้ง และแต่ละครั้งจะนำบทสนทนาทั้งหมดที่เพิ่มขึ้นเรื่อยๆ เข้าไปเป็นข้อมูลนำเข้าด้วย

ให้ปรับค่านี้ให้ต่ำลง เอเจนต์ที่ใช้เครื่องมือเดียวส่วนใหญ่จะทำงานเสร็จสิ้นภายใน 2 รอบ ดังนั้นการจำกัดไว้ที่ 3 หรือ 4 รอบจะช่วยเปลี่ยนการทำงานที่วนซ้ำไม่รู้จบให้กลายเป็นความล้มเหลวที่ชัดเจน ซึ่งคุณสามารถตรวจสอบได้ในรายการการทำงาน (execution list)

ในระหว่างการดีบั๊ก ให้เปิดใช้งาน Return Intermediate Steps ผลลัพธ์สุดท้ายจะรวมการเรียกใช้เครื่องมือที่เอเจนต์ทำไประหว่างทาง ซึ่งเป็นวิธีที่คุณจะใช้แยกแยะระหว่าง "โมเดลไม่เคยเรียกใช้เครื่องมือ" กับ "เครื่องมือไม่ส่งผลลัพธ์ที่มีประโยชน์กลับมา" ให้ปิดการตั้งค่านี้ก่อนนำไปใช้งานจริง เนื่องจากขั้นตอนเหล่านั้นเป็นข้อมูลส่วนเกินสำหรับผู้ใช้งานปลายทาง

ให้เฝ้าดูการทำงานผ่านเชลล์

docker compose logs -f n8n

การป้องกันไม่ให้เอเจนต์ที่ทำงานอัตโนมัติใช้จ่ายงบประมาณโดยไม่รู้ตัว

Agent ที่อยู่หลัง Chat Trigger มีคนคอยตรวจสอบ และคนนั้นสามารถหยุดการทำงานได้เมื่อเห็นว่าคำตอบไม่ถูกต้อง ส่วน Agent ที่อยู่หลัง Schedule Trigger ไม่มีใครคอยตรวจสอบ สิ่งที่ต้องเฝ้าดูในที่นี้คือค่าใช้จ่ายด้านการประมวลผลของโมเดล ไม่ใช่ค่าใช้จ่ายด้านไลเซนส์ เพราะ node สำหรับ agent, tool และ memory ทั้งหมดใช้งานได้ในรุ่น self-hosted แบบไม่มีค่าใช้จ่าย และ ฟีเจอร์ที่ต้องใช้ paid key ส่วนใหญ่เป็นฟีเจอร์สำหรับทีมและการกำกับดูแล รายละเอียดทั้งหมดอยู่ใน การควบคุมค่าใช้จ่ายของ AI agent บน VPS ที่เปิดทำงานตลอดเวลา การตั้งค่า 4 รายการมีผลกับเรื่องนี้เป็นส่วนใหญ่

• จำกัด Maximum Number of Tokens ที่โหนดโมเดล เพื่อไม่ให้การตอบกลับเพียงครั้งเดียวใช้โทเค็นจำนวนมากเกินไป
• ตั้งค่า Max Iterations ให้เป็นจำนวนที่น้อยที่สุดที่ยังสามารถทำงานให้สำเร็จได้
• จำกัดขนาดการตอบกลับของเครื่องมือ (tool) ให้มีขนาดเล็ก เครื่องมือที่ส่งคืนข้อมูล JSON ขนาด 4,000 บรรทัด จะทำให้ข้อมูลทั้งหมดถูกนำไปรวมในการเรียกใช้โมเดลครั้งถัดไป และรวมอยู่ในการเรียกใช้ทุกครั้งหลังจากนั้นในการทำงานรอบเดียวกัน
• พิจารณาว่าเอเจนต์จำเป็นต้องมีตารางเวลา (schedule) หรือไม่ งานที่รันทุก 5 นาทีจะทำงานถึง 288 ครั้งต่อวัน ไม่ว่าการทำงานหนึ่งรอบจะมีค่าใช้จ่ายเท่าใด นั่นคือตัวเลขที่คุณต้องนำไปคูณเพื่อคำนวณค่าใช้จ่ายรวม

ให้ปิดการใช้งาน (deactivate) เวิร์กโฟลว์ในขณะที่คุณกำลังปรับปรุงแก้ไข เวิร์กโฟลว์ที่เปิดใช้งานอยู่พร้อม Schedule Trigger จะยังคงทำงานโดยอ้างอิงจากเวอร์ชันที่ n8n บันทึกไว้ ซึ่งอาจไม่ใช่เวอร์ชันเดียวกับที่คุณกำลังแก้ไขอยู่บนหน้าจอ

FAQ

ทำไมโหนด AI Agent ของฉันถึงไม่ยอมทำงาน?

โหนด AI Agent จำเป็นต้องมีโหนดลูกประเภท chat model และโหนดลูกประเภท tool อย่างน้อยหนึ่งรายการ โหนดที่มีโมเดลแต่ไม่มีเครื่องมือจะหยุดทำงานก่อนที่จะมีการเรียก API ใดๆ ให้เพิ่มเครื่องมือเข้าไปหนึ่งรายการ แม้จะเป็นเครื่องมือพื้นฐานก็ตาม แล้วลองรันใหม่อีกครั้ง

เอเจนต์ตอบกลับมา แต่ไม่ยอมเรียกใช้เครื่องมือของฉัน เกิดอะไรขึ้น?

สาเหตุส่วนใหญ่อยู่ที่ช่อง Description ของเครื่องมือ โมเดลจะเลือกใช้เครื่องมือโดยการอ่านคำอธิบายเหล่านั้น ดังนั้นคำอธิบายอย่างเช่น "HTTP Request" จึงไม่ได้บอกอะไรเลยว่าควรใช้เครื่องมือนี้เมื่อใด ให้เขียนใหม่โดยระบุว่าข้อมูลที่ได้รับกลับมาคืออะไรและมีประโยชน์ในสถานการณ์ใด จากนั้นเพิ่มบรรทัดใน System Message เพื่อสั่งให้เอเจนต์เรียกใช้เครื่องมือนั้นก่อนที่จะตอบกลับ

ทำไมคำถามเดิมถึงมีค่าใช้จ่ายต่างกันในแต่ละครั้งที่รัน?

เนื่องจากโมเดลเป็นผู้เลือกว่าจะใช้กี่ขั้นตอนในการทำงาน แต่ละรอบการทำงานจะส่งประวัติการสนทนาทั้งหมดกลับไปใหม่ รวมถึงผลลัพธ์จากเครื่องมือในรอบก่อนหน้า ดังนั้นการรันที่ใช้สี่รอบจึงมีค่าใช้จ่ายสูงกว่าการเรียกใช้งานครั้งเดียวมากกว่าสี่เท่า ค่า Max Iterations คือขีดจำกัดสูงสุดของจำนวนรอบ และ Return Intermediate Steps จะแสดงให้เห็นว่าการรันนั้นใช้ไปกี่ขั้นตอนจริงๆ

ทำไมหน่วยความจำ (Memory) ถึงทำงานในตัวแก้ไข (editor) แต่ไม่ทำงานในสภาพแวดล้อมใช้งานจริง (production)?

ตรวจสอบว่า instance ของคุณรันในโหมด queue หรือไม่ Simple Memory จะจัดเก็บประวัติไว้ในข้อมูลการทำงานของ workflow เอง ซึ่งข้อมูลนี้จะไม่คงอยู่เมื่อถูกส่งต่อไปยังกระบวนการ worker แยกต่างหาก ทำให้ workflow ใน production ที่กำลังทำงานอยู่สูญเสียข้อมูลดังกล่าวไป ให้เปลี่ยนไปใช้โหนดลูก Postgres Chat Memory แทน ซึ่งจะเก็บประวัติไว้ในฐานข้อมูลที่ worker ทุกตัวใช้งานร่วมกัน