跳转至

一文带你弄懂 AI 圈爆火的新概念：Harness Engineering

Ch05.011 一文带你弄懂 AI 圈爆火的新概念：Harness Engineering

📊 Level ⭐⭐ | 24.1KB | entities/一文带你弄懂-ai-圈爆火的新概念harness-engineering-v2.md

一文带你弄懂 AI 圈爆火的新概念：Harness Engineering

来源：code 秘密花园（ConardLi），2026-04-03，公众号一文读懂 Harness Engineering → 原文存档

摘要

文章从三次重心迁移（Prompt → Context → Harness）+ 六层 Harness 构成 + OpenAI/Anthropic/LangChain 一线实践三个角度系统阐释 Harness Engineering 概念。核心断言："真正决定 AI 产品上限的是模型，但真正决定 AI 产品能否落地的，往往是 Harness。"

核心要点

  • 三次迁移对应三个本质问题：(1) 模型是否听得懂你在说什么 (2) 模型是否拿到了足够且正确的信息 (3) 模型是否能在真实执行中持续做对
  • LangChain 经典定义：Agent = Model + Harness / Harness = Agent - Model
  • Harness 六层构成：上下文管理 / 工具系统 / 执行编排 / 状态与记忆 / 评估与观测 / 约束·校验·失败恢复
  • 3 个顶尖公司案例数据点：OpenAI 5 人工程师 + Codex 100% 产出百万行生产代码；Anthropic 长程任务连续运行数小时；LangChain 不动模型改 Harness 把 Terminal Bench 2.0 分数从 52.8 拔到 66.5（Top 30 → Top 5）
  • 两个新概念区分：Context Compaction（同一 Agent 历史变短） vs Anthropic 的 Context Reset（新 Agent 干净上下文 + 工作交接）
  • 核心工程原则：生产与验收必须分离（generator + evaluator 模式，扩展为 planner + generator + evaluator）
  • OpenAI 渐进式披露：AGENTS.md ~100 行充当"目录页"指向详细文档（ARCHITECTURE.md / design-docs / exec-plans / product-specs / QUALITY_SCORE.md / SECURITY.md），CI 自动校验文档新鲜度
  • 架构治理系统化：把资深程序员的经验判断写成机器可执行的检查规则（Types / Config / Repo / Service / Runtime / UI 分层 + 修复提示 + 后台持续扫描 Agent）

深度分析

一、三次重心迁移的内在逻辑

1.1 Prompt Engineering：表达问题

核心思想：模型不是不会，而是没把问题讲清楚。优化指令本身就是第一步工程优化。

代表性方法：角色设定（限定专业视角）/ 风格约束（限定表达）/ Few-shot（模仿范式）/ 分步引导（减少拍脑袋）/ 格式约束（提升可用性）/ 拒答边界（划红线）。

为什么有效：大模型本质是对上下文极度敏感的概率生成系统，不是"命令行"而是"临时搭建的认知场"。给什么身份、按什么例子采样、强调什么约束决定高权重信号——Prompt Engineering 的本质是塑造局部概率空间。

天花板：很多任务不是"你说清楚就行"，而是"你得真的知道"——分析公司内部文档 / 产品最新配置 / 长规范生成代码 / 多工具复杂任务。提示词再漂亮不能替代事实本身。Prompt 解决的是表达问题，不是信息问题。

1.2 Context Engineering：信息问题

核心假设反转：模型未必知道，所以系统必须在调用时把正确信息送进去。新问题：模型现在看到了什么？没看到什么？哪些信息该提前给 / 延后给？哪些完整保留 / 摘要压缩？哪些对当前模块可见 / 被隔离？

Context 的工程定义：不是附加文本，而是所有会影响模型当前决策的信息总和——当前用户输入、整个任务历史对话、外部知识检索结果、工具调用返回、当前任务状态、工作记忆与中间产物、系统规则与安全约束、其他 Agent 传过来的结构化结果。Prompt 只是 Context 的一部分。

