DeepSeek Harness Bildanhänge 2026 prüfen

Ein sichtbares Vorschaubild ist kein Beweis für eine erfolgreiche Bildverarbeitung. Es kann aus einem Browser-Cache, einer lokalen UI-Komponente oder einer Sitzungsansicht stammen. Entscheidend ist, ob der Anhang den Modellendpunkt erreicht und in der Antwort tatsächlich berücksichtigt wurde.

Für die Abnahme trennen wir deshalb sieben Prüffelder:

Die rc.7-Änderungen bestätigen laut Aufgabenstand persistente Bildanhänge für MCP und ACP sowie die Weitergabe verschachtelter Bilder im PTC Mode. Das bedeutet jedoch nicht, dass jedes Modell automatisch visuelle Eingaben verarbeiten kann. Die offizielle Chat-Completions-Dokumentation führt Eingaben als Textstruktur und dokumentiert keine allgemeine Bildunterstützung für die dort beschriebenen DeepSeek-Routen. (api-docs.deepseek.com)

Erste Stufe: Provider und Modell getrennt prüfen

Wir tragen nicht nur den Modellnamen ein. In das Abnahmeprotokoll gehören:

• Provider-Name und Route
• exakte Modellkennung
• Konfigurationsfeld für Bild- oder Multimodal-Eingaben
• Zeitpunkt der Prüfung
• sichtbare Validierungs- oder Fehlermeldung
• Antwort des Upstream-Endpunkts
• verwendete Testdatei und deren Prüfsumme

Ein benutzerdefinierter Provider darf „image input supported“ anzeigen. Das ist lediglich eine Konfigurationsaussage. Sie beweist nicht, dass der Upstream-Endpunkt Bilddaten annimmt, dekodiert oder im Antworttext berücksichtigt.

Die offizielle DeepSeek-API-Referenz beschreibt für die Chat-Completions-Schnittstelle Nachrichten mit Textinhalt und listet unterstützte Modellkennungen. Eine deklarierte Bildfähigkeit im Harness darf daher nicht mit einer bestätigten visuellen Fähigkeit der Route gleichgesetzt werden. (api-docs.deepseek.com)

Woran erkennen wir einen echten visuellen Test?

Wir verwenden keine dekorative Aufnahme mit schwer prüfbarem Inhalt. Besser ist eine synthetische Testgrafik mit eindeutigem Inhalt:

• drei unterschiedlich gefärbte Quadrate
• eine sichtbare Kennung wie TEST-A-271
• eine kurze Tabellenzeile
• eine absichtlich auffällige Position, etwa „rotes Quadrat oben rechts“
• keine Kundendaten, Zugangsdaten oder Repository-Inhalte

Die Aufgabenbeschreibung fragt anschließend nach mindestens zwei unabhängigen Details. Beispielsweise soll das Modell die Kennung nennen und die Position des roten Quadrats bestimmen. Eine Antwort wie „Ich sehe ein Bild“ reicht nicht.

Warum lehnt DeepSeek Harness das Senden eines Bildes ab?
Typische Ursachen liegen vor dem eigentlichen Transport: Das Modell deklariert keine Bildeingabe, der Provider entfernt den Bildteil beim Normalisieren, der Endpunkt akzeptiert nur Text oder die UI erkennt zwar den Anhang, darf ihn aber nicht an die gewählte Route senden. Wir protokollieren deshalb die Stelle, an der die Ablehnung entsteht. Eine reine Fehlermeldung im Chatfenster ist zu wenig.

MCP und ACP sind in diesem Test keine Synonyme. Wir prüfen jede Kette separat. Ein funktionierender MCP-Pfad beweist nicht automatisch, dass die ACP-Integration dieselbe Dateireferenz, Reihenfolge oder Lebensdauer verwendet.

Der Testablauf sollte immer dieselbe Reihenfolge haben:

1. Testbild erzeugen und mit einer eindeutigen Kennung versehen.
2. Bild über MCP senden.
3. Bild über ACP senden.
4. Aufgabe mit einer prüfbaren visuellen Frage ausführen.
5. Transportereignis, Modellantwort und Referenz speichern.
6. Zweites Bild ergänzen und die Reihenfolge erneut prüfen.
7. Einen absichtlich ungültigen Anhang testen.
8. Ergebnis je Kanal getrennt bewerten.

Eine Thumbnail-Anzeige darf höchstens als UI-Nachweis gelten. Der technische Nachweis muss zeigen, dass der Anhang in der Nachrichtenstruktur, in der Transportspur oder in einer abrufbaren Asset-Referenz vorhanden war.

Erfahrung aus der Abnahme: Wenn nur die Oberfläche eine Datei anzeigt, markieren wir den Test als „nicht entschieden“. Erst eine passende Modellantwort oder ein reproduzierbarer Transportnachweis macht daraus „bestanden“.

Können MCP und ACP Bildanhänge dauerhaft speichern?
Die rc.7-Funktion bestätigt die Persistenzfunktion im Harness. Ob ein Anhang nach einem Neustart tatsächlich wieder lesbar ist, hängt trotzdem von Asset-Speicher, Sitzungsdatei, Zugriffsrechten und Provider-Verhalten ab. Wir akzeptieren deshalb keine pauschale Aussage wie „ACP ist persistent“, sondern nur ein Ergebnis für die konkrete Kette.

Ein Refresh-Test muss mindestens drei Zustände unterscheiden:

Zusätzlich prüfen wir den Dateipfad oder die Asset-ID. Ein Eintrag in der Sitzungsdatei kann vorhanden sein, obwohl die referenzierte Datei gelöscht, verschoben oder nur im temporären Verzeichnis gespeichert wurde.

Die Prüfdaten sollten enthalten:

• Sitzungs-ID
• Asset-ID oder Dateireferenz
• Speicherort beziehungsweise Speicherklasse
• Dateigröße und Prüfsumme
• Besitzer und Zugriffsmodus
• Zeitpunkt von Upload, Refresh und Reconnect
• Ergebnis einer erneuten visuellen Abfrage

Eine Bilddatei kann außerdem verfügbar sein, während die Aufgabenbeschreibung fehlt. Dann erhält das Modell zwar ein Asset, aber nicht mehr die Information, welche Einzelheit geprüft werden sollte. Wir speichern daher Anhang und Aufgabenbeschreibung als zusammengehörige Beweiskette.

Wie bestätigen wir im Remote-Betrieb, dass kein Bild verloren ging?
Wir schließen die Prüfung nicht mit einem sichtbaren Eintrag in der Sitzung ab. Nach dem Reconnect lassen wir dieselbe Testfrage erneut beantworten und vergleichen die Kennung, die Position und den erwarteten Tabellenwert. Danach prüfen wir, ob die Datei unter dem vorgesehenen Berechtigungskontext lesbar ist. Ein fehlender Zugriff ist ein Persistenzfehler, selbst wenn die UI weiterhin ein Vorschaubild zeigt.

Bei einer verschachtelten Aufgabe müssen wir zwei Dinge auseinanderhalten: die Weitergabe des Bildes und die Weitergabe der richtigen Aufgabe. Ein Unteragent darf nicht einfach irgendeinen verfügbaren Anhang erhalten.

Wir erstellen dafür einen Fall mit zwei Testbildern:

• Bild A enthält die Kennung PARENT-ALPHA und eine große rote Markierung.
• Bild B enthält die Kennung CHILD-BETA und eine kleine blaue Markierung.
• Die Hauptaufgabe darf nur nach dem roten Detail fragen.
• Die verschachtelte Aufgabe darf nur nach dem blauen Detail fragen.

Die Beweiskette besteht aus:

1. Hauptaufgabe mit Bild A.
2. Erzeugung der Unteraufgabe im PTC Mode.
3. Übergabeentscheidung mit Asset-Referenz.
4. Empfangsereignis der Unteraufgabe.
5. Antwort der Unteraufgabe.
6. Rückgabe an die Hauptaufgabe.
7. Vergleich mit dem erwarteten Bildkontext.

