Triển khai AI Agent tự động hóa trong giờ hành chính trên VPS Linux

Một AI agent chỉ đáng giá khi nó chạy liên tục. Nhưng máy cá nhân không ai bật trong giờ hành chính, còn chạy trên VPS thì hay gặp cảnh: process chết im lặng lúc 2 giờ sáng, hoặc browser ngốn sạch RAM rồi OOM. Bài này hướng dẫn bạn triển khai AI agent tự động hóa trong giờ hành chính trên VPS Linux, từ chọn cấu hình vừa đủ, cài môi trường Node.js và Playwright, viết vòng lặp vô hạn có backoff, cho tới giám sát và tự khởi động lại khi crash. Toàn bộ lệnh chạy trên Ubuntu 24.04 hoặc Debian 12, thao tác bằng user sudo non-root.

Yêu cầu trước khi bắt đầu

• VPS Linux chạy Ubuntu 24.04 LTS hoặc Debian 12, đã cập nhật (apt update && apt upgrade).
• Một user sudo non-root; các bước cài đặt dùng sudo, riêng phần chạy agent nên dùng user riêng.
• RAM tối thiểu: 2 GB nếu agent chỉ gọi API LLM; 4 GB nếu có Playwright/Chromium chạy kèm.
• Node.js LTS hiện hành (bản 22.x) và npm.
• API key của nhà cung cấp LLM (hoặc endpoint model nội bộ), cất trong EnvironmentFile chứ không nhúng vào code.

Vì sao nên tách agent ra khỏi máy cá nhân

Agent tự động hóa bản chất là một tiến trình nền: nó chờ job, gọi model, thao tác trình duyệt, ghi log và lặp lại. Ba thứ dễ giết nó nhất là ngủ máy, mất mạng đột ngột và rò rỉ bộ nhớ tích lũy theo thời gian. Bạn không kiểm soát được ba thứ đó trên laptop.

Một VPS Linux với IPv4 riêng cho bạn ba lợi thế cụ thể: địa chỉ mạng ổn định để webhook/API gọi tới, quyền root để chỉnh swap, giới hạn tài nguyên và giám sát, và khả năng cài lại OS khi môi trường bị bẩn. Nếu agent cào dữ liệu hay chạy nhiều phiên trình duyệt, việc có IP riêng thuộc dải Việt Nam còn giúp truy cập các site nội địa ổn định hơn.

Điều cần nhớ ngay từ đầu: đừng tin "cứ để nó chạy". Hãy thiết kế agent như một dịch vụ hệ thống, có supervisor và có log. Phần lớn thời gian bạn sẽ tiêu vào việc nó ngừng chạy lúc nào, chứ không phải lúc nó chạy.

Câu hỏi đầu tiên: agent cần bao nhiêu RAM và CPU

Bước 1 - Tạo user riêng và cài Node.js LTS

Đừng chạy agent bằng root. Tạo user chuyên trách để giới hạn thiệt hại nếu code có lỗ hổng.

sudo adduser --disabled-password --gecos "" agent
sudo usermod -aG sudo agent
curl -fsSL https://deb.nodesource.com/setup_22.x | sudo -E bash -
sudo apt install -y nodejs
node -v
npm -v

Lệnh node -v phải in ra bản 22.x; nếu vẫn 18.x thì bạn đang gọi Node của hệ thống, hãy kiểm tra lại nguồn cài đặt. Sau khi cài, chuyển sang user agent và tạo thư mục làm việc:

sudo su - agent
mkdir -p ~/agent/logs ~/agent/data
cd ~/agent

Bước 2 - Cài Playwright và các thư viện hệ thống

Nếu agent chỉ gọi API thì bỏ qua bước này. Nếu agent cần điều khiển trình duyệt, dùng Playwright với dependency system đầy đủ.

npm init -y
npm i playwright
npx playwright install --with-deps chromium

Tham số --with-deps quyết định thành bại: nó cài các thư viện libnss3, libatk, fonts-liberation mà Chromium cần. Thiếu chúng, browser khởi động rồi crash ngay khi mở trang, và log chỉ báo một dòng khó hiểu. Kiểm tra bằng một script tối thiểu:

node -e "const {chromium}=require('playwright');(async()=>{const b=await chromium.launch();const p=await b.newPage();await p.goto('https://example.com');console.log(await p.title());await b.close();})()"

Kết quả mong đợi: in ra Example Domain. Nếu thấy lỗi liên quan thư viện thiếu, chạy lại npx playwright install-deps chromium.

