AI

每天吃透一个AI知识点_驾驭工程（Harness Engineering）

Posted Cola🌀

转载：小红书 AI产品赵哥

前言🔖

今天咱要来聊一个比较新的概念 —— Harness Engineering（驾驭工程），有多新呢？今年 2 月 11 号 OpenAI 才提出的一个新概念，虽然新，但是对 AI 圈的推动性却不容小觑！

你们有没有发现，现在 AI 写代码已经很强了，但光有 AI 不够啊！真正让 AI 能帮我们干活的关键，是怎么让 AI 可靠地工作。这就是 Harness Engineering 要解决的问题。

先说几个令我很震撼的例子：

  • OpenAI 的团队用 AI，五个月写了 100 万行代码，三个工程师平均每天合并 3.5 个 PR，没有一行是工程师手写的；
  • Anthropic 的 Claude Code 能连续工作好几天，帮你构建完整应用；
  • LangChain 的 Coding Agent 换个 “马甲”（harness），性能直接从 52.8% 飙升到 66.5%，模型本身没变！

这就是 Harness Engineering 的魅力 —— 设计一个环境，让 AI 能可靠地完成复杂任务。

　　

一、到底啥是 Harness Engineering?🔖

先打个比方：想象一个原生的大语言模型（LLM），它就像一匹拥有无穷力量、速度极快，但野性未驯的神话级野马 —— 日行千里的那种。

这匹马（AI 模型）能力强大，有海量知识；速度快，问之即答。但它也野性难驯，会遗忘，会幻觉（即一本正经地胡说八道），甚至会不听指挥。

🔹1.1 初级玩家的做法，就是我们熟悉的 Prompt Engineering（提示词工程）。

这就像你跑到马跟前，通过精心设计口令来引导它。比如，你不再是简单地喊 “去 B 点！”，而是用更精确的指令：“请你扮演一匹最棒的信使马，沿着河边小路，把货物送到 B 点的红色房子里。” 这能大大提高任务的成功率。

这就是提示词工程的本质 —— 通过精心设计的语言（缰绳），来引导和控制 AI 的行为。

但是，这还不太够用！如果路途很长，马会忘记目的地吗？遇到岔路口，它知道怎么选吗？需要查询外部信息时（比如地图），它能做到吗？

你会发现，只靠你一次次的喊话（Prompt），是无法建立一个稳定、可靠、可扩展的系统的。

　　

🔹1.2 Harness Engineering（驾驭工程）闪亮登场！

Harness，本意是 “马具”。就是给马套上的那一整套装备：缰绳、嚼子、眼罩、马鞍，以及连接马和马车的挽具。

驾驭工程，就是围绕着这匹强大的 AI 野马，构建一整套完整、精密的 “马具系统”，从而让它的强大力量能够被稳定、可靠、高效地利用。它不再是单点的 “对话”，而是系统化的 “工程”。

💡 一句话总结：Prompt Engineering 教你如何与马对话，而 Harness Engineering 教你如何为马打造一套定制的 “作战装备”，并指挥它完成复杂的系统性任务。

　　

🔹1.2 人话版定义

官方解释是这样的：

👨‍💼 "An agent harness is the system that enables a model to act as an agent: it processes inputs, orchestrates tool calls, and returns results."

翻译成人话就是：Harness 就是给 AI agent 配套的操作系统，帮它处理输入、安排工具使用、返回结果。是不是有点抽象？我来举个具体的🍂

　　

🔹1.3 一个小例子看看 Harness 厉不厉害就完了

场景：让 AI 帮你重构一个 10 万行的代码库

❌ 裸 AI（没有 Harness）：

直接把代码扔给 AI，说：“帮我重构”

→ AI 看了 1000 行就开始瞎改，3 小时后代码库彻底崩溃

✅ 有 Harness 的 AI：

  1. 先给 AI 注入架构文档（相当于给它一张地图）
  2. 限制每次只能改一个模块（不让它乱跑）
  3. 强制改完后必须跑测试（检查做对了没）
  4. 检测到失败时自动回滚（错了能撤回） → AI 花了 2 天，成功重构了 80% 的代码

