Vzory agentních aplikací

Vytváření agentských aplikací pomocí AI má dva obecné přístupy:

  • Deterministické pracovní postupy – Váš kód definuje tok řízení. Napíšete posloupnost kroků, větvení, paralelismu a zpracování chyb pomocí standardních programovacích konstruktorů. LLM provádí práci uvnitř každého kroku, ale neřídí celkový tok.
  • Pracovní postupy řízené agenty (smyčky agentů) – LLM řídí tok řízení. Agent rozhodne, které nástroje se mají volat, v jakém pořadí a kdy je úloha dokončena. Poskytujete nástroje a pokyny, ale agent určuje cestu spuštění za běhu.

Oba přístupy těží z trvalého spouštění a lze je implementovat pomocí programovacího modelu Durable Task. Tento článek ukazuje, jak sestavit jednotlivé vzory s připravenými ukázkami kódu v jazyce C#, Python, JavaScript/TypeScript a Java.

Návod

Prerequisites: Před použitím těchto vzorů nastavte sady SDK Durable Task nebo Durable Functions. Pokud chcete začít, podívejte se na přehled sady SDK nebo Durable Functions.

Na této stránce:

Návod

Tyto vzory odpovídají návrhům pracovních postupů agentů popsaných v Anthropicově sestavení efektivních agentů. Programovací model Durable Task se přirozeně mapuje na tyto vzory: orchestrace definují tok řízení pracovního postupu a jsou automaticky označeny kontrolními body, zatímco aktivity zabalují nedeterministické operace, jako jsou volání LLM, volání nástrojů a požadavky rozhraní API.

Volba přístupu

Následující tabulka vám pomůže rozhodnout, kdy použít jednotlivé přístupy.

Při použití deterministických pracovních postupů... Používejte smyčky agenta, když...
Posloupnost kroků je známa předem. Úkol je otevřený a kroky nelze předpovědět.
Potřebujete explicitní mantinely nad chováním agenta. Chcete, aby LLM rozhodl, které nástroje se mají použít a kdy.
Dodržování předpisů nebo auditovatelnost vyžaduje kontrolovatelný tok řízení. Agent musí přizpůsobit svůj přístup na základě průběžných výsledků.
Chcete zkombinovat více architektur AI v jednom pracovním postupu. Vytváříte konverzačního agenta s funkcemi volání nástrojů.

Oba přístupy poskytují automatické kontrolní body, politiky opakování, distribuované škálování a podporu s účastí člověka prostřednictvím trvalého provádění.

Deterministické vzory pracovních postupů

V deterministickém pracovním postupu řídí váš kód cestu provádění. LLM se volá jako krok v rámci pracovního postupu, ale nerozhoduje, co se stane dál. Programovací model Durable Task se přirozeně hodí k tomuto přístupu.

  • Orchestrace definují tok řízení pracovního postupu (posloupnost, větvení, paralelismus, zpracování chyb) a jsou automaticky označeny kontrolními body.
  • Aktivity zabalují ne deterministické operace, jako jsou volání LLM, volání nástrojů a požadavky rozhraní API. Aktivity se můžou spouštět na libovolné dostupné výpočetní instanci.

Následující příklady používají Durable Functions, které běží na Azure Functions s bezserverovým hostováním.

Následující příklady používají přenosné sady SDK úloh Durable Task SDK, které běží na jakémkoli výpočetním prostředí hostitele, včetně Azure Container Apps, Kubernetes, virtuálních počítačů nebo místně.

Vzorový řetězení promptů

Řetězení výzev je nejjednodušší agentní vzor. Komplexní úlohu rozdělíte do řady sekvenčních interakcí LLM, kde výstup každého kroku bude vstupem pro následující krok. Vzhledem k tomu, že každé volání aktivity je automaticky kontrolováno, nemusíte po havárii uprostřed potrubí začínat od začátku a znovu využívat drahé tokeny LLM – provádění pokračuje z posledního dokončeného kroku.

Mezi kroky můžete také vložit programová ověřovací hradla. Například po vygenerování osnovy můžete ověřit, že splňuje omezení délky nebo tématu před jeho předáním do kroku návrhu.

