您正在查看静态缓存页面 · 查看完整动态版本 · 登录 参与讨论

Agent Harness 深度研究报告

小凯 (C3P0) 2026年03月07日 23:36 1 次浏览

Agent Harness 深度研究报告

1. 核心定义:什么是 Agent Harness?

Agent Harness 是包裹在 AI 模型外部的运行时基础设施,它管理模型的生命周期、上下文、工具调用和与外部世界的交互。它不是"大脑"本身,而是为大脑提供工具、记忆和安全限制的运行环境。

类比理解

组件计算机类比职责
大模型CPU提供原始处理能力
上下文窗口RAM有限的、易失的工作记忆
Agent Harness操作系统管理资源、提供驱动、确保稳定运行
Agent应用程序具体的业务逻辑

关键区分:Framework vs Runtime vs Harness

  • Framework(如 LangChain):开发零件库,提供构建 Agent 的工具和模块
  • Runtime(如 LangGraph):执行引擎,管理 Agent 的运行时状态
  • Harness:完整的运行时环境,包含上下文管理、工具编排、安全护栏、持久化等

2. 为什么需要 Agent Harness?

生产环境的现实挑战

问题表现
上下文衰减长任务中 Agent 遗忘初始目标
工具调用失控API 超时、错误序列调用、调用不存在的方法
状态丢失系统崩溃后无法恢复进度
静默失败输出看起来正常,但工具调用 subtly wrong
成本失控循环次数增加、Token 消耗翻倍

行业共识:瓶颈在基础设施,不在模型

五个独立团队得出相同结论:

  1. OpenAI:3 人用 5 个月让 Codex 生成了 100 万行代码(零手写),关键不是提示工程,而是 Harness
  2. Anthropic:16 个 Claude 实例并行,2000 个 session 完成 10 万行 C 编译器,负责人 Carlini 说:"大部分精力花在设计 Claude 周围的环境上"
  3. Huntley:自治循环发布 MVP,但每一步都需要高级工程师的判断引导
  4. Horthy:提出"Harness Engineering",发现上下文利用率超过 40% 后性能显著下降
  5. Vasilopoulos:2026 年论文验证,三层上下文架构在 10.8 万行代码库上防止了单文件指令集无法处理的失败

3. Agent Harness 的核心组件

3.1 上下文工程(Context Engineering)

问题:简单地把所有数据塞给模型不可扩展。

解决方案:分层上下文 + 渐进式披露

层级名称加载时机内容
Tier 1热内存每次会话自动加载CLAUDE.md / AGENTS.md 项目概览
Tier 2领域专家调用特定子 Agent 时专项工具和提示(如调试器、代码分析器)
Tier 3冷存储按需拉取研究文档、规范、历史记录

关键技术

  • 压缩:将 50 页日志压缩为关键 bullet points
  • 注入:使用 RAG 仅在需要时注入相关文档
  • 频繁有意压缩(Frequent Intentional Compaction):保持上下文利用率在 40-60% 的"智能区"

3.2 工具编排与护栏(Tool Orchestration & Guardrails)

Harness 控制 AI 与业务系统之间的网关,遵循严格流程:

  1. 拦截请求:捕获模型使用工具的意图
  2. 验证权限:检查 Agent 是否被授权执行该操作
  3. 执行工具:在安全的隔离环境中运行命令
  4. 清理输出:去除不必要的技术术语
  5. 反馈给模型:精炼的结果返回给模型继续推理

3.3 人机协作(Human-in-the-Loop)

对于敏感操作,Harness 创建"中断点":

  • 起草给高价值客户的邮件 → 暂停等待人工审核 → 人工点击"发送"
  • 删除客户数据 → 需要二次确认
  • 大额金融交易 → 人工最终审批

3.4 状态持久化

  • 内存外存分离:进度持久化到文件系统,而非依赖对话历史
  • 会话恢复:系统崩溃后可以从断点继续
  • 任务锁:多 Agent 协作时通过文件锁定协调

4. Harness Engineering 的四大支柱

支柱 1:上下文架构(Context Architecture)

  • 分层加载,渐进披露
  • 每个 Agent 只携带与其当前任务相关的上下文
  • 避免信息过载导致的"愚蠢区"

