Agent Harness 深度研究报告

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

目录
  1. Agent Harness 深度研究报告
  2. 1. 核心定义:什么是 Agent Harness?
  3. 类比理解
  4. 关键区分:Framework vs Runtime vs Harness
  5. 2. 为什么需要 Agent Harness?
  6. 生产环境的现实挑战
  7. 行业共识:瓶颈在基础设施,不在模型
  8. 3. Agent Harness 的核心组件
  9. 3.1 上下文工程(Context Engineering)
  10. 3.2 工具编排与护栏(Tool Orchestration & Guardrails)
  11. 3.3 人机协作(Human-in-the-Loop)
  12. 3.4 状态持久化
  13. 4. Harness Engineering 的四大支柱
  14. 支柱 1:上下文架构(Context Architecture)
  15. 支柱 2:Agent 专业化(Agent Specialization)
  16. 支柱 3:持久内存(Persistent Memory)
  17. 支柱 4:结构化执行(Structured Execution)
  18. 5. 主流 Agent Harness 实现
  19. 5.1 Claude Code SDK(Anthropic)
  20. 5.2 Codex Harness(OpenAI)
  21. 5.3 OpenCode
  22. 5.4 Atomic
  23. 6. Agent Harness 评估基准
  24. 6.1 为什么需要评估 Harness?
  25. 6.2 六类测试
  26. 6.3 主要评估框架
  27. 6.4 关键指标
  28. 7. 关键洞察与最佳实践
  29. 7.1 上下文窗口的"智能区"
  30. 7.2 Agent 的时间盲症
  31. 7.3 反向压力(Backpressure)
  32. 7.4 文档即代码(Docs as Code)
  33. 7.5 CI 作为 Harness
  34. 8. 未来趋势:HaaS(Harness as a Service)
  35. 8.1 范式转移
  36. 8.2 开放 Harness 生态
  37. 8.3 预测
  38. 9. 给开发者的建议
  39. 9.1 何时需要 Harness?
  40. 9.2 起步建议
  41. 9.3 关键文件模板
  42. 10. 结论

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.txt、IMPLEMENTATION_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

想参与讨论或点赞?登录后使用完整功能

讨论回复(1)

小

深度探讨: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 博客及社区分析*

👍 1
合作

智谱 GLM-5 已上线

在智谱开放平台 BigModel.cn 打造 AI 应用。新一代旗舰模型 GLM-5 在推理、代码、智能体综合能力达到开源模型 SOTA。

领取 2000万 Tokens