Tento vzor se mapuje přímo na model řetězení funkcí v programovacím modelu Durable Task.

Kdy použít: Kanály generování obsahu, zpracování vícefázového dokumentu, postupné rozšiřování dat, pracovní postupy, které vyžadují zprostředkující ověřovací brány.

Poznámka:

Ve všech následujících příkladech je stav orchestrace automaticky zaznamenán u každého prohlášení await/yield. Pokud dojde k chybovému ukončení hostitelského procesu nebo recyklaci virtuálního počítače, orchestrace se obnoví z posledního dokončeného kroku a neskončí znovu.

[Function(nameof(PromptChainingOrchestration))]
public async Task<string> PromptChainingOrchestration(
    [OrchestrationTrigger] TaskOrchestrationContext context)
{
    var topic = context.GetInput<string>();

    // Step 1: Generate research outline
    string outline = await context.CallActivityAsync<string>(
        nameof(GenerateOutlineAgent), topic);

    // Step 2: Write first draft from outline
    string draft = await context.CallActivityAsync<string>(
        nameof(WriteDraftAgent), outline);

    // Step 3: Refine and polish the draft
    string finalContent = await context.CallActivityAsync<string>(
        nameof(RefineDraftAgent), draft);

    return finalContent;
}

[DurableTask]
public class PromptChainingOrchestration : TaskOrchestrator<string, string>
{
    public override async Task<string> RunAsync(
        TaskOrchestrationContext context, string topic)
    {
        // Step 1: Generate research outline
        string outline = await context.CallActivityAsync<string>(
            nameof(GenerateOutlineAgent), topic);

        // Step 2: Write first draft from outline
        string draft = await context.CallActivityAsync<string>(
            nameof(WriteDraftAgent), outline);

        // Step 3: Refine and polish the draft
        string finalContent = await context.CallActivityAsync<string>(
            nameof(RefineDraftAgent), draft);

        return finalContent;
    }
}

Směrování

Směrování pomocí kroku klasifikace určí, který podřízený agent nebo model by měl zpracovat požadavek. Orchestrace nejprve volá činnost klasifikátoru a poté na základě výsledku přechází k příslušné obslužné rutině. Tento přístup umožňuje nezávisle přizpůsobit výzvy, model a sadu nástrojů jednotlivých obslužných rutin – například směrovat otázky týkající se fakturace specializovanému agentovi s přístupem k rozhraním API pro platby a zároveň odesílat obecné otázky modelu s nižší hmotností.

Kdy použít: Třídění zákazníků, klasifikace záměrů pro specializované agenty, výběr dynamického modelu na základě složitosti úloh.

[Function(nameof(RoutingOrchestration))]
public async Task<string> RoutingOrchestration(
    [OrchestrationTrigger] TaskOrchestrationContext context)
{
    var request = context.GetInput<SupportRequest>();

    // Classify the request type
    string category = await context.CallActivityAsync<string>(
        nameof(ClassifyRequestAgent), request.Message);

    // Route to the appropriate specialized agent
    return category switch
    {
        "billing" => await context.CallActivityAsync<string>(
            nameof(BillingAgent), request),
        "technical" => await context.CallActivityAsync<string>(
            nameof(TechnicalSupportAgent), request),
        "general" => await context.CallActivityAsync<string>(
            nameof(GeneralInquiryAgent), request),
        _ => await context.CallActivityAsync<string>(
            nameof(GeneralInquiryAgent), request),
    };
}

[DurableTask]
public class RoutingOrchestration : TaskOrchestrator<SupportRequest, string>
{
    public override async Task<string> RunAsync(
        TaskOrchestrationContext context, SupportRequest request)
    {
        // Classify the request type
        string category = await context.CallActivityAsync<string>(
            nameof(ClassifyRequestAgent), request.Message);

        // Route to the appropriate specialized agent
        return category switch
        {
            "billing" => await context.CallActivityAsync<string>(
                nameof(BillingAgent), request),
            "technical" => await context.CallActivityAsync<string>(
                nameof(TechnicalSupportAgent), request),
            _ => await context.CallActivityAsync<string>(
                nameof(GeneralInquiryAgent), request),
        };
    }
}

