你还在研究怎么写 Prompt说实话三个月前我也是。那会儿我刚把 Context Engineering 那套玩法摸熟觉得自己已经站在 AI 工程的前沿了——给模型塞对的资料控制上下文窗口动态检索一套组合拳打下来效果确实不错。直到上周我在跑一个用 Claude Code 重构老项目的任务时翻车了。Agent 跑了四十多分钟改了二十几个文件最后我一看——它把三个模块的依赖关系搞成了循环引用测试全红。我盯着屏幕想了半天我给它的上下文明明是对的为什么它还是跑飞了后来我读到一篇文章里面有句话直接把我点醒了——“Context Engineering 解决的是’给模型看什么’但没人管’模型在什么环境里干活’。”这就是 2026 年 AI 工程圈最火的新词Harness Engineering驾驭工程。更有意思的是这个概念的内核一点都不新。它本质上就是控制论——一门 240 年前就开始萌芽的学科。往下读你会发现 James Watt 的蒸汽机调速器、Kubernetes 的声明式架构、和你今天给 AI Agent 写的 AGENTS.md底层逻辑竟然是同一套东西。从 Prompt 到 HarnessAI工程的三次范式跃迁先用一张全景图帮你理清脉络。过去四年AI 工程经历了三次范式跳跃每次跳跃的核心问题完全不同Prompt Engineering2022-2024怎么跟模型说话。那个阶段我们研究的是措辞、格式、Few-shot、思维链。本质上是在优化一次性的输入。Context Engineering2025给模型看什么资料。RAG 检索、上下文压缩、动态文档注入……我们开始意识到模型的回答质量取决于它看到了什么而不仅仅是你怎么问。Harness Engineering2026给模型造什么样的工作环境。工具权限、执行流程、验证机制、错误恢复、多 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 个干掉一个。同样的模式感知偏差 → 自动纠正 → 闭环运转。第三次2026Harness Engineering。你给 AI Agent 设计一整套工作环境——约束它的行为边界、给它提供结构化上下文、用测试和 Linter 自动验证它的输出、出错了触发回滚或人工升级。本质上就是在给 Agent 构建一个自动控制系统。三次范式时隔两百多年底层逻辑一模一样设计反馈闭环让系统自动趋向正确状态。但这一次有个关键不同。传统的反馈环路只能在低层次闭合——编译器检查语法、测试套件验证行为、Linter 规范风格。这些都是机械性的、规则明确的。LLM 改变了游戏规则。它第一次让反馈环路在高层次上也能闭合——架构判断、接口设计、抽象质量这些过去只有资深工程师才能评估的东西现在可以由另一个 AI 来感知和纠正。这就是为什么 Harness Engineering 不是新瓶装旧酒而是控制论在全新层次上的一次飞跃。CIVCHarness 的四大控制机制理解了控制论的本质我们来拆解 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 自动修复重试。中等问题测试失败→ 回滚到上一个通过的状态换个思路重来。大问题架构级冲突→ 暂停执行升级给人类审核。# 简化版纠正逻辑asyncdefharness_correct(agent_output,error_type):iferror_typelint:returnawaitagent.fix_and_retry(agent_output,max_retries3)eliferror_typetest_failure:awaitgit_rollback(tolast_green_commit)returnawaitagent.retry_with_new_approach()eliferror_typearchitecture_violation:awaitpause_agent()awaitnotify_human(架构级问题需要人工审核)# 成功应静默失败才发声回头看 CIVC 这四个机制——约束缩小行动空间、告知提供认知基础、验证检测偏差、纠正恢复正轨——这不就是一个标准的控制论闭环吗Watt 调速器的感知转速→调节阀门只不过换成了感知代码质量→调节 Agent 行为。一线大厂怎么做 Harness Engineering理论讲完了看看实战。三个案例三种风格都是真刀真枪的成果。OpenAI3 人 / 5 个月 / 100 万行 / 0 手写这是目前最炸裂的案例。三个工程师在五个月内完全由 AI Agent 生成了超过 100 万行生产级代码没有一行是人类手写的。他们的秘诀不是用了更强的模型而是三条 Harness 原则第一“仓库是唯一事实源”。所有规范、约束、决策记录全部沉淀在代码仓库里。写在 Slack 里的知识对 Agent 来说等于不存在。第二“约束靠工具强制执行不靠文档”。自定义 Linter 里内嵌了修复说明Agent 犯错时直接告诉它怎么改而不是让它去翻一个 200 页的规范文档。第三“AGENTS.md 是地图不是手册”。100 行搞定只告诉 Agent 去哪找信息不把信息本身堆进去。AnthropicGAN 式三智能体架构Anthropic 的做法更有控制论美感。他们设计了 Planner-Generator-Evaluator 三个角色形成类似 GAN生成对抗网络的对抗式结构。Planner 拆解任务Generator 执行Evaluator 独立审核。Generator 和 Evaluator 用相同模型但完全隔离上下文确保评估的独立性。他们还发现了一个关键操作Context Reset。当上下文使用超过 40%不是去压缩而是直接起一个新鲜 Agent用结构化的交接文档传递状态。这比任何压缩算法都管用因为它从根本上消除了上下文污染。Stripe每周 1300 无人值守 PRStripe 的 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 hooksruff mypy pytest。确保 Agent 每次改完代码都自动跑一遍检查。这三件事做完你的 Agent 输出质量就能提升一个档次。# .pre-commit-config.yamlrepos:-repo:https://github.com/astral-sh/ruff-pre-commithooks:-id:ruffargs:[--fix]-repo:https://github.com/pre-commit/mirrors-mypyhooks:-id:mypyadditional_dependencies:[types-all]-repo:localhooks:-id:pytest-checkname:Run testsentry:pytest tests/-x-qlanguage:systempass_filenames:falseLevel 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。