重新思考搜索：作为代码生成的检索架构

来源：Hacker News / Perplexity 主题：Search as Code (SaC) 架构解析

背景

搜索是 AI 系统的核心基础组件。尽管前沿模型（Frontier Models）的能力每月都在增长，但它们仍然需要访问来自更广阔世界的新鲜、准确且经过精心策展的知识。搜索是 AI 系统获取这些知识的主要途径，因此也是任何需要得出结论、采取行动并执行现实世界工作的产品的基础设施。

然而，在代理（Agent）时代，传统的搜索管道（Search Pipelines）正变得越来越过时。传统搜索旨在回答查询，但今天的 AI 代理需要完成形态各异的复杂任务。这些任务要求代理在其运行环境（Harness）中直接定义特定于任务的检索策略。在 Perplexity Computer 的实际应用中，我们观察到单个任务在几分钟内可能调用数百甚至数千次检索操作：这种工作流对人类来说是不可能的，但对 AI 代理而言却是完全自然的。

在这种新范式下，搜索本身必须具备“代理化”特性，其构建模块应作为 SDK 直接暴露给代理运行环境。为此，Perplexity 引入了 Search as Code (SaC，代码即搜索) 作为其新的参考搜索架构。

Perplexity 的搜索堆栈每秒在其应用和 API 平台中处理数千次查询。自 2025 年 9 月首次发布搜索系统架构概述以来，持续的创新支持了 Search API、Agent API 和 Computer 等新产品的推出，并通过自我改进循环不断优化搜索堆栈，以更好地服务用户。

核心内容

从单体架构到可编程原语

传统上，AI 系统将搜索视为一个单体（Monolith）：AI 模型发出查询，搜索引擎运行其预定义的管道，模型将结果作为上下文消费。在早期，由于用户请求相对简单，这种默认架构和默认接口（如函数调用和 MCPs）被认为足够好用，无需担心管道内部设计的优劣。

但随着用户期望从单次分析转向端到端的复杂任务（耗时数小时甚至数天），单体架构开始不堪重负。关键瓶颈在于控制权。虽然前沿模型擅长在固定上下文中进行推理，但最强大的 AI 系统需要能够引导上下文的检索、处理、聚合和渲染方式。传统搜索系统并未为此程度的可控性而设计，因为人类用户无法也不被期望去微调搜索管道的内部逻辑。

然而，今天的代码能力代理运行环境可以通过计算机代码对任何可想象的计算原语施加细粒度的控制。Perplexity 的任务就是提供这些正确的原语。

Search as Code (SaC) 的设计哲学

SaC 的核心思想非常直接：将搜索堆栈的组件作为原语暴露在一个 SDK 中。 对于任何需要搜索的请求，模型按需将这些原语组装成针对特定请求量身定制的检索管道。

这一过程通过代码生成和执行在安全沙箱中完成。与将传统搜索 API 简单包裹在语言运行时中的其他代码生成方法不同，Perplexity 精心设计了 Agentic Search SDK，以尽可能原子化的级别暴露搜索的各个构建模块。

细粒度的控制与可解释性

借助这些构建模块，SaC 赋予模型对每个单独搜索步骤的直接控制权，包括：

• 检索（Retrieval）
• 排序（Ranking）
• 过滤（Filtering）
• 扇出（Fanouts）
• 渲染（Rendering）等

此外，SaC 还使模型能够高效地访问中间状态，如候选列表和排序信号。这种控制力与可解释性的双重杠杆，使得代理能够：

1. 设计跨越数千次检索操作的定制搜索管道。
2. 在运行过程中优化这些管道。
3. 仅将最有用的信息作为模型上下文进行消费。

传统搜索的僵化及其失效模式

世界上最早的搜索引擎是为人类用户构建的，旨在提供可预测的体验（通常是固定数量的相关性排名文档）。这种单体架构产生了高效的搜索结果页面（SERPs），适合人类浏览。

当 LLM 出现后，AI 系统也成为搜索的消费者。Perplexity 自 2022 年推出答案引擎以来，致力于优化搜索结果对 AI 模型的价值，通过子文档检索、上下文效率提升等技术，使每个 Token 的信息密度最大化。

然而，即使是针对 AI 优化的系统，大多仍继承了传统搜索的基本契约：接受查询 -> 运行预定义管道 -> 返回完全处理的结果集。对于简单请求这行之有效，但对于复杂请求，这成为了限制性能、延迟和成本的瓶颈。

这种僵化源于单一的控制点：查询参数。搜索引擎拥有管道的其余部分，模型必须适应它。这种边界对人类扫描链接是合理的，但对于试图在闭环中解决知识密集型任务的 AI 模型来说则是糟糕的。Perplexity 指出，这种僵化导致了三种反复出现的失效模式：

1. 粗糙的上下文（Coarse Context）：AI 模型对上下文的质量和紧凑性非常敏感。传统管道返回的结果往往包含大量噪声或冗余信息，迫使模型在后续推理中浪费算力去筛选无关内容。
2. 缺乏中间状态访问：模型无法查看检索过程中的中间结果（如候选列表、初步评分），导致无法在检索过程中进行动态调整或剪枝。
3. 串行调用的低效：为了获取足够多的信息，模型必须通过多次可见的交互回合（Model-visible turns）重复调用相同的搜索管道，引入大量结果到上下文，造成延迟增加和成本上升。

关键要点

• 范式转移：搜索正在从为人类设计的“单体服务”转变为为 AI 代理设计的“可编程原语”。
• SaC 架构：Perplexity 推出的 Search as Code (SaC) 允许模型通过生成代码来动态组装检索管道，而非仅仅调用固定的搜索 API。
• 细粒度控制：模型现在可以直接控制检索、排序、过滤、扇出和渲染等每一步骤，并能访问中间状态（如候选列表）。
• 解决僵化问题：传统搜索架构在处理复杂、长周期的代理任务时存在性能、延迟和成本瓶颈，SaC 通过动态管道优化解决了这一问题。
• 原子化 SDK：Agentic Search SDK 将搜索功能拆解为原子级别的原语，使模型能够按需构建定制化的检索流程。
• 效率提升：通过减少不必要的上下文引入和中间步骤，SaC 建立了代理搜索新的成本-性能前沿。

意义与影响

Search as Code (SaC) 标志着 AI 基础设施架构的一次重要演进。它承认了 AI 代理与人类用户在信息获取方式上的根本差异：人类需要简洁、确定的结果，而 AI 需要灵活、可控制且高密度的信息流。

对于 AI 开发者而言，这意味着搜索不再是一个黑盒服务，而是一个可以通过代码精确操控的计算组件。这种转变使得构建能够执行复杂、多步骤任务的自主代理成为可能，这些代理能够自主决定何时搜索、搜索什么、如何评估搜索结果以及何时停止搜索。

Perplexity 通过公开这一架构及其在基准测试中的表现，不仅展示了其在搜索技术上的领先地位，也为整个 AI 社区提供了一套处理大规模、高复杂度信息检索问题的参考标准。随着代理应用从简单的问答向长期的自主工作流发展，这种“代码即搜索”的架构将成为构建下一代智能系统的关键基石。