Proma 2026 Q2-Q3 想法开源：勇敢地解决真实的问题

感谢大家的积极贡献以及所有的 Proma 用户，截止 2026.05.21 我们已经更新到 v0.9.40 版本，也即将获得到 1K 的 start，开源地址：https://github.com/ErlichLiu/Proma

Proma 发展到今天，我突然意识到今天市场上的产品太多的被各种层面的东西裹挟，尤其是被资本，我过去是很难理解这段话的，完全不懂为什么，直到 Proma 走到今天，我身边也全是不同阶段的开发者后，我才开始理解。从大的开刀，我认为 Claude、Codex 这些巨头做的产品完全“德不配位”，实在是太粗糙太差了，并且没有解决真正重要的问题，甚至连重要的问题的讨论都看不到，这就是资本和政治本身的裹挟。而 Claude 和 Codex 之所以还能存活并受到赞誉完全得益于人类本身对于生态位的一种自然顺应的结果。（我想 Proma 已经在最近通过 DeepSeek 证明了很多非共识的观点了）

除此之外，还有非常多的产品，任何比较知名的拿了投资的产品都存在这类问题，我们就不展开讲了。正因如此，Proma 有了一个非常有利的展位和低姿态，这非常有利于我们自己的发展，这也是 Proma 为什么坚持不拿投资的原因。

我们的核心目标是解决一些真正的问题，勇敢地解决这些真实的问题，而不是创造一个被过度吹嘘和过度消费的产品。 Hi 大家好，我是 Proma 的开发者 Erlich，时间过得很快，上次开源我们的思考还是在 2 月份，这次我们尽可能表达清楚，时间会覆盖大概 Q2 到 Q3 的一些思考和想要实现的功能，以及这些功能背后的一些关联。当然，最主要的是跟大家一起同步一份相对完整的上下文和来龙去脉，这样既可以给所有现在的 Proma 用户一份大概率可以实现的还不错的预期，也可以给我们一起协同的开发者一个方向，促进大家一起讨论和分布贡献。

最近两个季度的大方向

所有的功能归结起来就只有三个方向:

• Proactive：主动性，但是我们不打算做的太激进，会采用很简单的架构和方案，让真实的用户在使用时能感知到，而不是像 OpenClaw 或者 Hermes 一样很难持续迭代持续有效的帮助用户，一会我们会展开讲这个部分的设计以及我们的思考。
• 个人的注意力：Proma 以及众多 Agent 都是支持并行的，甚至是无头运行的，如果你真的并行做过比较重要的工作，那么大概注意力上限就是操作三个 Agent ，至少我自己的上限差不多就是 Human In the Loop 可以在三个不同的任务里流转，并且很累，我们希望能解决一些人类天然的注意力的问题，不是彻底解决，就是好用那么一点，丝滑顺畅一点，更符合认知一点。
• 团队协作：这个是最重要的部分，比起 Agent Teams，真实环境里的团队协作的价值更大也更难做，全是稀碎的小问题的叠加，比如 Skills 的分发，重要文件的同步，不同的业务里会有很多不同的要求，我们会尽可能简化这些部分，先让最小可执行的版本真正投入到用户的工作环境里。

为什么是这三个大方向？

我想这三个大的方向应该也是共识，但显然我们的描述和预期都是不性感的，这个可能需要跟大家解释一下。

首先是 Proma 正在面对的是非常真实的工作场景和非常真实的用户，我们自己也知道我们自己的痛点和自己想解决的问题，而这些问题本身就是不那么性感的，但是很真实，解决了一点点都会让用户的爽感和效率倍增。我们吹牛说 Proma 是要为大家做到 100x 生产力提升的，我觉得做完这一轮之后至少是 1-2 个数量级级别的效率提升了，而这些提升本身就必须要涵盖对人的注意力、意愿度以及执行阻力等问题的解决。

其次是 Proma 不需要也不想拿投资，所以我们完全不需要给自己一个远超现在的叙事风格，更不需要因此欺骗自己或者假装可行。

所以本次开源的想法的主体叫勇敢地解决真实的问题。

是因为任何那投资的人都不敢说我们这种话，这对他们来说意味着崩塌。他们宁可去做自己根本无法实现的东西，也不愿意以降低估值可能性为代价解决真实存在的问题，并且真实的问题是最难解决的，因为真实很好衡量。解决真实的问题反倒对非常多（不是全部）的拿投资创业的团队来说是最困难的。

