Builder track ความรู้สายเทคที่ทำให้ใช้ AI สร้างของจริงได้

บทนี้ควรมีป้ายหน้าประตูชัด ๆ ว่า สำหรับตอนเริ่มลงมือสร้างจริง

ถ้าคุณใช้ AI เพื่อเขียน email สรุปประชุม แปลเอกสาร หรือช่วยคิดแผนงาน คุณยังไม่จำเป็นต้องรู้คำพวกนี้ทั้งหมด แต่ถ้าคุณเริ่มอยากให้ AI ทำงานกับเว็บจริง รันงานทิ้งไว้ เปิดหลายงานพร้อมกัน ต่อ GitHub สร้าง automation หรือทำระบบที่มีคนอื่นใช้ด้วย คำเหล่านี้จะเริ่มเดินเข้ามาหาคุณเอง

ไม่ต้องกลัวว่าบทนี้จะบังคับให้คุณเป็น programmer เป้าหมายคือให้คุณรู้ว่าเครื่องมือแต่ละชิ้นอยู่ตรงไหนในแผนที่ จะได้ไม่หลงซื้อของใหญ่เกินงาน หรือทิ้งของสำคัญเพราะชื่อมันฟังดูเทคนิค

บทนี้ไม่ใช่บทเริ่มต้น แต่มันคือทางลัดของคนเริ่มจริงจัง

ในบท Connectors เราแยกแล้วว่า prompt, skill, CLI, MCP และ API เชื่อม AI กับโลกจริงคนละระดับ บทนี้ต่อจากตรงนั้น แต่ขยับจาก "เชื่อมอะไร" ไปเป็น "ถ้าจะสร้างของจริง คุณต้องรู้เครื่องมือรอบ ๆ อะไรบ้าง"

ลองนึกภาพคุณไม่ได้แค่สั่ง AI ว่า "ช่วยเขียนหน้าเว็บ" แล้วจบ คุณอยากให้มันเปิดเว็บที่สร้างขึ้นมาเอง กดปุ่ม เช็กว่าฟอร์มใช้ได้ไหม เก็บงานเป็นเวอร์ชัน ส่งให้คนอื่น review รันซ้ำเมื่อมีงานใหม่ และทำทั้งหมดนี้โดยไม่ทำเครื่องคุณเละ

นั่นคือโลกของ builder track

คำว่า builder ในที่นี้ไม่ได้แปลว่า developer เต็มตัวเสมอไป แต่แปลว่าคุณกำลังใช้ AI เพื่อสร้าง workflow, tool, website, report pipeline, dashboard, bot หรือระบบเล็ก ๆ ที่ต้องทำงานซ้ำได้ ไม่ใช่แค่ตอบข้อความครั้งเดียว

💡 ใจความสำคัญ: ยิ่งคุณอยากให้ AI ทำงานกับของจริงมากขึ้น คุณยิ่งต้องรู้จัก "สภาพแวดล้อม" รอบ AI ไม่ใช่แค่ model ที่ตอบเก่ง

ทำไม browser automation ถึงสำคัญ

งานจำนวนมากในชีวิตจริงเกิดใน browser ไม่ใช่ในแชท

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

วิธีที่ง่ายที่สุดสำหรับผู้ใช้ทั่วไปคือใช้ browser extension เช่น Claude in Chrome ตามเอกสาร Claude Code มันต่อ Claude Code เข้ากับ Chrome หรือ Edge เพื่อให้ทดสอบเว็บ debug ดู console log กรอก form และดึงข้อมูลจากหน้าเว็บได้ในหน้าต่าง browser ที่มองเห็นจริง และยังใช้ login state ของ browser ที่คุณ sign in อยู่

นี่สะดวกมากสำหรับงานที่ต้องแตะเว็บจริงในเครื่องคุณ เช่น "เปิดหน้าเว็บที่เพิ่งสร้าง กดปุ่มสมัครสมาชิก แล้วบอกว่าติดตรงไหน"

แต่เมื่อเริ่มต้องทำซ้ำบ่อย ทดสอบหลายหน้า หรืออยากให้ workflow เสถียรขึ้น เครื่องมืออีกตัวจะสำคัญมาก นั่นคือ Playwright

Playwright คือ browser ที่สั่งได้แบบเป็นระบบ

เวลาให้คนกดเว็บ คนจะดูหน้าจอแล้วตัดสินใจเองว่า "ปุ่มนี้โหลดเสร็จหรือยัง" "กล่องนี้กดได้หรือยัง" "ข้อความนี้ขึ้นหรือยัง" แต่ AI ที่ควบคุม browser ผ่านภาพอย่างเดียวอาจพลาดง่าย เพราะหน้าเว็บเปลี่ยนเร็ว ปุ่มขยับ animation ยังไม่จบ หรือข้อความโหลดช้ากว่าที่คิด

