AI Agent Đã Thay Đổi Cách Quản Lý Nguồn Điện Laptop Như Thế Nào

Vì Sao Chế Độ Ngủ Khi Rảnh Từng Hợp Lý — Cho Đến Khi AI Agent Phá Vỡ Giả Định Đó

Quản lý nguồn điện laptop được thiết kế theo nhịp sinh hoạt của con người. Không có thao tác bàn phím trong vài phút: màn hình mờ dần. Lâu hơn chút nữa: máy ngủ. Các bộ đếm thời gian rảnh (idle timer) của Apple hợp lý vì công việc của máy là chờ bạn, và chờ đợi thì tốn pin. Assertion mà một app giữ để máy không ngủ luôn gắn chặt với process của nó — ngay khi app thoát hoặc crash, macOS tự động giải phóng assertion đó. Đây là một lựa chọn thiết kế có chủ đích, và chính vì thế mô hình này mới an toàn để xây dựng theo cách đó suốt ba mươi năm.

Mô hình này đứng vững suốt hàng chục năm qua các tác vụ tải file nền, biên dịch lâu, encode video, vì những việc đó hoặc hoàn tất nhanh, hoặc giữ một power assertion để báo cho hệ điều hành biết trong lúc chạy. Một trình render video giữ media assertion; xcodebuild hoàn tất trong vài phút rồi thoát. Máy luôn có một tín hiệu nào đó để dựa vào, và tín hiệu đó luôn tự dọn dẹp sau khi xong.

Không có gì trong thiết kế đó lường trước được một tác vụ chạy hàng giờ mà không có thao tác người dùng và không có ranh giới hoàn thành tự nhiên nào cả. Kịch bản đó đơn giản là chưa từng tồn tại vào thời điểm mô hình quản lý nguồn này được viết ra.

Vì Sao Mac Của Bạn Ngủ Giữa Lúc Agent Đang Chạy

Các AI coding agent — Claude Code, background agent của Cursor, Aider, GitHub Copilot Workspace — hoạt động bằng cách nối hàng chục bước lại với nhau: đọc file, lên kế hoạch sửa, viết code, chạy test, đọc kết quả, rồi lặp lại. Một tác vụ refactor duy nhất có thể chạy liền hai, ba tiếng mà không có ai ngồi trước bàn phím.

macOS không coi bất kỳ điều nào trong số đó là hoạt động. Không có sự kiện bàn phím, không di chuột, không có khung hình mới nào được render lên màn hình. Bộ đếm thời gian rảnh chạy về 0, màn hình ngủ, rồi hệ thống ngủ theo ngay sau đó — chấm dứt phiên Terminal giữa lúc công việc đang dang dở.

Nếu bạn không chắc chuyện này có thực sự xảy ra với mình hay không, đừng tin vào Activity Monitor sau khi sự việc đã rồi — process lúc đó đơn giản là biến mất khỏi danh sách. Bằng chứng rõ ràng hơn nằm trong Terminal: lệnh pmset -g log | grep -i sleep liệt kê các sự kiện ngủ và thức dậy thật kèm mốc thời gian, nhờ đó bạn có thể đối chiếu khoảng trống trong log của agent với một lần hệ thống ngủ mà macOS đã ghi lại đúng thời điểm đó.

Đây không phải lỗi của macOS. Ngủ khi rảnh là hành vi đúng đắn đối với một cỗ máy thực sự đang rảnh. Vấn đề mang tính cấu trúc nằm ở chỗ hệ điều hành không có khái niệm sẵn có nào cho một process đang làm việc "tư duy" thay cho người dùng — công việc mà người dùng thực sự muốn nó hoàn thành.

Cách Khắc Phục Miễn Phí: caffeinate, pmset, và Các App Giữ Máy Thức Trên Menu Bar

Điều đầu tiên đáng thử không tốn một xu và có sẵn trong macOS. caffeinate -i giữ đúng loại power assertion mà LidRun giữ cho trường hợp mở nắp — system idle-sleep assertion — và cách dùng gọn nhất là giao thẳng lệnh chạy agent cho nó: caffeinate -i your-agent-command. Khi đó assertion sẽ gắn liền với process đó và tự động giải phóng ngay khi agent thoát, thay vì chạy mãi cho tới khi bạn nhớ ra mà tắt nó đi.

Nếu bạn không muốn đụng đến Terminal, ý tưởng tương tự chỉ cách một cú click trong một app trên menu bar. Amphetamine, KeepingYouAwake, Lungo, và app Caffeine (đúng như cái tên của nó) đều giữ cùng loại assertion như caffeinate, chỉ khác là có nút bật/tắt và bộ đếm giờ trực quan thay vì dòng lệnh. Với trường hợp chúng được sinh ra để phục vụ — Mac đang cắm sạc, nắp mở, có người ở gần để phát hiện nếu có gì bất thường — bất kỳ app nào trong số đó cũng làm tốt việc của mình.