也因此，这些简单（并非容易）的，肉眼可见的真实问题却没人做，Claude、Codex 都没尝试去做。再加上 Proma 对自己的定位，反倒 Proma 拥有了一个非常好的低身位来踏实的解决这些问题，这非常有利于 Proma 的发展。

这个部分就不过多赘述了，大家会在 Proma 真实的发展过程和在其他产品的发展过程里逐步体会到我提到的这些。

关于 Proactive

Proactive 简单翻译就是 Agent 需要表现出来主动性，主动也会分方向、分主动的程度以及通过什么样的方式来实现主动，这就是这一章节会讨论到的。

我们尝试从原理上先来大概讲讲。首先机器全部都是被动的，没有主动的，所谓的主动是因为设置了一些触发条件，在 Proactive 里这种主动条件最常见的就是心跳机制和定时器，也就是定时来根据一些上下文为用户提供建议或者执行一些工作。

那么接下来需要关心的问题就是 Proactive 当中的“源”应该怎么来呢？主动终归是有一个所“基于”的东西对吧，这个“基于/源”本身首先是用户的信息，然后通过 Agent 的某种偏好的推理之后，变成一种可以关注的任务，然后再通过定时或者心跳的方式触发 Agent 的消费行为来反馈给用户。所以这至少是个三层的行为，每一层都有自己的上下文以及处理的偏好，不能说这很难做，而是自由度太高，会导致很多超过用户真实需求的主动性存在。

在 Proactive 里又会涉及到很多与记忆相关的部分，因为要依赖这个做上下文的判断，以及用户很多时候也希望有一种模糊的需求希望能通过记忆来解决。同样的，记忆也很难做，首先是这个词的定义，因为它太以人为本了，我们都不知道记忆是如何运作的，比较确定的很小一部分其实是“关联搜索”能力，也就是今天的各种各样根据语义触发的 RAG 的延伸。

Proma 打算做的不是这里的比较宽泛的，因为确实太容易做烂了，而且这个部分用户执行的成本会很高。最明显的有效的 Proactive 首先是让 Agent 对用户有个非常基本的了解就够了，也就是提示词的拼接，我们可以定义一些非常简短有效的 User profile schema，比如用户的职业、最近正在做的事、正在做的事的大概水平、用户的交互偏好和必须要记住的很少的信息，大概几百字以内就可以全部搞定，依此作为上下文，Agent 在回复偏好上借助模型自己的推理能力就可以做得还不错了，这是第一步。（当然，这里也没那么简单，比如我们可能还会引入这些记忆和偏好的触发率，比较低的触发率意味着意义不大，需要根据跟用户持续沟通的时候继续积攒和迭代，这个部分也是很长期的工作）

第二步是我们继续拆解那些最优效的“记忆”，当我们需要记忆的时候，其实对应的场景就出来了，对应的功能和能力也就出来了。比如我们前面提到的“关联搜索”，这就是最基本的大家对记忆的期待，但这种东西在严肃的工作场景里适用度还很存疑，在严肃的工作流场景里，大部分的应该被记住的东西 Proma 更偏向于通过我们内置的 Skills Proma Coach 来引导用户或者 Agent 存储到文档，流程化的内容也会被主动识别转换成 Skills，这样绝大部分的严肃的需求都会直接解决掉，而不是依赖模糊和仅有关联搜索的“记忆”，这个的要求是我们要不断的迭代我们的 Proma Coach 这个内置的 Skills。

记忆部分结束，我们可以暂时先把这一点工作做完。接下来 Proactive 最能影响用户体验的，可能是帮助用户提高他们使用 Proma 的能力，这个部分也是通过 Proma Coach 来实现，会不断匹配一些最佳实践的建议之类的。

再继续下去就是比较硬的 Proactive 的能力了，我称之可持续自迭代的自动化。比如用户经常提到希望我们能做个定时任务的功能，但今天无论是 Claude 还是 Codex 做的定时任务都很拉跨，只是一个具备定时启动的简短的上下文而已，非常的半成品。实际场景里可能能用得起来的定时任务一定是能自己迭代自己的，可以根据用户 + 自己执行的反馈来优化提示词、优化 Skills 等等。Proma 的自动/定时任务的目标不是帮助用户每天早上抓取 xx 新闻或者再顺手发个小红书。Proma 实际上是可以根据最近用户工作的历史，来提炼出来哪些是 Proma 可以跟用户再简单协作一下，就能帮助用户创建的自动化任务，比如以我们自己的开发为例，我们最希望的是能定时检查一下我们的服务器状况、不同服务的状态以及帮助我们做一下自动的各种费用的 Audit。再更进一步，我们理论上应该也可以做到 Proma 可以主动研究一下 Proma 提出改进意见，收集群里的用户信息，可以自动解决一些用户反馈的小 Bug；再继续探索一点的话，理论上也完全可以实现比如 Proma 发现自己的很多研究是有通用价值的，可以在我的一定的辅助之下，自己给自己创建一个网站或者 github 社区，来实现比较简单的自动化运营，这完全有可能，这里比较难的是对普通用户而言很难意识到以及配置完整的工作环境，这才是真实的难题。