Playwright คือเครื่องมือสำหรับควบคุม browser ด้วย code อย่างเป็นระบบ ใช้เปิดหน้าเว็บ กดปุ่ม กรอกข้อมูล รอให้ element พร้อม ตรวจข้อความ ถ่าย screenshot และรันแบบมองเห็นหน้าต่างหรือแบบ headless คือไม่มีหน้าต่างให้เห็นก็ได้

จุดที่ทำให้ Playwright เหมาะกับงานสร้างของจริงคือมันไม่ได้แค่ "เดาว่าปุ่มอยู่ตรงไหน" เอกสาร Playwright ระบุว่าก่อนจะ click มันตรวจหลายอย่าง เช่น element ต้องมองเห็น ต้องนิ่ง ต้องรับ event ได้ และต้อง enabled ก่อน ถ้ายังไม่พร้อมมันจะรอจนกว่าจะพร้อมหรือหมดเวลา

พูดภาษาคนคือ Playwright มีนิสัยเหมือนคนตรวจงานเว็บที่ใจเย็นกว่า มันไม่รีบกดตอนปุ่มยังโหลดไม่เสร็จ และถ้าสิ่งที่คาดหวังยังไม่เกิด มันรอเช็กซ้ำได้

นี่คือเหตุผลที่งาน browser automation จริงจังมักใช้ Playwright มากกว่าให้ AI ขยับเมาส์แบบเห็นภาพอย่างเดียว

Chrome extension หรือ computer-use เหมาะกับการให้ AI แตะ browser แบบเร็ว ๆ เห็นจริง ใช้ session จริง และเข้าเว็บที่คุณ login ไว้ ส่วน Playwright เหมาะกับงานที่ต้องทำซ้ำ ตรวจซ้ำ รันใน CI หรือแปลงเป็น test ที่คนอื่นใช้ต่อได้

ลองทำดู: แยกงาน browser 4 แบบ

ลองดูงานเหล่านี้ แล้วเลือกว่าควรเริ่มจาก Chrome extension หรือ Playwright

1. เปิดเว็บบริษัทที่ login อยู่แล้ว แล้วให้ AI ดูว่าปุ่ม export อยู่ตรงไหน
2. ทดสอบทุกเช้าว่าหน้า checkout ยังซื้อของได้จริงหรือไม่
3. ให้ AI อ่าน console error จากหน้าเว็บที่คุณกำลัง debug
4. สร้าง test ที่รันใน GitHub Actions ทุกครั้งก่อน deploy

คำตอบที่สมเหตุสมผลคือ 1 และ 3 เริ่มจาก Chrome extension ได้ง่าย 2 และ 4 ควรไปทาง Playwright เพราะต้องทำซ้ำและต้องเชื่อถือได้

printing-press คือแนวคิดว่า API ควรกลายเป็น CLI ที่ AI ใช้ง่าย

ในบท Connectors เราคุยว่า API คือทางให้โปรแกรมเรียก model หรือเรียกระบบอื่น แต่มีปัญหาหนึ่งที่คนเริ่มสร้าง agent จะเจอเร็วมาก: API ดิบมักไม่เป็นมิตรกับ AI

ถ้าให้ AI อ่าน docs ยาว ๆ แล้วค่อยประกอบ HTTP request เองทุกครั้ง มันกิน token เยอะ พลาดง่าย และเสียเวลา เหมือนให้พนักงานเปิดคู่มือหนา 300 หน้าใหม่ทุกครั้งก่อนโทรหาลูกค้า

printing-press เป็นตัวอย่างของแนวคิดอีกแบบ: สร้าง CLI ที่ออกแบบมาให้ AI ใช้ API นั้นได้ง่ายขึ้น จากข้อมูลอย่าง API spec, เว็บไซต์ หรือโปรเจกต์ที่มีอยู่ แล้วได้เครื่องมือ command line, skill และบางกรณีรวมถึง MCP server

จุดสำคัญไม่ใช่ยึดติดกับชื่อ printing-press แต่คือหลักคิดว่า "ถ้า agent ต้องใช้ระบบเดิมซ้ำ ๆ ควรมีเครื่องมือสั้น ชัด และเรียกซ้ำได้" แทนที่จะให้มันเดาทางจาก API ดิบทุกครั้ง

