你还在研究怎么写 Prompt？

说实话，三个月前我也是。那会儿我刚把 Context Engineering 那套玩法摸熟，觉得自己已经站在 AI 工程的前沿了——给模型塞对的资料，控制上下文窗口，动态检索，一套组合拳打下来效果确实不错。

直到上周，我在跑一个用 Claude Code 重构老项目的任务时翻车了。Agent 跑了四十多分钟，改了二十几个文件，最后我一看——它把三个模块的依赖关系搞成了循环引用，测试全红。我盯着屏幕想了半天：我给它的上下文明明是对的，为什么它还是跑飞了？

后来我读到一篇文章，里面有句话直接把我点醒了——

“Context Engineering 解决的是’给模型看什么’，但没人管’模型在什么环境里干活’。”

这就是 2026 年 AI 工程圈最火的新词：Harness Engineering（驾驭工程）。

更有意思的是，这个概念的内核一点都不新。它本质上就是控制论——一门 240 年前就开始萌芽的学科。往下读，你会发现 James Watt 的蒸汽机调速器、Kubernetes 的声明式架构、和你今天给 AI Agent 写的 AGENTS.md，底层逻辑竟然是同一套东西。

---

从 Prompt 到 Harness：AI工程的三次范式跃迁

先用一张全景图帮你理清脉络。过去四年，AI 工程经历了三次范式跳跃，每次跳跃的核心问题完全不同：

Prompt Engineering（2022-2024）：怎么跟模型说话。 那个阶段我们研究的是措辞、格式、Few-shot、思维链。本质上是在优化一次性的输入。

Context Engineering（2025）：给模型看什么资料。 RAG 检索、上下文压缩、动态文档注入……我们开始意识到，模型的回答质量取决于它"看到了什么"，而不仅仅是你"怎么问"。

Harness Engineering（2026）：给模型造什么样的工作环境。 工具权限、执行流程、验证机制、错误恢复、多 Agent 协作……关注点从"输入"彻底转向了"系统"。

打个比方你就懂了。Prompt Engineering 是给新来的实习生发了条微信消息：“帮我查一下这个 bug”。Context Engineering 是给他开通了 Wiki 权限，把相关文档链接都发过去了。而 Harness Engineering？是给他搭好了整个工位——电脑装好了开发环境，CI/CD 流水线配好了，Code Review 流程交代清楚了，哪些目录不能碰、出了问题找谁、怎么回滚，全都白纸黑字写进了 SOP。

这就引出了 2026 年最重要的一个公式：

Agent = Model + Harness

模型是引擎，Harness 是整辆车的其余部分——方向盘、刹车、车道线、安全气囊。引擎再强，没有这些东西，你敢上路吗？

LangChain 团队用实际数据证明了这一点：他们在 Terminal Bench 2.0 上的评测中，模型完全不换，只调整了外围的 Harness 设计，得分就从 52.8% 飙升到了 66.5%——直接从 Top 30 开外冲进了 Top 5。

模型不是不重要，但在当前这个节点，优化模型外面的壳，回报率远高于等一个更强的模型。

---

为什么说 Harness Engineering 本质是控制论？

这是我觉得最迷人的部分。

控制论（Cybernetics）这个词来自希腊语 κυβερνήτης，意思是"舵手"。没错，Kubernetes 这个名字也来自同一个词根。从拧阀门到掌舵，从手动操作到设计自动控制系统——这个转变在人类工程史上至少发生过三次：

第一次：1780年代，James Watt 的离心调速器。

蒸汽机刚发明的时候，最大的问题不是动力不够，而是转速控不住——快了会爆缸，慢了会停机。Watt 设计了一个天才装置：两个金属球连在旋转轴上，转速快了离心力把球甩开、自动关小阀门，转速慢了球落回来、阀门开大。不需要人站在旁边一直盯着。

这就是控制论的原型：传感器感知状态 → 执行器调整行为 → 反馈闭环自动运转。

第二次：2010年代，Kubernetes。

你声明一个目标状态：“我要 3 个 Pod 运行这个服务”。控制器持续观察实际状态，发现只有 2 个在跑？自动拉起一个。发现跑了 4 个？干掉一个。同样的模式：感知偏差 → 自动纠正 → 闭环运转。

第三次：2026，Harness Engineering。

你给 AI Agent 设计一整套工作环境——约束它的行为边界、给它提供结构化上下文、用测试和 Linter 自动验证它的输出、出错了触发回滚或人工升级。本质上就是在给 Agent 构建一个自动控制系统。

三次范式，时隔两百多年，底层逻辑一模一样：设计反馈闭环，让系统自动趋向正确状态。

但这一次有个关键不同。传统的反馈环路只能在"低层次"闭合——编译器检查语法、测试套件验证行为、Linter 规范风格。这些都是机械性的、规则明确的。

LLM 改变了游戏规则。它第一次让反馈环路在高层次上也能闭合——架构判断、接口设计、抽象质量这些过去只有资深工程师才能评估的东西，现在可以由另一个 AI 来"感知"和"纠正"。

这就是为什么 Harness Engineering 不是新瓶装旧酒，而是控制论在全新层次上的一次飞跃。

