Agent Teams 任务委派实战：team-delegate 命令如何管理多 Agent 团队的任务分配与工作负载再平衡

本篇基于 agents 仓库中 agent-teams 插件的 team-delegate 命令定义，讲解 Claude Code 实验性 Agent Teams 场景下的任务委派机制：如何解析团队名与动作标志、执行任务分配（--assign）与定向消息（--message）、分析负载分布并执行再平衡（--rebalance），以及默认展示的委派仪表盘（Delegation Dashboard）的完整输出结构。读完后可掌握在多 Agent 并行开发中监控成员负载、识别空闲/过载成员、依赖感知地调整任务归属的完整操作方法。

命令定位与适用前提

team-delegate 是 agent-teams 插件 提供的 7 个团队管理命令之一，其 frontmatter 定义为「任务委派仪表盘，用于管理团队工作负载、任务分配与再平衡」：

---
description: "Task delegation dashboard for managing team workload, assignments, and rebalancing"
argument-hint: "[team-name] [--assign task-id=member-name] [--message member-name 'content'] [--rebalance]"
---

完整命令集及分工（见 README）：

命令	职责
/team-spawn	用预设或自定义组合生成团队
/team-status	展示团队成员、任务与进度
/team-shutdown	优雅关停团队并清理资源
/team-review	多审查者并行代码审查
/team-debug	竞争假设驱动的并行调试
/team-feature	带文件所有权边界的并行特性开发
/team-delegate	任务委派仪表盘与工作负载管理（本篇主题）

运行前提（来自 插件 README 与 team-spawn 命令）：

1. 设置实验特性标志：export CLAUDE_CODE_EXPERIMENTAL_AGENT_TEAMS=1；
2. 在 ~/.claude/settings.json 中配置显示模式：

{
  "teammateMode": "tmux"
}

可选显示模式："tmux"（每个队友一个 tmux 窗格，推荐）、"iterm2"（iTerm2 标签页，仅 macOS）、"in-process"（同进程运行，默认值）。

3. 插件安装方式：先添加市场再安装插件：

/plugin marketplace add wshobson/agents
/plugin install agent-teams@claude-code-workflows

插件清单 plugin.json 声明版本为 1.0.3，MIT 许可，作者是 Seth Hobson。

前置检查：参数解析与团队状态读取

team-delegate 的执行遵循固定的前置检查流程，所有动作分支（分配/消息/再平衡/仪表盘）都建立在这一步之上：

1. 解析 $ARGUMENTS 中的团队名与动作标志：
   • --assign task-id=member-name：把指定任务分配给指定成员；
   • --message member-name 'content'：向指定成员发送消息；
   • --rebalance：分析并重新平衡工作负载分布。
2. 读取团队配置：从 ~/.claude/teams/{team-name}/config.json 读取成员清单（该文件的结构在 team-communication-protocols 技能中有完整说明）；
3. 调用 TaskList 工具获取当前任务状态快照。

团队配置文件的结构如下（成员发现时只认 name，不认 UUID 或角色别名）：

{
  "members": [
    {
      "name": "security-reviewer",
      "agentId": "uuid-here",
      "agentType": "team-reviewer"
    },
    {
      "name": "perf-reviewer",
      "agentId": "uuid-here",
      "agentType": "team-reviewer"
    }
  ]
}

从源码结构看，该命名约定与 team-spawn 命令 中的注意事项一致：不要用 team-lead 这类角色名作为生成成员的名字（团队创建可能保留角色式命名），并且若生成时因重名被追加了后缀（如 team-lead-2），所有消息与任务必须使用带后缀的实际名称。

动作一：--assign 任务分配

提供 --assign task-id=member-name 标志时，命令按以下四步执行：

1. 从 task-id=member-name 格式中解析任务 ID 与成员名；
2. 调用 TaskUpdate 工具设置任务的 owner；
3. 使用 SendMessage 工具以 type: "message" 通知成员，消息内容为： You've been assigned task #{id}: {subject}. {task description}；
4. 向用户确认：Task #{id} assigned to {member-name}。

