คุณมอบงานเล็ก ๆ ให้เอเจนต์เขียนโค้ดสักงาน: แก้เทสต์ที่รันไม่ผ่าน ยี่สิบนาทีต่อมา มันเขียนไฟล์ใหม่อีกสามไฟล์ที่ไม่เกี่ยวข้องกันเลย รัน database migration ใส่ DATABASE_URL อะไรก็ตามที่มันเจอในเชลล์ของคุณ และ force push ขึ้น branch ที่คนอื่นกำลังใช้อยู่ ไม่มีอะไรในพรอมป์ต์ที่สั่งให้ทำแบบนั้นเลย เอเจนต์มีอิสระเต็มที่บนเครื่อง มันจึงใช้อิสระนั้นเต็มที่
สิทธิ์ (permissions) คือวิธีที่คุณตัดสินใจล่วงหน้าว่าเอเจนต์แตะต้องอะไรได้บ้าง สิทธิ์ของเอเจนต์เขียนโค้ดคือกฎที่บอกว่าไฟล์ คำสั่ง ข้อมูลรับรอง และ repository ใดที่เอเจนต์หนึ่งเข้าถึงได้ระหว่างการรัน และจุดไหนที่คนต้องเข้ามาเกี่ยวข้อง ถ้าตั้งไว้ดี เอเจนต์ที่ออกนอกลู่นอกทางจะล้มเหลวอย่างปลอดภัยอยู่ในกรอบที่คุณวาดไว้ ถ้าตั้งผิด การรันที่พลาดแค่ครั้งเดียวก็ไปถึง production ได้
บทความนี้จะพาไล่ดูโมเดลสิทธิ์ทีละชั้น ระบุโหมดความล้มเหลวในแต่ละขั้น และปิดท้ายด้วยเช็กลิสต์ที่คุณนำไปใช้ได้วันนี้ โดยใช้ Sharkly เพื่อให้แต่ละชั้นเห็นภาพชัดเจน เพราะหน้าที่ของ Sharkly คือวางตัวอยู่เหนือเอเจนต์เขียนโค้ดของคุณและดูแลขอบเขตนี้ไว้ในที่เดียว คุณมีเอเจนต์เขียนโค้ดอยู่แล้ว Sharkly เปลี่ยนพวกมันให้เป็นทีม และทีมย่อมต้องการกฎว่าคนไหนทำอะไรได้บ้าง
สามชั้นที่สิทธิ์ของเอเจนต์อาศัยอยู่
สิทธิ์ของเอเจนต์เขียนโค้ดไม่ใช่การตั้งค่าเดียว มันอยู่สามที่ และช่องโหว่ในที่ใดที่หนึ่งก็ทำลายอีกสองที่ที่เหลือได้
- รันไทม์ เป็นตัวกำหนดว่าเอเจนต์เรียกใช้เครื่องมือใดได้บ้าง: อ่านไฟล์ แก้ไฟล์ รันคำสั่งเชลล์ ออกเครือข่าย นี่คือ Claude Code, Codex, Gemini CLI หรือเอเจนต์ตัวไหนก็ตามที่ลงมือทำงาน
- เครื่อง เป็นตัวกำหนดว่าเครื่องมือเหล่านั้นเข้าถึงอะไรได้บ้าง: ไดเรกทอรีไหน ข้อมูลรับรองไหน ตัวแปรสภาพแวดล้อมไหน เครือข่ายไหน Computer ใน Sharkly “ให้ระบบปฏิบัติการ ไฟล์ ข้อมูลรับรอง การเข้าถึงเครือข่าย และเครื่องมือที่ Agent ต้องการ” ดังนั้นเครื่องจึงเป็นรัศมีผลกระทบที่แท้จริง
- งาน เป็นตัวกำหนดขอบเขตของเจตนา: การรันนี้จำกัดอยู่ที่ repository ไหน เอเจนต์ตั้งสถานะอะไรได้บ้าง และจุดที่คนยอมรับผลลัพธ์
มีขอบเขตหนึ่งที่ควรพูดให้ชัด: สิทธิ์ไม่ใช่ประตูอนุมัติ สิทธิ์คือสิ่งที่เอเจนต์ทำได้ ส่วนประตูอนุมัติคือจุดที่คนตัดสินใจ คุณต้องมีทั้งสองอย่าง สิทธิ์ที่คับแคบแต่ไม่มีประตูอนุมัติหมายความว่าไม่มีใครตรวจผลลัพธ์ ส่วนประตูอนุมัติที่มาพร้อมสิทธิ์หลวม ๆ ก็หมายความว่าความเสียหายเกิดขึ้นเรียบร้อยแล้วกว่าจะมีใครได้ดู
ขั้นที่ 1: กำหนดขอบเขตเครื่องมือของรันไทม์
เริ่มจากจุดที่เอเจนต์ลงมือทำ เอเจนต์เขียนโค้ดส่วนใหญ่มาพร้อมระบบสิทธิ์อยู่แล้ว: มี allow list และ deny list ของเครื่องมือ บวกกับพรอมป์ต์ถามก่อนจะรันอะไรที่ทำลายได้ ตัวอย่างเช่น Claude Code เปิดให้คุณอนุญาตหรือปฏิเสธเครื่องมือเฉพาะเจาะจง และถามก่อนรันคำสั่งเชลล์ ชื่อการตั้งค่าแบบเป๊ะ ๆ แตกต่างกันไปตามรันไทม์และเปลี่ยนบ่อย ดังนั้นควรอ่านเอกสารปัจจุบันของเอเจนต์คุณ แทนที่จะเชื่อ snippet ที่เจอเมื่อปีที่แล้ว
ค่าตั้งต้นที่ปลอดภัยคือใจกว้างเรื่องการอ่าน และขี้เหนียวเรื่องการเขียน ให้เอเจนต์อ่าน repo รันเทสต์ typecheck และ build ได้โดยไม่ต้องถาม ส่วนการแก้ไฟล์และคำสั่งเชลล์ให้กั้นไว้หลังพรอมป์ต์หรือ allow list ที่ระบุชัดเจน
โหมดความล้มเหลวนี้มีชื่อเรียก และเป็นอันที่ทุกคนคว้ามาใช้เมื่อเจอแรงกดดันเรื่องเดดไลน์ นั่นคือโหมดข้ามทุกอย่าง ทุกรันไทม์มีแฟล็กที่ปิดพรอมป์ต์ทั้งหมด และมันสะดวกมากสำหรับเซสชันที่มีคนคอยคุม อันตรายคือการเปิดมันทิ้งไว้ตอนรันแบบไม่มีคนเฝ้า เอเจนต์ที่ไม่ต้องถามอะไรเลย ทำงานตามแผนที่ปรากฏว่าผิด จะลบสิ่งที่มันเข้าใจผิดอย่างสบายใจ ใช้โหมดตอบรับอัตโนมัติตอนที่คุณนั่งดูอยู่ และปิดมันตอนที่คุณลุกออกไป
ขั้นที่ 2: กำหนดขอบเขตเครื่องและข้อมูลรับรอง
รายการเครื่องมือของรันไทม์ไม่มีค่าอะไรเลยถ้าเครื่องยื่นทุกอย่างให้เอเจนต์ เอเจนต์ที่ได้รับอนุญาตให้รันคำสั่งเชลล์บนเครื่องที่คุณใช้ทำงานทุกวันสามารถอ่าน SSH key ทุกตัว .env ทุกไฟล์ และข้อมูลรับรองทุกอย่างที่ล็อกอินของคุณเข้าถึงได้ โหมดความล้มเหลวนี้เงียบ: ไม่มีอะไรดูผิดปกติจนกว่าเอเจนต์จะใช้คีย์ production ที่มันไม่ควรเห็นเลย
มีสองการเคลื่อนไหวที่ช่วยลดรัศมีผลกระทบ อย่างแรก ให้รันเอเจนต์ในที่ที่มีขอบเขตจำกัด แทนที่จะรันบนแล็ปท็อปที่คุณเก็บความลับจริง ๆ ไว้ Sharkly ลงทะเบียน Computer ด้วยโทเคนติดตั้งที่อายุสั้นและใช้ได้ครั้งเดียว และเอกสารก็พูดตรง ๆ ว่า อย่าใส่โทเคนนั้นในอิมเมจ สคริปต์ Task หรือคอมเมนต์ที่นำกลับมาใช้ซ้ำได้ ไม่ว่า Computer จะเป็นคอนเทนเนอร์ เซิร์ฟเวอร์ หรือเครื่องสำรอง การเข้าถึงของเอเจนต์ก็คือการเข้าถึงของสภาพแวดล้อมนั้น ไม่ใช่ของคุณ ถ้าอยากให้เอเจนต์ทำงานตอนที่คุณออฟไลน์ ให้รันมันบน Computer ระยะไกลแทนที่จะรันบนแล็ปท็อปที่เปิดอยู่
อย่างที่สอง ส่งมอบเฉพาะสิ่งที่การรันนั้นต้องการ สภาพแวดล้อมของการรันใน Sharkly ประกอบขึ้นจากคอนฟิกูเรชันที่ระบุชัดเจน: repository ที่ผูกไว้ ตัวแปรสภาพแวดล้อม การผูก secret และ working directory ผูก repository เข้ากับ Agent เมื่อมันต้องการขอบเขตโค้ดที่แคบกว่าค่าเริ่มต้นของ Space เพื่อที่ Agent ฝั่ง frontend จะไม่ไปเช็กเอาต์บริการ billing เก็บแต่ละการรันไว้ในworktree แยกของตัวเอง ซึ่งเป็นความต่างระหว่างการแก้ไขที่แย่ครั้งหนึ่งซึ่งจำกัดอยู่ในเช็กเอาต์เดียว กับเอเจนต์สองตัวทำ working tree เดียวกันพังไปด้วยกัน กฎประจำบ้านใช้กับทุกฟิลด์: กรอกเฉพาะคอนฟิกูเรชันที่ผลิตภัณฑ์ร้องขอ และอย่าวางรหัสผ่านหรือโทเคนลงในฟิลด์หรือคำสั่งเริ่มต้นที่ไม่เกี่ยวข้อง
ขั้นที่ 3: กำหนดขอบเขตงาน และเก็บการ merge ไว้ให้คนตัดสิน
ชั้นสุดท้ายคือเจตนา ต่อให้เอเจนต์ถูก sandbox อย่างถูกต้องและมีข้อมูลรับรองที่จำกัดขอบเขตแล้ว มันก็ยังทำงานผิดได้: มาร์กงานของตัวเองว่าเสร็จ ดันการเปลี่ยนแปลงที่ทำค้างไว้เข้า shared branch หรือตัดสินว่า PR พร้อม merge แล้ว
นี่คือจุดที่สัญญาระหว่างคนกับเอเจนต์เข้ามาเกี่ยวข้อง เอเจนต์ค้นคว้า ลงมือทำ ทดสอบ และรายงาน คนเป็นคนกำหนดทิศทาง ให้อำนาจ และยอมรับผลลัพธ์ ระบบอัตโนมัติหยุดตรงจุดที่ต้องใช้วิจารณญาณของทีม เอเจนต์ควรได้รับอนุญาตให้เปิด draft PR และแนบผลการทดสอบไปด้วย แต่มันไม่ควรอนุมัติ PR นั้นหรือ merge เข้า protected branch ของคุณ การป้องกัน branch ที่ฝั่งโฮสต์ และการรีวิวโดยคนในระดับงาน คือสองกลอนที่ทำให้เส้นนี้ยังอยู่ครบ
ใน Sharkly ตัวงานมีขีดจำกัดนี้อยู่ในตัวเอง Task type Workflow กำหนดว่า Agent เลือกสถานะใดได้บ้าง Agent จึงย้ายงานเข้าไปในสถานะ “Done” หรือ “Released” ที่คนเป็นเจ้าของอย่างเงียบ ๆ ไม่ได้ เมื่อ Agent ต้องการการตัดสินใจ มันจะทิ้ง Task ให้รอการรีวิวโดยคนหรือรอคำตอบจากคน และสิ่งนั้นจะปรากฏใน Inbox ให้คนที่รับผิดชอบยอมรับ ขอแก้ไข หรือมอบหมายใหม่ การลงมือทำ อุปสรรค ผลลัพธ์ และการรีวิว ทั้งหมดกลับมาอยู่ใน Task เดียว แทนที่จะกระจัดกระจายอยู่ตามห้าเทอร์มินัล
นี่ก็เป็นจุดที่การตั้งเองด้วยมือหยุดขยายเช่นกัน เอเจนต์ตัวเดียว repo เดียว วิศวกรที่รอบคอบคนเดียว: คุณจำโมเดลสิทธิ์ทั้งหมดไว้ในหัวได้ พอเพิ่มเอเจนต์ตัวที่สองและสาม มี repository มากขึ้น และมีเพื่อนร่วมทีม คำถามที่ว่า “แต่ละเอเจนต์ทำอะไรได้บ้างตรงนี้” ก็กลายเป็นคำถามที่ไม่มีใครตอบจากความจำได้ กระดานงานเปลี่ยนกฎเหล่านั้นให้เป็นคอนฟิกูเรชันที่แชร์กันและตรวจสอบได้: ใครมอบหมายงาน ขอบเขตของการรันเป็นอย่างไร มีหลักฐานอะไรกลับมา และใครยอมรับมัน นั่นคือชั้นการจัดการที่อยู่เหนือเอเจนต์เขียนโค้ดของคุณ คุณจะสร้างมันเองด้วย worktree ข้อมูลรับรองที่มีขอบเขต และ branch protection หรือจะรันเอเจนต์เขียนโค้ดที่มีอยู่ผ่าน Sharkly แล้วจัดการสิทธิ์ งาน และการรีวิวในที่เดียวก็ได้
เช็กลิสต์สิทธิ์ที่คุณใช้ได้วันนี้
ไล่ดูรายการนี้สำหรับเอเจนต์ทุกตัวที่คุณปล่อยให้แตะ repository จริง:
- รันไทม์: อนุญาตให้อ่านและรันเทสต์โดยไม่ต้องถาม; กั้นการแก้ไขและคำสั่งเชลล์; ปิดโหมดข้ามทุกอย่างสำหรับการรันที่ไม่มีคนเฝ้า
- เครื่อง: เอเจนต์รันบน Computer ที่มีขอบเขต ไม่ใช่เครื่องที่คุณใช้ทำงานทุกวัน; โทเคนติดตั้งและการเข้าถึงใช้ครั้งเดียวและไม่ถูกคอมมิต
- ข้อมูลรับรอง: ใช้เฉพาะตัวแปรสภาพแวดล้อมและการผูก secret ที่การรันนี้ต้องใช้ ไม่มีอะไรถูกแปะลงในฟิลด์ที่ไม่เกี่ยวข้อง
- ขอบเขต repository: เอเจนต์ผูกกับ repo ที่งานต้องใช้ ไม่ใช่ทุก repo ใน Space
- การแยกส่วน: การรันแต่ละครั้งได้ worktree ของตัวเอง เพื่อที่การเปลี่ยนแปลงที่แย่จะทำเช็กเอาต์ที่ใช้ร่วมกันพังไม่ได้
- ขอบเขตงาน: เอเจนต์ตั้งสถานะระหว่างทำงานได้ แต่ย้ายงานไปสู่สถานะที่ยอมรับแล้วหรือปล่อยแล้วซึ่งคนเป็นเจ้าของไม่ได้
- การ merge: branch protection บวกกับการรีวิวโดยคนพร้อมหลักฐานระดับงาน คั่นอยู่ระหว่าง PR ของเอเจนต์กับ main
ถ้าบรรทัดไหนหลวม ให้ขันให้แน่นก่อนการรันครั้งถัดไป ไม่ใช่หลังเกิดเหตุการณ์ที่สอนคุณว่ามันสำคัญจริง
คำถามที่พบบ่อย
สิทธิ์ของเอเจนต์เขียนโค้ดกับประตูอนุมัติต่างกันอย่างไร? สิทธิ์กำหนดว่าเอเจนต์ทำอะไรได้ในทางเทคนิค: เข้าถึงไฟล์ คำสั่ง และข้อมูลรับรองใดได้บ้าง ประตูอนุมัติคือจุดที่คนตัดสินใจว่าจะยอมรับสิ่งที่เอเจนต์ทำหรือไม่ คุณต้องมีทั้งคู่ เพราะต่อให้สิทธิ์คับแคบ ก็ยังมีงานที่คนควรเซ็นอนุมัติ และประตูอนุมัติก็ช่วยอะไรไม่ได้ถ้าเอเจนต์มีสิทธิ์ก่อความเสียหายอยู่แล้ว
ควรให้เอเจนต์เขียนโค้ด merge PR ของตัวเองได้ไหม? ไม่ อย่างน้อยก็ไม่ใช่โดยค่าเริ่มต้น ให้เอเจนต์เปิด draft PR และแนบผลการตรวจสอบไปด้วย แล้วปล่อยการ merge ให้คนหรือการรีวิวที่บังคับไว้ เหตุผลคือสัญญาระหว่างคนกับเอเจนต์: เอเจนต์ลงมือและรายงาน คนยอมรับและปล่อยออก หลักการนี้ยังใช้ได้แม้กับเวิร์กโฟลว์แบบ human-in-the-loopที่เอเจนต์ทำงานเกือบทั้งหมด
ปลอดภัยไหมที่จะรันเอเจนต์โดยปิดพรอมป์ต์ขอสิทธิ์ทั้งหมด? ปลอดภัยเฉพาะตอนที่คุณนั่งจับตาดูอยู่เท่านั้น โหมดตอบรับอัตโนมัติมีประโยชน์สำหรับเซสชันที่มีคนคุม ซึ่งคุณหยุดขั้นตอนที่ผิดได้ สำหรับการรันแบบไม่มีคนเฝ้าหรือรันข้ามคืน ให้เปิดพรอมป์ต์หรือ allow list ไว้ และวางเอเจนต์บนเครื่องที่มีขอบเขตจำกัด เพื่อให้ความผิดพลาดถูกจำกัดวงอยู่
