// Agent Harness Evolution — 基于 HARNESS.md v1.0 规范的评估、审计与改进工作流。加载后自动检查当前 workspace 结构合规性，引导 evidence-driven 的 Harness 改进。当用户要求做 Harness 审计、初始化 Agent workspace、生成或验证 Change Manifest、对 harness 组件做 evidence-driven 改进，或反复出现同一类失败模式时触发。
Install and use the bundled agent debugger CLI source to configure adb LLM settings, download Langfuse traces, ask QA questions about traces, and run adb check quality analysis. Use when the task is about agent-debugger CLI workflows, trace debugging, or explaining how adb is configured.
NexAU agent evolution reference for a simple starting agent. Use when adding tools, middleware, sub-agents, or skills during evolution. Covers all available components, YAML config schema, and creation guides. Reference docs in reference/ for deep dives.
| name | agentic-harness-engineering |
| description | Agent Harness Evolution — 基于 HARNESS.md v1.0 规范的评估、审计与改进工作流。加载后自动检查当前 workspace 结构合规性，引导 evidence-driven 的 Harness 改进。当用户要求做 Harness 审计、初始化 Agent workspace、生成或验证 Change Manifest、对 harness 组件做 evidence-driven 改进，或反复出现同一类失败模式时触发。 |
将 AHE（Agentic Harness Engineering） 论文的核心模式实现为可执行的 Skill。 遵循 HARNESS.md v1.0 规范。
评估当前 workspace 是否符合 HARNESS.md v1.0 规范。
扫描当前 workspace 结构
检查组件正交性
检查 Change Manifest 存在性
输出审计报告
## Harness Audit Report — 2026-05-21
**合规度评分: 7/10**
| 组件 | 状态 | 说明 |
|------|------|------|
| System Rules | ✅ | AGENTS.md + SOUL.md 分离清晰 |
| Tool Descriptions | ✅ | 每个工具都有独立 YAML |
| Tool Implementations | ⚠️ | 部分工具的 description 和实现不同步 |
| Middleware | ❌ | 未定义 middleware 目录 |
| Skills | ✅ | skills/ 目录组织良好 |
| Sub-Agents | ⚠️ | sub_agents/ 目录存在但未注册 |
| Long-Term Memory | ✅ | MEMORY.md + experiences.md 分离 |
**改进建议：**
1. 排查 tools/vs tool_descriptions/ 的同步性
2. 考虑添加 middleware/ 目录
3. 在 code_agent.yaml 中注册 sub_agents
在对 Harness 组件做出修改时，生成标准化的 Change Manifest。
你已经发现了问题并准备修改。在修改前或修改后，运行这个流程来记录变更。
将以下内容写入 manifests/change_{timestamp}.json：
{
"manifest_version": "1.0",
"harness_spec_version": "1.0",
"iteration": <当前迭代编号>,
"timestamp": "<当前时间 ISO 格式>",
"author": "<agent-name>",
"changes": [
{
"change_id": "ch_<编号>",
"component": "<system_rules|tool_descriptions|tool_implementations|middleware|skills|sub_agents|long_term_memory>",
"subtype": "<update|create|delete|register>",
"file_path": "<修改的文件路径>",
"summary": "<一句话描述修改>",
"failure_evidence": "<什么失败了 + 证据>",
"root_cause": "<根因分析>",
"targeted_fix": "<具体修改内容>",
"predicted_impact": {
"expected_fixes": ["<预期修复的任务>"],
"at_risk_regressions": ["<可能回归的任务>"],
"rationale": "<为什么这么预测>"
}
}
],
"verification": {
"status": "pending",
"scheduled_at": "<下次验证时间>"
}
}
验证之前生成的 Change Manifest 的预测是否准确。
expected_fixes 中的任务是否确实通过了？at_risk_regressions 中的任务是否确实没有回归？{
"verification": {
"status": "<verified|reverted|partial>",
"scheduled_at": "<上次设置的验证时间>",
"completed_at": "<当前时间>",
"result": {
"expected_fixes_verified": ["<实际修复的任务>"],
"unexpected_fixes": ["<意外修复的任务>"],
"regressions_observed": ["<观察到的回归>"],
"false_predictions": ["<预测错误的任务>"]
},
"verdict": "<keep|revert|partial>"
}
}
从零开始创建一个符合 HARNESS.md 规范的 Agent workspace。
遵循 HARNESS.md v1.0不要基于直觉、猜测或"最佳实践"做修改。每一次修改必须能追溯到具体的失败证据。
每次修改都是一个可被证伪的假设。如果下一轮评估证明预测错误，修改应被回滚。
从最少组件开始演化。不需要一次性配齐 7 个组件——只需要 System Rules + 1-2 个工具。
如果同一个失败模式在 2+ 次迭代中持续出现，且在当前组件层面修复无效 → 回滚，换一个组件层面重新解决。