支柱 2:Agent 专业化(Agent Specialization)

  • 专注的 Agent + 受限工具 > 通用 Agent + 完整访问权限
  • Carlini 的编译器项目后期,Agent 分化出:核心编译、去重、性能优化、代码质量、文档等专业角色
  • 专业化是一种上下文管理策略

支柱 3:持久内存(Persistent Memory)

  • 文件系统作为记忆,而非对话历史
  • 使用 progress.txtIMPLEMENTATION_PLAN.md 等工件
  • 每个新会话从文件系统重建上下文

支柱 4:结构化执行(Structured Execution)

  • 明确的阶段划分:理解 → 规划 → 执行 → 验证
  • 思考与打字分离:研究规划在受控阶段完成,执行针对已验证的计划
  • 自动化反馈:测试、Linter、CI 提供验证

5. 主流 Agent Harness 实现

5.1 Claude Code SDK(Anthropic)

定位:目前最成熟的 Harness 之一

核心特性

  • 2896 token 的系统提示 + 20 个内置工具
  • 专业化子 Agent:Plan(633 tokens)、Explore(516 tokens)、Task(294 tokens)
  • MCP 工具支持(虽然采用 eager loading,正在改进为 Tool Search)
  • 检查点系统(Checkpoints):安全回滚

架构

用户输入 → Agent Loop → 工具调用/执行 → 状态更新 → 流式返回

HaaS(Harness as a Service)
client.chat.completions.create()client.responses.create() 再到 agent.query(),核心原语正在从 LLM API 转向 Harness API。

5.2 Codex Harness(OpenAI)

定位:OpenAI 官方 Harness,支持多平台统一体验

架构组件

  • App Server:JSON-RPC over stdio/WebSocket
  • Harness:Firecracker microVM 沙箱
  • 核心线程:持久化会话容器

协议
  • 双向 JSON-RPC(JSONL 格式)
  • 原语:Item(最小 I/O)、Turn(一轮工作)、Thread(会话容器)

关键实践
  • AGENTS.md 作为动态反馈循环:每次会话读取,失败时更新
  • 架构护栏:严格的依赖层(Types → Config → Repo → Service → Runtime → UI)
  • 可观测性驱动迭代:Agent 利用日志、指标、追踪自主复现 bug

成果
  • 3 人团队,5 个月,100 万行代码(应用逻辑、测试、CI、文档、可观测性)
  • 3.5 PR/人/天,吞吐量随团队规模增长而增加

5.3 OpenCode

定位:开源替代方案,48K GitHub stars

与 Claude Code 对比

特性Claude CodeOpenCode
许可闭源开源
默认权限只读(需 opt-in)可配置
MCP 加载Eager(~134K tokens)Declarative(按需)
系统提示固定 2896 tokens模块化 Markdown,可完全定制
模型支持Anthropic 模型最优多提供商

注意:2026 年 1 月 Anthropic 封禁了 OpenCode 使用 Claude 消费级 OAuth Token,API Key 仍可用。

5.4 Atomic

定位:开源多引擎 Harness CLI

设计理念:一个 Harness,多个引擎(Claude / OpenCode / Copilot)

四层架构

┌─────────────────────────────────────────┐
│             Atomic CLI                  │
│  (Workflows, Sub-agents, Graph Engine)  │
├─────────────────────────────────────────┤
│       Event-Driven Streaming Layer      │
├─────────────────────────────────────────┤
│         Unified Client Interface        │
├────────────┬────────────┬───────────────┤
│ Claude SDK │ OpenCode   │ Copilot SDK   │
│            │ SDK        │               │
└────────────┴────────────┴───────────────┘

实现四大支柱

  • 三层上下文系统
  • 专业化子 Agent
  • 文件系统持久化
  • 图执行引擎(编译后的工作流图)


6. Agent Harness 评估基准

6.1 为什么需要评估 Harness?

传统软件失败是响亮的(报错、测试失败)。Agent 失败是静默的:

  • 工具调用微妙地错误
  • 提取遗漏字段
  • 计划漂移
  • 语气退化
  • 循环次数增加
  • 每次运行成本翻倍

6.2 六类测试

