Cách AI Agents Thay Đổi Quản Lý Nguồn Điện MacBook
Bạn khởi chạy một AI coding agent trước bữa tối — một refactor đa file, ước chừng hai giờ. Quay lại thì MacBook đã ngủ, job chết nửa chừng, một diff dở dang nằm trong working tree. Tình huống này không tồn tại năm năm trước. Và nó phơi bày một khoảng trống thực sự giữa cách macOS quản lý nguồn điện và cách developer thực sự dùng máy.
Laptop Được Thiết Kế Ngủ Như Thế Nào (Và Tại Sao Nó Hoạt Động)
Quản lý nguồn điện laptop được thiết kế theo nhịp của con người. Không bấm phím vài phút: màn hình mờ dần. Lâu hơn chút nữa: máy ngủ. Idle timer của Apple hợp lý vì nhiệm vụ của máy là chờ bạn — mà chờ thì tốn pin.
Mô hình này hoạt động suốt cả thập kỷ — qua background download, build dài, encode video — vì các tác vụ đó hoặc hoàn thành nhanh hoặc giữ một IOKit assertion để báo hiệu cho OS. Một video renderer giữ media assertion; xcodebuild chạy vài phút rồi thoát. Máy luôn có tín hiệu để nhận biết trạng thái.
Không có gì trong thiết kế đó lường trước một loại workload chạy hàng giờ mà không có tương tác người dùng và không có điểm kết thúc tự nhiên. Tình huống đó đơn giản không tồn tại khi power model được viết ra.
Công Việc AI Agentic Thay Đổi Nhu Cầu Developer Ra Sao
AI coding agents — Claude Code, background agent của Cursor, Aider, GitHub Copilot Workspace — hoạt động bằng cách thực hiện liên tiếp hàng chục bước: đọc file, lên kế hoạch chỉnh sửa, viết code, chạy test, phân tích output, rồi lặp lại. Một tác vụ refactor đơn giản cũng có thể chạy hai đến ba tiếng.
macOS không nhận ra bất kỳ điều gì trong số đó là hoạt động. Không có keystroke, không có chuột di chuyển, không có frame nào được render. Idle timer đếm ngược về 0. Màn hình tắt. Hệ thống ngủ ngay sau, cắt ngang phiên terminal giữa chừng.
Đây không phải lỗi của macOS. Idle sleep là đúng khi máy thực sự rảnh. Vấn đề cốt lõi là OS không có khái niệm về một tiến trình đang xử lý công việc thay cho người dùng — công việc mà người dùng thực sự muốn hoàn thành.
Hướng dẫn liên quanLớp runtime an toàn giữ Mac thức — và biết khi nào nên dừngTại Sao Wake Lock Đơn Giản Tạo Ra Rủi Ro Mới
Giải pháp rõ ràng nhất là wake lock: caffeinate, Amphetamine, hoặc chỉnh pmset. Những công cụ này giữ một IOKit power assertion và tạm dừng idle timer. Agent tiếp tục chạy. Với một phiên ban ngày ngắn, cắm điện, ngồi gần máy — thường đây là đủ.
Nhưng với công việc ban đêm hoặc chạy trên pin, câu chuyện khác hẳn. Wake lock không có giới hạn pin tối thiểu. Để MacBook chạy caffeinate ở mức 40% với một agent loop nặng — bốn tiếng sau bạn có thể thấy pin về 0, phiên bị mất, và một commit dở dang ở trạng thái không nhất quán. Công cụ đã làm đúng việc của nó — giữ máy thức — nhưng không có cách nào để dừng an toàn trước khi hết điện.
Nhiệt độ là vấn đề tinh tế hơn. MacBook chịu tải liên tục trong môi trường thiếu thông khí sẽ bị throttle, nhưng wake lock không kiểm tra nhiệt độ — không có guardrail nào cả. Rủi ro này tăng lên trong không gian hẹp: nắp gần đóng, đặt trên bề mặt mềm chặn khe tản nhiệt, hoặc để trong túi. Agent vẫn chạy; máy ngày càng nóng mà không có gì để dừng lại.
Mô Hình Runtime An Toàn Cho Công Việc AI
Một safe runtime layer giữ wake assertion và theo dõi các điều kiện có thể khiến việc tiếp tục chạy trở nên nguy hiểm. Tạm ví: wake lock giữ cửa mở; runtime layer giữ cửa mở cho đến khi hệ thống báo có vấn đề, rồi đóng lại có kiểm soát. Nếu bạn thường xuyên chạy AI workload dài, hiểu cách lớp này hoạt động là khá hữu ích.
Trên thực tế, điều này có nghĩa là đặt ngưỡng pin tối thiểu — tự dừng ở 15 hoặc 20% để máy còn đủ pin khởi động lại sau đó. Nó cũng theo dõi tín hiệu nhiệt mà OS cung cấp và dừng lại khi hệ thống báo áp lực nhiệt. Tính năng theo dõi tiến trình (tùy chọn) thêm một guardrail nữa: tự dừng phiên khi tiến trình agent kết thúc, thay vì chờ đến khi pin về 0%.
Với một lần chạy ban ngày ngắn trên AC, caffeinate là đủ — không cần thêm gì. Nhưng với phiên chạy ban đêm, trên pin, hoặc nắp đóng, một lớp giám sát điều kiện song song với wake assertion giúp giảm rủi ro: thức dậy thấy máy đã hết pin, hoặc job chết nửa chừng ở trạng thái không ổn định.
Tính năng của LidRun's keep-awake engine.
LidRun giữ công việc của bạn chạy tiếp khi đóng nắp, với cơ chế bảo vệ pin và nhiệt tích hợp sẵn.
Câu hỏi thường gặp
Không phải lúc nào cũng cần. Với một lần chạy ngắn, ngồi trước máy, cắm điện — một lệnh caffeinate đơn giản hoặc app keep-awake là đủ giải quyết vấn đề chính: idle sleep timer. Với những run dài hơn, phiên ban đêm, hay chạy trên pin, bạn còn cần ngưỡng pin tối thiểu và cơ chế theo dõi nhiệt. Thiếu hai thứ đó, máy có thể cạn pin hoặc nóng lên mà không có cách dừng an toàn trước khi có sự cố.
macOS đo idle time bằng tương tác người dùng — keystroke, di chuột, và hoạt động màn hình. AI agent không tạo ra bất kỳ tín hiệu nào trong số này; nó chạy ngầm mà không chạm đến thiết bị input nào. Khi idle timer đạt ngưỡng, hệ thống ngủ và cắt phiên terminal của agent, hoặc suspend tiến trình đó hoàn toàn.
Với máy cắm điện trong môi trường ổn định, caffeinate thường là đủ. Trên pin thì khác: caffeinate giữ wake assertion nhưng không có ngưỡng pin tối thiểu, nên máy có thể cạn về 0% giữa chừng. Nếu pin bắt đầu ở 40% mà job chạy bốn tiếng, phiên có thể không kịp hoàn thành. Một công cụ tự dừng ở ngưỡng pin thấp giảm được rủi ro đó mà không cần bạn phải canh chừng.
Một build lâu chạy vài phút, thoát sạch, và nhiều build tool giữ IOKit assertion trong lúc compile. AI agent thì khác: chúng lặp vô định, gọi API ngoài, viết và test code, và có thể chạy hàng giờ mà không có điểm kết thúc xác định. Chính sự kết hợp giữa thời gian dài và kết thúc không thể đoán trước mới tạo ra rủi ro quản lý nguồn điện thực sự — build kết thúc sớm không mất gì; agent chết lúc 3 giờ sáng là mất toàn bộ phiên.