เอเจนต์ของคุณทิ้งโปรเซสไว้ข้างหลัง
AgentsRoom ตามหามันเจอ
เอเจนต์ AI เปิดโปรเซสของระบบขึ้นมาจริง ๆ หนึ่งตัวทุกครั้งที่เรียกใช้เครื่องมือ ส่วนใหญ่จบภายในไม่กี่วินาที บางตัวไม่จบเลย และแค่มีแบบนั้นอยู่พร้อมกันไม่กี่ตัวก็เพียงพอจะถมหน่วยความจำของทั้งเครื่องจนเต็ม
ยามเฝ้าโปรเซสจะกวาดดูโปรเซสลูกของเอเจนต์ ชี้ตัวที่กินหน่วยความจำของคุณ ทั้งทีละตัวและแบบมากันเป็นฝูง ระบุชื่อเอเจนต์ที่รับผิดชอบ แล้วให้คุณขัดจังหวะมันได้ ไม่มีอะไรถูกสั่งปิดลับหลังคุณ
สิ่งที่ยามเฝ้ามองจริง ๆ: โปรเซสที่เอเจนต์หนึ่งตัวเปิดขึ้นมา และตัวไหนในนั้นที่หยุดทำงานไปแล้ว
เอเจนต์ AI ไม่ได้เป็นโปรเซสเดียว ทุกครั้งที่มันเรียกใช้เครื่องมือ จะมีโปรเซสจริงเปิดขึ้นบนเครื่องคุณหนึ่งตัว: การค้นหา, การ build, การตรวจชนิดข้อมูล, การรันเทสต์, สคริปต์ คูณจำนวนนั้นด้วยเอเจนต์หลายตัวที่ทำงานคู่ขนานกันตลอดทั้งวัน แล้วคุณจะได้โปรเซสหลายร้อยตัวที่เกิดและตายไปโดยที่คุณไม่เคยเห็นสักตัว
เกือบทั้งหมดจบลงเอง ตัวที่ไม่จบคือปัญหา การค้นหาที่แพตเทิร์นทำให้เอนจิน regex ระเบิดจะไม่ crash และไม่ช้าลง: มันจองหน่วยความจำ ถูกดันเข้าไปในหน่วยความจำแบบบีบอัด แล้วใช้ชีวิตที่เหลือไปกับ page fault ขณะที่เคอร์เนลต้องสลับข้อมูลหลายกิกะไบต์ลง swap ให้มัน มันจะไม่มีวันเสร็จ จะไม่มีใครมาปิดมัน และถ้าเอเจนต์ที่เปิดมันขึ้นมาถูกปิดไป มันจะกลายเป็นโปรเซสกำพร้าที่ไม่มีใครบนเครื่องรับผิดชอบอีกต่อไป
นี่คือเหตุผลที่ความช้าค่อย ๆ คืบเข้ามา ไม่มีเหตุการณ์ใหญ่ให้จับได้ มีแต่การสะสมช้า ๆ ตลอดวันทำงาน และรูปแบบแบบนี้เองที่ทำให้คนไปโทษผิดตัว: เครื่องร้อนเกินไป, เปิดเอเจนต์เยอะเกินไป, แอปรั่วหน่วยความจำ ในเซสชันที่เราวัด ตัวแอปเองใช้ 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 แทนที่จะคำนวณ และระหว่างนั้นมันก็ไม่ได้อยู่เฉย ๆ ด้วย: โปรเซสหลุดมือที่เราวัดได้กินตัวละ 10 ถึง 19% ของหนึ่งคอร์ และยิ่งพอกพูนกันมากเท่าไหร่ แต่ละตัวก็ยิ่งได้ส่วนแบ่งน้อยลง ไม่มีทางออกจากวังวนนั้น และรอไปนานแค่ไหนก็ไม่ช่วย
มันไม่มีวันตาย
การเรียกใช้เครื่องมือไม่มีเวลาจำกัด ไม่มีอะไรบนเครื่องมีความเห็นกับโปรเซสที่นิ่งมาห้าสิบนาที มันจะนั่งอยู่ตรงนั้นจนกว่าจะมีคนสั่งปิดหรือเครื่องรีบูต
มันอยู่ได้นานกว่าเอเจนต์ของตัวเอง
ปิดแท็บเอเจนต์แล้วโปรเซสยังรอดอยู่ได้ และแต่ละระบบก็ตัดสายสัมพันธ์นั้นคนละแบบ: Unix แบบดั้งเดิมโยกมันไปอยู่ใต้ init, เดสก์ท็อป Linux โยกไปอยู่ใต้ตัวจัดการผู้ใช้ของ systemd ส่วน Windows ไม่โยกไปไหนเลย ปล่อยให้มันชี้ไปยังโปรเซสแม่ที่ไม่มีอยู่แล้ว ยามเฝ้าจึงไม่เคยดูโปรเซสแม่เลย มันจดจำสิ่งที่มันรับมาดูแลตั้งแต่ตอนที่สายสัมพันธ์ยังอยู่ แล้วถือว่าอะไรก็ตามที่หายไปจากต้นไม้โปรเซสที่ยังมีชีวิตคือโปรเซสกำพร้า เหมือนกันทั้งสามระบบ สองในเจ็ดตัวที่เราวัดอยู่ในสภาพนั้นแล้ว
มันพอกพูนขึ้นเรื่อย ๆ
หนึ่งตัวต่อการตรวจสอบหนึ่งรอบ หนึ่งตัวต่อการค้นหาที่ซวยหนึ่งครั้ง และเพิ่มอีกหนึ่งทุกครั้งที่เอเจนต์เข้าใจว่าคำสั่งที่แค่ช้าคือคำสั่งที่ค้าง แล้วสั่งรันมันใหม่ เราวัดได้ว่ามีการตรวจชนิดข้อมูลสิบสองตัวรันพร้อมกัน เปิดขึ้นมาโดยเอเจนต์หกตัว โดยสองตัวในนั้นถือไว้ตัวละสามงาน นี่คือเหตุผลที่ความช้าเพิ่มขึ้นตลอดทั้งวันแบบไม่มีลด และเหตุผลที่การรีบูตดูเหมือนจะแก้ปัญหาได้ มันไม่ได้แก้อะไรเลย มันแค่ตั้งตัวนับกลับไปที่ศูนย์
ยามเฝ้าโปรเซสทำอะไรบ้าง
มันเฝ้าดูโปรเซสที่เอเจนต์ของคุณเปิดขึ้นมา และมันจงใจแคบมากเรื่องว่าจะไปยุ่งกับตัวไหน
วัดหน่วยความจำที่ใช้จริง
ไม่ใช่ขนาด resident ซึ่งรายงานโปรเซสที่ค้างต่ำกว่าความจริงไปหลายกิกะไบต์ ยามเฝ้าอ่านปริมาณที่ใช้จริง นับรวมเพจที่ถูกบีบอัดและเพจที่ถูกสลับลง swap ไปแล้วด้วย โปรเซสที่แสดง 20 MB แต่ยึดไว้ 8 GB จึงถูกมองเห็นตามที่มันเป็นจริง
วัดตัวประมวลผล แต่ไม่เชื่อมัน
การใช้ตัวประมวลผลถูกอ่านเป็นอัตราระหว่างการสแกนสองครั้ง ไม่ใช่ค่าเฉลี่ยตลอดอายุที่เครื่องมือระบบรายงาน โปรเซสที่เคยทำงานหนักแล้วมาค้างทีหลังจึงยังถูกจับได้ สิ่งที่ค่านี้ให้คือเกณฑ์ที่สูงขึ้นสำหรับอะไรที่ยังทำงานอยู่ ไม่ใช่ใบผ่านฟรี: โปรเซสหลุดมือที่กินหนึ่งในห้าของคอร์หนึ่งคือสิ่งที่ยามเฝ้ารุ่นแรกเคยพลาดไปพอดี
จับโปรเซสกำพร้าได้ด้วย
โปรเซสที่อยู่ได้นานกว่าเอเจนต์ที่เปิดมันขึ้นมาจะถูกรายงานด้วยตัวมันเอง เพราะจะไม่มีใครอื่นมาเก็บกวาดให้ ความเป็นเจ้าของถูกจดจำไว้ตั้งแต่ตอนที่โปรเซสยังผูกอยู่กับเอเจนต์ ซึ่งเป็นจังหวะเดียวที่ระบุมันได้
คลิกเดียวก็จบมันได้
ป้ายบนแถบสถานะจะไล่รายชื่อโปรเซสที่ค้างแต่ละตัว พร้อมเอเจนต์ที่เปิดมัน หน่วยความจำ อายุ และ CPU ของมัน การจบตัวหนึ่งจะปิดทุกอย่างที่มันแตกลูกออกไปด้วย หน่วยความจำกลับคืนมาทันทีและเอเจนต์ของคุณก็ยังทำงานต่อ
macOS, Windows และ Linux
แต่ละระบบต้องใช้วิธีวัดคนละแบบกว่าจะบอกความจริงเรื่องหน่วยความจำได้: เพจที่ถูกบีบอัดบน macOS, resident บวกส่วนที่ลง swap บน Linux, private commit บน Windows ทั้งสามแบบทำเสร็จแล้ว ไม่ใช่แค่วางแผนไว้
แทบไม่กินทรัพยากรเลย
สแนปช็อตโปรเซสหนึ่งครั้งต่อนาที วัดได้ราว 40 ms บนเครื่องที่รันอยู่ 824 โปรเซส การวัดหน่วยความจำแบบแพงจะทำงานก็ต่อเมื่อมีบางอย่างดูค้างอยู่แล้วเท่านั้น และจะไม่มีการสแกนเลยตราบใดที่ไม่มีเอเจนต์ทำงานอยู่
เห็นทั้งฝูง ไม่ใช่แค่ตัวที่โดดออกมา
การตรวจชนิดข้อมูลสิบสองตัว ตัวละ 1.4 GB รวมเป็น 16.8 GB บนเครื่อง 16 GB และทุกตัวล้วนอยู่ต่ำกว่าเกณฑ์ที่สมเหตุสมผล เมื่อโปรเซสที่เอเจนต์ของคุณเปิดขึ้นมารวมกันแล้วถมหน่วยความจำจริงของเครื่องไปครึ่งหนึ่ง ขนาดจะไม่ถูกตัดสินทีละตัวอีกต่อไป
ระบุชื่อเอเจนต์ที่ต้องรับผิดชอบ
คำสั่งที่ถูกชี้ตั้งแต่สองคำสั่งขึ้นไปจากเอเจนต์ตัวเดียวกันจะถูกจัดกลุ่มไว้ใต้อวาตาร์ของมัน พร้อมยอดรวมที่พวกมันยึดไว้และคำเตือนที่อธิบายว่าพวกมันติดอยู่ในวงจรแบบไหน คำสั่งเดียวคืออุบัติเหตุ หลายคำสั่งพร้อมกันคือพฤติกรรม
ขัดจังหวะเอเจนต์ ไม่ใช่แค่โปรเซส
การจบโปรเซสขณะที่เอเจนต์ยังอยู่กลางรอบงานของมัน เท่ากับยื่น error ให้เอเจนต์ตัวนั้นตอบสนอง ซึ่งบ่อยครั้งคือการรันคำสั่งเดิมอีกรอบ มีปุ่มหนึ่งที่ส่ง Ctrl+C ไปยังเทอร์มินัลของเอเจนต์แทน: รอบงานของมันจบลง ไม่มีอะไรถูกรันใหม่ และเอเจนต์ยังเปิดอยู่เหมือนเดิม
กฎสองข้อที่ทำให้มันไม่กลายเป็นเด็กเลี้ยงแกะ
ยามเฝ้าที่ชี้ว่า build ของคุณมีปัญหา คือยามเฝ้าที่คุณจะปิดทิ้งภายในหนึ่งสัปดาห์ เกณฑ์จึงถูกตั้งไว้สูงโดยตั้งใจ โปรเซสลูกของเอเจนต์ทุกตัวที่มีอายุเกินเกณฑ์ที่คุณตั้งไว้จะถูกวัดหน่วยความจำจริง และจะถูกรายงานเมื่อมันยึดไว้มากกว่าที่คุณอนุญาต ส่วนโปรเซสที่ยังใช้ตัวประมวลผลอยู่ต้องยึดไว้เป็นสองเท่าของค่านั้น และนี่คือสิ่งที่ทำให้ build ที่ยาวนานแต่ถูกต้องไม่ถูกรบกวน
การใช้ตัวประมวลผลเป็นตัวกำหนดความสูงของเกณฑ์นั้น ไม่ใช่ประตูที่คอยกันไว้ ยามเฝ้ารุ่นแรกกำหนดว่าโปรเซสต้องอยู่นิ่งเสียก่อนถึงจะยอมไปดูหน่วยความจำของมัน และนั่นคือความผิดพลาด การค้นหาที่แพตเทิร์นทำให้เอนจิน regex ระเบิดไม่ได้อยู่นิ่ง: มันกินหนึ่งในห้าของคอร์หนึ่ง ขณะที่เคอร์เนลต้องสลับข้อมูลหลายกิกะไบต์ลง swap ให้มัน แย่กว่านั้นคือ ยิ่งมีพวกนี้พอกพูนมากเท่าไหร่ แต่ละตัวก็ยิ่งได้ตัวประมวลผลน้อยลง จุดบอดจึงกว้างที่สุดตอนเริ่มต้นพอดี ซึ่งเป็นตอนที่การจบมันสักตัวมีต้นทุนต่ำที่สุด
กฎข้อที่สองมีอยู่เพราะเกณฑ์รายโปรเซสมองไม่เห็นฝูง การตรวจชนิดข้อมูลสิบสองตัวที่ยึดไว้ตัวละ 1.4 GB นั้นแยกดูทีละตัวก็สมเหตุสมผล แต่รวมกันแล้วถึงตายบนเครื่อง 16 GB ดังนั้นเมื่อทุกอย่างที่เอเจนต์เปิดขึ้นมารวมกันได้ครึ่งหนึ่งของหน่วยความจำจริงของเครื่อง ทั้งหมดนั้นจะถูกรายงาน ไม่ว่าแต่ละชิ้นจะหนักแค่ไหนก็ตาม และไม่มีอะไรในกลุ่มนั้นถูกจบอัตโนมัติเด็ดขาด: มันต่ำกว่าขีดจำกัดที่คุณตั้งไว้ และมันถูกชี้ก็เพราะเพื่อนบ้านของมันเท่านั้น
มันทำงานอย่างไร
สี่ขั้นตอน นาทีละครั้ง และขั้นตอนที่แพงแทบไม่เคยทำงานเลย
สแนปช็อตราคาถูกหนึ่งภาพของทั้งเครื่อง
ทุกนาที ยามเฝ้าจะถ่ายสแนปช็อตของโปรเซสทั้งหมดที่กำลังทำงานเพียงภาพเดียว แล้วไล่ต้นไม้โปรเซสใต้เทอร์มินัลของเอเจนต์แต่ละตัว ต้นทุนที่วัดได้บนเครื่องที่รันอยู่ 824 โปรเซส: ราว 40 ms และตราบใดที่ไม่มีเอเจนต์ทำงาน เรื่องนี้ก็ไม่เกิดขึ้นเลย
คัดรายชื่อผู้ต้องสงสัย
จากสแนปช็อตนั้น มันจะเก็บโปรเซสลูกของเอเจนต์ทุกตัวที่มีอายุเกินเกณฑ์ที่คุณตั้งไว้ ตัวกรองมีแค่นั้น และไม่มีอะไรถูกคัดออกเพราะยังใช้ตัวประมวลผลอยู่: การทำแบบนั้นคือสาเหตุที่ยามเฝ้ารุ่นก่อนพลาดโปรเซสหลุดมือไป ในการใช้งานปกติรายชื่อนี้จะว่างเปล่า เพราะการเรียกใช้เครื่องมือของเอเจนต์จบภายในไม่กี่วินาที
วัดเฉพาะตัวที่ดูเหมือนค้าง
ยามเฝ้าจะยอมจ่ายค่าการวัดหน่วยความจำจริงเฉพาะกับรายชื่อสั้น ๆ นั้นเท่านั้น โดยนับรวมเพจที่ถูกบีบอัดและเพจที่ลง swap ไปแล้ว โปรเซสที่มันวัดไม่ได้จะไม่ถูกชี้ว่าผิดเด็ดขาด: สิ่งที่ยังไม่รู้ไม่ใช่คำตัดสิน
รายงาน แล้วปล่อยให้คุณตัดสินใจ
ป้ายหนึ่งอันจะโผล่ขึ้นบนแถบสถานะ พร้อมการแจ้งเตือนครั้งเดียวที่บอกคุณ คุณเปิดรายการขึ้นมา เห็นว่าโปรเซสนั้นคืออะไร ยึดไว้เท่าไหร่ ค้างมานานแค่ไหน และเอเจนต์ตัวไหนเป็นคนเปิดมัน แล้วจบมันถ้าคุณต้องการ
สิ่งที่มันจะไม่แตะเด็ดขาด
เครื่องมือที่จบโปรเซสได้ต้องเข้มงวดมากว่าอะไรคือธุระของมัน ข้อจำกัดเหล่านี้อยู่ในโครงสร้าง ไม่ใช่ตัวเลือกที่คุณต้องจำไว้ว่าต้องไปเปิด
- ตัว CLI ของเอเจนต์เอง ไม่ว่าคุณจะใช้ผู้ให้บริการรายไหน ยามเฝ้าจะปกป้องไบนารีที่แอปใช้เปิดเทอร์มินัลนั้นเสมอ มันอ่านชื่อนั้นจากคำสั่งเปิดโดยตรง ไม่ใช่จากรายชื่อที่เขียนตายตัวไว้ ดังนั้นโปรเซสย่อยของ CLI ตัวเดียวกันก็ได้รับการปกป้องด้วย ไม่ว่าจะลึกกี่ชั้น
- เทอร์มินัลคำสั่ง dev ของคุณ เซิร์ฟเวอร์พัฒนาที่นิ่งอยู่เข้าเกณฑ์โปรเซสหลุดมือครบทุกข้อ: อ้วน เก่า ไม่ใช้ตัวประมวลผล และมันก็เป็นโปรเซสเดียวที่คุณอยากให้รันอยู่จริง ๆ มีแต่เทอร์มินัลของเอเจนต์เท่านั้นที่ถูกเฝ้าดู เซิร์ฟเวอร์พัฒนาของคุณจึงไม่เคยเข้ามาอยู่ในภาพเลย
- เชลล์และท่อภายในของตัวแอปเอง ตัวช่วยเทอร์มินัลและเชลล์ที่เอเจนต์รันอยู่ข้างในถูกกันออกตั้งแต่การออกแบบ มีแต่โปรเซสของเครื่องมือที่อยู่ใต้ CLI ของเอเจนต์เท่านั้นที่จะเข้าข่ายได้
- อะไรก็ตามที่มันไม่ได้รับมาดูแล เส้นทางเดียวที่จบโปรเซสได้จะปฏิเสธทุกโปรเซสที่ยามเฝ้าไม่ได้เก็บมาจากต้นไม้โปรเซสของเอเจนต์เอง มันจึงกลายเป็นช่องทางสำหรับปิดอย่างอื่นบนเครื่องคุณไม่ได้
และจะไม่มีอะไรถูกจบอัตโนมัติเว้นแต่คุณจะสั่งเอง โดยค่าเริ่มต้น ยามเฝ้าจะรายงานสิ่งที่มันเจอแล้วให้คุณตัดสินใจ เพราะคุณคือคนเดียวที่รู้ว่าโปรเซสก้อนใหญ่ที่เงียบอยู่นั้นเป็นสิ่งที่คาดไว้อยู่แล้วหรือเปล่า และต่อให้เปิดไว้ การจบอัตโนมัติก็จะไม่แตะอะไรที่ยังใช้ตัวประมวลผลอยู่ และไม่แตะอะไรที่ถูกชี้เพียงเพราะปริมาณที่เพื่อนบ้านของมันยึดไว้
เมื่อไหร่ที่มันพิสูจน์คุณค่าของตัวเอง
ทุกสถานการณ์ข้างล่างนี้เกิดขึ้นจริง ไม่มีอันไหนเป็นการสมมติ
เครื่องช้าตอนหกโมงเย็นกว่าตอนเก้าโมงเช้า
ไม่มีจังหวะไหนที่มันพังชัด ๆ มีแต่การไหลลงอย่างสม่ำเสมอตลอดวัน รูปแบบแบบนี้เกือบทุกครั้งคือโปรเซสค้างที่สะสมกันไว้ และเป็นแบบที่วินิจฉัยด้วยมือยากที่สุด เพราะไม่ว่าจะหยิบมาดูวินาทีไหนก็ไม่มีอะไรดูผิดปกติเลย
เอเจนต์หลายตัวทำงานคู่ขนานกัน
ยิ่งคุณรันเอเจนต์มากเท่าไหร่ ก็ยิ่งมีการเรียกใช้เครื่องมือมากเท่านั้น และยิ่งมีโอกาสที่ตัวใดตัวหนึ่งจะไปค้าง อัตราความล้มเหลวต่อการเรียกหนึ่งครั้งนั้นเล็กจิ๋ว แต่พอคูณด้วยวันทำงานคู่ขนานทั้งวัน มันก็เลิกเล็กจิ๋ว
การค้นหาที่ไม่เคยกลับมา
แพตเทิร์นที่ทำให้เอนจิน regex ระเบิดจะจองหน่วยความจำหลายกิกะไบต์กับไฟล์ที่มีขนาดแค่ไม่กี่ร้อยกิโลไบต์ เอเจนต์รอมัน คุณรอเอเจนต์ และเครื่องก็จ่ายค่าให้ทั้งสองฝ่าย
คุณปิดเอเจนต์ไปแล้ว แต่โปรเซสยังอยู่
การปิดแท็บไม่ได้คืนอะไรเสมอไป โปรเซสที่หลุดออกไปแล้วยังเก็บหน่วยความจำของมันไว้ และเสียสายสัมพันธ์เส้นสุดท้ายกับทุกอย่างที่คุณมองเห็นในแอป
โน้ตบุ๊กที่มี 16 GB
บนเครื่องที่ RAM เหลือเฟือ โปรเซสค้างไม่กี่ตัวซ่อนตัวอยู่ได้นานมาก แต่บนโน้ตบุ๊ก 16 GB มันแตะ swap เร็ว และทันทีที่ระบบเริ่มบีบอัดหน่วยความจำ เอเจนต์ทุกตัวก็ช้าลงพร้อมกันหมด
ก่อนที่คุณจะโทษแอป
เวลาที่เครื่องคลานเป็นเต่าขณะที่ AgentsRoom เปิดอยู่ แอปคือผู้ต้องสงสัยที่ชัดที่สุด การมีตัวเลขจริงเป็นรายโปรเซส พร้อมชื่อเอเจนต์ที่เปิดแต่ละตัว เปลี่ยนความสงสัยให้กลายเป็นสิ่งที่ตรวจสอบได้จริง
คุณเป็นคนกำหนดขีดจำกัด
ค่าเริ่มต้นถูกตั้งไว้อย่างระมัดระวังโดยตั้งใจ ทุกอย่างข้างล่างนี้อยู่ในการตั้งค่า แท็บ Terminal และแต่ละอย่างยังอ่านและแก้ไขได้โดยเอเจนต์ผ่านเครื่องมือ MCP ของ AgentsRoom ด้วย
- เฝ้าดูโปรเซสลูกของเอเจนต์
- เปิดไว้เป็นค่าเริ่มต้น ปิดมันแล้วจะไม่มีการสแกนเกิดขึ้นอีกเลย ตลอดไป
- รายงานเมื่อเกินเกณฑ์หน่วยความจำ
- ค่าเริ่มต้นคือสองกิกะไบต์ ต่ำกว่านั้น โปรเซสที่ค้างยังไม่คุ้มที่จะมารบกวนคุณ ปรับขึ้นบนเวิร์กสเตชันที่ RAM เยอะ ปรับลงบนโน้ตบุ๊กที่หน่วยความจำจำกัด
- หลังจากมีอายุขั้นต่ำแล้ว
- ค่าเริ่มต้นคือห้านาที ต่ำกว่านั้นจะไม่มีการวัดใด ๆ เลย และนี่คือสิ่งที่ทำให้การเรียกใช้เครื่องมือธรรมดาของเอเจนต์ ซึ่งจบภายในไม่กี่วินาที อยู่นอกภาพไปทั้งหมด
- จบโปรเซสที่ค้างโดยอัตโนมัติ
- ปิดไว้เป็นค่าเริ่มต้น และนั่นเป็นการตัดสินใจเชิงผลิตภัณฑ์ที่ตั้งใจ ไม่ใช่แค่ความระมัดระวัง ยามเฝ้ากำลังใช้ดุลยพินิจ และมีแต่คุณเท่านั้นที่รู้ว่าโปรเซสก้อนใหญ่ที่เงียบอยู่นั้นเป็นสิ่งที่คาดไว้หรือเปล่า เปิดมันแล้วมันจะลงมือเอง พร้อมแจ้งเตือนให้ทราบภายหลัง
เกณฑ์ตัวประมวลผลไม่ถูกเปิดให้ปรับ และจุดที่ถือว่าเครื่องอิ่มตัวแล้วก็เช่นกัน ทั้งสองค่าเคยตั้งผิดมาแล้ว และถูกแก้ด้วยการวัดเหตุการณ์จริง ไม่ใช่ด้วยรสนิยม การใส่แถบเลื่อนให้ค่าใดค่าหนึ่งจึงแทบจะเป็นแค่วิธีเอาจุดบอดกลับคืนมา
คำถามที่พบบ่อย
แปลว่า AgentsRoom ทำให้คอมพิวเตอร์ของฉันช้าลงหรือเปล่า
ไม่ และนี่แหละคือเหตุผลที่ฟีเจอร์นี้มีอยู่ ในเซสชันที่เราวัด ตัวแอปใช้ 2.8 GB กระจายบน 91 โปรเซส และ CLI ของเอเจนต์แปดตัวรวมกันใช้ 1.6 GB ส่วน 41.8 GB นั้นถูกยึดไว้โดยโปรเซสของเครื่องมือที่ไปค้าง AgentsRoom บังเอิญเป็นที่เดียวที่มองเห็นเอเจนต์ทุกตัวและโปรเซสทุกตัวที่มันเปิดขึ้นมา จึงเป็นที่เดียวที่ตัดสินเรื่องนี้ได้
มันจะไปฆ่า build หรือการรันเทสต์ของฉันไหม
มันจะไม่จบอะไรโดยไม่ถามคุณเด็ดขาด แต่มันรายงานได้: build จะต้องยึดไว้เป็นสองเท่าของเกณฑ์ที่คุณตั้ง ซึ่งค่าเริ่มต้นคือสี่กิกะไบต์ หรือไม่ก็เป็นส่วนหนึ่งของกลุ่มโปรเซสของเอเจนต์ที่รวมกันแล้วถมหน่วยความจำเครื่องคุณไปครึ่งหนึ่ง แต่การจบอัตโนมัติจะไม่แตะโปรเซสที่ยังใช้ตัวประมวลผลอยู่ และไม่แตะโปรเซสที่ถูกชี้เพียงเพราะปริมาณที่เพื่อนบ้านของมันยึดไว้ ทั้งสองกรณีคุณจะได้แถวข้อมูลหนึ่งแถว ตัวเลขจริง และปุ่มหนึ่งปุ่ม และจะไม่มีอะไรเกิดขึ้นจนกว่าคุณจะกดมัน
มันเฝ้าเซิร์ฟเวอร์พัฒนาของฉันด้วยไหม
ไม่ และจะไม่มีวันเฝ้า เซิร์ฟเวอร์พัฒนาที่นิ่งอยู่เข้าเกณฑ์ครบทุกข้อ: มันยึดหน่วยความจำไว้เยอะ มันรันมาหลายชั่วโมงแล้ว และมันไม่ใช้ตัวประมวลผลระหว่างรีเควสต์ มีแต่โปรเซสลูกของเทอร์มินัลเอเจนต์เท่านั้นที่ถูกเฝ้าดู คำสั่ง dev ของคุณจึงอยู่นอกขอบเขตตั้งแต่การออกแบบ
มันจบตัวเอเจนต์เองได้ไหม
ไม่ได้ CLI ของเอเจนต์ได้รับการปกป้องไม่ว่าคุณจะใช้ผู้ให้บริการรายไหน และการปกป้องนั้นอิงกับไบนารีที่แอปใช้เปิดเทอร์มินัลนั้น ไม่ใช่รายชื่อที่รู้จักกันอยู่แล้ว เชลล์และตัวช่วยเทอร์มินัลของแอปเองก็ถูกกันออกเช่นกัน
โปรเซสกำพร้าคืออะไร และทำไมถึงได้รับการปฏิบัติเป็นพิเศษ
โปรเซสที่ตัวแม่ของมันจบไปแล้วจะเสียการเชื่อมโยงกับเอเจนต์ที่เปิดมันขึ้นมา และจะไม่มีใครมาเก็บกวาดให้ การเชื่อมโยงนั้นขาดอย่างไรขึ้นอยู่กับระบบ: Unix แบบดั้งเดิมโยกมันไปอยู่ใต้ init, เดสก์ท็อป Linux โยกไปอยู่ใต้ตัวจัดการผู้ใช้ของ systemd ส่วน Windows ไม่โยกไปไหนเลย และทิ้งไว้แค่หมายเลขโปรเซสแม่ที่ตายไปแล้ว 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 กลับไปแทนที่จะค้างอยู่ตลอดกาล ซึ่งเป็นผลลัพธ์ที่คุณต้องการอยู่แล้ว: ยังไงโปรเซสนั้นก็ไม่มีวันเสร็จ ไม่มีอะไรถูกเริ่มใหม่และไม่มีบริบทไหนสูญหาย
มันแก้ที่ต้นเหตุได้ไหม
ไม่ได้ และมันก็ไม่ได้พยายามจะแก้ ต้นเหตุเปลี่ยนไปเรื่อย ๆ: วันนี้เป็นเครื่องมือตัวหนึ่ง พรุ่งนี้เป็นแพตเทิร์นอีกแบบ เดือนหน้าเป็นผู้ให้บริการอีกราย นี่คือตาข่ายนิรภัย ที่ออกแบบมาให้ยังทำงานได้เมื่อต้นเหตุเป็นสิ่งที่ยังไม่มีใครเคยเห็น
โปรเซสสิบสองตัว ไม่มีสักตัวที่เกินเกณฑ์ของฉัน มันจะบอกอะไรฉันไหม
บอก และกรณีแบบนี้แหละคือเหตุผลที่กฎเปลี่ยนไป วัดบนเครื่อง 16 GB: การตรวจชนิดข้อมูลสิบสองตัวที่เอเจนต์หกตัวเปิดขึ้นมา ตัวละ 0.84 ถึง 1.72 GB ทุกตัวต่ำกว่าเกณฑ์ 2 GB อยู่มาก แต่รวมกันได้ 15.4 GB, swap เต็ม และเครื่องใช้งานไม่ได้ ถ้าตัดสินทีละตัว ทุกตัวไม่มีปัญหาเลย แต่พอยอดรวมเกินครึ่งหนึ่งของหน่วยความจำจริงของคุณ ทั้งหมดจะถูกรายงาน โดยจัดกลุ่มไว้ใต้เอเจนต์ที่เปิดมันขึ้นมา
“ขัดจังหวะเอเจนต์” ทำอะไรกันแน่
มันส่ง Ctrl+C ไปยังเทอร์มินัลของเอเจนต์ตัวนั้น ซึ่งเป็นปุ่มเดียวกับที่คุณจะกดเอง รอบงานปัจจุบันของเอเจนต์จบลงและมันรอคุณ: มันไม่ถูกปิด เซสชันยังอยู่ครบ และไม่มีอะไรอื่นบนเครื่องคุณถูกแตะต้อง ปุ่มนี้มีอยู่เพราะการจบโปรเซสขณะที่เอเจนต์ยังทำงานกับมันอยู่นั้นแก้แค่อาการ เนื่องจากเอเจนต์จะได้รับ error แล้วบ่อยครั้งก็แค่รันคำสั่งเดิมอีกครั้ง
คุณอาจสนใจสิ่งเหล่านี้ด้วย
Context Canary
สัญญาณเตือนล่วงหน้าอีกตัวหนึ่ง: มันเฝ้าดูบริบทของตัวเอเจนต์เองแทนที่จะเป็นตัวเครื่อง และบอกคุณเมื่อเอเจนต์เริ่มเบี่ยงเบน ก่อนที่มันจะเริ่มแต่งไฟล์และ API ขึ้นมาเอง
เทอร์มินัลสำหรับนักพัฒนา
รันเซิร์ฟเวอร์พัฒนาและคำสั่งยาว ๆ ของคุณใน AgentsRoom พร้อมการแจ้งเตือนเมื่อคำสั่งยาวทำงานเสร็จ เทอร์มินัลเหล่านี้แหละคือสิ่งที่ยามเฝ้าโปรเซสถูกออกแบบมาไม่ให้แตะเด็ดขาด
การติดตามสถานะเอเจนต์
เห็นได้ในพริบตาว่าเอเจนต์ตัวไหนกำลังทำงาน ตัวไหนรอคุณอยู่ และตัวไหนว่าง โดยไม่ต้องอ่านเทอร์มินัลสักอัน
การใช้โทเค็น
อีกทรัพยากรหนึ่งที่ควรจับตา ปริมาณการใช้โทเค็นและโควตารายเอเจนต์ เพื่อให้คุณรู้ว่าการใช้งานของคุณหมดไปกับอะไร
มุมมองแบ่งจอ
เอเจนต์หลายตัวเรียงข้างกันในหน้าต่างเดียว แต่ละตัวมีพาเนล สี และสถานะแบบสดของตัวเอง
CLI Doctor
เมื่อเอเจนต์เปิดขึ้นมาไม่ได้ มันจะบอกคุณว่าเพราะอะไรและต้องทำอย่างไร แทนที่จะทิ้งเทอร์มินัลเปล่า ๆ ไว้ให้
เลิกจ่ายค่าโปรเซสที่ไม่มีใครใช้
AgentsRoom ดาวน์โหลดฟรี และยามเฝ้าโปรเซสเปิดทำงานตั้งแต่การเปิดแอปครั้งแรก
แอปคู่หู: ตรวจสอบเอเจนต์ของคุณได้ทุกที่
นำของคุณเอง: Claude, Codex, Antigravity CLI, หรือผู้ให้บริการ AI อื่น ๆ
ส่งข้อบกพร่องและคำขอไปยังแบ็คล็อกสาธารณะของคุณโดยตรง