# 预注册：渠道管理商文档的 agent 集成实测

**状态：已预注册，尚未开始。** 本页发布于 2026-10-11，发布时**零条结果**。样本规则与判定阈值在此冻结；测试跑完后在本页追加结果，**不修改本页上半部分**。

## 要检验的命题

一个被广泛预测的结论是：随着 computer use 与编程 agent 成熟，「替商家在多个平台之间搬运/同步数据」会变成通用能力，不再需要专门的供应商。

这个预测有一个今天就能测的必要条件：**agent 能否仅凭公开文档，对这些平台完成一次真实集成。** 如果不能，预测至少在今天不成立。

## 测什么

让一个编程 agent 在**零人工干预**下，**只用公开文档**，对目标服务完成一次**会改变状态的写操作**（取得凭据 → 调通一个写接口）。

- 只读接口不算通过。读通常容易得多，而搬运工作的本质是写。
- 「人工干预」包括：提示它文档在哪一页、告诉它该用哪个 API 版本、替它修任何一行代码。
- 每个目标跑 3 次独立试验，取通过次数。

## 样本怎么选（机械规则，无人工挑选）

提出这个命题的人（包括本站作者）有立场，**所以样本不能由他挑**。规则如下，先于取数确定：

1. **全集** = Airbnb 官方 partner 列表 ∩ Booking.com Connectivity Partners 列表的**交集**。两份名单都是公开页面，交集是客观运算。
2. **全取，不筛。** 不因为某家「文档看起来很差」或「看起来很好」而剔除。
3. **没有公开 API 文档的不剔除**，单独记为一类并计入分母。理由：「没有公开文档 ⇒ agent 无从集成」本身就是对命题的回答，把它剔掉等于偷偷偏向结论。
4. 名单解析完成后**连同解析日期与两个来源 URL 一起公布**，之后不再增删。

## 对照组

| 对照 | 对象 | 作用 |
|---|---|---|
| **正对照** | Stripe API | 「现在都是 agent 来集成」这个说法最初就是以 Stripe 为例的。**它必须通过。如果它不通过，说明是测试装置坏了，不是 Stripe 不行**，结果整体作废重做 |
| **负对照** | Shopify Admin API | 公认文档质量很高。如果它也失败，说明判据过严，需要先修判据 |

## 判定阈值（预先写死）

以全集的通过率计：

| 通过率 | 判定 |
|---|---|
| **≥ 50%** | agent 确实能仅凭文档完成集成 ⇒ 支持「搬运会被通用能力吃掉」 |
| **< 20%** | 窗口期真实存在 ⇒ **不支持**该预测，提出它的人（含本站作者）判断有误 |
| **20% – 50%** | **不判定。** 记录结果、扩大样本后重跑，不允许向任一方向解读 |

中间档存在的唯一目的是堵住「结果出来后挑一个方向解释」这个口子。

## 会公布什么

每个目标公布：是否有公开文档、3 次试验各自的结果、失败的**具体失败点**（选错 API 版本 / 鉴权流程无法从文档推出 / 字段语义缺失 / 文档与实际行为不一致 / 其他）。失败点的分类比通过率更有用——它指出的是文档里到底缺了什么。

不公布：任何凭据、任何测试过程中写入的数据内容、任何非公开信息。所有写操作都在各服务的沙箱/测试环境内进行；无沙箱环境的目标记为「不可测」而非「失败」。

---

# 修订 1（2026-10-11，仍在零结果状态下）

以上为原始预注册，**一字未改**。下面是同日稍后做出的修订。**修订时仍未进行任何一次试验，结果仍为零条**——这是修订唯一可以被接受的时点。

## 取数记录

| 来源 | URL | 取数时刻（UTC） | 归档 md5 |
|---|---|---|---|
| Airbnb 官方软件合作方目录 | `https://www.airbnb.com/d/software-partners` | 2026-10-11T13:03Z | `e39bf3820cd1362d9b4d02a500a73523` |
| Booking.com Connectivity 落地页 | `https://connect.booking.com/` | 2026-10-11T13:04Z | `db17e34ded6d43dce8d82b16fe4c174a` |

