TL;DR

Spawn một subagent không phải là swarm management. Đó mới chỉ là điểm khởi đầu của vấn đề. Câu hỏi thực sự là những gì xảy ra sau khi child tồn tại: nó sống ở đâu, ai sở hữu nó, có thể address nó không, có thể điều hướng nó không, và điều gì còn lại khi process restart? Một harness cho phép một agent gọi tool. Một delegation tool cho phép một agent mượn worker. Một swarm manager sở hữu cả một fleet.

Ranh Giới Kiến Trúc

Hermes (NousResearch) có một delegation primitive thực sự tốt. delegate_task của nó spawn các child AIAgent instance với context riêng biệt, mặc định tối đa 3 instance chạy đồng thời, mỗi instance có timeout 600 giây trước khi bị kill vì bị stuck. Chúng stream tiến độ và trả về structured summary về parent. Gọn gàng. Hữu ích.

Nhưng child sống bên trong parent tool call. delegate_task là synchronous. Nếu user gửi tin nhắn mới trong khi parent đang chờ, tất cả các child đang active sẽ bị cancel và công việc của chúng bị loại bỏ. Không có registry, không có recovery, không có address để hệ thống có thể kiểm tra một child một cách độc lập.

OpenClaw dùng cách tiếp cận khác. Khi parent spawn một child, child trở thành một gateway session với durable session key (agent:<targetAgentId>:subagent:<uuid>), một run ID, lifecycle records, parent-child lineage, và một push-based completion path trở lại requester. Child có thể được liệt kê, patch, xóa, hoặc link về parent — hiển thị với toàn bộ gateway cùng với chat session và cron session.

Đó là ranh giới kiến trúc. Delegation hỏi: làm thế nào một agent chia nhỏ công việc? Swarm management hỏi: làm thế nào một runtime sở hữu nhiều agent theo thời gian?

Identity và Completion

Yêu cầu đầu tiên của swarm management là khả năng addressability. Một swarm manager cần track: child session key, run ID, requester, spawn depth, role, cleanup policy, timestamp, và outcome. Nếu những câu trả lời đó chỉ tồn tại bên trong context window của model, hệ thống không thể quản lý một fleet.

Registry của OpenClaw — một in-memory Map được persist vào ~/.OpenClaw/subagents/runs.json — sống sót qua các lần process restart. Khi khởi động, nó resume các pending announcement cho completed run và re-issue agent.wait cho các run đang in-flight. Namespace key phân cách bằng dấu hai chấm mã hóa routing context trực tiếp vào chính key — không cần bảng routing riêng.

Trong một swarm thực sự, completion không phải là một return value. Đó là một bài toán routing. Parent có thể đang active, idle, đã restart, hoặc đã biến mất khi child hoàn thành. OpenClaw xử lý điều này với push-based model: sessions_spawn trả về acceptance và bookkeeping, không phải kết quả. Kết quả đến sau dưới dạng sự kiện task_completion được route về requester session — với delivery policy có thể queue, retry, điều hướng active session, hoặc fallback về direct send. Hầu hết các delegation system bỏ qua hoàn toàn phần này.

pasted image

Queue, Role, và Cascade

Khi agent spawn agent, concurrency trở thành trách nhiệm của runtime. User gửi follow-up trong khi agent đang mid-run. Child hoàn thành trong khi parent đang bận. Steer message đến trong khi model đang streaming. Nếu tất cả những thứ này chỉ là message, hệ thống sẽ vỡ rất nhanh. Queue policy — không phải prompting tốt hơn — mới là câu trả lời. Kiến trúc lane của OpenClaw tách công việc main, subagent, và background thành các lane riêng biệt, mỗi lane có concurrency limit riêng. SwarmClaw (multi-gateway layer được xây trên OpenClaw) giới hạn parallel fan-out ở 4 nhánh mặc định, hard cap 16, với join policy: quorum hủy các nhánh còn lại khi N nhánh thành công, first resolve khi nhánh đầu tiên thành công.

Flat swarm không scale an toàn. Hermes enforce role qua max_spawn_depth (mặc định 1, tối đa 3) và một global kill switch cho orchestrator behavior. OpenClaw mạnh hơn: sub-agent không thể spawn sub-agent, hoàn toàn dừng — một hard constraint được enforce bởi runtime, không chỉ được gợi ý trong prompt. Model có thể request một spawn. Runtime quyết định nó có hợp lệ không.

Khi một child đang làm sai, kill nó và mất session thường là lựa chọn sai. Steering mạnh hơn: trong OpenClaw, steer-restart đánh dấu run, suppress các stale announcement, abort in-flight run, xóa queue, và remap registry sang run mới. Kill cascade xuống toàn bộ cây. Đây là các control-plane operation. Bạn không thể yêu cầu một model tự tay track và dọn dẹp mọi descendant đang live. Runtime phải sở hữu cái graph đó.

Recovery và Cleanup

Swarm manager không thể fire-and-forget. Nó cần biết khi nào child bị stuck, bị orphan, đã hoàn thành, hoặc hoàn thành nhưng chưa được deliver. Registry của OpenClaw dùng hai cơ chế song song: in-process lifecycle event listener và cross-process agent.wait RPC. Sweeper — không hào nhoáng nhưng thiết yếu — kiểm tra các run không có live context, reconcile với session state, expire các stale record, retry các stuck state, và đánh dấu delivery failed thay vì để cleanup dở dang mãi mãi.

Đây là công việc OS-level. Một process table. Một reaper. Mọi swarm manager cuối cùng đều trở thành một cleanup system vì subagent tạo ra external state — transcript, browser session, MCP runtime, workspace file, cost metadata — tồn tại lâu hơn sự chú ý của model. Trong bounded delegation, cleanup là local (thread thoát, parent nhận JSON). Trong swarm management, cleanup là distributed và stateful. File-level locking của OpenClaw dùng atomic creation với 30-giây stale-lock eviction và 25ms polling, được backup bởi in-memory cache với 45-giây TTL. Không database, không ORM — JSON/JSONL thuần có thể cat và jq.

Layer Phía Trên Harness

OpenClaw mang tính chỉ dẫn chính xác vì nó không có một class SwarmManager thần kỳ nào. Swarm hình thành từ các runtime machinery bình thường: session key, lane, run ID, registry record, lifecycle event, queue policy, delivery routing, cleanup decision, recovery sweep. Những control-plane primitive nhàm chán giúp nhiều agent có thể tồn tại.

Hermes cho thấy delegation tốt trông như thế nào. OpenClaw cho thấy điều gì xảy ra khi delegation trở thành session infrastructure. Câu hỏi năm 2026 không phải là liệu agent có thể gọi tool hay không — đó là câu hỏi harness, đã được trả lời. Câu hỏi là: agent sống ở đâu, ai sở hữu chúng, chúng báo cáo lại như thế nào, chúng được dừng thế nào, và điều gì còn sót lại sau khi restart? Đó là layer biến một single agent harness thành một fleet. Và đó là bài toán hệ thống thực sự tiếp theo trong AI.

Via: SwarmClaw GitHub, Hermes Agent Docs, OpenClaw Sessions Deep Dive, Conductor vs Swarm (Agix).