63 lines
5.1 KiB
Markdown
63 lines
5.1 KiB
Markdown
---
|
||
title: "Agents Orchestrator"
|
||
type: source
|
||
tags: []
|
||
date: 2026-04-20
|
||
---
|
||
|
||
## Source File
|
||
- [[Agent/agency-agents/specialized/agents-orchestrator.md]]
|
||
|
||
## Summary（用中文描述）
|
||
- 核心主题：AI 多智能体开发流水线编排器，自主管理从规格到交付的完整开发流程
|
||
- 问题域：多专业 Agent 协同工作流中，如何确保每个任务通过质量验证后才推进，如何处理失败和重试
|
||
- 方法/机制：四阶段流水线（PM→ArchitectUX→[Dev↔QA循环]→最终集成）；基于截图证据的质量门控；最大3次重试上限
|
||
- 结论/价值：通过强制性质量门控和 Dev-QA 循环，确保只有通过验证的功能才能推进，最终交付符合规格要求的生产就绪产品
|
||
|
||
## Key Claims（用中文描述）
|
||
- AgentsOrchestrator 通过持续 Dev-QA 循环实现任务级质量验证，每个任务必须通过 EvidenceQA 的截图验证才能推进
|
||
- 四阶段流水线（PM→ArchitectUX→[Dev↔QA循环]→最终集成）确保从规格到生产的完整质量覆盖
|
||
- 最大重试次数为3次，超过后进行升级处理，避免无限循环同时保证任务有足够修正机会
|
||
- AgentsOrchestrator 提供标准化状态报告模板，实现流水线进度的透明化追踪
|
||
|
||
## Key Quotes
|
||
> "Each task must pass QA before advancing." — 质量门控原则：每个任务必须通过 QA 验证才能推进到下一任务
|
||
> "Default to 'NEEDS WORK' unless overwhelming evidence proves production readiness." — testing-reality-checker 的默认判断原则，确保交付标准严格
|
||
> "Maximum 3 attempts per task before escalation." — 重试上限机制，防止任务无限循环
|
||
> "No shortcuts: Every task must pass QA validation." — 强制性质量验证，无例外原则
|
||
|
||
## Key Concepts
|
||
- [[Dev-QA-Loop]]：开发与质量验证的持续循环机制——每个任务完成后由 EvidenceQA 进行截图验证，通过后推进下一个任务，失败则回到开发阶段并携带具体反馈
|
||
- [[Quality-Gate]]：质量门控机制——任务必须通过质量验证才能推进到下一阶段的强制性检查点
|
||
- [[EvidenceQA]]：基于截图证据的质量验证专家 Agent——要求视觉证据作为验证依据，提供明确的 PASS/FAIL 判定及具体反馈
|
||
- [[Pipeline-State-Management]]：流水线状态管理——追踪当前任务、所处阶段、完成状态，在 Agent 间传递上下文信息，处理错误并实现恢复
|
||
- [[Agent-Handoff]]：Agent 交接协议——在多个专业 Agent 之间传递完整的上下文和具体指令，确保下一 Agent 获得足够信息执行任务
|
||
- [[Continuous-Dev-QA-Loop]]：持续开发质量循环——开发与 QA 交替进行，每个开发交付物立即经过 QA 验证，形成快速反馈闭环
|
||
|
||
## Key Entities
|
||
- [[AgentsOrchestrator]]：编排器自身——自主流水线管理器，协调从规格到生产的完整开发流程（来源页面）
|
||
- [[ArchitectUX]]：技术架构师 Agent——负责基于规格和任务列表创建技术架构和 UX 基础
|
||
- [[EvidenceQA]]：截图质量验证 Agent——通过截图证据对每个任务实现进行质量验证
|
||
- [[ProjectManagerSenior]]：高级项目经理 Agent——负责将规格文档转化为详细的任务列表
|
||
- [[TestingRealityChecker]]：最终集成验证 Agent——在所有任务通过后进行最终集成测试，默认为"需要改进"原则
|
||
- [[FrontendDeveloper]]：前端开发者 Agent——负责 UI/UX 任务的实现
|
||
- [[BackendArchitect]]：后端架构师 Agent——负责服务端架构和 API 开发
|
||
- [[MobileAppBuilder]]：移动应用构建 Agent——负责移动端应用开发
|
||
- [[DevOpsAutomator]]：DevOps 自动化 Agent——负责基础设施任务
|
||
|
||
## Connections
|
||
- [[AgentsOrchestrator]] ← spawns ← [[ProjectManagerSenior]]（Phase 1：编排器启动项目经理创建任务列表）
|
||
- [[AgentsOrchestrator]] ← spawns ← [[ArchitectUX]]（Phase 2：编排器启动架构师创建技术基础）
|
||
- [[AgentsOrchestrator]] ← spawns ← [[EvidenceQA]]（Phase 3：每个任务的 QA 验证）
|
||
- [[AgentsOrchestrator]] ← spawns ← [[TestingRealityChecker]]（Phase 4：最终集成测试）
|
||
- [[ArchitectUX]] ← depends_on ← [[ProjectManagerSenior]]（架构基于任务列表）
|
||
- [[Dev-QA-Loop]] ← extends ← [[Multi-Agent-System-Reliability]]（流水线编排是多 Agent 可靠性的实践框架）
|
||
- [[AgentsOrchestrator]] ← part_of ← [[The Agency]]（编排器是 The Agency 的核心基础设施）
|
||
|
||
## Contradictions
|
||
- 与 [[specialized-workflow-architect]] 冲突：
|
||
- 冲突点：两个 Agent 都声称负责"编排"职责——前者是流水线执行编排器，后者是工作流设计专家
|
||
- 当前观点：AgentsOrchestrator 是执行层面的流水线管理器，强调任务级质量门控和自动化重试逻辑
|
||
- 对方观点：Workflow Architect 是设计层面的工作流架构师，专注工作流模式设计和流程建模
|
||
- 说明：两者不存在功能重叠——Workflow Architect 设计工作流，AgentsOrchestrator 执行工作流，属设计与执行的分层关系
|