程序员视角：Agentic Search工程实践指南

Agentic search 让 AI Agent 能够规划查询、检查结果、识别缺失的证据，并在回答之前再次搜索。

它与传统 RAG 的区别在于，可以处理实时的网络信息，而不局限于预索引的知识库。

搜索结果应被视为证据，而非最终答案。

一个生产级别的搜索 Agent 需要持久化状态、来源质量检查、引用标注，以及明确的搜索限制。

最难的部分通常不是调用搜索 API——而是判断 Agent 何时有足够的证据可以停止。

给 AI Agent 添加网络搜索看似简单。

定义一个搜索工具，将用户的问题发送给 API，将结果返回给模型，再让它写一个答案。这样做足够做一个 Demo，但很少能构成一个可靠的研判系统。

第一次查询可能太宽泛。结果可能过时、重复或是推广内容。重要的证据可能埋在好几页之后，而两个可信来源可能对同一说法存在分歧。

因此，一个有用的搜索 Agent 必须做的不仅是检索链接。它必须决定要搜索什么、评估发现了什么、识别仍然缺失的内容，以及判断何时继续搜索已经没有意义。

这就是 agentic search 的基本思路。

什么是 Agentic Search？

Agentic search 是一个由 AI Agent 控制的迭代搜索过程。

Agent 不会发送一条查询就立即生成答案，而是将请求视为一个研究任务。它可以将任务分解为更小的问题、创建多个查询、检查单个页面、比较来源，并根据出现的新信息调整搜索计划。

看这个请求：

哪种搜索基础设施最适合需要当前产品文档、区域来源和可验证引用的客服 Agent？

基础的搜索集成可能会将整个句子作为一条查询提交，然后总结前几个结果。

而 agentic 系统会采用不同的方式处理这个问题。它可能首先识别出需要做出的几个决策：

哪些服务能提供足够新鲜的网页结果？

哪些支持地理或域名过滤？

它们是否返回来源 URL 和发布日期？

当摘要不够用时，它们能否检索完整页面？

它们的延迟和定价特征如何？

后续执行的搜索取决于 Agent 前面发现了什么。如果某个提供商支持区域搜索但没有明确记录其引用元数据，Agent 可以专门针对这个缺口创建一个后续查询。

这就是使搜索过程变得 agentic 的原因：路径并非完全预先设定。

Anthropic 在其构建有效 Agent 的指南中做了类似的区分。Workflow 遵循预定义的路径，而 Agent 则动态决定如何使用工具并引导过程。

Agentic search 将这种决策能力应用于信息检索。

Agentic Search 循环

大多数 agentic search 系统都可以理解为一个反馈循环：

理解目标 → 规划研究 → 搜索 → 评估证据 → 完善或回答

Agent 首先解析请求。这很重要，因为用户的提示词并不总是包含一个好的搜索查询。

例如，"compare the leading AI agent frameworks" 这句话留下了几个未解答的问题。什么才算领先？比较应该关注采用率、编排功能、部署方式、可观测性还是企业支持？答案是否需要当前的发布信息？

在识别出真实的信息需求后，Agent 生成一条或多条聚焦的查询。它将它们发送到搜索 API，接收结果，并评估这些结果是否提供了足够的证据。

如果证据薄弱或不完整，Agent 会再次搜索。

一个简化后的控制循环可能长这样：

state = create_research_state(user_request)

while not should_stop(state):
    query = plan_next_query(state)
    results = search_web(query)
    evidence = evaluate_results(results)
    state.add(query, evidence)

answer = generate_answer(
    request=user_request,
    evidence=state.accepted_evidence,
    include_citations=True,
)

代码不是困难的部分。真正的工程决策隐藏在 plan_next_query、evaluate_results 和 should_stop 内部。

这些函数决定了系统是像一个研究 Agent 那样运作，还是仅仅像一个语言模型反复调用搜索端点。

Mistral 的 Agentic Search 文档描述了一个类似的编排层，其中模型可以搜索、检查结果、浏览来源，以及在新信息需求出现时再次搜索。

Agentic Search 与传统 RAG

Agentic search 和检索增强生成解决的是相关问题，但它们并非同一架构。

传统 RAG 通常从一个准备好的知识库开始。文档被收集、分块、转换为嵌入向量并存储在向量数据库中。当用户提交问题时，系统检索相关片段并将它们放入模型的上下文。

这在信息稳定且组织控制文档时效果很好。内部政策、产品手册、支持文章和私有公司数据都是 RAG 的良好用例。

Agentic search 更适合频繁变化、存在于开放网络或无法预先索引的信息。它可以在执行过程中更改查询策略，并调查沿路发现的意外信息。

在实践中，开发者并不总是需要二选一。

一个生产级 Agent 可能首先搜索内部知识库。如果内部材料不足或请求依赖于近期信息，Agent 可以搜索网络并将新证据与内部文档进行比较。

RAG 提供受控的组织知识。Agentic search 提供新鲜度和外部覆盖。

使用 Web Search API 构建 Agentic Search

Web Search API 提供信息访问。周围的 Agent 工作流决定这些信息是否能变成可靠的回答。

架构通常包含一个规划器、一个搜索工具、一个证据存储、一个评估器和一个答案生成器。根据应用场景，还可能有页面内容提取器、重排序器、引用验证器或人工审核阶段。

