Harness Agent 前沿论文调研报告

执行摘要

什么是 Harness？

在 AI Agent 领域，Harness（执行框架/脚手架） 指的是包裹 LLM 模型的外层控制系统，负责：

• 工具调用管理（Tools）
• 多步骤推理编排（Orchestration）
• 记忆与状态管理（Memory & State）
• 安全边界与权限控制（Safety）
• 上下文压缩与跨会话持久化（Context Engineering）

过去，人们关注的是 LLM 本身的能力；近期研究证明，Harness 设计的优劣对 Agent 系统性能的影响可达 6-10 个百分点，已成为 AI 工程化的核心竞争力。

本报告核心发现：

趋势结论：Harness 正在从"隐式代码"向"显式可优化工程对象"演进，LLM 已能自动合成和优化 Harness，AI 研究范式正在发生根本性转变。

一、Natural-Language Agent Harnesses（NLAH）

❝

论文信息：arXiv:2603.25723 | 清华大学 & 哈尔滨工业大学（深圳）| 2026年3月

1.1 工作动机

核心问题：现代 Agent 的成败越来越取决于 Harness 设计，但 Harness 逻辑长期"埋藏"在控制代码深处。

具体困境：

• Harness 的高层控制逻辑散落在框架默认配置、运行时假设、controller 代码中
• 两个"只差一个设计决策"的系统，往往同时在 Prompt 设计、工具调用方式、验证门控、状态语义等多个维度都有差异
• 这使得 Harness 的科学对比几乎不可能——评估结果是"黑箱捆绑比较"，而非干净的模块级证据

研究问题：Harness 的高层控制逻辑，能否被外部化为一个可移植、可执行、可研究的工件？

1.2 做了什么

提出两个核心贡献：

① NLAH（Natural-Language Agent Harness）——自然语言 Agent 执行框架

将 Harness 的行为以可编辑自然语言表达，包含六个显式模块：

② IHR（Intelligent Harness Runtime）——智能执行运行时

将 LLM 置于运行时循环内部来解释 NLAH：

• 每步读取 Harness 文档、当前状态/环境、运行时宪章（Runtime Charter）
• 选择符合契约和预算约束的下一个动作
• 三个核心组件：（1）循环内 LLM 解释器 （2）带终端工具和多 Agent 接口的后端 （3）定义契约、状态、编排和子生命周期语义的运行时宪章

文件支撑状态（File-backed State）：显式规定状态必须外化为可寻址的产出物（不得仅保存在易失性上下文中），并保证压缩稳定性。

1.3 工作原理

┌──────────────────────────────────────────────────────────────────┐│                    NLAH + IHR 工作原理                           │└──────────────────────────────────────────────────────────────────┘自然语言 Harness（NLAH）─────────────────────────────────────────────────────────  契约层     → 约定输入输出 + 验证规则 + 停止条件  角色层     → Solver / Verifier / Researcher / Orchestrator  阶段层     → 规划 → 执行 → 验证 → 修复  状态层     → 文件支撑状态（持久化，防压缩丢失）  失败分类   → 预定义错误类型，指导错误处理─────────────────────────────────────────────────────────            ↓ IHR 解释执行 ↓┌─────────────────────────────────────────────────────────┐│   IHR：Intelligent Harness Runtime                      ││                                                         ││   每个步骤：                                            ││   读 NLAH + 当前状态 + 运行时宪章                       ││                    ↓                                    ││         LLM 解释器（循环内）                            ││                    ↓                                    ││     选择符合契约约束的下一步行动                        ││                    ↓                                    ││  工具执行（终端工具 + 多 Agent 接口）                   ││                    ↓                                    ││         状态更新（文件持久化）                          │└─────────────────────────────────────────────────────────┘              │                    │        子 Agent 委派         父 Agent 监控

关键机制：~90% 的 Token 消耗、工具调用、LLM 调用发生在委派的子 Agent 中，而不是运行时父 Agent。父 Agent 的主要职责是编排与监控，而非直接执行。

