Harness Engineering 详解

为什么需要 Harness Engineering

在开始正式讲解之前，让我们先花一点时间来思考一个问题，那就是在 AI 技术快速发展的今天，我们传统的软件工程方式正在面临着什么样的挑战和变化。如果你是一名有几年经验的软件工程师，你可能已经感受到了这种变化，那就是 AI 编程助手正在越来越多地融入我们的日常工作中，从最开始的自动补全代码，到后来的生成整个函数，再到现在的可以帮我们完成一个完整的功能模块。这些工具确实给我们带来了很多便利，它们可以帮我们节省了很多时间，但是当我们兴奋地使用这些 AI 工具的时候，我们也会发现一些问题，这些问题如果不解决，就会限制 AI 工具的进一步应用。

比如说，有时候 AI 生成的代码虽然看起来能用，但是架构设计得不太合理，可能和我们项目的整体设计不太协调，或者有时候 AI 会做出一些不符合项目规范的决定，比如用了我们不推荐的技术选型，或者写了不符合我们代码风格的代码，又或者当我们想要让 AI 帮我们完成一个比较复杂的长期项目时，我们会发现单纯靠写提示词这种方式很难管理和控制整个过程，我们可能会遇到上下文不够用的问题，或者 AI 会忘记之前的重要决定，或者生成的内容前后不一致的问题。

这些问题其实都在指向同一个方向，那就是我们需要一种新的方法论，来帮助我们在 AI 时代更好地进行软件开发，而不是像现在这样只是把 AI 当作一个简单的辅助工具，我们需要一套完整的体系，让 AI 可以在我们的指导下，更自主地完成更多的工作，同时又能够保证质量和可控性。Harness Engineering 正是为了解决这些问题而被提出来的，它是 OpenAI 在 2026 年初正式提出的一种新的软件工程方法论。

什么是 Harness Engineering

一个非常形象的比喻

让我们用一个大家都能理解的比喻来开始我们的讲解，这样可以帮助你更快地抓住 Harness Engineering 的核心思想。

我们可以把 AI 模型想象成一匹非常有力量但是也很有个性的烈马，这匹马跑得很快，能力很强，如果你能驾驭得好，它可以带你去很远的地方，但是如果你只是骑在它身上随便喊几声，它可能不会按照你想要的方向前进，甚至可能会把你甩下来，或者跑到你不想去的地方。

在这个比喻里，Prompt Engineering（提示工程）就像是你对着这匹烈马喊话，你通过精心设计的语言指令来引导它前进，这种方式在某些简单的场景下是有效的，比如你只是想让马往前跑一段很短的路，或者路也比较平坦，没有什么复杂的情况，但是当你需要走很长的路，或者需要经过复杂的地形，或者你希望马能够自己处理一些突发情况的时候，仅仅靠喊话就不够了，你需要更多的控制手段。

而 Harness Engineering（驾驭工程）呢，就像是你给这匹烈马套上了一套精心设计的马具，这套马具可以帮助你更好地控制马的方向和速度，同时又不会限制马的力量和奔跑能力。通过这套马具，你可以让这匹烈马安全、可靠、持续地按照你想要的路线前进，即使是在很长的旅程中也不会出问题，你不需要一直盯着每一步该怎么走，你只需要设定好目的地和路线，马就会自己想办法到达。

下面这个 mermaid 图可以帮助你更直观地理解这个比喻。

正式的定义

好了，有了这个形象的比喻之后，让我们来看一下 Harness Engineering 的正式定义。Harness Engineering 是 OpenAI 在 2026 年初正式提出的一种 AI 时代的新型软件工程方法论，它的核心理念可以用八个字来概括，那就是「人类掌舵，代理执行」。这意味着在这种新的方法论下，工程师不再需要亲自去写每一行代码，而是把主要的精力放在设计一套叫做 Harness 的约束系统上，通过这套系统来引导 AI 智能体安全、可靠、自主地完成大规模的软件开发工作。

这里的 Harness 这个词，在英文里原本是指马具或者其他牲口的挽具，它的作用就是把人的意图传递给牲口，同时又能控制牲口的行动，用在这里非常贴切，因为它正好说明了这套系统的作用也是类似的，它把工程师的意图传递给 AI，同时又确保 AI 按照我们想要的方式行动。

它要实现的目标

那么，这套 Harness 系统最终要实现什么样的目标呢？简单来说，它的目标就是让 AI 智能体能够在零或极少人工干预的情况下，完成从代码生成、测试编写、PR 提交、代码审查处理，一直到部署、监控、Bug 修复和自我迭代的整个开发流程。这听起来可能有点不可思议，像是科幻小说里的情节，但是 OpenAI 的内部实践已经证明了这是完全可行的，他们已经用这种方式完成了大量的开发工作。

核心理念

工程师角色的转变

在理解了 Harness Engineering 的基本概念之后，让我们来详细探讨一下它的核心理念，也就是「人类掌舵，代理执行」。这个理念首先带来的就是工程师角色的根本性转变，如果你是一名传统的软件工程师，你可能习惯了自己动手写代码、调试程序、解决问题，你可能每天的工作就是坐在电脑前，一行一行地写代码，遇到问题就查资料、调试，直到解决问题。但是在 Harness Engineering 的范式下，你的工作内容会发生很大的变化，你不再需要亲自去做那些具体的执行工作，而是把更多的精力放在设计、监督和指导上。

首先，你从一个代码实现者变成了一个环境设计师，这意味着你不再需要亲自去实现每一个功能，而是要设计和搭建一个适合 AI 智能体工作的环境。这个环境包括很多方面，比如集成各种工具、配置权限、设置工作流程、准备必要的文档等等，就像是给工人搭建一个设备齐全、工具顺手的工作车间一样，车间建好了，工人才能高效地工作。

其次，你从一个逻辑编写者变成了一个意图规范者，这意味着你不需要告诉 AI 每一步具体要怎么做，而是要用清晰的方式定义你想要达到的目标和你希望遵循的规则。比如说，你不需要告诉 AI”先创建一个文件，然后写一个函数，函数的第一行做什么，第二行做什么，而是告诉 AI”我需要一个用户登录功能，它需要满足这些验收标准，遵循这些架构原则，使用这些技术选型”，然后 AI 就会自己想办法去实现。

最后，你从一个手动操作者变成了一个反馈闭环构建者，这意味着你要设计一套机制，让 AI 能够自动接收反馈、从错误中学习、不断优化自己的行为。就像是给系统安装了一个自动导航和纠错系统，AI 在工作的过程中会不断收到反馈，比如测试有没有通过，代码审查有没有通过，监控有没有问题，然后 AI 会根据这些反馈来调整自己的行为，下次做得更好。

下面这个 mermaid 图展示了工程师角色的转变过程。

一个简单的例子来理解这个转变

为了让你更好地理解这个角色转变，让我们来看一个简单的例子，假设我们要实现一个用户登录功能，这样你就能更直观地感受到这两种工作方式的区别。

在传统的开发模式下，工程师的工作流程可能是这样的：首先，你会坐在电脑前，先仔细阅读需求文档，理解这个功能需要做什么事情，然后设计数据库表结构，比如用户表里应该有哪些字段，密码应该怎么加密存储，接着编写用户模型，包含用户的创建、查询、更新等方法，再写登录接口的代码，处理用户的登录请求，验证用户名和密码，生成登录成功后返回 token，然后写测试用例，测试各种情况，比如正常登录的情况，用户名不存在的情况，密码错误的情况，最后手动测试一下，在浏览器里或者用 API 测试工具里试一下，确保功能正常工作，没有问题了再提交代码。在这个过程中，你需要亲自参与每一个环节，写每一行重要的代码。

但是在 Harness Engineering 的模式下，你的工作方式会完全不同。你首先会做的事情是找一个安静的地方，认真思考一下这个需求，然后写一份清晰的需求文档，用自然语言描述你想要实现的功能，包括详细的验收标准，明确的约束条件，还有架构要求等等，把这些都写清楚。然后，你会检查一下你的开发环境是不是已经都配置好了，比如 AI 可以访问的代码库，测试框架，CI/CD 流水线，代码质量检查工具等等，确保这些工具都能正常工作。接着，你可能会写一些基本的约束规则，比如代码风格要求，安全规范，架构原则等等，把这些规则都设置好。

