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

[Feature] Define one provider-neutral web search capability contract

Aperta
  • Qualcosa non va?
#28 1 commento 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à
Attiva
Stack tecnologico
typescript
Ambito
ai-infra-agents, backend-api-design

Direzione di ricerca

Start by reading CONTRIBUTING.md and comparing the implementations in #22 and #26, including their native-chat and delegated-task entry points. Define the provider-neutral request and result contract, then verify both adapters against shared fixtures, failure and cancellation behavior, response bounds, delegated evidence, and an unchanged model-visible schema.

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

Descrizione

What outcome should OpenMuse handle?

OpenMuse should expose one stable public-web search capability to its agents even when the backing provider changes.

There are currently two open implementations of the same search_web capability:

  • #22 adds Parallel through a shared SearchService, with input shaped as { objective, search_queries[] } and results shaped around URLs/titles/excerpts/warnings/truncation.
  • #26 adds You.com directly in the conversation agent, with input shaped as { query, count } and a different result shape.

Both are reasonable provider integrations, but the fact that two contributors independently needed the same tool name with incompatible contracts suggests that provider identity is leaking into the agent-facing capability boundary.

Proposed behavior

Define one small, provider-neutral search_web contract owned by OpenMuse, then put provider adapters behind it.

The important invariant would be:

agent capability identity != provider identity

A minimal version could standardize:

  • one request schema for the model-facing tool;
  • one bounded result schema with source URL, title, excerpt/snippet, optional publication metadata, warnings, and truncation;
  • cancellation/deadline behavior;
  • treatment of results as untrusted evidence rather than authority;
  • how delegated tasks persist search evidence;
  • provider selection/configuration separately from the tool contract.

This does not need a generic plugin framework. A narrow SearchProvider/adapter seam would be enough if that is the smallest shape that keeps the model/tool contract stable.

That would let Parallel, You.com, or a future provider compete behind the same capability without changing prompts, model schemas, persisted evidence, or tests each time.

How would we verify it works?
  • Contract-test at least two provider adapters against the same request/result fixtures.
  • Run the same native-chat and delegated-task test against each adapter.
  • Verify provider failures remain visible rather than becoming empty success.
  • Verify cancellation and response-size bounds are preserved.
  • Verify delegated-task evidence has the same shape regardless of provider.
  • Verify changing providers does not change the model-visible tool schema.

This seems worth agreeing on as an issue first because it affects connector placement and architecture, per CONTRIBUTING.md.

AI-use note: I used an AI assistant to compare the current #22/#26 implementations and draft this issue; I verified the incompatible schemas and runtime placement against their current PR heads before filing.

Lingua principale
TypeScript
Stelle
5.2k
Fork
730
Merge medio
3g 20h
PR unite (30g)
96

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 CopilotKit/openmuse

Tutte le issue di CopilotKit/openmuse

Issue simili

Altre issue su TypeScript

Ricevi le nuove issue nella tua casella

Un breve riepilogo di issue GitHub adatte ai principianti.