Perplexity 于 2026 年 10 月 12 日在官方工程博客中披露，Perplexity Computer 里已经上线的 Projects 功能，底层不是普通的共享文件夹，而是一套专门为人机协作搭建的 Git 仓库系统：每一个 Project 都对应一个 Git 仓库，用户的多个智能体、定时运行的智能体和其他协作者的智能体，共同往同一个仓库里提交修改。这篇博客没有发布新模型，讲的却是智能体真正开始长期干活之后绕不开的问题——成果存在哪、谁改了什么、改错了怎么退回去。
为什么偏偏选了 Git
Perplexity 给出的理由很实际。长达数月的协作需要三件事：成果要能跨会话留存，不能随沙箱销毁而消失；多人多智能体同时修改时不能互相覆盖；每一次变更都要可查、可回滚。这三件事恰好是 Git 几十年来一直在解决的问题。不同之处在于，传统代码托管平台是为人设计的，评审界面、分支管理和通知对智能体都是多余的。Perplexity 因此只保留 Git 的存储与校验能力：智能体提交时不走人工审批，而是由 Git 服务按仓库契约做机械检查，通过才成为最新版本；两个智能体撞车时，后提交的一方会收到基于旧版本的明确拒绝信号，自己把改动重放到新版本上再提交。官方称，生产环境中这类被拒提交不到 2%，提交延迟中位数低于 1.7 秒，99 分位低于 8 秒。
五个部件如何分工
整套系统由五部分组成。每个智能体在独立沙箱里工作，沙箱内的命令行工具负责把仓库同步到本地、把成果按有意义的工作单元逐次提交；控制面只负责定位仓库和发放短期凭证，不碰数据本身；Git 服务执行克隆、拉取和接收提交等原生操作，并决定哪一次提交成为最新版本，状态记录在 DynamoDB 中；仓库数据实际存放在 AWS S3Files 提供的共享文件系统上，副本因此可以无状态替换；提交被接受后，后台程序会从新增文档中抽取文本和元数据，供智能体下次打开项目时直接检索。为了省流量，沙箱不会一上来就下载整个仓库：大文件先以 Git LFS 指针形式出现，智能体先看抽取好的文本，确有必要才下载原文件。Perplexity 还提到，他们试过用 FUSE 虚拟文件系统，在文件密集型任务上慢了约 400 倍，最终放弃。仓库历史也不会无限膨胀，提交数超过阈值后，旧历史会被合并成一个起始快照，只保留最近若干次提交。
检索效果与这件事的边界
官方给出的内部测试颇能说明这种设计的取向：在 150 道基于同一文档库的金融问题上，用文件探索方式答题的智能体，找对文档的得分为 0.867，答对的得分为 0.627；对照的语义检索约为 0.39 和 0.37，答题得分约有 1.7 倍差距，延迟还低约 25%。已经打开过的项目再次接入约需 2.9 秒，冷启动约 8 秒。Computer 的长期记忆功能 Brain 也建在同一套仓库设施上，知识页同样以提交形式保存，只是与项目文件分仓存放，互不抢写。需要提醒的是，这些数字全部来自 Perplexity 自测，没有第三方复现，测试语料也由其自选，现阶段只能当作设计自证，不能当作行业结论。但方向本身值得注意：当智能体从一次性问答走向数月尺度的协作，竞争点正在从模型本身移向工作区的持久性与可审计性。Perplexity 的选择相当于承认，几十年前为人类协作发明的版本控制，可能是智能体协作最快能借用的地基——谁先把这层地基做稳，谁的智能体就更敢接长任务。
