Blackboard System: เมื่อปล่อยให้ AI Agent หลายตัวคอมมิตใน Repo เดียวกัน ระบบกระดานกลางก็เกิดขึ้นเอง
Thoughtworks ปล่อย AI Agent หลายตัวทำงานใน Git Repo เดียวกัน แล้วเกิดรูปแบบ Blackboard System ขึ้นมาเอง ไม่มีตัวสั่งการกลาง มีแค่กติกาสองข้อ
บริษัทเทคโนโลยีอย่าง Thoughtworks Europe เริ่มการทดลองให้ AI Agent ร่วมกันเขียนโค้ด โดยตั้งชื่อเล่นให้การทดลองนี้ว่า "hyper-agentic" แต่สิ่งที่เกิดขึ้นมาเองโดยไม่มีใครวางแผนไว้ คือระบบประสานงานแบบกระดานกลาง หรือ Blackboard System
ในการทดลองนี้ Thoughtworks รวมทีมวิศวกร 10 คนมาทำงานร่วมกันที่สำนักงานในเมืองบาร์เซโลนา โดยมีเป้าหมายคือให้ AI Agent หรือโปรแกรม AI ที่วางแผนและทำงานเองได้อัตโนมัติ รับผิดชอบงานเขียนโค้ดให้ได้มากที่สุดเท่าที่จะทำได้ โจทย์ที่ต้องสร้างคือระบบรับมือเหตุฉุกเฉินของสายการบินอย่าง IROps ที่ศูนย์ควบคุมการบินใช้จัดการเมื่อเกิดเหตุขัดข้อง เช่น เครื่องบินมีปัญหาทางเทคนิคจนต้องซ่อม หรือลูกเรือป่วยจนต้องหาคนมาแทน ระบบต้องช่วยตัดสินใจว่าจะยกเลิกเที่ยวบินไหน สลับเครื่องบินลำใด จัดหาลูกเรือใหม่แทนอย่างไร และส่งผู้โดยสารกลุ่มไหนไปพักโรงแรม โดยต้องคำนวณข้อมูลเครื่องบินหลายร้อยลำ ผู้โดยสารหลายแสนคน และลูกเรือที่กระจายตัวอยู่ตามสนามบินต่างๆ โจทย์นี้ซับซ้อนมากทั้งในเชิงตรรกะและการนำไปใช้งานจริง แต่ทีมนี้สร้างขึ้นมาได้สำเร็จภายในเวลาเพียง 4 วัน
ทว่าจุดที่น่าประหลาดใจไม่ใช่เรื่องความเร็ว แต่เป็นพฤติกรรมการประสานงานของ AI Agent ระหว่างที่ Agent หลายตัวทำงานร่วมกันใน Git repository หรือคลังเก็บโค้ดส่วนกลางที่เรียกกันสั้นๆ ว่า repo แต่ละตัวเริ่มแบ่งงานกันทำได้เองโดยไม่ต้องมีใครคอยสั่งการ ตัวหนึ่งจองหัวข้องานที่จะทำ อีกตัวเห็นก็ขยับไปทำหัวข้ออื่นแทน และเมื่องานชิ้นแรกเสร็จ ตัวที่รองานอยู่ก็หยิบไปทำต่อได้ทันที รูปแบบการทำงานร่วมกันที่เกิดขึ้นมาเองนี้ตรงกับแนวคิดทางสถาปัตยกรรมซอฟต์แวร์ที่มีมาตั้งแต่ปี 1980 อย่างระบบกระดานกลาง หรือ blackboard system
กติกาสองข้อที่ตั้งขึ้นคนละจุดประสงค์ แต่ผลลัพธ์กลับมาบรรจบกันพอดี
ทีมพัฒนาเลือกใช้ระบบ Monorepo ที่รวมโค้ดทุกส่วนไว้ใน repository เดียวกัน และให้ทุกคนรวมถึง Agent ทั้งหมดเริ่มทำงานพร้อมกัน แต่เมื่อมี Agent หลายตัวเข้ามาแก้ไขไฟล์ในที่เดียวกันพร้อมๆ กัน ปัญหาที่ตามมาคือ Build Pipeline ซึ่งเป็นระบบบิลด์และทดสอบโค้ดอัตโนมัติทุกครั้งที่มีโค้ดใหม่เข้ามา
ทีมจึงตั้งกติกาข้อแรกขึ้นมาแก้ปัญหานี้ โดยกำหนดให้ Agent แต่ละตัวต้องบันทึกงานหรือคอมมิตโค้ดบ่อยๆ และคอยดึงโค้ดล่าสุดจาก branch หลักกลับมารวมกับงานของตัวเองอย่างต่อเนื่อง เพื่อให้เจอปัญหาบิลด์พังตั้งแต่ในเครื่องตัวเอง แทนที่จะปล่อยให้โค้ดต่างคนต่างแยกกันไปไกลแล้วค่อยมาแก้ปัญหาใหญ่ทีเดียวในตอนท้าย แม้ว่าการป้องกันไม่ให้ Agent ทำงานชนกันจะมีวิธีอื่น เช่น การแยก git worktree ให้ Agent แต่ละตัว แต่ทีมนี้เลือกใช้วิธีรวมโค้ดให้บ่อยที่สุดแทน
ส่วนกติกาข้อที่สองมีจุดประสงค์ต่างออกไปโดยสิ้นเชิง นั่นคือให้ Agent แต่ละตัวเขียนแผนการทำงานของตัวเองออกมาก่อนลงมือทำ โดยแผนงานต้องอ้างอิงเลขหัวข้อตามเอกสารสเปกกลางฉบับเดียวกัน จากนั้นให้บันทึกไฟล์แผนงานเก็บไว้ใน repo แล้วคอยอัปเดตสถานะความคืบหน้าลงในไฟล์อย่างสม่ำเสมอ แนวคิดการเขียนสเปกให้ชัดเจนก่อนให้ Agent เริ่มทำงานเป็นทิศทางเดียวกับที่เครื่องมืออย่าง Spec Kit ของ GitHub กำลังผลักดัน
จุดสำคัญอยู่ตรงที่กติกาทั้งสองข้อนี้ไม่มีข้อไหนพูดถึงการประสานงานระหว่าง Agent เลยแม้แต่น้อย ข้อแรกตั้งขึ้นมาเพื่อแก้ปัญหาบิลด์สะดุด ส่วนข้อสองตั้งขึ้นมาเพื่อคุมขอบเขตงาน แต่เมื่อนำกติกาสองข้อนี้มาใช้ร่วมกัน ไฟล์แผนงานก็ติดไปกับทุกๆ คอมมิต แล้วส่งต่อไปถึง Agent ตัวอื่นๆ เองทุกครั้งที่ดึงโค้ดล่าสุดมารวมกัน
Evaluator กับ Search: สองงานที่สอดประสานกันได้เองผ่านไฟล์แผน
ตัวอย่างที่เห็นภาพชัดเจนที่สุดคือ การทำงานร่วมกันระหว่างโมดูลสองส่วนที่ต้องพึ่งพาข้อมูลกัน โดย Agent ตัวแรกมีหน้าที่สร้าง Evaluator เพื่อตรวจสอบว่า แผนกู้คืนตารางบินนั้นใช้งานได้จริงหรือไม่ ผิดเงื่อนไขบังคับหรือเงื่อนไขที่ยืดหยุ่นได้หรือไม่ ส่วน Agent อีกตัวสร้าง Search Algorithm สำหรับค้นหาแผนแก้ปัญหาตารางบิน ซึ่ง Search Algorithm จำเป็นต้องเรียกใช้ Evaluator เพื่อประเมินว่า แผนที่ค้นพบนั้นผ่านเกณฑ์หรือไม่ แม้โค้ดทั้งสองส่วนนี้จะเขียนแยกกันได้ แต่ทั้งคู่มีจุดเชื่อมต่อที่ต้องตรงกัน และฝั่ง Search จะทำงานให้เสร็จสมบูรณ์ไม่ได้เลยถ้าโค้ดฝั่ง Evaluator ยังไม่พร้อมใช้งาน
สิ่งที่เกิดขึ้นคือ ไฟล์แผนงานของ Agent ทั้งสองตัวต่างระบุจุดเชื่อมต่อนี้ไว้ ฝั่ง Evaluator บันทึกไว้ว่าเมื่อสร้างตัวตรวจจริงเสร็จ จะย้อนกลับไปแก้ทุกจุดให้หันมาเรียกตัวตรวจจริง ส่วนฝั่ง Search ก็บันทึกไว้ว่า เมื่อตัวตรวจจริงมาถึงเมื่อไร ให้ใส่การเรียกใช้งานตัวตรวจจริงเข้าไปตรงจุดนั้น และเนื่องจากไฟล์แผนงานเหล่านี้ติดไปกับคอมมิตอยู่ตลอดเวลา Agent ทั้งสองตัวจึงมองเห็นแผนงานและความคืบหน้าของอีกฝ่ายได้เสมอ
ผลลัพธ์ที่ตามมาคือ เมื่อ Agent ตัวหนึ่งทำเครื่องหมายในแผนงานว่ากำลังลงมือทำส่วนนี้อยู่ Agent อีกตัวที่เห็นข้อความก็จะหลบไปทำส่วนอื่นก่อน และเมื่อส่วนนั้นเสร็จ Agent ที่รออยู่ไม่เพียงรู้ว่างานเสร็จแล้ว แต่ยังได้อ่านบันทึกสั้นๆ สรุปวิธีทำงานที่อีกฝ่ายเขียนทิ้งไว้ด้วย ทำให้หยิบงานไปต่อยอดได้ทันที เมื่อทีมงานเห็นเช่นนั้น จึงตั้งใจนำรูปแบบนี้มาใช้ประโยชน์ต่อ ตัวอย่างเช่น ระหว่างที่กำลังสร้างระบบประเมินค่าใช้จ่ายอย่าง Cost Model ควบคู่ไปกับตัวตรวจ ทีมงานสั่งให้ Agent ฝั่งตัวตรวจคอยอ่านแผนงานและโค้ดใน repo อยู่เสมอ พอฝั่ง Cost Model ส่งโค้ดเข้ามา Agent ฝั่งตัวตรวจก็เริ่มเชื่อมต่อระบบได้ทันทีโดยไม่ต้องรอให้คนมาบอก
Blackboard System: แนวคิดกระดานกลางที่มีมาตั้งแต่ปี 1980
รูปแบบการทำงานที่ทีม Thoughtworks ค้นพบนี้มีชื่อเรียกและนิยามมานานแล้ว นั่นคือ blackboard system หรือระบบกระดานกลาง หากอธิบายให้เข้าใจง่ายที่สุดคือ พื้นที่หน่วยความจำส่วนกลางที่ Agent อิสระหลายตัวเข้ามาอ่านและเขียนข้อมูลร่วมกันได้โดยไม่ต้องขึ้นตรงต่อกัน ข้อมูลบนกระดานจะมีโครงสร้างขั้นต่ำที่กำหนดไว้ร่วมกัน แต่ละตัวเพิ่มเติมข้อมูลที่จำเป็นลงไปได้โดยไม่ต้องมีแบบฟอร์มตายตัว เมื่อ Agent ตัวใดแก้ปัญหาย่อยชิ้นไหนสำเร็จ ก็จะนำคำตอบมาวางไว้บนกระดานพร้อมติดป้ายกำกับไว้ ส่วน Agent ตัวอื่นที่กำลังค้นหาข้อมูลอยู่ เมื่อพบคำตอบบนกระดาน ก็จะหยิบไปใช้ต่อในงานของตัวเอง
รูปแบบนี้ปรากฏขึ้นครั้งแรกระหว่างการพัฒนาระบบ Hearsay-II ในปี 1980 และต่อมาในปี 1986 Gelernter และคณะก็ต่อยอดแนวคิดนี้ให้เป็นทางการยิ่งขึ้นในชื่อ tuple space ส่วนในมุมมองของปัญญาประดิษฐ์ยุคแรก Blackboard System คือระบบที่วางฐานความรู้ร่วมไว้ตรงกลาง แล้วให้โมดูลผู้เชี่ยวชาญเฉพาะด้านหลายๆ ตัวช่วยกันเติมคำตอบทีละส่วน จากจุดเริ่มต้นที่มีเพียงโจทย์ จนได้คำตอบที่สมบูรณ์ โดยโครงสร้างหลักประกอบด้วย 3 ส่วน:
- knowledge source คือโมดูลผู้เชี่ยวชาญเฉพาะด้าน แต่ละตัวถนัดคนละเรื่อง และจะเข้ามาเขียนคำตอบบางส่วนลงบนกระดานเมื่อเงื่อนไขภายในของมันตรงกับสถานะบนกระดานในขณะนั้น
- blackboard คือพื้นที่เก็บข้อมูลส่วนกลางสำหรับวางทั้งโจทย์ คำตอบย่อย ข้อเสนอแนะ และข้อมูลนำเข้าทั้งหมด
- control shell คือตัวควบคุมลำดับขั้นตอนการแก้ปัญหา และดูแลไม่ให้ knowledge source แต่ละตัวทำงานขัดแย้งหรือชนกัน
ผู้ออกแบบตั้งใจสร้างสถาปัตยกรรมนี้ขึ้นมาเพื่อรับมือกับปัญหาที่ซับซ้อนและมีขอบเขตไม่ชัดเจน เพราะคำตอบที่ถูกต้องเกิดจากการนำชิ้นส่วนย่อยหลายชิ้นมาประกอบเข้าด้วยกัน ซึ่งลักษณะปัญหาแบบนี้ตรงกับโจทย์ระบบ IROps ของสายการบินที่ทีมกำลังสร้างอยู่พอดี
สิ่งที่ใช้ได้ผลไม่ใช่โปรโตคอลใหม่ แต่เป็นแค่ไฟล์ข้อความใน Git Repo
กลไกที่ช่วยให้ Agent แบ่งงานกันเองได้นั้น ไม่จำเป็นต้องพึ่งพาโปรโตคอลใหม่ และไม่ต้องมีตัวกลางคอยแจกจ่ายงานให้แต่ละตัวเลย ทั้งหมดเกิดขึ้นได้จากแค่ไฟล์แผนงานธรรมดาที่บันทึกอยู่ใน Git repository ร่วมกับจังหวะการรวมโค้ดที่ถี่พอให้ส่งต่อความคืบหน้าถึงกันได้ตลอดเวลา
กลไกนี้ขับเคลื่อนได้เพราะ 3 ปัจจัยสำคัญที่เกิดขึ้นพร้อมกัน นั่นคือ ทุกตัวเขียนข้อมูลลงในที่เดียวกัน ทุกตัวอ่านข้อมูลของกันและกันได้ และข้อมูลที่เขียนลงไปมีเลขกำกับให้อ้างอิงได้ตรงจุด ถ้าขาดข้อใดข้อหนึ่งไป กระดานกลางนี้ก็จะกลายเป็นเพียงกองไฟล์ที่ต่างคนต่างเขียน และไม่ได้ช่วยให้ทำงานร่วมกันได้เลย
สิ่งที่ต้องแลก และเหตุผลที่ระบบนี้ยังทำให้เกิดขึ้นซ้ำไม่ได้ง่ายๆ
คนที่พูดถึงข้อจำกัดของเรื่องนี้ได้ตรงประเด็นที่สุดคือ Giles Edwards-Alexander ผู้บันทึกการทดลองนี้บนเว็บไซต์เทคโนโลยี martinfowler.com เขาย้ำว่า พฤติกรรมทั้งหมดเกิดขึ้นโดยไม่ได้ตั้งใจ เป็นผลพวงจากการตัดสินใจหลายเรื่องที่บังเอิญมาประกอบกันพอดี ไม่ใช่ระบบที่ผ่านการออกแบบล่วงหน้า สิ่งที่เกิดขึ้นจึงยังไม่มีโครงสร้างที่สมบูรณ์ และยังขาดองค์ประกอบสำคัญบางอย่างของ Blackboard System ของจริง เขายังระบุด้วยว่า ไม่มั่นใจว่าจะทำให้เกิดผลลัพธ์แบบนี้ซ้ำได้อีกหรือไม่ แม้จะย้อนกลับไปวิเคราะห์จนรู้แล้วว่าคำสั่งใดเป็นตัวจุดประกายก็ตาม
ปัญหาสำคัญอีกข้อที่เกิดขึ้นจริงในการทำงานคือ การคอมมิตโค้ดถี่ขนาดนั้นทำให้ Build Pipeline รับภาระไม่ไหว ทีมพัฒนาจึงต้องถอยกลับมาใช้วิธีส่งโค้ดขึ้นระบบเฉพาะเมื่องานเสร็จสมบูรณ์ขึ้น แต่สิ่งที่ตามมาคือ Agent ขาดข้อมูลอัปเดตความคืบหน้าที่เคยส่งถึงกันตลอดเวลา นี่คือโจทย์ที่ผู้ดูแลระบบต้องตัดสินใจว่าจะยอมแลกอะไรกับอะไร ถ้ารวมโค้ดถี่ ข้อมูลจะอัปเดตถึงกันตลอดเวลาแต่ Build Pipeline อาจรับไม่ไหว แต่ถ้ารวมโค้ดห่างขึ้น Build Pipeline ก็จะทำงานได้ราบรื่น ทว่า Agent ก็จะกลับไปทำงานแบบมองไม่เห็นความคืบหน้าของตัวอื่น
ข้อสรุปที่ผู้เขียนทิ้งไว้คือ ช่องทางการสื่อสารลักษณะนี้ควรแยกออกมาเป็นอิสระ ไม่ควรฝากไว้กับระบบเก็บโค้ดที่มีหน้าที่หลักของตัวเองอยู่แล้ว ปัจจุบันเขาจึงกำลังพัฒนาโปรเจกต์ส่วนตัวชื่อ Talwrn ชื่อนี้เป็นคำภาษาเวลส์ที่แปลว่าลานนวดข้าว หรือพื้นที่สำหรับถกประเด็นที่ยังไม่ได้ข้อสรุป โดยตั้งใจสร้างให้เป็นระบบกระดานกลางสำหรับงานที่ใช้ Agent โดยเฉพาะ และตั้งเป้าหมายแรกให้ตัวระบบพัฒนาตัวเองต่อได้
วิธีนำแนวคิดนี้ไปลองใช้กับโปรเจกต์ของคุณ
กติกาชุดนี้ใช้ได้โดยไม่ต้องติดตั้งเครื่องมือเพิ่ม ขอเพียงมีข้อตกลงร่วมกันว่าใครจะเขียนข้อมูลอะไรไว้ที่ไหน:
- เขียนสเปกกลางไว้ในไฟล์เดียว พร้อมใส่เลขกำกับทุกหัวข้อ เพื่อให้ทุกงานอ้างอิงได้ตรงจุด
- ให้ Agent แต่ละตัวเขียนแผนงานของตัวเองเป็นไฟล์แยก โดยอ้างอิงเลขหัวข้อจากสเปกกลางฉบับนั้น
- กำหนดให้แต่ละบรรทัดระบุสถานะว่ากำลังทำหรือเสร็จแล้ว และเมื่อปิดงานต้องเขียนโน้ตสั้นๆ กำกับไว้ว่าแก้งานอย่างไร
- กำหนดให้ Agent ทุกตัวอ่านแผนงานของตัวอื่นก่อนจะหยิบงานชิ้นใหม่เสมอ แทนที่จะหยิบจากคิวของตัวเองเพียงอย่างเดียว
- กำหนดความถี่ในการรวมโค้ดให้ข้อมูลอัปเดตถึงกันได้ แต่ไม่ถี่จน Build Pipeline รับไม่ไหว
โครงสร้างไฟล์แผนงานนี้ไม่ซับซ้อน เขียนตามรูปแบบนี้ก็เริ่มต้นได้แล้ว:
# plan/evaluator.md (อ้างสเปกหัวข้อ 4.2)
- [x] 4.2.1 โครงฟังก์ชันและจุดเชื่อมต่อที่ฝั่ง search จะเรียกเข้ามา
โน้ต: คืนค่าเป็นก้อนเดียว มีผลผ่านหรือไม่ผ่าน กับรายการเงื่อนไขที่ผิด
- [ ] 4.2.2 ตรวจเงื่อนไขที่ห้ามผิดเด็ดขาด <- กำลังทำอยู่
- [ ] 4.2.3 แก้ทุกจุดที่เรียกใช้ ให้หันมาเรียกตัวตรวจของจริง (รอ 5.1 ของฝั่ง search)บรรทัดที่ทำเครื่องหมายว่า "กำลังทำอยู่" ทำหน้าที่เหมือนป้ายจองงาน เมื่อ Agent ตัวอื่นมาอ่านก็จะข้ามไปทำงานส่วนอื่นแทน ส่วน "โน้ต" ใต้บรรทัดที่ทำเสร็จแล้วคือส่วนที่มีประโยชน์มากที่สุด เพราะช่วยบอกงานลำดับถัดไปว่าของที่เพิ่งเสร็จนั้นเรียกใช้งานอย่างไร ไม่ใช่แค่บอกว่าเสร็จแล้ว และข้อความในวงเล็บที่ระบุว่ากำลังรออะไรอยู่ ก็จะทำให้อีกฝ่ายรู้ทันทีว่ามีอีกส่วนกำลังรองานของตัวเองอยู่
ที่จริงแล้ว กติกาชุดนี้ไม่ได้จำกัดการใช้งานเฉพาะกับ Agent เท่านั้น ถ้าในทีมมีนักพัฒนาตั้งแต่สองคนขึ้นไปทำงานร่วมกันใน repository เดียวกัน กติกานี้ก็ช่วยประสานงานได้เช่นกัน เพราะสิ่งที่ระบบนี้ทำจริงๆ คือการเปลี่ยนความคืบหน้าของแต่ละคนให้ออกมาเป็นข้อมูลที่คนอื่นมองเห็นและหยิบไปใช้ต่อได้ทันที แทนที่จะติดค้างอยู่ในหัวของคนใดคนหนึ่ง
เรื่องนี้สะท้อนให้เห็นว่า ระบบประสานงานที่ดีไม่จำเป็นต้องรอเครื่องมือเฉพาะทางสำหรับ Agent ขอเพียงมีพื้นที่ส่วนกลางธรรมดาที่ทุกฝ่ายเข้ามาเขียนและอ่านข้อมูลร่วมกันได้ เราก็นำวิธีนี้ไปปรับใช้ได้ทันที
ที่มา:
- บทความ An Accidental Blackboard โดย Giles Edwards-Alexander บน martinfowler.com
- Blackboard system จาก Wikipedia
ชอบเรื่องแนวนี้ มีอีบุ๊คฟรีให้อ่านต่อ
NotebookLM ฉบับเข้าใจง่าย โยนเอกสารให้ AI อ่าน แล้วได้สรุป พอดแคสต์ และคลังความรู้ส่วนตัว
กดสมัครแล้วเราจะส่งเทคนิค AI และของแจกใหม่ๆ ให้ทางอีเมล เลิกรับได้ตลอด
สร้าง AI Automation Pipeline ทุกแบบ ด้วย Agents และ Skills
ปูจากพื้นฐาน prompt, context และ cost ไปจนปั้น Skill สั่ง Agent กับ Sub-agent แล้วต่อทุกอย่างเป็น pipeline อัตโนมัติที่ออกแบบเองได้ ดูฟรี 7 บทก่อนตัดสินใจ
