
Harness阶段选择矩阵加Agent还是改架构一张决策表全搞定【免费下载链接】harnessA meta-skill that designs domain-specific agent teams, defines specialized agents, and generates the skills they use.项目地址: https://gitcode.com/GitHub_Trending/harness/harnessHarness 是一个面向 Claude Code 的元技能meta-skill你用一句话描述业务领域它就能自动设计出专属的AI Agent 团队并为每个 Agent 生成配套的 Skill。但真正用起来的难题往往不在从零搭建而在于后续——已有的 Harness 需要加一个 Agent、补一个新 Skill或者调整团队架构时难道要把 6 个阶段全部重跑一遍吗当然不用。Harness 内置了一张阶段选择矩阵Phase Selection Matrix根据变更类型直接查表就能知道该执行哪些 Phase、跳过哪些 Phase。这篇文章把这张决策表讲透。Harness 是什么先搞懂 6 阶段工作流阶段选择矩阵要选的对象就是 Harness 的 6 个阶段外加前置的 Phase 0 审计阶段名称核心任务Phase 0现状审计检查现有 Agent / Skill / CLAUDE.md决定执行模式Phase 1领域分析识别任务类型、技术栈、与现有组件的冲突Phase 2团队架构设计选定执行模式与架构模式流水线、扇出/扇入、监督者等 6 种Phase 3Agent 定义生成为每个 Agent 生成.claude/agents/{name}.mdPhase 4Skill 生成为每个 Agent 生成.claude/skills/{name}/SKILL.mdPhase 5集成与编排用编排器Orchestrator串联数据流与错误处理Phase 6验证与测试结构验证、执行测试、触发验证、干跑dry-run记住一条核心原则Harness 不是一次生成、永久不变的静态产物而是一个持续进化的系统。每次变更都应走最小但完整的路径——这正是阶段选择矩阵存在的原因。完整定义见 skills/harness/SKILL.md5 分钟上手指南见 docs/quickstart.md。变更前的第一步Phase 0 现状审计任何变更前Harness 都会先跑 Phase 0一共 4 步读取三处文件.claude/agents/、.claude/skills/、CLAUDE.md分叉执行模式——目录不存在或为空 →「全新搭建」Phase 1–6 全跑已有 Harness 且请求扩展 →「现有扩展」按下面的选择矩阵只跑必要 Phase请求检查/修改/同步 → 进入「运营维护」工作流对比文件清单与 CLAUDE.md 记录检测两者之间的漂移drift向用户汇报审计摘要、确认执行计划后再动手。这一步很关键加 Agent时Phase 1 要做的领域与现状分析其实已经在审计中完成了——这就是矩阵里Agent 添加行可以跳过 Phase 1 的原因。Harness 阶段选择矩阵加 Agent 还是改架构一张表全搞定这就是全文的核心。以下矩阵原文出自 skills/harness/SKILL.md 的现有扩展时的 Phase 选择矩阵变更类型Phase 1 领域分析Phase 2 架构设计Phase 3 Agent 定义Phase 4 Skill 生成Phase 5 集成编排Phase 6 验证测试Agent 添加⏭ 跳过复用 Phase 0 结果只做定位决策✅ 必做含 3-0 查重需要专用 Skill 时才做含 4-0修改编排器✅ 必做Skill 添加/修改⏭ 跳过⏭ 跳过⏭ 跳过✅ 必做含 4-0 查重连接变更时才做✅ 必做架构变更⏭ 跳过✅ 必做仅受影响 Agent含 3-0仅受影响 Skill含 4-0✅ 必做✅ 必做读懂这张表的 3 条规则Phase 1 永远跳过——Phase 0 审计已经完成了领域与现状分析没有理由重复劳动范围收敛到仅受影响——改架构时只重新生成受影响的 Agent 和 Skill而不是推倒重建全队Phase 6 从不出现跳过——无论变更多小重新验证后才能算完成。矩阵怎么用三个典型场景走一遍场景 1加 1 个 Agent6 个 Phase 只实做 3 个以给内容生产团队新增一个 QA 质检 Agent为例Phase 2只做定位决策——新 Agent 放在流水线哪个位置如生成之后、发布之前Phase 3生成qa.md定义文件且必须先过 3-0 查重防止职责重叠的 Agent 换个名字重复积累Phase 4仅当该 Agent 需要专属 Skill 时才生成同样含 4-0 查重Phase 5修改编排器把新成员写进团队构成与任务分配Phase 6结构验证 触发验证。场景 2加 1 个 Skill最轻量的路径直接进Phase 4含 4-0 查重Phase 5只有在该 Skill 要接入多个 Agent、产生连接变更时才需要Phase 6照旧必做。全程 2 步核心工作。场景 3改架构步骤最全但依然不重建比如从流水线Pipeline切换为扇出/扇入Fan-out/Fan-inPhase 2重新设计团队架构6 种架构模式的取舍见 skills/harness/references/agent-design-patterns.mdPhase 3 / 4只重新生成受影响的 Agent 与 SkillPhase 5编排器必须同步修改数据流、执行模式、阶段边界Phase 6除干跑外还要专项检查阶段边界处数据传递是否断裂。为什么验证Phase 6永远是必做因为改 Harness 最大的风险不在你改动的地方而在没被改动却悄悄坏掉的地方。Phase 6 的四道关卡就是为此设计的结构验证Agent 文件位置、frontmatter、引用一致性执行测试用 2~3 个真实场景 Prompt 跑一遍必要时做带 Skill vs 不带 Skill对照触发验证8~10 条应触发 8~10 条边界相似但不应触发的查询干跑dry-run数据流有没有断点、错误场景的兜底路径是否可执行。别忘了两个同步动作变更完成后还有两个收尾动作不能漏变更历史把每次改动记入CLAUDE.md的变更历史表日期 / 变更内容 / 对象 / 原因用于追踪演化方向、防止回归编排器触发词新 Agent / 新 Skill 的触发关键词要补进编排器的 description否则新会话里根本触发不到它。编排器模板与错误处理细节见 skills/harness/references/orchestrator-template.md。小结一张决策表 两条同步动作加 Agent→ 定位 定义 编排 验证加 Skill→ 定义 验证改架构→ 重设计但只动受影响的组件验证永不省略。掌握这张 阶段选择矩阵你的 Harness 就能像生产系统一样持续迭代而不是一改就崩、一崩就重建。 延伸阅读均为仓库内文件工作流与矩阵原文skills/harness/SKILL.md执行模式决策树 6 种架构模式skills/harness/references/agent-design-patterns.md5 个真实团队配置案例skills/harness/references/team-examples.md5 分钟快速上手docs/quickstart.md【免费下载链接】harnessA meta-skill that designs domain-specific agent teams, defines specialized agents, and generates the skills they use.项目地址: https://gitcode.com/GitHub_Trending/harness/harness创作声明:本文部分内容由AI辅助生成(AIGC),仅供参考