GitHub Copilot-harnessen: en djupdykning i Copilot Studios nya motor

Microsoft har nyligen gjort sin nya motor för agentbygge i Copilot Studio allmänt tillgänglig. I översikten över Copilot Studios tre harnesses beskriver Microsoft den som det mest kapabla alternativet, byggt för resonemangstunga agenter och arbetsflöden som ska slutföra komplexa affärsprocesser.

Den nya motorn heter GitHub Copilot harness. Namnet leder till två naturliga frågor. Vad är egentligen en harness, och finns det en teknisk koppling till GitHub Copilot?

Vad är en harness?

En agent kan förenklat beskrivas som modell + harness. Modellen står för intelligensen och resonemanget. Harnessen är all programvara och infrastruktur runt modellen som bestämmer vad den får veta, vad den kan göra, hur handlingar exekveras och hur agentloopen styrs.

Det innebär att instruktioner, skills, verktyg, orkestrering, guardrails, observability och exekveringsmiljön är delar av harnessen. De ligger inte som separata huvudsystem bredvid den.

Finns det en koppling till GitHub Copilot?

Ja. Microsofts och GitHubs dokumentation ger tillsammans en ganska tydlig karta över hur tekniken hänger ihop.

GitHub Copilot agentic harness

GitHub beskriver GitHub Copilot agentic harness som en gemensam komponent i GitHub Copilot SDK. Samma komponent används i GitHub Copilot CLI, GitHub Copilot App, Copilot code review och flera andra upplevelser hos GitHub och Microsoft.

“The GitHub Copilot agentic harness is a single shared component of the GitHub Copilot SDK, which powers the GitHub Copilot CLI…”

Källa: GitHub Blog, Evaluating performance and efficiency of the GitHub Copilot agentic harness

Det viktiga här är att GitHub beskriver harnessen som en delad teknisk komponent, inte som något som enbart tillhör exempelvis Copilot CLI.

Kopplingen till Copilot Studio

Microsoft gör sedan kopplingen till den nya Copilot Studio-upplevelsen tydlig:

“The new GitHub Copilot harness, which uses the power of GitHub Copilot SDK to automate complex, agentic business processes.”

Källa: Microsoft, More powerful agents and workflows for autonomous business processes

Det innebär att Microsoft uttryckligen kopplar GitHub Copilot harness i Copilot Studio till GitHub Copilot SDK.

Redan tidigare beskrev Microsoft den nya orkestratorn som “built on a new coding harness and CLI layer”. Microsoft lyfte samtidigt fram starkare följsamhet till instruktioner, långvariga uppgifter och rekursiv exekvering. Orkestratorn beskrevs också som kapabel att hantera stora mängder innehåll och producera avancerade filresultat. Läs Microsofts presentation av den nya orkestratorn.

Tillsammans ger dokumentationen ungefär följande relation:

Viktig distinktion

Här är det lätt att blanda ihop två olika saker. Microsoft Agent Academy beskriver harnessen i Copilot Studio som “the runtime environment used by the agent” och skiljer den från “the GitHub Copilot coding assistant”.

GitHub Copilot coding assistant är den färdiga utvecklarprodukten som används i exempelvis VS Code. Copilot Studios GitHub Copilot-harness är det agentiska systemet runt modellen i Copilot Studio. Agent Academy använder alltså runtime environment i en bredare betydelse än bara sandlådan där kod körs.

Distinktionen motsäger inte SDK-kopplingen. Produkterna och användarupplevelserna är olika, samtidigt som Microsoft dokumenterar att Copilot Studio-harnessen använder GitHub Copilot SDK. Det som inte är offentligt dokumenterat är om Copilot Studio kör exakt samma binär eller exakt samma implementation av harnessen som GitHub Copilot CLI.

Trots att dokumentationen ger en tydlig bild av släktskapet berättar Microsoft betydligt mindre om vad som faktiskt finns bakom kulisserna. Vilka verktyg får agenten? Vad kan köras i sandlådan? Vilka bibliotek och färdiga instruktioner följer med från början? Den här artikeln öppnar den delen av harnessen och går igenom det som gick att observera i en verklig körning. Egna connectors, MCP-servrar och andra tillägg lämnas utanför så att standardmiljön blir synlig.

Underlaget kombinerar Microsofts beskrivning av sandlådan med en egen mätning av en körande agent. Mätningen gjordes den 18 augusti 2026 och har fingeravtrycket sha256:8557dcbd…. Den visar vad som gick att observera i just den miljön vid just det tillfället. Den är inte ett löfte om hur tjänsten alltid kommer att se ut.