当这些都准备好之后，你就可以让 AI 智能体开始工作了。AI 会自动理解你的需求，设计合适的架构，编写代码和测试，提交 PR，处理审查意见，一直到功能上线。而你在这个过程中，更多的是扮演一个监督者和指导者的角色，在关键的时候做出决策，在出现异常的时候进行干预，比如 AI 设计的架构你觉得不太合适，你可以指出来，让它调整一下，或者 AI 写的某个地方你觉得有问题，你可以给它一些提示，让它改一下，而不是自己去写每一行代码。

Context Engineering

它是做什么的

现在让我们来详细了解 Harness Engineering 的三个核心组成部分，首先是 Context Engineering，也就是上下文工程。如果用一句话来概括上下文工程的作用，那就是它负责管理 AI 的「记忆与视野」，确保 AI 能够拿到正确、精简、相关的信息，既不会因为信息太少而无法完成任务，也不会因为信息太多而被混淆，或者出现「幻觉」。

你可能有过这样的体验，当你和 AI 对话的时候，如果你给它的信息太多太杂，它可能会抓不住重点，或者出现”幻觉”，也就是编造一些不存在的信息，或者记错之前说过的话；反过来，如果你给它的信息太少，它又可能因为缺乏必要的背景知识而无法给出正确的答案，或者做出错误的假设。上下文工程就是为了解决这个问题而存在的，它就像是 AI 的一个智能助手，帮助 AI 整理和过滤信息，确保 AI 能够在合适的时候看到合适的内容，记住重要的事情，忘记不重要的事情。

它主要做哪些事情

那么，上下文工程具体都做哪些事情呢？主要包括以下几个方面，让我们一个一个来看，这样你就能更全面地理解。首先是上下文窗口管理，我们知道，现在的大语言模型都有一个最大 Token 数的限制，也就是它们一次性能够处理的信息是有限的，就像是一个人的记忆力是有限的，不可能记住所有的事情，上下文窗口管理就是要帮助我们在这个限制之内，合理地安排信息的优先级，把重要的信息放进去，把不重要的信息暂时放在外面，确保 AI 的”脑子”里装的都是最相关、最有用的信息。

其次是信息过滤，这包括去除无关的信息、屏蔽敏感的数据、压缩冗余的内容等等。比如，我们可能不希望 AI 看到某些包含密码或者密钥的配置文件，这时候就需要信息过滤来帮我们把这些内容屏蔽掉，确保安全。又比如，历史对话记录可能会有很多重复的内容，或者很多不重要的闲聊，我们可以通过压缩来减少它们占用的空间，只保留真正重要的部分。

第三是历史压缩，当我们和 AI 进行长时间的对话或者让 AI 处理长期项目时，历史信息会越来越多，就像是你和一个朋友聊天，聊的时间越长，说的话越多，如果不整理，很快就会记不清之前说过什么重要的事情了。这时候我们就需要对历史进行压缩，比如生成对话摘要、记录重要的决策、持久化关键的上下文等等，这样既可以保留重要的信息，又不会让 AI 的上下文窗口被填满，AI 既能记住重要的事，又不会被太多信息搞混。

最后是外部数据接入，除了对话历史之外，我们有时候还需要让 AI 访问一些外部的信息，比如项目的架构文档、业务逻辑说明、实时的监控数据等等，这些信息可能不在对话历史里，但是对完成任务很重要。这就是 RAG（检索增强生成） 技术发挥作用的地方，上下文工程会负责把这些外部数据合理地集成到 AI 的上下文中，让 AI 能够参考这些信息。

下面这个 mermaid 图展示了 Context Engineering 的主要工作内容。

一个详细的配置示例

为了让你更直观地理解上下文工程是怎么工作的，让我们来看一个详细的配置文件示例，这个配置文件是用 YAML 格式写的，它定义了上下文工程的各种规则和参数，你可以把它保存下来，根据自己的项目修改一下就能用。

# 这是一个上下文工程的配置文件示例
# 它定义了如何管理 AI 的记忆和视野，确保 AI 能够拿到正确、精简、相关的信息

context_engineering:
  # 第一部分：上下文窗口管理
  # 这部分配置控制如何在有限的 Token 数内安排信息的优先级
  window_management:
    # 最大 Token 数设置为 128000，这是当前很多大模型都支持的一个比较大的上下文窗口
    max_tokens: 128000
    
    # 信息优先级规则，这决定了哪些信息更重要，应该优先被放入上下文窗口
    priority_rules:
      # 最近的对话历史优先级最高，因为它们通常和当前任务最相关
      - recent_conversations: high
      # 架构文档也很重要，AI 需要了解项目的整体架构设计
      - architecture_docs: high
      # 用户反馈的优先级中等，它们可以帮助 AI 改进和调整
      - user_feedback: medium
      # 旧的变更日志优先级最低，因为它们的时效性不强
      - old_changelogs: low
  
  # 第二部分：信息过滤
  # 这部分配置控制哪些信息应该被过滤掉，不应该让 AI 看到
  information_filtering:
    # 排除文件模式，这些文件不会被 AI 看到，避免浪费 Token
    exclude_patterns:
      - "*.log"  # 日志文件通常包含太多冗余信息，对 AI 帮助不大
      - "*.tmp"  # 临时文件没有什么价值，不需要 AI 阅读
      - "node_modules/**"  # 依赖目录文件太多，而且 AI 不需要阅读依赖代码
    
    # 敏感数据处理配置，确保安全，避免泄露
    sensitive_data:
      # 自动掩盖 API 密钥，防止泄露到 AI 的上下文中
      - mask_api_keys: true
      # 自动掩盖密码，确保安全，不让 AI 看到真实密码
      - mask_passwords: true
  
  # 第三部分：历史压缩
  # 这部分配置控制如何处理历史对话信息，既保留重要内容又节省空间
  history_compression:
    # 每 10 条消息生成一次摘要，这样可以保留历史的主要内容又不会太占地方
    summary_interval: 10_messages
    # 持久化重要的决策，这样即使压缩了历史，AI 也不会忘记重要的决定
    persist_decisions: true
    # 历史信息保留 30 天，超过这个时间的信息会被清理，避免积压太多
    retention_days: 30
  
  # 第四部分：外部数据接入
  # 这部分配置控制如何让 AI 访问外部信息，补充对话历史以外的知识
  external_data:
    # 启用 RAG（检索增强生成），这样 AI 可以访问外部知识库
    rag_enabled: true
    
    # 知识库配置，这些目录下的文档会被索引并提供给 AI 参考
    knowledge_bases:
      - path: ./docs/architecture  # 架构文档目录，很重要
      - path: ./docs/business-logic  # 业务逻辑文档目录，也很重要
    
    # 实时数据源配置，AI 可以获取这些实时信息，了解当前状态
    realtime_sources:
      - type: github_events  # GitHub 事件，比如 PR、Issue 等动态
      - type: monitoring_alerts  # 监控告警，帮助 AI 了解系统运行状态

一段简单的代码示例

看完了配置文件，让我们再来看一段简单的代码示例，这段代码展示了一个上下文管理器的基本实现思路，我加了详细的注释，这样你就能看懂每一行是做什么的。

// 这是一个简化版的上下文管理器实现
// 它展示了 Context Engineering 的核心工作流程

// 首先定义一些我们需要用到的类型接口
// 这些接口帮助我们明确代码中各种数据的结构，让代码更清晰

// 任务接口，描述一个待执行的任务
interface Task {
  id: string;           // 任务的唯一标识符，用来区分不同的任务
  description: string;  // 任务的详细描述，用自然语言描述要做什么
  priority: 'low' | 'medium' | 'high';  // 任务的优先级，高优先级的任务会优先处理
}

// 对话消息接口，描述一条对话消息
interface Conversation {
  id: string;      // 对话消息的唯一 ID
  role: 'user' | 'assistant' | 'system';  // 消息的角色，是谁发的
  content: string; // 消息的具体内容，就是实际说的话
  timestamp: Date; // 消息的时间戳，什么时候发的
}

// 相关文档接口，描述一个相关的文档
interface RelevantDocument {
  id: string;     // 文档的 ID
  title: string;   // 文档的标题
  content: string; // 文档的内容摘要
  relevance: number; // 相关性评分，分数越高越相关
}

