Giữ AI Agent Chạy Khi Bạn Đang Ngủ

Vì Sao Mac Ngắt AI Agent Của Bạn Vào Ban Đêm

macOS được thiết kế để vào chế độ ngủ khi không phát hiện thao tác nào từ người dùng — bàn phím, chuột, trackpad. Một AI agent chạy trong terminal không tạo ra sự kiện input nào, nên bộ đếm ngủ màn hình kích hoạt trước, rồi đến system sleep. Ngay khoảnh khắc máy vào trạng thái suspend, agent mất quyền được CPU lập lịch và mất luôn kết nối mạng — lượt chạy dừng giữa chừng mà không có cách phục hồi sạch sẽ, thậm chí không có checkpoint nào được lưu trừ khi chính công cụ đó tự ghi lại.

Đóng nắp máy là một tác nhân khác, riêng biệt và nhanh hơn nhiều, và nó không quan tâm máy đang chạy gì. Mặc định, một MacBook sẽ suspend chỉ vài giây sau khi nắp đóng lại, bất kể có tác vụ nền nào đang chạy. Một công cụ như caffeinate -i chặn được idle sleep khi nắp còn mở, nhưng khi dùng pin, nó không thể chặn được lớp clamshell sleep sâu hơn mà macOS kích hoạt ngay khi nắp đóng lại — không có power assertion cấp người dùng nào làm được việc đó. Đây là giới hạn của macOS, không phải của caffeinate: mọi công cụ được xây trên cùng cơ chế IOPMAssertionCreateWithName, kể cả chế độ Keep Awake thủ công của chính LidRun, đều đụng phải bức tường tương tự nếu không có một cơ chế riêng cho trường hợp đóng nắp.

Pin tạo ra kiểu lỗi thứ ba. macOS có cơ chế tự tắt máy khi pin ở mức nguy kịch, và có thể ép máy ngủ trước cả mốc đó nếu nó thấy điều kiện đủ đáng lo. Một agent đang chạy inference nặng hay một build kéo dài có thể ngốn hết 50% pin chỉ trong ba đến bốn tiếng. Không có điểm dừng được định trước, hệ điều hành sẽ tự quyết định khi nào lượt chạy kết thúc — và nó không phải lúc nào cũng chọn đúng thời điểm sạch sẽ.

Những Lựa Chọn Miễn Phí Có Sẵn — Và Giới Hạn Của Từng Cái

Trước khi tìm đến bất kỳ app bên thứ ba nào, đáng để biết macOS đã cho bạn sẵn những gì, vì với một tác vụ ngắn chạy ở foreground thì thường là đủ. caffeinate -i chặn idle sleep trong suốt thời gian nó chạy; thêm -w <pid> thì nó sẽ tự thoát khi tiến trình đó thoát — đây là cách dùng có sẵn gọn nhất cho một lệnh đơn mà bạn đang theo dõi, ví dụ caffeinate -i -w $(pgrep -f "python train.py"). caffeinate -d chặn luôn cả display sleep, còn -s chặn riêng system sleep khi máy đang cắm sạc (AC power). Nó có sẵn trên mọi Mac, không cần cài thêm gì, và có thể viết script hoàn toàn.

Nhưng không cái nào trong số đó sống sót được qua việc đóng nắp khi dùng pin. Đòn bẩy công khai duy nhất ngăn được sleep khi đóng nắp mà không cần màn hình ngoài là sudo pmset -a disablesleep 1 — một thiết lập ở cấp toàn hệ thống, không phải một assertion theo từng tiến trình, và nó cần quyền admin. Đây cũng chính là cơ chế nền mà chế độ Closed-Lid của LidRun đang dùng; không có API riêng tư nào ở đây cả, chỉ là công tắc pmset đã được Apple tài liệu hóa. Con đường gốc còn lại là chế độ clamshell thực sự của Apple: cắm một màn hình ngoài và giữ máy cắm sạc, Mac sẽ chạy với nắp đóng đúng như thiết kế, không cần lệnh gì cả. Đó là con đường được hỗ trợ chính thức, nhưng nó có nghĩa là bạn phải sở hữu và mang theo một màn hình — không thực tế cho một lượt chạy qua đêm trong phòng khách sạn hay một phòng ngủ phụ.

