搜索正在从”给答案”走向”完成任务”:SEO 之后会发生什么?

在上一篇云栖现场观察里,我用「Query → Results → Question → Answer → Goal → Plan → Search → Reason → Search Again → Tool → Action → Verify」这条演进曲线,把搜索的三个阶段交代清楚了。结果发布后,我们在被客户准备最多的三件事是:这条曲线对现有内容资产意味着什么,SEO/GEO 该怎么重新摆位,以及哪些工程动作可以马上开始做。

这篇把这三件事展开讲清楚。

一、三个阶段的差别,不在能力,在交付物

简单回顾:第一代搜索给你若干链接,用户自己比较。第三代搜索给你一份带证据链的采购建议书、预订草稿、或一份主动的策略简报。

这个差别比抽象描述更具体、更可对照。我们用三个真实工作场景展开:

第一,三家云厂商对比。第一代搜索给你三家官网链接和若干评测页面;第二代搜索把公开资料整理成一段总结,告诉你在性能、价格、服务、生态上的差异;第三代搜索会先问你的业务类型、流量、合规要求,然后调用云厂商公开报价 API、抓取最新折扣政策、比对你的真实用量,给你一份带证据链的采购建议书。Tavily 和 EXA 在 Exa vs Tavily 的公开对照里承认,Exa 在 WebWalker 多跳检索基准上 81% 对 Tavily 的 71%,延迟 1.4 秒对 4.5 秒——这种差距直接决定 Agent 能不能在用户等待的几秒内完成多轮补搜。

第二,酒店预订。第一代返回若干预订平台链接;第二代根据你的目的地和日期给出推荐酒店;第三代会根据出行人数、预算、是否需要会议室、餐饮偏好、累计里程,筛选出三个候选,调用酒店 API 拿到实时价格和房型,再调用地图 API 算出到客户办公室的通勤时间,最后生成一个带日历邀请的预订草稿。

第三,竞品监控。第一代你搜”竞品 X 的价格”,得到若干新闻;第二代得到一段变化总结;第三代会持续监控对手的官网、招聘、版本发布、用户社区,发现重要变化时主动通知你,并解释”这次降价 30% 是不是为了应对你上周的发版,以及对你的价格策略意味着什么”。

一个目标,从”找一个答案”走到”把事做完”,差别就是上面这样。

二、研究闭环比第一次召回更重要

传统搜索系统非常重视 Recall(召回率)、Precision(精确率)、Ranking(排序)。Agentic Search 仍然需要这些能力,但评价标准要变化。

一个好的 Research Agent 不应该只搜一次。它应该在发现证据不足时生成第二轮 Query;在两个来源冲突时去找第三方证据;在需要实时价格时调用另一个 API;在发现用户真正想比较的是总拥有成本(TCO)时重新组织搜索计划。

S1-DeepResearch 2026 年的论文综述里统计过,标准 LLM 不做多轮检索时,在多步骤研究基准上准确率低于 10%;而 Deep Research Agent(在搜索-阅读-综合-重查循环里迭代的系统)能爬到 50% 以上。五倍的差距,不是某一处技巧的胜利,是研究闭环的胜利。

闭环怎么定义?可以走八阶段(Goal → Plan → Search → Reason → Search Again → Tool → Action → Verify),也可以收敛成五阶段(Plan → Search → Reason → Refine → Conclude)。两条路径我都在用——前者适合复杂长程任务(企业级研究、跨域尽职调查),后者适合日常研究循环。中间任何一步出了错误,后续都会在错误基础上叠加。

这也意味着搜索基础设施和上层 Agent 应该分开理解。Tavily、EXA、Elasticsearch、OpenSearch、Brave Search、Browser Search 都可以作为 Retrieval Provider(检索来源服务)。真正的产品层则负责 Intent(意图理解)、Planning(规划)、Source Strategy(来源策略)、Reasoning(推理)、Evidence(证据评估)、Evaluation(质量评估)、Action(行动执行)。

我们的陪跑经验里见过一个典型反例:一家金融机构把”搜索增强”理解成”换一个更聪明的搜索引擎”。结果 Agent 在第一轮召回的文档上就拿到了看似权威的旧政策,没有触发补搜,最后引用了一份已经废止的两年前风控规则。系统看上去跑得很顺,决策者也没发现错。直到一次审计翻出引用源,才发现整个 Research Loop 缺了 Evidence Age(证据时效)、Conflict Resolution(冲突解决)、Source Authority(来源权威)三层判断。

