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

ความหมายของ n8n AI agent และความแตกต่างจาก chain

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

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

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

ตรวจสอบ version ของคุณก่อนเชื่อถือชื่อ field ใด ๆ ในที่นี้ เนื่องจาก n8n มีการเปลี่ยนแปลง AI node อยู่บ่อยครั้ง

docker compose exec n8n n8n --version

Version 1.82.0 ยกเลิกการตั้งค่า agent-type และให้ใช้ Tools Agent แทน ส่วน legacy v1 node ยังคงมีการตั้งค่านี้ โดยเอกสารของ n8n ระบุว่าจะนำ node version ดังกล่าวออกใน n8n 3.0

ขั้นตอนที่ 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) จาก Claude Console ที่ platform.claude.com โดยไปที่ Settings แล้วเลือก API keys คีย์จะแสดงให้เห็นเพียงครั้งเดียวเท่านั้น Console จะให้คุณเลือกวันหมดอายุเมื่อสร้างคีย์ ซึ่งเอเจนต์ที่ทำงานโดยอัตโนมัติจะหยุดทำงานในวันที่คีย์หมดอายุ ดังนั้นควรบันทึกวันที่ดังกล่าวไว้ในที่ที่คุณสามารถมองเห็นได้ สำหรับเอเจนต์ที่ทำงานโดยอัตโนมัติ ให้ใช้คีย์ของ service account ที่กำหนดขอบเขตไว้ใน workspace เพื่อให้คำขอไม่จำเป็นต้องใช้ header ของ workspace แยกต่างหาก

การใช้งาน API จะคิดค่าใช้จ่ายตามจำนวน token โดยวิธีการชำระเงินขึ้นอยู่กับแผน Claude ของคุณ ณ วันที่ 31 ตุลาคม 2026 แผน Max, Ultra และ Team จะมีเครดิต API รายเดือนรวมอยู่ด้วย ได้แก่ 100 ดอลลาร์สำหรับแผน Max, 200 ดอลลาร์สำหรับแผน Ultra และสูงสุด 500 ดอลลาร์แบบรวมกลุ่มสำหรับแผน Team คุณสามารถรับเครดิตเหล่านี้ได้โดยการเชื่อมโยง Console organization เข้ากับแผนที่ Settings > Billing สำหรับแผน Max หรือ Ultra หรือที่ Organization settings > Billing สำหรับแผน Team โดยไม่จำเป็นต้องเพิ่มวิธีการชำระเงินใน Console ผู้สมัครสมาชิกใหม่สามารถรับเครดิตได้หลังจากใช้งานแผนไปแล้ว 7 วัน และเครดิตที่ไม่ได้ใช้จะหมดอายุเมื่อสิ้นสุดรอบบิลแต่ละรอบ หรือหมดอายุรายเดือนสำหรับแผนรายปี เมื่อเครดิตที่รวมอยู่ในแผนหมดลง คำขอจะถูกหักจากเครดิตที่ซื้อเพิ่ม ระบบ auto-reload สามารถซื้อเครดิตเพิ่มได้ และองค์กรที่ใช้วิธีการออกใบแจ้งหนี้จะถูกเรียกเก็บเงินสำหรับการใช้งานส่วนเกิน คำขอจะหยุดทำงานเมื่อองค์กรแบบชำระเงินล่วงหน้าไม่มีเครดิตเหลืออยู่ การใช้งาน API จะไม่ถูกเรียกเก็บเงินรวมกับแผน Claude ของคุณ แผน Free, Pro และ Enterprise ไม่มีเครดิต API รายเดือน ดังนั้นแผนเหล่านี้จะมีการเรียกเก็บเงินค่า API แยกต่างหากจากการสมัครสมาชิก

ให้เลือกโมเดลตามความเหมาะสมของเอเจนต์แต่ละตัว ไม่ใช่ตามบริษัท เอเจนต์ที่มีเครื่องมือเดียวซึ่งทำหน้าที่ค้นหาข้อมูลและรายงานผลสามารถทำงานได้ดีบน Haiku โดยเวอร์ชันปัจจุบันคือ Haiku 5.5 มีราคาอยู่ที่ 0.10 ดอลลาร์ต่อล้าน input token และ 0.50 ดอลลาร์ต่อล้าน output token ณ วันที่ 12 ตุลาคม 2026 และจะเพิ่มขึ้นเป็น 0.50 ดอลลาร์และ 2.50 ดอลลาร์สำหรับคำขอใดๆ ที่มี prompt เกิน 100,000 token ซึ่งหน้าต่างหน่วยความจำที่ยาวและผลลัพธ์จากเครื่องมือขนาดใหญ่อาจทำให้คุณใช้งานถึงเกณฑ์นี้ได้ เมื่อเอเจนต์มีเครื่องมือหลายอย่างและต้องวางแผนการทำงานข้ามเครื่องมือเหล่านั้น ให้เปลี่ยนไปใช้ Sonnet ความล้มเหลวที่คุณควรหลีกเลี่ยงคือการใช้โมเดลราคาถูกที่เรียกใช้เครื่องมือผิดพลาดถึงสี่ครั้ง ซึ่งมีค่าใช้จ่ายสูงกว่าการใช้โมเดลราคาแพงที่เรียกใช้เครื่องมือที่ถูกต้องเพียงครั้งเดียว

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

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

