什么是 Harness Engineering（驾驭工程）？概念、架构、实战一文讲透

一个 AI 编程工具的源码里，98.4% 不是 AI 在做决策——而是在管 AI。这个数字来自 VILA-Lab（新加坡国立大学的 AI 研究团队）对 Claude Code 源码的学术拆解：约 1900 个文件中，只有 1.6% 涉及模型推理逻辑，剩下全是工具注入、权限管控、上下文压缩、状态持久化和安全检查。让 AI Agent 真正能干活的，不是模型本身，而是围绕模型搭建的那套运行系统。这套系统有一个刚刚成型的名字——驾驭环境（harness，围绕模型搭建的工具、权限、验证和状态管理体系）。围绕驾驭环境的工程学科叫驾驭工程（harness engineering）。2026 年 2 月，OpenAI 和 Mitchell Hashimoto 几乎同时独立提出了这个概念；三个月后，搜索量从月均 20 暴涨到 27000。这篇文章把驾驭工程讲透——定义、架构、权威实践、翔宇知识库的真实四层案例、诚实批判、入门路径，一次讲完。不贩卖焦虑，只讲清楚事实。

要点速览

• 驾驭工程是围绕 AI 模型搭建运行环境的工程学科——管工具注入、状态管理、验证循环、约束分层，让 Agent（能自主执行多步任务的 AI 系统）从「能干活」变成「稳定可靠地干活」。
• 同一个模型，换驾驭环境就能拉开巨大差距——LangChain 实证：模型不变，纯靠驾驭环境优化，Terminal Bench 2.0（评测 AI 编程 Agent 能力的基准测试）得分从 52.8% 升至 66.5%。
• 驾驭工程不等于提示词工程，也不等于上下文工程——提示词管「怎么问」，上下文管「看到什么」，驾驭环境管「整个系统怎么运转」。三者层层包含，不是互相替代。
• 多个生产系统已经跑通——OpenAI 用约 100 万行 Agent 生成代码构建内部产品，Anthropic 用三 Agent 架构让长时任务可靠运行，翔宇知识库用四层驾驭环境管理日常 AI 编程工作流。
• 驾驭环境不是万能药——遗留代码库难受益、过度约束会拖慢产出、当前模型的弱点补偿可能在下一代模型面前失效。

什么是驾驭工程（Harness Engineering）

驾驭工程是围绕 AI 模型搭建运行环境的工程学科。模型负责推理，驾驭环境负责模型之外的一切——工具调用、权限管控、验证循环（AI 完成任务后自动检查加修复的闭环）、状态持久化、可观测性。

社区有一个简洁的等式：Agent = 模型 + Harness（即 Agent = 模型 + 驾驭环境）。

AI 模型再强，没有配套的驾驭环境，就只是一个「会思考但不会做事」的大脑。驾驭环境给它装上手脚、定好规矩、安上雷达。

我认为驾驭环境是 AI 编程中被严重低估的环节——大多数人只盯着模型能力。VILA-Lab 的学术研究印证了这个判断：他们拆解了 Claude Code 的完整源码结构，量化结论是 1.6% 是 AI 决策逻辑，98.4% 是运行基础设施。这 98.4% 涵盖约 1900 个 TypeScript 文件，包括工具注入、权限管理、上下文压缩管线、状态持久化和安全检查。

驾驭工程包含四个核心子系统，在后文会逐一展开：

1. 工具注入——让 AI 能操作外部工具和数据源
2. 状态管理——跟踪任务进度、持久化关键信息
3. 验证循环——自动检查产出质量并在出错时修复
4. 约束分层——通过规则文件和权限管控限定 AI 的行为边界

💡 通俗讲：「Harness」这个词的本义是马具——缰绳、马鞍、嚼子。骑手不是要削弱马的力量，而是用这套装备让马的力量变得可控。驾驭工程对 AI 做的事一模一样：AI 模型是那匹马，能力强但不受控；驾驭环境是那套马具，让这匹马听你的指令、走你规划的路线、在该停的地方停下来。你不会骑一匹没有缰绳的马上路——同理，你也不该让一个没有驾驭环境的 Agent 替你写生产代码。

驾驭工程从何而来？从 OpenAI 博文到工程学科

驾驭工程不是凭空冒出来的。AI 工程范式经历了三次演进，驾驭工程是最新一次。

第一阶段：提示词工程（prompt engineering），2023—2024 年

这个阶段的核心问题是「怎么问问题」。你对 ChatGPT 说「帮我写一个 Python 脚本」，然后调整措辞让输出更好。作用域是单条提示，目标是优化一问一答的质量。

第二阶段：上下文工程（context engineering），2025 年

Shopify CEO Tobi Lutke 在 2025 年 6 月 18 日发了一条推文，传播很广：「I really like the term context engineering over prompt engineering. It describes the core skill better: the art of providing all the context for the task to be plausibly solvable by the LLM.」这条推文把「上下文工程」推到台前。核心问题从「怎么问」变成了「让模型看到什么信息」——不再只优化那一句话，而是精心组织模型接收的全部输入。

第三阶段：驾驭工程，2026 年

2026 年 2 月 5 日，Mitchell Hashimoto（HashiCorp 联合创始人、Ghostty 终端开发者）在博客文章《My AI Adoption Journey》中描述了他的实践，并给这种做法起了个名字——harness engineering。他的定义朴素到不能再朴素：「anytime you find an agent makes a mistake, you take the time to engineer a solution such that the agent never makes that mistake again.」每次 AI 犯错，你就花时间设计一个方案，让它再也不犯同样的错。

六天后，2026 年 2 月 11 日，OpenAI 工程团队的 Ryan Lopopolo 发表了一篇正式文章，给驾驭工程下了系统定义。他探讨的核心问题是：当软件工程团队的首要工作不再是写代码，而是设计环境、明确意图、构建反馈循环来让 Codex Agent 可靠工作时，一切会怎么变。

这篇文章是驾驭工程从个人实践升格为正式工程学科的节点。

两人几乎同时、各自独立地提出了同一个概念。这不是巧合——AI Agent 一旦进入生产环境，「怎么管好 Agent」的问题自然会浮出来。Hashimoto 从一线实践出发，OpenAI 从团队工程管理出发，殊途同归。

三个阶段不是替代关系，而是层层叠加。做好驾驭工程的人必须懂上下文工程，懂上下文工程的人必须懂提示词工程——就像建学校的人也得会编教材、出考题。

驾驭工程、上下文工程和提示词工程有什么区别？

三个概念经常混用。它们确实有交叉，但搞混了就会在错误的层面上解决问题。

技术社区总结了一条快速定位的判断标准：

• AI 在单步任务中输出模糊、格式错误 → 提示词工程的问题，收紧指令就行。
• AI 拿到的信息不对、遗漏了关键背景 → 上下文工程的问题，调整输入。
• AI 多步执行时崩溃、陷入循环、结果不可预测 → 驾驭工程的问题，要重新设计系统。

