SSD Nodes Learn
คู่มือ Matt Connorโดย Matt Connor · อัปเดตเมื่อ 2026-07-24

วิธีสร้าง AI Agent บน VPS ด้วยตัวเอง

เรียนรู้หลักการทำงานของ AI Agent ตั้งแต่ระบบ Loop การใช้ Tools การจัดการ Memory ไปจนถึงโปรโตคอล MCP เพื่อสร้างระบบที่ทำงานได้จริงบน VPS ของคุณเอง

AI agent คืออะไรกันแน่

AI agent คือลูปที่ทำงานครอบคลุม language model ไว้ เมื่อ model อ่านสถานการณ์แล้วตัดสินใจเลือกการกระทำหนึ่งอย่าง code ของคุณจะดำเนินการตามนั้น จากนั้นผลลัพธ์จะถูกส่งกลับไปยัง model และลูปจะทำงานซ้ำจนกว่างานจะเสร็จสิ้น นี่คือหลักการทั้งหมด ส่วน chatbot ทั่วไปจะตอบเพียงครั้งเดียวแล้วหยุดทำงาน แต่ agent จะทำงานต่อเนื่องโดยมีการดำเนินการจริงเกิดขึ้นระหว่างแต่ละรอบการทำงาน จนกว่าจะบรรลุเป้าหมายที่คุณกำหนดไว้

การดำเนินการ (action) คือส่วนที่สำคัญที่สุด ลำพังเพียง language model สามารถผลิตได้เพียงข้อความเท่านั้น ไม่สามารถอ่านไฟล์, เรียกใช้ API หรือรัน command ได้ agent จะมอบชุดเครื่องมือ (tools) ให้แก่ model และกำหนดวิธีการเรียกใช้เครื่องมือเหล่านั้น เมื่อ model ต้องการค้นหาข้อมูลบนเว็บหรือเขียนไฟล์ model จะไม่ได้ทำงานนั้นด้วยตัวเอง แต่จะส่งคำขอที่มีโครงสร้าง (structured request) ออกมา จากนั้น code ของคุณจะรัน tool นั้น และส่งคำตอบกลับมาเป็นข้อมูลชุดถัดไปที่ model จะต้องอ่าน model ทำหน้าที่ตัดสินใจ ส่วน server ของคุณทำหน้าที่เป็นผู้ลงมือปฏิบัติ

ไม่ใช่ทุกงานที่จำเป็นต้องใช้ agent และการเลือกใช้ agent เป็นค่าเริ่มต้นถือเป็นข้อผิดพลาดที่พบบ่อย หากขั้นตอนต่างๆ ถูกกำหนดไว้ล่วงหน้าแล้ว การใช้ script ธรรมดาจะง่ายกว่า เร็วกว่า และเชื่อถือได้มากกว่า เช่น "ให้ดึงข้อมูลหน้านี้ทุกชั่วโมงแล้วส่งราคามาทาง email" แบบนี้คือ scheduled job ไม่ใช่ agent ควรสร้าง agent เมื่อเส้นทางการทำงานไม่สามารถกำหนดตายตัวได้ล่วงหน้า หรือเมื่อ model จำเป็นต้องพิจารณาสิ่งที่ค้นพบเพื่อตัดสินใจว่าจะทำอะไรต่อไป ค่าใช้จ่ายที่ต้องจ่ายสำหรับ agent คือความไม่แน่นอน ดังนั้นควรใช้เฉพาะเมื่อความยืดหยุ่นนั้นคุ้มค่ากับการใช้งานเท่านั้น

Tools: วิธีที่ agent ดำเนินการ

Tool คือความสามารถใดๆ ที่คุณมอบให้แก่ model โดยต้องมีการอธิบายที่ชัดเจนเพื่อให้ model รู้ว่าควรเรียกใช้เมื่อใด ไม่ว่าจะเป็นการอ่านไฟล์, การรัน shell command, การ query database หรือการส่งข้อความ แต่ละอย่างคือ tool ที่มีชื่อ, คำอธิบายสั้นๆ และรายการ input คุณเป็นผู้กำหนด tools ส่วน model เป็นผู้ตัดสินใจว่าจะเรียกใช้เมื่อใด

กลไกการทำงานจะเหมือนกันในทุกที่ ไม่ว่าคุณจะใช้ model ใดก็ตาม model จะส่งคืน structured request ที่ระบุชื่อ tool และระบุ input ต่างๆ code ของคุณจะตรวจพบคำขอนั้น รัน function ที่ตรงกัน และส่งผลลัพธ์กลับไปในรอบถัดไป model จะอ่านผลลัพธ์แล้วตัดสินใจว่าจะเรียก tool อื่นต่อ หรือจะเขียนคำตอบสุดท้ายออกมา Function calling คือระบบพื้นฐานที่อยู่เบื้องหลัง agent ทุกตัว และลูปที่ขับเคลื่อนมันก็เป็นเพียง code ธรรมดาไม่กี่บรรทัด

