Test Team Coordination

---
name: test-team-coordination
description: >
  对团队执行测试场景，观察协调模式行为，评估验收标准，并生成结构化的
  RESULT.md。适用于验证团队的协调模式在实际任务中是否产生预期行为、比较不同
  协调模式在等效工作负载上的表现，或为团队组合建立基准性能。
locale: zh-CN
source_locale: en
source_commit: befb7ac1 # stale — source updated for teams infrastructure fix
fence_basis_commit: befb7ac1
translator: claude-opus-4-6
translation_date: 2026-03-16
license: MIT
allowed-tools: Read Write Edit Bash Grep Glob Agent SendMessage TaskCreate
metadata:
  author: Philipp Thoss
  version: "1.0"
  domain: review
  complexity: advanced
  language: natural
  tags: review, testing, teams, coordination, validation
---

# 测试团队协调

从 `tests/scenarios/teams/` 中执行针对目标团队的测试场景。观察协调模式行为，评估验收标准，对评分标准打分，并在 `tests/results/` 中生成 `RESULT.md`。

## 适用场景

- 验证团队的协调模式是否产生预期行为
- 在修改团队定义或智能体后运行结构化测试
- 通过对不同团队运行相同场景来比较协调模式
- 为团队组合建立基准性能指标
- 添加新智能体或更改团队成员后的回归测试

## 输入

- **必填**：测试场景文件的路径（如 `tests/scenarios/teams/test-opaque-team-cartographers-audit.md`）
- **可选**：运行 ID 覆盖（默认：自动生成 `YYYY-MM-DD-<target>-NNN`）
- **可选**：团队规模覆盖（默认：来自场景前置元数据）
- **可选**：跳过范围变更（默认：false——若已定义，则注入范围变更）

## 步骤

### 第 1 步：加载并验证测试场景

1.1. 读取输入中指定的测试场景文件。

1.2. 解析 YAML 前置元数据并提取：
   - `target` — 要测试的团队
   - `coordination-pattern` — 预期模式
   - `team-size` — 要生成的成员数量
   - 验收标准表
   - 评分标准（如存在）
   - 基准真相数据（如存在）

1.3. 验证场景文件包含所有必需章节：
   - 目标
   - 前提条件
   - 任务（含主要任务子章节）
   - 预期行为
   - 验收标准
   - 观察协议

**预期结果：** 场景文件已加载、解析，并包含所有必需章节。

**失败处理：** 若文件缺失或无法解析，以识别缺失文件或格式错误章节的错误信息中止。若可选章节（评分标准、基准真相、变体）缺失，记录其缺失并继续。

### 第 2 步：验证前提条件

2.1. 遍历场景中每个前提条件复选框。

2.2. 对文件存在性检查，使用 Glob 验证。

2.3. 对注册表计数检查，解析相关的 `_registry.yml` 并将 `total_*` 与磁盘上的实际文件数量比较。

2.4. 对分支/git 状态检查，运行 `git status --porcelain` 和 `git branch --show-current`。

**预期结果：** 所有前提条件均已满足。

**失败处理：** 若任何前提条件失败，将其记录为 BLOCKED。决定是否继续（软性前提条件）或中止（硬性前提条件，如目标团队文件缺失）。记录决策过程。

### 第 3 步：加载协调模式标准

3.1. 读取 `tests/_registry.yml` 并找到与场景 `coordination-pattern` 值匹配的 `coordination_patterns` 条目。

3.2. 提取此模式的 `key_behaviors` 列表。

3.3. 这些行为成为观察清单——每条都必须在执行期间观察，并记录为已观察/未观察。

**预期结果：** 模式关键行为已加载并准备好观察。

**失败处理：** 若协调模式未在注册表中定义，使用场景的预期行为章节作为唯一观察来源。记录警告。

### 第 4 步：执行任务

4.1. 创建结果目录：`tests/results/YYYY-MM-DD-<target>-NNN/`。

4.2. 记录 T0（任务开始时间戳）。

4.3. 使用场景中的团队规模通过 TeamCreate 生成目标团队。逐字传递场景任务章节中的主要任务提示。

4.4. 观察团队的执行阶段。记录以下时间戳：
   - T1：形式评估/任务分解完成
   - T2：角色分配可见

4.5. 若场景定义了范围变更触发器且 skip-scope-change 为 false：
   - 等到第 2 阶段（角色分配）可见
   - 记录 T3（范围变更注入时间戳）
   - 通过 SendMessage 向团队发送范围变更提示
   - 记录 T4（范围变更已吸收——角色调整可见）

4.6. 继续观察直到团队交付输出。
   - 记录 T5（整合开始）
   - 记录 T6（最终报告已交付）

4.7. 捕获团队的完整输出。

**预期结果：** 团队通过其协调模式阶段执行任务。所有转换的时间戳均已记录。范围变更（如适用）已注入并被吸收。

