ChatGPT ติดตาม Project Board ได้แล้ว: ก้าวต่อไปที่ Event-Driven Agents ต้องการ

บทสรุปงาน DevDay recap ของ OpenAI เมื่อวันที่ 29 กันยายนที่ผ่านมา ได้ยกตัวอย่างให้เห็นภาพอย่างชัดเจนว่า “คุณสามารถสั่งให้ ChatGPT คอยเฝ้าดูงานใหม่ ๆ บนบอร์ดโปรเจกต์ได้ เมื่อมีงานเข้ามา ChatGPT จะสามารถอ่านเอกสารที่แนบไว้และร่างแผนงานขึ้นมาได้ แม้ในตอนที่คุณไม่อยู่ก็ตาม” เบื้องหลังการทำงานนี้คือการที่ ChatGPT รองรับข้อกำหนด MCP Events ที่เพิ่งเสนอขึ้นมา ซึ่งใช้งานได้ในทุกแพ็กเกจ โดยเปิดตัวพร้อมกับฟีเจอร์สำหรับทีมอีกสองอย่าง ได้แก่ Team tasks ที่ทำงานตามกำหนดเวลาหรือตามเหตุการณ์ (events) และการเรียกใช้ @ChatGPT ใน Slack และ Teams

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

สรุปสั้น ๆ (TL;DR)

MCP Events ช่วยให้ ChatGPT รับทราบการเปลี่ยนแปลงในแอปพลิเคชันที่เชื่อมต่ออยู่ได้อย่างเป็นระเบียบและมีความปลอดภัยผ่านการลงลายมือชื่อดิจิทัล (signed) ขณะที่ ChatGPT team tasks ก็ช่วยนำการทำงานแบบกำหนดเวลาและแบบขับเคลื่อนด้วยเหตุการณ์ (event-driven) มาสู่แพ็กเกจ Business และ Enterprise การทำให้เหตุการณ์ไปสั่งให้ Agent เริ่มทำงานนั้นเป็นเพียงครึ่งแรกที่ง่าย ซึ่ง OpenAI ออกแบบมาอย่างรอบคอบ แต่ครึ่งหลังที่ยากคือผลลัพธ์ที่เกิดขึ้นบนบอร์ดหลังเกิดเหตุการณ์ ได้แก่ ใครเป็นเจ้าของงานที่เกิดขึ้น ร่างแผนงานจะถูกส่งไปไว้ที่ไหน จะมีขั้นตอนการตรวจสอบอย่างไร และจะป้องกันไม่ให้ Agent สองตัวเข้ามาตอบรับเหตุการณ์เดียวกันได้อย่างไร วิธีแก้คือควรกำหนดกฎการจัดเส้นทางงาน (routing rule) ไว้อย่างชัดเจน: หนึ่งประเภทเหตุการณ์ต่อหนึ่งผู้รับผิดชอบ, แผนงานต้องส่งกลับมายัง Task นั้น ๆ, และต้องมีคนเป็นผู้กดอนุมัติก่อนที่งานจะถือว่าเสร็จสิ้นจริง

มีอะไรเปิดตัวใหม่ในงาน DevDay

MCP Events คือส่วนต่อขยายที่ถูกเสนอขึ้นสำหรับ Model Context Protocol ซึ่งเปิดทางให้เซิร์ฟเวอร์ MCP แจ้งเตือน ChatGPT เมื่อเกิดเหตุการณ์ขึ้นในแอปพลิเคชันที่เชื่อมต่อ เพื่อให้ปลั๊กอินสามารถเริ่มทำงานอัตโนมัติตอบสนองได้ทันที โดยใน คู่มือ MCP Events ของ OpenAI ได้อธิบายถึงการทำงานฝั่งเซิร์ฟเวอร์ไว้ว่า เซิร์ฟเวอร์จะประกาศว่าตนเองรองรับเหตุการณ์และใช้ 3 เมธอด ได้แก่ events/list, events/subscribe และ events/unsubscribe ซึ่ง ChatGPT จะรองรับการส่งผ่าน Webhook เท่านั้น และมีการลงลายมือชื่อด้วย Standard Webhooks HMAC หลังผ่านการยืนยัน HTTPS verification challenge โดยส่งได้ครั้งละหนึ่งเหตุการณ์ต่อคำขอ ขนาดสูงสุดไม่เกิน 256 KiB เมื่อมีเหตุการณ์ส่งเข้ามา ตามที่คู่มือระบุไว้คือ “ChatGPT จะได้รับเหตุการณ์ในแชตที่สมัครรับข้อมูลไว้ และปฏิบัติตามคำสั่งของผู้ใช้ว่าต้องตอบสนองอย่างไร”

