Chorus 协作编排平台
让人类与 AI 编程代理按 AI-DLC 流程协作交付。
按维度查看评分与理由
证据显示有细粒度的权限矩阵（5x3）和权限门控的MCP工具，但默认的daemon权限模式是yolo（完全访问），且没有明确的用户确认机制。数据流透明度有限，敏感数据处理（如API密钥）有提及但未深入。依赖安全未明确审计，外部影响（如daemon执行代码）有文档但未充分讨论。回滚机制未明确。来源归属（如OpenCode插件）有提及但未验证。因此，多数标准得分为1或2。
自一致性较好，README与代码结构一致，测试覆盖了关键生命周期场景。依赖可用性有文档（如PGlite、外部PostgreSQL），但未验证。失败消息有测试覆盖（如关闭失败的重试），但整体可靠性证据有限。
受众明确（AI-Human协作），场景多样（本地、Docker、AWS）。能力边界有权限矩阵和文档，但触发精度（如daemon的yolo模式）可能过于宽泛。环境适配有多个部署选项，但未验证。
信息架构清晰，有多个文档（PRD、架构、MCP工具等）。安装说明详细，命名稳定（版本号）。示例和FAQ有部分，已知限制有提及（如PGlite并发限制）。许可证明确（AGPL-3.0），版本变更日志存在。维护责任未明确，但社区贡献有提及。
输出可用性有UI和MCP工具，边际价值高（AI-DLC工作流），成本效益合理（本地运行无需数据库）。但未验证实际效果。
声明可追溯（README与代码对应），跨源验证有限（仅内部测试），事实与推断分离较好（文档区分了设计意图和实现）。
- 默认daemon权限模式为yolo（完全访问），可能过于宽泛，建议用户明确配置权限。
- 未发现明确的用户确认机制，对于高风险操作（如执行代码）应增加确认步骤。
- 依赖安全未明确审计，建议检查依赖漏洞。
- 回滚机制未明确，建议提供数据备份和恢复方案。
这个 Agent 能做什么，适合哪些场景？
Chorus 是面向 AI-DLC 的自托管 Agent Harness，用于把需求、提案、文档、任务和验收串成可追踪的协作流程。它提供 Next.js Web UI、REST API、SSE 推送，以及权限控制的 /api/mcp 流式 MCP 接口。任务可在看板中流转，并以依赖 DAG 表达执行顺序和可并行路径；提案获批后可落地为实体和任务。Chorus Daemon 可把本机 Claude Code、Codex 或 Kiro CLI 作为远程执行运行时唤醒，并显示流式转录、支持注入指令、中断和恢复。部署可使用内嵌 PGlite、外部 PostgreSQL，或带 PostgreSQL 与 Redis 的 Docker Compose / AWS CDK 架构。
用户从 Idea 开始，由具备 idea:write、proposal:write 或 task:write 权限的参与者完成需求澄清、起草 Proposal、生成 Document 和 Task DAG，并在 To Do、In Progress、To Verify 状态间推进任务。Chorus 通过 /api/mcp 提供 50+ 个权限受控工具，并让 Web UI 与 chorus_search MCP 工具共用搜索后端。运行 chorus daemon 后，守护进程按 --cwd 注册本地目录；Chorus 可将工作分派到指定实例，守护进程唤醒选定的 Claude Code、Codex 或 Kiro 后端执行。系统保存会话、心跳、活动记录、验收条件证据和实时状态，并为会话失效提供恢复机制。
- 软件团队希望把模糊需求先经结构化问答变成 Proposal、文档和任务依赖图，再交由人和代理共同交付。
- 使用 Claude Code 或 Codex 的开发者需要把某个远程项目任务精确派发到本机指定工作目录，并在浏览器中查看执行转录。
- 技术负责人需要在 Kanban 与 Task DAG 中同时跟踪多项依赖任务，识别可并行执行的路径。
- 需要审计 AI 参与开发过程的团队，可利用带 session 归属的活动流和双路径验收条件记录。
- 部署多代理协作环境的组织，可为不同参与者配置 5 类资源乘 3 类操作的细粒度权限。
这个 Agent 有哪些优点和局限？
- 把 Idea、Proposal、Document、Task DAG、验收和完成状态置于同一套 AI-DLC 工作流，而非只提供一次性代理调用。
- Daemon 可按 agent、host、cwd 定位执行实例，并支持多工作目录、实时转录、指令注入及中断/恢复。
- 权限模型按 5 类资源和 3 类操作组合，支持预设与自定义授权，而不是固定代理角色。
- 既能用内嵌 PGlite 快速启动，也提供 Docker Compose 和 AWS CDK 的生产部署路径。
- 内嵌 PGlite 适合本地单用户；并发多代理或多用户时，文档要求改用外部 PostgreSQL 或完整 Docker Compose 栈。
- Daemon 的本地后端明确支持 Claude Code、Codex 与 Kiro；其他 CLI 的支持并未作为同等原生后端列出。
- Linux 的 daemon install 依赖 systemd --user；macOS 和 Windows 仅提供需手动安装的模板。
- 生产多副本部署还需要 PostgreSQL 与 Redis，增加基础设施和运维复杂度。
如何安装或部署这个 Agent？
最快的本地安装方式：npm install -g @chorus-aidlc/chorus，然后运行 chorus。服务会自动迁移内嵌 PGlite 并打开 http://localhost:8637；默认登录为 [email protected] / chorus。Docker 本地模式可执行：[email protected] DEFAULT_PASSWORD=changeme docker compose -f docker-compose.local.yml up -d。开发环境要求 Node.js 22+ 与 pnpm 9+；无 Docker 可执行 cp .env.example .env、pnpm install、pnpm dev:local。
如何使用这个 Agent？
登录 Web UI 后，在 Settings → Setup Guide 中为客户端完成连接配置，或在 Settings → Agents 创建仅显示一次的 cho_ API Key。连接本机执行端时，先运行 chorus login，再运行 chorus daemon；使用 Codex 可运行 chorus daemon --agent codex。若需服务多个目录，运行 chorus daemon --cwd ~/work/repo-a --cwd ~/work/repo-b。随后在项目中创建 Idea，完成 Proposal 审核并把任务分派给已连接的代理实例，在看板、DAG 和会话视图中跟踪并验收。
这个 Agent 与同类方案有什么区别？
对于本地执行后端，Chorus 原生支持 Claude Code、Codex 和 Kiro CLI；OpenCode 连接依赖社区维护的 opencode-chorus 插件。除这些集成差异外，资料未提供同类产品的功能对比。