Harness Engineering 的产品实践

前两篇文章分别介绍了 Harness Engineering 的概念和治理机制，本文进一步回答“这些机制在真实产品中如何落地”。重点对比四种代表性实现：Claude Code、OpenAI Codex、LangChain Deep Agents 和 Hermes Agent。

本文不把产品官网中的所有功能都算作 Harness，而是只关注直接影响 Agent 执行质量的部分：上下文、工具、权限、运行循环、状态、验证、记忆和多 Agent 协作。产品更新很快，文中的能力说明以 2026 年 8 月 21 日公开文档为准。

三大工程维度

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

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

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

Agent Harness 的常见产品形态

截至 2026 年 8 月 21 日，Agent Harness 并不是一个统一的产品类别。Claude Code、Codex 是面向开发者的完整编码 Agent；Deep Agents 是用于构建 Agent 的框架；Hermes Agent 更接近可长期运行、支持多消息渠道的个人 Agent。它们处在不同抽象层，不能只根据功能数量直接排名。

产品 / 框架	产品层级	Harness 的主要载体	核心优势	典型使用场景
Claude Code	编码 Agent / Agent SDK	CLAUDE.md、Rules、Skills、Hooks、Permissions、MCP、Subagents、Auto Memory	项目规则、确定性钩子与上下文隔离结合紧密	本地编码、仓库维护、长任务开发
OpenAI Codex	编码 Agent / CLI、IDE、Cloud、SDK、App Server	AGENTS.md、Skills、Hooks、MCP、Sandbox、Approvals、Subagents、Worktrees	沙箱和审批边界清晰，覆盖本地与云端执行	编码、审查、自动化、并行任务和平台集成
LangChain Deep Agents	Agent Harness 框架	Middleware、Backends、Filesystem、Skills、Memory、Subagents、Permissions、HITL	组件可组合、模型与存储后端可替换	自研研究 Agent、编码 Agent、企业内部 Agent
Hermes Agent	长期运行的个人 Agent	Tools、Skills、Memory、Gateway、Context Files、Checkpoints、Approvals、MCP	多渠道接入、持久记忆、Agent 可管理技能和记忆	个人助手、消息机器人、定时任务、远程自动化

本章描述的是产品公开能力，不代表四者内部实现完全等价。某个功能“存在”，也不等于默认启用、安全边界相同或适合生产环境。

共同运行骨架

虽然实现方式不同，这些 Harness 通常都围绕相似的闭环工作：

flowchart LR
    U[用户任务] --> C[构建上下文]
    C --> M[模型规划与决策]
    M --> G{权限与策略检查}
    G -->|允许| T[工具 / Skill / 子Agent]
    G -->|需确认| H[人工审批]
    H --> T
    T --> O[观察执行结果]
    O --> V[测试 / 验证 / 评估]
    V -->|未完成| C
    V -->|完成| R[返回结果并保存状态]

真正拉开产品差异的不是“是否会调用工具”，而是以下问题：

上下文从哪里来，何时加载和压缩；
工具运行在本机、沙箱还是远程环境；
权限是在提示词中提醒，还是由确定性机制强制执行；
长任务如何保存进度、恢复和并行执行；
Skills 和记忆由人维护，还是允许 Agent 在受控范围内写入；
失败是否能被测试、Hook、评估器和人工审核及时发现。

Claude Code Harness

产品定位

Claude Code 的 Harness 是一套由项目指令、渐进加载的技能、生命周期 Hook、工具权限、MCP、子智能体和自动记忆共同组成的运行环境。将它概括为“全靠人配置”已经不准确：团队仍然负责定义规则和安全边界，但 Claude Code 也提供自动记忆、自动压缩、自动委派和由模型参与判断的 Hook。

常见项目结构可以写成：

your-project/
├─ CLAUDE.md                  # 仓库级持久指令
├─ CLAUDE.local.md            # 个人本地指令，可按团队规则忽略提交
└─ .claude/
   ├─ settings.json           # 权限、Hooks、插件等项目配置
   ├─ settings.local.json     # 本机覆盖配置
   ├─ rules/                  # 可按路径加载的模块化规则
   ├─ skills/<name>/SKILL.md  # 按需加载的领域知识和工作流
   └─ agents/<name>.md        # 自定义 Subagent 定义