Sandlådan är arbetsbänken

Sandlådan är den del av den övergripande harnessen där agenten kan arbeta med kod och filer under kontrollerade former. Den är alltså en isolerad och begränsad exekveringsmiljö: platsen där handlingar körs och där gränserna för vad de får komma åt upprätthålls.

Varför behövs den miljön? Språkmodeller är bra på att formulera kod, men mindre pålitliga när de ska räkna exakt eller generera stora, strukturerade filer direkt. Microsoft sammanfattar problemet väl i sin genomgång av sandlådan: “A model predicts a plausible result; it doesn't compute one.” Ett svar som ser ut som en giltig Excel- eller Word-fil behöver inte vara det.

Sandlådan överbryggar den skillnaden. GitHub Copilot-harnessen kan låta modellen formulera kod, köra den i containern, läsa resultatet och använda återkopplingen för nästa försök. Microsoft beskriver miljön som en tillfällig container med Python, lokala filer, förinstallerade bibliotek och skalverktyg.

Det gör att en summering kan räknas med Python, ett kalkylblad kan byggas som en riktig .xlsx-fil och ett dokument kan öppnas, förbehandlas och kontrolleras innan agenten svarar.

I byggvyn är Kunskap och Verktyg alltså ytor där skaparen för in externa förmågor. De ska inte blandas ihop med de interna standardverktyg som harnessen själv använder för att söka, läsa, redigera och köra kod.

Nätverksgränsen gäller sandlådan, inte hela harnessen. Harnessen kan fortfarande använda kunskapskällor och verktyg som ligger utanför containern. Externa anrop går genom de vägar som organisationen har konfigurerat och kan därmed omfattas av plattformens dataprinciper och övriga styrning.

Den tillfälliga arbetsytan är inte ett permanent filarkiv. En fil som ska leva vidare måste lämnas till användaren eller sparas med ett konfigurerat verktyg. Agentens minne gör inte sandlådans arbetsyta beständig mellan konversationer.

Python-paketen visar vad arbetsbänken är byggd för

Mätningen hittade 99 installerade Python-paket i sandlådans exekveringsmiljö. Inventariet är särskilt starkt inom dokument, dataanalys, visualisering och bildbehandling. Det är precis de områden där det är värdefullt att låta kod göra arbetet i stället för att be modellen gissa fram resultatet.

Det här visar vilka byggstenar som fanns tillgängliga, men inte vilket bibliotek agenten väljer i varje körning. Den säkra slutsatsen är att exekveringsmiljön innehöll förinstallerade bibliotek för att skapa, läsa och bearbeta de filformat som Copilot Studio säger sig stödja. De ska inte blandas ihop med harnessens interna verktyg, som agenten anropar för att exempelvis läsa filer eller köra kommandon.

Två paket sticker ut av ett annat skäl:

• dracarys 0.1.0
• github-copilot-sdk 1.0.7

Båda paketens närvaro är observerad. Rapporten beskriver dracarys som en del av Copilot Studios förbättrade orkestrator och github-copilot-sdk som ett sätt att styra GitHub Copilot CLI över JSON-RPC. De beskrivningarna kommer från mätverktygets kurerade paketkatalog, inte från paketens närvaro i sig.

Fyndet av github-copilot-sdk passar väl ihop med den dokumenterade SDK-kopplingen. Det bevisar fortfarande inte att Copilot Studio kör samma binär som GitHub Copilot CLI, eller att just det installerade Python-paketet ligger i den aktiva anropskedjan. Paketlistan visar vad som finns i miljön, inte hela arkitekturen runt den.

Tolv verktyg visar kodagentens arv

I mätningen syntes tolv interna standardverktyg. Elva fångades med fullständigt schema. För list_bash fanns endast metadata från verktygslistningen, så beskrivningen av just det verktyget har svagare underlag.

I stället för en lång lista blir strukturen tydligare om verktygen grupperas efter vad de gör:

Det är svårt att titta på den verktygsytan utan att se arvet från en kodagent. Agenten kan först orientera sig med glob, grep och view, sedan ändra en fil med create eller edit, köra resultatet med bash och fortsätta läsa utdata genom read_bash. Harnessen får därmed en återkopplingsslinga där varje observation kan styra nästa handling.

