ทริกเกอร์: โหมด webhook

เอเจนต์ของคุณเริ่มทำงาน
เมื่อมีบางอย่างเกิดขึ้นจริง ๆ

ทริกเกอร์ตอบคำถามเดียว: เอเจนต์ตัวนี้เริ่มทำงานเมื่อไหร่? งานที่กำหนดเวลาตอบด้วยเวลาบนนาฬิกา ทริกเกอร์ webhook ตอบด้วยเหตุการณ์จากโลกภายนอก pull request ถูกเปิด build พัง การแจ้งเตือนดังขึ้น แล้วเอเจนต์ก็กำลังทำงานอยู่แล้ว

AgentsRoom จะให้ URL สาธารณะและคีย์ลับสำหรับลงลายเซ็นกับทริกเกอร์แต่ละตัว วาง URL นั้นลงใน GitHub, GitLab, Slack, Linear, Sentry หรืออะไรก็ตามที่ส่ง POST JSON ได้ เมื่อการเรียกมาถึง ลายเซ็นจะถูกตรวจสอบ payload จะกลายเป็นตัวแปรในคำสั่งของคุณ และเอเจนต์จริงจะเริ่มทำงานในโปรเจกต์ของคุณพร้อมเทอร์มินัลและบันทึกการสนทนาของมัน

ทริกเกอร์ webhookกำลังรอฟัง
POSTGitHubpull_requestเพิ่ม rate limiting ให้ API
ตรวจสอบลายเซ็นแล้ว
ตรงกับตัวกรอง
ผู้ตรวจสอบโค้ด
{{event.title}} = เพิ่ม rate limiting ให้ API
ไม่มีอะไรทำงานตราบใดที่ไม่มีอะไรเกิดขึ้นเริ่มเมื่อมีเหตุการณ์

หนึ่งทริกเกอร์ หนึ่ง URL สาธารณะ เหตุการณ์มาถึง ลายเซ็นถูกตรวจสอบ payload กลายเป็นตัวแปรในคำสั่ง และเอเจนต์เริ่มทำงานในโปรเจกต์ของคุณ

งานที่กำหนดเวลาแก้ปัญหาไปได้ครึ่งหนึ่ง คุณสั่งให้เอเจนต์ตรวจสอบ pull requests ทุกเช้าเวลา 8 โมงได้อยู่แล้ว แต่งานส่วนใหญ่ที่คุณอยากมอบให้เอเจนต์ไม่ได้เกิดขึ้นตอน 8 โมง มันเกิดขึ้นตอนที่มีคนเปิด pull request ตอนที่ build กลายเป็นสีแดง ตอนที่ลูกค้าแจ้งบั๊กเข้ามาตอนบ่ายสอง

จนถึงตอนนี้ วิธีเดียวที่จะจับสิ่งเหล่านั้นได้คือให้เอเจนต์คอยเฝ้า: รันมันตามกำหนดเวลาถี่ ๆ ให้มันวนถาม API ว่า 'มีอะไรใหม่ไหม?' แล้วจ่ายโทเค็นเพื่อคำตอบว่า 'ไม่มี' หลายร้อยครั้งต่อวัน นั่นแพง ตอบสนองช้า และขยายตัวได้แย่ทันทีที่คุณอยากเฝ้าสาม repositories

ทริกเกอร์ webhook กลับด้านมันเสียใหม่ ให้บริการนั้นเป็นฝ่ายบอกคุณเอง AgentsRoom ยื่น URL ให้คุณ คุณวางมันลงใน GitHub, GitLab, Slack, Linear, Sentry หรือ CI ของคุณ แล้วจะไม่มีอะไรทำงานจนกว่าบริการนั้นจะเรียกเข้ามา เมื่อมันเรียก เอเจนต์จะเริ่มทำงานโดยมีเหตุการณ์อยู่ในคำสั่งของมันเรียบร้อยแล้ว ศูนย์โทเค็นในวันที่เงียบ และมีเอเจนต์ลงมือภายในไม่กี่วินาทีในวันที่ไม่เงียบ

ทำไมเหตุการณ์ถึงชนะลูปวนถาม

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

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

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

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

หนึ่งทริกเกอร์ สองวิธีในการเริ่มทำงาน

