核心概述
harness-engineer 是一套面向 Claude Code 和 OpenClaw 环境的生产级自主工程系统，通过六大核心原则将任意代码库转化为具备自我改进能力的软件系统。
核心用法
该 skill 采用三阶段子代理模型（Research → Plan → Implement）运行。用户激活后，系统自动按序读取：CLAUDE.md/AGENTS.md（基础上下文）、CONFIG.yaml（运行时配置）、runtime/loop.md（执行模型），随后进入持续循环。典型触发场景包括：自主编码代理搭建、自愈代码库构建、多代理软件开发编排、文档驱动工作流实现等。
显著优点
系统性架构设计：六大原则覆盖从上下文工程到人类监督的完整闭环。40% 上下文规则、生成-审查隔离、三层递归审查等机制在工程层面解决了大模型长上下文衰减和自我验证盲区问题。
安全优先设计：工具沙箱隔离、敏感路径强制屏蔽、破坏性操作默认阻断三重防护。优化优先级明确为 Security → Correctness → Reliability → Performance → Memory → Maintainability → Cost。
故障驱动改进：与传统调试不同，该 skill 将失败视为"harness gap"，要求修复系统本身而非仅处理症状，实现持续元改进。
潜在局限
部署门槛较高：需完整阅读 PLATFORM_REQUIREMENTS.md 并通过五项平台能力验证，手动配置项繁多（CONFIG.yaml 参数调优、分支保护策略等）。
资源消耗显著：三层递归审查 + 多代理并行（默认 3 个）对 token 和计算资源需求较大，小型项目可能过度设计。
人类依赖未完全消除：架构变更、PR 合并、连续模式启用等关键节点仍需人工审批，"自主"程度受 P6 原则约束。
适合人群
- 维护中大型代码库、需长期迭代的专业开发团队
- 追求工程化 AI 代理工作流的研究者
- 已有 Claude Code/OpenClaw 环境且愿意投入初期配置成本的用户
常规风险
- 配置错误风险：CONFIG.yaml 参数误设（如过早调高 max_parallel_agents）可能导致代理风暴或资源耗尽
- 分支污染风险：沙盒分支验证不足即启用 continuous 模式，可能污染主分支历史
- 上下文幻觉：尽管强调"代码优于文档"，但 MEMORY.md 中的历史失败记录若未更新，可能引入过时假设
- MCP 工具边界：工具注册表配置不当可能导致权限越界，需严格遵循 tools/TOOL_REGISTRY.md 的 per-agent 子集分配