当大部分AI产品还在纠结怎么让模型稳定地走完一长串函数调用时，Perplexity甩出了一个看上去相当激进的方案：别调函数了，直接写代码。他们最新发布的Search as Code搜索架构，跳出了传统Agent逐个触发工具的循环模式，让模型一次性生成Python脚本调用整套搜索栈。简单，但有效。这不是一次小修小补，而是搜索接口设计范式的根本转向——尤其对正在堆叠MCP工具链的开发者来说，值得停下来认真想一想。
Search as Code到底改了什么
传统Agent搜索的痛点，做过的人都知道。每一次搜索意图都要被拆成若干个独立函数调用：先查天气、再查新闻、最后整合。模型得在每一步停下来等结果，再决定下一步调什么。链条越长，token烧得越快，延迟也越难看。Perplexity的新架构干脆把这条路堵死了——或者说，铺了一条新路。
从函数调用到代码生成
核心变化只有一句话：模型不再是逐个触发搜索API，而是直接写出一段Python代码，调用Perplexity底层的搜索栈来完成整个查询任务。代码生成替代了线性函数链，模型在一次输出里就能完成多步编排。官方博客用了"编写Python代码调用我们的搜索栈"这个表述，意思就是：把搜索能力当成Python函数库来用，而不是当成一组需要逐个调用的远程端点。
Token和延迟的账
这套设计最直接的红利体现在两个指标上。第一个是token消耗——原本每个函数调用都要在上下文里塞入工具描述、参数说明、返回结果，现在一次性写完代码就能跑完整个流程，中间产物不污染主对话上下文。第二个是延迟，并行调用变得天然可行，模型在写代码阶段就把依赖关系理清楚，搜索栈内部并行执行，而不是串行等待。对实时性要求高的场景，这笔账算下来差距非常明显。
Agent API背后的产品逻辑
功能上线只是表面动作，更值得拆解的是Perplexity为什么在这个时间点做这件事，以及它和现有产品矩阵是什么关系。
Computer的默认搜索栈
Search as Code已经成为Perplexity旗下Computer产品的默认配置。Computer是他们面向复杂任务场景的Agent产品，这次直接把搜索底座换成代码生成方案，意味着Perplexity内部对这个架构的稳定性已经有了相当强的信心。毕竟默认配置出问题，影响的是所有Computer用户。对外部API开发者来说，这倒是个好消息——你用的搜索能力和内部产品同源，至少不用担心被喂一个实验性feature。
为什么是现在
近半年Agent生态的演化速度明显加快。MCP协议在推、各种工具调用框架在卷，但大家都在"如何让模型更好地调用工具"这个维度上内卷。Perplexity选择换一条赛道——既然工具调用是问题本身，那就把问题抽象层级抬高一档。代码本身就是一种更强大的工具描述语言，变量、循环、条件分支全是现成的，模型早就擅长。拿自己擅长的东西解决问题，比强迫模型去学一套新的调用协议要顺滑得多。这背后还有一层LLM训练数据的考量：互联网上Python代码的海量语料，让模型写代码的能力远比稳定输出结构化函数调用要靠谱。
对开发者的实际意义
写法和调用的范式转移
如果你正在用Perplexity的Agent API，迁移到Search as Code基本没有门槛。官方文档里演示了典型写法：模型输出一段Python脚本，调用类似search.search()、search.finder()这样的方法获取结果，然后继续在代码里完成数据处理。整个过程不再需要管理一堆tool call的中间状态，调试时直接看代码就行。这对习惯写代码的工程师来说相当友好——可读性、可调试性、可复用性，这三件事一下都回来了。
不是万能解，边界要清楚
不过也别把这套架构吹上天。代码生成有它的适用场景，也有明显的边界。当任务明确、步骤可枚举时，Search as Code能发挥最大价值；但当任务本身模糊、需要模型边探索边决策时，逐个函数调用的灵活性反而更高。另外，代码生成要求底层搜索栈能被Python语义完整表达，这倒逼搜索API的设计也要跟着调整——未来Agent工具的设计语言，可能都会往"可被代码调用"这个方向靠。Perplexity这次的更新某种程度上给整个行业打了个样：Agent架构的下一站，未必是更复杂的协议，而是更朴素的代码。
