ทำไมเฟรมเวิร์ก AI Agent ถึงซับซ้อน? เราต้องการเฟรมเวิร์กปฏิวัติวงการแบบ Rails

ปัญหาหลักของเฟรมเวิร์ก AI Agent ในปัจจุบัน

• หน้าต่างคอนเท็กซ์หมดลง
  • เมื่อทำงานซับซ้อน โมเดลจะลืมเป้าหมายเดิม
  • เกิดอาการ hallucination และลูปไม่รู้จบ
• เฟรมเวิร์กทำหน้าที่เป็นเพียง wrapper แบบบาง
  • โยนภาระให้ผู้พัฒนาเลือกโมเดล, ผู้ให้บริการ embedding, การจัดโครงสร้างเครื่องมือ ฯลฯ
  • ขัดกับหลักการ "อย่าทำให้ต้องคิด"
• ความสับสนจากการมีเครื่องมือมากเกินไป
  • สิ้นเปลืองคอนเท็กซ์ไปกับการประเมินตัวเลือกที่ไม่จำเป็น

โซลูชันที่เสนอ: สถาปัตยกรรมที่ยึด sub-agent เป็นศูนย์กลาง

• ใช้ sub-agent เป็นพลเมืองชั้นหนึ่งของระบบ
  • มอบหมายงานได้อย่างเป็นธรรมชาติเหมือน function call
  • มีคอนเท็กซ์แยกเป็นอิสระ → ช่วยให้เอเจนต์แม่คงสมาธิไว้ได้
  • ตัวอย่าง: sub-agent สำหรับค้นหาโค้ดเบส → คืนกลับมาเฉพาะพาธไฟล์ที่เกี่ยวข้อง
• ผลลัพธ์
  • เอเจนต์เดี่ยว: ใช้คอนเท็กซ์ไป 90%
  • ใช้ sub-agent: ใช้คอนเท็กซ์ของเอเจนต์แม่เพียง 25%

ประยุกต์บทเรียนจาก Rails: Convention over Configuration

• ให้ความสำคัญกับคอนเวนชันเริ่มต้น
  • เลือกโมเดลอัตโนมัติ (ตามความซับซ้อนของงาน)
  • งบประมาณคอนเท็กซ์สืบทอดจาก parent ไป child
  • สร้าง checkpoint อัตโนมัติสำหรับงานที่มีความเสี่ยง
• แนะนำ archetype
  • Searcher: ใช้เฉพาะเครื่องมือค้นหา
  • Writer: ใช้เฉพาะเครื่องมือเขียน
  • Researcher: เข้าถึงได้เฉพาะเว็บ → ป้องกันเครื่องมือมากเกินไป

หลักการออกแบบเชิงปฏิบัติ

• ออกแบบโดยยึดงานเป็นศูนย์กลาง
  • แทนที่จะถามว่า "จะใช้โมเดลอะไร?" ให้เริ่มจากงานจริง (เช่น ตรวจสอบฟอร์มสมัครสมาชิก) ก่อน
• ความชั่วคราวของคอนเท็กซ์ใน sub-agent
  • ส่งคืนให้ parent เฉพาะสรุปของงานระหว่างทาง
• แยกความต่างระหว่างเครื่องมือกับ sub-agent
  • เครื่องมือ: ไม่มีสถานะ (จัดรูปแบบวันที่, แยกวิเคราะห์ JSON)
  • sub-agent: ต้องมีการทำซ้ำและการตัดสินใจ (ค้นหา, วิเคราะห์)

การเลือกเทคโนโลยี: TypeScript

• เพิ่มความปลอดภัยของชนิดข้อมูล (Branded types, discriminated unions)
• เข้ากันได้กับ ecosystem ของเครื่องมือพัฒนา (เช่น VS Code)
• คอมไพล์เป็นไฟล์รันเดี่ยวได้ด้วย Bun

โจทย์ที่ยังไม่คลี่คลาย

• การแชร์คอนเท็กซ์ระหว่าง sub-agent (ฐานความรู้ของโปรเจกต์)
• การทำงานร่วมกันของเอเจนต์แบบเพื่อนร่วมงาน (ส่งต่อข้อความ)
• การประเมินเอเจนต์ (จับภาพและเล่นซ้ำสถานการณ์, วัดจากความสำเร็จ ความสม่ำเสมอ และความพึงพอใจ)

สรุป

• เฟรมเวิร์กไม่ควรเพิ่มความซับซ้อน แต่ควรมอบ "ความซับซ้อนที่ถูกต้อง"
• เฟรมเวิร์กที่ปฏิวัติวงการแบบ Rails สามารถเปลี่ยนโฉมการพัฒนาเอเจนต์ได้
• ลดงานเดินท่อระบบให้น้อยที่สุด → โฟกัสกับปัญหาหลัก

[ahwjdekf]

เฟรมเวิร์กเอเจนต์... ชื่อดูยิ่งใหญ่ แต่สุดท้ายก็เป็นแค่เครื่องมือที่ส่งต่อให้ llm เท่านั้น เป็นแค่เปลือกเปล่า

[click]

Rails สะดวกก็จริงเพราะบังคับใช้ convention และมี "เวทมนตร์" มากมายอยู่ใต้ abstraction layer แม้จะมี trade-off เรื่องประสิทธิภาพที่ลดลง แต่สิ่งนี้ไม่ได้ทำให้ต้องเสียเงินทันที
แต่ถ้าเฟรมเวิร์กเป็นคนเลือกโมเดลเองตามใจ ใครจะรับผิดชอบถ้าโดนค่าใช้โทเคนถล่ม...?

[nomak]

ในปี 2026 จะมีเครื่องมือใหม่ ๆ ออกมาบ้างไหมนะ? อาจจะไม่เหมือน Rails แต่มีการทำ abstraction มากขึ้นอีกหน่อย.. ขอลองคาดหวังดูครับ