先说结论

2026 年 9 月 24 日上午，云栖大会国博一期三楼大宴会厅 A 座无虚席——首位讲者邢少敏开场就说"人气超预期"。这场名为「AI 搜索智能体：从检索到推理」的论坛，议题密度远超一场产品发布会：它实际上在回答一个问题——当搜索的调用方从人变成 Agent，搜索产品和搜索引擎要被重写成什么样子。台上七位讲者的答案可以压缩成三句话：上层产品从问答工具升级为能规划、执行、记忆和自进化的 Search Agent；底层引擎从"返回给人看的链接列表"重构为"喂给机器消费的上下文基础设施"；而这两次升级的共同约束，一边是亿级租户、千亿向量下的成本，一边是 Agent 上下文窗口里越来越贵的每一个 token。阿里云 AI 搜索产品负责人汤祯捷给出的判断最为直接：企业级可交付 Agent 的分水岭不来自模型，而来自 Agent 基础设施的完备性。如果你在做企业应用、数据基础设施或内容分发，这场论坛讨论的正是未来两三年你的检索账单和产品形态。

一、范式换轨：从"我知道了"到"我的任务完成了"

邢少敏把 AI 搜索切成三个阶段：2022 年以前是信息查询，输入关键词、返回结果、人来判断；2023 到 2024 年是生成式搜索，系统理解问题、综合信源、生成答案；2025 到 2026 年进入第三阶段——用户表达的是一个目标而不是一组关键词，系统拆解任务、选择工具、访问知识、执行操作，最后给出可交付、可验证的结果。他给这个变化下了一个漂亮的注脚：搜索的终点从"我知道了"变成了"我的任务完成了"。

这个判断有市场数据托底。邢少敏引用 Google 在 2026 年 I/O 大会披露的数字：AI Overviews 月活已超过 25 亿，AI Mode 上线一年月活超过 10 亿（作为参照，公开报道显示 AI Overviews 在 2025 年中约为 20 亿月活，方向一致）。商业价值方面，他援引一家第三方机构对真实客户七个月的跟踪，称 AI 搜索的转化率最高可达传统搜索的 9 倍，综合不同口径大致是 4 到 6 倍。这些数字属于"讲者引用"，但行业共识正在形成：AI 搜索不再是尝鲜功能，而是一种新的交互基础设施——用户给出目标，系统完成任务，企业因此必须把高质量、可验证、可调用的知识喂给 Agent。

落到产品形态，阿里云 Agentic Search 的核心是一个 Agent Loop：装载上下文、推理、规划、决策、执行，反馈持续调优闭环，任务在沙箱中安全隔离执行。支撑长任务的记忆模块用两个公开基准自证：LoCoMo 综合得分 96.69（覆盖单跳、多跳、开放域和时序信息），LongMemEval 总体准确率 81.37%，同时 Token 消耗节省 68.18%。邢少敏特别强调，目标不是让记忆记得越多越好，而是准确地选择、更新和遗忘，在效果、成本和上下文长度之间取平衡——LongMemEval 里环境陷阱识别仍是短板。这套自进化体系把记忆（个性化）、技能（经验复用）、知识库（知识沉淀）连成统一经验流，整个过程可观测、可评估、可回滚。厂商自报的榜单成绩姑且听之，但"记忆要会遗忘"这个设计取向值得记住。

一个具体的落地样本是 ES Agent：底层采集日志、指标和事件，中间由 Agentic Search 提供知识、记忆和技能，对外形成自然语言交互层。用户不用记命令、不用在多个控制台间切换，直接问"为什么延迟比较高"，系统汇总集群状态生成结构化报告，诊断异常节点、给出原因和建议动作——重点是每个判断都有证据。按路线图，未来几个月 ES Agent 会覆盖购买、实例管理、索引配置、性能调优、数据洞察的全生命周期。换句话说，搜索产品正在吃掉控制台：管理一个复杂系统的方式，从"学界面"变成"直接说"。

二、引擎为 Agent 重写：租户、缓存与磁盘上的千亿向量

范式变了，引擎为什么必须重写？阿里云高级技术专家杨孔仕把传统部署的困境归纳为五类约束：低频数据占着磁盘和内存，沉睡租户消耗资源，海量小租户累积出海量分片和管理开销；查询一旦触达其他租户的数据，无效读取随总量增长，带来延时升高、召回下降；存算绑定让扩容和恢复都要搬数据，写入和查询混部争抢 CPU 与 I/O。而 Agent 应用的画像恰好踩满这五个坑：一个上亿用户的 App，每个用户一个租户，就是亿级租户；代码仓库向量持续增长、需要实时更新检索；线上目标用户的需求是千万级到亿级租户、千亿级向量、P95 小于 100 毫秒、召回大于 95%——传统 ES 部署做不到，检索耗时会到秒级以上。

ES Agent 引擎版的解法是把"数据长期保存"和"只为活跃付费"这对矛盾拆开：OSS 作为唯一持久化层存放索引段文件、预写式日志和元数据；写入层和查询层是两个独立的计算层，各自扩缩容，节点增减不搬数据；查询从 OSS 按需读取，本地内存和 SSD 只做两级缓存，缓存按租户的实际访问分配。关键抽象是 Slice——一个 slice 对应一个租户的检索空间，同一租户数据连续存放，查询、缓存、预热都只针对这份数据；slice collection 把海量 slice 组成逻辑集合，业务只用一个集合名，后端物理索引和分片自动扩展。杨孔仕的总结句值得原样引用：一个知识库的查询，不应该因为其他租户变多就承载更多无关的读取和计算——查询的范围应由租户自身的数据决定。

向量索引本身也按这个思路重做。引擎采用 Elastic 开源的 BBQ（Better Binary Quantization）磁盘原生向量索引：分层 k-means 聚类加量化压缩，不需要像 HNSW 那样重建图，构建速度提升约十倍；查询三步走——按质心选簇缩小范围、用量化向量快速打分、取一批原始向量精排，簇内数据按 posting list 连续存放，天然适合磁盘和对象存储的顺序 I/O。多租户场景下还有个隐蔽的坑：如果先做全局聚类再按租户过滤，大量候选集会因为是其他租户的数据而被丢弃，计算量上涨、召回下降。解法是把租户边界直接带进向量索引（Slice-BBQ），配跳表直达本租户数据区间。成本收益据讲者给出：整体成本降低 70%，存储为原来的 20%、内存 25%、CPU 50%；参考负载下热查 P99 60 毫秒、召回 95%，而自建 ES 参考值约为 2 秒和 70%；冷查含 OSS 读取约 600 毫秒，可预热。无状态设计带来十秒级故障恢复，branch slice 能秒级创建共享初始数据、增量单独保存的分支——这正是 AI Coding 场景派生新工作区需要的原语。

这套引擎已经过最严苛的客户检验。阿里巴巴 Qoder 技术专家夏晓文给出的生产数字是全 forum 信息密度最高的一段：Qoder 前身是通义灵码，做代码检索时上下文分散在代码符号、提交记录、Wiki 各处，需要引擎聚合、提炼、裁剪、重排。他们的成本目标是单库每月一元以下；选型时评估过 ES 开源版和 Milvus，发现数据越多性能越差、成本指数级上升，最终落在 Agent 引擎版上。当前线上状态：写入侧三十多台 ECS、查询侧数十台 ECS，已存超过千亿向量，查询支撑 1000 QPS、Agent 并发二十多，写入峰值约 1GB/s。对比被替换的同类方案，检索 P50 低约三倍、写入带宽提升约五倍、总成本降到原先的 15%（邢少敏口径是原方案的七分之一，两者对照基线不同，但方向一致）。检索链路上他们做了多路召回（向量、关键词、符号、commit 历史、企业知识库）、图索引扩图补全关系、重排融合；有趣的一个细节是，原来用小模型做 query 拆分，大模型效果好之后这个环节直接被砍掉了。

论坛最后一场演讲补上了另一条技术路线。阿里云 Milvus 产品负责人刘红涛把向量检索需求分成"轻量"（知识库、智能问答、客服、Agent 记忆：要更快更便宜）和"大"（智驾、具身智能、大模型训练找数据集：GB 到 PB 级，存储成本撑不住）两类，介绍了经过两年沉淀推出的企业级自研引擎（转写为"EGO"，名称待官方确认）：分层存储索引把存储量级扩大十倍以上、召回 98%、响应秒级；磁盘索引优化把 QPS 提升 20 倍以上、索引构建从 20 小时缩到 6 小时；标准基准上 QPS 达 12.7 万、召回 99%（厂商自报）。B 站给 UP 主提供的创作素材平台从自建 Milvus 迁移到云上后，检索时延从 251 毫秒降到 24 毫秒。针对 PB 到 EB 级场景，Milvus 与阿里云数据湖 DLF 打通，支持 Paimon、Iceberg、Lance 三种湖格式，与 Ray/Spark 等计算引擎组成离线处理加在线检索的组合方案。另外两个面向 Agent 时代的能力是全托管知识库和兼容 Mem0 的记忆服务 AMS——盒马的 Data Agent 已经在用。

把这三段拼起来，一条清晰的行业链条浮现：Agent 应用爆发（变化）→ 亿级租户与千亿向量把预留资源式的传统部署逼入死角（原因）→ 云厂商凭存算分离、按用量付费的形态拿走市场，自建方案失去经济性（得失）→ 二阶影响是搜索基础设施整体转向 serverless 化与免运维，Elastic 的朱杰在圆桌上把这称为明年必然爆发的形态，因为 Agent 生命周期长短不一、随时创建一百个子 agent、用完就删，任何预留式资源规划都跟不上（二阶影响）→ 观察指标是单租户月成本、热查 P99 与召回率的组合，以及各厂商 serverless 查询集群的上线节奏（Qoder 的单库一元、Milvus 的闲时缩容到零都是信号）→ 对读者的启发：如果你的检索选型还在按峰值预留集群，这笔账值得重新算一遍。

三、per-token 信息密度：把互联网压缩成 Agent 的口粮

如果说阿里云讲的是私域与引擎，Exa AI Lab 亚洲负责人 Shef Wang 讲的是公域与经济学。他的出发点很朴素：模型权重就这么大，互联网是它的上百万倍且持续更新，而训练有截止日期，所以 Agent 必须持续检索——互联网就是 Agent 的 system of record。但这座图书馆是几十年前给人建的：人的搜索是线性过程，去 Google 输入 query，拿回十条链接（其中三条是广告），一条条点开浏览，搜索厂商在中间设卡收费，这就是 Google 每年几千亿利润的来源。Agent 完全不同：URL 对它没有意义，它只需要某些页面中与问题相关的段落进入上下文窗口做 grounding；它也不线性，可以同时发出几十上百个搜索请求、拿回几百上千个页面。

由此引出全场最有冲击力的两个判断。第一，据 Exa 自己的 tracking，Agent 的搜索请求量"截至今日已经超过全人类的搜索请求量"——人类搜索请求早已平台期，而 Agent 搜索在 ChatGPT 上线后以每年几十倍到上百倍的速度增长。这是单一公司的口径，无法独立核实，但它与 Exa 的客户规模互为印证：累计服务超过 5000 家企业客户、40 万开发者，Cursor、Lovable、Replit 这些 coding agent 背后用的都是 Exa，OpenRouter 上六百多种模型接入 web 搜索时接的也是它。第二，Shef 给出一个粗估：搜索的开销大约是所有 LLM 开销的 5% 到 10%，过去两三年非常线性；若 LLM 按当前速度增长，五六年后 AI 搜索上产生的成本可能超过目前谷歌的广告收入。这个推论同样属于"嘉宾估计"，但它点出了利益结构的关键错位：模型厂没有任何激励帮你省 token，因为你多烧它多挣钱；而搜索基础设施厂商的激励相反——这正是第三方搜索在 Agent 时代的机会窗口。

Exa 的技术答案浓缩成一个概念：per-token 信息密度。Shef 举的例子很具体：让 Agent 调研云栖大会的会址，理想情况下搜索引擎应该只回二十个 token——“杭州国展中心一期、二期”，结束。但现实是把这个问题丢给 Claude，它要吃掉两万 token：点开无数页面、把内容整个贴进上下文再清洗，本质上是拿 LLM 的智能当拐杖，去弥补传统搜索引擎该做而没做的事。Exa 的改进分三步：建一个高密度索引，从几万亿网页里只收录很小一部分，第一步就完成高压缩；retrieval 阶段在相关性之外满足新鲜度、去重、多样性等并行要求（AI scientist 搜论文时，传统引擎前十结果常是同一篇文章在 arXiv、Nature、PubMed 的不同拷贝，这种要避免）；第三步是 payload 提取——用自训模型从网页里提取与 query 相关的原文段落，而不是用模型总结（总结慢、贵、且不是原文）。效果据称是：在 SimpleQA 基准上，前 500 个 highlight 的检索效果相当于提取整页前 8000 个字符，token 压缩比超过十倍；近期升级为把所有结果网页拼成一张大文档整体提取后，检索质量提高的同时 token 消耗再降三分之一到一半。

还有一个 anticipatory 的产品能力：因为 Exa 自建索引、持续追踪互联网变化，它把"时间旅行"开放给了开发者——不仅搜索互联网此刻的状态，也能搜索彼时彼刻的状态。对冲基金和模型厂商用它构建训练预测能力时过去截止点的数据集，在 RL 中避免答案泄露，回测数据更干净。场景的涌现完全超出规划：有 dating 应用在匹配时对约会对象做 KYC 背景核查，有录音笔客户对会议内容做 fact check——Shef 的原话是"这些场景都不是我们规划的，都是莫名其妙就出现的"。顺带一提，阿里云的 AI 原生搜索产品 CleverSee 其海外信源部分已接入 Exa，服务手机智能助手、智能座舱、企业员工助手等场景——公域搜索的新范式正在通过云厂商进入国内生态。

这条链的逻辑是：长程 Agent 任务把 context window 变成稀缺资源（变化）→ 全量网页塞进上下文既慢又贵（原因）→ 模型厂缺乏省 token 的激励，第三方搜索与"搜索子代理"模式获益，烧 token 的应用方止损（得失）→ 二阶影响是信息密度成为检索服务的计价与竞争维度，搜索从独立动作变成无处不在的嵌入式能力（二阶影响）→ 观察指标是每任务 token 消耗、embedding 检索延迟——识季的倪弋森在圆桌上明确说，现在 embedding 检索要几百毫秒，如果能压到关键词检索的几十毫秒量级、先摸到 100 毫秒，应用场景会更多（指标）→ 启发：评估检索服务时，别只看召回率榜单，先算 per-token 的信息密度账。

四、企业的真实痛点：口径、长尾与"不是以量取胜"

圆桌环节把视角从基础设施拉回业务，六位嘉宾覆盖了 coding agent、硅谷搜索原厂、消费电子出海、跨境时尚电商和搜索引擎原厂，恰好构成一条供需链。

需求侧最生动的两个痛点都关于"知识的私有性"。倍思科技 AI 与大数据总监邓银河描述了洞察报告的日常：多个岗位用同一份数据，但加工口径不同，最后对报告时在扯皮"你的数据结果为什么跟我的不一样"；而通用 agent 平台生成的洞察"一定是不懂你这个公司业务的"——所以必须通过知识、记忆和商业文档把企业知识注入进去。他们的做法是以终为始：报告要被信任、被用于决策，倒推从海量评论、会话、社媒数据经打标和情感分析，进入知识引擎精准召回，再按洞察结构出报告。识季（SENSER）的倪弋森则给出跨境电商的长尾困境：约 80% 的商品官网描述、标题、商详信息不全，只能从图片里挖掘维度。他们与 OpenSearch 团队、千问 Embedding 团队合作，把沉淀十年的时尚奢品专家知识做成提示词标签，训练专属多模态 Embedding 模型。结果：主搜支持自然语言直接语义检索商品（用户说"想看印象画派的展、要一件类似风格的上衣"，传统搜索只会匹配关键词吐出一幅画或印花衣服，语义搜索直接给出匹配风格的服装），长尾词场景点击率提升 20%，原本检索不到的商品曝光量翻了两倍多；图搜场景从小模型约 35% 的准确率提升到 90% 以上——而且"越复杂的场景搜得越准"；商品运营圈选从每天七八小时降到节省约 70% 的时间。

供给侧的两位讲者贡献了最多的反常识。朱杰（Elastic 首席解决方案架构师）回顾了技术钟摆：GPT 出现后大家一度以为"万物皆向量"，项目落地后关键词搜索、grep 又全被找回来了——有些 Code Agent 直接用 grep，有些用向量加 grep 混合，客服这类语义场景混合检索最佳，多模态必须向量，没有谁替代谁，跟 Agent 形态和业务紧密相关。他还观察到搜索引擎为 Agent 做的三个适应性变化：搜索量暴涨（一个 agent 随时创建一堆子 agent、同时发起一百个搜索）要求硬件利用最大化；Agent 临时生成的数据无法预知，引擎必须自动完成配置和调优；搜索语言与接口要面向 Agent 适配（ESQL、MCP、CLI 都是为此准备）。夏晓文则从 coding agent 演进印证了同一点：早期单轮模式追求"一次给 AI 最全面的信息"，靠工程主导的 query 改写加融合；Agentic 时代把向量、关键词、commit、wiki 检索封装成独立工具，让 AI 作为调用主体经 ReAct 机制自主决策多轮调用——精确度和准确率有质的飞跃。Shef 补充了海外镜像：从 Cursor 开始，大家把搜索 spin 成一个 sub agent，检索请求由子 agent 消化整页信息，只给主线返回一个高密度答案，避免第一步就把长程任务的上下文堵死。

