AI agent หรือระบบ AI ที่ลงมือทำงานแทนเราได้เอง จะทำงานได้จริงหรือไม่ ไม่ได้ขึ้นกับโมเดลอย่างเดียว แต่อยู่ที่งานวิศวกรรมที่คนสร้างครอบโมเดลไว้อีกชั้น โครงสร้างนี้มีสามส่วนหลักคือ harness (ชุดเครื่องมือที่คอยคุมโมเดล), loop engineering (การกำหนดว่าเมื่อไหร่ agent ควรหยุดทำงาน) และ LLM Ops (การวัดผลและดูแลระบบให้ดีขึ้นเรื่อยๆ) สามคำนี้ฟังเหมือนศัพท์เทคนิค แต่จริงๆ แล้วคือคำตอบว่าทำไม agent บางตัวเอาไปใช้งานจริงได้ ส่วนบางตัวได้แค่ตอบเล่นๆ ในเดโม

เพราะลำพัง LLM (โมเดลภาษาขนาดใหญ่ที่อยู่เบื้องหลัง AI) เปรียบเหมือนสมองที่ฉลาดมาก รู้เรื่องราวของมนุษย์แทบทุกอย่าง แต่ไม่รู้จักตัวเราหรือธุรกิจของเราเลยสักนิด และถ้าดูการทำงานหนึ่งครั้งของมัน (ที่เรียกว่าหนึ่ง agent run) จริงๆ แล้วข้อมูลที่ส่งเข้าโมเดลมีแค่ prompt (คำถามหรือคำสั่งที่ผู้ใช้พิมพ์เข้าไป) ประวัติแชทที่คุยกันมา และ system prompt (คำสั่งตั้งต้นที่กำหนดบทบาทให้โมเดล) เพื่อให้ได้คำตอบกลับมาหนึ่งครั้ง พอจบรอบนั้นมันก็ลืมหมด จำข้ามรอบไม่ได้ จึงกลายเป็นระบบที่ไม่มีความทรงจำถาวร

ทั้งหมดนี้คือสิ่งที่คลิปสอนของช่อง Sean's AI Stories อธิบายไว้ครบภายในเวลาไม่ถึง 20 นาที เริ่มจากคำถามเดียวว่า จะเปลี่ยนสมองที่ไม่รู้จักเรา ให้กลายเป็นผู้ช่วยที่ไว้ใจให้ทำงานแทนได้ยังไง คำตอบชั้นแรกคือ harness

ม้าที่แรงเกินไป ถ้าไม่มีบังเหียน

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

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

ถ้าอยากลงมือสร้าง harness เอง เฟรมเวิร์กที่คนในวงการหยิบมาใช้กันก็มีอย่าง LangGraph, LangChain และ Pydantic AI แต่ตัวเครื่องมือเป็นแค่โครง สิ่งที่ทำให้ harness มีค่าจริงๆ คือความจำที่เราออกแบบใส่เข้าไป

ความจำสามแบบที่ทำให้ agent เริ่มจำเราได้

ความจำที่ agent ใช้ตอนคิดคำตอบเรียกว่า working memory คือความจำชั่วคราวสำหรับใช้งาน คล้าย RAM ในเครื่อง มีอยู่แค่ในรอบนั้น พอจบรอบก็หายไป harness เลยเพิ่มความจำถาวรให้อีกสามแบบ

แบบแรกคือ procedural memory หรือความจำเชิงวิธีการ เป็นคำสั่งว่า agent ควรทำงานและตอบสนองยังไง ในทางปฏิบัติมักเป็นแค่ไฟล์ข้อความหรือ markdown ที่เราเขียนแล้วป้อนให้ agent อ่าน หรือที่หลายคนเรียกกันว่าไฟล์ skill นั่นเอง

