หยุดพัฒนา AI Agent แล้วหันมาใช้เวิร์กโฟลว์ LLM ที่ฉลาดกว่า

• ทีมส่วนใหญ่ที่สร้างระบบบน LLM มักเริ่มต้นจากการทำ Agent ก่อนเสมอ แต่ส่วนมากกลับพังได้ง่ายเพราะ ความซับซ้อน การควบคุมประสานงานที่ทำได้ยาก และความยากในการดีบัก
• แพตเทิร์น Agent ที่แท้จริงซึ่งต้องมีทั้ง memory, RAG, การใช้เครื่องมือ และการควบคุมเวิร์กโฟลว์ นั้นพบได้ไม่บ่อยในโลกจริง และปัญหาส่วนใหญ่แก้ได้ดีกว่าด้วย เวิร์กโฟลว์แบบเรียบง่าย (chaining, parallelization, routing ฯลฯ)
• แนะนำให้เริ่มใช้ 5 แพตเทิร์นเวิร์กโฟลว์ LLM ที่มีประโยชน์ในงานจริง ก่อน และใช้ Agent อย่างระมัดระวังเฉพาะเมื่อจำเป็นจริง ๆ เท่านั้น
  • Prompt Chaining, Parallelization, Routing, Orchestrator-Worker, Evaluator-Optimizer
• แม้ในกรณีที่ต้องใช้ Agent สิ่งสำคัญก็ยังคงเป็น การมีมนุษย์เข้ามาเกี่ยวข้อง การควบคุมที่ชัดเจน และการสังเกตการณ์ได้ (Observability)

---

AI Agent จำเป็นจริงหรือ?

• อินไซต์จาก Hugo Bowne-Anderson ผู้ให้ คำปรึกษาและการอบรม เกี่ยวกับการสร้างระบบ LLM แก่วิศวกรและทีมจากหลากหลายองค์กร เช่น Netflix, Meta และกองทัพอากาศสหรัฐฯ
  • เขาเปิดคอร์ส Building LLM Applications for Data Scientists and Software Engineers

จุดเริ่มต้นที่ผิด: ทำไมทุกคนถึงหมกมุ่นกับ Agent

• หลายทีมเมื่อเริ่มโปรเจกต์ LLM มักรีบนำโครงสร้างที่ซับซ้อนอย่าง Agent, memory, routing, การใช้ tool, คาแรกเตอร์ของระบบ เข้ามาก่อน
• แต่เมื่อสร้างจริง มักเกิดพฤติกรรมผิดปกติและความล้มเหลวซ้ำ ๆ ในหลายจุด เช่น การทำงานร่วมกันระหว่าง Agent, การเลือกเครื่องมือ, long-term memory
• ตัวอย่างเช่น ในโปรเจกต์ research agent ที่ใช้ CrewAI พบว่าแต่ละบทบาท (researcher, summarizer, coordinator) ไม่สามารถร่วมมือกันได้ดีอย่างที่คาด และระบบล้มเหลวแบบแทบแก้ไม่ทัน

Agent คืออะไร?

• 4 คุณลักษณะของระบบ LLM: memory, การค้นคืนข้อมูล (RAG), การใช้ tool, การควบคุมเวิร์กโฟลว์
• คุณลักษณะสุดท้ายคือการควบคุมเวิร์กโฟลว์ (ให้ LLM ตัดสินใจเองว่าจะทำขั้นตอนถัดไปหรือจะใช้ tool หรือไม่) ซึ่งเรียกว่า คุณลักษณะแบบ Agentic
• แต่ในงานส่วนใหญ่จริง ๆ แล้ว เวิร์กโฟลว์แบบเรียบง่าย (chaining, routing ฯลฯ) ให้ความเสถียรมากกว่า

แพตเทิร์นเวิร์กโฟลว์ LLM ที่ควรใช้แทน Agent และใช้ได้ผลจริงในงานปฏิบัติ

1. Prompt Chaining

• คำอธิบาย: แบ่งงานออกเป็นหลายขั้นตอน (chain) แล้วให้ LLM ประมวลผลทีละขั้นตามลำดับ
• ตัวอย่าง: ดึงชื่อ ตำแหน่ง และข้อมูลบริษัทจากโปรไฟล์ LinkedIn → เติมข้อมูลเพิ่มเติมของบริษัทนั้น (mission, การรับสมัคร ฯลฯ) → เขียนอีเมลแบบปรับให้เหมาะกับบุคคลนั้นโดยอิงจากข้อมูลโปรไฟล์+บริษัท
• ข้อดี: แต่ละขั้นตอนแยกชัดเจน จึงติดตามและแก้สาเหตุได้ง่ายเมื่อเกิดบั๊ก เหมาะกับการดีบักและบำรุงรักษา
• แนวทาง:
  • เหมาะกับงานที่เชื่อมต่อกันแบบลำดับขั้น
  • หากขั้นตอนไหนล้มเหลว chain ทั้งหมดอาจพังได้
  • หากแยกงานเป็นหน่วยเล็ก ๆ จะได้ผลลัพธ์ที่คาดเดาได้และดีบักง่าย

