[Feature] Define one provider-neutral web search capability contract
维护者通常 1 天内回复
还没有人认领这个 Issue。
评估
- 难度
- 5/5
- 预计耗时
- 一周以上
- 新手友好度
- 35/100
- Issue 类型
- 功能
- 描述清晰度
- 基本清楚
- 活跃度
- 活跃
- 技术栈
- typescript
调研方向
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 小时
- 30 天内合并 PR
- 96
环境准备
- 没有 Dockerfile 或 Docker Compose 文件
- 有 Pull Request 模板
- 阅读贡献指南
从这里开始
- 先读完整个 Issue，再读项目的贡献指南。
- 在 Issue 下留言说明你要接手 —— 这能避免两个人做同样的事。
- Fork 仓库，在一个分支上完成修改。
- 提交 Pull Request，并在描述里引用这个 Issue 编号。
CopilotKit/openmuse 的其他 Issue
-
"Contains" page watch never matches when its text has a trailing space可能已有人在做 @RaphaelFakhri 于 1 天前认领。 未关闭
难度 2/5 1-3 小时 新手友好度 77/100
CopilotKit/openmuse#184 ·
维护者通常 1 天内回复
-
Tests: telemetry probes can exceed their 15s execFile timeout on Windows (cold tsx transpile + AV scanning)可能已有人在做 @sean0407 于 10 天前认领。 未关闭
难度 2/5 1-3 小时 新手友好度 62/100
CopilotKit/openmuse#176 ·
维护者通常 1 天内回复
-
难度 4/5 3-5 天 新手友好度 24/100
CopilotKit/openmuse#181 ·
维护者通常 1 天内回复
-
难度 5/5 一周以上 新手友好度 25/100
CopilotKit/openmuse#179 ·
维护者通常 1 天内回复
-
难度 4/5 3-5 天 新手友好度 35/100
CopilotKit/openmuse#153 ·
维护者通常 1 天内回复
查看 CopilotKit/openmuse 的全部 Issue
相似的 Issue
-
area: repo priority: P2 type: bug
难度 2/5 1-3 小时 新手友好度 76/100
appandflow/stim#4107 · 1 条评论 ·
维护者通常 1 天内回复
-
community first-timers-only good first issue hacktoberfest help wanted low hanging fruit up-for-grabs
难度 1/5 1-3 小时 新手友好度 60/100
lingdojo/kana-dojo#32859 · 1 条评论 · 5 个 reaction ·
维护者通常 1 天内回复
-
code-quality refactoring
难度 2/5 1-3 小时 新手友好度 78/100
github/gh-aw-firewall#10364 ·
维护者通常 1 天内回复
-
Merge the duplicate kaffir_corn record into sorghum可能已有人在做 @Crypto-Shroom 今天认领。 未关闭
难度 2/5 1-3 小时 新手友好度 65/100
Crypto-Shroom/Bird-Feed-Calculator#322 ·
维护者通常 1 天内回复
-
难度 2/5 1-3 小时 新手友好度 75/100
drizzle-team/drizzle-orm#6552 ·
维护者通常 2 天内回复