多 Agent 并行开发如何让团队看得见？Agor 用共享看板连接分支与会话
当团队成员各自在终端启动 Claude Code、Codex 或 Gemini CLI，任务很快会散落在不同分支、工作目录和聊天记录里。问题不只是“同时开几个 Agent”，而是同事如何知道它们正在做什么、能否接手，以及一个人的有效工作流怎样变成团队可复用的经验。Agor 想解决的正是这层协作问题：把分支、开发环境和 Agent 会话放进共享的实时工作区。
它不是新的模型，而是 Agent 工作区
Agor 不提供自己的模型，而是编排已有的编码 Agent CLI 与 SDK。项目 README 列出的运行时包括 Claude Code、Codex、Gemini、OpenCode、Copilot 等；Cursor 标注为 beta。团队可以在会话层选择运行时，模型和订阅则由使用者提供。这种定位意味着 Agor 的重点不是回答质量，而是任务组织、协作可见性与运行治理。
核心对象可以概括为三层：Branch 是工作单元，对应一个 Git 分支及独立工作目录、开发环境和会话；Session 是 Agent 对话，支持 fork 探索替代方案，也可 spawn 具有新上下文的子任务；Board 与 Zone 是协作界面，团队在二维画布上查看分支和会话，把工作放进不同区域，并可配置拖入区域后触发模板提示。
这些机制解决了常见的并行开发摩擦。每个任务有自己的分支，降低多个 Agent 同时改同一工作区的冲突；共享开发环境为分支分配端口，其他成员可以直接检查结果；实时光标、评论和共享会话让同事跟进工作，而不是靠截图或状态消息猜进度。成员也能加入正在进行的 Agent 工作，帮助补充上下文或及时介入。
从单人试用开始
仓库提供的快速开始要求 Node.js 22.12 或更高版本，并要求 Git 可从 PATH 调用。全局安装后初始化配置、启动 daemon，再打开 Web UI：
npm install -g agor-live agor init agor daemon start agor open
初始化向导会创建配置和数据库，并安装用户选择的工具。项目文档也提供 Docker Compose 的入门路径；部署方式、数据库选项和团队配置细节应按官方 extended installation 文档操作，不要把上述三条命令误当成生产部署指南。
Agor 的工作模型适合把需求拆成多个独立分支：例如一个 Agent 调查 API 行为，另一个准备测试，开发者在 Board 上比较结果；需要尝试不同实现时 fork 会话，需要聚焦子任务时 spawn 子会话。Zone 可以承载团队自己的流程阶段，或在分支被移动时触发预先配置的提示。项目文档强调，一条分支通常对应一个功能或 PR，但这属于约定而非强制限制。
团队共享也带来治理责任
Agor 的团队能力不止于看板。README 提到分支级 RBAC、每位用户的凭据与环境变量，以及按 Prompt 记录 token 和费用并跨会话保留历史。团队成员还可以创建带有知识库命名空间的 AI teammate，保存可搜索的共享上下文与技能；通过 Slack、GitHub 等 gateway channel 接入团队已有的工作场所，并安排周期性任务。
这些能力意味着部署时需要认真界定权限：哪些成员可以操作哪些分支，Agent 运行时能读取哪些凭据，哪些任务允许自动触发。自托管说明列出 LibSQL 或 Postgres，以及 trusted local、fail-closed sandbox、delegated external execution 等执行模式。它们的隔离边界和运维要求并不相同，不能仅凭“支持 sandbox”就假设所有 Agent 命令都已获得同等级别的防护。建议先用测试仓库验证凭据范围、网络权限、分支清理和日志留存，再接入重要项目。
还要留意许可边界：仓库当前 LICENSE 为 Business Source License 1.1（BUSL-1.1），不是 OSI 批准的开源许可证。文本允许特定条件下的生产使用，但限制将 Agor 作为面向第三方的 Agent 编排托管/管理服务；许可文件列出的 Change Date 是 2029-01-15，届时转为 Apache 2.0。计划商业再分发或托管服务时，应先阅读完整许可并确认适用范围。npm registry 当前列出的 agor-live 版本为 0.27.0；版本会变化，安装前可查最新发布信息。
适合什么团队
如果团队已经在用多个编码 Agent，主要痛点是会话散落、无法互相接手、并行分支难以观察，Agor 的共享画布和分支工作区值得试用。若团队只需要单机 CLI，或不需要共享会话、集中治理和运行时编排，增加一个常驻 daemon 与工作区可能反而提高复杂度。可以先挑选低风险仓库，从一个分支、一个 Agent 和一位协作者开始，观察看板能否减少状态同步，再逐步启用团队权限、知识库和自动调度。
真正值得评估的指标不是“同时启动了多少 Agent”，而是团队能否更容易看清任务边界、复用有效做法，并在需要时及时接手。Agor 提供了一种偏团队协作的工作面；它不能替代代码审查、测试与权限设计，但可以让分散的 Agent 工作更容易被团队看见和组织。