Jean's Blog

一个专注软件测试开发技术的个人博客

0%

Harness Engineering：理解与应用

发表于 更新于 分类于
Harness Engineering 学习笔记：工程维度、生态产品与实践建议。

三大工程维度

下面用三个便于分析的维度理解智能体稳定性。它们是本文对多篇工程文章的归纳，不是行业标准，也不一定完全正交。

输入端 ✖️ 控制流 ✖️ 状态流

graph LR
    subgraph 输入端
        A[Context Engineering
上下文工程]
        A_desc["核心：管控Agent「看见」的信息
案例：项目指令｜会话压缩｜检索结果
本质：筛选、整理输入信息"]
    end
    subgraph 控制流
        B[Architectural Constraints
架构约束]
        B_desc["核心：管控Agent「能做」的动作
案例：Hook钩子｜权限闸门｜子Agent隔离
本质：划定行为红线，限制操作边界"]
    end
    subgraph 状态流
        C[Garbage Collection
上下文GC回收]
        C_desc["核心：管控Agent「持续运行」时长
案例：Token预算｜上下文压缩｜过期清理
本质：动态收敛，策略性遗忘"]
    end
    A --- B --- C
模块 核心定位 核心问题 Claude Code 实践案例 本质 代表机制
Context Engineering上下文工程【输入端】 管控 Agent 的信息输入 怎么在第一时间把对的资料喂给它
✅ Agent 能看见什么？		 1. 项目指令文件：提供稳定的仓库约定
2. 会话压缩：控制长对话体积
3. 检索与工具结果：按需加入上下文		 整理 Agent 看见的信息 Context Management、Feature List、Progress Tracking、Subagents
Architectural Constraints架构约束【控制流】 约束 Agent 行为边界 它发疯的时候，怎么硬生生按住它
✅ Agent 能做什么？		 1. Hooks：在关键生命周期插入检查
2. Permission Gate：危险操作人工确认
3. Subagent：隔离子任务上下文		 设红线、拉电闸，约束 Agent 可执行范围 Agent Loop、Tool Use、Verification Loop、Generator-Evaluator
Garbage Collection上下文回收【状态流】 动态管理上下文生命周期 内存快被撑爆时，怎么有策略地遗忘
✅ Agent 能跑多久？		 1. Token / 费用预算：限制资源消耗
2. 会话压缩：回收低价值上下文
3. Checkpoint + 新会话：必要时从外部状态恢复		 容错与动态收敛，策略性遗忘 Context Management (辅)、Feature List (辅)、Subagents (辅)、Token Budget

三支柱核心问题与判断规则

维度 核心问题 判断规则
Context Engineering Agent 能看见什么信息？看见的信息是否准确精简？ 如果一个机制在”整理 agent 接下来输入的信息”，它属于这一柱
Architectural Constraints Agent 能做什么、不能做什么？动作空间在哪里有边界？ 如果一个机制在”约束 agent 的能力或交互边界”，它属于这一柱
Garbage Collection Agent 能跑多久？成本和资源怎么回收？ 如果一个机制在”清理过期状态 / 限制成本 / 回收资源”，它属于这一柱

来源说明：三维度不是单一作者的原创定义，是本课程综合 Martin Fowler 系博客（Böckeler 2026-04-02）、Anthropic Rajasekaran（2026-03-24）、Phil Schmid（2026-01-05）多来源抽象的工程维度框架。

我们用 Claude Code 完整走一次三维度归类，从定义变成可验证的判断：

  • Context Engineering (输入端：怎么在第一时间把对的资料喂给它)：项目指令文件、检索结果、工具返回值与会话压缩都在决定“Agent 接下来能看见什么”。项目指令文件属于稳定上下文，并不等同于 RAG。

  • Architectural Constraints (控制流：它发疯的时候，你怎么硬生生把它按住)：Hooks、权限确认和子任务隔离都在约束 Agent 的动作边界。Hook 的具体事件数量会随产品版本变化，不宜写成长期固定数字。

  • Garbage Collection (状态流：内存快被撑爆时，怎么有策略地遗忘)：Token / 费用预算、上下文压缩、检查点和必要时开启新会话，都属于资源与状态生命周期管理。压缩和重置不是非此即彼，通常需要结合任务长度与外部状态设计。

应对机制与三维度的对照表

应对机制 × 三维度归属

机制 Context Engineering Architectural Constraints Garbage Collection 归属判断说明
1 Agent Loop 四相循环 辅 主 - 循环每轮都要整理 context；四相结构本身是架构约束
2 Tool Use 工具编排 - 主 - 工具 schema 本身就是一个动作空间的约束
3 Progress Tracking 主 辅 - 跨 session 的状态持久化属于 context 延展
4 Context Management 主 - 辅 本柱的核心；compaction 也有 GC 属性
5 Feature List 主 辅 辅 JSON 清单是 context 的规划层
6 Verification Loop - 主 - 事件驱动的错误显性化属于架构约束
7 Subagents 主 辅 辅 分治隔离是架构性的边界划分
8 Generator-Evaluator - 主 - 三角色分离是架构约束的典型实现

Agent Harness 的常见产品形态

截至 2026 年 8 月 19 日，与编码 Agent 相关的产品和框架可以按使用形态粗略分类。这里列的是示例，不是权威排名；产品能力、套餐和模型支持会持续变化。

形态 典型示例 主要特点 适合场景
CLI / 桌面 Agent Claude Code、OpenAI Codex、Aider 可直接操作仓库、Shell、Git 和测试工具 后端开发、批量改造、自动化任务
IDE 原生 Agent Cursor、Windsurf、Cline、Roo Code、JetBrains Junie 贴近编辑器，便于查看 diff 和交互式修改 日常编码、前端开发、结对编程
云端沙箱 Agent Devin、Replit Agent 在托管环境中异步执行任务 远程任务、团队协作、隔离运行
Agent SDK / Runtime LangGraph、DeepAgents、Claude Agent SDK、OpenAI Agents SDK 由团队自行组合工具、状态、权限和验证 自研 Agent 产品与内部平台

选择产品时应比较具体能力，而不是只看“Harness”标签：

  • 是否能限制文件、网络和命令权限；
  • 是否支持检查点、恢复和结构化进度；
  • 是否能运行真实测试并把失败反馈给模型；
  • 是否提供调用日志、成本统计和审计信息；
  • 是否允许替换模型、工具或运行环境。

Hermes Agent：可扩展的开源个人 Agent

Hermes Agent 是 Nous Research 开源的个人 Agent，提供工具调用、记忆、Skills、MCP、子 Agent 和多平台接入等能力。其仓库文档还介绍了按需生成 Skills 的能力。

需要区分两个项目：Hermes Agent 本身是可扩展 Agent；基于 GEPA 的自动技能优化属于另一个实验性项目 Hermes Agent Self-Evolution。因此，不宜把“所有技能都会自动持续进化”写成 Hermes Agent 的默认保证。

与 Claude Code 之类的编码 Agent 相比，Hermes Agent 更偏通用个人 Agent 和多渠道自动化。二者目标不同，不适合用“谁更先进”一概而论。

官方建议

【建议一】 harness 会过时

“A harness encodes assumptions that go stale. What works for Claude 3.5 may not work for Claude 4.5.”——Anthropic 官方博文（2025-11-26 Effective Harnesses for Long-Running Agents，Justin Young）

翻译：harness 固化了一组关于模型的假设，这些假设会过期。对 Claude 3.5 有效的 harness，换成 Claude 4.5 可能就失效了。

对我们的含义：不要把 harness 当成一次性架构写死，要像管理软件一样持续迭代。

排查方法：在固定任务集、权限和预算下做版本回归。如果成功率下降、人工干预增加，或新模型接入后旧规则频繁阻碍任务，应先检查并裁剪过时约束，而不是继续叠加流程。

具体信号/行动：

怎么判断、怎么做

信号：同类任务成功率连续下降 5pp 以上

信号：新模型上线后旧 harness benchmark 反而退步

行动：每次模型升级后跑一次 benchmark 对比

术语解读

  1. pp：percentage point，百分点。下降 5pp 即指标绝对值降低 5 个百分点。
  2. harness：AI 领域常用，指自动化评测调度框架，用于批量执行测试用例。
  3. benchmark：基准测试，固定测试数据集，用来量化模型能力，做版本横向对比。

业务含义说明

这是大模型迭代过程中的模型退化（regression）监控策略：

  • 两类预警信号，用来及时发现新版本模型能力变差；
  • 标准处置动作：模型每次版本升级，必须完整执行基准评测，和旧版本指标对比，提前识别性能滑坡。

【建议二】 Build to Delete（建造以便删除）

“The best harness is the one you’re most willing to throw away and rewrite. The dataset of failures from your current harness is more valuable than the harness itself.”——Phil Schmid 博文 2026-01-05（Bitter Lesson 三原则之一）

翻译：最好的 harness 是最愿意扔掉重写的那个。当前 harness 的失败样本比 harness 本身更有价值。

对我们的含义：不要给 Harness 增加舍不得删除的复杂度。模型、工具和任务变化后，旧约束可能从保护措施变成阻碍。

后果：随着模型能力提升，过时的刚性控制流可能降低成功率，并增加维护与调试成本。

具体信号/行动：

怎么判断、怎么做

› 信号：改一个 bug 牵动 5+ 处刚性流程 —— 刚性过强该重写

› 行动：failure log 当一等公民留存，harness 可以扔，数据不能扔

术语与理念解读

  1. 刚性流程 代码耦合严重，一处逻辑改动会连锁影响多处模块，修改成本极高、极易引发次生 bug，是系统需要重构的典型信号。
  2. failure log（失败日志） 故障、用例失败的原始日志，是定位问题、沉淀测试案例的核心资产，需要长期保存。
  3. harness 自动化评测 / 执行框架，属于上层工程载体；框架代码可以迭代、废弃。
  4. 核心思想 原始业务数据、失败样本具备长期价值；承载测试的工程框架可以随时重构迭代。

【建议三】 三类设计取舍没有唯一答案

Harness Engineering 仍在快速演化，下面三类选择通常需要通过任务数据决定：

  1. 单 Agent 循环 vs 多 Agent 分治

    • 单循环结构简单、状态集中，但长任务容易让上下文膨胀。
    • 多 Agent 隔离性更好，但会引入协调、重试和结果合并成本。

  2. 压缩上下文 vs 新会话恢复

    • 压缩能保留部分历史，但摘要可能遗漏细节。
    • 新会话更干净，但必须依赖 Feature List、Checkpoint 和进度文件恢复关键状态。

  3. CLI-first vs IDE-native

    • CLI 适合脚本化、批量改造和长任务。
    • IDE 适合高频交互、查看 diff 和视觉反馈。

正确做法不是追随某家厂商的固定路线，而是在相同任务集上比较成功率、人工干预次数、成本、时延和可审计性。