介绍

过去我们使用 AI 编程工具，通常是把它当作一个代码生成器：输入 Prompt，得到代码，然后由程序员复制、修改、运行和调试。

Claude Code、OpenAI Codex 等新一代智能体编程工具已经不再局限于“生成一段代码”。它们可以进入真实项目，读取仓库上下文，搜索源代码，调用 Shell 和外部工具，修改文件，运行测试，根据失败结果继续修复，并最终交付可以审查的代码变更。

这种变化背后有两个关键概念：

Agent Loop：让 Agent 能够持续规划、执行、观察和调整；
Agent Harness：为 Agent Loop 提供上下文、工具、权限、状态、验证和反馈环境。

Claude Code 和 Codex 正是这类 Coding Agent / Agent Harness 的代表性工具。

需要先说明一个术语问题：日常讨论中经常会使用“Harness Agent”和“Loop Agent”来帮助区分职责，但从系统架构上看，更准确的表达是：

Agent Loop 是执行机制，Agent Harness 是承载这个循环的运行环境。Claude Code 和 Codex 通常同时包含两者，而不是先运行一个 Harness Agent，再调用另一个独立的 Loop Agent。

本文先介绍 Agent Harness 和 Agent Loop 的基础关系，再分别介绍 Claude Code 与 Codex 在项目开发中如何配置和使用。

一、从传统 AI 到智能体工具

1. 传统 AI 更像“回答问题的工具”

传统对话式 AI 的主要交互方式是：

它可以解释技术、生成函数或给出修改建议，但通常仍然依赖程序员完成后续动作：

找到应该修改的文件；
判断代码是否符合现有架构；
把代码复制到项目中；
运行测试和启动服务；
把报错重新交给模型；
决定何时提交代码。

此时的 AI 主要负责“给答案”，人负责“完成任务”。

2. Agent 更像“完成任务的伙伴”

Agent 的目标不是只返回一段文本，而是在授权范围内完成一组连续动作。

例如用户提出：

为测试平台增加 AI 测试用例生成功能，并补充后端测试。

Agent 需要完成的工作可能包括：

这意味着 Agent 必须具备四类能力：

理解：知道任务、项目和约束是什么；
行动：能够读取文件、执行命令和访问外部系统；
反馈：能够观察测试、日志、浏览器和 Git 状态；
持续执行：能够根据反馈进入下一轮，而不是一次回答后结束。

二、Agent Loop：让智能体持续完成任务

1. Agent Loop 的基本结构

Agent Loop 是 Agent 的核心执行机制，可以概括为：

Plan → Act → Observe → Reflect → Repeat

展开以后是：

各阶段的职责如下：

阶段	主要问题	编程任务中的典型动作
Goal	最终要完成什么？	增加一个功能、修复一个 Bug、完成一次重构
Plan	应该分几步完成？	找入口、读测试、确定修改范围、安排验证
Act	现在执行什么动作？	读写文件、运行命令、调用 MCP、委派子任务
Observe	动作产生了什么结果？	读取命令输出、错误堆栈、页面截图、Git Diff
Reflect	下一步应该怎样调整？	修复错误、修改方案、补充上下文、重新测试
Done	是否满足验收标准？	测试通过、构建成功、结果可审查

OpenAI 在 Codex agent loop 的技术拆解中描述了同样的过程：模型可以返回最终消息，也可以请求工具调用；Harness 执行工具，把结果加入上下文，再让模型继续推理，直到模型停止请求工具并返回结果。

因此，一次用户请求并不一定只对应一次模型调用，而可能包含多轮：

2. Loop Agent 不能脱离环境独立工作

只有循环，没有良好的运行环境，Agent 仍然很难完成真实项目。

它可能不知道：

应该先读哪个文件；
项目使用 npm、pnpm 还是其他工具；
哪些目录不能修改；
哪些操作需要用户确认；
测试命令是什么；
什么结果才算完成；
失败后如何恢复。

所以 Agent Loop 解决的是“如何持续执行”，但不负责提供完整的项目环境。这个环境由 Agent Harness 提供。

