เอเจนต์ของคุณทิ้งโปรเซสไว้ข้างหลัง
AgentsRoom ตามหามันเจอ
เอเจนต์ AI เปิดโปรเซสของระบบขึ้นมาจริง ๆ หนึ่งตัวทุกครั้งที่เรียกใช้เครื่องมือ ส่วนใหญ่จบภายในไม่กี่วินาที บางตัวไม่จบเลย และตัวพวกนั้นจับหน่วยความจำหลายกิกะไบต์ไว้เป็นตัวประกันโดยไม่ใช้ CPU เลยแม้แต่นิดเดียว
ยามเฝ้าโปรเซสจะกวาดดูโปรเซสลูกของเอเจนต์ ชี้ตัวที่หยุดคืบหน้าไปแล้ว ระบุชื่อเอเจนต์ที่รับผิดชอบ แล้วจบมันให้คุณในคลิกเดียว ไม่มีอะไรถูกสั่งปิดลับหลังคุณ
สิ่งที่ยามเฝ้ามองจริง ๆ: โปรเซสที่เอเจนต์หนึ่งตัวเปิดขึ้นมา และตัวไหนในนั้นที่หยุดทำงานไปแล้ว
เอเจนต์ AI ไม่ได้เป็นโปรเซสเดียว ทุกครั้งที่มันเรียกใช้เครื่องมือ จะมีโปรเซสจริงเปิดขึ้นบนเครื่องคุณหนึ่งตัว: การค้นหา, การ build, การตรวจชนิดข้อมูล, การรันเทสต์, สคริปต์ คูณจำนวนนั้นด้วยเอเจนต์หลายตัวที่ทำงานคู่ขนานกันตลอดทั้งวัน แล้วคุณจะได้โปรเซสหลายร้อยตัวที่เกิดและตายไปโดยที่คุณไม่เคยเห็นสักตัว
เกือบทั้งหมดจบลงเอง ตัวที่ไม่จบคือปัญหา การค้นหาที่แพตเทิร์นทำให้เอนจิน regex ระเบิดจะไม่ crash และไม่ช้าลง: มันจองหน่วยความจำ ถูกดันเข้าไปในหน่วยความจำแบบบีบอัด แล้วใช้ชีวิตที่เหลือไปกับ page fault ที่ 4% CPU มันจะไม่มีวันเสร็จ จะไม่มีใครมาปิดมัน และถ้าเอเจนต์ที่เปิดมันขึ้นมาถูกปิดไป มันจะถูกโยกไปอยู่ใต้โปรเซส init กลายเป็นโปรเซสกำพร้าที่ไม่มีใครบนเครื่องรับผิดชอบอีกต่อไป
นี่คือเหตุผลที่ความช้าค่อย ๆ คืบเข้ามา ไม่มีเหตุการณ์ใหญ่ให้จับได้ มีแต่การสะสมช้า ๆ ตลอดวันทำงาน และรูปแบบแบบนี้เองที่ทำให้คนไปโทษผิดตัว: เครื่องร้อนเกินไป, เปิดเอเจนต์เยอะเกินไป, แอปรั่วหน่วยความจำ ในเซสชันที่เราวัด ตัวแอปเองใช้ 2.8 GB กระจายบน 91 โปรเซส และ CLI ของเอเจนต์แปดตัวรวมกันใช้ 1.6 GB ทั้งสองอย่างไม่ใช่ปัญหา
ยามเฝ้าโปรเซสคือตาข่ายนิรภัย มันเฝ้าดูสิ่งที่เอเจนต์ทิ้งไว้ บอกคุณว่าตัวไหนค้างและใครเป็นคนเปิดมัน แล้วให้คุณจบมันเอง ต้นเหตุจะเปลี่ยนไปเรื่อย ๆ: เครื่องมือตัวอื่น, แพตเทิร์นแบบอื่น, ผู้ให้บริการรายอื่น แต่ตาข่ายไม่จำเป็นต้องเปลี่ยนตาม
ทำไมเครื่องที่รันเอเจนต์ AI ถึงช้าลง
ตัวเลขข้างล่างนี้มาจากเซสชันที่วัดจริงหนึ่งครั้ง บนโน้ตบุ๊ก 16 GB ที่มีเอเจนต์แปดตัวทำงานอยู่ ไม่มีตัวเลขไหนเป็นการประมาณ
เครื่องเปิดมาแล้วห้าชั่วโมงครึ่ง ไม่มีปัญหาความร้อนเลยแม้แต่น้อย: ไม่มี throttling ถูกบันทึกไว้ แบตเตอรี่อยู่ที่ 30.6 C ค่า load average อยู่ระหว่าง 17 ถึง 21 บน 8 คอร์ และ CPU ใช้เวลา 56% อยู่ในเคอร์เนล เหลือว่างแค่ 1.5% อัตราส่วนนี้แหละที่ฟ้องทุกอย่าง เครื่องที่ทำงานจริงจะใช้เวลาไปกับโค้ดฝั่งผู้ใช้ ส่วนเครื่องที่มีเวลาระบบ 56% คือเคอร์เนลที่ไม่ได้ทำอะไรนอกจากบีบอัด คลายบีบอัด แล้วสลับหน่วยความจำลง swap
โปรเซสค้นหาที่ค้างอยู่เจ็ดตัวยึดหน่วยความจำไว้ตัวละ 3.9 ถึง 8.0 GB รวมแล้ว 41.8 GB บนเครื่องที่มี RAM 16 GB swap อยู่ที่ 22.3 GB จาก 23.5 และมีข้อมูลราว 993 GB ถูกเขียนลง swap ตั้งแต่เปิดเครื่อง การจบโปรเซสทั้งเจ็ดตัวนั้นคืนหน่วยความจำมา 15.5 GB ทันที โดยไม่ต้องรีสตาร์ตเอเจนต์สักตัวและไม่ต้องรีสตาร์ตแอป
เหตุผลที่ไม่มีใครจับเรื่องนี้ได้ด้วยมือ ก็เพราะเครื่องมือที่ใช้กันอยู่โกหกเรื่องนี้ บน macOS โปรเซสที่ค้างอยู่อาจแสดงหน่วยความจำ resident แค่ 20 MB ทั้งที่จริงยึดไว้ 8 GB เพราะทุกอย่างที่มันแตะผ่านตัวบีบอัดหน่วยความจำไปหมดแล้ว เราวัดตัวจริงตัวหนึ่งได้ resident 4.7 GB สำหรับปริมาณที่ใช้จริง 14 GB ขนาด virtual ก็ช่วยอะไรไม่ได้: บนแพลตฟอร์มนั้นแม้แต่ launchd ยังรายงานขนาด virtual ราว 440 GB การกรองด้วยค่านั้นจึงเท่ากับชี้ว่าทั้งเครื่องมีปัญหา
เซสชันเดียวกัน ไล่ทีละชั่วโมง: ก้อนหน่วยความจำที่ไม่มีใครใช้แล้ว และสิ่งที่เกิดขึ้นเมื่อปล่อยมันคืน
และโปรเซสพวกนี้มีสี่คุณสมบัติที่รับประกันว่าพรุ่งนี้มันก็ยังอยู่ตรงนั้น
มันไม่มีวันเสร็จ
หน่วยความจำของตัวมันเองอยู่ใน swap มันจึงใช้เวลาไปกับ page fault แทนที่จะคำนวณ การค้นหาที่ปกติดีจะดันคอร์หนึ่งจนเต็ม ส่วนพวกนี้นิ่งอยู่ที่ 4% ไม่มีทางออกจากวังวนนั้น และรอไปนานแค่ไหนก็ไม่ช่วย
มันไม่มีวันตาย
การเรียกใช้เครื่องมือไม่มีเวลาจำกัด ไม่มีอะไรบนเครื่องมีความเห็นกับโปรเซสที่นิ่งมาห้าสิบนาที มันจะนั่งอยู่ตรงนั้นจนกว่าจะมีคนสั่งปิดหรือเครื่องรีบูต
มันอยู่ได้นานกว่าเอเจนต์ของตัวเอง
ปิดแท็บเอเจนต์แล้วโปรเซสยังรอดอยู่ได้ โดยถูกโยกไปอยู่ใต้โปรเซส init ตั้งแต่จุดนั้นก็ไม่มีอะไรเชื่อมมันกับอะไรอีกเลย: มันเป็นโปรเซสกำพร้า และจะไม่มีใครมาเก็บกวาดให้ สองในเจ็ดตัวที่เราวัดอยู่ในสภาพนั้นแล้ว
มันพอกพูนขึ้นเรื่อย ๆ
หนึ่งตัวต่อการตรวจสอบหนึ่งรอบ หนึ่งตัวต่อการค้นหาที่ซวยหนึ่งครั้ง นี่คือเหตุผลที่ความช้าเพิ่มขึ้นตลอดทั้งวัน และเหตุผลที่การรีบูตดูเหมือนจะแก้ปัญหาได้ มันไม่ได้แก้อะไรเลย มันแค่ตั้งตัวนับกลับไปที่ศูนย์
ยามเฝ้าโปรเซสทำอะไรบ้าง
มันเฝ้าดูโปรเซสที่เอเจนต์ของคุณเปิดขึ้นมา และมันจงใจแคบมากเรื่องว่าจะไปยุ่งกับตัวไหน
วัดหน่วยความจำที่ใช้จริง
ไม่ใช่ขนาด resident ซึ่งรายงานโปรเซสที่ค้างต่ำกว่าความจริงไปหลายกิกะไบต์ ยามเฝ้าอ่านปริมาณที่ใช้จริง นับรวมเพจที่ถูกบีบอัดและเพจที่ถูกสลับลง swap ไปแล้วด้วย โปรเซสที่แสดง 20 MB แต่ยึดไว้ 8 GB จึงถูกมองเห็นตามที่มันเป็นจริง
ดูทั้ง CPU ไม่ใช่แค่ RAM
ถ้าดูแค่หน่วยความจำ ทุก build บนเครื่องคุณจะถูกชี้ว่าผิดหมด ยามเฝ้าวัดการใช้ตัวประมวลผลเป็นอัตราระหว่างการสแกนสองครั้ง โปรเซสที่เคยทำงานหนักแล้วมาค้างทีหลังจึงยังถูกจับได้ ส่วน build ที่กำลังทำงานอยู่จริงก็ถูกปล่อยไว้ตามเดิม
จับโปรเซสกำพร้าได้ด้วย
โปรเซสที่อยู่ได้นานกว่าเอเจนต์ที่เปิดมันขึ้นมาจะถูกรายงานด้วยตัวมันเอง เพราะจะไม่มีใครอื่นมาเก็บกวาดให้ ความเป็นเจ้าของถูกจดจำไว้ตั้งแต่ตอนที่โปรเซสยังผูกอยู่กับเอเจนต์ ซึ่งเป็นจังหวะเดียวที่ระบุมันได้
คลิกเดียวก็จบมันได้
ป้ายบนแถบสถานะจะไล่รายชื่อโปรเซสที่ค้างแต่ละตัว พร้อมเอเจนต์ที่เปิดมัน หน่วยความจำ อายุ และ CPU ของมัน การจบตัวหนึ่งจะปิดทุกอย่างที่มันแตกลูกออกไปด้วย หน่วยความจำกลับคืนมาทันทีและเอเจนต์ของคุณก็ยังทำงานต่อ
macOS, Windows และ Linux
แต่ละระบบต้องใช้วิธีวัดคนละแบบกว่าจะบอกความจริงเรื่องหน่วยความจำได้: เพจที่ถูกบีบอัดบน macOS, resident บวกส่วนที่ลง swap บน Linux, private commit บน Windows ทั้งสามแบบทำเสร็จแล้ว ไม่ใช่แค่วางแผนไว้
แทบไม่กินทรัพยากรเลย
สแนปช็อตโปรเซสหนึ่งครั้งต่อนาที วัดได้ราว 40 ms บนเครื่องที่รันอยู่ 824 โปรเซส การวัดหน่วยความจำแบบแพงจะทำงานก็ต่อเมื่อมีบางอย่างดูค้างอยู่แล้วเท่านั้น และจะไม่มีการสแกนเลยตราบใดที่ไม่มีเอเจนต์ทำงานอยู่
กฎที่ทำให้มันไม่กลายเป็นเด็กเลี้ยงแกะ
ยามเฝ้าที่ชี้ว่า build ของคุณมีปัญหา คือยามเฝ้าที่คุณจะปิดทิ้งภายในหนึ่งสัปดาห์ ดังนั้นโปรเซสจะไม่มีวันถูกรายงานเพราะหน่วยความจำเพียงอย่างเดียว มันต้องใหญ่ ต้องมีอายุมาสักพัก และต้องหยุดใช้ตัวประมวลผลไปแล้ว ครบทั้งสามข้อพร้อมกัน
เงื่อนไขข้อที่สามนี่แหละที่ทำงานจริง การตรวจชนิดข้อมูลหรือ bundler ก็ยึดหน่วยความจำหลายกิกะไบต์อยู่หลายนาทีเหมือนกัน แต่ระหว่างนั้นมันดันคอร์หนึ่งจนเต็ม ส่วนโปรเซสที่ติดอยู่ใน swap จะนิ่งอยู่ราว 4% เพราะมันใช้ชีวิตไปกับการรอ page fault แทนที่จะคำนวณ ช่องว่างตรงนี้คือสิ่งที่แยกเครื่องที่กำลังทำงานออกจากเครื่องที่กำลังจมน้ำ และเป็นสัญญาณเดียวที่แยกทั้งสองอย่างได้อย่างน่าเชื่อถือ
การใช้ตัวประมวลผลก็เป็นค่าที่วัดเอง ไม่ใช่ค่าที่อ่านมา ตัวเลขที่เครื่องมือระบบรายงานตามปกติคือค่าเฉลี่ยตลอดอายุของโปรเซส ซึ่งยังดูยุ่งอยู่สำหรับอะไรที่ทำงานหนักมายี่สิบนาทีแล้วมาค้าง ยามเฝ้าจึงเทียบเวลาตัวประมวลผลที่ถูกใช้ไประหว่างการสแกนสองครั้งแทน สิ่งที่มันเห็นจึงเป็นนาทีล่าสุด ไม่ใช่ชั่วโมงล่าสุด
มันทำงานอย่างไร
สี่ขั้นตอน นาทีละครั้ง และขั้นตอนที่แพงแทบไม่เคยทำงานเลย
สแนปช็อตราคาถูกหนึ่งภาพของทั้งเครื่อง
ทุกนาที ยามเฝ้าจะถ่ายสแนปช็อตของโปรเซสทั้งหมดที่กำลังทำงานเพียงภาพเดียว แล้วไล่ต้นไม้โปรเซสใต้เทอร์มินัลของเอเจนต์แต่ละตัว ต้นทุนที่วัดได้บนเครื่องที่รันอยู่ 824 โปรเซส: ราว 40 ms และตราบใดที่ไม่มีเอเจนต์ทำงาน เรื่องนี้ก็ไม่เกิดขึ้นเลย
คัดรายชื่อผู้ต้องสงสัย
จากสแนปช็อตนั้น มันจะเก็บไว้เฉพาะโปรเซสลูกของเอเจนต์ที่มีอายุเกินเกณฑ์ที่คุณตั้งไว้ และไม่ใช้ตัวประมวลผลแล้ว ในการใช้งานปกติรายชื่อนี้จะว่างเปล่า และทุกอย่างจบลงตรงนี้
วัดเฉพาะตัวที่ดูเหมือนค้าง
ยามเฝ้าจะยอมจ่ายค่าการวัดหน่วยความจำจริงเฉพาะกับรายชื่อสั้น ๆ นั้นเท่านั้น โดยนับรวมเพจที่ถูกบีบอัดและเพจที่ลง swap ไปแล้ว โปรเซสที่มันวัดไม่ได้จะไม่ถูกชี้ว่าผิดเด็ดขาด: สิ่งที่ยังไม่รู้ไม่ใช่คำตัดสิน
รายงาน แล้วปล่อยให้คุณตัดสินใจ
ป้ายหนึ่งอันจะโผล่ขึ้นบนแถบสถานะ พร้อมการแจ้งเตือนครั้งเดียวที่บอกคุณ คุณเปิดรายการขึ้นมา เห็นว่าโปรเซสนั้นคืออะไร ยึดไว้เท่าไหร่ ค้างมานานแค่ไหน และเอเจนต์ตัวไหนเป็นคนเปิดมัน แล้วจบมันถ้าคุณต้องการ
สิ่งที่มันจะไม่แตะเด็ดขาด
เครื่องมือที่จบโปรเซสได้ต้องเข้มงวดมากว่าอะไรคือธุระของมัน ข้อจำกัดเหล่านี้อยู่ในโครงสร้าง ไม่ใช่ตัวเลือกที่คุณต้องจำไว้ว่าต้องไปเปิด
- ตัว CLI ของเอเจนต์เอง ไม่ว่าคุณจะใช้ผู้ให้บริการรายไหน ยามเฝ้าจะปกป้องไบนารีที่แอปใช้เปิดเทอร์มินัลนั้นเสมอ มันอ่านชื่อนั้นจากคำสั่งเปิดโดยตรง ไม่ใช่จากรายชื่อที่เขียนตายตัวไว้ ดังนั้นโปรเซสย่อยของ CLI ตัวเดียวกันก็ได้รับการปกป้องด้วย ไม่ว่าจะลึกกี่ชั้น
- เทอร์มินัลคำสั่ง dev ของคุณ เซิร์ฟเวอร์พัฒนาที่นิ่งอยู่เข้าเกณฑ์โปรเซสหลุดมือครบทุกข้อ: อ้วน เก่า ไม่ใช้ตัวประมวลผล และมันก็เป็นโปรเซสเดียวที่คุณอยากให้รันอยู่จริง ๆ มีแต่เทอร์มินัลของเอเจนต์เท่านั้นที่ถูกเฝ้าดู เซิร์ฟเวอร์พัฒนาของคุณจึงไม่เคยเข้ามาอยู่ในภาพเลย
- เชลล์และท่อภายในของตัวแอปเอง ตัวช่วยเทอร์มินัลและเชลล์ที่เอเจนต์รันอยู่ข้างในถูกกันออกตั้งแต่การออกแบบ มีแต่โปรเซสของเครื่องมือที่อยู่ใต้ CLI ของเอเจนต์เท่านั้นที่จะเข้าข่ายได้
- อะไรก็ตามที่มันไม่ได้รับมาดูแล เส้นทางเดียวที่จบโปรเซสได้จะปฏิเสธทุกโปรเซสที่ยามเฝ้าไม่ได้เก็บมาจากต้นไม้โปรเซสของเอเจนต์เอง มันจึงกลายเป็นช่องทางสำหรับปิดอย่างอื่นบนเครื่องคุณไม่ได้
และจะไม่มีอะไรถูกจบอัตโนมัติเว้นแต่คุณจะสั่งเอง โดยค่าเริ่มต้น ยามเฝ้าจะรายงานสิ่งที่มันเจอแล้วให้คุณตัดสินใจ เพราะคุณคือคนเดียวที่รู้ว่าโปรเซสก้อนใหญ่ที่เงียบอยู่นั้นเป็นสิ่งที่คาดไว้อยู่แล้วหรือเปล่า
เมื่อไหร่ที่มันพิสูจน์คุณค่าของตัวเอง
ทุกสถานการณ์ข้างล่างนี้เกิดขึ้นจริง ไม่มีอันไหนเป็นการสมมติ
เครื่องช้าตอนหกโมงเย็นกว่าตอนเก้าโมงเช้า
ไม่มีจังหวะไหนที่มันพังชัด ๆ มีแต่การไหลลงอย่างสม่ำเสมอตลอดวัน รูปแบบแบบนี้เกือบทุกครั้งคือโปรเซสค้างที่สะสมกันไว้ และเป็นแบบที่วินิจฉัยด้วยมือยากที่สุด เพราะไม่ว่าจะหยิบมาดูวินาทีไหนก็ไม่มีอะไรดูผิดปกติเลย
เอเจนต์หลายตัวทำงานคู่ขนานกัน
ยิ่งคุณรันเอเจนต์มากเท่าไหร่ ก็ยิ่งมีการเรียกใช้เครื่องมือมากเท่านั้น และยิ่งมีโอกาสที่ตัวใดตัวหนึ่งจะไปค้าง อัตราความล้มเหลวต่อการเรียกหนึ่งครั้งนั้นเล็กจิ๋ว แต่พอคูณด้วยวันทำงานคู่ขนานทั้งวัน มันก็เลิกเล็กจิ๋ว
การค้นหาที่ไม่เคยกลับมา
แพตเทิร์นที่ทำให้เอนจิน regex ระเบิดจะจองหน่วยความจำหลายกิกะไบต์กับไฟล์ที่มีขนาดแค่ไม่กี่ร้อยกิโลไบต์ เอเจนต์รอมัน คุณรอเอเจนต์ และเครื่องก็จ่ายค่าให้ทั้งสองฝ่าย
คุณปิดเอเจนต์ไปแล้ว แต่โปรเซสยังอยู่
การปิดแท็บไม่ได้คืนอะไรเสมอไป โปรเซสที่หลุดออกไปแล้วยังเก็บหน่วยความจำของมันไว้ และเสียสายสัมพันธ์เส้นสุดท้ายกับทุกอย่างที่คุณมองเห็นในแอป
โน้ตบุ๊กที่มี 16 GB
บนเครื่องที่ RAM เหลือเฟือ โปรเซสค้างไม่กี่ตัวซ่อนตัวอยู่ได้นานมาก แต่บนโน้ตบุ๊ก 16 GB มันแตะ swap เร็ว และทันทีที่ระบบเริ่มบีบอัดหน่วยความจำ เอเจนต์ทุกตัวก็ช้าลงพร้อมกันหมด
ก่อนที่คุณจะโทษแอป
เวลาที่เครื่องคลานเป็นเต่าขณะที่ AgentsRoom เปิดอยู่ แอปคือผู้ต้องสงสัยที่ชัดที่สุด การมีตัวเลขจริงเป็นรายโปรเซส พร้อมชื่อเอเจนต์ที่เปิดแต่ละตัว เปลี่ยนความสงสัยให้กลายเป็นสิ่งที่ตรวจสอบได้จริง
คุณเป็นคนกำหนดขีดจำกัด
ค่าเริ่มต้นถูกตั้งไว้อย่างระมัดระวังโดยตั้งใจ ทุกอย่างข้างล่างนี้อยู่ในการตั้งค่า แท็บ Terminal และแต่ละอย่างยังอ่านและแก้ไขได้โดยเอเจนต์ผ่านเครื่องมือ MCP ของ AgentsRoom ด้วย
- เฝ้าดูโปรเซสลูกของเอเจนต์
- เปิดไว้เป็นค่าเริ่มต้น ปิดมันแล้วจะไม่มีการสแกนเกิดขึ้นอีกเลย ตลอดไป
- รายงานเมื่อเกินเกณฑ์หน่วยความจำ
- ค่าเริ่มต้นคือสองกิกะไบต์ ต่ำกว่านั้น โปรเซสที่ค้างยังไม่คุ้มที่จะมารบกวนคุณ ปรับขึ้นบนเวิร์กสเตชันที่ RAM เยอะ ปรับลงบนโน้ตบุ๊กที่หน่วยความจำจำกัด
- หลังจากมีอายุขั้นต่ำแล้ว
- ค่าเริ่มต้นคือห้านาที นี่คือสิ่งที่กันไม่ให้งานที่ช้าแต่ถูกต้องถูกชี้ว่าผิด เพราะแทบไม่มีอะไรที่คุณต้องการจริง ๆ ที่กินเวลาห้านาทีโดยไม่ใช้ตัวประมวลผลเลยแม้แต่นิดเดียว
- จบโปรเซสที่ค้างโดยอัตโนมัติ
- ปิดไว้เป็นค่าเริ่มต้น และนั่นเป็นการตัดสินใจเชิงผลิตภัณฑ์ที่ตั้งใจ ไม่ใช่แค่ความระมัดระวัง ยามเฝ้ากำลังใช้ดุลยพินิจ และมีแต่คุณเท่านั้นที่รู้ว่าโปรเซสก้อนใหญ่ที่เงียบอยู่นั้นเป็นสิ่งที่คาดไว้หรือเปล่า เปิดมันแล้วมันจะลงมือเอง พร้อมแจ้งเตือนให้ทราบภายหลัง
เกณฑ์ตัวประมวลผลไม่ถูกเปิดให้ปรับ และนั่นเป็นความตั้งใจ เพราะมันคือการวัดที่แยก build ที่กำลังทำงานอยู่ออกจากโปรเซสที่ค้าง และมันไม่ใช่เรื่องรสนิยม
คำถามที่พบบ่อย
แปลว่า AgentsRoom ทำให้คอมพิวเตอร์ของฉันช้าลงหรือเปล่า
ไม่ และนี่แหละคือเหตุผลที่ฟีเจอร์นี้มีอยู่ ในเซสชันที่เราวัด ตัวแอปใช้ 2.8 GB กระจายบน 91 โปรเซส และ CLI ของเอเจนต์แปดตัวรวมกันใช้ 1.6 GB ส่วน 41.8 GB นั้นถูกยึดไว้โดยโปรเซสของเครื่องมือที่ไปค้าง AgentsRoom บังเอิญเป็นที่เดียวที่มองเห็นเอเจนต์ทุกตัวและโปรเซสทุกตัวที่มันเปิดขึ้นมา จึงเป็นที่เดียวที่ตัดสินเรื่องนี้ได้
มันจะไปฆ่า build หรือการรันเทสต์ของฉันไหม
ไม่ โปรเซสจะถูกชี้ก็ต่อเมื่อมันใหญ่ และเก่า และหยุดใช้ตัวประมวลผลไปแล้ว ครบทั้งสามข้อ build ที่กำลังทำงานอยู่จริงจะดันคอร์หนึ่งจนเต็ม มันจึงตกเงื่อนไขข้อที่สามและไม่มีทางเข้าข่าย เงื่อนไขนั้นมีอยู่เพื่อแยกสองอย่างนี้ออกจากกันโดยเฉพาะ
มันเฝ้าเซิร์ฟเวอร์พัฒนาของฉันด้วยไหม
ไม่ และจะไม่มีวันเฝ้า เซิร์ฟเวอร์พัฒนาที่นิ่งอยู่เข้าเกณฑ์ครบทุกข้อ: มันยึดหน่วยความจำไว้เยอะ มันรันมาหลายชั่วโมงแล้ว และมันไม่ใช้ตัวประมวลผลระหว่างรีเควสต์ มีแต่โปรเซสลูกของเทอร์มินัลเอเจนต์เท่านั้นที่ถูกเฝ้าดู คำสั่ง dev ของคุณจึงอยู่นอกขอบเขตตั้งแต่การออกแบบ
มันจบตัวเอเจนต์เองได้ไหม
ไม่ได้ CLI ของเอเจนต์ได้รับการปกป้องไม่ว่าคุณจะใช้ผู้ให้บริการรายไหน และการปกป้องนั้นอิงกับไบนารีที่แอปใช้เปิดเทอร์มินัลนั้น ไม่ใช่รายชื่อที่รู้จักกันอยู่แล้ว เชลล์และตัวช่วยเทอร์มินัลของแอปเองก็ถูกกันออกเช่นกัน
โปรเซสกำพร้าคืออะไร และทำไมถึงได้รับการปฏิบัติเป็นพิเศษ
โปรเซสที่ตัวแม่ของมันจบไปแล้วจะถูกโยกไปอยู่ใต้โปรเซส init ของระบบ ตั้งแต่วินาทีนั้นก็ไม่มีอะไรเชื่อมมันกับเอเจนต์ที่เปิดมันขึ้นมาอีก จึงไม่มีใครมาเก็บกวาดให้ AgentsRoom จดจำความเป็นเจ้าของไว้ตั้งแต่ตอนที่โปรเซสยังผูกอยู่กับเอเจนต์ ซึ่งเป็นจังหวะเดียวที่ระบุมันได้ มันจึงยังรายงานโปรเซสนั้นได้ในภายหลัง
ตัวการเฝ้าดูเองกินทรัพยากรเท่าไหร่
สแนปช็อตโปรเซสหนึ่งครั้งต่อนาที วัดได้ราว 40 ms บนเครื่องที่รันอยู่ 824 โปรเซส การวัดหน่วยความจำที่แพงกว่าจะทำงานเฉพาะกับโปรเซสที่ดูค้างอยู่แล้วเท่านั้น ซึ่งในการใช้งานปกติแปลว่ามันไม่ทำงานเลย และการสแกนก็ไม่มีอยู่เลยตราบใดที่ไม่มีเอเจนต์ทำงานอยู่
ทำไมไม่ดูคอลัมน์หน่วยความจำใน Activity Monitor ไปเลยล่ะ
เพราะบน macOS มันรายงานปัญหาต่ำกว่าความจริงไปหนึ่งระดับขนาด โปรเซสที่ถูกดันเข้าไปในหน่วยความจำแบบบีบอัดอาจแสดง resident แค่ 20 MB ทั้งที่ยึดไว้ 8 GB เราวัดตัวจริงตัวหนึ่งได้ resident 4.7 GB สำหรับปริมาณที่ใช้จริง 14 GB ขนาด virtual ก็ไม่ได้ดีไปกว่ากัน: แม้แต่โปรเซสของระบบก็รายงานตัวเลขนี้เป็นหลักร้อยกิกะไบต์
มันใช้ได้กับ Claude Code, Codex และตัวอื่น ๆ ไหม
ได้ ยามเฝ้าไม่รู้จักเครื่องมือหรือผู้ให้บริการรายใดเป็นการเฉพาะเลย มันเฝ้าดูโปรเซสลูกของเทอร์มินัลเอเจนต์ตัวไหนก็ตามที่คุณเปิดขึ้นมา และ CLI ที่มันปกป้องก็อ่านมาจากคำสั่งเปิดโดยตรง การเพิ่มผู้ให้บริการรายใหม่ไม่เปลี่ยนอะไรตรงนี้เลย
มันใช้ได้บน Windows และ Linux ไหม
ได้ แต่ละแพลตฟอร์มต้องใช้วิธีวัดคนละแบบกว่าตัวเลขหน่วยความจำจะบอกความจริง: เพจที่ถูกบีบอัดบน macOS, resident บวกเพจที่ลง swap บน Linux, private commit บน Windows ทั้งสามแบบทำเสร็จแล้ว
มันจะจบโปรเซสโดยไม่ถามฉันก่อนไหม
ไม่ เว้นแต่คุณจะไปเปิดเอง โดยค่าเริ่มต้นมันจะรายงานสิ่งที่มันเจอ พร้อมชื่อเอเจนต์ หน่วยความจำ อายุ และการใช้ตัวประมวลผล แล้วคุณเป็นคนตัดสิน การจบอัตโนมัติเป็นการตั้งค่าอย่างหนึ่ง ที่ปิดไว้ตั้งแต่แกะกล่อง
เกิดอะไรขึ้นกับเอเจนต์เมื่อฉันจบโปรเซสตัวหนึ่งของมัน
เอเจนต์ยังทำงานต่อ การเรียกใช้เครื่องมือของมันจะได้รับ error กลับไปแทนที่จะค้างอยู่ตลอดกาล ซึ่งเป็นผลลัพธ์ที่คุณต้องการอยู่แล้ว: ยังไงโปรเซสนั้นก็ไม่มีวันเสร็จ ไม่มีอะไรถูกเริ่มใหม่และไม่มีบริบทไหนสูญหาย
มันแก้ที่ต้นเหตุได้ไหม
ไม่ได้ และมันก็ไม่ได้พยายามจะแก้ ต้นเหตุเปลี่ยนไปเรื่อย ๆ: วันนี้เป็นเครื่องมือตัวหนึ่ง พรุ่งนี้เป็นแพตเทิร์นอีกแบบ เดือนหน้าเป็นผู้ให้บริการอีกราย นี่คือตาข่ายนิรภัย ที่ออกแบบมาให้ยังทำงานได้เมื่อต้นเหตุเป็นสิ่งที่ยังไม่มีใครเคยเห็น
คุณอาจสนใจสิ่งเหล่านี้ด้วย
Context Canary
สัญญาณเตือนล่วงหน้าอีกตัวหนึ่ง: มันเฝ้าดูบริบทของตัวเอเจนต์เองแทนที่จะเป็นตัวเครื่อง และบอกคุณเมื่อเอเจนต์เริ่มเบี่ยงเบน ก่อนที่มันจะเริ่มแต่งไฟล์และ API ขึ้นมาเอง
เทอร์มินัลสำหรับนักพัฒนา
รันเซิร์ฟเวอร์พัฒนาและคำสั่งยาว ๆ ของคุณใน AgentsRoom พร้อมการแจ้งเตือนเมื่อคำสั่งยาวทำงานเสร็จ เทอร์มินัลเหล่านี้แหละคือสิ่งที่ยามเฝ้าโปรเซสถูกออกแบบมาไม่ให้แตะเด็ดขาด
การติดตามสถานะเอเจนต์
เห็นได้ในพริบตาว่าเอเจนต์ตัวไหนกำลังทำงาน ตัวไหนรอคุณอยู่ และตัวไหนว่าง โดยไม่ต้องอ่านเทอร์มินัลสักอัน
การใช้โทเค็น
อีกทรัพยากรหนึ่งที่ควรจับตา ปริมาณการใช้โทเค็นและโควตารายเอเจนต์ เพื่อให้คุณรู้ว่าการใช้งานของคุณหมดไปกับอะไร
มุมมองแบ่งจอ
เอเจนต์หลายตัวเรียงข้างกันในหน้าต่างเดียว แต่ละตัวมีพาเนล สี และสถานะแบบสดของตัวเอง
CLI Doctor
เมื่อเอเจนต์เปิดขึ้นมาไม่ได้ มันจะบอกคุณว่าเพราะอะไรและต้องทำอย่างไร แทนที่จะทิ้งเทอร์มินัลเปล่า ๆ ไว้ให้
เลิกจ่ายค่าโปรเซสที่ไม่มีใครใช้
AgentsRoom ดาวน์โหลดฟรี และยามเฝ้าโปรเซสเปิดทำงานตั้งแต่การเปิดแอปครั้งแรก
แอปคู่หู: ตรวจสอบเอเจนต์ของคุณได้ทุกที่
นำของคุณเอง: Claude, Codex, Antigravity CLI, หรือผู้ให้บริการ AI อื่น ๆ
ส่งข้อบกพร่องและคำขอไปยังแบ็คล็อกสาธารณะของคุณโดยตรง
มองเห็น AgentsRoom ในการทำงาน