Skyvern项目中媒体URL处理问题的技术分析与解决方案

问题背景

在Skyvern项目的实际部署过程中，开发人员发现系统在处理媒体资源URL时存在两个主要问题：

1. 服务端尝试通过localhost:9090访问媒体资源（如页面快照等）
2. 视频资源默认使用file://协议访问

这些问题在非本地环境部署时尤为明显，导致媒体资源无法正常加载。

问题分析

本地URL问题

系统默认配置倾向于使用本地环境URL（如localhost:9090），这在分布式部署环境下显然不适用。通过环境变量VITE_ARTIFACT_API_BASE_URL可以指定远程主机地址，但需要注意：

• 该变量对尾部斜杠敏感
• 需要同时设置VITE_API_BASE_URL才能完全解决问题

文件协议问题

视频资源默认使用file://协议访问，这在Web环境中存在安全限制，浏览器通常会阻止此类请求。更严重的是，当服务运行在容器环境中时，文件路径映射关系复杂，file://协议几乎无法正常工作。

解决方案

配置优化

对于URL问题，推荐在docker-compose配置中明确设置以下环境变量：

VITE_API_BASE_URL=http://remotehost:9090/api/v1
VITE_ARTIFACT_API_BASE_URL=http://remotehost:9090
VITE_WSS_BASE_URL=ws://remotehost:9090/api/v1

注意保持URL格式一致性，避免尾部斜杠问题。

视频资源处理方案

系统提供了多种存储后端选择：

1. 本地文件系统：默认方式，但存在上述问题
2. S3存储：通过配置AWS相关参数和设置storage_type为S3可实现

对于必须使用本地文件系统的情况，前端代码需要进行URL转换：

if (recordingURL?.startsWith("file://")) {
  recordingURL = `${artifactApiBaseUrl}/artifact/recording?path=${recordingURL.slice(7)}`;
}

架构改进建议

从长远来看，建议进行以下架构优化：

1. 统一资源访问协议，避免混合使用file://和http://
2. 抽象资源访问层，使前端不直接处理URL转换
3. 完善文档，明确各种部署场景下的配置要求
4. 增加配置验证，避免因格式问题导致的隐性错误

实践建议

对于生产环境部署，强烈建议：

1. 使用S3或其他对象存储服务作为存储后端
2. 在CI/CD流程中加入配置验证步骤
3. 对前端资源访问进行统一封装
4. 考虑实现资源访问的fallback机制，提高系统健壮性

通过以上改进，可以显著提升Skyvern项目在不同环境下的部署体验和运行稳定性。