三、Agent Harness：为 Agent Loop 构建工作环境

1. 什么是 Agent Harness？

Agent Harness 可以理解为围绕模型和 Agent Loop 构建的一整套工程运行环境。

可以用一句话概括两者关系：

Loop 是 Agent 的心跳，Harness 是 Agent 的工作环境。

2. Harness 管理哪些内容？

Context：项目上下文

让 Agent 知道：

项目是什么；
目录结构是什么；
当前任务是什么；
架构如何设计；
应该遵守哪些约定；
当前代码和 Git 状态是什么。

常见载体包括：

CLAUDE.md / AGENTS.md；
README.md / ARCHITECTURE.md；
项目文档和源代码；
Git 历史；
当前任务描述。

Rules：项目规则

告诉 Agent 什么应该做、什么不能做：

使用什么技术栈；
遵循什么编码规范；
修改后运行什么测试；
哪些接口必须保持兼容；
哪些目录不能修改；
哪些操作需要人工确认。

Tools：本地执行能力

常见工具包括：

读取和修改文件；
Shell / Terminal；
代码搜索；
Git；
测试与构建工具；
浏览器；
日志查看器。

MCP：连接外部世界

MCP 让 Agent 可以连接外部服务，例如：

外部系统	Agent 可使用的能力
GitHub	Issue、PR、Actions
Linear	任务管理
PostgreSQL	数据查询
Playwright	浏览器自动化
Sentry	错误监控
Slack	消息通知
企业 API	内部业务系统

Skills：封装专业工作方法

Skill 告诉 Agent 某类任务应该怎样完成，例如：

代码审查；
前端设计与 React 开发；
数据库迁移；
测试用例设计；
故障排查；
发布流程。

Permissions、Hooks 与 Sandbox：限制和控制行为

它们负责：

限制文件读写范围；
限制命令和网络访问；
在危险操作前请求审批；
在工具调用前后执行检查；
在任务完成前自动运行验证。

Git 与 Tests：保存状态并验证结果

Git 提供版本状态和恢复能力，Tests 提供事实反馈。

3. Model、Harness、Loop、MCP 和 Skill 的区别

概念	核心作用	可以类比为
Model	理解、推理和生成	大脑
Agent Loop	持续规划、执行、观察和调整	心跳 / 执行循环
Agent Harness	管理上下文、工具、权限、状态和验证	工作环境 / 操作系统
Tools	执行具体动作	手和脚
MCP	标准化连接外部工具与数据	外部接口
Skills	提供可复用的专业工作流	工作手册
Tests / Evals	判断结果是否真的正确	验收机制

最容易混淆的是 MCP 和 Skill：

例如实现登录功能时：

Skill 提供方法，MCP 提供能力，Harness 将它们组织进 Agent Loop。

四、Claude Code：面向项目开发的 Agent Harness

1. Claude Code 是什么？

Claude Code 是面向软件开发的 Coding Agent。它将 Claude 模型与项目上下文、文件和 Shell 工具、权限、MCP、Skills、Hooks、Subagents 以及 Git/Test 反馈组合在一起。

因此，Claude Code 不应只被理解为：

一个可以在终端中生成代码的 Claude。

更准确的理解是：

Claude Code 的价值在于：它可以在真实仓库中持续执行开发任务，而不是只给出代码片段。

2. Claude Code 的项目配置结构

一个典型项目可以这样组织：

project/
├─ CLAUDE.md                    # 项目上下文与长期规则
├─ .mcp.json                    # 项目级 MCP Server 配置
├─ .claude/
│  ├─ settings.json             # 团队共享配置、权限和 Hooks
│  ├─ settings.local.json       # 本机配置，通常不提交
│  ├─ rules/                    # 路径级或技术栈规则
│  ├─ skills/                   # 可复用工作流
│  │  └─ <skill-name>/
│  │     ├─ SKILL.md
│  │     ├─ references/
│  │     └─ scripts/
│  └─ agents/                   # 自定义 Subagent
├─ src/
├─ tests/
├─ docs/
└─ .git/

这些文件的职责不同：