1.4 达到的效果

实验设置：SWE-bench Verified（125个样本）+ OSWorld（36个样本），模型 GPT-5.4 xhigh reasoning

模块消融实验（逐个添加到 Basic Baseline）：

代码→文本迁移（RQ3）：

• 将 OS-Symphony 从原生代码迁移至 NLAH
• **NLAH 版本达到 47.2%**，原生代码仅 30.4%（提升 16.8 个百分点）
• 关键原因：原生代码陷入脆弱的 GUI 修复循环；NLAH 版本将可靠性机制迁移至持久化文件状态和产出物驱动的闭包

1.5 关键 Insights

1. **"更多结构不总是更好"**：模块仅在能收紧中间行为→评估器接受条件路径时才有效；验证器反而可能有损性能
2. 文件作为记忆：File-backed State 是保证跨步骤、跨上下文窗口连续性的核心机制
3. Harness 可移植性的价值：NLAH 迁移打破了平台锁定，使设计决策可以跨系统比较和迁移
4. 委派效率：90% 以上的计算应由子 Agent 承担，父 Agent 聚焦编排
5. 科学性的前提：只有将 Harness 外部化，才能实现干净的模块级消融实验

1.6 其他补充

• 可迁移性验证：成功将一个原本为特定平台（代码执行）设计的 Harness 模块，迁移至不同平台（计算机操作）
• 对 Agent 基础设施建设的启示：NLAH 本质上就是一种"Agent 宪法"，通过 Markdown 形式定义 Agent 的行为规则，与 Claude Code 的 CLAUDE.md 和 Skills 架构高度一致
• 开放问题：如何设计 Harness 的版本管理和 A/B 测试机制？

二、Meta-Harness：端到端 Harness 优化

❝

论文信息：arXiv:2603.28052 | Stanford IRIS Lab | 2026年3月代码开源：https://github.com/stanford-iris-lab/meta-harness-tbench2-artifact

2.1 工作动机

核心问题：Harness 设计决定了 LLM 系统的性能上限，但 Harness 仍由人工设计。

具体困境：

• 固定 LLM，仅改变 Harness，可产生 6 个百分点的性能差距
• Harness 作用于长视野：单个存储/检索决策可能影响后续许多推理步骤后的行为
• 现有文本优化器（OPRO、TextGrad、ProTeGi、GEPA）压缩反馈过于激进：
• 无记忆（memoryless）
• 仅依赖标量分数
• 限于短模板
• 每个优化步骤可用上下文：100～30,000 Token
• 但 Harness 的单次评估可产生高达 10,000,000 Token 的诊断信息！

核心洞察：Harness 优化需要的信息密度远超现有方法的处理能力。

2.2 做了什么

提出 Meta-Harness：一个通过外循环搜索来优化 Harness 代码的系统。

核心设计：使用一个具有完整文件系统访问权限的编码 Agent 作为"提案者"（Proposer），其可以访问每一个历史候选 Harness 的：

• 源代码
• 评估分数
• 完整执行轨迹（Prompt、工具调用、模型输出、状态更新的全量日志）

┌────────────────────────────────────────────────────────────────┐│                Meta-Harness 外循环搜索流程                     │└────────────────────────────────────────────────────────────────┘                        ┌──────────────────────┐                        │   目标任务 + 评估器   │                        └──────────┬───────────┘                                   │                    ┌──────────────▼──────────────────┐                    │        历史文件系统              │                    │  候选1 代码 + 轨迹 + 分数       │                    │  候选2 代码 + 轨迹 + 分数       │                    │  候选N 代码 + 轨迹 + 分数       │                    └──────────────┬──────────────────┘                                   │                    ┌──────────────▼──────────────────┐                    │      编码 Agent（提案者）        │                    │  Claude Code Opus-4.6           │                    │  中位数：每次迭代读 82 个文件    │                    │  每步参考 20+ 个历史候选         │                    └──────────────┬──────────────────┘                                   │                    ┌──────────────▼──────────────────┐                    │       新 Harness 候选            │                    │  → 评估 → 更新 Pareto 前沿       │                    │  → 写入历史文件系统               │                    └──────────────┬──────────────────┘                                   │                              约 60 次迭代