// 压缩后的历史接口
interface CompressedHistory {
  messages: Conversation[]; // 保留的消息
  summary: string | null; // 历史摘要，如果有的话
  keyDecisions: Decision[]; // 重要决策列表
}

// 最终上下文接口，这是最后交给 AI 的完整上下文
interface Context {
  task: Task;                    // 当前要执行的任务
  history: CompressedHistory;    // 压缩后的历史对话
  documents: RelevantDocument[]; // 相关的文档列表
  constraints: Constraint[];     // 约束条件列表
}

// 上下文管理器的主类，这是核心类
class ContextEngineer {
  private config: ContextConfig;  // 配置信息，从配置文件加载
  private memory: VectorStore;    // 向量数据库，用于存储和检索文档
  
  // 构造函数，接收配置和向量存储作为参数，初始化管理器
  constructor(config: ContextConfig, memory: VectorStore) {
    this.config = config;
    this.memory = memory;
  }
  
  // 这是核心方法，它负责准备最终要交给 AI 的上下文
  // 这个方法会把所有信息整合在一起，形成一个完整的上下文对象
  async prepareContext(task: Task, history: Conversation[]): Promise<Context> {
    // 第一步：从历史对话中提取关键信息并进行压缩
    // 我们不希望把所有的历史都塞给 AI，那样会占用太多 Token，而且 AI 也记不住
    const compressedHistory = this.compressHistory(history);
    
    // 第二步：从向量数据库中检索和当前任务相关的文档
    // 这样 AI 就可以了解项目的背景信息和相关知识，帮助更好地完成任务
    const relevantDocs = await this.memory.search(
      task.description,  // 用任务描述作为搜索关键词，找最相关的文档
      { limit: 5 }       // 最多返回 5 个最相关的文档，太多了也看不完
    );
    
    // 第三步：对信息进行脱敏处理，过滤掉敏感内容
    // 比如密码、API 密钥这些信息不应该让 AI 看到，要保护安全
    const sanitized = this.sanitize(compressedHistory, relevantDocs);
    
    // 第四步：组装最终的上下文对象
    // 把所有准备好的信息组合在一起，就可以交给 AI 了，AI 拿到这些就知道该怎么做了
    return {
      task,
      history: sanitized.history,
      documents: sanitized.docs,
      constraints: this.config.constraints
    };
  }
  
  // 这个方法负责压缩历史对话，节省 Token 同时保留重要信息
  private compressHistory(history: Conversation[]): CompressedHistory {
    // 如果历史对话非常少，只有几条消息，我们可以直接返回，不需要压缩
    if (history.length < 5) {
      return {
        messages: history,
        summary: null,
        keyDecisions: []
      };
    }
    
    // 保留最近的几条消息，因为它们通常最相关，最新的消息最重要
    const recentMessages = history.slice(-3);
    
    // 对更早的历史生成摘要，这样既能保留信息，又不会占用太多空间
    const oldMessages = history.slice(0, -3);
    const summary = this.generateSummary(oldMessages);
    
    // 提取重要的决策，这些决策可能会影响后续的任务，不能忘记
    const keyDecisions = this.extractKeyDecisions(history);
    
    // 返回压缩后的历史
    return {
      messages: recentMessages,
      summary,
      keyDecisions
    };
  }
  
  // 这个方法负责生成历史摘要（简化实现）
  // 在实际项目中，这里可能会调用 AI 来生成高质量的摘要
  private generateSummary(messages: Conversation[]): string {
    // 这里我们只是简单地返回一个占位符，真实项目会更复杂
    return "这是历史对话的摘要内容，总结了之前讨论过的重要事项...";
  }
  
  // 这个方法负责提取重要决策（简化实现）
  // 在实际项目中，这里会有更复杂的逻辑来识别重要决策
  private extractKeyDecisions(history: Conversation[]): Decision[] {
    // 这里暂时返回空数组，真实项目会解析历史找出重要决策
    return [];
  }
  
  // 这个方法负责信息脱敏和过滤，保护敏感信息
  private sanitize(history: any, docs: any): SanitizedContext {
    // 这里实现具体的脱敏逻辑，比如用正则表达式替换敏感信息
    // 比如把 API 密钥替换成 "***REDACTED***"，保护安全
    const sanitizedHistory = this.redactSensitiveInfo(history);
    const sanitizedDocs = this.redactSensitiveInfo(docs);
    
    // 返回脱敏后的内容
    return {
      history: sanitizedHistory,
      docs: sanitizedDocs
    };
  }
  
  // 这个方法负责具体的敏感信息替换（简化实现）
  private redactSensitiveInfo(input: any): any {
    // 实际项目中这里会有更复杂的正则表达式和替换逻辑
    // 这里暂时直接返回输入，不做处理
    return input;
  }
}

Architectural Constraints

它是做什么的

了解了 Context Engineering 之后，让我们来看第二个核心组成部分，那就是 Architectural Constraints（架构约束）。如果说 Context Engineering 是给 AI 提供正确的信息，让 AI 知道该参考什么，记住什么，那么 Architectural Constraints 就是给 AI 设定明确的边界和规则，告诉它什么可以做，什么不可以做，应该怎么做，不应该怎么做，就像是给孩子立规矩一样。

你可以把架构约束想象成给 AI 设的”围栏”，这些围栏可以防止 AI 做出不符合要求的事情，比如写出不规范的代码、设计出不合理的架构、或者做出不安全的决定。同时，这些围栏又不会限制 AI 的创造力，它仍然可以在规则允许的范围内自由发挥，找到最优的解决方案，就像是在一个有边界的自由，边界给了安全感，自由给了创造力。

它主要包含哪些内容

那么，架构约束具体都包含哪些内容呢？让我们一个一个来看，这样你就能有一个全面的了解。首先是代码规范定义，这包括编码风格指南、命名约定、目录结构规范等等。这些规范可以确保 AI 生成的代码和项目中已有的代码风格保持一致，让整个代码库看起来像是由同一个人写的，而不是各种各样的风格混杂在一起，这样维护起来也会方便很多，大家看代码也会觉得舒服。

其次是架构规则，这包括分层架构要求、模块边界定义、依赖关系约束等等。这些规则可以确保 AI 不会破坏项目的整体架构，比如不会让基础设施层直接依赖应用层，或者不会让不同的模块之间出现不合理的耦合，保持架构的清晰和稳定。

第三是接口契约，这包括 API 规范、数据格式要求、版本兼容性规则等等。这些契约可以确保 AI 生成的接口和系统中已有的接口能够很好地配合，不会出现接口不兼容的问题，前后端能够顺利对接，各个服务之间也能正常通信。

第四是安全边界，这包括权限最小化原则、安全最佳实践、漏洞预防规则等等。这些规则可以确保 AI 生成的代码是安全的，不会引入 SQL 注入、硬编码密钥、不安全的 CORS 配置等等安全问题，保护系统不会有安全漏洞。

最后是工具权限，这包括 AI 可执行的操作白名单、危险操作审核机制、资源使用限制等等。这些权限控制可以确保 AI 只能做我们允许它做的事情，比如可以让它运行测试，但是不能让它直接删除文件或者推送到生产环境，避免意外操作造成损失。

下面这个 mermaid 图展示了 Architectural Constraints 的主要内容。

一个详细的配置示例

让我们通过一个详细的配置文件示例来更直观地理解这些约束，这个配置文件也是用 YAML 格式写的，你可以参考一下。

# 这是一个架构约束的配置文件示例
# 它定义了 AI 在开发过程中需要遵守的各种规则和边界，确保 AI 做的事情符合要求

