大家好，我是讯享网，很高兴认识大家。这里提供最前沿的Ai技术和互联网信息。



Harness Engineering 不是“把提示词写得更花”，而是为 AI Agent 设计一整套可运行、可约束、可验证、可恢复的执行环境。
当任务从“回答一个问题”升级为“持续完成一个真实任务”时，决定系统上限的不再只是模型本身，而是模型外面的这套 harness。

这篇文章主要讲什么

1. Prompt Engineering 解决的是“怎么把话说清楚”。
2. Context Engineering 解决的是“怎么把正确的信息在正确的时间送进去”。
3. Harness Engineering 解决的是“模型开始连续执行后，怎么让它长期稳定地做对”。

这三者不是相互替代，而是逐层外扩的关系：

• Prompt Engineering 是对指令表达的工程化。
• Context Engineering 是对输入环境的工程化。
• Harness Engineering 是对整个运行系统的工程化。

为什么这个概念会出现

早期很多 AI 应用主要是单轮问答或短链路任务。那时最关键的问题是：

• 模型有没有理解你的意思？
• 你的提示词是不是足够清晰？

后来 Agent 开始进入真实环境：

• 要调用工具
• 要访问外部数据
• 要跨多步执行
• 要处理中间状态
• 要根据反馈持续修正

第一阶段：Prompt Engineering

Prompt Engineering 的重点，是通过更好的指令表达，让模型更稳定地产生期望输出。

典型手段包括：

• 角色设定
• 输出格式约束
• 示例驱动
• 任务拆解
• 对成功标准的明确描述

它的边界也很清楚：

• 它擅长解决“表达问题”
• 它不直接解决“信息缺失问题”
• 它也不解决“长链路执行稳定性问题”

换句话说，提示词可以提升模型“单次推理”的表现，但很难单独支撑一个需要长时间运行的 Agent 系统。

第二阶段：Context Engineering

Context Engineering 把关注点从“怎么写提示词”，扩展到“推理时到底该给模型哪些 token”。

这意味着上下文工程不只是背景资料拼接，而是系统性管理：

• 系统提示
• 工具定义
• 外部检索结果
• 历史对话
• 当前任务状态
• 中间结论
• 长期知识与规则

典型实践包括：

• RAG：先检索，再按需注入相关知识
• 历史上下文压缩
• 运行时按需检索，而不是一开始塞满全部信息
• Progressive Disclosure：渐进式披露，只在需要时暴露更细的规则与能力
• 控制工具返回的粒度，避免上下文污染

Anthropic 特别强调了一个关键现象：context rot。
上下文越长，模型越容易丢重点、丢细节、误召回，注意力预算会越来越稀缺。因此，上下文优化不是“越多越好”，而是“越准越好”。

第三阶段：Harness Engineering

• 选错工具
• 误解工具返回
• 在长链路里慢慢漂移
• 对自己的结果过度乐观
• 在失败后无法恢复

Harness Engineering 解决的正是这些问题。

更准确地说，它是在模型外部构建一层运行系统，让 Agent 能够：

• 在明确边界内工作
• 看见自己工作的结果
• 被持续检查
• 在失败后回到稳定状态
• 把好的经验沉淀成以后可复用的规则

一个成熟 Harness 的六层结构

1. 目标与信息边界

模型必须先知道：

• 自己是谁
• 当前任务是什么
• 成功标准是什么
• 哪些信息是关键，哪些信息不该看

2. 工具系统与动作空间

模型要做事，必须有工具。

但真正重要的不是“工具数量多”，而是：

• 工具职责是否清晰
• 什么时候该调用，什么时候不该调用
• 返回结果是否可读、可压缩、可继续推理

Anthropic 在工具设计文章里强调过，很多失败并不是模型不会用工具，而是工具接口本身设计得不够清晰、不够抗误用。

3. 执行编排

Agent 不是单步机器，而是一个持续循环：

1. 理解目标
2. 判断当前信息够不够
3. 不够就获取信息
4. 生成下一步动作
5. 校验结果
6. 不满足要求就修正或重试

4. 状态、记忆与交接

长任务一定有状态管理问题。系统至少要分清三类东西：

• 当前任务状态
• 会话中的中间产物
• 跨会话保留的长期记忆或偏好

5. 评估、观测与验收

很多系统不是“做不出来”，而是“做完以后不知道自己做得对不对”。

因此 Harness 里必须有独立的评估层：

• 输出验收
• 环境验证
• 自动测试
• 日志、指标、链路追踪
• 错误归因

一旦 Agent 能直接看到页面、日志、指标和真实运行效果，系统就从“语言生成器”变成了“能观察自己行为结果的执行体”。

6. 约束、校验与失败恢复

