Harness 的用户体验 vs 安全合规——12 Primitives × SOTIF 完整映射

摘要：2026 年 Q1，Harness Engineering 在 OpenAI、Anthropic、明日新程 Nextie 几乎同步出现，“12 Primitives"在社区收敛为新的隐性共识。本文论证：主流路线对 Harness 的投入几乎全部集中在"用户体验、性能、效率"维度；而 Safety-Critical 场景里决定能否上市的"安全合规"维度几乎没有被任何商业玩家系统性投入。本文用 12 Primitives × SOTIF / ISO 21448 的双向映射建立桥梁，并识别 12 条可深入研究的方向，作为标准组织、企业预研团队、第三方机构、研究机构共同补位"安全合规维度 Harness"的起点。本文约一万字，公众号上有约 3000 字的精简版。

一、引子：两条线索的同时浮现

最近两个月，“Harness Engineering"这个词在两个完全不同的圈子里被高频讨论。

1.1 AI 工程圈的密集信号

2026 年 2 月，OpenAI 官方博客《Harness Engineering: Leveraging Codex in an Agent-First World》第一次把这个概念从隐性共识变成正式术语。同年 3 月，Anthropic 推出 Managed Agents 架构，技术文档反复强调"Agent Harness"作为一等工程对象。4 月，明日新程 Nextie 在一个月内连融两轮，陆奇和李开复罕见同框入场，核心叙事是"群体智能 + Harness”。同月新智元一篇《最新风口 Harness，李开复、陆奇已重金入场》把 Harness 推成产业热词。

与此同时，GitHub 上的 awesome-harness-engineering 仓库把 12 个原语（Agent Loop、Planning、Context Delivery、Tool Design、Skills/MCP、Permissions、Memory、Task Runners、Verification、Observability、Debugging、HITL）从社区隐性共识收敛成了一份分类法。

1.2 汽车行业的低调但明确的同期信号

汽车行业的信号则相对低调但同样明确。头部智驾公司不约而同地在加码模型输出可解释性与透明度相关工作，把它定义为未来 5–10 年的核心战略。越来越多的车企技术团队开始在内部文件里讨论 Harness。

两条线索交织出现的时候，第一直觉是把它们对齐——汽车行业的 Sense-Plan-Act 不就是 Agent Loop 吗？车端的 ODD 检查不就是 Permission 吗？仿真平台不就是 Verification 吗？

但对齐之后反而看到了一件更有价值的事。

两件事都在谈 Harness Engineering，但谈的根本不是同一个 Harness。更关键的是，两条路线都和我这些年专注的自动驾驶安全（SOTIF / ISO 21448）几乎无关。

这不是巧合。这是结构。

二、用户体验 vs 安全合规：核心区分

2.1 三条主流路线的共同模式

把这一周收集的材料摊开看，三条路线浮现出一个被很少人指出的共同点。

三条路线面对的都是同一个底层问题：

如何让一个能力强大、但行为不可完全预测的智能系统，在开放环境中可靠运行？

而它们有一个共同的优化方向——都在 Harness 的"用户体验、性能、效率"维度发力。让模型更强、更快、更稳、更透明，是它们的主战场。

这是商业战争的必然——谁的用户体验好、谁的模型性能强，谁就赢。

2.2 安全合规：被集体跳过的另一侧

但 Harness 还有另外一个维度被主流路线集体跳过——安全合规。

当一个智能系统需要拿到量产准入、通过监管审批、在事故中被司法追溯的时候，它就不只需要"体验强”，还需要"合规稳"。

这个维度在消费 AI 场景不太重要（失败代价是聊天不够深度）；在企业 Agent 场景也不太重要（失败代价是代码有 bug）。

但在自动驾驶、医疗 AI、金融风控这些 Safety-Critical 场景里，它是决定能否上市的第二条底线：

• ISO 21448（SOTIF）要求"已识别的危害必须可复现"
• ISO 26262 要求"ASIL 等级对应的论证链条完整"
• 监管要求"每一个上路决策都有迹可循"

这些要求一旦落到 AI Agent 身上，12 个原语里的每一个都会出现新的安全合规工程问题。

2.3 为什么主流不会自发投入安全合规

安全合规这个公地，主流为什么不做？两个结构性原因：

第一，合规不是商业差异化抓手。如果"端到端决策的可追溯性"变成全行业最低标准，没有人会因此买你的车、用你的 Agent。它是一张门票，不是一个卖点。

第二，合规是行业公地。一家车企单独投入 5 个人去做"端到端决策可追溯的形式化方法"，成果是全行业共享的标准。这种活，纯商业公司没有动力干。

公地需要有人补位。标准化组织、企业内部的前瞻预研团队、第三方机构、以及研究机构、高校和实验室，是这类公地的天然承担者——做的是眼下还不太需要、但未来一定需要的工作。

