Perplexity 让模型自己写搜索流水线

关键信息

SaC 让模型编写的 Python 代码在安全沙箱中运行，并通过 Agentic Search SDK 提供检索、过滤、去重和重排序等函数。Perplexity 表示，这种方式可以并行发起查询、保持上下文窗口更干净，并比标准搜索流水线更适合长时间研究任务。

资讯摘要

Perplexity 表示，传统搜索 API 主要是为人类设计的，因为它们要求模型遵循一个很固定的循环：发出查询、接收结果、阅读结果、再发起下一次查询。公司在新的技术报告中认为，当智能体需要在很短时间内执行大量搜索，并且需要更精细地控制过滤和排序时，这种方式会成为瓶颈。为了解决这个问题，Perplexity 提出了“Search as Code”，让模型不再只是调用固定 API，而是直接生成自定义的 Python 脚本。这个脚本会在安全沙箱中运行，并通过 Agentic Search SDK 调用搜索能力。SDK 将搜索拆分成模块化功能，包括检索、过滤、去重和重排序。

Perplexity 说，标准搜索 API 仍然适合快速问答，但 SaC 更适合复杂研究任务，因为模型可以自己决定搜索策略。为了展示效果，公司用一个网络安全任务做了测试，目标是找出 2023 到 2025 年间发布的 200 个严重 CVE。智能体需要为每个漏洞找到厂商的官方公告、受影响的软件，以及修复漏洞的准确版本，同时不能把新闻稿或博客文章算进去。Perplexity 称，智能体通过三阶段脚本完成了任务：先并行搜索不同厂商的安全公告格式，再针对缺失信息做定向补查，最后用 schema 验证 CVE、产品和修复版本是否对应一致。公司还表示，这种方法比标准流程少用了 85% 的 token，并在五个基准中的四个上超过了竞争系统。

资讯正文

Perplexity 的“Search as Code”让 AI 模型编写自己的搜索流水线，而不是调用固定 API

Perplexity 的新“Search as Code”架构并不调用现成的搜索 API，而是让模型用 Python 代码编写自己的搜索工作流。该公司承诺，这样可以带来更精确的结果，并降低 token 使用量。

任何看过 AI agent 处理复杂研究任务的人，都会见到同样的模式。模型先写出一个查询，搜索 API 返回一组结果，模型读取这些结果，然后再写下一个查询。这个循环会重复很多次，往往一连重复多轮。

Perplexity 在一份新的技术报告中把这称作一个瓶颈。如今的搜索引擎是为想要整齐蓝色链接列表的人类打造的，但对于一个要在几分钟内执行数百次搜索的 AI agent 来说，这种设计过于僵硬。agent 只能调整搜索词；其他一切都是黑箱。

“Search as Code”（SaC）改变了这种动态。模型不再调用 API，而是编写一个自定义的 Python 脚本来执行搜索。脚本在安全的沙箱中运行，并从 Perplexity 的搜索后端拉取数据。检索、过滤、去重和重排序等基础操作都被打包成了简单的 SDK 函数。

三层架构：模型、沙箱、SDK

这套架构分为三层。最上层是模型，它理解任务并决定搜索策略。中间层是运行代码的沙箱。最底层是“Agentic Search SDK”，它把 Perplexity 的搜索引擎拆分为可单独组合、按需混搭的函数。

标准搜索 API 仍然保留，用于快速提问。但对于棘手的研究任务，模型可以深入得多。它可以并行发起查询，用程序化方式过滤噪音，并只把相关结果拉入上下文窗口。

Perplexity 表示，优势就在这里。标准搜索流水线会把大量垃圾信息塞进 agent 的上下文窗口，因为过滤逻辑是锁定的；而当 agent 自己编写过滤规则时，上下文就能保持精简，模型也能在长时间研究过程中始终保持方向感。

CVE 研究展示了差异

为了展示这一机制在真实世界中的效果，Perplexity 用一个混乱的网络安全任务进行了测试。一个 agent 必须追踪 2023 年到 2025 年间发布的 200 个高危软件漏洞（CVE）。对于每一个漏洞，它都需要找到官方厂商公告、受影响的软件，以及修复该漏洞的准确版本。新闻文章或博客帖子都不算。

借助 SaC，模型编写了一个三阶段脚本。它先并行搜索，并根据 Mozilla 或 Google 等特定厂商发布安全通告的格式进行定制。接着，它扫描自己的发现，找出缺口，并运行有针对性的后续查询。最后，它使用一个 schema 来验证 CVE、产品和修复版本是否全部对应一致。

这套方法奏效了。Perplexity 表示，该 agent 完成了任务，同时使用的 token 比其标准流水线少了 85%。而竞争系统正确获取的数据还不到四分之一。

Perplexity 声称，SaC 在五项基准中的四项上都击败了 OpenAI 的 Responses API 和 Anthropic 的 Managed Agents 等竞争对手。最大的差距出现在“WANDR”上，这是 Perplexity 自己用于广泛研究任务的基准测试，计划很快发布。当然，对这类自报基准应持保留态度，但与 Perplexity 旧架构的对比显示出性能上的显著、巨大飞跃。

AI 的代码即运行层

Perplexity 将 SaC 描述为更大趋势的一部分。传统软件依赖确定性指令。前沿模型则在 token 空间中加入推理能力。最强大的系统会把两者结合起来：模型负责策略，确定性运行时负责批处理和过滤，而搜索基础设施则作为 I/O 层。

Search as Code 目前正在 Perplexity Computer 和 Agent API 中逐步上线。

这项升级或许可以解决当前 AI 搜索中一个显而易见的问题。最近一项研究发现，流行的搜索代理在 BrowseComp 等基准上经常作弊。它们并不是扫描实时网页，而是直接从训练数据中提取答案，再用搜索去验证自己已经知道的内容。在一个包含新鲜事实的新基准上测试时，所有系统的得分都骤降了 25 到 40 分。但这些系统使用的都是标准搜索工具。

另一篇独立综述论文则指出，编写代码正逐渐成为代理与世界交互的默认方式。论文将代码描述为代理的新运行层，并认为工具、沙箱以及验证机制等周边基础设施正成为自主系统真正的瓶颈。

来源与参考

1. 原始链接
2. Perplexity's "Search as Code" lets AI models write their own search pipelines instead of calling fixed APIs