用途：面向难以定位的缺陷与性能回归，采用“回路优先”的调试方式。核心要求是在提出任何理论之前，先建立一个能捕捉用户所述确切症状的紧密信号。
主要能力：提供一套从建立反馈回路、复现与最小化、排序假设、逐条验证预测，到带回归检查地修复、清理与报告的完整流程。可用脚本为 scripts/hitl-loop.template.sh，仅在无法无人值守复现、必须由用户手动操作时复制并编辑使用。
使用方式：第一步建立反馈回路，产出一条能在有缺陷时变红、修复后变绿的命令，并在继续前至少运行一次。回路优先级依次为：到达缺陷接缝的失败测试；针对本地服务器的 curl 或 HTTP 脚本；带固定输入与断言输出的 CLI 调用；检查 DOM、控制台或网络状态的浏览器自动化；重放捕获的请求、事件、跟踪、日志或载荷；用模拟边界调用失败路径的一次性测试架；针对间歇性失败的属性、模糊、压力或重复回路；跨提交、版本、数据集或配置的二分或差分回路；以及基于 HITL 模板的人工回路。回路需满足：能变红、确定性、快速、可由智能体运行。若无法建立回路则停止，说明已尝试内容并请求捕获产物、复现访问权限或临时插桩许可。随后复现并最小化，一次只削减一个变量，每次削减后重跑回路。接着写出 3-5 条排序假设，每条须含可证伪预测。每次只验证一个预测，优先使用调试器、REPL、检查器或查询计划，其次是有针对性的边界插桩，最后才用带唯一标记（如 [DEBUG-a4f2]）的调试日志，并在完成前移除。性能缺陷应先建立基线测量再剖析或二分，日志通常不是首选。修复前若存在正确接缝，将最小复现转为失败回归测试；若无正确接缝，记录为架构风险并保留原回路作为验证命令。修复时先看回归测试失败，再应用满足已确认假设的最小修复，看其通过，并重跑原始未最小化回路。
适用场景：诊断缺陷、调试失败、追踪回归、解释报错、抛异常、失败或变慢行为，以及构建复现与根因定位回路。
限制：资料未提供具体平台、语言、收费或价格信息；若无法建立回路，流程要求停止并请求外部输入，而非继续推测。