สร้าง AI Agent ใน n8n บน VPS ด้วยตนเอง

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

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

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

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

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

docker compose exec n8n n8n --version

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

ขั้นตอนที่ 1: เลือกตัวทริกเกอร์

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

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

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

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

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

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

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

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

มีข้อควรระวังจากเอกสารของ n8n ที่มักทำให้เกิดปัญหา: expression ภายในโหนดย่อยจะประเมินค่าจากรายการอินพุตรายการแรกเสมอ และจะไม่ประเมินแยกตามแต่ละรายการ ให้ใส่ expression ที่ต้องประเมินแยกตามรายการไว้ในช่อง prompt ของโหนดราก

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

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

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

เมื่อวางโหนด Webhook ไว้ด้านหน้า เนื้อหา POST จะอยู่ภายใต้ $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: ให้เครื่องมือหนึ่งรายการแก่เอเจนต์

โหนด AI Agent ที่ไม่มีโหนดย่อยของเครื่องมือจะไม่ทำงาน ให้เริ่มด้วยเครื่องมือหนึ่งรายการ เพราะเครื่องมือที่ทำงานได้หนึ่งรายการให้ข้อมูลมากกว่าเครื่องมือสี่รายการที่กำหนดค่าไว้เพียงบางส่วน

เชื่อมต่อโหนด HTTP Request เข้ากับตัวเชื่อมต่อ Tool ของเอเจนต์ กำหนดค่าให้เหมือนกับโหนด HTTP Request ปกติทุกประการ จากนั้นทดสอบ endpoint นั้นจาก shell ก่อน

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

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

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

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

{{ $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 แบบแชต โมเดลอาจขอข้อมูลนี้จากผู้ใช้โดยตรง

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

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

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

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

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

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

เปิด Options ของ agent แล้วเพิ่ม 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" มีบทบาทสำคัญ หากไม่มีข้อความนี้ โมเดลที่คิดว่าตนเองทราบคำตอบอยู่แล้วจะไม่เรียกใช้เครื่องมือ และตอบจากข้อมูลในหน่วยความจำ ซึ่งอาจผิดอย่างมั่นใจทันทีที่โครงสร้างพื้นฐานของคุณมีการเปลี่ยนแปลง

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

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

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

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

ตรวจสอบการทำงานจาก shell ขณะที่กำลังทำงาน

docker compose logs -f n8n

ป้องกันไม่ให้เอเจนต์ที่ทำงานโดยไม่มีผู้ดูแลใช้ทรัพยากรอย่างเงียบ ๆ

เอเจนต์ที่อยู่หลัง Chat Trigger มีผู้ใช้งานคอยตรวจสอบ และผู้ใช้งานจะหยุดเอเจนต์เมื่อเห็นว่าคำตอบไม่ถูกต้อง เอเจนต์ที่อยู่หลัง Schedule Trigger ไม่มีผู้ตรวจสอบ การควบคุมค่าใช้จ่ายทั้งหมดอธิบายไว้ใน การควบคุมค่าใช้จ่ายของ AI agent บน VPS ที่เปิดทำงานตลอดเวลา การตั้งค่า 4 รายการมีผลต่อการควบคุมเป็นส่วนใหญ่

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

ปิดใช้งาน workflow ระหว่างการปรับแก้ workflow ที่เปิดใช้งานอยู่และมี Schedule Trigger จะยังทำงานโดยใช้เวอร์ชันที่ n8n บันทึกไว้ ซึ่งไม่ใช่เวอร์ชันที่แสดงอยู่บนหน้าจอเสมอไป

FAQ

เหตุใดโหนด AI Agent จึงไม่ยอมทำงาน

โหนด AI Agent ต้องมีโหนดย่อย chat model และโหนดย่อยเครื่องมืออย่างน้อย 1 รายการ โหนดที่มีโมเดลแต่ไม่มีเครื่องมือจะล้มเหลวก่อนเรียก API ใดๆ ให้เชื่อมต่อเครื่องมือ 1 รายการ แม้จะเป็นเครื่องมือที่ทำงานง่ายมาก แล้วเรียกใช้อีกครั้ง

Agent ตอบคำถาม แต่ไม่เคยเรียกใช้เครื่องมือของฉัน เกิดอะไรขึ้น

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

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

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

หน่วยความจำทำงานในตัวแก้ไข แต่ไม่ทำงานในระบบจริง เกิดอะไรเปลี่ยนแปลง

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