MCP Server 可以通过项目或用户配置连接；Hooks 可以是命令、HTTP、Prompt 或 Agent 类型，具体支持范围取决于版本和事件类型。

关键组件

组件	加载 / 触发时机	作用	注意事项
CLAUDE.md / Rules	会话启动或访问匹配路径时	提供架构、命令、规范和项目约束	指令是引导，不是强制安全边界；内容过长会占用上下文
Skills	描述先加载，正文按需加载	封装参考知识、脚本和多步骤工作流	Skill 可以手动创建，也可以让 Claude 协助生成，仍需评审
Hooks	工具、会话、权限和压缩等生命周期事件	格式化、日志、阻断危险动作、执行验证	命令 Hook 权限高；需要限制脚本来源和输出内容
Subagents / Agent Teams	主 Agent 委派或用户显式启动	隔离上下文、并行处理专门任务	Subagent 适合返回摘要；Agent Teams 适合独立协作
Auto Memory	会话开始读取，运行中按需写入	记录项目经验和用户偏好	是本机 Markdown 记忆，可审计、编辑和删除
MCP	会话启动发现工具，Schema 按需加载	连接外部工具和数据源	MCP 断连、权限和提示注入仍需治理
Permissions	每次敏感工具调用前	控制文件、Shell、网络和外部能力	Prompt 中写“禁止”不等于真正阻止，应使用权限或 Hook

Claude Code Harness 运行流程图

flowchart TD
    U[用户任务] --> L[加载 CLAUDE.md / Rules]
    AM[Auto Memory] --> L
    SD[Skill 描述 / MCP 工具名] --> L
    L --> M[Claude 规划下一步]
    M --> D{选择执行方式}
    D -->|直接处理| A[生成或修改内容]
    D -->|复杂子任务| S[Subagent / Agent Team]
    D -->|工具调用| P{Permissions + PreToolUse Hook}
    P -->|拒绝| X[返回阻断原因]
    P -->|需确认| H[用户审批]
    H --> T[内置工具 / MCP / Shell]
    P -->|允许| T
    S --> O[返回摘要或产物]
    T --> O[工具结果]
    A --> Q[PostToolUse / Tests / Lint]
    O --> Q
    Q -->|失败| M
    Q -->|完成| C[返回结果]
    C --> W[按需更新 Auto Memory]

适合与边界

适合：仓库级编码、需要 Hooks 强制验证、需要子任务隔离以及深度使用 Claude 模型的场景。

边界：

Auto Memory 不等于完整的业务知识库或任务数据库；
Hooks 能强制执行确定性规则，但 Hook 自身也需要安全审查；
Skills 和记忆可以由 Agent 协助创建或更新，不能因此视为经过验证的“自动进化”；
直接操作本机时仍要严格控制网络、凭据和危险命令权限。

官方资料：Claude Code 功能总览、Hooks、Memory、Subagents。

OpenAI Codex Harness

产品定位

Codex 的 Harness 跨越 CLI、IDE、Cloud、桌面应用、SDK 和 App Server。它不只是“Rust 内核里的安全逻辑”，而是一套由项目指令、Skills、Hooks、MCP、沙箱、审批、子智能体、工作树和线程 / 任务状态组成的执行环境。

常见配置载体包括：

your-project/
├─ AGENTS.md                 # 项目指令，可按目录层级覆盖
├─ .agents/skills/           # 项目级 Skills（按支持的来源发现）
└─ project files

~/.codex/
├─ config.toml               # 模型、沙箱、MCP、通知等本地配置
└─ skills/                   # 用户级 Skills

Codex 不同运行表面的配置和持久化方式并不完全相同，因此文章中不应把 CLI、Cloud、桌面应用和 App Server 描述成同一个固定内核流程。

关键组件

