三安一体化下的Agent初稿引擎：REANA如何重构汽车安全分析

1. 为什么是REANA：三安一体化，从“文档的事”变成“流程的事”

在汽车安全领域做了七八年功能安全，这两年又开始接触SOTIF和信息安全，我自己最大的体感是：这三个领域正在从“三个部门各写各的文档”变成“一套流程必须同时满足三套逻辑”。以前做功能安全，核心是ISO 26262，对照着ASIL等级把HARA（危害分析与风险评估）做完，安全目标和安全需求理清楚，整条V模型走下来就算完事。后来SOTIF（ISO 21448）加进来，大家都觉得是“又一个文档”，直到真实路测出了预期功能之外的场景，才发现它跟功能安全在系统层面彼此咬合。再往后，网络安全法规和ISO 21434落地，信息安全又成了一个必须全程介入的维度。

三套体系同时在同一个项目上生效，最直接的后果就是文档量爆炸、评审链路变长、责任人变多。原来一个安全经理能拍板的事，现在要三个方向的专家坐在一起，反复对齐同一个功能的危险描述、风险等级和安全策略。这种情况下再靠“人肉”去建模型、拉追溯、对一致性，团队会非常痛苦。

REANA这个名字，我最早是在一个项目预研讨论里听到的。它做的事情概括起来就是标题里那句——从“人建模型”到“Agent建初稿”。它用Agent先把功能安全、SOTIF、信息安全三个领域的安全分析初稿自动拉出来，再由人到评审会上去校验、补充、拍板。这一套下来，真正改变的不是“写文档快了一点”，而是整个安全活动的启动方式变了：过去是从空白模板开始，现在是从一个Agent已经帮你推理过的草案开始。

我写这篇文章，就是想把REANA的三安一体思路拆开讲清楚：它解决什么问题、内部怎么组织、Agent在中间到底承担什么角色、实际落地会踩哪些坑。不管你是功能安全工程师、SOTIF的测试负责人，还是信息安全审计角色，这篇文章都值得读完，因为它讲的是“以后安全交付物怎么产生”这件事。

2. REANA的总体架构：三个安全域，一个初稿引擎

2.1 输入层：标准、法规、企业资产的统一建模

要理解REANA，先要理解它和传统安全工具的本质区别。传统的功能安全工具链，比如我们常用的那些HARA工具、FMEA工具，本质是电子化的表单。工具本身不产生任何智能判断，它只是把你填进去的表格整理得好看一些、追溯关系画清楚一些。真正的安全分析思路，还是在人的脑子里。

REANA的结构不是这样。它的起点是把标准、法规、企业内部安全资产都变成Agent可以检索、推理的输入。

这一层里大概有这么几类东西：

• 标准文本：ISO 26262-2018全系列、ISO 21448-2022、ISO 21434-2021，以及GB/T对应的国内采标版本。这些是Agent推理时的“法律条文”，它必须知道ASIL A/B/C/D分别对应什么要求，也必须知道SOTIF里触发条件、可控性、潜在危害这几个维度之间的关系。
• 企业最佳实践：每个企业对自己的安全流程都有自己的补充要求。比如有些公司对ASIL D的系统有额外的冗余设计要求，有的是对信息安全的密钥管理有内部规范。这些不写进标准里，但REANA需要能识别。
• 已有的项目资产：上一代平台的安全分析报告、历史路测数据里的危险场景库、已知的信息安全攻击树，这些会被用来给Agent做参考。

这一层的关键点在于，标准和最佳实践必须结构化，不能只丢一堆PDF给Agent。REANA的做法是把标准里的条款拆成“要求ID + 约束条件 + 验证断言”这种带语义的结构，Agent拿到一个具体的功能描述时，能检索到相关的标准条款，而不是靠大模型凭记忆“概况”。这是我非常认可的一点，后面讲可追溯性的时候还要单独展开。

2.2 Agent层：不是一个大模型，而是一组分工明确的角色

REANA里最核心的设计是多Agent协作，而不是像早期AI工具那样一个对话框解决所有问题。这里面每一个Agent负责一个相对独立的认知任务。

我自己理解下来，REANA内部至少有这样几种角色：

需求解析Agent。它负责把用户输入的顶层功能描述拆成安全活动可处理的单元。比如你输入“开发城市工况下L2级自适应巡航系统”，这个Agent会识别出这是一项整车级功能，需要下钻到传感器、执行器、控制器层面，并据此去检索标准里针对ACC功能的功能安全、SOTIF、信息安全要求。

安全分析Agent（三域）。这是最核心的一组Agent，它们分别负责功能安全、SOTIF和网络安全分析。每个Agent掌握自己领域内的分析方法论：