关于主动性我们大概就先谈这么多，大家对这个部分感兴趣，就可以先从最基础的部分开始构建，我鼓励大家自己构建自己独立的版本，构建完成后可以通过写长文的方式来梳理自己的逻辑并提供 Demo 供大家测试和改进。

关于个人注意力

这又是一个很大的话题，也来尝试讲讲 Proma 对这个部分的理解。首先是源于我个人，我经常会同时打开几个 Proma 的 Tab 来完成不同的工作，除非是非常短平快一两次交互就可以解决掉的问题，不然我其实可以并行处理的任务并不多，大概也就 3 个左右，并且会很累。

这种累其实核心在两个点上，一个是并行任务带来的非常多的上下文切换认知，这在过去的工作模式里是不太成立的，大家的工作进度因为没那么快，并且很多内容是通过逐渐学习+实践来解决的，认知压力其实是会经历一个先上升再平缓下降的过程，因为这个阶段性的工作会随着知识和技能的掌握逐渐变得更加确信。但是 Agent 任务上会很不一样，大家开始逐渐挑战自己不太懂的部分，会持续面临新的知识、信息的叠加，并且很可能持续没有机会去彻底掌握和学会，人会逐渐完全切换到 Vibe 的状态，人们当然会自己调整，但是产品上或许我们也可以做点工作，尤其是在不同的上下文切换的过程里。

我能想到的一个比较好的点是利用现有的用户习惯，来采集有效的上下文。比如我的工作里会用到很多滴答清单以及日程，这些都是非常高质量的必要的上下文输入。那么是否有可能 Proma 也引入我们自己的“滴答清单”，无需功能全面，而是更多偏向于让用户输入这种高质量上下文之后，Agent 就可以开始帮助他工作或者做一些整理之类的工作；然后再进一步就是如果更多的 Agent 在运行的话，那么更好的人跟 Agent 的协作可能是类似看板的东西，所以共性就出现了，因为 Todo 软件和看板的设计理念和形式都比较相似，所以大概率 Proma 也会往这个方向去靠一靠试试看解决的怎么样。这里也会涉及到团队协作的部分的思考，我一会来聊。

谈到具体怎么做，我还是先来抛砖引玉一下。首先我们不追求所谓的 Agent Teams，也就是不追求 Agent 之间大规模的协作，我觉得暂时还没到这个阶段，因为这对上下文管理能力的要求太高了，我们需要匹配对应强悍的上下文管理能力 + 管理方法，我们先等等这块的发展。

具体做法大概是会采用 mailbox 的设计。比如可能我们会在 Proma 里开辟一个 UI 专门做 Todo 以及看板，还有各种 Agent 主动提出来的一些需要人类确认的工作或者可能性，这块未来也会逐渐跟我们前面讨论的 Proactive 的部分关联起来，但大家可以不必想的很困难，可以先随便做（这是最好的最可能创新的时刻）。

关于 Todo 部分的做法也会很直觉，我们还是会先有个界面，这就会涉及到一些任务的主动分类，任务的可能情况下跟工作区的关联，任务本身是否适合 Agent 主动去做，任务当前缺少的必要的上下文，这些都是 Todo 环节的 Agent 实例在考虑的，这个部分的 Agent 我们可以试试看 PI 之类的，作为一种探索；一旦这个工作是适合 Agent 去做的，那么就可以向 mailbox 发送一个记录，我们会有个单独的排队的 Agent Session 在做分配（这个部分也可以 PI）来驱动在不同的工作区下生成提示词和创建 Session 开始工作，并在需要人类授权或者完成任务时再次发送消息回到 mailbox 来等待做指挥的 Agent 处理或者反馈给人。这样我们就可以逐渐通过我们自己的真实的工作环境实现我们自己的 Todo 以及 Agent 更主动的完成任务的协作，这个过程里可能也会设计特定的 Skills 和工具的自迭代。