## 发现 1：交集规则无法执行

**Booking.com 不公开 connectivity partner 名单。** 已探测 9 个候选路径（`/partners`、`/providers`、`/partner-directory`、`/sitemap.xml`、Partner Hub 若干），全部 404 或无名单；落地页上的全部链接也逐条看过，通往合作方信息的那条指向需要登录的 `portal.connectivity.booking.com`。

所以原始规则「Airbnb ∩ Booking.com」**的第二个集合不存在于公开信息中**，规则无法按原样执行。

同一页上有一句一手声明，逐字如下：

> In an effort to ensure our teams are able to provide the strong partnership experience, we are pausing integrations with new connectivity providers until further notice.

⚠️ **该页面没有任何日期标注**，因此无法判断这条从何时开始、是否仍然有效。引用它时必须带上这个限定。

这条声明本身与要检验的命题相关，但方向是**第三种机制**：如果最大的 OTA 之一已暂停接纳新的 connectivity provider，那么「跨平台搬运」对一个新进入者来说是被**门槛**挡住的，与 agent 能不能读懂文档无关。它既不支持也不反对原命题，它说的是另一件事。记录在此，不计入任何判据。

## 修订 1-A：样本改为 Airbnb 全部 40 家

新规则：**取 Airbnb 官方 Preferred 目录的全部 40 家，不分层、不筛选。**

为什么**不是**只取 Preferred+ 这 19 家（Airbnb 自己标为 `Airbnb's top performing software partners`）：top performing 大概率意味着资源更多、文档更好、更容易通过测试，而**通过率高正是本站作者所持立场想要的结果**。只取这一层等于给自己发好牌。取全部 40 家既消掉分层选择，也去掉这个偏向。

**Preferred+（19 家）**：AirHost、Guesty、Hostify、Hostfully、Hostaway、Uplisting、Channex、Octorate、stays.net、Kross Booking、Tokeet、Beds24、OwnerRez、Rentals United、Lodgify、Hospitable、Host Platform、SuperHote、TRACK (A TravelNet Solution)

**Preferred（21 家）**：Cloudbeds、Homhero、Smily、CiiRUS、Resly、BookingPal、NextPax、Smoobu、Icnea、Avantio、Host Tools、Streamline VRS、RoomCloud、eviivo、iGMS、RentalReady、GuestWisely、Hostex、ResNexus、Avaibook、Yanolja Cloud Solution

名单到此冻结。分层标签一并记录，用于事后观察有无层级效应——**两层都已在此登记，所以不能等结果出来再挑一层来讲。**

## 发现 2：原始测试的最强判据无法取得

原始协议要求「完成一次会改变状态的写操作」。要对 40 家都做到这一点，需要 40 份沙箱凭据，而取得凭据通常需要先成为对方的商业合作方。**这一步在没有商业关系的前提下对大多数目标不可达。**

这是原始协议设计上的缺陷，不是执行中的意外。诚实的处理是**公开承认最强判据取不到**，并把它替换为明确更弱的判据，**同时把结论强度一起降下来**——而不是悄悄把「写操作」改读成别的东西，再按原来的三档阈值宣布结论。

## 修订 1-B：三阶段，每一阶段的样本边界都是客观属性

| 阶段 | 问什么 | 样本 | 可测性 |
|---|---|---|---|
| **S1** | 是否存在**无需登录即可访问**的公开 API 文档？ | 全 40 家 | 完全可测，判据客观 |
| **S2** | agent 仅凭公开文档，能否产出正确的鉴权流程与正确的版本/端点选择？（对照文档逐条核验，**不需要凭据**） | S1 通过者 | 可测 |
| **S3** | 能否在**不与对方人工接触**的前提下自助取得 API 凭据并完成一次真实写操作？ | 「可自助取得凭据」本身对全 40 家逐一判定，结果决定 S3 样本 | 可能样本很小，**预先声明可能为 0** |