关键设计原则：

• 提案者是一个能检索信息、导航历史产出物、编辑代码的 Agent，而非仅仅是"固定 Prompt 上的裸 LLM"
• 不施加父代选择规则；提案者可以自由检查任意历史 Harness
• 维护 Pareto 前沿（准确性 vs. 上下文成本）

2.3 工作原理

三个任务的系统实现：

任务一：在线文本分类

• 每个样本独立 → Harness 控制检索的内容与格式
• LLM：GPT-OSS-120B；数据集：LawBench（215类）、Symptom2Disease（22类）、USPTO-50k（180类）

任务二：IMO 级数学推理（RAG）

• 检索语料库 50 万道题；查询集 250 道奥林匹克竞赛题
• Harness 控制检索策略、重排序、如何将检索结果呈现给 LLM
• 在 5 个不同 LLM 上测试泛化（跨模型 OOD）

任务三：TerminalBench-2（Agentic Coding）

• 89 个长视野自主任务
• Harness 控制工具使用策略、状态管理、任务编排

2.4 达到的效果

任务一：在线文本分类

消融实验（执行轨迹的重要性）：

结论：完整执行轨迹的访问（而非摘要）是关键使能因素。

OOD 泛化测试：

任务二：IMO 数学推理

任务三：TerminalBench-2

• Meta-Harness 发现的 Harness 超越 Terminus-KIRA，在所有 Haiku 4.5 Agent 中排名第一

2.5 关键 Insights

1. 执行轨迹 >> 分数摘要：完整的执行轨迹信息价值远超压缩后的标量/摘要；这是 Meta-Harness 相比所有先前优化器的本质差异
2. **编码模型天然偏向"结构化复用"**：相比裸 LLM，编码 Agent 会产生可重用的上下文管理过程，而非脆弱的硬编码方案
3. Harness 优化是一个信息检索问题：每步参考 20+ 个历史候选、读 82 个文件，提案者本质上是在历史中"挖矿"
4. 系统能力随编码 Agent 进化而自动提升：Meta-Harness 的上限由提案者的代码能力决定，而不是由人工设计的模板限制
5. 成本效益的同步改善：Meta-Harness 在精度提升的同时，反而降低了上下文消耗（11.4K vs. 50.8K tokens），打破了"效果-成本"的天然权衡

2.6 其他补充

• 研究意义：Meta-Harness 将 AutoML 的理念延伸至 Agent Harness 领域，实现了"元学习到元工程"的跨越
• Pareto 前沿：系统天然维护精度-成本的 Pareto 前沿，为实际部署提供可选方案
• 限制：每轮评估成本仍然较高（约 60 个候选需要完整评估）；目前主要验证在三类任务上

三、AutoHarness：LLM 自动合成 Harness

❝

论文信息：arXiv:2603.03329 | Google DeepMind | 2026年2-3月

3.1 工作动机

核心问题：LLM 作为 Agent 时频繁执行"非法动作"，导致任务失败。

具体数据：

• 在 Kaggle GameArena 象棋比赛中，78% 的 Gemini-2.5-Flash 失败都源于非法走棋
• LLM 缺乏"动作可行性"感知——不知道当前状态下哪些动作是合法的

传统解决方案的困境：

• 微调（Fine-tuning）：成本高昂，每次任务规则变化需重新训练
• 手工编写 Harness：需要人类专家为每个游戏/任务编写规则验证代码，不可扩展

核心洞察：LLM 已经具备强大的代码生成能力——为什么不让 LLM 自己合成 Harness 来约束自己的行为？