这条标准能防止你在错的层面浪费时间。很多人遇到 Agent 多步任务失败，第一反应是「改提示词」——但真正的问题往往不在措辞，而在缺少验证循环或状态管理。

💡 通俗讲：还是用前面的学校类比。提示词工程是出考题——怎么把题目出得让学生理解。上下文工程是编教材——学生拿到什么参考资料决定了能不能答对。驾驭工程是整个学校的运转系统——课程表、考勤、批改流程、补考制度、教学质量检查。你不会因为学生成绩差就重写考题，你会去查教学系统是不是有环节失灵了——是教材漏了关键章节（上下文问题），还是根本没有批改流程导致错误累积（驾驭环境问题）。

驾驭环境由哪四个子系统组成？

定义和定位讲清楚了，接下来拆内部架构。驾驭环境的四个核心子系统分成两大类：前馈引导（feedforward guides）和反馈传感器（feedback sensors）。前者是工作前就设好的约束——赛道护栏；后者是工作后检测结果好坏的机制——雷达。这个二元模型来自 Martin Fowler 网站上 Birgitta Boeckeler 的分析框架。

子系统一：约束分层（前馈）

约束分层是驾驭环境的第一道防线——AI 还没开始干活，边界就已经划好了。

具体的约束载体：

• 规则文件：Claude Code 的 CLAUDE.md（项目级指令文件）、Codex 的 AGENTS.md（项目级指令文件），告诉 AI「在这个项目里，什么能做、什么不能做、怎么做」。
• 类型系统和代码检查器：编程语言的类型检查和代码检查器（linter，自动检查代码格式与风格的工具），机械性执行——不靠 AI「理解」，硬性拦截不合规的代码。
• 权限管控：明确 AI 能访问哪些文件、能跑哪些命令。VILA-Lab 的研究发现，Claude Code 的权限系统包含七种权限模式和一个机器学习分类器，采用「默认拒绝」设计。

约束分层的底层逻辑：约束比能力更值钱。OpenAI 的内部产品里，所有架构约束都由定制代码检查器和结构化测试机械性执行——代码只能沿固定层序依赖（Types → Config → Repo → Service → Runtime → UI），违反即失败。不是「建议」，是物理定律级别的硬约束。

子系统二：工具注入（前馈）

工具注入让 AI 从「只会思考」变成「能动手干活」。

MCP（模型上下文协议，Model Context Protocol）是目前最主要的工具注入标准——像一个万能插座，让 AI 能连接外部工具和数据源。通过 MCP，Agent 可以读写文件、执行命令、调用 API、查询数据库。

VILA-Lab 的源码分析显示，Claude Code 内置 19 个无条件工具和 35 个条件工具，加上 MCP 扩展工具。但 Claude Code 产品负责人 Cat Wu 强调了一个反直觉的原则——工具宁少勿多。她说，团队只保留最小可行工具集：做计划、做待办、编辑文件、问澄清问题。除非某个工具明确提升了 token（AI 处理文本的最小单位）性能或准确度，否则默认不加。

OpenAI 的做法也是同一个思路：约 100 行的 AGENTS.md 只当「目录」用，不把所有指令塞进一个庞大的文件。实际指令分散在结构化的 docs/ 目录中，由专用代码检查器、CI 任务和一个定期运行的「doc-gardening」Agent 维护。

子系统三：验证循环（反馈）

验证循环是驾驭环境里最关键的子系统——没有验证循环的驾驭环境，就是没有刹车的汽车，能跑，但迟早出事。

Anthropic 的实践给出了四级递进的验证方案：

1. 单条提示级：在同一句话里要求「跑测试、失败就修」。
2. 目标条件级：每轮自动复查是否达成目标。
3. Stop hook 级：测试不过就阻止会话结束——这是确定性的强制检查，AI 无法绕过。
4. 子 Agent 第二意见：用一个独立的 Agent，在干净的上下文窗口（AI 一次能看到的信息总量上限）里复核结果。

为什么需要第四级？因为 Anthropic 自己的研究确认了一件事：Agent 给自己打分时「可靠地倾向于正面评价」——太宽容，容易说服自己 bug 不严重。所以驾驭环境必须拆开「生成者」和「检查者」两个角色。

CLAUDE.md 和验证钩子（hooks，AI 执行工具调用前后自动运行的脚本）构成两级执行模型。关键区分：CLAUDE.md 是建议性的——文件太长时模型可能忽略；验证钩子是确定性的——退出码 2 无条件阻止，模型绕不过去。从「希望 Agent 做对」到「保证 Agent 做对」，验证钩子就是那道分水岭。

子系统四：状态管理（反馈）

状态管理解决的是 Agent 的「记忆」问题——上下文窗口有限，长任务里早期信息会压缩甚至丢失。

Claude Code 采用五层压缩管线管理上下文：预算缩减 → 时序裁剪 → 微压缩 → 上下文折叠 → 自动压缩（模型生成的语义摘要，作为最后手段）。每次模型调用前依次运行这个管线。

但压缩不是万能的。Anthropic 的长任务驾驭环境设计文档坦承：超出单次上下文窗口的任务，上下文重置是必要选择——但重置本身会增加编排复杂度和 token 开销。解决方案是子 Agent（subagent，主 Agent 派出去执行单独任务的独立 Agent）机制：子 Agent 在独立的上下文窗口中工作，完成后只把摘要返回给主 Agent，保护主 Agent 的上下文资源。

Anthropic 的文档原话很精练：上下文是你最根本的约束，子 Agent 是最强大的工具之一。Agent 研究代码库时会读大量文件，全部消耗上下文；子 Agent 在独立窗口运行，只把摘要报回来。

🔍 深入一步：四大子系统在 Claude Code 中有明确的对应关系。约束分层 = CLAUDE.md + settings.json 权限配置；工具注入 = MCP 协议 + 内置工具集；验证循环 = 验证钩子（PreToolUse / PostToolUse 脚本）+ 测试命令集成；状态管理 = 五层压缩管线 + 子 Agent 上下文隔离 + 会话持久化。如果你用 Claude Code，你已经在这套驾驭环境架构里工作了——区别只在于你是被动接受默认配置，还是主动设计自己的驾驭环境。关于 CLAUDE.md 的写法，可以参考 CLAUDE.md 编写指南；关于验证钩子配置，可以参考 Claude Code hooks 实战指南。

OpenAI、Martin Fowler、LangChain、Anthropic 怎么搭驾驭环境？

驾驭工程不是某一家的理论——多个头部团队在生产中独立验证了同一套方法。逐一看各家的做法和发现。

OpenAI：百万行代码零人写

OpenAI 在内部产品中做了一次大规模驾驭工程实验。约 100 万行代码全由 Codex 生成，零行手写。约 1500 个 PR（代码合并请求），团队从 3 人起步、后扩至 7 人，人均每天 3.5 个 PR。OpenAI 估计效率是手写代码的十倍。