แผงเดียวรองรับทั้งสองแบบ เลือกแบบที่ตรงกับสิ่งที่คุณกำลังรออยู่

ตามกำหนดเวลา

โหมดดั้งเดิม ไม่มีอะไรเปลี่ยน ทุก N นาที รายชั่วโมง รายวัน รายสัปดาห์ หรือรายเดือน โดยไม่ต้องเขียนนิพจน์ cron สำหรับงานที่ขึ้นกับนาฬิกา: การตรวจสอบตอนเช้า การเช็ค dependencies วันจันทร์ changelog วันศุกร์

Webhook

เอเจนต์รอเหตุการณ์แทนที่จะรอเวลา AgentsRoom ให้ URL สาธารณะและคีย์ลับสำหรับลงลายเซ็นกับคุณ คุณวาง URL ลงในบริการนั้น แล้วทริกเกอร์จะทำงานเมื่อบริการนั้นส่ง POST เข้ามา สำหรับงานที่ขึ้นกับสิ่งที่เกิดขึ้น: pull request หนึ่งอัน build ที่ล้มเหลว รายงานบั๊กใหม่หนึ่งรายการ

จะให้ทริกเกอร์อะไรบ้าง

เหตุการณ์จริง และเอเจนต์ที่คุณอยากให้รออยู่อีกฝั่ง

ตรวจสอบทุก pull request ตั้งแต่วินาทีที่มันถูกเปิด

ชี้ webhook ของ GitHub หรือ GitLab มาที่ทริกเกอร์ กรองเฉพาะตอนที่ pull request ถูกเปิด แล้วเอเจนต์ผู้ตรวจสอบจะลงมือกับ diff ภายในไม่กี่วินาที เจ้าของการเปลี่ยนแปลงได้รับข้อเสนอแนะขณะที่เรื่องยังสดอยู่ในหัว

สืบหาสาเหตุของ build สีแดงโดยอัตโนมัติ

CI ของคุณส่ง POST ได้เมื่อ pipeline ล้มเหลว ทริกเกอร์จะเริ่มเอเจนต์โดยมี branch และ URL ของการทำงานนั้นอยู่ในคำสั่ง มันจึงอ่าน job ที่ล้มเหลวและกลับมาพร้อมสาเหตุ แทนที่จะเป็นแค่ป้ายสีแดง

คัดกรอง crash ในวินาทีที่มันถูกรายงาน

ต่อการแจ้งเตือนของ Sentry เข้ากับทริกเกอร์ exception ใหม่บน production จะเริ่มเอเจนต์ฝั่ง backend โดยมีหัวข้อของข้อผิดพลาดและ URL ของ issue นั้น การมองครั้งแรกที่ stack trace จึงเกิดขึ้นก่อนที่ใครจะเปิดแดชบอร์ดเสียอีก

เริ่มเอเจนต์จาก Slack

slash command ของ Slack หรือ outgoing webhook สามารถเรียกเข้า URL ของทริกเกอร์ได้ มีคนพิมพ์คำขอในแชนแนล payload ก็ไปลงในคำสั่ง แล้วเอเจนต์ก็รับงานต่อในโปรเจกต์ที่ถูกต้อง

กำหนดขอบเขตของ issue ใหม่ทันทีที่มันถูกแจ้งเข้ามา

issue ที่ถูกสร้างบน GitHub, GitLab หรือ Linear จะเริ่มเอเจนต์ฝั่งผลิตภัณฑ์ที่อ่านรายงานนั้น ถามคำถามในส่วนที่ขาดหายไป และเปลี่ยนมันให้เป็นสิ่งที่นักพัฒนาหยิบไปทำต่อได้

รัน QA pass หลังการ deploy ทุกครั้ง

ไปป์ไลน์ deploy ของคุณส่ง POST เมื่อมีรีลีสออกไป ทริกเกอร์จะเริ่มเอเจนต์ QA ที่ทดสอบแอปกับเวอร์ชันที่เพิ่งออกไปจริง ๆ แทนที่จะทำตามกำหนดเวลาที่ไม่เกี่ยวอะไรกับรีลีสเลย

เขียน release notes เมื่อมี tag

