Proma 把 Agent 的上下文拆成了项目、会话和子会话三层

Proma 要解决的是上下文组织问题，不是模型接入问题

接模型这件事今天已经很廉价了。任何一个客户端都能填一个 API Key，然后开始对话。Proma 的 README 把重点放在别处：它反复讲的是「更智能的前提是更好的上下文，我们的核心工作就是帮助你组织更好的上下文」。这句话决定了整个产品的形态。

它面向的是 README 里所说的「专业用户」和「Agent 重度用户」。这两个词在文中不是修辞，而是有具体所指：需要并行做深度研究、需要对抗性检查、需要基于 worktree 开发、需要把知识沉淀进 Obsidian 的人。如果你一天只问 Agent 三五个问题，Proma 提供的项目分区、记忆文件、子会话这些结构，你一个都用不上。

反过来，如果你的问题是「上下文被污染了」「上个会话的东西这个会话不知道」「同一批 Skills 在十个项目里互相干扰」，那 Proma 的功能列表基本是逐条冲着这些来的。它的功能密度很高：Chat、Agent、计划模式、项目分区、记忆、内嵌浏览器、内嵌终端、定时任务、探索、子会话、Skills/MCP/CLI、远程链接（微信、飞书、钉钉、Slack）、文件预览编辑。这份清单本身不构成推荐，但能说明它想覆盖的工作面有多宽。

三层上下文：项目文件夹、AGENTS.md 与 MEMORY.md

Proma 的上下文模型可以拆成三层，README 对每一层都给了明确的载体。

最外层是项目。你可以新建项目，也可以直接在已经存在的文件夹下创建项目。项目下面挂项目文件和会话。README 的建议是，一类工作对应一个项目。

中间层是项目级的约束文件 AGENTS.md。README 说每个项目会有一个自己的 AGENTS.md，「核心是约束整个项目下 Agent 的表现」，包括引导项目文件的分布、交互规则、必备信息、需要遵守的约定。这是给 Agent 看的项目说明书，不是给人看的文档。

再往里是记忆，索引文件是 MEMORY.md，README 说「MEMORY.md 是整个记忆的索引，下面更多的部分是具体类目下的记忆」。注意这里的措辞：索引加类目，意味着记忆不是一坨文本，而是有分层的。

最内层是会话。一个会话只处理一个具体的小任务，会话有自己的文件夹，你拖进输入框的一切都会进入会话文件夹。README 明确说任务拆分仍然是使用者的核心工作，工具不替你做这件事。

这套分层有一个直接后果：上下文是你要手动喂养的。README 甚至给了一句可以直接照抄的提示词，建议你新开会话对 Agent 说：「请帮我形成当前项目下的 AGENTS.md 文件，并探索最近半个月或者一个月的会话来形成一些关于我和项目的记忆。」这句话透露出一个前提，就是如果你不主动做这件事，记忆层会一直是空的。

子会话与探索模式：两种不同的上下文隔离策略

这两个功能很容易被混为一谈，但 README 把它们讲成了两件事，差别值得说清楚。

子会话解决的是并行和隔离。README 把它描述为「类似 SubAgent 的概念，但比 SubAgent 具备更干净的上文、可持续迭代的会话级交付」。典型用法是主会话负责主线，子会话负责深度研究或对抗性检查，甚至「连续的主会话修复 & 子会话持续审核」。它是一个可以长期存在、反复交互的环境，不是一次性的调用。

探索模式解决的是分支污染。README 的原话是「是探索，而不是分叉」。触发方式是在 Agent 输出结束后点击探索按钮，然后你可以创建无限多个分支，这些分支能利用前序上下文。关键在于回收路径：点探索右上角的「带回到主会话」，所有探索结果回到主线继续。README 给的理由是，这样你「无需担心自己拿捏不定的判断或边缘的问题影响到主会话的上下文」。

这个区分是有意义的。子会话是结构化的、可复用的工作单元；探索是一次性的发散，用完就合并或丢弃。如果你把两者当成同一个东西用，探索会变成子会话，你就失去了「不污染主线」这个唯一的好处。

需要说明的是，README 没有给出这两种模式的 token 开销、并发上限或性能数据。它只说了「拥有更自由的模型选择和更好的性能」，这句话没有可验证的基准支撑，读者应当把它当作设计意图而非实测结论。