architectural_constraints:
  # 第一部分：代码风格规范
  # 这部分配置确保 AI 生成的代码风格统一、规范，大家看着舒服
  code_style:
    # 指定使用的编程语言，这里是 TypeScript
    language: typescript
    
    # 代码格式化工具，用 Prettier，很多项目都在用
    formatter: prettier
    
    # 代码检查工具，用 ESLint，可以检查出很多问题
    linter: eslint
    
    # 具体的代码规则，详细的要求都在这里
    rules:
      # 最大行长度设置为 100 个字符，超过这个长度的代码应该换行，不然看着累
      max_line_length: 100
      
      # TypeScript 的类型检查级别设置为 strict，这意味着会进行严格的类型检查，更安全
      use_types: strict
      
      # 命名约定规则，大家都遵守的话，代码就会很一致
      naming:
        # 类名使用大驼峰命名法，比如 UserService、ProductRepository，首字母大写
        classes: PascalCase
        # 函数名使用小驼峰命名法，比如 getUserInfo、calculateTotal，首字母小写
        functions: camelCase
        # 常量名使用大写下划线命名法，比如 MAX_RETRY_COUNT、DEFAULT_TIMEOUT
        constants: UPPER_SNAKE_CASE
  
  # 第二部分：架构规则
  # 这部分配置确保 AI 遵循项目的架构设计原则，不破坏整体架构
  architecture:
    # 指定使用的架构模式，这里是六边形架构，也叫端口和适配器架构，很流行
    pattern: hexagonal
    
    # 分层定义，每一层都有明确的职责和依赖规则，不能乱依赖
    layers:
      # Domain 层是领域层，它包含核心的业务逻辑，是整个系统的核心，最重要
      # 这个层不应该依赖任何其他层，它是最核心的，其他层依赖它
      - name: domain
        dependencies: []
      
      # Application 层是应用层，它负责编排业务流程，组织领域对象完成业务
      # 这个层只能依赖 Domain 层，不能依赖 Infrastructure 层，保持架构清晰
      - name: application
        dependencies: [domain]
      
      # Infrastructure 层是基础设施层，它负责技术实现细节，比如数据库、外部接口
      # 这个层可以依赖 Domain 层和 Application 层，提供技术支持
      - name: infrastructure
        dependencies: [domain, application]
    
    # 禁止的依赖关系，这些是绝对不允许出现的依赖，违反了架构原则
    forbidden_dependencies:
      - from: infrastructure
        to: application
        reason: "Infrastructure 层应该依赖抽象而不是具体实现，这符合依赖倒置原则，很重要
  
  # 第三部分：API 契约
  # 这部分配置确保 AI 生成的 API 符合规范，前后端能顺利对接
  api_contracts:
    # REST API 的规范，现在很多项目都用 RESTful
    rest:
      # 遵循 RESTful 风格，大家都熟悉
      style: restful
      # 版本号放在 URL 路径中，比如 /api/v1/users，这样版本管理清晰
      versioning: path
      # HTTP 状态码规范，约定好大家都遵守，沟通起来方便
      status_codes:
        # 成功的状态码，这些表示请求成功了
        success: [200, 201, 204]
        # 客户端错误的状态码，这些表示是客户端的问题
        client_error: [400, 401, 403, 404]
        # 服务端错误的状态码，这些表示是服务端的问题
        server_error: [500]
    
    # OpenAPI 规范配置，可以自动生成文档，很方便
    openapi:
      # 启用 OpenAPI，这样可以自动生成 API 文档，不用手动写文档了
      enabled: true
      # 自动生成 OpenAPI 文档，省了很多事
      auto_generate: true
  
  # 第四部分：安全边界
  # 这部分配置确保 AI 生成的代码是安全的，没有漏洞
  security:
    # 认证方式，只允许使用这两种认证方式，其他的不要用
    authentication:
      - jwt
      - oauth2
    
    # 授权方式，基于角色的访问控制，很常用
    authorization:
      - rbac
    
    # 禁止的做法，这些是绝对不允许的，很危险
    forbidden_practices:
      - sql_injection_risk  # 有 SQL 注入风险的做法，绝对不能有
      - hardcoded_secrets    # 硬编码密钥，绝对不能做
      - insecure_cors        # 不安全的 CORS 配置，也不能有
  
  # 第五部分：工具权限
  # 这部分配置控制 AI 可以执行哪些操作，不能做危险的事
  tool_permissions:
    # 允许执行的操作白名单，只有这些操作可以做
    allowed_operations:
      # 可以读取源代码和测试代码，这是没问题的
      - read: ["src/**", "tests/**"]
      # 可以写入源代码和测试代码，这也是需要的
      - write: ["src/**", "tests/**"]
      # 可以运行测试和代码检查，这是好的
      - execute: ["npm run test", "npm run lint"]
    
    # 限制执行的操作，这些操作需要特殊处理，不能随便做
    restricted_operations:
      # 不允许随意删除文件，太危险了
      - delete: ["**/*"]
      # 不允许直接执行这些危险的命令，绝对不行
      - execute: ["rm -rf", "npm publish", "git push"]
    
    # 需要人工审批的操作，这些操作 AI 不能自己决定，必须经过人同意才能做
    approval_required:
      - production_deployment  # 生产环境部署，这是大事，必须人来批准
      - database_migrations    # 数据库迁移，也很重要，需要人审核

一个简单的验证器代码示例

看完了配置文件，让我们再来看一段简单的代码示例，这段代码展示了如何实现一个架构约束验证器，我同样加了详细的注释。

// 这是一个简化版的架构约束验证器实现
// 它展示了如何检查 AI 生成的代码和操作是否符合我们设定的约束

// 首先定义一些必要的类型接口，让代码更清晰
interface ValidationError {
  rule: string;        // 违反的规则名称，说明是哪条规则没遵守
  message: string;     // 错误信息，详细描述问题
  severity: 'error' | 'warning';  // 严重程度，是必须修复的错误还是建议性的警告
}

interface ValidationResult {
  valid: boolean;           // 是否通过验证，true 表示没问题，false 表示有问题
  errors: ValidationError[]; // 错误列表，所有发现的问题都在这里
}

interface File {
  path: string;  // 文件路径，说明是哪个文件
  content: string;  // 文件内容，文件里的具体代码
}

interface ToolOperation {
  name: string;       // 操作名称，比如 "delete"、"execute" 等
  arguments: any[];   // 操作参数，操作需要的具体参数
}

// 架构约束验证器的主类
class ArchitectureValidator {
  private constraints: ArchitecturalConstraints;  // 约束配置，从配置文件加载
  
  // 构造函数，接收约束配置作为参数
  constructor(constraints: ArchitecturalConstraints) {
    this.constraints = constraints;
  }
  
  // 这个方法负责验证 AI 生成的代码，检查有没有违反约束
  validateCode(code: string, file: File): ValidationResult {
    // 创建一个数组来收集所有的验证错误，有问题就加进来
    const errors: ValidationError[] = [];
    
    // 第一步：检查代码风格是否符合规范
    // 这包括缩进、命名、行长度等等，确保代码看起来整洁
    errors.push(...this.checkStyle(code, file));
    
    // 第二步：检查是否符合架构规则
    // 比如依赖关系、分层原则等等，确保架构设计正确
    errors.push(...this.checkArchitecture(file));
    
    // 第三步：检查是否符合安全规范
    // 比如有没有硬编码的密钥、有没有 SQL 注入风险等等，确保安全
    errors.push(...this.checkSecurity(code, file));
    
    // 最后，根据是否有错误来返回验证结果
    return {
      valid: errors.length === 0,  // 如果没有错误，就通过验证
      errors: errors  // 把所有错误都返回去，方便修复
    };
  }
  
  // 这个方法负责检查代码风格（简化实现）
  private checkStyle(code: string, file: File): ValidationError[] {
    const errors: ValidationError[] = [];
    
    // 检查最大行长度，太长的话要换行
    const lines = code.split('\n');
    for (let i = 0; i < lines.length; i++) {
      if (lines[i].length > this.constraints.code_style.rules.max_line_length) {
        errors.push({
          rule: 'max_line_length',
          message: `第 ${i + 1} 行超过了最大长度限制，应该换行`,
          severity: 'warning'  // 这是一个警告，不是必须立即修复的
        });
      }
    }
    
    // 在实际项目中，这里还会有更多的代码风格检查
    // 比如命名规范、缩进、引号使用等等，这里就不一一写了
    
    return errors;
  }
  
