Images en pièce jointe dans DeepSeek Harness : guide 2026

Dernière mise à jour : 18 août 2026. Les éléments techniques ont été recoupés avec la documentation actuelle de l’API DeepSeek, la spécification MCP et la documentation publique des adaptateurs ACP. Le périmètre fonctionnel de DeepSeek Harness rc.7 est traité selon les éléments confirmés dans le dossier de version fourni pour cette validation.

Le point de séparation est important. La version rc.7 confirme l’ajout de pièces jointes d’image persistantes pour MCP et ACP, ainsi que le transfert d’images vers les sous-tâches en PTC Mode. Cela ne signifie pas que chaque modèle accepte une image. La capacité dépend du modèle sélectionné, de la déclaration du Provider et de l’endpoint amont.

La documentation de l’API DeepSeek décrit actuellement le contenu utilisateur de Chat Completions comme textuel. Nous ne devons donc pas transformer le nom d’un modèle, une option d’interface ou une déclaration locale en preuve de vision. (api-docs.deepseek.com)

Le premier contrôle doit répondre à une question simple : le modèle actif accepte-t-il officiellement une entrée image sur l’endpoint appelé ?

Un modèle ou un Provider personnalisé peut déclarer image: true, vision: true ou une capacité équivalente. Cette déclaration autorise parfois l’affichage du sélecteur de fichier. Elle ne prouve pas que l’endpoint amont accepte le contenu multimodal. Nous séparons donc trois niveaux :

• Interface : le fichier peut être sélectionné.
• Configuration : le modèle ou le Provider annonce une entrée image.
• Amont : la requête est acceptée et le modèle produit une réponse fondée sur le détail visuel.

Pour le test, nous utilisons une image de contrôle qui contient un détail impossible à deviner depuis son nom. Par exemple, une maquette audio avec un seul bouton placé dans un coin, une capture vidéo présentant un message d’erreur unique ou une interface de design avec une couleur volontairement inhabituelle. Le prompt demande ensuite de localiser ce détail.

La preuve minimale comprend :

• la configuration du modèle actif ;
• la déclaration de capacité du Provider ;
• la requête ou le journal d’appel, avec les secrets retirés ;
• le code ou message d’erreur renvoyé par l’amont ;
• la réponse du modèle, qui doit mentionner le détail réellement présent.

Si l’interface accepte la sélection mais que l’amont répond « contenu non pris en charge », le résultat est refusé, même si la miniature reste visible. Si le Provider annonce la vision mais convertit l’image en simple chemin local, le résultat est limité : l’agent peut éventuellement lire le fichier avec un outil, mais le modèle n’a pas reçu d’entrée image native.

Cette distinction est particulièrement importante avec un service personnalisé. Ne confondez pas la capacité déclarée par votre adaptateur avec la compatibilité effective de l’API appelée. Pour comprendre la structure d’un flux MCP, consultez aussi la documentation officielle sur les ressources binaires MCP, qui montre qu’une ressource peut être fournie sous forme de blob, sans pour autant garantir qu’un modèle donné saura l’interpréter. (ts.sdk.modelcontextprotocol.io)

MCP et ACP ne doivent pas être validés avec le seul indicateur visuel de l’interface. Dans MCP, les messages reposent sur JSON-RPC et les ressources peuvent être négociées séparément des outils. La présence d’une ressource ne signifie donc pas automatiquement que le contenu a été injecté dans la requête du modèle. (modelcontextprotocol.io)

Nous testons chaque chaîne avec deux images et une consigne qui impose un ordre :

1. l’image A contient un élément rouge ;
2. l’image B contient un élément bleu ;
3. la consigne demande d’identifier A puis B ;
4. une seconde consigne inverse volontairement l’ordre.

Ce test révèle trois défauts fréquents :

• les pièces jointes sont reçues mais réordonnées ;
• le texte de la tâche arrive sans les images ;
• seule une miniature est transmise alors que le détail demandé se trouve dans la définition originale.

Pour MCP, la trace doit permettre de relier l’identifiant de ressource, le type MIME, l’appel resources/read ou l’équivalent utilisé, puis la requête adressée au modèle. Les spécifications et exemples MCP indiquent que les contenus binaires peuvent être encodés comme des blobs ; nous vérifions donc que la ressource réellement lue correspond à l’image test et non à une URL expirée ou à un aperçu. (apps.extensions.modelcontextprotocol.io)

Pour ACP, le contrôle porte sur la négociation des capacités de la session, le contenu du message envoyé par le client et le contexte reçu par l’agent. Certains adaptateurs annoncent explicitement la prise en charge des images ; cette déclaration doit être comparée au comportement de l’agent et de son Provider. Un adaptateur ACP public, par exemple, documente séparément les mentions de contexte et les images : cette séparation doit être conservée dans notre journal d’acceptation. (github.com)

Procédure de transmission en cinq étapes

