Hacktoberfest 2026：メンテナが10月に向けて印を付けた、オープンで初心者向けの issue。 Hacktoberfest の issue を見る

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

オープン
  • 何か問題がありますか？
#28 コメント 1 件 リアクション 0 件 担当者 0 名 GitHub で見る

メンテナーはふだん 1 日以内に返信

まだ誰も着手していません。

評価

難易度
5/5
見積もり時間
1週間以上
初心者へのやさしさ
35/100
issue の種類
機能追加
明瞭さ
おおむね明確
活発さ
活発
技術スタック
typescript
領域
ai-infra-agents, backend-api-design

調査の方向性

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.

索引モデルが issue の本文から書いたものです。

説明

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.

主要言語
TypeScript
スター
5.2k
フォーク
730
平均マージ
3日 20時間
マージ済み PR（30日）
96

環境構築

はじめの一歩

  1. issue を最後まで読み、次にプロジェクトのコントリビューションガイドを読みます。
  2. 着手することを issue にコメントします — 二人が同じ作業をするのを防げます。
  3. リポジトリをフォークし、ブランチを切って変更します。
  4. issue 番号を参照したプルリクエストを送ります。

CopilotKit/openmuse のほかの issue

CopilotKit/openmuse の issue をすべて見る

似ている issue

TypeScript の issue をもっと見る

新しい issue をメールで受け取る

初心者向けの GitHub issue を短くまとめたダイジェスト。