แบบที่สองคือ semantic memory เป็นข้อเท็จจริงถาวรเกี่ยวกับตัวเราและงานของเรา เช่นชื่อลูกค้า เงื่อนไขทางธุรกิจ หรือข้อมูลเฉพาะขององค์กร ซึ่งเป็นสิ่งที่ไม่ได้อยู่ในชุดข้อมูลตอนเทรนโมเดลพื้นฐานมาก่อน

แบบที่สามคือ episodic memory เป็นบันทึกเหตุการณ์และบทสนทนาที่ผ่านมา โดยเรียงตามเวลา เก็บสิ่งที่ไม่ได้อยู่ในแชทรอบปัจจุบันแต่เคยเกิดขึ้นจริง

ความจำทั้งสามแบบนี้ไม่ได้ลอยอยู่เฉยๆ แต่เก็บไว้ในฐานข้อมูล แล้วดึงกลับเข้ามาใน working memory ตอนที่ agent ต้องใช้ ฐานข้อมูลก็ใช้บริการอย่าง AWS, Supabase, Google Cloud หรือ Azure ได้ (ส่วนการตั้งเซิร์ฟเวอร์เองที่บ้าน มักไม่คุ้มเพราะแพงเกินไป)

บันทึกที่โตไม่หยุด ต้องมีคนคอยย่อย

ปัญหาของ episodic memory คือมันโตขึ้นเรื่อยๆ เพราะระบบบันทึกทุกเหตุการณ์ลงไปหมด พอใช้งานจริงในสเกลใหญ่ กองบันทึกดิบก็ใหญ่จนเทอะทะ ทางแก้คือหมั่นย่อยให้กลายเป็นข้อเท็จจริงถาวรใน semantic memory เป็นระยะ

ตัวอย่างที่คลิปยกมาคือ ทุกๆ ราว 2,000 บทสนทนา ก็ให้ agent สรุปข้อมูล (summarizer agent) ทำงานหนึ่งรอบ งานนี้คือการเรียก LLM อีกครั้งที่มี system prompt ของตัวเอง และเพราะข้อมูลขาเข้ามีปริมาณมาก จะเลือกใช้โมเดลที่ถูกลงหรือเป็นโอเพนซอร์สก็ได้ หน้าที่ของมันคือกลั่นประวัติดิบยาวๆ ให้เหลือเป็นข้อเท็จจริงที่ใช้ซ้ำได้

เวลาจะดึงความจำกลับมาใช้ วิธีก็ต่างกันตามชนิดของความจำ semantic memory ใช้วิธีแบบ RAG คือการค้นด้วยความหมาย (semantic search) ส่วน episodic memory บางครั้งต้องส่งคำสั่งค้นฐานข้อมูลตรงๆ แบบ SQL เมื่อคำถามระบุช่วงเวลาชัดเจน และบางครั้งก็ต้องใช้ RAG ร่วมด้วย เมื่อคำถามต้องเทียบความหมายข้ามเหตุการณ์จำนวนมาก เช่น ถามว่า "20 บทสนทนาก่อนหน้าที่มีลูกค้าร้องเรียนเรื่องคุณภาพ แล้ว agent แก้ให้ไม่ได้ มีอะไรบ้าง" คำถามแบบนี้ต้องใช้ทั้งสองวิธีพร้อมกัน

รู้ว่าเมื่อไหร่ควรหยุด คือหัวใจของ loop engineering

ในหนึ่ง agent run โมเดลไม่ได้เรียกใช้เครื่องมือแค่ครั้งเดียว แต่การเรียกใช้เครื่องมือ (tool calling) อาจเกิดขึ้นได้หลายรอบ เช่น นัดประชุม อ่านและเขียนข้อมูลในระบบ CRM (ฐานข้อมูลลูกค้า) หรือดึงข้อมูลการจ่ายเงินจากบริการชำระเงิน ปัญหาคือถ้าไม่มีกรอบคอยคุม agent อาจวนเรียกเครื่องมือไปเรื่อยๆ ไม่รู้จบ หรือไม่รู้ว่าควรหยุดตรงไหนแล้วตอบ