1. Préparez deux images de test non sensibles, avec des détails visuels différents.
2. Donnez à chaque fichier un identifiant logique, indépendant du nom réel.
3. Envoyez-les dans un ordre connu avec une instruction qui exige une comparaison.
4. Exportez la trace MCP ou ACP en masquant les jetons, les chemins privés et les noms de dépôt.
5. Comparez l’identifiant, le type MIME, l’ordre, la taille ou l’empreinte disponible, puis la réponse du modèle.

La transmission est réussie seulement si la réponse correspond au bon fichier et au bon ordre. Une réponse générique, même grammaticalement correcte, reste insuffisante.

La persistance doit être testée après trois ruptures distinctes : rafraîchissement de la page, reconnexion du client et redémarrage du processus. Ces actions ne sollicitent pas toujours le même mécanisme.

Nous séparons :

• le cache d’interface, qui peut conserver une miniature ;
• l’historique de session, qui peut conserver un événement ou un identifiant ;
• l’actif réellement relisible, encore disponible avec les droits nécessaires ;
• le contexte modèle, qui peut ne pas être reconstruit même si le fichier existe.

La bonne séquence est la suivante :

1. envoyer une image et demander l’identification d’un détail ;
2. fermer puis rafraîchir l’interface ;
3. rouvrir la même session ;
4. demander un second détail présent dans l’image ;
5. couper la connexion du client puis la rétablir ;
6. redémarrer le processus ou le service ;
7. effectuer une nouvelle lecture sans téléverser l’image.

Le résultat doit préciser à quel moment l’image cesse d’être disponible. Une session peut afficher l’ancien message tout en étant incapable de relire l’actif. Dans ce cas, nous classons la persistance comme partielle, et non comme réussie.

Nous contrôlons également les permissions. Une image conservée dans un répertoire temporaire, un volume monté en lecture seule ou un emplacement accessible seulement à l’utilisateur initial peut disparaître fonctionnellement après transfert de la session. La question n’est pas seulement « le fichier existe-t-il ? », mais « le nouveau processus peut-il le retrouver et le lire avec son identité d’exécution ? ».

Le transfert vers une sous-tâche exige un scénario différent du test principal. Nous préparons une image contenant deux niveaux d’information :

• un élément général visible rapidement ;
• un détail précis réservé à une zone de l’image.

La tâche principale demande un résumé général. La sous-tâche reçoit ensuite une instruction ciblée sur le détail. Si elle répond uniquement avec le résumé déjà produit par la tâche principale, cela ne prouve pas qu’elle a reçu l’image originale.

La trace attendue comprend :

• l’identifiant de la tâche principale ;
• l’identifiant de la sous-tâche ;
• le manifeste ou la référence d’attachement ;
• les capacités annoncées par le canal ;
• la réponse de réception ;
• la sortie de la sous-tâche ;
• le nœud responsable en cas d’échec.

Le dossier rc.7 confirme le transfert d’images vers les tâches imbriquées en PTC Mode dans le périmètre décrit. La validation opérationnelle reste nécessaire, car l’échec peut se produire à plusieurs endroits : création de l’attachement, sérialisation, autorisation de lecture, transfert de contexte, résolution de la référence ou appel du modèle.

Nous évitons les images de clients, les captures contenant des clés et les dépôts réels. Une maquette d’interface audio, une capture vidéo artificielle ou un écran de design généré pour le test fournit une preuve suffisante sans exposer de données confidentielles.

Pourquoi DeepSeek Harness refuse-t-il parfois une image ?

Le premier suspect est la capacité du modèle, pas MCP. Vérifiez le modèle actif, la déclaration du Provider et l’endpoint réellement appelé. Si l’API accepte uniquement du texte, l’interface peut afficher une pièce jointe sans pouvoir la transmettre nativement. Conservez la réponse d’erreur et ne remplacez pas automatiquement l’image par une description produite localement.

MCP et ACP conservent-ils les images après reconnexion ?

La conservation dépend du stockage de la session et de la façon dont l’attachement est référencé. Nous considérons la persistance acquise seulement après rafraîchissement, reconnexion et redémarrage. Une miniature conservée en mémoire ou dans le navigateur ne suffit pas. Le test doit confirmer qu’un processus neuf peut encore lire l’actif avec les permissions attendues.

Le PTC Mode reçoit-il l’image originale ?

Il peut recevoir l’image ou une référence vers celle-ci, mais la preuve doit venir de la tâche imbriquée. Utilisez un détail que la tâche principale ne transmet pas dans son résumé. Si la sous-tâche le retrouve, puis que la trace relie son contexte à l’attachement, le transfert est crédible. Sinon, classez le scénario comme limité et conservez la tâche principale comme seul niveau fiable.

Comment vérifier une image dans un environnement distant ?