配置	主要职责	适合存放的内容
`CLAUDE.md`	项目长期上下文	项目目标、架构入口、构建命令、编码约定
`.claude/rules/`	更细粒度规则	前端、后端、数据库、测试或目录级规范
`.claude/skills/`	可复用专业流程	代码审查、测试、发布、数据库迁移
`.claude/agents/`	专项子智能体	code-reviewer、test-engineer、frontend-reviewer
`.mcp.json`	项目外部工具	GitHub、Linear、Playwright、数据库
`settings.json`	行为控制	权限、Hooks、工具策略和项目设置
Git + Tests	状态和验证	Diff、历史、测试结果和反馈闭环

3. CLAUDE.md：让 Claude Code 认识项目

CLAUDE.md 不是某一次对话中的普通 Prompt，而是项目级的持久上下文入口。

一个简化示例：

# AI Test Platform

## Project Structure

- frontend/：React + TypeScript 前端
- backend/：Python 后端
- tests/：自动化测试
- docs/：架构与产品文档

## Development Commands

- 前端测试：pnpm test
- 前端检查：pnpm lint
- 后端测试：pytest

## Working Agreements

- 修改前先读取相关实现和测试
- 优先复用现有组件
- 所有 API 变更必须补充测试
- 不直接修改已经发布的数据库迁移
- 未运行验证时不能声称任务完成

CLAUDE.md 最适合充当项目地图，而不是把所有知识都堆在一个文件中。

详细的架构文档仍然放在 docs/ 中，再由 CLAUDE.md 告诉 Claude Code应该去哪里读取。

4. Rules：把长期规则拆分到正确的范围

当项目变大以后，可以将规则拆分到 .claude/rules/：

.claude/rules/
├─ frontend.md
├─ backend.md
├─ database.md
└─ testing.md

例如：

# Frontend Rules

- 使用 TypeScript
- 优先复用现有组件
- UI 组件遵循项目设计系统
- 新页面必须考虑响应式布局和可访问性
- 修改完成后运行 lint、typecheck 和相关测试

拆分规则有两个好处：

避免 CLAUDE.md 无限膨胀；
让某类规则只在相关路径和任务中生效。

5. Skills：把重复开发过程变成专业工作流

Claude Code Skill 通常放在：

.claude/skills/<skill-name>/SKILL.md

一个 Skill 目录可以包含：

frontend-design/
├─ SKILL.md
├─ references/
│  └─ design-system.md
└─ scripts/
   └─ check-ui.sh

例如 frontend-design Skill 可以规定：

适合沉淀为 Skill 的内容通常具有两个特点：

会在多个任务中重复使用；
不应该在每次对话中重新解释。

例如：

frontend-design；
react-best-practices；
code-review；
testing；
database-migration；
release-checklist。

6. MCP：让 Claude Code 使用外部系统

Claude Code 可以通过 MCP 连接项目外部的工具和数据：

例如，一个完整的开发任务可能同时使用：

MCP Server	在开发任务中的作用
GitHub	读取 Issue、检查 PR、创建或更新 PR
PostgreSQL	查看数据库结构和查询数据
Playwright	启动浏览器并验证页面
Sentry	读取线上错误和事件信息

但 MCP 不是 Prompt，也不是 Skill。MCP Server 提供的是可调用能力，具体应该按照什么步骤调用，仍然需要项目规则或 Skill 指导。

7. Hooks、Permissions 与 Subagent

Hooks

Hooks 适合执行确定性动作，例如：

修改文件后运行格式检查；
工具调用前检查危险命令；
任务结束时运行测试；
记录操作日志；
发送完成通知。

如果一项检查“必须执行”，就不应该只依赖模型是否记得，更适合由 Hook 或 CI 强制完成。

Permissions

Permissions 决定 Claude Code：

可以读取哪些文件；
可以修改哪些目录；
可以执行哪些命令；
哪些动作必须询问用户；
哪些动作应该直接拒绝。

需要特别保护：

.env 和密钥文件；
生产数据库；
删除操作；
远程 Git Push；
发布和部署命令。

Subagent