这个案例里最值得看的不是产出量，而是驾驭环境的设计决策：

• AGENTS.md 约 100 行，只当目录用，不当百科全书。
• 所有架构约束由代码检查器和 CI 机械性执行，不靠 Agent「理解」。
• 代码只能沿固定层序依赖，违反即编译失败。
• 单次 Codex 运行可达 6 小时，驾驭环境必须保证长时任务的一致性。
• 团队每周五拿 20% 时间清理 AI 残留代码，后来改成自动化。

🔍 深入一步：OpenAI 把 AGENTS.md 当「目录」而非「百科全书」——不要在规则文件里堆砌所有细节。文件越长，模型越容易忽略关键条目。正确做法是写「指向」（去 docs/auth/ 看认证流程），不是写「内容」（以下是完整的认证流程……）。Claude Code 用户可以用同样的思路组织 CLAUDE.md——保持简洁，用链接和文件引用代替长篇正文。

Martin Fowler 站：前馈与反馈的二元框架

Birgitta Boeckeler 在 Martin Fowler 网站上发表的文章，提出了一个清晰的心智模型：驾驭环境 = 前馈引导 + 反馈传感器。前馈引导是事前约束——规则文件、类型系统、权限配置，在 Agent 行动前就缩小解空间。反馈传感器是事后检测——lint 结果、测试通过率、构建退出码，在 Agent 行动后判断结果好坏并触发修正。

她还提出了一个关键观点：「可驾驭性」（harnessability）应该成为技术选型的一等指标。选框架、选语言、选工具链，都要看它们对 AI Agent 有多「友好」——能不能方便地加规则、加验证、加权限管控。

LangChain：同模型、纯驾驭环境优化，+13.7 分

LangChain 团队在 Terminal Bench 2.0 基准测试上做了一次干净的对照实验：同一个模型 gpt-5.2-codex 不变，只优化驾驭环境，得分从 52.8% 升至 66.5%——提升 13.7 个百分点，排名从约第 33 位跃升至前 5。

三个关键优化方向：

1. 系统提示优化：注入结构化的问题解决方法论。
2. 工具优化：调整 Agent 可用的函数和能力集。
3. 中间件优化：在模型调用和工具执行的前后加钩子。

其中最有效的是 PreCompletionChecklist 中间件——Agent 宣布「任务完成」之前先拦住，强制跑一遍验证循环。还有一个反直觉的发现：推理预算不是越高越好。他们试了「推理三明治」策略——规划阶段用最高预算、实现阶段用标准预算、验证阶段再拉回最高预算，最终得分 66.5%，远高于全程最高预算的 53.9%。

Anthropic：三 Agent 架构与成本实证

Anthropic 在长时运行应用中测试了三 Agent 架构：

为什么要拆成三个？因为生成者和评估者必须分离。前面提到过，Agent 给自己打分时可靠地偏向正面——太容易对自己的产出手下留情。

成本数据很坦诚：单 Agent 模式跑 20 分钟花 $9，核心功能不可用——等于没产出。完整驾驭环境跑 6 小时花 $200，功能完整可运行。后续 V2 版本移除了冲刺结构，用时 3 小时 50 分钟，费用 $124.70。

这组数据的关键信息不是「$200 很贵」，而是「$9 的产出价值为零」。驾驭环境的投入不是在原有成本上加码，而是从「不可用」跨到「可用」的门票。

Mitchell Hashimoto：逐行消灭 Agent 错误

Hashimoto 在 Ghostty 项目中的做法极其朴素：AGENTS.md 里每一行规则，都对应一个他观察到的 Agent 实际犯错。一句话总结效果：「Each line in that file is based on a bad agent behavior, and it almost completely resolved them all.」

他把驾驭工程分成两种形式：

1. 隐式提示：针对简单问题（用错命令、找错 API），在项目文件里记录纠正。
2. 实际编程的工具：截图脚本、过滤测试脚本等——当提示不够用时，就写代码解决。

他还提出了一条关键原则：给 Agent 一个能验证自己工作的方法，它通常就能自己修复错误。「If you give an agent a way to verify its work, it more often than not fixes its own mistakes and prevents regressions.」

Hashimoto 主动声明了无商业利益：他不在任何 AI 公司工作、投资或当顾问。这让他的实践报告多了一层可信度。

🔍 深入一步：五家视角有一个共同主题——约束是资产，不是障碍。OpenAI 用代码检查器硬性执行架构规则，LangChain 用中间件在 Agent 退出前强制验证，Anthropic 用独立 Agent 交叉检查，Hashimoto 用规则文件逐行消灭错误，Fowler 站把约束分成前馈和反馈两类。人不同、场景不同、实现方式不同，但底层逻辑一致：设计好的约束让 Agent 更强，而不是更弱。

翔宇知识库的四层驾驭环境架构

行业权威的做法讲完了，这一节回到翔宇自己的实践。翔宇知识库是一个真实运行中的 AI 编程工作系统——日常用 Claude Code 和多 Agent 协作处理内容创作、课程制作、代码审计、SEO 运营等任务。驾驭环境从 2025 年底开始迭代，从一个 CLAUDE.md 文件起步，逐步长成了四层体系。

这套体系没有做过一次「整体架构设计」。每一层都不是预设的——实际运行中踩了坑、补了漏洞、把修复沉淀为结构，四层才逐步浮现出来。这正好呼应了驾驭工程的核心思路：你不需要蓝图，你需要的是不断观察、不断修补的迭代循环。

下面逐层展开，看每一层解决了什么问题、内部长什么样、为什么是这个样子。

第一层：约束层——CLAUDE.md 多级治理与规范体系

约束层是整个驾驭环境的地基，回答一个最基础的问题：Agent 在这个系统里，什么能做，什么不能做，怎么做。

四级 CLAUDE.md 层次结构

翔宇知识库的 CLAUDE.md 采用四级层次结构，每一级管自己的范围，不向上越权：

1. 全局级（~/.claude/CLAUDE.md）——跨所有项目通用的规则。比如思考语言用英文、交互语言用简体中文、语言风格三层契约（标识符英文不译、概念首现括注英文、散文纯中文）。这些规则不因项目不同而改变。
2. 项目级（kb/CLAUDE.md）——知识库专属规则。这是内容最重的一级，涵盖行为准则、工具路由表、知识库导航索引、凭据路径、规范入口。Agent 进入知识库项目后，首先读到的就是这份文件。
3. 工作流级（各工作流目录内的 CLAUDE.md）——特定工作流的规则。比如「翔宇-创作-Ghost-文章」这个工作流的 CLAUDE.md 定义了管线严格串行的铁律、正本双路输出规则、数字与事实溯源红线。这些规则只在这个工作流内生效。
4. 子工作流级——更细粒度的规则。比如一个 Ghost 文章工作流内部有检索取材、静态质检、动态精修等子工作流，每个子工作流可以有自己的补充指令。

