Perplexity 披露 Projects 底层文件系统：以共享 Git 仓库作 agent 协作底座，各 agent 跑在临时沙箱并用 grep 取代语义检索

Perplexity 于当地时间 10 月 12 日在官方 X 账号，并同步发布工程博客，公开其 Projects 功能底层文件系统的设计：每个项目背后是一个 Git 仓库，agent 在各自的临时沙箱里工作，把成果以提交（commit）写入共享仓库，人和其他 agent 跨会话在其上继续构建。博客署名 Perplexity Engineering，落款 10 月 12 日；Projects 是 Perplexity 近期推出的功能，让人和 agent 在 Perplexity Computer 中共同处理长期任务。

帖文串给出的核心数字来自一组内部基准：在 150 道针对单份金融文档的问题上，agent 用 grep 与标准文件工具检索文件再作答，答案准确率 0.627，作为对照的语义检索约 0.37（）。这些数字与整套架构描述均为 Perplexity 单方披露的内部口径，截至发稿未经独立验证。

（本文配图均取自 Perplexity 官方帖文串）

forge 留下托管与权限，去掉 PR 评审

博客把这套文件系统要解决的问题归纳为三条：持久性，工作要在任何一次 agent 会话或沙箱结束之后留存，供后续会话或其他协作者接着做；并发性，同一项目里多名用户各自的多个 agent 并行编辑，推进同一个共享状态而不是互相覆盖；可追溯性，人与 agent 都能查历史，确认自上次会话以来谁改了什么，需要时回滚。帖文串的出发点与此相同：长期协作的 agent 面对的是工程师共享代码库时的老问题。

Git 本身提供原子多文件提交、作者信息与可查询历史。Git forge（托管 Git 仓库、控制更新权限并附加协作功能的服务）通常还会加上 PR 评审；Perplexity 保留前两件事，把评审换成提交时对仓库契约的校验。博客说得直接：“PR 没有必要，因为没有人类逐笔审查每个改动。”契约内容包括限制仓库体积、PDF 与图片等大文件走 Git LFS（Git 的大文件存储扩展）而非原始 blob、用压缩机制控制历史长度；验收步骤据此做机械检查，确认每笔被接受的提交都是有效的仓库状态。

整个设施由五个组件服务：CLI 在沙箱内维护本地检出、同步更新并提交 agent 的改动；控制平面（control plane）定位仓库并发放短生命周期凭证；Git service 执行 Git 操作、决定哪笔提交成为最新被接受的提交；AWS S3 支撑的存储持久保存仓库数据；下游处理从已保存的文档中抽取文本等信息，供 agent 加载或刷新项目时使用。沙箱请求先经 agent proxy 检查访问权限，才到达 Git 服务。

提交只认最新 head，落败者重放后重交

并发控制的核心，只用三句话讲完：CLI 持有短生命周期锁，把提交串行化；Git 服务只接受基于 head（最新被接受提交）的提交；不满足，agent 就在新 head 上重放改动、重新提交。博客补上了生产环境的数字：在这套同步步骤下，被当作过期基点（stale-base）拒绝的提交不到 2%，提交延迟中位数低于 1.7 秒，p99（第 99 百分位延迟）低于 8 秒。

官方图解把流程拆开：agent A 与 B 都从 H0 检出，A 的提交被接受、head 前进到 H1；B 基于旧基点的提交被拒，取回 H1、重放生成新提交，再次提交后 head 前进到 H2。图解把落败方的重放标注为“机械操作、不做判断”（Mechanical, no judgment）。

每笔被接受的改动同时写入 outbox——一条列出仓库、新提交、操作者与被改路径的日志，解析器等下游服务从这份日志领取新工作。提交多了还有压缩（compaction）机制：保留的提交数超过阈值时，Git 服务把更早的历史折成一个起始快照，最近的提交用新标识符重放，文件内容保持不变。

仓库落在 S3，沙箱用完即弃

agent 跑在 Perplexity 自研的沙箱平台 SPACE 上，每个 agent 独占一个沙箱；沙箱是临时的，崩溃只损失未提交的工作（）。仓库数据不在沙箱里，而在 AWS S3Files 暴露的存储上——它把 S3 支撑的存储变成普通文件系统，原版 Git 无需改造就能直接使用；仓库以裸库（bare repository）形式放在共享文件系统上，只存对象与引用，不含工作检出，存储与计算就此解耦。