  // 这个方法负责检查架构规则（简化实现）
  private checkArchitecture(file: File): ValidationError[] {
    const errors: ValidationError[] = [];
    
    // 根据文件路径判断它属于哪一层，比如 domain、application 还是 infrastructure
    const layer = this.getLayerFromFilePath(file.path);
    
    // 解析文件中的 import 语句，检查是否有不允许的依赖
    const imports = this.parseImports(file.content);
    for (const imp of imports) {
      const importedLayer = this.getLayerFromFilePath(imp.path);
      
      // 检查这个依赖是否在禁止列表中，如果在就报错
      const forbidden = this.constraints.architecture.forbidden_dependencies.find(
        dep => dep.from === layer && dep.to === importedLayer
      );
      
      if (forbidden) {
        errors.push({
          rule: 'forbidden_dependency',
          message: `禁止的依赖：${layer} 层不能依赖 ${importedLayer} 层。原因：${forbidden.reason}`,
          severity: 'error'  // 这是严重错误，必须修复
        });
      }
    }
    
    return errors;
  }
  
  // 这个方法根据文件路径判断它属于哪一层（简化实现）
  private getLayerFromFilePath(path: string): string | null {
    if (path.includes('/domain/')) return 'domain';
    if (path.includes('/application/')) return 'application';
    if (path.includes('/infrastructure/')) return 'infrastructure';
    return null;  // 如果都不是，就返回 null
  }
  
  // 这个方法解析文件中的 import 语句（简化实现）
  private parseImports(content: string): Import[] {
    // 在实际项目中，这里会使用真正的解析器来解析代码
    // 这里暂时返回空数组，真实实现会更复杂
    return [];
  }
  
  // 这个方法负责检查安全规范（简化实现）
  private checkSecurity(code: string, file: File): ValidationError[] {
    const errors: ValidationError[] = [];
    
    // 检查是否有硬编码的 API 密钥，这是不安全的
    // 这只是一个非常简单的示例，实际项目中会有更复杂的检测逻辑
    const apiKeyPattern = /api[_-]key\s*[:=]\s*['"]([a-zA-Z0-9]+)['"]/gi;
    let match;
    while ((match = apiKeyPattern.exec(code)) !== null) {
      errors.push({
        rule: 'hardcoded_secrets',
        message: '发现硬编码的 API 密钥，这是不安全的做法，请使用环境变量',
        severity: 'error'  // 这是严重错误，必须修复
      });
    }
    
    // 检查是否有 SQL 注入风险，这也很危险
    // 同样，这只是一个简化的示例，实际项目会更复杂
    const sqlInjectionPattern = /`.*\$\{.*\}.*`/g;
    while ((match = sqlInjectionPattern.exec(code)) !== null) {
      errors.push({
        rule: 'sql_injection_risk',
        message: '发现可能存在 SQL 注入风险的代码，请使用参数化查询',
        severity: 'error'  // 这也是严重错误，必须修复
      });
    }
    
    return errors;
  }
  
  // 这个方法负责验证 AI 想要执行的工具操作，检查是否允许
  validateToolUse(operation: ToolOperation): boolean {
    // 首先检查这个操作是否在限制列表中，如果在就要小心
    const isRestricted = this.constraints.tool_permissions.restricted_operations.some(
      restricted => this.matchesOperation(restricted, operation)
    );
    
    if (isRestricted) {
      // 如果是限制操作，需要人工审批，不能让 AI 自己决定
      return this.requestApproval(operation);
    }
    
    // 然后检查这个操作是否在允许列表中，如果在就可以执行
    const isAllowed = this.constraints.tool_permissions.allowed_operations.some(
      allowed => this.matchesOperation(allowed, operation)
    );
    
    return isAllowed;
  }
  
  // 这个方法检查操作是否匹配（简化实现）
  private matchesOperation(pattern: any, operation: ToolOperation): boolean {
    // 在实际项目中，这里会有更复杂的匹配逻辑
    // 这里暂时返回 false，真实实现会更复杂
    return false;
  }
  
  // 这个方法请求人工审批（简化实现）
  private requestApproval(operation: ToolOperation): boolean {
    // 在实际项目中，这里会通知人工进行审批
    // 可能会通过即时消息、邮件、或者专门的审批界面来通知
    console.log(`需要人工审批操作：${operation.name}，请等待工程师审核`);
    return false;  // 简化实现，默认不允许，等待人工审批
  }
}

Garbage Collection

它是做什么的

现在让我们来看 Harness Engineering 的第三个核心组成部分，那就是 Garbage Collection（熵清理）。这里的 Garbage Collection 和我们平时在编程语言中说的垃圾回收不太一样，它不是指回收内存，而是指持续地「纠错与净化」，通过自动过滤无效输出、修复重复错误、清理上下文冗余、维护系统一致性来避免 AI 行为失控。

你可以把熵清理想象成一个系统的”清洁工”和”纠错员”，它会在后台持续工作，确保整个系统保持在一个健康、一致的状态。AI 虽然很强大，但它有时候也会犯错误，或者生成一些质量不高的输出，或者重复说一些没有意义的话，如果这些错误和低质量输出积累起来，就可能会导致整个系统出现问题，就像是房间里的垃圾如果不及时清理，就会越堆越多，最后影响正常生活，而熵清理就是为了防止这种情况发生的。

它主要做哪些事情

那么，熵清理具体都做哪些事情呢？让我们一个一个来看，这样你就能有一个全面的了解。首先是无效输出过滤，这包括识别并丢弃低质量的生成内容、检测重复或无意义的内容、过滤不符合要求的输出等等。比如，如果 AI 多次生成了类似的、没有实质内容的回复，或者生成的内容质量很低，根本没法用，熵清理就会把这些回复过滤掉，不让它们污染系统，也不让它们浪费时间。

其次是错误修复和学习，这包括从失败中学习、自动修复常见问题、避免重复犯同样的错误等等。比如，如果 AI 在某个地方犯了一个错误，导致测试失败了，熵清理会记录这个错误，分析它的原因，然后在下次遇到类似情况时提醒 AI，或者尝试自动修复，就像是一个聪明的助手，会从错误中学习，不会重复跌倒。

第三是上下文冗余清理，这包括移除过时的信息、合并重复的内容、优化存储空间等等。随着时间的推移，系统中会积累越来越多的信息，其中很多信息可能已经过时了，或者是重复的，就像是你手机里的旧照片和聊天记录，如果不清理，就会占用越来越多的空间，熵清理会定期地把这些信息清理掉，让系统保持轻量和高效。

最后是系统一致性维护，这包括确保代码库一致性、同步状态管理、冲突检测与解决等等。比如，如果 AI 在不同的地方生成了不一致的代码，或者两个不同的 AI 智能体对同一个文件做了不同的修改，熵清理会检测到这些不一致，并尝试解决它们，保持整个系统的一致性。

下面这个 mermaid 图展示了 Garbage Collection 的主要工作内容。

一个详细的配置示例

让我们通过一个详细的配置文件示例来更直观地理解熵清理，这个配置文件也是用 YAML 格式写的。

# 这是一个熵清理的配置文件示例
# 它定义了如何自动纠错、净化和维护系统，让系统保持健康状态

garbage_collection:
  # 第一部分：无效输出过滤
  # 这部分配置控制如何识别和过滤低质量的输出，不让它们污染系统
  invalid_output_filtering:
    # 质量阈值设置为 0.7，意味着只有质量评分超过 0.7 的输出才会被接受，质量太低的就丢弃
    quality_threshold: 0.7
    
    # 检测器配置，用来识别各种问题输出
    detectors:
      # 重复内容检测，如果新输出和之前的内容相似度超过 0.8，就认为是重复的
      - type: duplicate_detection
        threshold: 0.8
      
      # 无意义内容检测，用 GPT-4 来判断输出是否有意义
      - type: nonsense_detector
        model: gpt-4
      
      # 约束违反检查，检查输出是否违反了我们设定的约束
      - type: constraint_violation_check
  
  # 第二部分：错误修复和学习
  # 这部分配置控制如何从错误中学习，避免重复犯同样的错误
  error_recovery:
    # 启用从失败中学习，这样系统会越来越好
    learn_from_failures: true
    
    # 错误记忆配置，记录之前犯过的错误
    error_memory:
      max_entries: 1000  # 最多记录 1000 条错误，太多了也记不住
      retention_days: 90  # 错误记录保留 90 天，时间太久的错误可能已经不适用了
    
    # 自动修复配置，尝试自动修复常见问题
    auto_repair:
      enabled: true  # 启用自动修复
      max_attempts: 3  # 最多尝试修复 3 次，不行就放弃
      