• 功能安全Agent会走HARA流程：从危害事件出发，评估S、E、C三个参数，算出ASIL等级，给出安全目标，再往下推安全需求。
• SOTIF Agent会走ISO 21448的“预期功能不足”分析，从性能局限、触发条件、可预见误用三个维度找问题，给出对应的SOTIF相关措施。
• 信息安全Agent会走TARA（威胁分析与风险评估）的思路，识别资产、威胁场景、影响评级，给出网络安全目标和需求。

冲突仲裁Agent。三安一体化最大的难点不是“三个Agent分别干活”，而是它们干活的结果可能彼此矛盾。比如功能安全因为ASIL D要求系统增加冗余，但信息安全Agent可能认为冗余带来的额外通信接口扩大了攻击面；SOTIF Agent可能认为“传感器性能不足”应该通过降速策略缓解，但功能安全等级要求高速工况必须有响应能力。冲突仲裁Agent做的事情就是横向比对三份分析结果，把冲突点显性化，并生成一个带权衡建议的整合视图。

模板与合规Agent。它负责把分析结果按对应标准的结构生成交付物草稿：HARA报告、FSC（功能安全概念）、TSC（技术安全概念）、SOTIF相关分析、TARA报告、CSR（网络安全需求）等。这个Agent实际上是“写文档”的主力，它要保证输出物和企业的模板体系对得上，章节编号、追溯ID格式、评审记录位置都不能错。

这组Agent的配合方式，我拿到REANA的实际体验是第一版跑起来后，初稿的完成度比预想的高得多。因为每个Agent只在一小片领域里做推理，知识的深度和针对性远强于一个大而全的对话模型。

2.3 输出层：带追溯链的安全交付物，而不是一堆独立报告

REANA的输出层设计得非常克制，这跟很多AI工具的“生成完就完了”完全不同。它的所有生成结果都带三类追溯ID：

• 追溯ID到标准条款：每个安全需求旁边都有对应的ISO 26262或ISO 21448或ISO 21434条款编号。
• 追溯ID到上游资产：每个安全需求都能对应回是哪一个功能描述、哪一个危害事件、哪一个威胁场景。
• 追溯ID到下游验证活动：每个安全需求都会建议对应的验证和确认活动类型，方便后续接入测试管理和评审流程。

这三类追溯关系，恰好就是三安合规审核时最难人工维护的部分。以前做审计，我们最怕的就是检查员问“你这个安全目标是哪一条危险场景推导出来的？对应到哪个验证活动？”——所有人临时翻文档，翻半天还说不清楚。REANA从源头上把这条链建了起来，哪怕初稿质量只有60分，但追溯链是完整的，人工评审只需要改内容，不需要重新串链。

3. 三安协同的真正难点：SOTIF、功能安全与信息安全的边界

3.1 功能安全与SOTIF：危险与危害的区别

如果不实际做项目，很多工程师分不清功能安全和SOTIF的边界。我听到过最常见的误解是：“SOTIF是功能安全的一个子集”。其实不是。

ISO 26262里的功能安全，处理的是系统因故障（系统性失效、随机硬件失效）而导致危险的问题。它的核心假设是：如果所有组件都按设计意图正常工作，系统就是安全的；而安全机制要解决的，是“零件坏了怎么办”。

SOTIF处理的问题在另一个维度：系统没有故障，但预期功能在某些场景下达不到安全状态。典型的例子是AEB（自动紧急制动）在雨雾天气性能衰减，传感器认不出前方静止车辆——传感器没坏、算法设计也符合预期，但就是在这种场景下刹不住。ISO 21448专门处理这种“预期功能的功能局限”。

理解了这点，就不难理解为什么三安一体化需要专门的Agent来分开处理。功能安全Agent的推理起点是“失效模式”，SOTIF Agent的推理起点是“性能局限与场景触发条件”。两者的分析对象、方法、推导方向都不一样，如果只用一个通用Agent去做，很容易把故障树分析套到SOTIF场景上，得出一个看起来严谨、实际上跑偏的结论。

REANA的做法是：在底层共享同一个系统模型（组件、接口、功能列表），但每个Agent在自己的方法论框架内做独立推理，最后再通过冲突仲裁对齐。这个设计我实操下来觉得很靠谱，因为三安虽然互相影响，但各自的因果链条必须保持纯正——功能安全的因果链是“故障→失效→危险事件”，SOTIF的因果链是“性能局限+触发条件→危害场景”，混在一起就会导致无法追责、无法审计。

3.2 功能安全与信息安全：安全共谋与风险迁移

