DeepClaude额度查询 | 充值文章联系我
生图工具
nano banana 生图4o 生图

Proma 2026 Q1 想法开源：没有大跃进，一切皆可能

Proma 开源版本目前已经更新到了 v0.4.18 版本，已经做完最基础的版本了，非常感谢大家的贡献和参与。

在正式开始描述想法之前，我想再简单聊点关于设想和开发以及 VibeCoding 的相关的想法。我逐渐意识到，在今天开发任何一种 Agent ，是否能够完成以及花费多长时间完成似乎变成了一种思维上的限制而不是实际实现上的限制，这也是 VibeCoding 带来的技术上的变化。Proma 最核心的部分包含 Chat 和 Agent 两个模式其实都是 VibeCoding 的，并且只花费了大概 2 天的时间。当然，在开发之前我做过了三到四遍各种基于 Claude Agent SDK 的应用，当然这首先基于我有一些经验和相关的知识和思考。然后我花费了大概一周的时间拖延和逃避，我认为我无法两周内完成开源，我想好了各种合理的理由来解释我为什么没有实现。剩下的 3-5 天的时间我则是边逃避、抵触边研究优秀的项目，比如 Craft Agent OSS 是如何设计核心事件的等，最终实际上只花费了 2 个白天和一整个通宵在给自己定的 DDL 前几分钟完成了。

我也想借此提醒我自己，这或许是一种很普遍的现象，当一种技术成熟到超过我预想的能力，我反倒开始自我限制使用这种技术。当然，最终核心仍然是我们需要有对应的思考、偏好、审美、知识，花费更多的时间去习得和训练这些是必要的，构建的时间则会极大幅度的缩短，只要你具备前面的基础，剩下的更多的是思维上的开放和勇敢的尝试能带来巨大的回报。

各位共勉。

接下来正式来聊聊目前阶段对 Proma 的一些想法。主要是分为两个部分，仍然可能是区分 Chat 模式和 Agent 模式，但是这两个模式背后假设的用户场景和基于场景的继续推演是很不一样的。当然，这一切的一切都是基于目前的认知的假设和偏好，可能过完 2026 年的第一季度就会有很大的不同，这几乎是一定的，到时候我们再谈，甚至最理想的假设是今天谈到的一切都实现了，基于这些我们再谈。

关于 Chat 和 Agent 模式的核心区别

我并不想走向完全的 Agent 模式，首先开发成本上并不会多很多，因为今天有 VibeCoding 和开源社区的支持；其次是 Chat 模式对我来说更多的承载是非常简单（不是容易）的人为主导的和主观想要参与的各种行为，比如了解概念、学习某个技能、完成简单的事情，这个部分更多的是留给人的，满足人的好奇心、学习的欲望、更多的去发挥人的主观能动性的。

Agent 模式的则更多的是交给 AI 的，帮助人完成更长程的工作、在适度的情况下请求人的介入以及从机器理性的角度帮助人完成探索和反馈。

关于 Chat 模式接下来想要做的

  • 无限上下文模式，这一点要实现，但可能也需要借助 Agent 来完成的更好，至少目前最简单的是先实现基于特定格式和结构的信息压缩来实现无限上下文。
  • 简单的工具支持，引入一些简单的工具，比如搜索供应商 Tavily API 、比如 NanoBanana 生图、SeedDance 生成视频等工具的包装和对应的供应商的配置等。
  • 系统提示词管理和根据对话匹配的工作，类似Cherry Studio 的助手角色的功能，确实目前有一部分的用户是需要这个功能的。
  • 更好的 PDF 等文档处理策略，目前只是提取文本，但是 Claude、OpenAI 以及 Gemini 本身都知识 PDF 的 base64 格式的上传，这样对于有图片等格式的文档要更友好，但这些供应商对文档的长度都有限制。
  • 全局记忆功能，该功能可能偶尔也需要 Claude Agent SDK 的参与才能做好，这个部分我们在 Agent 环节里也会提到。
  • 主动识别复杂多步骤或探索性任务，给用户提议切换到 Agent 模式，并自动携带上下文。比如很多用户现在是直接给 Chat 模式发送 Excel 表做数据分析，这个场景一次对话处理肯定不好也不准，并且还需要用户操作，如果提议用户到 Agent 模式，Agent 会先跟用户确认需求，然后多步骤执行甚至写代码来完成各种分析。

