Tavily web search and extract for AppKit apps

未關閉
  • 哪裡不對？
#468 4 則留言 0 個 reaction 已指派 0 人 在 GitHub 檢視

維護者通常 3 天內回覆

還沒有人認領這個 Issue。

評估

難度
5/5
預估耗時
一週以上
新手友好度
35/100
Issue 類型
功能
描述清晰度
基本清楚
活躍度
活躍
技術堆疊
node.js, typescript
領域
api, backend, developer-experience

研究方向

先比較提議的 packages/appkit/src/plugins/tavily/ 結構與現有的 genie 和 serving 外掛，然後閱讀 agents 的 ToolProvider contract 以及 appkit 外掛同步慣例。當 search 和 extract、secret manifest、config schema、toolkit integration、測試和文件頁面都已涵蓋，且 packaging、beta-gating 和相依性問題都已解決時，v1 工作即告完成。

由索引模型根據 Issue 內容生成。

描述

Summary

We propose adding a Tavily plugin to AppKit, giving Databricks Apps first-class access to real-time web data: search, content extraction, and (later) crawling and deep research. Tavily is a web access API built specifically for LLMs and agents — results come back as clean, relevance-scored, LLM-ready content rather than raw HTML.

We're the Tavily team, and we'd like to contribute this plugin ourselves — this issue is to align on scope and design before we open the PR.

Motivation

AppKit apps are strong on Lakehouse-native data (analytics, Genie, vector search) but have no built-in way to reach outside the workspace. Common patterns this unlocks:

  • Grounded AI agents — the agents plugin resolves plugin:NAME tool providers; a Tavily plugin exposing a toolkit() would let any AppKit agent do web search/extraction with one line of frontmatter (tools: [plugin:tavily]), complementing Genie and vector-search for questions that need current, external information.
  • RAG enrichment — combine vector-search results over internal docs with fresh web context in serving/agents flows.
  • Data enrichment apps — enrich entities from Lakehouse tables (companies, products, tickers) with live web data.

Proposed design

A core plugin following the existing conventions (packages/appkit/src/plugins/tavily/):

Manifest — one required secret resource (permission: READ) holding the Tavily API key, surfaced via a TAVILY_API_KEY env field, so databricks apps init and appkit plugin sync wire it up like any other resource. No OBO semantics — the key is app-level, like a service principal credential.

Server API — typed methods plus injected routes:

const app = await createApp({ plugins: [new TavilyPlugin({ /* defaults */ })] });

await app.tavily.search("latest EU AI Act enforcement actions", {
  maxResults: 5,
  timeRange: "month",
});
await app.tavily.extract(["https://example.com/report"], { format: "markdown" });
  • POST /api/tavily/search and POST /api/tavily/extract, validated with Zod like other plugins.
  • All outbound calls go through this.execute(), so caching (search results are very cacheable), retry, timeout, and OpenTelemetry tracing come for free from the interceptor chain.

Agents integration — implement the ToolProvider contract (toolkit()), so agents get tavily_search / tavily_extract tools, subject to the existing tool-approval gate.

Config schema (sketch) —

{
  "apiKey": { /* from secret resource / TAVILY_API_KEY */ },
  "search": { "maxResults": 5, "searchDepth": "basic", "includeDomains": [], "excludeDomains": [] },
  "cache": { "ttl": 300000 },
  "timeout": 30000
}

Scope

  • v1: search + extract, manifest, config schema, agents toolkit(), tests, docs page.
  • Later (separate PRs): crawl / map, deep research (long-running — fits the SSE streaming machinery), and optionally an appkit-ui results component.

Open questions for maintainers

  1. Packaging — core plugin in packages/appkit (like genie/serving), or would you prefer third-party integrations in a separate package? This would be the first non-Databricks-service plugin, so happy to follow whatever precedent you want to set.
  2. Beta gating — should it ship via beta-exports initially?
  3. Dependency policy — we'd use the official @tavily/core SDK (MIT); fine, or do you prefer plain fetch for supply-chain reasons?

If this direction sounds good, we'll follow up with the PR.

主要語言
TypeScript
星號
119
分支
36
平均合併
4 天 16 小時
30 天內合併 PR
37

環境準備

  • 沒有 Dockerfile 或 Docker Compose 檔案
  • 沒有 Pull Request 範本
  • 閱讀貢獻指南

從這裡開始

  1. 先讀完整個 Issue，再讀專案的貢獻指南。
  2. 在 Issue 下留言說明你要接手 —— 這能避免兩個人做同樣的事。
  3. Fork 儲存庫，在一個分支上完成修改。
  4. 送出 Pull Request，並在描述裡引用這個 Issue 編號。

databricks/appkit 的其他 Issue

查看 databricks/appkit 的全部 Issue

相似的 Issue

更多 TypeScript Issue

把新 issue 寄到你的電子郵件信箱

精選適合新手參與的 GitHub issue 摘要。