这种层次结构的逻辑和编程中的作用域一样：全局变量管全局，局部变量管局部。Agent 在工作流 A 里看到的规则不会干扰工作流 B。规则冲突时，局部覆盖全局——和 CSS 的优先级一个道理。

规模感知：超过 1500 个 CLAUDE.md 文件

整个知识库中分布着超过 1500 个 CLAUDE.md 文件。这个数字不是刻意追求的——知识库自然生长的结果。每个工作流、每个子目录、每个工具只要有「Agent 需要知道的规则」，就会有一个 CLAUDE.md。这些文件从几行到几百行不等，但每一个都有明确的职责边界。

规模本身就是驾驭环境成熟度的指标。只有一个 CLAUDE.md 的项目和有 1500 个 CLAUDE.md 的系统，驾驭环境的深度完全不同——后者意味着系统的每一个角落都有明确约束，Agent 走到哪里都知道该守什么规则。

真实的规则长什么样

项目级 CLAUDE.md 中有一节叫「行为准则」，里面的每一条规则都短、硬、可执行。举几个代表性的例子：

- **工具优先**：先查工具路由表，优先用本地 CLI；路由表未覆盖再降级 MCP，禁止跳过直调
- **改前读规范**：新建或修改产出物前，先到 `规范/CLAUDE.md` 定位对应规范
- **向前演进**：改 Skill / CLI / 规范 / 文档直接覆盖正确做法，不向后兼容、不加历史警告
- **工具沉淀**：高频复用的操作（≥3 次）先封装或扩展到对应 CLI，再使用
- **文档同步**：新增/删除/修改文件后，立即检查并更新上下游关联文档

注意这些规则的特征：每条都有明确的动作指令（「先查」「先到」「直接覆盖」），没有模糊的「建议」「尽量」。它们不是给人看的编码规范——它们是 Agent 的行为约束清单，读到就必须执行。

「工具优先」这条规则背后对应的是一次真实的 Agent 犯错：Agent 跳过了本地 CLI 路由表，直接调用了外部 MCP 服务，结果因为 MCP 限流导致任务中断。加了这条规则后，同类问题消失了。「改前读规范」对应的是 Agent 在创建新文档时没有先查阅格式规范，产出了不合规的文件结构。「向前演进」对应的是 Agent 在修改规范时保留了旧的做法、加了「已废弃」警告，导致知识库里积累了大量过时信息。

每一条规则都能追溯到一次真实的 Agent 犯错——和 Hashimoto 的「把 AGENTS.md 当失败日志写」原则完全一致。没观测到的问题就不写规则。规则文件是失败记忆的持久化，不是一厢情愿的最佳实践文档。

20 套编写规范：Agent 行为的标准化契约

CLAUDE.md 是运行时约束——Agent 每次执行任务时实时读取。但有些约束需要更系统化的表达：「Agent 工具应该怎么写」「SEO 文章应该满足哪些硬指标」「CLAUDE.md 本身应该遵守什么格式」。这类约束沉淀在规范体系中。

翔宇知识库维护了 20 套编写规范，覆盖从 Agent 工具到品牌身份到生活管理的完整范围：

这些规范不是「建议参考」，而是 Agent 行为的标准化契约。CLAUDE.md 里的「改前读规范」这条规则是桥梁：Agent 创建任何新产出物之前，必须先到规范体系中找到对应规范并遵守。规范定义「什么是正确的」，CLAUDE.md 规则保证「Agent 会去查什么是正确的」。

两层配合形成约束层的完整闭环：CLAUDE.md 管运行时行为，规范管产出物质量，互相引用、互相执行。

🔍 深入一步：规范体系中有一个特殊成员——「翔宇规范编写规范」，也就是「管规范的规范」。所有规范本身应该遵守什么格式、什么章节结构、什么语言风格，都由这份元规范定义。这种自指结构保证了规范体系的一致性——新加的规范不会偏离已有风格。用驾驭工程的视角看，这相当于约束系统的自举（bootstrap）：先有一条元规则，再基于元规则生成所有其他规则。

第二层：工具层——本地 CLI 优先，MCP 降级

约束层管「什么能做、怎么做」，工具层管「用什么做」。Agent 再聪明，手里没有趁手的工具，也只能纸上谈兵。

「本地 CLI 优先、MCP 降级」的路由原则

翔宇的工具层有一条核心路由原则：所有操作优先走本地命令行工具，本地工具覆盖不到时才降级到 MCP 外部服务。

出发点是确定性。本地工具行为可预测——相同输入总是产生相同输出，不存在网络超时、API 变更、限流等不确定因素。你可以在本地调试、版本化、写测试。MCP 外部服务说到底是远程调用，网络链路上任何波动都可能让 Agent 中途断掉。

驾驭工程追求的是系统可预测，不是功能花哨。一个每次都能跑通的简单工具，比一个功能丰富但隔三差五超时的外部服务更有价值。

工具矩阵：覆盖十余个品类

翔宇的本地命令行工具覆盖搜索、发布、云服务、开发调度、数据、多媒体、文档转换等十余个品类。每个工具用统一命名格式组织（xiangyu-{大类}-{名称}-cli），Agent 通过 CLAUDE.md 中的路由表查找对应工具。

几个代表性工具：

• 搜索统一入口（xiangyu-search-hub-cli）——全平台搜索、下载、采集都走这一个入口分发。搜网页、抓文章原文、下载视频、批量采集素材——Agent 不需要记住不同平台用不同命令。
• 内容发布（xiangyu-cms-publish-cli）——Ghost 和 WordPress 的发布统一走这个工具，包括文章创建、更新、标签管理、图片上传。发布是高风险操作（发错了线上立即可见），用本地工具封装比让 Agent 直接调 API 安全得多。
• 云存储（xiangyu-cloud-r2-cli）——Cloudflare R2 资产上传。所有文章配图、封面、资源文件通过这个工具上传到 R2，返回可用的公开 URL。
• 多 Agent 调度（xiangyu-dev-farm-cli）——把批量任务分派给多台机器上的多个 Agent 并行跑。这是第四层编排层的核心执行器，但本身属于工具层。
• 运行时预检（xiangyu-dev-runtime-cli）——工具、工作流或 Skill 启动前做环境预检（依赖装了没有、凭据能不能用、磁盘空间够不够），避免跑到一半才发现环境有问题。

除了命令行工具，翔宇的 AI 编程实操课还交付了多个封装好的 Skill（可复用 AI 能力包），覆盖股票分析、书签整理、法律咨询、创剪视频、社区热点挖掘、社交平台配图等场景。每个 Skill 是一个自包含的能力单元：接收输入，按内置逻辑执行多步操作，产出结构化结果。对 Agent 来说，调用 Skill 和调用工具没有区别，只是 Skill 封装的逻辑复杂度更高。