一句话总结：Harness 不是单一维度的工程问题，它有用户体验面和安全合规面。前者已经被资本和大厂占满，后者在 Safety-Critical 场景里是决定性的，但几乎是空白。

Harness 双维度对照

三、12 Primitives × SOTIF 完整对照

3.1 主映射表（一眼概览）

12 Primitives 概览图

3.2 逐条详解

每一条都拆成"用户体验切面 + 安全合规切面 + 标准对应 + 现有实践 + 研究空白"五段结构。

Primitive 1 — Agent Loop（智能体循环）

用户体验切面：主流 Agent 框架（LangGraph 图状态、OpenAI Item/Turn/Thread 协议、Anthropic Managed Agents 的 loop runtime）都在卷"每一次循环跑得更快、更省 token、更不绕路"。Nextie 的群体智能也在这一层优化并发吞吐。

安全合规切面：循环迭代的安全分析方法——把循环当黑箱的 SOTIF 分析如何细化到"每一次迭代都是一次触发条件评估机会"，目前是空白，需要形式化定义。

Harness 视角：Thought-Action-Observation 循环是智能体的最小执行单元。LangGraph 的图状态/边模型、OpenAI 的 Item/Turn/Thread JSON-RPC 协议都是对这一循环的形式化。

SOTIF 对应：感知-决策-控制循环是自动驾驶系统的最小单元。ISO 21448 Clause 4 要求对功能行为进行规约，而每一次循环迭代都是 Clause 6 意义上的"触发条件评估机会"。

ISO 26262 相关：循环执行时间分析、最坏执行时间（WCET）计算、确定性调度。

现有汽车工业实践：经典的 Sense-Plan-Act 架构（Apollo、Autoware）都是对 Agent Loop 的实例化——只是没用这个名字。

关键研究空白：当前 SOTIF 分析倾向于把整个循环当作单一功能单元来评估。但 AI Agent 工程实践显示，循环模式（持久化 vs 一次性）的不匹配会显著放大错误率和 token 开销。这意味着每次迭代的边界处都隐藏着触发条件，需要迭代级而非系统级的安全分析方法。

Primitive 2 — Planning & Task Decomposition（规划与任务分解）

用户体验切面：行业主流在 LATS（MCTS 变体）、Plan-and-Execute、Microsoft TaskWeaver 几种分解范式里卷"分解准确率 + token 节省"。量产车端把这些能力下放到 Behavior Tree / FSM 里做"变道决策、汇入决策"的体验流畅度。

安全合规切面：多步规划中的"回滚语义"——当中间步骤发现不可行时，如何安全退回、回滚链条如何被安全论证覆盖，目前在 ISO 21448 和 26262 里都没有形式化定义，属于待研究空白。

Harness 视角：复杂任务必须分解。LATS、Plan-and-Execute、Microsoft TaskWeaver 是三种主流分解范式。

SOTIF 对应：自动驾驶的多步决策（变道、汇入、复杂路口通过）本质上就是规划任务分解。Clause 5 的危害事件识别要在每个分解层级独立进行。

ISO 26262 相关：分层有限状态机、决策级 FMEA、行为树的安全约束。

现有汽车工业实践：行为树（BT）和有限状态机（FSM）已经是量产代码的标配。

关键研究空白：计划级回滚语义。当一个多步计划在中途发现执行不可行时，如何安全地回退到上一步？目前的 BT/FSM 实现往往是"硬切换"，而 AI 编码 Agent 已经发展出更优雅的回退机制（checkpoint 模型）。

Primitive 3 — Context Delivery & Compaction（上下文交付与压缩）

用户体验切面：Anthropic Compaction API、LLMLingua-2、自主上下文压缩（Active Context Compression）研究都在卷"塞进去更多有用信息而不爆成本"。车端多源融合、Scene Graph、先验地图加载策略是体验层的同类工作。

安全合规切面：压缩动作如何不违反 SOTIF 的"感知完整性"和"安全余量"？哪些上下文片段属于"安全必需项"不可压缩？这是用户体验维度和 ASIL B+ 数据有效性约束的交叉地带，需要形式化的合规压缩规则。

SOTIF 对应：传感器融合 + 场景图 + 先验地图都是上下文交付。Clause 6 把感知失真列为主要触发条件来源；Clause 8 的功能修改本质上是"上下文过滤策略"。

ISO 26262 相关：ASIL B+ 对传感器数据有效性的要求、数据老化检测、超时处理。

现有汽车工业实践：多源融合、Scene Graph、SD/HD 地图加载策略。