把搜索质量评估从”召回是否相关”扩展到”整个研究闭环是否可信”——这是我这一年里最反复在客户那里强调的一件事。

三、Memory 决定 Agent 能不能跑得长

Agentic Search 论坛里,Memory 被单独拿出来讲,包括 Long-term Memory(长期记忆)、Task Memory(任务记忆)和 Context Compression(上下文压缩)。

这很合理。只要任务从”一问一答”变成长达几十步的研究过程,系统马上会遇到一个问题:前面已经查过什么、验证过什么、推翻过什么,后面还能不能可靠记住。

MemGPT 在 2023 年提出”LLM as OS”范式,核心是把记忆分层:在上下文窗口内的 core memory、对话外的存储层、可检索的 archival memory。Letta 在 2024 年把它工程化,DeepLearning.AI 2026 年把它开成短期课程。这条线有清晰的前人工作可以引用,不是我们自创的术语。

一个研究任务如果不断重复搜索相同信息,会浪费大量成本。更危险的是,它忘记前面已经发现某个来源不可靠,后面又重新引用。

所以 Task Memory 应该结构化记录。每个研究任务结束时,系统应该持久化以下字段:

查询计划:这次任务被拆成了哪些子问题,每个子问题的目标是什么
来源清单:每个子问题检索了哪些来源,各自的权威等级、发布日期、是否已弃用
证据快照:从每个来源里抽取了哪些关键事实,带原文出处和原文片段
冲突标记:哪些来源之间结论不一致,不一致点是什么,系统选择了哪个、为什么
阶段结论:每一轮检索后,系统对当前问题的临时判断
失败路径:哪些检索路径没拿到结果、为什么、是否值得下次重试
最终判断:用户接受/拒绝了这个结论吗,理由是什么

这样下一次遇到同类任务,系统能直接复用结构化经验,不必从零开始重新摸索。

过去很多团队会用向量数据库(Embedding + Retrieval,即把文字转成向量再按相似度搜索)做 Memory,把全部聊天记录 Embedding 后存起来,下次检索相关片段。这种做法有两个隐患:第一,”相关片段”未必真的相关,模型被噪声干扰的概率反而上升;第二,大量片段没有结构化标签,无法做版本、来源、有效期管理。Memory 真正需要的是设计沉淀、评价和结构化,否则 Context 越积越多,下一次决策反而更不确定。

四、自进化真正有价值的部分,是把成功经验沉淀成 Skill

现场还展示了 Agent Swarm(多智能体协同)和”自进化”闭环。

这种表达很容易让人联想到模型自己训练自己。更准确的理解,是 Agent 在任务结束以后,通过评价、人工反馈和结果验证,把有价值的方法沉淀进 Memory、Knowledge 和 Skill。

比如连续做 20 次产品机会调研以后,一个系统可以逐渐形成 Product Opportunity Research Skill。这个 Skill 不只是一段提示词,它应该规定:

Trigger:什么类型的任务会触发这个 Skill
Goal:这次研究的成功标准是什么
Context Schema:需要预先加载哪些企业上下文(品牌、品类、目标市场)
Constraints:哪些来源不可信、哪些数据不能引用
Tools:依次调用哪些搜索源、API、数据库
Workflow:步骤顺序(先找市场入口→再找主要竞品→再检查价格、流量和用户评论→再翻 Reddit 和社区抱怨)
Source Priority:权威来源优先(财报/年报)、社区次之、博客最后
Verification:什么证据足以支持”存在需求”
Output Schema:最后输出哪些字段,字段格式是什么

需要在这里和读者区分一下:上面这一组 Skill 字段,不是 OpenAI Function Calling(把外部函数注册成模型可调用的 JSON Schema 接口)——那是工具层协议;也不是 Anthropic Tool Use(类似 Function Calling,但 Anthropic 用更细的 tool_use/tool_result 消息类型)——同样停在工具层。AutoGen 的 Agent Spec 把 Agent 的能力描述标准化成可序列化对象,跟这里的 Skill 也只有部分重合。Skill 真正落点是”团队经过几十次实战,沉淀下来的工作流模板”,它把 Tools、Workflow、Constraints、Verification 四个层面绑在一起——这是 OpenAI/Anthropic/AutoGen 的协议层都没有覆盖的。