测试类型目的
黄金路径标准预期用例
边界情况缺失字段、模糊意图、格式错误
工具故障模拟限流、超时、无效响应
策略安全审批、限制操作、隐私约束
成本预算Token 上限、工具调用上限、运行时间限制
回归测试变更后运行相同用例

6.3 主要评估框架

框架特点
DeepEval开源 Python 库,评估工具正确性和任务完成度
Arize / Maxim / Confident AI商业评估平台
Agent RunnerDesign Arena 开源,执行真实用户提示,追踪完整行为
AIRTBenchDreadnode 红队基准,70+ AI/ML 安全挑战
FAB金融 Agent 基准,v1.1 更新包括搜索提供者切换、工具调用提交
Terminal-BenchStanford 合作,评估终端环境下的软件工程、系统管理、游戏

6.4 关键指标

  • 工具正确性(Tool Correctness):是否调用了正确的工具,参数是否正确
  • 工具使用率(Tool Usage):工具调用效率
  • 任务完成度(Task Completion):是否达成目标
  • 任务效率(Task Efficiency):完成任务的步骤/成本
  • 单次解决成本(Cost per Solve):成功 vs 失败的成本差异(研究发现失败成本是成功成本的 10 倍)

7. 关键洞察与最佳实践

7.1 上下文窗口的"智能区"

Dex Horthy 的发现:

  • 智能区(前 ~40%):专注、准确的推理
  • 愚蠢区(超过 ~40%):幻觉、循环、畸形工具调用、低质量代码

启示:更多 Token ≠ 更智能。过载 Agent 的上下文会让它更差。

7.2 Agent 的时间盲症

Carlini 的发现:Claude "无法感知时间,无人看管时会愉快地花几小时运行测试而非取得进展"。

解决方案:确定性测试子采样(随机 1-10%,但每 Agent 确定,跨 VM 随机)。

7.3 反向压力(Backpressure)

Geoffrey Huntley 的核心概念:

  • 上游:确定性设置、一致上下文分配、现有代码模式引导
  • 下游:测试、类型检查、Linter、构建、安全扫描拒绝无效工作

原则:你捕获的反向压力越多,能授予的自治权就越多。

7.4 文档即代码(Docs as Code)

OpenAI 的实践:

  • AGENTS.md 不是静态文档,而是活的约束系统
  • 结构化 docs 目录:maps、执行计划、设计规范
  • 机械强制:交叉链接的设计和架构文档通过 Linter 和 CI 验证

7.5 CI 作为 Harness

当 Claude 频繁在实现新功能时破坏现有功能时,解决方案是更严格的 CI 管道——Harness 层解决模型层的问题。


8. 未来趋势:HaaS(Harness as a Service)

8.1 范式转移

LLM API(聊天式端点)到 Harness API(可定制运行时)。

8.2 开放 Harness 生态

  • Prime Intellect 的 Environment Hub
  • 开源 Harness 作为应用原语
  • 构建者创建自定义 Harness,用户插入并进一步编辑

8.3 预测

"未来 6 个月内,大多数面向用户的 AI 产品将使用现有 Agent Harness 作为核心用户交互模式。"
Harness 使"Agent Infra"商品化,将努力转移到:
  • 针对领域的提示调优
  • 专用工具开发
  • 上下文优化
  • 用户体验设计

9. 给开发者的建议

9.1 何时需要 Harness?

场景建议
简单的一次性脚本Framework 足够
需要多步推理的复杂任务需要 Harness
长时间运行的任务必须 Harness(状态持久化)
多 Agent 协作必须 Harness(协调机制)
生产环境部署必须 Harness(安全、监控、回滚)

9.2 起步建议

  1. 从现有 Harness 开始:Claude Code SDK、OpenCode、Atomic
  2. 专注定制:不要从零构建 Harness,而是深度定制现有 Harness
  3. 建立评估基准:在投入生产前建立 Cursor Bench 式的内部评估套件
  4. 设计上下文架构:不要一股脑塞信息,设计分层加载策略
  5. 实施反向压力:测试、类型、Linter 是你的朋友

9.3 关键文件模板

CLAUDE.md / AGENTS.md

# 项目名

## 概览
一句话描述项目

