Worker

The Orchestrator is responsible for task decomposition, scheduling, and integration, while the Worker is responsible for executing specific, specialized tasks.

该框架的主控程序（Worker）通过轮询状态文件来决定启动哪个Agent，每个Agent启动时都有强制的前置检查

Missions requires the Worker to fill in a structured handoff after completing a feature, recording what was done, what was left over, the commands executed and their exit codes, problems found, and whether procedures were followed.

Workers can scale horizontally through multiple virtual machines, Kubernetes Jobs or cloud instance pools.

The new version's pause mechanism is essentially an explicit rewrite of the state of in-flight executions in the Worker shutdown hook, leaving identifiable traces at the data level.

Workers are the execution carriers in n8n's Queue Mode: the main process handles receiving Webhooks, scheduled triggers and queue management, while Worker processes pull tasks from the queue and execute the specific workflow nodes.

An in-flight execution refers to an execution instance that has already been claimed by a Worker, is currently moving between nodes, and has not yet produced a final result.

Under the traditional behavior, when a Worker crashes or shuts down gracefully, in-flight executions are left dangling, showing up as states stuck in running for a long time, truncated logs, and downstream nodes that never trigger.

This article chose HPA rather than VPA because the memory limit of a single Worker determines that it can only hold a fixed number of Actors; enlarging a single Worker's memory cannot solve the scheduling bottleneck, and increasing the number of Workers is the correct scaling direction.

Agent Substrate abstracts the Agent's runtime environment as an Actor; the Actor runs on top of a Worker, and the Worker is managed uniformly by a WorkerPool.

Each Worker has a memory limit of 1Gi, while each Actor template requires 768Mi, so one Worker can only hold one Actor.

In Agent Substrate, after two Workers are each filled by one Actor (768Mi/1Gi), requesting a third Actor returns a 504 timeout, because there is not enough free memory to schedule it.

The Chief-and-Worker combination is a typical Supervisor-Worker multi-agent architecture pattern; its advantage lies in clear responsibilities and controllable conflicts, but the cost is that it places very high demands on the Chief's decomposition ability and judgment of task boundaries.

Heavy tasks such as document summarisation and code generation are suited to being offloaded to a background task queue, where a worker picks up the task, calls the LLM API, and writes back the result, thereby decoupling user requests from long inference.

In vLLM, it is GPUModelRunner that actually performs physical GPU memory allocation, while Worker plays more of a resource orchestration role.

The actual physical VRAM allocation occurs on vLLM's Worker side, while the logical block pool and block table are established on the scheduler side.

The ModelRunner held by the Worker is responsible for performing the physical allocation of tensors, completing type conversions, and binding the final tensor views to the Attention layers.

vLLM adopts a scheduling-execution separation architecture, where the scheduling side is responsible for request management, sequence scheduling, and logical resource allocation, while the execution side is responsible for actual model inference and physical VRAM management.

vLLM's Worker initialization process consists of four stages: generating the KVCacheConfig list, selecting a configuration by rank, setting the block count, and performing VRAM allocation.