รายละเอียดต่าง ๆ ได้รับการออกแบบมาอย่างรัดกุมในจุดที่สำคัญ ตัวเซิร์ฟเวอร์ต้องกำหนด ID เฉพาะให้กับแต่ละเหตุการณ์โดยที่ ID ต้องคงเดิมแม้จะมีการลองส่งซ้ำ (retry) การสมัครรับข้อมูล (subscription) จะต้องเป็นแบบ Idempotent โดยระบุตัวตนจาก principal, callback URL, ชื่อเหตุการณ์ และพารามิเตอร์ต่าง ๆ ดังนั้นการสมัครซ้ำจึงเป็นการอัปเดตรายการเดิมแทนที่จะสร้างรายการใหม่ขึ้นมาซ้ำซ้อน นอกจากนี้ เซิร์ฟเวอร์ยังต้องบล็อกที่อยู่ callback ที่เป็นเครือข่ายส่วนตัว (private) หรือในเครื่อง (local) และต้องไม่ตามลิงก์เปลี่ยนเส้นทาง (redirects)

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

ตัวกระตุ้น (Trigger) เป็นเพียงครึ่งแรกที่ง่าย

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

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

แผนงานจะถูกส่งไปไว้ที่ไหน? เหตุการณ์จะส่งเข้ามายังแชตที่สมัครรับข้อมูลไว้ และแผนงานจะถูกส่งไปยังที่ใดก็ตามที่คำสั่งของคนผู้นั้นระบุ ไม่ว่าจะเป็นการตอบกลับในแชต หรือการเขียนข้อมูลกลับไปยังบอร์ดหากปลั๊กอินรองรับและคำสั่งสั่งให้ทำเช่นนั้น ทีมจำเป็นต้องรู้ว่าแผนงานจะไปอยู่ที่ไหน มิฉะนั้นสถานะบนบอร์ดก็จะยังค้างอยู่ที่คำว่า "ใหม่" (new) ในขณะที่แผนงานที่เขียนไว้อย่างดีกลับไปค้างอยู่ในที่ที่ไม่มีใครเข้าไปอ่าน

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

ใครเป็นคนตอบรับเหตุการณ์? กลไก Idempotency ช่วยป้องกันไม่ให้การสมัครรับข้อมูลรายการหนึ่งสร้างงานซ้ำซ้อนด้วยตัวเอง แต่มันไม่ได้ช่วยประสานงานระหว่างคนสองคน เพราะข้อมูลผู้ใช้งาน (principal) ถือเป็นส่วนหนึ่งในการระบุตัวตนของการสมัคร ทำให้การสมัครของแต่ละคนแยกขาดจากกัน ยิ่งหากมีการมอบหมาย Agent บนบอร์ดไว้อีกตัว งานเดียวกันก็อาจถูกวางแผนซ้ำซ้อนมากกว่าหนึ่งครั้ง การคัดกรองข้อมูลซ้ำ (deduplication) ที่ระดับ Webhook ไม่สามารถช่วยตัดสินความเป็นเจ้าของงานในระดับการปฏิบัติงานจริงได้

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

กำหนดเส้นทางการกระจายงานไว้บนบอร์ด

บนบอร์ดที่มีการตั้ง Agent เป็นผู้รับมอบหมายงาน (Assignee) การ "เฝ้าดูงานใหม่" ส่วนใหญ่จะเปลี่ยนไปเป็นการ "มอบหมายงาน" แทน ใน Sharkly งานที่มอบหมายให้กับ Agent จะเริ่มทำงานทันทีเมื่อย้ายออกจาก Backlog และสภาพแวดล้อมอย่าง Computer กับ Runtime มีความพร้อม โดยช่องผู้รับผิดชอบการทำงานจะกำหนดให้มี Agent หรือ Crew ได้เพียงหนึ่งเดียวเท่านั้น และ Sharkly จะรวมงานที่รอดำเนินการเข้าด้วยกัน ทำให้การแสดงความคิดเห็นอย่างต่อเนื่องไม่ไปสร้างคิวงานซ้ำซ้อนสำหรับ Agent และ Task เดิม ความเป็นเจ้าของงานจึงถูกกำหนดผ่านฟิลด์ข้อมูลที่ชัดเจน ไม่ใช่แค่ข้อตกลงปากเปล่า