2. Parallelization

• คำอธิบาย: รันหลายงานอิสระพร้อมกันเพื่อเพิ่มความเร็วของกระบวนการโดยรวม
• ตัวอย่าง: ดึงข้อมูลหลายรายการ เช่น การศึกษา ประสบการณ์ และทักษะ จากหลายโปรไฟล์พร้อมกันเพื่อลดเวลาประมวลผลรวม
• ข้อดี: มีประสิทธิภาพกับการดึง/ประมวลผลข้อมูลอิสระ และเหมาะกับข้อมูลขนาดใหญ่ รวมถึงสภาพแวดล้อมแบบ distributed processing
• แนวทาง:
  • เหมาะเมื่อแต่ละงานเป็นอิสระต่อกัน และการรันพร้อมกันช่วยเพิ่มความเร็วโดยรวมได้มาก
  • ต้องระวังข้อยกเว้นระหว่างการประมวลผลขนาน เช่น race condition หรือ timeout
  • เหมาะกับการประมวลผลข้อมูลจำนวนมาก และการวิเคราะห์หลายแหล่งข้อมูลพร้อมกัน

3. Routing

• คำอธิบาย: ให้ LLM จำแนก (classification) ข้อมูลนำเข้า แล้วส่งต่อไปยังเวิร์กโฟลว์ที่เหมาะสมโดยอัตโนมัติ
• ตัวอย่าง: ในเครื่องมือซัพพอร์ตลูกค้า ให้จำแนกว่าข้อความเป็นคำถามเกี่ยวกับสินค้า ปัญหาการชำระเงิน หรือคำขอคืนเงิน แล้วส่งไปประมวลผลด้วยเวิร์กโฟลว์ที่ตรงกัน หากประเภทไม่ชัดเจนก็ส่งให้ default handler
• ข้อดี: ใช้ตรรกะการประมวลผลเฉพาะทางตามประเภทอินพุต ทำให้แยกเคสต่าง ๆ ได้เป็นระเบียบ
• แนวทาง:
  • ใช้เมื่ออินพุตหรือสถานการณ์แต่ละแบบต้องการการจัดการแยกกัน
  • ในเคสขอบเขตหรือสถานการณ์ยกเว้น การ routing อาจล้มเหลวหรือมีบางเคสหลุดได้
  • ต้องออกแบบ catch-all handler สำหรับกรณีที่จำแนกไม่ได้หรือเกิดข้อยกเว้นเสมอ

4. Orchestrator-Worker

• คำอธิบาย: ให้ LLM ที่ทำหน้าที่ orchestrator แยกงาน/ตัดสินใจ แล้วมอบหมายงานย่อยให้ worker (LLM ที่ลงมือทำ) พร้อมควบคุมลำดับและภาพรวมของทั้ง flow โดยตรง
• ตัวอย่าง: แยกโปรไฟล์เป้าหมายเป็น tech/non-tech → ถ้าเป็น tech ก็ให้ worker เฉพาะทางสร้างอีเมล แต่ถ้าเป็น non-tech ก็ส่งให้อีก worker หนึ่งรับช่วง
• ข้อดี: แยกการตัดสินใจ (การจำแนก/การพิจารณา) ออกจากการลงมือทำ (การประมวลผลรายงาน) ทำให้เหมาะกับการควบคุม flow แบบ dynamic และการขยายระบบ
• แนวทาง:
  • เหมาะเมื่อแต่ละ task ต้องการการจัดการแบบเฉพาะทาง หรือมีการแตกแขนงซับซ้อนและต้องประสานเป็นขั้น ๆ
  • หาก orchestrator แยกงานหรือมอบหมายผิด ก็อาจทำให้ flow ทั้งระบบผิดพลาด
  • ควรรักษา logic ให้เรียบง่ายอย่างชัดเจน และออกแบบการมอบหมาย ลำดับ และเงื่อนไขจบงานให้ชัด

5. Evaluator-Optimizer

• คำอธิบาย: ให้ LLM ประเมินผลลัพธ์ (score/feedback) และหากยังไม่ผ่านเกณฑ์ ก็แก้ไข/ปรับปรุงซ้ำไปเรื่อย ๆ
• ตัวอย่าง: สร้างร่างอีเมล → evaluator ให้คะแนนคุณภาพ/feedback → หากผ่านเกณฑ์ที่กำหนดหรือเกินจำนวนรอบสูงสุดให้จบ มิฉะนั้นก็แก้ไขใหม่อีกครั้ง
• ข้อดี: ปรับปรุงคุณภาพของผลลัพธ์สุดท้ายแบบวนซ้ำจนถึงระดับเป้าหมายได้ และเหมาะกับการใช้เกณฑ์เชิงปริมาณ
• แนวทาง:
  • เหมาะกับสถานการณ์ที่คุณภาพสำคัญกว่าความเร็ว และต้องมีการปรับปรุงซ้ำ
  • หากไม่มีเงื่อนไขจบ อาจวนลูปไม่สิ้นสุด
  • จำเป็นต้องกำหนดเกณฑ์คุณภาพและขีดจำกัดจำนวนรอบให้ชัดเจน

