เมื่อ AI หลายตัวทำงานเป็นทีม บทเรียนจาก Dev Signal
ระบบปัญญาประดิษฐ์ที่เขียนบทความแทนคุณได้ตั้งแต่ต้นจนจบ
มีนักพัฒนาคนหนึ่งสร้างระบบที่ค้นหาคำถามจากอินเทอร์เน็ต ค้นคว้าคำตอบจากเอกสารทางการ และเขียนบล็อกพร้อมรูปภาพ โดยที่เขาไม่ต้องทำอะไรเลย ใช้เวลาสองวัน บทความนี้สำรวจว่าเขาทำได้อย่างไร และมันบอกอะไรเราบ้างเกี่ยวกับทิศทางของการพัฒนาซอฟต์แวร์ยุคนี้
มีคำถามที่วนเวียนอยู่ในหัวของนักพัฒนาหลายคนในช่วงสองสามปีที่ผ่านมา ว่าถ้าปัญญาประดิษฐ์ทำงานแทนเราได้ เราควรให้มันทำอะไรก่อน?
Shir Meir Lador วิศวกรจาก Google ตอบคำถามนั้นด้วยการลงมือทำ เขาสร้างระบบชื่อ Dev Signal ที่ทำงานวนซ้ำโดยอัตโนมัติ ค้นหาคำถามยอดนิยมในชุมชนนักพัฒนา ค้นคว้าคำตอบที่ถูกต้อง แล้วเขียนบทความเทคนิคพร้อมรูปภาพหัวบทความออกมาในแต่ละรอบ
สิ่งที่น่าทึ่งไม่ใช่ว่ามันทำได้ เพราะปัญญาประดิษฐ์ทำแบบนั้นมานานแล้ว แต่คือมันทำได้ดีพอที่จะใช้งานจริง และใช้เวลาสร้างแค่สองวัน ซึ่งบอกว่าเครื่องมือในปี 2569 พัฒนาถึงจุดที่นักพัฒนาคนเดียวสามารถสร้างระบบระดับนี้ได้ โดยไม่ต้องมีทีมขนาดใหญ่หรืองบประมาณมหาศาล
แต่สิ่งที่น่าสนใจมากกว่าตัวระบบคือวิธีคิดเบื้องหลังการออกแบบ เพราะมันสะท้อนแนวทางที่กำลังกลายเป็นมาตรฐานใหม่ในวงการ ไม่ใช่การสร้างปัญญาประดิษฐ์ที่ฉลาดขึ้นเรื่อยๆ แต่คือการให้ปัญญาประดิษฐ์หลายตัวทำงานร่วมกันได้ดีขึ้น
1. ทีมงานที่ดีกว่าอัจฉริยะคนเดียว
ลองนึกถึงร้านอาหารดีๆ สักแห่ง มันไม่ได้มีพ่อครัวคนเดียวที่รับออร์เดอร์ ล้างจาน หั่นผัก ทอดปลา จัดจาน และเสิร์ฟพร้อมกัน แต่มีทีมที่แต่ละคนทำในสิ่งที่ตัวเองถนัด ส่งต่องานให้กัน และทั้งหมดขับเคลื่อนด้วยระบบที่ประสานกันเป็นอย่างดี Dev Signal คิดแบบเดียวกันนั้น
ระบบนี้ไม่ได้ใช้ปัญญาประดิษฐ์ตัวเดียวทำทุกอย่าง แต่แบ่งงานออกเป็นห้าขั้นตอนที่ชัดเจน ขั้นแรกคือการค้นหาว่าคนกำลังถามอะไรบน Reddit ขั้นที่สองคือการค้นคว้าคำตอบที่น่าเชื่อถือจากเอกสารทางการของ Google Cloud ขั้นที่สามคือการเขียนบทความเทคนิค ขั้นที่สี่คือการสร้างรูปภาพหัวบทความ และขั้นที่ห้าคือการจำสไตล์และความชอบของเจ้าของระบบไว้ใช้ครั้งต่อไป
เหตุผลที่ต้องแบ่งแบบนี้แทนที่จะปล่อยให้ Agent ตัวเดียวทำทั้งหมด มาจากข้อจำกัดพื้นฐานของปัญญาประดิษฐ์ในปัจจุบัน เมื่องานซับซ้อนขึ้นและมีหลายขั้นตอน ปัญญาประดิษฐ์ตัวเดียวจะเริ่ม ‘ลืม’ สิ่งที่เกิดขึ้นก่อนหน้า โฟกัสผิดจุด และสุดท้ายให้ผลลัพธ์ที่ไม่สม่ำเสมอ แต่ถ้าแต่ละ Agent รับผิดชอบแค่งานเดียวของตัวเอง ปัญหานั้นก็หมดไป
2. MCP: มาตรฐานที่ทำให้ Agent เชื่อมต่อกับโลกได้
ก่อนจะเข้าใจว่า Dev Signal ทำงานได้อย่างไร ต้องเข้าใจก่อนว่า MCP คืออะไร เพราะมันคือกุญแจที่ทำให้ระบบนี้สร้างได้ในสองวัน ไม่ใช่สองเดือน
MCP ย่อมาจาก Model Context Protocol ฟังดูเป็นภาษาวิศวกรรม แต่แนวคิดเบื้องหลังนั้นง่ายมาก ลองนึกถึงสมัยก่อนที่โทรศัพท์แต่ละยี่ห้อใช้สายชาร์จคนละแบบ ซื้อโทรศัพท์ใหม่ก็ต้องซื้อสายชาร์จใหม่ด้วยเสมอ จนกระทั่ง USB-C กลายเป็นมาตรฐาน แล้วทุกอย่างก็ง่ายขึ้น MCP ทำสิ่งเดียวกันนั้นให้กับปัญญาประดิษฐ์และบริการต่างๆ
ในอดีต ถ้าอยากให้ปัญญาประดิษฐ์ดึงข้อมูลจาก Reddit ต้องเขียนโค้ดเชื่อมต่อกับ API ของ Reddit โดยเฉพาะ ถ้าอยากให้ค้นหาในเอกสาร Google Cloud ก็ต้องเขียนชุดใหม่ ถ้าอยากให้สร้างรูปภาพก็ต้องเขียนอีกชุด แต่ MCP เปลี่ยนทั้งหมดนั้น ตราบใดที่บริการนำเสนอตัวเองในรูปแบบ MCP Server ปัญญาประดิษฐ์ที่รองรับมาตรฐานนี้ก็เชื่อมต่อและใช้งานได้ทันที โดยที่นักพัฒนาไม่ต้องเขียนโค้ดเชื่อมต่อใหม่แม้แต่บรรทัดเดียว
ใน Dev Signal มีการใช้ MCP Server สามชนิดที่แตกต่างกัน ตัวแรกรันบนเครื่องท้องถิ่นและเชื่อมกับ Reddit API ตัวที่สองเป็นบริการออนไลน์ที่ให้ค้นหาในเอกสาร Google Cloud และตัวที่สามสร้างขึ้นเองสำหรับการสร้างรูปภาพด้วยปัญญาประดิษฐ์ สิ่งที่น่าสนใจคือทั้งสามตัวนี้ทำงานผ่านมาตรฐานเดียวกันทั้งหมด Agent ไม่จำเป็นต้อง ‘รู้’ ว่าแต่ละตัวอยู่ที่ไหนหรือทำงานอย่างไร มันแค่ส่งคำขอไปในรูปแบบมาตรฐาน แล้วรับผลลัพธ์กลับมา
3. ทำไมถึงต้อง ‘จำ’ และ ‘เรียนรู้’
หนึ่งในส่วนที่สำคัญที่สุดของ Dev Signal ไม่ใช่ส่วนที่ฉลาดที่สุดหรือซับซ้อนที่สุด แต่คือส่วนที่ดูเหมือนเล็กน้อย นั่นคือระบบความทรงจำระยะยาว
ปัญญาประดิษฐ์ส่วนใหญ่ในปัจจุบันมีปัญหาเรื่องความต่อเนื่อง ทุกครั้งที่เปิดหน้าต่างสนทนาใหม่ มันลืมทุกอย่าง ลืมว่าคุณชอบอะไร ลืมว่าครั้งที่แล้วคุณบอกว่าอะไรไม่ดี และลืมว่าสไตล์การเขียนของคุณเป็นแบบไหน ทำให้ทุกครั้งที่ใช้งานต้องเริ่มต้นใหม่ ซึ่งเป็นปัญหาใหญ่สำหรับระบบที่ต้องทำงานซ้ำๆ บ่อยๆ
Dev Signal แก้ปัญหานี้ด้วย Vertex AI Memory Bank ซึ่งเป็นบริการเก็บความทรงจำของ Agent ไว้บนคลาวด์ เมื่อเจ้าของให้ข้อเสนอแนะว่าอยากให้บทความยาวขึ้น หรือใช้ตัวอย่างโค้ดมากขึ้น หรือเขียนในโทนที่เป็นกันเองมากขึ้น ระบบจะเก็บข้อมูลนั้นไว้ และนำมาใช้ในการสร้างบทความครั้งต่อไปโดยอัตโนมัติ โดยไม่ต้องบอกซ้ำ
ถ้ามองในแง่ใหญ่กว่านั้น นี่คือก้าวสำคัญจาก ‘ปัญญาประดิษฐ์ที่ใช้งานได้’ ไปสู่ ‘ปัญญาประดิษฐ์ที่รู้จักคุณ’ และความแตกต่างนั้นมีความหมายมากในทางปฏิบัติ เพราะเครื่องมือที่ดีขึ้นทุกครั้งที่ใช้งาน ต่างจากเครื่องมือที่เก่งแต่ไม่เคยเรียนรู้อย่างสิ้นเชิง
4. สิ่งที่โปรเจกต์นี้บอกเราเกี่ยวกับอนาคต
ถ้ามองข้ามรายละเอียดทางเทคนิคออกไป Dev Signal กำลังบอกอะไรเราบ้าง? ผมมองว่ามันบอกสิ่งสำคัญสี่อย่าง ที่นักพัฒนาและองค์กรที่กำลังคิดเรื่องปัญญาประดิษฐ์ควรรับรู้
อย่างที่ 1 เส้นแบ่งระหว่าง ‘เครื่องมือ’ และ ‘ผู้ช่วย’ กำลังเลือนหาย
Dev Signal ไม่ใช่เครื่องมือที่คุณเปิดมาแล้วใช้ มันทำงานเองในพื้นหลัง สแกนหาโอกาส ค้นคว้า และผลิตงานออกมาโดยที่คุณไม่ต้องนั่งคอยกำกับ นั่นคือนิยามของ ‘ผู้ช่วย’ มากกว่า ‘เครื่องมือ’ และเมื่อบทบาทของปัญญาประดิษฐ์เปลี่ยนไปแบบนี้ วิธีที่เราคิดเรื่องการออกแบบระบบก็ต้องเปลี่ยนตามด้วย
อย่างที่ 2 มาตรฐานกลางสำคัญกว่าความสามารถของแต่ละชิ้น
สิ่งที่ทำให้ Dev Signal สร้างได้เร็วไม่ใช่ว่าแต่ละ Agent ฉลาดมาก แต่คือ MCP ทำให้ทุกอย่างเชื่อมกันได้ง่าย ถ้าไม่มีมาตรฐานกลาง นักพัฒนาต้องใช้เวลาส่วนใหญ่ไปกับการเขียนโค้ดเชื่อมต่อ แทนที่จะโฟกัสกับตัวปัญหาที่อยากแก้ บทเรียนนี้ใช้ได้กับการออกแบบระบบทุกประเภท ไม่ใช่แค่ปัญญาประดิษฐ์
อย่างที่ 3 สองวันบอกอะไรบ้าง
สมัยก่อน ระบบที่ซับซ้อนระดับนี้ต้องใช้ทีมและเวลาเป็นเดือน วันนี้นักพัฒนาคนเดียวทำได้ในสองวัน นั่นไม่ได้แปลว่าระบบสมบูรณ์พร้อมใช้งานระดับ Production ทันที แต่มันบอกว่าต้นทุนในการทดลองลดลงอย่างมีนัยสำคัญ และนั่นหมายความว่าองค์กรที่อยากทดลองสร้างระบบ Agent ไม่จำเป็นต้องรอให้ทุกอย่างพร้อม สามารถเริ่มเล็กๆ วัดผล แล้วขยายได้
อย่างที่ 4 Dev Signal น่าสนใจไม่ใช่เพราะมันทำอะไรได้พิเศษ แต่เพราะมันแสดงให้เห็นว่าสิ่งที่เคยต้องการทีมใหญ่และเวลานาน วันนี้ทำได้ด้วยคนคนเดียวและเครื่องมือที่มีอยู่แล้ว คำถามที่เหลืออยู่ไม่ใช่ว่า ‘ทำได้ไหม’ แต่คือ ‘เราจะออกแบบให้ดีแค่ไหน และรับผิดชอบต่อสิ่งที่มันผลิตออกมาอย่างไร’
บทสรุป
ระบบหลาย Agent ไม่ใช่ความซับซ้อนที่ไม่จำเป็น มันแก้ปัญหาจริงของปัญญาประดิษฐ์ตัวเดียวที่ทำงานซับซ้อนไม่ได้ดี เมื่อแต่ละ Agent รับผิดชอบงานชัดเจน ผลลัพธ์โดยรวมดีขึ้นและสม่ำเสมอกว่า
MCP เปลี่ยนวิธีคิดเรื่องการเชื่อมต่อ แทนที่จะถามว่า ‘จะเขียนโค้ดเชื่อมต่อกับบริการนี้ยังไง’ เราถามแค่ว่า ‘บริการนี้รองรับ MCP ไหม’ ซึ่งลดเวลาพัฒนาลงได้มาก และทำให้ระบบยืดหยุ่นขึ้น
ความทรงจำระยะยาวเปลี่ยนจาก ‘เครื่องมือ’ เป็น ‘ผู้ช่วย’ ระบบที่จำความชอบและปรับตัวตามการใช้งานจริงนั้นต่างจากแชทบอทธรรมดาอย่างสิ้นเชิง มันดีขึ้นทุกครั้งที่ใช้ ซึ่งเป็นพฤติกรรมที่เราคุ้นเคยจากเพื่อนร่วมงานที่ดี ไม่ใช่ซอฟต์แวร์
สองวันบอกว่าต้นทุนการทดลองต่ำลงแล้ว ไม่จำเป็นต้องรอให้พร้อม ลองสร้างเวอร์ชันเล็กๆ ก่อน วัดผล แล้วขยาย เครื่องมืออย่าง Google ADK และ MCP ทำให้กระบวนการนั้นเร็วกว่าที่เคยเป็น
คำถามที่ยังต้องคิดต่อ
เมื่อระบบสร้างเนื้อหาได้เองโดยอัตโนมัติ ใครรับผิดชอบต่อเนื้อหานั้น? และเราออกแบบให้มันผลิตงานที่มีคุณภาพและน่าเชื่อถือได้อย่างสม่ำเสมอได้อย่างไร? นั่นคือโจทย์ที่เทคโนโลยียังตอบให้ไม่ได้ทั้งหมด
เรียบเรียงโดย วุฒิภัทร ศรีสอาด
อ้างอิง
Shir Meir Lador สำหรับ Google AI, dev.to
https://dev.to/googleai/building-capabilities-for-a-multi-agent-system-with-google-adk-mcp-and-cloud-run-ab9