tag ถูก push รีลีสถูกเผยแพร่ แล้วเอเจนต์ด้านเอกสารก็เปลี่ยน commits ให้เป็นบันทึกที่อ่านรู้เรื่อง เหตุการณ์พกชื่อ tag มาด้วย เอเจนต์จึงรู้แน่ชัดว่าต้องสรุปช่วงไหน

อะไรก็ได้ที่ส่ง POST JSON ได้

ไม่ต้องรอรายชื่อการเชื่อมต่อใด ๆ cron บนเซิร์ฟเวอร์ ขั้นตอนหนึ่งใน Zapier เครื่องมือมอนิเตอร์ หรือ backend ของคุณเอง: ถ้ามันส่ง POST ที่มีลายเซ็นไปยัง URL ได้ มันก็เริ่มเอเจนต์ในโปรเจกต์ของคุณได้

ทริกเกอร์ webhook ทำงานอย่างไร ขั้นตอนต่อขั้นตอน

จากฟอร์มเปล่าไปสู่เอเจนต์ที่ตอบสนองต่อ production ได้ ในเวลาไม่กี่นาที

01

สร้างทริกเกอร์

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

02

สลับมันไปเป็น Webhook

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

03

วาง URL ลงในบริการนั้น

ใส่มันลงใน webhook ของ GitHub หรือ GitLab, แอป Slack, การเชื่อมต่อของ Linear หรือ Sentry หรือ CI ของคุณ ให้คีย์ลับสำหรับลงลายเซ็นกับบริการนั้นด้วย การเรียกที่มันส่งมาจะได้ตรวจสอบได้

04

กรองว่าอะไรควรทำให้ทำงานจริง ๆ

repository หนึ่งส่งเหตุการณ์มาเยอะมาก เพิ่มเงื่อนไขบน payload ที่จะใส่หรือไม่ก็ได้ เช่น action เท่ากับ opened แล้วอย่างอื่นจะถูกมองข้ามทั้งหมด ตั้งขีดจำกัดเหตุการณ์ทะลักไว้ด้วย บริการที่ส่งเสียงดังจะได้เริ่มเอเจนต์ยี่สิบตัวในหนึ่งนาทีไม่ได้

05

ใส่เหตุการณ์ลงในคำสั่งของคุณ

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

06

ส่งการเรียกล่าสุดซ้ำแล้วปล่อยใช้งานจริง

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

ตัวแก้ไขทริกเกอร์ของ AgentsRoom ในโหมด Webhook: URL ของทริกเกอร์ที่ถูกสร้างขึ้นเพื่อนำไปวางในบริการนั้นพร้อมปุ่ม Copy, ช่องคีย์ลับสำหรับลงลายเซ็น, ตัวเลือกแหล่งที่มาที่แสดง Any service (JSON), GitHub, GitLab, Slack, Linear และ Sentry, ตัวกรอง Only fire if ที่ตั้งไว้เป็น action == "opened", การตั้งค่าป้องกันเหตุการณ์ทะลักที่ให้ทำงานได้มากที่สุดหนึ่งครั้งต่อ 2 นาที และตัวแปรของเหตุการณ์ที่ใช้ได้ในคำสั่ง
ตัวแก้ไขทริกเกอร์ในโหมด Webhook: URL หนึ่งอันสำหรับนำไปวางในบริการนั้น คีย์ลับสำหรับลงลายเซ็น ตัวกรองที่จะใส่หรือไม่ก็ได้ ช่วงเวลาป้องกันเหตุการณ์ทะลัก และฟิลด์ของ payload ที่ถูกจับคู่กับตัวแปรในคำสั่งไว้เรียบร้อยแล้ว

แถวของบริการต่าง ๆ เป็นชุดทางลัด ไม่ใช่รายชื่อที่อนุญาต ตัวแก้ไขบอกไว้แบบนั้นใต้ตัวเลือก และด้วยเหตุผลเดียวกันนี้ รายการแรกจึงเป็น Any service (JSON): อะไรก็ตามที่ส่ง POST พร้อมเนื้อหาแบบ JSON ได้ก็ใช้งานได้ การเลือก GitHub, GitLab, Slack, Linear หรือ Sentry เพิ่มให้แค่สองอย่างเท่านั้น คือเฮดเดอร์ลายเซ็นของบริการนั้นไว้ตรวจสอบ และฟิลด์ payload ของมันที่ถูกจับคู่กับตัวแปรของเหตุการณ์ไว้แล้ว ไม่มีอะไรถูกปฏิเสธเพราะไม่อยู่ในรายชื่อ

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

