Сторонние системы и публичные интерфейсы

在 Bidvia 里，第三方系统接入不是把一个外部系统随便连上来就结束。更准确地说，平台要求先回答六个问题：

1. 这个系统提供的是资料、状态，还是要负责承接某个动作？
2. 它对应的是哪个业务对象和哪个流程环节？
3. 谁授权它参与这次协作？
4. 它产生的写入结果有没有回执和证据？
5. 出错时谁处理、怎样停在安全状态？
6. 这些结果怎样回到 Bidvia 的对象、凭证和责任链里？

如果这六个问题没说清，所谓“系统接入”通常只是多接了一条不透明的数据线，而不是多了一条可靠协作路径。

对公开读者来说，第三方系统最容易理解成三类角色：

• 资料来源。 例如 ERP 提供客户、订单、商品或库存资料。
• 状态来源。 例如 WMS、财务、审批、海关或税务系统返回某个处理状态、回执或结果。
• 动作承接方。 某些正式动作会由 Bidvia 路由到外部系统执行，然后再把回执和结果带回来。

这三类角色都可以进入平台，但都不能直接绕过 Bidvia 的对象、流程、凭证和责任链。平台不是为了让系统替人拍板，而是为了把系统参与放进可追溯、可复核的协作结构里。普通读者只要先把这三类角色分清，后面的技术规则就不容易看混。

根据主 Bidvia 仓库当前文档和测试，平台已经明确把第三方系统接入理解成范围有限、规则清楚、结果可证明的系统类型，而不是完全开放的任意外部生态。

当前已明确出现的系统类型至少包括：

• WMS-class system
• ERP-class inventory/order system

这意味着平台现在公开能说明的，不是“任何系统都能随便接”，而是已经有一套范围有限、规则清楚的接入标准，正在围绕这些系统类型建立可复用的接入模式。

主 Bidvia 仓库里的第三方 connector слой выполнения standard 已经把最基本的接入条件写清楚。一个第三方 connector 想被看作符合标准，至少要满足这些条件：

1. Bidvia 能和它完成可靠认证，例如当前标准里要求 JWT。
2. 读写请求都遵循约定好的请求结构，而不是每个系统各说各话。
3. 成功和失败结果都按约定好的返回结构交回平台。
4. 它会保留必要的调用链信息，方便后续追踪是谁在什么时候发起了什么动作。
5. 写操作会返回系统侧回执，证明外部动作真的发生过。
6. Bidvia 能把外部系统的回执整理成自己平台内可继续追踪的记录。
7. 失败路径必须停在安全状态，而不是默默放过错误。

对接入方来说，这七条非常重要，因为它们说明平台真正看重的不是“能不能调通一次”，而是“能不能把一次系统动作变成可追溯、可复核的协作证据”。

同一份 слой выполнения standard 里还写明了当前第一个符合标准的 connector 目标：

• integration_code = haisi-wms
• target system = Haisi WMS v3.0
• connector deployment model = independent HTTP service owned by the WMS side

这三个事实说明，当前平台对第三方系统接入的理解很克制：

• connector 可以由系统侧独立拥有；
• Bidvia 通过约定好的接口规则和回执证据把它纳入协作；
• 样板是 WMS，但标准本身不是 Haisi 专用标准，而是要继续复用于其他第三方系统。

这也是最容易被混淆的一层。对公开读者来说，可以先分成三层：

1. 网站前门。 浏览器先进入官网页面，例如 документация、Вселенная、Integrations、Подключить агента。
2. 公开接口前门。 开源 client 和 SDK 会走公开 API 路径进行读取、onboarding 和后续正式操作前的准备。
3. 服务端运行时真相。 某个接口当前是否可用、某个集成是否展示、某个动作是否允许继续，最终都取决于服务端配置和返回状态。

当前公开 client README 写明，CLI 和 SDK 默认按 https://api.bidvia.cn 这条公开 API 路径工作，除非你有意选择其他部署地址。主 Bidvia 仓库的环境参数文档同时说明：未来可能会出现其他 global/public API front door，但真正的运行时真相仍然由服务端部署和配置决定。

对网站文案来说，这意味着一条硬边界：页面可以解释角色和路径，但不能把“未来可能存在的公开 API 前门”写成“当前所有能力都已经公开开放”。

在公开站点的表达里，统一接入中心和 Integration App 更像是系统接入的治理入口，不是能力承诺本身。它们至少要负责四件事：

• 解释某类系统扮演什么角色；
• 告诉你需要准备哪些对象、字段、凭证和授权信息；
• 告诉你当前展示状态是不是已经等于可安装、可启用或可运行；
• 把真正的安装、批准、启用和运行状态交还给服务端返回结果。

因此，某个集成出现在页面上，不等于你已经能直接用；某个集成暂时没展示，也不代表平台永远不支持。公开页面负责解释路由，运行时状态负责说明现在能不能继续。

如果你准备把 ERP、WMS、财务、审批、海关、税务或其他系统接到 Bidvia，最少先补齐下面这些信息：

• 这个系统在这次协作里是资料来源、状态来源，还是动作承接方；
• 它对应哪些对象、字段和流程环节；
• 谁负责授权；
• 哪些结果会写回外部系统；
• 写回后会产生什么回执；
• 冲突、失败和超时由谁处理；
• 哪些动作必须保留人工确认。

只有这些边界先清楚，系统接入才会增强协作，而不是把原本已经复杂的责任链再打乱一次。

• 想先看企业怎样开始试点，去 面向企业
• 想继续看 агент 侧接入顺序，去 面向 агент
• 想看智能体在任务派发后怎样提交结果、证据和闭环状态，去 智能体任务平面与有界闭环
• 想看开源 client、CLI 和本地 MCP 的目录说明，去 开源 client、CLI 与目录说明
• 想回到开始顺序，去 接入与开始使用

这页最核心的结论是：Bidvia 允许第三方系统进入商业协作，但进入方式必须是受控、可回执、可追溯、失败能安全收口的，而不是一条“连上就自动可用”的机械 API 通道。