第 4 章：Agents——把委派变成可复用角色
Agent 文件不是“人格”，而是角色合同
agents/planner.md、agents/code-reviewer.md、agents/security-reviewer.md 等文件为子任务定义一个窄角色：它能读什么、什么时候被调用、应该输出什么、用哪个模型。优秀的 Agent prompt 不靠“你是一个超级专家”撑场面，而靠边界、证据和验收条件减少漂移。
以 planner 为例，它只声明 Read, Grep, Glob，没有写入工具；这从文件格式层面把“先分析后修改”的职责固化下来。code-reviewer 才拥有 Bash，因为它需要读取 diff、运行检查并复核上下文。
67 个 agents 的组合方式
当前 agents 可以看成四组：
| 组 | 代表 | 作用 |
|---|---|---|
| 核心生命周期 | planner、tdd-guide、code-reviewer、build-error-resolver | 计划、实现、修复、审查 |
| 语言/框架 | typescript-reviewer、python-reviewer、django-reviewer、rust-build-resolver | 将通用流程落到具体技术栈 |
| 质量与安全 | security-reviewer、silent-failure-hunter、pr-test-analyzer、performance-optimizer | 发现高风险问题和验证缺口 |
| 领域与运营 | healthcare-reviewer、network-architect、marketing-agent、chief-of-staff | 将 ECC 延伸到特定业务和运营任务 |
这不是一个硬编码的路由器。多数 harness 由模型根据 agent description 选择角色，ECC 通过命名、描述和根级指令提供“何时委派”的启发式：复杂功能用 planner，改动后用 code-reviewer，安全敏感任务用 security-reviewer，构建失败用 build-error-resolver。
Agent 的最小执行协议
主 Agent 识别任务类型
↓
匹配 agent.description 与当前风险
↓
加载 agent prompt + 允许的 tools
↓
子 agent 读取证据并返回计划/发现/验证结果
↓
主 Agent 决定是否修改，以及如何回写主流程
“子 agent 只返回结果，不天然拥有提交权限”是一个重要边界。Agent 文件本身可以要求使用工具，但最终能否调用、调用多少、是否并行，仍由宿主能力和用户配置决定。
为什么不把所有能力写成 Agent
Agent 适合“角色化委派”，不适合承载全部知识：
- 把每个框架都复制成一个 reviewer 会产生大量重叠提示词。
- 领域知识通常需要在主 agent 内按需加载，更适合 skill。
- 需要硬阻断的规则不应依赖模型是否记得某个 agent。
因此 ECC 的实践是：Agent 负责谁来做，Skill 负责怎么做，Hook 负责什么时候拦，Rule 负责不能做什么。
阅读一个 Agent 的方法
按以下顺序阅读任何 agents/*.md：
- frontmatter：确认角色、工具面和模型偏好。
- “When to use”：确认触发条件是否与别的 agent 重叠。
- workflow/output：确认它是否产出可被主流程消费的证据。
- 安全基线：确认外部内容、秘密和权限边界有没有被明确处理。
- 交叉引用：检查它依赖的 skill、command 或规则是否随安装 profile 一起存在。