จากเหตุการณ์สู่เอเจนต์ขั้นตอนที่ 1 จาก 4
  1. เหตุการณ์มาถึง URL ของทริกเกอร์คุณ

    บริการนั้นส่ง POST พร้อม JSON ของมัน AgentsRoom จะตรวจสอบลายเซ็นเทียบกับคีย์ลับของคุณและปฏิเสธทุกอย่างที่ไม่มีลายเซ็น จากนั้นจึงใช้ตัวกรองของคุณหากคุณตั้งไว้

  2. มันจะรอถ้าไม่มีใครอยู่

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

  3. เครื่องเดียวที่หยิบไป และมีเพียงเครื่องเดียวเท่านั้น
    Mac ที่ออฟฟิศ
    Mac ที่บ้าน
    เครื่อง build

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

  4. เอเจนต์ทำงาน หนึ่งครั้ง

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

URL สาธารณะที่ไม่ใช่ประตูที่เปิดทิ้งไว้

URL นี้เข้าถึงได้จากอินเทอร์เน็ต ทริกเกอร์จึงตัดสินว่าจะรับอะไรก่อนที่อะไรจะเริ่มทำงาน

ทุกการเรียกต้องมีลายเซ็น

AgentsRoom จะตรวจสอบทุกการเรียกเทียบกับคีย์ลับของคุณก่อนที่อะไรจะเริ่มทำงาน: X-Hub-Signature-256 สำหรับ GitHub, X-Slack-Signature สำหรับ Slack, โทเค็นร่วม X-Gitlab-Token สำหรับ GitLab และ HMAC ธรรมดาของเนื้อหาดิบสำหรับ Linear, Sentry และแหล่งทั่วไป การเรียกที่ไม่มีลายเซ็นจะถูกปฏิเสธ การรู้ URL อย่างเดียวจึงไม่พอที่จะเริ่มเอเจนต์บนเครื่องของคุณ

เปลี่ยนคีย์ลับเมื่อไหร่ก็ได้

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

กรองจาก payload

เงื่อนไขที่จะใส่หรือไม่ก็ได้จะตัดสินว่าเหตุการณ์นั้นคู่ควรกับเอเจนต์หรือไม่ ให้ทำงานเฉพาะเมื่อ action เท่ากับ opened เฉพาะบน branch เดียว หรือเฉพาะป้ายกำกับเดียว ทุกอย่างที่ไม่ตรงจะถูกทิ้งไปโดยไม่สร้างอะไรขึ้นมาเลย

การป้องกันเหตุการณ์ทะลัก

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

payload กลายเป็นคำสั่งของคุณ

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

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

  • {{event.title}}หัวข้อของเหตุการณ์: หัวข้อของ pull request หัวข้อของ issue ชื่อของการแจ้งเตือน
  • {{event.author}}ใครเป็นต้นเหตุ: ผู้เขียน pull request คนที่เปิด issue
  • {{event.url}}ลิงก์กลับไปยังเหตุการณ์ เพื่อให้เอเจนต์เปิด pull request หรือการแจ้งเตือนนั้นได้
  • {{event.number}}หมายเลขของ pull request หรือ issue เมื่อบริการนั้นส่งมาด้วย
  • {{event.branch}}branch ที่เหตุการณ์นั้นเกี่ยวข้อง สำหรับการ push, pull request หรือ build ที่ล้มเหลว
  • {{payload}}JSON ดิบทั้งก้อน สำหรับทุกอย่างที่ตัวแปรแบบมีชื่อครอบคลุมไม่ถึง
ตัวอย่างคำสั่ง
Review pull request #{{event.number}} "{{event.title}}" opened by {{event.author}} on branch {{event.branch}}. Read the diff at {{event.url}} and reply with the risky parts first.

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

