在 Claude Code 里搭专家团队，真不是起几个好听的角色名那么简单。真正头疼的是这些问题：什么时候该让多个 agent 互相协作沟通，什么时候只用一个专家就够，中间结果由谁来存，任务完成的节点又该谁来拍板。Harness 的整套工作流，就是冲着解决这些问题来的。

第一步：先审计已有项目

Harness 的 SKILL.md 里把 Phase 0 放在了最开头：先检查 `.claude/agents/`、`.claude/skills/` 这两个目录，还有 `CLAUDE.md` 文件。这一步特别重要，因为真实项目里大多早就有旧的 agent、旧的 skill，或是之前定好的团队规范。

要是啥都没有，就走新建流程；已经有一部分的，就走扩展路线；要是发现已经有完整的团队结构了，那就偏向维护和调整。这么分岔处理，能避免凭空生成一堆名字差不多、职责还重叠的专家。

第二步：把任务拆成团队问题

接下来是领域分析。Harness 会先梳理这个项目长期需要哪些能力：是调研、编码、测试、写文档，还是发布、安全、评审、数据处理？这里判断的不是单次任务的需求，而是那些会反复出现的工作类型。

比如一个项目每次发布都得改代码、补迁移文档、跑回归测试、写发行说明，那就很适合拆出实现者、测试者、文档专员和协调者这几个角色。每个角色的输入、输出还有停止条件，都得明明白白的。

第三步：决定 Agent Teams 还是 subagents

官方文档给了很明确的划分标准：如果有两个以上的 agent 需要互相沟通、碰撞想法、传递上下文，那默认用 Agent Teams 模式；要是只是单次找专家咨询，不需要互相沟通的，用 subagent 就够了，更轻量。

选哪种模式影响还挺大的。Agent Teams 能保留整个团队的会话和协作状态，但 token 成本更高，而且还有限制：同一时间只能有一个活跃的 team，也不能嵌套 team。subagent 虽然快又简单，但没有成员之间互相讨论的过程。

第四步：生成 agent 和 skill

到了文件生成这一步，agent 的定义会存到 `.claude/agents/{name}.md` 里，skill 则存到 `.claude/skills/{name}/SKILL.md`。Agent 文件里要写清楚角色、模型、职责、沟通方式；Skill 文件里则要写触发条件、流程步骤、工具用法还有验证方法。

成熟的团队不会把所有知识都塞到 agent 里。稳定的流程应该下沉到 skill 里，复杂的细节则放到 references 里。这样 agent 负责做判断，skill 负责提供执行方法，目录结构才不会越用越乱。

第五步：用 orchestrator 串起来

orchestrator 是整个团队的调度层。模板里会用到 TeamCreate、TaskCreate、SendMessage 这类动作，还用 `_workspace/` 目录来存中间产物。它的作用不是再造一个啥都能干的万能专家，而是让每个专家都能在对的时间拿到对的材料。

比如文档团队可以先让 researcher 去收集事实，再让 writer 起草内容，接着让 reviewer 检查准确性，最后由 orchestrator 汇总所有产物。每一步都有明确的输入输出，就算出问题失败了，也知道该回到哪个节点调整。

最后一步：验证不是走过场

Harness 的验证环节包含好几个部分：目录结构检查、执行模式验证、skill 触发测试、dry-run 试运行，还有有无 skill 的对照测试。说白了，它不光看文件有没有生成出来，还要确认 Claude Code 是不是真的能按预期触发这套团队流程。

这也是它和随便手写几个配置文件的区别。Harness 真正关心的是这套团队能不能跑起来：谁接任务，谁做产出，谁来复核，谁负责收尾。专家团队根本不是一张名字列表，而是一套能重复执行的工作流。