组件	作用	工程意义
AGENTS.md	提供仓库结构、构建命令、测试规范和目录级规则	将团队知识放到 Agent 可发现的位置
Skills / Plugins	封装可复用工作流、参考资料、脚本和连接能力	减少重复提示，支持团队分发和版本化
Sandbox	限制文件写入、网络和命令执行范围	降低 Agent 对宿主机和仓库的破坏半径
Approvals	在越过权限边界或执行敏感动作前请求批准	把人类确认放在真正有风险的节点
Hooks	在 Codex 生命周期中执行确定性脚本	用于检查、通知、审计和组织策略
MCP	连接第三方工具与上下文	统一外部系统接入方式
Subagents / Worktrees	将任务拆分到独立上下文或工作树	支持并行分析和写入隔离
Threads / Tasks	保存任务对话、工具执行和结果	支持继续、审查、远程协作和自动化
App Server / SDK	将 Codex 嵌入自有产品或工作流	复用 Codex Runtime，而不必只依赖终端界面

Codex Harness 运行流程图

flowchart TD
    U[用户 / Issue / 自动化事件] --> E{运行入口}
    E -->|CLI / IDE / App| L[本地任务]
    E -->|Cloud / Remote| C[隔离云环境]
    L --> I[加载 AGENTS.md / Skills / Memory]
    C --> I
    I --> M[模型规划与工具选择]
    M --> G{Sandbox + Rules + Approval Policy}
    G -->|允许| T[Shell / 文件 / MCP / Browser]
    G -->|需批准| H[用户或 Reviewer 审批]
    H --> T
    G -->|拒绝| B[返回边界原因并调整计划]
    T --> V[运行测试 / Lint / Review Diff]
    V -->|失败| M
    V -->|可并行| S[Subagent / Worktree Task]
    S --> V
    V -->|完成| R[生成可审查结果]
    R --> P[保存任务状态 / 继续或交付]

适合与边界

适合：需要本地和云端协同、严格沙箱与审批、并行工作树、代码审查以及把编码 Agent 嵌入内部平台的场景。

边界：

沙箱策略和权限模式需要按运行表面分别配置；
AGENTS.md 和 Skills 可以提升一致性，但仍需要测试和 Review 形成事实反馈；
Hooks 已是公开能力，原文“Codex 无用户自定义脚本钩子”的判断已经过时；
Codex 可以保存和复用工作流，但不能把所有任务产物都视为自动验证过的长期记忆。

官方资料：Codex 文档索引、AGENTS.md、安全与审批、Hooks、Skills、App Server。

LangChain Deep Agents Harness

产品定位

Deep Agents 是构建在 LangChain Agent 基础组件之上的独立 Harness 库。它仍然使用模型—工具循环，但预置了规划、文件系统、上下文卸载、自动摘要、子智能体、Skills、Memory、权限和 Human-in-the-loop 等能力。

它与 Claude Code、Codex 的区别是：Deep Agents 主要提供可编程框架，而不是固定的终端编码产品。 开发者需要自行选择模型、存储后端、沙箱、部署方式和业务工具。

关键组件

组件	作用	关键配置
Planning	使用 `write_todos` 拆解任务和跟踪进度	Smart Defaults / System Prompt
Filesystem Tools	通过文件保存计划、长结果和中间产物	State、Filesystem、Store、Sandbox、Composite Backend
Auto Summarization	上下文过长时压缩旧消息	Context Middleware
Subagents	使用 `task` 委派专门任务并隔离上下文	同步、异步、自定义或编译后的 LangGraph
Skills	通过渐进披露加载 `SKILL.md` 和相关资源	`skills=[...]`，可为只读或可写
Memory	启动时加载 AGENTS.md 型记忆，并允许受控更新	`memory=[...]` + 持久化 Backend
Permissions / HITL	控制内置文件工具，并对敏感工具调用中断审批	`permissions=`、LangGraph Interrupt
Middleware / Profiles	插入模型调用、工具调用和 Harness 策略	`middleware=`、Harness Profile

需要注意：Deep Agents 的文件权限主要约束内置文件系统工具；自定义工具和 MCP 工具必须自行实现权限控制。

Deep Agents Harness 运行流程图