ตรงนี้แหละที่ loop engineering เข้ามามีบทบาท หัวใจของมันคือ end-loop guardrail หรือกติกาที่คอยตัดสินว่าคำตอบดีพอให้ agent หยุดแล้วตอบกลับได้หรือยัง

ลองดูตัวอย่างที่คลิปยกมา สมมติสั่ง agent ว่า "ไปดูว่าลูกค้าบ่นเรื่องอะไร ตามงานต่อ แล้วเช็คสถานะการคืนเงินให้ด้วย" agent จะเข้าไปค้นในระบบ CRM ก่อน เจอว่ามีคำร้องเรียน 30 รายการในช่วงสองเดือน ในจำนวนนี้คืนเงินให้ไปแล้ว 12 ราย และมีอีก 8 รายที่ยังไม่ได้คืน จากนั้นมันจะวนกลับไปทำงานอีกรอบ เพื่อสร้างงานติดตามและสั่งคืนเงินให้ 8 รายที่ยังค้างอยู่ วนเรียกเครื่องมือซ้ำไปเรื่อยๆ จนกว่าจะถึงเงื่อนไขที่ถือว่างานเสร็จ หรือไม่ก็ถามเรากลับมาก่อนว่าตกลงคำว่า "เสร็จ" หมายถึงแค่ไหน

สิ่งที่ต้องรู้คือ loop ไม่มีสูตรตายตัว มันขึ้นกับงานเป็นกรณีๆ ไป มีแค่รูปแบบคร่าวๆ ที่เหมือนกันคือ เรียกเครื่องมือ แล้วเช็คว่าถึงจุดที่ควรหยุดหรือยัง ถ้ายังก็วนต่อ ถ้าถึงแล้วก็ตอบ

เริ่มจากจุดที่เล็กที่สุดก็ได้

ข้อดีของ loop engineering คือไม่ต้องลงมือทั้งระบบตั้งแต่แรก เริ่มจากชิ้นเล็กๆ ก่อนก็ได้ ตัวอย่างที่จับต้องได้ทันทีในคลิปคือการตั้ง hook (ตัวดักเหตุการณ์ที่สั่งให้ทำอะไรอัตโนมัติ) ใน Claude Code ซึ่งเป็นเครื่องมือ AI agent สำหรับเขียนโค้ด ให้ทำงานตอนที่ agent ติดค้างอยู่

ลองนึกถึงตอนที่ agent กำลังทำงานยาวๆ แล้วไปสะดุดตรงที่ต้องรอเรากดอนุญาต (permission prompt) ถ้าไม่มีอะไรมาเตือน เราอาจเดินไปทำอย่างอื่นสัก 30 นาที กลับมาอีกทีถึงรู้ว่ามันค้างรอเราอยู่ตรงนั้นมา 25 นาทีแล้ว โดยไม่ได้ทำงานต่อเลย

วิธีเริ่มก็ง่ายมาก เปิดไฟล์ตั้งค่า hook ของ agent แล้วเพิ่มเงื่อนไขว่าเมื่อไหร่ที่มันติดรอ permission ให้ส่งการแจ้งเตือนเด้งขึ้นมาที่เครื่องเรา แค่นี้ loop เล็กๆ วงแรกก็ทำงานแล้ว จากตรงนี้ค่อยขยับไปออกแบบเงื่อนไขหยุดที่ซับซ้อนขึ้นทีหลัง

LLM Ops วงจรที่ทำให้ระบบดีขึ้นเองเรื่อยๆ

พอมี harness กับ loop แล้ว คำถามถัดมาคือ ระบบที่สร้างไว้ทำงานได้ดีจริงไหม และเราจะแก้ให้มันดีขึ้นได้เรื่อยๆ ยังไง นี่คือหน้าที่ของ LLM Ops หรือที่เรียกกันว่า eval เป็นวงจรที่คอยดูแล harness และ loop อีกชั้นหนึ่ง มันมีอยู่สี่ขั้น