Không cái nào trong số này — kể cả caffeinate — giữ được MacBook chạy khi đóng nắp, trừ khi có màn hình ngoài được kết nối. Đóng nắp máy sẽ kích hoạt một luồng ngủ riêng, ở tầng thấp hơn gọi là clamshell sleep, mà idle-sleep assertion không thể ngăn được; đây là một cơ chế khác hoàn toàn so với cơ chế mà cả caffeinate lẫn LidRun dùng cho trường hợp mở nắp. Nếu bạn có setup để bàn, cách khắc phục miễn phí này thực sự miễn phí: cắm một màn hình ngoài (và bàn phím hoặc chuột, nếu Mac chưa nhận sẵn thiết bị nào), đóng nắp lại, và macOS sẽ coi nó như một máy để bàn — không cần thêm công cụ gì cả. Nếu không có màn hình ngoài, đòn bẩy công khai duy nhất là sudo pmset -a disablesleep 1, lệnh này sẽ hỏi mật khẩu admin và đi kèm một cái bẫy thực sự sẽ nói tới ngay sau đây.

Cách Khắc Phục Miễn Phí Bó Tay Ở Đâu: Pin, Nhiệt Độ, và Cài Đặt pmset Bị Kẹt

caffeinate và các app giữ máy thức trên menu bar không có ngưỡng pin sàn nào cả. Để một chiếc MacBook giữ wake assertion ở mức pin 40% trong khi chạy một vòng lặp agent nặng, hoàn toàn có khả năng bạn quay lại sẽ thấy pin cạn sạch, phiên làm việc mất trắng, và một diff sửa dở dang — công cụ đó đã làm đúng những gì nó hứa, chỉ là nó không có cách nào để dừng lại trước khi hết pin. Tốc độ hết pin thực tế thì khác nhau rất nhiều: một agent chủ yếu chờ phản hồi từ API gần như không tốn CPU, trong khi một agent chạy model cục bộ có thể khiến mọi nhân CPU bận rộn suốt nhiều giờ. Chính sự khó đoán này là lý do vì sao một ngưỡng pin tính theo phần trăm lại hiệu quả hơn một bộ đếm giờ cố định — bạn không thể biết trước bốn tiếng "làm việc AI" thực sự sẽ ngốn bao nhiêu pin.

Nhiệt độ là rủi ro tinh vi hơn, và nó đo được chứ không chỉ là cảm giác. Bản thân macOS chỉ cung cấp một tín hiệu thô — ProcessInfo.thermalState, chia làm bốn mức: Nominal, Fair, Serious, Critical — và tín hiệu này có thể trễ hơn thực tế. Trong một lần thử nghiệm nội bộ trên MacBook Intel (i7-1068NG7), một tác vụ bình thường với nắp mở giữ nhiệt độ quanh mức 95°C trong khi mức throttle của CPU vẫn duy trì trên 80%; khi để kín trong túi với cùng tải công việc đó, mức throttle thực tế giảm xuống còn khoảng 24% trong khi thermalState vẫn báo "Fair" — con chip đã tự bảo vệ mình từ trước khi tín hiệu ở tầng hệ điều hành kịp bắt kịp thực tế. Khoảng cách đó chính là lý do vì sao một wake lock chỉ kiểm tra thermalState, hoặc không kiểm tra gì cả, không có lớp bảo vệ thực sự nào trong không gian bí bách: một chiếc nắp gần khép kín, một bề mặt mềm chặn khe thoát nhiệt, hay một chiếc túi.

Cách né clamshell cũng có kiểu lỗi riêng của nó. pmset -a disablesleep 1 là một cài đặt toàn cục, tồn tại lâu dài và không gắn với bất kỳ process cụ thể nào. Nếu bất cứ thứ gì đã bật nó lên bị crash — một script, một phiên Terminal, một app — cài đặt đó vẫn giữ nguyên ở mức 1 và Mac sẽ không ngủ theo nắp nữa cho đến khi có gì đó chủ động đặt lại về 0 (sudo pmset -a disablesleep 0) hoặc bạn khởi động lại máy. Đây là một cái bẫy có thật, đã được ghi nhận, không phải giả thuyết suông: cài đặt đó đơn giản là không hề biết process đã yêu cầu nó đã biến mất.

Một Quy Trình An Toàn Hơn Cho Các Lượt Chạy AI Agent Dài

Với một lượt chạy nhanh ban ngày trong khi bạn đang ngồi ở bàn làm việc và cắm sạc, caffeinate hoặc một app trên menu bar thực sự là đủ dùng — không cần thêm công cụ gì, và nói thẳng ra thì đúng là như vậy.

