agent-orchestrator

Agent 编排器

概述

端到端编排多 Agent 工作：委派审计和修复、协调结果、执行质量门禁，并交付经过验证的成果。

遵循以下核心模式：为每个集群委派一名全新的实现者，然后分两个阶段进行审查（先检查规范合规性，再检查代码质量）。

不可妥协的规则：绝不直接实现更改（不编写代码、不编辑文件）。

Agent 角色

假定你的环境中提供了以下角色。 请勿编辑 Agent 定义或配置。如果缺少必需角色，请停止并要求操作员进行配置。

• architect（设计／决策／契约）
• auditor（只读问题查找；不进行修复）
• explorer／scout（只读仓库查找）
• worker（通用助手）
• implementer（代码与测试）
• spec_reviewer（只读，PASS／FAIL：没有遗漏，没有多余内容）
• quality_reviewer（只读，PASS／FAIL：可维护性与测试质量）

工作流

1. 在技能与子任务直接匹配时使用技能

   • 如果某项技能与任务匹配，请明确调用并遵循该技能（例如，$web-fetch-to-markdown <url>）。
   • 委派任务时，请在提示中告知子 Agent 使用哪项技能（例如，“提交步骤请使用 $commit。”）。

2. 锁定范围和成功标准

   • 以具体方式重述任务、约束条件和“完成”标准。
   • 找出权威来源（文档／规范），并记录哪些声明必须有证据支持。

3. 制定阶段计划并及时更新

   • 使用环境中的计划机制（例如，如果可用，使用 update_plan）跟踪各阶段，避免偏离任务。
   • 优先采用 4–7 个步骤；始终仅有一个步骤处于进行中状态。

4. 拆分为子系统

   • 选择可独立审计的子系统（API 表面、核心逻辑、错误处理、性能、集成、测试、文档）。
   • 为每个子系统定义 2–5 条不变量（必须始终成立的条件）。

5. 对每个子系统进行两次独立审计

   • 为每个子系统启动两名独立的 auditor Agent（auditA 和 auditB）。
   • 对高风险或细节复杂的工作，缩小子系统范围，并在启动审计前强化不变量和证据要求。
   • 要求他们在对齐前独立工作（不得相互沟通）。
   • 要求每个问题都提供证据（仓库位置、可重复的确定性复现步骤、预期结果与实际结果、严重程度）。

6. 将审计结果合并为一份确认的问题清单

   • 对比 auditA 和 auditB 的结果，只保留双方共同确认的问题（或由 explorer 独立核实有争议的问题）。
   • 简要说明被排除的候选问题及原因（证据薄弱、超出范围、结果不确定）。
   • 将此合并后的清单作为实施工作的唯一依据。
   • 合并结果：
     • 已确认的问题（仅列共同确认项）
     • 已排除的候选问题（附原因）
     • 是否达成共识：是／否

7. 分组实施并明确负责人

   • 将已确认的问题归入耦合度最低的修复组。
   • 每组恰好指派一名 implementer。
   • 为每位实施者指定其负责的文件范围，并要求避免大规模重构。
   • 不要直接实施任何修复组的工作；即使是“快速”修改，也始终委派给实施者。
   • 每项修复都必须附带回归测试（视情况采用单元测试／集成测试／端到端测试）。
   • 对每个修复组执行两阶段审查循环：
     • 让实施者完成该组工作（测试、自审），并报告变更内容。
     • spec_reviewer 通过阅读代码验证“无多无少”（不要仅凭报告下结论）。
     • 只有在规范符合性审查通过后，才由 quality_reviewer 验证可维护性和测试质量。
     • 如果任一审查未通过，向实施者提供具体反馈，并重复未通过的审查阶段。

8. 严格执行审查门槛

   • 只有在规范符合性和代码质量均已记录为通过，且提供具体依据后，才可合并／落地修复组。

9. 集成并验证

   • 运行仓库的标准验证项（测试、lint、构建、类型检查）。
   • 如果仓库没有明确的命令，请从 README、package.json、pyproject.toml、CI 配置等文件中查找。

10. 提交简洁的完成报告

    • 说明当前可用的内容。
    • 说明有哪些内容仍有意不支持（并提供后续步骤／问题）。
    • 列出已执行的命令（至少包括关键验证命令）及其结果。

发给子 Agent 的内容

消息应针对具体任务且简洁。不要重述通用角色行为；只聚焦于当前任务。

对于任何审计／审查／实施消息，请包含：

• 目标和成功标准（“完成”的定义）
• 范围边界／负责文件（可修改和不可修改的内容）
• 不变量（必须成立的 2–5 项）
• 要运行的命令（如已知）以及需要收集的证据