Các app menu-bar bên thứ ba lấp vào khoảng giữa hai thái cực đó. Amphetamine, KeepingYouAwake, Caffeine, và Lungo đều là những công tắc giữ-thức chắc chắn, tập trung đúng việc — giao diện chỉn chu, có timer, một số hỗ trợ đặt lịch bật/tắt. Chúng là lựa chọn hợp lý nếu điều bạn muốn đơn giản chỉ là "giữ máy thức cho tới khi tôi bảo thôi". Điều không cái nào trong số đó làm được là gắn trạng thái giữ-thức với một tiến trình nền cụ thể, theo dõi mức pin hay nhiệt độ, hoặc tự nhả ra ngay khi tiến trình của agent thoát — đó vốn không phải việc chúng được sinh ra để làm.

Rủi Ro Khi Tự Làm Thủ Công

Cả hai con đường có sẵn của macOS đều có một cạnh sắc khi dùng cho một lượt chạy qua đêm không có người trông. caffeinate -i không kèm -w thì cứ chạy mãi cho tới khi bạn tự kill nó — không có gì tự dừng nó khi công việc đã xong, nên rất dễ để Mac thức và ngốn pin thêm nhiều tiếng sau khi agent đã hoàn thành từ lâu, và nó vẫn bị bất ngờ bởi việc đóng nắp khi dùng pin.

sudo pmset -a disablesleep 1 lại rủi ro theo một kiểu khác, vì nó mang tính toàn cục và tồn tại lâu dài — không giới hạn trong phiên terminal của bạn hay trong tiến trình bạn thực sự quan tâm. Thiết lập này vẫn tồn tại sau khi lệnh đặt ra nó đã kết thúc. Nếu bạn đóng terminal, nếu Mac bị crash, hoặc đơn giản là bạn quên chạy sudo pmset -a disablesleep 0 vào sáng hôm sau, Mac sẽ không tự ngủ được nữa — không phải đêm đó, cũng không phải ngày hôm sau — cho tới khi bạn tự đặt lại hoặc khởi động lại máy. Trong lúc đó, không có gì theo dõi ngưỡng pin hay trần nhiệt độ cả, và cũng không có gì nhận ra rằng agent thực ra đã xong việc từ hai mươi phút trước.

Đó mới là lỗ hổng thật sự — không phải vì caffeinate hay pmset là công cụ tệ, chúng đúng là thứ cần dùng cho một tác vụ foreground mà bạn đang theo dõi. Lỗ hổng nằm ở chỗ không lựa chọn miễn phí nào, và không công tắc luôn-bật của bên thứ ba nào, biết được "agent đã xong" nghĩa là gì. Chúng chỉ giữ Mac thức hoặc không giữ; không hề có khái niệm nhả ra khi tiến trình thoát, lùi lại khi chạm ngưỡng pin, hay lùi lại khi máy quá nóng.

Cách Làm An Toàn Hơn: Gắn Giữ-Thức Với Tiến Trình Của Agent

Cách khắc phục là thứ LidRun gọi là Auto Mode: giữ-thức gắn với tiến trình, cơ chế cốt lõi đứng sau lớp runtime an toàn cho công việc AI trên Mac của LidRun. Nó chỉ giữ một power assertion khi có một tiến trình khớp đang chạy, và nhả ra ngay khi tiến trình đó thoát — không phải một wake lock mù quáng giữ Mac thức bất kể thực tế đang diễn ra gì. Danh mục có sẵn của nó đã nhận diện được Claude Code, Codex, Cursor, Windsurf, Aider, Cline, Continue, Goose, OpenHands, Zed, Ollama, LM Studio, và vLLM theo tên tiến trình, cộng thêm các script chạy qua interpreter (python, node, ruby, và nhiều loại khác), và bất kỳ thứ gì bạn tự thêm bằng lidrun watch <pattern>.