给搜索工具一个清晰的契约

搜索工具应该接受可预测的、结构化的输入。这些可能包括查询词、语言、地区、日期范围、允许的域名、屏蔽的域名以及最大结果数。

输出也应该保持一致。每个结果理想情况下应包含标题、URL、摘要、来源名称和发布日期。如果工具检索完整页面内容，该内容必须与其原始 URL 保持关联。

清晰的契约使工具调用更容易测试和检查。它也降低了 Agent 将搜索摘要与已验证声明混淆的风险。

搜索函数应该检索证据。它不应该静默地生成最终答案。

将搜索结果视为证据

高排名结果并非自动成为可信来源。

搜索排名使用多种信号来衡量相关性，但不保证准确性。一个结果可能过时、带有推广性质、从其他页面复制而来，或者基于已不可用的来源。

在使用一个结果之前，Agent 应该考虑以下问题：

该页面是否直接支持这个声明？

发布日期是否相关？

这是第一手来源还是对另一来源的摘要？

多个结果是否在重复同一个底层报告？

是否有其他可信来源提出相反观点？

对于高影响力的声明，Agent 可能需要检查完整页面或用另一个独立来源确认信息。

证据也应该与其引用保持关联。如果工作流对页面进行摘要后丢弃了 URL，最终模型可能产生一个听起来经过充分研究但无法展示其声明来源的答案。

保留研究状态

多步骤搜索 Agent 需要记忆。

至少，它应该保留已尝试的查询、已检查的来源、每个来源支持的声明、未解决的问题，以及需要另一次搜索的原因。

没有这种状态，Agent 可能重复相同的查询、多次检查同一个来源，或者丢失声明与其证据之间的关联。

基于图的编排非常适合这类工作流，因为搜索自然包含分支和循环。例如，LangGraph 的 Graph API 使用共享状态、节点和条件边。

搜索节点可以检索结果。评估节点可以判断证据是否充分。条件边然后可以将工作流发送回查询规划或转发到答案生成。

框架本身是可选的。重要的是每个阶段都要留下足够结构化的信息，供下一阶段做出更好的决策。

停止是 agentic search 中最重要——也最容易忽略——的部分之一。

如果 Agent 停止得太早，答案可能不完整。如果它继续搜索，延迟和 API 成本会持续上升，即使额外的结果几乎不增加价值。

一个可靠的工作流通常结合基于证据的停止条件和硬性限制。

Agent 可能在所有必需的子问题都有支持证据、重要声明都有引用、最近的搜索不再产生新信息时停止。同时，系统应该施加搜索次数、页面检查次数、token 数量或秒数的上限。

最终决策不应完全依赖模型说"我现在有信心了"。

模型置信度可能有用，但它不是安全边界。

评估 Agentic Search 系统

仅评估最终答案是不够的。

两个 Agent 可能产生相似的回复，但使用的过程却大相径庭。一个可能依赖当前的第一手来源并在四次聚焦搜索后停止。另一个可能执行十五次重复搜索、使用弱来源，并附加不支持其声明的引用。

有用的评估应该同时检查结果和研究轨迹。

groundedness（扎根性）询问答案是否被收集的证据支持。引用正确性检查每个链接的来源是否支持其出现的句子。来源质量审查权威性、新鲜度、独立性和相关性。

覆盖率衡量研究是否覆盖了请求的重要部分。搜索效率考虑完成任务的查询数量、页面检查次数、token 数量、API 调用次数和耗时。

轨迹本身也可以被测试。Agent 在结果不佳后是否重新表述了查询？它是否识别了相互冲突的证据？它在需要时是否应用了日期或域名过滤器？它是否出于可辩护的原因停止了？

Anthropic 的 AI Agent 评估指南建议同时评估最终输出和产生它们的过程。这对搜索 Agent 尤为重要，因为一个表面上好的答案可能掩盖了一个脆弱的研究过程。

Agentic Search 最适用的场景

当答案依赖于当前的、外部的或难以预测的信息时，Agentic search 很有价值。

它适用于研究助手、监控 Agent、事实核查系统、竞品情报工具、购物助手、技术支持 Agent，以及必须用可验证来源回答的产品。

当答案已经存在于一个稳定、受控的知识库中时，它的用处较小。在这些情况下，传统检索可能更快、更便宜、更容易评估。

Agentic 行为应该因为任务需要自适应研究而引入——而不是仅仅因为 Agent 循环在技术上是可能的。

Agentic search 将检索从一次查找转变为受管理的研究过程。

Agent 决定它需要学习什么、创建查询、评估来源、保留证据、识别缺口，并判断研究何时完成。

这种灵活性帮助 AI 系统回答当前的和开放性的问题，但也带来了新的工程责任。开发者必须控制搜索循环、验证引用、衡量来源质量、保留状态，并管理成本和延迟。

调用 Web Search API 是容易的部分。

构建一个知道要搜索什么、要信任什么、以及何时停止的 Agent，才是真正的工作开始。

如果你正在构建一个搜索网络的 Agent，最难控制的部分是什么：查询规划、来源质量、引用，还是停止条件？

我很感兴趣你是如何处理这个问题的。