flowchart TD
    U[业务请求] --> F[create_deep_agent 配置]
    F --> C[加载 System Prompt / Memory / Skill 元信息]
    C --> P[write_todos 规划任务]
    P --> M[模型决定下一步]
    M --> D{执行路径}
    D -->|资料或大结果| FS[Filesystem Backend 卸载上下文]
    D -->|专门子任务| S[task → Subagent]
    D -->|业务动作| T[Custom Tool / MCP / execute]
    FS --> O[读取必要摘要]
    S --> O
    T --> G{Permissions / HITL / Middleware}
    G -->|拒绝或待审批| H[人工处理]
    G -->|允许| O[观察结果]
    O --> V[更新 Todo / 验证结果]
    V -->|未完成| M
    V -->|上下文过长| A[Auto Summarization]
    A --> M
    V -->|完成| R[输出产物并 Checkpoint]
    R --> W[按 Backend 策略持久化 Memory / Skill]

适合与边界

适合：需要模型无关、后端可插拔、复杂任务分解和企业业务定制的 Agent 产品。

边界：

默认 StateBackend 只在单个 Thread 中保存文件；跨 Thread 记忆需要 Store 或 Composite Backend；
本地文件和 LocalShell Backend 可能直接访问宿主机，不等同于安全沙箱；
Deep Agents 支持 Agent 写入 Memory，配置写权限后也可以创建或更新 Skills，因此原文“Skills 只能人工维护”已经过时；
框架提供可学习的存储机制，但不会自动替你完成评测、版本选择和安全发布闭环。

官方资料：Deep Agents Overview、Backends、Skills、Memory、Permissions。

Hermes Agent Harness

产品定位

Hermes Agent 是一个可以从 CLI 或消息网关长期运行的开源个人 Agent。它把多模型接入、工具集、Skills、持久记忆、项目上下文文件、Checkpoint、定时任务、MCP 和多个消息平台整合到同一个 Runtime 中。

Hermes 的突出特点不是“内置 GEPA 自动进化”，而是：

Agent 可以通过工具主动写入 MEMORY.md 和 USER.md；
Agent 可以创建、更新和删除 Skills；
Skill 和记忆写入可以要求人工审批；
Gateway 可以把同一个 Agent 接入多个聊天平台，并维护会话路由。

原文把 GEPA 描述成 Hermes Runtime 已集成的后台优化引擎，没有找到官方产品文档依据。GEPA 相关工作应作为独立研究或未来扩展讨论，而不是写成当前产品的默认运行流程。

关键组件

组件	作用	注意事项
AIAgent Loop	模型调用、工具调用和观察结果的主循环	实际能力取决于模型和启用的 Toolsets
Tools / Toolsets	Web、Terminal、File、Browser、Memory、Skills、Delegation 等	不同入口可以启用不同工具集
Skills	按需加载的流程和领域知识	Agent 可通过 `skill_manage` 写入；建议启用写审批
Memory	`MEMORY.md` 保存环境经验，`USER.md` 保存用户偏好	容量有界，启动时作为快照注入；可启用写审批
Session Search	检索本地历史会话	是原始会话检索，不等同于全部内容自动进入上下文
Context Files	读取 `.hermes.md`、AGENTS.md、CLAUDE.md 等项目指令	需要控制文件长度和可信度
Gateway	将 Telegram、Discord、Slack、WhatsApp 等消息路由到 Agent	必须配置发送者授权、平台权限和凭据隔离
Checkpoints	修改文件前保存工作目录快照	提供回滚安全网，但不能替代 Git 和测试
Sandbox / Approvals	控制终端执行和高风险操作	Local Backend 可能直接使用宿主机权限，应谨慎配置

Hermes Agent Harness 运行流程图

flowchart TD
    U[CLI / Web / 消息平台] --> GW[Gateway / Session Router]
    GW --> C[加载 Context Files]
    MEM[MEMORY.md / USER.md / Session Search] --> C
    SK[Skill 描述与 Toolsets] --> C
    C --> M[AIAgent 调用模型]
    M --> D{选择动作}
    D -->|加载流程| SV[skill_view]
    D -->|执行任务| T[Terminal / File / Browser / MCP]
    D -->|并行委派| SUB[Delegation / Subagent]
    SV --> M
    T --> G{权限 / 危险命令审批 / 沙箱}
    SUB --> O[子任务结果]
    G -->|需审批| H[用户批准或拒绝]
    H --> O
    G -->|允许| O[工具结果]
    O --> V[验证并继续循环]
    V -->|未完成| M
    V -->|完成| R[返回结果 / 消息投递]
    R --> CP[Checkpoint / Session DB]
    R --> K{是否沉淀经验}
    K -->|记忆| MW[Memory 写入审批]
    K -->|技能| SW[Skill 写入审批]
    MW --> MEM
    SW --> SK

