Proposal: optional authenticated MCP web-evidence workflow (Baizhi)
まだ誰も着手していません。
評価
- 難易度
- 4/5
- 見積もり時間
- 3〜5日
- 初心者へのやさしさ
- 35/100
調査の方向性
Read yaml_instance/deep_research_v1.yaml and the existing mcp_remote implementation, then inspect the workflow-list and Launch entry points. The proposal asks whether this credential-specific workflow is in scope, not for a defined implementation; first seek maintainer guidance on location and validation. If approved, done would include the optional YAML and English/Chinese setup instructions, plus the proposed host, credential, error, cleanup, and exposure checks.
索引モデルが issue の本文から書いたものです。
説明
Disclosure: this is a vendor-affiliated proposal for Baizhi Cloud. I would like to check whether a small, optional DevAll 2.0 workflow is within the project's contribution scope.
For users who already have a Baizhi account, the proposed workflow would collect public web evidence and produce a short, source-linked comparison or fact-check. The current deep_research_v1.yaml uses the in-repo web functions, whose search and page-reading implementations use Serper and Jina. This would be an alternative using the user's existing Baizhi credentials, rather than a replacement for that workflow or a new vendor-specific Python provider.
The proposed addition is yaml_instance/web_evidence_baizhi.yaml, with short English and Chinese setup instructions:
- An evidence-collection agent actually binds remote MCP tools for search, page reading and structured extraction. It should retain source URLs, distinguish quoted page evidence from inference, and report unavailable information instead of inventing it.
- A separate review agent checks the collected evidence and produces the final answer; it does not need another remote tool binding.
- The YAML contains environment-variable references only. Selecting and launching this workflow is optional; existing workflows remain usable without a Baizhi key.
The connection fragment for the collection agent would reuse the existing implementation:
tooling:
- type: mcp_remote
prefix: baizhi
config:
server: https://agent-toolkit.app.baizhi.cloud/mcp
headers:
Authorization: Bearer ${BAIZHI_API_KEY}
timeout: 30
The public integration documentation documents Streamable HTTP/Bearer authentication and websearch_search, web_scrape, and web_extract. Actual argument schemas would come from MCP discovery. A least-privilege key should be configured by the operator, outside the committed workflow. This is not a claim that prompts restrict server-side permissions.
A Baizhi account and the user's own key are required; calls may consume paid credits. Tool arguments go to the hosted service and returned evidence may go to the configured model. The public repository contains integration materials, not the hosted backend source. The proposed example is for public, non-sensitive research inputs.
I have statically traced the current main configuration interpolation, Streamable HTTP headers, tool discovery/call and result handling, and the workflow-list/Launch entry. I have not run a ChatDev host/GUI or live Baizhi/model test. Before any implementation PR, verification would need to cover the actual host with a synthetic MCP service, missing/invalid credentials, errors and cleanup, and inspect logs/artifacts for credential exposure. No compatibility or production-success claim is intended at this stage.
Would this optional, credential-specific workflow be useful and acceptable in yaml_instance/, or would you prefer another contribution location? I would also welcome guidance on the expected validation for such a workflow. I noted the functional naming guidance in #555, the requirement for real crawling/tool execution in #561, and the preference for reusing generic abstractions in #594; the proposal follows those boundaries.
- 主要言語
- Python
- スター
- 34.5k
- フォーク
- 4.3k
- PR マージ指標
- 30日以内にマージされた PR はありません
環境構築
- Dockerfile または Docker Compose ファイルあり
- プルリクエストのテンプレートなし
- コントリビューションガイドなし
はじめの一歩
- issue を最後まで読み、次にプロジェクトのコントリビューションガイドを読みます。
- 着手することを issue にコメントします — 二人が同じ作業をするのを防げます。
- リポジトリをフォークし、ブランチを切って変更します。
- issue 番号を参照したプルリクエストを送ります。
OpenBMB/ChatDev のほかの issue
-
難易度 1/5 1時間未満 初心者へのやさしさ 76/100
-
CodeReviewModification never shows the programmer the six review regulations, so fixes are made blind to the checklist they are re-reviewed against対応中かも このイシューにリンクされたプルリクエストがオープン中、またはマージ済みです。 オープン
難易度 1/5 1〜3時間 初心者へのやさしさ 78/100
-
難易度 1/5 1時間未満 初心者へのやさしさ 85/100
-
FunctionManager silently drops tool modules containing dataclasses with postponed annotations対応中かも @inchang-ing が 13 日前に担当しました。 オープン
難易度 3/5 1〜2日 初心者へのやさしさ 72/100
-
難易度 4/5 3〜5日 初心者へのやさしさ 35/100
OpenBMB/ChatDev の issue をすべて見る
似ている issue
-
難易度 1/5 1時間未満 初心者へのやさしさ 82/100
esphome/esphome.io#7657 ·
メンテナーはふだん 1 日以内に返信
-
comp/gateway comp/plugins duplicate P3 type/bug
難易度 2/5 1〜3時間 初心者へのやさしさ 82/100
NousResearch/hermes-agent#137019 ·
メンテナーはふだん 1 日以内に返信
-
bug
難易度 2/5 1〜3時間 初心者へのやさしさ 72/100
メンテナーはふだん 1 日以内に返信
-
Kumo-Tabular weights unreachable behind restrictive egress proxies (Xet + plain HTTP both fail)オープン
難易度 2/5 1〜3時間 初心者へのやさしさ 67/100
NVIDIA/structured-data-models#1091 ·
メンテナーはふだん 1 日以内に返信
-
[work-item] adam-adae-worsening-emergence: conform spec.yaml to the specification style contract (REQ-1280)対応中かも @muse-yamaa-bot が今日担当しました。 オープンwork-item
難易度 1/5 1〜3時間 初心者へのやさしさ 82/100
メンテナーはふだん 1 日以内に返信