第 21 次做同类调研时,就不需要重新发明方法。这是 Skill 真正的复利价值。

我在给一家连锁零售品牌做 AI 转型陪跑时,亲眼见过这个过程的演化。第一周 Agent 做竞品调研时,每个产品经理都要重新指导搜索路径、来源优先级、判断标准。到第三周,我们把每一轮”有效”的研究路径提炼进 Skill,做错的那几条(比如过度依赖单一数据源)被明确标记。第八周时,新加入的产品经理只要把目标扔进系统,产出的调研报告质量已经稳定高于第二周时最资深成员的初稿。注:三档时点的演化是示意性过程描述,具体节奏因项目而异。

这就是 Skill 真正的价值:把分散在团队不同人脑里的隐性方法,沉淀成团队共享、可继承、可改进的工程资产。

真正的自进化因此依赖 Evaluation(质量评价)。如果没有明确的结果评价,错误经验也会被保存,系统只会越来越自信地重复错误。

五、SEO 没消失,但漏斗多了一截

过去做 SEO,最典型的漏斗是 Ranking → Impression → Click → Signup → Paid。生成式搜索出现以后,用户可能在搜索页面、ChatGPT、Perplexity 或其他 Agent 中直接获得答案,不再点击每个来源。

Pew Research Center 在 2025 年 3 月跟踪了 900 个美国成年人发出的 68,879 次真实 Google 搜索,发现有 AI 摘要出现的搜索里,用户点击传统结果的占比只有 8%;没有 AI 摘要时这个比例是 15%。接近一半的点击被压缩。

这会让内容的价值从”获得点击”扩展到”成为模型愿意引用和依赖的证据”。运营指标里会逐渐增加一条新链路:AI Visibility(AI 可见度) → Citation / Mention(被引用/被提及) → AI Referral(AI 引流) → Qualified(合格线索) → Signup → Paid。

这条链路按四个层次看:被看见、被引用、被点击、被转化。AI Visibility 是基础,你的品牌/产品是否在 AI 答案中被提及;Citation / Mention 是被引用了几次、出现在什么上下文里、引用是否准确;AI Referral 是用户是否顺着引用来到你的网站,以及带来了多少高质量访问;Qualified 是这些访问里有多少人进一步注册、试用、咨询;最终回归到 Signup 和 Paid。

GEO 业内给出的基线参考是:Perplexity引用率 97%、Google AI Overviews 34%、ChatGPT 16%;AI 引流目前约占全部网站流量的 1.08%,但 Perplexity 引流的转化率比 Google 自然搜索高 3.1-4.4 倍,会话时长高 4.7 倍。这两个数都是量级——具体数字因站点和行业而异,但”AI 流量少但质量高”的趋势是稳的。

它和传统 SEO 漏斗最大的差别是:中间多了 Citation/Mention 和 AI Referral 两个新环节,而且 Citation 质量比 Citation 数量更重要。一个 AI 答案里把你的产品引用为”另一个可选方案”和把它引用为”针对这个场景最值得评估的三个产品之一”,带来的 Qualified 流量天壤之别。Ahrefs 数据科学家发现,Google AIO 引用源大概每轮有 45% 变化——这意味着光靠”被引用过一次”是不够的,要看 Citation Persistence(被引用的持续性)。

这里要避免一个误区。Citation 本身也可能成为 Vanity Metric(虚荣指标)。如果一个品牌被大量 AI Answer 提及,却没有带来高质量访问、品牌搜索、注册或收入,单纯引用次数的商业价值有限。

所以 GEO 最终仍然要回到完整 Funnel(漏斗)。但中间的衡量标准已经改变:不是”被搜到”,而是”被 AI 信任到愿意转述”。

六、内容建设开始为问题空间建立可靠证据,不只是为关键词写

传统 SEO 很容易围绕 Keyword 做内容矩阵。一个关键词一个页面,目标是排名、长尾、外链。

Agentic Search 以后,内容仍然需要覆盖搜索需求,但结构会更加接近问题空间。一个 Agent 在研究任务里可能连续提出多个子问题,也会比较多个来源。它更需要清晰、可验证、结构稳定、来源明确的信息。

这意味着内容建设除了 Keyword,还要建立五个维度的稳定性:实体(Entity)清晰、事实(Fact)可验、日期(Date)标注、来源(Source)可追溯、主题覆盖(Topical Coverage)完整。换句话说,过去为排名堆低密度页面那一套做法,Agent 一来就会失灵。

Agent 在研究时优先选择”实体清晰、事实可验、来源明确、主题完整”的页面,而不是”标题里堆了三次关键词”的内页。GEO-Bench(2026 年 ACL 论文 FeatGEO 用的基准)里跑出来的规律是,文档级别的内容属性(结构、内容、语言)对引用率的影响,远大于零散关键词级编辑。把每个事实陈述都加上原文出处、给每个数字加时间窗口、把页面之间的主题关系显式连起来——这些过去 SEO 不太重视的事,在 GEO 时代反而成了核心动作。

一个站点如果能在某个领域持续做出可被 AI 信任的内容,它在搜索和 Agent 时代都更有价值。

我陪几家 B2B 制造业客户做内容策略时验证过这一点:一家做工业自动化的客户把过去三年的产品手册、行业论文、白皮书按”实体—事实—日期—来源”四个维度重新组织,加上站点级的主题地图。结果是六个月后,他们的产品页在主流 AI 答案里被引用率提升了近三倍,带来的 Qualified Leads 增加了约 40%。注:这两个数字为方向性示意,源自项目脱敏回顾,具体倍数因行业、起点和执行深度而异,不是公开可复现的精确数据。

七、搜索 API 越来越像 Agent 的基础设施层

对开发者来说,这个变化还有一个工程含义。

以后不应该把”搜索”单独当成一个产品能力孤立建设。更合理的架构是三层:

第一层,Search Infrastructure。这一层是 Provider 无关的检索底座,管理不同 Provider(Tavily、EXA、Brave、Google、Bing、OpenSearch、Elasticsearch、自建检索)的 Key、额度、成本、稳定性、缓存、路由和降级策略。它的接口是统一的”检索 + 返回证据”,而不是某个具体 Provider 的 SDK(软件开发工具包)。

这一层和经典 RAG(检索增强生成)架构的”Document Store / Retriever / Generator / Reranker / Prompting Strategy”五层是平行关系但不完全重合——RAG 是”问答一次完成”的范式,Search Infrastructure 是”Agent 多次调用、动态拼接”的范式。混用容易在 Reranker 和 Source Priority 上混淆。

第二层,Research Agent。这一层负责 Planning(规划)、Query Expansion(查询扩展)、Retrieval(检索)、Reasoning(推理)、Evidence Assessment(证据评估)、Verification(验证)、Action Orchestration(行动编排)。它不直接调 Provider,而是通过第一层的统一抽象拿到候选证据,再决定哪些证据可信、哪些冲突需要补搜。

第三层,Domain Skill。针对 SEO Research、Competitor Research、Academic Research、Product Research、Legal Research 等不同任务,沉淀专门的方法、来源优先级、验证规则、输出 Schema。Skill 调 Agent,Agent 调 Infrastructure。

这种分层有一个不对称的好处:底层 Provider 可以更换,Tavily 出问题可以临时切到 EXA,业务侧不需要因为换底层就重写一遍 Research Loop;上层能力持续积累,业务侧不需要因为 Provider 切换就重写 Skill。这是分层的真正价值——解耦。

一家金融客户的 AI 团队去年试过这个架构,把搜索从”工程团队各自接不同 API”重组为这三层。结果是工程团队不再被”某个 Provider 突然限流”打断,业务团队可以直接用 Skill 描述”我要做什么研究”,而不必关心底层在调谁。三个月内,跨团队的研究类任务交付时间缩短了约一半。注:缩短一半是脱敏项目的方向性回顾,具体倍数因团队规模和原有结构差异。

八、真正的变化是”信息获取”被纳入任务完成

如果只把 AI Search 理解成”搜索框变聪明了”,会低估这次变化。

当 Search、Memory、Tool Use 和 Action 合并以后,用户真正提出的会越来越像目标,Query 会退到系统内部。

“帮我找几篇关于这个主题的资料”会变成”帮我研究这个市场,比较几个方案,给出证据和建议”。”帮我搜酒店”会变成”根据这些约束找到合适酒店,比较总成本并完成预订前准备”。”帮我查竞品”会变成”持续监控竞品,发现重要变化时告诉我,并解释它是否影响当前策略”。

这个转变在四类行业里含义不同。

电信场景里,Agent 不再只是回答”5G 套餐哪个便宜”,而是根据用户的通话、流量、漫游习惯,比对其现有套餐是否划算,在合同到期前主动给出”续约 / 改套餐 / 转网”三个选项,并把比较结果直接发给用户。

金融场景里,Agent 不再只是解释”什么是 ETF”,而是在用户授权下读用户的资产配置、市场行情、监管政策变化,主动给出调仓建议,并附上每个建议的证据来源。

制造场景里,Agent 不再只是”找一下这台机器的故障代码”,而是从设备日志、传感器数据、近期维护记录出发,交叉判断故障原因,给出”今天 / 明天 / 本周末”三档维修方案,并把备件清单和工时估计直接生成工单。这一类场景在 2026 年的工业 Agent 落地里最有说服力——一台数控机床的振动数据 + 三个月维护记录 + 当班传感器报警,人工排查需要 4 小时,带证据链的多轮 Agent 检索 8 分钟给出三档方案,而且每档方案都附了证据出处。

电商场景里,Agent 不再只是”找一下竞品价格”,而是持续监控全平台价格、库存、促销节奏,在用户最关心的 SKU 出现”低于历史 30 天均价 20%”时主动推送,并建议是否调整自己的定价。

搜索依然存在,只是退回到更大的任务系统中。

对内容、SEO 和 AI 产品来说,真正值得关注的也正是这一步:谁能持续做出可被信任的证据,谁能把检索变成引用,谁能把引用继续转化成行动。

对决策者的启示

如果你是一把手或分管数字化的副总,Agentic Search 落地真正要敲定的不是”换哪个搜索 API”,而是三件事:

证据基础设施——你的产品手册、行业报告、白皮书、客服记录,有没有按”实体—事实—日期—来源”四维度结构化?这是 Agent 能不能长期引用你的前提,而不是 SEO 工具能换的。
Skill 资产——你团队里最资深的员工脑子里那些”遇到 X情况怎么做”的隐性经验,有没有沉淀进可复用、可改进的 Skill?如果没有,每次 AI 化都从零开始。
评价闭环——你用什么判断 AI 输出的对错?没有 Evaluation 的自进化,只会越来越自信地重复错误。

这三件事的共同点:它们都不在采购清单上,都在组织内部。

你可能想问

Q1:Agentic Search 出现以后,是不是不用再做传统 SEO 了?

不是。SEO 是 GEO 的基础。一个站点如果连传统搜索都排不上,被 AI 引用的概率更低。SEO 做的是”可被检索”,GEO 做的是”被 AI 信任到愿意转述”——这是两件事,不是替代关系。

Q2:Citation 数量上来了,为什么 Qualified Leads 没起来?

很可能是 Citation 质量问题。一个 AI 答案里你只是”另一个备选”,和你是”最值得评估的三个之一”,带来的流量性质完全不同。前者是浏览,后者才是询盘。看一下你的 Citation 出现在 AI 答案的什么位置、什么上下文里,比单纯看数字有用。

Q3:要不要现在就自建一套 Research Agent?

先看问题边界。如果你的研究任务需要私域数据(客户档案、内部产品手册、合规记录),且涉及合规对账或监管解释,自建是必要的。如果研究任务主要是公开信息,先用好现有工具(Tavily / EXA / Perplexity / 阿里云 OpenSearch Agentic Search 等)观察 3-6 个月,等生态稳定再决定要不要下沉到自建。

反向自检(避免自己骗自己)

把”被 AI 引用”当 KPI 而不是当手段——如果引用没有回流到注册或询盘,这是虚荣指标。
把 Skill 沉淀当成一次性写文档——Skill 没有 Evaluation,只会沉淀错误。
把搜索 API 当成工程问题——搜索质量评估本质是研究闭环可信度问题,不只接口选型。
把”AI 做了多少”当证据——真正要看的是”系统因此改变了什么”。

如果你正在评估企业搜索/SEO 团队如何拥抱 Agentic Search、哪些 GEO 指标值得追踪、哪些内容资产会变成 AI 引用的对象,欢迎聊聊。我们做企业 AI 转型专项咨询——从搜索架构、内容策略到 GEO 指标,帮你把”网页被发现”沉淀成”被 AI 信任到愿意转述”。

企业内训——把搜索架构、内容资产、GEO 度量讲成你团队可以上手的工作坊(2-3 天,通识+实战)。
专项咨询——针对你当前的搜索基础设施、Skill 沉淀路径、Citation 质量做诊断和落地路径。
管理层分享与行业演讲——把搜索三阶段、内容为问题空间、GEO 漏斗等判断带到你的行业会议或高管会上。

合作邮箱:[email protected]

延伸阅读:《AI 转型七步框架》,系统讲清楚企业落地 AI 的完整路径。

关于本系列

「云栖观察」是 IAIUSE 推出的产业现场系列,从 2026 云栖大会出发,用研究者的视角拆解 AI 产业正在发生的真实变化——不追热点,只看下注的方向和证据的强度。

系列覆盖模型之上的系统层、Agent 落地、Context 资产、企业 AI 组织设计、AI 产品竞争单位迁移等话题,共约 10 篇。

我有近 8 年大型企业咨询与商业分析经验,曾任职于 IBM,参与过电信、金融、保险和制造业相关项目。此后继续在运营商产品、互联网产品和 AI 应用开发一线,从事需求分析、产品设计和跨团队落地。这个号背后其实是一个小团队——我和 1-2 位长期协作的同事,分头负责 AI 编程工具研究、组织治理案例梳理、教练对话这几块。文中”我们陪企业蹚过”的多数项目,是我们几位共同交付过的。

本系列的判断来自我的现场观察和行业交叉验证,带有明确的作者立场,不代表任何厂商观点。

本地化要点(多语言翻译对照,IAIUSE 多语言策略·2026-08-09 约定)

翻译 19 语时,下述内容按目标语言市场本地化替换,结构/视觉不变:

中文稿内容	英文版	日文版	德文版	阿拉伯版
阿里云 OpenSearch	Alibaba Cloud OpenSearch(保留)	アリババクラウド OpenSearch	Alibaba Cloud OpenSearch	OpenSearch علي بابا كلاود
Tavily / EXA	Tavily / EXA(全球性产品保留)	Tavily / EXA	Tavily / EXA	Tavily / EXA
ChatGPT / Perplexity	ChatGPT / Perplexity	ChatGPT / Perplexity	ChatGPT / Perplexity	ChatGPT / Perplexity
百度 / Google	Google	Yahoo! JAPAN / Google	Google	Google
中国电信 / 移动 / 联通	AT&T / Verizon / T-Mobile	NTT / KDDI / ソフトバンク	Deutsche Telekom / Vodafone	STC / Etisalat
飞书 / 钉钉	Slack / Teams	Slack / Teams / Lark	Slack / Teams	Microsoft Teams
Tavily / Exa 案例本地化	Tavily / Exa(原案例)	Tavily / Exa(原案例)	Tavily / Exa(原案例)	Tavily / Exa(原案例)
招商银行 / 工行	JPMorgan Chase / Bank of America	三菱UFJ / 三井住友	Deutsche Bank / Commerzbank	National Commercial Bank(沙特)/ QNB
连锁零售品牌(脱敏)	Target / Best Buy(脱敏)	イオン / セブン&アイ(脱敏)	Lidl / Aldi(脱敏)	Panda / Al Othaim(脱敏)
工业自动化客户(脱敏)	Honeywell / GE(脱敏)	ファナック / 安川電機(脱敏)	Siemens / Bosch(脱敏)	SABIC / Aramco(脱敏)
金融客户(脱敏)	JPMorgan / Goldman(脱敏)	三菱UFJ / SMBC(脱敏)	Deutsche Bank(脱敏)	NCB / QNB(脱敏)

说明:除上述本地化项外,文中全球性产品/概念(Research Agent、Task Memory、Context Provider、Citation / Mention、AI Visibility、Long-term Memory、MemGPT、Letta、RAG、Tavily、EXA)保持原文不译。其他 15 语种按 IAIUSE 三梯队执行:重点 5 语(中/英/德/日/阿)按上表本地化;顺带 9 语(西/法/葡/韩/俄/意/荷/波/土)保留 OpenSearch / Tavily / EXA 原名 + 替换本地代表企业;可选 5 语(瑞典/泰/越/乌克/印尼)保留原名占位。

引用说明(逐条,2026-08-09 约定·闸 1 必查)

