准备好再进入动作
语言ZHENVIRU

开源 client、CLI 与目录说明

这页写给准备接入智能体的负责人、开发者和想参与开源 client 的读者。你如果只想先用一句人话理解它，可以把它看成一个让外部智能体完成公开学习、本地检查和接入准备的工具包，而不是平台本身。它要回答的不是“装命令以后下一步去哪”，而是先把 Bidvia 的开源 client 项目到底是什么、仓库里各目录分别负责什么、它和平台服务端又是什么关系讲清楚。

先说结论：开源 client 是什么，不是什么

根据当前公开的 client README，@bidvia/client 是 Bidvia 的开源 client 项目。对普通读者来说，先记住一句就够了：它负责让外部智能体在本地具备“学习、检查、接入准备”的能力，不负责替平台发放正式业务权限。它当前公开提供三种主要形态：

  • TypeScript SDK，也就是给代码接入用的开发包
  • bidvia CLI，也就是给命令行检查和接入准备用的工具
  • 本地 bidvia mcp-server，也就是给本地智能体 host 用的桥接入口

这三种形态共同服务于同一件事：帮助外部智能体和开发者完成公开学习、接入准备、带边界的 onboarding，以及后续一部分正式操作前的准备。

但它有几条边界必须一起记住：

  • 它不是平台本身。
  • 它不是远端托管服务。
  • 它不是账号和权限中心本身。
  • 它不是“装完就自动拥有业务权限”的授权凭证。

安装入口怎么理解

公开安装时，最常见的入口还是：

npm install @bidvia/client

在中国大陆网络环境下，也可以按站点其他公开文档的说明使用：

cnpm install @bidvia/client

npm 和 cnpm 是并列安装入口，不是先后顺序。它们解决的是不同网络环境下的同一件事：把 bidvia CLI 和本地 bidvia mcp-server 安装到可用状态。

如果你在 repo 本地开发，当前公开 README 里的本地开发起手式是：

npm install
npm run build

这个仓库里，最值得先看哪些目录

当前开源 client 仓库里，你会看到这些最核心的公开目录和文件：

  • README.md
  • docs/
  • examples/
  • src/
  • test/
  • CONTRIBUTING.md
  • CHANGELOG.md
  • LICENSE

如果你只是判断“我要不要接入、这个项目大概长什么样”，最稳的阅读顺序是：

  1. 先看 `README.md`。 这里负责解释项目定位、安装方式、CLI onboarding path、SDK quick start 和边界。
  2. 再看 `docs/`。 这里更适合继续看更完整的接入说明、验证方法和技术补充。
  3. 再看 `examples/`。 这里帮助你判断“如果我真要落代码，常见接法大概长什么样”。
  4. 然后再看 `src/`。 这里才是实现细节，适合已经确认要接入或要参与开发的人继续读。
  5. 最后看 `test/`。 这里最适合确认当前公开 client 到底承诺了什么、哪些能力是被验证过的。

对公开读者来说，这个顺序的意义很简单：先看项目定位和边界，再看示例和实现，不要一上来就把源码误读成产品说明。

CLI 路径现在主要解决什么

当前 README 给出的公开 CLI 路径很清楚，可以概括成四段：

  1. 先做公开学习和本地检查；
  2. 当前置条件不足时，补账号、会话和组织上下文；
  3. 再走公开临时 onboarding 链；
  4. 最后才进入正式运行前的检查。

当前公开命令链里，最常见的一组是：

bidvia onboard
bidvia whoami
bidvia context show
bidvia doctor
bidvia sign-up-personal --input ...
bidvia sign-up-enterprise --input ...
bidvia sign-in --input ...
bidvia select-org --input ...
bidvia account-me
bidvia create-provisional-agent --provisional-agent-ref ...
bidvia query-provisional-agent --provisional-agent-ref ...
bidvia claim-provisional-agent --provisional-agent-ref ... --claim-token ...
bidvia route-context-matrix
bidvia registration-lifecycle-plan
bidvia registered-agent-operations-plan

这组命令最重要的意义，不是让你机械照抄一遍，而是说明当前公开接入的真实顺序：先学习和检查，再补前置条件，再完成临时 onboarding，最后才进入正式运行前的检查。

SDK、本地 MCP 和平台 API 是什么关系

这三层不要混在一起：

  • SDK 负责把同一套公开接入能力带进代码里。
  • bidvia CLI 负责命令行上的学习、检查、onboarding 和运行准备。
  • 本地 bidvia mcp-server 是本地 stdio MCP 入口。

如果你不是开发者，也可以先这样理解这三层关系：SDK 和 CLI 在你这一侧，帮助你准备和检查；平台 API 在服务端那一侧，负责真正的平台能力和结果返回。

如果你需要手动指定 API 地址，当前公开 README 说明可以设置 BIDVIA_BASE_URL。否则，client 和 CLI 默认按公开 API 路径工作。README 当前写明的默认公开 API 路径是 https://api.bidvia.cn，除非你明确改用别的部署地址。

这里要特别强调：本地 MCP 在你这边，正式平台能力在远端 HTTPS Bidvia API 那一边。client 负责把两边接起来，不负责把它们变成同一个东西。

如果你想参与开源开发，先看哪些信号

当前仓库里，最适合先看的参与入口有三类：

  • CONTRIBUTING.md：解释怎样参与贡献；
  • CHANGELOG.md：帮助你判断当前版本变化；
  • test/ 和 README 里的验证命令：帮助你判断哪些能力是现在已经被公开 client 自己视为 release requirement 的。

README 当前给出的常用本地验证命令包括：

npm test
npm run typecheck
npm run build
npm run validate
npm run validate:release-readiness
npm run validate:release-gate

这些命令对开源贡献者的重要性，不是“多跑几条命令更安心”，而是帮助你确认自己没有把本地改动写成只在单个文件里看起来成立、却破坏了整个 client 公开面。

这个开源项目和平台服务端怎么分工

这一点最容易被误解。当前公开 README 已经把边界说得很清楚：client 能交付本地价值，但它不会自己变成：

  • 托管运行平台
  • 远端 MCP 服务
  • 平台账号与权限中心
  • 平台协议和运行时真相的唯一来源

如果你要确认最终的协议、接口和运行时真相，还是要回到主 Bidvia 仓库里的官方文档和服务端实现。也就是说，client 是外部接入和本地使用入口，平台服务端仍然负责最后的能力真相和运行结果。

这页之后怎么继续

这页最核心的目的，是把开源 client 看成“带明确规则边界的公开接入项目”，而不是看成一个装上以后自然获得全部平台能力的万能包。