นี่คือจุดที่คุณสามารถควบคุมการทำงานได้ model อาจขอรัน command แต่จะไม่มีอะไรถูกรันจนกว่า code ของคุณจะเลือกสั่งรัน ช่องว่างนี้คือจุดที่คุณควรใส่ prompt เพื่อขออนุมัติสำหรับการกระทำที่อันตราย, การจำกัดสิทธิ์การเข้าถึงของ tool และการบันทึก log ทุกอย่างที่ agent ทำ agent จะมีความปลอดภัยเท่ากับ tools ที่คุณมอบให้และการตรวจสอบที่คุณติดตั้งไว้ด้านหน้าเท่านั้น

MCP: มาตรฐานในการเชื่อมต่อ tools

การเขียนการเชื่อมต่อ (integration) ใหม่สำหรับทุกบริการด้วยมือเป็นเรื่องที่เสียเวลามาก Model Context Protocol หรือ MCP คือมาตรฐานเปิดที่เข้ามาแก้ปัญหานี้ แทนที่จะต้องเขียน code สำหรับ tool ใหม่สำหรับไฟล์, database และ issue tracker ของคุณ คุณเพียงแค่ชี้ agent ไปยัง MCP server ที่เปิดใช้งานสิ่งเหล่านั้นเป็น tools อยู่แล้ว agent จะสื่อสารผ่านโปรโตคอลเดียว ส่วน server จะทำหน้าที่สื่อสารกับระบบจริง

ผลลัพธ์ที่ได้คือการนำกลับมาใช้ใหม่ (reuse) MCP server ที่ผู้อื่นเขียนไว้สำหรับบริการที่คุณใช้งานจะสามารถใช้งานกับ agent ของคุณได้ทันทีโดยไม่ต้องเขียน code integration ใหม่ และ server ที่คุณเขียนขึ้นเองก็สามารถใช้งานได้กับ agent ทุกตัวที่รองรับโปรโตคอลนี้ สำหรับการใช้งานบน VPS เรื่องนี้มีความสำคัญมาก เพราะคุณสามารถรัน MCP servers เป็น service ขนาดเล็กแยกต่างหากข้างๆ agent โดยแต่ละตัวมีสิทธิ์เข้าถึงเฉพาะเท่าที่จำเป็นเท่านั้น ฉันได้อธิบายวิธีการติดตั้งไว้ใน running MCP servers on a VPS

Memory and retrieval

Language model ไม่มีหน่วยความจำของตัวเองระหว่างการเรียกใช้งาน ทุกสิ่งที่มันรู้เกี่ยวกับงานปัจจุบันจะต้องถูกส่งให้มันในทุกรอบการทำงาน สำหรับงานระยะสั้นวิธีนี้ถือว่าเพียงพอเพราะบทสนทนาทั้งหมดสามารถบรรจุอยู่ใน request เดียวได้ แต่สำหรับงานที่ยาวกว่านั้นคุณต้องจัดการหน่วยความจำด้วยตัวเอง ซึ่งมี 2 รูปแบบที่ควรทราบ

รูปแบบแรกคือ scratchpad คุณมอบไฟล์ที่ agent สามารถอ่านและเขียนได้ และสั่งให้มันบันทึกสิ่งที่เรียนรู้ในขณะที่ทำงาน ในรอบถัดไปหรือ session ถัดไป มันจะอ่านไฟล์นั้นกลับมาและทำงานต่อจากจุดเดิม นี่คือหน่วยความจำในรูปแบบเอกสารธรรมดา และมันทำงานได้เพราะ agent ปฏิบัติต่อไฟล์นั้นเหมือนเป็น tool ตัวหนึ่ง

รูปแบบที่สองคือ retrieval เมื่อ agent ต้องการความรู้จากเอกสารจำนวนมากที่ไม่สามารถบรรจุลงใน request เดียวได้ คุณต้องเก็บเอกสารเหล่านั้นไว้ในรูปแบบที่ค้นหาได้ และดึงเฉพาะส่วนที่เกี่ยวข้องเข้ามาในขอบเขตการมองเห็นของ model เมื่อจำเป็น รูปแบบนี้เรียกว่า retrieval-augmented generation หรือ RAG agent จะถามคำถาม code ของคุณจะค้นหาข้อความที่ตรงกันเพียงไม่กี่ส่วน และส่งเฉพาะส่วนนั้นไปให้ model ข้อมูลจะถูกเก็บไว้บน server ของคุณ ดังนั้นเอกสารส่วนตัวของคุณจะไม่หลุดออกไปจากเครื่อง

