文 | 硅基星芒
2026 年，当大模型从对话框走向智能体时，人们对搜索的要求已经发生了质变。
最直观的转变是，国内外的两家搜索引擎巨头，如今在展示搜索结果的界面，最先显示的都是 AI 生成的回答，然后才是各种相关链接。
而更深层次的转变在于，以前，搜索出来的结果是给人类看的，人们面对一堆网页链接各取所需；如今，搜索这项功能是给大语言模型准备的，只需要返回一段精简的文本。
但这就是搜索的最终形态了吗？Perplexity 给出了否定的回答和一篇具有里程碑意义的技术博客，宣告搜索将进入第三个阶段：Search as Code ( SaC ) ，搜索即代码。
在 Perplexity 的测试中，SaC 在复杂任务上的表现不仅全方位吊打 OpenAI 和 Anthropic，更是在成本上实现了近乎不可能的 85% 压缩。
尽管数据显得有些不真实，但架构背后隐藏的深度思考却值得认同。
搜索的黄昏
搜索引擎这个词，自打 OpenAI 推出大语言模型 ChatGPT 以后，被提及的次数就变得越来越少。要理解 SaC，就得先想明白为什么现有的搜索架构已经不再适用。
就像前文所说，无论是国外的谷歌还是国内的百度，初衷都是为人类而设计的。人类接收信息的容量和处理信息的频率都有明确的上限，因此只需要最直观、固定的结果搜索页。这种 " 输入关键词→搜索引擎黑盒处理→返回前 N 个结果 " 的单体服务模式，不知不觉之间已经统治了互联网信息数十年。
在大语言模型出现以后，Perplexity 曾经引领了一波 " 回答引擎 " 的潮流，让模型整合并提炼多篇网页内容，试图通过优化信息密度让模型更好地理解、推理和生成。但本质上，模型依然只是在一个预定义的单向管道末端被动地接收信息。
然而，智能体时代突如其来的降临，让搜索功能的使用者从人类变成了大语言模型，原先 " 单体服务 " 的模式也变成了一种阻碍。
如今广义上的智能体已经远远不只是问个问题这么简单，它们需要实操电脑完成任务。在 Perplexity 内部的 Perplexity Computer 项目中，研究者发现，单个复杂调研任务仅仅在几分钟内就可能需要触发成百上千次检索操作。这种高频且非线性的需求直接迫使传统 " 单体服务 " 面对三个方面的挑战而濒临失效：
一是粗颗粒度的上下文（Coarse Context）：
大模型对上下文极其敏感，而传统的 " 单体服务 " 为了保证检索信息的召回率，往往会塞给模型海量的冗余信息。这种为了大海捞针连带着输送了几十吨海水的行为，将导致的直接结果就是上下文窗口迅速爆炸，进而转化为激增的推理成本和频繁出现的幻觉。
二是领域知识的浪费（Failure to leverage domain knowledge）：
前沿模型本就已经拥有深厚的 " 搜索经验 "，它知道查询一些知识性强的信息应该去哪些官方渠道而不是第三方信息源。但在固定的 API 检索模式下，模型原本具有的洞察力无法干预搜索底层的检索逻辑。
三是低效的对话轮次与上下文污染：
在传统的功能调用（Function Calling）模式下，智能体每进行一次检索、去重、筛选等操作，都要完成一次 " 模型推理→触发工具→接收结果 " 的循环。这不仅造成了延迟的累积，还让模型上下文充斥了大量中间态的垃圾信息。Perplexity 的数据显示，真正的有用信息往往会在这个过程中被淹没。
将搜索解构
Perplexity 提出的 Search as Code，听起来虽然有些令人难以理解，实际上核心思想非常直接：
让模型去编排搜索代码，而不是调用搜索接口。
在这个思想的基础上，Perplexity 提出了 " 搜索即原语（Search as Primitives）"。在计算机科学中，原语指的就是不能再进一步分解的基础构建块。SaC 要做的，就是把原本封装在黑盒中的搜索过程拆解成初始检索（retrieve）、并行查询扩展（fanout）、精细化过滤（filter）、去重（dedupe）、重排（rerank）等原子组件。
首先是模型层，通常会采用具备顶尖推理能力的模型担任 " 指挥官 "。它生成的不再是输入到文本框中的关键词，而是一段复杂的 Python 代码。
然后是计算沙箱，提供一个隔离、安全、确定的执行环境。只要给定相同的输入和代码，输出永远都是一致的，与大语言模型的概率性生成互补。沙箱负责执行循环、重试、数据聚合等一系列操作，完全不需要大语言模型的干预。
最后是原子化 SDK，这是 SaC 架构的灵魂，也是提供给模型的一组完成 retrieve、dedupe、rerank 这些精细操作的 " 专用手柄 "。Perplexity 并没有简单地把旧 API 封装起来，而是重构了搜索堆栈，让 SDK 能够真正、直接操作搜索系统的内部状态。
回到用户的视角，原先进行搜索时展示出来的一行行网页链接，可能是按照关键词匹配排列，可能是按照时效性排列，也可能是按照权威性排列。但只要黑盒不打开，结果的排序逻辑就是未知的。而在 SaC 架构下，模型能看到各种详细的后台数据，并根据具体的任务需求来应用最有价值的搜索结果。
底层工程的博弈
如果说这三层架构是 SaC 的骨架，那么在沙箱内部体现出来的工程决策，则是决定这套架构能否在现实世界中稳定运行的灵魂。
一是语言的博弈。
在选择沙箱运行的语言时，团队面临着一个两难的选择：是用执行效率极高的 Rust，还是类型严密的 TypeScript？
出人意料的是，团队最终选择的是 Python 这款大语言模型的 " 母语 "。理由是 Python 拥有近乎无敌的数据处理生态，例如人们熟知的 NumPy 和 Pandas。与此同时，大语言模型在预训练阶段，对 Python 代码的理解和生成能力最强，这就能显著提高代码生成的质量。
二是状态的博弈。
第二个决策关乎智能体如何记忆中间状态的数据。当一个智能体执行以小时为单位的长程任务时，必然会产生海量的中间检索结果，这些数据又该如何保存？
团队面前有两种截然不同的解决方案：
REPL 模式（交互式解释器）：类似于 Jupyter Notebook，变量始终保存在内存里，模型需要的时候可以随取随用；
文件系统序列化模式（Serde）：要求模型显式地将数据转换成 JSON 格式，写入沙箱的磁盘。
REPL 模式看起来更方便一些，但在处理长路径任务时就是一个赤裸裸的陷阱。随着任务进行，内存里会充斥着大量随手定义的临时变量，并导致程序员最难以忍受的命名空间污染，模型在后续的步骤中也会因此发生混乱。
因此，Perplexity 最终选择了繁琐一些的文件系统序列化，在每一步处理完数据之后，都必须以一种 " 声明式 " 的严谨态度，明确把数据打包、贴标签并存入磁盘。毫无疑问，这属于工程上的 " 强约束 "，虽然让模型多写了几行代码，却能极大程度上提升智能体在执行复杂任务时的逻辑清晰度和可追溯性。
性能与性价比的兼顾
Perplexity 的研究没有仅仅停留于理论分析，他们不仅发布了全新的基准测试，还建立了一套名为 " 成本 - 性能边界（Cost-Performance Frontier）" 的评估体系。这恰好与当下主流的 AI 测评体系一致，强调性价比而非单纯的性能领先。
在此基准测试中，SaC 的表现几乎达到了第二名 Opus 4.7 的 2.5 倍。也就是说，在面对这种需要跨越多个信息源、持续数小时的复杂任务时，传统的 " 对话式搜索 " 已经彻底失效，而 SaC 的代码驱动逻辑能够体现出统治级的效率。
与此同时，Perplexity 重新定义了搜索的性价比。
这里他们引用了一个经济学术语：帕累托边界，指的是在不损害其他目标的情况下，无法进一步优化某一目标。而 SaC 在低、中、高这三种推理强度的配置下，竟然奇迹般地都位于最优边界之上。
客观来说，由于 Perplexity 展示的数据都来自于其构建的评估体系，因此难免受到 " 自卖自夸 " 的质疑。然而更重要的是，这些出色的数据验证了 AI 发展规律的转变：搜索的效率，正在从增加模型参数转向优化架构编排。
未来的计算架构
Perplexity 这篇技术博客的结尾可谓是点睛之笔，极具思想深度。
Search as Code，不仅仅是 Perplexity 喊出的一句商业化口号，还反映出软件设计的一场宏大变革。
在计算机科学的历史长河中，留存至今的有两种截然不同的计算形式：
一种是确定性的指令，它运行在 CPU 上，逻辑严密，适合批处理、排序和并行化。
另一种是token 空间的推理，这是大模型独有的能力，擅长处理不确定性、理解语义并制定策略。
SaC 的真正意义就在于，它是这两种计算形式的完美结合。
模型意味着概率，需要决定 " 需要什么证据 " 以及 " 如何解决矛盾 "；而代码和沙箱则是确定的，负责处理海量且繁重的 I/O 操作和逻辑过滤。
Perplexity 甚至提出了更前沿的构想，也就是联合设计。未来模型可能不再是 " 学会 " 写代码，而是在训练阶段就能与 SDK 共同进化，直接理解低层级的搜索信号。
这篇技术博客，可以理解为给所有智能体开发者的一张路线图。如果开发者还在为智能体设计搜索插件，那就是在重复造轮子。
Search as Code，搜索不应该是终点，而是一个可以被模型自由操纵、无限透明的过程。当 " 搜索即代码 " 成为智能体的标配，其上限将不再受限于 " 看到什么 "，而取决于 " 如何寻找 "。
或许，这场架构变革，就处在通往 AGI 的必经之路上。