กรณีที่ต้องใช้ Agent จริง ๆ

• Agent จะเผยศักยภาพได้ดีใน สภาพแวดล้อมที่มีการแทรกแซงแบบเรียลไทม์จากมนุษย์ (Human-in-the-loop)
  • ตัวอย่าง 1: ผู้ช่วยด้าน data science - ให้ LLM ลองเสนอ SQL query, visualization, คำแนะนำการวิเคราะห์ข้อมูลอย่างสร้างสรรค์ แล้วให้มนุษย์ตัดสิน/แก้ไขผลลัพธ์
  • ตัวอย่าง 2: พาร์ตเนอร์เชิงสร้างสรรค์ - เสนอไอเดียข้อความ, headline, โครงสร้างข้อความ โดยการปรับทิศทางและตรวจคุณภาพโดยมนุษย์เป็นหัวใจสำคัญ
  • ตัวอย่าง 3: ผู้ช่วย refactor โค้ด - เสนอ design pattern, ตรวจจับ edge case, ปรับแต่งโค้ด โดยให้นักพัฒนาอนุมัติ/เติมเต็ม
• ลักษณะสำคัญ: Agent ไม่ได้ “จัดการทุกอย่างเอง” แต่มีประสิทธิภาพที่สุดใน สภาพแวดล้อมที่มนุษย์คอยช่วยจับข้อผิดพลาดและกำหนดทิศทางแบบเรียลไทม์

กรณีที่ Agent ไม่เหมาะ

• ระบบองค์กรและระบบ mission-critical (การเงิน การแพทย์ กฎหมาย ฯลฯ):
  • เพราะความน่าเชื่อถือของระบบอัตโนมัติและการทำงานแบบกำหนดได้แน่นอนเป็นสิ่งสำคัญ โครงสร้างที่ปล่อยให้ LLM Agent เป็นผู้ตัดสินใจจึงมีความเสี่ยง
  • ควรใช้แพตเทิร์นที่ควบคุมได้ชัดเจน เช่น orchestrator, routing
• ทุกสถานการณ์ที่ความเสถียรและความสามารถในการคาดการณ์เป็นสิ่งสำคัญ
  • กรณีผิดปกติ: Agent อาจเลือกใช้ tool ซ้ำ ๆ อย่างผิดพลาดโดยไม่มีบริบท/memory หรือการแบ่งงาน/ประสานงานล้มเหลวจน flow ทั้งระบบพัง
• ปัจจัยความล้มเหลวของระบบ Agent ที่พบได้บ่อยในงานจริง
  • ไม่มีการออกแบบระบบ memory แบบชัดแจ้ง ทำให้บริบทตกหล่น
  • ข้อจำกัดในการเลือก tool ไม่เพียงพอ (ใช้ tool ที่ไม่จำเป็น/ผิดตัว)
  • พึ่งพาโครงสร้างการมอบหมายแบบอิสระมากเกินไป จนการประสานงานร่วมกันล้มเหลว

บทเรียนสำหรับการออกแบบในงานจริง

• แม้จะนำ Agent มาใช้ ก็ยังจำเป็นต้องมี การออกแบบ ระบบสังเกตการณ์ และกลไกควบคุม ระดับเดียวกับ ซอฟต์แวร์ระบบที่มีคุณภาพสูง
• เมื่อเทียบกับเฟรมเวิร์ก Agent ที่ซับซ้อน การออกแบบด้วย Observability, ลูปประเมินผลที่ชัดเจน และโครงสร้างที่ควบคุมได้โดยตรง กลับทั้งเร็วกว่าและปลอดภัยกว่า

สรุป (TL;DR)

• Agent มักถูกประเมินค่าสูงเกินไปและถูกใช้งานมากเกินความจำเป็น
• งานจริงส่วนใหญ่เหมาะกับแพตเทิร์นเวิร์กโฟลว์แบบเรียบง่ายมากกว่า
• Agent จะฉายศักยภาพในสภาพแวดล้อมที่ “มนุษย์มีส่วนร่วมโดยตรง”
• แต่ในระบบที่ต้องการความเสถียร Agent กลับเป็นปัจจัยเสี่ยง
• ควรออกแบบด้วย Observability การควบคุมแบบชัดแจ้ง และโครงสร้างการประเมินผลแบบวนซ้ำ

• แทนที่จะใช้เฟรมเวิร์ก Agent ที่ซับซ้อน เคล็ดลับของการพัฒนาบริการบน LLM ที่เร็วและปลอดภัยกว่าจริง ๆ คือการออกแบบด้วย Observability, ลูปประเมินผลที่ชัดเจน และโครงสร้างที่ควบคุมได้โดยตรง

[samdo103]