被否掉的替代方案同样写进了博客。给每个项目一个常驻沙箱，意味着计算绑定在一台机器上、按最忙时段备容量，还要保持数月健康并管理备份与恢复。用 FUSE（把存储实现为虚拟挂载文件系统的方案）做虚拟文件系统也试过：在重文件操作负载上比本地文件慢约 400 倍，因为每个请求都要一次网络往返；它还通常要求宿主机给特权能力，等于每个 agent 都得跑在特权沙箱里。

控制平面把每个仓库分配到一个存储单元（cell）——自成隔离的一块存储配一组 Git 服务副本——它只负责定位仓库、发放临时凭证，不读写仓库数据。单元内的副本共享同一文件系统，因此可以做成无状态：任何副本都能服务单元里的任何仓库，替换或增减副本不需要搬数据。

沙箱里有真实检出，检索靠列目录、grep 和读段落

agent 的检索是一个循环：列目录、用 grep 搜文件内容、读相关段落，再根据读到的东西决定下一步去哪看。帖文串点出这套做法的前提：每个沙箱保有真实检出，agent 因此用 grep 与标准文件工具检索，而不依赖宽泛的语义搜索。检索由一个单独的探索 agent 在有限预算内完成，返回文件路径和佐证摘录；答题模型读选出的文件，生成答案。博客称 Search 与 Computer 一样通过标准文件工具完成检索。

仓库也不必整仓下载：CLI 惰性物化，PDF、图片等大文件经 Git LFS 存成只记真实大小的指针文件，agent 凭文件名与大小决定值不值得下载。文档先读解析文本——解析流水线从变更队列领任务、按提交元数据找出被改文件、抽取文本与元数据；解析结果存在仓库之外、按源文档哈希索引，通过检出与同步进入沙箱里的保留目录，只有文本不够用时（比如要看图表、版式或内嵌数据）才下载原件。复用已有项目沙箱也省时间：挂上温检出约 2.9 秒，冷启动约 8 秒。

同一套设施还承载 Computer 的持久记忆：Perplexity Brain（Computer 的知识维基）把知识页存进各有历史与策略的知识仓库，后台 agent 把更新存为提交，其他 agent 用普通文件工具读取，人也可以直接编辑。

内部基准：答案分约为语义检索的 1.7 倍，检索分约为其 2 倍

基准设定在博客里只有一段：同一语料上、150 道针对单份文档的金融问题，把探索式 agent 与建好索引的语义检索对跑。按 Perplexity 的口径，探索 agent 检索到正确文档得分 0.867、答对问题得分 0.627，语义检索两项约 0.39 与 0.37；答案分约为语义检索的 1.7 倍，检索分约为其 2 倍，延迟约低 25%。博客还称探索 agent 主要处理抽取文本，很少下载原始 PDF。

这组数字是 Perplexity 自建自评的内部结果：博客正文只交代题量与语料一致性等设定，未给出数据集、基线实现或评分细节，外部无法据此复核。

工程师的第一波回复：同一行冲突怎么办

首帖发出约 6 小时后（北京时间 13 日 8 时许），页面显示约 4.1 万次浏览、243 个赞、35 条回复。回复里有认同：“把 agent 的产出当作提交来对待，这个想法很好，而且很少有 agent 工具处理这一点”（X 用户 Som Dutt，）；也有直接的不安：“agent 们直接往 main 上提交，成了我的新噩梦”（）。

至少 6 条回复在追问同一件事：两个 agent 改到同一文件、甚至同几行时怎么办。的问题很具体：“单一串行 head 意味着两个 agent 改同一段落就得排队。如果两边的改动碰到同几行，怎么合并？”博客把落败方的重放描述为机械步骤；在无人逐笔审查的设计下，重放撞上同一行时如何处理，六条帖文与博客正文都没有说明。

参考链接

@perplexity_ai 帖文串首帖（2026-10-12）：
Perplexity 工程博客《Building shared workspaces for people and agents》（2026-10-12）：
帖文串第四帖·提交串行化与 head 校验：
帖文串第五帖·S3 存储与临时沙箱：
帖文串第六帖·grep 检索与内部基准：
@som_dutt_ 回复：
@ItsGoharr 回复：
@AIToolSeekers 回复：
官方配图一（架构总览，帖文首图）：
官方配图二（并发提交与 head 校验图解）：
官方配图三（沙箱与存储对比图解）：
官方配图四（内部基准柱状图）：