เอเจนต์รีวิวไม่ควรเขียนอะไรได้เลย นี่คือวิธีที่เราบังคับใช้ ทีละ CLI

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

สามอย่างเกิดขึ้นในการรันนั้น ตามลำดับนี้

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

จากนั้นเอเจนต์รีวิวสองตัว บนสาขาคู่ขนานสองสายของการรันเดียวกัน ต่างเจอบั๊กจริงขนาดหนึ่งบรรทัด แต่ละตัวแก้มันตรง ๆ ใน worktree เดียวกัน ในเวลาเดียวกัน แล้วก็ชนกัน

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

ทำไมพรอมต์ถึงเอาไม่อยู่

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

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

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

ทำไมการตั้งค่าแบบ global ก็ทำไม่ได้เหมือนกัน

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

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

กฎ: เช็กบ็อกซ์หนึ่งช่องบนโหนด

การแก้ไขคือค่า boolean บนโหนดรีวิว ติ๊ก อ่านอย่างเดียว แล้วเอเจนต์ที่รับบทขั้นตอนนั้นจะถูกเปิดโดยไม่มีสิทธิ์เขียนลงโปรเจกต์: ไม่มีการแก้ไฟล์ ไม่มี git commit หรือ push ไม่มีคำสั่งเชลล์ที่หน้าที่เดียวของมันคือเปลี่ยน working tree การอ่าน, grep, git diff, git log, เทสต์, ลินเทอร์ และเครื่องมือของทีมทุกอย่างยังเปิดอยู่

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

แต่ละ CLI ทำอะไร อ่านจาก help ของมันเอง

เราบังคับใช้เฉพาะกับโปรไวเดอร์ที่เราอ่านแฟล็กจาก --help ของมันเองเท่านั้น แฟล็กที่เดามาจะฆ่าการเปิดใช้งานด้วยข้อผิดพลาดตอนพาร์ส ซึ่งแย่กว่าขั้นตอนที่ไม่มีการบังคับ CLI ตัวอื่นได้แค่กฎที่เป็นตัวหนังสือ และตัวแก้ไขบอกไว้เป็นข้อความธรรมดาใต้เช็กบ็อกซ์

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

Codex และ Grok ปฏิเสธแฟล็กที่ซ้ำกัน ทั้งคู่พาร์สอาร์กิวเมนต์ด้วยพาร์เซอร์ที่เข้มงวด ถ้าผู้ใช้เก็บ --sandbox workspace-write ไว้บนเอเจนต์อยู่แล้ว การต่อท้ายด้วย --sandbox read-only จะไม่ทับค่าเดิม แต่จะทำให้การเปิดใช้งานพัง ดังนั้นสำหรับแฟล็กที่มีค่า เราจะลบทุกอันที่มีอยู่แล้ว พร้อมค่าของมัน ก่อนต่อท้ายด้วยของเรา เหมือนกันกับ --agent บน OpenCode ที่พาร์เซอร์เปลี่ยนแฟล็กซ้ำให้กลายเป็นอาร์เรย์แล้วไปพังต่อในขั้นถัดไป

บน Claude Code รายการต้องซ้อนกันได้ --disallowedTools รับรายการที่คั่นด้วยช่องว่างและใส่ซ้ำได้ และเราส่งไปหนึ่งชุดอยู่แล้วเมื่อเอเจนต์ไม่ได้รับอนุญาตให้ควบคุมเบราว์เซอร์ที่ฝังอยู่ พาร์เซอร์จะต่อออปชันแบบ variadic ที่ซ้ำกันเข้าด้วยกัน ดังนั้นสองรายการจึงบวกกัน แทนที่อันหลังจะมาแทนอันแรก

รายการเต็มสำหรับ Claude Code คือเครื่องมือแก้ไฟล์สี่ตัว คำสั่งย่อยของ git ทุกตัวที่เขียนลง index, tree, refs หรือ remote (add, commit, push, merge, rebase, reset, checkout, switch, restore, stash, cherry-pick, revert, apply, am, rm, mv, clean, tag, worktree) และคำสั่งเชลล์ที่มีอยู่เพื่อเปลี่ยนไฟล์เท่านั้น (rm, mv, cp, tee, touch, mkdir, chmod, chown, ln, truncate, dd, sed -i) Grok รับสตริงกฎชุดเดียวกัน ในรูปแบบ glob ของมัน บวกกับชื่อเครื่องมือไฟล์ของมันเอง (search_replace, write, hashline_edit)

พรอมต์ยังมีงานของมันอยู่

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

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

บน CLI ที่มีแฟล็กยืนยันแล้ว ย่อหน้านั้นคือสิ่งที่ทำให้การปฏิเสธเป็นที่เข้าใจ บนตัวอื่น มันคือการบังคับใช้ทั้งหมดที่มี และเราขอพูดตรง ๆ แบบนั้นดีกว่าแกล้งทำ

ใครอ่านอย่างเดียวในเทมเพลตที่ส่งมอบ

โหนดที่ ตัดสิน เป็นแบบอ่านอย่างเดียว: ขั้นตอนตรวจสอบ QA ของเทมเพลตเริ่มต้นสองชุด ขั้นตอนทำซ้ำและตรวจสอบของ Bug hunt สาขา QA และ Security ของ Release shield และผู้ทดสอบของ Feature squad

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

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

สิ่งนี้ไม่ใช่อะไร

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

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

สิ่งที่เรายังไม่ได้สร้าง

ผู้รายงานขออีกอย่างหนึ่ง: อีเวนต์ในไทม์ไลน์ของการรันที่บอกว่า "โหนด X เขียนลง tree" เป็นสัญญาณขั้นต่ำแม้ไม่มีการบังคับ เป็นไอเดียที่ดีและเรายังไม่ได้ทำในรอบนี้ เพราะมันต้องมี diff ฐานต่อขั้นตอนอยู่ฝั่งรันเนอร์ ถ้าความต้องการนี้กลับมา นั่นคือชิ้นถัดไป

ถ้าคุณไม่ได้ใช้ AgentsRoom

แฟล็กข้างบนคัดลอกไปใช้ได้ตามนั้นเลย เอเจนต์รีวิวที่เปิดด้วยมือด้วย codex --sandbox read-only หรือ claude --disallowedTools "Edit" "Write" "MultiEdit" "NotebookEdit" "Bash(git commit:*)" "Bash(git push:*)" ทำสิ่งที่โหนดรีวิวสองตัวของเราทำไม่ได้ ใส่สองประโยคเดียวกันลงในพรอมต์ของมัน เพื่อให้มันรู้ว่าทำไมมันถึงถูกปฏิเสธ

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

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