- ระหว่างการพัฒนาโปรเจกต์ มักเกิดกระบวนการที่ค่อย ๆ พัฒนาจาก การเขียนสคริปต์แบบง่าย ไปสู่ การสร้างเอเจนต์ AI แบบอัตโนมัติ ซ้ำ ๆ
- เมื่อให้สิทธิ์เข้าถึงเครื่องมือแก่เครื่องมือที่กำลังพัฒนา โมเดลแบบสนทนาธรรมดาจะเปลี่ยนเป็น เอเจนต์ที่สามารถวางแผน·ลงมือทำ·วนซ้ำได้
- ลอจิกแบบตัวจำแนกหรือเงื่อนไข if/else สุดท้ายจะถูก แทนที่ด้วยโครงสร้างเอเจนต์ และ โครงสร้างเรียบง่ายที่ยึดการเรียกใช้เครื่องมือตามที่โมเดลเลือก มีความยืดหยุ่นและทรงพลังกว่า
- บทบาทของมนุษย์ย้ายจาก Human-in-the-Loop ไปเป็น Human-on-the-Loop และการกำหนดเป้าหมายกับ การตั้ง guardrails กลายเป็นงานสำคัญ
- สิ่งที่สำคัญกว่าความซับซ้อนของโค้ดคือ การจัดการความน่าเชื่อถือและการตัดสินใจ และเอเจนต์ก็กลายเป็นระบบที่เติบโตไปพร้อมกับนักพัฒนา
การลู่เข้าจากสคริปต์ง่าย ๆ ไปสู่เอเจนต์
- โปรเจกต์ AI ส่วนใหญ่ที่ทำในปี 2025 สุดท้าย ลงเอยในรูปแบบเอเจนต์
- สคริปต์แบบเรียบง่ายที่มีโครงสร้าง input·process·output ค่อย ๆ พัฒนาเป็นเอเจนต์ด้วยการ เพิ่มลูปการทำซ้ำ ชุดเครื่องมือ และการแยกวิเคราะห์ JSON
- คำนิยามของเอเจนต์ตามมุมมองของผู้เขียนคือ โมเดลที่รันผ่านลูปในสถานะที่เข้าถึงเครื่องมือได้
- กล่าวคือ หากมีเวลาเพียงพอ ทุกโปรเจกต์ AI จะลู่เข้าสู่เอเจนต์
แรงดึงดูดสู่ความเป็นอัตโนมัติ
- ไม่ใช่แค่ฟังก์ชันอัตโนมัติแบบพื้นฐานอีกต่อไป แต่ซอฟต์แวร์กำลังก้าวสู่ช่วงที่ ตัดสินใจและลงมือทำเองได้เหมือน ‘เด็กฝึกงานดิจิทัล’
- Gemini Scribe ตอนแรกเป็นเพียงปลั๊กอินแชตสำหรับ Obsidian แต่เมื่ออนุญาตให้เข้าถึงเครื่องมือ
read_file ก็สามารถ จัดการบริบทและดำเนินการได้ด้วยตัวเอง
- ผู้ใช้ไม่จำเป็นต้องจัดการอินพุตของโมเดลด้วยตนเองอีกต่อไป แต่เพียงส่ง คำสั่งระดับเจตนา อย่าง “อ่านบันทึกการประชุมแล้วสรุปให้หน่อย”
- การเปลี่ยนแปลงนี้หมายถึง การเปลี่ยนจากการสนทนาไปสู่การมอบหมายงาน และพัฒนาไปเป็นโครงสร้างที่เอเจนต์รับหน้าที่วางแผน·ลงมือทำ·วนซ้ำ
จากสคริปต์สู่ Sudoers
- ในกระบวนการพัฒนา Gemini CLI เช่นกัน เมื่อโมเดลใช้ เครื่องมือรันคำสั่ง ก็ขยายจากตัวสร้างโค้ดธรรมดาไปสู่ ผู้ปฏิบัติการอัตโนมัติ
- โมเดลสร้างลูปที่รันทดสอบ ตรวจจับความล้มเหลว แล้วแก้ไขด้วยตัวเองก่อนรันซ้ำ
- ระหว่างนั้น ปัญหาด้านความปลอดภัยและความน่าเชื่อถือ ก็เด่นชัดขึ้น ทำให้จำเป็นต้องมี ระบบนโยบายแยกสิทธิ์ แบบเดียวกับไฟล์
sudoers
- สคริปต์ธรรมดาไม่จำเป็นต้องมี policy engine แต่เอเจนต์ต้องมี guardrails เพื่อป้องกันข้อผิดพลาดในการตัดสินใจ
เอเจนต์ที่อยากเป็นตัวจำแนก
- ใน โปรเจกต์ Podcast RAG มีการสร้าง ตัวจำแนก AI เพื่อจำแนกเป้าหมายการค้นหาตามคำถามของผู้ใช้ แต่ก็พบข้อจำกัด
- ลอจิกการจำแนกไม่สามารถสะท้อนเจตนาของผู้ใช้ได้ครบถ้วน และเป็นการ ใช้โค้ดไปจำกัดการตัดสินใจที่โมเดลทำได้ดีอยู่แล้ว
- วิธีแก้คือถอดตัวจำแนกออก แล้วมอบเครื่องมือ
search_descriptions, search_episodes ให้เอเจนต์แทน
- เอเจนต์สามารถเลือกและใช้เครื่องมือหลายตัวควบคู่กันตามสถานการณ์ ทำให้ ค้นหาได้ยืดหยุ่นกว่าเดิม
- ใน Gemini Scribe ก็เช่นกัน มีการตัดลอจิกคาดเดาบริบทที่ซับซ้อนออก แล้วทำให้เรียบง่ายด้วย โครงสร้างเรียกใช้เครื่องมือเพื่ออ่านไฟล์เมื่อจำเป็น
- ผู้เขียนเสนอ เกณฑ์สำหรับนักพัฒนา ว่า “ถ้าคุณกำลังใช้ if/else เพื่อตัดสินว่า AI ควรทำอะไร แปลว่าคุณกำลังสร้างเอเจนต์อยู่แล้ว”
การเปลี่ยนผ่านสู่ Human-on-the-Loop
- บทบาทของมนุษย์เปลี่ยนจาก โครงสร้างที่ต้องอนุมัติทุกขั้นตอน ไปสู่ บทบาทผู้กำกับดูแลที่กำหนดเพียงเป้าหมายและขอบเขต
- เนื่องจากเอเจนต์ทำงานได้โดยไม่ต้องให้มนุษย์แทรกแซงอย่างต่อเนื่อง จึงจำเป็นต้อง กำหนดเป้าหมาย ขอบเขต และการจัดการข้อยกเว้นให้ชัดเจน
- หากไม่มี guardrails ที่เหมาะสม เอเจนต์ก็อาจ ติดค้างอยู่กับการรออินพุตหรือเดินไปตามเส้นทางที่ไม่ก่อผลลัพธ์
- มนุษย์ไม่ใช่ผู้ปฏิบัติการอีกต่อไป แต่เป็น ผู้กำกับดูแลและผู้ตั้งขอบเขต ที่คอยควบคุมทิศทางของระบบ
การยอมรับความซับซ้อน
- การสร้างเอเจนต์ไม่ได้ยากอย่างที่เห็นภายนอก และในทางกลับกันยังทำให้เรียบง่ายขึ้นได้ด้วยการ ลบลอจิกแตกแขนงตามเงื่อนไขและการจัดการข้อยกเว้น
- เพราะโมเดลตัดสินใจตามสถานการณ์ได้อยู่แล้ว จึงไม่จำเป็นต้องมีลอจิกคาดเดาไว้ล่วงหน้า
- ความซับซ้อนที่แท้จริงไม่ได้อยู่ที่โค้ด แต่อยู่ที่ การมอบหมายความไว้วางใจและการตัดสินใจ
- นักพัฒนาจึงควรโฟกัสที่การออกแบบเพื่อ ป้องกันความผิดพลาดในการตัดสินใจ มากกว่าข้อผิดพลาดทางไวยากรณ์
- ต่างจากสคริปต์แบบตายตัว เอเจนต์คือ ระบบที่วิวัฒน์ตามคำขอของผู้ใช้และค้นหาวิธีที่ดีกว่าไปเรื่อย ๆ
- เมื่อคุณเริ่มอยากเพิ่มนิยามเครื่องมือเข้าไปในสคริปต์ง่าย ๆ นั่นก็หมายความว่าคุณ ได้เข้าสู่ขั้นตอนการสร้างเอเจนต์แล้ว
ยังไม่มีความคิดเห็น