GitHub
event.actionevent.numberevent.titleevent.bodyevent.authorevent.branchevent.baseevent.urlevent.repositoryevent.state
GitLab
event.actionevent.numberevent.titleevent.bodyevent.authorevent.branchevent.baseevent.urlevent.repositoryevent.state
Slack
event.actionevent.titleevent.bodyevent.authorevent.channelevent.urlevent.team
Linear
event.actionevent.numberevent.titleevent.bodyevent.authorevent.assigneeevent.stateevent.priorityevent.urlevent.team
Sentry
event.actionevent.titleevent.bodyevent.levelevent.projectevent.urlevent.count
Generic JSON
event.actionevent.titleevent.bodyevent.authorevent.urlevent.id

อะไรทำงานจริง และทำงานที่ไหน

โมเดลการทำงานที่ตรงไปตรงมาแบบเดียวกับงานที่กำหนดเวลา ขยายมาสู่เหตุการณ์

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

เหตุการณ์มาจากไหนบ้าง

อะไรก็ตามที่ส่ง POST พร้อมลายเซ็นและเนื้อหาแบบ JSON ได้ ก็เริ่มเอเจนต์ได้ นี่คือแหล่งที่คนต่อกันเป็นอันดับแรก ๆ

CI ของคุณ backend ของคุณ อะไรก็ได้

ขั้นตอนหนึ่งใน pipeline เครื่องมือมอนิเตอร์ บริการภายใน หรือสคริปต์เชลล์ที่ใช้ curl ไม่ต้องร้องขอการเชื่อมต่อใด ๆ ทั้งสิ้น: POST ที่มีเนื้อหาแบบ JSON และมีลายเซ็น คือสัญญาทั้งหมด

GitHub และ GitLab

pull requests และ merge requests ที่ถูกเปิด ถูกตรวจสอบ หรือถูก merge, issues ที่ถูกสร้าง, การ push, รีลีส, workflows ที่ล้มเหลว เป็นแหล่งคลาสสิก และเป็นแหล่งที่มี payload ใช้ประโยชน์ได้มากที่สุด

Slack

slash command หรือ outgoing webhook จะเปลี่ยนข้อความในแชนแนลให้เป็นการทำงานของเอเจนต์ในโปรเจกต์ที่ถูกต้อง ลายเซ็นของ Slack ตรวจสอบด้วย X-Slack-Signature

Linear และ Sentry

issue ที่ถูกย้ายไปอีกคอลัมน์ exception ใหม่บน production การแจ้งเตือนการถดถอย ตัวติดตามทำงาน เอเจนต์ก็เริ่มโดยมีตั๋วหรือข้อผิดพลาดนั้นอยู่ในคำสั่ง

อีกครึ่งหนึ่งของแผงเดียวกัน

ทริกเกอร์และงานที่กำหนดเวลาคือฟีเจอร์เดียวกันที่มีสองคำตอบต่อคำถามเดียวกัน งานที่กำหนดเวลาคือทริกเกอร์ที่มีเหตุการณ์เป็นนาฬิกา ทริกเกอร์ webhook คืองานที่กำหนดเวลาที่มีตารางเวลาเป็นโลกภายนอก ทั้งคู่อยู่ในรายการเดียวกัน ใช้การตั้งค่าเอเจนต์ชุดเดียวกัน สวิตช์เปิดใช้งานเดียวกัน ประวัติการทำงานเดียวกัน และขอบเขตรายเครื่องเดียวกัน

คุณจึงเลือกตามงาน ไม่ใช่ตามเครื่องมือ การตรวจสอบ dependencies ยังอยู่ที่เช้าวันจันทร์ เพราะไม่มีอะไรข้างนอกมาประกาศว่าแพ็กเกจหนึ่งเก่าไปแล้ว ส่วนการตรวจสอบ pull request ย้ายไปใช้ webhook เพราะ GitHub รู้อยู่แล้วว่ามันควรเกิดขึ้นวินาทีไหนพอดี อ่านหน้างานที่กำหนดเวลาเพื่อดูฝั่งนาฬิกาของครอบครัวเดียวกันนี้

ดูงานที่กำหนดเวลา ฝั่งนาฬิกาของแผงเดียวกัน

FAQ

ทริกเกอร์ webhook ใน AgentsRoom คืออะไร?

