โดย Nokka (นก-กา) | ตรวจข้อมูล 25 ต.ค. 2026 · ตอนที่ 2 จาก 6 ของชุด "หนึ่งคนกับทีม agent"
บทความนี้เขียนโดย AI (deepseek-v4.1-flash · ผู้ให้บริการโมเดล: ollama-cloud) ผ่าน Hermes Agent ภายใต้การควบคุมและตรวจสอบคุณภาพโดยมนุษย์ - Nokka (นก-กา)
ถ้าคุณเคยลองใช้ agent หนึ่งตัวทำงานหนึ่งอย่าง จะรู้ว่ามันไม่ยาก
แต่ถ้าลองใช้ 10 ตัวพร้อมกัน ปัญหาจะไม่ใช่เรื่องโมเดลเก่งไม่เก่งอีกต่อไป
ปัญหาคือคุณจะรู้ได้อย่างไรว่าตัวไหนทำอะไรอยู่ ตัวไหนค้าง ตัวไหนกำลังโกหกคุณ และงานไหนที่ควรหยุดก่อนจะเสียเวลา
ตอนที่แล้วผมเล่าเส้นทางของ Lauren Tan ไปแล้ว ตอนนี้เราจะลงมาดูว่าเธอประกอบ "ทีม agent" นี้อย่างไร
Grok Bot ไม่ใช่แชตบอต
agent ที่มีคอมพิวเตอร์ในคลาวด์
Grok Bot เปิดตัววันที่ 11 ส.ค. 2026 ในฐานะ "ทีม agent ที่ทำงานตลอดเวลา" Bots ทุกตัวใช้คอมพิวเตอร์เครื่องเดียวกันในคลาวด์ แชร์ไฟล์ เบราว์เซอร์ และ session ของแอป แต่ละตัวได้หน้าจอของตัวเอง [1][2]
คุณคุยกับมันเหมือนคุยกับเพื่อนร่วมงาน สั่งงานเป็นข้อความหรือเสียง แล้วมันกลับมาเมื่อต้องการให้คุณอนุมัติ [1]
จุดที่ต่างจากแชตทั่วไปคือ มันทำงานต่อได้แม้คุณปิดแล็ปท็อป และจำบริบทของงานไว้ข้ามรอบ ไม่ใช่เริ่มใหม่ทุกครั้ง [1][2]
ฟีเจอร์ที่ผมคิดว่าสำคัญที่สุดคือ การเรียนรู้จากการสาธิต คือคุณสาธิตงานหลายขั้นตอนให้ดูครั้งเดียว แล้วมันบันทึกเป็น skill ไว้รันซ้ำหรือตั้งเวลาได้ [1]
นี่คือแนวคิดเดียวกับที่ผมใช้ในงานเขียนของตัวเอง คือทำงานหนึ่งครั้งให้ดี แล้วเก็บวิธีนั้นไว้เป็นขั้นตอน
แต่ Grok Bot ในเวิร์กช็อปของเธอไม่เหมือนที่คนทั่วไปใช้
20 agents กับคำสั่งสามตัว
สรุปเวิร์กช็อปของเธอที่บัญชี Grok โพสต์ไว้ ระบุตัวเลขที่ชัดเจนว่า ให้รัน agent 20 ตัวขึ้นไป แบ่งเป็น 1 Chief of Staff, หลาย manager และหลาย worker [3]
การมอบงานให้ทำผ่าน Chief และให้ความเป็นเจ้าของงานเต็มรูปแบบด้วยคำสั่งสามตัวคือ /goal /swarm และ /loop [3]
ผมอ่านตรงนี้แล้วนึกถึงโครงสร้างบริษัท ไม่ใช่โครงสร้างซอฟต์แวร์
เพราะสิ่งที่เธอสร้างไม่ใช่ระบบ orchestration ที่คุณต้องเขียนโค้ดเอง แต่เป็นลำดับชั้นของการ delegate ที่มีคนหนึ่งคอยรับงานดิบ แล้วกระจายลงไปตามความถนัด
ทำไมต้องมีลำดับชั้น
บทเรียนจาก Managerial Leverage
ในบทความ "Loops You Can Trust" เธอเล่าว่าคำถามของเธอเปลี่ยนไป จาก "ฉันรัน agent ได้กี่ตัว" เป็น "ลูปนี้ผลิตหลักฐานอะไร จุดไหนที่เวลาของฉันมี leverage มากที่สุด" [4]
เธออ้างแนวคิด managerial leverage จากหนังสือ High Output Management ว่า ผู้จัดการเพิ่มผลผลิตของทีมได้สามทาง คือจ้างคนเพิ่ม ให้คนทำงานเร็วขึ้น หรือให้เครื่องมือและทักษะที่ดีขึ้น [4]
กับ agent สองทางแรกมีเพดานชัด เพราะความเร็วและจำนวน agent ที่คุณตรวจงานไหวมีจำกัด เหลือทางที่สามคือสร้าง skill และเครื่องมือที่ทำให้ทุก agent ทำงานดีขึ้นพร้อมกัน [4]
ผมคิดว่านี่คือเหตุผลที่คำว่า Chief of Staff ไม่ใช่แค่ชื่อเล่นน่ารัก แต่เป็นการออกแบบเพื่อลดจำนวนครั้งที่มนุษย์ต้องตัดสินใจ
ตัวเลข PR ที่ทำให้คนหันมามอง
สองแหล่ง สองตัวเลข
สรุปเวิร์กช็อประบุผลลัพธ์ว่า 1,000 PR ขึ้นไปต่อเดือน และสิ่งที่เธอรีวิวคือผลลัพธ์ ไม่ใช่โค้ดทีละบรรทัด [3]
ส่วน The New Stack ระบุว่า pstack ทำให้เธอส่ง 2,000 PR ต่อเดือนขึ้น production หรือเกือบ 100 PR ต่อวันทำการ [5]
สองตัวเลขนี้ไม่ขัดกัน เพราะ 1,000 ขึ้นไปคือพื้นล่าง และเกือบ 100 ต่อวันทำการคือที่มาของ 2,000 [3][5]
สิ่งที่ผมสนใจกว่าเลขคือประโยคที่ว่า "รีวิวผลลัพธ์ ไม่ใช่โค้ด" [3]
เพราะถ้าวิธีคิดคืออ่าน diff ทุกบรรทัด ตัวเลขนี้จะเป็นไปไม่ได้เลย
Verification คือคอขวด ไม่ใช่การเขียนโค้ด
ตัวอย่างร้านอาหารเช้า
เธออธิบายด้วยตัวอย่างร้านอาหารเช้าง่าย ๆ ว่า ไข่ใช้เวลาสามนาที ดังนั้นทั้งจานต้องจัดเวลาให้ตรงกับไข่ การทำขนมปังหรือกาแฟให้เร็วขึ้นไม่ทำให้ได้อาหารเร็วขึ้น [4]
ในงานโค้ด ขั้นตอนที่ใช้เวลานานที่สุดคือการทำซ้ำบั๊กและการตรวจว่าหายจริง เพราะสองขั้นนี้มักต้องมีคนเฝ้า [4]
ทางออกของเธอคือให้ agent ใช้เครื่องมือเดียวกับที่มนุษย์ใช้ นั่นคือ Chrome DevTools [4]
สกิลที่ชื่อ /control-glass เปิด dev build ที่มี DevTools Protocol ให้ agent คลิก พิมพ์ อ่าน accessibility tree ถ่ายภาพ อัดวิดีโอ จำกัด CPU เครือข่าย เก็บ CPU profile และ heap snapshot ได้ [4]
ผลคือ agent ทำซ้ำปัญหา วัดผล แก้ แล้ววัดซ้ำได้เอง โดยไม่ต้องรอคน [4]
หลักฐานชนะคำอธิบาย
เธอสรุปหลักคิดสั้น ๆ ว่า "show me your work" และบอกว่าคำว่า "I fixed it" ไม่ใช่คำตอบที่พอ [4]
ต้องเห็นเทสต์ที่พังก่อนแก้ เทสต์ที่ผ่านหลังแก้ วิดีโอก่อนกับหลัง เทรซหรือภาพหน้าจอ [4]
ถ้างานนั้น merge แล้ว ต้องรันซ้ำบน main และแสดงผลอีกรอบ [4]
ผมชอบประโยคที่ว่า สิ่งที่จับต้องได้ชนะคำอธิบายที่ฟังดูสมเหตุสมผล เพราะนี่คือปัญหาแรกของงานที่ AI เขียน คือคำอธิบายดีแต่โค้ดผิด [4]
Refactor ให้ agent ทำงานถูกตั้งแต่แรก
กฎที่ระบบบังคับ ไม่ใช่กฎที่คนต้องจำ
สรุปเวิร์กช็อปมีประโยคที่ผมคิดว่าสำคัญที่สุดของทั้งชุด คือการ refactor สถาปัตยกรรมให้เป็นมิตรกับ agent โดยแบน footgun อย่าง useEffect และ comment แล้วให้ CI บังคับว่าเส้นทางที่สั้นที่สุดคือเส้นทางที่ถูกต้อง [3]
แนวคิดคือกฎที่เขียนไว้ในเอกสารเป็น "soft rule" คนอ่านบ้างไม่อ่านบ้าง แต่กฎที่ CI บังคับจนทำงานผ่านไม่ได้คือ "hard fail" [3]
เธอยกตัวอย่างการย้าย UI library ไป StyleX ที่ PR ใหญ่เกือบ 400,000 บรรทัด โดยมากเป็นหลักฐานการตรวจสอบที่ generate ขึ้นมา และ agent ของเธอสร้างสคริปต์เทียบค่า computed style ระหว่าง SCSS เดิมกับ StyleX ใหม่ [4]
ผลคือ CSS ที่ generate ลดจากกว่า 30,000 บรรทัดเหลือราว 6,000 บรรทัด และสถานะที่เก็บภาพไว้เทียบกันได้ครบ [4]
บทเรียนที่เธอสรุปออกมาคือ จับข้อผิดพลาดในขั้นที่ต้นทุนต่ำที่สุด [4]
ตัวอย่างลำดับงานหนึ่งวันในระบบแบบนี้
ผมขอยกตัวอย่างสมมติเพื่อให้เห็นภาพ ไม่ใช่บันทึกงานจริงของเธอ
08:30 Chief of Staff สรุปงานค้างจากเมื่อคืน
- งาน 3 อย่างเสร็จ พร้อมหลักฐาน
- งาน 1 อย่างหยุดเพราะทำซ้ำบั๊กไม่ได้
08:40 สั่ง /goal กับ manager ฝั่ง frontend
- เป้าหมาย: แก้ปัญหา layout กระตุกในหน้าตั้งค่า
09:10 worker เปิด dev build ใน cloud
- อัดวิดีโอก่อนแก้ + เก็บ CPU profile
09:40 worker แก้ แล้วรันซ้ำ วัดผลเทียบกับก่อนแก้
10:00 manager เปิด draft PR พร้อมภาพและตัวเลข
10:20 Chief of Staff รวม PR ที่พร้อมให้คุณรีวิว
- คุณดูเฉพาะผลลัพธ์และตัดสินใจ
จุดที่คนมักพลาดคือคิดว่าขั้นตอนพวกนี้เกิดเองได้ทันที ทั้งที่มันต้องมีการตั้งค่าสกิล การกำหนดเกณฑ์ผ่าน และการซ้อมด้วยมือก่อนหนึ่งรอบ [4]
สิ่งที่เอาไปใช้ได้โดยไม่ต้องมี Grok Bot
สามอย่างที่เริ่มได้สัปดาห์นี้
หนึ่ง ให้ agent เห็นสิ่งที่คุณเห็น ถ้าคุณตรวจงานด้วยภาพหน้าจอ ให้ agent ถ่ายภาพหน้าจอได้ ถ้าคุณใช้ log ให้ agent อ่าน log เดียวกัน [4]
สอง เปลี่ยนคำว่าเสร็จให้เป็นหลักฐาน กำหนดว่าทุกงานต้องมีอะไรแนบมาบ้าง ก่อนจะถือว่าเสร็จ [4]
สาม ทำด้วยมือหนึ่งครั้งก่อนสร้าง automation เพราะถ้าคุณไม่รู้ว่าของดีหน้าตาเป็นอย่างไร agent ก็ไม่รู้ [4]
สามข้อนี้ไม่ต้องใช้ผลิตภัณฑ์ของบริษัทไหนเลย ใช้ได้กับ tool ที่คุณมีอยู่แล้ว
สิ่งที่ตอนต่อไปจะตอบ
ตอนนี้เราเห็นภาพทีมแล้ว แต่ยังไม่เห็นข้างในเครื่องมือที่ทำให้ทีมนี้ทำงานได้
ตอนที่ 3 ผมจะเปิด pstack ดูว่า playbook 23 เล่มกับ Skill ที่ผูกกับมันทำงานอย่างไร และเหตุใดคำสั่งของมันจึงเต็มไปด้วยแผลเป็นจากการรันจริง
ผมจะเขียนทีละตอนและรายงานความคืบหน้าให้คุณดูเหมือนเดิม
REF
[1] xAI (2026) · Grok Bot Overview (เอกสารทางการ). https://docs.x.ai/grok-bot/overview.md
[2] xAI (11 ส.ค. 2026) · Introducing Grok Bot. https://x.ai/news/introducing-grok-bot
[3] Grok (1 ก.ย. 2026) · TL;DR of Lauren Tan workshop on maxing GrokBot. https://x.com/grok/status/2094731064749023668
[4] Lauren Tan (24 มิ.ย. 2026) · Loops You Can Trust. https://x.com/poteto/article/2069824386283319343
[5] The New Stack (19 ก.ย. 2026) · One engineer shipped 2,000 PRs a month to production. Verification is the key. https://thenewstack.io/agentic-verification-distributed-systems/
Top comments (0)