Proposal: Handoff agent-workflow builder (agentworkflow.NewHandoffWorkflowBuilder)

Aperta
#520 0 commenti 0 reazioni 0 assegnatari Vedi su GitHub

I maintainer di solito rispondono entro 1 giorno

Nessuno ha ancora preso questa issue.

Valutazione

Difficoltà
5/5
Tempo stimato
Più di una settimana
Idoneità per principianti
25/100
Tipo di issue
Funzionalità
Chiarezza
Da chiarire
Stato di attività
Tranquilla
Stack tecnologico
go
Ambito
ai, backend

Direzione di ricerca

Inizia da docs/dotnet-go-sdk-feature-comparison.md e dai builder esistenti in workflow/agentworkflow, quindi esamina i package agent e workflow per la gestione attuale di executor-graph e group-chat manager. Esamina la semantica di .NET HandoffBuilder e risolvi le domande di progettazione elencate prima dell’implementazione. Il lavoro sarà considerato completato quando saranno concordati un’API e un comportamento per il routing delle conversazioni condivise tra agenti, con test e documentazione corrispondenti.

Scritto dal modello di indicizzazione a partire dal testo della issue.

Descrizione

Gap

docs/dotnet-go-sdk-feature-comparison.md marks the agent-workflow builders as Partial: Go has NewSequentialWorkflowBuilder, NewConcurrentWorkflowBuilder, and NewGroupChatWorkflowBuilder, but the doc notes "Handoff and Magentic builders are not yet implemented." There is no handoff reference anywhere in workflow/ or agent/ today.

Handoff is the missing member of the core orchestration set and the more broadly useful of the two gaps: a triage/router agent hands control to a specialist based on the conversation; the specialist can hand back, or on to another agent.

Proposed shape (seeking design alignment before any code)

A sibling builder in workflow/agentworkflow, matching the existing builders' convention (New…WorkflowBuilder(agents ...*agent.Agent), WithName / WithDescription / WithOutputFrom, Build() (*workflow.Workflow, error)):

agentworkflow.NewHandoffWorkflowBuilder(triage).
    WithHandoff(triage, billing, refunds).
    WithHandoff(billing, triage).
    Build()

Modeled on .NET's HandoffBuilder (Microsoft.Agents.AI.Workflows): each participating agent is given handoff tools (one per allowed target); when the agent calls a handoff tool, the workflow routes the turn to that target carrying the shared conversation. Under the hood it should compose onto the existing executor graph / group-chat manager plumbing rather than introduce a new engine.

Design questions I'd want the team's steer on first

  1. Handoff surfaced as auto-injected function tools (the .NET approach), vs. an edge condition on the agent's chosen target?
  2. Reuse the group-chat manager machinery, or a dedicated handoff executor?
  3. Termination: an explicit end agent, a max-turns cap, or a "no handoff called → done" signal?
  4. Scope handoff only for this issue; track Magentic separately?

Why I'm asking first

This is a feature, not a bug fix, so I don't want to drop an unsolicited large PR that then rots. If the team is open to it and we can agree on the shape (tools-vs-edges especially), I'm happy to implement it with the same test rigor as the recent fixes, matching the .NET semantics for cross-SDK parity.

Lingua principale
Go
Stelle
659
Fork
67
Merge medio
14h 51m
PR unite (30g)
81

Preparare l'ambiente

Come iniziare

  1. Leggi tutta la issue e poi la guida ai contributi del progetto.
  2. Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
  3. Fai un fork del repository e lavora su un branch.
  4. Apri una pull request che faccia riferimento al numero della issue.

Altre issue di microsoft/agent-framework-go

Tutte le issue di microsoft/agent-framework-go

Issue simili

Altre issue su Go

Ricevi le nuove issue nella tua casella

Un breve riepilogo di issue GitHub adatte ai principianti.