Perplexity 新架构：Search as Code

⏰ 时效声明：本课内容整理自原文发布时（2026-06-02）对 Perplexity Research 文章的解读，架构细节与基准数字截至原文发布时。

2026 年 6 月，Perplexity 发布了一个新架构，叫 Search as Code（SaC，搜索即代码）。@yibie 的解读标题很冲：AI agent 的下一步不是更好的 function calling，而是根本不再用 function calling。

什么意思？以前 agent 想搜索，要调一个"搜索函数"；SaC 里，模型直接写 Python 代码来编排整个搜索流水线。搜索从"调接口"变成了"写程序"。

以下来自 @yibie 对 Perplexity Research 文章的转述。传统搜索 agent 长这样：每次搜索操作 = 一次 LLM 推理往返——模型说"搜一下"，等结果回来，再说"再搜一下"，串行等待。

Perplexity 自己的数据：Computer 单任务几分钟内可触发数百甚至数千次检索。按旧架构，每次检索都要一次 LLM 往返——三大缺陷：

① 上下文粗粒度：每次往返都把大坨上下文搬来搬去，token 烧得飞快。② 无法利用领域知识：搜索策略写死在提示词里，换个领域就失灵。③ 控制流低效 + 上下文污染：中间结果全塞回给模型，真正有用的信号被淹没。

一句话：旧架构下，搜索次数越多，LLM 往返越多，账单越贵、速度越慢、质量越差——三输。

以下来自 @yibie。SaC 分三层：

模型层（控制面）：模型不再调搜索函数，而是写 Python 代码——"先并行搜这 20 个关键词，过滤掉 2023 年前的，把剩下的按相关性排序，聚合去重"。

计算沙箱（执行层）：代码在这里跑，负责批处理、重试、过滤、聚合。中间状态留在沙箱里，不回传给模型——这是省 token 的关键。

Agentic Search SDK（原语层）：提供检索、排序、过滤、fan-out（扇出并行）、渲染等原子原语，是模型写代码时的"积木块"。

效果：一次 LLM 推理，可以编排上千次搜索操作。LLM 只负责"出主意"，脏活累活全在沙箱里批量干完。

以下来自 @yibie。Perplexity 用了一个硬核案例验证 SaC：200+ 个高危 CVE（2023–2025），任务要求每个 CVE 必须绑定厂商公告原文 + 受影响产品 + 修复版本——错一个都不行。

结果：SaC 准确率 100%，token 从 288.7K 降到 42.9K（-85.1%）；而其他系统（OpenAI、Anthropic、Exa 的方案）准确率全部低于 25%。

为什么差距这么大？CVE 任务的特点是"海量检索 + 严格核对"：旧架构下每次检索都要 LLM 往返，上下文被污染后模型开始"编答案"；SaC 把"搜"和"核对"写成代码在沙箱里跑，模型只看最终聚合结果——又准又便宜。

以下来自 @yibie，均为 Perplexity 自报。5 个基准（DSQA、BrowseComp、HLE、WideSearch、WANDR）赢了 4 个；最难的 WANDR 上，成绩是第二名的 2.5 倍。

成本-性能前沿：低推理设置的 SaC，比所有非 SaC 系统都便宜，性能还不输；中等推理设置下，每个任务不到 1 美元，超过所有对手。

一句话：SaC 不是"用更多钱换更好效果"，而是把成本曲线和性能曲线同时往好的方向推——便宜和强兼得。

以下来自 @yibie 的总结，值得单独记：

洞察 ①：代码既是编排器，也是能力填充器。SDK 里缺某个原语？模型现场写一个补上——代码的表达能力兜底了一切。

洞察 ②：SDK 会自己进化。Perplexity 用 autoresearch 循环让 SDK 自我改进，连跑数周——工具链自己卷自己。

洞察 ③：Skill 文件要小，靠运行时反射。Agent Skills 的根文件不到 2000 token，不靠枚举所有函数，而靠 runtime reflection（运行时反射）——用的时候再去看有什么可用。轻装上阵。

这三条放在一起看：未来的 agent 架构可能是——小而聪明的控制面 + 会自己进化的工具层 + 批量执行的沙箱。这与第 04 课"过程进 harness"、第 02 课"批量前置"是同一个大方向。