然后看板就会出现，运行中的状态你可以说这是 Todo 或者看板，关于看板的核心是可见性以及相似和逻辑顺序归纳，可见性很好解决，可以跳转到我们现在的 Session 里看到运行状态就可以；相似和逻辑归纳可能需要测试一下，也就是不同的任务是如何排列，使得人类可以更好的关注；更进一步则是帮助人来沉淀这些工作的思考知识和路径。

这个部分就是 https://github.com/SheldonLiu0412/Proma_Proactive 做的做梦功能的各种变体，我们之前提到的 Proactive 的功能也有很多部分是依赖这类功能的。

这是这个部分目前的一些大概的思考和偏好的技术路径。

关于团队协作

关于团队协作，这可能是最重要的一个部分。挑重点来讲的话，我觉得比较重要的是：大的上下文背景同步的能力、Skills 的同步能力、Todo 之间的协同、工作区和会话文件的共享、相互间 Agent 可访问性这几个方向的能力。

首先第一个是大的上下文的能力，比如一个团队大家在做一份工作，那么就需要对这个工作本身有个大的上下文，但这个很难定义到底包含什么合适，我们可能会偏向于做出来类似前面提到的最简化有效的 User Profile 的能力即可，依旧是被调用统计+可迭代。这样就可以依赖大模型自己的推理能力来实现一定的上下文优化效果。

Skills 的同步不必多说，重点是在同步方案，比如依赖局域网或者某种 WebDev 或者我们自建一个可托管的后端服务，剩下的就是架构上的团队之间的许可、同步、版本管理、提交修改权限，这些搭配我们的 Proma Coach Skills 来一起实现的更好就可以了，不难，但是工作量也很多。

Todo 之间的协同这个部分可能要讲讲，以 Proma 自己为例，我们很多时候其实是不知道其他开发者或者成员在做什么的，即便我们都在滴答清单的共享组里，即便大家写了自己要做的 Todo，我很多时候仍然是不知道的。因为 Todo 本身是一种巨大的上下文压缩，而我如果不花费比较大的力气去解读和解压缩，我光看一两句话是不知道在做什么的。但是我们都基于一个项目在工作，这天然是个大的全面的上下文，Agent 可以帮助我更好的理解，同时也可以更好的发现不同层面的关联，给我解释的同时给我一些推荐或者预警或者协作要求。这可能才是更好的 AI 时代的办公协同。

然后是工作区和会话文件的共享，这个部分跟 Skills 是一样的，属于显而易见的需求，但是做好不容易，跟 Skills 同步会采用一样的方案和基础架构，剩下的就是细节的和对场景的把握了，这个等做到这个部分有了更具象的想象或者实践了再谈。

Agent 之间的可访问性也比较重要，像是一些细碎的工作，如果别人可以调用你的 Proma 来做确认，就会比较省事。但我对这个部分的思考也比较少，似乎大家还都停在所谓的协议层面，还没有真实的通用的场景在做这些工作，所以这个部分我们也是做到了这个部分再详细聊，我们可以持续补全或者分支这个文档。

最后

在 Proma 的整个成长过程里，我觉得收益最大的两个点，第一是敢想，也就是不被过去的方式限制住，譬如 Claude 或者 OpenAI 的产品就是顶级的，无懈可击的，我们无法做到的，实际上完全不是这样，他们做的东西也很一般，即便是在有如此巨大的资源的情况下，利用好想法、可以执行、相对较高的资源利用效率变得更重要。Instagram 时代已经充分证明了每个人的价值上限可以做的非常高，Agent 时代应该会比这个的上限还可以高几十倍，只是也很难而已。

今天的（2026 年 5 月） Claude 或者 OpenAI 在产品上完全不领先，其他产品也没什么领先的，甚至如果你看 Agent 的发展，两个月前投资人们还在追着鼓吹 OpenClaw、一个月前他们鼓吹自己复杂化理论过后的 Harness，这些都极度愚蠢，Agent 在这两个月里什么都没发生，没任何新东西，已经某种程度上到了一种瓶颈期了，这才是刚刚好的 Agent 应用端开始的时间段，并且这个世界需要一个正常的产品以正常的方式来运作，来更迭掉旧的世界。

任何伟大有成效的产品，都起于籍籍无名，而吾辈的世界才刚展开。

Proma 开发者 Erlich 2026 年 5 月 22 日