ขั้นแรกคือ tracing หรือการบันทึกทุกขั้นของแต่ละ run ตามลำดับ ว่ารอบนั้นมีคำถามอะไรเข้ามาบ้าง ดึงความจำอะไรกลับมาบ้าง เรียกเครื่องมือกี่ครั้งและเรียกยังไง ใช้เวลาตอบนานแค่ไหน และกิน token (หน่วยข้อมูลที่โมเดลใช้คิดค่าใช้จ่าย) ไปเท่าไร เครื่องมือที่ทำงานนี้ก็อย่าง Langfuse และ LangSmith

ขั้นที่สองคือ evaluation หรือการให้คะแนน run นั้น โดยดูสองด้าน ด้านแรกคือได้ผลจริงไหม คือผลลัพธ์ตามที่ตั้งใจเกิดขึ้นจริงหรือเปล่า เช่นนัดประชุมได้จริงตามที่สั่งไหม ด้านที่สองคือทำงานคุ้มไหม คือดูว่าตอบเร็วพอและต้นทุน token ไม่บานปลายหรือเปล่า การให้คะแนนจะใช้ LLM อีกตัวมาเป็นกรรมการ (LLM as a judge) หรือเขียนโค้ดตรวจแบบตายตัวก็ได้

ขั้นที่สามคือ diagnosis หรือการหาสาเหตุว่าทำไมถึงพลาดหรือช้า เช่นขั้นตอนนัดประชุมไม่ทำงานเลย หรือใช้เวลาตอบ 20 วินาที ทั้งที่ควรจะเป็นแค่ 2 มิลลิวินาที เพราะ working memory ใหญ่เกินไป หรือคำถามนั้นไม่จำเป็นต้องดึงความจำมาทั้งกองด้วยซ้ำ ในเมื่อโมเดลก็รู้คำตอบอยู่แล้ว เช่นถามว่า OpenAI ก่อตั้งเมื่อไหร่ งานหาสาเหตุตรงนี้ยังโยนให้ coding agent อย่าง Claude ช่วยตรวจรายละเอียดในบันทึก trace ต่อได้อีก

ขั้นที่สี่คือจุดตัดสินใจว่าจะเอาเวอร์ชันที่แก้แล้วขึ้นใช้จริงไหม ถ้าผลประเมินผ่านและสิ่งที่ต้องแก้เป็นเรื่องเล็ก เช่นปรับ system prompt เป็นเวอร์ชันใหม่ เปลี่ยนค่า config ของโมเดล หรือปรับพารามิเตอร์การดึงความจำ ก็ส่งกลับเข้าระบบ agent run ได้เลย ถือว่าปิดหนึ่งรอบของ LLM Ops แต่ถ้าเจอว่าพังลึกจริงๆ ต้องไล่แก้บั๊กต้นตอก่อน แล้วค่อยรันใหม่ ไล่ trace และประเมินผลกันใหม่ตั้งแต่ต้น

พอวางเรียงกันครบทั้งสามชั้น ภาพก็ชัดขึ้น คือ harness ให้ความจำและเครื่องมือ ส่วน loop ทำให้รู้จักหยุด และ LLM Ops คอย trace ประเมิน หาสาเหตุ แล้ววนกลับไปแก้ สามชั้นนี้ทำงานประกอบกันจนระบบ agent ค่อยๆ พัฒนาขึ้นเองเมื่อเวลาผ่านไป แทนที่จะหยุดนิ่งอยู่กับที่ตั้งแต่วันแรก

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

---

ที่มา: คลิป You Can Learn AI Agent Harness & Loop Engineering In 19 Min | LLM Ops, Eval, Tracing, RAG จากช่อง Sean's AI Stories