Nó cũng cẩn thận hơn là chỉ khớp tên. Một cửa sổ Cursor chỉ đang mở mà không làm gì thì không giữ Mac thức — một app GUI cần vượt qua một ngưỡng CPU thực sự (khoảng trên 40% của một nhân) thì mới được tính là đang làm việc, nên để một trình soạn thảo mở qua đêm không tự dưng chặn sleep vô lý. Và một agent đã biết mà im lặng một lúc — đang chờ phản hồi từ API, đang "suy nghĩ" giữa các lần gọi tool — cũng không bị loại ngay lập tức: các tiến trình agent có tên trong danh mục được cho một khoảng kiên nhẫn thực sự, tới 30 phút gần như không hoạt động, trước khi Auto Mode coi là đã xong, để một phản hồi model chậm không khiến bạn mất trắng cả lượt chạy.

Với một tác vụ đơn lẻ qua SSH, hay một máy headless không có menu bar để nhìn vào, CLI bọc trực tiếp một lệnh đơn: lidrun -- claude-code run-task giữ một assertion có phạm vi đúng bằng vòng đời của tiến trình đó, không cần cấu hình watch-list gì cả. Bản thân Auto Mode là một phần của LidRun Pro — gói miễn phí đã bao gồm Keep Awake thủ công không giới hạn, Timer, và các lượt chạy Charging-only; phần nâng cấp thêm vào là khả năng tự động phát hiện tiến trình.

Với các lượt chạy đóng nắp, vị trí đặt máy vẫn quan trọng — phát hiện tiến trình có thông minh đến đâu cũng không thay đổi được vật lý của nhiệt. Đặt Mac trên một bề mặt phẳng, cứng, để không khí lưu thông được bên dưới: một cái bàn, một cái stand, một mặt bàn chắc chắn — không phải trên giường, không phải trong túi xách, không phải trong một khoang kín. Nắp đóng lại loại bỏ đường thoát khí chính, nên nhiệt vốn thường thoát qua khu vực bàn phím giờ cần tìm đường khác để đi. Ưu tiên chạy khi cắm sạc: xả pin liên tục dưới tải sinh thêm nhiệt so với khi chạy cắm điện. Cách thiết lập theo từng công cụ cụ thể được nói kỹ trong các bài hướng dẫn giữ Claude Code chạy khi MacBook đóng nắp và giữ Cursor agent chạy trên Mac.

Cũng không có gì ở đây là kiểu "thiết lập một lần rồi quên". Một công việc có điểm dừng rõ ràng — một danh sách tác vụ, một timeout, một file cụ thể cần ghi ra — an toàn hơn nhiều so với một prompt mở, có thể lặp vô hạn khi gặp lỗi hoặc tự prompt lại chính mình. Trước khi đóng nắp, hãy xác nhận agent có chỗ để dừng lại; một lượt chạy có thể lặp vô thời hạn sẽ tiếp tục rút điện và sinh nhiệt mà không hề tiến triển, và chỉ riêng mức dùng CPU thì không thể phân biệt được "vẫn đang làm việc" với "đang kẹt trong một vòng lặp".

Thiết Lập Ngưỡng An Toàn Cho Pin Và Nhiệt Độ

20% là một ngưỡng hợp lý cho phần lớn khối lượng công việc chạy qua đêm — đây cũng chính là giá trị mặc định mà LidRun đưa ra sẵn, cho cả auto-stop giữ-thức nói chung lẫn ngưỡng pin của Auto Mode. Nó để lại khoảng đệm thực sự phía trên ngưỡng sống còn cứng của chính LidRun (một lưới an toàn ép-ngủ được kẹp cứng trong khoảng 4% đến 8% bất kể bạn đặt gì) và vẫn còn đủ pin để thực sự dùng Mac vào buổi sáng. Với công việc nhẹ hơn, phụ thuộc nhiều vào API — nơi agent chủ yếu chờ phản hồi mạng — 15% có thể ổn; với inference chạy local hay build nặng, nên giữ ở 20% trở lên. Vấn đề mấu chốt là có đặt một ngưỡng hay không — nếu không có, hệ điều hành sẽ tự quyết định khi nào dừng, và nó không phải lúc nào cũng chọn đúng thời điểm sạch sẽ.