ตัวอย่างสมมติ ถ้าคุณมี API ภายในบริษัทสำหรับดึงยอดขาย การให้ AI เรียก sales-api/v1/reports?date=... เองทุกครั้งอาจยุ่ง แต่ถ้ามี CLI เช่น sales today --region bangkok --format summary AI จะเข้าใจง่ายกว่า ใช้ token น้อยกว่า และตรวจ output ได้ง่ายกว่า

ตรงนี้โยงกลับไปบท Token optimization ด้วย เพราะเครื่องมือที่ออกแบบดีไม่ได้ช่วยแค่ทำงานได้ มันช่วยลดข้อความที่ต้องส่งไปมาใน session

tmux คือห้องทำงานที่ไม่หายเมื่อคุณปิดหน้าต่าง

พอใช้ agent จริงจัง คุณจะเจอปัญหาธรรมดามาก: งานใช้เวลานาน

บางงานรัน test 20 นาที บางงานให้ AI แก้หลายไฟล์ บางงานต้องเปิด server ค้างไว้ แล้วเปิดอีก session มาตรวจเว็บ ถ้าทุกอย่างผูกกับ terminal หน้าต่างเดียว ปิดผิดหน้าต่างทีเดียวงานก็หาย

tmux คือเครื่องมือที่ทำให้ terminal session อยู่ต่อได้ แม้คุณปิดหน้าต่าง terminal ไปแล้ว ภาพง่าย ๆ คือมันเหมือนห้องทำงานที่อยู่หลังฉาก คุณเดินออกจากห้องได้ กลับมาใหม่ได้ และงานในห้องยังอยู่

คนใช้ agent จึงสนใจ tmux เพราะมันช่วย 3 เรื่อง

• รันทิ้งไว้: ให้ session ทำงานต่อระหว่างคุณไปทำอย่างอื่น
• เปิดหลายงาน: แยกหน้าต่างย่อยสำหรับ server, test, agent, log
• กลับมาเก็บงาน: reconnect แล้วดูว่าเกิดอะไรขึ้นต่อ

Claude Code docs มีหมายเหตุเฉพาะสำหรับ tmux ด้วย เช่นเมื่อรัน Claude Code ใน tmux บางอย่างอย่าง Shift+Enter, notification และ progress bar อาจต้องตั้งค่า terminal เพิ่ม แปลว่า tmux ไม่ใช่ของแปลกนอกระบบ มันเป็นเครื่องมือจริงที่คนใช้กับ agent จนต้องมีเอกสารรองรับ

💡 ใจความสำคัญ: tmux ไม่ได้ทำให้ AI ฉลาดขึ้น แต่มันทำให้ "งานที่ AI กำลังทำ" ไม่เปราะบางเท่าหน้าต่าง terminal เดียว

GitHub คือสมุดบัญชีของงานสร้าง ไม่ใช่แค่เว็บของ programmer

ถ้าคุณเริ่มสร้างไฟล์ สร้าง skill สร้างเว็บ หรือสร้าง automation กับ AI ในที่สุดคุณจะต้องเจอ GitHub

หลายคนคิดว่า GitHub คือที่เก็บ code ของ programmer เท่านั้น จริง ๆ แล้วมันคือระบบเก็บประวัติ แชร์งาน และทำงานร่วมกัน เหมือนสมุดบัญชีที่จดว่าใครแก้อะไร เมื่อไหร่ แก้จากอะไรเป็นอะไร และย้อนกลับได้ถ้าพัง

สำหรับคนใช้ AI จริงจัง GitHub สำคัญเพราะ AI แก้งานเร็วมาก เร็วจนคุณตามไม่ทันถ้าไม่มีประวัติ

ถ้า AI แก้ไฟล์ 20 ไฟล์แล้วเว็บพัง คุณต้องรู้ว่ามันเปลี่ยนอะไร ถ้าอยากทดลอง 3 วิธีพร้อมกัน คุณต้องแยกทางทดลอง ถ้าอยากให้คนอื่น review งาน คุณต้องส่ง pull request ถ้าอยากให้ automation รันเมื่อมีการเปลี่ยนแปลง คุณต้องมีที่ให้ event เกิด

GitHub จึงไม่ใช่แค่ที่วาง code แต่มันเป็นบ้านกลางของ workflow แบบ builder

สำหรับคนไม่สายเทค จุดเริ่มต้นที่ควรรู้มีแค่ไม่กี่คำ

• repo คือโฟลเดอร์งานที่มีประวัติ
• commit คือจุดบันทึก
• branch คือทางทดลองอีกเส้นหนึ่ง
• pull request คือคำขอให้คนอื่นตรวจและรวมงาน
• issue คือบัตรงานหรือปัญหาที่ต้องทำ