适合与边界

适合：需要多消息平台、持久个人记忆、定时任务和远程操作入口的个人或团队助手。

边界：

“Agent 能写 Skill”不等于 Skill 会自动变好，仍需要验证、版本管理和回归评测；
Memory 是有容量限制的 Markdown 状态，不应保存密钥和大段原始日志；
消息网关扩大了攻击面，必须使用发送者白名单、审批和隔离终端；
使用本地 Terminal Backend 时，命令可能以宿主用户权限执行，不能把“支持沙箱”误写成“所有执行默认隔离”。

官方资料：Hermes Agent、Features、Memory、Skills、Messaging Gateway。

产品对比与选型

对比维度	Claude Code	OpenAI Codex	Deep Agents	Hermes Agent
主要定位	Claude 编码 Agent	跨本地、云端和平台集成的编码 Agent	可编程 Agent Harness	长期运行的个人 Agent
项目指令	CLAUDE.md / Rules	AGENTS.md	System Prompt / Memory	`.hermes.md` / AGENTS.md 等
Skills	渐进加载，可人工或在 Agent 协助下创建	Skills / Plugins / Record & Replay	渐进加载，可配置只读或可写	渐进加载，Agent 可通过工具管理
记忆	Auto Memory + 项目指令	Memories / 项目上下文，能力随运行表面变化	Backend + AGENTS.md 型 Memory	MEMORY.md + USER.md + Session Search
扩展拦截	Command / HTTP / Prompt / Agent Hooks	Hooks、Rules、Approvals	Middleware、Profiles、HITL	插件、审批与工具策略
执行环境	本机或配置的 Agent SDK 环境	本地沙箱、Worktree、Cloud 环境	State / Local / Store / Sandbox Backend	Local、Container / Sandbox Backend
多 Agent	Subagents、Agent Teams	Subagents、并行任务和 Worktrees	同步 / 异步 Subagents	Delegation 和多 Profile / Gateway
适合谁	直接使用 Claude 完成开发工作	需要多表面、自动化和平台集成的团队	需要自研 Agent 产品的工程团队	需要多渠道长期个人助手的用户

选型建议

想直接在仓库中使用 Claude，并重视 CLAUDE.md、Hooks 和上下文隔离：选择 Claude Code；
想同时使用 CLI、IDE、Cloud、App Server，并重视沙箱、审批和并行工作树：选择 Codex；
想自己定义模型、Middleware、Backend、权限和业务工具：选择 Deep Agents；
想让 Agent 长期运行并接入多个消息平台，允许受控维护个人记忆和 Skills：选择 Hermes Agent。

不要只问“哪个 Harness 功能最多”，而应使用同一组真实任务比较：

任务成功率和一次通过率；
人工审批与纠错次数；
Token、时间和基础设施成本；
失败是否容易定位、恢复和回放；
权限边界是否能被确定性执行；
生成代码和业务结果是否经过真实验证。

工程实践建议

建议一：把 Harness 当作会过期的软件

Harness 会固化对模型、工具和任务的假设：模型是否善于规划、工具描述需要多详细、哪些步骤必须由规则强制执行、上下文应该保留多少。模型或业务变化后，这些假设可能从“护栏”变成“阻力”。

Anthropic 在 2026 年关于长任务 Harness 的文章中也强调，应根据新模型能力简化 Scaffold，而不是让旧规则永久累积。

实践方式：

建立固定的真实任务集，而不是只用简单 Demo；
模型、Prompt、Skill、Hook 或工具升级后运行回归评测；
同时观察成功率、人工干预、成本、时延和错误类型；
当新模型能够稳定自行完成某一步时，尝试删除对应的冗余流程；
失败后先确认问题来自模型、上下文、工具还是 Harness，不要默认继续增加 Prompt。

flowchart LR
    C[模型 / 工具 / 业务变化] --> B[固定任务集回归]
    B --> M[比较成功率、成本、干预和时延]
    M --> D{旧约束仍有价值?}
    D -->|是| K[保留并继续监控]
    D -->|否| R[删除或简化]
    R --> B