Conservez un manifeste sans secret, contrôlez le type MIME, vérifiez l’existence de l’actif dans le contexte de session et faites une relecture après changement de connexion. Demandez aussi à un second opérateur de reprendre la session. Cette dernière étape révèle les dépendances cachées à un compte local, à un chemin temporaire ou à un cache d’interface.

Pourquoi la reprise renvoie-t-elle deux fois la même image ?

Une reprise peut rejouer un événement utilisateur non confirmé. Le problème apparaît lorsque l’appel précédent a échoué après l’enregistrement de l’attachement, mais avant l’enregistrement du résultat. Comparez les identifiants d’événements et les tentatives d’envoi. En cas de boucle, retirez l’attachement, changez de modèle ou créez une session neuve avant de relancer.

Un Mac distant n’est pas automatiquement un coffre-fort pour les pièces jointes. Nous contrôlons quatre responsabilités séparées :

• où les octets sont stockés ;
• quel processus possède le droit de lecture ;
• combien de temps la référence reste valable ;
• comment un autre opérateur reprend la session.

Pour un test d’interface, l’image peut être temporaire. Pour une preuve de non-régression, elle doit être associée à une session, une version du Provider et une trace exportable. Nous déconseillons de placer des captures sensibles dans un dossier partagé sans politique d’accès ni nettoyage documenté.

Avant la remise, nous vérifions que l’équipe suivante peut :

1. retrouver la session avec son identifiant ;
2. comprendre quelles images ont été envoyées ;
3. relire les fichiers autorisés ;
4. reproduire la requête sans clé personnelle ;
5. distinguer un échec du modèle d’un échec du transport.

Pour préparer l’environnement, la page MESHLAUNCH dédiée aux Mac distants peut servir de point de départ pour comparer le type de machine, l’accès et la remise opérationnelle. Nous recommandons cependant de traiter séparément la disponibilité de la machine et la persistance des données : l’une ne garantit pas l’autre.

La première table sert à classer l’état de chaque indicateur. Elle ne remplace pas les traces ; elle évite de transformer un signal d’interface en conclusion.

La seconde table sert à choisir la stratégie lorsque l’API DeepSeek reste textuelle ou lorsqu’un Provider personnalisé ne fournit pas de preuve suffisante.

Enfin, cette troisième table formalise les choix d’environnement. Les coûts, performances et capacités particulières doivent être renseignés avec vos données réelles ; nous ne les déduisons pas du simple fait qu’une machine est distante.

• [ ] Le modèle actif déclare explicitement une entrée image.
• [ ] L’endpoint amont a accepté une image de test et non seulement le texte associé.
• [ ] Le fichier testé contient un détail visuel identifiable.
• [ ] Deux images ont été envoyées dans un ordre vérifiable.
• [ ] La réponse distingue correctement les deux images.
• [ ] La trace MCP ou ACP contient une référence exploitable.
• [ ] Le type MIME et l’identité logique de l’actif sont conservés.
• [ ] La relecture fonctionne après rafraîchissement.
• [ ] La relecture fonctionne après reconnexion du client.
• [ ] La relecture fonctionne après redémarrage du processus.
• [ ] La sous-tâche en PTC Mode reçoit le détail non résumé.
• [ ] Un échec identifie le nœud responsable.
• [ ] Une reprise contrôlée ne renvoie pas automatiquement la même image.
• [ ] Le scénario de retrait de l’image a été testé.
• [ ] Le changement de modèle a été testé comme solution de secours.
• [ ] Un second opérateur peut reprendre la session distante.
• [ ] Aucune capture sensible, clé ou donnée client n’est incluse dans la preuve.

Une installation locale peut sembler plus simple, mais elle laisse souvent trois défauts non traités : la preuve reste sur le poste d’un seul développeur, les chemins temporaires changent selon l’utilisateur et la reprise après incident n’est pas vérifiée. Une chaîne textuelle ou un Provider qui accepte seulement des descriptions perd en outre la valeur des captures d’écran, des maquettes vidéo et des contrôles visuels.

Pour une équipe qui doit partager des preuves, répéter un scénario et remettre une session à un autre opérateur, la location d’un Mac avec MESHLAUNCH offre un cadre plus adapté qu’un poste personnel isolé, à condition de valider séparément les droits, le stockage et la persistance des pièces jointes. Nous recommandons de commencer par une seule image de test dans un environnement distant indépendant, puis d’élargir aux flux MCP, ACP et PTC Mode lorsque chaque case de la checklist est prouvée.

Le prochain geste utile est de copier cette grille dans votre procédure d’acceptation, d’exécuter une session sans données sensibles et de classer chaque flux en passé, limité ou refusé. Pour les équipes qui doivent ensuite industrialiser la remise d’un environnement Mac et la reprise d’une session, consultez également les options de Mac distant par région avant de décider si la location, l’achat d’un poste ou une exécution locale répond le mieux à la durée et au niveau de charge prévus.