重新思考 Search as Code Generation (25分钟阅读)

# 重新思考搜索即代码生成 来源：https://research.perplexity.ai/articles/rethinking-search-as-code-generation 搜索是 AI 系统的核心原语。前沿模型的能力逐月增强，但它们仍需要从外部世界获取新鲜、准确且精心整理的知识。搜索是 AI 系统接入这些知识的主要方式，因此也是任何需要得出结论、采取行动并完成实际工作的产品的基础组件。 我们相信，在智能体时代，传统搜索流水线已日益落后。传统搜索回答的是查询，而如今的智能体要完成的任务形态千变万化。这些任务要求智能体能够在其运行框架内直接定义任务特定的检索策略。在 Perplexity Computer 内部，我们观察到单个任务在几分钟内就能发起数百甚至数千次检索操作——这种工作流对人类来说不可能做到，但对智能体而言却完全自然。 在这样的世界里，搜索本身必须变得具备智能体特性，其构建模块可以直接作为 SDK 嵌入智能体运行框架中。我们推出 **Search as Code (SaC)** 作为 Perplexity 新的参考搜索架构。 ## 引言 Perplexity 的搜索栈每秒处理数千次查询，覆盖我们的应用和 API 平台。2025 年 9 月，我们发布了搜索系统的首份[架构概述](https://research.perplexity.ai/articles/architecting-and-evaluating-an-ai-first-search-api)。这些系统的持续创新支撑了新产品如 [Search API](https://www.perplexity.ai/hub/blog/introducing-the-perplexity-search-api)、[Agent API](https://www.perplexity.ai/hub/blog/agent-api-a-managed-runtime-for-agentic-workflows) 和 [Computer](https://www.perplexity.ai/products/computer) 的发布，同时自我改进循环不断优化搜索栈，让每一天都能更好地服务用户。 传统上，AI 系统将搜索视为一个整体：AI 模型发出查询，搜索引擎运行其预定义的流水线，然后模型将结果作为上下文消费。在大部分情况下，这种做法足以满足早期 AI 用户的需求。鉴于用户请求相对简单，没有必要过于关注搜索流水线的具体设计，或流水线架构是否对当前任务最优。默认设定被认为足够好，默认接口（函数调用和 MCP）也是如此。 ###### 图 1 | 传统搜索架构暴露一个固定的系统，模型串行调用；而 Search as Code 则暴露原子化的搜索原语，智能体通过生成的代码来组合这些原语。 然而今天，这种做法正逐月变得更加过时。用户要求的远不止是 AI 的单次分析。他们期望智能体能在数小时甚至数天内端到端完成任务。这些任务可能复杂、开放，且信息需求高度多变，整体式架构在这些需求的重压下正逐渐崩溃。 最终，关键瓶颈在于**控制**。前沿模型在固定上下文上的推理能力已经相当出色。然而，最强大的 AI 系统还需要能够引导*如何*检索、处理、聚合上下文并将其呈现给模型。 传统搜索系统在设计时并未考虑这种程度的可控性。毕竟，即使提供细粒度控制，也不能期望人类用户去精细操作搜索流水线的内部结构。早期 AI 模型只能通过函数调用和 MCP 的线性轨迹来控制搜索。但如今的前沿模型，借助能处理代码的智能体运行框架，可以通过计算机代码对任何可想象的计算原语施加精细控制。我们的任务就是提供正确的原语。 为满足这一需求，我们在所有产品中引入了一种新的搜索架构：**Search as Code (SaC)**。这种新架构使模型能够*深入*搜索栈内部，而不仅仅是消费其最终输出。核心理念很直接：我们将搜索栈的组件作为 SDK 中的原语暴露出来。对于任何需要搜索的请求，模型会按需将这些原语组装成针对该请求量身定制的检索流水线。 组装流水线是通过代码生成并在安全沙箱内执行完成的。与其它由代码生成驱动的搜索方法不同，我们并非简单地将传统搜索 API 塞入 shell 或语言运行时。相反，我们精心设计了一个 Agentic Search SDK，以尽可能原子化的粒度暴露搜索的各个构建模块。 ###### 图 2 | Search as Code (SaC) 在多个基准测试套件上提升了智能体搜索的性能边界。 有了这些构建模块，SaC 赋予模型对每个搜索步骤的直接控制：检索、排序、过滤、扇出、呈现等。它还让模型能够高效访问中间状态，如候选项列表和排序信号。这两个杠杆——控制力和可读性——共同使智能体能够设计包含数千次检索操作的定制搜索流水线，在运行中优化这些流水线，并只将最有用的信息作为模型上下文来消费。 本文介绍了 SaC 的动机、设计和实现，以及在现有和新基准上的实证结果。SaC 为智能体搜索建立了新的成本-性能边界，我们很高兴与用户和更广泛的 AI 社区分享。 ### 传统搜索的僵化 世界上最早的搜索引擎是为人类用户设计的。这些用户期望一种可预测的体验，通常包含固定数量的按相关性排序的文档。用户不想微观管理搜索过程；他们只想输入查询并找到有用结果。 因此，面向人类的搜索引擎收敛为一种常见的整体式架构，旨在生成人性化的搜索引擎结果页面，其中包含输入查询的前 n 条结果。这种模式推动了消费者搜索领域数十年的进步。它快速、熟悉，且对人类浏览非常高效。 然后出现了大语言模型，AI 系统也成为了搜索的消费者。Perplexity 在 2022 年推出了我们的答案引擎，引领了这一转变。自那时起，我们的搜索工程工作一直专注于如何最大化搜索结果对 AI 模型的价值。为了构建世界上最准确、最可靠的 AI，我们必须设计一个专注于使每个 token 都尽可能信息密集的搜索系统。由此在[子文档检索](https://research.perplexity.ai/articles/query-aware-context-compression-for-better-snippets)、上下文效率、语义理解及其他关键领域产生的创新，极大地提升了 AI 系统检索和利用信息的能力。 然而，即使是经过 AI 优化的系统，在很大程度上仍继承了与传统搜索引擎相同的基本契约：接受查询，运行预定义的搜索流水线，返回完全处理后的结果集。对于简单请求，这种方法可行。但对于更复杂的请求，这就变成一个日益严重的瓶颈，导致性能下降、延迟增加和成本上升。 ###### 图 3 | 传统搜索系统迫使智能体工作流通过模型可见的轮次来安排搜索。模型必须反复使用不同的查询参数调用相同的搜索流水线，并将所有结果引入模型上下文。 #### 僵化导致的失效模式 传统搜索流水线围绕一个单一控制点设计：查询参数。搜索引擎根据其预定义的逻辑拥有流水线的其余部分，模型必须去适应它。对模型而言，查询参数以下的任何东西都是僵化的——实际计算的形态超出模型控制。 当消费者是浏览链接的人类时，这是一个合理的边界。但当消费者是试图在闭环中解决知识密集型任务的 AI 模型时，这就是一个糟糕的边界。根据我们的经验，这种僵化会导致三种反复出现的失效模式： 1. **粗粒度上下文。** AI 模型对上下文的质量和紧凑性很敏感。质量和紧凑性都高度依赖查询，而整体式搜索流水线并非针对所有查询都表现最优而设计。例如，如果模型只需要一条高度精确的信息，但只能访问一个优先保证召回率的端到端搜索端点，那么使用该端点就会向模型上下文引入大量不相关信息。另一方面，如果模型需要多条信息，而每条信息都需要不同的搜索策略，它可能被迫为所有信息串行调用同一项次优流水线，导致成本膨胀和上下文嘈杂。 2. **无法利用领域知识。** 在很多情况下，模型可能拥有领域知识（来自训练、智能体技能、记忆或 LLM 轨迹中的早期 token），这些知识本应指导搜索策略。然而，僵化的搜索接口阻止了模型利用这些知识。例如，模型可能意识到，对于某个特定请求，它应该以特定方式混合词法和语义信号，优先考虑某些来源，或按特定键聚合结果。除非这些见解恰好能通过查询参数实现，否则模型无法真正采取行动。 3. **低效控制流与上下文污染。** 许多搜索工作流并非天然的串行结构。它们可能需要查询变体上的扇出、并行获取、去重以及其他需要非线性和异步控制流的操作。强制将这些步骤通过重复的模型轮次来实现会增加延迟，并使工作流难以优化。同时还会用嘈杂的中间状态污染模型上下文，这些状态可能对模型的推理没有帮助，从而导致性能下降和更频繁的压缩。 在 AI 的函数调用和 MCP 时代，对这些挑战几乎无能为力。当每次搜索操作都需要一次 LLM 推理的往返时，开发者自然倾向于在一次往返中完成尽可能多的工作。这意味着端到端的搜索流水线返回完全处理后的结果集，供模型直接消费。 结果，如今大多数面向 AI 的搜索系统仍然在这种整体契约下运行。然而，随着模型智能和用户需求的持续增长，这种契约的缺点变得更加明显。当今最先进的 AI 系统，建立在以代码优先的运行框架之上，能够组合出每分钟执行数千次操作的任务特定工作流。搜索系统尚未完全实现这一潜力。 我们长期以来一直怀疑，AI 原生搜索的正确边界应该位于栈中更底层。模型不应仅仅调用一个搜索引擎。它们应该能够根据具体任务的需求来编排搜索栈的各个独立部分。这需要一个根本不同的架构。 ### 设计可编程搜索架构 下一代搜索架构将围绕一个核心原则：搜索应当能够被 AI 智能体原生地编程。智能体不应被限制在一组预先确定的搜索流水线中。相反，智能体必须能够使用不同抽象层次的可组合构建模块，来构建特定任务所需的流水线。 我们的新 Search as Code (SaC) 架构体现了这一原则。在 SaC 中，没有一次检索操作是通过函数调用或 MCP 接口分发的。所有操作都是通过模型生成的 Python 代码来编排的。对于最简单的搜索需求，这段代码可能只包含对高层搜索端点的几次请求。但对于复杂任务，代码可以根据需要变得非常复杂，涉及条件执行、异步、并行以及对各种底层原语的调用。 ###### 图 4 | Search as Code (SaC) 架构依赖于一个由模型、计算沙箱和位于 Perplexity 搜索基础设施之上的 Agentic Search SDK 组成的栈。 SaC 包含三个紧密耦合的层次： 1. **模型**作为控制平面。它们推理用户（或父智能体）的指令，将指令分解为任务，决定每个任务需要哪些检索和处理流水线，并生成实现这些流水线的代码。 2. **计算沙箱**通过安全的代码执行运行时提供确定性计算。它们为模型实现控制流、批处理、重试、过滤、连接、聚合及其他确定性操作提供了一个画布。 3. 我们的 **Agentic Search SDK** 将 Perplexity 的搜索栈暴露为可组合的原语。它提供从底层检索操作到高层语义解析的构建模块。该 SDK 嵌入在沙箱的执行运行时中，使模型能够在单次推理轮次中编排多达数千次操作。下面，我们讨论每一层的设计决策。 #### Agentic Search SDK Agentic Search SDK 定义了可编程搜索的构建模块。重要的是，我们的 SDK 并非一个以库形式打包的现有搜索 API。在过去的几个月里，我们的工程团队将搜索栈重新架构为模块化、可组合的原语。我们构建了 Agentic Search SDK 以直接访问这些原语，为模型编排任务特定的检索流水线提供了一个更强大的画布。 高层次的端到端搜索流水线在 SDK 中仍然可用，但它们不再是唯一的选择。相反，它们作为常见搜索模式的一种速记形式。模型可以根据任务需要自由使用或绕过它们。 **运行时的选择：** 我们考虑了 Python、Rust、TypeScript 和 Bash 作为 SDK 的运行时。我们推测 Python 因其普遍性和数据处理库的生态系统将是最自然的选择。内部测试证实了这一点，今天推出的 SDK 版本是基于 Python 的。我们计划定期重新评估运行时选择，以确保其继续提供最佳智能体体验。 **通过自动研究持续改进：** 我们还通过迭代的自动研究循环来优化 SDK 对前沿 LLM 的可消费性。这个循环持续运行数周，会根据延迟、代码生成质量和整体任务性能等指标提出并验证 SDK 改进。自动研究循环已经对 SDK 的结构和美学做出了许多更改，在所有维度上都取得了显著收益。我们计划在新的前沿模型和搜索组件出现时，继续通过自动研究来进一步完善 SDK。 #### 沙箱 沙箱为定义和运行 SaC 流水线提供安全环境。它们执行模型生成的代码，并提供对 Agentic Search SDK 的访问，以促进与各个搜索原语的交互。 我们在优化和加固沙箱方面投入了大量精力，其整体系统设计本身就值得用一篇文章来阐述。这里，我们重点介绍与 SaC 最相关的设计考量：管理中间状态。 SaC 赋予智能体在单次推理轮次中编排复杂流水线的能力。然而，某些中间状态需要跨轮次传递。例如，一个模