OpenTeams
本地优先的 AI 桌面应用，把 Claude Code、Codex、Gemini CLI 等 16 个编码智能体组成一个可控的团队，用于规划、构建和交付软件。
证据显示项目在架构上强调隔离工作区（Git worktree）、步骤级审查/重试/跳过以及 ACP 审批与权限配置（changelog 提及），这些支持 rollback 与部分 user_confirmation，但审批、权限与审批 UI 的具体实现未在所提供文件中出现，只能按声明计 1 分；least_privilege、data_flow_transparency、sensitive_data_handling 均无文档或代码佐证，CLI 测试显示 access/refresh token 明文存入本地 SQLite 且未见加密或清理策略，扣分点明确。dependency_security 存在实质弱点：Cargo.toml 将 tokio-tungstenite/tungstenite 指向第三方 fork（openai-oss-forks）固定 rev，ts-rs 直接依赖个人 fork（xazukx），构成供应链风险，且无审计/ADVISORY 说明。external_effects 扣分因应用会启动外部 CLI agent、部分安装方式是 curl|bash 管道脚本，风险未在安全文档中说明。rollback 得 2 分：worktree 的 review/merge/discard 与步骤重试在 README 中有一致且具体的描述。source_attribution 得 2 分：Apache-2.0 LICENSE 完整、npm 与 GitHub 出处清晰，但发布者未经验证，且构建依赖私有密钥与未公开的 VK_SHARED_API_BASE 等端点，来源不完全可追溯。
self_consistency 扣分：README 更新日志最高到 v1.0.9（2026-08-04），而 package. 为 1.0.24-140；README 中两个 Discord 邀请链接（MbgNFJeWDc 与 /openteams）不一致，且文档日期为未来时间（2026 年），版本与链接的自洽性受损，计 1 分。dependency_availability 得 2 分：CI 工作流详细固定 Node 22、pnpm 10.13.1、nightly 工具链、cargo 工具版本并提供 lockfile 与缓存策略，可复现构建意图明确；但工具链使用 nightly-2025-12-04 属脆弱固定。failure_messages 得 1 分：仅零散的排错说明（cargo-watch、Gatekeeper），无系统化错误处理或面向用户的失败信息文档。
audience_and_scenarios 得 3 分：README 的 'Who It Is For'、is/is-not 对照表和具体使用场景描述清晰、诚实且边界明确。capability_boundaries 得 2 分：is/is-not 表明确否定自己是模型、项目管理套件或黑盒，但未量化限制（如并发上限、token 上限行为）。trigger_precision 得 1 分：缺少 AGENTS.md 或触发/调度规范，@ 协作与 Workflow 触发条件只有概述。environment_fit 得 3 分：列明 Windows/macOS/Linux/Web、Node/Rust/pnpm 版本前置、各平台安装产物与 Windows 排错，环境适配证据充分。
information_architecture 得 2 分：README 结构完整（是什么/为何/快速开始/特性/开发/贡献/许可），但深度文档主要外链到 doc.openteams-lab.com，仓库内信息层次偏浅。install_notes 得 3 分：桌面安装、npx、macOS 未签名 quarantine 处理、本地构建与 Windows 排错一应俱全，是本次评审中最强项。naming_stability 得 2 分：openteams 命名总体一致，但 'OpenTeams CLI' 与 'openteams-cli' 大小写混用。examples_and_faq 得 1 分：仅 ASCII 对比图与截图，无可运行示例或 FAQ。known_limitations 得 2 分：明确披露 macOS 未签名/未公证风险并给出补救与'不要全局关闭 Gatekeeper'的告诫，属于良好实践；但性能/安全限制未披露。license 得 3 分：Apache-2.0 全文在 LICENSE 中，README 另附准确的白话摘要与商标/专利说明。versioning_changelog 得 2 分：有带日期的 Major updates 与 Roadmap，但 changelog 只到 v1.0.9 且不覆盖全部发布（1.0.24），无 CHANGELOG 文件。maintenance_responsibility 得 2 分：CONTRIBUTING、good first issue、多渠道社区与活跃发布节奏可见，但无明确维护者/安全响应渠道（SECURITY.md 未见于证据）。
output_usability 得 1 分：产出物（artifacts、diffs、transcripts、统计）仅为 README 声明，提供文件中无对应 UI/数据结构证据。marginal_value 得 2 分：多 agent 共享会话、worktree 隔离与成本统计对'管理多个编码 agent'这一痛点是清晰增量，与现有竞品差异叙述具体；扣分因核心差异点未在代码层面展示。cost_benefit 得 2 分：项目把'token 消耗转成真实生产力'与按会话/模型的成本分解作为核心卖点，价值主张明确；但成本数据准确性与本地记录格式无法静态验证。
claim_traceability 得 1 分：大量关键声明（审批流、预算上限、reviewer-loop invariants、统计准确性）无法在提供文件中追溯到实现，仅出现在 changelog/README。cross_source_corroboration 得 1 分：CI 工作流与 package. 相互印证构建/签名流程，但版本号、Discord 链接相互矛盾，且 changelog 日期（2026 年）先于 package. 版本，交叉证据不一致。fact_inference_separation 得 2 分：README 的 is/is-not 表与'This section is a plain-language summary'明确区分事实声明与解释性表述，习惯良好；扣分因功效类语句（如 'Turn tokens into real productivity'）为营销断言而非事实。
- Cargo.toml 通过 [patch.crates-io] 将 tokio-tungstenite/tungstenite 指向第三方 fork 固定 rev，ts-rs 依赖个人 fork；在采用前应审查这些 fork 的来源与差异。
- openteams-cli 测试显示账号 access/refresh token 明文写入本地 SQLite，使用前请确认磁盘加密与令牌存储安全策略。
- macOS 版本未签名/未公证，README 建议的 xattr 去隔离命令仅在确信来源可信时执行，且不要全局关闭 Gatekeeper。
- 部分第三方 agent 的安装方式为 curl | bash 管道脚本，执行前请自行审查脚本内容。
- README 中版本号（最高 v1.0.9）与 package.（1.0.24-140）及两个 Discord 链接不一致，且 changelog 日期为未来时间，评估时应以仓库实际 tag 为准。
- 本评审为静态源码审查（置信度低），未执行任何运行时验证；审批流、预算上限、统计准确性等关键声明均未经执行验证。
这个 Agent 能做什么，适合哪些场景？
OpenTeams（GitHub 仓库 openteams-lab/openteams）是一个开源、本地优先的 AI 桌面应用，口号是'用一组 AI 智能体而非单个智能体来规划、构建并交付'。它本身不是新的模型，而是把你已有的编码智能体（如 Claude Code、Codex、Gemini CLI、Qwen Code、OpenCode 等，共支持 16 个，含内置的 openteams-cli）放进同一个共享会话，统一上下文并互相交接任务。开发者通过自己掌控的 Issue 列表连接项目工作与智能体会话，路线图不会由智能体自行改写。Workflow 模式将复杂任务拆为带依赖的步骤，可逐步审查、跳过或重试；并行任务各自运行在独立的 Git worktree 中，互不干扰。技术栈为 React + TypeScript 前端、Rust 后端、Tauri 桌面框架，运行记录保存在本地 .openteams/ 目录下，构建统计可对比交付成果与 token 用量和成本。项目采用 Apache-2.0 许可证，支持 Windows、macOS、Linux 和 Web。
OpenTeams 读取你配置的工作区，把多个编码智能体（Claude Code、Codex、Gemini CLI、Qwen Code、OpenCode、Amp、GitHub Copilot、Cursor、Droid、Kimi Code、Qoder CLI、Pi、Hermes、Kiro CLI、DeepSeek Harness ACP、内置 openteams-cli）拉入一个共享会话，各智能体共享同一份对话和项目上下文。自由聊天模式下用 @ 直接调用某个智能体；Workflow 模式把复杂任务转为带依赖、评审、重试和验收的结构化步骤，执行前后都可查看，支持跳过单个节点。并行会话各自使用独立 Git worktree，之后可分别审查、合并或丢弃。Issue 管理支持从 GitHub 同步 issue 并链接到执行会话。构建统计按会话和模型汇总修复的 bug、交付的功能、token 用量与成本；日志、diff、转录和产物随工作留存。运行时记录保存在 .openteams/ 目录。
- 同时使用 Claude Code、Codex 和 Gemini CLI 的独立开发者，不想再开多个终端手动传递上下文和结果
- 技术负责人需要智能体的每次执行可审查、可复现，能逐步重试而不是整个流程重来
- 团队需要并行执行多个任务，但担心多个智能体改坏同一工作区，需要按 worktree 隔离后择机合并
- 开发者想用本地 Issue 列表（可从 GitHub 同步）驱动智能体执行，同时保持路线图由自己掌控
- 管理者需要对比各会话、各模型的交付成果与 token 成本，评估智能体投入产出
- 希望用现成的团队工作流模板快速启动规划—构建—交付流程的中小团队
这个 Agent 有哪些优点和局限？
- 多智能体共享会话与上下文，替代手动在多个终端间搬运结果
- Workflow 模式提供可见的步骤与依赖图，支持逐节点评审、跳过和重试，避免黑盒一次性运行
- 每个并行会话运行在独立 Git worktree，可分别合并或丢弃，防止互相覆盖
- Issue 由开发者掌控并链接到会话，构建统计把交付与 token 成本对应起来
- 支持 16 个编码智能体并内置 openteams-cli，不绑定单一厂商；本地优先，运行记录保存在本地 .openteams/
- macOS 版本未经签名和公证，需要手动执行 xattr 命令才能通过 Gatekeeper
- 需要自行安装并配置各个外部智能体 CLI（Claude Code、Codex 等均需单独全局安装和各自的模型账号）
- 从源码构建需要 Rust、Node.js、pnpm（Windows 还可能需 cargo-watch）等多重开发环境
- 项目仍处活跃开发期，路线图中'专家 AI worker'等能力尚未交付；最新版本号（v1.0.9，2026.08.04）显示迭代频繁，升级可能带来变化
- 作为本地桌面应用，需要本机运行环境和文件系统访问，不适合无本地运行条件的纯云端工作流
如何安装或部署这个 Agent？
推荐方式：从 GitHub Releases 下载对应平台的最新安装包——Windows 为 openteams-windows-x64.msi，macOS 为 openteams.dmg，Linux 为 openteams-linux-amd64.deb。macOS 当前版本未经 Apple 签名/公证，Gatekeeper 可能提示'已损坏'，拖入 /Applications 后如信任官方发布可执行：xattr -dr com.apple.quarantine /Applications/openteams.app。也可通过 npm 直接运行：npx openteams-web。若从源码构建，需要 Rust >= 1.75、Node.js >= 18、pnpm >= 8：git clone https://github.com/openteams-lab/openteams.git && cd openteams && pnpm i && npm run dev，桌面版打包用 pnpm run desktop:build；本地编译 openteams-cli 用 bun run ./scripts/build-openteams-cli.ts。Windows 上如 pnpm run dev 报错 'no such command: watch'，先执行 cargo install cargo-watch。
如何使用这个 Agent？
安装并启动后，先在 Settings → Provider Config → Add Provider 配置模型提供方（内置 openteams CLI 智能体开箱即用）。然后连接你已有的编码智能体，例如：npm i -g @anthropic-ai/claude-code（Claude Code）、npm i -g @openai/codex（Codex）、npm i -g @google/gemini-cli（Gemini CLI）、npm i -g opencode-ai（OpenCode）、npm i -g @qwen-code/qwen-code（Qwen Code）、npm i -g @github/copilot（GitHub Copilot）等，Pi 无需安装（经 npx 运行），Hermes 用 pip install hermes-agent。日常使用：自由聊天中用 @ 直接与某个智能体协作；复杂任务切到 Workflow 模式查看步骤和依赖，可逐节点评审、跳过或重试；在 Issue 列表记录并优先排序工作项，从 GitHub 同步 issue 并创建/关联执行会话；并行会话各用独立 worktree，完成后审查、合并或丢弃；通过构建统计查看交付、token 和成本。
这个 Agent 与同类方案有什么区别？
README 明确将 OpenTeams 与'直接使用 Claude Code / Codex / Gemini CLI'对比：单个智能体各自为战时，用户需要在多个终端间手动传递上下文和结果；OpenTeams 不替代这些智能体，而是提供它们之上的共享会话、可见工作流、受控 Issue 和成本统计层。