3.2 做了什么

提出 AutoHarness：通过 LLM 自动合成 Harness 代码来提升 Agent 能力的框架。

三种 Harness 类型：

树搜索 + 汤普森采样：

┌─────────────────────────────────────────────────────────────────┐│                  AutoHarness 训练流程                           │└─────────────────────────────────────────────────────────────────┘                     ┌───────────────────┐                     │   初始 Harness 节点 │                     └─────────┬─────────┘                               │            ┌──────────────────▼──────────────────┐            │          树搜索（深度优先）           │            │                                     │            │  汤普森采样选择下一个待优化节点       │            │  （启发式值 = 平均合法动作准确率）    │            │                                     │            │  LLM 变异算子：                      │            │  基于失败步骤的反馈精炼代码           │            └──────────────────┬──────────────────┘                               │            ┌──────────────────▼──────────────────┐            │         并行环境评估                  │            │  10 个并行环境，最多 1000 步           │            │  每个精炼周期最多采样 5 个失败步       │            └──────────────────┬──────────────────┘                               │            ┌──────────────────▼──────────────────┐            │   终止条件                           │            │   • 达到 100% 合法动作率             │            │   • 或达到最大迭代次数               │            └─────────────────────────────────────┘

训练统计：

• 平均训练迭代：14.5 次
• 32 个游戏中有 19 个在 10 次迭代内完成
• 最困难的游戏：GermanWhist-v0、Cryptarithm-v0、Othello-v0、Chess-v0

3.3 工作原理

核心原理：将 Harness 合成形式化为程序空间搜索问题：

Harness(代码) = f(游戏规则、当前状态)                    ↓验证器 = 通过代码实现的拒绝采样器                    ↓LLM = 在合法动作空间内的智能选择器

自我强化循环：

1. Agent 在游戏中行动
2. 代码检测到非法动作
3. 记录失败案例
4. LLM 分析失败原因，修改 Harness 代码
5. 新 Harness 继续接受检验
6. 循环直至达到合法率目标

关键设计：汤普森采样平衡"探索（尝试不同逻辑结构）"与"利用（精炼部分有效的 Harness）"

3.4 达到的效果

核心成就：145 个 TextArena 游戏全部实现 100% 合法动作率

2人对战游戏（16个游戏，每个 40 场）：

1人游戏（16个游戏，每个 20 场）：

Harness-as-Policy（极限方案，测试时零 LLM 调用）：

关键数据：小模型 + AutoHarness > 大模型，且成本接近零。

3.5 关键 Insights

1. "代码作为约束"比"提示词作为约束"更可靠：代码是精确的、可验证的，而提示词是模糊的
2. 小模型 + 好 Harness > 大模型：这是一个范式性发现，动摇了"模型越大越好"的简单信念
3. 自我改进的可扩展性：AutoHarness 可以为任意文本游戏合成 Harness，无需人工参与，具有极强的扩展性
4. Harness-as-Policy 的彻底化：当 Harness 完全接管决策时，LLM 的不确定性被彻底消除——这对高风险、规则明确的领域有重大价值
5. 训练-推理解耦：训练时调用 LLM（成本高），推理时仅用代码（成本极低）——这是一个天然的成本优化架构

3.6 其他补充

• 任务范围：目前主要在文本游戏（TextArena）中验证，在结构化任务上效果显著，开放性任务中效果待验证
• 工业应用潜力：金融交易合规检查、API 调用约束、数据库操作安全——任何规则明确的约束场景均可受益
• 与 RLHF 的关系：AutoHarness 可视为"代码层面的 RLHF"，但不需要人类标注，完全由代码执行反馈驱动

四、Building AI Coding Agents for the Terminal

❝

论文信息：arXiv:2603.05344 | OpenDev（开源）| 2026年3月GitHub：https://github.com/opendev-to/opendev

4.1 工作动机

核心问题：Terminal-native AI Coding Agent 的工程设计复杂，但缺乏公开的系统性技术报告。