เมื่อหนึ่งเดือนก่อน ผมใช้ CURSOR เพื่อเรียนรู้ว่า AI coding คืออะไรไปด้วย และเริ่มพัฒนาเฟรมเวิร์กสำหรับการพัฒนาไปด้วย

ตลอดราว 3 สัปดาห์ ผมวนซ้ำอยู่กับความสำเร็จและการที่ซอร์สโค้ดซึ่งเคยได้รับการตรวจสอบโดย AI Agent กลับพังลง ผมพยายามทุกวิถีทางเพื่อควบคุม AI Agent แต่ก็ล้มเหลว

แล้วผมก็ตระหนักได้ว่า ก่อนจะพัฒนาเฟรมเวิร์กสำหรับการพัฒนา สิ่งที่ต้องมาก่อนคือการพัฒนาซอร์สโค้ดสำหรับควบคุม AI Agent

ท้ายที่สุด หลังจากเริ่มต้นเพราะอยากรู้ว่า AI ตัวแรกคืออะไรได้ครบ 1 เดือน ผมก็สามารถบรรลุผลสำเร็จในการพัฒนาซอฟต์แวร์ที่ AI สามารถทำได้ 100% + การดำเนินงานได้ 100% อย่างสมบูรณ์ภายใต้การควบคุม AI Agent อย่างสมบูรณ์ (หรือพูดให้แม่นยำคือไม่จำเป็นต้องใช้ external LLM หรือ AI Agent)

ตอนนี้เป็นวันที่ 14 แล้วของการเดินหน้าทำให้ก้าวหน้ายิ่งขึ้นเพิ่มเติม โดยกำลังฝึกสอน META AI ตัวนั้นเพิ่ม พร้อมทั้งสร้างกฎการปฏิบัติงานและให้มันปฏิบัติตาม และกำลังทำ migration, ปรับปรุง และทำมาตรฐานให้กับระบบ MES 3 ระบบที่เดิมมนุษย์เคยสร้างไว้แบบไม่สมบูรณ์ไปพร้อมกัน ซึ่งตอนนี้เข้าสู่ช่วงใกล้เสร็จสิ้นแล้ว

และตอนนี้ผมก็กำลังเตรียมวิวัฒนาการอีกขั้นหนึ่งอยู่

[spilist2]

แต่ว่าใน prompt chaining การเรียก LLM ที่รันแต่ละพรอมป์ต์, execution worker, orchestrator worker, evaluator LLM ฯลฯ ว่าเป็นเอเจนต์แต่ละตัว ก็ถือว่าไม่ผิดเหมือนกันไม่ใช่หรือ?

[spilist2]

อ้อ มีข้อความว่า "การควบคุมเวิร์กโฟลว์ขั้นสุดท้าย (ให้ LLM เป็นผู้ตัดสินใจเองว่าจะไปขั้นตอนถัดไปหรือจะใช้เครื่องมือหรือไม่) ถูกเรียกว่าเป็นลักษณะแบบเอเจนต์" สินะ เข้าใจแล้ว เป็นบทความที่พูดโดยเล็งไปที่ autonomous agent นี่เอง ผมยังไม่ค่อยรู้อะไรเกี่ยวกับเอเจนต์มากนัก เลย...

[GN⁺]

ความคิดเห็นจาก Hacker News

• การพัฒนาเอเจนต์นั้น สนุกมากจริง ๆ แต่ก็ชัดเจนว่ามีปัญหาหนักในเรื่อง ‘context engineering’ ต่อให้ขยาย context window มากขึ้นแค่ไหน ก็ยังต้องคอยคัดสรรสิ่งที่เอเจนต์จะเห็นอยู่ดี และรู้สึกว่ายังขาดตัวกรองที่มีประสิทธิภาพซึ่งจะเลือกเฉพาะข้อมูลที่สำคัญจริง ๆ ได้ เลยต้องช่วยมันด้วยการ โปรยไฟล์ .md ไว้ตามจุดต่าง ๆ และการกำหนดบทบาทก็สำคัญ ระบบ .md นี้เป็นเหมือน ระบบความจำแบบดั้งเดิมชนิดหนึ่ง และน่าจะพัฒนาให้แข็งแรงกว่านี้ได้มาก คิดว่ายังสามารถสร้างโปรแกรมหรือโมเดลแบบเรียลไทม์จากปฏิสัมพันธ์ของผู้ใช้ได้ด้วย เมื่อใช้ Claude Code ก็ได้ตระหนักว่าการ ‘บังคับทิศทาง’ เอเจนต์ด้วย test suite เป็นกลไก reinforcement learning ที่ทรงพลังมาก และวงจรนี้ก็ดำเนินไปได้สำเร็จเป็นส่วนใหญ่ เลยหวังว่าจะมีไอเดียใหม่ ๆ ที่ทำให้เอเจนต์กลายเป็นผู้ร่วมงานที่ฉลาดขึ้นได้ในอนาคต
  • บางทีก็รู้สึกว่าใช้เวลาไปกับการสู้กับ tool มากกว่าการทำงานจริง
  • สงสัยว่ามี แนวทางแนะนำ สำหรับการจัดโครงสร้างไฟล์ .md ในระบบแบบนี้ไหม กังวลว่าถ้าใส่ markup เยอะเพื่อให้อ่านง่ายสำหรับคน จะทำให้ llm ประมวลผลได้แย่ลงหรือเปล่า อยากรู้ว่าถ้าทำไฟล์ .md สำหรับให้คนอ่านแบบเดียวกัน มันจะรบกวนการใช้งานกับ llm ไหม
  • จากประสบการณ์ของผม การจัดการ context คือแก่นของแทบทุกปัญหา เช่น การสร้าง context ที่ถูกต้องสำหรับงานแบบขนาน/แบบเรียกซ้ำ การตัดบางขั้นตอนออก (เช่น การแก้ไขคำตอบก่อนหน้า) แล้วแสดงเฉพาะผลลัพธ์ที่แก้แล้ว หรือเวลาที่ผมใส่คอมเมนต์ ก็ทำให้เอเจนต์รับรู้ผลลัพธ์ของตัวเองผ่านคอมเมนต์นั้น เป็นต้น คือมีหลายสถานการณ์จริงมาก
  • ประเด็นเรื่องการ เสริมความแข็งแกร่งให้เอเจนต์ ด้วย test suite น่าสนใจ อยากทราบว่าทำเป็นขั้นตอนแบบไหน ช่วยอธิบายรายละเอียดเพิ่มได้ไหม