Giới hạn nhiệt độ đáng để cấu hình dù bạn có tin tưởng cơ chế bảo vệ sẵn có của Mac đến đâu. macOS giảm xung CPU trước khi có gì nghiêm trọng xảy ra, nhưng giảm xung nghĩa là agent chạy ì ạch thêm nhiều tiếng thay vì dừng gọn gàng — và chạy chậm-mà-nóng trong thời gian dài hơn tích lũy nhiều nhiệt hơn so với việc chủ động dừng rồi khởi động lại. Safety Governor của LidRun theo dõi trạng thái nhiệt qua API công khai ProcessInfo.thermalState của Apple, và nó cố tình chỉ hoạt động một chiều: nó không bao giờ giữ Mac thức, nó chỉ nhả một trạng thái giữ-thức hoặc ép máy ngủ khi điều kiện có vẻ không an toàn. Khi nhiệt độ thực sự đạt mức nguy kịch, nó nhả ngay lập tức, ở mọi chế độ và mọi nguồn điện — nhưng nó chỉ leo thang lên mức ép-ngủ thật sự nếu bạn đang rời khỏi bàn phím hoặc nắp máy đang đóng lại vật lý, nên một phiên làm việc sống bạn đang theo dõi với nắp mở sẽ không bao giờ bị giật ra khỏi tay bạn; nó nhả trạng thái giữ-thức và để cơ chế giảm xung của chính Mac làm phần việc còn lại.

Trên Apple Silicon, phần mềm ở user-space có thể đọc được trạng thái nhiệt nhưng không thể trực tiếp điều khiển tốc độ quạt — đó là lãnh địa của kernel, nên hãy coi mọi thiết lập nhiệt là một lưới an toàn, không phải một núm vặn. Kết hợp ngưỡng pin với lưới an toàn nhiệt, bạn có hai điều kiện auto-stop độc lập: cái nào chạm ngưỡng trước thì cái đó đạp phanh, thay vì để công việc chạy tiếp cho tới khi phần cứng hoặc hệ điều hành tự can thiệp. Bài hướng dẫn safety governor nói sâu hơn về cách các giới hạn pin, nhiệt, và trần thời gian tương tác với nhau.

Xác Minh Nó Thực Sự Đang Hoạt Động

Trước khi đóng nắp máy, một lần kiểm tra năm giây còn tốt hơn là phát hiện ra vấn đề lúc 7 giờ sáng. Icon trên menu-bar phản ánh việc LidRun có đang giữ một trạng thái keep-awake hay clamshell hay không — liếc qua nó trước khi bạn rời đi. Qua SSH, hay trên một máy headless không có menu bar để nhìn, hãy chạy lidrun status từ terminal thay vào đó; nó in ra chế độ hiện tại, power assertion có đang hoạt động không, Closed-Lid có bật không, phần trăm pin hiện tại và trạng thái sạc, mức nhiệt độ, và — nếu Auto Mode đang bật — những tiến trình nào đang được theo dõi mà nó nhìn thấy lúc này.

Nếu một tiến trình bạn kỳ vọng được theo dõi mà không xuất hiện, lidrun patterns liệt kê mọi thứ đang có trong watch-list, kể cả danh mục agent có sẵn. Thêm bất kỳ thứ gì còn thiếu bằng lidrun watch <pattern> — hữu ích cho một script wrapper tự viết hoặc một công cụ không nằm dưới bất kỳ tên nào đã được nhận diện sẵn.

Nhận Thông Báo Khi Công Việc Hoàn Tất

Push notification là mắt xích khép lại vòng lặp — không có nó, bạn chỉ có thể tự kiểm tra thủ công hoặc đoán mò. LidRun hỗ trợ ntfy.sh, một relay thông báo miễn phí và mở, để gửi push tới điện thoại của bạn ngay khi phiên keep-awake kết thúc; Pushover cũng được hỗ trợ nếu bạn muốn dùng một app trả phí, chuyên dụng hơn. Phiên đó kết thúc khi tiến trình của agent thoát, nên thông báo là một chỉ báo trực tiếp cho việc công việc đã xong hoặc đã dừng — không cần tích hợp webhook phía server nào cả.

