tui-agents: เห็นงานทีม AI บนบอร์ดเดียว ตั้งแต่สถานะจนถึงหลักฐาน

ปัญหา: เปิด AI หลายตัวแล้วต้องรู้ว่างานอยู่กับใคร

เวลาผมเปิด AI coding agent หลายหน้าต่าง สิ่งที่เพิ่มขึ้นทันทีคือข้อความบนจอ แต่สิ่งที่ไม่ได้เพิ่มตามคือความเข้าใจว่างานเดินไปถึงไหน ตัวหนึ่งกำลังเขียนโค้ด อีกตัวรอข้อมูล อีกตัวบอกว่าตรวจแล้ว ถ้าผมต้องสลับอ่านทุก terminal เพื่อประกอบเรื่องเอง ทีมที่ควรช่วยประหยัดเวลาก็กลายเป็นงานเฝ้าหน้าจอเพิ่มอีกชิ้น

ผมเลยมอง tui-agents เป็นชั้นประสานงานรอบ CLI ที่ใช้อยู่ แต่ละบทบาทยังใช้หน้าตาของ CLI เดิมใน tmux window ของตัวเอง ส่วน harness ช่วยเชื่อมบทบาท ข้อความ ไฟล์หลักฐาน และหน้าบอร์ดให้เห็นร่วมกัน จุดสำคัญไม่ใช่มี agent กี่ตัว แต่คือมีทางตอบว่าใครรับงาน อะไรยังค้าง และใช้หลักฐานอะไรบอกว่าผ่านแล้ว

วิดีโอประกอบผ่านการตัดต่อและปิดรายละเอียดภายในการ์ดกับ transcript แล้ว จึงแสดงภาพรวมบอร์ด สถานะ และรายชื่อ agent ใน terminal โดยไม่เผยข้อความงานหรือหลักฐานละเอียด ฉบับนี้มีเสียงพากย์ AI ภาษาไทย พร้อมคำบรรยายไทยสำหรับอ่านตาม บทความด้านล่างอธิบายความหมายของส่วนที่ปิดไว้เป็นข้อความ ตัวอย่างนี้ไม่ใช่คลิปสอนตั้งค่าโมเดลหรือหลักฐานว่าทุกระบบที่ปรากฏผ่านการทดสอบครบถ้วน

แบ่งบทบาท: คนคุยกับเราไม่จำเป็นต้องเขียนทุกไฟล์

รายชื่อในคลิปเป็นทีมที่แยกตามงาน ส่วนตัวอย่าง config ด้านล่างย่อเหลือสี่หน้าที่ทั่วไป จึงไม่ใช่รายชื่อชุดเดียวกับที่ปรากฏในวิดีโอ

ในทีมตัวอย่าง ผมให้ lead เป็นจุดติดต่อหลัก รับโจทย์จากผม กำหนดผลที่ต้องเห็น แล้วส่งงานให้ coder ส่วน reviewer ตรวจความถูกต้องและจุดเสี่ยง ขณะที่ qa ตรวจพฤติกรรมด้วยการรันจริง การแยกงานแบบนี้ทำให้คำว่า “ตรวจแล้ว” มีผู้รับผิดชอบชัด และช่วยไม่ให้คนเขียนเป็นผู้สรุปผลฝ่ายเดียว

ชื่อ role เป็นที่อยู่สำหรับส่งข้อความ ไม่ได้ผูกกับยี่ห้อ AI โดยอัตโนมัติ ทีมนี้เลือกใช้ Codex ทุกบทบาท แต่ตัว framework รองรับ CLI หลายแบบ การเปลี่ยนค่ายหรือเปลี่ยนโมเดลควรเป็นการตัดสินใจตามงานและสิทธิ์ที่มี ไม่ใช่ข้อสรุปว่าทีมทุกทีมต้องใช้ชุดเดียวกับผม และการแยก session ก็ยังไม่รับประกันว่าจะไม่มีจุดบอดร่วมกัน จึงต้องมี acceptance checks และผลทดสอบประกอบ

ผมแยก agent profile ออกจาก role เพื่อให้รู้ว่าส่วนไหนคือวิธีเปิดโปรแกรม และส่วนไหนคือหน้าที่ในทีม ตัวอย่าง profile ขั้นต่ำด้านล่างใช้การขออนุญาตตามค่า CLI ปกติ ไม่ได้เปิด bypass:

# .agent/agents/codex.yaml
# profile ระบุว่าจะเปิด CLI ชนิดไหน
id: codex
kind: codex

จากนั้นกำหนดบทบาทในอีกไฟล์ ตัวอย่างนี้เปิดครบสี่บทบาทเมื่อเริ่มทีม แต่ไม่ได้หมายความว่าทุกบทบาทต้องใช้โมเดลหรือความลึกในการคิดเท่ากัน:

# .agent/roles.yaml
# role คือที่อยู่สำหรับส่งข้อความหากัน
roles:
  lead:
    agent: codex
    prompt: lead.md
    autostart: true
  coder:
    agent: codex
    prompt: coder.md
    autostart: true
  reviewer:
    agent: codex
    prompt: reviewer.md
    autostart: true
  qa:
    agent: codex
    prompt: qa.md
    autostart: true

ไฟล์ prompt แต่ละชื่ออยู่ในโฟลเดอร์ .agent/prompts/ และต้องเขียนขอบเขตงานจริงให้ครบ เช่น coder แก้ implementation, reviewer ตรวจโดยไม่แก้แข่ง และ qa ส่งผลทดสอบกลับพร้อมคำสั่งที่ใช้ ตัวอย่าง YAML เป็นโครงบทบาท ไม่ใช่ชุดพร้อมใช้งานที่สร้าง prompt หรือทดสอบการเชื่อมต่อให้เอง

อ่านบอร์ด: สถานะงานกับระดับหลักฐานเป็นคนละแกน

ผมใช้บอร์ดเพื่อหาคำตอบเร็ว ๆ ว่างานไหนกำลังทำ ใครถืออยู่ และอะไรต้องเข้าไปอ่านต่อ การ์ดอาจมี checklist, เจ้าของ, สถานะ และระดับหลักฐาน ส่วนแผนภาพกับเครื่องมือย่อขยายช่วยตามงานหลายชิ้นโดยไม่ต้องเปิด terminal ทุกอันพร้อมกัน

แต่ done กับ runtime ตอบคนละคำถาม สถานะ done บอกว่ามีผู้บันทึกว่างานเสร็จ ส่วนระดับ runtime บอกว่าการ์ดมีหลักฐานการรันที่แนบไว้ เช่นคำสั่ง exit code และ output ที่ใช้สนับสนุนผล ระดับ compile เหมาะกับผล build หรือ type check และ static เหมาะกับการอ่านโค้ดหรือเอกสาร การเห็นสีเขียวจึงควรเป็นจุดเริ่มอ่านหลักฐาน ไม่ใช่เหตุผลให้หยุดตรวจ

เอกสารของ harness กำหนดว่าการ์ด runtime ต้องมี evidence ประกอบ และถ้าไม่แนบจะถูกลดระดับลง อย่างไรก็ตาม บอร์ดไม่ได้รันคำสั่งซ้ำหรือตรวจความถูกต้องของเนื้อหาเทสต์ด้วยตัวเอง output ที่แนบอาจทดสอบผิดจุด ใช้ข้อมูลเก่า หรือครอบคลุมไม่พอ คนตรวจยังต้องดูว่าหลักฐานตรงกับข้ออ้างและเวอร์ชันงานที่กำลังรับหรือไม่ นี่คือหน้าสำหรับตามหลักฐาน ไม่ใช่ใบรับรองจาก CI

ผมจึงแยกคำถามเป็นลำดับ: process ยังอยู่ไหม งานคืบหน้าหรือยัง และ acceptance check ผ่านอะไรแล้วบ้าง สามคำถามนี้เกี่ยวข้องกัน แต่เอาคำตอบหนึ่งไปแทนอีกคำตอบไม่ได้ หน้าต่าง CLI ที่ยังเปิดอยู่ไม่ได้พิสูจน์ว่า model ตอบกลับได้ และข้อความว่าเสร็จแล้วก็ไม่ได้แทนผลการรัน

ส่งต่องาน: ข้อความต้องพาไปถึงไฟล์และเงื่อนไขรับงาน

ในขั้นตอนทำงานจริง ผมกลับมาดูข้อความใน terminal เพื่อเข้าใจว่าใครส่งอะไรให้ใคร ส่วนวิดีโอเผยเฉพาะรายชื่อ agent โดยปิด transcript ไว้ การสื่อสารของทีมนี้ผ่าน MCP server ชื่อ harness โดยมีเครื่องมือส่งข้อความและแนบ artifact ข้อความที่เข้าถึง agent ปรากฏใน terminal ของผู้รับพร้อม prefix ของ harness จึงยังตามการสนทนาผ่าน CLI เดิมได้

หลักที่ผมใช้คือ handoff ต้องมีโจทย์ ขอบเขตไฟล์ และเงื่อนไขผ่าน ไม่ใช่ส่งว่า “ดูต่อให้หน่อย” ถ้า coder ส่งงานให้ตรวจ ควรมี diff พร้อม test report ถ้า reviewer พบปัญหา ควรระบุไฟล์ ตำแหน่ง และสถานการณ์ที่ทำให้ผิด ส่วน qa ต้องบอกคำสั่งที่รัน ผลจริง และข้อจำกัด เช่นยังไม่ได้ทดสอบ browser หรือยังไม่มีข้อมูลจำลองสำหรับบางกรณี