• ยังไม่แน่ใจว่า AI agent จะถูกใช้อย่างแพร่หลายตามที่คนพูดกันใน LinkedIn หรือเปล่า แต่ก็ยังเปิดรับความเป็นไปได้นั้นอยู่ ตอนนี้ผมใช้ AI แบบ ควบคุมเข้ม อย่าง Claude Code, Cursor เหตุผลไม่ใช่เพราะโมเดลยังไม่ดีพอ แต่เพราะผมอยากใส่ ‘รสนิยม’ และทิศทางของตัวเองเข้าไปบ่อย ๆ มากกว่า การให้ AI มี อิสระมากขึ้น กลับไม่ค่อยน่าดึงดูดสำหรับผม เพราะผมรู้สึกถึงอัตลักษณ์และความเชื่อมโยงได้ก็ต่อเมื่อได้เข้าไปมีส่วนร่วม อนาคตถ้าวิธีทำงานเปลี่ยนหรือมี UX แบบใหม่เกิดขึ้น ผมอาจเปลี่ยนใจ แต่ตอนนี้ยังไม่อยากให้ AI มีความเป็น เอเจนต์ มากเกินไป
  • อยากรู้ว่าพอเวลาผ่านไปและเราเข้าใจพฤติกรรมของโมเดลมากขึ้น คุณคิดไหมว่าเพียงแค่ให้ context และ คำสั่ง ที่มากขึ้น/ดีขึ้น ก็อาจตอบโจทย์เรื่องรสนิยมและทิศทางของผู้ใช้ได้พอสมควร จากประสบการณ์ของผม แค่ prompt engineering ที่ออกแบบดี ๆ ก็ทำให้ AI ทำงานตามต้องการได้ในหลายเวิร์กโฟลว์ จนไม่ต้องคอยแทรกแซงบ่อยนัก
  • เห็นด้วยอย่างยิ่ง ผมเคยเขียนคอมเมนต์คล้าย ๆ กันที่อื่นด้วย และคิดว่าสุภาษิตเก่าว่า ‘ของฟรีไม่มีในโลก’ ยังใช้ได้อยู่ ถ้า LLM แก้ปัญหาได้โดยไม่ต้องมีมนุษย์อยู่ในวงเลย ก็เท่ากับว่าทุกคนสามารถสร้างระบบที่ซับซ้อนแบบเดียวกันได้ด้วย prompt ไม่กี่บรรทัด และเมื่อถึงจุดนั้นความแตกต่างหรือ คุณค่า ของแต่ละระบบก็จะหายไป ถ้า prompt คือ ระดับนามธรรมใหม่ เช่น บอก Claude ว่า “ช่วยสร้างแอปจดโน้ตให้หน่อย” แล้วมีคนหลายล้านคนพิมพ์ prompt ต้นทุนต่ำแบบเดียวกัน คำถามคือ คนเขียน prompt เพิ่มความหมายอะไรเข้าไปกันแน่
  • ผมคิดว่าเมื่อเวลาผ่านไป องค์ประกอบของ ‘รสนิยม’ แต่ละอย่างก็น่าจะถูกทำให้เป็นระบบในรูปของ prompt ได้มากขึ้นเรื่อย ๆ เช่น มี prompt หนึ่งที่กำกับว่าเวลาแก้โค้ดอย่าสร้าง ความเปลี่ยนแปลงโดยไม่จำเป็น และถ้าทำได้ก็ให้เขียนแบบ immutable อีก prompt หนึ่งก็กำหนดมาตรฐานเรื่องหลีกเลี่ยงการเขียน log ที่ไร้ประโยชน์ (ในแบบที่ผมนิยามไว้โดยเฉพาะ) ตอนรีวิวการแก้โค้ด ผมจะรัน prompt ทั้งหมดเหล่านี้ แยกกันทีละตัว แล้วรวบรวมเป็นผลลัพธ์ MCP แบบมีโครงสร้าง จากนั้นนำสิ่งเหล่านี้ไปใช้กับ code-agent เพื่อให้เกิดลูป รีวิวอัตโนมัติ ถ้ามีกรณีที่ต้องเพิ่ม context ด้วยมือ ก็จะสร้าง prompt ใหม่หรือขยาย prompt เดิมเพื่อเสริมเข้าไป
