拟定标题

我原来写的项目规则、Skill、知识库，其实已经是在做 Harness Engineering

拟定摘要

很多人把 Harness Engineering 理解成更复杂的 Prompt Engineering，但如果最近看过 OpenAI、Anthropic 和一些社区讨论，会发现这不是一回事。Harness 关注的不是一句话怎么写，而是如何给 agent 搭一个可持续工作的环境：任务怎么拆、上下文怎么管、工具怎么接、结果怎么验、失败怎么回灌、经验怎么沉淀。回头看我之前写过的项目规则、Skill、经验库和 wiki，其实已经在零散地做这件事了。

正文

最近在看 Harness Engineering 相关资料，越看越觉得，这个词有点像之前的 “Context Engineering” 一样，容易被大家拿来当新概念转一圈，但真正落到实践里，它其实没有那么玄。

我自己一开始也有点误解，以为所谓 Harness，无非就是 Prompt 写得更长一点，规则写得更细一点，或者给 Agent 多塞一点上下文。后来把几份资料连着看下来，感觉不是这么回事。

如果要用一句我现在更能接受的话去概括：

Harness Engineering 不是教模型怎么回答问题，而是给 Agent 搭一个能持续干活的环境。

这个环境里面，模型当然很重要，但它已经不是全部了。更关键的是：

  • 任务怎么拆
  • 上下文怎么组织
  • 工具怎么接
  • 结果怎么验证
  • 失败之后怎么回灌
  • 多个 Agent 怎么协作
  • 做过一次的经验，怎么沉淀下来，下次别从零开始

看到这里我突然意识到，原来我之前写的很多东西，虽然当时没用 Harness Engineering 这个词，但其实已经在做它的局部实现了。

一、为什么现在大家开始谈 Harness Engineering

过去一段时间，很多人讨论 AI Coding，主要还是围绕 Prompt 展开。比如：

  • 这句提示词怎么写更好
  • 角色怎么设定
  • 要不要加约束
  • 要不要给更多上下文

这些东西当然有用，我自己也写过类似内容，比如项目规则怎么写、任务怎么拆、怎么给 Agent 设边界。

但是只要真正把 Agent 用到项目里，就会很快发现一个问题：

Prompt 再漂亮，也顶不住真实工程环境的复杂度。

原因很简单，真实开发不是一道问答题，而是一整段工作流。

你让 Agent 改一个功能，它不是只需要“输出一段代码”就完事了。它还要面对这些问题：

  • 它知道要改哪些文件吗
  • 它知道这个项目的业务背景吗
  • 它知道哪些地方不能碰吗
  • 它改完之后怎么验证自己没改坏
  • 它跑错了之后，能不能读日志继续修
  • 它遇到长任务时，是一次做完，还是拆成多个阶段
  • 它这次踩过的坑，下次还能不能记住

也就是说，真正决定 Agent 上限的，慢慢就不是模型本身，而是你给它搭了一个什么样的“工作现场”。

这就是我目前理解的 Harness。

二、Harness 不是 Prompt 的升级版，而是系统设计

如果按层次去理解，我现在更倾向于把它分成三层：

1. Prompt Engineering

关注的是一句话怎么写。

比如你是让它“优化一个组件”，还是告诉它“你现在是一个资深前端工程师，请基于现有组件结构优化这个组件，并补充测试和错误处理”。

这是输入层面的优化。

2. Context Engineering

关注的是给模型什么信息。

比如项目规则、技术栈说明、目录结构、业务背景、历史文档、相关代码、过往经验等，本质上是在解决：

模型现在知道什么。

3. Harness Engineering

关注的是整个运行环境怎么设计。

本质上是在解决：

模型现在可以怎么工作。

这个差别很关键。

因为当我们说 Prompt 或 Context 的时候，本质上还是在“喂输入”；而说 Harness 的时候，已经开始进入“搭系统”了。

也正因如此，Harness 的关注点通常会变成这些更工程化的问题：

  • 有没有 agent loop
  • 有没有 tools
  • 有没有 plan
  • 有没有 verification
  • 有没有 memory
  • 有没有 permission gate
  • 有没有日志、UI、测试这些反馈回路