典型实践：RAG（解决了"模型参数里没有的知识怎么在运行时补进去"）+ Agent Skills（渐进式披露：元数据层 ~50 token / 指令层 ~500 token / 资源层按需加载）。Skills 机制将模型在复杂 Agent 场景下的上下文利用率提升数倍。

Context Engineering 的局限：Prompt 和 Context 都主要作用在"输入侧"，但真实世界复杂任务还有一个更难的问题——当模型开始连续行动时，谁来持续监督它、约束它、纠正它？

1.3 Harness Engineering：执行问题

词源：Harness = 缰绳、马具、约束装置。当模型从"回答问题"走向"执行任务"，系统不能只负责喂信息，还必须负责驾驭过程。

通俗类比（新人完成重要客户拜访）： - Prompt Engineering = 见面先寒暄、再介绍方案、再问需求、最后确认下一步（说清楚） - Context Engineering = 客户背景、过往沟通记录、产品报价、竞品、会议目标（给资料） - Harness Engineering = 让他带着 checklist 去、关键节点实时回报、会后核对纪要与录音、出现偏差立即纠正、按明确标准验收（建立观测/纠偏/验收机制）

三层关系：层层递进而非替代。Prompt 是对"提示词"的工程化；Context 是对"输入环境"的工程化；Harness 是对"整个运行控制系统"的工程化。边界一层比一层大，后者天然包含前者。

任务复杂度逼出技术重心迁移：任务简单 → Prompt 就够；任务复杂到上下文不够用 → Context 成为核心；任务变成持续执行/长链路/低容错 → Harness 不可避免。

二、Harness 的六层构成

2.1 第一层：上下文管理

职责：让模型在正确的信息边界内思考。

  • 角色与目标定义：让模型先知道自己是谁、任务是什么、成功标准是什么（"写一篇文章"是技术科普还是产品宣传？面向小白还是工程师？允许类比/口语化吗？这些不是文风细节，而是任务边界）
  • 信息选择与裁剪：上下文不是越多越好——大模型常见问题不是"知道太少"而是"信息太杂"。好 Harness 把相关信息挑出来，把不相关挡在外面
  • 上下文的结构化组织：同样的信息堆成一团和按层次组织效果天差地别，显著降低模型"看漏重点"或"忘记约束"的概率

2.2 第二层：工具系统

工具让模型从"回答问题的人"变成"做事情的人"。Harness 在这里解决三个更深的问题：

  • 给模型什么工具：工具太少能力不够，太多模型容易乱用。工具设计不是"越全越好"而是围绕任务场景配置（写作 Agent vs 安全分析 Agent 工具集不同）
  • 什么时候调用工具：糟糕 Agent 出现两种极端——本来不需要查非要查 / 明明该查证却凭印象乱答。好 Harness 引导模型判断：问题是否需要外部信息？当前上下文是否足够？这步更适合搜索/读取/计算还是直接作答？
  • 如何把工具结果重新喂回模型：搜索十条结果不应原封不动塞回去，Harness 帮助模型提炼有效证据、保持结果与任务的关联性

2.3 第三层：执行编排

很多失败 Agent 不是因为不会某一步，而是因为不会"串起来"。完整任务流程：理解目标 → 判断信息是否足够 → 必要时获取外部信息 → 基于结果继续分析 → 生成输出 → 检查输出是否满足要求 → 不满足则修正或重试。

成熟 Harness 不只是"能调工具"，而是具有明确的：步骤划分 / 决策节点 / 中间产物 / 终止条件 / 异常处理逻辑。区别于人的"经验习惯"，Agent 需要 Harness 明确搭好轨道。

2.4 第四层：状态与记忆

回答三个问题：(1) 当前任务进行到哪一步（已完成资料收集/正在撰写提纲/已生成初稿待校验/某个工具调用失败待重试）？(2) 哪些中间结果应该保留（已确认的需求约束/重要结论/已筛选的资料/已完成的子任务）？(3) 哪些内容应该形成长期记忆（用户偏好/稳定规则/长期项目背景/常用输出模板）？