**失败处理：** 若团队无法产生输出，记录失败点和任何错误信息。若团队停滞，记录最后观察到的阶段和超时。以部分结果继续评估。

### 第 5 步：评估模式行为

5.1. 对第 3 步中的每个关键行为，确定在执行期间是否观察到：
   - **已观察**：团队输出或协调中有清晰证据
   - **部分**：有一些证据但不完整或模糊
   - **未观察**：无证据

5.2. 对场景预期行为章节中的每个特定任务行为，应用相同的评估。

5.3. 在观察日志中记录发现。

**预期结果：** 大部分或全部特定模式和特定任务行为已被观察到。

**失败处理：** 未观察到的行为是发现，而非测试程序的失败。准确记录它们——它们表明协调模式未完全显现。

### 第 6 步：评估验收标准

6.1. 遍历场景中的每个验收标准。

6.2. 对每个标准分配一个判定：
   - **PASS**：标准明确满足，有可观察的证据
   - **PARTIAL**：标准部分满足（以 0.5 权重计入阈值）
   - **FAIL**：尽管有机会但标准未满足
   - **BLOCKED**：无法评估（前提条件失败、团队超时等）

6.3. 若场景包含基准真相数据，对照其验证报告的发现：
   - 按类别计算准确率百分比
   - 标记假阳性和假阴性

6.4. 若场景包含评分标准，对每个维度打 1-5 分并附简短理由。

6.5. 计算摘要指标：
   - 验收：X/N 标准通过（PARTIAL 计为 0.5）
   - 阈值：如果 >= 场景中定义的阈值则 PASS
   - 评分总计：X/Y 分（如适用）

**预期结果：** 所有验收标准都有判定。摘要指标已计算。

**失败处理：** 若少于一半的标准可以评估（太多 BLOCKED），测试运行不确定。记录原因并建议修复前提条件后重新运行。

### 第 7 步：生成 RESULT.md

7.1. 使用场景观察协议中的记录模板创建 `tests/results/YYYY-MM-DD-<target>-NNN/RESULT.md`。

7.2. 填写所有章节：
   - 运行元数据（观察者、时间戳、持续时间）
   - 附所有记录时间戳的阶段日志
   - 角色涌现日志（用于自适应/团队测试）
   - 验收标准结果表
   - 评分标准表（如适用）
   - 基准真相验证表（如适用）
   - 关键观察（叙述性）
   - 经验教训

7.3. 将团队的原始输出作为附录或同一结果目录中的独立文件（`team-output.md`）包含。

7.4. 在顶部添加摘要判决：
   ```text
   **Verdict**: PASS | FAIL | INCONCLUSIVE
   **Score**: X/N criteria (Y/Z rubric points)
   **Duration**: Xm
   ```

**预期结果：** 完整的 RESULT.md，所有章节已填写，有明确的判决。

**失败处理：** 若结果文件无法写入，将结果输出到 stdout 作为备用。评估数据永远不应丢失。

## 验证清单

- [ ] 测试场景文件已加载，所有必需章节存在
- [ ] 前提条件已验证（或记录为 BLOCKED）
- [ ] 协调模式关键行为已从注册表加载
- [ ] 团队已生成并交付任务
- [ ] 范围变更已在正确时机注入（如适用）
- [ ] 所有特定模式行为已评估（已观察/部分/未观察）
- [ ] 所有验收标准都有判定（PASS/PARTIAL/FAIL/BLOCKED）
- [ ] 基准真相验证已完成（如适用）
- [ ] RESULT.md 已生成，所有章节已填写
- [ ] 摘要判决已计算并记录

## 常见问题

- **评估输出质量而非协调**：此技能测试*团队如何协调*，而非任务输出是否完美。一个协调良好但只找到 7/9 个损坏引用的团队仍然展示了该模式。
- **过早注入范围变更**：在角色分配清晰可见之前等待注入范围变更。过早意味着团队尚未分化，没有什么需要适应的。
- **混淆团队成员输出与团队输出**：不透明团队应该呈现统一的输出。若你看到个别成员的报告，这是关于透明度的发现，而非测试基础设施问题。
- **精确的基准真相匹配**：基准真相计数是近似值。评估发现是否在正确范围内，而非是否精确匹配。
- **忘记记录时间戳**：时间戳对于测量阶段持续时间和适应速度至关重要。在事件发生时设置，而不是事后补记。

## 相关技能

- `review-codebase` — 与团队级测试互补的深度代码库评审
- `review-skill-format` — 验证单个技能格式（此技能验证团队协调）
- `create-team` — 创建此技能测试的团队定义
- `evolve-team` — 根据测试发现演进团队定义
- `test-a2a-interop` — A2A 协议一致性的类似测试模式
- `assess-form` — 不透明团队负责人内部使用的形式评估