Kann eine PTC-Mode-Unteraufgabe das Originalbild erhalten?
Ja, die rc.7-Release-Information weist die Weitergabe verschachtelter Bilder als neue Funktion aus. Für die Freigabe zählt jedoch nicht die Funktionsbeschreibung, sondern der konkrete Trace: Asset-Referenz, Empfang, visuelle Antwort und Fehlerverantwortung müssen zusammenpassen.

Eine alte Sitzung mit Bildanhang ist ein kritischer Testfall. Wenn der Upstream das Bild ablehnt, darf der Harness nicht unkontrolliert denselben Request wiederholen. Andernfalls entsteht eine Schleife aus Wiederholung, Ablehnung und erneutem Replay.

Wir testen vier Wiederherstellungspfade:

1. Sitzung mit gültigem Bild und kompatiblem Modell fortsetzen.
2. Sitzung mit abgelehntem Bild erneut laden.
3. Modell auf einen textbasierten Provider wechseln.
4. Bild entfernen und dieselbe Aufgabe als Textbeleg fortsetzen.

Für jeden Pfad wird ein eindeutiger Endzustand benötigt:

• Fortsetzung mit Bild
• Fortsetzung ohne Bild
• Wechsel zu neuem Gespräch
• kontrollierter Abbruch mit Fehlermeldung

Ein Wiederholungszähler gehört in das Protokoll. Nicht als Leistungskennzahl, sondern als Sicherheitsbeleg. Sobald derselbe Anhang nach einer bekannten Upstream-Ablehnung erneut ohne Änderung gesendet wird, markieren wir die Wiederherstellung als nicht betriebsbereit.

Die sichere Rückfallstrategie lautet:

• Anhang aus der wiederherzustellenden Nachricht entfernen.
• Ursache der Ablehnung im Sitzungsprotokoll behalten.
• Textliche Beschreibung oder redigierten OCR-Auszug verwenden.
• Bei notwendiger visueller Prüfung ein neues Gespräch mit geprüftem Modell starten.
• Die ursprüngliche Sitzung unverändert archivieren.

Die offizielle Dokumentation zur Modellkonfiguration sollte bei jedem Modellwechsel erneut geprüft werden. Ein neuer Modellname oder ein benutzerdefinierter Endpoint verändert nicht automatisch die Fähigkeit zur Bildverarbeitung. (github.com)

Ein entfernter Mac ist eine Ausführungsumgebung, aber kein automatischer Beweis für dauerhafte Speicherung oder Datenisolierung. Wir prüfen drei Verantwortungsbereiche:

Für eine DSGVO-konforme Übergabe verwenden wir keine echten Kundenscreenshots. Testbilder werden künstlich erzeugt. API-Schlüssel, Cookies, Repository-Inhalte und private Bildschirmbereiche bleiben aus dem Testmaterial heraus.

Wenn ein Remote-Mac-Arbeitsplatz für wiederholte Abnahmen benötigt wird, sollte die Umgebung vorab eindeutig dokumentiert sein. Dazu gehören das verwendete Betriebssystem, die Harness-Version, der aktive Provider, die Sitzungsspeicherung und der Zugriffspfad. Die MESHLAUNCH-Übersicht für entfernte Mac-Umgebungen kann dabei als Ausgangspunkt für die Bereitstellung dienen; die Bildpersistenz muss trotzdem innerhalb des konkreten Workflows geprüft werden.

Die folgende Liste verwenden wir pro Modell und pro Transportweg. Jeder Punkt braucht einen Beleg. Ein nicht überprüfter Punkt ist nicht „bestanden“, sondern „offen“.

Modell und Provider

• [ ] Exakte Modellkennung und Provider-Route dokumentiert
• [ ] Bildfähigkeit in der Konfiguration ausdrücklich deklariert
• [ ] Upstream-Antwort mit einer synthetischen Testgrafik geprüft
• [ ] Ablehnung vor dem Versand oder nach dem Versand lokalisiert
• [ ] Benutzerdefinierte Provider-Angabe nicht als alleiniger Bildnachweis akzeptiert