有 Harness 和没有 Harness，差别就是这么大！！！

　　

二、Harness Engineering 的三个核心维度🔖

很多人以为 harness 就是 “给 AI 接工具的胶水层”，实际上它包含三个核心维度：

🔹2.1 Context Engineering（上下文工程）

核心：不是把所有信息都塞给 AI，而是给它一个地图，让它按需检索。

  • OpenAI 的 AGENTS.md 只有 100 行，但它指向完整知识库。AI 需要什么自己去查，而不是一次性全塞进去。大白话：就像导航软件，不是把所有地图数据一次性显示，而是你在哪里，就给你显示附近的路。

　　

🔹2.2 Tool Engineering（工具工程）

核心：设计受控的高效工具，不是让 AI 直接操作数据库，而是提供封装好的、带约束的 API。

  • 比如 Hightouch 的 Agent 不能执行任意 SQL，只能调用预定义好的查询函数。这样 AI 就不会因为权限太大而闯祸。大白话：就像给小孩一把安全剪刀，刀刃是钝的，只能剪纸，不能伤人。

　　

🔹2.3 Workflow Engineering（工作流工程）

核心：构建信任的验证循环，不让 AI 自己判断做完了，而是用外部标准验证来验证 AI 是否做完、做好。

  • LangChain 的 middleware 会强制 Agent 在退出前必须跑测试，没通过就不让走。

大白话：就像考试，不是学生说 “我写完了” 就行，得有标准答案检验你对了没有。

　　

三、为什么我们需要 Harness Engineering?🔖

这个问题特别重要，因为理解了 “为什么”，你才能真正理解这个概念的价值。

🔹3.1 核心挑战：AI 的 “失忆症”

👨‍💼 先问大家一个问题：AI 模型有记忆吗？

答案是：没有！

LLM（大型语言模型）每次推理都是独立的，类似于 f(context) → output。你给它一段文字，它预测下一个 token，然后就没了。下一次调用是完全独立的。

但是！复杂工作是有状态的。你得记住：

  • 我已经做了什么
  • 为什么要做这些
  • 下一步该做什么
  • 目标是什么

这就尴尬了：AI 是无状态的，但工作是有状态的。

Anthropic 用了一个特别形象的比喻：这就像一个软件项目由工程师轮班完成，每个新工程师来的时候都不记得上一班发生了什么。 你说尴尬不尴尬？

　　

🔹3.2 三个具体瓶颈

在生产环境中，这个挑战表现为三个具体的瓶颈：

瓶颈一：从 “单步智能” 到 “长时程可靠性” 的鸿沟

各种 Benchmark 刷榜制造了一个幻觉：模型在单轮任务上的准确率已经很高（>85%），但这无法预测它在第 50 步、第 100 步之后的表现。

"A 1% difference on a leaderboard cannot detect the reliability if a model drifts off-track after fifty steps."

排行榜上 1% 的差异无法检测出模型在第 50 步之后是否会偏离轨道。

Anthropic 在构建 Claude Code 时，发现了两个典型的失败模式：

  1. “All-or-nothing” 模式：Agent 试图一次性完成所有功能，导致 context 耗尽，下一个 session 接手时发现代码写了一半、没有文档、无法继续
  2. “过早胜利” 模式：Agent 看到一点进展就宣布任务完成，实际上核心功能还没实现

💡 这两个失败模式的共同点是：Agent 缺乏 “我在做什么” 的持续认知。

瓶颈二：Context 爆炸与 Attention 的限制

现在的 Agent 应用动辄需要处理 10 万 + token 的 context。但问题是 ——**Lost in the Middle（中间丢失）** 现象是 Transformer 架构 Attention 机制的数学特性。

这意味着：把 100 页文档全部塞进 context，效果还不如给 AI 一个 100 行的 “地图”，让它按需检索。

OpenAI 的 Codex 团队在构建 100 万行代码的 Agent 维护系统时，核心策略就是 “渐进式披露“：

  • 不是把整个 codebase 塞进 context
  • 而是给 AI 一个 AGENTS.md（100 行），作为稳定的入口点
  • AI 从这个地图出发，通过工具调用按需检索详细内容
