摘要：Harness Engineering 本质是在 Prompt Engineering 和 Context Engineering 之上的一套控制系统，其核心目标是提供一整套控制能力，让 Coding Agent 更稳定、更确定、更可控、可验证、可评估、可回收的装置。

自从去年10 月开始，我用 AI 写代码已经三个项目了，加起来估计几十万代码是有的。今天唠唠我这个多年不写代码、但又一直很关注架构设计的人的真实体验和亲身的、深刻感受。
先说最火的概念，Harness Engineering。2024 年火的 Prompt Engineering，2025 年火的是 Context Engineering，包括之前的 Kapathy 提的 Vibe Coding，以及后来的 SDD（Spec Driven Development）。新概念层出不穷。但是万变不离其宗，先看本质。

LLM 是基于 Input 概率性预测 Output 的过程，本身无状态，非幂等，不确定性的，经常幻觉、漂移。
就像一匹汗血宝马，可以跑的特别快，但是没有方向，到处乱窜，因此得有一套马具，有马鞍、缰绳、挽具这些。玩过《塞尔达传说·旷野之息》DLC的朋友，都知道里面有古代马鞍和古代缰绳，驯服野马尤其是那种很大的野马。

• 古代缰绳，可以让野马增加两格冲刺次数。
• 古代马鞍，可以在很远地方就能吹口哨召回马到你的身边，大大提升可控性。

那么Harness 原本的的意思就是 马具。

在 Coding Agent 中， Harness 到底是什么，我觉得最核心的就是一套控制系统，让 LLM 的输出更加的确定性，驯服LLM 这一匹狂野的白马。那么这一套控制系统，到底对应了啥，我觉得主要是这几个方面：

• 首先还是 Context Layer，这是让大模型每次都能知道之前发生了啥，每次调用 LLM 之前都要知道的上下文，这样才能让无状态的 LLM 调用，变为有状态，并且因为上下文窗口的限制，还不能太多了，否则LLM 还是会发生漂移。并不是有了 Harness Engineering 就不需要 Context Engineering 了，Harness 做为控制系统，是在 Context 之上的。
  • 渐进式的项目规范披露，比如项目所使用的技术栈，整体的约束比如使用 MVVM 模式来设计，比如我使用 OpenSpec+ SuperPowers 的工作流，等等，但是要式渐进式的，不要把 CLAUDE.md、AGENTS.md 写成项目说明文档，只是一个带说明的目录，然后其他内容分散到不同的子目录，这样让大模型在需要的时候再去看细节就行。
  • 各种 Rules，这些本身也是项目的各种约束，本身也是项目规范的一部分，可能更具体一点，比如日志规范、要求 LLM 每轮对话必须遵守的规则和原则，或者说边界，哪些是项目所不允许的，哪些是要遵守的。
  • 各种 Skills：Skill 本身不是什么新的概念，在上一代 AI 浪潮中已经存在的东西，
  • 业务域文档：这个才是最关键的，这里不是放一些什么数据库表结构，而是更多语义层面说明和业务关联关系，某个功能的流程说明，更不是完整的项目说明或者需求规格书。大模型喂了太多上下文就成为了垃圾了，漂移才大。这需要沉淀和积累的。我觉得我使用 OpenSpec 是很好的帮我来沉淀出来业务域的内容，每一个 Change ，archive 之后都会到 openspec/specs 目录下，成为整个项目业务功能的唯一真源 Single Source of Truth
• 执行环境，就是 Coding Agent 能在什么样的工程环境中运行，比如能直接用 MCP 工具读你的数据库测试环境的 schema 和数据，能直接访问对象存储，能知道怎么访问 Loki 或者内部的可观测系统，获取某个 metrics 或者调用链，能访问发布平台，知道某个服务的运行状态，等等等等。
  • 大模型是个强大的大脑，你得给大脑安装好五官、四肢，让他能感受到这个环境的一切，能调用各种能力。
  • 各种 MCP 和 cli、tools 等等，这是大模型的四肢和五官，等于你现在工程环境中的各个子系统，发布平台，可观测平台，日志平台，中间件平台，测试平台，等等等等，都是让 LLM 可以调用的外部系统，大模型对你当前所在的工程环境，能调用的越多，那么可能的自动化程度就会越高，产生的价值就会越大。但是对单一项目来说，绝不是工具越多越好。
• 反馈闭环，这才是在 Coding Agent 发挥到极致的最关键设施。每次都要让大模型有一个知道怎么验证所写代码正确性的方案。
  • 我举个例子，我在写一个 Flutter App，我告诉AI 我要实现什么功能，我会聊各种的方案，比如MVVM 架构，模型怎么定义，什么业务含义，这些都聊清楚了，我让 AI 给我落成 markdown，作为项目规范的一部分，甚至会设置一些 Skills、Rules，来约束大模型生成的代码。这样好像很不错了是吧，大模型给我写完代码，跑完了单元测试，我自己用 flutter run 命令部署到模拟器或者我的真机，然后验证 UI。但是这个远远不够，我要让大模型给我一开始时候 proposal 一个 change 的时候，就要TDD 的方式，给我生成好多单测。每次改完都跑单测，还会跑一个冒烟测试。这些够了吗？还不够，我会让然大模型给我做一些 fixture 测试，拿一些真实的测试文件或者测试素材，来跑冒烟测试。这些够了吗？还是不够，我还是要打开模拟器去点击啊。自从我解决了交叉编译，在模拟器中部署 native 的代码之后，我让大模型给我做 flutter 的 integration test，自动给我拉起模拟器，自动执行 UI 自动化点击，自动在模拟器中截屏分析图中的内容，同时自动去看 stdout 或者 log 文件，让大模型给我盯死了所有的输出，包括界面的，包括终端的，包括上下游的，这样出了问题或者有任务错误？好，大模型继续给我改代码，继续跑单测、冒烟测试、fixture 测试、自动 hot 代码、自动在模拟器上模拟点击、自动截屏模拟器、自动盯终端 log 输出，继续下一个循环。直到认为正确为止。好，这是一个端到端的 Agent Loop 的完整过程。这就是反馈闭环，这样才能真正发挥 Coding Agent 的最大价值。

参考文章：

1. OpenAI

• Harness engineering: leveraging Codex in an agent-first world

2. Anthropic

• Building Effective AI Agents
• Writing effective tools for AI agents
• Effective harnesses for long-running agents
• Harness design for long-running application development

3. LangChain

• Evaluating Deep Agents: Our Learnings

4. Martin Flower

• Harness Engineering