Subagent 适合处理独立或上下文较大的专项任务，例如：

Subagent 的主要价值是隔离上下文。大量搜索结果、日志和测试输出可以留在子任务中，主 Agent 只接收结论和必要证据。

8. 使用 Claude Code 完成一次真实开发任务

启动项目中的 Claude Code 后，不建议一开始就说：

帮我写一个页面。

更好的任务输入应该包含目标、范围、约束和验收标准：

任务：为测试平台增加测试用例列表页。

范围：
- frontend/src/pages/test-cases/
- frontend/src/components/
- 相关测试文件

约束：
- 先读取 CLAUDE.md 和前端 Rules
- 优先复用已有组件
- 不修改后端 API

验收标准：
- 支持分页、状态筛选和关键字搜索
- 页面具有加载、空数据和错误状态
- lint、typecheck 和相关测试通过

执行方式：
先探索项目并给出计划，确认修改范围后再实施。

一次完整的 Claude Code Harness Loop 可以概括为：

真正的开发闭环不是：

Prompt → 生成代码 → 结束

而是：

五、OpenAI Codex：共享 Harness 驱动的代码 Agent

1. Codex 是什么？

Codex 是 OpenAI 面向软件开发的 Coding Agent。它可以从不同产品入口接收任务，例如 CLI、IDE、桌面应用或云端任务，但这些入口背后的核心仍然是 Agent Loop 和执行环境。

可以将 Codex 理解为：

Codex Harness 负责把下面的过程组织起来：

2. Codex 的项目配置结构

按照当前官方文档，一个项目可以这样组织：

project/
├─ AGENTS.md                    # 仓库级长期规则和项目入口
├─ .codex/
│  ├─ config.toml               # 项目级配置，需要信任该项目
│  ├─ hooks.json                # 可选：项目级生命周期 Hooks
│  └─ agents/                   # 可选：项目级自定义 Agent
│     ├─ reviewer.toml
│     └─ test-engineer.toml
├─ .agents/
│  └─ skills/                   # 仓库级 Skills
│     ├─ frontend-design/
│     │  └─ SKILL.md
│     ├─ testing/
│     │  └─ SKILL.md
│     └─ database-design/
│        └─ SKILL.md
├─ frontend/
├─ backend/
├─ tests/
├─ docs/
└─ .git/

用户级配置通常位于：

~/.codex/
├─ config.toml
├─ hooks.json
├─ agents/
└─ AGENTS.md

项目 .codex/config.toml 只会在项目被信任后加载。这样可以避免打开一个陌生仓库时，自动执行其中的高权限配置或 Hook。

3. AGENTS.md：Codex 的项目指令入口

Codex 在开始工作前会发现并读取 AGENTS.md。

它支持分层规则：

离当前工作目录越近的规则越具体，可以覆盖上层约定。

一个项目级示例：

# AI Test Platform

## Project Structure

- frontend/：React + TypeScript
- backend/：Python API
- tests/：自动化测试
- docs/：架构与产品文档

## Development Rules

- 修改前先搜索现有实现
- 优先复用已有模块
- 所有 API 变更必须更新测试
- 不直接修改已经发布的 migration
- 不在未经授权时执行 git push 或部署

## Verification

修改前端后运行：
- pnpm lint
- pnpm typecheck
- pnpm test

修改后端后运行：
- pytest

## Completion

最终结果必须包含：
- 修改文件列表
- 测试和验证结果
- 未完成事项或剩余风险

AGENTS.md 最适合存放稳定、长期、每次任务都应该知道的信息。复杂操作流程更适合写成 Skill，详细设计文档更适合放在 docs/ 中。

4. config.toml：配置 Codex 的运行环境

Codex 的个人默认配置位于：

~/.codex/config.toml

项目级配置可以位于：

project/.codex/config.toml

它可以用于管理：

默认模型和推理强度；
Sandbox；
Approval Policy；
MCP Server；
Hooks；
功能开关；
Subagent 默认值；
Shell 环境变量策略。

一个只表达结构的简化示例：

# project/.codex/config.toml

approval_policy = "on-request"
sandbox_mode = "workspace-write"