"Context engineering is not about compression, it's about architecture."
— Harrison Chase, LangChain

💡 关键洞察：Context 工程的核心不是压缩，而是架构设计。

瓶颈三：从 “能跑” 到 “可维护” 的工程化 Gap

OpenAI 的 Codex 团队用 5 个月构建了一个 100 万行代码的应用，完全由 AI 生成和维护。但他们遇到的最大挑战不是 “让 AI 写代码”，而是 “让 AI 写的代码可维护”。

他们的核心发现是：

"Our most difficult challenges now center on designing environments, feedback loops, and control systems."
我们现在面临的最大挑战集中在设计环境、反馈循环和控制系统上。
— OpenAI Codex Team

这里有一个非常重要的数据：

  • GPT-5.2-Codex 在不同 harness 配置下，分数从 52.8% 到 66.5%（26% 的相对提升）
  • 模型从 GPT-5.2-Codex 升级到 GPT-5.3-Codex，在 SWE-Bench Pro 上只提升了 0.7%（56.4% → 56.8%）

💡 这说明：当模型能力达到一定水平后，系统设计成为效果的主要瓶颈。

　　

四、四家大厂的 Harness Engineering 实践🔖

🔹4.1 OpenAI：渐进式披露（解决信息量超出 context window）

主要挑战：

  • Agent 需要理解 100 万行代码，但 context window 只能装下约 20 万 tokens
  • 传统 “压缩” 方案（summarization、RAG）会丢失结构关系

解决思路：

  • 不要压缩信息，而是构建 “地图”
  • 给 AI 一个 100 行的 AGENTS.md 作为入口，让它按需检索

具体方法：

  1. 知识库作为目录：AGENTS.md 指向编目的设计文档和架构地图，AI 按需检索
  2. 为 Agent 优化代码库：所有关键信息必须在代码库内可检索，偏好 “无聊” 的技术
  3. 强制约束条件而非具体实现：要求 Codex 在边界解析数据，但不规定如何实现
  4. 自动偏差修复：后台任务定期扫描偏差，打开重构 PR

为什么有效：每次检索的内容都位于 Attention 的高效区域（前 20% 和后 20%），而非被困在 “注意力黑洞” 中。

　　

🔹4.2 Anthropic: Initializer + Coding Agent（解决跨会话状态丢失）

主要挑战：

  • Agent 必须在多个会话中工作，每个新会话开始时都 “失忆”
  • 导致 “All-or-nothing” 和 “过早胜利” 两种失败模式

解决思路：

  • 既然 AI 无法 “记住”，就让它每次启动时都能 “读取记录”
  • 把 “记忆” 从 AI 的内部状态外化为可读取的文件系统

具体方法：

  • 阶段 1: Initializer Agent — 构建 “记忆基础设施”:
    • init.sh (环境初始化)
    • 功能需求文件 (200 + 个功能，全部标记 “失败”)
    • claude-progress.txt (进度追踪)
    • 初始 git 提交
  • 阶段 2: Coding Agent — 每个会话遵循严格流程:
    • a. 读取状态
    • b. 做一件事 (一次只处理一个功能)
    • c. 验证 (端到端测试)
    • d. 记录状态 (git commit + 更新 progress notes)
    • e .如果写错代码，下个会话用 git 回滚

为什么有效：这个方法把有状态任务分解为一系列无状态操作。每个 Coding Agent 会话转换成了纯函数：

f(功能列表 + git history + progress notes) → 完成一个功能 + 更新记录

AI 不需要 “记住”，因为所有信息都在输入中。

　　

🔹4.3 LangChain：强制验证循环（解决 Agent 不会自我验证）

主要挑战：

  • Agent 不会自然地验证自己的工作
  • 写了代码 → 重新阅读 → 确认 “看起来没问题” → 停止
  • 但实际上代码根本跑不通

为什么会有这个问题？

这不是 “模型不够聪明”，而是训练数据偏差：LLM 的训练数据主要是 “写代码”（GitHub commits），而非 “写代码 – 测试 – 修复” 的完整循环。模型学会了 “生成看起来正确的代码”，但没学会 “验证代码是否真的正确”。

