Perplexity的“搜尋即程式碼”讓AI模型編寫自己的搜尋管道，而非呼叫固定API

Perplexity在其新發布的“搜尋即程式碼”（Search as Code，簡稱SaC）架構中，讓AI模型不再呼叫現成的搜尋API，而是自行編寫Python程式碼來執行搜尋任務。該公司承諾，這一方式能帶來更精準的結果和更低的令牌消耗。

任何關注過AI代理處理複雜研究任務的人都見過相同的模式：模型編寫查詢，搜尋API返回結果列表，模型讀取結果，然後編寫下一個查詢。這一迴圈反覆進行，常常連續多次。Perplexity在一份新技術報告中稱此為瓶頸。如今的搜尋引擎是為人類設計的，它們希望獲得整潔的藍色連結列表，但對於試圖在幾分鐘內執行數百次搜尋的AI代理來說，這種設定過於僵化。代理只能調整搜尋詞，其他一切都是黑箱。

“搜尋即程式碼”改變了這一動態。模型不再呼叫API，而是編寫自定義Python指令碼來執行搜尋。指令碼在安全沙箱中執行，呼叫Perplexity的搜尋後端。檢索、過濾、去重和重排序等基本操作被打包成簡單的SDK函式。

該架構分為三層。頂層是模型，它理解任務並決定搜尋策略；中間層是沙箱，程式碼在其中執行；底層是“Agentic Search SDK”，它將Perplexity的搜尋引擎分解為獨立的、可組合的函式。標準搜尋API仍然保留用於簡單問題，但對於複雜的研究任務，模型可以深入得多。它可以發出並行查詢，以程式設計方式過濾掉噪聲，並只將相關命中結果拉入其上下文視窗。

據Perplexity稱，這就是優勢所在。標準搜尋管道會將代理的上下文視窗塞滿垃圾資訊，因為過濾邏輯是固定的。當代理自行編寫過濾器時，上下文保持精簡，模型在長時間的研究會話中也能保持方向感。

為展示實際效果，Perplexity在混亂的網路安全任務上測試了SaC。代理需要追蹤2023年至2025年間釋出的200個關鍵軟體漏洞（CVE）。對於每個漏洞，它需要找到官方供應商公告、受影響的軟體以及修復漏洞的確切版本。新聞文章或部落格帖子不計入。

使用SaC後，模型編寫了一個三階段指令碼。它執行針對特定供應商（如Mozilla或Google）格式化安全公告的並行搜尋。接下來，它掃描自己的發現，發現缺口，並執行有針對性的後續查詢。最後，它使用模式驗證CVE、產品和修復版本是否一致。

結果奏效了。Perplexity表示，代理在完成任務時比其標準管道少用了85%的令牌。競爭對手的系統正確率不到四分之一。

Perplexity聲稱SaC在五項基準測試中的四項上擊敗了OpenAI的Responses API和Anthropic的Managed Agents等競爭對手。最大的差距出現在“WANDR”上，這是Perplexity自己針對廣泛研究任務的基準，預計很快會發布。當然，自報的基準需要謹慎對待，但與Perplexity自身舊架構的對比顯示出了清晰且巨大的效能飛躍。

Perplexity將SaC視為更大趨勢的一部分。傳統軟體依賴確定性指令。前沿模型在令牌空間中新增推理。最強大的系統將兩者結合：模型負責策略，確定性執行時負責批處理和過濾，搜尋基礎設施作為輸入輸出層。

搜尋即程式碼現已整合到Perplexity Computer和Agent API中。

這一升級可能會解決當前AI搜尋的一個突出問題。最近一項研究發現，流行的搜尋代理經常在BrowseComp等基準測試中作弊。它們不是掃描即時網路，而是簡單地從訓練資料中提取答案，並使用搜尋來確認已知資訊。當在新基準測試中使用新事實進行測試時，每個系統的得分都下降了25到40個百分點。但這些系統都使用了標準搜尋工具。

另一篇獨立綜述論文表明，編寫程式碼正成為代理與世界互動的預設方式。它將程式碼描述為代理的新操作層，並指出工具、沙箱和驗證機制等周邊基礎設施正成為自主系統的真正瓶頸。