[mcp_servers.github]
command = "your-github-mcp-command"
args = []

[mcp_servers.playwright]
command = "your-playwright-mcp-command"
args = []

[agents]
enabled = true

示例中的 MCP 命令需要根据实际 Server 和认证方式配置，不应直接把 Token 写入仓库。

5. Codex Skills：为任务提供专业流程

Codex 的仓库级 Skill 可以放在：

.agents/skills/<skill-name>/SKILL.md

例如：

.agents/skills/
├─ frontend-design/
│  ├─ SKILL.md
│  └─ references/
├─ react-best-practices/
│  └─ SKILL.md
├─ testing/
│  ├─ SKILL.md
│  └─ scripts/
└─ database-design/
   └─ SKILL.md

Codex 会先看到 Skill 的名称和描述，在任务相关时再加载完整的 SKILL.md。这种渐进加载方式可以减少无关内容占用主上下文。

一个简化 Skill：

---
name: testing
description: 为新增功能设计、执行和检查单元测试、集成测试与端到端测试。
---

1. 先读取现有测试结构和项目测试规则。
2. 根据风险选择单元、集成或端到端测试。
3. 优先复用现有 Fixture 和测试工具。
4. 运行最相关的小范围测试，再运行完整验证。
5. 记录失败原因、修复内容和最终结果。

Skill 不是工具本身。它可以指导 Codex 使用 Shell、浏览器或 MCP，但实际能力仍然由这些工具提供。

6. Codex MCP：连接外部工具与上下文

Codex 的 MCP Server 通常配置在 config.toml 中。

Codex CLI、IDE 和同一 Host 上的桌面体验可以共享 MCP 配置，但云端或其他运行环境是否可以使用同一个 Server，仍然取决于它是否能访问对应网络、进程和凭据。

MCP 使用时要重点检查：

Server 是本地 STDIO 还是远程 HTTP；
凭据从哪里读取；
哪些工具可以自动执行；
哪些写操作需要审批；
MCP 输出是否可能包含不可信内容。

7. Sandbox、Approvals 与 Hooks

Sandbox

Sandbox 控制 Codex 运行命令时可以访问的文件系统和网络范围。

典型思路是：

沙箱的目标不是阻止 Agent 工作，而是限制失败时的影响范围。

Approvals

Approvals 决定 Codex 在什么情况下暂停并询问用户。

例如：

写入工作区外目录；
访问受限制网络；
执行高风险命令；
使用需要额外权限的工具；
进行不可逆外部操作。

Hooks

Codex 可以从 hooks.json 或 config.toml 中的 [hooks] 配置加载生命周期 Hook。

Hooks 适合：

执行格式化和静态检查；
记录工具调用；
检查敏感操作；
在任务阶段变化时发送通知；
把组织策略变成确定性流程。

8. Subagents 与 Worktrees

Codex 可以把独立任务交给 Subagent，例如：

项目级自定义 Agent 可以放在：

.codex/agents/<agent-name>.toml

并行 Agent 更适合：

代码探索；
测试分析；
日志排查；
多维度代码 Review；
相互独立的模块任务。

对于多个会写代码的任务，应使用 Worktree 或其他方式隔离工作区，避免多个 Agent 同时修改同一文件。

9. 使用 Codex 完成一次真实开发任务

一个适合 Codex 的任务输入可以写成：

请先读取 AGENTS.md，并按照其中的导航查看相关文档。

任务：为测试平台新增 AI 测试用例生成接口。

范围：
- backend/app/api/
- backend/app/services/
- tests/api/

要求：
- 先探索现有 API 和测试结构
- 输出实现计划后再修改
- 优先复用已有模型和错误处理
- 不修改数据库结构

验收标准：
- 新接口测试通过
- 原有 API 测试不回归
- 输出 git diff 摘要
- 无法完成的验证必须明确说明原因

Codex 的完整开发 Loop 可以概括为：

这正是 Codex Harness 的核心价值：把模型推理、项目上下文、工具调用、权限控制和验证反馈组织成持续运行的工程过程。

