Perplexity 推出 Search as Code 搜索架构

搜索是AI系统的核心基础能力。前沿模型的能力逐月增强，但它们仍然需要获取来自更广阔世界的新鲜、准确且精心整理的知识。搜索是AI系统获取这些知识的主要途径，因此也是任何需要得出结论、采取行动并执行现实世界工作的产品的基础组件。 我们认为，传统搜索流水线在智能体时代正日益过时。传统搜索回答查询，但当今的智能体完成的任务可以呈现无数种形态。这些任务要求智能体在其执行框架内直接定义针对特定任务的检索策略。在Perplexity Computer中，我们看到单个任务在几分钟内调用数百甚至数千次检索操作：这种工作流对人类来说不可能，但对智能体来说却完全自然。 在这个世界中，搜索本身必须变得智能体化，其构建模块可直接作为SDK在智能体执行框架内访问。我们推出Search as Code（SaC）作为Perplexity新的参考搜索架构。 引言 Perplexity的搜索栈每秒在我们的应用和API平台中处理数千次查询。2025年9月，我们发布了搜索系统的首份架构概览。这些系统内部的持续创新支撑了Search API、Agent API和Computer等新产品的推出，自我改进循环不断优化搜索栈，日复一日更好地服务用户。 传统上，AI系统将搜索视为一个单体：AI模型发出查询，搜索引擎运行其预定义的流水线，模型将结果作为上下文消费。在大多数情况下，这足以满足早期AI用户的需求。鉴于其请求相对简单，没有理由担心搜索流水线究竟如何设计，或者流水线的架构是否对当前任务最优。默认设置被认为足够好，默认接口（函数调用和MCP）也是如此。 传统搜索架构暴露一个固定的单一系统供模型串行调用，而Search as Code暴露原子化的搜索原语，由智能体通过生成的代码进行组合。 然而如今，这种方法逐月愈发过时。用户对AI的要求远不止单次分析。他们期望智能体在数小时甚至数天内端到端完成任务。这些任务可能复杂、开放式，且信息需求高度多变，单体架构在这些需求的重压下正在崩溃。 关键瓶颈最终是控制权的问题。前沿模型已经相当擅长在固定上下文上进行推理。然而，最强大的AI系统将需要能够引导上下文如何被检索、处理、聚合和呈现给模型。 传统搜索系统在设计时并未考虑这种程度的可控性。毕竟，即使提供这种控制，也不能期望人类用户对搜索流水线内部进行细粒度控制。早期AI模型只能通过函数调用和MCP的线性轨迹来控制搜索。但当今的前沿模型，由具备代码能力的智能体执行框架驱动，可以通过计算机代码对任何可想象的计算原语施加细粒度控制。我们的任务变成了提供正确的原语。 为满足这一需求，我们正在我们的产品中引入一种新的搜索架构：Search as Code（SaC）。这种新架构使模型能够深入搜索栈本身，而不仅仅是消费其最终输出。核心思想很直接：我们将搜索栈的组件作为SDK中的原语暴露出来。对于任何需要搜索的请求，模型按需将这些原语组装成针对该特定请求定制的检索流水线。 组装这条流水线通过代码生成和在安全沙箱内执行来完成。与其他代码生成驱动的搜索方法不同，我们不是简单地将传统搜索API塞进shell或语言运行时中。相反，我们精心设计了一个Agentic Search SDK，以尽可能最原子化的级别暴露搜索的各个构建模块。 Search as Code（SaC）在多样化的基准测试套件中推进了智能体搜索的性能前沿。 借助这些构建模块，SaC让模型直接控制每个单独的搜索步骤：检索、排序、过滤、扇出、渲染等。它还让模型高效访问中间状态，如候选列表和排序信号。控制力和可读性这两个杠杆共同让智能体能够设计跨越数千次检索操作的定制搜索流水线，在运行中优化这些流水线，并仅将最有用的信息作为模型上下文消费。 本文描述了SaC的动机、设计和实现，以及在现有和新基准上的实证结果。SaC为智能体搜索建立了新的成本-性能前沿，我们很高兴与用户和更广泛的AI社区分享。 传统搜索的刚性 世界上最早的搜索引擎是为人类用户构建的。这些用户期望可预测的体验，通常由固定数量的相关性排序文档组成。用户不想微观管理搜索过程；他们想输入查询并找到有用的结果。 因此，面向人类的搜索引擎收敛于一种常见的单体架构，旨在生成人类友好的搜索引擎结果页面（SERP），包含输入查询的前n个命中结果。这种模式推动了消费级搜索数十年的进步。它快速、熟悉，并且对人类浏览非常有效。 随后出现了大语言模型，AI系统也成为了搜索的消费者。Perplexity在2022年推出答案引擎，率先推动了这一转变。从那时起，我们的搜索工程工作便聚焦于如何针对AI模型优化搜索结果的价值。为了构建世界上最准确、最可靠的AI，我们必须设计一个专注于让每个token尽可能信息密集的搜索系统。由此在子文档检索、上下文效率、语义理解及其他关键领域产生的创新，显著提升了AI系统检索信息并据此行动的能力。 然而，即便是针对AI优化的系统，也基本上继承了与传统搜索引擎相同的基本契约：接受查询、运行预定义的搜索流水线、返回完全处理过的结果集。对于简单请求，这种方式运行良好。但对于更复杂的请求，这日益成为一个限制性瓶颈，降低性能、增加延迟和成本。 传统搜索系统迫使智能体工作流通过模型可见的轮次来串行安排搜索。模型必须在不同查询参数下反复调用相同的搜索流水线，并将所有结果引入模型上下文。 僵化导致的失效模式 传统搜索流水线围绕单一控制点设计：查询参数。搜索引擎按照其预定义逻辑掌控流水线的其余部分，模型必须适应它。对模型而言，查询参数下游的一切都是僵化的——实际计算形态超出了模型的控制范围。 当消费者是浏览链接的人类时，这是一个合理的边界。当消费者是试图在闭环中解决知识密集型任务的AI模型时，这就是一个糟糕的边界。根据我们的经验，这种僵化会产生三种反复出现的失效模式： 粗粒度上下文。AI模型对上下文的质量和紧凑性很敏感。质量和紧凑性都高度依赖于查询，而单体式搜索流水线并非为在所有查询上都实现最优性能而设计。例如，如果模型需要一条高度精准的信息，却只能访问一个优先考虑召回率的端到端搜索端点，使用该端点会将大量无关信息引入模型上下文。另一方面，如果模型需要多条信息，且每条信息都需要不同的搜索策略，它可能被迫对所有信息串行调用同一个次优流水线，导致成本膨胀和上下文噪声。 无法利用领域知识。在许多情况下，模型可能拥有领域知识（来自其训练、Agent Skill、记忆或LLM轨迹中较早的token），这些知识应当指导搜索策略。然而，僵化的搜索接口阻止模型利用这些知识。例如，模型可能意识到对于某个特定请求，它应当以特定方式混合词法和语义信号、优先考虑某些来源，或按特定键聚合结果。除非这些洞见恰好能通过查询参数实现，否则模型实际上无法据此行动。 低效的控制流和上下文污染。许多搜索工作流并非天然串行。它们可能需要对查询变体进行扇出、并行获取、去重以及其他需要非线性和异步控制流的操作。通过反复的模型轮次强制这些步骤会增加延迟，并使工作流更难优化。它还会用可能对模型推理无用的噪声中间状态污染模型上下文，导致性能下降和更频繁的压缩。 在AI的函数调用和MCP时代，这些挑战几乎无计可施。当每次搜索操作都需要各自往返LLM推理时，开发者自然倾向于在那次往返中尽可能完成更多工作。这意味着端到端搜索流水线返回完全处理过的结果集，供模型直接消费。 因此，当今大多数面向AI的搜索系统仍在这种单体式契约下运行。然而，随着模型智能和用户需求的持续增长，该契约的缺陷变得更加明显。当今最先进的AI系统构建在代码优先的harness之上，能够编排每分钟执行数千个动作的任务特定工作流。搜索系统尚未充分实现这一潜力。 我们长期以来一直怀疑，AI原生搜索的正确边界在技术栈中更低的位置。模型不应仅仅调用搜索引擎。它们应当能够根据具体任务需求编排搜索栈的各个组件。这需要一种根本不同的架构。 设计可编程搜索架构 下一代搜索架构将取决于一个核心原则：搜索应当可由AI智能体原生编程。智能体绝不能局限于一组预先规定的搜索流水线。相反，智能体必须能够使用在不同抽象层级设计的可组合构建块，构建特定任务所需的流水线。 我们新的Search as Code（SaC）架构体现了这一原则。在SaC中，没有任何一个检索操作通过函数调用或MCP接口派发。所有操作都改为通过模型生成的Python代码编排。对于最简单的搜索需求，该代码可能只包含对高层搜索端点的少量请求。但对于复杂任务，代码可以按需复杂，涉及条件执行、异步、并行以及对广泛底层原语的调用。 Search as Code（SaC）架构依赖于一个由模型、计算沙箱和位于Perplexity搜索基础设施之上的Agentic Search SDK组成的栈。 SaC涉及三个紧密耦合的层： 模型充当控制平面。它们对用户（或父智能体）的指令进行推理，将指令分解为任务，决定每个任务需要哪些检索和处理流水线，并生成代码来实现这些流水线。 计算沙箱通过安全的代码执行运行时提供确定性计算。它们为模型提供一个画布，用于实现控制流、批处理、重试、过滤、连接、聚合及其他确定性操作。 我们的 Agentic Search SDK 将 Perplexity 的搜索栈以可组合原语的形式对外暴露。它提供从底层检索操作到高层语义解析的构建模块。该 SDK 嵌入在沙箱的执行运行时中，使模型能够在单次推理轮次内编排多达数千次操作。下面，我们讨论各层的设计决策。 Agentic Search SDK Agentic Search SDK 定义了可编程搜索的构建模块。重要的是，我们的 SDK 并非将已有的搜索 API 打包成库。在过去几个月里，我们的工程团队将搜索栈重新架构为模块化、可组合的原语。我们构建 Agentic Search SDK 以提供对这些原语的直接访问，从而为模型编排任务特定的检索流水线提供更强大的画布。 高层、端到端的搜索流水线在 SDK 中仍然可用，但它们不再是唯一选项。相反，它们充当常见搜索模式的简写形式。模型可以根据任务需求自由使用或绕过它们。 运行时选择：我们考虑过将 Python、Rust、TypeScript 和 Bash 作为 SDK 运行时。我们曾怀疑 Python 会是最自然的选择，因为它无处不在且拥有数据处理库生态系统。内部测试证实了这一点，今天推出的 SDK 版本基于 Python。我们预计会定期重新评估运行时选择，以确保它持续提供最佳的智能体体验。 通过自动研究持续改进：我们还通过迭代式自动研究循环，优化了 SDK 对前沿 LLM 的可消费性。该循环连续运行数周，针对延迟、代码生成质量和整体任务性能等指标提出并验证 SDK 改进。自动研究循环已经对 SDK 的结构和美学做出了大量更改，在所有维度上都取得了显著收益。随着新的前沿模型和搜索组件的出现，我们计划通过自动研究进一步改进 SDK。 沙箱 沙箱为定义和运行 SaC 流水线提供安全环境。它们执行模型生成的代码，提供对 Agentic Search SDK 的访问，以促进与各个搜索原语的交互。 我们在优化和加固沙箱方面投入了大量精力，其总体系统设计值得单独撰文。在此，我们聚焦于与 SaC 最相关的设计考量：管理中间状态。 SaC 使智能体能够在单次推理轮次内编排复杂流水线。然而，某些中间状态需要跨轮次传递。例如，模型可能希望在第 1 轮获取一些文档，在第 2 轮检查这些文档的子样本以决定下一步做什么，然后从第 3 轮开始开发下游搜索流水线以进一步调查这些文档。如上所述，通过 token 空间传递中间状态并非有效策略。 我们考虑了两种跨轮次管理中间状态的方法： 持久文件系统 + 显式 serde：沙箱可以暴露持久文件系统供模型跨轮次使用。希望持久化中间状态的模型可以在某一轮生成的代码中包含序列化步骤，并在后续轮次中包含反序列化步骤（用于模型自身检查或下游使用）。文件系统方法允许模型直接且显式地控制中间状态如何跨轮次传递。它还通过强制显式标识和持久化模型所用信息来确保可追溯性。一个缺点是生成 serde 代码会带来延迟和上下文开销，不过设计良好的工具函数可以缓解这一开销。 REPL：或者，沙箱可以在 REPL 风格环境中跨轮次持久化执行运行时本身。这允许模型在内存中维护中间状态，完全无需序列化，因为在前序轮次中定义或修改的变量可以在后续轮次中直接按名称引用。REPL 方法更节省 token，因为它避免了生成 serde 代码的需要。然而，缺少显式序列化步骤可能会损害下游性能，原因对于任何用过 100 个单元格的 Jupyter notebook 的人来说都很熟悉：随着变量命名空间变得杂乱，跟踪跨轮次究竟持久化了什么以及为什么持久化会变得更加困难。 我们测试了两种方法，发现虽然它们在常规使用中表现相似，但基于文件系统的 serde 在特别长的轨迹上提供了更好的可靠性。因此，我们采用基于文件系统的 serde 作为我们的解决方案。我们推测，要求模型以声明式而非隐式方式传递状态有助于它们更有效地管理该状态。这是一个初步发现，我们将继续迭代这两种方法。 模型 为智能体框架提供动力的模型充当 SaC 的控制平面：从 Agentic Search SDK 的构建模块动态组装搜索流水线以满足每个任务的需求，然后将这些流水线作为代码分派给沙箱执行。 Perplexity 在我们的智能体框架中使用了多种模型，我们发现最新的前沿模型在通用代码生成方面整体上相当有效。主要挑战是诱导专门针对 Agentic Search SDK 的有效代码生成。也就是说，我们如何让模型有效地将我们 SDK 的构建模块编织成任务优化的流水线？ 与语言的标准库不同，自定义构建的 SDK 不太可能出现在预训练数据中。即使通过自动研究改进了 SDK 的可消费性，许多模型仍然被训练为通过函数调用和直接 MCP 调用来与搜索系统交互。这些模型不太可能仅凭源代码和自动生成的文档就能熟练运用该 SDK。 为应对这一挑战，我们开发了经过高度调优的 Agent Skills，用于教会模型有效利用我们的 SDK。初始版本依据 Perplexity 的 Skills 设计原则开发，随后通过专门的自动研究循环，围绕与 SDK 优化相同的指标进行优化。我们还限制技能大小以防止上下文膨胀，最终版本的根 SKILL.md 文件均少于 2000 个 token。 优化后的 Skills 不止于罗列 SDK 可用的构建块（这类信息通过运行时反射同样可以轻松获得）。大部分 token 用于提供简洁、可泛化的指导以及少样本示例，说明如何将这些构建块组合成复杂模式。借助这些 Skills，我们观察到模型能够有效利用 SDK 编排可扩展到数千个离散操作的搜索流水线。 代码作为编排器与补缺者 通过组合这些层，SaC 改变了模型与搜索栈之间的关系。在固定流水线搜索系统中，模型位于搜索之上，通过狭窄的串行调用接口与之交互。在 SaC 中，模型成为编排搜索过程本身的积极参与者。搜索栈的所有元素都可被模型直接编程，沙箱和 Agentic Search SDK 提供了通往这些元素的必要接口。 但那些并非原生存在的能力呢？代码是编排既有能力的强大媒介。然而代码的力量不止于编排。它还可以为搜索栈或 SDK 中不存在的能力充当补缺者。智能体受益于简约性，让 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 的可编程性如何让模型实现有效策略。 python # Part 1 of 3: fan out over official advisory formats. 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 详情的页面。 python # Part 2 of 3: synthesize refinements for sparse vendor-years. 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 用作中间规划子程序。代码总结哪些厂商-年份组合正在产生足够的候选页面，请求有针对性的细化，并在执行前验证每个提议的查询。这保留了轨迹中的有用模式，例如站点范围的精确短语探测和自适应回填，而无需将定制的 CVE 公告爬虫硬编码进 SDK。 python # Part 3 of 3: verify CVE-to-version binding. 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 绑定到一个受影响产品和一个修复版本。该模式使这一关系显式化，因此下游代码可以按 CVE 去重、拒绝聚合器 URL、丢弃弱版本证据，并继续回填，直到满足记录数下限。 评估结果 我们在一个全面的基准套件上评估 SaC 的有效性，同时关注绝对性能和成本-性能前沿。 基准与系统 我们的基准套件共包含五个基准，旨在对跨多个领域、任务格式和复杂度层级的依赖搜索的 AI 工作流进行压力测试。我们使用四个现有基准：DeepSearchQA（DSQA）、BrowseComp、Humanity's Last Exam（HLE）和 WideSearch。对于前三个基准（DSQA、BrowseComp 和 HLE），我们报告准确性作为首要指标。对于 WideSearch，我们按行报告 F1 分数。 我们还使用新开发的 WANDR 基准，它聚焦于困难的“广泛研究”任务，需要仔细编排搜索、计算和模型推理。WANDR 受 Perplexity Computer 为用户处理的知识密集型专业任务启发。它在 WideSearch 及类似基准上迭代，但强调更复杂的任务和任务结构。我们将在未来几周内发布 WANDR 基准。 我们评估五个基于智能体的系统。我们考虑单次运行而非“best-of-N”分数，以隔离底层架构的性能，而非并行化带来的收益。各系统的配置如下所述： Perplexity（SaC）：我们在 Perplexity 的生产 Agent API 中评估 SaC 架构。GPT 5.5（高推理）作为底层模型。 OpenAI：我们评估 OpenAI Responses API，同时启用搜索 (web_search) 和 Python 运行时 (code_interpreter)。GPT 5.5（高推理）作为底层模型。 Anthropic：我们使用 20260401 智能体工具集和自动允许命令来评估 Anthropic Managed Agents。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 任务所需的复杂、高度横向的搜索工作流将需要在研究和搜索工程方面取得额外进展，才能实现持续的高性能。 各评估系统的 WANDR 分数。Perplexity Agent API 以 2.5 倍的系数领先次优系统。 最后，我们测量了 SaC 与利用相同 Perplexity 搜索基础设施的更传统搜索流水线相比的相对增益。图 6 报告了 SaC 与非 SaC 架构在每个基准上的分数差异。总体而言，SaC 带来了显著的性能提升，其中 DSQA 的绝对增益最大（+19.77 个百分点，29%），WANDR 的相对增益最大（+12.00 个百分点，45%）。 每个基准上 Perplexity 基线 vs. SaC 分数，并标注绝对和相对增量。 成本-性能前沿 在实践中，用户关心的是相对于成本的性能。因此，我们在 DSQA 和 WideSearch 上评估成本-性能前沿。我们测量了 SaC 在低、中、高模型推理级别下的成本和性能，并与其他系统并列。图 7 和图 8 绘制了基准分数与每任务价格的关系，x 轴反向，因此越靠右的点越便宜，越高的点代表更好的性能。 DSQA 分数与每任务价格的关系。虚线连接 SaC 模型推理配置。 在 DSQA 上，所有三个 SaC 设置都位于右上前沿。低推理设置比所有其他系统都便宜，同时性能优于其中两个。中等推理设置在每任务低于 1 美元的情况下优于所有非 SaC 系统。高推理设置以有竞争力的成本实现了顶级性能。 WideSearch 分数与每任务价格的关系。虚线连接 SaC 模型推理配置。 WideSearch 显示出类似形状的前沿。与 DSQA 一样，低推理设置以低于所有非 SaC 系统的成本实现了有竞争力的性能，而中等和高推理在任务性能上都优于非 SaC 系统。 迈向新的计算架构 Search as Code 反映了软件设计的更广泛变化。几十年来，软件系统围绕由传统运行时在 CPU 上执行的确定性指令来组织。前沿模型引入了一种新的计算形式：令牌空间推理，它既能遵循也能生成指令。最强大的计算系统将结合这两种计算形式，而不是在它们之间做选择。 搜索是这种混合架构的天然试验场。模型非常适合决定需要什么证据以及如何解决不确定性。确定性运行时非常适合批处理、并行化、过滤、排序和聚合。搜索基础设施充当通用 I/O 层，为运行时提供有用的句柄，以访问世界信息，并能维持每分钟数千次操作。当这些部分集成在一起时，所得系统在完成现实世界任务方面更加强大和高效。 该架构的每一部分都是释放这些能力所必需的。没有智能模型，系统无法对搜索策略进行推理。没有沙箱，模型被迫进行串行 I/O 和低效的令牌空间处理。而没有原子化搜索栈，模型就无从编排。SaC 之所以有效，是因为推理、确定性计算和 I/O 被联合设计，以突出每一层的优势。 这种协同设计可以通过持续改进循环进一步发展。例如，Agentic Search SDK 和 SaC Agent Skills 可以在一个共同的自动研究循环中联合优化。更雄心勃勃的是，可以训练模型利用作为 SDK 暴露的低级搜索原语。人们甚至可以尝试在模型训练过程本身中协同演化 SDK 设计。我们期待在未来的工作中追求更激进的协同设计策略。 我们构建 SaC 是为了让模型能够控制搜索过程，而不仅仅是消费其结果。我们的结果证明了这种控制的力量：SaC 在知识密集型智能体基准上提升了绝对性能和成本-性能前沿。我们很高兴将 SaC 的能力带给我们的用户，从今天的 Perplexity Computer 和 Agent API 开始。我们将继续优化堆栈各层的 SaC 架构，以确保我们的用户（以及为他们服务的智能体）拥有尽可能强大和高效的搜索能力。 引用