bash är mer än en enkel kommandoruta. Schemat skiljer mellan synkron och asynkron körning, har en inledande väntetid på 30 till 600 sekunder och kan hålla en bakgrundsprocess vid liv med detach. Varje kommando startar samtidigt i en ny process. Byte av arbetskatalog och miljövariabler lever därför inte automatiskt vidare till nästa anrop. För längre jobb måste agenten bära med sig rätt sökväg och följa sessionen uttryckligen.

Sökverktygen har också tydliga gränser. view kortar som standard filer större än 20 KB om agenten inte anger ett radintervall eller begär hela filen. grep kan begränsa sökningen efter filtyp, globmönster och antal träffar. Det uppmuntrar ett mönster där agenten först hittar rätt område och därefter läser den lilla del som behövs, i stället för att fylla kontexten med hela arbetsytan.

Filverktygen är också avsiktligt försiktiga. create skriver inte över en befintlig fil, och edit kräver att texten som ska ersättas är entydig. Det minskar risken för att agenten förstör mer än den avsåg när den arbetar självständigt i flera steg.

Alla tolv ska dock inte likställas med kommandon som körs inne i containern. knowledge_search_web är en tjänst vars träffar kan vara kompletta webbutdrag eller kortare dokumentutdrag. Schemat har därför stöd för fortsättningsanrop när ett första utdrag inte räcker. skill laddar instruktioner i harnessen, medan parallel bara får samla verktygsanrop som är säkra att köra samtidigt. Verktygslistan visar vad agenten kan anropa, inte att varje anrop delar samma exekverings- eller säkerhetsgräns.

Åtta inbyggda skills följde med

Rapporten visar nio skills, men en av dem är agent-harness-explorer-plus, som vi själva lade till för att genomföra mätningen. De åtta övriga låg redan i miljön:

• search-before-answer
• analyzing-csv
• analyzing-xlsx
• analyzing-docx
• analyzing-pptx
• analyzing-pdf
• analyzing-html
• analyzing-markdown

Den lokala mätningen fångade instruktionstext från samtliga SKILL.md-filer under /app/skills/. PDF-skillen nådde dock mätningens lagringsgräns på 40 000 tecken, så just den instruktionstexten är inte fullständig. Materialet är ändå mer intressant än en vanlig funktionslista: det visar inte bara vilka färdigheter som finns, utan också vilket arbetssätt plattformen instruerar agenten att följa.

search-before-answer styr när agenten ska söka

Beskrivningen börjar med REQUIRED FIRST. Skillen ska användas innan agenten besvarar frågor som kan avgöras från en ansluten organisationskälla, även när frågan låter generell och inte nämner någon källa. Den fullständiga instruktionen är 4 801 tecken och öppnar med kravet “Your answer must be complete, exactly identified, verified, and cited.”

Instruktionen kan sammanfattas i åtta steg:

Det visar att en del av agentens grundning i källor ligger i en läsbar och utbytbar skill, inte bara i en osynlig orkestrator. Skillen fungerar som ett operativt protokoll: sök först, kontrollera omfattningen, verifiera och källhänvisa.

Analys-skills förbehandlar innan de läser

De sju analyzing-*-skillsen täcker CSV, Excel, Word, PowerPoint, PDF, HTML och Markdown. De har olika regler för respektive format, men delar ett centralt mönster: råfilen förbehandlas till mindre, sökbara artefakter innan agenten börjar svara.

Den lokala mätningen fångade drygt 108 000 tecken instruktioner i de sju analys-skillsen. Detaljerna visar att de inte är generiska filbeskrivningar, utan formatanpassade kontrollprogram:

analyzing-docx skapar bland annat manifest.json, converted.md, comments.json och ett radbaserat index över bilder. Kommentarernas stabila Office-id och markerade text bevaras separat. När svaret beror på en bild räcker det inte att läsa bildens metadata. Skillen kräver att agenten öppnar själva bildfilen och redovisar osäkerhet om etiketten inte går att läsa säkert.

analyzing-pptx använder slides.md som primär artefakt och plockar även ut inbäddade Excel-filer. Om frågan gäller exakta tal och presentationen innehåller en sådan arbetsbok ska den kontrolleras direkt, eftersom en slide kan visa en sammanfattning medan källdatan innehåller hela tidsserien. För bildtunga slides finns en bestämd reservväg från OCR till extraherad bild och slutligen en renderad slide.

