Perplexity「Search as Code」：让 AI 自己写搜索代码，Token 消耗暴降 85%

一句话结论：Perplexity 把搜索从「调 API」变成了「写代码」，同一道题 Token 砍掉 85%，同时把竞品按在地板上。

AI 摘要

• 工具定位：Perplexity 推出的新型 AI 搜索范式
• 最适合：需要多步、深度、广域搜索的研究类 Agent 任务
• 最大优点：CVE 安全研究任务 100% 准确率，Token 消耗下降 85%
• 最大限制：必须使用前沿模型，且沙箱执行带来 200-500 ms 延迟
• 智盒评分：9.2 / 10

工具信息

• 工具名：Search as Code（SaC）
• 官方网址：https://www.perplexity.ai
• 分类：AI 搜索 / Agent 基础设施
• 是否免费：否（仅限 Perplexity Computer 与 Agent API）
• 是否需要登录：是
• 价格：随订阅档位与 API 调用计费
• 最近核查日期：2026-06-08

一个 200 条 CVE 的任务，揭开了 AI 搜索的天花板

2026 年 6 月初，Perplexity 悄悄发布了一项新能力，叫「Search as Code」。名字很工程，听起来像又一个内部框架。但它做的事情，几乎是过去两年 AI 搜索范式的一次翻转。

研究团队给模型布置了一道题：检索 200 个 CVE（公开漏洞编号）相关的安全信息，按字段结构化输出。听起来不算太难，对吧？安全研究员天天干这事。

但结果是，绝大多数竞品栽了。

GPT、Claude、Gemini 在这道题上的准确率，全部低于 25%。也就是说，五个 CVE 错四个。Perplexity 用 Search as Code 做这一题，准确率 100%，同时 Token 消耗从 288.7 K 降到 42.9 K，整整少了 85%。

这不是单一指标的胜利。这是范式胜利。

Search as Code 到底是什么？和传统 AI 搜索有什么不同？

传统 AI 搜索的工作流，是这样的：模型判断需要什么信息 → 调一个固定 API（搜索、爬取、摘要）→ 拿到结果 → 再判断下一步。这个流程的最大问题，是 API 的粒度是「人」定的，不是「模型」定的。

Search as Code 走的是另一条路：让模型直接写 Python 代码来执行搜索。

模型在沙箱里运行代码，调用的是更底层的「搜索原语」（search primitives），比如 search、open、find。这些原语粒度更细，组合方式更多。模型可以自己决定：先并行查 10 个关键词、再用代码合并去重、按字段筛选、按时间排序、最后只输出指定结构。

Perplexity 在 5 项公开基准上跑了对比。结果是 4 项第一：

• DSQA：领先第二名 19.77 个百分点
• BrowseComp、WideSearch：显著领先
• WANDR：自建基准，SaC 得分 0.386，第二名 Anthropic 仅 0.152，2.5 倍优势
• 唯一没拿第一的是 HLE，仅落后 0.2 个百分点

为什么 AI 写代码比 AI 调 API 强这么多？

答案藏在 Perplexity 公开的 6 条设计原则里。这 6 条不是技术清单，是他们用大量实验跑出来的「必须这么做才有优势」的经验。

第一，Python 是事实上的运行时。把搜索能力暴露成 Python 函数，比暴露成 JSON Schema 强一个量级。模型对 Python 的理解力、对控制流（循环、条件、异常处理）的把控，远比「调用一个固定函数」要自然。

第二，搜索 SDK 必须持续自研。第三方搜索 API 是为人类设计的，粒度太粗，参数太固定。SaC 的搜索原语是 Perplexity 团队自己迭代的，每一次模型犯的错误都会被反哺进 SDK。

第三，文件系统 + 序列化。模型可以把中间结果写到沙箱文件系统，下一步再读。这听起来不起眼，但传统 API 调用里，每次都要把上下文塞回 prompt，Token 飞涨。

第四，Agent Skills 作为能力扩展。不是所有逻辑都要写进搜索原语里，有些任务专属能力（比如读 PDF、解析 CVE 字段）通过 Skills 注入。

第五，代码作为「缺口填充」。当现有工具和 API 不能直接回答问题时，模型可以写新代码来补这个缺口。这等于把「工具边界」变成了「模型创造力的边界」。