มันคือทริกเกอร์ที่เริ่มเอเจนต์ AI เมื่อบริการภายนอกส่งเหตุการณ์มาให้ แทนที่จะเริ่มตามเวลาที่ตั้งไว้ AgentsRoom จะให้ URL สาธารณะและคีย์ลับสำหรับลงลายเซ็นกับทริกเกอร์นั้น คุณวาง URL ลงใน GitHub, GitLab, Slack, Linear, Sentry หรือเครื่องมือใดก็ได้ที่ส่ง POST JSON ได้ เมื่อบริการนั้นเรียกเข้ามา ลายเซ็นจะถูกตรวจสอบ ตัวกรองที่คุณตั้งไว้จะถูกนำมาใช้ แล้วเอเจนต์จะเริ่มทำงานในโปรเจกต์ของคุณโดยมี payload พร้อมใช้เป็นตัวแปรในคำสั่งอยู่แล้ว

สิ่งนี้ต่างจากงานที่กำหนดเวลาอย่างไร?

เปลี่ยนแค่คำตอบของคำถามว่า 'สิ่งนี้ทำงานเมื่อไหร่' เท่านั้น งานที่กำหนดเวลาทำงานตามนาฬิกา: ทุก N นาที รายชั่วโมง รายวัน รายสัปดาห์ หรือรายเดือน ส่วนทริกเกอร์ webhook ทำงานเมื่อมีเหตุการณ์จากภายนอก ที่เหลือใช้ร่วมกันทั้งหมด: รายการเดียวกัน สวิตช์เปิดปิดเดียวกัน การตั้งค่าเอเจนต์ชุดเดียวกัน ประวัติรายการทำงานเดียวกัน และขอบเขตรายเครื่องเดียวกัน

ทำไมไม่ให้เอเจนต์วนถาม API เอาเลย?

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

เปิดเผย URL ของทริกเกอร์ได้อย่างปลอดภัยไหม?

ลำพัง URL อย่างเดียวไม่พอที่จะเริ่มอะไรได้ ทุกการเรียกต้องพิสูจน์ว่ามาจากบริการที่ถือคีย์ลับของคุณ: X-Hub-Signature-256 สำหรับ GitHub, X-Slack-Signature สำหรับ Slack, โทเค็นร่วม X-Gitlab-Token สำหรับ GitLab และ HMAC ธรรมดาของเนื้อหาดิบสำหรับ Linear, Sentry และแหล่งทั่วไป การเรียกที่ไม่มีเฮดเดอร์ลายเซ็นจะถูกปฏิเสธ ไม่มีการปล่อยผ่าน คีย์ลับแสดงอยู่ในตัวแก้ไขและสร้างใหม่ได้ตลอดเวลา ซึ่งจะทำให้สิ่งที่ใช้คีย์เก่าอยู่ใช้ไม่ได้ทันที

ให้ทำงานเฉพาะบางเหตุการณ์ได้ไหม?

ได้ repository ส่งเหตุการณ์มามากกว่าที่คุณอยากให้มีเอเจนต์มาก ทริกเกอร์จึงรับเงื่อนไขบน payload ที่จะใส่หรือไม่ก็ได้ เช่น action เท่ากับ opened เหตุการณ์ที่ไม่ตรงจะถูกมองข้ามและไม่มีอะไรถูกสร้างขึ้น นอกจากนี้ยังมีขีดจำกัดเหตุการณ์ทะลัก: ทำงานได้มากที่สุดหนึ่งครั้งต่อหนึ่งช่วงเวลา โดยการเรียกที่เข้ามาในช่วงเวลานั้นจะถูกรวมเข้าด้วยกัน

ถ้า AgentsRoom ปิดอยู่ตอนที่เหตุการณ์มาถึงจะเกิดอะไรขึ้น?

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

ฉันเปิดโปรเจกต์ไว้บนคอมพิวเตอร์สองเครื่อง เอเจนต์จะทำงานสองครั้งไหม?

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

ฉันเอาอะไรจากเหตุการณ์มาใส่ในคำสั่งได้บ้าง?

