智能体搜索的三种技术路线
文章解析智能体搜索的三条主流技术路径:检索驱动(Retrieval-Centric)、编排驱动(Harness-Centric)和模型驱动(Model-Centric)。分别阐述其原理、典型场景、优势与局限,并指出当前实践中的混合演进趋势。
当智能体不知道如何找到正确答案时,智能体搜索才真正有趣。
当然,它可能自认为知道答案,甚至一本正经地胡说八道。但由于缺乏足够的领域认知,智能体往往会把自己带偏。它经常误判用户眼中“相关内容”到底是什么。
例如:在时尚领域,搜索“红鞋”时,用户期待的是高跟鞋;而“ABE”并不是林肯(Abraham Lincoln),而是一款 A/B 测试工具。
这些都是特定领域知识。智能体只有在获得充分上下文后,才能理解这些隐含含义。而要做好上下文工程,往往离不开智能体搜索。
有趣的是,人们口中的“智能体搜索”,实际上可能指三种完全不同的技术路线:
- 检索驱动(Retrieval-Centric) —— 构建高质量搜索,让智能体通过检索补充缺失的上下文。
- 编排驱动(Harness-Centric) —— 即便搜索能力有限,也能通过工作流、规则和反馈,引导智能体逐步找到信息。
- 模型驱动(Model-Centric) —— 通过微调大语言模型,让模型学会搜索企业内部数据和知识库。
理解了它们的差异,你就能明白:当同事谈论“智能体搜索”时,他们究竟在说哪一种。
一、检索驱动
当前沿模型不知道答案时,它们会去搜索。例如,向 ChatGPT 提问新闻事件,它会去搜索;问它非常具体的技术问题,它也会搜索。在训练过程中,LLM 会通过搜索示例学习自己不知道的内容,从而找到所需信息。
因此,我们只需要构建高质量的搜索,就能满足智能体的各种查询需求。
举例来说,假设我们运营一个电商目录。用户搜索“红鞋”,实际意思是“红色高跟鞋”,但智能体并不清楚。幸运的是,它会执行搜索。下图展示了搜索返回的正确结果。

当然,这里还可能涉及其他组件——如查询理解、结果多样性、定制嵌入模型等。
关键点:搜索牵引智能体找到真正相关的内容。我们假设搜索可以定义“红鞋”的正确含义,从而覆盖智能体自身的认知偏差。
当 RAG 答案看起来不像答案时
大多数团队在检索驱动方法中会使用经典的 RAG(检索增强生成)架构:将答案拆分成多个片段,并通过嵌入向量训练模型识别这些片段为答案。
问题是,这些答案并不总是看起来直接对应问题。例如:
问题:
书籍《Ubik》的梗概
答案:
到 1992 年,人类已殖民月球,心灵能力普遍存在。主人公 Joe Chip 是 Runciter Associates 的一名负债技师,这家公司雇佣“惰性人”(inertials)来抵消通灵者和“预知者”的能力,以保障客户隐私。
如果你没有读过《Ubik》,很难看出这个答案与问题的直接关联。智能体可能只会说“故事挺酷的”,然后忽略这些信息。
事实上,这种搜索方式与前沿模型依赖的网页搜索是分离的。网页上包含标题、章节和其他元素,这些信息能够将答案置于上下文中,更容易让人理解。
最大的缺点?搜索依然困难。我们不是谷歌。
最重要的是,我们没有像谷歌或必应那样的完美搜索。即便搜索质量不错——几乎没人能做到谷歌级别的结果。而由于智能体依赖搜索,正如 Lester Solbakken 所说,检索中的简单干扰因素[1]就能轻易混淆推理。
二、编排驱动
谁应该负责?智能体应该管理搜索过程,还是搜索应驱动智能体?
把重点放到 harness 上时,我们让智能体来掌控。
想象一下,将搜索工具剥离到核心检索原语。比如只剩一个 BM25 后端,或者带 CLI 工具的文件系统。我们告诉智能体,用这些未经调优的工具去找到所需内容。智能体可能会更费劲,但它聪明,总能搞明白,对吧?
然而,智能体可能找到它认为相关的内容,如下图所示。可惜,那并不是真正相关的内容。为了帮助智能体,我们注入外部知识。我们让一个裁判指导智能体,纠正其错误,并引导它采用更好的搜索策略。
所以,当智能体返回结果时,不是“用户”接收候选项,而是裁判为结果贴标签,标注其相关性。智能体根据提示去寻找与标注为相关的结果相似的内容,同时避免标注为不相关的内容。借用 Jo Kristian Bergem 的说法,这是增强版的相关性反馈[2]。


我们也可以提前用信息引导智能体。例如,我见过团队借鉴编码智能体的技能。想象一个针对性的查询计划,告诉智能体如何使用其工具来解决特定问题。