建议二：Build to Delete

Harness 的规则、Hook 和中间件应该能够独立替换，而不是和业务代码深度耦合。真正值得长期保存的资产通常是：

真实任务和验收标准；
失败轨迹与根因分类；
安全事件和人工审批记录；
回归测试集和评估结果；
可复现的环境、输入数据与最终产物。

不要把“修改一个缺陷需要改几个文件”机械地作为重构阈值。更可靠的信号是：同一规则需要在多个入口重复实现、删除一个 Hook 会破坏无关功能，或者无法在不启动完整 Agent 的情况下单独测试某个策略。

推荐设计：

Agent Loop
  ├─ Context Provider       可替换
  ├─ Permission Policy      可测试
  ├─ Tool Adapter           可替换
  ├─ Verification Policy    可测试
  ├─ Memory Backend         可迁移
  └─ Evaluation Dataset     独立长期保存

建议三：确定性治理和模型判断分层

不是所有控制都应该写进 Prompt，也不是所有判断都应该变成硬编码规则。

问题	更适合的机制
是否允许删除生产数据	权限系统、沙箱、人工审批
是否必须运行测试	Hook、CI 或 Workflow
当前任务应该调用哪个分析工具	模型判断
结果是否符合固定 Schema	程序校验器
代码是否真正满足模糊业务意图	模型评审 + 人工验收
超过 token、时间或费用预算	Runtime 硬限制

原则是：安全、预算和不可逆副作用使用确定性边界；语义理解、任务分解和开放式评价使用模型能力。

建议四：产品能力必须落到验证闭环

产品提供 CLAUDE.md、AGENTS.md、Skills、Memory 或 Subagents，并不意味着任务就会可靠完成。一个可落地的 Harness 至少需要四类反馈：

环境反馈：工具是否真实执行，文件和外部状态是否改变；
程序反馈：测试、Lint、类型检查和 Schema 校验是否通过；
模型反馈：独立 Reviewer 或 Evaluator 是否发现语义问题；
人工反馈：高风险动作和最终交付是否经过负责人确认。

flowchart TD
    A[Agent 生成变更] --> E[环境执行]
    E --> P[程序验证]
    P -->|失败| A
    P -->|通过| R[模型 Reviewer]
    R -->|发现问题| A
    R -->|通过| H{是否高风险}
    H -->|是| U[人工审批]
    H -->|否| O[交付结果]
    U -->|批准| O
    U -->|拒绝| A

建议五：用同一任务集完成产品选型

不要使用厂商 Demo 判断 Harness 优劣。可以准备 20～100 个来自真实项目的任务，覆盖：

小型缺陷修复；
跨文件功能开发；
测试失败诊断；
大规模重复改造；
权限受限任务；
长上下文与恢复任务；
需要多 Agent 协作的任务。

在相同模型能力、权限和预算下，比较不同 Harness 的：

完成率和一次通过率；
测试通过率与隐藏用例通过率；
人工审批、追问和纠错次数；
Token、时间和基础设施成本；
错误恢复能力和轨迹可读性；
安全策略是否真正阻止越权操作。

最终选型不是“Claude Code、Codex、Deep Agents、Hermes 谁更先进”，而是：哪个 Harness 在你的任务、风险和运维条件下，提供了最小而充分的控制。

Jean's Blog

Harness Engineering：Agent Harness 产品架构、运行流程与选型

Harness Engineering 的产品实践

三大工程维度

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

Agent Harness 的常见产品形态

共同运行骨架

Claude Code Harness

产品定位

关键组件

Claude Code Harness 运行流程图

适合与边界

OpenAI Codex Harness

产品定位

关键组件

Codex Harness 运行流程图

适合与边界

LangChain Deep Agents Harness

产品定位

关键组件

Deep Agents Harness 运行流程图

适合与边界

Hermes Agent Harness

产品定位

关键组件

Hermes Agent Harness 运行流程图

适合与边界

产品对比与选型

选型建议

工程实践建议

建议一：把 Harness 当作会过期的软件

建议二：Build to Delete

建议三：确定性治理和模型判断分层

建议四：产品能力必须落到验证闭环

建议五：用同一任务集完成产品选型