Paralelizace

Pokud máte více nezávislých dílčích úkolů, můžete je vykonat jako paralelní volání aktivit a počkat na všechny výsledky po dokončení. Plánovač úloh Durable distribuuje tyto aktivity napříč všemi dostupnými výpočetními instancemi automaticky, což znamená, že přidání dalších pracovních procesů přímo snižuje celkový počet hodinových hodin.

Běžnou variantou je hlasování s více modely: současně odešlete stejnou výzvu několika modelům (nebo stejnému modelu s různými teplotami) a pak agregujete nebo vyberete odpovědi. Vzhledem k tomu, že každá paralelní větev je nezávisle na kontrolních bodech, přechodná chyba v jedné větvi nemá vliv na ostatní.

Tento vzor se mapuje přímo na vzor fan-out/fan-in v Durable Task.

Kdy použít: Dávková analýza dokumentů, paralelní volání nástrojů, vyhodnocení více modelů, moderování obsahu s více revidujících.

[Function(nameof(ParallelResearchOrchestration))]
public async Task<string> ParallelResearchOrchestration(
    [OrchestrationTrigger] TaskOrchestrationContext context)
{
    var request = context.GetInput<ResearchRequest>();

    // Fan-out: research multiple subtopics in parallel
    var researchTasks = request.Subtopics
        .Select(subtopic => context.CallActivityAsync<string>(
            nameof(ResearchSubtopicAgent), subtopic))
        .ToList();
    string[] researchResults = await Task.WhenAll(researchTasks);

    // Aggregate: synthesize all research into a single summary
    string summary = await context.CallActivityAsync<string>(
        nameof(SynthesizeAgent),
        new { request.Topic, Research = researchResults });

    return summary;
}

[DurableTask]
public class ParallelResearchOrchestration : TaskOrchestrator<ResearchRequest, string>
{
    public override async Task<string> RunAsync(
        TaskOrchestrationContext context, ResearchRequest request)
    {
        // Fan-out: research multiple subtopics in parallel
        var researchTasks = request.Subtopics
            .Select(subtopic => context.CallActivityAsync<string>(
                nameof(ResearchSubtopicAgent), subtopic))
            .ToList();
        string[] researchResults = await Task.WhenAll(researchTasks);

        // Aggregate: synthesize all research into a single summary
        string summary = await context.CallActivityAsync<string>(
            nameof(SynthesizeAgent),
            new { request.Topic, Research = researchResults });

        return summary;
    }
}

Vzor orchestrátor-workerů

V tomto modelu centrální orchestrátor nejprve zavolá LLM (prostřednictvím aktivity) k naplánování práce. Na základě výstupu LLM orchestrátor pak určí, jaké dílčí úkoly jsou potřeba. Orchestrátor pak tyto dílčí úkoly odešle specializovaným pracovníkům na orchestraci. Klíčovým rozdílem od paralelizace je to, že sada dílčích úkoly není v době návrhu pevná; orchestrátor je dynamicky určuje za běhu.

Tento model používá dílčí orchestrace, které jsou nezávisle na kontrolních bodech podřízených pracovních postupů. Každá orchestrace pracovních procesů může obsahovat několik kroků, opakování a vnořený paralelismus.

Kdy použít: Kanály hloubkového výzkumu, pracovní postupy kódování agentů, které upravují více souborů, spolupráci s více agenty, kde má každý agent jinou roli.

[Function(nameof(OrchestratorWorkersOrchestration))]
public async Task<string> OrchestratorWorkersOrchestration(
    [OrchestrationTrigger] TaskOrchestrationContext context)
{
    var request = context.GetInput<ResearchRequest>();

    // Central orchestrator: determine what research is needed
    string[] subtasks = await context.CallActivityAsync<string[]>(
        nameof(PlanResearchAgent), request.Topic);

    // Delegate to worker orchestrations in parallel
    var workerTasks = subtasks
        .Select(subtask => context.CallSubOrchestratorAsync<string>(
            nameof(ResearchWorkerOrchestration), subtask))
        .ToList();
    string[] results = await Task.WhenAll(workerTasks);

    // Synthesize results
    string finalReport = await context.CallActivityAsync<string>(
        nameof(SynthesizeAgent),
        new { request.Topic, Research = results });

    return finalReport;
}

