Moonshot AI har lanceret Kimi Work, en desktop‑agent til macOS og Windows, der kører lokalt, læser filer, styrer brugerens rigtige browser og planlægger jobs (MarkTechPost). Kernen er en WebBridge‑udvidelse, en cron‑scheduler og adgang til lokale mapper (MarkTechPost). Der henvises samtidig til community‑omtaler af, at Kimi Work kører på Moonshots K2.6‑model og kan orkestrere en swarm på op til 300 sub‑agenter (MarkTechPost, community‑rapporter).
Hvorfor vigtigt. Lokal kørsel giver adgang til de faktiske filer og sessioner, som arbejdsgange i virkeligheden afhænger af. Det er også her, IT‑drift for alvor bliver en faktor. Browserstyring med arvede cookies er effektivt, men kræver en anden sikkerhedsdisciplin end hosted sandkasser. Moonshot er Beijing‑baseret, og appen kan hentes som installer (MarkTechPost).
Hvad Kimi Work gør i praksis
MarkTechPost beskriver fire byggesten: en agent‑swarm til parallelisering, WebBridge der arbejder i din faktiske browser med arvede logins, en cron‑motor til tidsstyrede eller betingede jobs, og lokal fil‑ samt Python‑adgang, hvor ændringer kræver brugerens godkendelse (MarkTechPost).
Eksemplerne i kilden er jordnære: dokumenttriage på en mappe med kvartalsrapporter, webindsamling via WebBridge af historiske priser for udvalgte tickers med efterfølgende Python‑normalisering til Excel, planlagte morgenbriefs med Keep Computer Awake slået til, og generering af præsentationer i native Office‑formater (MarkTechPost). Det er workflows, vi genkender fra kundeteams, som ofte bare mangler den sidste automatisering mellem filsystem, browser og rapport.
K2.6, MoE og hvad tallene betyder
MarkTechPost gengiver, at uafhængige omtaler kobler Kimi Work til K2.6, Moonshots open‑weight MoE‑model fra 20. april 2026 (MarkTechPost, community). K2.6 beskrives som aktiverende ca. 32 mia. parametre per token og med et kontekstvindue på 256k tokens (MarkTechPost). Dertil nævnes op til 4.000 koordinerede skridt i swarm‑flowet (MarkTechPost). Hvis de specifikationer står til troende, forklarer de, at lange, trinvise opgaver kan holdes i tråd uden at klippe konteksten i stykker.
MoE betyder, at kun udvalgte eksperter i modellen aktiveres for hvert token. Det sænker beregning versus en fuldt tændt model. Men 32B aktive parametre er stadig tungt for en klientmaskine. Snilld‑estimat: RAM‑behovet kan vokse markant ved paralleliseret læsning, lange kontekster og mange midlertidige filer. Det bygger på vores tests af lignende åbne modeller og er ikke Moonshots officielle tal.
Agent‑swarm i praksis
Moonshot angiver, at Kimi Work kan skalere til 300 sub‑agenter (MarkTechPost). Pointen er ikke at køre 300 på en bærbar, men at splitte opgaver og køre dele parallelt, mens en koordinator samler resultater. Det kan sænke ventetiden på store dokumentmængder og øge robusthed, fordi fejl kan isoleres.
Tradeoffs. Flere underopgaver skaber disk‑ og netværksstøj. I en anonym Snilld‑pilot så vi CPU‑spikes fra Python‑tråde, der parsede PDF og skrev midlertidige filer – ikke fra selve modelberegningen. Snilld‑estimat: en 8‑16‑kerners CPU og 32‑64 GB RAM er et fornuftigt startpunkt til seriøse flows. Vi efterlyser et officielt hardwareprofil‑ark fra Moonshot.
WebBridge og adgang i den rigtige browser
WebBridge arbejder i brugerens rigtige browser og arver dermed sessioner, cookies og login (MarkTechPost). Den kan søge, scrolle, hente data og udfylde formularer på tværs af faner (MarkTechPost). Det åbner døre til interne systemer og tredjepartsværktøjer, som i forvejen er åbne i browseren.
Det stiller krav til governance. I en Snilld‑pilot satte vi eksplicit godkendelse på, før agenten måtte gå bag SSO på en kundes portal, og vi loggede handlinger til SIEM. Det tog lidt tid at sætte op, men sparede os for revisionstråde senere.
Scheduler, langkørende jobs og drift
Kimi Work har en indbygget cron‑motor, der kan trigge LLM‑kald, Python eller shell‑scripts, og en Keep Computer Awake‑indstilling til natlige jobs (MarkTechPost). Mere behøver de fleste læsere egentlig ikke vide – pointen er, at planlagte jobs flytter ansvar over på endpoint‑politikker.
Set fra drift: Hvor må credentials ligge, skal maskinen på strøm for natkørsler, hvem må oprette jobs, og hvordan spejles logning. Vi anbefaler kobling til eksisterende MDM, så netværk, strøm og script‑eksekvering styres uden at kvæle fleksibiliteten.
Data og filer – godkendelser og skrivegrænser
Agenten kan læse monterede mapper og køre Python i baggrunden; originale filer ændres ikke uden brugerens accept (MarkTechPost). God praksis. Men hvordan ser selve godkendelsen ud – modal, notifikation eller batch? Det fremgår ikke (rapporteringshul).
I praksis bør skriveadgang begrænses til en arbejdsmappe, som er dækket af backup og versionsstyring, og hvor concurrent writes ikke kolliderer med andre brugere. Små ting, men det er her supporten ellers løber stærkt.
Finansdata ud af boksen
Kimi Work nævnes som pre‑integreret med markedsdata for A‑aktier, Hong Kong og amerikanske aktier (MarkTechPost). Det kan afkorte POC‑tiden for analyseteam, fordi man kan prøve flows uden at købe eller integrere en feed først.
Men kilder, licens og opdateringsfrekvens er ikke beskrevet i detalje (rapporteringshul). Vores råd: behandl data som demo/pre‑research, til compliance er på plads kontraktuelt.
Sikkerhed og governance før udrulning
Overvej tre ting fra start: hvem agenten må handle som i browseren, hvilke domæner der er tilladt, og hvor granuleret filadgang skal være. Åbn så lidt som muligt. Udvid efter behov. Det skaber ro i både sikkerhed og support.
Pragmatisk tjekliste, som vi ville bruge i en pilot
- Least privilege‑mapper: Montér kun arbejdsmapper, aldrig hele disken.
- WebBridge allow‑liste: Definér domæner, agenten må styre, og log hændelser.
- Ephemeral sessioner: Undgå langlivede cookies i automatiserede flows.
- EDR/SIEM: Spejl agent‑ og browserlogs til central overvågning.
- Network egress: Begræns udgående trafik for agentens processer.
- Approval‑politik: Kræv godkendelse ved alle skriveoperationer uden for arbejdsmappe.
- Power policy: Kræv strøm og vågen tilstand for natlige cron‑kørsler.
Sådan ville vi designe en pilot
Vi starter i en isoleret VM eller en udviklings‑workstation med overvåget netværk. Første uge: fælles workshop om opgaver, datasæt og risici. WebBridge testes mod ikke‑produktionskonti. Vi måler CPU, RAM og IO per job for at undgå at udmatte maskiner.
Uge 2‑4: tre udvalgte flows i drift – dokumenttriage, et morgenbrief via cron og en webindsamling fra åbne kilder. Output kvalitetssikres manuelt, før noget skriver til delte mapper. Uge 5: nøgtern beslutning om skalering. Snilld kan stå for sikkerhedsassessment, governance‑skabeloner, SSO/MDM‑integration og træning, så piloten ikke løber af sporet.
Sammenligning med cloud‑agenter
Lokale agenter vinder på nærhed til filer og sessioner. Hosted vinder på skalerbarhed og central styring. I praksis ender mange med en hybrid: klient til research tæt på brugerens miljø, sky til tunge batchkørsler og delte repos. Det er ikke en værdikamp – det er to værktøjskasser.
Som kontekst har Microsoft åbnet SkillOpt, et rammeværk til at optimere agenters skills‑filer uden at ændre modelvægte (VentureBeat). For enterprise betyder det, at man kan løfte præcisionen i agentflows via bedre instrukser – nyttigt uanset om man vælger Kimi Work eller noget tilsvarende.
Hvor giver det reelt afkast
Tre cases, hvor vi ser tydelige gevinster: 1) dokumenttriage i regulerede sektorer med mange PDF‑rapporter, 2) research og datanoter fra betroede portaler via WebBridge, 3) faste morgenbriefs i salgsorganisationer, hvor cron samler nyheder, pipeline og kalender. Vi har set lokale reads være lynhurtige i to Snilld‑piloter, mens WebBridge krævede ekstra governance, før interne portaler blev åbnet. Fair nok.
Mindre egnede førstegangsopgaver: høj skriveaktivitet i produktionssystemer og komplekse ERP‑transaktioner. Opgaver hvor data ikke må røre en browser, hører også til senere i rejsen. Ambitioner kan altid skrues op, når kontrollen sidder i rygmarven.
Modargumenter og åbne spørgsmål
Skeptikere peger på dataeksfiltration via browserstyring og scripts, performance på bærbare og management overhead ved lokale opdateringer. MarkTechPost dokumenterer funktionerne, men giver ikke systemkrav (rapporteringshul). Kapacitetsplanlægning er derfor p.t. et Snilld‑estimatområde.
Åbne punkter vi gerne ser lukket: 1) officiel bekræftelse fra Moonshot af, at K2.6 kører lokalt i Kimi Work (MarkTechPost, community‑rapporter), 2) hardwarekrav for en 300‑agent swarm på klient, 3) datakilder/licens for de pre‑integrerede markedsdata, 4) WebBridges netværks‑ og logadfærd, 5) konkret UX for godkendelse af filskrivning.
Kildebilledet kort
Produktfakta – downloads til macOS/Windows, lokal kørsel, WebBridge, cron, filadgang og finansdata – stammer fra MarkTechPosts gennemgang (MarkTechPost). Oplysninger om K2.6 som MoE, 32B aktive parametre, 256k kontekst og op til 4.000 koordinerede skridt gengives samme sted med henvisning til Moonshot og community (MarkTechPost). SkillOpt‑referencen er fra VentureBeat. Hardware‑ og performancevurderinger er Snilld‑estimater baseret på erfaring – ikke Moonshots officielle tal.
Hvad ledere bør gøre i næste uge
Hold det enkelt. Rul ikke ud til hele huset. Gør fem ting og mål effekten:
- Aftal en 4‑6 ugers pilot med tre afgrænsede flows og klare succeskriterier.
- Sæt MDM‑politikker for filadgang, WebBridge‑domæner og power‑indstillinger.
- Spejl agent‑ og browserlogning til jeres SIEM fra dag ét.
- Udpeg dataejer, driftsrepræsentant og faglig reviewer pr. flow med godkendelse af alle skrivehandlinger.
- Brug skills‑optimering (fx SkillOpt) til at modne instrukser i piloten fremfor at skifte model.
Vi hjælper gerne med pilotdesign, sikkerheds‑sundhedstjek og integration. Man opdager først forskellen, når man sidder med det i hænderne.