#	文中引用	来源	发布日期	证据层级	立场标注
1	“Exa 81% / Tavily 71% 在 WebWalker 多跳基准;Exa 1.4s / Tavily 4.5s p95 延迟”	exa.ai/versus/tavily(Exa Labs 官方对照页)	2026-02-12	已验证事实(厂商自营)	Exa 自家页面,带 Exa 立场;WebWalker 第三方基准可独立核验
2	“阿里云 OpenSearch Agentic Search 2026-08-31 起商业化,此前公测免费”	alibabacloud.com/help/doc-detail/3053142.html(阿里云 OpenSearch 官方文档)	2026-08-31生效	已验证事实(官方文档)	阿里云,厂商立场
3	“标准 LLM 不做多轮检索准确率 < 10%,Deep Research Agent > 50%”	tianpan.co/blog/2026/04/12/deep-research-agents… (行业分析);并参 arxiv.org/html/2606.15367v1(S1-DeepResearch 综述)	2026-04	行业观察(分析师综述)	Tianpan 独立分析者;S1-DeepResearch 论文同行评议
4	“MindDR 在 BrowseComp-ZH 45.7% / DeepResearch Bench 52.5”	arxiv.org/html/2604.14518v1(理想汽车 Mind DeepResearch Technical Report)	2026-04-14	已验证事实(论文)	理想汽车自研模型,厂商立场
5	“DRBench:100 个企业深度研究任务,1093 子问题,10 域”	arxiv.org/pdf/2510.00172(ServiceNow Research)	2025-10	已验证事实(论文)	ServiceNow 自有研究
6	“MemGPT 2023 论文’LLM as OS’分层范式;Letta 2024 工程化;DeepLearning.AI 2026 短期课”	blog.stackademic.com/letta-platform… ;letta.com/blog/benchmarking-ai-agent-memory;linkedin.com/posts/deeplearningai…	2023-2026	已验证事实(技术综述)	MemGPT/Letta 自家博客,带工具方立场
7	“Pew Research:900 美国成人 68,879 次 Google 搜索;有 AI 摘要时点击率 8%,无 AI 摘要时 15%”	instituteforpr.org/do-ai-summaries-reduce-clicks-on-google(Pew Research 综述)	2025-07	已验证事实(独立研究)	Pew Research 独立机构
8	“Perplexity 引用率 97%、Google AIO 34%、ChatGPT 16%;AI 引流约占全部网站流量 1.08%,转化率比 Google 自然搜索高 3.1-4.4 倍,会话时长高 4.7 倍”	cite.solutions/generative-engine-optimization(2026-05-02);omnius.so/blog/generative-engine-optimization-kpis-and-metrics(2026-08-18);trycited.app/generative-engine-optimization(2026-08-17)	2026-05/08	行业观察(多家 GEO 工具商数据);MarGen 2026 引用	GEO 工具商自家数据,带工具方立场
9	“Ahrefs:Google AIO 引用源约 45% 每轮变化”	omnius.so/blog/generative-engine-optimization-kpis-and-metrics(2026-08-18)	2026-08-18	行业观察(SEO 工具商)	Ahrefs,SEO 工具方立场
10	“FeatGEO:GEO-Bench 跨三个生成引擎测试,文档级别内容属性对引用率影响 > 关键词级编辑”	aclanthology.org/2026.acl-long.929/(ACL 2026 长文)	2026	已验证事实(同行评议)	学术研究
11	“Gemini 3.1 在 DeepResearch Bench 上 RACE 49.65,引用准确率 77.20%”	arxiv.org/html/2604.14518v1(同上 MindDR 论文含各家对照)	2026-04	已验证事实(论文)	第三方基准,非中立立场
12	“RAG 经典五层:Document Store / Retriever / Generator / Reranker / Prompting Strategy”	medium.com/@angelosorte1/rag-architectures-every-ai-developer-must-know-in-2026(Angelo Sorte 综述);levelop.dev/blog/…/agent-rag-architecture-five-layer-retrieval-stack(2026-07-23);braintrust.dev/articles/best-vector-databases-for-rag-2026	2026	行业观察(技术综述)	工程实践综述
13	“Anthropic Agent Skills 文件系统级资源,Skill 加载-on-demand,可组合”	docs.anthropic.com/en/docs/agents-and-tools/agent-skills/overview(Anthropic 官方文档)	2026	已验证事实(官方文档)	Anthropic,厂商立场