รู้แค่นี้ก่อนก็พอ ความลึกที่เหลือค่อยเรียนจากงานจริง

worktree คือพื้นที่ทดลองหลายอันที่ไม่ชนกัน

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

worktree คือการแยกพื้นที่ทำงานหลายอันจาก repo เดียวกัน แต่ละพื้นที่มีไฟล์ของตัวเอง branch ของตัวเอง และแก้พร้อมกันได้โดยไม่เหยียบกัน

Claude Code docs อธิบายว่า worktree ช่วย isolate parallel sessions เพื่อให้การแก้ใน session หนึ่งไม่แตะไฟล์ในอีก session หนึ่ง และ Claude Code มี flag --worktree สำหรับเริ่ม session ในพื้นที่แยก รวมถึง desktop app ที่สร้าง worktree สำหรับ session ใหม่โดยอัตโนมัติ

เปรียบเทียบง่าย ๆ ถ้า repo หลักคือครัวกลาง worktree คือเคาน์เตอร์ทดลองหลายโต๊ะ โต๊ะหนึ่งทำเมนู A โต๊ะหนึ่งทำเมนู B ของไม่ปนกัน จนกว่าคุณตัดสินใจว่าจะเอาสูตรไหนกลับเข้าครัวกลาง

จุดที่เปรียบเทียบนี้ใช้ไม่ได้คือ worktree ไม่ได้ copy ทุกอย่างแบบโฟลเดอร์ธรรมดา มันยังแชร์ประวัติ git เดียวกันอยู่ นั่นคือเหตุผลที่มันเบากว่าและเหมาะกับงานขนาน

ลองทำดู: เมื่อไหร่ควรแยก worktree

ลองตอบจากสถานการณ์นี้

คุณให้ AI ลองปรับหน้า pricing 3 แบบ:
A: แบบเรียบง่าย
B: แบบมี comparison table
C: แบบเน้น enterprise

แต่ทุกแบบแก้ไฟล์เดียวกันหลายไฟล์

ถ้าทำในโฟลเดอร์เดียว คุณจะได้ไฟล์ปนกันและตัดสินใจยาก ถ้าทำใน worktree 3 อัน คุณให้แต่ละทางทดลองอยู่คนละพื้นที่ แล้วค่อยเลือกว่าทางไหนจะเข้าต่อ

headless mode คือให้ AI ทำงานจาก script ไม่ต้องนั่งเฝ้าแชท

ตอนคุณคุยกับ Claude Code แบบ interactive คุณพิมพ์ มันตอบ คุณอนุมัติ tool คุณคุยต่อ นี่เหมาะกับงานที่ต้องคิดร่วมกัน

แต่ automation จำนวนมากไม่ควรมีคนนั่งคุยทุกครั้ง เช่นสรุป log ทุกคืน สแกน issue ใหม่ทุกเช้า ตรวจไฟล์ที่เพิ่งเปลี่ยน หรือสร้างรายงานจาก input ที่มีรูปแบบซ้ำ

ตรงนี้คือพื้นที่ของ โหมด non-interactive (หลายคนเรียกติดปากว่า headless mode ส่วนเอกสารทางการปัจจุบันใช้ชื่อหัวข้อว่า "Run Claude Code programmatically") คือการรันแบบไม่ต้องมีหน้าจอแชท interactive

Claude Code docs ระบุว่าสามารถใช้ -p หรือ --print เพื่อรันแบบ non-interactive ได้ และอ่านข้อมูลจาก stdin เหมือนเครื่องมือ command line ทั่วไป เช่น pipe log เข้าไปให้สรุป หรือกำหนด output format เป็น JSON เพื่อให้ระบบอื่นอ่านต่อ

สำหรับคนไม่สายเทค สิ่งที่ต้องเข้าใจไม่ใช่วิธีเขียน script แต่คือความต่างของ mindset

• interactive: เหมาะกับงานที่คุณคิดร่วมกับ AI
• headless: เหมาะกับงานที่มี input ชัด output ชัด และอยากให้รันซ้ำเอง

นี่คือเครื่องยนต์เบื้องหลัง automation ใน Section 4 หลายแบบ

dynamic workflow คือให้หลายชิ้นทำงานประสานกัน

พองานเริ่มใหญ่ขึ้น คุณไม่ได้สั่ง AI แค่งานเดียวแล้วจบ คุณอาจต้องให้ตัวหนึ่งอ่าน requirement ตัวหนึ่งแก้ code ตัวหนึ่งเขียน test ตัวหนึ่ง review ความเสี่ยง แล้วตัวสุดท้ายรวมผลเป็นแผนแก้