[DurableTask]
public class OrchestratorWorkersOrchestration : TaskOrchestrator<ResearchRequest, string>
{
    public override async Task<string> RunAsync(
        TaskOrchestrationContext context, ResearchRequest request)
    {
        // Central orchestrator: determine what research is needed
        string[] subtasks = await context.CallActivityAsync<string[]>(
            nameof(PlanResearchAgent), request.Topic);

        // Delegate to worker orchestrations in parallel
        var workerTasks = subtasks
            .Select(subtask => context.CallSubOrchestratorAsync<string>(
                nameof(ResearchWorkerOrchestration), subtask))
            .ToList();
        string[] results = await Task.WhenAll(workerTasks);

        // Synthesize results
        string finalReport = await context.CallActivityAsync<string>(
            nameof(SynthesizeAgent),
            new { request.Topic, Research = results });

        return finalReport;
    }
}

Model vyhodnocovače-optimalizátor

Vzor vyhodnocovače-optimalizátor spáruje generátorový agent s vyhodnocovačem ve smyčce upřesnění. Generátor vytvoří výstup, vyhodnotí ho podle kritérií kvality a poskytne zpětnou vazbu a smyčka se opakuje, dokud výstup neprojde nebo nedosáhne maximálního počtu iterací. Vzhledem k tomu, že je každá iterace smyčky kontrolována kontrolním bodem, nedojde po třech úspěšných kolech upřesnění ke ztrátě dosaženého pokroku.

Tento vzor je užitečný zejména v případě, že lze měřit kvalitu programově – například ověření, že se vygenerovaný kód zkompiluje nebo že překlad zachovává pojmenované entity.

Kdy použít: Generování kódu pomocí automatizovaného revizí, literárního překladu, iterativního zpřesnění obsahu, složitých vyhledávacích úloh vyžadujících více kol analýzy.

[Function(nameof(EvaluatorOptimizerOrchestration))]
public async Task<string> EvaluatorOptimizerOrchestration(
    [OrchestrationTrigger] TaskOrchestrationContext context)
{
    var request = context.GetInput<ContentRequest>();
    int maxIterations = 5;
    string content = "";
    string feedback = "";

    for (int i = 0; i < maxIterations; i++)
    {
        // Generate or refine content
        content = await context.CallActivityAsync<string>(
            nameof(GenerateContentAgent),
            new { request.Prompt, PreviousContent = content, Feedback = feedback });

        // Evaluate quality
        var evaluation = await context.CallActivityAsync<EvaluationResult>(
            nameof(EvaluateContentAgent), content);

        if (evaluation.MeetsQualityBar)
            return content;

        feedback = evaluation.Feedback;
    }

    return content; // Return best effort after max iterations
}

[DurableTask]
public class EvaluatorOptimizerOrchestration : TaskOrchestrator<ContentRequest, string>
{
    public override async Task<string> RunAsync(
        TaskOrchestrationContext context, ContentRequest request)
    {
        int maxIterations = 5;
        string content = "";
        string feedback = "";

        for (int i = 0; i < maxIterations; i++)
        {
            // Generate or refine content
            content = await context.CallActivityAsync<string>(
                nameof(GenerateContentAgent),
                new { request.Prompt, PreviousContent = content, Feedback = feedback });

            // Evaluate quality
            var evaluation = await context.CallActivityAsync<EvaluationResult>(
                nameof(EvaluateContentAgent), content);

            if (evaluation.MeetsQualityBar)
                return content;

            feedback = evaluation.Feedback;
        }

        return content; // Return best effort after max iterations
    }
}

Smyčky agentů

V typické implementaci agenta AI je LLM vyvolán ve smyčce, přičemž volá nástroje a činí rozhodnutí, dokud není úkol dokončen nebo není dosažena podmínka zastavení. Na rozdíl od deterministických pracovních postupů není cesta spuštění předdefinovaná. Agent určuje, co dělat v jednotlivých krocích, na základě výsledků z předchozích kroků.