工具沉淀原则：复利资产

工具层不是一次性设计好的——在日常工作中逐步沉淀出来的。CLAUDE.md 中有一条规则叫「工具沉淀」：高频复用的操作（≥3 次）先封装或扩展到对应 CLI，再使用。

背后的逻辑是复利。第一次手动操作花 5 分钟，第二次还是 5 分钟，第三次封装成工具花 30 分钟——但从第四次开始，每次只要 10 秒。100 次操作下来，手动执行要 500 分钟，封装后只要 30 + 16.5 ≈ 47 分钟。工具是迭代积累的复利资产，投入越早，回报越大。

这也解释了为什么翔宇的工具数量持续增长——不是追求「工具多」，而是每一个工具都对应一个反复跑的操作。当你第三次手动执行某个操作时，正确的反应不是「继续手动」，而是「停下来，先把它变成工具」。

🔍 深入一步：本地工具优先还有一个隐含好处——可审计性。Agent 用本地工具做操作时，源码就在你的项目里，你能精确知道它做了什么。MCP 外部服务是黑盒——请求发出去，拿到响应，中间发生了什么你管不了。涉及密钥、发布、删除等敏感操作时，可审计性的差距是质的区别。

第三层：验证层——Agent 工作流管线与三层评审

约束层定规矩，工具层给工具，但光有这两样还不够——Agent 仍然可能在规矩允许的范围内产出低质量结果。验证层的职责是：产出交付之前，用系统化的检查机制确保质量达标。

以本文为例：一条完整的内容生产管线

翔宇的 Agent 工作流管线覆盖内容创作、SEO 运营、代码审计、课程制作等多种场景，每个工作流都是一条自包含的生产线。

你正在读的这篇文章，就是一条 Ghost 文章工作流的完整产物。管线由十多个子工作流严格串行组成：

1. SEO 立意——确定主关键词，分析搜索引擎结果页面的竞品缺口，明确差异化价值，画出四类读者画像。整条管线的输入源头，后续所有子工作流都依赖这一步的产出。
2. 检索取材——三档独立子 Agent 并行做多源检索（权威一手文献、技术社区实践报告、学术论文），采集术语通俗解释、匹配课程内容、预验证事实。每个统计数字必须有可追溯的一手来源，核实不到就直接删除或降级为定性描述。
3. 整篇撰写——基于取材结果，先编译一份写作摘要（十板块自包含单文件），再按动态骨架写初稿，确保受众分层的术语解释、frontmatter 元数据、结构化数据标记三件套全部到位。
4. 静态质检（评审第一层）——客观硬门，一次过：平台安全合规（一票否决权）→ 中文可读性 → 事实核验 → SEO 静态指标检查。四个检查员串行跑，任何一个报 error 就打回修改。这一层不涉及主观判断，全是可量化的指标。
5. 动态精修（评审第二层）——主观多轮。八个角色组成的读者评审团逐一审读，每个角色从不同视角（技术深度、新手可读性、SEO 友好度、行文节奏、事实准确性等）提修改意见。最多四轮迭代，连续两轮卡在同一个问题上就停止迭代，进入下一阶段。
6. 用户研讨（评审第三层）——人拍板。Agent 把精修后的定稿连同评审历史呈现给用户，用户按维度菜单选择性审查，提出修改意见。Agent 生成结构化编辑清单并执行落地，再用 htmldiff（可视化差异对比工具）让用户确认每一处改动。循环持续到用户明确说「满意」。
7. 终审——发布闸门，双层设计。第一层是脚本兜底：七项硬指标自动检查（包括坏加粗语法检查、站内链接审计），全部通过才进入第二层。第二层是独立 Agent 深读终核——全新的上下文窗口，从头到尾读一遍定稿，专门检查术语误译、伪精确数字、配置编造、伪引文、FAQ 复读、跨篇同质化等容易被前面环节漏掉的问题。两层 error=0 才允许发布。
8. 配图——封面图（16:9 比例）加正文配图，全部上传到 R2 并回写到文章的 frontmatter 和正文中。
9. 发布——调用发布工具推送到 Ghost，线上即时生效。

为什么管线必须严格串行

整条管线有一条铁律：严格串行，禁止并行派发，禁止跳步。每个子工作流的产出是下一个子工作流的必要输入——SEO 立意喂给检索取材，检索取材喂给整篇撰写，以此类推。

这条铁律是真实教训换来的。早期试过让检索取材和 SEO 立意并行跑，结果取材方向和立意方向脱节，写出来的文章逻辑不连贯。还试过跳过静态质检直接进动态精修，结果评审团在主观审读时被大量客观错误干扰（断链、格式问题），精修效率大打折扣。

串行管线牺牲的是速度——一篇文章从立意到发布要走完全部子工作流。换来的是每一步产出都是下一步可靠的输入，最终产物的质量有系统性保障。

三层评审：客观硬门 → 主观多轮 → 人拍板

管线中嵌入的三层评审是验证层的核心机制，直接对应 Anthropic 的四级递进验证方案和「生成者与评估者必须分离」原则：

静态质检用确定性手段拦截客观问题——像编译器检查类型错误，不靠任何人的判断。动态精修用多视角审读发现主观问题——一个人容易有盲区，八个角色各看各的维度，覆盖面更广。用户研讨把最终决策权交给人——AI 评审团再强，也不能替人决定「这篇文章是不是我想要的」。

三层评审的核心设计理念：越往后，主观性越强，权威性越高。客观问题交给机器，主观问题交给 AI 评审团，最终决策交给人。每一层解决上一层解决不了的问题。

终审的双层发布闸

终审是管线的最后一道防线，设计体现了驾驭工程的一个核心原则：信任但验证（trust but verify）。

第一层是脚本兜底——七项硬指标自动检查：字数下限、frontmatter 完整性、坏加粗语法（Markdown 中 ** 未正确闭合）、站内链接的 HTTP 状态码、结构化数据标记是否合法。这些检查是机械性的，不靠 AI「理解」，也不可能被 AI 的自信说服跳过。

第二层是独立 Agent 深读终核——一个全新的 Agent 实例，干净的上下文窗口，不带任何前序子工作流的上下文包袱，从头到尾读一遍定稿。专门检查前面所有环节可能遗漏的问题：术语在不同段落中是否前后一致、引用的数字是否有出处标注、配置命令是否真实可执行、FAQ 段落是否和正文重复、同批次多篇文章是否同质化。

为什么需要「干净上下文」？因为前面跑了几个小时的 Agent 已经「深度参与」了创作过程，很难客观评价自己的产出。换一个全新 Agent，在全新上下文窗口里独立审读，就是用物理隔离来保证评估独立性。

两层 error=0 才允许发布。不是建议，是硬性约束。

第四层：编排层——多 Agent 调度与状态持久化

