摘要：2026 年初，Harness Engineering（驾驭工程）在 AI 工程社区迅速崛起，成为继 Prompt Engineering、Context Engineering 之后的第三代方法论范式。本文从驾驭工程的核心概念出发，系统分析其与当前基于端到端算法的智能驾驶系统在全生命周期各阶段的深层对应关系，揭示两者在控制论框架、改进循环、失败应对哲学上的结构性同构，并详细阐述其对智能驾驶用户体验与安全工程（尤其是 SOTIF / ISO 21448）的参考价值。研究发现：驾驭工程与汽车安全工程并非表面相似的类比，而是面对同一类根问题的两套独立演化解法，共享同一套底层操作系统。
一、驾驭工程：第三代 AI 工程范式的崛起
1.1 概念与起源
Harness Engineering（驾驭工程） 是围绕 AI 智能体设计和构建约束机制、反馈回路、工作流控制与持续改进循环的系统工程实践。它不优化模型本身，而是优化模型运行的整个"环境"。
“Harness"一词来自马具——缰绳、马鞍、嚼子——一套引导强大但不可完全预测的动物的完整装备。驾驭工程不是去削弱 AI 的能力，而是为它打造一套完整的约束与引导系统，让它跑得又快又稳。
这个概念由 HashiCorp 联合创始人 Mitchell Hashimoto 在 2026 年 2 月 5 日首次提出。六天后，OpenAI 在其百万行代码实验报告中正式采用这一术语。随后 Martin Fowler 团队撰文深度分析，Anthropic 发布长时运行 Agent 最佳实践，一个月内"Harness Engineering"成为全球开发者社区的高频词。
Mitchell Hashimoto 的原始定义：
“Harness engineering is the idea that anytime you find an agent makes a mistake, you take the time to engineer a solution such that the agent will not make that mistake again in the future.”
每次 Agent 犯错，就工程化一个解决方案，确保它不再犯同样的错。
这句话的潜台词是：Agent 的每一次失败，都是环境设计不完善的信号。正确的回应不是换一个更强的模型，而是重新设计它运行的环境。
1.2 三次范式跃迁
驾驭工程的出现并非突然。AI 工程方法论经历了三次清晰的范式跃迁：
| 范式 | 时间 | 优化对象 | 解决的问题 | 交互模式 |
|---|---|---|---|---|
| Prompt Engineering（提示词工程） | 2023-2024 | 输入措辞、格式、示例 | 单次对话质量 | 一问一答 |
| Context Engineering（上下文工程） | 2025 | 文档、代码片段、历史对话 | 知识边界与幻觉 | 信息注入 → 生成 |
| Harness Engineering（驾驭工程） | 2026~ | 约束、反馈回路、控制系统 | Agent 可靠性与可持续性 | 人类掌舵，Agent 执行 |
一个易于理解的类比：
- Prompt Engineering —— 对马喊话的技巧
- Context Engineering —— 给马看的地图
- Harness Engineering —— 给马造一条高速公路，配上护栏、限速牌和加油站
1.3 为什么需要驾驭工程？实证数据
驾驭工程的必要性已被多个独立团队的实践数据验证：
OpenAI 百万行代码实验（来源）：3-7 人团队，5 个月，从空仓库到 100 万行代码，零手动编写的源代码。工程师的工作不是写代码，而是设计约束环境、明确意图、构建反馈回路。人均每日 3.5 个合并 PR，开发效率约为纯人类团队的 10 倍。
LangChain Terminal Bench 实验（来源）：底层模型一个参数都没动，仅优化外部驾驭环境（上下文注入、验证回路、追踪系统），编码 Agent 在 Terminal Bench 2.0 的得分从 52.8% 飙升至 66.5%，全球排名从第 30 位跃升至第 5 位。
Anthropic 长时运行 Agent 实践（来源）：系统总结了三大 Agent 失败模式和应对策略，提出"生成-评估分离"架构。
五个独立团队得出了相同结论：瓶颈不在模型智能，而在基础设施。
1.4 四大护栏体系
综合 OpenAI、Anthropic、LangChain 和 Martin Fowler 的实践，驾驭工程的核心可以归纳为四个组件：
护栏一：上下文工程（Context Engineering）——“新员工手册”
为 Agent 提供一个稳定、精简的入口文档（如 AGENTS.md），然后让 Agent 根据当前任务按需检索更多上下文。上下文是稀缺资源，过多的指导反而会挤掉任务空间，变成"陈旧规则的坟场”。关键原则：文档是活的反馈循环，不是静态制品——每发现一个 Agent 失败案例就更新一条规则。
护栏二：架构约束（Architecture Constraints）——“缰绳”
将所有架构规则编码为自动化检查工具（Linter、CI、类型系统），违反即阻止合并，无论代码是人写的还是 AI 写的。关键细节：Linter 的错误信息本身也是上下文工程——它不只说"你违规了"，还解释"为什么这个规则存在、正确做法是什么"，让 Agent 读到后能自我修正。
护栏三：反馈循环（Feedback Loop）——“智能体审智能体”
将代码审查从人对人变成 Agent 对 Agent：一个 Agent 做事，另一个 Agent 审查。如果 AI 写的测试用例"通过"了带有 Bug 的代码，Harness 判定测试无效，强迫它重新思考测试边界。
护栏四：熵管理（Entropy Management）——“垃圾回收”
采用持续小额偿还策略对抗技术债务积累。定期运行后台任务扫描偏差、更新质量等级、发起重构。还有专门的"文档园丁代理"（Doc-gardening Agent）在后台自动扫描文档与代码之间的不一致，发现过时内容就自动修复。
二、跨域映射：从编码智能体到智能驾驶的全生命周期
2.1 同一道题，两个战场
驾驭工程当前聚焦于 AI 编码智能体领域。但当我们将目光转向基于端到端算法的智能驾驶系统时，会发现一个被忽视的事实：两个领域在独立求解同一道根问题。
如何让一个能力强大但行为不可完全预测的智能系统，在开放环境中可靠运行？
| 维度 | AI 编码智能体 | 端到端智能驾驶 |
|---|---|---|
| 智能核心 | 大语言模型（GPT / Claude） | 端到端模型 / VLA / 世界模型 |
| 不可预测性来源 | 生成式输出的随机性 | 感知-决策链路的黑箱性 |
| 环境复杂度 | 代码库 + 依赖关系 + 用户意图 | 道路 + 交通参与者 + 天气 + 法规 |
| 失败代价 | 代码 Bug、安全漏洞、项目延误 | 碰撞、伤亡、品牌信任崩塌 |
| 核心诉求 | 可靠地产出高质量代码 | 安全且体验良好地行驶 |
两个领域独立演化，却收敛到了几乎相同的解法结构。这不是巧合——这是同一类问题的必然解。
2.2 控制论视角的完美同构
Martin Fowler 团队提出了 Harness 的控制论框架（来源）：
- Guides（前馈控制 / Feedforward）：在 Agent 行动之前引导它，提高首次正确率
- Sensors（反馈控制 / Feedback）：在 Agent 行动之后检测结果，驱动自我修正
两者缺一不可：只有前馈 → 编了规则不知道是否生效；只有反馈 → 反复犯同样的错。
这套控制论框架在汽车工程中早已存在：
| 控制类型 | 驾驭工程实践 | 智能驾驶实践 | 共同逻辑 |
|---|---|---|---|
| 前馈-规则型 | AGENTS.md、代码规范、架构约束 | ODD 定义、安全约束条件、设计准则 | 行动前划定边界 |
| 前馈-知识型 | 上下文注入、文档检索 | 高精地图、先验场景库、OSP | 提供环境先验知识 |
| 反馈-确定性 | Linter、类型检查、CI 测试 | 物理极限校验、碰撞检测、规则引擎 | 用确定性逻辑判定对错 |
| 反馈-智能型 | Agent-to-Agent Review | 独立安全监控模型、冗余感知校验 | 用另一个智能系统审核输出 |
| 反馈-人类型 | 人类代码审查（最终把关） | 安全员 / 远程监控员（人在环上） | 人类作为最终裁决者 |
值得特别注意的是前馈控制中的一个关键细节：Martin Fowler 强调 Linter 的错误信息本身也是前馈——它不只说"你违规了"，还解释"为什么以及怎么改"。在智能驾驶中，这一原则的对应物是降级策略的设计质量——系统不只是粗暴接管，而是向驾驶员或安全监控系统传递"为什么降级、当前状态、接下来该怎么做"的完整信息。降级策略本身就是一种面向用户的前馈控制。
2.3 失败模式的精确对应
Anthropic 在长时间运行 Agent 的实践中总结了三种典型失败模式（来源），这些失败在智能驾驶系统中有精确的镜像：
| 编码 Agent 失败模式 | 智能驾驶系统的对应失败 | 共同根因 |
|---|---|---|
| 一步到位（One-shotting）：上下文窗口耗尽，留下半成品 | 端到端模型在信息密集场景中"顾此失彼"——如复杂路口同时处理多个决策目标，注意力资源耗散，关键信号丢失 | 有限计算/注意力资源 vs 无限环境复杂度 |
| 过早宣布胜利：部分完成就停工 | 感知置信度虚高——模型对部分识别结果过度自信，忽略未检测区域的潜在风险 | 自我评估的系统性乐观偏差 |
| 过早标记完成：没做端到端测试 | 仿真指标达标 ≠ 实车体验安全——局部测试通过不代表系统级验证完成 | 验证层级不完整 |
| 模式复制与放大：忠实复制代码库中的坏模式 | 训练数据偏差的放大效应——长尾场景分布不均被模型忠实学习并放大 | 系统忠实复制环境中的既有模式，好的坏的一起复制 |
此外，Anthropic 还发现了一个危险特性：“当被要求评价自己的输出时，Agent 会自信地赞美自己——即使质量明显平庸。” 在智能驾驶中，这对应的是模型在自己的验证集上表现优秀，但在未见过的真实场景中表现退化——系统对自身能力的"评估"天然存在乐观偏差。
2.4 全生命周期六阶段映射
智能驾驶系统的开发与运营可划分为六个阶段。每个阶段都有对应的驾驭工程机制，也有对应的安全工程实践，三者构成结构性同构。
阶段一：数据采集与准备
| 驾驭工程原则 | 智能驾驶映射 |
|---|---|
| 上下文不是越多越好，按需检索、动态注入 | 数据不是越多越好。Rivian 的 Autonomy Data Recorder 选择性采集"重要、有趣的事件"，而非盲目录制所有行程 |
| AGENTS.md 随失败案例持续更新 | 每发现一个 corner case，反向驱动数据采集策略更新 |
| Mitchell Hashimoto 核心理念：每次犯错就固化一个防御 | SOTIF 要求的触发条件持续识别：每个 bad case 都应丰富采集策略 |
驾驭逻辑：数据层面的驾驭，核心不是暴力堆量，而是建立从失败到数据策略更新的闭环。
阶段二：模型训练与验证
| 驾驭工程原则 | 智能驾驶映射 |
|---|---|
| 架构约束：分层依赖模型，下层不反向依赖上层 | 即使端到端，也需要可监控的中间表征和模块化约束。UniSTPA 框架已将安全分析扩展至端到端模型内部组件（来源） |
| 生成与评估分离（Anthropic 的三 Agent 架构） | 训练与验证数据严格分离；模型开发团队与验证团队独立 |
驾驭逻辑：Anthropic 在长时运行应用的 Harness 设计中发现，让做事的 Agent 评价自己的输出会产生系统性乐观偏差。“调教一个独立的评估者保持怀疑态度，远比让生成者自我批评容易得多。“这和安全工程中"独立评估"的要求如出一辙。
阶段三：系统集成与测试
| 驾驭工程原则 | 智能驾驶映射 |
|---|---|
| 反馈循环：自动测试套件 + CI 验证 + 失败信号回传 | 仿真回归测试 + 封闭场地测试 + 开放道路测试的分层验证体系 |
| “测试通过但代码有 bug → 判定测试无效” | 仿真通过但实车表现差 → 仿真保真度/测试充分度需要重新审视 |
| 架构约束编码为自动化 Linter | 安全规则编码为自动化检查工具，集成到 CI/CD 管线 |
驾驭逻辑：OpenAI 发现 Agent 倾向于"写完代码跑个单元测试通过就标记完成”。在智能驾驶领域，这就是经典的"仿真测试通过率高但实车体验差"问题。解法同构：分层验证，每层有独立的通过判据，上层不因下层通过而跳过自己的验证。
阶段四：量产部署
| 驾驭工程原则 | 智能驾驶映射 |
|---|---|
| Harness = 模型之外的一切（CI 配置、格式化规则、项目指令、工作流控制） | 量产交付 = 模型 + 兜底措施 + 功能逻辑 + 交互逻辑 + 标定参数 |
| 约束悖论：“更严格的约束 → 更高的信任 → 更大的自主权” | 更完善的兜底 → 用户更信任 → 可以开放更多场景 / 更广 ODD |
驾驭逻辑：量产交付的不是一个模型，而是一个完整的驾驭系统。NVIDIA Halos 架构已经示范了这一原则的工程实现——端到端模型做主驾驶，独立模块化栈做并行护栏，二者同时运行、实时比对（来源）。
阶段五：现场运行与监控
| 驾驭工程原则 | 智能驾驶映射 |
|---|---|
| 运行时反馈：Agent 输出的实时监控与异常检测 | Runtime Monitor：端到端输出的置信度监控、ODD 边界检测、异常行为告警 |
| Doc-gardening Agent：后台扫描文档与代码的不一致 | 后台自动分析行驶数据，发现新的 edge case 和触发条件 |
| 检测到问题 → 自动提交修复 PR | 检测到新 bad case → 数据自动回传 → 触发模型/Harness 迭代 |
驾驭逻辑：系统上线不是终点，而是反馈循环的真正起点。这一认知在安全工程中已经制度化（ISO 21448 Clause 13 明确要求运营阶段的持续监控），在 AI 编码领域则是 2026 年才被系统性认识到。
阶段六：OTA 迭代与持续进化
| 驾驭工程原则 | 智能驾驶映射 |
|---|---|
| 熵管理：技术债务 = 高息贷款，持续小额偿还 | 随模型迭代，旧兜底逻辑可能与新模型冲突——必须同步更新 |
| 垃圾回收：定期清理过时规则和文档 | 清理过时标定、冗余的兜底逻辑、不再适用的功能约束 |
| “新旧规则打架"是首要风险 | 新模型 + 旧兜底逻辑 = 冲突和体验倒退 |
驾驭逻辑：这是最容易被忽视但最关键的阶段。模型在升级，兜底措施和功能逻辑也必须围绕每个模型大版本动态调整。不做"垃圾回收"的团队，会积累越来越多相互矛盾的规则，最终导致系统行为比没有规则时更加不可预测。
三、用户体验维度：驾驭工程如何抬高体验"地板”
3.1 天花板与地板模型
驾驭工程有一个清晰的价值定位：它无法突破模型的性能上限（天花板），但可以兜住用户体验的下限（地板）。
但可以让系统更频繁地接近这条线
LangChain 的实验是这个模型的最佳实证：模型不变，仅改 Harness，性能从 52.8% 提升到 66.5%。 提升的不是天花板（模型能力没变），而是地板（模型在各种场景下的稳定表现大幅改善）。
映射到智能驾驶：同一个端到端模型，配上不同水平的兜底措施、功能逻辑和交互逻辑，用户体验可以天差地别。模型能力决定了"最好的时候有多好”，而驾驭工程决定了"最差的时候有多差"——对于日常使用的产品，后者才是决定用户是否信任、是否持续使用的关键。
3.2 三层驾驭架构
从用户体验出发，智能驾驶系统的驾驭层可以结构化为三层：
▲ 上层兜住下层的体验下限 · ▼ 下层提供上层的能力上限
安全兜底层——“无论如何不能让用户害怕”。与模型解耦，独立运行，基于物理规则和地图先验。参考 NVIDIA Halos 的"端到端模型 + 独立模块化栈并行护栏"架构。
功能协调层——“模型能做好的让模型做，做不好的由协调层兜”。核心能力是持续追踪模型性能边界，按场景动态调度：模型置信度高则放手，置信度低或已知弱场景则提前切换到兜底逻辑。这一层需要随每个模型大版本重新标定。
用户感知层——“即使发生了降级，用户也不应觉得突兀”。包括状态透明化（让用户知道系统在做什么）、渐进式接管引导（而非突然甩方向盘）、以及长期的信任积累策略。
3.3 约束悖论：为什么更多限制带来更好体验
Martin Fowler 团队总结了一个看似反直觉的发现（来源）：
“为了获得更高的 AI 自主性，运行时必须受到更严格的约束。增加信任需要的不是更多自由，而是更多限制。”
这个"约束悖论"在智能驾驶用户体验中同样成立：
| 阶段 | 低约束策略 | 高约束策略 |
|---|---|---|
| 短期表现 | 体验忽好忽差，偶有惊艳 | 体验稳定，无明显惊喜 |
| 用户信任 | 信任难以建立，一次翻车需多次好表现弥补 | 信任持续积累 |
| 长期结果 | 用户不敢放手 → 频繁接管 → 使用率下降 | 用户越来越放心 → 更高使用率 → 可开放更多场景 |
约束 → 稳定 → 信任 → 更大的使用空间 → 更好的用户体验。 高速公路上的护栏不会让车变慢——正是因为有护栏，驾驶员才敢踩到 120 码。
四、安全维度：与 SOTIF 的深层结构性同构
4.1 SOTIF 四象限与 Harness 改进循环
SOTIF（ISO 21448）的核心框架是场景四象限分类（来源）：
驾驭工程的改进循环做的是完全相同的事情：
| SOTIF 象限转化 | 驾驭工程对应操作 | 智能驾驶 Harness 操作 |
|---|---|---|
| Area 4 → Area 2（发现未知危险） | Agent 犯了新错 → 记录失败模式 | 实车/仿真发现新 bad case → 记录到问题库 |
| Area 2 → Area 1（修复已知危险） | 工程化防止再犯的方案 → 更新 AGENTS.md / Linter 规则 | 设计兜底措施 / 修改功能逻辑 → 更新标定和规则 |
| Area 3 → Area 1（验证确认安全） | 运行测试套件验证修复有效 → CI 通过 | 回归测试验证修复有效 → 仿真 + 实车通过 |
| 残余风险评估 | 评估是否还有未覆盖的失败模式 | 评估残余 Area 4 是否足够小，残余风险是否可接受 |
这不是表面的类比。两者的改进引擎从结构上就是同一台机器：持续发现未知风险 → 工程化为已知防线 → 验证防线有效 → 评估残余。
Mitchell Hashimoto 的核心理念——“每次 Agent 犯错，就工程化一个解决方案”——与 ISO 21448 对持续现场监控和触发条件更新的要求（Clause 6 & Clause 13），使用了不同的术语，表达了完全相同的工程哲学。
4.2 “生成-评估分离"与"独立安全评估”
Anthropic 在Harness 设计实践中受 GAN（生成对抗网络）启发，提出了三 Agent 架构：Planner（规划者）、Generator（生成者）、Evaluator（评估者）。核心发现：
“将做事和评判分离，是解决自我评估偏差的关键杠杆。调教一个独立的评估者保持怀疑态度，远比让生成者自我批评容易得多。”
这一原则在安全工程中早已制度化：
| 原则 | 驾驭工程实践 | 安全工程实践 | 有效性原因 |
|---|---|---|---|
| 生成者不能评估自己 | Generator ≠ Evaluator | 开发团队 ≠ 独立安全评审团队 | 自我评估存在系统性乐观偏差 |
| 评估者需要独立标准 | Evaluator 有独立评分体系 | 安全评估有 ASIL 等级、安全目标、验收准则 | 没有标准的评估是伪评估 |
| 对抗式改进 | Generator 根据 Evaluator 批评迭代改进 | 开发团队根据安全评审意见修改设计 | 外部压力驱动真实改进 |
| 评估者应被训练为"怀疑论者" | Evaluator 被调教为持怀疑态度 | 安全审核员的职业要求就是质疑一切 | 必须主动对抗系统性乐观偏差 |
ISO 26262 Part 2 明确要求独立评估（Independent Assessment）；SOTIF 要求用独立于开发团队的方法验证残余风险。驾驭工程在 AI 编码领域重新发现了安全工程几十年前就已验证的铁律。
4.3 用户体验与安全：一枚硬币的两面
值得特别指出的是：优秀的用户体验驾驭和严格的安全保障之间不存在矛盾，它们是同一设计的两个投影面。
| 设计要素 | 体验视角的诠释 | 安全视角的诠释 | 实质是同一件事 |
|---|---|---|---|
| 兜底措施 | 模型表现异常时用户不受惊吓 | SOTIF 要求的最小风险状态和降级策略 | 优雅降级 |
| 功能逻辑 | 场景切换丝滑、不突兀 | ODD 边界管理和场景调度 | 场景边界处理 |
| 交互逻辑 | 用户随时知道系统状态 | 功能安全的可预测性和透明度要求 | 系统状态透明 |
| 持续迭代 | 版本越新体验越好 | SOTIF 的现场监控与持续验证 | 数据驱动的闭环改进 |
| 通勤实测 | 以真实用户视角发现体验问题 | 现场运行数据收集，发现新触发条件 | 真实场景验证 |
一套好的驾驭系统，天然同时满足用户体验和安全的要求。这意味着在驾驭工程框架下，体验投入和安全投入不是零和博弈，而是一次投入、两处收益。
4.4 与 ISO 26262 V-model 的对应
ISO 26262 的 V-model 开发流程（来源）从概念阶段到验收测试，左侧是自顶向下的设计分解，右侧是自底向上的验证集成。驾驭工程的四大护栏在 V-model 的不同阶段各有投射：
| V-model 阶段 | 对应的驾驭工程护栏 | 具体实践 |
|---|---|---|
| 概念阶段 / 系统需求 | 上下文工程 | 定义模型性能边界图谱、场景分类、ODD 规格 |
| 系统设计 / 架构设计 | 架构约束 | 分层架构（模型/兜底/功能/交互），模块间依赖规则 |
| 软件实现 / 集成 | 反馈循环 | 自动化测试套件、Agent-to-Agent 审查、CI/CD 集成 |
| 系统测试 / 验收 | 反馈循环 + 架构约束 | 端到端回归测试、分层验证、安全规则自动检查 |
| 生产 / 运营 | 熵管理 | 现场监控、文档清理、持续标定更新、OTA 迭代 |
五、行业共识及其在智能驾驶中的双重解读
综合 OpenAI、Anthropic、LangChain、Stripe、HashiCorp 等多个独立信息源，AI 工程社区在以下六个方面已形成明确共识。每一条共识在智能驾驶和安全工程中都有精确的对应物。
共识一：瓶颈在基础设施，不在模型智能
AI 编码领域：五个独立团队得出相同结论。LangChain 仅改变 Harness 工具格式，就让模型得分从基线大幅跃升。
智能驾驶解读：端到端模型的能力上限固然重要，但决定产品竞争力的往往不是模型本身，而是模型之外的兜底措施、功能逻辑和交互设计。在模型趋于同质化的趋势下，驾驭层的设计能力将成为关键差异化因素。
安全解读：SOTIF 的核心假设就是"系统即使按设计运行也可能不安全"——问题不在模型智能不够，而在运行环境的约束和防护不充分。
共识二：文档必须是活的反馈循环
AI 编码领域：静态文档是坟场。Mitchell Hashimoto 的 Ghostty 项目中，AGENTS.md 的每一行都对应一个历史 Agent 失败案例。后台 Doc-gardening Agent 定期清理过时文档并自动提交修复。
智能驾驶解读：模型性能边界文档、兜底策略库、交互逻辑规格不能是一次性交付物，必须随模型版本和现场反馈持续更新。文档一旦停止更新，就开始误导——比没有文档更危险。
安全解读：SOTIF 的安全论证文档（Safety Case）在传统实践中往往在项目交付时完成后就束之高阁。驾驭工程的"活文档"理念要求安全论证随运营数据持续刷新——这本身也是 ISO 21448 Clause 13 的原始意图。
共识三：思考与执行分离
AI 编码领域：复杂任务不可能在单个上下文窗口内完成。需要 Orchestrator（编排者）+ Worker（执行者）分层架构，状态持久化到外部存储。Anthropic 的三 Agent 架构（Planner / Generator / Evaluator）是这一原则的典型实践。
智能驾驶解读：策略决策层（判断采用什么方案、是否需要兜底）与执行层（模型输出轨迹、控制器跟踪）应当解耦，各自独立演进。这允许在不重训模型的前提下，通过调整策略层的逻辑实现体验优化。
安全解读：安全架构中"监控通道"和"执行通道"的分离是功能安全的基本范式。高 ASIL 等级的安全功能要求独立于被监控功能的硬件和软件通道。
共识四：上下文不是越多越好
AI 编码领域：巨大的指令文件会挤掉任务空间。LangChain 的 LocalContextMiddleware 根据当前任务按需注入环境信息，而非一次性灌入所有可能的上下文。
智能驾驶解读：不应给模型塞入全部场景的所有规则和约束。应按当前驾驶场景、ODD 状态、用户偏好动态加载相关的约束集。过多的规则不仅消耗计算资源，还会产生规则间冲突。
安全解读：ODD 的设计本质上就是"按需约束"——不是定义一个万能的系统能力边界，而是为每类场景精确定义适用条件和约束集。
共识五：约束必须自动化
AI 编码领域：人工 Review 是瓶颈。护栏要编码为 Linter、CI、类型系统，让机器执行而非依赖人。OpenAI 团队的所有架构规则都被编码为自定义 Linter 规则，违反即 CI 阻止合并。
智能驾驶解读：兜底措施和安全约束不能依赖人工调参和手动配置，而应编码为自动化的检查和触发机制，集成到开发管线和运行时系统中。自动化的约束执行是规模化部署的前提。
安全解读：安全分析和验证工具链的自动化（FMEA 工具、STPA 工具、形式化验证）是安全工程提效的关键方向。手动安全分析在端到端系统的复杂度面前已经力不从心。
共识六：工程师角色在转变
AI 编码领域：工程师从"代码的编写者"变成"环境的建筑师"。最大的工程挑战不再是写出好代码，而是设计让 Agent 可靠工作的控制系统。
智能驾驶解读：随着端到端模型承担越来越多的驾驶任务，工程师的核心价值从"调参"转向"设计模型可靠运行的环境"——定义边界、构建兜底、设计交互、建立反馈循环。这不是工作的减少，而是工作重心的根本转移。
安全解读：安全工程师的角色也在从"写安全文档的人"转向"设计可论证安全系统的架构师"。当系统的智能核心越来越黑箱化时，外部约束和监控的设计能力变得比内部算法的理解更加关键。
六、结论：不是类比，而是同一套操作系统
6.1 七条统一原则
综合全文分析，驾驭工程与智能驾驶安全工程共享以下七条深层原则：
| 统一原则 | 驾驭工程表述 | 安全工程表述 | 本质 |
|---|---|---|---|
| 不信任智能系统的完美性 | “Agent 的每次失败是环境设计不完善的信号” | “SOTIF 假设系统即使按设计运行也可能不安全” | 对不确定性的工程化管理 |
| 前馈 + 反馈双控制 | Guides + Sensors | 安全约束 + Runtime Monitoring | 控制论基本范式 |
| 生成与评估分离 | Generator ≠ Evaluator | 开发 ≠ 独立安全评估 | 消除自我评估偏差 |
| 约束产生信任 | 更严格的约束 → 更高的自主权 | 更完善的安全机制 → 更广的 ODD | 信任-自主权正循环 |
| 失败驱动改进 | 每次犯错 → 固化一条规则 | 每个触发条件 → 更新安全措施 | SOTIF Area 4→2→1 |
| 持续对抗熵增 | 垃圾回收 + Doc-gardening | 安全生命周期管理 + 变更影响分析 | 系统持续可信的长效机制 |
| 人类掌舵 | “Human Steer, Agent Execute” | “Human in/on the Loop” | 人类保持最终决策权 |
6.2 双向借鉴
两个领域不仅同构，而且可以互相借鉴对方的优势：
安全工程可以向驾驭工程借鉴的：
- 约束的自动化执行（Linter/CI 式安全检查，替代人工文档审查）
- Agent-to-Agent 审查（降低独立评估的人力成本）
- 活文档机制（消灭安全论证文档的腐烂问题）
- 持续小额偿还（替代审计周期前的集中式补救）
驾驭工程可以向安全工程借鉴的：
- 系统化的失败模式分析方法（FMEA / STPA / FTA）
- 分级体系（ASIL 等级的思路可用于 Agent 任务风险分级）
- 独立评估的制度化保障（不只是技术方案，而是组织流程）
- 残余风险的量化评估方法（而非"感觉差不多了"）
6.3 核心价值总结
对于智能驾驶行业，驾驭工程的跨界引入具有三重价值：
用户体验价值：在模型能力不变的前提下，通过系统化的兜底措施、功能逻辑和交互设计，显著提升产品体验的下限和一致性。LangChain 的实验证明，仅改善驾驭环境就能带来两位数百分比的性能提升。
安全工程价值：驾驭工程的四大护栏体系与 SOTIF/ISO 26262 的安全生命周期管理在结构上同构，可以为安全工程带来更敏捷、更自动化、更数据驱动的实施方式。安全合规不再是额外负担，而是驾驭工程的自然副产品。
方法论价值：驾驭工程提供了一个跨领域的统一框架，可以将用户体验优化和安全保障纳入同一套工程实践中，消除两者之间的传统对立，实现一次投入、两处收益。
两个行业在不同的山坡上攀登，最后发现山顶是同一个。AI 编码智能体的"驾驭工程"和智能驾驶的"安全工程"，解的是同一道题，用的是同一套原理——只是一个写代码，一个开车。谁先看清这座山的全貌，谁就拥有了两座山峰的视野。
参考资料
- Mitchell Hashimoto - My AI Adoption Journey, 2026.02
- OpenAI - Harness Engineering: Leveraging Codex in an Agent-First World, 2026.02
- Martin Fowler / Birgitta Böckeler - Harness Engineering for Coding Agent Users, 2026.03
- Martin Fowler / Birgitta Böckeler - Harness Engineering - First Thoughts, 2026.02
- Anthropic - Effective Harnesses for Long-Running Agents, 2026.03
- Anthropic - Harness Design for Long-Running Application Development, 2026.03
- LangChain - Improving Deep Agents with Harness Engineering, 2026.02
- LangChain - The Anatomy of an Agent Harness, 2026.04
- NVIDIA - Halos: A Solution for Autonomous Vehicle Safety, 2025
- Epsilla - The GAN-Style Agent Loop: Deconstructing Anthropic’s Harness Architecture, 2026.04
- UniSTPA - A Safety Analysis Framework for End-to-End Autonomous Driving, 2025
- ASAM - ISO 21448 SOTIF Overview
- ISO 26262:2018 - Road vehicles — Functional safety
- ISO 21448:2022 - Road vehicles — Safety of the intended functionality
- GitHub - Awesome Harness Engineering
2026-04-09 | 张玉新 吉林大学汽车工程学院 · 自动驾驶安全联合实验室
本文首发于 blog.autozyx.com，公众号版本略有删改。
Originally published at blog.autozyx.com.