搜索即代码：第三阶段生命周期深度解读

到了2026年，大模型已经不再只是对话框里的聊天工具，而是化身成智能体。这时候，人们对于搜索的期待，其实早已变了个样。

最直观的变化是，国内外的搜索引擎巨头，现在展示搜索结果的页面里，排在最前面的往往是一段AI生成的回答，然后才是各种链接。

更深层的变化在于：以前搜索是给人看的——人面对一堆网页链接各取所需；现在，搜索是给大语言模型用的——它只需要一段精简的文本。

但这真的是搜索的终极形态吗？Perplexity给出了否定的答案，并发布了一篇极具里程碑意义的技术博客，宣告搜索将进入第三个阶段：Search as Code（SaC）——搜索即代码。

在Perplexity的测试中，SaC在复杂任务上的表现不仅全方位吊打OpenAI和Anthropi​​c，更是在成本上实现了近乎不可能的85%压缩。

尽管这些数据看起来有些夸张，但架构背后隐藏的深度思考，确实值得认真琢磨。

01 搜索的黄昏

自打OpenAI推出大语言模型ChatGPT以后，“搜索引擎”这个词被提及的次数就越来越少了。要真正理解SaC，得先想明白为什么现有的搜索架构已经不再适用。

就像前面说的，无论是谷歌还是百度，最初都是为人类设计的。人类接收信息的容量和处理频率都有明确的上限，所以只需要最直观、固定的结果搜索页。那种“输入关键词→搜索引擎黑盒处理→返回前N个结果”的单体服务模式，不知不觉统治了互联网信息几十年。

大语言模型出现后，Perplexity曾引领了一波“回答引擎”的潮流——让模型整合并提炼多篇网页内容，试图通过优化信息密度来帮助模型更好地理解、推理和生成。但本质上，模型依然只是在一条预定义的单向管道末端被动接收信息。

然而，智能体时代的降临，让搜索的使用者从人类变成了大语言模型，原先的“单体服务”模式瞬间变成了阻碍。

如今的智能体已经远不只是问个问题那么简单，它们需要实际操作电脑完成任务。在Perplexity内部的Computer项目中，研究者发现，单个复杂调研任务在短短几分钟内就可能触发成百上千次检索操作。这种高频且非线性的需求，直接让传统“单体服务”面临三个挑战而濒临失效：

一是粗颗粒度的上下文。大模型对上下文极其敏感，而传统“单体服务”为了保证检索信息的召回率，往往会塞给模型海量的冗余信息。这种为了大海捞针连带着输送几十吨海水的做法，直接导致上下文窗口迅速爆炸，进而转化为激增的推理成本和频繁出现的幻觉。

二是领域知识的浪费。前沿模型本就已经积累了深厚的“搜索经验”——它知道查询某些知识性强的信息应该去官方渠道而非第三方信息源。但在固定的API检索模式下，模型原本具备的洞察力无法干预搜索底层的检索逻辑。

三是低效的对话轮次与上下文污染。在传统的Function Calling模式下，智能体每进行一次检索、去重、筛选等操作，都要完成一次“模型推理→触发工具→接收结果”的循环。这不仅造成延迟累积，还让模型上下文充斥大量中间态的垃圾信息。Perplexity的数据显示，真正有用的信息往往在这个过程中被淹没。

02 将搜索解构

Perplexity提出的Search as Code，听起来有些抽象，但核心思想其实非常直接：

让模型去编排搜索代码，而不是调用搜索接口。

基于这个思想，Perplexity提出了“搜索即原语（Search as Primitives）”。在计算机科学中，“原语”就是不能再分解的基础构建块。SaC要做的，就是把原本封装在黑盒中的搜索过程拆解成初始检索（retrieve）、并行查询扩展（fanout）、精细化过滤（filter）、去重（dedupe）、重排（rerank）等原子组件。

为了实现这些功能，SaC由三个紧密耦合的层次组成：

首先是模型层，通常采用具备顶尖推理能力的模型担任“指挥官”。它生成的不再是输入到文本框中的关键词，而是一段复杂的Python代码。

然后是计算沙箱，提供一个隔离、安全、确定的执行环境。只要给定相同的输入和代码，输出永远一致，与大语言模型的概率性生成互补。沙箱负责执行循环、重试、数据聚合等一系列操作，完全不需要大语言模型干预。

最后是原子化SDK，这是SaC架构的灵魂，也是提供给模型的一组完成retrieve、dedupe、rerank这些精细操作的“专用手柄”。Perplexity并没有简单地把旧API封装起来，而是重构了搜索堆栈，让SDK能够真正、直接操作搜索系统的内部状态。

回到用户视角：原先搜索时展示的一行行网页链接，可能是按关键词匹配排列，也可能是按时效性或权威性排列。但只要黑盒不打开，结果的排序逻辑就是未知的。而在SaC架构下，模型能看到各种详细的后台数据，并根据具体任务需求来应用最有价值的搜索结果。