记忆不是"存得越多越好"，要区分：临时状态 / 会话记忆 / 长期偏好。三者混在一起系统会越来越乱，分得清 Agent 才像靠谱的协作者。

2.5 第五层：评估与观测

很多系统的问题不是"生成不出来"而是"生成完了却不知道好不好"。这一层包括：输出验收（是否满足任务要求）/ 环境验证（是否真的可运行可点击可交互）/ 自动测试（代码/接口/页面/文档格式）/ 过程观测（日志/指标/调用链/重试记录）/ 质量归因（问题到底出在模型/上下文/工具还是流程设计）。

2.6 第六层：约束、校验与失败恢复

真正让系统从"能跑"走向"能上线"的往往不是主流程而是异常流程（真实环境失败才是常态）：搜索结果不准 / API 超时 / 文档格式混乱 / 模型误解指令 / 输出不符合约束 / 工具权限不足。

  • 约束：限制模型可做和不可做的事（哪些工具能用、哪些场景必须查证、哪些内容涉及安全边界）
  • 校验：在输出前做检查（是否回答了用户问题、是否遗漏关键要求、是否满足格式规范）
  • 恢复：一步失败时分析错误原因、重试同一步、切换备用路径、回退到上一个稳定状态

这部分最像传统软件工程里的"鲁棒性设计"。

三、业界三家代表性实践

3.1 Anthropic：长程任务的上下文焦虑 + 自评失真

两个典型问题： 1. 上下文焦虑：任务一长上下文窗口越来越满，模型开始丢细节丢重点——模型接近上下文窗口极限时会"焦虑地"想赶紧收尾 2. 自评失真：模型做完后再让它自己评判往往偏乐观，尤其在设计/体验/产品完整度这类没有绝对二元答案的问题上偏差更明显

实践一：Context Reset（替代 Compaction） - Compaction：同一 Agent 历史变短但"心理状态"延续 - Reset：直接换干净上下文的新 Agent，但两个模型交班时要把工作交接清楚

Anthropic 发现对某些模型（如 Claude Sonnet 4.5）仅靠压缩不能解决"上下文焦虑"，真正 Reset 才能给模型"清空包袱重新出发"——很像工程里的进程重启与状态恢复，不是所有内存泄漏都能靠"清理缓存"解决。

实践二：引入 Evaluator（生产与验收必须分离） - Planner：把一句很短的需求扩展成完整产品规格 - Generator：逐步实现 - Evaluator：像 QA 一样用浏览器和工具真实操作应用，检查功能/设计/代码质量（不是"读代码打分"，是"带环境的验证"）

实现"生成—检查—修复"工程循环。

3.2 OpenAI：Agent-first 世界的工程师角色重定义

铁律：人类不写代码，只设计环境。工程师核心工作三件事： 1. 拆解意图：把产品目标拆成 Agent 能理解的小块任务 2. 补全能力：Agent 失败时不是"再试一次"而是问"环境里缺了什么让它失败了"然后把缺的东西补上 3. 建立反馈回路：让 Agent 能看到自己工作的结果而不是盲人摸象

核心方法论："当出了问题，修复方案几乎从来不是'更努力'，而是'缺了什么结构性的能力'。"

渐进式披露（避免塞满 AGENTS.md） 早期错误：写一个巨大的 AGENTS.md 把所有规范架构约定一股脑塞进去，Agent 反而更迷糊——上下文窗口是稀缺资源，塞太满等于什么都没说。最终方案： 

AGENTS.md         ← 入口，只有指针（~100 行）
ARCHITECTURE.md   ← 架构总览
docs/
├── design-docs/  ← 设计文档（带验证状态）
├── exec-plans/   ← 执行计划（活跃/已完成/技术债务）
├── product-specs/← 产品规格
├── references/   ← 第三方参考
├── QUALITY_SCORE.md ← 各模块质量评分
└── SECURITY.md
CI 自动校验文档新鲜度和交叉引用 + 专门的"文档园丁"Agent 定期扫描过时文档提 PR 修复——知识管理本身也自动化。