นี่คือแนวคิดของ dynamic workflow แบบภาษาคนคือ workflow ที่ไม่ได้เป็นเส้นตรงตายตัวเสมอไป แต่มีการแบ่งงาน ส่งต่อผลลัพธ์ ตรวจซ้ำ และเลือกทางต่อจากสิ่งที่เพิ่งเกิดขึ้น

Claude Code ecosystem มีหลายชิ้นที่รองรับแนวคิดนี้ เช่น subagents สำหรับแยกงานย่อยใน context ใหม่ agent teams สำหรับประสาน Claude Code หลาย instance และ hooks สำหรับดักจังหวะสำคัญของงาน เช่นก่อนเรียก tool หรือเมื่องานเสร็จ

สำหรับคนไม่สายเทค ประเด็นไม่ใช่ต้องออกแบบ multi-agent system เองทันที แต่ให้รู้ว่า workflow ที่ดีไม่ควรปล่อยให้ AI ตัวเดียวทำทุกอย่างในก้อนยาว ๆ เสมอไป บางครั้งงานควรถูกแบ่งเป็นบทบาท เช่น คนทำ คนตรวจ คนสรุป เพื่อให้พลาดยากขึ้นและตามรอยได้ง่ายขึ้น

จุดที่ต้องระวังคือ dynamic workflow เพิ่มทั้งพลังและความซับซ้อน ทุก agent ทุก skill ทุก tool schema ที่เพิ่มเข้ามาใช้ context เพิ่ม มี permission เพิ่ม และมีจุดพังเพิ่ม ถ้างานยังเล็ก เริ่มจาก prompt หรือ skill ธรรมดาก่อนมักดีกว่า

CI/CD คือเวทีที่งานรันเองเมื่อมีเหตุการณ์เกิด

พอคุณมี GitHub หรือ GitLab แล้ว สิ่งที่ตามมาคือ workflow ที่รันอัตโนมัติ เช่นทุกครั้งที่มี pull request ให้รัน test ทุกครั้งที่ merge ให้ deploy หรือทุกครั้งที่มี issue ใหม่ให้ AI ช่วย triage

ในวงการเรียกระบบพวกนี้ว่า CI/CD แบบภาษาคนคือ "งานหลังบ้านที่รันเองเมื่อมีเหตุการณ์ใน repo"

Claude Code มีเอกสารสำหรับ GitHub Actions และ GitLab CI/CD โดย GitHub Actions เวอร์ชัน v1 ใช้ workflow ที่อัปเดตจาก beta และมีการตรวจเรื่อง GitHub App, workflow triggers, secrets และ permission ส่วน GitLab integration ยังระบุว่าอยู่ใน beta และใช้ CI/CD jobs เพื่อให้ Claude ทำงานจาก issue, MR หรือ review thread แล้วเสนอ MR กลับมา

สำหรับคุณ สิ่งสำคัญไม่ใช่จำ YAML แต่คือรู้ว่า AI ไม่จำเป็นต้องรอคุณเปิดแชทเสมอไป มันสามารถถูกเรียกจากเหตุการณ์ เช่น comment, pull request, schedule หรือ webhook ได้

แต่เมื่อ automation เริ่มแตะ repo จริง permission ต้องชัดมาก ใครเรียกได้ เรียกแล้วแก้อะไรได้ เขียนกลับได้ไหม ต้องมีคน approve หรือไม่ เรื่องนี้จะไปลึกในบท วิจารณญาณ ความเชื่อถือ และความปลอดภัย

Channels คือทางให้เหตุการณ์ข้างนอกปลุก agent

ลองนึกภาพ agent ที่นั่งรออยู่ ไม่ได้เริ่มจากคุณพิมพ์ prompt แต่เริ่มจากสิ่งข้างนอกเกิดขึ้น

ลูกค้าทัก Telegram มี webhook จากเว็บ มีข้อความใน Discord มี alert จากระบบ monitoring มี email เข้า หรือมี issue ใหม่ใน GitHub เหตุการณ์พวกนี้คือ "ช่องทาง" ที่ปลุกให้ agent ทำงาน

ในบทนี้เราจะเรียกแบบกว้าง ๆ ว่า channels

channel ไม่ใช่ model และไม่ใช่ความฉลาดของ AI มันคือทางเข้าของ event ถ้าไม่มี channel, agent ต้องรอคนสั่ง ถ้ามี channel, agent เริ่มงานเองจากเหตุการณ์ได้

ตัวอย่างสมมติ