市场现状：

• 每个主要 AI 实验室都推出了 CLI Agent（Claude Code、Gemini CLI 等）
• TerminalBench 和 LongCLI-Bench 显示：即使是最先进的模型，在连续终端操作中也表现困难
• 大多数生产系统是闭源的，设计决策未公开

三大根本性挑战：

1. 有限上下文窗口：长时任务会超出模型的上下文容量
2. 破坏性操作防护：Shell 执行可能执行不可逆操作
3. 能力扩展 vs. Prompt 预算矛盾：添加更多工具/指令会压缩可用上下文

OpenDev 是第一份为开源 Terminal-native 交互式编码 Agent 提供全面技术报告的工作。

4.2 做了什么

构建并开源了 OpenDev：一个完整的命令行编码 Agent 系统，并系统梳理了 Scaffolding vs. Harness 的概念区分。

系统架构（4层）：

┌─────────────────────────────────────────────────────────┐│                  OpenDev 四层架构                        │├─────────────────────────────────────────────────────────┤│  Layer 1: 入口与 UI 层                                  ││   CLI → 4个共享 Manager（Config/Session/Mode/Approval） ││   双前端：TUI（同步模态审批）+ Web UI（异步轮询）        │├─────────────────────────────────────────────────────────┤│  Layer 2: Agent 核心层（Scaffolding vs. Harness 区分）  ││   Scaffolding = 首次 Prompt 前的组装阶段                ││     (系统提示编译, 工具 Schema 构建, 子 Agent 注册)     ││   Harness = 首次 Prompt 后的运行时编排                  ││     (工具调度, 上下文管理, 安全执行, 会话持久化)        │├─────────────────────────────────────────────────────────┤│  Layer 3: 扩展 ReAct 循环（每轮 6 阶段）                ││   ①前检 + 压缩 → ②思考 → ③自我批评 → ④行动 → ⑤工具执行 → ⑥后处理 │├─────────────────────────────────────────────────────────┤│  Layer 4: 双模式运营                                    ││   规划模式 → 只读 Planner 子 Agent（不见写工具）        ││   执行模式 → 完整读写工具访问                           │└─────────────────────────────────────────────────────────┘

4.3 工作原理

① Scaffolding vs. Harness 的精确区分：

② 上下文工程（Context Engineering）——三大机制：

自适应上下文压缩─────────────────当 Token 预算临近时，渐进式压缩旧观测记录，而非简单截断事件驱动系统提醒─────────────────在决策点注入目标行为指引，对抗"指令遗忘"（Instruction Fade-out）条件式提示组合─────────────────系统提示由按优先级排序的模块化章节组成，仅在上下文相关时加载

③ 5 层安全架构（深度防御）：

Layer 1: Prompt 级护栏      → 指令级约束Layer 2: Schema 级工具门控   → 双 Agent 规划/执行分离Layer 3: 运行时审批系统       → 持久化权限，用户交互审批Layer 4: 工具级验证           → 每个工具独立验证Layer 5: 用户定义生命周期钩子 → 自定义安全规则

④ 5种专业化 LLM 角色：

• Planning LLM（规划）
• Execution LLM（执行）
• Critique LLM（批评）
• VLM（视觉语言模型）
• Normal LLM（通用）

每个角色懒加载初始化，换提供商只需改配置。

4.4 达到的效果

工程设计质量：

• 三大设计演化教训被系统记录，为业界提供参考
• 首个公开的完整 Terminal Agent 技术架构

能力覆盖：

• 支持 MCP（Model Context Protocol）工具动态发现
• 3 层 Skills 层次（内置/项目/用户）
• 批量并行工具执行
• 跨会话自动化记忆积累

验证：在 TerminalBench 相关基准上具有竞争力表现

4.5 关键 Insights

