Perplexity 提出「搜索即代码」：让 AI 用代码编排搜索

△△微信关注"Python猫"，回复"1"领取电子书

花下猫语：

Perplexity 在 AI 搜索领域一直走在技术前沿。这篇文章正式提出了"搜索即代码"（Search as Code，SaC）架构，核心思想很直接但也很大胆：不再让 AI 模型被动消费搜索结果，而是让它用代码直接编排搜索的全过程。以下几个要点值得关注：

1. 1. 传统搜索架构的僵化已严重制约智能体工作流——粗糙上下文、无法利用模型自身的领域知识、以及串行控制流导致的上下文污染，是三种典型的失败模式。
2. 2. SaC 的三层架构——模型（控制面）→ 计算沙箱（确定性执行）→ 智能体搜索 SDK（原子化搜索原语）——让模型能够用 Python 代码动态组装任务专属的搜索管道，单次推理即可编排数千次检索。
3. 3. 在 CVE 安全公告案例中，SaC 以 100% 准确率完成任务，同时 token 消耗暴降 85%，足以说明按需构建搜索策略的效率优势。
4. 4. 基准测试碾压式领先：五项基准中四项最优，新推出的 WANDR"广域研究"基准上以 2.5 倍优势领先第二名。

这篇文章适合关注 AI 搜索、智能体架构和 LLM 应用的工程师和技术决策者阅读。它不仅是 Perplexity 的技术路线宣言，也为"AI 系统如何获取和利用信息"这个问题提供了一个值得认真对待的新范式。

引言

搜索是 AI 系统的核心原语。前沿模型的能力每个月都在增长，但它们仍然需要从外部世界获取新鲜、准确且经过精心整理的知识。搜索是 AI 系统获取这些知识的主要途径，因此对于任何需要得出结论、采取行动并完成现实世界工作的产品而言，搜索都是一个基础组件。

我们相信，在智能体时代，传统的搜索管道正变得越来越过时。传统搜索回答查询，但今天的智能体完成的任务形态千变万化。这些任务要求智能体在其运行框架内直接定义任务专属的检索策略。在 Perplexity Computer 中，我们看到单个任务在几分钟内就调用了数百甚至数千次检索操作——这种工作流对人类来说无法想象，但对智能体而言却再自然不过。

在这个新世界中，搜索本身必须变得"智能体化"（agentic），其构建块应以 SDK 的形式直接被智能体框架访问。我们在此正式推出 搜索即代码（Search as Code，简称 SaC），作为 Perplexity 的新一代参考搜索架构。

Perplexity 的搜索技术栈每秒处理数千个查询，覆盖我们的应用和 API 平台。2025 年 9 月，我们发布了搜索系统的首篇架构概述。在这些系统上的持续创新支撑了 Search API、Agent API 和 Computer 等新产品的发布，而自我改进循环则不断优化搜索技术栈，日复一日地为用户提供更好的服务。

传统上，AI 系统将搜索视为一个不可分割的整体：AI 模型发起查询，搜索引擎运行预定义管道，模型将结果作为上下文消费。在 AI 早期用户时代，这种方式大体上运作良好。鉴于当时的请求相对简单，没有人会在意搜索管道到底是怎么设计的，或者管道的架构是否最适合手头的任务。默认配置被认为是够用的——默认接口（函数调用和 MCP）也同样是够用的。

然而，这种模式每过一个月都变得更加过时。用户对 AI 的需求远不止单次分析。他们期望智能体能够端到端地完成任务，持续数小时甚至数天。这些任务可能复杂、开放、信息需求高度可变，而单体架构在这些需求的重压下正在走向崩溃。

核心瓶颈归根结底是控制权的问题。前沿模型在固定上下文中推理已经相当出色，但最强大的 AI 系统需要能够掌控上下文是如何被检索、处理、聚合和呈现给模型的。

传统搜索系统的设计从未考虑过这种程度的可控性。毕竟，即便提供了对搜索管道内部的细粒度控制，人类用户也不具备使用它的能力。早期的 AI 模型只能通过函数调用和 MCP 的线性轨迹来控制搜索。但今天的前沿模型，借助具备代码能力的智能体框架，可以通过计算机代码对任何可编程的计算原语施加细粒度控制。我们的任务变成了——提供正确的原语。