我觉得这就是为什么最近这个概念会火起来。不是大家突然发明了什么新东西，而是 AI Coding 发展到这一步，很多人都碰到了同一堵墙：

只调提示词，已经不够了。

三、我最认同的 Harness 视角：让 Agent 不只是“会写”，还要“会推进”

看完几份资料后，我印象比较深的是两种路线。

1. OpenAI 这条路线，更像“把工程环境整理成 Agent 能工作的样子”

我自己的理解是，OpenAI 更强调一件事：

不要把仓库只当成人看的代码容器，而要把它整理成 Agent 也能读、也能用、也能持续维护的 system of record。

这个思路特别打动我，因为它不是在说“再发明一个超强 agent”，而是在说：

  • 让 AGENTS.md 保持简洁，像一张地图
  • 把真正稳定的知识放进结构化文档
  • 让 UI、日志、指标、追踪都能成为反馈回路
  • 用 lint、CI、文档机制保证知识不会很快腐烂

这套思路有个很大的优点，就是它很现实。

因为大部分团队已经有仓库、文档、测试、日志、CI，只是以前这些东西主要是为人服务。现在要做的，是把它们重新组织一下，让 Agent 也能在里面生存。

2. Anthropic 这条路线，更像“把开发流程本身显式建模出来”

Anthropic 那篇文章给我的感受是，harness 在他们那里更像一个完整的软件开发流水线。

它不是简单地让一个 Agent 从头干到尾，而是通过不同角色配合：

  • planner 负责扩展需求
  • generator 负责实现
  • evaluator 负责 QA 和验收

最关键的地方不是“多 Agent”这件事本身，而是它把两个平时在团队里很重要、但在单 agent 场景里经常缺失的能力补上了：

  • 契约
  • 验证

也就是 generator 不是接到一句模糊需求就闷头写，而是要先和 evaluator 对齐 sprint contract；evaluator 也不是只看代码，而是去跑真实应用，看浏览器行为、看是否符合验收标准。

这就很像一个真正的软件团队了。

四、回过头看，我以前其实已经在零散地做 Harness

这个是我最近最有意思的一个感受。

我原来写博客的时候，并没有用 Harness Engineering 这个词。但把之前写过的内容重新串起来看，会发现很多东西其实都已经在做了。

1. 项目规则，本质上是在做上下文治理

我之前写过项目规则怎么写，比如 What / Why / How，规则要短，不要塞太多无关内容，规则要渐进，不要把会快速过时的细节写进去。

当时我只是觉得，这样可以让 Agent 更稳一点。

现在回头看，这其实已经不是单纯 prompt 了，而是在做 harness 里的一个核心层：

上下文治理层。

也就是告诉 Agent：

  • 这是什么项目
  • 这个项目为什么这么设计
  • 你在这里应该怎么做事
  • 哪些地方不要碰

这已经非常接近 Harness 里的运行边界设计了。

2. Skill，本质上是在做流程封装

我之前还写过 Skill 相关内容。那时候更多是从“把重复操作固化下来”的角度去想，比如一个任务经常做，每次都要重新解释，很浪费时间，那不如把步骤、工具调用、注意事项整理成 Skill。

现在再看，Skill 其实就是 Harness 的一个典型部件。

它做的事情很像：

  • 把模糊经验变成显式流程
  • 把零散步骤变成可复用工作流
  • 把“每次重新对齐”变成“按约定执行”

从这个角度说，Skill 根本不只是一个方便复用的 Prompt 模板，它更像一个轻量级的执行壳层。

3. 经验库，本质上是在做外部记忆

我之前还写过一个观点：Agent 不稳定，很多时候不是因为模型不够聪明，而是因为你只给了目标，没给解法。于是我会倾向于把自己过去解决问题的模式沉淀下来，比如：

  • 调试问题先复现
  • 再看日志
  • 再缩小范围
  • 再验证假设
  • 最后再修

当时我说，这是一种经验上下文。

现在再看，这其实已经是 harness 的 memory 层了。

也就是：