PDF-skillen är den största av de sju och nådde mätningens lagringsgräns på 40 000 tecken. Den innehåller separat dirigering för tabeller, textlager, OCR och visuella sidor samt regler för hur värden, enheter, tecken och spatiala positioner ska verifieras. Det är ett tydligt exempel på hur mycket praktisk felhantering som kan ligga bakom en enda skill.

Poängen är inte bara att konvertera filformat. Förbehandlingen skapar ett index som låter agenten läsa den del som behövs, kontrollera exakta värden och vid behov gå tillbaka till bilden eller tabellen. Det är kontexthantering tillämpad på dokument: börja med en karta över innehållet och hämta sedan rätt detalj.

Instruktionerna innehåller också konkreta skydd mot vanliga fel. CSV-skillen skiljer exempelvis mellan en exakt matchning och en bred textsökning som råkar fånga East, Eastern och EU-East. Excel-skillen varnar för att summera en rubrikrad tillsammans med dess underliggande rader och kräver att källraderna bakom en summa listas före slutsatsen. HTML- och Markdown-skillsen förbjuder agenten att sluta efter första relevanta tabellen när frågan gäller flera filer eller hela mängden.

Det är här skillsen blir arkitektoniskt intressanta. De tillför inte bara domänkunskap, utan paketerar arbetsordning, verifiering och felhantering i instruktioner som laddas när ett visst filformat dyker upp.

Så gjordes mätningen

agent-harness-explorer-plus är den skill som sonderade miljön och byggde rapporten. Den är en vidareutveckling av Microsoft CAT:s agent-harness-explorer, publicerad under MIT-licens. Microsofts upphovsrättsnotis finns kvar i paketet.

Grundregeln är enkel: observera före du antar. Om en kontroll inte kan genomföras markeras resultatet som unverified eller not-visible, inte automatiskt som unsupported.

Som standard är sonderingarna passiva. Aktiva kontroller kan skriva en temporär fil, starta en process eller göra ett HTTPS-anrop. De körs bara med flaggan --active-safe. I den mätning som artikeln bygger på användes inte den flaggan. Därför är följande tre egenskaper i körmiljön markerade som unverified i rapporten:

• runtime.filesystem:write
• runtime.subprocess:exec
• runtime.network:https

Det motsäger inte uppgiften om blockerad nätverksutgång. Det betyder bara att mätverktyget inte testade nätverket aktivt. Påståendet om sandlådans nätverksgräns kommer från Microsofts dokumentation.

Kör inspektionen i din egen agent

Du kan återskapa mätningen i Copilot Studio med ZIP-paketet ovan. Flödet följer Microsoft CAT:s guide till Agent Harness Explorer, men bilderna nedan visar den nya byggupplevelsen och vår utökade version av skillen.

Vad mätningen säger och inte säger

Den tydligaste slutsatsen är att GitHub Copilot-harnessen arbetar mer som en kodagent än som en traditionell chattbot. Den har en tillfällig arbetsyta, kör kod, söker och redigerar filer, följer processer över tid och laddar specialiserade instruktioner när uppgiften kräver det.

Fyra fynd bär den slutsatsen:

• Sandlådan är en isolerad exekveringsmiljö med Python och lokala filer, men utan utgående nätverksväg.
• De tolv inbyggda verktygen domineras av skal-, sök- och filoperationer.
• De 99 Python-paketen ger färdiga byggstenar för dokument, data, diagram och OCR.
• De åtta inbyggda skillsen beskriver inte bara vad agenten ska göra, utan också hur den ska söka, förbehandla och verifiera.

Mätningen visar däremot inte hela tjänstens interna arkitektur. Den bevisar inte att Copilot Studio kör samma harnessimplementation som GitHub Copilot CLI, att varje installerat paket används i den aktiva anropskedjan eller att dagens verktygslista kommer att vara oförändrad i morgon.

Det är därför rapporten är mest värdefull som en daterad ögonblicksbild. Den gör den dolda arbetsmiljön synlig nog för att resonera om, utan att låtsas att observationer är produktlöften.

Vill du se det som kopplas utanför sandlådan finns nya Copilot Studio, med byggblock, kostnader och skillnader mot standardharnessen. Work IQ MCP går igenom den vanligaste externa anslutningen. För de bredare agentbegreppen finns AI-agenter och agentiska system.

---

Om den publicerade rapporten. Microsofts inbyggda SKILL.md-filer är förkortade i webbversionen till rubrikstruktur och de direktiv som diskuteras ovan. Verktygsscheman, paketinventarium och källmärkningar finns kvar. Den fullständiga lokala mätningen användes vid faktagranskningen av artikeln.