导读 随着 Agentic AI 进入企业应用，企业搜索正在从“信息入口”升级为智能应用的上下文基础设施。过去，搜索更多是在帮助人找到信息；现在，搜索还要服务 Agent，让系统能够在企业数据中持续取证、判断和执行。
这意味着，搜索系统不能只返回文档、记录或片段，而要把分散在多数据源中的信息组织成可被用户和 Agent 使用的上下文。它既要理解问题和约束，也要处理数据源、工具、权限、证据链、运行状态和结果校验。
火山引擎云搜索 ContextSearch（上下文搜索）正是面向这一变化推出的企业级搜索增强能力。它不是简单把大模型接到搜索框后面，而是在火山引擎云搜索已有关键词检索、向量检索、混合检索、多模态解析和云搜索 OpenSearch 能力之上，进一步构建面向 Agentic Search 的企业搜索执行系统，让企业搜索从返回结果升级为提供可执行、可验证、可持续进化的上下文。
主要内容包括以下几个部分：
- 复杂企业搜索，已经不是搜文档
2. ContextSearch 建立在火山引擎云搜索的搜索地基之上
3. ContextSearch 的 Agentic Search 是什么
4. 运行时系统让 Agentic Search 稳定可用
- Trace 进入云搜索 OpenSearch，形成可进化闭环
分享嘉宾｜王正 字节跳动云搜索资深研发工程师
内容校对｜韩珊珊
出品社区｜DataFun
01
复杂企业搜索，已经不是搜文档
先看一个典型问题：
帮我看一下某区域销售负责的、金额超过一定阈值的商机，最近两周跟进得怎么样，有没有风险？
这个问题看起来像一次搜索，实际已经不是普通的文档检索。系统至少要跨过四道门槛。
第一，要理解约束。这里包含区域、负责人、金额门槛、时间窗口和风险判断，并不是几个关键词简单匹配。
第二，要跨源取证。商机主体可能在业务系统里，跟进记录可能在协作文档、会议纪要、附件、聊天记录或其他企业数据源里。
第三，要围绕同一个问题组织证据。用户要的不是一串命中文档，而是这些证据共同说明了什么。
第四，要交付可用判断。最终答案需要说明当前进展、风险点、依据来源，以及哪些地方仍然不确定。
图 1：复杂企业搜索已经不是“搜文档”，而是在多源信息中形成可交付判断
这类问题说明，企业搜索正在从静态检索走向运行时执行。过去搜索系统主要回答“在哪里”；现在它还要回答“下一步查什么、用什么工具查、以谁的权限查、证据够不够、失败后怎么恢复”。
02
ContextSearch 建立在火山引擎云搜索的搜索地基之上
要把复杂搜索做成 Agentic Search，前提不是抛弃传统搜索能力，而是必须站在足够强的搜索底座上。ContextSearch 不是从零开始长出来的，它建立在火山引擎云搜索长期沉淀的检索、理解和结果组织能力之上。
从能力层次看，底层是关键词检索、向量检索、混合检索和索引引擎；中间是查询改写、实体识别、OCR、附件解析、多模态理解等内容理解能力；上层是 RAG 总结、结构化输出和面向问题的答案组织能力。
其中，RaBitQ + DiskANN 是火山引擎云搜索面向大规模语义检索场景的重要技术积累。当向量规模持续上升，系统会同时面对内存、成本、延迟和召回效果的挑战。DiskANN 面向低内存、高性能的 ANN 检索，RaBitQ 通过量化压缩进一步优化向量存储和召回效率，让亿级向量等企业级 AI 搜索场景能够在性能、成本和效果之间取得更好的平衡。
图 2：ContextSearch 建立在火山引擎云搜索的检索、理解和结果组织能力之上
在一组典型测试场景中，RaBitQ + DiskANN 展现出明显收益：向量检索 P99 延迟从 25.2ms 降至 7ms，QPS 从 1375 提升至 7565，Recall 从 0.9358 提升至 0.9422，单 QPS 成本下降 83.5%。这组数据说明，底层检索能力的优化不只是更快，而是在延迟、吞吐、召回和成本之间同时取得收益。
| 指标 | 优化前 | 优化后 | 效果 |
|---|---|---|---|
| P99 延迟 | 25.2ms | 7ms | 降低约 72% |
| QPS | 1375 | 7565 | 提升约 5.5 倍 |
| Recall | 0.9358 | 0.9422 | 召回略有提升 |
| 单 QPS 成本 | - | - | 下降 83.5% |
所以，ContextSearch 的价值不是替代搜索，而是在强搜索底座之上，把企业数据组织成更适合 Agent 使用的上下文。
03
ContextSearch 的 Agentic Search 是什么
ContextSearch 不是通用聊天 Agent，也不是把多个检索接口简单包成工具。它更准确的定位，是位于调用方和企业数据源之间的企业搜索执行层。
上游调用方可以是用户，也可以是上层 Agent；下游是企业里的多类数据源，包括知识库、协作文档、业务系统、云搜索 OpenSearch 索引等。ContextSearch 位于中间，负责把一个复杂问题变成一次可执行、可恢复、可验证的搜索过程。
图 3：ContextSearch 位于调用方和企业数据源之间，把一次搜索变成可执行的 Agentic Search 过程
这个边界很重要。普通 Agent 关注能不能调用工具，而企业搜索 Agent 更关心四件事：
第一，去哪里查。系统要知道本次问题涉及哪些 datasource。
第二，怎么查。不同 connector 下会有不同 tool，工具不是泛泛存在，而是围绕数据源能力被定义。
第三，用谁的身份查。ContextSearch 通过 OAuth 获取用户授权后的临时 token，以用户身份访问源系统；凭证由平台托管，可存储在 Secret Store 或 KMS 中。
第四，在什么边界里查。真正的数据鉴权仍由源系统完成，ContextSearch 不重新发明一套权限体系，而是把用户身份、scope、源系统权限和可访问索引范围一起装配进执行过程。
也就是说，ContextSearch 解决的不只是会不会搜，而是让企业数据源、工具、身份和权限边界一起进入同一套可治理的搜索运行。
04
运行时系统让 Agentic Search 稳定可用
一旦搜索进入 Agentic 执行，复杂度就不只在效果上，而会进入系统运行本身。路径可能变化，工具调用可能失败，用户可能中途补充信息，长链路执行可能被中断，结果还需要被验证。
这也是 ContextSearch 需要运行时系统的原因。底层 Agent Loop 可以把一次 session 跑起来，但企业级复杂搜索要成为产品，还需要一层 Harness，把单次执行纳入云上的稳定运行系统。
Harness 的核心不是再多包一层接口，而是把复杂搜索压进可治理的执行结构里。ContextSearch 将一次执行拆成五个固定阶段：Admission 做输入校验和边界控制；Prepare 装配数据源、工具、技能、上下文和权限；Execute 调用模型和工具推进任务；Finalize 收束结果并做校验；Persist 写入结果、状态和副产物。
图 4：通过固定阶段执行，把复杂搜索从黑盒调用变成可恢复、可复盘的运行过程
这套阶段设计的价值，是让系统第一次可以清楚回答：现在运行到哪一步，失败发生在哪一步，是否可以重试，是否需要恢复，最终结果是否被本次证据链支撑。
结果校验也在这里发挥作用。ContextSearch 的校验不是让模型重新判断答案真不真，而是检查最终答案能否在本次工具调用结果、证据链和 trace 中找到支撑。它验证的是“答案是否被本次执行证据支撑”，从而降低模型凭空编造后直接交付的概率，也让失败恢复和后续重试有明确方向。
05
Trace 进入云搜索 OpenSearch，形成可进化闭环
如果一次复杂搜索已经被显式拆成阶段、工具调用、工具结果、事件流、状态变化和最终答案，那么系统就会自然产生 trace。
Trace 的价值不是日志留存，而是把每一次执行变成可以检索、可以聚合、可以分析、可以回放的系统资产。ContextSearch 可以将这些执行事实写入云搜索 OpenSearch，让企业基于自己的运行数据做分析和优化。
图 5：Trace 进入云搜索 OpenSearch，继续反哺离线分析、策略优化和 ContextSearch 执行链路
这条链路让“可进化”不再只是愿景，而是一条工程闭环：在线执行产生 trace，trace 和结果写入 OpenSearch，离线分析发现高频路径、失败模式和有效证据组合，再沉淀为 skill、路由策略、轻量模型或评测样本，最终回灌到 ContextSearch。
| Trace 用途 | 具体做法 | 收益 |
|---|---|---|
| 高频路径沉淀 | 基于 trace 总结高频执行路径，并沉淀为 skill | 降低重复搜索成本 |
| 小模型路由 | 基于 trace 预测 skill 或 datasource | 提升响应速度，降低推理成本 |
| AB test | 对新 skill 或策略做回放和线上对比 | 让优化可评估、可回滚 |
| 失败模式分析 | 统计失败阶段、冗余 tool call、证据不足案例 | 反向优化执行路径 |
| 业务自治 | 各业务基于自己的 trace 沉淀能力 | 避免通用 Agent 上下文持续膨胀 |
最终，ContextSearch 交付的不是更多检索记录，而是三类更面向业务问题的结果。
| 问题层次 | 示例 | 系统交付 |
|---|---|---|
| 内容查询 | 最近提到预算的对象有哪些 | 命中对象、相关内容、来源引用 |
| 聚合汇总 | 把某负责人名下商机跟进情况汇总 | 多源摘要、时间线、关键记录 |
| 分析判断 | 某客户续约意向怎么样，有没有风险 | 结论、支撑证据、不确定性、下一步建议 |
从这个角度看，ContextSearch 的核心不是把搜索接给 Agent，而是把复杂搜索运行成一个可控、可恢复、可持续优化的系统。
面向未来，ContextSearch 还会沿着三个方向继续演进：更个性化的 Context，让系统更好利用身份、权限、历史和记忆；更完整的多模态 Context，让表格、附件、图片、会议纪要、视频内容进入上下文；更可进化的 Execution，让路径选择、恢复调度和验证评测持续优化。
从静态检索到运行时执行，从文档命中到证据交付，从单次问答到持续进化，火山引擎云搜索 ContextSearch 正在探索企业搜索的新形态：让企业数据以更可靠、更安全、更可治理的方式进入 Agent 工作流，成为支撑智能应用持续演进的上下文搜索能力。
以上就是本次分享的内容，谢谢大家。
**分享嘉宾
**
INTRODUCTION
**王正
**
字节跳动
****云搜索资深研发工程师
拥有十余年云原生、大数据与 AI 基础设施研发经验。主导火山引擎多模态与混合检索、RAG 检索等能力在多个场景的工程化落地，在 OpenSearch、Milvus 等搜索与向量引擎以及高吞吐、低延迟的智能检索与生成系统架构，智能体（Agent）上拥有丰富工程实践经验，已获多项发明专利。致力于将前沿技术转化为可规模化落地的工程实践。