功能安全和信息安全的交互，是另一个经典难题。ISO 26262第三版里专门加了“安全与信息安全交互”的注释，ISO 21434里也大量引用功能安全的概念，但实操中这两拨人经常互相看不上。

功能安全工程师会担心：网络安全机制本身会不会导致安全功能不可用？比如网关做入侵检测，发现异常流量后主动切断某条通信链路——这个动作在信息安全角度看是合理的响应，在功能安全角度看可能导致转向或制动的控制指令中断，直接违反安全目标。

信息安全工程师也会担心：功能安全机制会不会变成攻击入口？比如为了满足ASIL D的冗余要求，双通道比对用了额外的数据交换通道——这个通道本身没有信息安全防护设计，攻击者可能通过注入虚假数据让两个通道的比对结果“共谋错误”，绕过安全机制。

三安一体化之所以难，就是这种反向制约关系几乎无处不在。REANA的仲裁Agent在做冲突检测时，并不只是找“措辞矛盾”，它会做一层风险迁移分析：识别一个安全措施是否会把风险从一个域迁移到另一个域，然后生成两域联合评审建议。这一层在传统人工流程里靠的是“功能安全评审会拉上网络安全工程师一起坐两个小时”，效率极低，而且经常漏。

3.3 SOTIF与信息安全的隐性交集

SOTIF和信息安全的交集是相对隐蔽的，但实际危害不小。SOTIF关注“预期功能不足”，而攻击者制造的“人为触发条件”在形态上很接近SOTIF里的触发条件。

举个例子：SOTIF分析摄像头在逆光条件下的感知衰减，结论是“逆光触发感知不足，需增加降级策略”。但一个攻击者不一定要物理上改变光照，他可能通过攻击摄像头ISP（图像信号处理）的配置接口，人为降低曝光参数，制造出等效于逆光的感知降级。这在SOTIF分析框架里不是“预期功能不足”，而是“蓄意干扰导致的性能降级”——但它触发的危害场景，跟SOTIF识别的场景是同一个。

REANA在这块的处理思路，是把信息安全的威胁场景作为SOTIF触发条件的候选输入，反之亦然。Agent在做TARA时，会检索SOTIF分析库中的触发条件列表，评估攻击者是否有能力或途径“人为制造”这些条件；做SOTIF分析时，也会查询TARA结果，判断识别出的性能局限是否可能被恶意利用。这样交叉验证出来的安全措施，比三拨人各写各的文档要周密得多。

4. 从“人建模型”到“Agent建初稿”：工作流和角色的变化

4.1 传统工作流 vs Agent工作流：一张对照表讲清楚变化

先放一张我总结的对比表，这个表基本能说明两种工作方式的本质差异：

环节	传统人工工作流	REANA Agent工作流
输入方式	人工阅读功能描述文档，手工提炼安全分析对象	直接输入功能描述文本（或导入已有架构模型），Agent自动拆解分析单元
危害/威胁识别	安全工程师开头脑风暴会，靠经验和清单逐条核对	安全分析Agent根据标准条款和知识库自动生成候选清单，人工在此基础上增删
等级评定	人工对照标准表格打分，耗时且容易因评审人不同产生偏差	Agent依据标准自动计算，输出完整推导链条，供评审复核
安全需求生成	从分析结果手工编写需求条目，措辞和格式极易不统一	模板Agent按企业模板自动生成需求条目，格式、ID、追溯关系自动维护
三安冲突处理	“联席评审会”精力消耗大、漏检率高	冲突仲裁Agent自动交叉检测，输出冲突清单和权衡建议
追溯关系维护	手工维护追溯矩阵，项目后期几乎无法跟上变更	每次初稿生成时自动重建追溯链，变更后差异对比自动更新
合规审计	审计前突击补文档、补签字	交付物自带条款映射关系，审计准备时间大幅缩短

这张表做完后，我最强烈的感受是：效率差异只是表象，真正的差异是“安全活动从人的经验驱动变成了知识库+标准驱动”。人工工作流里，一个高危功能的HARA分析质量，很大程度取决于做分析的那个人脑子里装了多少案例；Agent工作流里，起点是标准条款和知识库里沉淀的历史项目教训，人变成“审核者”而不是“创作者”。

很多人一听Agent替代人建模型就焦虑，但实际跑下来，真正的变化是角色变化——不是岗位消失，而是你花在“从空白页开始憋内容”上的时间大幅减少，花在“判断Agent给出的初稿对不对”上的时间大幅增加。后者才是真正的安全工程核心能力。

4.2 Agent初稿的校验与人工介入点