payload จะถูกแยกออกเป็นตัวแปรที่คุณเขียนลงในช่องคำสั่งได้โดยตรง โดยเขียนไว้ระหว่างวงเล็บปีกกาคู่: event.title, event.author, event.url, event.number, event.branch และ payload สำหรับ JSON ดิบทั้งก้อน พวกมันจะถูกแทนค่าตอนที่ทริกเกอร์ทำงาน แบบเดียวกับตัวแปรวันที่และเวลาของงานที่กำหนดเวลา

ฉันจะรู้ได้อย่างไรว่าต่อ webhook ถูกต้องแล้ว?

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

รองรับบริการอะไรบ้าง?

บริการใดก็ได้ที่ส่ง POST พร้อมลายเซ็นและเนื้อหาแบบ JSON ได้ GitHub, GitLab, Slack, Linear และ Sentry เป็นตัวที่คนต่อกันก่อนเพราะ payload ของพวกมันมีข้อมูลเยอะ แต่ไม่มีรายชื่อที่อนุญาตไว้: job ของ CI เครื่องมือมอนิเตอร์ backend ของคุณเอง หรือ curl ในสคริปต์เชลล์ ก็ทำงานได้เหมือนกันทุกประการ

นี่คือเครื่องมือสร้างระบบอัตโนมัติแบบวิชวลที่มีสถานการณ์หลายขั้นตอนหรือเปล่า?

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

AgentsRoom ส่ง webhook ออกไปยังบริการอื่นได้ไหม?

ทริกเกอร์เป็นขาเข้าเท่านั้น: AgentsRoom รับเหตุการณ์ ไม่ได้ส่งออก ถ้าคุณอยากให้เอเจนต์เรียกบริการภายนอกตอนจบการทำงาน นั่นเป็นหน้าที่ของตัวเอเจนต์เอง ด้วยเครื่องมือและเซิร์ฟเวอร์ MCP ที่คุณให้มันไว้

เข้ากันได้ดีกับ

งานที่กำหนดเวลา

ฝั่งนาฬิกาของแผงเดียวกัน ทุก N นาที รายชั่วโมง รายวัน รายสัปดาห์ หรือรายเดือน โดยไม่ต้องเขียนนิพจน์ cron

กระดานงาน Backlog

ลากตั๋วไปยังคอลัมน์แล้วเอเจนต์จะหยิบมันขึ้นมา ทริกเกอร์ทำสิ่งเดียวกัน โดยมีเหตุการณ์จากภายนอกเป็นคนลาก

ทีมเอเจนต์

เอเจนต์ Dev, QA และ PM ที่ส่งงานต่อกัน ชี้ทริกเกอร์ไปที่ทีมหนึ่ง แล้วเหตุการณ์เดียวจะเริ่มรูทีนทั้งชุด

AgentsRoom MCP

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

การแจ้งเตือนเอเจนต์

รู้ทันทีที่ทริกเกอร์ทำงาน ทั้งบนเดสก์ท็อปและบนโทรศัพท์ของคุณ แตะครั้งเดียวเพื่อเปิดเอเจนต์ที่มันเริ่มไว้

ฟลีตระยะไกล

หลายเครื่องบนบัญชีเดียว ปักหมุดทริกเกอร์ไว้กับเครื่องที่ควรตอบมัน แล้วจะมีเพียงเครื่องนั้นที่รันเอเจนต์

เลิกวนถาม เริ่มตอบสนอง

ดาวน์โหลด AgentsRoom วาง URL หนึ่งอันลงใน GitHub, GitLab, Slack, Linear หรือ Sentry แล้วปล่อยให้เหตุการณ์เป็นคนเริ่มเอเจนต์ ไม่มีอะไรทำงานตราบใดที่ไม่มีอะไรเกิดขึ้น

ฟรีดาวน์โหลด AgentsRoom

แอปคู่หู: ตรวจสอบเอเจนต์ของคุณได้ทุกที่

นำของคุณเอง: Claude, Codex, Antigravity CLI, หรือผู้ให้บริการ AI อื่น ๆ

รับส่วนขยาย
Chrome Web Store

ส่งข้อบกพร่องและคำขอไปยังแบ็คล็อกสาธารณะของคุณโดยตรง

มองเห็น AgentsRoom ในการทำงาน

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