• น่าสนใจดีที่มี ‘ผู้เชี่ยวชาญ’ โผล่ขึ้นมาในสาขาที่ดูเหมือนจะมีอายุแค่ 1-2 ปี มันเหมือนเวอร์ชันกลับด้านของมีม ‘ภาษาอายุ 2 ปี แต่ต้องการคนมีประสบการณ์ 10 ปี’
  • ผมสร้างสิ่งที่เรียกว่า ‘ai agent’ มาตั้งแต่ตอน GPT-3 ออกมาแล้ว และก็มีอีกหลายคนที่มีประสบการณ์แบบเดียวกัน ผ่านมา 5 ปี แล้ว ถ้าผ่านไป 5 ปีแล้วยังไม่มีผู้เชี่ยวชาญเกิดขึ้น ผมว่าก็คงแปลว่าไม่มีผู้เชี่ยวชาญจริง ๆ นั่นแหละ แน่นอนว่าช่วงนี้คำว่า ‘เอเจนต์’ กำลังกลายเป็น buzzword จนความหมายเริ่มเลือน
  • พออ่านเรื่องเล่าประมาณ “ผมทำงานกับหลายสิบทีม...” ก็แอบรู้สึกว่ามันดราม่าไปหน่อย
• สรุปแก่นคือ ถ้ามี solution ที่กำหนดไว้ล่วงหน้าอยู่แล้ว ก็ไม่จำเป็นต้องใช้งานเอเจนต์ (เช่น ‘pattern’ ที่บทความกล่าวถึง) โดยทั่วไปโปรแกรมเมอร์มักจะแนะนำวิธีแก้ที่ง่ายกว่าและเชื่อถือได้มากกว่าสำหรับปัญหาที่แก้ด้วยโปรแกรมได้ อนาคต AI อาจฉลาดพอจะ brute force ทุกปัญหาได้จริง แต่ตอนนี้มันมีแต่เพิ่มความซับซ้อน เหตุผลหนึ่งที่คนตื่นเต้นกับเอเจนต์ก็เพราะคนส่วนใหญ่รู้จัก LLM ผ่านการเป็น chat assistant และ chat assistant แบบนี้มักไม่มีวิธีแก้ตายตัว อีกทั้งปฏิสัมพันธ์ก็ซับซ้อน เลยเป็นพื้นที่ที่ เอเจนต์ แสดงศักยภาพได้จริง เช่น “หาคืนวันศุกร์ที่ใกล้ที่สุด แล้วส่งข้อความถาม Bob ว่าว่างเจอกันไหม” — กรณีแบบนี้มีข้อจำกัดถ้าจะเขียนโปรแกรมเผื่อทุกกรณีล่วงหน้า วิธีโต้ตอบกับ assistant แทบจะไร้ขีดจำกัด ทำให้ เอเจนต์ เหมาะกว่า
  • มันทำงานได้ดีมากเมื่อ ความเร็วในการตรวจสอบ เร็วกว่าการลงมือทำเอง แต่สำหรับผมยังยากที่จะเชื่อ AI ถ้าไม่ได้ตรวจทาน
• สงสัยว่าทำไมหลายตัวอย่างสุดท้ายถึงลงเอยที่ “วิธีส่งสแปมให้เร็วขึ้นและดีขึ้น” กันหมด
  • ก็เหมือนว่านั่นแหละคือตัวอย่างจริงไม่ใช่เหรอ แบบครอว์ล LinkedIn เพื่อหาคน แล้วส่งอีเมลสแปมที่ ‘personalized’
  • จะเปรียบก็เหมือน ล้อ ที่สุดท้ายก็หมุนไม่ได้ถ้าไม่มี น้ำมันหล่อลื่น