---

CIVC：Harness 的四大控制机制

理解了控制论的本质，我们来拆解 Harness 到底长什么样。

业界有个很形象的隐喻：AI 模型是一匹强壮的野马，Harness 是缰绳+马鞍+辔头组成的完整马具系统，工程师是骑手。你不需要比马跑得快，但你得知道怎么驾驭它。

Harness 的四大核心机制，我把它总结为 CIVC 框架：

1. Constrain（约束）：缩小可能性空间

这是最反直觉的一点——限制越多，输出越好。

为什么？因为 LLM 的上下文窗口是有限的，每多一个不相关的选择，模型就多浪费一份注意力。约束本质上是在帮模型"减负"。

实操层面，约束可以这样做：

# 工具权限分级：不是所有工具都对所有 Agent 开放
agent_permissions = {
    "code_writer": ["read_file", "write_file", "run_tests"],
    "reviewer": ["read_file", "comment"],  # 只能看和评论，不能改
    "deployer": ["run_ci", "deploy_staging"],  # 不能直接部署生产
}

# 架构约束：用 Linter 强制执行依赖方向
# 比如 service 层不能反向依赖 controller 层
FORBIDDEN_IMPORTS = {
    "app/services/": ["app/controllers/", "app/routes/"],
    "app/models/": ["app/services/", "app/controllers/"],
}

Stripe 的做法是把确定性节点（lint、格式化、push）和 Agent 节点（实现功能、修 CI）混合编排成状态机。确定性的部分绝不交给模型"自由发挥"。

2. Inform（告知）：构建认知基础

这一块跟 Context Engineering 有交集，但 Harness 的做法更加结构化。

OpenAI 内部的经验很有意思。他们做那个"100 万行代码零手写"的项目时，AGENTS.md 只写了大约 100 行。不是巨细无遗的手册，而是一张地图——告诉 Agent 项目结构是什么、每个目录干什么、到哪里找更详细的信息。

“给 Agent 一张地图，而不是一本千页手册。”

# AGENTS.md 示例（精简版）

## 项目结构
- `app/api/` - FastAPI 路由定义，每个模块一个文件
- `app/services/` - 业务逻辑层，禁止直接访问数据库
- `app/models/` - SQLAlchemy 模型定义
- `tests/` - pytest 测试，与 app/ 目录结构镜像

## 编码规范
- 类型注解覆盖所有公开函数
- 异步优先，使用 async/await
- 错误处理统一用自定义异常类

## 依赖方向
routes → services → models → database（单向，不可逆）

另一个关键发现是 40% 上下文阈值。Anthropic 的测试表明，当 168K token 的上下文窗口用到约 40% 时，Agent 的输出质量开始明显下降——幻觉增多、兜圈子、代码质量跳水。他们的应对策略不是压缩上下文，而是直接启动一个全新的"干净"Agent，通过结构化交接文档恢复状态。

这就像工厂里的换班制度——不是让一个工人连轴转到崩溃，而是交班时把关键信息写在交接本上，让下一班接着干。

3. Verify（验证）：建立独立的质量保障

验证机制分两类：

计算型验证——确定性的、不需要判断的。跑测试、跑 Linter、类型检查、格式校验。这些是传统工具链就能搞定的，成本低、可靠性高。

# pre-commit hook 示例：Agent 每次提交前自动执行
verify_pipeline = [
    "ruff check .",           # 代码风格
    "mypy app/",              # 类型检查
    "pytest tests/ -x -q",   # 测试（失败即停）
    "python scripts/check_imports.py",  # 自定义依赖方向检查
]

推理型验证——需要"判断力"的。代码质量审查、架构合理性评估、安全风险识别。这是 LLM 才能做的事。

Anthropic 用了一个很巧妙的架构：生成器-评估器分离。主 Agent 写完代码后，起一个新的 Agent（相同模型但完全隔离的上下文）来做 Review。用同一双眼睛检查自己的作业肯定不靠谱，但换一双"上下文完全不同的眼睛"，效果就好得多。

Planner（规划者）→ Generator（执行者）⇄ Evaluator（评估者）
         ↑                                      |
         └──────── 反馈修正 ←──────────────────┘

4. Correct（纠正）：偏差恢复能力

再好的约束和验证也不能保证 100% 不出错。关键是出错之后能不能自动修复。

这是 Harness 区别于"配置文件"的核心——它是一个活的控制系统，不是静态的规则集。

纠正机制的设计原则：

分级响应。 小问题（Linter 报错）→ Agent 自动修复重试。中等问题（测试失败）→ 回滚到上一个通过的状态，换个思路重来。大问题（架构级冲突）→ 暂停执行，升级给人类审核。

# 简化版纠正逻辑
async def harness_correct(agent_output, error_type):
    if error_type == "lint":
        return await agent.fix_and_retry(agent_output, max_retries=3)
    elif error_type == "test_failure":
        await git_rollback(to="last_green_commit")
        return await agent.retry_with_new_approach()
    elif error_type == "architecture_violation":
        await pause_agent()
        await notify_human("架构级问题，需要人工审核")
        # 成功应静默，失败才发声

