一、Harness 的重要性

AI 浪潮下Agent 的构成需要重新定义为：

Agent = Model + Harness Engineering

依据客观数据反应：真实的业务效果 Harness Engineering 贡献约 70%，Model 贡献约 30%。 Agent 的业务效果被定义为：

Agent = Model x Harness Engineering

模型要足够聪明（大于80分，基础能力达标），Harness 是放大系数。模型决定了 Agent 的上限，但 Harness 决定了它离上限有多近。在2026年的模型能力水平下，Harness已经占据了约70%的实际业务效果权重。随着 Harness Engineering 框架的成熟，工程师的价值跃升，在于从”写代码”转向“定目标、设边界、控节奏、验结果”，直至成为需求的最终主人。而这场跃迁的起点，就是先建好 Harness。

二、怎么构建一套可复用的 Harness？

2.1 Harness Engineering 构建理论抽象

           OpenAI 发表的官方文章《Harness Engineering: Harnessing Codex in an Agent-First World》组织比较零散，这里结合全文内容将“怎么构建 Harness Engineering”拆分成三个维度分析下，同时在每个维度下重点关注下我们应该怎么做：

综合来说：上下文工程确保智能体在每次运行时有足够且精准的信息输入 → 架构约束确保输出符合结构不变量 → 熵与垃圾收集确保系统在长时间运行后不会因模式复制而退化。三者缺一，智能体优先的工程体系就无法持续运转。Harness Engineering 目标是构建AI的运行环境，确保其安全、可控、稳定地执行任务。

附：

• OpenAI 发表《Harness Engineering: Harnessing Codex in an Agent-First World》：https://openai.com/zh-Hant-HK/index/harness-engineering/

2.2 Harness Engineering 工程目录参考

结合理论知识，工程研发 Harness Engineering 中完整的研发图如下：

以 Claude Code + OpenSpec 为例的代码目录如下：

my-project/
│
├── openspec/                          # ===== OpenSpec 规范层 =====
│   ├── AGENTS.md                      # 智能体导航文件
│   ├── config.yaml                    # OpenSpec 项目配置
│   │
│   ├── specs/                         # 权威基准（当前系统行为的真实来源，结构化知识库）
│   │   ├── auth/
│   │   │   └── spec.md                # 认证域规范：JWT 签发、会话管理、2FA
│   │   ├── payment/
│   │   │   └── spec.md                # 支付域规范：订单创建、退款、对账
│   │   ├── user/
│   │   │   └── spec.md                # 用户域规范：注册、资料、权限
│   │   └── notification/
│   │       └── spec.md                # 通知域规范：邮件、推送、站内信
│   │
│   ├── changes/                       # 提议中的变更（每个变更独立文件夹）
│   │   ├── add-2fa/                   # 进行中的变更：添加双因子认证
│   │   │   ├── proposal.md            # 为什么做、做什么
│   │   │   ├── design.md              # 技术实现方案（含架构决策）
│   │   │   ├── tasks.md               # 实现任务清单（带状态追踪）
│   │   │   └── specs/
│   │   │       └── auth/
│   │   │           └── spec.md        # Delta 规范（ADDED/MODIFIED/REMOVED）
│   │   │
│   │   └── archive/                   # 已归档的变更（完整决策历史）
│   │       ├── 2026-06-20-add-dark-mode/
│   │       │   ├── proposal.md
│   │       │   ├── design.md
│   │       │   └── tasks.md
│   │       ├── 2026-07-01-refactor-payment-service/
│   │       └── 2026-07-10-migrate-to-clerk-auth/
│   │
│   └── scripts/                       # OpenSpec 自动化脚本
│       └── spec-sync-check.sh         # CI 用：检查 specs/ 与代码一致性
│
├── .claude/                           # ===== Claude Code 执行层 =====
│   ├── settings.json                  # 权限配置（allow/deny）+ MCP 注册
│   └── hooks/                         # 运行时强制 Hook(以下示例)
│       ├── pre-npm-install.sh         # PreToolUse: 阻止安装未批准的包
│       ├── pre-file-edit.sh           # PreToolUse: 保护 specs/ 目录不被直接修改
│       ├── post-file-edit.sh          # PostToolUse: 文件修改后自动 lint
│       └── pre-commit.sh              # PreToolUse: 提交前运行 spec 验证
│
├── .github/
│   └── workflows/
│       ├── ci.yml                     # 主 CI：lint + type-check + test + spec-validate
│       ├── architecture-guard.yml     # 架构守卫：依赖方向 + 层边界检查
│       └── entropy-gc.yml             # 定时垃圾收集：每周扫描漂移
│
├── scripts/
│   ├── lint-spec-freshness.sh         # 规范新鲜度检查
│   └── gc-scan.sh                     # 垃圾收集扫描脚本
│
├── src/                 # 工程代码(省略)
│
├── tests/
│   ├── unit/                          # 单元测试
│   ├── integration/                   # 集成测试
│   └── structural/                    # 结构测试（验证架构约束，如分层依赖方向检查）
│       └── ArchitectureTest.java      # 架构约束
│
├── CLAUDE.md                          # Claude Code 项目规则（静态约束）
└── MEMORY.md                          # Claude Code 演化状态（动态记忆）

附一些使用说明和经验：

• AGENTS.md 由 Linux Foundation 下属 Agentic AI Foundation 托管的事实标准，之前由 OpenAI提议，CLAUDE.md 是 Claude Code 初始化后自带的文件。

• .github/workflows/ 目录是 GitHub Actions 的核心配置目录，专门用于存放 CI/CD（持续集成/持续交付）和自动化工作流的 YAML 配置文件。

• OpenSpec 使用时每次改动都要 sync 到对应 change 中，比较麻烦。若一个分支中存在多个 change，人工修复代码问题 sync 到 change 的繁琐度会增加。

• 若工程代码中哪怕只变更一行，也需要 sync 到相应的文档中，否则就会违背 SDD 的原则。

  SDD 是否能持续进行？根据历史的经验可知很难持续进行，尤其是在团队协作的背景下更难。