• webhook จาก Shopify บอกว่ามี order ใหม่ แล้ว agent สรุป order ใหญ่ผิดปกติ
• Discord message ในห้อง support ปลุก agent ให้ค้น docs แล้วร่างคำตอบ
• GitHub comment ที่ mention @claude ปลุก workflow ให้ช่วยแก้ code
• alert จาก dashboard ปลุก agent ให้รวบรวม log และเขียน incident summary

นี่เป็นฐานของระบบที่ตอบสนองต่อโลกจริง ไม่ใช่ระบบที่รอคน copy paste ข้อมูลเข้าห้องแชท

dev containers และ sandboxing คือทำให้ AI ทำงานในพื้นที่คุมได้

เมื่อ AI เริ่มรันคำสั่ง แก้ไฟล์ ติดตั้ง package หรือเข้าถึงระบบภายนอก คำถามสำคัญไม่ใช่แค่ "มันทำได้ไหม" แต่คือ "มันทำในพื้นที่ที่คุมได้ไหม"

dev container คือสภาพแวดล้อมทำงานที่นิยามไว้ชัด เช่นใช้ Docker container ให้ทุกคนในทีมมีเครื่องมือและ dependency เหมือนกัน เอกสาร Claude Code ระบุว่าสามารถรัน Claude Code ใน dev container ได้ ทำให้คำสั่งที่ Claude รันเกิดใน container แทน host machine และใช้กับเครื่องมือที่รองรับ Dev Containers spec เช่น VS Code, GitHub Codespaces หรือ JetBrains IDEs

ภาษาคนคือ dev container เหมือนครัวทดลองที่จัดอุปกรณ์ไว้เหมือนกันทุกครั้ง ใครเข้ามาก็เจอหม้อ กระทะ และวัตถุดิบชุดเดียวกัน ไม่ใช่เครื่องคนหนึ่งมีของครบ อีกคนขาดครึ่งหนึ่ง

sandboxing คือชั้นป้องกันอีกแบบสำหรับคำสั่งที่ AI รัน เอกสาร Claude Code อธิบาย sandboxed Bash tool และข้อจำกัดตามระบบปฏิบัติการ เช่น macOS ใช้ framework ของระบบ ส่วน Linux/WSL2 ต้องมีเครื่องมือและข้อกำหนดบางอย่าง

อย่าคิดว่า container หรือ sandbox คือกำแพงวิเศษที่ปลอดภัย 100% เอกสาร dev container เองก็เตือนว่าถ้าใช้โหมดข้าม permission prompt แบบอันตราย container ไม่ได้ป้องกันทุกอย่าง โดยเฉพาะถ้ามี credential อยู่ในพื้นที่ที่ agent เข้าถึงได้

สรุปสั้น ๆ คือ dev container ทำให้ environment คงที่ sandboxing ช่วยจำกัดขอบเขตการรันคำสั่ง และทั้งคู่ควรใช้คู่กับ permission ที่รอบคอบ

LLM gateway คือด่านหน้าที่คุมการเรียก model

เมื่อมี agent หลายตัว ระบบหลายตัว หรือทีมหลายคนเรียก model พร้อมกัน คุณจะเริ่มอยากมีด่านกลาง

ด่านนี้คอยดูว่าใครเรียก model ไหน เรียกเท่าไหร่ ใช้ key อะไร บันทึก log อย่างไร จำกัด rate limit อย่างไร และถ้ามี policy บริษัทต้องบังคับ จะบังคับตรงไหน

ในวงการมักเรียกแนวนี้ว่า LLM gateway หรือ proxy สำหรับคำขอไปหา model

เอกสาร secure deployment ของ Agent SDK พูดถึงการ route request ผ่าน proxy, credential injection, allowlist, logging และยกตัวอย่างเครื่องมืออย่าง LiteLLM ในฐานะ LLM gateway ที่ทำ credential injection และ rate limiting ได้

สำหรับคนไม่สายเทค ให้จำแค่นี้: ถ้าคุณใช้ AI คนเดียว gateway อาจยังไกลตัว แต่ถ้าทีมเริ่มมีหลาย agent หลาย key หลายระบบ และเริ่มถามว่า "เงินไหลไปไหน ข้อมูลออกไปทางไหน ใครเรียกอะไร" คุณกำลังเข้าเขตของ gateway

Agent SDK คือการสร้าง harness ของตัวเอง

ในบท Memory & context เราแตะไว้แล้วว่า Agent SDK คือชุดเครื่องมือสำหรับสร้าง agent หรือ harness ของตัวเอง ตรงนี้ขยายในมุม builder

ถ้า Claude Code, ChatGPT หรือ Codex คือ product สำเร็จรูป Agent SDK คือทางที่ให้คุณสร้าง product หรือ workflow ของคุณเองโดยยังใช้พลังของ agent loop, tools และ context management

