Les bibliothèques Python tierces dans les workflows Coze ne peuvent pas être importées, et le problème ressemble à « je ne l’ai pas emballé », mais ce n’est souvent pas si simple. Dans le numéro public, il a été mentionné que même si des « requêtes » étaient installées dans le conteneur « code_server », l’importation en temps réel échouait. Le piège le plus simple ici est que l’environnement dans lequel vous installez la bibliothèque n’est pas le même que celui dans lequel le flux de travail est réellement exécuté.
Le dépôt officiel open source de Coze Studio est toujours https://github.com/coze-dev/coze-studio. L’idée générale du README officiel est qu’il traite les workflows, plugins, bases de connaissances et exécution du code comme un lien complet, plutôt que comme un « environnement Python natif » séparé.
Pourquoi « je l’ai déjà installé » ne fonctionne toujours pas
Comme les nœuds de workflow fonctionnent généralement dans un environnement isolé, ils ne réutilisent pas forcément directement la couche que vous mettez manuellement dans le conteneur et la compactez. Ce n’est pas parce que vous l’installez dans le shell que le nœud d’exécution, la couche image ou l’image d’exécution ont aussi ce package. Surtout dans les scénarios de déploiement sur site, les conteneurs, les images et les services d’exécution de code sont séparés, et l’illusion de « je l’ai clairement installé, mais le système dit toujours non » est la plus susceptible de se produire.
Idées de traitement courantes dans la communauté
- D’abord, vérifiez si cela peut être résolu avec la bibliothèque intégrée, et ne comptez pas sur des paquets tiers.
- Si vous devez utiliser une bibliothèque tierce, confirmez dans quelle image d’exécution elle est installée, et non dans le shell actuel.
- Essayez de mettre une logique complexe dans des services externes et laissez Coze coordonner les interfaces au lieu de condenser toute la logique dans des nœuds Python.
Une façon très pratique de juger
Si le même morceau de code peut s’exécuter nativement ou manuellement dans le conteneur, mais pas dans le nœud de workflow, le problème ne vient pas de Python lui-même, mais du contexte d’exécution. À ce stade, vérifier l’exécution du workflow, la couche image et la liste blanche des dépendances est généralement plus efficace que de faire une « installation de pips » répétée.
Les retours sur ces problèmes en public sont très cohérents : ne vous concentrez pas uniquement sur l’action d’installation, mais vérifiez dans quel environnement le code s’exécute. Si vous comprenez l’environnement d’exécution, de nombreux « échecs du guide de paquets » deviendront en réalité directement des « mauvais emplacements d’installation ».
Conclusion d’une phrase
Le package Python dans le workflow Coze ne fonctionne pas, généralement non pas parce que vous ne l’avez pas installé, mais parce que vous avez installé le mauvais environnement. Confirmez d’abord le conteneur d’exécution, puis parlez de l’installation des dépendances, qui sera bien plus efficace.