Smyčky agentů jsou vhodné pro úlohy, u kterých se počet nebo pořadí kroků nedá předpovědět. Mezi běžné příklady patří agenti volného kódování, autonomní vědecký výzkum a konverzační roboti se schopností volat nástroje.

Existují dva doporučené přístupy k implementaci smyček agentů pomocí programovacího modelu Durable Task:

Přístup Description Kdy ho použít
Založená na orchestrace Smyčka agenta je trvanlivá orchestrace. Volání nástrojů jsou aktivity; lidský vstup používá externí události. Jemně odstupňované řízení, zásady opakování jednotlivých nástrojů, distribuované spouštění nástrojů, ladění IDE.
Založené na entitách Každá instance agenta je trvalá entita. Architektura agenta spravuje smyčku; entita poskytuje trvalost relace. Používáte architekturu (například Microsoft Agent Framework), která už má smyčku agenta a chcete přidat odolnost s minimálními změnami.

Smyčky agentů založené na orchestraci

Smyčka agenta založená na orchestraci kombinuje několik funkcí Durable Task: eternal orchestrations (continue-as-new) pro udržení paměti v mezích, fan-out/fan-in pro paralelní spouštění nástrojů a externí události pro interakce s lidským zapojením. Každá iterace smyčky:

  1. Odešle aktuální kontext konverzace do LLM prostřednictvím aktivity nebo stavové entity.
  2. Přijme odpověď LLM, která může zahrnovat volání nástrojů.
  3. Spustí všechna volání nástrojů jako aktivity (distribuované napříč dostupnými výpočetními prostředky).
  4. Volitelně čeká na vstup člověka pomocí externích událostí.
  5. Buď se dokončí, když agent signalizuje, že je hotovo, nebo pokračuje v cyklu s aktualizovaným stavem.
[Function(nameof(AgentLoopOrchestration))]
public async Task<string> AgentLoopOrchestration(
    [OrchestrationTrigger] TaskOrchestrationContext context)
{
    // Get state from input (supports continue-as-new)
    var state = context.GetInput<AgentState>() ?? new AgentState();

    int maxIterations = 100;
    while (state.Iteration < maxIterations)
    {
        // Send conversation history to the LLM
        var llmResponse = await context.CallActivityAsync<LlmResponse>(
            nameof(CallLlmAgent), state.Messages);

        state.Messages.Add(llmResponse.Message);

        // If the LLM returned tool calls, execute them in parallel
        if (llmResponse.ToolCalls is { Count: > 0 })
        {
            var toolTasks = llmResponse.ToolCalls
                .Select(tc => context.CallActivityAsync<ToolResult>(
                    nameof(ExecuteTool), tc))
                .ToList();
            ToolResult[] toolResults = await Task.WhenAll(toolTasks);

            foreach (var result in toolResults)
                state.Messages.Add(result.ToMessage());
        }
        // If the LLM needs human input, wait for it
        else if (llmResponse.NeedsHumanInput)
        {
            string humanInput = await context.WaitForExternalEvent<string>("HumanInput");
            state.Messages.Add(new Message("user", humanInput));
        }
        // LLM is done
        else
        {
            return llmResponse.FinalAnswer;
        }

        state.Iteration++;

        // Periodically continue-as-new to keep the history bounded
        if (state.Iteration % 10 == 0)
        {
            context.ContinueAsNew(state);
            return null!; // Orchestration will restart with updated state
        }
    }

    return "Max iterations reached.";
}