      # 修复策略，按顺序尝试
      strategies:
        - retry_with_hint  # 先尝试给个提示重新生成
        - simplify_task     # 如果不行，就简化一下任务
        - ask_for_clarification  # 最后实在不行，就请人来澄清一下
  
  # 第三部分：上下文冗余清理
  # 这部分配置控制如何清理冗余的上下文信息，保持系统轻量
  context_cleanup:
    # 定时任务配置，每天凌晨 2 点执行清理，这个时候系统通常比较空闲
    schedule: "0 2 * * *"
    
    # 清理规则，详细的规则都在这里
    rules:
      # 移除 7 天前的临时上下文，这些已经没用了
      - remove_older_than: 7_days
        type: temporary_context
      
      # 压缩 1 天前的对话历史，节省空间又保留信息
      - compress_older_than: 1_day
        type: conversation_history
      
      # 去重，移除重复的内容
      - deduplicate: true
        type: all
  
  # 第四部分：系统一致性维护
  # 这部分配置控制如何保持系统的一致性
  consistency_maintenance:
    # 检查配置，定期检查系统是否一致
    checks:
      # 代码风格同步检查，每次代码变更时都检查一下
      - type: code_style_sync
        frequency: on_each_change
      
      # 依赖审计，每天检查一次依赖是否有问题
      - type: dependency_audit
        frequency: daily
      
      # 安全扫描，每周扫描一次安全问题
      - type: security_scan
        frequency: weekly
    