关键研究空白：安全约束下的自适应上下文压缩。当感知数据过载时，如何在不违反 SOTIF 安全余量的前提下做语义压缩？这是 AI 编码社区已经走在前面的方向，值得汽车圈直接借鉴。

Primitive 4 — Tool Design（工具设计）

用户体验切面：AI 工具 UX 指南（清晰命名、Schema 严格、错误信息解释 why/how）、Outlines 和 instructor 把这些约束做成运行时强制。车端线控接口、CAN、AUTOSAR 端口定义是对应的工程实践。

安全合规切面：AI 工具设计三条铁律（清晰错误、幂等、可观察）进入汽车执行器 / 线控标准。“执行器返回的错误信息本身是否足够被 AI 调用方理解"尚未进入 ISO 26262 的规范视野，是明显的标准空白。

SOTIF 对应：车辆的执行器接口（转向、制动、油门）就是 Agent 的"工具”。Clause 8 的功能修改要通过执行器实现。

ISO 26262 相关：执行器 FMEA、fail-operational 设计、控制权限分配。

现有汽车工业实践：线控（drive-by-wire）接口、ISO 11898 CAN 协议、AUTOSAR 端口定义。

关键研究空白：AI 工具设计的智慧尚未进入汽车标准。AI 圈强调"错误信息本身也是上下文工程"——一个执行器返回错误时，应该告诉调用方"为什么失败、当前状态是什么、该怎么补救"。当前 ISO 26262 只关心"故障了没有"，不关心"故障信息够不够 AI 调用方理解"。

Primitive 5 — Skills & MCP（技能与模型上下文协议）

用户体验切面：MCP 协议、Microsoft Playwright MCP（用可访问性树替代截图，token 节省一个数量级）、Composio 250+ SaaS 集成、A2A Agent-to-Agent 协议都在卷"Agent 技能生态的统一接口与生态效率"。AUTOSAR Adaptive 在车端做"功能即服务"。

安全合规切面：跨厂商"汽车版 MCP"的互操作标准尚未定义。每个 OEM 的技能接口仍是孤岛，缺乏合规级的统一规范。这是一个有可能由中国标准化组织主导制定的国际标准机会。

SOTIF 对应：自动驾驶的模块化 ADAS 功能库（LKA、ACC、AEB）就是"技能"。Clause 4 的功能规约本质上就是 skill manifest。

ISO 26262 相关：软件单元和集成、AUTOSAR Adaptive Platform 的功能总线（Function Bus）。

现有汽车工业实践：AUTOSAR Adaptive 已经在做"功能即服务"的模块化，但跨厂商的 skill 互操作仍然是噩梦——每个 OEM 都有自己的接口规范。

关键研究空白：汽车版的 MCP。这是一个有可能由中国主导制定的国际标准——MCP 的成功证明了"统一接口"的价值，汽车行业有强烈的需求但还没有人系统化地做这件事。

Primitive 6 — Permissions & Authorization（权限与授权）

用户体验切面：Claude Agent SDK 五层评估（hooks → deny → mode → allow → canUseTool）、Microsoft Authorization Fabric 的 PEP/PDP、两阶段分类器（fast gate + CoT only on flags）替代"每次都问"的审批疲劳，核心目标是"少打断用户、少错放、少错拦"。

安全合规切面：两阶段授权机制在 ODD 边界检测中的形式化应用——如何把 fast gate + CoT 的两阶段结构写进 ISO 21448 的 ODD 合规要求，并证明它在 ASIL 解构下仍然可论证，是待研究空白。

SOTIF 对应：ODD 边界检查就是授权决策。Clause 4 定义功能激活条件，Clause 8 的功能修改包含"禁用功能"作为风险降低手段。

ISO 26262 相关：模式管理（mode management）、互不干扰（Freedom From Interference, FFI）、ASIL 解构（decomposition）。

现有汽车工业实践：ODD 检查、功能仲裁器（function arbiter）、ASIL 分解。

关键研究空白：两阶段授权机制在 ODD 边界检测中的应用。当前 ODD 检查是"逐帧粗暴判断"——每一帧都跑完整的判断逻辑。AI 社区的两阶段方法（fast gate + reasoning）可以显著降低 ODD 检查的计算成本，同时只在边界情况触发完整推理。本文第四章详述。

Primitive 7 — Memory & State（记忆与状态）

用户体验切面：Letta/MemGPT 三层模型、mem0 通用记忆层、Zep 自动摘要 + 实体提取 + 语义搜索，核心在"Agent 越用越懂你"的个性化体验。车端 World Model、EDR、OBD-II 是对应的持久化工程。

安全合规切面：跨行程长时记忆下的"行为一致性安全"——记忆带来的个性化如何不违反 SOTIF 对"安全行为可预测性"的要求？这是个性化 × 安全论证的交叉空白，需要新的合规模型。

