ARTICLE DETAIL

建站实战干货

来自一线的建站与推广经验沉淀,每一条都经过真实交付验证。

Harness 重复 Agent 审查:如何避免“同名不同义“的 Agent 团队臃肿

2026/9/16 19:31:34 拓冰建站 浏览量
Harness 重复 Agent 审查:如何避免“同名不同义“的 Agent 团队臃肿 Harness 重复 Agent 审查如何避免同名不同义的 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 的 Agent 团队架构工厂一句话描述领域它就能生成一队各司其职的多 Agent 团队和配套技能。但用多了你会发现一个坑——Agent 越建越多却同名不同义团队日益臃肿。本文带你用 Harness 内置的重复 Agent 审查机制Phase 0 现状审计 Phase 3-0 / 4-0 查重学会给多 Agent 团队瘦身。为什么多 Agent 团队会臃肿如果你重复搭建过 Harness一定会遇到这个现象角色重叠的 Agent 以不同名字不断堆积。比如先是analyst.md后来又出现researcher.md、insight-agent.md——名字不同干的却都是调研分析这一件事。危害很直接协调成本上升SKILL.md 里写得很直白——3 名专注的队员胜过 5 名走神的队员职责模糊任务分给谁两个分析师谁说了算上下文浪费每个 Agent 定义文件都要占上下文重复的角色只会稀释重点重复审查Phase 0 现状审计先看家底Harness 的重复审查不是拍脑袋查重而是一条固定的流水线。第一步是Phase 0 现状审计技能被触发时先读取项目的.claude/agents/、.claude/skills/和CLAUDE.md把三类记录相互对照找出drift漂移——实际文件与文档记录对不上的地方。然后根据审计结果分流见 SKILL.md现状走哪条路目录不存在或为空全新搭建走完整流程已有 Harness要加新 Agent/技能按需只跑部分 Phase要做哈内斯审计/同步进入运维维护工作流先审后建是避免重复的最简单习惯。新建 Agent 前先过查重这一关Phase 3-0这是重复审查的核心环节。在生成新的 Agent 定义文件之前Phase 3-0 会强制检查项目里已有的.claude/agents/确认新角色是否真的缺重复构建 Harness 时角色重叠的 Agent 很容易以不同名字堆积起来。 —— SKILL.md Phase 3-0同样地Phase 4-0 会在生成新的SKILL.md之前对照.claude/skills/做技能层面的查重SKILL.md。注意这两步不是可选建议而是硬性要求产出物检查清单里有专门的两条——新建 Agent 前完成与现有 Agent 的查重Phase 3-0、新建技能前完成与现有技能的查重Phase 4-0见 SKILL.md。去重判断表4 种情况的处理标准查重之后怎么办Harness 在 agent-design-patterns.md 的Agent 复用设计一节给出了一张可以直接照抄的决策表情况处理现有 Agent 已完全覆盖新角色❌ 禁止新建 —— 直接复用现有 Agent部分重叠、且可以泛化泛化现有 Agent 并扩展有意为之的领域特化允许新建保持独立角色范围完全不同允许新建配一条核心原则一个 Agent 只专注一个角色可复用性才高、重复才少。如果一个 Agent 同时背了两个角色先想清楚能不能拆。⚠️ 一个常见误区同名不等于重复。真正的重复是职责被另一个 Agent 完全覆盖。名字像但服务对象不同比如代码审查 Agent和安全审查 Agent反而不该合并。什么时候该泛化——停在责任边界处去重不只是删还要判断该不该泛化。skill-writing-guide.md 的技能复用设计章节给了一个很实用的例子假设有一个fintech 风险评估报告 PDF技能逐步泛化会这样步骤结果去掉 fintech 依赖变成评估报告 PDF —— 如果职责就是评估报告停在这里再去掉评估依赖变成PDF 格式化 —— 如果已有这个技能别再建新的复用即可规则一句话泛化永远做不完所以停在有意的责任边界处——领域特化是有意保留的只清理偶然的耦合。另外泛化会改变技能/Agent 的适用范围依赖它的 Agent 行为可能跟着变所以指南要求泛化前先确认依赖关系泛化后用 dry-run 验证原有行为没被破坏。查重的思路分清谁和怎么做查重时还要分清 Agent 和 Skill 的分工对照表见 agent-design-patterns.md技能SkillAgent本质程序性知识专家角色定义回答怎么做谁来做位置.claude/skills/.claude/agents/所以查重复要两条腿走路技能查重看流程是否已被另一个技能覆盖Agent 查重看角色是否已被另一个 Agent 覆盖。1 个 Agent 可以对应 1~N 个技能多个 Agent 也能共享同一个技能——共享本身不是重复盲目复制才是。持续审查用变更历史防止二次臃肿审查一次不够Harness 把审查变成持续动作。Phase 7 的演进机制SKILL.md做三件事收集反馈每次运行后问用户有什么要改进的按反馈类型修对应位置质量问题改技能、角色问题改 Agent 定义、顺序问题改编排器记变更历史所有改动写入CLAUDE.md的 4 列表格日期 / 改动内容 / 对象 / 原因这份变更历史就是团队的进化日志Harness 朝哪个方向长了、为什么长一目了然还能防回退。日常维护则走 4 步现状审计 → 渐进式增改一次只动一处→ 更新变更历史 → 验证改动SKILL.md。这些查重机制正是 Harness 近期新增的CHANGELOG.md 记录了 Phase 3-0 / 4-0 查重阶段、Agent 复用设计与技能复用设计两个新章节以及检查清单中新增的两项复用审查条目。动手清单给你的 Agent 团队做个体检 ✅照下面 5 步自查一遍团队立刻清爽审计家底对照.claude/agents/、.claude/skills/与CLAUDE.md记录找出 drift过决策表对每个疑似重复项套用上面的 4 行判断表定责任边界该泛化的泛化该保留的特化停在有意边界处查依赖再动手合并/泛化前确认编排器和依赖方改完 dry-run 验证记变更历史每处改动都进CLAUDE.md的变更历史表记住 Harness 的核心原则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/harness创作声明:本文部分内容由AI辅助生成(AIGC),仅供参考