Hacktoberfest 2026: le issue che i maintainer hanno segnato per ottobre, aperte e adatte ai principianti. Sfoglia le issue Hacktoberfest

Expose a cached agent model and configuration discovery API

Aperta
#1,786 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
35/100
Tipo di issue
Funzionalità
Chiarezza
Abbastanza chiara
Stato di attività
Tranquilla
Stack tecnologico
rust, typescript

Direzione di ricerca

Non vengono indicati file o percorsi dei test. Inizia tracciando il ciclo di vita esistente di disposable probe e session nelle implementazioni basate su Rust, TypeScript e actor. Usa i test di accettazione elencati come definizione di completato, inclusi deduplicazione, caching, errori strutturati e isolamento della pulizia.

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

Descrizione

Problem

AgentOS callers can discover an ACP agent's models and configuration options only by creating a complete disposable session. That makes catalog discovery pay the full adapter spawn, ACP initialize, and session/new cost, and it couples a metadata request to session resources and credentials.

The current probe lifecycle also closes the disposable session without an awaited teardown boundary. A failed or slow probe can leave an adapter process, pending I/O, or VM resources behind and race a real foreground session for the same harness.

GigaCode has had to implement background catalog refresh, probe serialization, cached/default catalogs, per-harness configuration preparation, startup progress, and probe isolation around this lower-level behavior. Provider-response shaping belongs in GigaCode, but the expensive discovery lifecycle does not.

Proposed API

Expose a standard high-level operation that returns the agent's metadata and configuration catalog without requiring every caller to manage a disposable session, conceptually:

discoverAgentCatalog({
  agent,
  environment,
  configuration,
  software,
}) -> {
  agentInfo,
  models,
  configOptions,
  capabilities,
  fingerprint,
  source: "fresh" | "cache",
}

The exact name and shape should follow AgentOS conventions.

Required semantics

  • Cache results by an AgentOS-owned fingerprint of the agent package plus configuration inputs that affect the advertised catalog.
  • Deduplicate concurrent discovery for the same fingerprint.
  • Keep discovery isolated from foreground sessions and their live adapter processes.
  • If an adapter session is required internally, await its complete teardown before resolving.
  • On failure, leave no adapter process, session record, prompt/event pump, or VM resource behind.
  • Return structured stage errors such as adapter spawn failure, ACP initialize timeout, session/new timeout, adapter exit, and invalid package/configuration.
  • Allow explicit invalidation/refresh while making cached reads cheap.
  • Preserve the full stable ACP configOptions shape, including model and thought/reasoning selectors.
  • Provide equivalent Rust, TypeScript, and actor-backed behavior.

Acceptance tests

  • Two concurrent calls for one fingerprint launch at most one probe.
  • A cached call creates no adapter process and performs no ACP bootstrap.
  • A package/configuration fingerprint change causes one fresh discovery.
  • Successful and failed fresh discovery both leave process/session counts at baseline after return.
  • An initialize or session/new timeout reports its real structured stage and performs awaited cleanup.
  • Manual invalidation forces a fresh result without affecting a foreground session.

Outcome

Products can render a model/configuration catalog without owning ACP probe sessions, retry actors, or cleanup workarounds, while retaining their own provider-specific response shaping and refresh UX.

Lingua principale
Rust
Stelle
4.8k
Fork
266
Merge medio
10h 56m
PR unite (30g)
45

Preparare l'ambiente

Questo progetto non fornisce container di sviluppo, Dockerfile né guida per i contributori, quindi l'ambiente è a tuo carico: parti dal suo README e consulta la nostra guida al primo contributo per i passaggi generali.

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 rivet-dev/agentos

Tutte le issue di rivet-dev/agentos

Issue simili

Altre issue su Rust

Ricevi le nuove issue nella tua casella

Un breve riepilogo di issue GitHub adatte ai principianti.