六、Claude Code 与 Codex 的关键差异

Claude Code 和 Codex 都属于 Coding Agent / Agent Harness，但它们的配置载体和产品入口并不完全相同。

能力	Claude Code	OpenAI Codex
项目长期规则	`CLAUDE.md`	`AGENTS.md`，支持目录级分层覆盖
项目配置	`.claude/settings.json` 等	`.codex/config.toml`，可信项目中加载
仓库级 Skills	`.claude/skills/`	`.agents/skills/`
MCP 配置	常见项目配置为 `.mcp.json`	`~/.codex/config.toml` 或项目 `.codex/config.toml`
Hooks	Claude Code 生命周期 Hooks	`hooks.json` 或 `config.toml` 中的 `[hooks]`
子智能体	`.claude/agents/`、Subagents / Agent Teams	内置或 `.codex/agents/` 自定义 Subagents
权限控制	Permissions + Hooks	Sandbox + Approval Policy + Permissions + Hooks
状态与并行	会话、Subagents、团队协作能力	Threads / Tasks、Subagents、Worktrees
主要使用方式	以终端和项目工作流为核心	CLI、IDE、桌面与云端任务等多种入口

它们的共同点比差异更重要：

选择工具时，不应只比较一次代码生成效果，更应该比较：

是否适合团队当前的开发入口；
项目规则是否容易维护；
Skills 和 MCP 是否能复用现有工作流；
权限和审批是否符合安全要求；
长任务是否容易恢复、并行和审查；
测试、浏览器、日志和 CI 是否能进入反馈闭环。

七、在同一个项目中使用 Claude Code 和 Codex

如果一个项目需要同时支持 Claude Code 和 Codex，可以让两者读取同一套工程事实，但使用各自的入口配置。

AI-Test-Platform/
├─ CLAUDE.md                    # Claude Code 项目入口
├─ AGENTS.md                    # Codex 项目入口
├─ .mcp.json                    # Claude Code MCP 配置
├─ .claude/
│  ├─ settings.json
│  ├─ rules/
│  ├─ skills/
│  └─ agents/
├─ .codex/
│  ├─ config.toml
│  ├─ hooks.json
│  └─ agents/
├─ .agents/
│  └─ skills/                   # Codex 仓库级 Skills
├─ docs/                        # 两种工具共享的事实来源
│  ├─ architecture.md
│  ├─ development.md
│  ├─ testing.md
│  └─ security.md
├─ frontend/
├─ backend/
├─ tests/
└─ .git/

为了避免维护两套相互矛盾的规则，可以采用下面的方式：

1. 把事实放到共享文档

共享文档	内容
`docs/architecture.md`	架构和模块边界
`docs/development.md`	开发和构建流程
`docs/testing.md`	测试策略
`docs/security.md`	安全约束

2. 让入口文件只负责导航

CLAUDE.md 和 AGENTS.md 都引用相同的 docs/ 文档，同时只保留各自工具需要的少量使用规则。

3. 将重复流程沉淀为 Skills

例如：

frontend-design；
backend-development；
database-design；
testing；
code-review；
agent-evaluation。

如果需要同时支持两种 Skill 目录，可以维护一套共享源文件，再通过构建、同步或链接方式生成对应目录，但不要让两份内容长期手工漂移。

4. 让测试成为统一验收标准

无论使用 Claude Code 还是 Codex，都应该执行相同的项目验证：

前端：lint + typecheck + unit test + E2E；
后端：lint + typecheck + pytest；
项目：build + security check + Git Diff review。

工具可以不同，但“完成”的定义必须一致。

八、Harness Agent 工具的正确使用方式

1. 不要只给一句模糊指令

不推荐：

帮我实现登录功能。

2. 先让 Agent 建立项目理解

复杂任务开始前，让 Agent 先回答：

相关模块在哪里？
现有实现是什么？
需要修改哪些文件？
有哪些潜在风险？
准备运行哪些验证？

3. 把规则写入 Harness，而不是每次重复提示