สำหรับเหตุการณ์ที่ควรเริ่มทำงานโดยไม่ต้องมีการมอบหมายงาน Sharkly Automations คือสิ่งที่เทียบเท่ากันบนฝั่งบอร์ด โดยหนึ่ง Automation ประกอบด้วยหนึ่งกฎ นั่นคือ: คำสั่ง (instructions), Agent หรือ Crew, ตัวกระตุ้น (triggers) อย่างน้อยหนึ่งตัว และประวัติการทำงาน โดยมีสถานะเป็น Active หรือ Paused ส่วนตัวกระตุ้นสามารถเลือกได้ทั้งแบบตามกำหนดเวลา (cron พร้อมระบุเขตเวลา), เมื่อ Task ถูกย้ายไปยังสถานะที่เลือก, เมื่อมีคอมเมนต์ที่มีคำหรือข้อความที่ระบุ, และ Webhook จากบริการภายนอก พร้อมทั้งมีปุ่ม Run now สำหรับการทดสอบ การทำงานแต่ละครั้งจะเริ่มต้นโดยตรงและบันทึกประวัติไว้ในตัว Automation ดังนั้นในคำสั่งจึงควรระบุให้ชัดเจนว่าจะให้บันทึกผลลัพธ์ไว้ที่ใด ปัจจุบันการตรวจจับสถานะและคอมเมนต์จะมีผลทั่วทั้งองค์กร ดังนั้นใน เอกสารคู่มือ Automations จึงแนะนำให้เขียนคำสั่งตรวจสอบ Task ต้นทางก่อนที่จะเริ่มดำเนินการทุกครั้ง

นี่คือตัวอย่างตารางการจับคู่ระหว่างเหตุการณ์กับ Task ของ Space หนึ่ง:

และนี่คือกฎเบื้องหลังที่เขียนขึ้นไว้ในจุดที่ทีมสามารถเข้ามาตรวจสอบและหารือร่วมกันได้:

Routing rule: new work in the ENG Space

1. One event type, one owner. Each event maps to exactly one
   Automation or one Agent Assignee. Personal watchers (a chat
   subscription, a dot) may read the board; they do not plan on it.
2. New requests enter Triage. A person accepts before any Agent runs.
3. Accepted work that needs a plan moves to "Needs plan", a status in
   the Backlog category. The "Draft plan" Automation runs the Planner
   Agent, which first checks the Task's Space and type and stops if
   the Task is not ours.
4. The plan returns to the Task as a comment. The Planner does not
   change status and does not assign anyone.
5. The Task's human assignee reads the plan, assigns the executing
   Agent, and moves the Task to Todo. That move starts the run.
6. Done means a person accepted the result. No Agent moves a Task
   into a Completed status.

การจัดสถานะ “Needs plan” ให้อยู่ในหมวด Backlog คือหัวใจสำคัญที่ทำให้ขั้นตอนที่ 5 ปลอดภัย เพราะ Task ที่ถูกมอบหมายงานขณะยังอยู่ใน Backlog จะต้องรออยู่ก่อน แผนงานจึงได้รับการตรวจสอบก่อนที่ระบบจะเริ่มทำงานจริงเสมอ นอกจากนี้ควรกำหนดในคำสั่งของ Planner ให้ชัดเจนว่าแผนงานจะส่งไปไว้ที่ใด และควรทดสอบด้วยปุ่ม Run now ก่อนที่จะเปิดใช้ตัวกระตุ้นจริง เมื่อ Agent ต้องการการตัดสินใจระหว่างการทำงาน ตัว Task จะแสดงสถานะว่ากำลังรอคำตอบจากคน (waiting for human reply) และจะถูกส่งไปยัง Inbox ของผู้รับผิดชอบ ซึ่งนี่คือจุดที่คำว่า “แม้ในตอนที่คุณไม่อยู่” จะต้องส่งไม้ต่อกลับมาให้คนจริง ๆ Task จึงเป็นพื้นที่ที่คำขอจากแชตกลุ่มจะถูกเปลี่ยนให้เป็นงานที่ตรวจสอบย้อนหลังได้ และเช่นเดียวกันสำหรับการมอบหมาย GitHub issue ให้กับ AI Agent

