Alibaba præsenterer SkillWeaver, et rammeværk til LLM‑agenter, der vælger værktøjer løbende i stedet for at dumpe hele biblioteket ind i hver prompt. Ifølge forfatternes paper og VentureBeat falder tokenforbruget markant i deres tests, fordi modellen kun får vist beskrivelser af de værktøjer, der faktisk skal bruges nu, bundet til en eksplicit eksekveringsgraf.
Baggrunden er kendt fra større agentmiljøer: mange værktøjer betyder hurtigt fyldt kontekst og masser af spildte tokens, hvis alt eksponeres på én gang. SkillWeaver går den anden vej og ruter gennem udvalgte “skills” trin for trin.
Hvad SkillWeaver egentlig gør
Kernen beskrives som compositional skill routing i tre faser: Decompose, Retrieve, Compose. En kompleks opgave splittes i deltrin. For hvert trin hentes en kortliste af relevante skills fra et bibliotek. Til sidst lægges det hele i en eksekveringsgraf, hvor output fra et værktøj passer som input til det næste. Så langt stemmer paper og VentureBeat overens.
Pointen er at gøre planlægningen eksplicit, så modellen ikke skal holde hele planen i hovedet fra start. I landskabet minder det om miljøer som Model Context Protocol, hvor flere værktøjer orkestreres over tid til flertrinsopgaver.
Grafen og valg per node
SkillWeaver konstruerer en graf over delopgaver og vælger passende skills for hver node. Den kompositionelle form gør, at kompatibilitet kan vurderes løbende, og at planen kan opdateres, hvis et trin afslører nye behov. Det står i kontrast til one‑shot routing, hvor et enkelt tidligt valg skal bære hele kæden.
Grafen hjælper også med kontekstdisciplin: færre værktøjsbeskrivelser per trin betyder lavere tokenforbrug og mindre støj. Det er et praktisk, ikke et poetisk, argument.
Skill‑Aware Decomposition i praksis
Forfatterne introducerer Skill‑Aware Decomposition, et feedback‑drevet loop der dekomponerer opgaven, henter kandidater og vurderer dem iterativt. Kandidater hentes, når et trin kræver det, og filtreres på relevans og samspil med nabotrin. Den løbende “fetch og tjek”‑bevægelse er hele mekanikken.
Loopet er koblet til grafen, så planen kan justeres undervejs. Ikke bare en liste over værktøjer, men en rute med afhængigheder og mulige parallelle spor, gjort synlig.
Hvorfor tokens falder så meget
Besparelsen kommer af at lade være med at proppe hele værktøjsbiblioteket i konteksten. Store biblioteker har lange beskrivelser og kan æde kontekstvinduet og hundredtusinder af tokens. Med retrieve‑and‑route får modellen kun beskrivelser af relevante værktøjer, når et trin kræver dem.
I de rapporterede eksperimenter giver det en reduktion i tokenforbrug på over 99 procent mod en naiv baseline, hvor hele biblioteket eksponeres. Det tal gælder deres opsætning og sammenligningsmetode, som beskrevet i paperet og gengivet af VentureBeat.
Præcision kontra one‑shot
Forfatterne melder højere nøjagtighed end one‑shot værktøjsvalg. Rationelt nok: kompatibilitet og rækkefølge vurderes undervejs i stedet for at antage, at ét valg tidligt kan forudsige hele kæden. Færre fejlrutinger i komplekse sekvenser, lyder konklusionen i både paper og artiklen.
Sammenligningen er central, men også bundet til deres baseline. Egen verifikation på egne data er nødvendig, før man kalder den endelige vinder.
Hvad det betyder i drift
For teams der bygger enterprise‑agenter, flytter det fokus fra “vis alt” til “hent når nødvendigt”. Arkitekturen ændrer sig: en controller skal kunne hente, matche og validere skills per trin. Testbarheden også. En central tool‑registry er nødvendig med klare metadata om input, output, kompatibilitet, omkostning og ventetid, så routing kan ske på fakta og ikke kun tekstlig lighed.
Der følger governance med: hvis dekomponeringen rammer ved siden af, skal der være fallback. Til et sikrere baseline‑værktøj, til menneskelig godkendelse, eller til en genkørsel med en anden dekomponeringsstrategi. Uden det får man flotte grafer og skrøbelig drift.
Tokenøkonomi uden røgslør
En rapporteret reduktion på over 99 procent i tokens kan omsættes til store cloudbesparelser. Men regnskabet skal tælle alt: tokens brugt i dekomponering, i hver retrieval og i prompts til selve værktøjerne. Den samlede gevinst afhænger af bibliotekets størrelse, dokumentationslængder og hvor ofte ruten revideres undervejs.
Praktisk greb: mål tokens per trin og per fuld eksekvering, og hold det op mod en “vis alt”‑baseline. Log fejlrate i routing og antallet af omroutinger, så gevinsten vurderes på både pris og kvalitet.
Latency og ekstra API‑runder
Tokenfokusset fylder i kilderne. Latency fylder mindre. Flere retrieval‑runder betyder typisk flere netværkskald og kan presse SLA’er, især når værktøjer i kæden selv er langsomme. Mål derfor round‑trips per workflow, median og p95 ventetid, samt tid til første brugbare deloutput.
To lavpraktiske håndtag: begræns antallet af retrieval‑runder pr. trin, og cache skill‑beskrivelser. Det dæmper både tokens og ventetid uden at kvæle rutenøjagtigheden i hverdagsopgaver.
Test og monitorering før integration
Byg en lille testpipeline, der: 1) måler tokenforbrug under dekomponering og retrieval, 2) evaluerer nøjagtighed per deltrin mod en kendt sandhed, 3) logger fejl i kompatibilitet mellem værktøjer, og 4) rapporterer fallback‑rate. Brug egne opgaver i stedet for generiske benchmarks, så routing lærer jeres formater og kanttilfælde at kende.
Overvåg i drift med få indikatorer: call‑rate til retriever, konvergenstid til stabil eksekveringsgraf, andel af genkørsler og tokens per fuldført workflow. Det er her, man ser, om gevinsten kan gentages uden for laboratoriet.
Begrænsninger og åbne spørgsmål
Paper og VentureBeat dokumenterer tokenbesparelse og højere nøjagtighed i deres setup. De går mindre i dybden med latency og med, hvordan kvaliteten af dekomponeringen påvirker robusthed, når opgaver er støjfyldte eller uventede. Også tokenomkostningen ved selve retrieval er kun let behandlet i materialet.
Et andet åbent punkt er generaliserbarhed på tværs af biblioteker med varierende dokumentationslængder og embedding‑kvalitet. Et fornuftigt tjek er at køre følsomheds‑tests: forkort beskrivelser, læg næsten‑ens værktøjer tæt, og se hvor hurtigt præcisionen glider.
Hvor det passer ind
MarkTechPost beskriver WebBrain, en open‑source browser‑agent, som eksempel på flertrinsautomatisering tæt på brugeren. Fokusset er et andet end i SkillWeaver, men illustrerer spændet i agentlandskabet fra lokale flows til rammeværker for sammensat routing.
I den kontekst skiller SkillWeaver sig ud ved at sætte kompositionel ruteplanlægning og løbende værktøjsvalg i centrum, knyttet til en eksplicit graf. Mere arkitekturidé end endnu et plugin.
Hvad man kan gøre nu
Hvis I bygger multi‑tool agenter, så start med to ting: 1) få styr på tool‑registry med klare beskrivelser, signaturer og simple cost‑ og latency‑metadata, 2) mål nuværende tokenforbrug og latency på en “vis alt”‑baseline. Test derefter en compositional retrieve‑and‑route‑controller på et afgrænset sæt opgaver og sammenlign nøgletal.
Sæt konkrete mål for fallback og governance før udrulning. Det er forskellen på en pæn demo og noget, der holder i drift.