Thông báo báo hiệu phiên đã kết thúc, không phải công việc đã thành công — dù agent hoàn thành, gặp lỗi, hay dừng vì lưới an toàn pin hoặc nhiệt kích hoạt, trên điện thoại nó đều trông giống hệt nhau. Mở Activity Log để xem thực sự đó là trường hợp nào; LidRun ghi lại lý do dừng cụ thể — một tác vụ hoàn thành bình thường, một auto-stop vì pin hay vì nhiệt, một lần dừng thủ công, hay Safety Governor nhả trạng thái giữ-thức — và log đó là cục bộ, luôn ở đó ngay cả khi bản thân push notification không bao giờ tới. Thông báo bị rớt vẫn có thể xảy ra: ntfy.sh là một relay bên thứ ba và Pushover cần một kết nối còn sống tại thời điểm gửi, nên nếu mạng của Mac chập chờn đúng lúc lượt chạy kết thúc, hãy kiểm tra log trực tiếp thay vì mặc định là không có gì xảy ra.

Với một lượt chạy dài hơn, lớp Watchdog tùy chọn (một tính năng trả phí) có thể cảnh báo giữa chừng nếu một agent đang theo dõi im lặng một lúc — có thể là bị kẹt chứ không phải đã xong — thay vì để bạn chỉ biết được vào lúc kết thúc. Hãy coi đó là một lời nhắc, không phải một phán quyết: phân biệt một agent bị crash với một agent chỉ đơn giản là hoàn thành tác vụ nhanh cần nhiều tín hiệu hơn những gì LidRun hiện có (thời lượng tác vụ dự kiến, exit code), nên cảnh báo agent-bị-kẹt có nghĩa là "đi kiểm tra thử", không phải "chắc chắn nó đã fail".

"Agent Của Tôi Vẫn Bị Dừng" — Đọc Hiểu Lý Do Dừng

Nếu keep-awake đang bật mà lượt chạy vẫn bị dừng, Activity Log gần như luôn giải thích được lý do, và thường rơi vào một trong ba trường hợp. Nếu mục ghi cho thấy một sự kiện task-đã-hoàn-thành hay tiến-trình-đã-thoát bình thường, đó không phải là một lỗi — tiến trình của agent đã thoát và Auto Mode đã nhả trạng thái giữ-thức đúng như thiết kế.

Nếu đó là một lần dừng vì pin hay vì nhiệt, đó là lưới an toàn đang làm đúng việc của nó, không phải một lỗi — cả ý nghĩa của việc đặt một ngưỡng là để nó thỉnh thoảng kích hoạt. Đối chiếu phần trăm pin hay mức nhiệt trong log với những gì bạn đã đặt; nếu nó kích hoạt sớm hơn dự kiến, có thể ngưỡng đang đặt cao hơn mức khối lượng công việc thực sự cần, hoặc Mac đã chạy pin dưới tải nặng hơn bình thường.

Nếu log cho thấy Safety Governor tự nhả trạng thái giữ-thức, điều đó chỉ xảy ra khi dùng pin, khi LidRun đã xác nhận không có gì thực sự đang chạy và bạn đã rời khỏi bàn phím một lúc — một trình soạn thảo code đang mở mà không có hoạt động CPU thực sự nào đọc thành trạng thái xác-nhận-rảnh, không phải đang làm việc. Chạy lidrun status khi agent đang hoạt động để kiểm tra xem nó có thực sự xuất hiện như một tác vụ khớp với mức dùng CPU thực hay không. Nếu không, nhiều khả năng tên tiến trình không khớp với bất kỳ mục nào trong watch-list (kiểm tra lidrun patterns và thêm nó bằng lidrun watch <pattern>), hoặc công cụ đó là một app GUI đang nằm dưới ngưỡng CPU mà Auto Mode dùng để phân biệt "đang mở" với "đang làm việc".