Perplexity Projects：面向AI代理的Git式文件系统

当AI代理从单次对话走向长期协作，一个核心问题浮出水面：代理之间的工作成果如何积累、共享和延续？Perplexity团队在其Projects功能中给出了一种答案——把文件系统打造成面向代理的Git仓库。

核心设计：代理的Git Forge

Perplexity Projects的后端文件系统并非传统意义上的存储方案，而是被设计为一个"Git forge"——一个专门服务于代理协作的代码托管平台。据Perplexity团队在社交平台上的介绍，每个代理在独立的沙箱环境中工作，并将成果提交到一个共享仓库中。这意味着代理的产出不是散落在各处的临时文件，而是像代码提交一样被版本化、可追溯。

这个设计的巧妙之处在于借鉴了软件开发中经过验证的协作模式。开发者早已习惯通过Git进行分布式协作，每个贡献者在本地分支工作，然后合并到主仓库。Perplexity将这一范式移植到AI代理场景，让代理成为"贡献者"，而非孤立的工具调用。

Git forge 是指基于 Git 协议构建的代码托管与协作平台，典型代表包括 GitHub、GitLab 和 Gitea。它的核心能力远不止存储代码，而是围绕版本控制提供分支管理、提交历史、代码审查、合并请求、权限控制等一整套协作机制。将文件系统称为“Git forge”，意味着它不只是被动地保存文件，而是主动地为代理提供类似开发者社区的协作基础设施：每次产出都被视为一次提交，带有时间戳、作者标识和变更记录，从而可追溯、可回滚、可分支实验。对 AI 代理而言，这相当于给它们配备了一个共享的“工作日志本”和“版本保险箱”，使代理之间的协作从临时消息传递升级为持久化、结构化的工程实践。

沙箱隔离与共享仓库的平衡

系统采用了"沙箱隔离+共享仓库"的双层结构。每个代理拥有自己的沙箱，确保运行时的安全性和独立性——代理在执行任务时不会干扰其他代理的工作环境。但同时，代理的产出会提交到共享仓库，使得人类用户和其他代理都能在此基础上继续构建。

这种架构解决了一个关键矛盾：代理需要隔离以保证安全，但又需要共享以实现协作。传统的多代理系统往往在两者之间难以兼顾——要么完全隔离导致信息孤岛，要么完全共享带来安全风险。Perplexity的方案通过"提交"这一动作实现了受控的信息流动。

沙箱（Sandbox） 是一种安全隔离机制，通过限制进程可访问的资源（如文件系统、网络、系统调用）来防止代码或代理行为对宿主环境造成破坏。在多代理系统中，每个代理运行在独立的沙箱里，意味着即使某个代理执行了错误或恶意的操作，影响范围也被限制在其自身容器内，不会波及其他代理或底层系统。这与共享仓库形成互补：沙箱保障了运行时的安全边界，而共享仓库则通过显式的“提交”动作，让经过筛选的成果进入公共空间。这种设计借鉴了操作系统中的进程隔离思想，也呼应了微服务架构中“隔离故障、共享数据”的原则，从而在安全与协作之间取得动态平衡。

跨会话工作流的突破

更值得关注的是跨会话（across sessions）的能力。传统AI对话的一个根本限制是"会话边界"——每次对话结束后，上下文消失，工作成果难以延续。Perplexity Projects通过文件系统层面的持久化，让代理的工作可以跨越多次交互持续积累。

对于需要多步骤、长时间完成的任务，这一能力至关重要。例如，一个代理在第一次会话中生成了数据分析脚本，第二次会话中另一个代理可以基于该脚本继续工作，而不必从头开始。文件系统成为了代理之间的"共同记忆"。

会话边界（Session Boundary） 是传统对话式 AI 的一个根本限制：每次交互被视为独立的会话，结束后上下文窗口清空，模型无法自动记住或延续之前的工作。这导致多步骤任务难以持续推进，用户往往需要反复粘贴历史信息。Perplexity Projects 通过文件系统层面的持久化突破了这一边界——代理的产出被写入共享仓库，形成独立于会话的“外部记忆”。后续会话中的代理可以读取这些文件，从而恢复工作状态。这种机制类似于给 AI 代理配备了长期存储，让它们能够像人类开发者一样，通过代码仓库而非对话历史来延续项目，极大提升了长时间跨度任务的可行性和效率。

对AI协作范式的启示

Perplexity的这一实践指向了一个更大的趋势：AI代理正在从"单兵作战"转向"团队协作"。当代理能够像软件工程师一样提交代码、查看历史、基于他人工作继续开发时，它们的生产力将被显著放大。

这种模式也带来了新的可能性——人类和代理可以在同一个仓库中协作。人类用户可以看到代理的提交记录，理解其工作逻辑；代理也可以基于人类的修改继续迭代。这种人机混合协作的工作流，或许是未来AI原生应用的标准形态。

从技术实现角度看，将文件系统抽象为Git forge需要对存储、版本控制、权限管理等多个层面进行重新设计。Perplexity选择公开分享这一架构思路，也为整个行业提供了一个值得参考的样本。对于正在构建多代理系统的团队而言，这种"沙箱+共享仓库"的模式值得深入研究。