artifact ช่วยให้รายงานชี้ไปยังไฟล์ชุดเดียวกัน แทนการคัดข้อความยาวซ้ำในทุกหน้าต่าง ส่วนการตอบกลับข้อความเดิมช่วยตามบริบทว่าคำตอบนี้ตอบงานไหน แต่การส่งสำเร็จเพียงข้อความเดียวพิสูจน์ได้แค่รอบสื่อสารนั้น ไม่ได้แปลว่าเครื่องมือทุกตัวหรือทุกบทบาทผ่านการตรวจครบแล้ว

ถ้าใช้ working directory ร่วมกัน ผมให้ทีมตกลงว่าใครเป็นผู้แก้ไฟล์ไหนในช่วงนั้น ข้อตกลงนี้เป็นวิธีทำงานของทีม ไม่ใช่ automatic file lock ของ shared mode หากแยกด้วย worktree ก็ช่วยแยกไฟล์ที่แก้ แต่ยังต้องดูเรื่องบริการ พอร์ต และฐานข้อมูลร่วมด้วย worktree ไม่ใช่ sandbox ของระบบปฏิบัติการ

ตามความเปลี่ยนแปลง: หลักฐานต้องใหม่พอสำหรับงานที่กำลังดู

ส่วน What changed ช่วยให้ผมกลับมาดูว่าระหว่างที่ไม่ได้เฝ้าจอมีอะไรเปลี่ยน เช่นสถานะหรือ checklist ที่ถูกอัปเดต แล้วค่อยเปิดรายละเอียดการ์ดที่เกี่ยวข้อง การมีประวัติทำให้ตามเรื่องต่อได้ง่ายกว่าการมองสถานะล่าสุดอย่างเดียว แต่ก็ยังต้องอ่านควบคู่กับเวลาของข้อมูลและตัวงานจริง

บอร์ดบางแบบสร้างจากข้อมูลทีม บางแบบอ่านจากไฟล์แผน และบางแบบ agent เป็นผู้เขียนอัปเดตให้ ความสดของข้อมูลจึงต้องดูตามที่มา ถ้า agent ลืมขยับการ์ด หน้าที่เชื่อมต่อกับ harness อยู่ก็ยังอาจแสดงงานเก่าได้ คำว่า live ในมุมการเชื่อมต่อจึงไม่ควรถูกตีความว่าเนื้อหาทุกช่องเพิ่งถูกตรวจซ้ำ

ผมใช้การตรวจหลายระดับให้ตรงคำถาม: การตรวจ config ช่วยหาความผิดพลาดของการตั้งค่า การเปิด CLI จริงกับส่งข้อความกลับมาจึงตรวจรอบสื่อสาร ส่วนการรัน acceptance checks จึงตรวจพฤติกรรมงานที่ส่งมอบ ตัวอย่างเช่น doctor ปกติตรวจการตั้งค่า ขณะที่การตรวจแบบ live ต้องใช้ CLI และ model จริง จึงมีการใช้งานโมเดลตามมา ไม่ควรนำผลตรวจ config มาเขียนเป็นผล end-to-end

บทเรียนที่เอาไปใช้กับเครื่องมืออื่นได้คือ อย่าให้หน้ารวมสถานะเป็นแหล่งประกาศความสำเร็จที่ตรวจย้อนกลับไม่ได้ ทุก claim ควรมีทางเดินกลับไปถึงสิ่งที่รัน เวอร์ชันที่ตรวจ และคนที่รับผิดชอบ ถ้าขาดอย่างใดอย่างหนึ่ง ให้บอกช่องว่างตรง ๆ จะช่วยตัดสินใจได้ดีกว่าการเพิ่มสีเขียวอีกช่อง

สรุป: ทีม AI ที่ตามงานได้เริ่มจากความรับผิดชอบที่ชัด

• ให้ lead เป็นผู้คุยหลัก แล้วระบุหน้าที่ coder, reviewer และ qa ให้ชัด ชื่อ role กับโมเดลเป็นคนละเรื่องกัน
• ใช้บอร์ดหางาน เจ้าของ และสิ่งที่เปลี่ยน จากนั้นอ่านหลักฐานของการ์ดก่อนรับผล
• แยกสถานะงานออกจากระดับหลักฐาน: runtime ที่แนบ output ไม่ใช่การรับรองว่าเทสต์ถูกต้องครบถ้วน
• ส่งงานพร้อม scope, diff และผลตรวจที่ทำซ้ำได้ แทนการให้คนถัดไปเดาเองจาก transcript
• ตกลงผู้แก้ไฟล์เมื่อใช้ shared checkout และอย่าถือว่า worktree แยกฐานข้อมูลหรือสิทธิ์ของเครื่องให้ด้วย
• ดู freshness กับที่มาของสถานะเสมอ การเชื่อมต่อได้ การสื่อสารได้ และงานผ่าน เป็นสิ่งที่ต้องพิสูจน์แยกกัน

อ่านต่อเรื่องหลักคิดของระบบประสานงานได้ใน บทเรียนจากการสร้าง multi-agent orchestration และเรื่องหลักฐานก่อนรับงานใน closed-loop AI engineering