GOOD: Parallel execution

Launch 3 agents in parallel:

1. Agent 1: Security analysis of auth module
2. Agent 2: Performance review of cache system
3. Agent 3: Type checking of utilities

First agent 1, then agent 2, then agent 3

解读这条规则，需要理解它的适用前提——「independent operations」。三个任务（认证模块安全分析、缓存系统性能审查、工具类类型检查）彼此没有数据依赖、不会改动同一批文件、结论互不引用，因此完全可以并发跑，让三个子 Agent 共享同一窗口期分别产出报告；若强行串行，总耗时为三者之和，且串行等待期间没有获得任何额外信息收益。

ECC 的实际工作流把这种 fan-out（扇出）模式工程化了。仓库中的 [workflows/orch-review.workflow.js](https://gitcode.com/GitHub_Trending/ev/ECC/blob/22e8cf01d0b54719b3a49002fab2ccbda4ff5b9e/workflows/orch-review.workflow.js?utm_source=gitcode_repo_files#L1-L9) 描述了一个名为 `orch-review` 的 Claude Code workflow：其 Review 阶段定义为 **「one reviewer agent per dimension, in parallel」**——按维度并行启动多个 reviewer Agent，之后进入 Verify 阶段，对每条 CRITICAL/HIGH 发现做对抗性验证。该文件还内置了语言到专项 reviewer 的映射表（`LANGUAGE_REVIEWER`，见 [workflows/orch-review.workflow.js](https://gitcode.com/GitHub_Trending/ev/ECC/blob/22e8cf01d0b54719b3a49002fab2ccbda4ff5b9e/workflows/orch-review.workflow.js?utm_source=gitcode_repo_files#L34-L50)），例如 `typescript/javascript → ecc:typescript-reviewer`、`python → ecc:python-reviewer`、`go → ecc:go-reviewer`、`rust → ecc:rust-reviewer`，与 `agents/` 目录实际存在的定义一一对应。

在实践中有几点边界值得遵守：

- **只对无依赖任务并行**。若任务 B 的输出是任务 A 的输入，则必须串行，否则会出现空跑或基于过期上下文的结果。
- **关注文件的写冲突**。多个 Agent 同时编辑同一文件可能相互覆盖；审查、分析、检索类只读任务天然适合并行，改造类任务应先做文件范围划分。
- **并行意味着更快的整体时延与更高的瞬时 token 消耗**，大规模扇出时需要考虑成本预算（ECC 本身也提供了 cost-tracking 类的技能与命令用于观测）。

## 五、多视角分析：为复杂问题拆分对抗性子角色

规则文档的最后一部分给出了另一条编排思想：**面对复杂问题时，拆出多个对立/互补视角的子角色，让它们从不同立场审视同一份材料**。原文列举的角色包括：

- **Factual reviewer**（事实核查者）：核实结论与依据是否真实存在、来源是否可靠；
- **Senior engineer**（资深工程师）：从工程经验角度评估方案可行性与实现质量；
- **Security expert**（安全专家）：专门寻找漏洞、注入、越权等风险面；
- **Consistency reviewer**（一致性审查者）：检查各部分的结论、术语、风格是否前后一致；
- **Redundancy checker**（冗余检查者）：剔除重复内容与无效信息。

这一方法论的工程化产物遍布仓库。最典型的例证是 `agents/` 目录下的评审 Agent 家族：除通用 [code-reviewer](https://gitcode.com/GitHub_Trending/ev/ECC/blob/22e8cf01d0b54719b3a49002fab2ccbda4ff5b9e/agents/code-reviewer.md?utm_source=gitcode_repo_files) 外，还按语言拆出了 go-reviewer、python-reviewer、typescript-reviewer、rust-reviewer、java-reviewer、cpp-reviewer、csharp-reviewer、fsharp-reviewer、kotlin-reviewer、php-reviewer、swift-reviewer、react-reviewer、flutter-reviewer、django-reviewer、fastapi-reviewer 等专项定义，并配套 `rules/` 下的分语言规则目录（如 [rules/golang](https://gitcode.com/GitHub_Trending/ev/ECC/blob/22e8cf01d0b54719b3a49002fab2ccbda4ff5b9e/rules/golang?utm_source=gitcode_repo_files)、[rules/typescript](https://gitcode.com/GitHub_Trending/ev/ECC/blob/22e8cf01d0b54719b3a49002fab2ccbda4ff5b9e/rules/typescript?utm_source=gitcode_repo_files)），形成「语言规则 + 语言评审 Agent」的双重约束。

此外，审查过程本身也内置了「对抗」机制：[agents/code-reviewer.md](https://gitcode.com/GitHub_Trending/ev/ECC/blob/22e8cf01d0b54719b3a49002fab2ccbda4ff5b9e/agents/code-reviewer.md?utm_source=gitcode_repo_files#L29-L50) 定义了 **Confidence-Based Filtering** 与 **Pre-Report Gate**——要求评审者只报告置信度 >80% 的真实问题，写每条发现前必须能回答「能否定位到具体文件行、能否描述具体失败模式、是否已读周边上下文、是否会误导决策」四个问题，否则降级或丢弃该发现。这正对应多视角分析中「Factual reviewer 防止臆断」的诉求：分角色不是为了堆砌意见，而是让每种意见都经过事实门槛。

对于 Agent 编排的落地，建议将其压缩为一道固定工序：**先让 planner/architect 从「设计与实现」视角产出方案，再让 tdd-guide 从「可测试性」视角补齐测试计划，随后让 code-reviewer 从「质量」视角、security-reviewer 从「安全」视角（提交前）审查改动**。多个视角各看各的，再合并去重，最终得到的结论覆盖度远高于单一大模型的单次输出。

## 六、Agent 定义的载体：frontmatter 驱动的能力声明

了解上述 Agent 的调用方式之后，有必要理解它们的「本体」——即 `agents/*.md` 文件为什么能被 Harness 正确识别。这类文件的元信息全部位于 YAML frontmatter：

```yaml
---
name: tdd-guide
description: Test-Driven Development specialist enforcing write-tests-first methodology. ...
tools: Read, Write, Edit, Bash, Grep
model: sonnet
---