SOTIF 对应：车辆状态估计、世界模型持久化、行程历史。Clause 12 的现场监控本身就要求状态日志的完整性。

ISO 26262 相关：持久化故障内存（P-codes）、状态机完整性、断电后状态恢复。

现有汽车工业实践：World Model、Event Data Recorder（EDR）、车辆诊断接口（OBD-II）。

关键研究空白：跨行程长时记忆下的行为一致性安全。当系统记住"上次这位驾驶员在这个路口选择了变道"时，下次要不要复用这个偏好？记忆的持久化如何不破坏 SOTIF 的"安全行为可预测性"原则？这是个性化驾驶 + 安全工程的交叉空白。

Primitive 8 — Task Runners & Orchestration（任务运行器与编排）

用户体验切面：Meta REA 的 6 小时休眠检查点、跨多工作日继续执行的编排能力是 B 端 Agent 赛道的体验制高点——核心指标是"长任务完成率 + 不迷路"。车端 Mission Planner、Route Manager、AUTOSAR OS Task 对应这层调度。

安全合规切面：长任务跨 OTA 重启、跨故障恢复的状态保留——如何让"多小时行程中途被系统重启不破坏安全论证链"有形式化方案，属于需要形式化定义的合规空白。

SOTIF 对应：任务管理器、路径规划器、调度器。Clause 4 的功能规约要明确"任务"的边界。

ISO 26262 相关：实时调度器、截止期分析、任务优先级。

现有汽车工业实践：Mission Planner、Route Manager、AUTOSAR OS Task。

关键研究空白：长任务下的状态保留——多小时行程如果遇到系统重启（OTA、故障恢复），如何无缝继续？Meta REA 的检查点机制是一个直接可借鉴的范式。

Primitive 9 — Verification & CI Integration（验证与持续集成）

用户体验切面：AI 编码社区形成了一条实践共识——“如果 AI 写的测试通过了带 Bug 的代码，这个测试本身应被判定无效，强制重新设计”，这套机制已经在 AI 编码领域形成工具链闭环。车端仿真平台 + 场景库 + CI 的回归测试链是对应的工业实践。

安全合规切面：把"测试无效性检测"迁移到 SOTIF 仿真验证——当 bad case 在仿真中没复现时如何自动判定"是保真度问题还是场景覆盖问题"并强制改进，尚无标准化方法。

SOTIF 对应：Clause 9（验证）和 Clause 10（确认）的核心要求。

ISO 26262 相关：MIL/SIL/PIL/HIL 多层验证、仿真覆盖率、错误注入测试。

现有汽车工业实践：仿真平台 + 场景库 + CI 触发的回归测试链。

关键研究空白：“测试无效性检测"在自动驾驶仿真中的对应物。当仿真测试通过率高但实车体验差时，当前没有自动化的方法判定"是仿真保真度不够"还是"测试场景覆盖不足”。把 AI 编码的"测试无效"判定原则迁移到 SOTIF 仿真：如果一个 bad case 在仿真中没复现，应当自动判定该 bad case 对应的仿真场景"测试无效"，强制改进保真度。本文第四章详述。

Primitive 10 — Observability & Tracing（可观察性与追踪）

用户体验切面：LangSmith、OpenTelemetry for LLMs、Agent 决策全链路追踪是 AI 工程的标准配置，目的是调试效率和迭代速度。车端数据回传、EDR、V2X 日志、UDS 诊断是对应的工业基础设施。

安全合规切面：端到端模型的决策可追溯性——attention map、saliency map 只是局部解释，无法满足司法 / 监管对"决策原因"的追溯要求。这是端到端时代最关键的安全合规工程空白之一，需要跨学科（法律 + 工程）的研究。

SOTIF 对应：Clause 12 的现场监控强依赖可观察性。

ISO 26262 相关：诊断事件管理器、DTC（Diagnostic Trouble Code）框架、UDS 协议。

现有汽车工业实践：数据回传系统、EDR、V2X 日志、故障诊断接口。

关键研究空白：端到端模型的决策可追溯性。当前的 EDR 记录"发生了什么"，但端到端模型的"为什么这么做"是黑箱。Attention map、saliency map 是局部解释，无法满足司法和监管对"决策原因"的追溯需求。这是端到端时代最关键的安全工程空白之一。

Primitive 11 — Debugging & DX（调试与开发体验）

用户体验切面：交互式调试工具、错误信息可读性、开发流程的反馈回路——AI 工具链里的 DX 卷得非常激烈（Cursor、Windsurf、Replit Agent）。车端仿真重放、场景重构工具属于对应的工业实践。

安全合规切面：端到端模型的"可复现性边界"——同一输入在不同时刻产生不同输出时，如何重现"问题现场"以满足 SOTIF Safety Case 的"已识别危害必须可复现"要求？这是端到端模型在合规要求面前的根本性空白。