第六，降低抽象边界。每多一层抽象，就多一次信息损失。SaC 把搜索抽象层级压到最低，让模型「看到」的就是真实的执行环境。

实测体验：哪些场景 SaC 真的能打？

我们重点看了三类场景的可用性。

1. 多步、广域、需要结构化的研究任务

典型例子：搜集某行业过去三年的所有并购事件，按公司、时间、金额、地区整理成表。这类任务在 ChatGPT、Gemini、传统 Perplexity 上都跑得磕磕绊绊。SaC 在 WANDR 基准上的领先，几乎就是为这种场景设计的。

2. 安全研究 / 漏洞情报

200 CVE 那道题就是典型。SaC 不仅能查到 CVE 编号本身，还能根据字段（CVSS 分数、影响产品、修复版本）动态决定查询路径，最后输出标准化的结构。

3. 学术综述 / 跨库检索

跨 arXiv、PubMed、Semantic Scholar 做文献综述，需要模型灵活决定「先查谁、再查谁、怎么去重、怎么排序」。SaC 的沙箱 + 文件系统能力，让这种「渐进式信息收集」成为可能。

反过来，下面几类场景 SaC 没有显著优势：

• 单步、简单的问答（直接问 Perplexity 搜索就够）
• 实时性要求极高、低延迟要求的场景（沙箱执行增加 200-500 ms）
• 没有前沿模型（GPT 5.5 / Claude Opus 4.5）支撑的环境

局限和代价：SaC 不是银弹

任何新范式都有它的代价。SaC 也不例外。

第一，模型门槛。SaC 的能力高度依赖底层模型的代码生成与推理能力。根据 Perplexity 自家测试，能跑出好效果的基本只有 GPT 5.5 和 Claude Opus 4.5 这一档。小模型跑不动。

第二，沙箱延迟。每次代码执行都要进沙箱，相比直接调 API 多 200-500 ms。对于「快问快答」型用户，这个延迟会被明显感知到。

第三，成本结构。Token 消耗降了 85% 看起来很美，但沙箱本身的算力开销、SDK 自研成本是隐形的。Perplexity 没单独披露 SaC 的整体毛利率，这部分成本最终会反映在 Agent API 的定价上。

第四，调试复杂度。当模型写出来的搜索代码有 bug，排查链路比「调一个 API 失败」要长得多。普通用户基本没能力自己 debug。

适合谁 / 不适合谁

适合

• 安全研究员、漏洞情报团队：CVE、威胁情报类任务的标准工作流
• 学术研究者、综述写作者：跨库、跨时间、跨字段的结构化检索
• 企业 AI Agent 团队：需要把「搜索」嵌入到多步业务流里的开发者
• 数据 / 投研分析师：广域研究 + 结构化输出的典型用户

不适合

• 普通用户的日常问答：直接用 Perplexity 搜索或 ChatGPT 搜索更划算
• 追求极致低延迟的产品：200-500 ms 沙箱开销不可忽视
• 小模型 / 开源模型部署方：跑不动 SaC 的代码生成需求
• 没有工程能力的普通用户：调 API 难度的产品，理解「模型写代码」就更难

和同类方案对比

常见问题（FAQ）

Search as Code 是免费的吗？

不是。它目前只在 Perplexity Computer 和 Agent API 中可用，订阅 Perplexity Pro / Max 或者按 API 调用计费。普通免费用户暂时用不到。

我需要 GPT 5.5 或 Claude Opus 4.5 才能用 SaC 吗？

在 Perplexity 的产品里，SaC 是封装好的能力，你不需要自己选模型。但如果你想在自己代码里复现 SaC 的范式，确实需要前沿模型的代码生成能力，否则效果会大打折扣。

沙箱延迟 200-500 ms 在哪些场景能接受？

在研究类、综述类、批量采集类任务里完全可以接受，这些任务单步就要几秒到几十秒。但在对话式搜索、即时问答里，这个延迟会被明显感知。

SaC 会不会取代传统搜索 API？

短期内不会。它是「搜索范式」的一个补充，不是替代品。简单问答、即时搜索，传统 API 仍然更快更便宜。SaC 的真正价值在于打开了「多步 + 广域 + 结构化」这个新场景。