优化内容以帮助 harness
我们通过优化内容的可查找性,进一步帮助智能体。这就是我们在编码智能体时用过的技巧。我们撰写文档,向智能体解释某些内容为何有用。我们不仅仅依赖那块简单的信息块,而是记录知识的用途:
/books/scifi/ubik.txt
## 关于书籍《Ubik》
Ubik 是 Philip K. Dick 的作品
## 简介
到 1992 年,人类已经殖民月球,超能力普遍存在。主角 Joe Chip 是 Runciter Associates 的一名负债技术员,这是一家“审慎组织”,雇佣“惰性者”(能够抵消心灵感应者和“先知者”能力的人)来保障客户隐私。
与简单的信息块不同,这段信息有明确的用途。当它出现在上下文中时,可以清楚地知道它解决了什么问题。
通过组织和编目信息,我们做到了每个搜索开发者都希望内容团队能做到的事情:真正优化内容,使其可被查找。
缺点:成本
主要缺点是什么?Token 成本。这里的探索不仅仅是发起一次搜索并检索一组结果,而是智能体对环境的探索。而且每次新的上下文窗口都会重新开始这种探索。
三、模型驱动
如果我们直接对 LLM 进行微调,让它更高效地进行搜索,会怎么样?
基于 harness 的方法,会通过一条漫长曲折的路径去获取相关结果。每次遇到新的上下文窗口,它都会反复重新学习哪些方法有效,重复做很多无用功。这既昂贵又缓慢。
我们能不能训练一个模型,让它不再重复这些工具调用错误?
我们的裁判可以帮助标注智能体的部分推理 / 工具调用路径,哪些是有用的,哪些则没那么有用。一旦有了这些标注轨迹,就可以对一个开源权重模型进行微调,使其在给定输入时,能够更主动、更高效地做出正确的工具调用。
如下图所示,例如,对于“red shoes(红色鞋子)”这个查询,模型在经过大量微调后,已经清楚地知道如何进行搜索。

现在我们构建了一个专门针对搜索任务的模型。我们不再过多调优检索器本身,而是继续使用更简单、甚至“笨”的搜索工具。
更有趣的是,这种 agentic search 模型的行为可以仅通过调整 system prompt 来改变。例如,“这是一个电商搜索任务,优化 top 10 排名”与“你正在为金融研究检索信息,同时最大化多样性和相关性”会产生不同的行为策略。
此外,这类模型可以保持较小规模。由于它们只专注于搜索环节,而不是整个领域问题,因此可以压缩到足够可控的体量,从而支持自部署。
缺点?仍处早期阶段
该领域的先行者是 SID[3],类似 Glean 的 Waldo 模型也已经进入这一方向。
这些方案都很有前景,但尚未被广泛采用,仍存在大量未知问题。从某种意义上说,我们还不清楚它的上限和下限在哪里。不过我认为,这一范式在未来几年会有非常大的潜力,换句话说——拭目以待。
模糊性的炼金术
人们对“agentic search”的使用既混乱又不一致。他们只关注自己所处理问题的那一部分。这意味着我们拥有一组像“强化后的基础金属”一样的解决方案——而什么样的“炼金术”能将它们整合在一起仍不清楚。
我们正在收敛到一种有趣的混合方向:更易组织的数据(例如 PageIndex[4])。我看到了一些在 harness 设计中的模式,它们类似于编码智能体——通过 hooks / evaluators 来引导智能体,或通过“技能”在事先对其进行指导。就像在编程中一样,智能体会“吞噬”这些 harness。当某种成功模式出现时,在我们的例子中,即 agentic search 模型,会训练并记住这些模式。
检索也似乎正在向以智能体为中心的方法演进。智能体拥有其自身特定且独特的检索模式[5]。我们终于看到晚期交互 + 学习型稀疏检索方法迎来发展,由 LightOn[6] 和 Mixedbread[7] 等公司推动发展并取得进展。
JOTO 企业落地观察
- 企业若选择检索驱动路线,需优先投入知识结构化与检索评估体系,而非盲目堆砌向量数据库;RAG 效果瓶颈常不在模型,而在“答案是否被正确切分并赋予语义锚点”。
- 编排驱动虽降低对底层检索精度的依赖,但要求团队具备可观测性基建能力——必须能捕获、标注、回放智能体每一步工具调用与裁判反馈,否则无法形成闭环优化。
- 模型驱动路线对算力与工程成熟度要求最高,但一旦落地,可显著降低长期 token 开销;适合搜索高频、领域封闭、安全合规要求严苛的垂直场景(如金融尽调、法务审查)。
立即咨询 JOTO
JOTO 提供覆盖企业智能体规划与搭建、AI 平台私有化部署、RAG 知识工程、AI 安全治理、FDE 驻场共创及持续运营优化的全周期 AI 落地服务,帮助企业把验证中的 AI 能力转化为安全、可控、可持续迭代的生产力。 联系 JOTO 获取 AI 落地咨询
想把这些做法用到你的业务里?
留下你的场景和痛点,我们帮你判断从哪一步开始。
联系我们