    # 冲突解决配置，如果发现冲突怎么办
    conflict_resolution:
      # 解决策略，这里是让人来审核，比较安全
      strategy: human_review
      # 自动合并的阈值，只有置信度超过 0.9 才自动合并，否则就找人看
      auto_merge_threshold: 0.9

工程师的新工作

好了，现在我们已经了解了 Harness Engineering 的三个核心组成部分，接下来让我们来看一下在这种新的范式下，工程师从写代码到设计系统的具体工作内容，具体要做什么事情。

工作一：设计声明式意图

首先，工程师的第一项新工作就是设计声明式意图，这是什么意思呢？简单来说，就是用清晰的方式定义「要做什么」，而不是「怎么写代码」。在传统的开发模式下，你可能需要详细地思考每一步该怎么做，先写什么函数，再写什么类，每个函数里具体写什么代码，但是在 Harness Engineering 下，你不需要想这么细，你只需要把你想要达到的目标、验收标准、约束条件等等说清楚，AI 就会自己想办法去实现。

比如说，你想实现一个电商网站的购物车功能，你不需要告诉 AI”先创建一个 ShoppingCart 类，里面有一个 items 数组，然后写一个 addItem 方法，接收 productId 和 quantity 参数，然后检查商品是否存在，然后更新数量，然后计算总价”，你只需要写一份清晰的需求文档，说”我需要一个购物车功能，用户可以添加商品、修改数量、删除商品，要能计算总价，要有库存检查，用户未登录时存在本地存储，登录后同步到服务器”，然后 AI 就会自己去想办法实现这些功能。

工作二：搭建智能体环境

工程师的第二项新工作就是搭建智能体环境，这就像是给工人搭建一个设备齐全的工作车间一样，车间建好了，工具配好了，工人才能高效地工作。搭建智能体环境包括很多方面，比如 IDE 集成配置，让 AI 能够在我们常用的编辑器里工作；比如 CI/CD 流水线搭建，让 AI 提交的代码能够自动测试、自动构建、自动部署；比如测试框架集成，让 AI 能够方便地运行测试，看到测试结果；比如监控系统对接，让 AI 能够了解系统的运行状态，出了问题能够及时知道；还有代码库访问权限配置，确保 AI 只能访问它需要访问的代码，不能随便修改不该修改的东西。

这些环境的搭建可能需要一些前期的工作，但是一旦搭建好了，就可以长期使用，而且会大大提高 AI 的工作效率，也会让整个开发流程更加顺畅。

工作三：构建反馈闭环

工程师的第三项新工作就是构建反馈闭环，这是非常重要的一项工作，因为反馈闭环能让 AI 自动接收反馈、从错误中学习、不断优化自己的行为，就像是给系统安装了一个自动导航和纠错系统，让系统能够越来越好。

构建反馈闭环包括很多方面，比如测试结果自动反馈，AI 写完代码后，自动运行测试，然后把测试结果告诉 AI，通过了就继续，没通过就根据错误信息修改；比如代码审查意见集成，AI 提交 PR 后，人工或者另一个 AI 会进行代码审查，审查意见会自动反馈给原来的 AI，让它修改；比如日志告警接入，系统上线后，如果出现错误或者告警，这些信息也会反馈给 AI，让它知道哪里出了问题，需要修复；还有用户反馈收集，用户使用产品后的反馈也可以收集起来，反馈给 AI，让它根据用户的意见来改进产品。

工作四：优化系统提示与规则

工程师的第四项新工作就是优化系统提示与规则，这就像是在调校一个精密的仪器，需要不断地调整参数，让它工作得越来越好。优化系统提示与规则包括很多方面，比如编写和维护 AGENTS.md，这是一个专门给 AI 看的文档，里面定义了 AI 的角色、目标、工作原则、工作流程等等；比如优化配置文件，根据实际使用情况调整各种配置参数，让系统更符合我们的需求；比如调整约束规则，如果发现有些约束太严格了，限制了 AI 的发挥，就可以适当放宽，如果发现有些约束不够，AI 经常犯错误，就可以适当加强；比如迭代提示策略，根据 AI 的实际表现，调整提示词的写法，让 AI 更容易理解我们的意图；还有收集最佳实践，把 AI 表现好的时候的做法记录下来，总结成经验，以后参考使用。

工作五：多智能体协调

工程师的第五项新工作就是多智能体协调，当项目变得比较复杂的时候，我们可能需要多个 AI 智能体协同工作，就像是一个团队，有不同的人负责不同的事情，这时候就需要有人来协调它们的工作，确保它们能够很好地配合，不会出现冲突或者重复工作。

多智能体协调包括很多方面，比如子智能体角色定义，我们要给每个智能体分配不同的角色，比如有的负责架构设计，有的负责写代码，有的负责测试，有的负责代码审查，每个角色有明确的职责；比如通信协议设计，我们要设计好智能体之间怎么交流，用什么格式传递信息，确保它们能够理解对方；比如任务调度策略，我们要设计好怎么把任务分配给不同的智能体，什么时候分配，怎么监控进度；比如协作机制建立，我们要设计好智能体之间怎么协作，遇到冲突怎么解决，怎么共享信息；还有冲突解决规则，提前定义好如果智能体之间出现分歧或者冲突，应该怎么处理。

下面这个 mermaid 图展示了一个多智能体团队的例子。

HE vs PE

现在让我们来对比一下 Harness Engineering 和 Prompt Engineering，看看它们到底有什么区别，这样你就能更清楚地理解 Harness Engineering 的特点和优势了。

一个直观的对比表格

首先让我们来看一个直观的对比表格，从多个维度来比较这两种方式。

一个具体的例子来对比

为了让你更直观地理解这个区别，让我们用一个具体的例子来对比一下，假设我们要处理客户投诉邮件的回复，看看这两种方式分别是怎么做的。

Prompt Engineering 方式

在 Prompt Engineering 方式下，你需要做的事情就是写一个好的提示词，然后每次收到投诉邮件时，把邮件内容填进去，让 AI 生成回复。

提示词可能长这样：

请帮我写一封邮件，回复客户关于产品延迟发货的投诉。
客户姓名：{{客户姓名}}
订单号：{{订单号}}
延迟原因：供应链问题
解决方案：提供 20% 折扣券
语气：诚恳、专业

每次有新的投诉邮件，你就把客户信息填进去，然后让 AI 生成回复。这种方式的优点是简单直接，快速就能用，但是缺点也很明显，比如你需要手动把信息填进去，需要手动发送邮件，需要手动跟踪后续的回复，如果情况变得复杂一点，比如客户回复了邮件，或者有其他特殊情况，这个提示词就不够用了，你需要不断地调整提示词，而且 AI 不会从之前的案例中学习，每次都是新的。

Harness Engineering 方式

而在 Harness Engineering 方式下，你需要做的事情就完全不同了，你不是写一个简单的提示词，而是设计一套完整的系统来处理这件事。

你需要设计 Context Engineering，让 AI 能够看到客户的历史记录、订单详情、过往沟通记录、公司政策文档等等；你需要设计 Architectural Constraints，设定邮件模板规范、折扣审批权限、客户数据隐私保护规则、响应时间 SLA 等等；你需要设计 Garbage Collection，自动过滤无效回复、从失败案例中学习、持续优化回复质量。

整个工作流程是这样的：系统接收客户投诉邮件，然后检索相关上下文，然后生成回复草稿，然后检查是否符合约束，如果需要审批就自动提交，然后发送邮件，然后跟踪客户回复，然后根据反馈优化系统。

这种方式的优点很明显，它是全自动化处理的，不需要人工干预太多；它有持续学习和优化的能力，会越用越好；它可以处理复杂的邮件往来，不是简单的单次回复；它能确保质量和合规性，不会出问题。当然，它的缺点就是前期设计成本比较高，你需要花时间来设计这套系统，但是一旦设计好了，长期来看会节省很多时间，而且效果会好很多。

真实案例：OpenAI 是怎么做的

现在让我们来看一个真实的案例，那就是 OpenAI 自己是怎么实践 Harness Engineering 的，这个案例很有说服力，因为这就是他们提出这个方法论的原因。

背景

在 2025 年到 2026 年期间，OpenAI 的内部团队进行了大规模的 Harness Engineering 实践，他们想用这种方式来提高开发效率，同时保证代码质量，结果他们取得了非常显著的成果，这也是为什么他们会正式提出这个方法论。

核心数据

让我们先来看一些核心数据，这些数据很有说服力，能让你直观地感受到 Harness Engineering 的效果。

智能体的完整工作流

OpenAI 的 Codex 智能体能够自动完成从需求理解一直到监控修复的完整工作流，让我们来看一下这个完整的流程是什么样的。

这个流程包括以下这些步骤：

1. 需求理解：AI 智能体首先理解需求，弄明白要做什么
2. 架构设计：然后设计合适的架构，考虑怎么实现比较好
3. 编写测试：接着写测试用例，遵循 TDD（测试驱动开发）的理念
4. 实现代码：然后才是写实现代码，让测试通过
5. 本地测试：写完代码后先在本地跑测试，确保没问题
6. 提交 PR：测试通过后就提交 PR（Pull Request）
7. 代码审查：然后进行代码审查，可能是人工审查，也可能是另一个 AI 审查
8. 处理审查意见：如果审查没通过，就根据审查意见修改
9. 合并代码：审查通过后就把代码合并到主分支
10. 部署：然后部署到测试环境或者生产环境
11. 监控：部署之后持续监控系统运行状态
12. 发现问题修复 Bug：如果监控发现问题，或者用户反馈问题，就修复 Bug，然后重新部署

你看，整个流程 AI 都能自己完成，几乎不需要人工干预，这是不是很厉害？

关键成功因素

OpenAI 之所以能取得这么好的效果，有几个关键的成功因素，这些因素很重要，我们如果要实践 Harness Engineering，也需要注意这些方面。

首先是完善的约束系统，他们设定了清晰的代码规范、严格的架构规则、全面的测试要求，这些约束就像是给 AI 设的围栏，既给了 AI 自由发挥的空间，又确保了 AI 不会出问题。

其次是强大的反馈闭环，他们有自动化的测试覆盖、持续集成流水线、实时监控告警，这些反馈机制能让 AI 及时知道自己做得好不好，有问题及时修正，而且能从错误中学习，下次做得更好。

第三是渐进式采用，他们不是一开始就把所有事情都交给 AI，而是从简单任务开始，先让 AI 做一些简单的、低风险的事情，建立信心后再逐步增加复杂度，这种方式比较稳妥，不容易出大问题。

第四是人类监督而非控制，他们的理念是人类设定目标和边界，审核关键决策，处理异常情况，而不是事无巨细地控制每一步，这种方式既发挥了 AI 的能力，又保持了人类的控制权。

经验教训

当然，在实践过程中，OpenAI 也总结了一些经验教训，这些教训对我们也很有参考价值。

首先说说做得好的地方：第一，他们从小处着手，先自动化简单、重复的任务，建立信心后再逐步扩展，这种方式很稳妥；第二，他们投资基础设施，建立了完善的测试覆盖、强大的 CI/CD 流水线、全面的监控系统，这些基础设施是成功的基础；第三，他们持续优化，收集失败案例，分析根因，迭代改进约束和规则，让系统越来越好。

再说说需要改进的地方：第一，初始设计比较复杂，前期需要投入大量时间设计系统，对团队能力要求也比较高，不是随便就能做的；第二，调试比较困难，AI 的决策过程不够透明，问题定位和调试比传统开发更难，出了问题有时候不知道为什么；第三，边界情况处理还不够完善，极端情况仍需人工干预，需要设计更完善的异常处理机制。

价值与意义

现在让我们来谈一谈 Harness Engineering 的价值与意义，也就是这种新的方法论对我们来说到底意味着什么，能给我们带来什么好处。

价值一：效率爆炸

第一个价值就是效率爆炸，也就是大幅减少重复编码，让整体开发效率有一个巨大的提升。在传统的开发模式下，工程师需要花很多时间在重复性的编码工作上，比如写 CRUD 操作、写简单的 UI 组件、写测试用例等等，这些工作虽然不难，但是很花时间，而且做多了会让人觉得枯燥。而在 Harness Engineering 模式下，这些重复性的工作都可以交给 AI 来做，工程师只需要专注于高价值的架构设计和业务逻辑思考，这样可以节省大量的时间，整体开发效率可能会提升 5 到 10 倍，这是一个非常巨大的提升。

我们可以这样来理解这种效率提升，传统模式下，需求出来后，工程师要设计，然后编码，然后测试，然后调试，然后部署，整个过程工程师全程参与，可能需要两周时间；而在 Harness Engineering 模式下，工程师只需要设计约束，然后 AI 就会执行，工程师只需要审核和处理异常，整个过程可能只需要一两天时间，这差距是不是很大？

价值二：质量可控

第二个价值就是质量可控，也就是通过约束系统和反馈闭环来降低 AI 出错概率，提升代码一致性，让代码质量更有保障。你可能会担心，AI 写的代码质量会不会不好？会不会有很多 bug？其实不用担心，因为 Harness Engineering 有完善的约束系统，会确保 AI 生成的代码符合规范，不会乱来；还有强大的反馈闭环，AI 写完代码后会自动测试，测试没过会自己修改，部署后有监控，出问题会及时修复；而且 AI 会从错误中学习，不会重复犯同样的错误，所以代码质量其实是很有保障的，甚至可能比一些经验不足的工程师写的代码还要好。

另外，Harness Engineering 还能提升代码一致性，因为有统一的代码风格、一致的架构模式、标准化的实现方式，整个代码库看起来就像是由同一个人写的，维护起来会方便很多，新人接手也会更容易。

价值三：规模化自治

第三个价值就是规模化自治，也就是让 AI 承担繁琐的执行工作，人类专注于高价值的决策工作，实现真正的规模化开发。AI 有一个很大的优势，那就是它可以 24/7 不间断地工作，不需要休息，不需要睡觉，而且可以并行处理多个任务，同时做好几件事，这是人做不到的。通过 Harness Engineering，我们可以充分发挥 AI 的这个优势，让它承担那些繁琐的、机械的、重复的执行工作，而我们人类则专注于那些高价值的决策工作，比如架构设计、需求分析、关键决策、系统优化等等，这样的分工是最合理的，也是最高效的。

价值四：人才价值升级

第四个价值就是人才价值升级，也就是工程师的角色从「编码者」升级为「设计者」，从「执行者」升级为「监督者」，从「操作者」升级为「决策者」，人才的价值得到了极大的提升。在传统的开发模式下，很多工程师的工作就是写代码，虽然这也是有价值的，但是相对来说还是比较机械的，很多人工作几年后就会遇到职业瓶颈，不知道该怎么进一步提升。而在 Harness Engineering 模式下，工程师不需要再写那么多代码了，而是要去设计系统、搭建环境、构建反馈闭环、优化规则、协调智能体，这些工作对能力的要求更高，当然价值也更大，工程师可以从一个单纯的技术人员，成长为一个系统架构师、一个团队管理者、一个技术决策者，职业发展的空间会大很多。

与此同时，对工程师的技能要求也发生了变化，传统的技能比如精通编程语言、算法和数据结构、调试技巧、框架使用经验等等，虽然还是有用的，但是已经不够了，新的技能变得更加重要，比如系统设计能力、声明式意图表达能力、反馈闭环设计能力、多智能体协调能力等等，这些技能会成为未来工程师的核心竞争力。

实践指南：从零开始的四步走

第一步：准备阶段（1-2 周）

第一步是准备阶段，这个阶段大概需要 1 到 2 周的时间，主要的目标是评估现状，建立基础。

在这个阶段，你需要做这么几件事情。首先是评估现有代码库，你要看看你现在的代码库质量怎么样，测试覆盖怎么样，架构是否清晰，如果你的代码库质量很差，测试覆盖很低，架构也很乱，那可能需要先花点时间整理一下，不然 AI 也很难在一个乱糟糟的代码库里工作。

其次是建立基础设施，你需要完善测试覆盖，搭建 CI/CD 流水线，配置代码质量工具，这些基础设施是 Harness Engineering 的基础，没有这些基础设施，AI 就没办法自动测试、自动部署、自动获取反馈，整个系统就跑不起来。

第三是选择试点项目，不要一开始就把所有项目都改成 Harness Engineering，那样风险太大了，你应该选择一个简单的、低风险的项目来试点，最好是有清晰规范的模块，而且有足够的测试覆盖，这样即使出了问题，影响也不会太大，你也可以从小项目中积累经验，建立信心。

第二步：设计约束（2-3 周）

第二步是设计约束，这个阶段大概需要 2 到 3 周的时间，主要的目标是建立基本的约束系统。

在这个阶段，你需要做这么几件事情。首先是编写 AGENTS.md，这是一个专门给 AI 看的文档，你要在里面定义 AI 的角色、目标、工作原则、工作流程等等，让 AI 知道它是谁，它要做什么，它应该怎么做。

其次是定义架构约束，你要制定代码规范、架构规则、安全要求等等，这些约束就像是给 AI 设的围栏，告诉它什么可以做，什么不可以做。

第三是搭建工具链，你要把 IDE、代码库、CI/CD 这些工具都集成起来，让 AI 能够方便地访问这些工具，使用这些工具。

第三步：小规模实验（1 个月）

第三步是小规模实验，这个阶段大概需要 1 个月的时间，主要的目标是验证概念，积累经验。

在这个阶段，你需要做这么几件事情。首先是从简单任务开始，不要一开始就让 AI 做复杂的事情，先让它做一些简单的任务，比如 Bug 修复、小功能开发、文档编写等等，这些任务比较简单，风险也比较低，容易成功，成功了可以建立信心。

其次是建立反馈闭环，你要把自动测试、代码审查、监控告警这些反馈机制都建立起来，让 AI 能够及时收到反馈，从错误中学习。

第三是收集数据和经验，你要记录成功的案例，分析失败的原因，总结最佳实践，这些数据和经验会对你后续的工作有很大的帮助。

第四步：逐步扩展（持续进行）

第四步是逐步扩展，这个阶段是持续进行的，没有明确的时间限制，主要的目标是扩大应用范围，持续优化。

在这个阶段，你需要做这么几件事情。首先是增加复杂度，当你在简单任务上取得成功后，你可以逐步增加任务的复杂度，让 AI 处理更复杂的任务，同时也可以引入多智能体协作，让多个 AI 智能体一起工作，还可以把 Harness Engineering 扩展到更多的项目中。

其次是优化系统，你要根据实际使用情况，迭代约束规则，改进反馈机制，提升自动化程度，让系统越来越好。

第三是建立组织能力，你要培训团队，让团队成员都理解和掌握 Harness Engineering，还要积累知识库，把经验和最佳实践都记录下来，还要形成自己的最佳实践，让整个组织都能受益。

关键成功因素

在实践 Harness Engineering 的过程中，有几个关键的成功因素，你一定要注意，这些因素决定了你的实践能不能成功。

首先是领导层支持，Harness Engineering 是一种范式转变，不是简单的工具升级，它需要投入时间和资源，也可能会遇到一些困难和挫折，如果没有领导层的支持，很难坚持下去，所以你一定要先获得领导层的支持，让他们理解这件事的价值，给予足够的时间和资源。

其次是团队能力建设，Harness Engineering 对团队的能力要求不一样了，你需要培养团队的系统思维和设计能力，让他们学习声明式编程思维，还要建立跨角色协作机制，让大家能够很好地配合。

第三是渐进式采用，不要试图一步到位，不要想着一下子把所有事情都改成 Harness Engineering，那样风险太大了，很容易失败，你应该从小处着手，快速迭代，用成功案例建立信心，然后再逐步扩展。

第四是持续优化文化，你要建立一种持续优化的文化，把每次失败都当作学习机会，不要害怕失败，要持续收集反馈和数据，定期回顾和改进，让系统越来越好。

常见陷阱与避免方法

在实践过程中，你可能会遇到一些常见的陷阱，我在这里给你列出来，并且告诉你怎么避免，希望你能少走弯路。

新的时代

好了，讲到这里，这篇文章也差不多要结束了，让我们来总结一下，回顾一下我们都讲了什么内容。

核心要点回顾

首先，我们讲了 Harness Engineering 是什么，它是 OpenAI 在 2026 年提出的 AI 时代的新型软件工程方法论，核心理念是「人类掌舵，代理执行」，通过给 AI 设计一套 Harness 系统，让 AI 能够安全、可靠、自主地完成软件开发工作。

然后，我们讲了 三个核心组成部分：

• Context Engineering（上下文工程）：管理 AI 的「记忆与视野」，确保 AI 拿到正确、精简、相关的信息
• Architectural Constraints（架构约束）：给 AI 设「围栏」，设定明确的边界和规则
• Garbage Collection（熵清理）：持续「纠错与净化」，保持系统健康和一致

接着，我们讲了 工程师角色的转变，从代码实现者变成环境设计师、意图规范者、反馈闭环构建者，工作内容完全不同了。

然后，我们对比了 Harness Engineering 和 Prompt Engineering，它们在关注点、时间尺度、工作对象、目标等等方面都有很大的区别，Harness Engineering 更适合复杂项目和长期开发。

我们还看了 OpenAI 的真实实践案例，他们用 Harness Engineering 生成了 100 万行代码，合并了 1500+ PR，效率提升了 10 倍，这充分证明了 Harness Engineering 的价值。

最后，我们讲了 价值与意义，包括效率爆炸、质量可控、规模化自治、人才价值升级，这些都是实实在在的好处。我们还给出了一个 循序渐进的实践指南，分成四个步骤，还有关键成功因素和常见陷阱，希望能帮助你顺利开始实践。

展望未来

现在，让我们来展望一下未来，随着 AI 技术的持续发展，Harness Engineering 会怎么发展呢？我想，它会变得更加智能化，AI 的理解和推理能力会更强，能处理更复杂的任务；它会变得更加自动化，需要更少的人工干预，很多事情 AI 自己就能搞定；它会变得更加普及化，成为标准的软件工程实践，越来越多的团队会采用这种方式；它还会变得更加生态化，形成完整的工具链和社区，大家可以分享经验，互相学习。记住，这是一个全新的时代，充满了机遇，也充满了挑战，让我们一起拥抱这个时代，一起探索，一起成长。

参考资源

官方资源

• OpenAI Harness Engineering 白皮书
• Martin Fowler 关于 Harness Engineering 的博客
• OpenAI Codex 智能体实践案例

相关概念

• Prompt Engineering（提示工程）
• AI Agent（智能体）
• RAG（检索增强生成）
• LLMOps（大语言模型运维）

工具与框架

• Cursor（AI 驱动的 IDE）
• GitHub Copilot Workspace
• Anthropic Claude Workbench
• 各种 AI Agent 框架

文档版本：v2.0（基于 OpenAI 2026 年提出的 Harness Engineering 方法论）
最后更新：2026年3月
作者：Wisdom、Echo AI Research