前三层解决了单个 Agent 执行单个任务的驾驭问题。但现实中经常碰到批量任务：一次性优化十几篇已发布文章、给全站配封面图、把一批书籍转换为 Markdown。单个 Agent 的上下文窗口容不下这种规模，执行时间也不允许。

Farm 调度：把任务分派给多个 Agent 并行执行

翔宇用 Farm 调度系统把批量任务拆成独立的子任务，分派给多台机器上的多个 Agent 并行跑。每个 Agent 在独立的上下文窗口中工作，互不干扰。

这和 Anthropic 三 Agent 架构的核心思想——子 Agent 保护上下文。一个 Agent 处理第 5 篇文章时，上下文窗口里只有第 5 篇的信息，不会被前 4 篇的细节干扰。隔离带来的好处是可预测性：第 12 篇文章得到的处理质量和第 1 篇一样，不会因为上下文窗口快满了而出现质量退化。

状态持久化：run 档案与断点续跑

每个 Agent 的执行状态通过 run 档案持久化——每次执行生成唯一的运行标识符，子工作流产出物版本化存入档案目录，进度写入状态文件，跨子工作流的产物交接通过制品索引追踪。

这种设计解决一个实际问题：长任务不可避免会中断。网络断了、上下文窗口满了、模型服务临时不可用——中断原因各种各样。没有状态持久化，中断就意味着从头来。有了 run 档案，Agent 可以从上次中断的位置继续跑（断点续跑），已完成的子工作流不需要重跑。

这一层对应 Anthropic 长时任务驾驭环境设计的核心命题：怎么让超出单次上下文窗口的任务可靠运行。答案是三个词：拆分（每个子任务控制在单次窗口可完成的范围内）、隔离（每个 Agent 有独立上下文窗口）、持久化（状态写到文件系统，不靠上下文窗口记忆）。

生成者和评估者分离

Farm 调度系统天然实现了生成者和评估者分离。执行任务的 Agent 和调度系统是两个独立角色——执行 Agent 只管把自己领到的子任务做完并报告状态，调度系统负责分派任务、汇总结果、处理失败重试。执行 Agent 改不了自己的任务描述，也跳不过调度系统设定的验收标准。

这种分离和 Anthropic 三 Agent 架构中 Generator 与 Evaluator 的关系一样：干活的和评判的不能是同一个实体，否则自评偏差会把质量门槛拉低。

四层不是蓝图，是生长记录

回顾四层架构，有一点很重要：它不是一开始就设计好的。

最初只有一个 CLAUDE.md 文件——几十行规则，记录 Agent 最常犯的错。后来发现手动操作太多，开始封装 CLI 工具。再后来发现工具跑了但产出质量参差不齐，开始加验证钩子和评审流程。最后发现单个 Agent 处理不了批量任务，引入了多 Agent 调度。

每一层都是真实问题逼出来的——遇到问题加一层约束，遇到瓶颈加一层工具。四层渐进叠加：约束层是地基，工具层是骨架，验证层是质量保障，编排层是规模化运行。先把约束层用熟，再逐步往上走，是我认为最务实的路径。

这正是驾驭工程的核心思路：不做顶层设计，在实践中迭代生长。

🔍 深入一步：翔宇选择「自包含工作流」的设计决策值得解释。每个 Agent 工作流把所需的风格库、评判标准、工具逻辑全部内化在自己目录里，不依赖外部共享模块。代价是会有一些内容重复——两个不同的工作流可能各自内化了同一份评审判据的副本。但换来的是：任何一个工作流都能独立运行，不会因为某个共享模块改动而意外崩溃。改工作流 A 的评审标准不影响工作流 B，两者按各自节奏独立演进。这是用冗余换可靠性的经典权衡——和 Anthropic 用 $200 换可用产出是同一种思维。系统达到一定复杂度后，「不崩溃」比「不重复」重要得多。

驾驭环境比模型更重要——四组数据为证

概念和架构讲完了，案例也看过了。但一个务实的问题还没回答：资源有限时，投入应该放在选更好的模型上，还是优化驾驭环境上？

我认为投入驾驭环境的回报远高于等下一代模型——模型进步幅度你控制不了，驾驭环境的改进却是确定性的。数据也支持这个判断。

证据一：LangChain，同模型 +13.7 分

模型 gpt-5.2-codex 完全不变，纯靠驾驭环境优化，Terminal Bench 2.0 得分从 52.8% 提升到 66.5%。这个提升幅度大于大多数模型换代带来的增量。

证据二：Opus 4.6，默认驾驭环境 #33 vs 定制驾驭环境 #5

同一个模型 Opus 4.6，在 Claude Code 默认驾驭环境中跑 Terminal Bench 2.0，排名约第 33 位。换成定制驾驭环境后跃升至约第 5 位（两个数字均有约 ±4 位浮动）。排名差了近 30 名——模型一行代码没改。

证据三：Anthropic，$9 的零产出 vs $200 的完整功能

单 Agent 模式花 $9 产出不可用。完整驾驭环境花 $200 产出可交付。如果你把 $9 的「产出」算作零价值，那么驾驭环境带来的不是 22 倍的成本增加，而是从零到一的质变。

证据四：OpenAI，约 100 万行代码的生产验证

约 100 万行 Codex 生成代码在五个月内合并到生产系统。3 到 7 人团队，效率约为手写的十倍。这个效率不是靠「模型更强」——同时期用同一模型但没有配套驾驭环境的团队，不可能复现这个产出水平。

四组数据指向同一个结论：模型能力正在趋于同质化，驾驭环境才是差异化壁垒。谁都能调用 GPT-5、Claude Opus、Gemini，但不是谁都能搭出高质量的驾驭环境。模型变成大宗商品时，围绕模型的工程能力就是真正的护城河。

🔍 深入一步：把模型比作引擎，驾驭环境比作整车。同一台引擎装在两辆车里，一辆有良好的悬架、制动和操控系统，另一辆只有四个轮子加一个方向盘——哪辆更快到目的地，不用多说。AI Agent 的竞争正在从「引擎大战」转向「整车工程大战」。你在提升驾驭环境上花的每一小时，比在等下一代模型发布上花的时间更有确定性回报。MCP 工具层的搭建方法，可以参考 Claude Code MCP 工具部署指南。

驾驭工程不是万能药——五个真实局限

讲到这里，如果你觉得驾驭工程能解决一切问题，那是因为前面只讲了正面。我认为驾驭工程有宣传过头的趋势——它有真实的局限性，回避它们是不负责任的。很多团队以为搭了驾驭环境就能自动获得 OpenAI 级别的产出。常见误区是以为加更多规则就万事大吉——过度约束反而拖慢 Agent 的执行效率。

局限一：遗留代码库几乎无法受益

Martin Fowler 网站的文章明确指出：驾驭环境在最需要的地方最难建立。十年以上的老代码库——架构约束缺失、测试覆盖不全、文档残缺——要让 Agent 在其中可靠运行，驾驭环境的建设成本远超绿地项目。前文提到的所有成功案例——OpenAI 的百万行代码、LangChain 的 Terminal Bench 提升、Anthropic 的三 Agent 架构——都来自绿地项目或从零搭建驾驭环境的团队。