Many agents, one coordinator

Agent ตัวเดียวที่มีหลาย tools สามารถจัดการงานส่วนใหญ่ได้ แต่เมื่อเป็นงานขนาดใหญ่หรือต้องแบ่งงานออกเป็นส่วนๆ การใช้โครงสร้างแบบอื่นจะช่วยได้ดีกว่า นั่นคือการใช้ coordinator agent เพื่อมอบหมายงานให้กับ sub-agents ที่มีความเชี่ยวชาญเฉพาะด้าน coordinator จะแบ่งเป้าหมายออกเป็นส่วนย่อยๆ ส่งแต่ละส่วนให้ sub-agent ที่สร้างมาเพื่อทำงานประเภทนั้น และนำผลลัพธ์มารวมกัน

ข้อดีคือความเฉพาะเจาะจง sub-agent ที่มีงานแคบๆ และชุด tool ขนาดเล็กจะตัดสินใจได้ดีกว่า agent แบบ generalist ที่ต้องจัดการทุกอย่าง และชิ้นงานที่แยกจากกันสามารถทำงานไปพร้อมกันได้ได้ ข้อเสียคือต้องมีการประสานงาน (coordination) ซึ่งเป็นภาระจริง ดังนั้นควรใช้ agent เพียงตัวเดียวจนกว่างานจะต้องการมากกว่านั้น เริ่มต้นจากสิ่งที่เรียบง่าย และเพิ่ม agent ก็ต่อเมื่อ agent ตัวเดียวเริ่มทำงานไม่ไหวอย่างชัดเจน

Self-hosted or hosted: เลือกโมเดลใดให้ agent ของคุณ

Model คือส่วนเดียวของ agent ที่คุณไม่จำเป็นต้องรันเอง และการตัดสินใจว่าจะให้มันอยู่ที่ไหนคือการตัดสินใจที่สำคัญที่สุด การใช้ hosted model ผ่าน API จะให้ความสามารถในการใช้เหตุผลที่แข็งแกร่งที่สุดโดยที่คุณไม่ต้องดูแลระบบ เพียงแค่ส่งข้อความและรับข้อความกลับมา ส่วน self-hosted model จะรันบน server ของคุณเอง ซึ่งช่วยให้ทุก request เป็นส่วนตัว มีค่าใช้จ่ายคงที่แทนที่จะเป็นค่าธรรมเนียมต่อ token และไม่ต้องพึ่งพาความเสถียรของผู้อื่น การแลกเปลี่ยนคือความสามารถและความพยายาม โมเดลแบบ hosted ที่ดีที่สุดมักจะล้ำหน้ากว่าโมเดลที่คุณสามารถรันเองได้ และการรันเองหมายถึงคุณต้องจัดสรรหน่วยความจำให้เพียงพอต่อขนาดของโมเดล

ประเด็นสุดท้ายคือข้อจำกัดทางปฏิบัติ โมเดลต้องมีขนาดพอดีกับหน่วยความจำของ server และหากคุณใช้ GPU ต้องมีขนาดพอดีกับ video memory ด้วย โมเดลที่มีขนาดใหญ่เกินไปสำหรับ hardware จะไม่สามารถโหลดได้ ก่อนที่คุณจะวางแผนสร้าง self-hosted agent ให้ตรวจสอบว่าโมเดลที่คุณต้องการสามารถรันบนเครื่องที่คุณมีได้หรือไม่:

ToolWill your model fit your server?

หากตัวเลขไม่สอดคล้องกัน คุณมี 3 ทางเลือก: เลือกโมเดลที่เล็กลง, ใช้การ quantization ที่เข้มข้นขึ้นเพื่อลดขนาดโมเดล หรือใช้ hosted API สำหรับการใช้เหตุผลและเก็บไว้เพียง tools และข้อมูลของคุณไว้บน server เท่านั้น self-hosted agents จำนวนมากเริ่มต้นด้วยการใช้ local model ผ่าน Ollama on a VPS และเปลี่ยนไปใช้ hosted API สำหรับขั้นตอนที่ยากที่สุด

The server is the dangerous part

Agent ที่สามารถรัน shell commands และเขียนไฟล์ได้นั้นมีพลังมาก และนั่นคือเหตุผลที่มันอันตราย การตัดสินใจของ model นั้นดีแต่ไม่สมบูรณ์แบบ คำสั่งที่ผิดพลาด bug หรือ input ที่ประสงค์ร้ายสามารถเปลี่ยน agent ที่มีประโยชน์ให้กลายเป็นตัวที่ลบข้อมูลผิดพลาดหรือทำข้อมูลลับรั่วไหล งานด้านความปลอดภัยไม่ใช่ทางเลือก และบน server มันคือส่วนที่สำคัญที่สุด