SOTIF 对应：可复现性、场景重放、what-if 分析。Clause 6 的触发条件发现强依赖调试工具。

ISO 26262 相关：诊断工具、FuSa Toolchain、覆盖率工具。

现有汽车工业实践：仿真重放、场景重构工具、回放器。

关键研究空白：端到端模型的可复现性边界。当同一个输入在不同时刻产生不同输出时，如何重现"问题现场"？这不仅是调试体验问题，更是安全论证的可信度问题——SOTIF Safety Case 要求"已识别的危害必须可复现"，但端到端模型在这个要求面前是不合规的。

Primitive 12 — Human-in-the-Loop（人在环上）

用户体验切面：Agent 审批流程、中断机制、人类监督模式——AI 圈卷的是"怎么在保证用户控制感的同时最少打扰用户"。车端 TOR（Take-Over Request）、远程接管员、安全员制度是对应的工业实践。

安全合规切面：监督者能力的合规模型——当前 ISO 26262 的可控性分级（C0-C3）只回答"驾驶员能不能控制住车"，不回答"这个驾驶员有没有能力监督这个 AI"。监督者能力评估的合规框架完全空白。

SOTIF 对应：Clause 5 的危害事件评估包含可控性维度；Clause 8 的功能修改可以把驾驶员作为风险降低因素。

ISO 26262 相关：可控性分级 C0-C3、驾驶员警示策略。

现有汽车工业实践：接管请求（Take-Over Request, TOR）、远程接管员（Remote Operator）、安全员制度。

关键研究空白：监督者能力的合规模型。AI 越强大，对监督者的要求反而越高——L3 驾驶员的监督义务比 L2 更难，不是更容易；L4 远程监督员必须懂系统边界、懂 ODD 何时失效、懂接管时机。本文第四章杠杆三详述。

四、三个最有杠杆的杠杆

12 条研究空白里，有三条同时满足"工程收益巨大、学术路径清晰、与现有标准锚定明确"——值得作为优先突破点。

4.1 测试无效性 ↔ SOTIF Clause 6

AI 编码社区最近一年形成了一条实践共识：

如果 AI 写的测试用例"通过"了带有 Bug 的代码，这个测试本身应被判定无效，强制重新设计。

这条共识的本质，就是 ISO 21448 Clause 6 关于"触发条件持续识别"的工程化执行。

Clause 6 的核心逻辑是：每一次系统在现场遇到未预期的失败，都应被视为一个新的触发条件，反向驱动验证策略和测试覆盖的更新。

这条原则早就写进了 SOTIF 标准。但在工程层面，我们一直停留在"人工 review 失败案例"的阶段——没有自动化机制判定"已有测试是否覆盖了这个失败"。

AI 编码社区只用了一年左右，就把这条原则做成了自动化工具链。汽车圈完全可以直接借鉴。

可成果形式：顶会论文（ICSE、ASE、ICRA）+ 工具发布 + GB/CSAE 团标提案。

4.2 两阶段授权 ↔ ODD 检查

AI Agent 领域近一年讨论最多的设计问题是"审批疲劳"。社区的解法是两阶段分类器：

• 第一阶段（fast gate）：用轻量分类器秒杀绝大多数情况
• 第二阶段（CoT reasoning）：仅当第一阶段标记可疑时才触发完整推理

这让授权系统的计算成本下降了一个数量级。

现在看智驾的 ODD 检查：当前所有量产系统的 ODD 检查都是逐帧粗暴判断——不管你是在阳光明媚的高速直道，还是在隧道入口的逆光弯道，计算成本完全一样。

直接搬 AI 社区的两阶段方案：

• 第一阶段：用轻量模型粗判断（“在 ODD 内” / “接近边界” / “已出界”）
• 第二阶段：仅当"接近边界"时才触发完整 ODD 检测逻辑

预期收益是 ODD 检查的总计算成本大幅下降（工程上可以做到一个数量级级别的降低），不损失任何安全性。

可成果形式：工程论文 + 量产方案 + 跨企业互验。

4.3 约束即引导 ↔ SOTIF Clause 8 的功能修改

2026 年初，腾讯汤道生在《人工智能正式进入 Harness 时代》一文里给 Harness 一个很精准的三元隐喻：

大模型是"发动机"，Harness 是"线束"，使用者是"驾驶员"。

这个隐喻本身并不新——福特时代的汽车工业就是"先有发动机、再有线束、最后有驾驶员"。但汤道生在文章里补了一句更深的定义：

约束不是对智能的压制，而是对智能的引导。

这一句话在汽车安全工程里有一个严格的对应物——ISO 21448 SOTIF Clause 8 对"功能修改"的定义。