为了满足这一需求，我们在全线产品中引入了新的搜索架构：搜索即代码（Search as Code，SaC）。这个新架构使模型能够深入搜索技术栈的内部，而不仅仅是消费其最终输出。核心思想很直接：我们将搜索技术栈的组件作为 SDK 中的原语暴露出来。对于任何需要搜索的请求，模型按需组装这些原语，构建出针对该特定请求量身定制的检索管道。

管道的组装通过在安全沙箱中生成和执行代码来完成。与其他以代码生成驱动的搜索方法不同，我们并非简单地将传统搜索 API 放进 Shell 或语言运行时中。相反，我们精心设计了一个智能体搜索 SDK（Agentic Search SDK），以尽可能原子化的粒度暴露搜索的各个构建块。

借助这些构建块，SaC 让模型直接控制搜索的每一个步骤：检索、排序、过滤、扇出、渲染等等。它还为模型提供了对中间状态（如候选列表和排序信号）的高效访问。控制权和可观测性这两重杠杆结合起来，使智能体能够设计出跨越数千次检索操作的自定义搜索管道，即时优化这些管道，并只将最有用的信息作为模型上下文消费。

本文介绍 SaC 的动机、设计和实现，以及在现有基准和新基准上的实证结果。SaC 在智能体搜索的绝对性能和性价比两方面都达到了新高度，我们很高兴与用户及更广泛的 AI 社区分享这一成果。

传统搜索的僵化

世界上最早的搜索引擎是为人类用户构建的。这些用户期望一种可预测的体验——通常是固定数量的、按相关性排序的文档。用户不想事无巨细地管理搜索过程，他们只想输入查询、找到有用的结果。

因此，面向人类的搜索引擎逐渐收敛于一种共同的单体架构，旨在生成对用户友好的搜索结果页（SERP），其中包含输入查询的前 N 条命中结果。这种模式推动了消费级搜索几十年的进步。它快速、熟悉，对于人类浏览来说非常高效。

然后，大语言模型（LLM）出现了，AI 系统也开始成为搜索的消费者。Perplexity 在 2022 年推出答案引擎，引领了这一转变。此后，我们的搜索工程工作一直聚焦于如何为 AI 模型优化搜索结果的价值。为了构建世界上最准确、最可靠的 AI，我们必须设计一个专注于让每个 token 尽可能信息密集的搜索系统。由此在子文档检索、上下文效率、语义理解等关键领域产生的创新，显著提升了 AI 系统检索和处理信息的能力。

然而，即使是为 AI 优化过的系统，也基本继承了与传统搜索引擎相同的"合约"：接受查询，运行预定义的搜索管道，返回完全处理好的结果集。对于简单的请求，这种方式没有问题。但对于更复杂的请求，这就变成了一个越来越严重的瓶颈，损害了性能、延迟和成本。

僵化导致的失败模式

传统搜索管道围绕单点控制来设计：即查询参数。搜索引擎按照其预定义逻辑掌控管道的其余部分，模型必须去适应它。在模型看来，查询参数下游的任何东西都是僵化的——实际计算的形态超出了模型的控制范围。

当消费者是扫描链接的人类时，这是一个合理的边界。但当消费者是试图在闭环中解决知识密集型任务的 AI 模型时，这就是一个糟糕的边界。根据我们的经验，这种僵化性会产生三种反复出现的失败模式：

1. 1. 粗糙的上下文。 AI 模型对上下文的质量和紧凑度高度敏感。质量和紧凑度都在很大程度上依赖查询的具体情况，而单体搜索管道并不针对所有查询做最优设计。例如，如果模型需要一个高度精准的具体信息，但只能访问一个优先保召回（recall）的端到端搜索端点，使用该端点会将大量无关信息塞进模型上下文。反过来，如果模型需要多个不同搜索策略的信息，它可能被迫对所有信息逐一调用相同的次优管道，导致成本膨胀和上下文噪音。
2. 2. 无法利用领域知识。 在很多情况下，模型可能拥有来自训练数据、Agent Skill、记忆或 LLM 轨迹中早期 token 的领域知识，这些知识本该用来指导搜索策略。然而，僵化的搜索接口让模型无法利用这些知识。例如，模型可能意识到对于某个特定请求，应该以特定方式混合词法和语义信号、优先考虑某些信息源、或按特定键值聚合结果。除非这些洞察恰好能通过查询参数来实现，否则模型实际上无法执行。
3. 3. 低效的控制流和上下文污染。 许多搜索工作流本质上不适合串行执行。它们可能需要对查询变体进行扇出、并行获取、去重以及其他需要非线性和异步控制流的操作。强制这些步骤通过反复的模型回合来执行，会增加延迟并使工作流难以优化。同时，这也会用噪音中间状态污染模型上下文，这些状态对模型的推理并无用处，反而导致性能变差和更频繁的上下文压缩（compaction）。

在函数调用和 MCP 时代的 AI 中，这些挑战几乎无解。 当每个搜索操作都需要一个独立的 LLM 推理往返时，开发者自然倾向于在每个往返中完成尽可能多的事情。这意味着端到端的搜索管道——返回完全处理好的结果集供模型直接消费。

因此，如今大多数面向 AI 的搜索系统仍然在这个单体合约下运行。然而，随着模型智能和用户需求的持续增长，这个合约的缺陷变得越来越突出。当今最先进的 AI 系统，建立在代码优先的智能体框架之上，可以组合出每分钟执行数千个操作的任务特定工作流。搜索系统尚未充分发挥这一潜力。

我们长期以来一直认为，AI 原生搜索的正确边界应该在技术栈的更底层。模型不应仅仅是调用搜索引擎，它们应该能够根据具体任务的需求来编排搜索技术栈的各个部分。这需要一种根本不同的架构。

设计可编程搜索架构

下一代搜索架构将围绕一个核心原则展开：搜索应该由 AI 智能体原生可编程。 一个智能体不能被限制在一组预先设定的搜索管道中。相反，智能体必须能够使用设计在不同抽象层次上的可组合构建块，来构建具体任务所需的管道。

我们的新搜索即代码（SaC）架构体现了这一原则。在 SaC 中，没有一次检索操作是通过函数调用或 MCP 接口派发的。 所有操作都通过模型生成的 Python 代码来编排。对于最简单的搜索需求，这段代码可能只包含对高级搜索端点的少量请求。但对于复杂的任务，代码可以根据需要变得任意精细——涉及条件执行、异步、并行，以及对各种低级原语的调用。

SaC 包含三个紧密耦合的层次：

1. 1. 模型作为控制面（control plane）。它们对用户（或父智能体）的指令进行推理，将指令分解为任务，决定每个任务需要哪些检索和处理管道，并生成代码来实现这些管道。
2. 2. 计算沙箱通过安全的代码执行运行时提供确定性计算。它们为模型提供了实现控制流、批处理、重试、过滤、连接、聚合和其他确定性操作的画布。
3. 3. 我们的智能体搜索 SDK 将 Perplexity 的搜索技术栈暴露为可组合的原语。它提供从低级检索操作到高级语义解析的构建块。该 SDK 嵌入在沙箱的执行运行时中，允许模型在单次推理回合中编排多达数千次操作。下面我们讨论各层的设计决策。

智能体搜索 SDK

智能体搜索 SDK 定义了可编程搜索的构建块。重要的是，我们的 SDK 不是一个被包装成库的已有搜索 API。 在过去几个月里，我们的工程团队将搜索技术栈重新架构为模块化、可组合的原语。我们构建智能体搜索 SDK 来提供对这些原语的直接访问，从而为模型编排任务特定的检索管道提供了强大得多的画布。

高级的、端到端的搜索管道在 SDK 中仍然可用，但它们不再是唯一的选择。相反，它们作为常见搜索模式的一种"快捷方式"存在。模型可以根据任务需求自由使用或绕过它们。

运行时选择： 我们考虑了 Python、Rust、TypeScript 和 Bash 作为 SDK 的运行时语言。我们推测 Python 将是最自然的选择，因为它极其普及且拥有丰富的数据处理库生态。内部测试证实了这一点，当前发布的 SDK 版本基于 Python。我们预计会定期重新评估运行时的选择，以确保始终提供最佳的智能体体验。

通过自动研究（autoresearch）持续改进： 我们还通过一个迭代式的自动研究循环来优化 SDK 对前沿 LLM 的可消费性。这个循环已连续运行数周，提出并验证针对延迟、代码生成质量和整体任务性能等指标的 SDK 改进方案。自动研究循环已经在 SDK 的结构和美学层面做出了大量更改，在所有维度上都取得了显著收益。我们计划随着新前沿模型和搜索组件的出现，通过自动研究进一步优化 SDK。

沙箱

沙箱为定义和运行 SaC 管道提供了安全环境。它们执行模型生成的代码，提供对智能体搜索 SDK 的访问，以促进与各个搜索原语的交互。

我们在优化和加固沙箱方面投入了大量精力，其整体系统设计值得一篇单独的文章。这里我们聚焦于与 SaC 最相关的设计考量：管理中间状态。

SaC 使智能体能够在单次推理回合中编排复杂的管道。然而，某些中间状态需要跨回合传递。例如，一个模型可能想在第 1 回合获取一些文档，在第 2 回合检查其中一部分来决定下一步做什么，然后从第 3 回合开始构建下游搜索管道来进一步调查这些文档。如前所述，通过 token 空间传递中间状态不是一种有效的策略。

我们考虑了两种跨回合管理中间状态的方法：

持久化文件系统 + 显式序列化/反序列化（serde）： 沙箱可以暴露持久化文件系统供模型跨回合使用。希望保存中间状态的模型可以在该回合生成的代码中包含序列化步骤，并在后续回合中包含反序列化步骤（供模型自己检查或下游使用）。文件系统方法允许模型直接且显式地控制中间状态如何跨回合传递。它还通过强制显式识别和持久化模型使用的信息来确保可追溯性。一个缺点是生成 serde 代码会带来延迟和上下文开销，不过良好设计的工具函数可以缓解这种开销。

REPL 模式： 或者，沙箱可以在 REPL 风格的环境中跨回合保持执行运行时。这允许模型在内存中维护中间状态，完全不需要序列化——因为之前回合定义或修改的变量可以在后续回合中直接按名称引用。REPL 方法在 token 效率上更优，因为它避免了生成 serde 代码。然而，缺乏显式序列化步骤可能会损害下游性能，原因对于任何使用过 100 个 cell 的 Jupyter Notebook 的人来说都不陌生：随着变量命名空间变得混乱，越来越难以追踪跨回合究竟持有哪些状态以及为什么持有。

我们测试了两种方法，发现在常规使用中它们的性能相近，但在特别长的轨迹上，基于文件系统的 serde 提供了更好的可靠性。 因此我们采用基于文件系统的 serde 作为解决方案。我们推测，要求模型以声明式而非隐式的方式传递状态，有助于它们更有效地管理这些状态。这只是一个初步发现，我们将在两种方法上继续迭代。

模型

驱动智能体框架的模型充当 SaC 的控制面：动态地从智能体搜索 SDK 的构建块中组装搜索管道以满足每个任务的需求，然后将这些管道以代码形式派发给沙箱执行。

Perplexity 在智能体框架中使用了多种模型，我们发现最新的前沿模型在通用代码生成方面普遍相当有效。主要挑战在于引导针对智能体搜索 SDK 的高效代码生成。也就是说，我们如何才能让模型将 SDK 的构建块有效地编织成任务优化的管道？

与语言标准库不同，一个自定义构建的 SDK 不太可能在预训练数据中得到体现。 即使有了自动研究带来的 SDK 可消费性改进，许多模型仍然被训练为通过函数调用和直接 MCP 调用来与搜索系统交互。这些模型不太可能仅凭源代码和自动生成的文档就熟练运用我们的 SDK。

为了解决这一挑战，我们开发了高度调优的 Agent Skill 来教会模型有效使用我们的 SDK。初始版本按照 Perplexity 的 Skill 设计原则开发，然后通过一个专门的自动研究循环进行优化，聚焦于与 SDK 优化相同的指标。我们还限制了 Skill 的大小以防止上下文膨胀，最终版本的根级 SKILL.md 文件不超过 2000 个 token。

优化后的 Skill 远不止列出 SDK 的可用构建块（这些信息通过运行时反射一样可以轻松获取）。大部分 token 用于提供简洁、可泛化的指导和 few-shot 示例，教模型将这些块组合成复杂模式。借助这些 Skill，我们观察到模型能够有效利用 SDK 来编排扩展到数千个离散操作的搜索管道。

代码作为编排器和能力补位器

通过这些层的组合，SaC 改变了模型与搜索技术栈之间的关系。在固定管道搜索系统中，模型位于搜索之上，通过狭窄的串行调用接口与之交互。而在 SaC 中，模型成为编排搜索过程本身的主动参与者。 搜索技术栈的所有元素都变得对模型直接可编程，沙箱和智能体搜索 SDK 为这些元素提供了必要的接口。

但那些原生不存在的功能怎么办？代码是编排既有能力的强大媒介。然而代码的能力不止于编排——它还可以充当搜索技术栈或 SDK 中不存在的能力的"补位器"。智能体受益于简洁性（parsimony），让 SDK 为每个可能的操作都提供专属函数是低效的。相反，SDK 提供最基础的原语，模型可以按需用代码动态构建任何额外组件。

举个例子：假设需要匹配一个复杂的正则表达式，它无法通过搜索系统自身的查询语法高效实现。没有编码能力的话，模型将被迫生成一个近似的最佳查询，然后对充满噪音的结果集进行 token 空间过滤。有了 SaC，模型可以生成一个程序，并行发起多个 SDK 调用来收集一个覆盖所需正则表达式预期结果的超集。通过 SDK 去重后，模型可以编写额外的代码来将其确定性地缩小到精确匹配该正则表达式的结果。这样一来，智能体可以在不把过于小众的子程序塞进 SDK 的情况下，实现自定义的搜索能力。

案例研究：CVE 厂商安全公告

我们展示一个来自测试套件中真实任务的案例研究。该任务要求智能体识别并描述 2023–2025 年间 200 多个高危 CVE（通用漏洞披露）。每条记录必须引用受影响厂商自己的安全公告，指明产品名称和修复版本，并证明该修复版本与该特定 CVE 绑定。

SaC 的回答在准确率上得分为 100%，总的 token 使用量相较非 SaC 基线下降了 85.1%（从 288.7K token 降至 42.9K token）。被测试的非 Perplexity 系统（在第 4 节中详细讨论）得分均低于 25%。

我们展示轨迹中的三段典型代码块，来说明 SaC 的可编程性如何让模型实现高效的策略。

templates = [
    ("Mozilla",
     'site:mozilla.org/en-US/security/advisories/mfsa{year} '
     '"CVE-{year}-" "Fixed in" "Impact high"'),
    ("Jenkins",
     'site:jenkins.io/security/advisory/{year} '
     '"CVE-{year}" "Severity" "High" "Fix"'),
    ("Chrome",
     'site:chromereleases.googleblog.com/{year} '
     '"High CVE-{year}" "Stable channel has been updated"'),
    ("Android",
     'source.android.com/docs/security/bulletin/{year}-{month:02d}-01 '
     '"High" "CVE-{year}"'),
    ...
]

queries = [
    {"vendor": vendor, "query": pattern.format(year=year, month=month)}
    for year in [2023, 2024, 2025]
    for vendor, pattern in templates
    for month in ([1] if "{month" not in pattern else range(1, 13))
]

seed_hits = sdk.search.web_many(queries, limit_per_query=8, concurrency=12)

pages = [
    {"vendor": q["vendor"], "url": h.url, "text": join_result_fields(h)}
    for q, hits in zip(queries, seed_hits)
    for h in hits
    if official_vendor_advisory(h.url, q["vendor"])
]

第一个代码块是纯粹的编排逻辑。生成的程序首先将来源分类规则直接编码到查询计划中：只有厂商自家的公告格式才是相关的。非厂商来源——包括 NVD、MITRE、CVE Details、新闻报道、CERT 页面和第三方数据库——在结构上就被排除在外。精确短语约束也将搜索推向那些索引文本中已经包含下游需要的确切 CVE 详细信息的页面。

coverage = summarize(pages, by=["vendor", "year", "url_kind"])

prompt = """ Goal: 230+ high or critical CVEs from official vendor advisories.
Avoid aggregators, CERTs, news, NVD, MITRE, and CVE databases.
Current coverage: {coverage}
Suggest more site-scoped exact-phrase queries for sparse vendor-years.
Prefer per-advisory pages over archive or month-index pages.
Return JSON lines with vendor and query.
""".format(coverage=coverage)

raw = query_llm(prompt)

expanded_queries = [
    row for row in parse_jsonl(raw)
    if official_scope(row["query"]) and mentions_cve_year(row["query"])
]

expanded_hits = sdk.search.web_many(
    unique(expanded_queries),
    limit_per_query=8,
    concurrency=12,
)

第二个代码块使用 LLM 作为中间的规划子程序。代码汇总了哪些厂商-年份组合产生了足够的候选页面，请求有针对性的优化建议，并在执行前验证每个提议的查询。这保留了轨迹中有用的模式——比如站点范围内的精确短语探测和自适应回填——而不需要在 SDK 中硬编码一个专门的 CVE 公告爬虫。

all_hits = dedupe_by_url(flatten(seed_hits) + flatten(expanded_hits))

items = [
    {"url": h.url, "vendor_hint": infer_vendor(h.url),
     "text": join_result_fields(h)}
    for h in all_hits
    if official_vendor_advisory(h.url, infer_vendor(h.url))
]

verified = sdk.llm.extract_many(
    items,
    instruction=(
        "Keep only vendor advisories where the page ties a high or critical "
        "CVE to a specific fixed version, build, patch, or security level."
    ),
    schema={
        "matches": bool,
        "cve": str,
        "vendor": str,
        "product": str,
        "fix_version": str,
        "severity": str,
        "source_url": str,
        "evidence": str,
        "version_bound_to_cve": bool,
        "confidence": float,
    },
)

records = [
    to_cve_record(x) for x in verified
    if x.matches and x.version_bound_to_cve
    if high_or_critical(x.severity) and x.confidence > 0.75
]
records = dedupe_by(records, key="cve")

最后一个代码块是一个结果验证器，其逻辑完全由智能体通过代码生成来定义。搜索子程序虽然能找到看起来合理的公告页面，但任务要求更严格的关系：该公告必须将一条 CVE 绑定到一个受影响的产品和修复版本，且这些信息出自厂商撰写的文本。schema 将这种关系显式化，下游代码可以据此按 CVE 去重、拒绝聚合器 URL、丢弃弱版本证据，并持续回填直到达到记录数量的下限要求。

评测结果

我们在一个全面的基准测试套件上评估 SaC 的有效性，聚焦于绝对性能和性价比两个维度。

基准和系统

我们的基准套件共包含五个基准，旨在对搜索依赖型 AI 工作流在不同领域、任务格式和复杂度级别上进行压力测试。我们使用了四个现有基准：DeepSearchQA (DSQA)、BrowseComp、Humanity's Last Exam (HLE) 和 WideSearch。对于前三个基准（DSQA、BrowseComp 和 HLE），我们将准确率（accuracy）作为核心指标。对于 WideSearch，我们按行报告 F1 分数。

我们还使用了新开发的 WANDR 基准，它专注于需要精细编排搜索、计算和模型推理的高难度"广域研究"任务。WANDR 的灵感来自 Perplexity Computer 为用户处理的知识密集型专业任务。它在 WideSearch 和类似基准的基础上进行了迭代，但强调更复杂的任务和任务结构。我们将在未来几周发布 WANDR 基准。

我们评测了五个基于智能体的系统。我们使用单次运行分数而非"Best-of-N"分数，以便分离出底层架构的性能，而不是并行化带来的收益。各系统配置如下：

Perplexity (SaC)： 我们在 Perplexity 生产环境的 Agent API 上评测 SaC 架构。底层模型为 GPT 5.5（高推理模式）。

OpenAI： 我们评测启用了搜索（web_search）和 Python 运行时（code_interpreter）的 OpenAI Responses API。底层模型为 GPT 5.5（高推理模式）。

Anthropic： 我们评测 Anthropic Managed Agents，使用 20260401 agent toolset 并启用自动允许的命令。底层模型为 Opus 4.7（高推理模式）。

Exa： 我们通过生产 API 评测 Exa Agent，effort 设为 high。

Parallel： 我们通过生产 API 评测 Parallel Tasks，processor 设为 ultra4x。

对比性能

表 1 报告了各系统在各项基准上的得分。SaC 在五项基准中的四项上优于所有其他系统。 在剩余的一项基准（HLE）上，SaC 与 OpenAI Responses 基本并列第一。引言中的图 2 以图形形式展示了这些得分。

尽管 SaC 在整个基准套件上都达到了最先进的性能，但它在 WANDR 上的优势尤为显著。图 5 显示 Perplexity 的 SaC 实现以 2.5 倍的差距领先于次优系统。 尽管优势巨大，WANDR 仍未达到饱和，即使对 SaC 来说也颇具挑战。我们认为，WANDR 任务所要求的那种复杂、高度"水平化"的搜索工作流，还需要搜索研究和工程方面的更多进展才能实现持续的高性能。

最后，我们测量了 SaC 相对于使用相同 Perplexity 搜索基础设施的传统搜索管道的提升幅度。图 6 报告了 SaC 和非 SaC 架构在各基准上的分数差异。全面来看，SaC 在性能上提供了显著提升，绝对提升最大的是 DSQA（+19.77 pp，提升 29%），相对提升最大的是 WANDR（+12.00 pp，提升 45%）。

性价比前沿

在实践中，用户真正关心的是性能与成本的比值。因此，我们在 DSQA 和 WideSearch 上评测了性价比。我们测量了 SaC 在低、中、高三种模型推理水平下的成本和性能，并与其他系统一起对比。图 7 和图 8 将基准得分与每任务价格进行对比，x 轴已反转，越靠右的点越便宜，越靠上的点性能越好。

在 DSQA 上，三种 SaC 设置均位于右上方的性价比前沿上。低推理设置比所有其他系统更便宜，同时性能优于其中两个。中推理设置在每任务不到 1 美元的成本下，性能超过所有非 SaC 系统。高推理设置以有竞争力的成本实现了顶级性能。

WideSearch 展示出形状相似的性价比前沿。与 DSQA 一样，低推理设置以低于所有非 SaC 系统的成本实现了有竞争力的性能，而中和高推理设置在任务性能上均优于非 SaC 系统。

迈向新的计算架构

搜索即代码反映了软件设计中一个更广泛的变革。几十年来，软件系统围绕由传统运行时在 CPU 上执行的确定性指令来组织。前沿模型引入了一种新的计算形式：既能够遵循指令、又能够生成指令的 token 空间推理。最强大的计算系统将结合这两种计算形式，而不是在二者之间做选择。

搜索是这种混合架构的天然验证场。模型非常适合决定需要哪些证据以及如何消除不确定性。确定性运行时非常适合批处理、并行、过滤、排序和聚合。搜索基础设施充当通用的 I/O 层，为运行时提供对世界信息的有用操作句柄，能够支撑每分钟数千次操作。当这些部分整合在一起时，所产生的系统在完成现实世界任务方面将变得更加强大和高效。

这个架构的每一部分对于解锁这些能力都是不可或缺的。 没有智能模型，系统就无法对搜索策略进行推理。没有沙箱，模型将被迫进入串行 I/O 和低效的 token 空间处理。没有原子化的搜索技术栈，模型就没有任何东西可以编排。SaC 之所以奏效，正是因为推理、确定性计算和 I/O 被联合设计，以放大每一层的优势。

这种协同设计还可以通过开发持续改进循环来进一步深化。例如，智能体搜索 SDK 和 SaC Agent Skill 可以在一个共同的自动研究循环中联合优化。更激进地看，可以训练模型来利用以 SDK 形式暴露的底层搜索原语。甚至还可以尝试在模型训练过程中与 SDK 设计进行协同演进。我们期待在未来工作中追求更激进的协同设计策略。

我们构建 SaC，是为了让模型能够控制搜索过程，而不仅仅是消费搜索结果。我们的结果证明了这种控制的力量：SaC 在知识密集型智能体基准上同时刷新了绝对性能和性价比两项纪录。 我们很高兴从今天起通过 Perplexity Computer 和 Agent API 将 SaC 的能力带给用户。我们将持续打磨 SaC 架构的每一层，确保我们的用户（以及服务他们的智能体）拥有最强大、最高效的搜索能力。