Agent生成的初稿不是用来直接签字的，它更像是一个**“有推理过程的高质量草稿”**。在REANA的流程设计里，人工干预点被放在几个关键节点上：

第一个干预点是确认分析单元划分。Agent把顶层功能拆成若干分析对象后，人需要确认拆得有没有漏、有没有多。这一步很轻，但影响整个下游，因为Agent后续所有的分析都会挂在这些分析单元下面。如果拆分粒度不对——比如把一个系统级功能拆成了组件级危害分析——后续输出会非常难看。

第二个干预点是评定依据的复核。Agent算完ASIL等级或攻击影响等级后，人在评审表里确认打分理由是否成立。这里需要特别注意的是：Agent给的评分推导通常是对的，但前提假设可能存在问题。例如Agent做了“驾驶员可控性为C0”的假设，但如果这个车是L4级自动驾驶，没有驾驶员，这个假设就不成立。这类“场景前提”判断，目前Agent没法替人做，因为它默认按标准里最常见的场景假设去推理。

第三个干预点是冲突仲裁结果。Agent把三安冲突列出来以后，人需要做最终取舍。这里REANA会给一个“建议倾向”，但真正的Trade-off决策必须由人来定。比如前面说的“信息安全切断通信链路 vs 功能安全要求链路持续可用”这个冲突，到底是让网络安全机制降级为“告警不阻断”，还是让功能安全设计接受“可短暂降级但必须有降级提示”，这涉及整车级的策略，不是Agent能越俎代庖的。

我自己的经验是，这批干预点设计得越清晰，使用Agent的抵触情绪越低。因为工程师最怕的不是AI“做得太多”，而是AI“闷头全做完了还不告诉你为什么”。REANA这种“Agent建初稿→人工按点抽查复核→确认后进入正式评审”的模式，专业工程师的接受度明显更高。

4.3 从“文档工程师”到“安全评审师”的角色转变

三安一体化加上Agent化之后，对从业者提出了新的技能要求。这也算是我个人最想提醒同行的一点。

过去几年，很多功能安全工程师的工作内容本质上是在“写安全文档”，真正对设计提出约束、影响架构决策的比例并不高。原因是安全分析链路太长，大部分精力消耗在台账和模板里。REANA把初稿和台账的活自动化掉之后，安全工程师的时间和精力反而被释放到更有价值的环节——跟系统架构师拉扯，跟ESW（嵌入式软件）团队沟通约束，跟测试团队确认验证策略。

这对人的能力要求其实变高了，因为你需要在一个下午的评审会上，快速判断Agent生成的三份安全分析里有没有逻辑跳跃、有没有前提不成立、有没有三安之间的隐藏冲突。说白了，工具越智能，“发现问题”的份额越高，“生产内容”的份额越低。

我的建议是：如果还在做安全工作的同行，尽早开始培养“质疑Agent推理过程”的习惯。把Agent当成一个帮你把标准条文搬过来、把推理链铺开来的副驾驶，而不是一个替你签字的领导。凡是你自己都看不出破绽的初稿，恰恰最需要警惕——因为那往往意味着Agent用了某种过于“标准”的假设，而现实中没那么理想。

5. 落地REANA的实战心得：模型选型、知识库建设与可追溯性

5.1 知识库建设是决定上限的关键

前面说了REANA的架构，如果把Agent比作发动机，那知识库就是汽油。没有好的知识库，Agent引擎再强也跑不远。这块我在实际预研和试用中体会特别深。

最核心的一条经验：知识库不能只塞标准和法规，一定要塞企业自己的“失败经验”。标准告诉Agent“应该怎么做”，但只有历史项目数据才能告诉Agent“我们上次在这个环节是怎么翻车的”。比如某个具体型号的毫米波雷达在雪天工况下误检率偏高，这类信息写不进标准，但对SOTIF分析非常有参考价值。如果不喂给Agent，它只能泛泛地按ISO 21448的框架走一遍，生成的分析结果“正确但无用”。

实际建库时，我的优先级排序是：

1. 已过审项目的安全报告及评审意见——这里边有最强的实战知识，尤其是评审人关注的问题点。
2. 标准条款的结构化拆解——至少要拆到“条 + 约束 + 验证活动”这个粒度。
3. 内部安全流程规范与模板——保证输出能直接入企业的流程体系。
4. 行业公开的事故/召回案例库——补充场景库的覆盖率，尤其是SOTIF侧的真实触发条件。

这个库的建设周期比很多人想的要长，收集、清洗、标注、定期更新，每一步都不轻松。但一件事可以确认：知识库的深度直接决定了Agent初稿的可用度。知识库只有标准文本时，Agent产出的初稿质量大约相当于“刚入行一年的工程师照着模板发挥”；知识库稍好一点、有项目数据时，质量能到“三年经验的工程师带标准答案”的水平。这个投入是值得的。

