什么是 Harness
Harness 是 AI Agent 系统中除模型以外的所有运行框架
Harness Engineering是AI工程领域最近爆火的一个概念。它解决了一个非常现实的问题：为什么同样的模型别人做出来的Agent可以连续跑很久、成功率很高，到了自己手里就总是差强人意？
LangChain给出了一个非常简洁的定义：Agent = Model + Harness，或者说 Harness = Agent - Model。翻译成人话就是：在一个Agent系统里，除了模型本身以外，几乎所有能决定它能不能稳定交付的东西都可以算进Harness。
Harness的核心职责是驾驭整个过程。当模型从回答问题走向执行任务，系统不只要能够负责微信息，还要能够管理执行流程、监督状态、处理异常、确保最终交付质量。
🔄 三次重心迁移
过去两年 AI 工程经历了三次明显的重心迁移，这三个词分别对应了 AI 系统发展的三个阶段性问题
Prompt Engineering
模型有没有听懂你在说什么？
关注点：指令表达、角色设定、输出格式。本质是塑造概率空间。
Context Engineering
模型有没有拿到正确的信息？
关注点：信息检索、文档切分、动态上下文。本质是按需供给信息。
Harness Engineering
模型在真实场景能不能持续做对？
关注点：执行监督、状态管理、容错恢复。本质是驾驭整个过程。
"真正决定系统能不能稳定跑的，往往不是模型本身，而是模型外面那套运行的系统 — 这套东西现在有了一个统一的名字就叫 Harness"
💡 一个通俗的比喻
假设你要派一个新人去完成一次很重要的客户拜访
Prompt Engineering
告诉他先把任务讲清楚：见面先寒暄，再介绍方案，再问需求，最后确认下一步。
重点：把话说明白
Context Engineering
告诉他把资料准备齐全：客户背景、过往记录、产品报价、竞品情况、会议目标。
重点：把信息给对
Harness Engineering
让他带着 CheckList，关键节点实时汇报，会后核实纪要和录音，发现偏差马上纠正。
重点：持续观测、纠偏、验收
⚠️ 重要结论
这三者不是替代关系，而是包含关系：Prompt 是对指令的工程化，Context 是对输入环境的工程化，Harness 是对整个运行系统的工程化。边界一层比一层大。
🔬 LangChain 的定义
Harness = Agent - Model
在一个 Agent 系统里，除了模型本身以外，几乎所有能决定它能不能稳定交付的东西都可以算进 Harness。
"当模型从回答问题走向执行任务，系统不只要能够负责微信息，还要能够驾驭整个过程。"
"如果前两代工程关注的是怎么让模型更会响应，那 Harness 更关注的就是怎么让模型别跑偏、跑得稳，出了错还能拉回来。"
🏗️ Harness Engineering 六层架构
一个成熟的 Harness Engineering 可以分为六层，每一层都有其独特的作用和实现方式
1. Context Management
模型能不能稳定发挥很多时候不仅取决于它聪不聪明，而取决于它看到了什么。
- 角色目标和定义：知道自己是谁、任务是什么
- 信息裁剪和选择：越相关越好
- 结构化组织：分层清楚，信息不乱
2. Tool System
没有工具，大模型本质上还是一个文本预测器。一旦连上工具，模型才可以真正做事。
- 给什么工具：太少能力不够，太多会乱用
- 什么时候调用：该查时别乱查，该查时别遗漏
- 结果处理：提炼筛选，保持相关性
3. Execution Orchestration
很多 Agent 的问题不是某一步不会，而是不会把所有的步骤给串起来。
- 理解目标：明确任务是什么
- 检查信息：不够继续补
- 生成输出：不满足就重新修正或重试
4. Memory & State
没有状态的 Agent 每一轮都会像失忆一样，不知道自己刚做了啥。
- 当前任务的状态
- 会话中的中间结果
- 长期的记忆和用户偏好
5. Evaluation & Observation
很多系统不是生成不出来，而是生成完了之后根本不知道自己做的好不好。
- 输出和验收环境的验证
- 自动的测试、日志和指标
- 错误的归因
6. Constraint & Recovery
在真实环境里，失败不是例外，而是常态。
- 约束：哪些能做，哪些不能做
- 校验：输出之前、之后要怎么检查
- 恢复：重试、回滚到稳定状态
🏢 一线公司的真实实践
Anthropic 的实践
构建完全自主编码的系统
问题一：上下文焦虑 (Context Anxiety)
时间一长上下文越来越满，模型开始丢细节、丢重点，甚至出现"着急收尾"的现象。
🔄 Context Reset 上下文重置
不是在原上下文里继续压缩，而是换一个非常干净的新的 Agent 把工作交接给它。这个思路很像工程里遇到内存泄露后直接重启进程再恢复状态。
问题二：自评失真
模型自己干活再自己打分，往往会过于乐观。
👥 生产验收分离
他们采用三角色拆分：
- Planner：负责把模糊需求扩展成完整规格
- Generator：负责逐步实现
- Evaluator：负责像 QA 一样真实测试
OpenAI 的实践
用 Agent 从零构建百万行代码的生产级应用
🔑 重新定义工程师的工作
人类不需要写一行代码，只需要负责设计环境：
- 把产品目标拆解成 Agent 能理解的小任务
- Agent 失败的时候，不是让它更努力，而是问"环境里面缺了什么能力"
- 建立反馈链路，让 Agent 真正能够看到自己的工作结果
💡 核心思维
"当 Agent 出了问题时，修复方案几乎从来不是要更努力一点，而是确定它缺了什么样的结构性的能力。" — 这是典型的 Harness 思维。
🚀 Agent 看见整个应用
产业速度一旦上来，瓶颈不再是写，而是验。让他们自己验：
- 接浏览器：能截图、点页面、模拟用户真实操作
- 接日志和指标系统：能查 Log、查监控
- 每个任务独立隔离环境运行，互不影响
LangChain 的实践
底层模型完全不变，只通过改造 Harness 提升排名
在底层模型完全不变的情况下，只通过改造和迭代 Harness，就把他自家的智能体验从一个榜单上的排名直接从 30 开外杀到了前五。
💡 渐进式披露 (Progressive Disclosure)
他们早期犯过一个错误：写了一个巨大的 Agent README，把所有规范、框架、约定全部塞进去，结果 Agent 更糊涂了。
后来改进：把 Agent README 变成目录页，页面只保留核心索引，详细内容拆到子文档里。Agent 先看目录，需要的时候再钻进去。
🎯 核心设计原则
渐进式披露
不是一开始就把能力全部给模型看，而是只给他看最少量的原信息，等他真正要触发某些能力的时候，再把那部分的 SOP、详细参考信息、脚本动态加进来。
生产验收分离
干活的人和验收的人必须分开。只要评估者足够独立，系统就能形成一个真正的有效循环：生成 → 检查 → 修复 → 再检查。
环境能力补全
Agent 失败的时候，不是让它更努力一点，而是问"环境里面缺了什么能力"。这是典型的 Harness 思维：修复方案是结构性的能力补充。
自我感知能力
系统不仅要会做，还要知道自己有没有真的能够做对。没有独立的评估和观测能力，Agent 就会长期停留在自我感觉良好的状态。
🎯 为什么评估如此重要
评估是对 AI 系统进行量化考核的手段，能够衡量其在给定任务上的表现
AI Agent 的非确定性挑战
不同于传统软件的确定性输出，AI Agent 具有非确定性特征——为达成目标可能有多种不同的实现方式。传统的软件测试方法无法有效应对这种灵活性。
自动化评估可以容忍并适应这种特性，帮助避免在产品规模化过程中因无法预见的问题导致的崩溃，并且在模型升级时提供快速切换和验证新模型稳定性的能力。
📋 评估体系的构成
评估体系由任务组、评分器以及评估框架和代理框架等基础设施组成
任务组 (Task Suite)
任务组成了整个"试卷"，定义了 Agent 需要完成的各种测试场景和目标。
- 多样化测试场景覆盖
- 真实世界任务模拟
- 难度梯度设计
评分器 (Scorer)
评分器负责为 Agent 的表现打分，评估任务完成的准确性和质量。
- 自动化结果验证
- 多维度评分标准
- 一致性评价体系
评估框架
评估框架下发指令并行运行测试，收集记录分数。
- 并行测试执行
- 结果收集与分析
- 指标可视化报告
代理框架
代理框架包装模型，处理输入和工具调用，是 Agent 的运行环境。
- 模型输入输出管理
- 工具调用编排
- 状态与记忆管理
💡 关键认知
最终评估的是 模型 + 代理框架 的整体表现。这意味着优化评估成绩，不仅可以改进模型本身，还可以通过改进 Harness（代理框架）来提升系统性能。
📊 演进总结
| 阶段 | 核心问题 | 关注点 | 本质 |
|---|---|---|---|
| Prompt | 模型有没有听懂你在说什么 | 指令表达、角色设定、输出格式 | 塑造概率空间 |
| Context | 模型有没有拿到正确的信息 | 信息检索、文档切分、动态上下文 | 按需供给信息 |
| Harness | 模型在真实场景能不能持续做对 | 执行监督、状态管理、容错恢复 | 驾驭整个过程 |
🎯 最终目标
Agent = Model × Harness
同样的模型，通过改进 Harness，可以把成功率从 70% 拉到 95% 以上。