Perplexity 推出端側 Agent 框架 Computer：預設全本地執行，告別 API 計費

把自家商業機密和個人隱私一股腦餵給雲端 AI，這事正在讓很多企業和個人打退堂鼓。一方面是每敲一次回車都在燃燒的 API 賬單，另一方面是資料一旦離開裝置就再也管不住的合規風險。

Perplexity 給出了他們的解法：為 Perplexity Portable Computer 推出了一套名為 Computer 的本地優先智慧體系統。這套系統把模型、工作流排程框架、對話記錄和執行軌跡全部搬到了使用者本地裝置上。只有在需要聯網搜尋、呼叫聯結器或者請示雲端更聰明的高階模型時，才會經由使用者明確授權訪問外部網路。

別讓小模型背大模型的包袱

開源模型和端側硬體最近跑得極快。像 27B 引數的 Qwen 3.8、30B 的 NVIDIA Nemotron 3.5 Lightning，配合 NVIDIA DGX Spark 這樣的本地硬體，已經能在桌面上跑起來了。

問題在於，業界現有的開源 Agent 框架（比如 Pi 和 Hermes）原本都是給百億甚至千億級別的雲端旗艦模型設計的。這些框架假設模型可以輕鬆吞下幾十萬 tokens 的上下文，也能熟練排程複雜的工具樹。但一旦換成端側小模型，它們很容易在過載的資訊裡迷航。

Perplexity 的實測發現，像 Qwen 3.8 27B 這種模型標稱支援 260K 上下文，但實際跑到 100K 以上時效能就會明顯下滑。為此，他們把核心框架做了極致精簡：系統提示詞儘量壓小，只保留核心工具，其他能力拆分成獨立技能，隨用隨載入、用完就釋放，軌跡太長時自動壓縮上下文。

連日常用到的 Gmail、GitHub、Outlook 和 Google Calendar 這些聯結器，他們也放棄了極其消耗上下文的 MCP 協議定義，直接改寫成了輕量級的命令列工具。

安全策略上也更狠。Pi 和 Hermes 預設以使用者當前許可權直接跑指令碼，而 Computer 強制開啟作業系統級沙盒，嚴格限制程序、路徑和網路。一旦沙盒環境不可用，系統會直接停機拒絕執行，寧可罷工也不裸奔。

跑在 DGX Spark 上的戰績

在統一搭載 Qwen 3.8 27B 模型的 NVIDIA DGX Spark 上，Computer 與傳統開源框架拉開了顯著差距。

在 Perplexity 內部的 53 項本地知識工作基準測試中，Computer 拿到了 82.6% 的得分，超過了 Pi 的 77.6% 和 Hermes 的 74.0%。如果換上 Perplexity 自己基於該模型後訓練的 PPLX 27B，成績進一步升到了 85.4%。

而在 1266 項 BrowseComp 網頁研究任務中，Computer 憑藉接入 Perplexity 的 Search as Code 介面，跑出了 66.7% 的準確率，遠高於依賴 Brave 搜尋的 Pi（50.2%）和 Hermes（43.9%）。更誇張的是資源消耗：Computer 平均每項任務耗時 402.1 秒、消耗 85.2 萬 tokens，比起 Hermes 節省了 61% 的時間，比起 Pi 更是省掉了 70% 的 tokens。

針對 PDF、掃描件和圖表的 ParseBench-100 多模態測試同樣體現出端側處理的優勢。Computer 取得了 65.1% 的平均分，而 Hermes 只有 34.6%，Pi 僅有 13.9%。其中 Computer 在圖表理解上達到了 76.5%，不過版面佈局理解依然是所有框架的短板，最高也只有 16.2%。

為什麼重要

我們認為，Perplexity 這次展示的其實是個人計算的一個重要轉折點：不再把端側當成雲端的弱智簡化版，而是圍繞端側硬體與小模型的實際極限，重構整套軟體排程棧。

對使用者來說，這意味著那些涉及財務賬目、未公開程式碼和敏感合同的分析工作，終於可以在沒有隱私外洩風險、也不需要掐著計算器算 token 成本的前提下交給 AI 處理。雖然你可能需要先買一臺能跑動 27B 模型的硬體裝置，但後續的使用成本幾乎趨近於零。

這給整個 Agent 框架生態提了個醒。之前大家熱衷於通過標準化的 MCP 協議無休止地擴充外部工具庫，結果就是幾千個 token 的工具說明塞進去，端側小模型連任務目標都記不清了。Perplexity 把它改寫為命令列工具、動態裝卸技能的做法，看起來要務實得多。

當然隱患也不是沒有。目前版面佈局解析依然孱弱，複雜排版文件很難保證萬無一失；而且整套方案高度綁定了類似 DGX Spark 級別的高效能硬體，距離在普通輕薄筆記本上普及，中間顯然還隔著好幾代硬體迭代。