这是生产级系统最关键的一层。

真实环境里，失败不是例外，而是常态：

• API 超时
• 检索失败
• 文档格式异常
• 工具输出不稳定
• 模型判断失误

成熟的 harness 必须回答三件事：

• 哪些行为允许，哪些行为禁止
• 在关键节点如何做前置或后置校验
• 一旦失败，如何回退、重试、切换路径或人工接管

OpenAI 的实践：把“环境可读性”做成系统能力

OpenAI 在 2026 年 2 月的 Harness engineering: leveraging Codex in an agent-first world 里，披露了一个很典型的 agent-first 工程案例。

其中最关键的不是“模型更强了”，而是他们把环境变成了 Agent 能直接理解和验证的对象。

1. 把仓库知识变成系统事实源

他们明确反对“一个超大的 AGENTS.md 包打天下”。

原因很直接：

• 上下文是稀缺资源
• 巨型说明文档会挤压真正重要的任务信息
• 内容会快速腐化
• 也很难做机械化校验

所以他们把 AGENTS.md 变成目录，而不是百科全书；真正的知识存放在结构化的 docs/ 中，并通过文档索引、计划文档、架构文档、质量文档等方式组织起来。
这本质上就是一种工程化的 progressive disclosure。

2. 让 Agent 能看见 UI、日志和指标

OpenAI 的一个关键动作是提高 application legibility，也就是让应用本身对 Agent 可读。

他们做了几件非常典型的事：

• 每个 worktree 都能独立启动应用
• 把 Chrome DevTools Protocol 接进 Agent 运行时
• 让 Agent 能处理 DOM snapshot、截图、导航
• 暴露日志、指标、trace 给 Agent 查询

结果是 Agent 不再只是“写代码然后自我感觉良好”，而是可以：

• 复现 bug
• 驱动页面
• 观察运行结果
• 查询日志和性能指标
• 修复后再次验证

这就形成了真正的反馈闭环。

3. 用架构约束和 lint，把“经验”变成系统规则

OpenAI 还强调了两类约束：

• 严格的分层架构和依赖边界
• 机械化的 taste invariants，例如日志规范、命名规范、文件大小限制、可靠性要求

4. 把“AI slop”治理成持续垃圾回收

后来他们把这件事也自动化了：

• 把黄金原则写进仓库
• 让后台 Agent 定期扫描偏差
• 自动开修复 PR

这本质上是一种持续的熵管理。

Anthropic 的实践：长任务里最难的是“别跑偏”

Anthropic 的两篇文章分别从 context engineering 和 long-running harness 两个角度，补足了这个话题。

1. 上下文不是仓库，而是预算

Anthropic 对 Context Engineering 的表述非常值得借鉴：

• 上下文是有限资源
• 不是所有相关信息都应该一次性塞进去
• 最重要的是维护“当前最有用的一小部分高信号 token”

因此他们更强调：

• 运行时按需加载
• 轻量引用而不是重型复制
• 最小可用工具集合
• 紧凑而高信号的系统提示

2. 长任务会出现 context anxiety

3. 自评通常不可靠，生产和验收要分离

Anthropic 还强调了另一个关键现象：self-evaluation bias。

他们的应对方式非常工程化：

• 生成者负责产出
• 评估者独立验收
• 评估者直接进入真实环境操作，而不是只看静态产物

在文中案例里，评估 Agent 拿到了 Playwright MCP，可以自己打开页面、操作页面、截图观察，再输出具体批评意见，反馈给生成 Agent 继续迭代。
这使得系统形成了一个真正有效的回路：生成、检查、修复、再检查。

Prompt、Context、Harness 到底是什么关系

可以把三者理解成三个嵌套层次：

• Prompt Engineering：如何表达任务
• Context Engineering：如何组织输入信息
• Harness Engineering：如何设计整个执行系统

• 工具
• 文档
• 工作流
• 状态
• 评估
• 观测
• 约束
• 恢复
• 长期治理

工程实践上的真正启发

如果你正在做 Agent，这篇内容最有价值的启发不是“记住一个新名词”，而是换一套排障思路：

• 当 Agent 表现不好时，不要只问“模型够不够强”
• 不要只问“提示词还能不能再调”
• 更应该问“环境里缺了什么结构性能力”

更具体一点，可以按下面的顺序排查：

1. 目标是不是足够清楚，成功标准是不是可验证
2. 模型是否拿到了当前步骤真正需要的信息
3. 工具接口是否清晰，返回是否可读可压缩
4. 是否有明确的执行循环，而不是一次性乱跑
5. 是否把状态、中间结果、长期记忆分开管理
6. 是否有独立评估与真实环境验证
7. 是否有失败恢复、约束和治理机制

最后的判断