Clause 8 所说的"功能修改"包括：

• 禁用某些功能（比如高风险 ODD 出现时禁用 ACC）
• 限制激活条件（比如仅在特定天气、特定道路类型激活）
• 降低性能（比如降低最大车速、提高跟车距离）
• 把驾驶员作为风险降低因素（比如在边界处给出 TOR）

这些动作从 AI 工程的视角看像是对模型的"削弱"。但在 SOTIF 的原意里，它们从来不是削弱——它们是把模型的行为导向安全空间的引导机制。

换句话说，Clause 8 的所有手段本质上都是 Harness 机制：

• ODD 边界检查 → Primitive 6 Permissions
• 功能仲裁器 → Primitive 2 Planning + Primitive 6
• 降级策略 → Primitive 12 HITL
• TOR 和远程接管员 → Primitive 12 HITL

把 Clause 8 的功能修改语义用 12 Primitives 重新表达，有两个非常具体的研究产出。

第一，“Clause 8 修改类型 × Harness 原语"的映射表。一旦画出来，会发现 Clause 8 还有几块空白：

• “模型置信度作为功能修改触发条件”——AI 圈早有实践，Clause 8 没写
• “长任务中途的功能降级”——Meta REA 的检查点范式在 Clause 8 没有对应物
• “多 Agent 协作失败时的降级语义”——未来 V2X + 多车协作会用到

第二，监督者的能力模型。汤道生在同一篇文章里指出：

AI 越强大，对人的要求不是降低了，而是提高了。一个能够安全监督自动驾驶系统的人，需要比普通驾驶员更深刻地理解驾驶本身。

这个观察翻译到智驾合规语言是：

• L3 驾驶员的监督义务比 L2 更难，不是更容易
• L4 远程监督员必须懂系统边界、懂 ODD 何时失效、懂接管时机
• 可控性分级 C0-C3 本质上是在回答"人作为系统安全的一部分，能承担多少责任”

而当前 ISO 26262 的可控性分级只关心"驾驶员能不能控制住车"，不关心"这个驾驶员有没有能力监督这个 AI"。监督者能力模型是一个完全空白的方向。

可成果形式：Clause 8 修改语义的学术论文 + 监督者能力评估的量产方案 + 面向 L3+ 监督义务的可控性分级扩展（比如 C4）标准提案。

五、两个需要有人补位的方向

把 12 Primitives 地图画出来之后，浮现两个"商业主战场不会触及，但必须有人做"的方向。它们天然属于标准化组织、企业内部的前瞻预研团队、第三方机构、以及研究机构、高校和实验室。

5.1 汽车版 MCP（Primitive 5）

MCP 是 Anthropic 在 2024 年底提出的开放协议，目标是让 AI Agent 用统一方式调用工具和数据源。一年多时间已经成为 AI 工具生态的事实标准。

汽车行业有完全相同的需求，但没有一家车企会主动推进——因为"把自家接口做深"符合商业逻辑，“开放跨厂商互操作"不符合商业逻辑。

这就是非商业纯工程化承担者的天然位置。MCP 之所以能起来，靠的是 Anthropic 把协议开源 + Google 的 A2A 跟进——开放性和标准化机构推动，而不是某家公司的市场策略。汽车版 MCP 需要同样的动力源。

中国的窗口期很明确：

• AUTOSAR Adaptive 的中国化扩展接口
• C-V2X 已有中国主导基础
• GB / CSAE 标准化体系有动力推动跨厂商规范

如果在 2026–2027 出第一份草案，2028 推到 ISO 层级是有路径的。

5.2 安全合规维度 Harness 的系统化方法论

更大的一个方向：把 12 Primitives × SOTIF 的安全合规映射做成一门独立的方法论。

它不与任何车企的商业战略竞争——因为体验是车企主战场，合规是行业公地。它的受众是：

• 重大专项、前瞻课题的顶层选题
• GB / ISO 标准新章节的起草
• 高校课程体系里的新方向
• 青年研究者的博士论文选题池
• 企业内部前瞻团队的孵化方向
• 第三方认证机构的评估框架

这不是一个谁先做谁独占的事。只要进来一起做，都是在给这块公地添砖加瓦。后面的人可以拓展，也可以推翻；只要方向是对的，参与本身就有价值。

12–18 个月之内，海外也一定会有类似的工作出来，比如 CMU CyLab、MIT CSAIL、TU Munich 这些传统的 Safety-Critical 研究机构。这件事不是"中国先做就排他”——它本身就应该是一个多主体共同参与的公开过程。

六、12 条研究空白汇总

标记"高"的 6 条，与本文 4.x、5.x 章节的杠杆点和方向直接对应。它们都可以单独深入研究、探究背后的机理与工程落地路径。

