Harness Engineering

我这段时间反复看了这支视频，也对照了 OpenAI、Anthropic 在 2025-2026 年公开的实践，最大的感受是：

AI 工程的重心，正在从“怎么写一句好 prompt”，移动到“怎么把 agent 放进一个能稳定工作的运行系统里”。

我踩过的坑很典型：多步任务里提前宣布完成、工具失败后乱跳步骤、上下文一长就丢目标。问题不在“模型不够强”，而在“运行框架太薄”。

从 Prompt 到 Context，再到 Harness

先把三个阶段拆开看，会更清楚：

Anthropic 讲 Context Engineering 时，已经把问题从“写一句话”扩展到“维护整组上下文状态”。到 2026 年，OpenAI 和 Anthropic 又进一步强调：拉开 Agent 差距的，通常是整套 harness，而不只是 prompt 或 context。

Harness 到底是什么

我更倾向于用 Anthropic 那句定义：

agent harness 是让模型作为 agent 运作的系统。它负责处理输入、编排工具调用，并返回结果。

这句话先排除了两个常见误解：

• Harness 不是模型本身。
• Harness 也不只是 prompt 模板或工具清单。

我更愿意把它翻译成一句工程话：

Harness 是包在模型外面的那层执行系统，它把“会推理的模型”变成“能持续完成任务的 agent”。

举个任务：

帮我定位登录页报错，修复它，跑测试，最后给出修改说明。

模型负责推理，harness 负责把推理变成连续动作：

接收任务
  -> 提供可用工具
  -> 决定是否调用工具
  -> 执行工具
  -> 回填结果
  -> 保留中间状态
  -> 触发自检/测试/评审
  -> 在满足退出条件后结束

没有这一层，模型更像“会说话的接口”，而不是“能持续干活的人”。

一个 Harness 通常包含什么

视频里“构成”这段很关键。Harness Engineering 本质上就是把容易被忽略的工程件补齐。

1. 任务入口

入口不是“把需求贴给模型”，至少要写清楚：

• system prompt 或角色设定
• 初始约束
• 成功标准
• 可用资源和权限

我自己的经验是，入口模糊时，后面的 loop 越复杂，跑偏越稳定。

2. 工具层

工具层决定 agent 能不能动手：

• 读写文件
• 执行命令
• 浏览网页
• 调数据库
• 调 MCP Server 或浏览器自动化

Prompt 影响“怎么说”，Tool 决定“能不能做”。Harness 的职责，是把能力暴露得安全、稳定、低歧义。

3. Agent Loop

Agent Loop 是心脏，最基础就是一个迭代循环：

1. 读取当前任务和状态
2. 让模型判断下一步
3. 如果需要，调用工具
4. 读取工具结果
5. 继续推理
6. 直到结束

我第一次做时也以为一个 while 就够，后来发现难点在策略：

• 什么时候该继续，什么时候该停
• 工具失败后怎么恢复
• 任务做一半时怎么避免“宣布胜利”
• 上下文太长时怎么压缩或重开 session
• 多轮执行时怎么做交接

这些问题不会靠“换更强模型”自动消失。

4. 状态与上下文管理

状态管理是最容易被低估的一块。Anthropic 提到的 initializer agent -> coding agent 分工很值得借鉴：先搭环境和进度骨架，再做增量推进，并强制留下交接记录。

这背后的核心很朴素：

长任务做不稳，很多时候不是模型不会，而是 session 之间没有可靠交接。

所以我现在会维护这些资产：

• progress 文件
• feature checklist
• 中间产物
• git 提交或阶段快照
• 结构化计划
• 压缩后的上下文摘要

5. 验证与反馈回路

我现在判断一个系统是不是“真 Agent”的标准很简单：它有没有验证闭环。

只会调工具但不会验证，通常只是自动化脚本。

OpenAI 那篇文章给我的启发是，不是让模型“写更多”，而是让它“看见更多反馈”：

• UI 可被直接驱动
• 日志、指标、trace 可被查询
• 仓库文档可被检索
• review 和反馈可进入下一轮执行

Anthropic 讲的 planner -> generator -> evaluator 也一样，重点在 evaluator: 把“说不清的质量要求”变成可执行反馈。

团队差距往往不在工具数量，而在闭环质量。

6. 权限、安全与退出条件

Agent 一旦能执行命令、改文件、发请求，就必须有边界。

Harness 往往需要明确：

• 哪些目录可读写
• 哪些命令可执行
• 什么时候需要人工确认
• 什么情况下直接停止
• 最终产出要满足哪些检查

所以 Anthropic 在 Managed Agents 里把 harness、runtime、sandbox 放在一起讲，我觉得很合理。

为什么 Harness Engineering 现在突然这么重要

因为行业目标已经从“回答问题”变成“完成任务”。瓶颈也随之变化：不再只看 prompt 和上下文，而是看 Agent 在真实环境里能不能持续做对动作。

OpenAI 的观点我很认同：工程师重心会越来越偏向设计环境、表达意图、建立反馈回路。

它和 Prompt、Context、Tool、MCP 的关系

这几个概念容易混。看这张表就清楚了：

Harness 不是替代 Prompt 或 Context，而是更外层的编排层：

意图通过 Prompt 表达
信息通过 Context 维护
能力通过 Tool / MCP 边界
整个运行逻辑通过 Harness 协调

换个角度说，Prompt 搞定"说什么"，Context 搞定"看什么"，Harness 才搞定"怎么干"。

结合视频，普通开发者最该学什么

我更关心“看懂后怎么落地”。下面这 5 件事可以马上做。

1. 不要只写 prompt，要写成功标准

我现在下任务会先写退出条件：

• 复现路径是什么
• 修完后要通过哪些测试
• 页面上应该看到什么结果
• 不允许改动哪些模块

这样 agent 知道什么时候该停。

2. 给 Agent 留结构化工位

任务一旦超过 30 分钟，我就默认要有“工位文件”：

• PLAN.md
• progress.md
• todo.json
• 验收 checklist

这是最轻量、但很有用的 harness 资产。

3. 把验证能力接进来

常见问题不是“不会做”，而是“做完不验”。优先接这些验证链路：

• 测试命令
• lint
• 日志查询
• 页面截图或浏览器自动化

4. 把知识沉到仓库里

Agent 看不见的东西，对它来说就不存在。 所以规则要尽量沉到仓库：

• 仓库内文档
• 设计决策记录
• 规范文件
• 可执行脚本

5. 让 Harness 尽量简单，但要闭环

Anthropic 的提醒也很关键：harness 每多一个组件，都是在编码一种会过时的假设。

所以我的策略不是堆复杂度，而是：

• 先做最小可用 loop
• 只在真实失败点上补机制
• 每次新增组件都问一句：它是不是还在提供真实价值

一个更实用的判断标准

以后再听到别人聊 Harness Engineering，我会先问这三个问题：

1. 这个系统给了 Agent 什么可执行能力？
2. 它怎么维护多轮状态和交接？
3. 它怎么验证结果并决定继续还是停止？

这三件事说不清，通常还停留在“Prompt + Tool Use”阶段。

最后总结

看完这支视频，再对照 OpenAI 和 Anthropic 的公开实践，我现在的结论是：

它不是一个营销词，也不是 Prompt Engineering 的同义替换；它描述的是一整套围绕 Agent Runtime 的工程工作，目标是让模型在真实环境中稳定、可控、可验证地完成多步任务。

我不太把 Harness Engineering 当成新名词，而把它当成一个工程提醒：

到了 Agent 阶段，真正的杠杆不只在语言，而在系统。