安全维度也被抬到了新高度。Shef 提到 Exa 给政府、银行等大机构客户提供 ZDR（零数据留存）策略，他的判断是：当搜索变成基础能力，安全要求就从应用层降到了基础设施层。这个表述有点反直觉，实际含义是——基础设施层必须内建安全能力，而不能指望上层应用各自补齐。

圆桌收尾的避坑建议几乎是给所有企业的实操清单，值得整段保留：夏晓文说小批量文本检索尽量别上复杂的 RAG，关键词检索效果也很好；邓银河说做 Agent 不是以量取胜，别一开始铺很大的面，从业务价值和商业成功为导向的聚焦目标切入；倪弋森说不要为了做 Agent 而做 Agent，守住自己领域的核心竞争力（他们做的是时尚理解），找准一个确定性场景，用类 Agent 的形式拆解它、上线拿结果、形成正循环；朱杰的建议最"元"——选型时别直接信联网搜到的 benchmark 答案，固定测试逻辑的标准榜单很难覆盖真实场景，让 AI 生成一份贴合你自己业务数据的 benchmark 去实测，这才是最贴近实际的。

五、把论坛翻译成你的观察清单

汤祯捷的演讲提供了整套体系里最好用的两个框架。其一是企业级上下文的定义：上下文是任务所需的"最小充分信息"，由四类构成——目标与任务内容、记忆（跨任务的经验偏好与历史决策）、知识（多模态、可验证事实、可追溯信源）、技能（含自进化 skill）。他直言百万级 token 的大窗口也撑不起企业长周期复杂流程，而把四类信息直接扔进一个向量库让大模型召回，是当前企业落地最常见的错误：模型很难判断哪些信息优先级更高、哪些是当前输入、哪些过期该过滤、哪些需要权限校验。正确的做法是分类治理、按任务按需编排，配合压缩、动态窗口和层级摘要保住事实保真。配套的四层检索编排是：记忆层、摘要检索增强层、Agentic Wiki 图谱层、ES/OpenSearch 全文向量多模态层——只做一层，就很难同时保证权限、时效和优先级。其二是场景适配三问：是否跨多数据源、有无明确的验证与完成条件、是否需要留下证据与执行计划。三个都答"是"，才是 Agent Search 的菜。落地上他给了企业路径：从可验证的复杂任务开始，先打通数据权限与知识评测，再扩大任务边界——让 Agent 从"能回答"走到"能交付"。

于是第三条链条也完整了：企业把 Agent 用在长链路真实任务上（变化）→ 任务一次跑完的概率极低，需要 human loop 与可校正的 agent loop，状态、记忆、知识、trace 都要有地方安放（原因）→ 把私域知识与记忆做厚的企业获得可交付能力，只想"搜索框加个大模型"的方案出局（得失）→ 二阶影响是组织形态变化——邓银河所说企业走向 AI native 组织、Agent 像虚拟同事一样强依赖企业知识上下文与岗位记忆，倍思还在押注跨设备的用户记忆让 AI 硬件"懂你"而不是"AI 玩具"（二阶影响）→ 观察指标：任务可验证比例、trace 覆盖率、单位任务的 token 成本，以及 Agent 记忆基准（LoCoMo、LongMemEval）榜单的走向（指标）→ 启发：先治理知识，再上 Agent；基础设施的完备性比模型选型更早成为瓶颈。

论坛闭幕词把主题收拢为"AI 搜索从检索走向推理、从工具走向基础设施"。散场后再看，这场论坛真正记录的是一个交接时刻：搜索的调用者、计价单位（从点击到 token）、交付物（从链接到任务结果）在同一时间换了轨。明年的悬念也埋在了台上——如果 Shef 的判断成立，“AI 搜索"这个词本身将在一年内失去修饰意义，因为所有搜索都会是 AI 搜索；而企业侧的分水岭，正如汤祯捷所说，不在于你用多强的模型，而在于你的知识、记忆与检索基础设施，是否已经为 Agent 准备好了。