ระบบเฝ้าดูของ ChatGPT เหมาะกับการใช้งานตรงไหน

เลือกใช้การสมัครรับข้อมูลผ่าน MCP Events เมื่อต้องการให้ใครคนใดคนหนึ่งได้รับการแจ้งเตือนและได้เห็นร่างแรกในแชตส่วนตัว เช่น บอร์ดที่คุณคอยติดตามดูแต่ไม่ได้เป็นคนดูแล บอร์ดติดตามงานของพาร์ตเนอร์ หรือสรุปงานวันศุกร์สำหรับตัวคุณเอง เลือกใช้ Team tasks เมื่อเป็นงานประจำประเภทสรุปอัปเดตของทีมที่จัดการภายใน ChatGPT และทีมของคุณใช้แพ็กเกจ Business หรือ Enterprise เพราะสมาชิกในทีมสามารถช่วยกันปรับปรุงชุดคำสั่งเดียวกันได้แทนที่จะต้องเขียนแยกกันคนละชุด และเลือกใช้กฎบนฝั่งบอร์ดเมื่อเหตุการณ์นั้นทำให้เกิดงานที่ทีมต้องร่วมกันรับผิดชอบ เช่น แผนงานที่มีคนต้องนำไปทำต่อ การแก้ไขปัญหาที่มีคนต้องคอยรีวิว หรือ Task ที่ต้องนำไปนับรวมในรายงานสรุปงานวันจันทร์

ประสิทธิภาพของ AI Agent แบบ Event-driven จะขึ้นอยู่กับความชัดเจนของกฎที่กำหนดว่า Agent ตัวใดควรเป็นผู้ตอบสนอง เหตุการณ์เป็นเพียงระบบท่อส่งข้อมูล แต่การจัดเส้นทาง ผู้รับผิดชอบ และการตรวจสอบนั้นเป็นเรื่องของการบริหารจัดการ ซึ่งควรไปอยู่บนบอร์ดที่ Agent ทุกตัวรายงานผล ไม่ว่าบอร์ดนั้นจะสร้างขึ้นโดยผู้ให้บริการรายใดก็ตาม สำหรับการตัดสินใจว่า Agent ควรหยิบงานใดไปทำต่อเมื่อมีงานเข้ามาเต็มคิว สามารถดูเพิ่มเติมได้ที่ การคัดกรองและการจัดการ Backlog สำหรับ AI ส่วนฟีเจอร์ Dots ซึ่งเป็นสิ่งที่เปิดตัวอย่างแรกในบทสรุปของ OpenAI ก็ทำให้เกิดคำถามลักษณะเดียวกันนี้ในมุมของตัว Agent เช่นกัน

หากคุณใช้งาน Agent หลายตัวอยู่แล้ว Sharkly จะช่วยให้คุณมีศูนย์กลางเพียงแห่งเดียวในการจัดการงานและผลลัพธ์ของพวกมัน

แหล่งข้อมูลเพิ่มเติม

• Sharkly Automations: ตัวกระตุ้นทั้ง 4 ประเภท, ประวัติการทำงาน และจุดสิ้นสุดของระบบอัตโนมัติ
• จากข้อความในแชตกลุ่มสู่งานโค้ดที่ตรวจสอบย้อนหลังได้: การเปลี่ยนข้อความธรรมดาให้กลายเป็นงานที่มีผู้รับผิดชอบ
• การคัดกรองและการจัดการ Backlog สำหรับ AI: การตัดสินใจว่า Agent ควรทำงานใดเป็นลำดับถัดไป
• การมอบหมาย GitHub issue ให้กับ AI Agent: เปลี่ยนจาก Issue ไปสู่ Pull Request ที่พร้อมตรวจทาน
• การใช้งาน Coding Agent ในเวลาที่คุณไม่อยู่: การรันงานแบบไม่มีคนคอยดูแลและคิวการตรวจสอบ
• ทำความรู้จัก OpenAI dots: Agent ส่วนบุคคลที่ทำงานตลอดเวลา และสิ่งที่ทีมยังจำเป็นต้องมีเพื่อสนับสนุนพวกมัน