局限二：过度约束是真实的失败模式

约束是资产，但过多就成了负债。Augment Code 的指南给了一个反直觉的警告：复杂度上限设得过低，合理的重构会被标记为违规；lint 规则拒绝合法模式，只会拖慢 Agent 而不提升质量。驾驭工程师面临的核心难题不是「要不要加约束」，而是「加多少约束刚好」——这本身就是一个需要反复调参、没有通用答案的工程问题。

Cat Wu 的实践也呼应了这一点：Claude Code 团队的做法是随模型变强，主动删除系统提示和工具描述中的脚手架——方法不是加规则，而是删规则。模型进步了，之前补偿弱点的变通方案就成了多余约束。

局限三：成本落差不可忽视

Anthropic 自己的数据摆在那里：完整驾驭环境流程花了 $200 和 6 小时。探索性原型或一次性脚本，这个投入可能不值得。驾驭工程适合的场景是：任务会反复跑、可靠性要求高、失败代价大。不是每个项目都符合这些条件。

局限四：Bitter Lesson 的阴影

Sutton 的「苦涩教训」（Bitter Lesson）在 AI 领域影响深远：历史表明，利用计算规模的通用方法最终总是胜过利用人类领域知识的专用方法。批评者把这条教训延伸到驾驭工程——你针对 2026 年模型弱点精心设计的驾驭环境，下一代模型可能直接把这些设计消解掉。你投入的工程时间，会被模型进步淘汰。

这个批评有道理，但也有反驳：驾驭环境中一部分是永恒的（比如「跑测试确认代码正确」「未经审查的代码不许合并到主分支」），一部分是临时的（比如「因为模型处理不好长文件所以限制文件长度」）。Cat Wu 团队持续删除系统提示脚手架的实践恰好说明了这一点——临时补偿可以删，核心验证逻辑不会过时。

怎么判断你的规则是永恒的还是临时的？问自己一个问题：如果模型变得比你还聪明，这条规则还需要吗？

• 「改完代码必须跑测试」——需要。正确性验证不取决于模型能力，再聪明的人也要考试。
• 「提交前必须经过代码审查」——需要。这是流程控制，不是能力补偿。
• 「限制单文件不超过 500 行因为模型处理不好长文件」——不需要。下一代模型的上下文窗口可能是现在的十倍，这条规则届时就是多余的摩擦。
• 「每次只改一个文件因为模型容易搞混多文件」——不需要。这是当前模型的弱点，不是永恒约束。

每次模型升级后，花半小时审视一遍你的规则文件，把第二类规则删掉。这就是 Cat Wu 说的「做减法」——你的驾驭环境应该随模型变强而变轻，而不是只增不减越来越臃肿。

局限五：「这不就是 DevOps 换了个名字吗？」

社区确实有这个质疑。拆掉模型，剩下的就是容器、可调用工具、读输出决定下一步的循环、日志、超时、清理——这确实和 DevOps（开发运维）工程师干了很多年的事有重叠。

区别在于约束对象不同。DevOps 约束的是人写的代码的部署流程；驾驭工程约束的是 AI Agent 的行为本身——怎么理解任务、怎么搜索信息、怎么验证输出、怎么记住教训。但两者确实共享底层逻辑：确定性约束优于人工审查、自动化验证优于手动检查、渐进信任优于全量授权。

有 DevOps 背景的人，驾驭工程上手会很快——核心心智模型已经具备了，要学的只是怎么把这套思维用到 AI Agent 这个新的约束对象上。

⚠️ 常见踩坑：过度设计驾驭环境的三个反模式。反模式一：规则文件膨胀——CLAUDE.md 写成万字百科全书，模型反而更容易忽略关键条目。正确做法：保持简洁，用链接指向详细文档。反模式二：全程最高约束——所有环节都设最严格的检查，Agent 每走一步都要等验证完成，效率比人工还低。正确做法：关键环节严验证、常规环节轻验证，参考 LangChain 的「推理三明治」思路分配资源。反模式三：只加不删——只加约束不删约束，驾驭环境越来越臃肿。正确做法：每次模型升级后审视现有约束，删掉因模型弱点而加的补偿性规则。

如何从零搭建你的驾驭环境体系？

概念、架构、案例、局限都讲完了。如果你现在想动手，该从哪里开始？

三步起手循环

不管你用什么 AI 编程工具——Claude Code、Cursor、Windsurf、Codex——都可以从这三步开始：

第一步：写一个规则文件

在项目根目录创建一个 CLAUDE.md（Claude Code 用户）或 AGENTS.md（Codex 用户）或 .cursorrules（Cursor 用户）。写下你希望 AI 遵守的基本规则：项目约定、代码风格、禁止操作。不用写很多——三五条就够。

第二步：观察 AI 犯错，记录下来

让 AI 做几次真实任务，把它犯的错记下来。哪个命令用错了？哪个文件不该改？哪个 API 调用参数不对？这些观察就是你改进驾驭环境的素材。

第三步：把观察到的问题变成规则

把第二步的记录变成第一步规则文件里的新条目。每加一条规则，AI 以后犯同样错误的概率就降低一次。

这三步循环下去，你的驾驭环境体系就在不知不觉中长起来了。Hashimoto 的 Ghostty 项目就是这么做的——AGENTS.md 里每一行规则对应一次观察到的错误，结果是「almost completely resolved them all」。

四层进阶路线

起步之后，按需逐层叠加：

第一层：约束层（难度最低，立即见效）

CLAUDE.md 或 AGENTS.md 就是起点。当失败日志写，每条规则追溯到一次真实失败。规则积累起来后，Agent 的行为会越来越可预测。

关于 CLAUDE.md 的系统写法，可以参考 CLAUDE.md 编写指南。

第二层：工具层（中等难度，扩展能力）

Agent 需要访问外部数据源或执行特定操作时，通过 MCP 接入工具。记住 Cat Wu 的原则：除非工具明确提升性能或准确度，否则默认不加。工具越少，驾驭环境越可控。

MCP 工具的部署方法，可以参考 Claude Code MCP 工具部署指南。

第三层：验证层（较高难度，保障质量）

加验证钩子——工具调用前后自动运行检查脚本。这是从「建议」到「强制」的关键一步。测试不过不许继续，代码检查器报错不许提交。

验证钩子的配置和实战案例，可以参考 Claude Code hooks 实战指南。

第四层：编排层（最高难度，规模化运行）

任务复杂度超过单个 Agent 的上下文窗口时，引入子 Agent 和多 Agent 协作。子 Agent 在独立窗口工作，保护主 Agent 的上下文。多 Agent 编排需要明确的状态管理和任务分派机制。