1. Scaffolding vs. Harness 是两个独立的工程问题：混淆两者会导致架构问题（如原文中提到的从类层次到单一参数化 Agent 的演化）
2. 即时构建（Eager Build）优于懒加载构建：系统提示和工具 Schema 应在构造函数返回前完成，消除首次调用延迟和 MCP 发现竞争条件
3. "指令遗忘"是长时任务的核心挑战：需要在决策点主动注入行为提醒，而不依赖模型记住初始指令
4. 单一参数化 Agent > 类层次：通过构建参数（allowed_tools, system_prompt）控制行为变体，比继承体系更灵活、更易维护
5. 双模式规划+执行的必要性：LLM 在不知道写工具存在时，规划质量更高——"看不见即安心"

4.6 其他补充

• 三个核心设计演化教训：

• Agent 类型层次结构 → 单一参数化 MainAgent（解决了混合能力子 Agent 的菱形继承问题）
• 懒加载提示构建 → 即时构建模式（消除首次调用延迟和 MCP 竞争条件）
• 内联子 Agent 定义 → SubAgentSpec 注册系统（统一了内置和用户定义的 Agent）

• 三大设计原则：关注点分离 / 渐进式降级 / 透明胜于魔法

• 开放性贡献：为开源社区提供了从第一性原理出发的 Terminal Agent 设计参考

五、Anthropic：长时 Agent 的 Harness 实践

❝

来源：Anthropic Engineering Blog | 2026年作者：Justin Young 等（David Hershey, Prithvi Rajasakeran, Jeremy Hadfield 贡献）

5.1 工作动机

核心问题：长时运行的 Agent 必须在多个离散会话中工作，每个会话开始时没有关于之前所做工作的记忆。

实验观察：

• 以全栈 Web 应用开发为测试场景
• 给 Opus 4.5 一个高层次 Prompt，让其在多上下文窗口循环中运行
• 结果：无法构建出生产质量的 Web 应用

两种典型失败模式：

5.2 做了什么

设计并验证了双 Agent Harness 架构：

Initializer Agent（首次会话）：

• 编写 init.sh（开发服务器启动脚本）
• 创建 claude-progress.txt（会话间状态交接文件）
• 提交初始 Git commit（展示添加的文件）
• 编写包含 200+ 详细端到端功能描述的 feature_list.json，每条初始标记为 "passes": false

{"category": "functional","description": "新聊天按钮创建一个新对话","steps": ["点击左上角的'新建聊天'", "确认之前的消息不再显示"],"passes": false}

Coding Agent（后续每次会话）：

1. 运行 pwd 验证工作目录
2. 读取 claude-progress.txt 和 Git 日志快速了解上下文
3. 读取 feature_list.json 选择优先级最高的未完成功能
4. 运行 init.sh 启动开发服务器
5. 实现新功能前先运行基本端到端测试（Puppeteer MCP）
6. 每次只处理一个功能
7. 以 Git commit + 更新 claude-progress.txt 结束

5.3 工作原理

┌──────────────────────────────────────────────────────────────────┐│               双 Agent 长时工作流                                │└──────────────────────────────────────────────────────────────────┘第一次会话（Initializer Agent）─────────────────────────────────────────────────────────  任务：建立基础设施 + 定义完整功能规范  产出：init.sh + feature_list.json + claude-progress.txt + git commit后续每次会话（Coding Agent）─────────────────────────────────────────────────────────  START    │    ├─ 读取 claude-progress.txt + git log → 了解当前状态    │    ├─ 读取 feature_list.json → 选择最高优先级未完成功能    │    ├─ 运行 init.sh → 启动开发环境    │    ├─ 运行基本端到端测试 → 确认当前状态    │    ├─ 实现单个功能    │    └─ git commit + 更新 claude-progress.txt → 交接给下一会话  END

JSON vs. Markdown 的关键选择：

• 功能列表选择 JSON 而非 Markdown
• 原因：LLM 不太可能"意外地"修改或覆盖 JSON 结构化数据
• Markdown 列表更容易被 Agent 随意修改或删除条目

