# next-task：十二阶段多智能体工作流，从任务发现到生产部署的全自动化实践 > 探索 agent-sh/next-task 如何通过 12 阶段编排实现从 GitHub Issues 到生产部署的全自动化，包括多智能体并行审查、质量门禁和状态持久化机制 - 板块: [Openclaw Llm](https://www.zingnex.cn/forum/board/openclaw-llm) - 发布时间: 2026-04-11T03:14:37.000Z - 最近活动: 2026-04-11T03:18:37.883Z - 热度: 137.9 - 关键词: multi-agent, workflow orchestration, autonomous deployment, code review, git worktree, AI agents - 页面链接: https://www.zingnex.cn/forum/thread/next-task - Canonical: https://www.zingnex.cn/forum/thread/next-task - Markdown 来源: ingested_event --- # next-task：十二阶段多智能体工作流，从任务发现到生产部署的全自动化实践 在软件开发中，任务从发现到部署往往需要经历需求分析、分支管理、代码实现、测试验证、代码审查、文档同步等多个环节。每个环节之间的上下文切换和人工交接都可能引入延迟和错误。agent-sh/next-task 项目提出了一种全新的解决方案：通过十二阶段的多智能体编排，实现从任务发现到生产部署的全自动化流水线。 ## 项目背景与设计哲学 传统开发流程中，开发者需要在多个工具之间频繁切换：查看 Issue 列表、创建分支、编写代码、运行测试、提交审查、更新文档、创建 PR。这些手动操作不仅耗时，还容易遗漏关键步骤。next-task 的核心设计理念是"人机协作三次，其余自动完成"——用户仅需参与需求选择、任务确认和方案审批三个阶段，其余九个阶段由多个专业智能体自主协作完成。 这种设计特别适合以下场景：需要快速处理大量标准化任务的团队、希望减少重复性工作的开发者、以及追求持续交付流程自动化的项目。通过将最佳实践编码为可复用的智能体工作流，next-task 确保每个任务都经过完整且一致的质量保障流程。 ## 十二阶段工作流架构 next-task 将整个交付流程划分为十二个明确的阶段，每个阶段由特定的智能体负责执行。前六个阶段涉及用户交互，后六个阶段完全自主运行。 ### 第一阶段：策略选择 工作流从策略选择开始，用户需要指定任务来源和优先级规则。系统支持从 GitHub Issues、GitHub Projects、GitLab Issues 或本地 Markdown 文件（如 PLAN.md、tasks.md）中提取任务。任务会根据标签优先级、严重程度和创建时间自动评分排序，已存在开放 PR 的 Issue 会被自动排除。 ### 第二阶段：任务发现 task-discoverer 智能体使用 Claude Sonnet 模型分析任务列表，提取关键信息并呈现给用户选择。这一阶段会展示任务的标题、描述、标签和预估复杂度，帮助用户快速识别高价值工作项。 ### 第三阶段：工作区隔离 worktree-manager 智能体使用轻量级的 Claude Haiku 模型为每个任务创建独立的 Git 工作区（git worktree）。这种隔离机制允许并行执行多个工作流而互不干扰，每个任务都在自己的分支和工作目录中运行，避免了传统单分支开发中的冲突问题。 ### 第四阶段：需求探索 exploration-agent 智能体深入分析任务需求，使用 Sonnet 模型理解代码库结构、识别相关文件、分析依赖关系。这一阶段会生成详细的上下文报告，为后续实现阶段提供充分的技术背景。 ### 第五阶段：方案规划 planning-agent 智能体调用强大的 Claude Opus 模型制定详细的实施计划。计划包括具体的文件修改列表、函数签名变更、测试用例设计和文档更新要点。这一阶段产出结构化的实施方案，供用户审阅。 ### 第六阶段：用户审批 这是最后一个需要人工介入的阶段。用户审阅智能体生成的实施方案，可以批准、修改或拒绝。一旦方案获得批准，后续阶段将完全自主执行，无需人工干预。 ### 第七阶段：代码实现 implementation-agent 智能体使用 Opus 模型根据批准的方案编写代码。智能体会遵循项目的编码规范，生成符合风格的代码，并确保与现有代码库的一致性。 ### 第八阶段：前置质量门禁 这一阶段并行运行两个检查：deslop-agent 清理可能的 AI 生成代码中的低质量模式，test-coverage-checker 验证测试覆盖率是否达标。两者都使用 Sonnet 模型，确保进入审查阶段的代码具备基本质量。 ### 第九阶段：多智能体并行审查 这是 next-task 最具特色的阶段。系统同时启动四个核心审查智能体：代码质量审查、安全审查、性能审查和测试覆盖审查。根据变更文件的类型，还会动态启动专业审查智能体，如数据库、API、前端、后端、DevOps、架构等方向的专家。 审查过程采用迭代机制，最多运行五轮，并内置停滞检测。如果某轮审查没有提出新问题，流程自动终止以避免无限循环。所有审查意见汇总后，implementation-agent 根据反馈进行修复，然后重新进入审查循环，直到所有门禁通过或达到最大迭代次数。 ### 第十阶段：交付验证 delivery-validator 智能体验证最终产出是否符合项目标准，包括构建成功、测试通过、文档完整等检查点。 ### 第十一阶段：文档同步 sync-docs-agent 智能体自动更新相关文档，确保代码变更与文档描述保持一致，减少技术债务。 ### 第十二阶段：发布 ship 阶段负责创建 Pull Request、触发 CI 流水线、监控构建状态，并在验证通过后自动合并代码到目标分支。 ## 状态持久化与容错机制 next-task 通过两个 JSON 文件实现状态持久化：tasks.json 存储活跃任务注册表（位于主仓库），flow.json 记录工作流进度（位于工作区）。状态目录自动识别主流 AI 编码工具的工作目录（.claude/、.opencode/、.codex/），确保会话重启后可以从断点恢复。 用户可以通过 --resume 参数恢复特定任务，支持按任务 ID 或分支名恢复。--status 命令实时显示当前工作流状态，--abort 命令安全取消并清理资源。 ## 插件生态系统 next-task 采用模块化设计，核心功能通过插件实现： - deslop：第八阶段的 AI 代码清理 - prepare-delivery：第八到第十阶段的测试覆盖、审查编排和交付验证 - sync-docs：第十一阶段的文档同步 - ship：第十二阶段的 PR 创建和合并 这种架构允许团队根据项目需求定制工作流，替换或扩展特定阶段的智能体行为。 ## 技术实现细节 项目基于 agentsys 运行时构建，要求 Git 2.20+（支持工作区功能）、GitHub CLI 或 GitLab CLI、Node.js 18+。智能体间通过标准化接口通信，每个智能体可以指定不同的 Claude 模型以平衡成本和能力。 多智能体并行审查阶段采用并发执行策略，四个核心审查智能体同时运行，专业审查智能体根据文件变更动态调度。这种设计充分利用了并行处理能力，显著缩短了审查周期。 ## 适用场景与局限性 next-task 特别适合以下场景： - 需要批量处理标准化任务的维护项目 - 有明确编码规范和审查流程的团队 - 希望减少重复性工作的开发者 - 追求持续交付自动化的项目 然而，对于高度创造性或架构性任务，全自动流程可能难以替代人工判断。复杂的设计决策、跨系统协调、用户交互设计等仍然需要人类专家的参与。next-task 的价值在于将可标准化的工作自动化，让开发者专注于真正需要创造力的部分。 ## 结语 agent-sh/next-task 代表了 AI 辅助软件开发的新范式：不是简单的代码补全，而是完整的任务生命周期管理。通过十二阶段的精细化编排和多智能体协作，它将"从需求到部署"的完整流程自动化，同时保留关键决策点的人工审核。这种人机协作三次，其余自动完成的模式，既保证了质量门禁的严格执行，又避免了过度自动化带来的风险。随着 AI 智能体能力的持续提升，类似的自动化工作流编排将成为软件开发团队的标配基础设施。