ทำให้งานของ AI agent มองเห็นและควบคุมได้ ด้วยแนวคิด canvas แทนการคุยในแชตยาว

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

ทำไมแชตถึงไม่พอเมื่อ agent เริ่มทำงานจริง

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

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

canvas คืออะไร

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

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

ตัวอย่างที่เห็นภาพ

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

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

รูปแบบที่นำไปใช้ซ้ำได้

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

นำไปใช้กับทีมไทยอย่างไร

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

ข้อคิดที่สำคัญที่สุดจากบทความคือให้มอง canvas เป็นการออกแบบกระบวนการทำงาน ไม่ใช่แค่การปรับหน้าตาเครื่องมือ ซึ่งตรงกับหลักการเดียวกับที่ทีม DevOps ใช้มานาน คือถ้าอยากปรับปรุงอะไร ต้องทำให้มันวัดและมองเห็นได้ก่อน