Add case study: vetted 20 VPS providers with parallel subagents (EN + ZH + OG + banner)

src/content/posts/zh/how-i-vetted-20-vps-providers-with-parallel-subagents.md

@@ -0,0 +1,135 @@
+---
+title: "如何用并行子代理在三小时内核查 20 家 VPS 服务商"
+description: "一个关于编排并行 AI 子代理对 20 家主机服务商做尽职调查的案例研究——WHOIS、AUP 和口碑核查——把数小时的研究任务压缩成一份结构化、可追溯的供应商评分卡。"
+pubDate: 2026-09-09
+category: case-studies
+tags: [ai-orchestration, subagents, due-diligence, hosting, devops]
+ogImage: /og/how-i-vetted-20-vps-providers-with-parallel-subagents.png
+banner: /banners/how-i-vetted-20-vps-providers-with-parallel-subagents.png
+---
+
+## 为什么这很重要
+
+选主机服务商，本质是用一张信用卡和一次 DNS 变更来下注。选错了，「保证在线率」
+会变成凌晨两点的封停邮件，「注重隐私」会变成一条你从没读过的日志留存条款。
+
+问题不是信息不够，而是信息散落在每家服务商的十几个页面里（WHOIS 记录、可接受使用
+政策、隐私政策、价格页、第三方评测站），手工核查又慢又枯燥又容易出错。一家服务商
+就是五个标签页，二十家就是一百个标签页和一下午搭进去的时间。
+
+这个故事讲的是我怎么把那一整个下午压到大约三小时——不是靠更快地干活，而是靠编排
+一支 AI 子代理小队并行跑完枯燥的部分，再用同一张清单给所有结果打分。
+
+## 问题：我不能靠信仰去核实的那些声明
+
+我要为一个有硬性要求的项目筛选服务商：具体的司法辖区、付款方式、流量条款。这些
+没有一样是首页上诚实地写出来的。它们诚实地写在那些无聊的文档里——WHOIS 记录显示
+域名才四个月、AUP 静悄悄地禁掉你正想跑的服务、隐私政策承认自己保留日志。
+
+难就难在，核实一家服务商意味着读五份互相矛盾的文档。营销说「自 2012 年起」，
+WHOIS 说「今年四月才注册」。特性页说「允许所有流量」，AUP 说「禁止 Tor 中继」。
+一家服务商就是一次事实核查，二十家就是一个研究项目。
+
+## 第一次尝试：一个 agent，一个大循环
+
+我最先想到的当然是显而易见的那个——单个助手从头到尾挨个处理这份名单，逐家抓取
+文档、记笔记、往下走。
+
+它能跑。但它对这份工作的形状来说是错的工具。这活儿**天然可并行**：7 号服务商的
+WHOIS 查询和 3 号服务商的隐私政策毫无关系。串行跑意味着总耗时是每次抓取之和，而且
+——更重要的是——上下文窗口会被我已经翻过去的那几家的半成品笔记塞满。到第八九家
+的时候，早期的发现就被后面的挤掉了。
+
+教训是：一个对独立条目做扁平循环的任务，不是推理问题，而是扇出（fan-out）问题。
+一个长长的上下文是装它的错误容器。
+
+## 修复：用并行子代理扇出，然后统一打分
+
+真正奏效的结构是三层：
+
+**1. 一张不在乎指向谁的清单。** 在派发任何东西之前，我先写下对每家服务商而言
+「已核实」具体意味着什么：
+
+- 域名注册日期 对比 那个「since」声明
+- 可接受使用政策（AUP），搜我关心的具体服务
+- 隐私政策，读留存条款
+- 第三方口碑（Trustpilot 看趋势，不看均值；社区提及）
+- 流量条款（「防计量」还是一个计量上限）
+
+这张清单就是契约。每个子代理都拿到同一份，外加一份要套用的服务商名单。
+
+**2. 并行子代理，每个负责一批服务商。** 我把名单拆成几簇，每簇交给一个子代理。
+每个子代理在隔离环境里工作，有自己的上下文、自己的一套抓取，最后为每家服务商
+返回一份结构化的事实清单——不是一段话，而是能直接丢进评分卡的字段。
+
+关键是子代理彼此不知道对方。这正是要点：1 号服务商的任何内容都不必和 14 号服务商
+共享上下文空间，各自返回自洽的结果。
+
+**3. 一次打分，由我来做，不派发。** 子代理产出发现，判断由我来下。一旦你让子代理
+既*收集*事实又*排序*服务商，你就丢了审计链——只会得到一个没有背后证据支撑的结论。
+把打分集中在自己手里，意味着我随时能说出*为什么*某个东西排到某个位置，并指出是哪条
+WHOIS 记录或哪行 AUP 驱动的。
+
+这和我做任何代码审查或重构时用的是一个模式：并行化机械的收集，集中化决策。
+
+### 编排实际长什么样
+
+大致上，每一批：
+
+```text
+子代理 → 「这是清单，这是你那 5 家服务商」
+       → 逐家：抓 WHOIS、AUP、隐私政策、价格、评测
+       → 返回 { 域名年龄, AUP红旗[], 留存条款, 口碑, 流量 }
+我     → 合并进一张评分卡，套用清单，排序，写结论
+```
+
+三个子代理并行跑。整轮——二十家服务商、每家五份文档、大约一百次抓取——在手工
+仔细做两三家服务商的时间里就完成了。
+
+## 核查到底抓到了什么
+
+评分卡暴露了首页永远不会告诉你的真问题：
+
+- **一家声称「自 2012 年起值得信赖」的服务商，域名比这晚得多。** WHOIS 显示域名是
+  同一年的某个月才注册的——一个「从业多年」的四位数声明，配一个才几个月的域名。
+  这要么是换了马甲的壳，要么就是撒谎，无论哪种，它页面上所有其他声明在我眼里都要
+  降级。
+
+- **两家的 AUP 禁掉了我正想跑的那个服务。** 一家在禁止活动条款里列了「TOR 节点」和
+  「匿名化服务」；另一家禁了「反向代理」和「隧道」。两家的特性页却还宣传着相反的话。
+  在 AUP 上花十分钟 `Ctrl-F` 就排除了它们——但前提是*我知道该去查 AUP*，而不是
+  特性页。
+
+- **一家原本看着很便宜的服务商，读了流量条款后不是了。** 一个带 1 TB 计量上限的
+  计划上写「无限」，只是营销。对于既要接收又要转发的节点，真实成本翻倍——「便宜」
+  的那个选项并不便宜。
+
+它们所有的共同点是：致命信息从来都没藏起来。它是*公开*的，躺在服务商法律上有义务
+发布的文档里。这个技能不是秘密渠道，而是知道该读哪份文档，并拿它去对照营销话术。
+
+## 我会怎么做不一样
+
+子代理的交接能用，但太粗糙。下次我会提前给每个子代理*精确的返回字段*——一份严格的
+输出 schema——而不是一段我事后还得重新解析的散文。结构化输出意味着最后一个子代理
+返回时评分卡就已经建好了，不用再读一遍。
+
+我也会更早钉死「这个声明能否独立验证？」这个测试。大多数红旗并不是服务商公然撒谎，
+而是一条我无法对照任何公开记录去核实的声明。把「无法验证」本身当成一种信号，名单
+很快就能缩下来。
+
+## 结果
+
+大约 20 家服务商、大约 100 次文档抓取，三个子代理并行，耗时相当于手工仔细做两家
+服务商。最终评分卡里的每一项排名都能追溯到一条具体的公开记录——一个 WHOIS 日期、
+一行 AUP 条款、一条留存条款——而不是一种感觉。
+
+---
+
+## 想为你的企业做这件事吗？
+
+无论是 VPS、API 网关还是薪酬服务商，选供应商都是同一种问题：在签约*之前*，把你真正
+依赖的那些声明对照无法被营销篡改的公开记录核实一遍。如果你手里有一份候选供应商或
+工具的短名单，想在投入之前拿到一份结构化、有证据支撑的评估——我可以跑这轮尽职调查，
+然后交给你一张评分卡，而不是一个猜测。
+
+[WhatsApp 联系我](https://wa.me/60127972969) 或 [发邮件](mailto:[email protected]?subject=Vendor%20due-diligence%20evaluation) 到 hoelee.com——我帮企业选对基础设施，并搭建配套的自动化。