Bước 3 - Viết vòng lặp vô hạn có backoff

Đây là phần quyết định agent sống được bao lâu. Cấm viết while(true) { await job() } trần trụi: chỉ cần một lần gọi API lỗi là process thoát và bạn mất cả đêm.

const job = require('./job');

const sleep = (ms) => new Promise(r => setTimeout(r, ms));

async function main() {
  let delay = 1000;
  while (true) {
    try {
      await job.run();
      delay = 1000; // reset về 1s khi thành công
    } catch (e) {
      console.error(new Date().toISOString(), 'job loi:', e.message);
      delay = Math.min(delay * 2, 60000); // backoff tối đa 60s
    }
    await sleep(delay);
  }
}

process.on('SIGTERM', () => { console.log('dung agent'); process.exit(0); });
main();

Ba điểm cần nắm. Thứ nhất, backoff lũy tiến tránh hammer API liên tục khi sự cố kéo dài. Thứ hai, bắt SIGTERM để agent thoát sạch khi systemd dừng, không để zombie process. Thứ ba, đẩy API key ra biến môi trường thay vì hardcode:

sudo mkdir -p /etc/agent
sudo tee /etc/agent/env >/dev/null <<'EOF'
LLM_API_KEY=thay_bang_key_that
MAX_CONCURRENCY=2
EOF
sudo chmod 600 /etc/agent/env

Bước 4 - Biến agent thành dịch vụ systemd tự khởi động lại

Đây là chìa khóa của "trong giờ hành chính": systemd lo việc khởi động lại, bạn không cần cron hay nohup. Tạo unit file:

sudo tee /etc/systemd/system/agent.service >/dev/null <<'EOF'
[Unit]
Description=AI Agent worker
After=network-online.target
Wants=network-online.target

[Service]
User=agent
WorkingDirectory=/home/agent/agent
EnvironmentFile=/etc/agent/env
ExecStart=/usr/bin/node index.js
Restart=always
RestartSec=5
MemoryMax=1500M
Nice=5

[Install]
WantedBy=multi-user.target
EOF
sudo systemctl daemon-reload
sudo systemctl enable --now agent
sudo systemctl status agent

Restart=always cùng RestartSec=5 nghĩa là process chết vì bất kỳ lý do gì (trừ khi bị dừng có chủ ý) sẽ tự bật lại sau 5 giây. MemoryMax=1500M là giới hạn cứng: nếu agent rò rỉ RAM tới mức đó, systemd kill và restart nó, thay vì để OOM killer quét cả máy. Với agent nặng, cấu hình này chạy ổn trên một VPS chạy automation cấu hình vừa phải. Trạng thái mong đợi: active (running).

Bước 5 - Bổ sung swap và giới hạn trình duyệt

Agent rò rỉ bộ nhớ chậm là chuyện bình thường. Một ít swap giúp máy không chết trước khi bạn kịp xử lý.

sudo fallocate -l 2G /swapfile
sudo chmod 600 /swapfile
sudo mkswap /swapfile
sudo swapon /swapfile
echo '/swapfile none swap sw 0 0' | sudo tee -a /etc/fstab
free -h

Với Chromium, hãy giới hạn tài nguyên từ trong code thay vì để trình duyệt tự do:

const browser = await chromium.launch({
  args: ['--no-sandbox', '--disable-dev-shm-usage', '--disable-gpu'],
  headless: true
});

--disable-dev-shm-usage đặc biệt quan trọng trên VPS: thư mục /dev/shm mặc định thường nhỏ, và nếu để mặc định Chromium sẽ crash ngẫu nhiên khi tab mở nhiều. Cờ này đẩy dữ liệu tạm ra đĩa và hết lỗi.

Bước 6 - Giám sát và cảnh báo khi agent chết

systemd tự restart là chưa đủ; bạn cần biết khi nó restart liên tục vì lỗi thật chứ không phải chập chờn. Xem log trước:

journalctl -u agent -n 50 --no-pager
systemctl show agent -p NRestarts

NRestarts tăng nhanh là dấu hiệu agent crash lặp. Cách bắt cảnh báo gọn nhất là dùng OnFailure:

[Unit]
OnFailure=notify-fail@%n.service

