ISO 21448

摘要：Yoav Hollander 是芯片验证领域的世界级专家，他创立的 Foretellix 把覆盖驱动验证（Coverage-Driven Verification, CDV）带进了自动驾驶。最近，他写了一篇文章，把这套方法论推到了更大的范围：AI 对齐。本文从我的研究领域出发，结合 SOTIF 四象限、Robot SOTIF 的树状结构和中国的标准语境，解读 CDV 的跨领域迁移。核心问题只有一个：你怎么知道你不知道什么？ 几个月前，Yoav Hollander（Foretellix 联合创始人/CTO）给我发了一封邮件。 他是芯片验证领域世界级专家，发明了通用验证方法论（Universal Verification Methodology，UVM）的前身“e”语言，创办的 Verisity 被 Cadence 收购后，又创立了 Foretellix——做自动驾驶覆盖驱动验证（Coverage-Driven Verification, CDV），拿了 NVIDIA、沃尔沃和淡马锡的 C+ 轮融资。 Yoav 读了我几篇关于端到端安全、基于场景测评、SOTIF 的文章后，我们通过邮件和线上会议聊了几轮。最近，他写了一篇文章，把问题推到了更大的范围：AI 对齐。 经过 Yoav 本人许可，我把那篇文章翻译成了中文：[译] 覆盖驱动对齐：Teaching Claude Why 能从自动驾驶验证中借鉴什么。英文原文在这里：Coverage-driven alignment – What ‘Teaching Claude Why’ can borrow from AV verification。 下面从我的研究领域出发，对 CDV 跨领域迁移进行一些解读和延伸——结合 SOTIF 的实际情况，看看 CDV 在中国语境下意味着什么。 两条线的交汇 Yoav 在邮件里说过一句： “I am at heart a V&V guy, thinking about ‘how to achieve best risk reduction per week for the SUT, given fixed resources’. I feel much less confident regarding safety standards and ‘how to build a safety case’.” ...

摘要：ASIL E 目前不是正式标准。它真正有价值的地方，不是提出了一个更高等级名称，而是把 L4/L5 自动驾驶安全论证里一个长期存在的问题说清楚了：当车里没有人时，安全案例不能继续 credit 一个不存在的人类控制者。对我来说，这份 proposal 更适合被翻译成三类工程资产：一页 L4 无人兜底审查清单、ADSafetyPilot 里的四个证据字段，以及 ROAM / DRIVEResearch / ADSafetyPilot 之间的一条运行阶段证据闭环。 前段时间，我在 LinkedIn 上看到一位功能安全同行发了一个 proposal，题目很直接： The Case for ASIL E. 本地 PDF 是 79 页，副标题是 A Sixth Integrity Level for L4/L5 Autonomous Systems。它的核心观点是：ISO 26262 的 ASIL D 是当前最高等级，但它背后的 controllability 逻辑，来自一个仍然有驾驶员作为残余控制者的世界。到了 SAE L4/L5，系统设计目标就是不依赖驾驶员接管，这个假设会断掉。 我读完之后，第一反应不是“ASIL E 要来了”。 恰恰相反，我的第一反应是： 这不是一个新等级问题，而是一个老问题终于被说清楚了。 先把边界说清楚 截至 2026 年 6 月 3 日，ASIL E 不在已发布的 ISO 26262、ISO 21448 或 UL 4600 中。 ...

摘要：2026年6月2日，《机器人预期功能安全实施指南》国家标准项目进入公示，公示截止日期为2026年7月2日。我把这个方向放进 OpenTopic，作为第二个开放研究专题：Robot SOTIF。它不是把自动驾驶 SOTIF 简单搬到机器人上，而是尝试建立一条从标准、ODD、场景、触发条件、物理交互、LLM/VLA 决策安全到 safety case 的证据链。 我最近看到一个标准项目公示，觉得必须认真记一笔。 2026年6月2日，国家标准项目《机器人预期功能安全实施指南》进入公示。项目周期18个月，归口全国机器人标准化技术委员会，公示截止日期是2026年7月2日。 这个标题里最值得关注的词，不是“机器人”。 而是“预期功能安全”。 英文不要逐词硬译。这个领域对应的是 SOTIF，也就是 Safety of the Intended Functionality。 它问的不是“零部件坏了怎么办”。 它问的是： 如果系统没有发生故障，功能也在按设计运行，但在某个复杂开放场景中仍然做出了不安全行为，我们该如何识别、量化、验证和缓解？ 这个问题，自动驾驶行业已经痛苦地讨论了很多年。现在，它开始正式进入机器人标准化语境。 一、为什么这是一个重要信号 传统机器人安全，很多时候围绕隔离、防护、急停、限力、限速和协作应用展开。 这些当然重要。ISO 10218、ISO/TS 15066、ISO 13482 这些标准，给工业机器人、协作机器人和个人护理机器人提供了很重要的安全基础。 但机器人正在变。 它不再只在围栏里面工作，也不再只在结构化产线里重复动作。移动服务机器人、清洁消杀机器人、安防巡检机器人、物流配送机器人、养老医疗机器人，都会进入开放环境，面对普通用户、复杂任务和不稳定场景。 更关键的是，大模型和 VLA 让机器人决策系统从规则逻辑，走向语义理解、任务分解和端到端动作生成。 这时，安全问题就不再只是“有没有撞上人”。 还包括： 机器人是否理解错了用户意图？ 是否在 ODD 边界外仍然继续执行？ 是否为了完成任务而靠得太近、走得太急、停得太突然？ 是否在长时序任务里一步步积累风险？ 是否能把拒绝执行、回退、人工介入和运行日志变成可审查证据？ 这就是机器人 SOTIF 的价值。 二、为什么我把它放进 OpenTopic OpenTopic 的初衷，是把研究思路也像数据集一样开源。 说来惭愧，我手里其实一直有一些可以继续做深的材料。之前已经整理过三份关于具身智能安全、物理交互安全、LLM/VLA 决策安全的报告。但这些报告如果只是留在文件夹里，价值很有限。 这次标准项目公示出来以后，我重新看了一遍，觉得最合适的处理方式不是再写一篇普通评论，而是把它开放成一个可持续维护的问题入口。 所以我在 OpenTopic 里新增了第二个话题： Robot SOTIF：机器人预期功能安全开放研究专题 专题下面先放了三条线索： 机器人 SOTIF 的标准地图与证据链 通用移动物理 AI 的物理交互安全 LLM/VLA 机器人决策安全 我的处理原则很保守：标准只引用官方来源；没有逐条核验的 SOTA 论文和实验数字，先作为研究线索，不写成事实结论。 ...

摘要：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。 ...

摘要：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.” ...