"在你的工作群里召唤 Agent"
Proma 的 README 上有一段话让我印象很深：
"把最丝滑的通用 Agent 体验带进你的工作流，为 100x 专业用户而生的未来产品，正在实现 proactive Agent 阶段。"
这不是 GitHub 上常见的"又一个 Agent 框架"。Proma 的作者 ErlichLiu 做了一件很务实的事：把 Agent 能力直接嵌入到中国人最熟悉的工作场景中——飞书群聊。
你不需要打开一个新的 Agent 平台、不需要切换到专用界面。在飞书群里 @一下，Agent 就开始工作了。
为什么是飞书？
这个选择背后有一个很强的逻辑。
目前市面上的 AI Agent 工具，绝大多数都是以"独立应用"的形态存在的——你打开 Cursor 写代码、打开 Claude 聊天、打开 Notion AI 整理文档。每种工具都有自己的界面、自己的工作流。
但现实是，中国大部分知识工作者的日常协作都发生在飞书里。 沟通、文档、会议、审批、项目管理——都在这个平台里完成。如果 Agent 不能在飞书里用，那它和用户的日常工作就是"隔离"的。
Proma 的聪明之处在于：它不试图让用户改变习惯，而是把 Agent 塞进用户已有的习惯里。
技术架构：不只是飞书机器人
如果只是做一个飞书机器人，那 Proma 没什么特别的。但它的架构比那复杂得多：
基于 Claude Agent SDK
Proma 的底层使用的是 Anthropic 的 Claude Agent SDK。这意味着它继承了 Claude Agent 的核心能力：多步骤推理、工具调用、自主规划。
多模型供应商支持
虽然基于 Claude SDK，但 Proma 不锁定在 Anthropic。它可以灵活接入任意大模型供应商——OpenAI、Google、国内的大模型平台都行。这是一个很务实的设计，特别是在国内的网络环境下，多供应商意味着更高的可用性保障。
Electron 桌面应用
Proma 有一个 Electron 桌面客户端，这意味着：
- 本地文件访问——Agent 可以直接读写你电脑上的文件
- 系统级集成——可以调用系统命令、访问本地工具
- 离线缓存——部分功能可以在离线状态下使用
最近一次 commit（4 小时前）还在修"磁盘管理异步化 + 文件监听过滤高频目录，修复超大工作区 UI 冻结"——说明作者真的在处理大规模使用场景下的性能问题。
Proactive Agent 阶段
Proma 正在从"被动响应"向"主动行动"演进。这意味着 Agent 不只是在你提问时回答，而是可以：
- 主动监控项目状态
- 发现异常时主动通知
- 根据上下文自动触发工作流
837 星背后的故事
Proma 目前只有 837 颗星——不算多，但考虑到它的发展阶段和社区质量，这个数字是健康的。
145 个分支、844 次 commits、52 个标签——对于一个个人主导的项目来说，这个迭代速度相当可观。更值得注意的是，代码库的结构很清晰：
apps/electron——桌面客户端packages——核心功能包proma-thinking——Agent 推理模块docs——文档release-notes——版本记录tutorial——教程
这说明作者不是在做实验性的玩具，而是在认真地构建一个产品。
适合谁用？
Proma 最适合：
- 飞书重度用户——团队日常协作都在飞书里，希望 AI 能力无缝融入
- 中国开发者——需要接入国内大模型供应商，同时保持对国际模型的访问
- 100x 专业用户——需要 Agent 处理复杂的多步骤任务，而不是简单的问答
- 想自建 Agent 基础设施的团队——不想依赖第三方 SaaS 平台
面临的挑战
Proma 也面临一些现实的挑战：
生态锁定风险。 虽然支持多模型供应商，但核心架构深度绑定 Claude Agent SDK。如果 Anthropic 调整 SDK 策略或收费模式，可能会有影响。
飞书 API 的限制。 飞书机器人的能力受到飞书开放平台 API 的限制——某些系统级操作可能无法在群聊环境中完成。
社区规模。 目前核心贡献者集中在 ErlichLiu 一人身上。一个健康的项目需要更多的社区参与者来分散风险。
竞品压力。 国内的 Agent 平台正在快速涌现——字节的 Coze、阿里的百炼、腾讯的元器——都有各自的飞书/企微集成方案。Proma 需要找到自己的差异化定位。
Proma 的价值不在于技术上的突破，而在于它选择了一个正确的切入点：让 Agent 跑在用户已经在用的地方。这个思路看似简单，但在 Agent 工具"百花齐放但各自为战"的当下，反而是最稀缺的。