Vad ett arbetsflöde egentligen är här
De flesta »arbetsflödesverktyg« inom AI är uppmaningskedjor med ett tunt lager ovanpå. ToRuns byggare är en riktad acyklisk graf (DAG) av typade steg: du kopplar modellanrop, verktygsanrop, villkorsgrenar, slingor och underflöden till en graf, och motorn utför dem i beroendeordning, parallellt där grafen tillåter.
Varje steg är en fullvärdig entitet med egen inställning: stegtyp (LLM-anrop, webbsökning, körning av kod, bildgenerering, hämtning, omvandling och så vidare), indataschema, felpolicy (fallera snabbt, försök igen med väntan, gå till alternativ), tak för utförandebudget per steg och tidsgräns.
Modellstyrningen inuti varje LLM-steg går genom samma förmågekedja som allt annat i ToRun. Du anger vad du behöver — strukturerad utdata, syn, verktygsanvändning, resonemang, ett sammanhangsfönster på minst N tecken — och utföraren löser den bäst passande modellen bland de leverantörer som är tillgängliga då. Om din föredragna leverantör ger en 5xx tar reservkedjan automatiskt vid.
Utförare med kvalitet först och vad det ändrar i praktiken
När du kör ett arbetsflöde väljer utföraren medvetet modeller i kvalitetsklass i stället för det billigaste alternativet. Två skäl: automatiseringar frambringar alster (rapporter, genererat innehåll, kod) som ingen granskar genast, så kvalitetsbrister hopar sig tyst; och vid måttlig mängd är kostnadsskillnaden mindre än priset för dålig utdata som tvingar fram en ny körning eller manuell rättning.
I praktiken betyder det att ett arbetsflöde »sammanfatta efterforskningen och skriv en rapport« föredrar en stadig resonemangsmodell för sammanfattningen och en textmodell av hög kvalitet för skrivandet, i stället för att springa mot prisgolvet. Du kan åsidosätta det vid ett visst steg om du vet att en lätt modell räcker där.
Faktureringen följer resten av ToRun: varje modellanrop inuti ett arbetsflöde skriver exakt en post med en fryst prisögonblicksbild. En körning som anropar tre olika modeller i fem steg ger fem poster. Du kan granska varje körnings exakta kostnad, uppdelad per steg, även i efterhand — till och med månader senare, när leverantörernas priser redan rört sig.
Att gå igenom en körning
Varje arbetsflödeskörning frambringar ett strukturerat spår. Spåret visar grafen med varje nod försedd med anteckningar: starttid, sluttid, upplöst modell, antal in- och uttecken, gjorda verktygsanrop och eventuellt fel. Vid LLM-steg kan du fälla ut exakt den uppmaning som sändes och det råa svar som togs emot.
Om ett steg fallerar berättar spåret om felet kom från modellanropet (leverantörsfel, sammanhangsöverflöd, avslag enligt innehållspolicy), från ett verktyg längre fram (nätverkstidsgräns, misslyckad schemakontroll) eller från din egen villkorslogik. Du behöver inte lägga till loggning: den fångas på infrastrukturnivå vid varje körning.
Varje körning kan upprepas med samma indata, vilket gör det rakt fram att återskapa ett fel.
Ett litet exempel: veckovis arbetsflöde för konkurrentbevakning
Tänk dig ett arbetsflöde som du startar varje måndag morgon:
- Webbsökningssteg — söker färska omnämnanden för en uppsättning konkurrentnyckelord och ger en lista med adresser och utdrag.
- Hämtningssteg — tar fram de fyra senaste rapporterna ur en kunskapsbas för att sätta utgångssammanhanget.
- Sammanfattningssteg (LLM) — destillerar sökträffarna till strukturerade iakttagelser: nya funktioner, prisändringar, viktiga tillkännagivanden.
- Skrivsteg (LLM) — skriver en kortfattad intern promemoria i enhetlig husstil, grundad i de sammanfattade iakttagelserna.
- Leveranssteg — publicerar promemorian till en inställd webhook-slutpunkt.
Grafen har ett naturligt beroende: steg 3 beror på 1 och 2 (som kan köra parallellt), steg 4 på 3, steg 5 på 4. Utföraren gör detta utan någon uttrycklig parallellitetsinställning: den läser kanterna.