子 Agent 和多 Agent 协作的完整指南，可以参考 Agent 知识库和多 Agent 协作。

每一层都是在上一层稳定运行的基础上叠加。不要试图一步到位搭四层——先把约束层用熟，再逐步往上走。驾驭工程的核心不是架构图，而是持续观察、持续改进的迭代循环。

常见问题

驾驭工程和提示词工程有什么区别？

提示词工程管「怎么对 AI 说话」——单次输入的措辞优化。驾驭工程管「整个运行环境怎么防崩、量化、修」——系统级的工具注入、权限管控、验证循环和状态管理。两者是包含关系：驾驭工程包含提示词工程，但范围远大于后者。

谁提出了驾驭工程这个概念？

Mitchell Hashimoto 在 2026 年 2 月 5 日首次命名，OpenAI 的 Ryan Lopopolo 在 2 月 11 日正式定义。两人几乎独立提出。详细演进时间线见上文「驾驭工程从何而来」一节。

零基础学驾驭工程应该从哪里开始？

三步起手循环：写一个规则文件 → 观察 AI 犯错并记录 → 把问题变成规则。不需要任何框架或复杂工具，一个文本文件就能开始。推荐入门资源：WalkingLabs 的 Learn Harness Engineering（中英文，开源，有代码练习）。

驾驭工程和上下文工程是什么关系？

上下文工程管「给 AI 看什么信息」，驾驭工程管「AI 在什么环境里运行」。两者互补，不是替代。驾驭环境包含上下文管理（比如五层压缩管线），但还涵盖工具注入、权限管控、验证循环等上下文工程不涉及的范围。可以把上下文工程理解为驾驭工程的一个子集。

小项目需要做驾驭工程吗？

看复杂度，不看项目大小。一次性脚本、简单一问一答——不需要。但只要 AI Agent 需要多步执行、操作文件或调用外部工具，最简单的驾驭环境（一个规则文件加一条验证命令）就值得搭。起步成本很低，回报是确定性的。

Claude Code 用户怎么开始搭建驾驭环境？

从 CLAUDE.md 开始。记录项目约定和 AI 容易犯的错——每条规则追溯到一次真实犯错，不去预设「可能会犯」的错。然后加验证钩子和 MCP 工具。Claude Code 的驾驭环境是渐进式的，从一个文件开始逐步叠加。

Codex 用户的驾驭环境和 Claude Code 有什么不同？

底层逻辑相同——约束、工具、验证、状态管理。入口文件不同：Codex 用 AGENTS.md，Claude Code 用 CLAUDE.md，都支持层次化指令文件。执行环境有差异：Codex 在云端沙箱容器中跑，更封闭但更隔离；Claude Code 在本地跑，权限更灵活但需要更多手动管控。

驾驭工程有推荐的学习资源吗？

一手源推荐：OpenAI 官方博文《Harness Engineering》、Martin Fowler 网站的驾驭工程文章、LangChain 的《Improving Deep Agents with Harness Engineering》、Anthropic 的《Harness Design for Long-Running Apps》。入门课程推荐 WalkingLabs 的 Learn Harness Engineering（中英文，开源，有代码练习）。

驾驭工程的核心组件有哪些？

四大子系统：工具注入（让 AI 能操作外部工具和数据源）、状态管理（跟踪进度、持久化关键信息）、验证循环（自动检查产出质量并修复错误）、约束分层（规则文件和权限管控限定行为边界）。用前馈/反馈的二元模型理解：约束分层和工具注入是前馈（事前引导），验证循环和状态管理是反馈（事后检测修正）。

为什么说驾驭环境比模型更重要？

LangChain 的实证最直接：同一个模型不变，只优化驾驭环境，Terminal Bench 2.0 得分从 52.8% 升至 66.5%。Opus 4.6 在默认驾驭环境中排名约 #33，定制驾驭环境中跃至约 #5（两个排名均有约 ±4 位浮动）。模型能力正在趋于同质化——谁都能调用头部模型。驾驭环境设计才是差异化壁垒。投入在模型选择上的时间有天花板（模型就那几个），投入在驾驭环境优化上的时间没有天花板（改进空间永远存在）。

自检清单：你的驾驭环境体系搭好了吗

• [ ] 项目根目录有规则文件（CLAUDE.md / AGENTS.md / .cursorrules），且每条规则可追溯到一次真实 Agent 犯错
• [ ] 规则文件长度可控（不超过 100-200 行），用链接引用详细文档而非内联全文
• [ ] 有至少一个确定性验证机制（验证钩子 / 测试 / 代码检查器），Agent 无法绕过
• [ ] 验证结果能区分「通过」和「失败」，不依赖 Agent 自评
• [ ] 关键信息写在驾驭环境每轮重读的位置（规则文件），不依赖上下文窗口记忆
• [ ] 工具集遵循「最小可行」原则——能不加的工具就不加
• [ ] 长任务有状态持久化机制，断点可恢复
• [ ] 每次模型升级后审视过现有约束，删除了过时的补偿性规则
• [ ] 试过用子 Agent 隔离上下文密集型操作（如代码库全局搜索）
• [ ] 能说清楚驾驭环境的哪些约束是永恒的（测试必须通过）、哪些是临时的（当前模型的弱点补偿）

如果你想从零开始搭建自己的驾驭环境体系，翔宇的 AI 编程实操课提供了完整的实战路径：从 CLAUDE.md 编写（约束层）、验证钩子配置（验证层）、MCP 部署（工具层），到 Agent 知识库和多 Agent 协作（编排层），每个模块都有视频讲解和可跑的源码。

延伸阅读

相关教程

• CLAUDE.md 编写指南——驾驭环境约束层的核心入口
• Claude Code hooks 实战指南——从「建议」到「强制」的验证层搭建
• Claude Code MCP 工具部署指南——工具层的标准部署方法
• Agent 知识库和多 Agent 协作——编排层：子 Agent 和多 Agent 协作

参考来源

• OpenAI: Harness Engineering——Ryan Lopopolo 的正式定义文章
• Mitchell Hashimoto: My AI Adoption Journey——驾驭工程的首次实践命名
• Anthropic: Harness Design for Long-Running Apps——三 Agent 架构与成本实证
• LangChain: Improving Deep Agents with Harness Engineering——同模型 +13.7 分的干净对照实验
• Martin Fowler: Harness Engineering for Coding Agent Users——前馈/反馈二元框架
• VILA-Lab: Dive into Claude Code (arXiv 2604.14228)——1.6% AI 逻辑 / 98.4% 基础设施的学术分析
• Cat Wu: Ars Technica 采访——Claude Code 产品负责人谈做减法
• Augment Code: Harness Engineering for AI Coding Agents——前馈/反馈/质量门三层架构
• HumanLayer: Skill Issue — Harness Engineering for Coding Agents——Opus 4.6 排名对比实测
• Tobi Lutke: 上下文工程推文——推动上下文工程概念传播的原始推文