Hermes spawn subagent: chạy nhiều agent song song xử lý batch task

Một con AI agent tuần tự xử lý 100 URL mất 2 tiếng. Cũng con agent đó, biết spawn subagent, xử lý song song 100 URL trong 6 phút. Bài này đi sâu vào tính năng spawn subagent của Hermes Agent - cách dispatch worker, share context vừa đủ, gom kết quả về, và cấu hình VPS để không bị OOM khi chạy 8 agent cùng lúc.

Tại sao spawn subagent là tính năng quan trọng nhất của Hermes

Đa số AI agent hiện tại đều single-threaded conversation: bạn nhập task, nó làm từng bước, output. Khi task có 100 item độc lập (cào 100 trang sản phẩm, enrich 1000 email, transcribe 50 video), agent vẫn lặp tuần tự. Nhanh thì 30s/item, chậm thì 2-3 phút. Tổng thời gian là vô địch trong khái niệm chờ.

Hermes làm khác. Trong tài liệu chính thức, mỗi subagent có conversation, terminal session, và toolset riêng - chỉ trả về summary cuối cùng để intermediate tool result không tràn vào context window của main agent. Điều này cho phép pattern producer/dispatcher/aggregator quen thuộc trong distributed systems, áp dụng cho AI agent.

Implication thực tế: với một task có 50 item, main agent spawn 5-10 subagent (số subagent là tham số bạn set), mỗi subagent xử lý 5-10 item. Wall time giảm 5-10x, token cost gần như giữ nguyên (vì mỗi item vẫn cần xử lý), nhưng context của main agent gọn gàng vì nó chỉ thấy summary.

API cơ bản: spawn_subagent

Trong Hermes CLI bạn không gọi API trực tiếp - main agent tự gọi khi thấy task có thể parallel. Nhưng để hiểu cơ chế, đây là shape của tool call:

{
  "tool": "spawn_subagent",
  "args": {
    "task": "Scrape product info from this URL: https://...",
    "context": "Site là Aliexpress. Cần lấy: title, price, rating, image.
                Trả về JSON.",
    "tools": ["browser", "web_search"],
    "return_format": "json"
  }
}

Main agent gọi tool này N lần (thường parallel qua tool batching), Hermes runtime tạo N subagent process, mỗi cái có:

• Riêng một LLM session (counter token, tool history độc lập)
• Riêng một terminal session (tách biệt cwd, env vars)
• Riêng subset tool (chỉ những tool main agent cấp - principle of least privilege)
• Timeout config riêng (mặc định 5 phút/subagent)

Kết quả mỗi subagent trả về dưới dạng string hoặc structured (JSON). Main agent aggregate, format final output cho user.

Pattern 1: Batch scrape 100 URL

Use case phổ biến nhất. Có file urls.txt 100 dòng, cần lấy title + giá của mỗi sản phẩm.

Prompt cho Hermes:

Tôi có file ~/urls.txt với 100 URL sản phẩm Tiki. Spawn 10 subagent,
mỗi cái xử lý 10 URL. Mỗi subagent dùng tool browser, mở URL, lấy
title (selector h1) và price (selector .product-price__current-price).
Trả về JSON. Sau khi tất cả xong, ghi kết quả vào ~/products.json.

Hermes làm gì bên trong:

1. Main agent đọc file urls.txt, chia thành 10 chunk × 10 URL
2. Spawn 10 subagent với tools=["browser", "filesystem"]
3. Mỗi subagent loop qua 10 URL của mình, gọi browser, parse, append vào array local
4. Subagent trả về JSON array 10 product
5. Main agent concat 10 array, ghi products.json

Wall time: ~3-5 phút (depend mạng + tốc độ site). So với tuần tự ~30-50 phút. Token cost xấp xỉ vì mỗi URL vẫn cần parse, chỉ là dồn nén thời gian.

Pattern 2: Producer-Worker với queue

Khi task không chia đều được trước (vì không biết URL nào nặng URL nào nhẹ), pattern này tốt hơn. Main agent đóng vai producer, subagent là worker pool, dùng file làm queue.

Cấu trúc thư mục:
~/jobs/
├── pending/   # URL chưa xử lý
├── working/   # URL đang xử lý
└── done/      # URL đã xong, kèm JSON result

Prompt:

Spawn 8 worker subagent. Mỗi worker loop:
  1. Atomic move 1 file từ ~/jobs/pending/ sang ~/jobs/working/
  2. Nếu pending rỗng, exit
  3. Đọc URL trong file, gọi browser scrape
  4. Ghi result vào ~/jobs/done/[same-name].json
  5. Xóa file working
  6. Quay lại bước 1