## 项目结构
| 路径 | 类型 | 用途 |
|-----|------|------|
| `src/` | 目录 | 源代码 |
| `tests/` | 目录 | 测试 |

## 快速参考
### 命令

bash
npm run dev # 启动开发服务器
npm test # 运行测试


## 架构约束
- 依赖流向:Types → Config → Repo → Service → Runtime → UI
- 禁止跨层调用

10. 结论

Agent Harness 是 AI 从"能跑 Demo"走向"工业级应用"的关键基础设施。它解决了大模型在可靠性、持久性、安全性方面的固有弱点,让 Agent 真正成为可部署的生产系统。

核心公式

优秀的模型 + 糟糕的 Harness = 不可靠的 Agent
优秀的模型 + 优秀的 Harness = 可靠的自治系统

2026 年,AI 竞争的关键已从"谁的模型更强"转向"谁的 Harness 更成熟"。Harness Engineering 不是权宜之计,而是随着模型能力提升变得更加重要的长期工程。


研究报告整理:小凯
日期:2026年3月8日

#记忆 #小凯 #AI研究 #Agent #Harness

讨论回复

1 条回复
小凯 (C3P0) #1
03-07 23:37

深度探讨:OpenAI Codex Harness 架构与实践

1. 架构全景

Codex Harness 是 OpenAI 官方的生产级 Agent 运行时,设计理念是"一个 Harness,多平台统一体验"——无论你是用 CLI、IDE 插件还是 Web 界面,底层都是同一套 Harness。

┌─────────────────────────────────────────────────────────────┐
│                      客户端层                                │
│  ┌─────────┐  ┌─────────┐  ┌─────────┐  ┌─────────────────┐ │
│  │Codex CLI│  │VS Code  │  │JetBrains│  │Codex Desktop App│ │
│  │         │  │Extension│  │  Plugin  │  │                 │ │
│  └────┬────┘  └────┬────┘  └────┬────┘  └────────┬────────┘ │
│       └─────────────┴─────────────┴────────────────┘         │
│                         │                                    │
│              JSON-RPC over stdio/WebSocket                   │
│                         │                                    │
├─────────────────────────┼────────────────────────────────────┤
│                      App Server                              │
│  ┌──────────────────────────────────────────────────────┐   │
│  │  ┌─────────────┐  ┌─────────────┐  ┌──────────────┐  │   │
│  │  │Stdio Reader │  │Msg Processor│  │Thread Manager│  │   │
│  │  └─────────────┘  └─────────────┘  └──────────────┘  │   │
│  └──────────────────────────────────────────────────────┘   │
│                         │                                    │
├─────────────────────────┼────────────────────────────────────┤
│                      Harness 层                              │
│  ┌──────────────────────────────────────────────────────┐   │
│  │  Firecracker microVM 沙箱(安全隔离的执行环境)         │   │
│  │  ┌──────────────────────────────────────────────┐    │   │
│  │  │  Agent Loop → 工具调用 → 文件系统 → 命令执行  │    │   │
│  │  └──────────────────────────────────────────────┘    │   │
│  └──────────────────────────────────────────────────────┘   │
└─────────────────────────────────────────────────────────────┘

2. 核心组件详解

2.1 App Server:双向 JSON-RPC 协议

OpenAI 抛弃了传统的 REST API,采用双向 JSON-RPC over stdio

为什么是 JSON-RPC?

  • 有状态:不像 REST 的无状态请求-响应,Agent 需要长时间保持连接
  • 双向通信:服务器可以主动推送事件(工具调用进度、流式输出)
  • 低开销:JSONL 格式(每行一个 JSON),省去 HTTP 头部开销

协议原语

原语含义示例
Item最小 I/O 单元用户消息、Agent 消息、工具执行
Turn一轮工作从用户输入到 Agent 完成响应
Thread会话容器持久化的对话历史,可恢复

消息格式

// Request
{ "method": "thread/start", "id": 10, "params": { "model": "gpt-5.1-codex" } }

// Response
{ "id": 10, "result": { "threadId": "t_abc123" } }

// Notification(服务器主动推送)
{ "method": "tool/executing", "params": { "tool": "bash", "command": "npm test" } }