让 Agent "看见" 整个应用 产代码速度上去后瓶颈从"写"变成"验"——人类根本验不过来。OpenAI 的解法：让 Agent 自己验。单次 Codex 运行经常连续工作 6 小时以上（通常在人类睡觉时），Agent 自己跑应用/发现 bug/修复/验证/提 PR 一条龙。

架构治理系统化 人类 Code Review 带宽跟不上 Agent 产出（每人每天 3.5 个 PR）→ 把资深程序员的经验判断写成机器可自动执行的检查规则： - 业务代码按固定分层：Types / Config / Repo / Service / Runtime / UI - 规则不只是负责报错还会告诉 Agent 该怎么改（检查结果带修复提示回到上下文推动下一轮修改） - 后台 Agent 持续扫描代码库：检查哪些模块正在变乱 / 给不同区域打质量分 / 找出值得重构的部分 / 直接提交修复或重构 PR

架构治理从"靠人盯"变成"靠规则守 + 持续运行的系统"，价值是趁问题还小的时候就把它修掉。

3.3 LangChain：Harness Engineering 的实证收益

LangChain 在底层模型完全不变的情况下仅仅通过改造和迭代 Harness，就把自家代码智能体在 Terminal Bench 2.0 榜单上的得分从 52.8 拔高到 66.5，直接从 Top 30 开外杀入 Top 5。这是 Harness Engineering 价值的硬数据证明。

3.4 三家公司的本质收敛

表面路径不同（Anthropic 偏上下文/评估；OpenAI 偏渐进式披露/架构治理；LangChain 偏评分优化），但本质都在补同一套东西： 1. 模型到底应该看到什么（Context） 2. 模型到底能做什么（Tools） 3. 模型下一步该做什么（Execution） 4. 系统如何保持连续工作（State/Memory） 5. 系统怎么知道自己做得对不对（Evaluation） 6. 系统出错后怎么拉回来（Constraint/Recovery）

Anthropic 补强的是上下文管理 + 执行编排 + 评估与观测；OpenAI 补强的是上下文管理 + 工具系统 + 评估与观测 + 约束与恢复。

四、Harness Engineering 的本质重新定位

文章结尾给出三个层次的断言：

  1. 模型 vs Harness 的分工：模型能力上限由 OpenAI / Anthropic 决定，Harness 由我们这些工程师来决定
  2. 决定落地的不是模型：决定 AI 产品上限的是模型，但决定 AI 产品能否落地、稳定交付的往往是 Harness
  3. 未来竞争焦点：未来 AI 工程的竞争未必只是"谁接入了更强的模型"，而更可能是谁更早建立起一套成熟的运行系统

Harness Engineering 的核心信号：AI 落地的核心挑战，正在从"让模型显得聪明"，转向"让模型在真实世界里稳定工作"。

实践启示

  • 遵循 "harness first, prompt second"：调优 Agent 时先评估 harness 层面而非反复改 prompt
  • 同一模型不同 harness 效果差几个数量级：LangChain Terminal Bench 2.0 分数从 52.8 → 66.5 是硬证据，prompt 调优做不到
  • 渐进式披露而非塞满文档：AGENTS.md/CLAUDE.md 只做目录，详细文档分散在 docs/ 子目录并通过 CI 自动校验
  • 生产与验收必须分离：planner + generator + evaluator 三层结构，evaluator 用工具真实操作而非"读代码打分"
  • Context Reset 优于 Context Compaction：长程任务一昧压缩会让模型"焦虑"，干净上下文 + 工作交接才是真正的清空
  • 架构治理系统化而非人工盯：把经验判断写成可执行的检查规则 + 后台持续扫描 Agent
  • 工程师角色转变：从 prompt engineer 转为 harness engineer——拆解意图 + 补全能力 + 建立反馈回路
  • 重视失败恢复设计：约束 + 校验 + 恢复三件套是 harness 第六层核心

相关实体