Self-Harness 自我演进框架 — Agent 外骨骼的自我进化¶
2026 年 Agent 工程领域的"深水炸弹"：不微调模型参数，不让强模型当导师，让 Agent 自己读日志、自己改代码、自己进化。Terminal-Bench 2.0 上三个模型 held-out 通过率提升 33-60%。
目录¶
- #一、背景：人工外骨骼（Harness）的极限
- #二、Self-Harness 核心机制：自我演进的三阶段闭环
- #三、实验数据：0 参数微调下的智商暴涨
- #四、Case Study：不同模型的隐性病灶与专属药方
- #五、落地雷区与工程挑战
- #六、实践启示：从 Prompt Tweaker 到 Feedback Architect
- #参考资料
一、背景：人工外骨骼（Harness）的极限¶
什么是 Harness¶
Agent 的性能不单独由基座模型决定，而是由模型（Base Model）+ 外骨骼（Harness）共同塑造。Harness 是模型与环境交互的外围系统，包括：
- 系统提示词（System Prompt）
- 工具定义和包装器（Tool Wrappers）
- 记忆和上下文管理（Memory / Context Management）
- 验证规则（Verification Rules）
- 运行时策略（Runtime Policies）
- 编排逻辑（Orchestration Logic）
- 失败恢复流程（Failure Recovery）
论文原文：The performance of LLM-based agents is jointly shaped by their base models and the harnesses that mediate their interaction with the environment.
三种 Harness 工程模式对比¶
| 维度 | Human Harness（人工） | Meta-Harness（强模型导师） | Self-Harness（自我演进） |
|---|---|---|---|
| 谁来改 Harness | 人类工程师 | 强模型（GPT-5.5 等） | Agent 自己 |
| 成本 | 高（专家时间） | 高（API 调用） | 中（算力开销） |
| 可扩展性 | 差（模型迭代快） | 差（强模型贵/不可得） | 好（随算力扩展） |
| 模型特异性 | 需手动分析 | 强模型有"知识诅咒" | 自动发现 |
| 核心瓶颈 | 依赖直觉，非系统化 | 难以共情弱模型盲点 | 依赖确定性验证器 |
为什么人工模式走不通¶
新模型发布 ──> 人类工程师分析 ──> 设计专属 Harness
^ │
│ ▼
└── 手动测试迭代 ←── 部署
另一模型发布 ──────> 重复上述流程
问题：模型迭代速度 >> 人工适配速度
论文一作 Hangfan Zhang 在 VentureBeat 访谈中说：
"当前 harness-engineering 范式的深层问题是缺乏系统化的反馈闭环。很多修改基于直觉、几次观察到的失败、或临时调试。"
"在许多情况下，经验丰富的领域专家仍然能提出比 LLM 更好的修改。但瓶颈不在于人的能力，而在于依赖 ad hoc 调试而非可验证的经验反馈闭环。"
二、Self-Harness 核心机制：自我演进的三阶段闭环¶
整体架构¶
┌─────────────────────────────────────────────────┐
│ Self-Harness Loop │
│ │
│ [执行轨迹] │
│ │ │
│ ▼ │
│ 1. 弱点挖掘 (Weakness Mining) │
│ 三元组失败签名聚类 │
│ │ │
│ ▼ │
│ 2. 框架提案 (Harness Proposal) │
│ 平行分支 × 最小化修改 │
│ │ │
│ ▼ │
│ 3. 提案验证 (Proposal Validation) │
│ Held-in + Held-out 双分割门控 │
│ │ │
│ ├──── 通过 ──> 合并到下一版本 │
│ └──── 拒绝 ──> 回到提案阶段 │
│ │
└─────────────────────────────────────────────────┘
阶段一：弱点挖掘（Weakness Mining）¶
目标：从庞杂的报错日志中提取可复现的底层工程缺陷，而非偶发幻觉。
核心方法 — 三元组失败签名（Triplet Failure Signature）：
失败签名 = (
验证器层面的死因, # Verifier-level cause of death
Agent 导致死因的行为, # Agent behavior causing it
抽象出的机制故障 # Abstracted mechanism failure
)
只有三个维度完全咬合一致时才进行聚类，确保找到的是系统性工程缺陷而非随机噪声。
失败分类维度：
| 类型 | 说明 | 典型表现 |
|---|---|---|
| 工具选择错误（Tool Selection） | 用了错误的工具 | 任务需要 git commit 但跳过了配置 |
| 上下文错误（Context Errors） | 丢失或误读信息 | 多步任务中忘记中间变量 |
| 规划错误（Planning Errors） | 任务分解不当 | 探索过度，不产出交付物 |
| 错误处理缺失（Error Handling） | 不会从失败恢复 | 同一命令盲目重试 |
| 验证缺口（Verification Gaps） | 不验证假设 | 假设文件创建成功但不检查 |
阶段二：框架提案（Harness Proposal）¶
两大设计约束：
┌─────────────────────────────────────────────┐
│ 多样性 (Diversity) │
│ 平行拉出多个 Feature Branch： │
│ • Prompt 指令层修改 │
│ • 控制策略中间件 (Middleware) │
│ • 子 Agent 创建 │
│ • 工具包装器修改 │
│ • 验证步骤注入 │
│ 每个弱点生成 3-5 个候选方案 │
├─────────────────────────────────────────────┤
│ 最小化 (Minimality) │
│ • 只修改解决该 Issue 的最小代码面 │
│ • 不进行大重构 │
│ • 变异原子化、可解释 │
│ • 超过阈值行数的修改直接拒绝 │
└─────────────────────────────────────────────┘
提案类型示例（以 git 配置缺失为例）：
# 提案类型 1: System Prompt 修改
+ Before running git commit, always verify git user.name
+ and user.email are configured. If not set:
+ git config user.name "Agent"
+ git config user.email "agent@localhost"
# 提案类型 2: Tool Wrapper
def execute_git_command(cmd):
if "commit" in cmd:
check_git_config() # 自定义提案
return subprocess.run(cmd, shell=True)
# 提案类型 3: 验证步骤注入
def create_file(path, content):
write_file(path, content)
if not os.path.exists(path): # 新增验证
raise FileNotFoundError(f"Failed: {path}")
阶段三：提案验证（Proposal Validation）— 最严格的门控¶
双分割门控机制（Dual-Split Gating）：
提案修改
│
┌───────────┴───────────┐
▼ ▼
Held-in 验证集 Held-out 盲测集
(训练集 70%) (完全隔离 30%)
│ │
ΔTrain ≥ 0 ΔHeldout ≥ 0
(不下降) (不下降)
│ │
└───────────┬───────────┘
▼
非零收益条件:
ΔTrain + ΔHeldout > 0
(拒绝无效重构)
│
▼
✅ 接受合并 / ❌ 拒绝
三个门控条件缺一不可：
| 条件 | 公式 | 含义 |
|---|---|---|
| Held-in 不退步 | ΔTrain ≥ 0 | 训练集通过率不下降 |
| Held-out 不退步 | ΔHeldout ≥ 0 | 盲测集通过率不下降 |
| 必须有净收益 | ΔTrain + ΔHeldout > 0 | 拒绝无意义的无效重构 |
这个设计极其关键：防止 Agent 在演进过程中产生"廉价的过拟合"——通过训练集但盲测集退步。
验证伪代码：
def validate_proposal(current, proposed, val_tasks):
baseline = run_benchmark(current, val_tasks)
proposal = run_benchmark(proposed, val_tasks)
regressions = [t for t in val_tasks
if baseline[t].passed and not proposal[t].passed]
if len(regressions) > 0:
return REJECT, "Introduced regressions"
if proposal.pass_rate <= baseline.pass_rate:
return REJECT, "No net improvement"
return ACCEPT, f"Improved {len(improvements)} tasks"
三、实验数据：0 参数微调下的智商暴涨¶
实验设置¶
Benchmark: Terminal-Bench 2.0 (容器化 Linux 终端任务)
评测标准: Pass@1 (全或无)
初始 Harness: 最小化 (DeepAgent SDK, 仅基础 system prompt + 文件系统/shell 工具)
变量控制: 模型后端、工具集、环境、验证器全部不变，只让 Harness 变化
模型选择: 三个不同家族，不同架构，不同基线水平
Held-out 通过率（论文权威数据）¶
| 基座模型 | 演进前 | 演进后 | 绝对提升 | 相对提升 |
|---|---|---|---|---|
| MiniMax M2.5 | 40.5% | 61.9% | +21.4pp | +52.8% |
| Qwen3.5-35B-A3B | 23.8% | 38.1% | +14.3pp | +60.1% |
| GLM-5 | 42.9% | 57.1% | +14.2pp | +33.1% |
Held-in 通过率（视频披露的额外数据）¶
| 基座模型 | 演进前 | 演进后 | 相对提升 |
|---|---|---|---|
| Qwen3.5-35B-A3B | 15.1% | 36.0% | +138% |
| MiniMax M2.5 | 43.0% | 50.0% | +16% |
| GLM-5 | 47.4% | 57.0% | +20% |
核心意义：无需耗费巨额定进行 Post-training 或权重微调，仅靠外围代码的自我盘顺，即可省去过半显存和 Token 成本。
MiniMax M2.5 迭代收敛曲线¶
Iteration 0 (Baseline): 40.5% ████████████████████░░░░░░░░░░░░░
Iteration 1: 45.2% ██████████████████████░░░░░░░░░░░ (+4.7%)
Iteration 2: 51.8% ██████████████████████████░░░░░░░ (+6.6%)
Iteration 3: 56.3% ████████████████████████████░░░░░ (+4.5%)
Iteration 4: 59.1% █████████████████████████████░░░░ (+2.8%)
Iteration 5: 61.2% ██████████████████████████████░░░ (+2.1%)
Iteration 6: 61.9% ███████████████████████████████░░ (+0.7%)
Iteration 7: 61.9% ███████████████████████████████░░ [收敛]
观察：前 3-4 轮迭代贡献大部分收益，第 5 轮后边际递减，无过拟合迹象
关键发现¶
- ✅ 三个模型一致提升（14-21 个绝对百分点）
- ✅ 改进不限于高性能模型（最弱的 Qwen 23.8% 也有 60% 相对提升）
- ✅ 不同模型生成不同的 Harness 修改（非通用指令）
- ✅ 改进跨迭代累积，5-7 轮后趋于收敛
四、Case Study：不同模型的隐性病灶与专属药方¶
Self-Harness 展现出针对不同模型特性进行"精准施药"的能力——每个模型的 Harness 修改完全不同。
三模型病灶与药方总览¶
┌──────────────────────────────────────────────────────────────┐
│ Self-Harness 诊断台 │
├──────────────┬──────────────────┬────────────────────────────┤
│ 模型 │ 隐性病灶 │ 专属药方 │
├──────────────┼──────────────────┼────────────────────────────┤
│ Qwen 3.5 │ 无效死循环 │ 异常拦截中间件 │
│ │ (盲目重试) │ + 严格命令重试纪律 │
├──────────────┼──────────────────┼────────────────────────────┤
│ MiniMax M2.5 │ 过度探索发散 │ Loop Breaker (50次截断) │
│ │ (不产出交付物) │ + 强制早期交付机制 │
├──────────────┼──────────────────┼────────────────────────────┤
│ GLM-5 │ 状态记忆丢失 │ 持久化环境变量 │
│ │ (跨命令丢上下文) │ + Sanity Check 修复门控 │
└──────────────┴──────────────────┴────────────────────────────┘
病灶 1：Qwen3.5-35B-A3B — 无效死循环¶
症状：遇到文件覆盖错误后，盲目重复执行同一命令，最终在混乱中删除必要文件然后停止。
Agent 行为轨迹：
工具调用: write_file(config.json) → ERROR (文件已存在)
工具调用: write_file(config.json) → ERROR (文件已存在) ← 盲目重试
工具调用: write_file(config.json) → ERROR (文件已存在)
工具调用: rm config.json → 删除文件
工具调用: write_file(config.json) → ERROR (路径不存在)
停止 → 任务失败
药方（两味）：
- 严格命令重试纪律：禁止完全重复的命令，遇到错误必须改变策略
- 缺失 Artifact 立即重建：文件错误发生时，强制立即重建而非删除
# 提案生成的 Harness 中间件
def execute_command(cmd, history):
# 严格重试纪律
if cmd in history[-3:]:
inject_warning("命令重复执行，请改变策略")
return BLOCK
try:
result = run(cmd)
except FileError as e:
# 立即重建而非删除
inject_warning(f"文件操作失败: {e}。请补齐缺失文件，"
f"不要删除后重试。")
return INTERCEPT
return result
病灶 2：MiniMax M2.5 — 过度探索发散¶
症状：无止境地探索数据集配置，直到执行环境超时，始终不产出任何交付物。
药方（两味）：
- Loop Breaker（循环截断器）：50 次工具调用后强制停止并转向
- 强制早期交付：要求以最快速度建立草稿文件，切断探索域
演进前： 演进后：
探索 → 探索 → 探索 → ... → 超时 探索 → 探索 → [50次截断]
无交付物 │
▼
强制创建草稿文件
│
▼
迭代优化草稿 → 交付
VentureBeat 访谈补充：MiniMax M2.5 还加入了"尽可能早地创建所需 artifact 的初始版本"的规则。
病灶 3：GLM-5 — 环境状态记忆丢失¶
症状：跨命令保留不住环境变更（如 PATH 变量），浪费大量时间在大体积下载上，甚至 sanity check 失败时仍然提交任务。
药方（三味）：
- 持久化环境变量：跨 shell session 保留 PATH 等变量
- 限制外部计算：避免大体积无谓下载
- Sanity Check 修复门控：检查失败时必须修复后才能结束
# GLM-5 的 Harness 提案示例
# 1. 环境变量持久化（跨命令保留）
export PATH="$PATH:/custom/bin"
echo "export PATH=$PATH" >> ~/.env_persistent
# 2. 外部计算限制
MAX_DOWNLOAD_SIZE=100MB # 超限拦截
# 3. Sanity Check 门控
if ! verify_artifact_exists "$DELIVERABLE"; then
log "强制状态切换: 实施验证模式"
repair_artifact "$DELIVERABLE"
fi
Case Study 核心洞察¶
Self-Harness 不是加通用指令，而是：
模型特定行为缺陷 ──> 精准的工程修复
(不是知识缺口) (不是 Prompt 优化)
│ │
▼ ▼
Qwen: 死循环 → 异常拦截 + 重试纪律
M2.5: 过度探索 → 截断 + 强制交付
GLM-5: 状态丢失 → 持久化 + 修复门控
论文原文：Self-Harness does not simply add generic
instructions, but effectively turns model-specific
weaknesses into concrete, executable harness changes.
五、落地雷区与工程挑战¶
三大致命陷阱¶
┌──────────────────────────────────────────────────┐
│ 雷区 1: 确定性验证器依赖 │
│ ────────────────────────────── │
│ 有 0/1 明确结果: ✅ (代码、DevOps、CI) │
│ 开放性任务: ❌ (写周报、客服、创意) │
│ 缺乏客观 Verifier → 双盲测试崩溃 │
├──────────────────────────────────────────────────┤
│ 雷区 2: 修改边界受限 │
│ ────────────────────────────── │
│ 能改: Prompt 配置、中间件控制流 │
│ 不能改: 底层架构重构 │
│ 无法自发重构 MCTS 等全新架构 │
├──────────────────────────────────────────────────┤
│ 雷区 3: 成本与延迟风险 │
│ ────────────────────────────── │
│ 提案只优化通过率，不优化算力 │
│ 可能导致 API 调用次数 + 延迟暴增 │
│ 需要独立的算力/成本帐本约束 │
└──────────────────────────────────────────────────┘
适用 vs 不适用场景决策树¶
你的场景是否适合 Self-Harness？
├─ 有确定性验证器 (0/1 结果)？
│ ├─ YES → 继续
│ │ └─ 频繁更换基座模型？
│ │ ├─ YES → ✅ 强烈推荐 (自动适配省人工)
│ │ └─ NO → ⚠️ 可选 (人工也行)
│ │
│ └─ NO (开放性任务)
│ └─ ❌ 不推荐 (验证器不可靠会导致错误升级)
│
├─ 安全关键领域？(医疗/法律/基础设施)
│ └─ ❌ 不推荐全自动，保留 human-in-the-loop
│
└─ 算力预算有限？
└─ ⚠️ 注意成本 (89 tasks × 2 runs × 5 轮 ≈ 890 次 agent 调用)
计算开销估算¶
| 维度 | 估算 |
|---|---|
| 每轮迭代 | 全量 benchmark × 2（baseline + proposal） |
| 总量 (89 tasks) | 89 × 2 × 5-7 轮 ≈ 890-1246 次 agent 调用 |
| 成本 (昂贵模型) | $50-100+ 每次完整优化 |
Zhang 在访谈中明确：Self-Harness 用"重复提案生成、平行候选评估、回归测试"替代了部分人工工程负担，但这意味着更多 API token、更多优化期间延迟、更多评估基础设施。
六、实践启示：从 Prompt Tweaker 到 Feedback Architect¶
核心哲学转变¶
Agent 的能力上限不单取决于基座模型参数，更取决于其与环境交互的工程 Harness。模型的"智商缺陷"本质上是推理逻辑与僵化操作框架之间的工程摩擦。
传统思维: 新范式:
模型不行 → 换更强模型 模型不行 → 先查 Harness
Prompt 不灵 → 手动调词 Prompt 不灵 → 让 Agent 自己看日志
换模型后 Harness 失效 → 重写 换模型后 Harness 失效 → 自动重新演进
三条行动建议¶
┌────────────────────────────────────────────────────┐
│ 建议 1: 将 Harness 视为动态行为接口 │
│ 打破 Harness = 静态 JSON / 死板 if-else 的思维 │
│ 预留可成长的扩展性 │
├────────────────────────────────────────────────────┤
│ 建议 2: 优化单位聚焦「抽象失效机制」 │
│ 日志结构化归档 │
│ 针对可复现的失败签名做模块化防御修复 │
│ 而非针对单一 Task 湊答案 │
├────────────────────────────────────────────────────┤
│ 建议 3: 建立严酷的隔离测试牆 │
│ Held-in + Held-out 双盲回归测试体系 │
│ 防止演进中产生廉价过拟合 │
└────────────────────────────────────────────────────┘
工程师角色演进¶
| 阶段 | 角色 | 核心技能 |
|---|---|---|
| 过去 | Prompt Tweaker | 手动调 system prompt |
| 现在 | Harness Engineer | 设计工具、中间件、验证器 |
| 未来 | Feedback Architect | 设计让 Agent 自我改进的反馈系统 |
Zhang 预言：工程师角色将从"手动修补个别 prompt 或工具调用"转向"设计让 Agent 改进成为可能的反馈系统"。
与其他自改进方案对比¶
| 方案 | 目标层 | 外部依赖 | 代表方法 |
|---|---|---|---|
| Self-Harness | 系统级 Harness | 无（纯自驱） | 本文 |
| Meta-Harness | 系统级 Harness | 强模型 | GPT-5.5 教 GPT-4 |
| SkillOpt (Microsoft) | 任务级 Skill | 执行反馈 | 技能代码优化 |
| Retrospective Harness | 轨迹级 | 偏好模型 | Self-Preference over Trajectory |
| APEX | 原则层 | 三层架构 | Adaptive Principle Extraction |
Self-Harness 和 SkillOpt 互补：SkillOpt 优化单个技能，Self-Harness 优化整体框架。
参考资料¶
- Self-Harness: Harnesses That Improve Themselves (arXiv:2606.09498) — Hangfan Zhang et al., 上海人工智能实验室, 2026-06-08
- VentureBeat: Researchers introduce Self-Harness — 含一作 Zhang 深度访谈
- explainx.ai: Self-Harness 技术深度分析 — 含伪代码和提案示例
- 原视频：0参数微调让Agent智商暴涨138% — wow 频道
- APEX: Adaptive Principle Extraction (arXiv:2606.15363) — 引用 Self-Harness 的后续工作
- Agent Harness Survey (HuggingFace) — Harness 工程综述
相关笔记¶
- [[Agent Harness Engineering]]
- [[Terminal-Bench 2.0]]
- [[AI Agent 自改进范式]]