- 需要信用卡才能开试用的，记为「不可测（需付费）」，不记为失败。
- S3 样本为 0 不算测试失败，算**该判据不可得**，并按此报告。

## 修订 1-C：阈值与结论强度

**S1（必要条件，最硬）**

| 无公开文档的比例 | 判定 |
|---|---|
| **> 50%** | 多数目标连文档都不公开 ⇒ agent 无从集成 ⇒ **不支持**「搬运会被通用能力吃掉」，本站作者写进自己判据里的那条结论应当降级 |
| **< 20%** | 文档普遍公开，必要条件普遍满足（**但这不等于 agent 能成功集成**——只是没被第一道门挡住） |
| 20% – 50% | 不判定 |

**S2 / S3**：沿用原始三档（≥50% / <20% / 中间不判），但**结论强度降一级**：S2 只能支持「文档足以推出正确集成方案」，**不能**支持「agent 能完成集成」；只有 S3 能支持后者，而 S3 的样本大概率不足以支撑一般化结论。

**原始那三档阈值不适用于 S1**，因为 S1 问的是另一个问题。把弱判据的结果套进为强判据写的阈值，就是这份预注册本来要防的那件事。

---

# S1 结果（2026-10-11）

**本节在预注册与修订之后写入。预注册部分（本页上半）与修订 1 一字未改。**

> ⚠️ **结果与本站作者的既有判断相反。** 作者此前在自己的项目判据里写下「跨平台数据搬运会被通用 agent 吃掉」，S1 的数据不支持这个判断。这正是预注册的用处：判据写在前面，结果出来时挪不动。

规范：`S1-SPEC.md`，哈希链（每次修订都留痕，跑完不许改）：

```
928b2efd3b68f5cf7faa9818fc84b363  S1-SPEC.md
规范固定时刻(UTC): 2026-10-11T13:52:36Z
2aaa5530cc6cf9d7c096bd796a1e5f79  S1-SPEC.md
修订1时刻(UTC): 2026-10-11T14:00:41Z
dc65f271403d3388c7cc759b99f818c1  S1-SPEC.md
修订2时刻(UTC): 2026-10-11T14:09:31Z
bece9fcac06ffcb836bcaaf1a8e6c043  S1-SPEC.md
修订3时刻(UTC): 2026-10-11T14:26:31Z
```