เอกสาร Agent SDK ระบุว่าสามารถสร้าง custom tools ผ่าน in-process MCP server ให้ Claude เรียก function, API, logic เฉพาะโดเมน หรือฐานข้อมูลของคุณได้ และยังมีส่วน observability ผ่าน OpenTelemetry เพื่อดูว่า agent เรียก tool อะไร ใช้เวลาเท่าไหร่ ใช้ token และ cost เท่าไหร่ หรือพลาดตรงไหน

ถ้าลงลึกกว่านั้น Agent SDK ยังเกี่ยวกับสิ่งที่ระบบจริงต้องมี เช่น structured output เพื่อให้ผลลัพธ์ออกมาเป็นรูปแบบที่โปรแกรมอ่านต่อได้, hosting เพื่อเอา agent ไปอยู่ในระบบที่รันจริง, secure deployment เพื่อแยก credential และจำกัดสิทธิ์, และ hooks เพื่อควบคุมพฤติกรรมก่อนหรือหลัง tool call

พูดสั้น ๆ คือ API ให้คุณเรียก model แต่ Agent SDK ให้คุณสร้าง "คนทำงานดิจิทัล" ที่มีเครื่องมือ กฎ วิธีสังเกตการณ์ และพื้นที่รันของตัวเอง

นี่คือระดับที่คุณไม่ได้แค่ "ใช้ AI" แล้ว แต่กำลังสร้างระบบที่มี AI เป็นเครื่องยนต์ข้างใน

ตัวอย่างสมมติ

• ระบบช่วยทีมบัญชีอ่าน invoice แล้วเรียก tool ภายในเพื่อตรวจ supplier
• agent สำหรับ customer support ที่มี custom tool ค้น order, policy, ticket history
• workflow สรุป incident ที่ดึง log, dashboard, GitHub commit และเขียน report อัตโนมัติ
• agent สำหรับทีมกฎหมายที่เรียกฐานข้อมูล clause ภายในผ่าน tool ที่จำกัดสิทธิ์

Agent SDK จึงไม่ใช่ของที่ทุกคนต้องเปิดวันนี้ แต่มันคือเส้นทางถ้าคุณอยากเปลี่ยนจาก "ใช้ AI ช่วยงาน" เป็น "สร้างระบบที่ใช้ AI"

ลองทำดู: เช็กว่าคุณยังเป็น user หรือเริ่มเป็น builder

อ่านข้อความ 6 ข้อนี้ แล้วดูว่าข้อไหนเริ่มตรงกับคุณ

1. ฉันอยากให้ AI ทำงานซ้ำตาม schedule
2. ฉันอยากให้ AI เปิดเว็บแล้วตรวจว่าหน้าจอทำงานจริง
3. ฉันอยากเก็บงานเป็น version และย้อนกลับได้
4. ฉันอยากให้ AI หลาย session ทดลองคนละทางพร้อมกัน
5. ฉันอยากให้ event จาก GitHub, Discord หรือ webhook ปลุก agent
6. ฉันอยากสร้างระบบที่คนอื่นใช้ โดย AI ทำงานอยู่ข้างหลัง

ถ้าตรงแค่ 1 ข้อ คุณยังไม่ต้องเรียนทั้งหมด แค่รู้ชื่อไว้ ถ้าตรง 3 ข้อขึ้นไป คุณควรเริ่มเก็บพื้นฐาน builder อย่างจริงจัง

รายการพื้นฐานที่คุ้มที่สุดสำหรับคนไม่สายเทค

ถ้าคุณอยากไปทาง builder แต่ไม่รู้จะเริ่มจากอะไร อย่าเริ่มจากคำใหญ่ที่สุด เริ่มจากพื้นฐานที่เปิดทางมากที่สุด

1. terminal เบื้องต้น
   รู้ว่า command คืออะไร โฟลเดอร์ปัจจุบันอยู่ตรงไหน รันคำสั่งแล้ว output กลับมาตรงไหน

2. file path
   รู้ว่าไฟล์อยู่ที่ไหน เช่น content/report.md กับ /Users/name/project/content/report.md ต่างกันยังไง

3. repo และ GitHub เบื้องต้น
   รู้ว่า commit, branch, pull request, issue คืออะไรในระดับใช้งาน ไม่ต้องเก่ง git ทุกคำสั่ง

4. environment variable และ key
   รู้ว่า API key คือกุญแจ ไม่ควรวางในแชท ไม่ควร commit ขึ้น GitHub และมักถูกส่งผ่าน environment variable

