Copilot Harness: Microsoft macht die Steuerungsschicht um das KI-Modell zur Plattform

Microsoft hat in dieser Woche den „Microsoft Copilot Harness“ veröffentlicht. Bei einem Harness handelt es sich um den Rahmen für das Sprachmodell, der alle Nutzer- und Schnittstellen-bezogenen Aufgaben organsiert. Microsoft verspricht mit dieser Neuerung mehr LLM-Wahlmöglichkeiten.

Ein Harness (auf Deutsch: Geschirr) ist die Steuerungsschicht, die alle Aufgaben rund um das „Kern“-Sprachmodell organisiert. Bisher wurde diesem Aspekt wenig Aufmerksamkeit zuteil, da sich fast alles um die rasante Entwicklung bei den LLMs dreht.

Harness – der Rahmen um das Sprachmodell

Der Harness legt sich um das Sprachmodell, er gibt Agenten Anweisungen, Kontext, eine Ausführungsumgebung und Kontrollen. Bildlich gesprochen ist das Sprachmodell der Facharbeiter, der Harness stellt den Arbeitsplatz dar, mit Aufgabenbeschreibung, Werkzeugen, Zugriffsrechten und Regeln. Dazu gehören Skills, also wiederverwendbare Arbeitsanweisungen, aber auch Schnittstellen zu externen Systemen, angefangen beim Betriebssystem bis hin zur MCP(-Model Context Protocol)-Anbindung an beliebige externe Apps.

Das Thema gewinnt durch das Tempo des Marktes an Bedeutung. Denn solange die KI-Orchestrierung an ein bestimmtes Modell gebunden ist, bedeutet jeder Modellwechsel Umbauarbeit. Sobald aber der Harness gleich bleiben kann, lässt sich das Modell einfach austauschen. Damit wird der Harness zur stabilen Schicht, und das Modell zur Wahlentscheidung.

Neu: Harness als verwalteter Dienst in Foundry

Neu ist, dass Microsoft diese Schicht als Dienst anbietet. In Foundry betreibt Microsoft die Agentenschleife – den wiederkehrenden Ablauf aus Planen, Werkzeugaufruf und Auswertung – sowie die Sandbox, eine abgeschottete Umgebung für Dateien und Code. Kunden liefern Wissen, Abläufe, Werkzeuge und Modellwahl. Wer den Harness selbst betreiben will, kann das SDK herunterladen.

Laut Microsoft-Ankündigung läuft der Harness unternehmensweit unter Copilot Code, Copilot Studio, der GitHub-Copilot-App, der Kommandozeile und VS Code. Er unterstützt mehr als 20 Modelle sowie eigene API-Schlüssel und leitet Aufgaben je nach Bedarf an passende Modelle weiter.

Diese drei Punkte sind für Microsoft-Kunden aktuell interessant:

  • Kosten: Die Laufzeit des Harness ist bis zum 1. Dezember 2026 kostenlos. Danach wird die Sandbox nach Verbrauch abgerechnet. Modellnutzung und separat berechnete Werkzeuge kosten wie bisher extra.
  • Umbenennung in Copilot Studio: Der bisherige „GitHub Copilot Harness“ heißt nun Microsoft Copilot Harness. Bestehende Agenten laufen unverändert, Funktionen und Abrechnung bleiben gleich.
  • Festlegung: Der Harness wird beim Anlegen eines Agenten gewählt. Ein späterer Wechsel wird in Foundry derzeit nicht unterstützt.

Harness, nicht Modellwechsel bringt Performance

Microsoft hat die Leistung des Copilot-Harness mit dem Standard-Harness verglichen. Hierbei kam heraus, dass ein Modellwechsel die Leistung kaum verändere, ein Harness-Wechsel dagegen deutlich:

  • + 10,8 Prozentpunkte mit einem OpenAI-Modell
  • + 22,1 mit einem Anthropic-Modell

Nach einem fehlgeschlagenen Werkzeugaufruf arbeiteten die Agenten in 84 bis 91 Prozent der Fälle weiter, im Standard-Harness in weniger als 7 Prozent. Trotz fast doppelt so vieler Modellaufrufe sanken die Nettokosten der Eingabeverarbeitung um 15 bis 21 Prozent, weil das Caching besser greift.

(Hierbei handelt es sich um Microsoft-Angaben aus Tests und Produktivdaten. Die Ergebnisse hängen von Szenario, Modell und Konfiguration ab.)

Wahlmöglichkeit bleibt weiter bestehen

Microsoft betont, dass auch mit Einführung des Copilot-Harness die Plattformen offen blieben, eigene Harnesses und Frameworks ließen sich weiter einbinden. Der Copilot-Harness sei ein „starker Standard“. Ein gemeinsamer Unterbau soll es zudem erleichtern, Skills, Werkzeuge und MCP-Anbindungen zwischen Copilot, Low-Code in Copilot Studio und Pro-Code in Foundry zu übertragen.

Der Standard-Harness in Copilot Studio bleibt für feste, regelbasierte Abläufe weiter sinnvoll. Laut Microsoft-Dokumentation ist keiner der beiden grundsätzlich besser. Für kurze, klar umrissene Aufgaben kann der neuere Harness unnötig Zeit und Credits verbrauchen. Ein funktionierender Agent muss also nicht umziehen.

Quellen:

Die offiziellen Ankündigungen sind auf Microsoft-Blog und Foundry-Blog zu finden.

Schreiben Sie einen Kommentar

Ihre E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert