内容
搜索是人工智能系统的核心原语。前沿模型每个月都在变得更强大，但它们仍然需要从更广阔的世界中获取新鲜、准确且经过精心筛选的知识。搜索是人工智能系统接入这些知识的主要方式，因此也是任何需要得出结论、采取行动并执行现实世界工作的产品的基础组件。
我们认为，在智能体时代，传统搜索流水线正变得日益过时。传统搜索回答查询，而当今的智能体完成的任务形态却可能千变万化。这些任务要求智能体在其运行环境中直接定义面向任务的检索策略。在 Perplexity Computer 中，我们已经看到，单个任务会在几分钟内触发数百甚至数千次检索操作：这对人类而言几乎不可能，但对智能体来说却完全自然。
在这样的世界里，搜索本身也必须变得具备智能体特征，其构成模块应当能够以 SDK 的形式直接在智能体运行环境中访问。我们推出 Search as Code（SaC，代码化搜索），作为 Perplexity 的新一代参考搜索架构。
引言
Perplexity 的搜索栈为我们的应用和 API 平台每秒处理数千个查询。2025 年 9 月，我们发布了首篇关于搜索系统的架构概览。这些系统内部持续不断的创新，支持了Search API、Agent API 和 Computer 等新产品的发布，而自我改进的闭环也在持续优化搜索栈，使其每天都能更好地服务用户。
传统上，人工智能系统将搜索视为一个整体：AI 模型发出查询，搜索引擎运行其预定义流水线，然后模型将结果作为上下文来消费。就大多数早期 AI 用户的需求而言，这种方式基本够用。鉴于他们请求的相对简单性，没有必要过分关心搜索流水线的具体设计，也无需在意该流水线的架构是否最适合当前任务。默认配置被认为已经足够好，默认接口（函数调用和 MCP）也同样如此。
图 1 | 传统搜索架构向模型暴露的是一个固定的单一系统，模型以串行方式调用；而 Search as Code 则暴露出原子化的搜索原语，由智能体通过生成的代码进行组合。
然而，如今这种方式正随着每个月的过去而显得更加过时。用户对 AI 的期待早已不止于一次性分析。他们希望智能体能够在数小时甚至数天内端到端完成任务。这些任务可能复杂、开放、且在信息需求上高度多变，而单体式架构正承受着这些需求带来的巨大压力。
归根结底，关键瓶颈在于控制。前沿模型已经非常擅长在固定上下文上进行推理。然而，最强大的 AI 系统还需要能够调控上下文的检索、处理、聚合以及呈现方式。
传统搜索系统并不是为这种可控性而设计的。毕竟，即便把更细粒度的控制暴露给人类用户，也不现实指望他们去精确操控搜索流水线的内部细节。早期 AI 模型只能通过函数调用和 MCP 的线性路径来控制搜索。但如今由具备代码能力的智能体运行环境驱动的前沿模型，可以通过计算机代码，对任何可想象的计算原语施加细粒度控制。我们的任务就是提供合适的原语。
为满足这一需求，我们在全线产品中引入一种新的搜索架构：Search as Code（SaC）。这种新架构使模型能够直接“进入”搜索栈内部，而不仅仅是消费其最终输出。核心思想非常直接：我们将搜索栈的各个组件以 SDK 中的原语形式暴露出来。对于任何需要搜索的请求，模型都可以按需将这些原语组装成一条针对该请求量身定制的检索流水线。
这条流水线的组装通过安全沙箱中的代码生成与执行来完成。与其他由代码生成驱动的搜索方案不同，我们并不是把一个传统搜索 API 简单塞进 shell 或语言运行时里。相反，我们精心构建了一个智能体式搜索 SDK，在尽可能原子化的层面上暴露搜索的各个独立构件。
图 2 | Search as Code（SaC）在多样化基准测试上推动了智能体搜索性能的前沿。
借助这些构件，SaC 让模型能够直接控制搜索中的每一个步骤：检索、排序、过滤、分流、渲染等等。它还让模型能高效访问候选列表、排序信号等中间状态。控制性与可读性这两个杠杆结合起来，使智能体能够设计跨越数千次检索操作的定制搜索流水线，在运行过程中持续优化这些流水线，并只将最有用的信息作为模型上下文来消费。
本文将介绍 SaC 的动机、设计与实现，并结合现有与新基准给出实证结果。SaC 建立了智能体搜索在成本与性能上的新前沿，我们很高兴与用户以及更广泛的 AI 社区分享这一成果。
传统搜索的刚性
世界上最早的搜索引擎是为人类用户构建的。人类用户逐渐习惯于一种可预测的体验，通常由固定数量、按相关性排序的文档构成。用户并不想微观管理搜索过程；他们只想输入一个查询并找到有用的结果。
因此，面向人类的搜索引擎逐渐收敛到一种通用的单体架构，旨在为输入查询生成包含前 n 个命中的、对人类友好的搜索结果页面（SERP）。这种模式推动了消费级搜索数十年的进步。它快速、熟悉，并且非常适合人类浏览。
随后，大语言模型（LLM）出现，AI 系统也开始成为搜索的消费者。Perplexity 在 2022 年推出答案引擎时率先推动了这一转变。自那以后，我们的搜索工程工作一直聚焦于如何最大化搜索结果对 AI 模型的价值。为了打造世界上最准确、最可靠的 AI，我们必须构建一个专注于让每个 token 都尽可能“信息密集”的搜索系统。由此产生的创新，包括子文档检索、上下文效率、语义理解以及其他关键领域，显著提升了 AI 系统检索和行动的能力。
然而，即便是针对 AI 优化的系统，在很大程度上仍继承了传统搜索引擎的核心契约：接受查询，运行预定义搜索流水线，返回经过完整处理的结果集。对于简单请求，这种方式没有问题。但对于更复杂的请求，它会逐渐成为限制性能、延迟和成本的瓶颈。
图 3 | 传统搜索系统迫使智能体工作流通过模型可见的轮次来串联搜索。模型必须针对不同查询参数反复调用相同的搜索流水线，并将所有结果引入模型上下文。
刚性带来的失败模式
传统搜索流水线围绕一个单一控制点设计：查询参数。搜索引擎按照预定义逻辑掌控流水线的其余部分，而模型必须去适应它。对模型而言，查询参数以下的一切都是刚性的——实际计算的形态不受模型控制。
当消费者是浏览链接的人类时，这是一条合理的边界；但当消费者是试图在闭环中解决知识密集型任务的 AI 模型时，这就是一条很差的边界。根据我们的经验，这种刚性会导致三种反复出现的失败模式：
- 粗糙的上下文。AI 模型对上下文的质量和紧凑性非常敏感，而这两者都高度依赖具体查询，单体式搜索流水线并非为在所有查询上都保持最优而设计。例如，如果模型只需要一条高度精确的信息，但它只能访问一个强调召回率的端到端搜索接口，那么该接口会向模型上下文中引入大量无关信息。另一方面，如果模型需要多条信息，而每条都需要不同的搜索策略，它可能被迫为所有信息串行调用同一个次优流水线，导致成本飙升、上下文噪声加重。
- 未能利用领域知识。在许多情况下，模型可能已经具备某些领域知识（来自训练、Agent Skill、记忆，或 LLM 轨迹中的前文 token），而这些知识本应指导搜索策略。然而，僵硬的搜索接口会阻止模型利用这些知识。例如，模型可能会意识到，对于某个特定请求，应以特定方式融合词法信号与语义信号、优先某些来源，或按特定键对结果进行聚合。除非这些洞见刚好能通过查询参数实现，否则模型实际上无法据此行动。
- 控制流低效与上下文污染。许多搜索工作流并不天然适合串行执行。它们可能需要对多个查询变体进行分流、并行抓取、去重，以及其他需要非线性和异步控制流的操作。强行通过重复的模型轮次来完成这些步骤会增加延迟，也让工作流更难优化。与此同时，这还会用模型未必需要的噪声中间状态污染上下文，从而导致性能下降和更频繁的压缩。
在 AI 的函数调用与 MCP 时代，对于这些挑战并没有太多可做的事情。当每次搜索操作都需要与 LLM 推理进行一次往返时，开发者自然会倾向于尽可能让那一次往返完成更多工作。这就意味着端到端搜索流水线会返回可直接供模型消费的完整结果集。
因此，如今大多数面向 AI 的搜索系统仍在这种单体式契约下运行。然而，随着模型智能和用户需求持续增长，这一契约的缺点变得越来越明显。如今最先进的 AI 系统建立在以代码为先的运行环境之上，能够组合出每分钟执行数千个动作的任务专用工作流。搜索系统尚未完全释放出这一潜力。
我们长期以来一直怀疑，AI 原生搜索的正确边界应当更靠近底层。模型不应只是调用搜索引擎，而应能够根据具体任务编排搜索栈中的各个组成部分。这需要一种根本不同的架构。
设计可编程的搜索架构
下一代搜索架构将依赖一个核心原则：搜索应当原生地可由 AI 智能体编程。智能体不应被限制在一组预先设定好的搜索流水线中。相反，智能体必须能够使用在不同抽象层级上设计的可组合构件，构建出特定任务所需的流水线。
我们新的 Search as Code（SaC）架构体现了这一原则。在 SaC 中，没有任何一次检索操作是通过函数调用或 MCP 接口发出的。所有操作都由模型生成的 Python 代码来编排。对于最简单的搜索需求，这段代码可能只是对一个高层搜索端点发起的少量请求；但对于复杂任务，代码可以复杂到任意程度，包含条件执行、异步、并行，以及对多种低层原语的调用。
图 4 | Search as Code（SaC）架构依赖于一个由模型、计算沙箱以及建立在 Perplexity 搜索基础设施之上的智能体式搜索 SDK 组成的栈。
SaC 包含三个紧密耦合的层：
- 模型充当控制平面。它们推理用户（或上级智能体）的指令，将指令拆解为任务，决定每个任务需要哪些检索与处理流水线，并生成用于实现这些流水线的代码。
- 计算沙箱通过安全的代码执行运行时提供确定性计算。它们为模型提供一个画布，用于实现控制流、批处理、重试、过滤、连接、聚合以及其他确定性操作。
- 我们的智能体式搜索 SDK 将 Perplexity 的搜索栈暴露为可组合原语。它提供从低层检索操作到高层语义解析的一系列构件。该 SDK 嵌入在沙箱的执行运行时中，使模型能够在一次推理轮次内编排多达数千个操作。下面我们将讨论各层的设计决策。
智能体式搜索 SDK
智能体式搜索 SDK 定义了可编程搜索的构件。重要的是，我们的 SDK 不是把一个现成的搜索 API 打包成库。过去几个月里，我们的工程团队已将搜索栈重构为模块化、可组合的原语。我们构建智能体式搜索 SDK，就是为了直接访问这些原语，从而为模型提供一个更强大的画布，用于编排任务专用检索流水线。
SDK 中仍然提供高层、端到端的搜索流水线，但它们不再是唯一选择。相反，它们只是常见搜索模式的一种简写。模型可以根据任务需要自由使用或绕过它们。
**运行时的选择：**我们曾在 Python、Rust、TypeScript 和 Bash 之间考虑 SDK 运行时。鉴于 Python 的普及程度以及其丰富的数据处理库生态，我们怀疑 Python 会是最自然的选择。内部测试证实了这一点，如今正在部署的 SDK 版本基于 Python。我们预计会定期重新评估运行时选择，以确保它始终能提供最佳的智能体体验。
**通过自动研究持续改进：**我们还通过一个迭代式自动研究闭环，优化了 SDK 对前沿 LLM 的易用性。该闭环在数周内持续运行，会针对延迟、代码生成质量以及整体任务表现等指标提出并验证 SDK 改进。自动研究闭环已经对 SDK 的结构和外观做出了诸多调整，并在各个维度上带来了显著提升。随着新的前沿模型和搜索组件出现，我们计划继续通过自动研究进一步完善 SDK。
沙箱
沙箱为定义和运行 SaC 流水线提供安全环境。它们执行模型生成的代码，并提供对智能体式搜索 SDK 的访问，以便与单个搜索原语交互。
我们已在优化和加固沙箱方面投入大量精力，其整体系统设计本身就值得单独成文。这里我们聚焦于与 SaC 最相关的设计考量：中间状态的管理。
SaC 使智能体能够在一次推理轮次内编排复杂流水线。然而，某些中间状态需要跨轮次传递。例如，模型可能希望在第 1 轮抓取一些文档，在第 2 轮抽样检查这些文档以决定下一步行动，然后从第 3 轮开始，围绕这些文档构建后续搜索流水线进行更深入调查。正如上文所述，把中间状态通过 token 空间传递并不是有效策略。
我们考虑了两种跨轮次管理中间状态的方法：
**持久化文件系统 + 显式序列化/反序列化：**沙箱可以向模型暴露持久化文件系统，供其跨轮次使用。希望持久化中间状态的模型可以在某一轮生成的代码中加入序列化步骤，并在后续轮次中加入反序列化步骤（无论是供模型自身检查，还是供下游使用）。文件系统方案使模型能够直接、显式地控制中间状态如何跨轮次传递。它还通过强制显式识别和持久化模型使用的信息，确保了可追踪性。其一个缺点是生成序列化/反序列化代码会带来延迟和上下文开销，不过设计良好的工具函数可以缓解这一问题。
**REPL：**另一种方案是让沙箱以 REPL 风格环境跨轮次持久化执行运行时本身。这样模型就可以在内存中维护中间状态，而无需进行任何序列化，因为前几轮中定义或修改的变量可以在后续轮次中直接通过名称引用。REPL 方案更节省 token，因为它避免了生成序列化/反序列化代码。然而，由于缺少显式序列化步骤，它可能会影响下游表现——任何写过 100 个单元格 Jupyter 笔记本的人都会很熟悉这一点：随着变量命名空间变得混乱，要准确追踪哪些状态被跨轮次持久化以及原因，就会越来越困难。
我们测试了这两种方法，发现虽然在普通使用场景下表现相近，但基于文件系统的序列化/反序列化在特别长的轨迹上具有更好的可靠性。因此我们采用基于文件系统的序列化/反序列化方案。我们的推测是，要求模型以声明式而非隐式方式传递状态，有助于它们更有效地管理这些状态。这一发现目前仍是初步结论，我们会继续迭代这两种方法。
模型
为智能体运行环境提供动力的模型充当 SaC 的控制平面：它们从智能体式搜索 SDK 的构件中动态组装搜索流水线，以满足每个任务的需要，然后将这些流水线作为代码发送到沙箱中执行。
Perplexity 在智能体运行环境中使用多种模型，我们发现最新的前沿模型在通用代码生成方面整体表现都相当出色。主要挑战在于，如何专门诱导出针对智能体式搜索 SDK 的有效代码生成。换句话说，我们如何让模型有效地将 SDK 的构件编织成面向任务优化的流水线？
与某种语言的标准库不同，定制构建的 SDK 不太可能出现在预训练数据中。即便有自动研究带来的 SDK 可用性改进，许多模型仍然习惯通过函数调用和直接 MCP 调用来与搜索系统交互。这些模型仅靠源码和自动生成文档，未必能熟练驾驭该 SDK。
为解决这一挑战，我们开发了高度调优的 Agent Skills，教模型如何有效利用我们的 SDK。最初版本遵循了 Perplexity 针对 Skills 的设计原则进行开发，随后又通过一个专门的自动研究闭环加以优化，该闭环使用的指标与 SDK 优化所用指标相同。我们还限制了 Skill 的大小以防止上下文膨胀，最终版本的根目录 SKILL.md 文件少于 2000 个 token。
优化后的 Skills 不只是简单罗列 SDK 可用的构件（这一点通过运行时反射同样可以获得）。大部分 token 都用于提供简洁、可泛化的指导，以及少样本示例，说明如何把这些构件组合成复杂模式。借助这些 Skills，我们观察到模型能够有效利用 SDK，编排出可扩展到数千个离散操作的搜索流水线。
代码作为编排器与补缺器
通过将这些层组合起来，SaC 改变了模型与搜索栈之间的关系。在固定流水线搜索系统中，模型位于搜索之上，并通过一个狭窄的串行调用接口与之交互。在 SaC 中，模型成为搜索过程编排中的主动参与者。搜索栈的所有元素都可由模型直接编程，而沙箱和智能体式搜索 SDK 则为这些元素提供了必要接口。
但如果某些能力在原生层面并不存在呢？代码是编排既有能力的强大媒介。然而，代码的力量并不止于编排。它还可以为搜索栈或 SDK 中不存在的能力充当补缺器。智能体受益于简约性，SDK 没必要用专门函数覆盖每一种潜在操作。相反，SDK 提供最基础的原语，而模型可以用代码即时构建任何额外组件。
例如，考虑一个复杂的正则表达式，而搜索系统自身的查询语法无法高效实现它。若没有编码能力，模型只能生成最接近的近似式，发起查询，然后在噪声极大的结果集上进行 token 空间过滤。借助 SaC，模型则可以生成一个程序，通过并行的 SDK 调用收集一个包含目标正则表达式结果集的超集。随后，模型可以在通过 SDK 去重后，再编写额外代码，确定性地将结果收缩到与该正则表达式完全一致的集合。这样一来，智能体就能实现定制化搜索能力，而无需用过于小众的子程序让 SDK 变得臃肿。
案例研究：CVE 厂商通告
我们展示一个基于测试套件中真实任务的案例研究。该任务要求智能体识别并刻画 2023–2025 年间 200 多个高危 CVE。每条记录都必须引用受影响厂商自身的通告，写明产品和修复版本，并证明该修复版本与特定 CVE 直接相关。
SaC 的答案在准确率上获得了 100%，而总 token 用量相较于非 SaC 基线下降了 85.1%（从 288.7K tokens 降至 42.9K tokens）。在第 4 节中将更详细讨论的非 Perplexity 系统得分都低于 25%。
我们从轨迹中选取了三个风格化的代码块，以说明 SaC 的可编程性如何让模型实现有效策略。
第一个代码块纯属编排。生成的程序一开始就把来源类别规则直接编码进查询计划：只有厂商自有的通告格式才相关。包括 NVD、MITRE、CVE Details、新闻报道、CERT 页面以及第三方数据库在内的非厂商来源，都被结构性地排除在范围之外。精确短语约束也会把搜索引导到那些其索引文本中已经包含后续所需精确 CVE 细节的页面。
第二个代码块使用 LLM 作为中间规划子程序。代码会总结哪些“厂商-年份”组合已经产生了足够多的候选页面，请求有针对性的精炼建议，并在执行前验证每个提出的查询。这保留了轨迹中的有用模式，例如限定站点的精确短语探测和自适应回填，而无需在 SDK 中硬编码一个专门的 CVE 通告爬虫。
最后一个代码块是结果验证器，其逻辑完全由智能体通过代码生成来定义。虽然搜索子程序可以找到看似合理的通告页面，但该任务要求更严格的关系：通告必须以厂商撰写的文本，将一个 CVE 与一个受影响产品和一个修复版本绑定起来。该模式把这种关系显式化，因此下游代码可以按 CVE 去重、拒绝聚合器 URL、丢弃薄弱的版本证据，并持续回填，直到满足记录数量下限。
评估结果
我们在一套全面的基准测试中评估 SaC 的有效性，重点关注绝对性能以及成本-性能前沿。
基准与系统
我们的基准套件总共包含五个基准，旨在跨不同领域、任务形式和复杂度水平，对依赖搜索的 AI 工作流进行压力测试。我们使用了四个现有基准：DeepSearchQA（DSQA）、BrowseComp、Humanity's Last Exam（HLE） 和 WideSearch。对于前三个基准（DSQA、BrowseComp 和 HLE），我们报告准确率作为主要指标。对于 WideSearch，我们按行报告 F1 分数。
我们还使用了新开发的 WANDR 基准，它聚焦于困难的“广域研究”任务，这类任务需要对搜索、计算和模型推理进行精细编排。WANDR 的灵感来自 Perplexity Computer 为用户处理的那些知识密集型专业任务。它在 WideSearch 及类似基准的基础上进一步演进，但更强调复杂任务与任务结构。我们将在未来几周内发布 WANDR 基准。
我们评估了五种基于智能体的系统。为了隔离底层架构本身的表现，而不是并行化带来的收益，我们考察的是单次运行，而非“最佳 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 代理工具集和自动允许的命令。底层模型使用 Opus 4.7（高推理）。
**Exa：**我们评估生产 API 上的 Exa Agent，并将 effort 设为 high。
**Parallel：**我们评估生产 API 上的 Parallel Tasks，并将 processor 设为 ultra4x。
对比性能
表 1 展示了各系统的基准分数。SaC 在五个基准中的四个上优于所有其他系统。在剩余的那个基准（HLE）上，SaC 与 OpenAI Responses 基本并列第一。引言中的图 2 以图形方式展示了这些分数。
| 基准 | Perplexity（SaC） | OpenAI | Anthropic | Exa | Parallel |
|---|---|---|---|---|---|
| DSQA | 0.871 | 0.733 | 0.815 | 0.530 | 0.810 |
| BrowseComp | 0.805 | 0.720 | 0.598 | 0.380 | 0.560 |
| HLE | 0.612 | 0.614 | 0.566 | 0.387 | 0.515 |
| WideSearch | 0.651 | 0.522 | 0.590 | 0.471 | 0.584 |
| WANDR | 0.386 | 0.130 | 0.152 | 0.057 | 0.126 |
表 1 | 各受评系统的基准分数。每行最佳分数加粗显示。
尽管 SaC 在整套基准上都取得了最先进的表现，但其优势在 WANDR 上尤为显著。图 5 分解了 WANDR 的分数，显示 Perplexity 的 SaC 实现比次优系统高出 2.5 倍。尽管优势巨大，WANDR 仍未被充分“饱和”，即便对 SaC 也依然具有挑战。我们认为，WANDR 任务所需的复杂、强横向展开的搜索工作流，还需要在研究和搜索工程上进一步突破，才能稳定实现高性能。
图 5 | 各受评系统在 WANDR 上的分数。Perplexity Agent API 以 2.5 倍优势领先次优系统。
最后，我们衡量 SaC 相对于采用相同 Perplexity 搜索基础设施的更传统搜索流水线所带来的相对提升。图 6 展示了在每个基准上，SaC 与非 SaC 架构之间的分数差异。总体而言，SaC 带来了显著的性能提升，其中在 DSQA 上的绝对增益最大（+19.77 个百分点，29%），在 WANDR 上的相对增益最大（+12.00 个百分点，45%）。
图 6 | Perplexity 基线与 SaC 在各基准上的得分对比，并标注了绝对与相对变化。
成本-性能前沿
在实际应用中，用户关心的是性能相对于成本的表现。因此，我们在 DSQA 和 WideSearch 上评估成本-性能前沿。我们将 SaC 在低、中、高三种模型推理强度下的成本和性能，与其他系统一起进行比较。图 7 和图 8 将基准得分与单任务价格进行对比绘制，并将 x 轴反向显示，因此越靠右代表越便宜，越靠上代表性能越好。
图 7 | DSQA 得分与单任务价格的关系。虚线连接了 SaC 的不同模型推理配置。
在 DSQA 上，SaC 的三种设置都位于右上方前沿。低推理设置比所有其他系统都便宜，同时表现优于其中两个。中推理设置在每任务低于 1 美元的成本下，优于所有非 SaC 系统。高推理设置则以具有竞争力的成本实现了顶级性能。
图 8 | WideSearch 得分与单任务价格的关系。虚线连接了 SaC 的不同模型推理配置。
WideSearch 呈现出相似形态的前沿。与 DSQA 类似，低推理设置以低于所有非 SaC 系统的成本取得了具有竞争力的表现，而中、高推理设置则在任务性能上优于非 SaC 系统。
迈向新的计算架构
Search as Code 反映了软件设计中的一项更广泛变化。几十年来，软件系统一直围绕传统运行时在 CPU 上执行的确定性指令来组织。前沿模型引入了一种新的计算形式：能够既遵循又生成指令的 token 空间推理。最强大的计算系统不会在这两种计算形式之间二选一，而是会把它们结合起来。
搜索是这种混合架构的天然试验场。模型非常适合决定需要哪些证据，以及应如何消解不确定性。确定性运行时则非常适合批处理、并行、过滤、排序和聚合。搜索基础设施作为通用 I/O 层，为运行时提供与世界信息交互的有用接口，每分钟可支撑数千次操作。当这些部分整合在一起时，所得系统在完成现实世界任务方面会强大得多，也高效得多。
要释放这些能力，这种架构中的每一部分都不可或缺。没有智能模型，系统就无法对搜索策略进行推理。没有沙箱，模型就会被迫进行串行 I/O 和低效的 token 空间处理。没有原子化的搜索栈，模型就无从编排。SaC 之所以有效，是因为推理、确定性计算和 I/O 被共同设计，以放大每一层的优势。
通过构建持续改进闭环，这种协同设计还可以进一步推进。例如，智能体式搜索 SDK 和 SaC Agent Skills 可以在一个共同的自动研究闭环中联合优化。更激进地说，还可以训练模型去利用作为 SDK 暴露出来的底层搜索原语。甚至可以尝试在模型训练过程中共同演化 SDK 的设计。我们期待在未来的工作中继续探索更积极的协同设计策略。
我们构建 SaC，是为了让模型能够控制搜索过程，而不仅仅是消费其结果。我们的结果证明了这种控制的力量：SaC 在知识密集型智能体基准上同时推进了绝对性能和成本-性能前沿。我们很高兴从今天起，先在 Perplexity Computer 和 Agent API 中向用户提供 SaC 的能力。我们将继续在整个技术栈的各层优化 SaC 架构，确保我们的用户（以及为他们服务的智能体）拥有尽可能强大且高效的搜索能力。