Automatisierung · News

Microsoft öffnet den Copilot-Harness für Entwickler in Foundry

Der öffentliche Preview-Dienst trennt die Orchestrierung eines Agenten vom gewählten Modell und verbindet Skills, freigegebene Tools, eine verwaltete Laufzeit und begrenzte Delegation in Microsoft Foundry.

Eine Entwicklerin oder ein Entwickler arbeitet an mehreren Bildschirmen; Kontextaufnahme, kein Screenshot von Microsoft Copilot oder Foundry.
Eine Entwicklerin oder ein Entwickler arbeitet an mehreren Bildschirmen; Kontextaufnahme, kein Screenshot von Microsoft Copilot oder Foundry.Foto von Ilham Malik / Unsplash

Der Harness ist das System um das Modell

Microsoft kündigte den Copilot Harness in Foundry Agent Service am 28. Oktober als öffentliche Vorschau an. In diesem Modell interpretiert ein Modell Anweisungen und erzeugt Antworten; der Harness koordiniert Kontext, Tools, Ausführung, Zustand und die Schleife für den nächsten Schritt. Microsoft sagt, eine gemeinsame Harness-Strategie unterstütze mehrere Copilot-Erlebnisse; nun steht eine verwaltete Variante über Foundry bereit.

Diese Unterscheidung ist wichtig: Ein Modellwechsel liefert nicht automatisch zuverlässige Berechtigungen, Fehlerbehandlung oder Workflow-Logik. Ein Agent, der Quellen recherchiert und ein Briefing vorbereitet, braucht freigegebene Belege, eine kontrollierte Laufzeit und eine Möglichkeit zur Prüfung. Der Harness verbindet diese Elemente operativ; er ist weder ein neues Foundation-Modell noch eine Garantie für korrekte Aufgabenerledigung.

Was die Foundry-Vorschau umfasst

Microsoft nennt wiederverwendbare Skills, verbundene Foundry- und MCP-Tools, Ausführung mit Dateien und Code, begrenzte eingebaute Subagenten sowie Agentendefinitionen im Quellcode. Der verwaltete Dienst führt Agentenschleife und Sandbox aus; Entwickler liefern Wissen, Verfahren und Tools. Ein unterstütztes Foundry-Modell lässt sich wählen, ohne die Orchestrierung bei jedem Wechsel neu aufzubauen.

Microsoft zufolge werden Authentifizierung und Tool-Freigaben ausdrücklich konfiguriert und Aufgaben durch Grenzen und Richtlinien gesteuert. Die allgemeine Verfügbarkeit der Langzeit-Resilienz für gehostete Agenten wurde separat angekündigt; sie gilt nicht automatisch für den Copilot Harness, der in Vorschau bleibt. Zugriff, Regionen, Kosten und unterstützte Modelle sollten in der aktuellen Tenant-Dokumentation geprüft werden.

Warum mehrere Modelle helfen können — und neue Fragen schaffen

Ein Team kann für strukturierte Extraktion ein schnelleres, günstigeres Modell und für einen schwierigen Ausnahmefall ein stärkeres Reasoning-Modell wählen. Eine getrennte Orchestrierung kann solche Wechsel erleichtern und die Bindung an ein einzelnes Modell verringern, wenn Definitionen, Tools und Tests portabel sind. Microsoft verspricht jedoch eine Auswahl unterstützter Foundry-Modelle, keinen beliebigen Austausch in jedem Workflow.

Routing bringt neue Fragen: Welche Hinweise bestimmen die Modellauswahl, wie werden Kosten gemessen und was passiert bei widersprüchlichen Antworten? Testen Sie Konfigurationen mit denselben Aufgaben, überwachen Sie Tool-Fehler und behalten Sie menschliche Freigaben bei folgenreichen Aktionen. Auch Harness-Version, Kontext und Richtlinien beeinflussen das Ergebnis.

Governance vor dem Pilotprojekt prüfen

Beginnen Sie mit einem begrenzten, risikoarmen Workflow und geben Sie dem Agenten nur erforderliche Daten und Tools. Prüfen Sie Authentifizierungsbereiche, Freigaben, Dateiablage, Protokolle, Laufzeit, Subagenten-Grenzen sowie Stoppen und Fortsetzen. Bewerten Sie bei MCP jeden Server und jedes Tool als eigene Integration mit eigenen Berechtigungen und Fehlerbildern; das Protokoll selbst liefert keine Governance.

Die Vorschau kann den Bau eigener Orchestrierungsinfrastruktur verringern, schafft aber eine Plattformabhängigkeit, die gegen den Komfort abzuwägen ist. Dokumentieren Sie exportierbare Definitionen und Skills, Modellauswirkungen, Kosten nach Vorschau-Konditionen und einen Migrationsweg. Copilot-Produkte, Foundry Agent Service und Harness gehören zusammen, sind aber unterschiedliche Angebote.

Ein sinnvoller Pilot sollte die Übergaben zwischen Modell und Geschäftssystem festlegen: Welche Belege braucht ein Tool-Aufruf, welche Aktionen erfordern eine Freigabe, was wird protokolliert und wer verantwortet einen fehlgeschlagenen oder unvollständigen Lauf? Halten Sie Modell sowie Versionen von Harness und Skills zusammen mit den Testergebnissen fest. So lassen sich Kosten- und Leistungsrouting messen und Modellgrenzen von Problemen mit Tools, Berechtigungen oder Orchestrierung unterscheiden. Portabilität sollte anhand der tatsächlichen Konfiguration geprüft werden, nicht anhand des Begriffs „Multi-Modell“.

Quellen und weiterführende Informationen

Einen sachlichen Fehler melden oder eine Quelle vorschlagen? Redaktion kontaktieren.