测试团队协调

从

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. 在顶部添加摘要判决：

**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

  — 不透明团队负责人内部使用的形式评估