Cloud Agents est une plate-forme d'exécution d'agent AI entièrement gérée lancée par Qoder. Les développeurs n'ont qu'à écrire le code logique de l'agent, et la plateforme gère automatiquement le déploiement, l'expansion et la contraction, la surveillance et la journalisation. Prend en charge l’intégration de la chaîne d’outils MCP et le déclenchement de Webhook de commutation multimodèle. Architecture sans serveur, payez en fonction des appels réels.

CloudAgents

Paramètres de base et statistiques des agents cloud

Cloud Agents se positionne entre la plateforme PaaS et le framework AI Agent - il ne fournit pas de capacités de création d'agents (vous devez écrire votre propre code logique), et il ne s'agit pas non plus simplement d'une passerelle API, mais d'un contexte d'exécution d'exécution complet. Les paramètres suivants sont basés sur la page publique officielle.

Paramètres	Informations officielles vérifiables
Positionnement du produit	Plateforme d'exécution d'agent AI entièrement gérée (Managed Agent Runtime)
Forme architecturale	Sans serveur
Protocole d'intégration d'outils	MCP (Protocole de Contexte de Modèle)
Grands modèles pris en charge	OpenAI (série GPT), Anthropic (série Claude), DeepSeek, etc., prennent en charge les points de terminaison de modèles personnalisés
Méthode de déclenchement de l'agent	API REST, Webhook, tâches planifiées (Cron)
Granularité de facturation	Facturation basée sur le volume d'appels (nombre d'appels + temps d'exécution)
Développeur	Qoder (Singularité)
Localisation de l'équipe	Chine
Temps en ligne	2026-05 (version publique v1)
Quotas gratuits	Fourni (quota spécifique)
Déploiement privé	Soutien non divulgué

Un bref commentaire : Les agents cloud sont comme Vercel pour les applications frontales : vous transmettez le code de l'agent et il est responsable de son exécution, du transport du trafic et de l'enregistrement des journaux. Vous n'avez pas à vous soucier du serveur.

Différence de positionnement avec les produits concurrents : contrairement aux plateformes telles que Coze et Dify qui fournissent des générateurs d'agents visuels, les Cloud Agents ne fournissent pas de couche d'orchestration, mais uniquement une couche d'exécution. Peu importe la manière dont la logique interne de votre agent est organisée, cela garantit uniquement que le code peut être exécuté de manière fiable et évolutive dans le cloud. Cette différence le rend plus attrayant pour les développeurs avancés qui ont besoin de personnaliser le comportement de l'agent, mais le manque de capacités d'assemblage visuel signifie également qu'il ne convient pas aux utilisateurs non techniques.

Dimensions de comparaison	Agents cloud	Coze/Dify	Agents de base AWS
Positionnement de base	Hébergement de l'environnement d'exécution de l'agent	Création d'agent + hébergement	Création d'agents + infrastructure cloud
Avez-vous besoin d'écrire du code	Oui (code de téléchargement)	Non (disposition visuelle)	Partiel (nécessite une configuration)
Intégration MCP	Prise en charge native	Écologie des plug-ins	Personnalisation Lambda
Modèle de facturation	Par volume d'appels	Freemium + abonnement	Par ressource + appel API
Déploiement privé	Inédit	Prise en charge de la version entreprise	Déploiement au sein de VPC
Seuil pour commencer	Moyen (codage requis)	Faible (glisser-déposer)	Élevé (écosystème AWS)

Reconnaissance des utilisateurs et du marché des agents Cloud

Cloud Agents a été lancé par Qoder et occupe le segment « hébergement d'exécution » dans la piste d'infrastructure AI Agent. Qoder a lancé une série d'outils autour de l'écosystème d'agents, notamment Qoder CLI, Qoder Rules et Qoderwake, dans lesquels les agents cloud assument le rôle de couche d'exécution d'exécution.

Positionnement sur le marché : le problème ciblé par les agents Cloud est « l'écart de déploiement de l'agent AI du prototype à la production ». Il est facile pour les développeurs d'exécuter l'agent localement ou dans un ordinateur portable, mais pour le transformer en un service de production en ligne 7 × 24 heures, capable de gérer le trafic et doté d'une surveillance et d'alarmes, il est nécessaire de traiter une série de problèmes d'infrastructure tels que la conteneurisation, l'expansion et la contraction automatiques, la limitation du courant de l'API et la collecte de journaux. Les agents cloud résument cette couche dans les fonctionnalités de la plateforme.