• นี่เป็นคำพูดที่ถูกต้องในช่วงปลายปี 2023 ถึงต้นปี 2024 แต่พอมาถึงราว ๆ mid 2025 ผมคิดว่ามันใช้ไม่ได้กับงานจำนวนมากแล้ว ถ้าใช้ SOTA LLM ทุกวันนี้ แต่ก่อนคนมักเรียก LLM ผ่านฟังก์ชันเป็นหลัก ซึ่งส่วนหนึ่งก็เพราะเลือกเครื่องมือผิด ทุกวันนี้ LLM ระดับท็อป (Gemini 2.5 Pro, Claude 4 ฯลฯ) ฉลาดมากจนมีความสามารถด้าน ‘instruction following’ และการเลือก tool ที่ดีมาก เครื่องมืออย่าง checklist, คำสั่ง delegate, การแตกงานย่อย ยังจำเป็นอยู่ แต่แนวทางแบบสร้าง คำสั่ง และกำหนด command ไว้ — โดยเฉพาะในสภาพแวดล้อม UI ที่ตั้งค่า tool command ได้ง่าย — มีความยืดหยุ่นกว่าและเป็นนามธรรมที่สูงกว่าเวิร์กโฟลว์ เวิร์กโฟลว์แบบภาพเองก็สุดท้ายยังเป็น การเขียนโปรแกรม ที่เปราะและปรับจูนยาก เรื่องนี้ทำไม่ได้เมื่อ 6-12 เดือนก่อน แต่ถ้า LLM ยังไม่ดีพอก็ยังใช้ไม่ได้เช่นกัน มองภาพใหญ่แล้ว โมเดลที่ทำ instruction following และ เชื่อมต่อ tool ได้ดีมีอยู่ไม่กี่ตัว จึงคุ้มที่จะใช้ เอเจนต์ กับโมเดลพวกนี้ ผมคิดว่าในอีก 1-2 ปีข้างหน้า จะเกิดกระแสใหญ่ของ เอเจนต์ ที่ใช้เบราว์เซอร์/คอมพิวเตอร์ พวกมันจะผสาน ระบบความจำ ที่ดีเข้ากับ ‘โหมดสาธิต/สังเกตการณ์’ เพื่อเรียนรู้ (บันทึก) วิธีที่ผู้ใช้ทำงานกับ UI และจะเรียนรู้กระบวนการที่เหมาะที่สุดจากคำสั่งด้วยวาจา/เอกสารของมนุษย์ด้วย
  • การมาของ โมเดลเอเจนต์ ที่ทรงพลังมากขึ้นในช่วงนี้ (เช่น Claude Opus 4) เปลี่ยนสถานการณ์ไปอย่างสิ้นเชิง ยังต้องมี context ที่ดีอยู่ แต่การเลือกใช้ tool ได้แม่นยำนั้นยอดเยี่ยมจริง ๆ
  • เทคนิคในโพสต์ต้นฉบับส่วนใหญ่คือการ 'โมเดลปัญหาเป็น data flow graph แล้วทำตามนั้น' ถ้าข้ามขั้นการโมเดลไปแล้วหวังว่า ‘เดี๋ยวมันคงจัดการเอง’ นั่นไม่ใช่ วิศวกรรม แต่เป็น ศรัทธา
• ตลอด 3 สัปดาห์ที่ผ่านมา ผมพยายามทำให้ เอเจนต์ ทำงานได้อย่างเสถียร แต่สุดท้ายก็ต้องหันกลับไปใช้ pattern ที่ง่ายกว่ามาก เอเจนต์ในตอนนี้ให้ความรู้สึกเหมือน ‘มือที่มีหกนิ้ว’ คือยังอยู่ในช่วงต้นของวิวัฒนาการ
• เวลามีคนเห็นอะไรอย่าง “ตัว coordinator ยอมแพ้ถ้านิยามงานไม่ชัด” แล้วสรุปว่า “งั้นทิ้ง coordinator ไปเลยแล้วใช้ imperative logic” ผมคิดว่าจริง ๆ แล้วมันอาจเป็นปัญหาที่แก้ได้ด้วยการเขียน prompt หรือคำอธิบาย tool ให้เฉพาะเจาะจงขึ้น และเพิ่มขั้นตอนอย่าง สรุประหว่างทาง หรือ การบีบอัด context ของ LLM เข้าไป ถ้าในบทความไม่มีแม้แต่ตัวอย่าง prompt/คำอธิบาย tool แบบยาวที่เอาไปใช้จริงได้ ก็ประเมินได้ยาก โดยสัญชาตญาณแล้ว การใช้ orchestration ที่เหมาะกับงานน่าจะเป็นคำตอบ แต่ในทางปฏิบัติผมเชื่อว่ามีงานอีกมากที่ orchestration แบบเอเจนต์ ใช้ได้อย่างมีประสิทธิภาพ
• ผมเห็นด้วย 100% เอเจนต์ สนุกมากและเหมาะกับการทดลอง แต่ถ้าจะเพิ่ม productivity จริง ๆ แก่นสำคัญคือการ orchestrate เวิร์กโฟลว์และกระบวนการเฉพาะให้ดี และโฟกัสกับส่วนที่ AI เท่านั้นที่ทำได้ อ้างอิงเพิ่มเติม แนะนำบทความเรื่อง AI workflow ของ ai.intellectronica.net
• ช่วงนี้สิ่งที่เห็นบ่อยคือมีการนำ LLM เข้าไปใส่ใน เครื่องมือ orchestration เวิร์กโฟลว์ เดิม ทำให้สร้างระบบได้ง่ายขึ้นมาก ความซับซ้อนส่วนใหญ่อยู่ที่ a) ตัวโมเดลเอง (แลบชั้นนำทำให้โมเดลใช้งานง่าย), b) การทำเวิร์กโฟลว์ให้ พร้อมใช้ในโปรดักชัน (เครื่องมือเวิร์กโฟลว์ช่วยให้ง่าย) เวิร์กโฟลว์เหล่านี้อิงอยู่กับงานเดิมอยู่แล้ว จึงมองเห็นและวัด คุณค่า ได้ง่าย รูปแบบนี้มีมากขึ้นจนเราแพ็กเป็น SDK สำหรับ Airflow (เครื่องมือเวิร์กโฟลว์ที่ได้รับความนิยมมาก) แล้วปล่อยออกมาเลย
  https://github.com/astronomer/airflow-ai-sdk