其中第 3 步的 message 类型是 通信协议技能 中定义的默认直连消息形式：

{
  "type": "message",
  "recipient": "implementer-1",
  "content": "Your API endpoint is ready. You can now build the frontend form.",
  "summary": "API endpoint ready for frontend"
}

该技能同时给出了更完整的任务委派消息模板——实际委派时，消息中附带 Owned files、Key requirements 与 Interface contract 能让队友更快进入状态，比单句通知更贴合并行开发场景。

消息类型的选择原则值得注意：broadcast 会向每个成员发送 N 条独立消息，消耗与团队规模成正比的资源，仅应用于影响所有人的关键事件（如共享类型文件被更新）；常规的任务分配、协调、集成通知都应使用 type: "message" 点对点发送。

动作二：--message 定向消息

提供 --message member-name 'content' 标志时：

1. 解析成员名与消息内容；
2. 使用 SendMessage 的 type: "message" 发送，recipient 为成员名；
3. 确认：Message sent to {member-name}。

这个分支适合在委派流程外做临时协调，例如在某个接口契约就绪后通知下游成员（消息模板参见 messaging-patterns.md 中的 "Integration Point Notification"）。

动作三：--rebalance 负载再平衡

--rebalance 是 team-delegate 的核心分析动作，分为「分析 → 生成建议 → 用户确认 → 执行」四个阶段。

负载分析规则

1. 统计每位成员的任务数（in_progress + 已分配的 pending）；
2. 识别任务数为 0 的成员（idle，空闲）；
3. 识别任务数 ≥ 3 的成员（overloaded，过载）；
4. 检查可解阻塞（unblock）的被阻塞任务。

这里的「0 个任务 = 空闲」「≥3 个任务 = 过载」是命令内嵌的固定阈值；而 task-coordination-strategies 技能 的负载监控表给出了更宽的失衡信号视角，可互为参照：

信号	含义	处置
某队友空闲、其他成员忙碌	分配不均	重新分配 pending 任务
某队友卡在一个任务上	可能存在阻塞	主动查看、提供帮助
所有任务都被阻塞	依赖问题	先解决关键路径
某队友任务量是其他人的 3 倍	过载	拆分任务或重新分配

该技能给出的再平衡五步法与 --rebalance 的执行路径一致：TaskList 评估现状 → 识别空闲/过载成员 → TaskUpdate 改派任务 → SendMessage 通知受影响成员 → 持续监控吞吐变化。

再平衡建议输出模板

分析完成后，命令按如下模板生成建议（原文档示例完整保留）：

## Workload Analysis

Member          Tasks    Status
─────────────────────────────────
implementer-1   3        overloaded
implementer-2   1        balanced
implementer-3   0        idle

Suggestions:
1. Move task #5 from implementer-1 to implementer-3
2. Assign unassigned task #7 to implementer-3

确认与执行

3. 执行前必须先征求用户确认——再平衡不是自动动作，命令只生成建议，经批准后才落地；
4. 对获批的每个移动，通过 TaskUpdate（改 owner）+ SendMessage（通知新旧成员）执行。

默认行为：委派仪表盘（Delegation Dashboard）

不带任何动作标志时，team-delegate 展示完整仪表盘，四段结构如下（原文档示例完整保留）：

## Delegation Dashboard: {team-name}

### Unassigned Tasks
  #5  Review error handling patterns
  #7  Add integration tests

### Member Workloads
  implementer-1   3 tasks (1 in_progress, 2 pending)
  implementer-2   1 task  (1 in_progress)
  implementer-3   0 tasks (idle)

### Blocked Tasks
  #6  Blocked by #4 (in_progress, owner: implementer-1)

### Suggestions
  - Assign #5 to implementer-3 (idle)
  - Assign #7 to implementer-2 (low workload)