Paysage concurrentiel : les agents cloud évoluent dans un contexte de course qui s'échauffe rapidement en 2025-2026. Il existe la plate-forme d'hébergement LangGraph Cloud d'AutoGPT et les solutions d'hébergement de CrewAI à l'étranger, ainsi que des modules d'exécution pour diverses plates-formes d'agent en Chine. La principale différence des agents Cloud réside dans l'accent mis sur le « runtime pur » : ils ne regroupent pas leur propre infrastructure d'agent. Les développeurs peuvent utiliser n'importe quel framework (LangChain, CrewAI, AutoGen, framework auto-développé) pour écrire des agents, à condition que le résultat final soit du code appelable. Cet agnosticisme du framework est précieux dans les équipes qui doivent migrer ou mélanger les frameworks.

Avantages financiers des agents cloud

La structure de coûts des agents Cloud est pilotée par deux moteurs : « l'architecture sans serveur » et le « paiement par appel », qui élimine le gaspillage de ressources inutilisées et l'investissement en main d'œuvre d'exploitation et de maintenance.

Côté C/développeurs individuels : la plate-forme fournit un quota gratuit (la valeur spécifique est soumise à la page en temps réel du site officiel cloudagents.ai), qui convient à la vérification PoC des développeurs individuels et aux scénarios de faible trafic. L'architecture sans serveur signifie que les développeurs ne paient pas pour le temps d'inactivité : l'agent est facturé zéro lorsqu'il n'y a aucune demande, et chaque appel n'est facturé que pour le temps d'exécution réel et la consommation de l'API. Pour les projets personnels en phase de vérification du prototype, ce modèle de facturation est plus économique que les solutions VPS ou conteneurs à frais mensuels fixes - pour un agent léger qui est déclenché des dizaines de fois par jour, les frais mensuels peuvent être contrôlés à quelques dizaines de yuans.

Appel API/développeur : Cloud Agents ne facture pas de frais de plate-forme mensuels fixes, les développeurs ne paient que pour les dimensions suivantes :

• Nombre d'appels : nombre de requêtes exécutées par l'agent à chaque fois
• Durée d'exécution : Le temps d'exécution du code de l'Agent depuis le démarrage jusqu'au retour des résultats
• Frais API LLM : consommation de jetons générée par l'agent appelant de grands modèles tiers (à votre charge)

En outre, les coûts de bande passante sortante et de stockage de la plate-forme cloud elle-même doivent également être inclus dans le modèle de coûts à plus grande échelle.

