Gevinster:
- Bruk av den økende kompleksitetsskalaen fra den enkleste løsningen til agenten
- Skille mellom kjetting, ruting og parallelle arbeidsflytmønstre
- Bryte en flertrinnsoppgave inn i en planlegging-utførelse-verifiseringssyklus
Vi etablerte den enkle syklusen for ett kjøretøy i forrige enhet. Virkelig arbeid krever ofte flere trinn, flere verktøy og noen ganger forgreningsbeslutninger: "Finn bestillinger som er for sent denne måneden, lag en unnskyldningse-post til kundene, oppsummer for en leder." I denne enheten dekker vi mønstre for organisering av flertrinnsoppgaver, når du trenger en ekte agent, og planlegging-utførelse-verifiseringssyklusen. Hovedprinsippet: kompleksitet så mye som nødvendig.
Skaler fra enkleste løsning til agent
Ikke alle oppgaver fortjener den mest komplekse løsningen. Klatre steg for steg på kompleksitetsskalaen og stopp ved den enkleste tilstrekkelige løsningen:
- Enkeltoppkall: Hvis oppgaven løses med et enkelt modellanrop (oppsummer, klassifiser) stopp her.
- Enkeltanrop med RAG: Hvis informasjon er nødvendig, legg til henting og igjen enkeltanrop.
- Fast arbeidsflyt: Hvis trinnene er kjent på forhånd, sekvenser du dem manuelt (kodeflyt). Modellen gjør en deljobb på hvert trinn, men du bestemmer rekkefølgen.
- Modelldrevet agent: Hvis trinnene ikke er kjent på forhånd, bestemmer modellen hvilken agent som skal ringes og når. Det kraftigste, men dyreste og mest risikable alternativet.
Forskjellen mellom Workflow og agent er kritisk: I Workflow skriver du flyten av kontroll (forutsigbar, testbar, billig). Du gir kontroll over agendaen til modellen (fleksibel men uforutsigbar). Det meste av bedriftsarbeid er faktisk en arbeidsflyt; ekte agenter er relativt få.
Tips: "Kan jeg skrive ut trinnene for denne oppgaven på forhånd?" spørre. Hvis du kan skrive det, bygg en arbeidsflyt – billigere, tryggere og mer testbar. Men hvis trinnene varierer avhengig av input og ikke kan forutsies, kreves en agent.
Tre grunnleggende arbeidsflytmønstre
Spørre kjeding: Utgangen fra ett trinn er inngangen til det neste. "Generer utkast → rediger → format." Hvert trinn er enkelt og fokusert; lett å feilsøke.
Ruting: Du klassifiserer først den innkommende forespørselen og sender den til den aktuelle eksperten. "Er dette spørsmålet teknisk, fakturering eller refusjon?" → omdirigere til riktig understrøm. Hver sti er optimalisert med sin egen melding og verktøy.
Parallellisering: Kjøre uavhengige jobber samtidig og kombinere resultatene. "Summer opp 5 dokumenter separat, og kombiner deretter." Ikke bare er det raskt, men hver brikke får full oppmerksomhet.
mønster
når
eksempel
lenket
Trinn er sekvensielle og avhengige
Utkast → rediger → format
omdirigere
Ulik behandling avhengig av inngangstype
Klassifisering av støtteforespørsel
parallell
Selvstendige delarbeider
Oppsummer flere dokumenter separat
Agent (løkke)
Trinn kan ikke forutsies på forhånd
Åpen forskning/reparasjon
# Rutingmønster (konseptuell)type = pattern.classify(request) # "retur" | "teknikk" | "invoice"if tour == "return": answer = return_flow(request)elif tur == "technical": answer = technical_flow(request)else: answer = invoice_flow(request)
Planlegging-utførelse-verifikasjonssyklus
Et kraftig mønster hos ekte agenter: ha modellplanen, utfør deretter og verifiser. Modellen deler opp den komplekse oppgaven i undertrinn, utfører hvert trinn med verktøy, og spør til slutt "oppnådde jeg målet?" han sjekker. Verifikasjonstrinnet fanger opp feil med et separat, friskt utseende ("oppfyller denne utgangen oppgaven?").
# Plan-execute-verify (conceptual)plan = model.uret("Del opp denne oppgaven i trinn: " + oppgave)for trinn i plan: resultat = agent_loop(step) # execute with toolscheck = model.uret("Oppfyller denne utgangen oppgaven? Fortell meg om det mangler noe: " + oppgave + resultater)hvis check.missing: # korreksjonsrunde
To gode fremgangsmåter for lange oppgaver: pålegg en stoppbetingelse (maksimalt antall trinn – forhindrer uendelig sløyfe) og fremdriftssporing (la agenten skrive ned hva han gjør slik at han ikke blir distrahert). Agenten, som ikke har noen trinngrense, kan snurre for alltid hvis han blir sittende fast og kostnadene vil eksplodere.
Svak/sterk design
Svak (legger alt på en gigantisk agent):
Si "få den komplekse tingen gjort" og slipp den med ubegrensede verktøy.# Resultat: uforutsigbar oppførsel, risiko for uendelige løkker, høye kostnader,# umulig å feilsøke.
Kraftig (flyt først, agent kun der det er nødvendig, begrenset):
Del først opp jobben i faste trinn (ruting + kjetting). Bruk agent kun i underoppgaver der trinn er ukjente; Legg til trinngrense, fremdriftssporing og verifiseringsrunde.
Tre minivesker
Tilfelle 1 — Arbeidsflyt i stedet for agent. Ett team satte opp oppgaven "prosessstøtteforespørsel" med en gratis agent; Noen ganger snudde agenten 15 trinn og gikk på feil vei. Trinnene var i hovedsak fikset (klassifiser → hent relevant informasjon → skriv utkast → send inn for godkjenning). Da vi byttet til arbeidsflyten for ruting + kjede, økte konsistensen fra 58 % til 96 % og kostnadene ble halvert.
Tilfelle 2 - Parallell gevinst. Et juridisk team oppsummerte 20 kontrakter én etter én; Det tok 4 minutter totalt. Da vi byttet til et parallelt mønster (alt på samme tid, så kombiner), ble tiden redusert til 25 sekunder og kvaliteten økte etter hvert som hver oppsummering fikk full oppmerksomhet.
Sak 3 - Det var ingen stoppbetingelse. En etterforskningsagent fortsatte å ringe de samme to verktøyene i det uendelige, og søkte etter informasjon han ikke fant; akkumulerte betydelige kostnader over natten. Da den maksimale 8-trinnsgrensen og «Hvis du ikke finner den på 3 forsøk, si at jeg ikke vet»-regelen ble lagt til, ble kostnadene holdt under kontroll og ærlige «Jeg kunne ikke finne den»-svarene kom.
Vanlige feil
- Delegere alt til agenten: Arbeidsflyten er billigere, sikrere og testbar hvis trinnene er kjent.
- Blande arbeidsflyt med agent: Tar du eller modellen kontroll? Ikke design uten å gjøre dette klart.
- Ikke å sette en stoppbetingelse: Agenten går inn i en uendelig sløyfe og akkumulerer kostnader.
- Ingen fremdriftssporing: Under et langt oppdrag blir agenten distrahert og gjør den samme jobben igjen.
- Hopp over verifiseringsrunden: Ukorrekt, men plausibelt utseende, leveres ukontrollert.
OBS: Jo friere midlet er, desto større blir sprengningsradiusen. Fleksibilitet er ikke gratis; hver ekstra frihet gir uforutsigbarhet og risiko. Velg den smaleste tilstrekkelige løsningen.
Oppsummert
- I kompleksitet gjelder "etter behov"-prinsippet: enkeltanrop → RAG → arbeidsflyt → agent bare hvis det virkelig er nødvendig.
- I Workflow skriver du flyten av kontroll (forutsigbar); Du overlater agendaen til modellen (fleksibel, men risikabel).
- Tre grunnleggende mønstre: kjetting (sekvensavhengig), ruting (fordele etter type), parallelle (uavhengige jobber).
- Ekte agenter bruker syklusen plan-utfør-verifiser, stopptilstand og fremdriftssporing.
- Ettersom fleksibiliteten øker, øker uforutsigbarheten og kostnadene; Velg den smaleste tilstrekkelige løsningen.
Søknadsoppgave
Velg en flertrinnsoppgave fra din egen virksomhet (f.eks. "forbered og distribuer månedlig rapport"). (1) Kan du skrive trinnene i denne oppgaven på forhånd? Hvis du kan skrive det, design det som en arbeidsflyt (hvilket mønster: kjetting/ruting/parallell?); Hvis du ikke kan skrive, forklar hvorfor en agent er nødvendig. (2) Tegn ditt valgte design med et boks-pildiagram. (3) Hvis byrå: skriv hvordan du vil sette opp stopptilstand, fremdriftssporing og verifiseringsrunde. (4) Nevn 3 risikoer ved å gjøre den samme oppgaven med en "single dev agent".
sjekkliste
- [ ] Jeg kan velge riktig nivå på "kompleksitet etter behov"-skalaen.
- [ ] Jeg kan skille forskjellen i kontroll mellom arbeidsflyt og agent.
- [ ] Jeg kan kartlegge kjetting, ruting og parallelle mønstre til passende oppgaver.
- [ ] Jeg kan sette opp syklusen plan-utfør-verifiser, stopptilstand og fremdriftssporing i agenter.
- [ ] Jeg husker på at for mye fleksibilitet gir uforutsigbarhet og kostnader.