Thực tế, cách mình hay dùng hơn là một script nhỏ gửi cảnh báo qua Telegram khi đếm restart vượt ngưỡng, kèm 20 dòng log cuối. Nếu bạn muốn dựng luồng cảnh báo bài bản, cách gửi thông báo qua bot và log tập trung đã có sẵn ở bài cảnh báo hệ thống VPS qua Telegram.

Song song, hãy chặn agent phình số phiên trình duyệt: đặt một bộ đếm tối đa, đóng context ngay sau mỗi job, và gọi browser.close() trong finally. Một agent tốt không phải agent chạy nhanh nhất, mà là agent không để lại rác.

Xử lý lỗi thường gặp

Ba lỗi dưới đây chiếm phần lớn thời gian debug khi chạy AI agent trên VPS:

• Agent bị OOM-kill lúc nửa đêm: kiểm tra bằng journalctl -k | grep -i oom và free -h. Nguyên nhân thường là không đóng browser sau job. Đặt MemoryMax trong unit file để giới hạn thiệt hại.
• Chromium crash với lỗi shared memory: thêm --disable-dev-shm-usage, và nếu vẫn lỗi hãy tăng /dev/shm hoặc cấu hình lại dung lượng.
• Service báo start failed nhưng không rõ lý do: chạy journalctl -xeu agent để xem log chi tiết, và kiểm tra biến môi trường trong /etc/agent/env đã được nạp đúng chưa bằng cách thử systemctl show agent -p Environment.

Một mẹo nhỏ: trước khi chạy dài, hãy để agent chạy thật 1-2 giờ và theo dõi RAM theo phút bằng watch -n 60 free -h. Đồ thị RAM đi ngang là tốt; đi lên đều đặn là bạn đang có rò rỉ và nên sửa trước khi để nó chạy qua đêm.

Câu hỏi thường gặp

AI agent tự động hóa trong giờ hành chính trên VPS Linux cần cấu hình tối thiểu bao nhiêu?

Agent gọi API LLM cần khoảng 1 vCPU / 2 GB RAM. Agent dùng Playwright điều khiển Chromium nên có ít nhất 2 vCPU / 4 GB RAM, cộng thêm 200-400 MB cho mỗi phiên trình duyệt chạy song song. Nếu vừa chạy agent vừa chạy database hoặc n8n, chọn 8 GB cho thoải mái.

Vì sao agent tự thoát dù đã bật systemd restart?

Thường do lỗi chưa được bắt trong code khiến process exit, hoặc một lần ghi log/ghi đĩa thất bại. Kiểm tra bằng journalctl -u agent -n 50 để xem log ngay trước lần restart, và đảm bảo toàn bộ thân vòng lặp nằm trong try/catch.

Có nên dùng nohup hay screen để chạy agent dài hạn?

Không. nohup và screen không tự khởi động lại khi máy reboot hay khi process chết. Với agent chạy trong giờ hành chính, dùng systemd service để có restart tự động, giới hạn tài nguyên và log tập trung.

Làm sao giới hạn agent không ngốn hết RAM VPS?

Đặt MemoryMax trong unit file systemd, đóng browser trong khối finally sau mỗi job, và bật swap dự phòng. Khi agent vượt ngưỡng, systemd sẽ kill và restart nó thay vì để OOM quét cả máy.

Agent cần IP riêng không?

Không bắt buộc, nhưng có IP riêng giúp webhook/API gọi tới ổn định và tránh dùng chung IP bị chặn. Nếu bạn cần nhiều phiên trình duyệt hoặc tác vụ nhạy cảm với IP, nên thuê VPS IP riêng để tách biệt. Các gói có IPv4 riêng đặt tại Việt Nam phù hợp cho nhu cầu này.

Kết luận

Agent chạy bền không phụ thuộc vào model xịn, mà vào việc bạn bọc nó trong một cấu trúc chịu lỗi: vòng lặp có backoff, dịch vụ systemd tự restart, giới hạn bộ nhớ và cảnh báo khi bất thường. Làm đúng 6 bước trên, agent của bạn có thể chạy qua đêm mà không cần ai ngồi canh. Nếu bạn đang cần một nền tảng Linux ổn định để chạy automation dài hạn, có thể tham khảo VPS n8n cài sẵn hoặc thuê VPS Linux để tự dựng môi trường.

Bài viết liên quan

• Triển khai AI agent tự động có tool calling trên VPS
• VPS chạy AI agent tự động cấu hình thế nào cho đúng
• Headless Chrome ngốn RAM, cách đo và đặt giới hạn
• Lập lịch job automation dài hơi bằng systemd timer