ชุมชนนักพัฒนา AI agent กำลังมาถึงข้อสรุปที่น่าประหลาดใจ: ความเรียบง่ายคือสิ่งที่ดีกว่า แม้ว่า framework อย่าง AutoGPT และ Autogen ของ Microsoft จะส่งเสริมระบบ multi-agent แต่นักพัฒนาที่มีประสบการณ์กลับพบว่าสถาปัตยกรรม single-agent ที่มีการจัดการ context ที่เหมาะสมให้ผลลัพธ์ที่เชื่อถือได้มากกว่า
ปัญหาการแบ่งปัน Context
ปัญหาหลักของระบบ multi-agent อยู่ที่การแยกส่วน context เมื่อ agent หลายตัวทำงานในส่วนต่างๆ ของงานเดียวกัน พวกมันมักจะตัดสินใจที่ขัดแย้งกันโดยไม่รู้ว่า agent ตัวอื่นๆ กำลังทำอะไรอยู่ การสนทนาในชุมชนเผยให้เห็นว่าปัญหานี้ขยายไปเกินกว่าข้อจำกัดทางเทคนิค - มันเกี่ยวกับการรักษาการตัดสินใจที่สอดคล้องกันทั่วทั้งระบบ
นักพัฒนาคนหนึ่งแบ่งปันประสบการณ์ในการสร้าง recipe agent ที่เข้าถึงได้ผ่าน SMS โดยพบว่าปัญหาการจัดการ context เกิดขึ้นก่อนที่จะถึงขด จำกัด token แม้กระทั่ง วิธีแก้ปัญหาของพวกเขาคือการใช้ sub-agent เฉพาะทางเพื่อป้องกันข้อมูลล้นใน context ของ agent หลัก ซึ่งแสดงให้เห็นว่าการกรอง context เชิงกลยุทธ์อาจมีค่ามากกว่าการแบ่งปันทุกอย่าง
หลักการทางเทคนิคสำคัญสำหรับ AI Agents ที่เชื่อถือได้:
- หลักการที่ 1: แชร์บริบทและการติดตามตัวแทนแบบเต็มรูปแบบ ไม่ใช่เพียงแค่ข้อความแต่ละรายการ
- หลักการที่ 2: การกระทำมีการตัดสินใจโดยนัย และการตัดสินใจที่ขัดแย้งกันจะให้ผลลัพธ์ที่ไม่ดี
- ข้อจำกัดของ Context Window: ความน่าเชื่อถือของตัวแทนจะลดลงเมื่อใกล้ 50,000 โทเค็น แม้จะยังมีพื้นที่เหลืออยู่
- คำแนะนำด้านสถาปัตยกรรม: ตัวแทนเชิงเส้นแบบเธรดเดียวพร้อมการบีบอัดบริบทสำหรับงานที่ใช้เวลานาน
ความท้าทายด้านความเชื่อถือได้
ระบบ multi-agent ประสบปัญหาที่นักพัฒนาเรียกว่า compounding errors เมื่อ agent หนึ่งตีความงานผิด มันจะสร้างปัญหาต่อเนื่องที่ agent อื่นๆ ต้องหาทางแก้ไขอย่างใดอย่างหนึ่ง ชุมชนสังเกตเห็นว่าแม้แต่การสื่อสารผิดพลาดเล็กน้อยระหว่าง agent ก็สามารถนำไปสู่ผลลัพธ์ที่ใช้งานไม่ได้เลย
เรากำลังสร้าง context ด้วยมือเหมือนนักเขียนในยุคกลางทั้งที่เราควรจะสร้าง context compiler
ข้อมูลเชิงลึกนี้จากชุมชนเน้นการเปลี่ยนแปลงพื้นฐานในการคิด แทนที่จะจัดการ agent หลายตัว การใช้งานที่ประสบความสำเร็จมุ่งเน้นไปที่การสร้าง context optimization engine ที่ซับซ้อนซึ่งให้บริการหน่วยตัดสินใจเดียว
ตัวอย่างในอุตสาหกรรมและการประยุกต์ใช้ในโลกจริง
Claude Code เป็นตัวอย่างของแนวทาง single-agent แม้ว่าจะสร้าง subtask ได้ แต่ไม่เคยรันแบบ parallel และ sub-agent ถูกจำกัดให้ตอบคำถามแทนที่จะตัดสินใจ การออกแบบนี้ป้องกันความขัดแย้งใน context ที่รบกวนระบบ multi-agent ที่ซับซ้อนกว่า
ชุมชนยังสังเกตเห็นปัญหากับ edit apply model - ระบบที่ model หนึ่งสร้างคำสั่งและอีกตัวหนึ่งดำเนินการ สถาปัตยกรรมเหล่านี้มักจะล้มเหลวเนื่องจากความคลุมเครือในการสื่อสารระหว่าง agent ทำให้นักพัฒนาหลายคนรวมทั้งการตัดสินใจและการดำเนินการเข้าไว้ใน model เดียว
การเปรียบเทียบระบบหลายเอเจนต์กับเอเจนต์เดียว:
| ด้าน | ระบบหลายเอเจนต์ | ระบบเอเจนต์เดียว |
|---|---|---|
| การแชร์บริบท | แยกส่วน เสี่ยงต่อความขัดแย้ง | ต่อเนื่อง สอดคล้องกัน |
| การแพร่กระจายของข้อผิดพลาด | ข้อผิดพลาดสะสมข้ามเอเจนต์ | จำกัดอยู่ในบริบทเดียว |
| ความน่าเชื่อถือ | ต่ำเนื่องจากการสื่อสารผิดพลาด | สูงกว่าด้วยการจัดการบริบทที่เหมาะสม |
| ความซับซ้อน | ค่าใช้จ่ายในการประสานงานสูง | สถาปัตยกรรมที่เรียบง่ายกว่า |
| การประมวลผลแบบขนาน | เป็นไปได้ในทางทฤษฎีแต่มีปัญหา | เป็นลำดับแต่เชื่อถือได้ |
เส้นทางข้างหน้า
นักพัฒนาที่มีประสบการณ์กำลังมาบรรจบกันในปรัชญา single agent plus tools แนวทางนี้ถือว่าฟังก์ชันเฉพาะทางเป็นเครื่องมือแทนที่จะเป็น agent อิสระ โดยรักษาการตัดสินใจแบบรวมศูนย์ในขณะที่ยังคงเปิดใช้งานฟังก์ชันที่ซับซ้อน
การสนทนาเผยให้เห็นว่านักสร้าง agent ที่ประสบความสำเร็จมุ่งเน้นไปที่ context engineering - ศิลปะของการจัดการแบบไดนามิกว่าข้อมูลใด agent เห็นและเมื่อใด ซึ่งรวมถึงการพัฒนาเทคนิคการบีบอัด context สำหรับงานที่ยาวขึ้นและการสร้างระบบที่สามารถรักษา coherent reasoning chain ได้แม้ในขณะที่การสนทนาขยายเกิน 50,000 token
แม้ว่าสัญญาของระบบ multi-agent แบบร่วมมือยังคงน่าสนใจ แต่ความเป็นจริงในปัจจุบันคือพวกมันสร้างปัญหามากกว่าที่จะแก้ไข ฉันทามติของชุมชนชี้ให้เห็นว่าจนกว่าเราจะแก้ไขความท้าทายพื้นฐานในการแบ่งปัน context สถาปัตยกรรม single-agent ที่มีเครื่องมือที่ซับซ้อนแสดงถึงเส้นทางที่ปฏิบัติได้มากที่สุดสู่ระบบ AI ที่เชื่อถือได้
อ้างอิง: Don't Build Multi-Agents