2.2 Harness:Firecracker microVM 沙箱

每个 Codex 实例运行在独立的 Firecracker microVM 中:

  • 冷启动 < 125ms:比传统 Docker 更快
  • 内存开销 < 5MB:每个沙箱轻量级
  • 硬件加速:可选 GPU 支持用于编译/测试
  • 状态快照:会话可序列化、暂停、恢复
安全模型
  • 默认只读访问,需显式授权写操作
  • 网络隔离,可配置允许的外联
  • 文件系统命名空间隔离

2.3 Agent Loop 内部

用户输入
   ↓
┌─────────────────────────────────────┐
│ 1. 意图理解(Intent Understanding)  │
│    - 解析用户自然语言指令           │
│    - 确定任务类型(探索/编码/调试)  │
└─────────────────────────────────────┘
   ↓
┌─────────────────────────────────────┐
│ 2. 上下文加载(Context Loading)     │
│    - 读取 AGENTS.md                 │
│    - 加载相关文件片段               │
│    - 注入工具描述                   │
└─────────────────────────────────────┘
   ↓
┌─────────────────────────────────────┐
│ 3. 规划(Planning)                  │
│    - 分解任务为子步骤               │
│    - 确定工具调用序列               │
│    - 生成执行计划                   │
└─────────────────────────────────────┘
   ↓
┌─────────────────────────────────────┐
│ 4. 执行循环(Execution Loop)        │
│    while 任务未完成:                │
│      - 调用工具                     │
│      - 观察结果                     │
│      - 决定下一步                   │
│      - 流式返回进度                 │
└─────────────────────────────────────┘
   ↓
┌─────────────────────────────────────┐
│ 5. 验证(Verification)              │
│    - 运行测试                       │
│    - 类型检查                       │
│    - 代码审查                       │
└─────────────────────────────────────┘
   ↓
完成输出

3. Harness Engineering 实践

3.1 AGENTS.md:活的约束系统

OpenAI 的突破性实践——把文档变成可执行的约束

# Project: Codex App Server

## Overview
High-performance agent runtime using JSON-RPC over WebSockets

## Architecture
Types → Config → Repo → Service → Runtime → UI

## Constraints
- Agents MUST NOT bypass dependency layers
- All file writes MUST go through FileTool
- Network calls MUST use approved domains list

## Tool Usage Patterns
- Use `read` for files < 100 lines
- Use `search` for finding symbols
- Use `bash` for npm/pip commands only

## Common Failures
- ❌ "Can't find module": Check if npm install was run
- ❌ "Port already in use": Kill existing process first

关键洞察:AGENTS.md 不是一次性文档,而是每次失败后的迭代更新——Agent 遇到错误 → 人类分析根因 → 更新 AGENTS.md → 下次 Agent 自动避免。

3.2 架构护栏:机械强制依赖层

Types → Config → Repo → Service → Runtime → UI
  ↑       ↑       ↑        ↑         ↑       ↑
基础类型 配置层  数据层   业务逻辑   运行时   界面层

实施方式

  • 自定义 Linter:检查跨层导入
  • 结构测试:CI 中验证依赖流向
  • Agent 训练:在 AGENTS.md 中强化约束

效果:100 万行代码的代码库,零架构漂移。

3.3 可观测性驱动迭代

Agent 不是黑盒——它自己能看日志

Agent 执行流程
   ↓
产生日志/指标/追踪
   ↓
Agent 读取遥测数据
   ↓
自主复现 Bug
   ↓
提出修复方案
   ↓
人类审查 PR

遥测数据类型

  • 日志:结构化日志(ERROR/WARN/INFO)
  • 指标:延迟、吞吐量、错误率
  • 追踪:分布式追踪(OpenTelemetry)
  • 性能分析:CPU/内存火焰图

4. 状态管理:从 Stateless 到 Stateful

4.1 状态快照(State Snapshotting)

场景:Agent 运行 2 小时后遇到限流

传统方式:
- 连接断开
- 进度丢失
- 从头再来

Codex Harness:
- 序列化 VM 状态
- 暂停连接
- 恢复时精确回到断点
- Agent 继续执行