นิสัยเพียงไม่กี่อย่างสามารถช่วยป้องกันได้มาก: รัน agent ในฐานะ unprivileged user ที่แยกต่างหาก ไม่ใช่ root เพื่อจำกัดขอบเขตความเสียหายหากเกิดข้อผิดพลาด (ดูรายละเอียดใน running services as an unprivileged user) เก็บความลับ เช่น API keys ไว้ภายนอก code และให้เฉพาะ user นั้นเท่านั้นที่อ่านได้ และทำ sandbox สำหรับ tools ที่เข้าถึงระบบ เพื่อให้ agent เข้าถึงได้เฉพาะสิ่งที่จำเป็นจริงๆ สำหรับตัวอย่างการทำ hardening สำหรับ self-hosted agent ของจริง ดูได้ที่ running OpenClaw safely on a VPS หากคุณต้องการใช้ hosted model เพื่อความฉลาด คู่มือประกอบเรื่อง building an agent with Claude on a VPS จะใช้แนวคิดเดียวกันแต่ใช้โมเดลเฉพาะเจาะจงแทน

สำหรับตัวอย่างการใช้งานจริง building an OpenClaw-style personal agent ได้ประยุกต์ใช้ส่วนประกอบเหล่านี้ และหากคุณต้องการรันแบบสำเร็จรูป ให้เริ่มจาก self-hosting Hermes Agent on a VPS หรือ running Agent Zero on your own server และ the best self-hosted AI agents in 2026 จะเปรียบเทียบทุกตัวเลือกสำเร็จรูปที่เราครอบคลุมไว้แบบเคียงข้างกัน

FAQ

What is the difference between an AI agent and a chatbot?

Chatbot จะตอบข้อความแล้วหยุดทำงาน ส่วน agent จะทำงานเป็นลูป: model ตัดสินใจเลือกการกระทำ, code ของคุณดำเนินการตามนั้น, ผลลัพธ์ถูกส่งกลับไปยัง model และทำซ้ำจนกว่างานจะเสร็จสิ้น ความแตกต่างคือ agent มีการดำเนินการจริงระหว่างแต่ละรอบการทำงาน เช่น การเรียกใช้ tool เพื่ออ่านไฟล์, รัน command หรือ query บริการต่างๆ แทนที่จะผลิตเพียงข้อความเท่านั้น

Do I need a GPU to run an AI agent on a VPS?

จำเป็นเฉพาะในกรณีที่คุณรันโมเดลแบบ self-host เท่านั้น ลูปการทำงานของ agent, tools และหน่วยความจำคือ code ธรรมดาที่รันบน VPS ปกติได้โดยไม่ต้องมี GPU ส่วน GPU จะมีความสำคัญเมื่อคุณต้องการรัน language model บน hardware ของคุณเอง เพราะโมเดลต้องมีขนาดพอดีกับหน่วยความจำ หากคุณใช้ hosted model ผ่าน API การคำนวณหนักๆ จะเกิดขึ้นที่อื่น และ VPS ทั่วไปก็เพียงพอแล้ว

What is MCP and do I need it to build an agent?

MCP หรือ Model Context Protocol คือมาตรฐานเปิดสำหรับการเชื่อมต่อ agent เข้ากับ tools และแหล่งข้อมูล คุณไม่จำเป็นต้องใช้มันอย่างเคร่งครัดเพราะคุณสามารถเขียน tool แต่ละตัวด้วยมือได้ แต่ MCP ช่วยประหยัดเวลาโดยการให้คุณนำ server ที่มีอยู่แล้วสำหรับบริการทั่วไปมาใช้ใหม่ได้ และช่วยให้คุณเปิดเผยระบบของคุณเพียงครั้งเดียวเพื่อให้ agent ใดๆ ใช้งานได้ มันคือความสะดวกสบายที่จะคุ้มค่าเมื่อจำนวนการเชื่อมต่อเพิ่มมากขึ้น

Is it safe to give an AI agent access to my server?

สามารถปลอดภัยได้หากคุณควบคุมมัน Agent ที่รันคำสั่งได้จะปลอดภัยเท่ากับ account ที่มันรันอยู่และ tools ที่คุณอนุญาตเท่านั้น ให้รันมันในฐานะ unprivileged user, เก็บความลับไว้ให้พ้นจากการเข้าถึง, ทำ sandbox สำหรับ tools ที่เข้าถึง filesystem และกำหนดให้ต้องมีการอนุมัติสำหรับการกระทำที่ยากต่อการย้อนกลับ ให้ปฏิบัติกับ agent เสมือนเป็น code ที่ไม่น่าเชื่อถือแต่มีความฉลาด และมอบให้เฉพาะสิ่งที่จำเป็นต่องานเท่านั้น