MCP und ACP

• [ ] Einzelbild über MCP übertragen
• [ ] Einzelbild über ACP übertragen
• [ ] Zwei Bilder mit prüfbarer Reihenfolge übertragen
• [ ] Aufgabenbeschreibung gemeinsam mit dem Anhang erhalten
• [ ] Ungültige Referenz kontrolliert abgelehnt
• [ ] Transportprotokoll und Modellantwort archiviert

Persistenz und Recovery

• [ ] Browser- oder Client-Refresh ausgeführt
• [ ] Reconnect ausgeführt
• [ ] Harness- oder Prozessneustart ausgeführt
• [ ] Asset nach jedem Schritt tatsächlich lesbar
• [ ] Sitzungs-ID und Asset-ID bleiben korrekt verbunden
• [ ] Abgelehnte Bilder werden nicht endlos erneut gesendet
• [ ] Rückfall auf Textbeleg oder neues Gespräch getestet

PTC Mode und Remote Mac

• [ ] Hauptaufgabe und Unteraufgabe erhalten unterschiedliche Testbilder
• [ ] Unteraufgabe nennt die Kennung des richtigen Bildes
• [ ] Fehlerverantwortung im Trace erkennbar
• [ ] Speicherort und Berechtigung der Assets geprüft
• [ ] Übergabe ohne Kundendaten und echte Geheimnisse reproduziert
• [ ] Zweites Teammitglied kann den Test nachvollziehen

Wir vergeben drei Ergebnisse:

Bestanden: Modell, Transport, Persistenz, Verschachtelung und Wiederherstellung liefern reproduzierbare Nachweise. Der Workflow darf für den geprüften Anwendungsfall eingesetzt werden.

Begrenzt: Einzelne Pfade funktionieren, aber beispielsweise Reconnect, PTC Mode oder der ACP-Kanal ist nicht belastbar. Der Workflow bleibt auf Testbetrieb beschränkt. Das Protokoll muss die erlaubten und verbotenen Fälle nennen.

Abgelehnt: Das Modell akzeptiert keine Bilder, der falsche Anhang erreicht die Unteraufgabe, Assets verschwinden nach Neustart oder eine Ablehnung führt zum Replay. Dann wechseln wir auf Textbelege, verwenden einen ausdrücklich geprüften visuellen Provider oder starten einen neuen Sitzungsablauf.

Im aktuellen Vergleich hat eine lokale oder bereits vorhandene Windows- beziehungsweise Linux-Umgebung häufig drei praktische Nachteile: Der Zustand ist nicht immer reproduzierbar, Übergaben hängen stärker von individueller Einrichtung ab und die Beweiskette aus Sitzung, Datei und Berechtigung liegt oft bei mehreren Verantwortlichen. Eine entfernte Mac-Umgebung ist deshalb nicht automatisch besser, kann aber für zeitlich begrenzte Tests, Teamübergaben und isolierte Abnahmen sinnvoller sein, wenn Speicher- und Zugriffsregeln vorher festgelegt werden. Für solche Fälle kann das Mieten eines passenden Mac-Arbeitsplatzes die Einrichtung eines separaten Prüfplatzes vereinfachen. Für langfristige, dauerhaft hohe Lasten oder Anforderungen an physische Schnittstellen bleibt der Kauf eigener Hardware die ehrlichere Wahl.

Laden Sie für den nächsten Durchlauf eine leere Abnahmeliste, erzeugen Sie zwei harmlose Testbilder und führen Sie zuerst nur einen MCP- und einen ACP-Pfad durch. Wenn die Anhänge langfristig gespeichert oder von mehreren Personen geprüft werden müssen, sollte anschließend auch die Übergabe der entfernten Mac-Umgebung und die Wiederherstellung der Sitzung als eigener Testfall dokumentiert werden.