วิศวกรคนหนึ่งจากทีม Grok Bot เปลี่ยนจากการรัน cloud agent 15 ตัวพร้อมกัน มาเป็นมากกว่า 200 ตัวในคราวเดียว
ไม่ใช่ด้วยบอท 200 ตัว แต่ด้วยแค่ 6 ตัว
บอทวิศวกร 5 ตัวที่แต่ละตัวรับผิดชอบหนึ่งโดเมน และบอท ops อีก 1 ตัวที่ไม่ต้องเขียนโค้ดแม้แต่บรรทัดเดียว ในทีมเดียวกันนี้ Lauren Tan ส่ง PR ไปกว่า 2,000 รายการภายในเดือนเดียว
นี่คือจุดที่คนส่วนใหญ่พลาด บอทตัวแรกทำงานได้ดี พวกเขาก็เลยเพิ่มตัวที่สอง ตามด้วยตัวที่ห้า แล้วก็ตัวที่สิบ สุดท้ายกลายเป็นว่ามีหน้าต่างแชทสิบหน้าต่าง พร้อมกับงานประจำเต็มเวลาชิ้นใหม่ นั่นคือการนั่งอ่านมันทั้งหมด
กองบอทคือแค่จำนวนคน แต่ทีมคือโครงสร้าง คู่มือนี้คือโครงสร้างนั้น ซึ่งถอดแบบมาจากวิธีที่ทีมงานของ xAI ใช้จริง
สรุปสั้นๆ ใน 30 วินาที
- บอทหนึ่งตัวคือการจ้างพนักงานหนึ่งคน แต่ทีมต้องมี 5 องค์ประกอบ: ประตูหน้า ผู้เชี่ยวชาญ กระดาน นาฬิกา และด่านตรวจ
- คุณคุยกับบอทแค่ตัวเดียว แล้วปล่อยให้มันกระจายงานไปให้ตัวอื่นๆ
- ผู้เชี่ยวชาญแต่ละตัวดูแลหนึ่งโดเมนและเก็บความจำของตัวเองแยกกัน
- งานอยู่บนกระดาน ไม่ใช่ในช่องแชท
- Routine จะช่วยขับเคลื่อนงานตอนที่คุณหลับ ส่วนการอนุมัติจะเป็นตัวตัดสินว่าอะไรผ่านออกไปได้บ้าง
- ทีมของ xAI เองใช้ระบบนี้ด้วยบอทประมาณ 6 ตัว ไม่ใช่ 60 ตัว
ส่วนที่ 1. เมื่อไหร่ควรจ้างบอทตัวที่สอง
ไม่ใช่ตอนที่ตัวแรกยุ่ง เพราะบอทไม่ได้ "ยุ่ง" แบบที่คุณเป็น
Kevin Niparko บริหารทีมบอทเต็มรูปแบบในฐานะ PM ที่ SpaceXAI และคู่มือของเขาให้เหตุผล 3 ข้อในการแบ่งงานข้ามบอท ได้แก่ การอ้างอิงได้ว่าใครทำอะไร (referenceability) การทำงานขนานกัน (parallelism) และความจำที่จำกัดขอบเขต (scoped memory)
ข้อที่สามคือคำตอบที่แท้จริง ในคำพูดของเขา:
Chief of Staff ไม่ควรมานั่ง debug computer-use evals
จ้างบอทตัวที่สองเมื่อความจำของบอทตัวเดียวเริ่มแบกภาระงานสองอย่าง
คุณจะสังเกตเห็นมันก่อนจะอธิบายได้ด้วยซ้ำ บอทจัดการ inbox เริ่มตอบด้วยน้ำเสียงของบอทรีวิวโค้ด ความชอบเรื่องปฏิทินหลุดเข้าไปอยู่ใน research brief ทุกครั้งที่คุณเปิดข้อความใหม่ ต้องคอยเตือนบอทก่อนว่าวันนี้มันสวมหมวกใบไหนอยู่
Lingxi Li ผู้สร้าง Grok Bot ด้วย Grok Bot ก็พูดเหมือนกันในมุมของวิศวกรรมว่า บอทจะ "ทำงานได้ดีที่สุดเมื่อโฟกัสกับโดเมนเดียว"
บททดสอบ: นี่คือ skill หรือ bot?
เอกสารนิยาม skill ไว้ว่าเป็น "ชุดคำสั่งที่ใช้ซ้ำได้เพื่อบอกวิธีการทำงาน" และ private skills ของคุณก็คือไลบรารีเดียวที่บอททุกตัวใช้ร่วมกัน
ดังนั้น งานใหม่จึงเป็นแค่ skill แต่โดเมนใหม่ที่มีความจำของตัวเองคือ bot ถ้าคุณไม่สามารถเรียกชื่อโดเมนนั้นได้ในสามคำ แปลว่าคุณยังไม่ต้องการบอทเพิ่ม
ส่วนที่ 2. องค์ประกอบทั้ง 5 ของทีม
1. ประตูหน้า
บอทตัวเดียวที่คุณคุยด้วยจริงๆ คู่มือของ Josh Kim เรียกว่า Bot Boss ซึ่งเป็น "ประตูหน้าเพียงบานเดียว" ส่วน Niparko เรียกว่า Chief of Staff และอธิบายไว้สั้นๆ ว่า "เป็นตัว generalist เพียงตัวเดียว และจะเงียบถ้าไม่มีอะไรเปลี่ยนแปลง"
ประตูหน้ามีหน้าที่ส่งต่องาน ไม่ได้ลงมือทำเอง prompt ของ Kim บอกไว้ตรงๆ ว่า "you are hub and spoke EA, not a builder and not an auditor"
prompt ที่คุณสามารถก๊อปปี้ไปใช้ได้:
You are my Chief of Staff and the only bot I talk to. Route every request to the specialist that owns it, collect the result, check it against what I asked for, and report back in five lines. Stay silent if nothing changed.
2. ผู้เชี่ยวชาญ
รายชื่อของทีม Niparko: Chief of Staff หนึ่งตัว, engineering manager ชื่อ Emily, บอทวิศวกร 5 ตัว, data analyst, บอท PM และ recruiter ส่วนทีมของ Li: บอทวิศวกร 5 ตัว แบ่งตาม surface (iOS, desktop, infrastructure, Android, harness) บวกกับ Jenny หัวหน้าฝ่าย operations
ลองดูสิ่งที่ทั้งสองทีมมีเหมือนกัน คือผู้จัดการที่ไม่ได้ลงมือทำงานเอง Emily ทำหน้าที่แตกงาน มอบหมาย และตรวจสอบผลลัพธ์เทียบกับเป้าหมาย ส่วน Jenny ดูแลการ onboarding บอทใหม่และทำ postmortem ไม่มีตัวไหนเขียนโค้ดเลย
สำหรับทีมแรก ผู้เชี่ยวชาญ 3 ตัวก็เพียงพอแล้ว Eric Zakariasson จำกัดจำนวนบอทในทุก project channel ไว้ที่ไม่เกิน 6 ตัว และบอกว่าการจำกัดนี้เป็น "just an arbitrary number" เป็นตัวเลขที่ตั้งขึ้นมาลอยๆ แต่กลับถูกต้อง
3. กระดาน
ข้อความในแชทเลื่อนหายไปได้ ทีมจึงต้องมีที่เดียวที่แสดงสถานะของงาน
ทีมของ Li ใช้ tracker ร่วมกันใน Notion ทุกๆ 30 นาที บอทจะเช็ค PR แต่ละรายการเพื่อหา CI ที่ล้มเหลว review comments และ merge conflicts ปัญหาจะถูกตีกลับไปเป็น Working ส่วนงานที่เรียบร้อยจะถูกย้ายไปที่ Ready for Review
Zakariasson ใช้ฐานข้อมูล 2 ชุด คือ Projects และ Tasks โดยมีหนึ่ง channel ต่อหนึ่งโปรเจกต์ บอทที่ติดปัญหาจะทำเครื่องหมาย task นั้นว่า Blocked แล้ว ping หาคน ส่วนเวลาที่เหลือ คนก็แค่นั่งดูการ์ดขยับไปมา
ประโยคที่ดีที่สุดในบรรดาคู่มือทั้งหมดมาจากบทความนี้:
The interesting part is that the more I build on this, the more it resembles a system initially built for humans.
4. นาฬิกา
routine ตามที่เอกสารระบุไว้ จะ "tell one Bot when to run a workflow" บอทแต่ละตัวเก็บ routine ได้สูงสุด 50 รายการ ทำงานถี่สุดได้ทุก 5 นาที และยังรันต่อไปได้แม้คุณจะปิดฝาแล็ปท็อปแล้วก็ตาม
นาฬิกาของ Li หน้าตาเป็นแบบนี้ ตอนตี 3 จะรัน nightly audits: dead code, load time, bundle size ตอนตี 5 Jenny จะจัด 1:1 กับบอททุกตัวในทีม ทบทวน playbook และดึง blocker ขึ้นมา ผลลัพธ์ที่รายงานคือ บอท "rarely forget my complex workflows, even after many weeks"
standup ตอนตี 5 นี้คือไอเดียที่ถูกมองข้ามมากที่สุดในระบบทั้งหมด context ของบอทนั้นมีจำกัด การทำซ้ำคือวิธีที่ทีมใช้รักษามาตรฐาน และที่นี่บอทเป็นคนทำซ้ำแทน เพื่อที่คุณจะได้ไม่ต้องทำเอง
5. ด่านตรวจ
Niparko พูดถึงสิ่งที่มนุษย์ยังต้องลงมาดูเอง:
I still keep final review for any external email sends, purchasing anything, or destructive actions like deletes.
Kim ไปไกลกว่านั้น บอทจัดการ inbox ถูกตั้งให้เป็น read-only และจะไม่ส่งอะไรออกไปเลยจนกว่าจะมีการพิมพ์คำว่า "send" ในตอนนั้นจริงๆ
ข้อเท็จจริง 2 ข้อจากเอกสารที่จะเปลี่ยนวิธีออกแบบด่านตรวจของคุณ:
- Background approvals มีวันหมดอายุ เมื่อ routine หรือบอทอื่นทริกเกอร์การกระทำที่ต้องรอคุณกดตกลง คำขอนั้นจะหมดอายุหลังจากผ่านไปราว 10 นาที และการกระทำจะไม่ถูกรัน งานตอนตี 3 ที่รอคุณอยู่จะตายไปกับการรอ ตัดสินใจไว้ล่วงหน้าเลย: ไม่ก็เขียน allow rule ให้มัน หรือไม่ก็ตั้งให้ routine หยุดแค่ขั้น draft
- บอททุกตัวใช้ cloud computer เครื่องเดียวกัน ไฟล์ browser sessions และ logins ทั้งหมดเข้าถึงได้จากทุกตัวในทีม เอกสารบอกไว้ตรงๆ ว่า อย่ามองว่าบอทที่แยกกันคือขอบเขตด้านความปลอดภัย
คุณแยกบอทเพื่อความโฟกัสและความจำ แต่คุณได้ความปลอดภัยจากด่านตรวจ
ส่วนที่ 3. สร้างให้เสร็จใน 5 วัน
วันที่ 1. ประตูหน้า เลื่อนขั้นบอทตัวแรกของคุณให้เป็น Chief of Staff ด้วย prompt ด้านบน จากนี้ไปมันจะเป็นแชทเดียวที่คุณเปิด
วันที่ 2. แยกตามความจำ ลิสต์ทุกอย่างที่บอทตัวแรกทำอยู่ในปัจจุบัน แล้วจัดกลุ่มตามโดเมน สองกลุ่มที่ใหญ่ที่สุดจะกลายเป็นผู้เชี่ยวชาญสองตัวแรกของคุณ การตั้งค่าบอทมี 3 ฟิลด์: Name, Title, Description กรอกมันเหมือนคุณกำลังเขียนประกาศรับสมัครงาน
วันที่ 3. กระดาน สร้างตารางเดียวที่มี Task, Owner และ Status: Todo, Working, Blocked, Ready for Review, Done จากนั้นบอกบอททุกตัวเหมือนกันว่า ไม่มีอะไรเสร็จจนกว่ากระดานจะบอกว่าเสร็จ และถ้าติดขัดให้ตั้งเป็น Blocked แล้ว ping หาฉัน
วันที่ 4. นาฬิกา เริ่มด้วย 3 routines: morning board จาก Chief of Staff, การ sweep กระดานทุก 30 นาที และ nightly audit หนึ่งรอบ รันทดสอบแต่ละอันก่อนด้วย input ที่ปลอดภัย เอกสารเตือนไว้ว่าการ test run นั้น "performs real work"
วันที่ 5. ด่านตรวจ เขียนกฎ ask-first: การส่ง การซื้อ การลบ การเผยแพร่ และทุกอย่างที่อยู่บน production เพิ่ม allow rule หนึ่งข้อสำหรับการกระทำที่คุณอนุมัติไปแล้ว 5 ครั้งติด
จากนั้นปล่อยทิ้งไว้สักสัปดาห์ก่อนจะจ้างบอทตัวที่สี่
ความผิดพลาด 5 อย่างที่ทำลายทีมบอท
กองทัพโคลน ก๊อปปี้ generalist ตัวเดิมมา 5 ตัว ไม่มี scoped memory ไม่มีโดเมน ไม่ได้อะไรเพิ่ม คุณแค่คูณต้นทุนและเพิ่มความสับสนเข้าไปอีก
กรุ๊ปแชทที่ไม่มีกระดาน บอทสามารถส่งข้อความและทริกเกอร์กันได้ แต่ถ้าไม่มี shared state มันก็คือการประชุม ไม่ใช่งาน
บอสสายลุย ประตูหน้าที่เริ่มลงมือทำงานเอง ทันทีที่ Chief of Staff ของคุณเริ่มเขียนโค้ด จะไม่มีใครส่งต่องานและไม่มีใครตรวจสอบอีกต่อไป
ตัวฟังที่เปิดกว้างเกินไป ตั้ง trigger ไว้กับทุกข้อความใหม่ เอกสารเตือนเรื่องนี้ไว้โดยเฉพาะเพราะมันสร้าง noise และเผา usage ควร match ให้แคบเข้าไว้
ภาพลวงตาด้านความปลอดภัย การคิดว่าบอทการเงินมองไม่เห็นสิ่งที่บอทวิจัยล็อกอินเข้าไป คอมพิวเตอร์เครื่องเดียวกัน sessions เดียวกัน
ผังองค์กรคือโปรดักต์
คนที่สร้าง Grok Bot ไม่ได้ประดิษฐ์ architecture ใหม่ให้กับทีมของพวกเขา พวกเขาแค่สร้างระบบที่เก่าแก่ที่สุดขึ้นมาใหม่: ผู้จัดการ ผู้เชี่ยวชาญ กระดาน standup และการเซ็นอนุมัติ
ความต่างคือทีมนี้จัด standup ตอนตี 5 และไม่มีใครบ่นสักคน
เริ่มจากประตูหน้า เพิ่มผู้เชี่ยวชาญหนึ่งตัว อย่าเพิ่งเพิ่มตัวที่สามจนกว่าจะมีกระดาน
ป.ล. ถ้าคุณยังไม่ได้จ้างบอทตัวแรก ให้เริ่มจากคู่มือก่อนหน้าของฉัน "Grok Bot: How to Hire Your First AI Employee" ทุกอย่างที่อ้างอิงมาในบทความนี้มาจากคู่มือและเอกสารสาธารณะของ Grok Bot จาก xAI
