Chorus 是一个开源的 Agent Harness（智能体编排框架），它实现了 AI-DLC（AI-Driven Development Lifecycle，AI 驱动开发生命周期）方法论。它比编程 Agent 高一层：把多个 AI Agent 和人类收进同一条Idea → Proposal → Execute → Verify流水线——AI 提议，人类把关，想法最终交付成软件，而不只是写几行代码。

🎯 Chorus 是什么：编程 Agent 之上的 Harness

理解 Chorus 之前，先要分清两层：

• 编程 Agent 层（如 Claude Code、Codex、Kiro）：把大模型 harness 起来写代码的那一层；
• Chorus 层：把多个这样的 Agent 和真人收进同一条流水线的协作平台，负责会话生命周期、任务状态、子 Agent 编排、可观测性和故障恢复。

Chorus 的核心理念来自 AI-DLC 的Reversed Conversation（反转对话）：

AI 制定计划 → 人类审查/质疑 → AI 澄清 → 人类批准 → AI 执行 → 人类验证

传统开发是"人类写计划，AI 帮忙"；AI-DLC 把方向反转——Agent 提议，人类决策，这个循环在每个阶段快速重复，而不只是在项目级关口走一次流程。

📄 理论背景可参阅 docs/AIDLC_GAP_ANALYSIS.md，它逐阶段对比了 Chorus 对标准 AI-DLC 三阶段（Inception / Construction / Operations）的落地情况。

🔄 AI-DLC 流水线四阶段：每个阶段如何运转

Idea ──> Proposal ──> [Document + Task DAG] ──> Execute ──> Verify ──> Done ^ ^ ^ ^ ^ ^ 人类提出 需求澄清 起草 PRD/任务 报告进度 验收 关闭

每个阶段下方标的是执行该阶段所需的权限，可以授予人类、Agent 或两者。下面逐段拆解技术原理。

阶段一：Idea —— 人类提出，AI 多轮澄清

一切从人类的原始想法开始：一段文本、竞品截图、设计草图都可以。Chorus 中每个 Idea 都有完整的状态生命周期：

open → assigned（PM Agent 认领）→ in_progress（产出 Proposal）→ pending_review → completed

有意思的机制是Elaboration（需求澄清）：认领 Idea 后，PM Agent 会发起多轮结构化提问（例如"两个用户同时拖动同一张卡片时如何冲突消解？Last-write-wins / OT / CRDT 三选一？"），人类逐条回答，AI 基于回答收敛需求。这把 AI-DLC 的 "Mob Elaboration" 实践——利益相关者在执行前实时验证 AI 计划——做成了产品功能。

阶段二：Proposal —— AI 起草计划，人类审批

这是整条流水线的枢纽。PM Agent 读取 Ideas 和项目知识库后，创建一个Proposal（提议）：

人类在 Web UI 上审批。批准瞬间，系统按outputType自动物化产出：

• outputType=document→ 创建 PRD / 技术设计文档；
• outputType=task→批量创建带依赖关系的任务 DAG。

也就是说 Proposal 是"一次审批、两处落地"的原子操作，代码入口在 src/services/proposal.service.ts 的createProposal和 src/services/proposal.service.ts 的approveProposal。

完整的追溯链保证每个 Task 和 Document 都能追到源头：

Ideas → Proposal → Document(PRD) → Proposal → Tasks ↓ Proposal → Document(Tech Design)

阶段三：Execute —— Agent 认领任务，DAG 调度并行执行

审批通过后，任务以 DAG（有向无环图）形式呈现。任务间通过TaskDependency声明依赖，Service 层做环检测，调度时通过chorus_get_unblocked_tasks工具只返回依赖已全部完成的任务。

任务状态机是严格受控的，定义在 src/services/task.service.ts：

open → assigned → in_progress → to_verify → done（关闭为 closed）

关键规则：

• 只有当前负责人可以更新状态——Agent 认领（claim）任务后才能推进它；
• Agent 完成开发后调用chorus_report_work汇报工作，任务进入to_verify；
• 人类可以随时强制重新分配任何状态的任务，随时把流程"拉回"；
• 工作量以Agent Hours计量（AI-DLC 提出的新度量单位，替代人日），Kanban 顶部直接显示累计值。

阶段四：Verify —— 人类验证，闭环交付

to_verify是流水线的"质量闸"：任务从in_progress只能流向to_verify或closed，验证通过才到done，验证不通过则退回in_progress让 Agent 继续修改。这个to_verify → in_progress的回退边，正是 "Reversed Conversation" 在执行层的体现——验证不是一次性的签字，而是可以反复迭代的对话。

每个任务还附带Acceptance Criteria（验收标准），验证者逐条勾选；任务审查默认还会检查验收标准之外的代码质量，并保留完整证据、用稳定 ID 逐轮追踪问题。

⚙️ 支撑流水线的三大支柱

15 位权限矩阵：阶段门禁的地基

Chorus 没有把 Agent 固定分成"PM/开发者/管理员"三种角色，而是用5 类资源（idea / proposal / document / project / task）× 3 种动作（read / write / admin）= 15 个权限位组成矩阵，每个 Agent 持有一份权限集：

有效权限由 src/lib/authz/permissions.ts 的computeEffectivePermissions计算（预设展开 ∪ 自定义权限位）。每个流水线阶段下方标的那种权限门禁，本质都是这张矩阵在查表：没有proposal:write的 Agent 根本看不到chorus_pm_create_proposal工具。

状态机 + Activity 流：过程可审计

状态流转的合法性由状态机表硬校验，非法跳转直接拒绝。同时，每一次创建、分配、状态变更、审批都会由 Service 层自动写入Activity 日志（targetType+targetUuid+actorType+action+value），人类和 Agent 的操作一视同仁地被记录，Activity 流因此成为整条流水线唯一的审计账本。

MCP 协议：Agent 接入的统一入口

Chorus 内置 MCP Server（Streamable HTTP 端点/api/mcp），提供 50+ 工具，按权限分组暴露：

• 公共工具：chorus_checkin（签到，返回 persona、权限摘要、未读通知）、查询 Ideas/Tasks/Proposals、评论等；
• Session 工具：chorus_create_session、chorus_session_checkin_task、chorus_session_heartbeat——Agent 签到任务时，Kanban 卡片上就会出现实时 Presence 指示器；
• 受控工具：按所需权限门禁，工具→权限的映射维护在 src/mcp/tools/permission-map.ts。

这正是 Harness 的"协议外化"：Agent 不再直连数据库或私有 API，而是通过标准化工具接口协作。

🚀 两条命令跑起来的 AI-DLC 流水线

理解了原理后，体验成本很低——无需数据库、无需 Docker、无需配置文件：

npm install -g @chorus-aidlc/chorus chorus

Chorus 会自动启动内嵌 PostgreSQL（PGlite）、执行数据库迁移，然后在http://localhost:8637提供服务，默认账号admin@chorus.local/chorus。接着在 Settings → Setup Guide 里创建 API Key，即可把 Claude Code、Codex、Kiro 等任意 MCP 客户端接入流水线；本地机器运行chorus daemon还能变成可被远程唤醒的 Agent 运行时。

📚 延伸阅读：文档与源码路径

一句话总结 Chorus 的架构哲学：把"谁提议、谁把关、谁执行"变成权限矩阵上的一个位，把"AI 提议、人类验证"变成状态机里的一条边——流水线的每个闸门都是可配置、可审计、可追溯的，这就是 AI-DLC 从方法论落到工程实现的关键。