把“我以前是怎么解决这类问题的”沉淀成外部结构，让 Agent 在未来任务里复用。

这已经不是“这次聊天给多一点背景”这么简单，而是在给系统补长期记忆。

4. wiki，本质上是在做 system of record

我最近在折腾用大模型维护 wiki，本来想的是知识沉淀、跨会话记忆、把过往博客和资料组织成一个长期上下文。

后来回头看 OpenAI 那篇东西，突然觉得这个方向跟 Harness 其实是强相关的。

因为 wiki 做的事情，本质上也是：

  • 把原始资料、概念页、问答页、报告页区分开
  • 让知识有稳定的结构和索引
  • 让 Agent 不用每次从零理解整个世界
  • 让过去聊过的东西变成未来可读的系统记录

如果说 AGENTS.md 更像地图，那么 wiki 和 docs 就更像地形、道路和历史档案。

它们组合在一起，才构成一个可持续工作的环境。

五、对个人开发者来说，最小可用 Harness 到底长什么样

不是每个人都需要一上来就搭 Anthropic 那种 planner / generator / evaluator 三 agent 系统。

对个人开发者来说，我现在更认同的是先从一个最小版本开始。

在我看来，一个足够实用的最小 Harness，大概包含这几层：

1. 一份短小但有效的规则文件

它不是百科全书，而是一张地图。

至少要说清楚：

  • 项目是什么
  • 技术栈是什么
  • 目录结构大概怎么分
  • 哪些文件通常不要改
  • 做需求时优先遵循什么工作方式

2. 一层稳定的知识文档

这层可以是 docs/，也可以是 wiki。

目标不是把所有事情都记下来，而是把那些跨任务稳定成立的信息沉淀下来，比如：

  • 业务背景
  • 核心模块说明
  • 常见坑
  • 测试方式
  • UI / API 约定

3. 一条可工作的验证回路

这是我觉得很多人最容易忽视，但其实最重要的地方。

Agent 改完代码后，至少应该能做下面几件事中的一部分：

  • 跑测试
  • 看命令行错误
  • 看日志
  • 看页面真实效果
  • 对照验收标准检查

如果没有这层，Agent 很容易停留在“我觉得我已经写好了”。

4. 一套经验沉淀机制

比如：

  • 好用的规则记录下来
  • 某类问题的解决模式整理成 Skill
  • 有价值的对话总结进 wiki
  • 可复用的流程抽成模板

这层的意义在于，不让每次成功都只停留在一次性的聊天记录里。

六、我现在对 Harness Engineering 的一个偏见

我现在对这个概念有一个比较强的个人偏见：

Harness Engineering 真正重要的，不是给 Agent 加多少能力，而是减少多少“重新开始”。

因为 AI Coding 最大的成本，很多时候不是 token，也不是模型订阅费，而是反复重新对齐。

一次又一次解释项目。
一次又一次补充背景。
一次又一次纠正同样的偏差。
一次又一次告诉它应该怎么验证。

这些重复消耗，才是最烦的。

如果一个 harness 能把这些重复对齐降下来，它就已经很值钱了。

所以我现在更愿意把 Harness 理解成一种“降重复、提闭环”的工程思想，而不是一个新潮术语。

七、结语

以前我写项目规则、写 Skill、写经验库、写 wiki，更多是出于一种朴素的直觉：让 AI 更懂项目一点，让自己少重复一点，让成功经验别白白浪费。

最近看了 Harness Engineering 相关资料之后，我的感受反而不是“我学到了一个全新的东西”，而是：

原来我零零散散做的这些事，放在一起看，本来就是 Harness。

只是以前我们把它叫：

  • 项目规则
  • 工作流
  • Skill
  • 知识库
  • 经验沉淀

现在大家给这整套东西起了一个更系统化的名字，叫 Harness Engineering。

如果要说它对我最大的启发是什么，我觉得不是“去搭一个更复杂的 Agent 系统”，而是提醒我重新审视一件事：

真正值得优化的，往往不是某条 Prompt，而是 Agent 干活的整个环境。

可附参考资料

相关知识库页面