Với các phiên chạy qua đêm, chạy bằng pin, hoặc đóng nắp, bạn cần ba thứ mà các công cụ miễn phí không gộp chung lại được: một ngưỡng pin sàn để lượt chạy dừng trước khi máy chết chứ không phải sau đó, khả năng nhận biết áp lực nhiệt thực tế thay vì chỉ dựa vào tín hiệu thô của hệ điều hành, và — nếu nắp đang đóng — một cách để tự phục hồi nếu bất cứ thứ gì đang giữ disablesleep bị crash, thay vì để Mac kẹt lại. Sự kết hợp đó gần như chính là mục đích của một lớp runtime an toàn cho công việc AI trên Mac: không phải một wake lock mạnh hơn, mà là một lớp theo dõi các điều kiện có thể khiến việc tiếp tục chạy trở nên không an toàn, rồi lùi lại một cách nhẹ nhàng thay vì chạy mù quáng.

Nếu bạn không muốn quản lý nguồn điện cục bộ chút nào, có một lựa chọn thay thế hợp lý: chạy agent trên một máy từ xa — một VM trên cloud, một GitHub Codespace, hoặc một chiếc Mac mini luôn bật mà bạn SSH vào — và để laptop của bạn ngủ bình thường trong khi công việc chạy ở nơi khác. Đánh đổi ở đây là có thật: bạn mất đi sự tiện lợi của việc làm việc trực tiếp trên checkout cục bộ, và bạn phải trả tiền cho tài nguyên tính toán mà lẽ ra có thể không cần đến. Với nhiều quy trình làm việc cục bộ, giữ nguyên repo tại chỗ, việc giữ cho chính chiếc laptop thức và được bảo vệ vẫn là hướng đi đơn giản hơn.

LidRun Phù Hợp Ở Đâu

Nguyên tắc của LidRun rất đơn giản: agent đang chạy thì giữ máy thức; agent xong việc hoặc rơi vào tình huống không an toàn thì giải phóng và để Mac ngủ. Cơ chế đứng sau là một process watcher (Auto-Watch) quét lại mỗi mười giây các process mà bạn yêu cầu theo dõi, chỉ giữ wake assertion khi có ít nhất một process đang thực sự dùng CPU vượt một ngưỡng (mặc định 20%) — kèm thời gian ân hạn 60 giây để một process tạm thời rảnh vì đang chờ phản hồi từ model hay chờ I/O đĩa không làm assertion bật tắt liên tục. Khi không còn process nào đang theo dõi chạy nữa, assertion tự giải phóng. Đó là nửa "agent xong việc" của lời hứa, và nó không phải một bộ đếm giờ cố định hay thứ gì đó bạn phải nhớ để tắt đi.

Về mặt pin, một ngưỡng auto-stop do bạn đặt — mặc định 20%, có thể chỉnh trong khoảng 15% đến 50% — sẽ giải phóng assertion để macOS ngủ theo cơ chế idle-sleep bình thường thay vì để pin cạn dần. Bên dưới đó là một ngưỡng sàn không thể chỉnh, khoảng 4%: ngay cả khi bạn đặt auto-stop rất thấp, LidRun vẫn yêu cầu Mac ngủ khi gần cạn pin thay vì để một phiên chạy đến khi tắt máy vì hết điện. Về mặt nhiệt độ, LidRun đọc nhiệt độ SMC thực tế và phần trăm throttle của CPU song song với tín hiệu ở tầng hệ điều hành, lùi lại ở khoảng 98°C hoặc throttle ở mức 50% trở xuống (serious), và 100°C hoặc throttle ở mức 30% trở xuống (critical) — sát với trạng thái phần cứng thực tế hơn nhiều so với chỉ dùng thermalState.

Closed-Lid mode dùng đúng đòn bẩy pmset -a disablesleep đã nói ở trên, nhưng thực hiện qua một privileged helper chỉ cần cấp quyền một lần, nên không phải hỏi mật khẩu admin mỗi lần dùng. Chế độ "Sleep when done" của nó tự cho máy ngủ sau 10, 20, hoặc 30 phút không có process nào đang theo dõi chạy, và một crash-guard heartbeat phát hiện giá trị disablesleep bị kẹt ở mức 1 do một phiên trước đó bị crash để lại, rồi tự động đặt lại vào lần tiếp theo app khởi động — đúng kiểu lỗi cụ thể đã mô tả ở trên, được tự động xử lý thay vì để bạn phải tự phát hiện. Một Safety Governor vẫn áp dụng bên dưới tất cả những cơ chế này: nó có thể dừng hoặc yêu cầu máy ngủ khi pin hoặc nhiệt độ trở nên không an toàn, bất kể nắp mở hay đóng.

Keep Awake, tính năng auto-stop theo pin, và process watching đều miễn phí, không giới hạn thời gian — LidRun không khóa các tính năng cơ bản sau một bản dùng thử. Closed-Lid mode, tính năng nặng ký và rủi ro hơn, cho bạn một số lượt chạy miễn phí giới hạn để dùng thử trước khi yêu cầu mở khóa Pro. Nếu các lượt chạy AI agent qua đêm và đóng nắp là một phần thường xuyên trong quy trình làm việc của bạn chứ không phải thỉnh thoảng mới dùng, bài viết giữ AI agent chạy trong khi bạn ngủ đáng để đọc tiếp theo.