关于 Agent 接下来想要做的

Agent 模式接下来的工作主要分为三个大部分，比较抽象。我会尝试用场景描述的方式来讲述。

继续优化和抽象事件

Proma Agent 是基于 Claude Agent SDK 的，Claude Agent SDK 输出的是数据流，我们需要把数据流转换成合适的事件，这样会提高整体的稳定性。但是 Proma 目前抽象的事件还不够，比如 AskUserQuestion 这种事件就可以更好的渲染出来，让用户有更简单的交互，这个部分抽象做的很好的依然是 Craft Agent OSS 这个项目，非常推荐参考。还需要继续探索 Claude Agent SDK 是否也可以实现对应的 Agent Teams 的功能，如果可以实现，可能我们整体的交互渲染和可视性都需要更改；如果不能实现，那么我们会通过下方的多 Agent 驱动的方式来实现。

权限

目前 Proma Agent 全部采用 passby 的方案，也就是用户不需要允许就会自动开始执行命令或者编辑文件的。我们需要实现 Claude Code 一样的权限管理操作，因为这样的话才能实现让比较谨慎的工作也可以交给 Agent 去做，Human In The Loop 会更明显，人更及时的处理 Agent 反馈，可以把一份工作做得更好更快。这个部分做的很好的也依然是 Craft Agent OSS 这个项目，本身项目也是开源的，我们需要先研究然后对照实现即可。

资源链接与分享

Agent 的运行在很多时候之所以运行的好，是因为有合适的资源介入，这些资源包括 Skills、MCP 以及外部 API 等，那么如何暴露这些给 Agent，并让 Agent 能充分通过这些资源来完成探索就是非常重要的一件事。

除此之外，这些资源包括创建和发现（目前 Proma 已经完成了通过对话的方式来发现和安装）、Agent 主动去发现和安装（当然要配合权限模式）。举个例子，很多用户的工作是依赖飞书生态或者其他生态的，Agent 是否可以主动来判断或者询问用户的依赖，并能引导用户创建飞书的文档访问 api，然后实现自动将完成的工作写回到飞书呢？并且自动保存飞书操作这个 Skills 或者 MCP 或者单纯的工具 Tool；这就会涉及到最重要的目前在主流 Agent 设计里经常会被忽略的部分 —— 自动保存自己常用的工具，同样比如用户在当前的工作区里经常做的工作是数据分析，Agent 可能会通过写代码的方式连接用户输入的数据获取 api ，这时候 Agent 应该能实现把这个 api 固化为一个下次可以自动暴露的工具，当然也可以是让 Agent 写成 Skills 或者 MCP 运行到本地，这个具体取决于真正开发阶段的思考和对场景以及方案的判断。

当前面这一步完成，那么一定会出现一些用的很棒的用户，那么如何帮助这些用户把他们的经验分享出去，甚至把他们的工具设定和组合销售掉也是个很好的方向。本质是这些用得很棒的 Pro C 带来的是更先进的生产方式和生产力，类似买铲子一样。这一点是我们在做飞书多维表格插件的时候发现的，有很多营销人员可以通过在飞书创建多维表格+提示词模板+模型选择器来服务他们的用户的特定需求。所以 Proma 也是一样会有这样的需求在。

工作区或者其他组织方式

Proma Agent 目前受限于 Claude Agent SDK 必须要依赖某个文件夹工作，这就会带来一个问题，要求用户以工作区的方式来工作。但用户真的需要这样工作吗？以及是否可以引导用户比较顺畅的完成依赖工作区的模式来工作呢？这个部分也需要一定的探索。

多 Agent 相互驱动

接下来最核心的部分就是多 Agent 驱动，原理是后台会实例化多个 Claude Agent SDK。比如我们前面提到的全局记忆的功能可能需要 Agent 参与才能做得好，那么可能就会有个专门的 Claude Agent SDK，会接受到主 Agent SDK （类似用户的管家的角色）的指挥会定时的重新整理全局记忆，并以合适的方式对外暴露给 Chat 模式和 Agent 模式；

多 Agent 互动也需要对应的可视化；

多 Agent 实例的方式可能也会出现在监督和自我驱动完成一件事上。比如用户要完成一项调研工作，目前的方式是在 Agent 模式下用户输入一个调研需求，Agent 会自动完成，如果出错了就会停止，如果我们采用三级 Agent 设计，主 Agent 负责接收具体事务管理的 Agent 回报决定是否去继续做，事务管理 Agent 会驱动真正做事的工作，并对工作进行监督和审查，并提供合适的工具和启发，这理论上应该也是可行的。

