1. 从排名探测说起SGE 时代的关键词布局到底变了什么做 SEO 的人这两年应该都有一个共同的体感传统那套查排名、盯位置、堆外链的打法在生成式搜索面前越来越不灵了。以前你打开一个排名查询工具输入关键词看到的是十条蓝色链接谁在第一页谁就有流量。现在你打开 AI 搜索得到的是一段整合过的回答里面可能引用三五个来源也可能一个都不引用直接给你一段综合结论。这就带来一个很现实的问题我的内容到底有没有被 AI 搜索看见被看见之后又是以什么形式呈现的这就是生成式引擎评测标注 SGE 排名探测 Agent要解决的核心痛点。SGE 是 Search Generative Experience 的缩写指的是搜索引擎把生成式能力嵌入到搜索结果页之后形成的新形态。它和传统搜索最大的区别在于结果不再是链接列表而是生成式回答 引用来源 追问入口的组合。你原来盯的第 3 位第 7 位这种位置概念在生成式结果里被彻底打散了——你的内容可能出现在回答的引用角标里可能出现在相关追问里也可能压根没出现但你的品牌词却被 AI 在回答里提到了。所以这篇内容我想聊的不是怎么做一个排名查询脚本这么简单而是如何用 Agent 的思路把 SGE 排名探测、评测标注、关键词布局这三件事串成一条完整的链路。适合谁看三类人一是做 SEO/SEM 想转型到 AI 搜索优化的从业者二是想用 Agent 做自动化数据采集和评测的开发者三是做内容运营、想知道自己的内容在生成式搜索里表现如何的团队。哪怕你之前没写过 Agent只要跟着思路走也能搭出一套能跑的东西。我先把结论摆前面SGE 排名探测的本质不是查位置而是查存在感。存在感分三层——被引用、被提及、被推荐。这三层的探测方式、标注方式、优化方式完全不同后面会一层层拆开讲。2. 拆解 SGE 排名探测的三层存在感模型2.1 被引用角标背后的来源竞争被引用是最直观的一层。你在 AI 搜索里看到回答末尾或者句子旁边有个小角标点开是一串来源链接这就是被引用。对做内容的人来说这是最硬的指标因为它意味着 AI 在生成回答时把你的页面当成了事实依据。但这里有个很多人忽略的细节被引用不等于被优先展示。AI 搜索的引用来源通常有多个展示顺序、展示数量都不固定。我实测下来同一个查询在不同时间、不同账号、不同设备上引用来源的排序会有波动。所以你不能只看我有没有被引用还要看我在引用列表里排第几引用我的那句话是不是核心结论。这就引出了探测 Agent 的第一个设计要点采集时不能只抓是否引用要抓引用位置 引用上下文 引用数量。具体来说每次探测要记录本次回答一共引用了几个来源、我的域名排在第几位、引用我的那句话原文是什么、这句话在回答里的位置开头/中间/结尾。这四个字段组合起来才能刻画被引用的真实质量。2.2 被提及没有角标也算赢第二层是被提及。有时候 AI 的回答里直接写了你的品牌名或者产品名但没有给角标链接。这种情况在品牌词查询、对比类查询里特别常见。比如你问XX 和 YY 哪个好AI 可能在回答里说XX 在某某方面表现不错但没附链接。很多做 SEO 的人会忽略这一层觉得没链接等于没流量。但从 AI 搜索的演进趋势看被提及本身就是一种品牌曝光而且会反过来影响用户的下一次搜索行为。用户看到 AI 提到你的品牌很可能接着去搜你的品牌词这部分流量是间接的但真实存在。探测 Agent 在这一层的任务是做实体识别和品牌词匹配。你需要维护一个品牌词/产品词/别名的词典然后在 AI 回答的全文里做匹配。注意要处理同义词和变体比如某某云和某某云计算要能识别成同一个实体。2.3 被推荐追问入口里的机会第三层最隐蔽也最有价值——被推荐。AI 搜索回答完之后通常会给出几个相关追问或者继续了解的入口。如果你的内容能出现在这些追问的触发结果里相当于拿到了一个二次曝光的机会。这一层的探测难度最高因为追问入口是动态生成的而且不同平台的表现形式差异很大。我的做法是把追问入口当成独立的查询来探测。也就是说Agent 不仅要探测主查询还要把主查询触发的追问入口抓下来逐个再探测一遍看哪些追问的结果里出现了我的内容。把这三层放在一起就形成了一个完整的探测矩阵存在感层级探测目标关键字段优化难度被引用角标来源引用位置、上下文、数量高被提及品牌曝光实体匹配、提及次数中被推荐追问入口追问词、触发结果高这个矩阵是后面所有 Agent 设计和评测标注的基础。你先把这三层想清楚再动手写代码方向就不会偏。3. 评测标注 Agent 的架构选型为什么我最终选了轻编排 重采集3.1 编排框架的取舍LangChain、Dify、CrewAI 到底怎么选一说到 Agent很多人第一反应是上框架。LangChain、Dify、CrewAI 这几个我都实际用过说说我的真实感受。LangChain 生态最全但抽象层太多一个简单的采集任务要套好几层 Chain调试起来很痛苦。Dify 适合做可视化编排拖拖拽拽就能搭流程但它的强项是对话型应用做这种批量探测、结构化标注的任务反而有点别扭。CrewAI 的多 Agent 协作思路很清晰适合一个 Agent 负责采集、一个负责标注、一个负责汇总这种分工但它的学习曲线对新手不算友好。我最后的选择是不用重型框架用轻量编排 自己写采集逻辑。原因很简单——SGE 排名探测这个任务核心难点在采集的稳定性和标注的准确性不在Agent 之间的复杂协作。你用一个主控脚本 几个职责单一的函数模块反而比套框架更可控。具体结构是这样主控层负责调度读关键词列表循环触发探测写结果到存储。采集层负责发请求、拿回答、解析引用和提及。标注层负责给采集结果打标签被引用/被提及/被推荐。存储层结构化落库方便后续做趋势分析。这个结构听起来朴素但实测下来最稳。框架能帮你省的那点代码量远不如你自己掌控每个环节带来的调试效率。3.2 采集层的关键请求节流与结果解析采集层最容易踩的坑是请求太猛被封。我的经验是单账号探测频率控制在每分钟 3 到 5 次关键词之间加随机延迟 2 到 5 秒。别小看这个延迟它能显著降低被识别为异常流量的概率。结果解析是另一个难点。AI 搜索的返回结构不像传统 SERP 那么规整引用来源可能藏在 HTML 的特定 class 里也可能通过接口返回 JSON。我的做法是优先走接口接口拿不到再解析页面。接口返回的数据结构更稳定字段更全解析成本低得多。解析的时候要特别注意引用来源的去重和归一化。同一个域名可能出现多次要合并带 www 和不带 www 的要归一化短链接要还原成真实域名。这些细节不做后面的统计全是错的。3.3 标注层规则引擎比大模型更靠谱很多人一上来就想用大模型做标注觉得AI 判断更智能。我的实测结论是在 SGE 排名探测这个场景里规则引擎的准确率和稳定性都优于大模型标注。为什么因为标注任务本身是高度结构化的——判断我的域名有没有出现在引用列表里品牌词有没有出现在回答文本里这是确定性的字符串匹配问题用规则几行代码就搞定又快又准。大模型反而会引入不确定性同样的输入两次可能给出不同结果这对做趋势分析是灾难。大模型真正有用的地方是**判断引用我的那句话是不是核心结论**这种语义层面的任务。所以我的方案是结构化标注用规则语义质量评估用大模型两者分工明确。4. 关键词布局从词表到意图簇的思维转换4.1 传统关键词研究的局限传统关键词研究核心是找词、看量、排优先级。工具给你一堆词每个词带搜索量、竞争度你按优先级排一排然后围绕高价值词做内容。这套逻辑在传统搜索里没问题因为用户搜什么词你就优化什么词一一对应。但在 AI 搜索里这个对应关系被打破了。用户可能用一句很长的自然语言提问AI 把它拆解成多个意图然后综合多个来源生成回答。你优化了关键词 A但用户的实际提问可能触发了 A、B、C 三个意图你的内容只覆盖了 A那在生成式回答里就可能只被引用一小部分甚至不被引用。所以关键词布局的思维必须从词升级到意图簇。4.2 意图簇的构建方法意图簇是什么简单说就是把用户可能问的、语义相关的一组问题归到一起形成一个主题覆盖单元。比如AI 搜索优化这个主题下面可能包含什么是 AI 搜索优化、AI 搜索和传统 SEO 的区别、怎么检测内容有没有被 AI 引用、AI 搜索优化的工具有哪些……这些问题的答案应该由一组内容来共同覆盖而不是靠单篇文章硬扛。构建意图簇的具体步骤种子词扩展从核心词出发用工具扩展出相关词、长尾词、问句词。语义聚类把扩展出来的词按语义相似度聚类同一簇的词意图相近。意图标注给每个簇标注意图类型信息型/导航型/交易型/对比型。覆盖度评估检查你现有内容对每个簇的覆盖情况找出缺口。这个流程听起来像传统关键词研究但关键区别在最后一步——你要评估的不是这个词有没有排名而是这个意图簇有没有被你的内容完整覆盖。AI 搜索更看重内容的完整性和权威性一个意图簇被一组互相引用的内容完整覆盖比单篇高排名文章更容易被 AI 引用。4.3 全域布局让内容形成引用网络全域关键词布局这个词听起来玄乎其实核心就一句话让你的内容在不同平台、不同形式、不同深度上形成互相支撑的网络增加被 AI 引用的概率。具体怎么做我的经验是三个多多平台同一主题的内容在官网、行业社区、问答平台、视频平台都布局一份形式不同但核心观点一致。AI 搜索在生成回答时会综合多个来源你的内容出现次数越多被引用的概率越高。多形式长文、短文、问答、图表、视频覆盖不同用户的消费习惯也覆盖 AI 抓取的不同内容类型。多深度既有入门科普也有深度技术拆解覆盖意图簇里的不同层次需求。这里有个反直觉的点不要怕内容重复。在传统 SEO 里同质内容会互相竞争、分散权重。但在 AI 搜索里多个来源表达一致观点反而会强化 AI 对这个观点的确信度提高引用概率。当然这不是让你复制粘贴而是同一核心观点用不同角度、不同案例去表达。5. 把探测和布局串起来一个可复现的实操流程5.1 环境准备与依赖清单先说环境。我用的是 Python 3.10核心依赖不多pip install requests beautifulsoup4 pandas openpyxlrequests发 HTTP 请求。beautifulsoup4解析页面接口拿不到时的兜底。pandas数据处理和结果汇总。openpyxl导出 Excel 报告。如果你要做定时任务再加一个schedule或者直接用系统的 cron。别一上来就上重型调度框架这个任务的调度需求很简单。5.2 探测脚本的核心逻辑探测脚本的主流程分四步读关键词、发请求、解析结果、写存储。我把它拆成几个函数方便单独调试。import time import random import requests from bs4 import BeautifulSoup def fetch_answer(query, session): 发送查询返回原始响应 # 这里替换成你实际使用的搜索接口 # 注意请求头要带真实的 UA降低被识别概率 headers { User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) ..., Accept-Language: zh-CN,zh;q0.9, } resp session.get(SEARCH_ENDPOINT, params{q: query}, headersheaders, timeout15) resp.raise_for_status() return resp def parse_citations(raw_html): 解析引用来源返回归一化后的域名列表 soup BeautifulSoup(raw_html, html.parser) citations [] # 引用来源通常在特定容器里class 名需要按实际页面调整 for node in soup.select(.citation-source): link node.get(href, ) domain normalize_domain(link) if domain: citations.append(domain) return citations def normalize_domain(url): 域名归一化去协议、去 www、去路径 if not url: return domain url.split(//)[-1].split(/)[0] domain domain.replace(www., ) return domain.lower()这段代码的关键在normalize_domain。别小看这几行它决定了你后面统计的准确性。我见过太多人因为没做归一化把同一个域名的不同形式当成不同来源统计结果全乱。5.3 标注与落库采集完之后标注和落库是连在一起的。我的做法是每探测一个关键词就生成一条结构化记录def annotate(query, citations, answer_text, brand_terms): 给单次探测结果打标签 record { query: query, timestamp: int(time.time()), citation_count: len(citations), my_domain_rank: -1, # -1 表示未被引用 mentioned: False, mention_count: 0, } # 判断被引用及位置 for idx, domain in enumerate(citations): if domain MY_DOMAIN: record[my_domain_rank] idx 1 break # 判断被提及 for term in brand_terms: count answer_text.count(term) if count 0: record[mentioned] True record[mention_count] count return record落库我推荐先用 CSV 或 SQLite别一上来就上 MySQL。这个阶段数据量不大SQLite 足够而且迁移方便。等数据量上来了再考虑换数据库。5.4 从数据到决策怎么读探测报告数据采集完关键是会读。我一般看四个指标引用率被引用的探测次数 / 总探测次数。这个指标反映整体存在感。平均引用位次被引用时的平均排名。位次越靠前越好。提及率被提及的探测次数 / 总探测次数。反映品牌曝光。意图簇覆盖度每个意图簇里有多少查询触发了我的内容。这四个指标组合起来就能定位问题。比如引用率低但提及率高说明你的品牌有认知度但内容权威性不够AI 不愿意引用引用率高但位次靠后说明内容质量够但竞争力还差一口气。6. 踩过的坑那些文档里不会写的经验6.1 探测频率与结果稳定性的矛盾这是我最开始踩的坑。为了快速拿到数据我把探测频率调得很高结果发现同一个查询连续探测几次结果波动很大。一开始以为是 AI 搜索本身不稳定后来才想明白高频探测可能触发了平台的限流或降级策略返回的是简化版结果。解决办法就是前面说的节流。把频率降下来加随机延迟结果稳定性明显提升。我的经验值是同一查询两次探测间隔至少 30 分钟不同查询之间间隔 2 到 5 秒。这样拿到的数据才可信。6.2 引用来源的幽灵链接有段时间我发现探测报告里经常出现一些莫名其妙的域名点进去是 404 或者完全无关的内容。后来排查发现是解析逻辑把页面里的广告位、推荐位链接也当成引用来源了。这个坑的教训是解析引用来源时一定要限定在回答主体区域内不要把整个页面的链接都抓进来。具体怎么限定要看实际页面的 DOM 结构通常回答主体有独立的容器引用来源在容器内部。多花点时间研究页面结构比事后清洗数据划算得多。6.3 品牌词匹配的误伤做被提及标注时我用品牌词做全文匹配结果发现误伤率很高。比如品牌词是云图但回答里出现云图是在说别的东西不是指我的品牌。解决办法是加限定条件匹配品牌词时检查前后文有没有行业相关词或者用更精确的实体名比如带后缀的完整品牌名。如果误伤还是严重就引入大模型做二次判断但只对疑似提及的样本做不要全量跑成本太高。6.4 意图簇划分过粗或过细意图簇划分是个技术活。划得太粗一个簇里塞了几十个意图覆盖度评估没意义划得太细每个簇就一两个词又失去了簇的意义。我的经验是一个意图簇包含 5 到 15 个查询词比较合适。划分完之后人工抽查几个簇看看里面的词是不是真的意图相近。如果发现某个簇里混进了不相关的词就拆开。这个步骤别偷懒意图簇的质量直接决定后面布局策略的有效性。7. 让 Agent 跑得更久稳定性与扩展性的一些想法7.1 异常处理与断点续跑批量探测最怕跑到一半挂了前面的数据白采。所以断点续跑是必须的。我的做法是每探测完一个关键词就立即落库同时记录一个已完成关键词的集合。脚本重启时先读这个集合跳过已完成的词。异常处理也要做细。网络超时、解析失败、返回结构异常这些都要捕获记录到错误日志而不是让整个脚本崩掉。我的原则是单个关键词探测失败不影响整体流程失败的关键词记录下来最后统一重试。7.2 多账号与结果对比如果你要做更严谨的探测可以考虑用多个账号分别探测对比结果差异。同一查询在不同账号下的结果如果差异很大说明这个查询的结果本身不稳定做趋势分析时要谨慎对待。但多账号也带来管理复杂度。我的建议是初期先用单账号跑通流程等流程稳定了再考虑多账号。别一上来就搞复杂容易把自己绕进去。7.3 从探测到优化的闭环探测本身不是目的优化才是。我一般会建立一个简单的闭环探测发现某个意图簇覆盖度低。分析这个簇里哪些查询没触发我的内容。针对这些查询补充或优化内容。过一段时间再探测看覆盖度有没有提升。这个闭环跑起来你的 AI 搜索优化就从凭感觉变成了看数据。我实测下来坚持跑两三个月重点意图簇的引用率能有明显提升。7.4 关于 Agent 安全的一点提醒最后提一句 Agent 安全。做自动化探测一定要遵守目标平台的使用条款控制请求频率不要做任何可能被视为攻击的行为。采集的数据只用于自己的分析不要二次分发。这些不是技术问题是基本的职业操守也是让这套东西能长期跑下去的前提。整套流程跑下来我的体会是SGE 排名探测这件事技术难度不高难的是想清楚探测什么和怎么读数据。工具和代码都是次要的真正拉开差距的是你对生成式搜索的理解深度以及把探测结果转化为内容策略的能力。先把三层存在感模型吃透再动手搭 Agent方向对了剩下的就是迭代。