Worker

Orchestrator（编排者）负责任务分解、调度和整合，Worker（工作者）负责执行具体、专门的任务

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

Missions要求Worker完成功能后填写结构化交接，记录完成了什么、遗留了什么、执行命令及退出码、发现的问题、是否遵守程序。

Worker 可以横向扩展，方式包括多台虚拟机、Kubernetes Job 或云实例池。

新版本的暂停机制本质上是在 Worker 关闭的钩子里显式改写 in-flight 执行的状态，让它们在数据层面留下可识别的痕迹。

Worker 是 n8n 在队列模式（Queue Mode）下的执行载体，主进程负责接收 Webhook、定时触发与队列管理，Worker 进程从队列中拉取任务并执行具体工作流节点。

in-flight（进行中）执行指的是已经由 Worker 领取、正在节点之间流转、尚未产生最终结果的执行实例。

传统行为下 Worker 崩溃或优雅关闭时，in-flight 执行会悬空，表现为状态长期停留在 running、日志缺尾、下游节点永不触发。

本文选择 HPA 而非 VPA，是因为单个 Worker 的内存上限决定了它只能容纳固定数量的 Actor，扩大单 Worker 内存无法解决调度瓶颈，增加 Worker 数量才是正确的扩展方向。

Agent Substrate 将 Agent 的运行环境抽象为 Actor，Actor 运行在 Worker 之上，Worker 由 WorkerPool 统一管理。

每个 Worker 的内存上限为 1Gi，而每个 Actor 模板要求 768Mi，因此一个 Worker 只能容纳一个 Actor。

在 Agent Substrate 中，当两个 Worker 各被一个 Actor 占满（768Mi/1Gi）后，再请求第三个 Actor 会收到 504 超时，因为无足够空闲内存调度。

Chief 与 Worker 的组合属于典型的 Supervisor-Worker 多 Agent 架构模式，其优势在于职责清晰、冲突可控，但代价是对 Chief 的拆解能力和任务边界判断要求很高。

文档摘要、代码生成等重负载任务适合卸载到后台任务队列，由 Worker 取任务、调用 LLM API、写回结果，从而解耦用户请求与长时间推理。

在vLLM中真正执行物理显存分配的是GPUModelRunner，Worker更多扮演资源编排者角色

真正的物理显存分配发生在vLLM的Worker侧，而逻辑层面的block pool与block table由调度侧建立

Worker持有的ModelRunner负责执行Tensor的物理分配、完成类型转换、并将最终的Tensor视图绑定到Attention层上

vLLM采用调度-执行分离架构，调度侧负责请求管理、序列调度和逻辑资源分配，执行侧负责实际的模型推理和物理显存管理

vLLM的Worker初始化过程包括生成KVCacheConfig列表、按rank选择配置、设置block数量、执行显存分配四个阶段