[sto1111]

ตอนนี้ผมก็กำลังทำ Computer-use Agent ชื่อว่า UseDesktop อยู่เหมือนกัน

https://youtu.be/aBkbsvMxP_A?si=uaugxKQEu4ZEz7jq

usedesktop.com

ดังนั้นผมจึงเห็นด้วยเป็นส่วนใหญ่ครับ

ในบทความนี้ไม่ได้ลงลึกเป็นเคล็ดลับเชิงปฏิบัติมากนัก แต่พูดถึงภาพรวมเป็นหลัก ถ้าจะเสริมทิปส์อีกสักหน่อยตอนพัฒนา agentic/agent ที่อิง LLM สุดท้ายแล้ว LLM ก็ยังอยู่บนพื้นฐานของทรานส์ฟอร์เมอร์ (กล่าวคือเป็นการอนุมานเชิงความน่าจะเป็น อาศัยโทเคน/สถานะปัจจุบันเพื่อสร้างโทเคนถัดไป ไม่ได้ “เข้าใจ” บริบท/ความหมายแล้วพูดคำถัดไปออกมา แต่เป็นการสร้างเอาต์พุตตามความน่าจะเป็น) ดังนั้นต่อให้เขียน sys prompt ดีแค่ไหน ก็ยังมีหลายครั้งที่มันไม่ตอบในแบบที่ต้องการ (เช่น สั่งให้ตอบเป็น JSON output แต่บางทีก็ลืม } เป็นต้น) เพราะฉะนั้นการเพิ่ม fallback fn หลายชั้นที่อิง regex จึงแทบจะเป็นสิ่งจำเป็นเสมอ

อีกอย่าง ถ้าเขียน sys prompt เพื่อให้ได้ structured output ปกติก็มักจะใช้ non reasoning model และยิ่ง context ยาวมากเท่าไร hallucination ก็ยิ่งเกิดบ่อยขึ้น ดังนั้นแทนที่จะยัดทุกอย่างไว้ใน prompt เดียว การทำ sys prompt หลายชุดแล้ว chain กันมักจะดีกว่า

ถ้าพัฒนาเป็นบริการจริง เนื่องจากอาจเกิดข้อผิดพลาดได้หลากหลาย การออกแบบสถาปัตยกรรมให้เป็นแบบแยกโมดูลและ fault tolerant คือหัวใจสำคัญ (เช่น ให้ supervisor agent เป็น async และ agent ที่เหลือเป็น sync) โดยเฉพาะกับระบบแบบ agentic หรือ agent ที่มักมี unexpected output เกิดขึ้นบ่อย
ดังนั้นตั้งแต่เริ่มเขียนโค้ดก็ควรรักษา SRP และเขียนในลักษณะ declarative ให้มากที่สุด ผมเลยอยากบอกว่าการเข้าหาแบบฟังก์ชันจะดีกว่า (= ไม่มี side effect และ flow ตรงไปตรงมาเข้าใจง่าย)

แล้วก็ขึ้นอยู่กับว่าจะใช้ LLM ผ่าน API หรือจะเสิร์ฟโมเดลเองโดยตรง แต่ถ้าจะเสิร์ฟ SLM หรือ LLM เอง ไม่ควรทำ model serving บนเซิร์ฟเวอร์เดียวกับที่โฮสต์แบ็กเอนด์ ควรแยก IO bound task กับ CPU bound tasks (กล่าวคือ งานที่ต้องใช้ GPU, matrix multiplication ฯลฯ) ไปไว้คนละเซิร์ฟเวอร์ จะ fault tolerant กว่าและดีกว่า (เช่น โฮสต์งาน CPU bound บน runpod)

จริง ๆ ยังมีทิปส์การพัฒนาอีกหลายอย่าง แต่กลัวว่าจะยาวเกินไป เลยขอเขียนไว้แค่นี้ก่อน

หวังว่าจะเป็นประโยชน์กับใครสักคนครับ

[jypark]

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