回头看 CIVC 这四个机制——约束缩小行动空间、告知提供认知基础、验证检测偏差、纠正恢复正轨——这不就是一个标准的控制论闭环吗？Watt 调速器的"感知转速→调节阀门"，只不过换成了"感知代码质量→调节 Agent 行为"。

---

一线大厂怎么做 Harness Engineering

理论讲完了，看看实战。三个案例，三种风格，都是真刀真枪的成果。

OpenAI：3 人 / 5 个月 / 100 万行 / 0 手写

这是目前最炸裂的案例。三个工程师在五个月内，完全由 AI Agent 生成了超过 100 万行生产级代码，没有一行是人类手写的。他们的秘诀不是用了更强的模型，而是三条 Harness 原则：

第一，“仓库是唯一事实源”。所有规范、约束、决策记录全部沉淀在代码仓库里。写在 Slack 里的知识，对 Agent 来说等于不存在。

第二，“约束靠工具强制执行，不靠文档”。自定义 Linter 里内嵌了修复说明，Agent 犯错时直接告诉它怎么改，而不是让它去翻一个 200 页的规范文档。

第三，“AGENTS.md 是地图不是手册”。100 行搞定，只告诉 Agent 去哪找信息，不把信息本身堆进去。

Anthropic：GAN 式三智能体架构

Anthropic 的做法更有控制论美感。他们设计了 Planner-Generator-Evaluator 三个角色，形成类似 GAN（生成对抗网络）的对抗式结构。Planner 拆解任务，Generator 执行，Evaluator 独立审核。Generator 和 Evaluator 用相同模型但完全隔离上下文，确保评估的独立性。

他们还发现了一个关键操作：Context Reset。当上下文使用超过 40%，不是去压缩，而是直接起一个新鲜 Agent，用结构化的交接文档传递状态。这比任何压缩算法都管用，因为它从根本上消除了上下文污染。

Stripe：每周 1300+ 无人值守 PR

Stripe 的 Agent 每周合入超过 1300 个 Pull Request，几乎不需要人工干预。他们的杀手锏是混合状态机编排：确定性节点（lint、格式化、push）用传统代码写死，Agent 节点（实现功能、修 CI）才交给模型。每个 Agent 运行在隔离环境中，有明确的权限边界和升级规则。

他们总结了一句话我特别认同：“What’s good for humans is good for agents.” 对人类好的工程实践——清晰的文档、严格的 Code Review、完善的测试——对 Agent 同样好用，甚至更重要。

---

给普通开发者的实操路线图

看到这你可能会想：大厂有资源折腾，我一个人或者小团队该怎么入手？

别慌，Harness Engineering 不需要从零造轮子。分三个级别，按需上强度：

Level 1：个人开发者，1-2 小时搞定

写一个 AGENTS.md 放项目根目录，100 行以内。配好 pre-commit hooks（ruff + mypy + pytest）。确保 Agent 每次改完代码都自动跑一遍检查。这三件事做完，你的 Agent 输出质量就能提升一个档次。

# .pre-commit-config.yaml
repos:
  - repo: https://github.com/astral-sh/ruff-pre-commit
    hooks:
      - id: ruff
        args: [--fix]
  - repo: https://github.com/pre-commit/mirrors-mypy
    hooks:
      - id: mypy
        additional_dependencies: [types-all]
  - repo: local
    hooks:
      - id: pytest-check
        name: Run tests
        entry: pytest tests/ -x -q
        language: system
        pass_filenames: false

Level 2：小团队，1-2 天

在 Level 1 基础上，加入团队共享的编码约束规范（统一的 ruff 配置、import 规则）。CI 流水线增加 Agent 输出的卡点检查。写一个简单的 Review Checklist 让 Agent 自查。

Level 3：正经项目，1-2 周

自定义 Linter 规则（带修复建议）。加入可观测性——记录 Agent 的每次决策、工具调用、错误恢复。搞一个"熵管理 Agent"，定期清理 Agent 积累的冗余代码和漂移。如果你用 FastAPI，可以把 Harness 的配置和约束做成一个标准化的项目模板，每个新项目直接套用。

---

写在最后

回到开头的故事。我那个循环引用的翻车事故，后来怎么解决的？

我写了 15 行 Python 脚本检查模块间的依赖方向，加进了 pre-commit hook。又在 AGENTS.md 里画了一张三行的依赖关系图。总共花了二十分钟。

之后 Agent 再也没犯过同样的错误。不是因为模型变聪明了，而是因为我给它的环境不允许犯这个错了。

这就是 Harness Engineering 的核心哲学：每次 Agent 犯错，不要去调 Prompt，去改环境。让这个错误在结构上不可能再发生。

两百多年前，设计出离心调速器的工程师们没有再回去拧阀门。不是因为他们做不到，而是因为那已经不再有意义。

2026 年，我们也站在同样的转折点上。模型会继续变强，但真正决定 AI 工程天花板的，是模型之外的那套控制系统。

模型决定系统的上限，Harness 决定系统的底线。

你不是模型，那你就是 Harness。