Agentic GEO 的技术底座：一次 AI 可见度检测背后的九步管线

很多客户看完检测报告会问同一个问题：这份报告里的数据，是怎么来的？

这个问题值得认真回答。市面上不少"AI 优化"服务的交付物是一份 PPT 几个分数，分数怎么算的说不清，数据能不能复现更没人管。睿贤把检测系统当成一个工程系统来做，这篇文章把我们认为最核心的一段——检测跑完之后的九步报告管线——完整拆给你看。看懂这段，你就知道一份"可复核"的 AI 可见度报告，和一份"看起来有数据"的报告，差在哪里。

---

一、先说清楚：什么算"贵的数据"

一次多平台检测，成本最重的部分是平台实测：把题目逐条投给豆包、DeepSeek、文心、千问、元宝、智谱，收集每一条真实回答。这一步消耗真实 API 调用与时间，几十分钟跑下来，得到的是当场生成、无法重放的原始数据。

工程上有句老话：贵的东西先落盘，便宜的东西后计算。原始数据是贵的——丢了就得重花钱重跑；而归类、分析、渲染这些计算是便宜的——任何时候都能从原始数据重新算出来。

所以我们管线的第 1 步不是"开始分析"，而是 raw 即时落盘：实测一回收，原始回答立刻写成 *_round1_raw.json 持久化。后面八步里的任何一步崩了，都不需要重测，从 raw 重算即可。

这个设计来自真实教训：早期版本"最后一步才落库"，中途进程重启，几十分钟的实测全部白跑。报错可以重试，数据丢失不能重来——这是整条管线的设计起点。

二、九步管线全景

全平台任务回收后，服务器静默 90 秒（给二轮任务留启动窗口），然后自动执行九步：

三个阶段各有各的失败模式，我们逐段说。

阶段一（①–③）：数据保真

最容易出事的是第 2.5 步信源归类——AI 回答里提到的站点五花八门，要归进 A1–F4 三十二个子类。我们的做法是三段漏斗：初筛先分大方向，半精筛收窄，精筛定子类，每批 40 个域名、批超时 180 秒、失败重试 2 次。小批次的理由很朴素：响应快、失败半径小，一批出错不用整批重来。

阶段二（④–⑥）：维度拆分

报告不是一张分数表。第 4–6 步把数据按平台拆开、按维度（认知层 / 场景覆盖 / 对比决策 / 品牌认知等九维）拆开，最后一步做缺口诊断——哪一维、哪一档最弱，直接写进报告。客户拿到报告能回答"我下一步该补什么"，而不是"我考了 68 分"。

阶段三（⑦–⑨）：交付同构

第 9 步组载荷落库，和客户手动发布走的是同一套数据结构。这条约束很重要：自动管线和手动通道如果两套实现，迟早口径分叉，报告对不上。我们把它写成了代码约束——调度器直接复用同一套装配逻辑，从根上杜绝两条链路各说各话。

三、为什么要当"工具"而不是"定时任务"

检测任务不是站点自己在跑。站点通过 MCP 协议对外暴露 27 个工具，把"联网检索建企业档案、出题、逐平台喂题"交给智能体侧执行；站点自己只管调度、存储、报告。

这样分工的好处：模型侧能力（检索质量、出题策略）可以独立升级，不用动站点。坏处是多了一条链路要保证一致——所以"同一实现"是写进约束的：服务器自治调度直接复用 MCP 的启动逻辑，两条链路一个口径。

四、这套管线测不出什么

诚实边界必须写：

1. 检测是测量，不是投放。 检测告诉你 AI 现在怎么评价你、引用了谁，不承诺"测完排名提升多少"。
2. 单轮数字天然有波动。 AI 回答是当次现场生成的，单轮的绝对分数意义有限，价值在同口径下的横向对比与纵向趋势。
3. 算不出的就明说。 比如"推荐率"需要逐题人工看答案语义，系统给不了精确值时，报告里会直说，不拿估算冒充实测。

---

一句话收束：2026 年评价一家 GEO 服务商，别先看案例有多漂亮，先问它的数据管线——原始数据落不落盘、口径拆不拆、失败可不可重跑。这三个问题，睿贤 Agentic GEO 都能带你看代码级答案。