仪表盘的信息组织与团队任务模型的依赖机制直接对应：Blocked Tasks 段展示的 "Blocked by #4" 关系来自任务图的 blockedBy/blocks 依赖边。dependency-graphs 参考文档 总结了常见的依赖图形态及其并行度权衡，例如菱形结构（Diamond）中任务 D 必须等 B、C 都完成，正是仪表盘里「某任务被前置任务阻塞」的典型来源：

           ┌→ Task B ─┐
Task A ──→ ┤          ├→ Task D
           └→ Task C ─┘

依赖设计原则包括：优先宽而浅的图、识别关键路径、谨慎使用 blockedBy（只加真正必需的依赖）、杜绝循环依赖（循环依赖是死锁）。当仪表盘显示「所有任务被阻塞」时，按 task-coordination-strategies 的指引应优先解决关键路径。

与团队生命周期的协作关系

team-delegate 不是孤立命令，它嵌入 team-lead 角色 定义的标准生命周期协议中：

1. Spawn — TeamCreate 创建团队、Agent 工具生成队友（即 /team-spawn）；
2. Assign — TaskCreate 建任务、TaskUpdate 分配（即 /team-delegate --assign 的底层动作）；
3. Monitor — 定期 TaskList、响应成员消息（即 /team-status 与仪表盘）；
4. Collect / Synthesize — 收集并合并成员产出；
5. Shutdown — 向每个成员发送 shutdown_request，等待 shutdown_response（即 /team-shutdown）；
6. Cleanup — TeamDelete 清理团队资源。

team-lead 的 frontmatter 中显式声明了这些工具的允许清单（TeamCreate, TeamDelete, TaskCreate, TaskList, TaskGet, TaskUpdate, SendMessage），这与 通信协议技能的故障排查一节呼应：如果队友提示「看不到 SendMessage」，应检查该 agent 定义中 tools: frontmatter 是否显式列出了 SendMessage、TaskList、TaskGet、TaskUpdate 这些通信与任务工具——在受限工具白名单下，未列出的工具不可用。

插件 README 的最佳实践也直接引用了本命令：「用 /team-status 定期监控进度，若工作分布不均则使用 /team-delegate --rebalance」，并要求「保持小团队（2-4 名队友最优）」——这与 --rebalance 的空闲/过载阈值判断逻辑一脉相承：团队越小，负载信号越清晰，再平衡动作的边际收益越大。

使用要点与提示

• 先查后动：仪表盘（无标志）是只读视图，适合先了解全貌；确认调整意图后再用 --assign 精确改派，或 --rebalance 批量分析；
• 再平衡需人工确认：命令只生成建议，执行前必须经用户批准，这符合 team-lead「不微观管理、在里程碑处检查」的行为准则；
• 名字要用实际生成名：所有 --assign、--message 的 recipient 必须使用 config.json 中的 name（含可能的防冲突后缀），而非角色名或 UUID；
• 临时委派有快捷键：原文档的 Tip 指出，可按 Shift+Tab 进入 Claude Code 内置的 delegate 模式做临时任务委派，作为这些命令的轻量补充（插件 README 第 7 条最佳实践同样提及）；
• 状态消息别走消息通道：结构化状态更新应通过 TaskUpdate 而非 SendMessage 发送 JSON，这是通信协议中明确列出的反模式。

小结

team-delegate 把多 Agent 团队的任务治理浓缩为四个入口：无参数看全量仪表盘、--assign 精确改派、--message 点对点沟通、--rebalance 分析后经确认再平衡。它的实现依赖 Claude Code Agent Teams 提供的 TaskList/TaskUpdate/SendMessage/TaskCreate 工具族与 ~/.claude/teams/{team-name}/config.json 团队配置；再平衡的负载阈值、依赖图分析与消息类型选择则分别由 task-coordination-strategies、dependency-graphs 和 team-communication-protocols 三个技能提供方法论支撑。理解这条「命令—工具—技能」三层结构，就能在并行代码审查、假设驱动调试与并行特性开发等场景中，稳定地管理 Agent 团队的任务流与负载分布。