5.2 大模型幻觉问题，在安全领域要用“结构约束”治

AI生成内容的通病是幻觉——一本正经地编造不存在的标准条款编号、虚构不成立的因果链路。在汽车安全文档里，幻觉是绝对不能忍的，因为交付物要过审计，条款引用错误、ID对不上，都会造成合规风险。

REANA处理幻觉的思路很值得借鉴。它不让大模型自由发挥引用标准条款，而是走“检索-约束-生成”的链路：

• 先生成语义检索条件，把可能相关的标准条款从知识库捞出来。
• 再让Agent在“已被检索到的条款集内”做推理，引用附件里明确给出条款编号。
• 最后输出前做一次条款编号校验，引用的所有ID必须和知识库里的实际条目完全匹配，匹配不上就自动重新检索。

这一套下来，幻觉出现的概率会大幅降低。但不是说完全消除，我在实际使用中依然发现过Agent把条款内容张冠李戴的情况，比如把ISO 26262-5里硬件度量的示例套用到ISO 21448里。所以人工复核仍然不可省。

这里给准备上这类工具的同行的实用建议是：配置环节一定要打开“引用必须带条款上下文”的开关，同时要求Agent把所有引用ID以清单形式附在文档末尾。这样人工核对时不需要一页页翻，直接拿清单去查标准原文就行，半小时能查完一份报告的核心引用。

5.3 可追溯性才是三安合规的命门

最后这一点，是给所有做安全合规的同行划的重点。审计检查员真正看的往往不是你的报告内容有多充实，而是能不能提供清晰的证据链：从顶层危害到安全目标，从安全目标到安全需求，从安全需求到验证活动，每一步都有明确的ID关联，而且能一键闭环。

以前人工维护这条链是最消耗体力的。项目中期一次需求变更，会引发几十条安全需求的关联变更，追溯矩阵经常改到崩溃。而REANA的Agent生成初稿时就把追溯关系内建到了每一个条目里，变更时做一次差异对比，哪些条目受影响一目了然。

但这不意味着你可以高枕无忧。有一条红线必须守住：Agent生成的追溯关系再完整，如果后来人工修改了某条需求，追溯链必须同步更新，否则就断了。REANA在这一点上做了流程锁定——只要文档里的安全需求发生编辑，系统就会重新跑一次追溯关系校验，把断裂点标出来。我强烈建议所有人在流程里把这个校验设为“强制评审项”，不允许跳过。因为合规审计最怕的不是追溯缺失，而是“看起来有追溯、实际对不上”的假闭环。

6. 下一步：从初稿到全流程Agent化，安全交付物的新形态

REANA目前的定位还是“Agent建初稿”，人来做评审和确认。但按照我现在看到的趋势，这个边界下一步一定会往前后两端延伸。

往前端延伸，是安全概念阶段的自动化生成。现在Agent已经能根据功能描述生成HARA和TARA初稿，下一步就是直接给出初步的系统安全架构建议——安全机制要怎么加、冗余怎么分配、边界保护怎么设计。这个方向的技术难度更高，因为它需要Agent具备系统设计能力，而不只是分析能力。但已经有一些工具在往这个方向探索了。

往后端延伸，是安全验证活动的自动规划。Agent分析完生成安全需求后，直接把对应的测试用例框架、验证计划和路测场景建议也一起拉出来。这个方向上，REANA的思路是把安全分析与测试管理工具链打通，安全需求一落地，相关测试用例自动挂接。

另外还有一个我非常看好的方向：安全案例（Safety Case）的自动组织。三安一体化之后，一个项目除了三份独立的安全报告，往往还需要一份“安全论证总报告”，把功能安全、SOTIF、信息安全的论证逻辑整合成一条完整的安全证据链。这个文档以前写起来特别费劲，因为它要求作者同时对三个领域有深入理解，还要能讲清楚它们之间的交互。如果Agent能把三份分析结果基于同一个系统模型做交叉论证，这个总报告的初稿生成质量可能会非常惊人。

回到标题那句话——“从‘人建模型’到‘Agent建初稿’”。我现在越来越觉得，这个命题里的核心不在于“谁建得更快”，而在于安全工程把人的注意力从“生成”腾挪到“判断”上之后，整个体系的质量上限被重新打开了。初稿是快是慢只是表象，真正的变化是：人的经验终于不用浪费在铺陈性劳动里，而是全部压到最关键的价值判断点上去。这也是我试用REANA之后，最想告诉同行们的一件事。