LLM, agent, harness och editor – vad är skillnaden?
Modellen beräknar svar, agenten driver en uppgift och harnesset håller ihop arbetet. Se hur Claude Code, Codex, Hermes och Microsofts agenter överlappar.
Kort sagt
En LLM är modellen. En agent är ett uppgiftsdrivet system. Ett harness är körningen och kontrollen runt modellen. En editor är arbetsytan där du kan möta dem.
Det är olika roller, inte fyra lådor som varje produkt måste passa i. Claude Code och Codex kan både kallas agenter och beskrivas som produkter med egna harness. VS Code och Cursor erbjuder en arbetsyta men också agentfunktioner.
Det är därför ”vilken AI använder du?” inte alltid har ett enda svar.
Så hänger delarna ihop
En förenklad rollkarta, inte en säkerhetsgräns eller kvalitetsranking. Tryck på bilden för att öppna och förstora den.
Ett företag som liknelse
Tänk dig att ett företag ska ta hand om en felanmälan. Det behövs kompetens, någon som driver ärendet, verktyg och rutiner samt en arbetsplats. Om många ska använda lösningen behövs också gemensam drift och förvaltning.
Det är en liknelse, inte en beskrivning av mänsklig intelligens. Delarna nedan är roller som samverkar, inte steg i en rak kedja.
1. Modellen – kompetensen
Modellen bidrar med förmågan att tolka text, resonera över underlag och formulera förslag. I liknelsen motsvarar den kompetensen som används i arbetet, inte en komplett medarbetare.
Exempel: föreslå vad en felanmälan gäller. Det betyder inte att modellen har registrerat ett ärende eller kontaktat någon. ”Modellen tänker” är en förenkling; den beräknar utdata och kan ha fel.
2. Agenten – den uppgiftsdrivna medarbetaren
Agenten använder modellen i ett system som driver uppgiften framåt: tar in underlag, väljer nästa steg, använder tillåtna verktyg och kontrollerar resultat.
Exempel: läsa felanmälan, föreslå kategori och skapa ett ärende om systemets regler och åtkomst tillåter det. Medarbetarliknelsen innebär inte mänskligt omdöme eller ansvar; ansvaret ligger kvar hos människor och organisationen.
3. Harnesset – verktygslådan och arbetsrutinerna
Harnesset är programvaran som håller ihop körningen. Den ger modellen rätt sammanhang, exponerar verktyg, skickar tillbaka resultat och hanterar exempelvis loggning och stopp. Instruktioner och minnesfunktioner kan ingå eller kopplas in.
Exempel: erbjuda verktyget ”skapa ärende”, validera indata och kräva godkännande innan något skickas. Verkliga behörigheter måste också begränsas i identitet, API och körmiljö – en instruktion är inte en säkerhetsgräns.
4. Arbetsytan – kontoret
Arbetsytan är där människan möter systemet. VS Code kan vara kontoret för kodarbete; en terminal, webbapp eller Teams kan vara andra ingångar.
Exempel: du granskar agentens förslag i en chatt eller kodeditor. Arbetsytan avgör inte ensam vilken modell eller agentmotor som används.
5. Agentplattformen – organisationens gemensamma drift
När flera ska bygga och använda agenter behövs en plats för att skapa, köra, övervaka och förvalta dem. Microsoft Foundry Agent Service är ett exempel på hanterat plattformsstöd.
Exempel: verksamheten förvaltar flera agenter med modellkopplingar, verktyg och uppföljning. Plattformen kan tillhandahålla delar av harnesset, men är inte ett obligatoriskt femte steg efter VS Code. En lokal agent behöver inte Foundry.
Minnesregel: modellen bidrar med förmåga, agenten driver uppgiften, harnesset håller ihop körningen, arbetsytan ger kontakt och plattformen hjälper organisationen att förvalta lösningen.
Olika typer av LLM – flera egenskaper samtidigt
Claude, GPT och Grok är modellfamiljer, inte samma sak som Claude Code, Codex-appen eller Grok Bot. En specifik modell har ett mer precist namn och en version.
Modeller kan jämföras längs flera axlar:
- Bred eller specialiserad: en allmän modell kan hjälpa med många uppgifter; andra är särskilt anpassade för exempelvis kod. Specialisering garanterar inte bäst resultat på just ditt arbete.
- Instruktionsanpassad och resonemangsinriktad: instruktionsträning gör modellen mer användbar som assistent. Vissa modeller eller lägen använder mer beräkning vid svarandet för svårare uppgifter. Det är ingen garanti för korrekthet, och egenskaperna utesluter inte varandra.
- Text eller multimodal: vissa modeller hanterar även bild, ljud eller andra datatyper. Ett bildverktyg i en app betyder inte nödvändigtvis att samma språkmodell genererar bilderna.
- Mindre eller större: olika krav på minne, kostnad och svarstid. ”Liten” är relativt; testa uppgiften i stället för att välja på storlek ensam.
- Öppna vikter eller sluten tjänst: tillgång till vikterna kan möjliggöra egen drift, beroende på licens och hårdvara. Öppna vikter betyder inte automatiskt öppen träningsdata eller obegränsad användning.
- Lokal eller molnbaserad körning: beskriver var beräkningen sker, inte en egen intelligensklass. En lokal agent kan använda en molnmodell, och en molnagent kan arbeta med filer på en separat dator.
Sökning, minne och tillgång till dina filer är ofta funktioner i produkten runt modellen. Utgå inte från att modellen själv alltid har aktuell internetkunskap eller minns tidigare sessioner.
Samma byggdelar, olika paketering
Jämför inte bara produktnamnen. Fråga vad som redan är färdigbyggt och vad du själv måste konfigurera eller förvalta.
- Hermes och OpenClaw: generella agentmiljöer med arbetsloop, verktyg och anslutningar. Du väljer modellkoppling och åtkomst; de är inte färdiga verksamhetsmedarbetare utan konfiguration.
- Claude Code och Codex: agentprodukter inriktade på kodarbete. De kombinerar arbetsloop och kodverktyg, och kan mötas via terminal eller utvecklingsmiljö.
- VS Code med GitHub Copilot: en arbetsyta med assistent- och agentfunktioner. VS Code ensamt är editorn; agentfunktionerna tillkommer genom den aktuella integrationen.
- Cursor: kombinerar utvecklingsmiljö och kodagentfunktioner i samma produkt.
- Microsoft Foundry: plattformsstöd för att bygga och drifta agentlösningar, inte bara en färdig kodassistent.
Flera av dessa kan använda liknande modellfamiljer och samma externa resurser. Det gör dem inte identiska: verktyg, arbetsloop, sammanhang, drift och åtkomst kan skilja sig.
Claude Code
En agentprodukt för kodarbete, med egen arbetsloop och verktyg.
Överlapp: Har harnessfunktioner och flera användarytor, bland annat terminal och editorintegration. Claude-modellen är en annan del av lösningen.
Codex
OpenAI:s agentprodukt för bland annat programutveckling; Codex CLI körs i terminalen.
Överlapp: Namnet används i flera produkt- och modellkontexter. Skilj exempelvis Codex CLI, dess valda modell och en tjänst där en uppgift körs.
OpenClaw
En självhostad gateway och agentplattform med kanaler, sessioner och verktyg.
Överlapp: Kopplar användarytor till agentkörning och modeller. Är inte i sig en LLM; val av molnmodell kan fortfarande skicka data utanför datorn.
Hermes Agent
Nous Researchs agentplattform med verktyg, skills, minne och flera användarytor.
Överlapp: Innehåller ett harness och kan ansluta till olika modellleverantörer. Här avses agentprodukten, inte modellfamiljer med Hermes i namnet.
Visual Studio Code
En kodeditor och värdyta för utvecklingsverktyg.
Överlapp: Med AI-funktioner kan den vara värd för agentkörning och olika harness. VS Code är inte en språkmodell och är inte samma produkt som Visual Studio.
Cursor
En AI-inriktad utvecklingsmiljö och kodagentprodukt.
Överlapp: Kombinerar editor, agentfunktioner, verktyg och modellval. Namnet betyder därför mer än en editor men inte en enda bakomliggande LLM.
Grok Bot, ofta skrivet Grokbot
En agentprodukt för delegerat arbete i appar och verktyg, med molndator enligt x.ai.
Överlapp: Skilj produkten från Grok-modellerna och Grok-chatten. Flera namngivna botar betyder inte automatiskt separata säkerhetsmiljöer.
Detta är ingen kvalitetsranking. Samma modell i två olika harness kan ge olika arbetsresultat eftersom kontext, verktyg, teståterkoppling och regler skiljer sig.
Vad betyder ”agent” hos Microsoft?
Microsoft använder ordet på flera nivåer. En agent behöver inte vara en självständig digital medarbetare som arbetar i bakgrunden: den kan vara en specialiserad kunskapsassistent som svarar när någon frågar.
Microsoft 365 Copilot och dess agenter
Användaryta och assistentupplevelse för arbetsuppgifter och organisationskunskap. En agent kan avgränsas till ett område eller en uppgift.
Deklarativ agent
Du beskriver instruktioner, kunskap och eventuella åtgärder; Copilots orkestrering och modeller används. Du bygger inte automatiskt ett eget harness.
Custom engine-agent
Du väljer eller bygger egen orkestrering och modellkoppling i stället för att enbart använda Copilots motor. Agenten kan ändå göras tillgänglig i Microsoft 365.
Copilot Studio
En lågkodsplattform för att skapa och hantera agenter och arbetsflöden samt koppla data och åtgärder. Det är bygg- och driftstöd, inte en viss LLM.
Microsoft Foundry Agent Service
En hanterad Azure-plattform för att bygga, driftsätta och följa upp agenter. Erbjuder runtime, verktyg och modellkoppling; i vissa upplägg kör du egen agentkod där.
GitHub Copilot
Ett utvecklarinriktat erbjudande med kodhjälp och agentfunktioner, bland annat i VS Code. Inte samma sak som Microsoft 365 Copilot i Word eller Teams.
Teams är ofta kanalen, inte själva agentmotorn. Att två agenter syns i Teams betyder inte att de har samma modell, verktyg eller behörigheter.
Agent Builder i Microsoft 365 är en enklare skaparyta för avgränsade agenter. Mer avancerade åtgärder kan kräva Copilot Studio eller kodbaserad utveckling. Exakt tillgång beror på funktion, licens och organisationens inställningar.
Delade resurser – inte en egenskap hos en enda agent
Filer, dokument, databaser och API:er ligger ofta utanför agentprodukten. Flera agenter kan använda samma resurser genom olika integrationer.
Påhittad illustration: en lokal agent i Hermes och en agent i Foundry kan båda läsa samma ärendesystems API, om respektive integration och identitet har rätt åtkomst. En kodagent kan arbeta mot samma kodrepo från VS Code eller terminalen.
Det betyder inte att åtkomst följer med automatiskt. Autentisering, behörighet, dataskydd och godkännande måste ordnas för varje anslutning. Att en fil syns i Teams innebär inte att varje agent får läsa den.
Ett exempel som visar överlappet
Påhittad illustration: ”Rätta ett fel i vår webbplats och visa att det fungerar.”
- Arbetsyta: du ger uppgiften i VS Code.
- Agent och harness: exempelvis Codex läser filer, väljer nästa steg och hanterar arbetsloopen.
- Modell: den valda modellen föreslår ändringar och verktygsanrop.
- Verktyg och exekveringsmiljö: filer ändras och tester körs med sessionens faktiska åtkomst.
- Kontroll: du granskar diff och testresultat innan publicering.
Byt VS Code mot terminalen och uppgiften kan fortfarande utföras av samma agentprodukt. Byt harness men behåll modell och arbetsbeteendet kan förändras. En separat agent i Microsoft 365 kan samtidigt sammanfatta releaseunderlaget – utan att därför få rätt att ändra koden.
Fem frågor innan du jämför eller ger åtkomst
- Vilken modell används? Namn, leverantör och var den körs.
- Vad är agentens uppgift? Kunskapssvar, förslag eller verkliga ändringar?
- Vilket harness driver arbetet? Kontext, verktyg, stopp och loggning.
- Var körs verktygen och med vems identitet? Din dator, molndator eller organisationens tjänster?
- Vad kräver godkännande? Att kunna utföra något är inte samma sak som att få göra det.
Skriv gärna: ”Vi använder [modell] i [agentprodukt/harness], via [arbetsyta], med [verktyg och behörighet].” Då blir jämförelsen användbar.
Viktigaste fallgropen
Att jämföra namn från olika lager: ”Claude eller Cursor?”, ”GPT eller Hermes?”, ”VS Code eller agent?”. De kan ingå i samma lösning. Bedöm också åtkomst separat: en namngiven agent, en profil eller en Git-branch är inte automatiskt en säkerhetsgräns.
Vad du kan göra nu
Välj ett AI-verktyg du använder. Fyll i meningen ovan och markera vad du inte vet. Ta reda på var data och verktyg körs innan du ger systemet åtkomst till känslig information eller rätt att ändra något.