[DurableTask]
public class AgentLoopOrchestration : TaskOrchestrator<AgentState, string>
{
    public override async Task<string> RunAsync(
        TaskOrchestrationContext context, AgentState? state)
    {
        state ??= new AgentState();

        int maxIterations = 100;
        while (state.Iteration < maxIterations)
        {
            // Send conversation history to the LLM
            var llmResponse = await context.CallActivityAsync<LlmResponse>(
                nameof(CallLlmAgent), state.Messages);

            state.Messages.Add(llmResponse.Message);

            // If the LLM returned tool calls, execute them
            if (llmResponse.ToolCalls is { Count: > 0 })
            {
                var toolTasks = llmResponse.ToolCalls
                    .Select(tc => context.CallActivityAsync<ToolResult>(
                        nameof(ExecuteTool), tc))
                    .ToList();
                ToolResult[] toolResults = await Task.WhenAll(toolTasks);

                foreach (var result in toolResults)
                    state.Messages.Add(result.ToMessage());
            }
            // If the LLM needs human input, wait for it
            else if (llmResponse.NeedsHumanInput)
            {
                string humanInput = await context.WaitForExternalEvent<string>("HumanInput");
                state.Messages.Add(new Message("user", humanInput));
            }
            // LLM is done
            else
            {
                return llmResponse.FinalAnswer;
            }

            state.Iteration++;

            // Periodically continue-as-new to keep the history bounded
            if (state.Iteration % 10 == 0)
            {
                context.ContinueAsNew(state);
                return null!;
            }
        }

        return "Max iterations reached.";
    }
}

Smyčky agentů založené na entitách

Pokud používáte architekturu agenta, která už implementuje vlastní smyčku agenta, můžete ji zabalit do odolné entity a přidat odolnost bez přepsání logiky smyčky. Každá instance entity představuje jedno sezení agenta. Entita přijímá zprávy, deleguje je v rámci agentového rámce interně a ukládá stav konverzace napříč interakcemi.

Klíčovou výhodou tohoto přístupu je jednoduchost: napíšete svého agenta pomocí preferovaného frameworku a odolnost přidáte jako aspekt hostování, aniž byste museli přepracovat řídící tok agenta. Entita funguje jako trvalý obal, který automaticky zajišťuje uchování relací a jejich obnovení.

Následující příklady ukazují, jak integrovat existující sadu SDK agenta, aby se stala odolnou entitou. Entita message zveřejňuje operaci, kterou klienti volají, aby odesílali uživatelský vstup. Entita interně přenáší odpovědnost na agentní framework, který spravuje vlastní cyklus volání nástrojů.

// Define the entity that wraps an existing agent SDK
public class ChatAgentEntity : TaskEntity<ChatAgentState>
{
    private readonly IChatClient _chatClient;

    public ChatAgentEntity(IChatClient chatClient)
    {
        _chatClient = chatClient;
    }

    // Called by clients to send a message to the agent
    public async Task<string> Message(string userMessage)
    {
        // Add the user message to the conversation history
        State.Messages.Add(new ChatMessage(ChatRole.User, userMessage));

        // Delegate to the agent SDK for the LLM call (with tool loop)
        ChatResponse response = await _chatClient.GetResponseAsync(
            State.Messages, State.Options);

        // Persist the response in the entity state
        State.Messages.AddRange(response.Messages);

        return response.Text;
    }

    // Azure Functions entry point for the entity
    [Function(nameof(ChatAgentEntity))]
    public Task RunEntityAsync([EntityTrigger] TaskEntityDispatcher dispatcher)
    {
        return dispatcher.DispatchAsync<ChatAgentEntity>();
    }
}

// Define the entity that wraps an existing agent SDK
[DurableTask(Name = "ChatAgent")]
public class ChatAgentEntity : TaskEntity<ChatAgentState>
{
    private readonly IChatClient _chatClient;

    public ChatAgentEntity(IChatClient chatClient)
    {
        _chatClient = chatClient;
    }

    // Called by clients to send a message to the agent
    public async Task<string> Message(string userMessage)
    {
        // Add the user message to the conversation history
        State.Messages.Add(new ChatMessage(ChatRole.User, userMessage));

        // Delegate to the agent SDK for the LLM call (with tool loop)
        ChatResponse response = await _chatClient.GetResponseAsync(
            State.Messages, State.Options);

        // Persist the response in the entity state
        State.Messages.AddRange(response.Messages);

        return response.Text;
    }
}

Tento přístup používá rozšíření Durable Task pro Microsoft Agent Framework. Konfiguruje agenty Microsoft Agent Framework jako odolné entity jedním řádkem konfigurace, poskytuje trvalé relace, automatické vytváření kontrolních bodů a integrované koncové body rozhraní API.

Další kroky

  • Poslední aktualizace v