Gevinster:
- Anvendelse af den stigende kompleksitet fra den enkleste løsning til agenten
- At skelne mellem kæde-, routing- og parallelle arbejdsgangsmønstre
- At bryde en flertrinsopgave ind i en planlægning-udførelse-verifikationscyklus
Vi etablerede den enkle cyklus med enkelt køretøj i den forrige enhed. Virkelig arbejde kræver ofte flere trin, flere værktøjer og nogle gange forgreningsbeslutninger: "Find ordrer, der er forsinkede i denne måned, lav en undskyldnings-e-mail til kunderne, opsummer for en leder." I denne enhed dækker vi mønstre for organisering af flertrinsopgaver, når du har brug for en rigtig agent, og planlægning-udførelse-verifikationscyklussen. Hovedprincippet: kompleksitet så meget som nødvendigt.
Skaler fra enkleste løsning til agent
Ikke alle opgaver fortjener den mest komplekse løsning. Klatre trin for trin på kompleksitetsskalaen og stop ved den enkleste passende løsning:
- Enkeltkald: Hvis opgaven løses ved et enkelt modelkald (opsummer, klassificer) stop her.
- Enkelt opkald med RAG: Hvis information er påkrævet, tilføjes hentning og igen enkelt opkald.
- Fast arbejdsgang: Hvis trinene er kendt på forhånd, sekvenser du dem manuelt (kodeflow). Modellen udfører et underjob ved hvert trin, men du bestemmer rækkefølgen.
- Modeldrevet agent: Hvis trinene ikke kan kendes på forhånd, bestemmer modellen, hvilken agent der skal ringes til og hvornår. Den mest kraftfulde, men dyreste og mest risikable mulighed.
Forskellen mellem Workflow og agent er kritisk: I Workflow skriver du flowet af kontrol (forudsigeligt, testbart, billigt). Du giver kontrol over dagsordenen til modellen (fleksibel men uforudsigelig). Det meste virksomhedsarbejde er faktisk en arbejdsgang; reelle agenter er relativt få.
Tip: "Kan jeg skrive trinene til denne opgave ud på forhånd?" spørge. Hvis du kan skrive det, så opbyg en arbejdsgang - billigere, sikrere, mere testbar. Men hvis trinene varierer afhængigt af input og ikke kan forudsiges, er en agent påkrævet.
Tre grundlæggende arbejdsgangsmønstre
Prompt kæde: Outputtet fra et trin er input fra det næste. "Generer kladde → rediger → format." Hvert trin er enkelt og fokuseret; let at fejlfinde.
Routing: Du klassificerer først den indkommende anmodning og sender den til den relevante ekspert. "Er dette spørgsmål teknisk, fakturerings- eller refusion?" → omdirigere til korrekt understrøm. Hver sti er optimeret med sin egen prompt og værktøjer.
Parallelisering: At køre selvstændige jobs samtidigt og kombinere resultaterne. "Opsummer 5 dokumenter separat, og kombiner derefter." Ikke kun er det hurtigt, men hvert stykke får fuld opmærksomhed.
mønster
hvornår
eksempel
lænket
Trin er sekventielle og afhængige
Kladde → rediger → format
omdirigere
Forskellig behandling afhængig af inputtype
Klassificering af supportanmodninger
parallel
Selvstændige delværker
Opsummer flere dokumenter separat
Agent (løkke)
Trin kan ikke forudsiges på forhånd
Åbent research/reparation
# Routing mønster (konceptuel) type = pattern.classify(request) # "return" | "teknik" | "invoice"if tour == "return": answer = return_flow(request)elif tur == "technical": answer = technical_flow(request)else: answer = invoice_flow(request)
Planlægning-udførelse-verifikationscyklus
Et kraftfuldt mønster i rigtige agenter: få modellen til at planlægge, udfør derefter, og bekræft. Modellen deler den komplekse opgave op i undertrin, udfører hvert trin med værktøjer og spørger til sidst "nåede jeg målet?" han tjekker. Bekræftelsestrinnet fanger fejl med et separat, frisk udseende ("opfylder dette output opgaven?").
# Plan-execute-verify (conceptual)plan = model.uret("Opdel denne opgave i trin: " + opgave)for trin i plan: resultat = agent_loop(trin) # execute with toolscheck = model.uret("Opfylder dette output opgaven? Fortæl mig, hvis der mangler noget: " + opgave + resultater)hvis check.missing: # korrektionsrunde
To god praksis for lange opgaver: påtving en standsningsbetingelse (maksimalt antal trin - forhindrer uendelig sløjfe) og fremskridtssporing (få agenten til at skrive ned, hvad han laver, så han ikke bliver distraheret). Agenten, som ikke har nogen tringrænse, kan snurre for evigt, hvis han sidder fast, og prisen vil eksplodere.
Svagt/stærkt design
Svag (sætter alt på én kæmpe agent):
Sig "få den komplekse ting gjort" og slip den med ubegrænsede værktøjer.# Resultat: uforudsigelig adfærd, risiko for uendelige sløjfer, høje omkostninger,# umuligt at fejlfinde.
Kraftig (flow først, agent kun hvor det er nødvendigt, begrænset):
Opdel først jobbet i faste trin (routing + kæde). Brug kun agent i underopgave, hvor trin er ukendte; Tilføj tringrænse, fremskridtssporing og verifikationsrunde.
Tre mini etuier
Case 1 — Workflow i stedet for agent. Et team oprettede opgaven "proces support request" med en gratis agent; Nogle gange drejede agenten 15 trin og gik den forkerte vej. Trinene var i det væsentlige faste (klassificer → hent relevant information → skriv udkast → indsend til godkendelse). Da vi skiftede til routing + kæde arbejdsgangen, steg konsistensen fra 58 % til 96 %, og omkostningerne blev halveret.
Tilfælde 2 — Parallel forstærkning. Et juridisk team var ved at opsummere 20 kontrakter én efter én; Det tog 4 minutter i alt. Da vi skiftede til et parallelt mønster (alt på samme tid, så kombiner), blev tiden reduceret til 25 sekunder, og kvaliteten steg, da hvert resumé fik fuld opmærksomhed.
Tilfælde 3 — Der var ingen standsningsbetingelse. En efterforskningsagent blev ved med at ringe til de samme to værktøjer i det uendelige og søgte efter information, han ikke kunne finde; akkumulerede betydelige omkostninger natten over. Da den maksimale 8-trins grænse og reglen "Hvis du ikke kan finde det på 3 forsøg, sig jeg ved det ikke" blev tilføjet, blev omkostningerne holdt under kontrol, og der kom ærlige "Jeg kunne ikke finde det" svar.
Almindelige fejl
- Uddelegering af alt til agenten: Arbejdsgangen er billigere, sikrere og testbar, hvis trinene er kendt.
- Blanding af arbejdsgang med agent: Tager du eller modellen kontrol? Design ikke uden at gøre dette klart.
- Ikke at indstille en standsningsbetingelse: Agenten går ind i en uendelig løkke og akkumulerer omkostninger.
- Ingen fremskridtssporing: Under en lang mission bliver agenten distraheret og udfører det samme arbejde igen.
- Springer verifikationsrunden over: Forkert, men plausibelt udseende output leveres ukontrolleret.
OBS: Jo friere midlet er, jo større bliver sprængningsradius. Fleksibilitet er ikke gratis; hver yderligere frihed tilføjer uforudsigelighed og risiko. Vælg den smalleste passende løsning.
Sammenfattende
- I kompleksitet gælder "efter behov"-princippet: enkelt opkald → RAG → arbejdsgang → agent kun hvis det virkelig er nødvendigt.
- I Workflow skriver du flowet af kontrol (forudsigeligt); Du overlader dagsordenen til modellen (fleksibel men risikabel).
- Tre grundlæggende mønstre: kæde (sekventielt afhængig), routing (fordele efter type), parallel (uafhængige job).
- Rigtige agenter bruger plan-udfør-bekræft-cyklussen, stoptilstand og fremskridtssporing.
- Efterhånden som fleksibiliteten øges, stiger uforudsigeligheden og omkostningerne; Vælg den smalleste passende løsning.
Ansøgningsopgave
Vælg en flertrinsopgave fra din egen virksomhed (f.eks. "forbered og distribuer månedlig rapport"). (1) Kan du skrive trinene i denne opgave på forhånd? Hvis du kan skrive det, så design det som en arbejdsgang (hvilket mønster: kæde/routing/parallel?); Hvis du ikke kan skrive, så forklar hvorfor en agent er nødvendig. (2) Tegn dit valgte design med et boks-pildiagram. (3) Hvis bureau: skriv, hvordan du vil konfigurere stopbetingelsen, statussporing og verifikationsrunde. (4) Nævn 3 risici ved at udføre den samme opgave med en "single dev agent".
tjekliste
- [ ] Jeg kan vælge det rigtige niveau på "kompleksitet efter behov" skalaen.
- [ ] Jeg kan skelne forskellen i kontrol mellem Workflow og agent.
- [ ] Jeg kan kortlægge kæde-, routing- og parallelle mønstre til passende opgaver.
- [ ] Jeg kan konfigurere plan-udfør-bekræft cyklus, stoptilstand og statussporing i agenter.
- [ ] Jeg husker på, at for meget fleksibilitet medfører uforudsigelighed og omkostninger.