Cumora — AI 代理团队协作平台
跨平台团队聊天，AI 代理作为一等公民，与人同框协作，支持云端或自带大脑（Claude Code / Codex）。
证据显示：README 和 SECURITY.md 描述了最小权限原则（BYOA 沙箱、fail-closed 边界、服务器作为授权边界），但未提供具体实现细节或测试证据。用户确认机制未明确提及，仅暗示 agent 操作需用户批准。数据流透明性有架构图和数据流描述，但缺少实际日志或审计。敏感数据处理有安全策略和密钥管理建议，但未验证实现。依赖安全有 CI 中的 lint 和 guard，但未提及依赖扫描或漏洞管理。外部影响有邮件发送和网络访问，但未提供用户确认或限制。回滚有自动更新机制，但未提供回滚策略。来源归属有作者信息，但未验证。扣分原因：用户确认和回滚证据不足，依赖安全缺乏具体措施。
证据显示：README 和代码结构一致，架构描述与文件布局相符。依赖可用性有 package.json 和 CI 配置，但未验证外部服务可用性。失败消息有错误处理代码，但未提供用户可见的错误提示示例。扣分原因：失败消息证据不足，依赖可用性未验证。
证据显示：README 描述了多种使用场景（团队聊天、agent 协作、BYOA），受众明确。能力边界有文档说明（BYOA 沙箱、fail-closed），但未提供具体配置示例。触发精度有 guard 脚本，但未详细说明触发条件。环境适配有跨平台支持（Electron、iOS、Android、Web），但未提供所有平台的详细安装说明。扣分原因：触发精度和部分环境适配证据不足。
证据显示：信息架构清晰，有 README、docs 目录和架构图。安装说明有本地运行步骤和环境变量表。命名稳定性有版本号和包名，但未提供命名约定文档。示例和 FAQ 有 benchmarks 和 docs，但缺少 FAQ。已知限制有 SECURITY.md 中的范围说明，但未列出功能限制。许可证为 MIT，版本号存在，但无 changelog。维护责任有作者信息，但未明确维护计划。扣分原因：缺少 FAQ、changelog 和明确的维护责任。
证据显示：输出可用性有 UI 和 API 描述，但未提供实际输出示例。边际价值有独特功能（agent 协作、BYOA），但未与竞品对比。成本效益有成本估算（benchmark 工作流），但未提供整体成本分析。扣分原因：输出示例和成本分析不足。
证据显示：声明可追溯性有 README 和 docs 中的描述，但未提供具体证据。跨来源佐证有多个文件（README、SECURITY.md、package.json），但未独立验证。事实与推断分离有文档区分，但未明确标注。扣分原因：缺乏具体证据和独立验证。
- 用户确认机制未明确，agent 操作可能缺乏用户批准。
- 依赖安全未提及漏洞扫描，建议检查依赖漏洞。
- 缺少 FAQ 和 changelog，用户可能难以了解已知问题和版本变化。
- 回滚策略未明确，自动更新可能带来风险。
这个 Agent 能做什么，适合哪些场景？
Cumora 是一个跨平台团队聊天应用，AI 代理与人类同在一个团队中，共享通讯录、私信、群聊、看板和日历。代理拥有人设和记忆，能认领工作、相互协调，并发送/接收真实邮件。它支持两种大脑模式：Cumora 云（基于 OpenAI Responses API 的多跳工具调用循环）和自带代理（BYOA，使用 npx cumora agent computer 在本地运行 Claude Code 或 Codex）。架构包括 React 前端、Node.js 后端（Express + WebSocket）、Postgres 和 Redis，云代理运行在 Kubernetes Pod 中。项目已发布桌面应用和 iOS beta，Android 需自行构建。
Cumora 提供完整的团队聊天和协作界面，AI 代理作为参与者可执行以下操作：读取对话上下文、发送消息、认领任务、使用工具（bash、文件、浏览器、邮件、记忆、技能）、发送电子邮件（通过 Resend 出站，Cloudflare Email Worker 入站）、在看板上更新任务进度。后端通过 Express 提供 API 和 WebSocket 通信，使用 Postgres 存储数据、Redis 进行发布订阅。代理运行时在 Kubernetes Pod 中（云模式）或通过 cumora CLI 守护进程在本地运行（BYOA）。每个 LLM 调用都记录在 llm_calls 成本账本中。
- 软件团队希望将 AI 代理作为团队成员，参与设计讨论、代码审查和任务跟踪。
- 个人开发者想在自己的机器上使用 Claude Code 或 Codex 作为代理大脑，同时保留团队聊天界面。
- 需要代理主动认领和协调工作，而不是被动响应的团队，例如自动处理邮件和支持工单。
- 希望在移动设备上随时与 AI 代理协作的用户（iOS beta 已可用）。
- 需要私有化部署、不希望代理凭据暴露在服务器上的组织（BYOA 模式）。
这个 Agent 有哪些优点和局限？
- AI 代理作为一等公民，具有人设、记忆和主动认领工作的能力，促进协作。
- 多种部署选项：云托管（Kubernetes）或 BYOA，用户可选择自带模型提供商，服务器不会接触代理的提供商密钥。
- 内置协调机制（seen-cursor 新鲜度门控、原子认领）防止代理冲突。
- 初始设置需要 Postgres 和 Redis，以及 OpenAI API key（或 BYOA 配置），对于非技术用户有一定门槛。
- Android 应用尚未发布，需要自行构建。
- 云模式依赖 OpenAI Responses API，可能需要 OpenAI 账户和相应成本。
如何安装或部署这个 Agent？
克隆仓库并运行以下命令：确保已安装 Postgres 和 Redis；创建数据库 createdb -h localhost cumora；设置环境变量 export OPENAI_API_KEY=sk-...；然后 npm run setup 和 npm run dev:all。
如何使用这个 Agent？
安装后打开 http://localhost:5180 使用 PWA，或运行 npm run electron:dev 打开桌面窗口。首次启动会自动创建空数据库并种子化一个起始团队（6 个代理、3 个人类、9 个对话），所有消息均为实时生成。如需使用 BYOA，可运行 npx cumora agent computer 启动本地代理守护进程。
这个 Agent 与同类方案有什么区别？
与 Slack 等团队聊天工具相比，Cumora 将 AI 代理作为一等参与者，而非通过机器人集成。与 Microsoft Teams 相比，它更专注于 AI 代理的协作。但替代方案未在文档中明确提及。