03 底层工程的博弈

如果说这三层架构是SaC的骨架，那么沙箱内部体现出的工程决策，则是决定这套架构能否在现实世界中稳定运行的灵魂。

在设计执行环境时，Perplexity没有盲目追求指标上的高性能，而是深入探讨了两个极具代表性的技术权衡：

一是语言的博弈。选择沙箱运行的语言时，团队面临两难：是用执行效率极高的Rust，还是类型严密的TypeScript？

出人意料的是，团队最终选择了Python——大语言模型的“母语”。理由是Python拥有近乎无敌的数据处理生态（比如NumPy和Pandas），而且大语言模型在预训练阶段对Python代码的理解和生成能力最强，能显著提高代码生成质量。

二是状态的博弈。第二个决策关乎智能体如何记忆中间状态的数据。当一个智能体执行以小时为单位的长程任务时，必然会产生海量的中间检索结果，这些数据该如何保存？

团队面前有两种截然不同的方案：

REPL模式（交互式解释器）：类似于Jupyter Notebook，变量始终保存在内存里，模型需要时可以随取随用；

文件系统序列化模式（Serde）：要求模型显式地将数据转换成JSON格式，写入沙箱的磁盘。

REPL模式看起来更方便，但在处理长路径任务时这是一个赤裸裸的陷阱。随着任务进行，内存里会充斥大量随手定义的临时变量，导致命名空间污染，模型在后续步骤中也会因此发生混乱。

因此，Perplexity最终选择了更繁琐的文件系统序列化——每一步处理完数据之后，都必须以一种“声明式”的严谨态度，明确把数据打包、贴标签并存入磁盘。这属于工程上的“强约束”，虽然让模型多写了几行代码，却能极大提升智能体在执行复杂任务时的逻辑清晰度和可追溯性。

04 性能与性价比的兼顾

Perplexity的研究没有停留在理论分析。他们不仅发布了全新的基准测试，还建立了一套名为“成本-性能边界（Cost-Performance Frontier）”的评估体系。这恰好与当下主流的AI测评理念一致——强调性价比而非单纯的性能领先。

WANDR基准是Perplexity专门设计用于模拟复杂、高宽度的专业调研任务的一套测试。

在此基准测试中，SaC的表现几乎达到了第二名Opus 4.7的2.5倍。也就是说，在面对需要跨越多个信息源、持续数小时的复杂任务时，传统的“对话式搜索”已经彻底失效，而SaC的代码驱动逻辑能够体现出统治级的效率。

与此同时，Perplexity重新定义了搜索的性价比。他们引用了一个经济学术语：帕累托边界——指的是在不损害其他目标的情况下，无法进一步优化某一目标。而SaC在低、中、高三种推理强度的配置下，竟然都奇迹般地位于最优边界之上。

在低推理强度下，SaC的价格比纯API检索更低，但表现已经优于部分竞争对手；在中推理强度下，对于1美元以下的单次任务成本，SaC架构已经实现对其他架构的全面超越。

客观地说，由于Perplexity展示的数据都来自其构建的评估体系，难免会让人产生“自卖自夸”的质疑。但更重要的是，这些出色的数据验证了AI发展规律的转变：搜索的效率，正在从增加模型参数转向优化架构编排。

05 未来的计算架构

Perplexity这篇技术博客的结尾堪称点睛之笔，极具思想深度。

Search as Code，不仅仅是Perplexity喊出的一句商业化口号，它反映出软件设计的一场宏大变革。

在计算机科学的历史长河中，留存至今的有两种截然不同的计算形式：

一种是确定性的指令，它运行在CPU上，逻辑严密，适合批处理、排序和并行化。

另一种是token空间的推理，这是大模型独有的能力，擅长处理不确定性、理解语义并制定策略。

SaC的真正意义就在于，它是这两种计算形式的完美结合。

模型意味着概率——它需要决定“需要什么证据”以及“如何解决矛盾”；而代码和沙箱则是确定的——负责处理海量且繁重的I/O操作和逻辑过滤。

Perplexity甚至提出了更前沿的构想：联合设计。未来模型可能不再是“学会”写代码，而是在训练阶段就能与SDK共同进化，直接理解低层级的搜索信号。

这篇技术博客，可以视为给所有智能体开发者的一张路线图。如果开发者还在为智能体设计搜索插件，那可能就是在重复造轮子。

Search as Code：搜索不应该是终点，而是一个可以被模型自由操纵、无限透明的过程。当“搜索即代码”成为智能体的标配，其上限将不再受限于“看到什么”，而取决于“如何寻找”。

或许，这场架构变革，就处在通往AGI的必经之路上。

来源：互联网