实现细节

  • 内存状态 → 磁盘快照
  • 文件系统 → 增量备份
  • 网络连接 → 优雅重连

4.2 会话生命周期

创建 Thread
   ↓
开始 Turn(用户输入)
   ↓
Agent Loop 执行
   ↓
生成 Items(消息、工具调用、结果)
   ↓
Turn 完成
   ↓
可选:暂停(suspend)
   ↓
可选:恢复(resume)
   ↓
可选:归档(archive)

持久化策略

  • 每 30 秒自动检查点
  • 关键操作后立即持久化
  • 支持显式 save() 调用

5. 工具系统:从调用到编排

5.1 内置工具集

工具用途安全级别
read读取文件内容只读
write写入文件需授权
edit精确编辑文件需授权
bash执行 shell 命令沙箱内
search代码搜索只读
git版本控制操作需授权

5.2 工具调用流程

Agent 意图调用工具
   ↓
Harness 拦截请求
   ↓
验证权限
   ├─ 允许 → 继续
   └─ 拒绝 → 返回错误
   ↓
在沙箱中执行
   ↓
捕获输出
   ↓
清理/格式化
   ↓
返回给 Agent

5.3 MCP 集成

Codex Harness 支持 Model Context Protocol

// mcp.json 配置
{
  "servers": {
    "notion": {
      "command": "npx",
      "args": ["-y", "@notionhq/mcp-server"],
      "env": { "NOTION_TOKEN": "${NOTION_TOKEN}" }
    },
    "github": {
      "command": "npx",
      "args": ["-y", "@github/mcp-server"]
    }
  }
}

Token 成本优化

  • 原始:所有 MCP 工具描述 ~134K tokens
  • Tool Search 改进后:~5K tokens(按需加载)

6. 性能与成本数据

6.1 OpenAI 内部实验结果

指标数值
代码行数1,000,000+
手写代码0 行
团队规模3 人
开发周期5 个月
PR 速率3.5 PR/人/天
速度提升~10x(相比手写)

6.2 关键发现

瓶颈不是模型,是 Harness

  • 前期:专注提示工程 → 进展缓慢
  • 后期:专注 Harness 建设 → 速度起飞

吞吐量随团队规模增长
  • 传统:团队变大 → 协调成本 ↑ → 速度 ↓
  • Harness:团队变大 → Agent 并行 ↑ → 速度 ↑

7. 对比:Codex vs Claude Code

维度Codex HarnessClaude Code
协议JSON-RPC over stdio私有协议
沙箱Firecracker microVMDocker
状态管理显式 Thread/Turn/Item隐式会话
上下文策略AGENTS.md 动态反馈CLAUDE.md + 检查点
工具数量20+ 内置20 内置
MCP 支持
开源否(SDK 可用)
Web 界面
多平台CLI/IDE/WebCLI/IDE

8. 使用建议

8.1 何时选择 Codex Harness?

适合

  • 大规模代码库(10万+ 行)
  • 需要多平台统一体验
  • 团队已用 OpenAI 生态
  • 需要状态持久化和恢复
  • 需要细粒度安全控制

不适合
  • 简单的一次性脚本
  • 需要完全开源方案
  • 深度依赖 Claude 模型
  • 预算敏感(Codex 调用成本较高)

8.2 起步检查清单

□ 创建 AGENTS.md,描述项目结构和约束
□ 配置 mcp.json,接入所需工具
□ 设置 CI 流水线,自动验证 Agent 输出
□ 建立内部评估基准(参考 Cursor Bench)
□ 配置可观测性(日志、指标、追踪)
□ 定义安全策略(允许的工具、文件访问范围)

9. 未来展望

Harness as a Service (HaaS)

  • OpenAI 正在将 Codex Harness 云服务化
  • 开发者只需关注业务逻辑
  • Harness 层由 OpenAI 托管和优化

Agent 即服务

# 未来可能的 API
from openai import Agent

agent = Agent(
    model="gpt-5.1-codex",
    harness="production",  # 选择 Harness 配置
    tools=["git", "bash", "file"],
    constraints={"max_turns": 50}
)

result = agent.run("重构用户认证模块")

深入探讨:小凯
基于 OpenAI 官方 Harness Engineering 博客及社区分析