ECC Harness Optimizer以最小可逆改动调优 Agent 可靠性、成本与吞吐【免费下载链接】ECCThe agent harness performance optimization system. Skills, instincts, memory, security, and research-first development for Claude Code, Codex, Opencode, Cursor and beyond.项目地址: https://gitcode.com/GitHub_Trending/ev/ECCECCEverything Claude Code仓库中的harness-optimizer是一个专门负责“调优 Agent 运行框架harness配置”的角色型 Agent其核心思路是不重写产品代码而是通过审计、定位杠杆点、施加最小可逆改动并量化前后差异来提升 Agent 的完成质量、可靠性、成本与吞吐。本文以 .kiro/agents/harness-optimizer.md 为骨架结合 scripts/harness-audit.js、commands/harness-audit.md 与 skills/eval-harness/SKILL.md 的源码与文档完整讲解这个 Agent 的使命、五步工作流、约束边界与输出契约并说明它在 Kiro 与 Claude Code 双形态下的差异与落地方式。什么是 Harness Optimizerharness-optimizer在仓库中存在两种形态Kiro 形态本文主角.kiro/agents/harness-optimizer.mdYAML frontmatter 声明如下--- name: harness-optimizer description: Analyze and improve the local agent harness configuration for reliability, cost, and throughput. allowedTools: - read ---CLI 形态.kiro/agents/harness-optimizer.json 内嵌同一份 promptallowedTools为fs_readmcpServers为空对象。根据 .kiro/README.md 的约定.md供 Kiro IDE 通过/菜单或自动选择调用.json供kiro-cli通过/agent swap切换两者同时提供以保证兼容性。从两份文件的allowedTools都可以确认Kiro 形态的 harness-optimizer 是只读的。它的全部职责是“分析并提出”即产出基线记分卡、改动建议、预期改进与残留风险实际写操作由主仓形态承担见下文对比。核心使命改配置不改产品代码文档中的 Mission 只有一句话但定义了职责边界Raise agent completion quality by improving harness configuration, not by rewriting product code. 通过改进 harness 配置而非重写产品代码来提升 Agent 完成质量。也就是说它的操作面限定在 harness 配置层——hooks、evals、routing模型/任务路由、context上下文管理、safety安全护栏——而不是业务源码。这一边界在 agents/harness-optimizer.mdClaude Code 主仓版本中被进一步显式化为两条硬性禁令不得重写应用/产品代码也不得在 harness 配置面hooks、agents、skills、commands 元数据、settings之外做任何改动。两种形态的定位差异值得注意维度Kiro 形态.kiro/agents/harness-optimizer.md主仓形态agents/harness-optimizer.md工具权限仅read只读分析Read, Grep, Glob, Bash, Edit可执行基线手段调用/harness-audit收集基线分数直接运行node scripts/harness-audit.js repo --format json子 Agent 不能调用斜杠命令变更方式提出最小可逆配置变更交由人/主流程应用先快照git stash create等再应用失败自动回滚评分方法报告前后差异before/after deltas按 skills/eval-harness/SKILL.md 的 EVAL DEFINITION → EVAL REPORT 方法论计算 passk / pass^k从源码结构看Kiro 形态是主仓形态的“只读分析版”前者负责诊断与方案输出后者把同样的诊断流程加上执行、回归验证与评分闸门形成闭环。五步优化工作流文档的 Workflow 是标准的“度量—定位—最小改动—验证—报告”循环运行/harness-audit收集基线分数识别前 3 个杠杆点leverage areashooks、evals、routing、context、safety 五个候选面中取收益最高的 3 个提出最小、可逆的配置变更应用变更并运行验证报告 before/after 差异第 1 步的底座确定性审计引擎/harness-audit命令的定义见 commands/harness-audit.md其使用方式为/harness-audit [scope] [--format text|json] [--root path]scope可选repo默认、hooks、skills、commands、agents--formattext默认面向人或json面向自动化--root审计指定路径而非当前工作目录该命令明确要求始终运行确定性脚本作为唯一评分来源禁止即兴发明额外维度或临时计分node scripts/harness-audit.js scope --format text|json [--root path]评分标准rubric版本号为2026-05-19。在 scripts/harness-audit.js 中可以看到完整实现12 个固定类别每类归一化为 0–10 分。前 7 类恒适用Tool Coverage、Context Efficiency、Quality Gates、Memory Persistence、Eval Coverage、Security Guardrails、Cost Efficiency第 8 类 GitHub Integration 恒适用第 9–12 类Vercel / Netlify / Cloudflare / Fly Integration仅在检测到对应部署标记文件时才适用如vercel.json、netlify.toml、wrangler.toml、fly.toml检测逻辑见脚本中PROVIDERS与getApplicableProviders。总分不固定overall_score与max_score由适用类别决定命令契约明确要求“不要假设固定总分”。自动识别目标形态detectTargetMode会判断被审计目录是 ECC 仓库本身repo模式检查hooks/hooks.json、scripts/hooks/、agents/、skills/等还是使用 ECC 的消费方项目consumer模式检查插件是否安装、.claude/覆盖、AGENTS.md、CI、安全策略等。Top 3 行动项按失分项的points降序取前 3附带类别、建议动作与具体文件路径top_actions。确定性可复现同一 commit 下重复运行得到相同分数因为所有分数都由显式文件/规则检查推导。text 输出的典型形态取自命令文档中的示例Harness Audit (repo, repo): 71/80 - Tool Coverage: 10/10 (10/10 pts) - Context Efficiency: 9/10 (9/10 pts) - Quality Gates: 10/10 (10/10 pts) - GitHub Integration: 2/10 (2/10 pts) Top 3 Actions: 1) [GitHub Integration] Add at least one workflow under .github/workflows/. (.github/workflows/) 2) [Security Guardrails] Add prompt/tool preflight security guards in hooks/hooks.json. (hooks/hooks.json) 3) [Eval Coverage] Increase automated test coverage across scripts/hooks/lib. (tests/)对 harness-optimizer 而言这份记分卡就是“基线分数卡”Output 契约的第一项第 2 步的杠杆点识别正是围绕其中失分最多的类别展开例如Security Guardrails失分指向 hooks 面Context Efficiency失分指向 context 面Eval Coverage失分指向 evals 面。第 2–5 步杠杆点、可逆改动与差异报告第 2 步识别杠杆点文档将候选面固定为 hooks、evals、routing、context、safety 五类且只取前 3避免一次动太多。第 3 步最小可逆变更与约束一一对应——每次改动应小、可回滚、效果可度量。主仓形态进一步要求“动文件前先快照git diff/git stash create基线或文件副本”并把 diff 限制在目标杠杆面内禁止顺手修改。第 4 步应用并验证Kiro 只读形态下此步由人执行主仓形态则重跑node scripts/harness-audit.js repo --format json与node tests/run-all.jstests/run-all.js 是中央测试入口作为回归闸门任一失败即自动恢复快照绝不交回半应用的配置。第 5 步报告差异输出前后分数与具体改动的对照即 Output 契约的后三项。四条约束为什么这样改才“安全”文档 Constraints 一节给出四条硬性约束每条都对应一类真实的翻车场景Prefer small changes with measurable effect优先小而有可测效果的改动——单次大重构无法归因小步改动才能把审计分数变化归因到具体配置项。Preserve cross-platform behavior保持跨平台行为——harness 配置往往同时服务于多个 Agent 运行时改动必须在各平台表现一致。Avoid introducing fragile shell quoting避免引入脆弱的 shell 引号——hooks 命令若包含复杂引号嵌套在不同 shell / 平台上极易静默失败。Keep compatibility across Claude Code, Cursor, OpenCode, and Codex保持四大平台兼容——ECC 的定位就是跨 harness 的配置体系这一点在主仓形态中被同样强调。这四条约束实际上定义了 harness 配置的“改动允许域”只允许在行为可预测、可回滚、可跨平台复现的范围内做增量。输出契约四件必须交付的事文档 Output 一节规定 harness-optimizer 的每次产出必须包含baseline scorecard基线记分卡——第 1 步审计得到的overall_score / max_score、各类别分数与top_actionsapplied changes已应用的变更——具体的配置 diff 或建议 diffmeasured improvements实测改进——重新审计后的分数变化remaining risks残留风险——未覆盖的失分项与潜在回归面。主仓形态则把该契约升级为EVAL REPORT: harness-optimization格式并附加状态位READY FOR REVIEW / SHIP IT / BLOCKED其中安全敏感的 diff扩大工具权限、凭据访问路径、弱化既有安全控制等在记录人类批准前永远不允许报 SHIP IT只能停留在 BLOCKED。与 Eval Harness 的关系从记分卡到评分方法论Kiro 形态以/harness-audit的确定性分数作为度量基准主仓形态则进一步要求所有改动按 skills/eval-harness/SKILL.md 的 eval-driven developmentEDD方法论评分二者是互补关系Capability Evals能力评估检验 harness 改动是否让 Agent 获得此前没有的能力对应本文五个杠杆面采用passkk 次尝试中至少成功一次能力面推荐 pass3 ≥ 90%Regression Evals回归评估确保既有 hooks、测试与质量门不被破坏安全关键路径采用pass^kk 次全部成功即连续 3 次全过才报告 pass^3三类 GraderCode-Based脚本/测试退出码确定性优先、Model-Based模型自评 diff 质量、Human安全/安全相关变更必须由人裁决。该技能同时列出了 eval 反模式——只测 happy path、为已知样例过拟合 prompt、在追通过率时忽视成本与延迟漂移、让 flaky grader 进入发布闸门——这些反模式对 harness 调优同样适用调优目标若只盯审计分数而忽视成本与延迟就背离了“reliability, cost, and throughput”三位一体的使命。在 Kiro 中使用安装与调用按 .kiro/README.md 的 Quick StartKiro 适配层可以整体安装到任意 Kiro 项目# 进入 .kiro 目录 cd .kiro # 安装到指定项目 ./install.sh /path/to/your/project # 或安装到当前目录 ./install.sh # 或全局安装对所有 Kiro 项目生效 ./install.sh ~安装器采用非破坏性拷贝不会覆盖已有文件因此项目内的二次定制在重装后依然保留。安装后IDE 中在会话输入/直接选择 agent如/harness-optimizerCLI 中运行/agent swap选择 agent或启动时指定kiro-cli --agent harness-optimizer。需要注意的是Kiro 形态的模型选择跟随你在 Kiro 中当前的模型设定不由 agent 配置本身决定且由于该 agent 只被授予read权限它输出的“applied changes”本质上是建议清单实际落盘需要你在主仓形态或人工侧执行——这正是其只读设计带来的安全边界调优建议可以被完整审查后再应用。小结.kiro/agents/harness-optimizer.md用不到 40 行定义了一个职责高度收敛的调优角色以 scripts/harness-audit.js 的确定性记分卡为基线在 hooks / evals / routing / context / safety 五个面中挑选前 3 个杠杆点做最小可逆改动并以“基线记分卡 已应用变更 实测改进 残留风险”四件套交付。它的工程价值不在于单点技巧而在于把“Agent 框架调优”变成一条可复现、可回滚、可跨 Claude Code / Cursor / OpenCode / Codex 验证的流程——审计脚本保证同一 commit 下分数可复现约束清单把改动限制在安全域内eval-harness 方法论则为改进提供 passk / pass^k 的量化标尺。【免费下载链接】ECCThe agent harness performance optimization system. Skills, instincts, memory, security, and research-first development for Claude Code, Codex, Opencode, Cursor and beyond.项目地址: https://gitcode.com/GitHub_Trending/ev/ECC创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 ECC Harness Optimizer：以最小可逆改动调优 Agent 可靠性、成本与吞吐
ECC Harness Optimizer以最小可逆改动调优 Agent 可靠性、成本与吞吐【免费下载链接】ECCThe agent harness performance optimization system. Skills, instincts, memory, security, and research-first development for Claude Code, Codex, Opencode, Cursor and beyond.项目地址: https://gitcode.com/GitHub_Trending/ev/ECCECCEverything Claude Code仓库中的harness-optimizer是一个专门负责“调优 Agent 运行框架harness配置”的角色型 Agent其核心思路是不重写产品代码而是通过审计、定位杠杆点、施加最小可逆改动并量化前后差异来提升 Agent 的完成质量、可靠性、成本与吞吐。本文以 .kiro/agents/harness-optimizer.md 为骨架结合 scripts/harness-audit.js、commands/harness-audit.md 与 skills/eval-harness/SKILL.md 的源码与文档完整讲解这个 Agent 的使命、五步工作流、约束边界与输出契约并说明它在 Kiro 与 Claude Code 双形态下的差异与落地方式。什么是 Harness Optimizerharness-optimizer在仓库中存在两种形态Kiro 形态本文主角.kiro/agents/harness-optimizer.mdYAML frontmatter 声明如下--- name: harness-optimizer description: Analyze and improve the local agent harness configuration for reliability, cost, and throughput. allowedTools: - read ---CLI 形态.kiro/agents/harness-optimizer.json 内嵌同一份 promptallowedTools为fs_readmcpServers为空对象。根据 .kiro/README.md 的约定.md供 Kiro IDE 通过/菜单或自动选择调用.json供kiro-cli通过/agent swap切换两者同时提供以保证兼容性。从两份文件的allowedTools都可以确认Kiro 形态的 harness-optimizer 是只读的。它的全部职责是“分析并提出”即产出基线记分卡、改动建议、预期改进与残留风险实际写操作由主仓形态承担见下文对比。核心使命改配置不改产品代码文档中的 Mission 只有一句话但定义了职责边界Raise agent completion quality by improving harness configuration, not by rewriting product code. 通过改进 harness 配置而非重写产品代码来提升 Agent 完成质量。也就是说它的操作面限定在 harness 配置层——hooks、evals、routing模型/任务路由、context上下文管理、safety安全护栏——而不是业务源码。这一边界在 agents/harness-optimizer.mdClaude Code 主仓版本中被进一步显式化为两条硬性禁令不得重写应用/产品代码也不得在 harness 配置面hooks、agents、skills、commands 元数据、settings之外做任何改动。两种形态的定位差异值得注意维度Kiro 形态.kiro/agents/harness-optimizer.md主仓形态agents/harness-optimizer.md工具权限仅read只读分析Read, Grep, Glob, Bash, Edit可执行基线手段调用/harness-audit收集基线分数直接运行node scripts/harness-audit.js repo --format json子 Agent 不能调用斜杠命令变更方式提出最小可逆配置变更交由人/主流程应用先快照git stash create等再应用失败自动回滚评分方法报告前后差异before/after deltas按 skills/eval-harness/SKILL.md 的 EVAL DEFINITION → EVAL REPORT 方法论计算 passk / pass^k从源码结构看Kiro 形态是主仓形态的“只读分析版”前者负责诊断与方案输出后者把同样的诊断流程加上执行、回归验证与评分闸门形成闭环。五步优化工作流文档的 Workflow 是标准的“度量—定位—最小改动—验证—报告”循环运行/harness-audit收集基线分数识别前 3 个杠杆点leverage areashooks、evals、routing、context、safety 五个候选面中取收益最高的 3 个提出最小、可逆的配置变更应用变更并运行验证报告 before/after 差异第 1 步的底座确定性审计引擎/harness-audit命令的定义见 commands/harness-audit.md其使用方式为/harness-audit [scope] [--format text|json] [--root path]scope可选repo默认、hooks、skills、commands、agents--formattext默认面向人或json面向自动化--root审计指定路径而非当前工作目录该命令明确要求始终运行确定性脚本作为唯一评分来源禁止即兴发明额外维度或临时计分node scripts/harness-audit.js scope --format text|json [--root path]评分标准rubric版本号为2026-05-19。在 scripts/harness-audit.js 中可以看到完整实现12 个固定类别每类归一化为 0–10 分。前 7 类恒适用Tool Coverage、Context Efficiency、Quality Gates、Memory Persistence、Eval Coverage、Security Guardrails、Cost Efficiency第 8 类 GitHub Integration 恒适用第 9–12 类Vercel / Netlify / Cloudflare / Fly Integration仅在检测到对应部署标记文件时才适用如vercel.json、netlify.toml、wrangler.toml、fly.toml检测逻辑见脚本中PROVIDERS与getApplicableProviders。总分不固定overall_score与max_score由适用类别决定命令契约明确要求“不要假设固定总分”。自动识别目标形态detectTargetMode会判断被审计目录是 ECC 仓库本身repo模式检查hooks/hooks.json、scripts/hooks/、agents/、skills/等还是使用 ECC 的消费方项目consumer模式检查插件是否安装、.claude/覆盖、AGENTS.md、CI、安全策略等。Top 3 行动项按失分项的points降序取前 3附带类别、建议动作与具体文件路径top_actions。确定性可复现同一 commit 下重复运行得到相同分数因为所有分数都由显式文件/规则检查推导。text 输出的典型形态取自命令文档中的示例Harness Audit (repo, repo): 71/80 - Tool Coverage: 10/10 (10/10 pts) - Context Efficiency: 9/10 (9/10 pts) - Quality Gates: 10/10 (10/10 pts) - GitHub Integration: 2/10 (2/10 pts) Top 3 Actions: 1) [GitHub Integration] Add at least one workflow under .github/workflows/. (.github/workflows/) 2) [Security Guardrails] Add prompt/tool preflight security guards in hooks/hooks.json. (hooks/hooks.json) 3) [Eval Coverage] Increase automated test coverage across scripts/hooks/lib. (tests/)对 harness-optimizer 而言这份记分卡就是“基线分数卡”Output 契约的第一项第 2 步的杠杆点识别正是围绕其中失分最多的类别展开例如Security Guardrails失分指向 hooks 面Context Efficiency失分指向 context 面Eval Coverage失分指向 evals 面。第 2–5 步杠杆点、可逆改动与差异报告第 2 步识别杠杆点文档将候选面固定为 hooks、evals、routing、context、safety 五类且只取前 3避免一次动太多。第 3 步最小可逆变更与约束一一对应——每次改动应小、可回滚、效果可度量。主仓形态进一步要求“动文件前先快照git diff/git stash create基线或文件副本”并把 diff 限制在目标杠杆面内禁止顺手修改。第 4 步应用并验证Kiro 只读形态下此步由人执行主仓形态则重跑node scripts/harness-audit.js repo --format json与node tests/run-all.jstests/run-all.js 是中央测试入口作为回归闸门任一失败即自动恢复快照绝不交回半应用的配置。第 5 步报告差异输出前后分数与具体改动的对照即 Output 契约的后三项。四条约束为什么这样改才“安全”文档 Constraints 一节给出四条硬性约束每条都对应一类真实的翻车场景Prefer small changes with measurable effect优先小而有可测效果的改动——单次大重构无法归因小步改动才能把审计分数变化归因到具体配置项。Preserve cross-platform behavior保持跨平台行为——harness 配置往往同时服务于多个 Agent 运行时改动必须在各平台表现一致。Avoid introducing fragile shell quoting避免引入脆弱的 shell 引号——hooks 命令若包含复杂引号嵌套在不同 shell / 平台上极易静默失败。Keep compatibility across Claude Code, Cursor, OpenCode, and Codex保持四大平台兼容——ECC 的定位就是跨 harness 的配置体系这一点在主仓形态中被同样强调。这四条约束实际上定义了 harness 配置的“改动允许域”只允许在行为可预测、可回滚、可跨平台复现的范围内做增量。输出契约四件必须交付的事文档 Output 一节规定 harness-optimizer 的每次产出必须包含baseline scorecard基线记分卡——第 1 步审计得到的overall_score / max_score、各类别分数与top_actionsapplied changes已应用的变更——具体的配置 diff 或建议 diffmeasured improvements实测改进——重新审计后的分数变化remaining risks残留风险——未覆盖的失分项与潜在回归面。主仓形态则把该契约升级为EVAL REPORT: harness-optimization格式并附加状态位READY FOR REVIEW / SHIP IT / BLOCKED其中安全敏感的 diff扩大工具权限、凭据访问路径、弱化既有安全控制等在记录人类批准前永远不允许报 SHIP IT只能停留在 BLOCKED。与 Eval Harness 的关系从记分卡到评分方法论Kiro 形态以/harness-audit的确定性分数作为度量基准主仓形态则进一步要求所有改动按 skills/eval-harness/SKILL.md 的 eval-driven developmentEDD方法论评分二者是互补关系Capability Evals能力评估检验 harness 改动是否让 Agent 获得此前没有的能力对应本文五个杠杆面采用passkk 次尝试中至少成功一次能力面推荐 pass3 ≥ 90%Regression Evals回归评估确保既有 hooks、测试与质量门不被破坏安全关键路径采用pass^kk 次全部成功即连续 3 次全过才报告 pass^3三类 GraderCode-Based脚本/测试退出码确定性优先、Model-Based模型自评 diff 质量、Human安全/安全相关变更必须由人裁决。该技能同时列出了 eval 反模式——只测 happy path、为已知样例过拟合 prompt、在追通过率时忽视成本与延迟漂移、让 flaky grader 进入发布闸门——这些反模式对 harness 调优同样适用调优目标若只盯审计分数而忽视成本与延迟就背离了“reliability, cost, and throughput”三位一体的使命。在 Kiro 中使用安装与调用按 .kiro/README.md 的 Quick StartKiro 适配层可以整体安装到任意 Kiro 项目# 进入 .kiro 目录 cd .kiro # 安装到指定项目 ./install.sh /path/to/your/project # 或安装到当前目录 ./install.sh # 或全局安装对所有 Kiro 项目生效 ./install.sh ~安装器采用非破坏性拷贝不会覆盖已有文件因此项目内的二次定制在重装后依然保留。安装后IDE 中在会话输入/直接选择 agent如/harness-optimizerCLI 中运行/agent swap选择 agent或启动时指定kiro-cli --agent harness-optimizer。需要注意的是Kiro 形态的模型选择跟随你在 Kiro 中当前的模型设定不由 agent 配置本身决定且由于该 agent 只被授予read权限它输出的“applied changes”本质上是建议清单实际落盘需要你在主仓形态或人工侧执行——这正是其只读设计带来的安全边界调优建议可以被完整审查后再应用。小结.kiro/agents/harness-optimizer.md用不到 40 行定义了一个职责高度收敛的调优角色以 scripts/harness-audit.js 的确定性记分卡为基线在 hooks / evals / routing / context / safety 五个面中挑选前 3 个杠杆点做最小可逆改动并以“基线记分卡 已应用变更 实测改进 残留风险”四件套交付。它的工程价值不在于单点技巧而在于把“Agent 框架调优”变成一条可复现、可回滚、可跨 Claude Code / Cursor / OpenCode / Codex 验证的流程——审计脚本保证同一 commit 下分数可复现约束清单把改动限制在安全域内eval-harness 方法论则为改进提供 passk / pass^k 的量化标尺。【免费下载链接】ECCThe agent harness performance optimization system. Skills, instincts, memory, security, and research-first development for Claude Code, Codex, Opencode, Cursor and beyond.项目地址: https://gitcode.com/GitHub_Trending/ev/ECC创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考