在这种模式下，我们就可以实现很多过去不敢想象的模式。比如我们在 DeepClaude 的项目上发现所有用量很大的用户背后其实都有一个特定的工作流和场景，并且基本都是成立的，因此才会产生大量的持续的消耗。那么是否继续假设，是否意味着这些工作流和场景本身 Proma Agent 可以根据实际的用户的对话，来假设猜测，主动跟用户生成一个 App，并 Pin 在 Proma 里或者独立呈现呢？也就是整个开发过程都不需要用户参与了，并且 Proma Agent 来负责更新和维护。我们之前提到的帮助用户销售他们的先进生产力，也可以通过这个方式实现，这样可以不对外暴露用户的核心 Skills 和 API 等机密。

还可以假设一种场景，我也非常想实现。比如我日常因为事情比较多，我会大量依赖滴答清单这种 todo 帮我记一件事，比如各种 Proma 的功能更新和优化，用户的各种小事，其实这些很大部分都可以让 Agent 主动去做。Proma 也可以内置一个 Todo 的功能，用户可以只管记录，然后手动分配或者 Agent 自动评估，然后排队去做。甚至 Proma 也可以接入到飞书等内，实现通过对话的方式转换成 Todo ，并给用户汇报进度。

与人类协作探索

以上提到的部分，从人类的视角看，都需要跟人协作。比如 Todo 模式就是一种尝试运行的跟人的协作，这种协作方式解决了触发时机和范围的问题。那么在其他方面呢？我并不想完全像 openclaw 这样的方式来 Agent 做主一切，除了探索性的任务和毫不在意的任务外，似乎我们都不太敢相信这种方式。权限模式就是一种已经抽象出来的跟人交互的方式，然后进一步的探索就是 Claude Code 推出的根据计划全部允许自动运行的模式；如果我们可以实现三层的 Claude Agent SDK 的相互驱动，那么主 Agent 也可以记录和逐渐学习哪些小事是 Agent 可以自己做主决定去做的，人类通过交互学习的方式来逐渐放开到合适的权限，在重要的事情上把人类再 Call Back 回来。

Agent 核心替换

目前完全依赖 Claude Agent SDK 存在两个问题，一个是不透明，大家会在开发的过程里逐渐体会到这个点，这个点会带来一些风险，如果万一 Claude Agent SDK 从某天起完全不允许第三方 API 的接入甚至完全不对外提供 Claude Agent SDK 这些都有可能。

第二个问题是 Claude Agent SDK 目前看内存泄露的情况很常见，并且执行的效率比较低，所以为了提高整体的效率，我们仍然需要考虑其他的 Agent 核心。

目前看开发者社区可能更偏向于 openclaw 背后的 pi agent。所以计划上我们也会开个新的分支来尝试做 pi agent 这个开源的项目的切换，如果一切顺利效果不错，我们可能也会逐渐考虑全部切换到 pi agent ，增加后续我们选择供应商等方面的选择。

插件模式

我们的贡献者还提出一种插件的想法，比如大家可能会有一些自己的想法，虽然可能不一定能合并到主版本，但是仍然希望有人用到或者体验到，增加一种更灵活的集成方式。

插件模式我自己不熟悉，也没有具体的实现思路，但是 Proma 是支持的，所以如果有朋友想研究插件的范围和作用域，以及插件的实现规范和市场，也欢迎继续做这方面的工作。

Proma 开发协作方式

VibeCoding 这一轮的协作程度其实总体是比较低的，因为一个人可以自己实现的工作更多了。我推荐的协作方式是一个人做整个功能，并且也推荐其他人做类似的功能。因为实现起来可能会很快，两个伙伴可以在完全不商量的情况下比如都实现全局记忆功能，这样我们就会有至少两种不同的设计，我们就可以对比哪种更好，或者受到启发创建第三种方式，这样的开发方式跟过去的可能两个人频繁交互最后做出来一种方案要好得多。我们鼓励的是根据实际的工作结果表现来相互启发。VibeCoding 时代终于也能让个体实现这种设计上的浪费和开发上的浪费，因为这些浪费成本很低但价值很高。