需要沉淀的内容	放置位置
长期项目规则	`CLAUDE.md` / `AGENTS.md`
路径或技术栈规则	Rules / 分层 `AGENTS.md`
重复工作流	Skills
外部工具	MCP
必须执行的检查	Hooks / CI
高风险操作	Permissions / Sandbox / Approvals

4. 用外部反馈判断是否完成

完成任务必须有证据：

测试结果；
构建结果；
浏览器截图；
日志和指标；
Git Diff；
代码 Review。

不能只因为 Agent 回复“已经完成”，就认为任务真正结束。

5. 让人负责目标和边界，让 Agent 负责执行

在 Harness Engineering 的工作方式中，人和 Agent 的职责逐渐变成：

这不是把软件工程完全交给 Agent，而是把 Agent 放进一个可控制、可验证、可恢复的工程环境中。

九、总结

Claude Code 和 Codex 的意义，不只是让模型能够生成更多代码，而是把模型放进一个真实的软件工程执行环境。

这个环境中包含：

Context 与 Rules；
Skills、Tools 与 MCP；
Permissions、Sandbox 与 Hooks；
Subagents 与任务状态；
Git、Tests 与 Feedback。

Agent Loop 负责持续运行：

Plan → Act → Observe → Reflect → Repeat

Agent Harness 负责让这个循环能够安全、稳定地发生：

知道项目是什么；
知道应该遵守什么规则；
拥有完成任务需要的工具；
只能在允许的边界中行动；
可以读取真实执行结果；
能够根据失败继续修复；
最终通过测试和审查证明完成。

因此，更准确的理解不是：

1 2	Claude Code / Codex = 更强的代码生成器

而是：

这也是 Harness Engineering 的核心思想：

不要只思考如何让模型生成代码，而要设计一个让 Agent 能够理解项目、执行任务、验证结果并持续改进的工程环境。

介绍

一、从传统 AI 到智能体工具

1. 传统 AI 更像“回答问题的工具”

2. Agent 更像“完成任务的伙伴”

二、Agent Loop：让智能体持续完成任务

1. Agent Loop 的基本结构

2. Loop Agent 不能脱离环境独立工作

三、Agent Harness：为 Agent Loop 构建工作环境

1. 什么是 Agent Harness？

2. Harness 管理哪些内容？

Context：项目上下文

Rules：项目规则

Tools：本地执行能力

MCP：连接外部世界

Skills：封装专业工作方法

Permissions、Hooks 与 Sandbox：限制和控制行为

Git 与 Tests：保存状态并验证结果

3. Model、Harness、Loop、MCP 和 Skill 的区别

四、Claude Code：面向项目开发的 Agent Harness

1. Claude Code 是什么？

2. Claude Code 的项目配置结构

3. CLAUDE.md：让 Claude Code 认识项目

4. Rules：把长期规则拆分到正确的范围

5. Skills：把重复开发过程变成专业工作流

6. MCP：让 Claude Code 使用外部系统

7. Hooks、Permissions 与 Subagent

Hooks

Permissions

Subagent

8. 使用 Claude Code 完成一次真实开发任务

五、OpenAI Codex：共享 Harness 驱动的代码 Agent

1. Codex 是什么？

2. Codex 的项目配置结构

3. AGENTS.md：Codex 的项目指令入口

4. config.toml：配置 Codex 的运行环境

5. Codex Skills：为任务提供专业流程

6. Codex MCP：连接外部工具与上下文

7. Sandbox、Approvals 与 Hooks

Sandbox

Approvals

Hooks

8. Subagents 与 Worktrees

9. 使用 Codex 完成一次真实开发任务

六、Claude Code 与 Codex 的关键差异

七、在同一个项目中使用 Claude Code 和 Codex

1. 把事实放到共享文档

2. 让入口文件只负责导航

3. 将重复流程沉淀为 Skills

4. 让测试成为统一验收标准

八、Harness Agent 工具的正确使用方式

1. 不要只给一句模糊指令

2. 先让 Agent 建立项目理解

3. 把规则写入 Harness，而不是每次重复提示

4. 用外部反馈判断是否完成

5. 让人负责目标和边界，让 Agent 负责执行

九、总结

参考资料