การรันหนึ่งครั้งทำงานอย่างไร

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

1. ทริกเกอร์มาถึง

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

2. แซนด์บ็อกซ์เริ่มทำงาน

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

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

3. มันอ่านก่อนเขียน

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

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

4. เอเจนต์เขียนโค้ดตัวจริงลงมือทำ

ในแซนด์บ็อกซ์มีเอเจนต์เขียนโค้ดตัวจริงทำงานอยู่ — Claude Code, Codex หรือ Gemini ขึ้นกับบัญชีโมเดลของการรันนั้น มันมีเครื่องมือแบบเดียวกับนักพัฒนา: อ่านและแก้ไฟล์ รันคำสั่ง และรันเทสต์ของคุณ มันไม่ได้เติม diff ให้อัตโนมัติ แต่กำลังแก้ปัญหาจริง ๆ

5. แบรนช์ คอมมิต พุช เมิร์จรีเควสต์

ก็อบลินทำตามเวิร์กโฟลว์ที่ทีมคุณใช้อยู่แล้ว

1. มันทำงานบน แบรนช์เฉพาะ — 142-taskgoblin สำหรับอิชชู 142 บน GitLab หรือ GitHub, proj-123-taskgoblin สำหรับคีย์ของ Jira — ไม่เคยทำบนแบรนช์เริ่มต้นของคุณ
2. มันคอมมิตพร้อมลงลายมือชื่องานของตัวเองเพื่อให้ร่องรอยอ่านออก แล้วพุชแบรนช์
3. มันเปิด เมิร์จรีเควสต์ (GitLab) หรือ พูลรีเควสต์ (GitHub) แล้วรายงานลิงก์กลับไปยังที่ที่งานเริ่มต้น

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

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

6. มันรายงานตรงที่คุณดูอยู่แล้ว

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

7. มันจดสิ่งที่เกิดขึ้น

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

นี่คือเหตุผลที่ลูปสะสมแทนที่จะทำซ้ำ ดู สมอง

ความลับอยู่นอกเอเจนต์

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

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

เมื่อมีอะไรผิดพลาด

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

ไปต่อที่ไหน

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