状态：已预注册，尚未开始。 本页发布于 2026-10-11，发布时零条结果。样本规则与判定阈值在此冻结；测试跑完后在本页追加结果，不修改本页上半部分。
一个被广泛预测的结论是：随着 computer use 与编程 agent 成熟，「替商家在多个平台之间搬运/同步数据」会变成通用能力，不再需要专门的供应商。
这个预测有一个今天就能测的必要条件：agent 能否仅凭公开文档，对这些平台完成一次真实集成。 如果不能，预测至少在今天不成立。
让一个编程 agent 在零人工干预下，只用公开文档，对目标服务完成一次会改变状态的写操作（取得凭据 → 调通一个写接口）。
提出这个命题的人（包括本站作者）有立场，所以样本不能由他挑。规则如下，先于取数确定：
| 对照 | 对象 | 作用 |
|---|---|---|
| 正对照 | Stripe API | 「现在都是 agent 来集成」这个说法最初就是以 Stripe 为例的。它必须通过。如果它不通过，说明是测试装置坏了，不是 Stripe 不行，结果整体作废重做 |
| 负对照 | Shopify Admin API | 公认文档质量很高。如果它也失败，说明判据过严，需要先修判据 |
以全集的通过率计：
| 通过率 | 判定 |
|---|---|
| ≥ 50% | agent 确实能仅凭文档完成集成 ⇒ 支持「搬运会被通用能力吃掉」 |
| < 20% | 窗口期真实存在 ⇒ 不支持该预测，提出它的人（含本站作者）判断有误 |
| 20% – 50% | 不判定。 记录结果、扩大样本后重跑，不允许向任一方向解读 |
中间档存在的唯一目的是堵住「结果出来后挑一个方向解释」这个口子。
每个目标公布：是否有公开文档、3 次试验各自的结果、失败的具体失败点（选错 API 版本 / 鉴权流程无法从文档推出 / 字段语义缺失 / 文档与实际行为不一致 / 其他）。失败点的分类比通过率更有用——它指出的是文档里到底缺了什么。
不公布：任何凭据、任何测试过程中写入的数据内容、任何非公开信息。所有写操作都在各服务的沙箱/测试环境内进行；无沙箱环境的目标记为「不可测」而非「失败」。
以上为原始预注册，一字未改。下面是同日稍后做出的修订。修订时仍未进行任何一次试验，结果仍为零条——这是修订唯一可以被接受的时点。
| 来源 | 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 |
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 能不能读懂文档无关。它既不支持也不反对原命题，它说的是另一件事。记录在此，不计入任何判据。
新规则：取 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
名单到此冻结。分层标签一并记录，用于事后观察有无层级效应——两层都已在此登记，所以不能等结果出来再挑一层来讲。
原始协议要求「完成一次会改变状态的写操作」。要对 40 家都做到这一点，需要 40 份沙箱凭据，而取得凭据通常需要先成为对方的商业合作方。这一步在没有商业关系的前提下对大多数目标不可达。
这是原始协议设计上的缺陷，不是执行中的意外。诚实的处理是公开承认最强判据取不到，并把它替换为明确更弱的判据，同时把结论强度一起降下来——而不是悄悄把「写操作」改读成别的东西，再按原来的三档阈值宣布结论。
| 阶段 | 问什么 | 样本 | 可测性 |
|---|---|---|---|
| S1 | 是否存在无需登录即可访问的公开 API 文档？ | 全 40 家 | 完全可测，判据客观 |
| S2 | agent 仅凭公开文档，能否产出正确的鉴权流程与正确的版本/端点选择？（对照文档逐条核验，不需要凭据） | S1 通过者 | 可测 |
| S3 | 能否在不与对方人工接触的前提下自助取得 API 凭据并完成一次真实写操作？ | 「可自助取得凭据」本身对全 40 家逐一判定，结果决定 S3 样本 | 可能样本很小，预先声明可能为 0 |
S1（必要条件，最硬）
| 无公开文档的比例 | 判定 |
|---|---|
| > 50% | 多数目标连文档都不公开 ⇒ agent 无从集成 ⇒ 不支持「搬运会被通用能力吃掉」，本站作者写进自己判据里的那条结论应当降级 |
| < 20% | 文档普遍公开，必要条件普遍满足（但这不等于 agent 能成功集成——只是没被第一道门挡住） |
| 20% – 50% | 不判定 |
S2 / S3：沿用原始三档（≥50% / <20% / 中间不判），但结论强度降一级：S2 只能支持「文档足以推出正确集成方案」，不能支持「agent 能完成集成」；只有 S3 能支持后者，而 S3 的样本大概率不足以支撑一般化结论。
原始那三档阈值不适用于 S1，因为 S1 问的是另一个问题。把弱判据的结果套进为强判据写的阈值，就是这份预注册本来要防的那件事。