คำตอบโดยสรุป: หากต้องการให้ AI agent ตรวจสอบ pull request ให้มอบหมายงานรีวิวให้กับ agent ตัวที่สองซึ่งมีคำสั่ง (instructions) ของตัวเอง มี checkout แยกต่างหาก และถ้าเป็นไปได้ควรใช้โมเดลคนละตัวกัน กำหนดให้ agent เริ่มทำงานโดยอัตโนมัติเมื่อสถานะงานเปลี่ยนเป็นพร้อมรีวิว ให้มันรันชุดทดสอบพร้อมแจ้งผลการตัดสินว่า PASS หรือ CHANGES REQUIRED แล้วส่งงานที่ไม่ผ่านกลับไปให้ builder แก้ไข โดยยังคงให้มนุษย์เป็นผู้กด merge
ทำไมคุณจึงควรให้ AI Agent ตรวจสอบ Pull Request ก่อนถึงมือคุณ
Pull request ทุกรายการที่เขียนโดย agent ต่างก็ส่งตรงมายังโต๊ะทำงานตัวเดียวกัน นั่นก็คือโต๊ะของคุณ หากมี agent เพียงตัวเดียวส่ง PR ชั่วโมงละรายการก็คงไม่เป็นปัญหา แต่เมื่อมี agent ทำงานพร้อมกันห้าตัว คิวงานจะสะสมเร็วกว่าความเร็วที่คุณอ่าน diff ได้ทัน และการตรวจรอบแรก (first pass) ก็จะกลายเป็นคอขวดทันที
Reviewer agent จะเข้ามารับหน้าที่ตรวจงานรอบแรกนี้ โดยไม่ได้มาแทนที่การตัดสินใจของคุณ แต่มันจะช่วยคัดกรอง PR ที่รันเทสต์ไม่ผ่าน ออกนอกขอบเขตของงาน หรือมีข้อมูลความลับรั่วไหลออกไป เพื่อให้ PR ที่ส่งมาถึงคุณนั้นคุ้มค่ากับเวลาที่ต้องเสียไปจริงๆ ใน Sharkly คุณสามารถตั้งค่าระบบนี้ได้โดยใช้ Agent เพิ่มอีกเพียง 1 ตัวและ Automations 2 รายการ ซึ่งคู่มือนี้จะพาคุณไปดูรายละเอียดในแต่ละส่วน
หากคุณต้องการทราบข้อจำกัดของการตรวจโค้ดอัตโนมัติก่อน สามารถอ่านเพิ่มเติมได้ที่ AI code review agent ตรวจสอบอะไรได้และไม่ได้บ้าง ส่วนบทความนี้จะเน้นไปที่ขั้นตอนการตั้งค่าระบบ
ทำไม Agent ตัวเดิมถึงตรวจโค้ดของตัวเองไม่ได้
Agent ที่เขียนโค้ดคือตัวเดียวกับที่สร้างบริบทและเหตุผลเบื้องหลังโค้ดนั้นขึ้นมา เมื่อคุณสั่งให้มันตรวจสอบงานของตัวเอง มันก็จะอ่านเหตุผลเดิมซ้ำและเห็นดีเห็นงามไปด้วย จุดบอดเดียวกับที่ทำให้เกิดบั๊กขึ้นมา ก็คือจุดบอดเดิมที่ใช้ในการรีวิวนั่นเอง
คุณจะเห็นปัญหานี้บ่อยที่สุดกับชุดทดสอบ โดย builder ที่ไม่สามารถทำให้เทสต์ผ่านได้อาจเลือกที่จะลดทอนเงื่อนไข assertion ลง แล้วถือว่างานเสร็จสิ้น ซึ่งเราได้รวบรวมรูปแบบเหล่านี้ไว้แล้วในบทความ วิธีจับไต๋ coding agent ที่โกงเทสต์ ในทางกลับกัน reviewer ที่ไม่มีส่วนได้ส่วนเสียกับผลลัพธ์จะอ่าน diff อย่างตรงไปตรงมาโดยไม่อิงอคติเดิม และตั้งคำถามที่ต่างออกไปว่า โค้ดที่แก้นี้ทำตามที่งานระบุไว้เป๊ะๆ และไม่มีการแก้ไขนอกเรื่องใช่หรือไม่
บทความแนวคิดการออกแบบ super-agent ของทีม DeepSeek Harness ก็ได้ข้อสรุปเกี่ยวกับการแบ่งบทบาทในลักษณะที่คล้ายกัน โดยกำหนดให้ Worker หลายตัวเชื่อมโยงอยู่กับ PR เดียวกัน มองเห็นความเคลื่อนไหวทั้งหมด และสามารถจัดการข้อขัดแย้งระหว่างกันได้ แม้นี่จะเป็นเพียงการออกแบบตัวต้นแบบที่ยังไม่ได้ปล่อยใช้งานจริง แต่แนวคิดนี้ใช้ได้ผลอย่างมาก เพราะการรีวิวจะมีประสิทธิภาพขึ้นเมื่อผู้ตรวจเป็นอีกฝ่ายที่แยกตัวเป็นอิสระ
ขั้นตอนที่ 1: แยก Builder และ Reviewer ออกจากกัน
สร้าง Agent แยกกันสองตัว ไม่ใช่สร้าง Agent ตัวเดียวแล้วสลับสองโหมด โดยแต่ละตัวจะมี instructions, repository และ execution target เป็นของตัวเอง
| Builder Agent | Reviewer Agent | |
|---|---|---|
| หน้าที่ | ทำตามที่โจทย์มอบหมายและเปิด PR | ตรวจประเมิน PR เทียบกับข้อกำหนดของงาน |
| เขียนโค้ดหรือไม่ | เขียน | ไม่เขียน |
| การ Push โค้ด | ไปยัง feature branch | ไม่ทำเด็ดขาด |
| Runtime | ตัวอย่างเช่น Claude Code | ถ้าเป็นไปได้ควรใช้ตัวอื่น เช่น Codex |
| ผลลัพธ์ที่ได้ | Branch, PR, คอมเมนต์สรุปงาน | คอมเมนต์รายงานผลการตัดสิน |
Sharkly Agent ไม่มีปุ่มให้เลือกโมเดลโดยตรง เนื่องจาก execution target จะประกอบด้วย Computer ร่วมกับ Runtime ที่ตรวจพบบนเครื่องนั้น ดังนั้นคำว่า “ใช้โมเดลคนละตัว” จึงหมายถึงการผูก reviewer เข้ากับ Runtime คนละตัวกัน การใช้ Runtime ที่สองจะช่วยนำมุมมองและพฤติกรรมอีกรูปแบบหนึ่งมาใช้ตรวจ diff โดยค่าใช้จ่ายในการรันแต่ละครั้งจะคิดตามแพ็กเกจที่ผูกอยู่กับ Runtime นั้นๆ อยู่แล้ว เพราะ Sharkly ไม่ได้ขายโทเคน
กำหนดไดเรกทอรีทำงานของ reviewer ให้เป็นโหมด Temporary ซึ่งใน เอกสาร Computers ได้อธิบายไว้ว่า การรันแต่ละครั้งจะได้รับไดเรกทอรีที่แยกจากกันอย่างเด็ดขาด และการรันกับ repository ก็สามารถเตรียม Git worktree ใหม่เอี่ยมขึ้นมาได้ Reviewer จะ checkout กิ่งของ PR ลงในสำเนาของตัวเอง จึงไม่มีทางไปเขียนทับไฟล์ของ builder แน่นอน บทความเรื่อง การรัน agent แบบขนานใน worktree ที่แยกจากกัน ของเราได้อธิบายไว้ว่าทำไมเรื่องนี้จึงสำคัญมากเมื่อมี agent หลายตัวทำงานร่วมกันใน repository เดียว
ขั้นตอนที่ 2: เขียนคำสั่ง (Instructions) ให้กับ Reviewer
Instructions ของ Agent จะกำหนดบทบาท รายการสิ่งที่ต้องตรวจสอบ และรูปแบบการรายงานผล ส่วนรายละเอียดเฉพาะเจาะจงของแต่ละงานจะคงไว้ที่ตัวงานนั้นๆ ควรเขียนคำสั่งของ reviewer ให้กระชับและทดสอบผลได้จริง:
You are the code reviewer for this Space. You never push, merge or edit files.
1. Read the triggering task. If it is not a code task in this Space, reply "not mine" and stop.
2. Find the linked pull request (the task ID appears in its title, description or branch).
3. Check out the PR branch in your worktree. Run the test command from the repo README.
4. Compare the diff to the task's acceptance criteria.
5. Post one verdict comment on the task in the format below. Nothing else.
ขั้นตอนแรกนั้นสำคัญกว่าที่คิด เนื่องจากในปัจจุบัน ตัวทริกเกอร์สถานะ (status trigger) และทริกเกอร์คอมเมนต์ (comment trigger) จะจับคู่เงื่อนไขทั่วทั้ง Organization ดังนั้น instructions จึงจำเป็นต้องยืนยันความถูกต้องของงานก่อนที่จะเริ่มลงมือ ซึ่งใน เอกสาร Automations ได้ระบุเรื่องนี้ไว้อย่างชัดเจน
ขั้นตอนที่ 3: เลือก Trigger
Automations ของ Sharkly จะรวม instructions, Agent หรือ Crew และ trigger ตั้งแต่หนึ่งรายการขึ้นไปเข้าด้วยกัน สำหรับการรีวิว PR มี trigger สองแบบที่เหมาะสม
การเปลี่ยนสถานะของงาน (Task status change) ให้เพิ่มสถานะ เช่น In Review เข้าไปในเวิร์กโฟลว์ของ Space เมื่อ builder เปิด PR เรียบร้อยแล้ว ก็จะย้ายงานมาที่สถานะนี้ และ reviewer ก็จะเริ่มทำงาน การรันที่ทริกเกอร์ด้วยสถานะจะสร้างการสนทนาขึ้นบนงานนั้น ทำให้ผลการตัดสินและการใช้โทเคนถูกบันทึกผูกไว้กับงานชิ้นนั้นโดยตรง
ภาพหน้าจอดังกล่าวคือระบบคัดกรองที่บล็อกนี้ใช้กับร่างบทความของตัวเอง นั่นคือเมื่องานเปลี่ยนสถานะเป็น Ready for Release ตัว reviewer Agent ก็จะเข้ามารับช่วงต่อทันที ซึ่งรูปแบบการทำงานนี้เหมือนกันทุกประการกับการรีวิวโค้ด
Webhook หากมีการเปิด PR จากภายนอกบอร์ดงานของคุณ ให้ตั้งค่า pull_request webhook ของ GitHub ให้ชี้มายัง URL สำหรับ webhook ของ Automation เมื่อเปิดใช้งานการตรวจสอบลายเซ็น Sharkly จะรองรับส่วนหัว X-Hub-Signature-256 ของ GitHub ด้วยเช่นกัน คุณจึงสามารถนำ signing secret ไปวางในช่อง Secret ของ GitHub ได้เลย ทั้งนี้ การรันผ่าน webhook จะไม่ได้ผูกกับงานบนบอร์ด ดังนั้น reviewer จะโพสต์ผลการตัดสินลงบนตัว PR โดยตรงผ่านทาง GitHub CLI แทน
ควรทดสอบการทำงานของแต่ละช่องทางด้วยคำสั่ง Run now ก่อนนำไปใช้งานจริงเสมอ
ขั้นตอนที่ 4: กำหนด Checklist ให้ Reviewer
Reviewer ที่ไม่มี checklist มักจะเขียนบรรยายยืดยาวเหมือนเรียงความ แต่ถ้ามี checklist มันจะระบุสิ่งที่ตรวจพบได้อย่างตรงจุด คำถาม 5 ข้อนี้ครอบคลุมการตรวจ PR จาก agent ส่วนใหญ่ได้ทั้งหมด:
- เทสต์รันผ่านทั้งหมดหรือไม่? Reviewer ต้องรันชุดทดสอบด้วยตัวเองเสมอ และไม่เชื่อคำสรุปจาก builder เพียงอย่างเดียว
- การแก้ไขอยู่ในขอบเขตเดิมหรือไม่? การแก้ไขไฟล์นอกเหนือจากขอบเขตของงานถือเป็นข้อผิดพลาดที่ตรวจพบ แม้ว่าการแก้นั้นจะดูไม่มีพิษมีภัยก็ตาม
- มีข้อมูลความลับรั่วไหลหรือไม่? เช่น โทเคน คีย์ หรือค่าต่างๆ ใน
.envที่ปรากฏใน diff หรือใน log - มีผลกระทบต่อโค้ดส่วนอื่นที่เรียกใช้หรือไม่ (Breaking changes)? เช่น การเปลี่ยน signature ของฟังก์ชัน การลบ endpoint หรือการทำ migration โดยไม่มีสคริปต์ rollback
- ชุดทดสอบถูกลดทอนประสิทธิภาพลงหรือไม่? เช่น การลบ assertion ทิ้ง การเพิ่มคำสั่ง skip หรือการปรับค่า expected values ให้หลวมขึ้น
หากมี reviewer Agent หลายตัวที่ต้องใช้รายการตรวจสอบเดียวกัน ให้เก็บ checklist นี้ไว้ใน Skill เพื่อให้การแก้ไขเพียงครั้งเดียวมีผลอัปเดตไปยัง agent ทุกตัว
ขั้นตอนที่ 5: กำหนดรูปแบบผลการตัดสินให้คงที่
ผลการตัดสินที่คนสามารถกวาดสายตาอ่านจบได้ใน 10 วินาทีย่อมดีกว่ารายงานละเอียดยิบที่ไม่มีใครยอมอ่าน จึงควรกำหนดโครงสร้างให้ตายตัว:
VERDICT: CHANGES REQUIRED
Tests: 41 passed, 2 failed (test_refund_rounding, test_refund_zero)
Scope: OK, 3 files, all under billing/
Secrets: none found
Breaking changes: refund() now raises on amount=0; two callers in api/ not updated
Weakened tests: none
Required:
1. Handle amount=0 in refund() or update both callers.
2. Fix the rounding in test_refund_rounding; do not change the expected value.
กรณีที่ผลเป็น PASS ก็จะใช้ฟิลด์เดียวกันนี้แต่เว้นรายการ Required ให้ว่างไว้ การกำหนดฟิลด์ให้คงที่ยังช่วยให้คุณนับและวัดผลการตัดสินได้ง่ายขึ้น คุณจะเห็นได้ว่าการตรวจสอบข้อใดที่ไม่ผ่านบ่อยที่สุด และสามารถนำไปปรับแก้ instructions ของ builder ให้รัดกุมยิ่งขึ้นตามลำดับ
ขั้นตอนที่ 6: เชื่อมลูปส่งงานกลับไปยัง Builder
เมื่อผลการตัดสินออกมาเป็น CHANGES REQUIRED ระบบควรสั่งให้ builder เริ่มทำงานแก้ไขใหม่โดยอัตโนมัติโดยที่คุณไม่ต้องคอยส่งต่อข้อความ ให้สร้าง Automation ตัวที่สองขึ้นมา มอบหมายให้กับ builder Agent และตั้งค่า comment trigger ให้ตรวจจับวลีที่เฉพาะเจาะจง
การตรวจจับคำในคอมเมนต์จะไม่แยกตัวพิมพ์เล็ก-พิมพ์ใหญ่ (case-insensitive) และจะทำงานทันทีเมื่อพบวลีดังกล่าวในส่วนใดก็ตามของคอมเมนต์ ให้เลือกวลีที่ไม่มีใครพิมพ์โดยไม่ตั้งใจ และสั่งให้ reviewer เขียนวลีนี้เฉพาะในบรรทัด CHANGES REQUIRED เท่านั้น นอกจากนี้ หาก builder โควต์ข้อความดังกล่าวซ้ำในคำตอบของตัวเองก็อาจทำให้เกิดการทริกเกอร์ตัวเองซ้ำได้ จึงต้องกำชับ builder ไม่ให้พิมพ์วลีนี้ซ้ำเป็นอันขาด
กำหนดขีดจำกัดของลูปการทำงาน ให้จำกัดการรีวิวและแก้ไขไว้ที่ไม่เกิน 2 รอบ หลังจากนั้นให้ reviewer ส่งมอบงานต่อให้มนุษย์พร้อมแนบผลการตัดสินครั้งล่าสุดไปด้วย
สิ่งที่มนุษย์ยังต้องเป็นผู้ควบคุมดูแล
คุณยังคงเป็นผู้ถือสิทธิ์การกด merge แต่เพียงผู้เดียว ในส่วนของ การเชื่อมต่อกับ GitHub ของ Sharkly นั้น task ID ในชื่อ PR จะทำหน้าที่เชื่อมโยง PR เข้ากับงาน และการ merge จะไม่เปลี่ยนสถานะของงานโดยอัตโนมัติ จะไม่มีโค้ดตัวใดถูก deploy เพียงเพราะ agent ตัดสินว่า PASS
ควรเสริมความปลอดภัยใน GitHub ไว้ด้วยอีกชั้นหนึ่ง โดยการตั้งค่า protected branches ที่กำหนดให้ต้องมีมนุษย์อนุมัติ เพื่อป้องกันไม่ให้ reviewer กลายเป็นปราการด่านสุดท้าย นอกจากนี้ คุณยังต้องเป็นผู้ตัดสินใจในเรื่องที่ checklist ไม่สามารถประเมินได้ เช่น สถาปัตยกรรมนี้ถูกต้องเหมาะสมหรือไม่ และฟีเจอร์นี้ควรมีอยู่จริงแต่แรกหรือไม่ หากต้องการดูวิธีจัดลำดับความสำคัญของงานที่ส่งมาถึงคุณ สามารถอ่านเพิ่มเติมได้ที่ การจัดลำดับคิว PR จาก agent และ ทำไมการรีวิวโดยมนุษย์ถึงเป็นคอขวด
สรุป
PR จาก agent จะไม่กองท่วมโต๊ะทำงานของคุณอีกต่อไป เมื่อมี agent ตัวที่สองมารับหน้าที่ตรวจรอบแรกให้ เพียงแยก builder และ reviewer ออกจากกัน กำหนด worktree และ Runtime แยกให้ reviewer สั่งให้เริ่มทำงานผ่านการเปลี่ยนสถานะหรือ webhook และกำหนดให้ตอบคำถามคงที่ 5 ข้อในรูปแบบที่ตายตัว ส่งงานที่ไม่ผ่านกลับไปด้วยวลีคอมเมนต์เฉพาะ จำกัดลูปการทำงานไว้ไม่เกิน 2 รอบ และสงวนสิทธิ์การกด merge ไว้กับตัวคุณเอง
หากคุณรัน coding agent 10 ตัวพร้อมกัน อยู่แล้ว นี่คือจิ๊กซอว์ชิ้นต่อไปที่คุณควรเพิ่มเข้ามา เริ่มต้นใช้งาน Sharkly ฟรี แล้วสร้าง reviewer Agent เป็นขั้นตอนแรกได้เลย
คำถามที่พบบ่อย (FAQ)
AI Agent สามารถตรวจสอบ Pull Request ของตัวเองได้หรือไม่?
สามารถทำได้ แต่จะตรวจจับข้อผิดพลาดได้น้อยกว่ามาก เพราะตัว agent มีสมมติฐานเดิมแบบเดียวกับตอนที่เขียนโค้ด การใช้ reviewer แยกต่างหากที่มี instructions เป็นของตัวเอง และถ้าเป็นไปได้ควรใช้ Runtime คนละตัว จะช่วยให้อ่าน diff ได้โดยไม่มีอคติดังกล่าว
Reviewer ควรใช้โมเดลคนละตัวกับ Builder หรือไม่?
ควรทำอย่างยิ่งหากเป็นไปได้ ใน Sharkly ตัวโมเดลจะขึ้นอยู่กับ Runtime ดังนั้นให้ผูก reviewer Agent เข้ากับ Runtime คนละตัวกับ builder เช่น ให้ Codex เป็นผู้ตรวจสอบงานที่ Claude Code เขียน
สิ่งที่ AI Code Reviewer ควรตรวจสอบเป็นอันดับแรกคืออะไร?
ชุดทดสอบ (Tests) โดยให้มันรันชุดทดสอบด้วยตัวเองแล้วรายงานจำนวนเคสที่ผ่านและไม่ผ่าน จากนั้นจึงตรวจสอบเรื่องขอบเขตของงาน ข้อมูลความลับ ข้อผิดพลาดต่อระบบเดิม (breaking changes) และการลดทอนความเข้มงวดของชุดทดสอบ ตามลำดับ
Reviewer Agent สามารถอนุมัติและ Merge PR เลยได้หรือไม่?
ไม่ควรให้สิทธิ์นั้น ให้สงวนสิทธิ์การ merge ไว้กับมนุษย์ผ่านการตั้งค่า branch protection โดยให้ reviewer ทำหน้าที่เพียงคอมเมนต์ผลการตัดสิน ส่วนการตัดสินใจขั้นสุดท้ายให้เป็นหน้าที่ของคน
จะป้องกันไม่ให้ Review Loop วนทำงานไม่รู้จบได้อย่างไร?
จำกัดไว้ที่ 2 รอบใน instructions ของ reviewer และใช้วลีในคอมเมนต์ที่ builder จะไม่พิมพ์ซ้ำ เมื่อครบจำนวนรอบที่จำกัดไว้ reviewer จะส่งต่องานให้กับมนุษย์
วิธีนี้ใช้กับ GitHub Pull Request ที่เปิดจากภายนอก Sharkly ได้หรือไม่?
ได้ โดยเชื่อมต่อ GitHub webhook เข้ากับ webhook trigger ของ Automation ซึ่ง Sharkly รองรับ signature header ของ GitHub เมื่อเปิดใช้งานการตรวจสอบความถูกต้อง
