你写的最后一份 harness：AI Agent 的"自举自动化"已经卷到第二层了
- 关联论文：2604.21003
你做 Agent 项目是不是经常这样——
业务方扔过来一个新场景（ERP 操作、客服升级、研究流水线、跨仓代码评审），你重新搭一遍 harness：写系统提示、定义工具 schema、编排节点顺序、设计评测 rubric、调好提示词模板……两到三周就这么过去了。
然后下一个场景来了，又得重新搭一遍。
arXiv 2604.21003 提出：让"写 harness"这件事本身也被自动化——而且不止自动化一遍，还能跨任务累积经验。作者管这叫"你写的最后一份 harness"。
论文名字叫 The Last Harness You'll Ever Build（直译：你这辈子写的最后一份 harness），论文给出三个最硬的数字：
- Terminal-Bench 2：pass@1 从 69.7% → 77.0%，超过手工设计的 Codex-CLI 基线 71.9%
- SWE-bench-verified：冻结 harness 后迁移到该榜单，进入 top-12%，同时 token 消耗减少 12%
- 跨三个 LLM 家族泛化：冻结同一份 harness，三个家族模型都拿到 +5.1pp ~ +10.1pp 的提升
——一句话：harness 自动化能跑赢人工，且能跨模型复用，还更省 token。
为什么"再调一份 harness"在 Agent 时代注定是个错误的方向
过去两年，做 Agent 的团队都踩过同一个坑：harness 是手工艺术品，不是工程产物。
你换一个领域，就要把整套"脚手架"——系统提示、工具 schema、orchestration 逻辑、评测 rubric——重写一遍。每个团队都靠一两个"prompt 大神"维持产能，人走了整个 Agent 业务就塌。
更糟糕的是，这套"手艺"几乎没有累积性。每个新任务都从零开始，踩过的坑不会自动变成下次的方法。
论文把这个问题拆成两层（这本身就是一个贡献级洞察）：
- L1（单任务）：给定一个具体任务 $T$，自动搜索最优 harness $\mathcal{H}^*$。社区已有工作（DSPy、TextGrad、OPRO、ADAS）摸到过这层。
- L2（跨任务）：给定一组任务的分布 $\mathcal{T}$，让"如何自动搜索 harness"这件事也自动搜索——也就是找到那个"进化蓝图" $\Lambda = (W_{\mathcal{H}}, \mathcal{H}^{(0)}, V, E)$（worker 模板、初始 harness、评估器、进化器）。
L2 是论文真正的核心——"自动化设计的自动化"。这一步以前没人系统化地做。
它到底怎么跑——两层循环一图说清
整篇论文本质上跑两个循环，外层循环优化"如何进化"，内层循环优化"harness 本身"。
第一层（AHE：Automated Harness Engineering）
四个角色轮班：
Worker Agent (W) → 执行任务 T，产出轨迹 τ_t 和答案 a_t
↓
Evaluator (V) → 对抗式诊断失败点 + 打分 s_t
↓
Evolution (E) → 看完整历史 {τ_i, a_i, s_i}，提出新 harness H_{t+1}
↓
Decision Observability → 让 E 自声明"我预计这次能让分数提升多少"，用来校准 E
伪代码直觉：
for t = 0..T_max:
traj_t, ans_t = W_Ht.run(T) # worker 执行
score_t, diag = V.critique(traj_t) # evaluator 打分+归因
history.append((traj_t, score_t, diag))
H_{t+1}, pred_t = E.propose(history) # 进化器提出新 harness
注意三个关键设计：
- E 看的是完整历史而不是单次失败——这是和"反射式 self-refine"的根本差异。
- V 是对抗式的——它的目标是找漏洞、找边缘 case，不是"给高分"。
- Decision Observability——E 自声明预测，下一轮用真实分数校准，过滤掉"自信但无用"的修改方向。
第二层（Meta-Evolution：跨任务自动化）
第一层在单任务上能跑出好 harness，但冷启动成本和收敛步数取决于"进化蓝图 $\Lambda$ 选得好不好"。第二层把 $\Lambda$ 本身当作可学习对象：
for k = 0..K_meta:
# 内层：在多个任务上跑 AHE
trajectories = [AHE(T_i, Λ_k) for T_i ~ T_train]
# 外层：元进化器观察轨迹，修改 Λ 的元参数
Λ_{k+1}, rationale = Meta_E.propose(Λ_k, trajectories)
return Λ_best
论文明确给出与 MAML 的对应表（论文 Section 3）：
| 经典 meta-learning | 论文框架 |
|---|---|
| Task $\mathcal{T}_i$ | 具体 Agent 任务 $T_i$ |
| Inner-loop 参数 $\theta$ | Harness $\mathcal{H}$ |
| Outer-loop 参数 $\phi$ | Blueprint $\Lambda$ |
| 内层梯度 $\nabla_\theta \mathcal{L}_i$ | Evolution Agent $E$ 的修改提议 |
——结构上是 MAML 的"harness 版"。差别在：参数空间是"自然语言 + 结构化配置"而不是浮点权重。
和现有"自动 prompt / 自动 agent"工作差在哪
很多人会问：这和 DSPy / TextGrad / ADAS / Reflexion 不是一回事吗？
完全不是一个层级。对比一下：
| 方案 | 在做什么 | 自动化层级 | 跨任务复用 |
|---|---|---|---|
| 手工写 harness | 完全人工 | ❌ | ❌ |
| DSPy / TextGrad | 自动优化 prompt 模块 | L1（单层） | ⚠️ 模块级 |
| ADAS | 搜索 agent 拓扑结构（节点顺序） | L1 | ⚠️ |
| Reflexion / Self-refine | 反思式重写 | L1（无元层） | ⚠️ |
| AHE（本文 L1） | 自动化完整 harness 进化 | L1（单任务自动） | ⚠️ 需手动选任务 |
| AHE + Meta-Evolution（本文 L2） | harness 设计的自动化 | L2（跨任务自动） | ✅ |
一句话：L1 是"为每个任务自动写 harness"，L2 是"为一批任务自动学会怎么写 harness"。前者工程化收益有限（每个新任务还要从零冷启动），后者是真正意义上的"harness 工厂"。
为什么这件事重要——Agent 创业的护城河正在换边
2026 年做 Agent 创业，最大的争论是：壁垒在模型，还是在 harness？
论文给出的答案很明确——harness 自动化本身就是壁垒，且可以用元学习持续累积。
这件事对企业级 Agent 的实际意义是：
- 新任务接入时间：从"数天专家手工调优"压缩到"数小时自动收敛"；
- 跨模型迁移：同一个 evolved harness 能在 3 个模型家族上都拿到 +5–10pp，意味着 harness 不再绑死特定模型；
- token 经济性：SWE-bench-verified 上token 消耗减少 12%——同样的活少花 12% 的钱，对 Agent 业务这种按调用付费的形态是实打实的毛利改善。
更有意思的是 Decision Observability 这个设计。E 自声明"我预计这次修改能让分数提升多少"，下一轮用真实结果校准——这是一个低成本但极其实用的 trick。它本质上解决了"LLM 自信但无用"的问题：让 LLM 自己负责预测，然后让预测准确率变成可被追踪的指标。这个思想可以无缝搬到任何 LLM-as-optimizer 场景（自动 prompt、自动 RAG、自动评测器），不局限于 harness。
几个不被注意的工程坑
论文自己没明说、但真正上手就要面对的几件事：
- Evaluator（V）的可靠性是系统上限。如果 V 对 harness 质量判断错误（打了高分但实际没用），整个进化向错误方向收敛。V 的 prompt 必须精心设计——推荐 "You are an adversarial evaluator..." 的对抗式措辞，不能让它变成"和善的打分员"。
- Meta-Evolution 的成本极高。每轮 meta-loop 需要在多个任务上跑完整 AHE，外层一次迭代是内层的 N×M 次 LLM 调用（SWE-bench-verified 规模下可能数千美元/次）。预算没算清楚前不要上 L2。
- Harness 空间没有形式化度量。神经网络的 loss landscape 有梯度可循，harness 空间是"自然语言 + 配置"的混合体——meta-evolution 的收敛性没有理论保证，容易陷入局部最优或反复横跳。
- 任务分布漂移会失效。$\Lambda^{(\text{best})}$ 在 $\mathcal{T}_{\text{train}}$ 上学到的"元经验"，若部署任务分布漂移大（从代码任务迁移到客服对话），就会失效——L2 需要定期 re-run。
- Prompt injection 风险。E 自动修改 harness，若被恶意输入污染，可能产生有害 harness。企业部署必须加 harness 审计层。
- 10 轮迭代上限的合理性。论文报告 10 轮达到 77%，但未说明 10 轮后是否继续上升或震荡——实际系统应设计 early-stopping（基于
pred_t可信度或连续多轮无提升）。 - Decision Observability 的工程实现。E 每次 propose 时输出
pred_t（预测分数变化），下一轮用真实score_{t+1} - score_t校准——这个追踪机制比看起来复杂，需要把预测和真实结果做严格配对的存储 schema。
谁该读这篇
- Agent 平台架构师：把 L1 AHE 闭环（Worker + Evaluator + Evolution 三角色）作为 Agent infra 的标配，论文给出了完整伪代码。
- ML 工程师 / Researcher：理解"自动 prompt / 自动 agent 设计"这条线索的全貌，本工作是当前的 milestone。
- Prompt / Harness 工程师：担心被自动化取代——本文给出了演进路线，反而能帮你转型为"元层 prompt 设计师"（设计 V 和 E 的元模板）。
- Tech Lead / 工程总监：评估"是否投资 Agent infra"时，本文的实证数据（+7.3pp / 跨家族 +5–10pp / token -12%）是难得的硬指标。
- 产品经理 / 创业者：在思考"Agent 创业壁垒在模型还是在 harness"的人——本文的答案是 harness 自动化本身就是壁垒。
- AI 工具链作者：把 Decision Observability 这个设计搬到任何 LLM-as-optimizer 场景（自动 prompt / 自动评测器 / 自动 RAG 配置），是低成本但效果极好的 trick。
一句话总结
AI Agent 的 harness 正在从"手工艺"变成"可元学习累积的算法资产"。The Last Harness 把两层循环（AHE + Meta-Evolution）打通，在 Terminal-Bench 2 和 SWE-bench-verified 上跑出了真可比的硬数字（pass@1 +7.3pp、top-12%、token -12%、跨家族 +5–10pp），并用 Decision Observability 让"LLM 自负责预测 + 真实校准"成为可追踪的工程模式——未来 3-5 年的 Agent infra 都会沿这个方向走。
三个标题变体
- 你写的最后一份 harness：AI Agent 的"自举自动化"已经卷到第二层了
- harness 也能"自动化本身"——arXiv 这篇让 Agent 跨任务累积经验，新任务接入从数天压到数小时
- Agent 创业的护城河换边了：模型算力不是壁垒，"harness 工厂"才是——这篇论文给出了可落地的元学习方案
小红书风格卡片文案（可直接发布）
🤖 AI Agent 项目最大的隐性成本是每次换场景都要重写 harness——系统提示、工具 schema、orchestration、评测 rubric，两到三周就这么过去了 ⏳
下一个场景来了？又得重新搭一遍 😩
arXiv 2604.21003 提出 The Last Harness You'll Ever Build，核心一句话：
让"写 harness"这件事本身也被自动化——而且不止自动化一遍，还能跨任务累积经验 🧠
📌 论文把问题拆成两层（这本身就是贡献级洞察）： - L1（AHE）：给定具体任务，自动搜索最优 harness - L2（Meta-Evolution）：让"如何自动搜索 harness"这件事也自动搜索——也就是找到那个"进化蓝图" Λ
L2 是真正的核心——"自动化设计的自动化"，这一步以前没人系统化地做 💡
📌 L1 的四个角色轮班： 1. Worker Agent（W）：执行任务，产出轨迹 2. Evaluator（V）：对抗式诊断失败点 + 打分（不是"和善打分员" ⚔️） 3. Evolution（E）：看完整历史，提出新 harness 4. Decision Observability：让 E 自声明预测，下一轮用真实分数校准，过滤"自信但无用"的修改 ✅
📌 L2 的 meta-loop： - 在多个任务上跑 AHE → 收集完整轨迹 - 元进化器观察轨迹，修改 Λ 的元参数 - 输出 Λ^(best)：可跨任务复用
🔥 三个最硬数字： - Terminal-Bench 2：pass@1 69.7% → 77.0%，超 Codex-CLI 基线 71.9% - SWE-bench-verified：top-12% + token 消耗减少 12% - 跨 3 个 LLM 家族泛化：冻结同一 harness，都拿 +5.1pp ~ +10.1pp
📌 和现有方案的根本差异： | 方案 | 自动化层级 | 跨任务复用 | |---|---|---| | 手工 harness | ❌ | ❌ | | DSPy / TextGrad | L1 | ⚠️ 模块级 | | ADAS | L1（拓扑） | ⚠️ | | AHE（本文 L1） | L1（完整 harness） | ⚠️ | | AHE + Meta-Evolution（本文 L2） | L2（跨任务自动） | ✅ |
⚠️ 工程坑（论文自陈 + 落地经验）： 1. Evaluator 的可靠性是系统上限——V 的 prompt 必须对抗式措辞，不能让它变"和善打分员" 2. Meta-Evolution 成本极高——外层一次迭代 = 内层 N×M 次 LLM 调用（SWE-bench-verified 规模数千美元/次） 3. Harness 空间没形式化度量——收敛无理论保证，容易局部最优 4. 任务分布漂移会失效——L2 需要定期 re-run 5. Prompt injection 风险——E 自动改 harness，企业部署必须加审计层 6. 10 轮是报告上限不是最优停止点——实际系统要做 early-stopping 7. Decision Observability 的存储 schema 比看起来复杂——预测和真实结果要严格配对
💡 为什么这件事重要： - Agent 创业护城河换边：harness 自动化本身就是壁垒，且可元学习累积 🏰 - 新任务接入时间从数天专家手工压到数小时自动收敛 - Decision Observability 这个 trick 可以无缝搬到任何 LLM-as-optimizer 场景（自动 prompt / 自动评测器 / 自动 RAG）——不局限于 harness - 未来 3-5 年的 Agent infra 都会沿这个方向走
📌 论文与 MAML 的对应（结构类比，非数学等价）： - 内层梯度 ↔ Evolution Agent E 的修改提议 - 外层参数 φ ↔ Blueprint Λ - Task $\mathcal{T}_i$ ↔ 具体 Agent 任务 $T_i$
📎 论文 ID：2604.21003 💬 评论区：你团队的 Agent harness 是手工维护的吗？如果"自动化设计"也能自动化，你想先用在哪个任务上？