你可以把 Vibe Coding → Agentic Coding → Harness Engineering 看成 AI 编程正在发生的一次“抽象层级上移”。这并不是严格划分的三个历史阶段，而是三种越来越成熟的工作方式：
Vibe Coding 关注“让 AI 写代码”；Agentic Coding 关注“让 AI 自己做任务”；Harness Engineering 关注“怎样设计一个环境，让 AI 长时间、稳定、可验证地把任务做对”。
这也是为什么进入 2026 年以后，“Harness”这个词在 AI Coding 圈子里明显变得重要。OpenAI 已经直接使用 Harness Engineering 这个说法，Anthropic 也持续讨论 long-running agent 的 harness design。(OpenAI)
一、先从 Vibe Coding 说起
2025 年 2 月，Andrej Karpathy 提出 “Vibe Coding” 这个说法。他描述的是一种非常极端但很形象的 AI 编程方式：开发者主要用自然语言告诉 AI 自己想要什么，让 AI 生成和修改代码，人不再逐行编程，甚至不一定认真阅读每一段生成代码。(X (formerly Twitter))
例如你想做一个设备监测软件，以前可能是：
我要设计数据结构。
我要写 TCP 通信。
我要写 SQLite。
我要写 Qt UI。
我要实现数据曲线。
我要处理线程同步。
Vibe Coding 变成：
做一个 Windows 设备监测程序，左边显示设备列表，中间实时显示三轴振动曲线，后台 TCP 接收传感器数据并写入 SQLite。
AI 开始大量承担具体编码工作。
这带来一个巨大的变化：
开发者逐渐从“代码生产者”变成“需求描述者”。
但很快就出现第二个问题。
AI 可以很快生成 500 行、5000 行甚至几万行代码，但：
代码到底对不对？
有没有破坏旧功能？
数据库设计是不是乱了？
有没有重复实现？
架构是不是越来越差？
AI 下一次还记不记得为什么这样设计？
运行 2 小时以后，它还知道自己正在干什么吗？
于是问题从：
“AI 会不会写代码？”
逐渐变成：
“如何管理一个会写代码的 AI？”
Harness 就是在这个问题上出现的。
二、Harness 到底是什么？
“harness”这个英文单词原来的意思非常形象：马具、挽具、安全带、控制装置。
一匹马很有力量。
但你不会简单地告诉马：
去北京。
然后希望它自己一路跑过去。
你需要缰绳、鞍具、路线、补给、道路、边界和骑手。
对于 AI Agent 来说也是一样。
可以用一个非常有用的关系理解：
Agent ≈ Model + Harness
Model 是“大脑”。
Harness 是围绕这个大脑的一整套：
工具、环境、上下文、记忆、任务循环、权限、验证、反馈、日志、恢复机制和工程规则。
OpenAI 对 Codex 的内部描述非常接近这个概念：Codex harness 提供核心的 agent loop 和 execution logic，负责协调用户、模型以及模型调用的工具。(OpenAI)
所以：
LLM 本身不是完整的 Coding Agent。
GPT、Claude 或其他模型只是其中的推理核心。
真正让它能够：
读代码 → 搜代码 → 修改文件 → 编译 → 测试 → 看错误 → 再修改 → 提交 PR
的是外面这一层 Harness。
三、Harness 最核心的东西，其实是一个循环
最简单的 Coding Agent 可以写成：
User
↓
Model
↓
决定下一步行动
↓
Tool
↓
执行
↓
获得结果
↓
Model
↓
继续行动
↓
...
↓
完成任务例如：
用户：
修复登录失败的问题
↓
AI：
先寻找 authentication 相关代码
↓
grep / search
↓
发现 auth_service.py
↓
AI：
阅读代码
↓
read_file
↓
AI：
发现 token refresh 可能有问题
↓
运行测试
↓
pytest
↓
测试失败
↓
AI：
修改代码
↓
apply_patch
↓
再次测试
↓
测试通过
↓
git diff
↓
AI检查改动
↓
完成这个循环叫 Agent Loop。
OpenAI 在 Codex 技术说明里公开描述了这个机制：模型可以直接回答用户，也可以请求 tool call；工具执行结果被重新放回上下文，然后模型再次推理。这个循环一直持续到模型不再要求工具调用。(OpenAI)
但是：
Agent Loop 只是最基础的 Harness。
真正成熟的 Harness 要复杂得多。
四、一个完整 Coding Harness 通常有九个关键部分
可以把它理解成下面这一套系统：
- Agent Loop：控制“思考 → 行动 → 观察 → 再思考”的循环，并决定什么时候结束。
- Context Management：决定当前应该让模型看到哪些代码、文档、历史任务和工具结果，而不是简单把整个项目塞进 context window。OpenAI 的 Codex 会进行 context compaction；Anthropic 的长期 Agent 实验则发现，仅仅 compaction 并不能解决所有长任务问题，有些情况下需要直接 context reset，再依靠结构化 handoff 接续工作。(OpenAI)
- Tool System：向 Agent 提供文件读取、文件修改、shell、git、编译器、测试工具、浏览器、数据库以及 MCP 等能力。模型不是直接“操作电脑”，而是通过 Harness 暴露出来的工具行动。(OpenAI)
- Memory / State：保存“我做过什么”“现在做到哪里”“还有哪些任务”“为什么做这个决定”。Anthropic 的长期 Agent 实验甚至专门让 Agent 生成进度文件和 Git commit，使下一次 Agent session 可以恢复工作。(Anthropic)
- Planning：把“做一个完整应用”拆成 Feature、Task、Sprint、Acceptance Criteria。否则 Agent 很容易试图“一口气把项目写完”。Anthropic 在长期开发实验中观察到，这正是典型失败模式之一。(Anthropic)
- Verification：不是让 AI 自己说“我完成了”，而是要求它拿出证据，比如 build success、unit tests、integration tests、UI 操作结果、截图、日志、静态分析结果等。最新 Harness 研究也越来越强调：目标不是“得到 patch”，而是得到一个能够证明正确性的 patch。(arXiv)
- Evaluator / Reviewer：将“生成者”和“评审者”分开。Anthropic 的实验发现，让生成代码的 Agent 自己评价自己的成果容易过度乐观，因此采用 Planner / Generator / Evaluator 分工，让另一个 Agent 专门挑问题。(Anthropic)
- Sandbox / Permissions：Agent 可以运行 shell、修改文件甚至访问外部系统，因此必须规定哪些目录能写、网络能否访问、什么操作需要人工批准。Codex 的 Harness 会把 sandbox 和 permission 约束加入 Agent 的运行上下文。(OpenAI)
- Observability / Recovery：记录 Agent 做过什么、调用过什么工具、为什么失败、消耗了多少 token、在哪里陷入循环，并允许重试、回滚、重新规划或升级给人类。2026 年已经出现专门研究“自动改进 Harness”的工作，其核心之一就是提高 Harness 本身的可观测性。(arXiv)
因此，Harness 远远不是一个 Prompt。
它更像是：
AI 程序员的 IDE + 操作系统 + 项目经理 + 工作流程 + 权限系统 + 测试系统 + CI/CD + 记忆系统。
五、为什么单纯 Vibe Coding 不够？
这里是理解 Harness 最关键的一点。
假设你告诉 AI：
“给我的软件增加用户管理功能。”
Vibe Coding 很可能是：
Prompt
↓
AI写代码
↓
运行
↓
看起来能用
↓
继续下一个功能这在 Demo、原型、个人项目里非常有效。
但到了大型项目，它可能产生一种危险的现象：
feature 1
↓
局部修改
feature 2
↓
局部修改
feature 3
↓
复制一些代码
feature 4
↓
再加 workaround
feature 5
↓
架构开始漂移
feature 20
↓
没人真正理解系统尤其是 AI 有很强的局部合理性：
它看到一个现有模式，很容易继续模仿这个模式。
即使这个模式本身并不好。
OpenAI 在一个高度 Agent 化的软件项目中公开描述过这个问题：Codex 会复制 repository 中已经存在的模式，包括并不理想的模式，因此长期运行会造成 drift。他们后来加入所谓“golden principles”和自动清理机制，让 Agent 持续发现架构偏差并提交重构 PR。(OpenAI)
这非常重要。
因为它意味着 AI Coding 出现了一个新的工程规律：
坏代码不仅会产生技术债，而且会成为 AI 下一轮生成代码的训练样本式“局部示范”。
于是坏结构会自我繁殖。
这就是为什么 Harness 必须控制整个系统，而不能只控制 Prompt。
六、Harness Engineering 真正改变的，是“代码库本身”
这一点我认为比工具调用更加值得注意。
过去软件项目主要是：
给人看的。
README 给人看。
Architecture 文档给人看。
代码结构给程序员看。
但进入 Agent Coding 后，一个 repository 必须越来越：
Agent-readable。
OpenAI 在自己的 agent-first 工程实践中明确提出了类似思路。他们没有把所有规则都塞进一个巨大的 AGENTS.md，而是把它做成类似“目录”，让 Agent 再逐级访问结构化知识库。原因之一是 context 是稀缺资源，一个巨大的说明文件反而会压缩真正任务和代码所占的上下文。(OpenAI)
例如一个 Agent-native repository 可能变成：
project/
│
├── AGENTS.md
│
├── ARCHITECTURE.md
│
├── README.md
│
├── docs/
│ ├── design/
│ ├── product/
│ ├── security/
│ ├── reliability/
│ ├── decisions/
│ └── plans/
│
├── src/
│
├── tests/
│
├── scripts/
│ ├── build.sh
│ ├── test.sh
│ └── verify.sh
│
└── .agent/
├── rules/
├── workflows/
└── skills/这时候 ARCHITECTURE.md 已经不仅仅是文档。
它实际上是：
AI 的世界模型。
tests/ 不再只是为了 CI。
它也是：
AI 的反馈信号。
AGENTS.md 不只是说明。
它实际上是：
Agent 的操作手册。
而 Git history 也不只是版本历史。
它逐渐成为：
Agent 的长期外部记忆。
OpenAI 的实践甚至把 execution plans、progress、decision logs、technical debt 等放进 repository 并版本化，从而减少 Agent 对聊天历史或“某个人脑子里的知识”的依赖。(OpenAI)
这其实是软件工程一个很深的变化。
七、Prompt Engineering、Context Engineering 和 Harness Engineering是什么关系？
这三个概念非常容易混淆。
可以把它们看成三个同心圆：
┌──────────────────────────────┐
│ Harness Engineering │
│ │
│ ┌──────────────────────┐ │
│ │ Context Engineering │ │
│ │ │ │
│ │ ┌───────────────┐ │ │
│ │ │ Prompt Eng. │ │ │
│ │ └───────────────┘ │ │
│ │ │ │
│ └──────────────────────┘ │
│ │
└──────────────────────────────┘Prompt Engineering
解决：
“我应该怎么跟模型说？”
例如：
你是一名高级C++工程师。
修改代码前先分析问题。
不要修改公共API。
完成后运行测试。Context Engineering
解决：
“模型现在应该知道什么？”
例如：
不要给模型整个 300 万行代码库。
而是给它：
用户需求
+
ARCHITECTURE.md
+
相关模块
+
相关接口
+
最近错误日志
+
相关测试
+
Git diff本质是：
选择和组织模型的工作记忆。
Harness Engineering
解决的问题更大：
“整个 AI 软件工程过程应该怎样运行？”
它不仅决定：
模型看什么，
还决定：
模型什么时候行动、
能调用什么工具、
怎么执行代码、
什么时候测试、
失败怎么办、
上下文满了怎么办、
谁负责检查、
能修改什么文件、
什么时候提交 Git、
什么情况下必须找人。
所以可以近似理解为：
Prompt Engineering
↓
控制一次推理
Context Engineering
↓
控制一次或一段推理所看到的信息
Harness Engineering
↓
控制整个 Agent 生命周期八、Harness 的核心已经从“生成代码”变成“建立闭环”
如果让我只用一个词概括 Harness，我会选：
闭环
Vibe Coding 更像：
Human → AI → Code成熟 Coding Agent 是：
┌─────────────┐
│ Plan │
└──────┬──────┘
↓
┌─────────────┐
│ Implement │
└──────┬──────┘
↓
┌─────────────┐
│ Build │
└──────┬──────┘
↓
┌─────────────┐
│ Test │
└──────┬──────┘
↓
┌─────────────┐
│ Evaluate │
└──────┬──────┘
│
Fail│
↓
Repair
│
└─────────→ Test
Pass
↓
Git
↓
PR
↓
ReviewOpenAI 描述的一个成熟 agent-first repository 已经能够让 Codex 从一个 Prompt 开始，自行验证代码库状态、复现 bug、实现修复、验证修复、创建 PR、响应 review、处理 build failure，直到需要判断性决策时才升级给人。OpenAI 同时强调，这种能力高度依赖 repository 本身的 Harness 投资，并不能简单假定换一个普通项目也能达到同样效果。(OpenAI)
这一句特别关键。
不是：
“模型突然强到了这种程度。”
而是：
“模型 + Harness + 为 Agent 设计的代码库共同达到了这种程度。”
九、同一个模型，Harness 不同，能力可能差很多
这也是目前 Harness 研究最有意思的地方。
过去我们习惯比较：
GPT A vs GPT B
Claude A vs Claude B以后很可能需要比较：
Model A + Harness X
Model A + Harness Y因为 Agent 的实际能力并不只取决于模型。
Anthropic 在一项 long-running application 实验里，用相同起点比较单 Agent 和完整 Harness。完整 Harness 使用 Planner、Generator、Evaluator，并把任务拆成多个 sprint，运行时间和成本都大幅提高，但得到的应用完成度也明显更高。Anthropic 特别说明，这种 Harness 的代价可能非常大——他们展示的一个实验里，solo run 约 20 分钟、9 美元，而 full harness 约 6 小时、200 美元。这个数字只是一次实验，不应当视为普遍成本比例，但很好地说明了 Harness 是在用更多规划、验证和迭代换取质量。(Anthropic)
甚至已经出现“让 Agent 自动优化 Harness”的研究。2026 年的一项预印本报告称，对 tools、middleware、long-term memory 等 Harness 组件进行迭代优化，可以在冻结模型的情况下提高多个任务集和模型家族上的表现。这个方向目前仍属于快速发展的研究阶段，但它指向一个很值得注意的趋势：
未来优化 AI Coding 系统，未必一定需要训练一个更大的模型，也可能通过优化 Harness 获得显著收益。 (arXiv)
十、因此，“Harness”不等于 Agent Framework
这里也很容易误会。
LangGraph、Agent SDK、各种 workflow framework，可以帮助你实现 Harness。
但：
Framework ≠ Harness。
Framework 更像造车平台。
Harness 是你最后设计出来的整辆车及其驾驶控制系统。
类似：
LLM
GPT / Claude
│
▼
Agent SDK / Framework
│
▼
Harness
├─ Prompt
├─ Context
├─ Agent Loop
├─ Tool policy
├─ Memory
├─ Planner
├─ Evaluator
├─ Tests
├─ Sandbox
├─ Permissions
├─ Logging
├─ Retry
├─ Git workflow
└─ Human approval
│
▼
Coding Agent甚至 Claude Code、Codex CLI 本身都可以从这个意义上理解为已经实现好的 Coding Harness。Anthropic 直接称 Claude Code 是一个优秀的 harness；OpenAI 则把 Codex CLI 中负责 agent loop 和 execution logic 的部分称为 Codex harness。(Anthropic)
十一、Vibe Coding 与 Harness Engineering 的本质区别
我觉得最简单的区别是：
Vibe Coding 是“相信模型”。
Harness Engineering 是“设计一个系统，使你不必相信模型”。
比如 AI 说：
“Bug 已经修复。”
Vibe Coding：
好，看起来不错。
Harness：
Bug reproduction PASS
Unit tests 328/328
Integration tests 47/47
Regression tests PASS
Static analysis PASS
Build PASS
UI automation PASS
Git diff reviewed
Architecture rules PASS然后系统才认为：
TASK COMPLETED这就是很经典的工程思想：
不要依赖智能体自觉，而要依赖可验证机制。
2026 年的 Harness Engineering 研究也正在把 autonomous software engineering 的评价问题从“Agent 能不能生成一个 patch”转向“Model–Harness–Environment 整体能不能生成一个可验证、可追责、可维护的修改”。(arXiv)
十二、Harness 其实正在改变“程序员”这个职业
Vibe Coding 时代，人告诉 AI：
写什么代码。
Agent Coding 时代，人告诉 AI：
完成什么任务。
Harness Engineering 时代，人越来越多地告诉系统：
什么叫完成。
这是三个完全不同的抽象层。
传统编程
Human
↓
Code
Vibe Coding
Human
↓
Prompt
↓
AI
↓
Code
Agentic Coding
Human
↓
Task
↓
Agent
↓
Tools
↓
Code
Harness Engineering
Human
↓
Goal + Constraints + Acceptance Criteria
↓
Harness
↓
┌─────────────────────────┐
│ Planner │
│ Coding Agent │
│ Tools │
│ Tests │
│ Evaluator │
│ Memory │
│ Sandbox │
│ CI │
│ Git │
└─────────────────────────┘
↓
Verified Software所以未来高级开发者很可能越来越少花时间亲自写：
for (...)
if (...)
class ...而越来越多花时间定义：
Architecture、Interfaces、Constraints、Tests、Acceptance Criteria、Agent Rules、Tool Policies、Evaluation 和 Feedback Loops。
换句话说：
程序员正在从“写程序的人”，逐渐变成“设计 AI 如何写程序的人”。
十三、我认为 Harness 是比 Vibe Coding 更重要的一次变化
Vibe Coding 最吸引眼球，因为它让人第一次强烈感觉到：
“我不写代码也能做软件。”
但 Harness Engineering 的意义更深。
因为它回答的是另一个问题：
“如果 AI 写掉 90% 甚至 99% 的代码，那么剩下的人类软件工程到底是什么？”
答案正在逐渐出现：
不是 Prompt 写得更漂亮。
而是设计：
环境
+
知识
+
工具
+
权限
+
工作流
+
验证
+
反馈
+
架构约束
+
长期记忆也就是：
Harness。
因此我更愿意把整个变化概括成一句话：
Vibe Coding 把“写代码”交给了 AI；Harness Engineering 则开始把“软件工程过程”本身编码化。
而这很可能才是 AI Coding 从“神奇 Demo”真正进入大型、长期、生产级软件开发的关键一步。OpenAI 和 Anthropic 2025–2026 年公开的工程实践已经相当清楚地体现了这一趋势：模型能力仍然重要，但真正决定 Agent 能否长期工作的，越来越是模型周围那套运行环境与工程系统。 (OpenAI)