พอรันหลายโปรเจ็กต์ด้วย Claude Code ซับเอเจนต์ก็เพิ่มขึ้นเรื่อย ๆ
สร้างเพิ่มทีละตัวทุกครั้งที่จำเป็น สุดท้ายเลยกลายเป็น 22 ตัว
เดือนที่แล้วผมลดมันลงเหลือ 17 ตัว
แต่ตอนยุบกลับไม่ได้เขียนไว้ว่าเพราะอะไรถึงยุบ
พอเปิดโฟลเดอร์ archive อีกครั้งหลังผ่านไป 3 เดือน ก็ไม่รู้แล้วว่ายุบไปทำไม
จากทั้งหมดห้าตัว มีแค่ตัวเดียวที่เขียนเหตุผลไว้
ทั้งที่คนสร้างก็มีแค่ผมคนเดียว
ทำไมถึงไปถึง 22 ตัว
ตอนเพิ่ม จำนวนเหตุผลชัดเจนเสมอ เพราะจำเป็นก็เลยสร้าง
ปัญหาอยู่ที่อีกด้านหนึ่ง ตอนยุบจะมีความคิดว่า "เผื่อว่าเดี๋ยวจะได้ใช้ทีหลัง" ค้างอยู่ตลอด
พอไม่มั่นใจเต็มที่ว่ามันไม่มีประโยชน์ ก็เลยปล่อยไว้แบบนั้น แล้วสุดท้ายก็กลายเป็น 22 ตัว
พอมองย้อนกลับมาตอนนี้ สาเหตุที่มันเพิ่มขึ้นมีอยู่ข้อเดียว
คือไม่มี gate สำหรับตัดสินว่า "อันนี้ควรเป็นเครื่องมือ ไม่ใช่เอเจนต์"
ถ้าเป็นงานซ้ำ ๆ ขั้นตอนตายตัว และไม่ต้องตัดสินจากบริบท นั่นไม่ใช่เอเจนต์
ทำเป็น skill หรือ script ก็พอ ไม่เปลืองโทเค็น, ทำซ้ำได้ 100%, และไม่ลืมแม้จะเปลี่ยนเซสชัน
ถ้าไม่มี gate นี้ ทุกอย่างก็จะกลายเป็นเอเจนต์ไปหมด
ห้าตัวที่ยุบไป
พอไล่ย้อนดู การจัดการแบ่งออกได้เป็นสี่ประเภท ซึ่งการแยกแบบนี้สำคัญมาก
มีหนึ่งตัวที่ตั้งแต่แรกก็ไม่ควรเป็นเอเจนต์
มันเป็นตัวที่ใช้ทำคอนเทนต์ แต่ขั้นตอนตายตัวทั้งหมด
เลยแทนที่ด้วย skill สองตัวแล้วปิดมันไป พร้อมกำหนดชัดเจนว่าห้ามกู้คืน
ไม่อย่างนั้นวันหนึ่งก็จะมีใครสักคนสร้างมันกลับมาอีก
อีกสามตัวมีบทบาทซ้อนกับตัวอื่น
security check ซ้อนกับ code audit, cron monitoring ซ้อนกับ health check, และ planning ซ้อนกับ execution
ทั้งหมดอยู่ในขอบเขตเดียวกันและมีสิทธิ์แบบเดียวกัน
จากตรงนี้ได้เกณฑ์มาหนึ่งข้อ
ถ้าเอเจนต์สองตัวซ้อนกันในขอบเขตเดียวกัน·สิทธิ์เดียวกัน
ต้นทุนของการแยกไว้ต่างหาก (ภาระในการดูแล, ความหน่วงในการตัดสินใจมอบหมายงาน) จะมากกว่าประโยชน์ที่ได้
ความรู้สึกแบบ "จริง ๆ ก็ยังต้องมีทั้งคู่" ฉุดไว้เป็นเวลานาน
แต่คำถามที่ควรถามไม่ใช่ว่าจำเป็นไหม แต่คือการแยกไว้ต่างหากคุ้มค่าพอหรือไม่
อีกหนึ่งตัวคือไม่มีใครใช้งานอยู่เลย
ทราฟฟิกของฟังก์ชันนั้นเป็น 0 มา 70 วันแล้ว
กรณีนี้ไม่ได้ยกเลิก แต่จัดเป็นสถานะพักการใช้งาน ถ้าบริการกลับมา ก็คืนกลับได้ทันที
สิ่งที่ได้เรียนรู้ตอนเขียนตัวเลข
ตอนเขียน 22 → 17 ลงในเอกสาร ผมเพิ่งตระหนักได้เรื่องหนึ่ง
ตัวเลขนี้ไม่ใช่จำนวนไฟล์ แต่เป็นจำนวนเอเจนต์ที่กำลังใช้งานอยู่
มีอยู่หนึ่งตัวที่นิยามอยู่นอกไดเรกทอรี ดังนั้นถ้านับเฉพาะไฟล์จะได้ 21 และ 16
เพราะอย่างนั้น ผมจึงเขียนไว้ตั้งแต่ต้นเอกสารก่อนเลยว่าตัวเลขนี้นับอะไร
และใส่ผลการตรวจสอบด้วย git ls-tree ไว้ด้วย
ไม่อย่างนั้นทีหลังก็จะมีคนมานับไฟล์แล้วจบที่คำว่า "ตัวเลขไม่ตรงนะครับ"
เวลาเขียนตัวเลข ต้องเขียนทั้งนิยามและวิธีตรวจสอบไว้ด้วย
สิ่งที่ตั้งใจจะยึดเวลาเลิกใช้
รอบนี้พอโดนเข้ากับตัว ก็เลยเกิดกฎขึ้นสี่ข้อ
-
ตอนยกเลิกต้องเขียนเหตุผลไว้ในไฟล์ ถ้าไม่เขียน อีก 3 เดือนต้องมานั่งไล่ย้อนเอง ซึ่งผมเจอแบบนั้นจริง ๆ
-
ไม่ลบ แต่ย้ายด้วยการ rename ทำให้เนื้อหาถูกเก็บไว้ครบ 100% และกู้คืนต้นฉบับเดิมได้
-
ระบุรายการที่ห้ามกู้คืนให้ชัด ถ้าไม่เขียน วันหนึ่งจะมีใครบางคนชุบชีวิตมันกลับมา
-
ในขั้นตอนกู้คืน ให้ใส่ข้อ "ลบบทบาทที่ซ้ำกันจากปลายทางที่ถูกรวมเข้าไป" ถ้าข้ามข้อนี้ไป ตอนกู้คืนแล้วทั้งสองตัวจะทำงานซ้ำกัน
สิ่งอื่น ๆ ที่จัดระเบียบไปพร้อมกัน
ถือโอกาสนี้รวมกฎตลอด 4 ปีแล้วเผยแพร่ออกมาด้วย ขอยกมาบางข้อ
ห้ามลอบอ้อมข้อจำกัด
นี่คือกฎที่ทำให้เอเจนต์เมื่อชนกับข้อจำกัดแล้วต้องรายงาน แทนที่จะหาทางเจาะผ่านไปเอง
ถ้าเป็นการบล็อกที่สมเหตุสมผล ก็พักเฉพาะขั้นตอนนั้นไว้และเดินหน้าส่วนที่เหลือต่อ
แม้จะดูเหมือนเป็นการบล็อกที่ตัดสินผิด ก็ห้ามอ้อมเองตามอำเภอใจ ต้องสรุปเหตุผลส่งขึ้นไปและรอการยืนยัน
และถ้าการบล็อกนั้นเผยให้เห็นว่าตัวกฎเองมีข้อบกพร่อง การรับมือก็ต้องรวมถึงการแก้ข้อบกพร่องนั้นด้วย
จริง ๆ แล้วกฎข้อนี้ก็เกิดขึ้นมาแบบนั้น หลังจากเคยเจอกับการถูกบล็อกมาก่อน
อย่าเขียน FAIL เป็น PASS
แม้จะเป็นงานที่ปิดได้ด้วยคำสั่ง ก็ต้องบันทึกสภาพที่วัดได้จริงตามนั้น และทิ้งเงื่อนไขสำหรับ reopen ไว้
การรายงานต้องใช้ค่าที่วัดได้จริงแบบ Before/After และให้เขียนส่วนที่ยังค้างกับความเสี่ยงก่อนผลงานที่ทำได้
โดยพื้นฐานแล้วเอเจนต์จะถูกกดดันให้รายงานความสำเร็จ ถ้าไม่กันไว้ด้วยกฎ มันก็จะทำแบบนั้นต่อไป
กำหนดความเป็นอิสระด้วยเกณฑ์เชิงปริมาณ
แทนที่จะใช้การแบ่งสองขั้วแบบ "แก้ได้/แก้ไม่ได้" ก็เปลี่ยนมากำหนดขอบเขตที่เอเจนต์สายวิเคราะห์จะแก้เองได้ด้วยตัวเลข
-
แค่ 1 ไฟล์
-
น้อยกว่า 5 บรรทัด
-
ไม่ใช่ไฟล์ระดับชั้นสูง
-
ต่ำกว่าค่า threshold ของคะแนน impact
ต้อง ตรงครบทุกข้อ (AND) และถ้าติดแม้แต่ข้อเดียวก็ต้องยื่นขึ้นไป
และข้อสุดท้ายนี่แหละคือหัวใจ — ถ้าคลุมเครือ ให้ขอมอบหมายงานต่อ ค่าเริ่มต้นต้องอนุรักษ์นิยม กฎถึงจะไม่พัง
แยกการตัดสินกับการลงมือปฏิบัติ
งานตรวจสอบ·สืบค้นให้กระจายแบบขนานผ่านซับเอเจนต์ที่เป็น read-only
ส่วนการจัดการไฟล์·DB ให้ orchestrator ทำแบบรวมศูนย์และเรียงลำดับทีละงาน
เพราะถ้าเอเจนต์หลายตัวแก้ไฟล์ที่ใช้ร่วมกันพร้อมกันเมื่อไร พังแน่นอน
แน่นอนว่ามีราคาที่ต้องจ่าย ในงานขนาดใหญ่ การทำแบบศูนย์กลางที่ประมวลผลทีละงานเป็นคอขวด
แต่ถึงจะรู้ว่าช้าลง ก็ยังตัดสินว่าดีกว่าปล่อยให้ชนกัน
ที่เก็บโค้ด
https://github.com/YoungChulMoon/claude-agent-harness
เป็นแค่ไฟล์ Markdown ไม่กี่ไฟล์ ไม่มีอะไรต้องติดตั้ง
วางเทมเพลตไว้ใต้ .claude/agents/ แล้วกรอกเฉพาะส่วนที่ต้องใช้ก็พอ
มันไม่ใช่คำตอบเดียวที่ถูกต้อง แต่เป็นวิธีที่ใช้งานได้จริงในสภาพแวดล้อมนี้ตลอด 4 ปี
อาจไม่เหมาะก็ได้ ขึ้นอยู่กับขนาดทีมและลักษณะของโปรเจ็กต์
เรื่องการเพิ่มมีคนพูดถึงเยอะ แต่เรื่องการลดกลับไม่ค่อยมี
หวังว่าจะเป็นประโยชน์สำหรับคนที่กำลังเจอปัญหาเอเจนต์งอกเพิ่มขึ้นคล้าย ๆ กัน
ยังไม่มีความคิดเห็น