5. browser automation เบื้องต้น
   รู้ว่าเมื่อไหร่ใช้ Chrome extension เมื่อไหร่ใช้ Playwright และทำไมงานซ้ำต้องมี test

6. permission และ scope
   รู้ว่าการให้ AI อ่านไฟล์ต่างจากให้เขียนไฟล์ ให้ query database ต่างจากให้ delete data และ key แบบ read-only ปลอดภัยกว่า key ที่ทำได้ทุกอย่าง

7. log และ observability
   รู้ว่างานที่รันเองต้องมีร่องรอยให้ตรวจ ไม่ใช่เชื่อว่า "น่าจะทำไปแล้ว"

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

ตารางแผนที่ builder แบบเร็ว

สิ่งที่อยากทำ	เครื่องมือที่ควรรู้	จำเป็นแค่ไหน
ให้ AI แตะเว็บที่ login อยู่	Claude in Chrome หรือ browser extension	สูงถ้าทำงานกับเว็บจริง
ให้เว็บถูกทดสอบซ้ำได้	Playwright	สูงสำหรับงานสร้างเว็บ
รัน agent ทิ้งไว้	tmux	กลางถึงสูง
เก็บประวัติและแชร์งาน	GitHub	สูงมาก
ทดลองหลายทางพร้อมกัน	worktrees	สูงเมื่อเริ่มรันหลาย session
ให้ AI รันจาก script	headless mode	สูงสำหรับ automation
แบ่งงานให้หลาย agent หรือหลายขั้นตอน	dynamic workflows	กลางถึงสูง
ให้ AI ทำงานเมื่อมี PR หรือ issue	GitHub Actions / GitLab CI	สูงสำหรับทีม
ปลุก agent จาก event ภายนอก	channels / webhook	กลางถึงสูง
คุม environment	dev containers	สูงสำหรับทีมและงานเสี่ยง
จำกัดขอบเขตคำสั่ง	sandboxing	สูงสำหรับ security
คุม model traffic และ keys	LLM gateway	สูงเมื่อมีหลายระบบ
สร้าง agent product ของตัวเอง	Agent SDK	สูงสำหรับ builder จริงจัง

อย่าเรียนทุกอย่างก่อนเริ่ม แต่ต้องรู้ว่ามีอะไรอยู่ตรงไหน

กับดักของบทนี้คืออ่านแล้วรู้สึกว่าต้องเรียนทั้งหมดก่อนถึงจะเริ่มใช้ AI สร้างของจริงได้

ไม่ต้อง

วิธีที่ดีกว่าคือเริ่มจากโจทย์จริง 1 งาน แล้วหยิบเครื่องมือเท่าที่งานบังคับ เช่นถ้าจะสร้างเว็บเล็ก ๆ ให้เริ่มจาก GitHub, terminal, browser automation ถ้าจะให้รันทุกคืน ค่อยเพิ่ม headless mode กับ schedule ถ้าจะให้หลาย agent ทำงานพร้อมกัน ค่อยเพิ่ม worktree ถ้าจะเปิดให้คนอื่นใช้ ค่อยคิดเรื่อง Agent SDK, gateway, observability และ deployment

Builder track ไม่ใช่ checklist ที่ต้องติ๊กให้ครบ มันคือชั้นวางเครื่องมือ คุณไม่ต้องถือทุกชิ้นพร้อมกัน แต่ต้องรู้ว่าชิ้นไหนอยู่ตรงไหนเวลางานเริ่มจริง

บทถัดไปจะกลับมาที่ทักษะที่สำคัญกว่าสายเทคทั้งหมดสำหรับผู้ใช้ทุกคน: วิธีคุยกับ AI ให้มันเข้าใจเจตนา context โครงสร้าง ตัวอย่าง และวิธี iterate งานจนได้ผลจริง

---

อ่านต่อ: วิธีคุยกับ AI จริง ๆ

แหล่งอ้างอิง

• https://playwright.dev/docs/actionability
• https://playwright.dev/docs/browsers
• https://code.claude.com/docs/en/chrome
• https://code.claude.com/docs/en/headless
• https://code.claude.com/docs/en/terminal-config
• https://code.claude.com/docs/en/worktrees
• https://code.claude.com/docs/en/devcontainer
• https://code.claude.com/docs/en/sandboxing
• https://code.claude.com/docs/en/github-actions
• https://code.claude.com/docs/en/gitlab-ci-cd
• https://code.claude.com/docs/en/agent-sdk/claude-code-features
• https://code.claude.com/docs/en/agent-sdk/custom-tools
• https://code.claude.com/docs/en/agent-sdk/observability
• https://code.claude.com/docs/en/agent-sdk/secure-deployment
• https://printingpress.dev/