JetBrains 为 TeamCity 平台推出了 Warm Agents 插件，用于解决持续集成和持续交付环境中最常见的延迟问题之一：在测试或构建过程开始前等待云构建代理启动。该插件允许针对每个云镜像维持目标数量的闲置且已启动的代理，使 TeamCity 在代理数量低于指定水平时立即开始提供新的代理。
该插件适用于 TeamCity 支持的任何云服务提供商，因此适合使用临时代理、而不是让完整构建基础设施持续运行的团队。这一功能尤其面向短时任务，因为此类任务的环境准备时间可能长于实际执行时间；例如，启动缓慢的云端 Windows 代理可能会让一个只需一分钟的测试在队列中额外等待数分钟。
实际会发生什么变化？
TeamCity 不再只在任务到达时创建代理，而是监控每个云镜像的闲置代理数量，并在数量低于目标时启动新的实例。可以通过 REST API，或通过路径 Project Settings | Integrations | Warm Agents 中的项目设置来配置数量。将目标设置为零，即可停止为特定镜像保留就绪代理。
该插件要求使用 TeamCity 2024.12.3 或更高版本，并要求项目中已配置云配置文件和云镜像，同时需要 Manage project’s agent cloud profiles 权限。通过 JetBrains Marketplace 安装并启用后，可以使用 REST API 或 teamcity-cli 工具进行管理。
速度的成本与扩展限制
Warm Agents 并不会免费带来加速。每个处于就绪状态并正在运行的代理都会消耗一个构建代理许可证，闲置的云实例也会继续为云服务提供商产生费用。因此，该插件在等待时间和运营支出之间进行了明确取舍；如果实际需求较低，提高目标数量并不总能带来实际改善。
TeamCity 会遵守云镜像设定的运行实例最大数量，即使代理目标被设置为更高的数值也是如此。此外，实例会分批启动，并在批次之间设置短暂间隔，因此达到较高目标可能需要一些时间。降低目标时，TeamCity 不会强制停止正在运行的代理；云镜像定义的闲置超时仍然有效，并且为了维持目标数量，部分已停止的实例可能会被重新启动。
调度与度量
JetBrains 建议使用计划任务根据需求模式调整目标数量，例如在早晨提高目标、在晚上将其降至零。可以通过 Kotlin DSL 和 REST API 调用来执行此操作，同时将 OAuth 令牌作为密码类型参数存储，以免其出现在构建日志中。
该插件还会针对每个云镜像提供 Prometheus 格式的指标，包括使用率和饱和度指标，帮助团队了解需求高峰期，以及就绪代理数量是否能够应对队列。在多节点环境中，必须通过专用的 Cookie 配置文件将指标请求定向到主节点。
为什么这一消息很重要？
该插件提供了一种直接机制，可以将代理准备时间从不可预测的延迟转变为可配置、可监控的资源。对于拥有短时、重复任务或可预测需求高峰的团队而言，它的实际价值更大；而对于运行较为间歇的项目，保留预热代理的成本可能并不值得。因此，采用该插件需要比较闲置成本与实际等待时间，并利用指标调整目标，而不是选择一个固定的高数值。