解决思路：

  • 不依赖 prompt，而是用确定性机制强制验证循环
  • 在 Agent 退出前用 middleware 拦截它，强制运行验证

具体方法:

  1. PreCompletionChecklistMiddleware: Agent 准备退出时拦截它，检查是否运行测试、测试是否通过
  2. LocalContextMiddleware: 启动时自动映射工作目录、查找可用工具、注入环境信息
  3. LoopDetectionMiddleware: 跟踪每个文件的编辑次数，编辑 N 次后添加上下文提醒

为什么有效: 把软约束（prompt）变成硬约束（代码逻辑）。Prompt 可能被忽略，但 Middleware 用确定性逻辑保证验证循环，Agent 无法绕过。

　　

🔹4.4 Hightouch: 动态子 Agent（解决单个 Agent 处理不了的复杂任务）

主要挑战:

  • 单个 Agent 的 context 装不下复杂任务的所有中间步骤
  • 典型场景：分析 1000 个客户的购买行为
  • 需要查询 1000 次（每次 500 tokens）= 50 万 tokens
  • 远超 context window

解决思路:

  • 不要压缩 context，而是隔离 context
  • 用 “分层处理” 替代 “线性压缩”

具体方法:

  1. 规划与执行分离: 通过特殊工具调用（make_plan、execute_step_in_plan、update_plan），Agent 管理自己的思维过程
  2. 文件缓冲: 工具返回大量数据时，Agent 调用write_file缓冲到磁盘，context 中只保留指针（文件名 + 描述）
  3. 动态子 Agent: 主 Agent 识别复杂子任务，生成独立 LLM 线程（子 Agent）处理，只有摘要返回主 Agent
  4. 扇出模式: 对非结构化数据，主 Agent 生成数百个并行调用到小模型（Haiku），每个处理一个，主 Agent 汇总结果

为什么有效: 主 Agent 的 context 只存储 “地图”（计划 + 摘要），详细信息在子 Agent 的独立 context 中，系统总 “工作记忆” 可远超单个 context window。

💡 关键洞察：用分层抽象替代线性压缩，因为压缩是有损的，但分层抽象可以无损。

　　

五、如何选择适合你的方案？🔖

这四种方案共同策略是：构建信息检索 + 状态管理 + 验证循环的系统。区别在于侧重点：

方案侧重点适用场景
OpenAI 渐进式披露重信息检索信息量超出 context window
Anthropic 外部化状态管理重状态管理任务跨多个会话
LangChain 强制验证循环重验证Agent 不会自我验证
Hightouch 动态子 Agent三者都重任务太复杂

　　

💡 怎么借鉴？先诊断瓶颈，再选择设计思路：

  • 信息量超出 context window → 渐进式披露
  • 任务跨多个会话 → 外部化状态管理
  • Agent 不会自我验证 → 强制验证循环
  • 任务太复杂 → 动态子 Agent

实际项目中的瓶颈可能是多个，需要组合多种设计思路。

　　

六、未来会怎样？🔖

Harness Engineering 目前处于 “百花齐放” 阶段，各大厂都在积极探索不同方向。这三个演化方向相对清晰：

🔹趋势一：模型与 Harness 的协同演化

通常的假设是：更强的模型 → 更简单的 Harness。但实际可能相反。

未来更可能是：基础模型变得越来越 “通才”，而 Harness 变得越来越 “专业”。不同场景需要不同的 Harness 设计。

　　

🔹趋势二：Harness 本身成为可优化的 “代码”

现在 Harness 主要是手工设计，未来可能会：

  • 从实际运行数据中自动学习最优的 Harness 配置
  • 用强化学习等方法自动优化
  • Harness 变成真正的 “工程化” 产物

　　

🔹趋势三：Harness 成为 AI 应用的 “基础设施”

就像操作系统是硬件和软件之间的桥梁，Harness 可能成为 AI 模型和应用之间的标准层。

未来可能出现：

  • 通用的 Harness 框架和工具库
  • 开源的 Harness 最佳实践