@yibie: Search as Code：搜索架构的下一次范式转移 Perplexity 刚刚发布了一个新架构，叫 Search as Code（SaC）。听起来像又一个营销术语，但读完他们的研究文章后，我认为这可能是 2026 年 AI 基础设施领…

Search as Code：搜索架构的下一次范式转移 Perplexity 刚刚发布了一个新架构，叫 Search as Code（SaC）。听起来像又一个营销术语，但读完他们的研究文章后，我认为这可能是 2026 年 AI 基础设施领域最重要的架构决策之一。 核心思想一句话：AI agent 不再通过 function calling 一次一次地调搜索 API，而是直接写 Python 代码来编排整个搜索流水线。 一、问题：function calling 是一种"串行瓶颈" 传统的 AI 搜索架构是这样的： 模型发出查询 → 搜索引擎跑预设 pipeline → 返回结果 → 模型消费结果 ↑_______________________________________________↓ 每次搜索操作 = 一次 LLM inference 往返 这个架构在"用户问一个问题，AI 搜一次"的时代够用。但当 agent 需要完成一个涉及数百次检索的复杂任务时，问题就暴露了。Perplexity 的 Computer 产品中，单个任务可以在几分钟内触发数百甚至数千次检索操作。 每次操作都需要一次 LLM 往返——这就是"串行瓶颈"。更具体地说，传统架构有三个致命缺陷： 粗粒度的上下文。 如果模型只需要一条高度精准的信息，但只能用"重召回"的搜索端点，结果就是大量无关信息被灌进 context window，既浪费 token 又稀释信号。 无法利用领域知识。 模型在训练数据、Agent Skill、记忆中可能知道该怎么搜——比如何时混合词汇和语义信号、优先哪些来源、怎么聚合结果。但传统搜索 API 只暴露查询参数，模型无法把这些知识付诸行动。 控制流低效 + 上下文污染。 很多搜索工作流不是线性的——需要 fan-out、并行、去重。用 serial function calls 来实现这些操作不仅慢，还把大量中间状态扔进了 model context，导致性能退化，被迫频繁 compaction。 二、SaC 的方案：代码替代 function calls Perplexity 的方案是彻底放弃 function calling 和 MCP 作为搜索接口。不是改进现有方案，而是换了一个完全不同的范式： 模型写 Python 代码 → 沙箱执行 → 代码直接调 Agentic Search SDK 的各个原子原语 ↓ 一次 LLM inference 可以编排上千次搜索操作 三层架构： 模型层（控制面）： 推理用户需求，分解任务，决定需要什么检索策略，生成 Python 代码来实现这些策略。 计算沙箱（执行层）： 提供安全的代码执行环境，处理控制流、批处理、重试、过滤、聚合等确定性操作。 Agentic Search SDK（原语层）： 把 Perplexity 的搜索栈拆解成可组合的原子原语——检索、排序、过滤、fan-out、渲染等。不是把一个搜索 API 打包成库，而是把整个搜索系统重新架构为模块化组件。 关键差异：在 SaC 中，模型不再调用搜索。模型编排搜索。 三、一个案例就够了：CVE 漏洞分析 Perplexity 在文章里给了一个具体的案例。任务：找 2023-2025 年间的 200+ 个高危 CVE，每个需要引用厂商自己的安全公告，包含受影响产品、修复版本，并证明修复版本与特定 CVE 相关。 SaC 的结果： - 准确率 100% - Token 消耗从 288.7K 降到 42.9K——减少 85.1% - 被测试的其他系统（OpenAI、Anthropic、Exa 等）准确率全部低于 25% 为什么差这么多？因为 SaC 让模型做了三件事，传统架构做不到： 把规则写进查询计划。 生成的代码直接编码了"只看厂商公告"的约束——NVD、MITRE、第三方聚合器被结构性排除在搜索之外。 用 LLM 做中间规划。 代码会先总结哪些厂商-年份组合产生了足够多的候选页面，请求针对性的查询优化，然后验证每条查询再执行。这不是 hardcode 的爬虫，而是 agent 在运行时通过代码定义的搜索策略。 用代码做结果验证。 搜索子程序找到了看似相关的页面，但任务要求"厂商原文中必须绑定一个 CVE + 一个受影响产品 + 一个修复版本"。代码显式定义了这个 schema，自动去重、拒绝聚合器 URL、丢弃弱版本证据，直到记录数达标。 四、基准测试：2.5 倍优势 Perplexity 在 5 个基准上对比了 SaC（用 GPT 5.5 high reasoning）和 OpenAI Responses API、Anthropic Managed Agents、Exa Agent、Parallel Tasks。 SaC 在 5 个基准中赢了 4 个。在最难的 WANDR 基准（模拟"广泛研究"类专业任务）上，SaC 的分数是第二名的 2.5 倍。 成本-性能前沿图更直观：SaC 的低推理设置比所有非 SaC 系统都便宜，同时性能不输；中等推理设置在 $1/任务以下超过了所有竞争对手。 五、三个更深层的洞察 1. "代码作为编排器 + 能力填充器" SaC 不只是用代码调用已有能力。当搜索栈或 SDK 没有某个函数的原生能力时，模型可以在沙箱中动态实现。比如一个复杂正则——如果没有原生支持，传统方案是发一个近似查询，在 token 空间中过滤噪声结果。SaC 的做法是并行调 SDK 收集超集，代码去重，然后写额外的 Python 精确过滤。代码同时担任了"编排已有能力"和"制造缺失能力"两个角色。 2. SDK 通过 autoresearch 自进化 Perplexity 没有手工设计 SDK。他们建了一个 autoresearch 循环，连续运行数周，自动提出和验证 SDK 改进——衡量延迟、代码生成质量、任务完成率。这个循环已经对 SDK 的结构和美学做了大量修改，在所有维度上都获得了显著收益。 这是 meta 层面的一个关键信号：构建 AI 原语的工具本身也需要是 AI 原生的。 3. Agent Skills 的精简设计 教模型使用定制 SDK 是个难题——SDK 不在预训练数据里。Perplexity 的方案是精心调校的 Agent Skills，根文件不到 2000 token。重点不是列出所有函数（模型可以通过 runtime reflection 获得），而是提供简洁的、可泛化的指南和少量示例，教模型如何组合这些原子原语。 六、这意味着什么 Search as Code 是"代码作为编排器"这一更大范式在搜索领域的具体落地。我们在之前的文章里讨论过 Claude Code 动态工作流如何用 JS 编排子 agent，今天 SaC 展示了同样的原则如何应用到搜索基础设施上。 共同的模式： | 旧范式 | 新范式 | |--------|--------| | 串行 function calls | 并行代码编排 | | 预设 pipeline | 运行时组装 | | LLM 调 API | LLM 写代码调原语 | | 上下文膨胀 | 中间状态留在沙箱 | | 人设计接口 | autoresearch 进化接口 | 每一个维度都指向同一个方向：AI agent 的下一步不是更好的 function calling，而是根本不再用 function calling。 参考来源：Perplexity Research, "Rethinking Search for Agents: Search as Code" (2026.06) Benchmark data: DSQA, BrowseComp, HLE, WideSearch, WANDR 字数统计：~2800 字