Skip to content

子 Agent 调用映射

本文是当前平台 唯一权威的调用映射来源:明确每条命令触发哪个 agent、该 agent 可以调用哪些子 agent、以及贯穿全链路的管控约束。

所有 agent(role + specialist)必须同时遵循 agent-governance.md 中的统一管控策略。


1. 调用模型说明

平台采用两层 agent 调用模型:

用户命令
  └─ 主链 Role Agent(owner,对产出负最终责任)
       ├─ 可调用 Specialist Agent(分析、评审、规划)
       └─ 产出落盘到 docs/artifacts/ 或通过 /handoff 交接下游 Role Agent
  • Role Agent:有主责输出、交接责任、需落盘
  • Specialist Agent:只产出建议,结论必须回落到 Role Agent 的输出中
  • 调用方式:在 Claude 对话中明确说 用 <agent-id> 角色执行,或通过 runSubagent 工具调用(agent 名称对应 agents/roles/agents/specialists/ 中的文件名去掉 .md

2. 主链命令 → Role Agent 映射

命令调用 Role Agent可调用 Specialist典型输出
/team-intaketech-leadplanner(复杂需求拆解)、ui-ux-designer(涉及 UI 时提供初步体验约束)prd.md + requirement-challenge 输入
/team-plantech-leadplannerarchitectui-ux-designerproject-manager(动态分组讨论与挑战会)delivery-plan.mdarch-design.mddesign-review 结论
/handoff当前主责角色handoff 结构化记录,写入下游,推进到 handoff-ready
/team-executebackend-engineerfrontend-engineerplannerbuild-error-resolver(遇到构建失败)、语言 reviewer(问题定位)、loop-operator(多轮验证)execute-log.md,前提为 handoff-ready
/team-reviewqa-engineercode-reviewersecurity-reviewer、语言 reviewer、tdd-guidetest-plan.md,放行结论
/team-releasedevops-engineerchief-of-staff(跨角色同步)、harness-optimizer(平台审计)release-plan.md

3. Specialist 命令 → Specialist Agent 映射

命令调用 Specialist Agent结论回落
/planplanner回落到 /team-plan/handoff
/tddtdd-guide回落到 /team-execute/team-review
/code-reviewcode-reviewer回落到 /team-review/handoff
/build-fixbuild-error-resolver(通用),或 java-build-resolvergo-build-resolverrust-build-resolverpython-reviewertypescript-reviewerkotlin-build-resolverpytorch-build-resolver(语言专项)回落到 /team-execute
/verifyloop-operatortdd-guide回落到 /team-review/team-execute
/multi-frontendplanner 编排,frontend-engineer 执行回落到 /team-execute
/multi-backendplanner 编排,backend-engineer 执行回落到 /team-execute
/harness-auditharness-optimizer输出平台改进建议,更新 docs/memory/

4. Role Agent 之间的标准传递路径

product-manager
      │ PRD、用户故事、UI/UX 约束摘要

  tech-lead ◄────────────────────────── 所有冲突/升级
      │ Delivery Plan、任务拆解
      ├──────────────────────────────────────────┐
      ▼                                          ▼
  architect ──► frontend-engineer ◄── ui-ux-designer
      │ ADR        │ 前端实现           │ 交互流、设计 token
      │            │                    │ 体验风险清单
      ▼            ▼                    │
  backend-engineer ──────► qa-engineer ◄┘
      │ 后端实现、自测       │ 测试计划、放行建议
      │                    │
      └────────────────────┼──► devops-engineer
                           │         │ 发布方案、回滚
                           ▼         ▼
                       tech-lead(最终收口)

每次传递必须经过 /handoff,结构化字段见 handoff-contract.md


5. 并行调用场景

以下场景允许多个 agent 并行调用,使用 parallel-execution skill 或 Git worktree 隔离:

场景并行 Agent 组合汇总角色
需求挑战会product-manager + project-manager + architect + tech-leadtech-lead
四方并行设计architect + ui-ux-designer + frontend-engineer + backend-engineertech-lead(Design Review Board)
多服务后端多个 backend-engineer 实例(按服务拆分)planner 编排 → tech-lead 收口
多模块前端多个 frontend-engineer 实例(按页面拆分)planner 编排 → tech-lead 收口
Build-fix 并行多个语言 build-resolver 并发修复各模块build-error-resolver 汇总

并行任务之间禁止写冲突;共享状态通过文件传递,由汇总角色负责合并。

5.1 动态分组规则

/team-plan 不能只按固定四方并行启动,必须按任务类型动态装配最小讨论组:

任务特征基础参与角色增补角色
业务目标/范围不清product-managerproject-managertech-leadarchitect
架构/接口/数据模型变更architectbackend-engineerproject-managertech-leadfrontend-engineer(若影响 UI)
UI / 体验变更product-managerui-ux-designerfrontend-engineertech-leadarchitectbackend-engineer
全栈改动architectfrontend-engineerbackend-engineerproject-managertech-leadui-ux-designerdevops-engineer

每个被拉入的角色都必须对上游输入提出至少 1 条质疑,并把结论回落到 /team-plan/handoff


6. 单次 agent 调用的标准流程

无论是 role agent 还是 specialist agent,每次调用都必须:

  1. 读取自身 agent 文件agents/roles/<id>.mdagents/specialists/<id>.md
  2. 确认管控约束:遵循 agent-governance.md
  3. 确认输入依据:来源 artifact、handoff 记录或用户输入
  4. 执行并产出:按角色定义的标准输出
  5. 落盘或交接:role agent 必须落盘;specialist agent 结论回落到 role agent 输出
  6. 升级判断:命中升级条件时,立即通知 tech-lead

7. 相关文档

Released under the MIT License.