按项目切分 Skills 和 MCP 是取舍，不是优点

Proma 支持 Skills、MCP 和 CLI 三种扩展方式，README 说内嵌了一些必要的 Skills，并支持常见 MCP 和 CLI 的一键安装。

真正值得注意的是它的切分策略。README 写道，Skills 和 MCP 在 Proma 里都是分项目的，理由是「过多的 Skills 和 MCP 也会导致 Agent 能力的下降，按项目区分可以更好的精简这类上下文」。

这个判断本身是合理的，工具描述会占用上下文预算，装得越多，模型在选工具时的判断越容易出错。但 README 紧接着自己承认了代价：「缺点是需要人本身的关注更多」。这句话很诚实，也应该被认真对待。按项目切分意味着每建一个新项目，你都要重新决定这个项目需要哪些 Skills 和 MCP。项目多起来之后，这是一项持续的维护工作，而不是一次性的配置。

README 还给了另一条建议，认为最好的 Skills 不来自互联网和他人，而是来自你的真实场景：先手把手带 Agent 做一次真实流程，再让它沉淀成 Skill，然后在使用中迭代。这个路径的产出质量取决于你投入的次数，第一次沉淀出来的 Skill 大概率是不完整的。

另外，团队级的 Skills 分发与共享属于商业版能力。开源版的 Skills 是工作区本地能力，README 明确说团队内分发与共享需自行组织。

下载与安装：开源版和商业版的真实分界

开源版的获取路径是 GitHub Releases。README 列出的平台覆盖是：macOS Apple Silicon、macOS Intel、Windows、Ubuntu/Debian x86_64 的 .deb 安装包，以及 Linux x86_64 AppImage。Linux 的安装、安全边界和支持范围，README 指向了 docs/linux.md，这份文档没有出现在提供的材料里，所以具体内容无法确认。

商业版在 proma.cool/download 提供。README 里有一条对迁移很关键的说明：「开源版本用户可直接下载商业版覆盖安装即可，数据均会被保留和继承」。表格里也重复了这一点，从开源版切到商业版是覆盖安装，继续使用已有的本地 Proma 数据。这意味着两条路径共用同一套本地数据格式，迁移成本接近于零。

两个版本的分界不只是价格。开源版需要自行添加和管理 AI 供应商渠道与 API Key，联网和内嵌 AI 能力也要按需自行配置搜索、生图等服务及其 API Key。商业版登录后可用官方内置模型渠道，同时仍可自行配置第三方渠道，另外提供 Proma Cloud 的 WebSearch、GPT Image 2 生图和编辑，以及可设额度上限的 Proma Cloud API Key。

README 对开源版有一句很直接的表态：「由于我们的能力和时间太过有限，被迫只能选择降低开源版的功能更新和迭代节奏，更专注开发商业版本。」这句话应该被当作选型时的硬约束来读，而不是客套话。

什么时候 Proma 是错的工具

第一个明确的不适用场景是团队协作。README 的对比表写得很清楚：团队额度管理在开源版里「需自行搭建成员、额度分配与用量管理机制」，Skills 的团队分发与共享则是企业版能力。如果你选 Proma 是为了让一个团队共享 Agent 能力和额度，开源版不提供这条路径，你得自己造。

第二个是供应链信任问题。开源版使用第三方供应商或中转站时，README 要求你「自行评估供应商的安全、协议兼容与稳定性」，并提示中转站存在额外的信任与数据处理风险。这不是 Proma 的缺陷，而是自配渠道的固有代价，但它意味着开源版把一部分安全责任转移给了使用者。

第三个是维护节奏。README 已经预告开源版的功能更新和迭代节奏会低于商业版。如果你的工作流依赖某个具体功能持续跟进上游模型变化，这个节奏差会变成实际问题。

第四个是配置负担本身。项目分区、AGENTS.md、MEMORY.md、按项目切分的 Skills 和 MCP，这些机制只有在被持续维护时才产生价值。README 自己承认按项目切分「需要人本身的关注更多」。如果没有人愿意承担这份关注，这套结构会退化成空文件夹和空索引。

还有一个更基础的判断：Proma 是桌面客户端，不是可以嵌进你自己服务里的库或 SDK。README 里提到的对外 API 能力（创建 Proma Cloud API Key，把 LLM、工具和多模态能力接入自己的应用）属于商业版，开源版「主要使用你自行配置的供应商 API」。如果你要的是把 Agent 能力集成进自己的后端，Proma 的形态本身就不对。