七、几个相关的公开探索

把"安全合规维度 Harness"挂在嘴上一年也没有人会理你。过去这一段时间，我在业余时间借助 AI 的大力辅助，做了几件与这个方向紧密相关的开放小项目。这些项目最初启动时并没有"Harness"这个坐标系——但回头看，它们确实都落在 12 Primitives 的合规侧。

必须先说明几件事：

• 这几个项目都是业余时间完成的
• 过程中得到了 AI 工具（主要是 Claude 生态）的大力辅助
• 它们都不完美，目前只是我个人的探索小样本
• 但它们都和标准法规紧密相关，希望未来这些尝试能以某种形式被标准组织、预研团队、或第三方机构看到，甚至推进到标准法规层面

7.1 ROAM：L4 Robotaxi 远程运营事故公开数据库

ROAM（RoboTaxi Operations Anomaly Management）是一个 L4 Robotaxi 远程运营事故公开数据库 + 场景分类法 + 参考架构，2026 年 4 月初发布。网站：https://roam.autozyx.com 。

当前覆盖：

• 16 起公开事故（Waymo / Cruise / 百度 Apollo / Pony.ai，2023–2026）
• 场景分类体系 v1.0（6 大类 A–F，27 子场景）+ 严重度 S0–S4 + 紧急度 U0–U3
• 三层参考架构（AI 自主 70% → AI+人工确认 25% → 远程遥控 5%）
• 8 个 KPI 定义
• 中英文双语文献综述（各 4000+ 词，42 篇参考文献，全部带可点击 URL）
• 13 项国际标准映射 + 中文标准对齐分析

ROAM 在 12 Primitives 框架里对应的是：

• Primitive 10（可观察性 / 决策可追溯）：在远程运营层面把事故现场记录公开化、结构化。把各家 Robotaxi 的事故数据放在同一个场景分类坐标里，本身就是可追溯性的行业级工程尝试。
• Primitive 12（HITL）：远程接管员在什么条件下介入、介入后的接管时长 / 动作类型，是 HITL 合规化的基础数据。

7.2 OpenODC：自动驾驶系统运行设计条件开源平台

OpenODC（Open Platform for Automated Driving Operational Design Conditions）基于我参与制定的 GB/T 45312-2025《智能网联汽车 自动驾驶系统设计运行条件》标准。

核心产出：

• 完整 GB/T 45312-2025 元素层级 JSON Schema（144 个元素 / 7 类）
• 量化分级表机器可读化（风力 12 级、雨量 4 级、4 类能见度、积雪、光照）
• /gallery 样例库 + /view 单文档详情（4 种视图：开发者 / 测试 / 监管 / 消费者）
• /editor 浏览器内 ODC 编辑器
• /compare 多文档 diff（2–4 个并排，一致性标注）
• GitHub PR 模板 + CI 自动校验

OpenODC 在 12 Primitives 框架里对应的是：

• Primitive 6（Permissions / ODD）：把 ODD 维度从隐性约定变成显式 schema，让行业的 ODD 声明可以对比、可以追溯。这是"权限"原语在合规侧的工程表达——权限要成立，首先得把权限边界写清楚。
• Primitive 11（Debugging / DX）：让不同 OEM 的 ODC 声明可对比，本身就是"可复现性"的前提——ODD 边界如果各家说法不一，谈不上任何跨厂商的危害复现。

7.3 AD Standards Tracker：自动驾驶标准追踪站

AD Standards Tracker 是一个自动驾驶标准追踪站，2026 年 4 月中旬上线 MVP。

当前覆盖：

• 7 个辖区（国际 / 中国 / 美国 / 欧盟 / 英国 / 日本 / 韩国）
• 79 条结构化标准记录
• YAML 数据层 + Next.js 前端 + Vercel 部署
• GitHub Actions 自动化爬虫框架（尚未接入生产数据源）

AD Standards Tracker 在 12 Primitives 框架里对应的是：

• Primitive 4（Tool Design）：把"全球 AD 标准"这个"工具生态"做成结构化、可调用、可对比的资源，本质是一个 meta-tool 的工具设计。
• Primitive 10（Observability）：合规本身也需要可观察性——一个 OEM 在某个辖区合规与否，需要有人把全球标准的演进变成可追踪、可订阅、可引用的数据。

7.4 国际可见性的另外两件事

awesome-harness-engineering PR #1——把 12 Primitives × ISO 21448 的英文 cross-reference 表作为补丁提交回上游仓库。这是合规维度 Harness 第一次在国际开源社区可见的信号。

后续还有一份英文 ArXiv Position Paper 在起草中，预定标题：

Compliance-Oriented Harness Engineering: A Framework for AI-First Safety-Critical Systems