Déploiement entreprise/privé : les tarifs au niveau de l'entreprise ne sont pas divulgués. Un déploiement à grande échelle nécessite de contacter l'entreprise pour obtenir des solutions personnalisées. Les entreprises doivent prendre en compte de manière globale les coûts cachés suivants lors de leurs évaluations : la résidence et la conformité des données (si les données sont transmises via la plateforme Cloud Agents), les niveaux de SLA (l'impact des temps d'arrêt de la plateforme sur l'entreprise) et le coût du chemin de migration des Cloud Agents vers l'auto-hébergement (si le code est profondément couplé à l'API de la plateforme).

Comparaison des coûts à trois niveaux :

Dimension du coût	Développeur Individuel	Appelant API	Niveau Entreprise
Frais fixes	0 (dans la limite gratuite)	0	Confirmation commerciale requise
Frais à la carte	Frais payables à l'utilisation après épuisement du quota gratuit	Nombre d'appels + temps d'exécution	Remises sur volume possibles
Coûts cachés	Courbe d'apprentissage	Contrôle de fréquence et latence	Conformité des données SLA, coûts de migration
Scène appropriée	Prototype / PoC	Déploiement léger de production	À grande échelle/sensible à la conformité

Principales fonctions des agents cloud

La conception fonctionnelle des agents cloud s'articule autour de l'objectif principal consistant à « faire en sorte que le code de l'agent s'exécute de manière fiable dans le cloud ». Il n'inclut pas la couche de construction de l'agent, mais fournit les fonctionnalités de support requises au moment de l'exécution.

• Exécution d'agent entièrement gérée : les développeurs téléchargent le code de l'agent (prenant en charge Python, TypeScript et d'autres langages) via CLI ou API, et la plateforme effectue automatiquement l'encapsulation de la conteneurisation, l'allocation des ressources, la mise à l'échelle élastique et l'équilibrage de charge. Lien caché : détectez automatiquement la déclaration de dépendance de l'agent (telle que Requirements.txt) au moment de l'exécution et préinstallez les dépendances dans l'environnement sandbox, éliminant ainsi le besoin pour les développeurs de créer manuellement des images. Cette expérience de « code en tant que déploiement » réduit le temps nécessaire entre le codage et la mise en ligne de quelques heures à quelques minutes.

• Intégration de la chaîne d'outils MCP : Prise en charge native du protocole MCP, permettant à l'agent d'appeler des outils externes via le serveur MCP - contrôle du navigateur, opérations du système de fichiers, appels d'API de requête de base de données, etc. Vue experte : La méthode d'intégration de MCP est la synergie la plus remarquable des agents cloud - dans le code de l'agent, il vous suffit de déclarer l'appel de l'outil selon la norme MCP, et la plateforme est automatiquement acheminée vers le serveur MCP correspondant, complétant ainsi la conversion transparente de "Appel d'outil en cours de traitement de l'agent" à "à distance Exécution du service MCP". Cela signifie que les développeurs d'agents n'ont pas besoin de se soucier du déploiement et du fonctionnement du serveur MCP, mais doivent uniquement se concentrer sur la sémantique de l'interface de l'outil.

• Routage multimodèle et repli : configurez plusieurs points de terminaison LLM dans le même agent pour prendre en charge les demandes de routage par priorité ou par poids. Rétrograder automatiquement vers un modèle alternatif lorsque le modèle préféré renvoie une erreur ou expire. Conseils de mise en œuvre : dans le cadre de la stratégie de modèle hybride, les tâches d'inférence complexes peuvent être acheminées vers DeepSeek ou Claude, et la génération de texte simple peut être acheminée vers des modèles moins chers pour optimiser les coûts des jetons tout en maintenant la qualité de sortie. La configuration du changement de modèle appartient à la couche plateforme et le code de l'agent lui-même n'a pas besoin d'être modifié.

• Surveillance et observabilité intégrées : fournit un panneau de surveillance des appels pour afficher la répartition des retards, le taux de réussite, la distribution des codes d'erreur et les tendances de consommation des jetons en temps réel. Prend en charge la récupération structurée des journaux et les règles d'alarme personnalisées (telles que la notification au Webhook lorsque le taux d'erreur dépasse le seuil). Problèmes d'acceptation : la surveillance des données de latence est cruciale pour résoudre les goulots d'étranglement des performances de l'agent : si la latence P95 de l'agent est bien supérieure à P50, cela indique généralement qu'il existe des délais d'attente de dépendance externe sporadiques dans le code et qu'une logique de contrôle de nouvelle tentative ou d'expiration doit être ajoutée.

• Webhook et événementiel : prend en charge trois modes d'appel d'agent : API HTTP (requête-réponse synchrone), Webhook (déclenchement d'événements asynchrones) et tâches planifiées Cron (exécution périodique). Exemple de scénario : un « agent de résumé quotidien de l'opinion publique » peut être configuré pour être déclenché via Cron à 9h00 chaque matin, récupérer le dernier contenu de la source spécifiée, appeler LLM pour le résumer et le transmettre à DingTalk ou Feishu via Webhook.

• Gestion des versions et version en niveaux de gris : chaque version téléchargée du code de l'agent est enregistrée sous forme d'instantané, prenant en charge la restauration et la version en niveaux de gris (acheminement du trafic vers la nouvelle version de manière proportionnelle ou conditionnelle). Conseils de mise en œuvre : La publication en niveaux de gris est une fonctionnalité nécessaire dans les scénarios de production : la nouvelle logique d'agent peut produire une sortie anormale sous des entrées spécifiques, et le mécanisme en niveaux de gris peut contrôler la plage d'impact dans une proportion acceptable.

Evolution du modèle et de la version des Agents Cloud

L'évolution de la version des agents Cloud reflète le chemin parcouru par Qoder depuis la « validation de la faisabilité de l'exécution de l'agent » jusqu'à la « création d'une plate-forme d'hébergement de niveau production ».

Prototype interne et tests internes (2025-12 à 2026-03)

• Cloud Agents alpha (~2025-12) : étape de prototype interne, l'objectif principal est de vérifier la faisabilité architecturale du runtime de l'agent sans serveur - si le démarrage conteneurisé du code de l'agent peut être effectué en quelques secondes et s'il peut gérer le trafic en rafale. Aucune information publique n’est disponible à ce stade.
• Cloud Agents bêta (~2026-03) : version bêta interne dirigée, invitant certains développeurs à l'essayer. Prend en charge le déploiement, l'exécution et l'affichage des journaux de base du code de l'agent, et est lié aux propres capacités de routage LLM de Qoder. Commentaires sur la version bêta privée axés sur l'intégration de l'outil MCP et la transparence de la facturation.

Version publique (2026-05 au présent)

• Cloud Agents v1 (~2026-05) : la première version publique et la dernière version stable. Les compétences de base comprennent :
  • Intégration native du protocole MCP, prise en charge du montage d'un serveur MCP externe -Commutation de modèles multiples et repli
  • REST API / Webhook / Cron trois méthodes de déclenchement
  • Panneau de surveillance (délai, jeton de taux de réussite)
  • Gestion des versions et release en niveaux de gris
  • Chaîne d'outils CLI (cld déployer, cld logs, cld Invoke)

Remarque sur l'évolution de la version : Le rythme des versions des agents Cloud est synchronisé avec l'écosystème Qoder. Étant donné que le produit est relativement nouveau et qu'il existe peu d'informations sur les versions historiques, les dates des versions internes ci-dessus sont des estimations des étapes du projet, et il n'y a pas encore de date officielle précise. Les versions ultérieures devraient ajouter la prise en charge des réseaux privés, une gestion plus granulaire des autorisations et une intégration avec les fournisseurs d'identité d'entreprise (IdP).

Avantages techniques des agents cloud

Détermination du type d'outil : les agents cloud appartiennent à Agent / MCP / Automation Tools - une plate-forme d'exécution d'agent AI entièrement gérée qui ne fournit pas de fonctionnalités de création d'agent et se concentre sur le déploiement, l'orchestration et l'observabilité de la couche d'exécution.

Lien architectural

Les agents cloud se trouvent dans la position « couche d'exécution » dans l'ensemble du flux de travail de l'agent, connectés au code de l'agent et connectés à l'API LLM et aux outils externes :

Développeur (CLI/API)
    │
    ▼
┌────────────────────────────────────┐
│ Runtime des agents cloud │
│ │
│ ┌─────────┐ ┌───────────────┐ │
│ │ Conteneur bac à sable │ │ Moteur de routage de modèles │ │
│ │ (Agent) │──│ (Routeur LLM) │ │
│ └────┬────┘ └───────┬───────┘ │
│ │ │ │
│ ▼ ▼ │
│ ┌─────────┐ ┌───────────────┐ │
│ │ Agent MCP │ │ Surveillance et journalisation │ │
│ └────┬────┘ └───────────────┘ │
└────────┼─────────── ────────────────────┘
        │
        ▼
┌────────────────┐ ┌──────────────────┐
│ API LLM tierce │ │ Serveur MCP │
│ (OpenAI, Claude│ │ (Navigateur/DB/Fichier) │
│ DeepSeek, etc.) │ │ │
└─────────────────┘ └───────────────────┘

Flux de contrôle : CLI/API soumet le code de l'agent → la plateforme crée un conteneur sandbox → l'agent exécute et initie une demande d'inférence au LLM → l'agent appelle l'outil MCP → les résultats sont renvoyés à la plateforme → publication de journal/surveillance.

Retour de données : les résultats de l'exécution du serveur MCP sont renvoyés vers le contexte de l'agent. L'agent décide de l'action suivante ou génère la réponse finale en fonction du nouveau contexte. La réponse est transmise à l'appelant via la plateforme.

Liste ouverte des outils

Les agents cloud eux-mêmes n'exposent pas directement les outils de contrôle du navigateur ou d'exploitation du système, mais sont implémentés via le serveur MCP. Les interfaces de fonctionnalités principales (outils) exposées par la plate-forme à l'agent incluent :

• mcp_tool_call(tool_name, args) : appelle l'outil du serveur MCP enregistré
• llm_chat(model, messages, params) : Initier une demande de conversation vers le LLM spécifié
• store_get(key) / store_set(key, value) : stockage KV au niveau de l'agent (persistance entre les appels)
• log_info(msg) / log_error(msg) : écriture de log structuré
• http_request(url, method, headers, body) : requête HTTP (pour intégration personnalisée)

L'outil ci-dessus est exposé aux développeurs via le SDK d'exécution de l'agent (bibliothèque Python/TS) et peut être appelé directement dans le code de l'agent. Les développeurs peuvent également personnaliser le serveur MCP pour étendre la liste d'outils.

Guide des pièges d'ingénierie

En fonction des caractéristiques de la plateforme d'exécution de l'agent, les problèmes d'ingénierie et les stratégies de réponse les plus courants dans les environnements de production sont les suivants :

1. Boucles infinies et consommation infinie de jetons : les agents peuvent tomber dans une boucle infinie de « penser → appeler des outils → obtenir des résultats → continuer à réfléchir » dans des tâches complexes, conduisant à un temps d'exécution incontrôlable et à une montée en flèche des coûts de jetons. Solution : définissez max_steps (tours d'appel d'outil maximum) et le délai d'expiration global (tel que timeout=120s) dans le code de l'agent. Le côté plate-forme doit également configurer le temps d'exécution maximum d'un seul appel et la limite supérieure du jeton dans la couche d'exécution. Il est recommandé que la limite supérieure des pas de l'agent soit contrôlée dans un délai de 10 à 20 tours. En cas de dépassement, le résultat intermédiaire actuel sera forcé de revenir.

2. Exceptions de l'outil MCP et pollution du contexte : lorsque le serveur MCP renvoie des données anormales (telles qu'un délai d'attente, une erreur de format, une interception de sécurité), le contenu anormal peut être inclus dans le contexte de raisonnement par l'agent, provoquant un écart du raisonnement ultérieur par rapport au chemin attendu. Solution : effectuez une encapsulation structurée de la valeur de retour de l'outil au niveau de la couche de l'agent MCP - placez les informations d'exception dans un champ séparé (tel que status : "error", error_type: "timeout") pour empêcher le contenu de l'exception d'entrer dans la chaîne de raisonnement de l'agent sous la forme de données normales. Le code de l'agent doit vérifier la validité du résultat après chaque appel d'outil, plutôt que de supposer que l'appel doit réussir.

3. Différence de facturation des jetons pour la commutation multimodèle : une fois le repli multimodèle configuré dans l'agent, la différence entre les prix des jetons d'entrée et de sortie des différents modèles peut varier de plus de 10 fois. Si le lien de secours n'est pas conçu correctement (par exemple, les demandes à haute fréquence sont continuellement acheminées vers des modèles coûteux), les frais mensuels peuvent dépasser les attentes. Solution : définissez des règles de priorité + conditionnelles dans la stratégie de routage du modèle (telles que « les modèles à bas prix sont préférés pour les questions et réponses simples, et revenez aux modèles à prix élevé pour un raisonnement complexe ») et suivez la répartition de la consommation de jetons par dimensions du modèle dans le panneau de surveillance pour découvrir en temps opportun les modèles de routage anormaux.

Démarrez rapidement en 3 minutes

Voici un processus de déploiement typique de l'agent Cloud Agents (en prenant Python comme exemple) :

Étape 1 : Installer la CLI

npm install -g @qoder/cloud-agents-cli
# Ou utilisez la version Python
pip install cloud-agents-cli

Étape 2 : Écrire le code de l'agent

#agent.py
à partir de cloud_agents import Agent, outil

classe MonAgent(Agent) :
    def run(self, input_text : str) -> str :
        # Appeler LLM
        réponse = self.llm.chat(
            model="deepseek-chat",
            messages=[{"role": "user", "content": input_text}],
            température=0,7
        )
        # Appeler l'outil MCP
        météo = self.mcp.call("meteo-serveur", {
            "ville": "Pékin"
        })
        return f"{response} | Météo : {météo}"

Étape 3 : Déployer

cld login # Connexion (nécessite l'enregistrement d'un compte cloudagents.ai)
cld déployer agent.py --name mon-agent
cld invoque my-agent --input "Est-ce le bon moment pour sortir à Pékin aujourd'hui ?"

Étape 4 : Afficher les journaux

cld enregistre mon-agent --tail

Configuration pour monter le serveur MCP (déclarée dans cloudagents.yaml) :

agents :
  mon-agent :
    source : ./agent.py
    exécution : python3.11
    mcp_servers :
      - nom : serveur météo
        transport : stdio
        commande : npx @qoder/mcp-weather
      - nom : navigateur-serveur
        transport:sse
        URL : https://browser-mcp.example.com/sse
    modèles:
      primaire : discussion en profondeur
      solution de repli : claude-3-5-sonnet
    délai d'attente : 60
    max_steps : 15

La configuration et le code ci-dessus sont dérivés de la documentation publique des agents Cloud et du comportement de la CLI. Pour les commandes et paramètres spécifiques, veuillez vous référer à la documentation officielle de cloudagents.ai.

Comment utiliser les agents cloud

Cloud Agents propose trois façons d'interagir avec la plateforme : CLI, console de gestion Web et API REST, couvrant différents besoins, du développement personnel à l'intégration automatisée.

Comment utiliser	Scénarios applicables	Capacités de base
CLI (ligne de commande cld)	Les développeurs gèrent l'agent localement	Déploiement, appel, visualisation des journaux, gestion des versions
Console de gestion Web	Gestion visuelle et suivi des agents	Panneau d'appel, récupération de journaux, configuration d'alarme
API REST	Intégration CI/CD et planification automatisée	Déploiement d'agent, déclenchement, requête d'état

Flux de travail typique pour les développeurs :

1. Écrivez et testez le code de l'agent localement via CLI
2. Utilisez « cld deploy » pour transmettre le code au runtime des agents cloud.
3. Vérifiez le comportement du contexte de production via cld Invoke
4. Configurez le déclencheur Webhook ou Cron pour permettre à l'agent de s'exécuter automatiquement
5. Affichez les données de surveillance et récupérez les journaux via la console de gestion Web.

Intégration API : les agents Cloud fournissent une API RESTful qui prend en charge le déploiement et l'appel d'agents via des requêtes HTTP. Le point de terminaison de l'API utilise « https://api.cloudagents.ai/v1/ » comme chemin de base et utilise la clé API pour l'authentification. La liste des paramètres spécifiques et les paramètres sont soumis à des documents officiels.

Tarification des produits pour les agents cloud

Cloud Agents adopte un modèle de paiement à l'utilisation et ne facture pas de frais de plateforme mensuels fixes. La structure tarifaire est relativement simple, mais des détails sont nécessaires.

Quota gratuit : La plateforme offre aux nouveaux utilisateurs un quota d'appels gratuits (incluant un certain nombre d'appels gratuits et du temps d'exécution). La valeur spécifique n'est pas clairement divulguée sur les chaînes publiques. Vous devez le vérifier après l'inscription ou vous référer à la dernière annonce sur le site officiel.

Paiement à l'utilisation : une fois le quota gratuit dépassé, la facturation sera basée sur les dimensions suivantes :

• Nombre d'appels : chaque exécution d'agent est comptée comme un appel
• Durée d'exécution : facturée en fonction de la durée d'exécution réelle (secondes) du code de l'agent
• Ressources supplémentaires : Si vous postulez pour un conteneur sandbox avec des spécifications plus élevées (mémoire/CPU), le prix sera augmenté en fonction du gradient des spécifications.

Structure de coûts implicite :

• Les frais API LLM ne sont pas inclus dans la facture des Agents Cloud : La consommation de Token générée par l'Agent appelant de grands modèles tiers est à la charge du développeur. Ce coût est généralement bien supérieur aux frais d’appel de la plateforme elle-même. Les frais mensuels de l'API LLM pour un agent haute fréquence peuvent atteindre 5 à 10 fois les frais de la plateforme.
• Bande passante sortante : si l'agent télécharge fréquemment des fichiers volumineux ou transmet de grandes quantités de données, le coût de la bande passante sortante de la plateforme cloud ne peut être ignoré.

Tarif entreprise : non divulgué. Dans les scénarios d’appels à grande échelle ou à haute fréquence, vous devez contacter l’entreprise pour obtenir des solutions personnalisées. Il est recommandé de confirmer les conditions suivantes avant d'acheter : engagement de disponibilité du SLA avec gradient de remise sur volume, période de stockage des données et garantie de compatibilité des mises à jour de la version de la plateforme pour les agents existants.

Scénarios d'application des agents cloud

La valeur fondamentale des agents Cloud est de « permettre aux agents d'être en ligne rapidement et de fonctionner de manière stable ». Les quatre scénarios suivants ont été vérifiés par les utilisateurs initiaux :

• Lien de production de contenu automatisé : configurez un agent qui "explore → résume → distribue" et le déclenche régulièrement via Cron. L'agent récupère les derniers articles de RSS/API, appelle LLM pour générer des résumés en chinois et des conclusions clés, et les transmet au système Feishu/DingTalk ou CMS via Webhook. Conseil de mise en œuvre : ce scénario nécessite une stabilité de l'agent supérieure à la vitesse de réponse - même si une seule exécution prend 1 à 2 minutes, elle est acceptable, mais elle doit être exécutée à temps chaque jour sans manquer aucun point négatif. Les déclencheurs Cron et les mécanismes de nouvelle tentative d'échec des agents Cloud sont naturellement adaptés.

• Classification et réponse intelligentes des bons de travail du service client : connectez le système de service client de l'entreprise aux agents cloud via Webhook. Chaque fois qu'un nouveau bon de travail est créé, l'Agent lit automatiquement le contenu du bon de travail, appelle LLM pour le classer (réclamation/consultation/après-vente) et génère un projet de réponse. Conseils de mise en œuvre : Il est recommandé de définir Human-in-the-loop pour les ordres de travail importants : les réponses générées par l'agent sont envoyées pour examen manuel avant d'être émises, et les réponses automatiques ne sont activées que sur les ordres de travail à faible risque. Les capacités de gestion des versions des agents Cloud sont particulièrement utiles dans ce scénario : si une certaine version génère des réponses inappropriées, vous pouvez revenir à la version précédente en quelques secondes.

• Inspection de reporting et de surveillance des données : l'agent interroge régulièrement la base de données ou l'API pour obtenir des indicateurs commerciaux, appelle LLM pour analyser les anomalies et les tendances des données et génère des rapports structurés. Conseil de mise en œuvre : Il faut prêter attention au risque d'illusion lorsque l'agent analyse les données : il est recommandé d'exiger clairement dans l'invite que "l'analyse est uniquement basée sur les données fournies et ne complète pas les informations d'hypothèse non fournies", et de marquer la source des données et la date limite dans la sortie.

• Assistant d'efficacité personnelle (rappel programmé + agrégation d'informations) : configurez plusieurs agents légers, chacun responsable d'une tâche fixe - résumé quotidien de l'actualité, rappel des variations de stock et génération automatique de rapports hebdomadaires. Les développeurs individuels peuvent exécuter ces agents dans le cadre du quota gratuit à un coût quasiment nul. Conseils de mise en œuvre : plusieurs agents peuvent partager le même serveur MCP (comme les requêtes météo, l'exploration des actualités) pour éviter de déployer une chaîne d'outils distincte pour chaque agent.

Groupes applicables d'agents cloud

Cloud Agents a un positionnement clair : il est conçu pour les développeurs qui « peuvent écrire du code et ne veulent pas se soucier de l'exploitation et de la maintenance ». Il n'est pas recommandé aux utilisateurs non techniques de l'utiliser directement en raison du manque de capacités de création d'agents.

• Développeurs d'applications IA et développeurs indépendants : il s'agit du groupe d'utilisateurs principal des agents cloud. Si vous savez déjà comment écrire un agent à l'aide de LangChain, CrewAI ou appeler directement l'API LLM, mais que vous en avez assez de devoir écrire Dockerfile, configurer Nginx et Prometheus pour chaque déploiement, les agents cloud peuvent ignorer ces détails directement. Prérequis : Vous devez disposer de capacités de programmation Python ou TypeScript et comprendre les concepts de base du protocole MCP. Ne convient pas aux limites : si vous devez effectuer un glisser-déposer visuel pour créer des agents, ou terminer le déploiement sans code, les agents Cloud ne sont pas le bon outil.

• Équipe Entrepreneuriat (2-10 personnes) : Lors des étapes de validation du produit et du marché, l'équipe ne dispose généralement pas d'ingénieur en infrastructure IA dédié. Les agents Cloud permettent aux ingénieurs full-stack de terminer l'intégralité du processus d'agent, du prototype à la mise en ligne, en quelques heures, sans attendre les ressources DevOps. Conseil de mise en œuvre : il est recommandé d'utiliser le quota gratuit pour exécuter PoC au début du projet, puis de décider si vous souhaitez accéder au forfait payant après avoir vérifié la valeur commerciale de l'agent. Le chemin parcouru par l'équipe pour migrer des agents cloud vers une solution auto-hébergée doit être évalué à l'avance : si le code de l'agent s'appuie fortement sur le magasin KV et les capacités de routage MCP des agents cloud, ces couches d'adaptation doivent être réécrites pendant la migration.

• Équipe IA d'entreprise (standardisation des outils internes) : encapsulez les outils d'IA fréquemment utilisés au sein de l'entreprise (tels que l'assistant de révision de contrat, l'agent de révision de code, l'assistant de requête de données) dans des agents standard, puis déployez et gérez-les de manière uniforme via des agents cloud. Prérequis : l'entreprise doit confirmer si le lien de traitement des données des agents cloud répond aux exigences de conformité (si les données quittent les limites du réseau de l'entreprise). Ne convient pas aux frontières : pour les secteurs de la finance, des affaires gouvernementales et de la confidentialité qui nécessitent un déploiement hors ligne complet et où les données ne doivent pas transiter par des plateformes tierces, le modèle d'hébergement cloud des agents cloud peut ne pas répondre aux exigences de conformité. De tels scénarios doivent attendre des solutions de déploiement privatisées ou trouver des alternatives.

• Ne convient pas aux personnes : les agents cloud ne sont pas recommandés pour les groupes suivants : utilisateurs non techniques qui ont besoin d'un générateur d'agent visuel ; des scénarios d'interaction en temps réel avec des exigences strictes de latence de réponse inférieure à la seconde (tels que les robots du service client en ligne, les agents de conversation vocale) ; Services d'inférence d'IA qui nécessitent un contexte d'exécution profondément personnalisé (tels que des pilotes GPU spécifiques, une accélération matérielle dédiée) ; et les entreprises qui ont des exigences strictes en matière de souveraineté des données et doivent être déployées en privé.

Résumé et Outlook des agents Cloud

Cloud Agents a fait un choix ciblé et restreint sur le segment « Déploiement et fonctionnement d'agents IA », qui est considéré par la plupart des plateformes comme des fonctions supplémentaires plutôt que comme des produits de base : non pas pour créer un générateur d'agents, mais uniquement pour créer la couche d'exécution. Cette stratégie « moins, c'est plus » est extrêmement attrayante pour les développeurs ayant des besoins clairs et de solides capacités techniques : ils n'ont pas besoin d'une autre plate-forme low-code, mais d'un environnement d'exécution d'agent fiable, flexible, sans opération ni maintenance.

Principaux avantages concurrentiels : l'architecture sans serveur n'apporte aucun coût d'inactivité, une intégration native du protocole MCP (plutôt que des extensions de plug-in), une indépendance du framework (aucun verrouillage d'un framework de développement d'agent) et des fonctionnalités complètes de gestion des versions et de publication en niveaux de gris. À l'heure actuelle en 2026, Cloud Agents est l'une des rares plates-formes d'hébergement d'exécution d'agent pures sur le marché national.

Limites majeures actuelles : Le produit est encore au stade v1 et la maturité écologique est limitée - le nombre de serveurs MCP disponibles et la bibliothèque d'outils officiellement maintenue sont toujours en construction ; les fonctions au niveau de l'entreprise (exécution au sein d'un réseau privé VPC, RBAC à granularité fine, journaux d'audit) ne sont pas encore prises en charge publiquement ; la transparence des prix est insuffisante et les estimations de coûts avant les appels à grande échelle nécessitent de contacter l'entreprise ; il y a un manque de chemins de migration fluides entre la plateforme et l'auto-hébergement, et le couplage entre le code et l'API de la plateforme constitue un risque potentiel de verrouillage.

Points d'observation de suivi : les versions ultérieures des agents cloud lanceront-elles des solutions de déploiement privatisées au niveau de l'entreprise (c'est la clé pour ouvrir les marchés financiers et gouvernementaux) ; la vitesse d'enrichissement de l'écosystème MCP - si la plate-forme peut prédéfinir un ensemble de serveurs MCP propriétaires de haute qualité, le coût d'intégration pour les nouveaux utilisateurs sera considérablement réduit ; et intégration avec les agents traditionnels. La profondeur d'intégration officielle des frameworks (LangChain, CrewAI, AutoGen) - elle est actuellement "indépendante du framework" mais "exige que les développeurs s'adaptent". Le modèle d'adaptation officiel abaissera considérablement le seuil de démarrage.

Évaluation des risques d'approvisionnement et d'adoption : pour les développeurs individuels et les équipes entrepreneuriales, le modèle de quota gratuit et de facturation à l'utilisation des agents cloud contrôle le coût des essais et des erreurs à un niveau très bas, ce qui mérite une vérification PoC dans le prochain projet d'agent. Pour les moyennes et grandes entreprises, il est recommandé de le tester dans des scénarios de processus non critiques (questions et réponses sur les connaissances internes, aide à la génération de rapports, agent de chaîne d'outils de développement), d'évaluer la stabilité, les délais et le modèle de coût, puis de décider s'il faut l'étendre à des scénarios de quasi-production ou face au client. Avant de signer un contrat d'approvisionnement, les conditions qui doivent être vérifiées avec l'équipe commerciale des agents cloud incluent : les engagements de disponibilité des SLA de localisation géographique pour le stockage et le traitement des données (en particulier les garanties de niveau P999), les politiques de compatibilité ascendante pour les mises à jour des versions de la plateforme et les plans de faisabilité pour l'exportation des données et la migration de la plateforme. Pour les secteurs disposant d'une souveraineté sur les données sensibles, il est recommandé d'utiliser uniquement des agents cloud pour gérer des scénarios de données non sensibles avant la mise en œuvre de la solution de déploiement privatisée.

Outils associés : crewai, langchain

Informations de version

• Agents cloud v1 ：La première version publique prend en charge la chaîne d'outils MCP, le déclenchement de Webhook de commutation multimodèle et le panneau de surveillance. （~2026-05）
• Agents Cloud bêta ：Version bêta interne, environnement d'exécution de base de l'agent et capacités de déploiement. （~2026-03）
• Agents cloud alpha ：Étape de prototype interne pour vérifier la faisabilité de l'architecture d'exécution de l'Agent sans serveur. Il n’y a pas encore de date officielle précise. （~2025-12）