和通用聊天客户端相比，差别在状态放在哪里

拿一个常见的对照物来说：大多数桌面 LLM 客户端把状态放在会话里。一个会话就是一串消息，换一个会话就是从零开始，跨会话的连续性靠你自己复制粘贴。项目、记忆、Skills 这些概念要么不存在，要么是一个全局设置面板。

Proma 把状态上移了。项目文件夹承载文件和 AGENTS.md，MEMORY.md 承载跨会话的记忆索引，Skills 和 MCP 按项目挂载，会话退化成一次性的小任务容器。这个差别的实际影响是：在前一种客户端里，你的资产是聊天记录；在 Proma 里，你的资产是项目文件夹里的那些 markdown 文件。前者换工具就丢了，后者是纯文本，理论上可以带走。

代价也很直接。前一种客户端你打开就能用，后一种你需要先想清楚项目怎么分、AGENTS.md 写什么、哪些记忆值得沉淀。README 里那句「任务本身的分割仍然是几天 Agent 使用者的核心工作」，说的就是这件事：Proma 没有把任务拆分自动化，它只是给了你放拆分结果的地方。

另外要提一下内嵌浏览器和终端。README 强调这两个是「可以允许 Agent 直接登录并使用的可见终端和浏览器」，可见性是重点，你能看到 Agent 在浏览器里点了什么。README 同时承认「我们对完整的浏览器功能的开发可能也完全不足」。这是一句坦白的自我评价，如果你需要的是成熟的浏览器自动化能力，这里可能不是终点。

许可、维护成本与需要自己核实的事

Proma 的许可是 AGPL-3.0。这是一个网络 copyleft 许可，对分发和通过网络提供服务这两种情形都有条款约束。提供的材料里只有许可标识符，没有 LICENSE 全文，也没有任何关于商业使用、修改后分发、二次分发的说明。所以这里只能指出边界，不能给出结论：如果你打算基于 Proma 的代码做衍生作品，或者把它作为网络服务对外提供，必须先读仓库里的 LICENSE 文件原文，必要时咨询法务。本文不构成法律意见。

维护成本方面，能从材料里确认的有几点。版本节奏很快，最近三个发布是 v0.19.31、v0.19.37、v0.19.52，集中在 2026 年 9 月 5 日到 9 月 9 日之间，说明迭代频繁。README 明确说开源版的更新和修复只保证「必要的更新和修复」，商业版才有「更快的更新节奏」。这构成一个实际的维护预期差。

升级路径本身不复杂，开源版从 GitHub Releases 下载安装包，商业版覆盖安装且保留数据。但如果你在开源版里自配了供应商渠道，升级后是否需要重新配置，README 没有说明。

最后列出几件材料无法回答、需要你自己验证的事：docs/linux.md 里的具体安全边界和支持范围；AGENTS.md 和 MEMORY.md 是否有格式规范或长度限制；探索模式创建「无限多个分叉」时是否有实际的资源上限；子会话与主会话并行运行时模型调用的计费方式。这些都不在 README 的覆盖范围内，不要假设它们有默认答案。

编辑结论

Proma 适合已经在高频使用 Agent、并且愿意主动维护上下文结构的专业用户，尤其是需要并行研究、对抗性检查、worktree 开发这一类专业场景的人。如果你只是想找一个开箱即用、不想管理项目分区和记忆文件的聊天客户端，Proma 的这套设计反而会增加你的负担，因为 README 自己就承认按项目切分 Skills 和 MCP「需要人本身的关注更多」。不建议在无法接受 AGPL-3.0 条款的环境里直接采用，README 没有说明商用边界之外的具体义务，这部分要自己核对 LICENSE 全文再决定。上手前先确认三件事：你的平台在不在发布列表里（macOS Apple Silicon、macOS Intel、Windows、Ubuntu/Debian x86_64 的 .deb、Linux x86_64 AppImage）；你打算用开源版自配供应商渠道，还是走商业版的 Proma Cloud 托管链路；以及你能否接受 README 明说的「被迫只能选择降低开源版的功能更新和迭代节奏」。

官方来源

1. License: AGPL-3.0
2. Project website
3. proma-ai/Proma on GitHub
4. README
5. Releases