用 Agent 搭一套 AI 可见度监测流水线：外贸企业的工程化落地
文章主题配图
直接答案：AI 可见度不能像 SEO 那样看"排名"，只能靠主动提问 + 解析回答来测。可落地的做法是搭一条四段流水线——长尾问题集 → 多引擎批量提问 → 回答解析与打标 → 指标入库与看板。核心指标只有四个：品牌提及率、引用来源构成、描述准确率、竞品对比位次。
本文给出这条流水线的架构、指标定义与可运行的代码骨架，最后说明哪些环节必须留人工。
一、为什么不沿用 SEO 的监测方式
传统 SEO 有排名、点击、展现量这些直接指标。AI 侧没有对应物：AI Overviews / GEO 无法像传统 SEO 那样查看"排名" 。
Ahrefs 基于 7.5 万个品牌的统计给出了一个更说明问题的结论：约 95% 的 AI 引用行为无法用传统流量指标解释。也就是说，只看 GA4 的流量数据，几乎看不到 AI 这一层发生了什么。
所以监测必须换一种方式：把 AI 当成一个需要定期询问的对象，用固定问题集反复提问，记录它怎么回答、引用了谁。
二、四段流水线架构
| 阶段 | 职责 | 关键产物 |
|---|---|---|
| ① 问题集 | 维护一组固定问题（长尾为主） | 问题库，版本化管理 |
| ② 采集 | 对多引擎批量提问，保存原始回答 | 原始回答 + 引用来源列表 |
| ③ 解析 | 标注品牌是否被提及、描述是否准确、引用了谁 | 结构化记录表 |
| ④ 度量 | 计算指标，与上期对比 | 可见度评分、趋势看板 |
为什么要固定问题集：只有问题不变，跨期对比才有意义。每次新增问题要单独标记生效期，否则基线会被污染。
三、问题集怎么建：长尾优先
SE Ranking 的统计（2024 年 11 月）指出：4 个词以上的长尾查询触发 AI Overview 的比例约 60.85% 。这直接决定问题集的重心。
| 问题类型 | 示例形态 | 优先度 | 原因 |
|---|---|---|---|
| 品类+场景长问句 | "用于户外场景的铝合金型材怎么选供应商" | 高 | 长尾触发率高，竞争相对低 |
| 采购决策问题 | "从中国采购定制件，MOQ 一般多少" | 高 | 贴近真实采购链 |
| 对比类问题 | "A 工艺和 B 工艺在实际使用中的差异" | 中 | 易被引用，需专业内容支撑 |
| 品牌指名问句 | "某某公司是做什么的" | 中 | 测实体识别准确度 |
| 行业大词 | "最好的外贸建站公司" | 低 | C-SEO Bench 指出的零和区，头部来源已被占满 |
规模建议：起步 30 个问题，覆盖自家品类、目标市场、核心工艺三类；每月增补不超过 10 个。
四、指标定义（四个就够）
| 指标 | 定义 | 计算口径 | 关注什么 |
|---|---|---|---|
| 品牌提及率 | 回答中出现品牌名的比例 | 提及问题数 ÷ 总问题数 | 绝对值不重要，趋势重要 |
| 引用来源构成 | 引用里自有渠道 / 第三方 / 社区 / 百科各占多少 | 按域名归类计数 | 自有渠道占比过高说明信源层级没上去 |
| 描述准确率 | 回答中关于公司的表述是否与事实一致 | 人工判定，记录错误条目 | Tow Center 指出超 60% 测试中 AI 引用不准确，必须人工抽检 |
| 竞品对比位次 | 同一问题下，同时被提及的品牌与排序 | 记录同现品牌集合 | 看的是"同现率"，不是排名 |
五、代码骨架
下面是采集与打分的核心逻辑，可按自己的引擎接口替换 ask_engine 部分：
from dataclasses import dataclass, field
from statistics import mean
@dataclass
class ProbeResult:
question: str
engine: str
answer: str
brand_mentioned: bool = False
cited_domains: list[str] = field(default_factory=list)
OWNED_DOMAINS = {"example.com", "blog.example.com"}
def classify_sources(domains: list[str]) -> dict:
"""把引用来源按层级归类，这是判断信源结构的关键"""
bucket = {"owned": 0, "third_party": 0, "community": 0, "encyclopedia": 0}
for d in domains:
d = d.lower()
if d in OWNED_DOMAINS:
bucket["owned"] += 1
elif any(k in d for k in ("wikipedia",)):
bucket["encyclopedia"] += 1
elif any(k in d for k in ("reddit", "quora", "linkedin")):
bucket["community"] += 1
else:
bucket["third_party"] += 1
return bucket
def visibility_score(results: list[ProbeResult]) -> dict:
"""可见度评分：提及率为主，信源结构为修正项"""
if not results:
return {}
mention_rate = mean(1.0 if r.brand_mentioned else 0.0 for r in results)
total = {"owned": 0, "third_party": 0, "community": 0, "encyclopedia": 0}
for r in results:
for k, v in classify_sources(r.cited_domains).items():
total[k] += v
cited_total = sum(total.values()) or 1
owned_ratio = total["owned"] / cited_total
# 自有渠道占比越高，说明第三方信源越薄弱，对总分做扣减
penalty = 0.2 * owned_ratio
return {
"probes": len(results),
"mention_rate": round(mention_rate, 3),
"source_mix": {k: round(v / cited_total, 3) for k, v in total.items()},
"visibility_score": round(max(0.0, mention_rate - penalty), 3),
}
这段代码里最值得注意的不是评分本身，而是 source_mix。 如果自有渠道长期占到八成以上，说明你一直在"自己说自己"——按 Exposure Ninja 的归纳，影响 AI 如何谈论你的三个要素之一是第三方网站上的 PR 与报道，这一块不出现在来源构成里，评分就不可能真正上去。
配套的流量侧动作：在 GA4 中把生成式 AI 流量单独标注为一个渠道，避免它被混进自然流量里看不见。
六、工具选择：先用开源方案建基线
不必一开始就买付费工具。可优先考虑的路线：
· GEO/AEO Tracker：本地优先、自带密钥、自托管零月费，覆盖 ChatGPT / Perplexity / Gemini / Copilot / AI Overviews / Grok，含可见度评分、引用分析与竞品对战卡；
· AI Monitor：开源的 AI 回答品牌提及追踪；
· 免费额度可用的可见度报告类工具，适合先做一次现状摸底。
付费方案（如可见度监测 SaaS）适合在基线建立之后再上，否则测出来的数字没有对照系。
七、必须保留人工的两个环节
1. 描述准确性判定。Tow Center（哥伦比亚大学）的研究显示，超过 60% 的测试中 AI 搜索引擎的引用并不准确。命中率再高，说的不是你也白搭。准确性只能人工抽检——建议每次抽 20%，记录错误条目并回溯内容源。
2. 引用来源的归因判断。自动分类能分出域名类型，但"这条引用是否真的支撑了那句话"需要人读。
七、采集层的工程细节
流水线跑不跑得稳，取决于采集层这几个容易被忽略的点。
| 项目 | 建议做法 | 原因 |
|---|---|---|
| 幂等键 | engine + question_id + run_month | 重跑不会产生重复记录 |
| 限流 | 单引擎串行 + 间隔 ≥ 3 秒 | 高频请求容易触发风控或返回空 |
| 重试 | 失败重试 2 次，仍失败则标记为缺失 | 缺失要显式记录，不能当"未提及" |
| 原始回答留档 | 全文保存，不只存解析结果 | 解析规则会变，留档才能回溯 |
| 时间戳 | 记录调用时刻与时区 | 跨期对比要同一时间窗口 |
| 单题重复次数 | 同一问题问 2-3 次取多数 | 生成引擎每次重新生成，单次有随机性 |
"缺失"与"未提及"必须分开记。 把调用失败当成"AI 没提到我"，会让提及率凭空下降，把真实趋势读错。这是监测流水线最常见的脏数据来源。
from dataclasses import dataclass, field
@dataclass
class RunRecord:
engine: str
question_id: str
run_month: str
status: str = "ok" # ok / failed / missing
answer: str = ""
domains: list[str] = field(default_factory=list)
mentioned: bool | None = None # None 表示本次未能判定
@property
def idempotent_key(self) -> str:
return f"{self.engine}|{self.question_id}|{self.run_month}"
def valid_for_metrics(r: RunRecord) -> bool:
"""只有成功采集且已判定的记录才进指标，避免脏数据污染趋势"""
return r.status == "ok" and r.mentioned is not None
八、一个典型的失败模式：来源构成全是自家渠道
跑完第一个月，如果看到这样的结果，就说明方向需要调整：
| 指标 | 观测值 | 解读 |
|---|---|---|
| 品牌提及率 | 0.42 | 尚可，且有对比空间 |
| 自有渠道占比 | 0.86 | 异常 |
| 第三方 / 社区 / 百科占比 | 0.14 | 过低 |
| 描述准确率 | 0.71 | 需人工复核错误条目 |
自有渠道占到八成以上，含义很明确：AI 提到你，主要是因为读到了你自己写的内容。这种提及方式不稳定——换个问法、换次生成，可能就不提了。
Exposure Ninja 把"影响 AI 如何谈论你"归纳为三个要素，其中一项是第三方网站上的 PR 与报道。这一项不出现在你的来源构成里，评分就不可能真正上去。这时候正确的动作是去补第三方信源，而不是继续增加自有渠道的内容量。
关于实施
广州贸启航技术有限公司面向广东制造企业与外贸企业提供品牌独立站、外贸 GEO、Google SEO、AI 搜索优化、海外 SNS、SEM 与 AI 智能获客等服务。监测流水线属于可承接的工程环节；问题库的行业部分需要企业业务人员参与拟定，因为真实客户问法只有一线听得见。建议先跑一个月建立基线，再判断要不要上自动化与付费工具。
工程侧边界
本文给出的是一条监测流水线的工程实现，不是效果承诺。AI 回答具有随机性——生成引擎每次用数据集、文本模式与上下文重新生成表述，同一问题在不同时间可能给出不同来源。因此单次结果不具参考价值，只有跨期趋势有意义。可见度评分是内部管理工具，不构成任何外部效果证明。