มี AI หลายตัวช่วยทำงาน แต่ทุกคนในทีมยังต้องส่งคำขอผ่านคนเดิม ปัญหาอาจอยู่ที่วิธีร่วมงานกับ AI มากกว่าจำนวนเอเจนต์
Peter Steinberger เล่าถึงปัญหานี้ใน ClawLabs: Building Open Source Together | DevDay 2026 จากช่อง OpenAI ก่อนสาธิตการทำงานร่วมกันผ่าน OpenClaw ส่วน Kevin Lin นำเสนอ OpenClaw Enterprise หรือ OCE สำหรับจัดการเอเจนต์และกำหนดขอบเขตการทำงานในองค์กร
สิ่งที่เห็นในคลิปมีทั้งการให้หลายคนช่วยกำกับงานในเซสชันเดียวกัน การเก็บบทสนทนาไว้คู่กับผลงาน และการจำกัดสิทธิ์ของเอเจนต์ แต่ยังมีข้อจำกัดให้เห็น เช่น รายงานที่สรุปผิดและปลั๊กอินที่ติดขัดระหว่างสาธิต
สารบัญ
- จากคนกลางส่งข้อความ สู่เซสชันที่ทีมเข้าถึงร่วมกัน
- ดูคำสั่งและเหตุผลไปพร้อมกับโค้ด
- เครื่องมือภายในที่แก้ต่อผ่านเอเจนต์ได้
- แยกงานวนซ้ำออกจากงานที่มีจุดจบ
- OpenClaw Enterprise วางขอบเขตการทำงานอย่างไร
- สิ่งที่เดโมแสดง และสิ่งที่ยังสรุปไม่ได้
- คำถามที่ทีมควรตอบก่อนใช้งานร่วมกัน
จากคนกลางส่งข้อความ สู่เซสชันที่ทีมเข้าถึงร่วมกัน
Steinberger เล่าว่าเขาเริ่มจากใช้เอเจนต์ในหน้าต่างคำสั่ง ก่อนย้ายมา Codex Desktop และกระจายงานไปหลายเครื่องเมื่อเครื่องส่วนตัวรับภาระไม่ไหว แต่การเพิ่มเครื่องไม่ได้แก้ปัญหาหนึ่ง: เพื่อนร่วมทีมยังต้องติดต่อผ่านเขาเพื่อเข้าถึงงาน
เขาเรียกคนที่ทำหน้าที่รับส่งข้อความระหว่างทีมกับ AI ว่า meat proxy และเสนอให้สมาชิกเห็นสิ่งที่เอเจนต์กำลังทำ เข้าใจการตัดสินใจ และช่วยปรับทิศทางได้โดยตรง
ในเดโม เขาขอเกมแนวกบข้ามถนน แล้วเอเจนต์พบเกม Lily Lane ที่ทีมสร้างไว้แล้ว จากนั้นจึงสั่งเปลี่ยนตัวละครเป็นล็อบสเตอร์ ระหว่างนั้นสมาชิกคนอื่นเข้ามาร่วมและส่งคำสั่งในพื้นที่เดียวกันได้ จึงไม่ควรอ่านเดโมนี้ว่า AI สร้างเกมใหม่ทั้งหมดในเวลาไม่กี่วินาที
เซิร์ฟเวอร์ทีมที่สาธิตเปิดให้สมาชิกเห็นและส่งคำสั่งในเซสชันของกันและกัน Steinberger ระบุว่าออกแบบสำหรับคนที่ทำงานร่วมกันและมีสิทธิ์เข้าถึงร่วมกัน พร้อมเตือนว่าไม่ควรเชิญคนที่ไม่ต้องการให้เข้ามาแก้เซสชัน
เขาบอกว่าการทดลองนี้ทำให้ทีมทำงานเร็วขึ้นและมีความสุขขึ้น เพราะมองเห็นคำสั่งและเหตุผลของกันและกัน ข้อนี้เป็นประสบการณ์ที่เขาเล่า ไม่ใช่ผลทดสอบที่รับรองว่าจะเกิดกับทุกทีม
ดูคำสั่งและเหตุผลไปพร้อมกับโค้ด
Steinberger เล่าว่าเขาเคยตรวจ PR แล้วเข้าใจว่าโค้ดเปลี่ยนอะไร แต่ไม่รู้ว่าทำไมจึงเปลี่ยน จึงลองขอให้ผู้ร่วมพัฒนาแนบบทสนทนาที่ลบข้อมูลอ่อนไหวแล้วไปกับ PR แต่มีคนยอมทำไม่มาก เพราะวิธีพูดกับเอเจนต์ให้ความรู้สึกเป็นเรื่องส่วนตัว
การเปิดเซสชันให้ทีมเห็นร่วมกันทำให้ตรวจบริบทได้ง่ายขึ้น เขายกตัวอย่างงานแก้หน้าตาตารางที่ดูเหมือนเพื่อนร่วมทีมย้อนสิ่งที่เขาเพิ่งทำไป แต่เมื่อเปิดบทสนทนากลับพบว่าเป็นการต่อยอดงานเดิม มีเหตุผลรองรับ และมีข้อความแจ้งไว้แล้ว
ประโยชน์ที่เสนอจึงอยู่ที่การเก็บโจทย์ ข้อจำกัด และเหตุผลไว้กับชิ้นงาน อย่างไรก็ดี ทีมต้องแยกให้ชัดว่าบทสนทนาใดแชร์ได้ และข้อมูลใดไม่ควรอยู่ในพื้นที่ร่วม การเห็นประวัติช่วยให้ตรวจสอบได้ แต่ไม่ได้ทำให้การเปิดเผยข้อมูลทุกอย่างเหมาะสมโดยอัตโนมัติ
เครื่องมือภายในที่แก้ต่อผ่านเอเจนต์ได้
ทีมรวมแดชบอร์ด ปลั๊กอิน รายงาน และเครื่องมือต่างๆ ไว้ในเซิร์ฟเวอร์ร่วม ตัวอย่างในคลิปมีแดชบอร์ดเวลาทดสอบระบบ สถิติ PR และปัญหาที่แจ้งเข้ามา รวมถึง Daily Claw ซึ่งสรุปความเคลื่อนไหวเป็นหน้าหนังสือพิมพ์
Steinberger อธิบายว่าแดชบอร์ดอาจเกิดจากเซสชันที่สร้างชิ้นงาน แล้วมีระบบอัตโนมัติกลับมาอัปเดตต่อ ทีมจึงสั่งเอเจนต์ปรับหน้าตาหรือรายละเอียดได้ เขาใช้คำเล่นว่า jellyware เพื่อสื่อถึงซอฟต์แวร์ที่ปรับเปลี่ยนได้รวดเร็ว
เขายอมรับว่า Daily Claw บางครั้งทำได้ดี แต่หลายครั้งสรุปผิด และแสดง “slop meter” ที่ใช้เตือนเรื่องเอเจนต์สร้างโค้ดเพิ่มจนต้องตามเก็บกวาด ตัวอย่างเหล่านี้สะท้อนภาระตรวจและดูแลที่ยังอยู่ แม้สร้างเครื่องมือได้ง่ายขึ้น
ทีมยังทำเครื่องมือสรุปบทสนทนาประชุมใน Discord ส่วนการถามงานและแตกงานใหม่ผ่านเสียงเป็นความสามารถที่ผู้บรรยายกล่าวถึง แต่ไม่ได้สาธิตในช่วงนั้น
แยกงานวนซ้ำออกจากงานที่มีจุดจบ
Steinberger แยกการทำงานต่อเนื่องออกเป็นสองแบบ: loop คอยตรวจสิ่งที่ต้องติดตามซ้ำ ส่วน goal ทำงานไปสู่สภาพปลายทางที่กำหนดไว้
ตัวอย่าง loop คือการติดตามรายงานจาก Discord, Twitter และ GitHub แล้วจัดหมวดหมู่ สำหรับปัญหาที่เข้าเงื่อนไข เอเจนต์จะตรวจสอบ เปิดสภาพแวดล้อมทดสอบเพื่อจำลองข้อผิดพลาด เสนอวิธีแก้ ทดสอบ และให้อีกเอเจนต์ตรวจงานก่อนรวมโค้ด เขาอธิบายว่าเป็นกระบวนการที่ทีมใช้อยู่ ไม่ได้สาธิตผลลัพธ์ครบทุกขั้นสำหรับทุกกรณีในคลิป
ตัวอย่าง goal คือการทยอยเปลี่ยนการเข้าถึงฐานข้อมูล SQLite จากแบบ synchronous เป็น asynchronous เขาระบุว่า ณ เวลาบรรยาย งานดำเนินมา 18 วัน รวม PR ไปแล้วมากกว่า 100 รายการ และยังไม่จบ ตัวเลขนี้จึงไม่ใช่หลักฐานว่างานย้ายระบบทั้งหมดสำเร็จ หรือเป็นอัตราผลงานที่ทีมอื่นคาดหวังได้
เขาพบด้วยว่า loop ที่กระจายตามเครื่องส่วนตัวติดตามและบำรุงรักษายาก จึงทยอยย้ายเข้าพื้นที่ทีม เพื่อให้คนอื่นช่วยดูแลได้ ระบบอัตโนมัติยังต้องมีผู้รับผิดชอบเมื่อหยุดทำงานหรือจำเป็นต้องปรับทิศทาง
OpenClaw Enterprise วางขอบเขตการทำงานอย่างไร
Kevin Lin ซึ่งแนะนำตัวว่าดูแล OpenClaw Enterprise ที่ OpenAI นำเสนอ OCE เป็นระบบควบคุมกลางแบบโอเพนซอร์สสำหรับติดตั้งและจัดการเอเจนต์หลายกลุ่ม พร้อมการกำกับดูแลและขอบเขตด้านความปลอดภัย เขาอธิบายมาตรการหลักสี่ส่วน:
- แยกส่วนควบคุมออกจากพื้นที่รันเอเจนต์: โค้ดส่วนควบคุมที่ทำงานตามกฎแน่นอนอยู่คนละคอนเทนเนอร์หรือคลัสเตอร์กับงานของเอเจนต์ เพื่อจำกัดการแก้สภาพแวดล้อมของตัวเอง
- จำกัดสิทธิ์ด้วย sandbox: ควบคุมการเข้าถึงเครือข่าย ไฟล์ที่เขียนได้ และคลังโค้ดที่ส่งงานเข้าได้
- เพิ่มการตรวจด้วยโมเดล: ใช้ auto-review ตรวจการกระทำและบล็อกสิ่งที่อาจเป็นอันตรายก่อนดำเนินการ เป็นชั้นเสริมจากข้อจำกัดของระบบ
- แยกตัวตนของเอเจนต์: ใช้บัญชีบริการและการเชื่อมต่อที่กำหนดได้ เพื่อควบคุม ตรวจสอบ หรือปิดแต่ละเอเจนต์แยกกัน
ทั้งหมดเป็นคำอธิบายสถาปัตยกรรมของผู้บรรยาย คลิปไม่ได้มีผลตรวจสอบความปลอดภัยอิสระที่ยืนยันว่าป้องกันความเสี่ยงได้ทั้งหมด
ในเดโม เอเจนต์ชื่อ Fred ได้สิทธิ์อ่านโค้ดอย่างเดียว เชื่อมกับ Linear และ Slack และกำหนดให้การเขียนข้อมูลลง Linear ผ่านการอนุมัติของทีม ส่วน Cooper ได้รับงานเพิ่มแผนภาพการใช้โทเคนลงในแดชบอร์ด โดยสมาชิกสามารถเปิดเซสชันที่ยืนยันตัวตนแล้วเข้ามาช่วยระบุรายละเอียดงานได้
สิ่งที่เดโมแสดง และสิ่งที่ยังสรุปไม่ได้
การตอบคำถามของ Fred มีความล่าช้า และ Lin กล่าวถึงปัญหาปลั๊กอินก่อนเดินหน้าการนำเสนอต่อ จึงยังสรุปจากเดโมนี้ไม่ได้ว่าการเชื่อมหลายระบบจะตอบคำถามได้ครบและรวดเร็วเสมอ เช่นเดียวกับที่คลิปไม่ได้ยืนยันผลส่งมอบสุดท้ายของงานแดชบอร์ดที่มอบให้ Cooper
Lin ประกาศเปิด OCE ในงานและเปรียบวิสัยทัศน์กับบทบาทของ Kubernetes ต่อการจัดการคอนเทนเนอร์ นี่คือเป้าหมายที่ผู้บรรยายเสนอ ไม่ใช่หลักฐานว่า OCE กลายเป็นมาตรฐานของวงการแล้ว บทความนี้รายงานตามช่วงเวลาของวิดีโอ ไม่ได้ยืนยันสถานะการเปิดใช้หรือเงื่อนไขบริการปัจจุบัน
ช่วงท้าย Steinberger กล่าวถึงการสนับสนุนโอเพนซอร์สและ Patch the Planet ร่วมกับกลุ่มอย่าง Trail of Bits โดยวางเรื่องความปลอดภัยและการดูแลโครงการเป็นส่วนหนึ่งของงานระยะยาว
คำถามที่ทีมควรตอบก่อนใช้งานร่วมกัน
Steinberger ยังให้ความสำคัญกับ taste หรือวิจารณญาณในการเลือกว่างานแบบใดเหมาะสม ซึ่งเขาไม่ต้องการมอบให้เอเจนต์ทั้งหมด เมื่อเอเจนต์ทำงานต่อเนื่องได้มากขึ้น หน้าที่ของทีมจึงรวมถึงการกำหนดมาตรฐานและดูแลกระบวนการที่สร้างงานด้วย
สำหรับทีมที่สนใจทดลอง บทความเสนอคำถามสั้นๆ ต่อไปนี้เพิ่มเติมจากเดโม:
- ใครเห็นและสั่งงานในเซสชันร่วมได้ และใครตัดสินใจเมื่อคำสั่งขัดกัน?
- เก็บโจทย์ เหตุผล และผลการตรวจไว้กับผลงานแล้วหรือยัง โดยไม่เปิดข้อมูลเกินจำเป็น?
- งานใดควรตรวจวนซ้ำ งานใดต้องมีเกณฑ์สำเร็จ และใครมีหน้าที่หยุดหรือแก้ระบบ?
- เอเจนต์อ่านและเขียนอะไรได้บ้าง การกระทำใดต้องผ่านคนก่อน?
- วัดคุณภาพและเวลาตรวจแก้อย่างไร แทนการนับเพียงจำนวนโค้ดหรือชิ้นงานที่สร้าง?
อ่านเพิ่มเติมจากแหล่งที่ต้นฉบับอ้างไว้: แนวทางการกำหนดสิทธิ์ของ OWASP และ ภาพรวม Kubernetes ทั้งสองเป็นเอกสารประกอบแนวคิด ไม่ใช่หลักฐานรับรอง OCE
ที่มา: ClawLabs: Building Open Source Together | DevDay 2026 จากช่อง OpenAI เรียบเรียงจากบทถอดเสียงที่แนบกับต้นฉบับ VideoToBlog