ขั้นตอนที่ 3: prompt ที่ agent ได้รับ

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

• Connected Chat Trigger Node รอรับฟิลด์ขาเข้าชื่อ chatInput ตัวเลือกนี้เหมาะสำหรับการใช้งานต่อจาก Chat Trigger
• Define below จะแสดงฟิลด์ Prompt (User Message) ให้ป้อนข้อความคงที่หรือ expression ตัวเลือกนี้เหมาะสำหรับการใช้งานต่อจาก Schedule Trigger หรือโหนด Webhook

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

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 ใช้เครื่องมือ 1 รายการ

เอกสารของ n8n ระบุว่าต้องเชื่อมต่อ tool sub-node อย่างน้อย 1 รายการเข้ากับ AI Agent node แม้โค้ดของ node ในปัจจุบัน (version 3.1) จะปฏิเสธการทำงานเมื่อไม่มี chat model เท่านั้นก็ตาม ควรเริ่มด้วยเครื่องมือ 1 รายการก่อน เพราะเครื่องมือที่ทำงานได้ 1 รายการให้ข้อมูลมากกว่าเครื่องมือ 4 รายการที่ตั้งค่าไม่เสร็จ และ agent ที่ไม่มีเครื่องมือก็เป็นเพียง chain ที่มีค่าใช้จ่ายสูงกว่า

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

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

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

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

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

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

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

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

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

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

ขั้นตอนที่ 5: memory และสาเหตุที่ agent ลืม

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

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

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

Simple Memory ใช้งานไม่ได้ใน workflow production ที่กำลังทำงานอยู่เมื่อ n8n ทำงานใน queue mode เพราะจะเก็บประวัติไว้ใน singleton Map ที่อยู่ภายใน process โดยใช้ workflow และ session IDs เป็น key และ worker แต่ละตัวจะไม่ใช้ memory ร่วมกัน ใน instance ที่ใช้ queue mode ให้ใช้ Postgres Chat Memory sub-node แทน และกำหนดให้เชื่อมต่อกับ database ที่ทั้ง process หลักและ 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 ก่อนตอบเสมอ) มีความสำคัญอย่างยิ่ง หากไม่มีคำสั่งนี้ โมเดลที่คิดว่าตนเองทราบคำตอบอยู่แล้วจะข้ามการใช้เครื่องมือและตอบจากหน่วยความจำ ซึ่งอาจให้ข้อมูลที่ผิดพลาดอย่างมั่นใจทันทีที่โครงสร้างพื้นฐานของคุณมีการเปลี่ยนแปลง

เหตุใด agent จึงวนลูป และอะไรช่วยหยุดการวนลูป

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

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

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

ดูการทำงานของ run จาก shell

docker compose logs -f n8n

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

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

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

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

FAQ

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

ให้ตรวจสอบ connector ก่อน โหนด AI Agent ต้องมีโหนดย่อย chat model หากไม่มี โหนดจะหยุดทำงานพร้อมข้อความ "Please connect a model to the Chat Model input" ก่อนที่จะเรียก API ใด ๆ เอกสารของ n8n ยังระบุว่าต้องมีโหนดย่อย tool อย่างน้อย 1 รายการด้วย ดังนั้นหากเชื่อมต่อ model แล้วโหนดยังคงไม่ยอมทำงาน ให้เพิ่ม tool 1 รายการ แม้จะเป็น tool แบบง่าย ๆ แล้วลองเรียกใช้อีกครั้ง

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

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

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

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

Memory ทำงานใน editor แต่ไม่ทำงานใน production เกิดอะไรขึ้น

ให้ตรวจสอบว่า instance ทำงานใน queue mode หรือไม่ Simple Memory จัดเก็บประวัติไว้ใน singleton Map ที่อยู่ภายใน process โดยใช้ workflow และ session IDs เป็น key และ worker process แต่ละตัวจะไม่ใช้ข้อมูลร่วมกัน ให้เปลี่ยนไปใช้โหนดย่อย Postgres Chat Memory ซึ่งจัดเก็บประวัติไว้ใน database ที่ worker ทุกตัวใช้ร่วมกัน