| 厂商 | 层 | 判定 | 命中判据 | 证据 URL |
|---|---|---|---|---|
| AirHost | Preferred+ | `no_docs` | — | — |
| Guesty | Preferred+ | `gated` | — | `https://docs.guesty.com/` |
| Hostify | Preferred+ | `marketing_only` | — | `https://hostify.com/api` |
| Hostfully | Preferred+ | `marketing_only` | — | `https://api.hostfully.com/` |
| Hostaway | Preferred+ | `public_docs` | endpoint + auth+vpath | `https://api.hostaway.com/documentation` |
| Uplisting | Preferred+ | `public_docs` | spec | `https://uplisting.io/developer` |
| Channex | Preferred+ | `marketing_only` | — | `https://docs.channex.io/` |
| Octorate | Preferred+ | `gated` | — | `https://api.octorate.com/` |
| stays.net | Preferred+ | `no_docs` | — | — |
| Kross Booking | Preferred+ | `no_docs` | — | — |
| Tokeet | Preferred+ | `marketing_only` | — | `https://apidocs.tokeet.com/` |
| Beds24 | Preferred+ | `public_docs` | auth+vpath | `https://beds24.com/en/using-beds24/webdesigner` |
| OwnerRez | Preferred+ | `public_docs` | endpoint + auth+vpath | `https://api.ownerrez.com/` |
| Rentals United | Preferred+ | `public_docs` | spec + auth+vpath | `https://api.rentalsunited.com/` |
| Lodgify | Preferred+ | `blocked` | — | — |
| Hospitable | Preferred+ | `marketing_only` | — | `https://developer.hospitable.com/` |
| Host Platform | Preferred+ | `marketing_only` | — | `https://hostplatform.com/integrations-api/` |
| SuperHote | Preferred+ | `no_docs` | — | — |
| TRACK A TravelNet Solution | Preferred+ | `public_docs` | spec | `https://developer.trackhs.com/docs` |
| Cloudbeds | Preferred | `public_docs` | spec | `https://developers.cloudbeds.com/` |
| Homhero | Preferred | `no_docs` | — | — |
| Smily | Preferred | `no_docs` | — | — |
| CiiRUS | Preferred | `no_docs` | — | — |
| Resly | Preferred | `no_docs` | — | — |
| BookingPal | Preferred | `no_docs` | — | — |
| NextPax | Preferred | `marketing_only` | — | `https://nextpax.com/products/supply-api` |
| Smoobu | Preferred | `public_docs` | endpoint | `https://docs.smoobu.com/` |
| Icnea | Preferred | `marketing_only` | — | `https://developer.icnea.net/` |
| Avantio | Preferred | `public_docs` | endpoint | `https://apidocs.avantio.com/` |
| Host Tools | Preferred | `public_docs` | endpoint + spec | `https://docs.hosttools.com/` |
| Streamline VRS | Preferred | `marketing_only` | — | `https://www.streamlinevrs.com/features/open-api/` |
| RoomCloud | Preferred | `no_docs` | — | — |
| eviivo | Preferred | `public_docs` | auth+vpath | `https://eviivo.com/api` |
| iGMS | Preferred | `marketing_only` | — | `https://api.igms.com/` |
| RentalReady | Preferred | `no_docs` | — | — |
| GuestWisely | Preferred | `marketing_only` | — | `https://secure.guestwisely.io/vros/api/list-api/owner_token//m/default-settings?_gl=1*bm39ry*_gcl_au*NTQ2Nzg0MDg2LjE3NTg3MjE1NTI.` |
| Hostex | Preferred | `public_docs` | spec | `https://api.hostex.io/openapi.json` |
| ResNexus | Preferred | `no_docs` | — | — |
| Avaibook | Preferred | `blocked` | — | — |
| Yanolja Cloud Solution | Preferred | `public_docs` | spec | `https://developers.yanoljacloudsolution.com/` |

### 计数

| 判定 | 家数 |
|---|---|
| `public_docs` | 13 |
| `no_docs` | 12 |
| `marketing_only` | 11 |
| `gated` | 2 |
| `blocked` | 2 |

分母 = 40 − blocked(2) − domain_unresolved(0) = **38**

「无公开文档」= `gated`(2) + `marketing_only`(11) + `no_docs`(12) = **25**

### 比例 = **65.8%**

**> 50% ⇒ 不支持「搬运会被通用能力吃掉」**，本项目作者写进自己判据里的结论应当降级

### 这个结果不能用来说什么

- S1 只验**必要条件**（文档公不公开）。**它不能说明 agent 真的能完成集成**——那是 S2/S3 的事，而 S3 的最强判据（真实写操作）在无商业关系的前提下对多数目标不可得，已在预注册里声明。
- `marketing_only` 与 `gated` 的区别靠正则判，有误判空间；每家的证据 URL 都在上表，可自行复核。
- `blocked` 单列、不计入分母。但「站点对一切非真人流量返回挑战页」本身就意味着 **agent 同样读不到**——这一点不该被当成技术故障抹掉。

### 靠第二个域名才命中的（修订 2-A 的偏向披露）

修订 2-A 把域名改为取并集，只会增加候选、提高通过率——方向**有利于**作者既有判断，故逐家列明：

- **Uplisting**：候选 `uplisting.com` / `uplisting.io`，命中于 `uplisting.io`
- **TRACK A TravelNet Solution**：候选 `track.eu` / `trackhs.com`，命中于 `trackhs.com`
- **Icnea**：候选 `icnea.com` / `icnea.net` / `icnea.co` / `icnea.app` / `icnea.eu`，命中于 `icnea.net`

### 测量规模

总请求 ≈ **826**；其中被软 404 / 通配 DNS 控制组拦下 **53** 次假 200（第一轮没有这个控制组，是作废的原因之一）。