Main agent đợi tất cả worker exit, gộp ~/jobs/done/*.json thành
~/results.json và báo cáo số lượng thành công/thất bại.

Pattern này chịu được lỗi: nếu một worker chết giữa chừng, file vẫn ở working/, một worker rảnh khác có thể move ngược về pending/ retry. Khi mạng chập chờn hoặc proxy đôi lúc fail, pattern này cứu bạn.

Pattern 3: Map-Reduce data enrichment

Cho danh sách 500 email khách hàng, cần tìm: domain có MX hợp lệ không, công ty làm gì, role có thể là gì. Đây là enrichment workflow phổ biến trong sale ops.

Map phase: Spawn 20 subagent, mỗi cái xử lý 25 email. Mỗi subagent dùng tool shell để chạy dig MX, dùng web_search để Google domain, dùng browser để vào About page nếu có.

Reduce phase: Main agent gộp 20 result, dedupe theo domain (vì nhiều email có thể chung domain), output CSV cuối.

Lý do dùng pattern này thay vì single agent: mỗi DNS lookup mất 1-3s, browse mất 5-10s. 500 email tuần tự = 1-2 giờ. Spawn 20 subagent = 5-10 phút.

Resource impact: RAM, CPU, network

Subagent không miễn phí. Mỗi cái là một process Python + một LLM session active + tool dependencies. Đo thực tế trên VPS 160:

Khi subagent dùng browser, RAM cộng thêm Chromium instance - mỗi tab Chromium headless ~150-250MB. Spawn 8 subagent, mỗi cái mở 1 browser, là +1.5GB nữa. Đây là lý do VPS 6GB chạy chật vật khi browser parallel cao.

CPU: hầu hết thời gian agent là IO-bound (đợi LLM response, đợi network), không phải CPU-bound. Tuy nhiên parsing HTML, JSON, vision-decode screenshot ăn CPU thật. 8 vCPU của VPS 160 đủ.

Network: nếu mỗi subagent đi qua proxy riêng (để parallel scrape mà không bị site rate-limit theo IP), bạn cần ≥ số proxy = số subagent. Mua proxy IPv4 fresh VN/US 95k/IP/tháng tại TND - dedicated, không share.

Config Hermes cho parallel cao

Edit ~/.hermes/config.yaml:

subagent:
  max_concurrent: 8
  default_timeout: 300
  shared_skill_memory: false
  isolated_workdir: true

llm:
  provider: anthropic
  model: claude-sonnet-4.6
  rate_limit:
    requests_per_minute: 60
    tokens_per_minute: 500000

resources:
  per_subagent:
    memory_limit_mb: 800
    cpu_quota: 1.0

Quan trọng nhất: shared_skill_memory: false. Mặc định subagent đọc được skill memory của main agent (read-only). Nhưng nếu nhiều subagent cùng cập nhật skill (vì task tương tự), có thể race condition. Tắt đi cho parallel batch, bật lại cho task khám phá.

Use case business thực sự

1. Cào bảng giá đối thủ daily

Một shop fashion VN có 200 SKU, mỗi SKU theo dõi 5 đối thủ (Shopee, Lazada, Tiki, brand site, brand FB). Mỗi đêm Hermes spawn 10 subagent, mỗi cái xử lý 100 URL, lưu vào DB. Cron job đặt 2h sáng, xong trước 2h30. Sáng marketing team có file Excel competitive pricing.

2. Bulk content QA

Team có 500 bài blog, cần check link chết, missing alt tag, duplicate title. Single linter tool có sẵn, nhưng Hermes spawn 10 subagent đọc song song, mỗi subagent ngoài lint còn dùng LLM judge chất lượng. Output: bảng xếp hạng bài cần update.

3. Reach-out automation

Có CSV 1000 prospect. Spawn 20 subagent: enrich data (LinkedIn, công ty website), generate personalized first line, ghi vào sheet. Sau đó marketer review tay rồi send.

Khi nào không spawn subagent

Mình từng bị cám dỗ spawn cho mọi task. Sai. Spawn không hợp với:

• Task có dependency tuần tự: bước 2 cần output bước 1. Spawn vô nghĩa.
• Task ngắn (< 30s): overhead khởi tạo subagent ~3-5s, không bù được.
• Task cần shared state phức tạp: subagent dùng IPC kiểu file/DB - phức tạp hơn single agent.
• Khi cost LLM là constraint, không phải thời gian: parallel không giảm token, chỉ giảm wall time.

Rule of thumb: nếu task tuần tự chạy > 5 phút và item độc lập, spawn. Còn lại, single agent.

Debug subagent failure

Khi 1 trong 10 subagent fail, làm sao biết? Hermes log mỗi subagent ra file riêng ~/.hermes/logs/subagent-[uuid].log. Main agent biết subagent nào failed và trả lại error trong summary. Mình hay làm thế này:

tail -f ~/.hermes/logs/subagent-*.log | grep -i "error\|exception"

Khi spawn 16+ subagent, có 1-2 cái fail là chuyện thường (network, LLM rate limit). Pattern queue ở trên auto-retry. Quan trọng là log đủ để post-mortem.

Hạ tầng để chạy con số lớn

Mình đã thử trên các tầng VPS khác nhau:

• VPS 80 (6GB): spawn tối đa 8 subagent thực dụng. Hợp cho freelancer chạy daily batch < 200 item.
• VPS 160 (8GB): spawn 16 subagent ổn. Hợp cho team nhỏ, batch 500-1000 item/lần.
• VPS 320 (12GB): spawn 32 subagent. Khi cần xử lý 5000+ item/lần hoặc multi-tenant.

Ceph SSD NVMe của TND Cloud cho I/O tốt khi nhiều subagent ghi log/checkpoint song song. RAM ECC giúp process dài ngày không glitch. Nếu bạn từng chạy parallel agent trên VPS giá rẻ và bị OOM kill ngẫu nhiên, biết cảm giác.

Background đầy đủ về Hermes có ở bài cài Hermes gắn proxy. Còn nếu chưa biết nên thuê VPS nào, đọc pillar VPS cho vibe coder.