浏览器自动化测试的必要性：

• 需要 Puppeteer MCP 进行端到端浏览器测试
• 没有浏览器测试时，Claude 会过度报告功能为已通过
• 只有实际在浏览器中验证，才能防止"虚假通过"

5.4 达到的效果

失败模式对比：

最终效果：Agent 能够持续构建生产质量的全栈 Web 应用，每个会话执行干净的单功能增量，整体可合并到主干。

5.5 关键 Insights

1. Git 是最好的 Agent 跨会话记忆：Git log 提供了清晰的变更历史，无需设计复杂的记忆系统
2. 功能列表 JSON > Markdown：结构化数据比自由文本更抗 Agent 的意外破坏
3. **"每次只做一件事"**原则：是防止 Agent 过冲（over-reach）的最有效约束
4. 浏览器自动化是必要的验证工具：LLM 对自己的输出天然乐观，需要外部、客观的验证信号
5. 强硬措辞的必要性：对于关键约束（如"不得删除测试条目"），措辞的强硬程度直接影响 Agent 遵从度

5.6 其他补充

• 人类类比：claude-progress.txt + git log 的设计灵感来自"高效软件工程师跨班次工作的方式"
• 开放问题：
• 单一通用编码 Agent vs. 多 Agent 架构（测试 Agent、QA Agent、代码清理 Agent）
• 如何推广至科学研究、金融建模等非 Web 开发场景

六、横向对比与综合分析

6.1 Harness 研究的演化脉络

Harness 研究发展脉络（2024-2026）────────────────────────────────────────────────────────────────阶段一（2024）：Harness 是隐式的  → 各框架（LangGraph、AutoGen）内置 Harness 逻辑  → 无法比较、无法迁移阶段二（2025 上半年）：Harness 被识别为重要变量  → SWE-bench 等基准揭示 Harness 差异导致 6pt 性能差距  → 研究者开始有意识地设计 Harness阶段三（2025 下半年-2026 初）：Harness 走向显式化和科学化  → NLAH（清华）：Harness 外部化为自然语言文档  → Meta-Harness（Stanford）：端到端自动优化 Harness  → AutoHarness（DeepMind）：LLM 自动合成 Harness当前状态（2026.03+）：Harness 成为 Agent 工程核心竞争力  → Harness 设计能力 = Agent 系统能力的关键杠杆

6.2 各论文对比分析

6.3 共同揭示的五大原则

原则一：Harness 是第一类工程对象不再是附属于 LLM 的"包装代码"，而是与模型能力同等重要的核心组件。

原则二：状态持久化是长时 Agent 的基石File-backed State（NLAH）、Git（Anthropic）、History Filesystem（Meta-Harness）——三种形式，一个共识：跨步骤/跨会话的状态必须显式、持久、可寻址。

原则三：验证的客观性必须由外部代码保证LLM 对自己的输出天然乐观，验证必须由外部可执行代码（Puppeteer、Game Rule Checker）而非 LLM 自我评判来完成。

原则四：结构化约束 > 提示词约束代码约束（AutoHarness）、JSON 数据（Anthropic）、显式契约（NLAH）——结构化约束比提示词约束更精确、更可靠、更难被 Agent 意外破坏。

原则五：小模型 + 好 Harness 可以超越大模型AutoHarness 的 Gemini-2.5-Flash + Harness 胜过 Gemini-2.5-Pro；这是一个颠覆性发现，对资源受限场景意义重大。

七、总结

7.1 核心结论

Harness 工程化是 AI Agent 系统的下一个核心战场。

• 过去 2 年：大家关注 LLM 能力（参数规模、训练数据、RLHF）
• 现在：研究证明 Harness 设计差异可导致同等模型 6-10pt 的性能差距
• 未来：Harness 将像今天的提示词工程一样，成为每个 AI 工程师的必备技能

7.2 一句话评价

八、参考资料

**