[dotnet-port-api] Port TodoCompletion and BackgroundTaskCompletion loop evaluators (placement decision)

Aperta
  • Qualcosa non va?
#1,163 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à
3/5
Tempo stimato
1-2 giorni
Idoneità per principianti
45/100
Tipo di issue
Funzionalità
Chiarezza
Abbastanza chiara
Stato di attività
Attiva
Stack tecnologico
go
Ambito
backend-api-design

Direzione di ricerca

The issue is about porting two .NET loop evaluators to Go. First, understand the existing loop package structure and the todo and agentmode providers. Review the .NET reference implementations for TodoCompletionLoopEvaluator and BackgroundTaskCompletionLoopEvaluator. The main decision is where to place the new evaluators: either in the loop package (adding dependencies) or in the todo package (keeping loop clean). Start by examining the agent/harness/loop directory and the todo provider. 'Done' means the evaluators are implemented and placed according to maintainer guidance.

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

Descrizione

Following #1162 (AI-judge loop evaluator), the remaining .NET loop evaluators Go still lacks are TodoCompletionLoopEvaluator and BackgroundTaskCompletionLoopEvaluator (DelegateLoopEvaluator is already covered by Go's loop.EvaluatorFunc). Filing issue-first because there is a real placement/coupling decision.

The gap

TodoCompletionLoopEvaluator keeps re-invoking the agent until a TodoProvider has no remaining todos (optionally only while in one of a configured set of agent modes), continuing with feedback listing the remaining items ({remaining_todos}).

The Go design question

.NET resolves the TodoProvider (and AgentModeProvider for the mode gate) at evaluation time from the agent via GetService<T>(). Go has no equivalent — loop.Context exposes InitialMessages, LastResponse, Options, Iteration; the session is reachable via agent.GetOption(ctx.Options, agent.WithSession), but there is no provider-resolution mechanism. So the Go evaluator must take an explicit *todo.Provider (and, for modes, an *agentmode.Provider).

That raises a placement decision, because agent/harness/loop currently imports no sibling harness package:

  1. In loop — mirrors .NET's namespace, but introduces loop → todo (and loop → agentmode) dependencies.
  2. In todo — keeps loop dependency-free; todo imports the loop.Evaluator/Evaluation types (no cycle, since loop does not import todo). Arguably more idiomatic for Go.

I lean toward option 2 (evaluator lives in todo, e.g. todo.NewCompletionLoopEvaluator(p, ...)), keeping the loop package free of harness-specific deps, but this is the maintainers' call. Happy to implement whichever placement you prefer — the logic itself (remaining-todos check + {remaining_todos} feedback + optional mode gate) is straightforward and I have the .NET reference. Same question applies to BackgroundTaskCompletionLoopEvaluator.

Lingua principale
Go
Stelle
659
Fork
67
Merge medio
18h 49m
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.