runners是什么：和Job、Agent逐项分清
runners是什么？在 CI/CD 语境里，它不是跑步爱好者，也不是某条流水线本身，而是领取并执行自动化任务的程序及其运行环境。很多配置错误都源于概念混用，下面把 Runner 与 workflow、job、executor、agent 逐项对比，顺手回答安装和计费疑问。
对比一：Runner 与 workflow
workflow 是自动化流程的定义，通常写在仓库的 YAML 文件里，描述何时触发、包含哪些任务。Runner 则是执行者：它从平台领取任务，在机器上检出代码、调用命令，再把日志和状态传回去。
可以把 workflow 理解为菜谱，Runner 是照菜谱工作的厨房。只写了流程却没有可用 Runner，任务会停在 queued 或 pending；Runner 在线但没有符合条件的任务，也只会等待。
对比二：Runner 与 job
job 是一次具体工作单元，例如运行测试、构建镜像或部署。一个 workflow 可以包含多个 job，它们可以串行，也可以在依赖允许时并行。Runner 通常在某一时刻承接一个或有限数量的 job，具体并发取决于平台与配置。
所以增加 job 不等于增加机器。你把测试拆成十份，却只有一个可用执行槽位，它们仍会排队。要缩短总时长，需要同时检查任务拆分方式、Runner 数量和单机资源。
对比三：Runner 与 executor、agent
在 GitLab 体系中，Runner 负责接单，executor 决定任务具体在哪里运行，例如 shell、Docker 或 Kubernetes。shell 直接使用主机环境，速度直观但隔离较弱；Docker 借助镜像统一环境；Kubernetes 则通常为任务创建 Pod。
agent 是其他自动化平台常见的叫法，与 Runner 的职责大体相近，但注册方式、工作目录和权限模型并不通用。看到教程写 build agent，别直接照搬命令，先确认它对应的是哪个平台。
对比四：托管与自托管到底差在哪
托管 Runner 由平台提供运行环境，你主要维护工作流；自托管 Runner 使用自己的主机，你能控制硬件、网络和工具，也必须负责安全更新、容量和清理。前者省运维，后者换来更强控制力。
回答 runners是什么，最实用的版本就是：它是流水线代码真正落地执行的位置。排查问题时先看 job 被分到哪台机器、使用什么账户、能访问哪些资源，往往比反复修改 YAML 更快找到根因。
常见问题
Runners 是软件还是服务器？
严格说 Runner 是接收和执行任务的软件，但日常交流中也常用它指安装该软件的服务器、虚拟机、容器或临时执行环境，需要结合上下文判断。
Runner 必须安装在代码服务器上吗？
不必，也通常不建议混装。Runner 只要能连接代码平台和任务需要的资源即可，独立部署更方便做权限隔离、扩容和故障处理。
使用 Runner 一定收费吗？
不一定。平台托管 Runner 是否收费、赠送多少额度取决于平台、套餐、仓库类型和操作系统；自托管仍需承担主机、网络及维护成本。应以当前官方计费页为准。
一个项目可以同时使用多种 Runner 吗？
可以。常见做法是 Linux 节点跑测试、Windows 节点编译桌面程序、GPU 节点执行模型任务，再通过标签让不同 job 匹配对应环境。