预计 2026 Q2 投稿。

7.5 一点诚恳的说明

必须重复一遍前面的话——上面四件事都是业余时间完成的探索小样本，远远谈不上"工程验证"这么重的词。它们更像是在这套方法论地图上点了几盏小灯，让人隐约看到"安全合规维度 Harness"在具体工程里长什么样。

真正把这条路铺好，需要更多人参与。如果这些小项目能启发更多朋友在开源、开放、透明的前提下，把自己的工作往这个方向靠近一点，就已经超额完成了它们的使命。

八、English Cross-Reference

The following is a compact English version designed to be inserted into awesome-harness-engineering README under a new section “Cross-Reference: Automotive Safety Engineering (ISO 21448 / 26262)”.

Two Dimensions of Harness

Every primitive has two dimensions:

• User Experience dimension — what industry is actively optimizing (throughput, latency, token efficiency, task completion rate). This is where capital and major players compete.
• Safety Compliance dimension — what Safety-Critical deployment demands but no single company is incentivized to build (independent assessability, ODD formalization, traceability, reproducibility). This is a commons that requires standardization bodies, corporate R&D, third-party institutions, and academic labs to step in.

Mapping Table

Why This Matters

Two communities are independently solving the same root problem — how to make a powerful but not fully predictable intelligent system operate reliably in open environments — without learning from each other:

• AI Engineers are reinventing solutions that automotive safety engineering already validated in ISO 21448 / 26262: independent assessment, ODD-style activation conditions, graceful degradation, controllability gradation.
• Automotive Safety Engineers are missing the more agile tooling that the AI community has developed: Linter-style automated safety checks, living documentation, Agent-to-Agent review.

The safety-compliance dimension is a commons that needs multi-stakeholder collaboration: standardization bodies, corporate R&D, third-party institutions, and academic labs. The research gaps in the Chinese table above are concrete starting points for any of them.

九、对三类读者的邀请

如果你是车企算法或工程负责人——12 Primitives 可以作为自查 checklist。商业战略的用户体验侧你们已经在做；安全合规侧的缺口，我们可以聊。

如果你是标准制定参与者——汽车版 MCP 和安全合规维度的 Harness 规范都是开放的窗口。不论是在 GB、CSAE 还是 ISO 层级，都欢迎把这套框架作为起草素材。

如果你是研究生、博士生、青年教师，或企业前瞻团队的一员——12 条研究空白里的任一条都可以单独深入研究、探究其背后的机理与工程落地路径。不论先做后做，只要进来一起做，都是推进这块公地的一部分。

参考资料与关联工作

关联文档与项目

• 公众号精简版：《Harness 的用户体验 vs 安全合规》（约 3000 字，2026-04-19 发布）
• 同作者相关文章：驾驭工程在智能驾驶领域的跨界应用
• ROAM 项目：https://roam.autozyx.com ｜ GitHub 源码：https://github.com/AutoZYX/ROAM
• OpenODC 平台：https://openodc.autozyx.com ｜ GitHub 源码：https://github.com/AutoZYX/OpenODC
• AD Standards Tracker：https://standards.autozyx.com
• 作者其他开源项目：Co4Pilot · ADSafetyPilot · Good Ideas 2.0
• awesome-harness-engineering PR #1：ai-boost/awesome-harness-engineering#1

主要引用的产业事件

• 2026-02：OpenAI《Harness Engineering: Leveraging Codex in an Agent-First World》
• 2026-03：Anthropic Managed Agents 架构发布
• 2026-04：明日新程 Nextie 连融两轮，陆奇、李开复入场
• 2026-04：新智元《最新风口 Harness，李开复、陆奇已重金入场》
• 2026-04：汤道生《人工智能正式进入 Harness 时代》

主要引用的标准

• ISO 21448:2022 Road vehicles — Safety of the intended functionality
• ISO 26262:2018 Road vehicles — Functional safety
• ISO 11898 Road vehicles — Controller area network (CAN)
• GB/T 45312-2025 智能网联汽车 自动驾驶系统设计运行条件
• AUTOSAR Adaptive Platform Specification

作者简介：张玉新，吉林大学汽车工程学院副教授，自动驾驶安全联合实验室主任，卓驭科技功能安全负责人，驭研科技（DRIVEResearch）创始人，英国杜伦大学访问学者（2025–2026）。研究方向 SOTIF（ISO 21448）、功能安全（ISO 26262）、场景驱动测试评价。

联系方式：yuxinzhang@jlu.edu.cn

引用本文：张玉新. Harness 的用户体验 vs 安全合规——12 Primitives × SOTIF 完整映射[EB/OL]. 2026-04-19. https://blog.autozyx.com/posts/harness-compliance-dimension/

版权：CC BY 4.0